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

Re: [Pharo-dev] A screenshot we should remind today

by Frank Shearar

On 31 May 2013 09:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 31 May 2013, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > happy nostalgia :-) > > Cheers, > -- Pavel > <st80-19830531.png> > > > +1 > > It is amazing that so much of it still lives on. > > We've come a long way and the future is bright ;-) > > Note how also the collaboration model changed: from 'All right reserved' to MIT, from one lab to the whole world. I agree with the sentiment, but "All rights reserved" is a copyright thing, not a licence thing [1]. Pharo _still_ has "all rights reserved". It's just that Pharo doesn't need to say so because the Berne Convention makes it implicit. So it's more that the copyright is "The Pharo Project and Contributors" than "some random private corporation" that's the important part! frank [1] http://en.wikipedia.org/wiki/All_rights_reserved

May 31, 2013

Re: [Pharo-dev] A screenshot we should remind today

by Sven Van Caekenberghe

On 31 May 2013, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > happy nostalgia :-) > > Cheers, > -- Pavel > <st80-19830531.png> +1 It is amazing that so much of it still lives on. We've come a long way and the future is bright ;-) Note how also the collaboration model changed: from 'All right reserved' to MIT, from one lab to the whole world. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

May 31, 2013

[update 3.0] #30175

by Marcus Denker

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…

May 31, 2013

Re: [Pharo-dev] [amber-lang] Amber's new stepping debugger

by Norbert Hartl

Great work! Norbert Am 30.05.2013 um 23:26 schrieb Nicolas Petton <petton.nicolas(a)gmail.com>: > Hi guys! > > Today I was able to debug Amber code with a stepping debugger for the first time! > The debugger is based on an AST interpreter with a small stack implementation. > > Here's a short video of the debugger in action: > https://www.dropbox.com/s/43mli1wwbdwj5kx/amber-debugging.mov > > While it's an early version, it is already usable :) > > cheers, > nico

May 31, 2013

Re: [Pharo-dev] Reflectivity beta

by Norbert Hartl

Am 31.05.2013 um 09:48 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > On May 31, 2013, at 9:04 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Sounds great! What happens if a method is recompiled. All metalinks are gone then? >> > > Yes, because they have no semantic knowledge other than the AST node. > > Starting to match trees to put back links is difficult *and* does not work really, either. > > E.g if I put a link > on > self foo. > > and then add a second > self foo. > > just in front, where will the retained link be? > > And them, the new method could be completely different. Maybe the user putting the link did not want it > on all sends called foo, but on all self sends? No way to tellâ¦ they just do not carry the intention of the developer. > For that one needs higher levels to take care. > > The idea is that the links are low-level, you always use them in a managed way. E.g. a line-based > breakpoint would be manage by the debugger, the links in an AOP system would be managed by the > PointCut (which declaratively specifies where to put links). Edit method --> level above puts links again. > > In the *long* term I want Pharo to not manipulate text but ASTs directly, in this case it is easy to maintain the > links as the AST does not change. But this is Pharo5 or so ;-) > But even that does not remove then need of higher levels. Because if the user put links on all ivar accesses, the > code I add will not magically have those links even in this case, because the existing do not encode the intention > "I want links on all Ivar access". I don't think that editing the AST directly solves this problems. You can always remove things in a way so that bringing them back makes you loose the meta information. But then it maybe is not necessary to put something like that as a AST feature. If I programmatically annotate AST nodes I will have some code that does it. Then I only need to know when some method has changed and I can reapply the annotations/metalinks. To preserve exisiting metalinks I would have to know before and after a method has changed so I'm able to reapply the exact same thing there. Besides Announcements I could add metalinks to the compiler that triggers my code to manage metalinks of my code. There is always a way to go meta. Wonderful! Time for me to make my first 3.0 tests :) Norbert

May 31, 2013

A screenshot we should remind today

by Pavel Krivanek

happy nostalgia :-) Cheers, -- Pavel

May 31, 2013

Re: [Pharo-dev] Running coverage breaks the VM

by Guillermo Polito

