June 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50143 Home: https://github.com/pharo-project/pharo-core

June 30, 2015

Re: [Pharo-dev] pharo / Cairo / MacOS 10.6.8

by Nicolas Anquetil

will have a look at it thanks nicolas On 30/06/2015 11:01, Stephan Eggermont wrote: > On 30-06-15 10:55, Nicolas Anquetil wrote: >> >> While giving a course on Moose/Pharo last week, one of the attendants >> had a problem that we could not resolve with unfound cairo library on >> pharo 4.0 / MacOS 10.6.8 (simingly an old one) >> >> we had no chances with the instructions posted there: >> http://cairographics.org/download/ >> >> anyone knows how to solve the problem? > > Well known issue indeed. The cairo library was compiled with a wrong > dependency. > > Just copy the libcairo.2.dylib (in Contents/MacOS/Plugins when you do > Show Package Contents on the vm app) from the 18 september 2013 vm. > > http://forum.world.st/Last-Pharo-VM-on-mac-os-x-10-6-8-td4777304.html > > Stephan > > >

June 30, 2015

Re: [Pharo-dev] Stack

by Guillermo Polito

I will open an issue ^^ El mar., 30 de jun. de 2015 a la(s) 11:20 a. m., Marcus Denker < marcus.denker(a)inria.fr> escribiÃ³: > > On 30 Jun 2015, at 11:16, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Another *detail* is that LinkedList's design is heavily tied to the VM. > Our linked list implementation can contain any object that *looks like a > link*, meaning > - in the higher level they have to understand the message nextLink and > nextLink: > - in the lower level, if it is a linked list used by the VM, the nextLink > should be the first inst var of the object. > > What I mean with this is that we should be careful when changing linked > list. Changing its internal representation may crash your image ^^. > > > We should really rename it to âProcessListâ and put a comment âdo not > touch!!!â, then make a copy and have a Linked List that we can changeâ¦ > there are many issue tracker entries related to the linked list, as people > try to use it but nobody dares to change it. > > Marcus > >

June 30, 2015

Re: [Pharo-dev] Stack

by Thierry Goubier

2015-06-30 11:30 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > What he means is that just because subclassing is available as a technical > mechanism, we should only use it for modeling subtyping and not > implementation reuse (only in very few cases this is actually useful in the > long run). > Given how Smalltalk defines types and subtyping, I consider that subclassing should be used for implementation reuse and not for subtyping. Any Smalltalk class hierarchy which has instance variables defined in the superclass does implementation sharing/reuse. Modeling is another consideration. (I still consider the meaning of Stef phrase confusing...) > For reference, this goes under the name of Liskov substitution principle > and one nice article that explains it is this one: > http://www.objectmentor.com/resources/articles/lsp.pdf > This reference is too much into how that particular principle turns out in an ill-designed type and code sharing mechanism (C++) to be of much help ;) Thierry > > > Cheers, > Doru > > > On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2015-06-30 11:00 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >>> >>>> >>> What I mean is that this is not good to have subclassing when we can use >>> subclassing. >>> >> >> Are you sure you mean that? *confused* >> >> Thierry >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 30, 2015

Re: [Pharo-dev] Stack

by Tudor Girba

What he means is that just because subclassing is available as a technical mechanism, we should only use it for modeling subtyping and not implementation reuse (only in very few cases this is actually useful in the long run). For reference, this goes under the name of Liskov substitution principle and one nice article that explains it is this one: http://www.objectmentor.com/resources/articles/lsp.pdf Cheers, Doru On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > > > 2015-06-30 11:00 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >>> >> What I mean is that this is not good to have subclassing when we can use >> subclassing. >> > > Are you sure you mean that? *confused* > > Thierry > -- www.tudorgirba.com "Every thing has its own flow"

June 30, 2015

Re: [Pharo-dev] Stack

by Thierry Goubier

2015-06-30 11:00 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> > What I mean is that this is not good to have subclassing when we can use > subclassing. > Are you sure you mean that? *confused* Thierry

June 30, 2015

Re: [Pharo-dev] Stack

by Marcus Denker

> On 30 Jun 2015, at 11:16, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Another detail is that LinkedList's design is heavily tied to the VM. Our linked list implementation can contain any object that *looks like a link*, meaning > - in the higher level they have to understand the message nextLink and nextLink: > - in the lower level, if it is a linked list used by the VM, the nextLink should be the first inst var of the object. > > What I mean with this is that we should be careful when changing linked list. Changing its internal representation may crash your image ^^. > We should really rename it to âProcessListâ and put a comment âdo not touch!!!â, then make a copy and have a Linked List that we can changeâ¦ there are many issue tracker entries related to the linked list, as people try to use it but nobody dares to change it. Marcus

