November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] News about FastTable

by Thierry Goubier

Hi Cyril, more feedback about FTTree and #exampleTree1: - Moving the reject: before the sort: in ProtoObject allSubclasses cuts 40% of the time to run the example (-400ms) - Replacing all the asString by name divides that time by 9 (-900ms) Overall runtime went from > 1000ms to a bit above 100ms Class>>#asString is really, really slow :( Thierry Le 18/11/2015 10:53, Ferlicot D. Cyril a Ã©crit : > Hi everyone! > > I just wanted to say that I added a first version of Tree in FastTable > and I corrected some bugs. > > If someone want to try it and give some feedback you can see some > examples on the latest Pharo 5 in FTExamples class. > > With Usman we also worked on the glamour version of FastTable begun by > Esteban. > You can see some examples of FastList, FastTable, FastOutlineList and > FastTree in the GLMExamplesBrowser after executing this: > > (ConfigurationOfFastTable project version: #stable) load: #glamour > > Every feedback is welcome :) >

Nov. 20, 2015

Re: [Pharo-dev] Recovering _lost_ changes

by Yuriy Tymchuk

> On 20 Nov 2015, at 17:52, Skip Lentz <skip.lentz(a)inria.fr> wrote: > > Hi, > >> On Nov 20, 2015, at 5:27 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> is Epicea integrated already? > > No, not yet I think. > >> If so, is it possible to apply all the changes to code (without doits) since the last image save? I think that it should be really helpful because searching for changes and cherry-picking them is a pain. > > You can see the lost changes in the âOld sessionsâ browser (in the World menu). You have to then open the appropriate session, the timestamp shows when they were last modified. Open the one when you crashed the image, or whatever happened. This will open the log browser. I cannot find âOld sessionsâ. Where is it? Is it something new, or itâs âTools > Recover lost changesâ¦" thing that was always there? Cheers. Uko > > As of now you have to manually select all events (using shift you can select a range of events in the log).Then you have to redo them in one go by right clicking the selection. > Double check the changes for the time being as the redoing and undoing functionality is still being tested. For example, right now you will get an error when you redo (or undo) a class comment change. I will try to fix this bug right now. > >> Later this can be improved, so before the changes are applied you see the condensed diff. > > Yea that would be nice.. Also functionality for in the special case of recovering changes should really be there.. > > Skip

Nov. 20, 2015

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

by Eliot Miranda

Hi Nicolai, On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > GTDummyExamples class > d: anInteger > <gtExample> > <label: 'Dummy #d:, depends #c:'> > <description: 'should raise an exception as the argument is not > anInteger'> > <depends: #c:> > <raises: Literal constant expected -> MessageNotUnderstood> > > ^ 1 + anInteger > > The old Parser complains about the class name "MessageNotUnderstood" used > as a pragma > argument without being a string or symbol > > Opal does not complain > > Is Opals behavior intended ? > IMO no. The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g. addressField <primitive: 'primAddressField' module: 'IA32ABI' error: errorCode> ^self primitiveFailed instead of addressField <primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'> ^self primitiveFailed The issues are class reference, class redefinition, class removal etc. I guess we could extend the pragma syntax to allow class references but there's a lot of impact. I would prefer if we keep things restricted. There's nothing to stop one using a symbol and mapping it to a class name, e.g. GTDummyExamples class d: anInteger <gtExample> <label: 'Dummy #d:, depends #c:'> <description: 'should raise an exception as the argument is not anInteger'> <depends: #c:> <raises: #MessageNotUnderstood> ^ 1 + anInteger Also, I *hate* this style of pragma. Why not GTDummyExamples class d: anInteger <gtExampleLabel: 'Dummy #d:, depends #c:' description: 'should raise an exception as the argument is not anInteger' depends: #c: raises: #MessageNotUnderstood> ^ 1 + anInteger ? That's how the system is designed to be used. Then the message can be implemented by a builder which performs the selector from a visitor. >From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 > > Cascading message sends to super. > > Compiler refuses to compile > super > initialize; > setListProperties > > > It looks like Opal would compile this to > > super initialize. > super setListProperties. > > Intended ? Do we want to keep it? > > NBNativeCodeGen > parseOptions: optionsArray > uses association symbol -> block instead of block -> block > for caseOf arguments. > The old parser does not accept this. > > > -- _,,,^..^,,,_ best, Eliot

Nov. 20, 2015

Differences Compiler vs. OpalCompiler (or parser)

by Nicolai Hess

