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

[seb....@gmail.com]

Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 UTC+2:

On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:
>
>> Is it possible to choose the issue numbers in GH when making a migration? 
>> Then, setting a redirect of the form "
>> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the 
>> lion's share of the links still relevant.
>>
>
> Yes, to map it like this is the plan.
>  
>
>> This does not preserve fragments like "#comment:7", which is useful in 
>> long ticket discussions.
>>
>
> Thanks, I've opened https://github.com/sagemath/trac-to-github/issues/7 
> for this.
>
Don’t we need an issue for the first point, as well? The example #26 
 corresponds to #34110 
 which is not easy to recover from 
the migrated information.

Furthermore, it isn’t still clear to me how dependencies between PRs will 
be visible (like in the Trac dependencies field). In the above example you 
have to recover this from the history of commit messages (which may not be 
clear enough in general). Shouldn’t the migration put something into the 
header fields milestone, assignees, …, as well (if possible)? How will 
authors and reviewers be visible?
​

-- 
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/bb6690bd-809b-41d8-a0ed-8b45f6b4def9n%40googlegroups.com.

[sage-devel] Re: Temporary files problems

['Martin R' via sage-devel]

I also have this problem when doing

sage: qu = findstat("Permutations", 
compute_my_brand_new_permutation_statistic); qu
St00: a new statistic on Permutations
sage: qu.submit()

which writes the information for findstat into a temporary file, and then 
opens a webbrowser to display it.
On Tuesday, 27 September 2022 at 06:47:16 UTC+2 novo...@gmail.com wrote:

> I think it must be customizable, and also its use should be checked for 
> errors - if it does not exist anymore, it should be recreated... Public 
> SageCell servers probably see enough traffic to keep it alive, but people 
> with private servers are very likely to run into problems, e.g. when their 
> students are sleeping or pub crawling, all at once ;-)

-- 
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/640371c4-c270-41da-8c98-b956631cn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Dima Pasechnik]

On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  wrote:
>
> Hello!
>
> I've run into this while testing upgrades to Ubuntu 22.04 from 20.04, but it 
> seems that it comes from how temporary files are handled in Sage 9.7:
>
> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
>
> this temporary directory is created and then used ever after. But what if it 
> gets deleted?
I think it's meant to be used in a context manager, i.e. with with
statement, e.g., citing python docs:

>>> with tempfile.TemporaryDirectory() as tmpdirname:
... print('created temporary directory', tmpdirname)
>>>
# directory and contents have been removed

Or with a callback (from Sage source)

TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup())


Needless to say, one can interfere with it in a bad way messing around
with ~/.sage/ - but so it the case for any file-based process...



 For example, what if someone uses tmpreaper or something similar,
when old files are removed from /tmp? Sage does not notice it, but
things break in a weird way, e.g. plots are not displayed and the
error message is not transparent.
>
> I believe this is exactly what is happening and I would appreciate some 
> attention to this matter ;-)
>
> Thank you!
> Andrey
>
> --
> 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/5ee63ec7-26b2-4c32-a5a7-45fb63a11327n%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/CAAWYfq3V5wxwM32fEWTBz%2Bi%3Dt%3DZvLbfkqSemiuPfUx%2B%2BgYut8w%40mail.gmail.com.

Re: [sage-devel] is there a convention for _bool_ was: is it intentional that prod does not stop when it hits 0?

['Martin R' via sage-devel]

On Friday, 23 September 2022 at 20:09:55 UTC+2 Nils Bruin wrote:

> On Friday, 23 September 2022 at 10:37:01 UTC-7 axio...@yahoo.de wrote:
>
>> OK, this is off topic, but: shouldn't it be this convention?  At least: 
>> shouldn't there be some convention?  Maybe it would be good to discuss this 
>> in a separate thread.  Thus, I repeat the question:
>>
>> Is there, or should there be a convention about x._bool_ returning False 
>> only when x is provably False?
>>
>> No, quite the opposite. Certainly in SR, equalities that can't be proven 
> correct (for "proof" used in the loose sense of what the various symbolic 
> engines are willing to confirm), will return "False" when converted to 
> "bool" value. The key is: _bool_ cannot really error out (that would break 
> too much in python) and does not allow for "unknown" outcomes, so some 
> choice must be made.
>

The doc of Expression.__bool__ says:

Return True unless this symbolic expression can be shown by Sage
to be zero.  Note that deciding if an expression is zero is
undecidable in general.

which seems to be in agreement with what I thought.  Or am I missing 
something?

It seems really strange to me that "not O(x^7)" should be True.

Martin

-- 
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/66413f29-fb5d-4988-a371-16c9b58495a9n%40googlegroups.com.

Re: [sage-devel] is there a convention for _bool_ was: is it intentional that prod does not stop when it hits 0?

[Vincent Delecroix]

On Tue, 27 Sept 2022 at 11:58, 'Martin R' via sage-devel
 wrote:
>
>
>
> On Friday, 23 September 2022 at 20:09:55 UTC+2 Nils Bruin wrote:
>>
>> On Friday, 23 September 2022 at 10:37:01 UTC-7 axio...@yahoo.de wrote:
>>>
>>> OK, this is off topic, but: shouldn't it be this convention?  At least: 
>>> shouldn't there be some convention?  Maybe it would be good to discuss this 
>>> in a separate thread.  Thus, I repeat the question:
>>>
>>> Is there, or should there be a convention about x._bool_ returning False 
>>> only when x is provably False?
>>>
>> No, quite the opposite. Certainly in SR, equalities that can't be proven 
>> correct (for "proof" used in the loose sense of what the various symbolic 
>> engines are willing to confirm), will return "False" when converted to 
>> "bool" value. The key is: _bool_ cannot really error out (that would break 
>> too much in python) and does not allow for "unknown" outcomes, so some 
>> choice must be made.
>
>
> The doc of Expression.__bool__ says:
>
> Return True unless this symbolic expression can be shown by Sage
> to be zero.  Note that deciding if an expression is zero is
> undecidable in general.
>
> which seems to be in agreement with what I thought.  Or am I missing 
> something?
>
> It seems really strange to me that "not O(x^7)" should be True.

According to this symbolic specification,O(x^7) is not provably an
exact zero so it is reasonable to evaluate it to False. Which means
that "not O(x^7)" ought to be True.

-- 
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/CAGEwAAk_-fXfQpvj4YUnemJu3T3%3DJ%2BGJUuVrKa6whBHfqZAQOw%40mail.gmail.com.

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

[Tobias Diez]

One more question: The current plan is to use the sagetrac-mirror repo as 
the base for creating PRs but also to archived it. However, if I'm not 
mistaken, that makes all branches in sagetrac-mirror readonly and thus one 
cannot continue working on existing PRs by pushing to the corresponding 
branch in sagetrac-mirror.
On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com wrote:

> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 UTC+2:
>
> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:
>>
>>> Is it possible to choose the issue numbers in GH when making a 
>>> migration? Then, setting a redirect of the form "
>>> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
>>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the 
>>> lion's share of the links still relevant.
>>>
>>
>> Yes, to map it like this is the plan.
>>  
>>
>>> This does not preserve fragments like "#comment:7", which is useful in 
>>> long ticket discussions.
>>>
>>
>> Thanks, I've opened https://github.com/sagemath/trac-to-github/issues/7 
>> for this.
>>
> Don’t we need an issue for the first point, as well? The example #26 
>  corresponds to #34110 
>  which is not easy to recover 
> from the migrated information.
>
> Furthermore, it isn’t still clear to me how dependencies between PRs will 
> be visible (like in the Trac dependencies field). In the above example you 
> have to recover this from the history of commit messages (which may not be 
> clear enough in general). Shouldn’t the migration put something into the 
> header fields milestone, assignees, …, as well (if possible)? How will 
> authors and reviewers be visible?
> ​
>

-- 
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/d815783e-fd5c-4aa3-ab27-7024b18b299dn%40googlegroups.com.

Re: [sage-devel] is there a convention for _bool_ was: is it intentional that prod does not stop when it hits 0?

['Martin R' via sage-devel]

I am reading this differently, but that may be my lack of knowledge of 
English.

I thought "Return True, unless provably zero" would give true, if something 
cannot be shown to be zero.

Martin

On Tuesday, 27 September 2022 at 12:21:12 UTC+2 vdelecroix wrote:

> On Tue, 27 Sept 2022 at 11:58, 'Martin R' via sage-devel
>  wrote:
> >
> >
> >
> > On Friday, 23 September 2022 at 20:09:55 UTC+2 Nils Bruin wrote:
> >>
> >> On Friday, 23 September 2022 at 10:37:01 UTC-7 axio...@yahoo.de wrote:
> >>>
> >>> OK, this is off topic, but: shouldn't it be this convention? At least: 
> shouldn't there be some convention? Maybe it would be good to discuss this 
> in a separate thread. Thus, I repeat the question:
> >>>
> >>> Is there, or should there be a convention about x._bool_ returning 
> False only when x is provably False?
> >>>
> >> No, quite the opposite. Certainly in SR, equalities that can't be 
> proven correct (for "proof" used in the loose sense of what the various 
> symbolic engines are willing to confirm), will return "False" when 
> converted to "bool" value. The key is: _bool_ cannot really error out (that 
> would break too much in python) and does not allow for "unknown" outcomes, 
> so some choice must be made.
> >
> >
> > The doc of Expression.__bool__ says:
> >
> > Return True unless this symbolic expression can be shown by Sage
> > to be zero. Note that deciding if an expression is zero is
> > undecidable in general.
> >
> > which seems to be in agreement with what I thought. Or am I missing 
> something?
> >
> > It seems really strange to me that "not O(x^7)" should be True.
>
> According to this symbolic specification,O(x^7) is not provably an
> exact zero so it is reasonable to evaluate it to False. Which means
> that "not O(x^7)" ought to be True.
>

-- 
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/a4a00641-0b8d-4fd4-8690-7e75bb860c74n%40googlegroups.com.

Re: [sage-devel] is there a convention for _bool_ was: is it intentional that prod does not stop when it hits 0?

