March 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3789 in pharo: convert MenuMorph reference to invoke UIManager

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3789 by stephane...(a)gmail.com: convert MenuMorph reference to invoke UIManager http://code.google.com/p/pharo/issues/detail?id=3789 subMenu := MenuMorph new defaultTarget: self. should be turned into subMenu := UIManager default newMenuIn: self for: self. newMenuIn: <owner> like a pane for example for: receiver of the menu actions. This is related to issue: 3728

March 6, 2011

Re: [Pharo-project] Issue 3784 in pharo: ImageForDevelopers uses SHWorkspace which is not defined in the image

by pharo＠googlecode.com

Comment #2 on issue 3784 by stephane...(a)gmail.com: ImageForDevelopers uses SHWorkspace which is not defined in the image http://code.google.com/p/pharo/issues/detail?id=3784 Strange because I fixed it. So may be the pharo configuration should be update too. I will have a look

March 6, 2011

[Pharo-project] Does FFI support WideStrings?

by Mariano Martinez Peck

Hi. Someone pointed out here: http://stackoverflow.com/questions/5212790/unicode-characters-in-a-smalltal… a problem while using WideStrings with FFI. FFI throws a "Could not coerce arguments". Is this because of the usage of WideString? what we should use instead (I know that ByteString works) ? can we fix FFI so that it supports WideStrings? thanks Mariano

March 6, 2011

Re: [Pharo-project] Issue 3778 in pharo: cleaning cursor: and cursor

by pharo＠googlecode.com

Comment #1 on issue 3778 by stephane...(a)gmail.com: cleaning cursor: and cursor http://code.google.com/p/pharo/issues/detail?id=3778 Please review this fix! I do not like to integrate my own changes

March 6, 2011

[Pharo-project] I'm doing an integration of some fixes now.

by StÃ©phane Ducasse

March 6, 2011

[Pharo-project] Just a thought :)

by StÃ©phane Ducasse

Hi guys in the train friday I read event code during a couple of hours... and I came to the conclusion I want to rewrite part of them :). Now the real interested part of this email is the following: 2 years ago event handling was looking mysterious to me, why? because I never needed to understand that part. Now I started to read, build hypothesis, read again, break the system and I get an understanding to the point I can say ok I want them better. So the lesson in there: this is cool, at the beginning you are not an expert, you just learn a little bit here and here and you consolidate, and you understand more and more. Sound stupid and naive story but this is a cool one. I like to read the code of the system just because I learn a lot. So I hope that this is a good and positive message for you. Step back and realize that you have learned a lot and that you can learn a lot more. And in the process fix the system to make it better and easier to be understood. Magic no? Stef

March 6, 2011

Re: [Pharo-project] Pharo 1.2 and test failures

by StÃ©phane Ducasse

> 1) Always use ALL last version of everything > 2) Use last metacello version. Someone needs to update each configuration. > > If you want 2), then the PEOPLE needs to update configuration. There is no magic. Don't expect to always use the last code. If you want to use 1), perfect. But don't expect that the image is always working perfect: most repositories are public, so people can commit crap, and even more, some repositories are shared with squeak so someone can commit something that doesn't work with Pharo. > > We have to choose. > > To implement 2) then the Hudson script should be updated so that it loads the bleedingEdge: symbolic version of ConfigurationOfPharo. really? I'm confused then. :) For me this is ok as it is. We should have a look at the configuration and probably review them not to load the latest version but for the rest this is ok. And yes it requires some work because the configuration of a complex system over multiple versions is not simple. Now symbolic versions are present and can help us. Now if people are serious about pharo then they should read the metacello chapter for real because this is the way to work while the tools and process emerge. I cannot read it for people. Writing it is enough for me. Stef

March 6, 2011

Re: [Pharo-project] Pharo 1.2 and test failures

by Mariano Martinez Peck

