Ramso a écrit 2266 commentaires

1/ Python n'a pas de norme
2/ Python est portable à "99%"
car Python repose sur une implémentation unique et libre et ça remplace le besoin d'un standard.

fauuuuuuuuux !!!

Justement, Python est une norme, son implémentation de référence est CPython mais il en existe d'autres : Jython et Stackless Python à ma connaissance.

et 100% pour Python ? ;)

ok c'est sûrement plus simple avec un langage de haut niveau et relativement jeune.

merciiiiiiii ! je te plussois dès que j'ai à nouveau des votes.

mais comme tu le souligne toi-même, GNU s'impose, donc si je ne veux pas rester bloqué dans le temps, je dois utiliser GNU/FreeBSD ;)

GNU ne deviendrait-il pas un quasi-monopole en matière d'Unix et d'implémentation, surtout si plus personne ne cherche à implémenter le standard ?...

bon j'arrête là sinon ça va partir en troll de petite vertu.

je vais essayer de conclure en me disant que la licence libre de GNU nous protège contre les dérives de ses extensions et de son quasi-monopole, là où dans le cas de microsoft, la licence les rend dangereux.

de toute façon, BSD roulaize, au moins c'est un vrai système ;)

et je sors... pour mieux aller dormir !

merci papy !!

je me coucherai moins con... certes y'a du boulot encore ;)

t'énerve pas !!!

j'ai bien compris que gcc et mes programmes peuvent « coller » aux standards, c'est pas le problème.

mais quand je veux utiliser un logiciel taillé pour gcc, je dois me farcir l'installation de gcc avec parce que mon compilateur ne passe pas. certes c'est un mauvais exemple car gcc est « par défaut » dans freebsd.

Je vois pas pourquoi les specs de gcc devraient être dictées par une norme, ou BSD, ou MS, ou ...

heu... C99, je dirais :)))

je pense plutôt aux options de compilation au nom obscur, genre --fnolinemakecoffeifalignedon64bit que les compilateurs C sur les autres unix n'ont pas.

le fond du problème reste là, microsoft fait des extensions et tout le monde trouve ça mal, même si ce sont de bonnes idées comme tu dis. pourtant, tu te sens obligé de les utiliser ? donc tu reste libre d'une certaine manière.

GNU a aussi ses extensions mais il ne viendrait pas à l'esprit que de les utiliser c'est mal. ça tient à peu de choses :)

les dev de gcc ajoute ce qu'ils veulent et les utilisateurs utilisent ce qu'ils veulent.

s/gcc/microsoft/g

où se situe la limite ?

ok, je me suis emballé et comme t'as pu le remarquer, le petit monde de gcc m'est assez inconnu :)

j'imaginais que gcc avait des subtilités de syntaxe ou des options de compilation qui faisaient qu'en les utilisant, le logiciel ne pouvait plus être compilé avec un autre compilateur.

apparemment, C a déjà assez de problèmes à régler par ailleurs.

la problématique ressortira peut-être plus avec bash et les scripts shell.

il faudrait voir aussi du côté de posix.

merci pour toutes tes réponses

return ogl->terrain->data[x+y*ogl->terrain->width].height;

excuse-moi mais je trouve ça pas vraiment stupide mais en tout cas illisible !

lol, tout à fait dans mon propos, gcc est devenu le « standard » à suivre parce qu'il est le plus répandu. encore ces arguments à la microsoft mais dans un autre contexte.

pour devcpp, je crois qu'il utilise gcc, peut-être avec mingw32 (si j'ai compris ce que c'est).

C'est la technique du "Embrace and extend", mais bon ca a au moins le mérite d'apporter un plus.

alors pourquoi quand microsoft le fait, c'est des méchants mais que GNU c'est des gentils ? ça me paraît plus que limité, voire « télétubbien » comme raisonnement.

ce n'est pas en aucun cas contre toi, je pense que plein de gens auraient répondu ça mais je m'attendais à mieux.

sinon pour gcc, je vois mieux l'aspect des choses mais j'aimerais avoir confirmation que d'utiliser gcc n'est pas un « choix sans retour » à moins de se farcir des milliers de lignes de code et de makefile pour enlever les spécificités.

donc gcc ne semble pas poser trop de problèmes, j'aurais pensé le contraire.

de toute façon, difficile de se faire une idée sur BSD, c'est déjà gcc qu'il faut utiliser.

si d'ailleurs quelqu'un sait quelque chose sur les compilateurs qu'utilisait *BSD avant gcc... ils avaient les leurs ?

Pourtant rien ne t'empêche d'implémenter les extensions de Microsoft sur HTML et CSS, elles ne sont donc pas propriétaires ?

Ha on parlait de C ??? pourquoi ça serait évident ?

Ben d'un côté, return n'est pas une fonction mais une instruction donc pas de parenthèse. De l'autre, il y a un contre-exemple : l'instruction if qui provoque une erreur sans les parenthèses.

