tcljava-dev — discuss implementation and post patches here

Re: [tcljava-dev] Tcl Blend 1.4.0 binary for Win32 available for testing

[Mo D. <mo...@mo...>]

Virden, Larry W. wrote:
> I just had a question from a developer asking me whether the latest
> TclBlend, a recent version of Tcl, and JDK 1.5 was a combination that
> worked.
>
> Has anyone tried to build this?
>
> I am guessing this would be on SPARC Solaris, but if you've done it on
> Windows, that would be interesting to know as well.
>   
Yes, this combo should work. Be sure that they don't build with gcc 4, 
but other than that
there should be no problems.

Mo DeJong

[tcljava-dev] Tclblend and solaris

[Virden, L. W. <lv...@ca...>]

I am wondering if anyone has gathered tips on the modifications
necessary to the current tcljava code so that it will build on SPARC
Solaris.=20

The first problem I encountered is that the configure looks for:
Looking for /vol/javaNFS/jdk1.5.0/jre/lib/sun4u/libjava.so

However, Sun uses the path

/vol/javaNFS/jdk1.5.0/jre/lib/sparc/libjava.so

So I edited the tcljava.m4 file, as noted by the output from configure.
But configure doesn't seem to=20
Recognize that change.

So I decided to try and regenerate configure after making this change.
However, autoconf indicated that I needed an autoconf newer than ships
with Sun . So I get a newer one and use that.

I get farther at this point - now I'm told that the gcc in my
environment has a bug that breaks Tcl Blend and that I should use
another version.=20

So I set CC to point to a non-gcc compiler. That doesn't appear to
matter - configure continues to tell me that the gcc is broken.

checking for gcc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...=20
checking for suffix of object files... o
checking whether we are using the GNU C compiler... No

And then later:

checking for GCC 4.1.0 optimizer bug... yes
configure: error: This gcc release contains an optimizer bug that breaks
Tcl Blend, please use another version of gcc

The real problem, looking into the config.log, is:
configure:4564: checking for GCC 4.1.0 optimizer bug
configure:4601: cc -o conftest -g -O2   conftest.c  >&5
cc: Warning: option -2 passed to ld
/usr/ccs/bin/ld: illegal option -- 2

Am I forced to use gcc? I'd prefer to use Sun's compiler.

Oh, and note that the version of gcc that was used, as far as I can
tell, earlier, was 3.3.1, not 4.1.0. I don't have a newer gcc
available...

Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2

[Bruce J. <nm...@ma...>]

My point was not so much that there were Java libraries that exactly  
duplicated the functionality of Tcl specific C libraries, but that  
developing such libraries is much faster in Java than in C.   
Additionaly, there are libraries that can be rapidly interfaced to  
Jacl that give similar, and often more extensive, functionality.

For example, as an alternative to the graphing tools found in BLT  
I've written some simple interfaces to JFreeChart ( http:// 
www.jfree.org/jfreechart/ ).  With these interfaces I can put put  
JFreeChart graphs on the Swank canvas.  A bit more work and one would  
have a much more extensive charting library than what BLT provides.   
And as far as I can tell there are platform issues with BLT.  For  
example, it seems from the wiki pages on BLT ( http://wiki.tcl.tk/ 
199 ) that it doesn't run with Tk Aqua on the Mac.  Jacl/Java  
implementations pretty much run anywhere, often no compilation  
needed, just plug in the jar file.

As an alternative to the vector tools in BLT I use Colt ( http:// 
dsd.lbl.gov/~hoschek/colt/ ).  Again, just add one jar file to your  
classpath and have scripted access to a huge library of math and  
statistics.

What's not to like?


Bruce



On Feb 22, 2007, at 7:43 AM, Virden, Larry W. wrote:

>
>
>
> -----Original Message-----
> From: Charles Oliver Nutter
>>  What
> library exists in the C world that we don't have an analog for in  
> Java?
>
> Tix, BLT ... I suspect there are dozens of Tcl specific C libraries
> which have no Java counterpart...
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2

[Virden, L. W. <lv...@ca...>]

-----Original Message-----
From: Charles Oliver Nutter
>  What=20
library exists in the C world that we don't have an analog for in Java?=20

Tix, BLT ... I suspect there are dozens of Tcl specific C libraries
which have no Java counterpart...

Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2

