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

[Pharo-project] Plugins overview

by Torsten Bergmann

So more plugins identified include: Rome, DBus, GStreamer, Ogg, Kedama, DShowVideoDecoderPlugin, Windows File dialog plugin, Spoons flow plugin Bye Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

April 1, 2009

[Pharo-project] [ANN] VM for closures on pharo web site

by Torsten Bergmann

Damien wrote: >I really don't care :-). I did that because I didn't know the linked >VM had closure support. Bryce wrote: >You're probably better off using Andreas's VM than mine for general use. Hi Damien, so would you please link to http://squeakvm.org/win32/release/SqueakVM-Win32-3.11.2-bin.zip as the newest official Win32 VM and keep the link to Exupery as an optional alternative. Thanks in advance! Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

April 1, 2009

[Pharo-project] Schedule

by Torsten Bergmann

Yes - Pharo is late. But I think it's worth to wait until Unicode and Closures are completely integrated and bugs have settled down. But someone should adjust the schedule: http://pharo-project.org/home Thanks Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

April 1, 2009

Re: [Pharo-project] SUnit History

by Alexandre Bergel

yes, I will fix this Alexandre On 1 Apr 2009, at 19:39, StÃ©phane Ducasse wrote: > so will you fix it? Alex? > > > Stef > >> Hi Lukas, >> >> Thanks for your review. We made this in a couple of days. >> You suggested some cool changes, indeed. >> >> Cheers, >> Alexandre >> >> >> On 1 Apr 2009, at 12:07, Lukas Renggli wrote: >> >>> I have a few questions to the authors of the SUnit History feature: >>> >>> 1. I noticed is that all the results are stored in a dictionary of >>> TestResult mapping the classes to their last result. When I delete >>> tests, these obsolete classes remain references from the dictionary >>> and thus never get garbage collected. Why not save the history in a >>> class-instance variable of the TestCase itself? That would even make >>> the code much simpler. >>> >>> 2. Why to store the history of test results in nested dictionaries, >>> sets and arrays? We have a nice TestResult object that remembers >>> exactly the same information and additionally allows to do all kinds >>> of queryies like #hasFailures, hasPassed, ... I see that there is >>> one >>> problem here: the current implementation of TestResult remembers the >>> test case instances, and thus would reference potentially a lot of >>> unnecessary state. Maybe TestResult should only remember the method >>> references of the tests, instead of the test cases? I guess that >>> would >>> solve other problems people regularly report with SUnit as well. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://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 >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 >> > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 1, 2009

Re: [Pharo-project] about the closure

by StÃ©phane Ducasse

yeap you re right > I definitely care about the tests all green ;-) I just don't want to > debug into tests when there is no point. I'm not in favour of the > wiki idea either. So I'll have a look at expected failures. sounds > like we need to mark those two of Lukas' if they are not already > > thanks, > > Mike

April 1, 2009

[Pharo-project] About unicodeToMacRoman

by Nicolas Cellier

Hello list, that's just a detail, but I do not much like Character>>unicodeToMacRoman. Why? Because a Character does not explicitely carry encoding information. On the contrary, Character are implicitely considered as unicode encoded in 99% of code. So, pretending a Character can change encoding is just a hack for a small portion of code... ...and IMO a ugly one because a Debugger for example would be fooled and its user too (ego quoque). I bet most usages of this message will be (someCharacter unicodeToMacRoman charCode), so the pretended MacRoman encoded Character does not really need to exist... (Shame on me, I have not downloaded a recent image, I'm just picking changes here and there). If what I say is true, wouldn't a Character>>macRomanCharCode be more clean? Nicolas

April 1, 2009

Re: [Pharo-project] [ANN] VM for closures on pharo web site

by Bryce Kampjes

On Wed, 2009-04-01 at 14:48 +0200, Torsten Bergmann wrote: > Hi Damien, > > >> damien could you edit a page on the wiki with a link to these vms? > > > >http://code.google.com/p/pharo/wiki/Downloads?tm=2 > > > > I dont know why you linked to the Exupery VM for Win32 on this page? > Maybe because Bryce wrote in [1] that his VM has the closure > bytecodes compiled in too. > > But AFAIK closures were also already implemented in the official > standard windows Squeak VM in 3.11.1 (see [2]) and there is now also a > newer windows VM version from Andreas provided last week (see [3]). > > So the new pharo closure image from Marcus [4] should work with > that too and I would rather see the standard Squeak VM linked on the page > if we have full closure support there. But I would mention Exupery Win32 VM > as another option. > > Andreas, Bryce - any comments? You're probably better off using Andreas's VM than mine for general use. I maintain that VM purely to provide a Windows VM with Exupery support and closures support. All my Squeak work is on Linux. I released that VM before Andreas released his closure VM. I'll keep maintaining it because it's needed for Exupery but it's unlikely to receive the same amount of care as Andreas's. The benefits of my VM are it uses the same exact version of VMMaker as my Unix VM and it can run Exupery. Bryce

April 1, 2009

Re: [Pharo-project] [ANN] #10262cl

by Marcus Denker

