Discussion :

[eclesia]

Je ne sais pas comment dire ca, mais ca devient jouissif , c'est gros, très gros ce qui se passe avec ce projet. J'irai même jusqu'à penser que ca va créer un petit raz-de-marée dans le mondes des librairies java et aussi DotNet si on arrive a faire notre propre VM.

bon aller, voila la récolte :
- HashDictionnary : nouvelle implémentation beaucoup plus efficace
- OpenGL : ajout des lumières projectives
- 2D,3D : rapprochement des API entre la 2D et la 3D
- 2D : amélioration de l'API et du scénographe 2D
- URL : method utilitaire pour décoder les URL %20 etc..
- Code : début d'API pour le CODE, première base pour conversion du code entre language
- Code : tout début de machine virtuelle (en java)
- Unity : le décodage marche pout les bundles et les fichiers assets !
- Blender : support des paramètres de texture : offset,scale,clip
- OpenGL : amélioration des performances part réduction des données transmises entre les shaders
- OpenGL : amélioration du rendue des silhouettes
- OpenGL : nouvelle phase permettant la correction gamma de l'image
- Widget : gestion des focus fonctionnelle
- Widget : le WTextField a maintenant un 'caret' pour controler l'endroit où on écrit
- Widget : draft de l'api d'effet visuel (flou,ombre,...etc...)
- Widget : grosse, grosse réduction de l'utilisation du cpu
- XSD : reader et classes complète pour le modèle xsd
- Physic : début d'intégrateur avec l'algorithm verlet (Verlet integration)
- NTFS : début de décodeur du système de fichier NTFS, boot sector et master file table
- Image : nouvel opérateur de découpe d'image


Bon j'y retourne, bientot la v.1.0

[eclesia]

Avec la chaleur c'est plus dure de se motiver, enfin bref :

- Unity : divers correction, possibilité d'écriture partielle
- Code : API pour le code, class, fonction, parametres, doc, transcoder, formatter, etc...
- Geometry,Image,OpenGL : nouvelle API TupleBuffer commune
- Image : amélioration de l'api, plus simple d'utilisation et beaucoup plus extensible.
- Image : nouvel opérateur d'image : différence de valeur
- Image : draft opérateur d'image : contour
- DDS : support des textures AT1,ATI2, compression BC4 et BC5
- DDS : début de support des textures DirectX 10 et 11
- Buffer : nouvelle API pour la gestion, le parcours et la creation des Buffer.
- Regex : ajout de la function 'search and replace'
- Java : conversion de l'AST vers l'api de Code
- Blender : amélioration de performance de décodage
- Collection : ajout d'un BacktrackIterator
- SPIR-V : amélioration du modèle de classe pour les opérateurs
- UI : draft d'API de clipboard et drag&drop
- XML : draft XPath
- URL : correction sur le 'percent encoding' pour les characteres UTF-8 sur plusieurs octets


Et j'ai terminé la dernière tache fixée pour la version 1.0 .
Les débuts de l'outils de documentation de code
Voici les premiers résultats : http://unlicense.developpez.com/doc_new
Ca ne vaut pas encore JavaDoc ou Doxygen, mais toutes les informations sont présentes, c'est leur mise en forme html qui n'est pas encore au point.
Bien sur l'outil Unlicense-Doctool n'utilise que la librairie Unlicense-lib et rien d'autre. Il est aussi concu pour supporter d'autres languages.

Voila, bonne vacances.

[Kannagi]

Bravo pour le travail accompli

Avec la chaleur c'est plus dure de se motiver, enfin bref :

Je suis tout a fait d'accord , enfin moi j'ai le même probleme quand il fait trop froid

Bonne continuation

[eclesia]

Premiere release officielle disponible.


version : 2015-08-02
Repository maven :

Code :

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

1
2
3
4
5
6
 
<repository>
    <id>unlicense-lib</id>
    <name>Unlicense-Library</name>
    <url>http://unlicense.developpez.com/mvn/repo/</url>
</repository>

[eclesia]

