Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 24 Oct 2006 15:01:53 +0200

Kristoffer Lawson schrieb:
>> configure gets all arguments, including the values passed to init.
>> Use the one-liner of my last mail, and you
>> will see that this works for your example as well. if you pass the
>> saved values to object creation, you achieve
>> both, configuring the attributes and calling the constuctor with the
>> saved values.
>
> OK, thanks, this is working for me at the moment.
you can certainly provide an instmixin for "init" instead of
"configure", if you are only interested in the arguments passed
to the constructor. However, in the general case, doing it on
"configure" is better.

-gustaf neumann

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Sat, 20 Jul 2002 14:38:06 +0200

Zoran Vasiljevic wrote:
> 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 :)

my laptop does :-)

> I'd double-check
>
> % info commands xotcl::*
>
> If it returns xotcl::Object (among others) then you'd need
> to:
>
> % namespace import xotcl::*
>

It worked. I just wonder why is that necessary with the shared
library - it is not under xotclsh or xowish? I also tried under
another Xotxl 0.9 shared library installation... and it worked.

Thanks anyway!

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Michael Schlenker <schlenk_at_uni-oldenburg.de>
Date: Mon, 24 May 2004 16:09:08 +0200

Adam Turoff wrote:

> Uwe Zdun wrote:
>
>>what about just extending the usually interfaces with new
>>arguments, such as:
>>
>>A mixin X
>>A mixin add Z 3
>>A mixin add Y end
>>A mixin delete Y
>>A instmixin add T 1
>>A superclass B
>>A superclass add C
>
>
> That's pretty much what I was thinking:
>
> A mixin X ;# current behavior
> A mixin -set X ;# A mixin X
> A mixin -set X Y Z ;# A mixin {X Y Z}
>
> A mixin -add X ;# A mixinappend X
>
> Using -set, -add and -delete feels more Tcl-ish. Also, it
> is somewhat bad style to name a class 'add', but even worse
> style to name it '-add'. By using options, I can still
> mixin a class 'add' into a definition. Preventing me from
> mixing in a class '-add' is a good idea, for other reasons.

I wouldn't say an option for an action feels more Tcl-ish. I do not know
any tcl command that uses options to specifiy an action, its nearly
always a subcommand and options just specify details.
If you want to prevent things from happening add assertions or make it
explicit. In Tcl you name variables and procs as you like, even space,
\n \r or any kind of unicode fancyness is in principle supported and
there is no need to break this tradition for class names or mixin names.

So:
A mixin set foo bar baz
A mixin add boing
A mixin delete foo

feels quite natural, its verbose but thats usual Tcl style.

Why shouldn't you be able to add an mixin 'add' after the change?

A mixin add add

Syntax would probably be:

obj mixin ?subcmd args? , with subcmds add delete set
or
obj mixin mixinlist

So if the llength is 4 or greater the first behaviour is used, with just
one extra arg the old behaviour could be used.

Michael

From: Den Clair <amazabizopps_at_yahoo.ca>
Date: Sat, 24 Jun 2006 08:40:37 -0400 (EDT)

Hello Friends
  
  You to Can earn 7% Every Day for 28 days over and over again.
  Earn up to $700 a day.Join Lucly7Daily This autosurf Pays.
  Join Free A minum to upgrade $7 is required to be able to earn.
  This is not a scam AutoSurf.Members are being paid on time.
  
  Be one of the Lucky Members and Start Earning Now.
  
  http://lucky7daily.com/?ref=3
  


                 
---------------------------------
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 13 Oct 2010 15:33:40 -0700 (PDT)

I have just tried my application on latest TCL 8.6b4 and it crashes (Segmentation fault). The same application works just fine in TCL 8.5.9. Any idea how I can troubleshoot it? Tools, techniques etc?

Thank you

From: Teemu Hukkanen <tjhukkan_at_fishpool.fi>
Date: 03 Apr 2001 15:46:38 +0300

Teemu Hukkanen <tjhukkan_at_fishpool.fi> writes:

> 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

And here are packages for the stable distribution (along with tcl8.3 and
tk8.3 recompiled for stable):

deb http://bugger.fishpool.fi/debian stable tcl
deb-src http://bugger.fishpool.fi/debian stable tcl

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Wed, 6 Oct 2004 15:33:09 -0700

Aamer Akhter wrote:
> Has anybody run into weirdness with the komodo tcl debugger
> and xotcl? Sorry to be so imprecise, but that's the best way
> I can describe it right now.

Is it possible to be any more precise? The Komodo Tcl debugger
doesn't do anything fancy with regards to xotcl (not trying to
recognize it specifically).

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

From: Victor Mayevski <vitick_at_gmail.com>
Date: Sat, 18 Dec 2010 23:18:22 -0800

