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

Re: [Pharo-project] Citezen loading (Rio-Kernel defect)

by Damien Pollet

On Fri, Jun 5, 2009 at 18:41, Oscar Nierstrasz<oscar(a)iam.unibe.ch> wrote: > But a more robust and forgiving parser is needed. Well at least it would be nice if it could report errors, but that's a pain to do with LR parsers. I think I have an OMeta attempt somewhere but it will probably be slower than SmaCC. Personally I'd rather have a strict but simple parser and some assistance to fix bad .bib files than a permissive parser. Maybe one step would be to keep the current parser, but only use it to parse entries one by one instead of using a grammar rule for the whole file. > On Jun 5, 2009, at 16:20, Schwab,Wilhelm K wrote: >> I found the problem: #newForWin32 is missing the #new, so it sends That's a Rio bug then, please report it there. >> the class to do an instance's job. Â I fixed that, but Monitcello was >> determined to undo my efforts. Â After a few tries at getting around >> that, I realized that it should run on Linux, so I did the >> installation there and then added my fix so that it should run on >> win32 also. Â That appears to have worked. >> >> I find that it cannot parse my "real" .bib files, but it does seem >> to handle things that I build up from entries from Google scholar. >> The bib files in question are tested in the sense the LaTeX/BibTeX >> are happy with them, but I have yet to try bibclean on them. Â Is >> there any documentation or example code available? >> >> 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 > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

June 7, 2009

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

by Oscar Nierstrasz

Thanks! I'm embarrassed I did not think of that. I already have the web interface -- just need a fixed url to trigger it. - on On Jun 6, 2009, at 21:49, Eagle Offshore wrote: > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 7, 2009

Re: [Pharo-project] Streams - #nextLine

by Nicolas Cellier

Before adding a new set of messages, why not make the endOfStream pluggable? I mean add an endOfStream inst. var. to Stream. Initialize it with something that can understand value and will answer nil to not break existing base ([] for instance, or nil->nil) Then use (^endOfStream value) where due. Provide some handy hooks like: Stream>>doSignalEndOfStream endOfStream := [EndOfStreamError raise]. Stream>>doNotifyEndOfStream endOfStream := [EndOfStreamNotification raise]. Nicolas 2009/6/7 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Stef, > > I will see what I can do. I want to make my changes available, as I think they should be widely used, and it would nice to have them in the mainstream Pharo so that at least I can release code depending one them. I still think the correct action is to fix the behavior, but I am not optimistic. VW's #next has the same willingness to answer nil vs. raise an exception, and they too are hesitant to fix it for fear of breaking existing code. In Squeak/Pharo, #next: is also affected, doing what should be reserved for #nextAvailable:. > > The idea is to have "honest" semantics, in which there are strict and truncating versions of the selectors, putting thep programmer in charge. The strict versions do not answer nil; they raise and exception, calling attention to the failure vs. making the caller dig for it. Not being optimisic about a fix, I created new selectors that work as advertised, and have deprecated the ones that can fail silently. > > #nextLine is easier to call buggy, as the implementation details (specifically whether or not it can return nil - something it should not do IMHO) depends on the receiving class. It seems to me that one should be able to change stream type and get results that are as similar as possible, within the limits of generating and non-generating streams, of course. > > I will wrap what I can of this into some tests. > > 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 3:40 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Streams - #nextLine > > > 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 >> > > > _______________________________________________ > 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 7, 2009

Re: [Pharo-project] Streams - #nextLine

by Schwab,Wilhelm K

Stef, I will see what I can do. I want to make my changes available, as I think they should be widely used, and it would nice to have them in the mainstream Pharo so that at least I can release code depending one them. I still think the correct action is to fix the behavior, but I am not optimistic. VW's #next has the same willingness to answer nil vs. raise an exception, and they too are hesitant to fix it for fear of breaking existing code. In Squeak/Pharo, #next: is also affected, doing what should be reserved for #nextAvailable:. The idea is to have "honest" semantics, in which there are strict and truncating versions of the selectors, putting thep programmer in charge. The strict versions do not answer nil; they raise and exception, calling attention to the failure vs. making the caller dig for it. Not being optimisic about a fix, I created new selectors that work as advertised, and have deprecated the ones that can fail silently. #nextLine is easier to call buggy, as the implementation details (specifically whether or not it can return nil - something it should not do IMHO) depends on the receiving class. It seems to me that one should be able to change stream type and get results that are as similar as possible, within the limits of generating and non-generating streams, of course. I will wrap what I can of this into some tests. 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 3:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Streams - #nextLine 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 > _______________________________________________ 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] [ANN] Relicensing rewrites

by Gabriel Cotelli

