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

Re: [Pharo-project] Quasi-stateful traits?

by Igor Stasenko

On 27 February 2010 10:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > orthogonally to traits I sometimes would like python like hash based (but class and not object) semantics > ie > > Object dictionaryVariable: #MyClass > > > Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code > when a method add a property extension to a morph, another tests for its value and the third one remove it. > You get code that is really difficult to understand. >> <key1><value1> >> <key2><value2> > This is an object memmory layout - a pair of two oops(object pointers) one following other - key and value. > > > On Feb 27, 2010, at 12:39 AM, Igor Stasenko wrote: > >> One of the ways of introducing a stateful traits is changing the VM >> object format. >> There is a bits in object's header reserved for identity hash. >> Instead of putting the identify hash value there, we could use it to >> indicate if given object has additional arbitrary slots following the >> object contents: >> >> <header> >> <ivar1> >> ... >> <ivarN> >> <variableVar1> >> ... >> <variableVarM> >> <key1><value1> >> <key2><value2> >> ... >> <keyK><valueK> >> >> so, these keyN->valueN forming a dictionary of key/value pairs, which >> can be accessed using new primitives #slotAt: and #sloatAt:put: >> >> slot allocaiton can be expressed as: >> >> newObject := object copyWithSlot: key value: value. >> object becomeForward: newObject. >> >> (except that this is done by VM primitively). >> >> Once slots is allocated, object size is not grows anymore (so there >> are no overhead) and as bonus, you getting a way to attach any >> additional state to virtually any objects (except smallints) , for any >> purposes. >> Identity hash is become slower, but only at first hashing attempt. >> (slotAt: #identityHash put: value) >> But as benefit, we could use any object (or just 31 bit small integer) >> for hash values, which will increase the hashing quality considerably. >> So, it is a question, what will be faster, especially for large >> dictionaries. >> >> Obviously, then traits free to use this to keep own state, without any >> extra demands from classes where it installed: >> >> foo >> Â ^ self slotAt: #foo >> foo: value >> Â self slotAt: #foo put: value >> >> Also, I think that with such extension, we might expect a considerable >> speed boost for Magma OODB, which can use additional slot for marking >> objects by own ids, as well as for marking object dirty, instead of >> maintaining a huge and ineffective IdentityDictionaries to track the >> objects state. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 27, 2010

Re: [Pharo-project] Scamper revival

by GermÃ¡n Arduino

2010/2/27 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Just checking :) > > In that case however, I would like to see a nice(r) way to construct > Polymorph interfaces. Dolphin's MVP framework is very powerful. One thing > that it does not seem to do well is allow domain objects to insert > themselves into a GUI; Seaside and Magritte have an advantage there. I find > Magritte a little too helpful, and #description *much* too helpful, meaning > that it does so much for me that I forget how things work. > > There is probably nothing to stop us from taking a little more control over > Magritte descriptions and containers, and IIRC, there is a Polymorph version > of Magritte (or is that just wishful thinking??). Rather than write HTML to > feed into what we all agree is a sub-optimal browser, I suggest putting the > energy into refining Smalltalk idioms to turn data into a GUI using > Polymorph. The end result should be better user interfaces all around. > > Bill > > I agree with these comments (don't know if the way to go is Polymorph being that I don't know it deeper) but as I also think that Magritte is a BIG help to write almost any sort of applications. I we could have a better (more productive) way of write desktop UIs then we can take over the win-linux.mac market :) I would try myself with my PasswordsPro application (currently in Dolphin). It would be nice to me port PasswordsPro to Pharo and sell it as a real desktop app (native in any operating system) and reuse the same model to have it on web also. Having a only one model, with UI in desktop and web will be really awesome, even when a lot of people may claim that is possible today, I'm not really convinced with complex applications. Cheers.

Feb. 27, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by StÃ©phane Ducasse

