Xotcl October 2010

xotcl@alice.wu.ac.at

4 participants
11 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

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

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

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