La succession gwu - gwc - gwu introduit des différences dans le fichier .gw et provoque une erreur

[hgouraud]

gwu base -o base.gw gwc base.gw -o base1 gwu base1 -o base1.gw diff base.gw base1.gw

10206c10206
< comm 11 enfants dont 2 garçons et 5 filles survivent                         

---
> comm 11 enfants dont 2 garçons et 5 filles survivent         

Il y a un espace en plus dans la seconde ligne!!

gwc base1.gw -o base2
gwu base2 -o base2.gw
*** loading ascends array
*** loading couples array
*** loading unions array
*** loading descends array
Error get_field_acc "family/fevents/access" i = 0
Uncaught exception: Sys_error("base2.gwb/base_d/family/fevents/access: No such file or directory")

[GuillaumeBrochu]

Bonjour,

Il faudrait savoir quelle version vous utilisez (# du dernier commit, dépôt geneanet/geneweb ou geneweb/geneweb ou autre, et branche master ou api ou autre). Je pourrai ensuite tenter de reproduire votre bug de mon côté, ce problème m'affecte et m'intéresse moi aussi.

Il y a PEUT-ÊTRE un lien avec ce bug : https://github.com/geneanet/geneweb/issues/359, pour lequel il fut observé que https://github.com/geneanet/geneweb/commits/master/src/gwu.ml est deux commits derrière https://github.com/geneanet/geneweb/commits/api/src/gwu.ml.­­

De plus, dans ce message (https://github.com/geneanet/geneweb/issues/359#issuecomment-168504280) vous aviez observé un problème du même type (corruption de l'opération gwu -> 1.gw, gwc1 -> 2.gwb, gwu -> 2.gw).

Pour ma part, j'ai aussi observé que le "gwu" de la version de Geneweb utilisée par Geneanet.org (testé début janvier 2016) supprime de façon anormale des retours de chariot dans les notes des personnes, ce qui peut complètement briser le formatage que les usagers donnent à ces notes.

Mon intuition... il y a des bonnes chances que tout cela soit relié...

Guillaume

[hgouraud]

J’ai fait ce test hier avec la version suivante du dépôt geneweb/geneweb:

Compilation configuration

WARNING: remember to re-create your bases from .gw files

The OCaml toplevel, version 4.02.3 Camlp5 version 6.14 (ocaml 4.02.3) Darwin iMac-H 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 ProductName: Mac OS X ProductVersion: 10.10.5 BuildVersion: 14F1021 GeneWeb version : 7.00-127530a7 (Mar 10 nov 2015 13:25:34 CET)

(Mon script de compilation conserve automatiquement les informations ci-dessus. Je vais y rajouter le dépôt d’origine.).

Je viens de refaire l’essai avec la branche gwc2. Le problème de l’espace en trop persiste, mais l’échec au deuxième tour disparait - j’ai fait trois tours)

Compilation configuration

git clone https://github.com/geneweb/geneweb -b gwc2 gw-7.02-Mac WARNING: remember to re-create your bases from .gw files

The OCaml toplevel, version 4.02.3 Camlp5 version 6.14 (ocaml 4.02.3) Darwin iMac-H 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 ProductName: Mac OS X ProductVersion: 10.10.5 BuildVersion: 14F1509 GeneWeb version : 7.02-7ff02e44 (Sam 9 jan 2016 08:42:30 CET) iMac-H:GeneWeb-7.02-Mac Henri$

A suivre

Henri

Le 9 janv. 2016 à 02:43, Guillaume Brochu notifications@github.com a écrit :

Bonjour,

Il faudrait savoir quelle version vous utilisez (# du dernier commit, dépôt geneanet/geneweb ou geneweb/geneweb ou autre, et branche master ou api ou autre). Je pourrai ensuite tenter de reproduire votre bug de mon côté, ce problème m'affecte et m'intéresse moi aussi.

Il y a PEUT-ÊTRE un lien avec ce bug : #359 https://github.com/geneanet/geneweb/issues/359, pour lequel il fut observé que https://github.com/geneanet/geneweb/commits/master/src/gwu.ml https://github.com/geneanet/geneweb/commits/master/src/gwu.ml est deux commits derrière https://github.com/geneanet/geneweb/commits/api/src/gwu.ml https://github.com/geneanet/geneweb/commits/api/src/gwu.ml.

De plus, dans ce message (#359 (comment) https://github.com/geneanet/geneweb/issues/359#issuecomment-168504280) vous aviez observé un problème du même type (corruption de l'opération gwu -> 1.gw, gwc1 -> 2.gwb, gwu -> 2.gw).

Pour ma part, j'ai aussi observé que le "gwu" de la version de Geneweb utilisée par Geneanet.org (testé début janvier 2016) supprime de façon anormale des retour de chariot dans les notes des personnes, ce qui peut complètement briser le formatage que les usagers donnent à ces notes.

Mon intuition... il y a des bonnes chances que tout ceci soit relié...

Guillaume

— Reply to this email directly or view it on GitHub https://github.com/geneanet/geneweb/issues/368#issuecomment-170177082.

[GuillaumeBrochu]

J'ai observé la même chose que vous (ajout d'espace à la fin du comm) avec ma propre base, mais sans plantage ni de gwc, ni de gwu.

Famille problématique:

fam MAHEU Jean-Paul + #nm BRUNEAU Catherine
comm Marie-Anne Maheu est un enfant naturelle  
fevt
#nmar 
end fevt
beg
- f Marie-Anne #salias PAUL #salias LAROSE #apubl 0 0
end

À chaque répétition [ .gw -> gwc -> gwu -> ] il s'ajoute un espace à la fin du commentaire de famille (comm). J'ai fait jusqu'à 4 tours (donc jusqu'à 4 espaces ajoutés), mais sans plantage.

J'ai vérifié avec un éditeur hexadécimal qu'il s'agissait bien d'espaces (0x20). Je n'ai pas testé gwc2, sachant qu'il est encore en développement.

On note que j'ai aussi observé des plantages de gwu, mais il ne sont pas dus aux espaces. Je vais rapporter ce bug plus tard après l'avoir étudié plus en profondeur.

N.B. Pour ce test, j'ai compilé geneweb/geneweb/master (à ce commit du 24 déc, https://github.com/geneweb/geneweb/commit/d6bec129e9cad750c9e25e21fc0f9e1d56cf147f) avec Linux (Debian Jessie) et Ocaml 4.02.3 (Opam)

[hgouraud]

Lors d'un premier essai, j'avais aussi observé un caractère supplémentaire, dans des dates textuelles contenant des caractères soulignés!! :

13837c13837
<  #deat 0(_\_\_\_\_\_\_\_\_?\_) #p Amiens_(Somme)
---
>  #deat 0(_\_\_\_\_\_\_\_\_\_?\_) #p Amiens_(Somme)

provient de

pevt Carlier Marie
#birt 9/7/1897 #p Valenciennes_(Nord)
#deat 0(_\_\_\_\_\_\_\_\_?\_) #p Amiens_(Somme)
end pevt

A l'affichage, cela donne : Décès (____?_) · Amiens (Somme)

Henri

[dominique95880]

Bonjour Guillaume

C'est gwu qui ajoute cet espace supplémentaire.

Ci dessous mon test prouvant cela. Partant d'une base correcte, je constate 1° Il n'y a pas d'espace final au commentaire d'union (formulaire modifier famille par exemple) 2° Il n'y a pas non plus d'espace final dans un fichier gedcom généré par gwb2ged 3° Mais il y a un espace final dans un fichier gw généré par gwu.

C'est gênant, mais ce n'est pas gravissime

• puisque cet espace est invisible en consultation de base
• puisqu'un éditeur de texte tel Notepad++ est capable de supprimer tous les blancs en fin de ligne d'un fichier gw

Dominique

Le 10/01/2016 03:12, Guillaume Brochu a écrit :

J'ai observé la même chose que vous (ajout d'espace à la fin du comm) avec ma propre base, mais sans plantage ni de gwc, ni de gwu.

