August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Probably a bug

by Alexandre Bergel

+1 On 19 Aug 2010, at 18:03, StÃ©phane Ducasse wrote: > I checked a bit the senders of asString and the problem is that they often confused printString and asString. > > Like kent beck I do not like conversion methods between object that do not have the same API > ie aBag asSet is ok but aString asUrl is not good for me. > > I understand aText asString > but not really aColor asString, I would prefer a Color printString especially since asString seems inherited from > Object and calling printString. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 19, 2010

Re: [Pharo-project] Probably a bug

by StÃ©phane Ducasse

I checked a bit the senders of asString and the problem is that they often confused printString and asString. Like kent beck I do not like conversion methods between object that do not have the same API ie aBag asSet is ok but aString asUrl is not good for me. I understand aText asString but not really aColor asString, I would prefer a Color printString especially since asString seems inherited from Object and calling printString. Stef

Aug. 19, 2010

Re: [Pharo-project] cogVM in pharo {WAS} Re: [squeak-dev] Re: HTML parser (again)

by StÃ©phane Ducasse

I do not know. Plugin? Then there are compiler changes (may be this is for the closure). Stef On Aug 19, 2010, at 10:49 PM, Mariano Martinez Peck wrote: > > > On Wed, Aug 18, 2010 at 11:05 PM, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: > no CogVM is not ready for us. > > > why not? It tohught it was everything working but objects as methods.... > > is there something else? > > > > > > Is there a one-click image for CogVM somewhere so I can download it? > > > > > > On Wed, Aug 18, 2010 at 2:34 AM, laurent laffont > > <laurent.laffont(a)gmail.com> wrote: > >> > >> > >> On Wed, Aug 18, 2010 at 7:50 AM, Andrei Stebakov <lispercat(a)gmail.com> > >> wrote: > >>> > >>> I've been looking for a nice and fast HTML parser. > >>> I've found Zulq Alam's Soup > >>> (http://www.squeaksource.com/@vHckXt8_6gVtXFxy/XMrjDbIs) it looks nice > >>> but it's way too slow for me (takes 5 sec to parse the page, my > >>> current lisp parser takes about 1 sec for that.) > >>> I found another one, Todd Blanchard's HTML and CSS parser > >>> (http://www.squeaksource.com/@iMgHmTKVxU00wEdz/A0jkqk71) but I > >>> couldn't load it into Pharo 1.1 or Squeak 4.1. > >>> It complains about some syntax error and leaves the progress bar which > >>> I can't kill... > >>> I wonder if anyone (Todd?) can take a look at the parser and figure > >>> out how to fix it? > >>> > >>> What other options I have for an HTML parser? > >>> Looking at Pharo speed I wonder if there is any way to optimize it? Is > >>> JIT or some other speed optimization in plans for Pharo/Squeak? > >> > >> > >> What do you need to do ? > >> There's XMLSupport http://www.squeaksource.com/XMLSupport.html > >> Scamper might have a standalone HTML > >> parser http://www.squeaksource.com/Scamper.html > >> The CogVM has JIT. > >> Laurent. > >> > >>> > >>> Thank you, > >>> Andrei > >>> > >>> _______________________________________________ > >>> 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

Aug. 19, 2010

Re: [Pharo-project] Probably a bug

by Eliot Miranda

2010/8/19 GÃ¶ran Krampe <goran(a)krampe.se> > On 08/19/2010 09:53 PM, StÃ©phane Ducasse wrote: > >> What would you say the right thing is? >>>>> >>>> >>>> Well, intuitively I would say that converting an Array of Character >>>> instances (say 5 instances) using "asString" would give me a String of size >>>> 5. Also, "Character space asString" does NOT give me 'Character space' but >>>> actually ' '. >>>> >>> Maybe its just me, but I'd rather not have >>> SequenceableCollection>> asString mean "If I contain only elements which >>> may represent characters, return a string containing those, if not, return >>> my printString" >>> >> >> >> yes you are not the only one. Thanks I was thinking about that after my >> post :) >> >> Having a fallback on printString is of course fine, in Object. But... >>>> well, I haven't thought *deeply* on this, but a sequencable collection of >>>> Characters should IMHO be able to produce a String >>>> regards, GÃ¶ran >>>> >>> >>> And it is, using either >>> collection as: String, or >>> String withAll: collection >>> In both cases you then explicitly specify that this collection will >>> contain only elements which can be converted to a string, rather than have a >>> later reader of the code have to question "hmmm, does the use of asString >>> here mean he'll be using the collections printString, or the string with its >>> elements?" >>> >> >> I'm curious about the senders of asString, especially to collection. >> >> Stef >> > > I am all in agreement I think, my gut reaction was that, darn, something is > broken. But perhaps sending asString to a Collection of objects should... > well, what *should* it return? > > I think possibly one of the problems in all this is the fallback on > printString - that has clearly muddled the waters IMHO. #printString is for > the tools, it should give a "readable representation". But #asString is a > conversion method - it should give me IMHO the most reasonable conversion > for further "use". > > I agree that #as: etc might be a "better" protocol, but let's say we still > want #asString to work for Collections and NOT fall back on #printString - > then what should it do? > If aCollection asArray = (aCollection as: Array) then surely aCollection asString = (aCollection as: String) If ([aCollection as: String. nil] on: Error do: [:ex| ex]) notNil then surely ([aCollection as: String. nil] on: Error do: [:ex| ex messageText]) = ([aCollection asString. nil] on: Error do: [:ex| ex messageText]) i.e. if aCollection doesn't include characters both forms should return errors. I find the Object implementation of asString distasteful, but that's juts my taste. However, I find Collection's inheriting of that definition badly broken. my 2Â¢ best Eliot > regards, GÃ¶ran > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 19, 2010

