2011/5/4 Vitja Makarov :
> 2011/5/4 Vitja Makarov :
>> Hi!
>>
>> Jenkins doesn't work for me. It seems that it can't do pull and is
>> running tests again obsolete sources.
>> May be because of forced push.
>>
>> There are only 6 errors here:
>> https://sage.math.washington.edu:8091/hudson/view/cyt
2011/5/4 Vitja Makarov :
> Hi!
>
> Jenkins doesn't work for me. It seems that it can't do pull and is
> running tests again obsolete sources.
> May be because of forced push.
>
> There are only 6 errors here:
> https://sage.math.washington.edu:8091/hudson/view/cython-vitek/job/cython-vitek-tests-py
Hi!
Jenkins doesn't work for me. It seems that it can't do pull and is
running tests again obsolete sources.
May be because of forced push.
There are only 6 errors here:
https://sage.math.washington.edu:8091/hudson/view/cython-vitek/job/cython-vitek-tests-py27-c/
--
vitja.
_
On Tue, May 3, 2011 at 4:40 PM, Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>
>> ctypedef fused_type(float, double) speed_t
>> ctypedef fused_type(float, double) acceleration_t
>>
>> then you get 4 specializations.
>>
>> ctypedef speed_t acceleration_t
>>
>> I guess only 2 specializations.
>>
On Tue, May 3, 2011 at 12:59 PM, Dag Sverre Seljebotn
wrote:
> On 05/03/2011 08:19 PM, Robert Bradshaw wrote:
>
>>> Btw we shouldn't count on pruning for the design of this, I think this
>>> will
>>> for a large part be used with def functions. And if you use a cdef
>>> function
>>> from another m
Dag Sverre Seljebotn wrote:
ctypedef fused_type(float, double) speed_t
ctypedef fused_type(float, double) acceleration_t
then you get 4 specializations.
ctypedef speed_t acceleration_t
I guess only 2 specializations.
Treating the typedefs in this way is slightly fishy of course.
Indeed. Th
mark florisson wrote:
cdef func(floating x, floating y):
...
you get a "float, float" version, and a "double, double" version, but
not "float, double" or "double, float".
It's hard to draw conclusions from this example because
it's degenerate. You don't really need multiple versions of a
On 05/03/2011 08:19 PM, Robert Bradshaw wrote:
Btw we shouldn't count on pruning for the design of this, I think this will
for a large part be used with def functions. And if you use a cdef function
from another module through a pxd, you also need all versions.
Well, we'll want to avoid compil
On Tue, May 3, 2011 at 10:06 AM, mark florisson
wrote:
> On 3 May 2011 18:00, Robert Bradshaw wrote:
>> floating is implicitly available, we could require making it explicit.
>
> How would we make it explicit.
Require the parameterization, i.e.
floating_p[floating]
would be the as-yet-unsp
I was wrong. We need
cdef f(floating x, floating_p y)
...to get 2 specializations, not 4. And the rest follows from there. So I'm
with Robert's real stance :-)
I don't think we want flexibility, we want simplicity over all. You can always
use a templating language.
Btw we shouldn't count on p
On 3 May 2011 18:00, Robert Bradshaw wrote:
> On Tue, May 3, 2011 at 12:59 AM, mark florisson
> wrote:
>> On 3 May 2011 00:21, Robert Bradshaw wrote:
>>> On Mon, May 2, 2011 at 1:56 PM, mark florisson
>>> wrote:
On 2 May 2011 18:24, Robert Bradshaw wrote:
> On Sun, May 1, 2011 at 2:38
On 3 May 2011 16:36, Sturla Molden wrote:
> Den 03.05.2011 16:06, skrev Dag Sverre Seljebotn:
>>
>> Well, if you do something like
>>
>> ctypedef fused_type(float, double) speed_t
>> ctypedef fused_type(float, double) acceleration_t
>>
>> cdef func(speed_t x, acceleration_t y)
>>
>> then you get 4
On Tue, May 3, 2011 at 7:06 AM, Dag Sverre Seljebotn
wrote:
> On 05/03/2011 03:51 PM, Stefan Behnel wrote:
>>
>> mark florisson, 03.05.2011 15:17:
>>>
>>> if you have
>>>
>>> cdef func(floating x, floating y):
>>> ...
>>>
>>> you get a "float, float" version, and a "double, double" version, but
>>
On Tue, May 3, 2011 at 12:59 AM, mark florisson
wrote:
> On 3 May 2011 00:21, Robert Bradshaw wrote:
>> On Mon, May 2, 2011 at 1:56 PM, mark florisson
>> wrote:
>>> On 2 May 2011 18:24, Robert Bradshaw wrote:
On Sun, May 1, 2011 at 2:38 AM, mark florisson
wrote:
> A remaining iss
Den 03.05.2011 16:06, skrev Dag Sverre Seljebotn:
Well, if you do something like
ctypedef fused_type(float, double) speed_t
ctypedef fused_type(float, double) acceleration_t
cdef func(speed_t x, acceleration_t y)
then you get 4 specializations. Each new typedef gives a new
polymorphic type.
On 05/03/2011 03:51 PM, Stefan Behnel wrote:
mark florisson, 03.05.2011 15:17:
if you have
cdef func(floating x, floating y):
...
you get a "float, float" version, and a "double, double" version, but
not "float, double" or "double, float".
So, what would you have to do in order to get a "flo
mark florisson, 03.05.2011 15:17:
if you have
cdef func(floating x, floating y):
...
you get a "float, float" version, and a "double, double" version, but
not "float, double" or "double, float".
So, what would you have to do in order to get a "float, double" and
"double, float" version
On 3 May 2011 15:17, mark florisson wrote:
> On 3 May 2011 07:47, Greg Ewing wrote:
>> I'm a bit confused about how fused types combine to
>> create further fused types. If you have something
>> like
>>
>> ctypedef struct Vector:
>> floating x
>> floating y
>> floating z
>>
>> then is i
On 3 May 2011 07:47, Greg Ewing wrote:
> I'm a bit confused about how fused types combine to
> create further fused types. If you have something
> like
>
> ctypedef struct Vector:
> floating x
> floating y
> floating z
>
> then is it going to generate code for all possible
> combinations
I'm a bit confused about how fused types combine to
create further fused types. If you have something
like
ctypedef struct Vector:
floating x
floating y
floating z
then is it going to generate code for all possible
combinations of types for x, y and z?
That's probably not what the
On 3 May 2011 10:57, Dag Sverre Seljebotn wrote:
> On 05/03/2011 10:49 AM, mark florisson wrote:
>>
>> On 3 May 2011 10:44, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 05/03/2011 10:42 AM, mark florisson wrote:
On 3 May 2011 10:07, Dag Sverre Seljebotn
wrote:
>
> On 05/03/20
On 05/03/2011 10:49 AM, mark florisson wrote:
On 3 May 2011 10:44, Dag Sverre Seljebotn wrote:
On 05/03/2011 10:42 AM, mark florisson wrote:
On 3 May 2011 10:07, Dag Sverre Seljebotn
wrote:
On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshaw
wrote:
On
On 3 May 2011 10:44, Dag Sverre Seljebotn wrote:
> On 05/03/2011 10:42 AM, mark florisson wrote:
>>
>> On 3 May 2011 10:07, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshaw
wrote:
>
> On Mon, May 2, 2
On 05/03/2011 10:42 AM, mark florisson wrote:
On 3 May 2011 10:07, Dag Sverre Seljebotn wrote:
On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshawwrote:
On Mon, May 2, 2011 at 1:56 PM, mark florisson
wrote:
On 2 May 2011 18:24, Robert Bradshaw
wrot
On 3 May 2011 10:07, Dag Sverre Seljebotn wrote:
> On 05/03/2011 09:59 AM, mark florisson wrote:
>>
>> On 3 May 2011 00:21, Robert Bradshaw wrote:
>>>
>>> On Mon, May 2, 2011 at 1:56 PM, mark florisson
>>> wrote:
On 2 May 2011 18:24, Robert Bradshaw
wrote:
>
> On Sun, Ma
On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshaw wrote:
On Mon, May 2, 2011 at 1:56 PM, mark florisson
wrote:
On 2 May 2011 18:24, Robert Bradshaw wrote:
On Sun, May 1, 2011 at 2:38 AM, mark florisson
wrote:
A remaining issue which I'm not quite certain
On 3 May 2011 00:21, Robert Bradshaw wrote:
> On Mon, May 2, 2011 at 1:56 PM, mark florisson
> wrote:
>> On 2 May 2011 18:24, Robert Bradshaw wrote:
>>> On Sun, May 1, 2011 at 2:38 AM, mark florisson
>>> wrote:
A remaining issue which I'm not quite certain about is the
specialization
Hi!
I can move unreachable code removal into its own branch and then make
a pull request.
But it seems to me that dead code removal should be done in control
flow analysis so there are few options:
1. remove unreachable code in control flow transformation
2. set is_terminator flag in control flo
28 matches
Mail list logo