Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

XOTcl 1.5.3 available
by Gustaf Neumann 25 Nov '06

25 Nov '06

Dear XOTcl Community, i am pleased to announce XOTcl 1.5.3. This is an unplanned bugfix release, which is necessary due to certain changes in Tcl 8.4.14, which can lead to memory corruption in certain applications when xotcl is used. In particular, installations of OpenACS/DotLRN using Tcl 8.4.14 are required to upgrade to XOTcl 1.5.3. Major changes relative to 1.5.2 are: + provided compatibility with Tcl 8.5 + provided compatibility with Tcl 8.4.14 (fixed a nasty bug caused by a change in tcl 8.4.14, could led to a crash due to freed Tcl_Objs in OpenACS, allthough the xotcl regression test passed correctly) + reduced calling overhead of methods with nonpositional arguments by about 10 percent by avoiding shimmering. + fixed handling of "return -code break" from xotcl methods (thanks to Artur Trzewik for the bug report) + library/comm/Access.xotcl: fixed handling of chunked encoding For more details about the changes, please consult the ChangeLog. MORE INFO General and more detailed information about XOTcl and its components can be found at http://www.xotcl.org Best regards, Gustaf Neumann Uwe Zdun

1 0

XOTcl on pocketpc
by Cristian Chaparro 23 Nov '06

23 Nov '06

Hi all, Has anybody compiled xotcl to be used on a pocketpc with etcl? Libraries, instructions... whatever info is welcome. Thanks. Cristian -- Ce message a ete verifie par MailScanner pour des virus ou des polluriels et rien de suspect n'a ete trouve. CRI Université de Perpignan

2 1

Children object shadows parent objects method
by V.K.Vallinayagam 22 Nov '06

22 Nov '06

Hi, I just joined this list to get this help. I am seeing this behaviour. It is giving lot of inconvenience to me. I want to know if it is a bug or not -?. In short, if I have a children object as the same name as parent object's proc/instproc . The parent object's method is not getting called. Here is a sample code. Object a Object a proc name {} { return "I am valli" } a name # returns "I am valli" Object a::name # Child object with same name as the proc a name # returns ::a::name and not the previous message Is this the desired behaviour. Is there any workaround. Regards Vallinayagam valli(a)ezorder.in

2 2

AW: [Xotcl] Children object shadows parent objects method
by mail＠xdobry.de 22 Nov '06

22 Nov '06

Hi! It's not a bug it's a feature. Children object can be accessed per shortcuts like methods. my mychild childmethod par1 par2 It can be confusing about reading such code. therefore I use by coding XOTclIDE convencion that all child objects beginns with @ Also XOTclIDE syntax checker will understand this. so the code will look my @mychild childmethod par1 par2 Anyway I use often methods call like this [my info parent] parentMethod why not a shourtcut for it my parent parentMethod Artur Trzewik >Hi, > I just joined this list to get this help. I am seeing this behaviour. >It is giving lot of inconvenience to me. I want to know if it is a bug >or not -?. > In short, if I have a children object as the same name as parent >object's proc/instproc . The parent object's method is not getting called. > > Here is a sample code. > > Object a > Object a proc name {} { > return "I am valli" > } > a name # returns "I am valli" > Object a::name # Child object with same name as the proc > a name # returns ::a::name and not the previous message > > Is this the desired behaviour. Is there any workaround. > >Regards >Vallinayagam >valli(a)ezorder.in > > >_______________________________________________ >Xotcl mailing list >Xotcl(a)alice.wu-wien.ac.at >http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

1 0

Small compatiblity problems with XOTcl 1.5.2 - tk bind
by Artur Trzewik 20 Nov '06

20 Nov '06

Hi XOTcl friends! I have found some small incompatibility between XOTcl 1.4 and 1.5 by using XOTclIDE. It considers tk binding I use code as follow bind $twin <KeyPress-Tab> [list [self] tabPress] IDE::TclModeEdit instproc tabPress {} { # ..... return -code break } the "return -code break" have caused that the event is not propagated more. See more in Tk bind command manual. It does not work with XOTcl 1.5.2. I use small work around by wrapping XOTcl method in Tcl proc now. XOTcl Method returns a boolean value. bind $twin <KeyPress-Tab> [list tabPressHandler [self]] proc tabPressHandler object { if {[$object tabPress]} { return -code break } } This incompatibility causes bad behavior in XOTclIDE editor. (Code completion and automatic indenting). I plan to ship next XOTclIDE version in some time without this problem. Artur Trzewik

2 1

Troubles with upvar and the trace mechanism from the tutorial.
by Shishir Ramam 19 Nov '06

19 Nov '06

I am passing an array name by reference across an instproc. The vanilla version works just fine (see creation of x1 midway through the code segment). To add some debugging in, I essentially used the trace example from the tutorial, and funnily, the upvar stopped doing it's job (see error on creating x2 towards the end of the code segment). To get rudimentary debug control of the parray proc, I copied it into a proc called barray. None of the logic is changed - just my crude attempt at adding breadcrumbs. I have included the output at the end of the code segment. Running Windows XP Pro + Active Tcl 8.4.13 + XoTcl 1.4.0. thanks for all help. -shishir <CODE SEGMENT> package require XOTcl namespace import ::xotcl::* proc barray {a {pattern "*"}} { puts "barray" upvar 1 $a arr if {![array exists arr]} { error "\"$a\" isn't an array" } set maxl 0 foreach name [lsort [array names arr $pattern]] { if {[string length $name] > $maxl} { set maxl [string length $name] } } set maxl [expr {$maxl + [string length $a] + 2}] foreach name [lsort [array names arr $pattern]] { set nameString [format %s(%s) $a $name] puts stdout [format "%-*s = %s" $maxl $nameString $arr($name)] } } Class X X instproc bar {ar args} { puts "bar" upvar $ar arr puts "upvard" barray arr } X instproc init {args} { array set arr {a 1 b 2} parray arr my bar arr } X x1 Object Trace Trace set traceStream stdout Trace proc openTraceFile name { my set traceStream [open $name w] } Trace proc closeTraceFile {} { close $Trace::traceStream my set traceStream stdout } Trace proc puts line { puts $Trace::traceStream $line } Trace proc add className { $className instfilter [concat [$className info filter] traceFilter] } Object instproc traceFilter args { # don't trace the Trace object if {[string equal [self] ::Trace]} {return [next]} set context "[self class]->[self callingproc]" set method [self calledproc] switch -- $method { proc - instproc {::set dargs [list [lindex $args 0] [lindex $args 1] ...] } default {::set dargs $args } } Trace::puts "CALL $context> [self]->$method $dargs" set result [next] Trace::puts "EXIT $context> [self]->$method ($result)" return $result } Trace add X X x2 </CODE SEGMENT> ------------ <OUTPUT> arr(a) = 1 arr(b) = 2 bar upvard barray arr(a) = 1 arr(b) = 2 CALL ::xotcl::Object->> ::x2->cleanup EXIT ::xotcl::Object->> ::x2->cleanup () CALL ::xotcl::Object->> ::x2->configure EXIT ::xotcl::Object->> ::x2->configure (0) CALL ::xotcl::Object->> ::x2->init arr(a) = 1 arr(b) = 2 CALL ::xotcl::Object->init> ::x2->bar arr bar upvard barray "arr" isn't an array </OUTPUT> ---- <ERRORINFO> % set errorInfo "arr" isn't an array while executing "error "\"$a\" isn't an array"" (procedure "barray" line 5) invoked from within "barray arr" (procedure "bar" line 6) invoked from within "next" (procedure "bar" line 13) ::x2 ::xotcl::Object->traceFilter invoked from within "my bar arr" (procedure "init" line 5) invoked from within "next" (procedure "init" line 13) ::x2 ::xotcl::Object->traceFilter ::X ::xotcl::Class->recreate ::X ::xotcl::Class->create ::X ::xotcl::Class->unknown invoked from within "X x2" (file "c:/temp/trace_trouble.tcl" line 81) invoked from within "source c:/temp/trace_trouble.tcl" </ERRORINFO>

2 1

non-positional arguments and init proc
by Shishir Ramam 11 Nov '06

11 Nov '06

I must be missing something here - but are non-positional arguments not permitted on the init proc? A transcript of my attempts below... thanks in advance for any help. -shishir % Class foo -parameter {{-a "apple"}} ::foo % foo instproc init {{-a "apple"} args} {} % foo f ::f % foo f -a "banana" ::f: unable to dispatch method 'a' during '::f a' % foo f a "banana" ::f % foo instproc init {{-a "apple"} args} { puts "a=$a args=$args" } % foo f a "banana" a=apple args=a banana ::f % foo f -a "banana" ::f: unable to dispatch method 'a' during '::f a' % foo instproc init {{a "apple"} args} { puts "a=$a args=$args" } % foo f a "banana" a=a args=banana ::f % -- The point of living and of being an optimist, is to be foolish enough to believe the best is yet to come. - Peter Ustinov

2 1

Namespaces and Xotcl
by Shishir Ramam 29 Oct '06

29 Oct '06

Hi, Was wondering why it's not possible to import namespaces when XOTcl objects are involved. The shortest example that I could rustle up is included below. Help in understanding what prevents this from working is much appreciated. -shishir % package require XOTcl 1.4.0 % namespace eval ::my::test { namespace import ::xotcl::* Class Foo Foo instproc bar {} { puts " foo bar is a very tasty!" } } % ::my::test::Foo foo ::foo % foo bar foo bar is a very tasty! % ::my::test::Foo info instances ::foo % # Why doesn't the following work? % namespace import ::my::test::* % Foo foo2 invalid command name "Foo" % ::my::test::Foo info instances ::foo % Foo info instances invalid command name "Foo"

2 2

Creating objects from C
by Scott Gargash 28 Oct '06

28 Oct '06

When creating XOTcl objects from C, it would be nice to be able to initialize the new object's clientData prior to any methods being invoked on the object. Right now, the only way I can think of to do this is to 1. create the object (which invokes "init", which can't rely on the ClientData) 2. XOTclSetObjectClientData( XOTclGetObject(), data); // Or the Class equivalent 3. Invoke some secondary, private "init"-like method that does true initialization It would be nice to have two new exported functions: int XOTclCreateObjectCl (Tcl_Interp* in, Tcl_Obj* name, ClientData data, struct XOTcl_Class* cl); int XOTclCreateClassCl (Tcl_Interp* in, Tcl_Obj* name, ClientData data, struct XOTcl_Class* cl); That initialize the XOTcl ClientData field prior to invoking "init" so that "init" could rely on the XOTcl ClientData being valid. This would make it much easier to construct XOTcl wrappers around C/C++ objects. Is this reasonable? Is there a better way to accomplish this? Scott Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you.

2 1

Building debug version on Windows
by Jamie Rasmussen 25 Oct '06

25 Oct '06

Hello, I have a binary installer of AOLserver 4.5 for Win32, and I'd like to add XOTcl 1.5.2 to it, since I know OpenACS 5.3 will require it. While running some load tests on the binaries I built I saw a crash in XOTclAddIMethod. I'm not worried about that crash yet, since I think it might have been caused by a bad interaction with the nstclprof module. But to investigate further, I tried to compile a debug version of XOTcl, and I've run into some problems. The compiler is Visual Studio 6, and the command line I was using is: nmake /f Makefile.vc DEBUG=1 * I am trying to compile against TCL 8.4.14, which was compiled with the threads and thrdalloc options. The first problem I had was with the values of TCLIMPLIB and TCLSH in Makefile.vc, which didn't reflect that the threaded build includes a 't' in the filename before $(DBGX) for the .lib and tclsh. This applies to \library\store\XOTclSdbm\Makefile.vc too. * The -WX compiler option (error instead of warning) is specified for DEBUG=1, so compilation aborts because of this warning: ..\generic\xotcl.c(5271) : warning C4018: '==' : signed/unsigned mismatch. * I also noticed XOTCL_RELEASE_LEVEL=.0 and not .2 - is that intentional? Any suggestions? I'm new to XOTcl, but I already like it - thanks. Jamie

1 0

← Newer
1
...
22
23
24
25
26
27
28
...
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