Re: [sage-devel] Whitespace patchbombs

[Jori Mäntysalo]

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

[sage-devel] Re: gambit does not build (sage 8.2.beta6)

[Travis Scrimshaw]

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 
>

-- 
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: jsmol broken on JupyterHub

[Kwankyu Lee]

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 confusion was that these jsmol, threejs, 
mathjax are served at /nbextensions. These are not proper nbextensions in 
Jupyter notebook ecosystem, but just static files. I suppose the proper 
place to serve them is /static, like /static/jsmol,  

Fortunately we can use a Jupyter notebook option to serve /static from 
arbitrary directory that contains jsmol, threejs, and mathjax:

c.NotebookApp.extra_static_paths = ["/path/to/extra/static/files"]

I guess that with some changes mainly replacing "/nbextensions" to 
"/static",  sage 3d and interact outputs all would work fine. 

Jupyterhub serves static files at /hub/static, so it would be necessary to 
forward(alias) /static to /hub/static for sage 3d and interact outputs to 
work. 

-- 
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: Whitespace patchbombs

[Volker Braun]

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 where I don't have to 
bother with trailing whitespace, so you better have git hooks to auto-fix 
everything on commit etc.



On Tuesday, February 20, 2018 at 12:04:26 PM UTC+1, 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 to live with though). 
>
> Usually when preparing patches this means manually removing such 
> distracting whitespace cleanup, though all that means is then removing 
> it again, and again, and again... (or sometimes I will just leave it 
> in a commit if it's just one or two lines). 
>
> It might be nice to just clean up a whole lot of this at once, but I 
> think that would require some coordination so as to not create too 
> many trivial merge conflicts... 
>
> Thanks, 
> E 
>

-- 
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] Whitespace patchbombs

[R. Andrew Ohana]

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 mercurial patches with conflicts arising from a whitespace
patchbomb. I also believe that we included in the documentation and server
side hook a suggestion to use the trailing whitespace stripping commit hook
(and there was a sage-dev command that would automatically do that,
although sage-dev has now been removed in favor of vanilla git or Volker's
git trac).

On Tue, Feb 20, 2018 at 12:47 PM, Jeroen Demeyer  wrote:

> 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 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.
>



-- 
Andrew

-- 
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] Whitespace patchbombs

[Jeroen Demeyer]

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 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: Whitespace patchbombs

[Jeroen Demeyer]

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).


--
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] Whitespace patchbombs

[Jeroen Demeyer]

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 idea because it can potentially generate a 
lot of silly merge conflicts. Why not remove it as part of the usual 
workflow, for example when refactoring something anyway? I generally 
don't mind if a ticket makes a bunch of whitespace changes (as long as 
it's not dominating the diff).


By the way, the situation is not too bad: only 19 files have 20 or more 
lines with trailing whitespace. One file that stands out is 
functions/piecewise_old.py with 244 lines.


--
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: gambit does not build (sage 8.2.beta6)

[kcrisman]

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 issue to fix, or unique to some unusual Python 
setup. 

-- 
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: How should ordering of constants be defined?

[Erik Bray]

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__, and so
>> if asking if pi <= pi that's good enough for it.
>
>
> Actually Constants.__eq__ is never called here. Pi is an expression not a
> constant. With expression relations ultimately Expression.__nonzero__ does
> all the work. It calls OP(pi.pyobject(), pi.pyobject()) with OP =
> operator.le. This calls Expression._richcmp_(pi, pi, Py_LT) (why?) which
> consults Pynac. Pynac checks if LHS-RHS is trivially zero which it is and
> returns True. No floating point involved, just symbolics.

Right, but pi.pyobject() is sage.symbolic.constants.Pi, a subclass of
Constant, so this invokes Constant.__le__ (when we call __nonzero__)
which isn't defined on Python 3 (on Python 2 it has a default
implementation that first checks equality at least, and then falls
back on a nonsensical < implementation).

-- 
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: How should ordering of constants be defined?

[Erik Bray]

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
> before the inexact ones by changing Expression.__nonzero__(). Please cc me
> on the ticket.

I haven't made a ticket yet, I don't think, but I will when I do.

-- 
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] Error compiling Sage: undefined symbol GC_move_disappearing_link