Re: [Pharo-project] organization

by StÃ©phane Ducasse

> Stef, > > As part of his GSoC 2010 project, GermÃ¡n Leiva has been doing some refactoring of this and has some sample code at http://www.squeaksource.com/Environments.html. While it hasn't come as far as I hoped, it does give an interesting insight into some of the relationships between environment, organization, and related things (the Monticello implications were somewhat nontrivial). Although the GSoC is officially over, I expect to be working on this going forward and would like to have a significant discussion with interested parties at ESUG next month. How quickly do you want to solve this? ;-) Ok we will discuss. Stef > > James > > On Aug 19, 2010, at 1:29 PM, stephane ducasse wrote: > >> so far we have >> >> SystemDictionary>>organization >> "Return the organizer for the receiver" >> ^SystemOrganization >> >> so it means that this is global in Smalltalk globals. >> But I'm skeptical that this can work for another instance of SystemDictionary >> and even if this works I find this code brittle since it relies on the compiler global look up. >> >> I was thinking that >> >> either defining an organization as an instance variable SystemDictionary would make sense or >> using an explicit lookup in the instance itself. >> >> SystemDictionary>>organization >> "Return the organizer for the receiver" >> ^ self at: #SystemOrganization >> >> now I'm dead so I need other eyes. >> >> Stef >> >> _______________________________________________ >> 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

Aug. 19, 2010

Re: [Pharo-project] organization

by Carla F. Griggio

IIRC GermÃ¡n told me that the extensions of the package in the repository should be refactors to make in Pharo, and there are things there related to enviroments and system organization. On Thu, Aug 19, 2010 at 5:49 PM, James Foster <Smalltalk(a)jgfoster.net>wrote: > Stef, > > As part of his GSoC 2010 project, GermÃ¡n Leiva has been doing some > refactoring of this and has some sample code at > http://www.squeaksource.com/Environments.html. While it hasn't come as far > as I hoped, it does give an interesting insight into some of the > relationships between environment, organization, and related things (the > Monticello implications were somewhat nontrivial). Although the GSoC is > officially over, I expect to be working on this going forward and would like > to have a significant discussion with interested parties at ESUG next month. > How quickly do you want to solve this? ;-) > > James > > On Aug 19, 2010, at 1:29 PM, stephane ducasse wrote: > > > so far we have > > > > SystemDictionary>>organization > > "Return the organizer for the receiver" > > ^SystemOrganization > > > > so it means that this is global in Smalltalk globals. > > But I'm skeptical that this can work for another instance of > SystemDictionary > > and even if this works I find this code brittle since it relies on the > compiler global look up. > > > > I was thinking that > > > > either defining an organization as an instance variable > SystemDictionary would make sense or > > using an explicit lookup in the instance itself. > > > > SystemDictionary>>organization > > "Return the organizer for the receiver" > > ^ self at: #SystemOrganization > > > > now I'm dead so I need other eyes. > > > > Stef > > > > _______________________________________________ > > 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 >

Aug. 19, 2010

[Pharo-project] About changes logging

by StÃ©phane Ducasse

Hi I noticed that if I define a method it shows up in the recentMessageSet Now if I load code with mc it does not, even though it is logged in the changes (the logging in the changes is done by SmalltalkImage>>event:) which could indicate that SystemChangeNotifier notified the right tools. Does anybody have an idea? Because this is confusing. Stef

Aug. 19, 2010

Re: [Pharo-project] Probably a bug

