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

Weblog Page

Showing 1181 - 1190 of 1561 Postings (summary)

Re: [Xotcl] renaming a 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: Tue, 17 Aug 2010 08:28:43 +0200

  On 16.08.10 15:36, Kevin Van Workum wrote:
> How do I rename a Class instproc? For example:
>
> Class T -parameter { {msg "Hello world!"} }
> T instproc hi {} {
> puts [my msg]
> }
> T instparametercmd msg
>
> T t
> t hi
>
> t msg "Good Bye!"
> t rename hi bye
> t bye
there is no "rename" method predefined in xotcl.
i would recommend to implement rename in terms of
introspection (see below). with that, your example
works.
> Also, what's the difference between using "instparametercmd" and
> "parametercmd" in the example above?
The difference between "instparametercmd" and "parametercmd"
is the same as the difference between "instproc" and "proc".
The versions starting with "inst" are defined on the class level
and represent methods for instances of the class. Without
"inst", they are methods on objects (object specific methods).

In your example, you do not need "instparametercmd" (which
defines a c-implemented setter method), since the implementation
of the method "parameter" defines it already.

-gustaf neumann
============================================

Object instproc method-serialize {o m prefix name} {
   set arglist [list]
   foreach v [$o info ${prefix}args $m] {
     if {[$o info ${prefix}default $m $v x]} {
       lappend arglist [list $v $x] } {lappend arglist $v}
   }
   lappend r $o ${prefix}proc $name \
       [concat [$o info ${prefix}nonposargs $m] $arglist] \
       [$o info ${prefix}body $m]
   foreach p {pre post} {
     if {[$o info ${prefix}$p $m] ne ""} {
       lappend r [$o info ${prefix}$p $m]
     }
   }
   return $r
}
Object instproc rename {from to} {
     foreach {obj methtype name} [my procsearch $from] break
     switch $methtype {
       instproc {set newMethod [my method-serialize $obj
$from inst $to]}
       proc {set newMethod [my method-serialize $obj $from
"" $to]}
       default {error "can't rename [my procsearch $from]"}
     }
     $obj $methtype $from "" ""
     eval $newMethod
}

[Xotcl] XOTcl 1.5.4 available

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, 14 Aug 2007 19:49:56 +0200

Announcing XOTcl 1.5.4
*************************

We are pleased to announce the availability of XOTcl 1.5.4.
Originally, this release was planned as a small bug fix release. However,
the total size of the (unified) diff between 1.5.3 and 1.5.4 is more
than 5000 lines, mostly due to the varRefom changes (see first
item below).

