- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: Why you need new Method trailers? :)

by Adrian Lienhard

Yes, it also works for aliased methods. It should be ... @ {#methodB -> #methodA} meaning methodB is an alias for methodA Cheers, Adrian On Dec 21, 2009, at 13:50 , Igor Stasenko wrote: > 2009/12/21 Adrian Lienhard <adi(a)netstyle.ch>: >> >> On Dec 21, 2009, at 13:36 , Igor Stasenko wrote: >> >>> 2009/12/21 Adrian Lienhard <adi(a)netstyle.ch>: >>>> >>>> Hi Igor, >>>> >>>> This looks complicated... >>> >>> Hmm, i wonder, what Traits serve for, if requesting an original >>> source >>> code of method which being installed in specific behavior using >>> specific selector >>> becomes non-trivial task. >> >> Well, it *is* trivial -- at least with the version of the Traits >> implementation in Pharo. See the changeset I attached. >> > will it work for aliased ones? > > I found that in both trunk & pharo, aliases seem disfunctional. > > create > Trait named: #Foo > > create method: > Foo>>methodA . > > create > Trait named: #Bar > using: Foo @ {#methodA -> #methodB }. > > Bar shows a single method (methodA) ... but i expected to see > #methodB instead. > > Same for classes.. > > Object subclass: #Zork > uses: Bar > .. > shows methodA, not methodB in browser. > I am doing something wrong? > >> Cheers, >> Adrian >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Why you need new Method trailers? :)

by Igor Stasenko

2009/12/21 Adrian Lienhard <adi(a)netstyle.ch>: > > On Dec 21, 2009, at 13:36 , Igor Stasenko wrote: > >> 2009/12/21 Adrian Lienhard <adi(a)netstyle.ch>: >>> >>> Hi Igor, >>> >>> This looks complicated... >> >> Hmm, i wonder, what Traits serve for, if requesting an original source >> code of method which being installed in specific behavior using >> specific selector >> becomes non-trivial task. > > Well, it *is* trivial -- at least with the version of the Traits > implementation in Pharo. See the changeset I attached. > will it work for aliased ones? I found that in both trunk & pharo, aliases seem disfunctional. create Trait named: #Foo create method: Foo>>methodA . create Trait named: #Bar using: Foo @ {#methodA -> #methodB }. Bar shows a single method (methodA) ... but i expected to see #methodB instead. Same for classes.. Object subclass: #Zork uses: Bar .. shows methodA, not methodB in browser. I am doing something wrong? > Cheers, > Adrian > > -- Best regards, Igor Stasenko AKA sig.

Dec. 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Why you need new Method trailers? :)

by Adrian Lienhard

On Dec 21, 2009, at 13:36 , Igor Stasenko wrote: > 2009/12/21 Adrian Lienhard <adi(a)netstyle.ch>: >> Hi Igor, >> >> This looks complicated... > > Hmm, i wonder, what Traits serve for, if requesting an original source > code of method which being installed in specific behavior using > specific selector > becomes non-trivial task. Well, it *is* trivial -- at least with the version of the Traits implementation in Pharo. See the changeset I attached. Cheers, Adrian

Dec. 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Why you need new Method trailers? :)

by Igor Stasenko

