2008/11/22 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>>
>>> Yes. Although, you won't get around doing something about unloading
>>> either -
>>> we spent today learning about the intricacies of unloading OpenAL32.dll
>>> and
>>> it turned out to be absolutely crucial to be able to unload our own
>>> plugins.
>>> A flat shared namespace might have caused some serious issues here.
>>>
>> Almost anything "might have cause some serious issues", if you don't
>> use it wisely (Class become: nil).
>> Its not an argument not to use it.
>
> Certainly. And it wasn't an argument not to use it, merely a practical point
> about something that comes up with a flat shared namespace (cleaning up that
> namespace in the face of unloading modules and possibly overwriting entries
> that are now owned by other modules).
>

I agree, it is not flawless, as well as current implementation.
I just looking for a ways to relax interdependency between different
modules or between VM and modules.
A shared namespace fits good for some cases listed, and not so good
for others. No wonder, there can't be single tool to make everything
:)
If you see better alternatives (to shared namespace), i'll listen with
interest.

>>>> doesn't it look like more modular?
>>>
>>> No. It looks utterly pointless to me. You introduce a plugin that does
>>> nothing but looking up and call an atom; what good is that plugin? If you
>>> generalize that just a little you have the FFI where you might declare
>>> ioFoo() directly and call it. Which of course could be done via atom
>>> table
>>> too, but I still fail to see how that would be more modular.
>>
>> Not a plugin. I mentioned VM code in interp.c. I see little need in
>> having such constructs in plugin.
>> In VM core, however, there is always a bit of uncertainty - VM forced
>> to provide primitive by default (because its a standart one), but on
>> different platforms, depending on their capabilities or your intent,
>> you may omit putting functionality of some primitives into VM.
>
> Well, that's why we came up with plugins to begin with ;-) So that different
> platforms and different builds can have different sets of functionality.
>

Yeah, but still there are places which is quite rigid and causing
headache when you have to deal with them.
For instance, try building VM without including SecurityPlugin:

//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Intel.c:1128:
undefined reference to `ioInitSecurity'
./obj/vm/sqWin32Prefs.o: In function `SetAllowFileAccess':
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:96:
undefined reference to `ioHasFileAccess'
./obj/vm/sqWin32Prefs.o: In function `SetAllowImageWrite':
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:101:
undefined reference to `ioCanWriteImage'
./obj/vm/sqWin32Prefs.o: In function `SetAllowSocketAccess':
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:106:
undefined reference to `ioHasSocketAccess'
./obj/vm/sqWin32Prefs.o: In function `HandlePrefsMenu':
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:383:
undefined reference to `ioHasFileAccess'
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:383:
undefined reference to `_ioSetFileAccess'
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:387:
undefined reference to `ioCanWriteImage'
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:387:
undefined reference to `_ioSetImageWrite'
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:391:
undefined reference to `ioHasSocketAccess'
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:391:
undefined reference to `_ioSetSocketAccess'
-------

Without SocketPlugin:

./obj/vm/sqWin32Prefs.o: In function `HandlePrefsMenu':
//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Prefs.c:400:
undefined reference to `win32DebugPrintSocketState'
-------

Without FilePlugin (this list quite long, so i just leave a one error
per single .c file):

//F/projects/pharo-freetype/src32/winbuild/./src/vm/gnu-interp.c:3242:
undefined reference to `sqImageFileSeek'

//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Args.c:26:
undefined reference to `sqImageFileOpen'

//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32Intel.c:1116:
undefined reference to `sqImageFileOpen'

//F/projects/pharo-freetype/src32/winbuild/../platforms/win32/vm/sqWin32PluginSupport.c:252:
undefined reference to `fileRecordSize'

./obj/vm/AsynchFilePlugin.lib(sqWin32AsyncFilePrims.o): In function
`asyncFileValid':
//F/projects/pharo-freetype/src32/winbuild/obj/AsynchFilePlugin/../../../platforms/Win32/plugins/AsynchFilePlugin/sqWin32AsyncFilePrims.c:167:
undefined reference to `thisSession'

./obj/vm/DropPlugin.lib(sqWin32Drop.o): In function `dropRequestFileHandle':
//F/projects/pharo-freetype/src32/winbuild/obj/DropPlugin/../../../platforms/Win32/plugins/DropPlugin/sqWin32Drop.c:745:
undefined reference to `fileRecordSize'
---------------

I cannot accept any reasoning, why VM would be considered defunc
without any of the above plugins, and therefore they ought to be
included in build. In the end it defeats the purpose of plugins: be
able to plug-in or plug-out at will.

>> Its not the same thing. Currently you have to define a function - with
>> implementation or with empty body to make compiler content.
>> In example i showed - you can do simpler - just omit binding a
>> function to a symbol.
>
> Sure. But it's still a completely contrived example. The stubs are only
> there because once upon a time, in an age long past there weren't VM plugins
> and you couldn't leave out entire plugins from the generated VM so the stubs
> were a necessity. I need to remove these stubs - they are completely
> pointless in this day and age. Thanks for reminding me.
>
Yeah, less cruft is good :)

>> Take a look at Hydra code, where InterpreterProxy has left with only 3
>> functions, and will stay to have 3 functions forever without need in
>> extending protocol , because rest functions is obtained dynamicaly
>> using name lookup.
>> A plugin simply refuse to start without having all requested VM
>> functions be non-null. But the trick is, that VM not forced anymore to
>> support obsolete stuff of ever-growing InterpreterProxy protocol.
>
> I see - I had understood you wrongly. I thought you were explicitly trying
> to back out of the role of InterpreterProxy as the contract (which is not
> fulfilled if the VM doesn't export all the required functions in Hydra) and
> rather have the plugin code deal with the necessary lookups manually.
>
> The way Hydra does the proxy lookup is just fine as far as I am concerned.
> There is no difference from the client's point of view - for the plugin
> writer the proxy remains the contract and the ability to selectively allow
> and deny certain entry points can in fact be helpful since it allows a more
> flexible set of definitions of what is part of a particular proxy interface.
>
> Cheers,
>  - Andreas
>
>


-- 
Best regards,
Igor Stasenko AKA sig.