Giving short testcase, can someone else reproduce it?
Also attaching backtrace.
On second thought, if I don't crash, there could be some memory
corruption and sage runs with screwed memory.
```
x,y=var('x,y');n=10**6
while True: so=solve_mod(x*y-1,n)
#press CTL-C, crashes with probability about 1/
We have received messages from several people that the level of discord on
display between Dima and Matthias makes them feel uncomfortable
participating on this email list. To protect the community from this
acrimony, we are for now restricting Dima and Matthias to moderated
contributions on sage-d
> 4. Please vote -1 on https://github.com/sagemath/sage/pull/36580,
https://github.com/sagemath/sage/pull/36753, and
https://github.com/sagemath/sage/pull/37138, which attempt to obstruct the
modularization project and the mechanism for the distribution on PyPI.
Please refrain from such unfoun
+1
--
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/m
Reported.
On Wednesday, April 10, 2024 at 3:39:56 PM UTC-7 Dima Pasechnik wrote:
> On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe
> wrote:
>
>> On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org
>> wrote:
>>
>> We have carefully reviewed [...]
>>
>> We therefore disagree with
On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote:
On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe
wrote:
On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
There is simply no need to keep the .gitsubmodules -
the only file in the main repo affected by
On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe
wrote:
> On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org wrote:
>
> We have carefully reviewed [...]
>
> We therefore disagree with characterizing opposing opinions as “artificial
> friction”, “hostile demands”, or an “attempt to
On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe
wrote:
> On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
>
> On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe
> wrote:
>
> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 C
On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe
wrote:
On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
On 10 April 2024 19:24:12 CEST, Matthias Koeppe
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 P
On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe
wrote:
> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >
> >[...] git submodules [...]
>
Also not that there is plenty of code that, in the course of computation,
writes into attributes of objects. If you're doing multiple of those it's
very hard in python to make such a modification atomic. So if an interrupt
ends up splitting an update, you may leave the system in an inconsistent
On 10 April 2024 21:50:43 CEST, Matthias Koeppe
wrote:
>On Monday, April 8, 2024 at 5:19:02 PM UTC-7 Dima Pasechnik wrote:
>
>On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe wrote:
>
> You will find the comments in these PRs instructive -- also as
>illustration for a (long overdue) *discussio
On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
On 10 April 2024 19:24:12 CEST, Matthias Koeppe
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>[...] git submodules [...]
>
>git submodules are included in a repository by specific commit
On 10 April 2024 19:24:12 CEST, Matthias Koeppe
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>[...] git submodules [...]
>
>
>git submodules are included in a repository by specific commit sha of the
>submodule repo.
>So whenever one has to make a change in th
On Monday, April 8, 2024 at 5:19:02 PM UTC-7 Dima Pasechnik wrote:
On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe wrote:
You will find the comments in these PRs instructive -- also as
illustration for a (long overdue) *discussion about governance and review
standards* in the Sage project.
*
On 10 April 2024 20:23:10 CEST, Matthias Koeppe
wrote:
>Dima, our project does not have such a policy of not adding standard normal
>packages. This bundling with your political demand is inappropriate and not
>welcome here.
Why is it unwelcome?
I explained under what condition I am OK with
Dima, our project does not have such a policy of not adding standard normal
packages. This bundling with your political demand is inappropriate and not
welcome here.
On Wednesday, April 10, 2024 at 11:20:14 AM UTC-7 Dima Pasechnik wrote:
> As in the previous attempt, I am OK with it becoming st
As in the previous attempt, I am OK with it becoming standard only if it
remains a pip package, a no new "batteries are included".
As a matter of fact, there is no point in keeping Python toolchain packages
vendored. They can all be pip packages just as well.
On 10 April 2024 05:44:36 CEST, Mat
I do not remember anything specific about solve_mod. Though, there are
many places in Cython source code where sig_on/sig_off is not handled
carefully enough (and many that were fixed).
The fact that it is not reproducible is not necessarily a huge problem. However,
- Could you share the code (as
On Tuesday, April 9, 2024 at 6:39:00 PM UTC-7 Kwankyu Lee wrote:
How about redefining the meaning of "CI Fix" label:
1. We designate a person to be the CI manager.
2. For PRs pertaining to the designated directories and files, we add "CI
Fix" label
3. The CI manager has the right to merge PRs w
On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
[...] git submodules [...]
git submodules are included in a repository by specific commit sha of the
submodule repo.
So whenever one has to make a change in the submodule repo, one also has to
commit a change (by a second PR)
On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org wrote:
We have carefully reviewed [...]
We therefore disagree with characterizing opposing opinions as “artificial
friction”, “hostile demands”, or an “attempt to sabotage”.
Such allegations will have no effect other than to ant
Thanks, that's the page I was expecting.
I think it would be a good idea to have that linked more obviously, but I
am not able to make a PR right now.
I found a tarball on GitHub on the releases page, so made progress, though
as I reported elsewhere I have not yet been able to build sage from it
Please don't!
+1 for sure
> The modularization project (making pip-installation packages that contain
portions of the sage library) started years ago with a general consensus of
the sage community. Matthias led the project and did most of hard works.
Many others did not care much about the
I guess the idea is that further down on this page, you are told to follow
the instructions in the README here
https://github.com/sagemath/sage/#readme which in turn tells you get the
"sources" from here https://www.sagemath.org/download-source.html.
I agree that this is not terribly intuitive,
I don't have reproducible testcase, but my pain is that sometimes if I
press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and
abort.
I suspect besides signals, it is hitting race condition.
Is this a known issue?
Very long ago there was vulnerability in sendmail, where it did
printf
Hi Martin,
On Tuesday, April 2, 2024 at 3:17:19 PM UTC+3 Martin R wrote:
I tried all day to make sense of the element_constructor of the
InfinitePolynomialRIng (which uses sage_eval to interpret the repr), but I
failed.
That string eval is quite curious. I have no clue why it's necessary.
Ho
+1: Using the PyPA standard build tools is a good move.
On Tuesday, April 9, 2024 at 10:44:36 PM UTC-5 Matthias Koeppe wrote:
> We added python_build as an optional "pip" package (see
> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
> for
> the terminolo
Matthias,
We have carefully reviewed the arguments people have brought for and
against the disputed PRs and find it credible that both sides have genuine
concerns. We therefore disagree with characterizing opposing opinions as
“artificial friction”, “hostile demands”, or an “attempt to sabotage
On 10 April 2024 03:39:00 CEST, Kwankyu Lee wrote:
>How about redefining the meaning of "CI Fix" label:
>
>1. We designate a person to be the CI manager.
>2. For PRs pertaining to the designated directories and files, we add "CI
>Fix" label
>3. The CI manager has the right to merge PRs with "
On 10 April 2024 02:04:48 CEST, Matthias Koeppe
wrote:
>On Tuesday, April 9, 2024 at 4:20:56 PM UTC-7 Dima Pasechnik wrote:
>
>have a CI/sage-distro repo [...] with all that .github/ etc stuff needed
>for CI, including a part of build/ - and checkout sagelib as a submodule.
>
>
>Also that doe
In the first line of
https://doc.sagemath.org/html/en/installation/source.html#sec-installation-from-sources
the words "source code" are a link to the wikipedia page for "source code",
which is not very helpful. I was expecting it to be a link to page shoing
where to download a tarball. I sometim
Please whoever is not blocked by the author of this PR, record my -1 vote on
this.
Yes, this vote has a political element in it.
You want to play politics - let us play it.
Dima
On 10 April 2024 02:40:40 CEST, Tobias Diez wrote:
>@tobiasdiez requested your review on: sagemath/sage#36676 Restru
Please don't!
Martin
On Wednesday 10 April 2024 at 00:39:39 UTC+2 Dima Pasechnik wrote:
> I think I will quit the Sage project as soon as decisions on technical
> merits of PRs and issues will start to be taken in a nakedly political way.
>
> I am very strongly against any political overtones i
34 matches
Mail list logo