2009/12/21 Adrian Lienhard <adi(a)netstyle.ch>: > Hi Igor, > > This looks complicated... Hmm, i wonder, what Traits serve for, if requesting an original source code of method which being installed in specific behavior using specific selector becomes non-trivial task. > Note, in Pharo this does not work because there is > no sharing of compiled methods from traits anymore. > and it is good that there is no sharing, because in fact, my new code won't work if traits/behaviors sharing same CompiledMethod instances, because this could lead to recursion when looking for method's source code. I'm also made my own 'fix' for that by overriding the addTraitSelector: aSymbol withMethod: aCompiledMethod which ALWAYS makes a copy of aCompiledMethod before installing it into receiver's method dict and replaces its trailer with one that tells class to use #getSourceCodeBySelector: for finding its source code. (I hope this is the only entry method, which used by all traits to install the non-local method in behavior's method dict, if not, please tell me what other places should be fixed). I found that because squeak not doing that, there is a funky methods, which a) originally belong to some trait b) responding a behavior (not trait), where it installed when sending #methodClass a regression test is: Trait allSubInstancesDo:[:t | t methodDict do: [:m | self assert(m methodClass == t) ]] > I attached a changeset that does the same as yours but for Pharo. > Thanks, i'll take a look. > > > > > The only thing that is needed are a few lines in sourceCodeAt:. The method > #traitOrClassOfSelector: returns the origin of a method -- this should work > just fine for aliased methods too. > > HTH, > Adrian > > On Dec 21, 2009, at 01:09 , Igor Stasenko wrote: > >> I just created a small changeset >> >> http://bugs.squeak.org/view.php?id=7432 >> >> which gives me a long awaited feature: >> to see in a browser, where the heck a given method comes from. >> >> If method comes from trait, a method's source tells me , from which one >> exactly! >> >> Open a browser on Behavior clas and select an #addExclusionOf:to: method. >> Usually you'll see: >> >> addExclusionOf: aSymbol to: aTrait >> Â Â Â Â self setTraitComposition: ( >> Â Â Â Â Â Â Â Â self traitComposition copyWithExclusionOf: aSymbol to: >> aTrait) >> >> But with my changes you'll see: >> >> " From: TAccessingTraitCompositionBehavior " >> addExclusionOf: aSymbol to: aTrait >> Â Â Â Â self setTraitComposition: ( >> Â Â Â Â Â Â Â Â self traitComposition copyWithExclusionOf: aSymbol to: >> aTrait) >> >> in code pane. >> >> Same applies to traits themselves for instance, browse >> TPureBehavior>>isAliasSelector: >> >> " From: TAccessingTraitCompositionBehavior " >> isAliasSelector: aSymbol >> Â Â Â Â "Return true if the selector aSymbol is an alias defined >> Â Â Â Â in my or in another composition somewhere deeper in >> Â Â Â Â the tree of traits compositions." >> >> Â Â Â Â ^(self includesLocalSelector: aSymbol) not >> Â Â Â Â Â Â Â Â and: [self hasTraitComposition] >> Â Â Â Â Â Â Â Â and: [self traitComposition isAliasSelector: aSymbol] >> >> >> There is one problem , which requires better expertise than mine and i >> need a help from Traits experts: an aliased methods. >> I tried to find out, how to dig out the aliased method from >> composition, and get its source to display in code pane .. but no >> luck. >> Please give me an advice, how a Â #getSourceCodeBySelector: >> method should be implemented for proper handling of aliases. >> Currently, all aliased methods sources shown using decompiler: >> >> Behavior>>methodDictAddSelectorSilently: t1 withMethod: t2 >> Â Â Â Â self basicAddSelector: t1 withMethod: t2 >> >> Aliased methods, obviously, will require an additional info in source >> header, like: >> >> " From: SomeTrait , originalSelector: Â #blablba " >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- Best regards, Igor Stasenko AKA sig.

Dec. 21, 2009

Re: [Pharo-project] Why you need new Method trailers? :)

by Adrian Lienhard

