Re: Plan for 2.0

["David Séverin" <david@altosw.be>]

Hi Guilers,

It might be a small thing [and of course not a priority at all], but I'd love to see
a small evolution of the manual index structure in order to separate scheme
procedures from others, scheme variables from others...:

    * Concept Index				
    * Scheme Prodedure Index	* C Procedure Index
    * Scheme Variable Index	    	* C Variable Index
    * Scheme Type Index			* C Type Index
    * R5RS Index 

Being a scheme 'only' programmer, I'd love not to have to scroll through
gh_* and scm_* ... when I am looking for something in an index.

David

;; --

Le Sat, 3 Jan 2009 18:38:13 +0000,
"Neil Jerram" <neiljerram@googlemail.com> a écrit :

> We're clearly moving towards a 2.0 release.  Here is my attempt to
> pull that together a bit and flesh out what needs to be done.
> 
> What will go into 2.0:
> 
> 1. The git "master" branch.  In principle, everything here, but we
> need to review and check for
> 
>   - anything that should be excluded
> 
>   - any applicable fixes that were made in 1.8.x and didn't get copied
> to master.
> 
> I've started doing this review and will hopefully complete soon.  If
> there is anything that shouldn't be in 2.0, I'll move it into a new
> branch.  If there are missing fixes from 1.8.x, I'll cherry pick them
> into master.
> 
> 2. The "vm" branch.  Once the review of "master" is done, we'll merge
> "vm" into "master".
> 
> 3. The "ossau-gds-dev" branch.  This contains some minor improvements
> to the Emacs interface.  After the review of "master" is done, we'll
> merge "ossau-gds-dev" into "master".
> 
> 4. Any other changes (including bug fixes) that we think are important
> to get done before 2.0.  I propose to review the bugs in Savannah, and
> also recent email discussions, to identify these.
> 
> Is there anything else?  In particular, am I right in thinking that
> the BDW-GC work is not ready yet?
> 
> One specific query...  Although I advocated removing GH before, I
> don't feel 100% confident that that's the right thing for 2.0.  I'm
> wondering now if we should instead move the GH code into a separate
> library, "libgh", but continue to provide this as part of the Guile
> distribution.  Moving the code out of libguile will still achieve the
> important objectives of (1) reducing the size of the libguile code
> that developers need to look at and work with, and (2) ensuring that
> GH is implementable on top of the advertised SCM API; but keeping
> libgh in the distribution will be a significant help for users who are
> still using GH (who will just need to add -lgh to their link line).
> 
> I still think we should remove all GH-related documentation, as we
> don't want to do anything to encourage further GH usage.  The GH code
> itself is sufficient IMO for showing how someone can migrate their
> code from GH to SCM.
> 
> That's all for now.  Any concerns or comments?
> 
> Regards,
>        Neil
> 
>