Re: [vos-d] s5 site ids

2008-04-03 Thread Lalo Martins
Also spracht Lalo Martins (Thu, 03 Apr 2008 13:40:51 +):
 Sorry to resurrect this, but after working with s5 for two months, I
 still have the same concerns, only more so :-)

Actually, never mind; I had an epiphany ;-)

Here's basically how it works...

My VOS browser is looking at a remote site, and finds an object of a type 
it doesn't know.  Now, for some reason, it wants to introspect this 
object (maybe to build a python wrapper?).  What can it do?

Well, it just asks the remote host to send over a replica of the site 
containing that class.  My local replica won't be considered 
authoritative, since the host don't have the private key, but then 
again the remote host doesn't either -- library sites are ghost sites, 
that no host has the private key for.

Now, this could easily be done by treating Library objects specially, and 
putting in place a system to replicate them.  But why make special cases, 
when there's already a perfectly good system to replicate sites?

best,
   Lalo Martins
-- 
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
   -
  http://lalomartins.info/
GNU: never give up freedom  http://www.gnu.org/


___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Fun with the generator

2008-03-18 Thread Lalo Martins
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

2008-03-17 Thread Lalo Martins
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

2008-02-19 Thread Lalo Martins
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

2008-02-17 Thread Lalo Martins
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

2008-02-15 Thread Lalo Martins
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

2008-02-15 Thread Lalo Martins
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

2008-02-14 Thread Lalo Martins
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

2008-02-11 Thread Lalo Martins
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

2008-02-10 Thread Lalo Martins
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

2008-02-10 Thread Lalo Martins
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

2008-02-08 Thread Lalo Martins
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

2008-02-08 Thread Lalo Martins
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

2007-12-12 Thread Lalo Martins
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

2007-12-09 Thread Lalo Martins
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

2007-12-07 Thread Lalo Martins
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

2007-12-06 Thread Lalo Martins
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

2007-11-29 Thread Lalo Martins
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

2007-10-15 Thread Lalo Martins
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!)

2007-07-02 Thread Lalo Martins
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!)

2007-07-01 Thread Lalo Martins
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!)

2007-07-01 Thread Lalo Martins
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

2007-05-08 Thread Lalo Martins
(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

2007-05-06 Thread Lalo Martins
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...

2007-05-04 Thread Lalo Martins
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...

2007-05-04 Thread Lalo Martins
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)

2007-04-26 Thread Lalo Martins
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)

2007-04-22 Thread Lalo Martins
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

2007-03-30 Thread Lalo Martins
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

2007-03-30 Thread Lalo Martins
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?

2007-03-10 Thread Lalo Martins
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...

2007-03-10 Thread Lalo Martins
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

2007-03-09 Thread Lalo Martins
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

2007-02-25 Thread Lalo Martins
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...

2007-02-25 Thread Lalo Martins
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

2007-01-31 Thread Lalo Martins
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

2007-01-24 Thread Lalo Martins
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

2007-01-24 Thread Lalo Martins
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

2007-01-22 Thread Lalo Martins
On Mon, 22 Jan 2007 10:07:43 -0500, Peter Amstutz wrote:
 Quick technical design question I wanted to throw out for debate: 
 unsigned types.  The current s5 design calls for 8, 16, 32 and 64 bit 
 signed and unsigned integer types, in addition to single- and 
 double-precision floats.  It recently occurred to me that some important 
 languages don't have unsigned types (Java being the main one, but also 
 many dynamically typed languages only have a single integer or 
 number type).
 
 Does it make sense to axe unsigned types from the basic core types in 
 the interests of harmony between languages, or do we want as diverse a 
 set of basic types as possible and leave it up to the language binding 
 to deal with it?  (Then you have to figure out what the correct behavior 
 is when you pass in a negative number to an unsigned type...)

Python doesn't have unsigned types, but the functions that convert data
between C and Python know about them.  I'm not quite partial either way; I
like unsigned for blobs, as you say.  Although arguably blobs should be
strings...

best,
   Lalo Martins