Bon, ca fait un petit moment que je n'ai pas fait de mise a jour, alors voila :

- C : amelioration du parseur de preprocesseur C/C++
- Layout : nouveau layout : PairLayout pour les positionnements 2 à 2
- Layout : simplification et nette amélioration des performances
- Swing : draft de pont avec l'api java swing/awt afin de pouvoir utiliser les widgets dans les fenetres java standard sans jogamp
- Rasterizer : rendue avec antialiazing possible en pure cpu.
- Rasterizer : amélioration du rendue des polices, (grid fitting)
- Property : nouvelle api de synchronisation de propriété
- Unity : beaucoup de corrections, debut d'ecriture, debut de decodage des textures,mesh,joint,material
- Math : utilitaire de creation de transformation classique, center, scaled, stretch,...
- Math : utilitaire de creation d'interpolation classique, lineaire, cubic, quadric, sinusoidale, exp.,
- Animation : nouvelle API dédiée aux animations, avec KeyFrame, TimeSerie, Interpolator, ...
- Widget : grosses améliorations pour les composants en lignes, table, treetable, liste, ... (voir screenshot)
- Widget : simplification de la syntaxe pseudo-css
- Collection : implémentation de HashSet
- Collection : des collections optimisées pour les types primitifs
- KTX : decodeur d'image KTX
- Tests : beaucoup de test unitaire en plus un peu partout


Et aussi des GROS ajouts avec :

- Elliptic Curve Cryptography : on remercie George Barwood, Paulo S.L.M. Barreto et Stuart D. Gathman pour avoir placé ce travail dans le domaine public.
http://bmsi.com/java/#EC

- Diff engine : les bases pour un outil de diff comme en utilise svn,hg,git,bazar,.... on remercie Michael Potter
http://www.codeproject.com/Articles/...orithm-in-C-II


et voici a quoi ressemble les widgets WTable et WTreeTable, JavaFX n'a qu'a bien se tenir !

[maeiky]

- C : amelioration du parseur de preprocesseur C/C++

Peux-tu expliquer un peu ce point, je pensais que le projet était en Java, on peut parser du C++? Dans quel but?

Diff engine est en C#, tu compte le traduire?

[eclesia]

Peux-tu expliquer un peu ce point, je pensais que le projet était en Java, on peut parser du C++? Dans quel but?
Diff engine est en C#, tu compte le traduire?

> Parseur C/C++ : le projet est bien en Java. Rien ne m'interdit d'avoir la capacité de lire du code C non ? par exemple pour faire de la coloration syntaxique ou encore pour convertir du C vers du Java ou autres, GLSL, python, ruby, ... voir meme executer du code C dans une VM ou compiler des dll, ca viendra, juste une question de temps.
C'est une librairie qui n'a pas de but particulier donc tout est bon .

> DiffEngine : oui je l'ai traduit en Java.

[maeiky]

> Parseur C/C++ : le projet est bien en Java. Rien ne m'interdit d'avoir la capacité de lire du code C non ? par exemple pour faire de la coloration syntaxique ou encore pour convertir du C vers du Java ou autres, GLSL, python, ruby, ... voir meme executer du code C dans une VM ou compiler des dll, ca viendra, juste une question de temps.
C'est une librairie qui n'a pas de but particulier donc tout est bon .

> DiffEngine : oui je l'ai traduit en Java.

J'admire tes talents de traducteur. Qu'est-ce qui ta fait choisir le Java ?

Un parseur pour convertir du C vers Java & autre? Même si tu y arrive, chaque langage à ces particularités, ça ne sera jamais parfaitement convertie et/ou parser. En même temps quel en serait l'utilité? Même si tu inventerais ton propre langage, parser à la perfection, juste l'idée d'exécuté le code à la volé serait un travail de titan.
Compiler du C vers une dll? Tu veux dire faire un IDE en java pour le C. Quel serait l'avantage par rapport à un IDE natif?

Quand est-il de la maintenabilité? Tu traduis des codes, mais l'auteur peut très bien l'améliorer et faire des ajouts par après?

