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

[Pharo-project] setsockopt: No,buffer space available

by Philippe Marschall

Hi I have some code that runs a protocol on consisting of 8k packets over TCP. This works fantastically well on Linux. However on Mac OS I get a lot of failed request. Investigating further I found the following error log: 16.02.12 18:44:12.485 [0x0-0x95095].com.squeak.Cog: setsockopt: No buffer space available After some more investigation I found out that I do set SO_SNDBUF and SO_RCVBUF to 8192 (remember 8k packets) but these calls fail. That's on Mac OS 10.7, I'm not sure but the way I remember it the code was working on Mac OS 10.6 Cheers Philippe

Feb. 16, 2012

[Pharo-project] Refactoring Questions

by Camillo Bruni

after having a look with ben at the current refactoring implementation in Nautilus we found that the "Extract into temporary" refactoring is most of the time not that useful. I wonder wether it would make sense to loosen the requirements on conserving behavior... consider the following example where we extract "self foo" into the temporary "tmp": =========================================== foo ^ self foo even ifTrue: [ self foo * 2 ] ifFalse: [ self foo / 2 ] actual result ============================= foo | tmp | tmp := self foo. ^ tmp even ifTrue: [ self foo * 2 ] ifFalse: [ self foo / 2 ] proposed result =========================== foo | tmp | tmp := self foo. ^ tmp even ifTrue: [ tmp * 2 ] ifFalse: [ tmp / 2 ] =========================================== note that the proposed solution is not side-effect free. However the given refactoring hardly makes ever sense, since this action can be easily done manually in less time. given that you first have to find the proper menu-item. best cami

Feb. 16, 2012

Re: [Pharo-project] Is the plan to replace FileStream by FSStream?

by Camillo Bruni

there are some serious implications when doing so The main issue arises from: FileStream is 0 indexed FSStream is 1 indexed but we should reason about this and what to do exactly On 2012-02-16, at 18:45, Luc Fabresse wrote: > Hi, > > reading this: http://code.google.com/p/pharo/issues/detail?id=5303 > I wonder if the plan is to replace FileStream by FSStream? > > #Luc >

Feb. 16, 2012

Re: [Pharo-project] TabbedPane Class/ Package / Workspace browsers

by Eliot Miranda

Hi Krish, On Wed, Feb 15, 2012 at 10:15 PM, S Krish <krishnamachari.sudhakar(a)gmail.com > wrote: > > > Just this quick n usable prototype.. ? > I really like the look of the tabs. But can you not push the tabs up so that they are at the same level as the open/close/collapse buttons and replace the title? Shame to loose so much screen real-estate to the tabs. That's why in my own hack I use a pop-up menu in the title bar. I would use a tab containing just "+" for "add a tab", and add an "x" button to each tab for closing it. > Any comments of its utility.. I for one would rather prefer having > everything navigable from one Tabbed Pane.. > > Panes capable of rendering about every window of the basic tools of > Pharo.. workspace, Finder, ScriptManager, possibly Transcript as a console > collapsible as reqd > > Akin to the eclipse but not really that intensively single windowed.. > there are uses for spawning separate windows.. > > -- best, Eliot

Feb. 16, 2012

[Pharo-project] Is the plan to replace FileStream by FSStream?

by Luc Fabresse

Hi, reading this: http://code.google.com/p/pharo/issues/detail?id=5303 I wonder if the plan is to replace FileStream by FSStream? #Luc

Feb. 16, 2012

Re: [Pharo-project] Traits in PHP

by Mariano Martinez Peck

