Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

crash report
by vitick＠gmail.com 14 Oct '10

14 Oct '10

Don't know if the mailing list is the best place to post bug reports. Let me know the correct way to do it. On a clean 32 bit debian based system, fresh compilation of TCL 8.5.9 and XOTcl/Next, TCL will crash when calling "obj info has type" without arguments or with wrong arguments: nx::Class create C C create obj obj has type tclsh: ./generic/nsf.c:9853: IsSubType: Assertion `cl && subcl' failed.

3 3

XOTcl 2.0 and NX
by vitick＠gmail.com 08 Oct '10

08 Oct '10

Dear Gustaf, What is the reason for having XOTcl 2.0 and NX at the same time? In NX, method declaration is private by default where it seems to me that it is more natural for it to be public by default (since the majority method declarations will be public) and it is the private method that should be declared explicitly.

3 3

Re: [Xotcl] XOTcl 2.0 and NX
by Victor Mayevski 01 Oct '10

01 Oct '10

I will wait for the announcement to see the entire picture. I wish I participated in those 10+ years of discussions so I could understand things better. Time to catch up. I am sure that people coming from C++ or Java backgrounds will find NX more appealing. For me, even looking at code like "public void method" is painful. I like short, readable code. But, again, NX seems to be flexible enough to make all of us happy. May be it will even warm me up to C++ or Java, so I finally learn at least one of them. Not that I have too much time on my hands. :) Thank you. ----- Original Message ----- From: "Gustaf Neumann" <neumann(a)wu-wien.ac.at> To: xotcl(a)alice.wu-wien.ac.at Sent: Thursday, September 30, 2010 11:44:58 PM GMT -08:00 US/Canada Pacific Subject: Re: [Xotcl] XOTcl 2.0 and NX On 01.10.10 06:50, vitick(a)gmail.com wrote: > Dear Gustaf, > > What is the reason for having XOTcl 2.0 and NX at the same time? we will make a larger announcement in the near future explaining the background, relationships in detail. For now: we have a large XOTcl code base, for which it is unrealistic to switch to the new language in short time. Both, XOTcl 2.0 and our next scripting language are fully scripted (loaded via package require), so they are much easier to maintain. > In NX, method declaration is private by default where it seems to me that it is more natural for it to be public by default (since the majority method declarations will be public) and it is the private method that should be declared explicitly. many experiences and comments from 10+ years of xotcl were brought into the design of nx (e.g. issues about naming, large set of base methods, experiences from bug tracking, etc.). One experience from larger projects (more than 500.000 tcl/xotcl code, larger and changing programmer team) is that forcing developer to declare interfaces helps to improve comprehensibility for starters. btw, nx has a weak form of protection, one can call protected methods via "obj eval .....", but these should be reminders to provide a public interface for that functionality. Furthermore, the default protection can be changed from the scripting level. -gustaf neumann _______________________________________________ Xotcl mailing list Xotcl(a)alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

1 0

Compiling xotcl 1.6.6 on Visual Studio 2010
by Shedi Shedi 01 Oct '10

01 Oct '10

Hi, I'm trying to compile on vs 2010 and getting the following error nmake -f makefile.vc OPTS=threads TCLDIR=d:\tcl8.5.9 INSTALLDIR=c:\aolserver xotclshells Microsoft (R) Program Maintenance Utility Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. makefile.vc(344) : fatal error U1023: syntax error in expression Stop. Any ideas? TIA Shedis Shedis(a)gmail.com

1 0

new feature idea
by vitick＠gmail.com 01 Oct '10

01 Oct '10

It occurred to me that XOTcl could benefit or it's "coolness" value could be raised even more if it had method chaining similar to JQuery. Example: Class create Myclass Myclass :method a args { process {*}$args; } Myclass :method b args { process {*}$args; } Myclass create myobj execute: myobj :chain :a :b {value1 value2} or: myobj :chain :a :b :a :b :destroy {value1 value2} ################ syntax: obj :chain :method1 :method2 .... {arg1 arg2 ...} ################ functionality: each method would be executed in the order listed with the args provided in the end of the "chain" method. ################ This functionality is even more enhanced with mixins and superclasses where each chained method would be passed to a mixin/superclass via [next]. P.S. this is not really a feature request at the moment because I see you are very busy doing a lot of work on Next. And that has more priority. Also, the "chain" functionality can be easily done via scripting it myself. Again, for the "coolness" or "extra power" value, it would be nice to have that, in my opinion, as a built-in feature.

3 2

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

Problem with slots and moving objects
by Neil Hampton 28 Sep '10

28 Sep '10

I am having a problem/have found a bug with slots created with an -initcmd. If I set a value on an object containing a slot with an initcmd and then move it an error gets thrown every time I read the value. Class Fred -slots { Attribute a -initcmd { set _ 4 } } Fred x x a 4 x move y y a can't read "a": invalid command name "::x" Are there any simple work arounds for this other than having to write a method for 'a'? Neil Hampton www.rostrvm.com

3 2

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

← Newer
1
...
12
13
14
15
16
17
18
...
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