Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

Bug: Non-positional args with no value cause core dump
by Schofield, Bryan (GE Transportation) 10 Nov '04

10 Nov '04

Gustaf/Uwe - I found a little bug in 1.3.3 that I downloaded on October 15th from=20 http://media.wu-wien.ac.at/download/xotcl-1.3.3.tar.gz The following causes a core dump on my Solaris workstation: Object o o proc foo {{-foo 1}} {} { puts "foo: $foo" } o foo #--> "foo: 1" o foo -foo 0 #--> "foo: 0" o foo -foo #--> BOOM! Just thought I'd pass that on. Regards -- bryan

1 0

XOTcl extending nonPosArgs class
by Giovanni Cristelli 04 Nov '04

04 Nov '04

With version 1.3.0 I've tried to extend the class to support a new option in using the following code: xotcl::nonPosArgs proc in { allowedValues argName args} { if { [lsearch $allowedValues $args] == -1 } { error "Invalid value |$args| for option $argName (allowed values: [join $allowedValues {, }])" } } example: Class create A A proc y {{{-q:in {add remove}} add}} {} { puts $q } A y; # prints add A t -q bad; # throw an error A y -q remove; # prints remove With version 1.3.1 this code doesn't work anymore and the error returned is: ::xotcl::nonPosArgs: unable to dispatch method 'in {add remove}' How can I change the prototype to make it work again ? Thanks, Giovanni. -------------------------------------------------------------------- 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(a)telecomitalia.it. Thank you www.telecomitalia.it --------------------------------------------------------------------

1 0

RE: [Xotcl] [Fwd: Bug with namespace'd Class?]
by Schofield, Bryan (GE Transportation) 02 Nov '04

02 Nov '04

I don't think it is a bug, and I don't think it is unexpected behavior...exactly; more on that in a second. In fact, if it *were* available, as you expected, I'd consider that bad behavior since no package should ever export commands into the root namespace automatically. So, if it's not behaving badly, but still isn't exactly what you expected, where does this discrepancy come from, and how is it resolved? I suggest that documentation is culprit and the solution. I think that an "XOTcl & Namespaces" section or a "General XOTcl Usage" section that describe this situation would beneficial. Btw, I remember when I first stumbled across this; it made me step back and scratch my head too. --bryan > -----Original Message----- > From: xotcl-bounces(a)alice.wu-wien.ac.at > [mailto:xotcl-bounces@alice.wu-wien.ac.at]On Behalf Of Damon Courtney > Sent: Tuesday, November 02, 2004 3:27 PM > To: xotcl(a)alice.wu-wien.ac.at > Subject: RE: [Xotcl] [Fwd: Bug with namespace'd Class?] > > > I figured as much. I guess I'll just do import the > commands into the > root namespace. It doesn't really bother me, but some of the other > Tcl'ers are real sticklers about namespacing everything. I just use > what's best. 0-] > > So, does this still constitute a bug then, or should I > just chalk it > up to expected behavior? > > Thanks, > > Damon > > > because "self" is a command in the xotcl namespace. you > will also find > > that there are others, such a "my" > > > > If you don't import xotcl, you end up with source that > looks like this: > > > > ::xotcl::Class foo > > Foo instproc bar {} { > > puts "[::xotcl::self] is a [::xotcl::my info class]" > > } > > > > > > I'd suggest, do something like the following... > > > > package require XOTcl 1.3 > > namespace eval fooPackage { > > namespace import ::xotcl::* > > Class Foo > > Foo instproc bar {} { > > puts "[self] is a [my info class]" > > } > > } > > > > > > hope that helps. > > -- bryan > > > >> -----Original Message----- > >> From: xotcl-bounces(a)alice.wu-wien.ac.at > >> [mailto:xotcl-bounces@alice.wu-wien.ac.at]On Behalf Of > Damon Courtney > >> Sent: Tuesday, November 02, 2004 2:23 PM > >> To: xotcl(a)alice.wu-wien.ac.at > >> Subject: [Xotcl] [Fwd: Bug with namespace'd Class?] > >> > >> > >> Why does this not work? > >> > >> package require XOTcl > >> > >> ::xotcl::Class Foo > >> > >> Foo instproc bar {} { > >> puts "SELF = [self]" > >> } > >> > >> Foo foo > >> % Foo foo > >> ::foo > >> % foo bar > >> invalid command name "self" > >> > >> > >> But, if I "namespace import ::xotcl::*" and make the > >> class with just > >> the Class command (not ::xotcl::Class), it works. > >> > >> Any ideas? > >> > >> D > >> > >> PS: Windows, Tcl 8.4.3, XOTcl 1.3.1 > >> > >> _______________________________________________ > >> Xotcl mailing list > >> Xotcl(a)alice.wu-wien.ac.at > >> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl > >> > > > > _______________________________________________ > > Xotcl mailing list > > Xotcl(a)alice.wu-wien.ac.at > > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl > > > > > _______________________________________________ > Xotcl mailing list > Xotcl(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl >

1 0

RE: [Xotcl] [Fwd: Bug with namespace'd Class?]
by Schofield, Bryan (GE Transportation) 02 Nov '04

02 Nov '04

because "self" is a command in the xotcl namespace. you will also find that there are others, such a "my" If you don't import xotcl, you end up with source that looks like this: ::xotcl::Class foo Foo instproc bar {} { puts "[::xotcl::self] is a [::xotcl::my info class]" } I'd suggest, do something like the following... package require XOTcl 1.3 namespace eval fooPackage { namespace import ::xotcl::* Class Foo Foo instproc bar {} { puts "[self] is a [my info class]" } } hope that helps. -- bryan > -----Original Message----- > From: xotcl-bounces(a)alice.wu-wien.ac.at > [mailto:xotcl-bounces@alice.wu-wien.ac.at]On Behalf Of Damon Courtney > Sent: Tuesday, November 02, 2004 2:23 PM > To: xotcl(a)alice.wu-wien.ac.at > Subject: [Xotcl] [Fwd: Bug with namespace'd Class?] > > > Why does this not work? > > package require XOTcl > > ::xotcl::Class Foo > > Foo instproc bar {} { > puts "SELF = [self]" > } > > Foo foo > % Foo foo > ::foo > % foo bar > invalid command name "self" > > > But, if I "namespace import ::xotcl::*" and make the > class with just > the Class command (not ::xotcl::Class), it works. > > Any ideas? > > D > > PS: Windows, Tcl 8.4.3, XOTcl 1.3.1 > > _______________________________________________ > Xotcl mailing list > Xotcl(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl >

2 1

[Fwd: Bug with namespace'd Class?]
by Damon Courtney 02 Nov '04

02 Nov '04

Why does this not work? package require XOTcl ::xotcl::Class Foo Foo instproc bar {} { puts "SELF = [self]" } Foo foo % Foo foo ::foo % foo bar invalid command name "self" But, if I "namespace import ::xotcl::*" and make the class with just the Class command (not ::xotcl::Class), it works. Any ideas? D PS: Windows, Tcl 8.4.3, XOTcl 1.3.1

1 0

RE: [Xotcl] Bug: Empty arglist and body throws error
by Schofield, Bryan (GE Transportation) 28 Oct '04

28 Oct '04

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(a)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 > >

1 0

Bug: Empty arglist and body throws error
by Schofield, Bryan (GE Transportation) 27 Oct '04

27 Oct '04

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(a)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(a)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(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl >

2 1

XOTclIDE in version 0.70 updated for XOTcl 1.3.2
by Artur Trzewik 23 Oct '04

23 Oct '04

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

1 0

RE: [Xotcl] XOTcl / Tcl Namespace issues
by Schofield, Bryan (GE Transportation) 23 Oct '04

23 Oct '04

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(a)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(a)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(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl >

3 2

XOTcl / Tcl Namespace issues
by Adam Turoff 22 Oct '04

22 Oct '04

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

1 0

← Newer
1
...
35
36
37
38
39
40
41
...
66
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Xotcl