[Charles O. N. <cha...@su...>]

Bruce Johnson wrote:
> I agree to some extent with what you say, but personally I think that  
> when the core of a language like Jacl catches up with the C version  
> (and it is not that far now), that progress can potentially occur  
> much faster.  There are so many APIs built-in to Java that  writing  
> extensions is much faster than with C development, and once written  
> they are cross-platform.  For example, I have scripted access to  
> Oracle databases with just a few lines of Jacl calling the JDBC  
> APIs.  I probably never would have set out to write a C interface to  
> Oracle (like Oratcl etc.), but doing this with Jacl was a breeze.

I was going to respond myself, but Bruce is exactly right here. What 
library exists in the C world that we don't have an analog for in Java? 
Generally porting over "extensions" just means providing a compatible 
interface to the same library in Java. In JRuby, that's exactly how 
we've provided socket support, zlib support, and so on. There are cases 
where a technology needs to be ported because it's based on a very 
specialized library (OpenSSL) or a technology is too new to have a Java 
equivalent (YAML) but we've had community members step up to the 
challenge of implementing those too.

I think in general the problem most dynamic languages on the JVM have 
had is that they target the wrong goal: some amorphous measure of 
"compatibility" with the target language. What's needed is a concrete 
goal people can latch onto and get excited about; some endpoint that 
will actually help developers do something they couldn't do before. For 
JRuby that milestone is Rails support (and BTW, Rails does run fine in 
JRuby apart from a few remaining interpreter bugs since it's generally 
pure Ruby), which has been a compelling enough goal to get folks really 
excited about JRuby. Similar targets exist for Jython, and perhaps 
Grails will be the first really compelling use of Groovy.

The big question then becomes "what milestone can we set for our 
implementation of language X that will get people excited about using it?"

- Charlie

Re: [tcljava-dev] Dynamic Languages on the JVM: The Future

[Charles O. N. <cha...@su...>]

Bruce Johnson wrote:
> 
> Of course, these things always contribute a little to the traditional 
> "we have the best-kept secret", or perhaps, "we have the largest 
> inferiority complex" that plagues the Tcl world.  One would like to 
> think that Tcl/Jacl wouldn't be relegated to the "etc." category in 
> lists such as this (from the Java One flyer).  
> 
> Scripting languages (e.g. Groovy, Jython, Ruby, Perl, PHP, Python, 
> Rhino, etc.)
> 
> Apparently we do need what the Java One conference calls a "Rock 
> Star".  On the other hand perhaps the steady, but unnoticed,  usage of 
> Tcl is better than a rise to stardom followed by decline to obscurity.

Yes, this whole dynamic language world is pretty fickle. Either you're 
the darling or the stepchild, and there's no guarantees where you'll 
stand from year to year.

I suppose you're right about the "rock star" thing. Perhaps what most 
people are missing in Tcl nowadays is a big-name app that fits into one 
of the latest popular development models... a Rails or Django or 
something that shows people they can get things done in Tcl they can't 
do as easily in other languages. Not knowing the Tcl world much myself, 
I can't say what that an app would be.

- Charlie

Re: [tcljava-dev] Dynamic Languages on the JVM: The Future

[Charles O. N. <cha...@su...>]

Bruce Johnson wrote:
> I've had some inquiries about access to Swank (Tk in Java) from other  
> languages like JRuby.  It might be interesting to think about what  
> core features would make this simpler.  I hadn't planned on attending  
> Java One, but this sounds like an interesting event, so I may think  
> about it.

Actually someone just asked about Tk support in JRuby today, and I'd 
never heard of Swank. I bet it would be fairly easy to write Ruby 
bindings in JRuby for Swank...

- Charlie

Re: [tcljava-dev] Tcl Blend 1.4.0 binary for Win32 available for testing

[Virden, L. W. <lv...@ca...>]

I just had a question from a developer asking me whether the latest
TclBlend, a recent version of Tcl, and JDK 1.5 was a combination that
worked.

Has anyone tried to build this?

I am guessing this would be on SPARC Solaris, but if you've done it on
Windows, that would be interesting to know as well.


--=20
<URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/
>
=20


-----Original Message-----
From:  Mo DeJong
Sent: Tuesday, January 23, 2007 3:10 PM

