April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 11834 Debugger <Restart> then <Over> does not step over

by Ben Coman

Ben Coman wrote: > Has anyone else noticed the different in behaviour between #haltOnce > and #halt. For example, evaluate the following.... > Halt enableHaltOnce. > Transcript crShow: 1. > self haltOnce. > Transcript crShow: 2. > self halt. > Transcript crShow: 3. > > When the Debugger appears, select Undefined>>DoIt in the stack, > then <Restart>, then step <Over> until the end of script. > > I logged this case a while ago... > https://pharo.fogbugz.com/f/cases/11834/Debugger-Restart-then-Over-does-not… > > but its not clear if there is a bug. > > Any opinions? > > cheers -ben > > Max, Thanks for your comment on the Case. I've moved to Pharo 4. cheers -ben

April 14, 2014

Re: [Pharo-dev] [Pharo3] Issue tracker status

by Marcus Denker

On 12 Apr 2014, at 11:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>>> https://pharo.fogbugz.com/f/filters/64/3-0-TODO >>>> >>>> (this list should be empty before we release) >>>> >>>> There are overall 87 issues tagged for Pharo3: >>>> >>> down to 74 >> down to 50 >> > Down to 41 > Down to 35â¦ Marcus

April 14, 2014

Re: [Pharo-dev] 13102

by Stephan Eggermont

Sven wrote: >I don't have an opinion on this, but 'showstopper' ~= 'Canât explain this to new users'. Try explaining our Morphic implementation to new users ;-P It is not the implementation I need to explain. Can anyone explain why global shortcuts should override application ones? I havenât seen a rationale for that. Stephan

April 13, 2014

Re: [Pharo-dev] 13102

by Sergi Reyner

2014-04-13 15:50 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Stephan Eggermont wrote > > I think 13102 is a showstopper. Can't explain this to new users. > > I don't have an opinion on this, but 'showstopper' ~= 'Can't explain this > to > new users'. Try explaining our Morphic implementation to new users ;-P > I am on the "You create some objects, or not, and send them some messages, and then morphs do stuff sometimes. Or something." stage. Cheers, Sergi

April 13, 2014

Re: [Pharo-dev] 13102

by phil＠highoctane.be

This is unfair to Morphic! Le 13 avr. 2014 16:52, "Sean P. DeNigris" <sean(a)clipperadams.com> a Ã©crit : > Stephan Eggermont wrote > > I think 13102 is a showstopper. Can't explain this to new users. > > I don't have an opinion on this, but 'showstopper' ~= 'Can't explain this > to > new users'. Try explaining our Morphic implementation to new users ;-P > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/13102-tp4754417p4754446.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 13, 2014

Re: [Pharo-dev] 13102

by Sean P. DeNigris

Stephan Eggermont wrote > I think 13102 is a showstopper. Canât explain this to new users. I don't have an opinion on this, but 'showstopper' ~= 'Canât explain this to new users'. Try explaining our Morphic implementation to new users ;-P ----- Cheers, Sean -- View this message in context: http://forum.world.st/13102-tp4754417p4754446.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 13, 2014

Re: [Pharo-dev] PharoCondenseChanges validation

by Ben Coman

April 13, 2014

11834 Debugger <Restart> then <Over> does not step over

by Ben Coman

Has anyone else noticed the different in behaviour between #haltOnce and #halt. For example, evaluate the following.... Halt enableHaltOnce. Transcript crShow: 1. self haltOnce. Transcript crShow: 2. self halt. Transcript crShow: 3. When the Debugger appears, select Undefined>>DoIt in the stack, then <Restart>, then step <Over> until the end of script. I logged this case a while ago... https://pharo.fogbugz.com/f/cases/11834/Debugger-Restart-then-Over-does-not… but its not clear if there is a bug. Any opinions? cheers -ben

April 13, 2014

Re: [Pharo-dev] FileSystem-Git status update 3

by Max Leske

On 10.04.2014, at 13:18, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 10 April 2014 11:44, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 09 Apr 2014, at 5:30 , Max Leske <maxleske(a)gmail.com> wrote: > > > > > On 09.04.2014, at 17:25, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > >> Max Leske wrote > >>>> In NB, how do I pass NULL into a function call without modifying the > >>>> argument type? e.g. my argument has type String. passing something like > >>>> `NBExternalAddress null` will be converted into a C string instead of > >>>> being passed through (I know, that seems to be the point in this case but > >>>> I couldn't find any other way to create NULL). Any suggestions? > >> > >> I think you just pass nil, no? > > > > One would think so, but noâ¦ :) > > NB will signal an exception because UndefinedObject is not of the expected type. > > I remember an optCoerceNilToNull, but that seems to > 1) Only apply to pointer types (which could mean having to use char *, not String, and thus need to do encoding/decoding manually) > 2) Be scoped to entire call, not single parameter (may or may not be more than a philosophical objection) > > Might be worth a shot though? > > - optCoerceNilToNull is for pointers > > for strings, there's an option: > - optStringOrNull That should work for most cases. Thanks Igor > > which, if enabled, adds additional check for nil in generated marshaller code, > so that by passing nil it will pass NULL to calling function. > > > Cheers, > Henry > > > > -- > Best regards, > Igor Stasenko.

April 13, 2014

Re: [Pharo-dev] PharoCondenseChanges validation

by Sven Van Caekenberghe

Ben, I ran your code. [ PharoChangesCondenser condense ] timeToRun. ==> 0:00:00:13.315 (that's 13 seconds) I see no differences: {#sameAfter->64066. #diffAfter->0} This Windows issue is annoying, it is just file manipulation, right ? Sven On 13 Apr 2014, at 13:29, Ben Coman <btc(a)openInWorld.com> wrote: > Its cool the new PharoCondenseChanges was integrated 30821, presumably to be used for Pharo 3 release. I have a problem running it on MS Windows (reported on Case 12729), but that is not critical for the Release since presumably for that it only needs to run properly on one platform. > > However while investigating my MS Windows problem, it seemed that some sources before and after were not the same. This could be an consequence of the MS Windows problem, so I was hoping that someone could report the result of the following code on non-Windows platforms (presuming that this provides a valid #condense function check.) > --------- > cacheMethodSourcesBlock := > [ | classes methods methodSources | > classes := (Smalltalk globals select: [ :g | g isClass ]) values. > methods := classes flatCollect: [ :c | c methods ]. > methodSources := Dictionary new. > methods do: [ :m | methodSources at: m printString put: m asString ]. > methodSources > ]. > > methodSourcesBefore := cacheMethodSourcesBlock value. > > PharoCondenseChanges condense. "btw, this took over an hour for me. Is that reasonable?" > > methodSourcesAfter := cacheMethodSourcesBlock value. > > sameAfter := Dictionary new. > diffAfter := Dictionary new. > methodSourcesBefore keys do: > [ :methodName | | methodSourceBefore methodSourceAfter | > methodSourceBefore := methodSourcesBefore at: methodName. > methodSourceAfter := methodSourcesAfter at: methodName. > methodSourceBefore = methodSourceAfter > ifTrue: [ sameAfter at: methodName put: { #beforeAndAfter -> methodSourceBefore } ] > ifFalse: [ diffAfter at: methodName put: { #before -> methodSourceBefore . String cr, String cr. #after -> methodSourceAfter }] > ]. > > { #sameAfter -> sameAfter size . #diffAfter -> diffAfter size } inspect > --------- > > cheer -ben

April 13, 2014