I wrote:

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

    And of course, with the source released by Andreas. Sorry for the
ommission.

    Cheers,

    PhiHo.

----- Original Message -----
From: "phiho.hoang" <phiho.hoang@[...].com> 
To: <squeak@[...].edu> 
Sent: Saturday, May 05, 2001 4:50 PM
Subject: Re: [Win32][VM]: Update to 3.1 Alpha build 4


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