[Vincent Delecroix]

You are right of course (my bad): bool(expr) could be considered as
being True according to these specifications (and anyway "True" is
always a good answer). Though these are specifications for SR and does
not apply to the entire library. It is not clear to me what global
specification we could have for bool(algebraic expression).

On Tue, 27 Sept 2022 at 12:49, 'Martin R' via sage-devel
 wrote:
>
> I am reading this differently, but that may be my lack of knowledge of 
> English.
>
> I thought "Return True, unless provably zero" would give true, if something 
> cannot be shown to be zero.
>
> Martin
>
> On Tuesday, 27 September 2022 at 12:21:12 UTC+2 vdelecroix wrote:
>>
>> On Tue, 27 Sept 2022 at 11:58, 'Martin R' via sage-devel
>>  wrote:
>> >
>> >
>> >
>> > On Friday, 23 September 2022 at 20:09:55 UTC+2 Nils Bruin wrote:
>> >>
>> >> On Friday, 23 September 2022 at 10:37:01 UTC-7 axio...@yahoo.de wrote:
>> >>>
>> >>> OK, this is off topic, but: shouldn't it be this convention? At least: 
>> >>> shouldn't there be some convention? Maybe it would be good to discuss 
>> >>> this in a separate thread. Thus, I repeat the question:
>> >>>
>> >>> Is there, or should there be a convention about x._bool_ returning False 
>> >>> only when x is provably False?
>> >>>
>> >> No, quite the opposite. Certainly in SR, equalities that can't be proven 
>> >> correct (for "proof" used in the loose sense of what the various symbolic 
>> >> engines are willing to confirm), will return "False" when converted to 
>> >> "bool" value. The key is: _bool_ cannot really error out (that would 
>> >> break too much in python) and does not allow for "unknown" outcomes, so 
>> >> some choice must be made.
>> >
>> >
>> > The doc of Expression.__bool__ says:
>> >
>> > Return True unless this symbolic expression can be shown by Sage
>> > to be zero. Note that deciding if an expression is zero is
>> > undecidable in general.
>> >
>> > which seems to be in agreement with what I thought. Or am I missing 
>> > something?
>> >
>> > It seems really strange to me that "not O(x^7)" should be True.
>>
>> According to this symbolic specification,O(x^7) is not provably an
>> exact zero so it is reasonable to evaluate it to False. Which means
>> that "not O(x^7)" ought to be True.
>
> --
> 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/a4a00641-0b8d-4fd4-8690-7e75bb860c74n%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/CAGEwAA%3DQ0ZEP82hSKFq7Sx4r7qraO7aZ5L005xzabr19QJSp%3Dw%40mail.gmail.com.

[sage-devel] Re: is there a convention for _bool_ was: is it intentional that prod does not stop when it hits 0?

[Marc Mezzarobba]

Vincent Delecroix wrote:
> Though these are specifications for SR and does
> not apply to the entire library. It is not clear to me what global
> specification we could have for bool(algebraic expression).

Something like "bool(x) iff x is not trivially zero" would make sense to
me, where "not trivially zero" means "not exactly identical to the most
simple representation of zero of the given type". Something that can be
used to decide whether a coefficient of a polynomial should be
displayed, for instance. (And that is cheap to test.)

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/tgunmp%2415pl%241%40ciao.gmane.io.

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

[Dima Pasechnik]

On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez  wrote:
>
> One more question: The current plan is to use the sagetrac-mirror repo as the 
> base for creating PRs but also to archived it. However, if I'm not mistaken, 
> that makes all branches in sagetrac-mirror readonly and thus one cannot 
> continue working on existing PRs by pushing to the corresponding branch in 
> sagetrac-mirror.

IMHO the plan is to create new PRs in sagemath/sage, not in
sagemath/sagetrac-mirror
There won't be "existing" PRs, only issues, pointing to branches on
sagetrac-mirror



> On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com wrote:
>>
>> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 UTC+2:
>>>
>>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:

 Is it possible to choose the issue numbers in GH when making a migration? 
 Then, setting a redirect of the form 
 "https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
 https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the 
 lion's share of the links still relevant.
>>>
>>>
>>> Yes, to map it like this is the plan.
>>>

 This does not preserve fragments like "#comment:7", which is useful in 
 long ticket discussions.
>>>
>>>
>>> Thanks, I've opened https://github.com/sagemath/trac-to-github/issues/7 for 
>>> this.
>>
>> Don’t we need an issue for the first point, as well? The example #26 
>> corresponds to #34110 which is not easy to recover from the migrated 
>> information.
>>
>> Furthermore, it isn’t still clear to me how dependencies between PRs will be 
>> visible (like in the Trac dependencies field). In the above example you have 
>> to recover this from the history of commit messages (which may not be clear 
>> enough in general). Shouldn’t the migration put something into the header 
>> fields milestone, assignees, …, as well (if possible)? How will authors and 
>> reviewers be visible?
>
> --
> 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/d815783e-fd5c-4aa3-ab27-7024b18b299dn%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/CAAWYfq2J9Ksersn9LHhBayWg4%2BEV4nuyEZBYH%3DD5FxumXwRMsg%40mail.gmail.com.

[sage-devel] specification of __bool__

['Martin R' via sage-devel]

I think that x.__bool__ should return True only if x is *known* to be zero.

I have three docstrings that support this view:

rings/real_mpfi.pyx\03905:def __bool__(self):
rings/real_mpfi.pyx\03906-"""
rings/real_mpfi.pyx\03907-Return ``True`` if ``self`` is not known 
to be exactly zero.
rings/real_mpfi.pyx\03908-
--
rings/complex_interval.pyx\01495:def __bool__(self):
rings/complex_interval.pyx\01496-"""
rings/complex_interval.pyx\01497-Return ``True`` if ``self`` is not 
known to be exactly zero.
rings/complex_interval.pyx\01498-
--
symbolic/expression.pyx\03310:def __bool__(self):
symbolic/expression.pyx\03311-"""
symbolic/expression.pyx\03312-Return True unless this symbolic 
expression can be shown by Sage
symbolic/expression.pyx\03313-to be zero.  Note that deciding if an 
expression is zero is

and I have not found a docstring contradicting this point of view.  
However, the behaviour of (fixed precision) power series is different:

sage: R. = QQ[[]]
sage: f = t.add_bigoh(5) - t
sage: f
O(t^5)
sage: not f
True

I think that this is a bug.

One implication is, as noticed by Chris Wuthrich, that the product "x * y" 
is not necessarily zero, even if "not x" gives True.

Before trying to create a branch, I'd like to hear other opinions.

Martin

-- 
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/5ad675ea-1cf1-4ea5-a39d-40eb567ff2e9n%40googlegroups.com.

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

[Tobias Diez]

Yes, the target repo of these PRs will be the (new) sagemath/sage, but the 
source will be sagemath/sagetrac-mirror, right? So in order to update the 
pull request one needs to push the changes to sagemath/sagetrac-mirror (it 
is not possible to update a PR by pushing to /refs/pull/xyz, because this 
is readonly). Thus, if sagetrac-mirror is archived (and thus readonly), the 
only way to work on existing tickets/branches would be to checkout the 
existing branch (from either sagetrac-mirror or sage/refs/pull), make 
changes, push to a new fork, create a new PR, close the old PR (essentially 
the workflow 
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally).

On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com wrote:

> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez  wrote:
> >
> > One more question: The current plan is to use the sagetrac-mirror repo 
> as the base for creating PRs but also to archived it. However, if I'm not 
> mistaken, that makes all branches in sagetrac-mirror readonly and thus one 
> cannot continue working on existing PRs by pushing to the corresponding 
> branch in sagetrac-mirror.
>
> IMHO the plan is to create new PRs in sagemath/sage, not in
> sagemath/sagetrac-mirror
> There won't be "existing" PRs, only issues, pointing to branches on
> sagetrac-mirror
>
>
>
> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com wrote:
> >>
> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 
> UTC+2:
> >>>
> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:
> 
>  Is it possible to choose the issue numbers in GH when making a 
> migration? Then, setting a redirect of the form "
> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
> https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the 
> lion's share of the links still relevant.
> >>>
> >>>
> >>> Yes, to map it like this is the plan.
> >>>
> 
>  This does not preserve fragments like "#comment:7", which is useful 
> in long ticket discussions.
> >>>
> >>>
> >>> Thanks, I've opened 
> https://github.com/sagemath/trac-to-github/issues/7 for this.
> >>
> >> Don’t we need an issue for the first point, as well? The example #26 
> corresponds to #34110 which is not easy to recover from the migrated 
> information.
> >>
> >> Furthermore, it isn’t still clear to me how dependencies between PRs 
> will be visible (like in the Trac dependencies field). In the above example 
> you have to recover this from the history of commit messages (which may not 
> be clear enough in general). Shouldn’t the migration put something into the 
> header fields milestone, assignees, …, as well (if possible)? How will 
> authors and reviewers be visible?
> >
> > --
> > 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/d815783e-fd5c-4aa3-ab27-7024b18b299dn%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/6df40198-0d1a-45f4-ac1f-2bee6e07d313n%40googlegroups.com.

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

[Dima Pasechnik]

On Tue, 27 Sep 2022, 14:08 Tobias Diez,  wrote:

> Yes, the target repo of these PRs will be the (new) sagemath/sage, but the
> source will be sagemath/sagetrac-mirror, right?



Hmm, I might have missed something - what is the need to have 2 repos here,
if 1 is sufficient?

Any fork of sagemath/sage may be a source of a PR, not only sagetrac-mirror


So in order to update the pull request one needs to push the changes to
> sagemath/sagetrac-mirror (it is not possible to update a PR by pushing to
> /refs/pull/xyz, because this is readonly). Thus, if sagetrac-mirror is
> archived (and thus readonly), the only way to work on existing
> tickets/branches would be to checkout the existing branch (from either
> sagetrac-mirror or sage/refs/pull), make changes, push to a new fork,
> create a new PR, close the old PR (essentially the workflow
> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally
> ).
>
> On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com wrote:
>
>> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez 
>> wrote:
>> >
>> > One more question: The current plan is to use the sagetrac-mirror repo
>> as the base for creating PRs but also to archived it. However, if I'm not
>> mistaken, that makes all branches in sagetrac-mirror readonly and thus one
>> cannot continue working on existing PRs by pushing to the corresponding
>> branch in sagetrac-mirror.
>>
>> IMHO the plan is to create new PRs in sagemath/sage, not in
>> sagemath/sagetrac-mirror
>> There won't be "existing" PRs, only issues, pointing to branches on
>> sagetrac-mirror
>>
>>
>>
>> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com
>> wrote:
>> >>
>> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46
>> UTC+2:
>> >>>
>> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:
>> 
>>  Is it possible to choose the issue numbers in GH when making a
>> migration? Then, setting a redirect of the form "
>> https://trac.sagemath.org/ticket/$TICKET_NUMBER ->
>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the
>> lion's share of the links still relevant.
>> >>>
>> >>>
>> >>> Yes, to map it like this is the plan.
>> >>>
>> 
>>  This does not preserve fragments like "#comment:7", which is useful
>> in long ticket discussions.
>> >>>
>> >>>
>> >>> Thanks, I've opened
>> https://github.com/sagemath/trac-to-github/issues/7 for this.
>> >>
>> >> Don’t we need an issue for the first point, as well? The example #26
>> corresponds to #34110 which is not easy to recover from the migrated
>> information.
>> >>
>> >> Furthermore, it isn’t still clear to me how dependencies between PRs
>> will be visible (like in the Trac dependencies field). In the above example
>> you have to recover this from the history of commit messages (which may not
>> be clear enough in general). Shouldn’t the migration put something into the
>> header fields milestone, assignees, …, as well (if possible)? How will
>> authors and reviewers be visible?
>> >
>> > --
>> > 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/d815783e-fd5c-4aa3-ab27-7024b18b299dn%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/6df40198-0d1a-45f4-ac1f-2bee6e07d313n%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/CAAWYfq0Ku9tpQieEADjWcWE%2BYywNaknL3dsDjPtzJusF%2B8iCSQ%40mail.gmail.com.

Re: [sage-devel] Temporary files problems

[John H Palmieri]

One of the issues is that code in Sage is using this temporary directory in 
the background; the user is not doing it and has no control over it. 
Regardless of the context manager approach, apparently some browsers refuse 
to open local files that are not in the user's home directory, so this 
location just won't work for them.


On Tuesday, September 27, 2022 at 2:22:47 AM UTC-7 dim...@gmail.com wrote:

> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
> wrote:
> >
> > Hello!
> >
> > I've run into this while testing upgrades to Ubuntu 22.04 from 20.04, 
> but it seems that it comes from how temporary files are handled in Sage 9.7:
> >
> > TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
> >
> > this temporary directory is created and then used ever after. But what 
> if it gets deleted?
> I think it's meant to be used in a context manager, i.e. with with
> statement, e.g., citing python docs:
>
> >>> with tempfile.TemporaryDirectory() as tmpdirname:
> ... print('created temporary directory', tmpdirname)
> >>>
> # directory and contents have been removed
>
> Or with a callback (from Sage source)
>
> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup())
>
>
> Needless to say, one can interfere with it in a bad way messing around
> with ~/.sage/ - but so it the case for any file-based process...
>
>
>
> For example, what if someone uses tmpreaper or something similar,
> when old files are removed from /tmp? Sage does not notice it, but
> things break in a weird way, e.g. plots are not displayed and the
> error message is not transparent.
> >
> > I believe this is exactly what is happening and I would appreciate some 
> attention to this matter ;-)
> >
> > Thank you!
> > Andrey
> >
> > --
> > 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/5ee63ec7-26b2-4c32-a5a7-45fb63a11327n%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/bcfa5eaa-600b-4752-8b52-189422564a49n%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Dima Pasechnik]

On Tue, 27 Sep 2022, 15:45 John H Palmieri,  wrote:

> One of the issues is that code in Sage is using this temporary directory
> in the background; the user is not doing it and has no control over it.
> Regardless of the context manager approach, apparently some browsers refuse
> to open local files that are not in the user's home directory, so this
> location just won't work for them.
>

tempfile.TemporaryDirectory(*suffix=None*, *prefix=None*, *dir=None*,
*ignore_cleanup_errors=False*)


dir=  may be used to set a directory to place
the created one in.




>
> On Tuesday, September 27, 2022 at 2:22:47 AM UTC-7 dim...@gmail.com wrote:
>
>> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev 
>> wrote:
>> >
>> > Hello!
>> >
>> > I've run into this while testing upgrades to Ubuntu 22.04 from 20.04,
>> but it seems that it comes from how temporary files are handled in Sage
>> 9.7:
>> >
>> > TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
>> >
>> > this temporary directory is created and then used ever after. But what
>> if it gets deleted?
>> I think it's meant to be used in a context manager, i.e. with with
>> statement, e.g., citing python docs:
>>
>> >>> with tempfile.TemporaryDirectory() as tmpdirname:
>> ... print('created temporary directory', tmpdirname)
>> >>>
>> # directory and contents have been removed
>>
>> Or with a callback (from Sage source)
>>
>> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
>> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup())
>>
>>
>> Needless to say, one can interfere with it in a bad way messing around
>> with ~/.sage/ - but so it the case for any file-based process...
>>
>>
>>
>> For example, what if someone uses tmpreaper or something similar,
>> when old files are removed from /tmp? Sage does not notice it, but
>> things break in a weird way, e.g. plots are not displayed and the
>> error message is not transparent.
>> >
>> > I believe this is exactly what is happening and I would appreciate some
>> attention to this matter ;-)
>> >
>> > Thank you!
>> > Andrey
>> >
>> > --
>> > 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/5ee63ec7-26b2-4c32-a5a7-45fb63a11327n%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/bcfa5eaa-600b-4752-8b52-189422564a49n%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/CAAWYfq2VWNbzfBOTKxt7JDgQAyY-GgHkA3c%2BRFNENSRv_u-mHA%40mail.gmail.com.

[sage-devel] Re: specification of __bool__

[Nils Bruin]

It seems attractive that for numerical types, bool(a) gives that same 
result as "not(a==0)", which would hopefully be the same as "a!=0".

It is definitely the case that O(t^5) == 0 is a lot more useful for 
computations. For instance, with that in place, Gaussian elimination will 
actually sort-of work on a matrix of power series with plenty of precision 
(it will work quite badly if you don't implement an appropriate pivoting 
strategy, though). If O(t^5) != 0 , basically nothing works and you end up 
with a numerical type that is virtually useless, except for the things 
purpose-implemented for it. So for that reason, equal-to-zero testing 
pretty much has to assume that enough precision is available to distinguish 
elements that you'll be encountering in your particular computation. You'll 
only be proving that things are not equal that way: you'll just get 
evidence things may be equal, unless you establish lower bounds on distance 
between elements that are not equal.

Your examples for interval arithmetic have their roots more in floating 
point, where equality testing is more generally accepted to be useless, but 
I would say that has a different pedigree than p-adic and power series, 
non-archimedean metrics,

where a question about a power series  + O(t^5) is much more clearly a 
question about an element of k[t]/(t^5), where equality has a very 
well-defined meaning.

Whether  "a != 0" should be basically the same as "bool(a)" ... python 
tradition says it should. If it's not, then I'd say bool(a) is pretty much 
useless anyway. I don't think the python habit of replacing every "if a !=0 
:" by "if a:" is a good one, but I acknowledge the habit is widespread. So 
laying mines by breaking its equivalence is a bad idea.

On Tuesday, 27 September 2022 at 05:00:00 UTC-7 axio...@yahoo.de wrote:

> I think that x.__bool__ should return True only if x is *known* to be zero.
>
> I have three docstrings that support this view:
>
> rings/real_mpfi.pyx\03905:def __bool__(self):
> rings/real_mpfi.pyx\03906-"""
> rings/real_mpfi.pyx\03907-Return ``True`` if ``self`` is not known 
> to be exactly zero.
> rings/real_mpfi.pyx\03908-
> --
> rings/complex_interval.pyx\01495:def __bool__(self):
> rings/complex_interval.pyx\01496-"""
> rings/complex_interval.pyx\01497-Return ``True`` if ``self`` is 
> not known to be exactly zero.
> rings/complex_interval.pyx\01498-
> --
> symbolic/expression.pyx\03310:def __bool__(self):
> symbolic/expression.pyx\03311-"""
> symbolic/expression.pyx\03312-Return True unless this symbolic 
> expression can be shown by Sage
> symbolic/expression.pyx\03313-to be zero.  Note that deciding if 
> an expression is zero is
>
> and I have not found a docstring contradicting this point of view.  
> However, the behaviour of (fixed precision) power series is different:
>
> sage: R. = QQ[[]]
> sage: f = t.add_bigoh(5) - t
> sage: f
> O(t^5)
> sage: not f
> True
>
> I think that this is a bug.
>
> One implication is, as noticed by Chris Wuthrich, that the product "x * y" 
> is not necessarily zero, even if "not x" gives True.
>
> Before trying to create a branch, I'd like to hear other opinions.
>
> Martin
>

-- 
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/73d3e6ae-f431-466e-a8c4-34ebc59f9e77n%40googlegroups.com.

Re: [sage-devel] Re: specification of __bool__

[David Roe]

Nils put it well; please don't change __bool__ for p-adic and power
series.  It should be compatible with equality testing.
David

On Tue, Sep 27, 2022 at 11:44 AM Nils Bruin  wrote:

