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

Re: [Pharo-project] pharo VM names

by ClÃ©ment Bera

2013/2/5 Denis Kudriashov <dionisiydk(a)gmail.com> 2013/2/5 Esteban Lorenzano <estebanlm(a)gmail.com> > RizelVM What is RizelVM? Correct me if I am wrong, but Rizel VM is a VM that permits to benchmark. It was done by a student and worked nicely but it is not maintained any more. >

Feb. 5, 2013

[Pharo-project] RE : on the 1.4 one click the Pharo-14-one-click.sh does not work on Ubuntu12.0.4

by GOUBIER Thierry

Hi Stef, two things not working with 1.4 on 12.04 and 12.10 (and probably other linuxes as well). - Lack of ia32 libs on a x64 linux - Pharo1.4-app directory in a path with accents (for example : TÃ©lÃ©chargements/) -- This one is already an issue I think. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de stephane ducasse [stephane.ducasse(a)free.fr] Date d'envoi : mardi 5 fÃ©vrier 2013 19:45 Ã : Pharo Development Objet : [Pharo-project] on the 1.4 one click the Pharo-14-one-click.sh does not work on Ubuntu12.0.4 Hi guys we got a problem during a lecture. The script on the 1.4 one click the Pharo-14-one-click.sh does not work on Ubuntu12.0.4 Stef

Feb. 5, 2013

[Pharo-project] on the 1.4 one click the Pharo-14-one-click.sh does not work on Ubuntu12.0.4

by stephane ducasse

Hi guys we got a problem during a lecture. The script on the 1.4 one click the Pharo-14-one-click.sh does not work on Ubuntu12.0.4 Stef

Feb. 5, 2013

Re: [Pharo-project] pharo VM names

by Denis Kudriashov

2013/2/5 Esteban Lorenzano <estebanlm(a)gmail.com> > RizelVM What is RizelVM?

Feb. 5, 2013

Re: [Pharo-project] [Update] Zinc-SSO now supports Dropbox !

by Sven Van Caekenberghe

