- Pharo-dev - lists.pharo.org

Nautilus memory leak/hog crashing Pharo

by Johan Brichau

Hi, It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so. I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only. When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable. Is this a known issue? Any thoughts on what may be causing this? regards! Johan

June 25, 2014

Re: [Pharo-dev] ZnURL HTTP Download-to-file shortcut

by Sven Van Caekenberghe

Henrik, Good idea, added a slightly modified version (named the class to the operation) and added a test. In #bleedingEdge. Thank you ! Sven PS: I was almost forgotten that I added this ZnUrlOperation stuff, I am glad you found it. === Name: Zinc-HTTP-SvenVanCaekenberghe.403 Author: SvenVanCaekenberghe Time: 25 June 2014, 7:26:21.541717 pm UUID: 3032d604-6363-400b-b2ce-c9401ac7cf17 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.402 Add ZnHttpSaveContentsToFile to implement ZnUrl>>saveContentsToFile: (thx Henrik Sperre Johansen) with a new unit test Make sure to put the code where necessary in the proper package extensions Fix ZnClient>>#testLogging on Pharo 2 === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.25 Author: SvenVanCaekenberghe Time: 25 June 2014, 7:27:13.501891 pm UUID: 867946e0-c085-4a7a-a35d-0005a99c7e44 Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.24 Add ZnHttpSaveContentsToFile to implement ZnUrl>>saveContentsToFile: (thx Henrik Sperre Johansen) with a new unit test Make sure to put the code where necessary in the proper package extensions Fix ZnClient>>#testLogging on Pharo 2 == Name: Zinc-Tests-SvenVanCaekenberghe.213 Author: SvenVanCaekenberghe Time: 25 June 2014, 7:27:39.279953 pm UUID: 1b7415a0-72b5-4b9e-93fa-53749e05b3e5 Ancestors: Zinc-Tests-SvenVanCaekenberghe.212 Add ZnHttpSaveContentsToFile to implement ZnUrl>>saveContentsToFile: (thx Henrik Sperre Johansen) with a new unit test Make sure to put the code where necessary in the proper package extensions Fix ZnClient>>#testLogging on Pharo 2 === On 18 Jun 2014, at 15:07, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Hi! > Iâm a lazy bastard, but one which needs to download large files from time to time, hence I wrote the attached shortcut-operation for ZnUrls which gives me that without the extra fuss of manually creating a client etc. > Maybe just me who didnât spot existing functionality, or maybe itâd be a nice convenience operation to have in general distribution if you feel like picking better names/integrating it. > > Cheers, > Henry > > <DownloadToFile.cs>

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Chris Cunningham

Hi. On Wed, Jun 25, 2014 at 8:06 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com > >: > > 2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > Slot > \SimpleSlot (current iv slot) > > > Yes, the naming of that oneâ¦ I think we just need to take the freedom of > iterating. > For now I called it âInstanceVariableSlotâ, but that might be confusing > and it is a long word. > > > but is less confusing than âSimpleSlotâ, which basically says nothing, IMO > > > What about SimpleInstanceVariableSlot? (just kidding) > > I don't like over descriptive class names. Because they restrict you > from using it for other, unexpected, purposes or contexts. > > > The question to me is why this is "over descriptive". We have a tradition > here to be descriptive and intention revealing. It happens everywhere > except when it comes to instance variables it is instVarAt: instVarNamed: > etc. I never liked them. > Another question might be the usage context. Why is it called > InstanceVariableSlot anyway? Is there a difference if the slot is attached > to the instance side or class side? Isn't it really just a VariableSlot? > The context for the instance is where it is used. Asking an object for > instance variables and class instance variables could just return a > collection of VariableSlots, no? > Instances have instanceVariables, and classes have instanceVariables. There are also ClassVariables, which are a completely different thing (and commonly referred to directly from instance, class, and subclasses directly). It would be good not to make this any more complex (confusing?) than those concepts already are. -cbc > > Norbert > >

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Marcus Denker

