LupusMic a écrit 1481 commentaires

J'ai été embauchée par une boîte qui édite du logiciel propriétaire, et qui ne s'est pas gênée pour déposer une annonce sur ce site spécialisé dans les annonces d'emplois en relation avec le logiciel libre...

Si tu parles de MS Windows Me, il faut aussi parler de MS Windows Tulipe !

Il est vrai que les plus jeunes ne savent pas qu'emprunter un mail bordé de marronniers est romantique.

Dans la compilation, il n'y a justement pas de langage cible...

Je ne suis absolument pas d'accord sur ta définition d'un compilateur. Un compilateur est un outil qui permet de traduire un code source, intelligible par un humain, en un code objet, directement traitable par une machine. Quelle soit virtuelle ou physique d'ailleurs.

Mais les outils qui traduisent du code d'un langage en un autre ne sont pas des compilateurs. Ce sont des traducteurs.

Gambit-C ne compile pas, il traduit. M'enfin, il y a bien des abrutis qui prétendent compiler avec le compilateur MS Visual Studio...

Je te comprends. Le code est ignoble. Habituellement, j'ai les cheveux hérissés quand je vois du français dans du code (oui, le W-Langage c'est mal ©). Mais alors quand j'ai vu tout ces new et tout ces memcpy, ces appels au destructeur sans raison, les variables globales omniprésentes, sans aucune protection par sémaphore dans une application multi-thread... bref, une version alpha.

J'ai commencé à réécrire toute la partie connexion, pour remplacer le protocole binaire (hmm l'endianess) par un protocole texte. C'est plus lent, mais plus facile à déboguer.

En attendant l'ouverture du google group, je replonge :D

Ça l'est. Dans le monde professionnel c'est intolérable, et lorsque cela touche à la sécurité (plomberie, électricité, etc). Comme le sobriquet de « Bricolo ». Bien sûr, ce n'est pas parce qu'on croit bricoler qu'on réalise un bricolage d'ailleurs : un amateur peut être meilleurs que quelqu'un qui se prétend professionnel.

Ça s'achète où ce genre de processeurs ? Et la carte mère tant qu'à faire. Je n'ai rien trouvé sur Google, ni sur le site du fondeur.

Je me doute qu'il me faudrait quelques siècles de paie pour m'offrir un tel jouet :D

Javascript n'est pas le problème. Ce langage est un langage objet très avancé, qui a plein de qualités.

Non, ce qui pose vraiment problème, c'est l'absence de réflexion derrière Elixir. Les bindings sont bêtes et méchant. Les bindings n'ont rien d'objet, ils sont procéduraux. Ce qui fait que programmer un jeu avec cet environnement ne sera pas agréable. Et puis, utiliser un langage purement objet de manière procédurale, ça va difficilement permettre au projet d'être crédible.

La logique de partitionnement n'est pas la même. Il me semble que ce que les linusciens appellent partitions, les bsdiens les dénomment slices ; des slices contenant des partitions BSD :D

Il faut que tu lises le Handbook FreeBSD qui, de mon souvenir, est très bien fait.

Tu es resté bloqué à MS Windows Me. Les MS Windows de la branche NT sont compatibles POSIX. Donc il y a bien fork.

Les applications développées pour MS Windows étaient massivement multi-thread parce que c'est plus rapide, et parce que la création d'un nouveau processus était trop lent. Et puis, ça permettait de conserver les bonnes habitudes de programmations sous DOS avec ces joies et ces contrariétées ;)

La contre-façon va évidemment baisser dans un premier temps, mais suivra le même chemin que les radars automatiques.

En quoi un formulaire de connexion n'est pas une donnée tabulaire. Pour moi c'en est. Une liste de couple nom/valeur.

C'est vrai que c'est pratique de regarder une carte en marchant. Et puis la précision doit être terrible : personne ne marche droit devant lui. Surtout dans une grotte.

Et non thunfish ! C'est dit.

J'ai du mal à participer aux projets que je ne considère pas pertinents, voir dégueulasses (une regex pour parser du XML, c'est dégueulasse quand on a à disposition un parseur efficace).

Et pourquoi ne pas avoir corrigé le bogue directement dans PHP ? :D

