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

Re: [Pharo-project] Traits in PHP

by Stefan Marr

Hi Hernan: On 15 Feb 2012, at 23:30, Hernan Wilkinson wrote: > what is the difference with the current trait implementation in pharo? I could not see the difference... There are only cosmetic differences. (If I remember correctly what Pharo's traits entail.) Most importantly, you cannot exclude arbitrary methods from a trait. Thus, there is no exclude operator. Instead, conflicts are resolved by explicitly stating which method wins a conflict with the insteadof keyword. And, because PHP has a much more dynamic notion of object fields/slots, I added a couple of rules to make that manageable. https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate The main idea is, break on obviously incompatible things, and leave the rest to the normal dynamic semantics. (which means, we do not have a solution for state). Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Feb. 15, 2012

Re: [Pharo-project] End of startup script behavior changed ?

by Sven Van Caekenberghe

;-) It is not so much that I need help, I am not stuck. I just want to understand how this change came about, because I think it is an important difference for scripting and server usage. Also, I don't like the silly busy code: it hurts aesthetically. On 15 Feb 2012, at 22:19, StÃ©phane Ducasse wrote: > Please help sven :) > > Begin forwarded message: > >> Status: Accepted >> Owner: ---- >> Labels: Milestone-1.4 Type-Bug >> >> New issue 5300 by sven.van...(a)gmail.com: End of startup script behavior changed ? >> http://code.google.com/p/pharo/issues/detail?id=5300 >> >> Guys, >> >> Maybe I missed this, but did something change with the behavior at the end of a startup script between 1.3 and 1.4 ? >> >> It used to be that the image kept on running unless you asked it to quit explicitly, now it seems that the image automatically quits unless you keep it busy. Can someone confirm this ? Was this intentional ? >> >> What would be the recommended way to keep the image open ? >> >> Somehow something like >> >> [ (Delay forDuration: 1 hour) wait ] repeat. >> >> seems so silly, but it works. >> >> Thx, >> >> Sven > >

Feb. 15, 2012

Re: [Pharo-project] Traits in PHP

by Hernan Wilkinson

what is the difference with the current trait implementation in pharo? I could not see the difference... 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 <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Feb. 15, 2012

[Pharo-project] End of startup script behavior changed ?

by StÃ©phane Ducasse

Please help sven :) Begin forwarded message: > Status: Accepted > Owner: ---- > Labels: Milestone-1.4 Type-Bug > > New issue 5300 by sven.van...(a)gmail.com: End of startup script behavior changed ? > http://code.google.com/p/pharo/issues/detail?id=5300 > > Guys, > > Maybe I missed this, but did something change with the behavior at the end of a startup script between 1.3 and 1.4 ? > > It used to be that the image kept on running unless you asked it to quit explicitly, now it seems that the image automatically quits unless you keep it busy. Can someone confirm this ? Was this intentional ? > > What would be the recommended way to keep the image open ? > > Somehow something like > > [ (Delay forDuration: 1 hour) wait ] repeat. > > seems so silly, but it works. > > Thx, > > Sven

Feb. 15, 2012

Re: [Pharo-project] FSPath withExtension: bug

by StÃ©phane Ducasse

The intro is there http://codingjunkie.net/java7-file-revolution/ Stef On Feb 15, 2012, at 10:13 PM, StÃ©phane Ducasse wrote: > thanks I will read that carefully > > Stef > > On Feb 15, 2012, at 9:59 PM, Sven Van Caekenberghe wrote: > >> >> On 15 Feb 2012, at 21:51, StÃ©phane Ducasse wrote: >> >>> May be FS is over engineered (even if I would like to hear what camillo think because he work on GitFS shows that FS is powerful) >>> I was reading >>> http://www.gnu.org/software/smalltalk/manual-base/gst-base.html#FilePath >>> and >>> http://www.gnu.org/software/smalltalk/manual-base/gst-base.html#FileDescrip… >>> >>> and I like what I read. >> >> Apparently they are adding Path objects to Java: >> >> http://codingjunkie.net/java-7-copy-move/ > >

