February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New debugger in pharo 5

by stepharo

Le 15/2/16 11:10, Norbert Hartl a Ã©crit : > I'm using pharo 5 for the first time and I have trouble getting used to the new debugger there. > > I think that actions like proceeding, stepping into, overâ¦ etc. are important functionalities of a debugger. So it is not a good idea to move them to the upper right of the window and make them not to look like buttons. To me it is to make central functionality inaccessible. we agree and it was already reported. > On the other hand I find the "Source" tab superfluous. Is this space supposed to be covered with more tabs then just the source? > > The Variables tab in the lower left: Is the "Type" information the most important? Not to me. If I look at the tab I want to find the name of a variable I expect there to be. So the Variable should be this first column, then Value and finally Type. This would also solve the UI issue that the Type label with strings of different size make a bad appearance when scrolling. It is hard to focus on the names of the Variable because the Type label having a dark background is catching attention. > > What needs some time to adjust but I like is to have the same behaviour as in the inspector in the bottom row starting from the actual execution context. > > my 2 cents, > > Norbert > > > > > >

Feb. 15, 2016

Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder?

by stepharo

I'm so fucking sad.... These kinds of glitches are killing my fun and energy. I lost again one hour trying to produce a video for nothing. Stef Le 15/2/16 11:24, Stephan Eggermont a Ã©crit : > On 15-02-16 10:48, stepharo wrote: >> This is 5 times that I'm redoing a videos for the mooc. :( > > Isn't it amazing (and/or terrible) what kind of, and how many, little > issues you tend to find when shooting a video/screencast to explain > something? Every time I've made a screencast I've found things that > first needed fixing or working around. > > Stephan > > > > > >

Feb. 15, 2016

Is there a problem in latest pharo with refresh?

by stepharo

Hi I cannot produce videos with the latest pharo image because when I move a window then all the previous windows stay on the screen. Do you see the same? Stef

Feb. 15, 2016

Re: [Pharo-dev] why spotter shows up when I type enter in the inputfield of the finder?

by Stephan Eggermont

On 15-02-16 10:48, stepharo wrote: > This is 5 times that I'm redoing a videos for the mooc. :( Isn't it amazing (and/or terrible) what kind of, and how many, little issues you tend to find when shooting a video/screencast to explain something? Every time I've made a screencast I've found things that first needed fixing or working around. Stephan

Feb. 15, 2016

Re: [Pharo-dev] Improving Ghost proxies

by Denis Kudriashov

And who is using Ghost now? If I will change something I want to check users 2016-02-15 11:15 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hello. > > I think it is important to get single proxy framework for Pharo. It should > provide required integration support for our tools. > > I want push Ghost in that direction. Debuggers and inspectors should work > correctly with proxies which based on Ghost. > > Now Ghost is stored in CAR team repository. Should we move it to Pharo? > > P.S. Ghost has one failed tests due to Spur problem 17536 > <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…> > . > > Best regards, > Denis >

Feb. 15, 2016

Improving Ghost proxies

by Denis Kudriashov

Hello. I think it is important to get single proxy framework for Pharo. It should provide required integration support for our tools. I want push Ghost in that direction. Debuggers and inspectors should work correctly with proxies which based on Ghost. Now Ghost is stored in CAR team repository. Should we move it to Pharo? P.S. Ghost has one failed tests due to Spur problem 17536 <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…> . Best regards, Denis

Feb. 15, 2016

New debugger in pharo 5

by Norbert Hartl

I'm using pharo 5 for the first time and I have trouble getting used to the new debugger there. I think that actions like proceeding, stepping into, overâ¦ etc. are important functionalities of a debugger. So it is not a good idea to move them to the upper right of the window and make them not to look like buttons. To me it is to make central functionality inaccessible. On the other hand I find the "Source" tab superfluous. Is this space supposed to be covered with more tabs then just the source? The Variables tab in the lower left: Is the "Type" information the most important? Not to me. If I look at the tab I want to find the name of a variable I expect there to be. So the Variable should be this first column, then Value and finally Type. This would also solve the UI issue that the Type label with strings of different size make a bad appearance when scrolling. It is hard to focus on the names of the Variable because the Type label having a dark background is catching attention. What needs some time to adjust but I like is to have the same behaviour as in the inspector in the bottom row starting from the actual execution context. my 2 cents, Norbert

Feb. 15, 2016

why spotter shows up when I type enter in the inputfield of the finder?

by stepharo

Hi guys you cannot imagine the amount of energy I'm losing because of the flux of the tools. why spotter shows up when I type enter in the inputfield of the finder? Is it on purpose? This is 5 times that I'm redoing a videos for the mooc. :( Stef

Feb. 15, 2016

Re: [Pharo-dev] PharoObjectModel chapter is available for review

by stepharo

fixed! Tx Le 15/2/16 00:34, Eliot Miranda a Ã©crit : > Hi Stef, > > "Implementation note. Deep in the implementation of Pharo, there are > three different kinds of objects: > 1. ordinary objects with instance variables that are passed by > references > 2. small integers that are passed by value > 3. indexable objects like arrays that hold a contiguous portion of > memory > The beauty of Pharo is that you normally donât need to care about the > differences between these three kinds of object." > > The distinction between 1. and 3. is erroneous. Both Arrays and > normal objects are passed by reference. And with Pharo 5 there are > more kinds of immediate objects than SmallInteger. > > This should read something like the following. And I would put it > much later in the chapter. > > "Implementation note. Deep in the implementation of Pharo, there are > two different kinds of objects: > 1. objects with zero or more fields that are passed by reference > and exist on the Pharo heap > 2. immediate objects that are passed by value. Depending on > version these are a range of the integers called SmallInteger, all > Character objects and possibly a sub-range of 64-bit floating-point > numbers called SmallFloat64. In the implementation immediate objects > occupy an /object pointer/, most of whose bits encode the immediate's > value and some of the bits encode the object's class. > > The first kind of object, an ordinary object, comes in a number of > varieties > 1. normal objects that have zero or more named instance variables, > such as Point which has an x and a y instance variable. Each instance > variable holds an object pointer, which can be a reference to another > ordinary object or an immediate. > 2. indexable objects like arrays that have zero or more indexed > instance variables numbered from 1 to N. Each indexed instance > variable holds an object pointer, which can be a reference to another > ordinary object or an immediate. Indexable objects are accessed using > the messages at: and at:put:. For example ((Array new: 1) at: 1 put: > 2; at: 1) answers 2. > 3. objects like Closure or Context that have both named instance > variables and indexed instance variables. In the object, the indexed > instance variables follow the named instance variables. > 4. objects like ByteString or Bitmap that have indexed instance > variables numbered from 1 to N that contain raw data. Each datum may > occupy 8, 16 or 32-bits, depending on its class definition. The data > can be accessed as either integers, characters or floating-point > numbers, depending on how at: and at:put: are implemented. The at: > and at:put: methods convert between Pharo objects and raw data, hiding > the internal representation, but allowing the system to represent > efficiently data such as strings, and bitmaps. > > A beauty of Pharo is that you normally donât need to care about the > differences between these three kinds of object." > > Note that I replaced "The beauty" with "A beauty". > > Personally I would introduce the idea of classes after giving examples > of the different kinds of objects, and introducing polymorphism and > message syntax. You might mention that all objects are instances of a > class and the class defines the layout and behaviour of the object, > but say no more until you've presented objects and messaging. = and > > are good messages to demonstrate polymorphism with; you can use them > with integers, floats characters, strings and points. > > On Sun, Feb 14, 2016 at 5:45 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > I finished to revisit the chapter Pharo object model for updated > pharo by example > > Here it is: > https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample… > > Stef > > > > > -- > _,,,^..^,,,_ > best, Eliot

Feb. 15, 2016

Re: [Pharo-dev] PharoObjectModel chapter is available for review

by stepharo

In fact I let it because I did not write it but I will remove this section and add a section including your text more at the end of the chapter Stef Le 15/2/16 00:34, Eliot Miranda a Ã©crit : > Hi Stef, > > "Implementation note. Deep in the implementation of Pharo, there are > three different kinds of objects: > 1. ordinary objects with instance variables that are passed by > references > 2. small integers that are passed by value > 3. indexable objects like arrays that hold a contiguous portion of > memory > The beauty of Pharo is that you normally donât need to care about the > differences between these three kinds of object." > > The distinction between 1. and 3. is erroneous. Both Arrays and > normal objects are passed by reference. And with Pharo 5 there are > more kinds of immediate objects than SmallInteger. > > This should read something like the following. And I would put it > much later in the chapter. > > "Implementation note. Deep in the implementation of Pharo, there are > two different kinds of objects: > 1. objects with zero or more fields that are passed by reference > and exist on the Pharo heap > 2. immediate objects that are passed by value. Depending on > version these are a range of the integers called SmallInteger, all > Character objects and possibly a sub-range of 64-bit floating-point > numbers called SmallFloat64. In the implementation immediate objects > occupy an /object pointer/, most of whose bits encode the immediate's > value and some of the bits encode the object's class. > > The first kind of object, an ordinary object, comes in a number of > varieties > 1. normal objects that have zero or more named instance variables, > such as Point which has an x and a y instance variable. Each instance > variable holds an object pointer, which can be a reference to another > ordinary object or an immediate. > 2. indexable objects like arrays that have zero or more indexed > instance variables numbered from 1 to N. Each indexed instance > variable holds an object pointer, which can be a reference to another > ordinary object or an immediate. Indexable objects are accessed using > the messages at: and at:put:. For example ((Array new: 1) at: 1 put: > 2; at: 1) answers 2. > 3. objects like Closure or Context that have both named instance > variables and indexed instance variables. In the object, the indexed > instance variables follow the named instance variables. > 4. objects like ByteString or Bitmap that have indexed instance > variables numbered from 1 to N that contain raw data. Each datum may > occupy 8, 16 or 32-bits, depending on its class definition. The data > can be accessed as either integers, characters or floating-point > numbers, depending on how at: and at:put: are implemented. The at: > and at:put: methods convert between Pharo objects and raw data, hiding > the internal representation, but allowing the system to represent > efficiently data such as strings, and bitmaps. > > A beauty of Pharo is that you normally donât need to care about the > differences between these three kinds of object." > > Note that I replaced "The beauty" with "A beauty". > > Personally I would introduce the idea of classes after giving examples > of the different kinds of objects, and introducing polymorphism and > message syntax. You might mention that all objects are instances of a > class and the class defines the layout and behaviour of the object, > but say no more until you've presented objects and messaging. = and > > are good messages to demonstrate polymorphism with; you can use them > with integers, floats characters, strings and points. > > On Sun, Feb 14, 2016 at 5:45 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > I finished to revisit the chapter Pharo object model for updated > pharo by example > > Here it is: > https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample… > > Stef > > > > > -- > _,,,^..^,,,_ > best, Eliot

Feb. 15, 2016