On 25 Jun 2014, at 17:32, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 25 juin 2014, at 14:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Hi, >> >> Already in Pharo3 all instance variables are described using meta-objects (so called slots). >> >> To make it easier to access the slots, I added some simple methods to ClassDescription on 4.0 043, >> Now we can do e.g.: >> >> Context slots >> Context allSlots >> >> Point hasSlotNamed: #x >> Point slotNamed: #x >> >> e.g. the slot âxâ of Point knows how to reflectively read itself from a point: >> >> (Point slotNamed: #x) read: 5@3 > > Now we should be careful that the reflective APIs for slots at object-level and at class-level don't clash. > What I means is that if "Point slotNamed: #x" return a slot what is the selector that satisfies "Point ?: #superclass" --> Object. > > It's difficult to have an elegant and consistent naming scheme because we lack precise terminology. > For example when we talk about an instance variable, do we refer to the declaration of an iv in a class or to the value bound to an iv in a given instance of that class? > Right now it is not clear: compare current class-level reflective API (#hasInstVarNamed: #instVarNames & co) to the object-level one (#instVarNamed: #instVarNamed:put: & co). > I'm afraid that if we don't pay attention, we will have the same confusion when talking about slots. > > A slot is the *specification* of a variable that is accessible to the instances of a class. > So I think that the term slot should be reserved for methods of the class-level reflective API, as Marcus proposes with these new methods. > > So now what should be the new reflective API at the object-level? > Note that a slot doesn't necessarily define an instance variable, a slot could represent a shared variable like a class variable for example. > So I'm not sure that #instVarNamed: and #instVarNamed:put are still good names (even if they are backward compatible)... > Maybe #variableNamed: and #variableNamed:put:? > Or #valueOfSlotNamed: and #setValueOfSlotNamed:to:? > I think I dislike both, so I hope you have better ideas :) > > Sorry to be the annoying nitpicker :), I know I tend to be fussy with terminology. > But terminology determines APIs: ill-defined terminology is a step towards bad APIs. > Yesâ¦ the problem is that the âSlot meta objectâ and the âSlot that stores somethingâ use the same nameâ¦ this was not a problem for instance variables as the where not reified. maybe on the class side it could be Point slotDefinitionNamed: but nice it is notâ¦ or we maybe we use #resolveSlot: as the layoutâ¦. Marcus

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Camille Teruel

On 25 juin 2014, at 17:06, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > >> 2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>> On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>> >>>>> Slot >>>>> \SimpleSlot (current iv slot) >>>> >>>> Yes, the naming of that oneâ¦ I think we just need to take the freedom of iterating. >>>> For now I called it âInstanceVariableSlotâ, but that might be confusing and it is a long word. >>> >>> but is less confusing than âSimpleSlotâ, which basically says nothing, IMO >> >> What about SimpleInstanceVariableSlot? (just kidding) >> >> I don't like over descriptive class names. Because they restrict you >> from using it for other, unexpected, purposes or contexts. >> > > The question to me is why this is "over descriptive". We have a tradition here to be descriptive and intention revealing. It happens everywhere except when it comes to instance variables it is instVarAt: instVarNamed: etc. I never liked them. > Another question might be the usage context. Why is it called InstanceVariableSlot anyway? > Is there a difference if the slot is attached to the instance side or class side? No indeed there is no difference, an iv slot attached to the class side is still an instance variable slot that happens to be declared in a metaclass and assigned in its unique instance and in its many subinstances. > Isn't it really just a VariableSlot? It sounds too generic to me as custom slots can represent other kind of variables like class-variables: ClassSlot>>read: anObject ^ value ClassSlot>>write: anObject to: aValue value := aValue Note that iv slots are the default kind of slot, so no matter how long it seems to type InstanceVariableSlot, you won't have to type it. For example the current class builder can be used like this: PharoClassInstaller make: [ :builder | builder name: #MyClass; slots: { #a. #b => CustomSlot } ]. #a will be a slot of the default kind (currently named Slot) and #b will be a CustomSlot. > The context for the instance is where it is used. Asking an object for instance variables and class instance variables could just return a collection of VariableSlots, no? > Norbert

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Camille Teruel

