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

Re: [Pharo-project] Traits in PHP

by Frank Shearar

Smalltalk _uses_ classes, but there's no "class" in "everything's an object, and objects communicate by sending messages". That aside, while Ruby _supports_ something like "object level trait" in the form of eigenclasses, mixins seem much more like how Gilad describes them, and "parameterised subclasses" - classes that take a superclass as parameter. That means that Array withTrait: IdentityHashed. Object withTrait: IdentityHashed creates _classes_, something like this: Array Object ^ ^ | | (IdentityHashed) (IdentityHashed) frank On 17 February 2012 05:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> >> On Thu, Feb 16, 2012 at 7:35 PM, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: >> oh, ok. Yeah, I like the idea, but I agree with stef that you need tool support... an environment like Self for example >> >> I agree, it would need some tool support, I didn't have time to work on it yet. >> >> Which kind of tool support do you think we would need? >> (I love many of the ideas in Self, but the environment is not one of them.) >> >> One thing I would like to put some work on is refactorings for traits (including some not necessarily related with the previous idea). > Indeed. > > I do not see why we would like to have object level trait. May be in ruby but not in class-based language or this is not a class based language > anymore. > >

Feb. 17, 2012

Re: [Pharo-project] troubles with glamour finder in pharo 1.4

by StÃ©phane Ducasse

thanks doru. What about an initialize and a default value? Because I find that strange. Stef On Feb 17, 2012, at 9:39 AM, Tudor Girba wrote: > Hi, > > For your information, the bug is now fixed. > > The issue was that Scrollbar changed the way it sets the scroll value in the model. Before, we had some magic way of inferring the selector, now the selector must be explicitly set: > ScrollBar new > model: self; > setValueSelector: #scrollBarValue:; > yourself. > > This is a good thing, but perhaps others will have similar problems so I thought of documenting it. > > Cheers, > Doru > > > On 15 Feb 2012, at 07:02, Tudor Girba wrote: > >> Thanks, Ben. >> >> You can: >> - load it in Pharo 1.4: >> Gofer new >> squeaksource: 'Glamour'; >> package: 'ConfigurationOfGlamour'; >> load. >> (ConfigurationOfGlamour project version: 'default') load: #('Core' 'Morphic') >> >> - or download the ready-made Moose image: >> http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/arti… >> >> >> To reproduce the problem, try this: >> GLMFinder new >> show: [:a | a list display: [:x | 1 to: x ]]; >> openOn: 100 >> >> and then click on the first and on the second to try to get the third pane. The third pane does not appear, but the scrollbar does. >> >> >> The relevant code is in GLMPaneScroller. >> >> Cheers, >> Doru >> >> >> >> On 14 Feb 2012, at 22:07, Benjamin wrote: >> >>> If you tell me how to load the code easily, and where to have a look, I can do that ;) >>> >>> >>> Ben >>> >>> On Feb 14, 2012, at 9:58 PM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> We are almost done with getting Glamour work on 1.4. The model works, and most of the rendering is fine as well. The only major trouble is with the rendering of the finder. In particular, the problem is the scrolling through the panes. >>>> >>>> The scrolling code was basically copied from OB (shamelessly :)). Something must have changed in Pharo 1.4 that disables some of the behavior. Could anyone spare a pair of eyes to look into this :). >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Next time you see your life passing by, say 'hi' and get to know her." >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > >

Feb. 17, 2012

Re: [Pharo-project] troubles with glamour finder in pharo 1.4

by Tudor Girba

Hi, For your information, the bug is now fixed. The issue was that Scrollbar changed the way it sets the scroll value in the model. Before, we had some magic way of inferring the selector, now the selector must be explicitly set: ScrollBar new model: self; setValueSelector: #scrollBarValue:; yourself. This is a good thing, but perhaps others will have similar problems so I thought of documenting it. Cheers, Doru On 15 Feb 2012, at 07:02, Tudor Girba wrote: > Thanks, Ben. > > You can: > - load it in Pharo 1.4: > Gofer new > squeaksource: 'Glamour'; > package: 'ConfigurationOfGlamour'; > load. > (ConfigurationOfGlamour project version: 'default') load: #('Core' 'Morphic') > > - or download the ready-made Moose image: > http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/arti… > > > To reproduce the problem, try this: > GLMFinder new > show: [:a | a list display: [:x | 1 to: x ]]; > openOn: 100 > > and then click on the first and on the second to try to get the third pane. The third pane does not appear, but the scrollbar does. > > > The relevant code is in GLMPaneScroller. > > Cheers, > Doru > > > > On 14 Feb 2012, at 22:07, Benjamin wrote: > >> If you tell me how to load the code easily, and where to have a look, I can do that ;) >> >> >> Ben >> >> On Feb 14, 2012, at 9:58 PM, Tudor Girba wrote: >> >>> Hi, >>> >>> We are almost done with getting Glamour work on 1.4. The model works, and most of the rendering is fine as well. The only major trouble is with the rendering of the finder. In particular, the problem is the scrolling through the panes. >>> >>> The scrolling code was basically copied from OB (shamelessly :)). Something must have changed in Pharo 1.4 that disables some of the behavior. Could anyone spare a pair of eyes to look into this :). >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Next time you see your life passing by, say 'hi' and get to know her." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Feb. 17, 2012

