Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 6 Jun 2001 11:08:16 +0200

On Wednesday 06 June 2001 10:27, you wrote:
> On Tuesday 05 June 2001 21:44, Gustaf Neumann wrote:
> > Dear XOTcl community,
> >
> > If you have interest to get access to the current development
> > version of XOTcl (which is exactly 0.85-p1) you can use bitkeeper to
> > get the source tree. Bitkeeper (http://www.bitkeeper.com) is
> > an open source version control system.
>
> Hopla !
> This "BitKeeper" is a commercial product requiring license ?

 license yes, "commercial" in certain cases. bitkeeper has different kind
 of licenses (including a commercial one). It is free for multi-user when
 "open logging" is activated. See below.

 look at the list of projects using bitkeeper, it includes e.g. mysql.
 http://www.bitkeeper.com/v2_logging/desc.html

 the main reason for me to switch from cvs to bitkeeper was that it allows
 renaming of files and directories. I am still somewhat struggling with
 it, but it seems quite a nice product. Larry McVoy (one of the persones
 behind bitkeeper) wrote some time ago about a distributed
 source code management system, which certainly influenced bitkeeper...
 http://www.bitmover.com/lm/papers/smoosh.ps

 -gustaf

PS: i have no personal interest in bk, nobody is forced to use bitkeeper,
 it is just an easy way to access our development verison. we will continue
 to distribute tar files as well.
 


bk licensing(1) BitKeeper User's Manual bk licensing(1)

NAME
       bk licensing - BitKeeper Licensing Overview

DESCRIPTION
       This section briefly explains the licensing models. See
       the references for more detailed information.

       BitKeeper has multiple licensing models:

       =>free with no Open Logging (aka single user), license
       is the BKL.
       =>free with Open Logging, license is the BKL.
       =>commercial, license is the BKCL.

FREE USE WITH NO LOGGING
       BitKeeper can be used for free, without licensing or Open
       Logging, if the repository is single user. To create a
       single user repository, at setup time pick a permanent
       user name and a host name and add to the Bit-
       Keeper/etc/config file; all deltas will appear to be made
       by this user.

       The lines in the config file must look like this:

           single_user:<user_name>
           single_host:<host_name>

       The <user_name> and <host_name> can be anything, but once
       they have been chosen they cannot be changed. If changed
       the repository will be seen as a multiple user repository
       by BitKeeper and will either need a license key or will
       need to participate in Open Logging.

       To change a single user repository to a multiple user
       repository see bk multiuser.

   WARNING
       Single user repositories only work on repositories that
       have less than 1000 files. If the maximum is reached, the
       repository will not allow any more changesets to occur.
       To use the repository again, the repository must be setup
       for openlogging or a commercial license must be purchased.

       Once a repository is changed from a single user to multi-
       ple user repository it can not be changed to a single user
       repository again. Once a multiple user repository it must
       be setup for openlogging or a commercial license must be
       purchased.

       If you are looking for the BitKeeper License for free use
       (BKL), see bk help bkl.

FREE USE WITH LOGGING
       BitKeeper may be used for free, without any functionality
       loss or other restrictions, if Open Logging is used.

       To setup openlogging, add the following line to the config
       file:

           logging:logging_at_openlogging.org

COMMERCIAL USE
       The use of BitKeeper without Open Logging enabled requires
       a commercial license key. You can get a temporary license
       by sending a mail request to bk_license_at_bitmover.com.

       Once the license key is obtained, add a line to the Bit-
       Keeper/etc/config file that looks like:

           license: <license key>

SEE ALSO
       bk help bkl
       bk help config-etc
       bk help multiuser
       bk help openlogging

CATEGORY
       Licensing
       Overview

BitMover, Inc 2001/02/02 1

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 08 Dec 2010 08:31:52 +0100

On 08.12.10 07:35, Victor Mayevski wrote:
> Thank you Gustaf,
>
> I guess I just expected that things will be automatically tracked no
> matter in which namespace I invoked the nx::Class command.
maybe your assumption was that since you create a class ::C with
"nx::Class", then init of C will run in the "nx" namespace;
... but it is not, it is running in ::.

The reason, why using nx there is probably not a good
idea is a follows: Consider that one might want to create e.g.
other cmds (objects/procs/...) from a method without
explicit namespaces. If the current namespace would be
nx, these cmds would be created in the nx namespace,
probably not always desired.

XOTcl/nx tries to follow Tcl with the namespace rules.
If a proc foo is contained in a namespace X
(place of definition), then the current namespace in foo is X.
For objects/classes this is not so obvious, but similar.
If a class is created in a namespace X, its methods are
executed in that namespace.

============================================
    package req nx

    #
    # your application namespace
    #
    namespace eval ::app {
       proc foo {} {puts proc-current=[namespace current]}

       nx::Class create C
       C method init args {puts current=[namespace current]}
    }

    #
    # using the definitions
    #
    ::app::foo
    ::app::C create c1
============================================

The behavior is the same if ::app::foo or ::app::C are
created from some other namespace (eg the
toplevel namespace) with the explicit namespace
in the name. So, not the namespace of the invocation
is important, but the namespace of the definition (which
certainly might be the same).

Btw, one can use "namespace import ::nx" or
"namespace path" not only in the global namespace,
but in the namespace of definition.

============================================
     package req nx

    #
    # your application namespace
    #
    namespace eval ::app {
       namespace path ::nx

       nx::Class create C
       C method init args {puts self=[self]; next}
    }

    #
    # using the definitions
    #
    ::app::C create c1
============================================

Hope, this helps a little....

-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 10 Oct 2010 13:25:59 +0200

  On 09.10.10 21:05, vitick_at_gmail.com wrote:
> Don't know if the mailing list is the best place to post bug reports. Let me know the correct way to do it.
let's hope, there are not to many!
if the report is short (like the current one), you can send
it here.
if it is more complex, please send to me + stefan.

the requiredness of several info commands was still incorrect.
these are fixed by now.

-gustaf neumann
> On a clean 32 bit debian based system, fresh compilation of TCL 8.5.9 and XOTcl/Next, TCL will crash when calling "obj info has type" without arguments or with wrong arguments:
>
> nx::Class create C
> C create obj
> obj has type
> tclsh: ./generic/nsf.c:9853: IsSubType: Assertion `cl&& subcl' failed.
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Wed, 1 Feb 2006 09:44:01 -0500

Kristoffer,

I hit the same problem in a persistent application I am working on. My
solution
is to define a new method, delete, that destroys the object and deletes
the object from the persistent storage. Just destroying the object does not
delete it from persistent storage.

Instead of explicitly calling destroy on objects, I just call delete. My
persistence
layer is snapshot based, but delete instantly deletes the persistence
for an object. This has the problem of a shrinking set of persisted objects
between snaphots.

Have you worked with prevayler(www.prevayler.org)? In my java days I used
this
for a while. I'd like to make a port of this to xotcl one day.

Ben

On 01/02/06, Kristoffer Lawson <setok_at_fishpool.com> wrote:
>
> When XOTcl exits, it seems that the [destroy] method is called on all
> objects. The first question is whether this is wise .. possibly. The
> problem is I would like to build a transparent layer for persistence
> storage which could be applied to a wide range of applications. The
> problem naturally is that the objects in the persistence storage get
> destroyed when the application exits :-)
>
> / http://www.fishpool.com/~setok/
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

--
Lao Tsu said:
When the fool learns the Way,
   He laughs at it.
   Yet if the fool did not laugh at it,
   It would not be the Way.
   Indeed, if you are seeking the Way,
   Listen for the laughter of fools.

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 16 Sep 2006 00:11:13 +0300

On 15 Sep 2006, at 21:28, Scott Gargash wrote:
>
> I've stepped into the XOTcl code and it looks like it's searching
> the the interpreter's call stack to determine the active object but
> as near as I can tell, my C-defined methods don't correctly
> annotate Tcl's call stack.

For the record I have stumbled across a related problem with at least
some version of XOTcl. This was some while ago so perhaps it's not
true for 1.5. I should've recorded the exact circumstances back then,
but I was so busy that I didn't get round to it.

Basically, if I remember correctly, I found that doing [uplevel 1
self] did not always appear to work as expected. Ie. in some
situations [self] would be reported wrong or was it that it did not
work at all. I cannot recall the exact circumstances and I believe I
wasn't certain what they were at the time (hence the need to spend
some effort with it, which I did not get round to). OK, so this isn't
likely to be a very useful report, if one can even call it that, but
I thought it might be worth mentioning in case it might ring a bell
or two with XOTcl developers.

Oh, also errors taking place inside filters might get really strange
results. Again, this might be fixed in 1.5.

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Wed, 11 Aug 2010 12:43:07 +0300

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

> I was never happy with the way how searchDefault works in
> xotcl 0.* and xotcl 1.*,
> so the missing detailed documentation discourages people to
> depend on it.
> The method "searchDefaults" is not defined on
> ::xotcl::Object but on the
> parameter class. This will change in the near future,
> parameter classes
> in general will disappear.

OK, thanks, Gustaf, for the clarification! Should this be mentioned in the documentation, as searchDefaults is only referred to in one place (create)? Even if it is just to say that this behaviour shouldn't be relied on for the future and use is discouraged.

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

From: Cristian Chaparro <cristian.chaparro_at_univ-perp.fr>
Date: Wed, 09 Jun 2010 14:51:22 +0200

Hi all,
I would like to have some help on an error message that I got recently.
The code has been working for about 2 years without giving any error and
today it didn't want to start. I have XOTcl 1.6.6 with tcl 8.5.8 on a
debian machine.

The error message:
wrong # args: should be "init" during '::Sim4 slots'

produced when sourcing this code

Class Sim4 -slots {
     Attribute file1
     Attribute file2
     Attribute options Default ""
}

Sim4 instproc init {} {
     my instvar hits
     ...
}

Any help is greatly appreciated.

Thanks
Cristian

-- 
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
CRI UPVD http://www.univ-perp.fr

From: Andriy Tkachuk <ant_at_imt.com.ua>
Date: Mon, 22 Apr 2002 10:50:52 +0300 (EEST)

thank you very mutch!

andriy.

On Fri, 19 Apr 2002, Uwe Zdun wrote:

> Hi Andriy,
>
> this was a little bug. We have closed down the filter chain upon the "msg"
> method but the filter was not done with its own next. I'll attach an xotcl.c
> file that should fix the problem (the fix will also be in the next xotcl
> release ... but as this is a quite unusual case we don't produce a full patch
> release for this fix). Simply replace the xotcl.c file in the distribution
> and re-compile ...
>
> --uwe
>
>
> On Wednesday 17 April 2002 05:46 pm, Andriy Tkachuk wrote:
> > Hello! :)
> >
> > How it must works, when in pre/post part of filter
> > object calls his procs that calls next?
> > Situation like here:
> >
> > Class A
> > A instproc msg msg {
> > puts "puts: $msg"
> > }
> >
> > Class B -superclass A
> > B instproc msg msg {
> > next
> > }
> >
> > B instproc my_filter args {
> > my msg "before next in filter"
> > next
> > }
> >
> > B b
> >
> > b filter my_filter
> > b msg bb
> > puts: before next in filter
> >
> > that's all!: there is no "puts: bb".
> >
> > if filter like this:
> >
> > B instproc my_filter args {
> > my msg "before next in filter"
> > next
> > my msg "after next in filter"
> > }
> >
> > then:
> > "too many nested calls to Tcl_EvalObj"
> >
> > Thank you.
> >
> > _______________________________________________
> > Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

--
  Because strait is the gate, and narrow is the way, which leadeth unto
   <b>life</b>, and few there be that find it. (MAT 7:7)
 <b>Ask</b>, and it shall be given you; <b>seek</b>, and ye shall find;
   <b>knock</b>, and it shall be opened unto you... (MAT 7:14)

From: Eckhard Lehmann <eckhardnospam_at_gmx.de>
Date: Sun, 20 Apr 2008 16:00:23 +0200

Version 1.3.0 of Tloona Tcl/Tk IDE is out. Here are the highlights for
this release:

* various bugfixes
* client console is able to read stdin
* code browser understands XOTcl meta classes and slots
  (via the -slot argument)
* Added some files for creating Mac OS X bundles (more on this will
  follow on the blog at tloona.sourceforge.net)
* code definitions can be sent to the client console: proc, method
  (Itcl), instproc, class proc, Class, meta Class (XOTcl) with
  <Control-Return>

The latter makes it a pleasure to test your programs and procedures
while you are developing them. Just load the program into the client
console, then edit the procedures, classes etc. and repeatedly send them
to the console with <Control-Return>. You can immediately try out what
you have done... this makes you even more productive!

There is a new screenshot, showing how Tloona is running Tclhttpd inside
it's client console. Combined with the ability to send code definitions
to the console this is a very pleasant way to develop and test web
applications rapidly.

Here you go:
http://tloona.sourceforge.net/
http://sourceforge.net/projects/tloona

-- 
Eckhard

From: Uwe Zdun <uzdun_at_k2.informatik.uni-essen.de>
Date: Thu, 21 Dec 2000 12:25:39 +0100 (CET)

On Thu, 21 Dec 2000, Kristoffer Lawson wrote:

>
> Attached to this post I have a slightly fixed version of xodoc.

 great
 
 ...

> What I didn't do:
>
> I was going to add an extension facility so that applications could
> specify their own handler-objects for certain special sections. Like in
> Class Foo above I might have a section {Attribute Aliases} in addition to
> errorCodes (as I do). I would like to specify a AttrAliasDocHandle object,
> for example, which would have the method "toHtml" (if outputting HTML)
> that gets called when the section {Attribute Aliases} is encountered, with
> the data passed to it as an argument. This would then return a nice HTML
> table documenting my aliases.
>
> The syntax to create an extension might be something like this:
>
> _at_ @DocExtension Class {Attribute Aliases} AttrAliasDocHandle
>

Hi Kristoffer,
 
FYI just a short note in response: I didn't make it to look into the xodoc
issues yet (sigh) and probably won't make it this year :) I just want to
let you know that we were discussing to extend the basic mechanism, that
xodoc+makeDoc use, to a more generic framework for conditional &
customized parsing. There are several application which require similar
facilities. The extension facility that you propose is one important
ingredient.

one general aim is to use the introspection facilities as much as possible
without really executing the program (but only parts of it, like
namespace in xodoc+makedoc). That way we can build for instance a
graphical representation as documentation of a script ... as oppossed to a
graphical documentation of a running script. So having such callback
handler objects (as you propose for the HTML table representation), would
also be important to build such documentation visualizations.

--Uwe



Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de