On Feb 21, 2015 9:32 AM, "Volker Braun" wrote:
>
> Followups to sage-flame please...
>
I strongly agree.
>
> On Saturday, February 21, 2015 at 6:14:33 PM UTC+1, Felix Salfelder wrote:
>>
>> Hi Volker.
>>
>> actually i anticipate that you know better. anyway i reply. again. just
>> for the record
Followups to sage-flame please...
On Saturday, February 21, 2015 at 6:14:33 PM UTC+1, Felix Salfelder wrote:
>
> Hi Volker.
>
> actually i anticipate that you know better. anyway i reply. again. just
> for the record.
>
> On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote:
> > That
Hi Volker.
actually i anticipate that you know better. anyway i reply. again. just
for the record.
On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote:
> That is not true. What is true is that none of the core developers wants to
> make their life even more difficult so that the debian
On Saturday, February 21, 2015 at 3:42:28 AM UTC+1, Michael Orlitzky wrote:
>
> On 02/20/2015 11:02 AM, kcrisman wrote:
> >
> >>
> >> I no longer use sage for my day-to-day work, but when I was and I had
> to
> >> e.g. give a presentation, it was infuriating to find sage broken AGAIN
> >>
>
On Saturday, February 21, 2015 at 3:09:58 PM UTC+1, Felix Salfelder wrote:
>
> as it seems, hardly anybody (and about zero of the core developers) from
> the sage community wants to make use of system-installed packages
> (except for maybe gcc, ssl and whatnot).
That is not true. What is true i
On Sat, Feb 21, 2015 at 03:58:29AM -0800, Volker Braun wrote:
> [..] it still doesn't work.
you keep saying that. but does it matter? the configuration worked
pretty good as a proof-of-concept. i am sorry if your expectations were
higher. note that this particular part was just optional within the
On Saturday, February 21, 2015 at 12:26:26 PM UTC+1, Snark wrote:
>
> Felix Salfelder did a GSOC about using a configure script.
You keep saying that but it still doesn't work.
Nor is it a particularly good way of exposing a lot of configuration
options (at least one per package).
--
You re
Le 21/02/2015 11:15, Volker Braun a écrit :
I agree that we should have some user configuration mechanism to customize
how we build packages (including replacing sage packages with distro
dependencies), but going about it by patching Sage or adding $DISTRO
subdirectories everywhere are crap. Some
I agree that we should have some user configuration mechanism to customize
how we build packages (including replacing sage packages with distro
dependencies), but going about it by patching Sage or adding $DISTRO
subdirectories everywhere are crap. Something like yaml config files (e.g.
hashdis
On 02/20/2015 11:02 AM, kcrisman wrote:
>
>>
>> I no longer use sage for my day-to-day work, but when I was and I had to
>> e.g. give a presentation, it was infuriating to find sage broken AGAIN
>>
>
> ??? I assume this is because you updated some dependency and Sage didn't
> work quite proper
>> In all honesty, I think you should throw golden bridges to people like
>> Julien and Francois who are doing all this heavy-lifting work on the
What is a "golden bridge"?
>> software engineering side of things. I think that having sage integrating
>> with distro packages would not only be a ben
>
> I no longer use sage for my day-to-day work, but when I was and I had to
> e.g. give a presentation, it was infuriating to find sage broken AGAIN
>
??? I assume this is because you updated some dependency and Sage didn't
work quite properly somewhere in its bowels with that? I've never on
I ignored this thread because of the title, but I guess I shouldn't have!
> general the combinatorial explosion of configurations to debug is way
>> too large and it is next to impossible to find any distribution where
>> the version numbers even remotely match. We updated to GAP 4.4.12 in
>>
>>
There is no deceit, libgap is the gap source made useable as a shared
libary. Its not like git/libgit who don't share a line of code...
On Friday, February 20, 2015 at 8:23:20 AM UTC+1, Snark wrote:
>
> Hi,
>
> Le 20/02/2015 01:07, Volker Braun a écrit :
> > On Thursday, February 19, 2015 at 6
Hello William,
On 20 February 2015 at 01:22, William Stein wrote:
>
> This has been discussed over and over again and it plainly doesn't
> work. The Sage in Debian does not pass doctests, not even close. In
> general the combinatorial explosion of configurations to debug is way
> too large and it
On 2015-02-19 18:54, Michael Orlitzky wrote:
On 02/19/2015 11:24 AM, Jeroen Demeyer wrote:
On 2015-02-19 16:55, Michael Orlitzky wrote:
It's not incompatibility with Debian that's the problem. Having
dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
UTC-5" leads to madness.
Hi,
Le 20/02/2015 01:22, William Stein a écrit :
On Thu, Feb 19, 2015 at 12:51 PM, Francesco Biscani
wrote:
On 19 February 2015 at 18:05, Julien Puydt wrote:
All distributions have thousands of packages, and deps are not a big
issue. Sage-the-distribution has about a hundred, and it's a big
Hi,
Le 20/02/2015 01:07, Volker Braun a écrit :
On Thursday, February 19, 2015 at 6:36:38 PM UTC+1, Snark wrote:
Sage's libgap and cddlib are problems : they correspond to upstreams
That is not correct, there is no upstream library interface to gap. So
there is no conflict. However, Debian i
On Thu, Feb 19, 2015 at 12:51 PM, Francesco Biscani
wrote:
> On 19 February 2015 at 18:05, Julien Puydt wrote:
>>
>> All distributions have thousands of packages, and deps are not a big
>> issue. Sage-the-distribution has about a hundred, and it's a big issue.
>
>
> This is something I have faile
On Thursday, February 19, 2015 at 6:36:38 PM UTC+1, Snark wrote:
>
> Sage's libgap and cddlib are problems : they correspond to upstreams
That is not correct, there is no upstream library interface to gap. So
there is no conflict. However, Debian invented a gap-library package.
--
You receive
On Thursday, February 19, 2015 at 1:22:12 PM UTC-8, Michael Orlitzky wrote:
>
> Libc was an extreme example -- gd/dvipng are more mundane. Sage ships a
> gd spkg, and sage uses dvipng but doesn't ship an spkg for it. The
> problem? dvipng links against gd. But since dvipng comes from my system,
On 02/19/2015 03:49 PM, Julien Puydt wrote:
> Le 19/02/2015 18:54, Michael Orlitzky a écrit :
>> This presupposes that the status quo is not madness. My sage builds work
>> for about two weeks before some invisible dependency update breaks them.
>> There's a line in sage beyond which we just don't
Le 19/02/2015 18:54, Michael Orlitzky a écrit :
This presupposes that the status quo is not madness. My sage builds work
for about two weeks before some invisible dependency update breaks them.
There's a line in sage beyond which we just don't care about
dependencies. We ship gcc, some utilities,
On 02/19/2015 11:24 AM, Jeroen Demeyer wrote:
> On 2015-02-19 16:55, Michael Orlitzky wrote:
>> It's not incompatibility with Debian that's the problem. Having
>> dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
>> UTC-5" leads to madness.
> Why madness?
If you try to have sa
On 19 February 2015 at 18:05, Julien Puydt wrote:
>
> All distributions have thousands of packages, and deps are not a big
> issue. Sage-the-distribution has about a hundred, and it's a big issue.
>
This is something I have failed to understand so far. What is it that makes
Sage require such spec
Hi,
Le 19/02/2015 17:29, William Stein a écrit :
On Thu, Feb 19, 2015 at 11:24 AM, Jeroen Demeyer wrote:
On 2015-02-19 16:55, Michael Orlitzky wrote:
It's not incompatibility with Debian that's the problem. Having
dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
UTC-5"
Le 19/02/2015 15:21, Jeroen Demeyer a écrit :
On 2015-02-19 12:56, Julien Puydt wrote:
Well, examples exist where poor choices have been made which make(made)
it harder for other projects.
From the top of my head :
(1) ECL was configured to disable SIGCHLD... by patching it! I proposed
a two
On 2015-02-19, Michael Orlitzky wrote:
> On 02/19/2015 09:21 AM, Jeroen Demeyer wrote:
>>
>>> I don't think software was ever delayed for debian.
>> If people are against #16997 because it's not compatible with Debian,
>> then Debian is *already* slowing down Sage.
>>
>
> It's not incompatibili
On Thu, Feb 19, 2015 at 11:24 AM, Jeroen Demeyer wrote:
> On 2015-02-19 16:55, Michael Orlitzky wrote:
>>
>> It's not incompatibility with Debian that's the problem. Having
>> dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
>> UTC-5" leads to madness.
>
> Why madness?
>
> It
On 2015-02-19 16:55, Michael Orlitzky wrote:
It's not incompatibility with Debian that's the problem. Having
dependencies like "whatever was in the git repo at 11:00 on 2015-02-19
UTC-5" leads to madness.
Why madness?
It has been done before (#9343) and it worked just fine.
Waiting forever unt
Hi,
Regarding third-party packaging, etc., what's the status of the Sage
Ubuntu PPA from AIMS?
Because of SageMathCloud I regularly (try to) install a lot of big
complicated scientific software in other areas (not pure math), that
are in many ways similar to Sage. In many cases there is an Ubunt
On 02/19/2015 09:21 AM, Jeroen Demeyer wrote:
>
>> I don't think software was ever delayed for debian.
> If people are against #16997 because it's not compatible with Debian,
> then Debian is *already* slowing down Sage.
>
It's not incompatibility with Debian that's the problem. Having
dependen
On 2015-02-19 12:56, Julien Puydt wrote:
Well, examples exist where poor choices have been made which make(made)
it harder for other projects.
From the top of my head :
(1) ECL was configured to disable SIGCHLD... by patching it! I proposed
a two-line patch which did it programmatically from sa
Le 19/02/2015 10:19, Jeroen Demeyer a écrit :
On 2015-02-19 08:31, Marc Mezzarobba wrote:
On a perhaps related note, Sage used to be about "building the car",
didn't it?
I would say it still is about "building the car". I think this refers to
using dependencies where possible. Instead of writ
On 2015-02-19 08:31, Marc Mezzarobba wrote:
On a perhaps related note, Sage used to be about "building the car",
didn't it?
I would say it still is about "building the car". I think this refers to
using dependencies where possible. Instead of writing our own functions
to compute in number field
Jeroen Demeyer wrote:
> Sage shouldn't support Debian. Debian should support Sage.
On a perhaps related note, Sage used to be about "building the car",
didn't it¹? I find it ironic how hard sage makes it for other projects
to rely on it in the way it itself relies on tons of third-party
package
Le 18/02/2015 19:15, maldun a écrit :
Maybe I'm missing something here, but aren't these test also badly stated?
This would be a good example why some tolerance should be included
if one test something with floating points: Every small change in some flop
somewhere in the
code will lead to a fai
Maybe I'm missing something here, but aren't these test also badly stated?
This would be a good example why some tolerance should be included
if one test something with floating points: Every small change in some flop
somewhere in the
code will lead to a fail.
I personally wouldn't call something
38 matches
Mail list logo
