Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 10 Apr 2004 21:27:40 +0200

On Friday 09 April 2004 17:05, Jim Lynch wrote:
> Hi,
>
> Subject says it all (xowish always generated even if --without-tk)...
>
> Can't fix today.

 can it be that you reconfigured you system with out a make clean etc.?
 can you show me your configure line? can it be that you are trying
 to combine a --without-tk with a
   - with --with-all or
   - with --with-xowish
 ?
 well, although i believe that it is not of cruical importance to support
 configure lines like ./configure .... --with-xowish ... --without-tk
 i have added a small fix to my development version to support it.

 -gustaf
PS: i can sand you later my configure.in file for getting in sync.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 29 Oct 2010 09:56:23 +0200

Dear victor,

There is a difference/asymmetry between
"namespace path" and "namespace import"

* "namespace import" creates cmd-stubs in the actual namespace
    (if issued on "::", in the top-level namespace). The
default rule
    for function resolving checks the contents of the top-level
    namespace as a final resort.

* "namespace path" adds a searchpath to the current namespace,
    but this is apparently not used as "final resort rule".

Look at the following test script, which is pure tcl:
  - the namespace ::tst contains two procs, f-1 is
     namespace-imported to top, f-2 not (just
     namespace-pathed).
   - Both are seen by a toplevel "info command",
     both can be executed on top.
   - in the ::app-namespace, we have no
     namespace path. We can call f-1, but not f-2

===================================
namespace eval ::tst {
   proc f-1 {} { return f-1 }
   proc f-2 {} { return f-2 }
   namespace export f-1 f-2
}

namespace path tst
namespace import tst::f-1
puts f-1=[namespace which f-1]
puts f-2=[namespace which f-2]
puts "we see: [info command f-*]"

namespace eval ::app {
   proc foo {} {
     puts [namespace current]//[namespace path]
     puts f-1=[namespace which f-1]
     puts f-2=[namespace which f-2]
     f-1
     f-2
   }
}

::app::foo
===================================

Exactly the same happens in "a::b tst", since "::a"
is an object with object-specific methods and
establishes a tcl namespace.

% Object create a
::a
% Object create a::b
::a::b
% a public method tst args {puts [self]};
::a::tst
% a::b public method tst args {puts [self]};
::a::b::tst
% a tst
::a
% a::b tst
::a::b
%

One could add a namespace path to "::a", but
an application writer does most probably not
like to do this. One could automatically mangle
the default namespace paths (or use special
resolvers) from nx/xotcl, but that could as well
lead to surprising behavior....

Hope, this explains the observed behavior...

-gustaf neumann
PS: namespace path came already with tcl 8.5

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 05 Jan 2008 09:24:09 +0100

Kristoffer Lawson schrieb:
> I understand that requirement. That is why I am suggesting you use a
> combination of XOTcl filters and [trace]. It might be that even
> [trace] is enough, if it catches all Tcl command calls (I haven't
> looked at it). If not, have XOTcl filters for the XOTcl stuff and
> [trace] for the rest?
>

one can set enterstep calls on next

   proc CALL args {puts "CALL $args"}
   proc EXIT args {puts "EXIT $args"}
   trace add execution next enterstep CALL
   trace add execution next leavestep EXIT

and maybe add these two traces in the filter once on the first call (e.g.
controlled via a global variable).

Alternatively, one could define a "proc n args {next}", register the traces
on it and use in the filter "set r [n]" instead of "set r [next]". In
this case multiple
filter registrations are not a problem.

It is as well possible to register enterstep on the object/class names,
   trace add execution b1 enterstep CALL
   trace add execution b1 leavestep EXIT
but there you might get as well too much output.

-gustaf neumann
> / http://www.scred.com/
> / http://www.fishpool.com/~setok/
>
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 5 Jan 2012 13:15:28 -0800

Hello Gustaf,
Is it possible to have an alias to ensemble or multi-word commands? Example:

Obj public alias string_length "::string length"
      or
Obj public alias "string length" "::string length"

Thanks

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 27 Jul 2012 12:32:20 +0200

On 26.07.12 21:34, Rene Zaumseil wrote:
> 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.

