Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Volker Braun]

Splitting responsibilities for different parts of the codebase is standard 
operating procedure for every large software project. And monorepo 
(everything in one git tree) is by now the well-established gold standard 
for managing the source code, especially for all components where you need 
versions to be in lock-step. Because it really makes no sense to test 
different versions of the CI infrastructure against multiple versions of 
the core business logic and multiple version of the documentation to verify 
that they really work together. And not everybody is a mathematician and a 
devops engineer and can write the Japanese documentation.

I don't see how it can be confusing to other developers, only the 
maintainers need to have a grasp of what they are maintaining. If you don't 
know you can always just open a PR and it will go its usual way.

The subsystem maintainer doesn't have to be a single person, can also be a 
group that manages their own workflow. 

Really we should focus our effort on the math part, where review by experts 
in the field is super-important to implement state-of-the-art algorithms. 
On the other hand, I don't really care how the CI is set up as long as it 
runs the testsuite.



On Saturday, May 11, 2024 at 1:19:14 AM UTC+2 julian...@fsfe.org wrote:

Dear Matthias,

If I read your proposal correctly, it is about removing review from changes 
made by "maintainers" and merging things directly into develop without 
waiting for the Release Manager.

Mostly, I am opposed to this because changes to the files you list are not 
automatically uncontroversial, see the disputed 
https://github.com/sagemath/sage/pull/37740, 
https://github.com/sagemath/sage/pull/37387, 
https://github.com/sagemath/sage/pull/37351, 
https://github.com/sagemath/sage/pull/36726, 
https://github.com/sagemath/sage/pull/36697, 
https://github.com/sagemath/sage/pull/36694, 
https://github.com/sagemath/sage/pull/36678, (there's probably more.)

In general, I am not sure about changing the review requirements. I know 
that having to do several rounds of review can be frustrating. At the same 
time, I like the idea of having somebody double check things. (I consider 
waiting for the first round of review a necessary annoyance. What can be 
really frustrating is waiting for the second round of review. Maybe, there 
are other ways to improve this, e.g., by encouraging people to set things 
to "feel free to set to positive review yourself once you addressed these 
tiny things I brought up in my review.")

I also think it's fairly confusing to have different rules for different 
parts of the repository. I would not mind at all to use different rules for 
different repositories within the sagemath organization though. And 
breaking the sage repository into smaller bits sounds like a good idea to 
me anyway. (As long as all the src/sage and src/doc stays in one place…) 
There are some means to reuse workflows in GitHub (I have not checked if 
they are feasible for us) and one could certainly try to extract some 
things into shared actions that live elsewhere. Maybe that's an approach 
that is worth exploring?

julian

-- 
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/b28f918f-7275-49b6-b9c0-ea2ef428c19fn%40googlegroups.com.

[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Volker Braun]

+1 to the general idea of maintainers for distinct subtrees 

As far as the implementation, I'd rather follow a model where there is a 
single merge queue at the end (currently me, could be automated when the CI 
is stricter and developers do not / cannot ignore it any more). Otherwise 
we'll just either have broken releases (untested rebase at the end) or 
drain my time by having to rebase / retest (takes a long time on the 
buildbot) / notice than another rebase is needed / rinse and repeat

Really all you need is to 
* have a "CI Build & Test" tag whose PR's are merged in before CI runs. 
* maintainer sets positive review on tickets under his responsibility
On Tuesday, April 9, 2024 at 11:12:00 PM UTC+2 Matthias Koeppe wrote:

> Dear Sage developers:
> I propose to consider the following governance change for a small part of 
> the Sage repository:
> 1. The directories *.ci, .devcontainer, .github/workflows*. These are 
> special directories that control the GitHub workflows that run for example 
> on pull requests and when release tags are pushed.
> 2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain 
> the infrastructure for portability testing of the Sage distribution (
> https://doc.sagemath.org/html/en/developer/portability_testing.html). 
>
> Some of these files are shipped as part of the Sage distribution, but none 
> of them have any role in the build process or runtime of Sage, and thus 
> none of them are tested by the Release Manager.
>
> *Status quo: *All changes to these files go through the normal review 
> process for Sage PRs; when set to "positive review", Volker merges them 
> into the next development release.
> In the terminology of https://martinfowler.com/articles/ship-show-ask.html 
> (ht Gonzalo Tornaria), this is the "Ask" model.
>
> Acknowledgment: I'm grateful to all who have contributed to the review of 
> my PRs that made changes to these files in the past: thanks for your time 
> and energy.
>
> *Proposed change: *All changes to these files are made through PRs. When 
> the PR is ready, a developer in the Maintainer role directly merges the PR 
> into the "develop" branch.
> In other words, switch to the "Show" model for these changes.
>
> *Why the change:*
> 1. Changes to these files do not have any effect on the build and runtime 
> of Sage;
> - thus changes to these files do not risk breaking the mathematical 
> correctness, or the performance of anything in Sage;
> - hence there may not be the same need for formal review compared to 
> changes to the Sage library.
>
> 2. Our project has a collective interest in smoothly operating development 
> infrastructure / quality assurance tools;
> - but tragedy of the commons;
> - more specifically, developing/improving such development tools only pays 
> off individually for developers with a sufficiently high volume of activity 
> (cf. 
> https://github.com/sagemath/sage/graphs/contributors?from=2020-01-01=2024-04-09=c
> );
> - there may also be a technical barrier that prevents developers from even 
> reviewing a PR that makes changes to these files;
> - hence, waiting for reviewers to approve a PR and waiting for the Release 
> Manager to merge it adds too much delay and friction.
>
> 3. Examples (all PRs authored by me, waiting for review):
> - "CI build, doc-build: Run containers explicitly, separate jobs for 
> pyright, build, modularized tests, long tests" (
> https://github.com/sagemath/sage/pull/36498) waiting for review since Oct 
> 21, 2023
> - "GH Actions: Build platform-independent wheels of sagemath-environment, 
> sage-setup, sage-sws2rst for PyPI" (
> https://github.com/sagemath/sage/pull/37099) waiting for review since Feb 
> 5
> - "CI: Update Linux platforms / runners" waiting for review since Feb 14
> - "GH Actions: Build macOS arm64 wheels" (
> https://github.com/sagemath/sage/pull/37503) waiting for review since Feb 
> 28
> - "CI Build: Fix "test modularized distributions" (
> https://github.com/sagemath/sage/pull/37750) waiting for review since Apr 
> 4
> - "dist.yml: Download optional/experimental tarballs for GitHub Release 
> assets" (https://github.com/sagemath/sage/pull/37762) waiting for review 
> since Apr 6
>
> 4. Non-examples (all PRs authored by me, waiting for review):
> - "CI Build: Show segfaults using GitHub annotations" (
> https://github.com/sagemath/sage/pull/37738, waiting for review) -- this 
> makes changes in sage.doctest, so would continue to be reviewed normally
> - "tox.ini: Add environments ruff, ruff-minimal; GH Actions: run 
> ruff-minimal" (https://github.com/sagemath/sage/pull/37453, waiting for 
> review) -- this also makes changes in src/tox.ini and src/doc, so would 
> continue to be reviewed normally
> - "src/tox.ini (coverage:run): Set concurrency = multiprocessing,threads" (
> https://github.com/sagemath/sage/pull/37010) -- makes changes in 
> src/tox.ini, so would continue to be reviewed normally
> - "sage -tox -e pyright: Update, speed up, isolate" 

[sage-devel] Group is set to moderate new members

[Volker Braun]

Somebody just pointed out to me that sage-release was set to moderate new 
members, so I changed it back so that everyone can post. This might be a 
new feature that is being rolled out with a default that prevents new 
members from posting directly. 

sage-devel is also set that "Group members can post but posts from new 
members will be held for moderation". Not sure if there is a big spam 
problem, but maybe we should also remove the new-member moderation. But I'm 
not a group admin there, so I can't do it

-- 
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/c5fd83ee-2ac7-434d-9dc8-bd343c2fab19n%40googlegroups.com.

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

[Volker Braun]

On Tuesday, April 23, 2024 at 6:24:51 PM UTC+2 seb@gmail.com wrote:

The problem with this is: if there are commits on a branch that are 
reviewed in more than one PR, the question is: does *positive review* mean 
*all* or *some* PR's?


The review is for a single PR, not for individual commits.

The positively reviewed PR gets merged, and then you may or may not want to 
rebase other PRs on the new develop branch. If you do, then the changes 
that were merged disappear from the "files changed" tab of that other PR on 
github. Either way, the commits from the positively reviewed PR are added 
to the sage codebase.

-- 
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/e5dd55d8-b716-483a-9414-546cdcc530fdn%40googlegroups.com.

Re: [sage-devel] Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Volker Braun]

Yes in a perfect world, but then you don't get a gold star for satisfying 
some purity test. We should just do the minimal amount of work to get us 
where we want to be. Lets focus on the direction to go and not too much on 
the process.

On Friday, April 19, 2024 at 7:18:03 PM UTC+2 Michael Orlitzky wrote:

> On Fri, 2024-04-19 at 09:46 -0700, Matthias Koeppe wrote:
> > 
> > Michael, note that in my message I asked for a vote on that dependency 
> > https://github.com/sagemath/sage/pull/36676.
> > 
>
> Even if 36676 gets approval, 36964 must be reverted. It was not
> meaningfully voted upon.
>
>

-- 
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/b9d41da8-57ec-4542-a5d8-7f2690849a49n%40googlegroups.com.

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

[Volker Braun]

It was merged because it was positively reviewed. 

Neither I nor the merge script reads every ticket description and looks 
through the text whether any dependency is mentioned that has not yet been 
reviewed. We can try to build such a Rube Goldberg machine, but I would 
very much argue against it. Just go with how github works, which is 
positive review = ready to merge and "files changed" shows the actual 
changes that this PR implements. Anything else will just prevent us from 
using standard tooling in the future. If anything introduce a "preliminary 
positive review" tag that gets replaced with actual positive review when 
the dependencies are in.

On Friday, April 19, 2024 at 9:50:35 AM UTC+2 Travis Scrimshaw wrote:

> +1 for merging #37796.
>
> Volker, I would appreciate if you could say something about how #36964 was 
> merged. It would be useful to understand the process with merging this, 
> rather than guessing the intent. Additionally, I thought we didn't merge 
> things when the dependencies have not been merged (or merged 
> simultaneously)? (This is why I am voting for reverting.)
>
> Best,
> Travis
>
> On Friday, April 19, 2024 at 9:57:25 AM UTC+9 G. M.-S. wrote:
>
>>
>> -1
>>
>> If something has been done that should be undone, I very much trust 
>> Volker to take care of it when he can, without the need for endless 
>> time-consuming discussions and votes.
>>
>> Best,
>>
>> Guillermo
>>
>> On Thu, 18 Apr 2024 at 17:54, David Roe  wrote:
>>
>>> Hi all,
>>> Sage has had a review process for over 15 years, but a combination of 
>>> recent changes has led to the merging of a PR into sage-10.4.beta3 of a 
>>> change (#36964 ) that I 
>>> believe should not (yet) have been merged.  In #37796 
>>>  I created a PR to revert 
>>> the change, which was opposed by the author of the original change.  After 
>>> some 
>>> voting 
>>>  
>>> using the disputed PR policy 
>>> , 
>>> Matthias has asked 
>>>  
>>> for a vote on sage-devel about this reversion, in accordance with the 
>>> section that "This process is intended as a lower-intensity method for 
>>> resolving disagreements, and full votes on sage-devel override the process 
>>> described below."  I am therefore asking you to vote (+1 means merge 
>>> #37796  in order to revert 
>>> #36964 ).
>>>
>>> First, here are the relevant parts of the history of this particular 
>>> change:
>>>
>>> - #36964  was created on 
>>> December 25 by Matthias, positively reviewed 
>>>  
>>> by Kwankyu on Decemebr 27, disputed, received enough votes 
>>>  
>>> to get a positive review on April 7, and was merged 
>>>  
>>> by Volker on April 12.  It had dependencies: #37667, 
>>> #36951 
>>> , and #36676 
>>> .  While #37667 
>>>  had positive review and 
>>> was already been merged, the other two were still disputed: they had 
>>> received an initial positive review but others objected and discussion was 
>>> ongoing.
>>>
>>> - #37667  is not disputed.
>>>
>>> - #36951  was created on 
>>> December 23 by Matthias, positively reviewed 
>>>  
>>> by Kwankyu on January 1, disputed, received enough votes 
>>>  
>>> (3-1) to change to positive review on April 7, had a clarification to bring 
>>> back to (3-2) and remove positive review, then was included in the merge of 
>>> #36964 . On April 13, John 
>>> Palmieri voted in favor 
>>> , 
>>> so the current vote stands at 4-2, enough for the 2-1 threshold in order to 
>>> get positive review under the disputed voting process.
>>>
>>> - #36676  was created on 
>>> November 8 by Matthias, positively reviewed 
>>>  
>>> by John Palmieri on November 15, and then disputed.  The most recent count 
>>> was 6-4 in favor 
>>> 

[sage-devel] Re: Sage's Code of Conduct: proposed changes

[Volker Braun]

Thanks for working on this, John!

I like that they are aspirational goals, being nice to each other shouldn't 
be that hard.

There are always going to be questions "what exactly is now allowed", but 
its impossible to enumerate everything. Is it OK to push to somebody else's 
branch, or change the issue description? Maybe. Surely fixing a typo is OK. 
But hijacking somebody else's issue to do something that wasn't intended by 
the author is not OK. Unless you talked about it first, and agreed on it. 
Then its OK again. Maybe you though the change was welcome, but it turns 
out it wasn't. Just be nice and reset the branch to the previous state, no 
harm done.





On Wednesday, February 28, 2024 at 10:24:29 PM UTC+1 John H Palmieri wrote:

> Dear colleagues,
>
> I am working on some changes to Sage's Code of Conduct, and I am asking 
> for comments. Once the draft has stabilized, then we will hold a vote on 
> sage-devel to approve (or not) the changes. Please visit 
> https://github.com/sagemath/sage/pull/37501 to see the proposal.
>
> The current Code of Conduct was approved by a vote in sage-devel almost 10 
> years ago. My intention is not to alter the core principles in the Code of 
> Conduct, but instead to add more details: for example, how should you 
> report a possible violation, what are possible consequences if the Sage 
> Code of Conduct Committee (what has until now been called the Sage Abuse 
> Committee) finds that a violation occurred, how to amend the document, etc. 
> The changes are based in large part on similar documents from SciPy and 
> NumFOCUS: we are not reinventing the wheel.
>
> As such, I hope that the proposed changes are (a) not controversial, and 
> (b) a clear improvement. I could certainly be wrong about either of these, 
> but I will make this suggestion: if you agree with me about (a) and (b) and 
> you also want to propose changes that are potentially more controversial, 
> then I would ask that you make that proposal separately so that the Sage 
> community can vote on it separately, and the changes can be merged 
> independently of each other.
>
> Please take a look and leave comments on the PR.
>
> -- 
> John
>
>

-- 
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/c4d11498-88c5-4306-8216-e7776c3eff30n%40googlegroups.com.

[sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Volker Braun]

On Saturday, January 13, 2024 at 1:19:52 PM UTC-5 Matthias Koeppe wrote:

I think we need to know at least some rough indication on the intended 
timeline of this proposed process.


My offer would be that I get it started (i.e. serve as the editor on the 
first batch of disputed tickets). Others will take over in the future if 
need be (though ideally its not needed, of course)

The timeline is then 1) editor makes decision to approve or decline and 2) 
done! 

Note: I'm on holiday this week

-- 
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/00bbf9d6-25a4-4126-a787-ce302425b0afn%40googlegroups.com.

[sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Volker Braun]

On Wednesday, January 10, 2024 at 2:37:59 PM UTC-5 Matthias Koeppe wrote:

[...] clarify the Code of Conduct and spell out its procedures and the 
range of sanctions


In case anyone missed this point, it is literally spelled out in William's 
original message:
 

For now, the main act of censure that the sage-abuse committee will be 
taking going forward will be to delete comments (on github and mailing 
lists) that violate the code of conduct.


 

-- 
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/bdf09d2b-db2a-4788-ba45-f7fcd739b7a1n%40googlegroups.com.

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Volker Braun]

Appointing an editor is not supposed to be part of normal review. This is 
for the (hopefully rare) cases where we, the community, horribly failed in 
the code review process and for whatever reason no consensus can be found 
among the issue participants. The code review should have been a 
cooperative group decisions of the issue participants.

If anyone thinks they can game the system by being a general nuisance and 
starting review wars in every issue to force editor decisions, then I'd 
encourage them to rethink their approach.


-- 
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/dd1261c7-4bcc-40cb-9c45-ee77adfde077n%40googlegroups.com.

[sage-devel] Re: Memory leaks in `while SR(float(0.5))` and in `a=gp('bnfinit(x^2+1)')`

[Volker Braun]

That is form ComplexIntervalField:

==4190879== 955,264 bytes in 39,803 blocks are still reachable in loss 
record 1,352 of 1,356
==4190879==at 0x484182F: malloc (vg_replace_malloc.c:431)
==4190879==by 0x1A6D3B07: sig_malloc (memory.c:1898)
==4190879==by 0x1A6D3B07: __pyx_f_4sage_3ext_6memory_sage_sig_malloc 
(memory.c:1517)
==4190879==by 0x153A4465: ???
==4190879==by 0x153A43F2: ???
==4190879==by 0x1C86D180: ???
==4190879==by 0x1C9F5B52: 
__pyx_pf_4sage_5rings_16complex_interval_27ComplexIntervalFieldElement___cinit__
 
(complex_interval.c:4266)
==4190879==by 0x1C9F5B52: 
__pyx_pw_4sage_5rings_16complex_interval_27ComplexIntervalFieldElement_1__cinit__
 
(complex_interval.c:4199)
==4190879==by 0x1C9F5B52: 
__pyx_tp_new_4sage_5rings_16complex_interval_ComplexIntervalFieldElement 
(complex_interval.c:21613)
==4190879==by 0x49FAE04: type_call (typeobject.c:1100)
==4190879==by 0x49A25E9: _PyObject_Call (call.c:343)
==4190879==by 0x49A25E9: _PyObject_Call (call.c:313)
==4190879==by 0x494F44B: _PyEval_EvalFrameDefault (ceval.c:5379)
==4190879==by 0x4A6F8DF: _PyEval_EvalFrame (pycore_ceval.h:73)
==4190879==by 0x4A6F8DF: _PyEval_Vector (ceval.c:6435)
==4190879==by 0x155B1F7E: __Pyx_PyObject_Call (coerce_maps.c:14540)
==4190879==by 0x155B1F7E: __Pyx_PyObject_Call2Args (coerce_maps.c:14797)
==4190879==by 0x155BF403: 
__pyx_f_4sage_9structure_11coerce_maps_24DefaultConvertMap_unique__call_ 
(coerce_maps.c:4719)

On Sunday, August 13, 2023 at 6:57:47 PM UTC+2 Georgi Guninski wrote:

> ```
> while 1: a=bool(SR(float(0.5)))
> ```
> leaks much. The stack and the global vars appear ugly to me.
> -- 
> guninski
> https://www.guninski.com/me.html
>

-- 
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/8cb18968-dbd5-4aef-862f-948a0586e307n%40googlegroups.com.

Re: [sage-devel] Re: Memory leak (quite bad)

[Volker Braun]

I've created a PR with the missing mpz_clear and a unit test strategy for 
memory leaks at https://github.com/sagemath/sage/pull/36046

On Friday, August 4, 2023 at 1:46:15 AM UTC+2 Dima Pasechnik wrote:

> is it  related to https://github.com/sagemath/sage/issues/27185 ?
> and/or 
> https://github.com/sagemath/sage/issues/19363
>
> pynac is a worry.
>
> On Thu, 3 Aug 2023, 23:59 Volker Braun,  wrote:
>
>> A quick valgrind run for 
>>
>> from sage.all import sqrt
>> T2 = sqrt(2)
>> for b in range(num := 100_000):
>> C = sqrt(T2)
>>
>> confirms that it is in pynac:
>>
>> ==3947957== 799,912 bytes in 99,989 blocks are definitely lost in loss 
>> record 1,299 of 1,300
>> ==3947957==at 0x484182F: malloc (vg_replace_malloc.c:431)
>> ==3947957==by 0x1A6D3B07: sig_malloc (memory.c:1898)
>> ==3947957==by 0x1A6D3B07: __pyx_f_4sage_3ext_6memory_sage_sig_malloc 
>> (memory.c:1517)
>> ==3947957==by 0x13D0EC2B: ???
>> ==3947957==by 0x13D0FEFD: ???
>> ==3947957==by 0x1FBA2393: 
>> GiNaC::numeric::integer_rational_power(GiNaC::numeric&, GiNaC::numeric 
>> const&, GiNaC::numeric const&) (numeric.cpp:1621)
>> ==3947957==by 0x1FBA266D: 
>> GiNaC::numeric::integer_rational_power(GiNaC::numeric&, GiNaC::numeric 
>> const&, GiNaC::numeric const&) (numeric.cpp:1614)
>> ==3947957==by 0x1FBA94DC: GiNaC::rational_power_parts(GiNaC::numeric 
>> const&, GiNaC::numeric const&, GiNaC::numeric&, GiNaC::numeric&, bool&) 
>> (numeric.cpp:1692)
>> ==3947957==by 0x1FBAA2AF: GiNaC::numeric::power(GiNaC::numeric 
>> const&) const (numeric.cpp:1916)
>> ==3947957==by 0x1FBBA918: GiNaC::power::eval(int) const 
>> (power.cpp:536)
>> ==3947957==by 0x1FB09107: 
>> GiNaC::ex::construct_from_basic(GiNaC::basic const&) (ex.cpp:923)
>> ==3947957==by 0x1FBB9D89: ex (ex.h:314)
>> ==3947957==by 0x1FBB9D89: GiNaC::power::eval(int) const 
>> (power.cpp:507)
>> ==3947957==by 0x1FB09107: 
>> GiNaC::ex::construct_from_basic(GiNaC::basic const&) (ex.cpp:923)
>> ==3947957== 
>>
>> On Wednesday, July 5, 2023 at 5:24:27 PM UTC+2 Gonzalo Tornaria wrote:
>>
>>> This slowly and inexorably goes on. Computing `sqrt(T2)` leaks 32 bytes 
>>> each and every time (asymptotically).
>>>
>>> Found by a student who, through no fault of himself, brought down our 
>>> server (unable to ssh in until the OOM triggered -- but since the leak is 
>>> slow it takes a while to trash 16G of swap).
>>>
>>> ===
>>> $ cat memleak.py 
>>> from sage.all import sqrt
>>> T2 = sqrt(2)
>>> import psutil
>>> ps = psutil.Process()
>>> base = ps.memory_info().rss
>>> for a in range(1, 10):
>>> for b in range(num := 100_000):
>>> C = sqrt(T2)
>>> mem = ps.memory_info().rss - base
>>> print(f"{mem/1e6 :.2f} MB ({mem/a/num :.2f} bytes/iter)")
>>> $ sage memleak.py 
>>> 2.70 MB (27.03 bytes/iter)
>>> 5.95 MB (29.74 bytes/iter)
>>> 9.19 MB (30.64 bytes/iter)
>>> 12.44 MB (31.09 bytes/iter)
>>> 15.41 MB (30.82 bytes/iter)
>>> 18.65 MB (31.09 bytes/iter)
>>> 21.90 MB (31.28 bytes/iter)
>>> 25.14 MB (31.43 bytes/iter)
>>> 28.39 MB (31.54 bytes/iter)
>>> ===
>>>
>>> Replace the 10 in the outer loop by something larger at your own peril 
>>> (each outer iteration will take 3.2M so 10_000 should kill a laptop in an 
>>> hour or two).
>>>
>>> This is with system sagemath 10.0 but it also happens with 9.6, 9.7, 9.8 
>>> and 10.0 in cocalc.com.
>>>
>>> Best,
>>> Gonzalo
>>>
>>> -- 
>> 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/eb17a08e-1576-4ab6-b09a-8333e3d55caan%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/eb17a08e-1576-4ab6-b09a-8333e3d55caan%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/d015e067-24c4-4536-b43c-2e58ac5d4bfbn%40googlegroups.com.

[sage-devel] Re: Memory leak (quite bad)

[Volker Braun]

A quick valgrind run for 

from sage.all import sqrt
T2 = sqrt(2)
for b in range(num := 100_000):
C = sqrt(T2)

confirms that it is in pynac:

==3947957== 799,912 bytes in 99,989 blocks are definitely lost in loss 
record 1,299 of 1,300
==3947957==at 0x484182F: malloc (vg_replace_malloc.c:431)
==3947957==by 0x1A6D3B07: sig_malloc (memory.c:1898)
==3947957==by 0x1A6D3B07: __pyx_f_4sage_3ext_6memory_sage_sig_malloc 
(memory.c:1517)
==3947957==by 0x13D0EC2B: ???
==3947957==by 0x13D0FEFD: ???
==3947957==by 0x1FBA2393: 
GiNaC::numeric::integer_rational_power(GiNaC::numeric&, GiNaC::numeric 
const&, GiNaC::numeric const&) (numeric.cpp:1621)
==3947957==by 0x1FBA266D: 
GiNaC::numeric::integer_rational_power(GiNaC::numeric&, GiNaC::numeric 
const&, GiNaC::numeric const&) (numeric.cpp:1614)
==3947957==by 0x1FBA94DC: GiNaC::rational_power_parts(GiNaC::numeric 
const&, GiNaC::numeric const&, GiNaC::numeric&, GiNaC::numeric&, bool&) 
(numeric.cpp:1692)
==3947957==by 0x1FBAA2AF: GiNaC::numeric::power(GiNaC::numeric const&) 
const (numeric.cpp:1916)
==3947957==by 0x1FBBA918: GiNaC::power::eval(int) const (power.cpp:536)
==3947957==by 0x1FB09107: GiNaC::ex::construct_from_basic(GiNaC::basic 
const&) (ex.cpp:923)
==3947957==by 0x1FBB9D89: ex (ex.h:314)
==3947957==by 0x1FBB9D89: GiNaC::power::eval(int) const (power.cpp:507)
==3947957==by 0x1FB09107: GiNaC::ex::construct_from_basic(GiNaC::basic 
const&) (ex.cpp:923)
==3947957== 

On Wednesday, July 5, 2023 at 5:24:27 PM UTC+2 Gonzalo Tornaria wrote:

> This slowly and inexorably goes on. Computing `sqrt(T2)` leaks 32 bytes 
> each and every time (asymptotically).
>
> Found by a student who, through no fault of himself, brought down our 
> server (unable to ssh in until the OOM triggered -- but since the leak is 
> slow it takes a while to trash 16G of swap).
>
> ===
> $ cat memleak.py 
> from sage.all import sqrt
> T2 = sqrt(2)
> import psutil
> ps = psutil.Process()
> base = ps.memory_info().rss
> for a in range(1, 10):
> for b in range(num := 100_000):
> C = sqrt(T2)
> mem = ps.memory_info().rss - base
> print(f"{mem/1e6 :.2f} MB ({mem/a/num :.2f} bytes/iter)")
> $ sage memleak.py 
> 2.70 MB (27.03 bytes/iter)
> 5.95 MB (29.74 bytes/iter)
> 9.19 MB (30.64 bytes/iter)
> 12.44 MB (31.09 bytes/iter)
> 15.41 MB (30.82 bytes/iter)
> 18.65 MB (31.09 bytes/iter)
> 21.90 MB (31.28 bytes/iter)
> 25.14 MB (31.43 bytes/iter)
> 28.39 MB (31.54 bytes/iter)
> ===
>
> Replace the 10 in the outer loop by something larger at your own peril 
> (each outer iteration will take 3.2M so 10_000 should kill a laptop in an 
> hour or two).
>
> This is with system sagemath 10.0 but it also happens with 9.6, 9.7, 9.8 
> and 10.0 in cocalc.com.
>
> Best,
> Gonzalo
>
>

-- 
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/eb17a08e-1576-4ab6-b09a-8333e3d55caan%40googlegroups.com.

[sage-devel] Can we get rid of the "Consider using a block-scoped tag" warning?

[Volker Braun]

The test output is full of "Warning: Consider using a block-scoped tag by 
inserting the line...", making it hard to see where the actual error is. 

Whats the purpose of this? Is somebody working on converting the magic 
comments? Should the warning be unconditionally removed? Can it at least be 
filtered out when running "/sage -t --all --long --only-errors"? Its 
--only-errors, not --only-errors-and-docstring-warnings ;)


