Tim wrote:

>  >     I did ;-) and have a feature request. Can you give me an option to
>  > always generate function names as 'moduleName_functionName'.
>  not in the VMMaker - it's part of the InterpreterPlugin translation
>  stuff. See CCodeGenerator>declareModuleName:local: etc

    Thanks for the hint. That's all I need for now. Just the naming part.

>  >     I also reported the problem about the VM directory. I created it at
the
>  > same level as other plugins under 'platforms/Win32',i.e, it is
>  > 'Platforms/Win32/VM', put in there Win32 specific stuff and they were
not
>  > copied to the final VM directory. The stuff in the plugin directories
were
>  > copied OK though.
>  Might the capitalisation be the problem? The default is 'vm' - I have no
>  idea if windoze would accept 'VM' equally as well.

    You are absolutely right. I changed to 'vm' and it works like a charm !

>  >     Oh, one more feature request, please. Can I have an option to put
all
>  > the header files in a central 'src/include' directory ?
>  I can't imagine why that would be useful, but I suppose you could put a
>  subdirectory 'include' under platform/win32/misc (which would be copied
>  to /src/include) and  modify the implementors of
>  writeHeaderFileToDirectory: & writeSupportFilesToDirectory: to ignore
>  the passed indirectory and always use /src/include. What would the
>  benefit be?

    As I am trying out the implementation of PluginProxy, I found that one
plugin might need to include a header file of another plugin. It would be
convenient if we have a central include directory.

    Thanks for the pointer, I will look at where you pointed to.

    One more thing, SqueakFFIPlugin class > > moduleName returns 'FFIPlugin',
should it be 'SqueakFFIPlugin' ? Anyway, I changed it and still got 'callout
mechanism not available' when tried 'Win32Window coloredEllipses'.

    Btw, my Squeak.exe is now 187KB, with 26 external plugins (a few are
still missing inaction, because of the linking problem of the MinGW
dlltools). The total disk space required is 984 KB.

    I didn't get the 10% gain in speed as you did for Acorn VM:

0 tinyBenchmarks

All internals : '110,918,544 bytecodes/sec; 3,033,855 sends/sec' (as
released by Andreas)
All externals: '113,475,177 bytecodes/sec; 3,040,207 sends/sec' (built with
VMMaker, MinGW and PluginProxy alone, no tweaks regarding internal/external
name and function lookup.)

    It's good news to me. At least it's not slower ;-)

    Cheers,

    PhiHo

----- Original Message -----
From: "Tim Rowledge" <tim@[...].edu> 
To: <squeak@[...].edu> 
Sent: Saturday, May 05, 2001 2:01 PM
Subject: Re: [Win32][VM]: Update to 3.1 Alpha build 4


>  "phiho.hoang" <phiho.hoang@[...].com> is widely believed to have written:
> 
>  > Tim,
>  >
>  >     I did ;-) and have a feature request. Can you give me an option to
>  > always generate function names as 'moduleName_functionName'.
>  not in the VMMaker - it's part of the InterpreterPlugin translation
>  stuff. See CCodeGenerator>declareModuleName:local: etc
>  >
>  >     I always generate 'all external' but sometimes I am stuck and need
to
>  > put back some modules as internals. And yes, I rebuild the VM every 10
>  > minutes ;-)
>  As Andreas &  have both recommended, you ought to do this by
>  regenerating the appropriate code. Rather than regenerating _everything_
>  you might look into implementing some dependency rules so that you could
>  generate the problem plugin & a new sqNamedPrims.h together. I guess the
>  old version of the plugin ought to be deleted to avoid confusion on any
>  system that works out its own makefiles.
>  >
>  >     I also reported the problem about the VM directory. I created it at
the
>  > same level as other plugins under 'platforms/Win32',i.e, it is
>  > 'Platforms/Win32/VM', put in there Win32 specific stuff and they were
not
>  > copied to the final VM directory. The stuff in the plugin directories
were
>  > copied OK though.
>  Might the capitalisation be the problem? The default is 'vm' - I have no
>  idea if windoze would accept 'VM' equally as well.
> 
>  >
>  >     Oh, one more feature request, please. Can I have an option to put
all
>  > the header files in a central 'src/include' directory ?
>  I can't imagine why that would be useful, but I suppose you could put a
>  subdirectory 'include' under platform/win32/misc (which would be copied
>  to /src/include) and  modify the implementors of
>  writeHeaderFileToDirectory: & writeSupportFilesToDirectory: to ignore
>  the passed indirectory and always use /src/include. What would the
>  benefit be?
> 
>  tim
> 
>  --
>  Tim Rowledge, tim@[...].edu, http://sumeru.stanford.edu/tim
>  A)bort, R)etry, I)nfluence with large hammer.
> 
>