Feb. 15, 2012

Re: [Pharo-project] FSPath withExtension: bug

by StÃ©phane Ducasse

thanks I will read that carefully Stef On Feb 15, 2012, at 9:59 PM, Sven Van Caekenberghe wrote: > > On 15 Feb 2012, at 21:51, StÃ©phane Ducasse wrote: > >> May be FS is over engineered (even if I would like to hear what camillo think because he work on GitFS shows that FS is powerful) >> I was reading >> http://www.gnu.org/software/smalltalk/manual-base/gst-base.html#FilePath >> and >> http://www.gnu.org/software/smalltalk/manual-base/gst-base.html#FileDescrip… >> >> and I like what I read. > > Apparently they are adding Path objects to Java: > > http://codingjunkie.net/java-7-copy-move/

Feb. 15, 2012

Re: [Pharo-project] FSPath withExtension: bug

by Sven Van Caekenberghe

On 15 Feb 2012, at 21:51, StÃ©phane Ducasse wrote: > May be FS is over engineered (even if I would like to hear what camillo think because he work on GitFS shows that FS is powerful) > I was reading > http://www.gnu.org/software/smalltalk/manual-base/gst-base.html#FilePath > and > http://www.gnu.org/software/smalltalk/manual-base/gst-base.html#FileDescrip… > > and I like what I read. Apparently they are adding Path objects to Java: http://codingjunkie.net/java-7-copy-move/

Feb. 15, 2012

Re: [Pharo-project] FSPath withExtension: bug

by StÃ©phane Ducasse

May be FS is over engineered (even if I would like to hear what camillo think because he work on GitFS shows that FS is powerful) I was reading http://www.gnu.org/software/smalltalk/manual-base/gst-base.html#FilePath and http://www.gnu.org/software/smalltalk/manual-base/gst-base.html#FileDescrip… and I like what I read.

Feb. 15, 2012

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

by StÃ©phane Ducasse

> 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? I do not know :) Because if we generalize that to all the widgets UITheme will explode. And you cannot use a widget without a theme. Then you always asks the theme. I do not like that - Do we want UITheme to be a facade? - Is UITheme our new preference class? - I would prefer to get something like setting - GrowlMorph has a class Var for its labelColor - and somehow The UITheme push its value inside may be the GrowlMorph initialize ask the theme or something like that. - may each UI could register to the UItheme and the UItheme propagate its changes by saying to the widgets I changed ask me what you need. and the widget say I need these values. Now I do not see how Uitheme defining the logic of a widget can scale. Now I'm trying to understand the flow and architecture that the system could have. So we should get some more exercises to see. Stef

Feb. 15, 2012

Re: [Pharo-project] moved repos to gemstone

by StÃ©phane Ducasse

> > >>>>> 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. This is what I thought too but I'm naive. > I don't know enough about the history of all this, but I completely fail to understand how someone who wrote something like FileSystem I started to really want to use FS so I started to comment it and publish my change in PharoTaskForces and people told me that I should share so did I and I put a FS project on Squeaksource and colin pubslihed one version there. thought that he would continue to publish there but not. This is ok. Now let us be free. I do not think that it makes sense to continue like that. > or RB would not find it interesting that his code would be included by default in Pharo (and thus support a mutual cooperation). Because we want to change some of the approach to be able to manage remote refactorings and this goes against the Design of RB but with bit of discussions and positive energy if would be probably easy to get somewhere. Now we will see and probably have to fork. When people do not want to collaborate then you work on your own. We arrived to the point that for example for SmallLint we will have to fork everything because we do not dare to propose extensions. And to collaborate you should trust people and there is not even an inbox in SmallLint and other projects. So this measn that changes are not welcomed. This is ok too but this is another approach. Simple. This is just sad to see a microscopic world with nearly no impact on industry struggling instead of pushing in the same direction. Anyway we will do it. Because Pharo deserves better vision than that. > 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. Not necessarily ... Stef > > Anyway, that is my opinion.

Feb. 15, 2012