Weblog Page

From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Tue, 24 Jul 2007 09:18:33 +0200

> Concerning bug#2: i think you sent me the same bug (with a different
> testfile) on march 15, i have sent you a fix back on march 16.

Gosh, this is so true. I simply forgot about patching it in the
last time i set up xotcl ...

Many thanks for your quick response and your efforts to
assemble a bug-fix release.

best
//stefan

-- 
Stefan Sobernig
Institute of Information Systems and New Media
Vienna University of Economics	
Augasse 2-6
A - 1090 Vienna
`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan.sobernig_at_wu-wien.ac.at <mailto:stefan.sobernig_at_wu-wien.ac.at>
`- ss_at_thinkersfoot.net <mailto:ss_at_thinkersfoot.net>

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 30 Sep 2005 14:28:27 -0400

Thanks for the advice. I have made sure to garbage collect my unneeded
objects. I need
to look into those other sources of memory usage.

My application is soley Tcl/XOTcl and does not use threads. The majority of
the code is
XOTcl. There are no C extensions.

I am using introspection to find objects and values of the variables in
those objects. This
has been very helpful in identifying "lost objects."

I will recompile the tcl and xotcl binaries to enable memory usage commands.
I still
suspect a list or array out of control. I guess I am in for a few more
nights of staring
at top.

Thanks for the time { ... } 10000... idea. That will be useful in my unit
tests.

Thanks,

Ben

>xotclsh
% package require XOTcl
1.3.6
% package require Tcl
8.4
%


