Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

Question on [eval] method
by Kristoffer Lawson 06 Sep '04

06 Sep '04

It states that object-local variables are accessible as normal Tcl variables inside the script, but what about methods? I noticed the following: % package require XOTcl 1.1 ::ob % ob proc pomous {} {puts pomous} % ob eval pomous pomous % xotcl::Class JOu ::JOu % JOu instproc uoah {} {puts jeah} % JOu ob ::ob % ob eval uoah invalid command name "uoah" Is that guaranteed to work at all? Is there any proper way to get what I want to do? The reason I'm doing this is because I'm implementing a type of binary reading command which looks something like this: buynary::scan $clusterDat { option endian little format { object root { short objNum short $objNum objIDs } object * children { short 3 cellID short addObjNum short $addObjNum addObjIDs short rmObjNum short $rmObjNum rmObjIDs } } } It uses XOTcl to build a representation of the binary data as objects. I made a version which parses the format manually, but for performance reasons I'd like Tcl to do that. Ie. to have, in a particular context, commands such as 'format', 'short', 'object' etc. Then I could just [eval] the whole nonsense and get all the performance benefits that has to offer. One could always do this using namespaces, but that would be really annoying as I've started off with XOTcl for this. / http://www.fishpool.com/~setok/

2 2

Compilation with free VC++
by michael.heca＠email.cz 03 Sep '04

03 Sep '04

Start from http://wiki.tcl.tk/11431 Use modified config.vc. Please add $(INSTALLDIR) to $(TCLSH) .\installWin.tcl call in Makefile.vc Michael Heca

1 0

alloc error
by michael.heca＠email.cz 02 Sep '04

02 Sep '04

Hi, I found error in running XOTclIDE with new xotcl from version 1.3.0. Error is raised by similar code: --------------------------------------------- #!/usr/bin/tclsh package require XOTcl namespace import ::xotcl::* Class NS Class NS::Main NS::Main proc m1 {} { my m2 } NS::Main proc m2 {} { namespace eval :: Object crash } NS::Main m1 --------------------------------------------- Error is: --------------------------------------------- couldn't find result of alloc ::xotcl::Object ::xotcl::Class->create ::xotcl::Object ::xotcl::Class->unknown invoked from within "Object crash" (in namespace eval "::" script line 1) invoked from within "namespace eval :: Object crash" (procedure "m2" line 3) ::NS::Main->m2 invoked from within "my m2" (procedure "m1" line 3) ::NS::Main->m1 invoked from within "NS::Main m1" (file "T:\home\heca\test\xotcl\e130.tcl" line 18) --------------------------------------------- If i directly call NS::Main m2, everything is ok. It is xotcl error or problem is in this code? Michael Heca

2 1

Announce of 1.3.1
by Gustaf Neumann 26 Aug '04

26 Aug '04

Dear XOTcl Community, This is a minor fix release relative to 1.3.0. This release fixes a few problems introduced in 1.3.0 (invocation of checking procs in nonpositional argument) and has a better build support for building XOTcl outside of the source tree, the tar files are now dist-cleaned. Best regards, Gustaf Neumann Uwe Zdun -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

1 0

Use of TclGetInterpProc
by Neil Madden 26 Aug '04

26 Aug '04

Hi all, I've just been compiling XOTcl 1.3.0 on Mac OS X against the latest (as of about an hour ago) CVS HEAD versions of Tcl and Tk. It initially failed on the final linking stages, missing the TclGetInterpProc function. This function has been taken out of Tcl in CVS. Commenting out the 1 reference to this function in the XOTcl sources (generic/xotcl.c line 10461) allows the compile to finish, all the tests pass and the resulting library seems fine. Talking to Donald Porter on the Tcl'ers Chat indicates that use of this function should no longer be necessary as Tcl doesn't create any procs using the old string-based interfaces anymore. Just thought I'd send out a heads-up, as you probably want to fix/alter the XOTcl code to deal with this. Cheers, Neil.

2 1

XOTcl 1.3.0 available
by Gustaf Neumann 19 Aug '04

19 Aug '04