> It seems attractive that for numerical types, bool(a) gives that same
> result as "not(a==0)", which would hopefully be the same as "a!=0".
>
> It is definitely the case that O(t^5) == 0 is a lot more useful for
> computations. For instance, with that in place, Gaussian elimination will
> actually sort-of work on a matrix of power series with plenty of precision
> (it will work quite badly if you don't implement an appropriate pivoting
> strategy, though). If O(t^5) != 0 , basically nothing works and you end up
> with a numerical type that is virtually useless, except for the things
> purpose-implemented for it. So for that reason, equal-to-zero testing
> pretty much has to assume that enough precision is available to distinguish
> elements that you'll be encountering in your particular computation. You'll
> only be proving that things are not equal that way: you'll just get
> evidence things may be equal, unless you establish lower bounds on distance
> between elements that are not equal.
>
> Your examples for interval arithmetic have their roots more in floating
> point, where equality testing is more generally accepted to be useless, but
> I would say that has a different pedigree than p-adic and power series,
> non-archimedean metrics,
>
> where a question about a power series  + O(t^5) is much more clearly a
> question about an element of k[t]/(t^5), where equality has a very
> well-defined meaning.
>
> Whether  "a != 0" should be basically the same as "bool(a)" ... python
> tradition says it should. If it's not, then I'd say bool(a) is pretty much
> useless anyway. I don't think the python habit of replacing every "if a !=0
> :" by "if a:" is a good one, but I acknowledge the habit is widespread. So
> laying mines by breaking its equivalence is a bad idea.
>
> On Tuesday, 27 September 2022 at 05:00:00 UTC-7 axio...@yahoo.de wrote:
>
>> I think that x.__bool__ should return True only if x is *known* to be
>> zero.
>>
>> I have three docstrings that support this view:
>>
>> rings/real_mpfi.pyx\03905:def __bool__(self):
>> rings/real_mpfi.pyx\03906-"""
>> rings/real_mpfi.pyx\03907-Return ``True`` if ``self`` is not
>> known to be exactly zero.
>> rings/real_mpfi.pyx\03908-
>> --
>> rings/complex_interval.pyx\01495:def __bool__(self):
>> rings/complex_interval.pyx\01496-"""
>> rings/complex_interval.pyx\01497-Return ``True`` if ``self`` is
>> not known to be exactly zero.
>> rings/complex_interval.pyx\01498-
>> --
>> symbolic/expression.pyx\03310:def __bool__(self):
>> symbolic/expression.pyx\03311-"""
>> symbolic/expression.pyx\03312-Return True unless this symbolic
>> expression can be shown by Sage
>> symbolic/expression.pyx\03313-to be zero.  Note that deciding if
>> an expression is zero is
>>
>> and I have not found a docstring contradicting this point of view.
>> However, the behaviour of (fixed precision) power series is different:
>>
>> sage: R. = QQ[[]]
>> sage: f = t.add_bigoh(5) - t
>> sage: f
>> O(t^5)
>> sage: not f
>> True
>>
>> I think that this is a bug.
>>
>> One implication is, as noticed by Chris Wuthrich, that the product "x *
>> y" is not necessarily zero, even if "not x" gives True.
>>
>> Before trying to create a branch, I'd like to hear other opinions.
>>
>> Martin
>>
> --
> 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/73d3e6ae-f431-466e-a8c4-34ebc59f9e77n%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/CAChs6_mEktABgG8zMAjWZ-dG6%3D7CF%3DG-%3DcCbKUGz5cqcvo_D_A%40mail.gmail.com.

Re: [sage-devel] Re: specification of __bool__

['Martin R' via sage-devel]

OK.

On Tuesday, 27 September 2022 at 17:50:04 UTC+2 David Roe wrote:

> Nils put it well; please don't change __bool__ for p-adic and power 
> series.  It should be compatible with equality testing.
> David
>
> On Tue, Sep 27, 2022 at 11:44 AM Nils Bruin  wrote:
>
>> It seems attractive that for numerical types, bool(a) gives that same 
>> result as "not(a==0)", which would hopefully be the same as "a!=0".
>>
>> It is definitely the case that O(t^5) == 0 is a lot more useful for 
>> computations. For instance, with that in place, Gaussian elimination will 
>> actually sort-of work on a matrix of power series with plenty of precision 
>> (it will work quite badly if you don't implement an appropriate pivoting 
>> strategy, though). If O(t^5) != 0 , basically nothing works and you end up 
>> with a numerical type that is virtually useless, except for the things 
>> purpose-implemented for it. So for that reason, equal-to-zero testing 
>> pretty much has to assume that enough precision is available to distinguish 
>> elements that you'll be encountering in your particular computation. You'll 
>> only be proving that things are not equal that way: you'll just get 
>> evidence things may be equal, unless you establish lower bounds on distance 
>> between elements that are not equal.
>>
>> Your examples for interval arithmetic have their roots more in floating 
>> point, where equality testing is more generally accepted to be useless, but 
>> I would say that has a different pedigree than p-adic and power series, 
>> non-archimedean metrics,
>>
>> where a question about a power series  + O(t^5) is much more clearly 
>> a question about an element of k[t]/(t^5), where equality has a very 
>> well-defined meaning.
>>
>> Whether  "a != 0" should be basically the same as "bool(a)" ... python 
>> tradition says it should. If it's not, then I'd say bool(a) is pretty much 
>> useless anyway. I don't think the python habit of replacing every "if a !=0 
>> :" by "if a:" is a good one, but I acknowledge the habit is widespread. So 
>> laying mines by breaking its equivalence is a bad idea.
>>
>> On Tuesday, 27 September 2022 at 05:00:00 UTC-7 axio...@yahoo.de wrote:
>>
>>> I think that x.__bool__ should return True only if x is *known* to be 
>>> zero.
>>>
>>> I have three docstrings that support this view:
>>>
>>> rings/real_mpfi.pyx\03905:def __bool__(self):
>>> rings/real_mpfi.pyx\03906-"""
>>> rings/real_mpfi.pyx\03907-Return ``True`` if ``self`` is not 
>>> known to be exactly zero.
>>> rings/real_mpfi.pyx\03908-
>>> --
>>> rings/complex_interval.pyx\01495:def __bool__(self):
>>> rings/complex_interval.pyx\01496-"""
>>> rings/complex_interval.pyx\01497-Return ``True`` if ``self`` is 
>>> not known to be exactly zero.
>>> rings/complex_interval.pyx\01498-
>>> --
>>> symbolic/expression.pyx\03310:def __bool__(self):
>>> symbolic/expression.pyx\03311-"""
>>> symbolic/expression.pyx\03312-Return True unless this symbolic 
>>> expression can be shown by Sage
>>> symbolic/expression.pyx\03313-to be zero.  Note that deciding if 
>>> an expression is zero is
>>>
>>> and I have not found a docstring contradicting this point of view.  
>>> However, the behaviour of (fixed precision) power series is different:
>>>
>>> sage: R. = QQ[[]]
>>> sage: f = t.add_bigoh(5) - t
>>> sage: f
>>> O(t^5)
>>> sage: not f
>>> True
>>>
>>> I think that this is a bug.
>>>
>>> One implication is, as noticed by Chris Wuthrich, that the product "x * 
>>> y" is not necessarily zero, even if "not x" gives True.
>>>
>>> Before trying to create a branch, I'd like to hear other opinions.
>>>
>>> Martin
>>>
>> -- 
>> 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/73d3e6ae-f431-466e-a8c4-34ebc59f9e77n%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/efd55988-060a-4e4d-87b5-1beeaeda2f1dn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Andrey Novoseltsev]

On Tuesday, 27 September 2022 at 03:22:47 UTC-6 dim...@gmail.com wrote:

> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
> wrote: 
> > this temporary directory is created and then used ever after. But what 
> if it gets deleted? 
> I think it's meant to be used in a context manager, i.e. with with 
> statement, e.g., citing python docs: 
>
> >>> with tempfile.TemporaryDirectory() as tmpdirname: 
> ... print('created temporary directory', tmpdirname) 
> >>> 
> # directory and contents have been removed 
>
> Or with a callback (from Sage source) 
>
> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory() 
> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup()) 
>
>
> Needless to say, one can interfere with it in a bad way messing around 
> with ~/.sage/ - but so it the case for any file-based process... 
>
>
It seems to me like a pretty common and sensible practice, that /tmp 
directories get cleaned up, especially on systems with lots of activity. I 
would not consider it as "a bad way messing around". But creating a 
temporary directory and then counting on it being there hours later for 
another quick temporary operation may be a bit too optimistic. That 
callback is designed to clean up after Sage quits, which is a good thing to 
do, but it is not related to being able to use the directory. 

-- 
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/231e405f-3af0-4a23-808e-0fb5edeb89bcn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Matthias Koeppe]

Previous discussion -- in the ticket that made these changes to SAGE_TMP 
--- https://trac.sagemath.org/ticket/33213#comment:11


On Tuesday, September 27, 2022 at 9:10:28 AM UTC-7 novo...@gmail.com wrote:

> On Tuesday, 27 September 2022 at 03:22:47 UTC-6 dim...@gmail.com wrote:
>
>> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
>> wrote: 
>> > this temporary directory is created and then used ever after. But what 
>> if it gets deleted? 
>> I think it's meant to be used in a context manager, i.e. with with 
>> statement, e.g., citing python docs: 
>>
>> >>> with tempfile.TemporaryDirectory() as tmpdirname: 
>> ... print('created temporary directory', tmpdirname) 
>> >>> 
>> # directory and contents have been removed 
>>
>> Or with a callback (from Sage source) 
>>
>> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory() 
>> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup()) 
>>
>>
>> Needless to say, one can interfere with it in a bad way messing around 
>> with ~/.sage/ - but so it the case for any file-based process... 
>>
>>
> It seems to me like a pretty common and sensible practice, that /tmp 
> directories get cleaned up, especially on systems with lots of activity. I 
> would not consider it as "a bad way messing around". But creating a 
> temporary directory and then counting on it being there hours later for 
> another quick temporary operation may be a bit too optimistic. That 
> callback is designed to clean up after Sage quits, which is a good thing to 
> do, but it is not related to being able to use the directory. 
>

-- 
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/8400b398-f51a-4a1b-a911-32f60ef8b8fdn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Dima Pasechnik]

Basically, we should deprecate and remove tmp_dir() and tmp_filename()
from Sage.
Does Sagecell use them? It should not, Python3 has perfectly good
replacements...