Hi Igor, This looks complicated... Note, in Pharo this does not work because there is no sharing of compiled methods from traits anymore. I attached a changeset that does the same as yours but for Pharo. The only thing that is needed are a few lines in sourceCodeAt:. The method #traitOrClassOfSelector: returns the origin of a method -- this should work just fine for aliased methods too. HTH, Adrian On Dec 21, 2009, at 01:09 , Igor Stasenko wrote: > I just created a small changeset > > http://bugs.squeak.org/view.php?id=7432 > > which gives me a long awaited feature: > to see in a browser, where the heck a given method comes from. > > If method comes from trait, a method's source tells me , from which > one exactly! > > Open a browser on Behavior clas and select an #addExclusionOf:to: > method. > Usually you'll see: > > addExclusionOf: aSymbol to: aTrait > self setTraitComposition: ( > self traitComposition copyWithExclusionOf: aSymbol to: aTrait) > > But with my changes you'll see: > > " From: TAccessingTraitCompositionBehavior " > addExclusionOf: aSymbol to: aTrait > self setTraitComposition: ( > self traitComposition copyWithExclusionOf: aSymbol to: aTrait) > > in code pane. > > Same applies to traits themselves for instance, browse > TPureBehavior>>isAliasSelector: > > " From: TAccessingTraitCompositionBehavior " > isAliasSelector: aSymbol > "Return true if the selector aSymbol is an alias defined > in my or in another composition somewhere deeper in > the tree of traits compositions." > > ^(self includesLocalSelector: aSymbol) not > and: [self hasTraitComposition] > and: [self traitComposition isAliasSelector: aSymbol] > > > There is one problem , which requires better expertise than mine and i > need a help from Traits experts: an aliased methods. > I tried to find out, how to dig out the aliased method from > composition, and get its source to display in code pane .. but no > luck. > Please give me an advice, how a #getSourceCodeBySelector: > method should be implemented for proper handling of aliases. > Currently, all aliased methods sources shown using decompiler: > > Behavior>>methodDictAddSelectorSilently: t1 withMethod: t2 > self basicAddSelector: t1 withMethod: t2 > > Aliased methods, obviously, will require an additional info in source > header, like: > > " From: SomeTrait , originalSelector: #blablba " > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 21, 2009

Re: [Pharo-project] Long method can not be compiled using #compile: aString

by Lukas Renggli

