kdewin foutage de geule - Page 9

squalyl (./233) :
[échec] provoqué par qui?

Ça dépend du cas. Ici, il est clair qui je retiens responsable (cf. mes posts précédents), mais je ne suis évidemment pas objectif.

on ne peut pas contribuer efficacement en utilisant CVS quand on n'est plus d'un seul développeur; il y a trop de risques.

Quels risques? Si tu sais utiliser CVS, tu ne risques absolument rien!

Vu comment tu refuses les contributions qui te paraissent inutiles

Si ce n'était que ça, je ne les refuserais pas, mais les contributions que je refuse dégraderaient la qualité de TIGCC si je les mergeais, cf. les exemples fournis, avec les raisons du refus (./221 et ./239).

ok.

Kevin Kofler (./240) :
on les a déjà en _nostub avec code de démarrage d'ailleurs

nostub or not nostub?

Kevin Kofler (./242) :
Si tu sais utiliser CVS, tu ne risques absolument rien!

Tu fais comment? Tu passes un coup de fil à tes comitters pour leur dire "touchez plus rien, je comitte, attendez que ce soit fini pour lancer le votre!"

squalyl (./242) :
Tu fais comment? Tu passes un coup de fil à tes comitters pour leur dire "touchez plus rien, je comitte, attendez que ce soit fini pour lancer le votre!"

