Subject: Re: [Cython-dev] Callbacks from threads and PyGILState_Ensure/PyGILState_Release - msg#00100

Previous Message by Date: click to view message preview

Re: [Cython-dev] Licence of output

William Stein wrote: > I think you should be able to put the output under any license > you choose, just like you can with the output of GCC, > Emacs, Microsoft Word (??), etc. Does Greg or Stefan or Robert > Bradshaw think any differently? As far as I'm concerned, any output that Pyrex generates from your source is yours to do with as you wish. -- Greg

Next Message by Date: click to view message preview

newbie question: error using pyrex

Hi, I'm a first time user of pyrex and tried to translate that piece of code using pyrex: cdef extern from "math.h" def pofr(vectors): distances = list() cdef int n n = len(vectors) for i from 0 <= i < n: for j from i+1 <= j < n: a = vector[i] b = vector[j] dist = sqrt((a[0]-b[0]) * (a[0]-b[0]) + (a[1]-b[1]) * (a[1]-b[1]) + (a[2]-b[2]) * (a[2]-b[2])) distances.append(dist) return distances running 'pyrexc pofr_module.pyx' results in this error message: /home/cm/bin/mc_rigid_dir/src/pofr_module.pyx:1:25: Expected ':' I'm using Ubuntu's 0.9.4.1-2ubunut1 package of pyrex, for it matters. Can anybody give me a hint on what my mistake is? TIA Christian

Previous Message by Thread: click to view message preview

Re: [Cython-dev] Callbacks from threads and PyGILState_Ensure/PyGILState_Release

Stefan Behnel wrote: > Greg uses words like "triggers the generation of code to acquire the > GIL if necessary around the body." The "if" is futile. It will always have to > do that, as it can't know who calls the function in what context. The nogil signature is what tells Pyrex about the calling context. If that signature is present in the function's declaration, Pyrex knows that it can't assume the GIL is held. So, if any Python operations are performed within the function body, the GIL needs to be acquired. For this purpose, "performing a Python operation" includes calling any function that hasn't been declared with a nogil signature. Pyrex has to assume that such a function could perform Python operations, and needs the GIL. > Pyrex must still figure > out if it needs to acquire the GIL or not. We're fighting Turing here. No, we're not. If we were trying to figure out *exactly* when the GIL was needed and when it wasn't, under all conditions, with no help from the programmer, then we would be fighting Turing. But we're taking a conservative approach by assuming the GIL is needed unless we can prove that it isn't, and relying on declarations to fill in Pyrex's gaps in knowledge. Declarations are needed in certain key places. Then Pyrex checks that everything else is consistent with those declarations. -- Greg

Next Message by Thread: click to view message preview

Re: [Cython-dev] Callbacks from threads and PyGILState_Ensure/PyGILState_Release

Stefan Behnel wrote: > it's > actually two things you were trying to catch with the "nogil" annotation: > > - "this can safely execute without the GIL", which Pyrex can verify and even > figure out based on function bodies, but which it needs to be told for > external functions That's correct. > > and the second being > > - "this *will* be executed without the GIL", I wouldn't describe it quite that way. When you use 'nogil' on the *implementation* of a function, you're asserting "This function *must* be callable without the GIL". It's then up to Pyrex to do whatever is necessary to make that true. A fully smart implementation would analyse the body to determine whether the GIL needed to be acquired, based on the nogil status of the things it calls. A completely naive implementation would always acquire the GIL, just in case, although that might be inconvenient, as then you wouldn't be able to write pure-C non-GIL-using functions in Pyrex. A middle ground would be to provide another annotation somehow to tell Pyrex to acquire the GIL, such as cdef void myfunc() acquires GIL: ... where 'acquires GIL' would also imply 'nogil'. Another way would be to write cdef void myfunc() nogil: with GIL: ... and have Pyrex recognise 'with GIL' at the top level of the body as a special case and generate GIL-acquiring code around everything. I'm leaning towards this, because it would avoid introducing a notation that would become obsolete later with a smarter implementation. -- Greg which Pyrex cannot know and has > to be told to acquire the GIL if necessary. > > I'm not sure the two fit into one keyword. > > Maybe a "nopython" annotation for external functions and a smarter Pyrex would > fit the first, while a "nogil" function annotation would match the second? > > Stefan >