- Pharo-dev - lists.pharo.org

Re: [Pharo-project] was "Re: About projects with Metacello"

by StÃ©phane Ducasse

On Dec 21, 2009, at 3:12 PM, Damien Cassou wrote: > On Sun, Dec 20, 2009 at 8:32 PM, <csrabak(a)bol.com.br> wrote: >> Is there a reason we keep both O2 and OB in parallel? Can't we >> just get the best parts of one of the solutions and consider the >> other as the "trunk" or mainstream for Pharo? > > Pharo must have the notion of Packages. I'm working on it have a look at RPackage in PharoTaskForces I took into account the feedback I got from lukas and now the tests are green again so I should be able to continue and start to work on the integration inside the system but if someone wants to help or read the code.... > This is a prerequisite of a > good package browser. Unless we have that, O2 will be slow and won't > be the default. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > 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] did you check in 1.1 how the old browser now support the creation of new method cat

by StÃ©phane Ducasse

sure no problem. Lukas. I sent the mail because this is an important point. I think that we should also understand what is a good amount of time between two releases. On Dec 21, 2009, at 12:20 PM, Lukas Renggli wrote: >> 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 > > _______________________________________________ > 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

[Pharo-project] SUnit

by Adrian Kuhn

Niko and me are thinking about doing some work on SUnit. Background is that we are working on Phexample, which extends SUnit with test that expand on one another [1]. We got test dependencies working with the current SUnit, but had to do some quick ugly hacks. So we thought about cleaning the internals SUnit up, and then include test dependencies in the core. Things we would possible change (we will certainly identify more as we clean up SUnit...) - store test resources in a dynamic variable rather than a static one - refactor the assert: protocol to a trait, such that they can be used in setup and teardown of test resources as well (actually I already did that, you can find a version on my squeaksource account) - apply the fixes to test resources in Niall's slide deck that Lukas showed us - add expectations matchers as used in behavior-driven testing - break testcase into two classes, and to run the test and one to store the result (no more #cleanUpInstanceVariables hack to avoid memory leaks) - add test dependencies to test results, such that one test can extend on the return value of another test - fix expected failures such that they are a first-class result (no more #shouldPass with O(n^2) or worse behavior) So you see, the idea is twofold: first to clean up what is there, and second to add test dependencies as a new feature. For those that dont know test dependencies. They had first been proposed by Markus GÃ¤lli based on an analysis of all Squeak tests years ago. He found that most tests cover a superset of another test's coverage set. A prototype in Java as been implemented later by Lea HÃ¤nsenberger and me. We published a case study at XP 2008, which lead to PHP folks to include test dependencies in the latest PHPUnit. The idea of explicit test dependencies is to shift the burden of isolating test cases from the developers to the framework. You avoid duplicate test code and you get less red test cases per failure. Please refer to Niko's blog post for more details [2]. We got some more ideas (such as API baseline testing, search in test results, etc...) but they will not likely make it into a first clean up. One thing we do not know is how many folks are out there that depend on internal representation of SUnit. I talked to some folks and identified two requirements, first that legacy tests should keep running and second that contributions to other sunit forks should keep being mergeable. The first seems feasible, the second sounds like it boils down to not cleaning anything :) What do you think? cheers, AA [1]: http://www.squeaksource.com/phexample.html [2]: http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-ex…

Dec. 21, 2009

Re: [Pharo-project] Issue 1634: Object allSubInstances slooooow

by merlyn＠stonehenge.com

>>>>> "Stan" == Stan Shepherd <stan.shepherd414(a)gmail.com> writes: Stan> Eliot Miranda-2 wrote: >> >> >> Sorry Sam :) I had to be blunt. I knew you'd understand :) >> >> Stan> No worries, it made me laugh. Stan> I do have a question out of it though. Is there a conceivable situation Stan> where you would want Object class to have specific behaviour? If so, as Stan> Object class carries the role of backstop case where other classes don't Stan> define a method, is there any acceptable way to treat Object class Stan> differently? allSubinstances self == Object ifTrue: [^self allSubinstancesSpecialCasedForObject]. ^super allSubinstances -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Dec. 21, 2009

Re: [Pharo-project] Issue 1634: Object allSubInstances slooooow

by Stan Shepherd

Eliot Miranda-2 wrote: > > > Sorry Sam :) I had to be blunt. I knew you'd understand :) > > No worries, it made me laugh. I do have a question out of it though. Is there a conceivable situation where you would want Object class to have specific behaviour? If so, as Object class carries the role of backstop case where other classes don't define a method, is there any acceptable way to treat Object class differently? ...Stan -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p4… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 21, 2009

Re: [Pharo-project] Issue 1634: Object allSubInstances slooooow

by Stan Shepherd