Thank you very much Gustaf for taking your time to explain this.




On Thu, Dec 16, 2010 at 2:31 AM, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
> Dear Victor,
>
> here is a scripted writeup to address your questions.
>
> -gustaf neumann
> ===========================================================
> package req nx::test
> nx::Object create o
>
> # The method setter registers an accessor method for instance
> # variables. It provides "set" and "get" operations and value
> # checking.
>
> # Register accessor named x
> o setter x
>
> # Use the accessor method x as setter
> # (set instance variable x to 1; returns 1)
> ? {o x 1} 1
>
> # Use the accessor method x as getter
> # (get the value of the instance variable x; returns 1)
> ? {o x 1} 1
>
> # Define a setter with a value constraint
> o setter x:int
> ? {o x 3} 3
> ? {o x a} {expected integer but got "a" for parameter "x"}
>
> # The accessor function can be realized with some more typing as well
> # via the following method. So, the method "setter" does not provide
> # any additional functionality in terms of expressability of the
> # language.
>
> o public method y {value:int,optional} {
>  if {[info exists value]} {
>    return [set :y $value]
>  } else {
>    return [set :y]
>  }
> }
>
> ? {o y 3} 3
> ? {o y a} {expected integer but got "a" for parameter "value"}
>
> # Why are accessor function at all provided since instance variables
> # can be accessed as well without these?  In nx it is easy for an
> # object to access the own instance variables via variable resolvers
> # (variable names starting with a single colon), butmore work to
> # access the variables of other objects. One can use e.g. the method
> # "eval" to execute a script in the context of an object (and to be
> # able to use the variable resolver).
>
> ? {o eval {set :x 2}} 2
>
> # So, an accessor method makes the access of public variables easy, it
> # provides the value constraints, one can use interceptors for
> # tracing, refinement, etc.
>
> # Ok, why do we need attributes?
>
> # Attributes (as defined by nx) provide all functionalities provided
> # by the setter methods plus
> #  - some attribute life-cycle management (e.g. default values), and
> #  - arbitrary meta-data
>
> # For example, we can define an integer attributed named "z" with a
> # default value.
>
> o attribute {z:int 123}
> # return the default value
> ? {o z} 123
> ? {o z a} {expected integer but got "a" for parameter "z"}
>
> # The example above is an object specifc attribute. In most
> # situations, attributes are defined on the class level. Attributes
> # are inherited to subclasses (setters certainly as well).
>
> nx::Class create Employee {
>  :attribute serial_number:int,required
> }
> nx::Class create Manager -superclass Employee {
>  # Project names are upper case, provided as an list, which might be
>  # empty and are per default initialized to the empty list.
>  :attribute {projects:upper,0..n {}}
> }
>
> Manager create joe -serial_number 4711
>
> # What about the meta-data? I want to use e.g. very special meta-data,
> # such as e.g. time-stamps.
>
> # The method "attribute" creates so-called slot objects, which are in
> # turn nx objects. These slot objects can be initialized like all
> # other nx objects in a scripted way.
>
> nx::Class create C {
>  # Create attributes "x" and "y" and script the initialization of
>  # these attributes.
>  :attribute x {
>    set :timestamp [clock clicks]
>  }
>  :attribute y {
>    set :timestamp [clock clicks]
>  }
>  :create c1
> }
>
> # Print for every slot object the value of the timestamp, if it
> # exists.
> proc print_slots_and_timestamps {obj} {
>  foreach slot [$obj info lookup slots] {
>    if {[$slot eval {info exists :timestamp}]} {
>      puts "$slot created at [$slot eval {set :timestamp}]"
>    }
>  }
> }
> print_slots_and_timestamps c1
>
> #
> # Ok. What if I want to use a time-stamp for every attribute of my
> # application without having to write this for every occurance?
> #
> # Well, use the force, luke. Remember, we have quite a powerful
> # underlying framework, supporting e.g. mixin, dynamic call
> # definitions, etc.
>
> ::nx::Attribute mixin [Class new {
>  :method init {} {
>    set :timestamp [clock clicks]
>    next
>  }
> }]
>
> nx::Class create D {
>  # Create attributes "x" and "y" and script the initialization of
>  # these attributes.
>  :attribute x
>  :attribute y
>  :create d1
> }
>
> print_slots_and_timestamps d1
>
> #
> # What if i want to use different kinds of attributes, such as
> # e.g. persistent attributes and non-persistent attributes, etc.?  How
> # can i define my on slotclasses if i need?
> #
> # Per default, attributes are of the class ::nx::Attribute. One can
> # certainly define subclasses of this class and specify these classes
> # during attribute creation. Since "attribute" is technically a
> # method, the syntax is slightly different to the usual object
> # creation.
> #
> # We define now "MyAttribute" as a subclass of ::nx::Attribute with an
> # additional attribute named timestamp. The timestamp has the actual
> # timestamp as default.
> #
> ::nx::MetaSlot create MyAttribute -superclass ::nx::Attribute {
>  :attribute {timestamp "[clock clicks]"}
> }
>
> # Use this type of attribute:
> nx::Class create E {
>  :attribute x -slotclass MyAttribute
>  :attribute y -slotclass MyAttribute
>  :create e1
> }
>
> print_slots_and_timestamps e1
>
> # A final question: i see that "attribute" is more powerful then
> # "setter". Do I need as an enduser the method "setter" at all?
> #
> # No. I think, we could safely remove it from the default method set
> # for the final release.
> #
> # One other observation during this writeup: maybe "slotclass" is to
> # crude, we could use "class" or "type" instead (at some earlier
> # state, we could not use technically "class"). We will overthink
> # this.
>
>
>
>
>