[eclesia]

J'admire tes talents de traducteur. Qu'est-ce qui ta fait choisir le Java ?

De C# a Java il n'y a qu'un pas.
Pourquoi Java ? parceque c'est le language que je connais le mieux, et je me limite volontairement, pas de generic, pas de lambda, pas d'annotations. bref c'est du bonne objet sans paillette donc tout le monde est capable de le comprendre.

Un parseur pour convertir du C vers Java & autre? Même si tu y arrive, chaque langage à ces particularités, ça ne sera jamais parfaitement convertie et/ou parser. En même temps quel en serait l'utilité? Même si tu inventerais ton propre langage, parser à la perfection, juste l'idée d'exécuté le code à la volé serait un travail de titan.
Compiler du C vers une dll? Tu veux dire faire un IDE en java pour le C. Quel serait l'avantage par rapport à un IDE natif?

Quand est-il de la maintenabilité? Tu traduis des codes, mais l'auteur peut très bien l'améliorer et faire des ajouts par après?

Il faut voir plus loin, les languages il y en a de plus en plus, les librairies aussi.
Mais dans le domaine public, se sont des projets 'morts' pour 95% d'entre eux, l'évolution se passe ici désormais, je n'ai fait qu'empecher leur disparition et leur donner un second souffle.

Ce n'est pas un travail de titan, c'est juste qu'on vous a enfoncé dans le crane que 'réécrire la roue c'est mal'. Bêtise que cela c'est tres formateur et on n'est plus dépendant.

Assez parlé, le language du developpeur c'est le code pas le francais

[MoDDiB]

J'adore le projet, c'est vraiment un excellent boulot.
Maintenant j'ai l'impression que des tutos explicatifs complets sur les algos mis en oeuvre ce serait encore bien plus bénéfique.

"Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours."

Dans tous les cas je reste admiratif et j'espère en avoir besoin un jour !

[eclesia]

Un petit mois de travail en plus :
- 7Z : draft de decodeur d'archive 7z
- Unity : amelioration du decodage des assets version 5+
- Animation : separation des differents composants d'une animation de modele, scale, translate, rotation pour avoir un controle tres fin sur les timeseries.
- Path : resolution de chemin relatif
- Widget : DesktopFrame et InternalFrame hérite désormais la meme interface Frame
- Widget : colonnes redimensionnable pour Table et TreeTable
- JOGL : mise a jour vers la version 2.3.2
- MarkDown : amelioration de la syntaxe
- M3U : decodeur de fichier de playlist multimédia m3u
- Layout : BorderLayout et PairLayout respectent désormais les min/max extent des widgets
- WGraphicImage : possibilité de controler le mode de mise a l'echelle de l'image : scaled,centered,zoomed et stretched
- Jpeg : amélioration du temps de décodage
- DXT : amélioration du temps de décodage
- Image : BitPackColorModel et BitPackRawModel supportent les samples de taille variables : 1 à 32bits


Et les remerciements vont à Thomas Mueller et Doug Whiting pour le code de l'algorithme de Hash Skein-512 placé dans le domaine publique :
http://www.h2database.com/skein


voila, voila, ca avance petit à petit, on finira bien par tout réécrire. mais surtout ne vous bousculez pas pour venir apporter une pierre à l'édifice.

[eclesia]

Je n'ai pas écrit beaucoup de code ces deux dernier mois,
heureusement quelqu'un est venu aider cette fois encore

- Node,Parameter,Doc : rapprochement de ces 3 apis, interface communes.
- Image : ajout des espaces de couleurs CMY et CMYK
- Widget : meilleur synchronization entre les evenements souris/clavier et le rendue
- Widget : nouveau widget WSeparator
- Widget : draft widget WCrumbBar
- Lexer : ajout d'un indicateur de fin de flux, exceptions plus précises et ajout de l'information de la position des tokens dans le flux.
- OpenGL : ajout des classes utilitaire Shader et ShaderProgram
- Base85 : support de l'encodage base85/ascii85/Z85
- Postscript : amélioration du reader
- Postscript : début de machine virtuelle (voir snapshot)
- AVI : draft de writer
- RIFF : draft de writer
- RAS : draft reader d'image sun raster


