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

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

by stepharo

thanks I will update the code and probably go less in the details. 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

Textmenu-in-Finder-code-pane-does-not-work

by stepharo

https://pharo.fogbugz.com/f/cases/17590/Textmenu-in-Finder-code-pane-does-n…

Feb. 15, 2016

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

by Eliot Miranda

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> 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. 14, 2016

[UpdatedPharoByExample] Metaclass chapter is available

by stepharo

https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample… Yes the book is making progress. Big tx to werner who is reading all the chapters and spotting my mistakes :) Stef

Feb. 14, 2016

Re: [Pharo-dev] Recent changes in Bloc, no more BlMorph

by Sean P. DeNigris

Tudor Girba-2 wrote > the design got too complicated when we tried to have composites because > the delegation had to essentially go through two hierarchies. It sounds like you are experimenting with using Bloc "for real". If so, is there any code available? And I can't wait to read your blog post about it ha ha ----- Cheers, Sean -- View this message in context: http://forum.world.st/Recent-changes-in-Bloc-no-more-BlMorph-tp4875999p4877… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 14, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by Nicolai Hess

2016-02-13 16:24 GMT+01:00 stepharo <stepharo(a)free.fr>: > > > > 2016-02-09 13:46 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi nicolai >> >> I agree. I will have a look at the Calipso experience of Alain. >> Because may be Calipso + Spec layout format would be much nicer. >> Did you look at it? >> > > I could not find anything about Calipso, what is it? > > > http://smalltalkhub.com/#!/~AlainPlantec/Calypso > > Sorry still can not find out what this is about. With this amount of documentation, I guess it is not yet ready for review/feedback. > > Stef > > > > > > >> Alain just brainstormed but this is interesting for thinking. >> >> Stef >> >> What I hate also is that the >> >> AbstractApdate>>update: aSymbol >> >> self changed: aSymbol >> >> This is a bit terrible because the adpater should not exist at runtime >> and adapter should just encapsulate how to create and set the >> communication >> between the model and the view. Now it is in the middle and this is not >> good. >> >> stef >> >> >> Le 8/2/16 11:31, Nicolai Hess a Ã©crit : >> >> >> >> 2016-02-08 10:37 GMT+01:00 stepharo < <stepharo(a)free.fr>stepharo(a)free.fr> >> : >> >>> Hi guys >>> >>> I should say that I'm sick (gift from my little boy) so may be this is >>> obvious. >>> >>> I'm looking at the code of Spec and I hate this code :) >>> >>> widgetDo: aBlock >>> >>> ^ self widget ifNotNil: aBlock >>> >>> >>> I do not see why widgetDo: has to test for nil >>> So I transformed >>> >>> widgetDo: aBlock >>> >>> ^ self widget ifNotNil: aBlock >>> >>> into >>> >>> >>> widgetDo: aBlock >>> >>> ^ aBlock cull: self widget >>> >>> BTW I hate all the cull: call. They are connected with sloppiness). It >>> is far too easy to use cull: >>> I do not know how many arguments, I do not care I use cull: >>> cull: is slow slow and help producing messing API. >>> >>> And it broke. The methodBrowser example did not work anymore and many >>> others. >>> Debugger felt down.... >>> I feel sad. Now my brain is dead so I cannot concentrate more. >>> >>> >>> Stef >>> >>> >> This is a big problem with morphic/spec ui elements. You never know for >> sure >> what code this >> self update ---> search through all (dynamicly added) dependents and >> notify >> will finally call. >> In this example we are about to *built* the widgets and in this run , we >> change a component that >> will update all dependents goes back and forth between model, adapter and >> widget. And all >> before the widget is actually accessible for the widgetDo: call. >> >> (and, REALLY we need to clean this up. This is really bad code if we >> announce a textChanged announcement for >> a text component, if we *initialize* an *empty textcomponent* with an >> *empty text*!). >> >> >> >> > >

Feb. 14, 2016

PharoObjectModel chapter is available for review

by stepharo

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

Feb. 14, 2016

