View · Search · Index
No registered users in community xowiki
in last 10 minutes

Weblog Page

Showing 301 - 310 of 1561 Postings (summary)

[Xotcl] re: problem when having both a filter and a Tk callback returning a break

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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
 

[Xotcl] NX memory leak

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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

RE: Private methods (was [Xotcl] build problem on solaris)

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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

[Xotcl] replacing libtcl

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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

Re: [Xotcl] installation on fedora

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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

Re: [Xotcl] full trace support for XOTcl methods/procs

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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/

Re: [Xotcl] Very severe limitation in XOTcl

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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/

[Xotcl] XOTcl 1.4.0 available

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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

[Xotcl] xotcl 1.2: info parameter problem

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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

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

RE: [Xotcl] Re: Bug: configure step chooses wrong tclsh [REASONING]

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 12 Apr 2004 17:58:10 -0700

> i looked into http://sourceforge.net/projects/incrtcl, which
> contains itcl3.2.1, which uses still the SC_* macros (i got
> there by clicking on project "incrtcl" on
> http://www.tcl.tk/software/tcltk/netcvs.html).
>
> i have checked out the version from there, it uses TEA_* macros.
> jeff, is this TEA2 or TEA3? i got as well tcl.m4 from cvs
> tcl/tclconfig, which appears to be more recent. in both
> files, i find not hint whether this is based on TEA2 or TEA3.

itcl 3.2 used TEA1 (which was SC_* macros). The itcl in CVS
uses TEA2 (which is TEA_* macros, but unversioned). You should
see that the tcl/tclconfig (and related tcl/sampleextension)
is TEA3 - it includes a specific TEA_INIT([<VERSION>]) in it
(to alleviate more version confusion in the future).

> Where is TEA3 documented? Is there a better documentation
> than the comments of the macros?

It's all the comments in the sample extension and in the macros
at this point unfortunately. If you've used TEA before, then
it should be easy to move over. One of these years I'll get
some time to document this better, but that's not going to
happen soon. :/

Jeff

Next Page