Forum OpenACS Q&A: [incr] tcl abd AolServer

Posted by yury korsky on
at my company we are trying to add a more structured code system, and
were intrested in the capabilities that [incr] tcl offers.  The
problem is that we are not 100% percent certain of the compatability
issues there migth exist between that and Aolserver.  Has anyone
every done something like this, or know if it is possible?
Posted by Neophytos Demetriou on
Yury, I suggest that you check out XOTCL ( I started working with XOTCL in an effort to provide a persistence layer for OpenACS earlier this year and I'm most impressed:
  - xotcl is the most tclish oo language out there
  - xotcl is the fastest oo tcl
  - xotcl is fully compatible with tcl, it can live together
    nicely with tcl and is fully interopable with tcl
  - xotcl is proven to run in real world setups under aol-server (more details upon request)
  - xotcl improves tcl programming in various aspects
     e.g. - flexibility (interceptors)
          - modularization, reuse
          - simple parameter passing
Posted by Kenny Chan on
Hi Neophytos,

> xotcl is proven to run in real world setups under aol-server (more details upon request)

Would you please give more detail? It sounds very interesting. (this would be a request :>)


Posted by Neophytos Demetriou on
Hi Kenny, AFAIK, Zoran Vasiljevic is using it for his company projects. For those of you who don't know Zoran, he was the developer who found and fixed the memleaks in aolserver last year (among other aolserver contributions).
Posted by Randy Kunkee on
IIRC, the Tcl conference in Austin (was that 1999?), a paper on Xotcl was presented.  Xotcl is indeed an excellent design and very tcl-ish in its usage.  I used it years ago (when it was otcl) and would gladly use it again.  It is a lightweight interface as compared to [incr tcl].  On the other hand, Itcl more closely follows C++, so if you like C++ you'll like [incr tcl].  I'm pretty sure that Itcl is thread-safe.  My guess is that XOtcl is also.

I took to using [incr tcl] and have enjoyed it greatly.  In fact, as I wade through learning OpenACS, I've begun writing an application to generate the initial code (SQL, PG/PLSQL, TCL) to help get a new object type up fast.  It is currently in [incr tcl] but could easily be ported to Xotcl.  I'm going to post more about it in a separate thread so as not to go too off topic here.

[incr tcl] is an excellent way to provide more structure and increase reusability in your Tcl code.  I've had a lot of experience with it, and it really works.

Posted by defunct defunct on
The only thing I remember about incr tcl is that in AOLServer the global context is not maintained across threads, thereby you tend to end up with a little hack somewhere that essentially recreates all namespaces (objects) for each new interpreter.. not ideal really.

Also, if its any consolation our anecdotal observations do not support the notion that  incr tcl breeds more structure... (more obfuscation would be nearer the mark)

Posted by Dan Wickstrom on
IIRC when I looked at xotcl, it also required a hack to handle the namespace problem.  It's not really so much a problem with [incr] tcl or xotcl, as it is a problem with the single-threaded design of tcl that has been shoe-horned into the multi-threaded aolserver environment.  I think both modules could be modified so that the namespace problem would be transparent to end-users that wished to use them with aolserver.

Using an OO programing language in aolserver can certainly lead to more obfusication, but it doesn't have to.  Certainly, you don't have to look far to find examples of incredibly obfuscated tcl code...

Posted by Randy Kunkee on
Simon, I think it just goes to show you can program badly in any language. And, I've also seen surprisingly well-designed and "structured" programming in non-structured programming languages. This proves to me that a good language, even an OO language, can only help a programmer out so much. Giving a non-OO programmer an OO language, does not instantly make an OO programmer out of them.

As far as Yury's question goes, aforementioned compatibility issues notwithstanding, I still encourage him to go for it.

Posted by Peter Harper on
In addition to Simon's comments about [incr]tcl, we also had to kinda shoehorn the [incr]tcl functionality into the Tcl interpreter within Aolserver.  This was achieved by essentially compiling in the [incr] Tcl stuff when building Aolserver.  It was a nasty way of doing it, but the only way we found at the time.  In the end it was only used in a development system, but I would have been fairly apprehensive about running a production level system on it.  Perhaps someone's found a cleaner way of doing it since then.....
Posted by Gustaf Neumann on
I am very casual reader of this board, so i want to
apologize for a late response. We (the vienna university
of economics and business administration) are developing a
university learning platform based on OACS 4.*
and XOTcl which is scheduled to be launched this

For our project we hired about 38 people
(34 content-developer, 2 technical people, 2 didactical
people) to develop a fully-covered curriculum of all
courses in the first year (we are a business school,
the courses are ranging from law over mathematics
over IS to marketing, economics, etc). About 2000
students will enroll in the following year these

What we did so far is more-or-less orthogonal
to .LRN since we focussed in the first phase of the
project on content creation and content
classification tools and automatic linkage of related

Roughly speaking,
we developed a series of XML-Schemata to describe learning
resources together with some support for uploading and
process according XML files (with tDOM) and feed them
into the content repository. These learning resources
are e.g. six different types of tests (like multiple-choice
tests, etc), text-books, glossary etc. together with some
important meta-data (like categorization, etc.). To produce
the XML-schema instances, we developed support for MS-Word,
where one can use style-sheets (.dot files) and some helper
functions in some ms* user friendly way. Those, who do not
want to use word use at our university plain XML.

XOTcl was quite handy in this process since it allows
for better encapulation of context information, reuse
of methods, definition of specialized methods, etc.
(these are pretty much the standard OO arguments,
for deeper discussion of XOTcl features and properties,
see with its publication  section)

As being one of the XOTcl core developers, i am
certainly biased. Hoever, most of our development work
on the server-side is done by Peter Alberer, who
startet this project with no XOTcl background.

sorry for being a bit lengthy