Short feedback (being a win-dummy).

- i installed win7 in a vbox

- downloaded mingw+msys via
http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/
   (the most popular one, newer than what you wrote)

- set up the environment variable to contain path to
mingw/bin and msys/bin

- started a console, but had to write "bash kbs.tcl ..."
instead of "./kbs.tcl ..."
   (maybe one one setup required)

- got an error that wget is not installed;
   installed wget, added GnuWin32/bin to the path

The compilation of tcl ran into the following problem (the
fetched tcl version is 8.5.11).
Does one have to install the "20110211" version of mingw? is
there a configure problem
on win7?

-gn


Y:\win\kbs\MINGW32_NT-6.1\tcl>make
gcc -c -O2 -fomit-frame-pointer -Wall -I"../../sources/tcl8.5/win/../generic" -DTCL_TOMMATH -DMP_PREC=4 -I"../../sources/tcl8.5/win/../libtommath"
-I"../../sources/tcl8.5/win" -pipe -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\"
-DSTDC_HEADERS=1 -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DHAVE_WINNT_IGNORE_VOID=1 -DHAVE_ALLOCA_GCC_INLINE=1 -DHAVE_CAST_TO_UNION=1 -DHAVE_NO_STRUCT_STAT32I64=1 -DTCL_CFGVAL_ENCODING=\"cp1252\" -DSTATIC_BUILD=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_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DBUILD_tcl "../../sources/tcl8.5/win/../generic/regcomp.c" -o regcomp.o
In file included from ../../sources/tcl8.5/win/../generic/regguts.h:36:0,
                  from ../../sources/tcl8.5/win/../generic/regcomp.c:33:
../../sources/tcl8.5/win/../generic/regcustom.h:33:20: error: ../../sources/tcl8.5/win/../generic/tclInt.h: Invalid argument
../../sources/tcl8.5/win/../generic/regcustom.h:93:1: error: unknown type name 'Tcl_UniChar'
In file included from ../../sources/tcl8.5/win/../generic/regcustom.h:161:0,
                  from ../../sources/tcl8.5/win/../generic/regguts.h:36,
                  from ../../sources/tcl8.5/win/../generic/regcomp.c:33:
../../sources/tcl8.5/win/../generic/regex.h:138:1: error: unknown type name 'VOID'
../../sources/tcl8.5/win/../generic/regex.h:160:5: error: unknown type name 'size_t'
../../sources/tcl8.5/win/../generic/regex.h:298:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'

From: Bernard Devlin <bdrunrev_at_gmail.com>
Date: Mon, 22 Dec 2008 19:41:11 +0000

Hi, First of all I'm new to Tcl. I've been reading around it for the past
10 days or so, and I like it very much. I saw there were lots of OO
implementations on top of it, which is kind of mind-blowing when one is used
to languages that have 'the-one-true-way' to do OO.

In the languages I've learned in the past quite often OO just seemed to get
in the way. However, I've finally got to the point in my programming
development where I'm feeling restricted by languages like Python and Java.
 Hence my delight at re-discovering Tcl for myself.

When I did a quick survey of the OO implementations in Tcl, I was
immediately drawn to OTcl, and then disappointed to see it hadn't been
enhanced over the last decade. Until I discovered XOTcl :-) This seems to
me to be the most power OO system I've looked at - as powerful as Smalltalk,
only for me Tcl is a more amenable language.

I'm using Artur's 0.83 image of XOTclIDE (which has XOTcl 1.6 bundled inside
it). Of course, I'm really enjoying Artur's IDE. I finally feel like I've
got the right combination of language and toolset to extend my programming
ability. I am so grateful that XOTcl and the IDE have been made publicly
available.

