From Aamer Akhter Wed Oct 6 13:24:15 2004 From: Aamer Akhter (Aamer Akhter) Date: Wed, 6 Oct 2004 08:24:15 -0400 Subject: [Xotcl] komodo debugger incompatibility with xotcl Message-ID: <7cf4fa750410060524681a9906@mail.gmail.com> Hello, Has anybody run into weirdness with the komodo tcl debugger and xotcl? Sorry to be so imprecise, but that's the best way I can describe it right now. -- Aamer Akhter / aakhter@gmail.com From Bryan.Schofield@trans.ge.com Wed Oct 6 14:00:04 2004 From: Bryan.Schofield@trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Wed, 6 Oct 2004 09:00:04 -0400 Subject: [Xotcl] 1.3.3 Plans? Message-ID: Just curious on the plans for the next official release of xotcl. I know that there have been a few issues that Gustaf & Uwe have been mulling over since the first 1.3 release. In particular, the namespace scoping handling that made it's debut then was removed in Uwe's 1.3.2 unofficial, interim build. I ask because I have some code that I've been working on that I started when I was testing Gustaf's original implementation before 1.3. I think (hope) that others will these libraries useful, but I hesitate to make them public until the namespace scoping has settled. Anyway, just curious. -- bryan From attilio.dona@telecomitalia.it Wed Oct 6 16:38:02 2004 From: attilio.dona@telecomitalia.it (Attilio Dona`) Date: Wed, 06 Oct 2004 17:38:02 +0200 Subject: [Xotcl] XOtcl 1.3 bug Message-ID: <4164115A.6080100@telecomitalia.it> This is a multi-part message in MIME format. ------=_NextPart_000_3CD5AA_01C4ABCB.BCA29960 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hy Gustaf and Uwe, We have the following bug: package require XOTcl namespace import xotcl::* xotcl::Class::Parameter create Param -parameter { {value ""} } Class create MA -superclass Class MA parameter {{v -Class {Param -value ciao} -default 1}}=20 MA create A puts "A exists pippo: [A exists pippo]" set pippo 10 puts "A exists pippo: [A exists pippo]" --> A exists pippo: 0 --> A exists pippo: 1 This is true if you have at least one parameter defined for a Metaclass and for every global variable defined! ciao Attilio -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_3CD5AA_01C4ABCB.BCA29960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hy Gustaf and = Uwe,

We have the following bug:

package require = XOTcl
namespace import xotcl::*

xotcl::Class::Parameter create = Param -parameter {
{value ""}
}

Class create MA = -superclass Class

MA parameter {{v -Class {Param -value ciao} = -default 1}}

MA create A

puts "A exists pippo: [A exists = pippo]"

set pippo 10

puts "A exists pippo: [A exists = pippo]"


--> A exists pippo: 0
--> A exists pippo: = 1

This is true if you have at least one parameter defined for a = Metaclass
and for every global variable = defined!

ciao
Attilio




