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

Re: [Pharo-project] moved repos to gemstone

by Sven Van Caekenberghe

On 15 Feb 2012, at 18:52, Lukas Renggli wrote: >>>> A quick comparison shows that the Pharo fork is based on outdated code and has some methods of the public API renamed. >>> >>> where's the other code located? I would like to check that. > > http://source.wiresong.ca/mc > >> Me too especially because I committed in FS on squeak source and not in Pharo so that colin can commit. Because originally I worked on PharoTaskForces. > > This is not how open-source works [1, 2]. Not even Pharo works like this. > >> In addition I do not see how we can control our life if we cannot publish on the repository of a part that should be central to us. > > I understand that you want to change things. Also I understand that > the original project might be too slow, or that the authors might not > accept your changes. In this case it is only fair to do a proper fork > [3], to choose a new name, and a new namespace. And to live with all > the consequences. > > Lukas > > [1] http://producingoss.com/en/getting-started.html#developer-guidelines > [2] http://subversion.apache.org/docs/community-guide/general.html > [3] http://producingoss.com/en/forks.html#forks-initiating > > -- > Lukas Renggli > www.lukas-renggli.ch Cooperation has to be mutual. I don't know enough about the history of all this, but I completely fail to understand how someone who wrote something like FileSystem or RB would not find it interesting that his code would be included by default in Pharo (and thus support a mutual cooperation). Being in an image by default means much more usage and true OSS feedback, it will only improve things. We have to work together to make progress. Anyway, that is my opinion. Sven

Feb. 15, 2012

Re: [Pharo-project] annoying press "ok" when running tests (not headless)

by Tudor Girba

Hi, I am not sure I understand, so let's get more specific. We talk about one package which contains one Morph. I thought the purpose of UITheme is to encapsulate all decisions related to how a morph gets rendered. It's like a strategy. For example, we have UITheme>>plainGroupPanelBorderStyleFor: and this is called by the PlainGroupboxMorph. In the same style, I have: UITheme>>growlLabelColorFor: aGrowlMorph ^ Color white GrowlMorph>>labelColor ^ self theme growlLabelColorFor: self Is this not the intended way? Doru On 15 Feb 2012, at 18:04, Igor Stasenko wrote: > On 15 February 2012 17:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Feb 15, 2012, at 1:58 PM, Tudor Girba wrote: >> >>> Hi, >>> >>> It's not UIManager, but UITheme. I made it dependent on the UITheme in >>> the sense that I moved all the rendering code as an extension. I >>> thought this is the official way to get things working with Polymorph. >>> Did I get it wrong? >> >> I do not know. I'm still confused by the responsibility of UITheme vs UIManager vsâ¦ >> Now you do not want that every tools add method to UITheme because imagine that we do that >> then how each theme can be modular? >> > > Imo, it is simple: the right to use ui theme should have only those > object, which actually > responsible for ui: widgets and perhaps ui builders. > The rest of world should assume UITheme not exists. > > >> so far I do not have the right answer. >> Now GrowlMorph should have setting and get initialized from the UITheme settings >> >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> On Wed, Feb 15, 2012 at 1:54 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> On Feb 15, 2012, at 1:47 PM, Tudor Girba wrote: >>>> >>>>> Indeed, this is a project that is since too long on my to do list. >>>>> >>>>> I worked on Growl a bit as well, but we need to bring it further. I >>>>> just pushed the to do towards the top of the list :) I would be happy >>>>> to collaborate on this issue. >>>> >>>> Would be good. >>>> Doru could you fix the fact that if I remember correctly you make it dependent on the UIManager? >>>> or something like that? >>>> But we could really add it to the image so that we have vanishing messages :) >>>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Wed, Feb 15, 2012 at 1:38 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>> There is a Growl in Pharo. I improved it :) >>>>>> >>>>>> Stef >>>>>> >>>>>> On Feb 15, 2012, at 12:42 PM, Camillo Bruni wrote: >>>>>> >>>>>>> gargl.... >>>>>>> >>>>>>> we should have some non-interactive inform: like Growl on Mac. >>>>>>> The popups should just open but not block the interaction IMO. >>>>>>> >>>>>>> >>>>>>> On 2012-02-14, at 23:50, Igor Stasenko wrote: >>>>>>> >>>>>>>> i started tests and leaved image for a while, but when i went back >>>>>>>> hoping that it already finished, i discovered that it waiting for me >>>>>>>> to press ok >>>>>>>> and did not ran even 20% of all tests. >>>>>>>> >>>>>>>> Somewhere in GoferOperationTest>>testMerge >>>>>>>> it says 'No changes' and waits for the user to press 'ok' >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > > -- > Best regards, > Igor Stasenko. > -- www.tudorgirba.com Innovation comes in least expected form. That is, if it is expected, it already happened.

