Weblog Page

From: Yusuke Yamasaki <tm9233yy_at_gmail.com>
Date: Wed, 15 Oct 2014 19:13:25 +0900

Hello Gustaf,

It worked. Thank you!
Currently I'm using Tcl 8.5. But the main purpose of upgrading XOTcl
to 1.6.8 is to migrate to Tcl 8.6.
So I think it's better to use the exclusive one for Tcl 8.6 when I
leave Tcl 8.5 completely.

Regards,
Yusuke

---
Yusuke Yamasaki <tm9233yy_at_gmail.com>
2014-10-15 4:32 GMT+09:00 Gustaf Neumann <neumann_at_wu.ac.at>:
> Dear Yusuke,
>
> building XOTcl binaries with Tcl 8.5, that work with Tcl 8.6 is actually not
> quite simple,
> since when XOTcl is compiled under Tcl 8.5 uses the Tcl function
> TclObjInterpProcCore(),
> which was unfortunately removed from Tcl in 8.6. The commit entry, which
> deleted the
> stub entry in Tcl 8.6 says:
>
>     "Used to be needed for TclOO-extension; unneeded now that TclOO is in
> the core
>     and NRE-enabled"
>
> Therefore, when one loads the binary from Tcl 8.5 into Tcl 8.6, this symbol
> cannot be
> resolved. See as well the discussion in [1].
>
> However, to address this problem, i've added a new configure
> option "--enable-forward-compat86", which allows to build binaries of XOTcl
> with 8.5, that do not use TclObjInterpProcCore(), and can therefore be
> loaded into Tcl 8.6 as well. You can get this version currently just from
> git
>
>   git clone git://alice.wu.ac.at/nsf
>   cd nsf
>   git branch xotcl1 origin/xotcl1
>   git checkout xotcl1
>
> Use "--enable-forward-compat86" only in cases, where you need the forward
> compatibility. One will get better performance under Tcl 8.5 or Tcl 8.6 by
> compiling
> exclusively for these versions.
>
> best regards
> -gustaf neumann
>
> [1] https://next-scripting.org/list/1207.html
>
>
>
> Am 14.10.14 07:05, schrieb Yusuke Yamasaki:
>
> Hello,
>
> Because the teapot repository has up to XOTcl 1.6.7 for Windows,
> I tried to build 1.6.8 for myself. The easiest way was to use Msys/MinGW.
>
> ./configure --enable-threads --prefix=/c/bin/tcl8.5.16 \
> --with-tcl=/c/src/tcl8.5.16/win --with-tk=/c/src/tk8.5.16/win \
> --with-actiweb=no --with-xotclsh=no --with-xowish=no \
> --without-expat --without-gdbm \
> --with-tclinclude=/c/bin/tcl8.5.16/include \
> --with-tkinclude=/c/bin/tcl8.5.16/include
> make
> make install
>
> However it only works with either 8.5 or 8.6 depending on the version
> which I specified by --with-tcl option. Though I don't have deep
> understanding of the stub mechanism, I know it is a key to make a
> generic version of a C extension. I think XOTcl has -DUSE_TCL_STUBS=1
> by default configuration according to config.log.
>
> Is there anything wrong with my build procedure?
>
> Windows 7 Professional SP1 64bit
> Tcl/Tk 8.5.16
> ---
> Yusuke Yamasaki <tm9233yy_at_gmail.com>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>
>
> --
> Univ.Prof. Dr. Gustaf Neumann
> WU Vienna
> Institute of Information Systems and New Media
> Welthandelsplatz 1, A-1020 Vienna, Austria

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

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





  

From: Edmond Ho <edmondho_at_gmail.com>
Date: Sun, 9 Mar 2008 17:00:45 -0400

Hello all,

I downloaded XOTcl 1.6.0 today, and I immediately ran into an issue in some
of my existing code. The following example works in XOTcl 1.5.6, but is
different in XOTcl 1.6.0 -- as I understand the documentation on the
website, there should be no difference between versions.


package require XOTcl
namespace import ::xotcl::*
Class Foo
set f [Foo new]
$f info Class ;# returns "::Foo", which seems correct
$f info Class "Foo" ;# in 1.5.6, returns 1; in 1.6.0, returns an empty
string