> A new binary release that combines Tcl, Thread, Tk, Tcl Blend, and
Sun's=20
> JDK 1.4
> is now available for testing.

Re: [tcljava-dev] Fwd: tcljava-dev Digest, Vol 5, Issue 4

[Bruce J. <nm...@ma...>]

http://home.pacbell.net/ouster/scripting.html


On Feb 19, 2007, at 4:48 PM, Patrick Finnegan wrote:

>
>
>> I think John O's critical stance of OO (that rubbed the Java guys  
>> the wrong
>> way) and Tcl's lack of object oriented features was one of the  
>> biggest
>> reasons something did not happen.
>
> Very interesting.  What exactly did John O have against OO?
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

[tcljava-dev] Fwd: tcljava-dev Digest, Vol 5, Issue 4

[Patrick F. <pfi...@oz...>]

>I think John O's critical stance of OO (that rubbed the Java guys the wrong
>way) and Tcl's lack of object oriented features was one of the biggest
> reasons something did not happen.  

Very interesting.  What exactly did John O have against OO?

Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 3

[Ray J. <ra...@in...>]

I ran the group working on Jacl and TclBlend at Sun.  Sun had several =
language projects at the time but it was becoming clear that Java was =
the big sucess and that you had better do something Java related if you =
wanted last.  (Well that was the cynical view anyway.)  We also knew =
that Java really needed a scripting story - which is why we started the =
project.
=20
At the time, however, Sun was in a hurry because Netscape who was the =
big player to adopt Java was also working on a scripting language.  We =
were proposing to Sun management that Jacl would be just the ticket.  In =
the end, Bill Joy pushed for a deal with Netscape to name the language =
they were working on as JavaScript.
=20
I think John O's critical stance of OO (that rubbed the Java guys the =
wrong way) and Tcl's lack of object oriented features was one of the =
biggest reasons something did not happen.  Though I'm sure timing and =
other political things were also part of the mix - I certainly do not =
claim to know the whole picture.  Though I do know that that decision =
marked the begining of the end of Tcl at Sun.

So I too find this interest in Jacl by Sun folks as ironic.
=20
Another irony, (in my own humble opinion) is that it seems to me this =
effort is in a response really to Microsoft's efforts to support dynamic =
languages.  MS is way ahead of Java at this point in supporting dynamic =
lanugages.  Sun is now playing catch-up to MS's lead...
=20
Ray
=20
________________________________

From: tcl...@li... on behalf of Patrick =
Finnegan
Sent: Sun 2/18/2007 1:38 PM
To: tcl...@li...
Subject: Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 3




>
> Of course, these things always contribute a little to the traditional
> "we have the best-kept secret", or perhaps, "we have the largest
> inferiority complex" that plagues the Tcl world.  One would like to
> think that Tcl/Jacl wouldn't be relegated to the "etc." category in
> lists such as this (from the Java One flyer).
>

The greatest irony is that Tcl and JACL were originally developed by Sun =
and
then put out to grass.  The fact is dynamic language capability has been =
part
of the JVM since 1997.  Just look at the JACL source.  It has Sun =
copywrite
plastered all over the shop.    Just add the two JACL jar files to the
lib/ext directory of the Java SDK/JRE to enable dynamic class loading =
and hey
presto you have a built in scripting environment for JAVA.  I am amazed =
that
Java did not ship with built in JACL as standard.      =20

* BlendExtension.java --
 *
 *      This extension encapsulates the java::* commands.
 *
 * Copyright (c) 1997-1998 by Sun Microsystems, Inc.

-------------------------------------------------------------------------=

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 3

[Patrick F. <pfi...@oz...>]

>
> Of course, these things always contribute a little to the traditional
> "we have the best-kept secret", or perhaps, "we have the largest
> inferiority complex" that plagues the Tcl world.  One would like to
> think that Tcl/Jacl wouldn't be relegated to the "etc." category in
> lists such as this (from the Java One flyer).
>

The greatest irony is that Tcl and JACL were originally developed by Sun and 
then put out to grass.  The fact is dynamic language capability has been part 
of the JVM since 1997.  Just look at the JACL source.  It has Sun copywrite 
plastered all over the shop.    Just add the two JACL jar files to the 
lib/ext directory of the Java SDK/JRE to enable dynamic class loading and hey 
presto you have a built in scripting environment for JAVA.  I am amazed that 
Java did not ship with built in JACL as standard.        