-- 
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/41a76ce9-ced3-4bd8-94ea-b2ea38259b27n%40googlegroups.com.

[sage-devel] Re: Follow NEP 29: Recommended Python version

[Volker Braun]

NEP 29 just defines the minimum supported Python version, having a longer 
support window is equally NEP 29 compatible. 

Since we depend on numpy, sage-the-library inherits NEP 29. There isn't 
really anything to vote on here.

As far as sage-the-distribution goes, we should tie the support window to 
popular distros. Ideally by liberally calling "conda install python" 
whenever the distro python is too old.

Its unclear to me if this or the vote thread is about the library code or 
the distribution...


On Saturday, February 25, 2023 at 4:10:07 AM UTC+1 Tobias Diez wrote:

> Hi all, 
>
> I propose to follow the NumPy enhancement proposal 29: "Recommend Python 
> and Numpy version support as a community policy standard" available at: 
> https://numpy.org/neps/nep-0029-deprecation_policy.html
>
> In essence it specifies when it's okay to drop support for old Python 
> version. Namely, a release should support "all minor versions of Python 
> released 42 months prior to the project, and at minimum the two latest 
> minor versions. ". In particular, this means:
> - On Apr 14, 2023 drop support for Python 3.8 (initially released on Oct 
> 14, 2019) 
> - On Apr 05, 2024 drop support for Python 3.9 (initially released on Oct 
> 05, 2020)
>
> The main idea of NEP 29 is to have a community-wide standard to prevent 
> issues with e.g. dependencies dropping support for older Python versions to 
> early. It is followed by many scientific packages such as Scipy, 
> Matplotlib, and IPython, among others. Sage itself is also roughly 
> following it (based on the past drops, e.g. Python 3.7 support was dropped 
> 9 months ago and NEP recommends Dec 26, 2021). But as far as I'm aware 
> there is not yet a clear policy for when to drop support for older versions.
>
> Of course, the dates in the NEP 29 are only a guideline and not set in 
> stone, e.g. you don't want to drop support at the end of the release cycle 
> just because the NEP says so. But for example, Sage 10 will be most likely 
> released after Apr 14 2023, so we can now already drop support for Python 
> 3.8.
>
> Relevant issue: https://github.com/sagemath/sage/issues/30384
>
>

-- 
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/fac2d0d2-9a30-4e61-b48a-aae26d70dd7bn%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

[Volker Braun]

+1 to just using conda for all basic infrastructure packages if the host 
doesn't have them. Just put a conda env in the PATH and done.

In my experience these work really well. I've only gotten issues with conda 
when you veer off the trodden path too much, e.g. I've had nothing but 
trouble installing ruby from conda-forge and then trying to build gems on 
top of that (ruby has various hard-coded compiler configuration paths, some 
of which point to the wrong place). 


On Saturday, April 29, 2023 at 1:25:26 AM UTC+2 Matthias Koeppe wrote:

> On Thursday, April 27, 2023 at 1:24:01 AM UTC-7 Dima Pasechnik wrote:
>
> The next in line will be jupyter and friends.
>
>
> I agree with this point; specifically the front-end parts of 
> Jupyter/JupyterLab, which run in a separate Python process (and therefore 
> can be installed in a completely separate tree / venv). For this idea, we 
> have the the long-open metaticket 
> https://github.com/sagemath/sage/issues/30306 
>
> But this observation can be generalized. 
>
> For any package from which we only use executables or data, not a shared 
> library, we can install it in any way we want -- without compromising the 
> Sage distribution's ability to use already installed system packages.
> So we can switch from our own installation scripts to using conda-forge 
> for these!
>
> I've written up the details in 
> https://github.com/sagemath/sage/issues/35583
>
> I'm counting about 40 packages (not counting the Jupyter frontend 
> components) for which we can make a safe and easy withdrawal from packaging 
> activities, WITHOUT making the Sage distribution harder to install, and 
> avoiding the "concave cost" along the path that I mentioned.
>
> (Note that gcc/gfortran do not fall into this category of packages because 
> of their runtime library components.)
>
>

-- 
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/5b0f815b-9557-4bc3-8eb7-8ec3122df5d8n%40googlegroups.com.

[sage-devel] Incremental build breakage

[Volker Braun]