Feb. 15, 2012

Re: [Pharo-project] FSPath withExtension: bug

by Igor Stasenko

hmm.. i don't see if it will handle well a multiple extensions which sometimes is nice. (btw, why FS have to even care about it? a file name is a string. whatever you put there) Perhaps there should be two methods: one for adding extra extension (just unconditionally concatenate) and second for replacing extension #addExtension: + #changeExtension: (or #replaceExtension: ,if you want). Because what if i want to have extensions like .tar.gz? tarFile := (FSFilesystem disk workingDirectory / 'file.tar'). "zip stuff here" newName := tarFile addExtension: 'gz'. apparently new name should have .tar.gz extension while with current implementation of #withExtension: , it will replace the original one and put just .gz On 15 February 2012 19:42, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > OK, but don't hardcode the extensionDelimiter :) > > > Le 15 fÃ©vrier 2012 16:20, Camillo Bruni <camillobruni(a)gmail.com> a Ã©crit : >> makes more sense to me >> On 2012-02-15, at 15:29, Esteban Lorenzano wrote: >> >>> hi, >>> >>> FSPath>>#withExtension: Â is ignoring adding extension if extension is equal to end of basename. >>> >>> For example, if I want to produce: >>> >>> (FSFilesystem disk workingDirectory / 'Host') withExtension: 'st'. >>> >>> I should receive: >>> >>> /path/to/Host.st >>> >>> but I actually receive: >>> >>> /path/to/Host >>> >>> that can be fixed replacing >>> >>> FSPath>>#withExtension: extension >>> Â Â Â | basename name | >>> Â Â Â basename := self basename. >>> Â Â Â ^ (basename endsWith: extension) >>> Â Â Â Â Â Â Â ifTrue: [ self ] >>> Â Â Â Â Â Â Â ifFalse: >>> Â Â Â Â Â Â Â Â Â Â Â [name := basename copyUpToLast: self extensionDelimiter. >>> Â Â Â Â Â Â Â Â Â Â Â self withName: name extension: extension] >>> >>> with: >>> >>> FSPath>>#withExtension: extension >>> Â Â Â | basename name | >>> Â Â Â basename := self basename. >>> Â Â Â ^ (basename endsWith: '.', extension) >>> Â Â Â Â Â Â Â ifTrue: [ self ] >>> Â Â Â Â Â Â Â ifFalse: >>> Â Â Â Â Â Â Â Â Â Â Â [name := basename copyUpToLast: self extensionDelimiter. >>> Â Â Â Â Â Â Â Â Â Â Â self withName: name extension: extension] >>> >>> but I don't know if that would be a good solution :) >>> >>> best, >>> Esteban >> >> > -- Best regards, Igor Stasenko.

Feb. 15, 2012

Re: [Pharo-project] FSPath withExtension: bug

by Nicolas Cellier

OK, but don't hardcode the extensionDelimiter :) Le 15 fÃ©vrier 2012 16:20, Camillo Bruni <camillobruni(a)gmail.com> a Ã©crit : > makes more sense to me > On 2012-02-15, at 15:29, Esteban Lorenzano wrote: > >> hi, >> >> FSPath>>#withExtension: Â is ignoring adding extension if extension is equal to end of basename. >> >> For example, if I want to produce: >> >> (FSFilesystem disk workingDirectory / 'Host') withExtension: 'st'. >> >> I should receive: >> >> /path/to/Host.st >> >> but I actually receive: >> >> /path/to/Host >> >> that can be fixed replacing >> >> FSPath>>#withExtension: extension >> Â Â Â | basename name | >> Â Â Â basename := self basename. >> Â Â Â ^ (basename endsWith: extension) >> Â Â Â Â Â Â Â ifTrue: [ self ] >> Â Â Â Â Â Â Â ifFalse: >> Â Â Â Â Â Â Â Â Â Â Â [name := basename copyUpToLast: self extensionDelimiter. >> Â Â Â Â Â Â Â Â Â Â Â self withName: name extension: extension] >> >> with: >> >> FSPath>>#withExtension: extension >> Â Â Â | basename name | >> Â Â Â basename := self basename. >> Â Â Â ^ (basename endsWith: '.', extension) >> Â Â Â Â Â Â Â ifTrue: [ self ] >> Â Â Â Â Â Â Â ifFalse: >> Â Â Â Â Â Â Â Â Â Â Â [name := basename copyUpToLast: self extensionDelimiter. >> Â Â Â Â Â Â Â Â Â Â Â self withName: name extension: extension] >> >> but I don't know if that would be a good solution :) >> >> best, >> Esteban > >

