+1 for having it inside https://github.com/sagemath

I think it is desirable to have the possibility to enable or disable
cysignals manually. In other words
  enable + "no cysignals present" -> error
  enable + "cysignals present" -> compilation with sigs
  disable + "whatever" -> compilation without sigs

I thought cysignals would be Windows compatible after

https://github.com/sagemath/cysignals/pull/104

Though the project seems to be abandoned. What a shame.

Vincent

Le 29/03/2021 à 15:06, 'jonatha...@googlemail.com' via sage-devel a écrit :
https://github.com/kliem/memory_allocator

I started MemoryAllocator as a seperate project. I think it is almost ready
to push to PyPI. Any opinions? Do I need permission to publish it like
this? Should this be moved into a different repository? (E.g.
https://github.com/sagemath/memory_allocator).

It symlinks `cysignals/src/cysignals/memory.pxd`. Thus it only depends on
`sig_block`/`sig_unblock` from cysignals. This will be used, if cysignals
is found at time of setup. Otherwise, `sig_block`/`sig_unblock` will be
replaced by functions doing nothing. Using `sig_block`/`sig_unblock` only
seems to make sense, if you have cysignals anyway.

Disadvantage of this approach is of course, that you need to make sure that
you install cysignals before memory_allocator manually.

jonatha...@googlemail.com schrieb am Donnerstag, 11. März 2021 um 10:33:35
UTC+1:

This approach might not be pretty, but it seems to work fine.

I can use cysignals on cygwin, linux, mac and not use it on windows
without cygwin.

However, it would be much nicer to allow pip installing cysignals on
windows without cygwin in the first place. This would simplify this a lot.

jonatha...@googlemail.com schrieb am Mittwoch, 10. März 2021 um 17:44:05
UTC+1:

Here is my project (I just made the repository public):
https://github.com/kliem/PyKPartiteKClique/tree/main/

The source folder is kpkc

As you can see, I completely copied memory_allocator*

This should be moved to its own project eventually.

Instead of cimporting directly from cysignals (which may fail, if not
present), I cimport from kpkc.cysignals

There are two files for this. kpkc/cysignals.pyx which is a plain
wrapper about the cysignals functions (just cimporting did not work).

If cysignals is not present, I instead compile kpkc/cysignals_backup.pyx
as module kpkc.cysignals.

Of course, you need to reinstall the project, if you install cysignals
afterwards.

On 10.03.21 16:07, E. Madison Bray wrote:
On Wed, Mar 10, 2021 at 3:51 PM 'Jonathan Kliem' via sage-devel
<sage-...@googlegroups.com> wrote:
What I'm struggling with is the following:

How do I cimport from different sources (runtime dependent probably
won't work, but compile time dependent would already be nice). At the
moment my package just pulls in cysignals during pip install and if
this
does not work it replaces those functions by standard allocation
functions.

Is there a better solution to do this?
What do you mean by "cimport from different sources"? If you are
already working on this could you link to the source?

If this is about my idea to make the memory allocation functions
"pluggable" that would be done by setting some function pointers to
them, which would be done by third-party Cython code using
MemoryAllocator (there would need to be a C method for setting them).

On 10.03.21 15:27, E. Madison Bray wrote:
On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe
<matthia...@gmail.com> wrote:
On Friday, February 12, 2021 at 2:35:45 PM UTC-8 vdelecroix wrote:
Why make it part of cysignals? The purpose of the memory allocator
is quite distinct from cysignals. Merging them look artificial to
me.
Really? MemoryAllocator is just a wrapper class around
cysignals.memory
Was there ever any action on this? MemoryAllocator does seem like a
useful thing to have as an independent package. It's basically a more
sophisticated version of the SomeMemory recipe given in the Cython
docs:
https://cython.readthedocs.io/en/latest/src/tutorial/memory_allocation.html

I agree that it's distinct from cysignals. It doesn't necessarily
have to depend on cysignals, and could have a hook interface to allow
different memory allocation functions. It just happens to use the
ones from cysignals since Sage already uses cysignals, and its memory
functions have the advantage of being interrupt-safe.

I would continue using cysignals by default for an initial
implementation, but if anyone had a need for it, it would be possible
to make this work with cysignals as an optional dependency as well.

--
You received this message because you are subscribed to the Google
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/58a5c332-7331-8433-941e-b73f7090d608%40gmail.com.





--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2d7f6a4e-59cf-5c25-4cc3-ae55280d09e6%40gmail.com.

Reply via email to