Error handling failure during load

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Error handling failure during load

Schwab,Wilhelm K
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.

Bill



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Igor Stasenko
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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Schwab,Wilhelm K
Sig,

How would Sake help?

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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Igor Stasenko
2009/11/3 Schwab,Wilhelm K <[hidden email]>:
> Sig,
>
> How would Sake help?
>
It supports logging and defining a 'build process'

http://wiki.squeak.org/squeak/Sake

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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Stéphane Ducasse
In reply to this post by Schwab,Wilhelm K

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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Schwab,Wilhelm K
 
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:[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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Dale
In reply to this post by Schwab,Wilhelm K
Bill,

Have you looked at http://code.google.com/p/metacello? I don't think there's a lot of future tense writing there:).

Dale
----- "Wilhelm K Schwab" <[hidden email]> 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:[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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Stéphane Ducasse
In reply to this post by Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

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: [hidden email] [mailto:[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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

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: [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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

David T. Lewis
In reply to this post by Schwab,Wilhelm K
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Schwab,Wilhelm K
Dave,

First, many thanks for the packages!  All I am aware that I did was comment out the line in #initialize that opens the workspace and re-save.  Can you make that change and post a new version?  If for any reason that turns out not to load cleanly for me, then I can track down what else I might have done and makge that available.

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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Schwab,Wilhelm K
In reply to this post by Stéphane Ducasse
 
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:[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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

David T. Lewis
In reply to this post by Schwab,Wilhelm K
On Thu, Nov 05, 2009 at 10:36:31PM -0500, Schwab,Wilhelm K wrote:
> Dave,
>
> First, many thanks for the packages!  All I am aware that I did was comment out the line in #initialize that opens the workspace and re-save.  Can you make that change and post a new version?  If for any reason that turns out not to load cleanly for me, then I can track down what else I might have done and makge that available.
>

I'll take a look at it again this weekend, and update if I can find the underlying
problem. I think there is some difference in Pharo that is making the pipe processing
work incorrectly (hence the error in #initialize but there are issues elsewhere too,
see the unit tests). I have not figured it out yet, so if anyone has any ideas
please let me know.

Dave

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
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:[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:[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
Reply | Threaded
Open this post in threaded view
|

Re: Error handling failure during load

Stéphane Ducasse
strange I could load it without problem.
I integrated it in pharo1.1

Stef

On Nov 6, 2009, at 6:01 AM, Schwab,Wilhelm K wrote:

> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project