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

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

by nullPointer

Someone knows the posibilities of implement a Smalltalk environment in MONO .NET? I see projects like http://ajlopez.wordpress.com/2008/07/14/ajtalk-a-smalltalk-like-interpreter/ or too http://www.refactory.com/Software/SharpSmalltalk/ but I will like know the guruÂ´s opinion. Regards. -- View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1750615p1751812.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 5, 2010

Re: [Pharo-project] New step in Pharo modularity

by Mariano Martinez Peck

On Mon, Apr 5, 2010 at 3:27 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > 1) There are packages that should NOT be part of the core, but they are not >> also dev tools. For example, ObjectTracer, ObjectViewer, Morph examples, >> Sound, ImageSegment (?) etc. So...where do we put them ? >> > > I would imagine to have each package in a dedicated SqueakSource > repository, pretty much the same way we have OB, RB, NewInspector. > Yes, actually, the repository was alrady created in SqueakSource under the name of PharoNonCorePackages. > From what you wrote, I understand that you wish to create an intermediary > layer, PharoNonCorePackages > In that case: > Pharo = PharoVeryCore + PharoNonCorePackages + PharoDev > Is this what you intend ? Exactly. > Ideally, I do not see a valid reason for PharoNonCorePackages to be: each > package can happily live in its own SS rep. Yes, they can also live in their own repository. But I think it is easier to have the all together in the same repository. Mostly because I don't think there will be too much packages for the same repository. I mean, all those packages are little and seem not to be very related to each other...so it is not like a big project where you need a repository because you have a lot of packages for the same project. In this case we will probably have one package. > Moreover, this could easily create confusion. Why ? What is the difference with the Pharo repository for example ? > But for practical reason, it could make your life easier. > > yes! > Cheers, > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

April 5, 2010

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

by Bryce Kampjes

You can safely ignore this. Mondrian and GraphViz is only used for inspectors to view the generated code and intermediate languages. The easiest way to resolve them would be to load GraphViz and Mondrian from the Exupery repository. It should be easy to port Exupery forward to the latest Mondrian releases but may take a few very minor and localised code changes. Bryce On Sun, 2010-04-04 at 10:23 +0200, 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 > > > > >

April 5, 2010

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

by StÃ©phane Ducasse

igor I'm confused. Do you want to write C code in our smalltalk editor? (as in Smalltalk/X) Where the native code is coming? Who compiles it? Can I edit it? Do you have a scenario in mind to help understanding what is your vision behind your suggestion? Stef On Apr 5, 2010, at 10:13 AM, Igor Stasenko wrote: > Hello again, > > it is about running a native code , stored in compiled methods. > > All we need is: > > a) allow code execution for object memory. On most platforms this is > trivial - just pass additional flags to virtual memory allocation > functions. > b) add a single primitive 'call a native code' > c) use a special compiled method trailer, which will store the native > code inside itself > > Then we could place any native code inside a compiled method and use a > single primitive to run this code. > This is quite simple thing, given that both pharo and squeak adopted > method trailers, so > a primitive, before running the code, needs few checks: > - a method's trailer format is valid (we could reserve a terminal > byte value for that) > - a native code, placed inside a method trailer is targeted for same > platform as currently running on > > if not, then primitive will simply fail, and interpreter will run the > method's bytecode, which , depending on a situation, can check if it > can recompile the code > (if platform doesn't match) or use a workaround. > The only limitation of such approach, that native code, placed in > compiled method should be relocate-agnostic, i.e. > never use absolute jumps, only relative ones and so on. > > Also, we could force, that code using a specific calling convention, > so it will be easy to fetch values from stack and other useful stuff > from interpreter/object memory (like passing an interpreterProxy > pointer). > This could be a good answer in generating a trampoline code for > FFI/Alien on the fly. > > What you think? > > -- > Best regards, > Igor Stasenko AKA sig. >

April 5, 2010

Re: [Pharo-project] New step in Pharo modularity

by Alexandre Bergel

> 1) There are packages that should NOT be part of the core, but they > are not also dev tools. For example, ObjectTracer, ObjectViewer, > Morph examples, Sound, ImageSegment (?) etc. So...where do we put > them ? I would imagine to have each package in a dedicated SqueakSource repository, pretty much the same way we have OB, RB, NewInspector. From what you wrote, I understand that you wish to create an intermediary layer, PharoNonCorePackages In that case: Pharo = PharoVeryCore + PharoNonCorePackages + PharoDev Is this what you intend ? Ideally, I do not see a valid reason for PharoNonCorePackages to be: each package can happily live in its own SS rep. Moreover, this could easily create confusion. But for practical reason, it could make your life easier. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 5, 2010

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

by David T. Lewis

On Mon, Apr 05, 2010 at 03:13:51PM +0300, Igor Stasenko wrote: > Here the proof of concept implementation. > So, here the questions, which i like to be answered: > 1. reserve a numbered primitive Probably a named primitive in the interpreter is best, see comment in John's new primitiveMicrosecondClock. I don't think that there is any performance implication once the primitive name has been resolved once. > 2. discuss the calling convention > 3. add a 'platform id' code to VMMaker, and let language side know , > on which platform id VM currently runs on (through additional > primitive) I'm not sure how to handle #3, but there are a lot of different CPUs and operating systems out there, not to mention all the different modes of say an Intel CPU. So it may not be trivial to answer the question "can this snippet of compiled code be executed in my current runtime environment". Dave

