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

Weblog Page

Filtered by date 2017-01-02, 861 - 870 of 1541 Postings (all, summary)

[Xotcl] Illusion templates

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, 6 Feb 2008 18:14:13 +0200

On 6 Feb 2008, at 17:18, Jade Rubick wrote:

> Kristoffer:
>
> Can you post some more information about how the API looks and works?
> Your blog post doesn't have much information on how it works or looks.

Sure. Well, for a start the package itself contains a couple of
really simple examples, but I'll copy the simplest one here.

Here is what the template looks like:

<!-- ILL-TMPL SRC example.tcl -->
<html>
   <body>
     Hello world. Let's try some magic:
     <p>
       <ul>
         <!-- ILL-OB ColourList START -->
         <li>%%colour%%</li>
         <!-- ILL-OB ColourList END -->
       </ul>
     </p>
     End of magic
   </body>
</html>

This template is for creating a list of colours. example.tcl, as
specified on the first line, contains the logic for the content of
objects and their amount. It is evaluated along with the template.
This is what it looks like:

Class ColourList -parameter {
     colour
}

foreach colour {red green blue} {
     set ob [ColourList new -colour $colour]
     ColourList lappend obOrder $ob
}

So basically it creates a single ColourList object for each colour we
want. It also appends them to obOrder to display them in the right
order (this phase is optional). The template uses the 'colour' method
to receive values, which is here implemented with -parameter, but
could easily be a method with some more logic instead.

To get the result we simply do:

set data [illusion::processTemplate example]

Here's the result:

<html>
   <body>
     Hello world. Let's try some magic:
     <p>
       <ul>

         <li>red</li>

         <li>green</li>

         <li>blue</li>

       </ul>
     </p>
     End of magic
   </body>
</html>

I also have added a feature to include other template files. I've
kept it simple on purpose as I don't think a template file should be
complex. The complexity should be in the Tcl. I do think this could
lead to quite a versatile solution, though.

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

Re: [Xotcl] Very severe limitation in XOTcl

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 13:21:39 +0300

On 5 Aug 2010, at 12:11, Gustaf Neumann wrote:

> Am 05.08.10 10:38, schrieb Kristoffer Lawson:
>> Yes, this is also true for setting a parameter:
>>
>> Car new -doors $amount
>>
>> If $amount contains a dash, it'll do a method call.
>>
> Well, "contains" is too strong,
> "starts with a dash followed by alpha" is precise.

Sorry, yes. I need to check still what 2.0 does with:

Car c1 $a

where $a starts with a dash.

> Class Car -parameter {{doors:integer 4}}
> Car c1 -doors -2
> Car c2 -doors a-b
>
> to trigger an error on "c2", or better define your own checker "posint"
>
> Class Car -parameter {{doors:posint 4}}
>
> to get already errors on c1.

I think these are fine. Errors when given a parameter of the wrong type are totally expected, and cannot be abused to execute code with bad values.

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

Re: [Xotcl] XOTclIDE 0.41 - with sqlite support

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 3 Mar 2003 20:34:32 +0200 (EET)

On Mon, 3 Mar 2003, Artur Trzewik wrote:

> all people that use atkdebugger should rebuild tcl with new
> tcl8.4.1-atkdebugger.patch

Just a silly sidenote, but I always find the name "atkdebugger" so funny.
You see ATK in Finnish is a very frequently used term for computing,
literally "Automatic Information Management". So I was really surprised
to see it used in foreign software, until I realised it was probably
from your name. Still, it fits quite nicely! :-)

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

[Xotcl] psnm - aufgabe 1c

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

From: Irene Fellner <irene_at_fellner.at>
Date: Thu, 7 Nov 2002 16:14:28 +0100

hallo,

