Weblog Page

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Tue, 09 Jan 2001 19:50:08 +0100

Hi,

I have a question about documentation mechanisms in XOtcl. I would
like to use introspection for documenting my application, but not
for generating HTML files. As far as I have understood:

        - metadata is deprecated (http://media.wu-wien.ac.at/doc/tutorial.html#meta-data)

        - _at_ object is a kind of /dev/null which has to be redefined somehow

        - xodoc does this but for HTML documentation

So my question is: how do I use or not use _at_ for generating some kind of
metadata, i.e data which can be found (and changed by the user if needed) during
the application? Why is metadata deprecated?

Thanks in advance!

-- 
Catherine Letondal -- Pasteur Institute Computing Center

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Thu, 27 Sep 2001 17:06:25 +0200

On Wednesday 26 September 2001 05:19 pm, you wrote:
> A hugely important feature I would like to see in the near future,
> and one I've asked about before, is for a good C&C++ interface. I know
> this is not an easy issue to deal with, but for some things it would
> actually be quite vital. For me, the normal application development model
> would be to built everything in Tcl/XOTcl first, and then to begin
> converting critical parts to C if better performance is required.
>

that's more or less our opinion as well .. a mature (and documented) C API is
VERY important

> So what I would need is a semi-standard documented mechanism for
> adding procs and instprocs to objects from C (and, possibly later, C++)
> so that the C implementations can rely on the same information about
> object context and next-chaining as the XOTcl code itself. To take this
> even further, I may want to implement complete objects in C.
>

the basic (==OTcl) features are working currently quite well from C, but its
not documented. You can use XOTclAddIMethod for inst-commands and
XOTclAddPMethod for obj-commands. Take a look at xotclgdbm or xotclsdbm how
it can be done.

However, the newer features are still missing (of course, you can use
Tcl_Eval ... but that's not yielding the desired performance advantages)

> I've given this some amount of thought, but I don't have any really
> worthwhile suggestions to give as to how best to do this. I just think
> that now, with 1.0 coming out, is a good time to really put some thought
> into this. Another reason is that while the language develops I'm sure it
> will be more and more difficult to specify a complete library for
> this. With a simple core a library can be built and the extended as new
> aspects arise that use the same core.
>

I believe it is actually quite easy to be done, because you just have to add
extern wrapper functions for existing static functions. Of course, it is hard
to say what is needed ... but we can add more stuff later on ...

> Does this make sense at all?
>
 
As Zoran suggested: I would say, yes, Yes, and YES :)

To be serious: we'll roll out what we have done now as 0.9 as soon as
possible so that you all have a chance to update your applications to the new
features. We can give the C API a try for 1.0. If you need something
meanwhile, just put it in yourself, send it to us, and we'll incooperate it
directly into xotcl.h or xotclInt.h.

Cheers,

Uwe


> - ---------- = = ---------//--+
>
> | / Kristoffer Lawson | www.fishpool.fi|.com
>
> +-> | setok_at_fishpool.com | - - --+------
>
> |-- Fishpool Creations Ltd - / |
>
> +-------- = - - - = --------- /~setok/
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Institute for Computer Science, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Tue, 27 Mar 2001 18:39:47 +0200

Hi,

Is there a debian package for the 0.84 release of XOtcl?
Or even a 0.83?

I found this in a previous email:

deb http://bugger.fishpool.fi/debian tcl /
deb-src http://bugger.fishpool.fi/debian tcl /

but there is nothing there? And nothing on the XOtcl server either...

The problem is that the package doesn't compile:

cc -c -o tclexpat.o -O2 -D__NO_STRING_INLINES -D__NO_MATH_INLINES -Wall
-DHAVE_UNISTD_H=1 -DHAVE_MEMORY_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_FCNTL_H=1
-fPIC -Iexpat/xmltok -Iexpat/xmlparse -I. -I../../../src
-I/usr/include/tcl8.2/generic -I/usr/X11R6/include tclexpat.c
tclexpat.c:856: macro `Tcl_EvalObj' used with too many (3) args
tclexpat.c:929: macro `Tcl_EvalObj' used with too many (3) args
tclexpat.c:991: macro `Tcl_EvalObj' used with too many (3) args
tclexpat.c:1054: macro `Tcl_EvalObj' used with too many (3) args
tclexpat.c:1116: macro `Tcl_EvalObj' used with too many (3) args
tclexpat.c:1193: macro `Tcl_EvalObj' used with too many (3) args
tclexpat.c:1268: macro `Tcl_EvalObj' used with too many (3) args
tclexpat.c:1336: macro `Tcl_EvalObj' used with too many (3) args
tclexpat.c:1403: macro `Tcl_EvalObj' used with too many (3) args
make[1]: *** [tclexpat.o] Error 1

Thanks for your help,

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 13 Feb 2001 05:16:15 +0200 (EET)

A friend here at Fishpool made a simple HTML generation library in XOTcl
which does automatic indentation and generally makes code that deals with
HTML much neater. Currently it's all based around a HtmlDocument class,
which can be used to build a whole document or parts of a document (which
can then be added to other HtmlDocuments). Naturally this can be extended
with for things like tables, forms and whatever, although it already
includes methods for some of those.

I'm sure it might make the xodoc source code a lot cleaner (and I've been
tempted to stick it in there when editing it) :-)

If anyone is interested, do check it out:

http://dev.fishpool.fi/oss/htmllib/

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 17 Sep 2003 10:44:00 +0200

This is rather an unexpected behavior than a bug ...
I think it would be ok, to force a full name for serialize and deepSerialize,
that is, change the method in Serializer.xotcl to:

Serializer instproc serialize {objectOrClass} {
    my [my category $objectOrClass]-serialize [$objectOrClass]
}

can you please check whether that would work in your example?

--uwe

On Tuesday 16 September 2003 22:34, MichaelL_at_frogware.com wrote:
> Since you're getting 1.1 ready...
>
> I ran across a very, very subtle bug. I was using the serializer to
> serialize an obj tree. The topological sorting wasn't quite working for
> one case. In the end, I tracked it down to the fact that I was passing in
> an unqualified name. The sorting routine was in turn using fully qualified
> references as it tried to build the correct ordering, and the mismatch
> meant that it got some orderings for the root object slightly wrong.
> (Basically a few objects were being created before their containers; their
> containers were objects aggregated by the root object.)
>
> In effect, I was using this:
>
> Serializer deepSerialize obj
>
> when I should have been using this:
>
> Serializer deepSerialize ::obj
>
> I don't think you'd be able to reproduce this easily, because it turned
> out to relate to a specific set of objects and relationships. It turns out
> that for other reasons, even when you make this "mistake" the algorithm
> nearly works.
>
> To make this work you'd either have to a) require fully qualified names or
> b) turn a name into a fully qualified name. I don't know enough about Tcl
> internals to say that (b) is a realistic option--but on the face of it it
> doesn't seem like it would be.
>
> Don't know if this helps much. :-)

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 27 May 2007 13:36:05 +0200

Dear Shishir,

You are right, this is a bug. If you can compile xotcl by yourself,
applying the attached patch will help. Alternatively (before the next
release), you can add the modified instproc "parameter" (from default.xotcl)
to your application, mayby guarding it with ...

   if {$::xotcl::version$::xotcl::patchlevel eq "1.5.3"} ...

The patch will be included in the next releases (both the
bug-fix release 1.5.4 and the next major release 1.6.0).
The test went as well into our regression tests.

best regards
-gustaf neumann


Shishir Ramam schrieb:
> I'm using ActiveState's 8.4 distribution on Windows XP, and am unable
> to explain the behaviour in the example below.
>
> Shouldn't '-exact' be allowed as the default initializer for match? It
> seems to have something to do with the
> leading '-' since removing it seems to create the class Foo without
> issue.
>
> Any help much appreciated.

From: John McGlaughlin <jmcglaug_at_cisco.com>
Date: Mon, 07 Mar 2005 13:47:00 -0500

The following examples in tutorial cause errors

Object o
 o proc y {-a {-b {1 2 3}} x y} {
     puts "$a $b $x $y"
 }

Class P
 P instproc y {-a:required {-b:boolean true}} {
     puts "$a $b"
 }


Thanks to Ben Thomasson for correcting this for me
the code should be

ALSO notice that one example is incorrect for -b passing a string 4 5 needs to be bound {4 5}

(tcl) 165 % o proc y {-a {-b {1 2 3}}} { x y } {
   puts "$a $b $x $y"
}
(tcl) 166 % o y -b 4 5 -a 1 3 4
wrong # args: should be { x y }
(tcl) 167 % o y -b {4 5} -a 1 3 4
1 4 5 3 4
(tcl) 168 % o y -a 1 3 4
1 1 2 3 3 4
(tcl) 169 % o y -a 1 -- -b -c
1 1 2 3 -b -c
(tcl) 170 %


(tcl) 174 % P instproc y {-a:required {-b:boolean true}} {} {
     puts "$a $b"
 }
(tcl) 175 % P p
::xotcl::p
(tcl) 176 % p y -a 1 -b 0
1 0

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 7 Dec 2010 16:05:31 -0800

Trying to compile the latest NX/XOTcl 2.0 against Tcl CVS Head:

 gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
-DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1
-D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-DHAVE_TCL_COMPILE_H=1 -I"/root/TCL/tcl/generic"
-I"/root/TCL/tcl/unix" -I./generic -pipe -O2 -fomit-frame-pointer
-Wall -fPIC -c `echo ./generic/nsfStubLib.c` -o nsfStubLib.o
./generic/nsfStubLib.c:40: error: conflicting types for ‘nsfStubsPtr’
./generic/nsfDecls.h:262: note: previous declaration of ‘nsfStubsPtr’ was here
./generic/nsfStubLib.c:41: error: conflicting types for ‘nsfIntStubsPtr’
./generic/nsfIntDecls.h:41: note: previous declaration of
‘nsfIntStubsPtr’ was here
./generic/nsfStubLib.c:43: error: conflicting types for ‘nsfStubsPtr’
./generic/nsfDecls.h:262: note: previous declaration of ‘nsfStubsPtr’ was here
./generic/nsfStubLib.c:44: error: conflicting types for ‘nsfIntStubsPtr’
./generic/nsfIntDecls.h:41: note: previous declaration of
‘nsfIntStubsPtr’ was here
make: *** [nsfStubLib.o] Error 1

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 5 Feb 2001 16:54:46 +0200 (EET)

On Mon, 5 Feb 2001, Rick Hedin wrote:

> What is your thinking regarding widgets from XOTcl?

I've been pondering the same issue, but I haven't yet required Tk so
I haven't done anything about it. Anyway, the ideas I came up with follow
on these lines:

1) Have a meta-class for Tk widgets, that automatically registers
a filter for each class it creates. This filter would reroute all
calls to an object to the actual Tk widget so that when
"$myButton configure" is called the command ".frame.b configure" is
called. Then with this meta-class created, just create the classes
for each Tk object (not really that many -- and no methods are needed
for the XOTcl classes as methods are just passed on).

2) Do the same with [incr Tk]. In fact, [incr Tcl] is enough. Then
you automatically can use [incr Tk] and all other iTcl libraries as if
they were XOTcl libraries. Could be extremely handy.

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 11 Dec 2010 09:43:53 +0100

i have commited this yesterday to the repository....
will do so, either a configure test or a complete
replacement....
-gustaf

On 11.12.10 06:19, Victor Mayevski wrote:
> It seems that strnstr() function is new to Linux (as of January 2010)
> and is not present in many Linux libraries yet. May be you can
> substitute it with something else.