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

Weblog Page

Showing 901 - 910 of 1561 Postings (summary)

[Xotcl] Compiling xotcl 1.6.6 on Visual Studio 2010

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

From: Shedi Shedi <shedis_at_gmail.com>
Date: Fri, 1 Oct 2010 09:10:07 +0300

Hi,

I'm trying to compile on vs 2010 and getting the following error

nmake -f makefile.vc OPTS=threads TCLDIR=d:\tcl8.5.9
INSTALLDIR=c:\aolserver xotclshells

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.

makefile.vc(344) : fatal error U1023: syntax error in expression
Stop.

Any ideas?

TIA
Shedis
Shedis_at_gmail.com

[Xotcl] Re: [Xotcl] The debian packages

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

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Thu, 11 Jan 2001 18:36:53 +0100

On Thursday 11 January 2001 18:15, Kristoffer Lawson wrote:
> Just tested the debian packages for XOTcl 0.83 by Teemu and they seem to
> be working fine now, including the pkgIndex.tcl generation, which was a
> problem before.
>

FYI, we have just written a Sdbm wrapper with complete src code in the XOTcl
distribution, which will be included in the next XOTcl version ...
this should solve the problem with the Gdbm version in Debian (and on
Windows).

Moreover, we'll probably create a minimal man-page for xotclsh & xowish ...

Regarding tclexpat: which version is used in debian? I don't think that its a
big issue (at the moment XOTcl uses tclxml per default), but for
compatibility with the rest of XOTcl I've renamed the produced lib to
libtclexpat.so ... that should at least prevent that an existing tclexpat.so
is overwritten (not in 0.83!). At the moment we have performed some
modification in configure+make of tclexpat, but the lib should be identical
to 1.1. Probably we'll add someday an xotcl-wrapper, which directly produces
the object-interface with the XOTcl C API.


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

[Xotcl] Re: [Xotcl] old bug

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

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Wed, 24 Jan 2001 18:32:04 +0100

On Saturday 20 January 2001 04:39, Kristoffer Lawson wrote:
> Apparently a bug I think was fixed at one point has managed to creep in:
>
> [~] Class Foo
> Foo
> [~] Foo instproc init {foo} {
>
> > [self] instvar {foo fooAlias}
> > puts "yeah"
> >}
>
> [~] Foo ob bar
> variable "foo" already exists
> while evaluating {Foo ob bar}
>
> Ie. although an alias is created, the foo variable conflicts.
>

I don't think that we have really fixed this bug already, because with
Tcl_VariableObjCmd & Tcl_UpVar (which we have used), we can't get around this
problem. I've implemented a solution, which is rather complicated & copies
alot of Tcl's internal code, because Tcl does not export some important
functions ...

I hope we find something more simple ... but I'll attach the fix for the time
being. If you require it now, please exchange the function
GetInstVarAliasIntoCurrentScope in xotcl.c against the code attached down
below. Otherwise, it'll be also in 0.84.

--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
#############################################################################
/*
 * We need NewVar from tclVar.c ... but its not exported
 */
static Var *NewVar() {
  register Var *varPtr;
  
  varPtr = (Var *) ckalloc(sizeof(Var));
  varPtr->value.objPtr = NULL;
  varPtr->name = NULL;
  varPtr->nsPtr = NULL;
  varPtr->hPtr = NULL;
  varPtr->refCount = 0;
  varPtr->tracePtr = NULL;
  varPtr->searchPtr = NULL;
  varPtr->flags = (VAR_SCALAR | VAR_UNDEFINED | VAR_IN_HASHTABLE);
  return varPtr;
}
/*
 * Provide functionality similar to Tcl's VariableObjCmd for instvared
 * vars with alias (VariableObjCmd does not accept aliases)
 *
 * We have to copy a lot of code from MakeUpvar, because Tcl does not
 * export it (sigh)
 */