I'll make a summary from what I understand... Maybe we should move this discussion to the VM list, but I'm not sure. - Igor made changes to support the primitive 220 - those changes may try to activate a non-method object - I added a check to tell if it is a compiled method or not to the new code, so if it's not it flows through the old method handling (which uses the primitiveFunctionPointer I assume right from the CoInterpreter implementation) This, I see should be taken into account into #internalExecuteNewMethod and #executeNewMethod, which are preeeeeeety similar and both have the same change :). Maybe I'm making nonsense again, It's difficult to say to me. I just want to help fixing this. Tx!!! Guille On Fri, May 31, 2013 at 9:28 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Actually, from CoInterpreter: > > addNewMethodToCache: class > "Override to refuse to cache other than compiled methods. > This protects open PICs against having to test for compiled methods." > (objectMemory isOopCompiledMethod: newMethod) ifFalse: > [primitiveFunctionPointer := #primitiveInvokeObjectAsMethod. > ^self]. > super addNewMethodToCache: class > > > On Fri, May 31, 2013 at 9:20 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Ahh, that's why the code in CoInterpreter I was looking didn't match the >> C code :D. Was looking at the wrong place, hehe. >> >> Igor, why do you say that this method should be reached only with vanilla >> compiled methods? From the comment I understand >> >> "For interpreter performance and to ease the objectAsMethod >> implementation eagerly >> evaluate the primtiive, i.e. if the method is cogged and has a >> primitive /do not/ evaluate >> the machine code primitive, just evaluate >> primitiveFunctionPointer directly." >> >> And in #addNewMethodToCache: there is as a first statement: >> >> [...] >> (objectMemory isOopCompiledMethod: newMethod) >> ifTrue: >> [primitiveIndex := self primitiveIndexOf: newMethod. >> primitiveFunctionPointer := self functionPointerFor: primitiveIndex >> inClass: class] >> ifFalse: >> [*primitiveFunctionPointer := #primitiveInvokeObjectAsMethod*]. >> [...] >> >> So I'd say that both objects as methods and primitives are kind of >> handled in the same way after? >> >> >> >> On Fri, May 31, 2013 at 2:27 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> On 30 May 2013 20:06, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> > Ok, I was playing with flushing caches and stuff... Its still a bit >>> obsure >>> > to me why the example in the workspace works and the code coverage >>> doesnot. >>> > >>> > However, I managed to hack the VM to make it work :). >>> > >>> > It looks like the VM is treating the objects as methods, as cog >>> methods. So >>> > I added the following validation in the commonSend: >>> > >>> > methodHeader2 = longAt((GIV(newMethod) + BaseHeaderSize) + >>> (HeaderIndex << >>> > ShiftForWord)); >>> > >>> > if (isCogMethodReference(methodHeader2) && >>> > isCompiledMethodHeader(methodHeader2)) { >>> > >>> > /* begin externalizeIPandSP */ >>> > >>> > assert((((usqInt)localIP)) != (ceReturnToInterpreterPC())); >>> > >>> > GIV(instructionPointer) = oopForPointer(localIP); >>> > >>> > GIV(stackPointer) = localSP; >>> > >>> > GIV(framePointer) = localFP; >>> > >>> > executeCoggedNewMethodmethodHeader(1, methodHeader2); >>> > >>> > } >>> > >>> > >>> > And it works :). >>> > >>> > I cc Eliot, so maybe he has an idea... >>> > >>> I touched this code. >>> >>> Original: >>> >>> CoInterpreter>>internalExecuteNewMethod >>> <inline: true> >>> "For interpreter performance and to ease the objectAsMethod >>> implementation eagerly >>> evaluate the primtiive, i.e. if the method is cogged and has a >>> primitive /do not/ evaluate >>> the machine code primitive, just evaluate >>> primitiveFunctionPointer directly." >>> primitiveFunctionPointer ~= 0 ifTrue: >>> [| succeeded | >>> self isPrimitiveFunctionPointerAnIndex ifTrue: >>> [^self internalQuickPrimitiveResponse]. >>> "slowPrimitiveResponse may of course context-switch. >>> If so we must >>> reenter the >>> new process appropriately, returning only if we've >>> found an >>> interpreter frame." >>> self externalizeIPandSP. >>> succeeded := self slowPrimitiveResponse. >>> instructionPointer = cogit ceReturnToInterpreterPC >>> ifTrue: >>> [instructionPointer := self iframeSavedIP: >>> framePointer]. >>> self internalizeIPandSP. >>> succeeded ifTrue: >>> [self return: self popStack toExecutive: true. >>> self browserPluginReturnIfNeeded. >>> ^nil]]. >>> "if not primitive, or primitive failed, activate the method" >>> (self methodHasCogMethod: newMethod) >>> ifTrue: [self iframeSavedIP: localFP put: localIP >>> asInteger. >>> instructionPointer := cogit >>> ceReturnToInterpreterPC. >>> self externalizeFPandSP. >>> self activateCoggedNewMethod: true. >>> self internalizeIPandSP] >>> ifFalse: [self internalActivateNewMethod] >>> >>> Now in subclass (NBCoInterpreter) >>> i made this: >>> >>> internalExecuteNewMethod >>> <inline: true> >>> "For interpreter performance and to ease the objectAsMethod >>> implementation eagerly >>> evaluate the primtiive, i.e. if the method is cogged and has a >>> primitive /do not/ evaluate >>> the machine code primitive, just evaluate >>> primitiveFunctionPointer directly." >>> >>> | methodHeader | >>> >>> methodHeader := self rawHeaderOf: newMethod. >>> >>> (self isCogMethodReference: methodHeader) ifTrue: [ >>> self externalizeIPandSP. >>> self executeCoggedNewMethod: true methodHeader: >>> methodHeader. >>> "we never reach here" >>> ]. >>> >>> primitiveFunctionPointer ~= 0 ifTrue: >>> [| succeeded | >>> self isPrimitiveFunctionPointerAnIndex ifTrue: >>> [^self internalQuickPrimitiveResponse]. >>> "slowPrimitiveResponse may of course context-switch. >>> If so we must >>> reenter the >>> new process appropriately, returning only if we've >>> found an >>> interpreter frame." >>> self externalizeIPandSP. >>> succeeded := self slowPrimitiveResponse. >>> instructionPointer = cogit ceReturnToInterpreterPC >>> ifTrue: >>> [instructionPointer := self iframeSavedIP: >>> framePointer]. >>> self internalizeIPandSP. >>> succeeded ifTrue: >>> [self return: self popStack toExecutive: true. >>> self browserPluginReturnIfNeeded. >>> ^nil]]. >>> "if not primitive, or primitive failed, activate the method" >>> (self methodHasCogMethod: newMethod) >>> ifTrue: [self iframeSavedIP: localFP put: localIP >>> asInteger. >>> instructionPointer := cogit >>> ceReturnToInterpreterPC. >>> self externalizeFPandSP. >>> self activateCoggedNewMethod: true. >>> self internalizeIPandSP] >>> ifFalse: [self internalActivateNewMethod] >>> >>> === >>> The intent of change was: >>> - if method is cog method, execute it (the jited code takes care to >>> call primitive, if it there) >>> >>> The old code logic was: >>> - run primitive if it there >>> - and only then, if no prim/or prim failed, try to run a jited code >>> (but entry point is to the first bytecode of method, >>> not to its start) >>> >>> This (old) logic prevents from using primitive 220 properly, because >>> it is a "meta-primitive" - a marker >>> that says that given method should: >>> - always be jited >>> - actual primitive is taken by copying machine code from compiled >>> method trailer into CogMethod's primitive section. >>> Therefore executing prim 220 (a C function) ~~ invoking method's >>> primitive (a machine code generated by image). >>> >>> Still i cannot understand why code reaching this point, when a result >>> of lookup is not a compiled method, but arbitrary object, because >>> everything even in original code says: VM enters this method only if >>> it found 100% vanilla guaranteed CompiledMethod, and not something >>> which pretends to be it. >>> As i understand , the logic to handle object-as-method is in method >>> lookup.. but not in internalExecuteNewMethod, because VM can "execute" >>> the only thing it knows, and it is CompiledMethod. >>> >>> Your test says, that Cog does something extra (some magic, which i >>> failed to grasp) with object-as-method, >>> like generating special kind of CogMethod which sends #run:as:in: >>> message to it. >>> >>> I would like to hear Eliot's comments on this. >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >

May 31, 2013

Re: [Pharo-dev] [Pharo-fuel] Corrupt BlockClosure

by Max Leske

Bump. Doesn't anybody feel that corrupt blocks are a problem? IMHO that's something that should *never* happen. Max On 25.05.2013, at 17:56, Max Leske <maxleske(a)gmail.com> wrote: > 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 >

May 31, 2013

Re: [Pharo-dev] Amber's new stepping debugger

by XumuK

Finally! It will be very useful! Ð¿ÑÑÐ½Ð¸ÑÐ°, 31 Ð¼Ð°Ñ 2013 Ð³., 1:26:01 UTC+4 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ nicolas petton Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > Hi guys! > > Today I was able to debug Amber code with a stepping debugger for the > first time! > The debugger is based on an AST interpreter with a small stack > implementation. > > Here's a short video of the debugger in action: > https://www.dropbox.com/s/43mli1wwbdwj5kx/amber-debugging.mov > > While it's an early version, it is already usable :) > > cheers, > nico

May 31, 2013

Re: [Pharo-dev] Reflectivity beta

by Tudor Girba

Indeed, this would be fantastic :) Doru On Fri, May 31, 2013 at 9:45 AM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > > On 31 mai 2013, at 09:03, Norbert Hartl wrote: > > Sounds great! What happens if a method is recompiled. All metalinks are > gone then? > > > Yes indeed. If you have the method: > foo > self bar > with a metalink on the message node and you recompile it to: > foo > self > qux; > bar; > bar. > > then it is hard to tell which node(s) should adopt the metalink because > there is no way to tell which #bar message of the second version is the one > from the first version. > I would love to have an editor where you manipulates ast nodes directly. > With such an editor the developer would have feedback of where the > metalinks are. > In the underlying model, AST nodes would have an equivalence relation to > say whether two nodes are different versions the same or not. > This model could also be really useful for versioning and diff too. > > > Norbert > > Am 30.05.2013 um 18:15 schrieb Camille Teruel <camille.teruel(a)gmail.com>: > > Hello everyone, > > Reflectivity beta is out ! > > Reflectivity is a tool that permit to annotate AST nodes with "metalinks". > You can put metalinks at different "positions": > > - before: the metalink is executed before the node > - instead: the metalink is executed instead the node > - after: the metalink is executed after the node > - onError: the metalink is executed only if the execution of the node > raises an error > - onSuccess: the metalink is executed only if the execution of the > node raises no error > > > When you put metalinks on some node of a method's AST, a wrapper is > installed in place of the method. When executed, this wrapper compiles an > expanded version of the AST that takes metalinks into account and install > the resulting compiled method. > > Examples: > > increaseAllNumbersIn: aCompiledMethod > "A method that increases all numbers in aCompiledMethod" > aCompiledMethod reflectiveAST > forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ] > putInstead: [ :node | RFMetalink fromExpression: (node value + 1) asString > ]. > > removeMetalinksIn: aCompiledMethod > aCompiledMethod reflectiveAST removeAllMetalinks > > In nautilus, you have a menu entry called 'Edit metalinks' that permit to > edit the metalinks of the node corresponding to the selected piece of code. > As an example use case, another entry called 'Put breakpoint' adds a > metalink that corresponds to 'Halt now' before the selected node. > > Remember that it is a beta, so you might find errors and things are likely > to change. > > You can load Reflectivity with: > > Gofer it > smalltalkhubUser: 'RMoD' project: 'Reflectivity'; > configuration; > loadDevelopment > > Or you can download it from RMoD's CI: > https://ci.inria.fr/rmod/job/Reflectivity/ > > Camille > > > -- www.tudorgirba.com "Every thing has its own flow"

May 31, 2013