GTDummyExamples class d: anInteger <gtExample> <label: 'Dummy #d:, depends #c:'> <description: 'should raise an exception as the argument is not anInteger'> <depends: #c:> <raises: Literal constant expected -> MessageNotUnderstood> ^ 1 + anInteger The old Parser complains about the class name "MessageNotUnderstood" used as a pragma argument without being a string or symbol Opal does not complain Is Opals behavior intended ? >From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 Cascading message sends to super. Compiler refuses to compile super initialize; setListProperties It looks like Opal would compile this to super initialize. super setListProperties. Intended ? Do we want to keep it? NBNativeCodeGen parseOptions: optionsArray uses association symbol -> block instead of block -> block for caseOf arguments. The old parser does not accept this.

Nov. 20, 2015

Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil

by Nicolai Hess

Any idea how to solve this: 16961 <https://pharo.fogbugz.com/f/cases/16961/Unable-to-accept-changes-in-SyntaxE…> Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil and 16723 <https://pharo.fogbugz.com/f/cases/16723/File-in-a-file-with-an-error-does-n…> File in a file with an error does not set the doitFlag well If you file in some code that with syntactic errors, you can not fix the code from within SyntaxErrorDebugger because 1. the doitflag is nil, and If we would change this, init it with true... 2. ... the category is nil >From where it is used and comments like: notify: message at: location in: code self flag: #hack. "Should use the new OPalWarnings directly instead of recreating a SyntaxErrorNotification" SyntaxErrorNotification inClass: STCommandLineHandler category: nil withCode: code doitFlag: nil errorMessage: message location: location. it looks like the usage for SyntaxErrorNotification should be cleaned reworked, any ideas what to do? I can not find a Opal OCSytaxEror or something like this. And I don't understand the workflow of raising and catching and reraising SyntaxErrorNotifications.

Nov. 20, 2015

Re: [Pharo-dev] Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Nicolai Hess

2015-11-18 13:53 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Thanks Nicolai. Our monkey say it was success :) > Do you think Marcus should review it? or you confident enough? > > Now there is a bug tracker entry for pharo 4.0 too, and a fix, ready for testing. 17057 <https://pharo.fogbugz.com/f/cases/17057/BackPort-Pharo4-13854-frameSize-cal…> BackPort Pharo4: 13854 frameSize calculated wrongly for #lineSegmentsDo: > Cheers, > > On Wed, Nov 18, 2015 at 6:43 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2015-11-17 14:21 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> Hi Nicolai, >>> Thanks for sharing an updated cs. I can confirm that this version DOES >>> work and fixes my VM crash as well. >>> I have updated https://pharo.fogbugz.com/f/cases/13854 >>> >>> Thanks Nicolai!! >>> >> >> Hi Mariano, >> I am glad that it works! >> I reviewed the fix again (wasn't sure if all changes were needed - but >> yes they are) and added a slice for issue 13854. >> If it passes the tests and works in Pharo 5.0, we can create another >> issue and slice for Pharo 4.0 too. >> >> nicolai >> >> >> >>> >>> On Tue, Nov 17, 2015 at 6:36 AM, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> 2015-11-17 1:35 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> : >>>> >>>>> >>>>> >>>>> On Mon, Nov 16, 2015 at 8:41 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> 2015-11-16 22:16 GMT+01:00 Mariano Martinez Peck < >>>>>> marianopeck(a)gmail.com>: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 16, 2015 at 5:37 PM, Mariano Martinez Peck < >>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> So I found out the exact method that is causing the VM crash. If I >>>>>>>> compile the method with Opal, it crashes the VM when I execute the code >>>>>>>> that use that method. If I compile it with old compiler, the code does work >>>>>>>> correctly. >>>>>>>> >>>>>>>> I tried comparing both compiled methods compiled from both >>>>>>>> Compilers and I cannot see real differences. They both seem to have similar >>>>>>>> (same?) bytecodes, literals, decompiled string, etc. The only difference I >>>>>>>> see is in #frameSize (old compiler one is 16 while Opal one is 56). >>>>>>>> Any idea what else can I check/compare? >>>>>>>> >>>>>>>> I also tried in Pharo 5.0 but same results. >>>>>>>> >>>>>>>> Thanks in advance, >>>>>>>> >>>>>>>> >>>>>>> OK, it seems my issue may be related to: >>>>>>> https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-li… >>>>>>> But the attached cs in there does NOT fixes mine. >>>>>>> >>>>>> >>>>>> You need to: >>>>>> switch to old compiler in settings >>>>>> >>>>> >>>>> I was doing that via >>>>> >>>>> Smalltalk compilerClass: XXX. >>>>> >>>>> (I didn't know there was setting). >>>>> >>>>> >>>>>> load change set fix_closure_stack_frame_size_computation.1.cs (not >>>>>> fix_closure_stack_frame_size_computation.2.cs!) >>>>>> switch back to opal >>>>>> recompile all >>>>>> >>>>> >>>>> Yes, I did that. >>>>> >>>>> >>>>>> But the change set is old, and does not work for recent images (not >>>>>> even for pharo 4.0 release), because there are many >>>>>> changes for the bytecodegenerator. >>>>>> >>>>> >>>>> Uhhhh. Yes, I saw some. For example, i changed from >>>>> IRAbstractBytecodeGenerator to IRBytecodeGenerator >>>>> >>>>> Do you think we can re-create your fix with latest 4.0 or 5.0 so that >>>>> I can see if the issue was the same? >>>>> >>>> >>>> >>>> you can try this one, (I just changed all the code that makes this run >>>> for pharo 4, but I need more time to check if all of >>>> this code is necessary - and correct) : >>>> fix_closure_stack_size_4.0.cs (tested with Pharo 4.0 40624). >>>> >>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I can confirm it's a problem with the number of temp vars defined. >>>>>>> As soon as I remove any of the temp vars, it works again. >>>>>>> >>>>>>> The method is this (a bit ugly, yes) pasted below. >>>>>>> But the key point is: *As soon as I remove ANY tempVar the code >>>>>>> starts to work again.* >>>>>>> >>>>>>> Any clues? >>>>>>> >>>>>>> createZacksAccountingRulesFromTable: t1 >>>>>>> | t2 t3 t4 | >>>>>>> t2 := FaUserContextInformation current dbAccessor >>>>>>> db: 'zacks' >>>>>>> getTableAccessorOn: t1 >>>>>>> indexOn: nil. >>>>>>> t3 := OrderedCollection new. >>>>>>> t4 := FaFileTranscript named: 'create-zacks-rules.txt'. >>>>>>> FaApplicationDB session >>>>>>> inUnitOfWorkDo: [:t5 | >>>>>>> | t6 | >>>>>>> t6 := FaUserContextInformation current userDisplayName. >>>>>>> t2 >>>>>>> doWithRowDictionaries: [:t7 | (t7 at: 'label') >>>>>>> == FaNullDatum instance >>>>>>> ifFalse: [{{'Annual'. 'ZACKS_A_'}. {'Quarterly'. 'ZACKS_Q_'}} >>>>>>> do: [:t8 | >>>>>>> *| t9 t10 t11 t12 t13 t14 t15 t16 t17 t18 |* >>>>>>> t4 crLog: t8 first. >>>>>>> t9 := t8 at: 1. >>>>>>> t16 := t7 at: 'label'. >>>>>>> t18 := t7 at: 'TTM'. >>>>>>> t10 := t7 at: 'quuveKeyEquivalent'. >>>>>>> t12 := (t7 at: 'zacksKey') asUppercase. >>>>>>> t13 := 'ZACKS_' , t12. >>>>>>> t14 := 'ZACKS_Q_' , t12. >>>>>>> t15 := 'ZACKS_A_' , t12. >>>>>>> t11 := (t8 at: 2) >>>>>>> , t12. >>>>>>> t17 := FaAccountingRule new label: t16; >>>>>>> selector: t13 asSymbol; >>>>>>> context: 'Zacks' , t9 , 'Override'; >>>>>>> argumentTypesSpecification: '{FaProcessorProxy}'; >>>>>>> returnTypeSpecification: 'FaDatedFnSeries'; >>>>>>> isReturnValueConstant: true; >>>>>>> action: (self >>>>>>> getZacksDataAtScriptForCache: t11 >>>>>>> forZacksKey: t11 >>>>>>> fromSet: t9); >>>>>>> comment: (nil >>>>>>> ifNil: [t16]); >>>>>>> isSensitive: true; >>>>>>> definedBy: t6; >>>>>>> ownedBy: t6; >>>>>>> lastEditBy: t6; >>>>>>> yourself. >>>>>>> t5 register: t17. >>>>>>> t3 add: 'Successfully added ' , t17 selector , '/' , t17 context. >>>>>>> t4 crLog: t3 last]]]]. >>>>>>> ^ t3 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < >>>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < >>>>>>>>> marianopeck(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess < >>>>>>>>>> nicolaihess(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Mariano, if you know the method that may cause this crash can >>>>>>>>>>> you check >>>>>>>>>>> if it works if you recompile this method with the old compiler, >>>>>>>>>>> maybe this issue is responsible - wrong stack frame size : >>>>>>>>>>> 13854 >>>>>>>>>>> <https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-li…> >>>>>>>>>>> frameSize calculated wrongly for #lineSegmentsDo: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hi Nicolai, >>>>>>>>>> >>>>>>>>>> Thanks for the pointer. I tried with your fix and I still get the >>>>>>>>>> same results (even after recompiling). >>>>>>>>>> However...if I swap back to old Compiler rather than OpalCompiler >>>>>>>>>> and I recompile everything, then I do not have anymore the crash. >>>>>>>>>> So it's definitively something related to Opal compilation, and >>>>>>>>>> probably, related to closures compilation. >>>>>>>>>> I will see if I find other opal issues opened in 4.0. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-11-16 17:00 GMT+01:00 Mariano Martinez Peck < >>>>>>>>>>> marianopeck(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi guys, >>>>>>>>>>>> >>>>>>>>>>>> I am debugging a Pharo VM crash I am having and I cannot figure >>>>>>>>>>>> out what it is exactly. I suspect it might be related to block closures >>>>>>>>>>>> compilation but I am not sure. I have a reproducible crash test under Pharo >>>>>>>>>>>> 4.0 and OSX. >>>>>>>>>>>> >>>>>>>>>>>> I built a VM in debug mode and I run it via gdb. This is the >>>>>>>>>>>> kind of info I am able to see: >>>>>>>>>>>> >>>>>>>>>>>> *Program received signal SIGSEGV, Segmentation fault.* >>>>>>>>>>>> *0x000ab66b in updatePointersInRangeFromto (memStart=924623948, >>>>>>>>>>>> memEnd=928201420) at >>>>>>>>>>>> /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40444* >>>>>>>>>>>> *40444 && (((longAt(fieldOop)) & MarkBit) != 0)) {* >>>>>>>>>>>> *(gdb) call printAllStacks()* >>>>>>>>>>>> *Process 0x30e228c4 priority 40* >>>>>>>>>>>> *0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction >>>>>>>>>>>> class* >>>>>>>>>>>> *0xbffb2e30 M BlockClosure(FaMemoryStoreSession)>register: >>>>>>>>>>>> 0x371d0968: a(n) BlockClosure* >>>>>>>>>>>> *0xbffb2e4c M INVALID RECEIVER>register: 0x371cfd54: a(n) bad >>>>>>>>>>>> class* >>>>>>>>>>>> >>>>>>>>>>>> *(callerContextOrNil == (nilObject())) || >>>>>>>>>>>> (isContext(callerContextOrNil)) 48626* >>>>>>>>>>>> *0x3721e1f0 is not a context* >>>>>>>>>>>> *0x371c34b4 is not a context* >>>>>>>>>>>> >>>>>>>>>>>> And another crash: >>>>>>>>>>>> >>>>>>>>>>>> *Program received signal SIGSEGV, Segmentation fault.* >>>>>>>>>>>> *0x000ab66b in updatePointersInRangeFromto (memStart=924677864, >>>>>>>>>>>> memEnd=928262300) at >>>>>>>>>>>> /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40444* >>>>>>>>>>>> *40444 && (((longAt(fieldOop)) & MarkBit) != 0)) {* >>>>>>>>>>>> *(gdb) call printAllStacks()* >>>>>>>>>>>> *Process 0x30e228c4 priority 40* >>>>>>>>>>>> *0xbffb2de0 M INVALID RECEIVER>initialize 0x3722b9a0: a(n) bad >>>>>>>>>>>> class* >>>>>>>>>>>> *0xbffb2df8 M FaAction class(Behavior)>new 0x20ebb104: a(n) >>>>>>>>>>>> FaAction class* >>>>>>>>>>>> *0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction >>>>>>>>>>>> class* >>>>>>>>>>>> *0xbffb2e30 M INVALID RECEIVER>register: 0x371ddee0: a(n) bad >>>>>>>>>>>> class* >>>>>>>>>>>> *0xbffb2e4c M INVALID RECEIVER>register: 0x371dd328 is in old >>>>>>>>>>>> space* >>>>>>>>>>>> >>>>>>>>>>>> *(callerContextOrNil == (nilObject())) || >>>>>>>>>>>> (isContext(callerContextOrNil)) 48626* >>>>>>>>>>>> *0x3722b750 is not a context* >>>>>>>>>>>> *[New Thread 0x1b43 of process 5886]* >>>>>>>>>>>> *[New Thread 0x1d2f of process 5886]* >>>>>>>>>>>> *[New Thread 0x1f07 of process 5886]* >>>>>>>>>>>> *[New Thread 0x1e07 of process 5886]* >>>>>>>>>>>> >>>>>>>>>>>> From what I can see in *#printActivationNameFor: aMethod >>>>>>>>>>>> receiver: anObject isBlock: isBlock firstTemporary: maybeMessage* >>>>>>>>>>>> It looks like if the memory address is not an OOP, nor >>>>>>>>>>>> forwarding pointer nor... >>>>>>>>>>>> >>>>>>>>>>>> It also seems like the above stack I can get is not the real >>>>>>>>>>>> cause but a side effect that makes GC to crash >>>>>>>>>>>> (#updatePointersInRangeFromto) >>>>>>>>>>>> >>>>>>>>>>>> As said, I have a way to reproduce the crash, and I already >>>>>>>>>>>> have the VM compiled in debug and gdb running. I can also attach the full >>>>>>>>>>>> output of the gdb stack. >>>>>>>>>>>> >>>>>>>>>>>> BTW.... in the output of the gdb I see lots of printings like: >>>>>>>>>>>> >>>>>>>>>>>> *(numStack + ReceiverIndex) < (lengthOf(theContext)) 45421* >>>>>>>>>>>> *(ReceiverIndex + contextSize) < (lengthOfbaseHeaderformat(oop, >>>>>>>>>>>> header2, fmt)) 40416* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Any pointer is appreciated. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Mariano >>>>>>>>>>>> http://marianopeck.wordpress.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mariano >>>>>>>>>> http://marianopeck.wordpress.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mariano >>>>>>>>> http://marianopeck.wordpress.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mariano >>>>>>> http://marianopeck.wordpress.com >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 20, 2015

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

