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

Weblog Page

Showing 921 - 930 of 1561 Postings (summary)

[Xotcl] Multi threaded web-server in XOTcl

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: Thu, 17 Apr 2003 16:01:13 +0200

 Fellow XOTcl-community,

 maybe, someone finds the following code useful. The attached file
 implements a simple multi threaded Webserver in XOTcl that
 uses Zoran's the wonderful tcl thread library 2.5. It is about
 150 lines of code and supports conditional requests (if-modified-since).
 
 best regards
-gustaf neumann




    Re: [Xotcl] Use of TclGetInterpProc

    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: Thu, 26 Aug 2004 21:32:19 +0200

    Neil,

    thanks for noting. we had a few more references to the
    variable of the xotcl interp state set in this line, so i added a couple
    of ifdefs. If someone needs the string based interface, please
    compile with USE_INTERP_PROC and send us mail, otherwise
    we drop the usage in the future completely.

    best regards
    -gustaf

    On Thursday 26 August 2004 20:43, Neil Madden wrote:
    > Hi all,
    >
    > I've just been compiling XOTcl 1.3.0 on Mac OS X against the latest (as
    > of about an hour ago) CVS HEAD versions of Tcl and Tk. It initially
    > failed on the final linking stages, missing the TclGetInterpProc
    > function. This function has been taken out of Tcl in CVS. Commenting
    > out the 1 reference to this function in the XOTcl sources
    > (generic/xotcl.c line 10461) allows the compile to finish, all the
    > tests pass and the resulting library seems fine. Talking to Donald
    > Porter on the Tcl'ers Chat indicates that use of this function should
    > no longer be necessary as Tcl doesn't create any procs using the old
    > string-based interfaces anymore.
    >
    > Just thought I'd send out a heads-up, as you probably want to fix/alter
    > the XOTcl code to deal with this.
    >
    > Cheers,
    >
    > Neil.
    >
    > _______________________________________________
    > 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
    

    XOTcl/NX mailing list by object move?

    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: Sun, 19 Mar 2006 02:52:25 +0100

    Scott Gargash schrieb:
    >
    > Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 03/18/2006 01:39:35 PM:
    > >
    > > I do not see much evidence of a speed increase when adding a layer of
    > > indirection for every object access.
    >
    > Well, for example, it might be possible to get rid of namespaces in
    > the implementation.
    >
    thinking about getting rid of namespaces is a different theme, this can
    be done as well without "strongly aliased objects".

    namespaces are pretty essential in tcl. every command name lookup
    works through a namespace. xotcl uses
    tcl-namespaces for methods (procs and instprocs), for variables, and for
    aggregations. certainly, this could be
    implemented differently, frequently we have to fight with namespaces,
    but the idea was to reuse concepts
    from tcl in xotcl. Using tcl-namespaces has many advantages as well:
    currently, we can rename tcl-procs
    or tcl-commands to make it methods in xotcl; or we can namespace-import
    procs/cmds from tcl as
    methods/instmethods etc. into xotcl with the standard tcl-commands.
    >
    > If the access to the object is always through the reference and the
    > true object was never visible, you might not have to create a new
    > namespace (on demand or not)
    >
    i can't follow the argument.... what ist the relationship with the
    visibility? namespaces are used for various purposes:
    methods are tcl_procs or tcl-commands and have to "live" somewhere, in
    tcl they live in namespaces.
    one can certainly implement this differently as in tcl, as for example
    using hash-tables only, but this is not
    related to visibility. btw, if you never show the real name to the
    application developer, it will be hard to create
    multiple references other than by creating an alias of the alias.
    >
    > or ever move an existing object to make it a child of another object.
    > The parent/subobject relationship could be inferred from the alias's
    > location in the namespace, or even tracked in child/parent hash tables
    > if you wanted to support object relationships beyond a tree (DAGs),
    > but it would not be a property of the object's location. If objects
    > never moved, everything could live in the same namespace, and just
    > tracked via the object hashes.
    >
    > And is method dispatch done via a command lookup? If so, an invariant
    > method location should allow command lookup to be elided.
    >
    whatever "same namespace" means (see above). note that we have multiple
    identical method names in procs/classes,
    they can't live in the same namespace. if the nesting relationship is
    realized via the namespaces of the aliases,
    these have to be created as well since they will most likely not exist.
    This way, they namespaces are moved
    out of the xotcl objects, but introduced at different places, where they
    are more complicated to manage.
    some interactions with namespaces will be even more complicated as they
    are now: you have to
    deal with cases, where e.g. someome deletes the alias (e.g. via "rename
    myreference {}") or deletes
    the namepace, where the alias lives in.
    >
    >
    > Of course, since I'm the one who keeps asking "How do I do this?"
    > questions, I'm probably completely wrong.
    > BTW, does invocation via an alias have any overhead? I would guess
    > not as it's (seems like) a string->Tcl_Obj mapping, the same as a
    > native command lookup, but I don't know.
    >
    an "interp alias" has a certain overhead, since it is an additional
    command invocation.
    Try the following; if you increment the loop counter in the for loop to
    e.g. 1000,
    you will get a "too many nested evaluations" error. you will see, the
    last test will be
    the slowest by far.

    ==========================================================
    proc t {cmd {txt ""}} {
      set n 100000
      set ms [lindex [time [list time $cmd $n] 10] 0]
      puts "[format %7.4f [expr {$ms*1.0/$n}]]ms for $cmd ($txt)"
    }

    proc x {} {set x 1}
    interp alias {} myset {} set
    interp alias {} myx {} x
    interp alias {} myx1 {} x

    for {set i 1} {$i < 100} {incr i} {
      set i1 [expr {$i+1}]
      interp alias {} myx$i1 {} myx$i
    }

    t {set x 1} "set"
    t {myset x 1} "myset"

    t {x} "x"
    t {myx} "myx"
    t myx$i1 myx$i1
    ==========================================================

    It is however possible to implement zero-overhead aliases
    with the tcl c-api, at least in certain situations, when one does not
    care about someone else replacing commands on the fly with
    global effects. I have implemented such things by myself.

    best regards
    -gustaf neumann

    Re: [Xotcl] Mixins in XOTcl

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

    From: Kristoffer Lawson <setok_at_fishpool.com>
    Date: Wed, 19 May 2004 18:37:35 +0300 (EEST)

    On Wed, 19 May 2004, Michael Schlenker wrote:

    >
    > Its similar in tcl, where you have [info commands] and not a magic
    > $commands variable as you might have in other languages.
    >
    > Using traces it should be possible to provide such an interface if
    > anyone really wants it.

    So what is so problematic about just getting a list, manipulating it and
    then setting it back? Seems like a lot of copied effort for what is
    basically just list manipulation.

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

    Re: [Xotcl] replacing libtcl

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

    From: Kevin Van Workum <vanw_at_sabalcore.com>
    Date: Thu, 12 Aug 2010 10:05:03 -0400

    On Thu, Aug 12, 2010 at 9:20 AM, Gustaf Neumann <neumann_at_wu-wien.ac.at>wrote:

    > On 11.08.10 19:51, Kevin Van Workum wrote:
    > > I would like to include XOTcl functionality to my control script, but
    > > naively using "package require XOTcl" doesn't seem to work.
    > "package require XOTcl" is supposed to work. In xotcl 1.6.6,
    > i count
    > 128 occurrences of "package require XOTcl".
    >
    > If Tcl does not find the package, it might be the case that
    > you installed it to some
    > directory not on your auto_path or (TCLLIBPATH, etc.), or
    > that you are
    > using a Tcl distribution, not including it.


    That's was I initially thought. so I simply set TCLLIBPATH which didnt'
    work. I recently discovered that for security reasons, the invoking env is
    not being passed through to the interpreter's env. I didn't think to
    manually set auto_path in my script, but now that's what I'm doing and it
    works.

    Thanks.



    > After the
    > install you should have e.g.
    >
    > /usr/local/lib/xotcl1.6.6/pkgIndex.tcl
    > /usr/local/lib/xotcl1.6.6/libxotcl1.6.6.so
    > /usr/local/lib/xotcl1.6.6/libxotclstub1.6.6.a
    >
    > You can certainly initialize via C as well (using Xotcl_Init()),
    > but i would recommend the "package require" way.
    >
    > best regards
    > -gustaf neumann
    >
    > _______________________________________________
    > Xotcl mailing list
    > Xotcl_at_alice.wu-wien.ac.at
    > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
    >



    -- 
    Kevin Van Workum, PhD
    Sabalcore Computing Inc.
    Run your code on 500 processors.
    Sign up for a free trial account.
    www.sabalcore.com
    877-492-8027 ext. 11
    

    [Xotcl] RE: Non-positional args with no value cause core dump

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

    From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
    Date: Thu, 11 Nov 2004 17:21:20 -0500

    I found another problem with non-position args... an argument of "--" can cause a core dump.
    Consider the following.


    Object o
    o proc foo {{-a A}} {b} {
       puts "$a $b"
    }
    o foo "B"
    #--> "A B"

    o foo "-"
    #--> "A -"

    o foo "---"
    #--> "A ---"

    o foo "--"
    #--> core dump.





    > -----Original Message-----
    > From: Schofield, Bryan (GE Transportation)
    > Sent: Wednesday, November 10, 2004 9:17 AM
    > To: xotcl_at_alice.wu-wien.ac.at
    > Subject: Bug: Non-positional args with no value cause core dump
    >
    >
    > Gustaf/Uwe -
    >
    > I found a little bug in 1.3.3 that I downloaded on October
    > 15th from=20
    > http://media.wu-wien.ac.at/download/xotcl-1.3.3.tar.gz
    >
    > The following causes a core dump on my Solaris workstation:
    >
    > Object o
    > o proc foo {{-foo 1}} {} {
    > puts "foo: $foo"
    > }
    >
    > o foo
    > #--> "foo: 1"
    >
    > o foo -foo 0
    > #--> "foo: 0"
    >
    > o foo -foo
    > #--> BOOM!
    >
    >
    >
    > Just thought I'd pass that on. Regards
    > -- bryan
    >

    Re: [Xotcl] Sqlite command inside NX object

    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, 01 Aug 2011 14:19:45 +0200

    Dear Victor,

    The confusion is in part due to the fact, that mysql uses the tcl idiom
    "eval" and varnames looking like tcl varnames, but it provides its
    semantics with its own machinery. One can use

       db1 eval {insert into mytable values ($data)}

    but one cannot use syntactically e.g.

       db1 eval {insert into mytable values (${data})}

    since the sqlite sql parser does not know about braced var-names, and the
    "eval" after "db1" is no "eval" in the Tcl sense.

    I would recommend to let sqlite create its own objects, and address
    these with their full path.

        sqlite3 ::db1 /tmp/my.db
        ::db1 eval {create table mytable (data)}

        Object create o
        o public method insert {data} {::db1 eval {insert into mytable values ($data)} }

    In case, you need/want databases per object/class, you can certainly use
    [self] inside the database handle. This is essentially the same what you
    found out.

    -gustaf neumann

    Am 29.07.11 02:24, schrieb Victor Mayevski:
    > #I am confused about the following behaviour of Sqlite command inside
    > NX object.
    >
    > Object create o;
    > o require namespace;
    > sqlite3 o::db /tmp/my.db
    > o db eval {create table mytable (data)};
    > o public method insert {data} {:db eval {insert into mytable values ($data)} };
    >
    > #In the above, sqlite sees the variable $data as being empty (or non-existent);
    > #If I rewrite the method in a following way (using double quotes
    > instead of braces), it works:
    >
    > o public method insert {data} {:db eval "insert into mytable values ($data)" };
    >
    > #The problem is that I might want to insert binary/BLOB data etc,
    > therefore use the : _at_ $ prefix for variables, I have to use braces,
    > not double quotes.
    > #After much trial and error I got the following to work:
    >
    > o public method insert {data} {[self]::db eval {insert into mytable
    > values ($data)} };
    >
    > #why doesn't sqlite see the variable with :db AND braces syntax but it
    > works fine with [self]::db or :db + double quotes syntax ?
    > #as far as I am concerned, the problem is solved, I am just curious
    > what is going on here.


    -- 
    Univ.Prof. Dr. Gustaf Neumann
    Institute of Information Systems and New Media
    WU Vienna
    Augasse 2-6, A-1090 Vienna, AUSTRIA
    

    [Xotcl] Bug: configure step chooses wrong tclsh

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

    From: <jim_at_jam.sessionsnet.org>
    Date: 29 Mar 2004 01:50:15 -0000

    Hi,

    When configuring xotcl to build with a tcl which is not the system tcl,
    the configure step assumes the tclsh in the $PATH, which is a wrong
    assumption.

    The right assumption would be to choose the tclsh located in the tclConfig.sh.

    Doing this would ensure the builder will get the tclsh which is in the
    installation of tcl he/she specified.

    -Jim

    [Xotcl] setExitHandler & threads

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

    From: Scott Gargash <scottg_at_atc.creative.com>
    Date: Thu, 10 Aug 2006 20:49:54 -0600

    I've run into an interaction with threads and the XOTcl exit handler that I don't understand.

    I create a thread from within an object, and release that thread in the object's destructor. If I
    destroy the object directly, everything's fine, but if I destroy the object through "Object
    setExitHandler", I get an error. Am I treading into undefined behavior? Is there well-defined way
    to shut down multiple threads?

          Scott

    Here's some sample code:

    package require XOTcl
    package require Thread

    namespace import {xotcl::*}
    Class A
    A instproc init {} {
      my set tid [thread::create [subst -nocommands {
        set ::auto_path [list $::auto_path]
        package require XOTcl
        namespace import {xotcl::*}
        Object b
        thread::wait
      }]]
    }

    A instproc destroy {args} {
      thread::send [my set tid] {b destroy}
      thread::release [my set tid]
      next
    }

    A a
    if {0} {
      # This gives an error
      xotcl::Object setExitHandler {a destroy}
    } else {
      # this works
      a destroy
    }

    exit

    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: Tue, 03 Jun 2008 10:00:49 +0200

    Dear Eckhard,

    Eckhard Lehmann schrieb:
    > One thing comes to mind since I play around with Tclhttpd and a
    > persistency framework: Tclhttpd maintains sessions as safe slave
    > interpreters. These interpreters must know about persistency objects
    > in the server, so it is necessary that
    > - whenever a persistency object is created, a command alias for it
    > must be created in certain sessions (interpreters)
    > - whenever a session is created, certain persistency objects must be
    > "informed" (-> a command alias for them must be created in the new
    > interpreter).
    > - whenever a session is destroyed, it's alias must be removed from all
    > persistency objects that contain it.
    i would not recommend to use method combinators
    or filters for this kind of problem: This problem looks to me
    like an perfect example for metaclasses.

    Meta-classes allow to create special kinds of classes.
    Sometimes you would like to have PersistentClasses,
    sometimes RemoteClasses, or LoggedClasses,
    etc. One can certainly use object or class mixins
    as well to mix the feature "persistency" into one or
    several classes. The mixin approach has advantages
    for finer-grained control, but i doubt that you will
    need it for e.g. session management.

    So, for your problem, define a meta-class for classes
    with persistant objects and overwrite
    on the class level the methods "create" and "instdestroy". The same
    can be done with the Session class as well. I have not looked at
    the session model of TclHttpd, but from your specification, the
    class structure can look like the code below. The script
    produces the following output:

    creating object p1 of class ::Person
    ... create an alias for p1
    creating session s1
    ... inform instances of ::Person
    creating object p1 of class ::Person
    ... create an alias for p1
    creating object e1 of class ::Employee
    ... create an alias for e1
    creating session s2
    ... inform instances of ::Employee ::Person
    deleting session ::s2
    deleting session ::s1
    object ::e1 destroy
    ... delete alias for ::e1
    object ::p1 destroy
    ... delete alias for ::p1

    Hope, this helps.
    -gustaf neumann




    ##############################################
    package require XOTcl
    namespace import -force ::xotcl::*

    Class PersistentClass -superclass Class
    PersistentClass instproc create {name args} {
      puts stderr "creating object $name of class [self]"
      puts stderr "... create an alias for $name"
      next
    }
    PersistentClass instproc instdestroy {name} {
      puts stderr "object $name destroy"
      puts stderr "... delete alias for $name"
      next
    }

    Class Session
    Session proc create {name args} {
      puts stderr "creating session $name"
      puts stderr "... inform instances of [PersistentClass info instances]"
      next
    }
    Session proc instdestroy {name} {
      puts stderr "deleting session $name"
      next
    }


    PersistentClass Person
    Person p1

    Session s1

    Person p1
    PersistentClass Employee -superclass Person
    Employee e1

    Session s2

    s2 destroy
    s1 destroy

    Next Page