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

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

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

Nov. 6, 2009

Re: [Pharo-project] Shadowed Variables

by StÃ©phane Ducasse

> Well, with the presence of traits, i don't see how we could avoid > that nicely. May be I missed something but I do not see why? If I do not use in a trait a local variable that are the same name as an iv then I have no problem. So just using a different local or iv solve it. Stef

Nov. 6, 2009

Re: [Pharo-project] Shadowed Variables

by StÃ©phane Ducasse

I do not understand why this would be related to traits it seems to me more like a bad coding practices. May be cyrille did not pay attention to that. >>> >> Yes, but that would occur when adding a Trait to class >> definition... Or when adding an inst var to a traitified class >> definition >> In both case, you don't have method source under the browser scope, >> so it is hard to interact. I guess this was a (bad) reason >> motivating silent warnings. > > I see. A side effect of augmenting Smalltalk with Traits! > > I'm too tired now to offer an intelligent suggestion on how to > overcome > this difficulty "structurally", but let's see if until the sprint we > can discuss something about it. > > Regards, > > -- > Cesar Rabak > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 6, 2009

Re: [Pharo-project] [update] 1.0 #10439

by Adrian Lienhard

yes, that usually works well. I had just quit the image too early last time. Adrian On Nov 5, 2009, at 11:31 , Damien Cassou wrote: > On Wed, Nov 4, 2009 at 6:39 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> yes, sorry for the confusion > > normally you just have to copy/past the content in the workspace in > the email. Don't you have a workspace opened at the end of the > release? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 6, 2009

Re: [Pharo-project] Announcements question

by HernÃ¡n Morales Durand

2009/11/4 keith <keith_hodges(a)yahoo.co.uk> > > On 4 Nov 2009, at 23:58, HernÃ¡n Morales Durand wrote: > > > Hi Keith, thanks for your reply. > > I've tried your implementation a bit this way: > > Ok, the package is SeaWA-Core, > > First of all we add a double dispatch back to the Announcement, > enabling the Announcement subclass to be able to specialize announcing > policy. e.g. the default is to announce to all dependents, but you > might want to announce to all dependents that meet a certain criteria. > > The class comment describes this as follows: > ====== > Unlike normal announcers which figure out what to announce to whom, as > much responsibility is given to each Announcement as possible so that > behaviour can be overriden completely for different scenarios. > > When handling an announcement we double back and send #announceTo: to > the announcement itself to give it complete control, over what it does > before or after informing dependants. Its default behaviour is > #dependantsAnnounce . This allows an Announcement to replace the > behaviour of Announcer-#dependantsAnnounce: altogether if it wants to. > ======== > > A second enhancement is to return the announcement from the invocation > of the trigger. Though I cant remember exactly why this is now. > > ======= > Triggering example: (we always return the original announcement) > > theAnnouncement := self announcer announce: (SomeAnnouncement param: > arg1). > ======= > > Now here we come to the interesting bit. > > =============== > Subscriptions example: > > self announcer on: SomeAnouncement do: [ :announcement | ... ]. > self announcer on: SomeAnouncement send: #tellMe: to: anObject. > > Normally, the announcer is passed as the argument, however, each > announcement class defines #args, so it can call a method that is not > expecting an Announcement as the parameter. This enables you to wire > up objects that were not designed with announcements in mind. > > example trigger: > self announce: (HtmlUpdateAnnouncement on: html) > > self announcer on: HtmlUpdateAnouncement send: #renderOn: to: anObject. > > where: > > HtmlUpdateAnnouncement-#args > ^ Array with: html > > ================= > > > does that help? > Now I see the potential (the double dispatching is actually a scenario where making Announcements as classes does make more sense). Although I can adapt the api with your approach, my issue is a situation where I want to keep the current interface (supporting Announcements transparently) and, at the tech level, setting up widgets inside containers which broadcast events both at asynchronous (with AJAX) and synchronous submission time, under this scenario, it is necessary to catch the contained arguments at subscription time for setting up its notification. Otherwise, if I choose to notify at signalling time, I have to select for all of them later which could be inefficient since they could be nested at many levels. Anyway today, with an amazing lack of inspiration, I wrote an extension to the implementation to write something like: eventSource subscribe: ( AnnouncementMockA with: argument ) send: #value: to: anObject. Just for the record, if someone needs this feature, it would be in the next SmallFaces release. Cheers, > HernÃ¡n

Nov. 6, 2009

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

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

Nov. 6, 2009

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

by David T. Lewis

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: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis > Sent: Thursday, November 05, 2009 4:00 PM > To: Pharo-project(a)lists.gforge.inria.fr > 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 >

Nov. 6, 2009

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

by Schwab,Wilhelm K

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

Nov. 6, 2009

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

by 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: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Thursday, November 05, 2009 4:00 PM To: Pharo-project(a)lists.gforge.inria.fr 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 Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 6, 2009

Re: [Pharo-project] Compiler compile:

by Igor Stasenko

2009/11/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I think that what we should get is > > > Compiler compile: 'text' with: aCompilingContext > > aCompilingContext should hold the information about > Â Â Â Â where: in > Â Â Â Â classified: > Â Â Â Â failing > Â Â Â Â noytfying > Â Â Â Â .... > Since i tried to get rid of that in Moebius, it wont hurt if i share my experience here :) Currently i end up with following public entry points for parsing and compiling: parse: sourceStream in: environment requestor: aRequestor parseDoIt: sourceStream in: environment requestor: aRequestor compile: aSourceStream in: env requestor: aRequestor compileDoIt: sourceStream in: environment requestor: aRequestor the requestor object in one who responsible for handling errors, warnings and notifications etc. and environment object is one who responsible for providing essentials, needed for a method where it will be installed & work, like resolving variables bindings etc. In most cases, the environment is some class. But there are things like doits in specific context during debugging, where environment object should 'see' not only the variables of receiver, but also temporary variables, declared in current context. These two objects + source code is enough to parse & produce a compiled method. I'm also had a variation, where Requestor was responsible for answering whether incoming source is doit or not (by having #noPattern method), but then i found that it would be more convenient to designate such intent more directly , and use different selector instead of requiring the requestor to implement additional protocol ('noPattern' method). > Stef > > On Nov 3, 2009, at 10:32 PM, Igor Stasenko wrote: > >> 2009/11/3 Lukas Renggli <renggli(a)gmail.com>: >>>> Well, I can rename the compile: method and post to PharoInbox, if >>>> anyone is interested. >>> >>> Also I agree that it is confusing, but there are tons of projects >>> that >>> depend on this function. #compile: and #compile:classified: are about >>> the only two compiler related methods that are available cross >>> platform. If you rename them you will break any code that compiles >>> something, including the Refactoring Browser, SmaCC, OmniBrowser, >>> Seaside (for the file libraries), etc. >>> >> You are right , of course. >> >> But inner API should be simplified. >> For instance, take a look at compiler invocation here: >> >> self compilerClass new >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â compile: code >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â in: self >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â classified: category >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notifying: requestor >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFail: failBlock. >> >> i really don't understand, why compiler would be interested in a >> method's category? >> What is the purpose of passing this extra info to compiler? >> The main purpose of compiler is to produce the CompiledMethod >> instance, and compiler should not care >> about anything related to installation of the resulting method into >> class and its categorization. >> >> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 5, 2009