>     Isn't it true that 'ioLoadFunctionFrom()'  only works with exported
> functions ?
Yup. Take a look at the implementation of ioLoadFunctionFrom(); it calls
findOrLoadModule(), which in turn loads the squeakModule. Then consider
the findFunctionIn() procedure which, if the module name is null, ends
up looking in the squeak module (ie the exported functions in the vm,
including any functions added in platform.exports) for its target. Thus
if you need to access something in the vm you can do so by adding it to
the platform.exports list and using ioLoadFunctionFrom(fnName, NULL)
just like I do for the socket poll setting function in the Acorn socket
code.
And sorry, I mistyped when saying the platform.exports stuff got added
to the interpreterProxy. I plead youth and inexperience combined with
long and faithful service, along with lack of caffeine. No salary -> no
spare money for lattes.


> > >         1/- The source code is only needed to be generated once. After
> that
> > > any configuration of the VM + internal plugins can be built.
> > With a tool like VMMaker it's so simple to do and eventually we will
> > drive the compiler directly anyway. Really eventually I would like to
> > generate the executable direclty. We did it at Interval and I can't see
> > any reason not to expect it to be useful out in the real world.
> 
>     How could I have left out the external plugins !!! Until the VMMaker can
> generate external plugins that can just be built and used, a lot of hackings
> must be done before many of them can be built as external plugins. Every
> time you generate the new code, all your hackings are gone. Don't you find
> this frustrating. Unless you always use all plugins as internal, then there
> is no problems.
I haven't found any hackings neccessary except to use -DDISABLE_SECURITY
in order to avoid the problems to do with badly implemented
interdependencies between socket, file and security plugins. I'm pretty
sure I detailed that proble in an email some time ago.
Aside from that, I haven't had any problems in doing VMMaker stuff on
Acorn or unix. Can't look at windows since I don't have a windows
machine. Won't look at Mac since CodeWorrier annoys me too much.

> > >         2/- Without the 2 arrays of plugin name, function and function
> > > pointers, the function lookup for internal plugins will scale well.
> Think of
> > > millions of internal plugins (not that we will ever have that many ;-)
> > You will need _exactly_ the same number of slots whichever way it is
> > done.
> > >
> 
>     Please note 'Without the 2 arrays...'. There will be no, none, nil slots
> required whether for 10 or 1000000 internal plugins.
If you put tables in the vm or in the plugins, they will take approx the
same space. Maybe I missed some explanation of a detail that changes
that?


>     In the spirit of  Squeak and 'OpenSource', in the name of  'The
> VMMaker', I wish you will share your joys with other Squeak minimalist VM
> lovers, myself included, by putting your knowledge and experience into the
> VMMaker so that it will generate all external plugins with all the beautiful
> crossplatform supporting code that can just be built with my makefile
> (already sent to you) and ready for use. (Please don't say that you will do
> it for a fee ;-)
I've just finished a small article for Tansel's Squeak ezine fiorst
edition and a second release of VMMaker with some small improvements
that might make you happier. No charge. No salary neither :-(


>     With your reputaion, if you submit your implementation, it will be
> accepted before you even send it. ;-)
I wish.
> 
>     I am looking forward for Your VMMaker. Don't forget I am among the first
> supporters of  The VMMaker ;-)
How could I forget?

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Diarrhea of the mouth; constipation of the ideas.