date:20210310

> On 11/03/2021, at 05:03, Matthias Koeppe  wrote:
> 
> On Wednesday, March 10, 2021 at 1:21:07 AM UTC-8 François Bissey wrote:
> [...] building the documentation [...] 
> 
> In https://trac.sagemath.org/ticket/29868 I sketch a design that is in line 
> with modern Python packaging, in particular build isolation. I welcome 
> discussions based on this.

build isolation is nice. If python packaging says that what numpy does 
and sage is about to do is right, they are completely diverging from
traditional packaging. May be packagers have been wrong all along.

In a way, it mimics the way commercial closed packages tend to behave and
be distributed. And I don’t like that imitation one bit. It rubs me the
wrong way. Reading myself, I hope I am not turning into a “Richard Stallman”
but I am certainly opinionated and not afraid of it.

François

-- 
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/AAEDB4E9-745F-4290-85F4-F27059475138%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation




> On 11/03/2021, at 01:10, Antonio Rojas  wrote:
> 
> El miércoles, 10 de marzo de 2021 a las 10:21:07 UTC+1, François Bissey 
> escribió:
> Instead of trying to fix the problem that you should be building the 
> documentation 
> before installing, the push to modularisation is currently used to enshrine 
> the 
> current situation. #30010 actually separate the bits needed to build the sage 
> documentation in a completely separate package. 
> So the situation is now: 
> * install package A 
> * install package B 
> * make a package C that takes B and applies it to the install of A and 
> install 
> the documentation of A (not C). 
> 
> 
> Hi,
>  As long as everything is still shipped in the Sage source tarball, isn't it 
> just a matter of changing a path in the build script? I've always run the doc 
> build directly from the Sage source, without installing anything, and I hope 
> to be able to keep doing it that way (after a quick test, it still seems to 
> be possible after #30010). Of course, if the long term plan is to split this 
> to a separate git repo, then I completely share your concerns. 
> 

I’d like to talk to you on another channel, I have to do a small
patch currently. It may reflect different packaging strategy or
something I could improve.

François

-- 
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/C2A6536C-BCA9-4B7E-82C8-0D427886BF19%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation




> On 10/03/2021, at 23:50, Dima Pasechnik  wrote:
> 
> On Wed, 10 Mar 2021, 09:21 François Bissey,  wrote:
> So the situation is now:
> * install package A
> * install package B
> * make a package C that takes B and applies it to the install of A and install
> the documentation of A (not C).
> 
> Can anyone point me to some other system that do that? Does anyone else 
> thinks 
> that’s a bit insane?
> 
> numpy does this:
> https://numpy.org/devdocs/docs/howto_build_docs.html
> 
> you can only build numpy docs after numpy is installed.
> 

And Gentoo doesn’t even try to build the doc we use their provided tarball.

As far as I see it, the way sage sage is going I won’t build or test the 
documentation
anymore and rely on you producing tarballs. Which means there won’t be version 
bump
of sage in Gentoo until those exists when that happens.

François

-- 
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/7BC141F4-4A95-4624-B538-8C48FEC3F1D7%40gmail.com.

[sage-devel] Re: distro packaging, docbuilding and modularisation

On Wednesday, March 10, 2021 at 4:10:19 AM UTC-8 Antonio Rojas wrote:

>  As long as everything is still shipped in the Sage source tarball, isn't 
> it just a matter of changing a path in the build script?
>

That's right. As far as changes in src/ are concerned, what #30010 did was 
move src/sage_setup/setup_docbuild to src/sage_docbuild.
The renamed modules sage_docbuild.* can just be imported without installing 
anything.

In fact, this is a key design principle of the modularization approach of 
https://trac.sagemath.org/ticket/29705: The overall structure of the src 
tree is not changed. If you want to ignore questions of Python packaging, 
you can and just look at src/ as a monolithic source tree containing the 
top-level package directories sage, sage_setup, sage_docbuild.

I've always run the doc build directly from the Sage source, without 
> installing anything, and I hope to be able to keep doing it that way (after 
> a quick test, it still seems to be possible after #30010).
>

Absolutely.

-- 
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/816bfdf1-b1e8-4633-98b6-39d83f854d82n%40googlegroups.com.

[sage-devel] Re: distro packaging, docbuilding and modularisation

On Wednesday, March 10, 2021 at 1:21:07 AM UTC-8 François Bissey wrote:

> Sagemath as a meta distribution of stuff has bad habits in regards to 
> treating “sagelib” as a regular package. In short it doesn’t. 
>

That's no longer true.

sagelib is now a regular Python distribution called "sagemath-standard".
An sdist can be built using the script build/pkgs/sagelib/spkg-src
(in fact, the sdist is already available at 
https://pypi.org/project/sagemath-standard/)

(As of 9.3.beta8, it is still missing Python dependency metadata. This is 
rectified by https://trac.sagemath.org/ticket/30913, which is waiting for 
review...)

You can update your downstream distribution packaging so it installs 
sagelib like any other Python package.

-- 
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/9d2bc845-d7f2-46b3-a948-8361d394a0acn%40googlegroups.com.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

2021-03-10 Thread 'Jonathan Kliem' via sage-devel

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
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
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+unsubscr...@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.

Re: [sage-devel] Sage on Windows

With apologies for replying to such an old message, I should just note that
I fixed this in the most recent Sage Windows release:
https://github.com/sagemath/sage-windows/releases/tag/0.6.2-9.2

On Wed, Dec 16, 2020 at 8:29 PM Matthias Koeppe 
wrote:

> This looks like https://trac.sagemath.org/ticket/29537
> "cygwin-standard: build not portable despite using SAGE_FAT_BINARY=yes,
> NTL-related"
>
> On Wednesday, December 16, 2020 at 8:24:02 AM UTC-8 Jan Groenewald wrote:
>
>> Correct output will follow when she figures out how to run coreinfo -- it
>> just opens a terminal and closes quickly.
>> That is not the right output.
>>
>> On Wed, 16 Dec 2020 at 16:30, Dima Pasechnik  wrote:
>>
>>> Jan mentioned Celeron N3060, but this is Xeon W3520, a rather different
>>> CPU.
>>>
>>> On Wed, Dec 16, 2020 at 1:07 PM Malala Rakotondrasoa 
>>> wrote:
>>>
 Hi! This is the output after I run coreinfo

 On Wednesday, December 16, 2020 at 2:59:14 PM UTC+3 dim...@gmail.com
 wrote:

> On Wed, Dec 16, 2020 at 11:36 AM Jan Groenewald 
> wrote:
>
>> Hi
>>
>> On Wed, 16 Dec 2020 at 11:26, Dima Pasechnik 
>> wrote:
>>
>>> it looks as if the hardware does not understand a command.
>>> Ask them about the CPU type of the machine.
>>>
>>
>> Intel Celeron N3060 1.6GHZ
>>
>
> that's one of these low-end CPUs from 2016 that are reported to have
> this kind of issue.
> Can you ask them to download and run coreinfo utility from
>
> https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo
>
> without parameters - and post the output here.
>
> E.g. one possibility is that popcnt instruction is not supported.
>
>
>
>> 4GB RAM
>> 64bit Windows 10 version 1803
>>
>> Regards,
>> Jan
>>
>>
>>
>>
>>
>>>
>>> On Wed, Dec 16, 2020 at 9:22 AM Jan Groenewald 
>>> wrote:
>>>
 Hi

 I have a student who is in another country, with Windows 10, whom I
 sent this link to install sage:

 https://sagemath.mirror.ac.za/win/SageMath-9.2-Installer-v0.6.1.exe

 She has these errors on any computation:

 [image: saegmath-jupyter.jpeg]
 Google translate says:
 Kernel being restarted
 The kernel seems to crash It will restart automatically

 and the terminal screenshot:
 [image: windows-kernel.jpeg]
 I can probably get teamviewer access to investigate further but I
 am not familiar with windows or sage on windows.

 Any ideas?

 Regards,
 Jan


 --
   .~.
   /V\ Jan Groenewald
  /( )\www.aims.ac.za
  ^^-^^

 --
 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/CAAg%3Dp_0w7RtW7%3DDSoYREpqa-y1YnLS3CkKEAqe3vH-MvL%3DmzfQ%40mail.gmail.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+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/CAAWYfq318FzwkfMgv5NYH%3DJouMV1dcjsJawj4Y-rturnSOEx5Q%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>>   .~.
>>   /V\ Jan Groenewald
>>  /( )\www.aims.ac.za
>>  ^^-^^
>>
>> --
>> 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/CAAg%3Dp_1zkbRbv%2BSWVFks0t5ru-iob8uUqhVb4-dNCLtvxv8swQ%40mail.gmail.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] Re: distro packaging, docbuilding and modularisation

On Wednesday, March 10, 2021 at 4:10:19 AM UTC-8 Antonio Rojas wrote:

>  Of course, if the long term plan is to split this to a separate git repo, 
> then I completely share your concerns. 
>

No, the plan for modularization does not involve splitting the repository. 
See https://trac.sagemath.org/ticket/29705 for an overview.

 

-- 
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/ec6b1fac-9265-4afa-a890-a5571adf08f4n%40googlegroups.com.

[sage-devel] Re: distro packaging, docbuilding and modularisation

On Wednesday, March 10, 2021 at 1:21:07 AM UTC-8 François Bissey wrote:

> [...] building the documentation [...] 


In https://trac.sagemath.org/ticket/29868 I sketch a design that is in line 
with modern Python packaging, in particular build isolation. I welcome 
discussions based on this.




-- 
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/2fa76717-5b5f-4d71-a154-4ed22fb381c4n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!]

On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de  wrote:
>
>
> For what's worth, + 1 for migrating to github.
>
> The interface is cleaner, it has many more features and integrations, and is 
> more active which could attract more contributions. There are a few 
> scripts/tools that allow to migrate from trac to github. But most of them are 
> unmaintained for a few years already, so I'm not sure if they still work 
> (which should be taken as a sign that one should migrate sooner than later).

In 2019 Julian Rüth and I, with the help of some others, already put
in some effort to set up an organization for SageMath on GitLab:
https://gitlab.com/sagemath

Between GitHub and GitLab, we felt that the latter would be more
acceptable to the broader Sage community.  We also implemented a bot
that can mirror GitLab merge requests as Trac tickets, though it's
been in need of troubleshooting for a while.

This was also done before the advent of GitHub Actions, and the
ability to provide custom CI runners for GitLab Pipelines seemed
advantageous, since we could maintain our own fleet of runners, be it
on Sage developers' personal machines (if they are generous enough to
host them) or any conceivable constellation of cloud computing
platforms.