I think there is no magic here. If you want daily build images, then you have 2 options: 1) Always use ALL last version of everything 2) Use last metacello version. Someone needs to update each configuration. If you want 2), then the PEOPLE needs to update configuration. There is no magic. Don't expect to always use the last code. If you want to use 1), perfect. But don't expect that the image is always working perfect: most repositories are public, so people can commit crap, and even more, some repositories are shared with squeak so someone can commit something that doesn't work with Pharo. We have to choose. To implement 2) then the Hudson script should be updated so that it loads the bleedingEdge: symbolic version of ConfigurationOfPharo. cheers mariano On Sun, Mar 6, 2011 at 8:48 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > On Mar 6, 2011, at 11:29 AM, StÃ©phane Ducasse wrote: > > well, I provided a fix already. And it seems that 3 mails to the list and > the mentioning withing this mail does not make it visible. It needs an > integration step or just to load the newest ImageForDevelopers > > How to tell? > > I think the ConfigurationOfPharo needs to be updated... > > Probably. Do you know what was the problem? Because I can have a look but I > need to know what went wrong. > > I am all in all not happy with the process we have... we should fix it. > > I would not be that negative. I think that we are building an > infrastructure and learning how to use it. > Generating one single image is easy. Generating an infrastructure to be > able to manage multiple images over different > setup in another story. I think that metacello is getting there and also > knowledge. This is why I spent time writing and fixing the > metacello chapter. Now there is more than 30 pages and with the latest > important features like symbolic configuration. > > I spent 2 hours to integrate one single changes for shout last week-end, so > I know the pain now I think that the situation will > get better. Then else I would like to know your solution and roadmap? > For me this is clear: metacello and distributions are the way. I like that > alex and dale are pushing tools on top of Metacello > because we have first class spec and dependencies and we can use them to > get to a much better stage and we will get there. > > Stef > > I agree with Stef ... the solution is going to involve both tools and > process and at the moment Metacello tools are almost non-existent (Alex and > I are trying to change that ... excellent effort Alex!) and we are still > learning the process ... > > The integration process for Pharo dev should parallel the process for > creating PharoCore ... I'm not familiar with the PharoCore integration > process , but after a bug is submitted for fixing, someone changes a script > or a config to get the change included in the next PharoCore build ... the > same thing needs to happen for Pharo Dev ... the Pharo dev configuration has > to be edited to include the proposed fixes ... > > The developer submitting the change _could_ update the configuration or the > "owner" of the configuration could update the config or .... > > I can imagine more possibilities ... right now it probably makes sense for > an owner to make the changes ... that way if there are configuration issues > the owner is responsible for fixing the issues the owner could also filter > the changes, much the same way that the bugfixes for PharoCore are filtered > ... once the manual process settles down we can look at improving the > process and tool support incrementally... > > Dale > > >

March 6, 2011

Re: [Pharo-project] Pharo 1.2 and test failures

by Dale Henrichs

On Mar 6, 2011, at 11:29 AM, StÃ©phane Ducasse wrote: well, I provided a fix already. And it seems that 3 mails to the list and the mentioning withing this mail does not make it visible. It needs an integration step or just to load the newest ImageForDevelopers How to tell? I think the ConfigurationOfPharo needs to be updated... Probably. Do you know what was the problem? Because I can have a look but I need to know what went wrong. I am all in all not happy with the process we have... we should fix it. I would not be that negative. I think that we are building an infrastructure and learning how to use it. Generating one single image is easy. Generating an infrastructure to be able to manage multiple images over different setup in another story. I think that metacello is getting there and also knowledge. This is why I spent time writing and fixing the metacello chapter. Now there is more than 30 pages and with the latest important features like symbolic configuration. I spent 2 hours to integrate one single changes for shout last week-end, so I know the pain now I think that the situation will get better. Then else I would like to know your solution and roadmap? For me this is clear: metacello and distributions are the way. I like that alex and dale are pushing tools on top of Metacello because we have first class spec and dependencies and we can use them to get to a much better stage and we will get there. Stef I agree with Stef ... the solution is going to involve both tools and process and at the moment Metacello tools are almost non-existent (Alex and I are trying to change that ... excellent effort Alex!) and we are still learning the process ... The integration process for Pharo dev should parallel the process for creating PharoCore ... I'm not familiar with the PharoCore integration process , but after a bug is submitted for fixing, someone changes a script or a config to get the change included in the next PharoCore build ... the same thing needs to happen for Pharo Dev ... the Pharo dev configuration has to be edited to include the proposed fixes ... The developer submitting the change _could_ update the configuration or the "owner" of the configuration could update the config or .... I can imagine more possibilities ... right now it probably makes sense for an owner to make the changes ... that way if there are configuration issues the owner is responsible for fixing the issues the owner could also filter the changes, much the same way that the bugfixes for PharoCore are filtered ... once the manual process settles down we can look at improving the process and tool support incrementally... Dale

March 6, 2011

Re: [Pharo-project] Pharo 1.2 and test failures

by StÃ©phane Ducasse

> well, I provided a fix already. And it seems that 3 mails to the list and the mentioning withing this mail does not make it visible. It needs an integration step or just to load the newest ImageForDevelopers >> >> How to tell? >> > I think the ConfigurationOfPharo needs to be updated... Probably. Do you know what was the problem? Because I can have a look but I need to know what went wrong. > > I am all in all not happy with the process we have... we should fix it. I would not be that negative. I think that we are building an infrastructure and learning how to use it. Generating one single image is easy. Generating an infrastructure to be able to manage multiple images over different setup in another story. I think that metacello is getting there and also knowledge. This is why I spent time writing and fixing the metacello chapter. Now there is more than 30 pages and with the latest important features like symbolic configuration. I spent 2 hours to integrate one single changes for shout last week-end, so I know the pain now I think that the situation will get better. Then else I would like to know your solution and roadmap? For me this is clear: metacello and distributions are the way. I like that alex and dale are pushing tools on top of Metacello because we have first class spec and dependencies and we can use them to get to a much better stage and we will get there. Stef

March 6, 2011