[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Argh! Module system frustration.
From: |
Neil Jerram |
Subject: |
Re: Argh! Module system frustration. |
Date: |
28 Nov 2001 21:16:07 +0000 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Marius" == Marius Vollmer <address@hidden> writes:
Marius> Excellent! Please tell me what part I should work on.
Marius> I was thinking about showing people how to put their new
Marius> primitives into a module, how to make that module visible
Marius> in guile-user, and how to evaluate code in guile-user.
Marius> Then show some examples of how to let the user actually
Marius> influence the behavior of the application (letting the
Marius> user set variables, calling out the user supplied
Marius> functions, etc.)
Marius> Then try to point out the advantages (and disadvantages)
Marius> of packaging an application as a library.
This all sounds great. The structure that I have in mind for Part II
is something like this:
- Programming Overview
- General discussion [already begun in program.texi]
- Intro to Scheme programming
[this is the existing `Basic Ideas in Scheme' chapter]
- Guile C Programming
- defining primitives and variables
- interaction with modules and extensions address@hidden
- smobs
- awareness of memory management and GC
- interrupts and threading models
[plus anything else about the SCM interface that is better covered
here than as reference-style doc in Part III]
- internals [whatever is left over from data-rep.texi]
- Utilities
- Snarfing
- Docs generation
- Debugging etc.
- Using the debugger
- GDB tips
- trace
- profiling
- Emacs interface
- Packaging
- as modules
- as executable scripts
- as extensions/libraries address@hidden
- autoconf helper macros
- handling versioning and deprecation
And, of course, all with lots of helpful examples everywhere. I think
the docs that you propose writing would fit nicely at the places
marked with address@hidden
>> - The general area of modules and variables etc. is also high
>> on my list of doc to work on next. (In fact I was planning to
>> do this tonight, but now I'll wait a bit!) This priority is
>> motivated by the frequency of related questions on the mailing
>> list.
Marius> Yes. If you can provide a framework where reference
Marius> information needs to be filled in, that would it make easy
Marius> for others to provide that information.
Right. I'll try to do this. In the particular case of modules and
variables, I think it makes best sense to move the documentation for
variables into the chapter on modules.
Regards,
Neil
- Re: Argh! Module system frustration., (continued)
Re: Argh! Module system frustration., Han-Wen Nienhuys, 2001/11/13
Re: Argh! Module system frustration., Rob Browning, 2001/11/20
Re: Argh! Module system frustration., Marius Vollmer, 2001/11/21
Re: Argh! Module system frustration., Neil Jerram, 2001/11/21
Re: Argh! Module system frustration., Marius Vollmer, 2001/11/23
Re: Argh! Module system frustration.,
Neil Jerram <=
Re: Argh! Module system frustration., Han-Wen Nienhuys, 2001/11/29