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

Weblog Page

Showing 1221 - 1230 of 1561 Postings (summary)

Re: [Xotcl] Help with Filters. Resubmission.

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

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Mon, 17 Dec 2001 17:40:01 +0100

The problem below is that a filter (like a mixin) is only called if a method
to be dispatched exists for an object ... maa does not exist for A's objects,
therefore, the filter is not called, but unknown is called. The standard
unknown raises the error here. You can test this by adding a custom unknown
to A (of course you can also handle the delegation in unknown):

A instproc unknown args {
  puts "unknown $args --> error"
  next
}


On Saturday 15 December 2001 16:28, Sheik Yussuff wrote:
> Below is nonsensical sample code to illustrate a problem I
> am having with filters. On invocation of:
> a mb (see code section below)
> 1. Object a is sent the message mb(not an instproc) of A
> 2. Filter af of object a intercepts and
> dispatches message mbb to object b
> 3. Filter bf of object b intercepts and
> redispatches message maa to object a
> This time the filter af does not intercept message maa!!
> The message maa is sent directly to object a with
> the resulting error: object a unable to dispatch
> method maa.
>
> Can anyone assist me in explaining what is happening here?
> ------------------------------------------------------------
> #Code: Win 98 version 0.91; got same problem with ver 0.85 3 months ago.
>
> Class A -parameter {delegate}
>
> A instproc af args {
> set method [self calledproc]
> if {[[self] exists delegate]} {
> set del [[self] set delegate]
> if {$method == "maa"} {
> return [eval $del mbb]
> }
> if {$method != "ma"} {
> return [eval $del $method $args]
> }
> }
> next
> }
>
> A instfilter {af}
>
> A instproc ma args {
> puts "method ma of A"
> }
>
>
> Class B
> B instproc bf args {
> set sender [self callingobject]
> set method [self calledproc]
> puts "method is: $method"
> if {$method == "mb"} {
>
> return [eval $sender maa]
> }
> next
> }
>
> B instfilter bf
>
> B instproc mb args {
> puts "method mb of B"
> }
>
> B instproc mbb args {
> puts "method mbb of B"
> }
>
> B b
> A a
> a delegate b
> #a ma ; #works ok
> a mb
>
>
>
> _______________________________________________
> 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

Re: [Xotcl] problem compiling xotcl-0.9.4 on Linux

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

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Sat, 20 Jul 2002 11:40:43 +0200

On Saturday 20 July 2002 11:11, Catherine Letondal wrote:
> Hi,

>
> So, I don't know what to do. Do you have any suggestions?
> Thanks again in advance,

Seems, you like saturdays :)
I'd double-check

  % info commands xotcl::*

If it returns xotcl::Object (among others) then you'd need
to:

  % namespace import xotcl::*

Cheers
Zoran

Re: [Xotcl] NX on windows

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

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Mon, 30 Jul 2012 09:59:01 +0200

The problem with the compile below is very wierd. The key is
in the following line where cpp (the c pre-processor)
complains about an invalid argument

../../sources/tcl8.5/win/../generic/regcustom.h:33:20:
error: ../../sources/tcl8.5/win/../generic/tclInt.h: Invalid
argument

The "invalid argument" is strange, because it does not say
at all, what the problem is (gcc is normally more specific).
This message is a generic error message from c-library. Some
more investigation revealed that the problem has to do with
the size (!!!) of tclInt.h. Shortening it to e.g. 126785
bytes lets cpp process it (but of course, later other
problems occurred). I had the sources on the host and
mounted it from the windows environment in the vbox, and
assigned it to the drive letter "y:".

Copying the full tree to "c:" solved this issue. Very weird.
After digging into tcl's platform specific defines it took
me quite a while to start to distrust cpp. Not sure, whether
this is a bug in cpp, win7 or vbox, but i am posting it here
in the hope, that maybe someone who runs into the same
problem might google it and save some time.

