May 2013 - Pharo-dev - lists.pharo.org

1000 factori -> emtpy completion?
by StÃ©phane Ducasse May 24, 2013

May 24, 2013

This is strange that when I type factori I get an empty completion. Stef

2 1

Fwd: [Pharo-fuel] Corrupt BlockClosure
by Max Leske May 24, 2013

May 24, 2013

Begin forwarded message: > From: "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> > Subject: Re: [Pharo-fuel] [Pharo-dev] Corrupt BlockClosure > Date: 24. Mai 2013 08:10:19 MESZ > To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > Hi, > > Thanks all of you for interest ;) > > On May 24, 2013, at 7:15 AM, Max Leske <maxleske(a)gmail.com> > wrote: > >> I played around with reverting the method and serializing but that doesn't change anything (the existing BlockClosure is obviously not modified). >> Then I thought that maybe the method was changed during a running DFSession but still couldn't reproduce. > > Me neither!! > >> >> @Roberto >> Can you tell us anything about what you did befor / during / after running your session? > > Nope. Unfortunately I've a couple of "broken sessions" I cannot serialize because of that bug.. But all of them refers sooner or later to the DFSession>>#numberOfMethodCalls method. Dunno why. > >> @Roberto >> Is it possible to reproduce the stack with a new session? Or did this only happen once? > > I have no clue how to reproduce, but it did not happen only once. As I said, there are 3/4 sessions I couldn't export due to this SubscriptOutOfBounds. > > Cheers, > Roby > > >> >> >> On 24.05.2013, at 06:44, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 23.05.2013, at 22:58, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: >>>> theBlock instVar: 2 put: 43. >>>> The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession>>#numberOfMethodCalls), but I don't know why. >>> >>> Would it help to recompile the method? >>> >>>> I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? >>> >>> No, there was never a materialization of that session. >>> >>>> >>>> Camille >>>> >>>> On 23 mai 2013, at 21:02, Max Leske wrote: >>>> >>>>> Hi Marcus >>>>> >>>>> Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. >>>>> >>>>> The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. >>>>> To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: >>>>> >>>>> @Roberto >>>>> Is it possible to reproduce the stack with a new session? Or did this only happen once? >>>>> >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 >>>>>> Date: 23. Mai 2013 14:23:45 MESZ >>>>>> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>>>> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>>>> >>>>>> Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. >>>>>> Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) >>>>>> Thanks! >>>>>> >>>>>> >>>>>> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> What's the compiled method? Is it a special one? Which selector in which class? >>>>>> >>>>>> Max >>>>>> >>>>>> On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. >>>>>>> >>>>>>> I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). >>>>>>> >>>>>>> I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. >>>>>>> >>>>>>> Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Roby >>>>>>> >>>>>>> ############################################################################################ >>>>>>> ######################################### STACK#1 ########################################### >>>>>>> ########################################################################################### >>>>>>> CompiledMethod(Object)>>errorSubscriptBounds: >>>>>>> CompiledMethod(Object)>>at: >>>>>>> InstructionStream>>interpretNextInstructionFor: >>>>>>> CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... >>>>>>> BlockClosure>>on:do: >>>>>>> CompiledMethod>>abstractBytecodeMessageAt: >>>>>>> BlockClosure>>blockCreationBytecodeMessage >>>>>>> BlockClosure>>endPC >>>>>>> BlockClosure>>abstractBytecodeMessagesDo: >>>>>>> BlockClosure>>isClean >>>>>>> BlockClosure>>shouldBeSubstitutedByCleanCopy >>>>>>> BlockClosure>>fuelAccept: >>>>>>> FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: >>>>>>> FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... >>>>>>> FLLargeIdentityDictionary>>at:ifAbsent: >>>>>>> FLFullGlobalMapper>>mapAndTrace: >>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace: >>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace: >>>>>>> FLAnalysis>>mapAndTrace: >>>>>>> FLAnalysis>>run >>>>>>> FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... >>>>>>> FLAnalyzer>>analysisFor: >>>>>>> FLSerialization>>analysisStep >>>>>>> FLSerialization>>run >>>>>>> DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... >>>>>>> DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... >>>>>>> FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] >>>>>>> BlockClosure>>ensure: >>>>>>> FLEncoder class>>on:globalEnvironment:do: >>>>>>> DFSerializer(FLSerializer)>>serialize:on: >>>>>>> >>>>>>> >>>>>>> ############################################################################################ >>>>>>> ######################################### STACK#2 ########################################### >>>>>>> ############################################################################################ >>>>>>> Decompiler(Object)>>error: >>>>>>> Decompiler>>decompileBlock: >>>>>>> BlockClosure>>decompile >>>>>>> BlockClosure>>printOn: >>>>>>> BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] >>>>>>> String class(SequenceableCollection class)>>streamContents:limitedTo: >>>>>>> BlockClosure(Object)>>printStringLimitedTo: >>>>>>> BlockClosure(Object)>>printString >>>>>>> BlockClosure>>DoIt >>>>>>> Compiler>>evaluate:in:to:notifying:ifFail:logged: >>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... >>>>>>> BlockClosure>>on:do: >>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: >>>>>>> SmalltalkEditor>>evaluateSelection >>>>>>> PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] >>>>>>> PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] >>>>>>> TextMorphForEditView(TextMorph)>>handleEdit: >>>>>>> PluggableTextMorph>>handleEdit: >>>>>>> PluggableTextMorph>>doIt >>>>>>> SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] >>>>>>> BlockClosure>>cull: >>>>>>> BlockClosure>>cull:cull: >>>>>>> BlockClosure>>cull:cull:cull: >>>>>>> KMCategoryTarget>>completeMatch:buffer: >>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] >>>>>>> Array(SequenceableCollection)>>do: >>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: >>>>>>> KMKeymap>>onMatchWith:notify:andDo: >>>>>>> KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... >>>>>>> Set>>do: >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-fuel mailing list >>>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-fuel mailing list >>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> _______________________________________________ >>>>>> Pharo-fuel mailing list >>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>> >>>> >>> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

