On Wed, 2006-07-05 at 17:32 -0400, Stephane Le Dorze wrote: > I agree, you need someone to promote Felix. > > I don't know exactly what's the current state of Felix (I am lacking > visibility) but looking at LUA, you don't need to have the best solution > to start spreading it around!
Lua is ok i guess. > I would really enjoy helping, the best I can do now is to try using it > and test if it can work for our needs, it's a risk for me as it is still > young. To start, you'd be risking some time. I guess you'd write some micky mouse applications, a couple of non-critical tools. > BTW, do you know any existing problems (scalability, correctness, > limitations, etc...) that could prevent me to succeed using it now? Oh sure, lots of them! If it were perfect, I'd be promoting it rather than programming it :) Some of the issue are hard to fix *because* of the requirement for C/C++ integration. For example the garbage collector cannot trace the machine stack, so collections can only occur in procedural code: procedures use a spaghetti heap for stack frames, but functional code uses the machine stack, at least for return addresses. Also since the code is not purely functional, and, there is no write barrier, the collector is naive mark-sweep "world stop". Technically only the threads sharing a collector need to be stopped for a collection -- multiple threads could exist with distinct collectors. OTOH, unlike other FPL's, Felix uses ctor/dtor and manual allocation deallocation as well. For example string is C++ string class, and the internal store therefore isn't garbage collected: a frame with a string variable will have its destructor executed by the collector, and the string storage is released by the component destructor. That is, Felix doesn't drive the gc as hard as an FPL. This is just an example of one issue. There is actually an arena (sequential) allocator with a compactor which moves objects, but it proved slower than malloc. BTW: we have a company Async P/L to provide commercial support. > We're aiming at PC, Xenon, PS3, Wii for sure and possibly PSP, DS, GBA. > We mainly develop on Windows XP with Visual 2003/2005. I gather most of these are console devices. I also understand these have heaps of processing power and RAM, but hardly any disk. At the moment Felix needs C++ support, and it can generate more bloated code than hand written C. So I'd be expecting bigger executables. > One cool feature could be to ship a solution that enable player to > customize the game using Felix. That could be done BUT you should recall that to build a Felix plugin at the moment means to build a native code DLL using a C++ compiler. It could be embedding a decent bytecode VM would be a better option. Lua is a bit primitive. Neko is probably a better alternative (however Neko currently requires Boehm collector). > I'm interested in RF's arcade game, where could I find it? RF is on holiday in Italy .. he's just back from a week in the wild fighting Napoleon's ghost, so he'll be playing catchup with the mailing list for a while. > Thanks for your reply! > I know that it's very time consuming. Marketing always is lol :) -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
