From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gsl-discuss-return-5382-listarch-gsl-discuss=sources.redhat.com@sourceware.org>
Received: (qmail 1795 invoked by alias); 7 Dec 2008 12:29:42 -0000
Received: (qmail 1786 invoked by uid 22791); 7 Dec 2008 12:29:41 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 07 Dec 2008 12:29:06 +0000
Date: Thu, 11 Dec 2008 17:03:00 -0000
Message-ID: <m38wqsjhis.wl%bjg@network-theory.co.uk>
From: Brian Gough <bjg@network-theory.co.uk>
To: Patrick Alken <patrick.alken@colorado.edu>
Cc: gsl-discuss@sourceware.org
Subject: Re: [Help-gsl] Submitted patch to add bspline derivative	capabilities
In-Reply-To: <20081205191058.GA11218@hippogriff.homeunix.org>
References: <4a00655d0811191412t371982eev1bb77325719860f7@mail.gmail.com>
	<20081119235047.GA18604@hippogriff.homeunix.org>
	<m38wr9cey2.wl%bjg@network-theory.co.uk>
	<20081124175854.GA994@hippogriff.homeunix.org>
	<m3y6z7c10k.wl%bjg@network-theory.co.uk>
	<20081129214241.GA15002@hippogriff.homeunix.org>
	<m3d4g6jvsg.wl%bjg@network-theory.co.uk>
	<20081205191058.GA11218@hippogriff.homeunix.org>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.2 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Message-Mac: 90bd8e2a66e701529a1a44621cd869d5
Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gsl-discuss.sourceware.org>
List-Subscribe: <mailto:gsl-discuss-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gsl-discuss/>
List-Post: <mailto:gsl-discuss@sourceware.org>
List-Help: <mailto:gsl-discuss-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gsl-discuss-owner@sourceware.org
X-SW-Source: 2008-q4/txt/msg00044.txt.bz2

At Fri, 5 Dec 2008 12:10:58 -0700,
Patrick Alken wrote:
> Ah I hadn't considered this issue. If there are other areas of GSL
> which have the same issues maybe we should keep a list so when there
> is a major new release like 2.0 we could integrate these "extra"
> workspaces?

I've put the following in the toplevel TODO file. We should
probably make 2.0 the next release after this.

Changes for Release 2.0

Break binary compatibility, but keep source compatibility.

* Add a 'void *' to all workspaces, to allow for future changes.

* Disable deprecated functions

* Fix up the workspace_alloc functions so they have consistent names
  (add functions where needed, don't remove)


> Of course one problem with that is if we have a separate workspace
> for bspline derivatives it may never be convenient to integrate it
> with the normal bspline workspace.

True, unfortunately I don't see any easy way round that.