* BlendExtension.java --
 *
 *	This extension encapsulates the java::* commands.
 *
 * Copyright (c) 1997-1998 by Sun Microsystems, Inc.

Re: [tcljava-dev] Dynamic Languages on the JVM: The Future

[Bruce J. <nm...@ma...>]

Of course, these things always contribute a little to the traditional  
"we have the best-kept secret", or perhaps, "we have the largest  
inferiority complex" that plagues the Tcl world.  One would like to  
think that Tcl/Jacl wouldn't be relegated to the "etc." category in  
lists such as this (from the Java One flyer).

Scripting languages (e.g. Groovy, Jython, Ruby, Perl, PHP, Python,  
Rhino, etc.)

Apparently we do need what the Java One conference calls a "Rock  
Star".  On the other hand perhaps the steady, but unnoticed,  usage  
of Tcl is better than a rise to stardom followed by decline to  
obscurity.



On Feb 16, 2007, at 9:11 PM, Charles Oliver Nutter wrote:

> (Hi there Tcl enthusiasts and Jacl devs! This is kind of a form  
> letter,
> but I'm serious about getting this event together with devs from
> multiple languages. I'd love to hear your thoughts on such an event  
> and
> see if you'd be interested in attending.)
>
> Hello all!
>
> I am attempting to organize an outside event for JavaOne this year
> entitled "Dynamic Languages on the JVM: The Future". It is my  
> intent to
> have as many alternative (dynamic) language implementers together  
> in the
> same place as well as Java and JVM developers and specifiers. This  
> would
> be our opportunity to talk about areas that have caused us trouble,
> features we'd like to see in Java or the JVM (or features we'd like to
> remove) and other related topics. I really want to break down the
> boundaries between the language implementations/implementers so we can
> cooperatively work toward making the JVM a more dynlang-friendly  
> platform.
>
> Ideally we'd have as many of your core team as possible (or others, as
> you see fit) in attendance. I'll be there, as will at least Tom Enebo
> and Ola Bini of the JRuby team. I'm also reaching out to other  
> language
> teams in hopes of having a really good cross-language discussion.
>
> The event would likely be hosted at a nearby hotel, bar, or  
> restaurant.
> I'd like it to be pretty informal, but somewhere we can actually talk.
>
> It would help my cause to get this event organized (and funded) if I
> could get a vote of confidence from likely attendees. Many high-level
> folks at Sun have already voiced their approval, and I think this  
> is an
> excellent opportunity for us to show that real cooperation between the
> dynlang impls is possible and that it would be productive.
>
> Please feel free to reply on this list (assuming the owners don't  
> mind)
> or in private if you have questions or to voice your opinion. This is
> going to be a big year for dynlangs on the JVM, and we need to make  
> sure
> things keep moving in the right direction.
>
> -- 
> Charles Oliver Nutter
> JRuby Core Developer
> Senior Staff Engineer
> Sun Microsystems, Inc
> _______________________________________________
> dev-tech-js-engine mailing list
> dev...@li...
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] Dynamic Languages on the JVM: The Future

[Charles O. N. <cha...@su...>]

Bruce Johnson wrote:
> I've had some inquiries about access to Swank (Tk in Java) from other  
> languages like JRuby.  It might be interesting to think about what  
> core features would make this simpler.  I hadn't planned on attending  
> Java One, but this sounds like an interesting event, so I may think  
> about it.

I'm pushing for JavaOne attendance to not be a prerequisite also. 
Obviously it would be great for you to attend what will truly be "the 
scripting JavaOne" and see all the talks, but I don't want the cost of 
the conference to prevent folks like you from joining the conversation.

Do keep me posted on your plans.

- Charlie

Re: [tcljava-dev] Dynamic Languages on the JVM: The Future

[Bruce J. <nm...@ma...>]

I've had some inquiries about access to Swank (Tk in Java) from other  
languages like JRuby.  It might be interesting to think about what  
core features would make this simpler.  I hadn't planned on attending  
Java One, but this sounds like an interesting event, so I may think  
about it.

Bruce



On Feb 16, 2007, at 9:11 PM, Charles Oliver Nutter wrote:

> (Hi there Tcl enthusiasts and Jacl devs! This is kind of a form  
> letter,
> but I'm serious about getting this event together with devs from
> multiple languages. I'd love to hear your thoughts on such an event  
> and
> see if you'd be interested in attending.)
>
> Hello all!
>
> I am attempting to organize an outside event for JavaOne this year
> entitled "Dynamic Languages on the JVM: The Future". It is my  
> intent to
> have as many alternative (dynamic) language implementers together  
> in the
> same place as well as Java and JVM developers and specifiers. This  
> would
> be our opportunity to talk about areas that have caused us trouble,
> features we'd like to see in Java or the JVM (or features we'd like to
> remove) and other related topics. I really want to break down the
> boundaries between the language implementations/implementers so we can
> cooperatively work toward making the JVM a more dynlang-friendly  
> platform.
>
> Ideally we'd have as many of your core team as possible (or others, as
> you see fit) in attendance. I'll be there, as will at least Tom Enebo
> and Ola Bini of the JRuby team. I'm also reaching out to other  
> language
> teams in hopes of having a really good cross-language discussion.
>
> The event would likely be hosted at a nearby hotel, bar, or  
> restaurant.
> I'd like it to be pretty informal, but somewhere we can actually talk.
>
> It would help my cause to get this event organized (and funded) if I
> could get a vote of confidence from likely attendees. Many high-level
> folks at Sun have already voiced their approval, and I think this  
> is an
> excellent opportunity for us to show that real cooperation between the
> dynlang impls is possible and that it would be productive.
>
> Please feel free to reply on this list (assuming the owners don't  
> mind)
> or in private if you have questions or to voice your opinion. This is
> going to be a big year for dynlangs on the JVM, and we need to make  
> sure
> things keep moving in the right direction.
>
> -- 
> Charles Oliver Nutter
> JRuby Core Developer
> Senior Staff Engineer
> Sun Microsystems, Inc
> _______________________________________________
> dev-tech-js-engine mailing list
> dev...@li...
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2

[Bruce J. <nm...@ma...>]

I agree to some extent with what you say, but personally I think that  
when the core of a language like Jacl catches up with the C version  
(and it is not that far now), that progress can potentially occur  
much faster.  There are so many APIs built-in to Java that  writing  
extensions is much faster than with C development, and once written  
they are cross-platform.  For example, I have scripted access to  
Oracle databases with just a few lines of Jacl calling the JDBC  
APIs.  I probably never would have set out to write a C interface to  
Oracle (like Oratcl etc.), but doing this with Jacl was a breeze.

Bruce



On Feb 17, 2007, at 3:37 PM, Patrick Finnegan wrote:

>
>>
>> (Hi there Tcl enthusiasts and Jacl devs! This is kind of a form  
>> letter,
>> but I'm serious about getting this event together with devs from
>> multiple languages. I'd love to hear your thoughts on such an  
>> event and
>> see if you'd be interested in attending.)
>>
>> Hello all!
>>
>> I am attempting to organize an outside event for JavaOne this year
>> entitled "Dynamic Languages on the JVM: The Future". It is my  
>> intent to
>> have as many alternative (dynamic) language implementers together  
>> in the
>> same place as well as Java and JVM developers and specifiers. This  
>> would
>> be our opportunity to talk about areas that have caused us trouble,
>> features we'd like to see in Java or the JVM (or features we'd  
>> like to
>> remove) and other related topics. I really want to break down the
>> boundaries between the language implementations/implementers so we  
>> can
>> cooperatively work toward making the JVM a more dynlang-friendly  
>> platform.
>
>
>
> I think the future of dynamic languages in the JVM really depends  
> on whether
> non Java developers find Java based deployment of their favourite  
> dynamic
> language an attractive proposition.
>
> There are two approaches to integrating C based dynamic languages  
> with the
> JVM.  One is to rewrite the underlying implementation in Java  
> instead of C
> so that the language runs within the JVM.  The dynamic language  
> commands
> and syntax are interpreted into Java rather then C.  The other is Java
> Native Interface.  The dynamic language loads a JVM into the C  
> runtime and
> makes calls to JAVA using JNI pointers.
>
> Running dynamic languages within the JVM is attractive to Java  
> developers
> who wish to develop hybrid or mixed language applications because  
> it allows
> development within a single IDE and deployment to a single runtime
> environment.  However it has some major drawbacks.  Most of the  
> dynamic
> languages have a small core command set and are dependent on external
> packages or extensions to provide the rich set of features required  
> for
> enteprise development.  In most cases it's only the core that has been
> ported to Java and developers soon find that they have to make  
> extensive
> use of of the java class libraries to provide features that are  
> missing
> from the embedded version of the dynamic language.  No ldap support  
> in JACL.
> No smtpd support in Jython.  No Rails support in JRuby(Current  
> version).
>
> That makes it difficult if not impossible to port a dynamic language
> application written for a C runtime environment directly to a Java  
> runtime
> environment without an extensive rewrite.  Then there is the catch  
> up issue.
> New features in dynamic languages need to be back ported to Java.   
> This is a
> huge overhead that could cripple application development budgets.   
> Most
> Java programmers would rather use a native Java dynamic language like
> Groovey rather than jump on the backport treadmill.
>
> Non Java developers already have a complete toolset for dynamic  
> language
> development and the most popular dynamic languages are certified to  
> run on
> most operating platforms.  So they already have write once run  
> anywhere
> capability.  However there is a demand for an interoperability  
> layer between
> dynamic languages and JAVA that allows the C based runtime call  
> Java class
> libraries and interact with Java applications.  This is partially  
> satisfied
> by the JNI interface.  The Perl inlineJava module and the Tcl tcljava
> extension both use JNI to provide connectivity to the JVM.   
> Historically
> there have been runtime issues with JNI because the extension only  
> supports
> the specific version of the JDK it's compiled against and the  
> location of
> the Java runtime on the installation server is picked up from  
> environment
> variables.  Problems occur when either the JDK is not at a  
> supported level
> or environment vararibles are not set properly.  The latest version of
> TclBlend(Tcl + tcljava) overcomes this by embedding the JVM runtime  
> in it's
> install directory.  It ships with it's own JVM.
>
> The Windows beta version is available here:
>
> http://www.patrickfinnegan.com/
>
> I suppose the holy grail for dynamic languages and Java is really  
> reverse
> JNI i.e a C runtime environment inside the JVM that would allow  
> JAVA to
> support any C based interpreted language natively without the need for
> expensive rewrites in Java.  Java needs something conceptually  
> similar to
> the Common Language Runtime engine in the .NET framework that would  
> allow
> transparent execution of C processes under Java.  Application  
> portability
> across Java and C runtime environments is the best way to attract  
> dynamic
> language developers to Java.
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2

[Patrick F. <pfi...@oz...>]

>
> (Hi there Tcl enthusiasts and Jacl devs! This is kind of a form letter,
> but I'm serious about getting this event together with devs from
> multiple languages. I'd love to hear your thoughts on such an event and
> see if you'd be interested in attending.)
>
> Hello all!
>
> I am attempting to organize an outside event for JavaOne this year
> entitled "Dynamic Languages on the JVM: The Future". It is my intent to
> have as many alternative (dynamic) language implementers together in the
> same place as well as Java and JVM developers and specifiers. This would
> be our opportunity to talk about areas that have caused us trouble,
> features we'd like to see in Java or the JVM (or features we'd like to
> remove) and other related topics. I really want to break down the
> boundaries between the language implementations/implementers so we can
> cooperatively work toward making the JVM a more dynlang-friendly platform.



I think the future of dynamic languages in the JVM really depends on whether 
non Java developers find Java based deployment of their favourite dynamic 
language an attractive proposition.   

There are two approaches to integrating C based dynamic languages with the
JVM.  One is to rewrite the underlying implementation in Java instead of C
so that the language runs within the JVM.  The dynamic language commands
and syntax are interpreted into Java rather then C.  The other is Java
Native Interface.  The dynamic language loads a JVM into the C runtime and
makes calls to JAVA using JNI pointers.

Running dynamic languages within the JVM is attractive to Java developers
who wish to develop hybrid or mixed language applications because it allows
development within a single IDE and deployment to a single runtime
environment.  However it has some major drawbacks.  Most of the dynamic
languages have a small core command set and are dependent on external
packages or extensions to provide the rich set of features required for
enteprise development.  In most cases it's only the core that has been
ported to Java and developers soon find that they have to make extensive
use of of the java class libraries to provide features that are missing
from the embedded version of the dynamic language.  No ldap support in JACL.  
No smtpd support in Jython.  No Rails support in JRuby(Current version).  

