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

Re: [Pharo-project] Streams - #nextLine

by StÃ©phane Ducasse

On Jun 6, 2009, at 7:15 PM, Schwab,Wilhelm K wrote: > Stef, > > I can certainly write some tests. Of course, they would have to > start with a bias toward one behavior (I suggest never answering > nil), and then illustrate the differences in behavior. Is that what > you want to see? yes :) The problem is that I do not have a clear picture of the problem solution and pros and cons (Ansi???) So if you can try in simple emglish to phrase the three following paragraph I think that we could use it as a template and instance for Request for Improvement. > In terms of my modified methods (#nextOne, etc.), I consider them a > compromise, but a necessary one. I can create tests to illustrate > their use, but the real focus is to avoid silent failures. VW even > has a trap in that (IIRC) #next will answer nil, but they get #next: > right. They were willing to discuss a breaking change, but decided > against doing it, so I "gave up" and decided to create my own robust > set of selectors. > > 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: Saturday, June 06, 2009 8:04 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Streams - #nextLine > > Hi bill > > do you have a couple of unit tests so that we can really give you an > answer? > > Stef > On Jun 6, 2009, at 1:19 AM, Schwab,Wilhelm K wrote: > >> Hello all, >> >> You might recall my advocating breaking changes to #next, #next: and >> company: these methods do not behave as advertised, answering nil vs. >> raising an exception when reading off the back of a stream. It was >> fairly clear that the will did not exist to make he required changes, >> so I have put myself on a strict diet of #nextOne, #nextMany:, >> #nextAvailable: that *do* work as expected. I plan to make code for >> these methods available to all, and strongly recommend using them. >> >> My initial efforts with Citezen have convinced me that I am correct >> to >> demand that code function as advertised/expected. I lost a couple of >> hours trying to sort out whether I was faced with a debugger defect, >> but ended up finding a source of inconsistency >> among like-named methods. Look at implementors of #nextLine. >> First, this is perhaps ambiguous given Pharo's cross-platform nature >> - it might be wise to always specify CrLf or simply Lf??? Beyond >> that, some implementations answer nil (why is beyond me, as it leaves >> callers with two things to check when #notEmpty would otherwise >> almost >> always suffice). >> >> Any thoughts? If nothing else, I think the various #nextLine methods >> should behave alike, and as you can tell, I strongly favor answering >> empty vs. nil. >> >> 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 >

June 6, 2009

Re: [Pharo-project] class removal problem

by StÃ©phane Ducasse

so this is an issue :) Stef On Jun 6, 2009, at 6:49 PM, Adrian Lienhard wrote: > > On Jun 6, 2009, at 17:47 , Alain Plantec wrote: > >> Adrian Lienhard a Ã©crit : >>> Hi Alain, >>> >>> Just this morning when removing SqueakMap I noticed the same >>> problem. >>> >>> What I did to solve it is to explicitly execute "ClassToBeRemoved >>> unload" as part of the ScriptLoader update before loading the new >>> package versions >> Thanks. >> Is it an issue or is there a good reason for that ? > > I don't think so. > > However, looking at the code, it seems #unload is sent. > > MCClassDefinition>>#unload sends > Smalltalk removeClassNamed: name > which eventually calls Class>>removeFromSystem: > which call #unload > > Strange... > > Adrian > >> >> alain >>> . >>> >>> Cheers, >>> Adrian >>> >>> On Jun 6, 2009, at 15:47 , Alain Plantec wrote: >>> >>> >>>> Hi all, >>>> >>>> It is about the class load/unload logic. >>>> >>>> I'm trying to remove BooleanPreferenceView. >>>> But this class is registered as a preference view : >>>> --------------- >>>> BooleanPreferenceView class>>initialize >>>> PreferenceViewRegistry ofBooleanPreferences register: self. >>>> --------------- >>>> >>>> BooleanPreferenceView also implements #unload which unregisters >>>> itself >>>> from the registry: >>>> --------------- >>>> BooleanPreferenceView class>>unload >>>> PreferenceViewRegistry ofBooleanPreferences unregister: self >>>> --------------- >>>> >>>> So ok, if I remove the class from the browser, #unload is sent and >>>> the >>>> PreferenceViewRegistry registry is kept clean. >>>> The same if I load a change set. >>>> But if I make a SLICE and load it from a fresh image, then, it >>>> seems >>>> that #unload is not sent because >>>> AnObsoleteBooleanPreferenceView is still referenced by the >>>> PreferenceViewRegistry registry. >>>> >>>> Have I missed something ? >>>> Thanks >>>> Alain >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >

June 6, 2009

Re: [Pharo-project] Fwd: Issue 584 in pharo: SqueakPageCache generateURL -> DNU because pathForFile is not defined on ServerFile

by StÃ©phane Ducasse