Famille problématique:

|fam MAHEU Jean-Paul + #nm BRUNEAU Catherine comm Marie-Anne Maheu est un enfant naturelle fevt #nmar end fevt beg - f Marie-Anne #salias PAUL #salias LAROSE #apubl 0 0 end |

À chaque répétition [ .gw -> gwc -> gwu -> ] il s'ajoute un espace à la fin du commentaire de famille (comm). J'ai fait jusqu'à 4 tours (donc jusqu'à 4 espaces ajoutés), mais sans plantage.

J'ai vérifié avec un éditeur hexadécimal qu'il s'agissait bien d'espaces (0x20). Je n'ai pas testé gwc2, sachant qu'il est encore en développement.

On note que j'ai aussi observé des plantages de gwu, mais il ne sont pas dus aux espaces. Je vais rapporter ce bug plus tard après l'avoir étudié plus en profondeur.

N.B. Pour ce test, j'ai compilé geneweb/geneweb/master (à ce commit du 24 déc, geneweb@d6bec12 https://github.com/geneweb/geneweb/commit/d6bec129e9cad750c9e25e21fc0f9e1d56cf147f) avec Linux (Debian Jessie) et Ocaml 4.02.3 (Opam)

— Reply to this email directly or view it on GitHub https://github.com/geneanet/geneweb/issues/368#issuecomment-170300737.

