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

Weblog Page

Showing 1211 - 1220 of 1561 Postings (summary)

Re: [Xotcl] error not taken in account in init instproc

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: Thu, 24 Feb 2005 02:20:17 +0100

Dear Fabrice,

thanks for noting; the bug is confirmed.

Apply this small patch to fix it. We will change the package require
to return the full verison number as well in the next version.

happy xotickling
-gustaf neumann


--- generic/xotcl.c-orig Thu Feb 24 02:04:31 2005
+++ generic/xotcl.c Thu Feb 24 02:11:32 2005
_at_@ -6391,7 +6391,9 @@
     obj->flags |= XOTCL_INIT_CALLED;
   }
 
- Tcl_SetObjResult(in, savedObjResult);
+ if (result == TCL_OK) {
+ Tcl_SetObjResult(in, savedObjResult);
+ }
   DECR_REF_COUNT(savedObjResult);
 
   return result;



Fabrice Pardo schrieb:

>The errors seems not to be taken in account in "init" instproc:
>
>Class create C
>C instproc init {e} {
> if {$e} {error "an error"}
> next
>}
>C create o1 1 ;# ::o1
>set errorInfo ;# an error...while executing...
>C create o1 1 ;# now a blank line !
>C create o2 ;# ::o2
>set errorInfo ;# wrong # args: should be "init e" ...
>
># Program version:
>info patchlevel ;# 8.4.8
>package ifneeded XOTcl 1.3.3 ;# load /.../libxotcl1.3.3.so XOTcl
>
>
>

[Xotcl] xotcl 1.1.0, tcl/tk 8.4.4 and freebsd 4.9 are not happy with each other

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

From: Marc Spitzer <mspitze1_at_optonline.net>
Date: Sat, 29 Nov 2003 18:45:50 -0500

Hello all,

I am trying to build xotcl 1.1.0 with tk/tcl8.4.4 from the ports tree on a freebsd 4.9 box and it is not working. The problem os that tk/tcl on
freebsd is setup such that you can have mutpile version of tcl on the box at the same time and this breaks the build process. Here is my
configure line:

./configure --with-all --with-tcl=/usr/local/lib/tcl8.4/ --with-tk=/usr/local/lib/tk8.4 --with-tkinclude=/usr/local/include/tk8.4

here is the output from gmake:
$ gmake
cc -DUSE_TCL_STUBS -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" -O -fPIC -g -DXOTCLVERSION=\"1.1\" -DXOTCLPATCHLEVEL=\".0\" -c `echo ../generic/xotcl.c` -o so/xotcl.o
In file included from ../generic/xotcl.c:47:
../generic/xotclInt.h:15: tclInt.h: No such file or directory
In file included from ../generic/xotclInt.h:16,
                 from ../generic/xotcl.c:47:
../generic/xotcl.h:30: tcl.h: No such file or directory
../generic/xotcl.h:102: #error Tcl distribution is TOO OLD, we require at least tcl8.0
gmake: *** [so/xotcl.o] Error 1
$

Now the files that are "missing" are in /usr/local/include/tcl8.4:

bogomips# cd ../tcl8.4
bogomips# ls
generic tcl.h tclDecls.h tclPlatDecls.h unix
bogomips# ls *
tcl.h tclDecls.h tclPlatDecls.h

generic:
regcustom.h tclDecls.h tclMath.h
regerrs.h tclIO.h tclPlatDecls.h
regex.h tclInitScript.h tclPort.h
regguts.h tclInt.h tclRegexp.h
tcl.h tclIntDecls.h
tclCompile.h tclIntPlatDecls.h

unix:
tclUnixPort.h tclUnixThrd.h

so how hard would it be to add a --with-tclinclude ?

Also I would need to do this for tclsh and wish(do I need to do wish?),
on freebsd they are both shell scripts that tel you what you have installed not the real tclsh, like so:
bogomips# tclsh
In FreeBSD, tclsh is named with a version number. This is because
different versions of tclsh are not compatible with each other and
they can not all be called "tclsh"! You may need multiple versions
installed because a given port may depend on a specific version.

On your system, tclsh is installed under at least the following names:

tclsh8.3
tclsh8.4


Thanks,

marc

[Xotcl] Expand init arguments and custom destructor

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

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Tue, 08 Feb 2011 09:20:01 +0100

Hello,

Thank for all your help so far. I have two more questions:

1. Is it less efficient if I expand a list before providing it as an
argument for init?

set myList [list 1 2 3 4]

MyClass myObject $myList

vs

eval MyClass myObject $myList

2. When do I need to create a custom destructor? I create objects inside
init - do I have to do that in this case, or will those object be
destroyed automatically when I destroy their parent?

MyClass instproc init args {

        my contains {
                MySecondClass innerObject
        }
}

Best Regards,
Krzysztof

[Xotcl] children order

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

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Wed, 12 Jan 2011 14:00:42 +0100

Hello,

I would like to use the children mechanism for my classes. When I create
a class (lets call it B) I use -contains {...} and list other objects.
But in init proc of B I also use this: eval C new -childof [self].
I am interested in the order that children are listed. I need it to be
fixed. I noticed that first goes the child from init of class B, then
the ones that I add using -contains (outside the init proc).

Is this order fixed? (first children created in superclesses, then ones
from cunstructor, then ones from -contains). Also: is the order used in
-contains fixed? Will I always get children in the same order that I
added them?