I updated it Thanks anyway because this is good to see people pushing some changes from sqeuak to pharo. I'm reimplementing my package class right now. See you later :) Stef On Feb 27, 2010, at 3:17 PM, Miguel Enrique CobÃ¡ Martinez wrote: > El sÃ¡b, 27-02-2010 a las 09:44 +0100, StÃ©phane Ducasse escribiÃ³: >> :) >> >> http://code.google.com/p/pharo/issues/detail?id=2087 >> >> :) > > :), yes, I was in a hurry and I didn't create a issue, thanks for > creating it. > > Cheers >> >> On Feb 27, 2010, at 8:29 AM, Miguel Enrique CobÃ¡ Martinez wrote: >> >>> Maybe we can add this to the cleanUpForRelease script. >>> >>> Cheers >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> From: commits(a)source.squeak.org >>> Date: February 26, 2010 6:38:01 PM GMT+01:00 >>> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >>> Subject: [squeak-dev] The Trunk: Kernel-ar.411.mcz >>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>> >>> >>> Andreas Raab uploaded a new version of Kernel to project The Trunk: >>> http://source.squeak.org/trunk/Kernel-ar.411.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Kernel-ar.411 >>> Author: ar >>> Time: 26 February 2010, 7:36:40.257 pm >>> UUID: b69a28db-8475-bc4b-89ed-285ccf3841cd >>> Ancestors: Kernel-ul.410 >>> >>> Add MethodDictionary class>>compactAllInstances to save space in releases. Compacting all MDs in my images saves 600k in image size which isn't bad at all. >>> >>> =============== Diff against Kernel-ul.410 =============== >>> >>> Item was added: >>> + ----- Method: MethodDictionary class>>compactAllInstances (in category 'initialization') ----- >>> + compactAllInstances "MethodDictionary compactAllInstances" >>> + "Compacts all MethodDictionaries to save space" >>> + >>> + | oldInstances newInstances | >>> + oldInstances := self allInstances. >>> + newInstances := oldInstances collect:[:md| >>> + (self new: md size) >>> + compactCopyFrom: md; >>> + yourself]. >>> + oldInstances elementsForwardIdentityTo: newInstances. >>> + ! >>> >>> Item was added: >>> + ----- Method: MethodDictionary>>compactCopyFrom: (in category 'private') ----- >>> + compactCopyFrom: sourceMD >>> + "Copy the contents of source dictionary without growing" >>> + >>> + sourceMD keysAndValuesDo:[:key :value| | index | >>> + index := self scanFor: key. >>> + (self basicAt: index) ifNotNil:[self error: 'Something is horribly broken']. >>> + self basicAt: index put: key. >>> + array at: index put: value. >>> + tally := tally + 1. >>> + ]. >>> + self size = self capacity ifTrue:[self grow]. "grow only if we reach capacity" >>> + ! >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 27-02-2010 a las 09:44 +0100, StÃ©phane Ducasse escribiÃ³: > :) > > http://code.google.com/p/pharo/issues/detail?id=2087 > > :) :), yes, I was in a hurry and I didn't create a issue, thanks for creating it. Cheers > > On Feb 27, 2010, at 8:29 AM, Miguel Enrique CobÃ¡ Martinez wrote: > > > Maybe we can add this to the cleanUpForRelease script. > > > > Cheers > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > From: commits(a)source.squeak.org > > Date: February 26, 2010 6:38:01 PM GMT+01:00 > > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > > Subject: [squeak-dev] The Trunk: Kernel-ar.411.mcz > > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > > > > Andreas Raab uploaded a new version of Kernel to project The Trunk: > > http://source.squeak.org/trunk/Kernel-ar.411.mcz > > > > ==================== Summary ==================== > > > > Name: Kernel-ar.411 > > Author: ar > > Time: 26 February 2010, 7:36:40.257 pm > > UUID: b69a28db-8475-bc4b-89ed-285ccf3841cd > > Ancestors: Kernel-ul.410 > > > > Add MethodDictionary class>>compactAllInstances to save space in releases. Compacting all MDs in my images saves 600k in image size which isn't bad at all. > > > > =============== Diff against Kernel-ul.410 =============== > > > > Item was added: > > + ----- Method: MethodDictionary class>>compactAllInstances (in category 'initialization') ----- > > + compactAllInstances "MethodDictionary compactAllInstances" > > + "Compacts all MethodDictionaries to save space" > > + > > + | oldInstances newInstances | > > + oldInstances := self allInstances. > > + newInstances := oldInstances collect:[:md| > > + (self new: md size) > > + compactCopyFrom: md; > > + yourself]. > > + oldInstances elementsForwardIdentityTo: newInstances. > > + ! > > > > Item was added: > > + ----- Method: MethodDictionary>>compactCopyFrom: (in category 'private') ----- > > + compactCopyFrom: sourceMD > > + "Copy the contents of source dictionary without growing" > > + > > + sourceMD keysAndValuesDo:[:key :value| | index | > > + index := self scanFor: key. > > + (self basicAt: index) ifNotNil:[self error: 'Something is horribly broken']. > > + self basicAt: index put: key. > > + array at: index put: value. > > + tally := tally + 1. > > + ]. > > + self size = self capacity ifTrue:[self grow]. "grow only if we reach capacity" > > + ! > > > > > > > > > > _______________________________________________ > > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 27, 2010

