Weblog Page

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 25 May 2012 12:19:51 +0200

> as far as I can see, nx is currently missing any methods to introspect
> class level methods. (I know there is info lookup, but that's not exactly
> what I want to do).
one can use "/cls/ class info methods" to introspect class
level methods.
See e.g.

http://next-scripting.org/docs/2.0b3/doc/nx/nx-migration/index1#_introspection
> Also, as classes can be treated as objects, it's confusing that that
> calling `MyClass info methods` returns the instance methods of the class,
> whereas `$my_object info methods` returns the objects callable methods.
keep in mind, that "method" is used to create either class
level methods (available
for instances of the class) and object level methods
(available for objects).
Object level methods are defined by

     /obj/ method foo args {....}
     /cls/ class method bar args {....}

The latter one defines "bar" as a method of the class object.

"/obj/ info methods" returns always the methods defined by
the entity, where as
"/obj/ info lookup methods ..." returns the methods callable
by the obj (consumer side).

all the best
-gustaf neumann

From: Kristoffer Lawson <setok_at_scred.com>
Date: Mon, 12 Jul 2010 12:08:29 +0300

On 10 Jul 2010, at 09:38, Gustaf Neumann wrote:

> I am somewhat confused by your terminology. If you are looking for
> access control management,
> look for example at xoRBAC, which follows the role based access control
> model, standardized
> by the NIST
> http://wi.wu-wien.ac.at:8002/home/mark/xoRBAC/index.html

Thanks, Gustaf, for bringing this up. I'll be looking at this.

> the basic notion in access control is based on <subject> <pred> <object>
> idea,
> which subject (individual, user) is allowed to execute which operations
> (pred)
> on which objects.

Yes, I am aware of this, if only on a vague level (having so far avoided the need). As this is all to do with describing, in a web framework, which users are allowed to do what, on the lowest level, this may be overkill. But maybe not.

At the moment I've been experimenting with the idea, stolen from UNIX file permissions, that each object has an owner and a group — both of which are optional. Each object has a set of easy UNIX style permissions, but with the additional concept of a 'friend'. So rwxrwxrwxrwx

That is to say what kind of permissions the user has, the user's friends (if defined), members of the group the object belongs to, and other users.

Each method for the object can be defined to be a read, a write or an 'execute' method (like "Send Email"). The system checks the currently logged in user, the method being called, and the access that user has. Later ACLs could be added.

There may be serious drawbacks with this idea, as I'm just experimenting, but it feels appealingly simple. The benefit of simplicity is that then it is almost no effort to specify a base level of access. That means people actually bother doing it, which then leads to better security :-)

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 08 May 2006 23:46:23 +0200

