December 2009 - Pharo-dev - lists.pharo.org

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

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

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

Dec. 21, 2009

Re: [Pharo-project] freetype plugin on os-x squeak v5.0

by John M McIntosh

Ok, I spent a good 4 hours here working through issues. Unfortunately the plugin just assumes an oops reference is a pointer (it's not), and that the squeak word size is (4), it might not be, and the occasional FreeType variable is that an int or long? FreeType defines their own var types so their code isn't confused, but we are... Plus a sprinkling of self cCode: to do magic transformations between oops pointers and instance pointer values transformed to an int, or is that a long... So it will be sometime yet before I get it working with a 64bit VM and 32bit image. On 2009-12-17, at 3:16 AM, Henrik Johansen wrote: > > On Dec 17, 2009, at 11:09 01AM, John M McIntosh wrote: > >> Now I need someone to tell me where it fails when running as a 64bit VM with a 32bit image. >> No doubt there is a primitive call that needs to be changed, but I'm a bit too tired now to >> sort thru how the heck the FreeType class works to find out where it fails. (Silently I might add...) -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 21, 2009