bin grad am üben für den test nächste woche :-)
die lösung von aufgabe 1c (liste - jedes wort nur einmal) versteh ich nicht ganz.
dh insbesondere folgenden teil der methode lunique:
foreach elt $l {
if $memberArray($elt) {
lappend result $elt
set memberArray($elt) 0
}

ganz konkret kapier ich die if-methode nicht - hier fehlt doch die bedingung oder??
vielleicht kennt sich ja jemand aus, und kann mir es erklären ...

danke,
lg
irene

Re: [Xotcl] NX direct variable access

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: Wed, 19 Jan 2011 13:50:25 +0100

Am 19.01.11 10:19, schrieb Victor Mayevski:
> In NX, what is the correct way to give a direct access to an object
> variable for outside caller, just like we used to do with XOTcl's
> [myvar varname]?
>
I assume, you want to obtain a fully qualified variable handle for an
instance variable. Essentially, it works in nx very similar to XOTcl.
See below for the method "bindvar" which obtains the fully
qualified name and shows its usage in the context of Tk.

-gustaf neumann

==================================================
#
# Tiny Tk example with bindvar and callback
#
# -gustaf neumann

package require nx
package require Tk

nx::Class create Callbacks {
   #
   # A small support class to ease syntactically the reference to
   # instance variables and the registration of callbacks.
   #
   :method bindvar {name} {
     :require namespace
     return [nx::self]::$name
   }
   :method callback {name args} {
     return [list [nx::self] $name {*}$args]
   }
}

nx::Class create Myclass {

   #
   # A sample application class that creates a text entry field bound
   # to an instance variable. When the provided button is pressed, the
   # content of the variable is placed into an additional output label.
   #

   :mixin Callbacks

   :public method button-pressed {} {
     .label configure -text ${:myvar}
   }

   :method init {} {
     wm geometry . -500+500
     pack [label .title -text "Type something and press start button...."]
     pack [entry .text -textvariable [:bindvar myvar]]
     pack [label .label]
     pack [button .button -text start -command [:callback button-pressed]]
   }
}

Myclass new
==================================================


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

Re: [Xotcl] NX nested objects

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: Sat, 22 Jan 2011 10:22:55 +0100

Technically, "slot" is a child object, which is not easy to
hide from the
application developer (otherwise, slot handling will break).
An option
could be to store the slot objects at a different place, but
this would
involve more complications on renaming, cleanup, etc. Not sure,
we can address that before our release in the not to far future.

Using "info lookup method|methods|..." is used for obtaining
information about the closure of local and inherited items from
the standpoint of an object. Questions like "what methods
can i call?", "where is the method defined, i am calling?", etc.
So hiding "slot" on "info children" and showing it on "...
lookup ..."
is not an option.

"info children" has already an option "-type" that can be
used to filter
the result. Is this an option for you?

-gustaf neumann

On 21.01.11 23:52, Victor Mayevski wrote:
> Hello Gustaf,
>
> After adding attributes to an object, and creating nested objects
> within it, I need to list those nested objects. When I do [myobject
> info children], "::myobject::slot" is listed among other nested
> objects that I created. Since my code did not specifically create the
> "slot" object (it is an artifact of creating attributes), it seems
> that it should not be listed along with my scripted objects, perhaps
> [myobject info lookup children] is a better place to list the "slot"
> object?
>
> Thanks,
>
> Victor

Re: [Xotcl] Linking object instance variables to a widget -textvariable?

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

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Sat, 15 Nov 2003 13:15:30 -0800

Uwe Zdun wrote:
> -opencmd "[self] modifyTree 1 $sw.tree" \
> -closecmd "[self] modifyTree 0 $sw.tree"]
> ...
> $tree bindText <ButtonPress-1> "[self] selectTreeElement $tree"
> $tree bindText <Double-ButtonPress-1> "[self] openTreeElement $tree"

And of course you always want to write core like the above as:

-opencmd [list [self] modifyTree 1 $sw.tree]
or
$tree bindText <ButtonPress-1> [list [self] selectTreeElement $tree]

otherwise you are asking for a maintenance headache.

-- 
     Jeff Hobbs, The Tcl Guy
     http://www.ActiveState.com/, a division of Sophos

