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

Re: [Pharo-project] Fwd: nice bug with regex

by csrabak＠bol.com.br

Em 05/11/2009 05:19, Lukas Renggli < renggli(a)gmail.com > escreveu: > 2009/11/5 Lukas Renggli : > > I don't know, I did not write the code. I trust it, because it > > passes the test suite of Henry Spencer's regexp.c package. > > Lukas I'm not sure if this is trivial and you're looking for something else, but for standards this link is a start: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html and if you want an historic perspective and an European Standard in melting pot: http://www.opengroup.org/onlinepubs/007908799/xbd/re.html. HTH -- Cesar Rabak

Nov. 5, 2009

[Pharo-project] chasing AnObsoleteFlaps

by Nicolas Cellier

I tried this to get rid of AnObsoleteFlaps Preferences dictionaryOfPreferences: (Preferences dictionaryOfPreferences reject: [:e | e value isObsolete]). Unfortunately, RequiredSelectors still has some references... Just too bad.

Nov. 5, 2009

Re: [Pharo-project] Shadowed Variables

by csrabak＠bol.com.br

Em 04/11/2009 18:25, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> escreveu: > 2009/11/4 : > > Em 04/11/2009 17:53, Nicolas Cellier escreveu: > > Right. However, shouldn't the message about shadowing be issued > > when we accept the method in the browser? > > > Yes, but that would occur when adding a Trait to class > definition... Or when adding an inst var to a traitified class > definition > In both case, you don't have method source under the browser scope, > so it is hard to interact. I guess this was a (bad) reason > motivating silent warnings. I see. A side effect of augmenting Smalltalk with Traits! I'm too tired now to offer an intelligent suggestion on how to overcome this difficulty "structurally", but let's see if until the sprint we can discuss something about it. Regards, -- Cesar Rabak

Nov. 5, 2009

Re: [Pharo-project] Compiler compile:

by StÃ©phane Ducasse

Niko what would be cool is that you design a new interface so that we can see how it feels and we integrate it. rename is for simple and fast stuff. Migrating is for used software. :) On Nov 4, 2009, at 10:20 AM, Niko Schwarz wrote: > Every project needs to have sacred cows that may not be tipped :D. > > Well, alright, in case that we can't agree on renaming, how about my > original proposal, which left everything the way it was and only added > the class-side compile:onClass: method to Compiler? Possibly sided by > compile:onClass:ifFail: > > Cheers, > > Niko > > On Tue, Nov 3, 2009 at 10:23 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: >>> Well, I can rename the compile: method and post to PharoInbox, if >>> anyone is interested. >> >> Also I agree that it is confusing, but there are tons of projects >> that >> depend on this function. #compile: and #compile:classified: are about >> the only two compiler related methods that are available cross >> platform. If you rename them you will break any code that compiles >> something, including the Refactoring Browser, SmaCC, OmniBrowser, >> Seaside (for the file libraries), etc. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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

Nov. 5, 2009

Re: [Pharo-project] Compiler compile:

by StÃ©phane Ducasse

What would be nice is to propose a nice interface (based on compiler context to remove this argument plague) Then to slowly migrate to it using deprecation. Stef On Nov 3, 2009, at 10:23 PM, Lukas Renggli wrote: >> Well, I can rename the compile: method and post to PharoInbox, if >> anyone is interested. > > Also I agree that it is confusing, but there are tons of projects that > depend on this function. #compile: and #compile:classified: are about > the only two compiler related methods that are available cross > platform. If you rename them you will break any code that compiles > something, including the Refactoring Browser, SmaCC, OmniBrowser, > Seaside (for the file libraries), etc. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2009

Re: [Pharo-project] Compiler compile:

by StÃ©phane Ducasse

