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

Re: [Pharo-project] Minor test runner bug?

by StÃ©phane Ducasse

damien I prefer that we try to confirm this first because after it can take time to close. On May 28, 2009, at 9:00 AM, Damien Cassou wrote: > 2009/5/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Is this a bug ? If someone confirm it I will create a ticket. > > Please create a ticket in all cases. We will close it if it's not a > bug. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 28, 2009

Re: [Pharo-project] How To build exupery?

by Giuseppe Luigi Punzi

I asked, because it won't run. I get the same problems I posted some days on squeak-dev. Trying to run it, I get this: check that /usr/local/lib/squeak/3.10-3/vm-display-X11.so exists, or And I have /usr/local/lib/squeak/3.10-4.... I solved this for squeak, building for sources and make install, and I suppose, I need to do this for exupery. El miÃ©, 27-05-2009 a las 22:09 +0100, Bryce Kampjes escribiÃ³: > On Wed, 2009-05-27 at 20:39 +0200, Giuseppe Luigi Punzi Ruiz wrote: > > I downloaded but I suppose a make install or something like this is > > needed, to put all files and plugins in the rigth place. > > What are you trying to do? The VM's include a pre-built squeak > executable, just execute that. > > There's also some source tarballs but they aren't recommended because > most people should either build from VMMaker (real source) or use a > pre-compiled VM. I supply the source packages because they were asked > for and there are a few legitimate uses for them. > > Bryce > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 28, 2009

[Pharo-project] [Fwd: Re: preferences refactoring]

by Alain Plantec

Hi all, We have to make important decisions about squeak/pharo compatibility regarding the new setting package. The problem is that some packages (as Polymorph but also OB, ecompletion and certainly a lot of others) are included in pharo (aka pharo-dev) but are also used by squeak and the compatibility is now an issue because we plan to remove the Preferences class from Pharo. So, I'm looking for advices about that... Any feedback ? Cheers Alain

May 28, 2009

Re: [Pharo-project] New Pharo based on core 10318 with antialiased fonts

by Damien Cassou

On Wed, May 27, 2009 at 10:32 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Upload where? source.wiresong.ca/ob is world-writeable -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 28, 2009

Re: [Pharo-project] Bug with debugger ?

by Damien Cassou

2009/5/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi folks! I think there is a little (but a bit annoying) bug with the > debugger. To reproduce it: Please open a ticket on the tracker and tell us what image you chose. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 28, 2009

Re: [Pharo-project] Minor test runner bug?

by Damien Cassou

2009/5/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Is this a bug ? If someone confirm it I will create a ticket. Please create a ticket in all cases. We will close it if it's not a bug. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 28, 2009

Re: [Pharo-project] Pharo and XML

by Serge Stinckwich

On Wed, May 27, 2009 at 9:35 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr> wrote: > Hi Torsten, > > The work done by Michael is excellent. The parser works pretty well, > even on big XML files. There is currently no support for XPath > unfortunately. Pastell by Giovanni is a first step, but most of the > test are red. I plan to put some work on Pastell in a few days. We > could do it together if you wish. > > XMLParserTest is a collection of simple and small tests that run out > of the box. No need of external files as the XML testing package > requires as far as I remember. Regarding XML, Julien Bourdon developped some support for RDF : http://www.squeaksource.com/Rikaiko.html -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

May 28, 2009

Re: [Pharo-project] Issue 832

by Schwab,Wilhelm K

Henry, I for one appreciate your effort, and encourage you to keep going. Speaking of slow machines, I have a small herd and would be willing to help you profile the problem. Give me about a month, and I will be in a position to press them into service to help with this. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen Sent: Wednesday, May 27, 2009 5:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic! Cheers, Henry On 27.05.2009 23:54, Henrik Sperre Johansen wrote: Yes, rollbacking probably is the safest choice, As I implied in the mail, this was really meant as a experimental effort, to see if people on slower machines noticed the effects I was (pre)anticipating. I really don't see how an extra intersect: per Morph (containing submorphs) can make such a big difference... I'll definately post another update sometime in the future, I don't know when I'll have to look into it though. <rant> To me, the way it is right now seems unacceptable, there's really no reason to write a "smart" drawOn: routine for morphs that are likely to end up as a subMorph (saaaay, the TextMorph which I started investigating in the first place), as they have to redraw the entire area anyways. This leads to a bad cycle in morph development; "As long as at minimum the area we want to redraw is marked as, it's fine. There's no performance gain from reporting a more accurate area anyways". So you end up with "sloppy" damage rects for new morphs, which leads to more to fix if it IS changed, and slower performance for those whom redrawing the entire area rather than a subsection IS expensive. </rant> Cheers, Henry On 27.05.2009 19:44, StÃ©phane Ducasse wrote: Thanks for reporting. Henrik? I could rollback the changes. Stef On May 27, 2009, at 6:25 PM, Gary Chambers wrote: Performance of UI seems poor after 832 integration. http://code.google.com/p/pharo/issues/detail?id=832 Regards, Gary _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 27, 2009

