Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Jan 2003 16:09:02 +0200 (EET)

On Fri, 24 Jan 2003, Uwe Zdun wrote:

> nice idea, I've played a bit with var traces to make some tie functionality
> work; is this what you were thinking of?

Yeah, nice going. Looks like exactly what I had in mind (I reckoned you
could probably do it with Tcl traces). I thinking that I might almost
prefer if [tie] was not an object command as it's not really related to
any specific object (f.ex. using it from outside an object would be
funny). Or what do you think?

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

From: Victor Mayevski <vitick_at_gmail.com>
Date: Sun, 20 Mar 2011 20:09:17 -0700

Hello Gustaf,

I have switched the TCL repository from SourceForge to Fossil, got the
latest sources, compiled and installed TCL. The problem now is that NX
will not compile against it.
Make fails with this error:

########################################################################################
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
./generic/nsf.c: In function ‘MethodDispatchCsc’:
./generic/nsf.c:7797: error: ‘TEOV_callback’ undeclared (first use in
this function)
./generic/nsf.c:7797: error: (Each undeclared identifier is reported only once
./generic/nsf.c:7797: error: for each function it appears in.)
./generic/nsf.c:7797: error: ‘rootPtr’ undeclared (first use in this function)
./generic/nsf.c: In function ‘DispatchDestroyMethod’:
./generic/nsf.c:8503: warning: too many arguments for format
make: *** [nsf.o] Error 1
###################################################################################



If I uncomment "#define NRE_SANE_PATCH 1", as I had to do every time I
compiled NX, the error is even longer, I will just give the first few
lines:

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

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
In file included from ./generic/nsf.c:45:
./generic/nsfInt.h:725: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘NRE_SANE_PATCH’
./generic/nsfInt.h:792: warning: data definition has no type or storage class
./generic/nsfInt.h:792: warning: type defaults to ‘int’ in declaration
of ‘NsfRuntimeState’
./generic/nsf.c: In function ‘NsfLog’:
./generic/nsf.c:362: error: expected expression before ‘)’ token
In file included from ./generic/nsf.c:629:
./generic/nsfStack.c: In function ‘CscListAdd’:
./generic/nsfStack.c:21: error: expected expression before ‘)’ token
./generic/nsfStack.c: In function ‘CscListRemove’:
./generic/nsfStack.c:42: error: expected expression before ‘)’ token
./generic/nsfStack.c: In function ‘Nsf_PushFrameObj’:
./generic/nsfStack.c:144: error: expected expression before ‘)’ token
./generic/nsfStack.c: In function ‘Nsf_PushFrameCsc’:
./generic/nsfStack.c:187: error: expected expression before ‘)’ token
./generic/nsfStack.c: In function ‘CallStackPopAll’:
########################################################################################

I am on Debian based Linux, 32bit.

Thanks,

Victor

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 04 Jan 2008 13:56:31 +0100

Dear Florian,

tcl var-traces and copy/move operations is a hairy issue.
You are right, the the current behavior on the issue
is a bug. I can't currently look into the details (i am on vacation
in a small place in the alps until Jan 6), but my guess is that
the behavior was introduced by the changes due to
VarReform.

Use the following fix in the meantime, until i have
more time to look into the details (insert this code before
the first copy).

best regards
-gustaf neumann

Class PreserveVarTraces
PreserveVarTraces instproc copy {obj dest} {
  set traces ""
  foreach v [$obj info vars] {
    set t [$obj trace info variable $v]
    if {$t ne ""} {
      foreach ops $t {
    foreach {op cmd} $ops break
    append traces [list $obj trace add variable $v $op $cmd] "\n"
      }
    }
  }
  set r [next]
  eval $traces
  return $r
}
::xotcl::Object::CopyHandler instmixin add PreserveVarTraces

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 16 May 2002 21:15:34 +0200

