On Fri, May 12, 2006 at 06:39:05PM +0000, Tuomo Valkonen wrote:
Of course. But the paper contains some great ideas (at least with an application side POV, see below), so I'm trying to follow it as much as possible (without major hassle, that is).The paper only has a draft implementation of what a Vis-like system would really be; don't take the API too literally.
Infact, if I wrote this Vis paper now, I'd probably try do the example in Haskell with static typing :).
Actually, I'm doing the prototype in Python.
In any case, it's nice to see someone take on implementing Vis or something like, and I'll gladly help what I can.Don't expect to much of it for now. It's mostly for my own purposes in my spare time and I ain't got a lot of it. Of course as soon as it's even marginally usable, I'll do a release, so at least in theory, others could continue my effort.
Also, I certainly don't think that the Vis core should be implemented in Lua, after all, but in C, as that's the only language easily accessible from other languegesThe prototype will be fully in Python. For one part, I really don't like C at all and don't understand why it's used that much (most of the buffer overflow exploits couldn't have happened with a high level language). For the other part, doing it in C would cost me too much time better devoted to finishing the prototype and designing the version 2 implementation (that could then provide interfaces to other languages) based on the experiences with the prototype.
2. Are the parameters to Vis.Command specified in the name (separated by=20dots) string literals or variable names?I haven't actually fully specified how commands receive parameters.
I've found something in the paper that gives another hint about it:
Section 6.2:
[...]
pgctx:def('std/control.openfile().filename', vis.String)
[...]
So something like 'std/control.openfile().param1.param2' would be
invalid, instead two defines are needed:
pgctx:def('std/foo().param1', vis.String)
pgctx:def('std/foo().param2', vis.Integer)
I like that approach (at least for now <g>).
Looking at the examples, a method of some data e.g. in
cv:def('std/view.area:changed', vis.Command):setv(set_viewarea)
would receive 'std/view.area' as parameter, but a non-method would
get no parameters.
OK. This currently gives me headaches (well, to be honest, I already had them before ;) ). Structs containing (sub-)Structs are fine (and already work as specified), but Sets containing Structs containing Sets... <shudder> From the application side, it looks great (because it's simple to use). But from the library side, it's quite complicated.Suppose you have the data 'something/foo[]' of Strings. Thenrequesting this would return a set of strings, say {"a", "b", "c"}, etc. Suppose then that you have the data 'something/foo[].bar[]' of Integers. If you request all of this, you might get {{1,2,3},{1,5,9},{2,3,7}}
So it's essentially like killing that object and creating a new one, just "cheaper".I guess it's supposed to undefine (hey, it's a long time since I wrote that paper) any defs, and put the context in such a state that it can not be interacted with before :realise() is called again.
Now I'm more confused than before. How can they be in the same namespace if they can co-exist?5. What's expected to happen if there are both 'std/foo' and=20 'libbar/foo'? Raise a name collision exception?Both can exist with collision.
Or should I interpret this tag as an extension to the leaf name?I.e. how are is 'std/foo.bar.baz' a child of the previously-defined Struct 'mock/foo.bar'?
As I've currently implemented it, the tag is just an informative attribute of an entry. Trying to define 'std/foo' after 'mock/foo' will raise an exception.
This is where I'm stalling currently. I need to think some more about it and might do it quite differently as outlined in the paper.7. How is Context:realise() expected to work? When does it return? How=20does it interact with std/seq.next() and vis.mainloop()?
CU Sascha -- http://sascha.silbe.org/
pgpQcXWhg4eTx.pgp
Description: PGP signature
