There are some efforts underway to look at putting support for languages such as Tcl into Eclipse (www.eclipse.org, for those unfamiliar with it).
One of the things that's being gauged currently is what large groups of users for each language would be interested, especially corporations. So for those of you out there who work someplace where Tcl is used heavily by large numbers of people, like it is here at Cisco, I'd be interested in hearing from you.
I work for a Science Museum, but before that I had worked developing Automation tools for the semiconductor industry. We used Tcl/Tk a lot for software testing.
We're currently implementing the RUP process and introducing Rational TestManager. Towards the end of the year Rational plan to deliver their next generation testing tools based around Eclipse (Haydes).
As our main test automation language is Tcl (lots of Perl in the company too) I'm keen to see Tcl in Eclipse.
At the moment I've almost no exposure to Eclipse - I've downloaded it but not really been using it.
> There are some efforts underway to look at putting support for > languages such as Tcl into Eclipse (www.eclipse.org, for those > unfamiliar with it).
> One of the things that's being gauged currently is what large groups of > users for each language would be interested, especially corporations. So > for those of you out there who work someplace where Tcl is used heavily > by large numbers of people, like it is here at Cisco, I'd be interested > in hearing from you.
> One of the things that's being gauged currently is what large groups of > users for each language would be interested, especially corporations. So > for those of you out there who work someplace where Tcl is used heavily > by large numbers of people, like it is here at Cisco, I'd be interested > in hearing from you.
We use Tcl for testing, launching and configuring applications, and some inter-application processing like parsing command grammars. We don't use Eclipse now, but were discussing it today and wondering about using it with Tcl and C++. Sounds like a good idea. BTW we've about 8 on our team.
> Bill Schongar wrote: > <snip> >> One of the things that's being gauged currently is what large groups of >> users for each language would be interested, especially corporations. So >> for those of you out there who work someplace where Tcl is used heavily >> by large numbers of people, like it is here at Cisco, I'd be interested >> in hearing from you.
> We use Tcl for testing, launching and configuring applications, and some > inter-application processing like parsing command grammars. We don't use > Eclipse now, but were discussing it today and wondering about using it > with Tcl and C++. Sounds like a good idea. BTW we've about 8 on our > team.
> Regards,
> Bob Oliver
Eclipse was originally a java IDE developed by IBM as a replacement for the "Visual Age For Java" IDE which had a proprietary non extensible architecture. IBM designed Eclipse with an open extensible API to allow the addition of third party features known as plugins, then open sourced the base product.
The plugins are written in Java so any attempt to add Tcl support to Eclipse involves learning Java and writing lots of Java code. The end result would be a very slow primitive Tcl debugger with syntax highlighting inferior to even the open source TCL development environments. Building in support for TK and the other popular Tcl libraries would be even more work.
The Tcl community would be better off releasing up to date versions of TclBlend and JACL in an easily deployable format i.e Windows binaries. Enabling Tcl connectivity to java class libraries and java applications in remote JVMs is much more important than building yet another IDE.
Patrick wrote: > Eclipse was originally a java IDE developed by IBM as a replacement > for the "Visual Age For Java" IDE which had a proprietary non > extensible architecture. IBM designed Eclipse with an open > extensible API to allow the addition of third party features known > as plugins, then open sourced the base product.
> The plugins are written in Java so any attempt to add Tcl support > to Eclipse involves learning Java and writing lots of Java code. ...
> The Tcl community would be better off releasing up to date versions > of TclBlend and JACL ...
Unless I'm quite confused, TclBlend and JACL aren't IDEs which is what we're talking about here.
Yes, Eclipse is Java-based. Yes, writing a Tcl plug-in for Eclipse would require Java programming. No, myopic Tcl experts wouldn't be up to that task. But there are lots of polyglots 'round here and Eclipse seems to offer a good platform to build on (that's kind of the point). We'd have to write a Tcl parser in Java but we'd get an interface to Make and Ant and CVS, a syntax highlighting editor, refactoring tools, etc., etc.
While I have no use for visual design tools (emacs makes a fine Tk layout tools, thankyouverymuch), IDEs for code are great. If I can use Eclipse for a multi-language project where one of those languages is Tcl or for multiple projects, some of which are in Tcl, that's a win for me. I'd like to see a full-features plug-in for Tcl. I might even find time to contribute to the effort and I have a couple of years' of Java experience to get me started.
Patrick wrote: > The plugins are written in Java so any attempt to add Tcl support to Eclipse > involves learning Java and writing lots of Java code. The end result would > be a very slow primitive Tcl debugger with syntax highlighting inferior to > even the open source TCL development environments. Building in support for > TK and the other popular Tcl libraries would be even more work.
Actually the effort being looked at is a bit less simplistic than just a Tcl language plugin - it's concerned with the core capabilities to support languages besides Java, and would involve Perl, Python, et al.
I'm not the best one to go into the details here in c.l.t, but for anyone who's interested email me offline with your contact info and I'll put you in touch with the appropriate people for those details.
I'm just collecting names and such specifically for Tcl support.
> Patrick wrote: >> Eclipse was originally a java IDE developed by IBM as a replacement >> for the "Visual Age For Java" IDE which had a proprietary non >> extensible architecture. IBM designed Eclipse with an open >> extensible API to allow the addition of third party features known >> as plugins, then open sourced the base product.
>> The plugins are written in Java so any attempt to add Tcl support >> to Eclipse involves learning Java and writing lots of Java code. ...
>> The Tcl community would be better off releasing up to date versions >> of TclBlend and JACL ...
> Unless I'm quite confused, TclBlend and JACL aren't IDEs which is what > we're talking about here.
> Yes, Eclipse is Java-based. Yes, writing a Tcl plug-in for Eclipse > would require Java programming. No, myopic Tcl experts wouldn't be up > to that task. But there are lots of polyglots 'round here and Eclipse > seems to offer a good platform to build on (that's kind of the point). > We'd have to write a Tcl parser in Java but we'd get an interface to > Make and Ant and CVS, a syntax highlighting editor, refactoring tools, > etc., etc.
> While I have no use for visual design tools (emacs makes a fine Tk > layout tools, thankyouverymuch), IDEs for code are great. If I can use > Eclipse for a multi-language project where one of those languages is > Tcl or for multiple projects, some of which are in Tcl, that's a win > for me. I'd like to see a full-features plug-in for Tcl. I might even > find time to contribute to the effort and I have a couple of years' of > Java experience to get me started.
> Chris
Fine in theory but...................................
Have a look at the plugins for Perl(EPIC) and Python(Pydev).
Comment from Python programmer on Eclipse with Pydev.
"I've used it for some java stuff and know plenty of people that do every day and they all love it for Java, but having tried using it for anything else it's next to useless. In fact it's worse than a plain editor in some ways when your not using it for Java".
Eclipse is big and slow and needs a lot of expertise to configure it properly for just java development. The Eclipse based commercial IBM java development environment(WSAD) requires 7000 IBM plugins and retails at $5000 US per license before volume discounts. By Comparison the Active State TCl/Perl IDE Komodo retails for $295 US before volume discounts. Active State are practically giving it away.
In my opinion the best approach to Tcl/Java IDE integration is to take something like Komodo and embed the Sun JVM with a jacl or tcl interface. CISCO could pay Active State to do this. It's not like CISCO are short of cash!
"Patrick" <chppxf1@No_SPAMozemail.com.au> wrote in message <news:iXb3e.228$v47.5548@nnrp1.ozemail.com.au>... > The plugins are written in Java so any attempt to add Tcl support to Eclipse > involves learning Java and writing lots of Java code. The end result would
Not for people who are familiar with (at least) java.
> be a very slow primitive Tcl debugger with syntax highlighting inferior to
Java is not slow. It can be *made* slow, of course ;-). The only bad thing about eclipse is the startup time, but except that it is really great IDE.
> even the open source TCL development environments. Building in support for > TK and the other popular Tcl libraries would be even more work.
I am sure that TclBlend could be employed for that.
> The Tcl community would be better off releasing up to date versions of > TclBlend and JACL in an easily deployable format i.e Windows binaries. > Enabling Tcl connectivity to java class libraries and java applications in > remote JVMs is much more important than building yet another IDE.
Yes it is important. And having some people coding on an eclipse plugin using TclBlend will probably have nice side effects on TclBlend.
Using eclipse for multilanguage projects (currently writing an app in C[++]/Tcl), I would definitely appreciate an eclipse Tcl-Plugin and would support the work as well as I can. Sadly I can only do this in a very limited part of my spare time...
eck...@web.de (Eckhard Lehmann) writes: > And syntax completion - one of the most useful features in Eclipse
In Italy, the phrase people use for this sort of thing is "discovering hot water". Syntax completion of various types has been available for years in Emacs and Vim.
> > And syntax completion - one of the most useful features in Eclipse
> In Italy, the phrase people use for this sort of thing is "discovering > hot water". Syntax completion of various types has been available for > years in Emacs and Vim.
I am using Vim for Tcl and other things - but have not discovered this until now. Can you give me a hint how to have syntax completion with Tcl and Vim?
eck...@web.de (Eckhard Lehmann) writes: > I am using Vim for Tcl and other things - but have not discovered > this until now. Can you give me a hint how to have syntax completion > with Tcl and Vim?
I'm in the emacs camp myself, but my vim using friends tell me that it's possible... I'll let one of them answer.
Uwe Koloska <kolo...@voiceinterconnect.de> writes: > David N. Welton wrote: > > I'm in the emacs camp myself, > And how is (syntax) completion done in (X)emacs? I have searched > for something like intellisense for years ...
You can do 'dumb' completion with alt-/ which is usually enough for me.
This looks like it might be an improvement over that:
Eckhard Lehmann wrote: > Is there a language definition file for Tcl somewhere (probably yes)? > Javacc (https://javacc.dev.java.net/) could be used to write this > parser.
Umm, Tcl doesn't work like that. Sure, you could define a LL(1) or LR(1) grammar[*] but it wouldn't help; the language is not usefully defined in a context-free way.
Donal. [* Just encode the rules in the Tcl(n) manual page. ]
The problem with writing a syntax parser for Tcl (for use in highlighting) is that almost everything is "discovered" at runtime. While it's possible to make educated guesses which are right the vast majority of the time, it's not uncommon to have pieces of text that could be either data or code.
Even the tcl-mode for emacs has issues. A large number of people have worked on making it better, but I have yet to see anyone get it completely right.
I don't think it's so tough to write a syntax-hilight parse for tcl. I'd image only a few rules are required. These may be a little simplified, but off the top of my head you do pretty decent highlighting with just a few regexps
{ (^|[\[])\s+(\S)\s} (\S component will be a command) {[$]\S} (variable) {(\"|\').*(\"\')} (quoted string) {#.*$} (comment)
But I agree with you that getting it 100% perfect is pretty damn hard and probably not worth the effort or processing power.
"bryan.schofi...@trans.ge.com" <bschofi...@users.sf.net> wrote in message <news:1112635858.337520.191820@z14g2000cwz.googlegroups.com>... > I don't think it's so tough to write a syntax-hilight parse for tcl. > I'd image only a few rules are required. These may be a little > simplified, but off the top of my head you do pretty decent > highlighting with just a few regexps
> { (^|[\[])\s+(\S)\s} (\S component will be a command) > {[$]\S} (variable) > {(\"|\').*(\"\')} (quoted string) > {#.*$} (comment)
> But I agree with you that getting it 100% perfect is pretty damn hard > and probably not worth the effort or processing power.
The another way is to simulate a first level of tcl processing. The syntax hightlight in XOTclIDE (http://www.xdobry.de/xotclIDE) is programmed such way. Idea: Tcl script is a list. Tcl command is a list. A parameter of command can be script (example: for while if) Command "for" has parameter in list form: script expr script script
The same is used for syntax checking. (discovering for variable names) It works good for most tcl scripts. The problem are self defined control structures and data that contains scripts.
Sadly, those regexps fail in many, many cases. It's those cases where it starts to get really hard to fontify things. As an example:
string map {" &dquot;}
The above will blow up on te quoted string regexp. As another note, the single quote doesn't create strings in Tcl, does it?
The variable regexp blows up in some places, and the comment regexp needs to be told only to apply when it would be the start of a command, and that \ means it continues to the next line.
In addition, quotes and the like in a comment should change the fontification, in my opinion. There's just a TON of special cases.
bryan.schofi...@trans.ge.com wrote: > I don't think it's so tough to write a syntax-hilight parse for tcl. > I'd image only a few rules are required. These may be a little > simplified, but off the top of my head you do pretty decent > highlighting with just a few regexps
> { (^|[\[])\s+(\S)\s} (\S component will be a command) > {[$]\S} (variable) > {(\"|\').*(\"\')} (quoted string) > {#.*$} (comment)
> But I agree with you that getting it 100% perfect is pretty damn hard > and probably not worth the effort or processing power.
> > I am using Vim for Tcl and other things - but have not discovered > > this until now. Can you give me a hint how to have syntax completion > > with Tcl and Vim?
> I'm in the emacs camp myself, but my vim using friends tell me that > it's possible... I'll let one of them answer.
I found out (using Google ;-), that it works by putting the following into ~/.vimrc (~/_vimrc) --- function InsertTabWrapper() let col = col('.') - 1 if !col || getline('.')[col - 1] !~ '\k' return "\<tab>" else return "\<c-p>" endif endfunction inoremap <tab> <c-r>=InsertTabWrapper()<cr> --- It does syntax completion for other languages too...
