Dear Faré, I'm sorry (but also impressed ;) to hear that you have reached the limit of procrastination within Common Lisp.
I'm a little preoccupied until next week, but brief answers to some of your questions are inline below... > Is there a mailing list specifically about technical details of maru, > or is FoNC the thing? No and not really (at least not for any kind of sustained planning, design and development discussion). Throwing caution to the wind and misplaced trust into the toxic smog^H^H^H^H^H^H^H^H^H^H cloud, I created maru-...@googlegroups.com (with https://groups.google.com/forum/#!forum/maru-dev possibly being the place to sign up, I think, assuming some cookie or other isn't poisoning my view of that page compared to everyone else's view of it). I am tempted to write a big introductory post containing my vision for where Maru might go or how it might be reborn, given enough community support, but that will not happen before next week. > * I see the gc reserves 8 bits for flags, but uses only 3. Is that a > typo? Is that done with the intent of addressing that byte directly? No and not really (at least not explicitly). An ancient gcc generated wretched code when the boundary was not byte-aligned. Things may be different now. You're right that 16 Mbytes is a stingy limit for certain kinds of application. > On the other hand, given the opportunity for 5 extra bits, I'd gladly > grab one for a one-bit reference count (i.e. is the object linear so > far or not), and another one for a can-we-duplicate capability, > if/when implementing a linear lisp on top of it. They're yours for the taking. I was waiting to have some time to reply properly to the linear lisp thread but, since you mention it, one of the reasons for having all accesses to object fields go through get() and set() was to make it ridiculously easy to add read and write barriers. > * The source could use comments and documentation. I suffer from being able to make sense of my own code many years after writing it. Not very conducive to community process, I know. > Would you merge in patches that provide some? Of course! I might not merge them very quickly, though, since I'd be so unreasonable as to want to read them all first and elaborate if necessary. :) > * Speaking of documentation, could you produce an initial README, with > a roadmap of which files are which and depend on which, and how to run > the various tests, etc.? Maybe separating things in subdirectories > could help. Or not. Many Makefile targets are obsolete. A working > test-suite could help. You almost answered your own question. I try to keep README.examples (which is a script) working properly. It exercises a huge amount of the code, but to find out what exactly that code is you do need to obtain some kind of transitive closure over all the 'load's and 'require's that pull in lots of source files. Many Makefile targets were for temporary experiments, long abandoned, and should be removed. Others are for exercising interesting code (that still works and yet is not portable enough to be part of README.examples) and should be made more prominent. (Targets that exercise a statically-typed compiler for Maru are hiding in there somewhere, with obscure names.) Other interesting code has no Makefile or README.examples presence at all. (Minimal SDL bindings to open a window, render some text and then paint with the mouse is one example, prompted by a recent discussion on this list.) The whole thing is teetering on the edge of being rewritten in itself (as the original three-file version of Maru was written in itself). My intention was always to tidy things up considerably at that time. FWIW, there is a sketch of how Maru's generalised eval works (http://piumarta.com/freeco11/freeco11-piumarta-oecm.pdf) which is entirely accurate in intent and approach, if a little different in some implementation details. > * Is the idea that everyone should be doing/forking his own, > CipherSaber style, or is there an intent to share and build common > platform? I'd love to build a common platform. Maru is in particular trying to be malleable at the very lowest levels, so any special interest that cannot be accommodated easily within the common platform would be a strong indicator of a deficiency within the platform that should be addressed rather than disinherited. Where there is a choice between forking to add a fix or feature and clamouring to get that fix of feature adopted into some kind of central repository, I believe clamouring always benefits vastly more people in the long run. I intensely dislike the github/gitorius 'clone fest' mindset because it dilutes and destroys progress, encouraging trivial imitation rather than radical innovation -- which, if there is any at all, finds itself fighting an intractably high noise floor. Forking will always split a community (even if one side is only left with a community of one) so if you want what you are doing to be relevant one day and benefit the most people then trying to limit forks and clones is a good thing, IMO. If anyone wants to do something hugely incompatible with Maru, with no guarantee of eventual success, I'm happy to make a branch in the repository for it. While public forking might be a viable model for development that closely linked with and intends to contribute back to a mature project, where the gravitational field of the parent repository is irresistibly high, I don't think it is very helpful or efficient for getting a small and unestablished project off the ground. Regards, Ian _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
