On Thu, Mar 27, 2008 at 9:02 AM, Gary Furnish <[EMAIL PROTECTED]> wrote:
> I'll move this to an spkg.
With it moved to an spkg, I now vote +1, which makes it unanimous and official
that glib-lite goes into Sage (as an spkg).
-- William
>
>
> On Thu, Mar 27, 2008 at 2:07 AM, mabshoff
> <[EMAIL
I'll move this to an spkg.
On Thu, Mar 27, 2008 at 2:07 AM, mabshoff <
[EMAIL PROTECTED]> wrote:
>
>
> > > Furthermore, I intend to help
> > > maintain the C algorithms. I fully intend to work on them actively if
> their
> > > speed is not sufficient. Making a seperate spkg dramatically increa
> > Furthermore, I intend to help
> > maintain the C algorithms. I fully intend to work on them actively if their
> > speed is not sufficient. Making a seperate spkg dramatically increases the
> > difficulty of active development.
>
> Why??? I could have said the same about Pyrex two years ago
On Mar 26, 2008, at 4:48 PM, Gary Furnish wrote:
> I have not yet benchmarked hash tables (nor actually tried them
> out), but one of the big advantages is that they avoid much of the
> memory management issues, so I don't expect them to be slower (and
> if they are, I may have to fix that)
On Wed, 26 Mar 2008 11:57:26 -0700, Gary Furnish <[EMAIL PROTECTED]> wrote:
> Honestly, independent of the spkg vs libcsage issue, which is really an
> issue of semantics in my opinion, Sage has no high speed implementations of
> C algorithms. Sage can not escape this forever. Either someone wi
On Wed, 26 Mar 2008 14:06:08 -0700, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> On Mar 26, 2008, at 11:57 AM, Gary Furnish wrote:
>
>> Honestly, independent of the spkg vs libcsage issue, which is
>> really an issue of semantics in my opinion, Sage has no high speed
>> implementations of C alg
There are non trivial changes involved in getting compilation without
internationalization, primarily because their error handling system uses
internationalization in many places. Its not just a copy and paste job, but
now that I've figured out exactly what headers we need and set up autoconf
repl
On Mar 26, 2008, at 11:57 AM, Gary Furnish wrote:
> Honestly, independent of the spkg vs libcsage issue, which is
> really an issue of semantics in my opinion, Sage has no high speed
> implementations of C algorithms. Sage can not escape this forever.
> Either someone will have to write the
Honestly, independent of the spkg vs libcsage issue, which is really an
issue of semantics in my opinion, Sage has no high speed implementations of
C algorithms. Sage can not escape this forever. Either someone will have
to write their own at some point or we can use glib as a starting block. It
On Wed, Mar 26, 2008 at 11:16 AM, didier deshommes <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Mar 26, 2008 at 1:52 PM, mabshoff
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On Mar 26, 6:43 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > > On Wed, Mar 26, 2008 at 10:09 AM, mabshoff
> >
On Wed, Mar 26, 2008 at 1:52 PM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Mar 26, 6:43 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 26, 2008 at 10:09 AM, mabshoff
> >
>
> > <[EMAIL PROTECTED]> wrote:
> >
> > > On Mar 26, 6:02 pm, "William Stein" <[EMAIL PROTECTED]> wr
On Mar 26, 6:43 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 26, 2008 at 10:09 AM, mabshoff
>
> <[EMAIL PROTECTED]> wrote:
>
> > On Mar 26, 6:02 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > > Is any of the code gpl v3+ only?
>
> > No.
>
> That's good.
>
>
>
> > > How di
On Wed, Mar 26, 2008 at 10:09 AM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Mar 26, 6:02 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > Is any of the code gpl v3+ only?
>
> No.
That's good.
>
>
> > How difficult will it be to update our version whenever upstream
> > changes? Do on
On Mar 26, 6:02 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> Is any of the code gpl v3+ only?
No.
> How difficult will it be to update our version whenever upstream
> changes? Do only you know how to do this?
Not particularly hard.
> Why put this in c_lib instead of a separate spkg call
Is any of the code gpl v3+ only?
How difficult will it be to update our version whenever upstream
changes? Do only you know how to do this?
Why put this in c_lib instead of a separate spkg called glib-min?
Couldn't such a package be useful outside of sage?
Any chance the glib people might see
On Mar 25, 5:12 pm, Gary Furnish <[EMAIL PROTECTED]> wrote:
> Trac #2436 adds the following algorithms from glib to libcsage:
> Multiplatform threads
> Thread pools
> Asynchronous Queues
> Memory Slices
> Doubly and Singly linked lists
> Queues
> Sequences
> Hash Tables
> Arrays
> Balanced Binary
On Wednesday 26 March 2008, Gary Furnish wrote:
> Trac #2436 adds the following algorithms from glib to libcsage:
> Multiplatform threads
> Thread pools
> Asynchronous Queues
> Memory Slices
> Doubly and Singly linked lists
> Queues
> Sequences
> Hash Tables
> Arrays
> Balanced Binary Trees
> N-ar
+1
--Mike
On Tue, Mar 25, 2008 at 7:15 PM, <[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Tue, 25 Mar 2008, Gary Furnish wrote:
>
> >
> > Trac #2436 adds the following algorithms from glib to libcsage:
> > Multiplatform threads
> > Thread pools
> > Asynchronous Queues
> > Memory Slices
> > Dou
On Tue, 25 Mar 2008, Gary Furnish wrote:
>
> Trac #2436 adds the following algorithms from glib to libcsage:
> Multiplatform threads
> Thread pools
> Asynchronous Queues
> Memory Slices
> Doubly and Singly linked lists
> Queues
> Sequences
> Hash Tables
> Arrays
> Balanced Binary Trees
> N-ary
On Mar 26, 1:12 am, Gary Furnish <[EMAIL PROTECTED]> wrote:
> Trac #2436 adds the following algorithms from glib to libcsage:
> Multiplatform threads
> Thread pools
> Asynchronous Queues
> Memory Slices
> Doubly and Singly linked lists
> Queues
> Sequences
> Hash Tables
> Arrays
> Balanced Binar
20 matches
Mail list logo
