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

Re: [Pharo-project] cog-based image crashes on mac

by Henrik Johansen

On Aug 1, 2010, at 10:40 53AM, Lukas Renggli wrote: > The changes I submitted are the ones of Eliot adapted to work in > Pharo. I don't understand what Henrik writes, if he has something > better he should attach the change. > > Lukas Not better, just simpler code. If I'm not mistaken, if primitive 38 fails in Cog, so will primitive 60. Primitive 38 will always fail in a non-cog vm. The failure handling code after the ec == nil check is the same in Float>>basicAt: and Object basicAt: Thus, writing Float>>basicAt: index <primitive:38> ^super basicAt: index would yield the exact same result, with the difference that you will have an extra primtive 60 failure in Cog vm's, an ec = nil check less in non-cog VM's, and no duplication of the fallback-handling code. The alternate code was attached, in issue 2581. Cheers, Henry > > On Sunday, August 1, 2010, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> lukas >> >> could you have a look at >> http://code.google.com/p/pharo/issues/detail?id=2579 >> because henrik mentioned that we missed something or could do it better. >> >> Stef >> >> >> On Jul 26, 2010, at 1:32 PM, Lukas Renggli wrote: >> >>>>>> The image I got is based on the sources from 27.06.2010. >>>>> >>>>> You may be missing some image-side changes. The CogVM was open sourced on >>>>> 20.06.2010. >>>> >>>> Actually, where should I get the complete image-side changes from? I have >>>> those prepared by Lukas a while ago. >>> >>> Yeah, these are the complete ones from the repository adapted to Pharo. >>> >>> Maybe these same socket related crashes that randomly appear with >>> Seaside images? >>> >>> nanosleep: Invalid argument >>> Exited with exit code: 1 >>> >>> 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 >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > 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. 2, 2010

[Pharo-project] Unloading oCompletion to use eCompletion

by Tim Mackinnon

