- Pharo-dev - lists.pharo.org

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

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

by Denis Kudriashov

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

Re: [Pharo-dev] Does Pharo stores original author of methods?

by Denis Kudriashov

2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > epicea data is not stored forever. It is seasion based and the shipped > image is > clean. > But current source of this info is changes file (maybe sources). And I remember you planned to store current sources in image. And such information can be there too. Maybe I miss something?

Nov. 20, 2015

Re: [Pharo-dev] Issue with large file path on windows

by Esteban Lorenzano

yes it was. latest win vm should have long paths. Esteban > On 20 Nov 2015, at 12:27, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Hello, > > I would like to read from Pharo a file with a long name (so more than 255 chars) under Windows. > A thread from last month (13 oct): âRe: [Pharo-dev] [Vm-dev] Re: issue with large file path on windowsâ, talks about a patch. > Does it has been integrated? > If it has, which VM should I take to have the patch? > My current one is http://files.pharo.org/vm/pharo/win/494.zip <http://files.pharo.org/vm/pharo/win/494.zip> > > Thanks, > > Vincent Blondeau > > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Nov. 20, 2015