To repeat, the issue is that "Object info class <classname>" returns a
boolean value in XOTcl 1.5.6, but returns an empty string in 1.6.0 -- the
current documentation on the website suggests that the 1.5.6 behavior is
correct.

Am I missing something? Should the documentation be changed, or is the
behavior in 1.6.0 incorrect? I downloaded the package via ActiveState's
teacup service; I'm working on Mac OS X 10.4 Intel.

Thanks in advance for any help!

Cheers,
Edmond

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Thu, 02 Sep 2004 11:43:31 +0200

Hi Michael,

the problem is part of the new namespace treatment. I've fixed this problem
and will send you the updated .tar.gz in a separate email. Anyone else
who has this problem
can get the fixed version from me. the fix will also make its way into
the next release.

Uwe




michael.heca_at_email.cz wrote:

>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
>
>
>
>_______________________________________________
>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_acm.org, uwe.zdun_at_wu-wien.ac.at

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Mon, 01 Sep 2003 11:56:57 +0200

Zoran Vasiljevic wrote:
> On Friday 29 August 2003 16:26, Catherine Letondal wrote:
> > Hi,
> >
> > I have just re-installed Xotcl 1.0.2 version and succedeed in running my
> > application with some minor changes since the last xotcl version I used on
> > this platform (Sparc/Solaris 7) was the 0.9 :-)
> >
> > I have a segmentation fault that occurs when a command is called from a Tk
> > menu. The command is attached to the popup by a:
> > add command -command
> > statement on a menu Tk widget that is raised by a tk_popup.
> >
> > However, the very same command, when called from the tcl (xowish)
> > interpreter, works and does not produce any core dump. And most menu items
> > also work well.
> >
> > So my question is: how do I debug such a situation?
> > Thanks for any help...
>
> You should compile wish with symbols (./configure --enable-symbols).
> The same appiles for xotcl as well.


When I compile xotcl after a ./configure --enable-symbols the compilation
just fails to compile because it looks for a libtcl8.3g.so file (or maybe I should
have built the tcl library before?):

cc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DVERSION=\"1.0\" -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 -DHAVE_TCL_COMPILE_H=1 -DTCL_SHLIB_EXT=\".so\" -I/local/packages/tcl8.3.2/generic -I/local/packages/tcl8.3.2/unix -I"./../generic" -I"./../unix" -I"/usr/local/include" -g -g -fPIC -g -DXOLIBPKG=\"/usr/local/lib/xotcl1.0\" -DXOTCLVERSION=\"1.0\" -DXOTCLPATCHLEVEL=\".2\" -c `echo ../unix/xotclAppInit.c` -o o/xotclAppInit.o
cc: Warning: illegal option -fPIC
cc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DVERSION=\"1.0\" -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 -DHAVE_TCL_COMPILE_H=1 -DTCL_SHLIB_EXT=\".so\" -I/local/packages/tcl8.3.2/generic -I/local/packages/tcl8.3.2/unix -I"./../generic" -I"./../unix" -I"/usr/local/include" -g -g -fPIC -g -DXOLIBPKG=\"/usr/local/lib/xotcl1.0\" -DXOTCLVERSION=\"1.0\" -DXOTCLPATCHLEVEL=\".2\" -c `echo ../generic/findXOTcl.c` -o o/findXOTcl.o
cc: Warning: illegal option -fPIC
cc o/xotclAppInit.o o/findXOTcl.o -L/local/packages/tcl8.3.2/unix -ltcl8.3g -ldl -lsocket -lnsl -lm -lc -o ../xotclsh
ld: fatal: library -ltcl8.3g: not found
ld: fatal: File processing errors. No output written to ../xotclsh
*** Error code 1
make: Fatal error: Command failed for target `../xotclsh'
Current working directory /local/packages/xotcl-1.0.2/unix
*** Error code 1
make: Fatal error: Command failed for target `xotclsh'



But in fact, gdb tells where the program stopped:

(gdb) bt
#0 0xfed5c580 in Tcl_PopCallFrame () from /local/lib/libtcl8.3.so
#1 0xfed69950 in TclObjInterpProc () from /local/lib/libtcl8.3.so
#2 0xfed61f98 in EvalObjv () from /local/lib/libtcl8.3.so
#3 0xfed625dc in Tcl_EvalEx () from /local/lib/libtcl8.3.so
#4 0xfed627cc in Tcl_Eval () from /local/lib/libtcl8.3.so
#5 0xfed28114 in Tcl_GlobalEval () from /local/lib/libtcl8.3.so
#6 0xfee26058 in Tk_BindEvent () from /local/lib/libtk8.3.so
#7 0xfee2aaac in TkBindEventProc () from /local/lib/libtk8.3.so
#8 0xfee308a0 in Tk_HandleEvent () from /local/lib/libtk8.3.so
#9 0xfee30ca4 in WindowEventProc () from /local/lib/libtk8.3.so
#10 0xfed5f960 in Tcl_ServiceEvent () from /local/lib/libtcl8.3.so
#11 0xfed5fcf8 in Tcl_DoOneEvent () from /local/lib/libtcl8.3.so
#12 0xfee30d08 in Tk_MainLoop () from /local/lib/libtk8.3.so
#13 0xfee3bb7c in Tk_MainEx () from /local/lib/libtk8.3.so
#14 0x2be9c in main ()


In fact I should rather re-start from the beginning. I had many problems during
the compilation of Xotcl on my platform.
Here is how the output looks like:

Text relocation remains referenced
    against symbol offset in file
<unknown> 0x140f8 so/xotcl.o
<unknown> 0x140f4 so/xotcl.o
<unknown> 0x13d78 so/xotcl.o
<unknown> 0x10b60 so/xotcl.o
<unknown> 0x13644 so/xotcl.o
<unknown> 0x10b5c so/xotcl.o
[...]
memcpy 0x50 so/xotcl.o
memcpy 0x124 so/xotcl.o
memcpy 0x638 so/xotcl.o
memcpy 0xf594 so/xotcl.o
memcpy 0x5a4 so/xotcl.o
memcpy 0xbc so/xotcl.o
tclStubsPtr 0x96a8 so/xotcl.o
tclStubsPtr 0x98ac so/xotcl.o
tclStubsPtr 0x98dc so/xotcl.o
tclStubsPtr 0x98e0 so/xotcl.o
tclStubsPtr 0x9680 so/xotcl.o
tclStubsPtr 0x9600 so/xotcl.o
[...]
tclStubsPtr 0x468 so/xotclTrace.o
[...]
XOTclObjErrArgCnt 0xd2f8 so/xotcl.o
[...]
XOTclObjErrArgCnt 0x12dac so/xotcl.o
[...]
XOTclObjErrArgCnt 0x458 so/xotclTrace.o
[...]
tclIntStubsPtr 0x119dc so/xotcl.o
[...]
XOTclAddPMethod 0x10ad8 so/xotcl.o
XOTclAddPMethod 0x1447c so/xotcl.o
XOTclSelfDispatchCmd 0x1443c so/xotcl.o
XOTclSelfDispatchCmd 0x14438 so/xotcl.o
XOTclInitProcNSCmd 0x14414 so/xotcl.o
XOTclInitProcNSCmd 0x14418 so/xotcl.o
Xotcl_Init 0x12f40 so/xotcl.o
Tcl_InitStubs 0x138f0 so/xotcl.o
XOTcl_TraceObjCmd 0x14388 so/xotcl.o
XOTcl_TraceObjCmd 0x14384 so/xotcl.o
<unknown> 0xa4 so/xotclError.o
<unknown> 0xc0 so/xotclError.o
<unknown> 0x114 so/xotclError.o
[...]

XOTclStackTrace 0x498 so/xotclTrace.o
XOTclCallStackTrace 0x4c0 so/xotclTrace.o
ld: fatal: relocations remain against allocatable but non-writable sections
make: Fatal error: Command failed for target `libxotcl1.0.so'
Current working directory /local/packages/xotcl-1.0.2/unix
make: Fatal error: Command failed for target `libs'

I don't remember how it is I still have a libxotcl1.o.so built!!

No wonder there is a segmentation fault.

Thanks a lot for any help,

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sat, 13 Oct 2001 16:45:34 +0200

Hi