1 0

Fwd: [Seaside] I am experiencing the following reported bug
by stephane ducasse May 24, 2013

May 24, 2013

Hi philippe Can you explain to us what are the problems you have? Stef Begin forwarded message: > From: Philippe Marschall <philippe.marschall(a)gmail.com> > Subject: Re: [Seaside] Re: I am experiencing the following reported bug > Date: May 23, 2013 11:57:03 AM GMT+02:00 > To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> > Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> > > On Thu, May 23, 2013 at 12:42 AM, intrader <intrader(a)aol.com> wrote: >> Philippe Marschall <philippe.marschall <at> gmail.com> writes: >> >> >>> Which version of Seaside do you use? What's your version of >>> Seaside-Pharo-Development? >>> >>> Cheers >>> Philippe >>> >> Unfortunately a different component call: method gives me the error: 'Error: >> subscript is out of bounds:1 >> >> The same pattern of methods appears in the stack trace: it is part '[] in >> WAPharoWalkback>>tempNamesAndValuesIn: do:' >> >> I still need help with thia Pharo-Squeak bug. > > Can you upgrade to 3.0.7 or load Seaside-Pharo-Development-pmm.56? > > I did not find a reliable way to make stack introspection work on > Pharo closure VMs. So Seaside-Pharo-Development-pmm.56 removes stack > introspection entirely from the walkback. > > [1] http://code.google.com/p/seaside/issues/detail?id=689 > [2] http://code.google.com/p/seaside/wiki/Seaside307Changelog > > Cheers > Philippe > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

1 0

MC Filetree -- missing FiletreeURL ?
by Goubier Thierry May 24, 2013

May 24, 2013

I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line. Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

9 49

Corrupt BlockClosure
by Max Leske May 24, 2013

May 24, 2013