Sabine, On 05 Feb 2013, at 14:45, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > Hi Sven, > > great! The file was created in my dropbox account:-) And it will be read, updated and written from now on, every time you run the demo. > I will try to use it now in my application and will come back with questions if they occur. Yesterday I used STON to serialize a ZnOAuth1DropboxUserAccess instance that was created from the demo web app demo. To make such an instance you use the codes that were also needed to set up the web demo and the 2 part access token that the web app requested and was granted by the user. To access this token, you currently have to inspect/explore the sessions in the ZnServer instance (there will normally only be one) and assign it to the following object (this is all in hack/debug mode): | data service | data := ZnOAuth1ConsumerData newForDropbox consumer: 'vqzexpgl5rvzXXX'; consumerSecret: '13uygcdbou8lXXX'; yourself. service := ZnOAuth1Service new providerAccount: data ; yourself. ZnOAuth1DropboxUserAccess new oauth1Service: service; yourself. (And send it #accessToken:). This will give you a representation like this: ZnOAuth1DropboxUserAccess { #oauth1Service : ZnOAuth1Service { #providerAccount : ZnOAuth1ConsumerData { #getRequestTokenUrl : 'https://api.dropbox.com/1/oauth/request_token', #authorizeTokenUrl : 'https://www.dropbox.com/1/oauth/authorize', #getAccessTokenUrl : 'https://api.dropbox.com/1/oauth/access_token', #consumer : 'vqzexpgl5rvzXXX', #consumerSecret : '13uygcdbou8lXXX', #accessTokenClass : nil } }, #accessToken : ZnOAuth1Token { #value : 'qdcm6mivqesdXXX', #secret : '39w7r9wqamdgXXX', #sessionid : nil } } I don't know what the lifetime is of this, but from other apps using Dropbox I am guessing it must be pretty long, even close to infinite. So one day later, with the demo web app long gone and image restarted, I can do this: ('ZnOAuth1DropboxUserAccess.ston' asFileReference readStreamDo: [ :in | STON fromString: in ]) getFile: #( 'demo.txt' ). And it just works. Now, we have to work out a way to make this flow easier and secure at the same time. > Thank you very much. We wrote this so that others can use it, so we are happy with other developers trying out our stuff. Thanks for testing and for the feedback. Sven > Sabine > > On Mon, Feb 4, 2013 at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Jan 2013, at 19:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 30 Jan 2013, at 18:32, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > > > >> Sven, > >> > >> could you provide a simple code fragment which shows how to write and how to read a file from the smalltalk image to the connected dropbox app folder? > > > > The whole API is not (yet) implemented. > > > > https://www.dropbox.com/developers/reference/api > > > > Have a look at ZnOAuth1TwitterUserAccess. > > > > If I find more time, I might try myself. > > > > GET is pretty straightforward, for PUT or POST you will have to supply a ZnEntity of a specific mime-type with bytes or a string. > > > > Note that for file access the host is different. > > I added a bit more Dropbox API and a little demo accessing files. > > There is now #manipulateDemoFile: which will try to access a file called 'demo.txt' and read an id out of it. If found the file is written again, with the id increased and some other fields updated as well. If the file did not exist, it is created with id 1. All this happens automatically if you access /sso-dropbox and log in. You'll get the updated id in the web page and you'll see your Dropbox client doing a local update immediately! > > Here are the details (http://mc.stfx.eu/Zinc-HTTP-Components) > > --- > Name: Zinc-SSO-OAuth1-Core-SvenVanCaekenberghe.13 > Author: SvenVanCaekenberghe > Time: 4 February 2013, 12:27:12.196 pm > UUID: 3d78a965-462e-4a4e-94aa-1779369aecb8 > Ancestors: Zinc-SSO-OAuth1-Core-SvenVanCaekenberghe.12 > > extended ZnOAuth1Service with #httpDelete:using: #httpPost:with:using: #httpPut:with:using: > extended ZnOAuth1DropboxUserAccess with #getFile: and #putFile:data: > some refactoring in ZnOAuth1DropboxUserAccess > --- > Name: Zinc-SSO-Demo-SvenVanCaekenberghe.5 > Author: SvenVanCaekenberghe > Time: 4 February 2013, 12:28:14.601 pm > UUID: 4bb17785-f885-4db5-98f5-9c7d52d3add6 > Ancestors: Zinc-SSO-Demo-SvenVanCaekenberghe.4 > > added ZnSSOServerDelegate>>#manipulateDemoFile: > --- > > This should get you started. > > Note that it is not necessary to log in each time: the access token is valid until you get an unauthorized response. > With the access token and the consumer data you can create service objects separate from the web app that did the setup. > > HTH, > > Sven > > > >> Greetings > >> Sabine > >> > >> On Wed, Jan 30, 2013 at 6:00 PM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > >> Hi Sven, > >> > >> there was only missing loading Zodiac, the dll (windows) was already included in the 1 klick image. > >> > >> Gofer it > >> squeaksource: 'Zodiac'; > >> package: 'Zodiac-Core'; > >> package: 'Zodiac-Tests'; > >> load. > >> > >> It works. I play around now. > >> Thank you very much! > >> Sabine > >> > >> > >> On Wed, Jan 30, 2013 at 5:38 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> On 30 Jan 2013, at 17:21, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > >> > >>> Hi Sven, hi Jan, > >>> > >>> thank you. > >>> I am one step further now but there must be something else missing to load. > >>> I failed with my current image, so I tried the following: > >>> > >>> I took a fresh image - the Pharo 1.4. one click app from the pharo homepage > >>> (http://gforge.inria.fr/frs/download.php/31258/Pharo-1.4-14557-OneClick.zip) > >>> > >>> Then I loaded seaside 3.0 (from the welcome screen - MetacelloConfigurationBrowser open). > >>> > >>> After that, I loaded > >>> > >>> Gofer it > >>> url: 'http://mc.stfx.eu/ZincHTTPComponents'; > >>> package: 'ConfigurationOfZincHTTPComponents'; > >>> load. > >>> > >>> And then the bleeding Edge version > >>> ConfigurationOfZincHTTPComponents project bleedingEdge load: 'SSO'. > >>> > >>> Then this was possible: > >>> (ZnServer startDefaultOn: 8100) > >>> logToTranscript; > >>> debugMode: true; > >>> delegate: (ZnSSOServerDelegate new > >>> dropboxData: (ZnOAuth1ConsumerData newForDropbox > >>> consumer: 'my appdata'; > >>> consumerSecret: 'my appdata'; > >>> yourself); > >>> yourself). > >>> > >>> No I tried in my browser > >>> localhost:8100/sso-dropbox > >>> > >>> Then I got a walkback in my Image: No secure socket stream class set or available > >> > >> Well, the error says it all: you need TLS/SSL support. As is noted in > >> > >> https://github.com/svenvc/docs/blob/master/zinc/zinc-sso-paper.md#installat… > >> > >> You can get Zodiac to work in 1.4 > >> > >> http://zdc.stfx.eu > >> > >> Don't forget that you also need the plugin next to your VM ! > >> > >> In Pharo 2.0 Zodiac is included by default the latest VM's there should have the plugin. > >> But in 2.0 it will be slightly more difficult to load Seaside, but it does work. > >> > >> Sorry, but all this is still a bit in motion, hopefully you will keep trying. > >> > >>> ==>> I do not have the class ZdcSecureSocketStream in my Image > >>> self secureSocketStreamClass is Nil in > >>> > >>> streamClassForScheme: scheme > >>> (#(http ws) includes: scheme) ifTrue: [ > >>> ^ self socketStreamClass ]. > >>> (#(https wss) includes: scheme) ifTrue: [ > >>> ^ self secureSocketStreamClass ifNil: [ > >>> self error: 'No secure socket stream class set or available' ] ]. > >>> (ZnUnknownScheme scheme: scheme) signal > >>> > >>> Can you tell me what is missing to load? > >>> > >>> Greetings > >>> Sabine > >>> > >>> > >>> 30 January 2013 5:14:22.402 pm > >>> > >>> ZnNetworkingUtils(Object)>>error: > >>> Receiver: a ZnNetworkingUtils > >>> Arguments and temporary variables: > >>> aString: 'No secure socket stream class set or available' > >>> Receiver's instance variables: > >>> socketStreamClass: SocketStream > >>> secureSocketStreamClass: nil > >>> > >>> ZnNetworkingUtils>>streamClassForScheme: > >>> Receiver: a ZnNetworkingUtils > >>> Arguments and temporary variables: > >>> scheme: #https > >>> Receiver's instance variables: > >>> socketStreamClass: SocketStream > >>> secureSocketStreamClass: nil > >>> > >>> ZnNetworkingUtils>>socketStreamToUrlDirectly: > >>> Receiver: a ZnNetworkingUtils > >>> Arguments and temporary variables: > >>> url: https://api.dropbox.com/1/oauth/request_token > >>> stream: nil > >>> address: #[199 47 218 158] > >>> Receiver's instance variables: > >>> socketStreamClass: SocketStream > >>> secureSocketStreamClass: nil > >>> > >>> ZnNetworkingUtils>>socketStreamToUrl: > >>> Receiver: a ZnNetworkingUtils > >>> Arguments and temporary variables: > >>> url: https://api.dropbox.com/1/oauth/request_token > >>> Receiver's instance variables: > >>> socketStreamClass: SocketStream > >>> secureSocketStreamClass: nil > >>> > >>> > >>> > >>> > >>> On Wed, Jan 30, 2013 at 4:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> Sabine, > >>> > >>> On 30 Jan 2013, at 16:24, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > >>> > >>>> Hi Sven, > >>>> > >>>> after loading: > >>>> > >>>> Gofer it > >>>> url: 'http://mc.stfx.eu/ZincHTTPComponents'; > >>>> package: 'ConfigurationOfZincHTTPComponents'; > >>>> load. > >>>> > >>>> ConfigurationOfZincHTTPComponents project latestVersion load: 'SSO'. > >>>> > >>>> The ZnOAuth1ConsumerData does not have a method called >>newForDropbox (but >>newForGoogle and >>newForTwitter). > >>>> Also, ZnSSOServerDelegate does not have a method >>dropboxData: (but facebook, twittter and google) > >>>> > >>>> Did I miss something? > >>> > >>> Yes and no. The latest stable version of the configuration does not yet include the Dropbox code. > >>> The following will load what is called bleedingEdge, the very latest version of everything, regardless of its release status. > >>> > >>> ConfigurationOfZincHTTPComponents project bleedingEdge load: 'SSO'. > >>> > >>> Sorry about that. > >>> > >>> Sven > >>> > >>>> Greetings > >>>> Sabine > >>>> > >>>> > >>>> On Sun, Jan 27, 2013 at 8:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>> > >>>> On 27 Jan 2013, at 13:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>> > >>>>> If anyone is interested, I can write another email explaining how you can run this demo for yourself on your own account. > >>>> > >>>> How to run the Dropbox code yourself: > >>>> > >>>> 1. Get yourself a free Dropbox account at http://www.dropbox.com > >>>> > >>>> 2. Install some client software on one or more of your computers (Mac, Windows, Linux) or devices (iOS [iPhone, iPad, iPod], Android, BlackBerry, Kindle Fire) and move some files around to get a feel for the service. > >>>> > >>>> 3. When you give other applications access to (part of) your Dropbox files, you can check that at https://www.dropbox.com/account#applications > >>>> > >>>> 4. Define your own app that will try to access Dropbox files. Go to https://www.dropbox.com/developers (Developer home) and start defining a new app by clicking the 'Create an app' button at https://www.dropbox.com/developers/apps - start with the access type 'App folder'. > >>>> > >>>> 5. The two important elements you need are the 'App key' and 'App secret', make sure to copy them correctly. > >>>> > >>>> 6. Get the very latest code in your image (we develop in Pharo 2.0, but 1.4 or even 1.3 should work - SSL has to be fully operational). > >>>> > >>>> Gofer it > >>>> url: 'http://mc.stfx.eu/ZincHTTPComponents'; > >>>> package: 'ConfigurationOfZincHTTPComponents'; > >>>> load. > >>>> > >>>> ConfigurationOfZincHTTPComponents project latestVersion load: 'SSO'. > >>>> > >>>> 7. Start a Zn server with an appropriate delegate, configured for your app > >>>> > >>>> (ZnServer startDefaultOn: 8100) > >>>> logToTranscript; > >>>> debugMode: true; > >>>> delegate: (ZnSSOServerDelegate new > >>>> dropboxData: (ZnOAuth1ConsumerData newForDropbox > >>>> consumer: 'vqz-app-key-zoca'; > >>>> consumerSecret: '13u-app-secret-8l006'; > >>>> yourself); > >>>> yourself). > >>>> > >>>> (The above is a demo setup limited to Dropbox, the other demos are not configured and won't work). > >>>> > >>>> 8. Go to http:://localhost:8100/sso-dropbox and click the link to log in - you will be transferred to Dropbox to log in (if you aren't already) and asked to authorise your demo app, after which Dropbox will redirect you back to your app. > >>>> > >>>> 9. Once back in your app, sso-dropbox-callback (#ssoDropboxCallback:) will access your account info and list the app root folder, which will then be shown. > >>>> > >>>> 10. For the rest of the API, (currently not yet implemented), see https://www.dropbox.com/developers/reference/api - you don't have to worry about the whole authentication thanks to Zinc-SSO. > >>>> > >>>> We would love for others to try this (as well as the other Zinc-SSO options, Google, Facebook, Twitter) out, in their own projects, and to provide actual feedback and generally help improve the code and documentation. > >>>> > >>>> As always, May the Source be with you! > >>>> > >>>> Sven > >>>> > >>>> PS: The demo app is not (yet) a production app: only you and up to 5 explicitly listed users can use it. You have to apply for production status later on. Also, the whole ZnSSOServerDelegate code is a demo, for an actual project, it would be best to extract the necessary parts out of it, reusing the underlying Zinc-SSO-OAuth1-Core framework. > >>>> > >>>> -- > >>>> Sven Van Caekenberghe > >>>> http://stfx.eu > >>>> Smalltalk is the Red Pill > >>>> > >>>> >

Feb. 5, 2013

Re: [Pharo-project] pharo VM names

by Camillo Bruni

On 2013-02-05, at 16:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > 1) CI builds names is not the same than app names. I am talking about the artifact names if that wasn't clear. > 2) The "official" pharo vm (the NB Cog JIT), should be named just "Pharo", because that is what users will see in his dock bar. > 3) The stack VM is not a debug vm is just a VM who uses a stack-to-register approach. I would call it PharoS or something that simple. think about the user perspective? why would I even bother taking this VM? There is one that is fast, and another one that is what? less stable? > 4) RizelVM is not a regularly distributed VM, so it should not be in pharo, but in pharo-contribution yes, definitely. > 5) PLEASE, STOP MARKING ISSUES THAT CAN WAIT AS 2.0!!!! We are just 2 weeks of release. Stop adding new tasks. No matter if you think is important. Unless it will block us to release, IT IS NOT. I associated this with Pharo2.0 ... I guess wrongly.. I provide fixes that can be included NOW => I have to mark them 2.0 otherwise nobody will ever ever look at it. => did you ever touch the monkey? You didn't, so unless that is fixed and it checks 3.0 tags as well, I can't help myself but putting it on 2.0