Et cette fois les remerciements vont à Francois Berder , développeur du projet Crypto (https://developer.mbed.org/users/feb11/code/Crypto/) qui a contribué à la partie crypto avec :
- SHA-224
- SHA-256
- SHA-384
- SHA-512
- MD2
- MD4
- RC4


Et voici un apercu de ce que produit la machine virtuelle postscript :

[P.i.e.r.r.e.]

Euh... N'étant pas programmeur, je comprends pas vraiment tout le travail que tu présentes mis à part son intitulé mais devant tant d'efforts pour un but aussi cool, je laisse un petit message d'encouragement par ce que je sais que ça fait toujours plaisir

Chapeau bas!

[eclesia]

Euh... N'étant pas programmeur, je comprends pas vraiment tout le travail que tu présentes mis à part son intitulé mais devant tant d'efforts pour un but aussi cool, je laisse un petit message d'encouragement par ce que je sais que ça fait toujours plaisir

Chapeau bas!

Merci ca fait toujours plaisir comme tu dis, meme un graphiste peut etre utile au projet, par exemple faire un fichier TTF (avec birdfont ou fontforge) avec des icones de base, comme fontawesome.


J'en profite pour annoncer un nouveau palier atteint après maintenant 3 ans d'efforts :
300.000 le nombre de lignes de codes (hors commentaires et lignes vides)
50 le nombre de developpeurs ayant contribués directement ou indirectement.

[dourouc05]

300.000 le nombre de lignes de codes (hors commentaires et lignes vides)
50 le nombre de developpeurs ayant contribués directement ou indirectement.

!

[P.i.e.r.r.e.]

meme un graphiste peut être utile au projet, par exemple faire un fichier TTF (avec birdfont ou fontforge) avec des icones de base

ok je t'envoies un MP

EDIT : Ah oui, non en fait... "eclesia a dépassé son quota de messages privés"

[eclesia]

ok je t'envoies un MP

EDIT : Ah oui, non en fait... "eclesia a dépassé son quota de messages privés"

Désolé pour ca, je viens de faire du vide.

[eclesia]

Ca avance, ca avance :
- Math : algorithme MedianCut (https://en.wikipedia.org/wiki/Median_cut)
- Math : algorithme K-Means (https://en.wikipedia.org/wiki/K-means_clustering)
- Image : operateur de création de palette de couleur réduite pour une image
- Image : operateur de création d'image de distance (signed distance-field)
- OpenGL : refonte du modèle de scene afin de pour implémenter ses propres 'Renderer' ce qui permet bien plus de personalisation des rendues.
- ANI : draft de lecteur de curseur animé (.ani)
- SWF : ajout du decodage des geometries
- TGA : support des images en niveau de gris et avec palette de couleurs
- GIF : début d'encodeur
- XNB : draft decodeur (juste l'entete du fichier pour le moment)
- Telnet : draft de client telnet



Plusieurs contributeurs cette fois encore :

Francois Berder a encore frappé avec :
- RSA : algorithme d'encryption

Samuel Andrés :
- Time : nombreuses classes traitant les calendriers : Julian, Gregorian, Petrinian, Romaic

Et plusieurs contributions indirectes :

Remerciements à Jankovics Andras pour sont algorithme de vectorisation d'image :
- ImageTrace (https://github.com/jankovicsandras/imagetracerjava)
- Geometry : algorithme de simplification de géométrie

Remerciements à Spoon! du project literateprograms
- Image : algorithme FloydSteinberg dither (https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering)

Remerciements à Nasca Octavian Paul pour son synthétiseur audio simple et efficace.
- Audio, synthetizer padsynth (http://zynaddsubfx.sourceforge.net/d...h/PADsynth.htm)

Remerciements à Stefan Gustavson http://contourtextures.wikidot.com :
- OpenGL : support des textures de type DistanceField (voir snapshot)


Dans un tout autre domaine, remerciements à p.i.e.r.r.e
qui a posé la première pierre d'une police graphique, dont voici le résultat :




Distance Field, texture classique vs distance :

[eclesia]

Pour le plaisir des yeux, les widgets ont subit un lifting durant les dernieres semaines.
Le toolkit s'approche de la qualité pro :

[eclesia]

Aller un petit compte rendu :
- Widget : nouveau composant WGLCanvas qui permet d'avoir un encart OpenGL à l'intérieur des widgets.
- Widget : encore des améliorations niveau perf, usage mémoire, rapidité, (ca peut tourner sur 32Mo de ram)
- Layout : nouveau LineLayout qui permet les retour à la ligne adapté à la largeur (c'est le type de layout qu'utilise un document odf)
- Layout : amélioration de la gestion des tailles en fonction des min/best/max extent des widgets.
- IO : beaucoup de nouvelles méthodes de lecture sur DataInputStream pour simplifier encore le décodage
- IO : amélioration des performances du HashInputStream
- Math : diverses amélioration de performances sur les matrices.
- OpenGL : nouvelle interface graphique de debuggage permettant de voir le contenue des différentes textures et les temps d'éxécutions.
- TDCG : draft de decodeur TSO/TMO/PNG
- Icons : une quinzaine de nouvelles glyphs graphique disponible dans la police Unicon.
- Image : nouveau modèle de couleur BandTransformColorModel permettant d'afficher les intervalles arbitraire (exemple : [-1,+1] vers [0,255])
- Animation,Media : meilleur timing du rendu des images des videos.


Remerciement à Haruhiko Okumura et Shawn Hargreaves pour le code de compression et décompression LZSS.


-----------------------------------------------------------------------------------------------
Je me permet un petit coup de gueule afin que tous soit au courant que même dans les grandes sociétés, l'incompétence, la vrai, grossière et honteuse existe :

- Google et VP8 : avoir de l'argent n'aide pas a avoir la qualité, la spécification est une M.... pleine d'erreurs et de phrases incohérentes. C'est ma troisième tentative afin de décoder du VP8 et du VP8L. Et je n'ai toujours pas réussi, je ne me considère pas comme mauvais ni sans expérience pourtant. Une perte de temps d'autant qu'aucun dev ne répond sur leur liste.

- Lucasfilm et OpenEXR : ce format n'a d'ouvert que le nom, c'est en fait un format propriétaire dont les sources d'outils internes (IlmImf) ont été placé en open-source, ajouté à cela l'aide d'un ou deux stagiaires pour tenter de pondre un document servant de spécification. De qui se moque-t-on quand en plein milieu du document il y a écrit : "If this document and the IlmImf library disagree,then the library takes precedence" ou encore "For information on the compressed data formats, see the source code for the
IlmImf library" (traduction : "Si la documentation et la librairie IlmImf sont en désaccord alors IlmImf est la référence", "Pour les informations sur les formats de compression voir le code source de IlmImf").

Mon constat est clair, voici deux sociétés qui font semblant de surfer sur la vague de l'open-source, prenant plaisir à mettre autant de baton dans les roues que possible aux développeurs. Profitant de leur position privilégié pour pousser des formats médiocre sans réel discussion ou échange avec quiconque. OpenEXR heureusement n'a pas connu un succes, malheureusement vp8 et ses petits webm et webp se sont répendues principalement grace au web. Je ne peux que vous encourager à boycotter ceux ci afin d'assainir le web et d'éviter ces poisons.

-----------------------------------------------------------------------------------------------

Retour à la joie et la bonne humeur, voici deux projets basé sur Unlicense-Lib qui font leurs premiers pas :

Un-Explorer, l'objectif est de remplacer les outils comme nautilus,thunar,media-player,irfanview :



Un-WidgetEditor, l'objectif est de réaliser un éditeur WYSIWYG pour les widgets :