Weblog Page

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 8 Jan 2003 16:12:34 +0100

Hi Adrian,

you're right. The orginal idea was to provide one XOTcl version that is only
XOTcl (the xotcl-1.0.1) on its own and own "full" version with the actiweb
packages etc. especially for students and testing purposes; so someone not
using actiweb does not have to install all the persistence, xml, web object,
etc. stuff just ot use XOTcl; however, since then (to my knowledge) nobody
uses the smaller xotcl-only version. We're thinking about removing the
version number again. I guess, we try to move to the TEA2 directory naming
scheme ....

For you immediate problem: in the makefiles there are variables "PATCHLEVEL"
(this is the release level ... "" for 1.0, ".1" for 1.0.1) and FULLVERSION
defined, which contain the necessary information. Within XOTcl you can get
the patchlevel with "set xotcl:patchlevel":

xotclsh
% set xotcl::patchlevel
.1

--uwe




On Wednesday 08 January 2003 16:37, Adrian Wallaschek wrote:
> Hi there!
>
> I do like version numbers, but there is a "too much" in everything.
>
> What is the deeper benefit of having the version number for xotcl
> recursively even inside the source-tree?
>
> What actually happens for me is that now I seem to have problems building
> the code because in 1.0.1
> When running xotcl-1.0.1/xotclsh I do find ..../xotcl-1.0 in the auto_path
> instead of the required/expected .../xotcl-1.0.1.
>
> I haven't yet found out where it goes wrong but it looks like the $VERSION
> doesn't use the revision counter in some Makefile.
>
> The question is: why all this fuzz?
>
> Didn't anybody else see this occurring, did I mess up anything?
>
>
> Regards,
> Adrian Wallaschek
>
> "Just when you think, life can't possible get worse,
> it suddenly does!"
> The Hitchhiker's guide to the galaxy - Douglas Adams
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 6 Jul 2001 00:50:04 +0200

Dear Catherine,
here comes a quick fix for this.
search for

FilterDispatch(Tcl_Interp* in, XOTclObject* obj, int objc, Tcl_Obj* CONST
objv[]) {

in xotcl.c and replace towards the end of this procedure

 if (result != TCL_OK)
   result = TCL_ERROR
 return result;
}

by
  if (result >= XOTCL_UNKNOWN)
    result = TCL_ERROR;
    return result;
}

If you have a problem with this, i can place a patched version
of 0.85 on our webserver

best regards
-gustaf
 

From: Kristen Eisenberg <kristen.eisenberg_at_yahoo.com>
Date: Sat, 22 Oct 2011 13:00:00 -0700 (PDT)

Hello Gustaf, I am using the latest Tcl 8.6 from SourceForge and latest NX on 32bit Linux. I am experiencing a pretty bad memory leak when using NX objects with attributes. Example code: time {Object create o; o attribute "[clock clicks] [clock clicks]";o destroy} 1000000 Within like 3 minutes the memory usage grows to around 300meg. Kristen Eisenberg Billige Flüge Marketing GmbH Emanuelstr. 3, 10317 Berlin Deutschland Telefon: +49 (33) 5310967 Email: utebachmeier at gmail.com Site: http://flug.airego.de
- Billige Flüge vergleichen

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Tue, 27 Jul 2004 14:54:29 -0400

> -----Original Message-----
> From: Aamer Akhter [mailto:aakhter_at_gmail.com]
> Sent: Tuesday, July 27, 2004 1:44 PM
> To: Schofield, Bryan (GE Transportation)
> Cc: xotcl_at_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

From: Kevin Van Workum <vanw_at_sabalcore.com>
Date: Wed, 11 Aug 2010 13:51:29 -0400

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
_at_ 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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Thu, 1 Apr 2004 18:02:36 +0200

Am Mittwoch, 31. März 2004 19:35 schrieb Alexandre Dehne:
> Hello,
>
> In order to use biok, I have to install xotcl. My problem with xotcl
> installation is that my system is under Fedora and there is no tclInt.h
> file under this distribution (even with the tcl-devel package). Of
> course, I can uninstall the tcl package and install tcl manually but, by
> uninstalling tcl package, other packages are going out and that put me
> in trouble ...
>
> Any suggestion on the way to manage my tclInt.h problem ?
> Does anyone have an rpm for fedora ?
>
> Thanks in advance
> Alexandre
>
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

I know this problem from old RedHat
The fastest solution is to get the source (watch proper Tcl Version) from
http://sourceforge.net/projects/tcl/
unpack (untar) the sources.
copy tclInt.h and tclIntDecls.h (I think it is enough) from generic directory
into directory there
tcl.h ist (I suppose /usr/include)
You should compile it without problems.

It is also possible (and easier) to include tclInt.h path by setting
env-variable.
It this example the is tcl8.3.3 unpacked

export C_INCLUDE_PATH=~/tcl8.3.3/generic
./configure --with-tcl=/usr/lib --with-tk=/usr/lib
make

