> On 24 Oct 2014, at 15:05, Nicolai Hess <[email protected]> wrote:
>
> 2014-10-24 14:09 GMT+02:00 Marcus Denker <[email protected]
> <mailto:[email protected]>>:
>
>> On 24 Oct 2014, at 14:06, stepharo <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>>> --
>>>> Dr. Geo - http://drgeo.eu <http://drgeo.eu/>
>>>> iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/>
>>>
>>> Few NB-FFI methods will work without sources, as many rely on the automatic
>>> argument name -> signature mapping.
>>> This happens the first time a method is called after startup, and
>>> platform-specific recompilation occurs. When the argument names are
>>> decompiled as arg1, arg2, the mapping will fail.
>>> (Other NB methods that generate machine code without using NB-FFI, will
>>> still work though)
>>>
>>> Theoretically, one could solve this by internalizing the source of all
>>> NB-FFI calling method in the method trailer* at the end of deployment
>>> preparation process. (so no NB methods have a chance to trigger before
>>> image save)
>>> NB puts native code into the same trailer space, and combing different
>>> method trailer types is currently unsupported (AFAIK), but the transition
>>> TrailerWithEmbeddedSource** -> TrailerWithNBCode should happen only once.
>>
>> Yes it would be good to have a method for doing that.
>> https://pharo.fogbugz.com/default.asp?14311
>> <https://pharo.fogbugz.com/default.asp?14311>
>
> No, please… we need to simplify, not make everything complex.
>
> It would be much better to spend engery on getting rid of .sources and
> changes… we are drowning in complexity with
> the current stuff.
>
> Marcus
>
>
> Isn't that for what NativeBoost prepareForProduction is used?
>
>
Yes! Now I remember, we solved that usecase already.
Good.
Ceterum Censeo: We need to get rid of .sources and .changes.
Marcus
