- Pharo-dev - lists.pharo.org

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

by Eliot Miranda

2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/5/16 Eliot Miranda <eliot.miranda(a)gmail.com> > > >> I think Andreas' recent post to squeak-dev<http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html>is most cogent o this topic: >> >> > > why ? > Read it and you'll see. But the most important thing is that there is one place to find all the external packages which are "supported", or part of the base distribution but not bundled. It is in the image so it can be updated to keep it current. I think its better than the external repository (doesn't force a single repository). But read Andreas' message. He motivates the idea very well; cogently no less :) > > >> >>> Thanks >>> >>> 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] [Pharo-users] [ANN] Traits installer/uninstaller utility

by Johan Fabry

On 16 May 2010, at 19:30, Tudor Girba wrote: >> My philosophy here is to not hide anything from the developer, which is why the Trait is part of the definition. What you see is what you get. Delete the Trait when editing the base class and it goes away. What you see is what you get. >> >> So just edit the class as you want to, you can even add new Traits manually. You can always remove the TAMStructuralZoom trait (or any other trait actually) using the traits uninstaller. > > I know that, but I was just pointing out that if I change the base class and commit while your code is loaded, I publish unwillingly your trait. So, when your code is loaded I have to be careful to first remove the trait and only afterwards publish my change. > > This is a severe limitation and it stems from the Trait definition being tightly coupled with the class definition (both in the model and in the browser). OK so we are in agreement :-) -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

May 16, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Traits installer/uninstaller utility

by Tudor Girba

Hi, On 16 May 2010, at 19:43, Johan Fabry wrote: > > On 16 May 2010, at 03:48, Tudor Girba wrote: > >> I took a quick look and it looks interesting. > > Thanks :-) > >> Just a note for discussion. Executing "AspectMapsUI open" installs >> the traits. One of your trait extension is adding TAMStructuralZoom >> to FAMIXClass. >> >> Now, when I browse the FAMIXClass, I get this in the browser: >> >> ----- >> FAMIXType subclass: #FAMIXClass >> uses: TAMStructuralZoom >> instanceVariableNames: 'isInterface' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Famix-Core' >> ----- >> >> There are two problems with this: >> >> 1. So, now if I just want to edit the base class, I have to take >> care and delete the Trait before, because the Trait is part of the >> definition. >> >> This is a limitation of the browser, but we have to pay attention >> to it. > > My philosophy here is to not hide anything from the developer, which > is why the Trait is part of the definition. What you see is what you > get. Delete the Trait when editing the base class and it goes away. > What you see is what you get. > > So just edit the class as you want to, you can even add new Traits > manually. You can always remove the TAMStructuralZoom trait (or any > other trait actually) using the traits uninstaller. I know that, but I was just pointing out that if I change the base class and commit while your code is loaded, I publish unwillingly your trait. So, when your code is loaded I have to be careful to first remove the trait and only afterwards publish my change. This is a severe limitation and it stems from the Trait definition being tightly coupled with the class definition (both in the model and in the browser). Cheers, Doru >> 2. If you look in Monticello, the base package (FAMIX-Core in this >> case) is not dirty, but if you explicitly look for Changes, it gets >> dirty. I do not know how this could be solved. Perhaps we need >> extension as first class? > > OK this should not happen. I tried to be as close to how the browser > works when redefining a class (the redefinition even gets recorded > in changes) because I want to avoid breaking any magic that is going > on. But apparently I did not succeed completely. If any Monticello > magicians can tell me what incantation to add I would be most happy > to oblige! > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

May 16, 2010

[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