Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

NX object copy bug?
by Victor Mayevski 16 Dec '10

16 Dec '10

Hello Gustaf, When an object contains a setter, and if you do a copy of that object, the variable gets copied but the setter method is not copied. Object create o; o setter s; o s value; o s;# returns "value" o copy o1; o1 s; # error: unable to dispatch method 's' When I use "attribute" instead of "setter", it works fine.

1 0

nx: make failing on strnstr()
by Victor Mayevski 11 Dec '10

11 Dec '10

Hello Gustaf, ./generic/nsf.c: In function ‘ParamOptionParse’: ./generic/nsf.c:8281: warning: implicit declaration of function ‘strnstr’ ./generic/nsf.c:8281: warning: assignment makes pointer from integer without a cast ./generic/nsf.c: At top level: ./generic/nsfStack.c:1015: warning: ‘BeginOfCallChain’ defined but not used It seems that strnstr() function is new to Linux (as of January 2010) and is not present in many Linux libraries yet. May be you can substitute it with something else.

3 2

Error or normal behavior?
by Victor Mayevski 08 Dec '10

08 Dec '10

It came to my attention that [namespace import -force nx::*] is a requirement and not an option, otherwise things don't work right. Example: nx::Class create C C method init args {puts [self]; next} C create c #error, commands "self" and "next" do not exist, but if I first do [namespace import -force nx::*], everything works fine. This is not how I thought the namespaced commands should work. Is this a feature or a bug? If not a bug, then it needs to be clearly documented.

2 3

Latest compile error
by Victor Mayevski 08 Dec '10

08 Dec '10

Trying to compile the latest NX/XOTcl 2.0 against Tcl CVS Head: gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\" -DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1 -DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\" -DHAVE_TCL_COMPILE_H=1 -I"/root/TCL/tcl/generic" -I"/root/TCL/tcl/unix" -I./generic -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c `echo ./generic/nsfStubLib.c` -o nsfStubLib.o ./generic/nsfStubLib.c:40: error: conflicting types for ‘nsfStubsPtr’ ./generic/nsfDecls.h:262: note: previous declaration of ‘nsfStubsPtr’ was here ./generic/nsfStubLib.c:41: error: conflicting types for ‘nsfIntStubsPtr’ ./generic/nsfIntDecls.h:41: note: previous declaration of ‘nsfIntStubsPtr’ was here ./generic/nsfStubLib.c:43: error: conflicting types for ‘nsfStubsPtr’ ./generic/nsfDecls.h:262: note: previous declaration of ‘nsfStubsPtr’ was here ./generic/nsfStubLib.c:44: error: conflicting types for ‘nsfIntStubsPtr’ ./generic/nsfIntDecls.h:41: note: previous declaration of ‘nsfIntStubsPtr’ was here make: *** [nsfStubLib.o] Error 1

2 1

another error
by Victor Mayevski 28 Nov '10

28 Nov '10

Everything is now compiling and installing nicely, but I get another error when using NX or XOTcl 2.0: package req nx nx::Class create C C destroy can't read "__default_superclass": no such variable

2 1

Re: [Xotcl] troubleshooting
by vitick＠gmail.com 28 Nov '10

28 Nov '10