Je ne trouve pas le templating à coup de str_replace (ou même de preg_replace) une méthode de travail satisfaisante. Certes ça peut dépanner, ça permet de faire rapidement ce qui, proprement, aurait nécessité plus de temps.

Quand à l'humilité... ce donner de la consistance avec des certification, ce n'est pas humble.

J'ai un peu fouillé, et très franchement, je ne vois pas ce qu'il y a de compliquer à gérer les ODT : tous les outils nécessaires sont disponibles dans PHP. Avec DOMDocument et XSLT, on peut arriver à une solution plus que satisfaisante. Et puis le XML, si c'est lourd, c'est pas compliqué.

Merci de m'avoir énervé. Du coup, je pense que je vais continuer et écrire un outil de manipulation de ces fameux ODT. (continuer parce que du coup, j'ai écrit un outil équivalent à ce que vous avez fait pour voir combien de temps ça me prendrait)


Tu veux qu'on parle du utf8_encode qui encode une chaîne soumise sans même vérifier l'encodage de la chaîne ? ;)

Si tu relis bien ma remarque sur sed, tu verras bien que je n'ai pas écris que j'allais invoquer sed, mais qu'en gros, ça ne faisait rien de plus (et même moins) qu'un sed.

Quand à un exec avec sed... très franchement... on peut facilement gérer et sécuriser un tel appel. il suffit de faire attention.

Pour tout ceux qui essayent de tester, faites attention, il y a un bogue avec certaines versions récentes de PHP qui empêche OOo d'ouvrir les fichiers Zip créés par ZipArchive : http://bugs.php.net/bug.php?id=48763

Heureusement que c'est l'été, sinon je ne crois pas que cette news serait passée.

Une news pour un 423 lignes de PHP, qui ont certes leur utilité, mais pas celle qu'on croit deviner en lisant l'article. Cette classe permet de faire du templating sur des fichiers ODT, mais elle ne permet absolument pas de les manipuler.

Très franchement, être quatre sur ça, et prétendre avoir réaliser un outil révolutionnaire, c'est du foutage de gueule.

À la rigueur, un DOM qui permet de manipuler un ODT en long en large et en travers, pourquoi pas. Mais là... C'est juste un sed en moins bien.

Ah ben en fait j'avais mal compris à l'époque : http://gcc.gnu.org/gcc-3.2/c++-abi.html

Il y a donc un effort de standardisation entre les différents compilateurs, sans avoir de norme établie. Cela me rend perplexe quand au fonctionnement de programmes compilés avec gcc sous MS Windows, utilisant des bibliothèques compilées avec le compilateur C++ de Microsoft. Il doit bien y avoir une compatibilité binaire.

Je ne suis pas un guru de la programmation, mais je pense pouvoir te fournir quelques remarques qui te permettrons d'améliorer ton langage.

Pour l'ensemble de mes remarques, je vais suivre et commenter le ninja language reference http://ooc-lang.org/doc/langref/book1.htm (tu devrais rajouter dans la FAQ pourquoi c'est une référence Ninja).

http://ooc-lang.org/doc/langref/c31.htm
« All types should be in CamelCase, all variables and functions in camelCase. [...] The justification for that is consistency. »

Je ne vois pas en quoi le nomage des « types » en Java est incohérent. Les POD ont une minuscule parce qu'ils ne sont pas des objets. Si ton système est cohérent, alors on peut dériver depuis un Int. Dans le cas contraîre, c'est OOC qui est incohérent et non Java. À noter qu'ici Java est cohérent, raison de l'existence des classes Integer, Float, etc.

Quand au C++, la tradition est de ne jamais utiliser de majuscules. Que ce soit pour les noms de classe ou des fonctions. Seules exeptions, les noms de constantes ou les nom des paramètres de templates. Par exemple : void std::map<template T>::push(T &) ;

« You can declare several variables on the same line »
Mauvaise habitude. En plus tu montre que tu ne sais pas que le type pointeur n'existe pas en C/C++ (c'est un qualificatif).

« Correspondance with C and Java types »
En Java, je crois bien qu'on peu utiliser le mot-clé « self » dans la liste des paramètres et le type de retour des fonctions membre. En C++, je déclare souvent typedef Myclass self.

Je ne comprends pas cette prolifération de types numérique. Pourquoi ne pas proposer un type générique qui gère les opérations sur les nombres avec une précision arbitraire ? Ça permettrait de totalement abstraire l'usage des nombres, ce qui manque avec C++ et Java (il faut toujours faire attention aux limites, ce qui est rarement testé correctement, voir ignoré le plus souvent).

Le nom Octet est franchement maladroit, quant on sait qu'un byte ne fait pas forcément un octet. D'ailleurs, quelle est la taille de tes int (parce qu'en C, c'est dépendant de l'architecture, tout comme char) ?

« printf("A moins que vous n'epousiez la %s?\n", name); »
Pourquoi pas :
console.print "A moins que vous n'epousiez la %s?\n".format name ;

Je n'arrive pas à entrevoir l'intérêt des Covers sur la dérivation de la classe.

http://ooc-lang.org/doc/langref/x209.htm
Une critique qu'on peut faire au C++, c'est d'avoir conserver les tableaux à la mode C. Pourquoi faire la même erreur ? L'encapsulation des tableaux permet d'éviter la duplication des tests de contrôle, et surtout t'éviter tout problème de sécurité relatif au débordement de tampon (et de centraliser la correction d'un éventuel bogue). Ton langage impose déjà plusieurs paradigme : tu devrais aller au bout de ton idée. Sinon, autant faire du C ou du C++.

« A function is declared with the func keyword. »
Pourquoi un mot-clé ?

« func add(Int arg1, Int arg2) -> Int { } »
Argh... Je n'ai jamais compris cette logique que de noyer le type de retour après la list de paramètres (Pascal, Basic, etc).

« The main function: entry point »
Mais pourquoi une fonction ? :D

« SDL_Quit(); // We must use parenthesis, cause it's a C function »
On pourrait te reprocher une certaine incohérence à ce niveau là. Mais je comprends la limitation technique.

« Instanciation »
Je ne comprends pas l'intérêt du mot-clé new. En plus, de ce que j'en comprends, tes types ne sont jamais créé sur la pile ? Dans ce cas, tu devrais reprendre ton benchmark sur l'instantiation, et faire la création sur la pile. Tu verras que la différence de performances est... non-négligeable (l'instantiation sur la pile est 7× plus rapide que dans le tas, chez moi).

Un objet peut-il être utilisé comme un functor ?

Les objets sont polymorphiques ?

Quelle est la portée par défaut des membres d'une classe ? Public ? N'est-ce pas là une violation du principe d'encapsulation ?

« for in ranges »
C'est pratique, indubitablement. Une bonne idée serait de rajouter un type Range. Pour éviter de déclarer des ensemble en dur dans les boucles. En embarquant le pas dans le Range, évidemment.

Tu aurais pu virer switch ;)

Pas de do..while ?

« The package of a source unit is relative to the sourcepath. »
Je ne penses pas que ce soit une bonne idée. Pour tout un tas de raisons, allant de la relativité du chemin au caractère dur du chemin. Bien que le mot-clé super permette de contourner partiellement ce défaut.

Voilà pour mes quelques remarques. J'espère que ça t'aidera dans ta réflexion.

C++ a une ABI normalisée. Mais les implémentations ne la respectent pas forcément. Par exemple, GCC a migré son ABI propriétaire vers l'ABI normalisée entre 2.9 et 3.0 si mes souvenirs sont bons.

Mais je ne vois pas le problème d'avoir un main dans un .c et d'utiliser une API C++. Il y a des méthodes qui permettent de facilement jongler entre les différentes unités de compilation.

Je n'ai pas le niveau, j'en ai conscience. Mais certains ont dû le faire : http://blog.pavlov.net/2007/11/10/memory-fragmentation/

new est un opérateur comme les autres, tu peux le surchargé. Et c'est ce qui est fait dans l'implémentation de base me semble-t-il. Donc à un moment donné, tu peux toujours réécrire la spécialisation de new. Du coup, ça ne se mort pas la queue.

Faut que je fouille pour comprendre le mécanisme exact de ce qui se passe.