[hgouraud]

Dominique,

ces espaces supplémentaires ne sont effectivement pas « catastrophiques », mais ils détruisent une des caractéristiques de GeneWeb que Daniel mettait souvent en avant : l’utilisation de l’outil Unix « diff » pour suivre les évolutions d’une base!!

Je pense qu’il est important d’apporter une correction à ce bug.

Amitiés,

Henri

Le 10 janv. 2016 à 11:50, Dominique DERAM notifications@github.com a écrit :

Bonjour Guillaume

C'est gwu qui ajoute cet espace supplémentaire.

Ci dessous mon test prouvant cela. Partant d'une base correcte, je constate 1° Il n'y a pas d'espace final au commentaire d'union (formulaire modifier famille par exemple) 2° Il n'y a pas non plus d'espace final dans un fichier gedcom généré par gwb2ged 3° Mais il y a un espace final dans un fichier gw généré par gwu.

C'est gênant, mais ce n'est pas gravissime

• puisque cet espace est invisible en consultation de base
• puisqu'un éditeur de texte tel Notepad++ est capable de supprimer tous les blancs en fin de ligne d'un fichier gw

Dominique

Le 10/01/2016 03:12, Guillaume Brochu a écrit :

J'ai observé la même chose que vous (ajout d'espace à la fin du comm) avec ma propre base, mais sans plantage ni de gwc, ni de gwu.

Famille problématique:

|fam MAHEU Jean-Paul + #nm BRUNEAU Catherine comm Marie-Anne Maheu est un enfant naturelle fevt #nmar end fevt beg - f Marie-Anne #salias PAUL #salias LAROSE #apubl 0 0 end |

À chaque répétition [ .gw -> gwc -> gwu -> ] il s'ajoute un espace à la fin du commentaire de famille (comm). J'ai fait jusqu'à 4 tours (donc jusqu'à 4 espaces ajoutés), mais sans plantage.

J'ai vérifié avec un éditeur hexadécimal qu'il s'agissait bien d'espaces (0x20). Je n'ai pas testé gwc2, sachant qu'il est encore en développement.

On note que j'ai aussi observé des plantages de gwu, mais il ne sont pas dus aux espaces. Je vais rapporter ce bug plus tard après l'avoir étudié plus en profondeur.

N.B. Pour ce test, j'ai compilé geneweb/geneweb/master (à ce commit du 24 déc, geneweb@d6bec12 https://github.com/geneweb/geneweb/commit/d6bec129e9cad750c9e25e21fc0f9e1d56cf147f) avec Linux (Debian Jessie) et Ocaml 4.02.3 (Opam)

— Reply to this email directly or view it on GitHub https://github.com/geneanet/geneweb/issues/368#issuecomment-170300737.

— Reply to this email directly or view it on GitHub https://github.com/geneanet/geneweb/issues/368#issuecomment-170333959.

[hgouraud]

Après comparaison avec le code de la version 6.08-alpha, dans gwu, en ligne 796, j'ai supprimé l'espace après le %s, et le problème a disparu. Je soupçonne qu'il pourrait y avoir d'autres endroits où le même problème existe (par exemple en ligne 800)!!

