On 2006-05-15, Sascha Silbe <[EMAIL PROTECTED]> wrote:
>> Also, I certainly don't think that the Vis core should be implemented=20
>> in Lua, after all, but in C, as that's the only language easily=20
>> accessible from other langueges
> The prototype will be fully in Python.
Unfortunately, prototypes often tend to stay prototypes and not get
a proper implementation.
> For the other part, doing it in C would cost me too much time=20
> better devoted to finishing the prototype and designing the version 2=20
I'm not so sure about that. I was only talking about the Vis core, that
should be quite minimal. The UI backends could in principle be written
in any language interfacing to that C core as long as it doesn't want
to take over the whole environment (by stealing timers and signals and
stuff).
Hey, I'm not saying that C is a nice language to write high-level stuff
in, but it's the only language easily accessible from other languages,
and a simple non-OO C core will not be too restrictive to paradigms used
in other languages.
>>> 2. Are the parameters to Vis.Command specified in the name (separated=20
>>> by=3D20
>>> dots) 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)
> [...]
Oh, there it is. Of course.
> So something like 'std/control.openfile().param1.param2' would be=20
> invalid, instead two defines are needed:
>
> pgctx:def('std/foo().param1', vis.String)
> pgctx:def('std/foo().param2', vis.Integer)
Well, param1 could be a structure containing param2.
>> 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.
> When you talk about methods, do you mean attributes (as defined in the=20
> paper) that are commands (vis.Command)?
Checking the document :) ... Ah, well, "attribute" is perhaps a
misnomer since "methods" can be defined as well with the colon syntax.
>> Suppose then that you have the data 'something/foo[].bar[]' of=20
>> Integers. If you request all of this, you might get=20
>> {{1,2,3},{1,5,9},{2,3,7}}
> OK. This currently gives me headaches (well, to be honest, I already had=20
> them before ;) ). Structs containing (sub-)Structs are fine (and already=20
> work as specified), but Sets containing Structs containing Sets...=20
><shudder>
Hmm.. a more correct description of the result of this example
would be
{ (bar => {1,2,3}), (bar => {1,5,9}), (bar => {2,3,7}) }
in some fancy notation, where (a => b, c => d) denotes structure
constructor.
> From the application side, it looks great (because it's simple to=20
> use). But from the library side, it's quite complicated.
Not necessarily, in a lazy language :)
>> 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.
> So it's essentially like killing that object and creating a new one,=20
> just "cheaper".
Well, not exactly. The context may be a window or some such, and already
managed somewhere by the window manager, or within another window/context
by Vis, and so on, and creating a new one will destroy these associations.
>>> 5. What's expected to happen if there are both 'std/foo' and=3D20
>>> 'libbar/foo'? Raise a name collision exception?
>> Both can exist with collision.
> Now I'm more confused than before. How can they be in the same namespace=20
> if they can co-exist?
> 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=20
> Struct 'mock/foo.bar'?
>
> As I've currently implemented it, the tag is just an informative=20
> attribute of an entry. Trying to define 'std/foo' after 'mock/foo' will=20
> raise an exception.
'std' and 'mock' are two different namespaces; think of modules in
many languages, including Python. Both can have the same symbols.
In some contexts, you could think of these as 'std.foo' and 'mock.foo'.
However, the slash is used to indicate that in some cases some
substructures of different namespaces may be fused, but even then
'std/foo' and 'mock/foo' are different. These are when an UI is
automagically built. For example, in the example of Section 6.2,
we have
cv:defconst('std/info.filename', vis.String):setv(fnam)
cv:defconst('viewer/info.dimensions', vis.String):setv(image dimensions)
cv:defconst('viewer/info.depth', vis.Integer):setv(image depth)
'std/info.filename' is something defined in the standard namespace,
and when automagically constructing an UI without a stylesheet specifying
otherwise, the 'info' part of the path to the filename indicates, that
it should be shown where some information is generally shown (unless
the UI backend has specific rules about about 'std/info.filename').
Similarly, 'viewer/info.dimensions' is something defined in our
example program's namespace, and an UI backend that hasn't been
specifically instructed how to display this data (by stylesheets),
will again take from the 'info' part that the data should be displayed
along with other such 'info' -- including the filename. We could
have 'viewer/info.filename', and this would not be the same as
'std/info.filename'; but obviously there's no point to that in
this case at least, as the standard namespace already defines
a suitable field.
Hmm.. that explanation is a bit too messy perhaps, but hopefully it
helps.
>>> 7. How is Context:realise() expected to work? When does it return?=20
>>> How=3D20
>>> does it interact with std/seq.next() and vis.mainloop()?
> This is where I'm stalling currently. I need to think some more about it=20
> and might do it quite differently as outlined in the paper.
Continuation functions rock. They're just too difficult to use in
applications written in C and other languages without high-level
functions and function closures.
--
Tuomo
