[Vm-dev] issues integrating Eliot latest version with cocoa

[Esteban Lorenzano]

Hi, 

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

> 
> 
> On Wed, Nov 9, 2011 at 2:52 PM, Esteban Lorenzano <estebanlm at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20111111/b0e36b48/attachment.htm