- Pharo-dev - lists.pharo.org

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

by Damien Cassou

On Wed, Apr 1, 2009 at 11:27 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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. done -- Damien Cassou http://damiencassou.seasidehosting.st

April 2, 2009

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

by Damien Cassou

Ok, I've updated the page On Wed, Apr 1, 2009 at 2:48 PM, Torsten Bergmann <astares(a)gmx.de> 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? > > 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 > -- Damien Cassou http://damiencassou.seasidehosting.st

April 2, 2009

Re: [Pharo-project] old debugger and Cloasure vm on unix

by Dale Henrichs

----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | I'm trying to reproduce the problem that Michael Roberts reported. But | I'm running into a couple of problems. | | I'm running on a linux system, so I grabbed exupery-vm-0.15-linux.tz | from the downloads page on google. I'm using the prebuilt squeak vm in | this download. | | I grabbed pharo0.1-10259dev09.03.3 and then loaded ClosureTests.st | from Lukas. | | When I run the ClosureTests I get: | | 16 run, 8 passes, 0 expected failures, 8 failures, 0 errors, 0 | unexpected passes | | Obviously, I'm missing a crucial part of the formula. | | BlockClosureTests.st also mostly fails.... | | Are closures expected to work in the linux vm? Is there a different vm | I should be using? | | Thanks for the help, | | Dale What a coincidence, I was poking around in the same area and have found that you need to use 10259-ClosureBeta1 you'll get what appears to be the right image ... at least only 2 of the tests fail... Hope this helps, Dale ... {:-|>

April 2, 2009

[Pharo-project] old debugger and Cloasure vm on unix

by Dale Henrichs

I'm trying to reproduce the problem that Michael Roberts reported. But I'm running into a couple of problems. I'm running on a linux system, so I grabbed exupery-vm-0.15-linux.tz from the downloads page on google. I'm using the prebuilt squeak vm in this download. I grabbed pharo0.1-10259dev09.03.3 and then loaded ClosureTests.st from Lukas. When I run the ClosureTests I get: 16 run, 8 passes, 0 expected failures, 8 failures, 0 errors, 0 unexpected passes Obviously, I'm missing a crucial part of the formula. BlockClosureTests.st also mostly fails.... Are closures expected to work in the linux vm? Is there a different vm I should be using? Thanks for the help, Dale

April 2, 2009

[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