Does TCL fit my requirements ?
llothar
i have to move away from python as an embedded language for my current
project and find something else. My requirements are
1) a lot of high level functions either as primitives (C compiler) or
in TCL scripts.
2) thread safe, multiple separated interpreters in different threads
3) Cross Plattform: Aix, HP-UX, Solaris, Windows, MacOSX, Linux, BSD's
4) FTP/HTTP Network access, with FTPS and HTTPS. Not implemented via
CURL !!
5) Supporting UTF8
6) embeddable without problems and documenting even sophistiscated
problems like
threading and UTF encoding (this was the killer for python).
7) No TCL Runtime files! Just one single DLL. No undocumented
environment variables
that have any influences
8) easy windows build system
I used TCL for quite some time so i think most of the points are okay,
i'm only scared about (4), (6), (7) and (8). Especially the last time
there was almost no documentation about the threading implementation
and i spend hours to try to get (7) and failed in the end.
Also 3 years ago (8) was not possible. It was a huge fucking
complicated autocreated make file that only worked with MSVC6. I want a
simple one that i understand 100% so i can change it if it does not
work anymore in the future.
I'm also looking at Lua. This looks very good but it lacks so much
libraries that it's almost unuseable for me.
Michael Schlenker
> Hello,
> i have to move away from python as an embedded language for my current
> project and find something else. My requirements are
>
> 1) a lot of high level functions either as primitives (C compiler) or
> in TCL scripts.
> 2) thread safe, multiple separated interpreters in different threads
> 3) Cross Plattform: Aix, HP-UX, Solaris, Windows, MacOSX, Linux, BSD's
> 4) FTP/HTTP Network access, with FTPS and HTTPS. Not implemented via
> CURL !!
> 5) Supporting UTF8
> 6) embeddable without problems and documenting even sophistiscated
> problems like
> threading and UTF encoding (this was the killer for python).
> 7) No TCL Runtime files! Just one single DLL. No undocumented
> environment variables
> that have any influences
> 8) easy windows build system
>
>
> I used TCL for quite some time so i think most of the points are okay,
> i'm only scared about (4), (6), (7) and (8). Especially the last time
> there was almost no documentation about the threading implementation
> and i spend hours to try to get (7) and failed in the end.
For point 4 you need TLS, which can be statically built and linked into
the executable AFAIK. I don't know if the tcllib ftp lib supports FTP
via TLS, if not you would have to patch it.
(6) is ok, utf is no problem, the thread model is sane, but you may find
the documentation not perfect
(7) is possible via stardlls, Jeff Hobbs has done it for the Tcl plugin.
(8) is not easy, especially not for special problems like yours where
you need a stardll style setup..., there is the VC makefile and the
autoconf based configure system, if you use mingw, but non of them care
for specialities like stardll and embedding.
If you really need massiv support in there you should consider hiring an
expert consultant to get you started on this kind of stuff. David
Gravereaux and Jeff Hobbs come to mind, for doing many things with
threads on windows, or the stardll stuff, but there are surely others
who can give you a good start in those topics.
Michael
Cameron Laird
Michael Schlenker <sch...@uni-oldenburg.de> wrote:
>llothar schrieb:
>> Hello,
>> i have to move away from python as an embedded language for my current
>> project and find something else. My requirements are
.
.
>> I used TCL for quite some time so i think most of the points are okay,
>> i'm only scared about (4), (6), (7) and (8). Especially the last time
.
.
I want to reinforce Michael's advice. It's not just that Tcl
can do this; I find it easy to calculate that Tcl uniquely meets
these requirements.
Lua's the one other candidate that's closest.
llothar
Is comp.lang.tcl.announce dead or is it that google does not maintain
the newsgroup anymore ?
Starkit seems nice for applications but what i need is a "dll" that i
can link against not an exe file. Is this possible ? The wiki is also
mentioning that there seems to be problems on Solaris and with adding
the different character set encoding files.
llothar
then a dll file.
Donal K. Fellows
> 4) FTP/HTTP Network access, with FTPS and HTTPS. Not implemented via
> CURL !!
FTP and HTTP are available as packages (note that the package that does
HTTP comes with all distributions, FTP requires a package from tcllib).
If you want HTTPS, you need to also use the TLS package. Not sure about
FTPS; never used it. :-)
> 6) embeddable without problems and documenting even sophistiscated
> problems like
> threading and UTF encoding (this was the killer for python).
When embedding Tcl in a threaded binary, the main thing to remember is
that an interpreter may only ever be used from the thread that created
it. If you're using Tk (you don't say whether you are or not) keep it in
a single thread; we've definitely not ironed out all the problems there.
Encoding handling is well-documented. Or just ask here. :-)
> 7) No TCL Runtime files! Just one single DLL. No undocumented
> environment variables that have any influences
I believe this can be done (memory says to search for "stardll", but
other approaches may also be suitable).
> 8) easy windows build system
It seems easy enough to me when I build it on Windows. :-D
> I used TCL for quite some time so i think most of the points are okay,
> i'm only scared about (4), (6), (7) and (8). Especially the last time
> there was almost no documentation about the threading implementation
> and i spend hours to try to get (7) and failed in the end.
It should be much better now. A lot of work has been put into clever
packaging systems, leveraging off our virtual filesystem layer.
Hope this helps, or at least prompts you to get better answers from
others who know more. ;-)
Donal.
Eckhard Lehmann
llothar wrote:
> Is there any list of available TCL libraries ?
>
> Is comp.lang.tcl.announce dead or is it that google does not maintain
> the newsgroup anymore ?
The most announcements are usually done here in c.l.t. It's better to
follow this newsgroup for announcements.
>
> Starkit seems nice for applications but what i need is a "dll" that i
> can link against not an exe file. Is this possible ? The wiki is also
> mentioning that there seems to be problems on Solaris and with adding
> the different character set encoding files.
You don't need stardll or starkits here... Tcl *itself* is a dll,
located on Windows in bin/tcl84.dll. You can link against lib/tcl84.lib
and have the functionality of tcl84.dll.
You can distribute a minimal setup with the Tcl dll, an init script and
some part of the library (lib/tcl8.4). The init.tcl script is the only
runtime file that is required. If you still don't want it to be a
single file, there is a way to include it statically in the build
(I've done this once, but don't remember exactly... anyway it wasn't
complicated).
What is also possible, is to link the interpreter statically into your
application...
Eckhard
Wojciech Kocjan
> Just want to add that having a *.lib or *.a file would even be better
> then a dll file.
*.a is not an issue - if you look at
http://sourceforge.net/projects/dqsoftware/ - you can build dqkit and get
a bunch of
*.a files that you may then link against.
If this is ok with you I can help you set up the build env and later on
link it all with your final exe.
The main issue with it is that your final exe will need to be compiled
using MinGW as well.
--
WK
Eckhard Lehmann
Eckhard Lehmann wrote:
> You don't need stardll or starkits here... Tcl *itself* is a dll,
> located on Windows in bin/tcl84.dll. You can link against lib/tcl84.lib
> and have the functionality of tcl84.dll.
The only things you need to distribute as minimal runtime setup are:
bin/tcl84.dll
lib/tcl8.4/init.tcl
It boils down to a size of 636kb. However, you might find that it is
not sufficient and need to add encoding files, the lib/package.tcl for
loading additional packages and so on..
If you don't want special things and have MSVC as your build
environment, you can just link your application against lib/tcl84.lib
(it contains the locations of identifiers in bin/tcl84.dll) - there is
not even a need to compile Tcl.
Eckhard
llothar
Jeff Hobbs
> llothar schrieb:
...
>> 7) No TCL Runtime files! Just one single DLL. No undocumented
>> environment variables
>> that have any influences
>> 8) easy windows build system
> (7) is possible via stardlls, Jeff Hobbs has done it for the Tcl plugin.
> (8) is not easy, especially not for special problems like yours where
> you need a stardll style setup..., there is the VC makefile and the
> autoconf based configure system, if you use mingw, but non of them care
> for specialities like stardll and embedding.
You can cover these two points by getting Tcl Dev Kit and have the
ability to build your own stardlls from the base stardlls. You might
have to build your own stardlls on some platforms, but Windows is
certainly covered.
Jeff