Re: [Pharo-dev] More tests for new frameworks

by stepharo

Thanks I do not have the cycle for that but I would love to get some feedback on if this is possible to run and for which packages. Stef Le 14/2/16 04:09, Alejandro Infante a Ã©crit : > If you plan to add it to an automatic CI Job with Hapao, I would recommend to load the following group of Spy2: > âââââ > (ConfigurationOfSpy2 project version: #stable) load: #HapaoCore > âââââ > > This is going to load just the core of Spy and Hapao and will not load Roassal, GT-Inspector and GT-Debugger extensions. > > Cheers, > Alejandro > >> On Feb 13, 2016, at 6:39 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Yes I would even buy 20% coverage right now. >> >> Stef >> >> >> Le 13/2/16 20:22, Max Leske a Ã©crit : >>> How about enforcing coverage? I know that coverage tests donât say anything about the quality of the test cases but itâs (almost) always better to have some tests than none. I wouldnât set the bar too high either for coverage, maybe 60 or 70%. 100% is unrealistic, but 60 to 70 should be achievable with a couple of well written tests. >>> >>> Of course we would need a way to run coverage tests on the test suite. Do we have a tool for coverage tests? >>> >>>> On 13 Feb 2016, at 19:35, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Hi guys >>>> >>>> with damien cassou we had an interesting discussion. Basically we are teaching tests and we see that many Pharo subsystems are not really well tested. I wonder how we can change this. For example, we will have a new graphical core without any tests >>>> and this is sad because tests could be really good to make sure that we will be able to move forward in the future. >>>> I would like to get tests for Ring. >>>> >>>> Stef >>>> >>>> >>>> >>> >> > >

Feb. 14, 2016

Re: [Pharo-dev] missing cairo library in CI

by Aliaksei Syrel

Thanks Peter :) It seems to work! Cheers, Alex On Sun, Feb 14, 2016 at 1:16 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > I've personally solved it by forcing the job to run on > "pharo-contribution-linux64-3" slave. > There should be also at least one more slave that has cairo, but I don't > remember the name. > > Peter > > On Sat, Feb 13, 2016 at 11:54 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> CI still can not find cairo library sometimes... >> >>> Error: Cannot locate cairo library. Please check if it installed on your >>> system >> >> For example: >> https://ci.inria.fr/pharo-contribution/job/Bloc/63/console >> <https://ci.inria.fr/pharo-contribution/job/Bloc/63/console> >> >> >> Cheers, >> Alex >> > >

Feb. 14, 2016

Re: [Pharo-dev] More tests for new frameworks

by Alejandro Infante

If you plan to add it to an automatic CI Job with Hapao, I would recommend to load the following group of Spy2: âââââ (ConfigurationOfSpy2 project version: #stable) load: #HapaoCore âââââ This is going to load just the core of Spy and Hapao and will not load Roassal, GT-Inspector and GT-Debugger extensions. Cheers, Alejandro > On Feb 13, 2016, at 6:39 PM, stepharo <stepharo(a)free.fr> wrote: > > Yes I would even buy 20% coverage right now. > > Stef > > > Le 13/2/16 20:22, Max Leske a Ã©crit : >> How about enforcing coverage? I know that coverage tests donât say anything about the quality of the test cases but itâs (almost) always better to have some tests than none. I wouldnât set the bar too high either for coverage, maybe 60 or 70%. 100% is unrealistic, but 60 to 70 should be achievable with a couple of well written tests. >> >> Of course we would need a way to run coverage tests on the test suite. Do we have a tool for coverage tests? >> >>> On 13 Feb 2016, at 19:35, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi guys >>> >>> with damien cassou we had an interesting discussion. Basically we are teaching tests and we see that many Pharo subsystems are not really well tested. I wonder how we can change this. For example, we will have a new graphical core without any tests >>> and this is sad because tests could be really good to make sure that we will be able to move forward in the future. >>> I would like to get tests for Ring. >>> >>> Stef >>> >>> >>> >> >> > >

Feb. 14, 2016