On Tue, Sep 27, 2022 at 6:06 PM Matthias Koeppe
 wrote:
>
> Previous discussion -- in the ticket that made these changes to SAGE_TMP --- 
> https://trac.sagemath.org/ticket/33213#comment:11
>
>
> On Tuesday, September 27, 2022 at 9:10:28 AM UTC-7 novo...@gmail.com wrote:
>>
>> On Tuesday, 27 September 2022 at 03:22:47 UTC-6 dim...@gmail.com wrote:
>>>
>>> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
>>> wrote:
>>> > this temporary directory is created and then used ever after. But what if 
>>> > it gets deleted?
>>> I think it's meant to be used in a context manager, i.e. with with
>>> statement, e.g., citing python docs:
>>>
>>> >>> with tempfile.TemporaryDirectory() as tmpdirname:
>>> ... print('created temporary directory', tmpdirname)
>>> >>>
>>> # directory and contents have been removed
>>>
>>> Or with a callback (from Sage source)
>>>
>>> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
>>> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup())
>>>
>>>
>>> Needless to say, one can interfere with it in a bad way messing around
>>> with ~/.sage/ - but so it the case for any file-based process...
>>>
>>
>> It seems to me like a pretty common and sensible practice, that /tmp 
>> directories get cleaned up, especially on systems with lots of activity. I 
>> would not consider it as "a bad way messing around". But creating a 
>> temporary directory and then counting on it being there hours later for 
>> another quick temporary operation may be a bit too optimistic. That callback 
>> is designed to clean up after Sage quits, which is a good thing to do, but 
>> it is not related to being able to use the directory.
>
> --
> 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/8400b398-f51a-4a1b-a911-32f60ef8b8fdn%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/CAAWYfq0bSZonYOjNQDJER8AxOR%3Ddq2yKt33_6GURC7XUEyeU_g%40mail.gmail.com.

Re: [sage-devel] Temporary files problems

[John H Palmieri]

On Tuesday, September 27, 2022 at 8:33:01 AM UTC-7 dim...@gmail.com wrote:

>
>
> On Tue, 27 Sep 2022, 15:45 John H Palmieri,  wrote:
>
>> One of the issues is that code in Sage is using this temporary directory 
>> in the background; the user is not doing it and has no control over it. 
>> Regardless of the context manager approach, apparently some browsers refuse 
>> to open local files that are not in the user's home directory, so this 
>> location just won't work for them.
>>
>
> tempfile.TemporaryDirectory(*suffix=None*, *prefix=None*, *dir=None*, 
> *ignore_cleanup_errors=False*)
>
>
> dir=  may be used to set a directory to place
> the created one in.
>

Exactly, and this is what we should allow users to customize, but they 
currently can't (without modifying the Sage source code).

 

On Tuesday, September 27, 2022 at 2:22:47 AM UTC-7 dim...@gmail.com wrote:
>>
>>> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
>>> wrote: 
>>> > 
>>> > Hello! 
>>> > 
>>> > I've run into this while testing upgrades to Ubuntu 22.04 from 20.04, 
>>> but it seems that it comes from how temporary files are handled in Sage 
>>> 9.7: 
>>> > 
>>> > TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory() 
>>> > 
>>> > this temporary directory is created and then used ever after. But what 
>>> if it gets deleted? 
>>> I think it's meant to be used in a context manager, i.e. with with 
>>> statement, e.g., citing python docs: 
>>>
>>> >>> with tempfile.TemporaryDirectory() as tmpdirname: 
>>> ... print('created temporary directory', tmpdirname) 
>>> >>> 
>>> # directory and contents have been removed 
>>>
>>> Or with a callback (from Sage source) 
>>>
>>> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory() 
>>> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup()) 
>>>
>>>
>>> Needless to say, one can interfere with it in a bad way messing around 
>>> with ~/.sage/ - but so it the case for any file-based process... 
>>>
>>>
>>>
>>> For example, what if someone uses tmpreaper or something similar, 
>>> when old files are removed from /tmp? Sage does not notice it, but 
>>> things break in a weird way, e.g. plots are not displayed and the 
>>> error message is not transparent. 
>>> > 
>>> > I believe this is exactly what is happening and I would appreciate 
>>> some attention to this matter ;-) 
>>> > 
>>> > Thank you! 
>>> > Andrey 
>>> > 
>>> > -- 
>>> > 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/5ee63ec7-26b2-4c32-a5a7-45fb63a11327n%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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/bcfa5eaa-600b-4752-8b52-189422564a49n%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/bce8d7cd-9a48-4bb6-8bfd-eb797225a02cn%40googlegroups.com.

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

[Matthias Koeppe]

On Tuesday, September 27, 2022 at 1:02:06 AM UTC-7 seb@gmail.com wrote:

> Furthermore, it isn’t still clear to me how dependencies between PRs will 
> be visible (like in the Trac dependencies field).
>
This is an important point. 
See https://trac.sagemath.org/ticket/30363#comment:91

 

> ​
>

-- 
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/4e8074fa-cde3-4d7f-9113-bdf87fa77ddan%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[John H Palmieri]

On Tuesday, September 27, 2022 at 10:11:00 AM UTC-7 dim...@gmail.com wrote:

> Basically, we should deprecate and remove tmp_dir() and tmp_filename() 
> from Sage. 
> Does Sagecell use them? It should not, Python3 has perfectly good 
> replacements... 
>

As long as we test everything on a variety of platforms and browsers, 
because it seems that things are broken on some platforms now. 
https://ask.sagemath.org/question/64192/temporary-html-files-location-in-sage-97/

 

>
> On Tue, Sep 27, 2022 at 6:06 PM Matthias Koeppe 
>  wrote: 
> > 
> > Previous discussion -- in the ticket that made these changes to SAGE_TMP 
> --- https://trac.sagemath.org/ticket/33213#comment:11 
> > 
> > 
> > On Tuesday, September 27, 2022 at 9:10:28 AM UTC-7 novo...@gmail.com 
> wrote: 
> >> 
> >> On Tuesday, 27 September 2022 at 03:22:47 UTC-6 dim...@gmail.com 
> wrote: 
> >>> 
> >>> On Tue, Sep 27, 2022 at 3:58 AM Andrey Novoseltsev  
> wrote: 
> >>> > this temporary directory is created and then used ever after. But 
> what if it gets deleted? 
> >>> I think it's meant to be used in a context manager, i.e. with with 
> >>> statement, e.g., citing python docs: 
> >>> 
> >>> >>> with tempfile.TemporaryDirectory() as tmpdirname: 
> >>> ... print('created temporary directory', tmpdirname) 
> >>> >>> 
> >>> # directory and contents have been removed 
> >>> 
> >>> Or with a callback (from Sage source) 
> >>> 
> >>> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory() 
> >>> atexit.register(lambda: TMP_DIR_FILENAME_BASE.cleanup()) 
> >>> 
> >>> 
> >>> Needless to say, one can interfere with it in a bad way messing around 
> >>> with ~/.sage/ - but so it the case for any file-based process... 
> >>> 
> >> 
> >> It seems to me like a pretty common and sensible practice, that /tmp 
> directories get cleaned up, especially on systems with lots of activity. I 
> would not consider it as "a bad way messing around". But creating a 
> temporary directory and then counting on it being there hours later for 
> another quick temporary operation may be a bit too optimistic. That 
> callback is designed to clean up after Sage quits, which is a good thing to 
> do, but it is not related to being able to use the directory. 
> > 
> > -- 
> > 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/8400b398-f51a-4a1b-a911-32f60ef8b8fdn%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/86132f9c-85ef-4d16-a699-0625795371f8n%40googlegroups.com.

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

[Matthias Koeppe]

On Tuesday, September 27, 2022 at 3:29:10 AM UTC-7 tobias...@gmail.com 
wrote:

> One more question: The current plan is to use the sagetrac-mirror repo as 
> the base for creating PRs but also to archived it. However, if I'm not 
> mistaken, that makes all branches in sagetrac-mirror readonly and thus one 
> cannot continue working on existing PRs by pushing to the corresponding 
> branch in sagetrac-mirror.


Thanks for catching this. I have 
revised 
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#conversion-of-trac-tickets-and-the-trac-wiki-to-github
 
as follows:

   1. Make a fork of sagemath/sagetrac-mirror called 
   sagemath/sagetrac-archive and archive 
    it 
   (= set it to readonly).
   2. Open PRs from sagemath/sagetrac-mirror 
    to the new repo for all 
   open tickets with attached branches.

 

-- 
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/be783180-49ff-4bf3-8d2d-f8db3bad749bn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Andrey Novoseltsev]

On Tuesday, 27 September 2022 at 11:11:00 UTC-6 dim...@gmail.com wrote:

> Basically, we should deprecate and remove tmp_dir() and tmp_filename() 
> from Sage. 
> Does Sagecell use them? It should not, Python3 has perfectly good 
> replacements...
>

The problems that surfaces so far that I believe these tools may not 
address on their own:
1) tmp directory is used for "too long" i.e. while Sage process is 
running,  which may be a problem if it gets automatically cleaned
2) tmp stuff is deleted "too fast" e.g. as soon as it was generated, while 
some interfaces may rely on access to generated content a bit after Sage is 
done with it, e.g. to show plots in a browser
3) default location may not work with our interfaces as well

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/faca7769-4469-4c98-aace-04ab902a370dn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Matthias Koeppe]

On Tuesday, September 27, 2022 at 10:21:15 AM UTC-7 John H Palmieri wrote:

> On Tuesday, September 27, 2022 at 8:33:01 AM UTC-7 dim...@gmail.com wrote:
>
>>
>> tempfile.TemporaryDirectory(*suffix=None*, *prefix=None*, *dir=None*, 
>> *ignore_cleanup_errors=False*)
>>
>> dir=  may be used to set a directory to place
>> the created one in.
>>
>
> Exactly, and this is what we should allow users to customize, but they 
> currently can't (without modifying the Sage source code).
>

Users can set the TMPDIR environment variable -- see
https://docs.python.org/3/library/tempfile.html#tempfile.gettempdir

