yAroTweet (ou le topic des pensées à la con) - Page 60

un email ? moi c'est sûr que non... mais par contre on nous oblige à prendre des jours...

ah ouais, t'as raison, le client va ptet pleurer et ils vont ptet vouloir raccourcir mes congés, c'est pas impossible

vince (./1770) :
Ouais bah moi, pour noël, avec ma boite, je ne suis même pas sûr d'avoir droit à un email

bah comme pour beaucoup de monde, hein ^^

(sous entendu, j'ai pas de prime de cadeau, de treizième mois... à mettre en perspective avec les "on n'a droit à qu'à" de madame folco, nil et madame nil...)

(ah non, ma femme est scandalisée par tout ce à quoi elle a droit ^^)

Pensée du jour : si vous faites un soft libre, efforcez vous de ne pas mettre de lien de téléchargement depuis la page de présentation, c'est tellement drôle d'aller sur le site d'un utilisateur du soft pour savoir comment le récupérer

Pen^2 (./1771) :
un email ? moi c'est sûr que non... mais par contre on nous oblige à prendre des jours...

5 jours, ici.

Pareil.

./1765 : je pourrais, mais c'est toujours embêtant de pas bosser avec les mêmes outils que ceux qui vont servir au final, surtout qu'il y a des livrables intermédiaires. Y'a le souci des libs aussi, je ne sais pas si elles sont encore maintenues pour MPLAB 8.x ; si elles le sont, ça ne va plus durer longtemps - et déjà que la qualité de la version pour MPLAB X laisse à désirer, la version pour MPLAB 8.x est probablement encore moins bien testée...

Marrant, Atmel est a "contre courant" j'ai installe Atmel Studio et... ce n'est pas du tout eclipse

C'est normal, chez Atmel ils font les choses bien, eux

(non en fait, ils ont testé Eclipse aussi, mais ils ont pas été satisfaits : http://www.electronicsweekly.com/news/design/embedded-systems/atmel-builds-ecosystem-for-avr-embedded-world-2011-03/)

Si vous avez aimé les comics Green Lantern, alors ne regardez pas le film (ou alors préparez un sac à vomit)

./1781 : comment certains peuvent penser que ce ne sont pas des gens bien

Quelqu'un s'est-il déjà fait une opinion sur la distrib Yunohost ? en deux mots, une Debian modifiée avec la plupart des services serveur préinstallés (mail, web, cloud...).
Rien que configurer les accès web me prend toujours la tête quand je dispose d'une nouvelle structure, et je songe actuellement à passer à un serveur privé plutôt que de continuer à louer un dédié, d'autant qu'avec ma nouvelle BBox j'ai un débit upload très acceptable.
Dommage que cette distrib par ailleurs ne soit pas proposée parmi les choix d'install fréquents des fournisseurs.

Question plutôt destinée au topic Linux (même si la plupart des gens qui fréquentent ce topic lisent aussi celui-ci).

Quel casse-tête de taré de vouloir assembler des macros sans expansion du code, avec des labels locaux qui otn des noms aléatoires

Ayé, comme d'hab, le fait de l'écrire me donne une idée, mais ça complique un peu les choses. Pas beaucoup cependant.

Ca vous le fait vous aussi, d'avoir des idées qui viennent en écrivant ? J'ai lu qqpart que l'écriture ou l'expression orale activent certains circuits du cerveau, et débloque parfois des réflexions que l'abstraction pure n'avait pas immaginées. C'est magique, l'homme

Folco (./1786) :
Ca vous le fait vous aussi, d'avoir des idées qui viennent en écrivant ?

À peu de choses près tous les jours.

Merde alors, pourquoi tu me l'as pas dit plus tôt

En effet, je viens de pondre ça en 1/4 heure, ce qui constitue beaucoup plus que les quelques heures précédentes de réflexion :

Parsing des macros :

On ajouter un fichier "virtuel" à la liste des fichiers. Ce fichier à le FLAG_MACRO.
Son point de départ d'assemblage est calculé, donc au début de la ligne suivant la directive MACRO.

Son point d'appel est enregistré pour avoir accès aux arguments. Le point d'appel est enregistré dans un champs de MACRO_HD, à côté de la définition de la macro.
Si ya un appel de macro récursif, on verra que le champs n'est pas vide => exception. Et ça permet d'enchainer les appels de macro dans
les macros sans se soucier de créer une liste à côté juste pour retenir l'adresse des arguments

Le compteur de macro est incrémenté de 1

On appelle AssembleCurrentSource (), qui va démarrer au point de départ d'assemblage précédemment calculé.

Quand, dans cette fonction, on tombe sur des \x. Alors, on retrouve la définition de la macro, on se positionne sur l'argument kivabien, et on continue le parsing
jusqu'à rencontrer une ','.
D'ailleurs, en parsant normalement un source, si on tombe sur une virgule, soit il faut revenir parce qu'on est dans une macro (compteur de macro != 0),
soit on continue si le compteur est nul.

En fait, la lecture de l'argument ne fait que modifier le Curseur, le contexte objet reste le même, ainsi que l'état de la liste des fichiers ouverts/parsés


La directive ENDM vérifie que le compteur de macro n'était pas à 0, le décrémente, puis branche comme si on avait atteint EOF.
On va donc revenir dans la gestion de l'appel de macro : on appelle FilesList::RemoveMacroFile, qui cherche, en partant de la fin, et détruit le premier fichier
contenant le flag FLAG_MACRO. C'est important de ne pas supprimer juste la dernière entrée, car une macro pourrait contenir la direcvive include, dont le fichier est
persistant dans FilesList.





Pour les labels de macro... Ils sont de la forme: \abc@xyz. Abc est constant, xyz est un nombre

Mais il y a aussi des labels de la forme \@abc ou \\@abc, avec abc constant, mais le \@ étant remplacé par qqchose d'unique.

Dans les deux cas, c'est la merde, vu qu'on ne regénère pas de source avec un préproc. Pas la place.



Donc il faut définir une table délimitant les macros. Une table est une suite d'offsets dans le "binaire de l'objet".
Une adresse de départ de macro, une adresse de fin, une adresse de départ, une adresse de fin, etc...


Ainsi, à la création de l'objet, un adressage avec un nom \@lakhôn ne pourra chercher sa résolution que dans l'espace de la macro. Il sera borné, et n'interfèrera
pas avec les macros d'à côté. Comme en plus il est pas con, il sautera les macros gentiment incluses en son sein pour le perturber. M'enfin Comme ça, chacun
travaillant dans un espace où il est unique, pas de risque de conflit. Et voilà la solution au problème des noms uniques.

Pour les \@labels n'étant pas dans une macro, ils chercheront leur résolution partout, sauf dans les macros.
FUCK YEAH !!!!!

edit -> faut la même chose avec les fichiers include, pour localiser les labels uniques qui peuvent être inclus plusieurs fois, suite à plusieurs inclusions (non récursives !) du même fichier

Folco (./1786) :
Ca vous le fait vous aussi, d'avoir des idées qui viennent en écrivant ?

oui, pour moi ça marche plutôt bien comme technique.
il m'arrive régulièrement d'écrire "pour rien", si ce n'est avoir le processus de "mettre mes pensées à plat / au clair", qui permet souvent d'avancer.
ça a tendance à marcher un peu quand j'écris au clavier ; mais je trouve que ça marche mieux en écriture manuscrite ; surtout quand il s'agit plus de réfléchir à "quoi dire / comment avancer" qu'à "comment le formuler"

Comme squale, le fait d'écrire sur papier ou sur un tableau me permet d'organiser les idées et d'en faire venir de nouvelles (idées, voyons ). En particulier quand je dois concrétiser un bout de programme (j'ai le concept, mais j'ai besoin d'une étape intermédiaire avant de passer au code pur ; il y a beaucoup de pseudocode ou de modèles de données dans les feuilles qui trainent partout sur mon bureau au taff).

Pseudo-code et modèle de donnée, pas grand chose à voir avec ce que j'ai écrit. Je ne sais pas si je m'y prends mal, ou si c'est lié au fait que j'implémente en assembleur. Mais déjà, je sais que je ne sais pas analyser, et c'est pour ça que j'ai énormément de mal en conception...

Ben c'est du pseudocode très très écrit Et, parfois, mon pseudocode ressemble aussi à ça (quand je ne veux pas faire des choix d'implémentation trop tôt).
Après, je n'ai jamais fait d'assembleur (à part des TP de 6809, et encore, c'était pour piloter des diodes...), c'est peut-être différent au niveau de l'approche...

Folco (./1786) :
Ca vous le fait vous aussi, d'avoir des idées qui viennent en écrivant ?

Coin !

En fait de "coin", j'ai une peluche Firefox de panda roux pour me tenir compagnie. C'est surprenant, quand tu entends ce que tu dis à haute voix tu réfléchis à ce que tu es en train de dire sans en avoir conscience comme si ça venait d'un autre, tandis que seulement le méditer dans un coin de sa tête ne remet pas les pensées en question sauf si tu y veilles activement.
J'imagine que le même phénomène peut avoir lieu de façon asynchrone avec l'écriture en lisant ce que tu écris.

D'ailleurs, avec cette méthode, quand le canard/la peluche/whatelse te réponds, ça veut dire que tu écris trop de code et que tu as besoin de sommeil.

(Et s'il se met à jouer au Go avec toi ? )

Meowcate -> Ah, côté review, pas de souci, je review mon code 10 ou 20 fois avant de le lancer, d'ailleurs j'ai rarement des bugs. En général, je trouve tout avant. Non le souci est pas là, c'est que j'ai pas de méthode pour analyser correctement, et donc mettre en forme un simple format de données par exemple.Là, j'essaie de faire un format objet. Ben je sais même pas si les infos que je tire du source sont suffisantes pour linker, et j'ai pas la méthodologie pour arriver à répondre à la question : "est-ce que j'ai les infos kivonbien pour linker ?" C'est usant d'être dans le brouillard ><

Moi j'ai Teto* sur mon bureau pour ca

Bon ce n'est pas Teto en fait, mais un des renard écureuils de Laputa, mais bon c'est pareil!

vince (./1794) :
D'ailleurs, avec cette méthode, quand le canard/la peluche/whatelse te réponds, ça veut dire que tu écris trop de code et que tu as besoin de sommeil.

Ou que c'est un perroquet