Re: [sage-devel] Re: SEGV Crash in `numerator(f(t)/g(t)-const)`
I see your point, but segafault should be avoided if possible. In some cases it is considered denial of service and IIRC on Fedora the coredump is in /var, owned by root and not deletable by user. -- 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/CAGUWgD9AHV%3Dmd3bW_DPVh_f4Utm__pe%2B3GMHiGbDBK%2Bv6q%3DV9Q%40mail.gmail.com.
[sage-devel] Re: SEGV Crash in `numerator(f(t)/g(t)-const)`
On Saturday 11 May 2024 at 09:58:38 UTC-7 Georgi Guninski wrote:
The following hurt my computations.
```
#Author Georgi Guninski, Sat May 11 04:53:23 PM UTC 2024
p=101;
Kt.=Integers(p)[]
c5,s5=((100*t^10 + 45*t^8 + 93*t^6 + 8*t^4 + 56*t^2 + 1)/(t^10 + 5*t^8
+ 10*t^6 + 10*t^4 + 5*t^2 + 1), (10*t^9 + 82*t^7 + 50*t^5 + 82*t^3 +
10*t)/(t^10 + 5*t^8 + 10*t^6 + 10*t^4 + 5*t^2 + 1))
f1=numerator(c5+99/101);f2=numerator(s5-20/101)
print("Done",f1,f2)
```
Unhandled SIGSEGV: A segmentation fault occurred
The system should of course not segfault on this, but I doubt that this
fault kept you from getting a valid result. The fractions 99/101 and 20/101
cannot be coerced into Kt. So the problem is probably that for convenience
the system pretends there is a coercion map Q -> GF(101), but it's actually
only a partial map. It may be as simple as an uncaught exception (because
the code didn't expect an exception to occur here.
To work around this bug, coerce your constants into Kt before doing the
arithmetic:
f1=numerator(c5+Kt(99/101));f2=numerator(s5-Kt(20/101))
That will give you an appropriate error instead of a segfault.
--
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/df71fb00-791a-4aa4-9390-ba8f8e05a737n%40googlegroups.com.
[sage-devel] SEGV Crash in `numerator(f(t)/g(t)-const)`
The following hurt my computations.
```
#Author Georgi Guninski, Sat May 11 04:53:23 PM UTC 2024
p=101;
Kt.=Integers(p)[]
c5,s5=((100*t^10 + 45*t^8 + 93*t^6 + 8*t^4 + 56*t^2 + 1)/(t^10 + 5*t^8
+ 10*t^6 + 10*t^4 + 5*t^2 + 1), (10*t^9 + 82*t^7 + 50*t^5 + 82*t^3 +
10*t)/(t^10 + 5*t^8 + 10*t^6 + 10*t^4 + 5*t^2 + 1))
f1=numerator(c5+99/101);f2=numerator(s5-20/101)
print("Done",f1,f2)
```
Unhandled SIGSEGV: A segmentation fault occurred
--
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/CAGUWgD8uxzsS0OK2i38_OADfr0Mni%3DR3oAsi0gUTRRWfuJAvmA%40mail.gmail.com.
[sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
On Thursday, May 9, 2024 at 2:18:41 AM UTC-7 Volker Braun wrote: +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). [...] 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 That would also be fine with me, of course. I've opened https://github.com/sagemath/sage/issues/37971 for 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/227b9298-52ea-48c0-a17d-3576725ceacen%40googlegroups.com.
Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini
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.