-- 
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/02a23e60-181b-4e72-93ea-9c3119fc180fn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Dima Pasechnik]

On Tue, 27 Sep 2022, 18:38 Andrey Novoseltsev,  wrote:

> On Tuesday, 27 September 2022 at 11:11:00 UTC-6 dim...@gmail.com wrote:
>
>> Basically, we should deprecate and remove tmp_dir() and tmp_filename()
>> from Sage.
>> Does Sagecell use them? It should not, Python3 has perfectly good
>> replacements...
>>
>
> The problems that surfaces so far that I believe these tools may not
> address on their own:
> 1) tmp directory is used for "too long" i.e. while Sage process is
> running,  which may be a problem if it gets automatically cleaned
> 2) tmp stuff is deleted "too fast" e.g. as soon as it was generated, while
> some interfaces may rely on access to generated content a bit after Sage is
> done with it, e.g. to show plots in a browser
>

this sounds like a bad design


> 3) default location may not work with our interfaces as well
>

dir= parameter in TemporaryDirectory etc
can be used to set a better location.
This should take care of 1) 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/faca7769-4469-4c98-aace-04ab902a370dn%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/CAAWYfq3HdnnEdaXZOTY5OSzs8XeOrT4SyvpV5_9ifKyJF9dgLw%40mail.gmail.com.

[sage-devel] Re: Temporary files problems

[Matthias Koeppe]

https://manpages.ubuntu.com/manpages/bionic/man8/tmpreaper.8.html
suggests "As long as there are files present inside a subdirectory, it 
won't get removed. You can use a non-writable, self-owned file, perhaps 
named ".tmpreaper", or, if you are su, a file that has the ext2fs 
*immutable* attribute set, to keep a subdirectory from being deleted."
So perhaps we should just create such a file in TMP_DIR_FILENAME_BASE after 
creating it.

On Monday, September 26, 2022 at 7:58:01 PM UTC-7 novo...@gmail.com wrote:

> Hello!
>
> I've run into this while testing upgrades to Ubuntu 22.04 from 20.04, but 
> it seems that it comes from how temporary files are handled in Sage 9.7:
>
> TMP_DIR_FILENAME_BASE=tempfile.TemporaryDirectory()
>
> this temporary directory is created and then used ever after. But what if 
> it gets deleted? For example, what if someone uses tmpreaper or something 
> similar, when old files are removed from /tmp? Sage does not notice it, but 
> things break in a weird way, e.g. plots are not displayed and the error 
> message is not transparent.
>
> I believe this is exactly what is happening and I would appreciate some 
> attention to this matter ;-)
>
> Thank you!
> Andrey
>

-- 
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/1aaefda0-0374-44a1-b1b3-afdf789ad4ccn%40googlegroups.com.

Re: [sage-devel] Temporary files problems

[Michael Orlitzky]

On Tue, 2022-09-27 at 18:10 +0100, Dima Pasechnik wrote:
> Basically, we should deprecate and remove tmp_dir() and tmp_filename()
> from Sage.
> Does Sagecell use them? It should not, Python3 has perfectly good
> replacements...
> 

That was always the plan. From #33213:

> Afterward, the custom functions tmp_dir() and tmp_filename() can be
> deprecated in favor of tempfile.TemporaryDirectory() and 
> tempfile.NamedTemporaryFile().

That solves the problem.

-- 
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/92ac8ece46b1c27c78f76447bbf74b62e0e5fc5c.camel%40orlitzky.com.

Re: [sage-devel] Temporary files problems

[John H Palmieri]

I created https://trac.sagemath.org/ticket/34593: we should document how to 
change the location of the temporary directory, and maybe we should create 
a `.tmpreaper` file.


On Tuesday, September 27, 2022 at 11:06:01 AM UTC-7 Michael Orlitzky wrote:

> On Tue, 2022-09-27 at 18:10 +0100, Dima Pasechnik wrote:
> > Basically, we should deprecate and remove tmp_dir() and tmp_filename()
> > from Sage.
> > Does Sagecell use them? It should not, Python3 has perfectly good
> > replacements...
> > 
>
> That was always the plan. From #33213:
>
> > Afterward, the custom functions tmp_dir() and tmp_filename() can be
> > deprecated in favor of tempfile.TemporaryDirectory() and 
> > tempfile.NamedTemporaryFile().
>
> That solves the problem.
>
>

-- 
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/318737a6-85d2-4860-abf0-bb8546294660n%40googlegroups.com.

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

[Matthias Koeppe]

I've created https://github.com/sagemath/sage-gh-templates-sandbox for 
playing with Issue and PR templates.

On Friday, September 23, 2022 at 12:50:05 PM UTC-7 Matthias Koeppe wrote:

> I think part of a solution could be PR templates, which add structure to 
> the PR description (= the first comment). That could be a way of adding 
> Authors (and Reviewers) to a PR.
>
> https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates
>
> https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
>
> On Friday, September 23, 2022 at 9:51:55 AM UTC-7 Matthias Koeppe wrote:
>
>> On Friday, September 23, 2022 at 7:51:24 AM UTC-7 kcrisman wrote:
>>
>>> On the GH page documenting the transition and new workflow proposal, I 
>>> don't see a way to have multiple AUTHORs in the way we usually kept track 
>>> of it.
>>
>>
>> I agree, this still needs to be specified. (Related: 
>> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/pPqbu13fAAAJ)
>>
>>
>>
>>  
>>
>

-- 
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/301e5900-6aa7-48b1-8f99-3a1782e59c8bn%40googlegroups.com.

[sage-devel] View issues

[Ben Salisbury]

Hi all,

I'm having trouble with the view method.  For example, 

sage: G = graphs.PetersenGraph()
sage: view(G)

produced the following error. 

An error occurred.
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022) (preloaded 
format=pdflatex 2022.9.9)  17 SEP 2022 18:58
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**\nonstopmode \input{sage.tex}
(./sage.tex (/usr/local/texlive/2022/texmf-dist/tex/latex/base/article.cls
Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
(/usr/local/texlive/2022/texmf-dist/tex/latex/base/size10.clo
File: size10.clo 2021/10/04 v1.4n Standard LaTeX file (size option)
)
\c@part=\count185
\c@section=\count186
\c@subsection=\count187
\c@subsubsection=\count188
\c@paragraph=\count189
\c@subparagraph=\count190
\c@figure=\count191
\c@table=\count192
\abovecaptionskip=\skip47
\belowcaptionskip=\skip48
\bibindent=\dimen138
)
(/usr/local/texlive/2022/texmf-dist/tex/latex/amsmath/amsmath.sty
Package: amsmath 2021/10/15 v2.17l AMS math features
\@mathmargin=\skip49



! Undefined control sequence.
\@outputpage ...istfalse \@parboxrestore \shipout 
 \vbox 
{\set@typeset@protec...
l.118 \end{document}

(That makes 100 errors; please try again.) 
Here is how much of TeX's memory you used:
17546 strings out of 478268
364860 string characters out of 5846348
670991 words of memory out of 500
35436 multiletter control sequences out of 15000+60
472216 words of font info for 40 fonts, out of 800 for 9000
1141 hyphenation exceptions out of 8191
94i,9n,104p,428b,907s stack positions out of 
1i,1000n,2p,20b,20s

!  ==> Fatal error occurred, no output PDF file produced!

Latex error

Is there a known error or is my installation messed up (or something else)?

Best,
Ben

-- 
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/bb617109-e9a3-4a91-b3ac-4238c15f40f4n%40googlegroups.com.

Re: [sage-devel] View issues

[Dima Pasechnik]

On Tue, Sep 27, 2022 at 8:16 PM Ben Salisbury  wrote:
>
> Hi all,
>
> I'm having trouble with the view method.  For example,
>
> sage: G = graphs.PetersenGraph()
> sage: view(G)

works for me with Sage 9.8.beta0

>
> produced the following error.
>
> An error occurred.
> This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022) (preloaded 
> format=pdflatex 2022.9.9)  17 SEP 2022 18:58
> entering extended mode
> restricted \write18 enabled.
> %&-line parsing enabled.
> **\nonstopmode \input{sage.tex}
> (./sage.tex (/usr/local/texlive/2022/texmf-dist/tex/latex/base/article.cls
> Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
> (/usr/local/texlive/2022/texmf-dist/tex/latex/base/size10.clo
> File: size10.clo 2021/10/04 v1.4n Standard LaTeX file (size option)
> )
> \c@part=\count185
> \c@section=\count186
> \c@subsection=\count187
> \c@subsubsection=\count188
> \c@paragraph=\count189
> \c@subparagraph=\count190
> \c@figure=\count191
> \c@table=\count192
> \abovecaptionskip=\skip47
> \belowcaptionskip=\skip48
> \bibindent=\dimen138
> )
> (/usr/local/texlive/2022/texmf-dist/tex/latex/amsmath/amsmath.sty
> Package: amsmath 2021/10/15 v2.17l AMS math features
> \@mathmargin=\skip49
>
> 
>
> ! Undefined control sequence.
> \@outputpage ...istfalse \@parboxrestore \shipout
>  \vbox {\set@typeset@protec...
> l.118 \end{document}
>
> (That makes 100 errors; please try again.)
> Here is how much of TeX's memory you used:
> 17546 strings out of 478268
> 364860 string characters out of 5846348
> 670991 words of memory out of 500
> 35436 multiletter control sequences out of 15000+60
> 472216 words of font info for 40 fonts, out of 800 for 9000
> 1141 hyphenation exceptions out of 8191
> 94i,9n,104p,428b,907s stack positions out of 
> 1i,1000n,2p,20b,20s
>
> !  ==> Fatal error occurred, no output PDF file produced!
>
> Latex error
>
> Is there a known error or is my installation messed up (or something else)?
>
> Best,
> Ben
>
> --
> 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/bb617109-e9a3-4a91-b3ac-4238c15f40f4n%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/CAAWYfq0onq_G4z1H%3Dq%2B%3Dny4s5k78JYptv1%3DonV%2BMLf3aUWB9_w%40mail.gmail.com.

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

[Matthias Koeppe]

The first proposed Issue template can be seen 
here: https://github.com/sagemath/sage-gh-templates-sandbox/issues/new/choose
See 
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
 


On Tuesday, September 27, 2022 at 12:13:13 PM UTC-7 Matthias Koeppe wrote:

> I've created https://github.com/sagemath/sage-gh-templates-sandbox for 
> playing with Issue and PR templates.
>
> On Friday, September 23, 2022 at 12:50:05 PM UTC-7 Matthias Koeppe wrote:
>
>> I think part of a solution could be PR templates, which add structure to 
>> the PR description (= the first comment). That could be a way of adding 
>> Authors (and Reviewers) to a PR.
>>
>> https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates
>>
>> https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
>>
>> On Friday, September 23, 2022 at 9:51:55 AM UTC-7 Matthias Koeppe wrote:
>>
>>> On Friday, September 23, 2022 at 7:51:24 AM UTC-7 kcrisman wrote:
>>>
 On the GH page documenting the transition and new workflow proposal, I 
 don't see a way to have multiple AUTHORs in the way we usually kept track 
 of it.
>>>
>>>
>>> I agree, this still needs to be specified. (Related: 
>>> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/pPqbu13fAAAJ)
>>>
>>>
>>>
>>>  
>>>
>>

-- 
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/11b4072c-deca-457b-98a4-0da23ac6b147n%40googlegroups.com.

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

[Tobias Diez]

Just to make sure we are talking about the same thing. Imagine a currently 
open ticket with a linked branch. How is this going to be migrated? My 
assumption has been that this will create a PR from 
sagemath/sagetrac-mirror/branch into sagemath/sage.

If thats indeed the plan (which I find is a good plan), then there are the 
following issues:
- sagetrac-mirror is not a fork of sage, thus it might not be possible to 
create a PR from it (at leas from the web interface its not possible, not 
sure about the API)
- sagetrac-mirror cannot be archived otherwise it will be readonly (this is 
taken care of my Matthias recent edit to the migration wiki page)
- devs might not have the permission to push to sagetrac-mirror (currently 
there is a branch protection rule in place that prevents any direct 
commits, but even if that's removed I'm not sure if everyone can just push 
to it)

On Tuesday, 27 September 2022 at 15:29:35 UTC+2 dim...@gmail.com wrote:

>
>
> On Tue, 27 Sep 2022, 14:08 Tobias Diez,  wrote:
>
>> Yes, the target repo of these PRs will be the (new) sagemath/sage, but 
>> the source will be sagemath/sagetrac-mirror, right? 
>
>
>
> Hmm, I might have missed something - what is the need to have 2 repos 
> here, if 1 is sufficient?
>
> Any fork of sagemath/sage may be a source of a PR, not only sagetrac-mirror
>
>
> So in order to update the pull request one needs to push the changes to 
>> sagemath/sagetrac-mirror (it is not possible to update a PR by pushing to 
>> /refs/pull/xyz, because this is readonly). Thus, if sagetrac-mirror is 
>> archived (and thus readonly), the only way to work on existing 
>> tickets/branches would be to checkout the existing branch (from either 
>> sagetrac-mirror or sage/refs/pull), make changes, push to a new fork, 
>> create a new PR, close the old PR (essentially the workflow 
>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally
>> ).
>>
>> On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com wrote:
>>
>>> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez  
>>> wrote: 
>>> > 
>>> > One more question: The current plan is to use the sagetrac-mirror repo 
>>> as the base for creating PRs but also to archived it. However, if I'm not 
>>> mistaken, that makes all branches in sagetrac-mirror readonly and thus one 
>>> cannot continue working on existing PRs by pushing to the corresponding 
>>> branch in sagetrac-mirror. 
>>>
>>> IMHO the plan is to create new PRs in sagemath/sage, not in 
>>> sagemath/sagetrac-mirror 
>>> There won't be "existing" PRs, only issues, pointing to branches on 
>>> sagetrac-mirror 
>>>
>>>
>>>
>>> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com 
>>> wrote: 
>>> >> 
>>> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 
>>> UTC+2: 
>>> >>> 
>>> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote: 
>>>  
>>>  Is it possible to choose the issue numbers in GH when making a 
>>> migration? Then, setting a redirect of the form "
>>> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
>>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the 
>>> lion's share of the links still relevant. 
>>> >>> 
>>> >>> 
>>> >>> Yes, to map it like this is the plan. 
>>> >>> 
>>>  
>>>  This does not preserve fragments like "#comment:7", which is useful 
>>> in long ticket discussions. 
>>> >>> 
>>> >>> 
>>> >>> Thanks, I've opened 
>>> https://github.com/sagemath/trac-to-github/issues/7 for this. 
>>> >> 
>>> >> Don’t we need an issue for the first point, as well? The example #26 
>>> corresponds to #34110 which is not easy to recover from the migrated 
>>> information. 
>>> >> 
>>> >> Furthermore, it isn’t still clear to me how dependencies between PRs 
>>> will be visible (like in the Trac dependencies field). In the above example 
>>> you have to recover this from the history of commit messages (which may not 
>>> be clear enough in general). Shouldn’t the migration put something into the 
>>> header fields milestone, assignees, …, as well (if possible)? How will 
>>> authors and reviewers be visible? 
>>> > 
>>> > -- 
>>> > 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/d815783e-fd5c-4aa3-ab27-7024b18b299dn%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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-

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

[Dima Pasechnik]

On Tue, 27 Sep 2022, 21:12 Tobias Diez,  wrote:

> Just to make sure we are talking about the same thing. Imagine a currently
> open ticket with a linked branch. How is this going to be migrated? My
> assumption has been that this will create a PR from
> sagemath/sagetrac-mirror/branch into sagemath/sage.
>

No, there will be an issue on sagemath/sage, no PR. There will be a link to
a branch on sagetrac-mirror (which will be readonly).

To proceed, just push this branch to your personal fork of sagemath/sage
and make a PR from there.
At this point it becomes a usual github workflow.


> If thats indeed the plan (which I find is a good plan), then there are the
> following issues:
> - sagetrac-mirror is not a fork of sage, thus it might not be possible to
> create a PR from it (at leas from the web interface its not possible, not
> sure about the API)
> - sagetrac-mirror cannot be archived otherwise it will be readonly (this
> is taken care of my Matthias recent edit to the migration wiki page)
> - devs might not have the permission to push to sagetrac-mirror (currently
> there is a branch protection rule in place that prevents any direct
> commits, but even if that's removed I'm not sure if everyone can just push
> to it)
>

all this is avoided if done as I described above

Dima


> On Tuesday, 27 September 2022 at 15:29:35 UTC+2 dim...@gmail.com wrote:
>
>>
>>
>> On Tue, 27 Sep 2022, 14:08 Tobias Diez,  wrote:
>>
>>> Yes, the target repo of these PRs will be the (new) sagemath/sage, but
>>> the source will be sagemath/sagetrac-mirror, right?
>>
>>
>>
>> Hmm, I might have missed something - what is the need to have 2 repos
>> here, if 1 is sufficient?
>>
>> Any fork of sagemath/sage may be a source of a PR, not only
>> sagetrac-mirror
>>
>>
>> So in order to update the pull request one needs to push the changes to
>>> sagemath/sagetrac-mirror (it is not possible to update a PR by pushing to
>>> /refs/pull/xyz, because this is readonly). Thus, if sagetrac-mirror is
>>> archived (and thus readonly), the only way to work on existing
>>> tickets/branches would be to checkout the existing branch (from either
>>> sagetrac-mirror or sage/refs/pull), make changes, push to a new fork,
>>> create a new PR, close the old PR (essentially the workflow
>>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally
>>> ).
>>>
>>> On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com wrote:
>>>
 On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez 
 wrote:
 >
 > One more question: The current plan is to use the sagetrac-mirror
 repo as the base for creating PRs but also to archived it. However, if I'm
 not mistaken, that makes all branches in sagetrac-mirror readonly and thus
 one cannot continue working on existing PRs by pushing to the corresponding
 branch in sagetrac-mirror.

 IMHO the plan is to create new PRs in sagemath/sage, not in
 sagemath/sagetrac-mirror
 There won't be "existing" PRs, only issues, pointing to branches on
 sagetrac-mirror



 > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com
 wrote:
 >>
 >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46
 UTC+2:
 >>>
 >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2
 wrote:
 
  Is it possible to choose the issue numbers in GH when making a
 migration? Then, setting a redirect of the form "
 https://trac.sagemath.org/ticket/$TICKET_NUMBER ->
 https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the
 lion's share of the links still relevant.
 >>>
 >>>
 >>> Yes, to map it like this is the plan.
 >>>
 
  This does not preserve fragments like "#comment:7", which is
 useful in long ticket discussions.
 >>>
 >>>
 >>> Thanks, I've opened
 https://github.com/sagemath/trac-to-github/issues/7 for this.
 >>
 >> Don’t we need an issue for the first point, as well? The example #26
 corresponds to #34110 which is not easy to recover from the migrated
 information.
 >>
 >> Furthermore, it isn’t still clear to me how dependencies between PRs
 will be visible (like in the Trac dependencies field). In the above example
 you have to recover this from the history of commit messages (which may not
 be clear enough in general). Shouldn’t the migration put something into the
 header fields milestone, assignees, …, as well (if possible)? How will
 authors and reviewers be visible?
 >
 > --
 > 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 vi

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

[Matthias Koeppe]

On Tuesday, September 27, 2022 at 1:12:55 PM UTC-7 tobias...@gmail.com 
wrote:

> Just to make sure we are talking about the same thing. Imagine a currently 
> open ticket with a linked branch. How is this going to be migrated? My 
> assumption has been that this will create a PR from 
> sagemath/sagetrac-mirror/branch into sagemath/sage.
>
> If thats indeed the plan (which I find is a good plan), then there are the 
> following issues:
> - sagetrac-mirror is not a fork of sage, thus it might not be possible to 
> create a PR from it (at leas from the web interface its not possible, not 
> sure about the API)
>

Good point about the "is-fork-of" relation. I've made another refinement 
in  
https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#conversion-of-trac-tickets-and-the-trac-wiki-to-github
 :

   1. Convert all tickets to Issues in a new repo sagemath/sage-temp. (This 
   preserves the ticket numbers as Issue numbers.)
   2. Rename sagemath/sagetrac-mirror to sagemath/sagetrac-archive and 
   archive 
    it 
   (= set it to readonly).
   3. Create a single-branch fork of sagemath/sage-temp called 
   sagemath/sagetrac-mirror and push all branches (or all branches of open 
   tickets) from sagemath/sagetrac-archive to it.
   4. Open PRs from sagemath/sagetrac-mirror 
    to sagemath/sage-temp for 
   all open tickets with attached branches.


-- 
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/32619c62-5234-4b75-98ef-c653f0293865n%40googlegroups.com.

Re: [sage-devel] View issues

[John H Palmieri]

If you do `view(G, debug=True)`, it will first print out the entire LaTeX 
file that it's using. You could paste that into an actual file and see if 
you can pin down what the error is, and whether it's coming from your TeX 
installation or somewhere else.


On Tuesday, September 27, 2022 at 12:32:38 PM UTC-7 dim...@gmail.com wrote:

> On Tue, Sep 27, 2022 at 8:16 PM Ben Salisbury  wrote:
> >
> > Hi all,
> >
> > I'm having trouble with the view method. For example,
> >
> > sage: G = graphs.PetersenGraph()
> > sage: view(G)
>
> works for me with Sage 9.8.beta0
>
> >
> > produced the following error.
> >
> > An error occurred.
> > This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022) 
> (preloaded format=pdflatex 2022.9.9) 17 SEP 2022 18:58
> > entering extended mode
> > restricted \write18 enabled.
> > %&-line parsing enabled.
> > **\nonstopmode \input{sage.tex}
> > (./sage.tex 
> (/usr/local/texlive/2022/texmf-dist/tex/latex/base/article.cls
> > Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
> > (/usr/local/texlive/2022/texmf-dist/tex/latex/base/size10.clo
> > File: size10.clo 2021/10/04 v1.4n Standard LaTeX file (size option)
> > )
> > \c@part=\count185
> > \c@section=\count186
> > \c@subsection=\count187
> > \c@subsubsection=\count188
> > \c@paragraph=\count189
> > \c@subparagraph=\count190
> > \c@figure=\count191
> > \c@table=\count192
> > \abovecaptionskip=\skip47
> > \belowcaptionskip=\skip48
> > \bibindent=\dimen138
> > )
> > (/usr/local/texlive/2022/texmf-dist/tex/latex/amsmath/amsmath.sty
> > Package: amsmath 2021/10/15 v2.17l AMS math features
> > \@mathmargin=\skip49
> >
> > 
> >
> > ! Undefined control sequence.
> > \@outputpage ...istfalse \@parboxrestore \shipout
> > \vbox {\set@typeset@protec...
> > l.118 \end{document}
> >
> > (That makes 100 errors; please try again.)
> > Here is how much of TeX's memory you used:
> > 17546 strings out of 478268
> > 364860 string characters out of 5846348
> > 670991 words of memory out of 500
> > 35436 multiletter control sequences out of 15000+60
> > 472216 words of font info for 40 fonts, out of 800 for 9000
> > 1141 hyphenation exceptions out of 8191
> > 94i,9n,104p,428b,907s stack positions out of 
> 1i,1000n,2p,20b,20s
> >
> > ! ==> Fatal error occurred, no output PDF file produced!
> >
> > Latex error
> >
> > Is there a known error or is my installation messed up (or something 
> else)?
> >
> > Best,
> > Ben
> >
> > --
> > 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/bb617109-e9a3-4a91-b3ac-4238c15f40f4n%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/754cd816-2a30-4d41-b03d-b982d84a159dn%40googlegroups.com.

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

[Tobias Diez]

Okay, fair enough! Then it's a bit more work to get tickets into PRs (for 
devs) but maybe its a good idea to start with a clean slate.

On Tuesday, 27 September 2022 at 22:31:57 UTC+2 dim...@gmail.com wrote:

>
>
> On Tue, 27 Sep 2022, 21:12 Tobias Diez,  wrote:
>
>> Just to make sure we are talking about the same thing. Imagine a 
>> currently open ticket with a linked branch. How is this going to be 
>> migrated? My assumption has been that this will create a PR from 
>> sagemath/sagetrac-mirror/branch into sagemath/sage.
>>
>
> No, there will be an issue on sagemath/sage, no PR. There will be a link 
> to a branch on sagetrac-mirror (which will be readonly). 
>
> To proceed, just push this branch to your personal fork of sagemath/sage 
> and make a PR from there.
> At this point it becomes a usual github workflow.
>
>
>> If thats indeed the plan (which I find is a good plan), then there are 
>> the following issues:
>> - sagetrac-mirror is not a fork of sage, thus it might not be possible to 
>> create a PR from it (at leas from the web interface its not possible, not 
>> sure about the API)
>> - sagetrac-mirror cannot be archived otherwise it will be readonly (this 
>> is taken care of my Matthias recent edit to the migration wiki page)
>> - devs might not have the permission to push to sagetrac-mirror 
>> (currently there is a branch protection rule in place that prevents any 
>> direct commits, but even if that's removed I'm not sure if everyone can 
>> just push to it)
>>
>
> all this is avoided if done as I described above 
>
> Dima
>
>
>> On Tuesday, 27 September 2022 at 15:29:35 UTC+2 dim...@gmail.com wrote:
>>
>>>
>>>
>>> On Tue, 27 Sep 2022, 14:08 Tobias Diez,  wrote:
>>>
 Yes, the target repo of these PRs will be the (new) sagemath/sage, but 
 the source will be sagemath/sagetrac-mirror, right? 
>>>
>>>
>>>
>>> Hmm, I might have missed something - what is the need to have 2 repos 
>>> here, if 1 is sufficient?
>>>
>>> Any fork of sagemath/sage may be a source of a PR, not only 
>>> sagetrac-mirror
>>>
>>>
>>> So in order to update the pull request one needs to push the changes to 
 sagemath/sagetrac-mirror (it is not possible to update a PR by pushing to 
 /refs/pull/xyz, because this is readonly). Thus, if sagetrac-mirror is 
 archived (and thus readonly), the only way to work on existing 
 tickets/branches would be to checkout the existing branch (from either 
 sagetrac-mirror or sage/refs/pull), make changes, push to a new fork, 
 create a new PR, close the old PR (essentially the workflow 
 https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally
 ).

 On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com wrote:

> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez  
> wrote: 
> > 
> > One more question: The current plan is to use the sagetrac-mirror 
> repo as the base for creating PRs but also to archived it. However, if 
> I'm 
> not mistaken, that makes all branches in sagetrac-mirror readonly and 
> thus 
> one cannot continue working on existing PRs by pushing to the 
> corresponding 
> branch in sagetrac-mirror. 
>
> IMHO the plan is to create new PRs in sagemath/sage, not in 
> sagemath/sagetrac-mirror 
> There won't be "existing" PRs, only issues, pointing to branches on 
> sagetrac-mirror 
>
>
>
> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com 
> wrote: 
> >> 
> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 
> UTC+2: 
> >>> 
> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 
> wrote: 
>  
>  Is it possible to choose the issue numbers in GH when making a 
> migration? Then, setting a redirect of the form "
> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
> https://github.com/sagemath/sage/issues/$TICKET_NUMBER"; will make the 
> lion's share of the links still relevant. 
> >>> 
> >>> 
> >>> Yes, to map it like this is the plan. 
> >>> 
>  
>  This does not preserve fragments like "#comment:7", which is 
> useful in long ticket discussions. 
> >>> 
> >>> 
> >>> Thanks, I've opened 
> https://github.com/sagemath/trac-to-github/issues/7 for this. 
> >> 
> >> Don’t we need an issue for the first point, as well? The example 
> #26 corresponds to #34110 which is not easy to recover from the migrated 
> information. 
> >> 
> >> Furthermore, it isn’t still clear to me how dependencies between 
> PRs will be visible (like in the Trac dependencies field). In the above 
> example you have to recover this from the history of commit messages 
> (which 
> may not be clear enough in general). Shouldn’t the migration 

[sage-devel] Weird behaviour of Matrix_cyclo_dense

[alexKar]

Hi all,

Having trouble with the matrix multiplication which I first explained 
in 
https://ask.sagemath.org/question/64194/determinants-over-cyclotomic-fields-are-broken/
If I define two matrices (L and U) over CyclotomicField and then multiply 
then like L*U and via the definition then the results are sometimes 
different. An example is:

K. = CyclotomicField(16)
OK = K.ring_of_integers()
L = [[-575*z^7 - 439*z^6 - 237*z^5 + 237*z^3 + 439*z^2 + 575*z + 623, 0],
[0, -114*z^7 - 88*z^6 - 48*z^5 + 48*z^3 + 88*z^2 + 114*z + 123]]
U = [[-1926*z^7 - 1474*z^6 - 798*z^5 + 798*z^3 + 1474*z^2 + 1926*z + 2085, 
0],
[0,   -1014*z^7 - 777*z^6 - 421*z^5 + 421*z^3 + 777*z^2 + 1014*z + 1097]]
L, U = matrix(K,L), matrix(K,U)
LU = matrix( [ [L[i].inner_product(U.transpose()[j]) for j in range(2)] for 
i in range(2)] )
assert LU == L*U

Where the last assertion must clearly sucseed but it doesn't.

Note: if I define L, U = matrix(K,L), matrix(K,U) then the matrices are no 
longer Matrix_cyclo_dense but Matrix_generic_dense and the last assertion 
sucseeds!

Checked that one on Ubuntu 22.04.01 and MacOS on sage 9.4, 9.5 and 9.6. Is 
this the known issue? Am doing it wrong?

Kind regards,
Alexander

-- 
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/44f0ff3c-71db-4555-a494-80b2ae222c22n%40googlegroups.com.