Feb. 5, 2013

Re: [Pharo-project] pharo VM names

by Esteban Lorenzano

Hi, 1) CI builds names is not the same than app names. 2) The "official" pharo vm (the NB Cog JIT), should be named just "Pharo", because that is what users will see in his dock bar. 3) The stack VM is not a debug vm is just a VM who uses a stack-to-register approach. I would call it PharoS or something that simple. 4) RizelVM is not a regularly distributed VM, so it should not be in pharo, but in pharo-contribution 5) PLEASE, STOP MARKING ISSUES THAT CAN WAIT AS 2.0!!!! We are just 2 weeks of release. Stop adding new tasks. No matter if you think is important. Unless it will block us to release, IT IS NOT. Thanks, Esteban On Feb 5, 2013, at 4:08 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > We should really decide on this: https://code.google.com/p/pharo/issues/detail?id=7423 > > I guess that would simplify the choice for newcomers significantly!

Feb. 5, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Igor Stasenko

On 5 February 2013 15:58, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> it did. It was because we didn't had time to catch-up since argentina >> trip. up until you came back at january. >> you, of course, can explain it as my lazyness or whatever.. but the >> fact is that i have no idea what you did.. > > thats why I write mails. The mails here are not just random blabbering, they > are communication for the people that are not physically present. > > Now I hope you understand the value of incremental mails and even more of > reading mails... > And i hope you will understand that i have a physical limits of how much information i can digest at some limited period of time. And how many i can remember and keep in mind. When there's too much mails and every mail is "highly important" then everything turns into "random blabbering". and sure.. i am bad at filtering stuff.. and stupid. But stating that doesn't really helps. You should know, that i know much much better and deeper in what and how really bad i am, so please stop trying to beat me on this field :) >> and how to use it. >> having a documentation, is not the same as seeing the whole picture. >> i want to understand, how it works and why it works like that, not how >> to use it. > > If you know how it works you're done as a user of the NativeBoost job. Everything else > is mostly interesting for the ci/jenkins administrator. > > The main motivation is to NOT use jenkins. Jenkins is bad software, it does it's job but > setting it up is not that nice. I wrote all these scripts that we can simply write a single > bash file which does everything. > > My use-case is always: What do I have to do, to reproduce this locally? > i like your motivation! > Before: > - check that I copy the scripts-download > - check that I download the right VM from jenkins (I cannot run it locally since the urls were relative) > - check that I us the right scripts from pharo-build > - check that I put the images in the right location otherwise build.sh won't work > - pray that everything works > > Now: > - copy the jenkins job bash into a file > - execute it > - pray that it works > +1 i like it. >> like following: >> >> ciCog.sh >> ciCogVM.sh >> ciNBCog.sh >> ciNBCogVM.sh >> ciPharo13.sh >> ciPharo14.sh >> ciPharo14Cog.sh >> ciPharo14CogVM.sh >> ciPharo20.sh >> ciPharo20Cog.sh >> ciPharo20CogVM.sh >> ciPharo20NBCog.sh >> ciPharo20NBCogVM.sh >> ciPharo20PharoVM.sh >> ciPharo20Rizel.sh >> ciPharo20RizelVM.sh >> ciPharoVM.sh >> ciRizel.sh >> ciRizelVM.sh >> >> >> this list burns my eyes. > > Initially the scripts did not have the VM suffix, stupid me. So I added it, but I could not > change all the jenkins jobs since my internet connection was very bad in argentina. > > => we can remove all the non -VM scripts there > The rest are just combinations of the image and the VMs > >> and having same problem,as Marcus asks about VMs: which one i have to use? >> Is there a way to have less? just wonder. > > Yes, if you make the PharoVM compile we only need 2/3 of them... > > - PharoVM the default VM including "everything" > - StackVM the debug vm, in case we have issues with the JIT > - RizelVM for profiling > > > What can we do to simplify this? > -------------------------------- > => rename them > - PharoVM is fine > - StackVM => Pharo-Debug-VM > - RizelVM => Pharo-Profiler-VM > > like that nobody has to decode the name of the VM's anymore... -- Best regards, Igor Stasenko.

