Am 11.04.2007 um 20:45 schrieb Peter Amstutz:
[...]
On a related note, I started thinking a lot about user
threads/microthreading/continuations etc in part from reading a couple
of developer blog entries on how Linden Labs acomplished it in their
server. They have an interesting challenge
Peter Amstutz wrote:
On Fri, Apr 06, 2007 at 05:16:16PM -0400, Reed Hedges wrote:
There's also something called Flow-Based Programming that is similar. In
some ways it's closer to VOS since Actors are, I think, more like method
handlers (in VOS terminology).
I don't agree. Flow-based
So messages between local objects will be serialized and passed like
remote messages, rather than being method calls? Is that overhead a
concern?
If so, maybe an optimization would be to have a message format that just
packs native machine format arguments into the message in the same order
On Thu, Apr 12, 2007 at 10:41:40AM +0200, Karsten Otto wrote:
I thought that the coroutine stuff applied trusted code only -
after all, when you cross the border to untrusted code, you have to
pass control over to whatever virtual machine executes it, and hope
for the best. In the most
On Thu, Apr 12, 2007 at 08:13:19AM -0400, Reed Hedges wrote:
OK. (You could use VOS easily to do flow based programming, I think
there's a brief note about this in the wiki somewhere.)
Yes, of course. I think the actor model is much more general-purpose,
at least in so far as it seems much
This is mostly directed at Reed, but I thought everyone might be
interested --
In working on a virtual demo world/presentation (which I intend to use
as a more compelling alterative to openoffice impress slides in
presenting VOS to potential investors) I've made a few changes that make
Peter Amstutz wrote:
On Thu, Apr 12, 2007 at 08:16:59AM -0400, Reed Hedges wrote:
So messages between local objects will be serialized and passed like
remote messages, rather than being method calls? Is that overhead a
concern?
It is a concern, although I'm don't think I would call it
On Thu, Apr 12, 2007 at 08:56:12PM -0400, Reed Hedges wrote:
Will messages be like they are now, essentially a map? Or could we have
a Message subclass generated from the OTD, with pointers into the
message data for each field, so we don't have to look up fields by name
each time?
We
Nice! I'll have to try a build tonight and see if this works for me.
(update: just finished the build... I get complaints about a usleep
function in demoplugin.c. Ah well -- silly windows!)
I haven't had much time this week to look at VOS stuff It sounds like
you have been pretty busy
I tried a quick fix, replacing usleep(2) with _sleep(20) [usleep is
microseconds and _sleep is miliseconds, right?] ... But then I get a linking
problem:
g++ -shared -nostdlib /mingw/lib/dllcrt2.o
c:/mingw/bin/../lib/gcc/mingw32/3.4.2/crtbegin.o
.libs/demoplugin.o
Nevermind, I got it to build. Just needed to add -lvosext_http
and -lmetaobject_services to the demoplugin part of the .am file.
I can't seem to get omnivos to load gallery.xod, though. I get a Error:
tried to dereference null smart pointer in - operator
-Ken
11 matches
Mail list logo