I'm noticing some random breakage with incremental builds, e.g. today in 
this incremental build 
(http://build.sagemath.org/#/builders/40/builds/59/steps/9/logs/stdio) 
the sage-conf package gets removed and then the installation crashed. I 
then re-ran exactly the same incremental build and it succeeded.


Possibly related, on OSX docbuild in incremental builds tends to die () 
with an

[sagemath_doc_html-none] ImportError: cannot load Singular library from 
libSingular.so (b'dlopen(libSingular.so, 9): image not found')

that then succeeds by re-runnnig.

-- 
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/4c8270ec-d39b-4e4b-9cda-8d9e025f7f08n%40googlegroups.com.

Re: [sage-devel] weird commits on top of develop

[Volker Braun]

I agree that we should turn on branch protection, it is rather easy to 
accidentally push to develop.

Its also not ok to push what you think is a CI fix without it going to 
review, we had some irregularities to support the github transition but 
that is over now. 



On Sunday, February 26, 2023 at 11:19:24 AM UTC+1 Vincent Delecroix wrote:

> I do not understand why develop isn't protected against anybody but
> the release manager pushes.
>
> On Sun, 26 Feb 2023 at 11:16, Dima Pasechnik  wrote:
> >
> > it was a mistake on my side - I thought develop branch was broken, but 
> it was not.
> >
> > On Sun, 26 Feb 2023, 10:13 Vincent Delecroix, <20100.d...@gmail.com> 
> wrote:
> >>
> >> Hello,
> >>
> >> Why do we have commits on top of develop after the release commits? 
> Namely
> >>
> >> commit 52a81cbd161ef4d5895325657c88a68590ea1d3b
> >> Author: Dima Pasechnik 
> >> Date: Fri Feb 24 21:15:42 2023 +
> >>
> >> Revert "add missing # optional - gap3"
> >>
> >> This reverts commit c017a6a3d68f0aca8cb63ceba52fe451a64881a3.
> >>
> >> commit c017a6a3d68f0aca8cb63ceba52fe451a64881a3
> >> Author: Dima Pasechnik 
> >> Date: Fri Feb 24 11:57:32 2023 +
> >>
> >> add missing # optional - gap3
> >>
> >> to let CI pass
> >>
> >> Best
> >> Vincent
> >>
> >> --
> >> 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/CAGEwAAkF50jNxVth6io%2BCErWu9mWFW4L2D%2BERqQVcNf7aPjp1A%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/CAAWYfq0XTpPcxuKuE11ChKpx0jcAjsxGRVsrD%2BLDeQO-X4RxnQ%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/3e520e29-93ba-4220-8b0d-3ba647792e73n%40googlegroups.com.

[sage-devel] Re: positively reviewed tickets on trac - do they need PRs?

[Volker Braun]

But also: Please don't merge branches into develop until it is absolutely 
necessary for the github transition (issue templates or ci setup)

On Tuesday, February 7, 2023 at 6:23:54 PM UTC+1 Dima Pasechnik wrote:

> We have positively reviewed tickets on trac - do we need to do
> anything, or just wait for the release manager to merge them?
>
> Dima
>

-- 
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/d0352dab-0a8a-477c-b240-766dcb90ae18n%40googlegroups.com.

[sage-devel] Re: positively reviewed tickets on trac - do they need PRs?

[Volker Braun]

I'll try to get them merged

On Tuesday, February 7, 2023 at 6:23:54 PM UTC+1 Dima Pasechnik wrote:

> We have positively reviewed tickets on trac - do we need to do
> anything, or just wait for the release manager to merge them?
>
> Dima
>

-- 
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/3ee02a4d-48a6-4a61-a4a2-9b6f91d07e77n%40googlegroups.com.

[sage-devel] Re: VOTE: move Sage development to Github

[Volker Braun]

+1 for github

On Wednesday, September 21, 2022 at 7:23:36 PM UTC+2 David Roe wrote:

> Dear Sage developers,
> Following extensive discussion, both recently 
>  
> (prompted 
> by issues upgrading the trac server) and over 
>  the 
>  last 
>  
> decade 
> , we 
> are calling a vote on switching Sage development from Trac 
>  to Github .  We've 
> created a summary of the pros and cons of each system 
> , a 
> description 
> of the development model to be used on github 
> , 
> and a trac ticket  for 
> coordinating work on the transition.  More work will need to be done to 
> carry out the actual transition once voting is complete.
>
> The voting will last until noon Eastern time (16:00 UTC) on Wednesday, 
> October 5.  Please use this thread only for sending votes, to make it 
> easier to count them afterward; there is a parallel thread where you can 
> make arguments in favor of either system.
>
> Finally, I will close with a plea to be involved in this vote and 
> discussion even if you are not a core Sage developer.  By definition, core 
> Sage developers have become comfortable with trac, and I think that one of 
> the major arguments in favor of github is that it will help bring in new 
> contributors who are not familiar with Sage's development workfow 
> .  Anyone who has 
> ever contributed to the Sage code base or who maintains a Sage user package 
> is welcome to vote.
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5c38adcb-cb73-4a04-a1d8-bf32daa1a284n%40googlegroups.com.

[sage-devel] Re: Moving SAGE_TMP to the system location

[Volker Braun]

Are we talking about /tmp or /var/tmp? 

https://systemd.io/TEMPORARY_DIRECTORIES/ says:
* /tmp/ should be used for smaller, size-bounded files only; /var/tmp/ 
should be used for everything else.
* Data that shall survive a boot cycle shouldn’t be placed in /tmp/.

While its often the case that /var/tmp has some time-based cleanup, this is 
not universally so.


-- 
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/7848acc1-089a-4f75-b3af-eae6bf3373b8n%40googlegroups.com.

Re: [sage-devel] Re: 32768

[Volker Braun]

On Tuesday, January 18, 2022 at 4:54:19 PM UTC+1 William Stein wrote:

> I'm curious -- what is the situation is with Sage and 32-bit Linux?
>

The Sage buildbot has 32-bit Debian 9, 10, 11 and it works. But using a 
recent (64-bit capable) CPU.


-- 
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/b0b0b3bd-dab4-4301-bb11-0f1033e46f3cn%40googlegroups.com.

[sage-devel] Whats the plan for random doctests with floating point numbers?

[Volker Braun]

There are doctests of the form 

sage: x = random_value()
sage: abs(floating_point_computation(x) - exact_value(x)) < tolerance
True 

but every floating point computation has SOME values where it is 
ill-conditioned. I'm finding a steady trickle of test failures due to the 
(now) random seeds for each run. Whats the plan for that?

A) mark them all as # random

B) identify all such tests and pick a fixed seed for those

C) identify all such tests and do the error analysis to find a tolerance(x) 
that takes the numerical instabilities into account

D) ignore issue and pick a fixed seed for the buildbot, will still randomly 
fail for users


PS: Here is one to illustrate the issue:

sage -t --long --warn-long 50.7 
--random-seed=269711721119345330713403621242624346446 
src/sage/functions/exp_integral.py
**
File "src/sage/functions/exp_integral.py", line 1493, in 
sage.functions.exp_integral.exponential_integral_1
Failed example:
for prec in [20..128]:  # long time (15s on sage.math, 2013)
R = RealField(prec)
S = RealField(prec+64)
a = R.random_element(-15,10).exp()
n = 2^ZZ.random_element(14)
x = exponential_integral_1(a, n)
y = exponential_integral_1(S(a), n)
c = RDF(4 * max(1.0, y[0]))
for i in range(n):
e = float(abs(S(x[i]) - y[i]) << prec)
if e >= c:
print("exponential_integral_1(%s, %s)[%s] with precision %s 
has error of %s >= %s"%(a, n, i, prec, e, c))
Expected nothing
Got:
exponential_integral_1(57.77854062056109797473161078505723378, 1)[0] 
with precision 127 has error of 4.75102130393081 >= 4.0
**
1 item had failures:
   1 of  11 in sage.functions.exp_integral.exponential_integral_1
[275 tests, 1 failure, 7.23 s]
--
sage -t --long --warn-long 50.7 
--random-seed=269711721119345330713403621242624346446 
src/sage/functions/exp_integral.py  # 1 doctest failed
--

-- 
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/6a08eaf8-227a-4340-8e33-a8c96a4ced32n%40googlegroups.com.

[sage-devel] Re: singular crash

[Volker Braun]

I'm seeing these fail regularly (and randomly)

On Friday, November 12, 2021 at 6:38:44 PM UTC+1 vdelecroix wrote:

> Dear all,
>
> I just set up a patchbot but two tests related to singular fail. The
> singular it uses was compiled from source. See the patchbot report
> at https://patchbot.sagemath.org/ticket/32859/
>
> sage -t --long --warn-long 42.4 
> --random-seed=24651699140802493978117085271929917492 
> src/sage/interfaces/expect.py
> **
> File "src/sage/interfaces/expect.py", line 915, in 
> sage.interfaces.expect.Expect._eval_line
> Failed example:
> singular.interrupt()
> Expected:
> True
> Got:
> False
> **
> File "src/sage/interfaces/expect.py", line 921, in 
> sage.interfaces.expect.Expect._eval_line
> Failed example:
> singular('2+3')
> Expected:
> Singular crashed -- automatically restarting.
> 5
> Got:
> 5
> **
> 1 item had failures:
> 2 of 16 in sage.interfaces.expect.Expect._eval_line
> [102 tests, 2 failures, 18.08 s]
>
> Best
> Vincent
>

-- 
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/a29fb38a-55eb-4f3e-b5b1-cdaf5fdcc377n%40googlegroups.com.

[sage-devel] Re: compilation problem for cypari

[Volker Braun]

As it says, you don't have enough memory to compile cypari

On Monday, November 8, 2021 at 9:15:48 AM UTC+1 fj.m...@gmail.com wrote:

> I get this error:
> [cypari-2.1.2]   virtual memory exhausted: Cannot allocate memory
> [cypari-2.1.2]   error: command '/usr/bin/gcc' failed with exit code 1
> which seems weird. Attached log as usual.
> Thanks for any help
> FM
>

-- 
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/1a6ca2b5-890d-4369-87cf-3e3ad773eeacn%40googlegroups.com.

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

[Volker Braun]

On Monday, September 27, 2021 at 1:29:23 AM UTC+2 dim...@gmail.com wrote:

> Homebrew need not be installed into /usr/local, and doesn't need root if 
> one chooses not to install there.
>

You can theoretically untar homebrew in a different directory, but at least 
when I tried that a couple of years ago I found myself up in a shit creek 
without a paddle. Have you actually tried? The installation document says:

However do yourself a favour and use the installer to install to the 
default prefix. Some things may not build when installed elsewhere. One of 
the reasons Homebrew just works relative to the competition is because we 
recommend installing here. Pick another prefix at your peril!

-- 
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/67bd3615-2c52-4c19-b68a-70f2187e092cn%40googlegroups.com.

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

[Volker Braun]

On Sunday, September 26, 2021 at 11:34:33 PM UTC+2 dim...@gmail.com wrote:

> I don't really see how homebrew is different from a rolling Linux distro.
>

Homebrew doesn't come from the OS vendor. No automatic security updates. 
There is no package management where the admin can look up if any 
suspicious file was installed by homebrew. You can't verify that the files 
in /usr/local are actually from homebrew, and not tampered with. The 
homebrew installation process is not cryptographically signed. I can go on 
if you want me to...

Conda, on the other hand, doesn't need root. Its as safe as any other user 
space app. You don't need admin permissions, and the standard unix 
permissions prevent you from screwing over other users on the system.

-- 
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/0a523dcb-c97b-44f2-90cd-353d88f04a91n%40googlegroups.com.

[sage-devel] Re: #32532 - removing gcc and gfortran spkgs

[Volker Braun]

On OSX I don't feel comfortable recommending anyone to run a script as root 
so homebrew can barf random files into the filesystem. For security and 
maintainability we really need to be able to install Sage without having 
unsigned and effectively unversioned dependencies.

My suggestion would be to replace the toolchain packages with a local conda 
install, i.e. keep the part where our configure checks if a suitable 
gcc/gfortran/... is installed. If not then pull down miniconda and install 
a working toolchain into $SAGE_LOCAL/conda, instead of trying to compile 
it. That way we can easily offload the toolchain maintenance effort, and 
keep all the benefits.
 


On Friday, September 24, 2021 at 12:17:29 AM UTC+2 dim...@gmail.com wrote:

> https://trac.sagemath.org/ticket/32532 
>  proposes to remove 
> these packages as not needed, and a huge time sink for everyone involved.
>
> Rationale: nowadays every platform that Sage supports has said tools (or 
> their equivalents - e.g. clang/clang++ in case of macOS and FreeBSD) 
> available, if not outright as a system package, but surely with a very 
> minimal effort.
>
> There is no need to carry this baggage forward.
> Moreover, it seems that Sage  is the only Python library/platform around 
> which (potentially) vendors gcc/g++/gfortran. 
>
>
>

-- 
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/7ad09b74-dc26-473c-b44f-342ab84e01ddn%40googlegroups.com.

[sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

[Volker Braun]

What about replacing gcc with a script that installs the conda toolchain 
automatically. The distro gcc currently does not work for me, so its not 
THAT rare to get into problems. On the other hard, installing conda is more 
likely to work than compiling gcc from scratch.

On Thursday, June 24, 2021 at 12:57:44 PM UTC+2 dim...@gmail.com wrote:

> It's high time we get rid of this annoyances; all the systems Sage
> supports have C/C++/fortran
> compilers capable of building Sage, and Python3 as well.
>
> (and in the very rare cases where it's not available, it's usually a
> problem solved
> by using something like Conda;)
>

-- 
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/763f5e25-ec75-434c-b2dc-978e94457c86n%40googlegroups.com.

Re: [sage-devel] Sage 9.4.beta3 failed to build (gcc-10.3.0)

[Volker Braun]

I'm running Fedora 34 and 9.4.beta3 builds fine (x86_64). It did compile 
the included gcc.




On Tuesday, June 22, 2021 at 11:50:00 PM UTC+2 dim...@gmail.com wrote:

>
>
> On Tue, 22 Jun 2021, 22:16 Kazuyoshi Furutaka,  
> wrote:
>
>> On the other hand, build of gcc-10.3 failed.   Then, what to do?
>>
>
> use another compiler.
> e.g. you can use clang
>
> dnf install clang
>
> then run Sages configure as follows
>
> CC=clang CXX=clang++ ./configure
>
> and then
>
> make
>
>
> This configuration is not tested much on Linux, but on macOS this is the 
> compiler used in our builds.
>
>
>
>> Kazuyoshi
>>
>> 2021年6月23日(水) 5:40 Dima Pasechnik :
>>
>>> Sage is not yet ready to be built with gcc 11, see
>>> https://trac.sagemath.org/ticket/31786
>>>
>>> On Tue, Jun 22, 2021 at 8:36 PM Kazuyoshi Furutaka
>>>  wrote:
>>> >
>>> >
>>> >
>>> > 2021年6月23日(水) 0:06 Dima Pasechnik :
>>> >>
>>> >> On Tue, Jun 22, 2021 at 3:45 PM Kazuyoshi Furutaka
>>> >>  wrote:
>>> >> [...]
>>> >> > First of all, I'd like to let you know that on Fedora-34 (x86_64), 
>>> the simple build (configured with --prefix only) of prestine gcc-10.3.0 
>>> fails without the static version of libstdc++ library (please read this 
>>> thread for details).
>>> >> >
>>> >> > On Fedora-33 systems, it can build without libstdc++.a; I've tried 
>>> to investigate the reason but couldn't figure out yet.
>>> >> >
>>> >> > Then, even on a Fedora-34 (x86_64) system WITH libstdc++.a, the 
>>> build of Sage 9.4.beta3 fails; the build of gcc-10.3.0 failed due to 
>>> "gcc-multilib-multiarch.patch": without it, the build of gcc succeeds.  
>>> I'll attach the log of the failed gcc build.
>>> >> > On Fedora,
>>> >> >   MULTILIB_OSDIRNAMES =  m64=../lib64 m32=../lib mx32=../libx32
>>> >> > instead of
>>> >> >   MULTILIB_OSDIRNAMES =  m64=../lib m32=../lib32 mx32=../libx32
>>> >> >
>>> >> > Sorry for just a report; I could not yet figure out how to resolve 
>>> this issue (modify the patch).
>>> >>
>>> >> it is not clear what you are trying to do.
>>> >>
>>> >> The reasons gcc is included as a package in Sage are mostly
>>> >> historical; I don't think there are many current use cases for it,
>>> >> and I think it actually should be removed.
>>> >> Fortunately there are enough options nowadays to source C/C++/Fortran
>>> >> compilers elsewhere.
>>> >> (at most, Sage might need to add some C,C++,Fortran flags)
>>> >>
>>> >> HTH,
>>> >> Dima
>>> >
>>> >
>>> > I once post a reply but it seems to disappear...
>>> >
>>> > I just want to build Sage from source.
>>> > The sage-build try to build GCC and a huge number of its dependent 
>>> packages though they're already on my system as rpm packages because GCC on 
>>> Fedora is TOO NEW.
>>> > So I'm very happy if someone modify the build system to avoid the 
>>> time-consuming build of GCC and its dependent!
>>> >
>>> > Yours,
>>> > Kazuyoshi
>>> > --
>>> > Kazuyoshi Furutaka
>>> >
>>> > --
>>> > 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/CANjERvf_M%3DDf25S3HKvkPhzXMxNEXGRcAbtUSU6g0J2UG6Q3CQ%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/CAAWYfq2g68RNyD6L6jw2d_XNtOrdrqc8K3TvoMcU_H9iVXRPLQ%40mail.gmail.com
>>> .
>>>
>>
>>
>> -- 
>> Kazuyoshi Furutaka
>>
>> -- 
>> 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/CANjERveKpCrg%2BhJ-Expdkx5is-Jy7ehhhmmw3buWzcBpPL9o7w%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/a2dc0758-8dd3-4b59-aa28-27d9d2f5e461n%40googlegroups.com.

[sage-devel] Re: Help with merge conflict

[Volker Braun]

As you said, module_list.py has been deleted in the meantime

First: abort your previous merge

git merge --abort

Then merge:

git checkout public/optional_spkg/differential_algebra-13268
git merge trac/develop
git add src/module_list.py
git commit



On Monday, June 21, 2021 at 10:37:17 PM UTC+2 adamn...@gmail.com wrote:

> Hello,
>
> I am trying to merge the branch 
> public/optional_spkg/differential_algebra-13268 into current version of 
> Sage but am running into issues. Pulling returned a merge conflict:
>
> CONFLICT (modify/delete): src/module_list.py deleted in HEAD and modified 
> in 81aef63dc5e33948f1f37a995ac09189d0a99eda. Version 
> 81aef63dc5e33948f1f37a995ac09189d0a99eda of src/module_list.py left in tree.
>
> I interpret this message as meaning module_list.py was removed from the 
> develop branch after the last commit to the 13268 branch (which was bout 2 
> years ago). module_list.py is listed as being for 'pkg-config setup'. Is 
> this no longer necessary? Does something need to be updated so that 13268 
> is compatible with the current version of Sage?
>
> I tried deleting module_list.py, but that didn't seem to work. After 
> comitting, git said I could no longer merge files, and running 'make build' 
> returned the errors:
>
> make[1]: *** [Makefile:39: all-build] Error 1
> make: *** [Makefile:16: build] Error 2
>
> I don't know how to handle these errors. Is it perhaps an issue of my 
> inexperience with git?
>
> Any help would be greatly appreciated!
>

-- 
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/1e49e87f-088e-4059-9950-3731645dadacn%40googlegroups.com.

[sage-devel] Re: Minimum Python version to 3.8

[Volker Braun]

Yet another possibility is to look for a backport that implements 
sufficient functionality for your needs for now.

On Tuesday, May 11, 2021 at 2:40:04 AM UTC+2 Matthias Koeppe wrote:

> -1. Even NEP 29 (https://numpy.org/neps/nep-0029-deprecation_policy.html) 
> does not drop Python 3.7 support before end of the year.
>
>
> On Monday, May 10, 2021 at 4:12:48 PM UTC-7 Travis Scrimshaw wrote:
>
>> On #30423 , which is getting 
>> close to completion, we will be using multiprocessing.shared_memory, which 
>> is only available on Python 3.8+. However, right now we are at least 
>> allowing Python 3.7 (as per the patchbot). So my main proposal would be to 
>> bump the minimum required Python version to 3.8, which was released Oct. 
>> 14, 2019.
>>
>> On that ticket, we can make it so that the main entry point runs things 
>> in serial if the Python version is sufficiently small and that the doc 
>> builds, but the doctests for the parallel code will fail. So the first 
>> alternative option would be to mark certain doctests (or the file) as 
>> needing a large Python version.
>>
>> A second alternative is that this can be split off as a separate package 
>> (either an optional Sage package or pip installable). Yet, it is somewhat 
>> tightly coupled with the FusionRing code (and root systems) in Sage, so 
>> this is not so desirable. A less invasive way would be to just split the 
>> parallel part off, but this would take some work to do I think.
>>
>> What do people think?
>>
>> Best,
>> Travis
>>
>>

-- 
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/1433c01d-4c0a-4960-9a3f-e1f11ea6e9d3n%40googlegroups.com.

Re: [sage-devel] [abi:cxx11] in givaro prevents linking to system givaro on Fedora 32

[Volker Braun]

"Dual" refers to libstdc++ here, i.e. you only have one standard library 
supporting both abi's.  

Other libraries generally are only one or the other, this is what is 
controlled by the -D_GLIBCXX_USE_CXX11_ABI; Theoretically you could make 
your own dual-abi library but you'd have to plaster 
__attribute__((abi_tag("cxx11"))) everywhere, so hell no.

What I'm saying is: if you provide the same value for 
-D_GLIBCXX_USE_CXX11_ABI as what was used for the system givaro then you 
should be able to link them together.



On Monday, May 10, 2021 at 2:27:44 PM UTC+2 dim...@gmail.com wrote:

> On Sunday, May 9, 2021 at 11:24:23 AM UTC+1 Volker Braun wrote:
>
>> This is c++11 dual abi, see 
>> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
>>
>> IMHO we just shouldn't use the system version then, but building Sage 
>> with -D_GLIBCXX_USE_CXX11_ABI=0 should allow you to link with old-style abi 
>> libraries.
>>
>> The default value of _GLIBCXX_USE_CXX11_ABI can be changed by the distro, 
>> which is probably what accounts for the differences seen in this thread.
>>
>
> Are you saying it's a bug in Fedora 32, they should have provided dual 
> ABI, like Gentoo does, but they don't?
> Or that they provide an old-style ABI, and we can use ` 
> -D_GLIBCXX_USE_CXX11_ABI=0` to make this work for Sage?
> Isn't c++11 "old" nowadays?
>
> I tried to write a short C++ code do produce this error, so that we can 
> put it into our gcc/spkg-configure.m4, but I cannot
> figure it out.  
>
>
>  
>
>>
>>
>> On Saturday, May 8, 2021 at 7:01:13 PM UTC+2 Steven Trogdon wrote:
>>
>>> Building Givaro on Gentoo I have
>>>
>>> CXXFLAGS=-O2 -pipe -march=native -O2 -pipe   -fabi-version=6   -msse 
>>> -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx
>>>
>>> Your Redhat has
>>>
>>> CXXFLAGS=-O2 -g -pipe -Wall -Werror=format-security 
>>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
>>> -fstack-protector-strong -grecord-gcc-switches 
>>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
>>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>>>
>>> Could the  abi-version=6 be the issue?
>>>
>>> On Saturday, May 8, 2021 at 6:01:02 AM UTC-6 dim...@gmail.com wrote:
>>>
>>>> one has 
>>>> https://kojipkgs.fedoraproject.org//packages/givaro/4.1.1/1.fc32/data/logs/x86_64/build.log
>>>> and other logs there
>>>>
>>>> On Saturday, May 8, 2021 at 12:45:07 PM UTC+1 Dima Pasechnik wrote:
>>>>
>>>>> On Saturday, May 8, 2021 at 12:34:11 PM UTC+1 François Bissey wrote:
>>>>>
>>>>>> What compiler and flags have used to compile fedora 32 givaro? Can we 
>>>>>> easily find out?
>>>>>
>>>>>
>>>>> the compiler used to build Sage is g++ 10.2.1
>>>>>
>>>>> $ g++ -v
>>>>> Using built-in specs.
>>>>> COLLECT_GCC=/usr/bin/g++
>>>>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
>>>>> OFFLOAD_TARGET_NAMES=nvptx-none
>>>>> OFFLOAD_TARGET_DEFAULT=1
>>>>> Target: x86_64-redhat-linux
>>>>> Configured with: ../configure --enable-bootstrap 
>>>>> --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr 
>>>>> --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=
>>>>> http://bugzilla.redhat.com/bugzilla --enable-shared 
>>>>> --enable-threads=posix --enable-checking=release --enable-multilib 
>>>>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
>>>>> --enable-gnu-unique-object --enable-linker-build-id 
>>>>> --with-gcc-major-version-only --with-linker-hash-style=gnu 
>>>>> --enable-plugin 
>>>>> --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none 
>>>>> --without-cuda-driver --enable-gnu-indirect-function --enable-cet 
>>>>> --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
>>>>> Thread model: posix
>>>>> Supported LTO compression algorithms: zlib zstd
>>>>> gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC) 
>>>>>
>>>>>  
>>>>>
>>>>>>
>>>>>>
>>>>>> > On 8/05/2021, at 23:31, Dima Pasechnik  wrote

Re: [sage-devel] [abi:cxx11] in givaro prevents linking to system givaro on Fedora 32

[Volker Braun]

PS: Fedora 32 EOL is imminent (= 4 weeks after the just-released fedora 
34), so I wouldn't worry too much about it

On Sunday, May 9, 2021 at 12:24:23 PM UTC+2 Volker Braun wrote:

> This is c++11 dual abi, see 
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
>
> IMHO we just shouldn't use the system version then, but building Sage with 
> -D_GLIBCXX_USE_CXX11_ABI=0 should allow you to link with old-style abi 
> libraries.
>
> The default value of _GLIBCXX_USE_CXX11_ABI can be changed by the distro, 
> which is probably what accounts for the differences seen in this thread.
>
>
> On Saturday, May 8, 2021 at 7:01:13 PM UTC+2 Steven Trogdon wrote:
>
>> Building Givaro on Gentoo I have
>>
>> CXXFLAGS=-O2 -pipe -march=native -O2 -pipe   -fabi-version=6   -msse 
>> -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx
>>
>> Your Redhat has
>>
>> CXXFLAGS=-O2 -g -pipe -Wall -Werror=format-security 
>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
>> -fstack-protector-strong -grecord-gcc-switches 
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>>
>> Could the  abi-version=6 be the issue?
>>
>> On Saturday, May 8, 2021 at 6:01:02 AM UTC-6 dim...@gmail.com wrote:
>>
>>> one has 
>>> https://kojipkgs.fedoraproject.org//packages/givaro/4.1.1/1.fc32/data/logs/x86_64/build.log
>>> and other logs there
>>>
>>> On Saturday, May 8, 2021 at 12:45:07 PM UTC+1 Dima Pasechnik wrote:
>>>
>>>> On Saturday, May 8, 2021 at 12:34:11 PM UTC+1 François Bissey wrote:
>>>>
>>>>> What compiler and flags have used to compile fedora 32 givaro? Can we 
>>>>> easily find out?
>>>>
>>>>
>>>> the compiler used to build Sage is g++ 10.2.1
>>>>
>>>> $ g++ -v
>>>> Using built-in specs.
>>>> COLLECT_GCC=/usr/bin/g++
>>>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
>>>> OFFLOAD_TARGET_NAMES=nvptx-none
>>>> OFFLOAD_TARGET_DEFAULT=1
>>>> Target: x86_64-redhat-linux
>>>> Configured with: ../configure --enable-bootstrap 
>>>> --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr 
>>>> --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=
>>>> http://bugzilla.redhat.com/bugzilla --enable-shared 
>>>> --enable-threads=posix --enable-checking=release --enable-multilib 
>>>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
>>>> --enable-gnu-unique-object --enable-linker-build-id 
>>>> --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin 
>>>> --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none 
>>>> --without-cuda-driver --enable-gnu-indirect-function --enable-cet 
>>>> --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
>>>> Thread model: posix
>>>> Supported LTO compression algorithms: zlib zstd
>>>> gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC) 
>>>>
>>>>  
>>>>
>>>>>
>>>>>
>>>>> > On 8/05/2021, at 23:31, Dima Pasechnik  wrote: 
>>>>> > 
>>>>> > With system Givaro, one gets 
>>>>> > 
>>>>> > [dochtml] ImportError: 
>>>>> /home/scratch2/dimpase/sage/sage/local/lib64/python3.8/site-packages/sage/matrix/
>>>>> matrix_modn_sparse.cpython-38-x86_64-linux-gnu.so: undefined symbol: 
>>>>> _ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
>>>>>  
>>>>>
>>>>> > make[3]: *** [Makefile:2280: doc-html] Error 1 
>>>>> > 
>>>>> > which demangled says 
>>>>> > 
>>>>> > $ c++filt 
>>>>> _ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
>>>>>  
>>>>>
>>>>> > Givaro::Integer::operator std::__cxx11::basic_string>>>> std::char_traits, std::allocator >[abi:cxx11]() const 
>>>>> > 
>>>>> > The system library has Givaro::Integer::operator 
>>>>> std::__cxx11::basic_string, 
>>>>> std::allocator >() const 
>>>>> > 
>>>>> > (no of that weird [abi:cxx11] qualifier) 
>>>>> > 
>>>>> > Any ideas how to fix this? (besides not using system Givaro) ? 
>>>>> > 
>>>>> > Dima 
>>>>> > 
>>>>> > -- 
>>>>> > 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/b187faf3-50c4-42c4-ae37-77c5a3902bbcn%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/c1ada588-aa08-4115-ad21-f121ae47fa30n%40googlegroups.com.

Re: [sage-devel] [abi:cxx11] in givaro prevents linking to system givaro on Fedora 32

[Volker Braun]

This is c++11 dual abi, see 
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

IMHO we just shouldn't use the system version then, but building Sage with 
-D_GLIBCXX_USE_CXX11_ABI=0 should allow you to link with old-style abi 
libraries.

The default value of _GLIBCXX_USE_CXX11_ABI can be changed by the distro, 
which is probably what accounts for the differences seen in this thread.


On Saturday, May 8, 2021 at 7:01:13 PM UTC+2 Steven Trogdon wrote:

> Building Givaro on Gentoo I have
>
> CXXFLAGS=-O2 -pipe -march=native -O2 -pipe   -fabi-version=6   -msse 
> -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx
>
> Your Redhat has
>
> CXXFLAGS=-O2 -g -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
> -fstack-protector-strong -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>
> Could the  abi-version=6 be the issue?
>
> On Saturday, May 8, 2021 at 6:01:02 AM UTC-6 dim...@gmail.com wrote:
>
>> one has 
>> https://kojipkgs.fedoraproject.org//packages/givaro/4.1.1/1.fc32/data/logs/x86_64/build.log
>> and other logs there
>>
>> On Saturday, May 8, 2021 at 12:45:07 PM UTC+1 Dima Pasechnik wrote:
>>
>>> On Saturday, May 8, 2021 at 12:34:11 PM UTC+1 François Bissey wrote:
>>>
 What compiler and flags have used to compile fedora 32 givaro? Can we 
 easily find out?
>>>
>>>
>>> the compiler used to build Sage is g++ 10.2.1
>>>
>>> $ g++ -v
>>> Using built-in specs.
>>> COLLECT_GCC=/usr/bin/g++
>>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
>>> OFFLOAD_TARGET_NAMES=nvptx-none
>>> OFFLOAD_TARGET_DEFAULT=1
>>> Target: x86_64-redhat-linux
>>> Configured with: ../configure --enable-bootstrap 
>>> --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr 
>>> --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=
>>> http://bugzilla.redhat.com/bugzilla --enable-shared 
>>> --enable-threads=posix --enable-checking=release --enable-multilib 
>>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
>>> --enable-gnu-unique-object --enable-linker-build-id 
>>> --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin 
>>> --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none 
>>> --without-cuda-driver --enable-gnu-indirect-function --enable-cet 
>>> --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
>>> Thread model: posix
>>> Supported LTO compression algorithms: zlib zstd
>>> gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC) 
>>>
>>>  
>>>


 > On 8/05/2021, at 23:31, Dima Pasechnik  wrote: 
 > 
 > With system Givaro, one gets 
 > 
 > [dochtml] ImportError: 
 /home/scratch2/dimpase/sage/sage/local/lib64/python3.8/site-packages/sage/matrix/
 matrix_modn_sparse.cpython-38-x86_64-linux-gnu.so: undefined symbol: 
 _ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
  

 > make[3]: *** [Makefile:2280: doc-html] Error 1 
 > 
 > which demangled says 
 > 
 > $ c++filt 
 _ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
  

 > Givaro::Integer::operator std::__cxx11::basic_string>>> std::char_traits, std::allocator >[abi:cxx11]() const 
 > 
 > The system library has Givaro::Integer::operator 
 std::__cxx11::basic_string, 
 std::allocator >() const 
 > 
 > (no of that weird [abi:cxx11] qualifier) 
 > 
 > Any ideas how to fix this? (besides not using system Givaro) ? 
 > 
 > Dima 
 > 
 > -- 
 > 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/b187faf3-50c4-42c4-ae37-77c5a3902bbcn%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/d5ab7843-811a-452d-bf74-c3c21bc4aef2n%40googlegroups.com.

[sage-devel] Re: Using a pickle jar for doctesting purpose

[Volker Braun]

Python pickles aren't really a good long-term storage format; A much safer 
bet would be to serialize/deserialize to json, say.  I don't know how 
feasible that woud be in your case though.

On Friday, April 30, 2021 at 10:18:01 AM UTC+2 Kwankyu Lee wrote:

> Hi all,
>
> The ticket  
>
> https://trac.sagemath.org/ticket/27957
>
> adds algebraic geometry error correcting codes (also called geometric 
> Goppa codes) and their decoders to Sage. Once merged, this will be another 
> edge where Sage is superior to Magma.
>
> Travis and I are working on the ticket, and we encountered an issue on 
> doctesting the code. It takes a "long" time (about 4 seconds) to construct 
> a decoder (a smallest nontrivial example). Thus it takes much time for 
> doctesting all code (about 60 doctests) as each doctest has to construct a 
> decoder before testing a method. So to save time, we decided to save the 
> decoder as an sobj object, and to load the object before each test. There 
> are 8 saved objects in .../coding/tests subdirectory for this purpose.
>
> Now we worry if there is a security breach in this way of doctesting. We 
> did not find other example doing the same in the Sage lib. What do you 
> think? If there is a real threat in security, then we would revert to the 
> established way of adding "# long time" to the doctests. Thank you for 
> attention.
>

-- 
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/dc307a69-565b-40f4-ac70-2fafcfc0261an%40googlegroups.com.

[sage-devel] Re: Feature request: Flatpak

[Volker Braun]

