Weblog Page

From: Zoran Vasiljevic <zv_at_archiware.com>
Date: Fri, 30 Sep 2005 20:30:35 +0200

Am 30.09.2005 um 20:15 schrieb Jeff Hobbs:

> We have
> a copy that I have used many times. Valgrind comes close,
> finds different things, but I still prefer Purify. Valgrind
> is free though, so there's not excuse not to try that.

Unfortunately (as you already know) ...
Those will not report regular memory usage (C-wise) when
you just expand an array, extend the list, flood the event
loop, forget to destoy objects, etc. pp., indefinitetly.
Hence, I found the Poor Man's Purify ([time] + glancing at
the top display) equaly useful.

What I believe, (under assumption that Ben is using only
Tcl/XOTcl code) is that he's hitting something like the
above. I had those problems en mass until I persuaded
Gustaf to make the "-volatile" mechanism in XOTcl...

Zoran

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sat, 21 Jul 2007 11:31:41 +0100

> I bring bad news. I am receiving seg faults and bus errors while
> running XOTcl code. I am running XOTcl 1.5.3 and Tcl 8.4 on both
> Linux x86 and OS X PPC. I received the errors randomly on both
> platforms. This started occuring when I reloaded the source code. At
> first I thought it was related to Tcl packaging, but I mostly removed
> calls to package require and package forget. Currently I just use
> source to load most files. I am writing code generation libraries
> and using Object eval so I may be doing new things with XOTcl. How
> should I go about debugging these seg faults? Are core dumps useful?
> I'll try to write a script that reproduces the problem, but I
> haven't really narrowed the problem down yet.
>
> Any help is much appreciated.
>
> Thanks,
>
> Ben
> _______________________________________________
>
Hello Ben!

I have also very seldom some segmentation faults with Tcl/XOTcl (and
many another extensions).
I have noticed, that it can occurs when I am debugging and changing code
(by using XOTclIDE).
So it is similar to your scenario.
It can occurs by me when I suspend processing of one method (with tkwait
- used internally by debugger)
and from another event handler (beginned from Tk -command) I manipulate
some objects.
The program have problems when I try to fire tkwait variable (resume the
debugger).
So I suppose you should not reload the package by itself.

The best method to have a bug fix is to write some short script that
always reproduces the error.
I have not a success to write it yet. Even if I try to reproduce the
same debugging session it does not occurs.
Because the error is very seldom it is not possible to fix it without
this script.

Artur

From: Kevin Van Workum <vanw_at_sabalcore.com>
Date: Wed, 11 Aug 2010 15:55:02 -0400

On Wed, Aug 11, 2010 at 3:11 PM, Jeff Hobbs <jeffh_at_activestate.com> wrote:

> On 11/08/2010 10:51 AM, Kevin Van Workum wrote:
>
>> 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?
>>
>
> It sounds like you are trying to use libtcl.so (or equivalient) in your
> setup. It is possible to make use of extensions if you initialize
> everything correctly. It is also possible to build special-purpose DLLs
> that can actually include other extensions added, called stardlls. See
> http://wiki.tcl.tk/15969 for more. This enhanced setup provides a lot of
> flexibility for embedders.
>
> Jeff
>


Replacing "Tcl_Init()" with "Xotcl_Init()" in my C code, and then linking to
libxotcl1.6.6.so seems to have worked. Pretty simple.

-- 
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: <MichaelL_at_frogware.com>
Date: Mon, 12 May 2003 13:30:39 -0400

I must admit that I was only thinking about elegance, and hadn't thought
about memory and performance implications.

One option, I suppose, is to use a flyweight approach. In other words,
pass the list in as a parameter to some function/object. This is roughly
analogous to using the existing list commands in pure Tcl. The difference
is simply that it would be possible to add a number of convenience
functions in an XOTcl implementation. For example, Tcl doesn't have a
simple "add only if it isn't there" command or a simple "copy list"
command (you use lrange with specific arguments) or a simple "delete
element" command (you use lreplace with specific arguments). Such an
approach would only be a small improvement, but maybe it would be enough.
It would certainly be easier than a full implementation of lightweigt
objects. :-)

You do, however, hint that there may be plans for ongoing development. Are
there specific plans, or just a general interest is evolving it "somehow"?

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 05/12/2003 12:39:44 PM:

> On Monday 12 May 2003 17:36, Uwe Zdun wrote:
> > This corresponds to the idea of making filters etc themselves objects.
> > I like this idea from a conceptual point of view. Implementation-wise
> > it could be a larger undertaking ... the problem is that these
> > "collections" manage different things at the C-code level (Tcl_Obj*s,
Cmds,
> > etc) in lists and hashtables and that some parts are not under control
of
> > XOTcl's C code (children are managed by Tcl in Namespaces). So really
a 2.0
> > issue :)
>
> same opinon here; we had already some discussion some time ago about
> transforming e.g. methods into objects, etc. We did a big step in
> this direction when
> we implemented our "light-weight objects", which require namespaces
> etc on demand (please note, that lightweight is relative; see also
> http://media.wu-wien.ac.at/download/mem.log). But still, objects
> are costly in terms of time and memory.
>
> I am pondering since a while about a simple thing: transforming
> xotcl parameters into objects. Conceptually, this is quite simple, but
> has disadvantages from benchmarks etc, whenmultiple objects are created
> on the fly, in situations where the users expects one class/object
> to be created.
> Maybe we are able to provide object facades, or to create these
interface
> objects on demand, while keeping low-fat memory strucutures....... but
this
> will take a few releases...
>
> greetings
> -gustaf
>
> --
> Univ.Prof. Dr.Gustaf Neumann
> Abteilung für Wirtschaftsinformatik
> WU-Wien, Augasse 2-6, 1090 Wien

From: Marc Spitzer <mspitze1_at_optonline.net>
Date: Sat, 29 Nov 2003 20:42:02 -0500

I have attached a log of my build, just incase I am missing something.
The --with-tkinclude=/usr/local/include/tk8.4/generic from configure does not seem to be getting to the CC line as a -I directive:

cc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DVERSION=\"1.1\" -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_UNISTD_H=1 -DCOMPILE_XOTCL_STUBS=1 -DTCL_SHLIB_EXT=\".so\" -I/usr/ports/lang/tcl84/work/tcl8.4.4/generic -I/usr/ports/lang/tcl84/work/tcl8.4.4/unix -I"./../generic" -I"./../unix" -I/usr/local/include/tcl8.4/generic -O -fPIC -g -DXOTCLVERSION=\"1.1\" -DXOTCLPATCHLEVEL=\".0\" -c `echo ../unix/tkAppInit.c` -o o/tkAppInit.o
../unix/tkAppInit.c:19: tk.h: No such file or directory
gmake: *** [o/tkAppInit.o] Error 1

Thanks

marc

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 5 Sep 2005 13:02:48 +0300

On 5 Sep 2005, at 12:14, Gustaf Neumann wrote:

>> (3) Is there any way to represent relationship across two classes?
>> For example, Class A is related to Class B with one-to-many
>> relationship.
>>
>
> a few class/class relations and object/class relations are
> maintained by xotcl (e.g. superclass,
> class, mixins). A start point might be ::xotcl::Relations, which
> is used to implement a
> uniform interface to mixins (and instmixins ...), which allows to
> specify "... mixin add ...", #
> "... mixin delete ...", "... mixin set ...", etc. In principle,
> the same interface could be used
> for application level relations as well...
>
> In current applications, the classes use and maintain a list of
> related object/classes.
> Often, it is conveniant to use aggregations to express 1:1 or 1:n
> relationships.

I was thinking about using packages to collect classes together. The
problem with this is that classes are not automatically searched for
in the same package. That is if Class A depends on Class B (A is B's
sub-class), B needs to be read in before A is read. In Java it is
enough that they are in the same package, they'll be found. With
XOTcl you need to build a kind of stub file that represents the
package and which then sources in all the other necessary files in
the required order.

Whether this helps or not, I don't know...

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 11 Apr 2004 12:56:14 +0200

On Sunday 11 April 2004 07:24, Jim Lynch wrote:
> > well. by using --with-aolserver3 you tell xotcl, that it should build
> > the aolserver 3.* type c module, and you tell it at the same time, where
> > to find the includes. therefor i think --with-aolserver3 is still better.
>
> Well, of course I meant the aolserver prefix :) The includes should be
> right there, in <the-aolserver-prefix>/include. Do you not also need
> the aolserver libs? It's feasible you might in the future.

 ok. as far as i remember, there is no need to use the aolserver lib,
 since the external symbols are resolved against the running binary.
 i have changed this to --with-aolserver3=AOL_SERVER_DIR
 