Même si on regarde les normes (K&R, ANSI, ISO, machin), il y a la réalité du terrain :-)

Il faut voir ce que ton compilateur accepte et ce que les compilateurs cibles en cas de portabilité acceptent pour leur part.

Au moins avec Python, la syntaxe est claire : pas de parenthèses autour des instructions ;-) ok, j'arrête...

Ben dans le doute, met-les, apparemment y'a des compilateurs qui les réclament mais c'est vrai que c'est embêtant (pour rester poli) de ne pas savoir pourquoi.

bordel, mais y'a autre chose que la GPL dans la vie !!!

leur licence, ZPL, est tout à fait open source et compatible avec la GPL.

Passons... pour ton histoire, ben une appli Zope est derrière un serveur HTTP/FTP/WebDAV/XML-RPC donc déjà y'a de quoi s'amuser :)

Sinon tu peux peut-être ajouter les modules DCOM de Python à Zope (je ne pense pas qu'ils y soient) et écrire des produits ou des scripts qui les utilsent. Je ne m'aventurerai pas plus sur ce point.

Tu ne va pas manipuler la ZODB mais des objets accessibles par les protocoles susnommés en externe et par une programmation objet qui roulaize en interne. Ces objets verront leurs données stockées dans la ZODB de façon transparente pour le programmeur, avec une règle spéciale pour les documents qui seront sur le système de fichiers. Ou alors tout stocker sur le disque...

la ZODB n'est qu'un backend parmi d'autres possibles (stockage dans des SGBDR par exemple) ou alors la ZODB est l'interface et c'est derrière elle qu'il y a les différents backends (fichier Data.fs, SGF, SGBDR), je sais plus.

Sauf que si je fais ta commande magique, il me vire les libs utilisés par les lecteurs « moultimédia » car ces libs ne sont pas essentielles mais étendent les formats supportés par mplayer et compagnie.

Bien comprendre que deborphan ne vire pas les paquets inutiles mais ceux que l'on peut enlever sans qu'un autre paquet s'en plaigne (les paquets en bout de l'arbre des dépendances). Je peux enlever presque toutes les fonts de X11 sinon toutes sans plainte d'un autre paquet mais pourtant aujourd'hui xterm tire la tronche avec ses fonts à la CGA 320x200.

Deborphan montre son intérêt si t'as installé un paquet A qui réclamait aussi les paquets B et C. Finalement t'enlève A mais B et C restent installés. Si aucun autre paquet en dépend, deborphan les détectera.

C'est comme ça que j'ai récupéré au moins 500 Mo sur une Debian de 2 ans aujourd'hui en unstable.

Sinon merci pour auto-apt !

Et au passage apt-proxy roulaize !

heu par contre j'ai eu des merdes en utilisant à la fois les sources de stable, testing et unstable (unstable par défaut je crois)

il foirait pour trouver les bons paquets des fois, mais bon ça venait peut-être d'autre chose.

par contre j'ai gardé ce paragdime :

si testing alors sources de testing et stable
si unstable alors sources de unstable et testing

bref, je garde les versions n et n-1

je ne suis pas non plus sûr que ce soit utile mais j'ai pas envie de tester

pour de la gestion documentaire et des métadonnées, je pense Zope.

Les 21 Go de données peuvent très bien rester sur le disque mais l'indexation et les métadonnées sont sockées dans la ZODB.

avantages :

- framework qui t'évite de réinventer la roue et de pisser du code comme tu dis

- moteur d'indexation et de recherche sans effort avec le ZCatalog

- gestion fine des rôles et des permisssions, indépendantes de celles du système

- sans compter tous les outils pour faire une appli web (page templates, script, ...)

bon les inconvénients, c'est que tu ne veux pas forcément d'une appli web.

Ça change des recettes des cuisiniers pervers qu'on trouve sur usenet !

(j'ai pas de lien sous la main à ce propos)

on r'met ça ? ;)

c'est vrai, tu risque d'entrer dans une école de décideurs pressés ;)))

pas de complétion sous vim ??

et ctrl+n ctrl+p :)

voire dedans, en plein dedans...

mais il a raison, pas la peine de troller, vim éclate n'importe quel éditeur.

d'ailleurs emacs c'est pas un éditeur ;)

ben j'aurais plutôt coupé sur le nombre de lignes pour l'aperçu des journaux, et ensuite vérifié qu'ils ne dépassent pas un certain nombre de caractères comme actuellement

et un bug d'affichage des journaux... oui, je sais bien que ça date de janvier...

Non j'attendais l'occasion... et l'occasion fait le larron !

Diamond m'a tendu la perche et je tiens le bon bout !

Bon, il est temps de sortir là

Bien tenté mais non...

D'une part parce que je reçois la version sans CD :)

D'autre part parce que je l'ai même pas ouvert, donc je pouvais pas le savoir :))

Double Bryçage !!