The new version 0.20 of XotclIDE
Integrated Interactive Developing Envirorment for Xotcl is ready.


The most important changes in version 0.19 and 0.20
- Full featured configuration browser. For managing sets of versioned
components
- Changes Browser. To see the changes among different component versions
(something like diff)
- Version System Browser. To see the components without the need to load them.
- Error Reporting Tool - to allow user to send tcl error stack as XML file
- Method Call Tracker - to track the method calls.
- Many user friendly GUI additions

Download, Documantation, Screenshoots

http://www.xdobry.de/xotclIDE/

Artur Trzewik

From: Artur Trzewik <mail_at_xdobry.de>
Date: Wed, 25 Apr 2001 20:51:56 +0200

Halo

The problem is more complicated than I have expected.
It is true, proc are not good for this purposes.
Classproc are very good idea but it would complicate the model.

It is really a program style not to use class methods.
If you come from C++ or Java (brr...) you will seldom use it.
Smalltalk-programmers will miss it (there are many smalltalk based languages)
A main usage is individual instance creation
(such as Factory Patterns in C++ or type based polymorphismus)
for example

MyClass createFromXML "...xml string"
MyClass createFromFooObject myObject

C++ programmers will write

class MyClass {
public:
     MyClass(XMLNode node);
     MyClass(FooClass myObject);
};

It is difficult to simulate it in xotcl by using C++ way

MyClass instproc init {aThing} {
       if {[Object isobject $aThing] && [$aThing istype FooClass]} {
              [self] initFromFooObject $aThing
       } else {
            .......
       }
}

Perhaps Xotcl need inheritable class methods because it is not typed.
It can be very usefull to delegate some tasks to another class method
by implementing factories as class methods.

At now I implement databased persistence for Xotcl objects.
I use class methods for create instances, query database or code
mapping rules.

Class DBPersistence
Class MyClass -super DBPesistence

so I will do (100 is the database Id)

MyClass createFormId 100

or

MyClass getAllFor {name="destroy" and type not null}

I have noticed that Xotcl Philosophy is to use Metaclasses

Class DBPersistent -superclass Class
DBPersistent MyClass

until now I have not programed any Metaclasses (maybe it is time to do it)


> InheritClassProc instproc unknown {m args} {
> foreach c [[self] info heritage] {
> if {[info command ${c}::$m] != ""} {return [eval $c $m $args]}
> }
> next
> }
> Class instmixin InheritClassProc

The solution do not do what I expect
See this example. It demostrate how inheritable class method can be used

Class TkWidget
TkWidget proc testMe {} {
   set toplevel [toplevel [Object autoname .toplevel]]
   set inst [[self] create [Object autoname twidget] ${toplevel}.test]
   pack $toplevel.test
   return $inst
}
Class TkText -superclass TkWidget
TkText instproc init {win} {
     text $win
}
Class TkEntry -superclass TkWidget
TkEntry instproc init {win} {
     puts "window $win"
     entry $win
}
TkEntry testMe

I will try to use metaclasses for my problems.
It can be good to take a look on other new objectbased languages
ruby, self, python.
How do these languages handle class methods?


=========================================

 Artur Trzewik
 http://www.xdobry.de

=========================================

From: Rick Hedin <rhedin_at_aquifer.geology.uiuc.edu>
Date: Wed, 23 May 2001 15:04:33 -0500

Hello all.

I have been just using puts to debug my xotcl code. Is there a debugger
that works? TclPro seems to have some problems with Xotcl, or I don't
understand how to use TclPro.


        Regards,

        Rick

Today's mighty oak is just yesterday's acorn that held its ground.

From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Wed, 18 Aug 2004 11:59:15 -0700

Hi.

I'm Jim Lynch, and I have started making improvements to the configure/
build process for xotcl. As Gustaf mentions in his letter, my work is
incorporated into xotcl-1.3.0, mostly in the files called configure.in
and Makefile.in.

Executive summary: Big immprovement; not finished. Separate build dirs
do not work yet. xotclConfig.sh gets installed in $libdir; please read
it, especially if you are an embedder or similar. Lots more work to do,
but it works for most cases when you build in the source tree root.

On Wed, 18 Aug 2004 11:44:02 +0200
Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:

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

[snip]