You might want to have a look at SmaCC and how it generates the scanner code: a huge state machine implemented in a single method that consumes the source code of a programming language. To compile the method SmaCC repeatedly applies the "extract method" refactoring to reduce the code into nicely sized (but still efficient) methods. Lukas 2009/12/21 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/12/20 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/12/20 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>> On Dec 20, 2009, at 8:44 PM, Bart Gauquie wrote: >>> >>>> Dear all, >>>> >>>> I'm developing code which generates a method content, compiles it and adds it to an existing class. >>>> I compile the message using #compile: message: >>>> for instance: >>>> >>> In general, everything is limited to a fairly low quantity: number of temps, number of ivars, number of >>> literals. >>> >>> Especially that the literal frame is limted to some small number (255 or something) can be easily be a problem. >>> (we ran into that already when using bytesurgeon on large existing methods when reifying all sends, for example). >>> >> >> To get around this, place all literals into one (usually array): >> #( a b c d e ..... ) >> >> For instance, the above: >> Â self addMMEFrom: 1054@512 to: 1037@504. >> Â self addMMEFrom: 651@559 to: 643@579. >> >> can be easily replaced by something like: >> >> #( (1054 512 1037 504) >> Â Â ..... put as many as you want here.... no limit!!! >> >> Â Â (651 559 643 579) ) do: [:each | >> self addMMEFrom: (each first @ each second) to: (each third @ each fourth) >> ] >> >>> Â Â Â Â Marcus >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Hehe, when generating code for evaluating monster symbolic > expressions, I bumped into many of these limitations. > Using a literal Array was not enough because even the indices would > consume a literal slot. So i had to decompose indices into > operations... Â Oh, and even some message sends had to be transformed > in #perform: sends (not shown here)... > Here is a fragment of code for allocating a literal slot (in > Objectworks, an ancestor of VW). > > Nicolas > > CodeStream subclass: #ExtendedCodeStream > Â Â Â Â instanceVariableNames: 'reduceLiterals' > Â Â Â Â classVariableNames: 'MaxLiteralIndex ' > Â Â Â Â poolDictionaries: 'OpcodePool ' > Â Â Â Â category: 'System-Compiler' > > ExtendedCodeStream>>pushReducedConstant: lit > Â Â Â Â "Handle MaxLiteralsNumber" > > Â Â Â Â | classIndex newClassArray litIndex | > Â Â Â Â self push. > Â Â Â Â lit == nil > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [code nextPut: OpLoadNil. > Â Â Â Â Â Â Â Â Â Â Â Â ^self]. > Â Â Â Â lit == true > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [code nextPut: OpLoadTrue. > Â Â Â Â Â Â Â Â Â Â Â Â ^self]. > Â Â Â Â lit == false > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [code nextPut: OpLoadFalse. > Â Â Â Â Â Â Â Â Â Â Â Â ^self]. > Â Â Â Â lit isInteger > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [(lit >= 0 and: [lit <= 2]) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [code nextPut: OpLoadZero + lit. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^self]. > Â Â Â Â Â Â Â Â Â Â Â Â (lit >= 0 and: [lit <= 255]) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [code nextPut: OpLoadByte with: lit. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^self]. > Â Â Â Â Â Â Â Â Â Â Â Â (lit >= -32768 and: [lit < 32768]) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [code > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â nextPut: OpLoadTwoBytes > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â with: ((lit bitShift: -8) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â bitAnd: 255) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â with: (lit bitAnd: 255). > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^self]]. > Â Â Â Â ((lit isMemberOf: Character) > Â Â Â Â Â Â Â Â and: [lit asInteger between: 0 and: 255]) > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [code nextPut: OpLoadCharacter with: lit asInteger. > Â Â Â Â Â Â Â Â Â Â Â Â ^self]. > Â Â Â Â classIndex := literals at: lit class > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifAbsent: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ["Add the literal class array to the collection" > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â literalCollection addLast: Array new. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â literals at: lit class put: literalCollection size - 1]. > Â Â Â Â classIndex > MaxLiteralIndex > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [Errorscript cr; show: 'compilation failure: too many literal classes...'. > Â Â Â Â Â Â Â Â Â Â Â Â self class literalLimitSignal raiseWith: topNode body]. > Â Â Â Â classIndex <= MaxLoadLiteral > Â Â Â Â Â Â Â Â ifTrue: [code nextPut: OpLoadLiteral + classIndex] > Â Â Â Â Â Â Â Â ifFalse: [code nextPut: OpXLoadLiteral with: classIndex]. > Â Â Â Â newClassArray := literalCollection at: classIndex + 1. > Â Â Â Â litIndex := newClassArray indexOf: lit ifAbsent: [0]. > Â Â Â Â litIndex = 0 > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [newClassArray := newClassArray copyWith: lit. > Â Â Â Â Â Â Â Â Â Â Â Â literalCollection at: classIndex + 1 put: newClassArray. > Â Â Â Â Â Â Â Â Â Â Â Â litIndex := newClassArray size]. > Â Â Â Â self pushBigIndex: litIndex. > Â Â Â Â self sendNoCheck: #at: numArgs: 1 > > ExtendedCodeStream>>pushBigIndex: index > Â Â Â Â "i do not want the index to figure in literalCollection > Â Â Â Â so it must remain < 32768" > > Â Â Â Â | q r | > Â Â Â Â index < 32768 ifTrue: [^self pushConstant: index]. > Â Â Â Â q := index // 32768. > Â Â Â Â r := index - (q * 32768). > Â Â Â Â self pushConstant: 32767; pushConstant: 1; sendNoCheck: #+ numArgs: 1. > Â Â Â Â q = 1 ifFalse: [self pushBigIndex: q; sendNoCheck: #* numArgs: 1]. > Â Â Â Â r = 0 ifFalse: [self pushConstant: r; sendNoCheck: #+ numArgs: 1]. > > ExtendedCodeStream>>pushStatic: binding > Â Â Â Â "Static variables do normally consume a literal slot. > Â Â Â Â Arrange to economize this precious ressource" > > Â Â Â Â reduceLiterals > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [self pushReducedConstant: binding. > Â Â Â Â Â Â Â Â Â Â Â Â self sendNoCheck: #value numArgs: 0] > Â Â Â Â Â Â Â Â ifFalse: [super pushStatic: binding] > > ExtendedCodeStream>>pushConstant: lit > Â Â Â Â "Handle MaxLiteralsIndex" > > Â Â Â Â reduceLiterals ifTrue: [^self pushReducedConstant: lit]. > Â Â Â Â super pushConstant: lit. > > ExtendedCodeStream>>testLiteralsSize > Â Â Â Â "Restart compilation if literal limit is exceeded" > > Â Â Â Â literalCollection size > MaxLiteralIndex ifTrue: [reduceLiterals > Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self class literalLimitSignal raiseWith: topNode body] > Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self doReduceLiterals; restartCompilation]] > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 21, 2009

