Discussion :

[bumbolol]

Je voudrais savoir s'il y a en ocaml une fonction tout prete (p-e au travers de la zlib) pour calculer le crc32 d'une chaine de caractère ?

Merci.

[adtunum]

Bonsoir,
je viens de regarder dans camlzip et dans camlbz2 et je n'en trouve pas trace.
Cependant j'ai commencé il y a peu un binding pour la lib lzma et j'avais vu la précence d'une fonction lzma_crc32() dans un des header C de la lib.
Je viens d'ajouter cette fonction au binding, tu peux télécharger les sources avec cette commande :

svn checkout svn://scm.ocamlcore.org/svnroot/ocaml-lzma

Je l'ai testé, j'obtiens le même résultat qu'avec la fonction crc32 de PHP.

[adtunum]

Re,

Je profite de l'occasion pour faire une petite présentation du lzma pour ceux qui ne le connaîtraient pas encore.
Il s'agit d'un algo de compression qui auparavant n'était pas libre et donc qui n'était pas utilisé dans le monde du libre. Il me semble que c'est il y a environ 2 ans qu'il a été placé dans le domain public, depuis de nombreuses distributions linux l'on adopté comme par exemple avant dans Mandriva les pages de man étaient compressées en bz2 mais maintenant la totalité des pages de man sont compressées en lzma. Certains éléments de packaging utilisent aussi la compression lzma dans mandriva, comme dans d'autres distros. L'extension réduite pour .tar.lzma est .tlz ou .txz pour le .tar.xz (xz correspond au lzma2), pour décompresser une archive .tar.lzma on utilise l'option Y en ligne de commande ce qui donne "tar xYf tarball.tar.lzma".

Le lzma donne donc comme vous l'avez compris un résultat de taille inférieur à ce que donnent gzip et bzip2, voici quelques chiffres (en anglais) :
"""
Lzma provides very high compression ratio and fast decompression:

- Average compression ratio 30% better than that of gzip and 15%
better than that of bzip2.

- Decompression speed is only little slower than that of gzip, being
two to five times faster than bzip2.

- In fast mode, compresses faster than bzip2 with a comparable
compression ratio.

- Achieving the best compression ratios takes four to even twelve
times longer than with bzip2. However, this doesn't affect
decompressing speed.
"""

Le seul point faible du lzma est la grande quantité de mémoire vive qu'il utilise lors de la phase de compression (ce qui n'effecte pas la phase de décompression), si 1 ou 2 Go de mémoire vive sont disponible il me semble qu'il peut très bien les utiliser. Au minimum il lui faut 64 Mo de mémoire vive pour compresser, cependant pour décompresser un vieil ordinateur sera suffisant.

ocaml-lzma est donc un binding pour cette bibliothèque. Vous pouvez m'envoyer n'importe quels commentaires au sujet de ce binding, mon email ce trouve dans l'entête des fichiers source.

[bumbolol]

Bonsoir,
je viens de regarder dans camlzip et dans camlbz2 et je n'en trouve pas trace.
Cependant j'ai commencé il y a peu un binding pour la lib lzma et j'avais vu la précence d'une fonction lzma_crc32() dans un des header C de la lib.
Je viens d'ajouter cette fonction au binding, tu peux télécharger les sources avec cette commande :

svn checkout svn://scm.ocamlcore.org/svnroot/ocaml-lzma

Je l'ai testé, j'obtiens le même résultat qu'avec la fonction crc32 de PHP.

Je connaissais pas camlzip (merci du tuyau d'ailleurs), mais comme ca wrappe la zlib, j'étais étonné de ne pas trouver la fonction crc32, du coup j'ai vérifié, elle y est, c'est "camlzip_update_crc32"

[adtunum]

oui camlzip est une lib très ancienne et surtout écrite par Xavier Leroy
si on regarde dans le scm il y a des dates qui remontent à 8 ans.
et effectivement crc32 y est accessible, je croyais pourtant avoir bien fait mon grep mais à cette heure avancée de la soirée je me suis peut-être mélangé les pinceaux

sinon je vois que dans camlzip la fonction a pour type :
update_crc: int32 -> string -> int -> int -> int32

J'imagine que les 2 int définissent une sous-chaîne du buffer string.
dans lzma je n'ai pas mis ces deux paramètres additionnels (donc la chaine considérée est la chaine passée en entier). Tant que je tiens un utilisateur de cette fonction sous la mains, pourrais-tu me dire si tu trouves qu'avoir ces paramètres est intéressant ou pas ?
éventuellement mettre ces paramètres comme optionnel ?

[InOCamlWeTrust]

Et pourquoi ne pas implanter toi-même le CRC, plutôt que polluer le code avec des bindings foireux vers des librairies archaïques et poussiéreuses ?

[adtunum]

Bonsoir InOCamlWeTrust,
Je ne sais pas trop si ton message s'adresse à moi ou à bumbolol (ou peut-être les deux).
Au cas où je serais concerné voici ce que j'aurais à répondre à ton troll :

Mon binding est peut-être foireux, c'est normal je viens de le commencer donc c'est normal qu'il soit en état "alpha", en revanche il ne peut en aucune façon être accusé d'interfacer une bibliothèque "archaïques et poussiéreuses", je t'invite à relire mon poste dans ce fils de discussion où je donne une courte introduction d'lzma. C'est ce que tout le monde devrait vouloir utiliser actuellement. Ce n'est ni archaïques ni poussiéreux, lzma est libre depuis 2 ans je crois et est utilisé dans les distros linux depuis un an environ.

En ce qui concerne camlzip, c'est peut être une bibliothèque "archaïque et poussiéreuse" comme tu dis en revanche ce binding ne peut en aucun cas être qualifié de "foireux" l'auteur de ce binding est Xavier Leroy rien que ça, un des auteur principaux d'Objective Caml. Si c'est le peu de cas que tu fais de ses réalisations, je me demande ce que tu fais sur ce forum. De plus zip/zlib est peut-être ancien mais ce format est encore largement utilisé aujourd'hui, en parler en terme aussi négatif comme tu le fais est très désagréable et inapproprié.

Deplus le terme "foireux" est explicitement péjoratif et familier. Si tu l'utilises pour faire référence à mon travail je te dirais que je l'apprécie assez moyennement. Si tu l'utilises en référence au travail de Xavier Leroy, je ne l'apprécie pas plus.

Si ta critique (ou devrais-je dire troll) porte sur la technique des bindings vers du C, je te ferais remarquer qu'une partie très importante de la bibliothèque standard d'OCaml est réalisée de cette manière. Je t'invite à aller consulter ses sources pour le constater par toi-même. Encore une fois si tu n'aimes pas cela n'utilise pas OCaml et ne viens pas nous importuner.

Bref j'ai beau retourner ta remarque dans tous les sens, je n'y vois rien de positif ou de constructif. Implanter soi-même le CRC en OCaml prendrait un temps indéterminé et demanderait un minimum de compétence, interfacer la fonction C ne prend qu'une ou deux minutes et ne requiert que peu de connaissances techniques.

[bumbolol]

Voici le code correspondant à camlzip_update_crc32, les arguments sont les mêmes que pour crc32, avec en plus un offset pour le début de la string. Donc oui on peut s'en servir, avec len, pour definir une sous-chaîne.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
value camlzip_update_crc32(value crc, value buf, value pos, value len)
{
  return caml_copy_int32(crc32((uint32) Int32_val(crc), &Byte_u(buf, Long_val(pos)), Long_val(len)));
}

Perso non, ca ne m'est pas utile, mais n'étant pas un vieux routard du ocaml, p-e que c'est dans les usages, d'avoir des fonctions manipulant des strings qui fournissent cette possibilité.

[bumbolol]

Et pourquoi ne pas implanter toi-même le CRC, plutôt que polluer le code avec des bindings foireux vers des librairies archaïques et poussiéreuses ?

Parce que là tout de suite, j'ai besoin d'un crc32 pour tester quelque chose dans mon appli, c'est un peu pressé, et je prefere pour l'instant ne pas perdre de temps à reimplémenter qqe chose de present dans une lib.

Maintenant, ca me gonfle effectivement de rajouter une dependance pour une seule fonction de ce gabarit, mais si les tests sont concluant, plus tard elle s'en ira au profit d'une fonction maison.

Mais bon, si tu as un code ocaml tout prêt à proposer pour calculer un crc32, je suis preneur .

[Cacophrene]

Bonjour,

Saupoudrons un peu d'apaisement par ici.

Maintenant, ca me gonfle effectivement de rajouter une dependance pour une seule fonction de ce gabarit, mais si les tests sont concluant, plus tard elle s'en ira au profit d'une fonction maison.

Tout est dit.

Cordialement,
Cacophrène

[InOCamlWeTrust]

Bref j'ai beau retourner ta remarque dans tous les sens, je n'y vois rien de positif ou de constructif. Implanter soi-même le CRC en OCaml prendrait un temps indéterminé et demanderait un minimum de compétence, interfacer la fonction C ne prend qu'une ou deux minutes et ne requiert que peu de connaissances techniques.

Plusieurs remarques

1- prends les temps passés à

poster et répondre sur des forums
+ chercher des libs foireuses
+ les utiliser
-------------------------------------------------
= le temps requis pour comprendre l'algorithme et l'implanter soi-même, démarche plus intéressante, de plus

2- J'ai rien contre Xavier Leroy, mais je ne suis pas de ceux qui ont l'habitude d'élever au rang de demi-dieu des personnes qui ont implanté un compilateur et demi. Sinon, l'Olympe ne serait pas assez grand !

3- Le problème de OCaml, c'est bien qu'il s'agit d'un langage construit au-dessus de C, dans le sens où les fonctionnalités de bas niveau passent, malheureusement, par des routines C non portables, dépendant de l'endianness, du mot machine, de l'OS, de la version du compilateur, du processeur, du préprocesseur du compilateur C... Pour y remédier, il faut s'assurer que les fonctionnalités ont bien été portées proprement soit par les concepteurs du langage, auquel cas il n'y a rien à redire, soit par les gens qui ont fait la librairie en question. Et c'est bien là tout le problème !

4- Une autre source d'emmerdes fréquentes avec OCaml vient du fait que bon nombre de librairies distribuées ne sont pas utilisables pour des applications sérieuses. Des librairies de qualité existent, bien évidemment, mais une myriade composée de portages de qualité bien inférieure également. Ce phénomène n'est pas propre à OCaml, il existe aussi en C, à ceci près qu'en C, étant donné que la communauté est infiniment plus vaste, il existe toujours au moins une implantation sérieuse. En OCaml, lorsqu'il en existe une, c'est déjà pas mal, mais reste la question de sa qualité et de sa durabilité dans le temps...

5- Et c'est ainsi que j'en viens au point 5-, celui de la maintenance et du suivi des librairies. Une nouvelle version d'OCaml sort environ chaque année/année-et-demi, avec son lot de nouveautés et son lot de caractéristiques obsolètes. On se retrouve ainsi beaucoup de fois avec des routines écrites il y a quatre ou cinq ans, qui ne fonctionnent plus avec la dernière version de OCaml. C'était particulièrement vrai lors du passage à la version 3.06, version majeure, qui rendait bon nombre d'applications écrites avec la 3.05 ou les 2.XX non opérantes. Malheureusement, ce n'est pas en rendant le code libre que l'on y remédie, car si il n'y a personne pour maintenir la librairie ou le portage, il/elle mourra inexorablement.

Mon post était censé résumer tout ceci en une phrase, afinde t'épargner cette longue litanie de banalités.

Concernant tes remarques sur le code de la librairie standard, sache que la plupart d'entre nous sur le forum le connaissons, si non par coeur, du moins très bien, tout comme le code et le fonctionnement des compilateurs ocamlc, ocamlopt, ocamlyacc, ocamllex, etc...

Depuis combien de temps utilises-tu OCaml ?

[adtunum]

Bonjour InOCamlWeTrust,

Je ne suis pas fondamentalement en désaccord avec toi sur le fond de ton dernier message (quoiqu'on pourrait discuter sur certains points de détail), mais je suis surtout en désaccord avec le ton péjoratif et insultant de ta première intervention, ce qui explique pourquoi je me suis emporté, ce qui n'aurait pas eut lieu si tu avais fait preuve de courtoisie et de respect.

Je le répète : les termes "foireux", "archaïques" et "poussiéreuses" sont péjoratifs et insultants.
De plus sur le fond comme je l'ai expliqué avec beaucoup de détails ces termes ne peuvent en aucun cas s'appliquer ni à la lib camlzip, ni à la lib ocaml-lzma, dont il était question.