ANNOUNCE: TclOO 0.2 Released

[Donal K. Fellows]

As the sharp-eyed among you may have already noticed, TclOO 0.2 has now
been released (escaped?) and is now available for download in source
form from the Tcl SF download area. You can also get it via anonymous
CVS by pulling the 'oo' module from Tcl's CVS tree. Binary distributions
via the ActiveState teapot are also going out I believe.
http://sf.net/project/showfiles.php?group_id=10894&package_id=247402

Features of 0.2 w.r.t. 0.1:
* Changes to C API to be less confusing.
* C API to allow creation and configuration of many more features.
* Better use of TEA3, autoheader, etc.
* Support for building using MSVC (though still with GNU make)
* Support for mixing a class into a class (including itself!)
* Redesigned object cloning mechanism (for better support of TDBC)
* Many small features, mostly hidden out of sight, for support of
Arnulf Wiedemann's itcl-ng.
* Misc bug fixes (especially in call-chain management)
* Documentation fixes, so now match the Tcl core style better.

Donal.

[Jeff Hobbs]

On Apr 14, 2:59 am, "Donal K. Fellows"

And available as binary in ActiveTcl's teacup.

Jeff

[vit...@gmail.com]

In the new Tcl00 API, will it be possible to make ensemble command -
or- [object method] commands to be a single string command?
I just went through hell trying to implement a custom code [socket -
server accept port] as method in XOTcl. I spent may be an hour on
something that should be very simple and ended up with this:

<<< my sock [ socket -server [list eval [concat [myproc accept]
http ] ] -myaddr [my addr] [my port] >>>

where with a single string command it would be something like this:

my sock [ socket -server [list [self]::accept http ] ] -myaddr [my
addr] [my port]

In XOTcl it does work rather nicely if I create procs after object
creation (Class instance) instead of creating instprocs in the Class
itself. Then the "object::method" syntax works fine. Using instproc
doesn't work the same way though :(

I think that lists, strings, and ensemble commands are probably
biggest turn off for the people who wish to learn Tcl. I have wasted
many hours in my time fighting with errors until I learned the tricks
of going around those issues. You never know if the variable is a list
or a string or whether it will stay as a list or become a string or if
my ensemble command will work if I pass it around, etc etc etc. Having
to do "[eval [list [concat my command]]]" looks rather silly and makes
the code much less readable. I'd rather see TCL having everything in
OBJECTS as opposed to "everything in TCL is a string".

---Victor

[Neil Madden]

vit...@gmail.com wrote:
> In the new Tcl00 API, will it be possible to make ensemble command -
> or- [object method] commands to be a single string command?
> I just went through hell trying to implement a custom code [socket -
> server accept port] as method in XOTcl. I spent may be an hour on
> something that should be very simple and ended up with this:
>
> <<< my sock [ socket -server [list eval [concat [myproc accept]
> http ] ] -myaddr [my addr] [my port] >>>
>
> where with a single string command it would be something like this:
>
> my sock [ socket -server [list [self]::accept http ] ] -myaddr [my
> addr] [my port]

I believe the following should work for XOTcl:

my sock [socket -server [myproc accept http] \
-myaddr [my addr] [my port]]

So no need for all the eval/concat stuff (which should never be needed
anyway). Snit's [mymethod] works similarly, IIRC. I imagine TclOO has
something similar. DKF's a clever fellow (pun intended!), so has
probably thought of this. Even without such helpers, you can always do:

my sock [socket -server [linsert [myproc accept] end http] ...]

>
> In XOTcl it does work rather nicely if I create procs after object
> creation (Class instance) instead of creating instprocs in the Class
> itself. Then the "object::method" syntax works fine. Using instproc
> doesn't work the same way though :(
>
> I think that lists, strings, and ensemble commands are probably
> biggest turn off for the people who wish to learn Tcl. I have wasted
> many hours in my time fighting with errors until I learned the tricks
> of going around those issues. You never know if the variable is a list
> or a string or whether it will stay as a list or become a string or if
> my ensemble command will work if I pass it around, etc etc etc. Having
> to do "[eval [list [concat my command]]]" looks rather silly and makes
> the code much less readable. I'd rather see TCL having everything in
> OBJECTS as opposed to "everything in TCL is a string".

This does indeed look silly, but it should never be necessary. Tcl
commands are lists, so you should always use list commands to form and
manipulate them. I agree that this is perhaps a difficult area for new
Tcl programmers. When I have time (not until May now), I'll see if the
tutorial can be updated to better cover these concepts. If you notice
other areas in need of better tutorial documentation, feel free to
create items on the Tcl tracker at sourceforge.net and assign them to
the tutorial category and my sf id (tallniel).

-- Neil

[vit...@gmail.com]

> I believe the following should work for XOTcl:
>
> my sock [socket -server [myproc accept http] \
> -myaddr [my addr] [my port]]
>

This is so funny because it does indeed work as stated. :)
My problem was that I didn't not start off from my own code but
somebody else's. And that code had all those "list"s
[list accept [list a b c]]
And I spent all this time fitting my code into this configuration.

> ... Tcl

> commands are lists, so you should always use list commands to form and
> manipulate them. I agree that this is perhaps a difficult area for new
> Tcl programmers. When I have time (not until May now), I'll see if the
> tutorial can be updated to better cover these concepts. If you notice
> other areas in need of better tutorial documentation, feel free to
> create items on the Tcl tracker at sourceforge.net and assign them to
> the tutorial category and my sf id (tallniel).
>
> -- Neil

Yes, the problem is that people don't know that, for example, commands
are list etc. I always did [list cmd] because I see it everywhere in
somebody else's code and it often helped me, but I had no idea why I
had to do that. So, these things need to be clearly stated in the
documentation.

Thanks a lot for your help.

---Victor

[Georgios Petasis]

O/H Jeff Hobbs έγραψε:

Which can be installed multiple times:

C:\Program Files (x86)\Tcl\bin>teacup update-self
Updating C:/Program Files (x86)/Tcl/bin/teacup.exe ...
Nothing to do. Found only older or same version

C:\Program Files (x86)\Tcl\bin>teacup update

Retrieving application base-tcl-thread 8.5.2.1.284998 win32-ix86 ...@
http://
teapot.activestate.com ... Ok
Retrieving application base-tclsvc-thread 8.5.2.1.284998 win32-ix86 ...@
http://
teapot.activestate.com ... Ok
Retrieving application base-tk-thread 8.5.2.1.284998 win32-ix86 ...@
http://
teapot.activestate.com ... Ok
Retrieving package TclOO 0.2 win32-ix86 ...@
http://
teapot.activestate.com ... Ok

Installing 4 newer packages

Installing into C:/Program Files (x86)/Tcl/lib/teapot

Installing application base-tcl-thread 8.5.2.1.284998 win32-ix86
Installing application base-tclsvc-thread 8.5.2.1.284998 win32-ix86
Installing application base-tk-thread 8.5.2.1.284998 win32-ix86
Installing package TclOO 0.2 win32-ix86

Installed 4 newer packages
Installed 0 unknown packages

C:\Program Files (x86)\Tcl\bin>teacup update

Retrieving package TclOO 0.2 win32-ix86 ...@
http://teapot.activestate.com ... Ok

Installing 1 newer package

Installing into C:/Program Files (x86)/Tcl/lib/teapot

Installing package TclOO 0.2 win32-ix86

Installed 1 newer package
Installed 0 unknown packages

C:\Program Files (x86)\Tcl\bin>teacup update

Retrieving package TclOO 0.2 win32-ix86 ...@
http://teapot.activestate.com ... Ok

Installing 1 newer package

Installing into C:/Program Files (x86)/Tcl/lib/teapot

Installing package TclOO 0.2 win32-ix86

Installed 1 newer package
Installed 0 unknown packages

C:\Program Files (x86)\Tcl\bin>teacup update

Retrieving package TclOO 0.2 win32-ix86 ...@
http://teapot.activestate.com ... Ok

Installing 1 newer package

Installing into C:/Program Files (x86)/Tcl/lib/teapot

Installing package TclOO 0.2 win32-ix86

Installed 1 newer package
Installed 0 unknown packages

C:\Program Files (x86)\Tcl\bin>

George

[Donal K. Fellows]

vit...@gmail.com wrote:
> In the new Tcl00 API, will it be possible to make ensemble command -
> or- [object method] commands to be a single string command?

No. More particularly, one of the things I had to drop to make TclOO
work well was making methods be normal Tcl commands. That in turn means
that there needs to be some sort of wrapper. Luckily, this can be made
in just a few lines of (unsupported) code:

proc oo::Helpers::callback {methodName args} {
set objNS [uplevel 1 namespace current]
return [list ${objNS}::my $methodName {*}$args]
}

That'll let you write (inside your methods only) code like this:

set sock [socket -server [callback accept http] -myaddr $addr $port]

Assuming that you've brought all the relevant variables into the
method's scope (TclOO just uses normal namespace variables, giving each
object its own namespace to work with).