On Thursday 16 May 2002 15:16, Rick Hedin wrote:
> Hello. My friends are trying to convince me of the value of functional
> programming. Writing safer and clearer programs sounds good, but I am not
> inclined to learn Haskell.
>
> Xotcl is a pretty flexible beast. Can I do functional programming in it?
> It seems as though classes are a variety of object in Xotcl, so that will
> be an advantage for passing classes around, but what else am I missing? I
> suspect that Gustaf and Uwe thought about functional programming when they
> designed their beast. Can I find out what their thoughts were?

 hi rick,

 nobody can find out today, what their thoughts really were :)

 there is no exact answer to your question, here are some
 random thoughts...

 well, functional programming is quite different in principle
 from oo programming which is in turn quite different to say
 logic programming. it's not a matter of "power" or "flexibilty",
 it's a matter, how the matter how one like to think about
 a certain problem area and what are the primary things of
 concern ... well in theory. in practice, many of the pure
 concepts are sometimes less important.

    oo: think in things, classify things, encapsulate state,
        reuse code, build systems

    functional programming: think in expressions, purists say that
        variables are not needed, support powerful nice things
        with funny names like "list comprehensions", "monads" etc.

    logic programming: think in logic, expressing relations between
        things (like grammars), express "truth", don't focus on
        program flow, try theories
 
 you can certainly program in a functional programming style
 in Tcl or XOTcl, but it does not make this necessarily a functional
 language. The much rumored "feather" project much more support
 in this direction.

 i am a friend of varieties: use the right tool for the right
 task. There are many projects that i would start today in
 e.g. C, some other in Prolog/clp(R), some in Java or whatever,
 but most in xotcl (but i am certainly not objective).

 There is no way, we could port all nice features of all
 programming languages to xotcl, and if we would, i am not
 sure whether i would like the result. xotcl is a theme,
 a way, we proceed. There are certainly other ways as well,
 and many of these will be better suited for certain tasks.

 i would say, listen to your friends, look into haskell,
 make your own opinion, how you would like to solve your
 programming tasks, this will help you to make well-founded
 decisions.

 I have never used Haskell for anything real. The next best
 was APL where i have written various programs; it was
 quite fun, but i a got the somewhat wrong impression
 what computers are for (i thought a computer is primarily
 is a big, powerful calculator). Today i would say that it is
 more important to use a computer to build systems. For this
 task, oo is quite ok, i would say....

 hope this helps a little to make your mind up.

 greetings
-gustaf
 

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 16 Nov 2004 00:44:26 +0100

On Monday 15 November 2004 18:51, MichaelL_at_frogware.com wrote:
> Ok, I've found a temporary workaround using
>
> TestB create ::b -x 5
>
> rather than
>
> TestB ::b -x 5
>
> Still, why doesn't the second approach work?

 XOTcl used XOTCL_UNKNOWN to flag the situation, where
 a filter catches an unknown call, such that the dispatcher
 knows when to call "unknown" in the presence of filters.

 i have changed the internal communication from the tcl
 return code to an internal flag. XOTCL_UNKNOWN is
 gone, both of the above examples do work now (i.e.
 will work in the forthcoming version).

 With Zoran's help with the wonderful purify, i fixed over the
 weekend an old bug showing up in the new extended regression
 test (access to freed memory), so the biggest blocker of
 the new release is gone. we should check, how to deal
 with the recent glitches showing up here...

-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 9 May 2001 03:13:27 +0300 (EEST)

Just wanted to note a change I noticed from 0.83->0.84 which doesn't seem
to be in the changes file? It's to do with abstract methods and code like
the following:

Class Foo
Foo abstract instproc blah {}

Class Bar -superclass Foo
Bar instproc instproc blah {
  puts "blah"
  next
}

With 0.83 this worked but it gives an error about an abstract method
being called in 0.84. The reason the "next" is there in the first place is
basically because if someone decides to add a class to the chain after Bar
then the "next" commands will already be in place. Are there other
arguments for/against the 0.84 model?

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Mon, 25 Nov 2002 11:43:40 +0100

Hi Michael,

I've fixed recently a bug in which the same error message was reported, but
there the xotcl lib was found correctly. perhaps you've encountered the same
problem. Can you test this version please:

  http://wi.wu-wien.ac.at/~uzdun/xotcl-full-1.0-win-tcl8.4.1.zip

and report your experiences? If it does not work, can you also test, whether
XOTcl is loaded or not:

% xotclsh
...
> ::xotcl::Object o

does this work (should not say "unknown command").


Thanks,

Uwe



On Monday 25 November 2002 03:01 am, Michael Schlenker wrote:
> Hi,
>
> i tried to use tclkit (8.4.1, windows) with XOTcl 1.0 and always get the
> annoying error message:
> "Cannot locate the XOTcl library on your system!"
>
> when i try to [package require xotcl] in tclkit.
>
> I read the source code, where the message seems to be generated and
> found that it is produced by some code that tries to modify the
> auto_path on loading of the xotcl**.dll. This seems to fail when loaded
> as a dll.
>
> What has to be done to get rid of the error message and to get the
> library found?
>
> At the moment i do:
> lappend auto_path [file join $xotcl-dir library]
>
> This seems to work, if xotcl-dir is set to the lib dir used by XOTcl.
>
> Other than those minor problems, are there any known problems using
> XOTcl 1.0 with Tclkit?
>
> Michael Schlenker
>
>
>
> _______________________________________________
> 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_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Matthew Smith <chedderslam_at_gmail.com>
Date: Wed, 7 May 2008 13:25:02 -0500

How do I call the methods like push and pop?

Thank you.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 14 Oct 2010 03:56:00 +0200

  Hi Victor,

our typical test setup is to run the regression test with
8.5.9, tcl 8.6b1,
and with 8.6head version (where i have applied the
SANE-NRE-patch
from Miguel). i just double-checked, for me all three test
settings
work fine.

does the regression work on your installation with tcl 8.6b4
(run: make test)?
If they run fine, and you experience a crash with your
application,
the following works probably best:

Strategy a: try to isolate and pinpoint the problem from the
tcl layer
    by simplifying your script. if the problem can be
reproduced with
    a few lines of code, send it to me.

Strategy b: mostly for c-literate developers: use gdb.

   - compile tcl and nsf with -g enabled (e.g. add it to
     the compile flags in the Makefile and recompile with
     "make clean" and "make")

   - start the tcl shell under gdb, like e.g.
        gdb /usr/local/src/tcl8.5.9/unix/tclsh

   - start your application from gdb using
        run ..../yourapp.tcl

   - when it crashes, type in
        where
     an you will get the backtrace.
     maybe what you see makes sense to you.
     if not, send it to me, i'll try me best on it.

all the best
-gustaf

On 14.10.10 00:33, Victor Mayevski wrote:
> I have just tried my application on latest TCL 8.6b4 and it crashes (Segmentation fault). The same application works just fine in TCL 8.5.9. Any idea how I can troubleshoot it? Tools, techniques etc?
>
> Thank you
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Wed, 10 Oct 2001 10:27:14 +0200

Hi,

from 0.9 on we will execute in the calling namespace instead of the object
namespace. The "downside" is that you cannot do

 TestA instproc fooB {} {
   fooC
 }

anymore because you do not execute in TestA's namespace. The benefits are:

- you don't have to write :: to access global commands (e.g.
  if you want to ::set something in an instproc of ::Object).
- you can "compose" commands, like
  X instproc myli c {
    [em [li $c]]
    p
  }
- Thus, if you always have to use self, the problem below disappears.
  Without this we would not be able to provide the same debug infos because
  we have no control over the tcl command dispatch mechanism

However, the second problem you mention (with [[self] next])
is still there. We have discussed this and think that we should forbid [self]
next as well, so that next calls are never dispatched as method calls. This
seems to be a cleaner language design (since [self] next is rather for
backwards compatibility and as we are approaching version 1.0 we should
better get rid of it).

--uwe


On Saturday 06 October 2001 02:24 pm, you wrote:
> Hallo
>
> For XotclIDE I have built a Error Stack browser witch can parse
> error messages (in errorInfo) a convert it to methods list.
>
> I have following problem. Consider the example
>
> Class TestA
> TestA instproc fooA {} {
> [self] fooC
> }
> TestA instproc fooB {} {
> fooC
> }
> TestA instproc fooC {} {
> error {error from fooC}
> }
>
> TestA a
> a fooA
>
> generate following errorInfo
> error from fooC
> while executing
> "error {error hier}"
> (procedure "fooC" line 2)
>
> ::sample0 ::TestA->fooC
>
> invoked from within
> "[self] fooC"
> (procedure "fooA" line 2)
>
> ::sample0 ::TestA->fooA
>
> invoked from within
>
> a fooB # generate following message
>
> error from fooC
> while executing
> "error {error hier}"
> (procedure "fooC" line 2)
> invoked from within
> "fooC"
> (procedure "fooB" line 2)
>
> ::sample0 ::TestA->fooB
>
> invoked from within
>
> I the first example we have the lines
> (procedure "fooC" line 2)
>
> ::sample0 ::TestA->fooC
>
> This can be good used for parsing errorInfo
> I the second there are only
> (procedure "fooC" line 2)
> The same bahavior is by method chains with "next" or filter methods.
>
> Can the xotcl be changed for same dubug infos?
>
> Artur Trzewik
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Institute for Computer Science, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de