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

Re: [Pharo-dev] Is smart suggestions working in latest 30?

by Damien Cassou

On Fri, May 24, 2013 at 8:47 AM, Gisela Decuzzi <giseladecuzzi(a)gmail.com> wrote: > It should, Martin has the same problem and we found that is mapped to Cmd+1, > I was playing with shoruts and end in that mapping... I will change it > today. ctrl+1 is nice. Why do you want to use ctrl+t ? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 24, 2013

Re: [Pharo-dev] 1000 factori -> emtpy completion?

by Sven Van Caekenberghe

On 24 May 2013, at 08:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > This is strange that > when I type factori I get an empty completion. > > Stef That's because it is computing the answer in the background ;-) No seriously, it seems to think the type of the receiver is Number, not Integer, and #factorial is defined on Integer. Sven

May 24, 2013

Re: [Pharo-dev] Is smart suggestions working in latest 30?

by Gisela Decuzzi

It should, Martin has the same problem and we found that is mapped to Cmd+1, I was playing with shoruts and end in that mapping... I will change it today. 2013/5/24 stephane ducasse <stephane.ducasse(a)free.fr> > Because I cannot get the menu when I do cmd-t.. > > Stef > >

May 24, 2013

Fwd: [Pharo-fuel] Corrupt BlockClosure

by Max Leske

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

May 24, 2013

1000 factori -> emtpy completion?

by StÃ©phane Ducasse

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

May 24, 2013

It seems that recategorizing a method does not make the package dirty

by StÃ©phane Ducasse

Hi Is it me or It seems that recategorizing a method does not make the package dirty? Is there a fix that I can review? Stef

May 24, 2013

Is smart suggestions working in latest 30?

by stephane ducasse

Because I cannot get the menu when I do cmd-t.. Stef

May 24, 2013

Re: [Pharo-dev] clean, please

by btc＠openinworld.com

May 24, 2013

Re: [Pharo-dev] clean, please[SEC=UNCLASSIFIED]

by btc＠openinworld.com

May 24, 2013

Fwd: [Seaside] I am experiencing the following reported bug

by stephane ducasse

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 >

May 24, 2013