No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Even more [eval] woes
From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 14 Sep 2004 16:36:35 +0300 (EEST)
On Tue, 14 Sep 2004, Gustaf Neumann wrote:
>> In practise this is now causing so many headaches I think I'm going to
>> give up on doing this package using XOTcl that way. There appears to be no
>> (working?) way to run a script within the 'context' of an object, in order
>> to easily parse data which is formed in the style of a Tcl script. This is
>> unfortunate as it would likely have offered clear performance benefits.
>
> If you have some some code, we can look at, we will certainly
> try to help with that.
I'm actually working on a package built on top of normal [binary] which
would allow a clearer definition of the format of the binary data.
Something like:
byenary::scan $data {
option endian little
type cellObject {
short objID
int8 triByteNum
int8 $triByteNum triVisibility
}
format {
object root {
short objNum
short triNum
cellObject $objNum objects
}
object * children {
short objID
short objNum
short triNum
cellObject $objNum objects
}
}
}
The aim is then that it returns a hierarchy of objects to represent the
data. I actually made a version already, but it parses that format
description manually and continuously. Even if I split the script into
lists, I still have to go through that. The format description is
intentionally made to look like a Tcl script with the idea that later I
could evaluate it in the appropriate context and let Tcl do the work (and
also byte compile it).
Now I'm thinking about doing that not by XOTcl mechanisms but namespaces.
Perhaps that could be the best option.
/ http://www.fishpool.com/~setok/
Date: Tue, 14 Sep 2004 16:36:35 +0300 (EEST)
On Tue, 14 Sep 2004, Gustaf Neumann wrote:
>> In practise this is now causing so many headaches I think I'm going to
>> give up on doing this package using XOTcl that way. There appears to be no
>> (working?) way to run a script within the 'context' of an object, in order
>> to easily parse data which is formed in the style of a Tcl script. This is
>> unfortunate as it would likely have offered clear performance benefits.
>
> If you have some some code, we can look at, we will certainly
> try to help with that.
I'm actually working on a package built on top of normal [binary] which
would allow a clearer definition of the format of the binary data.
Something like:
byenary::scan $data {
option endian little
type cellObject {
short objID
int8 triByteNum
int8 $triByteNum triVisibility
}
format {
object root {
short objNum
short triNum
cellObject $objNum objects
}
object * children {
short objID
short objNum
short triNum
cellObject $objNum objects
}
}
}
The aim is then that it returns a hierarchy of objects to represent the
data. I actually made a version already, but it parses that format
description manually and continuously. Even if I split the script into
lists, I still have to go through that. The format description is
intentionally made to look like a Tcl script with the idea that later I
could evaluate it in the appropriate context and let Tcl do the work (and
also byte compile it).
Now I'm thinking about doing that not by XOTcl mechanisms but namespaces.
Perhaps that could be the best option.
/ http://www.fishpool.com/~setok/