May 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 2435 - DNU in cleanUpForRelease

by Torsten Bergmann

see http://code.google.com/p/pharo/issues/detail?id=2435 -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 16, 2010

Re: [Pharo-project] ConfigurationOfExternalWebBrowser working in Squeak and Pharo trunk

by Sean P. DeNigris

Torsten Bergmann wrote: > > Why do you rerelease the ConfigurationOfExternalWebBrowser that > was already working in Squeak and Pharo in an own repository > and reanounce it? > Hey T, I created my own ConfigurationOf because, on the Mac, when EWB is loaded, it tries to load the Applescript project via a Squeak Map Loader class (not sure of exact name) that doesn't exist in Pharo. So I actually refactored EWB itself into Core and Platform and made a Config for that project, which I had to host personally because I don't have write access to EWB on SqS. Torsten Bergmann wrote: > > I think this adds more confusion ... > Absolutely, emailed EWB admin with code, waiting for a response... HTH, Sean -- View this message in context: http://forum.world.st/ConfigurationOfExternalWebBrowser-working-in-Squeak-a… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2010

[Pharo-project] Vertical scroll disappear with OB in Pharo 1.1

by Mariano Martinez Peck

Hi Lukas. In the latest code of OB in Pharo 1.1 if the size of the System Browser is too small, the vertical scroll disappear. I tried in PharoCore and there it doesn't happen. Look the two attached screenshots. Cheers mariano

May 16, 2010

Re: [Pharo-project] Decoding bug with XMLParser ?

by Damien Pollet

On Sun, May 16, 2010 at 22:57, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > I will check your code today. Thanks. Thinking of it, it's not really an encoding problem, rather a bug in the entity->character conversion. I guess there should be a similar test where there is an actual ellipsis character in the xml, instead of the entity. For the context, I was trying to use the twitter component in pier, to display http://twitter.com/rmod_inria (or the XML feed file, which has the ellipsis character literally as well). And now I realize our server will not be able to connect outside its DMZ, so I won't be able to use the fix :D > On 16 May 2010, at 13:35, Damien Pollet wrote: > >> Hi, >> >> I have a failing test to show the problem, but I can't commit to the >> XMLSupport squeaksource, so I attach the MCZ here. >> Basically, if I parse an UTF-8 document with an entity like … >> (ellipsis), I don't get a Character with the correct #codePoint. >> >> Cheers, >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> <XML-Parser-DamienPollet.75.mcz> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 16, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Alexandre Bergel

> - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge I will go over some this week. Alexandre

May 16, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Mariano Martinez Peck

On Sun, May 16, 2010 at 11:16 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > check the network problem. > But we can release rc1 anytime now. > > No, please. We are not in a RC yet. We should first go as alpha, then beta and finally RC. We cannot go in a RC with the first build ever. Cheers Mariano > Stef > > On May 16, 2010, at 11:00 PM, Alexandre Bergel wrote: > > > Mariano, > > > > What is needed for Pharo 1.1? Not much I feel. I produced yesterday a > Pharo1.1 from a core, and it works perfectly, including condenseChange. > > > > Cheers, > > Alexandre > > > > > > On 16 May 2010, at 11:14, StÃ©phane Ducasse wrote: > > > >> We are basically ready > >> Waiting for feedback on network. > >> > >> Stef > >> > >> > >> On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: > >> > >>> We said that for middle May we were going to freeze 1.1. This means, no > more new features or refactors. Just bug fixes. So, the next steps can be: > >>> > >>> - Release a PharoCore1.1 with the last version we have so far tagged as > alpha1 (please, put this tag in the zip, .image and .changes). This may be, > for example: Pharo-1.1-11360-alpha1.image > >>> - Build and release a Pharo 1.1 alpha1 based on such core (now we have > almost all dev tools working well in 1.1) > >>> - Make publish all new VMs (for each OS) > >>> > >>> Then the idea is that people/developers start to play with Pharo 1.1. > It may be quite unstable as this is the first release for 1.1. People should > try to load their own packages, adapt them (if necessary) to 1.1, and report > all issues they find (and fixes!!). But they should keep in mind this the > first alpha ;) > >>> > >>> With these, we will be testing: new VMs, PharoCore, PharoDev tools, and > external packages (from other people). > >>> > >>> Pharo team at the same time, continues to work, fixing and integrating. > We make new versions as we have been doing so far. When we consider, we > release an alpha2....then beta, then RC and finally Pharo 1.1. > >>> > >>> now...do you think there is an issue that is so important to be > fixed/included in the first Pharo1.1 even being a first alpha ? > >>> > >>> Cheers > >>> > >>> Mariano > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 16, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Mariano Martinez Peck