Re: [Pharo-project] ScriptLoader>>loadMetacello

by Dale Henrichs

What I would add is that there is a functional prototype (alpha version) available now that is being experimented with a bit. If you've got a particular set of package management/version/configuration problems that you're struggling with right now, I'd be interested in hearing about your particular problems, so I can see if there is a way of solving the problem with Metacello. I've gotten very useful feedback so far and plan on rewriting the system based on that feedback. So as it stands there is gap between what the prototype actually does today and what it will do after the rewrite... I am hopeful that the I will have a useful system a month from now and documentation would naturally follow. Dale ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | No real documentation for now, only email exchanges. Metacello | currently works at top of MC1 and using MC2 should not be a problem. | It is still early work, but looks promising. Dale is putting a great | | energy into it. I am experimenting with few projects I am familiar | with. I will send a report to this mailing list in a few days time. | | Cheers, | Alexandre | | | On 27 May 2009, at 16:10, Mariano Martinez Peck wrote: | | > Ahh okok. Is this documented somewhere? For example, advantages it | | > has compared to standard MC ? or against MC 2. Features? is it | > stable or is still in development phase ? | > | > thanks! | > | > Mariano | > | > On Wed, May 27, 2009 at 7:06 PM, Alexandre Bergel | > <alexandre(a)bergel.eu> wrote: | > A version management system built at the top of Monticello by Dale | > Henrichs from Gemstone. It is a bit early to say whether it will | gain | > a large adoption in Pharo or not. But one single method does not | hurt | > much I think | > | > Dale, are you member of Pharo? | > | > Cheers, | > Alexandre | > | > | > On 27 May 2009, at 15:59, Mariano Martinez Peck wrote: | > | > > hey what's Metacello ? | > > | > > On Wed, May 27, 2009 at 6:55 PM, Alexandre Bergel | <Alexandre.Bergel(a)inria.fr | > > > wrote: | > > Name: ScriptLoader-Alexandre_Bergel.877 | > > Author: Alexandre.Bergel | > > Time: 27 May 2009, 3:43:22 pm | > > UUID: 84df91c2-2efc-4cfd-8f0a-d566e9e05f73 | > > Ancestors: ScriptLoader-stephane_ducasse.876, ScriptLoader- | > > Alexandre_Bergel.861 | > > | > > - minor refactoring | > > - added loadMetacello | > > | > > ISSUE 850 | > > | > > Waiting in PharoInbox | > > | > > Cheers, | > > Alexandre | > > -- | > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > > Alexandre Bergel http://www.bergel.eu | > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > > | > > | > > | > > _______________________________________________ | > > 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 | > | > -- | > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > Alexandre Bergel http://www.bergel.eu | > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > | > | > | > | > | > | > _______________________________________________ | > 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 | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 27, 2009

Re: [Pharo-project] Issue 832

by Henrik Sperre Johansen

Sorry, just back from the pub (YAY BARCELONA!) my initial reaction was really: I'd rather see the cause of such slowdowns while resizing investigated (and fixed), but considering the time needed to accomplish that, rollbacking is probably a safer option at this time. My mind absolutely boggles that a resizing performance decrease would be the most visible effect of the changes made in that update... Welcome to the wonderful world of Morphic! Cheers, Henry On 27.05.2009 23:54, Henrik Sperre Johansen wrote: > Yes, rollbacking probably is the safest choice, > As I implied in the mail, this was really meant as a experimental > effort, to see if people on slower machines noticed the effects I was > (pre)anticipating. > I really don't see how an extra intersect: per Morph (containing > submorphs) can make such a big difference... > > I'll definately post another update sometime in the future, I don't > know when I'll have to look into it though. > <rant> > To me, the way it is right now seems unacceptable, there's really no > reason to write a "smart" drawOn: routine for morphs that are likely > to end up as a subMorph (saaaay, the TextMorph which I started > investigating in the first place), as they have to redraw the entire > area anyways. > This leads to a bad cycle in morph development; > "As long as at minimum the area we want to redraw is marked as, it's > fine. There's no performance gain from reporting a more accurate area > anyways". > So you end up with "sloppy" damage rects for new morphs, which leads > to more to fix if it IS changed, and slower performance for those whom > redrawing the entire area rather than a subsection IS expensive. > </rant> > > Cheers, > Henry > > > On 27.05.2009 19:44, StÃ©phane Ducasse wrote: >> Thanks for reporting. >> Henrik? >> I could rollback the changes. >> >> Stef >> >> On May 27, 2009, at 6:25 PM, Gary Chambers wrote: >> >> >>> Performance of UI seems poor after 832 integration. >>> >>> http://code.google.com/p/pharo/issues/detail?id=832 >>> >>> Regards, Gary >>> >>> _______________________________________________ >>> 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 27, 2009