In practice this has gained little traction, in part due to lack of
advertising.  The GitLab Runner solution also proved a bit troublesome
to maintain, as it required some constant attention to make sure there
were always working runners available.   I tried to keep that up for a
while myself, but have had other obligations.

In the meantime Matthias and others have been doing really interesting
things with GitHub Actions for our CI.  For the time being GitHub is
being *very* generous with computing time available to open source
projects.  Though I fear it's only a matter of time before Microsoft's
investors come banging on the door, and they start putting in bigger
limits for free users (as happened with Travis CI).

I would still prefer the GitLab approach for a myriad of reasons, or a
hybrid approach at least for the GitHub Actions stuff.  It just needs
to be better advertised, and there needs to be better instructions for
where users and potential developers should go to open issues.

As for the wiki I've always been in favor of dropping Moin Wiki and
migrating the existing wiki pages to Trac (or to GitLab).  Someone
just has to do it, as is always the problem.

> On Thursday, January 7, 2021 at 9:50:49 PM UTC+1 David Roe wrote:
>>
>> On Thu, Jan 7, 2021 at 3:49 PM Isuru Fernando  wrote:
>>>
>>> It should be sagemath.zulipchat.com right? (Instead of .org)
>>
>>
>> Yes, sorry for the typo!
>> David
>>
>>>
>>> Isuru
>>>
>>> On Thu, Jan 7, 2021 at 2:47 PM David Roe  wrote:

 On Thu, Jan 7, 2021 at 3:30 PM Harald Schilly  wrote:
>
> On Thu, Jan 7, 2021 at 9:23 PM Dima Pasechnik  wrote:
> > Harald - can you take care of this?
> >
>
> Uhm, what's happening? Could someone please summarize this for me?

 zulip.sagemath.org used to point to a google virtual machine.  We'd like 
 it to redirect to sagemath.zulipchat.org so that people looking for the 
 Zulip server are sent to the right place.
 David

>
>
> --
> 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/CAGG4CB5oiSVA3W3AJWfosLuMuzEKPaoHZ_DWNS58H%3DFgast98w%40mail.gmail.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+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/CAChs6_mN8PRRt2Ot7YcHqcZGLXPoPcVS0_R_QdjCVYpZHpi5Ng%40mail.gmail.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+...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/CA%2B01voOy5SXXkyQeqMB-AxeGMXEv5MN%2Bj3FBdYB1DihHHh0inQ%40mail.gmail.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/e2c237d2-b8aa-4002-8fb4-edeaf03a8d3fn%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

On Wed, Mar 10, 2021 at 3:51 PM 'Jonathan Kliem' via sage-devel
 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
> >  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+unsubscr...@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/CAOTD34Z3mn0danobOkvXoX-OfjK-kMj94ojueNOLV-uQ6pdD_A%40mail.gmail.com.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