Best Regards,
-- 
Krzysztof Frukacz

[Xotcl] 1.3.3 Plans?

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

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Wed, 6 Oct 2004 09:00:04 -0400

Just curious on the plans for the next official release of xotcl. I know that there have been a few issues that Gustaf & Uwe have been mulling over since the first 1.3 release. In particular, the namespace scoping handling that made it's debut then was removed in Uwe's 1.3.2 unofficial, interim build. I ask because I have some code that I've been working on that I started when I was testing Gustaf's original implementation before 1.3. I think (hope) that others will these libraries useful, but I hesitate to make them public until the namespace scoping has settled. Anyway, just curious.

-- bryan

Re: [Xotcl] XOTcl and Thread

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

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Thu, 10 Feb 2011 16:04:30 +0100

On 02/10/2011 03:26 PM, Victor Mayevski wrote:
> #Thread #1
> tsv::set array1 key2 [tread::id]
>
> #Thread #2
> set tid [tsv::get array1 key2]
> thread::send $tid [list $localVar doSomething]
>
> On Feb 10, 2011 5:27 AM, "Krzysztof Frukacz"
> <frukacz.krzysztof_at_gmail.com <mailto:frukacz.krzysztof_at_gmail.com>> wrote:

Hello Victor,

This looks like a nice solution. As far as I understand Thread #1 would
have to call thread::wait to enter event loop to be able to process what
was sent from Thread #2, right?
I would like Thread #1 to do its work and receive commands from Thread
#2. The problem is that when Thread #1 calls thread::wait it will wait
until another thread sends a script, right? In case there is nothing to
do (in the event loop) I would like Thread #1 to continue normal work.
How can I do that?

-- 
K

[Xotcl] Multithreading, memory usage, etc.

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

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Mon, 5 Mar 2001 10:56:52 +0100

Hi Xotcl collegues !

My name is Zoran Vasiljevic. Uwe and Gustaf already know me,
as I've helped them for rolling-out the 0.83 version. I did some
multithreading-related fixes and Purify tests.

I've been using Xotcl in an multithreading environment,
i.e. within the AOLserver Web server, version 3.2.
I did have to make certain modifications to the server in order
to intergrate Xotcl there, but that was not so difficult.

After some (deployment) time I've noticed certain memory
(well, not exactly leaks, rather uncontrolled) consumptions
which I was not able to track-down with Purify.

I've invested some days investigating this and have found the
cause of problems. I also have the needed changes to xotcl.c
to correct this behaviour.

My question is: when is the next Xotcl version planned and to
whom should I send the changes so they get integrated into
the main distro ? Uwe ? Gustaf ?

Cheer's
Zoran Vasiljevic
Archiware

[Xotcl] Compilation failure

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

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 18 May 2011 10:52:44 -0700

Hello Gustaf,

NX will not compile against the latest 8.6 TCL from fossil on 32 bit
Ubuntu. Here is the error (after "./configure"):

#####################
4ghz NX # make
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsf.c` -o nsf.o
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfError.c` -o nsfError.o
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfObjectData.c` -o nsfObjectData.o
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfProfile.c` -o nsfProfile.o
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfTrace.c` -o nsfTrace.o
./generic/nsfAccessInt.h:76: warning: ‘VarHashTableCreate’ defined but not used
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfUtil.c` -o nsfUtil.o
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfShadow.c` -o nsfShadow.o
./generic/nsfAccessInt.h:76: warning: ‘VarHashTableCreate’ defined but not used
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfCompile.c` -o nsfCompile.o
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/aolstub.c` -o aolstub.o
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfStubInit.c` -o nsfStubInit.o
rm -f libnsf2.0.0.so
gcc -shared -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC
-Wl,--export-dynamic -o libnsf2.0.0.so nsf.o nsfError.o
nsfObjectData.o nsfProfile.o nsfTrace.o nsfUtil.o nsfShadow.o
nsfCompile.o aolstub.o nsfStubInit.o -L/usr/local/lib -ltclstub8.6
: libnsf2.0.0.so
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -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_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
-DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
-DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
-I"/root/tcl-src-fossil/generic" -I"/root/tcl-src-fossil/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfStubLib.c` -o nsfStubLib.o
rm -f libnsfstub2.0.0.a
ar cr libnsfstub2.0.0.a nsfStubLib.o
ranlib libnsfstub2.0.0.a
TclStackFree: incorrect freePtr (0x8bb1e78 != 0x8bb2000). Call out of sequence?
make: *** [libraries-pkgindex] Aborted

###############################


Thanks

Re: [Xotcl] Loading XOTcl crashes

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

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Wed, 13 Jun 2012 11:24:41 -0700

Node answered. I believe this was fixed a few months ago, but you'd
need to be on nightly updates to get it.

On 13/06/2012 8:35 AM, Kurt Stoll wrote:
>
> 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] new doesnt check for existing object handle.

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

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 15 Apr 2005 18:30:51 -0400

Hi Gustaf,

Have you fixed or considered fixing this issue? I see this in 1.3.6.
Is there a way
to set the beginning handle number?

>xotclsh
% Object ::xotcl::__#0
::xotcl::__#0
% Object new
::xotcl::__#0
%


Thanks,

Ben

Next Page