> > everything including "make libxotcl1.2.so" should be fine without
> > a tclsh. the "make install-aol" uses a tclsh to load xotcl (for a minor
> > purpose, to rebuild the pkgIndex files). If you comment out
> > the last line of the "libraries:" rule in unix/Makefile,
> > you should be fine.
>
> See though, the whole point is not having to edit anything...

 the suggestion to remove the line was a temporary fix to keep you
 going and certainly not a permanent fix

> Having to
> do so implies C-based clue, which while you could assume it 20 years
> ago, is just not the case among unix-alike users anymore, and note
> carefully that this group especially includes people who want to use
> xotcl.

 we have the same opinion about the goals, no need to argue.

 you have certainy a complex setup, which is not the setup
 of an average user. i have currently on my system 2 tcl
 versions installed and a aolserver4, and i have not seen
 the problems you reported, otherwise i would have fixed it.
 One can only fix problems that you are aware off. your
 comments are very helpful raise this awarensss and
 to improve the system

 -gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Rene Zaumseil <r.zaumseil_at_freenet.de>
Date: Thu, 26 Jul 2012 21:34:43 +0200

Am Donnerstag, 26. Juli 2012, 05:09:06 schrieb Jonathan Kelly:
> Hi,
>
> I'm trying to get nx working under windows. I was using Activestate 8.5
> on an XP box ... and following the suggestion on the website I installed
> MSVisualStudio 10.0 express ... but I couldn't see how to get that to
> work ... there isn't a Makefile ... I had downloaded nsf2.0b3
>
> So I thought I'd try cygwin (which I already use for other purposes). I
> installed the compile tools, and ran configure, but it broke because I
> apparently don't have a /usr/local/include/tcl8.5/tools/genStub.tcl ...
> I took a gamble and downloaded a version I found on the web somewhere,
> and then configure ran but with some warning messages. Make then breaks
> with this
>
> ./generic/nsfError.c:116: error: conflicting types for 'NsfPrintError'
> ./generic/nsfDecls.h:73: error: previous declaration of 'NsfPrintError'
> was here
> ./generic/nsfError.c:116: error: conflicting types for 'NsfPrintError'
> ./generic/nsfDecls.h:73: error: previous declaration of 'NsfPrintError'
> was here
> Makefile:575: recipe for target `nsfError.o' failed
>
> I'm happy to be the guinea pig for getting the "use NX on windows"
> instructions to be useable.
Get msys/mingw with the default installer
http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-
get-inst/mingw-get-inst-20110211/mingw-get-inst-20110211.exe
and selected also g++, msys, and tools.

Then get kbs.tcl from
  http://sourceforge.net/projects/kbskit/files/

Put it in a directory and run:
  ./kbs.tcl -r install kbskit8.5 nsf2.0
If everything works you can find the lib under directory build*/

Or to get a interpreter containing nsf run:
  ./kbs.tcl -r -bi=nsf2.0 -vq-bi install kbskit8.5

Hope this works.
rene

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 18 Sep 2006 12:27:54 +0200

Murr, Florian schrieb:
> Dear XOTcl team,
> with XOTcl1.4.0 and XOTcl1.5.0 I encountered the following behaviour:
>
This behavior is unchanged since many years.
> ------------------------------------------------------------------------
> Class X -parameter {
> {p {}}
> }
>
> # works fine
> X create x1 -p {a b c}
>
> # blows up!!
> X create x2 -p {-name a -xyz b}
>
whatever "blows up" means: XOTcl replys an error message telling that it
tries
to call a method named "name a -xyz b".

The serializer handles this situation by using

    X create x2 [list -p {-name a -xyz b}]

Alternatively, one can use with slightly changed semantics
(no parsing of argument contents)

    X create x2
    x2 p {-name a -xyz b}

-gustaf neumann

From: Bernd Eidenschink <eidenschink_at_web.de>
Date: Mon, 15 Dec 2008 10:16:06 +0100

> For what it's worth, I've had to use Python lately for work and I have
> to say I'd still use XOTcl for any of my own projects. Python just
> seems wrong and even somewhat limited compared to the straightforward
> power of XOTcl.

You compare the wrong thing.

Tcl <-> Python
XOTcl <-> XOPython

But I don't remember the downloadlink at the moment :-)

Bernd.