Re: [Cython] Cython 0.15 release

2011-07-28 Thread 최원준
I had posted several issues in detail on the list
but there was no answer so I deleted it several times.. on the cython users
list.
I just want to hear the answer(like a "describe in detail") even though the
answer guy doesn't know the solution.
I think no answer is bothering act.

It is easy to tell me rtfm or do not post in here.



2011/7/28 Dag Sverre Seljebotn 

> ** The reason you do not get answers is because people do not understand
> your question. Please describe in detail what you want to do (on the users
> list).
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
>
> "최원준"  wrote:
>>
>> because of no answer on the cython users..
>> anyone knows about this?
>>
>>
>>
>> 2011/7/28 Stefan Behnel 
>>
>>> 최원준, 28.07.2011 08:23:
>>>
>>>  Can I make cython file from python and C using generators?

>>>
>>> Please ask your question on the cython-users mailing list, not on this
>>> list, which is the core developers mailing list. And please try to be
>>> specific about what you want to achieve. It's not clear to me at all from
>>> the question above what you are trying to do.
>>>
>>>
>>> Stefan
>>> __**_
>>> cython-devel mailing list
>>> cython-devel@python.org
>>> http://mail.python.org/**mailman/listinfo/cython-devel
>>>
>>
>>
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
>
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] Cython 0.15 release

2011-07-28 Thread Stefan Behnel

최원준, 28.07.2011 09:31:

I had posted several issues in detail on the list
but there was no answer so I deleted it several times.. on the cython users
list.
I just want to hear the answer(like a "describe in detail") even though the
answer guy doesn't know the solution.
I think no answer is bothering act.


It's much more "bothering" to ask questions that no-one understands, 
because a lot of nice and helpful people will waste time in reading them 
and trying to understand them before they resign. They want to help you, 
but you do not allow them to do it.


It's not a problem if you have difficulties with the English language, 
which the users mailing list deploys. We try to be helpful anyway.


It *is*, however, a problem if you do not provide the details that are 
necessary to understand what you want. It's in your own interest to make 
others understand. After all, it's *you* who wants a specific problem solved.


This will help you in writing better questions:

http://www.catb.org/~esr/faqs/smart-questions.html



It is easy to tell me rtfm


We cannot tell you "RTFM" as long as we do not even know which manual you 
need to read.




or do not post in here.


We tell you not to post on this list, because it is the wrong list. Please 
use the users mailing list for usage related questions.


This is the last time I tell you this.

Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] Cython 0.15 release

2011-07-28 Thread 최원준
OK Nervermind!
The problem is that I don't know my question is wrong unless someone tell me
"what are you talking about?"
or "Please describe in detail"

and Sorry for posting in here.



2011/7/28 Stefan Behnel 