On Sun, May 16, 2010 at 11:00 PM, Alexandre Bergel < alexandre.bergel(a)inria.fr> wrote: > Mariano, > > What is needed for Pharo 1.1? Not much I feel. I produced yesterday a > Pharo1.1 from a core, and it works perfectly, including condenseChange. > No, it doesn't work perfectly ;) All the mails I sent to the mailing list was the "things" I found while building Pharo 1.1. We still have problems with network for example. Not too much indeed. I need to update a little some configurations. I just tested with the new vms and today I was testing how to install external packages like seaside to see if the welcome workspace that explains how to install them deserves an update. What I need is that someone: - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge - to create a section in the website specially for 1.1 where we mention we are in alpha1 blah blah - in that section we include new VMs. - For windows it is the same we have for 1.0: http://gforge.inria.fr/frs/download.php/26814/PharoVM-Win32-4.0.2-bin.zip - For linux: http://squeakvm.org/unix/release/Squeak-4.0.3.2202-linux_i386.tar.gz - For mac we are waiting a new one from John, but for the moment we should use: ftp://ftp.smalltalkconsulting.com/Squeak%204.2.4beta1U.app.zip - Finally we add in that section the Pharo image I build. I have updated my build scripts to work with Pharo 1.1 and I build a dev, So...once those points are done, I just create the image and update it to website. But we will need help from people to test it and report bugs, feedback and all kind of issues. There are still failing and error tests (they are even in PharoCore). Cheers Mariano > Cheers, > Alexandre > > > On 16 May 2010, at 11:14, StÃ©phane Ducasse wrote: > > > We are basically ready > > Waiting for feedback on network. > > > > Stef > > > > > > On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: > > > >> We said that for middle May we were going to freeze 1.1. This means, no > more new features or refactors. Just bug fixes. So, the next steps can be: > >> > >> - Release a PharoCore1.1 with the last version we have so far tagged as > alpha1 (please, put this tag in the zip, .image and .changes). This may be, > for example: Pharo-1.1-11360-alpha1.image > >> - Build and release a Pharo 1.1 alpha1 based on such core (now we have > almost all dev tools working well in 1.1) > >> - Make publish all new VMs (for each OS) > >> > >> Then the idea is that people/developers start to play with Pharo 1.1. It > may be quite unstable as this is the first release for 1.1. People should > try to load their own packages, adapt them (if necessary) to 1.1, and report > all issues they find (and fixes!!). But they should keep in mind this the > first alpha ;) > >> > >> With these, we will be testing: new VMs, PharoCore, PharoDev tools, and > external packages (from other people). > >> > >> Pharo team at the same time, continues to work, fixing and integrating. > We make new versions as we have been doing so far. When we consider, we > release an alpha2....then beta, then RC and finally Pharo 1.1. > >> > >> now...do you think there is an issue that is so important to be > fixed/included in the first Pharo1.1 even being a first alpha ? > >> > >> Cheers > >> > >> Mariano > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 16, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by StÃ©phane Ducasse

check the network problem. But we can release rc1 anytime now. Stef On May 16, 2010, at 11:00 PM, Alexandre Bergel wrote: > Mariano, > > What is needed for Pharo 1.1? Not much I feel. I produced yesterday a Pharo1.1 from a core, and it works perfectly, including condenseChange. > > Cheers, > Alexandre > > > On 16 May 2010, at 11:14, StÃ©phane Ducasse wrote: > >> We are basically ready >> Waiting for feedback on network. >> >> Stef >> >> >> On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: >> >>> We said that for middle May we were going to freeze 1.1. This means, no more new features or refactors. Just bug fixes. So, the next steps can be: >>> >>> - Release a PharoCore1.1 with the last version we have so far tagged as alpha1 (please, put this tag in the zip, .image and .changes). This may be, for example: Pharo-1.1-11360-alpha1.image >>> - Build and release a Pharo 1.1 alpha1 based on such core (now we have almost all dev tools working well in 1.1) >>> - Make publish all new VMs (for each OS) >>> >>> Then the idea is that people/developers start to play with Pharo 1.1. It may be quite unstable as this is the first release for 1.1. People should try to load their own packages, adapt them (if necessary) to 1.1, and report all issues they find (and fixes!!). But they should keep in mind this the first alpha ;) >>> >>> With these, we will be testing: new VMs, PharoCore, PharoDev tools, and external packages (from other people). >>> >>> Pharo team at the same time, continues to work, fixing and integrating. We make new versions as we have been doing so far. When we consider, we release an alpha2....then beta, then RC and finally Pharo 1.1. >>> >>> now...do you think there is an issue that is so important to be fixed/included in the first Pharo1.1 even being a first alpha ? >>> >>> Cheers >>> >>> Mariano >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 16, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by StÃ©phane Ducasse