On Thu, Feb 16, 2012 at 3:04 PM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > I have an idea about the state issue in traits, maybe you thought about it > too... I was thinking that the definition of representing something as > state or not should be responsibility of the implementation, that is the > class (nothing new here), so we delay that decision until the trait is > used. > So, maybe what we need is a way to indicate that a message send in a trait > is not really that in a class... For example: > > TraitA>>m1 > > ^self name first > > Object subclass: #ClassA > uses: #TraitA > mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') > ... bla bla. > > So, #m1 in ClassA would look like: > > ClassA>>m1 > > ^firstName first > > Of course this implies some complexity when copying the behavior from the > trait to the class (we can not use the same compiled method), also > maintaining the relationship with changes on the trait (what happens if #m1 > is changed in TraitA and does not send #name anymore), etc. > First class slot (a la Self) would be a nicer solution, > For the slower ones ... why would first class slots solves this? I didn't get it. Thanks! > but I feel that that implies a more radical change on the object model, > vm, etc. and also has the disadvantages of making all state public (unless > something is done to avoid that). > > At the same time, I would like to point out that having subclassing and > traits at the same time as sharing mechanism is kind of confusing, > programmers do not know which one is better to use, should I subclass or > use a trait? how I'm sure which one is better? etc. We talk about this when > you came to Argentina, do you remember? A student did his tesis about > removing subclassing and using only traits as sharing tool, but the results > were not as good as I expected (sadly, the thesis is written in Spanish...) > > Anyway, my two cents > Hernan. > > > On Thu, Feb 16, 2012 at 4:56 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote: >> >> > what is the difference with the current trait implementation in pharo? >> I could not see the differenceâ¦ >> >> Stefan replied but what I wanted to say is that I would like to have the >> time to see how we can introduce more nicely traits. >> Right now there are edges where this is ugly and also rethink the system. >> I think that if we would have first class slots we could have >> traits with state in a much better fashion. >> >> Stef >> >> > On Wed, Feb 15, 2012 at 7:45 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> > Indeed. Now I would love that we rethink our trait implementation and >> tool support but no time. >> > >> > On Feb 15, 2012, at 6:40 AM, blake wrote: >> > >> > > This is kinda cool: >> > > >> > > http://phpmaster.com/using-traits-in-php-5-4/ >> > > >> > >> > >> > >> > >> > >> > -- >> > HernÃ¡n Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: hernan.wilkinson(a)10Pines.com >> > site: http://www.10Pines.com >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> > >> >> >> > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > > -- Mariano http://marianopeck.wordpress.com

Feb. 16, 2012

Re: [Pharo-project] garbage collection

by Milan Mimica

When Magma is down there are no instances of MaTimer. There are 3 instances of MaServerSocket though. On 15 February 2012 18:41, Chris Muller <asqueaker(a)gmail.com> wrote: > Milan, try checking whether the number of instances of MaTimer > correlate to the number of instances of Semaphore you are seeing. > > - Chris > > On Tue, Feb 14, 2012 at 2:01 PM, Milan Mimica <milan.mimica(a)gmail.com> > wrote: > > This is more of a GC theory question perhaps, but I do have practical > > problems, so: I'm trying to figure out how come my headless Pharo 1.3 > image > > with fairly recent Cog running Magma ran out of Semaphores. I know there > is > > a fixed limit on number of semaphores Cog can handle, and only Magma and > RFB > > server have been running on this image for two months, and there wasn't > any > > heavy load whatsoever, so something must be leaking semaphores - or more > > likely - something must be leaking objects having reference(s) to > > semaphore(s). I am not leaking sockets btw. > > > > At the moment there is about 1400 instances of Semaphore class, and > around > > 400 after GC. > > So first question is: Suppose I haven't run GC manually, could the > semaphore > > limit be hit? > > > > 400 is still too high for a idling image, don't you think? > > > > Anyway, what I try next is to shut down Magma completely and try to clean > > the memory by hand. I notice some MaServerSockets are still floating > around > > so I track the pointers and I find that all the references are circular! > > Question two: Does Pharo's GC solve circular references? If yes, how > good is > > it at it? > > > > But then, thinking more about it, the whole running image is one big > graph > > of circular references, you wouldn't want the GC to clean that :) So how > > does it really work? That's my naive view anyway. > > > > After I wrote all this I figure I'm better of taking a fresh new image > and > > load what I need into it, even if I have to do it every two months. Not > > saving the image is also an option. Yeah, I think I'm going to do just > that. > > I found my solution, at least this e-mail served for something. Since I > > don't have a blog I'll send it anyway. > > > > > > -- > > Milan Mimica > > > > -- Milan Mimica http://sparklet.sf.net