From: Rene Zaumseil <r.zaumseil_at_freenet.de>
Date: Sat, 28 Jul 2012 22:23:53 +0200

Am Freitag, 27. Juli 2012, 12:32:20 schrieb Gustaf Neumann:
> On 26.07.12 21:34, Rene Zaumseil wrote:
> > Get msys/mingw with the default installer
> > http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer
> > /mingw- get-inst/mingw-get-inst-20110211/mingw-get-inst-20110211.exe
> > and selected also g++, msys, and tools.
> >
> > Then get kbs.tcl from
> >
> > http://sourceforge.net/projects/kbskit/files/
> >
> > Put it in a directory and run:
> > ./kbs.tcl -r install kbskit8.5 nsf2.0
> >
> > If everything works you can find the lib under directory build*/
> >
> > Or to get a interpreter containing nsf run:
> > ./kbs.tcl -r -bi=nsf2.0 -vq-bi install kbskit8.5
> >
> > Hope this works.
>
> Short feedback (being a win-dummy).
>
> - i installed win7 in a vbox
>
> - downloaded mingw+msys via
> http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-
> get-inst-20120426/ (the most popular one, newer than what you wrote)
>
> - set up the environment variable to contain path to
> mingw/bin and msys/bin
>
> - started a console, but had to write "bash kbs.tcl ..."
> instead of "./kbs.tcl ..."
> (maybe one one setup required)
>
> - got an error that wget is not installed;
> installed wget, added GnuWin32/bin to the path
Ok, I have the sources downloaded under unix and then copied to windows.
>
> The compilation of tcl ran into the following problem (the
> fetched tcl version is 8.5.11).
> Does one have to install the "20110211" version of mingw? is
> there a configure problem
> on win7?
I have installed the 20110211 version last year because my older
installation from the tcl sourceforge side was not working anymore.
I think it was a problem with missing libraries.
>
> -gn
>
>
> Y:\win\kbs\MINGW32_NT-6.1\tcl>make
Oh,may be here. I have put the kbs directory under:
  C:\MinGW\msys\1.0\home\rene
Could you also try to put the kbs directory under these path?

> 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

HTH
rene

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Mon, 22 Jan 2001 14:51:36 +0100 (CET)

>>>>> "KL" == Kristoffer Lawson <setok_at_fishpool.com> writes:
KL> [~] package require XOTcl
KL> 0.83
KL> [~] Class Foo
KL> [~] Foo instproc init {} { Bar [self] }
KL> [~] Foo instproc destroy {} { puts rm }

KL> [~] Class Bar
KL> [~] Bar instproc init {blah} {}

KL> [~] Foo ob
KL> rm
KL> no value given for parameter "blah" to "init"
KL> while evaluating {Foo ob}
KL> [~] Foo uh
KL> rm
KL> Segmentation fault

KL> The "Bar [self]" line was actually a bug in my own code (oops, forgot
KL> "new"), but it's interesting to note that it resulted in a segmentation
KL> fault.

 just to paraphrase the code: during the constructor of Foo, you
 created a new object of class Bar with the name of the instance of
 Foo. when you create a new command with the same name, the "old"
 object is deleted, and the constructor for the new command is called.
 but the constructor for the new object is called incorrectly, since
 the parameter "blah" was not provided.
 
 During the output of the error message, XOTcl tries to provide
 the backtrace (callstack), but it this case it contains a command
 from an non-existing object.

 on my system, i do not get an segfault, but an output containing freed
 memory. if you remove the "blah" argument from the constructor of
 Bar, i would expect a graceful behavior on your system as well.

 If you are interested, i could send you a quick fix for the problem.
 However, I experimented with the problem, you are addressing, and
 found another related problem, for which i have no fix yet....

 -gustaf