- Pharo-dev - lists.pharo.org

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Levente Uzonyi

On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > We do not want a process/system where one single person controls something important. > > - first it does not scale. > - second it is not good for the ecosystem feeling. > - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because > we could not touched graphics and we needed to integrate other fixes) and we do not want that again. > - fourth we are reading to share and we know how to do it but not at any price. It's a bit funny to read that from a "benevolent dictator". Levente > > Now I have to work. :) > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

Re: [Pharo-project] Magnitude should be reimplemented as a Trait

by StÃ©phane Ducasse

On Aug 30, 2010, at 1:25 PM, jaayer wrote: > > > ---- On Mon, 30 Aug 2010 03:32:18 -0700 StÃ©phane Ducasse wrote ---- > >> +1 >> So this is ok :) >> What I would love in my wildest dream is to have magnitude using TComparable :) >> But this may be too complex. >> I would like to have the time to check how we can make trait implementation leaner, smaller..... >> >> Stef > > Actually, if you change Magnitude's class definition to this: > > Object subclass: #Magnitude > uses: TComparable > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Kernel-Numbers' > > and then manually remove its "comparing" and "testing" messages, everything seems to work. (Same number of passed/failed tests in "KernelTests-Numbers" as before ) But I could see this potentially causing build issues. Excellent!!!!! I would not have dare doing it. We are trying to get the system bootstrap and bumping in a lot of issues and shaking the system. So I was implying more that. I'm also thorn apart about the pluggability of traits - my meta sin. :) http://code.google.com/p/pharo/issues/detail?id=2884 > Also, Magnitude's "testing" messages, despite what their category name implies, do not return booleans; instead they return other Magnitudes. I have recategorized those messages (#min:, #max:, and #min:max:) in TComparable under "comparing" in the attached fileout.<TComparable2.st>_______________________________________________ Indeed http://code.google.com/p/pharo/issues/detail?id=2882 > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Levente Uzonyi

On Mon, 30 Aug 2010, Henrik Johansen wrote: > > On Aug 30, 2010, at 1:06 10PM, Levente Uzonyi wrote: > >> On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: >> >>>>> >>>>> I suggest that the people that want and know, group together and build an open-source one. >>>> >>>> Why do you have to have your "own" library? >>> >>> Did I say "pharo library"? reread carefully I said an "open-source one". >> >> What I get from Andreas' words is that he's willing to make it open source if it won't be forked. > > So, definitely not MIT then. Why? > I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well? I don't think so. Squeak releases won't come with WebClient loaded, Andreas mentioned it in his mail. > >> >>> We do not want to be in the situation that somebody can change the license under our feet. >>> We want a library where people can participate. Now Pharoers will decide, I think that we do not have problem >>> with sharing on WebClient. I can understand that people do not like that they cannot improve an infrastructure >>> that they will rely upon. We do not want string to number conversion, and rely on squeakToUtf. >> >> I think Andreas solved these issues with the WebClient-Pharo package, but I may be wrong. > > If you call overriding String #, (to accept any object responding to asString without raising errors) and Collection #ifEmpty: (to return nil instead of the collection ifNotEmpty) "solving the issues" in Pharo, then yeah, sure. I don't like the "magical" #asString, but you should discuss it with Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in the WebClient-Pharo package (and in Squeak), and I think it's better than nil. > If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes. In Squeak these methods avoid the creation of the TextConverter object if the receiver is a ByteString, which is usually the case. Levente > > Personally, I'd call it forcing Squeakisms on anyone wanting to use WebClient, and potentially breaking any number of other packages. > > The rest I have no problems with, most are fixes/convenience methods which are already in, or should be introduced before Pharo 1.2 (for exampe the SocketStream fixes ) > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

[Pharo-project] Information about ESUG 2010 conference

by Noury Bouraqadi

Dear Smalltalkers, I'd like to remind you that all information about the ESUG conference is on-line as usual http://www.esug.org/Conferences/2010 you'll there many info including (but not limited to:) -The conference schedule: http://www.esug.org/wiki/pier/Conferences/2010/SchedulePDF?view=PRDownloadV… -Venue : http://www.esug.org/wiki/pier/Conferences/2010/Venue -A list of Hotels: http://www.esug.org/wiki/pier/Conferences/2010/Accomodation Last, a statistic: So far we have 133 registered people! Definitely the ESUG conference is the place to be to meet the community. For any question, please feel free to contact the esug board (board(a)esug.org) See you in Barcelona, Noury Esug treasurer

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by StÃ©phane Ducasse

We do not want a process/system where one single person controls something important. - first it does not scale. - second it is not good for the ecosystem feeling. - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because we could not touched graphics and we needed to integrate other fixes) and we do not want that again. - fourth we are reading to share and we know how to do it but not at any price. Now I have to work. :) Stef