If fedora still use 8.3 I suggest to build new tcl/tk 8.4.6 by yourself.
It is not so difficult.

Artur Trzewik

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 2 Jan 2008 19:39:01 +0200

On 2 Jan 2008, at 12:51, Eckhard Lehmann wrote:
>
> I see that there is no need for another interception technique, but
> it would be really helpful to have the current filter techiques
> also applied to ordinary Tcl code inside methods.

Why not just use the Tcl [trace] command for the normal Tcl commands?

            / http://www.scred.com/
            / http://www.fishpool.com/~setok/

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 10:20:38 +0300

On 5 Aug 2010, at 02:05, SImon Millward wrote:

> 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)

My mistake :-) Not hitting the "Reply to All"...

> 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?

I think we're entering a totally unrelated debate here. For what it's worth, I've been using dynamic languages for over 15 years (Tcl in particular), so it's not like they're something totally new to me. This particular problem does not, for instance, exist in Python, whereas PHP is riddled with many (and, in practical situations, has often caused problems for people). I'd say the basic rule should be that common usage with argument passing should be safe. It should not be necessary to do every single instantiation like this:

set ob [MyClass new [list -init arg1 arg2 arg3]]

This makes common use awkward and something that will easily trip up users. Consider that in an OO environment, object instantiation is one of the things you will be doing a lot of. Keep in mind you have to do the above every time, just to avoid mistakingly sending something which will cause a crash or a hole. It seems Gustav agrees, as he pointed out this will not be the case in 2.0.

>> 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?

Uhm.. Yes? I didn't realise this community was closed off to hobbyists. I imagine many people using Tcl or XOTcl fit that bill. Naturally it's the right of the authors to implement their language however they feel — it's lot like I'll bring them to court (plus I've enjoyed beers with one of them :-) — but it is also my right not to be happy about a particular implementation.

>> 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....

Well, I raise my cap if your unit tests are always 100% great, with 100% coverage of all possible values and you have code without bugs. We should probably hire you.

> 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!

I'm talking about common sense here. A feature of the language makes it awkward to write safe code, and leads to error prone results. For something so basic as object instantiation, requiring awkward syntax is just not going to go down well with many coders. It reduces readability and, in fact, none of the XOTcl examples you see use the safe instantiation model.

There are a few gotchas like this in Tcl. [switch] is dangerous, but the "--" pattern is well established (although I'm not a big fan of that). [puts] is something I imagine most code has got wrong, but the consequences are generally not particularly dangerous. At the end of the day programming languages are for humans, and need to consider that as a factor.

I don't know why I'm ruffling your feathers so much. It's true my initial posting on this was filled with late night "Argh", but I stand by the point. Also, I've been using on and off XOTcl since the 0.8x days and have always been a fan of the language. I've done my part to evangelise it. That it has taken this long to stumble across this issue is exactly why it is particularly dangerous.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 18 Feb 2006 21:14:46 +0100

Fellow xotclers,

i am glad to annouce the availablity of xotcl 1.4.0. The major
changes against 1.3.9 are:

    * Improved Functionality
      * new option: ::xotcl::configure softrecreate on|off
         if softrecreate is set, class relations (superclass, subclass,
class, instances)
         are not affected by a recreate; this allows files with class
definitions
         more easily to reload
       + easier syntax for providing commands for initializing default
values
       + setting and querying options for ::xotcl::configure simiar to set

     * Improved Code Quality:
       + fixed a bug in connection with nonpositional arguments and "args"
       + fixed a bug with adding on the fly transitive mixin classes
       + fixed a bug with filter states after next
       + fixed omitted error message after calling self with unknown
subcommands
       + fixed a bug with variable traces on thread exit (triggered by
volatile)
       + fixed incorrect rpm dependencies
       + cleaner compile for xotcl for gcc 4.* under linux
       + don't destroy namespace imported child objects
       + info children returns true children, not namespace imported
objects/classes
       + unsetting the global variable "cmd" from predefined.xotcl
       + Upgraded TEA to 3.5
       + more regression tests addeed

 For more details about the changes, please consult the ChangeLog and
 documentation on www.xotcl.org.

The window binaries will follow soon.

all the best
-gustaf neumann

From: Attilio Dona <attilio.dona_at_telecomitalia.it>
Date: Tue, 23 Mar 2004 13:20:55 +0100

Hi,

I am newer of XOTcl and I am evaluating the language for using it
instead of Itcl in the new version
of a large OSS Telecommunication sw project ranging from SDH/PDH, ip,atm
and application level management.

XOTcl builded successfully on HP-UX 11 and SunSolaris 8 and was
integrated easily it into a starkit.

My preliminary tests reveal this bug:

# define a C class with a name
Class C -parameter {{name ""}}

# add a new parameter
C parameter {{oid ""}}

# now inspect the parameters
C info parameter
{oid ""}

Whereas it would be:
{name ""} {oid ""}


Best Regards
Attilio





--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster_at_telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------