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

Re: [Pharo-dev] help needed with fixing the SpecDebugger

by Tudor Girba

That would be very much appreciated. I would also be interested in the approach you took to debug the problem. It would make for a nice assessment case study. Cheers, Doru On Tue, Nov 12, 2013 at 9:50 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Camillo we should have a look together. > > Are you at work today ? > > > 2013/11/11 Tudor Girba <tudor(a)tudorgirba.com> > >> Hi, >> >> I need a bit of help with the issue of the SpecDebugger relying on the >> default inspector being implemented in Spec. >> >> I investigated a bit, but now I am stuck. Details here: >> https://pharo.fogbugz.com/f/cases/12055/ >> >> Can anyone look at it? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 12, 2013

Re: [Pharo-dev] Unexpected block variable change of value

by ClÃ©ment Bera

This bug is tricky and nasty. It will be fixed before Pharo 3 release but it may not be fixed very soon. Regards. 2013/11/12 <btc(a)openinworld.com> > Thanks ClÃ©ment. > > Making that setting change, then "Compiler recompileAll" did fix the > problem. > However following up with "OpalCompiler recompileAll" does not reintroduce > the problem. > > Starting again with a fresh build #30564, I confirmed the problem was > there, > then first did "OpalCompiler recompileAll" and the problem remained. > > btw, (sorry) a correction below, > the place to insert the breakpoint was SpecLayout>>privateAsArray > not SpecRowLayout>>privateAsArray. > > regards, Ben > > > ClÃ©ment Bera wrote: > > There is a bug left in double nested blocks in the debugger (some variables > then shows incorrect value). > > Retry with the old compiler (world menu>settings>compiler>Compiler) and see > if this is fixed. > > > > 2013/11/11 Max Leske <maxleske(a)gmail.com> <maxleske(a)gmail.com> > > Not sure if itâs related to your issue but Iâve been seeing swapped > temporary variables in the debugger. The value used for execution is > correct but in the view two variables will have the value of the other. > Are you sure that the value *effectively* changes or could it be a > visualization problem? > > Max > > On 11.11.2013, at 17:29, btc(a)openinworld.com wrote: > > > > I'm not sure if I'm missing something, but there seems some strange > > > behavior that I don't understand. The value of a block variable changes > when stepping over a method that acts on that variable. I encountered this > in Spec, but that seems co-incidental to the behaviour. > > > SETUP > 1. The attached "My-Spec-Tutorial-BenComan.1.mcz" (i.e. Bahman's > > > tutorial) was loaded into build #30564. > > > 2. A breakpoint was inserted after the first "e generateArguments" in... > SpecRowLayout>>privateAsArray > | result shouldCheckSplitters | > result := OrderedCollection new. > shouldCheckSplitters := false. (self commands reject: [:e | e > > > isSplitter ]) do: [:e | > > > ...lots..hidden.for..conciseness.... > e generateArguments. > self haltOnce. "<------------------" > e asSpecElements do: [:el | > result add: el ]]. > > 3. The following was evaluated... > Halt enableHaltOnce. > MyFirstWindow new openWithSpec: #defaultSpec. > > > OBSERVATION > 1. When the debugger opened at the breakpoint > e = a SpecLayoutAdd > > 2. But after stepping over #asSpecElements > e = an OrderedCollection() > > So how did the value of 'e' change? > > Where... > SpecLayoutAdd(SpecLayoutSend)>>asSpecElements > ^ {self selector.}, self arguments > > SpecLayoutAdd(SpecLayoutSend)>>selector > ^ selector > > SpecLayoutAdd(SpecLayoutSend)>>arguments > ^ arguments > > > This was on Windows 7. Since files.pharo.org is offline, I wasn't able > > > to try a newer VM. My current was... > > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > > > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > > > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > git://gitorious.org/cogvm/blessed.git Commit: > > > 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> <estebanlm(a)gmail.com> Jenkins build #14535 > > > Win32 built on Mar 13 2013 18:49:42 Compiler: 4.6.2 > VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: > > > 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> <estebanlm(a)gmail.com> Jenkins build #14535 > > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > > > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > > > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > cheers -ben > > <My-Spec-Tutorial-BenComan.1.mcz> > > > >

Nov. 12, 2013

Re: [Pharo-dev] Remove Class Category

by ClÃ©ment Bera

