This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jay Glascoe <jglascoe@jay.giss.nasa.gov> writes: > On Tue, 8 Dec 1998, Bernard URBAN wrote: > > > > > >>>>> "Jay" == Jay Glascoe <jglascoe@jay.giss.nasa.gov> writes: > > > > Jay> hi, I hope this isn't flame bait, but IMO guile-1.3 is not > > Jay> (yet!) ready for "mission critical" applications. For one > > > > What do you mean by "mission critical" ? If it is running some program > > hmm. To tell the truth, I'm not sure what I mean. But then, that's the > problem: I need to be able to explain to my boss, in down-to-earth terms, > why we should go with Guile. I could easily show off the power of Scheme, > in general, and specifically the simplicity of the Guile/C API (docs! > docs! docs! ;) But sooner or later the age old question will arise: "how > stable is it?" What do I say? I don't even understand the garbage > collection mechanism. I wonder if something like a guile hacking guide, that describes the intimate details of how parts of the system work would be useful? Even just the general concepts of how things like the gc, evaluator, symbols, smobs, etc... work internally might prove useful in both introducing new hackers to the gutz o' guile, as well as hunting down bugs (that code is definately not doing what it's supposed to do). It doesn't have to be terribly formal; all it would require is for someone to pick a file, figure out what it does and jot it down (I've found myself doing this a lot while working on the gc; of course, by the time I'd gone through the effort, I understood the operation pretty well and didn't actually finish the notes ;). I'm not sure if this is being addressed in the manual JimB is working on now, but I don't think it's necessary on that scale (most users of guile only need to know how to use the system effectively, and aren't particularly interested in how the system works, just that it does). Some of it is already done in the comments (tags.h, for example), but a little more depth (describing how major functions go about their work) would be even more helpful. The hardest bit about something like this would be keeping it in sync with the actual code, but this only really requires someone to scan the ChangeLog for additions or removals to a certain part, and update the text accordingly. -- Greg