However, following the main XOTcl tutorial (
http://media.wu-wien.ac.at/doc/tutorial.html) in the IDE, I've got a
problem. After running 'do it' on each stage of the tutorial, when I get to
this line:

set fb [bayernMunich newPlayer -name "Franz Beckenbauer" \
  -playerRole PLAYER]

I get an error. Here's the stack trace:

::bayernMunich::__#WZ: unable to dispatch method 'name' during
'::bayernMunich::__#WZ name'
  ::bayernMunich::__#WZ ::xotcl::Object->configure
  ::Player ::xotcl::Class->create
  ::Player ::xotcl::Class->new
  invoked from within
"Player new -childof ::bayernMunich -name {Franz Beckenbauer} -playerRole
PLAYER"
  ("eval" body line 1)
  invoked from within
"eval Player new -childof [self] $args"
  (procedure "newPlayer" line 5)
  ::bayernMunich ::SoccerTeam->newPlayer
  invoked from within
"bayernMunich newPlayer -name "Franz Beckenbauer" \
  -playerRole PLAYER"
  (in namespace eval "::" script line 1)
  invoked from within
"namespace eval :: $string"
  (procedure "evalString" line 3)
  ::IDE::System->evalString
  invoked from within
"IDE::System evalString $string"
  (procedure "evalString" line 3)
  ::xotcl::__#HM::_at_editor ::IDE::Editor->evalString
  invoked from within
"my evalString $sel"
  (procedure "evalSelection" line 5)
  ::xotcl::__#HM::_at_editor ::IDE::Editor->evalSelection
  invoked from within
"::xotcl::__#HM::_at_editor evalSelection"
  invoked from within
".workspace1.#workspace1#mb.#workspace1#mb#menu8 invoke active"
  ("uplevel" body line 1)
  invoked from within
"uplevel #0 [list $w invoke active]"
  (procedure "tk::MenuInvoke" line 50)
  invoked from within
"tk::MenuInvoke .workspace1.#workspace1#mb.#workspace1#mb#menu8 1"
  (command bound to event)

I'm not sure if this is because XOTcl has changed since the tutorial was
written, or if it is because I'm just running through the tutorial in the
workspace.

Regards, Bernard

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 4 Mar 2002 13:36:43 +0100

On Monday 04 March 2002 12:15, you wrote:
> In file xotcl.c:
>
> static int
> XOTclCNewMethod(ClientData cd, Tcl_Interp* in, int objc, Tcl_Obj *objv[]) {
> DEFINE_NEW_TCL_OBJECTS_ON_STACK(objc+1, ov);
...
>
> /* ^^^^^^ */
>
> Should read:
>
> DEFINE_NEW_TCL_OBJECTS_ON_STACK(objc+2, ov);

 zoran, thank you. this bug is confirmed and fixed.
-gustaf

From: Luc Rasson <luc_rasson_at_yahoo.com>
Date: Mon, 20 Aug 2007 11:39:18 -0700 (PDT)

Hi,

I've noticed that the xotcl distribution in activetcl differs from the one provided on the xotcl site (let say xotcl-1.5.3.tar.gz)

So, for example, the "library" directory is missing ... And, if you try something like "package require xotcl::store::persistence
 " (as you can see in the http://media.wu-wien.ac.at/doc/library/store/persistenceExample.xotcl example) that doesn't work (file missing) ... that's a real gap because as OO programmers we all know how persistence is closely related to the OO world (and not only).
 I've asked why to the activetcl team but they say they just build the xotcl distribution you gave to them. Maybe you provided to them a specific Makefile, or maybe is this one corrupt/incomplete ?

So my question is what appened, and obviously what can I do to integrate the full ("official" ?) xotcl distribution to my existing activetcl installation ? (runs on windows) ?

Thanks,
LR

       
---------------------------------
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 7 Oct 2010 19:06:35 -0700 (PDT)

Is there any need to submit bug reports for XOTcl/Next at this stage of development?

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 5 Oct 2006 16:29:14 +0300

On 5 Oct 2006, at 02:07, Gustaf Neumann wrote:

For what it's worth, I definitely think the two-levelled approach
makes sense. Get as dynamic a core as possible, which will benefit
all extensions, then build stuff on top of it. However, I also think
there should be a simple and powerful user-level OO facility packaged
with the core distribution, so there is at least one that is always
there. The best is if both happen at once. I'm right now inclined to
believe a prototype object system could well provide that.

In any case, if your proposal gains some support, as it probably
will, TIP it :-)

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