Hello, I would look at: SystemOrganizer>>removeCategory: and you access it with: Smalltalk organization But I'm not sure it will help you. 2013/11/11 Jimmie Houchin <jlhouchin(a)gmail.com> > Hello, > > I am wanting to write a method which uninstalls all of the Classes which I > have created. > > I have one which looks like this: > > uninstall > > AllClasses reverse do: [ :c | Smalltalk removeClassNamed: c ] > > > However the class category which was created to install them into still > remains. I am having a hard time discovering what method I use to remove > the category these classes were in. > > There are a lot of methods with category in the name. And is quite > confusing how category and protocol are sometimes used interchangeably. I > can't tell whether or not they are talking about removing the method's > protocol categorization or the classes' category categorization. Its not > until you go read the source that you might learn which you are looking at. > > Any help pointing to the method I am looking for is greatly appreciated. > > Jimmie > >

Nov. 12, 2013

Re: [Pharo-dev] help needed with fixing the SpecDebugger

by ClÃ©ment Bera

Camillo we should have a look together. Are you at work today ? 2013/11/11 Tudor Girba <tudor(a)tudorgirba.com> > Hi, > > I need a bit of help with the issue of the SpecDebugger relying on the > default inspector being implemented in Spec. > > I investigated a bit, but now I am stuck. Details here: > https://pharo.fogbugz.com/f/cases/12055/ > > Can anyone look at it? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 12, 2013

Re: [Pharo-dev] Remove Class Category

by Goubier Thierry

Hi, this probably depends on the version of Pharo you're using but, in 3.0, what you can do is: Smalltalk globals organization removeCategory: name. And then you need to update the relevant RPackage tag: package removeClassTag: name (Because RPackage class tags are synchronized on some category operations, but not all). In 2.0, you just have to execute the first one. Nautilus, or Browser, are good places to see that type of code. Thierry Le 11/11/2013 23:33, Jimmie Houchin a Ã©crit : > Hello, > > I am wanting to write a method which uninstalls all of the Classes which > I have created. > > I have one which looks like this: > > uninstall > > AllClasses reverse do: [ :c | Smalltalk removeClassNamed: c ] > > > However the class category which was created to install them into still > remains. I am having a hard time discovering what method I use to remove > the category these classes were in. > > There are a lot of methods with category in the name. And is quite > confusing how category and protocol are sometimes used interchangeably. > I can't tell whether or not they are talking about removing the method's > protocol categorization or the classes' category categorization. Its not > until you go read the source that you might learn which you are looking at. > > Any help pointing to the method I am looking for is greatly appreciated. > > Jimmie > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

It is not necessary better, but it saves you from having hundreds of temp vars :) Ben On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Example: >> aMenu addGroup: [ :aGroup | >> aGroup addItem: [ :anItem | >> anItem name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix ]. >> aGroup addItem: [ :anItem | >> anItem name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ] ] ]. >> > > I do not see the value of passing block to add element to groups > why not the normal way i.e. passing an object. I do not get why executing > a block with an object is better? > > Stef >

Nov. 12, 2013

Re: [Pharo-dev] Pharo 2.0 and Monticello settings: looks like there is no way to change

by Tudor Girba

That was almost too long :) Good job, Doru On Tue, Nov 12, 2013 at 1:00 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Sean P. DeNigris wrote > > Fix in inbox (for 2.0) > > And for 3.0... > Fix in inbox: > > SLICE-Issue-12146-Port-to-30-12145-Settings-Replace-references-to-FileDirectory-SeanDeNigris.1 > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-2-0-and-Monticello-settings-looks-like-there-is… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 12, 2013

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

by Sean P. DeNigris

Sean P. DeNigris wrote > Using the presentation, I tried to communicate with the portaudio lib (OSX > 10.8.5, lib installed with brew). > ... > Thanks in advance for any guidance... Bump. btw I should mention that the error was "function unavailable" ----- Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 12, 2013

Re: [Pharo-dev] Pharo 2.0 and Monticello settings: looks like there is no way to change

by StÃ©phane Ducasse

cool :) Stef On Nov 12, 2013, at 1:00 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sean P. DeNigris wrote >> Fix in inbox (for 2.0) > > And for 3.0... > Fix in inbox: > SLICE-Issue-12146-Port-to-30-12145-Settings-Replace-references-to-FileDirectory-SeanDeNigris.1 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-2-0-and-Monticello-settings-looks-like-there-is… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

> > Example: > aMenu addGroup: [ :aGroup | > aGroup addItem: [ :anItem | > anItem name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix ]. > aGroup addItem: [ :anItem | > anItem name: 'Browse Class'; > action: [ self browseSelectedObjectClass ] ] ]. > I do not see the value of passing block to add element to groups why not the normal way i.e. passing an object. I do not get why executing a block with an object is better? Stef

Nov. 12, 2013