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
Hi Jeroen,
On 2016-08-18, Jeroen Demeyer wrote:
> 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.
In the computation of a coh
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
Hi Dima,
On 2016-08-18, Dima Pasechnik wrote:
> Anyway, I guess it depends upon how much GAP code you have. If its hundreds
> of lines it's probably nicer to put them into a file.
It is about 1500 lines, currently in three files.
Cheers,
Simon
--
You received this message because you are sub
Hi Jeroen,
On 2016-08-18, Jeroen Demeyer wrote:
> 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 upstrea
On Thursday, August 18, 2016 at 12:59:39 PM UTC+1, Simon King wrote:
>
> Hi Dima,
>
> On 2016-08-18, Dima Pasechnik > wrote:
> >> Does a concept of "GAP packages" and "Singular packages" exist? If so,
> >> you should follow recommendations for those kinds of packages to
> install
> >> your G
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
Hi Dima,
On 2016-08-18, Dima Pasechnik wrote:
>> Does a concept of "GAP packages" and "Singular packages" exist? If so,
>> you should follow recommendations for those kinds of packages to install
>> your GAP/Singular code.
>
> With GAP it is problematic, as updating GAP wipes out installed GAP
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
Hi Jeroen,
On 2016-08-18, 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 provides a C library and some
>>
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
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
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 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
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
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
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 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
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
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
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
On Tuesday, August 16, 2016 at 6:14:27 PM UTC+1, Simon King wrote:
>
> Hi!
>
> 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 package (called "meataxe", already
36 matches
Mail list logo