--
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
--
personal:  http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/



___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] vobject namespace

2006-12-11 Thread Lalo Martins
I love it.  In fact I was thinking of something similar recently, I don't
remember the exact context -- but it had to do with mounting remote sites
(nfs? heh) and some distant relation to the OLPC's social mesh.

On Mon, 11 Dec 2006 13:03:47 -0500, Peter Amstutz wrote:
 I just wanted to float another idea for a change in s4 to s5. Previously
 in s4, there was no well defined root of the vobject tree. Or rather,
 there was the site root, but listing the contents of this root would get
 you every vobject on the site, which was rarely what you wanted.
 
 I'm thinking that it would be useful to have a well defined root, similar
 to the unix file system root, and for vobjects on the site to be treated
 sort of like inodes.  This has a few advantages: it is simpler to mount
 conventional filesystems onto the VOS namespace, and it is easy to
 identify named (accessable via the root) and unnamed objects, and to
 garbage collect the latter since we found that long-running sites had a
 tendency to build up cruft in the form of discarded unlinked vobjects.
 
 A vobject would now be describable as either a literal identifier like
 vos://interreality.org/$88FA3483 or with a path like
 vos://interreality.org/worlds/blocks.  The former would be used
 internally, the latter would reflect the human and programmatic layout of
 a VOS site.
 
 VOS reflective structures would be linked as branches off the root, such
 as the list of vobject types, and sitewide configuration parameters (like
 what plugins are loaded).  So you could browse
 vos://interreality.org/types/namespaces/core to get a list of all vobject
 types present in the core namespace.  Or you could browse
 vos://interreality.org/etc/plugins to get a list of plugins.  This would
 be well defined so that these structures are available on any site.
 
 Child links would be like hard links in a Unix file system, except that
 we'll maintain the parent list, so you can actually tell who's pointing
 to a particular vobject.  I suppose in this scheme a hypercard would be
 like a symbolic link.
 
 The basic model of the child list as associative list would be unaffected.
  Also, this is extremely easy to implement, since the code for parsing and
 following paths is more or less the same either way.


best,
   Lalo Martins
--
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
--
personal:  http://www.laranja.org/
technical:http://lalo.revisioncontrol.net/
GNU: never give up freedom http://www.gnu.org/



___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] Time-awareness in VOS

2006-12-01 Thread Lalo Martins
===
 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

2006-12-01 Thread Lalo Martins
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

2006-12-01 Thread Lalo Martins
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

2006-08-19 Thread Lalo Martins
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?

2006-06-06 Thread Lalo Martins
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

2006-04-21 Thread Lalo Martins
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

2006-04-20 Thread Lalo Martins
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

2006-04-17 Thread Lalo Martins
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

2006-04-11 Thread Lalo Martins
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

2006-04-03 Thread Lalo Martins
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 ?)

2006-03-31 Thread Lalo Martins
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

2006-03-29 Thread Lalo Martins
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

2006-03-26 Thread Lalo Martins
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

2006-03-23 Thread Lalo Martins
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

2006-03-13 Thread Lalo Martins
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

2006-03-12 Thread Lalo Martins
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?

2006-03-09 Thread Lalo Martins
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

2006-02-11 Thread Lalo Martins
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

2006-02-08 Thread Lalo Martins
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

2006-02-06 Thread Lalo Martins
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

2006-02-06 Thread Lalo Martins
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

2006-02-03 Thread Lalo Martins
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

2006-02-02 Thread Lalo Martins
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

2006-02-02 Thread Lalo Martins
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?

2005-12-31 Thread Lalo Martins
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

2005-12-17 Thread Lalo Martins
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

2005-12-17 Thread Lalo Martins
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: .]

2005-12-11 Thread Lalo Martins
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]

2005-12-10 Thread Lalo Martins
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

2005-09-22 Thread Lalo Martins
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?

2005-09-04 Thread Lalo Martins
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

2005-08-28 Thread Lalo Martins
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

2005-08-12 Thread Lalo Martins
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