Re: [Pharo-project] did you check in 1.1 how the old browser now support the creation of new method cat

by Lukas Renggli

> Lukas, is there a particular reason why you want/need your stuff to > work also with 1.1? The initial trigger for this discussion was Stef asking me to use #chooseOrRequestFrom: for creating protocols in OB. This method was a recently added to morphic in Pharo 1.1 and is used in the old ST-80 browser to create new method protocols with one click. I would love to add it to OB, but since this requires Pharo 1.1 I cannot. > I don't think it makes sense to adapt and fix the external packages > that are in Pharo (of which you maintain a few) as long as PharoCore > is in alpha state. I do not complain, I completely agree with the Pharo development process. It is great what you are doing. I was telling Stef that I cannot take advantage of the cool new dialogs right now, but only when there is a release candidate for Pharo 1.1. Also I was hoping that I could use Helvetia directly in Pharo 1.1, maybe together with a proposal for making the compiler tool-chain easier to plug-in. However since Helvetia depends on RB and OB that would mean that I had to fork these two projects. Something I cannot do right now. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 21, 2009

Re: [Pharo-project] did you check in 1.1 how the old browser now support the creation of new method cat

by Adrian Lienhard

Lukas, is there a particular reason why you want/need your stuff to work also with 1.1? I don't think it makes sense to adapt and fix the external packages that are in Pharo (of which you maintain a few) as long as PharoCore is in alpha state. Therefore, I think its a bit early to provide a public Pharo 1.1 image on the download page. This gives the false impression that also the externally maintained packages are being worked on in the 1.1 branch. Cheers, Adrian BTW: this is the same with most other software projects. E.g., I don't migrate our commercial projects to Seaside 3 at least until it is final and stable. On Dec 21, 2009, at 10:35 , StÃ©phane Ducasse wrote: > Adrian > > lukas was frustrated because he could not have the last version of > the tools like RB, helvetia working in 1.1 and 1.0 > I think that this is not something that you can expect. Else we can > just stop Pharo now and go to > do something else. > > This is why tools should work on a stable version and be marked > tools for Pharo1.0 > and brnaching to have tools for pharo1.1 > > Stef > > > On Dec 20, 2009, at 7:53 PM, Adrian Lienhard wrote: > >> Version 1.0 is the one to work with, to build and maintain tools for, >> etc. Unless you work on the Pharo base system there is no good reason >> to use 1.1 at the current time. It is unstable and it is going to >> change. Furthermore, nobody can expect that external packages are >> already flawlessly working with the moving target 1.1. At a later >> point when 1.1 is getting stable it makes sense to move over from 1.0 >> and make your packages, applications etc. work with the new version. >> >> I don't know the details and context of the discussion that Stef >> posted. But I assume that it also concerns packages that are in Pharo >> (i.e., packages that are added to PharoCore). There we have a >> slightly >> different situation because these packages are part of the Pharo >> image >> and hence also need to follow its release regime. That is, for the >> release of Pharo 1.0, the added packages need to be in a stable >> state. >> The versions of the packages used in Pharo should not add new >> features >> since post release 1.0 there should only be few updates for critical >> fixes. >> >> Adrian >> >> On Dec 20, 2009, at 19:16 , HernÃ¡n Morales Durand wrote: >> >>> Hi, >>> can you clarify what is a frozen 1.0 and which is the stable Pharo >>> image to use as a base system to develop tools? (I cannot mantain my >>> packages for both 1.0 and 1.1, it's a lot of work) >>> Thanks >>> >>> HernÃ¡n >>> >>> 2009/12/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I sent that to the list because this is really important. >>>> >>>> >>>> >>>> >>>>>> one of these days we will have to have some pharo specific tools. >>>>> >>>>> There will be nobody that maintains them. There will be nobody >>>>> that takes responsibility and that writes and runs tests. You can >>>>> see that with Davids browser, it is dead. You can see that with >>>>> Services, they are dead. And many others ... >>>> >>>> Yes but pharo is moving so slowly we will get more people taking >>>> care of packages. >>>> >>>>> But that is not the real problem. And I didn't mean Squeak >>>>> (although that's a problem too, but I personally don't care). What >>>>> I ment is the difference between Pharo 1.0 and Pharo 1.1. >>>> >>>> You lost me there :) >>>> >>>>> These two versions are killing any progress on the tool front and >>>>> makes any maintainer of external packages a lot of pain. >>>> >>>> Why >>>> why don't you freeze a version for pharo1.0 >>>> Else we can just stop now. >>>> because this will be the same with pharo1.1 and 1.2 and 1.0 >>>> >>>>> I spent the complete Thursday and Friday trying to get Helvetia >>>>> running in Pharo 1.1, but that doesn't work because it requires >>>>> some significant changes in packages like the Refactoring Rngine, >>>>> the AST, Shout, eCompletion and OB that are also supposed to work >>>>> on Pharo 1.0. >>>> >>>> No there are not supposed to work in 1.0 >>>> CERTAIN frozen versions are supposed to work on 1.0 and others >>>> won't. >>>> A lot of software on mac does not run automatically on snowleopard >>>> and 10.2 >>>> >>>> Tell me if Im wrong but we should use release and version. >>>> >>>>> Adding the category dialog to OB makes it depend on 1.1, thus >>>>> people cannot use it in 1.0 anymore. So the category dialog can >>>>> maybe happen in a year from now. I cannot use 1.1 at the moment, I >>>>> am stuck with the frozen 1.0 version. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 21, 2009

