Xotcl November 2004

xotcl@alice.wu.ac.at

6 participants
17 discussions

cum patch #42 for xotcl-1.3.3
by Jeff Hobbs 01 Dec '04

01 Dec '04

I'm not sure how many I've sent so far, but I hope this is the last ;). In addition to the previous, this corrects: * CallStackGetFrame patch from Gustaf, exposed by HP build * make doc on Windows now works (from cygwin build) In doing test-core, the very end can sometimes complain that xotcl::test isn't found - I think this is expecting an installed version or something. Also, 'make doc' on Windows catches one failure: ...z:\src\xotcl-1.3.3\tests\testx.xotcl error processing z:\src\xotcl-1.3.3\tests\testx.xotcl: too many nested evaluations (infinite loop?) (procedure "getCommand" line 1) ::docdb26 ::StaticMetadataAnalyzer->getCommand invoked from within "my getCommand c" (procedure "getCommand" line 25) ::docdb26 ::StaticMetadataAnalyzer->getCommand invoked from within "my getCommand c" (procedure "getCommand" line 25) ::docdb26 ::StaticMetadataAnalyzer->getCommand invo... So doing the doc on that pushes the stack limit I think, as it takes a while on any platform for that file. I would rewrite that proc to not be recursive - getCommand could iterate ones over the string and break it into a list of commands (as tkcon does). We are still seeing some issues with 8.5 build/installs, but I think they may be localized (and not as important at this point). Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos

1 0

updated patch for xotcl 1.3.3
by Jeff Hobbs 01 Dec '04

01 Dec '04

I have updated my patch from yesterday. This has been tested across a much more elaborate set of platforms. My guess is that xotcl has not been compiled against anything but gcc, or installed on non-linux systems. This patch builds and installs on the following variants: * Windows-x86 (cygwin/MSVC build) * Linux-x86 and x86_64 (gcc) * HP-UX 11 pa-risc (gcc and cc) * HP-UX 11 ia64 (cc) * AIX 4.3.3 (xlc) * Solaris 2.8 (gcc and cc) test-core fails on HP-UX 11 pa-risc with: FAILED: FAILED - UpLevel Test 2 Got: ::o Expected: ::s 0 g='::o' e='::s' make: *** [test-core] Error 255 and on some other platforms it can fail on exit (bad cleanup?), but this gets things a lot further. I don't think the ALLOC checks are being done properly, as I said before - there is too much expectation that gcc-isms can be the default, which isn't correct, IMO. Part of this patch is the for loop break fix in xotcl.c that I mentioned in my last message - that seems to have no effect on the test-core for the platforms. It's probably best to just take this patch directly and call it xotcl-1.3.4, unless you want to further clean up based on my other suggestions (like ALLOC stuff). Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos

2 3

bug in XOTcl_DeleteCommandFromToken ?
by Jeff Hobbs 30 Nov '04

30 Nov '04

I found this oddity in XOTcl_DeleteCommandFromToken: XOTclCallStackContent *csc = cs->top; for (; csc > cs->content; csc--) { - if (csc->cmdPtr == cmd) - csc->cmdPtr = NULL; - break; + if (csc->cmdPtr == cmd) { + csc->cmdPtr = NULL; + break; + } } return Tcl_DeleteCommandFromToken(in, cmd); } Is my fix correct, or is there some magic reason why you would want to break after the first 'if' check no matter what? BTW - any conditionals without { } is BAD CODE, for exactly the above reason. Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos

2 1

yet more fixes to xotcl-1.3.3 ...
by Jeff Hobbs 30 Nov '04

30 Nov '04

The patches I send are cumulative, so you just need this patch against pristine xotcl-1.3.3. This patch adds to the previous with fixes for compiling against 8.5 on Windows. There was header management changes in 8.5 which force a different order of includes, and this causes several redefine issues. In general though, enums with names like INIT, ALLOC, EMPTY and ZERO should not be considered very exclusive. ;) Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos

1 0

xotcl-1.3.3 Makefile / configure fixes
by Jeff Hobbs 30 Nov '04

30 Nov '04

Attached is a patch to xotcl to make it build better. The changes are to correct the build and install both on unix and Windows. The fixes correct: * installation when built outside source directory * build and installation on Windows using TEA * more clarity during install-libraries The addition of VISUAL_CC to the defines on Windows highlights a generally incorrect usage of Windows-checking constructs. You can add things like #ifdef _MSC_VER in your C code, or better yet it should simply switch on: #if defined(WIN32) which tcl.h defines, and for the USE_MALLOC case, something like this should suffice: #if defined(WIN32) && !(defined(__GNUC__) but the changes I made work, just in a less favorable way. Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos

1 1

XOTcl 1.3.3 available
by Gustaf Neumann 27 Nov '04

27 Nov '04

