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

Re: [Pharo-project] TeaTime (Re: nebraska?)

by Lawson English

Andreas Raab wrote: > On 3/20/2010 4:43 PM, Michael Rueger wrote: >> On 3/20/10 4:35 PM, Marcus Denker wrote: >>>> So why does everyone ignore TeaTime? I admit I don't understand the >>>> internals, but it obviously *looks* like it could be the basis of >>>> Nebraska (or any other P2P solution). >>>> >>> Can you point me to a real good publication about it? I mean, a >>> *real* one? >> >> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some >> multiplayer game like sync scheme (at least the poor me understood when >> I saw the implementation ;-) ). > > Actually we didn't. TeaTime (as conceived by David Reed) consisted of > two separate ideas, namely that of a world synchronization protocol > and that of a P2P network protocol. When David Smith and I implemented > the version we shipped in Hedgehog we dropped the P2P network protocol > part and only concentrated on the synchronization aspect which > resulted in *major* simplifications. > [...] > > Coincidentally, I am toying regularly with the idea of using an even > more simplified version of TeaTime to do something like Nebraska. > Might get around to it one of these days, it's actually straightforward. > > BTW, it's a misconception to think TeaTime is something complicated. > Complicated things don't work. Simple things do. TeaTime is actually > VERY simple. That's why it works. I'm extremely interested in this kind of thing, since it helps hybridize virtual worlds with hopefully beneficial results for all concerned. http://www.ietf.org/mail-archive/web/vwrap/current/msg00082.html Lawson

April 6, 2010

Re: [Pharo-project] FFI+Linux+double return value

by Schwab,Wilhelm K

Hello all, I built (I think) a 2151 vm, but I can't run it. It keeps complaining that it can't find the X11 display driver. What am I missing about the command line options? I generally try to use /full-path-to-vm/squeakvm options /full-path-to-image Help?? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Tuesday, April 06, 2010 3:05 PM To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] FFI+Linux+double return value Nicolas, I am running this on Ubuntu (9.10) and have been using the Pharo 0.15.2f vm. I just tried a Squeak vm (3.11-3) and could not get it to load my library. I have been using an absolute path the the .so; could that be the problem with the Squeak vm?? There has been a lot of discussion of the Pharo Linux vm lately, with some links and corrections, so I'll have to look around a little. You asked if I can check the vm sources; the concern is whether or not I will have anything to add :) Is there something specific you want me to do? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Tuesday, April 06, 2010 1:46 PM To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: [Pharo-project] FFI+Linux+double return value Hello all, I had some strange results with double return values and boiled it down to a C function Double AnyDouble() { return 1.0; } called via anyDouble < cdecl: double 'AnyDouble' () > and driven by | out | out := Array writeStream. 100 timesRepeat:[ out nextPut:Library default anyDouble ]. out contents. The results are not good. It works for the first three elements, after which it produces NaN. The real problem appears to be comparison of floats being broken after that point, as evidenced by a walkback that arises when trying to inspect the resulting collection - exploring it works. I need to try this on the latest image/vm, but wanted to start gathering opinions. Any ideas? Bill _______________________________________________ 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 6, 2010

Re: [Pharo-project] Redline Smalltalk

by Dan Ingalls