2021-03-10 Thread 'Jonathan Kliem' via sage-devel


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?

On 10.03.21 15:27, E. Madison Bray wrote:

On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe
 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+unsubscr...@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.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe
 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAOTD34bfTfrsFskmBGTwCOmco0zY%2B5pPpTdinikxcv9-8ffV%3Dw%40mail.gmail.com.

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

On Tue, Mar 9, 2021 at 6:13 PM Nathan Dunfield  wrote:
>
> An update: I just tried three different binary versions on Linux: The Ubuntu 
> 20.04 binary posted at SageMath.org, the sagemath/sagemath:develop Docker 
> image, and conda on RHEL 7.  None of them "just worked" with "sage -i foo".  
> The Docker image and conda failed completely with
>
> make: *** No rule to make target 'all-toolchain'.  Stop.
>
> I got farther with the Ubuntu binary.  Choosing "sage -i pyflakes", it 
> successfully pip-installed pyflakes and then started rebuilding all of Sage 
> from scratch, starting with libpng, pkgconf, etc.  So in some sense this 
> worked --- I was able to abort the build and import pyflakes --- but in the 
> end was equivalent to building Sage from source if I hadn't stopped it.

Yes, this has been a persistent problem.  It's a problem on
Sage-Windows as well.  In the past I've gotten it to work, but every
time people make changes to the build system (which is often) it tends
to break again, and as Matthias pointed out there is a not a
well-established process for testing this (I try to test it manually
but don't always remember to; or sometimes I do test it, but throw up
my hands when it doesn't work because I don't want to hold up the
release any longer).

A big part of the problem is that the system for installing packages
is badly interwoven with the build system for Sage itself.  There is a
good reason for this: If one of sagelib's build dependencies is
changed, it is necessary to rebuild sagelib.

For optional/experimental packages I think we should try to
disentangle them a bit better from the "normal" build system.  They
really should be "drop-in" and not require a rebuild of sagelib.

Part of my original goals for developing the "DESTDIR" build system
was so that it would eventually be easier to build binary packages for
optional packages.  I wanted to be able to use this on Windows, for
example, by allowing users to select optional packages by just
unpacking pre-built tarballs, but I never got around to materializing
that goal.  Of course, if such a system did exist it should be
available for other platforms as well.

> On Tuesday, March 9, 2021 at 9:00:22 AM UTC-6 Nathan Dunfield wrote:
>>
>> To what extent does installing optional packages "just work" with the 
>> current binary distributions of Sage?  I'm thinking of both those posted on 
>> sagemath.org as well as things not directly under our control such as the 
>> sage packages for conda, debian, gentoo, etc.  My past experience has been 
>> that "sage -i foo" works only if I had built Sage from source, though I 
>> haven't tried any of the binaries recently.
>>
>> I bring this up because the user impact of moving R or any other package to 
>> optional depends tremendously on whether "sage -i R" just works.  If 
>> switching R to optional is tantamount to requiring users of R to build all 
>> of Sage from source, that would be very disruptive for those users of R in 
>> Sage.  Building Sage from source  is a huge hurdle for 95% users and a 
>> nontrivial hassle for the rest.
>>
>> Best,
>>
>> Nathan
>
> --
> 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/4c6b267c-b29d-4aae-8bbd-f52f7f9ae820n%40googlegroups.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/CAOTD34bQKFJAGNqpXOajyAwioKCMJGiytHMw3tN%3Dc1L9P_eMcw%40mail.gmail.com.

[sage-devel] Re: distro packaging, docbuilding and modularisation

2021-03-10 Thread Antonio Rojas

El miércoles, 10 de marzo de 2021 a las 10:21:07 UTC+1, François Bissey 
escribió:

> Instead of trying to fix the problem that you should be building the 
> documentation 
> before installing, the push to modularisation is currently used to 
> enshrine the 
> current situation. #30010 actually separate the bits needed to build the 
> sage 
> documentation in a completely separate package. 
> So the situation is now: 
> * install package A 
> * install package B 
> * make a package C that takes B and applies it to the install of A and 
> install 
> the documentation of A (not C). 
>
>
Hi,
 As long as everything is still shipped in the Sage source tarball, isn't 
it just a matter of changing a path in the build script? I've always run 
the doc build directly from the Sage source, without installing anything, 
and I hope to be able to keep doing it that way (after a quick test, it 
still seems to be possible after #30010). Of course, if the long term plan 
is to split this to a separate git repo, then I completely share your 
concerns. 

-- 
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/d2c24ae8-a5ce-493c-8005-2518ec81d7abn%40googlegroups.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

2021-03-10 Thread Dima Pasechnik

On Wed, 10 Mar 2021, 09:21 François Bissey,  wrote:

> Hi all,
>
> So today I will be talking about subject that I in sage-on-gentoo have
> brushed under the carpet for years focusing on helping to be able to
> use more and more components of the system and ultimately get “sagelib”
> to be one such component.
>
> Sagemath as a meta distribution of stuff has bad habits in regards to
> treating “sagelib” as a regular package. In short it doesn’t.
>
> A normal software package usually should only contains it own sources,
> vendoring as it is called should be kept at a minimum and some other
> best practise are that
> * the package can be tested after being built and before being installed
> * the package documentation be built usually after the package itself,
> but before it is installed and the documentation should be installed
> at the same time as the rest of the package.
>
> Some project offer pre-build documentation, as part of the package if
> it is small, or downloadable tarballs if it is large. It is also
> the way to go for particularly difficult to build documentation.
> I’d say Sagemath will eventually go that way.
>
> So, we have made progress on vendoring, sage-on-gentoo has been building
> Sagelib and the documentation as a regular well behaved package for years
> and I have only pestered about the testing. Modularisation may force some
> things about the testing and offer solutions to an unmentioned problem
> so far, optional dependencies.
>
> But my situation about being able to build the documentation is under
> threat and is hack-ish in any case.
>
> So how are we building, installing and testing the elements of “vanilla"
> sage
> at the moment:
> * sagelib is built and installed
> * using the sagelib install the documentation is built. It is not supposed
> to be
> possible to build the doc without installing sage first, which is why
> sage-on-gentoo’s
> ability is really a hack
> * testing is done on the installed elements, that includes running tests
> inside the documentation
>
> Instead of trying to fix the problem that you should be building the
> documentation
> before installing, the push to modularisation is currently used to
> enshrine the
> current situation. #30010 actually separate the bits needed to build the
> sage
> documentation in a completely separate package.
> So the situation is now:
> * install package A
> * install package B
> * make a package C that takes B and applies it to the install of A and
> install
> the documentation of A (not C).
>
> Can anyone point me to some other system that do that? Does anyone else
> thinks
> that’s a bit insane?
>

numpy does this:
https://numpy.org/devdocs/docs/howto_build_docs.html

you can only build numpy docs after numpy is installed.



> #30010 is not all bad. Doc building elements have been buried inside
> sage_setup
> for a while and that wasn’t a good thing. sage_setup is mostly useless at
> runtime and shouldn’t really be installed unless some downstream packages
> can
> make use of it. But the doc building elements are already used by
> downstream
> packages (p_cohomology_group does), so installing them has some value.
>
> My own idea of modularisation would be that each package should be able to
> build
> its own documentation and be testable on its own, before install. Not to
> split
> the whole documentation as a separate package.
>
> I want to repeat #30010 is not without value. Having a helper package to
> build
> the documentation is not a bad idea in itself so long as it applies in the
> following
> order:
> * install B (the doc building helper)
> * build A, build A’s documentation using B
> * install A and its documentation
> No C please.
>
> If you read this far, thank you. That’s long enough for such a rant.
>
> François
>
>
> --
> 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/BE94013F-0363-4E78-94AD-93390E8669EA%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/CAAWYfq0tAM8kUFjLKi9DJgvcejwTaPXjeSP2ecF0ppHiwHd0qw%40mail.gmail.com.

[sage-devel] distro packaging, docbuilding and modularisation