On drive c, compilation of tcl and tk worked perfectly
(tried tcl 8.5.12).

-gustaf neumann



On 27.07.12 12:32, Gustaf Neumann wrote:
>
> 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'
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

Re: [Xotcl] troubleshooting

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

From: Victor Mayevski <vitick_at_gmail.com>
Date: Fri, 26 Nov 2010 19:48:19 -0800

Hello Gustaf,

I have the following problem when trying to compile NX on freshly
installed Linux x86 system against latest TCL 8.6 from SourceForge
CVS.

./generic/nsf.c: In function ‘MethodDispatchCsc’:
./generic/nsf.c:6959: error: too many arguments to function
‘tclIntStubsPtr->tclNRRunCallbacks’
make: *** [nsf.o] Error 1


Thank you

[Xotcl] NX ???

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

From: Luc Rasson <luc_rasson_at_yahoo.com>
Date: Sun, 23 Oct 2011 02:11:50 -0700 (PDT)

Hi all,

Sorry for that stupid question but what is NX ? I know what is XOTcl about (that's why I'm on the so called mailing list ;-) but nothing about NX, and I've made some searchs on the web and nothing at all :-( So please don't let me in the dark ;-)


Oh by the way I have few more questions:
- is it possible to call some functions written in tcl/xotcl from python ? I'm using a lot some great tools (such WikiPad which is simply excellent, try it you will see ! ;-) that can be extended but I'm not sure I want to spend too much time to learn a new language ...
- is there some functions in tcl/xotcl to encode/decode urls ? I don't find such tools in unix what is (for me) obvious (it seems that's possible in perl for example but I dislike perl ;-)
- long time ago I have been talking about the RETE algorithm that is used for example in CLIPS ... My question was about "is there such a thing in tcl/xotcl". Gustaf told me "write it by yourself" ;-) but after a lot of search I didn't find the algorithm itself ... Any issues about that ? (google if you don't know what I'm talking about ... I think that for some applications the Rete is simply genious) ... I know that it what ported in some languages for example java, but what about tcl/xotcl ?

Regards,
L.R.

[Xotcl] European Tcl meeting

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 30 Jan 2001 00:59:08 +0200 (EET)

Is there any plans for an XOTcl presence there? I was thinking of going
and it'd be great to meet the developers and/or users. It might also be
worthwhile presenting some systems people have used XOTcl for, along with
an actual presentation of the project.

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

[Xotcl] RE: [Xotcl] Probable bug: no method calls with "next" & init

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

From: Rick Hedin <rhedin_at_aquifer.geology.uiuc.edu>
Date: Mon, 5 Feb 2001 15:22:02 -0600

Hi Kristoffer.

This behavior seems correct. You are trying to pass three arguments:

        1. myArg 2. -whatever 3. niceSystem

to one formal parameter:

        arg

We could send one argument:

        next {myArg -whatever niceSystem}

