[vos-d] traits
http://www.iam.unibe.ch/~scg/Research/Traits/ Interesting stuff, and reminds me of s5. There may be some wisdom there that we can reuse. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 properties again
Also spracht Peter Amstutz (Thu, 01 May 2008 22:31:03 -0400):
> - It's going back to the drawing board (again) (not completely, but it
> does mean some work redesigning the VOS APIs, the XOD format, changing
> the code generator, etc)
For me this kills it. How much do you estimate it would set you back?
And is what's wrong with the current design serious enough to justify
this time? A good yardstick for that is: is the new design sufficiently
better that, if you stop now to implement it, you'll still have gone as
far by end of this year as you would if you don't?
*IF* you really think it's worth it, then I'm willing to discuss the
details; but I think before we even get to that, it would be good to
discuss whether a project of this magnitude is worth considering at all.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Also spracht Lalo Martins (Thu, 03 Apr 2008 13:40:51 +): > Sorry to resurrect this, but after working with s5 for two months, I > still have the same concerns, only more so :-) Actually, never mind; I had an epiphany ;-) Here's basically how it works... My VOS browser is looking at a remote site, and finds an object of a type it doesn't know. Now, for some reason, it wants to introspect this object (maybe to build a python wrapper?). What can it do? Well, it just asks the remote host to send over a replica of the site containing that class. My local replica won't be considered "authoritative", since the host don't have the private key, but then again the remote host doesn't either -- library sites are "ghost" sites, that no host has the private key for. Now, this could easily be done by treating Library objects specially, and putting in place a system to replicate them. But why make special cases, when there's already a perfectly good system to replicate sites? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Sorry to resurrect this, but after working with s5 for two months, I still have the same concerns, only more so :-) Also spracht Lalo Martins (Tue, 12 Feb 2008 04:55:19 +): > Also spracht Peter Amstutz (Mon, 11 Feb 2008 17:43:45 -0500): >> With regard to shipping the private key, my thinking is that publishing >> an API is like specifying a protocol, and that you really want a way of >> unambigiously referring to a specific API as published by a specific >> entity at a specific version. > > Hmm... no, I don't think I for one want that. It would mean I can't > make changes to third-party library from source A and still have > third-party software from source B work against it without a manual > hack-and- recompile. That would be against the spirit of Free Software, > and the letter of the LGPLv3 (which I see you picked for s5 and I > approve of). > > Yes, it would be nice to have a way of *referring* to a specific (...) > as you say. But having all code by default *depend* on a specific > version published by a specific entity? Bad idea, IMO. > > For the matter, I don't think Libraries should be distributed as a site, > at all. I think they should just import the Library object into the > local host (possibly inside some "safe" location like /otd or /libraries > or even /lib). But it seems you have put some thought behind this > decision; would you mind sharing your reasoning with us? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Fun with the generator
Also spracht Peter Amstutz (Tue, 18 Mar 2008 11:09:24 -0400): > On Mon, Mar 17, 2008 at 07:33:24PM +0000, Lalo Martins wrote: >> Well. I spun off the web MVC stuff into a new library (hypervos). >> That opened a pandora box of generator fun :-) > > Yea, as you've probably figured out by now, writing good C++ is hard, > but automatically generating good C++ is even harder. :-D >> 2: The #define guards use only the file name. If you have headers with >> the same name in different libraries (eg MVC.hh)... you get my point I >> think. I manually changed them to eg #define _hypervos_MVC_hh_, might >> make the change in the generator later. > > Oops. Yes, the generator should be smarter than that. See my comment > below about directory organization for headers. Fixed in my branch (assuming we agree _hypervos_MVC_hh_ is good enough). >> 3: Much worse happens if you have namespaces with the same name :-) the >> generated code has things like MVC::View all over, which of course >> generate "ambiguous namespace reference" errors galore. > > This is a bit of a pathalogical case, although hopefully now you see the > reason for the site_xxx namespace. > > The brute force solution would be to have the generator go ahead and > qualify everything with the excessively long site_xxx namespace, which I > was trying to avoid purely for the sake of readability. Ah no, you're taking it a step further. I'm referring to VOS Namespace objects, not C++ namespaces in general. See, you already solved this problem ;-) since we encourage each library to ship one Library object, named the same as the library, and then a number of Namespace objects inside it. Splitting a (VOS) Library in different (C++) libraries and/or directories would, yes, be a problem, but we'll cross that bridge when there is even water on the river ;-) What I'm talking about is... - Site 0011223344556677889900aabbccddee - Library vos - Namespace MVC - Site 6879706572766f73203474656877696e - Library hypervos - Namespace MVC See? So that could be handled in C++ (and it's how I solved it by manually editing the files, but that means I can't atm run the generator on mod_vos or my other project) by qualifying it with vos::MVC:: or hypervos::MVC:: >> 4: This is unrelated to the hypervos move, I noticed it earlier. If my >> class "Foo" extends "vos::core::Bar", then Foo.hh will have #include >> "Bar.hh" >> which of course won't work so well... should be :-) > > Since I was originally focused on getting the libvos core to work, I > didn't give too much thought to how the C++ headers should be explictly > organized into directories. Again, the brute force solution would be to > have the headers mimic the namespace up to and including the site, which > would be horribly verbose but would eliminate most of the ambigious > cases. Again, you're forgetting we already have the handy Library object, which I'd like to encourage developers to keep unique-ish. So would do it (and, bonus of bonuses, already works with our current layout!), and it's what I made the generator do, in my branch. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Fun with the generator
Also spracht Lalo Martins (Mon, 17 Mar 2008 19:33:24 +): > 1: mod_vos.xod (and my other projects) extend a lot of classes from the > new library. But since the generator doesn't know about those, it > reports broken links and generally doesn't know what to do. > > The answer to this may be in my plugin loader; I might try my hand at > solving it later this week. > > 2: The #define guards use only the file name. If you have headers with > the same name in different libraries (eg MVC.hh)... you get my point I > think. I manually changed them to eg #define _hypervos_MVC_hh_, might > make the change in the generator later. > > 3: Much worse happens if you have namespaces with the same name :-) the > generated code has things like MVC::View all over, which of course > generate "ambiguous namespace reference" errors galore. > > 4: This is unrelated to the hypervos move, I noticed it earlier. If my > class "Foo" extends "vos::core::Bar", then Foo.hh will have #include > "Bar.hh" > which of course won't work so well... should be :-) > > 5: Just to put in a positive note and because I like the number 5 better > than 4, I'll say I found great joy in recent s5 work; in particular > Vobject::clone() saved me hours of toil! Fixed 2 and 4 today, may tackle 1 or 3 tomorrow. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Fun with the generator
Well. I spun off the web MVC stuff into a new library (hypervos). That opened a pandora box of generator fun :-) I'm a bit exhausted, so I'll go over them briefly; if you need more detail, ask, and I'll elaborate tomorrow. Or check out my branch and play around yourself. Also, I'm not saying these need to be fixed urgently; just that we need to know about them for the future. 1: mod_vos.xod (and my other projects) extend a lot of classes from the new library. But since the generator doesn't know about those, it reports broken links and generally doesn't know what to do. The answer to this may be in my plugin loader; I might try my hand at solving it later this week. 2: The #define guards use only the file name. If you have headers with the same name in different libraries (eg MVC.hh)... you get my point I think. I manually changed them to eg #define _hypervos_MVC_hh_, might make the change in the generator later. 3: Much worse happens if you have namespaces with the same name :-) the generated code has things like MVC::View all over, which of course generate "ambiguous namespace reference" errors galore. 4: This is unrelated to the hypervos move, I noticed it earlier. If my class "Foo" extends "vos::core::Bar", then Foo.hh will have #include "Bar.hh" which of course won't work so well... should be :-) 5: Just to put in a positive note and because I like the number 5 better than 4, I'll say I found great joy in recent s5 work; in particular Vobject::clone() saved me hours of toil! best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Website design ideas
Also spracht Reed Hedges (Tue, 19 Feb 2008 18:11:26 -0500):
> I did want the background to look very CGI, could even turn it into flat
> unsmothed polygons or put a wireframe on it.
I'll agree a starfield is the "lazy" way to get the effect that we were
both going for ;-) maybe a different scenery would look better.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Website design ideas
I like #1. When I did a mockup a long long time ago, I went with a
similar idea, and I think it's still valid; the metaphor being that
you're looking at a few "flat" widgets floating in a 3d space.
I have a nice background image I generated from Celestia :-)
Also, in my own mockup, I used partial opacity in the boxes. Maybe mine
were too transparent, but something like 90%, 95% would look good? (The
problem with a lower value being, of course, that the Celestia background
was black with white stars, which would clash with the text...)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] gc
hate to answer myself, but :-)
The recipe for "transient" objects is:
factory.create(core::SiteWrapper(), fooComponent::implementation())
It will have no site, and its vobjectId will be 0. And it won't be in
any site's vobjectTable, so when the refcount reaches 0, it's gone.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] gc
Also spracht Lalo Martins (Fri, 15 Feb 2008 06:20:22 +):
> (Now, on my original design, web pages would be "transient views",
> meaning, there is a ViewImplementation that writes to the WebRequest,
> but it never actually returns a View. This feature has been lost on
> Peter's implementation, but we plan to bring it back later on; just not
> a very high priority. For now, by not attaching the View to any site,
> the ViewImplementation can make sure it's collected in the next gc
> cycle.)
Er, except we have no gc at the moment :-D so even things like the
WebRequest object will just linger forever in the Site's vobjectTable
until the process is restarted.
I went ahead and re-added transient views, essentially by moving the
createView() logic from the ViewFactory to the ViewImplementation, where
it can be overridden. But that means I'll still be leaking WebRequest
objects. Is it as simple as adding a Site.releaseVobject(vw) method (to
delete vw from the vobjectTable, therefore allowing the refcount to
eventually reach 0)? Or am I missing some implications? I know later on
we want to have a smarter, proper gc, but for the simple case...
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] s5 hypervos (mod_vos)
Also spracht Reed Hedges (Thu, 14 Feb 2008 14:23:53 -0500): > On Thu, Feb 14, 2008 at 07:13:14PM +0000, Lalo Martins wrote: >> hypervos is already alive and kicking in the form of an Apache mod_vos; > > Ack! Why didn't you email the list! I've been adding stuff to S4 > hypervos (and intend to port them to S5!) And I have many plans for > further development (see HyperVosIdeas on the wiki) Heh, sorry. It's still a bit nebulous, as I'm working on grokking s5 and reality-checking the APIs; I thought I'd tell the list about it once it's actually possible to build a (web) site, which as I said, is by the end of this month. But if I realised you were actively working on s4 hypervos, I'd probably have made a different decision. > Tell me more about mod_vos. Before I do that, to inform your reading, I guess I should talk about my own personal long-term vision for VOS. For me, there are a few points ahead of a3dl and the Interreality in the coolness scale. I like the whole architecture. I like that it has actual sessions and connections and is stateful. At the top of the list, I love it that the whole structure is object-oriented and fully semantic; we're more than a collection of opaque files, each with a type tag, which leaves it to the client to sort things out. This is POWER that shouldn't be forgotten, and empowers us to do a lot of things the web has been struggling to do in the last few years, with impressive but ultimately very poor results. So my "angle" at VOS development is CONTENT. What I desire to have, at the latest shortly after the Interreality becomes usable (but preferably a while before then), is a small, www-like network of interesting, useful content. And I don't mean VR content; VR content of the sort that, say, Second Life has by the million, is really interesting, about as much as the Web was interesting in the beginning. And I'm not talking about "before web 2.0"; I'm talking before e-commerce, before blogs, sourceforge, forums, wikis. And this, if I may be so bold, is the reason I believe Second Life will ultimately fail. Hypervos is an essential part of my "migration strategy". Not everybody will jump on Interreality as soon as the first alpha is usable, and that seriously limits the amount of content we can have on this network. The natural answer is to write web interfaces for this content. And, why not, plain-old-GUI interfaces too; that doesn't take that much extra time. Hence the big focus on MVC in s5. Sure, in some situations you'll want to "circumvent" it and just build a3dl content. But my vision has things like an "abstract" object of type, say, "/vos/talkative/Hub", which can appear on the web as an AJAX chat page, on GUI as an IRC-like thing, and on Interreality as a fancy bar (the View class would fetch shapes, textures and whatnot from child objects, maybe by casting the Vobject to / interreality3d/a3dl/Scene). So. How it works is basically... MVC. There is a View Context class called WebRequest. (This is in libvos, in case someone wants to write another implementation of hypervos, say, stand-alone, IIS, whatever; mod_vos subclasses this into ApacheRequest.) Peter's ViewFactory object is a registry of ViewImplementation objects, each of which in turn is responsible for (a) examining a (model, context) pair and seeing if it can handle it; and (b) if it can, creating a View object for it. (Now, on my original design, web pages would be "transient views", meaning, there is a ViewImplementation that writes to the WebRequest, but it never actually returns a View. This feature has been lost on Peter's implementation, but we plan to bring it back later on; just not a very high priority. For now, by not attaching the View to any site, the ViewImplementation can make sure it's collected in the next gc cycle.) And really, it's as simple as that. The s4 behaviour of generating html/ xml can be reproduced by a ViewImplementation object. (I have intentionally not used the name "hypervos" anywhere, in case you want to write just such an object and call it "hypervos".) You can look at CoreSchema.xod or mvc.hh for the WebRequest API; it's pretty well-commented, and by all means please poke me back with questions, comments, criticisms, complaints, and suggestions. The core thing is, of course, the write(s) method. And it's also the one sticking point, or should I say, flaw. It's actually a symptom of a larger s5 problem which we're aware of but not in a hurry to fix. Namely, s5 uses UnicodeStrings everywhere; but this is a somewhat "half- hearted" Unicode support, because at the entry and exit points, there is no way to specify encodings. So, write(s) takes an UnicodeStri
Re: [vos-d] Updated "Road Map" on Wiki
Also spracht reed (Thu, 14 Feb 2008 09:35:40 -0500): > > I updated the "Road Map" page on the Wiki to reflect S5 plans. Pete, > please correct it if it's a bit off. This is just a general guideline, > we don't really know yet when the first S5 release will be, or whether > it will be a "1.0" release or a beta or testing prerelease that is less > easy to use. Cool! I think you're very much on spot on the grand total of features, but maybe I'd sort them differently :-) It's not up to me, but I'd do a more "testing" r1 (r0?) earlier, maybe as soon as spring. That would probably entail not having any networking, or access control, or chat, or persistence, or something else that would seem pretty essential; but it would allow interested people to play with the development model and tools, and even write content. On the other hand, some things that are in your r2 will be there in r1 in summer, or even "r0" in spring, because I'm working on them ;-) for one, hypervos is already alive and kicking in the form of an Apache mod_vos; I'm busy adding useful tools to that box, and I intend to have a mod_vos powered site up by the end of February, maybe mid-March if work rears its head too much. And the first scripting language will be there a week after Peter adds marshaling (which language that will be depends greatly on my mood that week, though). best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Also spracht Peter Amstutz (Mon, 11 Feb 2008 17:43:45 -0500):
> With regard to shipping the private key, my thinking is that publishing
> an API is like specifying a protocol, and that you really want a way of
> unambigiously referring to a specific API as published by a specific
> entity at a specific version.
Hmm... no, I don't think I for one want that. It would mean I can't make
changes to third-party library from source A and still have third-party
software from source B work against it without a manual hack-and-
recompile. That would be against the spirit of Free Software, and the
letter of the LGPLv3 (which I see you picked for s5 and I approve of).
Yes, it would be nice to have a way of *referring* to a specific (...) as
you say. But having all code by default *depend* on a specific version
published by a specific entity? Bad idea, IMO.
For the matter, I don't think Libraries should be distributed as a site,
at all. I think they should just import the Library object into the
local host (possibly inside some "safe" location like /otd or /libraries
or even /lib). But it seems you have put some thought behind this
decision; would you mind sharing your reasoning with us?
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Also spracht Reed Hedges (Sun, 10 Feb 2008 12:35:21 -0500): > Thanks! Does one just run voscodegen with the xod file as input to > generate the code? $ cd debug/stage/bin $ ./run.sh ./voscodegen -o ../../../src/app/helloworld ../../../src/app/ helloworld/HelloWorld.xod best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Also spracht Lalo Martins (Sun, 10 Feb 2008 08:18:05 +):
> This naming pattern unfortunately means you can't have two "things"
> (class, function, namespace) on the same directory.
... two "things" (...) with the same name in the same directory.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Also spracht Reed Hedges (Sat, 09 Feb 2008 10:35:25 -0500): > The new type IDs are still bothering me a bit too (among other things, > like the code namespaces). A huge advantage of the old user-invented > type names is that they were natural to understand and easy to remember. >We're going to have to do a lot of cutting and pasting, and when we > get one digit wrong, will be tearing our hair out over it. (Or the only > option will be to use the GUI tool.) AIUI from IRC conversations, the site IDs won't actually be visible to the application programmer later on; we'll deal only with IDs like "/vos/ core/StringProperty". (I'm not sure about the code namespaces, but I hope some simplification is intended there too ;-) ) Peter has actually told me a few days ago that side IDs being required for the type attribute in XOD is "a bug". For now, we cope; the IDs are extra work, but not really a killer. > Also, what in the HelloWorld example is autogenerated and what isn't? All C++ files except for main.cc (and in my branch, plugin.cc) are generated. Here's how I observed it works: Things are packed in Library and Namespace objects. Inside a namespace, you'll usually have classes (Class) and functions (Lambda). Each Library "hello" gets a "helloInit.cc", responsible for registration of all interfaces/components in the Library. Each Namespace "world" gets a "world.hh" with wrappers and interfaces, plus "worldComponents.hh" and "worldComponents.cc" with components. It's not yet 100% clear to me when "user" code should #include "x.hh" or "xComponents.hh"; I believe if you need to create a new instance of something, you need "xComponents.hh", otherwise "x.hh" will allow you to work with existing objects. Each "xComponents.hh" already #includes "x.hh", so you never need both. And each Class or Lambda "foo" gets its own "foo.hh" and "foo.cc", where you'd put the concrete implementation. These don't get overwritten if they exist, since they will contain handwritten code. (Which makes it a bit of work to cope with API evolution, but you can always point the generator at a new, empty directory, then copy-paste.) This naming pattern unfortunately means you can't have two "things" (class, function, namespace) on the same directory. Whether that can be a problem is illustrated by helloworld itself: if you write a "Library" to contain only one single class, the most natural naming would be for Library, Namespace and Class to have the same name. Suggestions on how to fix this are appreciated, I have no idea myself ;-) (Maybe something like "/helloworld/core/HelloWorld"?) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 build errors
Also spracht Reed Hedges (Sat, 09 Feb 2008 10:36:19 -0500):
> Can this be fixed, or is there a way to disable sitetest, or have scons
> skip it or something?
IIRC, all tests are currently broken; they were copied from the "old" s5
(s4.5 if you wish) and haven't been retooled yet.
In my branch (interreality.org/home/bzroot/s5.lalo/) I have removed them
from the default target. You can still build them with "scons tests",
but that will, of course, break right now ;-) (For that matter, when
they do work, "scons tests" should probably *run* the tests, not only
build them. I have some scons magic to do that from a different project
which I can copy.)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Yet, you didn't address my actual point ;-)
I know what site IDs are supposed to be for. My question is -- do we
really want libraries to "ship" as a separate site each? I realise the
key space is pretty large, so "polluting" it is probably no big deal, but
I see no big advantage in this case. (You would need to ship the private
key, anyway, right?)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] s5 site ids
Is there any rhyme or reason to site ids? If all libraries will ship a separate site (as XOD or something) with their OTDs, won't that pollute the site id space? And aren't them bound to clash at some point? Maybe set up a registry of library site ids somewhere in the website? Or is this (library OTD) going to be substantially different later on? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] More new S5 classes/concepts
Also spracht Peter Amstutz (Sun, 27 Jan 2008 23:38:04 -0500):
> (lots of clarifications on s5 concepts/classes)
On that note... can we have a documenting property (akin to Python's
docstrings and __doc__)? Preferably with nice syntax sugar on XOD :-)
Just having all the information you have on this post, right there on the
XOD file (and presumably the C++ generated from it) would have helped
immensely.
Also... I can't make heads or tails of interreality3d :-( could we have a
very minimal "hello world"?
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] MVC
Also spracht Reed Hedges (Mon, 10 Dec 2007 10:28:36 -0500):
> Thanks for writing up your thoughts. How important do you think it is
> to define specific interfaces for MVC?
I tried to define as little as possible and keep them simple ;-)
As Peter said, the idea is to define a "registry" interface; that has to
exist somewhere, and the actual code that uses this interface can then
vary as widely as necessary.
The main reason I'm proposing this so early on, is that it resonates with
Peter's ideas for Interreality3D; so I thought it would be best to have a
minimal framework that could be used by both that and "hypervos", which
would make things easier to understand for new developers.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] MVC
I posted a draft spec to http://interreality.org/~lalo/mvc.html -- your feedback is appreciated. I see both Interreality3D and the s5 equivalent of hypervos using this extensively. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design - OTD XML
Also spracht Reed Hedges (Fri, 07 Dec 2007 10:57:10 -0500): > Oh, ok, then my sketch is not really SOD, just a similar thing. Sorry > for apropriating the name. I didn't know that you implemented your > format (or forgot). Why wasn't it merged into the main S4 repository? Hmm... ehn... that's a good question :-P didn't even think about it. Guess s5 came around before I could "finish" it? > I couldn't access your bzr repository, can you maybe post an example SOD > file just so those of us getting nervous about editing all that XML can > relax a bit :) Ah yes, the repository was in a temporary location... I now pushed it to http://interreality.org/~lalo/bzr/sod (or for those who can, bzr+ssh:// interreality.org/home/lalo/bzr/sod). I also checked it out there, so you can actually see the source by going to the same URL; the example is at http://interreality.org/~lalo/bzr/sod/doc/examples/3dworld-blocks.sod best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design - OTD XML
Also spracht Reed Hedges (Thu, 06 Dec 2007 17:46:37 -0500):
> Or you could use any file format for Vobjects, even COD. Back in S4 I
> sketched out a possible curly-bracket format called "SOD" I think
> (don't remember it exactly anymore though, maybe there's a message about
> it in the archive?).
SOD was a plain-text format which I designed and actually implemented for
s4. I will most likely want to port it to s5 :-) (unless someone wants
to do it first)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s/MetaObject/Component
Also spracht Peter Amstutz (Thu, 29 Nov 2007 09:53:17 -0500):
> The most common use of term "component" is probably in the context of
> COM, XPCOM, KParts and so forth type of systems where it simply implies
> loosely-coupled objects, with separatation of interface and
> implementation and often dynamicly loadable and language-neutral. The
> plan is for S5 VOS vobject MetaObjects to do all those things, hence
> changing the name to "component".
Also Zope3 (formerly called "the Zope Component Architecture").
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s/MetaObject/Component
+1 best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 version control and persistence
Also spracht Reed Hedges (Tue, 16 Oct 2007 10:24:27 -0400): >> - type list >> - child list >> - payload, if any (eg properties) >> - security capabilities > > - parent list? That would be problematic. Since the PCRs are already represented on the "parent" side, having them repeated on the child would open a potential spot for corruption. Also, it kind of breaks the idea that an object only "commits" itself; if it adds a new child, then the child would have to update its parent list. Most of all, I don't think it's necessary. >> Version control: how it's stored > > Hmm, it seems the only thing that you need to "reason" about merging is > textual property data. I don't think so. I think the most common type of "merging" we'll have is on child lists. > I think we should really never have any > situation in which there's a "conflict", unless you as a user > specifically command it to merge two divergent branches, then of course > you are there to resolve conflicts. Right. In all other cases, I suppose the newer revision overrides the older one, when there is conflict. > What would the downsides be to treating payload (e.g. property data) as > atomic? We can do diffs in a "version history" UI to present it in a > nicer way. We could. >> Revisions and transactions > > Sounds pretty good, not sure I understand all the issues with local > objects doing commits. Any particular call chain would be building up a > list of commits, that would be executed by the initial vobject that got > the message before it returns from handling the message and sends any > reply? The commits are executed immediately. > Regarding transactions, is this something that could be saved for later, > after the basic revision control is implemented,or does it have to be > integrated now? No, I think we could leave them for later. Let's need them first :-) >> Horizons >> >> >> Off the top of my head, I think we'd like to be able to set a horizon >> per host, per type, and per vobject, in that order of precedence >> (vobject overrides type). What if a vobject has two different types >> that specify a horizon? Respect the first? The last? > > What is a horizon?? A preference of how many historical revisions to keep. You may set your host globally to a horizon of, say, 10, to save space; or set some less important object to a small number, because you don't care... best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] s5 version control and persistence
uch anything. Now, look at the 5 things we're storing in our version control: - global list of ids - vobject list of types - vobject list of children - vobject payload - vobject list of capabilities See a pattern? ;-) The only one who "doesn't belong" is the payload, but then, most of them will be a small discrete value (like a number), while occasionally we'll have long chunks of text, which are important to be smart about. So I think we can treat payload as bzr treat text files, and store it as a sequence of lines. This gives us "smart merge" for pretty much everything; with this kind of format, the situations where you get a conflict are MUCH rarer than with the usual one delta per revision. I'll probably start this project by writing a "libmerge" or something like that in C++, implementing a version of whatever is the latest tech in bzr, for handling arbitrary (STL) sequences. Revisions and transactions == Revisions are identified by GUIDs, rather than numbers, because numbers change during merges. Based on the actor model of s5, we came to this revision model: by default, when an object (actor) finishes a "request", a revision is committed. By "request" I mean, it can call other methods **in the same object** to help out, and these methods won't trigger commits when they return. A revision corresponds to all changes that were made in response to a message from another object (local or remote). Tying into the actor model, this revision will *only* commit the changes to that vobject; that's specially important, since at that point a different thread may be running something else, for a different vobject. Also, of course, if there were no changes, there's no point introducing a new revision. It's important to note, during a "request", the object may (and probably will, in many cases) send messages to other local objects. These will trigger commits when they return! And if those other objects call back to the "first" object, then that will cause a commit too... which may end up committing some changes that were made by the original method. We think, in normal usage, that shouldn't be a problem, so it's a reasonable default behaviour. You can, of course, escape the default. I imagine having a method at the host level, which unconditionally commits a new revision, taking a set of objects as an argument. (Well, not quite unconditionally -- rather, as long as there have actually been any changes.) The other thing you can do is a larger revision, essentially stopping auto-commit for some time. The way this happens internally is more similar to a bzr "microbranch" than an SQL transaction, but we can still call it a transaction. So one host method "branches" current execution line from the latest host revision. From that point, all new revisions from methods in "child requests" (or same call stack) will be on that "microbranch", whether explicit or automatic. It's important to note, since this is a branch, those methods won't see any concurrent changes to the objects, made by calls outside the branch. This is intentional and important. (I think.) Then, of course, there would be a method to explicitly reconcile the "microbranch", or it would happen automatically at the end of the request where it was created. What makes this branch "micro" is that, on merge point, all "internal" revisions are discarded; what gets committed to the main branch is one single revision, accumulating all changes. Peter, blow me off if that sounds too hard to do :-) it would imply the ability of having more than one "version" of the same object in memory in the same host, and knowing which one is the "right" one for a given call... Horizons Off the top of my head, I think we'd like to be able to set a horizon per host, per type, and per vobject, in that order of precedence (vobject overrides type). What if a vobject has two different types that specify a horizon? Respect the first? The last? What else = The "protocol" for replication is a whole other can of worms, I'll let Peter talk about that when he wants. One point he asked me to remember is that "cluster" replication propagates capability lists, while "mirror" replication doesn't. Probably. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] State of S4 Scripting (Lalo!)
Also spracht Reed Hedges (Mon, 02 Jul 2007 19:47:42 -0400): > Lalo Martins wrote: >> Yes. There is already a prototype s5-scripting branch somewhere to >> match Peter's prototype s5 branch, and it looks absolutely beautiful, >> although > > Is it sftp://interreality.org/home/bzroot/s5-scripting/libs/vos/python? Yes. > Do you have any documentation or notes you can add like the great docs > in s4-scripting? Why thanks, that's a great idea of something to do until s5 materializes. I haven't written the docs first as I usually do (referred to as "design by science fiction" in Zope circles), because I was learning s5 as I go, so I wasn't too sure what it was going to look like :-) but I think I know enough to at least write the gist of the docs now. It may even be possible to recycle the s4-scripting doc structure to some extent. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] State of S4 Scripting (Lalo!)
Also spracht Reed Hedges (Sun, 01 Jul 2007 11:56:15 -0400):
> OK, cool. Maybe we can tar up the Python stuff as a separate download in
> case people want to try it out? Though lack of message handling might
> be a problem for some people?
That wouldn't be too hard, I guess.
> So, you plan on moving forward with S5 scripting some time in the
> future, and not really continuoing to work on S4 scripting? (which would
> be basically a dead end.)
Yes. There is already a prototype s5-scripting branch somewhere to match
Peter's prototype s5 branch, and it looks absolutely beautiful, although
from what I understand of Peter's July plans, I guess I'll have to pretty
much rewrite it for the real s5 :-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] State of S4 Scripting (Lalo!)
Also spracht Reed Hedges (Wed, 27 Jun 2007 12:58:40 -0400): > What is the state of the S4 scripting branch > (http://interreality.org/home/bzroot/s4-scripting)? Does the Python > interface work? disclaimer: I haven't touched it in months. I'm answering half from memory, half from a quick look in the last two hours. The whole scripting extension idea suffers from one conceptual "bug", as explained to me by Peter: in-process messaging isn't guaranteed to work in s4, and scripts communicate with c++ entirely by messages. However, in my tests, it has worked flawlessly; my tests aren't very extensive, though, so it's possible I didn't cover whatever corner case it is that breaks them. The Python interface mostly works. You can build script objects from a string or file, and you can execute it. Missing is the idea of "script properties" we discussed before. Binding a script to respond to a message requires a hack. Also, it should probably be doable from Python as well, and it isn't. The JavaScript interface segfaults like there's no tomorrow, due to my poor understanding of SpiderMonkey's weird garbage collection. And the whole thing isn't hooked into the vos build system. All in all, I'm not sure it's worth fixing; it value would be, at best, a "technology preview" of the kind of script you'll get (much more safely) in s5, and at that, it won't even be api-compatible. If anyone really wants it, they can compile from the branch; then again, if you think you want it, you probably actually want s5 :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data" -- revision control
On Wed, 09 May 2007 09:07:57 +0200, Karsten Otto wrote:
> I don't quite understand what you need versioning for. The bulk of
> changes you get in a shared word is avatar movement, which may wind up
> to ~30 changes per second per avatar. Do you really want to keep a
> record of all this? My understanding was that if you want to make a
> movie, its your responsibility to do the recording (and filling your
> hard disk), not that of the world/server.
IMO, much of the "interesting" content may not actually be 3d objects,
but rather, information (text, models, images, sound, the works) which
you use the 3d objects to navigate trough and interact with.
Anyway, in my mental model, the answer to that is horizons. For a
document (akin to a wikipage), you may define an infinite horizon: all
revisions will be kept. For most 3d content, the default horizon, which
is to be defined -- a month, a week, 200 revisions? And for things like
position of avatars, zero: no revision control at all.
Alternatively, only record a revision when the object remains unchanged
for some period of time... but this is hairy to implement and I'm not
sure it would be worth it.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data"
(Cutting the great summary, keeping the VOS part)
On Mon, 07 May 2007 22:57:05 -0400, Peter Amstutz wrote:
> So, Lalo, this is probably a bit more than you expected :-) I think the
> answer to your question ("could VOS be useful for the things Van
> Jacobson talks about") is yes, if we incorporate a robust notion of time
> and version as related to state changes. If anyone thinks this is
> fanciful, this actually cuts right to the core of how remote vobjects
> work, and how we eventually handle caching -- central issues to the s5
> redesign.
The gratifying thing is that we already talked about this sort of thing
before, and I think the ideas we reached then are still perfectly valid
in this context.
I was thinking earlier this week about version-control-like updates; in
cases where you know sending a whole tree of vobjects is expensive, and
that it typically doesn't update much (or rather, most updates affect
only the same small subset of objects). Then we go in an approach
similar to bzr (or svn); we send our last-seen revision, the server
computes a "patch" and sends it back. (That's just the tip of the
iceberg; this raises questions of storage space, which are answered with
horizons, which raises other questions and so on...)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: "named data"
oh, before I get stoned to death by the FUD patrol :-D I'm not claiming we already do *exactly* what he wants. I am, rather, interested in how *related* what he wants is to the VOS model; in the sense that if it is, then it might be easy for us to add a few interesting features based on his ideas. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Van Jacobson: "named data"
Aaron Bentley posted to the bzr list about a Van Jacobson talk:
> I was watching this talk by Van Jacobson about a new networking
> paradigm, and I started going "hey, I know this stuff".
>
> http://video.google.com/videoplay?docid=-6972678839686672840&hl=en
>
> Around 37:31, he starts talking about a new dissemination mechanism in
> which you look for named data, rather than having conversations with
> servers.
I can't actually *watch* the talk, though, as stupid google video doesn't
work in China. If anyone is interested, can you please watch, and post a
summary? In particular, how much it's relevant to the way we're already
doing things ("named data" sounds a lot like "vobject" from my chair).
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS: Idea for instant publicity...
On Fri, 04 May 2007 16:47:23 -0600, S Mattison wrote: > Hm... Good questions. Doubleclicking a desktop cube or free-floating > desktop panel could zoom-and-snap it... Of course, I might like the > option to make the desktop background completely transparent so I could > see the 3d world beneath it too... But this is madness! Is it? My cube is transparent :-) (Although it's actually a prism -- I use 3 workspaces only -- and I set it to about 20% opacity just for eye candy) > Hmm... Crystalspace does all our work for us... Pure OpenGL means we'd > have to do all the work... And there's no way to integrate the two, is > there? Run CS under OGL? Damn! That would put a big damper on things if > we couldn't work past it. CS does run under OGL if you tell it to. What I don't know if it can do is integrate its scene graph into an existing OGL context. The alternative is adding another alternative rendering backend to Compiz. My 3d programming is too rusty to say which option is more feasible. > A linked opensource network protocol (err, I mean the VOS project!) > seems inevitable. And in my mind, it seems inevitable that such a > protocol will someday link to our desktop... For Freedom! I dare say, I'd hope it to *replace* our desktop, in which case something like this would be necessary for backwards compatibility (like the dos box in a windows machine). best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS: Idea for instant publicity...
We've talked about that before, back when Compiz was a new thing. We could actually do better, a plugin *alternative* to Cube, that allows you to create "workspaces" as free-floating billboards in virtual space. There are two big problems, however: 1: Compiz is "pure opengl"; might be hard to integrate that with the CrystalSpace-based Interreality. 2: Just like with Cube, the workspaces would only become usable (in terms of accepting input) when you "stick them to your screen" (zoom and position so that it corresponds exactly to the screen). Of course we could facilitate that, probably with some kind of snapping. This is because at the moment X doesn't do the kind of input redirection that would be necessary to allow them to work in any other mode. (Beryl has a really neat hack to allow input when you're zoomed *in*, but that wouldn't solve our problem here). Also, I don't know about the "instant" in the title... this is something that would take weeks to develop, months to make bug-free :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] build system reviews (long)
On Wed, 25 Apr 2007 23:07:11 -0400, Peter Amstutz wrote: > It's actually "make distcheck" that's interesting in this case. Ok, but the first step to get there is to replicate "make dist" :-) > Also > "make dist" is distinguished from simply dumping your repository to a > tar file by the fact that it includes certain generated scripts like > "configure" that don't, strictly speaking, belong in your version > control branch (since they're automatically generated from other files.) Yeah, I appreciate the complexity, but I'm still ok with doing it. By comparing with "bzr export" I didn't intend to mean it will be trivial, just that I have previous experience that should help me. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] build system reviews (long)
I realise this is probably not the biggest con of scons (I guess that would be
the slowness), but I'd be happy to write a "make dist" alike command and
contribute it to upstream scons. I wrote the similar thing for bzr, after all.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 scripting (design part 3)
As an illustration of this, I'd like to remind folks that there is a
prototype of s5 with almost-usable python scripting in my s5.scripting
branch. There are some kinks to be solved about messages that return
multiple values (I need to clarify how this works with Peter on IRC some
day), and creating vobjects is currently cumbersome (because Peter intends
to make this operation reflexible too, so when it is, that's what Python
will use), but you can already run simple tests with is and see what it's
going to look like.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Thinking about Javascript
First -- what Peter said :-)
Requiring a plugin is probably a bad idea, I wouldn't expect many people to
install it. (Although it would be cool.) More realistic is to write and
distribute our own javascript library, which implements a mockup of the VOS
API, but actually serialises over HTTP and JSON (or XML, but JSON is
faster). That's one thing that I could certainly write, and it wouldn't
take me nearly as much as the bindings are taking :-)
For added coolness, we could *also* have a plugin or something similar, and
then code the js library to detect the plugin and use it automagically. So
if you have the plugin, your connection actually goes trough VOS/VIP, but
transparently, so "user" js code doesn't need to change or know about it.
It's just faster.
One problem I have with the pure-js version is the nature of HTTP; either
the browser would need to keep a persistent connection to the server, like
some web chat rooms do -- which is error prone (hard to recover from a
disconnect) and makes the deserialisation a bit more complicated -- or it
would have to poll, which sucks for a number of other reasons.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 design overview
On Thu, 29 Mar 2007 07:29:35 -0700, Ken Taylor wrote: > Sounds reasonable... What reasons (other than asthetics/symmetry) are there > for properties to be first-class? Will a property object ever have children? Two use cases we encountered in the past for putting children in a property: - Translations. Depending on the data, the translation can be a further property inside the property, or it can be a sibling, with each language version having a property containing the language code. - And misc:metadata, of course; you can surely imagine lots of situations where you'd want to store a date, author information, etc for a property, right? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] http://interreality.org/wiki/YiMeiyou
On Thu, 29 Mar 2007 17:32:17 -0700, HEBLACK, J wrote:
> http://interreality.org/wiki/YiMeiyou
>
> The faq at the above page is missing.
All the links are missing; I let my laranja.org domain expire,
accidentally :-(
I'll be setting up new addresses for all that stuff shortly.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS apps...
On Sat, 10 Mar 2007 10:28:33 -0700, S Mattison wrote: >> That's a separate matter altogether, and one that would be cool IMO. But >> a windows program running in wine inside VOS would be a "flat" windows >> program, running in a floating billboard, not a real "VOS application". > > What WOULD constitute a "real VOS application"? Certainly no program > written for Linux OR Windows. Or PPC or BeOS for that matter. > > I'd say the first "real" VOS app would be a program written using > purely 3d primitives, with a built-in VOS scripting language, that > emulated the usefulness of any of these programs we've spoken of > already. > > THAT would be cool. IMO. But that's more or less what we're talking about, at least for some of those cases if not all. A properly 3d IM app using libgaim wouldn't be too hard, for example. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] What are some ideas for cool demos?
On Sat, 10 Mar 2007 01:45:08 -0700, S Mattison wrote: > On 3/10/07, Lalo Martins wrote: >> You forget on your list that VOS is cross-platform, and the primary >> platform is GNU/Linux. With that in mind: > > Wait What? > > Did I fail to mention repeatedly that 9/10ths of these applications > are "OpenSource"? I guess I did fail to mention that the people > programming the source of TerAngreal know how to compile Source... But > maybe I thought that was easy to discern from the fact that this group > is pretty much oriented towards programming? > > Anyways, everything listed below as 'opensource' can be recompiled FOR > GNU/Linux. In case you didn't know. > Oh, wait, you wanted BINARIES? Er, I went to the actual website of all of those I tagged "windows-only", and I'm quite sure they don't work on anything but windows. Yes, they're open-source, and I can have the source, but they are written with Windows system libraries in mind, and running them elsewhere would require extensive porting. (I already knew some of them, but I went to the website anyway, to check if they had been ported since I last looked.) [miranda vs. gaim] >> Better write our own, using libgaim. Gaim is one of the most powerful >> IM clients out there, recently, even on Windows, I'm recommending Gaim >> rather than Miranda. > > Miranda has a very small memory footprint, and is about 500 times more > customizable than GAIM, one fourth as big as GAIM even with the 6 > included protocols, as well as having an open plugin architecture, and > being very minimalistic... And you would rather go with GAIM? Did I > mention that if you go with GAIM, you'll have to force the entire GTK > toolkit to run inside your 3d renderer? Sorry, I disagree with you on all counts. Gaim might be less customisable and larger than Miranda, but I didn't say anything about using Gaim. I said, "write our own, using libgaim". And libgaim is both smaller and more customisable than Miranda, and has an open plugin architecture, and doesn't depend on GTK. So, what are you talking about? >> On non-windows, usually you have a separate command-line program (or >> library) for each different compression format. Even rar/unrar and >> 7zip in their GNU/Linux versions support only rar and 7z >> (respectively). So what I believe we'd end up doing is a front-end >> program that is able to delegate file handling to many other >> "handlers"; it's a known field, there are many such apps specially in >> the GNU/Linux world (nautilus, squeeze, etc). > > OH, WAIT, by "Windows Only" do you mean that there are only Zip files? > And you mean to tell me that nobody has ever written a GNU/Linux program > that deals with the ZIP format? Er, what the heck are you talking about? I can't follow at all. What I'm saying above is: the Windows apps -- WinRar, 7z, etc -- generally support a lot of different formats internally, whereas on GNU/Linux, you have a different command line tool for each format. That's all I said. > I think you really oughtta think of how to get WINE to run inside VOS, > before you say "We can't do windows programs"... That's a separate matter altogether, and one that would be cool IMO. But a windows program running in wine inside VOS would be a "flat" windows program, running in a floating billboard, not a real "VOS application". best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] What are some ideas for cool demos?
On Fri, 09 Mar 2007 14:55:56 -0700, S Mattison wrote: > Of all the applications on my system that it would be awesome to > include, if you were including applications that could render > themselves in 3d, I would say; You forget on your list that VOS is cross-platform, and the primary platform is GNU/Linux. With that in mind: > Comms: > Miranda IM - Opensource, Small, and includes AIM, MSN, Yahoo, ICQ, > Jabber/Gtalk, IRC, plugins support SMTP Email. > http://www.miranda-im.org/screenshots Better write our own, using libgaim. Gaim is one of the most powerful IM clients out there, recently, even on Windows, I'm recommending Gaim rather than Miranda. And now they managed to isolate all the actual functionality in a library, so you can write your own UI on top of that -- the very popular AdiumX client for the Mac is now based on libgaim. > Filesharing: > Shareaza - Opensource, supports HTTP, FTP, ed2k, Gnutella, BitTorrent > http://www.shareaza.com Windows-only, no good. > Media: > VLC or Media Player Classic - both Opensource. VLC is "teh kewlness". And it already has deeply entrenched a separation of UI and logic, so it's not too hard to tack a 3d UI on top of it. > Images: > i.Mage editor - Opensource and Small. > http://www.memecode.com/image.php Windows-only, no good. I'd go for The Gimp, but then, I'm not sure I want that just yet -- images are 2d anyway, so how much do I gain by a 3d editor? > Compression: > unxutils or 7zip - both Opensource. On non-windows, usually you have a separate command-line program (or library) for each different compression format. Even rar/unrar and 7zip in their GNU/Linux versions support only rar and 7z (respectively). So what I believe we'd end up doing is a front-end program that is able to delegate file handling to many other "handlers"; it's a known field, there are many such apps specially in the GNU/Linux world (nautilus, squeeze, etc). > Office: > OpenOffice - Opensource but NOT small. I don't have a good feeling about this one. It's way too heavy, has hard dependencies on java, and I doubt it would be easy to decouple or integrate the UI. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] blog mention of VOS
On Thu, 08 Mar 2007 23:46:30 -0500, Peter Amstutz wrote:
> If they every decide to go for VC funding, they could crush everything
> else.''
Eh, let's hope ;-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] The best part about bzr...
On Sat, 24 Feb 2007 16:50:08 -0500, Reed Hedges wrote:
> On Sat, 24 Feb 2007 13:30:52 -0800, Ken Taylor wrote:
>> I see Reed uses a
dvorak keyboard! ;)
>
> Haha, I picked Dvorak up from Pete actually.
Damn, Ken found us out! Yes, VOS is part of the International Dvorak
Conspiracy. Aoeui! Aoeui!
best,
Lalo Martins
--
It doesn't bother me that people say things like
"you'll never get anywhere with this attitude".
In a few decades, it will make a good paragraph
in my biography. You know, for a laugh.
best,
Lalo Martins
--
It doesn't bother me that people say things like
"you'll never get anywhere with this attitude".
In a few decades, it will make a good paragraph
in my biography. You know, for a laugh.
--
http://www.laranja.org/mailto:[EMAIL PROTECTED]
pgp key: http://www.laranja.org/pessoal/pgp
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] second draft requirements
On Fri, 23 Feb 2007 14:49:43 -0500, Peter Amstutz wrote:
> On Thu, Feb 22, 2007 at 11:16:24PM -0500, Rob Meyers wrote:
>> In terms of your scripts section, it would be great to have a COM binding
>> to your api. Although this is pretty winders specific, it opens up all
>> your code to .Net. I've done some work with editing worlds while you are
>
> To be honest, I hate COM and our primary development platform has always
> been Linux, so it's not particularly high on the list of priorities.
> However, interoperability is going to be a strong focus of the next
> version, so some kind of COM binding may be down the road.
Conversely, on Linux, I have long wanted to have d-bus bindings, which
would achieve more or less the same effect. That is something that
probably will be in s5 out of the box -- you add a site extension
(assuming site extensions exist in s5; or whatever is the equivalent if
they don't), and you get d-bus, similar to how you get VIP.
best,
Lalo Martins
--
It doesn't bother me that people say things like
"you'll never get anywhere with this attitude". In a few decades, it
will make a good paragraph
in my biography. You know, for a laugh.
best,
Lalo Martins
--
It doesn't bother me that people say things like
"you'll never get anywhere with this attitude".
In a few decades, it will make a good paragraph
in my biography. You know, for a laugh.
--
http://www.laranja.org/mailto:[EMAIL PROTECTED]
pgp key: http://www.laranja.org/pessoal/pgp
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] new vos concept: listen conditions
You probably already know I like this idea. For things like web interfaces it would be awesome, in fact my web framework idea had a design very similar to this. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS requirements
On Wed, 24 Jan 2007 20:03:52 -0500, Reed Hedges wrote:
> Lalo Martins wrote:
>> http://telepathy.freedesktop.org/wiki/System_Overview
>
> Yeah there are a bunch of interesting proposals for application data
> sharing over dbus. There was one for sharing a single presence status
> code between applications (online, away, busy, etc.). I think I linked
> to it from the Wiki, not sure if it's still active. Galago or Galaga or
> something?
It's folded into Telepathy now. Telepathy covers that, and contact lists,
and actual conversations (text, voice, video, whatever). I looked at it
briefly and it just screams "VOS".
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS requirements
On Wed, 24 Jan 2007 00:53:40 -0500, Peter Amstutz wrote:
>It shall be possible to interoperate with chat systems such as
>IRC and Jabber and give users on these other systems a
>presence in the virtual world.
Take a look at this, I love it. It's once again validation for my idea to
bridge VOS via d-bus ;-)
http://telepathy.freedesktop.org/wiki/System_Overview
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] datatypes
On Mon, 22 Jan 2007 10:07:43 -0500, Peter Amstutz wrote: > Quick technical design question I wanted to throw out for debate: > unsigned types. The current s5 design calls for 8, 16, 32 and 64 bit > signed and unsigned integer types, in addition to single- and > double-precision floats. It recently occurred to me that some important > languages don't have unsigned types (Java being the main one, but also > many dynamically typed languages only have a single "integer" or > "number" type). > > Does it make sense to axe unsigned types from the basic core types in > the interests of harmony between languages, or do we want as diverse a > set of basic types as possible and leave it up to the language binding > to deal with it? (Then you have to figure out what the correct behavior > is when you pass in a negative number to an unsigned type...) Python doesn't have unsigned types, but the functions that convert data between C and Python know about them. I'm not quite partial either way; I like unsigned for blobs, as you say. Although arguably blobs should be strings... best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] vobject namespace
I love it. In fact I was thinking of something similar recently, I don't remember the exact context -- but it had to do with mounting remote sites (nfs? heh) and some distant relation to the OLPC's social mesh. On Mon, 11 Dec 2006 13:03:47 -0500, Peter Amstutz wrote: > I just wanted to float another idea for a change in s4 to s5. Previously > in s4, there was no well defined "root" of the vobject tree. Or rather, > there was the site root, but listing the contents of this root would get > you every vobject on the site, which was rarely what you wanted. > > I'm thinking that it would be useful to have a well defined root, similar > to the unix file system root, and for vobjects on the site to be treated > sort of like inodes. This has a few advantages: it is simpler to "mount" > conventional filesystems onto the VOS namespace, and it is easy to > identify "named" (accessable via the root) and "unnamed" objects, and to > garbage collect the latter since we found that long-running sites had a > tendency to build up cruft in the form of discarded unlinked vobjects. > > A vobject would now be describable as either a literal identifier like > vos://interreality.org/$88FA3483 or with a path like > vos://interreality.org/worlds/blocks. The former would be used > internally, the latter would reflect the human and programmatic layout of > a VOS site. > > VOS reflective structures would be linked as branches off the root, such > as the list of vobject types, and sitewide configuration parameters (like > what plugins are loaded). So you could browse > vos://interreality.org/types/namespaces/core to get a list of all vobject > types present in the "core" namespace. Or you could browse > vos://interreality.org/etc/plugins to get a list of plugins. This would > be well defined so that these structures are available on any site. > > Child links would be like hard links in a Unix file system, except that > we'll maintain the "parent" list, so you can actually tell who's pointing > to a particular vobject. I suppose in this scheme a hypercard would be > like a symbolic link. > > The basic model of the child list as associative list would be unaffected. > Also, this is extremely easy to implement, since the code for parsing and > following paths is more or less the same either way. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Animation comment
The trick here is "divide and conquer". VOS represents these objects with a lot of granularity, so the updates that actually go trough the network end up being quite small. Also, the protocol has built-in support for updates, scheduling, and invalidation. If three updates to the same object are in the queue before the first one gets actually sent, then only the most recent one will actually get transmitted. That's a very simplistic description, if you want to know the details you'll have to study the source code :-) I guess my point is, trust us; Peter and Reed have already worked years on that part of the problem, and we're quite confident in the solution we have. In fact, the current discussion -- although that may not be apparent to those new to the model -- is largely (but not entirely) motivated by a desire for the animation representation that best makes use of what VOS and VIP already can do well. On Fri, 01 Dec 2006 03:29:47 -0700, S Mattison wrote: > But the question comes; How often do you choose to update it? What will > each user be missing, if one user gets a vector that tells them 'in this > timeframe, move this vertex through this vector', and the next user in > line gets something a little bit different, for their timeframe? And > again, how much load would it put on the server, if everyone is doing > these dynamic animations? > > Surely, while playing halflife or countless other games with 'ragdoll > physics' built in... You think "Man, a multiplayer game like this would be > great!"... But would both players see the same thing? Just how much data > transfer would it require, if one ragdoll body was being shared, between > only two computers? How about ten, between two computers? Now how about > ten, between five computers? And think of the one server computer, that > has to send all that data, to all the others. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] status and scheming
On Fri, 01 Dec 2006 02:21:48 -0800, Ken Taylor wrote:
> Double-caveat: I still haven't dug in and figured out how the current
> implementation of VOS-as-a-3d-virtual-world-server really works yet. Maybe
> I should go and do that before blabbing and speculating too much on this
> list
To those planning to do that: despite the far-reaching changes in s5,
"Creating Interreality" (the document in the "Manual" link in
interreality.org) is still a very good introduction, and apart from the
code examples, it mostly still applies to s5 too. I found it very
illuminating to read.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Time-awareness in VOS
=== Time-awareness in VOS === :author: Lalo Martins :date: 2006-12-01 :status: braindump :abstract: Thoughts and designs on time-aware VOS vObjects .. For those not familiar with the concept, “braindump” is an early stage of discussion, a writeup that doesn't even deserve to be called a “draft” yet. Many applications that either have already been tried in VOS or that we'd like to have in the future are time-sensitive. The most obvious case here is animation, which typically “travels” an object trough “keyframes” across a timeline. However, another application — and one with ample experience and research we can use — is revision control. While some might argue that revision control, as applied to source code, might be out of the scope of VOS, the kind of revision control commonly found in wikis does fit in our current scope. Peter and I were chatting about this on IRC, and he thinks it might be useful to have time awareness built in to s5, rather than a layer on top of it. (I agree, of course, or I wouldn't be spending time writing this; when I say it was his idea, I only mean to give due credit.) One last important point is that the two applications we're using to draw use cases from aren't mutually exclusive; an animation may be revision controlled. So the time functionality in s5 needs to be orthogonal, or multi-dimensional. Terminology and concepts The basic unit that is time-aware in our proposed model is the **vObject**. A vObject **state** is what we call each individual point in a timeline. Equivalent terminology is a “keyframe” or “frame” in animation, and a “revision” or “snapshot” in revision control. Every state has an “UID”, a string identifier that's unique within that vObject. (It's not guaranteed unique globally or even within the site, as we may want the ability to “snapshot” multiple objects in a single “meta-state”, and it may be convenient to have all resulting states share the same UID.) It would be useful if an individual state could have arbitrary metadata, such as a message, author id, UIDs of “merged” states, or a signature. I won't approach this point in this stage of the design, but I imagine the most convenient way to achieve that would be to be able to refer to the state itself as a vObject, or maybe optionally create a vObject that represents the state metadata. A reference (handle in s5) to a vObject actually refers to one specific state of that object in a specific timeline (see below). It's still an open question whether this will extend to parent-child relationships. There is one state for each object which is called the **“current state”**. If parent-child relationships are not time-aware, then this is the state you'll get by default when you follow one. If PCRs are time-aware, then the “current state” will be stored in the PCR between the object and its site. For the whole system to work, we need built-in time objects. Two objects are at the core of the design: the **timestamp** represents a given point in *absolute* (real-world) time, and is available for use by other applications; it would have properties and methods similar to other such objects, such as Python's datetime or ECMAScript's Date. Being *absolute* time, they need to be timezone-aware; we'll do that in a system similar to Python's datetime, by having an optional property **timezone**, which is expected to be a timezone object. The mandatory API for timezone implementations is very simple: they provide two methods, ``toUTC`` and ``fromUTC``. Each one takes a timestamp object, and returns another; I hope the semantics are obvious. Different from Python's datetime, however, a timestamp with no timezone object is *not* assumed to be timezone-unaware; rather, it's assumed to be expressed in UTC. Or, in other words, the null timezone object is the UTC timezone. Internally, the time-awareness APIs discussed in this document will use UTC exclusively, and for this reason, it's likely that s5 won't include any timezone objects off the proverbial shelf. The other core object, and one that will actually be used more frequently, is the **timespan**. It represents nothing more than a given length of time, presumably expressed in seconds. You can add and subtract timespans from timestamps, and you get another timestamp. You can also subtract one timestamp from another and get a timespan. A **timeline** is what we call a sequence of states. It corresponds to a branch in revision control terminology, or to an individual animation in a multi-animation object (such as a 3d character). Timelines have “names”, which must be unique within a vObject and dimension (see later); the semantics of timeline names will be intentionally left open to the application, as for each application, it may be more meaningful to have automatically ge
[vos-d] Re: Linux to get 3D GUI
On Sat, 19 Aug 2006 11:13:42 -0700, J.A. wrote:
> http://www.apcstart.com/site/admin/2006/05/95/the-third-dimension-linux-of-the-future-part-1
old news, I have been using it for months :-)
I have even considered a while ago (search for a message with subject
"CrystalZilla? What for?" on the archives) if there could be a
VOS(a3dl)-based composite manager, effectively put X inside your virtual
environment.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Re: Debian packages
On Mon, 24 Jul 2006 20:09:56 +0200, Benjamin Mesing wrote:
> Would you suggest to package 0.23 or a checkout the current development
> version (is it stable)? When is 0.24 scheduled to be be released (one of
> Peters messages suggested at the earliest in Oct.)?
Current development is certainly not stable yet.
Isn't 0.23 already packaged though? :-) Of course I think you're welcome
to make any corrections you deem necessary according to current debian
policies to it, then upload it to Debian.
> The debian package for bazaar said, that it is no longer maintained
> upstream, however, bzr-ng did not say such a thing. Is bzr still alive?
Yes, very alive :-) bazaar-1 (baz) is no longer maintained because focus
has switched to bazaar-ng (bzr, soon bazaar-2). Check
http://www.bazaar-vcs.org/
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we summon the will, they
soon become inevitable.
--
personal: http://www.laranja.org/ technical:
http://lalo.revisioncontrol.net/ GNU: never give up
freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Debian packages
On Mon, 24 Jul 2006 13:48:18 +0200, Benjamin Mesing wrote:
> I am currently in the process of becoming a Debian Maintainer. One of
> the tasks to complete the process is the packaging of a piece of
> software. Since I would like to see VOS and ter'angreal becoming part of
> Debian, I would like to do the packaging on that software.
>
> IIRC there were already packages out there earlier which I could use as
> a starting point. I will probably need some assistance in getting
> dependencies right.
Peter keeps a debian directory in our revision control. I updated it
myself for the latest (0.23) release. It will probably need some more
updating now, since Peter folded Ter'angreal back into the vos tree.
Other than that, it should be working. So it shouldn't be too hard :-)
Last I checked (0.23), the dependencies were right, or at least they
worked for me on an up-to-date Ubuntu dapper pre-release.
So I'd say, get your bzr checkout, tweak the stuff under debian, and once
you get it working, you can send us patches, or publish your branch so
Peter can merge your changes into the mainline.
It would be nice to have the vos packages in the official repositories,
even though I'm not using any Debian derivatives anymore.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Which version of bzr? sftp support?
On Sun, 04 Jun 2006 16:39:42 -0400, Reed Hedges wrote:
> Anyway, it seems to be doing something different... "Fetch phase 0/4".
> Doesn't seem to be doing much but someone mentioned earlier that an
> initial checkout can take a very long time?
Yes, and that's exactly the message. It says it's in "Fetch phase 0/4"
and it may remain so for a long time, until it finally starts moving.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Re: vos CVS locked, migrating to bzr
On Mon, 15 May 2006 09:53:09 -0400, Peter Amstutz wrote: > On Mon, 15 May 2006, Karsten Otto wrote: >> I am not a python user, but /usr/bin/python -V says "Python 2.3.5" > > Ok, that's what we needed to know. Lalo, is it true that bzr *requires* > Python 2.4? Also bzr uses a non-standard Python module for access over > ssh, which could be troublesome (this is only required for write access, > though, read access works fine over http). It does. And yes, there's paramiko, which in turn requires pycrypto. > I do intend to set up a job to mirror changes to a read-only CVS, as > well as have it generate nightly snapshots, so it won't be necessary to > use bzr unless you are committing changes directly into the main > interreality.org branch. Or the snapshot tarball idea. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: vos CVS locked, migrating to bzr
On Fri, 12 May 2006 10:44:55 -0400, Peter Amstutz wrote: > Well, it's written in Python, so platform support should not be too big of > a deal. Does OS X or XCode come with Python by default? OSX comes with python, with was a nice surprise for me when I learned it a few years back. But it does tend to be quite outdated. Hey our OSX users -- what is the python version you have installed there? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: VOS scripting
sorry for the triple signature... it's a beta version of pan and it seems to be slightly insane :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] VOS scripting
I started the scripting subsystem this weekend. I expect to work on it a bit this week and refine the design; then I'll write some docs on how it works, both from the "how to use it" perspective and from the "design breakdown" perspective. If you want to take a look at the branch, it's published at Launchpad, which is Canonical's development portal thingie: https://launchpad.net/people/lalo.martins/+branch/vos/scripting If you already have the main VOS branch in bzr, here's the fast way to get mine: % bzr branch vos vos-scripting # or just copy it with `cp -a` or rsync % cd vos-scripting % bzr pull http://bazaar.launchpad.net/~lalo.martins/vos/scripting mostly, I got my existing python code to run again, and turned it into a site extension. Next step is moving more APIs into the extension, so that it looks more VOS-ish; then get some basic JavaScript functionality; and then figure what parts of the code can be moved to common, language-neutral base classes. This is phase 1... until the 0.24 release, there is much more, with the goal being full JS scriptability. Although "full" is still not definet very precisely... ;-) probably it will be the checklist in the original vos-python document: - use a script to handle a message - store a script in a property and call it explicitly - scripts are able to look up objects, as children of an object or all the way up from a site, ACLs permitting - scripts are able to get property values, ACLs permitting - scripts are able to send messages to local or remote objects Plus the non-read-only complement: - scripts can modify property values, ACLs permitting - scripts can insert, move and remove child objects, ACLs permitting - scripts can create new objects, ACLs permitting Note it's still treated more or less like a remote site; me and Peter have been discussing this over IRC. There's no provision on the API to add site extensions, for example. Notably missing is subscribing; I'll probably leave this to the next one, although I'd prefer to have it if there is time. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Collaborative text editing
On Fri, 28 Apr 2006 11:08:24 -0400, Reed Hedges wrote:
>
> What if two people modify the same property at the same time? Currently one of
> them get's clobbered, or if they are inserting instead of replacing, weird
> things could happen.
Generally wikis go with a simple form of version control to handle that
(and also spam, vandalising, etc).
In a future version (there's lot of hotter stuff on our plates before
that), I'd like to revamp the basic revision control extension to handle
at least the kind of uses you have in a wiki -- but preferably more, at
least merging between different objects (possibly on different sites).
There's a lot of cool R&D I/we could reuse from bzr and the other
distributed VCSes for that. But later :-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: OTDs, metaobjects, and scripting
On Sat, 22 Apr 2006 20:13:28 -0400, Reed Hedges wrote:
> Hi Lalo, yes this was exactly the intended use of OTDs, but they were
> abandoned because there was more important things to do.
Yeah I know. What I'm saying is, if we decide to focus the next release
on scripting, then it's the perfect time for them to come back :-)
> Is there still any OTD documentation on the website? If not, I'll try to
> find some in my archive and put it on the wiki.
There isn't any that I can find, just a note somewhere that they're marked
to be redesigned.
> There was also going to
> be an OTD repository on the website with a certain directory hierarchy,
> and also a metaobject or site extension which could send you an OTD if
> you asked for it.
I remember those.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Can we do Summer of Code?
Yeah, late thought, the applications close Monday morning. But what do you think of putting a project or two on SoC? http://code.google.com/soc/mentorfaq.html I can imagine some of the more hairy and reasonably self-contained items on the todo list as SoC projects. Full skeletal animation, full physics, VRML, and scene graphs all sound viable. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: OTDs, metaobjects, and scripting
Some further thoughts on it...
1. What if OTD is not a string, but rather, a Vobject tree itself? So we
have an OTD for OTDs ("core:type description"), and it's relatively easy
for the VOS libraries to get information from an OTD in a remote server --
there's no parser involved...
If you need to stream an OTD through a non-VOS channel, or save it to a
file, or put it on your website, then you have COD, XOD, SOD, and possibly
other representations available in the future. I imagine you'd use XOD if
you want to provide the information to some application, and SOD as a kind
of bare-bones documentation of the object type for humans.
2.
On Thu, 20 Apr 2006 20:55:25 +0800, Lalo Martins wrote:
> However, on dynamic languages, client support can be deduced from an OTD,
> and built on runtime by VOS.
Hrm. With 'operator ->' and maybe sacrificing a black lamb or
two ^W^W^W^W^W^W template metaprogramming, we could do that for C++ too.
Of course, people that have experience with the black lamb sacrificing
thing already do count C++ among "dynamic languages", but I thought it
should be spelt out :-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] OTDs, metaobjects, and scripting
There are, I believe, two "levels" of supporting a given object type.
Let's call them "full" and "client" support (and then there is "no"
support)
Full support means you can have local objects of that type;
without full support, you can still have that type in the type chain of
your Vobjects, but you don't get any of the actual behaviour expected from
the type.
For remote objects, full support would be necessary if there is any
special behaviour you want from remote objects; that would be the case,
for example, of a3dl for Ter'angreal (I think), or talkative.
If, however, all the local behaviour you want will be implemented by your
application code -- for example, most types as seen by Mesh -- then you
can go with client support, or no support.
Client support allows you to access the "local" behaviour on the remote
object; or in other words, if your application code will do the displaying
work, but you want to be able to call methods on your remote objects, then
you want client support.
Comparing to the C++ API, if the Remote* class of your metaobject
definition only implements proxy methods -- or, in other words, there are
no methods that do anything more than sending a message to the object on
the other side and possibly waiting for a reply -- then you can use this
type with only client support.
Full support needs actual code, on any language; it will be either
built-in to your application, or loaded as a module.
However, on dynamic languages, client support can be deduced from an OTD,
and built on runtime by VOS. Of course, "OTD" right now is a vapour
term ;-) but this is the whole point of this message. If we specify
the OTD format well enough that it usefully describes the child
objects and the messages, then we make this deduction system possible.
Here's how I imagine it used from Python, for example::
obj = vos.vobject.find_object_from_root(siteurl + "/hello")
hello = obj.meta_cast("tutorial:hello")
print "Saying 'Good day to you sir.'"
print "received back:", hello.hello("Good day to you sir.")
The OTD says that there is a message with method "tutorial:hello", and
that it should map to a local method "hello". It might also say
something about arguments.
Conceivably, we could extend this to also encompass methods defined in
terms of child or property access; Metadata is a good example:
def print_basic_meta(path):
obj = site.find_object(path)
metadata = obj.meta_cast('misc:metadata')
if metadata is None:
print "Object at %s has no metadata" % path
else:
print "Object at %s has metadata:" % path
print "Title:", metadata.getTitle()
print "Description:\n " + \
"\n ".join(metadata.getDescription.split("\n"))
print "Author:", metadata.getAuthor()
print "Modified:", metadata.getModificationTime()
So my pitch is -- if the focus of .24 is scripting, we could spend
some time setting up this deduction system, and define the OTD format
usefully. I think it opens the door for a lot of cool stuff.
If we define a standard location where sites may make OTDs available
-- say, at "/type-descriptions/$TYPENAME" -- then clients can download
them and add client support for arbitrary times at runtime. This
could tie into downloading UI rules from somewhere else, for example.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: next priorities; persistence, revision control
On Mon, 17 Apr 2006 14:40:12 -0400, Peter Amstutz wrote: >> http://dbstep.sourceforge.net/ > If it's not being maintained, perhaps we could fork our own version and > import it into the VOS codebase. That would save some work. Yeah, I suppose that's the best course of action. > The current VOS SQL persistance uses bog-standard SELECT, INSERT and > UPDATE statements. Anything SQL, son-of-SQL, grandfather-of-SQL, > brushed-shoulders-with-SQL-on-the-subway, etc should support it. DBStep is just plain old SQL. What changes is the access API -- it provides a single, very simple and reasonable API, that works for all database back-ends. > b) There is no discrimination between properties, so data like position > properties which might be updated ten times a second will be pushed to the > database every time it is changed. It may be desirable to have some way > of throttling that to avoid too much database traffic. Good point. > c) I'm interested in ways of recording change history so that previous > states can be recovered. There is an experimental revision control > plugin which has in fact been running as the backend for the hypervos > section of interreality.org for a couple of years, but it is slow (it > uses RCS as a backend for property data, and a history log file for > vobject structure data) and the required tools to fetch manipulate the > repository were never really developed. Something to think about would > be a versioned SQL backend, which added a "version" column and only did > inserts, keeping around old rows... Yeah, I'm very interested on this... the requirement has come up frequently on the design of my current project. You also mentioned in the past storing wiki-like content, and history is essential for that. A few versions down the road, I'd like the revision control subsystem to be very complete, with most of the features you'd expect from bzr or svn (from svn the ability for one vobject to "descend" from another, so you can merge between them). Tracking vobjects -- as opposed to properties only -- adds a few extra requirements. - We'll be storing some marshaled representation of the child list; probably leave the representation up to the persistence system? Or is a standard representation necessary for merging across sites? - Objects now have an "unique" id at this point in time -- the name they have at the site root. For this system they need to *also* have an unique-over-all-time id, which we can probably generate by prepending a (creation) timestamp to the site id. - So the way I see it, one revision of a vobject's child list is a list of triplets: contextual name, persistent unique id, revision id. - A revision of one object is... what? Off the top of my head, the typeset, ACLs, child list, and if it's a property, prop type and data. Do we track all of these separately (could cause less headache for merges), or marshal everything to one large string? Or perhaps one string per metaobject (so two in this case)? Then there is the question of whether to store snapshots or some form of delta-ish representation. In the last year we have been through exactly this question with bzr and opted for weaves (or knits), so I suppose the same reasoning probably applies; but not necessarily, since I believe the data we'll be keeping will be typically more fine-grained (many small objects rather than a few large ones). Just throwing ideas around for reflection... it's probably too early to marry any decision, since I don't see us spending too much time on this at least for the next 2 releases :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Re: Re: next priorities; mySQL
On Mon, 10 Apr 2006 12:24:47 +0100, Neil Mosafi wrote:
> Surely the best approach is trying to support as many different database
> servers as possible, rather than pushing a single one onto the VOS user?
>
> To that extent, does anyone know of a flexible C++ data access library which
> can be configured to talk to many different databases?
Heh. You read my mind. I was thinking of this one:
http://dbstep.sourceforge.net/
It runs for me, but I'm afraid it might be a bit unmaintained
(last release was in 2004).
> I am talking not only MySql, Postgres etc but also commercial
> ones like Oracle and Microsoft SQL Server (or MS SQL Express,
> which is free)?
Hmm. Dunno about that. But it does ODBC, so it should be
possible to use those too.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Re: next priorities; mySQL
On Sun, 09 Apr 2006 18:55:29 -0400, Reed Hedges wrote: >> my personal goal for .24 would be refurbishing the sqlpersist machinery. I >> just don't trust mysql at all ;-) > > What do you mean, you don't trust it? > > What about PostgreSQL then? I know MySQL is now a complete proper database system, with ACID and all. But up to just a few months ago, it was just a place to dump your data that happened to (mostly) respond to SQL queries. It gained so much popularity because it was fast; but anyone who really cared about this database stuff knew that it was faster because it was incomplete. Like, well, DOS is faster than WinXP. And even now, at least last time I looked, the "completeness" (ACID compliance and whatever else) is optional... the default setup is just as bad (and fast) as it was in the bad old days. The Free Software / Open Source world can do better. Where you need ACID compliance, safety, robustness, and flexibility, go with PostgreSQL, it's a much better database. Where you need speed and don't care much about the other stuff, sqlite simply humiliates MySQL. As for the "trust"... most admins will go for the "fast" setup, or even not touch the defaults. Then something bad happens to the data, and it's our fault. Sigh. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: next priorities
On Mon, 03 Apr 2006 18:10:57 -0400, Peter Amstutz wrote: >* Ditch CVS in favor of SVN or BZR I think this is orthogonal to any other goals. > - - VOS core >* Rewrite site connection management to use public keys instead of > hostnames as discussed previously I'd like to see this one sooner rather than later. > - - Scripting >* Bring Python bindings completely up to speed so that they can be used > to write omnivos plugins, parts of ter'angreal etc This gets my vote for the .24 goal; but of course we enter the discussion of whether the swig bindings are even capable of doing what we're talking about. I still think you can't wrap an existing Vobject as a python object, then call python code from C++ passing this wrapped object. I just couldn't find a way to do it. Whether it's possible or not, I'd be more than happy to merge my scripting code on vos. If swig turns out to be usable, then we just ditch the wrapping parts and keep the rest. > - - 3D rendering >* Add native animation to A3DL >* Add skeletal models to A3DL >* Add terrain to A3DL >* Add prims (via FractalSpline) to A3DL >* Add trees (via OpenTreeLib) to A3DL >* Add humans (via MakeHuman) to A3DL >* Support for more import 3D formats to A3DL, such as VRML/X3D, 3DS, > Quake maps, Collada, OpenFlight, FBX... One or more of these would get my second-choice vote. But I suppose it's more interesting to have powerful scripting first, and then from .25 on focus on these, because having scripting will make them much more useful, and help with testing. > - - User interface >* Add a concept of a "user agent" to A3DL which is an object > which specifically reperesents the 3D browser application and what is > being displayed to the user >* "Clickable" type, would indicate a 3D object (or other interface item) > was clickable and would send a message back saying it was clicked These also sound lovely, but would largely benefit from powerful scripting already being in place. >* Start using AWS2, the next-generation Crystal Space which defines >and > renders UI components with fragments of javascript, would allow the > client to download a UI from a server to reconfigure itself on the fly I'm not extremely excited about this. >* Rewrite ter'angreal in python (since CS+VOS+Wx all have Python > bindings) Are you trying to throw me a bone here? :-D But if a complete rewrite is even considered, then I'd ditch CS too; it doesn't seem it will ever be stable enough. --- my personal goal for .24 would be refurbishing the sqlpersist machinery. I just don't trust mysql at all ;-) But if .24 focus on scripting, I suppose I'll have my hands full, so I'll leave sqlpersist to .25 or something. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Re: VOS 0.23.0-pre3 released
On Mon, 03 Apr 2006 11:51:08 -0400, Peter Amstutz wrote: > I vaguely recall you sent me the patch, but I can't remember what I did > with it. Probably it is sitting in my inbox somewhere. it's on bugzilla. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: VOS 0.23.0-pre3 released
Did you get my Debian patch? It would be nice to have .debs of this prerelease. On Mon, 03 Apr 2006 00:56:49 -0400, Peter Amstutz wrote: > A new prerelease version for testing, 0.23.0-pre3 has been released. > This is a release candidate, and assuming no major errors are found, we > expect to have the 0.23.0-stable release sometime this week! forgot-to-configure-my-signature-on-Pan-ly yours, Lalo ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Acquire more users and developers (Re: Second Life ?)
And so says Sergey Izvoztchikov on 31/03/06 23:12... > I was talking more about difference in users base, actually. > Any ideas why SL users base is growing much faster than > VOS's ? My goal is more about finding out what VOS is missing > at the moment compare to SL, to be able to acquire more users > and developers. I'm not trying to play down importance and cool > features of VOS or challenge you guys. Just trying to help with > directions and find out what's missing in VOS now. Well, now you're talking :-) What follows is IMO, and you may feel free to weight it less than you would weight something from Peter or Reed. And of course it's not really a comparison to SL, because I've never seen it, and I don't see any reason to take a look (non-Free Software is not software, and a single-purpose virtual world is not something that rings me as interesting). So this is my take: - First of all, VOS has no marketing dept. We place no ads. - There are a few missing features that are important for us, but overall, it's quite usable right now as a multi-user, virtual reality chat environment. This is mostly documented on http://interreality.org/cgi-bin/moinwiki/moin.cgi/VosRoadMap and on Bugzilla. The main things I believe we need, technically: * building is troublesome. Peter fixed this for VOS proper, but Ter'angreal (vos-browser) still sucks; I believe he's still working on it. Much of the blame lies with CrystalSpace, and to a lesser extent, wxWidgets. Either building must be *much* easier, or we must have binaries for every imaginable platform. Or both. (As a measure, myself, an enthusiastic VOS developer, currently don't have a working Ter'angreal.) * We need portals/hypercards/whatever to navigate between worlds. This is the big differential that makes VOS a "3d web". (From the Roadmap, it seems there is a simple form of links working now?) * I believe we need a better persistence framework, so that people can feel comfortable putting interesting, dynamic (mutable) content up online. I'll be tackling this one first thing after the .23 release. * there isn't anything that resembles bots. A basic barkeeper, a basic "npc" that roams around and does nothing useful (or maybe listens to chat and responds to keyphrases) would be cool. * sound, absolutely, how could I forget that. We need sound. * We need a way to display GUI elements and specially text, to enable people to build more interesting content. which brings us to... - mostly, we need content, lots of content. This falls into two categories IMO: * nicer chatrooms (as in, nicer than a flat square floating in the middle of nowhere with three coloured blocks on it), interlinked, so that you'd actually feel compelled to chat from there; worlds that make the best use of the features we already have. (Rendering of places from real life, history, or fiction would be specially cool.) * interesting dynamic worlds; if the previous item is "cool but static websites", this one is the web applications that make the web really useful. Here, the content author will most likely stumble on missing features (like there being no convenient way to display text right now), but that is actually a good thing, because it would drive development with real-life use cases. Of course, in this stage, it would be better if such content authors were also developers. One possible, if "cheap", approach for interactive content, in the initial stage, is to just bridge it from the web. Wikipedia strikes me as easy. Another approach -- one I'm actually working on -- is go the other way around; keep interesting data in a VOS database, and be able to view it as a website. The current interreality.org does that. You could write your blog as a 3d world, and have hypervos or a "dumper" turn it into html. Nice-to-haves: - I'd be really happy about an XMPP (and maybe msn/icq) bridge; then I could dump gaim for ter'angreal, which would probably mean running it most of the time. - I wrote some design for an email bridge, and got sidetracked into other things (because it seemed to me email would be of limited use without those). I'll probably be going back to it once I have a sufficiently good GUI viewer (and better persistence). - Personally, if we had the manpower (which we don't), I'd be very happy if we had a second browser, based on something other than CS (I'd go with Ogre). Maybe I just grew weary of CS constantly breaking and never getting anywhere nearer 1.0 :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/
[vos-d] VOS bzr mirror
Ok, the "semi-official" bzr mirror of the CVS mainline is up. It's set
to update from anonymous CVS every hour (23 * * * *). You can get it
from: http://lalo.revisioncontrol.net/bzr/vos/
With a recent bzr (0.8 pre), if you use 'bzr checkout' with the url
above (rather than 'get' or 'branch'), it will create a checkout, which
is a bound branch quite similar to what you have with cvs. So for those
afraid of distributed RC semantics, you can try it too ;-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: site peering
And so says Peter Amstutz on 28/03/06 13:57... > I think you lost me here. Searching for site ids / key fingerprints > works because it cannot be forged. Creating a namespace of arbitrary > strings, however, seems a lot more complicated? Yeah. But remember I said something about signing data, like secure DNS. Here's one possible way how it could work: if you dump all properties of a record that are not signatures to XOD, using a standardised whitespace convention, you get a string representation which you can check against the signatures. If at least one signature passes for at least one of the public keys in the record, then it's accepted. When a "server" receives an update, it's a bit more strict; it enforces tree rules: - any signatures that don't "pass" are dropped (not stored) - at least one signature must "pass" the set of keys in the record - at least one signature must "pass" the set of keys in the *previous* contents of the record (before the update) this easily allows you to expire a key, if you want to start using a stronger one. > Unfortunately such ideas quickly run into the harsh reality that as soon > as such a system gained any traction it would likely be spammed to hell > and back, rendering it useless. If you want to get complicated you can > then have trust networks which help filter the on data quality, or you > need a policing system like wikipedia to constantly fight against spam, > but in any event experience has shown it is an extrodanarily difficult > problem. A separate system of "VOS.licio.us" tags could be done using the same infra-structure. The pointer aliases, however, are more strict and authoritative. For any given "node" in the hierarchy (eg "community", "community/freesoftware") there is one entity in control, and a procedure for creating new entries; so it would be like DNS once was, or Usenet still is -- a new entry requires human intervention. I think this works well enough; while Usenet is pretty much institutionalised spam, there is very little spam in newsgroup *names*. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: site peering
And so says Lalo Martins on 27/03/06 13:16...
> A record could be just a PCR to a remote object. Or even better, a
> Vobject containing the remote PCR, but also some metadata.
Er. Remote PCRs are probably not the most useful representation,
specially seeing as we may already be using remote PCRs in the tree
itself to distribute it VOS-style. Rather, an unbound number of
properties containing IP addresses? You could even have properties
named "pointer:ipv4" and "pointer:ipv6". (When VIP supports ipv6.)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: site peering
And so says Peter Amstutz on 27/03/06 12:46...
> The solution is to completely re-think how a remote site is identified,
> and I will discuss this in my next email.
Cryptographic key pairs? (Which would then also open up the field to
encrypted payloads when we deem them necessary?)
So A can refer to B by whatever address; before C even tries to resolve
the address, it will first check in its sitecache if there is any site
with that same public key.
And/or, if C "knows" it's in a privileged network (gigabit, behind
firewall, etc), and the cache misses, it can try service discovery next,
and only if that also fails, revert to DNS.
===
Funny, that kind of ties into one other thing I have been thinking. It
is quite possible to have a VOS-based "directory" service, comparable to
DNS. You could configure on your client machine the address of your
preferred pointer site, just like you configure your DNS server.
A record could be just a PCR to a remote object. Or even better, a
Vobject containing the remote PCR, but also some metadata. If a site
goes down, it can signal the pointer that it's inactive, and the record
can be flagged as such. If it comes back under a different address, it
can update the pointer.
Like DNS, the pointers can network and distribute information. The
authority to update data could then be purely cryptographic -- when a
site sends an update, it also sends a signature. But pointers may also
have rules like "records with addresses matching 10.0.0.0/8 should only
be shared with pointers whose address also matches this mask".
The pointer site works based on two objects on the site root:
"pointer:alias" and "pointer:key". The latter is a flat listing, where
contextual names are the crypto keys of sites -- and this is what would
be used to resolve most remote PCRs, for example.
The "alias" object is the root of a hierarchic "human-readable" alias
tree, more akin to DNS; interreality could be at
"/pointer:alias/community/freesoftware/vr/interreality", but also at
"/pointer:alias/community/freesoftware/objects/vos".
Then we could refine VIP URLs:
vip://foo.bar/fnord is a DNS-based URL at host "foo.bar". The same
notation is used for raw IP: vip://10.0.0.23/fnord
vip:{dsa}5103581E58E743BC4D30624A73E36EB01A4F3D49/fnord is a key-based
URL, pointing to the server with that key.
vip:/community/freesoftware/objects/vos/hubworld//fnord is an
alias-based URL pointing to the object "fnord" at our "hubworld" server.
vip:/community/freesoftware/objects/vos/hubworld/fnord is equivalent;
since the "hubworld" object in the alias tree doesn't have a child named
"fnord", it's assumed to be an object. But if we later happen to evict
this object into a separate server, the URL remains valid. (In fact,
I'm tempted to claim that the "//" separated URL above doesn't really
need to exist.)
Then in the documentation we encourage people to just type
"/community/..." on the address bar (for the power users who will bother
to use it), and that will be interpreted as an alias URL...
Heh, to the basket with semantic web, this is semantic DNS ;-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] [philosophical] VOS as AI
Just a random thought... can probably be reused in some piece of
documentation.
The VOS object model neatly matches the way some people believe our
memory works.
A Vobject maps to a "concept". Each concept is a discrete, very
abstract atom, meaningless in itself. Each concept can have an
unlimited number (theoretically unlimited; there are probably upper
bounds that we haven't reached) of connections to other concepts, each
connection labeled and directional. Although a connection is
directional, you can navigate it both ways. The concept acquires
meaning trough its network of connections to other concepts.
A Property maps to a "memory", which is a piece of "concrete" sensorial
data - a word, an image, a taste, hunger, pain, etc. It can connect to
concepts just like a concept, so in terms of OOP, it "is" also a concept.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] compiling today's CVS: mysqlpersist.cc
Does apps/omnivos/plugins/mysqlpersist.cc compile for everyone? I'm
getting some major silliness...
First, it's still using the old paths for property.hh and vosapp.hh.
After I fixed that, I get:
mysqlpersist.cc: In function 'void vosplugin_init(VOS::Vobject*)':
mysqlpersist.cc:46: error: request for member 'getSite' in 'daemon',
which is of non-class type 'int ()(int, int)throw ()'
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: [OFF] typing
And so says Peter Amstutz on 14/03/06 14:23... > That said, there's probably a crossing-over point, where projects > below some size are better served with a dynamic type system, and > projects above that size are better server with a static type system. > The point could also be made that certain dynamically typed languages > are more powerful (they can acomplish more per line of code) which > raises the bar. That is IMO a common misconception from people that don't have a lot of experience with dynamic typing. In my experience, static typing is suitable for *medium* projects, if at all; the larger the project, the more you want dynamic typing, because it's easier to improve, debug, and read (large projects have higher rotativity of developers, so being able to quickly understand the codebase is a major bonus). As I said before in this thread, I can't think of a project that would be done better with static typing, except for low-level tasks that you'd probably rather do in C or assembler. > So while you can do dynamic type checking in a mostly static > language, typically you can't do static type checking in a dynamic > langauge. In the end this seems less powerful to me. Not really... you can *emulate* dynamic typing on a more static language like C++, but you only get dynamic typing between subclasses of a given root point (RefCounted in the case of VOS, IIRC). In fact, vRef is one of the best implementations of dynamic typing for static languages I remember seeing. But even that much would be just impossible in C. You'd have to mess around with defining your own type system. It's impossible to meaningfully find the type of the thing that was passed in one of your arguments, for example. On the other hand, it's equally easy to emulate stronger checking on dynamic languages. It's just bad practice ;-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: [OFF] typing
And so says Hugh Perkins on 13/03/06 19:14...
> Lalo,
>
> What are your thoughts on Duck Typing? http://boo.codehaus.org/Duck+Typing
that's how I work most of the time :-) in the company where I used to
work, we had an expression going around, "Beijing Duck Typing"...
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: [OFF] typing
And so says Hugh Perkins on 13/03/06 18:59...
> I guess the thing that I find tricky in Python is that it is possible to
> accidentally add unintended properties to a class by misspelling the
> intended one, and sometimes it's tricky to catch this.
It is certainly possible, but it doesn't happen as often as you'd think.
Also - self.foo = bar assigns to the instance, not the class.
> For example (my
> Python syntax might be a little rusty..):
>
> class MyClass():
>def __constructor__(self, name):
> self.name <http://self.name> = name
>
>def PrintName(self):
> print "My name is " + self.myname
>
> myobject = new MyClass("Tom")
> myobject.PrintName()
>
> gives:
> C:\> python test.py
>
> My name is
No, it gives an AttributeError exception. You only "create" new
attributes with an assignment.
And you can constrain even that using slots. If you're interested,
contact me in private :-) otherwise, just record the fact that it's
possible. (A class with slots makes all attribute assignments fail
unless the attribute name is in the slots list.)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] [OFF] typing
Basic, javascript and a few others have weak typing. Python, Lisp, Perl, Ruby, Smalltalk and a few others have dynamic typing. Which is very different. (Although Perl's case is, like everything else when Perl is in the sentence, arguable.) I can't fathom a case of high-level code where strong typing is better than dynamic... for low-level yes, but then you would probably be using C or assembler anyway. In fact, I think this was one of the (many) mistakes of C# "design". But that's a prejudiced opinion; I just looked at tutorials and example code, and turned away in disgust. Maybe it's better if you actually use it a bit. (I know Python's indentation takes some getting used to... and smalltalk's/objC's keyword args. One funny thing is that it's not hard to beat C++ into dynamic typing. Your typical VOS application is at least partially dynamic typed. Although in my dream world, the dream language uses neither kind... it uses "interface typing" exclusively. But I don't know a language that works like that in the real world :-) And so says Hugh Perkins on 13/03/06 11:03... > Yes, you're right, for many applications weak typing is better, because > it produces more compact, easier to read code. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Python scripting
And so says Peter Amstutz on 17/02/06 13:06... > On Sat, 11 Feb 2006, Reed Hedges wrote: >>> >>> Lalo, ideally your API would be almost the same as the existing bindings >>> (except extended to be more "Pythonic" where appropriate), do you think? > > Not to re-ignite any arguments, but wouldn't that defeat the purpose of > doing bindings by hand, if they end up looking more or less like the > SWIG bindings we already have? Yeah, what he said. I see the "extension" API to be more high-level. One way of looking at it, is thinking that it "pretends" to be on a different site, without actually going over the extra memory requirements this would imply. So -- it only has access to the kind of operation that a remote site would be able to do... no loading extensions or shutting down the site, for example. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Swig
And so says Hugh Perkins on 12/03/06 14:27...
> Just to throw some salt in the wounds of the Python discussions, I cant
> help thinking that C# has all the advantages of both Python (run from
> source, easy to read) and C++ (strong typing, runs quickly).
agreeing to that would require me to agree that strong typing is an
advantage :-) I think it's a serious weakness.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] CrystalZilla? What for?
I was thinking... wouldn't it be possible to write something based on Xgl (maybe even a plugin for Xgl proper) that renders stuff to CS surfaces? Or - same result, different approach - a plugin for Ter'angreal and/or CS, so that your application becomes the window+composite manager... if Compiz can do a cube, then we certainly can render on surfaces. yet-to-invest-the-time-to-get-Xgl-to-work-ly yours, Lalo Martins (but would-definitely-bother-to-do-it-if-what-I'm-talking-about- was-possible-ly yours too) -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Python scripting
And so says Reed Hedges on 12/02/06 04:12...
> One thing, I wonder what the need for the ProxyListener is? If you
> want to use a message handler instead of a listener, you just have to
> handle the "update" messages. On the other hand, having API
> specifically for implementing listeners is extremely convenient, and I
> recommend including that in your Python API.
There is no need for the ProxyListener, and it's going to get dropped
from the design. When I wrote the design doc, I didn't remember the
internal workings of VOS very well - if you annotate the file you will
see many other mistakes which are already corrected. In this case, when
I discovered that updates are simply another kind of message, I was like
"hah, cool" :-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Python scripting
And so says Peter Amstutz on 09/02/06 05:31... > On Wed, 8 Feb 2006, Lalo Martins wrote: > >>> The SWIG bindigns are a wrapper for the whole API. AFAICS, there is no >>> way to take an existing Vobject from C++, turn it into a Python object, >>> and send it as an argument to a Python function. SWIG simply doesn't do >>> this. I may be wrong, but I couldn't find a way. Rather, the python > > > Um? Unless I misunderstand what you want, this is exactly the purpose > of SWIG's C++ support. See the discussion of proxy classes: > http://www.swig.org/Doc1.3/Python.html#Python_nn28 Then I think you misunderstood; a proxy class wraps an existing class, I'm talking about wrapping an existing instance. After reading the whole text of the chapter above, I: - still don't see how to do that - believe even more strongly that swig is not meant for what I'm doing - believe even more strongly that complete, 1:1 wrapping as done by swig is a very poor way to bridge between languages :-) > Have you looked at the python programs using the existing SWIG bindngs, > in vos/swig/tutorials? I have; since they are in Python, they are unrelated to what I'm doing here. === Another way to try to explain what I mean is by using the terminology of "world" as used by the guile manual. It talks about an application in the scheme world, which calls functions defined in C, as opposed to an application in the C world, which calls back into Scheme code (typically scripts). Swig helps with the former; it *may* help with the latter, but I can't find how from the documentation. Even if I could, I'd rather maintain this separate set of (higher-level) bindings, than give these scripts the full power of the VOS api; it's less trouble in the long term. I don't want these scripts to be able to easily create a site, set ACLs, load/unload site extensions, for example. All they're supposed to do is traverse the object hierarchy and communicate trough messages. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Python scripting
And so says Peter Amstutz on 08/02/06 09:11... > On Tue, 7 Feb 2006, Lalo Martins wrote: > >>> Yes... the main point of this thing is running python code, so I'd be >>> using libpython anyway. So I figured, the work of binding by hand would >>> probably be less than figuring out how to integrate the swig bindings. >>> >>> Or in other words - why would I use the existing swig stuff? :-) > > > I think that you will find that in the long run that SWIG is much more > maintainable that keeping up a set of bindings by hand. First, since it > generates them directly from the C++ API, you can avoid the situation > where any change, no matter how small, causes the Python API to break. > > Second, complete coverage of the VOS APIs (including metaobjects) means > wrapping dozens of classes and hundreds of method calls. Do you really > want to do that by hand? ... > Anyways, the point is that you should take a closer look at SWIG if you > haven't already. A little bit of time spent learning how to use it will > mean a huge time savings in the grunt work of actually setting up the > code to interface each and every API call. That's my point... those bindings serve a different purpose than the swig bindings, and they're not *supposed* to wrap each and every API call. It's a much simpler, high-level interface. The SWIG bindigns are a wrapper for the whole API. AFAICS, there is no way to take an existing Vobject from C++, turn it into a Python object, and send it as an argument to a Python function. SWIG simply doesn't do this. I may be wrong, but I couldn't find a way. Rather, the python code would create a new site, connect... and presumably receive URLs for its arguments. This is just silly. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Python scripting
And so says Peter Amstutz on 06/02/06 14:22...
> On Fri, 3 Feb 2006, Lalo Martins wrote:
> Okay, by publishing some VOS code via bzr you've finally convinced me to
> try it out :-)
>
> Conclusion: yes, this is an improvement over cvs/svn. I will probably
> see about into converting the repository over to bzr after the 0.23
> release.
You can leave that to me, if you give me a copy of the CVS repository.
I think I got the hang of tailor now.
> Okay, looking this over briefly, correct me if I am wrong but it appears
> that you are binding VOS into Python by hand, rather than using the
> existing work with SWIG. Is there a particular reason for this?
Yes... the main point of this thing is running python code, so I'd be
using libpython anyway. So I figured, the work of binding by hand would
probably be less than figuring out how to integrate the swig bindings.
Or in other words - why would I use the existing swig stuff? :-)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Python scripting
And so says Peter Amstutz on 06/02/06 14:22...
> With regards to adding a new method on VobjectBase to add
> MessageDispatch objects directly -- yes, that might be a reasonable
> solution to the problem you pose. Another solution, one that wouldn't
> involve changing the API, would be for your code to register each
> message call back to call the same method, and then have that method do
> a second-stage table lookup on the message method to dispatch into the
> python code. Since you're crossing the language barrier anyway, such an
> extra step seems reasonable.
The beauty of the solution I proposed, is that I wouldn't need to
subclass MetaObject, at all :-) so an application can have python
message handlers without having to mess with its inheritance tree.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Simple Object Description
And so says Peter Amstutz on 06/02/06 14:39...
>
> In defense of XOD, the decision to go with XML was...
I don't think XOD needs a defense :-) XML has the merit of having
libraries for all languages and environments, so if I want to write an
exporter from something else to vos, I'd use XOD myself.
(Hmm. Now there's a thought. Maybe I should convert those map files to
XOD rather than reading them directly into vos...)
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Re: Simple Object Description
Some people can live with XML... I know I can. But it's not very
intuitive. Check in my source tree the side-by-side versions of the
same data in XOD and SOD and tell me what you think.
And so says Neil Mosafi on 03/02/06 17:33...
> A major advantage is that if I open a XOD file in any decent text editor
> (vim, notepad2, visual studio etc) then I get full syntax highlighting
> all over.. open it in IE and you can see this too! Agreeably, there are
> probably syntax highlighting for other formats (vim has so many!), but I
> doubt as many editors will support them.
By the way, Emacs can usefully highlight SOD in conf-javaprop-mode :-)
I don't know what javaprop is, but it's seemingly similar enough. Vim
probably has a mode for that too...
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Simple Object Description
In my crusade against uses of XML for things intended to be edited by humans (and also to teach myself Spirit), I wrote a Spirit parser for a simple, plain-text store format. It's partially complete; it's only a loader now, not a saver, and some features (specially ACL) are missing, mostly because XOD is still undocumented. So if someone can point me to what those features are and how XOD does them, I can happily add them (preferrably send me a XOD example). This format is intended for config files and things meant for humans to edit. You can `bzr get` the code from http://lalo.revisioncontrol.net/bzr/sod/ (And yes, I know the acronym is weird. Sue me.) ;-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Python scripting
I have a semi-functional extension for "server-side" python scripting.
You can `bzr get` it from http://lalo.revisioncontrol.net/bzr/vos-python/
By semi-functional I mean:
- You can run python code that interacts with vobjects and messages,
from C++
- You can't yet store such python code on a Property
- You can read such code from a file or string
- You can't yet set up such code to handle a message for you (unless you
hack vos)
The last point merits discussion. Pasting from IRC:
(08:13:27) lalo: I have an API question/request
(08:14:38) lalo: how come we have a public, subclassable MessageDispatch
abstract class, and the message handlers are stored in a list of
pointers to this abstract class...
(08:15:27) lalo: *but*, the list itself is private, and there are no
public methods that allow you to use any other kind of message dispatch
(08:16:45) lalo: this smells like something to be refactored... either
expose the feature somehow (I played locally with adding a
addMessageHandler method that accepts a MessageDispatch*) or get rid of
the abstract class
(08:18:29) lalo: concrete case: I'm playing with python scripting, and I
want message handlers that don't consist on calling a method on the
metaobject. It can be implemented as calling a method on a wrapper
object if it ends up being necessary, but I'd rather have a different
MessageDispatch subclass.
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
personal: http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