[Pharo-project] Issue 329: strange behaviour when Proceeding or Stepping in a newly opened Debugger

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=329 what is the status? Can we make progress on this point? Stef Reported by jfitzell, Nov 11, 2008 Summary ~~~~~~~ When you Proceed in a Debugger, it assumes the interruptedProcess is sitting at the right context and so merely resumes the process. This assumption is valid once you have hit Restart or recompiled a method but not (currently) when the Debugger is first opened. When the Debugger first opens, the interruptedProcess is sitting in Process>>suspend and that is within the contexts of all the UnhandledError handling code, the code to open the debugger, etc. So if you hit Proceed right after opening the Debugger, the behaviour is different (see below). Current Behaviour ~~~~~~~~~~~~~~~~~ If you evaluate "Error signal" and then immediately Proceed, the behaviour is as follows: + Debugger class>>openOn:context:label:contents:fullView: is resumed and runs to completion, falling off the end + UnhandledError>>defaultAction eventually returns (and returns a Process because of the weird implementation of StandardToolSet>>debugError:) + The (non-resumable) UnhandledError is resumed with that value (a Process) + This causes the signal of UnhandledError in Error>>defaultAction to return the Process + Error>>defaultAction now returns but it ignores the Process that was returned by the UnhandledError and just returns self + The (possibly non-resumable) original error is now resumed with the value of #defaultAction (self) Expected Behaviour ~~~~~~~~~~~~~~~~~~ While the above basically works, the return value (the Error) is pretty sub-optimal and it is logically a bit confusing because the Debugger is supposed to be debugging the context where the error was signaled, not the code path that led to opening the Debugger. When you press Step, you expect it to make one step withing the current context, not to unwind a whole bunch of error handling code first. I expect step to simply make a step in the signaling context and I expect Proceed to carry on running in the signaling context. Since we are dealing with an Error that did not have a default value (since #defaultValue resulted in opening a Debugger), it seems reasonable to return nil as the result of the signal. Reproducing the Problem ~~~~~~~~~~~~~~~~~~~~~~~ This is of course hard to trace. You can verify the return value by simply inspecting "Error signal" and then hitting Proceed in the Debugger that pops up. You will see the result is an Error, not nil as I would expect. (For comparison, VW produces nil in this case, though you have to "Debug" and then "Run" because it won't let you Proceed a non-resumable error). To confirm the execution path, I ended up adding Transcript messages in UndefinedObject>>handleSignal: like this: handleSignal: exception value := exception defaultAction. Transcript show: exception name; show: ' -- defaultAction returned value: '; show: value printString; cr. ^ exception resumeUnchecked: value Suggested Fix ~~~~~~~~~~~~~ As far as I can tell, the best/easiest fix is to have the Debugger set the process into the debugged context on startup. I did this by making the attached change to Debugger>>process:controller:context:isolationHead:. It just adds a call of #popTo:value: on the process. (the debugger doesn't seem to be in a Monticello package?) This exception stuff gets complicated though, so discussion may be warranted if anybody else has a better suggestion. ***As an aside, I think the return values in UnhandledError>>defaultAction and StandardToolSet>>debugError: should be fixed to be more meaningful (or self). Returning a Process as the result of either message is silly. Debugger-processcontrollercontextisolationHead.st 704 bytes Download Delete commentComment 1 by jfitzell, Nov 11, 2008 Sorry... don't know why I couldn't see the Tools package. I found it and saved a version into Pharo-Inbox: Name: Tools-jf.90 Author: jf Time: 11 November 2008, 2:52:23 pm UUID: 5b6889f2-9071-314b-9c30-e6d83e014049 Ancestors: Tools-stephane.ducasse.89 Possible fix for issue 329: http://code.google.com/p/pharo/issues/detail?id=329 When opening a Debugger, pop the interruptedProcess back to the context that signaled the original Error. Delete commentComment 2 by jfitzell, Nov 11, 2008 Gah! Just discovered my fix seems to break things when a Warning is triggered... I need to look into it further. Delete commentComment 3 by jfitzell, Nov 11, 2008 Ok, the error I was getting was "the active process cannot pop contexts". The problem seems to be fixed by implementing ToolSet>>debugContext:label:contents: as follows: debugContext: aContext label: aString contents: contents ^ self debug: Processor activeProcess context: aContext label: aString contents: contents fullView: false This also has the side-benefit that "[Warning signal: 'foo'] fork" will now work (you get a white screen of death without that change). Anybody know why the Debugger class-side methods #openOn:context:label:contents:fullView: and #openContext:label:contents: are implemented differently to begin with? The method names don't suggest that their behaviour should be different. I feel like I've pulled on a thread that maybe I shouldn't have pulled on... :) Delete commentComment 4 by jfitzell, Nov 11, 2008 And I notice DebuggerUnwindBug>>testUnwindDebuggerWithStep is failing, but it seems to fail even with my changes reverted so I think that's not a problem here. Delete commentComment 5 by marcus.denker, Feb 18, 2009 As the change seems to be not stable yet, I have attached the mcz to the bug-report (this way we can clean the inbox) Tools-jf.90.mcz 384 KB Download

Feb. 27, 2010

Re: [Pharo-project] Scamper revival

by Schwab,Wilhelm K

Just checking :) In that case however, I would like to see a nice(r) way to construct Polymorph interfaces. Dolphin's MVP framework is very powerful. One thing that it does not seem to do well is allow domain objects to insert themselves into a GUI; Seaside and Magritte have an advantage there. I find Magritte a little too helpful, and #description *much* too helpful, meaning that it does so much for me that I forget how things work. There is probably nothing to stop us from taking a little more control over Magritte descriptions and containers, and IIRC, there is a Polymorph version of Magritte (or is that just wishful thinking??). Rather than write HTML to feed into what we all agree is a sub-optimal browser, I suggest putting the energy into refining Smalltalk idioms to turn data into a GUI using Polymorph. The end result should be better user interfaces all around. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of laurent laffont Sent: Saturday, February 27, 2010 1:47 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Scamper revival The goal is to use it for the new HelpSystem, to display images, layout easily, some colors. For browsing the web it's crap. Laurent Laffont 2010/2/27 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> I would much rather see a robust interface to an external browser, for two reasons: (1) scamper was never terribly impressive; (2) Seaside testing. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of laurent laffont Sent: Friday, February 26, 2010 4:45 PM To: An open mailing list to discuss any topics related to an open-source Smalltalk Subject: [Pharo-project] Scamper revival Hi, It's not stable, but it loads google :) Gofer new squeaksource: 'LaurentLSandbox'; package:'HTML'; package:'Scamper'; load. Then: Scamper openOnUrl: 'http://www.google.com'. I suppose there's a technique to replace all _ by := Laurent Laffont _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] new pavel mini image :)

by GermÃ¡n Arduino

2010/2/27 GermÃ¡n Arduino <garduino(a)gmail.com> > Ahh, thanks! > > May be I get confused with the old MinimalMorphic we are still using (with > the Edgar work). > > The google page seems not respond currently. > Responding now! Thanks Mariano.

Feb. 27, 2010

Re: [Pharo-project] new pavel mini image :)

by GermÃ¡n Arduino

