Smalltalk › Squeak › Squeak VM

issues integrating Eliot latest version with cocoa

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

EstebanLM

issues integrating Eliot latest version with cocoa

Hi,

Sorry guys, I need some help here :P

I'm finally taking the task of integrating latest changes from Eliot into my builds (and also, all jenkins builds)... I don't know anything about this, but I'm learning (consider this as a warning: my first integration cycles obviously will have problems)...
Well... right now I merged all the external sources in a way "it seems" to be ok, and I started merge VMMaker.oscog with VMMaker-oscog and it looked more or less straight forward making me suspect that I'm doing something wrong... but ok... I'm trying, isn't? so, let's break things :)
Anyway... once I merged the code, I started with a couple of issues:

1) headers are being generated with __builtInfo[] which throws an annoying "duplicated definition" error... I suppose with some link flag or something I can skip this problem, but I'm lazy... anyone knows?

2) This is most important: LargeIntegersPlugins is being generated with an error, here:

LargeIntegersPlugin>>digitAddLarge:with:
...
over > 0
ifTrue:
["sum := sum growby: 1."
interpreterProxy remapOop: sum in: [newSum := interpreterProxy instantiateClass: resClass indexableSize: longLen + 1].
...

it complains because as it is using interpreterProxy as receiver of #remapOop:in:, and it does not exists in the struct.
if I replace "interpreterProxy" with just "self" it looks like doing right and compiling...
I think this is a bug introduced in LargeIntegersPlugin because of latest changes... but I'm not sure and maybe is because of my integration.

welll... tweaking this two issues I'm compiling and opening an image... and pharo tests runs just like before...

but:

3) I have an error compiling FFI plugin: it is generating a "halt" function which is already present (as macros). I don't know why it is being generated... I think that it shouldn't, but I don't know how to prevent that.

If I can fix this (I touched some things in the code to test it), the integration seems to work (of course, I don't know if it *really* work). My masterplan is to have a first version working, then invite you to test it... then continue working, as always :)

Thanks,
Esteban

Eliot Miranda-2

Re: issues integrating Eliot latest version with cocoa

On Wed, Nov 9, 2011 at 2:52 PM, Esteban Lorenzano <[hidden email]> wrote:

Hi,

Sorry guys, I need some help here :P

I'm finally taking the task of integrating latest changes from Eliot into my builds (and also, all jenkins builds)... I don't know anything about this, but I'm learning (consider this as a warning: my first integration cycles obviously will have problems)...
Well... right now I merged all the external sources in a way "it seems" to be ok, and I started merge VMMaker.oscog with VMMaker-oscog and it looked more or less straight forward making me suspect that I'm doing something wrong... but ok... I'm trying, isn't? so, let's break things :)
Anyway... once I merged the code, I started with a couple of issues:

1) headers are being generated with __builtInfo[] which throws an annoying "duplicated definition" error... I suppose with some link flag or something I can skip this problem, but I'm lazy... anyone knows?

__buildInfo should be static, e.g.

src/vm/gcc3x-cointerp.c:static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.137 uuid: fbe64d98-6b1a-4c5b-b3f3-d2b1091406dc " __DATE__ ;

2) This is most important: LargeIntegersPlugins is being generated with an error, here:

LargeIntegersPlugin>>digitAddLarge:with:
...
over > 0
ifTrue:
["sum := sum growby: 1."
interpreterProxy remapOop: sum in: [newSum := interpreterProxy instantiateClass: resClass indexableSize: longLen + 1].
...

it complains because as it is using interpreterProxy as receiver of #remapOop:in:, and it does not exists in the struct.
if I replace "interpreterProxy" with just "self" it looks like doing right and compiling...
I think this is a bug introduced in LargeIntegersPlugin because of latest changes... but I'm not sure and maybe is because of my integration.

welll... tweaking this two issues I'm compiling and opening an image... and pharo tests runs just like before...

LargeIntegersPlugin should be generated with SmartSyntaxPluginCodeGenerator since

SmartSyntaxInterpreterPlugin subclass: #LargeIntegersPlugin

instanceVariableNames: 'andOpIndex orOpIndex xorOpIndex'

classVariableNames: ''

poolDictionaries: ''

category: 'VMMaker-Plugins'

and in SmartSyntaxPluginCodeGenerator>initializeCTranslationDictionary is

#remapOop:in: #generateRemapOopIn:on:indent:

and SmartSyntaxPluginCodeGenerator>generateRemapOopIn:on:indent: maps remapOop:in: to calls of pushRemappableOop and popRemappableOop.

but:

3) I have an error compiling FFI plugin: it is generating a "halt" function which is already present (as macros). I don't know why it is being generated... I think that it shouldn't, but I don't know how to prevent that.