Dear XOTcl Community, XOTcl 1.3.3 is available. Major changes relative to 1.3.1 are: - Qualitative Improvements * Improved code quality: + fixed possible segmentation violations in free memory reads (many thanks to Zoran Vasiljevic for his help with purify) + fixed "self callinglevel" when uplevel was called from uplevel + fixed nonposargs + fixed configure in connection with enable-symbols and for aolserver configuration + extended regression test * Improved Functionality + Producing error message when a non-existing proc/instproc is tried to be deleted + fixed exists method for objects with namespaces by using a namespace resolver + fixed return code for unknown handling in next + reduced memory consumption for objects and classes with procs/instprocs of about 14% * Improved Documentation We will annouce XOTcl 1.3.3 on c.l.t, when we have the windows binaries Greetings -gustaf neumann -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

1 0

Using uplevel within instprocs from instprocs
by MichaelL＠frogware.com 19 Nov '04

19 Nov '04

I've defined a proc which is supposed to be a control structure that iterates over the children of an object. There's a problem, though, when I nest calls. Here's some code: Object instproc each {objName body} { puts " *** level = [info level]" puts " *** self callinglevel = [self callinglevel]" uplevel [self callinglevel] [list foreach $objName [lsort [[self] info children]] $body] } Class TestB Class TestA TestA instproc init {args} { next TestB [self]::b1 TestB [self]::b2 TestB [self]::b3 } Class Test Test instproc init {args} { next TestA [self]::a1 TestA [self]::a2 TestA [self]::a3 } Test instproc loop1 {} { set i 0 [self] each a { incr i puts "$a" } puts "Total = $i" } Test instproc loop2 {} { set i 0 [self] each a { incr i puts "$a" $a each b { incr i puts " $b" } } puts "Total = $i" } Test t t loop1 t loop2 Here's some output: *** level = 2 *** self callinglevel = #1 ::t::a1 ::t::a2 ::t::a3 Total = 3 *** level = 2 *** self callinglevel = #1 ::t::a1 *** level = 2 *** self callinglevel = #2 can't read "i": no such variable (reading value of variable to increment) invoked from within "incr i" ("foreach" body line 2) invoked from within "foreach b {::t::a1::b1 ::t::a1::b2 ::t::a1::b3} { incr i puts " $b" }" ("uplevel" body line 1) invoked from within "uplevel [self callinglevel] [list foreach $objName [lsort [[self] info children ]] $body]" (procedure "each" line 5) ::t::a1 ::xotcl::Object->each invoked from within "$a each b { incr i puts " $b" }" ("foreach" body line 4) invoked from within "foreach a {::t::a1 ::t::a2 ::t::a3} { incr i puts "$a" $a each b { incr i puts " ..." ("uplevel" body line 1) invoked from within "uplevel [self callinglevel] [list foreach $objName [lsort [[self] info children ]] $body]" (procedure "each" line 5) ::t ::xotcl::Object->each invoked from within "[self] each a { incr i puts "$a" $a each b { incr i puts " $b" } ..." (procedure "loop2" line 4) ::t ::Test->loop2 invoked from within "t loop2" invoked from within "if 1 { Object instproc each {objName body} { puts " *** level = [info level]" puts " *** self callinglevel = [self cal..." (file "XOTcl-test.tcl" line 7) You can see that the one-level iterator succeeds, but the two-level iterator can't see the variable defined in the outer loop. You can also see that the first time "level" and "callinglevel" are different (as you would expect) but the second time they're the same (which looks like it might be an XOTcl bug). Any ideas? (I can work around this for now, of course, but it would be nice to figure out what's wrong.)

2 1

Catching errors in calls to "next"
by MichaelL＠frogware.com 16 Nov '04

16 Nov '04

I'm using XOTcl 1.3.1. (I haven't upgraded to the 1.3.3 beta yet.) I have a filter that does work before and after calls to "next". I'd like to make sure that the "after" code always gets called, so I'm using "catch" around my call to "next," a bit like this: # do something before set err [catch {next} result] # do something after The problem is that in specific circumstances (when objects are constructed) the fact that "next" is called within "catch" is screwing things up. (The error I'm getting is "5", which is defined in XOTcl as "XOTCL_UNKNOWN".) I can see why "catch" would get in the way, but so far I haven't found a way around the problem. Does anyone have any ideas? Here's some sample code. TestA works (as expected), but TestB doesn't. Object instproc someFilterA {args} { puts "self class = [self class]" puts "self = [self]" puts "self calledclass = [self calledclass]" puts "self calledproc = [self calledproc]" puts "args = $args" puts "" set err 0 set result [next] if {$err==0 || $err==2 || $err==3 || $err==4} { # 0 = OK # 2 = Return # 3 = Break # 4 = Continue return $result } else { # 1 = Error # * = Error (user-defined) return -code error $result } } Object instproc someFilterB {args} { puts "self class = [self class]" puts "self = [self]" puts "self calledclass = [self calledclass]" puts "self calledproc = [self calledproc]" puts "args = $args" puts "" set err [catch {next} result] if {$err==0 || $err==2 || $err==3 || $err==4} { # 0 = OK # 2 = Return # 3 = Break # 4 = Continue return $result } else { # 1 = Error # * = Error (user-defined) return -code error $result } } puts "*** Initializing..." puts "" Class TestA -parameter {{x 0}} -filter someFilterA TestA instproc err {} { expr {5/0} } Class TestB -parameter {{x 0}} -filter someFilterB TestB instproc err {} { expr {5/0} } puts "*** Starting..." puts "" TestA ::a -x 5 a x a x 10 #a err puts "" puts "----------" puts "" TestB ::b -x 5 b x b x 10 #b err puts "*** Finished." The relevant part of the output is: *** Starting... self class = ::xotcl::Object self = ::TestA self calledclass = self calledproc = ::a args = -x 5 self class = ::xotcl::Object self = ::TestA self calledclass = ::xotcl::Class self calledproc = unknown args = ::a -x 5 self class = ::xotcl::Object self = ::TestA self calledclass = ::xotcl::Class self calledproc = create args = ::a -x 5 self class = ::xotcl::Object self = ::TestA self calledclass = ::xotcl::Class self calledproc = alloc args = ::a -x 5 ---------- self class = ::xotcl::Object self = ::TestB self calledclass = self calledproc = ::b args = -x 5 ::TestB ::xotcl::Object->someFilterB invoked from within "TestB ::b -x 5" invoked from within "if 1 { Object instproc someFilterA {args} { puts "self class = [self class]" puts "self = [self]" puts "..." (file "XOTcl-test.tcl" line 7) self class = ::xotcl::Object self = ::TestA self calledclass = ::xotcl::Class self calledproc = instdestroy args = ::a self class = ::xotcl::Object self = ::TestA self calledclass = ::xotcl::Object self calledproc = destroy args = self class = ::xotcl::Object self = ::TestB self calledclass = ::xotcl::Object self calledproc = destroy args =

2 2

RE: [Xotcl] Filters on classes
by Schofield, Bryan (GE Transportation) 15 Nov '04

15 Nov '04

One other thought... have you tried explicitly namespace scoping your object... I know that there were some namespace issues with the early 1.3 series. try: TestA ::a ::a x 1 > -----Original Message----- > From: xotcl-bounces(a)alice.wu-wien.ac.at > [mailto:xotcl-bounces@alice.wu-wien.ac.at]On Behalf Of > MichaelL(a)frogware.com > Sent: Monday, November 15, 2004 10:33 AM > To: xotcl(a)alice.wu-wien.ac.at > Subject: [Xotcl] Filters on classes > > > I'm using XOTcl 1.3.1. > > This code: > > Object instproc someFilter {args} { > puts "self class = [self class]" > puts "self called class = [self calledclass]" > puts "self = [self]" > puts "self calledproc = [self calledproc]" > puts "args = $args" > puts "" > next > } > > Class TestA -parameter {{x 0}} > TestA filter someFilter > > TestA a > a x > a x 10 > > produces this output: > > self class = ::xotcl::Object > self called class = > self = ::TestA > self calledproc = a > args = > > self class = ::xotcl::Object > self called class = ::xotcl::Class > self = ::TestA > self calledproc = unknown > args = a > > self class = ::xotcl::Object > self called class = ::xotcl::Class > self = ::TestA > self calledproc = create > args = a > > self class = ::xotcl::Object > self called class = ::xotcl::Class > self = ::TestA > self calledproc = alloc > args = a > > invalid command name "a" > > Note that filtering on "TestA a" seems to prevent the > creation of an obj > named "a". Any ideas? > > _______________________________________________ > Xotcl mailing list > Xotcl(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl >

2 1

RE: [Xotcl] Filters on classes
by Schofield, Bryan (GE Transportation) 15 Nov '04

15 Nov '04

hmm.. I just tried this with Gustaf's 1.3.3 version and it works for me... Give this a try and see if this works for you: http://media.wu-wien.ac.at/download/xotcl-1.3.3.tar.gz It's pre-release build that I've been testing for several weeks now that has some bug fixes in it. -- bryan > -----Original Message----- > From: xotcl-bounces(a)alice.wu-wien.ac.at > [mailto:xotcl-bounces@alice.wu-wien.ac.at]On Behalf Of > MichaelL(a)frogware.com > Sent: Monday, November 15, 2004 10:33 AM > To: xotcl(a)alice.wu-wien.ac.at > Subject: [Xotcl] Filters on classes > > > I'm using XOTcl 1.3.1. > > This code: > > Object instproc someFilter {args} { > puts "self class = [self class]" > puts "self called class = [self calledclass]" > puts "self = [self]" > puts "self calledproc = [self calledproc]" > puts "args = $args" > puts "" > next > } > > Class TestA -parameter {{x 0}} > TestA filter someFilter > > TestA a > a x > a x 10 > > produces this output: > > self class = ::xotcl::Object > self called class = > self = ::TestA > self calledproc = a > args = > > self class = ::xotcl::Object > self called class = ::xotcl::Class > self = ::TestA > self calledproc = unknown > args = a > > self class = ::xotcl::Object > self called class = ::xotcl::Class > self = ::TestA > self calledproc = create > args = a > > self class = ::xotcl::Object > self called class = ::xotcl::Class > self = ::TestA > self calledproc = alloc > args = a > > invalid command name "a" > > Note that filtering on "TestA a" seems to prevent the > creation of an obj > named "a". Any ideas? > > _______________________________________________ > Xotcl mailing list > Xotcl(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl >

1 0

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 November 2004