Oui, le code est imbittable, parce que ça n'est pas vraiment du C++, c'est plein de macros qui définissent un nouveau dialecte, et quand on mit le code, ça ne respecte pas la grammaire du langage.
Quelles macros ? Les seules que je tape régulièrement, ce sont qRH, qRB, qRR..., et leurs consœurs qRFwk(), qRGnr()...; qui sont dédiées à la gestion d'erreurs ; algorithmiquement, elles ne sont pas significatives, et elles ne sont pas nécessaires à la compréhension du code, sauf quand celui-ci s'occupe de la gestion des erreurs, évidemment. Quant aux autres macros, elles existent juste pour m'éviter d'avoir à taper du code dont j'ai fréquemment besoin, mais elles ne constituent certainement pas un nouveau dialecte.
Si l'on m'indique quelles macros posent problème, je détaillerais volontiers leurs usages...
Ceci dit, non, ça n'est pas non plus un pur troll, puisque l'auteur du journal semble comprendre sa technologie et même arriver à en vivre. D'ailleurs, dans le journal précédent, certaines discussions techniques semblaient confirmer que plusieurs personnes comprenaient le principe.
Pour moi, c'est de l'informatique abstraite: tu as des trucs qui font des surcouches à une autre techno qui modifie du code dans un autre langage qui va te générer du HTML qu'il va falloir lire avec un navigateur, tu as besoin d'un quadricœur avec 4Go de RAM rien que pour un "Hello Word", mais soi-disant ça accélère le développement. Je ne comprend pas l'utilité d'une telle complexité, mais je dois être dépassé...
Ce n'est de loin pas de l'informatique abstraite : la preuve, il y a une démonstration accessible en ligne qui montre que c'est au contraire tout à fait concret. Quand à cette histoire de surcouche avec HTML, je n'ai pas trop compris. Cela concerne peut-être ce que j'ai décris dans ce journal.
Pour ce qui est d'avoir besoin d'un quadricœur avec 4GO de RAM, il y a un package disponible avec les binaires Windows destinés à du XP SP3 et supérieur, et un autre pour du GNU/Linux compatible IA-32 ou AMD64natif. Ces packages sont relativement simple à déployer (mais je concède que c'est améliorable), et je suis preneur de tout retour sur leur mise en œuvre.
Soit dit en passant, comme je l'ai signalé, la CGI et le backend tournent sans problèmes sur une brique internet, à savoir une architecture ARM 32 bits dual-core à 1 GHz avec 512 Mo de RAM. Pour ceux qui disposent d'un matériel similaire tournant sous GNU/Linux, ils peuvent le vérifier ; je décris la procédure dans le journal. Et enfin, il y a la démonstration en ligne ; là aussi, je suis preneur de tout retour sur les ressources nécessaires et les éventuels problèmes rencontrés en fonction du navigateur utilisé.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: xdhbrwq/xdhbrwq XDHTML/orgnzqxdh
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : l'interface Web. Évalué à 4. Dernière modification le 26 juillet 2016 à 10:17.
Quelles macros ? Les seules que je tape régulièrement, ce sont
qRH, qRB, qRR..., et leurs consœursqRFwk(), qRGnr()...; qui sont dédiées à la gestion d'erreurs ; algorithmiquement, elles ne sont pas significatives, et elles ne sont pas nécessaires à la compréhension du code, sauf quand celui-ci s'occupe de la gestion des erreurs, évidemment. Quant aux autres macros, elles existent juste pour m'éviter d'avoir à taper du code dont j'ai fréquemment besoin, mais elles ne constituent certainement pas un nouveau dialecte.Si l'on m'indique quelles macros posent problème, je détaillerais volontiers leurs usages...
Ce n'est de loin pas de l'informatique abstraite : la preuve, il y a une démonstration accessible en ligne qui montre que c'est au contraire tout à fait concret. Quand à cette histoire de surcouche avec HTML, je n'ai pas trop compris. Cela concerne peut-être ce que j'ai décris dans ce journal.
Pour ce qui est d'avoir besoin d'un quadricœur avec 4GO de RAM, il y a un package disponible avec les binaires Windows destinés à du XP SP3 et supérieur, et un autre pour du GNU/Linux compatible IA-32 ou AMD64 natif. Ces packages sont relativement simple à déployer (mais je concède que c'est améliorable), et je suis preneur de tout retour sur leur mise en œuvre.
Soit dit en passant, comme je l'ai signalé, la CGI et le backend tournent sans problèmes sur une brique internet, à savoir une architecture ARM 32 bits dual-core à 1 GHz avec 512 Mo de RAM. Pour ceux qui disposent d'un matériel similaire tournant sous GNU/Linux, ils peuvent le vérifier ; je décris la procédure dans le journal. Et enfin, il y a la démonstration en ligne ; là aussi, je suis preneur de tout retour sur les ressources nécessaires et les éventuels problèmes rencontrés en fonction du navigateur utilisé.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...