On 31.03.2009, at 17:17, Adrian Lienhard wrote: > I think we can do it manually, yes. > > But it would be good to have a detailed description of the manual > steps so that we (or someone else) is able to reproduce it at a later > point in time. > Here is everything, description+changesets > Adrian > > On Mar 31, 2009, at 16:52 , Marcus Denker wrote: > >> Hi, >> >> So this is not done as an update... reason: much simpler. >> doing the closure conversation is a bit manual, e.g. closing all >> windows, >> doing some other stuff, then save, restart, cleanup changeset... then >> re-saving all the dirty packages. >> >> I would *a lot* of work to do that with the update-stream. >> >> The question is: can we live without? >> >> We could add a changeset that just pops up a window that says: end- >> of- >> line, please get the hand-build image. >> >> Marcus >> >> >> On 31.03.2009, at 16:15, Marcus Denker wrote: >> >>> Hi, >>> >>> I have merged the closure changed in the 1062 image (manually). >>> >>> We now can continue with this image to provide updates using the >>> update stream: >>> >>> http://gforge.inria.fr/frs/download.php/20098/ >>> Pharo0.1Core-10262cl.zip >>> >>> >>> Changes: >>> -> Closure changes merged. >>> -> BlockClosurePharo.1.cs >>> -> FixDebugger.1.cs >>> -> TraitDescription-closure support.st >>> -> BlockContextTestFix.1.cs >>> -> ArrayLiteralTestFix.1.cs >>> >>> >>> -- >>> Marcus Denker -- denker(a)acm.org >>> http://www.marcusdenker.de >>> >> >> -- >> Marcus Denker -- denker(a)acm.org >> http://www.marcusdenker.de >> >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

April 1, 2009

Re: [Pharo-project] about the closure

by Michael Roberts

I definitely care about the tests all green ;-) I just don't want to debug into tests when there is no point. I'm not in favour of the wiki idea either. So I'll have a look at expected failures. sounds like we need to mark those two of Lukas' if they are not already thanks, Mike On Wed, Apr 1, 2009 at 6:29 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I would like to see the pattern "all tests always green" (except for > expected failures, see below). Maybe this is too rigorous in practice > since not everybody seems to care that much about tests. It would mean > that no new updates are pushed in the stream until all tests that were > broken by the previous update are fixed. Or even better, we would not > integrate any code as long as it breaks a test. > > Anyway, I see the following two possibilities: > - use SUnit's expected failures feature (see implementors of > #expectedFailures) to marke tests we know are broken > - create a wiki page to document currently broken tests > > I would use the former only for tests that document a bug that we > don't know how to fix within the foreseeable future. The drawback of > the wiki page is that it is prone to get out of date. > > Cheers, > Adrian > > On Apr 1, 2009, at 19:00 , Michael Roberts wrote: > >> It would be good to document this knowledge of what is expected in our >> test suites. Especially if some are known to fail. Is there a pattern >> already in use? >> E.g. Method comment, pragma, wiki page entry? If not what should we >> adopt? >> >> Thanks mike >> >> On 4/1/09, Marcus Denker <denker(a)acm.org> wrote: >>> >>> On 01.04.2009, at 11:31, StÃ©phane Ducasse wrote: >>> >>>> >>>> On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote: >>>> >>>>>> lukas is it normal that we get 3 tests yellow - did you get the >>>>>> same >>>>>> in your image? >>>>> >>>>> #testToDoOutsideTemp and #testWhileModificationBefore are broken. I >>>>> don't think that should stop us from integrating the closures into >>>>> Pharo. Most "industrial strength" Smalltalk implementations have >>>>> many >>>>> more closure bugs than Pharo. >>>> >>>> This is integrated already and this is good to have such great test >>>> suites. >>>> I will integrate them this evening. >>>> >>> >>> Lukas' teste should be already in, I think. >>> >>> Â Â Â Marcus >>> >>> >>> -- >>> Marcus Denker Â -- Â denker(a)acm.org >>> http://www.marcusdenker.de >>> >>> >>> _______________________________________________ >>> 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 >

April 1, 2009

Re: [Pharo-project] [ANN] VM for closures on pharo web site

by StÃ©phane Ducasse

> Thanks for the information. Since I'm only a mac user I was not aware of that So we will link to the others. Stef >>> I dont know why you linked to the Exupery VM for Win32 on this page? > Maybe because Bryce wrote in [1] that his VM has the closure > bytecodes compiled in too. > > But AFAIK closures were also already implemented in the official > standard windows Squeak VM in 3.11.1 (see [2]) and there is now also a > newer windows VM version from Andreas provided last week (see [3]). > > So the new pharo closure image from Marcus [4] should work with > that too and I would rather see the standard Squeak VM linked on the > page > if we have full closure support there. But I would mention Exupery > Win32 VM > as another option. > > Andreas, Bryce - any comments? > > Thanks > Torsten > > BTW: The exupery VM does not respond to ALT+F4 for me... > > > [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/007233.html > [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-March/134710.ht… > [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-March/135189.ht… > [4] http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/007220.html > -- > Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + > Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 1, 2009