Re: [vos-d] Steps to start building in Mandriva 2007?
On Wed, Apr 04, 2007 at 11:38:26AM -0600, S Mattison wrote: > What sort of build environments do you guys use? Any particular IDE > you prefer, or just KWrite/Kate? > I have (GCC) 4.1.1 20060724 (prerelease) (4.1.1-3mdk). > What should I get via URPMI first? Or is this all I need? Are you building from the 0.24 release or from a source repository checkout or snapshot? The build requirements should be in README or in the manual. Essentially they are G++; automake, autoconf, etc.; libtool; and the typical shell tools. > > I also hear that "Blender's cob export saves uv's but not materials", > leading to objects of pure white. Is this an issue with Interreality, > or have things changed with blender, since? Do I need a different COB > script? The COD export script includes image (bitmap) textures. It doesn't include material properties like reflectance, nor does it include any procedural textures -- that's what that statement means. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] s5 concurrency (design part 2)
Okay, in following up with Ken's question, let me talk a little bit about s5 concurrency. Warning, long, fairly detailed writeup follows. In s4, the threading model is essentially wide open. There is a thread pool fed by the "task queue", and all incoming requests, updates and notification callbacks are serviced by creating a Task object and adding it to the task queue. This meant all code can potentially be called reentrantly, and need to be protected accordingly. Since most calls are potentially blocking, asynchronous tasks are spun off into separate threads by assigning them to the task queue. This means that the burden of serializing callbacks that act on non-threadsafe code (Crystal Space, WxWidgets) falls on the application. Unsuprisingly, these scheme turns out to be fairly difficult to program for. There are locks everywhere, the Crystal Space plugin is a mess of asynchronous code fragments, there are race conditions, and there's at least one known (but not yet debugged) deadlock in the ircbridge code which is why the demo world on interreality.org is nonresponsive half the time. The essential problem is that the vobject model in s4 doesn't include computation: how the flow of control is transferred between parts of the program. While the data semantics of vobjects were pretty well defined, we didn't understand at the time the need to also define the computation semantics -- we were stuck in the object-oriented notion of "message passing" == "synchronously calling a method". As noted above, for an openended framework like VOS, that's not good enough. So, a key goal in the s5 design process is to introduce a computational model. Having thought it through and done some research, I determined that the Actor Model (http://en.wikipedia.org/wiki/Actor_model) is the closest to what we're trying to do, and so serves as a basis going forward as we turn it into a concrete design. The key features of the actor model are: - Each actor executes independently of other actors - Actors can send asynchronous messages to other actors - Actors can execute behavior based on received messages - Actors can create other actors - Actors have no shared state Now, replace "Actor" with "Vobject" and you have a pretty good description of how s4 VOS already works when talking to remote sites. The problem is, s4 VOS does't do this internally, which leads to a "leaky abstraction" when code written to work on local vobjects is made to access remote vobjects, as well all the other problems of shared-state concurrency outlined above. Thus, in s5 we will establish each vobject-actor as a logically independent thread of control, and work primarily through message passing both within the local process as well as over the network. This approach was popularized by the Erlang language (http://erlang.org/) and is often referred to as "Erlang-style concurrency." However, unlike Erlang, we're not trying to get into the programming language business, instead the strategy is to add this functionality via libraries or bindings to the "VOS kernel" into existing, popular programming languages. I should note at this point that a naive implementation of actors would create one operating system thread (or process!) for each actor, so you may get the impression that this is inefficient. This is not what we intend to do at all, and instead propose the following optimization: Observe that in the common case, at any given point in time most vobjects are idle. Thus, we don't need a thread for every single vobject. Instead, we "bind" a vobject to a thread on demand, allow it to execute, and then "unbind" it when we're done. Binding a vobject is similar to acquiring a normal mutual exclusion lock, with the key difference that it can continue to accumulate pending asynchronous message. A thread may have many vobjects bound to it. This is crucial for tasks such as working with single-threaded code like WxWidgets or Crystal Space, as it allows for a fine-grained vobject-based representation but while requests are automatically marshaled and serialzed into a single thread. To avoid excessive context switches, if a vobject is unbound, then it may be bound to the current thread and the request executed synchronously. The decision to whether to execute the request synchronously is based on whether the method handler is "fast" or "slow". A "fast" method does not block waiting for any other vobject, does not consume an inordinate amount of CPU time, and does not block on I/O from the operating system. A "slow" method is any method that doesn't fit that criteria and is typically spun out into a separate thread. Presently the determination of "fast" and "slow" has to be made by the programmer, although it may be possible to determine it automatically via some kind of code scanning or validation in future scripting langugaes. If the vobject is bound to another thread, t
[vos-d] Steps to start building in Mandriva 2007?
What sort of build environments do you guys use? Any particular IDE you prefer, or just KWrite/Kate? I have (GCC) 4.1.1 20060724 (prerelease) (4.1.1-3mdk). What should I get via URPMI first? Or is this all I need? I also hear that "Blender's cob export saves uv's but not materials", leading to objects of pure white. Is this an issue with Interreality, or have things changed with blender, since? Do I need a different COB script? ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] WxTerangreal TaskQueue question
On Wed, Apr 04, 2007 at 12:50:10AM -0700, Ken Taylor wrote: > Just a quickie: > > Most tasks in the wx version of terangreal get added to a "mainThreadTasks" > static queue, which is handled by wxgui's Pump (a wxTimer). However, the > goToWorldTask gets added to TaskQueue::defaultTQ. What's the difference > between these two mechanisms for task scheduling, and why would you use one > or the other? The mainThreadTasks are executed by the main event loop managed by wxWidgets. Anything that needs to interact with wxWidgets or Crystal Space *must* run in that main event loop because neither WX nor CS are thread safe. However, because the event loop is also used to repaint the GUI and 3D scene, you can't have any blocking operations in your handlers or the application will appear to freeze. So to execute an lengthy request (such as downloading a world) you create a task and put it in the "default task queue", which is serviced by a thread pool. So the task goes off and is run sometime in the future in some other thread. Also, all event callbacks like notifyPropertyChange() are processed through the thread pool. This design seemed like a great idea at the time, and works reasonably well on the server side when handling multiple independent requests. However on the client side, where there is a lot more task dependency and forced serialization brought on by the requirements of the libraries as well as the need to remain responsive to the user, having a lot of worker threads wizzing making reentrant calls into user code turned out to be really hard to program for. For s5 I'm working on a different approach which will be much cleaner, which I hope to have a writeup for later today. -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] bakefiles
On Wed, Apr 04, 2007 at 07:38:11AM -0400, Reed Hedges wrote: > Well, automake works fine for me in general on MinGW whenever I've used > it there, but never tried it with Visual Studio or Cygwin. Of course > there's always the incompatible-versions problem with the autotools. > And maintaining a ton of visual C files sucks, I have to do that all the > time :) Well automake essentially works, the real bastard on mingw and cygwin is libtool. Unfortunately you can't really use automake to build DLLs without libtool, at least not without a lot of hacking. My main beef with automake itself is that it doesn't have good mechanisms for applying rules across the whole project (so we end up with the "inplace" boilerplate at the bottom of every file) and recursive makefiles suck for parallel builds. It's not worth fighting with any more, and since we're going to be doing a lot of rewriting from scratch in s5, we might as well reboot the build system as well. > That's good. If we can keep those project/make files in the tree > without too much trouble then that would be an ok way to go. Let's also > keep the bakefile source in the tree and in the source release too, > especially if eventually we want vos to be buildable on all kinds of > server operating systems (and where admins want to just run "make" and > not have to install extra tools). Before settling on bakefile I still need to get an idea of the strengths and weaknesses of the Crystal Space build system (Perforce Jam), Boost.Build (Boost Jam) and Scons. Essentially bakefile is a meta-makefile more like automake but more abstract (and thus able to target a variety of underlying build tools), whereas Jam and Scons are full make replacements. I still need to determine what specific unique features Jam and Scons offer that might tip the decision in their favor. Incidentally, it's probably possible to write a bakefile backend to produce Jam and Scons files ;-) -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] bakefiles
Peter Amstutz wrote: > Whenever I try to set up a VOS build environment on Windows, I get a > sharp, throbbing headache and a strong urge to throw my chair out the > window. It's difficult to understate just how big of a maintainance > hassle the current build system is on Windows (whether Cygwin, Mingw or > Visual Studio). It's so bad that I've seriously considered creating a > tarfile of the entire mingw tree on interreality.org as the recommend > way of setting up a VOS build environment. It takes me personally > several days of fiddling to get ter'angreal to build and work on Windows > on a new system. Automake is lovely on Unix, but it is an awful > cross-platform build system where the platform is not a unix variant. > Well, automake works fine for me in general on MinGW whenever I've used it there, but never tried it with Visual Studio or Cygwin. Of course there's always the incompatible-versions problem with the autotools. And maintaining a ton of visual C files sucks, I have to do that all the time :) >> tools you list. If you do switch to bakefile, let's keep some Makefiles >> in the bzr tree. And keep bakefile inside the bzr tree so that you don't >> have to have it installed if you want to modify the makefiles. > The primary advantage of bakefile vs. jam or scons is that it generates > actual project files for various compilers, so users don't have to drop > down to the command line to build VOS when everything else they are > doing is in the IDE. That's good. If we can keep those project/make files in the tree without too much trouble then that would be an ok way to go. Let's also keep the bakefile source in the tree and in the source release too, especially if eventually we want vos to be buildable on all kinds of server operating systems (and where admins want to just run "make" and not have to install extra tools). Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] WxTerangreal TaskQueue question
Just a quickie: Most tasks in the wx version of terangreal get added to a "mainThreadTasks" static queue, which is handled by wxgui's Pump (a wxTimer). However, the goToWorldTask gets added to TaskQueue::defaultTQ. What's the difference between these two mechanisms for task scheduling, and why would you use one or the other? -Ken ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
