Xotcl August 2010

xotcl@alice.wu.ac.at

9 participants
9 discussions

XOTcl 1.6.6 available
by Gustaf Neumann 03 Nov '11

03 Nov '11

Announcing XOTcl 1.6.6 ************************* Dear XOTcl Community, We are pleased to announce the availability of XOTcl 1.6.6 Major changes relative to 1.6.5 are: * improved 64-bit compatibility (expat) * fixed minor memory leaks (info methods, forward error case) * fixed potential cyclic dependencies via namespace imports during cleanup * fixed potential crash with var-traces being fired twice * compatibility with Tcl 8.6b1 * fix for debian packaging For more details about the changes, please consult the ChangeLog and documentation. The planned next release will be 2.0.0 MORE INFORMATION General and more detailed information about XOTcl and its components can be found at http://www.xotcl.org best regards -gustaf neumann

1 1

Bug in filter processing?
by Kristoffer Lawson 30 Sep '10

30 Sep '10

Take a look at this code: package require XOTcl 1.6 namespace import xotcl::* Class Foo Foo instproc hello {} { puts hello } Foo instproc myfilter {args} { puts "\nme: [self]" ::set targetclass [my info class] puts "targetclass: $targetclass" puts "calledproc: [self calledproc]" ::set r [next] puts "back from next" puts "paramcmds: [$targetclass info instparametercmd]" } Foo instfilter myfilter Foo ob ob hello ob foo So first I have a filter installed which does nothing but print some information, and checks something using the [info] method afterwards. I call an instantiated object with [hello] (an existing method) and again with [foo] (a non-existing method). The latter is when things get interesting. Check the output: me: ::ob targetclass: ::Foo calledproc: configure back from next paramcmds: me: ::ob targetclass: ::Foo calledproc: init back from next paramcmds: me: ::ob targetclass: ::Foo calledproc: hello hello back from next paramcmds: me: ::ob targetclass: ::Foo calledproc: foo back from next me: ::alloc ::alloc: unable to dispatch method 'info' while executing "my info class" (procedure "cleanup" line 4) ::alloc ::Foo->myfilter ::Foo ::xotcl::Class->recreate ::Foo ::xotcl::Class->create ::Foo ::xotcl::Class->unknown ::Foo ::xotcl::Class->create ::Foo ::xotcl::Class->unknown ::Foo ::xotcl::Class->create ::Foo ::xotcl::Class->unknown invoked from within "$targetclass info instparametercmd" (procedure "foo" line 9) ::ob ::Foo->myfilter invoked from within "ob foo" (file "filtertest.tcl" line 24) me: ::alloc targetclass: ::Foo calledproc: destroy back from next paramcmds: me: ::info targetclass: ::Foo calledproc: destroy back from next paramcmds: me: ::ob targetclass: ::Foo calledproc: destroy back from next paramcmds: ... So while the [hello] method works as expected, things get totally weird for [foo]. The first thing we notice is that it doesn't jump out at [next] (which should give an error as it does not exist). It continue execution of the filter after [next]. This may or may not be intended, I don't know. The documentation is not clear on this. More interesting still, we end up with a totally unexpected error. The thing I believe is happening is that, for some reason or other [$targetclass info instparametercmd] is not ending up calling [info] for $targetClass, but creating an object called ::info (and thus overriding the original Tcl command). How [alloc] gets involved in the filter chain too, I am not sure. My guess is that the "unknown method" that resulted from [foo] is being interpreted by the XOTcl $targetclass C implementation as an error that occurred there, and that a new instance called "info" or possibly "alloc" should be created. This causes major havoc as soon as an unknown method is called. Does the filter code look correct? This happens with 1.6.2. I had a quick look at CHANGES for later versions and while there was some mention of memory leaks in [info] I wasn't sure if there was anything that would have fixed this. Any ideas? -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

4 8

renaming a instproc
by Kevin Van Workum 29 Aug '10

29 Aug '10

