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

Eliot Miranda eliot.miranda at gmail.com
Wed Nov 9 23:42:33 UTC 2011

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__

> 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

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20111109/15c9fd8b/attachment.htm

More information about the Vm-dev mailing list