> * The docs are absolutely out of date. This makes guile unusable
> unless you're a guile developper yourself. You can't ask people to learn the
> code by heart in order to be able to use a package. This is a real showstopper
> for new people to get involved too.
Amen. Long ago I volunteered to review gh_* documentation,but Jim got derailed
and the project sits. I still would
like to convert my Autogen project to Guile (for political
reasons more than anything), but I also refuse to read code
to figure out how to do it. If my project were a simple
matter of interpreting a source string, I think I could wade
through it. But it is different, so the application of Guile
is non-obvious to me and, as stated above, having to read code
is a showstopper.
> * Another showstopper is the apparent lack of will to help newcomers
> solving their problems. OK, it's August. But I don't see how you can expect to
> get more people involved in the developpement if you don't help them getting
> started.
Yep. If anyone were able to tell me how I could applyGuile to my stuff, then
I would have moved forward and
blasted out the grunt work....
> * You can't either expect people to use the snapshots. People need
> stable releases. I'm not against the idea of moving the API, if it can improve
> it. But people must be informed of the incompatible changes from stable
> release to stable release.
I would settle for snapshots that were labeled "robust",tho more regular releases
would be better...
> * As far as I could see, but again, this is a newbie view, the gh API
> seems strange, uncomplete and inconsistent.
I believe, ultimately, I will need to construct a pre-parsedtree containing the
function calls and arguments that then gets
processed by the Guile engine. Many (most?) of the functions
need callback support. Not clear how to do all that.