Feb. 5, 2013

[Pharo-project] pharo VM names

by Camillo Bruni

We should really decide on this: https://code.google.com/p/pharo/issues/detail?id=7423 I guess that would simplify the choice for newcomers significantly!

Feb. 5, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Camillo Bruni

> it did. It was because we didn't had time to catch-up since argentina > trip. up until you came back at january. > you, of course, can explain it as my lazyness or whatever.. but the > fact is that i have no idea what you did.. thats why I write mails. The mails here are not just random blabbering, they are communication for the people that are not physically present. Now I hope you understand the value of incremental mails and even more of reading mails... > and how to use it. > having a documentation, is not the same as seeing the whole picture. > i want to understand, how it works and why it works like that, not how > to use it. If you know how it works you're done as a user of the NativeBoost job. Everything else is mostly interesting for the ci/jenkins administrator. The main motivation is to NOT use jenkins. Jenkins is bad software, it does it's job but setting it up is not that nice. I wrote all these scripts that we can simply write a single bash file which does everything. My use-case is always: What do I have to do, to reproduce this locally? Before: - check that I copy the scripts-download - check that I download the right VM from jenkins (I cannot run it locally since the urls were relative) - check that I us the right scripts from pharo-build - check that I put the images in the right location otherwise build.sh won't work - pray that everything works Now: - copy the jenkins job bash into a file - execute it - pray that it works > like following: > > ciCog.sh > ciCogVM.sh > ciNBCog.sh > ciNBCogVM.sh > ciPharo13.sh > ciPharo14.sh > ciPharo14Cog.sh > ciPharo14CogVM.sh > ciPharo20.sh > ciPharo20Cog.sh > ciPharo20CogVM.sh > ciPharo20NBCog.sh > ciPharo20NBCogVM.sh > ciPharo20PharoVM.sh > ciPharo20Rizel.sh > ciPharo20RizelVM.sh > ciPharoVM.sh > ciRizel.sh > ciRizelVM.sh > > > this list burns my eyes. Initially the scripts did not have the VM suffix, stupid me. So I added it, but I could not change all the jenkins jobs since my internet connection was very bad in argentina. => we can remove all the non -VM scripts there The rest are just combinations of the image and the VMs > and having same problem,as Marcus asks about VMs: which one i have to use? > Is there a way to have less? just wonder. Yes, if you make the PharoVM compile we only need 2/3 of them... - PharoVM the default VM including "everything" - StackVM the debug vm, in case we have issues with the JIT - RizelVM for profiling What can we do to simplify this? -------------------------------- => rename them - PharoVM is fine - StackVM => Pharo-Debug-VM - RizelVM => Pharo-Profiler-VM like that nobody has to decode the name of the VM's anymore...

Feb. 5, 2013