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

[Pharo-project] Fwd: [BUG] [ :a | ] value: 1
by Lukas Renggli Dec. 17, 2009

Dec. 17, 2009

---------- Forwarded message ---------- From: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2009/12/16 Subject: Re: [BUG] [ :a | ] value: 1 To: Lukas Renggli <renggli(a)gmail.com>, Dan Ingalls <Dan.Ingalls(a)sun.com>, "L. Peter Deutsch" <lpd(a)major2nd.com> Cc: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Hi Lukas, Â Â Â can you forward my response to Pharo? Â TIA. On Wed, Dec 16, 2009 at 2:54 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Hi Eliot > > While working on a way to use the RB-AST with the standard compiler I > think I found a problem in your code. To reproduce evaluate the > following expression: > > Â Â [ :a | ] value: 1 > > According to my understanding that should return nil, not the first argument 1. > > The generated bytecode is: > > Â Â pushTemp: 0 > Â Â blockReturn > > I think it should be: > > Â Â pushConstant nil > Â Â blockReturn > > Cheers, > Lukas :) :) Â This is funny. Â VisualWorks has exactly the same bug^H^H^Hfeature. Â And if you look at the ANSI standard (ok, this is from the draft, but it is essentially the actual document) there is an exception for precisely this case, Â See the last sentence in section 3.4.4 Blocks: If a block has no <block body> or no <statements> in its <block body> then the value of the block is undefined. Which allows [] to be implemented as e.g. [Random new next]. Â In fact both VisualWorks and Squeak answer the last argument: [:a ] value: 1 1 [:a :b|] value: 1 value: 2 2 [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8 [:a | nil] value: 1 nil [:a :b| nil] value: 1 value: 2 nil At least it is consistent whether the block is inlined or not ;) 1+2 ifNotNil: [:arg|] 3 It as ever been so. Â This from Smalltalk-80 V2: BlockNode methods forÂ initialize-release arguments: argNodes statements: statementsCollection returns: returnBool from: encoder sourceEnd: sourceEnd "compile" sourceRange Â _ sourceEnd to: sourceEnd. arguments _ argNodes. statements _ statementsCollection size > 0 ifTrue: [statementsCollection] ifFalse: [argNodes size > 0 ifTrue: [statementsCollection copyWith: arguments last] ifFalse: [Array with: NodeNil]]. returns _ returnBool This from VW: BlockNode methods forÂ code generation emitBody: codeStream "The codeStream invokes this to compile the body of the block, including the final return." (body isEmpty and: [arguments isEmpty not]) ifTrue: [codeStream noteSourceStart: body. arguments last variable emitLocalReturn: codeStream from: body] ifFalse: [body emitLocalReturn: codeStream from: body] This from Squeak (my timestamp, but I just changed the _'s to :='s :) ) BlockNode methods forÂ initialize-release arguments: argNodes statements: statementsCollection returns: returnBool from: encoder "Compile." arguments := argNodes. statements := statementsCollection size > 0 ifTrue: [statementsCollection] ifFalse: [argNodes size > 0 ifTrue: [statementsCollection copyWith: arguments last] ifFalse: [Array with: NodeNil]]. optimized := false. returns := returnBool So at least it is easy to fix ;) Â The question you have to ask yourself is how much code is affected by this wafer thin change. I'm with you, I think this is a bug. Â But perhaps it was well thought through. Â What say you, Dan & Peter? Â Did y'all agonise over this? What say you Squeak & Pharo communities? Â Should we fix this or make it a preference ;) best Eliot P.S. Â I'm caught between wanting to fix it and wanting to let sleeping dogs lie. Â I'd like to know what all the other dialects do. Â If a substantial majority have the same curio I think we have to live with this, uh, ornament. Â Just to be clear, making it a preference is a sick joke on my part. > > -- > Lukas Renggli > http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch

6 5

[Pharo-project] Fwd: [BUG] [ :a | ] value: 1
by Torsten Bergmann Dec. 17, 2009