How do I rename a Class instproc? For example: Class T -parameter { {msg "Hello world!"} } T instproc hi {} { puts [my msg] } T instparametercmd msg T t t hi t msg "Good Bye!" t rename hi bye t bye Also, what's the difference between using "instparametercmd" and "parametercmd" in the example above? Thanks, Kevin -- Kevin Van Workum, PhD Sabalcore Computing Inc. Run your code on 500 processors. Sign up for a free trial account. www.sabalcore.com 877-492-8027 ext. 11

6 5

replacing libtcl
by Kevin Van Workum 12 Aug '10

12 Aug '10

Hi, I have an application (TORQUE resource manager) which provides a TCL interface to its C library and provides the ability to program its behaviour using TCL. Basically it has a C program (pbs_sched) which calls Tcl_CreateInterp() and other Tcl library calls, and then runs a TCL script which I can write to control its behaviour. I would like to include XOTcl functionality to my control script, but naively using "package require XOTcl" doesn't seem to work. I get "TCL error @ line 3: can't find package XOTcl". Which I guess indicates you can't do that from a standard TCL script. So, is there a simple way to drop the XOTcl interpretor in place of the normal Tcl interpretor? Or just to add XOTcl functionality? Thanks, Kevin -- Kevin Van Workum, PhD Sabalcore Computing Inc. Run your code on 500 processors. Sign up for a free trial account. www.sabalcore.com 877-492-8027 ext. 11

3 4

seachDefaults?
by Kristoffer Lawson 11 Aug '10

11 Aug '10

Gustaf (or others working on the core), you didn't say if this was an oversight of the current XOTcl documentation, or if somethins is missing on the [searchDefaults] stuff. Check here: http://media.wu-wien.ac.at/doc/langRef-xotcl.html#Class-create It states that the [searchDefaults] method is called to set default values for instance attributes (is this referring to parameter defaults as well?). However such a method does not exist for objects. I would like to be able to separate allocation, defaults and initialisation (via constructor) in object instantiation. -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

2 2

For anyone who wants their XOTcl instantiation safer
by Kristoffer Lawson 06 Aug '10

06 Aug '10

OK, I did a quick setup of an environment where [new] does not accept -dash initialised data, but with a separate [new-wish] that has a final argument, a script evaluated inside the object, which can do any pre-initialisation before the constructor is called. This solution works for me now and I'm not having issues with the couple of other XOTcl libraries I'm using. I think this is a pretty decent solution and the resulting instantiation code actually looks pretty nice and readable. I'm up to other names for "new-with". Maybe something like <new ?args? with ?initscript?.There's a mini-example at the bottom. Enjoy. Class SafeInit SafeInit instproc new {args} { return [next [concat [list -init] $args]] } SafeInit instproc new-with {args} { set script [lindex $args end] set args [lrange $args 0 end-1] set name [my autoname ::xotcl::stk__#] return [my create $name [list -eval $script] [concat [list -init] $args]] } # Mix safer [new] and [new-with] into every class Class instmixin SafeInit # Test: Class Foo -parameter { {animal horse} } Foo instproc init {arg1 arg2} { puts "Constructor args: $arg1 $arg2" } Foo instproc hello {} { puts jou } # We do not override [create] or the auto-create from [unknown]. Ie. # class creation still works and other stuff :-) puts "Should say 'jou':" Foo ob 1 2 -hello puts "Animal: [ob animal]" # Instantiate with -dash args set ob [Foo new -hellou world] puts "Animal: [$ob animal]" # Instantiate with some presets puts "Show say 'jou':" set ob [Foo new-with 1 2 { my hello my animal cat }] puts "Animal: [$ob animal]" -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

3 4

Re: [Xotcl] Very severe limitation in XOTcl
by SImon Millward 05 Aug '10

05 Aug '10

I agree there was a case for raising this. I'm sorry if I gave any other impression. ( I don't know why u raised this with me only and not the list? But I have) But, I don't think the case is a valid one, because you are finding difficulty with a dynamic language. Dynamic languages offer power. With power comes responsibility. Responsibility in my book equals things like comprehensive UT. If you don't test you fail.... please demonstrate another industry that doesn't consider testing an essential element of what they do? > 1) This particular one is a hobby project, and I don't really fancy spending my free time writing unit tests. I'm sorry to be contrary... but... if you are a hobbyist... should you really be commenting on the semantic or operational aspects of a language?.... if you are not writing unit tests then you are not behaving like a professional... if you are not, then why should a language implementation adhere to you? If you think that not being a professional excuses you from doing a good job then that is equally worrying.... UT is not a pro Vs hobbyist choice... its how one builds good software... QED... if u can't be bothered then what r u doing? I hate to bang the drum.. but I am tired of silly crap.... > 2) Unit tests, by their nature, don't cover everything. What if the unit tests never passed in a value beginning with "-"? Then they are crap unit tests (and probably crap code).. if failed to expect 'dirty' inputs.... I fail to see how someone who admits to not being professional can then create a justification for a language change..... I'm more surprised anyone's taking it seriously! Regards Simon On 4 Aug 2010, at 18:43, Kristoffer Lawson wrote: > > On 4 Aug 2010, at 19:50, SImon Millward wrote: > >> Isn't it fair to say that by design, any dynamic language has such possible traps and pitfalls... (although this one is especially awkward). You don't need to try very hard to make TCL fall over in all sorts of ways like this. > > Absolutely, dynamic languages do have these (and static languages do too, just in a different way). However I think for many things Tcl is probably reasonably OK. PHP is notorious for holes. > > But yes, this a particularly bad one because one normally assumes you can send variables as parameters to methods and constructors quite freely. It's common to be initialising with random pieces of string, for various purposes. It's obvious that something like [eval] or [after] is going to be dangerous. Perhaps even [switch] (although I think there'd be a case against that too). But creating a new ob with initial data passed as a variable? > >> The question I always ask my teams when something like this comes up is >> - Why didn't the unit tests catch it >> - What 'stock' unit test will we add in future to catch it > > 1) This particular one is a hobby project, and I don't really fancy spending my free time writing unit tests. > > 2) Unit tests, by their nature, don't cover everything. What if the unit tests never passed in a value beginning with "-"? > > The flipside to this, as mentioned, is that the resolution is actually quite ugly, and would need to be utilised for safety reasons almost every time a class is instantiated. I think there is definitely a case for raising some concern over this. > > -- > Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/ >

3 10

searchDefaults?
by Kristoffer Lawson 05 Aug '10

05 Aug '10

The reference manual for [create] specifies that it calls alloc, searchDefaults, configure and then init. However I find no mention of searchDefaults elsewhere in the manual, and it does not appear to be available, at least for 1.6. As I am experimenting with a replacement for [new] I would like to be able to pre-set the default values for parameters, upon class instantiation. Is this an oversight or am I looking in the wrong place? -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

1 0

Very severe limitation in XOTcl
by Kristoffer Lawson 04 Aug '10

04 Aug '10

This is really bad news, guys... % package require XOTcl 1.6.2 % namespace import xotcl::* % Class Foo ::Foo % Foo instproc init {a} {puts $a} % set a "-test" -test % Foo new $a ::xotcl::__#0: unable to dispatch method 'test' during '::xotcl::__#0 test' In other words: it is totally impossible to pass in a value beginning with "-" to an XOTcl constructor using the normal instantiation methods. This means absolutely anything where you don't know what is going to be passed beforehand is at a huge risk, as obviously any text can thus call random methods. That is without doing the whole process manually (ie. alloc, init). And you'd have to do it almost always, to be safe. Even if the usual Tcl "--" style was used, I still think that would not be enough, as practically speaking you'd have to use that every single time, making the code horribly ugly. It's just about acceptable for [switch], but not for a constructor, where people fully expect to be able to pass in any variable... Please tell me I'm dreaming (it's almost 4am here) -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

5 6

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 August 2010