> Best regards,
>
> Gustaf Neumann
> Uwe Zdun

Thank you :)

But I still have things to do and things to ask for, which I will:
some now, some later :)

I have to learn how to make separate build dirs work, or what the
prevailing standard is, and make that work, so that people can do

  mkdir build
  cd build
  ../configure --with-all
  make
  make install
  (read the xotclConfig.sh to see which tcl has the package installed)
  (run the shell from that tcl)
  % package require XOTcl

and have the shell load xotcl. Added complication is there are several
nested build trees; the configure and build steps work for this except
when trying to use a separate build dir.

I would like to ask embedders of xotcl, if there is a chance you'd be
able to use a tclsh where you do the package require of xotcl and
other packages you need, rather than use xotclsh and xowish... it's
been suggested that this might be the more portable approach, but
I want to ask all of the embedders first before I ask Gustaf whether
it'd be ok to deprecate them in favor of having the embedders prepare
a plain tclsh.

Also to embedders!! The file xotclConfig.sh is now installed, and
has -relevent- information about where the install of xotcl is!
I ask you to please read this file; it gets installed in $libdir.
In addition, this file only covers posix shells, not csh. Any
csh-using embedders here? If so, I'll figure out how to deshellify
this script; all it does is set some variables in the environment.

There will be a lot more later... but this is enough for now :)

Comments please :)

-Jim

--
Jam sessions community web site: http://jam.sessionsnet.org

From: Kurt Stoll <kstoll_at_echelon.com>
Date: Wed, 13 Jun 2012 08:35:44 -0700

Thank you Gustaf. I did open up a thread in their forum, but have not seen any responses yet. It's at:

        http://community.activestate.com/node/8750

I'll see if I can find the error handling code that is being called to determine where the issue is.

-Kurt


> -----Original Message-----
> From: Gustaf Neumann <neumann_at_wu.ac.at>
> Subject: Re: [Xotcl] Loading XOTcl crashes
> Date: June 13, 2012 12:16:34 AM PDT
> To: xotcl_at_alice.wu-wien.ac.at
>
>
> When everything works from the shell, and it works with Komodo V6 and it does not work with Komodo V7, then it certainly looks like a problem with Komodo V7. We do not have Komodo here, which is a commercial product (most likely with a commercial support). Is the a public visible forum with your discussions, maybe i can get a clue from it... From the snippet below, there seems to be a problem with the error handling (where i see nothing special from the xotcl side).
>
> -gustaf neumann
>
> On 13.06.12 02:33, Kurt Stoll wrote:
>> (I realize that this is probably not an XOTcl issue, but a ActiveState Komodo issue; however, I have not been able to find an answer through ActiveState, so I may have better luck here.)
>>
>> Running on a Mac, using OSX V10.7.4.
>>
>> I cannot get XOTcl to load properly with ActiveState Komodo V7. I do not have any problem with V6 of that tool. Also, loading XOTcl into tclsh when invoked from the Terminal works. All three environments (Komodo V7, V6, and Terminal / tclsh) are using the same version of Tcl (8.5) and the same version of XOTcl (1.6.6 - I know, down rev by one release). All three versions point to the same library file: /System/Library/Tcl/8.5/xotcl1.6.6/libxotcl1.6.6.dylib.
>>
>> Yet, when I attempt to load XOTcl (using package require XOTcl) from Komodo V7, it gets stuck in an infinite loop:
>>
>>
>> Error in predefined code
>> too many nested evaluations (infinite loop?)
>> while executing
>> "DbgNub_infoCmd exists DbgNub(returnState)"
>> (procedure "catch" line 11)
>> invoked from within
>> "catch {set savedErrorInfo $::errorInfo}"
>> (procedure "::unknown" line 18)
>> invoked from within
>> ...
>> "proc ::xotcl::myproc {args} {linsert $args 0 [::xotcl::self]}"
>> too many nested evaluations (infinite loop?)
>>
>>
>> I don't believe I have changed any relevant settings.
>>
>> Any clues?
>>
>> Thanks,
>> Kurt Stoll
>>
>>
>> _______________________________________________
>> Xotcl mailing list
>> Xotcl_at_alice.wu-wien.ac.at
>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl