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

Weblog Page

Showing 681 - 690 of 1561 Postings (summary)

[Xotcl] XOTclIDE updated 0.83

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Mon, 12 May 2008 13:58:11 +0200

Hi!

There is new release of XOTclIDE 0.83
http://www.xdobry.de/xotclIDE

Changes:
1) Small fix for compatibility with XOTcl 1.6. This fixes problems this
syntax highlighting and code checker.
2) Debugger will be not blocked by others window grab
3) Some small usability improvements and bug fixes.
4) Code refactoring (Pre Tcl8.4 code parts ware removed)
5) Components of binary Tclkit distributions were updated (Tcl 8.5.2,
XOTcl 1.6, actual sqlite)

Bug reports and comments are welcome.

Artur Trzewik

Re: [Xotcl] Problem with automatic variable unsetting upon return from an instproc?

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

From: Jim Russell <Jim.Russell_at_dynetics.com>
Date: Wed, 19 Nov 2003 12:29:28 -0600

XOTcl is so cool! I like it so much better than incrTcl. This is
exactly what I was looking for. Thank you so much for the help.

Jim

Uwe Zdun wrote:
> Hi!
>
> the -volatile option of new does something like this for local objects in the
> current scope (it uses an "unset" trace set in C). Example:
>
> package require XOTcl
> namespace import ::xotcl::*
>
> Class A
> A instproc destroy args {
> puts "I'm destroyed: [self]"
> next
> }
> A proc x {} {
> A new -volatile
> }
> A x
>
> Does this help?
>
> Uwe

[Xotcl] xotcl 0.9 for linux debian

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

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Tue, 26 Mar 2002 16:09:45 +0100

Dear XOtcl list,

I have some problems to install the latest xotcl version on a linux debian
platform. The current debian package is 0.85 and I would really like to install 0.9.

So I have tried to install the full source distribution
(http://media.wu-wien.ac.at/download/xotcl-full-0.9.3.tar.gz), but, as tcl/tk debian
include installation is in the same directory (/usr/include/tcl8.3), it's difficult
to tell configure how to deal with it.

1) I have tried:
        ./configure
but the tcl configuration directory is not found:
checking for Tcl configuration... configure: warning: Can't find Tcl configuration definitions

2) Then I have tried:
        ./configure --with-tcl=/usr/lib/tcl8.3 --with-tk=/usr/lib/tk8.3

but, when running make:

cc -DVERSION=\"0.9\" -DXOTCL_LIBRARY=\"/usr/local/lib/xotcl0.9/library\" -I/usr/include/tcl8.3/tcl-private/generic -I/usr/include/tcl8.3/tcl-private/unix -I"./../generic" -I"./../unix" -I"/usr/include" -g -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -fPIC -g -DXOLIBPKG=\"/usr/local/lib/xotcl0.9\" -DXOTCLVERSION=\"0.9\" -DXOTCLPATCHLEVEL=\".3\" -c `echo ../unix/xotkAppInit.c` -o o/xotkAppInit.o
../unix/xotkAppInit.c:19: tk.h: No such file or directory
../unix/xotkAppInit.c:31: #error Tk distribution TOO OLD

3) And I get the same error when telling configure where to actually find tk.h
(in /usr/include/tcl8.3) :

./configure --with-tcl=/usr/lib/tcl8.3 --with-tk=/usr/include/tcl8.3
cc -DVERSION=\"0.9\" -DXOTCL_LIBRARY=\"/usr/local/lib/xotcl0.9/library\" -I/usr/include/tcl8.3/tcl-private/generic -I/usr/include/tcl8.3/tcl-private/unix -I"./../generic" -I"./../unix" -I"/usr/include" -g -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -fPIC -g -DXOLIBPKG=\"/usr/local/lib/xotcl0.9\" -DXOTCLVERSION=\"0.9\" -DXOTCLPATCHLEVEL=\".3\" -c `echo ../unix/xotkAppInit.c` -o o/xotkAppInit.o
../unix/xotkAppInit.c:19: tk.h: No such file or directory
../unix/xotkAppInit.c:31: #error Tk distribution TOO OLD
make[1]: *** [o/xotkAppInit.o] Error 1

4) I have also tried to specify both include and library, as told by configure --help:
        ./configure --with-tcl=/usr/lib/tcl8.3 --with-tk=/usr/include/tcl8.3,/usr/lib/tk8.3
but the syntax is not recognized?


So my question is: is there a debian package going to be distributed for the 0.9 version?
Does this ditribution contain the necessary .h, or is there a xotcl-dev distribution?
Or, could someone help?

Thanks a lot in advance,

-- 
Catherine Letondal -- Pasteur Institute Computing Center

[Xotcl] Re: Status of the bugs I reported/could people resend their replies to those bugs

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

From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Tue, 6 Apr 2004 07:06:16 -0700

Hi Gustaf...

On Mon, 5 Apr 2004 20:51:09 +0200
"Gustaf Neumann" <neumann_at_wu-wien.ac.at> wrote:

> On Friday 02 April 2004 05:37, Jim Lynch wrote:
> > Hi,
>
> Hi Jim,
> sorry for the delayed answer, i was last week on vacation.
>
> > Last month I reported three bugs in the configure step of the xotcl
>
> you mean last week? well, last week is also last month, just to remove
> disambiguity, i have received no earlier mails from you.
>
> > build process. While I was reporting those bugs and for a few days
> > after, I was working on my mail, and so turned off the list's replying
> > to me at first.
> >
> > Is there a different way to report bugs? Could someone tell me the
> > status of these bugs? Would anyone like copies of the bug reports
> > sent to them?
>
> as uwe pointed out, we have since last week serious hardware
> problems on our webserver.
>
> i have received four mails from concerning a) the aolserver, and b)
> tclsh without path.
>
> concerning (a) you are right, determining to build with AOLserver
> from the `pwd` is not pretty, also the hardwired path to the
> AOLserver include directory. i have changed that
> right now. note, that making an aolserver module is only an issue
> for AOLserver 3.*, the AOLserver 4* series does not require this
> at all. Therefore, i have named the configure switch
> --with-aolserver3=AOL_INCLUDE_DIR
> where you have to specify the include directory.

Suggestion, howbout the prefix dir instead? That way, any time you add
dependendency on another kind of thing, you already planned for the
stem dir. Besides, if this switch is to represent the include dir, it
is misnamed, and should be named something like --with-aolserver-inc=.

So if you said to aolserver, "./configure --prefix=/x/y ...", then you'd
say to xotcl, "./configure --with-aolserver3=/x/y ..."

> Concerning the second problem, you wrote:
> >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.
>
> well, can you be more specific, where this happens?
> XOTcl uses in configure.in SC_PROC_TCLSH
> and uses in all the Makefiles $TCLSH_PROG as far i can see.
> What version of xotcl are you working with?

I'm using xotcl-1.2.0; my situation is I'm building using a tcl
I built specifically for an aolserver4. It's not the system tcl
and its bin dir is not in my path.

As far as I've been able to determine, the tclsh which is called
has to be able to find the libxotcl thing. Apparantly, not every
tclsh I have is able to do that, so I looked closely at the
SC_PROG_TCLSH macro (having traced the problem down to that macro)
and noticed that it doesn't try to use the tclsh specified in the
supplied tclConfig.sh, which as far as I know is the only correct
choice (should use the tclsh linked to the same libs that were
used in the build process of xotcl, and that can find the modules).

The fix for this is easy, and a patch has already been sent to the list.

> -gustaf

-Jim

--
Jam sessions community web site: http://jam.sessionsnet.org

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 14:53:50 +0100

One general observation about our discussion: it is often not clear,
what "namespace"
refers to, a "tcl namespace" or some kind of an abstract namespace.
tcl-namespaces
are different to what people understand e.g. in C++ under namespaces. a
tcl-namespace
consists essentially of a name (fully qualified and simple), three
hash-tables, one for vars,
one for child-tcl-namespaces, one for commands and some info for
managing these
(e.g. epoch-handling, namespace resolvers, state-handling during
deletion...).
see in tclInt.h for more details.

in many respects, tcl-namespaces contain much functionality useful for
xotcl objects
as well. Allthough tcl-namespaces are no perfect fit in many respects
for xocl,
it is certainly not useful to duplicate its functionality in xotcl
without some very
good reasons. i for my part would be happy to have a lower level
interface to these
functionalities, having e.g. the management for cmds different from the
management
of the vars, but this would be a deeper change in the tcl-internals,
requireing many
interface changes.

Kristoffer Lawson schrieb:
>
> On 19 Mar 2006, at 14:09, Scott Gargash wrote:
>
>> xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/19/2006 04:08:40 AM:
>>
>> >
>> > On 19 Mar 2006, at 00:12, Scott Gargash wrote:
>> > >
>> > > When would you need the namespace of the object?
>> > I have only ever needed the namespace of an object
you mean, you needed to use the explicit "requireNamespace", since
namespaces are used all over in tcl as discussed in depth. as soon you
define e.g. a child object or a proc for an object, a tcl-namespace is
automatically added.
>> which attaching
>> > traces to variables (f.ex. with Tk), but for that it is,
>> > unfortunately quite necessary.
> I haven't used it yet, but doesn't the "trace" method handle this?
actually, the xotcl trace method does not require an object-specific
namespace for
variable traces. one can add a trace to an xotcl instvar, alhough this
is not in a
tcl-namespace.
>>
>> Where do you see this happening? Do you mean losing the original
>> representation via shimmering, or something else?
> I've seen it happen with scripts given to [after]. I was actually very
> surprised by this, but at some point I was witnessing those scripts
> becoming strings and thus losing the original Tcl_Objs inside them
> (the scripts were built as lists).
There are unfortunately many cases, where this happens, even for careful
programmers,
avoiding obvous cases of shimmering. Unfortunately this tend to happen
often in
complex situations: i was recently caught be such a behavior
in connection with ttrace (demand loading for naviserver/aolserver based on
tcl's unknown mechanism), which is by itself quite complex, and it happend
only in recursive cases (while resolving one unknown command, another
unknown
was triggered). I have seen it happen as well with after or other callbacks.

-gustaf neumann
>
> / http://www.fishpool.com/~setok/
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

Re: [Xotcl] Announcing: Spindle v0.1 — An MVC web framework for Tcl/XOTcl

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

From: Victor Mayevski <vitick_at_gmail.com>
Date: Fri, 21 May 2010 16:11:51 -0700 (PDT)

>As for the Ruby / Tcl thingy ... first I've ever heard of it. Got any
>pointers to it?


http://woof.magicsplat.com/woof_home

RE: [Xotcl] xotcllib?

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

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Mon, 18 Oct 2004 13:44:26 -0400

> -----Original Message-----
> From: Jeff Hobbs [mailto:jeffh_at_ActiveState.com]
> Sent: Sunday, October 17, 2004 6:22 PM
> To: Schofield, Bryan (GE Transportation); xotcl_at_alice.wu-wien.ac.at
> Subject: RE: [Xotcl] xotcllib?
>
>
> > xow - A megawidget framework. This is a package that allows
> > xotcl objects to be megawidgets.
>
> Does this handle the option db correctly, do composition
> of megawidgets, handle focus and events right, etc.?

No, currently doesn't handle the option db. This is a tricky area of building megawidgets. An xow widget can be based off of any other existing widget or megawidget. That can make things a little more complicated since xow widgets can & will pick up option db settings for base widgets and the -class option isn't available for most widgets. Personally, I am aware of this shortcoming and work around it. I'd rather not have this feature than have one that works partially and is unpredictable. Since I haven't had the time to devote to writing a complete implementation, I haven't done anything with it.

There is no special code to handle composition of megawidgets, focus, or event processing.





>
> > xcentuate - a theme engine for tk. This isn't all that
> > important on windows, but on unix tk often needs a little
> > help looking good. This package provides a very simple method
> > of defining and changing the look of tk apps. It can even do
> > it on the fly.
>
> I would not propagate this in favor of Tile. There is
> also already the 'style' package in tklib (which again
> may be abortive when Tile becomes part of 8.5). What
> features does xcentuate really provide? Should they not
> just go into 'style'?

I'm not sure what "style" package you are refering to. I see none in the docs for TkLib, but maybe I missed them or it's not in the latest official release. I did manage to google up a "as::style" package that you appear to have written. So I'll assume that's the package to which you refer.

xcentuate provides the common things like colors and borderwidth for widgets. It also provides some named colors and eventually named fonts. I have some good font generation routines already, I just need to convert them to xotcl and integrate them. The widget classes and options applied to those classes are not hard coded in xcentuate. It can be trained to apply style to new widget classes or change what options are applied. Finally, xcentuate is OO. I like objects, I like them alot. This package works well for me but I look forward to Tile being part of 8.5 so I can declare this obsolete.

Below is an example of a LookAndFeel that shows what xcentuate can control right now. This particuler LookAndFeel gets applied by default on unix. Xcentuate will also learn what tk looks like by default so there is always a "default" LookAndFeel that can be applied. Oh, xcentuate can change styles (LookAndFeels) on the fly.

   LookAndFeel lightgrey \
       -name "Light Grey" \
       -description "A simple light grey palette" \
       -activebackground grey90 \
       -activeforeground red \
       -background grey80 \
       -disabledbackground grey85 \
       -disabledforeground grey40 \
       -foreground black \
       -highlightbackground grey80 \
       -highlightcolor red \
       -insertbackground red \
       -readonlybackground grey90 \
       -selectbackground skyblue \
       -selectcolor red \
       -selectforeground black \
       -textbackground white \
       -textforeground black \
       -troughcolor grey75 \
       -borderwidth 1 \
       -labelframepad 4 \
       -labelframebd 2 \
       -texterrorbg \#fee \
       -texterrorfg red3 \
       -textwarnbg PeachPuff \
       -textwarnfg orange2 \
       -textokbg \#dfd \
       -textokfg green3 \
       -textnotebg \#ffd \
       -textnotefg yellow3 \
       -textinfobg \#def \
       -textinfofg blue2
   lightgrey apply





>
> > xout - a unit testing framework. I know, I know, tcl already
> > provides one, tcltest. But I found tcltest to be too
> > cumbersome and clunky. I'd write some tests, but maintaining
> > those tests often was neglected because of the amount of
> > programming overhead needed to write complex test cases. xout
>
> Did you compare against tcltest v1 or v2?

Version 2. Tcltest is more powerful, no question about that. But for testing complex scenarios, I like to build on the success of one test later. For example, consider the following distinct events that I can test, where later tests use something from previous tests.
 
  1. Can I create object X?
  2. Can object X do something?
  3. Can object X do something else?
  4. Can I delete object X and it clean up properly?

Thing can get way more complicated than that, too. Imagine trying to test db or remote server interaction. With tcltest, I'd have to create object X or connect to a db or server in the setup of every test. I can appreciate isolating tests from one another so that one test doesn't impact another, which is what tcltest does. To achieve that, I have two level in my test hierachy. One is the TestSuite. No two suites can interact with each other. They run in their own iterpreter from scratch. A TestSuite has one or more Tests that *can* interact with each other. Also, on a side note, I hate having to specify a test name with tcltest.

   test example-1.1 {test file existence} -setup {
      set file [makeFile {} test]
   } -body {
      file exists $file
   } -cleanup {
      removeFile test
   } -result 1

It's fine until you realize next month that you need a new test, and that it make more sense from a readability viewpoint to stick it in between example-1.1 and example-1.2. Do I call it example-1.1.5 or renumber the other tests below? The test name doesn't add much to me, the tester. It's the description that matters. For comparison purposes, xout test file would be structured as follows:

    TestSuite foo \
        -description "blah" \
        -setup {set file [makeFile {} test]} \
        -cleanup {removeFile test}
    foo test \
        -description "test file existence"
        -result 1 \
        -script {file exists $file}

Finally, xout is only a framework. It can be embedded into other applications such as an IDE. That can easily find and query TestSuite objects to run and get their results. Just so happens that the GUI can also be embedded in or run standalone.




>
> > I mention all of this because if other have some handy xotcl
> > packages, I'd be interested in creating a formal xotcllib
> > project. Perhaps something at sourceforge. I'll be making
> > these available soon either way.
>
> I think that would be a handy thing as an addon.
>
> Jeff Hobbs, The Tcl Guy
> http://www.ActiveState.com/, a division of Sophos
>
>

I threw some screen shots of xcentuate & xout in action on my (unfinished) website if anyone wants to take a look.
http://www.abschofield.com/code/ss/

Sorry for being long winded.

-- bryan

[Xotcl] Bug or feature in 1.1.1. Access to subobjects

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Tue, 30 Dec 2003 12:25:13 +0100

Hi!

I have discovered some interesting change in 1.1.1 that I could not find in
ChangeLog.

In 1.1.1 one can access to subobject as method call
Example
b::a
can be produced as
b a
My problem is that I have "a" as method and as subobject from b.
Can I force "b" to invoke method "a" and not return subobject "a"?

Artur Trzewik

Example:
% [artur_at_localhost xotclIDE]$ /opt/tcl845/bin/tclsh8.4
% package require XOTcl
1.1
% namespace import xotcl::*
% Class A
::A
% Class B
::B
% B create b
::b
% A create b::a
::b::a
% b a
::b::a
% [artur_at_localhost xotclIDE]$ /opt/tcl844/bin/tclsh8.4
% package require XOTcl
1.0
% namespace import xotcl::*
% Class A
::A
% Class B
::B
% B create b
::b
% A create a
::a
% b a
b: unable to dispatch method 'a'
%

Re: [Xotcl] Reference manual for NX

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

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Wed, 08 Aug 2012 12:13:06 +0200

Hey Jon!

> Is there one? One planned?

This one is on me :) Yes, there has been one in preparation for quite a
while now, but I have not managed to complete it by now, both content-
and presentation-wise, I am afraid.

I understand that this is a major entry barrier. Mea culpa. For now, the
best I can offer is a cross-reading exercise:

Gustaf Neumann's migration guide maps XOTcl concepts to NX concepts.
So by reading up basics on XOTcl (ie manual and tutorial at
http://media.wu.ac.at/doc/index.html), you can then jump to the
"closest" NX equivalents by following the migration guide at:
http://next-scripting.org/docs/2.0b3/doc/nx/nx-migration/index1

//stefan

XOTcl/NX mailing list by XOTcl 1.3.1 (XOTclIDE)

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Thu, 2 Sep 2004 20:27:13 +0200

Hi!

XOTclIDE does not run with XOTclI 1.3.1 because
of uncompatibility of the namespace handling.
Thank to Michael Heca for noting it.

I have played a little with xotcl and discovered following
behavior incompatibility that make problems by XOTclIDE.

Examples:

package require XOTcl
namespace import xotcl::*

Object O
Class O::B
O::B instproc test {} {
    Class A
}
O::B create o
o test

# XOTcl 1.2 returns ::A
# XOTcl 1.3 returns ::O::A

using Class ::A solves the problem

Another one should not occours by any XOTcl programm
but by XOTclIDE this happened

Object O
Class O::A
O::A proc test {} {
    A self
}
O::A create A
O::A test

# XOTcl 1.2 returns ::A
# XOTcl 1.3 returns ::O::A
# using ::A solves the problem

So probably even with XOTcl 1.3.2 XOTclIDE will not work
out of the box and need some changes.
So all XOTclIDE user be patience and wait for new version of XOTclIDE
that supports XOTcl 1.3. I will need also some time to support
new XOTcl functionality.

Artur Trzewik

Next Page