[Xotcl] Tcl source requirement

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 2 Mar 2003 12:15:03 +0200 (EET)

Is there any particular reason why XOTcl still requires the Tcl source
lying around to compile? Generally I find it awkward and not quite "clean"
that some Tcl extensions require the original Tcl source and I've never
really needed it myself for my own stuff.

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

Re: [Xotcl] Attributes bug?

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, 25 Jun 2012 11:52:41 +0200

Dear all,

the same problem as reported by Kurt Stoll exists as well in
nx/xotcl2.
Since the new implementation has already an elaborated resolver
infrastructure, and since it already flags slot container
objects as such,
i have added a specialized resolver for handling this
unwanted interaction.

The test case below works now correctly.

-gustaf neumann

nx::Test case slot-container-name-interaction {

   nx::Class create Test2 {
     :property list {
       :public method assign { obj var val } {
        nsf::var::set $obj $var [list $obj $var $val]
       }
       :method unknown { val obj var args } {
        return unknown
       }
     }
   }

   ? {Test2 create t2} ::t2
   ? {t2 list 3} {::t2 list 3}
   ? {t2 list} {::t2 list 3}
   ? {t2 list this should call unknown} "unknown"
}


On 25.06.12 09:30, Gustaf Neumann wrote:
> Dear Kurt,
>
> Replace in the assign method
> $obj set $var [list $obj $var $val]
>
> by
> $obj set $var [::list $obj $var $val]
>
> Background: the created slot object2 ("alist" and "list")
> are fully named
>
> ::Test1::slot::alist
> ::Test1::slot::list
>
> In order to create these conveniantely (i.e. without
> requiring the user to write the namespaces explicitly),
> the method "slots" changes the current namespace to
> "::Test1::slot". The method "assign" is executed
> in this namespace (::Test1::slot), and picks up the
> "::Test1::slot::list" instead of the desired "::list".
> Therefore, using the explicit namespace path for "::list"
> helps.
>
> The only way to get rid of this unexpected behavior is to
> introduce a namespace resolver for the
> slot object container, that overrides the Tcl behavior.
>
> -gustaf neumann
>
> On 25.06.12 00:54, Kurt Stoll wrote:
>> This looks wrong to me, but I could be wrong - maybe
>> there are prohibitions somewhere that would tell me not
>> to do this.
>>
>> If I define an Attribute "list", and then use the Tcl
>> list command within the assign (and, presumably, other
>> procs of the attribute as well), the attribute's unknown
>> handler is called reflecting an odd invocation. I would
>> suspect that other "overloading" (this is not really
>> overloading, but looks similar so I have used that term;
>> I apologize it that confuses you) of Tcl commands as
>> Attributes would result in similar problems.
>>
>> First, here is a simple Test class without overloading
>> the list command to demonstrate the expected behavior.
>> Note that I redefine unknown so that I can verify the
>> order of the invocation:
>>
>> (Warning - I submitted a question with embedded test code
>> some years ago and this caused problems for people when
>> they attempted to copy-and-paste the code. I don't
>> recall exactly what caused the issue, but I am still
>> using the same email client, so this may have similar
>> issues.)
>>
>> Class create Test1 -slots {
>> Attribute create alist -proc assign { obj var val } {
>> puts "list<$obj> <$var> <$val>"
>> $obj set $var [list $obj $var $val]
>> } -proc unknown { val obj var args } {
>> puts "unknown: $obj $var $val $args"
>> }
>> }
>>
>>> ## Create a test object t1
>>> Test1 create t1
>> ::t1
>>> ## Call alist setter
>>> t1 alist 3
>> list<::t1> <alist> <3>
>> ::t1 alist 3
>>> ## Check to see that alist variable set properly
>>> t1 set alist
>> ::t1 alist 3
>>> ## Force a call to unknown; note that the printed output
>>> matches the invocation order
>>> t1 alist this should call unknown
>> unknown: ::t1 alist this should call unknown
>>
>> Now, I create a simple variant. All I have changed is
>> the name of the Attribute from "alist" to "list". But,
>> in this case, when attempting to call the setter, unknown
>> is called (I have done other experiments that showed that
>> it is called when "list $obj $var $val" is called).
>> Also, note that the invocation of unknown is a bit
>> strange; it appears that unknown is directly invoked on
>> the original call (in this case, "t2 list 3"), instead of
>> having the arguments swapped as demonstrated above:
>>
>> Class create Test2 -slots {
>> Attribute create list -proc assign { obj var val } {
>> puts "list<$obj> <$var> <$val>"
>> $obj set $var [list $obj $var $val]
>> } -proc unknown { val obj var args } {
>> puts "unknown: $obj $var $val $args"
>> }
>> }
>>
>>> ## Create a test object t2
>>> Test2 create t2
>> ::t2
>>> ## Call list setter. Unknown handler is called.
>>> t2 list 3
>> list<::t2> <list> <3>
>> unknown: list 3 ::t2
>>> ## See what ended up in the list variable.
>>> t2 set list
>>> ## Blank above
>> Am I wrong to expect Test2 (and t2) to behave just as
>> Test1 / t1 behaved? It's not a serious issue for me;
>> I'll just avoid overloading Tcl commands in this
>> context. But, it was unexpected enough for me that I
>> thought it was warranted for me to ask the experts.
>>
>> -Kurt Stoll
>>
>> _______________________________________________
>> Xotcl mailing list
>> Xotcl_at_alice.wu-wien.ac.at
>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 8 Jul 2002 14:04:07 +0200