by GÃ¶ran Krampe

On 08/19/2010 09:53 PM, StÃ©phane Ducasse wrote: >>>> What would you say the right thing is? >>> >>> Well, intuitively I would say that converting an Array of Character instances (say 5 instances) using "asString" would give me a String of size 5. Also, "Character space asString" does NOT give me 'Character space' but actually ' '. >> Maybe its just me, but I'd rather not have >> SequenceableCollection>> asString mean "If I contain only elements which may represent characters, return a string containing those, if not, return my printString" > > > yes you are not the only one. Thanks I was thinking about that after my post :) > >>> Having a fallback on printString is of course fine, in Object. But... well, I haven't thought *deeply* on this, but a sequencable collection of Characters should IMHO be able to produce a String >>> regards, GÃ¶ran >> >> And it is, using either >> collection as: String, or >> String withAll: collection >> In both cases you then explicitly specify that this collection will contain only elements which can be converted to a string, rather than have a later reader of the code have to question "hmmm, does the use of asString here mean he'll be using the collections printString, or the string with its elements?" > > I'm curious about the senders of asString, especially to collection. > > Stef I am all in agreement I think, my gut reaction was that, darn, something is broken. But perhaps sending asString to a Collection of objects should... well, what *should* it return? I think possibly one of the problems in all this is the fallback on printString - that has clearly muddled the waters IMHO. #printString is for the tools, it should give a "readable representation". But #asString is a conversion method - it should give me IMHO the most reasonable conversion for further "use". I agree that #as: etc might be a "better" protocol, but let's say we still want #asString to work for Collections and NOT fall back on #printString - then what should it do? regards, GÃ¶ran

Aug. 19, 2010

[Pharo-project] [update 1.2] #12100

by StÃ©phane Ducasse

12100 ----- - Enter back to accept TextEntryDialogWindow. Thanks Gary Chambers. - Issue 2833: Pharo 1.1 final has two senders of #haltOnce - fixes some Smalltalk -> Smalltalk globals

Aug. 19, 2010

Re: [Pharo-project] Can't file in *.st exports

by Henrik Johansen

No, PharoSound on squeaksource, I also merged some fixes from squeak trunk a few weeks ago. Den 19. aug. 2010 kl. 22:13 skrev StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Thanks henrik, you uploaded the code in the pharoNonCore repo? > > Stef > > On Aug 19, 2010, at 8:20 PM, Henrik Johansen wrote: > >> There are three senders of #clone in the 1.1 One-click image, all part of the sound package. >> (I've uploaded a new version to PharoSound where this is fixed, and #copy occurences replaced with #postCopy implementations instead). >> >> ArrayedCollection>>mergeSortFrom:to:by uses shallowCopy. >> I'd check what code you've imported which has changed that. >> >> Cheers, >> Henry >> >> >> On Aug 19, 2010, at 6:49 43PM, Peter Hugosson-Miller wrote: >> >>> Better :-) The attached image is of a stack trace that shows where the error occurs, which is certainly helpful! >>> >>> During the execution of ArrayedCollection>>#mergeSortFrom:to:by:, the message #clone is sent to an instance of Array, and the message is not understood, which means that there is no method called #clone in the Array class or any of its superclasses. >>> >>> So the question is, why is the message being sent, when no corresponding method exists on the receiver? One possibility is that there is an error in the method where the #clone message is being sent, or that the missing method just hasn't been filed in yet. The next step would probably be to look at the file being filed in, and see what methods it contains. Perhaps it depends on another file that needs to be filed in first? >>> >>> -- >>> Cheers, >>> Peter >>> >>> 2010/8/19 Robert Sirois <watchlala(a)hotmail.com> >>> No problem, Pharo's driving me crazy today hehe. >>> >>> It says: "*** system error handling failed ***" (see attached image). >>> >>> Thanks, >>> RS >>> >>>> From: oldmanlink(a)gmail.com >>>> Date: Thu, 19 Aug 2010 17:33:03 +0200 >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] Can't file in *.st exports >>> >>>> >>>> Pardon me for being blunt, Robert, but we're going to need a bit more to go on than "some sort of weird system error". >>>> >>>> Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) >>>> >>>> -- >>>> Cheers, >>>> Peter. >>>> >>>> On 19 aug 2010, at 17:11, Robert Sirois <watchlala(a)hotmail.com> wrote: >>>> >>>>> There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to "CR" for a debugger or any key to restart. I ended up having to force quit. >>>>> >>>>> This is in the latest 1.1 one-click. >>>>> >>>>> Thanks, >>>>> RS >>>>> _______________________________________________ >>>>> 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

Aug. 19, 2010