Hi, Stef - >This is fun because I was rereading the miniimage contents and started to think in terms of package reorganization to support a mini image. >I reread also Spoon a bit and I was looking at the nuturning. >Dan it would be nice if you could merge the potatoe change into Jsqueak? Potato is JSqueak. I don't get it. >Dan, Mariano for his PhD did some analysis about number of object used during typical coding session and we got around 17 %. >So mariano would like to see how we can get something like LOOM to dispose unused objects :) Are you aware of the work I did that enables class fault detection in Squeak? If a class has a nil methodDictionary, it causes a fault (ie it sends recoverFromMDFault to the class). That code then restores the MD in addition to any anyalysis you want. I never cleaned it up for posterity, but it enabled lots of interesting work... By nilling all but a few MDs, and then running some application, you could tell exactly what classes were needed and which were not. See the method discoverActiveClasses. A special feature even recorded the call stack that caused each class to be touched. What I was doing was restructuring the entire system as a bunch of image segments that could be swapped out and brought in on demand -- a sort of user-programmable swapping memory. This all worked at one point. Swapping of projects was a bit flakier because of our weak discipline on pointer scope, but it even worked in many cases. Where I was going with the whole "reorganizeEverything" project was that the SystemDictionary would be partitioned into many separate dictionaries in each project, and that namespaces would be the same as the project swapping unit, and the whole thing would be simple and fast. It actually worked once (;-) also. Loom was cool, but it could never come close to the speed of imageSegments. I played around with swapping out the entire VM Support category with all classes and methods, and it would swap in the entirety in less than 200 milliseconds, and this was a decade ago. Sorry for the long digression, but maybe some of this thinking or even the actual mechanism can be of use to your experiments. - Dan > >> James Ladd <james_ladd(a)hotmail.com> wrote... >>>> Hi Pharo-ites, >>>> >>>> I'm working on a port of Pharo to the Java Virtual Machine called Redline Smalltalk. >>>> (read more here: http://jamesladdcode.com/?p=323) >>>> >>>> I'm wanting to port every single class over time, but initially enough to get the >>>> compiler working and have a minimum runtime. >>>> >>>> Of the 1600+/- classes which are those necessary to make a small workable compiler >>>> and runtime environment? >> >> Hi, James - >> >> Bert Freudenberg forwarded this along to me, as I'm not on a Pharo mailing list. >> >> I think you know of my JSqueak project (a.k.a. Potato) -- a Squeak VM written in Java. The image that I used with it, is the same that I always use for this kind of experiment -- mini.image built in Squeak 2.2. >> >> The reason it is so cool is that it includes browser, editor, compiler, inspector debugger, and files -- everything you need for self-support. Plus it has the decompiler, and special temp-name hack, so you can actually browse sources with temp names before any file system works. My favorite thing about this image is that although it is only 600k, if you decompile all its sources, it comprises over 850k of Smalltalk, so it's like a compressed version of the sources with a full-function IDE thrown in for free ;-). >> >> As I said, the image is about 600k, of which 240k is code -- 202 classes (x2 if you count the metas) with 4590 methods. This should be a good guide for you in choosing classes to start with. >> >> You can actually run this image live in JSqueak on the web if you have Java installed and the planets are aligned correctly... >> http://Weather-dimensions.com/Dan/JSqueak.jnlp >> Another interesting statistic is that the Java .jar file is only 433k, including not only the VM, but also the entire image! This is possible because the image is so small that the pointers in it are mostly zeroes, so it compresses nicely. I just checked that this runs, and was happy to see that it putts along at 21 million bytecodes/sec on my laptop. > > >> I haven't looked recently, but I think you'll find Mini2.2.image or something like it in the same place where all the historical releases of Squeak are kept. Let me know if you can't find it. >> >> Have fun with your project! I hope this helps >> >> - Dan >> _______________________________________________ >> 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 6, 2010

Re: [Pharo-project] A small idea how to get closer to hardware with small efforts :)

by Igor Stasenko

On 6 April 2010 14:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > I always liked how Smalltalk X did it... they have > > Â Â Â Â -> an ivar in CompiledMethod that is the "native code pointer". > Â Â Â Â -> Primitive methods are just methods that have this pointer set > Â Â Â Â Â Â to the primitive in the vm. > Â Â Â Â -> Methods with embedded C-code are compiled and linked with > Â Â Â Â Â Â the Smtk->C cross-compiler, the pointer than points to that function > Â Â Â Â -> the JIT just put a pointer to the code it generates. > > So they merge primitives / static compiling(+embedded c-code) *and* the JIT > into one not that ugly mechanism. In STX, the memory is managed by the VM, though (the > code is not allocated in the GCed object memory by the JIT). > > So: Yes, I like this :-) and your mechanism is a nice way to get it easily integrated into the current > system. > > Q: what happens when code is moved by the GC? > Yeah, it will break the whole thing :) To avoid that, a native code should not issue any memory allocation, which may cause GC. Perhaps, there is a way to counter this , while still being able to move the code. A primitive could set a flag that its going to call a native code, embedded into compiled method, so, then, after GC, if this flag is set, VM knows, that memory allocation is issued from native code, and should fix the return address (1) on stack, before returning to native code, which moved to the new code location: primitive -> native code --(1)-> VM allocation procedure -> GC (1) - a return address , which should be fixed. > -- > 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 > -- Best regards, Igor Stasenko AKA sig.

April 6, 2010

Re: [Pharo-project] Handle Close Event in Image - necessary for 1.0?

by StÃ©phane Ducasse