On 30/09/05, Zoran Vasiljevic <zv_at_archiware.com> wrote:
>
>
> Am 30.09.2005 um 19:28 schrieb Gustaf Neumann:
>
> >> What tools or tricks are useful for tracking down memory leaks in
> >> Tcl or XOTcl?
>
> Tricks? No tricks. Hard work and lots of money to spend on good
> memory analyzer (Purify), heh...
>
> And, watching "top" output for hours while doing "time {....} 100000"
> on some spots you *suspect* may be raining on your party!
>
> Honestly, this is one of the most
> ugly
> time consuming
> boring
> unproductive
> difficult
> stupid
> (... you name it ...)
>
> tasks you can imagine. Have been doing this for quite
> a few years already, so I know what I'm saying.
>
> Couple of hints...
>
> Is your Tcl or your C-code leaking? (this is not as
> dumb question as it may appear on the first glace...)
>
> If you are using threads, try in a non-threaded env.
>
> Try isolating parts of your code by divide/conquer
> method (start from top and work yourself down) and
> use "time" to repeat sections of code. At the same
> time keep an eye on the "top" utility... (Poor Man's Purify)
>
> If you are running in an event mode, do you clean
> event loop fast enough?
>
> If possible, try compilng *ALL* the C-code you use
> with -DTCL_MEM_DEBUG and read "memory" man-page.
> This is somehow difficult to use (gives A LOT of
> info) but in some cases it saved my skin.
>
> As of my experience, Tcl/XOTcl are leak-free.
> If not I'd already scream aloud. If you are
> using any other C-level extensions, well...
>
> If not, then most probably you do not care enough
> about destroying the objects. What I do is to
> (mostly) instantiate objects like this:
>
> Object new -volatile
>
> which guarantees to garbade-collect them when the scope
> (i.e. proc) were I new'ed them is gone. This won't work
> for "globaly" needed objects, though...
>
> Memory "leaks" can be quite "hidden", for example arrays
> getting larger, lists getting longer, etc. etc. Those
> are not "leaks" per-se, hence never caught by any
> C-level memory debugger. For that you'd need to employ
> the poor-man's purify, like described above.
>
> Eh... good luck!
>
> Zoran
>
>
>
>
>
>
>

--
You know you have reached perfection of design not when you have nothing
more to add, but when you have nothing more to take away. --Antoine de Saint
Exupéry

From: <mail_at_xdobry.de>
Date: Thu, 21 Oct 2004 13:46:01 +0200

Hi!

I work currently with 1.3.2 and have one problem
that relate to namespace handling.
I would need new object method that could return full name of
object
(similar to "namespace origin" command)

I could not find any possibility to get it from
build-in Object methods.
I would expect that "self" or "my" on object would work.

So I must programm new global Object instproc:

Object instproc fullname {} { self }

so it work

Object a
a fullname
>::a

Is were any better possibility to get the same result?
If not it could be idee to extend object base interface (for example
info command)

Artur Trzewik

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Mon, 30 Jul 2012 11:10:05 +0200

On 28.07.12 22:23, Rene Zaumseil wrote:
> Am Freitag, 27. Juli 2012, 12:32:20 schrieb Gustaf Neumann:
>
> - got an error that wget is not installed;
> installed wget, added GnuWin32/bin to the path
> Ok, I have the sources downloaded under unix and then copied to windows.
maybe, your kbs.tcl script could obtain wget automatically?
This would
make life for newbies easier. i had the impression, the
script was
supposed to work under win.
> I have installed the 20110211 version last year because my older
> installation from the tcl sourceforge side was not working anymore.
> I think it was a problem with missing libraries.
For the record, the version " mingw-get-inst-20120426" works
fine.
> Oh,may be here. I have put the kbs directory under:
> C:\MinGW\msys\1.0\home\rene
> Could you also try to put the kbs directory under these path?
See the previous mail, the "path" in general was not the
problem, but the drive.
After the copy, the script kbs.tcl continued nicely until it
run again into
troubles in the compilation of vfs.c (trying to access
incomplete type
Tcl_StatBuf, see below). According to the sources,
definition of
Tcl_StatBuf has changed in tcl 8.5.12 (most likely it will work
with 8.5.11). I hacked locally vfs.c by defining a type
Tcl_StatBuf_ (using the
definition of pat thoyts in [1]. Then vfs compiled fine.

Then I run than into the problem:

--2012-07-30 10:28:40-- http://equi4.com/pub/tk/tars/zlib.tar.gz
Auflösen des Hostnamen »equi4.com«.... 188.142.57.184
Wiederverwendung der bestehenden Verbindung zu www.equi4.com:80.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 502488 (491K) [text/plain]
In »zlib.tar.gz« speichern.

100%[========================================================> ] 502.488 606K/s in 0,8s

2012-07-30 10:28:41 (606 KB/s) - »zlib.tar.gz« gespeichert [502488/502488]

=== Configure C:/Users/neumann/Downloads/kbs/buildWindowsNT/zlib1.2.3-static
/usr/bin/env: ./configure: No such file or directory
=== Require error: zlib1.2.3-static
child process exited abnormally
Error in execution of 'install kbskit8.5':
=== Package failed for: zlib1.2.3-static
Require failed for: zlib1.2.3-static


In .../Downloads/kbs/buildWindowsNT/zlib1.2.3-static i have
now two entries,
__dev__null__ and zlib (the latter is a directory containing
configure. So, maybe
the directory is path in kbs.tcl is incorrect....

Stopping here
-gustaf neumann

[1] http://old.nabble.com/-Tcl-bugs----tcl-Bugs-2651823---Tcl_StatBuf-definition-problem-with-VS2005-and-Win-XP-x64-td31486201.html


=== Install C:/Users/neumann/Downloads/kbs/buildWindowsNT/tk8.5-static
=== Require done: tk8.5-static
=== Require eval: tk8.5
=== Require tk8.5
=== Require tcl8.5
=== Require eval: tcl8.5
=== Make C:/Users/neumann/Downloads/kbs/buildWindowsNT/tcl8.5
=== Install C:/Users/neumann/Downloads/kbs/buildWindowsNT/tcl8.5
=== Require done: tcl8.5
=== Require leave: tcl8.5
=== Make C:/Users/neumann/Downloads/kbs/buildWindowsNT/tk8.5
=== Install C:/Users/neumann/Downloads/kbs/buildWindowsNT/tk8.5
=== Require done: tk8.5
=== Require eval: vfs1.4-static
=== Make C:/Users/neumann/Downloads/kbs/buildWindowsNT/vfs1.4-static
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c: In Funktion »VfsStat«:
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1128:12: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1142:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1149:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1156:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1163:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1170:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1177:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1184:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1191:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1198:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1205:13: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1210:10: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1212:10: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
c:/Users/neumann/Downloads/kbs/sources/vfs1.4/generic/vfs.c:1215:10: Fehler: Dereferenzierung eines Zeigers auf unvollständigen Typen
make: *** [vfs.o] Error 1
=== Require error: vfs1.4-static
child process exited abnormally
Error in execution of 'install kbskit8.5':
=== Package failed for: vfs1.4-static
Require failed for: vfs1.4-static

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Tue, 11 Jan 2011 10:58:01 +0100

Hello,

Thank you all for your help.
I now know how to avoid the error that I was getting. The reason why I
was concerned by the error was that I did not remove any class like in
your examples, all I did was several source commands on the same file.
It appears that some filter removes tester.tcl from my attachment, so
here it is:

package require XOTcl
namespace import xotcl::*
source extendedContainer.xotcl
source c.xotcl

ExtendedContainer create ec

Currently I am using Ubuntu 9.04 with XOTcl 1.6.5-1.2 package.

-- 
Krzysztof Frukacz

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Thu, 28 Oct 2004 09:03:50 -0400

I think the ability to delete an instproc is handy, I just didn't realize what was going on. Thanks for the quick response.

--bryan



> -----Original Message-----
> From: Gustaf Neumann [mailto:neumann_at_wu-wien.ac.at]
> Sent: Wednesday, October 27, 2004 5:54 PM
> To: Schofield, Bryan (GE Transportation); xotcl_at_alice.wu-wien.ac.at
> Subject: Re: [Xotcl] Bug: Empty arglist and body throws error
>
>
> Dear Bryan,
>
> > I'm afraid I found a bug that will generate an "unable to
> dispatch" error
> if the argument list & body of an >instproc are both empty.
> You will notice
> that as long as either contain something, it's ok. Notice the
> body of >"Bar
> notpuke", it's just a single comment. See the code below:
>
> we have a behavior in xotcl that we inherited from otcl:
> when instproc is
> invoked
> with an empty argument list and an empty body, this instproc
> is deleted.
> Most probably, we should do the following:
> a) produce an error, when someone tries to delete a non.existing
> proc/instproc
> b) document this behavior somewhere more visible.
>
> -gustaf
>
>

From: Marc Spitzer <mspitze1_at_optonline.net>
Date: Thu, 22 Apr 2004 22:47:46 -0400

On Thu, 22 Apr 2004 17:29:52 -0700
Jeff Hobbs <jeffh_at_ActiveState.com> wrote:

> However, a true core OO should be done in C. xotcl is that
> already. Sure, you can code parts of snit in C - but xotcl
> is already there *and tested*. It has active developers and
> interested users. It's even gone so far as to have an alpha
> "itcl compatability" mode that actually faster than the C
> coded itcl!

I seem to remember an alpha snit compatibility also.

marc

From: Ron <brisgent_at_bigpond.net.au>
Date: Mon, 10 Apr 2006 08:00:26 +1000

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 28 Jun 2011 12:24:31 -0700

%Object create o
::o
%o attribute {a oldvalue}
::o::a
%o a
oldvalue
%o attribute {a newvalue}
::o::a
%o a
oldvalue
%


Thanks,

Victor

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 29 Sep 2005 02:01:39 +0200

Donal K. Fellows schrieb:

>
> There are two 'move' methods/instprocs. One is in the XOTcl base Object
> class, and one is in C.

ok, i though this was already omitted :)

