Error handling failure during load

> Bill
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
> Sent: Tuesday, November 03, 2009 11:32 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] Error handling failure during load
>
> 2009/11/3 Schwab,Wilhelm K <[hidden email]>:
>> 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.
>>
>
> Sake is your friend then :)
>
>> Bill
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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.

> 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.

>
> 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: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of Stéphane Ducasse
> Sent: Thursday, November 05, 2009 1:42 PM
> To: [hidden email]
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> 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: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of Stéphane Ducasse
> Sent: Thursday, November 05, 2009 1:42 PM
> To: [hidden email]
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of Stéphane Ducasse
> Sent: Thursday, November 05, 2009 3:28 PM
> To: [hidden email]
> 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: [hidden email] [mailto:pharo-
>> [hidden email]] On Behalf Of Stéphane Ducasse
>> Sent: Thursday, November 05, 2009 1:42 PM
>> To: [hidden email]
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of Stéphane Ducasse
> Sent: Thursday, November 05, 2009 3:28 PM
> To: [hidden email]
> 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: [hidden email] [mailto:pharo-
>> [hidden email]] On Behalf Of Stéphane Ducasse
>> Sent: Thursday, November 05, 2009 1:42 PM
>> To: [hidden email]
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Having command shell come along with the pipes is not a very big problem.  Having the packages load cleanly would be huge in itself.
>
> I hope to use pipes to control gnuplot from Pharo.  Another possible use would be to create a LaTeX IDE, but that is farther away and harder to justify.  Why write one at all?  TeX maker is pretty good, but it would be nice to embed Smalltalk expressions that can generate LaTeX source; I did that in Dolphin and it worked reasonably well.  One weakness of TeX maker (perhaps more a weakness of TeX Live, or maybe I just haven't found it yet) is a tool such as texify that does everything needed to update a document.
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of David T. Lewis
> Sent: Thursday, November 05, 2009 4:00 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Error handling failure during load
>
> 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
>

> 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: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of Stéphane Ducasse
> Sent: Thursday, November 05, 2009 3:28 PM
> To: [hidden email]
> 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: [hidden email] [mailto:pharo-
>> [hidden email]] On Behalf Of Stéphane Ducasse
>> Sent: Thursday, November 05, 2009 1:42 PM
>> To: [hidden email]
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of Schwab,Wilhelm K
> Sent: Thursday, November 05, 2009 10:41 PM
> To: [hidden email]
> 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: [hidden email] [mailto:pharo-
> [hidden email]] On Behalf Of Stéphane Ducasse
> Sent: Thursday, November 05, 2009 3:48 PM
> To: [hidden email]
> 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: [hidden email] [mailto:pharo-
>> [hidden email]] On Behalf Of Stéphane Ducasse
>> Sent: Thursday, November 05, 2009 3:28 PM
>> To: [hidden email]
>> 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: [hidden email] [mailto:pharo-
>>> [hidden email]] On Behalf Of Stéphane Ducasse
>>> Sent: Thursday, November 05, 2009 1:42 PM
>>> To: [hidden email]
>>> 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
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project