StÃ©phane Ducasse wrote: > > Stan > did you compare/have a look at spaceTally because it is also reporting > memory consumption > and may be we could make everything better. (I just read my mails between > two houses fixes). > I will take more time this evening if I can. > Anyway thanks. I like these kinds of discussions. Because I learn stuff or > they make me think > and rethink what I think I know > > Stef > > SpaceTally uses allInstances for each class. [(SpaceTally new systemWideSpaceTally asSortedCollection: [:a :b | a spaceForInstances > b spaceForInstances]) asArray inspect] timeToRun 363332 on a slow machine. Could probably be made somewhat faster by keeping a count of all classes' instances during one pass. Senders of allSubInstances with their number of subclasses ---------------------------------------------------------- a MethodReference Behavior >> #inspectSubInstances->3396 a MethodReference Morph class >> #morphsUnknownToTheirOwners->221 a MethodReference Morph >> #morphsUnknownToTheirOwners->221 a MethodReference Set class >> #rehashAllSets->21 a MethodReference Set >> #rehashAllSets->21 a MethodReference UITheme class >> #closeExampleDialogs->6 a MethodReference UITheme >> #closeExampleDialogs->6 a MethodReference FT2Handle class >> #shutDown:->5 a MethodReference FT2Handle >> #shutDown:->5 a MethodReference Categorizer class >> #sortAllCategories->4 a MethodReference Categorizer >> #sortAllCategories->4 a MethodReference TTCFont class >> #recreateCache->2 a MethodReference TTCFont >> #recreateCache->2 a MethodReference Symbol class >> #rehash->2 a MethodReference Symbol >> #rehash->2 a MethodReference StrikeFont class >> #setupDefaultFallbackFont->2 a MethodReference StrikeFont >> #setupDefaultFallbackFont->2 a MethodReference WAProcessStatus >> #processes->0 a MethodReference Utilities class >> #closeAllDebuggers->0 a MethodReference Utilities >> #closeAllDebuggers->0 ...etc Morph morphsUnKnownToTheirOwners timeToRun is 10s; could be faster, but has no senders. Senders of allSubInstancesDo: with their number of subclasses ---------------------------------------------------------- a MethodReference Behavior >> #allSubInstances->3396 a MethodReference Behavior >> #allInstancesEverywhereDo:->3396 a MethodReference ClassDescription >> #updateInstancesFrom:->3395 a MethodReference WASqueakStatusItem >> #numberOfSessions->8 a MethodReference MCFileBasedRepository class >> #flushAllCaches->5 a MethodReference MCFileBasedRepository >> #flushAllCaches->5 a MethodReference PopUpMenu class >> #setMenuFontTo:->3 a MethodReference PopUpMenu class >> #initialize->3 a MethodReference PopUpMenu >> #setMenuFontTo:->3 a MethodReference PopUpMenu >> #initialize->3 a MethodReference ChangeList >> #selectConflictsWith->3 a MethodReference TTCFont class >> #initialize->2 a MethodReference TTCFont >> #initialize->2 a MethodReference StrikeFont class >> #shutDown->2 a MethodReference StrikeFont >> #shutDown->2 a MethodReference WARegistry class >> #clearAll->1 a MethodReference WARegistry >> #clearAll->1 a MethodReference ShortIntegerArray class >> #swapShortObjects->1 a MethodReference ShortIntegerArray >> #swapShortObjects->1 a MethodReference Preferences class >> #smartUpdatingChanged->1 a MethodReference Preferences class >> #setFlapsFontTo:->1 ...etc Metaclass is the sole sender of allInstancesEverywhereDo: Conclusion- there are no cases which clearly need attention, with the possible exception of Object>>allSubInstances It might be worth catching calls to #allSubInstances, #allSubInstancesDo: where subclasses size > say 100, as Martin mentioned. -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p4… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 21, 2009

Re: [Pharo-project] was "Re: About projects with Metacello"

by Damien Cassou

On Sun, Dec 20, 2009 at 8:32 PM, <csrabak(a)bol.com.br> wrote: > Is there a reason we keep both O2 and OB in parallel? Â Can't we > just get the best parts of one of the solutions and consider the > other as the "trunk" or mainstream for Pharo? Pharo must have the notion of Packages. This is a prerequisite of a good package browser. Unless we have that, O2 will be slow and won't be the default. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dec. 21, 2009

Re: [Pharo-project] About projects with Metacello

by Damien Cassou

On Sun, Dec 20, 2009 at 10:55 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Dale? Do we have xor for configuration ;) ? Even if it was the case, you asked me to install both. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dec. 21, 2009

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

by Nicolas Cellier

2009/12/21 Lukas Renggli <renggli(a)gmail.com>: > 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 > Of course, that would have been a nice option too (more general). Above code is from 1994, not sure what was the status of SmaCC at that time... In case of symbolic expressions, more agressive transformation could occur, like common subexpression elimination... (run on symbolic expression tree rather than AST, because knowing there would be no side effect). Nicolas > 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 > > _______________________________________________ > 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>: > Yes, it also works for aliased methods. > > It should be ... @ {#methodB -> #methodA} meaning methodB is an alias for > methodA > So, the pattern is: @ { #newName -> #oldName } hmm.. then there is no wonder, since i interpret it differently , assuming that pattern is: @ { #existingName -> #aliasedName } because, as to me , by reading this expression its more natural to think that operand to the left of '->' is the 'initial' or 'original' state, and to the right - intended state, but not reverse. Otherwise, maybe its worth to use an explicit & different selector: @ { #aliasedName <- #existingName }. And in #<- create something other than Association, which will make trait definitions a bit more error proof , by not allowing associations in composition. (just guessing) Btw, it would be good to assert at such point, saying to user that he attempts to make an alias of non-existing method. > Cheers, > Adrian > > -- Best regards, Igor Stasenko AKA sig.

Dec. 21, 2009