static XOTCLINLINE int
GetInstVarAliasIntoCurrentScope(Tcl_Interp* in, char* varName, char* newName) 
{
  Interp *iPtr = (Interp *) in;
  Var *varPtr, *otherPtr, *arrayPtr;
  int result;
  char *tail, *cp;
  CallFrame frame;
  Tcl_CallFrame *procFrame;
  CallFrame *savedFramePtr = NULL;
  CallFrame *varFramePtr;
  int new;
  Tcl_HashEntry *hPtr;
  Tcl_HashTable *tablePtr;
   
  /* Look up var in the current namespace context, creating
   * it if necessary. */
  otherPtr = TclLookupVar(in, varName, (char *) NULL,
			  (TCL_NAMESPACE_ONLY | TCL_LEAVE_ERR_MSG), "define",
			  /*createPart1*/ 1, /*createPart2*/ 0, &arrayPtr);
  if (newName == NULL) {
    return XOTclVarErrMsg(in, "can't define alias to ",
			  varName, ": alias not given.", NULL);
  }
  if (otherPtr == NULL) {
    return TCL_ERROR;
  }
  /*
   * Mark the variable as a namespace variable
   */
  if (!(otherPtr->flags & VAR_NAMESPACE_VAR)) {
    otherPtr->flags |= VAR_NAMESPACE_VAR;
  }
  varFramePtr = iPtr->varFramePtr;
  /*
   * If we are executing inside a Tcl procedure, create a local
   * variable linked to the new namespace variable "varName".
   */
  if ((iPtr->varFramePtr != NULL)
      && iPtr->varFramePtr->isProcCallFrame)  {
    Proc *procPtr = varFramePtr->procPtr;
    int localCt = procPtr->numCompiledLocals;
    CompiledLocal *localPtr = procPtr->firstLocalPtr;
    Var *localVarPtr = varFramePtr->compiledLocals;
    int nameLen = strlen(newName);
    int i;
    varPtr = NULL;
    for (i = 0;  i < localCt;  i++) {    /* look in compiled locals */
      if (!TclIsVarTemporary(localPtr)) {
	char *localName = localVarPtr->name;
	if ((newName[0] == localName[0])
	    && (nameLen == localPtr->nameLength)
	    && (strcmp(newName, localName) == 0)) {
	  varPtr = localVarPtr;
	  new = 0;
	  break;
	}
      }
      localVarPtr++;
      localPtr = localPtr->nextPtr;
    }
    if (varPtr == NULL) {	/* look in frame's local var hashtable */
      tablePtr = varFramePtr->varTablePtr;
      if (tablePtr == NULL) {
	tablePtr = (Tcl_HashTable *) ckalloc(sizeof(Tcl_HashTable));
	Tcl_InitHashTable(tablePtr, TCL_STRING_KEYS);
	varFramePtr->varTablePtr = tablePtr;
      }
      hPtr = Tcl_CreateHashEntry(tablePtr, newName, &new);
      if (new) {
	varPtr = NewVar();
	Tcl_SetHashValue(hPtr, varPtr);
	varPtr->hPtr = hPtr;
	varPtr->nsPtr = varFramePtr->nsPtr;
      } else {
	varPtr = (Var *) Tcl_GetHashValue(hPtr);
      }
    }
  
    if (!new) {
      if ((varPtr == otherPtr) || TclIsVarLink(varPtr) || 
	  !TclIsVarUndefined(varPtr) || (varPtr->tracePtr != NULL)) {
	return XOTclVarErrMsg(in, "can't set variable alias ", newName, 
			      ": name already exists", 0);
      }
    }
    TclSetVarLink(varPtr);
    TclClearVarUndefined(varPtr);
    varPtr->value.linkPtr = otherPtr;
    otherPtr->refCount++;    
  }
  return TCL_OK;
}

Re: [Xotcl] Encoding problems with web application

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

From: Nikos <nicolas_at_maich.gr>
Date: Mon, 31 Oct 2005 08:53:22 +0200

Erwin Sistinger wrote:

>Hello,
>
>since 1 year i have had a small xotcl web application running on a server
>with Redhat Linux (don´t know the version, changed since), xotcl 1.1 (i´m
>using the actiweb packages), mysql 3.23 and mysqltcl installed on it.
>A few weeks ago the admin of the server upgraded to a new redhat version and
>also to mysql 4.1.14. Since then the encoding of the web pages my
>application delivered was not correct anymore - characters like ü or ä
>weren´t displayed.
>
>
You might try changing the system encoding of the shell, e.g.

"encoding system utf-8"

regards,

nikos

>I changed the charset-information in the html-header to utf8, converted my
>old database (which was in iso88591) to utf8 and upgraded to mysqltcl 3.0.1
>- still no utf8-characters in the html-pages. I tried to find a solution
>within the actiweb code but although i found some lines with "encoding" in I
>it don´t really know what is happening in there - could anybody please give
>me a small hint?
>
>Thanks a lot,
>Erwin
>
>the server´s configuration:
>Redhat Linux 3.0ES
>xotcl 1.1 (i´m using the actiweb packages)
>mysqltcl 3.0.1
>mysql 4.1.14
>
>
>

Re: [Xotcl] Collections

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

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Mon, 12 May 2003 17:36:31 +0200

This corresponds to the idea of making filters etc themselves objects.
I like this idea from a conceptual point of view. Implementation-wise
it could be a larger undertaking ... the problem is that these "collections"
manage different things at the C-code level (Tcl_Obj*s, Cmds, etc) in lists
and hashtables and that some parts are not under control of XOTcl's C code
(children are managed by Tcl in Namespaces). So really a 2.0 issue :)

Uwe


On Monday 12 May 2003 16:47, MichaelL_at_frogware.com wrote:
> This is an item for the suggestion box.
>
> XOTcl uses a number of collections: filters, mixins, children, etc. It may
> perhaps make sense to introduce a real collection class or abstraction,
> and implement those concepts directly *as* collections. Reading through a
> lot of XOTcl code--eg, xoRBAC--you can see that the same themes appear
> over and over again, such as checking to see if an object is already mixed
> in. Right now "append"--and only "append"--is built into the list of
> supplied Object methods (eg, "filterappend"). Rather than flooding Object
> with more and more collection management procs it might be better to
> expose the filter collection as an object that supports operations
> directly (like "append" and "contains" and "remove").
>
> This is more like a 2.0 change--and presupposes that there will be a 2.0.
>
> :-)

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

Re: [Xotcl] Very severe limitation in XOTcl

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, 04 Aug 2010 15:40:07 +0200

Am 04.08.10 14:14, schrieb Kristoffer Lawson:
> I think dropping it is a good decision. It'll be interesting to see what the next XOTcl is like.
>
> How much complexity will the new version be adding? The beauty with XOTcl, especially the earlier versions, was that despite the power of it, it was quite simple (unlike C++). Much like Tcl itself: power, but simplicity. I would be concerned if that gets lost along the way.
>
>
the new object system as a much smaller interface (half the number of
predefined methods) and the whole system is more orthogonal.

See e.g. the paper at and slides from the last tcl tk conference.
http://nm.wu-wien.ac.at/research/publications/b802.pdf
http://nm.wu-wien.ac.at/research/publications/b806.pdf

you can follow the development via git

     git clone git://alice.wu-wien.ac.at/xotcl 2.0.0-develop
     cd 2.0.0-develop
     git branch 2.0.0-develop origin/2.0.0-develop
     git checkout 2.0.0-develop

all the best
-gustaf neumann

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

Re: [Xotcl] rules engine ?

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

From: Andreas Kupries <andreask_at_activestate.com>
Date: Fri, 14 Mar 2008 09:18:18 -0700

http://wiki.tcl.tk/8365
Not for Xotcl, but general links and info. Better than nothing I guess.
--
        Andreas Kupries <andreask_at_ActiveState.com>
        Developer _at_ http://www.ActiveState.com
        Tel: +1 778-786-1122
  -----Original Message-----
  From: xotcl-bounces_at_alice.wu-wien.ac.at
[mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of Luc Rasson
  Sent: Friday, March 14, 2008 7:24 AM
  To: xotcl_at_alice.wu-wien.ac.at
  Subject: [Xotcl] rules engine ?
  Dear XOTcl community,
  Maybe it is not the proper mailing list but I was wondering if
any -business- rules engine based on the RETE algorithm exists for XOTcl ?
(as for example Drools for Java) ?
  If yes, all informations/links/resources are welcome :)
  Thanks & regards,
  Luc Rasson
----------------------------------------------------------------------------
--
  Looking for last minute shopping deals? Find them fast with Yahoo! Search.

Re: [Xotcl] Changing method name and Filters

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: Wed, 29 Aug 2001 13:47:12 +0200

On Wednesday 29 August 2001 00:05, Sheik Yussuff wrote:
> Is there a way for one filter (A say) to change the name of a method
> and pass this new method name with the same args to the next
> filter in sequence(B say)?

 you want to call from D->f1 via next the method C->f2?

 Class C
 C instproc f1 ....
 C instproc f2
 Class D -superclass C
 D instproc f1 {} {
    next
 }

 no, you can't do it. you can do certainly the following:

  D instproc f1 {} {
    if {....some-condition...} {
       [self] f2
    } else {
      next
    }
 }

 -gustaf
PS: there is a way to call methods of a class directly,
but i won't recommend it, since it is going to change in the
next releaese, when XOTcl will be a well behaved extension, and
everything is moved into the xotcl namespace

Re: [Xotcl] Send NULL arg to Class constructor

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: Tue, 28 Apr 2009 01:24:42 +0200

Colin Ross schrieb:
>
> There are potentially 2 ways around this, however, I am unable to find
> information on if either of them are possible:
>
> 1. Allow the passing in of a NULL argument
>
One can call arbitrary methods via configure. You just have just to provide
your own method to handle such a cases, as the default parameter handling
expect always exactly one argument.

==========================
::xotcl::Class Connect -parameter {
    {ssh}
    {ip}
}
Connect instproc telnet {} {
  my set telnet true
}
Connect instproc init {node args} {
  my instvar telnet ip

  # provide a default
  if {![info exists telnet]} {
    set telnet false
  }

  puts telnet=$telnet
  # ....
}

Connect dev node -ip "127.0.0.1" -telnet
==========================

> 1. Prevent the constructor parsing args so that I can parse my own
>
This is as well an option:

==========================
::xotcl::Class Connect

Connect instproc configure args {
  #
  puts stderr "wanna interpret $args"
  #
  # do what ever you want to do with the arguments.....
  #
}
Connect dev node -ip "127.0.0.1" -telnet
==========================


All the best
-gustaf neumann

[Xotcl] nx question

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

From: Rene Zaumseil <r.zaumseil_at_freenet.de>
Date: Mon, 26 Mar 2012 21:52:40 +0200

Hi,

I have a question regarding properties in nx.

A property can be set at creation time with
  <class> create <object> -property value
and later get with
  <object> property
and set with
  <object> property value

What was the reason not to use -property
as method name of the accessor function?
The -property notation seems IMO better
and does not interfere with normal method
names of an object. It is like the option
notation in tk.


Regards,
rene

Next Page