On 2017-09-08 14:55, Simon King wrote:
sage: cython("""
: #!clib gap
: from sage.libs.gap.gap_includes cimport *
: from sage.libs.gap.element cimport GapElement_FiniteField
: from sage.libs.gap.libgap import libgap
: def test(x):
: libgap_enter()
: cdef GapElem
On 2017-09-08, Simon King wrote:
> Hi Vincent,
>
> On 2017-09-08, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
>> In the above code you are *not* calling the C API. Just avoid the
>> libgap_enter / libgap_exit.
>
> I know. But part of my question was whether it is safe to have
> python ca
Hi Vincent,
On 2017-09-08, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> In the above code you are *not* calling the C API. Just avoid the
> libgap_enter / libgap_exit.
I know. But part of my question was whether it is safe to have
python calls inside a libgap_enter/exit pair. Apparentl
On 08/09/2017 08:55, Simon King wrote:
On 2017-09-08, Simon King wrote:
When I do libgap_enter() and then
cdef GapElement_FiniteField zero = libgap(F.zero())
(where F=GF(2)), I get a crash. I am about to test whether I can make
up a minimal example from it.
Voilà :
sage: cython("""
...
On 2017-09-08, Simon King wrote:
> When I do libgap_enter() and then
>cdef GapElement_FiniteField zero = libgap(F.zero())
> (where F=GF(2)), I get a crash. I am about to test whether I can make
> up a minimal example from it.
Voilà :
sage: cython("""
: #!clib gap
: from sage.libs.gap
On 2017-09-07, Simon King wrote:
> I expected a crash when *not* using libgap_enter/exit. But actually I am
> getting the crash when I *do* use it. I see the message
> sig_error() without sig_on()
> followed by a lng gdb backtrace.
>
> So, does one need sig_on()/sig_off() in addition to l
On Friday, September 8, 2017 at 6:00:31 AM UTC+2, Nils Bruin wrote:
>
> On Thursday, September 7, 2017 at 9:49:33 AM UTC-7, Volker Braun wrote:
>>
>> First question: The GAP garbage collector might delete objects, or it
>> might move existing objects around in memory (it is a compacting garbage
>
On Thursday, September 7, 2017 at 9:49:33 AM UTC-7, Volker Braun wrote:
>
> First question: The GAP garbage collector might delete objects, or it
> might move existing objects around in memory (it is a compacting garbage
> collector). If your code contains C pointers to GAP objects, bad things
>
Hi Vincent,
On 2017-09-07, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> I believe that GAP should also be initialized before calling any
> non-trivial function using the stack. How do you initalize it? (the call
> "import sage.libs.gap.libgap should do the job).
I do
from sage.libs
Hi!
On 2017-09-07, Simon King wrote:
> On 2017-09-07, Volker Braun wrote:
>> Second question: Move the libgap_enter/exit outside of the loop, assuming
>> that the python functions don't themselves call libgap. If they do, you
>> will get a "RuntimeError: Entered a critical block twice". In th
Hi Volker,
On 2017-09-07, Volker Braun wrote:
> First question: The GAP garbage collector might delete objects, or it might
> move existing objects around in memory (it is a compacting garbage
> collector). If your code contains C pointers to GAP objects, bad things
> will happen after that.
On 07/09/2017 18:04, Simon King wrote:
Hi Dima,
On 2017-09-07, Dima Pasechnik wrote:
I don't think anything special like libgap_enter/exit is needed when
calling libgap.* stuff from
Python or Cython.
The documentation in sage.libs.gap.libgap says:
"""
In particular, you must call ``libgap_m
Hi Volker,
On 2017-09-07, Volker Braun wrote:
> For the record, using the libgap Python interface (i.e. from
> sage.libs.gap.libgap import libgap) automatically takes care of the
> libgap_enter/exit business. This is only an issue if you want to the libGAP
> C API directly, which is what Simon
Hi Dima,
On 2017-09-07, Dima Pasechnik wrote:
> I don't think anything special like libgap_enter/exit is needed when
> calling libgap.* stuff from
> Python or Cython.
The documentation in sage.libs.gap.libgap says:
"""
In particular, you must call ``libgap_mark_stack_bottom()`` in every
functi
The change will mostly be to remove the libGAP_ prefix for symbols, so it
should be pretty easy to sed that out (or use a macro to be compatible with
both).
On Thursday, September 7, 2017 at 7:45:04 PM UTC+2, Dima Pasechnik wrote:
>
> I would not touch C API to libGAP with a stick, given that i
I would not touch C API to libGAP with a stick, given that it might get changed
by GAP people soon, I guess.
https://github.com/gap-system/gap/pull/1205
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop recei
For the record, using the libgap Python interface (i.e. from
sage.libs.gap.libgap import libgap) automatically takes care of the
libgap_enter/exit business. This is only an issue if you want to the libGAP
C API directly, which is what Simon is presumably asking.
On Thursday, September 7, 2017 a
First question: The GAP garbage collector might delete objects, or it might
move existing objects around in memory (it is a compacting garbage
collector). If your code contains C pointers to GAP objects, bad things
will happen after that. Not every libGAP_* function can invoke the garbage
colle
On Thursday, September 7, 2017 at 7:01:47 AM UTC-7, Dima Pasechnik wrote:
>
> Hi Simon,
>
> I don't think anything special like libgap_enter/exit is needed when
> calling libgap.* stuff from
> Python or Cython.
> We do quite a few libgap calls in graphs/strongly_regular_db.pyx
> and in graphs/gen
Hi Simon,
I don't think anything special like libgap_enter/exit is needed when
calling libgap.* stuff from
Python or Cython.
We do quite a few libgap calls in graphs/strongly_regular_db.pyx
and in graphs/generators/classical_geometries.py
so this all seems to work just fine.
Do you mean somethi
20 matches
Mail list logo
