How are merge conflicts handled, and is there any use for priority-flag on
trac? It would make sense that lower priority tickets would be merged
after more important ones.
--
Jori Mäntysalo
I get the same on my Ubuntu desktop with essentially the same log.
Best,
Travis
On Monday, February 19, 2018 at 5:29:18 PM UTC+10, vdelecroix wrote:
>
> Dear all,
>
> The optional package gambit does not build on my machine (the quasar
> patchbot). See log attached.
>
> Best
> Vincent
>
--
On Wednesday, January 27, 2016 at 12:47:58 AM UTC+9, Volker Braun wrote:
>
> It doesn't work right now; The kernel doesn't know whether it is running
> under jupyter or jupyterhub.
>
After lots of trial and errors, I managed to make sagemath work under
Jupyterhub. One cause of constant confusi
IMHO the evils of trailing whitespace are greatly exagerrated.
The eaisest solution is to just fix your editor to not introduce changes
that you did not make yourself.
If you think fighting the windmills of trailing whitespace is a worthwhile
use of your time, be my guest. But I want a workflow
If I recall, when I originally setup the git-trac server, I included a hook
that would reject/warn any introduction of new trailing whitespace. I
believe this was a compromise made after a long discussion at a Sage days
-- there were a lot of concerns at the time about the effort required to
rebase
Interesting fact: the number of lines with trailing whitespace is
generally *increasing* with every Sage release. So it seems to me that
the biggest problem (if you find whitespace a problem) is preventing new
whitespace.
--
You received this message because you are subscribed to the Google Gr
On 2018-02-20 14:16, Erik Bray wrote:
I'd be completely fine with that so long as no one complains about
otherwise irrelevant whitespace cleanup coming along for the ride in
my tickets.
To clarify, I'm fine with this too if it's not too much in one branch
(this is of course very subjective).
First of all, we should ensure that no new trailing whitespace is added.
Otherwise, your effort is futile. The recently added file
src/sage/rings/valuation/valuation_space.py is a bad example.
I recall that we had a discussion about autogenerated patchbombs not so
long ago. I think it's a bad
On Monday, February 19, 2018 at 2:29:18 AM UTC-5, vdelecroix wrote:
>
> Dear all,
>
> The optional package gambit does not build on my machine (the quasar
> patchbot). See log attached.
>
>
I've emailed one of the people responsible for initially getting gambit in
Sage; hopefully it's a minor
On Sat, Feb 17, 2018 at 8:22 AM, Ralf Stephan wrote:
> I'm afraid the issue is more complicated.
>
> On Friday, February 16, 2018 at 5:04:30 PM UTC+1, Erik Bray wrote:
>>
>> On Python 2 this works:
>>
>> sage: bool(pi <= pi)
>> True
>>
>> This works fine because the Constant class implements __eq_
On Sat, Feb 17, 2018 at 8:47 AM, Ralf Stephan wrote:
> On Saturday, February 17, 2018 at 8:22:13 AM UTC+1, Ralf Stephan wrote:
>>
>> This baffles me and I would like to know why the computation differs from
>> the above.
>
>
> Ah ok, _richcmp_ is Py2 specific. Then we want to do the symbolic check
On Tuesday, February 20, 2018 at 12:28:27 PM UTC, vdelecroix wrote:
>
> On 20/02/2018 13:21, Vincent Delecroix wrote:
> > Bonjour Luca,
> >
> > On 17/02/2018 00:32, Luca De Feo wrote:
> >> I'm having trouble compiling 8.2.beta5 on Arch. Compiling with `make
> >> build -k`: flint and r fail,
On Tue, Feb 20, 2018 at 1:58 PM, Travis Scrimshaw wrote:
>
>
> On Tuesday, February 20, 2018 at 5:04:26 AM UTC-6, Erik Bray wrote:
>>
>> How do we feel about large patches full of whitespace cleanup? Lots
>> of Sage modules have stray whitespace, and my editor usually
>> automatically removes it
On Tuesday, February 20, 2018 at 5:04:26 AM UTC-6, Erik Bray wrote:
>
> How do we feel about large patches full of whitespace cleanup? Lots
> of Sage modules have stray whitespace, and my editor usually
> automatically removes it when I open files (this is a personal
> preference that I have
On Tue, Feb 20, 2018 at 1:44 PM, John Cremona wrote:
> Would this help?
> https://stackoverflow.com/questions/9776527/merging-without-whitespace-conflicts
>
> In brief: git merge -Xignore-space-change
>
> There is also a reference there to a commit hook which removes trailing
> whitespace.
+1 F
Would this help?
https://stackoverflow.com/questions/9776527/merging-without-whitespace-conflicts
In brief: git merge -Xignore-space-change
There is also a reference there to a commit hook which removes trailing
whitespace.
On 20 February 2018 at 12:23, Vincent Delecroix <20100.delecr...@gmail
On 20/02/2018 13:21, Vincent Delecroix wrote:
Bonjour Luca,
On 17/02/2018 00:32, Luca De Feo wrote:
I'm having trouble compiling 8.2.beta5 on Arch. Compiling with `make
build -k`: flint and r fail, because of some weird missing symbol in
libguile-2.2
make: symbol lookup error: /usr/lib/li
On 20/02/2018 12:45, Erik Bray wrote:
On Tue, Feb 20, 2018 at 12:22 PM, Daniel Krenn wrote:
On 2018-02-20 12:07, Simon King wrote:
Why not doing such cleanup right before releasing a beta version?
Or even better, right before a release, e.g. doing it for a rc0 or rc1.
That was my thinking
Bonjour Luca,
On 17/02/2018 00:32, Luca De Feo wrote:
I'm having trouble compiling 8.2.beta5 on Arch. Compiling with `make
build -k`: flint and r fail, because of some weird missing symbol in
libguile-2.2
make: symbol lookup error: /usr/lib/libguile-2.2.so.1: undefined
symbol: GC_move_disa
> We have already seen that before, in the last month I think. Your version
> of make is compiled with guile support.
> The compilation breaks because “make" itself breaks. flint and R use
> LD_LIBRARY_PATH in their build system and make loses touch with some
> of the libraries it has been compiled
On Tue, Feb 20, 2018 at 12:22 PM, Daniel Krenn wrote:
> On 2018-02-20 12:07, Simon King wrote:
>> Why not doing such cleanup right before releasing a beta version?
>
> Or even better, right before a release, e.g. doing it for a rc0 or rc1.
That was my thinking as well--I'm sure Volker and I could
On 2018-02-20 12:07, Simon King wrote:
> Why not doing such cleanup right before releasing a beta version?
Or even better, right before a release, e.g. doing it for a rc0 or rc1.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from
Why not doing such cleanup right before releasing a beta version?
On 2018-02-20, Erik Bray wrote:
> How do we feel about large patches full of whitespace cleanup? Lots
> of Sage modules have stray whitespace, and my editor usually
> automatically removes it when I open files (this is a personal
How do we feel about large patches full of whitespace cleanup? Lots
of Sage modules have stray whitespace, and my editor usually
automatically removes it when I open files (this is a personal
preference that I have to live with though).
Usually when preparing patches this means manually removing
24 matches
Mail list logo
