On 01/28/16 11:18, François Bissey wrote:
I am asking because I got a report about a singular/ntl
interaction with gcc-5.3.0 in sage-on-gentoo.
Basically ntl 9.6.2 switches on c++11 support and then
g++ refuse to compile bits of singular calling ntl without
c++11 being enabled. Of course
I am asking because I got a report about a singular/ntl
interaction with gcc-5.3.0 in sage-on-gentoo.
Basically ntl 9.6.2 switches on c++11 support and then
g++ refuse to compile bits of singular calling ntl without
c++11 being enabled. Of course singular's configure
scripts [yes there are
Hello sage-devel,
There are various degrees of patching upstream projects for Sage:
(0) vanilla upstream stable release
(1) upstream stable release with patches accepted by upstream
(2) upstream development code (e.g. git master)
(3) upstream code with patches not accepted by upstream
(4) fork
On Wednesday, 27 January 2016 15:59:34 UTC, Jeroen Demeyer wrote:
>
> Hello sage-devel,
>
> There are various degrees of patching upstream projects for Sage:
>
> (0) vanilla upstream stable release
> (1) upstream stable release with patches accepted by upstream
> (2) upstream development
On 2016-01-27 17:52, Dima Pasechnik wrote:
For the record, I never proposed to create a fork of either of them in
the 1st place.
True, you didn't propose anything. You just did it.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe
On 2016-01-27 17:52, Dima Pasechnik wrote:
I really do not understand why a complicated, buggy, hard to maintain,
fix, or even read
patches and scripts (e.g.
https://github.com/sagemath/sage/blob/master/build/pkgs/cliquer/spkg-install
and
its role in Sage 7.0 OSX binaries facepalm)
should be
On Wednesday, 27 January 2016 18:18:47 UTC, Jeroen Demeyer wrote:
>
> On 2016-01-27 17:52, Dima Pasechnik wrote:
> > I really do not understand why a complicated, buggy, hard to maintain,
> > fix, or even read
> > patches and scripts (e.g.
> >
>
Imho if upstream hasn't made any changes in the last 5 years and/or can't
be bothered with the added value of building a shared library then its
better to fork. Make a git repo under the sagemath github organization,
done. Really, everything is a fork in git. Just get used to it.
On
On Wednesday, 27 January 2016 17:53:47 UTC, Jeroen Demeyer wrote:
>
> On 2016-01-27 17:52, Dima Pasechnik wrote:
> > For the record, I never proposed to create a fork of either of them in
> > the 1st place.
> True, you didn't propose anything. You just did it.
>
Since when creating a public
> Since when creating a public git repo of something is called forking?
In the present, upstream explained that the software was barely
updated anymore (last update was 5 years ago) and that there are no
plans to change it in the close future (except possible bugfixes).
*if* such a thing were to
On Wednesday, 27 January 2016 18:50:02 UTC, Nathann Cohen wrote:
>
> > Since when creating a public git repo of something is called forking?
>
> In the present, upstream explained that the software was barely
> updated anymore (last update was 5 years ago) and that there are no
> plans to
On 2016-01-27 19:46, Dima Pasechnik wrote:
Since when creating a public git repo of something is called forking?
It is forking if the only way to obtain the tarball is using some
obscure git repo that you created.
--
You received this message because you are subscribed to the Google Groups
On 2016-01-27 20:03, Dima Pasechnik wrote:
The exciting alternative approach proposed by Jeroen is patching
makefiles, and
possibly other parts of upstream, by hand.
Again false dichotomy...
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On 2016-01-27 20:27, Volker Braun wrote:
Imho if upstream hasn't made any changes in the last 5 years and/or
can't be bothered with the added value of building a shared library then
its better to fork.
I agree!
However, note the very important condition "can't be bothered with the
added
On 2016-01-27 19:42, Dima Pasechnik wrote:
Note that planarity already had a ./configure && make install support.
This autoconf build system his was added by Nathann Cohen and accepted
by upstream.
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
On Wednesday, January 27, 2016 at 1:22:15 AM UTC-5, Clemens Heuberger wrote:
>
> Is there a way to convert a jupyter notebook .ipynb to a "doctestable
> file"?
> Such a thing existed for the sage notebook.
>
>
Is it possible that there is an ipynb -> rst out there, or in development?
That
>
> I surprisingly don't remember even one user request for such
> tinymce style wysiwyg editing for SMC. And our users are constantly asking
> for the functionality they feel they really need... I'm very surprised by
> this lack of demand. However maybe they don't know what they want.
>
>
Min (in the Jupyter project) wrote a program to doctest .ipynb files a
while ago: https://gist.github.com/minrk/2620735. I think it expects an
old version of the .ipynb format, but it is a good starting point to update
to the newest .ipynb format.
Thanks,
Jason
On Wed, Jan 27, 2016 at 3:39 PM
I'm fine with giving him all the time in the world to respond. Once he does
I'm happy to update the SPKG.txt metadata.
On Wednesday, January 27, 2016 at 3:27:58 PM UTC-5, Jeroen Demeyer wrote:
>
> On 2016-01-27 20:27, Volker Braun wrote:
> > Imho if upstream hasn't made any changes in the
It would be pretty easy to do since ipynb has an official api to read
files. We could also combine it with the sagenb->ipynb converter...
On Wednesday, January 27, 2016 at 3:39:23 PM UTC-5, kcrisman wrote:
>
>
>
> On Wednesday, January 27, 2016 at 1:22:15 AM UTC-5, Clemens Heuberger
> wrote:
On 2016-01-27 07:22, Clemens Heuberger wrote:
- diffs between various versions would be much easier than diffing the .ipynb
file.
I know that "diffability" of ipynb files is on upstream's TODO list.
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
21 matches
Mail list logo