Feb. 16, 2012

Re: [Pharo-project] Traits in PHP

by Nicolas Passerini

I think it would be very nice to be able to apply a trait directly to an object, without having to create a new class. This is possible for example in scala: val myObject = new MyClass with MyTrait I have programmed a simple implementation in Pharo which allows you to do: myObject := (MyClass with: MyTrait) new. The implementation is only a proof of concept and has some issues that should be addressed before being able to use it in a real program, but I can make it available if someone is interested. What do you think about this? On Thu, Feb 16, 2012 at 11:04 AM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > I have an idea about the state issue in traits, maybe you thought about it > too... I was thinking that the definition of representing something as > state or not should be responsibility of the implementation, that is the > class (nothing new here), so we delay that decision until the trait is > used. > So, maybe what we need is a way to indicate that a message send in a trait > is not really that in a class... For example: > > TraitA>>m1 > > ^self name first > > Object subclass: #ClassA > uses: #TraitA > mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') > ... bla bla. > > So, #m1 in ClassA would look like: > > ClassA>>m1 > > ^firstName first > > Of course this implies some complexity when copying the behavior from the > trait to the class (we can not use the same compiled method), also > maintaining the relationship with changes on the trait (what happens if #m1 > is changed in TraitA and does not send #name anymore), etc. > First class slot (a la Self) would be a nicer solution, but I feel that > that implies a more radical change on the object model, vm, etc. and also > has the disadvantages of making all state public (unless something is done > to avoid that). > > At the same time, I would like to point out that having subclassing and > traits at the same time as sharing mechanism is kind of confusing, > programmers do not know which one is better to use, should I subclass or > use a trait? how I'm sure which one is better? etc. We talk about this when > you came to Argentina, do you remember? A student did his tesis about > removing subclassing and using only traits as sharing tool, but the results > were not as good as I expected (sadly, the thesis is written in Spanish...) > > Anyway, my two cents > Hernan. > > > On Thu, Feb 16, 2012 at 4:56 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote: >> >> > what is the difference with the current trait implementation in pharo? >> I could not see the differenceâ¦ >> >> Stefan replied but what I wanted to say is that I would like to have the >> time to see how we can introduce more nicely traits. >> Right now there are edges where this is ugly and also rethink the system. >> I think that if we would have first class slots we could have >> traits with state in a much better fashion. >> >> Stef >> >> > On Wed, Feb 15, 2012 at 7:45 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> > Indeed. Now I would love that we rethink our trait implementation and >> tool support but no time. >> > >> > On Feb 15, 2012, at 6:40 AM, blake wrote: >> > >> > > This is kinda cool: >> > > >> > > http://phpmaster.com/using-traits-in-php-5-4/ >> > > >> > >> > >> > >> > >> > >> > -- >> > HernÃ¡n Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: hernan.wilkinson(a)10Pines.com >> > site: http://www.10Pines.com >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> > >> >> >> > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > >

Feb. 16, 2012

Re: [Pharo-project] garbage collection

by Henrik Johansen

On Feb 15, 2012, at 5:53 PM, Igor Stasenko wrote: > On 15 February 2012 11:26, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> I sort of doubt Magma uses anything registering external objects but the standard Socketsâ¦ >> While interrupting finalization process _could_ be a culprit, I'd rather watch for something like what happened with the InputEventFetcher, where registration/deregistration ends up not being symmetric. >> >> Perhaps Magma tries to reuse existing Socket instances by calls to initialize:/acceptFrom: for example? >> >> I think changing ExternalSemaphoreTable to a weak structure would be a really bad idea btw. >> All of a sudden, you free up slots which were previously taken for insertion of old objects. >> >> There is no guarantee the external user of the semaphore will stop using the index it was given just because the image no longer holds a reference to the object which used to occupy that index. >> >> So if you register a new object in the same slot, in the case of Sockets at least, you could potentially end up responding to signals from both the old external user, and the new one. >> >> TLDR; Any object registered in this table by definition needs explicit cleanup of external users before they are GC'd. Thus, making the table weak makes no sense. >> > > Yes, that could happen. > Well, then the only option is to check what code producing leaks. And > that's not trivial, since > you cannot trace references back to semaphore's original owner. :( > > > -- > Best regards, > Igor Stasenko. > It's not such a big task to review the current users, there are like 5 of them in the base image. AFAICT: 1) InputEventFetcher, this has been bug-fixed once already. No leaks as long as it has a single entry in startup/shutdown lists. 2) Sockets, which, to my knowledge work OK with the weak finalization. 3) AsyncFile, only done correctly if #close'd at EOL. No weak cleanup done it seems, could be changed to work like Sockets. 4) StandardFileStream url opening, should be modified to use an ensure: block. Only applicable when running in a browser though, unlikely to be a large issue. 5) NetNameResolver, never unregisters the semaphore, and leaks one whenever network needs (re)initialization. Snapshot? Image quit? Arbitrary points during execution? Reading the plugin source would tell the real cases I guess. A probable culprit in this case, I would say. I opened http://code.google.com/p/pharo/issues/detail?id=5310 , which contains proposed changes related to 3-5. I also opened 2 additional issues for things I ran into, but didn't do as it wasn't worth the effort/strictly related: 5311: Rewrite AsyncFile to have weak finalization for guaranteed cleanup of external objects 5312: Move StandardFileStream browserRequest protocol functionality to a separate package, and deprecate the protocol itself. The main purpose of the methods in this protocol has nothing to do with FileStreams, but rather performing navigation in a Browser when Pharo is run as a plugin. Cheers, Henry

Feb. 16, 2012

Re: [Pharo-project] Traits in PHP

by Hernan Wilkinson

I have an idea about the state issue in traits, maybe you thought about it too... I was thinking that the definition of representing something as state or not should be responsibility of the implementation, that is the class (nothing new here), so we delay that decision until the trait is used. So, maybe what we need is a way to indicate that a message send in a trait is not really that in a class... For example: TraitA>>m1 ^self name first Object subclass: #ClassA uses: #TraitA mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') ... bla bla. So, #m1 in ClassA would look like: ClassA>>m1 ^firstName first Of course this implies some complexity when copying the behavior from the trait to the class (we can not use the same compiled method), also maintaining the relationship with changes on the trait (what happens if #m1 is changed in TraitA and does not send #name anymore), etc. First class slot (a la Self) would be a nicer solution, but I feel that that implies a more radical change on the object model, vm, etc. and also has the disadvantages of making all state public (unless something is done to avoid that). At the same time, I would like to point out that having subclassing and traits at the same time as sharing mechanism is kind of confusing, programmers do not know which one is better to use, should I subclass or use a trait? how I'm sure which one is better? etc. We talk about this when you came to Argentina, do you remember? A student did his tesis about removing subclassing and using only traits as sharing tool, but the results were not as good as I expected (sadly, the thesis is written in Spanish...) Anyway, my two cents Hernan. On Thu, Feb 16, 2012 at 4:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote: > > > what is the difference with the current trait implementation in pharo? I > could not see the differenceâ¦ > > Stefan replied but what I wanted to say is that I would like to have the > time to see how we can introduce more nicely traits. > Right now there are edges where this is ugly and also rethink the system. > I think that if we would have first class slots we could have > traits with state in a much better fashion. > > Stef > > > On Wed, Feb 15, 2012 at 7:45 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Indeed. Now I would love that we rethink our trait implementation and > tool support but no time. > > > > On Feb 15, 2012, at 6:40 AM, blake wrote: > > > > > This is kinda cool: > > > > > > http://phpmaster.com/using-traits-in-php-5-4/ > > > > > > > > > > > > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > > > > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Feb. 16, 2012