Re: [Pharo-project] garbage collection

by Sven Van Caekenberghe

On 17 Feb 2012, at 09:16, Milan Mimica wrote: > Might be also because of RFB server, but that is less likely. I have the impression that most people who run in trouble with server images are using RFB. On the other hand, those not using RFB with probably restart server images sooner. Anyway, Henrik's list is excellent, thanks ! Sven

Feb. 17, 2012

Re: [Pharo-project] garbage collection

by Milan Mimica

On 17 February 2012 08:15, Henrik Johansen <henrik.s.johansen(a)veloxit.no>wrote: > > As per later mails though, network reinitialization is already one case in > the base image where such leaks can occur , so it's not certain Magma is > involved at all... > Might be also because of RFB server, but that is less likely. -- Milan Mimica http://sparklet.sf.net

Feb. 17, 2012

Re: [Pharo-project] [update 1.3] #13321

by Marcus Denker

On Feb 16, 2012, at 11:05 PM, Helene Bilbo wrote: > where can you find this version? > on the website the newest version is 13315 and on Jenkins 13320. > jenkins should have updated automatically... I will check why not. -- Marcus Denker -- http://marcusdenker.de

Feb. 17, 2012

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

by Henrik Johansen

On Feb 16, 2012, at 9:56 PM, StÃ©phane Ducasse wrote: > Henrik > > I'm sure that if we would be in face of a browser together I would get 100% what you are saying now I hate mail > but I'm not 100% clear about what you say. :) > Could you make a list of the steps that we could follow? > I will sit and discuss with camillo next week. I would like to have a todo so that I can do item after itemâ¦ > Because I want to get rid of the old code. > > Stef Replace FSFileStream & subclasses' references with something like an FSStreamProvider, where FSStreamProvider: - delegates an API for returning different classes to use for #readStream, #writeStream etc. to a #currentProvider method. For thread-safe switching on case-by-case basis: - implement FSStreamProvider#currentProvider as thread-local lookup with FSStreamProvider CurrentProvider class var as backup. - implement FSStreamProvider #useDuring: aBlock installing self in the thread-local var during execution of aBlock. For use in Pharo: - Implement a FSLegacyStreamProvider, set as CurrentProvider in Pharo. (Should return MultiByteFileStream for most instances) For modularizing the current FSFileStreams: - Revert compatibility fixes extending the API, move them to an independent package,and implement an FSAnsiStreamProvider or some such in that package. Cheers, Henry

Feb. 17, 2012

Re: [Pharo-project] garbage collection

by Henrik Johansen

On Feb 17, 2012, at 3:01 AM, Chris Muller wrote: > Ok. I thought you were trying to figure out whether the majority of > the Semaphores you were seeing were due to Magma or not. I have a > suspicion that they may be. Which might be a concern since I didn't > realize there was a Semaphore limit.. There isn't a limit to Semaphores per se, but there's (in Cog) a limit to the amount of Semaphores which can be registered in the ExternalSemaphoreTable (a.k.a. being available to signal by primitives). In the base image the five cases I mentioned earlier are the only users, any wrongdoings on Magma's part would either be through something doing custom registering in that table, or "misuse" of base users, like reusing Sockets by sending certain messages, as mentioned in my first mail. As per later mails though, network reinitialization is already one case in the base image where such leaks can occur , so it's not certain Magma is involved at all... Cheers, Henry

Feb. 17, 2012

Re: [Pharo-project] Opening...

by S Krish

Out of 70 odd customers it is live in 2. There is a need to support all major Banks for the next I believe 3 - 4 years for changes on the VA version ( and what if strategy changes in the next couple of yrs to retain Smalltalk..! ). On Fri, Feb 17, 2012 at 9:52 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 16/02/12 4:13 PM, S Krish wrote: > >> This is a VA App of about 3 million lines of code.. >> >> Ported to Java and now live. The VA work is now to maintain and sustain >> it till Java can get its handle over all the major implementations over >> the years ahead. >> > > Do you mean the Java port is now live? Then why does the VA App need to be > maintained? > > >

Feb. 17, 2012

Re: [Pharo-project] Traits in PHP

by StÃ©phane Ducasse

> > > On Thu, Feb 16, 2012 at 7:35 PM, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: > oh, ok. Yeah, I like the idea, but I agree with stef that you need tool support... an environment like Self for example > > I agree, it would need some tool support, I didn't have time to work on it yet. > > Which kind of tool support do you think we would need? > (I love many of the ideas in Self, but the environment is not one of them.) > > One thing I would like to put some work on is refactorings for traits (including some not necessarily related with the previous idea). Indeed. I do not see why we would like to have object level trait. May be in ruby but not in class-based language or this is not a class based language anymore.

Feb. 17, 2012