Scott Gargash schrieb:
>
> Is this documented somewhere? It surprised me.
>
in the source (joke).
>
>
> > PS: wouln't be conditional mixins a solution for your problem?
>
> I don't know. What do you mean by "conditional mixin"?
>
mixins with guards. see following example. -gustaf


  Class Fly -instproc fly {} {puts "[my signature]: yippee, fly like an
eagle!"}
  Class Sing -instproc sing {} {puts "[my signature]: what a difference
a day make"}

  Class Animal -parameter age
  Animal instproc unknown args { puts "[my signature]: how should i $args?"}
  Animal instproc signature {} { return "[self] [my info class] ([my
age] years)" }

  Class Bird -superclass Animal
  Class Penguine -superclass Bird
  Class Parrot -superclass Bird
  Class Duck -superclass Bird

  Parrot tweedy -age 1
  Penguine pingo -age 5
  Duck donald -age 4
  Parrot lora -age 6

  Bird instmixin {{Fly -guard {[my age]>2 && ![my istype Penguine]}} Sing}
  foreach bird [Animal allinstances] { $bird fly }

> Scott
>

From: Laurent Duperval <laurent.duperval_at_netergynet.com>
Date: Mon, 11 Dec 2000 14:49:52 -0500 (EST)

Hi,

Thanks for all the answers to my questions. I'll read and digest them and
take it from there.

L

-- 
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK
Laurent Duperval                   "Montreal winters are an intelligence test,
Netergy Networks - Java Center            and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:laurent.duperval_at_netergynet.com           Penguin Power!

From: Michael Schlenker <schlenk_at_uni-oldenburg.de>
Date: Thu, 23 Feb 2006 16:56:26 +0100

Hi all,

i tried wrapping the ::struct::queue datastructure from Tcllib with a
simple XOTcl wrapper, but I'm unsure if there is a better way to setup
the instforwarder, it looks too complex to be really the best solution.


package require XOTcl
namespace import ::xotcl::*
package require struct::queue
Class Queue
Queue instproc init {args} {
        next
        ::struct::queue [self]::queue
}
Queue instforward clear eval {[self]::queue} clear
Queue instforward get eval {[self]::queue} get
Queue instforward peek eval {[self]::queue} peek
Queue instforward put eval {[self]::queue} put
Queue instforward unget eval {[self]::queue} unget
Queue instforward size eval {[self]::queue} size
Queue instproc destroy {args} {
        queue destroy
        next
}

Any hints on how to do this in a nicer way?

Michael

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 20 Jul 2006 19:59:04 +0200

Kristoffer Lawson schrieb:
> In the online reference manual, the volatile method is documented
> under Class, meaning it would be a class procedure.
Kristoffer, you right this is a documentation bug

> In a similar vein, can [volatile] be called at any point, not just
> during object instantiation? I might be getting an object returned
> from somewhere else and, in that proc, I may want to make it volatile
> so as to not have to worry about the point of destruction.
right. volatile is an ordinary method, causing the object to be
destroyed, when the current
variable context is left. The following script ...

---------------------------------------------------------
Class C -instproc destroy {} {puts "destroying [self]"; next}
C c1

proc f {} {
  c1 volatile
}

puts ====
f
puts ====
---------------------------------------------------------

... outputs:

====
destroying ::c1
====

-gustaf

>
> / 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: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 7 May 2003 15:32:31 +0300 (EEST)

I've been running this idea about a Tcl party on c.l.t and I decided to
post it here too, in case someone missed it. The plan would be to get a
cool venue here in Finland and have a real proper code party (in the
demoscene sense) for about 3 days. These are nothing like normal user
meetings or conferences. The events are 24h/day (although naturally you
can sleep if you want) and the focus is on the compos. Compos allow you to
show off your skills, creativity and ideas to the audience and have them
vote on the best for prizes. Some competition ideas:

- Tcl game

- Useless extension

- Demo competition (multimedia presentation)

- Real-time coding competition.

- Obfuscated Tcl

- ...

In addition an important part is meeting and hanging out with people from
all round. It's difficult to beat the feeling when people are crowded
together, hacking away at some really cool ideas with the deadline
looming... If the place was appropriate, and I think I could manage it,
we could fry sausages and drink the odd beer, plus enjoy a good sauna and
swim. Accommodation is free -- often people camp inside the party place --
but youc an stay in a hotel too if that's your preference.

I haven't got much in the way of a positive response to this idea -- not
quite sure why -- but at least 'Stonekeeper' from IRC described the idea
as "very tempting", so I haven't quite given up yet. I myself am very
excited by the idea so please, if this sounds at all like something you
might be interested in, give me a shout so I don't give up hope entirely.

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

From: Mark Strembeck <strembeck_at_acm.org>
Date: Tue, 26 Apr 2011 15:09:31 +0200

Hi Victor,

in case you like to give it a try: version 0.5 of the basic STORM test
environment (including a small example written by Stefan) can be
downloaded from the following URL:
http://wi.wu.ac.at/home/mark/STORM/storm-v.0.5.tar.gz
or
http://wi.wu.ac.at/home/mark/STORM/storm%2dv%2e0%2e5%2etar%2egz

best regards,

Mark


On Tuesday 26 April 2011 12:40:14 Stefan Sobernig wrote:
> Victor,
>
> > I am beginning to learn and use test driven development in my
> > projects. I've noticed that NX does not use the standard "tcltest"
> > package in Tcl but instead provides it's own "nx::test". Is there a
> > specific reason for that?
>
> I can't give you the full story, only some observations of mine. To some
> extent, nx::test and especially its predecessors (xotcl::test) are a legacy:
>
> OTcl had its own testing environment, not using or not building upon
> tcltest, and so had XOTcl; see e.g.
> http://otcl-tclcl.cvs.sourceforge.net/viewvc/otcl-tclcl/otcl/lib/test.tcl?view=markup
>
> test migration vs. test continuity so is the issue here. also: nx::test
> & friends have always been used to test core functionality of the
> language system, rather than application testing. for your XOTcl/nx
> application, tcltest is certainly a viable option (coming with nice
> helpers actually missing in nx::test). another answer along these lines
> is probably that a home-brewed testing evironment is usually one of the
> first prototype applications written by the language authors in their
> language.
>
> as for application testing, however, an object-aware testing environment
> comes handy; you can refine your test suites occasionally through
> mixins; or nx::test traces object lifecycles during test execution to
> maintain a prestine testing sandbox to avoid unwanted test interactions.
> however, that does not mean that you could not realise all of this using
> tcltest.
>
> some further pointers, especially when it comes to TDD (which is, by the
> way, something different than merely writing and executing tests in the
> sense of tcltest or nx::test):
>
> Two or three years ago, I had a look at a xUnit framework for XOTcl:
> http://xotcllib.cvs.sourceforge.net/viewvc/xotcllib/xounit/
>
> While it gave me a xUnit environment, it found it incomplete and its
> implementation rather clumsy (including its usage of Exception objects
> ontop of Tcl's error control flow mechanism).
>
> More recently, Mark published on a scenario-driven approach and
> prototype framework (STORM) which I successfully used in one or two dev
> projects of mine. It comes with essentials concepts for applying a
> test-first development approach:
>
> http://wi.wu-wien.ac.at/home/mark/publications/se2011-extended.pdf
>
> I don't know whether the prototype implementation (the XOTcl script) is
> publicly available, but you could most certainly talk Mark into
> providing it to you :)
>
> //stefan
>
>
>
>
>
>
>
>
>
>
> >
> > Thanks,
> >
> > Victor
> > _______________________________________________
> > Xotcl mailing list
> > Xotcl_at_alice.wu-wien.ac.at
> > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
> >
>
>
>

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Sun, 04 Jan 2004 10:28:29 +0100

Artur Trzewik wrote:
> >
> > It seems that I have subscribed to this problem :-)
> > This time it is on a debian/linux (an old one) where xotcl 1.0.2
> > was successfully compiled (although make test hangs, I don't know why).
> >
> > It's the same symptom:
> > A Tk window built by a command either is correctly displayed if the
> > command is called directly from the "wish", or causes a seg fault if the
> > command is called from a Tk menu.
> > I have compiled xotcl/tcl/tk/itk/itcl with --enable-symbols
> > (I haven't recompiled other libraries such as blt though). Unfortunately,
> > my gdb is broken - but since the symptom is the same, here is the report
> >
> > of gdb for the last time it happended (it was tcl 8.3 and now it is 8.4):
> > > #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 ()
> >
> > So, if anyone has an idea of why this happens everytime I reinstall
> > xotcl... :-(
> >
>
> The same stack dump I have got with 1.1.1.
> I used also callbacks from Tk.
> I could find out that it crashed in context of additional instmixinst but onl
      y
> by 1.1.1
> Herr Neumann send me pre realease of 1.1.2 with some explanation.
> In Version 1.1.1 the insmixins treads the frame in same way as filters in pre
       
> 1.1.1.
> With 1.1.2 it do not crash any more but I do not know if the problem was fixed
> or the instmixinst works as in 1.0.2.
>
> Do you use filters in context of Tk callback?
> If yes, you can try to remove temporary the filters and look if the crash
> happen.
>

No, no filters are active when it happens.

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 14 Sep 2004 14:54:20 +0200

On Monday 06 September 2004 15:51, Kristoffer Lawson wrote:
> [self proc] inside a method that has been called inside an [ob eval] block
> gives the result "eval" inside of the method we're in.

 actually, i do not find it surprising, that "self proc" returns "eval", since
 self proc returns the topmost xotcl-method from the xotcl call stack.
 If one calls the XOTcl "eval" method, it performs the tcl-eval to
 execute (without the xotcl dispatcher) the presented tcl script.
 Therefore the xotcl stack is not aware of the actual tcl commands
 at and returns the topmost method, namely "eval".
 
 It looks to me that you can use [info level 0] instead, which operates
 on the tcl stack.

~/scripts> o proc p {} {puts [self]-p-[info level 0]}
~/scripts> o p
::o-p-p
~/scripts> o eval p
::o-p-p

> In practise this is now causing so many headaches I think I'm going to
> give up on doing this package using XOTcl that way. There appears to be no
> (working?) way to run a script within the 'context' of an object, in order
> to easily parse data which is formed in the style of a Tcl script. This is
> unfortunate as it would likely have offered clear performance benefits.

 If you have some some code, we can look at, we will certainly
 try to help with that.

-gustaf
>
> I may still try to do it directly with normal namespaces instead of XOTcl.
>
> / http://www.fishpool.com/~setok/
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

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