That makes it difficult if not impossible to port a dynamic language 
application written for a C runtime environment directly to a Java runtime 
environment without an extensive rewrite.  Then there is the catch up issue.  
New features in dynamic languages need to be back ported to Java.  This is a
huge overhead that could cripple application development budgets.  Most
Java programmers would rather use a native Java dynamic language like
Groovey rather than jump on the backport treadmill.

Non Java developers already have a complete toolset for dynamic language
development and the most popular dynamic languages are certified to run on
most operating platforms.  So they already have write once run anywhere 
capability.  However there is a demand for an interoperability layer between 
dynamic languages and JAVA that allows the C based runtime call Java class
libraries and interact with Java applications.  This is partially satisfied
by the JNI interface.  The Perl inlineJava module and the Tcl tcljava
extension both use JNI to provide connectivity to the JVM.  Historically
there have been runtime issues with JNI because the extension only supports
the specific version of the JDK it's compiled against and the location of
the Java runtime on the installation server is picked up from environment
variables.  Problems occur when either the JDK is not at a supported level
or environment vararibles are not set properly.  The latest version of
TclBlend(Tcl + tcljava) overcomes this by embedding the JVM runtime in it's
install directory.  It ships with it's own JVM.

The Windows beta version is available here:

http://www.patrickfinnegan.com/

I suppose the holy grail for dynamic languages and Java is really reverse
JNI i.e a C runtime environment inside the JVM that would allow JAVA to
support any C based interpreted language natively without the need for
expensive rewrites in Java.  Java needs something conceptually similar to
the Common Language Runtime engine in the .NET framework that would allow
transparent execution of C processes under Java.  Application portability 
across Java and C runtime environments is the best way to attract dynamic 
language developers to Java.

[tcljava-dev] Dynamic Languages on the JVM: The Future

[Charles O. N. <cha...@su...>]

(Hi there Tcl enthusiasts and Jacl devs! This is kind of a form letter, 
but I'm serious about getting this event together with devs from 
multiple languages. I'd love to hear your thoughts on such an event and 
see if you'd be interested in attending.)

Hello all!

I am attempting to organize an outside event for JavaOne this year 
entitled "Dynamic Languages on the JVM: The Future". It is my intent to 
have as many alternative (dynamic) language implementers together in the 
same place as well as Java and JVM developers and specifiers. This would 
be our opportunity to talk about areas that have caused us trouble, 
features we'd like to see in Java or the JVM (or features we'd like to 
remove) and other related topics. I really want to break down the 
boundaries between the language implementations/implementers so we can 
cooperatively work toward making the JVM a more dynlang-friendly platform.

Ideally we'd have as many of your core team as possible (or others, as 
you see fit) in attendance. I'll be there, as will at least Tom Enebo 
and Ola Bini of the JRuby team. I'm also reaching out to other language 
teams in hopes of having a really good cross-language discussion.

The event would likely be hosted at a nearby hotel, bar, or restaurant. 
I'd like it to be pretty informal, but somewhere we can actually talk.

It would help my cause to get this event organized (and funded) if I 
could get a vote of confidence from likely attendees. Many high-level 
folks at Sun have already voiced their approval, and I think this is an 
excellent opportunity for us to show that real cooperation between the 
dynlang impls is possible and that it would be productive.