I nuked the macro definition of halt in sqAssert.h in r2490.

If I can fix this (I touched some things in the code to test it), the integration seems to work (of course, I don't know if it *really* work). My masterplan is to have a first version working, then invite you to test it... then continue working, as always :)

Thanks,
Esteban

HTH

Eliot

--
best,

Eliot

EstebanLM

Re: issues integrating Eliot latest version with cocoa

Hi,

El 09/11/2011, a las 8:42p.m., Eliot Miranda escribió:

On Wed, Nov 9, 2011 at 2:52 PM, Esteban Lorenzano <[hidden email]> wrote:

Hi,

Sorry guys, I need some help here :P

I'm finally taking the task of integrating latest changes from Eliot into my builds (and also, all jenkins builds)... I don't know anything about this, but I'm learning (consider this as a warning: my first integration cycles obviously will have problems)...
Well... right now I merged all the external sources in a way "it seems" to be ok, and I started merge VMMaker.oscog with VMMaker-oscog and it looked more or less straight forward making me suspect that I'm doing something wrong... but ok... I'm trying, isn't? so, let's break things :)
Anyway... once I merged the code, I started with a couple of issues:

1) headers are being generated with __builtInfo[] which throws an annoying "duplicated definition" error... I suppose with some link flag or something I can skip this problem, but I'm lazy... anyone knows?

__buildInfo should be static, e.g.

src/vm/gcc3x-cointerp.c:static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.137 uuid: fbe64d98-6b1a-4c5b-b3f3-d2b1091406dc " __DATE__ ;

yes, they are... but as they are being generated on .c files and some headers... (like interp.h), I have collisions... again, this is likely because my ignorance of gcc compiler directives...

2) This is most important: LargeIntegersPlugins is being generated with an error, here:

LargeIntegersPlugin>>digitAddLarge:with:
...
over > 0
ifTrue:
["sum := sum growby: 1."
interpreterProxy remapOop: sum in: [newSum := interpreterProxy instantiateClass: resClass indexableSize: longLen + 1].
...

it complains because as it is using interpreterProxy as receiver of #remapOop:in:, and it does not exists in the struct.
if I replace "interpreterProxy" with just "self" it looks like doing right and compiling...
I think this is a bug introduced in LargeIntegersPlugin because of latest changes... but I'm not sure and maybe is because of my integration.

welll... tweaking this two issues I'm compiling and opening an image... and pharo tests runs just like before...

LargeIntegersPlugin should be generated with SmartSyntaxPluginCodeGenerator since

SmartSyntaxInterpreterPlugin subclass: #LargeIntegersPlugin
instanceVariableNames: 'andOpIndex orOpIndex xorOpIndex'

classVariableNames: ''
poolDictionaries: ''

category: 'VMMaker-Plugins'

and in SmartSyntaxPluginCodeGenerator>initializeCTranslationDictionary is

#remapOop:in: #generateRemapOopIn:on:indent:

and SmartSyntaxPluginCodeGenerator>generateRemapOopIn:on:indent: maps remapOop:in: to calls of pushRemappableOop and popRemappableOop.

yes... but #remapOOp:in: is defined for the plugin, not for the interpreterProxy (that's what I mean: I need to replace "interpreterProxy remapOop: ... with "self remapOop:", otherwise is not being translated.

but:

3) I have an error compiling FFI plugin: it is generating a "halt" function which is already present (as macros). I don't know why it is being generated... I think that it shouldn't, but I don't know how to prevent that.

I nuked the macro definition of halt in sqAssert.h in r2490.

cool, now It works :)

cheers,

Esteban