- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] OSX 10.9 PharoVM build failure workarounds

by Esteban Lorenzano

Hi, you have to check the README of https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm> :) Esteban > On 17 Nov 2014, at 16:58, Ben Coman <btc(a)openInWorld.com> wrote: > > > I followed the instructions at https://github.com/pharo-project/pharo-vm > to build the Pharo VM. In generator.image I evaluated... > PharoVMBuilder buildMacOSX32. > then > cd ../build > bash build.sh > > After cmake finished its checks, it tried to compile freetype (2.4.9) but gets errors... > > *Generating /Users/ben/Repos/pharo-vm/results/Pharo.app/Contents/MacOS/Plugins/libfreetype.6.dylib* > > clang: warning: no such sysroot directory: > '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk' > > **fatal error: **'math.h' file not found* > > > And indeed, I don't have > ../MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk > I have > ../MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk > > So updating CMakeLists.txt as follows... > + set(CMAKE_OSX_DEPLOYMENT_TARGET 10.9) > + set(CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk) > > - set(CMAKE_OSX_DEPLOYMENT_TARGET 10.5) > - set(CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk) > > allowed the build to progress further. > > ========= > > Then the build failed getting "too many errors" that looked somewhat like this... > /Users/ben/Repos/pharo-vm/platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m:208:18: error: use of undeclared identifier 'GL_TEXTURE_RECTANGLE_ARB' > glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MIN_FILTER, GL_NEAREST); > > Tracked down a likely suspect here... > https://codereview.chromium.org/587193005/diff/1/content/browser/compositor… > > And indeed editing... > platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m > > to add... > #import <OpenGL/gl.h> > > gave me a working VM. > > > ========= > > Should I log these somewhere ? > cheers -ben

Nov. 17, 2014

OSX 10.9 PharoVM build failure workarounds

by Ben Coman

I followed the instructions at https://github.com/pharo-project/pharo-vm to build the Pharo VM. In generator.image I evaluated... PharoVMBuilder buildMacOSX32. then cd ../build bash build.sh After cmake finished its checks, it tried to compile freetype (2.4.9) but gets errors... *Generating /Users/ben/Repos/pharo-vm/results/Pharo.app/Contents/MacOS/Plugins/libfreetype.6.dylib* clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk' **fatal error: **'math.h' file not found* And indeed, I don't have ../MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk I have ../MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk So updating CMakeLists.txt as follows... + set(CMAKE_OSX_DEPLOYMENT_TARGET 10.9) + set(CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk) - set(CMAKE_OSX_DEPLOYMENT_TARGET 10.5) - set(CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk) allowed the build to progress further. ========= Then the build failed getting "too many errors" that looked somewhat like this... /Users/ben/Repos/pharo-vm/platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m:208:18: error: use of undeclared identifier 'GL_TEXTURE_RECTANGLE_ARB' glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MIN_FILTER, GL_NEAREST); Tracked down a likely suspect here... https://codereview.chromium.org/587193005/diff/1/content/browser/compositor… And indeed editing... platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m to add... #import <OpenGL/gl.h> gave me a working VM. ========= Should I log these somewhere ? cheers -ben

Nov. 17, 2014

Re: [Pharo-dev] [Vm-dev] Re: How to check whether the handle is always valid with NativeBoost ?

by Blondeau Vincent

Hi Thanks a lot for your answers ! It is very helpful. But how can I launch a script at the startup or shutdown of the image especially for Pharo ? Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Igor Stasenko EnvoyÃ© : jeudi 13 novembre 2014 23:40 Ã : Squeak Virtual Machine Development Discussion Cc : Pharo Development List Objet : Re: [Pharo-dev] [Vm-dev] Re: How to check whether the handle is always valid with NativeBoost ? On 13 November 2014 18:37, Eliot Miranda <eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>> wrote: Hi Vincent, one way, used in VisualWorks, is to ensure that only valid handles exist. So very early at startup the system does some allInstances invocations on the classes of handles and invalidates all the handles found. This doesn't fix handles stored as raw integers anywhere, but provided the system is designed to have specific objects for external handles (and I hope it is) this shouldn't happen. Since snapshot is relatively rare and start-up relatively frequent (at least in e.g. a web deployment context), one performance improvement is to do the allInstances before snapshot, and then merely enumerate the collection of handles, rather than use allInstances. Just to add: - (re)validating external resources could vary depending on library or how short/long-lived the resource is etc. As you described, one of the scenarios is to flush invalid handles at system startup. In NB i using session checking, to do it lazily, once there's an attempt to use external resource. But all that, of course, doesn't addresses the problem when external resource get invalidated, for one or another reason, during same session. Using proxy to control each and every access to external resource is, of course, an ultimate solution, but alas, quite expensive since imposes high overhead. I would call it a brute-force solution. To minimize overhead, my approach often is to place a check at key entry part of algorithm, so if check passed, then rest of algorithm can run safely without excessive checking. But that really depends on design of external library/framework, whether it possible or not. Usually, if you cleverly organize the access to services, it is possible to do it without using brute-force proxyfying. On Thu, Nov 13, 2014 at 9:05 AM, Blondeau Vincent <vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>> wrote: Hi ! I am doing a binding to the R library with NativeBoost. So I create some external objects and apply some functions on them. If the handle to the object is not valid, either the function crashes or gives a bad result. How can I ensure to have a valid pointer at anytime ? I see two solutions: - Either check at any NativeBoost call that the handle is valid (by checking the session id) - Or do a proxy that checks the session and recreate the external object. What do you think ? Thanks in advance, Cheers, Vincent BLONDEAU ________________________________ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. -- best, Eliot -- Best regards, Igor Stasenko. ________________________________ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Nov. 17, 2014

