Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 20 Jul 2006 13:08:57 +0200

The mentioned patch is only for compiling against 8.5. Applying this
patch as it is
will break compilation with tcl 8.4.*. It will need another ifdef. just
by looking into the patch, i have the suspicion that it will create a memory
leak. So, the better approach seems to increment the autonames without
TclIncr*Var2, which should not be terribly complex. it will go into the
next release.

however, concerning the original mail, this is good evidence, that you
were not compiling against tcl 8.4.13 but against a tcl 8.5 version.
Using the --with-tcl flag should solve the issue.

-gustaf

Bernd Eidenschink schrieb:
> Hi Michael,
>
>
>> I saw the same error when compiling XOTcl 1.4 against Tcl 8.5 from cvs
>> head, where TclIncrVar2 is commented out in the internal stubs table for
>> tclIntDecls.h.
>> (on SUSE 10.1 x86-64)
>>
>
> At least there is a patch here:
> http://alice.wu-wien.ac.at/pipermail/xotcl/2006-April/005074.html
>
> Bernd.
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Andreas Kupries <andreask_at_activestate.com>
Date: Thu, 01 May 2014 12:36:02 -0700

21'th Annual Tcl/Tk Conference (Tcl'2014)
http://www.tcl.tk/community/tcl2014/

November 10 - 14, 2014
Embassy Suites Downtown
Portland, Oregon, USA

Important Dates:

Abstracts and proposals due Sep 8, 2014
Notification to authors Sep 22, 2014
Author materials due Oct 20, 2014
Tutorials start Nov 10, 2014
Conference starts Nov 12, 2014

[[
        Registration is open.
]]

Email Contact: tclconference_at_googlegroups.com

Submission of Summaries

Tcl/Tk 2014 will be held in Portland, Oregon, USA from November
10 - 14, 2014. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 5,
2014. Authors of accepted abstracts will have until September 2, 2014
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis.
WIP slots can be reserved like any paper proposal. BOF slots will be
managed on-site. All attendees with an interesting work in progress
should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2014/) and will be published on
various Tcl/Tk-related information channels.

        Registration is open.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt Noumena Corp General Chair, Website Admin
Andreas Kupries ActiveState Software Inc. Program Chair
Brian Griffin Mentor Graphics Site/Facilities Chair
Arjen Markus Deltares
Cyndy Lilagan Nat. Museum of Health & Medicine, Chicago
Donal Fellows University of Manchester
Gerald Lester KnG Consulting, LLC
Jeffrey Hobbs ActiveState Software Inc.
Kevin Kenny GE Global Research Center
Larry Virden
Mike Doyle National Museum of Health & Medicine, Chicago
Ron Fox NSCL/FRIB Michigan State University
Steve Landers Digital Smarties

Contact Information tclconference_at_googlegroups.com


Tcl'2014 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Mon, 05 Feb 2001 15:20:01 +0100

"Rick Hedin" wrote:
>
> Hello all.
>
> I want to build an object on top of a canvas. The object adds some
> internationalized features. I'm not clear how to manage the XOTcl object in
> conjunction with the Tk object. For now, I'm just managing the two as
> separate entities.
>
> Icanvas icanvas .f ;# I pass the path for the tk object.
> pack .f.icanvas -fill both -expand true ;# And manipulate the tk object
> with tk commands.
>
> Or maybe I should:
>
> pack [icanvas tkpath] -fill both -expand true
>
> Or give my object a truly wicked name:
>
> Icanvas .f.icanvas ;# Will this work?
>
> Or wrap every tk command in my xotcl object.
>
> What is your thinking regarding widgets from XOTcl?

I have a data structure registering object names for tk widgets.
Thus, a tk callback looks generally like:

        ::bind $path <tk event> {
            set object [names object %W]
            $object method args
        }

(names is an XOtcl Object knowing which object a tk widget belongs to)

--
Catherine Letondal -- Pasteur Institute Computing Center

From: <MichaelL_at_frogware.com>
Date: Mon, 12 May 2003 10:35:39 -0400

With XOTcl 1.0.2 on Windows 2000 I get the "Cannot locate the XOTcl
library on your system!" message despite the fact that the library is
successfully found. I read the message in the archives on this, but a) the
workaround didn't seem to work for me (if I understood it correctly) and
b) it seemed like 1.0.2 was supposed to fix the problem (but obviously
didn't in my case).

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 21 Jul 2006 13:49:26 -0400

One too many l's

Try this: http://xotcllib.sourceforge.net/

Ben

On 21/07/06, Kristoffer Lawson <setok_at_fishpool.com> wrote:
>
>
> On 21 Jul 2006, at 20:35, Ben Thomasson wrote:
>
> > Thanks! I'll test it other browsers next time. So http://
> > xotclllib.sourceforge.net should work in IE and Firefox now.
>
> Tested with Safari:
>
> An error has been encountered in accessing this page.
>
> 1. Server: xotclllib.sourceforge.net
> 2. URL path: /
> 3. Error notes: File does not exist: /home/groups/x/xo/xotclllib/htdocs/
> 4. Error type: 404
> 5. Request method: GET
> 6. Request query string:
> 7. Time: 2006-07-21 10:41:12 PDT (1153503672)
>
> Reporting this problem: The problem you have encountered is with a
> project web site hosted by SourceForge.net. This issue should be
> reported to the SourceForge.net-hosted project (not to SourceForge.net).
>
> If this is a severe or recurring/persistent problem, please do one of
> the following, and provide the error text (numbered 1 through 7, above):
>
> Contact the project via their designated support resources.
> Contact the project administrators of this project via email (see the
> upper right-hand corner of the Project Summary page for their
> usernames) at user-name_at_users.sourceforge.net
> If you are a member of the project that maintains this web content,
> please refer to the Site Documentation regarding the project web
> service for further assistance.
>
>
> / 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: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Sat, 20 Jul 2002 16:18:11 +0200

On Saturday 20 July 2002 14:38, Catherine Letondal wrote:

> 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.
>

The xotclsh/xowish already do this import per-se.
The extension library is a good citizen in the
Tcl world (well, starting from 0.9.4) and it
uses it's own namespace in order to avoid name
collisions and stuff.
This is good so, but it triggers some
misunderstandings when updating from
the earlier version.

Cheers
Zoran

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Tue, 26 Aug 2003 17:52:32 +0200

Hi,

It's a long time I haven't re-installed Xotcl on my Sparc/Solaris and
the unix directory configure apparently hangs on a part of the configure script
where an sed -f command is executed:

root 22332 99.6 0.7 984 776 pts/9 R 17:11:33 8:24 sed -f /tmp/cs2226...

The /tmp/cs2226.../out file in this indeed empty.

Could anybody help?

Thanks in advance,

-- 
Catherine Letondal -- Pasteur Institute Computing Center

From: Rick Hedin <rhedin_at_aquifer.geology.uiuc.edu>
Date: Mon, 29 Jan 2001 11:51:55 -0600

Greetings.

I worked through the example in the "Meta-Classes" section of the XOTcl
tutorial. The result is the same whether myMetaClass is a metaclass or not.
If you define it

        Class myMetaClass

rather than

        Class myMetaClass -superclass Class

then

        Agent info superclass

gives the same result.

I understand, in theory, that one wants to derive a class from some "more
basic" entity, but so far it seems to me that I can achieve everything I
want to achieve by starting with a class, not a metaclass, and modifying it.

Is there an example where being a metaclass results in different output?


        Regards,

        Rick

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 10 Jan 2001 00:23:56 +0200 (EET)

A couple of times I've come across a feature in XOTcl that makes it
more difficult for me to structure my applications the way I would like.

First I'll explain the structure I'd like:

In file foo.tcl I have class A defined. foo.tcl also sources the file
bar.tcl, which defines classes B and C, which are sub-classes of A.
I source bar.tcl at the top of foo.tcl because that's where I tend to put
things like that (as I would in C).

The problem:

I get an error when sourcing bar.tcl because classes B and C depend on
class A, which is only later defined in file foo.tcl. That's
understandable, so I build another file, definitions.tcl. In there I put
a stub for class A, with no methods defined yet. The methods are still
defined in foo.tcl.

The problem with this is that I like to have the "Class A" line in foo.tcl
as well, near the methods and the _at_ documentation. Just to remind me and
to keep things together nicely -- and so that the class definitions by
themselves don't need an external file. Now, the class that B and C point
to is still the one defined in definitions.tcl, and even though class A is
essentially redefined in foo.tcl, B and C do not point to this class, but
the one with no methods.

Now, there are ways around this, of course. In fact, it could be argued
that when this situation occurs the program perhaps should be restructured
somehow anyway. OTOH, maybe not. So would it be worth considering the
option that if a class is redefined then either it directly redefines
the existing class (ie. the class definition line is ignored), or it
makes all references to the original class point to the redefined one.
Are there good arguments against this behaviour?

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 02 May 2008 21:04:21 +0200

Eckhard Lehmann schrieb:
> Hi,
>
> two questions on the -type field of the Attribute class:
>
> 1)
> There is obviously no documentation on the available types? I needed to
> force an error on a wrong -type that told me all the available types
>
The type-checking is implemented in Tcl and is not hardcoded.
The logic is defined in the method mk_type_checker of the
class ::xotcl::Attribute and behaves as follows:

 a) if the specified "-type" of an ::xotcl::Attribute is an XOTcl class,
     the specified values have to be instances of the class

     In the example below, the attribute tasks of a Workflow
     has to be filled with instances of Task.

     #=======
     xotcl::Class Task

     xotcl::Class create Workflow -slots {
       Attribute tasks -multivalued true -type Task
       Attribute name -default ""
     }
     =======
     The full example is in
http://groups.google.at/group/comp.lang.tcl/browse_frm/thread/eccb038ec48236bb/cfe350d1283b6c70?lnk=st&q=xotcl+workflow#cfe350d1283b6c70


 b) if the specified "-type" of an ::xotcl::Attribute consists of a
single word,
    the single word is interpeted as a string-class of Tcl's
    "string is STRING-CLASS value"

 c) "-type" of an ::xotcl::Attribute consists of a single word, it is
    interpreted as a method call in XOTcl.

    See for example:
     =======
     Class Person -slots {
       ...
       Attribute sex -type "my sex" -proc sex {value} {
         switch -glob $value {
           m* {my uplevel {$obj set $var m}; return 1}
           f* {my uplevel {$obj set $var f}; return 1}
           default {return 0}
         }
       }
     }
    =========
    http://media.wu-wien.ac.at/doc/tutorial.html#slot-experimental

  So, the potential range of permissable values is quite large, since it
includes
  all STRING-CLASSES from Tcl, all classes from XOTcl
  (::xotcl::Class info instances -closure) and potentially, all methods
  that can be defined in XOTcl.

> 2)
> Is there a -type that denotes a string? There is alnum and alpha, but I
> mean ordinary strings that can contain arbitrary (utf-8, ISO-8859-1
> etc.) characters? Or alternatively, are the types extensible?
>
   All types are extensible, actually in multiple dimensions: one can define
   different checking methods, and one can as well define new types
   of ::xotcl::Attributes via subclassing. The latter ensures reusability.
> Background of this question: The -type of an attribute seems to be a
> useful invention for an automated persistency framework for databases.
> The problem with that automation is currently that you can not really
> generate SQL automatically for XOTcl attributes, because you don't know
> their exact storage types from looking at the classes.
> If it was possible to assign the proper -type to attributes (e.g.
> "text", "date", "bytea" ...), then I could see two cool possibilities
> for a persistency framework:
>
  Sure. In the OpenACS framework, xotcl-core contains definitions for
  subclassing ::xotcl::Attribute with ::xo::db::Attribute, which are
persistent
  attributes containing e.g. the column_name or the sql-type. Note that
these
  types might be different depending on the used database m management
system.

  see for example slide 28ff in
  
http://alice.wu-wien.ac.at:8000/s5-xotcl-core-tutorial/download/file/xotcl-core.pdf
> a) create XOTcl classes automatically using meta information of the
> database, and -type as validator
> b) create CRUD and select statements automatically from XOTcl classes,
> using -type for the proper quoting/format that the database expects
>
   This can be achieved in various ways.

   Certainly, one can keep the meta-data in XOTcl, and create just
   the tables in SQL (see e.g. slide 38ff), where the definitions
   are used to create the tables and the CRUD methods.

   In OpenACS exits already a rich meta-data catalog, stored in
   the database (e.g. acs_object_types, acs_attributes, ...).
   The xotcl-componets use there the pre-existing catalog and can generate
   on the fly XOTcl classes from this. The appropriate method is
   "get_class_from_db", see slide 45 above.

   It is certainly a question, whether the xotcl-type checker is the best
   instrument, since one would like to check e.g. referential integrity,
   or as some other value constraints. Furthermore, the database
   has sometimes other understanding of permissable values to
   certain types than tcl (e.g. for boolean values). In come cases,
   the xotcl-core layer provides value constraints for table definitions.

   The next major release of XOTcl will have several improvements
   in this area. For example, it will use the same type checking mechanisms
   for non-positional arguments and slot values and clean up some
   legacy stuff (i have this - and many more improvements - in my
   leading edge branch, not sure, how much of this will make it
   into the next release).

   best regards
-gustaf neumann