by Mariano Martinez Peck

Thierry, Sorry to bother again. Unfortunately, RB does not work out of the box in GemStone .... only the formatter part. grrr. Anyway, I am trying to make it work, and it's failing in this easy example: *| tree rewriter |* *tree := RBParser parseMethod: 'DoIt ^ [:proxy | proxy at: #oldSelector. ]'.* *rewriter := RBParseTreeRewriter new. * *rewriter * * replace: ('`#oldSelector `{:node | node value isSymbol and: [node value matchesRegex: ''.*oldSelector.*''] }')* * with: ('`{RBLiteralNode value: (`#oldSelector value copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol }').* *rewriter executeTree: tree. * *rewriter tree newSource* And the problem is the line: *with: ('`{RBLiteralNode value: (`#oldSelector value copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol }').* which gets translated to: [ :aDictionary | RBLiteralNode value: ((*self* lookupMatchFor: '`#oldSelector' in: aDictionary) value copyReplaceAll: 'oldSelector' with: 'newSelector') asSymbol ] The problem in GemStone is that that "self" is binded to nil and not to the receiver instance (RBPatternBlockNode). And so I get a Nil dnu.. *And I don't know how that closure is finally generated.* The message node: *(self lookupMatchFor: '`#oldSelector' in: aDictionary) * Its generated in: RBPatternBlockNode >> constructLookupNodeFor: aString in: aRBBlockNode | argumentNode | argumentNode := RBLiteralNode value: aString. ^RBMessageNode receiver:* (RBVariableNode named: 'self')* selector: #lookupMatchFor:in: arguments: (Array with: argumentNode with: aRBBlockNode arguments last) Any ideas? thanks in advance, On Mon, Nov 9, 2015 at 2:39 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 09/11/2015 17:38, Mariano Martinez Peck a Ã©crit : > >> Thierry, I have a last question. My last requirement will basically be >> to find ANY node that would match the regex *oldSelector* and rename it >> to *newSelector* being that.. a literal string, a literal symbol, a >> message send, a tempVar name, a comment, etc... I guess there is a >> simpler way that defining rewrite for each type of node right? >> I can always do a "(methodSource substrings detect: [:each | each >> matches: '*oldSelector'] ifNone: [#()] ) each2: [:each2 | copReplace. >> .... ] >> > > I think that if it is really everywhere, then it may works better to just > do text replace (methodSource copyReplaceAll: 'oldSelector' with: > 'newSelector'). > > But remember that it will touch everything (pragmas, varNames, comments, > etc.) > > but RB is probably better. >> > > It gives you more control to what you will change. But then you will have > to write rewrites for all types of nodes (around 6 or 7?). > > Any clues in this last requirement? >> > > Well, one thing which may be interesting would be to consider > encapsulating the rewrites in refactoring commands, and bring them as a > composite change, so that you could launch a rewrite, recover all those > method changes, apply (execute) them, check the result with the possibility > of undoing them. > > But I'm not familiar with that part of RB. I do consider it could become > significant with EPICEA. It has been a long term project to have AltBrowser > make all coding actions as refactoring commands so that EPICEA could log > them properly, but its only partly there (and has been for years now)... > and EPICEA is not yet here as well (but could be soon). > > Thierry > > -- Mariano http://marianopeck.wordpress.com

Nov. 20, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50456 Home: https://github.com/pharo-project/pharo-core

Nov. 20, 2015

[pharo-project/pharo-core] 8c66dd: 50456

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8c66dd7525db04dc03571f4aacca5bcb0a31c926 https://github.com/pharo-project/pharo-core/commit/8c66dd7525db04dc03571f4a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-20 (Fri, 20 Nov 2015) Changed paths: A Reflectivity.package/Breakpoint.class/class/class initialization/initialize.st A Reflectivity.package/Breakpoint.class/class/cleanup/cleanUp.st M Reflectivity.package/Breakpoint.class/class/cleanup/removeAll.st M Reflectivity.package/Breakpoint.class/class/cleanup/removeFrom_.st M Reflectivity.package/Breakpoint.class/definition.st M Reflectivity.package/Breakpoint.class/instance/install/install.st M Reflectivity.package/Breakpoint.class/instance/install/remove.st M Reflectivity.package/HookGenerator.class/instance/ast manipulation/wrapCondition_link_.st M Reflectivity.package/HookGenerator.class/instance/ast manipulation/wrapInContext_link_.st M Reflectivity.package/HookGenerator.class/instance/private/hookFor_.st A Reflectivity.package/RFMessageNode.class/README.md A Reflectivity.package/RFMessageNode.class/definition.st A Reflectivity.package/RFMessageNode.class/instance/as yet unclassified/debugHighlightRange.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50455.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50456.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50455.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50456.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsBreakConditionSuggestion.class/instance/breakpoints/breakpointForCondition.st Log Message: ----------- 50456 17068 fix debug highlight of breakpoints https://pharo.fogbugz.com/f/cases/17068 17067 Breakpoint #removeAll https://pharo.fogbugz.com/f/cases/17067 http://files.pharo.org/image/50/50456.zip

Nov. 20, 2015

Re: [Pharo-dev] Cleanup of debug requests API

by Andrei Chis

Very nice. I remember when I made GTDebugger that there were way to many ways to open the debugger. I ended up just copy-pasting things. Would be very useful to have a small doc with what one needs to do to replace SpecDebugger with another debugger (e.g. what are the entry points of the debugger in the system) Cheers, Andrei On Fri, Nov 20, 2015 at 6:48 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I clean and refactor all but lowSpaceWatcher. > It is in slice 17069. > In my image it is not broke stuff. So I hope it is safe change. > > 2015-11-20 12:18 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Hi >> >> I try to investigate how debugger opens and who initiates it. >> I want to cleanup this logic and simplify current debugger API. >> >> I found that basic error debugging starts with UIManager then UIManager >> calls SpecDebugger, then SpecDebugger calls UIManager and again... At the >> end of this chain debugger is opened by #openFullSuspendLabel: or >> #openNotifierContents:label: >> >> There are two places where opening debugger initiated differently: >> - Low space watcher calls SpecDebugger class>>openInterrupt:onProcess: >> - Warning default action calls SpecDebugger >> class>>openContext:label:contents: (And it not uses UIManager. I guess non >> interactive mode not working here). >> >> In latest Pharo image it is only users of this methods. Is anybody know >> anyone else? >> >> I almost cleaned basic errors debugging. And I want use it for this two >> cases too. But they implements very specific logic. They both contains >> primitive simulation guard 19 and some kind of recursion tracking. >> I understand that low space watcher requires something clever. But why >> Warning not opens debugger with way Error does it? >> >> Any suggestions? >> >> Best regards, >> Denis >> > >

Nov. 20, 2015