flatpak is designed for gui apps, registering a desktop icon and so on. To 
really make use of it we'd need at least a small gui app that then lets you 
start/stop the jupyter server and/or launch browser windows. 

If you just want to run Sage then there is already a one-liner podman / 
docker command to download and run it (and with podman any user account can 
do it, no permission setup needed):

 podman run  -it sagemath/sagemath


On Sunday, April 18, 2021 at 6:17:39 AM UTC+2 318...@gmail.com wrote:

> Flatpak is a format for packaging Linux desktop applications that can work 
> on most distros using a single binary.  Given the difficulty of packaging 
> Sagemath for each distro, and the difficulty of updating existing Sage 
> packages to work with newer versions of distros, I think having a flatpak 
> package of sagemath would make it easier to get the latest version of Sage 
> running on as many systems as possible.
>
> --Beth
>

-- 
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/dc0fb066-2fe1-458a-a1f7-02b9a31b3ec9n%40googlegroups.com.

[sage-devel] Re: Doctest memory limit

[Volker Braun]

I don't understand what the big pain point is, if Steve doesn't like the 
limit it he can just pick a different value no?

We do need some way of keeping the memory usage in check, people naturally 
want to show off largeish computations and we run the risk to require a 
beefy developer machine to be able to develop for Sage.

As long as we have 32-bit buildbots the limit can't be much higher, but the 
writing is on the wall than 32-bit is going away eventually.

>From my point of view its better to have some limit that provides immediate 
feedback during development than me having to maintain a special buildbot 
to limit memory usage and police tickets where developers don't have an 
easy way to reproduce.   

On Tuesday, March 23, 2021 at 1:21:43 AM UTC+1 Michael Orlitzky wrote:

> Is anyone very much in love with the --memlimit (default: 3300MB)
> option to the sage -t command?
>
> Once again it has completely broken testing on some systems. We could
> try to guess a new, higher limit... or just admit that maybe it's not a
> great idea after all and delete the thing. The latter is what I'm about
> to propose on https://trac.sagemath.org/ticket/31395
>
> A few points:
>
> * The failure of the default limit has been and will always be a 
> recurring problem as sage requires more and more memory. Every
> time we hit it, a bunch of machines are broken until the limit
> can be raised in the "develop" branch.
>
> * The default memory limit exists for precisely one doctest (which 
> I've refactored to still be tested, modulo the next bullet point).
>
> * Testing out-of-memory conditions doesn't test what you'd expect, 
> since if you _actually_ run out of memory, all hell breaks loose
> on the system at the same time as your graceful error handling 
> kicks in.
>
> * A global limit is likely incorrect, as would be revealed if there 
> were more than one doctest using it. Each test needs the limit to
> be low enough to trigger a failure, but not low enough to crash
> the rest of sage. Both of these numbers are test- and system-
> dependent.
>
> * Reimplementing "ulimit -v" in a mathematics suite is a waste of
> development resources.
>
> I'd rather just delete it and generalize the one existing doctest with
> something like a "with memlimit(...)" context manager in the unlikely
> event that we ever have another test for OOM behavior.
>
>
>

-- 
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/536abe7e-c9fd-4336-aa03-8d430508a472n%40googlegroups.com.

Re: [sage-devel] Memory leak in integer multiplication in sage?

[Volker Braun]

This is presumably the same memory leak as in 
https://trac.sagemath.org/ticket/31340

On Thursday, March 18, 2021 at 7:21:14 PM UTC+1 m.derick...@gmail.com wrote:

> Hi Vincent,
>
> Thanks for testing and good that you realized that indeed looked fishy 
> indeed.
>
> I think your extension of my code with multiple loops actually confirms 
> that there is a problem even after warming up:
>
> the prints:
>
> memory usage 30k: 1771.8046875
> memory usage 40k: 1771.80859375
>
> mean that you are using 1.7 GB memory extra after the 3th and the 4th loop 
> (notice you chance the baseline of memory usage every loop so the 1.7 GB is 
> not the total memory usage of sage, it is the new memory usage relative to 
> the previous loop). So that in the end sage was using around 885+3*1777 MB 
> = 6.1 GB of memory in your session.
>
> Also,  the largest object ever created are a range object of size 1 
> (which in python 3 is actually consuming almost no memory since under the 
> hood it behaves very much like xrange from python 2) and an srange object 
> of size 3000. Neither of these should occupy an amount of memory in the GB 
> range.
>
> Also one thing that is maybe easy to miss, I doubled the size of the loop 
> between the first loop and the second loop, which explains the 885 vs 1771.
>
>
> On Thursday, 18 March 2021 at 17:52:19 UTC+1 vdelecroix wrote:
>
>> Sorry, your example indeed looks fishy. 
>>
>> Le 18/03/2021 à 17:36, Vincent Delecroix a écrit : 
>> > Maarten, in your example your can not fairly compare the first 
>> > and second run. For example R is not allocated at your first 
>> > call of "mem = get_memory_usage()". Also Integers have a pool 
>> > which is likely not being filled at startup. Ignoring the first 
>> > run, I do not notice any difference. 
>> > 
>> > (both on system sage 9.2 and compiled sage 9.3.beta8 on archlinux) 
>> > 
>> > sage: M = 3000 
>> > : import gc 
>> > : _ = gc.collect() 
>> > : mem = get_memory_usage() 
>> > : for i in range(1): 
>> > : R = srange(M) 
>> > : _ = gc.collect() 
>> > : print("memory usage 10k:", get_memory_usage(mem)) 
>> > : mem = get_memory_usage() 
>> > : for i in range(2): 
>> > : R = srange(M) 
>> > : _ = gc.collect() 
>> > : print("memory usage 20k:", get_memory_usage(mem)) 
>> > : mem = get_memory_usage() 
>> > : for i in range(2): 
>> > : R = srange(M) 
>> > : _ = gc.collect() 
>> > : print("memory usage 30k:", get_memory_usage(mem)) 
>> > : mem = get_memory_usage() 
>> > : for i in range(2): 
>> > : R = srange(M) 
>> > : _ = gc.collect() 
>> > : print("memory usage 40k:", get_memory_usage(mem)) 
>> > 
>> > memory usage 10k: 885.4453125 
>> > memory usage 20k: 1771.9375 
>> > memory usage 30k: 1771.8046875 
>> > memory usage 40k: 1771.80859375 
>> > 
>> > Le 18/03/2021 à 17:00, Maarten Derickx a écrit : 
>> >> Hi Guys, 
>> >> 
>> >> Thanks for the replies. I think this is enough info to know that it 
>> >> happens 
>> >> on multiple systems and that it's not just the cocalc enhanced version 
>> of 
>> >> sage. I have created: 
>> >> https://trac.sagemath.org/ticket/31511#ticket for this. 
>> >> 
>> >> In the meantime I found the problem is already with the srange 
>> >> command. So 
>> >> the integer multiplication seems to be a red herring. 
>> >> 
>> >> ~$ sage 
>> >> ┌┐ 
>> >> │ SageMath version 9.2, Release Date: 2020-10-24 │ 
>> >> │ Create a "Sage Worksheet" file for the notebook interface. │ 
>> >> │ Enhanced for CoCalc.   │ 
>> >> │ Using Python 3.8.5. Type "help()" for help.│ 
>> >> └┘ 
>> >> sage: M = 3000 
>> >> : import gc 
>> >> : gc.collect() 
>> >> : mem = get_memory_usage() 
>> >> : for i in range(1): 
>> >> : R = srange(M) 
>> >> : gc.collect() 
>> >> : print("memory usage 10k:", get_memory_usage(mem)) 
>> >> : mem = get_memory_usage() 
>> >> : for i in range(2): 
>> >> : R = srange(M) 
>> >> : gc.collect() 
>> >> : print("memory usage 20k:", get_memory_usage(mem)) 
>> >> 434 
>> >> 0 
>> >> memory usage 10k: 884.4296875 
>> >> 0 
>> >> memory usage 20k: 1770.71875 
>> >> 
>> >> On Thursday, 18 March 2021 at 16:01:56 UTC+1 David Joyner wrote: 
>> >> 
>> >>> On Thu, Mar 18, 2021 at 6:56 AM Maarten Derickx <
>> m.derick...@gmail.com> 
>> >>> wrote: 
>> >>> 
>>  Hi All, 
>>  
>>  tldr: the bottom of this post contains example code of which I would 
>>  like 
>>  the results on some other systems. 
>>  
>>  I recently encountered a memory leak in the relatively innocently 
>>  looking 
>>  code: 
>>  
>>  d = 27 
>>  M = 109 
>>  for i in range(1): 
>>   for a 

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

[Volker Braun]

There are way better distributions of R than ours, just install one of 
these and the R interface will still work. In fact, if you rely on R then 
you shouldn't be using the outdated version in Sage...


On Monday, March 8, 2021 at 5:22:12 AM UTC+1 John H Palmieri wrote:

> Dear all,
>
> You should be aware that ticket #31409 (
> https://trac.sagemath.org/ticket/31409) intends to downgrade R to an 
> optional package because of difficulties building it on Cygwin. Just 
> letting you know in case you care about R being part of Sage and/or you 
> have ideas about how to fix the Cygwin build.
>
> (The branch there to downgrade R already has a positive review, by the 
> way. I have no position on this, but I thought that more Sage developers 
> should be aware.)
>
> -- 
> John
>
>
>

-- 
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/00b9f888-094c-4236-9cdd-4f1240d934d9n%40googlegroups.com.

[sage-devel] Re: python3-3.8.5 won't compile under Big Sur

[Volker Braun]

Looks like its #31326, but I posted some details to #30651

On Sunday, March 7, 2021 at 8:16:08 PM UTC+1 Matthias Koeppe wrote:

> Details please -> https://trac.sagemath.org/ticket/30651
>
> On Sunday, March 7, 2021 at 3:16:37 AM UTC-8 Volker Braun wrote:
>
>> For the record, I've set up a BS buildbot at http://build.sagemath.org, 
>> but it currently doesn't succeed in compiling Sage.
>>
>>
>>
>> On Friday, March 5, 2021 at 9:01:51 PM UTC+1 harald@gmail.com wrote:
>>
>>> Hi,
>>>
>>> I've been trying to compile Sage on a Mac running macOS 11.2.2 (Big Sur).
>>> (I first tried to install the binary package, but the process was 
>>> interrupted by 30+ dialog boxes telling me that I had to authorize this and 
>>> that .so because it had been downloaded from an unknown source.)
>>>
>>> Unfortunately, python3-3.8.5 won't compile. First, it claimed gcc it was 
>>> broken - but then, when I did
>>>
>>> export CC=clang
>>>
>>> export CXX=clang++
>>>
>>> I still ran into trouble. I've installed zlib, but that doesn't seem to 
>>> help.
>>>
>>>
>>> See the log file. Thank you in advance for your help!
>>>
>>>
>>> Best
>>>
>>> Harald Helfgott
>>>
>>> University of Goettingen/CNRS
>>>
>>

-- 
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/a8aeee09-ec82-42ab-8384-9c8a1097c960n%40googlegroups.com.

[sage-devel] Re: python3-3.8.5 won't compile under Big Sur

[Volker Braun]

For the record, I've set up a BS buildbot at http://build.sagemath.org, but 
it currently doesn't succeed in compiling Sage.



On Friday, March 5, 2021 at 9:01:51 PM UTC+1 harald@gmail.com wrote:

> Hi,
>
> I've been trying to compile Sage on a Mac running macOS 11.2.2 (Big Sur).
> (I first tried to install the binary package, but the process was 
> interrupted by 30+ dialog boxes telling me that I had to authorize this and 
> that .so because it had been downloaded from an unknown source.)
>
> Unfortunately, python3-3.8.5 won't compile. First, it claimed gcc it was 
> broken - but then, when I did
>
> export CC=clang
>
> export CXX=clang++
>
> I still ran into trouble. I've installed zlib, but that doesn't seem to 
> help.
>
>
> See the log file. Thank you in advance for your help!
>
>
> Best
>
> Harald Helfgott
>
> University of Goettingen/CNRS
>

-- 
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/7453439c-c937-4e11-968f-919e6d69cd85n%40googlegroups.com.

[sage-devel] Re: Correctly re-installing sage from source after removing a prior install from source?

[Volker Braun]

Did you set up global environment variables (like SAGE_ROOT) in you 
previous install? This is not recommended. Whats the output of "env | grep 
SAGE"?



On Saturday, January 9, 2021 at 2:57:55 PM UTC+1 siddu...@gmail.com wrote:

> I'd installed SAGE from source once, and then deleted the folder. I'm now 
> trying to install SAGE again from source, this time at a /different/ 
> location. It builds, and then finally fails with:
>
> 
> [2021-01-09 19:20:11] SageMath version 9.3.beta5, Release Date: 2020-12-27
> ERROR:  The Sage installation tree has moved
>
> from /home/bollu/work/sage
>   to /home/bollu/software/sage
>
> This is not supported, and Sage will not work. To install Sage from a
> binary package:
>
> 1. Open the .tar.bz2 archive (or .dmg on OSX)
>
> 2. Move the SageMath folder/app to where you want it to be. You can
>also rename the directory now.
>
> 3. Start sage for the first time. This will then automatically patch
>paths in binaries.
>
> After starting Sage for the first time you cannot change the
> installation any more. To install Sage elsewhere, start over from the
> binary package. Or recompile Sage from scratch in the new location
> ("make distclean && make")
> --
>
> Unfortunately, I can't follow the instructions because I don't *have* a 
> SageMath install anymore. It seems like some sort of
> specter of the previous installation is still hanging around somewhere. 
>
> How do I actually cleanly install SAGE a second time?
>
> Thanks,
> ~Siddharth
>
>
> -- 
> https://bollu.github.io/
>

-- 
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/96488fc2-7467-44a3-9a66-18f495c40c57n%40googlegroups.com.

[sage-devel] Re: Sage 9.3 release cycle

[Volker Braun]

I think there are pros and cons to looking at the Milestone field; In 
particular, if scripts evaluate it then it must always be set correctly or 
else your ticket is silently ignored forever.  There is certainly a use 
case for deferring tickets, but you can do that already manually by 
depending on another ticket. Plus thats more flexible in that its not tied 
to the release version. 

Is it possible to get the current milestone from the trac xmlrpc api? If 
not then the scripts can't...



On Wednesday, November 11, 2020 at 12:14:45 AM UTC+1 Matthias Koeppe wrote:

> On Tuesday, November 10, 2020 at 2:14:29 PM UTC-8, Matthias Koeppe wrote:
>>
>> I would suggest that we aim for a much shorter release cycle for Sage 9.3 
>> with a focus on the following issues:
>> - macOS 11 Big Sur
>> - critical fixes that were not merged in 9.2
>> - package upgrades that did not make it into 9.2
>> - fixing broken optional packages
>>
>> Perhaps a release date at the end of the month would be possible.
>>
>
> Volker, I am not sure if you are aware of this, but your ticket merging 
> scripts seem to ignore the Milestone set in the trac tickets. I would 
> suggest that this be changed. 
>
> The current process seems to have an abrupt transition from "merging 
> anything that's positively reviewed" to "only merging blocker tickets". 
> Allowing developers to defer a ticket to the next release cycle by setting 
> the Milestone would in my opinion improve release quality.
>
>
>

-- 
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/bc968f1c-515d-4767-b756-a090abe20bc5n%40googlegroups.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[Volker Braun]

On Wednesday, October 21, 2020 at 1:43:43 PM UTC+2 dim...@gmail.com wrote:

> I gather that (ignoring NaNs and +/-infinities) 
> the addition and multiplication are commutative here



Actually not even x+y == x+y is guaranteed and may fail once you let the 
optimizer loose ;)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323


-- 
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/ca1e2497-e7df-43f5-97fc-72d1a837ff33n%40googlegroups.com.

[sage-devel] Re: problems building develop branch

[Volker Braun]

* Download Xcode 11 (distributed as .xip I think, double-click to unpack)
* Rename to Xcode-11.app so it doesn't clash with Xcode.app
* Move to /Applications
* Run "xcode-select -p /Applications/Xcode-11.app/Contents/Developer" to 
switch

On Monday, September 21, 2020 at 6:59:26 PM UTC+2 Matthias Koeppe wrote:

> You can try to downgrade your Xcode command line tools to 11.x, for 
> example using this:
>
>
> https://download.developer.apple.com/Developer_Tools/Command_Line_Tools_for_Xcode_11.5/Command_Line_Tools_for_Xcode_11.5.dmg
>
>
>
> On Monday, September 21, 2020 at 9:14:11 AM UTC-7 anne1.s...@gmail.com 
> wrote:
>
>> Ok, thanks for letting me know. Does that mean I can now not work on 
>> tickets that are based on the latest develop branch?
>>
>> Anne
>>
>> On Monday, September 21, 2020 at 8:58:18 AM UTC-7 Matthias Koeppe wrote:
>>
>>> Hi Anne,
>>> This is from the new Xcode 12 that probably came with a system update.
>>> https://trac.sagemath.org/ticket/30494 tracks the progress of fixing 
>>> Sage to support the new Xcode version.
>>> Matthias
>>>
>>>
>>> On Monday, September 21, 2020 at 8:51:35 AM UTC-7 anne1.s...@gmail.com 
>>> wrote:
>>>

 Dear All,

 I am having trouble again to build the latest develop branch on MacOS 
 10.15.6. The log files can be found at 

 https://www.math.ucdavis.edu/~anne/config.log
 https://www.math.ucdavis.edu/~anne/gf2x-1.3.0.log

 Best wishes,

 Anne




-- 
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/443c75fa-d2dd-40c4-aacb-ba5ac01ff859n%40googlegroups.com.

[sage-devel] Re: line length in docstring and tests

[Volker Braun]

I'm with Linus in that the 80 characters limit is an anachronism thats too 
restrictive in a time and age where large high-resolution displays are 
ubiqitous. There certainly is a "too long" somewhere but its more in the 
100-character region.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144

-- 
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/a718bd44-6b38-4da3-9df8-7e8e23121cd8%40googlegroups.com.

[sage-devel] Re: New Python version requirement for Sage?

[Volker Braun]

Thats true, I'll fix it


On Monday, June 1, 2020 at 11:08:36 PM UTC+2, Jonathan Kliem wrote:
>
> At the moment we are guessing that kucalc buildbot runs with ./configure 
> --with-python=2, because this will lead to exactly this error message (and 
> it really is the only way that this error message makes sense, because this 
> module is present in python 3.5.2 and the import error doesn't make any 
> sense).
>
> Can someone verify/change that or contact someone who will do so?
>
> Am Freitag, 29. Mai 2020 01:22:54 UTC+2 schrieb Matthias Koeppe:
>>
>> On Thursday, May 28, 2020 at 12:15:33 PM UTC-7, Volker Braun wrote:
>>>
>>> Another datapoint is that the kucalc buildbot runs on Ubuntu 16.04 LTS 
>>> which has Python 3.5.2
>>>
>>
>> I see you opened a ticket for a https://trac.sagemath.org/ticket/29753 
>>
>> It would be good if you could provide substantially more information 
>> about that build.
>>
>>
>>

-- 
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/3e3ec925-cb49-4534-ac34-593efef13deb%40googlegroups.com.

[sage-devel] Re: New Python version requirement for Sage?

[Volker Braun]

Another datapoint is that the kucalc buildbot runs on Ubuntu 16.04 LTS 
which has Python 3.5.2

-- 
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/bb742f39-0093-4bdd-867c-52b47feec9ca%40googlegroups.com.

[sage-devel] New Python version requirement for Sage?

[Volker Braun]

Which python versions do we want to be compatible with now? Please separate 


A) Supported Python versions for building Sage

Note that I'm already seeing f-strings in #29547 so unless a policy is 
formulated real soon the de-facto answer is going to be Python 3.6+


B) Supported Python versions for running Sage

The default answer for B) is whatever is 
in build/pkgs/python3/package-version.txt, of course

-- 
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/94cfccfd-aba2-467e-adbf-646e0889fa87%40googlegroups.com.

Re: [sage-devel] Error Building Sage

[Volker Braun]

Python picks up the wrong readline, is there stuff in /usr/local?



On Sunday, February 23, 2020 at 8:23:42 AM UTC+1, Tanav Shah wrote:
>
> Hi
>
> I tried building the sage module in the internal wsl file system and it 
> seems to be working better than before, but still there are a couple of 
> errors. It says
>
> The following package(s) may have failed to build (not necessarily
> during this run of 'make all-start'):
>
> * package: gap-4.10.2.p1
>   log file: /home/tanav/sage-9.0/logs/pkgs/gap-4.10.2.p1.log
>   build directory: 
> /home/tanav/sage-9.0/SAGE_LOCAL/var/tmp/sage/build/gap-4.10.2.p1
>
> * package: python3-3.7.3.p1
>   log file: /home/tanav/sage-9.0/logs/pkgs/python3-3.7.3.p1.log
>   build directory: 
> /home/tanav/sage-9.0/SAGE_LOCAL/var/tmp/sage/build/python3-3.7.3.p1
>
> After this it terminates building. I have attached the log files here. Can 
> you please help me out with this?
>
> Thanks in advance.
>
> Tanav Shah
>
> On Sunday, February 23, 2020 at 4:50:33 AM UTC+5:30, Volker Braun wrote:
>>
>> I've built Sage in WSL before, its really a pretty standard Ubuntu.
>>
>> OP's problem is that he's building it on /mnt/c/, the mounted windows 
>> filesystem. That one is not POSIX so there is little chance. You have to 
>> build it on the internal WSL filesystem, which is fully POSIX compatible.
>>
>>
>>
>> On Saturday, February 22, 2020 at 8:17:26 PM UTC+1, Dima Pasechnik wrote:
>>>
>>> I don't think anyone managed to build Sage on WSL.
>>>
>>>
>>> On Sat, 22 Feb 2020, 19:47 Tanav Shah,  wrote:
>>>
>>>> Hi
>>>>
>>>> I have downloaded the source code for SageMath from 
>>>> https://www.sagemath.org/download-source.html and am willing to 
>>>> contribute for the same. I have been following the steps provided in this 
>>>> page 
>>>> http://doc.sagemath.org/html/en/installation/source.html#prerequisites, 
>>>> but am getting an error while building.
>>>>
>>>> When running the 'make' command, I get an error that "[arb-2.16.0.p0] 
>>>> spkg-install should not be marked executable in the build/pkgs directory" 
>>>> and it displays "Error building Sage". I have been trying to find a 
>>>> solution to it but have not found one. I am working on HP-SPECTRE with 
>>>> Windows-10 Home installed in it. I am using Windows Subsytem for 
>>>> Linux(WSL) 
>>>> Ubuntu 18.04 LTS for executing the commands. I have attached the error log 
>>>> files.
>>>>
>>>> Can someone please help me solve this issue?
>>>>
>>>> Thanks in advance,
>>>> Tanav Shah
>>>>
>>>> -- 
>>>> 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-...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/sage-devel/cd9d5155-d82b-4e99-9b65-654d423c6671%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/sage-devel/cd9d5155-d82b-4e99-9b65-654d423c6671%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>

-- 
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/50f75886-e7bb-4fe3-a50a-7ba0aa3f5c76%40googlegroups.com.

Re: [sage-devel] Error Building Sage

[Volker Braun]

I've built Sage in WSL before, its really a pretty standard Ubuntu.

OP's problem is that he's building it on /mnt/c/, the mounted windows 
filesystem. That one is not POSIX so there is little chance. You have to 
build it on the internal WSL filesystem, which is fully POSIX compatible.



On Saturday, February 22, 2020 at 8:17:26 PM UTC+1, Dima Pasechnik wrote:
>
> I don't think anyone managed to build Sage on WSL.
>
>
> On Sat, 22 Feb 2020, 19:47 Tanav Shah, > 
> wrote:
>
>> Hi
>>
>> I have downloaded the source code for SageMath from 
>> https://www.sagemath.org/download-source.html and am willing to 
>> contribute for the same. I have been following the steps provided in this 
>> page 
>> http://doc.sagemath.org/html/en/installation/source.html#prerequisites, 
>> but am getting an error while building.
>>
>> When running the 'make' command, I get an error that "[arb-2.16.0.p0] 
>> spkg-install should not be marked executable in the build/pkgs directory" 
>> and it displays "Error building Sage". I have been trying to find a 
>> solution to it but have not found one. I am working on HP-SPECTRE with 
>> Windows-10 Home installed in it. I am using Windows Subsytem for Linux(WSL) 
>> Ubuntu 18.04 LTS for executing the commands. I have attached the error log 
>> files.
>>
>> Can someone please help me solve this issue?
>>
>> Thanks in advance,
>> Tanav Shah
>>
>> -- 
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/cd9d5155-d82b-4e99-9b65-654d423c6671%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/fbf2ef82-1e8d-4994-bfd4-d4e683f4f67d%40googlegroups.com.

[sage-devel] Re: drop python2 compatibility in 9.1 ?

[Volker Braun]

* I think its not too difficult to write code that is Python 2.7 + 3.x (for 
high enough x) compatible, so its not a super pressing issue
* We do have a Python 2 buildbot to test for regressions
* For semver reasons we should drop Python 2.7 support in Sage 10, not 9.1

Having said that, I'm fine with an accelerated Sage 9 -> Sage 10 schedule, 
maybe a month or two instead of the usual 3-4. Though first we should take 
the opportunity and see if there are any outstanding Python 3 bugs now that 
we have more data. For example it would be nice if a build with 
SAGE_DEBUG=yes would pass tests. There are a few more regressions, e.g. 
#28817


-- 
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/4e7cd06a-2d73-4530-b235-d4f675cd9cbd%40googlegroups.com.

[sage-devel] Re: Buiding sage on a Raspberry Pi 4B

[Volker Braun]

Which hardware are you using, and how long does it take to bulid and run 
the tests?

On Tuesday, December 31, 2019 at 12:14:28 AM UTC+1, Timo Kaufmann wrote:
>
> For what it's worth, I regularly build and test sage-on-nixos on aarch64. 
> The testsuite shows no issues, except some transient timeouts which may or 
> may not be caused by the architecture.
>

-- 
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/47b989f5-6156-445d-8e9a-381dc4cd7aa5%40googlegroups.com.

[sage-devel] Re: Sage 8.9 build fails on macOS Catalina

[Volker Braun]

The OSX code signing is a major annoyance. We can't notarize our binaries 
since we rewrite paths to shared libraries on start. But that modifies the 
binary and invalidates any signature. I think we can clear the quarantine 
flag, so you'd only get the gatekeeper warning dialog once. Maybe one of 
you can try out if this works, just run

xattr -rd com.apple.quarantine /path/to/sage

to recursively clear the quarantine flag. After that sage should start 
fine...




On Saturday, December 21, 2019 at 4:40:34 PM UTC+1, Clayton Cafiero wrote:
>
> macOS Catalina 10.15.2 (19C57)
>
> Tried downloading and installing binary (sage-8.9-OSX_10.14.6-x86_64.dmg) 
> but when run macOS complained bitterly about every file Sage tried to load 
> when starting with
>
> “python2.7” cannot be opened because the developer cannot be verified."
>
>
> If I use System Preferences > Security & Privacy to allow python2.7, then 
> another warning appears:
>
>
> “libpython2.7.dylib” cannot be opened because the developer cannot be 
> verified."
>
>
> ...I had patience for about the first 100 files (_locale.so, zlib.so, 
> _collections.so, blah, blah, blah), then I threw in the towel and tried to 
> build.
>
> % xcodebuild -version   
> Xcode 11.2
> Build version 11B52
>
> Downloaded Sage 8.9 source from mirror. Followed instructions in 
> README.md, specifically
>
> * __OS X:__
>* Make sure you have installed the most recent version
>of Xcode which you can install for free from the App Store.
>* You also need to install the "command line tools". When
>using OS X Mavericks, after installing Xcode, run
>`xcode-select --install` from a terminal window:
>Then click "Install" in the pop-up window.
>When using OS X Mountain Lion or earlier, you need to install the
>command line tools from Xcode: run Xcode; then from the File
>menu, choose "Preferences", then the "Downloads" tab, and then
>"Install" the Command Line Tools. You might also have Homebrew or
>a similar "Apple's missing package manager" system installed, with
>and libraries such gfortran, gmp, etc installed. (However, this
>is still experimental as of May 2019).
>
> ...
>
> Extract the tarball
>
>tar zxvf sage-*.tar.gz
>
> cd into the Sage directory and type make
>
>cd sage-*/
>make
>
> This ran for quite a while and then failed, informing me to 
> check /Users/myname/Downloads/sage-8.9/logs/pkgs/gfortran-7.4.0.log for 
> more information. This file has over 500k lines and ends with
>
> ../../../src/libssp/gets-chk.c:59:13: error: storage class specified for 
> parameter '__chk_fail'
>  extern void __chk_fail (void) __attribute__((__noreturn__));
>  ^~
> ../../../src/libssp/gets-chk.c:63:1: error: expected '=', ',', ';', 'asm' 
> or '__attribute__' before '{' token
>  {
>  ^
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h:110:0,
>  from 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:66,
>  from ../../../src/libssp/gets-chk.c:39:
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:447:9:
>  
> error: old-style parameter declarations in prototyped function definition
>  int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, 
> __IPHONE_2_0);
>  ^~
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:447:1:
>  
> error: parameter name omitted
>  int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, 
> __IPHONE_2_0);
>  ^~~
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:447:1:
>  
> error: parameter name omitted
> ../../../src/libssp/gets-chk.c:92:1: error: expected '{' at end of input
>  }
>  ^
> ../../../src/libssp/gets-chk.c:92:1: warning: control reaches end of 
> non-void function [-Wreturn-type]
>  }
>  ^
> make[7]: *** [gets-chk.lo] Error 1
> make[6]: *** [all] Error 2
> make[5]: *** [all-target-libssp] Error 2
> make[4]: *** [all] Error 2
>
> 
> Error building gfortran-7.4.0
>
> 
>
> Zip of this complete file is attached. 
>
> Any suggestions? Please advise. TYVVM.
>
>
>
>
>

-- 
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 

Re: [sage-devel] Re: OSX Catalina works

[Volker Braun]

Patch gcc, see: see https://trac.sagemath.org/ticket/28691

On Monday, November 4, 2019 at 11:34:48 AM UTC+1, Dima Pasechnik wrote:
>
> in view of problems with building gcc/gfortran on osx 10.15 and latest 
> Xcode, one must wonder what Homebrew does to make it work.
> Do they patch system headers, or something like that?
>

-- 
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/59a143d4-8282-480e-a165-b0aca1e69bdc%40googlegroups.com.

Re: [sage-devel] MacOS 10.15.1: gfortran does not compile in sage-8.9

[Volker Braun]

Xcode 11 contains once again broken system headers so compiling any version 
of gcc/gfortran fails. This is 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835

Xcode 11 is now also pushed to Mojave so OSX 10.14 is now broken as well. 

Presumably you can work around it by manually installing Xcode 10 (and the 
corresponding commandline tools)

I've made https://trac.sagemath.org/ticket/28691 to track this issue.

-- 
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/9541b07a-4a91-409c-a27d-d6841923606f%40googlegroups.com.

[sage-devel] Switch to Python 3 by default

[Volker Braun]

Maybe I missed it, but I didn't find a ticket for that. I think now would 
be a good time to flip the switch, though. Any thoughts?

-- 
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/ecedb76c-c6ab-4f7c-9ce5-9c2781b8ce79%40googlegroups.com.

[sage-devel] Re: OSX Catalina works

[Volker Braun]

Means: I successfully compiled Sage 8.9 on OSX Catalina with Xcode 11.0 



On Sunday, October 13, 2019 at 9:24:44 PM UTC+2, Samuel Lelievre wrote:
>
> Sun 2019-10-13 08:26:52 UTC, Volker Braun:
>>
>> I just upgraded the OSX buildbot and Sage works
>>
> in case anybody is wondering. This is the first time in years
>>
> that the latest OSX release doesn't introduce major toolchain
>>
> issues and/or scrambles the filesystem, hope this starts a trend ;-) 
>>
>
> That's good to hear, and there were people wondering.
> See for instance this question on Ask Sage about SageMath
> and macOS 10.15 "Catalina":
>
> - How to unlock SageMath 8.8 on macOS 10.15 Catalina?
>   https://ask.sagemath.org/question/48293
>
> By "Sage works" do you mean any of the following?
>
> - there are / there will be binaries for macOS 10.15 "Catalina"
> - the SageMath 8.9 binaries for macOS 10.14 "Mojave"
>   also work for macOS 10.15 "Catalina"
> - on macOS 10.15 "Catalina" building SageMath 8.9 from
>   source gives a version that works and is not "locked"
>
>
>

-- 
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/d548d18b-f696-4f77-81f9-86a3dfa967bc%40googlegroups.com.

Re: [sage-devel] Error installing scipy-1.2.0 when compiling sage math 9.0.beta1

[Volker Braun]

I just tried the latest Xcode and gfortran fails to build for me, too...

>
>>

-- 
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/ec70de61-0ee2-4c9a-ba85-574c1bd53938%40googlegroups.com.

[sage-devel] OSX Catalina works

[Volker Braun]

I just upgraded the OSX buildbot and Sage works in case anybody is 
wondering. This is the first time in years that the latest OSX release 
doesn't introduce major toolchain issues and/or scrambles the filesystem, 
hope this starts a trend ;-) 

-- 
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/069eafdb-e5c7-42cc-a72d-d9ff11b1bf53%40googlegroups.com.

[sage-devel] Re: Static libraries

[Volker Braun]

IMHO its a bug to have static libraries in any sort of maintainable 
distribution, besides the wasted disk space its also an unnecessary 
headache to understand the binary dependencies. There is some theoretical 
performance increase, but if you are really chasing the last few percentage 
points then you'll want to build everything with your own optimized 
compiler flags anyways. 


On Thursday, October 10, 2019 at 5:26:29 PM UTC+2, Marc Mezzarobba wrote:
>
> Hi, 
>
> Maybe a stupid question, but: does Sage really need to build all 
> these static libraries? Why? 
>
> 456M./local/lib/libgiac.a 
> 144M./local/lib/libec.a 
> 120M./local/lib/libppl_c.a 
> 107M./local/lib/libpari.a 
> 69M ./local/lib/libppl.a 
> 48M ./local/lib/libsymmetrica.a 
> 31M ./local/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.a 
> 24M ./local/lib/libgsl.a 
> 16M ./local/lib/python2.7/config/libpython2.7.a 
> 16M ./local/lib/libsqlite3.a 
> 16M ./local/lib/libfplll.a 
> 7,7M./local/lib/ecl-16.1.2/libcmp.a 
> 7,5M./local/lib/libbraiding.a 
> 5,9M./local/lib/libSingular.a 
> 5,4M./local/lib/libyasm.a 
> 4,5M./local/lib/ecl-16.1.2/libasdf.a 
> 3,7M./local/lib/libfactory.a 
> 3,1M./local/lib/libecm.a 
> 2,3M./local/libexec/singular/MOD/gfanlib.a 
> 2,2M./local/lib/libpolys.a 
> 2,2M./local/lib/libgslcblas.a 
> 1,6M./local/lib/libgfan.a 
> 1,6M./local/lib/libgc.a 
> 1,6M./local/lib/libcddgmp.a 
> 1,1M./local/lib/libiml.a 
> 1,1M./local/lib/libgd.a 
> 900K./local/lib/libplanarity.a 
> 880K./local/lib/ecl-16.1.2/libdefsystem.a 
> 796K./local/lib/libcdd.a 
> 564K./local/lib/ecl-16.1.2/libdeflate.a 
> 536K./local/lib/libgivaro.a 
> 472K./local/share/gap/pkg/SmallGrp-1.3/small8/sml1536.a 
> 448K./local/lib/ecl-16.1.2/libsockets.a 
> 372K./local/share/gap/pkg/SmallGrp-1.3/small6/sml1152.a 
> 364K./local/share/gap/pkg/SmallGrp-1.3/small6/sml1920.a 
> 344K./local/lib/python2.7/site-packages/numpy/core/lib/libnpymath.a 
> 320K./local/lib/libomalloc.a 
> 292K./local/lib/liblrcalc.a 
> 232K./local/lib/ecl-16.1.2/libecl-help.a 
> 204K./local/libexec/singular/MOD/gitfan.a 
> 200K./local/share/gap/pkg/SmallGrp-1.3/small7/sml512.a 
> 200K./local/lib/ecl-16.1.2/libprofile.a 
> 184K./local/lib/ecl-16.1.2/librt.a 
> 180K./local/lib/libcord.a 
> 176K./local/lib/libratpoints.a 
> 172K./local/lib/libhomfly.a 
> 172K./local/lib/ecl-16.1.2/libecl-cdb.a 
> 168K./local/libexec/singular/MOD/cohomo.a 
> 140K./local/lib/ecl-16.1.2/libecl-curl.a 
> 132K./local/lib/ecl-16.1.2/libserve-event.a 
> 132K./local/lib/ecl-16.1.2/libql-minitar.a 
> 124K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1728.a 
> 124K./local/libexec/singular/MOD/Order.a 
> 120K./local/share/gap/pkg/SmallGrp-1.3/small2/sml896.a 
> 116K./local/share/gap/pkg/SmallGrp-1.3/small2/sml640.a 
> 116K./local/libexec/singular/MOD/syzextra.a 
> 112K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1600.a 
> 112K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1344.a 
> 108K./local/share/gap/pkg/SmallGrp-1.3/small2/sml960.a 
> 104K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1440.a 
> 100K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1944.a 
> 100K./local/share/gap/pkg/SmallGrp-1.3/small2/sml384.a 
> 96K ./local/share/gap/pkg/SmallGrp-1.3/small5/sml1296.a 
> 96K ./local/share/gap/pkg/SmallGrp-1.3/small2/sml576.a 
> 96K ./local/share/gap/pkg/SmallGrp-1.3/small2/sml256.a 
> 96K ./local/lib/ecl-16.1.2/libecl-quicklisp.a 
> 92K ./local/share/gap/pkg/SmallGrp-1.3/small2/sml864.a 
> 72K ./local/share/gap/pkg/SmallGrp-1.3/small3/sml768.a 
> 72K ./local/lib/ecl-16.1.2/libsb-bsd-sockets.a 
> 64K ./local/libexec/singular/MOD/pyobject.a 
> 44K ./local/libexec/singular/MOD/interval.a 
> 32K ./local/lib/libatomic_ops_gpl.a 
> 28K ./local/lib/libsingular_resources.a 
> 24K ./local/lib/librw.a 
> 24K ./local/lib/libatomic_ops.a 
> 16K ./local/share/gap/pkg/SmallGrp-1.3/id3/id768.a 
> 12K ./local/share/gap/pkg/SmallGrp-1.3/id5/id1344.a 
> 12K ./local/libexec/singular/MOD/python_module.a 
> 12K ./local/libexec/singular/MOD/bigintm.a 
> 8,0K./local/share/gap/pkg/SmallGrp-1.3/id2/id832.a 
> 8,0K./local/share/gap/pkg/SmallGrp-1.3/id2/id800.a 
> 8,0K./local/share/gap/pkg/SmallGrp-1.3/id2/id576.a 
> 8,0K./local/libexec/singular/MOD/customstd.a 
> 4,0K./local/share/gap/pkg/SmallGrp-1.3/id10/id46620.a 
> 4,0K./local/share/cliquer/testcase-small.a 
> 4,0K./local/libexec/singular/MOD/singmathic.a 
> 4,0K./local/libexec/singular/MOD/polymake.a 
>
> -- 
> Marc 
>
>

-- 
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 

[sage-devel] Re: Access to macOS computer

[Volker Braun]

I can make an account on the buildbot worker, send me the name and ssh 
public key (I don't have Isuru's email address)



On Sunday, September 15, 2019 at 10:47:58 PM UTC+2, Samuel Lelievre wrote:
>
> Dear sage-devel, 
>
> Can anyone give Isuru Fernando access to a macOS computer so 
> he can debug package dependencies for the conda packaging of 
> Sage? While the Linux conda package built fine, there's an issue 
> with the macOS package dependencies for SageMath 8.9.rc0. 
>
> Samuel 
>

-- 
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/91e1682e-44c5-4eae-bd3e-59b69bfd50b5%40googlegroups.com.

Re: [sage-devel] Resolution of singularities

[Volker Braun]

The toric version is also natively in Sage, e.g. 
http://doc.sagemath.org/html/en/reference/schemes/sage/schemes/toric/morphism.html


On Friday, August 23, 2019 at 9:11:05 AM UTC+2, Dima Pasechnik wrote:
>
> On Fri, Aug 23, 2019 at 3:55 AM Dan Abramovich  > wrote: 
> > a student of mine, Jonghyun Lee, will be coding the resolution of 
> singularities algorithm of the 
> > 
> > paper 
> > 
> > 
> > https://arxiv.org/abs/1906.07106 
> > 
> > 
> > as part of his senior thesis. He is working in sage (that's what he 
> chose!). 
> > 
> > 
> > two questions: 
> > 
> > 
> > 1. Are there packages in sage parallel to those available in Singular or 
> Macaulay? 
>
> Singular has an efficient interface to Sage, so normally one would 
> create a Sage interface to a Singular 
> package rather than an independent implementation. 
>
> The interface to Macaulay2 is on the other hand pretty basic and slow, 
> so it might be 
> different for Macaulay2. 
>
> What kind of functionality of Sage is needed for the project which is 
> not in Singular? 
>
> A more efficient way might be to implement the algorithm in Singular 
> (or Macaulay2) and then 
> expose in in Sage, rather than spend time fighting the interfaces. 
>
>
> > 
> > 
> > 2. Is there any existing resolution of singularities package? Anyone 
> else working on similar projects? 
>
> I know about 
>
> 1) resolution of some kind of toric singularites package in Macaulay2 
>
> 2) resolution of surface singularites in Singular 
> https://www.singular.uni-kl.de/Manual/latest/sing_934.htm#SEC986 
>
> HTH 
> Dima 
> > 
> > Best, 
> > 
> > 
> > - Dan Abramovich 
> > 
> > 
> > -- 
> > 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-...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/7aa65e37-f8ae-41ac-9afd-2ee6c8c92a92%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/37163308-d1ab-48c2-aaa5-96b2ab7f0155%40googlegroups.com.

Re: [sage-devel] save/loads and the pickle jar

[Volker Braun]

Not to be confused with Another System Definition Facility, the de facto 
standard build facility for Common Lisp

-- 
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/76da8353-7131-4c18-b2c3-a7b47bd5a0f2%40googlegroups.com.

[sage-devel] Re: Failing to build documentation

[Volker Braun]

Looks like a race condition, does

SAGE_NUM_THREADS=1 sage --docbuild reference html

work?

On Saturday, July 6, 2019 at 7:14:51 PM UTC-4, Matt (trac: gh-Torrencem) 
wrote:
>
> Hi, I'm running Ubuntu and Sage 8.9 (also tried with 8.8), and whenever I 
> try building the documentation using "sage --docbuild reference html", I 
> get a failure with the message:
>
> ...
> [manifolds] Exception occurred:
> [manifolds]   File "/home/[...]/sage/local/lib/python2.7/os.py", line 157, 
> in makedirs
> [manifolds] mkdir(name, mode)
> [manifolds] OSError: [Errno 17] File exists: 
> '/home/[...]/sage/local/share/doc/sage/html/en/reference/manifolds/_static'
> ...
>
> Which eventually terminates the entire build (or replacing manifolds with 
> whatever particular module's documentation I'm trying to build)
>
> This happens when building the documentation for any module under reference
>
> I've tried "make doc-clean" several times, and even re-build all of Sage 
> when upgrading to 8.9 (which went fine), and I still get the same error 
> with "sage --docbuild". Googling the "_static" problem seems to have turned 
> up several past issues in Sage that have since been fixed. I've attached 
> the log file output from the failed build process ([...] is the path to my 
> sage installation, which has no other problems). Any ideas on how to get it 
> working would be much appreciated!
>
> Matt
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e105ec99-61af-424d-b771-06d62bd8abe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: patchbot security

[Volker Braun]

The patchbot configuration has some options for trusting specific user 
accounts.

Having said that, you are correct in that it executes code submitted by 
strangers over the internet. At the very least make a separate user account 
for running the patchbot. You might want to add an additional container / 
vm layer.



On Saturday, July 6, 2019 at 4:20:09 AM UTC-4, Jonathan Kliem wrote:
>
> Hi,
>
> I'm wondering what safety measures are taken for distributing code to the 
> patchbot clients.
>
> E.g. if I where to register a new github account and create a ticket that 
> uploads all files from the user to a server of my choice (maybe via a 
> malicous doctest), is that ticket still going to be distributed to patchbot 
> clients?
>
> I guess the underlying question is, what security measures are recommended 
> before running a patchbot. On https://wiki.sagemath.org/patchbot I cannot 
> find anything.
>
> Jonathan
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/51233fce-98dc-46b9-b643-5e912a994bf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Fail to build openblas -- sage 8.8 on debian 9

[Volker Braun]

I've created https://trac.sagemath.org/ticket/28104 for this issue

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4b7620ad-c152-4c6e-a762-d4352f6afb54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Fail to build openblas -- sage 8.8 on debian 9

[Volker Braun]

Works on the buildbot. The log looks hardware specific. Which cpu is this?



On Wednesday, July 3, 2019 at 6:56:31 AM UTC-4, Jan Groenewald wrote:
>
> Attached logs
>
> -- 
>   .~. 
>   /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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/227b983b-1c52-4a0e-830d-68db770b7c06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: A question on pickling cached methods

[Volker Braun]

There is the do_pickle argument, e.g. from TFM:

sage: class C:
: @cached_method(do_pickle=True)
: def __hash__(self):
: return id(self)


Note that it can cause the following problem: Not every circularly 
dependent collection of cython objects can be pickled. Cached values can 
make the difference between what can an cannot be pickled. So whether or 
not pickling works can't reliably be tested in that case. 


On Thursday, June 27, 2019 at 5:07:04 AM UTC+2, Kwankyu Lee wrote:
>
> Hi,
>
> Suppose I have an object X. I computed X.genus(), which took a long time. 
> The method genus() is a cached method. So it gives the result quickly next 
> time. Then I saved the object X. After loading X in a new session, I want 
> X.genus() to give the cached result rather than computing it again.
>
> Is it possible to implement genus() to behave in such a way? Is there some 
> option to @cached_method decorator for that purpose?
>
> I am reading the code for cached methods, but you answer will help me. 
> Thanks.
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9b2c316e-b601-4e14-af28-0eef2cb4d189%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Installation gets stuck when it tries to download zeromq-4.2.5.tar.gz

[Volker Braun]

The url in the screenshot 
http://mirrors.mit.edu/sage/spkg/upstream/zeromq/zeromq-4.2.5.tar.gz works 
for me, you can try downloading it from within your VM to exclude any 
networking issues.


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f04bbc1f-560f-4b4e-8742-7523c99b590d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] avx512 anyone? (Skylake-X or later)

[Volker Braun]

Thanks! AVX512 dgemm is indeed currently disabled on OpenBLAS.


On Saturday, June 15, 2019 at 9:15:19 PM UTC+2, Clement Pernet wrote:
>
> Hi,
> I just successfully compiled and tested upstream develop (at 
> 8df690fd2a4e7a0c36e7dbc05c22d4d977217065 ) on a Intel(R) Xeon(R) Gold 6126 
> CPU @ 2.60GHz server with AVX512.
> All tests passed.
> Is there any specific compilation to test for #27961 ?
> I'll give a look at the ticket later on.
> As a side note, OpenBLAS dgemm is still disapointing in terms of 
> performance on this machine, which make me think that they disabled some 
> AVX512 specific kernels.
>
> Clément
>
> Le sam. 15 juin 2019 à 10:50, Volker Braun  > a écrit :
>
>> Has anybody except for John Palmieri tested the latest Sage beta releases 
>> on a machine with avx512 support? I.e. at least Core i7 7820X (the X being 
>> important):
>>
>> https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
>>
>> Trying to get some data for https://trac.sagemath.org/ticket/27961
>>
>> -- 
>> 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-...@googlegroups.com .
>> To post to this group, send email to sage-...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/sage-devel.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/37f6cff5-f134-47fd-b88b-9045aa75b396%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/37f6cff5-f134-47fd-b88b-9045aa75b396%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/fedee8c6-e381-4904-b83e-c2ceeb7107d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] avx512 anyone? (Skylake-X or later)

[Volker Braun]

Has anybody except for John Palmieri tested the latest Sage beta releases 
on a machine with avx512 support? I.e. at least Core i7 7820X (the X being 
important):

https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

Trying to get some data for https://trac.sagemath.org/ticket/27961

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/37f6cff5-f134-47fd-b88b-9045aa75b396%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Apple deprecates Python

[Volker Braun]

In their ongoing war against general computation, Apple has announced that 
they deprecate (and presumably eventually remove) a Python interpreter from 
OSX. 

Python is a dependency of the Sage binaries (for rewiting paths) and also 
for building Sage.

The easiest solution is probably to let people first manually install 
python, though thats not exactly user-friendly for the binaries...

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/243e1b85-f5ec-45a5-956a-0ff4018ffbe9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Continuous benchmarking

[Volker Braun]

Any kind of shared cpu container solution like openstack is also going to 
be unsuitable for benchmarking, I think. There is going to be lots of 
background stuff that the test process has no control / visibility of. 



On Friday, May 31, 2019 at 5:31:22 PM UTC+2, E. Madison Bray wrote:
>
> On Thu, May 30, 2019 at 8:07 AM Samuel Lelièvre 
> > wrote: 
> > 
> > Dear sage-devel, 
> > 
> > This blog post on continuous benchmarking looks interesting! 
> > 
> > 
> https://medium.com/@wolfv/building-an-open-source-continuous-benchmark-system-717839093962
>  
> > 
> > There have been related discussions on this list in the past, 
> > for example around airspeed velocity: 
> > 
> > 
> https://groups.google.com/forum/#!searchin/sage-devel/airspeed$20velocity%7Csort:date
>  
>
> I agree of course per previous discussions about it.  It would be nice 
> to have the infrastructure to do continuous *anything* outside the 
> Sage buildbots. 
>
> I've all but given up on Paris-Sud's OpenStack infrastructure. 
> Everything I try to do with it regarding CI (be it the Cygwin 
> buildbot, or gitlab runners) breaks constantly and I don't think it's 
> anything I'm doing wrong.  E.g. recently (within the last few weeks) 
> they seem to have fiddled with some firewall rules such that now it 
> terminates long-running TCP/IP connections.  At least, that's my 
> guess.  I haven't been able to investigate thoroughly yet but it's 
> basically causing all my CI processes to lose connections with their 
> master servers mid-build. 
>
> We need reliable infrastructure for Sage builds. 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7f24486d-8295-44e7-ab7f-fd99f88c4ff7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: r-3.6.0 unable to download due to a libcurl issue

[Volker Braun]

Its picking up /anaconda3/bin/curl-config and that one is too old. Either 
update or move it out of the way to build R

On Saturday, May 25, 2019 at 9:26:46 PM UTC+2, Anna Chlopecki wrote:
>
> I am running into an issue with r-3.6.0 not being able to download due to 
> a libcurl issue. My libcurl is the 7.64.1 version, yet it still seems to 
> fail the libcurl test. Can anyone help? I have attached my log file. 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/aacc5e68-2491-499d-9fdf-3813d3a5cd28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: show() method for all sage objects

[Volker Braun]

If you find yourself typing show() all the time you probably want to change 
the displayhook to typeset stuff, i.e.  you want "%display typeset" in the 
notebook or on the command line:

sage: m = random_matrix(ZZ, 3)
sage: m
[12 -5  6]
[ 1 -1  1]
[-1  2  1]
sage: %display unicode_art
sage: m
⎛12 -5  6⎞
⎜ 1 -1  1⎟
⎝-1  2  1⎠

In general, I would lean more on the side of reasonable defaults (e.g. why 
is %display typeset not the default in the notebook, its easier for power 
users to turn it off than for novices to turn it on) than a proliferation 
of more display-related methods.



On Sunday, May 19, 2019 at 1:29:58 AM UTC+2, Kwankyu Lee wrote:
>
> Hi,
>
> How about adding show() method to the class of sage objects, so that we 
> can do
>
> mat.transpose().show()
>
> instead of
>
> show(mat.transpose())
>
> which is cumbersome to add to and remove from mat.transpose()? This is 
> useful in Jupyter notebook.
>
>
> Kwankyu
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/219017e2-ba73-4d5a-b727-c8d2b3f9076d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: gcc 9.1 ?

[Volker Braun]

gcc9 in fedora 30 apparently miscompiles bcache

https://fedoraproject.org/wiki/Common_F30_bugs#Upgrade_bcache_based_systems_to_Fedora_30_may_result_in_severe_storage_corruption

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7164fb65-f8e5-4b45-91b7-e612e15fd0f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: python3 status report (mi-april of last python2 year)

[Volker Braun]

On Saturday, April 20, 2019 at 8:41:34 PM UTC+2, vdelecroix wrote:
>
> Shouldn't we implement that only as a IPython hook as well then? 
>

The displayhook override is really just a hack since the plain python 
output can't be changed, whereas Sage can generate nice output by default. 
So IMHO no, just do the right thing in _repr_.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: python3 status report (mi-april of last python2 year)

[Volker Braun]

On Saturday, April 20, 2019 at 1:10:28 AM UTC+2, Andrew wrote:
>
> Set(['a', 'b', 'c'])
> gives different output with each sage session, at least when `sage` is 
> compiled with python3.
>

Ideally Set._repr_ would try to sort the set members (falling back to 
alphabetical order if the elements can't be compared). This is how the 
plain-python set() works; The set members are unordered but the IPython 
displayhook will sort them to obtain nicer output:

$ python
[...]
>>> set([1,2,320,6,210])
{320, 1, 2, 6, 210}
$ ipython
[...]
In [1]: set([1,2,320,6,210])
Out[1]: {1, 2, 6, 210, 320}

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: building doc: u'\xe9' in position 19: ordinal not in range(128)

[Volker Braun]

Can you change the offending line to

self._stream.write(line.encode('utf-8'))



On Friday, April 19, 2019 at 4:09:00 PM UTC+2, vdelecroix wrote:
>
> Dear all, 
>
> I freshly cloned and compile SageMath. Everything went fine until the 
> documentation where each time sphinx tries to write something I see 
>
> [dochtml] Traceback (most recent call last): 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 287, in write 
> [dochtml] self._write(str) 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 261, in _write 
> [dochtml] self._log_line(line) 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 227, in _log_line 
> [dochtml] self._stream.write(line) 
> [dochtml] UnicodeEncodeError: 'ascii' codec can't encode character 
> u'\xe9' in position 19: ordinal not in range(128) 
> [dochtml] Traceback (most recent call last): 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 287, in write 
> [dochtml] self._write(str) 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 261, in _write 
> [dochtml] self._log_line(line) 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 227, in _log_line 
> [dochtml] self._stream.write(line) 
> [dochtml] UnicodeEncodeError: 'ascii' codec can't encode character 
> u'\xe9' in position 19: ordinal not in range(128) 
> [dochtml] Traceback (most recent call last): 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 287, in write 
> [dochtml] self._write(str) 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 261, in _write 
> [dochtml] self._log_line(line) 
> [dochtml]   File 
> "/opt/sage-clang/local/lib/python2.7/site-packages/sage_setup/docbuild/sphinxbuild.py",
>  
>
> line 227, in _log_line 
> [dochtml] self._stream.write(line) 
> [dochtml] UnicodeEncodeError: 'ascii' codec can't encode character 
> u'\xe9' in position 19: ordinal not in range(128) 
>
> There is a tone of them in the attached log  but which is not very 
> helpful for debugging. 
>
> Any help is appreciated. 
>
> Vincent 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: The future of the Mac Application on Mojave

[Volker Braun]

For 3), where should the downloaded Sage installation be stored? If its in 
the same folder as the Sage mac app then presumably OSX will again iterate 
through all 1 files at glacial pace?

>
>
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: schedule for 8.7 rc and final release

[Volker Braun]

PS: The openssl master branch is already Apache 
licensed: 
https://github.com/openssl/openssl/commit/151333164ece49fdba3fe5c4bbdccd9ae66d.
 
Though no release yet.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: schedule for 8.7 rc and final release

[Volker Braun]

On Friday, March 15, 2019 at 5:12:59 PM UTC+1, Dima Pasechnik wrote:
>
> 1) As Python.org now ships 2.7.16 with pre-build openssl, then why 
> don't we do the same? 
>

Because Python is not GPL licensed, of course
 

> (IMHO Sage should not try to out-saint the pope, and stick to "we 
> don't ship openssl orthodoxy") 
>

I'm fine with packaging the cert bundle, installing it, switch the osx 
binary build to include it, and test that on a variety of older macs. It 
would definitely be a improvement for the mac users. But we shouldn't delay 
Sage 8.7 for that.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: schedule for 8.7 rc and final release

[Volker Braun]

Is openssl compiled into the macos binary? Technically we wouldn't be 
allowed to distribute that


On Friday, March 15, 2019 at 3:58:17 PM UTC+1, Dima Pasechnik wrote:
>
> On Fri, Mar 15, 2019 at 2:53 PM Volker Braun  > wrote: 
> > 
> > We don't build it by default, so imho the answer is no. Not every 
> optional package works on every supported platform, even if we strive for 
> that. 
>
>
> Are we going to ship broken MacOS binaries then? 
>
> > 
> > On Friday, March 15, 2019 at 3:31:36 PM UTC+1, Dima Pasechnik wrote: 
> >> 
> >> It appears that Sage's openssl package is broken on MacOS nowadays. 
> >> Should this be a blocker? 
> >> 
> >> On Thu, Mar 14, 2019 at 4:49 PM Volker Braun  
> wrote: 
> >> > 
> >> > Feel free to fix the Cygwin-related bugs, but some of these are 
> longstanding issues that should be discussed with upstream first; 
> Realistically thats not going to make it to the next Sage version. 
> >> > 
> >> > 
> >> > 
> >> > On Thursday, March 14, 2019 at 2:36:29 PM UTC+1, E. Madison Bray 
> wrote: 
> >> >> 
> >> >> Hi Volker, 
> >> >> 
> >> >> I don't think there should be a release candidate at least until 
> most 
> >> >> of the blocker issues [1] are resolved; in particular the four that 
> >> >> are already either positively reviewed or are in-progress. 
> >> >> 
> >> >> Thanks 
> >> >> 
> >> >> 
> >> >> [1] 
> https://trac.sagemath.org/query?priority=blocker=needs_info=needs_review=needs_work=new=positive_review=sage-8.7=status=id=summary=priority=owner=type=component=time=priority
>  
> >> >> 
> >> >> On Thu, Mar 14, 2019 at 2:25 PM Volker Braun  
> wrote: 
> >> >> > 
> >> >> > Next develop release will be rc0 
> >> >> > 
> >> >> > IMHO changes to gmpy2 should wait until the next version to give 
> it some time to test out. 
> >> >> > 
> >> >> > -- 
> >> >> > 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 post to this group, send email to sage-...@googlegroups.com. 
> >> >> > Visit this group at https://groups.google.com/group/sage-devel. 
> >> >> > For more options, visit https://groups.google.com/d/optout. 
> >> > 
> >> > -- 
> >> > 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 post to this group, send email to sage-...@googlegroups.com. 
> >> > Visit this group at https://groups.google.com/group/sage-devel. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > -- 
> > 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 post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>

>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: schedule for 8.7 rc and final release

[Volker Braun]

We don't build it by default, so imho the answer is no. Not every optional 
package works on every supported platform, even if we strive for that.


On Friday, March 15, 2019 at 3:31:36 PM UTC+1, Dima Pasechnik wrote:
>
> It appears that Sage's openssl package is broken on MacOS nowadays. 
> Should this be a blocker? 
>
> On Thu, Mar 14, 2019 at 4:49 PM Volker Braun  > wrote: 
> > 
> > Feel free to fix the Cygwin-related bugs, but some of these are 
> longstanding issues that should be discussed with upstream first; 
> Realistically thats not going to make it to the next Sage version. 
> > 
> > 
> > 
> > On Thursday, March 14, 2019 at 2:36:29 PM UTC+1, E. Madison Bray wrote: 
> >> 
> >> Hi Volker, 
> >> 
> >> I don't think there should be a release candidate at least until most 
> >> of the blocker issues [1] are resolved; in particular the four that 
> >> are already either positively reviewed or are in-progress. 
> >> 
> >> Thanks 
> >> 
> >> 
> >> [1] 
> https://trac.sagemath.org/query?priority=blocker=needs_info=needs_review=needs_work=new=positive_review=sage-8.7=status=id=summary=priority=owner=type=component=time=priority
>  
> >> 
> >> On Thu, Mar 14, 2019 at 2:25 PM Volker Braun  
> wrote: 
> >> > 
> >> > Next develop release will be rc0 
> >> > 
> >> > IMHO changes to gmpy2 should wait until the next version to give it 
> some time to test out. 
> >> > 
> >> > -- 
> >> > 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 post to this group, send email to sage-...@googlegroups.com. 
> >> > Visit this group at https://groups.google.com/group/sage-devel. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > -- 
> > 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 post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: internet tests failing

[Volker Braun]

I'm guessing you run this on an oldish mac, those have an outdated openssl 
that doesn't support TLS12. More and more sites are switching that on. 
Building Sage's openssl should fix that.



On Thursday, March 14, 2019 at 7:09:50 PM UTC+1, kcrisman wrote:
>
> This could be just me.  But I am getting a lot of this when I try running 
> optional internet tests for e.g. src/sage/databases/oeis.py or 
> src/sage/symbolic/integration/external.py  Internet clearly works if you 
> can read this message, but apparently it doesn't work from within Sage, 
> because I get this message when I try it in the Sage command line as well 
> with e.g. this command.  Any ideas - do I need to rebuild Sage with 
> additional SSL support or something?  That should be mentioned somewhere. 
>  Thanks!
>
> - kcrisman
>
> w = oeis(7540) ; w 
>
> URLError:  verify failed (_ssl.c:726)>
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: schedule for 8.7 rc and final release

[Volker Braun]

Feel free to fix the Cygwin-related bugs, but some of these are 
longstanding issues that should be discussed with upstream first; 
Realistically thats not going to make it to the next Sage version.



On Thursday, March 14, 2019 at 2:36:29 PM UTC+1, E. Madison Bray wrote:
>
> Hi Volker, 
>
> I don't think there should be a release candidate at least until most 
> of the blocker issues [1] are resolved; in particular the four that 
> are already either positively reviewed or are in-progress. 
>
> Thanks 
>
>
> [1] 
> https://trac.sagemath.org/query?priority=blocker=needs_info=needs_review=needs_work=new=positive_review=sage-8.7=status=id=summary=priority=owner=type=component=time=priority
>  
>
> On Thu, Mar 14, 2019 at 2:25 PM Volker Braun  > wrote: 
> > 
> > Next develop release will be rc0 
> > 
> > IMHO changes to gmpy2 should wait until the next version to give it some 
> time to test out. 
> > 
> > -- 
> > 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 post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: schedule for 8.7 rc and final release

[Volker Braun]

Next develop release will be rc0

IMHO changes to gmpy2 should wait until the next version to give it some 
time to test out.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

[Volker Braun]

You only need MACOSX_DEPLOYMENT_TARGET / -mmacosx-version-min when building 
binaries to run on older mac versions. Whoever distributes cysignals should 
decide which min sdk version they support. What is bound to go wrong is 
that somebody builds an application that includes your library with their 
chosen MACOSX_DEPLOYMENT_TARGET, and the binaries don't work because some 
dependency thought it would be fun to require a higher version. And the 
distributor of the app (like Sage) typically doesn't have a basement full 
of old macs to test if the binaries really are downward compatible.

* If you definitely require  then just include it. Add a comment 
with the min sdk version for anyone hitting that #include error.

* If  is optional then add a #warning that it is recommended


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Proposal: Add ascii_art representation to factor

[Volker Braun]

Unicode has superscripts btw, would be neat to make use of that:

x⁴⁵⁶⁷⁸⁹

16 = 2⁴

>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: giacpy_sage missing (Was: Sage 8.7.beta5 released)

[Volker Braun]

Fixed.

As a general PSA, if you want to make sure that I'm uploading your new 
tarball then mention it in the ticket title. "Since 8.7.beta3, giacpy_sage 
fails some groebner bases-related testdocs." is not nearly self-explanatory 
enough.



On Sunday, February 24, 2019 at 2:05:14 PM UTC+1, vdelecroix wrote:
>
> giacpy_sage-0.6.7 seems absent from mirrors 
>
> Le 24/02/2019 à 11:39, Volker Braun a écrit : 
> > As always, you can get the latest beta version from the "develop" git 
> > branch. Alternatively, the self-contained source tarball is at 
> > http://www.sagemath.org/download-latest.html 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] MemoryError when individually doctesting sage/combinat/tableau.py

[Volker Braun]

On Wednesday, February 13, 2019 at 5:33:38 PM UTC+1, Travis Scrimshaw wrote:
>
> My (complete) guess is that there are so many partitions of 50 (204226 to 
> be precise) and in such a tight for loop that the garbage collector does 
> not have enough time to actually collect the parents being created and 
> discarded. 
>

The Python GC also starts collection if there are many new objects, so I 
don't think this is it.

 Running the example takes > 1 gb of ram; Surely a smaller example could be 
used with the same code coverage.  

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: python3 status report

[Volker Braun]

Also, I have now set up a Python3 buildbot to catch regressions!

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: spkgs dependencies graph

[Volker Braun]

If you want to use it for external dependencies you'll probably need to 
know about acceptable versions of these. Then you'll soon need a sat 
solver; E.g. conda does in that way.

On Tuesday, January 29, 2019 at 7:45:07 PM UTC+1, Dima Pasechnik wrote:
>
> Has anyone written code to compute it? 
> (and create a Sage graph out of it, maybe) 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Native Windows version

[Volker Braun]

On Wednesday, January 23, 2019 at 12:12:39 AM UTC+1, William wrote:
>
> If I had to run Sage on Windows for some reason today, I would use 
> Docker or VirtualBox.


I recently tried out the new Windows 10 Subsystem for LInux and its pretty 
sleek. I built Sage for shits & giggles and everything worked fine. I would 
definitely use that nowadays.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: OSX testing?

[Volker Braun]

I'm administering the OSX buildbot, if you send me your ssh key I can 
create an account


On Friday, January 4, 2019 at 11:16:57 AM UTC+1, E. Madison Bray wrote:
>
> Good afternoon (here in France anyways), 
>
> Does anyone have an OSX machine that Sage builds on which I can have 
> an SSH account on to test some stuff (e.g. one of the buildbots)? 
>
> The machine I used to have access to has been down for some time, and 
> I have no way to test potentially fragile changes (e.g. to the gcc 
> build) on OSX. 
>
> Thanks in advance. 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Error building Sage 8.5 on Manjaro 18.0

[Volker Braun]

This is now https://trac.sagemath.org/ticket/26996

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: error installing database-gap

[Volker Braun]

On Tuesday, January 1, 2019 at 2:48:49 PM UTC+1, Simon King wrote:
>
> Can I conclude that the comment "merge conflict" without indicating 
> the conflicting ticket will only arise when the next release is 
> imminent, so that there is really no point in finding out what other 
> ticket has exactly caused the conflict (because all what the ticket 
> author needs to do is to wait another day, pull the "develop" branch, 
> and merge the develop branch into the ticket branch)? 
>

I'm trying to make new betas/rcs about weekly, thats how long you'll have 
to wait in the worst case.  

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.