2014/1/10 Igor Stasenko <siguctua@gmail.com>

On 10 January 2014 11:48, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

NativeBoost and AsmJit are quite problematic to unload.

problematic, why?

with the �right oder it's doable:

| remove |

remove := #('Athens-Cairo' 'PangoCairo' 'NativeBoost-Tests' �'NativeBoost-Examples' 'NativeBoost-Unix' 'NativeBoost-Win32' 'NativeBoost-Mac' � 'NativeBoost-Core' 'NativeBoost-Pools' 'AsmJit-Tests' 'AsmJit-StackManagement' 'AsmJit-Operands' 'AsmJit-x86' �'AsmJit-Extension' 'AsmJit-Instructions' 'AsmJit-Core').

remove do: [ :packageName |

�(MCWorkingCopy forPackage: (MCPackage named: packageName)) unload. ].

However the resultant image is quite dirty then (look at obsoleteClasses) and�OSEnvironment uses NB to get some information so such image rises startup errors. Can we look at these issues, Igro?

�

I want to ask if we want to be able to do that.

Definitely.
�

I know that in future they should play more important role but they support only one architecture so it seems reasonable to me to do not declare them currently as kernel packages (only the default ones) and have a configuration with an ability to unload them.

I am not sure, to me FFI is a core feature which you would want to have in the system.
Which makes me think it should belong to if not kernel, but to some basic set of packages available in system.

If we can remove it, we should keep it removeable and do it on CI. It's not about minimalism but about modular system and well defined dependencies. Beause if some patch that for example uses NB for the default way to set environment variables breaks the CI job and the patch is automatically rejected, then the author will maybe start to thing about dependencies :-)

-- Pavel

�

�

Cheers,

-- Pavel

--
Best regards,
Igor Stasenko.