On Thu, Nov 19, 2009 at 01:43, David Cournapeau
wrote:
> Robert Kern wrote:
>
>> One can have a proprietary application statically linked
>> with an LGPL library. The only detail there is that, in order to
>> satisfy the "user must be able to relink the application with a
>> modified Library" req
Robert Kern wrote:
> One can have a proprietary application statically linked
> with an LGPL library. The only detail there is that, in order to
> satisfy the "user must be able to relink the application with a
> modified Library" requirement, the distributor must provide object
> files for his p
On Wed, Nov 18, 2009 at 23:39, David Cournapeau
wrote:
> Robert Kern wrote:
>> On Wed, Nov 18, 2009 at 22:52, David Cournapeau
>> wrote:
>>
>>> René Dudfield wrote:
>>>
pygame is also LGPL... as are a number of other libraries. (pyqt is GPL
btw).
LGPL basically means you can
Robert Kern wrote:
> On Wed, Nov 18, 2009 at 22:52, David Cournapeau
> wrote:
>
>> René Dudfield wrote:
>>
>>> pygame is also LGPL... as are a number of other libraries. (pyqt is GPL
>>> btw).
>>>
>>> LGPL basically means you can link to the library source, but if you
>>> make changes to
On Wed, Nov 18, 2009 at 22:52, David Cournapeau
wrote:
> René Dudfield wrote:
>> pygame is also LGPL... as are a number of other libraries. (pyqt is GPL
>> btw).
>>
>> LGPL basically means you can link to the library source, but if you
>> make changes to the library you should give them back. U
René Dudfield wrote:
> pygame is also LGPL... as are a number of other libraries. (pyqt is GPL btw).
>
> LGPL basically means you can link to the library source, but if you
> make changes to the library you should give them back. Users should
> also be able to change the library if they want... e
On Fri, Nov 6, 2009 at 7:46 PM, David Cournapeau wrote:
> On Sat, Nov 7, 2009 at 3:41 AM, David Cournapeau wrote:
>
>> I don't think LGPL has much meaning for
>> python code, especially pure python code (and m4 for that matter)
>
> This is funny - besides pyqt, the only LGPL reference with python
On 11/12/2009 05:56 PM, David Cournapeau wrote:
> On Thu, Nov 12, 2009 at 11:34 PM, Michael Droettboom wrote:
>
>> I'm happy to make these changes, since I've got access to the "finicky"
>> platform, but want to confirm how you would prefer it done first.
>>
> Cool. The changes should be
On Thu, Nov 12, 2009 at 11:34 PM, Michael Droettboom wrote:
> The new macros contain non-constant initializers for a type declared
> constant.
>
> const union IEEEl2bitsrep u = {x};
>
> AFAIK, ANSI dictates that the initializer must be a literal or another
> constant variable. We could declare
The new macros contain non-constant initializers for a type declared
constant.
const union IEEEl2bitsrep u = {x};
AFAIK, ANSI dictates that the initializer must be a literal or another
constant variable. We could declare 'x' as constant in the function
signature, but it actually does get
On Thu, Nov 12, 2009 at 12:45 AM, David Cournapeau wrote:
>
> I will implement this, but I would prefer using this method everywhere
> for every compiler, it would be more robust.
Done for r7727. I have not tested it much (I have only checked that
the bit twiddling macros to get sign/exp/mantiss
On Thu, Nov 12, 2009 at 12:33 AM, Michael Droettboom wrote:
> Thanks. Behind that, however, it runs into this compiler shortcoming:
>
> cc: build/src.solaris-2.8-sun4u-2.5/numpy/core/src/npymath/npy_math.c
> "numpy/core/src/npymath/npy_math_private.h", line 229: invalid type for
> bit-field: man
Forgot to attach the patch.
Mike
Michael Droettboom wrote:
Thanks. Behind that, however, it runs into this compiler shortcoming:
cc: build/src.solaris-2.8-sun4u-2.5/numpy/core/src/npymath/npy_math.c
"numpy/core/src/npymath/npy_math_private.h", line 229: invalid type
for bit-field: manh
"nump
Thanks. Behind that, however, it runs into this compiler shortcoming:
cc: build/src.solaris-2.8-sun4u-2.5/numpy/core/src/npymath/npy_math.c
"numpy/core/src/npymath/npy_math_private.h", line 229: invalid type for
bit-field: manh
"numpy/core/src/npymath/npy_math_private.h", line 230: invalid type
On Wed, Nov 11, 2009 at 6:18 AM, Michael Droettboom wrote:
> I don't know if your 'long double' detection code is complete yet, but I
> thought I'd share the current build output on one of our Solaris
> machines. It looks like it may just be a typo difference between
> 'IEEE_QUAD_BE' in long_doub
I don't know if your 'long double' detection code is complete yet, but I
thought I'd share the current build output on one of our Solaris
machines. It looks like it may just be a typo difference between
'IEEE_QUAD_BE' in long_double_representation() and 'IEEE_QUAD_16B_BE' in
setup.py, but I wa
On Sun, Nov 8, 2009 at 10:04 PM, David Cournapeau <
da...@ar.media.kyoto-u.ac.jp> wrote:
> Charles R Harris wrote:
> >
> > I don't remember how PPC does it's arithmetic with the two doubles,
> > but one holds small values that are added to the other double, so I
> > don't think it can be just like
Charles R Harris wrote:
>
> I don't remember how PPC does it's arithmetic with the two doubles,
> but one holds small values that are added to the other double, so I
> don't think it can be just like a double in some circumstances.
That's not how it seems to work on mac os x - when I look at the
g
On Sun, Nov 8, 2009 at 10:11 PM, Charles R Harris wrote:
>
>
> On Sun, Nov 8, 2009 at 9:43 PM, David Cournapeau wrote:
>
>> On Mon, Nov 9, 2009 at 12:49 PM, Charles R Harris
>> wrote:
>>
>> >>
>> >
>> > Umm, PPC doesn't have ieee quad, it is an amalgam of two doubles.
>>
>> Good catch ! I added
On Sun, Nov 8, 2009 at 9:43 PM, David Cournapeau wrote:
> On Mon, Nov 9, 2009 at 12:49 PM, Charles R Harris
> wrote:
>
> >>
> >
> > Umm, PPC doesn't have ieee quad, it is an amalgam of two doubles.
>
> Good catch ! I added a new type define for this case, with the
> corresponding union.
>
> I ha
On Mon, Nov 9, 2009 at 12:49 PM, Charles R Harris
wrote:
>>
>
> Umm, PPC doesn't have ieee quad, it is an amalgam of two doubles.
Good catch ! I added a new type define for this case, with the
corresponding union.
I have quickly tested it under rosetta, and it seems that
npy_nextafterl gives a
On Sun, Nov 8, 2009 at 8:12 PM, David Cournapeau wrote:
> Hi Michael,
>
> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom
> wrote:
> > I'm getting the following from r7603 on Solaris Sparc -- somehow related
> > to not having a long double version of next after available. I realise
> > not e
Hi Michael,
On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom wrote:
> I'm getting the following from r7603 on Solaris Sparc -- somehow related
> to not having a long double version of next after available. I realise
> not everyone has access to (or is dependent on) this platform, so I'm
> will
Charles R Harris wrote:
>
>
> On Thu, Nov 5, 2009 at 10:35 PM, David Cournapeau
> mailto:da...@ar.media.kyoto-u.ac.jp>>
> wrote:
>
> Charles R Harris wrote:
> > So you are going to leave us all hanging here in curiosity? What is
> > your solution?
>
> I had to sleep :)
>
> The s
On Thu, Nov 5, 2009 at 10:35 PM, David Cournapeau <
da...@ar.media.kyoto-u.ac.jp> wrote:
> Charles R Harris wrote:
> > So you are going to leave us all hanging here in curiosity? What is
> > your solution?
>
> I had to sleep :)
>
> The solution is based on parsing the generated binary code - that'
Charles R Harris wrote:
> So you are going to leave us all hanging here in curiosity? What is
> your solution?
I had to sleep :)
The solution is based on parsing the generated binary code - that's how
MPFR is doing it, so it has been tested in the wild. The code to compile
is something like:
/*
On Thu, Nov 5, 2009 at 4:55 AM, Michael Droettboom wrote:
> David Cournapeau wrote:
>> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom wrote:
>>
>>> I'm getting the following from r7603 on Solaris Sparc -- somehow related
>>> to not having a long double version of next after available. I real
David Cournapeau wrote:
> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom wrote:
>
>> I'm getting the following from r7603 on Solaris Sparc -- somehow related
>> to not having a long double version of next after available. I realise
>> not everyone has access to (or is dependent on) this pl
On Wed, Nov 4, 2009 at 12:38 PM, Charles R Harris wrote:
>
>
> On Wed, Nov 4, 2009 at 12:35 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Wed, Nov 4, 2009 at 12:11 PM, David Cournapeau wrote:
>>
>>> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom
>>> wrote:
>>> > I'
On Wed, Nov 4, 2009 at 12:35 PM, Charles R Harris wrote:
>
>
> On Wed, Nov 4, 2009 at 12:11 PM, David Cournapeau wrote:
>
>> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom
>> wrote:
>> > I'm getting the following from r7603 on Solaris Sparc -- somehow related
>> > to not having a long double
On Wed, Nov 4, 2009 at 12:11 PM, David Cournapeau wrote:
> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom
> wrote:
> > I'm getting the following from r7603 on Solaris Sparc -- somehow related
> > to not having a long double version of next after available. I realise
> > not everyone has acce
On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom wrote:
> I'm getting the following from r7603 on Solaris Sparc -- somehow related
> to not having a long double version of next after available. I realise
> not everyone has access to (or is dependent on) this platform, so I'm
> willing to help i
I'm getting the following from r7603 on Solaris Sparc -- somehow related
to not having a long double version of next after available. I realise
not everyone has access to (or is dependent on) this platform, so I'm
willing to help in whatever way I can, I'm just not sure I understand
the change
33 matches
Mail list logo
