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

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 4, 2010

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

by Alexandre Bergel

Laurent, I separated MOGraphVizLayout from the main Mondrian distribution. You will find this package in the Mondrian squeaksource repository. cheers, Alexandre On 4 Apr 2010, at 04: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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 4, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by Alexandre Bergel

Hi James, I do not know how related is it to your work, but I made some experiment to translate Smalltalk into Java (http://www.squeaksource.com/Smalltalk2Java.html ). Cheers, Alexandre On 3 Apr 2010, at 20:16, James Ladd 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) > > >> Excellent I think that having a smalltalk running on JVM is cool. > Did you check SqueakOnJava? > > I have looked at these implementations, Bistro and others. > However, I'm wanting to get as close to native JVM Bytecode as > possible. > > >>Why do you want to port the compiler in Java? > >>In Java you should only implement the necessary infrastructure to > run the object model of Pharo (primitives > >>in particular). Then you can load Smalltalk code and you do not need > >>to compile smalltalk code in smalltalk? > > A good point, but I'm not sure how that approach would allow > profiling, debugging and > integration with Java. This is outlined a little in the previous post: > http://jamesladdcode.com/?p=311 > > >> study little Smalltalk for example to get an idea. > Would it be sufficient to choose those classes that are also > outlined in the ANSI standard? > > Rgs, James. > > Australia's #1 job site If It Exists, You'll Find it on SEEK > _______________________________________________ > 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 4, 2010

Re: [Pharo-project] [squeak-dev] RE: Dynamic content in inspector??

by Schwab,Wilhelm K

Lukas, That is certainly a workaround, but I have serious reservations about any surprises that might result from text that I choose to display to represent an object and without subsequently interacting with the inspector. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, April 04, 2010 2:46 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] RE: Dynamic content in inspector?? I think you should fix your #printOn: method not to cause any side-effects. #printOn: belongs to the public protocol and can be called by any tool at any time on any object. Lukas On 4 April 2010 02:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > I appreciate the tip, but I'm trying to go the other direction: I want the inspector to stop messing around with what should be sleeping dogs. Â There really does appear to be some type of side effect of the multi-line print string, and no doubt the precise text I am displaying. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > HernÃ¡n Morales Durand > Sent: Saturday, April 03, 2010 7:40 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [squeak-dev] RE: Dynamic content in inspector?? > > If you want to monitor or track any object in a workspace-like morph with a specific periodicity, then you may want to install the EventsMonitor package and implement your own monitor subclassing GenericMonitor and implementing #report and #windowTitle. EventMonitor and OBEventMonitor are just provided as examples. > Cheers, > > HernÃ¡n > > 2010/4/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> I certainly didn't install it, nor do I find EventMonitor in the image. >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> HernÃ¡n Morales Durand >> Sent: Saturday, April 03, 2010 6:53 PM >> To: The general-purpose Squeak developers list >> Cc: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] [squeak-dev] RE: Dynamic content in inspector?? >> >> http://www.squeaksource.com/EventsMonitor.html ? >> >> HernÃ¡n >> >> 2010/4/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> Help.... >>> >>> This might be a problem in Pharo (RC1) in general or in its standard toolset, but I have a multi-line print string that when displayed in an inspector appears to try to edit the receiver and cause strangeness. Â Is that a known problem with a solution? >>> >>> 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: Saturday, April 03, 2010 1:59 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: [Pharo-project] Dynamic content in inspector?? >>> >>> Hello all, >>> >>> With the understanding that I am doing non-trivial FFI work and could have completely fried my image already, I'm wondering if this is a common Squeak/Pharo newbie kind of amazement: I create and inspect a new instance of something that has a #printOn: method, and the contents of the inspector's workspace change with time. >>> >>> I have seen inspectors update to track objects in the past, but this behavior is unwanted. Â I thought of finalization, but that appears not to be happening (nor should it be with the object inspected). >>> >>> I will keep looking, but plausible explanations will be appreciated. >>> >>> 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 >> _______________________________________________ >> 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 > -- 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

April 4, 2010

Re: [Pharo-project] [squeak-dev] RE: Dynamic content in inspector??

by StÃ©phane Ducasse

sounds cool! Stef On Apr 4, 2010, at 1:52 AM, HernÃ¡n Morales Durand wrote: > http://www.squeaksource.com/EventsMonitor.html ? > > HernÃ¡n > > 2010/4/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Help.... >> >> This might be a problem in Pharo (RC1) in general or in its standard toolset, but I have a multi-line print string that when displayed in an inspector appears to try to edit the receiver and cause strangeness. Is that a known problem with a solution? >> >> 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: Saturday, April 03, 2010 1:59 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Dynamic content in inspector?? >> >> Hello all, >> >> With the understanding that I am doing non-trivial FFI work and could have completely fried my image already, I'm wondering if this is a common Squeak/Pharo newbie kind of amazement: I create and inspect a new instance of something that has a #printOn: method, and the contents of the inspector's workspace change with time. >> >> I have seen inspectors update to track objects in the past, but this behavior is unwanted. I thought of finalization, but that appears not to be happening (nor should it be with the object inspected). >> >> I will keep looking, but plausible explanations will be appreciated. >> >> 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 4, 2010

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

by laurent laffont

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 >> > >

April 4, 2010

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

by laurent laffont

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 >

April 4, 2010

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

by Tudor Girba

Aha, in this case, it looks like the dependency was added only to Mondrian-GraphViz, but not to Mondrian. Mondrian-GraphViz inherits from Mondrian, so Mondrian should be loaded first: Gofer new squeaksource: 'Mondrian'; package: 'Mondrian'; load Doru On 4 Apr 2010, at 10:23, Lukas Renggli wrote: > AFAIK, Exupery uses Mondrian to visualize code generation/ > optimization/... > > Lukas > > On 4 April 2010 10:19, 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 >> > > > > -- > 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 -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

April 4, 2010

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

by Lukas Renggli

AFAIK, Exupery uses Mondrian to visualize code generation/optimization/... Lukas On 4 April 2010 10:19, 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 > -- Lukas Renggli www.lukas-renggli.ch

April 4, 2010

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

by Tudor Girba

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."

April 4, 2010