Alien + MacVM + plugin/primitive error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Alien + MacVM + plugin/primitive error

Luc Fabresse
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
Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Igor Stasenko
On 4 February 2011 21:43, Luc Fabresse <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Luc Fabresse
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.


Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Igor Stasenko
On 4 February 2011 23:05, Luc Fabresse <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Igor Stasenko
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 <[hidden email]> wrote:

> On 4 February 2011 23:05, Luc Fabresse <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

EstebanLM
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 <[hidden email]> wrote:
On 4 February 2011 23:05, Luc Fabresse <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

EstebanLM
In reply to this post by Igor Stasenko

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
Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Luc Fabresse


2011/2/4 Esteban Lorenzano <[hidden email]>

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

Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Igor Stasenko
In reply to this post by EstebanLM
On 4 February 2011 23:17, Esteban Lorenzano <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

EstebanLM
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 <[hidden email]> 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Luc Fabresse
In reply to this post by Igor Stasenko


2011/2/4 Igor Stasenko <[hidden email]>
On 4 February 2011 23:17, Esteban Lorenzano <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Luc Fabresse
In reply to this post by EstebanLM


2011/2/4 Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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.
>



Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

David T. Lewis
In reply to this post by Igor Stasenko
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
 

Reply | Threaded
Open this post in threaded view
|

Re: Alien + MacVM + plugin/primitive error

Igor Stasenko
On 20 February 2011 22:44, David T. Lewis <[hidden email]> 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.