I have just installed the same 32bit ActiveState Windows version on Windows XP and TCL will also crash at [package req XOTcl]. So, this might be related to the specific build of ActiveState binary. ----- Original Message ----- From: "Gustaf Neumann" <neumann(a)wu-wien.ac.at> To: xotcl(a)alice.wu-wien.ac.at Sent: Thursday, October 14, 2010 12:29:00 AM GMT -08:00 US/Canada Pacific Subject: Re: [Xotcl] troubleshooting Dear Victor, many thanks for the short example! i have compiled xotcl 1.6.6 with my three test releases, the script runs fine in every version, also valgrind did not report unusual happenings, but i tried so far only with mac os x with 64bit. i am slightly confused about the activestate version number TCL 8.6.0.0b4. There was never a version of Tcl 8.6 b4 released (or tagged on sourceforge). As you wrote, the tcl_patchLevel is 8.6b1.2, which is the current HEAD release (and therefore a moving target). Apparently, activestate uses its own tags. Have you seen somewhere on activestate a source-release? -gustaf neumann On 14.10.10 08:21, Victor Mayevski wrote: > Thank you Gustaf, > I am using the ActiveState binary and XOTcl is version 1.6.6, not NX. I don't know where to get the source code for TCL 8.6.0.0b4, it is not available anywhere yet. > > I think I have zeroed in where the crash happens. Here is the sample code that causes the crash for me: > > tcl_patchLevel 8.6b1.2 > tcl_platform(byteOrder) = littleEndian > tcl_platform(machine) = x86_64 > tcl_platform(os) = Linux > tcl_platform(osVersion) = 2.6.35-22-generic > tcl_platform(pathSeparator) = : > tcl_platform(platform) = unix > tcl_platform(pointerSize) = 4 > tcl_platform(threaded) = 1 > tcl_platform(user) = root > tcl_platform(wordSize) = 4 > > #################################### > Object o > Object o::o > [o::o info parent] info children > > Segmentation fault > ##################################### > > I have also installed the 32bit version of the same ActiveState binary (the latest one, 8.6.0.0b4, tcl_patchLevel 8.6b1.2) and it will crash right at [package req XOTcl] > > Hope that helps > > > > > ----- Original Message ----- > From: "Gustaf Neumann"<neumann(a)wu-wien.ac.at> > To: xotcl(a)alice.wu-wien.ac.at > Sent: Wednesday, October 13, 2010 6:56:00 PM GMT -08:00 US/Canada Pacific > Subject: Re: [Xotcl] troubleshooting > > Hi Victor, > > our typical test setup is to run the regression test with > 8.5.9, tcl 8.6b1, > and with 8.6head version (where i have applied the > SANE-NRE-patch > from Miguel). i just double-checked, for me all three test > settings > work fine. > > does the regression work on your installation with tcl 8.6b4 > (run: make test)? > If they run fine, and you experience a crash with your > application, > the following works probably best: > > Strategy a: try to isolate and pinpoint the problem from the > tcl layer > by simplifying your script. if the problem can be > reproduced with > a few lines of code, send it to me. > > Strategy b: mostly for c-literate developers: use gdb. > > - compile tcl and nsf with -g enabled (e.g. add it to > the compile flags in the Makefile and recompile with > "make clean" and "make") > > - start the tcl shell under gdb, like e.g. > gdb /usr/local/src/tcl8.5.9/unix/tclsh > > - start your application from gdb using > run ..../yourapp.tcl > > - when it crashes, type in > where > an you will get the backtrace. > maybe what you see makes sense to you. > if not, send it to me, i'll try me best on it. > > all the best > -gustaf > > On 14.10.10 00:33, Victor Mayevski wrote: >> I have just tried my application on latest TCL 8.6b4 and it crashes (Segmentation fault). The same application works just fine in TCL 8.5.9. Any idea how I can troubleshoot it? Tools, techniques etc? >> >> Thank you >> _______________________________________________ >> 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 _______________________________________________ Xotcl mailing list Xotcl(a)alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

3 5

Re: [Xotcl] nested objects in nx
by Gustaf Neumann 29 Oct '10

29 Oct '10

