Hi, Georgios and Mo -
I realize I am coming quite late to this party, but I have a request
for each of you :
Georgios - would you be willing to post your patches to TclBlend 1.4.0
(or .1, if you've updated them). Like you, I find that I want to load
TclBlend into an active TCL interpreter, but have little or no interest
in loading TCL or TclBlend into a JVM. If I'm in a JVM, I'll use JACL.
Mo, let me start by saying how impressed I am with the work on JACL and
TclBlend - these are great! My request for you would be to think about
how there could be a version of TclBlend that can only be loaded into a
TCL interpreter, never into a JVM. I'd be willing to help work on this,
since I'm the one asking. Would it be as simple as (a) coming up with a
third product name and (b) using Georios' patch as the build process?
I'm suggesting having a new name and separate build process to emphasize
that this other thing and TclBlend really are different beasts for
different purposes. It might even be possible to modify the source base
so that the part that continues to be called TclBlend only loads into a JVM.
I also have a question about the Tcl stubs issue. It seems to me
that we could solve this problem with the canonical extra level of
indirection : the TclBlend build process creates a generic TclBlend
shared library whose only functions are to
(a) Look up in a configuration file which specific 'real' TclBlend and
Tcl libraries to load; and
(b) Provide the support necessary to interface the specific JVM that is
running with the specific TclBlend that is (will be?) running. This
could be implemented as a whle suite of libraries supporting the various
JVM and TclBlend interfaces, with some plumbing to connect the two.
The 'real' TclBlend library would be stubs aware, but need not know
which JVM or TCL it is talking to. The 'interface' libraries could be
specifically tailored to individual combinations of JVM / TCL /
TclBlend, but only one (or a few) would need to be built for any given user.
Thanks!
David
|