June 30, 2015

Re: [Pharo-dev] Stack

by Guillermo Polito

Another *detail* is that LinkedList's design is heavily tied to the VM. Our linked list implementation can contain any object that *looks like a link*, meaning - in the higher level they have to understand the message nextLink and nextLink: - in the lower level, if it is a linked list used by the VM, the nextLink should be the first inst var of the object. What I mean with this is that we should be careful when changing linked list. Changing its internal representation may crash your image ^^. El mar., 30 de jun. de 2015 a la(s) 11:10 a. m., Max Leske < maxleske(a)gmail.com> escribiÃ³: > > > On 30 Jun 2015, at 11:00, stepharo <stepharo(a)free.fr> wrote: > > > > > > > > Le 28/6/15 19:00, Sven Van Caekenberghe a Ã©crit : > >>> On 28 Jun 2015, at 17:59, Max Leske <maxleske(a)gmail.com> wrote: > >>> > >>> > >>>> On 28 Jun 2015, at 17:22, stepharo <stepharo(a)free.fr> wrote: > >>>> > >>>> Hi guys > >>>> > >>>> is there a real reason for Stack being a subclass of LinkedLink? > >>> 1. You donât need to adjust an internal data structure (grow, shrink, > move, sort) to update the stack but only move references. > > But it is used in practice? > > Because Stack could use a LinkedList and you get the same benefits and > not stupid methods that do not make sense for Stack. > > agreed. > > > > >>> 2. The interface is pretty similar > > > > No there are not :) > > Stack is push pop top not insert after:..... > > or this is a strange stack. > > What I meant was: Linked list provides an interface that allows for stack > operations. Not that the naming conventions are the same. > > >> 3. It is an implementation detail/technique, it is indeed not as if > Stack is-a LinkedList (from that point of view it is confusing) > > > > What I mean is that this is not good to have subclassing when we can use > subclassing. > > We remove the fact that Dictionary is a subclass of Set for this reason. > > > > You asked for reasons. I didnât say they were *good* reasons :) > > >> > >>>> Stef > >>>> > >>> > >> > >> > > > > > > >

June 30, 2015

Re: [Pharo-dev] Stack

by Max Leske

> On 30 Jun 2015, at 11:00, stepharo <stepharo(a)free.fr> wrote: > > > > Le 28/6/15 19:00, Sven Van Caekenberghe a Ã©crit : >>> On 28 Jun 2015, at 17:59, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> >>>> On 28 Jun 2015, at 17:22, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Hi guys >>>> >>>> is there a real reason for Stack being a subclass of LinkedLink? >>> 1. You donât need to adjust an internal data structure (grow, shrink, move, sort) to update the stack but only move references. > But it is used in practice? > Because Stack could use a LinkedList and you get the same benefits and not stupid methods that do not make sense for Stack. agreed. > >>> 2. The interface is pretty similar > > No there are not :) > Stack is push pop top not insert after:..... > or this is a strange stack. What I meant was: Linked list provides an interface that allows for stack operations. Not that the naming conventions are the same. >> 3. It is an implementation detail/technique, it is indeed not as if Stack is-a LinkedList (from that point of view it is confusing) > > What I mean is that this is not good to have subclassing when we can use subclassing. > We remove the fact that Dictionary is a subclass of Set for this reason. > You asked for reasons. I didnât say they were *good* reasons :) >> >>>> Stef >>>> >>> >> >> > >

June 30, 2015

Re: [Pharo-dev] pharo / Cairo / MacOS 10.6.8

by Stephan Eggermont

On 30-06-15 10:55, Nicolas Anquetil wrote: > > While giving a course on Moose/Pharo last week, one of the attendants > had a problem that we could not resolve with unfound cairo library on > pharo 4.0 / MacOS 10.6.8 (simingly an old one) > > we had no chances with the instructions posted there: > http://cairographics.org/download/ > > anyone knows how to solve the problem? Well known issue indeed. The cairo library was compiled with a wrong dependency. Just copy the libcairo.2.dylib (in Contents/MacOS/Plugins when you do Show Package Contents on the vm app) from the 18 september 2013 vm. http://forum.world.st/Last-Pharo-VM-on-mac-os-x-10-6-8-td4777304.html Stephan

June 30, 2015