Dear pharoers, I tried to load a Pharo 2.0 on a Raspbian (with Phratch inside !). It works fine (the VM Squeak is already included in the Raspbian). I tried it with Pharo3.0 and it does not work. What changed in Pharo3.0 ? I know that some guys work on a PharoVM on a Raspbian. What is the status ? Thank you all. -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
On 16 Jan 2014, at 16:10, jannik laval <jannik.laval@gmail.com> wrote:
Dear pharoers,
I tried to load a Pharo 2.0 on a Raspbian (with Phratch inside !). It works fine (the VM Squeak is already included in the Raspbian).
I tried it with Pharo3.0 and it does not work. What changed in Pharo3.0 ?
There is this: https://pharo.fogbugz.com/f/cases/11869/NativeBoost-usage-in-PreferenceStart...
Thank you Marcus for the pointer. Jannik 2014/1/16 Marcus Denker <marcus.denker@inria.fr>
On 16 Jan 2014, at 16:10, jannik laval <jannik.laval@gmail.com> wrote:
Dear pharoers,
I tried to load a Pharo 2.0 on a Raspbian (with Phratch inside !). It works fine (the VM Squeak is already included in the Raspbian).
I tried it with Pharo3.0 and it does not work. What changed in Pharo3.0 ?
There is this:
https://pharo.fogbugz.com/f/cases/11869/NativeBoost-usage-in-PreferenceStart...
-- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
On 16 Jan 2014, at 16:10, jannik laval <jannik.laval@gmail.com> wrote:
Dear pharoers,
I tried to load a Pharo 2.0 on a Raspbian (with Phratch inside !). It works fine (the VM Squeak is already included in the Raspbian).
I tried it with Pharo3.0 and it does not work. What changed in Pharo3.0 ? I know that some guys work on a PharoVM on a Raspbian. What is the status ?
Thank you all.
I think it is really important to have Pharo 3.0 running on the Raspberry Pi. But I don't know what needs to happen. On a related note, what are these CI jobs ? https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Cog-Git-Tracker/ https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Cog-Git-Tracker-Devel... https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Compilation/ https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Compilation-FastBltBi... https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Cross-Compilation/ It seems that there is some effort under way... Sven
On 17 Jan 2014, at 15:01, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 16 Jan 2014, at 16:10, jannik laval <jannik.laval@gmail.com> wrote:
Dear pharoers,
I tried to load a Pharo 2.0 on a Raspbian (with Phratch inside !). It works fine (the VM Squeak is already included in the Raspbian).
I tried it with Pharo3.0 and it does not work. What changed in Pharo3.0 ? I know that some guys work on a PharoVM on a Raspbian. What is the status ?
Thank you all.
I think it is really important to have Pharo 3.0 running on the Raspberry Pi.
But I don't know what needs to happen.
is just to compile a NB Stack VM⦠with should be fairly straightforward⦠Esteban
On a related note, what are these CI jobs ?
https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Cog-Git-Tracker/ https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Cog-Git-Tracker-Devel... https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Compilation/ https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Compilation-FastBltBi... https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Cross-Compilation/
It seems that there is some effort under way...
Sven
On 17 Jan 2014, at 15:06, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
is just to compile a NB Stack VM⦠with should be fairly straightforwardâ¦
So that means there _is_ a working VM, right ? Where can we download it for testing ?
no, there isnât :) there are some (minor) changes to do to a StackVM and they are not done yet. AFAIK, is just change one or two methods and to add the NB Plugin. Esteban
On 17 Jan 2014, at 15:12, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 17 Jan 2014, at 15:06, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
is just to compile a NB Stack VM⦠with should be fairly straightforwardâ¦
So that means there _is_ a working VM, right ? Where can we download it for testing ?
no, there isnât :) there are some (minor) changes to do to a StackVM and they are not done yet.
AFAIK, is just change one or two methods and to add the NB Plugin.
I think many people are quite eager for this. So how many request does it take ? Who do we have to ask ? In any case, here is my request: Please, please, Dark Lords of the VM, can we please have a Pharo VM for 3.0 for the Raspberry Pi, please, please, please ... ;-) Anyone else ?
On 17 January 2014 15:24, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:12, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 17 Jan 2014, at 15:06, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
is just to compile a NB Stack VM⦠with should be fairly straightforwardâ¦
So that means there _is_ a working VM, right ? Where can we download it for testing ?
no, there isnât :) there are some (minor) changes to do to a StackVM and they are not done yet.
AFAIK, is just change one or two methods and to add the NB Plugin.
I think many people are quite eager for this.
So how many request does it take ? Who do we have to ask ?
In any case, here is my request:
Please, please, Dark Lords of the VM, can we please have a Pharo VM for 3.0 for the Raspberry Pi, please, please, please ...
forget about having NB on ARM. yes, you can easily make VM-side plugin working, but image-side code is not nearly ready to run on it, because there's no ARM assembler, no ARM calling convention(s) implemented whatever :) -- Best regards, Igor Stasenko.
On 17 Jan 2014, at 15:28, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 January 2014 15:24, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:12, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 17 Jan 2014, at 15:06, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
is just to compile a NB Stack VM⦠with should be fairly straightforwardâ¦
So that means there _is_ a working VM, right ? Where can we download it for testing ?
no, there isnât :) there are some (minor) changes to do to a StackVM and they are not done yet.
AFAIK, is just change one or two methods and to add the NB Plugin.
I think many people are quite eager for this.
So how many request does it take ? Who do we have to ask ?
In any case, here is my request:
Please, please, Dark Lords of the VM, can we please have a Pharo VM for 3.0 for the Raspberry Pi, please, please, please ...
forget about having NB on ARM. yes, you can easily make VM-side plugin working, but image-side code is not nearly ready to run on it, because there's no ARM assembler, no ARM calling convention(s) implemented whatever :)
oh, crap⦠I confused the architecture (I should think before answer mails, he). Yes⦠there is a problem with that. What we need is to make NB not mandatory in Pharo3 (right now there are problems with that), and we will. Pavel had some work on that direction that we want to integrate soon :) Esteban
-- Best regards, Igor Stasenko.
JB? Soon in the blog close to you :) Hi, We compile the StackVM now for RaspberryPi based on a Raspbian os. In order to do that you have to: - get your image - prepare your RaspberryPi or your cross compile environment - and compile First step, the VMMaker image: Here is the link to the source (basically the job just prepare the source and a image): https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cog-... You will found a preconfigured image in the image folder. If you want to create your own and not just extend this one, you need to clone the pharo-vm git repository: https://github.com/pharo-project/pharo-vm all the used source code is in mc use the filetree in montecello. Second Step Preparing the Raspberry: I used the linux source (raspbian), Then you can recompile using a RaspberryPi (what I do), but you need to follow Nick instruction for install all the required dependencies on the RaspberryPi: " On the raspberry PI: # install build tools sudo apt-get install gcc g++ cmake # dependencies for vm plugins sudo apt-get install libasound2-dev libssl-dev libfreetype6-dev libgl1-mesa-dev sudo apt-get install build-essential # to fix: # /usr/bin/ld: cannot find -lSM #/usr/bin/ld: cannot find -lICE # create the following links in: /usr/lib/arm-linux-gnueabihf/ sudo ln -s libSM.so.6 libSM.so sudo ln -s libICE.so.6 libICE.so Once the source is installed: chmod +x platforms/unix/config/version chmod +x platforms/unix/config/verstamp " Then compile: I have done a configuration to generate VM on raspbian. StackRaspbianConfig, you need to subclass and add your plugin + configure Cmake as you want. "YourSubclass generate" and recompile (cmake . & make from a terminal in build folder) on the Raspberry Pi, it should work. My jenkins job actually take the last version of the source VM, and it is able to rebuild it on RaspPi. You can cross-compile but I do not explore that way. I hope that help you. ========Second mail I will explain everything. First of all the StackVM on rbp now work only on headless mode but soon the fast bltbit will be introduce. The main issue is you cannot develop directly on raspberryPi for now. You need to develop on another os for prepare the environment and then push it on your raspberryPi for compile (I have a job jenkins to do that). You need to do newImage.sh, but this will not work on raspberry pi. For create your generator image. In this image load you own source. (with your configuration and plugin). You can use this image to generate vm, try to do not keep this image for keeping your vm up to date. after that you need to: - first generate source in by doing: "YourConfigSubclass new generateSources.". but this step is really long If you do on raspberry pi, but you can do on raspberry pi, you can also do this step before send the source on the Rasp (what i do to save time). - second you need to generate CMakeFile. That step should be perform on RaspPi The process required a working vm, Here is a working vm for RaspberryPi on Raspbian: https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp... As you cannot run the VM with UI So, you need to run a script.st like this one. echo " YourConfigSubclass new generate. Smalltalk snapshot: false andQuit: true." > ./script.st execute like that in a shell: ./StackVM -vm-display-null generator.image script.st - third step: build. in build folder do: sh build.sh RaspberryPi is slow for recompiling everything. Maybe a solution for develop faster is to cross-compile but as I say I do not explore that way. If you have any problem you can give me feedback On 17 Jan 2014, at 15:24, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:12, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 17 Jan 2014, at 15:06, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
is just to compile a NB Stack VM⦠with should be fairly straightforwardâ¦
So that means there _is_ a working VM, right ? Where can we download it for testing ?
no, there isnât :) there are some (minor) changes to do to a StackVM and they are not done yet.
AFAIK, is just change one or two methods and to add the NB Plugin.
I think many people are quite eager for this.
So how many request does it take ? Who do we have to ask ?
In any case, here is my request:
Please, please, Dark Lords of the VM, can we please have a Pharo VM for 3.0 for the Raspberry Pi, please, please, please ...
;-)
Anyone else ?
Who is JB ? On 17 Jan 2014, at 21:03, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Here is a working vm for RaspberryPi on Raspbian: https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp...
Well, I tried this download: https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp... and we're soo close (I think) to running 3.0 (headless at least): pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval '1+2' Error: Can't find the requested origin UnixResolver(PlatformResolver)>>cantFindOriginError UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ] BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: PrimitiveFailed(Exception)>>signal PrimitiveFailed class(SelectorException class)>>signalFor: NativeBoost class(Object)>>primitiveFailed: NativeBoost class(Object)>>primitiveFailed NativeBoost class>>isEnabled NativeBoost class>>forCurrentPlatform NativeBoost class>>CLibrary NixEnvironment(OSEnvironment)>>getEnv: NixEnvironment(OSEnvironment)>>at:ifAbsent: NixEnvironment(OSEnvironment)>>at: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ Smalltalk os environment at: aString ] BlockClosure>>on:do: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: UnixResolver>>home UnixResolver>>preferences in Block: [ self home / '.config' ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ] BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: PrimitiveFailed(Exception)>>signal PrimitiveFailed class(SelectorException class)>>signalFor: ;-)
Btw, to reduce the pain, i propose to introduce: NativeBoost isAvailable protocol. The implementation is simple, since primitiveIsEnabled fails only if it not exists (else it returns true or false), do a following: isAvailable ^ self primIsAvailable notNil primIsAvailable "Answer flag indicating whether running a native code enabled by plugin" <primitive: #primitiveIsEnabled module: #NativeBoostPlugin> ^ nil Then you can easily implement a fallback mechanisms, if NB is not avail. On 17 January 2014 23:07, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
There is already NativeBoost class>>#isEnabledOrNil On 17 Jan 2014, at 23:12, Igor Stasenko <siguctua@gmail.com> wrote:
Btw, to reduce the pain, i propose to introduce:
NativeBoost isAvailable
protocol.
The implementation is simple, since primitiveIsEnabled fails only if it not exists (else it returns true or false), do a following:
isAvailable ^ self primIsAvailable notNil
so this could become ^ self isEnabledOrNil notNil
primIsAvailable "Answer flag indicating whether running a native code enabled by plugin" <primitive: #primitiveIsEnabled module: #NativeBoostPlugin>
^ nil
Then you can easily implement a fallback mechanisms, if NB is not avail.
But we would still have to write the fallback code, right ;-)
On 17 January 2014 23:07, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 17 January 2014 23:19, Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is already NativeBoost class>>#isEnabledOrNil
oh.. right..
On 17 Jan 2014, at 23:12, Igor Stasenko <siguctua@gmail.com> wrote:
Btw, to reduce the pain, i propose to introduce:
NativeBoost isAvailable
protocol.
The implementation is simple, since primitiveIsEnabled fails only if it not exists (else it returns true or false), do a following:
isAvailable ^ self primIsAvailable notNil
so this could become
^ self isEnabledOrNil notNil
primIsAvailable "Answer flag indicating whether running a native code enabled by plugin" <primitive: #primitiveIsEnabled module: #NativeBoostPlugin>
^ nil
Then you can easily implement a fallback mechanisms, if NB is not avail.
But we would still have to write the fallback code, right ;-)
On 17 January 2014 23:07, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
+1 On 17 Jan 2014, at 23:12, Igor Stasenko <siguctua@gmail.com> wrote:
Btw, to reduce the pain, i propose to introduce:
NativeBoost isAvailable
protocol.
The implementation is simple, since primitiveIsEnabled fails only if it not exists (else it returns true or false), do a following:
isAvailable ^ self primIsAvailable notNil
primIsAvailable "Answer flag indicating whether running a native code enabled by plugin" <primitive: #primitiveIsEnabled module: #NativeBoostPlugin>
^ nil
Then you can easily implement a fallback mechanisms, if NB is not avail.
On 17 January 2014 23:07, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
+ 1. And for Seed that can be helpful too. On 18 Jan 2014, at 09:08, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1 On 17 Jan 2014, at 23:12, Igor Stasenko <siguctua@gmail.com> wrote:
Btw, to reduce the pain, i propose to introduce:
NativeBoost isAvailable
protocol.
The implementation is simple, since primitiveIsEnabled fails only if it not exists (else it returns true or false), do a following:
isAvailable ^ self primIsAvailable notNil
primIsAvailable "Answer flag indicating whether running a native code enabled by plugin" <primitive: #primitiveIsEnabled module: #NativeBoostPlugin>
^ nil
Then you can easily implement a fallback mechanisms, if NB is not avail.
On 17 January 2014 23:07, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
On 17 Jan 2014, at 23:07, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
Good to know. Thanks Jean-Baptiste !
One of the problem we are thinking about now is the FFI on ARM (alien or not alien)â¦.
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
Good to know.
Thanks Jean-Baptiste !
On 18 Jan 2014, at 09:09, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
One of the problem we are thinking about now is the FFI on ARM (alien or not alien)â¦. +1, we need to think the, best solution is to have NativeBoost on ARM. We need an agreement between, time to develop and usage. Maybe first I should fix Alien or FFI. Then one day, port Nativeboost on ARM.
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
Oh, for real, I'm flattered.
Good to know.
Thanks Jean-Baptiste !
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
Hi Jean-Baptiste, On Mon, Jan 20, 2014 at 7:25 AM, Jean Baptiste Arnaud < jbaptiste.arnaud@gmail.com> wrote:
On 18 Jan 2014, at 09:09, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
One of the problem we are thinking about now is the FFI on ARM (alien or not alien)â¦.
+1, we need to think the, best solution is to have NativeBoost on ARM. We need an agreement between, time to develop and usage. Maybe first I should fix Alien or FFI. Then one day, port Nativeboost on ARM.
Did you see the thread on vm-dev about the ARM FFI? When I wrote the FFI-replacement ThreadedFFIPlugin (which is the standard FFI plugin in Cog) I added stubs for ARM and PowerPC. I hope that Doug McPherson is going to be able to fully implement these stubs. If you're interested perhaps you could collaborate? I'm confident that the effort involved in getting this going is a week or two at most. Days for someone who well understands alloca and the ARM ABI. On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
Oh, for real, I'm flattered.
Good to know.
Thanks Jean-Baptiste !
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
-- best, Eliot
On 20 Jan 2014, at 23:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Jean-Baptiste,
On Mon, Jan 20, 2014 at 7:25 AM, Jean Baptiste Arnaud <jbaptiste.arnaud@gmail.com> wrote:
On 18 Jan 2014, at 09:09, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
One of the problem we are thinking about now is the FFI on ARM (alien or not alien)â¦.
+1, we need to think the, best solution is to have NativeBoost on ARM. We need an agreement between, time to develop and usage. Maybe first I should fix Alien or FFI. Then one day, port Nativeboost on ARM.
Did you see the thread on vm-dev about the ARM FFI? When I wrote the FFI-replacement ThreadedFFIPlugin (which is the standard FFI plugin in Cog) I added stubs for ARM and PowerPC. I hope that Doug McPherson is going to be able to fully implement these stubs. If you're interested perhaps you could collaborate? I'm confident that the effort involved in getting this going is a week or two at most. Days for someone who well understands alloca and the ARM ABI.
Yes it would be good to collaborate. Stef
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
Oh, for real, I'm flattered.
Good to know.
Thanks Jean-Baptiste !
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
-- best, Eliot
Yes it would be good to collaborate.
I agree. On 21 Jan 2014, at 09:07, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On 20 Jan 2014, at 23:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Jean-Baptiste,
On Mon, Jan 20, 2014 at 7:25 AM, Jean Baptiste Arnaud <jbaptiste.arnaud@gmail.com> wrote:
On 18 Jan 2014, at 09:09, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
One of the problem we are thinking about now is the FFI on ARM (alien or not alien)â¦.
+1, we need to think the, best solution is to have NativeBoost on ARM. We need an agreement between, time to develop and usage. Maybe first I should fix Alien or FFI. Then one day, port Nativeboost on ARM.
Did you see the thread on vm-dev about the ARM FFI? When I wrote the FFI-replacement ThreadedFFIPlugin (which is the standard FFI plugin in Cog) I added stubs for ARM and PowerPC. I hope that Doug McPherson is going to be able to fully implement these stubs. If you're interested perhaps you could collaborate? I'm confident that the effort involved in getting this going is a week or two at most. Days for someone who well understands alloca and the ARM ABI.
I see it, It is what I speak about when I speak about "fix" FFI, fill the stub. I can collaborate with Doug to fill it, it would be good.
Yes it would be good to collaborate.
Stef
On 17 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote: Who is JB ?
Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry.
Oh, for real, I'm flattered.
Good to know.
Thanks Jean-Baptiste !
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
-- best, Eliot
you need to subclass NewObjectMemory to override growObjectMemory: delta (see it in NBCoObjectMemory) to enable object memory to be executable you need to subclass from StackInterpreter to override initStackPagesAndInterpret to enable object memory to be executable and to use new object memory class. basically, same sort of changes what i did for NBCoInterpreter, when adapting NB plugin for Cog. On 17 January 2014 15:12, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 17 Jan 2014, at 15:06, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2014, at 15:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
is just to compile a NB Stack VM⦠with should be fairly straightforwardâ¦
So that means there _is_ a working VM, right ? Where can we download it for testing ?
no, there isnât :) there are some (minor) changes to do to a StackVM and they are not done yet.
AFAIK, is just change one or two methods and to add the NB Plugin.
Esteban
-- Best regards, Igor Stasenko.
participants (8)
-
Eliot Miranda -
Esteban Lorenzano -
Igor Stasenko -
jannik laval -
Jean Baptiste Arnaud -
Marcus Denker -
Stéphane Ducasse -
Sven Van Caekenberghe