> I think that lists, strings, and ensemble commands are probably
> biggest turn off for the people who wish to learn Tcl.

Alas, these features are sophisticated and complex, and so can take some
effort to learn. Maybe they need to have some of the sharper edges worn
off (suggestions welcome!) But that doesn't mean that that's the only
problem about, as your specific issue indicates...

> Having to do "[eval [list [concat my command]]]" looks rather silly

It's probably wrong too, and indicates that there's an "education"
problem; in particular, we've somehow failed to communicate how to do
this sort of thing to you. For reference, I now no longer use [eval] at
all except for certain very specialized and rare uses.

Donal.

[vit...@gmail.com]

On Apr 15, 6:57 am, "Donal K. Fellows"

<donal.k.fell...@manchester.ac.uk> wrote:
> vit...@gmail.com wrote:
> > In the new Tcl00 API, will it be possible to make ensemble command -
> > or- [object method] commands to be a single string command?
>
> No. More particularly, one of the things I had to drop to make TclOO
> work well was making methods be normal Tcl commands. That in turn means

> that there needs to be some sort of wrapper.....

That's why I love Tcl, you can mold it into almost anything and create
a totally new syntax and programming language out of it.

There was my previous post where I discussed the [namespace glob
expension].

http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/a37c95242b20549f

As an experiment and, may be, something I would use in the future, I
extended XOTcl to have it's objects and methods look like the /
directories/commands in the Linux shell.
I simply intercepted the init/instproc/instdestroy methods using
filters in the "Class" and "Object" meta-classes and created proc
commands to redirect the call to the actual [object method] commands.

The resulting functionality is as follows:

%Class C
::C
%info commands /C/*
/C/ismixin /C/__next /C/filtersearch /C/instforward /C/isobject /C/
isclass /C/move /C/configure /C/noinit /C/forward /C/slots /C/mixin /C/
instproc /C/upvar /C/cleanup /C/cmd1 /C/cmd2 /C/cmd3 /C/class /C/
alloc /C/defaultmethod /C/parameterclass /C/copy /C/uplevel /C/incr /C/
info /C/init /C/parametercmd /C/autoname /C/superclass /C/append /C/
unknown /C/create /C/array /C/lappend /C/instvar /C/volatile /C/
abstract /C/hasclass /C/instmixin /C/subst /C/mixinguard /C/trace /C/
procsearch /C/instfilterguard /C/method /C/check /C/uses /C/invar /C/
ismetaclass /C/vwait /C/istype /C/extractConfigureArg /C/new /C/
contains /C/proc /C/instparametercmd /C/instfilter /C/set /C/recreate /
C/unset /C/eval /C/instdestroy /C/tst /C/instmixinguard /C/filter /C/
filterguard /C/requireNamespace /C/parameter /C/destroy /C/
allinstances /C/instinvar /C/exists /C/self
%C c
::c
%info commands /c/*
/c/volatile /c/proc /c/set /c/abstract /c/mixin /c/upvar /c/hasclass /
c/tst /c/noinit /c/eval /c/class /c/parametercmd /c/configure /c/
contains /c/self /c/array /c/append /c/ismetaclass /c/subst /c/trace /
c/destroy /c/move /c/check /c/invar /c/method /c/ismixin /c/vwait /c/
cmd1 /c/cmd2 /c/cmd3 /c/isclass /c/istype /c/filterguard /c/isobject /
c/copy /c/unset /c/forward /c/defaultmethod /c/incr /c/info /c/init /c/
cleanup /c/mixinguard /c/procsearch /c/filter /c/uplevel /c/
filtersearch /c/exists /c/extractConfigureArg /c/requireNamespace /c/
lappend /c/instvar /c/__next /c/autoname
%/c/destroy
%/C/destroy

So I have solved two issues for myself: glob expansion of commands
names and one string ensemble commands
( [ object method ] becomes [ /object/method ] )
This can be extended further by adding the "ls" and "find" commands as
in Linux shell.

It was an interesting experiment. I wonder if it has any usability
value.

---Victor

[EL]

vit...@gmail.com schrieb:

> That's why I love Tcl, you can mold it into almost anything and create
> a totally new syntax and programming language out of it.

With some limitations... that would maybe vanish, if Tcl had procedures
that are first class values, and a macro system. Guess what language I
refer to :-)?

After some experiences with many, many programming languages that are
all equal to some extend, I must say that the only one that I would
still like to add to this repository is Lisp.
But it is sooo deeply interwoven with Emacs, and I am a Vim user... this
kindof stops me from this experience ;-).

Eckhard

[Gerald W. Lester]

EL wrote:
> ..., I must say that the only one that I would

> still like to add to this repository is Lisp.
> But it is sooo deeply interwoven with Emacs, and I am a Vim user... this
> kindof stops me from this experience ;-).

Lisp is much wider in scope then Emacs.

And only the later versions of Emacs are in Lisp, the earliest versions were
in TECO.

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

[EL]

Gerald W. Lester schrieb:

> Lisp is much wider in scope then Emacs.

I know... but you get hardly around Emacs when you try to learn Lisp.
There seem to be no free /and/ good IDE's available, other than SLIME.
I wouldn't care to learn Emacs as well, but all this is a matter of time ;).

Eckhard

[Neil Madden]

Have you looked at Dr Scheme? http://www.drscheme.org/

It has some nice features, especially for learning. I've often thought
something similar for Tcl would be a nice project.

-- Neil

[EL]

Neil Madden schrieb:

> Have you looked at Dr Scheme? http://www.drscheme.org/

Yes, I did... and it made me thinking whether to start with Lisp or with
Scheme :).
I'd still tend more to Lisp, mostly because of P. Grahams book "On Lisp"
(great resource for every software engineer, not only Lisp programmers),
and the comparison here:
http://groups.google.com/group/comp.lang.scheme/msg/b505263f820dba29

> It has some nice features, especially for learning. I've often thought
> something similar for Tcl would be a nice project.

Tcl lacks some very interesting features to be comparable to either of
these languages. The most notably is not the "proc as value" thing or a
macro system, but the integrated debugging facilities. It makes thing so
much easier to have a built in debugger, that jumps in on errors and can
be controlled by commands (or switched off entirely).
In Lisp it is just there. But in Tcl...? It would be possible and has
been done already (by Arthur Trzewik in his ATKdebugger), but nobody
seems to care.

- Eckhard

[Neil Madden]

EL wrote:
> Neil Madden schrieb:
>
>> Have you looked at Dr Scheme? http://www.drscheme.org/
>
> Yes, I did... and it made me thinking whether to start with Lisp or with
> Scheme :).
> I'd still tend more to Lisp, mostly because of P. Grahams book "On Lisp"
> (great resource for every software engineer, not only Lisp programmers),
> and the comparison here:
> http://groups.google.com/group/comp.lang.scheme/msg/b505263f820dba29

Scheme is a nicer language. If you stick to a single implementation
(e.g. PLT scheme) then you can also get many of the advantages of Common
Lisp, as these implementations have fairly comprehensive libraries. I
still prefer Tcl's libraries though :)

>
>> It has some nice features, especially for learning. I've often thought
>> something similar for Tcl would be a nice project.
>
> Tcl lacks some very interesting features to be comparable to either of
> these languages. The most notably is not the "proc as value" thing or a

Tcl has "proc as value" -- see [apply].

> macro system, but the integrated debugging facilities. It makes thing so
> much easier to have a built in debugger, that jumps in on errors and can
> be controlled by commands (or switched off entirely).
> In Lisp it is just there. But in Tcl...? It would be possible and has
> been done already (by Arthur Trzewik in his ATKdebugger), but nobody
> seems to care.

Tcl provides all you need to write a debugger, and using these
facilities on their own can often be enough. As you say, more
comprehensive debuggers do exist (and people do care about them). Their
existence surely demonstrates that this doesn't have to be built in.

Another point to consider is that some of the facilities that Tcl lacks
(continuations, macros) are also facilities that can obscure stack
traces and make debugging more difficult. In my own code, I know that
stack traces + a simple way of bringing up an interactive console on an
app ([console show]/tkcon) is often enough to quickly diagnose the
error, so I don't feel myself needing a debugger very often (most of the
really tricky bugs usually turn up in custom C code).

-- Neil

[EL]

Neil Madden schrieb:

> Tcl has "proc as value" -- see [apply].

Ok, but lexical scoping is not there...

> Tcl provides all you need to write a debugger, and using these
> facilities on their own can often be enough. As you say, more
> comprehensive debuggers do exist (and people do care about them). Their
> existence surely demonstrates that this doesn't have to be built in.

I use your [breakpoint] procedure, that I found on a page at
http://lambda-the-ultimate.org/ which I don't remember anymore. It is
quite useful, but it does not enable you to step.
I know, there are workarounds and there is always a way to do it with
[trace] etc., there are heaps of solutions on the wiki... But couldn't
it be simply a builtin feature? Everybody needs debugging at some point,
so why should everybody invent his own debugger?

> In my own code, I know that
> stack traces + a simple way of bringing up an interactive console on an
> app ([console show]/tkcon) is often enough to quickly diagnose the
> error, so I don't feel myself needing a debugger very often

Absolutely right, this is often all that I need as well. When it was
only possible to *step* inside this console, I would be more than happy ;-).

> really tricky bugs usually turn up in custom C code).

For this it would be somewhat helpful if TCL_ERROR could bring up the
debugger. Your [breakpoint] can be registered with the [error] command
at least.
TIP #290 that I proposed some time ago goes into this direction, but is
probably better designed in the context of a fully fledged set of
debugger commands.

- Eckhard

[Donal K. Fellows]

EL wrote:
> For this it would be somewhat helpful if TCL_ERROR could bring up the
> debugger. Your [breakpoint] can be registered with the [error] command
> at least.

At the moment, it's quite tricky to do that. The problem is, the core
(currently) doesn't find out that there's been an error until the code
that generated the error returns. At which point, it's too late to
attach a debugger (naturally!)

Changing this wouldn't be too hard technically, but would mean a lot of
alterations to third-party code. Messy, and definitely not something we
want to do in 8.* anyway. (It breaks the ABI promise.)

Donal.