> On 8/04/2016, at 14:13, Kwankyu Lee wrote:
>
> (3) Optional parts to install can be selected at build time.
Or Optional parts can be installed separately after installing the core
part. Very pythonic that way.
François
--
You received this message because you are subscribed to the Google G
It would be nice if
(1) Sage library consists of core + optional parts
(2) An optional part is dependent on core + other optional parts
(3) Optional parts to install can be selected at build time.
(4) An optional part has its own documentation, but accessible through a
single interface in Sage.
Hi,
On Thu, Apr 07, 2016 at 05:36:21PM -0700, William Stein wrote:
> The sage reference manual is way too big already. Building it is a
> high source of friction and complaints by users.
It's worth (and also fun) to point out there that the second major topic at
Sage Days 77 here after pac
On Thursday, April 7, 2016, Volker Braun wrote:
> On Friday, April 8, 2016 at 1:26:07 AM UTC+2, William wrote:
>>
>> This thread is first and foremost about reducing the friction involved in
>> making code that depends on the Sage distribution available to the world.
>>
>
> Whats wrong with the o
IMHO your package should never alter Sage sources, thats just confusing.
Documentation should be built when your package is installed, and installed
in the standard SAGE_LOCAL/share/doc/mypackage.
Similarly, your code should be installed into SAGE_LOCAL and never into the
Sage source tree. SAGE
Dear sage-devel,
The spkg-install [1] (inspired from a early version of sagemanifolds) of my
optional sage package slabbe-0.2.spkg installs the documentation like this:
# Remove old documentation
rm -fr "$SAGE_ROOT"/src/sage/doc/en/slabbe*
cp -r doc/en/slabbe "$SAGE_ROOT"/src/doc/en
[1] https:
Correction: "sage -pip install
git+https://github.com/vbraun/awesomepackage.git";
--
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...@googlegro
On Friday, April 8, 2016 at 1:26:07 AM UTC+2, William wrote:
>
> This thread is first and foremost about reducing the friction involved in
> making code that depends on the Sage distribution available to the world.
>
Whats wrong with the obvious solution: make it a Python package (basically
add
On Thu, Apr 07, 2016 at 03:58:43PM -0700, William Stein wrote:
> Cool! If there's any summary of discussions or questions, etc., let me know.
We are taking notes in a couple of pads, including:
https://www.lri.fr/etherpad/p/sage-days77-packaging
This will end up after the Sage Days on t
On Thursday, April 7, 2016, Volker Braun wrote:
> On Friday, April 8, 2016 at 12:19:57 AM UTC+2, William wrote:
>>
>> > You mean like in the Linux kernel, which uses a single monolithic git
>> > repository?
>> I think you are being sarcastic.
>
>
> I'm only partially kidding. Why is the kernel no
On Thursday, April 7, 2016 at 11:19:57 PM UTC+1, William wrote:
>
> On Wed, Apr 6, 2016 at 12:51 AM, Volker Braun > wrote:
> > On Tuesday, April 5, 2016 at 8:44:45 PM UTC+2, William wrote:
> >>
> >> [...] toward standard open source practices.
> >
> >
> > You mean like in the Linux kernel,
On Friday, April 8, 2016 at 12:19:57 AM UTC+2, William wrote:
>
> > You mean like in the Linux kernel, which uses a single monolithic git
> > repository?
> I think you are being sarcastic.
I'm only partially kidding. Why is the kernel not a collection of packages?
Because nobody wants half a k
On Thu, Apr 7, 2016 at 3:41 PM, Nicolas M. Thiery
wrote:
> On Thu, Apr 07, 2016 at 03:19:14PM -0700, William Stein wrote:
>> There are very good reasons to supporting both modularization and much
>> more standard approaches to packaging. ... Since -- based on responses --
>> almost nobody else in
On Thu, Apr 07, 2016 at 03:19:14PM -0700, William Stein wrote:
> There are very good reasons to supporting both modularization and much
> more standard approaches to packaging. ... Since -- based on responses --
> almost nobody else in our community seems to get this either,
For the record, modula
On Wed, Apr 6, 2016 at 12:51 AM, Volker Braun wrote:
> On Tuesday, April 5, 2016 at 8:44:45 PM UTC+2, William wrote:
>>
>> [...] toward standard open source practices.
>
>
> You mean like in the Linux kernel, which uses a single monolithic git
> repository?
I think you are being sarcastic. It's
When I run following code on cloud.sagemath.com I get two different results
for numerical and symbolic integration, I guess it is a bug.
var('t')
f=sin(t)*atan2(2*sin(t),1-2*cos(t))
version()
print "numeric integral: ", numerical_integral(f,0,pi)[0]
print "symbolic integral: ", integrate(f,(t,0,p
On Thu, Apr 7, 2016 at 12:14 PM, Emil Widmann wrote:
> < I don't really wee why it could not be user-friendly, can you elaborate on
> this?
>
> I think cygwin is a lot slower than virtualisation - or has this changed?
In my benchmarking even native Windows *can be* a lot slower than
Linux in a VM
< I don't really wee why it could not be user-friendly, can you elaborate
on this?
I think cygwin is a lot slower than virtualisation - or has this changed?
Am Montag, 4. April 2016 14:38:41 UTC+2 schrieb Sebastien Gouezel:
>
>
>
> Le lundi 4 avril 2016 11:48:34 UTC+2, Erik Bray a écrit :
>>
>>
On Fri, Mar 25, 2016 at 8:41 AM, Dima Pasechnik wrote:
>
>
> On Friday, March 25, 2016 at 11:53:51 AM UTC, aishen wrote:
>>
>> Unfortunatly it doesn't work on an intel core II pentium I have, it says
>> it can't do virtualization...
>
>
> you might need to change BIOS settings to allow virtializat
> Its not that "make ptestlong" does anything special to build Sage, it just
> launches our own (parallel) doctester after building the dependencies which
> happen to include Sage. Makefile parallelism is some version of
>
> MAKE='make -j8' make
>
> You can't really enable makefile paralle
Its not that "make ptestlong" does anything special to build Sage, it just
launches our own (parallel) doctester after building the dependencies which
happen to include Sage. Makefile parallelism is some version of
MAKE='make -j8' make
You can't really enable makefile parallelism from with
Hi all,
I have two questions about make ptestlong (or probably just make ptest).
1) I was under the (mis)conception that make ptest would also
(automatically) build in parallel. Apparently this is not the case (only
*tests* in parallel), and when you are building gcc too and not in
parallel, th
On Tue, Apr 5, 2016 at 8:53 AM, alexander.stottmeister via sage-devel
wrote:
> I faced the same error, which appears to be caused by gcc-5.3.0. After
> downgrading to gcc-4.9.3, brial compiled successfully.
> I am now stuck with a segmentation fault related to doc-html.
I'm starting to work on Cy
Little correction; it is Mike Zabrocki (and not Zabroky as I spelled it,
sorry Mike!)
2016-04-07 14:25 GMT+02:00 Viviane Pons :
> Dear all,
>
> here is a reminder about the SageDays78 in Vancouver, June 29 to July 1st
> 2016:
>
> https://wiki.sagemath.org/days78
>
> And some information:
>
> * Mi
Dear all,
here is a reminder about the SageDays78 in Vancouver, June 29 to July 1st
2016:
https://wiki.sagemath.org/days78
And some information:
* Mike Zabroky will be our invited speaker
* We have some (limited) student funding available, please send your
request before April 30.
Best
Vivian
The failure looks similar to http://trac.sagemath.org/ticket/11551. Any
help would be appreciated :)
Am Dienstag, 5. April 2016 11:53:28 UTC+2 schrieb
alexander.s...@googlemail.com:
>
> No, start-up fails with a related(?) seg fault.
>
> Am Dienstag, 5. April 2016 11:50:01 UTC+2 schrieb Dima Pas
On Wed, 6 Apr 2016, Johan S. R. Nielsen wrote:
So, we could have also something like
numbertheory.a_special_function(42)
for casual use, and "power user" might just start with
from numbertheory import *
Right. Except that sticking to plain old Python packaging without
shenanigans, then it
27 matches
Mail list logo