I think that what we should get is Compiler compile: 'text' with: aCompilingContext aCompilingContext should hold the information about where: in classified: failing noytfying .... Stef On Nov 3, 2009, at 10:32 PM, Igor Stasenko wrote: > 2009/11/3 Lukas Renggli <renggli(a)gmail.com>: >>> Well, I can rename the compile: method and post to PharoInbox, if >>> anyone is interested. >> >> Also I agree that it is confusing, but there are tons of projects >> that >> depend on this function. #compile: and #compile:classified: are about >> the only two compiler related methods that are available cross >> platform. If you rename them you will break any code that compiles >> something, including the Refactoring Browser, SmaCC, OmniBrowser, >> Seaside (for the file libraries), etc. >> > You are right , of course. > > But inner API should be simplified. > For instance, take a look at compiler invocation here: > > self compilerClass new > compile: code > in: self > classified: category > notifying: requestor > ifFail: failBlock. > > i really don't understand, why compiler would be interested in a > method's category? > What is the purpose of passing this extra info to compiler? > The main purpose of compiler is to produce the CompiledMethod > instance, and compiler should not care > about anything related to installation of the resulting method into > class and its categorization. > > >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2009

Re: [Pharo-project] Error handling failure during load

by David T. Lewis

On Thu, Nov 05, 2009 at 02:22:48PM -0500, Schwab,Wilhelm K wrote: > > Stef, > > The classes in CommandShell-Piping would be better separated from CommandShell. That said, I do not terribly much care about loading CommandShell to get pipes - I care a lot that it won't load w/o proceeding past two warnings followed by a debug/edit/proceed cycle. I have no idea whether it is a true fix or not, but I commented out the offending line and re-saved the package, only to find that it loads w/o hassles. If it really is that simple, the repository should be fixed. > Bill, Please send me your patch for this (lewis at mail dot msen dot com). r.e. CommandShell-Piping FYI when I split OSProcess into two packages (OSProcess and CommandShell) many years back, I split it in such a way that there were no dependencies between the two, and that put the piping support in CommandShell (which of course is where piping is needed). Back then I don't think anybody really used either package, so it did not matter where I did the split ;-) Now it seems that folks have found uses for the piping stuff, and I guess it would be better moved into OSProcess or maybe a separate package. It's a bit of work to do that and breaks backward compatibility of the packages, so I have not done anything to change it. Thanks, Dave

Nov. 5, 2009

[Pharo-project] [update 1.1] #11034

by StÃ©phane Ducasse

11034 ----- - Issue 1415: New version VBRegex - Issue 1413: remove presenter inst var from PasteUpMorph enjoy. Stef

Nov. 5, 2009

Re: [Pharo-project] Error handling failure during load

by StÃ©phane Ducasse

in the inbox the slice proposed by nicolas which fixees the interface of SharedQueue2 Stef On Nov 5, 2009, at 9:41 PM, Schwab,Wilhelm K wrote: > Stef, > > I'm happy to help, but don't know where to look. Where can I find > it, and (roughly) what do I need to do to load it? Which topic does > it address (piping or the SharedQueu)? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Thursday, November 05, 2009 3:28 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Error handling failure during load > > bill load the slice of nicolas and let us know. > I integrated in 1.1 > and adrian will probably integrate it in 1.0 > > Stef > > On Nov 5, 2009, at 8:22 PM, Schwab,Wilhelm K wrote: > >> >> Stef, >> >> The classes in CommandShell-Piping would be better separated from >> CommandShell. That said, I do not terribly much care about loading >> CommandShell to get pipes - I care a lot that it won't load w/o >> proceeding past two warnings followed by a debug/edit/proceed cycle. >> I have no idea whether it is a true fix or not, but I commented out >> the offending line and re-saved the package, only to find that it >> loads w/o hassles. If it really is that simple, the repository >> should >> be fixed. >> >> Re Metacello, I looked around for information, found a lot of future >> tense writing that looked interesting, and went back to cleaning up >> my >> recreation of Migrate for Pharo. The result is not as flashy as >> Migrate, but it adds the search for unpackaged code that I wrote >> (something I have never found missing in Dolphin given its IDE) and >> it >> seems to simplify saving all packages of interest. >> >> I will keep an eye on Metacello, but I do not really need it at the >> moment. Of greater concern to me is that I am dead in the water on >> RC1. The SharedQueue2 bug stops me cold every time I try to build an >> image, and strikes in a way that will not allow me to debug it by >> normal means. Do we have a procedure for reverting to SharedQueue? >> That might at least get me going. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- >> project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >> Sent: Thursday, November 05, 2009 1:42 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Error handling failure during load >> >> >> On Nov 3, 2009, at 5:17 PM, Schwab,Wilhelm K wrote: >> >>> Hello all, >>> >>> I am gradually approaching a working load "script," but I just hit a >>> new wrinkle in RC1: at some point in the process I get offered an >>> emergency evaluator, which appears unable to open. There is mention >>> of looking for something in the system dictionary, and something >>> about "system error handling failed." Nothing is logged, and the >>> image is helpless at that point. Any ideas for how to debug it? >>> >>> Creating my own build log comes to mind; the idea would be to open/ >>> update/close each time it starts work on a new package. I can also >>> load the loader into a clean older image and see what happens. >>> >>> It would be _really_ nice to have a clean-loading version of OS >>> Process/Command Shell. Actually, I do not need the shell at all, >>> but >>> I do need the pipeable processes. >> >> damien told today that it would be nice that some CommandShell class >> such as (I do not remember) StdOut/SdtIn could be packaged with >> OSProcess and not with CommandShell. Or that they are separated >> because people want to get them but not need the CommandShell. >> >> Now bill did you got a look at Metacello? >> Because I'm sure it can help to maintain your packaged code. >> >> Stef >> >> >> >>> >>> Bill >>> >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2009

Re: [Pharo-project] Error handling failure during load

by Schwab,Wilhelm K

Stef, I'm happy to help, but don't know where to look. Where can I find it, and (roughly) what do I need to do to load it? Which topic does it address (piping or the SharedQueu)? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Thursday, November 05, 2009 3:28 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Error handling failure during load bill load the slice of nicolas and let us know. I integrated in 1.1 and adrian will probably integrate it in 1.0 Stef On Nov 5, 2009, at 8:22 PM, Schwab,Wilhelm K wrote: > > Stef, > > The classes in CommandShell-Piping would be better separated from > CommandShell. That said, I do not terribly much care about loading > CommandShell to get pipes - I care a lot that it won't load w/o > proceeding past two warnings followed by a debug/edit/proceed cycle. > I have no idea whether it is a true fix or not, but I commented out > the offending line and re-saved the package, only to find that it > loads w/o hassles. If it really is that simple, the repository should > be fixed. > > Re Metacello, I looked around for information, found a lot of future > tense writing that looked interesting, and went back to cleaning up my > recreation of Migrate for Pharo. The result is not as flashy as > Migrate, but it adds the search for unpackaged code that I wrote > (something I have never found missing in Dolphin given its IDE) and it > seems to simplify saving all packages of interest. > > I will keep an eye on Metacello, but I do not really need it at the > moment. Of greater concern to me is that I am dead in the water on > RC1. The SharedQueue2 bug stops me cold every time I try to build an > image, and strikes in a way that will not allow me to debug it by > normal means. Do we have a procedure for reverting to SharedQueue? > That might at least get me going. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Thursday, November 05, 2009 1:42 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Error handling failure during load > > > On Nov 3, 2009, at 5:17 PM, Schwab,Wilhelm K wrote: > >> Hello all, >> >> I am gradually approaching a working load "script," but I just hit a >> new wrinkle in RC1: at some point in the process I get offered an >> emergency evaluator, which appears unable to open. There is mention >> of looking for something in the system dictionary, and something >> about "system error handling failed." Nothing is logged, and the >> image is helpless at that point. Any ideas for how to debug it? >> >> Creating my own build log comes to mind; the idea would be to open/ >> update/close each time it starts work on a new package. I can also >> load the loader into a clean older image and see what happens. >> >> It would be _really_ nice to have a clean-loading version of OS >> Process/Command Shell. Actually, I do not need the shell at all, but >> I do need the pipeable processes. > > damien told today that it would be nice that some CommandShell class > such as (I do not remember) StdOut/SdtIn could be packaged with > OSProcess and not with CommandShell. Or that they are separated > because people want to get them but not need the CommandShell. > > Now bill did you got a look at Metacello? > Because I'm sure it can help to maintain your packaged code. > > Stef > > > >> >> Bill >> >> >> >> _______________________________________________ >> 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

Nov. 5, 2009