Ahh, thanks! May be I get confused with the old MinimalMorphic we are still using (with the Edgar work). The google page seems not respond currently. Cheers. GermÃ¡n. 2010/2/27 Mariano Martinez Peck <marianopeck(a)gmail.com> > PharoKernel are has to be run -headless. The only way (I think) to interact > with it is sending scripts as parameters when starting the image from > command line. > > Look http://code.google.com/p/pharo/wiki/PharoKernel > > Cheers > > Mariano > > 2010/2/27 GermÃ¡n Arduino <garduino(a)gmail.com> > > Good news! >> >> May be that on Linux (Ubuntu 9.10) with vm pharo-vm-0.15.2f-linux don't >> works? I get only a blank world were >> nothing seems to respond. >> >> GermÃ¡n. >> >> >> 2010/2/26 Marcus Denker <marcus.denker(a)inria.fr> >> >> >>> On Feb 26, 2010, at 11:15 PM, Lukas Renggli wrote: >>> >>> > This is super cool! Exciting. >>> > >>> > The link doesn't seem to work though. Or at least I don't see where I >>> > can download the image. >>> > >>> >>> >>> http://gforge.inria.fr/frs/download.php/26462/PharoKernel-1.1-11229-UNSTABL… >>> >>> > Lukas >>> > >>> > On 26 February 2010 20:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>> >> Hi guys >>> >> >>> >> I do not know if you noticed by Pavel uploaded a new minimal image >>> >> http://gforge.inria.fr/frs/shownotes.php?release_id=4921 >>> >> >>> >> This is really exciting. >>> >> >>> >> Stef >>> >> >>> >> _______________________________________________ >>> >> Pharo-project mailing list >>> >> Pharo-project(a)lists.gforge.inria.fr >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >>> > >>> > >>> > >>> > -- >>> > 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 >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> _______________________________________________ >>> 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 >

Feb. 27, 2010

Re: [Pharo-project] new pavel mini image :)

by Mariano Martinez Peck

PharoKernel are has to be run -headless. The only way (I think) to interact with it is sending scripts as parameters when starting the image from command line. Look http://code.google.com/p/pharo/wiki/PharoKernel Cheers Mariano 2010/2/27 GermÃ¡n Arduino <garduino(a)gmail.com> > Good news! > > May be that on Linux (Ubuntu 9.10) with vm pharo-vm-0.15.2f-linux don't > works? I get only a blank world were > nothing seems to respond. > > GermÃ¡n. > > > 2010/2/26 Marcus Denker <marcus.denker(a)inria.fr> > > >> On Feb 26, 2010, at 11:15 PM, Lukas Renggli wrote: >> >> > This is super cool! Exciting. >> > >> > The link doesn't seem to work though. Or at least I don't see where I >> > can download the image. >> > >> >> >> http://gforge.inria.fr/frs/download.php/26462/PharoKernel-1.1-11229-UNSTABL… >> >> > Lukas >> > >> > On 26 February 2010 20:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> Hi guys >> >> >> >> I do not know if you noticed by Pavel uploaded a new minimal image >> >> http://gforge.inria.fr/frs/shownotes.php?release_id=4921 >> >> >> >> This is really exciting. >> >> >> >> Stef >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > 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 >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> 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 >

Feb. 27, 2010

Re: [Pharo-project] new pavel mini image :)

by GermÃ¡n Arduino

Good news! May be that on Linux (Ubuntu 9.10) with vm pharo-vm-0.15.2f-linux don't works? I get only a blank world were nothing seems to respond. GermÃ¡n. 2010/2/26 Marcus Denker <marcus.denker(a)inria.fr> > > On Feb 26, 2010, at 11:15 PM, Lukas Renggli wrote: > > > This is super cool! Exciting. > > > > The link doesn't seem to work though. Or at least I don't see where I > > can download the image. > > > > > http://gforge.inria.fr/frs/download.php/26462/PharoKernel-1.1-11229-UNSTABL… > > > Lukas > > > > On 26 February 2010 20:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> Hi guys > >> > >> I do not know if you noticed by Pavel uploaded a new minimal image > >> http://gforge.inria.fr/frs/shownotes.php?release_id=4921 > >> > >> This is really exciting. > >> > >> Stef > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > 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 > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2010