Feb. 15, 2012

Re: [Pharo-project] moved repos to gemstone

by Lukas Renggli

>>> A quick comparison shows that the Pharo fork is based on outdated code and has some methods of the public API renamed. >> >> where's the other code located? I would like to check that. http://source.wiresong.ca/mc > Me too especially because I committed in FS on squeak source and not in Pharo so that colin can commit. Because originally I worked on PharoTaskForces. This is not how open-source works [1, 2]. Not even Pharo works like this. > In addition I do not see how we can control our life if we cannot publish on the repository of a part that should be central to us. I understand that you want to change things. Also I understand that the original project might be too slow, or that the authors might not accept your changes. In this case it is only fair to do a proper fork [3], to choose a new name, and a new namespace. And to live with all the consequences. Lukas [1] http://producingoss.com/en/getting-started.html#developer-guidelines [2] http://subversion.apache.org/docs/community-guide/general.html [3] http://producingoss.com/en/forks.html#forks-initiating -- Lukas Renggli www.lukas-renggli.ch

Feb. 15, 2012

Re: [Pharo-project] garbage collection

by Chris Muller

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 >

Feb. 15, 2012

[Pharo-project] slowly preparing 1.4: list of actions ...

by StÃ©phane Ducasse

Hi guys I went over the script loader descriptions and built the following list of items we did (I went up to 14240). http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotFour If you could go over the list and write a small 2-3 lines, it would be really helpful. Stef

Feb. 15, 2012

Re: [Pharo-project] annoying press "ok" when running tests (not headless)

by Igor Stasenko

On 15 February 2012 17:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Feb 15, 2012, at 1:58 PM, Tudor Girba wrote: > >> Hi, >> >> It's not UIManager, but UITheme. I made it dependent on the UITheme in >> the sense that I moved all the rendering code as an extension. I >> thought this is the official way to get things working with Polymorph. >> Did I get it wrong? > > I do not know. I'm still confused by the responsibility of UITheme vs UIManager vsâ¦ > Now you do not want that every tools add method to UITheme because imagine that we do that > then how each theme can be modular? > Imo, it is simple: the right to use ui theme should have only those object, which actually responsible for ui: widgets and perhaps ui builders. The rest of world should assume UITheme not exists. > so far I do not have the right answer. > Now GrowlMorph should have setting and get initialized from the UITheme settings > > > >> >> Cheers, >> Doru >> >> >> On Wed, Feb 15, 2012 at 1:54 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> On Feb 15, 2012, at 1:47 PM, Tudor Girba wrote: >>> >>>> Indeed, this is a project that is since too long on my to do list. >>>> >>>> I worked on Growl a bit as well, but we need to bring it further. I >>>> just pushed the to do towards the top of the list :) I would be happy >>>> to collaborate on this issue. >>> >>> Would be good. >>> Doru could you fix the fact that if I remember correctly you make it dependent on the UIManager? >>> or something like that? >>> But we could really add it to the image so that we have vanishing messages :) >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Wed, Feb 15, 2012 at 1:38 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> There is a Growl in Pharo. I improved it :) >>>>> >>>>> Stef >>>>> >>>>> On Feb 15, 2012, at 12:42 PM, Camillo Bruni wrote: >>>>> >>>>>> gargl.... >>>>>> >>>>>> we should have some non-interactive inform: like Growl on Mac. >>>>>> The popups should just open but not block the interaction IMO. >>>>>> >>>>>> >>>>>> On 2012-02-14, at 23:50, Igor Stasenko wrote: >>>>>> >>>>>>> i started tests and leaved image for a while, but when i went back >>>>>>> hoping that it already finished, i discovered that it waiting for me >>>>>>> to press ok >>>>>>> and did not ran even 20% of all tests. >>>>>>> >>>>>>> Somewhere in GoferOperationTest>>testMerge >>>>>>> it says 'No changes' and waits for the user to press Â 'ok' >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- Best regards, Igor Stasenko.

Feb. 15, 2012

Re: [Pharo-project] garbage collection

by Igor Stasenko

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.

Feb. 15, 2012

Re: [Pharo-project] moved repos to gemstone

by Sven Van Caekenberghe

On 15 Feb 2012, at 17:16, Camillo Bruni wrote: > bah, basically this shows that squeaksources sucks at comunity based multi version code :D No it does not ;-) Monticello does not care where versions are stored, you could ship .mcz files around on an USB stick. The point is, distributed version control is possible, but requires cooperation: if I as maintainer of Zn do not accept your patches no cooperation will happen, it is as simple as that. It requires effort on both sides. This is not a technical problem (although improvements are most welcome), it is a social one. Sven

Feb. 15, 2012