I was thinking to move ObjectOut and little friends out of kernel and out them in a dedicated package Then clean MorphObjectOut. There would be nice examples of reflective uses of Smalltalk but I'm not sure that they still work. Now I would do the following: remove BookMorph TabbedPalette SqueakPageCache and see if we can rescue the saving/proxing of Object and Morph Then clean out Project and the other left over from etoy. Stef On Jun 6, 2009, at 3:51 PM, Adrian Lienhard wrote: > When removing SqueakPageCache, shouldn't one remove the whole morph > saving logic (i.e., SqueakPage, ObjectOut, MorphObjectOut and maybe > more)? I have never used this, so I cannot say whether it may be worth > keeping (in which case, we should make it work again). > > Adrian > > On Jun 6, 2009, at 15:05 , StÃ©phane Ducasse wrote: > >> >> >> I would be inclined to say that we should remove SqueakPageCache but >> what the other think? >> SqueakPageCache is a cache for Morph sved on disc and that can be >> reloaded >> Begin forwarded message: >> >>> From: codesite-noreply(a)google.com >>> Date: June 5, 2009 10:53:23 PM CEDT >>> To: stephane.ducasse(a)gmail.com >>> Subject: Issue 584 in pharo: SqueakPageCache generateURL -> DNU >>> because pathForFile is not defined on ServerFile >>> >>> >>> Comment #2 on issue 584 by alain.pl...(a)free.fr: SqueakPageCache >>> generateURL -> DNU because pathForFile is not defined on ServerFile >>> http://code.google.com/p/pharo/issues/detail?id=584 >>> >>> so do we remove SqueakPage (#issue 477) or not ? >>> >>> >>> -- >>> You received this message because you are listed in the owner >>> or CC fields of this issue, or because you starred this issue. >>> You may adjust your issue notification preferences at: >>> http://code.google.com/hosting/settings >> >> >> >> >> >> >> _______________________________________________ >> 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 >

June 6, 2009

Re: [Pharo-project] How to run a "cron" job?

by Eagle Offshore

One way this is often done is to create a url that, when accessed, executes the periodic code you want and replies with a short status. Then create a crontab job on any host you like using curl to fetch that url on a schedule. Works on all web development environments and has the bonus that you can 'kick it' from any web browser if you want it done on demand. -Todd Blanchard On Jun 6, 2009, at 2:46 AM, Oscar Nierstrasz wrote: > > Hi folks, > > I need to run a periodic job in a Pier image. (Checking for new PDF > files and generating news items.) > > What is the recommended way to do this? > > Thanks in advance for any tips. > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 6, 2009

[Pharo-project] Logging package does not compile

by FranÃ§ois Tanguy

Hello, did anyone ever tried to load the "Logging" package from Keith Hodges ? http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-December/132923… In pharo, the following method does not compile. testFilter: aMessage | lowerString | lowerString := aMessage value value asLowercase. ^(self searchString asString substrings allSatisfy: [:sub | sub := (sub asLowercase) replaceAll: $_ with: (Character space). ((sub first = $-) and: [(lowerString includesSubString: sub allButFirst) not]) or: [(sub first = $+) and: [lowerString includesSubString: sub allButFirst]] or: [lowerString includesSubString: sub]]) It is easy to fix by using an extra variable. My question, should we ask Keith to fix this method so that this package would be "pharo loadable" ? FranÃ§ois

June 6, 2009

Re: [Pharo-project] Streams - #nextLine

by Schwab,Wilhelm K

Stef, I can certainly write some tests. Of course, they would have to start with a bias toward one behavior (I suggest never answering nil), and then illustrate the differences in behavior. Is that what you want to see? In terms of my modified methods (#nextOne, etc.), I consider them a compromise, but a necessary one. I can create tests to illustrate their use, but the real focus is to avoid silent failures. VW even has a trap in that (IIRC) #next will answer nil, but they get #next: right. They were willing to discuss a breaking change, but decided against doing it, so I "gave up" and decided to create my own robust set of selectors. 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: Saturday, June 06, 2009 8:04 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Streams - #nextLine Hi bill do you have a couple of unit tests so that we can really give you an answer? Stef On Jun 6, 2009, at 1:19 AM, Schwab,Wilhelm K wrote: > Hello all, > > You might recall my advocating breaking changes to #next, #next: and > company: these methods do not behave as advertised, answering nil vs. > raising an exception when reading off the back of a stream. It was > fairly clear that the will did not exist to make he required changes, > so I have put myself on a strict diet of #nextOne, #nextMany:, > #nextAvailable: that *do* work as expected. I plan to make code for > these methods available to all, and strongly recommend using them. > > My initial efforts with Citezen have convinced me that I am correct to > demand that code function as advertised/expected. I lost a couple of > hours trying to sort out whether I was faced with a debugger defect, > but ended up finding a source of inconsistency > among like-named methods. Look at implementors of #nextLine. > First, this is perhaps ambiguous given Pharo's cross-platform nature > - it might be wise to always specify CrLf or simply Lf??? Beyond > that, some implementations answer nil (why is beyond me, as it leaves > callers with two things to check when #notEmpty would otherwise almost > always suffice). > > Any thoughts? If nothing else, I think the various #nextLine methods > should behave alike, and as you can tell, I strongly favor answering > empty vs. nil. > > 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

June 6, 2009

Re: [Pharo-project] class removal problem

by Adrian Lienhard

On Jun 6, 2009, at 17:47 , Alain Plantec wrote: > Adrian Lienhard a Ã©crit : >> Hi Alain, >> >> Just this morning when removing SqueakMap I noticed the same problem. >> >> What I did to solve it is to explicitly execute "ClassToBeRemoved >> unload" as part of the ScriptLoader update before loading the new >> package versions > Thanks. > Is it an issue or is there a good reason for that ? I don't think so. However, looking at the code, it seems #unload is sent. MCClassDefinition>>#unload sends Smalltalk removeClassNamed: name which eventually calls Class>>removeFromSystem: which call #unload Strange... Adrian > > alain >> . >> >> Cheers, >> Adrian >> >> On Jun 6, 2009, at 15:47 , Alain Plantec wrote: >> >> >>> Hi all, >>> >>> It is about the class load/unload logic. >>> >>> I'm trying to remove BooleanPreferenceView. >>> But this class is registered as a preference view : >>> --------------- >>> BooleanPreferenceView class>>initialize >>> PreferenceViewRegistry ofBooleanPreferences register: self. >>> --------------- >>> >>> BooleanPreferenceView also implements #unload which unregisters >>> itself >>> from the registry: >>> --------------- >>> BooleanPreferenceView class>>unload >>> PreferenceViewRegistry ofBooleanPreferences unregister: self >>> --------------- >>> >>> So ok, if I remove the class from the browser, #unload is sent and >>> the >>> PreferenceViewRegistry registry is kept clean. >>> The same if I load a change set. >>> But if I make a SLICE and load it from a fresh image, then, it seems >>> that #unload is not sent because >>> AnObsoleteBooleanPreferenceView is still referenced by the >>> PreferenceViewRegistry registry. >>> >>> Have I missed something ? >>> Thanks >>> Alain >>> >>> >>> >>> _______________________________________________ >>> 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

June 6, 2009

Re: [Pharo-project] How to run a "cron" job?

by HernÃ¡n Morales Durand

http://squeak.saltypickle.com/Scheduler 2009/6/6 Oscar Nierstrasz <oscar(a)iam.unibe.ch> > > Hi folks, > > I need to run a periodic job in a Pier image. Â (Checking for new PDF > files and generating news items.) > > What is the recommended way to do this? > > Thanks in advance for any tips. > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 6, 2009

Re: [Pharo-project] NetNameResolver - too much cleaning?

by Schwab,Wilhelm K

Adrian, Sorry, I described the wrong problem: it's the other direction (name from address) that is missing. At least on win32, I found it necessary to use both lookups to get fully qualified names, especially for the local host. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Saturday, June 06, 2009 3:47 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NetNameResolver - too much cleaning? Hi Bill It seems to work for me (Mac 4.1.1beta2U): NetNameResolver addressForName: 'pharo-project.org' --> 212.103.66.211(one),0(0) Doesn't that work for you or are you trying something else? Adrian On Jun 6, 2009, at 01:22 , Schwab,Wilhelm K wrote: > Hello all, > > There is no good way to get an address given a name :( I tried > "borrowing" code from 3.9 and was roundly punished: it hangs > miserably. Any ideas? > > 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

June 6, 2009

Re: [Pharo-project] class removal problem

by Alain Plantec

Adrian Lienhard a Ã©crit : > Hi Alain, > > Just this morning when removing SqueakMap I noticed the same problem. > > What I did to solve it is to explicitly execute "ClassToBeRemoved > unload" as part of the ScriptLoader update before loading the new > package versions Thanks. Is it an issue or is there a good reason for that ? alain > . > > Cheers, > Adrian > > On Jun 6, 2009, at 15:47 , Alain Plantec wrote: > > >> Hi all, >> >> It is about the class load/unload logic. >> >> I'm trying to remove BooleanPreferenceView. >> But this class is registered as a preference view : >> --------------- >> BooleanPreferenceView class>>initialize >> PreferenceViewRegistry ofBooleanPreferences register: self. >> --------------- >> >> BooleanPreferenceView also implements #unload which unregisters itself >> from the registry: >> --------------- >> BooleanPreferenceView class>>unload >> PreferenceViewRegistry ofBooleanPreferences unregister: self >> --------------- >> >> So ok, if I remove the class from the browser, #unload is sent and the >> PreferenceViewRegistry registry is kept clean. >> The same if I load a change set. >> But if I make a SLICE and load it from a fresh image, then, it seems >> that #unload is not sent because >> AnObsoleteBooleanPreferenceView is still referenced by the >> PreferenceViewRegistry registry. >> >> Have I missed something ? >> Thanks >> Alain >> >> >> >> _______________________________________________ >> 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 > > >

June 6, 2009