> Perhaps I should explain more about what I was asking about. :-)
>
> What I did was I constructed the situation according to the attached
> diagram (sorry to everyone for doing an attachment, but I refuse to do
> ASCII art for this!) and what I wanted to know was, given that we've got
> a per-object mixin, would the foo inherited from A by B be mixed in at
> higher precedence than the foo gained by D directly from C. If that's

> the case, would the move inherited from Object through the mixin side
> override the move gained directly from C? As far as I can tell as
> someone who has not thought about this in detail, that's the only way to
> do this sort of thing consistently. But it also means that mixins will
> stamp all over any attempt to redefine behaviour for a particular
> application domain.

Look at the precedence order:

% D info precedence
::B ::A ::C ::xotcl::Object

therefore C->move before ::xotcl::Object->move

it would be no good idea to define this as you mentioned above
::B ::A ::xotcl::Object ::C

since e.g. on an "D destroy" the object would be deallocated though
::xotcl::Object
and a destructor in C would never be called. Since every class is a subclass
of ::xotcl::Object, mixin would not work in any useful way, at least
when class
hierarchies are mixed in. Mixing in single classes would be rather limited.

we call the mapping from the class structure to the order classes are
searched "linearization". It takes care that the more general classes
are not
preceding subclasses.

> If I'm wrong and I've overlooked something, what is
> it? It's certainly not clear to me. (Mind you, it's midnight as I write
> this so the old braincells might not be producing maximum clarity
> anyway. ;-) )
>
> I hope this all explains why I was asking what appears to be on the
> surface a trivial question, and the answer should clear up the details
> of what I don't know about XOTcl inheritance rules from reading the
> documentation.

The follwing paragraph in the section "Precedence Order" in the tutorial
is supposed to describe linearization. Sorry, if this is not clear enough:
 
Filters as well as classes (mixins and ordinary classes) are linearized.
That means, each filter and each class can be only once on a precedence
order list. If a filter or class can be reached more than once, the
last occurrence is used.

best regards
-gustaf neumann