Re: [Pharo-project] Long method can not be compiled using #compile: aString

by Nicolas Cellier

2009/12/20 Igor Stasenko <siguctua(a)gmail.com>: > 2009/12/20 Marcus Denker <marcus.denker(a)inria.fr>: >> >> On Dec 20, 2009, at 8:44 PM, Bart Gauquie wrote: >> >>> Dear all, >>> >>> I'm developing code which generates a method content, compiles it and adds it to an existing class. >>> I compile the message using #compile: message: >>> for instance: >>> >> In general, everything is limited to a fairly low quantity: number of temps, number of ivars, number of >> literals. >> >> Especially that the literal frame is limted to some small number (255 or something) can be easily be a problem. >> (we ran into that already when using bytesurgeon on large existing methods when reifying all sends, for example). >> > > To get around this, place all literals into one (usually array): > #( a b c d e ..... ) > > For instance, the above: > Â self addMMEFrom: 1054@512 to: 1037@504. > Â self addMMEFrom: 651@559 to: 643@579. > > can be easily replaced by something like: > > #( (1054 512 1037 504) > Â Â ..... put as many as you want here.... no limit!!! > > Â Â (651 559 643 579) ) do: [:each | > self addMMEFrom: (each first @ each second) to: (each third @ each fourth) > ] > >> Â Â Â Â Marcus >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Hehe, when generating code for evaluating monster symbolic expressions, I bumped into many of these limitations. Using a literal Array was not enough because even the indices would consume a literal slot. So i had to decompose indices into operations... Oh, and even some message sends had to be transformed in #perform: sends (not shown here)... Here is a fragment of code for allocating a literal slot (in Objectworks, an ancestor of VW). Nicolas CodeStream subclass: #ExtendedCodeStream instanceVariableNames: 'reduceLiterals' classVariableNames: 'MaxLiteralIndex ' poolDictionaries: 'OpcodePool ' category: 'System-Compiler' ExtendedCodeStream>>pushReducedConstant: lit "Handle MaxLiteralsNumber" | classIndex newClassArray litIndex | self push. lit == nil ifTrue: [code nextPut: OpLoadNil. ^self]. lit == true ifTrue: [code nextPut: OpLoadTrue. ^self]. lit == false ifTrue: [code nextPut: OpLoadFalse. ^self]. lit isInteger ifTrue: [(lit >= 0 and: [lit <= 2]) ifTrue: [code nextPut: OpLoadZero + lit. ^self]. (lit >= 0 and: [lit <= 255]) ifTrue: [code nextPut: OpLoadByte with: lit. ^self]. (lit >= -32768 and: [lit < 32768]) ifTrue: [code nextPut: OpLoadTwoBytes with: ((lit bitShift: -8) bitAnd: 255) with: (lit bitAnd: 255). ^self]]. ((lit isMemberOf: Character) and: [lit asInteger between: 0 and: 255]) ifTrue: [code nextPut: OpLoadCharacter with: lit asInteger. ^self]. classIndex := literals at: lit class ifAbsent: ["Add the literal class array to the collection" literalCollection addLast: Array new. literals at: lit class put: literalCollection size - 1]. classIndex > MaxLiteralIndex ifTrue: [Errorscript cr; show: 'compilation failure: too many literal classes...'. self class literalLimitSignal raiseWith: topNode body]. classIndex <= MaxLoadLiteral ifTrue: [code nextPut: OpLoadLiteral + classIndex] ifFalse: [code nextPut: OpXLoadLiteral with: classIndex]. newClassArray := literalCollection at: classIndex + 1. litIndex := newClassArray indexOf: lit ifAbsent: [0]. litIndex = 0 ifTrue: [newClassArray := newClassArray copyWith: lit. literalCollection at: classIndex + 1 put: newClassArray. litIndex := newClassArray size]. self pushBigIndex: litIndex. self sendNoCheck: #at: numArgs: 1 ExtendedCodeStream>>pushBigIndex: index "i do not want the index to figure in literalCollection so it must remain < 32768" | q r | index < 32768 ifTrue: [^self pushConstant: index]. q := index // 32768. r := index - (q * 32768). self pushConstant: 32767; pushConstant: 1; sendNoCheck: #+ numArgs: 1. q = 1 ifFalse: [self pushBigIndex: q; sendNoCheck: #* numArgs: 1]. r = 0 ifFalse: [self pushConstant: r; sendNoCheck: #+ numArgs: 1]. ExtendedCodeStream>>pushStatic: binding "Static variables do normally consume a literal slot. Arrange to economize this precious ressource" reduceLiterals ifTrue: [self pushReducedConstant: binding. self sendNoCheck: #value numArgs: 0] ifFalse: [super pushStatic: binding] ExtendedCodeStream>>pushConstant: lit "Handle MaxLiteralsIndex" reduceLiterals ifTrue: [^self pushReducedConstant: lit]. super pushConstant: lit. ExtendedCodeStream>>testLiteralsSize "Restart compilation if literal limit is exceeded" literalCollection size > MaxLiteralIndex ifTrue: [reduceLiterals ifTrue: [self class literalLimitSignal raiseWith: topNode body] ifFalse: [self doReduceLiterals; restartCompilation]]

Dec. 21, 2009

Re: [Pharo-project] did you check in 1.1 how the old browser now support the creation of new method cat

by StÃ©phane Ducasse

On Dec 20, 2009, at 7:39 PM, Lukas Renggli wrote: >> can you clarify what is a frozen 1.0 and which is the stable Pharo >> image to use as a base system to develop tools? (I cannot mantain my >> packages for both 1.0 and 1.1, it's a lot of work) > > Pharo 1.0rc1 is basically frozen. The unstable moving target is 1.1. > > The same here, I cannot maintain versions for 1.0 and 1.1. Also I > cannot freeze my tools for 1.0, because I need to change them and want > to use them on a stable base. > > AST and RB should now work in both, but it was a significant amount of > work. I cannot keep RB, OB, Seaside, Pier, Magritte, PetitParser, > SmaCC, ... running on all versions and will concentrate on 1.0 for > now, keeping in mind upcoming changes for the next unstable versions. Yes this is reasonable. I do not see why this would be different without having to maintain two branches. Or it means that the core does not change. (which I hope will happen in the future but not for now). Stef

Dec. 21, 2009