- Pharo-dev - lists.pharo.org

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

by Max Leske

> On 21 Nov 2015, at 09:34, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Slice was declined because I remove SyntaxErrorDebugger. I not found any reference to it. And there was no instances of it. Can anybody show me where it is used? > > Are you sure? The validation says that it failed due to âsubclass responsibility not definedâ (two messages of UIManager that arenât implemented in all of its subclasses). It doesnât say anything abut SyntaxErrorDebugger. Cheers, Max > 20 Ð½Ð¾ÑÐ±. 2015 Ð³. 19:27 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Andrei Chis" <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > 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 <mailto:dionisiydk@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 <mailto:dionisiydk@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. 21, 2015

Re: [Pharo-dev] Refactoring and traitsâ¦

by Max Leske

Not sure about current Pharo, but I know that it has been a problem in the past (e.g. in 1.3 you should *never* use refactoring when a trait is affected). > On 20 Nov 2015, at 15:01, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi guys, > > is it a known issue that if you are refactoring something (eg. doing a class rename) and some changes should happen in a method which comes from trait, then new methods are compiled in concrete classes instead of changing the trait method? > > Cheers. > Uko

Nov. 21, 2015

Re: [Pharo-dev] SystemAnnouncer class>>#uniqueInstance

by Max Leske

> On 20 Nov 2015, at 17:06, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > Hi, > > The class SystemAnnouncer has #restoreAllNotifications method that is called only by RPackageRenameTest>>setUp. This is pretty strange. I have an impression that tests should not affect global information (singleton). And there are some objects that depends on calling #restoreAllNotifications. I guess that all this staff works thanks to this particular test case. > > I think this is a bug and correct solution should be: > > -=-=-=- > uniqueInstance > "Answer a system annoncer." > > ^ announcer ifNil: [ announcer := self new. self restoreAllNotifications. announcer ]. > -=-=-=- > Wouldnât RPackageRenameTest then have to nil the announcer instance? > And it should be removed from RPackageRenameTest>>setUp. > What do you think? > Should I open an issue? > Cheers, > Juraj

Nov. 21, 2015

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

by Denis Kudriashov

Slice was declined because I remove SyntaxErrorDebugger. I not found any reference to it. And there was no instances of it. Can anybody show me where it is used? 20 Ð½Ð¾ÑÐ±. 2015 Ð³. 19:27 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Andrei Chis" < chisvasileandrei(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > 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. 21, 2015

Re: [Pharo-dev] About being a real Pharo Jedi developer

by Craig Latta

> IMO, unloading is for the viewpoint of having an "ultimate image" > which is never replaced. Or, at least, not replaced from scratch while you're in the middle of day-to-day work and don't want to have to recreate a bunch of useful state somewhere else. Unloading has practical value. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Nov. 21, 2015

Re: [Pharo-dev] Recovering _lost_ changes

by Yuriy Tymchuk

That was my point. If we had a solid model of changes (and I expect epic to be like that), than I believe we could simply select the real changes since last save and apply them. Maybe some time :) Cheers. Uko > On 20 Nov 2015, at 23:11, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-11-20 23:01 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > > > On 20 Nov 2015, at 17:52, Skip Lentz <skip.lentz(a)inria.fr <mailto:skip.lentz@inria.fr>> wrote: > > > > Hi, > > > >> On Nov 20, 2015, at 5:27 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@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? > > Yes, âTools > Recover lost changesâ¦" the session browser is gone. It was just a list of last save timestamp. Now the Recover lost changes > just shows *all* changes. But beware, recovering from this changes browser does not always work - some times the order is wrong :( > > > 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] Recovering _lost_ changes

by Nicolai Hess

2015-11-20 23:01 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > > 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? > Yes, âTools > Recover lost changesâ¦" the session browser is gone. It was just a list of last save timestamp. Now the Recover lost changes just shows *all* changes. But beware, recovering from this changes browser does not always work - some times the order is wrong :( > > 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] 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