Hi Jeroen,
On 2017-07-10, Jeroen Demeyer wrote:
> I don't think that it should be so strict. Of course, the optional
> module should still be within the scope of Sage and be sufficiently
> related to things that Sage does.
That would indeed be the case.
> Keep in mind that there are advantage
On 2017-07-08 13:37, Simon King wrote:
Sure. The meataxe experience was the reason why I tried optional extension
modules. I don't recall *who* said so, but I was told that optional extension
modules in the Sage source tree should only be used for functionalty that exists
in vanilla Sage and can
Hi Jeroen,
On 2017-07-07, Jeroen Demeyer wrote:
> On 2017-07-07 13:24, Simon King wrote:
>> However I was told that the plan to add optional extension modules will not
>> be supported.
>
> Who has said this? We do currently have several optional extension
> modules (in particular, one implement
On 2017-07-07 13:24, Simon King wrote:
However I was told that the plan to add optional extension modules will not be
supported.
Who has said this? We do currently have several optional extension
modules (in particular, one implementing matrices using meataxe, where
you were involved in IIRC
On 2017-07-06, Dima Pasechnik wrote:
> There is also Simon's package about group cohomology, with an upgrade still
> in the works IIRC.
Yes. At some point I had the plan to make a separate new-style package for the
C-code of my spkg,
put the GAP- and Singular-code of my spkg into an appropriate