Re: [Pharo-dev] Julia vs Pharo

by Serge Stinckwich

On Mon, Nov 17, 2014 at 2:56 PM, werner kassens <wernerk740(a)gmail.com> wrote: >>... What is missing in Pharo at the moment: >>- multiple dispatch >>- arbitrary precision float ... > > Hi Serge, > there exists an arbitrary precision float package made by nicolas cellier: > https://code.google.com/p/arbitrary-precision-float/wiki/ArbitraryPrecision… Great to know such a beast exist ;-) > ok, its not builtin into pharo, but this is not really a problem, one uses > those things more for crosschecking, where speed is not really a problem. > re multiple dispatch, actually this was the first and most important thing i > found missing when i discovered pharo ,squeak, smalltalk. otoh there exists > a package that does this; if i remember correctly the name is helvetica. i > read the papers about that package but never downloaded that package > essentially for two reasons: > - i'm a speed freak and feared this would slow down my programs too much. i > thought this is something that should indeed be hard coded. > - although, if i remember correctly, this package _is downloadable, it was > in a way deeply hidden in the internet (not in the usual places like > smalltalkhub or squeaksource) as if the author did not really want it to be > used by everybody for every task. I never heard about this one. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Help fight Ebola by joining the Computing for Ebola Challenge http://bit.ly/1oEdBag

Nov. 17, 2014

Re: [Pharo-dev] ValueHolder analysis

by Igor Stasenko

On 17 November 2014 12:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 15 Nov 2014, at 10:49 , stepharo <stepharo(a)free.fr> wrote: > > I get dizzy (may be time to go to sleep) but I wonder > why do we need to check first the the window changed and after that it got > closed? > Especially since whenWindowChanged: presuppose that we have access to > window. > Am I missing something? > > self whenWindowChanged: [ :w | > > w whenClosedDo: [ self clear ] ]. > > > ComposableModel>>whenWindowChanged: aBlock > window whenChangedDo: aBlock > > > WindowModel>>whenClosedDo: aBlock > > isClosedHolder whenChangedDo: [:value | > value ifTrue: [ aBlock value ] ] > > > IMHO, APIs that, in essence, glue together announcers and non-self > subscribers, are bad, it's an extra level of indirection with little gains. > (And quite a few restrictions) > Let the announcers be resolvable, and leave it to subscribers to do the > actual subscribing. > > To me, it looks like ValueHolders are being used for the sake of using > ValueHolders, rather than delivering events in the simplest way possible... > Say you do something like > > WindowModel >> announcer > windowAnnouncer := Announcer new > > WindowModel >> createWindow > window := blahblah. > window announcer when: GenericWindowEvent do: [:event self announcer > announce: event ]- > > And all the modelling widgets are free to respond to any window events by > subscribing to the models windowAnnouncer, rather than registering blocks > for value holders linked to single type changes. > > users of whenClosedDo: would instead do something like (usually in an > initialize method where it's passed as a windowModel parameter) > windowModel announcer when: WindowClosed do: aBlock > and as such, the code that starts with self whenWindowChanged (I assume in > the initialize method on a ComposableModel subclass?) > window announcer when: WindowClosed do: [self clear] > > After your post, i think i figured, where i see the design flaw. And can articulate it: - the widget model can expose certain properties , like extent, color etc to its controller - the controller model can expose certain properties of domain object to the widget (for example if we take a list model, it could be: list size, list items, selected item index etc) - both controller and widget models can expose various events to any interested party(es) via subscription mechanism To me it is clear that properties are not events.. They are conceptually distinct, and there's different mechanisms how and where you use them: you treat one as data, and other as behavior. Yes, smalltalk largely blurs the distinction between data & behavior since everything is an object, but i think this is the case where you want to keep distinction clear: - the fact that you should be able to customize your reaction on different events by implementing different behavior, don't means that you should turn that into property e.g. "property which holds a block that will be evaluated when something happens". No, that's complete nonsense.. when you having announcement mechanism, you can simply react to announced event the way you want. And you certainly don't want to react on events like 'what we gonna do when someone changes the block that will be evaluated when certain event triggered'. Because you want to react on user events, not to events that trigger when your application changes the way it wants to handle the events, nor the events that trigger when when your application changes the way it wants to handle the events, that trigger when your application changes the way it wants to handle the events, nor the events that trigger when when your application changes the way it wants to handle the events, that trigger when when your application changes the way it wants to handle the events, that trigger when your application changes the way it wants to handle the events ... (you get an idea :) For example look at: AbstractWidgetModel subclass: #CheckBoxModel instanceVariableNames: 'actionWhenActivatedHolder actionWhenDesactivatedHolder stateHolder labelClickableHolder labelHolder' classVariableNames: '' category: 'Spec-Core-Widgets' It is clear that actionWhenActivatedHolder and actionWhenDesactivatedHolder are events which should just be announced by widget, that anyone would want to handle. period. you don't need ValueHolder(s) to hold blocks running in case of such events. Phew...

Nov. 17, 2014

Re: [Pharo-dev] [smalltalk-research] Re: Julia vs Pharo

by Alexandre Bergel

I would not be that pessimistic. We have to go step by step. I have not had a look at SciSmalltalk. But can the section "15.1 Simple bootstraping exerciseâ of http://bogumilkaminski.pl/files/julia_express.pdf <http://bogumilkaminski.pl/files/julia_express.pdf> be written in SciSmalltalk? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Nov 16, 2014, at 12:42 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > On Sun, Nov 16, 2014 at 1:45 AM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >> Hi Serge! >> >> Thanks for sharing this. >> >> I indeed believe that scientific computing will play a big role in Pharo adoption by a large public > > The problem is that you need to invest at least 5 years of work before > having some impact in this domain. > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Help fight Ebola by joining the Computing for Ebola Challenge > http://bit.ly/1oEdBag >

Nov. 17, 2014

Re: [Pharo-dev] ValueHolder analysis

by Igor Stasenko

On 17 November 2014 11:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > On 15 Nov 2014, at 10:41 , stepharo <stepharo(a)free.fr> wrote: > > > > initializePresenter > > "Used to specify the subwidgets, and/or to bind them together" > > "By default, do not do anything" > > > > extentHolder whenChangedDo: [:ex | > > self widget ifNotNil: [:widget | > > (widget respondsTo: #extent:) > > ifTrue: [ widget extent: ex ]]]. > > > > > > may be by design the ifNotNil should not be needed and the respondsTo > too.... > > > > pffff. > > > > I don't get it, doesn't the presenter already have an initialize: method > that gets passed in its model? > > So a more "proper" thing to do is > PresenterClassesThatCaresAboutExtent >> initializeFromModel: myModel > myModel extentHolder when: ChangedValue do: [:ann | self extent: > ann newValue] > > The controller and presenter(or view) are always in 1:1 correspondence, not one to many. The idea that you can easily swap out presenter, leaving controller intact is IMO wrong. You either drop both of them and create another pair, if you want, but you never drop only one of them because, by nature, they form a very strong relationship.. which goal is: properly represent the domain object in GUI. For domain object(s), however there's no 1:1 correspondence between domain object its views.. single domain object can have multiple different views. But that in fact means it can have multiple pairs of controller+presenters at once. My point that there's no need for things like 'windowChanged' , where window role is a view in MVC (or MVP) models, to be handled by controller, since it is never changes for single pair of controller and presenter during their lifetime, once initialized and set up. Cheers, > Henry > -- Best regards, Igor Stasenko.

Nov. 17, 2014

Re: [Pharo-dev] ValueHolder analysis

by Henrik Johansen

> On 15 Nov 2014, at 10:49 , stepharo <stepharo(a)free.fr> wrote: > > I get dizzy (may be time to go to sleep) but I wonder > why do we need to check first the the window changed and after that it got closed? > Especially since whenWindowChanged: presuppose that we have access to window. > Am I missing something? > > self whenWindowChanged: [ :w | > w whenClosedDo: [ self clear ] ]. > > > ComposableModel>>whenWindowChanged: aBlock > window whenChangedDo: aBlock > > > WindowModel>>whenClosedDo: aBlock > > isClosedHolder whenChangedDo: [:value | > value ifTrue: [ aBlock value ] ] > IMHO, APIs that, in essence, glue together announcers and non-self subscribers, are bad, it's an extra level of indirection with little gains. (And quite a few restrictions) Let the announcers be resolvable, and leave it to subscribers to do the actual subscribing. To me, it looks like ValueHolders are being used for the sake of using ValueHolders, rather than delivering events in the simplest way possible... Say you do something like WindowModel >> announcer windowAnnouncer := Announcer new WindowModel >> createWindow window := blahblah. window announcer when: GenericWindowEvent do: [:event self announcer announce: event ]- And all the modelling widgets are free to respond to any window events by subscribing to the models windowAnnouncer, rather than registering blocks for value holders linked to single type changes. users of whenClosedDo: would instead do something like (usually in an initialize method where it's passed as a windowModel parameter) windowModel announcer when: WindowClosed do: aBlock and as such, the code that starts with self whenWindowChanged (I assume in the initialize method on a ComposableModel subclass?) window announcer when: WindowClosed do: [self clear] Cheers, Henry 1004

Nov. 17, 2014

Re: [Pharo-dev] ValueHolder analysis

by Henrik Johansen

> On 15 Nov 2014, at 10:41 , stepharo <stepharo(a)free.fr> wrote: > > initializePresenter > "Used to specify the subwidgets, and/or to bind them together" > "By default, do not do anything" > > extentHolder whenChangedDo: [:ex | > self widget ifNotNil: [:widget | > (widget respondsTo: #extent:) > ifTrue: [ widget extent: ex ]]]. > > > may be by design the ifNotNil should not be needed and the respondsTo too.... > > pffff. > I don't get it, doesn't the presenter already have an initialize: method that gets passed in its model? So a more "proper" thing to do is PresenterClassesThatCaresAboutExtent >> initializeFromModel: myModel myModel extentHolder when: ChangedValue do: [:ann | self extent: ann newValue] Cheers, Henry

Nov. 17, 2014

Re: [Pharo-dev] [Vm-dev] Reproducible VM crash with excessive garbage collection

by Max Leske

> On 17.11.2014, at 10:56, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-11-16 17:46 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > > Hi. > > I may have discovered a bug in the PharoVM (stable and latest), which may have been around for at least two years (I had a very similiar situation about two years ago with Fuel). > > I have a test that fails when a particular method contains â3 timesRepeat: [ Smalltalk garbageCollect ]â. In order to be sure that itâ not the #timesRepeat message thatâs causing the crash, I replaced that with multiple âSmalltalk garbageCollectâ sends. > > The test Iâm talking about ObsoleteTest>>testFixObsoleteSharedPools. To make the test crash the VM, simply add a couple of garbageCollects at the end of SmalltalkImage>>fixObsoleteSharedPools. I tried to come up with a little script to demonstrate the issue but I can only reproduce the problem with Nautilus (which makes me suspect that the problem is related to Nautilus). > > Steps to reproduce: > 1. get a fresh image and the latest vm: > curl get.pharo.org/40+vmLastest <http://get.pharo.org/40+vmLastest> | bash && ./pharo-ui Pharo.image > 2. open the class browser and navigate to SmalltalkImage>>fixObsoleteSharedPools > 3. Append ten âself garbageCollectâ statements to the method. > 4. navigate to ObsoleteTest>>testFixObsoleteSharedPools and click on the test runner icon to the left of the method name. > > I can reproduce this with the Mac VM (OS X 10.10) as well as with the linux VM (Ubuntu 12.04.1). > > Iâve opened an issue for this: https://pharo.fogbugz.com/f/cases/14478/Reproducible-VM-crash-with-excessiv… <https://pharo.fogbugz.com/f/cases/14478/Reproducible-VM-crash-with-excessiv…> > > > Cheers, > Max > > > Can not reproduce this on linux with may own vm build from an older version (on ubuntu 10.04) > > /home/nicolai/devel/pharo-vm/pharo-vm/results/pharo > NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 > NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 > https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> > > Unix built on Oct 14 2014 20:55:01 Compiler: 4.4.3 > VMMaker versionString https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> > NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 > NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 > > > reproducable on ubuntu 12.? 64 bit (32 bit latest vm): > --------------- > /home/nicolai/Downloads/pharo-vm/pharo > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 > https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 27d505ceffde98d854ed887903a2a94908637a49 Date: 2014-11-04 12:04:48 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> Jenkins build #14876 > > Unix built on Nov 13 2014 00:43:51 Compiler: 4.6.3 > VMMaker versionString https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 27d505ceffde98d854ed887903a2a94908637a49 Date: 2014-11-04 12:04:48 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> Jenkins build #14876 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 > > > both with image 40370 Thanks Nicolai

Nov. 17, 2014