Re :[Squeak-fr] Re: fileIn d'un fichier ST > 1 KO

[email protected]
Newsgroups gmane.comp.lang.smalltalk.squeak.french
Message-ID <[email protected]>
Merci Nicolas pour tes précisions.
Tes explications répondent à ma curiosité sur les raisons de limitation.

La méthode trop longue est une méthode existante qui a été écrite en  
utilisant une autre implantation Smalltalk.
Je l'ai divisée en plusieurs sous-méthodes.

Bonne journée,
Houssam


Le 12 mars 2009 22:18, Nicolas Cellier <[email protected]> a écrit :
> >
> > On 12 mars 09, at 15:26, Houssam Fakih wrote:
> > Merci pour ta réponse.
> > J'ai envoyé un peu vite mon courriel.. Squeak traite bien des fichiers  
> dont la
> taille dépasse 1 KO.
> > Je voulais parler des blocs de code qui dépassent 1 KO que Squeak ne  
> compile pas.

> > Ma question : est ce que cette limitation est imposée pour éviter des  
> méthodes
> avec un nombre de lignes important ou bien ya t-il une autre raison pour  
> cela ?
> >


> Il ya en effet pleins de limitations sur les méthodes...

> ...et ceci est lié à la conception de l'interpreteur.

> Le code Smalltalk est convertit en une séquence d'instructions  
> élémentaires.
> Il utilise un langage de bas niveau de type langage à pile.
> La plupart de ces instructions sont codées sur un ou deux octets.

> On parle de bytecode.

> Les instructions principales sont push/pop/send message/return.
> push et pop servent à empiler/dépiler des objects...
> ...échange entre la pile et variables temporaires, d'instances, litéraux.

> send message envoie un message (évidemment)...
> ...et laisse la valeur de retour sur la pile.
> return quitte la méthode (la valeur de retour est empilée avant).

> De plus il ya des instructions de branchement conditionnelles ou non:

> jump jumpIfTrue jumpIfFalse.
> Ces instructions jump ne sont pas strictement nécessaire au langage.
> Elles sont là pour optimiser l'implémentation.
> Tout jump forward peut être remplacé par un message ifTrue:

> (envoyé à un booléan avec un bloc de code en argument).
> Tout jump backward peut être remplacé par une méthode récursive.

> Les limitations viennent:
> - du codage des instruction (bytecode) sur un nombre de bit limités

> - du codage de l'entête des méthodes avec un nombre de bit limités

> Il ne peut y avoir plus de :
> m variables d'instances, superclasses comprises,
> n variables temporaires,
> p litéraux différents dans une méthode,

> les jump ne peuvent pas être longs, (c'est là ton problème je pense)
> Peut être que la profondeur de pile est limitée aussi...

> Quand on écrit dans la philosophie Smalltalk, cela pose rarement un  
> problème.

> Les méthodes font rarement plus de quelques lignes.
> Mais si on veut générer du code, ou que l'on vient avec d'autres  
> habitudes...

> Le nouveau compilateur pourrait contourner certaines limitations.
> Par exemple générer un tableau de litérales si il n'ya plus de slot libre.

> Ou bien un tableau de "variables temporaires"...

> VisualWorks Smalltalk peut contourner le jump trop long aussi...
> ...car les blocs de codes n'utilisent pas de jump.
> Ce sont des objets séparés placés dans les litérales de la méthodes...

> Le compilateur execute turnOffOptimisationOfBlock quand il rencontre  
> l'erreur.
> Malheureusement, l'implémentation des blocs de code en Squeak utilise  
> jump!
> (le code des blocs de code se trouve fondu dans la méthode qui les  
> héberge).


> Voilà, tu as la raison: c'est très technique, et pas très précis...
> Mais tu es invité à creuser la question si cela t'intéresse.

> Mais pourquoi une méthode si longue?

> Nicolas


> >

> > Certes, ce n'est pas de l'ordre du bon style d'écrire des méthodes avec  
> plus
> d'une dizaine de ligne.
> > Mais, c'est un pb d'implantation. Je me demande si cela n'a pas été  
> corrigé

> dans le nouveau compilo.
> > Mais, je crois c'est l'ancien qui est toujours utilisé dans Squeak.
> > As-tu essayé avec Pharo ? Probablement, que le nouveau compilateur y est
> utilisé (ou au moins il devrait l'être).

> > A noter que rien n'empêche d'avoir des méthodes avec de grands tableaux  
> de
> literaux ou de longues chaînes de caractères, même avec l'ancien compilo.
> > Noury
> >
> >
> >
> > Houssam

> > 2009/3/11 Noury Bouraqadi  
> [email protected]>
> > On 11 mars 09, at 15:44, Houssam Fakih wrote:
> > Bonjour la liste,

> > J'essaye de faire fileIn d'un fichier .st.
> > J'ai une exception avec le message suivant : 'A block compiles more  
> than 1K
> bytes of code'.
> > Est ce que vous pourriez m'aider pour comprendre pourquoi il ya cette  
> limitation

> > et qu'est ce que je peux faire pour "fileIn" des fichiers qui dépassent  
> 1 KO.
> > Oui. A priori, il n'ya pas de limite de taille de fichier .ST.
> > La limite que je connais est dans certains compilateurs une limite sur  
> le

> nombre de littéraux.
> > C'est pour cela que les méthodes dans le .ST sont suivies par un point
> d'exclamation.
> > Peut-être qu'il n'y en a pas dans ton fichier .ST. Ca peut poser  
> problème.
> > Nouryhttp://vst.ensm-douai.fr/noury/

> > --------------
> > -ESUG 17th International Smalltalk Conference - Brest, France, August  
> 31 -
> September 4, 2009http://www.esug.org/Conferences/2009
> > -17èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’09).  
> Lyon,

> 21-23 Octobre 2009http://bat710.univ-lyon1.fr/~sycosma/JFSMA09/
> > _______________________________________________
> > Squeak-fr mailing
> listSqueak-fr-bD51WKytQuJI8mQ4nJOOf3xJsTq8ys+cHZ5vskTnxNA@public.gmane.orghttp://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr

_______________________________________________
Squeak-fr mailing list
Squeak-fr-bD51WKytQuJI8mQ4nJOOf3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.