Major changes relative to 1.5.4 are:

    * Improved code quality:

      + provided compatibility with Tcl 8.5
          (currently, this requires the verison of Tcl 8.5
         from CVS head, including the changes for VarReform
         (For details, see
http://groups.google.at/group/comp.lang.tcl/browse_frm/thread/bff391a7f1bd8f6c/3f214d088a28ed13?hl=de#3f214d088a28ed13)

      + improved serializer
         (handling var traces for instances variables)

      + several small bug-fixes
          (e.g. fixing empty variable names, error message
          propagation for configure, fixing potential crashes,
          when namespaces are added to objects during
          <object> eval, etc.)

      + improved portablility for more platforms
          (more portable shell tests for e.g. FreeBSD)

      + extended regression test

 For more details about the changes, please consult the ChangeLog and
 documentation.

MORE INFO
  General and more detailed information about XOTcl and its components
  can be found at http://www.xotcl.org

Re: [Xotcl] Permissions framework

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Fri, 9 Jul 2010 19:49:31 +0300

On 9 Jul 2010, at 19:25, Stefan Sobernig wrote:

>> Has anyone done any code or a framework for managing per-class permissions? Basically a way to do rules describing which other objects, or which roles users must have, in order to call the different methods provided by instances of the class (plus any class procs). This is kind of like an expanded approach to Java style simple permissions (private/protected/public), which of course could also be incorporated into that, if wanted.
>
> Nope, speaking for myself, I have never done anything into this direction. (And never really felt the need for doing so.)

I've been using XOTcl since the 0.8 days and this is also the first time I feel the real need for it :-)

I don't believe in doing very fixed Java style public/protected/private stuff, and that wouldn't suffice for this purpose, but looking at something a bit more flexible. Basically I need strong protections in place. I'm playing around with some ideas and for Scred (which is Python :( ) I may end up implementing something, depending on how it works.

> In the upcoming major release, there will be some "access properies" (like the UML2 private, for instance) to manipulate the publicly accessible signature interface of an object whereas these can then still be tweaked (removed or set) through a lower-level API at any time).

Are these really necessary, though? I've never felt even the slightest need for that, and they wouldn't help with what I'm doing anyway. Basically I see the Java access properties as a documentation matter, and should not be seen as a help with security.

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

[Xotcl] Multiple cookies with the Httpd comm module

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Tue, 6 Jul 2010 16:16:58 +0300

Hi, I've been playing around with the XOTcl Httpd module for my web framework, Spindle (http://github.com/Setok/Spindle). When looking through the source it seems there is no support for multiple cookies to the same domain.

OK, there's actually no support for cookies, as such, but the worker does have access to the 'meta' instance variable, which has all the fields of the HTTP request. Unfortunately this does not work with cookies, as I understand them, as they can appear as follows:

Cookie: band=front242;
Cookie: album=Tyranny For You;

In that case the meta variable would only have a single cookie, the latter, set. Am I missing something?

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

[Xotcl] Announcement: Next Scripting Framework 2.0.0 available

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: Thu, 01 Jan 2015 19:36:00 +0100

Dear Community,

Since releasing the Next Scripting Framework (NSF) 2.0b5, we have
received more feedback from early adopters. Many thanks for the
helpful and the constructive comments!

Since the release of 2.0b5, there have been more than 450 commits to
our code repository. The implementation is very stable and has been
used for more than two years in production of our large-scale,
multi-threaded web environment inside NaviServer. Most of the changes
happened in NX and, therefore, on the NSF scripting level, without the
need to modify the NSF C layer. The implementation of XOTcl 2 has
changed very little. The Next Scripting Framework was tested with Tcl
8.5.17 and Tcl 8.6.2 on Linux, Mac OS X, and in Windows enviroments
(MinGW, VC12).

Below are the most notable differences in NSF/NX 2.0 final relative to
2.0b5:

a) Pluralism reform:

    Use plural names for structural features of objects and classes,
    whenever potentially multiple elements are provided or
    returned. This rule applies now consistently throughout NX. Here are
    examples from the introspection interface:

        /cls/ info superclasses
        /cls/ info subclasses
        /cls/ info mixins
        /obj/ info object mixins
        /cls/ info filters
        /obj/ info object filters

    Similarly, there the plural is used for configure options, e.g.:

        nx:create create Foo -superclasses {C D}

    Note that abbreviations are allowed as well:

        nx:create create Foo -superclass {C D}

b) Dispatch by arity is gone in NX.

    XOTcl and earlier versions of NX supported a dispatch-by-arity
    mechanism for relation slots:

        o mixin; # arity 1: get value
        o mixin M1; # arity 2: set value
        o mixin add M1; # arity 3: use arg 2 for slot methods

    The problem with this approach is that it is not straight forward
    to provide meaningful error messages. In addition, one might be
    irritated about the result of e.g. "o mixin add" (leaving out a
    class to be added). In the final release, we removed the entailed
    complexity by relying on a fixed arity of 3 (last form above) for
    the default slot methods:

        add, clear, delete, get, guard, set

c) Support for querying computed parameters of methods.

    Earlier versions of NX had several methods to query the parameters
    for configuring objects of different classes. The configure
    parameters are determined by the inheritance order in the class
    hierarchy and are relevant during object creation (e.g.
    methods "create" or "new").

    Now, these configure parameter can be queried using the standard
    parameter introspection interface for e.g. "new", "create", or
    "configure", such as in:

      nx::Object info lookup parameters create

    The above command call returns the parameters which can be provided
    to an "nx::Object create ..." invocation. Furthermore, these
    computed parameters are returned in error messages.

d) Support abbreviations of non-positional parameter names (for plain
    methods, nsf::proc, or "... configure...").

    To avoid surprises, especially for computed argument lists, the
    minimal number of optional trailing characters is set to 4.

e) Updated MongoDB interface:

    The interface was extended in various ways and is now based on
    mongo-c-driver 1.0.2 and was tested with MongoDB 2.6.5. The driver
    can be used nicely with e.g. Naviserver by using the c-driver
    supported connection pool.

