[sage-devel] Re: patchbot says ValueError: {} inserted on {} non-empty lines
Oups, I wanted to post this on sage-devel. Sorry.
Sébastien
On Tuesday, December 22, 2015 at 10:30:10 PM UTC+1, Sébastien Labbé wrote:
>
> Hello patchbot developers,
>
> At http://patchbot.sagemath.org/ticket/13580/, before the doctest
> continuation problem was fixed, the patchbot was returning an incomplete
> error message (see below). Maybe it would be better to
>
> raise ValueError(full_msg.format(something here))
>
> ?
>
> == plugins.doctest_continuation ==
> git checkout patchbot/ticket_merged
> Already on 'patchbot/ticket_merged'
> inside file: b/src/sage/combinat/backtrack.py
> @@ -689,6 +691,33 @@ class SearchForest(Parent):
> +...lambda (li, sum, _): y**sum, lambda x,y: x + y, 0 )
> Old-style doctest continuation inserted on 1 non-empty lines
> Traceback (most recent call last):
> File "/home/worker/sage-patchbot/local/bin/patchbot/patchbot.py", line 974,
> in test_a_ticket
> baseline=baseline, **kwds)
> File "/home/worker/sage-patchbot/local/bin/patchbot/plugins.py", line 315,
> in doctest_continuation
> msg="Old-style doctest continuation", **kwds)
> File "/home/worker/sage-patchbot/local/bin/patchbot/plugins.py", line 195,
> in exclude_new
> raise ValueError(full_msg)
> ValueError: {} inserted on {} non-empty lines
> plugins.doctest_continuation -- 0 seconds
> == end plugins.doctest_continuation ==
>
> Available at:
> http://patchbot.sagemath.org/log/13580/Gentoo%20Base%20System/2.2/x86_64/3.2.1-gentoo-r2/sage4/2015-12-15%2013:14:59?plugin=plugins.doctest_continuation
>
>
> Sébastien
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Jupyter notebook by default?
On Tuesday, December 22, 2015 at 9:16:55 PM UTC+1, Nils Bruin wrote: > > We could make the UX more consistent by "preinstalling" a migration ipy > notebook. > Into which directory are we going to put that MigrateFromSagenb.ipynb file? > In fact, that notebook could include code to open and read the sagenb > worksheets (jupyter kernels don't run chrooted by default, right? so their > code can still access HOME/.sagenb) > The kernel and the file browser ui are two separate components, potentially running on separate computers. The kernel can execute arbitrary code (and access ~/.sage if the OS allows), the file browser is restricted to the directory tree below the startup 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Jupyter notebook by default?
On Sunday, December 20, 2015 at 10:40:23 PM UTC-10, Volker Braun wrote: > > On Monday, December 21, 2015 at 5:16:44 AM UTC+1, Nils Bruin wrote: >> >> different notebook. We could possibly alleviate the problem of lack of >> information by somehow guessing if this is the first time this user starts >> up sage ipython notebook >> > > Thats inconsistent UX, now you open different notebooks on different > computers / accounts. Unless you mean: print help to the terminal. The > ticket does that already. > The reason why I expect that printing on the terminal is insufficient, is because most notebook users will not look there at all: they're just looking at the browser that pops up. There are quite some precedents for informational pop-ups: firefox and chrome are usually quite insistent on start-up to ask you about migrating information to themselves and/or selecting them as default browser. We could make the UX more consistent by "preinstalling" a migration ipy notebook. In fact, that notebook could include code to open and read the sagenb worksheets (jupyter kernels don't run chrooted by default, right? so their code can still access HOME/.sagenb) and help with translating the worksheets. The main scenario is that of single-user notebooks. multi-user setups don't translate easily to jupyter anyway, so a more manual translation approach will be required anyway. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Patchbot's PluginFailed plugins.startup_modules failure
Hello, this may be caused by the fact that currently the "develop" branch is 6.10, which is also "base", ie not a beta release. The patchbot has some troubles every time one reaches this situation. You can probably safely ignore it. Having a green light is not mandatory, and the bot is only there to help real people find problems in their code. Frederic Le jeudi 17 décembre 2015 15:19:28 UTC+1, fhivert a écrit : > > Hi there, > > Working on #13580 I'm getting a plugins.startup_modules failure. I don't > understand why, knowing that: > > - the goal of this patch is to I create a new file namely > sage/parallel/map_reduce.py whose main entry is the class > RESetMapReduce. > > - I'm *not importing* RESetMapReduce at Sage's top level. > > - except for advanced use, it is supposed to be used through the > map_reduce method of the class RecursivelyEnumeratedSets. > > - it is lazily imported when called this method. More precisely the code > is: > > def map_reduce(self, [...]): > r""" > Apply a Map/Reduce algorithm on ``self`` > > [...] > """ > import sage.parallel.map_reduce > return sage.parallel.map_reduce.RESetMapReduce( > forest = self, > map_function = map_function, > reduce_function = reduce_function, > reduce_init = reduce_init).run() > > So I'm not changing anything at Sage's startup, do I ? > > What should I do to please the patchbot ? > > Cheers, > > Florent > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] modulo operators (integers, rationals, real numbers)
Hi sage-devel,
I think 1) should be the default but I find myself needing 2) quite a
bit these days (also for integers)
Cheers,
Martin
Vincent Delecroix writes:
> Hello,
>
> While responding to this ask question
>
> http://ask.sagemath.org/question/31740/why-112321-and-111320
>
> I discovered some inconsistencies with the modulo operators in Sage. We
> indeed have three coexisting definitions for x % y
>
> 1) the unique x' between [0,y) of the form x + ny (used when both x
> and y are integers)
>
> 2) the unique x' between (-y/2, y/2] of the form x+ny (used when x is
> a float)
>
> 3) the result of an operation in Zmod(y) and a lift to {0, ..., y-1}
> (used when x is a rational and y a float)
>
> I would suggest to always use 1) but I am not sure if my opinion is
> shared by many mathematicians and Sage programmers...
>
> Best,
> Vincent
--
_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
Re: [sage-devel] modulo operators (integers, rationals, real numbers)
On 2015-12-22 00:31, Vincent Delecroix wrote: > 1) the unique x' between [0,y) of the form x + ny (used when both x > and y are integers) +1 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] modulo operators (integers, rationals, real numbers)
On 2015-12-22 09:59, Jori Mäntysalo wrote: Other option would be to remove it for non-integer arguments. -1 Modulo can be useful for floating-point numbers and it makes sense mathematically. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] modulo operators (integers, rationals, real numbers)
On Mon, 21 Dec 2015, Vincent Delecroix wrote: I discovered some inconsistencies with the modulo operators in Sage. We indeed have three coexisting definitions for x % y 1) the unique x' between [0,y) of the form x + ny (used when both x and y are integers) 2) the unique x' between (-y/2, y/2] of the form x+ny (used when x is a float) I would suggest to always use 1) but I am not sure if my opinion is shared by many mathematicians and Sage programmers... At least for me this was a surprise. And I don't like surprises, at least not after yule. Other option would be to remove it for non-integer arguments. -- Jori Mäntysalo