794   if (comm <> "" || has_evt) then do {
795      fprintf oc "comm ";
796      if comm <> "" then fprintf oc "%s" (no_newlines comm)
797      else ();
798      if old_gw.val then do {
799        if sou base (get_marriage_note fam) <> "" then
800         fprintf oc "marriage: %s "
801            (no_newlines (sou base (get_marriage_note fam)))
802        else ();
803        List.iter
804          (fun e -> do {print_fevent oc base gen True e; fprintf oc " "})
805          fevents;
806      }

Je ne maitrise pas suffisamment Ocaml pour trancher!! Pour le cas #deat (_ ... je ne trouve pas où cela se passe dans le code!! Probablement là où sont traitées les chaines de caractères (remplacement des espaces par "", et donc remplacement des "" par "", sauf que cela ne comme pas pour le premier!!). Mickael? Fabien? Help

A suivre

Henri

[GuillaumeBrochu]

En effet...

Voir https://github.com/geneweb/geneweb/blob/distrib-6-08/src/gwu.ml#L535-L538 vs https://github.com/geneweb/geneweb/blob/master/src/gwu.ml#L794-L810

Le code de gwu a considérablement changé avec la V7, je suis un peu perdu...

La variable "old_gw.val" du code récent semble permettre de faire des actions différentes selon sa valeur. À la lecture du code, sous toutes réserves, la variable "old_gw.val" me donne l'impression d'être vraie si la version de geneweb est récente (>=7.0), ce qui est un peu contre-intuitif ! Et pourquoi cette chaîne de caractères "marriage: " à la ligne 800, je ne vois pas ça dans le format gwplus (http://geneweb.tuxfamily.org/wiki/GWformat)??? Faudrait-il documenter ceci dans le wiki?

Si on enlève l'espace après le %s à la ligne 796, faut-il aussi en mettre un devant le mot "marriage:" à la ligne 800, c'est-à-dire " marriage: %s " ???

AJOUT (10jan2016, 18 : 04 GMT):

~~pour "old_gw.val", voir : https://github.com/geneweb/geneweb/blob/master/src/gwu.ml#L10-L11 https://github.com/geneweb/geneweb/blob/master/src/gwu.ml#L1879-L1880~~

Bref, c'est un paramètre qui est toujours à False (semble hard-codé), mais qui sera éventuellement relié à l'option -old_gw si j'ai bien compris...

AJOUT (23jan2016):

Ce qui est barré = erreur d'interprétation de ma part... désolé

[GuillaumeBrochu]

Pour le problème d'espace supplémentaire avec le #deat, c'est peut-être dû au fait qu'il est lié à une date au format libre 0(...) (voir http://geneweb.tuxfamily.org/wiki/GWformat#Dates).

Probablement que la combinaison événement #deat et date au format libre 0(...) ne passe pas bien...

Si j'ai bien compris le format gwplus, les événements répètent les dates des informations des personnes et familles (redondance...). Est-ce qu'il y a aussi des espaces supplémentaires qui s'ajoutent dans le #deat 0(...) situé dans les informations de la personne?

[GuillaumeBrochu]

Ultimement, pour trouver tous ces problèmes de conversion, il faudrait se faire une base V6 de quelques personnes avec systématiquement TOUS les champs remplis et utilisés (et qui utilise toutes les particularités rarement utilisées du format .gw), tenter d'importer ceci dans la V7, faire des boucles gwc->gwu, utiliser les templates V7 pour éditer les champs, et voir les différences entre les fichiers .gw. Des heures de plaisirs :-)

[a2line]

Oui. Redondance dont on se passerait bien vu le volume d'info qu'elle a ajouté aux bases passées en v7.

J'avais fait le décorticage du diff. pour ma base la semaine dernière à la demande d'Henri. Voilà ce que j'ai observé :

« Pour la science j'ai appliqué ce processus sur ma base importée d'une 6.08 j'ai +4050 lignes différentes !!! :

• tous les « od » pour « certainement décédé » deviennent 0 (environ 1140 comme ça) ;
• tous les « comm » après un fam (commentaires de mariage) gagnent une espace finale (environ 2900 espaces en rab ! à chaque opération > BAD)
• le e dans « e884 » (exécuté en 884) disparait pour « 884 » seul ;

Le reste c'était quelques bêtises à moi qui sont mise en avant et que j'ai pu corriger dans ma base :

• « #mj » (mort jeune) qui disparait car la personne est vivante (:þ) ;
• des burials qui permutent avec des death à cause d'une typo dans l'année ;
• « #nsck mf » (no sex check pas marié) se transforme en « #nm » ;
• « #nsckm mf » qui disparait, ces deux dernier ne sont pas documentés sur le wiki, à comparer les 4 fiches c'est juste des cas où la case « union homosexuelle (nsck) » a été cochée par mégarde qui sont auto-corrigée car les sexes sont différents. »

– A2

[GuillaumeBrochu]

Merci A2.

Par contre, je ne suis pas convaincu que toutes ces anomalies sont dues à gwu. Certaines sont dues à gwc à mon avis (à confirmer). À ce sujet, voir aussi : https://github.com/geneanet/geneweb/issues/369

[a2line]

Un ancien aurait peut-être une base de test v6 de ce genre qui traine dans la poussière d'un de ses vieux dossiers ??!

Ce serait plus utile que https://github.com/geneanet/geneweb/blob/master/test/grimaldi.ged qui est plus une base de démo que de test…

Mail précédent à Henry :

« J'ai essayé ged2gwb>gwu>gwc>gwu>gwc en boucle sur la base grimaldi.ged ça ajoute d'abord trois mariages automatiquement, et une espace en plus à une seule ligne par boucle après « ENGAGEMENT_ ». Il faudrait que cette autocorrection ajoute #nmen à la place de #marr (forcé !).

fam CASIRAGHI Andrea + SANTO_DOMINGO Tatiana 24/11/1983 #bp Genève,1200,Genève,Région_Lémanique,SUISSE comm evenement: PACS [juillet 2012]

_UST: ENGAGEMENT

Ce passage devient à la première passe :

fam CASIRAGHI Andrea + SANTO_DOMINGO Tatiana 24/11/1983 #bp Genève,1200,Genève,Région_Lémanique,SUISSE comm evenement: PACS [juillet 2012]

_UST: ENGAGEMENT fevt

marr

end fevt »

Le 10 janvier 2016 à 17:06, Guillaume Brochu notifications@github.com a écrit :

Ultimement, pour trouver tous ces problèmes de conversion, il faudrait se faire une base V6 de quelques personnes avec systématiquement TOUS les champs remplis et utilisés (et qui utilise toutes les particularités rarement utilisées du format .gw), tenter d'importer ceci dans la V7, faire des boucles gwc->gwu, utiliser les templates V7 pour éditer les champs, et voir les différences entre les fichiers .gw. Des heures de plaisirs :-)

— Reply to this email directly or view it on GitHub https://github.com/geneanet/geneweb/issues/368#issuecomment-170362467.

[hgouraud]

Les espaces en double apparaissent aux deux endroits où la date (format libre) apparaît. Il faut regarder dans le traitement des champs texte dans lesquels les espaces sont replacés par des « _ », mais pour cela, je pense qu’il faut bien maitriser Ocaml. La tentative que j’ai faite n’a pas aboutie!!

Henri

Le 10 janv. 2016 à 17:00, Guillaume Brochu notifications@github.com a écrit :

Pour le problème d'espace avec le #deat, c'est peut-être dû au fait qu'il est lié à une date au format libre 0(...) (voir http://geneweb.tuxfamily.org/wiki/GWformat#Dates http://geneweb.tuxfamily.org/wiki/GWformat#Dates).

Probablement que la combinaison événement #deat et date au format libre 0(...) ne passe pas bien...

Si j'ai bien compris le format gwplus, les événements répètent les dates des informations des personnes et familles (redondance...). Est-ce qu'il y a aussi des espaces supplémentaires qui s'ajoutent dans le #deat 0(...) situé dans les informations de la personne?

— Reply to this email directly or view it on GitHub https://github.com/geneanet/geneweb/issues/368#issuecomment-170362043.

[hgouraud]

Dans le code de updateData.ml, il est fait plusieurs fois référence à (* Astuce pour gérer les espaces. *) qui utilise Mutil.tr ' ' '’ pour remplacer les espaces par des Je n’ai pas trouvé l’endroit ou un texte contenant déjà des est traité!! Il se peut aussi que le fait que le caractère ait une utilisation sémantique forte dans Ocaml soit à l’origine du problème

Henri

Le 10 janv. 2016 à 17:51, Henri Gouraud Henri.Gouraud@LaPoste.net a écrit :

Les espaces en double apparaissent aux deux endroits où la date (format libre) apparaît. Il faut regarder dans le traitement des champs texte dans lesquels les espaces sont replacés par des « _ », mais pour cela, je pense qu’il faut bien maitriser Ocaml. La tentative que j’ai faite n’a pas aboutie!!

Henri

Le 10 janv. 2016 à 17:00, Guillaume Brochu <notifications@github.com mailto:notifications@github.com> a écrit :

Pour le problème d'espace avec le #deat, c'est peut-être dû au fait qu'il est lié à une date au format libre 0(...) (voir http://geneweb.tuxfamily.org/wiki/GWformat#Dates http://geneweb.tuxfamily.org/wiki/GWformat#Dates).

Probablement que la combinaison événement #deat et date au format libre 0(...) ne passe pas bien...

Si j'ai bien compris le format gwplus, les événements répètent les dates des informations des personnes et familles (redondance...). Est-ce qu'il y a aussi des espaces supplémentaires qui s'ajoutent dans le #deat 0(...) situé dans les informations de la personne?

— Reply to this email directly or view it on GitHub https://github.com/geneanet/geneweb/issues/368#issuecomment-170362043.

[GuillaumeBrochu]

Pour le cas d'ajout d'espaces dans la date en format texte 0(...) (voir https://github.com/geneanet/geneweb/issues/368#issuecomment-170328924)

J'ai fait un test d'itérations successives .gw->gwc->gwu->.gw avec une date en format texte 0(...) contenant trois mots séparés par des espaces, et le texte reste le même d'une itération à l'autre. J'ai aussi essayé avec "?" comme texte initial et encore une fois le texte reste le même.

Donc, je ne suis pas capable de reproduire ce bug. Ça me semble être un cas vraiment particulier...

[hgouraud]

Oui, c’est un cas particulier, celui de la présence d’un caractère au début du texte de la date en format 0(…). a ne provoque pas l’erreur _a provoque l’erreur

< #deat 0(_a) #p Amiens(Somme)

deat 0(__a) #p Amiens(Somme)

Il me semble que la première ligne aurait du être < #deat 0(a) #p Amiens(Somme)

Dans le cas a_b, on a

deat 0(ab) #p Amiens(Somme)

A suivre Henri

Le 10 janv. 2016 à 23:28, Guillaume Brochu notifications@github.com a écrit :

Pour le cas d'ajout d'espaces dans la date en format texte 0(...) (voir #368 (comment) https://github.com/geneanet/geneweb/issues/368#issuecomment-170328924)

J'ai fait un test d'itérations successives .gw->gwc->gwu->.gw avec une date en format texte 0(...) contenant trois mots séparés par des espaces, et le texte reste le même d'une itération à l'autre. J'ai aussi essayé avec "?" comme texte initial et encore une fois le texte reste le même.

Donc, je ne suis pas capable de reproduire ce bug. Ça me semble être un cas vraiment particulier...

— Reply to this email directly or view it on GitHub https://github.com/geneanet/geneweb/issues/368#issuecomment-170399804.

[GuillaumeBrochu]

Je confirme le bug trouvé ci-haut par hgouraud pour les dates en format texte qui commencent par un "_".

Autant la toute dernière version de gwu soumise hier en pull request (https://github.com/geneweb/geneweb/pull/5) que la version venant avec la version 6.08 ont le problème. C'est donc un bug relativement vieux, il n'a pas été introduit avec les modifications majeures de la V7.00.

[GuillaumeBrochu]

Bug sur l'ajout d'espaces dans les commentaires des familles et bug sur l'ajout de barres de soulignement "_" dans les dates en format texte:

J'ai vérifié que c'était bien réglé en compilant et testant le nouveau code correspondant à ces deux commits :

https://github.com/geneweb/geneweb/commit/8f1d9a56e59c282e9a59fd6af7b6f68758128ca3 https://github.com/geneweb/geneweb/commit/3593e71a6de5ba20a4062690e3721335345d3f55

Cette "issue" pourrait être fermée.

[a2line]

Leave a comment