Torsten I appreciate your effort but we can only do what can be done in the time we can allocate to do a task if you see what I mean. I cannot test on windows because we do not have a windows machine. We are doing an incredible amount of work but we cannot do more than it is reasonable to do. Then in freeze time this is freeze time. we will try to get shorter iteration cycles and this is not by delaying 1.0 that we are making progress on that front. And this is not by saying that pharo "will be less quality than" ... more or less that it helps. So 1.0 will be like it can. And if people bash us this is ok too. You remember a while ago one guy asked who is ready to pay 10 Euros per month to have a better pharo and we got 6 persons.... > However I still believe that fixing this in 1.0 would not only > be a plus - it will also prevent questions regarding this > new problem since people WILL use newer VM's after the > first 1.0 release of Pharo and then instantly step into the problem! > > > And it is not a Windows specific problem as Stef thinks it is. > > Bert requested John today (see [1]) to change the default for Mac too ... TODAY. Imagine I was painting my house.... and this evening this would have to be fixed? When is the last time that a bug that annoys you on windows got fixed in one day? because for me on mac so far it took months. > so if you upgrade your Mac VM for whatever reason (maybe to do > 1.1 work or since you need a newer VM for a commercial project) > then you will step into this with the 1.0 image. Yes and since you are a good pharoers you will know and you will understand and help us and help yourself. > Guess what people think when Pharo tries to bring Squeak to a > better quality level and then would not be able to close the > system as usual after upgrading to a newer and better VM. > > But maybe my expectations for a 1.0 release are too high... > > Bye > T. > > > > [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 6, 2010

Re: [Pharo-project] Handle Close Event in Image - necessary for 1.0?

by Adrian Lienhard

Yes, there will certainly be other important fixes, which â together with the new close logic â are going into a 1.0.1 maintenance release. Cheers, Adrian On Apr 6, 2010, at 22:40 , StÃ©phane Ducasse wrote: > +1 > > On Apr 6, 2010, at 7:53 PM, Michael Roberts wrote: > >> 1.0 will be a maintained release. I suggest we push out 1.0 and >> schedule this fix for the first maintenance release. otherwise we will >> never get it out the door. from a process point of view, there will >> always be another important bug to fix. >> >> thanks, >> Mike >> >> On Tue, Apr 6, 2010 at 6:08 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> So...which is the working Windows VM we should use for 1.0 ? the one before >>>> 4 version. >>> >>> Last one before this change was introduced was the 3.11.8 Squeak VM >>> which I adapted for Pharo. You can download it from: >>> >>> https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip >>> >>> >>> However I still believe that fixing this in 1.0 would not only >>> be a plus - it will also prevent questions regarding this >>> new problem since people WILL use newer VM's after the >>> first 1.0 release of Pharo and then instantly step into the problem! >>> >>> >>> And it is not a Windows specific problem as Stef thinks it is. >>> >>> Bert requested John today (see [1]) to change the default for Mac too ... >>> so if you upgrade your Mac VM for whatever reason (maybe to do >>> 1.1 work or since you need a newer VM for a commercial project) >>> then you will step into this with the 1.0 image. >>> >>> Guess what people think when Pharo tries to bring Squeak to a >>> better quality level and then would not be able to close the >>> system as usual after upgrading to a newer and better VM. >>> >>> But maybe my expectations for a 1.0 release are too high... >>> >>> Bye >>> T. >>> >>> >>> >>> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html >>> >>> -- >>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>> >>> _______________________________________________ >>> 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 6, 2010

Re: [Pharo-project] Handle Close Event in Image - necessary for 1.0?

by StÃ©phane Ducasse

+1 On Apr 6, 2010, at 7:53 PM, Michael Roberts wrote: > 1.0 will be a maintained release. I suggest we push out 1.0 and > schedule this fix for the first maintenance release. otherwise we will > never get it out the door. from a process point of view, there will > always be another important bug to fix. > > thanks, > Mike > > On Tue, Apr 6, 2010 at 6:08 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> So...which is the working Windows VM we should use for 1.0 ? the one before >>> 4 version. >> >> Last one before this change was introduced was the 3.11.8 Squeak VM >> which I adapted for Pharo. You can download it from: >> >> https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip >> >> >> However I still believe that fixing this in 1.0 would not only >> be a plus - it will also prevent questions regarding this >> new problem since people WILL use newer VM's after the >> first 1.0 release of Pharo and then instantly step into the problem! >> >> >> And it is not a Windows specific problem as Stef thinks it is. >> >> Bert requested John today (see [1]) to change the default for Mac too ... >> so if you upgrade your Mac VM for whatever reason (maybe to do >> 1.1 work or since you need a newer VM for a commercial project) >> then you will step into this with the 1.0 image. >> >> Guess what people think when Pharo tries to bring Squeak to a >> better quality level and then would not be able to close the >> system as usual after upgrading to a newer and better VM. >> >> But maybe my expectations for a 1.0 release are too high... >> >> Bye >> T. >> >> >> >> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html >> >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> 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 6, 2010