> 최원준, 28.07.2011 09:31:
>
>  I had posted several issues in detail on the list
>> but there was no answer so I deleted it several times.. on the cython
>> users
>> list.
>> I just want to hear the answer(like a "describe in detail") even though
>> the
>> answer guy doesn't know the solution.
>> I think no answer is bothering act.
>>
>
> It's much more "bothering" to ask questions that no-one understands,
> because a lot of nice and helpful people will waste time in reading them and
> trying to understand them before they resign. They want to help you, but you
> do not allow them to do it.
>
> It's not a problem if you have difficulties with the English language,
> which the users mailing list deploys. We try to be helpful anyway.
>
> It *is*, however, a problem if you do not provide the details that are
> necessary to understand what you want. It's in your own interest to make
> others understand. After all, it's *you* who wants a specific problem
> solved.
>
> This will help you in writing better questions:
>
> http://www.catb.org/~esr/faqs/**smart-questions.html
>
>
>
>  It is easy to tell me rtfm
>>
>
> We cannot tell you "RTFM" as long as we do not even know which manual you
> need to read.
>
>
>
>  or do not post in here.
>>
>
> We tell you not to post on this list, because it is the wrong list. Please
> use the users mailing list for usage related questions.
>
> This is the last time I tell you this.
>
>
> Stefan
> __**_
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/**mailman/listinfo/cython-devel
>
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] GCC 4.6 unused-but-set-variable warnings

2011-07-28 Thread Stefan Behnel

[moving this here from cython-users]

Nikolaus Rath, 13.06.2011 16:59:

Stefan Behnel writes:

Nikolaus Rath, 13.06.2011 01:18:

Stefan Behnel writes:

Nikolaus Rath, 03.06.2011 23:24:

Cython 0.14 generated code triggers lots of  unused-but-set-variable
warnings (which are new in GCC 4.6).


Hmm, that's annoying. We actually generate a lot of useless "dangling
reset to 0" statements for safety (and also as a bit of a "now unused"
hint to the C compiler).

We could get rid of most of them based on control flow analysis, but I
actually like having them there, just in case we accidentally generate
broken code at some point. A NULL pointer is a lot safer than an
arbitrarily dangling address, especially when it comes to CPython heap
allocated memory (which doesn't necessarily get freed, so you may not
get a quick segfault but a read from dead memory).


I don't quite understand. The way to get rid of the warnings is to
remove the unnecessary variables. How can this result in a dangling
address? You'll get a syntax error from gcc about using an undeclared
variable.


Ah, sorry. I misunderstood the meaning of the warning message as
pointing at unnecessary assignments in general. Could you post a C
code snippet (and the corresponding Cython code) that triggers this? I
don't have gcc 4.6 available for testing.


Sure. It's apparently triggered by unused function arguments:

$ cat test.pyx
class Operations(object):
 def handle_exc(self, fn, exc):
 pass

$ cython test.pyx

$ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c test.c -o test.o 
-D_FILE_OFFSET_BITS=64 -I/usr/include/fuse -Werror -Wall -Wextra -Wconversion 
-Wno-unused-parameter -Wno-sign-conversion -fno-strict-aliasing test.c:
test.c:454:13: warning: variable ‘__pyx_v_exc’ set but not used 
[-Wunused-but-set-variable]
test.c:453:13: warning: variable ‘__pyx_v_fn’ set but not used 
[-Wunused-but-set-variable]
test.c:452:13: warning: variable ‘__pyx_v_self’ set but not used 
[-Wunused-but-set-variable]


http://trac.cython.org/cython_trac/ticket/704

I think this is something that the control flow analysis could deal with. 
Basically, every parameter that turns out to be unused in the function (and 
this most likely only happens with parameters) could be ignored, unless it 
requires a type conversion with potential side effects. In that (unlikely) 
case, we could still drop the final assignment to the variable itself.


Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] GCC 4.6 unused-but-set-variable warnings

2011-07-28 Thread Vitja Makarov
2011/7/29 Stefan Behnel :
> [moving this here from cython-users]
>
> Nikolaus Rath, 13.06.2011 16:59:
>>
>> Stefan Behnel writes:
>>>
>>> Nikolaus Rath, 13.06.2011 01:18:

 Stefan Behnel writes:
>
> Nikolaus Rath, 03.06.2011 23:24:
>>
>> Cython 0.14 generated code triggers lots of  unused-but-set-variable
>> warnings (which are new in GCC 4.6).
>
> Hmm, that's annoying. We actually generate a lot of useless "dangling
> reset to 0" statements for safety (and also as a bit of a "now unused"
> hint to the C compiler).
>
> We could get rid of most of them based on control flow analysis, but I
> actually like having them there, just in case we accidentally generate
> broken code at some point. A NULL pointer is a lot safer than an
> arbitrarily dangling address, especially when it comes to CPython heap
> allocated memory (which doesn't necessarily get freed, so you may not
> get a quick segfault but a read from dead memory).

 I don't quite understand. The way to get rid of the warnings is to
 remove the unnecessary variables. How can this result in a dangling
 address? You'll get a syntax error from gcc about using an undeclared
 variable.
>>>
>>> Ah, sorry. I misunderstood the meaning of the warning message as
>>> pointing at unnecessary assignments in general. Could you post a C
>>> code snippet (and the corresponding Cython code) that triggers this? I
>>> don't have gcc 4.6 available for testing.
>>
>> Sure. It's apparently triggered by unused function arguments:
>>
>> $ cat test.pyx
>> class Operations(object):
>>     def handle_exc(self, fn, exc):
>>         pass
>>
>> $ cython test.pyx
>>
>> $ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
>> -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c test.c -o test.o
>> -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse -Werror -Wall -Wextra
>> -Wconversion -Wno-unused-parameter -Wno-sign-conversion -fno-strict-aliasing
>> test.c:
>> test.c:454:13: warning: variable ‘__pyx_v_exc’ set but not used
>> [-Wunused-but-set-variable]
>> test.c:453:13: warning: variable ‘__pyx_v_fn’ set but not used
>> [-Wunused-but-set-variable]
>> test.c:452:13: warning: variable ‘__pyx_v_self’ set but not used
>> [-Wunused-but-set-variable]
>
> http://trac.cython.org/cython_trac/ticket/704
>
> I think this is something that the control flow analysis could deal with.
> Basically, every parameter that turns out to be unused in the function (and
> this most likely only happens with parameters) could be ignored, unless it
> requires a type conversion with potential side effects. In that (unlikely)
> case, we could still drop the final assignment to the variable itself.
>

There is entry.cf_unused flag it's set when the whole entry is not used.

-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] GCC 4.6 unused-but-set-variable warnings

2011-07-28 Thread Vitja Makarov
2011/7/29 Vitja Makarov :
> 2011/7/29 Stefan Behnel :
>> [moving this here from cython-users]
>>
>> Nikolaus Rath, 13.06.2011 16:59:
>>>
>>> Stefan Behnel writes:

 Nikolaus Rath, 13.06.2011 01:18:
>
> Stefan Behnel writes:
>>
>> Nikolaus Rath, 03.06.2011 23:24:
>>>
>>> Cython 0.14 generated code triggers lots of  unused-but-set-variable
>>> warnings (which are new in GCC 4.6).
>>
>> Hmm, that's annoying. We actually generate a lot of useless "dangling
>> reset to 0" statements for safety (and also as a bit of a "now unused"
>> hint to the C compiler).
>>
>> We could get rid of most of them based on control flow analysis, but I
>> actually like having them there, just in case we accidentally generate
>> broken code at some point. A NULL pointer is a lot safer than an
>> arbitrarily dangling address, especially when it comes to CPython heap
>> allocated memory (which doesn't necessarily get freed, so you may not
>> get a quick segfault but a read from dead memory).
>
> I don't quite understand. The way to get rid of the warnings is to
> remove the unnecessary variables. How can this result in a dangling
> address? You'll get a syntax error from gcc about using an undeclared
> variable.

 Ah, sorry. I misunderstood the meaning of the warning message as
 pointing at unnecessary assignments in general. Could you post a C
 code snippet (and the corresponding Cython code) that triggers this? I
 don't have gcc 4.6 available for testing.
>>>
>>> Sure. It's apparently triggered by unused function arguments:
>>>
>>> $ cat test.pyx
>>> class Operations(object):
>>>     def handle_exc(self, fn, exc):
>>>         pass
>>>
>>> $ cython test.pyx
>>>
>>> $ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
>>> -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c test.c -o test.o
>>> -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse -Werror -Wall -Wextra
>>> -Wconversion -Wno-unused-parameter -Wno-sign-conversion -fno-strict-aliasing
>>> test.c:
>>> test.c:454:13: warning: variable ‘__pyx_v_exc’ set but not used
>>> [-Wunused-but-set-variable]
>>> test.c:453:13: warning: variable ‘__pyx_v_fn’ set but not used
>>> [-Wunused-but-set-variable]
>>> test.c:452:13: warning: variable ‘__pyx_v_self’ set but not used
>>> [-Wunused-but-set-variable]
>>
>> http://trac.cython.org/cython_trac/ticket/704
>>
>> I think this is something that the control flow analysis could deal with.
>> Basically, every parameter that turns out to be unused in the function (and
>> this most likely only happens with parameters) could be ignored, unless it
>> requires a type conversion with potential side effects. In that (unlikely)
>> case, we could still drop the final assignment to the variable itself.
>>
>
> There is entry.cf_unused flag it's set when the whole entry is not used.
>

((6af313c...)) vitja@vitja-laptop:~/work/cython-vitek$ python
cython.py -X warn.unused_arg=True test.pyx
warning: test.pyx:2:19: Unused argument 'self'
warning: test.pyx:2:25: Unused argument 'fn'
warning: test.pyx:2:29: Unused argument 'exc'


-- 
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] GCC 4.6 unused-but-set-variable warnings

2011-07-28 Thread Stefan Behnel

Vitja Makarov, 29.07.2011 08:38:

2011/7/29 Vitja Makarov:

2011/7/29 Stefan Behnel:

Nikolaus Rath, 13.06.2011 16:59:

$ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c test.c -o test.o
-D_FILE_OFFSET_BITS=64 -I/usr/include/fuse -Werror -Wall -Wextra
-Wconversion -Wno-unused-parameter -Wno-sign-conversion -fno-strict-aliasing
test.c:
test.c:454:13: warning: variable ‘__pyx_v_exc’ set but not used
[-Wunused-but-set-variable]
test.c:453:13: warning: variable ‘__pyx_v_fn’ set but not used
[-Wunused-but-set-variable]
test.c:452:13: warning: variable ‘__pyx_v_self’ set but not used
[-Wunused-but-set-variable]


http://trac.cython.org/cython_trac/ticket/704

I think this is something that the control flow analysis could deal with.
Basically, every parameter that turns out to be unused in the function (and
this most likely only happens with parameters) could be ignored, unless it
requires a type conversion with potential side effects. In that (unlikely)
case, we could still drop the final assignment to the variable itself.


There is entry.cf_unused flag it's set when the whole entry is not used.


((6af313c...)) vitja@vitja-laptop:~/work/cython-vitek$ python
cython.py -X warn.unused_arg=True test.pyx
warning: test.pyx:2:19: Unused argument 'self'
warning: test.pyx:2:25: Unused argument 'fn'
warning: test.pyx:2:29: Unused argument 'exc'


Cool. That's what I expected. :)

Want to give it a try? The argument unpacking code has traditionally been 
my domain, and it's somewhat complex, but it should still be easy to stick 
this in. Note that there is more than one place where this needs to be 
handled, as the code is structured into different cases based on the type 
of signature.


Otherwise, I can see if I find a bit of time over the weekend.

Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel