Thank you, Dima! It was indeed due to an accidental allocation of a
significant portion of RAM to the integrated graphics.
On Wed, Jan 10, 2024 at 11:46 PM Dima Pasechnik wrote:
> Hi,
> you need to give your WSL more RAM.
> Otherwise big C++ compilations don't go through.
>
>
> On Thursday,
Hi,
you need to give your WSL more RAM.
Otherwise big C++ compilations don't go through.
On Thursday, January 11, 2024 at 6:44:14 AM UTC gko...@math.arizona.edu
wrote:
> Hello,
>
> I'm trying to build Sage 10.2 from source in Ubuntu 22.04 WSL by following
>
Hi,
Appointing an editor (or editors) seems not a realistic solution, as it
would be harder than resolving a disputed PR.
Forcing the code of conduct is not realistic either, as we have no means to
force it.
I advocate for adopting a policy such as David Roe suggested for disputed
PRs, as
On 10 January 2024 20:29:28 GMT, Edgar Costa wrote:
>>
>> I suspect it's due to the latter used to Sage the distro as a "missing
>> macOS
>> package manager".
>> So they are happy adding more and more spkgs to Sage.
>> And Linux users rightly see adding to Sage spkgs, which
>> package software
1. I think many of these uses have been made obsolete by the automatic
pingbacks that appear when an Issue/PR is mentioned elsewhere. For example,
in PR https://github.com/sagemath/sage/pull/36951, I included the text "-
Part of https://github.com/sagemath/sage/issues/33577;, which created a
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
>
> I suspect it's due to the latter used to Sage the distro as a "missing
> macOS
> package manager".
> So they are happy adding more and more spkgs to Sage.
> And Linux users rightly see adding to Sage spkgs, which
> package software available on their systems in a regular way,
> as a bloat,
We have a problem of one developer, who decided, based on his, certainly,
prolific contributions, that he can appoint himself a CTO of the project, and
tell everyone who disagrees with him that it's a violation of CoC.
On 10 January 2024 19:37:58 GMT, Matthias Koeppe
wrote:
>As I have
As I have explained to the current, semi-anonymous sage-abuse committee in
private communication:
The framing of the dysfunction in the affected PRs
https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed as
mere "disputes" or "controversies" is misguided and harmful.
We
On Wednesday, January 10, 2024 at 3:21:54 PM UTC Michael Orlitzky wrote:
On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote:
> Dear Sage Developers,
>
> 1. There are over 20 pull requests labeled as "disputed" [1]. To
> resolve these pull requests, we will be appointing an editor with
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
Maybe it would make sense to appoint a group of editors, rather than a
single editor, and this group decides per vote? I'd feel much better if
the responsibility is at least a little bit distributed between several
people, and, most importantly, people who have been around for some time.
Back in the days of trac, we sometimes had meta tickets that anyone
could edit, for things such as wishlists or keeping track of larger
projects. Some of these meta tickets were turned into GitHub issues,
but now they are no longer editable by anyone except the original
author (or so it seems).
On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote:
> Dear Sage Developers,
>
> 1. There are over 20 pull requests labeled as "disputed" [1]. To
> resolve these pull requests, we will be appointing an editor with no
> direct involvement in the pull request to make a judgement call on
> that
Dear Sage Developers,
1. There are over 20 pull requests labeled as "disputed" [1]. To
resolve these pull requests, we will be appointing an editor with no
direct involvement in the pull request to make a judgement call on
that particular pull request. We will then fully support the
decision
On Wednesday 10 January 2024 at 03:03:09 UTC-8 Martin R wrote:
... What would be a good name? Brainstorming: `coefficient_system`,
`coefficients`, `coefficients_monomials`,
`coefficient_matrix_monomial_vector`...
I think coefficients_monomials() is the most descriptive, as it tells you
what
How about .linearize()?
(I think this method should also optionally take a list
of monomials as an argument, since there are situations
in which users would like to force their own ordering.
Returning the same monomial vector again would then of
course be redundant, so in that case the method
I like this idea much better! What would be a good name? Brainstorming:
`coefficient_system`, `coefficients`, `coefficients_monomials`,
`coefficient_matrix_monomial_vector`...
On Wednesday 10 January 2024 at 09:06:36 UTC+1 Nils Bruin wrote:
> deprecation in a way that allows code to be
deprecation in a way that allows code to be adapted gradually would mean:
- introduce a new method with a different name that implements the desired
behaviour
- deprecate old method
- after appropriate deprecation period remove old method
- possibly, at this point introduce the now-vacated
19 matches
Mail list logo