Hi Marcus Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: @Roberto Is it possible to reproduce the stack with a new session? Or did this only happen once? Cheers, Max Begin forwarded message: > From: Mariano Martinez Peck <marianopeck(a)gmail.com> > Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 > Date: 23. Mai 2013 14:23:45 MESZ > To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. > Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) > Thanks! > > > On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: > What's the compiled method? Is it a special one? Which selector in which class? > > Max > > On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: > > > Hi, > > > > While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. > > > > I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). > > > > I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. > > > > Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. > > > > Thanks in advance, > > Roby > > > > ############################################################################################ > > ######################################### STACK#1 ########################################### > > ########################################################################################### > > CompiledMethod(Object)>>errorSubscriptBounds: > > CompiledMethod(Object)>>at: > > InstructionStream>>interpretNextInstructionFor: > > CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... > > BlockClosure>>on:do: > > CompiledMethod>>abstractBytecodeMessageAt: > > BlockClosure>>blockCreationBytecodeMessage > > BlockClosure>>endPC > > BlockClosure>>abstractBytecodeMessagesDo: > > BlockClosure>>isClean > > BlockClosure>>shouldBeSubstitutedByCleanCopy > > BlockClosure>>fuelAccept: > > FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: > > FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... > > FLLargeIdentityDictionary>>at:ifAbsent: > > FLFullGlobalMapper>>mapAndTrace: > > FLPluggableSubstitutionMapper>>mapAndTrace: > > FLPluggableSubstitutionMapper>>mapAndTrace: > > FLAnalysis>>mapAndTrace: > > FLAnalysis>>run > > FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... > > FLAnalyzer>>analysisFor: > > FLSerialization>>analysisStep > > FLSerialization>>run > > DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... > > DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... > > FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] > > BlockClosure>>ensure: > > FLEncoder class>>on:globalEnvironment:do: > > DFSerializer(FLSerializer)>>serialize:on: > > > > > > ############################################################################################ > > ######################################### STACK#2 ########################################### > > ############################################################################################ > > Decompiler(Object)>>error: > > Decompiler>>decompileBlock: > > BlockClosure>>decompile > > BlockClosure>>printOn: > > BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] > > String class(SequenceableCollection class)>>streamContents:limitedTo: > > BlockClosure(Object)>>printStringLimitedTo: > > BlockClosure(Object)>>printString > > BlockClosure>>DoIt > > Compiler>>evaluate:in:to:notifying:ifFail:logged: > > SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... > > BlockClosure>>on:do: > > SmalltalkEditor>>evaluateSelectionAndDo: > > SmalltalkEditor>>evaluateSelection > > PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] > > PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] > > TextMorphForEditView(TextMorph)>>handleEdit: > > PluggableTextMorph>>handleEdit: > > PluggableTextMorph>>doIt > > SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] > > BlockClosure>>cull: > > BlockClosure>>cull:cull: > > BlockClosure>>cull:cull:cull: > > KMCategoryTarget>>completeMatch:buffer: > > KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] > > Array(SequenceableCollection)>>do: > > KMKeymap>>notifyCompleteMatchTo:buffer: > > KMKeymap>>onMatchWith:notify:andDo: > > KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... > > Set>>do: > > > > > > > > _______________________________________________ > > Pharo-fuel mailing list > > Pharo-fuel(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

2 3

Messy Configurations
by Camillo Bruni May 23, 2013

May 23, 2013

I recently spent some time to revise how to write Metacello Configurations. Observation: ============ - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser. Solution: ========= - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it What do you think?

8 16

MC should really write snaphsot/source.st in UTF8
by Nicolas Cellier May 23, 2013

May 23, 2013

http://stackoverflow.com/questions/16645848/squeak-monticello-character-enc… Let's kill this one, it's totally insane

6 15

May 23, 2013

Hi Gary We are working with alain on removing all the triggering event facilities from Object and porting it to announcement. Now I was wondering what is the ExclusiveWeakMessageSend. Stef

3 2

Latest vm on Ubuntu 8.04.4 LTS
by Sven Van Caekenberghe May 23, 2013

May 23, 2013

Guys, I am trying to run the latest (as in curl -L get.pharo.org | bash) vm on Ubuntu 8.04.4 LTS and it tells me $ ldd ./pharo-vm/pharo ./pharo-vm/pharo: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by ./pharo-vm/pharo) linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib32/libm.so.6 (0xf7769000) libdl.so.2 => /lib32/libdl.so.2 (0xf7765000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf774c000) libc.so.6 => /lib32/libc.so.6 (0xf75f8000) /lib/ld-linux.so.2 (0xf779c000) This machine was previously happy running all kinds of (older) VMs. Is there a way around this ? Is there a recent vm somewhere that does not require such a recent libc version (or whatever, I don't understand the error message, /lib32/libc.so.6 seems to be present, would that no be enough) ? Thx, Sven

6 11

Video: The Moose Roadmap
by Stephan Eggermont May 23, 2013

May 23, 2013

Another video from the MooseDay2013 Tudor Girba showing the Moose roadmap http://www.youtube.com/watch?v=2JCDS3OVnGM Stephan

1 0