I upload to the Pharo Inbox: Name: SLICE-FileDirectoryFloat-GabrielOmarCotelli.2 Author: GabrielOmarCotelli Time: 6 June 2009, 8:16:57 pm UUID: 10ab60e2-df85-bb45-bd2c-36e69e2b047c Ancestors: SLICE-FileDirectoryFloat-GabrielOmarCotelli.1 Dependencies: CollectionsTests-GabrielOmarCotelli.359, Exceptions-GabrielOmarCotelli.18, Files-GabrielOmarCotelli.ducasse.53, Kernel-GabrielOmarCotelli.renggli.343, KernelTests-GabrielOmarCotelli.112 Rewrite FileDirectory>>oldFileOrNoneNamed: , Float>>/, DictionaryTest>>testIncludesAssociationNoValue. Added test cases Gabriel

June 6, 2009

[Pharo-project] Win32Setup for 10324dev09.06.1

by Torsten Bergmann

Within the pharo files page [1] you will now also find a new Win32 Setup [2] based on the latest "pharo0.1-10324dev09.06.1.". This now also includes the fonts as provided by Damien. Attached you will find the new modified NSIS script - based on [3]. Janko wrote >So, there is at least some short text needed to encourage user to >explore further, at least a reference to Squeak by example book. And how >to open a Class browser ... I expect to soon have a "Pharo by example" from Stephane and friends?! ;) If so I will package the PDF right into the setup... Depending on time we can also finish the "Getting started workspace" Have fun Torsten [1] https://gforge.inria.fr/frs/?group_id=1299 [2] https://gforge.inria.fr/frs/download.php/22410/setup_pharo_0.0.0.3.exe [3] http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008790.html [4] http://code.google.com/p/pharo/wiki/GettingStartedWorkspaces -------------------------------------------------------------------------- -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

June 6, 2009

Re: [Pharo-project] can we remove TabbedPalette

by Alain Plantec

Lukas Renggli a Ã©crit : > I recently fixed the SmaCC GUI to work in Pharo. I replaced the old > tabs with morphs from Polymorph, but the GUI is a mess indeed. Feel > free to commit your changes to the repository. > Hi Lukas, which repository ? thanks alain > Lukas > > On Sat, Jun 6, 2009 at 10:51 PM, Alain Plantec<alain.plantec(a)free.fr> wrote: > >> in pharoInbox: SLICE-TabbedPaletteRemoval-alain_plantec.4 >> >> alain >> >> StÃ©phane Ducasse a Ã©crit : >> >>> On Jun 5, 2009, at 10:17 PM, Alain Plantec wrote: >>> >>> >>>> Hi all, >>>> I know it is used by the Smacc GUI. >>>> I can provide a new Smacc GUI implementation (old one is really messy) >>>> any other good reason to keep TabbedPalette ? >>>> >>> no >>> Lukas already proposed a new UI for Smacc I believe. >>> >>> Stef >>> >>>> 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

Re: [Pharo-project] can we remove TabbedPalette

by Lukas Renggli

I recently fixed the SmaCC GUI to work in Pharo. I replaced the old tabs with morphs from Polymorph, but the GUI is a mess indeed. Feel free to commit your changes to the repository. Lukas On Sat, Jun 6, 2009 at 10:51 PM, Alain Plantec<alain.plantec(a)free.fr> wrote: > in pharoInbox: SLICE-TabbedPaletteRemoval-alain_plantec.4 > > alain > > StÃ©phane Ducasse a Ã©crit : >> >> On Jun 5, 2009, at 10:17 PM, Alain Plantec wrote: >> >>> Hi all, >>> I know it is used Â by the Smacc GUI. >>> I can provide a new Smacc GUI implementation (old one is really messy) >>> any other good reason to keep TabbedPalette ? >> >> no >> Lukas already proposed a new UI for Smacc I believe. >> >> Stef >>> >>> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

June 6, 2009

Re: [Pharo-project] can we remove TabbedPalette

by Alain Plantec

in pharoInbox: SLICE-TabbedPaletteRemoval-alain_plantec.4 alain StÃ©phane Ducasse a Ã©crit : > > On Jun 5, 2009, at 10:17 PM, Alain Plantec wrote: > >> Hi all, >> I know it is used by the Smacc GUI. >> I can provide a new Smacc GUI implementation (old one is really messy) >> any other good reason to keep TabbedPalette ? > > no > Lukas already proposed a new UI for Smacc I believe. > > Stef >> >> thanks >> Alain >> >> _______________________________________________ >> 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] Logging package does not compile

by StÃ©phane Ducasse

On Jun 6, 2009, at 7:37 PM, FranÃ§ois Tanguy wrote: > 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" ? If you need it please ask him or even propose a fix. Keith is asking for participation so I do not see why he would be against that. Stef > > > FranÃ§ois > _______________________________________________ > 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