On 25 juin 2014, at 14:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Already in Pharo3 all instance variables are described using meta-objects (so called slots). > > To make it easier to access the slots, I added some simple methods to ClassDescription on 4.0 043, > Now we can do e.g.: > > Context slots > Context allSlots > > Point hasSlotNamed: #x > Point slotNamed: #x > > e.g. the slot âxâ of Point knows how to reflectively read itself from a point: > > (Point slotNamed: #x) read: 5@3 Now we should be careful that the reflective APIs for slots at object-level and at class-level don't clash. What I means is that if "Point slotNamed: #x" return a slot what is the selector that satisfies "Point ?: #superclass" --> Object. It's difficult to have an elegant and consistent naming scheme because we lack precise terminology. For example when we talk about an instance variable, do we refer to the declaration of an iv in a class or to the value bound to an iv in a given instance of that class? Right now it is not clear: compare current class-level reflective API (#hasInstVarNamed: #instVarNames & co) to the object-level one (#instVarNamed: #instVarNamed:put: & co). I'm afraid that if we don't pay attention, we will have the same confusion when talking about slots. A slot is the *specification* of a variable that is accessible to the instances of a class. So I think that the term slot should be reserved for methods of the class-level reflective API, as Marcus proposes with these new methods. So now what should be the new reflective API at the object-level? Note that a slot doesn't necessarily define an instance variable, a slot could represent a shared variable like a class variable for example. So I'm not sure that #instVarNamed: and #instVarNamed:put are still good names (even if they are backward compatible)... Maybe #variableNamed: and #variableNamed:put:? Or #valueOfSlotNamed: and #setValueOfSlotNamed:to:? I think I dislike both, so I hope you have better ideas :) Sorry to be the annoying nitpicker :), I know I tend to be fussy with terminology. But terminology determines APIs: ill-defined terminology is a step towards bad APIs. > > ==> 5 > > Marcus

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Esteban A. Maringolo

2014-06-25 12:06 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > I don't like over descriptive class names. Because they restrict you > from using it for other, unexpected, purposes or contexts. > The question to me is why this is "over descriptive". We have a tradition > here to be descriptive and intention revealing. It happens everywhere except > when it comes to instance variables it is instVarAt: instVarNamed: etc. I > never liked them. I agree with you here, it is like those instVar* selectors are obfuscated only to show they are "low level stuff". > Another question might be the usage context. Why is it called > InstanceVariableSlot anyway? Is there a difference if the slot is attached > to the instance side or class side? Isn't it really just a VariableSlot? The > context for the instance is where it is used. Asking an object for instance > variables and class instance variables could just return a collection of > VariableSlots, no? "Simplicity is the ultimate sophistication", so finding a good intention revealing selector is not an easy task. But IMO the naming is as important as other factors, because you'll keep referring them in many contexts, and that will help build good mental models. I like how VariableSlot sounds. But aren't slots meant to be used always in the context of variables? If so, Variable might be read as an attribute (that varies, in shape, etc.). Many of us are non native speakers, so this is an important factor too. Regards!

June 25, 2014

Re: [Pharo-dev] can I be added to the pharoextras team?

by Damien Cassou

On Wed, Jun 25, 2014 at 4:47 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > my sthub username is pdebruic done -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Marcus Denker

On 25 Jun 2014, at 14:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 25 Jun 2014, at 14:16, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Very nice! >> >> Next would be an example of how to specialize a slot :) >> > > Yes, the next steps are: > > - introduce abstract superclass for Slot > For now there is a subclass InstanceVariableSlot, all Slot instances have been migrated. > - Opal needs to delegate code generation to the Slot. > This is now done. Opal now, in the semantic analysis phase, annotates slot accesses as OCSlotVariable (OCInstanceVariable we can remove later). Then when generating, it just forwards to the slot: emitStore: methodBuilder slot emitStore: methodBuilder To allow Slots subclasses to be implemented without knowledge of bytecode, the next thing to add it the fallback: > - The abstract slot generates by default reflective read/write access code Marcus

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Norbert Hartl

Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>>> Slot >>>> \SimpleSlot (current iv slot) >>> >>> Yes, the naming of that oneâ¦ I think we just need to take the freedom of iterating. >>> For now I called it âInstanceVariableSlotâ, but that might be confusing and it is a long word. >> >> but is less confusing than âSimpleSlotâ, which basically says nothing, IMO > > What about SimpleInstanceVariableSlot? (just kidding) > > I don't like over descriptive class names. Because they restrict you > from using it for other, unexpected, purposes or contexts. > The question to me is why this is "over descriptive". We have a tradition here to be descriptive and intention revealing. It happens everywhere except when it comes to instance variables it is instVarAt: instVarNamed: etc. I never liked them. Another question might be the usage context. Why is it called InstanceVariableSlot anyway? Is there a difference if the slot is attached to the instance side or class side? Isn't it really just a VariableSlot? The context for the instance is where it is used. Asking an object for instance variables and class instance variables could just return a collection of VariableSlots, no? Norbert

June 25, 2014