Dear victor, There is a difference/asymmetry between "namespace path" and "namespace import" * "namespace import" creates cmd-stubs in the actual namespace (if issued on "::", in the top-level namespace). The default rule for function resolving checks the contents of the top-level namespace as a final resort. * "namespace path" adds a searchpath to the current namespace, but this is apparently not used as "final resort rule". Look at the following test script, which is pure tcl: - the namespace ::tst contains two procs, f-1 is namespace-imported to top, f-2 not (just namespace-pathed). - Both are seen by a toplevel "info command", both can be executed on top. - in the ::app-namespace, we have no namespace path. We can call f-1, but not f-2 =================================== namespace eval ::tst { proc f-1 {} { return f-1 } proc f-2 {} { return f-2 } namespace export f-1 f-2 } namespace path tst namespace import tst::f-1 puts f-1=[namespace which f-1] puts f-2=[namespace which f-2] puts "we see: [info command f-*]" namespace eval ::app { proc foo {} { puts [namespace current]//[namespace path] puts f-1=[namespace which f-1] puts f-2=[namespace which f-2] f-1 f-2 } } ::app::foo =================================== Exactly the same happens in "a::b tst", since "::a" is an object with object-specific methods and establishes a tcl namespace. % Object create a ::a % Object create a::b ::a::b % a public method tst args {puts [self]}; ::a::tst % a::b public method tst args {puts [self]}; ::a::b::tst % a tst ::a % a::b tst ::a::b % One could add a namespace path to "::a", but an application writer does most probably not like to do this. One could automatically mangle the default namespace paths (or use special resolvers) from nx/xotcl, but that could as well lead to surprising behavior.... Hope, this explains the observed behavior... -gustaf neumann PS: namespace path came already with tcl 8.5

1 0

nested objects in nx
by vitick＠gmail.com 28 Oct '10

28 Oct '10

I was reading the migration guide, and at the end it talk about the incompatibilities. I have specifically tested the "Calling objects like methods" and I do not understand it. It just doesn't work right. Example: Object create a; Object create a::b a public method tst args {puts [self]}; a::b public method tst args {puts [self]}; a tst; #works, returns ::a a::b tst; #error, invalid command self a::b eval self; #works, returns ::a::b Thanks

3 4

non positional argument
by vitick＠gmail.com 28 Oct '10

28 Oct '10

Is it possible to have a non-positional argument that is optional and its variable is only set when it is present as the argument to the method. Otherwise, it is ignored, no error. Basically, I want it behave like an option to the method but without specifying any value. Example: myobj method m {-test} { if {[info exists test]} { puts "test exists"; } else { puts "test does not exist"; } myobj m;#test does not exist myobj m -test;#test exists Or, it can even be a boolean, set to 1 if it was specified and set to 0 if not. That would be even better, shorter code. Thank you

3 2

Re: [Xotcl] troubleshooting
by Victor Mayevski 27 Oct '10

27 Oct '10

Thank you Gustaf, I am using the ActiveState binary and XOTcl is version 1.6.6, not NX. I don't know where to get the source code for TCL 8.6.0.0b4, it is not available anywhere yet. I think I have zeroed in where the crash happens. Here is the sample code that causes the crash for me: tcl_patchLevel 8.6b1.2 tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = x86_64 tcl_platform(os) = Linux tcl_platform(osVersion) = 2.6.35-22-generic tcl_platform(pathSeparator) = : tcl_platform(platform) = unix tcl_platform(pointerSize) = 4 tcl_platform(threaded) = 1 tcl_platform(user) = root tcl_platform(wordSize) = 4 #################################### Object o Object o::o [o::o info parent] info children Segmentation fault ##################################### I have also installed the 32bit version of the same ActiveState binary (the latest one, 8.6.0.0b4, tcl_patchLevel 8.6b1.2) and it will crash right at [package req XOTcl] Hope that helps ----- Original Message ----- From: "Gustaf Neumann" <neumann(a)wu-wien.ac.at> To: xotcl(a)alice.wu-wien.ac.at Sent: Wednesday, October 13, 2010 6:56:00 PM GMT -08:00 US/Canada Pacific Subject: Re: [Xotcl] troubleshooting Hi Victor, our typical test setup is to run the regression test with 8.5.9, tcl 8.6b1, and with 8.6head version (where i have applied the SANE-NRE-patch from Miguel). i just double-checked, for me all three test settings work fine. does the regression work on your installation with tcl 8.6b4 (run: make test)? If they run fine, and you experience a crash with your application, the following works probably best: Strategy a: try to isolate and pinpoint the problem from the tcl layer by simplifying your script. if the problem can be reproduced with a few lines of code, send it to me. Strategy b: mostly for c-literate developers: use gdb. - compile tcl and nsf with -g enabled (e.g. add it to the compile flags in the Makefile and recompile with "make clean" and "make") - start the tcl shell under gdb, like e.g. gdb /usr/local/src/tcl8.5.9/unix/tclsh - start your application from gdb using run ..../yourapp.tcl - when it crashes, type in where an you will get the backtrace. maybe what you see makes sense to you. if not, send it to me, i'll try me best on it. all the best -gustaf On 14.10.10 00:33, Victor Mayevski wrote: > I have just tried my application on latest TCL 8.6b4 and it crashes (Segmentation fault). The same application works just fine in TCL 8.5.9. Any idea how I can troubleshoot it? Tools, techniques etc? > > Thank you > _______________________________________________ > 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

3 6

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