Hi Guys - I tried using Lucas' hudson build of the seaside image which has eCompletion enabled in it by default - and I have to say I found it much snappier and it just seems to work better somehow (take this with a pinch of salt - as a Dolphin user I find so many things strange in Pharo - but I keep plugging away trying to convert myself to a place where I feel comfortable). However I do like the MercuryPanel in the standard Pharo/Seaside image - and as I don't know/understand what gets loaded into each image, I thought I would try just unloading oCompletion and loading in eCompletion in the standar seaside 3.0RC image instead. Anyway - I get an error when I do this (things are registered to receive events, and then when they start to unload things aren't there to receive the events and so you get a walkback). I logged a bug report for this - but did eventually manage to unload oCompletion manually. However when I then loaded eCompletion it seemed that certain classes weren't being picked up, so I had to resave a few methods in the debugger to get it going (is there a way to just refresh an image to make sure all classes are up to date?). Is there an easier way to load/unload oCompletion and eCompletion? Tim

Aug. 1, 2010

[Pharo-project] CampSmalltalk London tutorial

by Nick Ager

Hi Though it's been a couple of weeks since CampSmalltalk London, I've only just got round to creating a ConfigurationOfCampSmalltalkLondon which can be used to download the beginners tutorial Tim Mackinnon and I created. First some context. The beginners tutorial ran on the first day. We had 9 developers with a mixed background in Ruby/Java/C#/PHP etc. We started by going through the excellent ProfStef tutorial which we used as jump off point for frequent asides into the tools and code in Pharo. Next we gave them a simple exercise. You can download the code by grabbing ConfigurationOfCampSmalltalkLondon from http://www.squeaksource.com/MetacelloRepository.html and executing: (ConfigurationOfCampSmalltalkLondon project version: '1.0') load. The aim was to put into practice some of the concepts they'd learnt in the ProfStef tutorial - initially focusing on loops. The tutorial grabs live traffic information from the SE of the UK. Initially there is only one entry in the list viewable from their image at: http://localhost:8080/camp-smalltalk-london The first task was to change the code in CSLTransportInfo>>renderPage: to loop over the results and pass them to a custom renderer. Note we wanted to pass-on the joy of developing a web app in Smalltalk - the liveliness of the environment, code editing in the debugger etc - without first having to learn Seaside. So we hid the Seaside code behind some custom renderers. The second task was the change the renderer in CSLTransportInfo>>modelRenderer to be a CSLListItemRenderer. The task here was to notice the signature of the addItem method had changed and use the inspector and the browser to discover the relevant accessors on the result items. Finally they changed the renderer again for a CSLMapRenderer and went through a similar routine to step two, though this time the result of their labours was to transform a boring list into an impressive map - graphically showing traffic incidents. Those who were more advanced could then filter the results to look at say only incidents along particular roads etc. The tutorial session seemed to be well received. I don't know if anyone out there is planning to run an introduction to Smalltalk - if so they are more than welcome to use the code. All feedback gratefully received. Nick

Aug. 1, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Philippe Marschall

On 01.08.2010 21:07, Andrey Larionov wrote: > Pharo1.1 dosn't contain this methods Yes, that's why the tests failed. Cheers Philippe

Aug. 1, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by laurent laffont

Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Thu, Jul 29, 2010 at 10:24 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > Maybe it's just me, or could we not add Announcement to the end of every > Announcement subclass name though? > > Like with the window announcement, I like them better as verbs describing > the event, f.ex. > > someAnnouncer on: TestStarted do: [] > > someAnnouncer on: TestEnded send: #x to: y > > Someone else vote for this? > I'm experimenting with Announcers on TestResult. What do you think about this syntax ? TestResult when: TestCaseStarts do: [:event | do some stuff ]. TestResult when: TestCaseEnds do: [:event | do some stuff ]. Laurent > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 1, 2010

Re: [Pharo-project] About overlapping packages :(

by Tudor Girba

Hi Stef, I would go for first mirroring categories. Like this, Monticello would still work as expected, and we can just focus on improving the image based tools/concepts. Cheers, Doru On 1 Aug 2010, at 22:02, StÃ©phane Ducasse wrote: > > >> Stef, >> >> Are you perhaps running into problems with mapping category names >> to packages? The Dolphin approach to that is to avoid the topic: >> just present a list of packages and make the user pick one, after >> which the class/method/etc. is packaged. The resulting package >> system might then suffer the indignity of cyclic prerequisites, but >> there are ways to help the user fix that. I am not saying it is >> the correct solution (nor suggesting that it is not) - just >> reporting what Object Arts did. They got so many things *really* >> right that I default to trusting them. > > This is what my implementation does. No magic matching. Just a list > of classes and methods. > Now if I do not support the * convention of packageinfo it means > that we will not be able to load and save > packages in a compatible form. We could do that and it would save me > a lot of work. But people have to agree and understand the > consequences. Of course we could do a MCPackageInfor specific loader > that loads and convert MC packages. > But this means that the packages will not be able to be used in > Squeak. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

Aug. 1, 2010

[Pharo-project] [update 1.2] #12073

by StÃ©phane Ducasse

12073 ----- - Issue 1289: Changing locale raises DNU - test categories cleaning. Thanks alexandre. - Issue 2205: pluggable Tree Morph deselect behavior. Tx Laurent.

Aug. 1, 2010

Re: [Pharo-project] About overlapping packages :(

by StÃ©phane Ducasse

> Stef, > > Are you perhaps running into problems with mapping category names to packages? The Dolphin approach to that is to avoid the topic: just present a list of packages and make the user pick one, after which the class/method/etc. is packaged. The resulting package system might then suffer the indignity of cyclic prerequisites, but there are ways to help the user fix that. I am not saying it is the correct solution (nor suggesting that it is not) - just reporting what Object Arts did. They got so many things *really* right that I default to trusting them. This is what my implementation does. No magic matching. Just a list of classes and methods. Now if I do not support the * convention of packageinfo it means that we will not be able to load and save packages in a compatible form. We could do that and it would save me a lot of work. But people have to agree and understand the consequences. Of course we could do a MCPackageInfor specific loader that loads and convert MC packages. But this means that the packages will not be able to be used in Squeak. Stef

Aug. 1, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Andrey Larionov

Pharo1.1 dosn't contain this methods On Sun, Aug 1, 2010 at 21:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Cool! > Thanks. > I think that this is important to get good infrastructure. > > On Aug 1, 2010, at 3:43 PM, Philippe Marschall wrote: > >> On 01.08.2010 09:39, StÃ©phane Ducasse wrote: >>> andrey >>> >>> do you know if they tests are failing also in squeak? >>> Else what are the problems? >> >> #squeakToUtf8, #utf8ToSqueak concatenating Strings and Integers. >> I sent a patch to Andreas, got WebSockets running in Seaside now :-) >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> 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. 1, 2010

Re: [Pharo-project] String, ByteString and WideString

by Andrey Larionov

maybe, but i'm thinking what (WideString basicNew: size) writeStrem contents should return WideString, not the ByteString On Sun, Aug 1, 2010 at 17:48, Philippe Marschall <kustos(a)gmx.net> wrote: > On 01.08.2010 01:56, Andrey Larionov wrote: >> Working with WebClient i found what it lacks of non latin languages >> support (for example Russian). During investigation i found, what for >> streaming there used ByteString, which is custructed by calling String >> class>>new:. All subclases of String by calling of this method >> produces only ByteString instances. Also WriteStream>>contents >> indirectly calls String class>>new:. So even you construct WideString >> with #basicNew: calling >> (WideString basicNew: size) writeStrem contents >> produce only ByteString > > You probably want one of the MultiByteStreams and then set either the > encoding or the converter. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 1, 2010