Evaluating TCL
Robert Keane
Financial Apps where the browser is running on Linux and I suppose Windows.
The Apps will have to have read/write access to the local file system,
after whatever security procedure is necessary to do so safely, but it
does not bother me that the only browser supported will be Mozilla/Firefox.
Questions that have not been answered by my initial look at TCL are :
1) Is there CGI support for TCL, an Apache module? fastcgi?
2) Is there any support for using Dollar amounts, direct dollar
arithmetic, formatting in columns, leading zero supression etc.
3) XML, librarys for parsing input or creating new xml files.
Regards,
R Keane
Gennadiy
> I'm trying to select a language to use to develop browser based
> Financial Apps where the browser is running on Linux and I suppose Windows.
>
> The Apps will have to have read/write access to the local file system,
> after whatever security procedure is necessary to do so safely, but it
> does not bother me that the only browser supported will be Mozilla/Firefox.
>
> Questions that have not been answered by my initial look at TCL are :
> 1) Is there CGI support for TCL, an Apache module? fastcgi?
http://www.aolserver.com/
http://wiki.tcl.tk/1389
>
> 2) Is there any support for using Dollar amounts, direct dollar
> arithmetic, formatting in columns, leading zero supression etc.
>
> 3) XML, librarys for parsing input or creating new xml files.
http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcldom/index.html
http://aspn.activestate.com/ASPN/docs/ActiveTcl/tclxslt/index.html
>
> Regards,
>
> R Keane
Robert Keane
Gennadiy wrote:
> Robert Keane wrote:
>>I'm trying to select a language to use to develop browser based
>>Financial Apps where the browser is running on Linux and I suppose Windows.
>>
>>The Apps will have to have read/write access to the local file system,
>>after whatever security procedure is necessary to do so safely, but it
>>does not bother me that the only browser supported will be Mozilla/Firefox.
>>
>>Questions that have not been answered by my initial look at TCL are :
>>1) Is there CGI support for TCL, an Apache module? fastcgi?
>
> http://tcl.apache.org/
> http://wiki.tcl.tk/1389
>
>>2) Is there any support for using Dollar amounts, direct dollar
>>arithmetic, formatting in columns, leading zero supression etc.
>
> http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcl/TclCmd/format.htm
>
>>3) XML, librarys for parsing input or creating new xml files.
>
> http://tclxml.sourceforge.net/
>
>>Regards,
>>
>>R Keane
>
I appreciate you reply greatly.
I'm not sure I even want to ask this next question as I don't want to
start a religious war but here goes.
My language search has narrowed to TCL, Python and a newcommer, to me at
least, RealBasic. Would you care to voice an opinion on ant or all of my
choices?
Regards,
Robert Keane
Earl Grieda
"Robert Keane" <rke...@acm.org> wrote in message
news:07IWe.76$zG1.72@trnddc05...
> I'm trying to select a language to use to develop browser based
> Financial Apps where the browser is running on Linux and I suppose
Windows.
>
> The Apps will have to have read/write access to the local file system,
> after whatever security procedure is necessary to do so safely, but it
> does not bother me that the only browser supported will be
Mozilla/Firefox.
>
> Questions that have not been answered by my initial look at TCL are :
> 1) Is there CGI support for TCL, an Apache module? fastcgi?
I write my CGI programs in Tcl and use the ncgi package included in Tcllib.
I prefer Tcl because it produces readable, understandable code that, for
most purposes, executes extremely fast, and, so far, has been capable of any
programming task I needed.
Gennadiy
you listed. I did not even know that REALbasic exists. I have only used
Microsoft technologies: FoxPro, SQL Server, Visual Basic, a little bit
of C#. The only reason that I was able to provide you with some
hyperlinks is that I am learning Tcl right now. I want to start using
open-source stuff and decided to learn one of the scripting languages.
I did my research over the Internet and this is what I have found:
* Perl - unnecessary complicated syntax, write-only , not clear
when version 6 will be ready, why to learn version 5.8 if version 6
will be very different, many people hate Perl.
* Ruby - not very popular in North America (ActiveState does not
support it).
* PHP - very web oriented, not good enough for general purpose.
* Python, Tcl/Tk - both are very good. Tcl is amazingly flexible,
even difficult to understand, has built-in GUI. Python has more stuff
for Win32.
davidh...@simplifiedlogic.com
Komodo debugger is great - and can even emulate CGI Tcl Scripts right
in the debugger!
It also makes learning easier because the interface points out problems
in your code for you (much like Word highlights misspelled words).
You will find Tcl and a Database a perfect match with CGI. Fast,
flexible and super easy to learn/use. We have been writing production
code with this for about 8 years with much success, stability, and
performance.
Not to mention the Tcl community is a great resource for solving
problems - someone always willing to help and answer questions.
Best of Luck!
Dave
David N. Welton
I don't know anything about RealBasic. Python is a good language, as is
Tcl. Mostly, the "whitespace issue" in Python is a non-issue, but in
the web programming field I think it is more important. Tcl is a bit
more robust if you have multiple people working on files and perhaps mix
HTML and Tcl in templates, and so on... I don't think it's by accident
that most big web programming systems in Python have a template language
that's not actually Python.
--
David N. Welton
- http://www.dedasys.com/davidw/
Apache, Linux, Tcl Consulting
- http://www.dedasys.com/
Eckhard Lehmann
> My language search has narrowed to TCL, Python and a newcommer, to me at
> least, RealBasic. Would you care to voice an opinion on ant or all of my
> choices?
I don't know RealBasic, but Python and Tcl.
Python always seems to be very slow to me. I have seen many Python
scripts ("programs") so far, and always they eat up heaps of memory and
CPU time. The language itself looks and feels like Java but much slower.
I tried several times to motivate myself to learn and use Python,
because of the hype that goes around everywhere - but always found after
some time that I could just stick to Java instead of learning another
new scripting language. It seems that Python aims to be a fully
functional programming language, but it is and will be a weakly typed
scripting language. IMHO the weak typing is the problem that doesn't
make it a good choice for big projects.
Tcl is weekly typed as well ("everything is a string..."), but there is
no big deal with this - Tcl is a scripting language, dot. Nevertheless
there are very good (and also large) programs around, written in Tcl/Tk.
They are running on every platform, they run fast and the sources are
easy to read, if you feel like fixing some bugs here and there. Programs
like TkCvs, Tkdiff, VisualRegexp or Insight I have come to love over time.
If the weak type system is a problem, it is easy to extend Tcl with
strong typed languages ("real" programming languages ;-), C/C++ is
available adhoc, Java binding and -implementation exist as well (.Net
too, I believe...(?)). That is btw the way I use Tcl/Tk - develop
reusable components/libraries in C(++)/Java and connect them with Tcl
scripts and Tk interfaces + extensions to build complete programs. I've
found this to be a very flexible and fast way for program development...
Eckhard
tcl...@gmail.com
Otherwise you will need to find a host that supports Tcl. PHP is good
for the web only (pretty much) but has a lot of hosting support for
mod_php. Perl is easy to find hosting for as a CGI but mod_perl hosts
are hard to come by as well. Perl (and Tcl) lets you program from the
prompt to the web and all stops in between.
For Tcl, look to Rivet to help you out if you are using Apache (not
Apache2). There is a dev list that is really helpful. I think hands
down the nicest community as well.
For Python, there is Django, Myghty and a few other frameworks. Both of
the mentioned frameworks look really good. Myghty is a port of Mason to
Python and takes care of the "whitespace" issue for you.
For Perl, there is Template-Toolkit (my fav), Mason, CGi::Application,
or Catalyst. It isn't a "write only" language as I write clear concise
code myself that can be read months later (although sometimes I wonder
what I was thinking).
For Ruby, not mentioned but I will, there is Ruby on Rails which is
getting a lot of looks nowadays. I am not a big fan of Ruby but I
thought I would mention it anyway.
For PHP, look as Smarty as the template language. It is really nice. I
have used that as well.
I realize I may have given you too much to think about but "knowledge
is power". : )
I hope that helps in some way...
Robert
Michael A. Cleverly
>> 3) XML, librarys for parsing input or creating new xml files.
>
> http://tclxml.sourceforge.net/
Also consider tDOM:
http://www.tdom.org/
http://wiki.tcl.tk/tdom
Michael
Cameron Laird
Eckhard Lehmann <eck...@web.de> wrote:
.
.
.
>new scripting language. It seems that Python aims to be a fully
>functional programming language, but it is and will be a weakly typed
>scripting language. IMHO the weak typing is the problem that doesn't
>make it a good choice for big projects.
.
.
Python is strongly typed. It is *dynamically* strongly typed,
but remains arguably more strongly typed than Java. I frequently
advance the argument that Python is the *best* single language
for large projects (although Smalltalk, Eiffel, ... also have
legitimate claims).
Might you be writing "weakly" where I think "dynamically"? I
agree that Python diagnoses type errors only at run-time.
Eckhard Lehmann
> Might you be writing "weakly" where I think "dynamically"? I
> agree that Python diagnoses type errors only at run-time.
Yes, that 's what I mean - so the typing system is a different thing...
ok, I thought this is closely related or the same. What I meant is that
it is not necessary with Python and other script languages, to specify
the data type. E.g.:
a = 2
b = "string"
rather than
int a = 2;
char *b = "string"; // (or "String b"...).
This causes many runtime errors, as we have seen in our Tcl projects.
These errors are (among others) often not detected until runtime, when
the program is running for your customer - and this is usually very bad...
A syntax checker that supports some level of type checking would be nice
for dynamic languages ;)
Eckhard
Darren New
> Yes, that 's what I mean - so the typing system is a different thing...
Just for the record...
static typing: Variables have a specific type assigned at compile time.
dynamic typing: Values have a specific type determined at run time.
strong typing: the semantics of using a value of a given type where a
different type is expected are well-defined.
weak typing: the semantics of using a value of a given type where a
different type is expected is not well-defined.
And one more pair that's important:
safe: Every operation has a known and well-defined semantic effect.
unsafe: Some operations have an unknown semantic effect.
Note that a lot of multi-user operating system stuff is designed to
build a "safe" playpen for your unsafe languages. Catching a bad pointer
and turning it into a core dump changes C from being "unsafe" to "safe"
in the Unix context, in some sense. You often see even multi-user
systems built without any memory mapping hardware etc when the only
languages running on the system are safe.
C is weakly statically typed, because you declare the types of variables
but you can (for example) point an int* at a float. It's also unsafe, as
the standard doesn't say what happens when you do things like this.
Smalltalk is strongly dynamically typed, because you don't declare the
types of variables, but every value is of a specific class that doesn't
change. Every time you try to do something "wrong", you have a
well-defined response, so it's safe.
Java is both statically and dynamically typed by this definition, which
is kind of odd. The variable can be class Stream, and the value can be
class FileStream or StringStream or whatever. Most OO languages with
inheretance based on type are like this. Java is also supposed to be
safe, preventing one instance from groping into another instance's
variables, for example, altho of course the implementation has to be
unbuggy.
Machine language is neither statically nor dynamically typed, as neither
values nor the places you store them generally have types. (Excluding
Burroughs B-series computers, FPU registers, etc.) Interestingly enough,
it's probably still strongly typed, as using (for example) an odd-valued
integer as an address causes a trap. (Again, depending on the machine.)
This is generally called an untyped language. FORTH falls into this
category too.
Similarly, I think Tcl is neither statically nor dynamically typed, but
it is safe (again, modulo bugs). For example, the reason "safe
interpreters" are safe is there isn't any way for code running in a safe
interpreter to overwrite the tables in the master interpreter to give it
additional privs. Of course, with Tcl_Obj tech, one could think of
values having particular types. Or one could consider "123" a list, an
integer, *and* a string. But generally, if the same value can have
multiple types, you're usually looking at an untyped language.
Ada uses a somewhat different terminology that makes a lot of sense for
a type system that complex. In Ada, a "type" is a collection of values,
essentially those that can be assigned to a particular variable. This
allows for you to have two variables each of which are in every way
compatible with integers but which are not compatible with each other,
which is a useful feature sorely lacking in every other language I know
of besides Pascal. You also have subtypes (integers in the range 0 ..
100, say), class types (which is a parent type and all its children
types), and then a whole bunch more.
--
Darren New / San Diego, CA, USA (PST)
"Rabbit beer, now with organic hops!"
eck...@web.de
before, resp. that it was not really clear to me - now I understand...
;-)
Eckhard
Cameron Laird
Donal K. Fellows <donal.k...@manchester.ac.uk> wrote:
.
.
.
>Hmm. But by your definitions [elide above] I'd also characterize Tcl as
>strongly typed (we've got something of an obsession with failing fast).
.
.
.
My programs fail quickly and dramatically! Despite my mathematical
background, which obliges me to note that type theory is one of the
best abstract things computing has going for it, on an engineering
basis I think the degradation trajectory of my work far more
important. So: part of Tcl's success is that it is a language
which helps its authors find their errors quickly--even quicker'n
through pure type checking.
Donal K. Fellows
> Similarly, I think Tcl is neither statically nor dynamically typed, but
> it is safe (again, modulo bugs). For example, the reason "safe
> interpreters" are safe is there isn't any way for code running in a safe
> interpreter to overwrite the tables in the master interpreter to give it
> additional privs. Of course, with Tcl_Obj tech, one could think of
> values having particular types. Or one could consider "123" a list, an
> integer, *and* a string. But generally, if the same value can have
> multiple types, you're usually looking at an untyped language.
Hmm. But by your definitions [elide above] I'd also characterize Tcl as
strongly typed (we've got something of an obsession with failing fast).
Odd combo that, strongly typed but untyped. :-)
Donal.
Darren New
> Hmm. But by your definitions [elide above] I'd also characterize Tcl as
> strongly typed (we've got something of an obsession with failing fast).
I'd disagree. I'd say it's untyped, but safe. What makes you think it's
strongly typed? I can easily misinterpret a string as a list. It'll fail
if the string isn't a valid list (which means it's safe), but it'll work
if it is (which means it's weakly typed). You can't look at a value and
tell what type it is, unless there's really only the type "variable
value". I.e., if you distinguish the type "proc" from the type
"command" from the type "variable value" for example, then you might
have various types. But if you're just looking at things that could
serve as the final argument to [set], I think you don't have any sort of
strong typing there. Just safety.
But of course, with a sufficiently outside-the-usual language, the
boundary cases get harder to clarify in a way that everyone will agree on.
Neil Madden
healthy, so I'll add a few comments of my own. For readers not
interested in musings about Tcl's semantics, feel free to skip this
long, rambling post.
Darren New wrote:
<snip good definition of typing "dimensions"/>
I'd add that a definition of "safety" I read recently was having
unbreakable abstractions. For instance, Tcl abstracts over pointers and
memory layout and the fact that I can't break that abstraction means
that I am safe from dangling pointers. There is a tension between
safe/unbreakable abstractions and "leaky" abstractions, though. The
higher level an abstraction is, the more specific and less general it
also is, and so the more likely it is that you might want to break it.
Most languages provide some base layer of unbreakable abstractions.
Tcl provides a bunch of unbreakable abstractions, including channels,
variables, namespaces, commands etc. These are generally kept
consistent, and it is not possible from Tcl to mess around with their
internal implementation or render them unusable or unrecoverable. Where
Tcl differs from most other languages is that it only provides a single
unbreakable data type: the string. [I'll distinguish types used for data
abstraction, like strings, lists etc from those used for functional
abstraction (procs, classes) or naming/relational abstraction
(variables, arrays, namespaces)]. All other data types are layered on
top of strings, just as data types in other languages are built in terms
of ints, chars, doubles, etc. The advantage of strings is that they are
extremely flexible representation medium, and as such very much
domain-independent. Most languages start from strings (source code) and
then build up their basic types from there during parsing. Tcl leaves
everything as strings, and essentially leaves parsing and data
abstraction up to individual commands. This is what gives Tcl its power
as a glue language, as those individual commands are then free to place
widely different domain-specific interpretations on the values they are
passed instead of being constrained by some pre-existing interpretation
enforced by the language. Ironically, it is because Tcl as a base
language does *less* for you than other languages that it is so widely
useful!
But of course, that is only half the story, because Tcl does layer
abstractions over the top of strings: lists, dicts, numbers, scripts,
commands and all the other types you'd expect from a language. This is
essential, as you can't do anything without putting some interpretation
on your values (which implies a type), and manipulating everything as
strings would be insane. These types are implemented behind the scenes
by parser functions (e.g., Tcl_GetIntFromObj or whatever it calls) which
actually do the real work of abstraction; extracting relevant
information from the string[*]. Most commands then actually delegate to
these functions (either directly or indirectly) rather than actually
going about parsing and interpreting values themselves. These are proper
types in some sense, in that they can generate what can only be termed
"type errors" at runtime:
set x "foo"
incr x ;# expected integer but got "foo"
So in this sense, I'd say that Tcl is lazily typed or implicitly typed,
rather than untyped. I actually think this puts Tcl closer to some
statically-typed languages like Haskell or ML, which can infer type from
usage and associate types with "names" (variables/parameters/functions)
rather than values. Of course, it's generally not possible to infer the
types of values in Tcl statically, or put another way the most specific
type that can be inferred for many variables will be "string".
[ [*] Note that I am associating "type" with a parser function (which
implies a type) rather than with a Tcl_ObjType or internalRep structure,
which are just implementation details. ]
The downside of this is that Tcl does less to stop you breaking
abstractions, and generally allows you to break them on a variety of
different levels. Not on as low a level as C, but you can still e.g.,
manipulate lists with string commands and end up with a runtime error.
Tcl is thus weakly typed down to the level of strings, but still safe in
the sense that the error is predictable and reasonably well defined
behaviour. You can create unbreakable abstractions in Tcl, by creating
new commands that hide their workings. e.g., safe interpreters fall into
this category. One such abstraction you can create is that of a type
system, such as the various OO systems that provide strong dynamic
typing. TOOT does similar, but the abstractions are still breakable
(they're still strings), and so provides weak dynamic typing.
I'd like to extend TOOT to be able to also provide unbreakable
variables. Ideally, I'd like to be able to do (in an interactive session):
% set f [func: a b c { ... }]
...
% set typef [type infer $f]
a number b number c string
% type check $typef {a 12 b 14 c "Hello, World!"}
1
% type check $typef {a foo b 14 c "Hello, World!"}
expected number but got "foo" for variable "a" ...
% define foo $f
foo
The "type infer" will likely never work in Tcl as it is just too
dynamic. Type checking is definitely possible, and I am currently
working on a version for TOOT. The "define" command at the end takes a
value and turns it into an unbreakable abstraction -- i.e., it is not
possible to manipulate its representation directly any more and its type
becomes fixed. I think looking at ways to increase Tcl's data
abstraction capabilities are useful and type systems for Tcl can cover a
variety of points on the dynamic explicit/implicit weak/strong axes.
There is certainly some interesting areas to explore in between
everything-is-a-named-object/command and everything-is-a-string.
>
> Java is both statically and dynamically typed by this definition, which
> is kind of odd. The variable can be class Stream, and the value can be
> class FileStream or StringStream or whatever. Most OO languages with
> inheretance based on type are like this. Java is also supposed to be
> safe, preventing one instance from groping into another instance's
> variables, for example, altho of course the implementation has to be
> unbuggy.
I gather that quite a few statically typed languages are like this:
static typing where possible, dynamic typing everywhere else seems to be
the slogan. It's a reasonable trade-off, but until static type systems
get more flexible (which they are doing) then I think I'd prefer dynamic
typing by default with static typing where I specify it. There are
"soft" type systems for Lisp/Scheme (and possibly other languages) which
do something like this.
>
> Ada uses a somewhat different terminology that makes a lot of sense for
> a type system that complex. In Ada, a "type" is a collection of values,
> essentially those that can be assigned to a particular variable. This
> allows for you to have two variables each of which are in every way
> compatible with integers but which are not compatible with each other,
> which is a useful feature sorely lacking in every other language I know
> of besides Pascal. You also have subtypes (integers in the range 0 ..
> 100, say), class types (which is a parent type and all its children
> types), and then a whole bunch more.
>
I'm not familiar with Ada -- is this nominal or structural typing? The
value collection stuff sounds a bit like Ontic, which I'm also not very
familiar with, but apparently allows sets instead of types. It also
unifies that with non-determinism, IIRC, in that a function can return a
set of potential values that can be narrowed down by other functions
(presumably through set intersection).
Anyway, apologies for the long ramble.
-- Neil
Joe English
>Darren New wrote:
>> Similarly, I think Tcl is neither statically nor dynamically typed, but
>
>Hmm. But by your definitions [elide above] I'd also characterize Tcl as
>strongly typed (we've got something of an obsession with failing fast).
>Odd combo that, strongly typed but untyped. :-)
By Darren's definitions (which are pretty much standard
usage among those who care about such things), Tcl is firmly
in the "untyped" camp. The bumper-sticker version is:
static typing: Expressions have types
dynamic typing: Values have types
untyped: Types are implicit in the operations
Untyped languages are pretty rare; Tcl and Forth are the
only two popular (!) ones I can think of.
There's also:
strongly typed: "well-typed programs don't go wrong"
where "doesn't go wrong" has a precise mathematical meaning,
but it boils down to "if an expression has type T, then the
result of evaluating the expression also has type T."
Tcl can be said to be strongly typed, but that's not a terribly
interesting thing to say, since it's also monotyped (everything
is a string). Evaluating any script yields a <completion code, value>
pair [*]; and sure enough, you can pass any string to [eval]
and you'll always get back a completion code and a value.
The completion code might be TCL_ERROR, of course, and you
can't say anything about the value other than "it's a string",
but it doesn't go wrong.
--Joe English
[*] Plus some other stuff that hangs off the side.
Darren New
> I gather that quite a few statically typed languages are like this
Well, I more meant that it's both statically typed (variables have
types) and dynamically typed (values have types), but there are rules
that allow you to assign values of one type to variables of a different
type and still have everything work. (I.e., subclass values assigned to
superclass variables.)
> I'm not familiar with Ada -- is this nominal or structural typing?
Nominal, but quite complex.
> value collection stuff sounds a bit like Ontic, which I'm also not very
> familiar with, but apparently allows sets instead of types.
Well, it's more that Ada *defines* "type" to mean "a collection of
values" rather than some string, structure, name, etc. It's just how the
language talks about things. They do this because, for example:
type X = new integer 0..100;
type Y = new integer 50..70;
type Z = integer 0..100;
type w = integer;
Now, are X and Y the same type? X and Z? Are they compatible for
assignment? For comparison? I.e., "casting" is defined in terms of
intersections of types and such. The type system is wildly complex in
Ada, and provides for much of the run-time safety enforced at compile
time. Like, the reason you can't return a pointer to an "automatic"
variable defined in the function is based on the type rules.
i.e., in C you can do
int * f() { int x = 23; return &x; }
In Ada you can't, and it's caught at compile time because of a *type*
mismatch, which is kind of funky. Similarly for preventing having
multiple tasks having access to the same "global" variable, etc.
Any time I don't look at it for more than a few weeks, I forget how it
all works.
Anyway, that's getting way off topic. :-)
Antti Järvinen
> some bugs here and there. Programs like TkCvs, Tkdiff, VisualRegexp or
> Insight I have come to love over time.
Oh dear, what is the closet where this tkdiff thingie has been kept in?
I've been looking for decent beyond compare -replacement for some time
and this thing just lacks directory diff..
--
Costello the Warrior St:18/09 Dx:14 Co:18 In:8 Wi:12 Ch:7 Neutral
Dlvl:16 $:0 HP:129(129) Pw:52(52) AC:-6 Xp:14/83896 T:19462 Satiated
Don Libes
> Eckhard Lehmann <eck...@web.de> writes:
> > some bugs here and there. Programs like TkCvs, Tkdiff, VisualRegexp or
> > Insight I have come to love over time.
>
> Oh dear, what is the closet where this tkdiff thingie has been kept in?
> I've been looking for decent beyond compare -replacement for some time
> and this thing just lacks directory diff..
'eskil' is a version of tkdiff that has directory diff. It also shows
exactly where (character by character) two lines differ. Cool stuff.
Weird name.
Don
Donald Arseneau
> I've been looking for decent beyond compare -replacement for some time
> and this thing just lacks directory diff..
Have you checked dirdiff?
--
Donald Arseneau as...@triumf.ca
Jeff Godfrey
news:m3zmpqmg...@fisuvaan.localdomain...
While not a Tcl based tool, I think kdiff3 is one of the best comparison /
merge utilities available.
It does 2 and 3 file comparisons and merging, can do directory comparisons,
displays both line and character differences, supports UNICODE, has
automatic merging capabilities, and a built-in editor for resolving merge
conflicts.
It's completely FREE and distributed under a GPL license. Also, it's
multi-platform, so you can get versions for Windows, Linux, *nix, and Mac
OS X.
It can be found here:
http://kdiff3.sourceforge.net/
Jeff