Bah non, tu committes, et si tu as un conflit, tu le résous. Tu peux te retrouver en conflit sur certains fichiers et pas d'autres, mais dans la plupart des cas c'est détecté par le pre-commit check (et donc il ne committe rien avant que tu n'aies fait un cvs update et résolu tes conflits), et si vraiment les commits tombent pile en même temps, tu résous le conflit juste après et c'est bon (et c'est toujours un des 2 développeurs en conflit qui a la priorité, donc la résolution des conflits ne crée pas de nouveaux conflits, sauf dans des cas extrèmes et très improbables comme le conflit à 3).

Maintenant, si on ne sait pas résoudre un conflit, on a effectivement un problème, mais j'inclus ça dans "ne sait pas utiliser CVS".

Beaucoup de mes contributions à la doc sont _antérieures_ à l'inclusion des cross-references. J'ai passé des journées à intégrer à la main les cross-references... juste pour me rendre compte, _une fois fini_, que ça ne fonctionnait pas, parce que les cross-references cassent quand on veut bouger un fichier.

Tu avais répondu que tu avais fait à ton avis assez de travail là-dessus et que c'était as is.

J'ai dû écrire ça au moins une fois, en effet, parce que ça faisait trop ch*** de refaire le boulot... mais raconte l'histoire en entier, STP
Tu omets de mentionner que j'ai, par la suite, _essayé_ de corriger mes patches. J'avais _commencé_ (une partie du squelette, mais pas vraiment le contenu) à écrire (en C, je ne parlais rien d'autre à l'époque), un programme qui corrigeait les cross-references en mettant des chemins complets (headername.h/membername) pour toutes les cross-references. Parce que c'est bien cette absence de chemins complets entre membres du même header, la plus grosse source de casse pour les cross-references. Cette absence empêchait (et empêche toujours) de faire dans les .hsf et .hsh un simple s@unknown.h/membername@leheaderquivabien.h/membername@g .


Fast forward 3 up to 5 years:
* je maîtrise suffisamment Perl (appris en-dehors de la fac, d'ailleurs, malheureusement...) pour faire, avec plus de facilité d'écriture qu'en Delphi ou C++, et en profitant de la profondeur de CPAN (plusieurs modules qui parcourent une arborescence de fichiers déjà tout prêts), un outil qui sait mettre des chemins complets partout. Et je suis en train de le faire: le code est presque terminé (avec quelques étapes intermédiaires pour vérifier ce que je faisais) - et il reste le test, bien sûr.
* j'ai compris l'intérêt de splitter les patches, et je le fais dans mon boulot aussi, de manière à faciliter les bisections avec Git.

Tiens, au fait, une question que tu n'as pas posée, et à laquelle je vais répondre: puisque c'est moi qui veux tant que ça ce fork (c'est moi que tu vises dans tes messages)...

Je te vise parce que je ne sais pas qui d'autre participe, tu as refusé de le révéler.

-tu ne sais pas +tu n'as pas réfléchi.
Non seulement plusieurs ont posté dans ce topic, mais il y en a au moins un qui devrait t'être évident, avec ce que j'ai écrit dans ./227...

tout récemment, la mention de la possibilité de suppression d'A68k, sans avoir ajouté un mode de compatibilité avec la syntaxe A68k à gas. Obstacle à la création d'un OS _libre_ pour TI-68k.

Un logiciel n'est vraiment libre que s'il est compilable avec des outils libres, cf. http://www.gnu.org/philosophy/java-trap.html (l'exemple n'est plus d'actualité, le problème l'est). PedroM doit être porté vers GNU as (enfin, il aurait dû être codé avec GNU as dès le départ, mais le mal a été fait, maintenant il faut y remédier, c'est-à-dire porter). Si PpHd continue à refuser de le faire, je vais finir par le faire.

Je pense qu'il serait malin d'ajouter un mode de compatibilité avec la syntaxe classique Motorola à GNU as.

(à propos de PpHd) Et je n'ai jamais vu de documentation au format correct non plus. (Il m'a envoyé un stdint.h à un moment, mais c'était un header seul qui n'utilisait pas du tout le générateur de headers et documentation fait pour et qui par conséquent n'avait aucune documentation. Inutile de dire que ce patch n'a pas été mergé (et je le lui ai expliqué, il a répondu que ce serait trop de travail et exigé que je prenne le header tel quel, ce que j'ai évidemment refusé). Tout identifiant (fonction, variable, type, macro) dans TIGCCLIB doit avoir un fichier .hsf correspondant, sauf si l'identifiant est totalement interne et pas prévu pour être utilisé directement. De même, toute option de ld-tigcc doit être documentée dans les fichiers .hss de ld-tigcc (mais dans ce cas c'est un seul fichier pour tous les arguments).)

Tiens, stdint.h / inttypes.h... Je les avais oubliés, ceux-là.

persistance du refus d'intégrer tout ou partie des features de PreOS/PedroM dans TIGCC ( topics/112598-export-de-version ), alors que PreOS est le kernel devenu standard depuis 'juste' quatre ou cinq ans. Même si le mode de programmation kernel-based a objectivement des défauts, il a objectivement des avantages, et rendre plus difficile pour les utilisateurs potentiels d'en profiter n'est pas une façon de créer le meilleur outil pour tous.

Et si on lance le programme avec certains anciens kernels, il plante la calculatrice! C'est totalement inacceptable. Si PpHd nous proposait une manière de détecter si on a un kernel suffisamment récent (sans devoir coder en dur les identifiants PO (PreOs) et RO (PedroM), ce serait un lock-in, ça!),

Mouais... lock-in en théorie, à la limite, mais en pratique, quelqu'un va s'amuser à développer un nouveau 'kernel' pour TI-68k ? Allons donc

d'autant plus qu'il est trivial de contourner ce refus.

Si je désactive le CVS, tu contourneras ça comment?

Mon propos se plaçait dans le cadre de la création (coopérative ou pas) d'un miroir à partir d'un repository CVS _accessible_, naturellement

Voire si j'y committe n'importe quoi sans te prévenir et que je release une branche privée totalement différente.

Vu que je vérifie le contenu des commits avant de propager sur le miroir (pour vérifier que le diff-er de dumpfiles SVN que j'ai écrit ne fait pas n'importe quoi), tu te donnerais de la peine pour rien

Et avec le temps que j'ai passé à maintenir mon patchset pour GCC, je sais aussi exactement quoi faire de release à release pour transformer tes merges en enfer (le projet GCC a fait plein de trucs comme ça sans faire exprès)

Si ça t'amuse plus de faire ch*** les autres (détruire) que de bosser à _avancer_ TIGCC (construire), vas-y donc

non désolé je parlais pas de conflits (qui sont pas un problème) mais de pourissage complet de repository en cas de problème de commit. et de la super méthode de gestion des historiques dans un fichier par objet, de l'absence de gestion de répertoires, etc etc etc

bref tu pourras pas me convaincre que CVS n'a pas fait son temps.

Lionel Debroux (./244) :
* je maîtrise suffisamment Perl (appris en-dehors de la fac, d'ailleurs, malheureusement...) pour faire, avec plus de facilité d'écriture qu'en Delphi ou C++, et en profitant de la profondeur de CPAN (plusieurs modules qui parcourent une arborescence de fichiers déjà tout prêts), un outil qui sait mettre des chemins complets partout.

Sauf que la bonne solution, c'est de ne devoir mettre des chemins complets nulle part, pas partout. Et aussi convertir automatiquement les références à _ROM_CALL_nnn vers le vrai nom quand il est connu. Et pour ça, il faut la refonte prévue du système de documentation.

-tu ne sais pas +tu n'as pas réfléchi.
Non seulement plusieurs ont posté dans ce topic, mais il y en a au moins un qui devrait t'être évident, avec ce que j'ai écrit dans ./227...

Je sais très bien réfléchir, mais je ne veux accuser personne sans preuves irréfutables. (Je soupçonne 3 personnes sans te compter, mais je ne ferai pas de noms sans preuves.)

Je pense qu'il serait malin d'ajouter un mode de compatibilité avec la syntaxe classique Motorola à GNU as.

Et qui le code? Il y a un mode --mri-compat qui fait certaines de ces choses, mais il est loin de gérer toutes les bizarreries de A68k. La mythique "syntaxe classique Motorola" n'existe pas, les assembleurs sont tous différents, il y a apparemment des différences subtiles entre les assembleurs MRI et A68k (à moins que le mode --mri-compat ne soit incomplet).

Tiens, stdint.h / inttypes.h... Je les avais oubliés, ceux-là.

Pour avoir une implémentation mergeable de ces headers, il faudra un fichier .hsf pour chaque type déclaré, avec tous les "See Also" qu'il faut. Ça me prend 5 minutes d'écrire juste un header, ce n'est pas du tout ça, le travail.

Mouais... lock-in en théorie, à la limite, mais en pratique, quelqu'un va s'amuser à développer un nouveau 'kernel' pour TI-68k ? Allons donc

Tu ne peux pas prévoir le futur. On disait la même chose avec PreOs 0.67, puis est venue la Titanium, PreOs n'a pas été porté assez rapidement et TitaniK, puis Iceberg ont été créés. Même si on ignore TitaniK qui est un peu particulier, je signale que l'identifiant kernel de Iceberg est 'IC', pas 'PO'.

Vu que je vérifie le contenu des commits avant de propager sur le miroir (pour vérifier que le diff-er de dumpfiles SVN que j'ai écrit ne fait pas n'importe quoi), tu te donnerais de la peine pour rien

Une erreur subtile, genre une faute de frappe dans un nom de variable ou un petit mixup de = et ==, voire carrément une erreur logique indétectable par le compilateur, ça se glisse rapidement, et je ne suis pas sûr que tu arrives à détecter ça avant d'avoir rendu ton code bogué ou non compilable, et je pourrai toujours faire semblant d'avoir fait une erreur, corriger le problème, et en introduire un autre encore plus subtil dans le prochain commit.

squalyl (./245) :
pourissage complet de repository en cas de problème de commit

Jamais vu ça, et visiblement Fedora n'a jamais eu ce problème avec leur CVS pour les paquetages.

Kevin Kofler (./247) :
Une erreur subtile, genre une faute de frappe dans un nom de variable ou un petit mixup de = et ==, voire carrément une erreur logique indétectable par le compilateur, ça se glisse rapidement, et je ne suis pas sûr que tu arrives à détecter ça avant d'avoir rendu ton code bogué ou non compilable, et je pourrai toujours faire semblant d'avoir fait une erreur, corriger le problème, et en introduire un autre encore plus subtil dans le prochain commit.

désolé de dire ça crûment, mais ça ferait de toi un fieffé salaud et ne redorerait sans doute pas ton image dans la communauté libre.

prout

Si t'as rien à apporter tu peux aller te faire voir ailleurs, merci

De toute façon, visiblement, vous êtes déjà bien partis tous seuls pour dégrader la qualité de votre fork, étant donnée votre intention apparente d'accepter des headers entiers sans documentation, des patches qui ne fonctionnent qu'à moitié etc., donc ce ne sera probablement pas la peine que je le fasse.

même pas envie de te répondre tellement tu veux rien comprendre.

bah alors tais toi

pas faux, allez taisons nous.

Je souhaiterais finir au sujet de la doc

je maîtrise suffisamment Perl (appris en-dehors de la fac, d'ailleurs, malheureusement...) pour faire, avec plus de facilité d'écriture qu'en Delphi ou C++, et en profitant de la profondeur de CPAN (plusieurs modules qui parcourent une arborescence de fichiers déjà tout prêts), un outil qui sait mettre des chemins complets partout.

Sauf que la bonne solution, c'est de ne devoir mettre des chemins complets nulle part, pas partout.

Je ne suis pas sûr que tu aies fait part de cette opinion à l'époque, mais passons...
A la limite, pourquoi pas. Mais passer du caca actuel (mélange) à soit aucun chemin complet, soit tous les chemins complets, et passer dans les deux sens entre ces deux dernières solutions (en particulier dans le sens 'enlever les chemins complets'), ne présente pas de difficulté.

Et aussi convertir automatiquement les références à _ROM_CALL_nnn vers le vrai nom quand il est connu.

Hmm. Quand on veut faire ça, qu'y a-t-il à faire, à part changer '_ROM_CALL_nnn' ou 'unknown.h/_ROM_CALL_nnn' en 'funcname' ou 'header.h/funcname' (selon la convention qu'on utilise) dans les lignes suivantes:
[ul][li]'See (a|A)lso='[/li]
[li]'In='[/li]
[li]'Out='[/li]
[li]les autres lignes qui contiennent des $$LINK((unknown.h/)?_ROM_CALL_nnn) - sachant qu'il n'y a actuellement aucune telle ligne dans tigcc/doc/System/Include, et que de telles références vers des ROM_CALLs non documentés n'auraient pas grand sens.[/li][/ul]
?


Pour chacun de ces deux changements, il est possible de faire autrement qu'une refonte complète du système de doc. J'écrirais même que c'est facile de faire autrement, vu le temps que j'ai passé à faire mon script Perl qui met des chemins complets partout, et le nombre de lignes de code significatives...
Que tu souhaites faire d'autres choses que tu n'as pas envie de révéler (tu n'y es pas obligé, évidemment ), et qui elles, seraient difficiles à faire sans modifier le code Delphi, c'est tout à fait possible. Mais les deux raisons que tu as données comme nécessitant ('il faut') une réécriture du système de doc me paraissent fausses, désolé.

Préprocesser les fichiers avant de lancer les outils, c'est du bidouillage, pas une solution à long terme.

Tant qu'il n'y a pas de très bonne raison de réécrire le système, je pense qu'il peut être plus malin de faire un 'bidouillage' qui prend 2-3h, voire beaucoup moins (le déplacement d'un fichier ne doit pas prendre bien plus de 10 lignes de sed ou awk, du moins si on a soit des chemins complets partout soit des chemin incomplets partout...) plutôt que de passer le double, le triple de temps à réécrire l'outil dans un autre langage qui n'est pas de type script (moins de sucre syntaxique, etc.).
Nous ne sommes pas d'accord là-dessus, on le sait... et on en restera là, si tu le veux bien.

-

squalyl (./249) :
Si t'as rien à apporter tu peux aller te faire voir ailleurs, merci

!kick JackosKing
--- Kick : vous n'etes pas modérateur ou administrateur de ce forum !
--- Kick : vous n'etes pas modérateur ou administrateur de ce forum !

Participer à un reglement de compte completement sterile et HS, non!
Par contre kdewin ca m'interesse!

Franchement, je suis d'accord avec toi.
Je m'excuse pour ma participation au hors-sujet, mais je ne pouvais pas laisser certaines accusations sans réponse.
Maintenant, si on pouvait revenir au sujet?
Si vous voulez avoir les dernières nouvelles du projet, jeter un coup d'œil sur la mailing list peut être très utile: http://mail.kde.org/pipermail/kde-windows/. Mais tout n'est pas intéressant pour tout le monde, par exemple on y trouve souvent des problèmes de compilation du trunk qui ne concernent pas trop l'utilisateur qui installe juste les binaires officiels.
Sinon, actuellement, il y a des binaires W32 de KDE 4.1.0.

dualmoo (./199) :
Les droits moraux sont incessibles, imprescriptibles et inaliénables.

Mais ils sont héritables par contre

Je ne sais pas si les droits moraux sont vraiment héritables (ie. je doute que les héritiers aient un droit de retrait sur les oeuvres). Ils n'héritent que du droit d'exploitation, je pense.

Les héritiers peuvent parfaitement interdire la représentation d'une œuvre, ils ne se contentent pas de toucher les droits, malheureusement (et « les héritiers » peuvent être absolument n'importe qui, par exemple les éditions Universal )

Oui mais l'interdiction de représentation, je ne pense pas que ça soit la même chose que le retrait (interdiction d'édition, destruction d'une oeuvre picturale, etc.), si ? (oué, je sais bien que ça peut être une maison d'édition ou Mickael Jackson).

Je ne sais pas mais bon dans le cas d'une œuvre théâtrale ou musicale (ou les deux) ça te fait une belle jambe de pouvoir lire le texte (oui ok c'est mieux que rien mais bon), si tu n'as pas le droit de la jouer elle est retirée de fait...
pour un roman, ok.

après je ne sais pas ce que recouvre juridiquement « droits moraux » mais d'après moi ça s'y apparente (on peut te dire : vous n'avez pas le droit de jouer, ou bien : vous pouvez jouer mais seulement comme ci et comme ça, ou parfois : seulement dans un grand théâtre parisien (oui oui c'est une exigence d'héritier typique)), bref ça permet de décider arbitrairement ce que tu as le droit de faire ou non avec l'œuvre, par opposition aux droits consistant à toucher des royalties sur les utilisations de l'œuvre.

Et le ridicule, c'est que n'importe quel théâtre amateur aux USA peut représenter l'œuvre quand les droits d'auteur ont expiré là-bas, ils peuvent aussi détruire l'image de la pièce entièrement (ils peuvent même faire ça sous certaines conditions quand les droits d'auteur sont encore valables, si ça tombe sous le droit de parodie qui est très fort aux USA), et les théâtres français n'ont pas le droit de faire la même chose parce que les droits moraux n'expirent pas en France. (En revanche, si la représentation est filmée et distribuée en France, les américains peuvent se taper un procès en France, c'est déjà arrivé avec des films.)

Kevin Kofler (./265) :
Et le ridicule, c'est que n'importe quel théâtre amateur aux USA peut représenter l'Å“uvre quand les droits d'auteur ont expiré là-bas, ils peuvent aussi détruire l'image de la pièce entièrement

C'est aussi le cas en France, hein... je ne compte pas le nombre d'orchestres amateurs qui massacrent l'oeuvre de Bizet

Kevin Kofler (./265) :
(ils peuvent même faire ça sous certaines conditions quand les droits d'auteur sont encore valables, si ça tombe sous le droit de parodie qui est très fort aux USA)

Ca, on y a droit en France aussi (pour combien de temps ? c'est une autre question).

ça dépend qui tu parodies

Kevin Kofler (./265) :
Et le ridicule, c'est que n'importe quel théâtre amateur aux USA peut représenter l'œuvre quand les droits d'auteur ont expiré là-bas

Sauf que les droits d'auteur n'expirent plus

Oui mais peut-être que c'est plus facile d'être reconnu comme une parodie aux USA ?

sinon la différence c'est que les droits d'auteur expirent plus tard en France (70 ans après la mort de l'auteur, voire plus sous diverses conditions, c'est énorme). Ainsi on peut remarquer que Feydeau est beaucoup plus joué depuis quelques années, en fait c'est juste parce qu'il n'est dans le domaine public que depuis récemment — avant cela, l'autorisation de jouer ses pièces dépendait de son petit-fils qui, comédien, ne la donnait que s'il était distribué dans la pièce...

edit (cross) : comment ça ils n'expirent plus

ben théoriquement ils expirent (sinon ce serait contraire à la Constitution), mais en pratique les oeuvres postérieures à 1928 ne tomberont pas dans le domaine public avant la prochaine révolution ^^ (au sens propre ou figuré)