[Dima Pasechnik]

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, 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_disappearing_link 
> >> 
> >> I don't even understand where Guile is supposed to be used. I can 
> >> compile flint alone without problems. Any ideas? 
> > 
> > Please have a look at 
> > 
> >https://trac.sagemath.org/ticket/24575 
>
> And concerning a fix, have a look at the attached patch. 
>

This patch will break ecl, and so everything that uses Lisp: maxima (and 
quite a bit of calulus) first of all.

The core problem is wrong library versioning on your Linux systems, I 
gather, it has nothing to do with gc.


> Vincent 
>

-- 
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: Whitespace patchbombs

[Erik Bray]

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 when I open files (this is a personal
>> preference that I have to live with though).
>>
>> Usually when preparing patches this means manually removing such
>> distracting whitespace cleanup, though all that means is then removing
>> it again, and again, and again... (or sometimes I will just leave it
>> in a commit if it's just one or two lines).
>>
>> It might be nice to just clean up a whole lot of this at once, but I
>> think that would require some coordination so as to not create too
>> many trivial merge conflicts...
>>
> What about more of a middle ground where any file you touch and your editor
> does whitespace cleanup, then you can merge it into that ticket. That way it
> puts conflict in files that would possibly have conflicts anyways, but it
> does not make your workflow harder. Although in a broad sense, I do not
> oppose a big cleanup, but I do slightly worry about it creating too many
> undue trivial merge conflicts with branches that otherwise would work,
> pre-(beta-)release or otherwise.

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.  I'll point out also that the cgit diff viewer allows
setting whitespace=ignore when viewing branch diffs.

-- 
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: Whitespace patchbombs

[Travis Scrimshaw]

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 to live with though). 
>
> Usually when preparing patches this means manually removing such 
> distracting whitespace cleanup, though all that means is then removing 
> it again, and again, and again... (or sometimes I will just leave it 
> in a commit if it's just one or two lines). 
>
> It might be nice to just clean up a whole lot of this at once, but I 
> think that would require some coordination so as to not create too 
> many trivial merge conflicts... 
>
> What about more of a middle ground where any file you touch and your 
editor does whitespace cleanup, then you can merge it into that ticket. 
That way it puts conflict in files that would possibly have conflicts 
anyways, but it does not make your workflow harder. Although in a broad 
sense, I do not oppose a big cleanup, but I do slightly worry about it 
creating too many undue trivial merge conflicts with branches that 
otherwise would work, pre-(beta-)release or otherwise.

Best,
Travis

 

-- 
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: Whitespace patchbombs

[Erik Bray]

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 For the release manager who actually does the merges this is
probably useful.  Though we would also have to add it to the Sage Trac
plugin and patchbot so that they don't show branches as unmergeable
(and at least for some branches we do want to see whitespace changes,
so I'm not exactly sure how best to manage that)

> On 20 February 2018 at 12:23, Vincent Delecroix <20100.delecr...@gmail.com>
> wrote:
>>
>> 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 as well--I'm sure Volker and I could coordinate
>>> something like that.
>>>
>>> However, it could still leave plenty of open tickets with otherwise
>>> good (but as yet unmerged) branches with trivial merge conflicts :/
>>
>>
>> Indeed, this is the problem. Further patches would not apply for
>> trivial reason. To my mind the best would be to get rid of trailing
>> whitespaces once and forever (ie not accepting branches with trailing
>> whitespaces).
>>
>> Vincent
>>
>>
>> --
>> 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.
>
>
> --
> 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.

-- 
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: Whitespace patchbombs

[John Cremona]

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.com>
wrote:

> 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 as well--I'm sure Volker and I could coordinate
>> something like that.
>>
>> However, it could still leave plenty of open tickets with otherwise
>> good (but as yet unmerged) branches with trivial merge conflicts :/
>>
>
> Indeed, this is the problem. Further patches would not apply for
> trivial reason. To my mind the best would be to get rid of trailing
> whitespaces once and forever (ie not accepting branches with trailing
> whitespaces).
>
> Vincent
>
>
> --
> 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.
>

-- 
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] Error compiling Sage: undefined symbol GC_move_disappearing_link

[Vincent Delecroix]

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/libguile-2.2.so.1: undefined
symbol: GC_move_disappearing_link

I don't even understand where Guile is supposed to be used. I can
compile flint alone without problems. Any ideas?


Please have a look at

   https://trac.sagemath.org/ticket/24575


And concerning a fix, have a look at the attached patch.

Vincent

--
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.
>From 172a624b6e8900648c5f2dd779b9f23147673c90 Mon Sep 17 00:00:00 2001
From: Vincent Delecroix <20100.delecr...@gmail.com>
Date: Tue, 20 Feb 2018 13:25:11 +0100
Subject: [PATCH] disable gc patch

---
 build/pkgs/ecl/dependencies   | 2 +-
 build/pkgs/gc/type| 2 +-
 build/pkgs/libhomfly/dependencies | 1 -
 3 files changed, 2 insertions(+), 3 deletions(-)
 delete mode 100644 build/pkgs/libhomfly/dependencies

diff --git a/build/pkgs/ecl/dependencies b/build/pkgs/ecl/dependencies
index ce10f9c1f9..c75216c320 100644
--- a/build/pkgs/ecl/dependencies
+++ b/build/pkgs/ecl/dependencies
@@ -1,4 +1,4 @@
-$(MP_LIBRARY) readline gc
+$(MP_LIBRARY) readline
 
 --
 All lines of this file are ignored except the first.
diff --git a/build/pkgs/gc/type b/build/pkgs/gc/type
index a6a7b9cd72..134d9bc32d 100644
--- a/build/pkgs/gc/type
+++ b/build/pkgs/gc/type
@@ -1 +1 @@
-standard
+optional
diff --git a/build/pkgs/libhomfly/dependencies b/build/pkgs/libhomfly/dependencies
deleted file mode 100644
index 65b64fcf3f..00
--- a/build/pkgs/libhomfly/dependencies
+++ /dev/null
@@ -1 +0,0 @@
-gc
-- 
2.16.1

Re: [sage-devel] Re: Whitespace patchbombs

[Vincent Delecroix]

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 as well--I'm sure Volker and I could coordinate
something like that.

However, it could still leave plenty of open tickets with otherwise
good (but as yet unmerged) branches with trivial merge conflicts :/


Indeed, this is the problem. Further patches would not apply for
trivial reason. To my mind the best would be to get rid of trailing
whitespaces once and forever (ie not accepting branches with trailing
whitespaces).

Vincent

--
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] Error compiling Sage: undefined symbol GC_move_disappearing_link

[Vincent Delecroix]

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_disappearing_link

I don't even understand where Guile is supposed to be used. I can
compile flint alone without problems. Any ideas?


Please have a look at

  https://trac.sagemath.org/ticket/24575

Vincent

--
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] Error compiling Sage: undefined symbol GC_move_disappearing_link

[Luca De Feo]

> 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 with in favour of some in
> SAGE_LOCAL/lib/

I'm not sure I fully understand the explanation. Which library does
`make` lose touch with? Guile? There is lo libguile in SAGE_LOCAL/lib.

Anyway, do you know a fix?

Thanks,
Luca

-- 
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: Whitespace patchbombs

[Erik Bray]

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 coordinate
something like that.

However, it could still leave plenty of open tickets with otherwise
good (but as yet unmerged) branches with trivial merge conflicts :/

-- 
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: Whitespace patchbombs

[Daniel Krenn]

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 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: Whitespace patchbombs

[Simon King]

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
> preference that I have to live with though).
>
> Usually when preparing patches this means manually removing such
> distracting whitespace cleanup, though all that means is then removing
> it again, and again, and again... (or sometimes I will just leave it
> in a commit if it's just one or two lines).
>
> It might be nice to just clean up a whole lot of this at once, but I
> think that would require some coordination so as to not create too
> many trivial merge conflicts...
>
> Thanks,
> E
>

-- 
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] Whitespace patchbombs

[Erik Bray]

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 such
distracting whitespace cleanup, though all that means is then removing
it again, and again, and again... (or sometimes I will just leave it
in a commit if it's just one or two lines).

It might be nice to just clean up a whole lot of this at once, but I
think that would require some coordination so as to not create too
many trivial merge conflicts...

Thanks,
E

-- 
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.