or use the special properties of the args keyword:

        Foo instproc init {args} { . . .

Am I looking at this right?


        Regards,

        Rick

-----Original Message-----
From: xotcl-admin_at_alice.wu-wien.ac.at
[mailto:xotcl-admin_at_alice.wu-wien.ac.at]On Behalf Of Kristoffer Lawson
Sent: Monday, February 05, 2001 2:59 PM
To: XOTcl developers
Subject: [Xotcl] Probable bug: no method calls with "next" & init



[~] Class Foo
[~] Foo instproc init {arg} {
puts "arg: $arg"
}
[~] Foo instproc whatever {system} {
puts "sys: $system"
}
[~] Class Bar -superclass Foo
[~] Bar instproc init {} {
next myArg -whatever niceSystem
}
[~] Bar ob
called "next" with too many arguments

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


_______________________________________________
Xotcl mailing list - Xotcl_at_wi.wu-wien.ac.at
http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

Re: [Xotcl] forwarding

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: Tue, 24 Jan 2012 09:01:16 +0100

Dear Victor,

The best approach for forwarding to a child object is either
an alias, or a direct invocation of a subobject through the
method interface. Consider the following code, where we have
an object "obj" and an embedded child object "obj::child".

    nx::Object create obj {

       nx::Object create [self]::child {
       :public method foo {} {return [self]}
     }

     :public alias a [self]::child
     :public forward f [self]::child
    }


One could certainly use as well a forward, but this is
necessary. Technically, objects are Tcl commands, and Tcl
commands and procs reside in a namespace. Therefore, by
creating a child object of obj, one has to create in its
namespace a cmd "child", which is in turn very similar to a
per-object method. Therefore, one cannot define a per-object
method "foo" and a child object "foo" at the same time.

The idiom to use an object as a container for subobject and
delegate to these is quite common in some systems (used
intensively in xotclIDE). In our previous releases of nx,
the semantics of calling of the subobject have changed
relative to XOTcl 1.6 due to the requirements of ensemble
objects. The recent changes reintroduced backwards
compatibility in this respect as well, leading to a probably
more expected behavior in the case above (concerning "self"
in the methods of the subobject). As you can see below the
invocation of the child is the fastest approach.

   ? {obj a foo} {::obj::child}
   ? {obj f foo} {::obj::child}
   ? {obj child foo} {::obj::child}

v/child-obj-delegation.001: 0.71 mms, obj a foo
(overhead 0.62)
v/child-obj-delegation.002: 0.75 mms, obj f foo
(overhead 0.65)
v/child-obj-delegation.003: 0.65 mms, obj child foo
(overhead 0.68)

Note, that this requires the head version of nx (which works
now as well with Tcl version from fossil head); we will tag
a new beta release soon, documentation updates are pending.

In case, one does not want to allow calls of the subobject
via the method interface (3rd case above), one can use
access control ("private" or "protected"). Maybe we add for
nx some more syntactic sugar by allowing something along the
lines of

    nx::Object create obj {

     :public child nx::Object bar {
        :public method foo {} {return [self]}
     }

     :public alias a [self]::child
     :public forward f [self]::child
    }


for creating a child object "obj::bar" with public access.

-gustaf neumann

On 11.01.12 04:06, Victor Mayevski wrote:
> Is it possible to do a forward in the following manner:
>
> obj public forward link %self::child-obj
>
> The best I could do was:
>
> obj public forward link :child-obj
>
> which I have to call in the following way:
> [obj link] mymethod
>
> Also, I don't even know why it works that way, because I think it
> should work this way:
> obj public forward link -objframe :child-obj
> but that does not work.
>
> Thanks
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

Re: [Xotcl] info method behaviour

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

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Sat, 11 Aug 2001 14:31:34 +0200

On Saturday 11 August 2001 00:00, Kristoffer Lawson wrote:
> Situation:
>
> I create a class "C" with instproc "foo".
> An object is created from C called "ob".
>
> Problem:
>
> The commands "ob info procs", "ob info args" and "ob info body" do not
> work as I would expect them to. In particular, there doesn't seem to be a
> way of finding out the body and arguments for the instproc "foo" from the
> object. I could do this by asking the class, but I specifically would
> like a uniform way to do this, without caring whether the methods are
> inherited or not. Is this intended? Why?
>
>

You can do this pretty easy with:

% [ob info class] info instprocs

... and similar.

AFAIK, the "ob info procs|args|body" is ment to be used
with per-object resources (procs), like for example:

% ob proc bar args {puts $args}
% ob info procs
bar
% ob info body bar
puts $args
% ob info args bar
args

If you change the current behaviour, how would you
cover this issue then ?


Regards,
Zoran

[Xotcl] coroutines

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, 1 Sep 2010 22:28:14 -0700 (PDT)

I am wondering if it will be possible to somehow implement coroutines in XOTcl? Is it feasible? Would it be worth it?

Next Page