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/82e9d9f8-6b90-4898-be87-3fa323d7b7c4n%40googlegroups.com.
