[Cython] Bootstrapping broken in master
Checking out Cython from master (the 0.23.x branch works fine) and running "python setup.py install" gives me Unable to find pgen, not compiling formal grammar. Compiling module Cython.Compiler.Scanning ... ERROR: 'module' object has no attribute 'CCodeConfig' Extension module compilation failed, looks like Cython cannot run properly on this system. To work around this, pass the option "--no-cython-compile". This will install a pure Python version of Cython without compiling its own sources. Traceback (most recent call last): File "setup.py", line 289, in compile_cython_modules(cython_profile, cython_compile_more, cython_with_refnanny) File "setup.py", line 233, in compile_cython_modules result = compile(pyx_source_file) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Main.py", line 677, in compile return compile_single(source, options, full_module_name) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Main.py", line 630, in compile_single return run_pipeline(source, options, full_module_name) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Main.py", line 487, in run_pipeline err, enddata = Pipeline.run_pipeline(pipeline, source) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Pipeline.py", line 334, in run_pipeline data = phase(data) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Pipeline.py", line 53, in generate_pyx_code_stage module_node.process_implementation(options, result) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/ModuleNode.py", line 118, in process_implementation self.generate_c_code(env, options, result) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/ModuleNode.py", line 317, in generate_c_code c_code_config = Code.CCodeConfig( AttributeError: 'module' object has no attribute 'CCodeConfig' ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bootstrapping broken in master
Jeroen Demeyer schrieb am 05.09.2015 um 11:01: > Checking out Cython from master (the 0.23.x branch works fine) and running > "python setup.py install" gives me > > Unable to find pgen, not compiling formal grammar. > Compiling module Cython.Compiler.Scanning ... > > ERROR: 'module' object has no attribute 'CCodeConfig' Did you try a clean checkout? I.e. delete all .so files in the tree and rebuild? This looks like there's a stale "Code.so" in Cython/Compiler/. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] overflow bug?
Hi Mark!
Mark Florisson schrieb am 14.07.2015 um 20:34:
> I think this might be a bug (python 3.3 + cython 0.22.1):
>
> def f(term=b"12345"):
>
> val = int('987278186585')
> # The below line does not work, because it treats 1 as a constant integer
> # in the C code (32 bit on my machine). Using 1L does work however.
> val -= 1 << (len(term) * 8)
> return val
>
> print(f())
>
> This works in pure-python, but Cython generates '1 <<
> __pyx_t_somevar', which I think treats the '1' as an integer (causing
> it to overflow). Using '1L' works in the Cython code however (but that
> may be just my platform).
Thanks for the report. Yes, the generated C code evaluates the shift
operation in C space as
(1 << (__pyx_t_2 * 8))
And yes, I consider this a bug. It's not entirely easy to find the right
fix, though. I mean, the obvious thing to do would be to evaluate all
left-shift operations in Python space, but that wouldn't be fast for the
"normal" cases. Not sure if there's a point where to draw a line, though...
Stefan
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] overflow bug?
On 2015-09-05 11:22, Stefan Behnel wrote: Thanks for the report. Yes, the generated C code evaluates the shift operation in C space as (1 << (__pyx_t_2 * 8)) And yes, I consider this a bug. It's not entirely easy to find the right fix, though. I mean, the obvious thing to do would be to evaluate all left-shift operations in Python space, but that wouldn't be fast for the "normal" cases. Not sure if there's a point where to draw a line, though... To me, it's not different than overflow when multiplying C integers. So I don't really consider it a bug. It is something which could be dealt with by the overflowcheck directive. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] All DEF constants are now unsigned?
Hello Cython-devel, I noticed that now unsigned constants like DEF foo = 1 become 1U in the C source code. This change (i.e. commit ea6414cd293ba2134c3df5b37b158d8e3db79083) broke Sage. I haven't managed yet to actually isolate why this change broke something. Was this change of 1 to 1U intentional? Why was it done? Jeroen. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] All DEF constants are now unsigned?
This is a bug: DEF myconst = 1 def foo(): cdef long x = -myconst return x This returns 4294967295. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] All DEF constants are now unsigned?
Jeroen Demeyer schrieb am 05.09.2015 um 12:17: > I noticed that now unsigned constants like > > DEF foo = 1 > > become 1U in the C source code. > > This change (i.e. commit ea6414cd293ba2134c3df5b37b158d8e3db79083) broke > Sage. I haven't managed yet to actually isolate why this change broke > something. > > Was this change of 1 to 1U intentional? Why was it done? Pretty much intentional, yes. I changed it in response to this bug report: http://thread.gmane.org/gmane.comp.python.cython.devel/15774 The problem with DEF constants is that they are Python values that use Python semantics in expressions before they eventually get converted back into literals and inserted into the AST. Specifically, they loose any literals semantics that they initially had in the source code, including any information about literal C integer types that contributed to their value, as in this case. Thus, there isn't really a 'correct' way to write them out as literals and C might be happy with what we output, or not. I guess it might be better to undo this part of the change. Unsigned literals are usually not the right way to do it in C, definitely not for everything. We could then maybe apply the usual 32/64 bits heuristic to add at least L/LL suffixes at need. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] All DEF constants are now unsigned?
Stefan Behnel schrieb am 05.09.2015 um 16:01: > Jeroen Demeyer schrieb am 05.09.2015 um 12:17: >> I noticed that now unsigned constants like >> >> DEF foo = 1 >> >> become 1U in the C source code. >> >> This change (i.e. commit ea6414cd293ba2134c3df5b37b158d8e3db79083) broke >> Sage. I haven't managed yet to actually isolate why this change broke >> something. >> >> Was this change of 1 to 1U intentional? Why was it done? > > Pretty much intentional, yes. I changed it in response to this bug report: > > http://thread.gmane.org/gmane.comp.python.cython.devel/15774 > > The problem with DEF constants is that they are Python values that use > Python semantics in expressions before they eventually get converted back > into literals and inserted into the AST. Specifically, they loose any > literals semantics that they initially had in the source code, including > any information about literal C integer types that contributed to their > value, as in this case. Thus, there isn't really a 'correct' way to write > them out as literals and C might be happy with what we output, or not. > > I guess it might be better to undo this part of the change. Unsigned > literals are usually not the right way to do it in C, definitely not for > everything. We could then maybe apply the usual 32/64 bits heuristic to add > at least L/LL suffixes at need. Does this look better? https://github.com/cython/cython/commit/2ac9ffbab1e868137bf33bf025eb7a5c7e4707ce It now appends the 'U' suffix only to literals that are used in an unsigned context (e.g. assignment to unsigned variable), and additionally appends L/LL suffixes for integers that might exceed the int/long limits. That's just guessing, but it should generally improve the current handling of literals and DEF expressions. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] call for contribution: PEP 498 - Literal String Interpolation
Hi! It looks like PEP 498 (f-strings) is going to be accepted soon. Anyone interested in implementing it for Cython? https://www.python.org/dev/peps/pep-0498/ It's certainly a bit of work, but it's also very much Python-level functionality and most of it can be handled in the parser, so I would count it as an entry-level project for working on Cython. There is already an initial implementation for CPython (in C) which should provide an answer to the tricky details of the functionality itself, as well as tests for it (eventually). https://bugs.python.org/issue24965 So, if this feature, and if extending the Cython language and working on a real compiler sounds tempting to you, please speak up on the cython-devel mailing list. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
