RE: Activity

"Jonathan Bachrach" <[email protected]> Tue, 2 Aug 2005 18:54:42 -0400
Newsgroups gmane.comp.lang.goo.general
Message-ID <[email protected]>
I have to say that you caught me at a good time.  I've been experimenting
with both multimedia apps written in C and experimental languages for new
paradigms of computation.  I intentionally departed from goo to free myself
to concentrate on the tasks at hand and to not be unduly biased.  I am now
ready to integrate the results of my research back into goo.

I have included specific comments below:

> -----Original Message-----
> From: [email protected] [mailto:googoogaga-
> [email protected]] On Behalf Of Scott Graham
> Sent: Tuesday, August 02, 2005 2:47 PM
> To: [email protected]
> Subject: Re: [Googoogaga] Activity
> 
> Warning: a bit long-winded...
> 
> > > I'd like to be able to use goo on an embedded system. Ideally, I'd
> > > ...
> > What sort of embedded platform are you thinking of?  In particular, how
> much
> > memory would your target system have?  I am also thinking of embedded
> > systems.  Currently goo doesn't have memory/code space as its primary
> > implementation goal.  I was thinking about doing an extremely small
> > footprint VM implementation combined with a JIT.
> 
> My "real job" is a console game programmer. 99% of console games are
> written entirely in C/C++, and having made games that way for the last
> 6-7 years, I strongly believe the time for that is over. I'd love to
> bring goo up on an Xbox or PSP. These are probably larger embedded
> systems than you were thinking of. The "embeddedness" of game consoles
> is: limited memory, though a reasonable amount (~16-64meg, and larger
> now), no virtual memory, soft real time constraints (especially for
> GC), multiple hardware threads, and the general unavailability of TTY
> and some general posix-y things (environment variables, etc.). There's
> also the question of targetting a variety of different processors: at
> least PPC, x86, MIPS. Anyhow, I'm not hoping you'll magically sort
> through all those problems, but I think goo would be the perfect thing
> to build on/around for a language that's very suitable for game
> programming.

I'm very excited about getting goo apps to run on xbox/psp etc!  What does
someone need to be able to develop code for such a system?  How would I get
started?

> The JIT sounds like a neat/fun idea, though possibly quite a lot of
> work, depending on what hardware it was to run on. The small footprint
> VM (sans JIT) could certainly be very useful in a variety of
> situations though. Personally, I'd like to see just two (possibly
> simpler) levels: the straight interpreted/VM version, and the
> compiled-through-C version. As long as both the interpreter and the
> compiled version have the same semantics, and the interpreter
> "overrides" and interacts with the compiled code cleanly, this seems
> like the best of both worlds. 

This is the way it works right now.  You can create a very small system
without the full c compiler in the runtime with only the interpreter
instead.

> Generally, the workflow could be compile
> everything through C, then iterate using the interpreter
> (re-re-defining methods, etc.), and when you take a break, or need to
> restart the application, recompile all to C and start over. I'm
> assuming that the C compiler can do crazy hardware-specific
> optimizations that goo can then get relatively for free. (Is that
> actually true? I'm not sure how amenable to optimization the goo->c
> code is for the C compiler).

Yes this is true.

> > > A related request, that's possibly the first step in that direction:
> > > clearly defining all the interfaces to the system, and assuming less
> > > availability of various posix, etc. functions. Being able
> > > enable/disable: bignums, tty, stdio. This would also help with at
> > > least minimal ports to other (possibly smaller/simpler) OSs.
> >
> > This could be done and is desirable.  Not sure what the plan would be.
> Goo
> > can definitely be run without bignums and the rest.  It's really about
> > designing and teasing out the modules.
> 
> I can certainly look into this. I don't know too much about the
> internals of goo at this point, but it doesn't seem too big and scary
> :-), so I'm sure I could make a first attempt at factoring out the
> things that I'm concerned about (at least as a test). Is the released
> 0.155 what I should work against?

I really want to resurrect goo and fold in some changes that never got
released.  

> > > And finally, I'd like to see a less restrictive license (at least LGPL
> > > ...
> >
> > I'm open to all of that.  It's really just about getting MIT lawyers to
> do
> > something.
> 
> Ah, OK. I didn't realize that had to involve lawyers. The license
> commonly known as the "MIT License" would be perfect, though obviously
> I have no idea if your institution has deprecated or otherwise doesn't
> like that license. Perhaps it's more permissive than you want too.

Any software work that I do on MIT's time must be released by permission of
MIT.  I got "them" to agree to release goo under GPL.  I chose GPL.  I could
have chosen another license.  I would just need to get them to change the
licensing.  

> Anyway, thanks for your comments. I hope you can find time to continue
> to work on goo.
> 
> scott
> 
> _______________________________________________
> Googoogaga mailing list
> [email protected]
> https://lists.csail.mit.edu/mailman/listinfo/googoogaga


_______________________________________________
Googoogaga mailing list
[email protected]
https://lists.csail.mit.edu/mailman/listinfo/googoogaga