Dear XOTcl Community, i am proud to announce the availability of XOTcl 1.3.0. Major changes relative to 1.2.0 are: - Qualitative Improvements * Improved portability: + TEA3 compatible build + Much more polished configure+makefile (many thanks to Jim Lynch for his help) * Improved code quality: + fixed 2 possible segmentation violations (error handling) + fixed free memory reads (many thanks to Zoran Vasiljevic for his help with purify) * Less intrusive usage of XOTcl components: + XOTcl procs and instprocs use now the namespace in which they were defined. One can use XOTcl packages without having the need to import xotcl globally or to use the xotcl-prefix in all xotcl procs/instprocs. - Functional Improvements * New forwarding mechanisms for fast delegation: new methods 'forward' and 'instforward' (many thanks to Bryan Schofield for fruitful discussions and suggestions). This method is a superset of tclcmd/insttclcmd, which has been marked as deprecated. See the tutorial for more details. * Nonpositional arguments for xotcl procs/instprocs; this is a flexible way to check arguments, to provide defaults etc for every xotcl proc/instproc. It uses a similar syntax as ad_proc and ad_page_contract in OACS. See the tutorial for more details. * Extended methods filter, mixin, instfilter, instmixin as discussed in the XOTcl mailing list. These commands can be used more flexibly as follows obj mixin same as: obj info mixin obj mixin {C1 C2} same as: obj mixin set {C1 C2} obj mixin set {C1 C2} sets the mixins for obj obj mixin get same as: obj info mixin obj mixin add C3 adds a mixin on front of the mixin list obj mixin add C3 end adds a mixin at the end the mixin list obj mixin add C3 3 adds a mixin at the 3rd position obj mixin delete ::C3 removes the mixin from the mixin list The same semantics are available as well for filter, instmixin and instfilter. This change is fully backward compatible. {filter,instfilter,mixin,instmixin}append are deprecated now. For more details about the changes, please consult the ChangeLog and documentation. 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 -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

4 6

small glitch in serializer
by Gustaf Neumann 18 Aug '04

18 Aug '04