Aug. 30, 2010

Re: [Pharo-project] OBMorphicIcons (was Re: this style looks cool)

by Alexandre Bergel

> > This looks useful; how do you turn an image into a method, though? Hi! Have a look at the class side of MenuIcons. There are a bunch of import/export methods. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Levente Uzonyi

On Mon, 30 Aug 2010, Lukas Renggli wrote: >>> We want a library where people can participate. Now Pharoers will decide, >>> I think that we do not have problem >>> with sharing on WebClient. I can understand that people do not like that >>> they cannot improve an infrastructure >>> that they will rely upon. We do not want string to number conversion, and >>> rely on squeakToUtf. >> >> I think Andreas solved these issues with the WebClient-Pharo package, but I >> may be wrong. > > What WebClient-Pharo does is to patch (and break) Pharo in the most > absurd ways to make it ill-behaved like Squeak. For example, check out > the implementation of String>>#,. I don't like "magical typecasts", but you (the community) should discuss it with the author (Andreas) before forking the package. > > Philippe (an expert in writing platform independent code) and Sven > have fixed all these issues so that the code works flawlessly on both > platforms, Squeak and Pharo. Cool. Levente > >> Well, we are about to use it for Seaside. It scales a lot better than Kom. >> Cog can't really speed up Kom (based on our benchmarks done with JMeter)*, >> probably because of the heavy use of notifications (DynamicBindings), but it >> can boost WebClient significantly. > > Kom is not ideal, we all know that (thanks for sharing the > benchmarks). However, the current licensing situation of WebClient > makes it totally useless for me and presumably many other people. > Luckily there are many other options. > > Lukas > > -- > Lukas Renggli > 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 >

Aug. 30, 2010

Re: [Pharo-project] this style looks cool

by Mariano Martinez Peck

On Mon, Aug 30, 2010 at 11:13 AM, ja(a)anymorphic.com <ja(a)anymorphic.com>wrote: > > StÃ©phane Ducasse <stephane.ducasse@...> writes: > > did you sign the license agreement? > > For the License, I send a fax to you, now. > I pushed the changes used and created by Anymorphic into Pharo-Inbox > under the Name "Polymorph-Themes-Pro". > > this is awesome!!! I have just tested in Pharo 1.1 and it is really really cool. I love it. I will use it for all my images :) Hope it is integrated in Pharo. If people don't agree, not as default, but at least include it so that those who want can set it and use it. Thanks a lot mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

[Pharo-project] OBMorphicIcons (was Re: this style looks cool)

by Rob Rothwell

> Message: 4 > Date: Mon, 30 Aug 2010 03:41:45 +0200 > From: Tudor Girba <tudor.girba(a)gmail.com> > Subject: Re: [Pharo-project] this style looks cool > To: Pharo-project(a)lists.gforge.inria.fr > Message-ID: <6950297A-3FF9-46B5-9AC5-CAA382233986(a)gmail.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Hi Bill, > > As I said, all you have to do is to override #browserIcon on the class > side of your class to return a symbol that corresponds to a method in > OBMorphicIcons. Please look at the implementors of #browserIcon. > > For example: > > Announcement class>>browserIcon > ^ #announcement > > OBMorphicIcons>>announcement > ^ ((ColorForm > extent: 12@12 > depth: 8 > fromArray: ... > > > Cheers, > Doru > This looks useful; how do you turn an image into a method, though? Thank you, Rob

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by StÃ©phane Ducasse

> > Personally, I'd call it forcing Squeakisms on anyone wanting to use WebClient, and potentially breaking any number of other packages. > > The rest I have no problems with, most are fixes/convenience methods which are already in, or should be introduced before Pharo 1.2 (for exampe the SocketStream fixes ) I think that we integrated all the socketStreams fixes last week or so. Stef

Aug. 30, 2010