--------------------------------------------------------------------=
CONFIDENTIALITY =0DNOTICE
This message and its attachments are = addressed solely to the =0Dpersons
above and may contain confidential = information. If you have =0Dreceived
the message in error, be = informed that any use of the content =0Dhereof
is prohibited. Please = return it immediately to the sender and =0Ddelete
the message. Should = you have any questions, please contact us =0Dby
replying to webmaster@telecomitalia.it.
        Thank = =0Dyou
          &nb= sp;           &nbs= p;            = ;     =0Dwww.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_3CD5AA_01C4ABCB.BCA29960-- From neumann@wu-wien.ac.at Wed Oct 6 22:26:33 2004 From: neumann@wu-wien.ac.at (Gustaf Neumann) Date: Wed, 6 Oct 2004 23:26:33 +0200 Subject: [Xotcl] XOtcl 1.3 bug In-Reply-To: <4164115A.6080100@telecomitalia.it> References: <4164115A.6080100@telecomitalia.it> Message-ID: <200410062326.33209.neumann@wu-wien.ac.at> Hi Attilio, if i would be Mr Spock, i would say "fascinating". The example can be simplified to: set pippo 1 Object o puts [o exists pippo] Object o::p puts [o exists pippo] and was like this already at least in 0.9 (in 2001), most likely as well in all versions supporting "exists". For the time being, you can use: Object instproc exists var { string compare [my info vars $var] "" } puts [o exists pippo] o set pippo 1 puts [o exists pippo] It should be fixed properly in the forthcoming release. best regards -gustaf On Wednesday 06 October 2004 17:38, Attilio Dona` wrote: > Hy Gustaf and Uwe, > > We have the following bug: > > package require XOTcl > namespace import xotcl::* > > xotcl::Class::Parameter create Param -parameter { > {value ""} > } > > Class create MA -superclass Class > > MA parameter {{v -Class {Param -value ciao} -default 1}} > > MA create A > > puts "A exists pippo: [A exists pippo]" > > set pippo 10 > > puts "A exists pippo: [A exists pippo]" > > > --> A exists pippo: 0 > --> A exists pippo: 1 > > This is true if you have at least one parameter defined for a Metaclass > and for every global variable defined! > > ciao > Attilio > > > > > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons above > and may contain confidential information. If you have received the message > in error, be informed that any use of the content hereof is prohibited. > Please return it immediately to the sender and delete the message. Should > you have any questions, please contact us by replying to > webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien From setok@fishpool.com Wed Oct 6 22:45:21 2004 From: setok@fishpool.com (Kristoffer Lawson) Date: Thu, 7 Oct 2004 00:45:21 +0300 (EEST) Subject: [Xotcl] XOtcl 1.3 bug In-Reply-To: <200410062326.33209.neumann@wu-wien.ac.at> References: <4164115A.6080100@telecomitalia.it> <200410062326.33209.neumann@wu-wien.ac.at> Message-ID: On Wed, 6 Oct 2004, Gustaf Neumann wrote: > Hi Attilio, > if i would be Mr Spock, i would say "fascinating". > > The example can be simplified to: > > set pippo 1 > Object o > puts [o exists pippo] > Object o::p > puts [o exists pippo] > > and was like this already at least in 0.9 (in 2001), > most likely as well in all versions supporting "exists". Oop, I think I noticed something like this too but forgot to report it as I made a workaround. Bad me :-) (Need to look at that segmentation fault thing again as soon as I have time) / http://www.fishpool.com/~setok/ From jeffh@ActiveState.com Wed Oct 6 23:33:09 2004 From: jeffh@ActiveState.com (Jeff Hobbs) Date: Wed, 6 Oct 2004 15:33:09 -0700 Subject: [Xotcl] komodo debugger incompatibility with xotcl In-Reply-To: <7cf4fa750410060524681a9906@mail.gmail.com> Message-ID: <10f001c4abf4$75364f80$de04a8c0@activestate.ca> Aamer Akhter wrote: > Has anybody run into weirdness with the komodo tcl debugger > and xotcl? Sorry to be so imprecise, but that's the best way > I can describe it right now. Is it possible to be any more precise? The Komodo Tcl debugger doesn't do anything fancy with regards to xotcl (not trying to recognize it specifically). Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos From neumann@wu-wien.ac.at Sat Oct 9 23:45:45 2004 From: neumann@wu-wien.ac.at (Gustaf Neumann) Date: Sun, 10 Oct 2004 00:45:45 +0200 Subject: [Xotcl] 1.3.3 Plans? In-Reply-To: References: Message-ID: <200410100045.45939.neumann@wu-wien.ac.at> Hi Bryan and all, i just fixed the problem of attila and resolved the open namespace issues. We will do some more testing and will come out with 1.3.3. RSN. all the best -gustaf -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien From bogus@does.not.exist.com Thu Oct 14 10:26:15 2004 From: bogus@does.not.exist.com () Date: Thu Oct 14 10:26:17 2004 Subject: No subject Message-ID: when compiling the distributed binaries. Is there a reason why not? It seems like it is a low cost (simply add the "-DUSE_TCL_STUBS" compile switch?) thing to do in order to get the benefit of distributing more widely usable binaries. Thanks, Brian Theado ------_=_NextPart_001_01C15893.671068D0 Content-Type: text/html; charset="iso-8859-1" RE: xotcl and tclkit

On Fri, 19 Oct 2001 09:07:31 +0200, Gustaf Neumann wrote:
> the xotcl binaries are built with tcl 8.3.2.
> therefore it should work without compiling only with
> 8.3.

> however, when it is compiled with 8.4, it will work.

I remember that stubs support was recently added to xotcl.
From the above, I gather stubs support is not being used
when compiling the distributed binaries.  Is there a reason
why not?  It seems like it is a low cost (simply add the
"-DUSE_TCL_STUBS" compile switch?) thing to do in order to
get the benefit of distributing more widely usable binaries.

Thanks,
Brian Theado

------_=_NextPart_001_01C15893.671068D0-- From bogus@does.not.exist.com Thu Oct 14 10:26:15 2004 From: bogus@does.not.exist.com () Date: Thu Oct 14 10:26:19 2004 Subject: No subject Message-ID: > This does not work as you intend it because you forgot the "next" > call in your destroy method. That means the real destructor is > never reached ... Yes, I understand. > I would also recommend to always use "args" for init > and destroy, as arguments for these methods may change. Yes, I understand. I was trying to submit the simplest possible code to illustrate the problem. Btw, very nice work. I'm impressed with and appreciate the attention to detail. --=_alternative 0058C63985256D24_= Content-Type: text/html; charset="US-ASCII"
Thanks, guys!

From Uwe:

> This does not work as you intend it because you forgot the "next"
> call in your destroy method. That means the real destructor is
> never reached ...

Yes, I understand.

> I would also recommend to always use "args" for init
> and destroy, as arguments for these methods may change.

Yes, I understand. I was trying to submit the simplest possible code to illustrate the problem.

Btw, very nice work. I'm impressed with and appreciate the attention to detail. --=_alternative 0058C63985256D24_=-- From aakhter at gmail.com Wed Oct 6 14:24:15 2004 From: aakhter at gmail.com (Aamer Akhter) Date: Thu Oct 14 10:26:23 2004 Subject: [Xotcl] komodo debugger incompatibility with xotcl Message-ID: <7cf4fa750410060524681a9906@mail.gmail.com> Hello, Has anybody run into weirdness with the komodo tcl debugger and xotcl? Sorry to be so imprecise, but that's the best way I can describe it right now. -- Aamer Akhter / aakhter@gmail.com From Bryan.Schofield at trans.ge.com Wed Oct 6 15:00:04 2004 From: Bryan.Schofield at trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Thu Oct 14 10:26:23 2004 Subject: [Xotcl] 1.3.3 Plans? Message-ID: Just curious on the plans for the next official release of xotcl. I know that there have been a few issues that Gustaf & Uwe have been mulling over since the first 1.3 release. In particular, the namespace scoping handling that made it's debut then was removed in Uwe's 1.3.2 unofficial, interim build. I ask because I have some code that I've been working on that I started when I was testing Gustaf's original implementation before 1.3. I think (hope) that others will these libraries useful, but I hesitate to make them public until the namespace scoping has settled. Anyway, just curious. -- bryan From attilio.dona at telecomitalia.it Wed Oct 6 17:38:02 2004 From: attilio.dona at telecomitalia.it (Attilio Dona`) Date: Thu Oct 14 10:26:23 2004 Subject: [Xotcl] XOtcl 1.3 bug Message-ID: <4164115A.6080100@telecomitalia.it> Hy Gustaf and Uwe, We have the following bug: package require XOTcl namespace import xotcl::* xotcl::Class::Parameter create Param -parameter { {value ""} } Class create MA -superclass Class MA parameter {{v -Class {Param -value ciao} -default 1}} MA create A puts "A exists pippo: [A exists pippo]" set pippo 10 puts "A exists pippo: [A exists pippo]" --> A exists pippo: 0 --> A exists pippo: 1 This is true if you have at least one parameter defined for a Metaclass and for every global variable defined! ciao Attilio -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://alice.wu-wien.ac.at/pipermail/xotcl/attachments/20041006/594f5517/attachment.html From neumann at wu-wien.ac.at Wed Oct 6 23:26:33 2004 From: neumann at wu-wien.ac.at (Gustaf Neumann) Date: Thu Oct 14 10:26:23 2004 Subject: [Xotcl] XOtcl 1.3 bug In-Reply-To: <4164115A.6080100@telecomitalia.it> References: <4164115A.6080100@telecomitalia.it> Message-ID: <200410062326.33209.neumann@wu-wien.ac.at> Hi Attilio, if i would be Mr Spock, i would say "fascinating". The example can be simplified to: set pippo 1 Object o puts [o exists pippo] Object o::p puts [o exists pippo] and was like this already at least in 0.9 (in 2001), most likely as well in all versions supporting "exists". For the time being, you can use: Object instproc exists var { string compare [my info vars $var] "" } puts [o exists pippo] o set pippo 1 puts [o exists pippo] It should be fixed properly in the forthcoming release. best regards -gustaf On Wednesday 06 October 2004 17:38, Attilio Dona` wrote: > Hy Gustaf and Uwe, > > We have the following bug: > > package require XOTcl > namespace import xotcl::* > > xotcl::Class::Parameter create Param -parameter { > {value ""} > } > > Class create MA -superclass Class > > MA parameter {{v -Class {Param -value ciao} -default 1}} > > MA create A > > puts "A exists pippo: [A exists pippo]" > > set pippo 10 > > puts "A exists pippo: [A exists pippo]" > > > --> A exists pippo: 0 > --> A exists pippo: 1 > > This is true if you have at least one parameter defined for a Metaclass > and for every global variable defined! > > ciao > Attilio > > > > > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons above > and may contain confidential information. If you have received the message > in error, be informed that any use of the content hereof is prohibited. > Please return it immediately to the sender and delete the message. Should > you have any questions, please contact us by replying to > webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- -- Univ.Prof. Dr.Gustaf Neumann Abteilung f?r Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversit?t Wien, Augasse 2-6, 1090 Wien From setok at fishpool.com Wed Oct 6 23:45:21 2004 From: setok at fishpool.com (Kristoffer Lawson) Date: Thu Oct 14 10:26:23 2004 Subject: [Xotcl] XOtcl 1.3 bug In-Reply-To: <200410062326.33209.neumann@wu-wien.ac.at> References: <4164115A.6080100@telecomitalia.it> <200410062326.33209.neumann@wu-wien.ac.at> Message-ID: On Wed, 6 Oct 2004, Gustaf Neumann wrote: > Hi Attilio, > if i would be Mr Spock, i would say "fascinating". > > The example can be simplified to: > > set pippo 1 > Object o > puts [o exists pippo] > Object o::p > puts [o exists pippo] > > and was like this already at least in 0.9 (in 2001), > most likely as well in all versions supporting "exists". Oop, I think I noticed something like this too but forgot to report it as I made a workaround. Bad me :-) (Need to look at that segmentation fault thing again as soon as I have time) / http://www.fishpool.com/~setok/ From jeffh at ActiveState.com Thu Oct 7 00:33:09 2004 From: jeffh at ActiveState.com (Jeff Hobbs) Date: Thu Oct 14 10:26:23 2004 Subject: [Xotcl] komodo debugger incompatibility with xotcl In-Reply-To: <7cf4fa750410060524681a9906@mail.gmail.com> Message-ID: <10f001c4abf4$75364f80$de04a8c0@activestate.ca> Aamer Akhter wrote: > Has anybody run into weirdness with the komodo tcl debugger > and xotcl? Sorry to be so imprecise, but that's the best way > I can describe it right now. Is it possible to be any more precise? The Komodo Tcl debugger doesn't do anything fancy with regards to xotcl (not trying to recognize it specifically). Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos From neumann at wu-wien.ac.at Sun Oct 10 00:45:45 2004 From: neumann at wu-wien.ac.at (Gustaf Neumann) Date: Thu Oct 14 10:26:23 2004 Subject: [Xotcl] 1.3.3 Plans? In-Reply-To: References: Message-ID: <200410100045.45939.neumann@wu-wien.ac.at> Hi Bryan and all, i just fixed the problem of attila and resolved the open namespace issues. We will do some more testing and will come out with 1.3.3. RSN. all the best -gustaf -- Univ.Prof. Dr.Gustaf Neumann Abteilung f?r Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversit?t Wien, Augasse 2-6, 1090 Wien From Bryan.Schofield at trans.ge.com Fri Oct 15 18:47:44 2004 From: Bryan.Schofield at trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Fri Oct 15 18:47:58 2004 Subject: [Xotcl] xotcllib? Message-ID: Does xotcllib, or some other collection of XOTcl utility packages exist? From neumann at wu-wien.ac.at Fri Oct 15 19:03:10 2004 From: neumann at wu-wien.ac.at (Gustaf Neumann) Date: Fri Oct 15 19:03:10 2004 Subject: [Xotcl] xotcllib? In-Reply-To: References: Message-ID: <200410151903.10781.neumann@wu-wien.ac.at> On Friday 15 October 2004 18:47, Schofield, Bryan \(GE Transportation\) wrote: > Does xotcllib, or some other collection of XOTcl utility packages exist? just the library that comes with the source in xotcl*/library -gustaf -- Univ.Prof. Dr.Gustaf Neumann Abteilung f?r Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversit?t Wien, Augasse 2-6, 1090 Wien From Bryan.Schofield at trans.ge.com Fri Oct 15 19:48:57 2004 From: Bryan.Schofield at trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Fri Oct 15 19:49:18 2004 Subject: [Xotcl] xotcllib? Message-ID: Ack! What a shame. I've been working on six utility packages that are very close to being ready for public consumption. I'm just waiting on 1.3.3 to make sure everything works well with the finalized namespace scoping implementation. It has all been written against the 1.3 feature set. So far I have the following packages: xow - A megawidget framework. This is a package that allows xotcl objects to be megawidgets. xol - Yet another logging framework. But since this is object oriented, this package provides some features that are not available in other packages. Foremost, the ability to use "Formatter" and "Receiver" objects. For example, the following simple line: $logger warn "Ack! Foo" could be able to log to file or console, package the message up as XML and send it over the network, or even feed an RSS stream depending on the formatter & receiver the logger is using. So far, I've only written a simple formatter and output channel receiver, but this is all possible. xtend - a collection of "singleton" objects that extends the basic functionality of tcl, tk, and xotcl. This package provides various string, list, tk, and xotcl utilities. xact - an "action" framework package. If you are not familiar with the "action" concept in ui programming, it is a very powerful tool that simplifies programming chores. wiki.tcl.tk has some information available. This package can also be used in a non-tk environment. xcentuate - a theme engine for tk. This isn't all that important on windows, but on unix tk often needs a little help looking good. This package provides a very simple method of defining and changing the look of tk apps. It can even do it on the fly. xout - a unit testing framework. I know, I know, tcl already provides one, tcltest. But I found tcltest to be too cumbersome and clunky. I'd write some tests, but maintaining those tests often was neglected because of the amount of programming overhead needed to write complex test cases. xout (X Out) simplifies unit tests. xout is only a framework, so I wrote graphical utility "xam" (think Exam) that puts xout to work. It is what I'm using these days to run my unit tests. I mention all of this because if other have some handy xotcl packages, I'd be interested in creating a formal xotcllib project. Perhaps something at sourceforge. I'll be making these available soon either way. -- bryan > -----Original Message----- > From: xotcl-bounces@alice.wu-wien.ac.at > [mailto:xotcl-bounces@alice.wu-wien.ac.at]On Behalf Of Gustaf Neumann > Sent: Friday, October 15, 2004 1:03 PM > To: xotcl@alice.wu-wien.ac.at > Subject: Re: [Xotcl] xotcllib? > > > On Friday 15 October 2004 18:47, Schofield, Bryan \(GE > Transportation\) wrote: > > Does xotcllib, or some other collection of XOTcl utility > packages exist? > just the library that comes with the source in xotcl*/library > -gustaf > > -- > Univ.Prof. Dr.Gustaf Neumann > Abteilung f?r Wirtschaftsinformatik und Neue Medien > Wirtschaftsuniversit?t Wien, Augasse 2-6, 1090 Wien > _______________________________________________ > Xotcl mailing list > Xotcl@alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl > From setok at fishpool.com Fri Oct 15 23:42:16 2004 From: setok at fishpool.com (Kristoffer Lawson) Date: Fri Oct 15 23:42:43 2004 Subject: [Xotcl] xotcllib? In-Reply-To: References: Message-ID: On Fri, 15 Oct 2004, Schofield, Bryan \(GE Transportation\) wrote: > > xol - Yet another logging framework. But since this is object oriented, > this package provides some features that are not available in other > packages. Foremost, the ability to use "Formatter" and "Receiver" > objects. For example, the following simple line: > $logger warn "Ack! Foo" could be able to log to file or console, > package the message up as XML and send it over the network, or even feed > an RSS stream depending on the formatter & receiver the logger is using. > So far, I've only written a simple formatter and output channel > receiver, but this is all possible. I've been doing some logging using filters, actually. Kind of "separation of concerns". Methods themselves concentrate on just getting functionality right, and the filters 'slice in' and do logging. > xout - a unit testing framework. I know, I know, tcl already provides > one, tcltest. But I found tcltest to be too cumbersome and clunky. I'd > write some tests, but maintaining those tests often was neglected > because of the amount of programming overhead needed to write complex > test cases. xout (X Out) simplifies unit tests. xout is only a > framework, so I wrote graphical utility "xam" (think Exam) that puts > xout to work. It is what I'm using these days to run my unit tests. This sounds interesting. > I mention all of this because if other have some handy xotcl packages, > I'd be interested in creating a formal xotcllib project. Perhaps > something at sourceforge. I'll be making these available soon either > way. I think atm from myself I could mostly offer the caching filter object, which is already on the Wiki in some form or other, and maybe a couple of other things if and when I get them ready and am allowed to release them. Anyway, that all sounds pretty nice. / http://www.fishpool.com/~setok/ From jeffh at ActiveState.com Mon Oct 18 00:21:33 2004 From: jeffh at ActiveState.com (Jeff Hobbs) Date: Mon Oct 18 00:21:52 2004 Subject: [Xotcl] xotcllib? In-Reply-To: Message-ID: <02d801c4b497$ab6cc470$de04a8c0@activestate.ca> > xow - A megawidget framework. This is a package that allows > xotcl objects to be megawidgets. Does this handle the option db correctly, do composition of megawidgets, handle focus and events right, etc.? > xcentuate - a theme engine for tk. This isn't all that > important on windows, but on unix tk often needs a little > help looking good. This package provides a very simple method > of defining and changing the look of tk apps. It can even do > it on the fly. I would not propagate this in favor of Tile. There is also already the 'style' package in tklib (which again may be abortive when Tile becomes part of 8.5). What features does xcentuate really provide? Should they not just go into 'style'? > xout - a unit testing framework. I know, I know, tcl already > provides one, tcltest. But I found tcltest to be too > cumbersome and clunky. I'd write some tests, but maintaining > those tests often was neglected because of the amount of > programming overhead needed to write complex test cases. xout Did you compare against tcltest v1 or v2? > I mention all of this because if other have some handy xotcl > packages, I'd be interested in creating a formal xotcllib > project. Perhaps something at sourceforge. I'll be making > these available soon either way. I think that would be a handy thing as an addon. Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos From Bryan.Schofield at trans.ge.com Mon Oct 18 19:44:26 2004 From: Bryan.Schofield at trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Mon Oct 18 19:44:05 2004 Subject: [Xotcl] xotcllib? Message-ID: > -----Original Message----- > From: Jeff Hobbs [mailto:jeffh@ActiveState.com] > Sent: Sunday, October 17, 2004 6:22 PM > To: Schofield, Bryan (GE Transportation); xotcl@alice.wu-wien.ac.at > Subject: RE: [Xotcl] xotcllib? > > > > xow - A megawidget framework. This is a package that allows > > xotcl objects to be megawidgets. > > Does this handle the option db correctly, do composition > of megawidgets, handle focus and events right, etc.? No, currently doesn't handle the option db. This is a tricky area of building megawidgets. An xow widget can be based off of any other existing widget or megawidget. That can make things a little more complicated since xow widgets can & will pick up option db settings for base widgets and the -class option isn't available for most widgets. Personally, I am aware of this shortcoming and work around it. I'd rather not have this feature than have one that works partially and is unpredictable. Since I haven't had the time to devote to writing a complete implementation, I haven't done anything with it. There is no special code to handle composition of megawidgets, focus, or event processing. > > > xcentuate - a theme engine for tk. This isn't all that > > important on windows, but on unix tk often needs a little > > help looking good. This package provides a very simple method > > of defining and changing the look of tk apps. It can even do > > it on the fly. > > I would not propagate this in favor of Tile. There is > also already the 'style' package in tklib (which again > may be abortive when Tile becomes part of 8.5). What > features does xcentuate really provide? Should they not > just go into 'style'? I'm not sure what "style" package you are refering to. I see none in the docs for TkLib, but maybe I missed them or it's not in the latest official release. I did manage to google up a "as::style" package that you appear to have written. So I'll assume that's the package to which you refer. xcentuate provides the common things like colors and borderwidth for widgets. It also provides some named colors and eventually named fonts. I have some good font generation routines already, I just need to convert them to xotcl and integrate them. The widget classes and options applied to those classes are not hard coded in xcentuate. It can be trained to apply style to new widget classes or change what options are applied. Finally, xcentuate is OO. I like objects, I like them alot. This package works well for me but I look forward to Tile being part of 8.5 so I can declare this obsolete. Below is an example of a LookAndFeel that shows what xcentuate can control right now. This particuler LookAndFeel gets applied by default on unix. Xcentuate will also learn what tk looks like by default so there is always a "default" LookAndFeel that can be applied. Oh, xcentuate can change styles (LookAndFeels) on the fly. LookAndFeel lightgrey \ -name "Light Grey" \ -description "A simple light grey palette" \ -activebackground grey90 \ -activeforeground red \ -background grey80 \ -disabledbackground grey85 \ -disabledforeground grey40 \ -foreground black \ -highlightbackground grey80 \ -highlightcolor red \ -insertbackground red \ -readonlybackground grey90 \ -selectbackground skyblue \ -selectcolor red \ -selectforeground black \ -textbackground white \ -textforeground black \ -troughcolor grey75 \ -borderwidth 1 \ -labelframepad 4 \ -labelframebd 2 \ -texterrorbg \#fee \ -texterrorfg red3 \ -textwarnbg PeachPuff \ -textwarnfg orange2 \ -textokbg \#dfd \ -textokfg green3 \ -textnotebg \#ffd \ -textnotefg yellow3 \ -textinfobg \#def \ -textinfofg blue2 lightgrey apply > > > xout - a unit testing framework. I know, I know, tcl already > > provides one, tcltest. But I found tcltest to be too > > cumbersome and clunky. I'd write some tests, but maintaining > > those tests often was neglected because of the amount of > > programming overhead needed to write complex test cases. xout > > Did you compare against tcltest v1 or v2? Version 2. Tcltest is more powerful, no question about that. But for testing complex scenarios, I like to build on the success of one test later. For example, consider the following distinct events that I can test, where later tests use something from previous tests. 1. Can I create object X? 2. Can object X do something? 3. Can object X do something else? 4. Can I delete object X and it clean up properly? Thing can get way more complicated than that, too. Imagine trying to test db or remote server interaction. With tcltest, I'd have to create object X or connect to a db or server in the setup of every test. I can appreciate isolating tests from one another so that one test doesn't impact another, which is what tcltest does. To achieve that, I have two level in my test hierachy. One is the TestSuite. No two suites can interact with each other. They run in their own iterpreter from scratch. A TestSuite has one or more Tests that *can* interact with each other. Also, on a side note, I hate having to specify a test name with tcltest. test example-1.1 {test file existence} -setup { set file [makeFile {} test] } -body { file exists $file } -cleanup { removeFile test } -result 1 It's fine until you realize next month that you need a new test, and that it make more sense from a readability viewpoint to stick it in between example-1.1 and example-1.2. Do I call it example-1.1.5 or renumber the other tests below? The test name doesn't add much to me, the tester. It's the description that matters. For comparison purposes, xout test file would be structured as follows: TestSuite foo \ -description "blah" \ -setup {set file [makeFile {} test]} \ -cleanup {removeFile test} foo test \ -description "test file existence" -result 1 \ -script {file exists $file} Finally, xout is only a framework. It can be embedded into other applications such as an IDE. That can easily find and query TestSuite objects to run and get their results. Just so happens that the GUI can also be embedded in or run standalone. > > > I mention all of this because if other have some handy xotcl > > packages, I'd be interested in creating a formal xotcllib > > project. Perhaps something at sourceforge. I'll be making > > these available soon either way. > > I think that would be a handy thing as an addon. > > Jeff Hobbs, The Tcl Guy > http://www.ActiveState.com/, a division of Sophos > > I threw some screen shots of xcentuate & xout in action on my (unfinished) website if anyone wants to take a look. http://www.abschofield.com/code/ss/ Sorry for being long winded. -- bryan From jeffh at ActiveState.com Mon Oct 18 22:43:33 2004 From: jeffh at ActiveState.com (Jeff Hobbs) Date: Mon Oct 18 23:13:42 2004 Subject: [Xotcl] xotcllib? In-Reply-To: Message-ID: <079201c4b553$28c41a70$de04a8c0@activestate.ca> > > > xow - A megawidget framework. This is a package that allows > > > xotcl objects to be megawidgets. > > > > Does this handle the option db correctly, do composition > > of megawidgets, handle focus and events right, etc.? > > No, currently doesn't handle the option db. This is a tricky > area of building megawidgets. An xow widget can be based off > of any other existing widget or megawidget. That can make ... > There is no special code to handle composition of > megawidgets, focus, or event processing. While I don't want to discourage good coding exercises, I do want to encourage others to use code based on all the best practices. We don't have a perfect megawidget framework to rely on yet, but hopefully you'll be willing to take part when we get around to it, or maybe work on yours until it is that system. ;) > > > xcentuate - a theme engine for tk. This isn't all that > > I would not propagate this in favor of Tile. There is > I'm not sure what "style" package you are refering to. I see > none in the docs for TkLib, but maybe I missed them or it's > not in the latest official release. I did manage to google up > a "as::style" package that you appear to have written. So > I'll assume that's the package to which you refer. Yes, that's a variant that was included. > xcentuate provides the common things like colors and > borderwidth for widgets. It also provides some named colors > and eventually named fonts. I have some good font generation Hmmmm ... ok, you have created something more for users to define their own themes, whereas 'style' says "these are better overall alternate themes". I must say that I personally encourage the latter. It's a pity you couldn't make it to Tcl'2004 last week, because I had a tutorial and talk on these points. I don't mean to pick on you, I just want to give my ideas and how they may affect your current efforts. The whole idea of themeing, which will be core in 8.5, is to enable a better look for Tk. However, it is not intended for the user (in the common case) to change this theme. The functionality is there merely for Tk to better adapt to current styles. Thus, the 'style' code defines styles for users to just use, rather than providing a framework to create their own. > I look forward to Tile being part of 8.5 so I can declare > this obsolete. Note that tile works perfectly well with 8.4. ActiveState will actually be shipping an app RSN that uses tile. What is now a testbed will soon be a core feature, but that doesn't mean you can't use it now. > interact with each other. Also, on a side note, I hate having > to specify a test name with tcltest. ... > It's fine until you realize next month that you need a new > test, and that it make more sense from a readability > viewpoint to stick it in between example-1.1 and example-1.2. > Do I call it example-1.1.5 or renumber the other tests below? > The test name doesn't add much to me, the tester. It's the > description that matters. For comparison purposes, xout test OK, I've dealt with this before. There is nothing in the naming of that test that requires it be numbers, that is just convention. It makes it easier for grouping and such, and is handy when searching through the test suite after failures. In your example below: > file would be structured as follows: > > TestSuite foo \ > -description "blah" \ > -setup {set file [makeFile {} test]} \ > -cleanup {removeFile test} > foo test \ > -description "test file existence" > -result 1 \ > -script {file exists $file} What happens when you don't provide a description? This should be a required field, as it is in tcltest, so why have it an option? Otherwise, I see the structure you have chosen could make it easier to build tests. > Finally, xout is only a framework. It can be embedded into > other applications such as an IDE. That can easily find and > query TestSuite objects to run and get their results. Just so > happens that the GUI can also be embedded in or run standalone. I like the UI you added to it. > I threw some screen shots of xcentuate & xout in action on my > (unfinished) website if anyone wants to take a look. > http://www.abschofield.com/code/ss/ Very nice. > Sorry for being long winded. No problem, and I don't want to sound negative. I'm just trying to assist constructively. As I've told Gustaf and Uwe before, xotcl (or some close variant) could be the OO for the core, if it provided 100% itcl compatability (for the many many folks that rely on itcl). Jeff From Bryan.Schofield at trans.ge.com Tue Oct 19 17:10:28 2004 From: Bryan.Schofield at trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Tue Oct 19 17:09:54 2004 Subject: [Xotcl] xotcllib? Message-ID: I've cut a bunch of the older email content out for brevity. > -----Original Message----- > From: Jeff Hobbs [mailto:jeffh@ActiveState.com] > Sent: Monday, October 18, 2004 4:44 PM > To: Schofield, Bryan (GE Transportation); xotcl@alice.wu-wien.ac.at > Subject: RE: [Xotcl] xotcllib? > > [...] > While I don't want to discourage good coding exercises, I > do want to encourage others to use code based on all the > best practices. We don't have a perfect megawidget > framework to rely on yet, but hopefully you'll be willing > to take part when we get around to it, or maybe work on > yours until it is that system. ;) This actually started out as a coding exercise just to play with the new forwarding features of xotcl. I look forward to day that there is an "official" megawidget framework, but in the mean time, I do plan on enhancing mine to cover it's short comings. [...] > > Hmmmm ... ok, you have created something more for users to > define their own themes, whereas 'style' says "these are > better overall alternate themes". I must say that I > personally encourage the latter. It's a pity you couldn't > make it to Tcl'2004 last week, because I had a tutorial > and talk on these points. I don't mean to pick on you, I > just want to give my ideas and how they may affect your > current efforts. > > The whole idea of themeing, which will be core in 8.5, is > to enable a better look for Tk. However, it is not > intended for the user (in the common case) to change this > theme. The functionality is there merely for Tk to better > adapt to current styles. Thus, the 'style' code defines > styles for users to just use, rather than providing a > framework to create their own. First, I don't take any of your comments personally. While I consider myself a good developer, I know that I'm not perfect and can be blinded my own intentions, motivations, and enthusiasm to create something new. Not to mention the fact that I know I don't know everything. I welcome your comments, as well as the comments of so many others. Just clear up my intentions with xcentuate, it isn't really meant to be used for each application to define it's own look and feel. While it is very easy to do so, I'd hope that developers will respect the look and feel of the platform on which they will deploy. My main motivation was to improve how tk looks on my unix workstation. Currently, xcentuate only changes the theme on unix, by default it's a light grey theme which is suitable for brighter environments. It also provides a dark grey theme which works nicely in darker office settings. I think that xcentuate and 'style' share the same goal. Xcentuate, too, provides some "better alternate themes", it just goes one step further by making it very easy to define what the themes are. That makes it easy for corporate branding. For example, the system I work on is beige in color during normal operation. However, the same application can be launched in a training mode which is aqua in color. I can also have a "development" color mode to distinguish application instances that are in beta against those that running live. With xcentuate, the application look is simplified to: switch -- $mode { TRAINING { aquaLook apply } DEVELOP { devLook apply } default { normalLook apply } } [...] > OK, I've dealt with this before. There is nothing in the > naming of that test that requires it be numbers, that is > just convention. It makes it easier for grouping and such, > and is handy when searching through the test suite after > failures. In your example below: > > > file would be structured as follows: > > > > TestSuite foo \ > > -description "blah" \ > > -setup {set file [makeFile {} test]} \ > > -cleanup {removeFile test} > > foo test \ > > -description "test file existence" > > -result 1 \ > > -script {file exists $file} > > What happens when you don't provide a description? This > should be a required field, as it is in tcltest, so why > have it an option? Otherwise, I see the structure you > have chosen could make it easier to build tests. By the default, the description is "No Description Available". So nothing happens if it is not provided. Much like the following: test foo-1.1 {} \ -result 1 \ -body { set x 1 } Sure, tcltest makes it a required field, but it doesn't ensure there is anything meaningful in it. If you really think about, the description is optional in tcltest, too. Now... having spent the time to write xout and the ui that goes with it, I've (begrudgingly) accepted the following: 1. Tcl does not need another another a testing framework. Choice is not always beneficial, and in this case I think it would hurt tcl overall. It's hard enough to get people to write tests; no point in muddying up the water with something else. 2. Having to name my tests (example-1.1) isn't that much more work. Calling "cleanupTests" isn't a big deal either, so I'll just do it and quit whining. 3. My efforts would have been better spent adding a ui to tcltest. I think I'll do that. 4. It took suprisingly little time to convert my xout test files to tcltest files. [...] > I like the UI you added to it. Thanks, I think I'll redo it to work with tcltest. [...] > No problem, and I don't want to sound negative. I'm just > trying to assist constructively. As I've told Gustaf and > Uwe before, xotcl (or some close variant) could be the OO > for the core, if it provided 100% itcl compatability (for > the many many folks that rely on itcl). > > Jeff You don't sound negative. Thanks, I appreciate your opinion, Jeff. Didn't Gustaf whip up something that was itcl compatible, at least to some degree? And does it need to be 100% itcl or 100% itcl/itk? -- bryan From jeffh at ActiveState.com Tue Oct 19 18:00:08 2004 From: jeffh at ActiveState.com (Jeff Hobbs) Date: Tue Oct 19 18:13:46 2004 Subject: [Xotcl] xotcllib? In-Reply-To: References: Message-ID: <41753A08.1000305@activestate.com> Schofield, Bryan (GE Transportation) wrote: > Didn't Gustaf whip up something that was itcl compatible, at least to some > degree? And does it need to be 100% itcl or 100% itcl/itk? Yes, because TIP #50 specifies adding itcl to the core, but it doesn't say specifically how. If xotcl can provide that same functionality, the itcl users won't care, and we get the best of both OO worlds for those who prefer xotcl style OO. -- Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos From mail at xdobry.de Thu Oct 21 13:46:01 2004 From: mail at xdobry.de (mail@xdobry.de) Date: Thu Oct 21 13:48:05 2004 Subject: [Xotcl] getting full name object Message-ID: <5854386$109835866241779f86bf4421.45699880@config11.schlund.de> Hi! I work currently with 1.3.2 and have one problem that relate to namespace handling. I would need new object method that could return full name of object (similar to "namespace origin" command) I could not find any possibility to get it from build-in Object methods. I would expect that "self" or "my" on object would work. So I must programm new global Object instproc: Object instproc fullname {} { self } so it work Object a a fullname >::a Is were any better possibility to get the same result? If not it could be idee to extend object base interface (for example info command) Artur Trzewik From uwe.zdun at wu-wien.ac.at Thu Oct 21 14:17:53 2004 From: uwe.zdun at wu-wien.ac.at (Uwe Zdun) Date: Thu Oct 21 14:20:47 2004 Subject: [Xotcl] getting full name object In-Reply-To: <5854386$109835866241779f86bf4421.45699880@config11.schlund.de> References: <5854386$109835866241779f86bf4421.45699880@config11.schlund.de> Message-ID: <4177A8F1.2060006@wu-wien.ac.at> Hi Artur, if you invoke the object command (==ID) without any arguments, it returns the fully qualified name: Object a puts [a] -> ::a Uwe mail@xdobry.de wrote: >Hi! > >I work currently with 1.3.2 and have one problem >that relate to namespace handling. >I would need new object method that could return full name of >object >(similar to "namespace origin" command) > >I could not find any possibility to get it from >build-in Object methods. >I would expect that "self" or "my" on object would work. > >So I must programm new global Object instproc: > >Object instproc fullname {} { self } > >so it work > >Object a >a fullname > > >>::a >> >> > >Is were any better possibility to get the same result? >If not it could be idee to extend object base interface (for example >info command) > >Artur Trzewik >_______________________________________________ >Xotcl mailing list >Xotcl@alice.wu-wien.ac.at >http://alice.wu-wien.ac.at/mailman/listinfo/xotcl > > -- Uwe Zdun Department of Information Systems, Vienna University of Economics Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746 zdun@acm.org, uwe.zdun@wu-wien.ac.at From adam.turoff at gmail.com Fri Oct 22 22:20:41 2004 From: adam.turoff at gmail.com (Adam Turoff) Date: Fri Oct 22 22:21:50 2004 Subject: [Xotcl] XOTcl / Tcl Namespace issues Message-ID: Hi, Can anyone explain why this program: package require XOTcl namespace import xotcl::* proc ns {} {return "global"} proc examine {} {puts "[ns] EXAMINE"} Class Outer Outer instproc test {} {return [examine]} namespace eval inner { proc ns {} {return "inner"} proc examine {} {puts "[ns] examine"} Class Inner Inner instproc test {} {return [examine]} } Outer o o test inner::Inner i i test namespace eval inner { ::o test ::i test } produces this output: global EXAMINE global EXAMINE inner examine inner examine I've defined the class 'Inner' within the namespace 'inner'. I'd expect that proc in methods defined within that namespace should first look within that namespace before looking in the global namespace. Instead, they look in the namespace currently in use when a method call is made. (Note how ::o test picks up the definition of inner::examine when invoked from the inner namespace.) This is the opposite behavior of how Tcl proc calls work -- when I land on inner::examine, the [ns] is actually shorthand for inner::ns, not ::ns. I'm guessing there's a good reason for this behavior, but I can't seem to find it in the docs. Thanks, -- Adam From Bryan.Schofield at trans.ge.com Fri Oct 22 22:51:41 2004 From: Bryan.Schofield at trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Fri Oct 22 22:51:08 2004 Subject: [Xotcl] XOTcl / Tcl Namespace issues Message-ID: I think you've stumbled on the namespace resolution bug that appeared with 1.3.0. Gustaf & Uwe have been working on fix and appear to close to releasing a new version. I'm testing a 1.3.3 version of XOTcl for Gustaf now. I added one more combination to your test: inner::Inner inner::i2 and I get the following results: In :: o -> GLOBAL EXAMINE i -> inner examine inner::i2 -> inner examine In ::inner o -> GLOBAL EXAMINE i -> inner examine inner::i2 -> inner examine Which seems more inline to what you were expecting to see. Try this test version of XOTcl and see if you get better results. I'm sure the XOTcl guys would appreciate the extra testing anyway. http://media.wu-wien.ac.at/download/xotcl-1.3.3.tar.gz Hope that helps. -- bryan > -----Original Message----- > From: xotcl-bounces@alice.wu-wien.ac.at > [mailto:xotcl-bounces@alice.wu-wien.ac.at]On Behalf Of Adam Turoff > Sent: Friday, October 22, 2004 4:21 PM > To: xotcl@alice.wu-wien.ac.at > Subject: [Xotcl] XOTcl / Tcl Namespace issues > > > Hi, > > Can anyone explain why this program: > > package require XOTcl > namespace import xotcl::* > > proc ns {} {return "global"} > proc examine {} {puts "[ns] EXAMINE"} > > Class Outer > Outer instproc test {} {return [examine]} > > namespace eval inner { > proc ns {} {return "inner"} > proc examine {} {puts "[ns] examine"} > > Class Inner > Inner instproc test {} {return [examine]} > } > > Outer o > o test > > inner::Inner i > i test > > namespace eval inner { > ::o test > ::i test > } > > produces this output: > > global EXAMINE > global EXAMINE > inner examine > inner examine > > I've defined the class 'Inner' within the namespace 'inner'. I'd > expect that proc in methods defined within that namespace should first > look within that namespace before looking in the global namespace. > Instead, they look in the namespace currently in use when a > method call > is made. (Note how ::o test picks up the definition of inner::examine > when invoked from the inner namespace.) > > This is the opposite behavior of how Tcl proc calls work -- > when I land > on inner::examine, the [ns] is actually shorthand for > inner::ns, not ::ns. > > I'm guessing there's a good reason for this behavior, but I can't seem > to find it in the docs. > > Thanks, > > -- Adam > _______________________________________________ > Xotcl mailing list > Xotcl@alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl > From adam.turoff at gmail.com Fri Oct 22 23:06:28 2004 From: adam.turoff at gmail.com (Adam Turoff) Date: Fri Oct 22 23:07:35 2004 Subject: [Xotcl] XOTcl / Tcl Namespace issues In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004 16:51:41 -0400, Schofield, Bryan (GE Transportation) wrote: > I think you've stumbled on the namespace resolution bug that appeared with 1.3.0. Gustaf & Uwe have been working on fix and appear to close to releasing a new version. I'm testing a 1.3.3 version of XOTcl for Gustaf now. Whoops. Sorry. I'm using 1.2.0. -- Adam From neumann at wu-wien.ac.at Sat Oct 23 00:48:56 2004 From: neumann at wu-wien.ac.at (Gustaf Neumann) Date: Sat Oct 23 00:48:57 2004 Subject: [Xotcl] XOTcl / Tcl Namespace issues In-Reply-To: References: Message-ID: <200410230048.56251.neumann@wu-wien.ac.at> On Friday 22 October 2004 22:51, Schofield, Bryan \(GE Transportation\) wrote: > I think you've stumbled on the namespace resolution bug that appeared with > 1.3.0. actually, what adam points out was the xotcl behavior before 1.3.*. Earlier versions used always the current namespace for instprocs/procs, which is different from the standard tcl behavior, and has as well some more disadvantages for packages. The bug that Michael Heca came up with (alloc bug) was a consequence of changing the old behavior. The exists bug that Attila came up with was in since the first xotcl versions. All these issues are solved in the current testing version. We have still one complex issue to double check; if everything goes well, we should be able to release 1.3.3 next week. -gustaf -- Univ.Prof. Dr.Gustaf Neumann Abteilung f?r Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversit?t Wien, Augasse 2-6, 1090 Wien From mail at xdobry.de Sat Oct 23 16:02:23 2004 From: mail at xdobry.de (Artur Trzewik) Date: Sat Oct 23 16:02:48 2004 Subject: [Xotcl] XOTclIDE in version 0.70 updated for XOTcl 1.3.2 Message-ID: <200410231602.23443.mail@xdobry.de> Hi There is new version 0.70 of XOTclIDE ready on: http://www.xdobry.de/xotclIDE Main changes: - adapted for XOTcl 1.3.2 - support for non postional arguments (new in XOTcl 1.3.2) - user preferences setting (for editor and list fonts and background colors) - many fixes and improvements of user usability (Michael Heca) - improved class browser (MH) - all browser supports paned windows (MH and AT) - bugfixes by syntax parser XOTclIDE 0.70 was developed and tested with not official version of XOTcl 1.3.2 but is still backwarts compatible with XOTcl 1.2 Many thanks to Michael Heca for many (more than 30) bug fixes, improvements of usability and suggestions starkits for XOTclIDE 0.70 are comming soon. Artur Trzewik From Bryan.Schofield at trans.ge.com Wed Oct 27 22:51:48 2004 From: Bryan.Schofield at trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Wed Oct 27 22:52:03 2004 Subject: [Xotcl] Bug: Empty arglist and body throws error Message-ID: Hullo - I'm afraid I found a bug that will generate an "unable to dispatch" error if the argument list & body of an instproc are both empty. You will notice that as long as either contain something, it's ok. Notice the body of "Bar notpuke", it's just a single comment. See the code below: Gustaf -- This is the build that I downloaded from you on October 18th at: http://media.wu-wien.ac.at/download/xotcl-1.3.3.tar.gz -- blah.tcl -- package require XOTcl 1.3 namespace import ::xotcl::* Class Foo Foo instproc puke {} {} Class Bar Bar instproc notpuke {} {#} Class Ack Ack instproc notpuke {a} {} Bar b b notpuke Ack a a notpuke x Foo f f puke -- End -- Produces the following error: ::f: unable to dispatch method 'puke' while executing "f puke" (file "/homes/bschofie/blah.tcl" line 20) > -----Original Message----- > From: xotcl-bounces@alice.wu-wien.ac.at > [mailto:xotcl-bounces@alice.wu-wien.ac.at]On Behalf Of Gustaf Neumann > Sent: Friday, October 15, 2004 1:03 PM > To: xotcl@alice.wu-wien.ac.at > Subject: Re: [Xotcl] xotcllib? > > > On Friday 15 October 2004 18:47, Schofield, Bryan \(GE > Transportation\) wrote: > > Does xotcllib, or some other collection of XOTcl utility > packages exist? > just the library that comes with the source in xotcl*/library > -gustaf > > -- > Univ.Prof. Dr.Gustaf Neumann > Abteilung f?r Wirtschaftsinformatik und Neue Medien > Wirtschaftsuniversit?t Wien, Augasse 2-6, 1090 Wien > _______________________________________________ > Xotcl mailing list > Xotcl@alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl > From neumann at wu-wien.ac.at Wed Oct 27 23:54:19 2004 From: neumann at wu-wien.ac.at (Gustaf Neumann) Date: Wed Oct 27 23:54:21 2004 Subject: [Xotcl] Bug: Empty arglist and body throws error References: Message-ID: <007601c4bc6f$833978b0$a100a8c0@tpn> Dear Bryan, > I'm afraid I found a bug that will generate an "unable to dispatch" error if the argument list & body of an >instproc are both empty. You will notice that as long as either contain something, it's ok. Notice the body of >"Bar notpuke", it's just a single comment. See the code below: we have a behavior in xotcl that we inherited from otcl: when instproc is invoked with an empty argument list and an empty body, this instproc is deleted. Most probably, we should do the following: a) produce an error, when someone tries to delete a non.existing proc/instproc b) document this behavior somewhere more visible. -gustaf From Bryan.Schofield at trans.ge.com Thu Oct 28 15:03:50 2004 From: Bryan.Schofield at trans.ge.com (Schofield, Bryan (GE Transportation)) Date: Thu Oct 28 15:04:22 2004 Subject: [Xotcl] Bug: Empty arglist and body throws error Message-ID: I think the ability to delete an instproc is handy, I just didn't realize what was going on. Thanks for the quick response. --bryan > -----Original Message----- > From: Gustaf Neumann [mailto:neumann@wu-wien.ac.at] > Sent: Wednesday, October 27, 2004 5:54 PM > To: Schofield, Bryan (GE Transportation); xotcl@alice.wu-wien.ac.at > Subject: Re: [Xotcl] Bug: Empty arglist and body throws error > > > Dear Bryan, > > > I'm afraid I found a bug that will generate an "unable to > dispatch" error > if the argument list & body of an >instproc are both empty. > You will notice > that as long as either contain something, it's ok. Notice the > body of >"Bar > notpuke", it's just a single comment. See the code below: > > we have a behavior in xotcl that we inherited from otcl: > when instproc is > invoked > with an empty argument list and an empty body, this instproc > is deleted. > Most probably, we should do the following: > a) produce an error, when someone tries to delete a non.existing > proc/instproc > b) document this behavior somewhere more visible. > > -gustaf > >