April 5, 2010

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

by Igor Stasenko

Here the proof of concept implementation. 1. Build VM with a new primitive (in Interpreter-primitiveNativeCall.st) 2. run image with new VM - file-in a NativeCodeTrailers - then NativeCodeTests I found that on my WinXP, i even haven't to change a platform-specific code to run it - only this tiny primitive!! Seems like someone put a right flags into memory allocation procedure already :) If you look at primitive, it is quite primitive :) The one thing, which bothers me above everything is a sanity check, which should be done more appropriately. A primitive checks that trailer contains a right platform code, and if it contains something else, then it fails. This is done, obviously, in order to prevent running a native code, generated for different platform. The problem, that VMMaker don't having any notion of platform code, to my knowledge, so i put there '1' for now. But for correct behavior, there should be one, set by VMMaker at initialization, so for different platforms, VM built for that platform will answer different code, i.e. windoze32 = 1, linux32 = 2 ... and so on. So, here the questions, which i like to be answered: 1. reserve a numbered primitive 2. discuss the calling convention 3. add a 'platform id' code to VMMaker, and let language side know , on which platform id VM currently runs on (through additional primitive) P.S. And yes. The ' MethodNativeCodeTest new testAnswer42 ' runs flawlessly , at least on my box :) And I'm already having an tiny assember lying over there , which i can use for generating the native stuff .. It would be cool to adapt this stuff for generating an FFI/Alien trampoline code. -- Best regards, Igor Stasenko AKA sig.

April 5, 2010

Re: [Pharo-project] New step in Pharo modularity

by Michael Roberts

On Monday, April 5, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Stef, please correct me if I wrote something incorrect :) > > Hi folks. It is since a couple of months that we have been discussing with Stef about the current Pharo architecture and the different kind of images we have. What we want to achieve, is to have a really small kernel and provide Metacello configurations so that people can easily load the rest of the stuff. Similar to what we are already doing with PharoCore and PharoDev. However, this still have limitations: > > 1) There are packages that should NOT be part of the core, but they are not also dev tools. For example, ObjectTracer, ObjectViewer, Morph examples, Sound, ImageSegment (?) etc. So...where do we put them ? > > 2) Most of the Pharo external packages that are loaded in a Dev image, are maintained by their own developers, not necessary "Pharo developers". > > So, we want to define "something" that Pharo developers should maintain, but that are not part of the core, neither a dev tool. For example, suppose that we want to remove some messages, classes or whatever, when we look senders or references, we should do it now not only in the core, but also in this new image. This is because now Pharo developers, will take care also about this. We don't have yet a clear name for this image. Do you have? > > We created a new repository called PharoNonCorePackages in squeaksource, Why not call it PharoExtras ? > The last thought was how we can integrate Metacello to manage updates in the system update. This is still green, but would be cool to a future. The idea is to migrate the ScriptLoader stuff, and instead, releasing metacello versions. Then, the system update should be just to load the last metacello version. > > So...what do you think ? > I would like to see a metacello version for the core. It would make it easier to review changes before they are pushed into the update stream. Cheers mike

April 5, 2010

Re: [Pharo-project] [Seaside] a note system for pharo?

by StÃ©phane Ducasse

there is flag: have a look at the senders... :) Far too many? Stef On Apr 5, 2010, at 1:27 PM, Stan Shepherd wrote: > > I follow Steve Wessels's method: > http://squeak.preeminent.org/tut2007/html/035B.html (Leaving Notes In > Your Code) > > He recommends to define a dummy method on Object called #revisit: , passing > your note as the string. > > then you can browse senders of #revisit: to see all your notes. > > ...Stan > -- > View this message in context: http://n4.nabble.com/Re-Seaside-a-note-system-for-pharo-tp1751477p1751520.h… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 5, 2010

Re: [Pharo-project] CollabActive book :)

by StÃ©phane Ducasse

serge for now there is relationship with PBE (I do not have the time to convert it in web support). The idea is how I write it: make sure that there is a place for people to consolidate and wrtie knowledge/documentation tutorial about pharo. After we will probably see how to trun them into chapters for PBE2. Stef On Apr 5, 2010, at 11:07 AM, Serge Stinckwich wrote: > Great idea ! > But what will be the relationship between this book and "Pharo by > Example" ? Not the same material ? > Regards, > > On Sat, Apr 3, 2010 at 6:35 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi Pharoers >> >> We put in place (big big thanks doru, anton, lukas and gemstone for that) a pier book >> http://book.pharo-project.org/ >> >> The idea is that we can collect/edit.... information about pharo on this collaborative book. >> Now we would like that **you**/**us** control the quality of the contents. The book will be open: >> **you**= anybody from the pharo community can be editor (you should ask probably doru because I have to >> really make sure that I do not mess it up) but not everybody can change text, everybody will be able to add notes >> following the http://book.seaside.st principle. >> As an editor you can register to the rss stream and includes the comments. >> >> Now the idea is that after a while the ready to get publish parts may be used for Pharo by example 2 since we >> can generate automatically latex from the web. >> >> Now I would love to have chapter on >> - how to compile my vm on Mac OSX >> - how to compile my vm on linux >> - how to compile my vm on Windows >> - Understanding Announcement >> - Settings >> - Building UI with Polymorph.... >> - Help >> - ... >> >> So if you want to be an editor you are more than welcome! >> Just ask >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 5, 2010