Re: [Cython] Dash in the executable's filename
On Sun, Apr 26, 2015 at 11:16 AM, Stefan Behnel wrote:
> Robert Bradshaw schrieb am 24.04.2015 um 10:31:
>> On Thu, Apr 23, 2015 at 2:22 AM, Anton D. Kachalov wrote:
>>> I've found that executable script with dashes in the filename lead to
>>> produce wrong cythonized source:
>>>
>>>$ touch my-great-script.py
>>>$ cython my-great-script.py --embed
>>>$ fgrep PyInit my-great-script.c
>>> PyMODINIT_FUNC PyInit_my-great-script(void); /*proto*/
>>> PyMODINIT_FUNC PyInit_my-great-script(void)
>>> __Pyx_RefNannySetupContext("PyMODINIT_FUNC PyInit_my-great-script(void)",
>>> 0);
>>> m = PyInit_my-great-script();
>>>
>>> So, if I don't want to import my final script elsewhere, I'm free to choose
>>> any filename for it.
>>
>> Good point:
>> https://github.com/cython/cython/commit/e0fd2b3c8265ea40084ee9981d8601bc6e11b97e
>
> This change prevents finding the external .pxd file for the module. I
> noticed this by pure luck when several of the Cython optimised benchmarks
> in Demos/benchmarks/ suddenly dropped substantially in performance.
>
> https://sage.math.washington.edu:8091/hudson/view/bench/job/cython-devel-cybenchmarks-py3k/1400/artifact/bench_chart.html
>
> The build job compiles them as Python-embedded programs.
Arguably that's still correct behavior, similarly to how one can do
"import foo" when executing "python foo.py" and it's a new module.
However, I've undone this change for now (though "cython
my-great-script.py --embed" is now an error rather than produce bad C
code).
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
[Cython] New hosting
Since Cython's inception, we've been able to take advantage of William Stein's and University of Washington's infrastructure for hosting the Cython project along side that of Sage. However, due to UW policy, those days are coming to and end. Maybe it's time--Cython has come a long way from its birth of SageX + lxml. So the question is where to move. Our primary needs are not that large: we've got a site, a bugtracker (trac), and a continuous build (jenkins) currently being served (the source code and wiki have already been migrated to github). I would propose that we look into moving everything we can over to github. For starters, they now offer serving simple sites from a repository (cython.org) so that seems an obvious choice. I know their bug tracking v1 was considered far inferior to trac, but the situation may be better now (at least worth exploring). We also have travis.ci, which isn't as configurable as jenkins, but may be good enough. (The biggest deficiency is that it probably wouldn't allow for building and testing Sage regularly, or benchmarks, this is the one thing that we may need to find/provide custom hosting for.) Thoughts? ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] New hosting
Robert Bradshaw schrieb am 27.04.2015 um 20:15: > We also have travis.ci, > which isn't as configurable as jenkins, but may be good enough. (The > biggest deficiency is that it probably wouldn't allow for building and > testing Sage regularly, or benchmarks, this is the one thing that we > may need to find/provide custom hosting for.) ... and it won't easily allow us to track the CPython development branches and build against them. A really neat feature of our Jenkins server was that it could nicely store away pre-built artefacts for later reuse on the same machine, such as a series of CPython branch builds, and just happily rebuilt them regularly on external changes. That totally helped spotting integration problems as early as possible, including bugs on both sides. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] New hosting
Hi, On Mon, Apr 27, 2015 at 11:56 AM, Stefan Behnel wrote: > Robert Bradshaw schrieb am 27.04.2015 um 20:15: >> We also have travis.ci, >> which isn't as configurable as jenkins, but may be good enough. (The >> biggest deficiency is that it probably wouldn't allow for building and >> testing Sage regularly, or benchmarks, this is the one thing that we >> may need to find/provide custom hosting for.) > > ... and it won't easily allow us to track the CPython development branches > and build against them. A really neat feature of our Jenkins server was > that it could nicely store away pre-built artefacts for later reuse on the > same machine, such as a series of CPython branch builds, and just happily > rebuilt them regularly on external changes. That totally helped spotting > integration problems as early as possible, including bugs on both sides. Some of us use scikit-learn's rackspace account for that. I'm sure if you ask Olivier Grisel nicely, from scikit-learn - he'd let you use it too. We use travic-ci encrypted tokens to push artefacts like wheels up to the rackspace CDN, and then pull them down again for testing. Can point you to relevant stuff if you are interested... Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] New hosting
On Mon, Apr 27, 2015 at 1:59 PM, Matthew Brett wrote: > Hi, > > On Mon, Apr 27, 2015 at 11:56 AM, Stefan Behnel wrote: >> Robert Bradshaw schrieb am 27.04.2015 um 20:15: >>> We also have travis.ci, >>> which isn't as configurable as jenkins, but may be good enough. (The >>> biggest deficiency is that it probably wouldn't allow for building and >>> testing Sage regularly, or benchmarks, this is the one thing that we >>> may need to find/provide custom hosting for.) >> >> ... and it won't easily allow us to track the CPython development branches >> and build against them. A really neat feature of our Jenkins server was >> that it could nicely store away pre-built artefacts for later reuse on the >> same machine, such as a series of CPython branch builds, and just happily >> rebuilt them regularly on external changes. That totally helped spotting >> integration problems as early as possible, including bugs on both sides. That's a good point. > Some of us use scikit-learn's rackspace account for that. I'm sure if > you ask Olivier Grisel nicely, from scikit-learn - he'd let you use it > too. > > We use travic-ci encrypted tokens to push artefacts like wheels up to > the rackspace CDN, and then pull them down again for testing. > > Can point you to relevant stuff if you are interested... If we go down this route, for sure. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
