mardi 02 septembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Eet passe en 1.0 alpha

Posté par Steven Le Roux (Jabber id, page perso, ). Modéré le 02 avril 2008.
0
Rasterman, le project leader d'Enlightenment, vient d'annoncer le passage au stade alpha de la bibliothèque Eet.

Cette bibliothèque, faisant partie des EFL[0] est dédiée à l'encodage/décodage et au stockage des données. Elle est écrite afin d'être très simple pour le programmeur, déchargeant une bonne partie des routines de lecture et d'écriture.

Elle peut par exemple stocker de multiples bouts de données dans un ficher unique à accès arbitraire et rapide, encoder ou décoder des images ou tout autre type de donnée. Les fichiers ainsi produits sont compacts et rapides d'accès tout en étant portable entre différentes architectures (exemple : il est possible de produire un fichier écrit sur une architecture 32bits x86 puis de l'utiliser sur une architecture 64bits PowerPC sans autre action que celle de le déplacer).

Eet est portable sur beaucoup d'architectures et de systèmes d'exploitation (actuellement porté sur GNU/Linux, *BSD et même windows grâce au travail de Vincent Torri entres autres) et fonctionne pleinement sur les systèmes embarqués comme sur les fermes de serveur multi core/CPU.

> Lire la suite (47 commentaires, moyenne: 3,7).   [dépêche : 952 caractères]

Au final, Eet est une petite bibliothèque (52Kb sur x86-32, 56Kb sur ARM4) qui soulage le parsage de configuration et gère efficacement aussi bien le stockage que le déplacement des données sans pertes.

Pour finir, Eet n'est pas gourmand en dépendances. Sur les systèmes Unix, mis à part la classique libc et les outils de compilations, ne sont nécessaires que les deux bibliothèques libjpeg et zlib (et leurs version de développement, headers...).

Bien qu'au stade alpha, Eet fait preuve d'une grande stabilité et la version finale 1.0.0 sera publiée lorsque suffisament de monde l'aura compilé, testé, éprouvé. Autrement dit, plus il y aura de poisson, plus vite e17 sortira !

[0] : Les EFL sont les bibliothèques sur lesquelles s'appuie le prochain desktop shell enlightenment : e17. Celles-ci sont d'ores et déjà utilisées par des distributions, ou sociétés : Yellow Dog, Openmoko, Elive, ThinkGos, Englobe, Ebuntu...

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Documentation

Posté par Émilien Tlapale (page perso, ) le 02/04/2008 à 08:42. (lien). Évalué à 9.

Un petit lien vers la documentation [1] histoire qu'on puisse voir à quoi ça peut servir en vrai avec des exemples.

[1] http://docs.enlightenment.org/api/eet/html/

A tester !

Posté par Neije () le 02/04/2008 à 09:22. (lien). Évalué à 3.

Personnellement, j'utilise le plus souvent KDE mais qd j'ai essayé Enlightement il y a qq mois, j'ai vraiment été bluffé par cet environnement. On commençait alors à parler des effets de bureau (3D, transparence ...) mais là j'étais vraiment surpris de voir à quel point c'était en avance sur son temps.

Dommage cependant que les applis tierce (amarok ...) ne soit pas toujours bien utilisables.

Au niveau de l'utilisation des ressources systèmes, je n'ai pas eu d'impressions de lourdeur mais les infos sur le net sont contradictoires : certains affirment qu'il est léger et d'autre qu'il est lourd ... Mais est-ce que l'on compare ce qui est comparable (mêmes applis, même "gadgets" ...)

J'encourage donc à tester, rien que pour la curiosité.

Euh... Première page???

Posté par Zenitram (page perso, ) le 02/04/2008 à 09:39. (lien). Évalué à 7.

Corrigez-moi si je me trompe, mais la on ne parle pas de E17, mais d'une très petite API pour accéder à un fichier de données, de façon très simple.
Genre sqlite, mais en 100x moins puissant (il n'y a aucune gestion de base de données)
Je me demande pour quelle raison un version alpha d'une petit bout d'API a le droit à une "une"?
Le même traitement sera possible pour la version alpha d'une version de Gconf (qui fait bien plus que cette API...)? ou pour tout autre petit bout de projet sur lequel on aura mis le mot "API" pour 4 commandes qui se battent en duel?
Parce que API de ce style, il en sort des dizaines tous les jours (moins documentées, certes...)

[+] systèmes embarqués ??

Posté par rewind () le 02/04/2008 à 10:14. (lien). Évalué à -2.

"les systèmes embarqués comme sur les fermes de serveur multi core/CPU"

on ne doit pas avoir la même définition de Systeme_Embarque

codage/décodage

Posté par Olivier Jeannet () le 02/04/2008 à 13:05. (lien). Évalué à 1.

Simple remarque de français, on dit normalement codage/décodage et coder/décoder, tout comme codec = codeur/décodeur (et non "encodec").
Le "en" que certains mettent devant est un anglicisme (merci de ne pas me sortir tel dico en ligne, ils se trompent aussi ; ce n'est pas parce que c'est sur un site que c'est vrai).

(c'était mes 2 centimes de combat perdu d'avance...)

coquilles ...

Posté par Pol' uX () le 02/04/2008 à 18:54. (lien). Évalué à 3.

> dans un ficher unique à accès aléatoire

Il faut traduire random access par accès arbitraire (i.e. un accès à n'importe quelle donnée, n'importe quand), qui s'oppose à un accès séquentiel, par octets ou blocks d'octets.

> Eet est portable sur beaucoup d'architectures et de systèmes d'expoitation d'exploitation

--
Soutenez le logiciel libre, en adhérant dès maintenant à l'April

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1797s (dont 0.0183 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !