Stef, The slice depends on Collections-Sequencable-nice.46.mcz; loading that using the file browser gets about half way and hangs; loading it via MC gets to "cleaning up" and hangs. I'm using the 9.11.1 web image.
Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Schwab,Wilhelm K Sent: Thursday, November 05, 2009 10:41 PM To: [email protected] Subject: Re: [Pharo-project] Error handling failure during load Stef, That's great! I see it and will give it a try. I wonder if I can go for a run and sleep at the same time? Maybe we could add that to milestone 2 :) Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stéphane Ducasse Sent: Thursday, November 05, 2009 3:48 PM To: [email protected] Subject: Re: [Pharo-project] Error handling failure during load 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: [email protected] [mailto:pharo- > [email protected]] On Behalf Of Stéphane Ducasse > Sent: Thursday, November 05, 2009 3:28 PM > To: [email protected] > 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: [email protected] [mailto:pharo- >> [email protected]] On Behalf Of Stéphane Ducasse >> Sent: Thursday, November 05, 2009 1:42 PM >> To: [email protected] >> 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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
