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

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

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. ].

why we do unloading like that?

one must not manually specify order nor different subpackages to unload (e.g. it makes no sense to keep AsmJit-Extension if you unload AsmJit-Core etc).

it should be done by configuration, or system itself should maintain knowledge about dependencies, like that one could just say:

(Package named: 'NativeBoost-Core') unload.

i'm not blaming anyone, i just think that instead of investing effort into creating

manually crafted things each time, it would be wiser to invest effort into creating things which will do it automatically freeing us from such boring and counterproductive tasks once and for all.

I wanted to create such code to have something we can put in the configuration (http://smalltalkhub.com/mc/Pharo/SystemConfigurations). Monticello quite well does the loading of multiple packages at once but we have not something like atomic unload.

-- Pavel

�

�

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?

sure.. but it would be much less work if people would care about it from the

�very starting :/

�

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 :-)

yes. And you don't have to convince me why modularity is important and has value :)

�

-- Pavel

�

--
Best regards,
Igor Stasenko.