That sounds risky; I think we should consider master as non-rebaseable except in emergencies. So fixes should be pushed to release and then merged into master. Of course, for something like this with no development depending on it one can just delay the merge for a day or two in case more fixes show up. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. mark florisson <markflorisson88@gmail.com> wrote: On 31 July 2011 21:49, mark florisson <markflorisson88@gmail.com> wrote: > 2011/7/31 Vitja Makarov <vitja.makarov@gmail.com>: >> I've tried openmp support with simple example: >> >> from cython.parallel cimport prange >> >> def mul(values): >> ret = 1 >> for i in prange(values): >> ret *= i >> return ret >> >> And cython crashes: >> >> ((b04e040...)) vitja@vitja-laptop:~/work/cython-vitek/zzz$ make mul.so >> /usr//bin/python ../cython.py --gdb -v mul.pyx -o mul.c >> Compiling /home/vitja/work/cython-vitek/zzz/mul.pyx >> >> Error compiling Cython file: >>_____________________________________________

...

... >> from cython.parallel cimport prange >> >> def mul(values): >> ret = 1 >> for i in prange(values): >> ^ >>_____________________________________________

...

...

mul.pyx:5:26: stop argument must be numeric or a pointer (perhaps if a >> numeric literal is too big, use 1000LL) >> >> Error compiling Cython file: >>_____________________________________________ ... >> from cython.parallel cimport prange >> >> def mul(values): >> ret = 1 >> for i in prange(values): >> ^ >>_____________________________________________ mul.pyx:5:19: Compiler crash in AnalyseExpressionsTransform >> >> ModuleNode.body = StatListNode(mul.pyx:1:0) >> StatListNode.stats[0] = DefNode(mul.pyx:3:0, >> modifiers = [...]/0, >> name = u'mul', >> num_required_args = 1, >> reqd_kw_flags_cname = '0', >> used = True) >> File 'Nodes.py', line 337, in analyse_expressions: StatListNode(mul.pyx:4:4, >> is_terminator = True) >> File 'Nodes.py', line 6553, in analyse_expressions: >> ParallelRangeNode(mul.pyx:5:19, >> assigned_nodes = [...]/1, >> is_parallel = True, >> is_prange = True, >> valid_keyword_arguments = [...]/3) >> >> Compiler crash traceback from this point on: >> File "/home/vitja/work/cython-vitek/Cython/Compiler/Nodes.py", line >> 6553, in analyse_expressions >> self.index_type, node.type) >> File "/home/vitja/work/cython-vitek/Cython/Compiler/PyrexTypes.py", >> line 2624, in widest_numeric_type >> elif type1.rank < type2.rank: >> AttributeError: 'PyObjectType' object has no attribute 'rank' >> make: *** [mul.c] Ошибка 1 >> rm mul.c >> ((b04e040...)) vitja@vitja-laptop:~/work/cython-vitek/zzz$ >> >> >> >> -- >> vitja. >>_____________________________________________ cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> > > Thanks for the report, I pushed a fix: > https://github.com/cython/cython/commit/e9f9fde70d5d96f418244a0640a63a966a24... > . Seems like I forgot an error test for that. > I pushed it to release, should I rebase master on release now?_____________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel

On 1 August 2011 08:48, Stefan Behnel <stefan_ml@behnel.de> wrote:

mark florisson, 31.07.2011 22:08:

...

I pushed it to release, should I rebase master on release now?

Well, so far, the release branch hasn't been used and rc1 was created from master. All current changes in master are either considered safe (by me :) or just fixes that should go into the release. So I think it's best to just rebase your single commit in the current release branch back on the master, delete the release branch and recreate it from the tip of the master branch.

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

Ok, thanks Dag and Stefan, I suspected the danger, but if Stefan's changes are to go in I'll just do as Stefan suggested.

Robert Bradshaw, 02.08.2011 02:42:

In general, if we have a distinct release branch (e.g if anything really interesting had gone in since the last rc), I'd say we should push release fixes to that and then merge into master.

+1 Stefan