Dear XOTcl community, i just fixed a small glitch in the serializer code (one can never have enough regression tests :(). most likely, only aolserver users will be affected. please refetch 1.3.0 from the server, if you have already got a copy of 1.3.0 -gustaf -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

1 0

RE: Private methods (was [Xotcl] build problem on solaris)
by Schofield, Bryan (GE Transportation) 28 Jul '04

28 Jul '04

> -----Original Message----- > From: Aamer Akhter [mailto:aakhter@gmail.com] > Sent: Tuesday, July 27, 2004 1:44 PM > To: Schofield, Bryan (GE Transportation) > Cc: xotcl(a)alice.wu-wien.ac.at > Subject: Re: [Xotcl] build problem on solaris [snip snip snip] > > One thing that popped into my mind was > how to do private variables and methods (i think this can be done via > the filters, but i haven't exactly figured them out yet) > > Thank-you to the developers for maintianing xotcl. Here is a quick hack example showing how to privatize a method. The instproc "priv" simply registers a method name to be considered private. Then a filter checks to see if the a method being called from somewhere outside of the object has been registered; If so, it throws. There is a lot of refinement that could be done, but at least this shows how a filter could be used to provide levels of protection. Making variables private is a little trickier. That might require the overloading variable mutators like "set", "lappend", "append" & so on. But one could make all thoses method private and then you've essentially made all variable private. Then use "parameters" for publicly accessible data, which is probably better any way since you are not allowing outsiders to directly change a variable, but rather providing them an interface to get & set the value of some piece of data. -- bryan --- package require XOTcl namespace import ::xotcl::* Class Foo Foo instproc init {args} { my array set priv {} my priv bar } Foo instproc bar {} { puts "[self] BAR!" } Foo instproc ack {} { my bar puts "[self] ACK!" } Foo instproc priv {method} { my set priv($method) 1 } Foo instproc checkAccess {args} { puts "check access [self] [self calledproc] called from [self callingproc]" if {[my exists priv([self calledproc])] && ([self callingproc] eq "")} { return -code error "[self calledproc] is private" } next } Foo instfilter checkAccess Foo f f ack # This next line will generate an error. f bar

2 1

RE: [Xotcl] build problem on solaris
by Schofield, Bryan (GE Transportation) 27 Jul '04

27 Jul '04

I had that problem at as well. I didn't care to make xowish or xotclsh, I ended up commenting portions of the make file out to get it to work. Specifically, I commented out "binaries", "install", and part of "libraries" target. I don't mean to speak for Gustaf, but maybe give this version a try: http://media.wu-wien.ac.at/download/xotcl-1.2.1.tar.gz I don't think it's quite ready for primetime, since Gustaf & Co. are adding a few enhancements. But I think all that remains is documentation. I've been using it & testing out the new features for a about 2 months and consider it stable. That version also has a better build & configuration system and compiles with out complaint fine for me (which is the only reason I'm mentioning it, it was a painful to get the last publicly released version to compile on Solaris). I'm sure the XOTcl guys will correct me if I'm wrong. I noticed you posted a question on the IncrTcl mailing list earlier today about "unknown" handlers. I think you'll find that XOTcl's unknown handler is fantastic. I've used IncrTcl extensively, but over the last 6 months or so I've began using XOTcl instead. I now prefer XOTcl greatly to IncrTcl. After using it, I feel so constrained with IncrTcl by having to fully define my classes, and thus my object behavior, a head of time. The flexibility of XOTcl is phenomenal. -- bryan > -----Original Message----- > From: xotcl-admin(a)alice.wu-wien.ac.at > [mailto:xotcl-admin@alice.wu-wien.ac.at]On Behalf Of Aamer Akhter > Sent: Tuesday, July 27, 2004 12:42 PM > To: xotcl(a)alice.wu-wien.ac.at > Subject: [Xotcl] build problem on solaris > > > Folks, > > I'm having a a makefile problem on solaris (the linux build went fine) > > gcc -pipe -shared -o libxotcl1.2.so so/xotcl.o so/xotclError.o > so/xotclMetaData.o so/xotclObjectData.o so/xotclProfile.o > so/xotclTrace.o so/xotclUtil.o so/xotclShadow.o so/xotclCompile.o > so/aolstub.o so/xotclStubInit.o > -L/auto/nsite-mmpls/users/aakhter/ats4.0/lib -ltclstub8.4 > : libxotcl1.2.so > /bin/bash: -c: line 1: syntax error near unexpected token `;' > /bin/bash: -c: line 1: `if test ! "x" = "x" ; then for dir in ; do > if (cd $dir; make binaries) ; then true ; else exit 1 ; fi ; done; > fi;' > > which is (with make -d): > > Finished prerequisites of target file `binaries'. > Must remake target `binaries'. > Putting child 0x00068080 (binaries) PID 17840 on the chain. > Live child 0x00068080 (binaries) PID 17840 > /bin/bash: -c: line 1: syntax error near unexpected token `;' > /bin/bash: -c: line 1: `if test ! "x" = "x" ; then for dir in ; do > if (cd $dir; make binaries) ; then true ; else exit 1 ; fi ; done; > fi;' > > makefile: > > binaries: $(BINARIES) $(XOTCLSH) $(XOWISH) pkgIndex.tcl > @if test ! "x$(subdirs)" = "x" ; then \ > for dir in $(subdirs) ; do \ > if (cd $$dir; $(MAKE) $@) ; then true ; else exit 1 ; fi ; \ > done; fi; > > > has anybody run into this problem already? > > -- > Aamer Akhter / aakhter(a)gmail.com > _______________________________________________ > Xotcl mailing list - Xotcl(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl >

2 1

build problem on solaris
by Aamer Akhter 27 Jul '04

27 Jul '04

Folks, I'm having a a makefile problem on solaris (the linux build went fine) gcc -pipe -shared -o libxotcl1.2.so so/xotcl.o so/xotclError.o so/xotclMetaData.o so/xotclObjectData.o so/xotclProfile.o so/xotclTrace.o so/xotclUtil.o so/xotclShadow.o so/xotclCompile.o so/aolstub.o so/xotclStubInit.o -L/auto/nsite-mmpls/users/aakhter/ats4.0/lib -ltclstub8.4 : libxotcl1.2.so /bin/bash: -c: line 1: syntax error near unexpected token `;' /bin/bash: -c: line 1: `if test ! "x" = "x" ; then for dir in ; do if (cd $dir; make binaries) ; then true ; else exit 1 ; fi ; done; fi;' which is (with make -d): Finished prerequisites of target file `binaries'. Must remake target `binaries'. Putting child 0x00068080 (binaries) PID 17840 on the chain. Live child 0x00068080 (binaries) PID 17840 /bin/bash: -c: line 1: syntax error near unexpected token `;' /bin/bash: -c: line 1: `if test ! "x" = "x" ; then for dir in ; do if (cd $dir; make binaries) ; then true ; else exit 1 ; fi ; done; fi;' makefile: binaries: $(BINARIES) $(XOTCLSH) $(XOWISH) pkgIndex.tcl @if test ! "x$(subdirs)" = "x" ; then \ for dir in $(subdirs) ; do \ if (cd $$dir; $(MAKE) $@) ; then true ; else exit 1 ; fi ; \ done; fi; has anybody run into this problem already? -- Aamer Akhter / aakhter(a)gmail.com

1 0

← Newer
1
...
38
39
40
41
42
43
44
...
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