Dec. 17, 2009

Smalltalk/MT also returns nil -- Preisknaller: GMX DSL Flatrate fÃ¼r nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02

3 4

Re: [Pharo-project] [Vm-dev] Re: squeak VM 5.0
by Laval Jannik Dec. 17, 2009

Dec. 17, 2009

Hi Eliot, hi John, This is what I do: - create a class var in SystemDictionary - accessors (wordSize and wordSize:), the first one can initialize the variable if nil, the second is to modify the value in case of 64bits image. Maybe the second one could be integrated in System-Tracing file. - in CompiledMethod, initialPC use it. Maybe we could integrate it in pharoCore. Cheers, Jannik ======= 'From PharoCore1.1ALPHA of ''19 October 2009'' [Latest update: #11088] on 16 December 2009 at 11:06:21 pm'! IdentityDictionary subclass: #SystemDictionary instanceVariableNames: 'cachedClassNames ' classVariableNames: 'LastImageName LastQuitLogPosition LowSpaceProcess LowSpaceSemaphore MemoryHogs ShutDownList SpecialSelectors StartUpList StartupStamp SystemChanges WordSize ' poolDictionaries: '' category: 'System-Support'! !SystemDictionary class methodsFor: 'initialization' stamp: 'jannik.laval 12/16/2009 22:40'! wordSize WordSize ifNil: [WordSize := [SmalltalkImage current vmParameterAt: 40] on: Error do: [4]]. ^WordSize! ! !SystemDictionary class methodsFor: 'initialization' stamp: 'jannik.laval 12/16/2009 22:40'! wordSize: aNumber WordSize := aNumber! ! IdentityDictionary subclass: #SystemDictionary instanceVariableNames: 'cachedClassNames' classVariableNames: 'LastImageName LastQuitLogPosition LowSpaceProcess LowSpaceSemaphore MemoryHogs ShutDownList SpecialSelectors StartUpList StartupStamp SystemChanges WordSize' poolDictionaries: '' category: 'System-Support'! !CompiledMethod methodsFor: 'accessing' stamp: 'jannik.laval 12/16/2009 22:41'! initialPC "Answer the program counter for the receiver's first bytecode." ^ (self numLiterals + 1) * SystemDictionary wordSize + 1! ! ======= On Dec 16, 2009, at 18:32 , Eliot Miranda wrote: > Um, I'm _quite_ serious on insisting that Smalltalk wordSize be implemented in some way that caches the value in e.g. a class variable (or class inst var for max speed) that is reevaluated on startup. initialPC is evaluated a lot, e.g. once for every method in a "browse inst var refs". This is performance-critical, and going to a slow primitive to access something that can only change at startup is not a good idea. Please arrange that e.g. SystemDictionary gains a class var that caches the word size. > > On Wed, Dec 16, 2009 at 12:48 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > RIght and it's 12:30 am again, > > So the MAGIC fixes for the tracer to let you build a 64bit Pharo image are below. > No doubt they apply to closure based squeak trunk images. > > Could someone can be kind enough to integrate them into the current System-Tracing.2forPharo.cs ? > Then some people in Europe? can grab the current Pharo/Trunk image and convert it, and run some smoke tests. > BTW you need to use the Squeak.5.0.0.b9.64*64.app.zip to run a 64bit image > > Don't forget to convert you have to use a powerpc, or a squeak VM that is running as powerpc (via get info settings) on your macintel machine. > Still need someone to *fix* the systemtracer so it will run on intel machines. (Hint watch how it writes out integer data). ... > > Changes below: > > "This is the magic change, it's not the conversion of the image that is bad. It's the Smalltalk code assumption of is that 4 or 8 bytes? " > "There likely should be a Pharo/Squeak bug for this since it should be using wordSize not a magic number of 4" > > Eliot notes "Bravo! But Smalltalk wordSize has to be implemented in some way that caches the value in e.g. a class variable (or class inst var for max speed) that is reevaluated on startup." > > So I'll let someone propose/write a clever solution since the Smalltalk wordSize is computational heavy. > > CompiledMethod>>initialPC > "Answer the program counter for the receiver's first bytecode." > > ^ (self numLiterals + 1) * (Smalltalk wordSize) + 1 > > > "This next method isn't used much, should be. But the System-Tracing.2forPharo.cs trashes it with a ancient version. > This is the correct version" > > SystemDictionary>>wordSize > "Answer the size (in bytes) of an object pointer." > "Smalltalk wordSize" > ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4] > > "Changes to properly fix up BlockClosure in the SystemTracer2" > > SystemTracer2>>object: object allFieldsWithIndex: block collect: sequenceableCollectionClass > "Evaluate block against each of the pointer fields with index, and collect the results in an instance of sequenceableCollectionClass" > > | fixedSize results varSize nilResults blockvalue | > object isCompiledMethod ifTrue: > [results := sequenceableCollectionClass new: 1 + object numLiterals. > 1 to: 1 + object numLiterals do: > [:j | results at: j put: (block value: (object objectAt: j) value: j)]. > ^ results]. > > fixedSize := object class instSize. > varSize := object basicSize. > results := sequenceableCollectionClass new: fixedSize + varSize. > 1 to: fixedSize do: > [:j | results at: j put: (block value: (object instVarAt: j) value: j)]. > 1 to: varSize do: > [:j | > results at: fixedSize + j put: (block value: (object basicAt: j) value: fixedSize + j)]. > > object isContextPart ifTrue: > [(object instVarAt: 2) ifNotNil: > ["May need to adjust PC and startPC if changing wordSize..." > blockvalue := (object instVarAt: 2)+(self pcDeltaForMethod: object method). > results at: 2 put: (block value: blockvalue value: 2)]. > ((object isMemberOf: BlockContext) and: [object home notNil]) ifTrue: > [results at: 5 put: (block value: (object instVarAt: 5)+(self pcDeltaForMethod: object method) value: 5)]. > "Need to fill out the nils beyond the knowable end of stack" > nilResults := sequenceableCollectionClass new: object frameSize - object basicSize. > 1 to: nilResults size do: > [:j | nilResults at: j put: (block value: nil value: j)]. > ^ results , nilResults]. > object class = BlockClosure ifTrue: > ["May need to adjust PC and startPC if changing wordSize..." > blockvalue := (object instVarAt: 2)+(self pcDeltaForMethod: object method). > results at: 2 put: (block value: blockvalue value: 2)]. > ^ results > > > >> Eliot and I spent 30 minutes chatting about what is wrong. The conclusion is we *think* we are doing the right thing, > >> yet the Virtual Machine says the image is busted. So a quick fix is not apparent, and we'll dig more. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > >

2 2

[Pharo-project] squeak VM 5.0
by Alexandre Bergel Dec. 17, 2009

Dec. 17, 2009

Hi! I just tried Squeak.5.0.0.b9.64*64.app.zip, but I was not able to run a pharo core on it. I have a MacBookPro 10.5.8. I do not know whether this is helpful or not. Feel free to ask more info about my config. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

7 20

[Pharo-project] Fwd: [BUG] [ :a | ] value: 1
by Lukas Renggli Dec. 16, 2009

Dec. 16, 2009

---------- Forwarded message ---------- From: L Peter Deutsch <lpd(a)major2nd.com> Date: 2009/12/16 Subject: Re: [BUG] [ :a | ] value: 1 To: eliot.miranda(a)gmail.com Cc: renggli(a)gmail.com, Dan.Ingalls(a)sun.com, squeak-dev(a)lists.squeakfoundation.org Good Heavens. Â To think that that something like this would surface after all these years.... I agree with Lukas. Â The block should return nil. Â The ANSI standard is broken -- the fewer special cases a standard has, the better. I didn't write the Smalltalk source-to-bytecode compiler, and if I had, I would have made it return nil if I had had my wits about me. OTOH, Dan may know of a historical reason why things were done this way -- perhaps there's some fairly common usage pattern that I've forgotten that makes the return-the-last-argument definition worthwhile. I agree that changing this is likely to break code. Â All the same, I am somewhat in favor of changing it in the ANSI standard. Â If that is done, I would hope someone would create a tool to do a pass over Smalltalk source code and browse any occurrences of the problematic construct. Â (Fixing them automatically might not be a good idea, since the value that the block returns might not actually be used, and if not, no fix would be needed.) Fortunately, this is an example where it's easy, if a little unsightly, to write code so that it will work under either interpretation (by explicitly include the desired return value in the block). Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â L Peter Deutsch P.S. Writing standards is really very tricky. Â If one writes a standard too early, it's likely to get something important wrong simply from not enough experience; but if you write it too late, it may be impossible to get implementations to follow it, or the standard may have to compromise on quality to conform to the implementations. Â A depressing example of this is HTML5, where I'm told the standards committee pretty much caved to whatever the major browsers had actually done, regardless of how poorly designed it was. ---------------------------------------------------------------- -- Lukas Renggli http://www.lukas-renggli.ch

2 2

[Pharo-project] Package management info
by GeertClaes Dec. 16, 2009

Dec. 16, 2009

I tried to search for more info about the "Package management system" mentioned to be part of the next 1.1 Pharo milestone. Can someone point me to more info about this package management system? I also could not find that much info about MetaCello either. Any links to papers, presentation and/or video much appreciated. -- View this message in context: http://n2.nabble.com/Package-management-info-tp4176930p4176930.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 2

Re: [Pharo-project] [squeak-dev] Re: [BUG] [ :a | ] value: 1
by Stephen Pair Dec. 16, 2009

Dec. 16, 2009

On Wed, Dec 16, 2009 at 1:24 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > I like Peter's response. How about making it a preference? ;) ;) What I > mean is we replace the code by something that compiles code that either > raises an error or answers nil. y default the preference is set to generate > the error code. Then we force people to write [:arg| nil] because [:arg| ] > will generate a run-time error (with a verbose and helpful explanatory > comment). Then in a few months, years, decades we'll be in a position to > remove the preference and generate code that answers nil because all the > uses will have been caught. > > I can imagine wanting to keep the preference and turning it on when > importing code from other dialects for error checking. > > The downside to this approach is that empty blocks with arguments will > include the "nil" noise. But that;s very easy to remove automatically once > the putsch is stable. > Egads! I thought it was a really good joke at first, but now I realize you are half serious. Make it work right, fix all the code in the base image, maybe write something that can reveal places where this is done in a particular class or package, then publish it while reminding people of: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - Stephen

1 0

[Pharo-project] Fwd: [BUG] [ :a | ] value: 1
by Lukas Renggli Dec. 16, 2009

Dec. 16, 2009

---------- Forwarded message ---------- From: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2009/12/16 Subject: Re: [BUG] [ :a | ] value: 1 To: Lukas Renggli <renggli(a)gmail.com> Cc: Dan Ingalls <Dan.Ingalls(a)sun.com>, "L. Peter Deutsch" <lpd(a)major2nd.com>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org>, Pharo Development <pharo-project(a)lists.gforge.inria.fr> On Wed, Dec 16, 2009 at 9:44 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > > :) :) Â This is funny. Â VisualWorks has exactly the same bug^H^H^Hfeature. > > Â And if you look at the ANSI standard (ok, this is from the draft, but it is > > essentially the actual document) there is an exception for precisely this > > case, Â See the last sentence in section 3.4.4 Blocks: > > > > If a block has no <block body> or no <statements> in its <block body> then > > the value of the block is undefined. > > Ok, I did not check that document. I somehow expected that all empty > blocks would return nil. As do we all, which is why this is so horribly broken :) Â The sad thing is, we've been living with it for thirty years. > > > Which allows [] to be implemented as e.g. [Random new next]. Â In fact both > > VisualWorks and Squeak answer the last argument: > > [:a ] value: 1 1 > > [:a :b|] value: 1 value: 2 2 > > [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8 > > [:a | nil] value: 1 nil > > [:a :b| nil] value: 1 value: 2 nil > > At least it is consistent whether the block is inlined or not ;) > > 1+2 ifNotNil: [:arg|] 3 > > It as ever been so. > > Thank you for the additional insight. I learned something new on the > Smalltalk semantics today :-) > > I will fix my code then. > > > P.S. Â I'm caught between wanting to fix it and wanting to let sleeping dogs > > lie. Â I'd like to know what all the other dialects do. Â If a substantial > > majority have the same curio I think we have to live with this, uh, > > ornament. Â Just to be clear, making it a preference is a sick joke on my > > part. > > I think we'd better let it sleep. In my image I have 61 empty blocks > with one or more argument. Some of them might depend on that hidden > behavior. > I like Peter's response. Â How about making it a preference? ;) ;) What I mean is we replace the code by something that compiles code that either raises an error or answers nil. Â y default the preference is set to generate the error code. Â Then we force people to write [:arg| nil] because [:arg| ] will generate a run-time error (with a verbose and helpful explanatory comment). Â Then in a few months, years, decades we'll be in a position to remove the preference and generate code that answers nil because all the uses will have been caught. I can imagine wanting to keep the preference and turning it on when importing code from other dialects for error checking. The downside to this approach is that empty blocks with arguments will include the "nil" noise. Â But that;s very easy to remove automatically once the putsch is stable. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch

1 0

Re: [Pharo-project] [BUG] [ :a | ] value: 1
by Lukas Renggli Dec. 16, 2009

Dec. 16, 2009

> :) :) Â This is funny. Â VisualWorks has exactly the same bug^H^H^Hfeature. > Â And if you look at the ANSI standard (ok, this is from the draft, but it is > essentially the actual document) there is an exception for precisely this > case, Â See the last sentence in section 3.4.4 Blocks: > > If a block has no <block body> or no <statements> in its <block body> then > the value of the block is undefined. Ok, I did not check that document. I somehow expected that all empty blocks would return nil. > Which allows [] to be implemented as e.g. [Random new next]. Â In fact both > VisualWorks and Squeak answer the last argument: > [:a ] value: 1 1 > [:a :b|] value: 1 value: 2 2 > [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8 > [:a | nil] value: 1 nil > [:a :b| nil] value: 1 value: 2 nil > At least it is consistent whether the block is inlined or not ;) > 1+2 ifNotNil: [:arg|] 3 > It as ever been so. Thank you for the additional insight. I learned something new on the Smalltalk semantics today :-) I will fix my code then. > P.S. Â I'm caught between wanting to fix it and wanting to let sleeping dogs > lie. Â I'd like to know what all the other dialects do. Â If a substantial > majority have the same curio I think we have to live with this, uh, > ornament. Â Just to be clear, making it a preference is a sick joke on my > part. I think we'd better let it sleep. In my image I have 61 empty blocks with one or more argument. Some of them might depend on that hidden behavior. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

2 1

Re: [Pharo-project] Package management info
by Dale Henrichs Dec. 16, 2009

Dec. 16, 2009

These are two places to get started with Metacello: http://code.google.com/p/metacello/ http://groups.google.com/group/metacello If you have questions, join the mailing group and ask away. Dale ----- "GeertClaes" <geert.wl.claes(a)gmail.com> wrote: | I tried to search for more info about the "Package management system" | mentioned to be part of the next 1.1 Pharo milestone. Can someone | point me | to more info about this package management system? | | I also could not find that much info about MetaCello either. Any | links to | papers, presentation and/or video much appreciated. | -- | View this message in context: | http://n2.nabble.com/Package-management-info-tp4176930p4176930.html | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0