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 vos/Bar.hh :-) 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 vos/Bar.hh :-) 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
[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
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
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 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 (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
[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] 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
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
[vos-d] s5 version control and persistence
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 (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] 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] 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
[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=-6972678839686672840hl=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...
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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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
[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 generated names, or names based on some computed information (originating user and timestamp
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
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
[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: 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: 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: 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] 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/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d
[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 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] 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] [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] 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: 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: 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
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] 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
[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] Re: [planning] When are we content-ready?
And so says Jonathan Jones on 01/01/06 08:15... - Complete import/export support to and from blender, for both worlds and avatars. So, do we have that fabled import/export subsystem yet? Is it documented? If so, where? If not, what source code can I 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] Re: vip/userinterface
And so says Reed Hedges on 17/12/05 00:28... How about: * TerAngreal could include in its own site a home 3d world! This would be your private, local world. When you start TerAngreal, it could initially connect to this world. The contents of this world would be saved in a XOD file; if that file doesn't exist, it would create a minimal default that contains some text/image objects that welcome you, tell you what the default controlls are, etc. In the future, TerAngreal will have editing controls and you could modify the world. This private world could even contain 3d representations of all of the things TerAngreal uses Vobjects to store info in (e.g. your preferences are Vobjects, they could be editable in 3d)! h... and then if afterwards you want to get to this world, could the url for it perchance be about:config? 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://www.laranja.org/ mailto:[EMAIL PROTECTED] 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] 3dui article, with review and (entirely free) rant
There was this article in The Tech Zone recently, linked from Slashdot, Where Computer Interfaces Are Going : 3D Beyond Games: http://www.thetechzone.com/?m=showid=465 It doesn't say much that people who hang around here don't know already; but it should have at least one point of information or a snack for thought for everyone. The author doesn't seem to have much of an opinion; the article basically amounts to a few instances of there is camp A and camp B, but the future will IMO be somewhere in between. Well duh. I even disagree in some points; I like webpages in angles, spreading them around me is better than tab browsing. But certainly a tool to align them with my view would be nice. In the end, he wonders why desktop UIs didn't evolve much in the last 20 years. Then I go well duh again. Of course mainstream reporters would be wary to even think this, but IMO the reason is pretty clear; we have a de-facto monopoly on UIs this days. If we were to switch our whole UI paradigm, there would be too big a risk that someone else would get it right, and the monopoly would take a severe hit. They don't want that. The status quo is comfortable. Besides, they're now struggling to get their software everywhere; and I think it will be a while before refrigerators and wristwatches have enough power for 3duis. Until then, we'll be stuck with the desktop metaphor on our powerful, 3d-capable PCs, just because. 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://www.laranja.org/ mailto:[EMAIL PROTECTED] 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: [Fwd: .]
And so says Peter Amstutz on 12/12/05 05:10... Probably spam or an email virus? I know mailman strips off attachments over 40k, so there may have been an incriminating payload which was dropped. I certainly didn't send out these empty emails. In fact, this is exactly the reason why I GPG sign all my communications :-) hear hear... I got a reject message from mailman for an exactly identical message, and it had an attachment. I obviously didn't open it to see if it was virus. Equally obviously, I never sent the message to begin with :-) This seems to be a specially smart virus designed to hit mailing lists. 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://www.laranja.org/ mailto:[EMAIL PROTECTED] 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: [aims]
And so says Jonathan Jones on 11/12/05 02:37... Just out of interest, forget sourceforge, forget the website, in your minds, what do you aim to acheive with this project? I believe Peter has stated he wants to do the web, but he can speak for himself. Me, I want the 3dui - the everyday UI you use to do stuff. This is at the same time more and less interesting, because there are already a few functional 3duis. (Or vrui or ii or whatever you prefer to call it.) I think they're not going anywhere because there is a lack of pull, a lack of basically two things - enough apps that you can actually use this in production, and a few killer apps that make people come and try. I think the killer apps is what we're working on - we have pretty much the vr equivalent of IRC, and Peter dreams of the 3d web, and a few of us are working on games which would be very flexible thanks to the vos model. 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://www.laranja.org/ mailto:[EMAIL PROTECTED] 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] neat article about simulation (game) engines
http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/ Regardless of the scripting focus, I find it interesting for the descriptions of the actors approach and the attitude of the engine is the game's OS. 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://www.exoweb.net/ mailto:[EMAIL PROTECTED] 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: Terangreal and Unicode?
And so says Reed Hedges on 05/09/05 09:44...
Has anyone else been hacking on Terangreal to build in unicode mode?
actually, I have (see the thread can't compile ter'angreal from cvs).
With help from Peter and a lot of back-bending over wx documentation,
this is what I came up with. I didn't submit a patch earlier because
it's now segfaulting to me - but vostest segfaults identically, so it's
probably not wxRelated().
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://www.exoweb.net/ mailto:[EMAIL PROTECTED]
GNU: never give up freedom http://www.gnu.org/
? +build
? Makefile.in
? aclocal.m4
? autom4te.cache
? config.guess
? config.sub
? configure
? depcomp
? install-sh
? ltmain.sh
? missing
? unicode.diff
? vos-browser-config.h.in
? apps/Makefile.in
? apps/terangreal/Makefile.in
Index: apps/terangreal/ter_mainframe.cc
===
RCS file: /home/cvsroot/vos-browser/apps/terangreal/ter_mainframe.cc,v
retrieving revision 1.8
diff -u -r1.8 ter_mainframe.cc
--- apps/terangreal/ter_mainframe.cc 13 Aug 2005 21:00:41 - 1.8
+++ apps/terangreal/ter_mainframe.cc 5 Sep 2005 02:36:23 -
@@ -115,8 +115,8 @@
mb-Append(winmenu, wxT(Windows));
wxMenu* helpmenu = new wxMenu();
-helpmenu-Append(wxID_ABOUT, About...);
-helpmenu-Append(wxID_HELP, Help...);
+helpmenu-Append(wxID_ABOUT, wxT(About...));
+helpmenu-Append(wxID_HELP, wxT(Help...));
mb-Append(helpmenu, wxT(Help));
SetMenuBar(mb);
@@ -124,7 +124,7 @@
void TerWxMainFrame::constructHelp()
{
-helpdialog = new wxDialog(0 , -1, wxTer'Angreal Keys,
+helpdialog = new wxDialog(0 , -1, wxT(wxTer'Angreal Keys),
wxDefaultPosition, wxSize(520, 220));
int w, h;
helpdialog-GetClientSize(w, h);
@@ -147,7 +147,7 @@
void TerWxMainFrame::constructAbout()
{
-aboutdialog = new wxDialog(0 , -1, About wxTer'Angreal,
+aboutdialog = new wxDialog(0 , -1, wxT(About wxTer'Angreal),
wxDefaultPosition, wxSize(500, 200));
int w, h;
aboutdialog-GetClientSize(w, h);
@@ -580,7 +580,7 @@
void TerWxMainFrame::setStatus(const std::string s)
{
-status-SetLabel(s.c_str());
+status-SetLabel(wxString(s.c_str(), *wxConvCurrent));
}
void TerWxMainFrame::warpAvatarHome(wxCommandEvent)
Index: apps/terangreal/ter_prefs.cc
===
RCS file: /home/cvsroot/vos-browser/apps/terangreal/ter_prefs.cc,v
retrieving revision 1.2
diff -u -r1.2 ter_prefs.cc
--- apps/terangreal/ter_prefs.cc 9 Mar 2005 08:13:24 - 1.2
+++ apps/terangreal/ter_prefs.cc 5 Sep 2005 02:36:23 -
@@ -83,16 +83,16 @@
{
try {
avatar.assign(ta, true);
-nickentry-SetValue(avatar-getNick().c_str());
+nickentry-SetValue(wxString(avatar-getNick().c_str(), *wxConvCurrent));
double x, y, z, r;
avatar-getObject3D()-getOrientationHT(x, y, z, r);
-rotx-SetValue(wxString::Format(%f, x));
-roty-SetValue(wxString::Format(%f, y));
-rotz-SetValue(wxString::Format(%f, z));
-rotr-SetValue(wxString::Format(%f, r));
+rotx-SetValue(wxString::Format(wxT(%f), x));
+ roty-SetValue(wxString::Format(wxT(%f), y));
+ rotz-SetValue(wxString::Format(wxT(%f), z));
+ rotr-SetValue(wxString::Format(wxT(%f), r));
} catch(std::runtime_error) {
}
}
@@ -105,57 +105,56 @@
void TerPrefs::setNick(wxCommandEvent)
{
try {
-#if wxUSE_UNICODE
-avatar-setNick(nickentry-GetValue().mb_str().data());
-#else
avatar-setNick(nickentry-GetValue().mb_str());
-#endif
} catch(std::runtime_error e) {
LOG(terprefs, 3, Exception setting nick: e.what());
-wxMessageBox(e.what(), wxT(), wxICON_EXCLAMATION, this);
+wxMessageBox(wxString(e.what(), *wxConvCurrent),
+ wxT(), wxICON_EXCLAMATION, this);
}
}
void TerPrefs::setAvatarModel(wxCommandEvent)
{
-wxString sel = wxFileSelector(Please select an avatar to load, , ,
- ,
- Quake MD2 (*.md2)|*.md2|3D Studio (*.3ds)|*.3ds,
+wxString sel = wxFileSelector(wxT(Please select an avatar to load),
+ wxT(), wxT(), wxT(),
+ wxT(Quake MD2 (*.md2)|*.md2|3D Studio (*.3ds)|*.3ds),
wxOPEN | wxFILE_MUST_EXIST);
if(!sel.empty()) {
try {
vRefA3DL::Model m = meta_castA3DL::Model(avatar-getObject3D());
-m-setModelToFile(sel.c_str());
+m-setModelToFile(sel.mb_str());
} catch(std::runtime_error e) {
LOG(terprefs, 3, Exception setting avatar model: e.what());
-wxMessageBox
[vos-d] can't compile ter'angreal from cvs
checkout as of today, probably about noon UTC. if g++ -DHAVE_CONFIG_H -I. -I../../../apps/terangreal -I../.. -I../../../libs -I../../libs -DCS_DEBUG -I/opt/crystal-cvs/include/crystalspace -I/usr/lib/wx/include/gtk2u-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_REENTRANT -D_PTHREADS -I/usr/local/include -D_REENTRANT -D_PTHREADS -I/usr/local/include -D_REENTRANT -D_PTHREADS -I/usr/local/include -D_REENTRANT -D_PTHREADS -I/usr/local/include -g -O2 -g -Wall -D_REENTRANT -D_PTHREADS -MT wxterangreal-wxmain.o -MD -MP -MF .deps/wxterangreal-wxmain.Tpo -c -o wxterangreal-wxmain.o `test -f 'wxmain.cc' || echo '../../../apps/terangreal/'`wxmain.cc; \ then mv -f .deps/wxterangreal-wxmain.Tpo .deps/wxterangreal-wxmain.Po; else rm -f .deps/wxterangreal-wxmain.Tpo; exit 1; fi In file included from ../../../apps/terangreal/ter_mainframe.hh:15, from ../../../apps/terangreal/wxmain.cc:12: ../../../apps/terangreal/ter_progmeter.hh:22: error: invalid type `const char[6]' for default argument to `const wxString' make[3]: *** [wxterangreal-wxmain.o] Error 1 This is a gentoo system. VOS is a checkout from this morning. wxGTK is from gentoo, release 2.6.1. gcc is 3.3.3 (from gentoo 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. -- http://www.exoweb.net/ mailto:[EMAIL PROTECTED] 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: new feature - speech bubbles
And so says Peter Amstutz on 12/08/05 13:50... I've added speech bubbles to ter'angreal. Check out a screenshot here: http://interreality.org/screenshots from the screenshot, it seems there is also a bubble thing identifying the user, and both look like exactly the same. That would be a bad idea IMHO. Possible solutions: - make them look different - hide the id tag when there is actual speech - only show the id tag when the user clicks on something in the UI (an identify people button?) - only show the id tag when it might be relevant... like a 3d version of tooltips - any combination of the above 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://www.exoweb.net/ mailto:[EMAIL PROTECTED] 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
