On 2016-08-18 00:02, Simon King wrote:
Slightly elaborating on my suggestion: Split the code from the old-style
p_group_cohomology-2.1.6.spkg into four parts, namely
1. an optional package "meataxe", which provides a C library and some
executables and which is *not* a Python package. It is us
On Wednesday, August 17, 2016 at 3:25:31 PM UTC-7, Bill Page wrote:
>
>
> It turns out that a solution is now "hidden away" in plain sight:
>
> https://trac.sagemath.org/ticket/18640
>
> http://sagemanifolds.obspm.fr/doc/18640/reference/manifolds/sage/manifolds/utilities.html
>
>
>
And also not
Harald got access to the server hosting combinat.sagemath.org and added a
server-side redirect to the corresponding documents on doc.sagemath.org.
Hopefully that will speed up the indexing by Google of the new
documentation location.
On Sunday, August 7, 2016 at 8:25:56 AM UTC-7, William wrote
I was a bit shocked to find a solution to a long standing annoyance
with Sage symbolic derivatives
https://trac.sagemath.org/ticket/5711
https://trac.sagemath.org/ticket/6344
https://trac.sagemath.org/ticket/14517
https://groups.google.com/forum/#!topic/sage-devel/LIBo8nwftkI
I still find my self
Hi Jeroen,
On 2016-08-17, Jeroen Demeyer wrote:
> On 2016-08-17 21:32, Simon King wrote:
>> It will provide a C library
>
> I would *not* recommend putting C libraries in Python packages.
I did not suggest that the C library is provided by a *Python* package.
Slightly elaborating on my suggesti
On 2016-08-17 21:32, Simon King wrote:
It will provide a C library
I would *not* recommend putting C libraries in Python packages. First of
all, it doesn't really make sense (if it has nothing to do with Python,
it should not be a Python package). Second, the Python build system
cannot handl
Jean-Pierre Flori wrote:
> On Tuesday, August 16, 2016 at 5:29:52 PM UTC+2, Luca De Feo wrote:
>
> > But if we want to migrate to using system libs why not let gd use
> whatever it wants!
>
> Well, in that case we should use system gd, shouldn't we?
>
> Yes indeed.
> And if we don't
On Wednesday, August 17, 2016 at 9:44:45 PM UTC+2, Simon King wrote:
>
> "most logging messages are intended for reading by humans". And I believe
> that a log is more easily accessible to humans if the log messages are
> formatted so that logical blocks in the computation correspond to visual
>
Hi Volker,
On 2016-08-17, Volker Braun wrote:
> I think thats hard to do because it runs against the grain for what logging
> is supposed to do.
Citing from
https://docs.python.org/2/howto/logging-cookbook.html:
"most logging messages are intended for reading by humans". And I believe
that a lo
Hi Jeroen,
On 2016-08-17, Jeroen Demeyer wrote:
> On 2016-08-17 16:53, Simon King wrote:
>> So, does the cohomology spkg qualify as an "independent" Python module?
>
> Perhaps it *could* be a independent Python module. One thing which is
> not clear to me is to what extent your package would nee
Hi Simon,
On 17/08/16 16:07, Simon King wrote:
Hi Vincent,
On 2016-08-17, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
It is a bit better for dealing with backward compatibility:
- if there a problem, you do not have to fix anything in the Sage
sources. Just release a new tarball. I
Hi Vincent,
On 2016-08-17, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Concerning the meataxe being installed you can add at the begining of
> the setup.py
>
> {{{
> try:
> from sage.env import SAGE_ROOT, SAGE_SRC
> from sage.misc.package import is_package_installed
> except
Hi Jean-Pierre,
On 2016-08-17, Jean-Pierre Flori wrote:
>> Here I am a bit reluctant. Upstream isn't really active and I need
>> patches to make the package useful.
>>
> I think I already mentioned it earlier, but IIRC there is a revived
> meataxe package.
> Did you have a look?
>
> Old meatax
I made https://trac.sagemath.org/ticket/21269
On Wednesday, August 17, 2016 at 10:04:47 AM UTC+2, Martin R wrote:
>
> While working on the new fricas interface, I noticed that the
> method __repr__ in sage.interfaces.InterfaceElement is always called twice.
> Apparently, once by __call__ in f
Disclaimer: I am not a lawyer.
Not the way I understand it, but I suppose it matters what you mean by
create.
If you use Sage(Math) to derive a formula that you then incorporate into
your
commercial closed-source program, I think the answer is, that's OK.
If you use your commercial closed-sou
I think thats hard to do because it runs against the grain for what logging
is supposed to do. Usually we "log" the state of the program at a
particular line of code, and not the previous execution history. In
particular, one expects that only the order of log lines is switched if
independent c
On 2016-08-17 16:53, Simon King wrote:
So, does the cohomology spkg qualify as an "independent" Python module?
Perhaps it *could* be a independent Python module. One thing which is
not clear to me is to what extent your package would need changes to
Sage itself. If you need to make non-trivia
On 17/08/16 11:53, Simon King wrote:
Hi Vincent,
On 2016-08-16, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
This is *one* way to do. You can also distribute your package as an
independent Python module. That is to say, you can also move the "Cython
interface part" to your package. One
On Wednesday, August 17, 2016 at 5:08:00 PM UTC+2, Simon King wrote:
>
> Hi Vincent,
>
> On 2016-08-17, Vincent Delecroix <20100.d...@gmail.com >
> wrote:
> > +1: if meataxe is a great improvement for basic arithmetic ...
>
> See #12103. Multiplication of 2000x2000 matrices over GF(125) impro
Hi Vincent,
On 2016-08-17, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> +1: if meataxe is a great improvement for basic arithmetic ...
See #12103. Multiplication of 2000x2000 matrices over GF(125) improves
from 747 s to 7.7 s, inversion improves from 1100 s to 23.6 s, and
gaussian elimi
Hi Vincent,
On 2016-08-16, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> This is *one* way to do. You can also distribute your package as an
> independent Python module. That is to say, you can also move the "Cython
> interface part" to your package. One advantage of this approach is th
https://trac.sagemath.org/ticket/21231
--
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 t
On 17/08/16 11:03, Simon King wrote:
Hi Vincent,
On 2016-08-17, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
Why are you keeping sources in the Sage tree instead of moving
everything to your module? (see also my previous post).
It's the other way around. Previously, in my old-style sp
Hi Vincent,
On 2016-08-17, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Why are you keeping sources in the Sage tree instead of moving
> everything to your module? (see also my previous post).
It's the other way around. Previously, in my old-style spkg, everything
(code in C, gap, sing
Hi Simon,
Why are you keeping sources in the Sage tree instead of moving
everything to your module? (see also my previous post).
You will be free to use whatever method for testing (including Sage with
$ sage -t --force-lib PATH_TO_THE_PKG_SOURCES
)
On 17/08/16 09:58, Simon King wrote:
Hi
Hi Dima,
On 2016-08-17, Dima Pasechnik wrote:
> Do you mean to sat that src/sage/groups/modular_cohomology/ would be
> standard, and relying on meataxe
> at the same time (i.e., useless without meataxe) ?
Let's better talk about code that you can look at, i.e.
src/sage/matrix/matrix_gfpn_dens
I recommend this be crossposted to sage-devel and perhaps to sage-combinat
There are people who know all about formal power series in Sage...
On Tuesday, August 16, 2016 at 9:25:08 AM UTC+1, Martin R wrote:
>
> Hi Waldek! (and all others of course, too!)
>
> Am Samstag, 13. August 2016 22:08:16
On Wednesday, August 17, 2016 at 8:55:38 AM UTC+1, Simon King wrote:
>
> Hi Dima,
>
> On 2016-08-16, Dima Pasechnik > wrote:
> > I don't see why you ever need to mark tests in a module X, which only
> > depend on X being installed, optional; after all if X is not
> > installed then the tests
Disappointed. That's about as controversial as the pope being a catholic.
Bill.
On Wednesday, 17 August 2016 07:02:16 UTC+2, William wrote:
>
>
> http://ask.sagemath.org/question/34442/can-i-create-commercial-software-using-sagemath
>
>
> I put: "ANSWER: It depends on what you mean by "commerci
Hi Eric,
On 2016-08-17, Erik Bray wrote:
> Off the top of my head I don't know specifically what you're looking
> to do though; something more concrete would be helpful.
The computation of the cohomology ring of a group G with coefficients in
GF(p) involves the computation of cohomology rings of
On Wednesday, August 17, 2016 at 9:05:25 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2016-08-16 22:28, Volker Braun wrote:
> > gdb on OSX should work, the only issue is that Apple decided that only
> > root shall have sufficient permissions to use it (PTRACE)
>
> So in practice it doesn't work :-)
William Stein writes:
> Good point. Also, I'm for making the user type
>
>import something.or.other
>
> **explicitly**, rather than having it pre-imported on startup. Of
> course, the import command will be documented.
I see your point. But is
"You need an explicit import, and a warning
On Wed, Aug 17, 2016 at 10:03 AM, Simon King wrote:
> Hi Erik,
>
> On 2016-08-17, Erik Bray wrote:
>> It's probably easy, but I don't understand the full context well
>> enough to simply state how to do what you want. There are lots more
>> pieces to the logging framework than just message handl
While working on the new fricas interface, I noticed that the
method __repr__ in sage.interfaces.InterfaceElement is always called twice.
Apparently, once by __call__ in fancy_repr.py, and a second time by
_repr_pprint in pretty.py.
Is this intentional?
The problem is that in the interface wo
On 2016-08-16 22:28, Volker Braun wrote:
gdb on OSX should work, the only issue is that Apple decided that only
root shall have sufficient permissions to use it (PTRACE)
So in practice it doesn't work :-)
--
You received this message because you are subscribed to the Google Groups
"sage-devel
Hi Erik,
On 2016-08-17, Erik Bray wrote:
> It's probably easy, but I don't understand the full context well
> enough to simply state how to do what you want. There are lots more
> pieces to the logging framework than just message handlers too, so
> there are several places you can plug in. I wo
On Wed, Aug 17, 2016 at 12:43 AM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
> Hi,
>
> On 16/08/16 09:07, Jeroen Demeyer wrote:
>>
>> On 2016-08-16 14:04, Erik Bray wrote:
>>>
>>> Hi all,
>>>
>>> Is there a make target for building/installing all *optional* packages
>>> as well as the sta
Hi Dima,
On 2016-08-16, Dima Pasechnik wrote:
> I don't see why you ever need to mark tests in a module X, which only
> depend on X being installed, optional; after all if X is not
> installed then the tests are not there, and if X is installed then it's
> there...
The .pyx wrapper for X defi
On Tue, Aug 16, 2016 at 7:14 PM, Simon King wrote:
> My first question is about logging. The old spkg has a custom logger
> that tells by what object it was called, unless it is called repeatedly by
> the same object. Thus, if it is called by object A with messages m1 and m2,
> then called by B wi
39 matches
Mail list logo
