[Pharo-project] Alien + MacVM + plugin/primitive error
Hi Guys, Jannik pointed an interesting problem. If I load Alien in both 1.1 or 1.2. Gofer it squeaksource: 'MetacelloRepository' ; package: 'ConfigurationOfAlien'; load. ((Smalltalk globals at: #ConfigurationOfAlien) project version: 'Pharo 1.1') load: {'All'. 'MacOSX'} - with the MacVM 4.2.5beta1U => 40 tests green (it works) - with the MacVM 5.7.4 => 20 tests green and 20 errors (can't call a simple external function) it seems that the I32ABI plugin is not loaded correctly. AlienLibrary>>primLoadLibrary: 'IA32ABI' failed. Any clue to make it work in the MacVM 5.7.4? #Luc
On 4 February 2011 21:43, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Guys, Â Jannik pointed an interesting problem.
 If I load Alien in both 1.1 or 1.2.
 Gofer it squeaksource: 'MetacelloRepository' ;  package: 'ConfigurationOfAlien'; load. ((Smalltalk globals at: #ConfigurationOfAlien) project version: 'Pharo 1.1') load: {'All'. 'MacOSX'}  - with the MacVM 4.2.5beta1U => 40 tests green (it works)  - with the MacVM 5.7.4 => 20 tests green and 20 error (can't call a simple external function)  it seems that the I32ABI plugin is not loaded correctly.  AlienLibrary>>primLoadLibrary: 'IA32ABI' failed.
is it internal or external?
 Any clue to make it work in the MacVM 5.7.4?
Yes, build & debug your own (joking). My plate is full, and Esteban's too i guess... but i added this to my todo list anyways.
#Luc
-- Best regards, Igor Stasenko AKA sig.
Hi Igor, Esteban said that he has integrated the plugin as internal. And I suspect that it is the main problem for the tests because the image code tries to load the the plugin. He just gave me the infos to compile my own VM. So I will have a look .... and learn ;-) Thx, #Luc
Any clue to make it work in the MacVM 5.7.4?
Yes, build & debug your own (joking). My plate is full, and Esteban's too i guess... but i added this to my todo list anyways.
#Luc
-- Best regards, Igor Stasenko AKA sig.
On 4 February 2011 23:05, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Igor, Â Esteban said that he has integrated the plugin as internal. Â And I suspect that it is the main problem for the tests because the image code tries to load the the plugin.
yes. most probably this is why they fail, because can't find the .dll symbol lookup in main module is different comparing to external lib.
 He just gave me the infos to compile my own VM.  So I will have a look ....  and learn ;-)
Thx, #Luc
-- Best regards, Igor Stasenko AKA sig.
btw, this could be avoided by checking that module is internal (using Smalltalk listBuiltinModules), so then don't run tests that depending on plugin being external On 4 February 2011 23:09, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 February 2011 23:05, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Igor, Â Esteban said that he has integrated the plugin as internal. Â And I suspect that it is the main problem for the tests because the image code tries to load the the plugin.
yes. most probably this is why they fail, because can't  find the .dll symbol lookup in main module is different comparing to external lib.
 He just gave me the infos to compile my own VM.  So I will have a look ....  and learn ;-)
Thx, #Luc
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
oops... the answer to Luc was also for all the list... not private intention, just wrong button pressed. I'm coping here again... sorry :) Hi Luc, cool you are willing to help :) in 5.7.4 alien is integrated to the vm... so you need to download latest version from here: http://gitorious.org/~estebanlm/squeak-vm/cocoa-osx and should compile out of the box. The project is platforms/iOS/vm/SqueakPureObjc.xcodeproj there is a PharoDev 1.1.1 with every thing loaded there (under ./image) To generate the files as expected, you can execute CMakeGenScripts generateCocoaVM. ...and that's all :) btw... in my Alien-MacOS, I needed to fix some things (on the native code, not yet merged into trunk), and now -in my tests- everything looks like working, but not the tests... it fails loading a library, maybe because the library is not there (as it is an integrated module)... I didn't spend time fixing the tests yet :( Cheers, Esteban El 04/02/2011, a las 7:12p.m., Igor Stasenko escribió:
btw, this could be avoided by checking
that module is internal (using Smalltalk listBuiltinModules), so then don't run tests that depending on plugin being external
On 4 February 2011 23:09, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 February 2011 23:05, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Igor, Esteban said that he has integrated the plugin as internal. And I suspect that it is the main problem for the tests because the image code tries to load the the plugin.
yes. most probably this is why they fail, because can't find the .dll symbol lookup in main module is different comparing to external lib.
He just gave me the infos to compile my own VM. So I will have a look .... and learn ;-)
Thx, #Luc
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 4 February 2011 23:17, Esteban Lorenzano <estebanlm@gmail.com> wrote:
oops... the answer to Luc was also for all the list... not private intention, just wrong button pressed. I'm coping here again... sorry :) Hi Luc, cool you are willing to help :) in 5.7.4 alien is integrated to the vm... so you need to download latest version from here: http://gitorious.org/~estebanlm/squeak-vm/cocoa-osx and should compile out of the box. The project is platforms/iOS/vm/SqueakPureObjc.xcodeproj there is a PharoDev 1.1.1 with every thing loaded there (under ./image) To generate the files as expected, you can execute CMakeGenScripts generateCocoaVM. ...and that's all :)
btw, Esteban, check out the latest CMakeVMMaker package. I trying to invent somewhat more convenient protocol for this.. help me :) So, what i did is made each CPlatformConfig subclasses to answer #generate (to generate config only) and #generateWithSource (to generate vmmaker sources and then config) because it is logical, that each config knows how to generate itself (StackVMConfig knows which VM sources it should use etc). So, i think this script (#generateCocoaVM) should be put into CocoaIOSConfig or one of its subclasses >> #generateSourceFiles method as well as many other CMakeGenScripts >> generateXXXX, So then we could use something simple , like: CogUnixConfig generate[WithSources] CocoaIOSConfig generate[WithSources] i.e. pick config which you wanna use and do the rest automatically :) P.S. i hope someday we could even run builds using OSProcessPlugin directly from image by issuing: ABCDEblablaConfig build :)
btw... in my Alien-MacOS, I needed to fix some things (on the native code, not yet merged into trunk), and now -in my tests- everything looks like working, but not the tests... it fails loading a library, maybe because the library is not there (as it is an integrated module)... I didn't spend time fixing the tests yet :( Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
btw... since you are working with Alien, I just commit my refactor of Alien-MacOS package (just in case) is not yet fully functional, but it is "almost there" Cheers, Esteban El 04/02/2011, a las 7:41p.m., Igor Stasenko escribió:
On 4 February 2011 23:17, Esteban Lorenzano <estebanlm@gmail.com> wrote:
oops... the answer to Luc was also for all the list... not private intention, just wrong button pressed. I'm coping here again... sorry :) Hi Luc, cool you are willing to help :) in 5.7.4 alien is integrated to the vm... so you need to download latest version from here: http://gitorious.org/~estebanlm/squeak-vm/cocoa-osx and should compile out of the box. The project is platforms/iOS/vm/SqueakPureObjc.xcodeproj there is a PharoDev 1.1.1 with every thing loaded there (under ./image) To generate the files as expected, you can execute CMakeGenScripts generateCocoaVM. ...and that's all :)
btw, Esteban, check out the latest CMakeVMMaker package. I trying to invent somewhat more convenient protocol for this.. help me :)
So, what i did is made each CPlatformConfig subclasses to answer #generate (to generate config only) and #generateWithSource (to generate vmmaker sources and then config)
because it is logical, that each config knows how to generate itself (StackVMConfig knows which VM sources it should use etc).
So, i think this script (#generateCocoaVM) should be put into CocoaIOSConfig or one of its subclasses >> #generateSourceFiles method as well as many other CMakeGenScripts >> generateXXXX,
So then we could use something simple , like:
CogUnixConfig generate[WithSources] CocoaIOSConfig generate[WithSources]
i.e. pick config which you wanna use and do the rest automatically :)
P.S. i hope someday we could even run builds using OSProcessPlugin directly from image by issuing:
ABCDEblablaConfig build
:)
btw... in my Alien-MacOS, I needed to fix some things (on the native code, not yet merged into trunk), and now -in my tests- everything looks like working, but not the tests... it fails loading a library, maybe because the library is not there (as it is an integrated module)... I didn't spend time fixing the tests yet :( Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
2011/2/4 Esteban Lorenzano <estebanlm@gmail.com>
btw... since you are working with Alien, I just commit my refactor of Alien-MacOS package (just in case) is not yet fully functional, but it is "almost there"
Thanks. #Luc
Cheers, Esteban
El 04/02/2011, a las 7:41p.m., Igor Stasenko escribió:
On 4 February 2011 23:17, Esteban Lorenzano <estebanlm@gmail.com> wrote:
oops... the answer to Luc was also for all the list... not private intention, just wrong button pressed. I'm coping here again... sorry :) Hi Luc, cool you are willing to help :) in 5.7.4 alien is integrated to the vm... so you need to download latest version from here: http://gitorious.org/~estebanlm/squeak-vm/cocoa-osxand should compile out of the box. The project is platforms/iOS/vm/SqueakPureObjc.xcodeproj there is a PharoDev 1.1.1 with every thing loaded there (under ./image) To generate the files as expected, you can execute CMakeGenScripts generateCocoaVM. ...and that's all :)
btw, Esteban, check out the latest CMakeVMMaker package. I trying to invent somewhat more convenient protocol for this.. help me :)
So, what i did is made each CPlatformConfig subclasses to answer #generate (to generate config only) and #generateWithSource (to generate vmmaker sources and then config)
because it is logical, that each config knows how to generate itself (StackVMConfig knows which VM sources it should use etc).
So, i think this script (#generateCocoaVM) should be put into CocoaIOSConfig or one of its subclasses >> #generateSourceFiles method as well as many other CMakeGenScripts >> generateXXXX,
So then we could use something simple , like:
CogUnixConfig generate[WithSources] CocoaIOSConfig generate[WithSources]
i.e. pick config which you wanna use and do the rest automatically :)
P.S. i hope someday we could even run builds using OSProcessPlugin directly from image by issuing:
ABCDEblablaConfig build
:)
btw... in my Alien-MacOS, I needed to fix some things (on the native code, not yet merged into trunk), and now -in my tests- everything looks like working, but not the tests... it fails loading a library, maybe because the library is not there (as it is an integrated module)... I didn't spend time fixing the tests yet :( Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
2011/2/4 Igor Stasenko <siguctua@gmail.com>
On 4 February 2011 23:17, Esteban Lorenzano <estebanlm@gmail.com> wrote:
oops... the answer to Luc was also for all the list... not private intention, just wrong button pressed. I'm coping here again... sorry :) Hi Luc, cool you are willing to help :) in 5.7.4 alien is integrated to the vm... so you need to download latest version from here: http://gitorious.org/~estebanlm/squeak-vm/cocoa-osx and should compile out of the box. The project is platforms/iOS/vm/SqueakPureObjc.xcodeproj there is a PharoDev 1.1.1 with every thing loaded there (under ./image) To generate the files as expected, you can execute CMakeGenScripts generateCocoaVM. ...and that's all :)
btw, Esteban, check out the latest CMakeVMMaker package. I trying to invent somewhat more convenient protocol for this.. help me :)
So, what i did is made each CPlatformConfig subclasses to answer #generate (to generate config only) and #generateWithSource (to generate vmmaker sources and then config)
because it is logical, that each config knows how to generate itself (StackVMConfig knows which VM sources it should use etc).
So, i think this script (#generateCocoaVM) should be put into CocoaIOSConfig or one of its subclasses >> #generateSourceFiles method as well as many other CMakeGenScripts >> generateXXXX,
So then we could use something simple , like:
CogUnixConfig generate[WithSources] CocoaIOSConfig generate[WithSources]
i.e. pick config which you wanna use and do the rest automatically :)
P.S. i hope someday we could even run builds using OSProcessPlugin directly from image by issuing:
ABCDEblablaConfig build
:)
yes and with Coral (Pharo system scripting) ;-) #Luc
btw... in my Alien-MacOS, I needed to fix some things (on the native code, not yet merged into trunk), and now -in my tests- everything looks like working, but not the tests... it fails loading a library, maybe because the library is not there (as it is an integrated module)... I didn't spend time fixing the tests yet :( Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
On Fri, Feb 04, 2011 at 11:41:51PM +0100, Igor Stasenko wrote:
P.S. i hope someday we could even run builds using OSProcessPlugin directly from image by issuing:
ABCDEblablaConfig build
:)
Hi Igor, Actually I used to do that exactly for my own unix builds (circa 2002 or so). I'm afraid that I have not kept it up to date, but you can see how it worked in CommandShell class: makeVmIn: buildDirectoryPathName "Rebuild the virtual machine and plugins in the buildDirectoryPathName directory. If the build is successful, save the image and restart using the new VM. This assumes that the currently executing VM is either located in, or linked to, the buildDirectoryPathName directory." I think it would be easy to do something similar for CMakerVMMaker builds. I'll be glad to help if you want to give it a try. Dave
On 20 February 2011 22:44, David T. Lewis <lewis@mail.msen.com> wrote:
On Fri, Feb 04, 2011 at 11:41:51PM +0100, Igor Stasenko wrote:
P.S. i hope someday we could even run builds using OSProcessPlugin directly from image by issuing:
ABCDEblablaConfig  build
:)
Hi Igor,
Actually I used to do that exactly for my own unix builds (circa 2002 or so). I'm afraid that I have not kept it up to date, but you can see how it worked in CommandShell class:
makeVmIn: buildDirectoryPathName     "Rebuild the virtual machine and plugins in the buildDirectoryPathName     directory. If the build is successful, save the image and restart using the     new VM. This assumes that the currently executing VM is either located in,     or linked to, the buildDirectoryPathName directory."
I think it would be easy to do something similar for CMakerVMMaker builds. I'll be glad to help if you want to give it a try.
Fortunately cmake does things quite nicely. What i like about it, that it allows to avoid dealing with shell scripting :) But still, writing actions in normal language (anything except shell syntax) is much more useful, because it is easy to understand what it does. I work on *nixes more than 10 years, and still i feel very bad when i need to write some shell script or makefile. Its is awful DSL with mix of shell commands and programs, each having tons of arguments... It is hard to write scripts, but it is even harder and time consuming to understand what it does when written not by you. It would be nice, for instance to tell image to generate and build external plugin or other modules. Yes, i'd like to have it written in smalltalk.. so we can control every aspect of building VM. But it means rewriting most of the parts what cmake does.. Sure thing we might don't need too fancy functionality.. But still this is much of work.
Dave
-- Best regards, Igor Stasenko AKA sig.
El 04/02/2011, a las 7:12p.m., Igor Stasenko escribió:
btw, this could be avoided by checking
that module is internal (using Smalltalk listBuiltinModules), so then don't run tests that depending on plugin being external
No, I don't think this is the right path... better to be able to do different loadings if it's internal or external, but execute the tests in both cases :) Or much better, compile alien plugin as a dylib, not all integrated. Of course, to do this we need time... and time is not all around lately... but soon or later I will be doing all of this ;) best, Esteban
2011/2/4 Esteban Lorenzano <estebanlm@gmail.com>
El 04/02/2011, a las 7:12p.m., Igor Stasenko escribió:
btw, this could be avoided by checking
that module is internal (using Smalltalk listBuiltinModules), so then don't run tests that depending on plugin being external
No, I don't think this is the right path... better to be able to do different loadings if it's internal or external, but execute the tests in both cases :) Or much better, compile alien plugin as a dylib, not all integrated. Of course, to do this we need time... and time is not all around lately... but soon or later I will be doing all of this ;)
yes, I agree that tests should be always executed. The Alien code should be fixed to run smoothly even if the plugin is internal. But, as Bert said it would be better for security reasons to have the Alien plugin as an external one. So I think will try to generate it as external and make the tests pass. Cheers, #Luc
best, Esteban
participants (4)
-
David T. Lewis -
Esteban Lorenzano -
Igor Stasenko -
Luc Fabresse