On Wed, Aug 17, 2016 at 11:30 AM, Simon King wrote:
> 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
> G
On 2016-08-18 16:43, Simon King wrote:
What do you mean by Singular interface?
If I understand correctly, your package has an interface for GAP,
Singular and Sage and these are all independent from eachother. I am
asking that, if somebody has Singular installed but not GAP and not
Sage, that
On 2016-08-18 11:22, Simon King wrote:
What are you talking about? The current optional Sage package "meataxe"
is the latest upstream from Aachen.
I was under the impression that you needed special patches and that "the
latest upstream from Aachen" did not work for you. Anyway, it doesn't
mat
On Thursday, August 18, 2016 at 7:37:28 AM UTC+1, Jeroen Demeyer wrote:
>
> 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
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 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
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
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 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 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
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
Hello,
On 16/08/16 17:48, Dima Pasechnik wrote:
On Tuesday, August 16, 2016 at 6:14:27 PM UTC+1, Simon King wrote:
>>
I made progress turning my optional old-style group cohomology spkg into
a new style package (called "modres", to be added to Sage at some point)
depending on another new-style
13 matches
Mail list logo