[Pharo-project] Expacted Resource (RAM) requirements to run Pharo

by Rudi Ludwig

Hello, so I got interested in Smalltalk (again) installed Pharo and ran the ProfStef tutorial. I'm not a programmer, just interested :-) To be more precise, I followed the link on the Pharo homepage Download directory and installed from squeakvm.org/unix : Squeak-3.11.3.2135-solaris2.10_i386.tar.gz in - /usr/local/Squeak-3.11.3.2135-solaris2.10_i386 and from Pharo: Pharo-1.0-10515-rc3dev10.03.1 in my home directory. OS: OpenSolaris b127. Now while that worked --I can start Squeak (/usr/local/../bin/squeak.sh) chose the Pharo Image form the file browser that opens and go. Just following the integrated tutorial (ProfStef) and having maybe one more ClassBrowser open, at some point consumed 780 MB RAM (RSS). Question: Is that the expacted behavior (resource requirement) or is there something wrong with the steps I choose to run Pharo, although apparently they worked? There is a "PharoDebug.log" 180+kB large from that session, I can provide on request. (Didn't want to send it to whole list directly). Rudi

April 6, 2010

Re: [Pharo-project] Making the operating system close window event prompt for squeak window closure.

by StÃ©phane Ducasse

Hi john for the moment we do nothing but we are ready to do something if somebody explains what exactly. Stef On Apr 6, 2010, at 7:14 PM, John M McIntosh wrote: > Ok, before I do this I need to ask the Pharo folks if they handle the close window event. > To test someone can alter the info.plist setting as describe below and see what happens. > > > Begin forwarded message: > >> From: Bert Freudenberg <bert(a)freudenbergs.de> >> Date: April 6, 2010 3:35:26 AM PDT >> To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> >> Subject: Re: [Vm-dev] New Windows VM: 4.0.1 >> Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> >> >> >> On 28.03.2010, at 22:59, Andreas Raab wrote: >>> >>> >>> 1) The VM will now default to pass the window close event to the image instead of handling it directly. You can see that in a current trunk image by clicking on the close button (you'll now get a Squeak notifier instead of the previous VM notifier). The old behavior is still available if you SHIFT-Click on the close button. This is very useful if your image hangs. >> >> John, >> >> could you change the default for the Mac VM too? Both Linux and Windows VMs now deliver the window event rather than killing the image. >> >> For Etoys we use >> >> SqueakWindowAttribute <8200001f> >> >> in the VM's Info.plist. That at least enables the red window close button (though "Quit" from the dock menu does not work). >> >> - Bert - >> >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 6, 2010

Re: [Pharo-project] Problem loading Exupery on PharoCore 1.0

by Javier PimÃ¡s

Not sure with this either, but I think it comes from a bug related to squeak and pharo syntax. Pharo admits a slightly modified Squeak syntax, probably this code that didn't compile was commited in Squeak and was perfectly valid there. When this happens, you get that window indicating the syntax error. If you change the code and then accept it, you get past this step, but then it fails in the place you are seeing now. Maybe there is a bug report for this problem already. To get out of it right now... maybe Bryce can commit the fixed code from squeak and you won't have the problem, or you can debug it and try to find the place in where nil appears (the error pops because its sending #methodClass: to nil). Remember, all this would be true if it is the error I think it is. Regards, Javier. 2010/4/6 laurent laffont <laurent.laffont(a)gmail.com> > 2010/4/5 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > > maybe you could try separating with spaces the elements of the array, I >> think I had a similar problem once, don't know if it is the case: >> >> #( (block 1 (mov (literalVariableAddress 10) t1) ) ) >> > > > Thanks Javier. I just have to put a space between mov and ( > (really strange). > > Then I have this error. I've tried with last Exupery and > Exupery-wbk.335.mcz. > > UndefinedObject(Object)>>doesNotUnderstand: #methodClass: > IntermediateSimplifierTests class(Behavior)>>basicAddSelector:withMethod: > IntermediateSimplifierTests > class(Behavior)>>methodDictAddSelectorSilently:withMethod: > IntermediateSimplifierTests > class(Behavior)>>addSelectorSilently:withMethod: > IntermediateSimplifierTests > class(ClassDescription)>>addSelectorSilently:withMethod: > MethodAddition>>installMethod > [] in [] in [] in MCPackageLoader>>basicLoad > OrderedCollection>>do: > [] in [] in MCPackageLoader>>basicLoad > BlockClosure>>on:do: > [] in MCPackageLoader>>basicLoad > BlockClosure>>ensure: > MCPackageLoader>>basicLoad > [] in MCPackageLoader>>loadWithNameLike: > [] in MCPackageLoader>>useChangeSetNamed:during: > BlockClosure>>ensure: > MCPackageLoader>>useChangeSetNamed:during: > MCPackageLoader>>useNewChangeSetNamedLike:during: > MCPackageLoader>>loadWithNameLike: > MCVersionLoader>>loadWithNameLike: > MCVersionLoader>>load > GoferLoad>>execute > Gofer>>execute:do: > Gofer>>execute: > Gofer>>load > > Laurent Laffont > > >> >> Regards, >> Javier. >> >> >> On Sun, Apr 4, 2010 at 9:49 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: >> >>> Maybe a non-visible character? >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 4 Apr 2010, at 04:32, laurent laffont wrote: >>> >>> I do: >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfMondrian'; >>>> load.. >>>> >>>> ConfigurationOfMondrian project latestVersion load. >>>> >>>> Then >>>> >>>> Gofer new >>>> squeaksource: 'Exupery'; >>>> package: 'Exupery'; >>>> load. >>>> >>>> ==> Syntax Error >>>> >>>> testLiteralVariableAddress >>>> source := MedMethod >>>> createIntermediate: >>>> #((block 1 >>>> (mov(literalVariableAddress 10) t1) )Nothing more expected ->) >>>> for: machine. >>>> mockEmitter expectEmission: >>>> #( (block1 >>>> (mov #(#emitFetchAddress 1 >>>> #(#simplifiedLiteralAddress 10)) t1)) >>>> (block2) ). >>>> >>>> self simplifyFullyMocked. >>>> >>>> self verify. >>>> mockEmitter verify. >>>> >>>> >>>> Laurent Laffont >>>> >>>> >>>> On Sun, Apr 4, 2010 at 10:26 AM, laurent laffont < >>>> laurent.laffont(a)gmail.com> wrote: >>>> OK Thanks. I will try. Would be cool to have a ConfigurationOfExupery >>>> :). >>>> >>>> Laurent Laffont >>>> >>>> >>>> On Sun, Apr 4, 2010 at 10:19 AM, Tudor Girba <tudor.girba(a)gmail.com> >>>> wrote: >>>> Hi Laurent, >>>> >>>> Something is wrong. MOAbstractLayout and MOGraphVizLayout come from >>>> Mondrian. Were these by mistake somehow added as dependencies to Exupery? >>>> Doru >>>> >>>> >>>> >>>> On 4 Apr 2010, at 10:06, laurent laffont wrote: >>>> >>>> Hi, >>>> >>>> I want to try to build Exupery VM. On PharoCore 1.0 I do: >>>> >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfVMMaker'; >>>> load. >>>> >>>> (ConfigurationOfVMMaker project version: '1.2') load. >>>> >>>> Then >>>> >>>> Gofer new >>>> squeaksource: 'Exupery'; >>>> package: 'Exupery'; >>>> load. >>>> >>>> I have this error: >>>> >>>> This package depends on the following classes: >>>> MOAbstractLayout >>>> You must resolve these dependencies before you will be able to load >>>> these definitions: >>>> MOGraphVizLayout >>>> MOGraphVizLayout>>doExecute: >>>> MOGraphVizLayout>>findTopLeftCorner: >>>> >>>> >>>> I suppose I need GraphViz package >>>> >>>> Gofer new >>>> squeaksource: 'GraphViz'; >>>> package: 'GraphViz'; >>>> load. >>>> >>>> But when I load it I have a Syntax Error: >>>> >>>> runWithSystemFramework: string >>>> <> expected ->apicall: short 'system' (char*) module: >>>> 'System.framework'> >>>> >>>> ^ self externalCallFailed >>>> >>>> Laurent Laffont >>>> _______________________________________________ >>>> 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 >>>> >>>> "It's not how it is, it is how we see it." >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> 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 > -- Javier PimÃ¡s Ciudad de Buenos Aires

April 6, 2010