On Saturday 06 July 2002 10:22, Catherine Letondal wrote:
> Hi,
>
> I get an error when compiling on Linux (debian potato):
>
> make[1]: Entering directory
> `/usr/local/packages/xotcl-full-0.9.4/xotcl-0.9.4/unix' cc -DUSE_TCL_STUBS
> -DVERSION=\"0.9\" -DXOTCL_LIBRARY=\"/usr/local/lib/xotcl0.9/library\"
> -I/usr/local/include/tcl8.2/generic -I/usr/local/include/tcl8.2/unix
> -I"./../generic" -I"./../unix" -I"/usr/local/include" -g -O2
> -D__NO_STRING_INLINES -D__NO_MATH_INLINES -fPIC -g
> -DXOLIBPKG=\"/usr/local/lib/xotcl0.9\" -DXOTCLVERSION=\"0.9\"
> -DXOTCLPATCHLEVEL=\".4\" -c `echo ../generic/xotcl.c` -o so/xotcl.o
> ../generic/xotcl.c: In function `TclCommands':
> ../generic/xotcl.c:9271: syntax error before `initMutex'
> ../generic/xotcl.c:9275: `initMutex' undeclared (first use in this
> function) ../generic/xotcl.c:9275: (Each undeclared identifier is reported
> only once ../generic/xotcl.c:9275: for each function it appears in.)
> ../generic/xotcl.c:9278: `rc' undeclared (first use in this function)
> make[1]: *** [so/xotcl.o] Error 1
> make[1]: Leaving directory
> `/usr/local/packages/xotcl-full-0.9.4/xotcl-0.9.4/unix' make: *** [libs]
> Error 1
>
> Thanks in advance for any help,


 Dear Catherine,

 please change in xotclnt.h
 the section defining XOTclMutex
 to the following.
 
#if !defined(PRE83) && defined(TCL_THREADS)
# define XOTclMutex Tcl_Mutex
# define XOTclMutexLock(a) Tcl_MutexLock(a)
# define XOTclMutexUnlock(a) Tcl_MutexUnlock(a)
#else
# define XOTclMutex int
# define XOTclMutexLock(a) (*(a))++
# define XOTclMutexUnlock(a) (*(a))--
#endif

 this should help.
-gustaf
PS: how comes that debian still uses Tcl 8.2?

Next Page