+ 1 especially on this one. > I still would like to hear the opinion of the developers that have most of the configurations. We are doing this together. If you don't agree, it will not succeed. > Yes, it is similar to Andreas post. We were thinking about this since a lot of time but without making progress. Now, with the post of Andreas, we remembered about it. And I am happy both proposal are similar. Little differences: > > - They want one only package for all confs. We want one package per configuration. Like we did in MetacelloRepository. I think it is easier to manage, less conflicts (imagine if everybody is commiting in the same package) and easier to browse. > > - They didn't say how to solve the problems with multiple version. What will they do when they have squeak 5 ? use the same package ? another one ? other repo ? > > - How do they know which version of the configuration works on the current version of squeak? So...I browse ConfigurationOfFFI, how do I know that the version 1.1.4 is the one that works in Squeak 4.1 and that the 1.2 is the one that works in Squeak 4.2 ? Of course, you can put such information inside the configuration, maybe in #description: or similar...but in all cases, you have to enter and browse the conf. We don't want that. > > - We wanted to define a standard way to load the packages on such repository: just send the message load. > > I still would like to hear the opinion of the developers that have most of the configurations. We are doing this together. If you don't agree, it will not succeed. > > What we want in summary is: is a repository of projects tested that works for a particular release of Pharo and that they all get installed in the same way. And that such installation can be executed any time in future. > > Cheers > > Mariano > > > 2010/5/16 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi Stef, > > You obviously didn't read Andreas post. Please do it, it is really good > idea, which includes Metacello, it is simple and very similar to > Mariano's proposal. This means that a common solution for both Squeak > and Pharo is around a corner and that's what we all want! > > Best regards > Janko > > On 16. 05. 2010 18:26, StÃ©phane Ducasse wrote: > >> > >> I think Andreas' recent post to squeak-dev is most cogent o this topic: > > > > Eliot believe me we talk a lot of metacello since at least ESUG last year :) > > We support and appreciate dale's effort (even when people bashed metacello a while ago). > > So I think that we have a solution that looks ok for us. > > We started to see how we can manage pharoCore to produce pharoMini using metacello > > and what hamper us to remove more aggressively package is the speed of load monticello packages. > > > > Stef > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 16, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by StÃ©phane Ducasse

we will release 1.1 rc this week... No need to get an email about andreas to know that you do not want to mix 1.0 and 1.1 configurations. Stef On May 16, 2010, at 9:17 PM, Mariano Martinez Peck wrote: > Yes, it is similar to Andreas post. We were thinking about this since a lot of time but without making progress. Now, with the post of Andreas, we remembered about it. And I am happy both proposal are similar. Little differences: > > - They want one only package for all confs. We want one package per configuration. Like we did in MetacelloRepository. I think it is easier to manage, less conflicts (imagine if everybody is commiting in the same package) and easier to browse. > > - They didn't say how to solve the problems with multiple version. What will they do when they have squeak 5 ? use the same package ? another one ? other repo ? > > - How do they know which version of the configuration works on the current version of squeak? So...I browse ConfigurationOfFFI, how do I know that the version 1.1.4 is the one that works in Squeak 4.1 and that the 1.2 is the one that works in Squeak 4.2 ? Of course, you can put such information inside the configuration, maybe in #description: or similar...but in all cases, you have to enter and browse the conf. We don't want that. > > - We wanted to define a standard way to load the packages on such repository: just send the message load. > > I still would like to hear the opinion of the developers that have most of the configurations. We are doing this together. If you don't agree, it will not succeed. > > What we want in summary is: is a repository of projects tested that works for a particular release of Pharo and that they all get installed in the same way. And that such installation can be executed any time in future. > > Cheers > > Mariano > > > 2010/5/16 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi Stef, > > You obviously didn't read Andreas post. Please do it, it is really good > idea, which includes Metacello, it is simple and very similar to > Mariano's proposal. This means that a common solution for both Squeak > and Pharo is around a corner and that's what we all want! > > Best regards > Janko > > On 16. 05. 2010 18:26, StÃ©phane Ducasse wrote: > >> > >> I think Andreas' recent post to squeak-dev is most cogent o this topic: > > > > Eliot believe me we talk a lot of metacello since at least ESUG last year :) > > We support and appreciate dale's effort (even when people bashed metacello a while ago). > > So I think that we have a solution that looks ok for us. > > We started to see how we can manage pharoCore to produce pharoMini using metacello > > and what hamper us to remove more aggressively package is the speed of load monticello packages. > > > > Stef > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 16, 2010