- Pharo-dev - lists.pharo.org

Handling error with PetitParser
by StÃ©phane Ducasse May 31, 2013

May 31, 2013

We would like to see if we can use PetitParser to build syntax hilighting and for this we need to see if there is a way to specify error handling. Does any of you know? So far we tried to use the RBSCanner but it does not really work for what we need Stef

1 0

No Internationalization (nor Multilingual) Project in bug tracker
by Nicolas Cellier May 31, 2013

May 31, 2013

Like in Squeak/Trunk I want to push UTF8 encoding in .mcz/snapshot/source.stand want to first create an InvalidUTF8 exception (Error) - so as to fallback to legacy encoding in error handling. What project do you suggest for classifying the fogbugz entry? Nicolas

3 3

[update 3.0] #30175
by Marcus Denker May 31, 2013

May 31, 2013

30175 ----- 10812 CommandlineTestRunner >> #stderr is not returning properly https://pharo.fogbugz.com/f/cases/10812 10807 Scanning wrong token produces DNU https://pharo.fogbugz.com/f/cases/10807 10809 Path>>isAbsoluteWindowsPath: can be optimized https://pharo.fogbugz.com/f/cases/10809 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-UI-MarcusDenker.68.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.161.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Tests-Core-MarcusDenker.2…

1 0

Re: [Pharo-dev] [Pharo-fuel] Corrupt BlockClosure
by Max Leske May 31, 2013

May 31, 2013

I can now reprocuce corrupt sessions. The trick is to debug DFSession>>numberOfMethodCalls: 1. start new session 2. debug "DFSession uniqueInstance printString" 3. step into #numberOfMehthodCalls 4. proceed 5. stop the session 5. right click on the new session in the session browser and click "Export session" 6. boom! The reason is of course, that now the compiled method of #numberOfMethodCalls is referenced by the session and will be serialized by Fuel and when Fuel gets to the corrupt BlockClosure, serialization fails. So the real question still is: how did that BlockClosure obtain a wrong start PC? What I find particularly interesting, is that even changing the method does not fix the BlockClosure. I added the line "Transcript show: 'foo'." before the block (so the block should get a new start PC). Then running the procedure detailed above still produced an open debugger. To illustrate that the block did indeed not get fixed I ran "BlockClosure allInstances select: [ :e | e startpc = 59 ]", with 59 being the new startPC ("55 <8F 01 00 03> closureNumCopied: 0 numArgs: 1 bytes 59 to 61"). The result does not include the block. Any ideas? Max On 24.05.2013, at 08:10, roberto.minelli(a)usi.ch wrote: > 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 1

StringMorph>>decimalPlaces:?
by StÃ©phane Ducasse May 30, 2013

May 30, 2013

Hi guys I wonder if we could not remove decimalPlaces: and friends from UpdatingStringMorph because UpdatingStringMorph is already not really good. so cleaning. Stef

1 0

New mailing list on Gmane
by Jimmie Houchin May 30, 2013

May 30, 2013

Hello, I frequently read the Pharo list on Gmane. Since the mailing list move to a new server, none of the messages are being sent to Gmane. There have been no new messages since May 15. It would be nice if the service to Gmane could be resumed. And if possible to populate the missed messages. Just wanted to let the list know. Thanks. Jimmie

2 2

[ANN]: ValidationRevisited (alpha)
by Sean P. DeNigris May 30, 2013

May 30, 2013

I got really inspired reading the extreme validation section of "A Mentoring Course on Smalltalk", Andres Valloud's OOP bible (see seandenigris.com/blog/?p=573) and enhanced a bit my port of ValidationRevisited. I made a short screencast of a little UI monitoring the health of a domain object in real-time. https://vimeo.com/67244280 If you want to play with the code (works on Pharo 2.0), doIt: Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'aMentoringCourseOnSmalltalk'; package: 'ValidationRevisited'; load. See ValidationDashboard class>>#openExample ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-ValidationRevisited-alpha-tp4690680.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

5 8