Please feel free to reply on this list (assuming the owners don't mind) 
or in private if you have questions or to voice your opinion. This is 
going to be a big year for dynlangs on the JVM, and we need to make sure 
things keep moving in the right direction.

-- 
Charles Oliver Nutter
JRuby Core Developer
Senior Staff Engineer
Sun Microsystems, Inc
_______________________________________________
dev-tech-js-engine mailing list
dev...@li...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

[tcljava-dev] JACL eval cancellation

[Wei D. <wd...@fn...>]

HI,

=20

Is it possible that an eval command can be cancelled during its
execution? It does not seem to have any API to do this, but I wonder if
there is way to achieve this in the current JACL implementation, e.g Can
I use Interp.setInterrupted to achieve this?=20

=20

Thanks a lot in advance,

=20

Wei

Re: [tcljava-dev] tcljava-dev Digest, Vol 4, Issue 3

[Patrick F. <pfi...@oz...>]

> A new binary release that combines Tcl, Thread, Tk, Tcl Blend, and Sun's
> JDK 1.4
> is now available for testing. This binary is for Win32 systems and
> should just work
> "out of the box" with no compilation.
>
> http://www.modejong.com/tcljava/handoff/tclBlend140Binary.zip
>

I have wheeled the binary through all my tcljava scripts with no issues bar 
the "DriveManager" tclclasspath problem which is present in all versions of 
tcljava/jacl.

Should we announce the distro on comp.lang.tcl and get more people interested?
   

Re: [tcljava-dev] TJC and ITcl Methods

[Mo D. <mo...@mo...>]

Bruce Johnson wrote:
> Mo,
>
> Does TJC compile ITcl methods?  If not, how much work would be  
> involved to do that?
>
> Bruce
>
>   
No, TJC does not compile Itcl methods. I think it would take 2 to 3 weeks
of effort to compile Itcl methods. It would be possible to compile the 
commands
inside an Itcl method, but class variables and class methods would be 
really tricky
to cache properly.

Mo DeJong

[tcljava-dev] TJC and ITcl Methods

[Bruce J. <nm...@ma...>]

Mo,

Does TJC compile ITcl methods?  If not, how much work would be  
involved to do that?

Bruce

[tcljava-dev] Tcl Blend 1.4.0 binary for Win32 available for testing

[Mo D. <mo...@mo...>]

Hello

A new binary release that combines Tcl, Thread, Tk, Tcl Blend, and Sun's 
JDK 1.4
is now available for testing. This binary is for Win32 systems and 
should just work
"out of the box" with no compilation.

http://www.modejong.com/tcljava/handoff/tclBlend140Binary.zip

If folks could give it a try that would be great.

thanks
Mo DeJong

Re: [tcljava-dev] Question about Tcltk - Request for some new command options

[Mo D. <mo...@mo...>]

 > The reason I'm writing this mail is because I recently tried to interpet
 > some tcl source files from my java application but run into some 
problems.
 > I got some errors using the tcl regexp command, in particular I got an
 > error about using the -all option with regexp.My question is will there
 > be anynew version that supports the latest regexp (and other tcl
 > commands) options like -all ?

Hello Charalampos

Current, the Jacl regexp and regsub commands support only the earlier 
Tcl 8.1
style regexp syntax. It should be possible to upgrade the RE syntax now that
Java 1.4 includes a regexp package. Still it is a bit of work and would 
require
perhaps a week and a half of developer time to implement.

Mo DeJong

[tcljava-dev] Got Tclblend working with Active State Tcl.

[<pat...@hs...>]

I managed to generate a portable binary version of the TclBlend extension
for the Windows platform.  I did some limited testing with the Active State
Tcl distro using the normal package installation procedure i.e copy
tcljava1.3.2 to C:\Tcl\lib\tcljava1.3.2.  No compilation required.  It
seemed to work quite well.

C:\Tcl\bin>tclsh84

% package require java
1.3.2

% puts  [ java::call System getProperty user.dir ]
C:\Tcl\bin

% java::import java.net.InetAddress

%  puts "My IP Address is: [ [ java::call InetAddress getLocalHost ]
getHostAddress ] "
My IP Address is: XXX.XX.XX.XX

% package require snack
2.2
% package require Expect
5.43

Do we have a regression test suite for tcljava?

Would anyone like to volunteer for testing.  I can ftp the binary.  It has
an embedded JVM so it's 80 megabytes in size.


Regards .


Patrick Finnegan.


************************************************************
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority
************************************************************


-----------------------------------------
SAVE PAPER - THINK BEFORE YOU PRINT!

This E-mail is confidential.                      
                                                  
It may also be legally privileged. If you are not the addressee you
may not copy, forward, disclose or use any part of it. If you have
received this message in error, please delete it and all copies
from your system and notify the sender immediately by return
E-mail.
                                                  
Internet communications cannot be guaranteed to be timely secure,
error or virus-free. The sender does not accept liability for any
errors or omissions.