f) API changes:

        nx::Object info lookup parameters create
        /cls/ mixins ...
            /obj/ object mixins ...
            /cls/ filters ...
            /obj/ object filters ...

     Simplified info methods for interceptors:

         /cls/ info mixin classes -> /cls/ info mixins
            /cls/ info filter methods -> /cls/ info filters
            /obj/ info object mixin classes -> /obj/ info object mixins

     Dropped methods:

           /cls/ info mixin guard
            /obj/ info object mixin guard
            /cls/ info filter guard
            /obj/ info object filter guard

     Instead, use the "-guards" option of "... info ?object?
mixins|filters ...".

      Added methods:

            /cls/ mixins classes
         /cls/ filters methods
         /obj/ object filters methods
         /obj/ object mixins classes

g) Added API documentation:

    Using tcllib's doctools markup and dtplite, we now provide manpages
    for:
       nx::Object
       nx::Class
       nx::current
       nx::next
       nx::configure

The Next Scripting Framework 2.0.0 (containing NX and XOTcl 2.0.0) can
be obtained from https://next-scripting.org/

The detailed ChangeLog can be downloaded from
https://next-scripting.org/xowiki/download/file/ChangeLog-2.0b5-2.0.0

Best regards
- Gustaf Neumann
- Stefan Sobernig

Re: [Xotcl] Improvement proposal for instfilters and guards

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: Fri, 30 May 2008 14:34:53 +0200

Dear Eckhard,

Eckhard Lehmann schrieb:
> In 99% of the cases one (I at least) creates a filter that needs to be
> triggered only at a certain method.
The more efficient approach for just intercepting a single method is a
mixin. The purpose of the mixins is intercept one or more known
methods, the strength of the filters is to execpt all methods. This
can be certainly restricted by the guards, but there is a performance
penalty in such cases.
> Class A
> ...
> A instproc do1 {} ...
> A instproc do2 {} ...
> A instproc do3 {} ...
>
> A instproc do1Filter {} ...
>
> # trigger only at do1
> A instfilter do1Filter -methods do1 ;# or -methods {do1 do3}
>
well, note that "instfilter" accepts a list of filters (with potential
guards)

> # rather than
> A instfilter do1Filter
> A instfilterguard do1 {[string eq [self calledproc] do1]}
>
You can define the guard as well at the registraton of a filter, so there is
no need for two separate statements.

A instfilter {
  {do1Filter -guard {[self calledproc] eq "do1"}}
}

It should be possible to create a different front-end in tcl, to provide
more
syntactical sugar and create the guarding expression on the fly:

proc mk_guard args {
  for {set i 0} {$i < [llength $args]} {incr i} {
    if {[lindex $args $i] eq "-methods"} {
      puts stderr M
      incr i
      set clause [list]
      foreach proc_name [lindex $args $i] {
        lappend clause "\[self calledproc\] eq \"$proc_name\""
      }
      lappend guards [join $clause ||]
    }
  }
  return [join $guards &&]
}

The interceptor via mixin could be done like the following

   A instmixin [Class new -instproc do1 args {puts hi; next}]

> Is such a feature already planned? If not, is there anything that speaks
> against it?
>
the major argument against it is not to bloat the language with a subset of
its functionality.

However, can you tell more about your use-cases?

I was thinking a few times about providing interceptors
for single methods, similar to the method combinator :around
in CLOS.

http://www.aiai.ed.ac.uk/~jeff/clos-guide.html

This approach could allow to assign something
like the filter to a single method of a single class.
The advantage would be to no search and testing
to filter away the unwanted filter class, but stick
this to a method. The approach could fit nicely
into the method-slots (in the pipe for 2.0) and
could server as a generalization of the
current pre and post conditions in XOTcl.

-gustaf neumann

[Xotcl] ANN: ttclcheck syntax checker with XOTcl support

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Wed, 20 Mar 2013 20:37:36 +0100

Announcement

ttclcheck (typed Tcl checker) is a new tcl syntax checker that support
object oriented code for XOTcl, ITcl (and Tk). It uses new approach for
type checking of object references.

It is based on checker in XOTclIDE but now it is as a stand alone
application.

http://www.xdobry.de/ttclcheck

ttclchecker can produce nice html site from Tcl source code with
advanced browsing and syntax highlighting.
Look at this
http://www.xdobry.de/ttclcheck/xotclide

It is the first public release. Please send comments and bug reports to me.

Artur

Re: [Xotcl] XOTcl and Tcl 8.6

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

From: Koen Danckaert <koen_at_retarget.com>
Date: Tue, 09 Feb 2010 17:37:02 +0100

Dear Gustaf,

I have seen the slides on XOTcl 2.0 and am looking forward to it :-)
However, in the meantime, I wanted to get an existing version of XOTcl working with Tcl 8.6.

XOTcl 1.6.5 does not work with Tcl 8.6 because it requires a function which is not present in Tcl8.6 anymore: TclObjInterpProcCore().

So I switched back to an earlier version of XOTcl (1.6.1), which apparently does not require this function.

I still had to apply some small modifications:
- replacing interp->errorLine by Tcl_GetErrorLine(interp)
- adding some "const" qualifications
but finally managed to compile XOTcl 1.6.1 with Tcl8.6.

If you're interested, I can send you the patch.

Thanks for all the good work on XOTcl !

Best regards,
Koen Danckaert


Gustaf Neumann wrote:
> Dear Koen,
>
> we are busy working on xotcl 2.0, which works for tcl 8.5 and tcl 8.6
> (we will most probably not be able to make 2.0 work with tcl 8.4;
> the 8.4 support is still in the 2.0 code base, but getting it to work
> with 8.4 would require a lot of work, so we will skip it).
>
> i am currently in the midst of reworking slots, which is the
> last biggy before the release (which i hoped to get finished
> by end of 2009)). There will be some more polishing on
> the interfaces and the code, documentation is at an early
> state, so end of q1 seems in reach for the release.
>
> xotcl 2.0 is quite different from xotcl 1.*, but there
> is an xotcl 1.* layer available, which is highly backwards
> compatible (i have tested it e.g. against xotcl-core and xowiki
> inside openacs, about 46000 lines of code). in case, you have
> not seen the slides an the xotcl 2.0 paper, drop me a note.
>
> if you have interest on getting access to the development version
> of xotcl 2.0, i can give you access to the git repository.
>
> -gustaf neumann
>
> Am 08.02.10 18:17, schrieb Koen Danckaert:
>> Dear XOTcl developers,
>>
>> I'm trying to use XOTcl (1.6.5) with Tcl8.6.
>>
>> Apparently XOTcl does not compile with Tcl8.6, but on Linux, I can get it to work by using a version compiled for Tcl8.5.4.
>>
>> However, this is not the case on Windows: loading XOTcl will make Tcl8.6 crash there.
>>
>> I also tried to use the xotcl165.dll provided by Activestate in the Tcl8.6b1 distribution. This seems to work with Tcl8.6b1 indeed, but not with newer versions of Tcl fetched from CVS (which I need).
>>
>> Is it possible today to use XOTcl in a recent Tcl8.6 ?
>> Or are there any plans to update XOTcl ?
>>
>> Best regards,
>> Koen Danckaert
>> _______________________________________________
>> Xotcl mailing list
>> Xotcl_at_alice.wu-wien.ac.at
>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>>
>
>

[Xotcl] Re: [Xotcl] Re: [Xotcl] The debian packages

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

From: Teemu Hukkanen <tjhukkan_at_fishpool.fi>
Date: Tue, 27 Mar 2001 20:01:45 +0300

On Tue, Mar 27, 2001 at 06:39:47PM +0200, Catherine Letondal wrote:
> Is there a debian package for the 0.84 release of XOtcl?
> Or even a 0.83?
>
> I found this in a previous email:
>
> deb http://bugger.fishpool.fi/debian tcl /
> deb-src http://bugger.fishpool.fi/debian tcl /
>
> but there is nothing there? And nothing on the XOtcl server either...

I've reorganised my package repositories, here's the new apt stanza:

deb http://bugger.fishpool.fi/debian unstable main
deb-src http://bugger.fishpool.fi/debian unstable main

Re: [Xotcl] Object eval Problem

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: Wed, 04 Jun 2008 19:59:54 +0200

Dear Ben,

apparently the problem you are experiencing is the same as the one
reported by Rene Zamseil
http://alice.wu-wien.ac.at:8000/xotcl-mailing-list/1060.html

This bug is fixed in the current development verison of
XOTcl, which you can get via git with

    git clone git://alice.wu-wien.ac.at/xotcl

Version 1.6.1 should be released in the near future.

best regards
-gustaf neumann

Next Page