Re: [sage-devel] Docker images no longer being build and is gitlab still maintained?

[Maarten Derickx]

Yeah I had to use buildx to debug why the build was failing (standard 
docker build would not give enough logs). For me doing:

docker buildx create --use --name larger_log --driver-opt 
env.BUILDKIT_STEP_LOG_MAX_SIZE=5000 docker buildx build 
Just worked without any other config. I guess you could even leave out the 
"--driver-opt env.BUILDKIT_STEP_LOG_MAX_SIZE=5000" part.

Note that for me the build was failing cause of the OOM killer killed one 
of the build processes, so the only thing I needed to do to make the build 
work is assign more resources to the docker container to make it work.

On Sunday, 5 December 2021 at 15:14:32 UTC+1 dim...@gmail.com wrote:

> Anyone tried using buildx?
>
>  It seems to simplify setting up the build - although on Linux it appears 
> to have extra hoops to jump through.
>
> On Sun, 5 Dec 2021, 14:06 Maarten Derickx,  wrote:
>
>> Hi Julian,
>>
>> I didn't build a sagemath-dev image. So the first test will likely fail. 
>> I did manually test that the command line starts and that I could do 
>> computations which depend on singular pari and gap, and I also tested 
>> manually that jupyter starts and that I could do computations in it. The 
>> main purpose for building this image is that I use the sagemath docker 
>> images as base image for CI testing in a downstream package. And I needed 
>> certain features/fixes that are in 9.4 but not 9.2. And up to now all the 
>> CI tests of the downstream package pass just fine with this image.
>>
>> I will try to see if I can also successfully build and test a dev image.
>> On Saturday, 4 December 2021 at 18:08:19 UTC+1 dim...@gmail.com wrote:
>>
>>> One way or another, it's probably a good idea to run the builder on GH 
>>> Actions - translating one yml to another should be doable.
>>>
>>>
>>> On Sat, 4 Dec 2021, 16:11 julian...@fsfe.org,  
>>> wrote:
>>>
>>>> Hi Maarten,
>>>>
>>>> thanks for verifying that the Dockerfile still works.
>>>>
>>>> On Thursday, December 2, 2021 at 10:06:30 PM UTC-6 maarten...@navara.nl 
>>>> wrote:
>>>>
>>>>> In the meantime I managed to verify that aside from the gitlab CI/CD 
>>>>> there are no other things that are broken. Meaning that I managed to 
>>>>> build 
>>>>> the docker file shipped with sage just fine on my laptop. I pushed a 
>>>>> build 
>>>>> of 9.4 to https://hub.docker.com/r/mderickx/sagemath/ in case anyone 
>>>>> is interested.
>>>>>
>>>>
>>>> Did you also run the tests on the docker image? There are three tests 
>>>> defined here 
>>>> https://gitlab.com/sagemath/sage/-/blob/develop/.gitlab-ci.yml#L145. 
>>>> These often failed in the past with new releases.
>>>>
>>>> julian
>>>>
>>>> -- 
>>>>
>>> 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+...@googlegroups.com.
>>>>
>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/sage-devel/6d614b77-f673-4dbf-9e38-661fc7af4247n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/sage-devel/6d614b77-f673-4dbf-9e38-661fc7af4247n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> 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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/fc867437-4b30-4efa-8d17-4f1c842bc984n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/fc867437-4b30-4efa-8d17-4f1c842bc984n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2df8df20-64a4-4199-b339-34c2685568dbn%40googlegroups.com.

Re: [sage-devel] Docker images no longer being build and is gitlab still maintained?

[Maarten Derickx]

Hi Julian,

I didn't build a sagemath-dev image. So the first test will likely fail. I 
did manually test that the command line starts and that I could do 
computations which depend on singular pari and gap, and I also tested 
manually that jupyter starts and that I could do computations in it. The 
main purpose for building this image is that I use the sagemath docker 
images as base image for CI testing in a downstream package. And I needed 
certain features/fixes that are in 9.4 but not 9.2. And up to now all the 
CI tests of the downstream package pass just fine with this image.

I will try to see if I can also successfully build and test a dev image.
On Saturday, 4 December 2021 at 18:08:19 UTC+1 dim...@gmail.com wrote:

> One way or another, it's probably a good idea to run the builder on GH 
> Actions - translating one yml to another should be doable.
>
>
> On Sat, 4 Dec 2021, 16:11 julian...@fsfe.org,  wrote:
>
>> Hi Maarten,
>>
>> thanks for verifying that the Dockerfile still works.
>>
>> On Thursday, December 2, 2021 at 10:06:30 PM UTC-6 maarten...@navara.nl 
>> wrote:
>>
>>> In the meantime I managed to verify that aside from the gitlab CI/CD 
>>> there are no other things that are broken. Meaning that I managed to build 
>>> the docker file shipped with sage just fine on my laptop. I pushed a build 
>>> of 9.4 to https://hub.docker.com/r/mderickx/sagemath/ in case anyone is 
>>> interested.
>>>
>>
>> Did you also run the tests on the docker image? There are three tests 
>> defined here 
>> https://gitlab.com/sagemath/sage/-/blob/develop/.gitlab-ci.yml#L145. 
>> These often failed in the past with new releases.
>>
>> julian
>>
>> -- 
>>
> 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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/6d614b77-f673-4dbf-9e38-661fc7af4247n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/fc867437-4b30-4efa-8d17-4f1c842bc984n%40googlegroups.com.

[sage-devel] Re: Naming conflict between Givaro and Factory

[Maarten Derickx]

Well factory.h is a file generated by singular using this template:
https://www.singular.uni-kl.de:8005/trac/browser/git/factory/factory.template?rev=ee668eff445bb4cf7e96d94673c39f627a30d232
and that template 
uses: https://www.singular.uni-kl.de/dox/html/cf__defs_8h_source.html
Not really sure why they #define IntegerDomain 1 on line 25 there. But I 
guess that doesn't matter. It is just an occasion of having to different 
libraries accidentally using the same name for different things.

So this just means we should be careful with includes and other things so 
that these things don't clash.
Op vrijdag 3 december 2021 om 11:54:08 UTC+1 schreef Clement Pernet:

> Hi,
>
> Working on
>
> https://trac.sagemath.org/ticket/32959
>
> I hit a compilation error due to
>
> sage/local/include/factory/factory.h: #define IntegerDomain 1
>
> which conflicts with
>
> sage/local/include/givaro/givinteger.h: using IntegerDomain = 
> ZRing
>
> See the compilation log ;
>
> [sagelib-9.5.beta7] In file included from 
> /home/soft/sage/local/include/singular/coeffs/coeffs.h:19,
> [sagelib-9.5.beta7]  from
> /home/soft/sage/local/include/singular/polys/monomials/ring.h:12,
> [sagelib-9.5.beta7]  from 
> /home/soft/sage/local/include/singular/kernel/polys.h:15,
> [sagelib-9.5.beta7]  from 
> /home/soft/sage/local/include/singular/kernel/structs.h:25,
> [sagelib-9.5.beta7]  from
> /home/soft/sage/local/include/singular/Singular/libsingular.h:7,
> [sagelib-9.5.beta7]  from
>
> build/cythonized/sage/rings/polynomial/multi_polynomial_libsingular.cpp:724:
> [sagelib-9.5.beta7] /home/soft/sage/local/include/givaro/givinteger.h: At 
> global scope:
> [sagelib-9.5.beta7] /home/soft/sage/local/include/factory/factory.h:92:23: 
> error: expected
> nested-name-specifier before numeric constant
> [sagelib-9.5.beta7]92 | #define IntegerDomain 1
> [sagelib-9.5.beta7]   |   ^
> [sagelib-9.5.beta7] 
> /home/soft/sage/local/include/givaro/givinteger.h:412:11: note: in 
> expansion of
> macro ‘IntegerDomain’
> [sagelib-9.5.beta7]   412 | using IntegerDomain = ZRing;
> [sagelib-9.5.beta7]   |   ^
>
> I have no clue what is this Factory, and why it defines IntegerDomain to 1.
>
> Any insight would be most welcome.
>
> Cheers.
>
> Clément
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/41bfbe41-5c62-428a-bd93-a5a2c0c5a0e3n%40googlegroups.com.

Re: [sage-devel] Docker images no longer being build and is gitlab still maintained?

[Maarten Derickx]

In the meantime I managed to verify that aside from the gitlab CI/CD there 
are no other things that are broken. Meaning that I managed to build the 
docker file shipped with sage just fine on my laptop. I pushed a build of 
9.4 to https://hub.docker.com/r/mderickx/sagemath/ in case anyone is 
interested.

Op dinsdag 30 november 2021 om 18:57:51 UTC+1 schreef wst...@gmail.com:

> Thanks Thierry, I'll email you directly to figure out the details.
>
>
> On Tue, Nov 30, 2021 at 4:32 AM Thierry  
> wrote:
>
>> Hi,
>>
>> On Sun, Nov 28, 2021 at 07:32:18PM +, Dima Pasechnik wrote:
>> > On Sun, 28 Nov 2021, 15:38 William Stein,  wrote:
>> > > On Sun, Nov 28, 2021 at 2:32 AM Dima Pasechnik  
>> wrote:
>> > > > On Sun, Nov 28, 2021 at 10:12 AM Maarten Derickx
>> > > >  wrote:
>> > > > >
>> > > > > What are the specs that the dedicated builder would need? In 
>> terms of
>> > > cpu + ram + diskspace?
>> > > >
>> > > > nothing spectacularly big, but somehow it manages to run out of
>> > > > smallish disk space on an INRIA (or was it Paris Sud, aka Paris
>> > > > Saclay?).
>> > > >
>> > > > Like, in might need more than 20 Gb or 50Gb free space for some 
>> reason.
>> > > > Nothing too bug, a reasonable modern desktop would do the job ---if 
>> we
>> > > > don't let it run on every push into the repo.
>> > >
>> > > There is still a powerful server at Univ of Washington that I bought 
>> using
>> > > a grant specifically for Sage development
>> > > (nearly a decade ago!) that could be used for building Docker images. 
>> It's
>> > > very powerful and has tons of disk space.
>> > > The drawback is it could just go "poof" at any moment, and it could 
>> be a
>> > > very long time until it comes back, if ever.
>> > > But for building docker images, that's probably fine.
>> > 
>> > can it be used as a gitlab or/and github runner for sagemath org?
>> > 
>> > I guess I don't have an account there, but it would be good to get one.
>>
>> If this ressource is not fully used, i am also volonteering to get an
>> account and setup some specific (e.g. 32bit) patchbots there.
>>
>> Ciao,
>> Thierry
>>
>>
>>
>> > Dima
>> > 
>> > 
>> > > wstein@kucalc:~/cocalc-docker/linux$ df -h .
>> > > FilesystemSize  Used Avail Use% Mounted on
>> > > tank/home/wstein  2.7T  252G  2.5T  10% /home/wstein
>> > > wstein@kucalc:~/cocalc-docker/linux$ uptime
>> > >  07:30:53 up 904 days, 20:11,  9 users,  load average: 0.67, 0.61, 
>> 0.52
>> > > wstein@kucalc:~/cocalc-docker/linux$ free -g
>> > >   totalusedfree  shared  buff/cache
>> > > available
>> > > Mem:251  11  41   2 198
>> > >   198
>> > > Swap:   255   1 254
>> > > wstein@kucalc:~/cocalc-docker/linux$ cat /proc/cpuinfo | grep 
>> processor
>> > > |wc -l
>> > > 48
>> > >
>> > > -- William
>> > >
>> > > >
>> > > > Dima
>> > > >
>> > > >
>> > > >
>> > > > >
>> > > > > On Saturday, 27 November 2021 at 19:13:14 UTC+1 dim...@gmail.com
>> > > wrote:
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> On Sat, 27 Nov 2021, 17:07 Maarten Derickx, <
>> m.derick...@gmail.com>
>> > > wrote:
>> > > > >>>
>> > > > >>> I noticed on https://hub.docker.com/r/sagemath/sagemath/ that 
>> there
>> > > haven't been any updates of the official sagemath docker image since
>> > > 9.3.beta8-py3 about 9 months ago.
>> > > > >>>
>> > > > >>> On that page it mentions "Every push to our GitLab repository
>> > > triggers a pipeline in GitLab CI which pushes the actual images to 
>> Docker
>> > > Hub."
>> > > > >>>
>> > > > >>> Now I had a look at the pipelines on gitlab
>> > > 
>> https://gitlab.com/sagemath/sage/-/pipelines?page=1=all=success
>> > > the last succesful run of the pipeline

Re: [sage-devel] Docker images no longer being build and is gitlab still maintained?

[Maarten Derickx]

What are the specs that the dedicated builder would need? In terms of cpu + 
ram + diskspace?

On Saturday, 27 November 2021 at 19:13:14 UTC+1 dim...@gmail.com wrote:

>
>
> On Sat, 27 Nov 2021, 17:07 Maarten Derickx,  wrote:
>
>> I noticed on https://hub.docker.com/r/sagemath/sagemath/ that there 
>> haven't been any updates of the official sagemath docker image since 
>> 9.3.beta8-py3 
>> <https://hub.docker.com/layers/sagemath/sagemath/9.3.beta8-py3/images/sha256-a7be2d3cd0253a89ee6770c2915ee1476f8d06d8db4f568cb1f7de0476d8ba41?context=explore>
>>  about 
>> 9 months ago. 
>>
>> On that page it mentions "Every push to our GitLab repository 
>> <https://gitlab.com/sagemath/sage> triggers a pipeline in GitLab CI 
>> which pushes the actual images to Docker Hub." 
>>
>> Now I had a look at the pipelines on gitlab 
>> https://gitlab.com/sagemath/sage/-/pipelines?page=1=all=success 
>> the last succesful run of the pipelines was about 8 months ago. So gitlab 
>> pipelines being broken seems to explain why no new images are being pushed 
>> to dockerhub.
>>
>> So I am wondering, is gitlab being phased out/abandoned, or do we still 
>> support it and do we just need to show it some love?
>>
>
> It needs quite a bit of love, in form of a gitlab runner that doesn't run 
> out of disk space (a dedicated runner at France runs of disk space).
>
> It's perhaps the time to switch over to GitHub.
> Mattias Koeppe should have an idea how much effort this would entail.
>
> Dima
>
>>
>> Thanks,
>> Maarten
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/492af376-40ad-45b2-940c-f0ea4f49bf60n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/492af376-40ad-45b2-940c-f0ea4f49bf60n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cf606e1d-ab3e-4cb1-85bc-26b65ecdcbd4n%40googlegroups.com.

[sage-devel] Docker images no longer being build and is gitlab still maintained?

[Maarten Derickx]

I noticed on https://hub.docker.com/r/sagemath/sagemath/ that there haven't 
been any updates of the official sagemath docker image since 9.3.beta8-py3 

 about 
9 months ago. 

On that page it mentions "Every push to our GitLab repository 
 triggers a pipeline in GitLab CI which 
pushes the actual images to Docker Hub." 

Now I had a look at the pipelines on gitlab 
https://gitlab.com/sagemath/sage/-/pipelines?page=1=all=success 
the last succesful run of the pipelines was about 8 months ago. So gitlab 
pipelines being broken seems to explain why no new images are being pushed 
to dockerhub.

So I am wondering, is gitlab being phased out/abandoned, or do we still 
support it and do we just need to show it some love?

Thanks,
Maarten

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/492af376-40ad-45b2-940c-f0ea4f49bf60n%40googlegroups.com.

[sage-devel] Bug in testing whether an element is in an abelian group

[Maarten Derickx]

Hi All,

Believe it or not, the relatively innocent looking piece of code:

sage: Zmstar = AbelianGroup(1,[4]) 
sage: Hgens =  [Zmstar.gen(0)**2] 
sage: H = Zmstar.subgroup(Hgens) 
sage: g = Zmstar.gen(0)**3 
sage: g in H 

Produces a:

TypeError: no conversion of this rational to integer

At https://trac.sagemath.org/ticket/32910#comment:2 I already posted a 
possible solution with some explicit code. However I don't have a 
development environment setup for sage, and have been having some trouble 
to get my development setup to work. So I'm hoping someone else is willing 
to take it from here.

Thanks,
Maarten

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cf01877d-58d5-4db2-8b92-78f4f44d4f04n%40googlegroups.com.

[sage-devel] Re: Currently advised way to build sage from a fresh git clone

[Maarten Derickx]

On Friday, 19 March 2021 at 20:07:15 UTC+1 Maarten Derickx wrote:

> Hi All,
>
> I haven't had a development version of sage for some time, and now am 
> setting one up again. In setting it up I found out that both my 
> understanding of how to do a build from a fresh git clone for some time 
> ago, as well as the current developer documentation don't seem to matching 
> the current situation anymore.
>
> Here is how I got a working sage installation:
>
> git clone git://github.com/sagemath/sage.git #I realize I need to add 
> git.sagemath.org later
> make #gives an error that I should run configure first
> ./configure 
> make
>
> The ./configure used and second make to be unnecessary according to my 
> memory and the documentation on 
> https://doc.sagemath.org/html/en/developer/walk_through.html#obtaining-the-sage-source-code
>  
>
> *The ./configure  and second make used to be unnecessary 

> Additionally the ./configure command is not available until you run make 
> at least once, so is there a step that I am missing (or an argument to the 
> first make) so that I don't get an error after the first make?
>
> Thanks,
> Maarten
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5066a55f-024f-4231-acbe-ce6fb4247f0cn%40googlegroups.com.

[sage-devel] Currently advised way to build sage from a fresh git clone

[Maarten Derickx]

Hi All,

I haven't had a development version of sage for some time, and now am 
setting one up again. In setting it up I found out that both my 
understanding of how to do a build from a fresh git clone for some time 
ago, as well as the current developer documentation don't seem to matching 
the current situation anymore.

Here is how I got a working sage installation:

git clone git://github.com/sagemath/sage.git #I realize I need to 
add git.sagemath.org later
make #gives an error that I should run configure first
./configure 
make

The ./configure used and second make to be unnecessary according to my 
memory and the documentation 
on 
https://doc.sagemath.org/html/en/developer/walk_through.html#obtaining-the-sage-source-code
 

Additionally the ./configure command is not available until you run make at 
least once, so is there a step that I am missing (or an argument to the 
first make) so that I don't get an error after the first make?

Thanks,
Maarten

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5d2c1492-0011-44db-a25c-8daf6ae90558n%40googlegroups.com.

Re: [sage-devel] Memory leak in integer multiplication in sage?

[Maarten Derickx]

Hi Vincent,

Thanks for testing and good that you realized that indeed looked fishy 
indeed.

I think your extension of my code with multiple loops actually confirms 
that there is a problem even after warming up:

the prints:

memory usage 30k: 1771.8046875
memory usage 40k: 1771.80859375

mean that you are using 1.7 GB memory extra after the 3th and the 4th loop 
(notice you chance the baseline of memory usage every loop so the 1.7 GB is 
not the total memory usage of sage, it is the new memory usage relative to 
the previous loop). So that in the end sage was using around 885+3*1777 MB 
= 6.1 GB of memory in your session.

Also,  the largest object ever created are a range object of size 1 
(which in python 3 is actually consuming almost no memory since under the 
hood it behaves very much like xrange from python 2) and an srange object 
of size 3000. Neither of these should occupy an amount of memory in the GB 
range.

Also one thing that is maybe easy to miss, I doubled the size of the loop 
between the first loop and the second loop, which explains the 885 vs 1771.


On Thursday, 18 March 2021 at 17:52:19 UTC+1 vdelecroix wrote:

> Sorry, your example indeed looks fishy.
>
> Le 18/03/2021 à 17:36, Vincent Delecroix a écrit :
> > Maarten, in your example your can not fairly compare the first
> > and second run. For example R is not allocated at your first
> > call of "mem = get_memory_usage()". Also Integers have a pool
> > which is likely not being filled at startup. Ignoring the first
> > run, I do not notice any difference.
> > 
> > (both on system sage 9.2 and compiled sage 9.3.beta8 on archlinux)
> > 
> > sage: M = 3000
> > : import gc
> > : _ = gc.collect()
> > : mem = get_memory_usage()
> > : for i in range(1):
> > : R = srange(M)
> > : _ = gc.collect()
> > : print("memory usage 10k:", get_memory_usage(mem))
> > : mem = get_memory_usage()
> > : for i in range(2):
> > : R = srange(M)
> > : _ = gc.collect()
> > : print("memory usage 20k:", get_memory_usage(mem))
> > : mem = get_memory_usage()
> > : for i in range(2):
> > : R = srange(M)
> > : _ = gc.collect()
> > : print("memory usage 30k:", get_memory_usage(mem))
> > : mem = get_memory_usage()
> > : for i in range(2):
> > : R = srange(M)
> > : _ = gc.collect()
> > ....: print("memory usage 40k:", get_memory_usage(mem))
> > 
> > memory usage 10k: 885.4453125
> > memory usage 20k: 1771.9375
> > memory usage 30k: 1771.8046875
> > memory usage 40k: 1771.80859375
> > 
> > Le 18/03/2021 à 17:00, Maarten Derickx a écrit :
> >> Hi Guys,
> >>
> >> Thanks for the replies. I think this is enough info to know that it 
> >> happens
> >> on multiple systems and that it's not just the cocalc enhanced version 
> of
> >> sage. I have created:
> >> https://trac.sagemath.org/ticket/31511#ticket for this.
> >>
> >> In the meantime I found the problem is already with the srange 
> >> command. So
> >> the integer multiplication seems to be a red herring.
> >>
> >> ~$ sage
> >> ┌┐
> >> │ SageMath version 9.2, Release Date: 2020-10-24 │
> >> │ Create a "Sage Worksheet" file for the notebook interface. │
> >> │ Enhanced for CoCalc.   │
> >> │ Using Python 3.8.5. Type "help()" for help.│
> >> └┘
> >> sage: M = 3000
> >> : import gc
> >> : gc.collect()
> >> : mem = get_memory_usage()
> >> : for i in range(1):
> >> : R = srange(M)
> >> : gc.collect()
> >> : print("memory usage 10k:", get_memory_usage(mem))
> >> : mem = get_memory_usage()
> >> : for i in range(2):
> >> : R = srange(M)
> >> : gc.collect()
> >> : print("memory usage 20k:", get_memory_usage(mem))
> >> 434
> >> 0
> >> memory usage 10k: 884.4296875
> >> 0
> >> memory usage 20k: 1770.71875
> >>
> >> On Thursday, 18 March 2021 at 16:01:56 UTC+1 David Joyner wrote:
> >>
> >>> On Thu, Mar 18, 2021 at 6:56 AM Maarten Derickx  >
> >>> wrote:
> >>>
> >>>> Hi All,
> >>

Re: [sage-devel] Memory leak in integer multiplication in sage?

[Maarten Derickx]

Hi Guys,

Thanks for the replies. I think this is enough info to know that it happens 
on multiple systems and that it's not just the cocalc enhanced version of 
sage. I have created:
https://trac.sagemath.org/ticket/31511#ticket for this.

In the meantime I found the problem is already with the srange command. So 
the integer multiplication seems to be a red herring. 

~$ sage
┌┐
│ SageMath version 9.2, Release Date: 2020-10-24 │
│ Create a "Sage Worksheet" file for the notebook interface. │
│ Enhanced for CoCalc.   │
│ Using Python 3.8.5. Type "help()" for help.│
└┘
sage: M = 3000 
: import gc 
: gc.collect() 
: mem = get_memory_usage() 
: for i in range(1): 
: R = srange(M) 
: gc.collect() 
: print("memory usage 10k:", get_memory_usage(mem)) 
: mem = get_memory_usage() 
: for i in range(2): 
: R = srange(M) 
: gc.collect() 
: print("memory usage 20k:", get_memory_usage(mem))
   
434
0
memory usage 10k: 884.4296875
0
memory usage 20k: 1770.71875

On Thursday, 18 March 2021 at 16:01:56 UTC+1 David Joyner wrote:

> On Thu, Mar 18, 2021 at 6:56 AM Maarten Derickx  
> wrote:
>
>> Hi All,
>>
>> tldr: the bottom of this post contains example code of which I would like 
>> the results on some other systems.
>>
>> I recently encountered a memory leak in the relatively innocently looking 
>> code:
>>
>> d = 27
>> M = 109
>> for i in range(1):
>> for a in srange(M):
>> for r in srange(d):
>> tmp = r*a
>>
>> However it doesn't seem to be on all platforms that sage supports. For 
>> example on cocalc (ubuntu 20.04) one gets:
>>
>> ~$ sage
>> ┌┐
>> │ SageMath version 9.2, Release Date: 2020-10-24 │
>> │ Create a "Sage Worksheet" file for the notebook interface. │
>> │ Enhanced for CoCalc.   │
>> │ Using Python 3.8.5. Type "help()" for help.│
>> └┘
>> sage: import gc 
>> : gc.collect() 
>> : mem = get_memory_usage() 
>> : d = 27 
>> : M = 109 
>> : for i in range(1): 
>> : for a in srange(M): 
>> : for r in srange(1,d): 
>> : tmp = r*a 
>> : gc.collect() 
>> : print("memory usage 10k:", get_memory_usage(mem)) 
>> : mem = get_memory_usage() 
>> : for i in range(2): 
>> : for a in srange(M): 
>> : for r in srange(1,d): 
>> : tmp = r*a 
>> : gc.collect() 
>> : print("memory usage 20k:", get_memory_usage(mem)) 
>> :
>>  
>> 434
>> 0
>> memory usage 10k: 9.15234375
>> 0
>> memory usage 20k: 21.3984375
>> 
>>
>> showing clear indication of a memory leak. While on my own laptop (OS X 
>> 10.13.6) I get:
>>
>>
>>
>> ~ mderickx$ sage
>> ┌┐
>> │ SageMath version 9.2, Release Date: 2020-10-24 │
>> │ Using Python 3.8.5. Type "help()" for help. │
>> └┘
>> sage: import gc
>> : gc.collect() 
>> : mem = get_memory_usage() 
>> : d = 27 
>> : M = 109 
>> : for i in range(1): 
>> : for a in srange(M): 
>> : for r in srange(1,d): 
>> : tmp = r*a 
>> : gc.collect() 
>> : print("memory usage 10k:", get_memory_usage(mem)) 
>> : mem = get_memory_usage() 
>> : for i in range(2): 
>> : for a in srange(M): 
>> : for r in srange(1,d): 
>> : tmp = r*a 
>> : gc.collect() 
>> : print("memory usage 20k:", get_memory_usage(mem)) 
>> :  
>> 278 
>> 0 
>> memory usage 10k: 0.0 
>> 0 
>> memory usage 20k: 0.0 
>>
>>
>> so here the memory leak does not occur. However I don't have any

[sage-devel] Memory leak in integer multiplication in sage?

[Maarten Derickx]

Hi All,

tldr: the bottom of this post contains example code of which I would like 
the results on some other systems.

I recently encountered a memory leak in the relatively innocently looking 
code:

d = 27
M = 109
for i in range(1):
for a in srange(M):
for r in srange(d):
tmp = r*a

However it doesn't seem to be on all platforms that sage supports. For 
example on cocalc (ubuntu 20.04) one gets:

~$ sage
┌┐
│ SageMath version 9.2, Release Date: 2020-10-24 │
│ Create a "Sage Worksheet" file for the notebook interface. │
│ Enhanced for CoCalc.   │
│ Using Python 3.8.5. Type "help()" for help.│
└┘
sage: import gc 
: gc.collect() 
: mem = get_memory_usage() 
: d = 27 
: M = 109 
: for i in range(1): 
: for a in srange(M): 
: for r in srange(1,d): 
: tmp = r*a 
: gc.collect() 
: print("memory usage 10k:", get_memory_usage(mem)) 
: mem = get_memory_usage() 
: for i in range(2): 
: for a in srange(M): 
: for r in srange(1,d): 
: tmp = r*a 
: gc.collect() 
: print("memory usage 20k:", get_memory_usage(mem)) 
:  
   
434
0
memory usage 10k: 9.15234375
0
memory usage 20k: 21.3984375


showing clear indication of a memory leak. While on my own laptop (OS X 
10.13.6) I get:



~ mderickx$ sage
┌┐
│ SageMath version 9.2, Release Date: 2020-10-24 │
│ Using Python 3.8.5. Type "help()" for help. │
└┘
sage: import gc
: gc.collect() 
: mem = get_memory_usage() 
: d = 27 
: M = 109 
: for i in range(1): 
: for a in srange(M): 
: for r in srange(1,d): 
: tmp = r*a 
: gc.collect() 
: print("memory usage 10k:", get_memory_usage(mem)) 
: mem = get_memory_usage() 
: for i in range(2): 
: for a in srange(M): 
: for r in srange(1,d): 
: tmp = r*a 
: gc.collect() 
: print("memory usage 20k:", get_memory_usage(mem)) 
:  
278 
0 
memory usage 10k: 0.0 
0 
memory usage 20k: 0.0 


so here the memory leak does not occur. However I don't have any other 
systems to which I have access to. So I was wondering if people could 
execute the code below on some other systems and report back here to see 
where the leaking is actually occurring. Since I do not have access to a 
plain vanilla sage install on ubuntu, *I am especially interested if on 
ubuntu the non cocalc enhanced version of sage also produces a memory leak 
for the following code:*

import gc
gc.collect()
mem = get_memory_usage()
d = 27
M = 109
for i in range(1):
for a in srange(M):
for r in srange(1,d):
tmp = r*a
gc.collect()
print("memory usage 10k:", get_memory_usage(mem))
mem = get_memory_usage()
for i in range(2):
for a in srange(M):
for r in srange(1,d):
tmp = r*a
gc.collect()
print("memory usage 20k:", get_memory_usage(mem))


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5882460b-842c-49c4-b33b-fae1c7986db9n%40googlegroups.com.

[sage-devel] Re: Why my patch is not yet accepted?

[Maarten Derickx]

Hi Victor,

Just looked at the ticket, and without looking at the mathematical content 
I see a few things that make the ticket probably not get attention from 
reviewers. 

1) The plugins of the patchbot currently show multiple problems with your 
ticket: https://patchbot.sagemath.org/ticket/24542/
2) The ticket on trac is says your ticket is in the component: "packages: 
standard". However, that label only for already very robust third party 
packages like the ones mentioned 
on http://www.sagemath.org/links-components.html . A first glance of your 
code shows that you just modify and add .py files in the core sage library. 
However just modifying .py files is not adding a third party package so you 
should just file your ticket under the mathematical component that your 
ticket falls under.

Is this your first contribution to sage?
If so, do you have anyone that you personally know that has succesfully 
contributed to sage in the past? Making a first succesfull contribution to 
sage that also meets all the standard that your code has to satisfy without 
the guidance of a more experienced sage developer is something that is 
really difficult.

Another option to make your code available instead of modifying the sage 
source code is just to make a pip package like I did with my private sage 
code in order to make it reusable for others: 
https://github.com/koffie/mdsage . Depending what you are expecting this 
might be a good choice. If your standalone package becomes succesful it can 
then later still be included in sage.

Thanks,
Maarten

On Wednesday, 23 May 2018 00:13:25 UTC+2, Victor Porton wrote:
>
> I committed a new feature of Sage 4 months ago. It is now needs_review. 
> Why is it not yet accepted? Is something wrong? Or should I just wait more?
>
> https://trac.sagemath.org/ticket/24542 
> 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sage Days about Python 3

[Maarten Derickx]

Ha Jeroen,

I am quite busy this summer because of my upcoming move to the US, would it 
be useful to have someone joining for just one or two days? I.e. will there 
be any python3 related tasks that you imagine could be doable by one person 
in one day? I will be in the Netherlands that week anyway, so taking the 
train to gent is not that bad.

Thanks,
Maarten

On Tuesday, 26 June 2018 21:13:14 UTC+2, Travis Scrimshaw wrote:
>
> Hi Jeroen,
>I will be happy to participate remotely, but I will be in the Pacific 
> timezone by that point.
>
> Best,
> Travis
>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Improving code with AI?

[Maarten Derickx]

A big +1 on adding a "plain old rule-based lint" like pyflakes to the 
testsuite.

On Wednesday, 2 May 2018 20:03:24 UTC+2, Erik Bray wrote:
>
> On Wed, May 2, 2018 at 4:41 PM, John Cremona  > wrote: 
> > On another python project I contribute to  (LMFDB) we have for some time 
> > only merged commits which satisfy pyflakes 100%.  It's a much smaller 
> > project than Sage, and when we first started using pyflakes there was 
> quite 
> > a lot of work to do, some of which seemed rather unnecessary, but also a 
> lot 
> > of actual and potential bugs were discovered and fixed. 
> > 
> > Doing the same to Sage would also be  a huge amount of work if all done 
> at 
> > once, but it could be done incrementally (*).  In fact, I already use 
> > pyflakes to examine Sage course files I am working on and slip in some 
> > changes it prompts as well as everything else in the patch. 
> > 
> > I know that there are many such tools out there and am not proposing 
> using 
> > any of them in particular, just reporting on one situation where the 
> result 
> > was positive and where LMFDB developers would not want to put the clock 
> > back.  This has nothing to do with algorithmic efficiency. 
>
> Indeed--at some point I plan to start running pyflakes over Sage.  A 
> lot of stuff is getting fixed up in the process of implementing the 
> Python 3 support, but that should be the primary focus first.  Later, 
> adding a per-commit pyflakes check will be easy. 
>
> > (*) For example in src/sage/schemes/elliptic_curves/*.py there are 
> "only" 
> > 138 lines of output from pyflakes now almost all of which would be 
> trivial 
> > to fix (things imported but not used, variables assigned to but not used 
> -- 
> > which can be an indication of a typo giving a bug.  You also see 
> > "ell_curve_isogeny.py:1672: undefined name 'InputError'" which I already 
> > fixed as part of https://trac.sagemath.org/ticket/23222 . 
> > 
> > On 2 May 2018 at 14:21, Peter Luschny  
> wrote: 
> >> 
> >> 
> >> rjf> The chance that Machine Learning AI programs will find 
> >> rjf> important algorithmic efficiency fixes in algebraic 
> >> rjf> mathematical implementations seems pretty slim. 
> >> 
> >> Improving code is something other than improving algorithmic 
> >> efficiency of high-level algorithms, of whatever kind. The 
> >> latter is certainly not an option yet. But as soon as such 
> >> tools look simultaneously on written and compiled code new 
> >> opportunities will arise. 
> >> 
> >> rjf> On the other hand, if you have gobs of code written by high 
> >> rjf> school summer interns just learning Python, it is possible 
> >> rjf> their code is filled with non-idiomatic and inefficient 
> >> rjf> constructions that might be detected/repaired. 
> >> 
> >> The assumption that only the inexperienced beginner makes 
> >> stupid mistakes or writes optimizable code is not likely to be 
> >> shared here. But if, as you can seemingly imagine, such can 
> >> be pointed to by checkers/optimizers, then the level of 
> >> experience of the coder obviously does not matter. 
> >> 
> >> Between these two extremes are the daily necessaries of the 
> >> programmer, and that is what it is all about. In this respect 
> >> I find Volker's answer informative and revealing at the same 
> >> time. 
> >> 
> >> vb> First we should add one of the plain old rule-based linters 
> >> vb> to our testsuite, imho that would go a long way of maintaining 
> >> vb> a consistent code style (and avoid trivial review friction). 
> >> 
> >> I have expected a lot of people answering Volker: "Hey, you 
> >> are right, after the next release let's introduce such tools 
> >> before we continue." 
> >> 
> >> Since such answers did not come in I gladly admit to having 
> >> asked the question in the wrong place and at the wrong time. 
> >> 
> >> The question for me remains whether this reluctance towards 
> >> such tools is typical for open-source/academic projects. 
> >> Interestingly also Volker writes only about 'code style', not 
> >> of other forms of improvements. I have the impression that 
> >> the situation in the industry is quite different. 
> >> 
> >> rjf> It's your choice how to spend your time. Is it worth a try? 
> >> 
> >> You are absolutely right. I don't know any plausible estimate 
> >> that the programming time developers spend for debugging is 
> >> less than 50%; many estimates are significantly higher. But 
> >> that's an old hat. 
> >> 
> >> P. 
> >> 
> >> -- 
> >> 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+...@googlegroups.com . 
> >> To post to this group, send email to sage-...@googlegroups.com 
> . 
> >> Visit this group at https://groups.google.com/group/sage-devel. 
> >> For more options, visit https://groups.google.com/d/optout. 
> > 
> > 

Re: [sage-devel] dicts in doctests

[Maarten Derickx]

On Tuesday, 12 December 2017 15:30:39 UTC+1, Erik Bray wrote:
>
> On Fri, Dec 8, 2017 at 10:10 AM, Erik Bray  > wrote: 
> > On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky  > wrote: 
> >> On 12/06/2017 09:49 AM, Erik Bray wrote: 
> >>> 
> >>> Did anyone ever think up a better solution to this? 
> >>> 
> >> 
> >> Whatever you do, you wind up with a big pile of dict output in the 
> >> middle of your test case. So (where possible) you might as well use 
> that 
> >> space to define a new dict containing the expected value. For example, 
> >> 
> >>   >>> actual = some_computation() 
> >>   >>> expected = { 1: "one", 
> >>   ...  2: "two", 
> >>   ...  9: "nine" } 
> >>   >>> actual == expected 
> >>   True 
> >> 
> >> That's harder to do when the dict is buried in some other data 
> >> structure, but maybe we shouldn't be testing the exact string 
> >> representation of some big conglomerate in the first place -- do we 
> >> actually care what it is? Instead, we should test only what we care 
> about. 
> >> 
> >> Regardless, I don't think the framework should make it look like you 
> can 
> >> rely on dicts being sorted when you can't. Users should be able to run 
> >> the EXAMPLES and see what we say they'll see. 
> > 
> > That is a good thing and a bad thing about so many of the tests 
> > doubling as "examples" in the documentation (especially for 'public' 
> > methods to the extent that there is such a thing).  You want them to 
> > actually function nicely as examples of how a user should use an 
> > interface and what a user should expect to see.  Going into 
> > contortions in order to make it function reliably as a test can be at 
> > odds with that. 
> > 
> > If we're talking one dict it's not much of a problem.  The main 
> > problem seems to be with more complex objects that contain dicts 
> > nested in their reprs.  And you do sometimes want to test the repr 
> > string itself too (that, however, could be in the form of a TEST not 
> > an EXAMPLE). 
>
> Another workaround that's so obvious I smacked myself on the head is 
> that for many cases, particularly objects that have a small dict in 
> their representation, is to simply change the __repr__ so that its 
> dict is always displayed sorted.  If the order doesn't matter anyways 
> that it doesn't hurt to impose an order at least for the __repr__.  I 
> doubt there are many cases where this should have any performance 
> impact either.
>

I think this is indeed the way to go. In fact this is what I was trying to 
say with my remark "In more complicated data structures it is probably more 
a sign of the complicated data structure not pretty printing itself in a 
nice way (i.e. failing to pretty print the dicts it depends on) then 
anything else.". Which I admit is a bit cryptic, but essentially suggests 
your workaround because dicts are sorted when pretty printed.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: SageNB and ldap packages

[Maarten Derickx]

Hi Jori,

Maybe not a direct answer to your question. But if you plan on setting up 
an ldap authenticated sage server these days and you are planning on 
actually maintaining it for some time in the future, I would not go the 
SageNB way, since SageNB is not really being actively developed anymore.

I think the way to go would be to setup jupyterhub and connect that with 
ldap. This can be done using the jupyterhub ldap plugin at: 
https://github.com/jupyterhub/ldapauthenticator

On Friday, 8 December 2017 09:56:07 UTC+1, Jori Mäntysalo wrote:
>
> How to set up SageNB with LDAP to SageMath 8.1? 
>
> After some trying I ended up with line 
>
> from ldap.functions import strf_secs 
>
> trying to give an error message but even ending with 
>
> ImportError: cannot import name LDAPError 
>
> i.e. error in error reporting. I was able to install SageNB such that it 
> either says that my password is wrong or give 500 Internal error, so I 
> suppose that most parts of the system are working. 
>
> -- 
> Jori Mäntysalo 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Why doesn't #23931 get merged?

[Maarten Derickx]

On Friday, 8 December 2017 10:26:06 UTC+1, Erik Bray wrote:
>
> On Thu, Dec 7, 2017 at 6:26 PM, William Stein  > wrote: 
> > On Thu, Dec 7, 2017 at 7:02 AM, Frédéric Chapoton  > wrote: 
> >> We have currently 115 such positive-reviewed tickets waiting for 
> inclusion, 
> > 
> > Maybe the release manager could use some assistance? Or we could 
> > rotate to more release managers like we used to do for many years... 
>
> Two things that would be helpful and more like "most" open source 
> projects (quotes because I have no data to back this up, but from 
> experience): 
>
> a) Have a normal "bleeding edge" master branch into which all accepted 
> changes are immediately merged--no waiting (for developers) to get a 
> development "release" before getting new changes in. 
>
>

The branch could already be programmatically created by a bot based on the 
positive review status of trac. I think this could be of huge value in 
terms of seeing wether your code cleanly merges with already positively 
reviewed code, and for testing purposes as well. However if something like 
this is done it should be made very clear to everybody to not base any code 
on this branch (only merge your code with it on a separate branch from time 
to time to see wether there are merge conflicts and passes all test after 
the merge).

To actually make code get included faster in some branch that at some point 
will be the next release I think there indeed needs to be some extra 
"acceptance" mechanism on top of the current positive review one. Since the 
current positive review does not provide enough guarantees that a ticket is 
actually good enough that we as a community want to commit to actually get 
that ticket into the next release, and timely fix the unsuspected blocker 
tickets it might introduce. I do like the idea of having certain trusted 
core developers helping to distribute the work of the release manager, but 
they would have to be really good and trustworthy enough so that they 
actually save work and not cause extra work and frustration.

 

> b) More people who can merge into master--while it makes sense to have 
> one "release manager" responsible for keeping a schedule and ensuring 
> stability of the release (including occasionally putting on hold big 
> changes that might hold up a release), it also makes sense to have 
> multiple delegates of approving and merging changes in different areas 
> of the code, helping to set priorities, and triaging.  This can be 
> entrusted to multiple people with the help of guidelines to make sure 
> they check all the right boxes when approving a change.  For example: 
>
> http://docs.astropy.org/en/stable/development/workflow/maintainer_workflow.html
>  
> 
>  
>  .  CPython has a similar document I've seen before, but I can't find 
> it at the moment, as do many other large projects.  I believe Sage 
> might too... 
>

I also think this blogpost has a very nice description on how to deal with 
git and different releases:  
http://nvie.com/posts/a-successful-git-branching-model/ . The develop 
branch there is playing the role of your "bleeding edge master", and the 
master branch is only used for official releases. But the underlying 
principle is the same. There could be some core developers who have right 
to commit things to the develop aka "bleeding edge master" branch.

To make it match also with all the beta's we do the master branch there 
should maybe split up into a "beta-master" and a "master" branch. With the 
"beta-master" containing all releases including beta's rc's and the 
"master" branch just containing the actual releases like 8.0 and 8.1.

Depending on how much time it would cost Volker to already start the 
develop branch for the next release while waiting for the blockers to get 
fixed in the rc of the current release. Having both of these exist at the 
same time could solve some of the frustration of things not getting merged. 
Although I think in a certain sense the not having other things get merged 
could also be seen as a feature instead of an annoyance, since it provides 
a good natural incentive for fixing the blockers.

That being said, I feel that the people who have actually have been release 
manager should have a larger say in this then me, since they actually know 
how it is to do all the hard and dirty work.


 

>
> >> see 
> >> 
> >> 
> https://trac.sagemath.org/query?status=positive_review=!sage-duplicate%2Finvalid%2Fwontfix=milestone=id=summary=type=component=changetime=author=reviewer=dependencies=40=1=changetime
>  
> >> 
> >> 
> >> Le jeudi 7 décembre 2017 15:39:07 UTC+1, Friedrich Wiemer a écrit : 
> >>> 
> >>> The ticket #23931 has a positive review for quite some time and I'm 
> not 
> >>> aware of any changes left for it, so my 

Re: [sage-devel] dicts in doctests

[Maarten Derickx]

I strongly dislike the idea making the doctesting framework more 
complicated by parsing the output like this. I think this should only be 
done as a last resort, since it makes the doctesting framework itself more 
error prone, and if implemented incorrectly might even silently let real 
error slip by. In more complicated data structures it is probably more a 
sign of the complicated data structure not pretty printing itself in a nice 
way (i.e. failing to pretty print the dicts it depends on) then anything 
else.

p.s. according to https://trac.sagemath.org/ticket/23586 it will help a lot 
if we upgrade ipython to a version 
where https://github.com/ipython/ipython/pull/10767 is merged before 
switching to py3. I do not know wether this has been done already on some 
other ticket.

On Wednesday, 6 December 2017 16:07:03 UTC+1, Erik Bray wrote:
>
> On Wed, Dec 6, 2017 at 3:59 PM, Jeroen Demeyer  > wrote: 
> > On 2017-12-06 15:49, Erik Bray wrote: 
> >> 
> >> I think this question has come up before, but I don't know that 
> >> there's been a really satisfactory solution. 
> >> 
> >> Many of the doctests have dicts as their output (or worse, contained 
> >> embedded in their output).  This can fail from time to time since dict 
> >> element order is not guaranteed. 
> > 
> > 
> > In doctests, the output of dicts is sorted. So I guess you run into 
> trouble 
> > only when 
> > 
> > (A) The dict is embedded in some deeper structure: no general solution, 
> a 
> > case-by-case fix is needed 
> > 
> > (B) The sorting is different in Python 2 and Python 3: this is a general 
> > consequence of the __cmp__/__richcmp__ differences. One important ticket 
> is 
> > https://trac.sagemath.org/ticket/22029 
> > 
> > (C) The keys cannot be sorted: fixed by 
> > https://github.com/ipython/ipython/pull/10767 which is not in Sage yet. 
> > 
> > I would not try to fix cases (B) and (C) in doctests because they will 
> be 
> > fixed at some point anyway. 
>
> Aha, thanks for the summary of the current state of affairs.  I didn't 
> realize plain dicts were already sorted in their repr--that is good. 
>
> In that case probably most of the examples I've encountered are indeed 
> with more nested data structures.  I'd have to double-check but that 
> sounds right for the examples I can think of off the top of my head. 
>
> I think then for (A) the most general solution would be the one I 
> suggested--of basically scanning for dict literals, parsing them, and 
> reordering them.  This isn't too hard in most cases; the only concern 
> might be if there are any cases of output that looks exactly like a 
> dict literal but for some reason isn't, and shouldn't be messed with. 
> I don't know that there are any cases like that though. 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Proposal : a branch for OpenSSL-less Sage

[Maarten Derickx]

On Friday, 27 October 2017 16:19:30 UTC+2, Emmanuel Charpentier wrote:
>
> Dear Marteen,
>
> Le vendredi 27 octobre 2017 16:02:03 UTC+2, Maarten Derickx a écrit :
>>
>> Why a separate git branch and not make it something configurable, like 
>> building sage with gmp vs mpir?
>>
>
> Because those are not the same cases :
>
>
Well, yes there clearly are differences between to the two scenarios. But 
your arguments are all either just a) pointing out differences between the 
mpir vs OpenSSL situation or b) arguments against the usefulness of being 
able to build sage without OpenSSL and this is not what I was asking for. 
What I actually was looking for were arguments for why having a branch is a 
better idea then making it something configurable. I think the choice 
between a branch and something configurable is something that is just a 
technical difference on how to achieve the wished end result (make it 
possible to compile sage without OpenSSL). So here some reasons why I think 
a separate branch is a worse idea then making the instalalation of OpenSSL 
configurable:
1) A separate branch creates way more maintenance work then making it 
configurable since now something needs to be done each release, instead of 
potentially doing something when R is updated.
2) Because a separate branch it is quite a far fetched solution compared to 
using configure and make and maybe some environment variables which are the 
standard tools for deciding how and what to build.
3) It deviates from the way sage currently behaves with respect configuring 
which packages to install, requiring the user to learn something new. 
Making the sage the distribution experience feel less coherent.
 

> a) there is no currently (to the best of my limited knowledge) , strong 
> reasons to choose one over the other,
> b) they give (modulo my limited knoiwledge, again) roughly the same 
> possibilities to Sage,
> c) there are people able, and **volunteering**, to maintaint this 
> alternative.
>
> In the case of OpenSSL not having OpenSSL:
>
> a) doesn't give us anything but the ability to do without a package deemed 
> "GPL incompatible" (in the sense that we currently cannot ship it  with 
> Sage)
>

Which is a useful ability to have considering the bad experience almost al 
sage-devs on OS X had getting this to work.
 

> b) deprives R and pip users of an useful ability (deemed mandatory by R 
> authors)
>

Or worded differently: gives people the option to have a working sage 
installation missing just two of its many features instead of no sage 
installation at all if getting sage to work with OpenSSL turns out to be 
too difficult. This is what Jeroen meant with his Koan about that an R that 
builds without OpenSSL can be very usefull for people not using R, since it 
means they can forget about the non trivial step (on some platforms) of 
getting OpenSSL to work.
 

> c) forces us to maintain a patch that is of no use to what I think a 
> majority of Sage users.
>

Well I think the statement "this patch is of no use to what I think a 
majority of Sage users" is a very important statement since the answer to 
the key question: "Do we wish to support building sage without OpenSSL?" 
hinges on wether you consider c) to be true. Several people (including me, 
but also other sage developers I talked to at some sage days) have had 
serious trouble getting sage to build with OpenSSL so having an option to 
avoid these troubles at the cost of a less functional R and pip is 
certainly something useful for at least a significant minority of the Sage 
users. 

Additionally I think demanding something to be useful to a majority is a 
way to strong criterion for when to support something in sage or not, 
otherwise we could also probably also say: R in sage is not used by the 
majority of Sage users so we might as well not ship it.

Now wether "this patch is of no use to what I think a majority of Sage 
users" is true also very much depends on how difficult it is to get sage to 
work with OpenSSL, if this is trivial then of course the patch is of no 
use. But I think at least in the current sage it is not trivial on all 
platforms. For this reason I am for anything that is working in the 
direction of making it easier to get sage to work with OpenSSL, however the 
proposed changes have not been implemented/let alone be battle tested. And 
requiring OpenSSL to build sage is a change of the status quo. Personally I 
certainly believe that in the long term we should just require OpenSSL, but 
at this moment right now I think it is also important to provide a clean 
migration path. Right now requiring OpenSSL is actually doing two things at 
once:

1) change the default from building without OpenSSL support to building 
with OpenSSL support.
2) remove the possibility of falling back to the old default of bu

[sage-devel] Re: Proposal : a branch for OpenSSL-less Sage

[Maarten Derickx]

Why a separate git branch and not make it something configurable, like 
building sage with gmp vs mpir?

On Wednesday, 25 October 2017 18:01:00 UTC+2, Emmanuel Charpentier wrote:
>
> The recent vote on the inclusion of OpennSSL in Sage has shown that some 
> Sage developers [wished](
> https://groups.google.com/d/msg/sage-devel/fE45025Wphs/mKdCAeNhAgAJ) to 
> keep the ability to build Sage without dependence on this contentious 
> library.
>
> I think that this can be implemented, thanks to Git, in the following 
> manner :
> * Prepare a branch (let's say `anchorite`).
> * Follow the [Trac ticket](https://trac.sagemath.org/ticket/24107) aiming 
> at the inclusion of OpenSSL
> * At this ticket merge into Sage, revert the pertinent commits in 
> `anchorite`
> * At each point you want to release, merge with the branch you wish to 
> reach to in `master` or `develop`, and reverse again.
> * If new additions or patches rely on the presence of OpenSSL, add them to 
> your set of patches to be reversed, rinse and repeat...
>
> In short, the delta between `master` or `develop` and `anchorite` will be 
> the sum of patches reversal involvig OpenSSL.
>
> This is easy to do for people using git as thei source. The problem is not 
> so simple to release tarballs or binaries : a synchronization with the 
> release manager is necessary. And I haven't the foggiest idea on how to 
> proceed, for lack of knowledge of the release process.
>
> No ,proposal ticket (yet), since this is mainly an organizational issue...
>
> Your inputs, please ?
>
> --
> Emmanuel Charpentier
>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Maarten Derickx]

On Wednesday, 18 October 2017 18:23:53 UTC+2, Thierry 
(sage-googlesucks@xxx) wrote:
>
> Hi, 
>
> the dichotomy of the vote is not clear to me. 
>
> I am -1 to make openssl a stantard package (hence shipped with the source 
> tarball), not only regarding licensing issues but also for security 
> reasons: our "package manager" is such that packages can not be updated 
> unless Sage itself is updated (because the package version is hardcoded). 
> Hence, when a security issue is found and fixed in openssl, the user who 
> installed it from Sage won't get it until the user upgrades Sage (while 
> every decent distro will provide a hotfix). 
>
> However, i am +1 that we should do our best to let the user have an 
> openssl-enabled version of Sage (for pip, R, some cryptographic hash,...), 
> an acceptable workflow could be: 
>
> - check if libssl-dev (or similar) is installed on the OS 
>   - yes: 
> - use it 
>   - no: 
> - strongly complain about it, provide documentation on how to do it 
>   (possibly provide a doc that depends on the system), 
> - propose 3 options: 
> - "i will install openssl from the distro, and come back later 
>   (recommended)" 
> - "i want Sage to install openssl optional package, i know that 
>   there will be security issues" 
> - "i do not want openssl support, i know that i will not be able 
>   to install any R or Python package from the web" 
>
>
+1 for this.
 

> If the last point (compiling Sage without openssl support) requires a lot 
> of work, i am OK to remove it (i am not sure if this is the point of the 
> vote). 
>
> Note that that there is no chicken-and-eggs issue since the way our 
> "package manager" works allows to install an optional package without 
> having to rely on openssl (no https), we only rely on the computation of 
> sha1 which python-hashlib offers even if it is build without openssl 
> support. 
>
> By the way, Sage is not GPL-3+ but GPL-2+. 
>
>  
>
> Mac fans claim that paying a computer 1.5 the price of a random PC with 
> similar charateristics if justified by the fact that OSX is s 
> user-friendly, perhaps didn't they find the openssl one-click installer 
> right in the middle of the screen yet. 
>
> Proposal: require Apple a grant, corresponding to the huge amount of time 
> Sage developpers waste in porting Sage components (not only openssl, just 
> have a look at trac, sage-devel and ask timelines) on their broken and 
> constantly changing OS. This is not our job to help Apple pretend their 
> system is user-friendly, we are losing a lot of energy which could be 
> spent in much more interesting parts of Sage (e.g. mathematics). 
>
>  
>
> Ciao, 
> Thierry 
>
>
>
>
> On Mon, Oct 16, 2017 at 03:08:51AM -0700, Emmanuel Charpentier wrote: 
> > [ The first post started too fast... Sorry for the interruption ! ] 
> > 
> > Following numerous discussions on this list and various Trac tickets*, 
> the 
> > issue of maintaining Sage-specific patches to various components of Sage 
> > emerged again about the proposed upgrade 
> >  of R to 3.4.2 (discussed here 
> > ). 
> William 
> > again raises 
> >  
> the 
> > issue of security. 
> > 
> > Since Trac#22189 , installation 
> of 
> > a systemwide opennssl is recommended (may be too strongly 
> > , in the taste of some 
> respectable 
> > Sage developers...). The ongoing relicensing of OpenSSL should lift the 
> > last barriers to its inclusion in sage. A discussed here 
> > ,, the 
> > probability of a legal problem related to the incusion of this library 
> in 
> > Sage seems infinitesimal. 
> > 
> > It has beeen furthermore suggested 
> >  
> to 
> > add to our licensing (an adaptatin of) the following language, used in 
> Gnu 
> > Wget License (GPL) : 
> > 
> > "Additional permission under GNU GPL version 3 section 7 
> > 
> > If you modify this program, or any covered work, by linking or combining 
> it 
> > with the OpenSSL project's OpenSSL library (or a modified version of 
> that 
> > library), containing parts covered by the terms of the OpenSSL or SSLeay 
> > licenses, the Free Software Foundation grants you additional permission 
> to 
> > convey the resulting work. Corresponding Source for a non-source form of 
> > such a combination shall include the source code for the parts of 
> OpenSSL 
> > used as well as that of the covered work." 
> > 
> > 
> > The proposed inclusion would entail : 
> > 
> >- Deprecation of our OpenSSL-avidance patches 
> >- Standardization of SSL communications on OpenSSL 
> >- At compilation, research 

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Maarten Derickx]

On Wednesday, 18 October 2017 03:35:15 UTC+2, Michael Orlitzky wrote:
>
> On 10/17/2017 08:42 PM, Maarten Derickx wrote: 
> > 
> > What makes you think their process is dubious? They are reaching out for 
> > consent from all people who have contributed, and they have removed the 
> > code from the several people who have objected on record. 
> > 
>
> The mail that they sent to contributors ended with, 
>
>   If we do not hear from you, we will assume that you have no objection. 
>
> That's not the way it works, but if they've changed their approach, I'll 
> be happy to be wrong in this case. 
>

Hmmm that line in the e-mail is very different from what is suggested by 
their public announcements, like for 
example 
https://www.coreinfrastructure.org/news/announcements/2017/03/openssl-re-licensing-apache-license-v-20-encourage-broader-use-other-foss
 
. To quote from that section:

“This re-licensing activity will make OpenSSL, already the world's most 
widely-used FOSS encryption software, more convenient to incorporate in the 
widest possible range of free and open source software," said Mishi 
Choudhary, Legal Director of Software Freedom Law Center (SFLC) and counsel 
to OpenSSL. “OpenSSL's team has carefully prepared for this re-licensing, 
and their process will be an outstanding example of 'how to do it right.’

This gives me the confidence that they will not take a dubious unlawful 
approach, even though I find the wording in the e-mail dubious as well. 

To all the people reading this and caring about the OpenSSL license change: 
please visit https://license.openssl.org/cgi-bin/authors.py . Here you can 
see a list of contributors who have not yet responded to the license change 
request, and helping with getting OpenSSL to reach them will surely help 
with the license change. 

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Maarten Derickx]

|x| Yes, we should fully support OpenSSL now, and clarify the licensing 
issue.

Where I want to add that my support is conditional on that this can be done 
in a legal way.

On Monday, 16 October 2017 11:47:09 UTC+2, Emmanuel Charpentier wrote:
>
> Following numerous discussions on this list an various tickets, the issue 
> of maintaining Sage-specific patches to various components of Sage emerged 
> again about the proposed upgrade  
> of R to 3.4.2 (discussed here 
> ).
>
> Since Trac#22189 , installation 
> of a systemwide opennssl is recommended (may be too strongly 
> , in the taste of some 
> respectable Sage developers...).
>
> The proposed inclusion would entail :
> Deprecation of our OpenSSL-avidance patches
> Sta
> At compilation, research of a systemwide OpenSSL
> If found : do nothing
>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Maarten Derickx]

On Tuesday, 17 October 2017 22:46:52 UTC+2, Michael Orlitzky wrote:
>
> On 10/17/2017 03:56 PM, Emmanuel Charpentier wrote: 
> > 
> > Throwing my vote away: 
> > 
> > [X] Require OpenSSL to be installed on the system. 
> > 
> > 
> > That's not one of the proposed options. 
>
> That's what I meant by "throwing my vote away" =) 
>
>
> > But it seems to imply that we should wait for OpenSSL relicensing. 
>
> We don't have to wait if we require it to be installed on the system. 
>
> "Wait for OpenSSL to relicense" is a bad option because they will 
> probably never relicense -- even if they ultimately change their LICENSE 
> file, the process by which they've done it is extremely dubious, and 
> several copyright holders are on record withholding permission to do so. 
>
>
What makes you think their process is dubious? They are reaching out for 
consent from all people who have contributed, and they have removed the 
code from the several people who have objected on record.

"Include it anyway" is a bad option because we've just announced to the 
> world that we're going to commit (willful) copyright infringement. 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] optional package mpfrcx not on the mirror

[Maarten Derickx]

This is probably because it is still in beta. The tarbal can be found at 
https://trac.sagemath.org/ticket/11806

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] switching back to readline-based IPython tab completion? (or live with segfaults etc?)

[Maarten Derickx]

Did you report this to IPython? What did they have to say about it?

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] submodules subvectorspaces violate the unique parent condition. Why? Should we change that?

[Maarten Derickx]

The reason why unique parents were introduced is for speed and memory reasons. 
Having a million copies of the same parent around is a bit of a waste, but this 
is something that happens quite easily if one does not make parents unique. I 
also noticed that submodules violate the "equal => equal hash principle" since:

X = QQ^2
V = X.span([[1,0],[0,1]])
W = X.span_of_basis([[1,0],[0,1]])

Are all equal but have distinct hashes.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: sets and sorted tuples, possibly python 3 related

[Maarten Derickx]

In Python 3 you can still sort. But the elements that you are sorting have to 
be of the same type. So no mixing of lists with strings, integers and tuples 
anymore. But sorting a list of strings is no problem.

For the given ticket I would not replace the internal representation and just 
stick to fixing the hash function.

Looking for what the best internal representation is, is not something that has 
nice precut answers and requires a lot of performance testing. If you care 
about speed I would make the improved internal representation for performance 
reasons a separate ticket.

Things to test would be:
1. Initialisation time of matchings
2. A subset to your liking of the most important high level functions of 
matchings
3. Some low level access function of matchings
4. All of the above for both small and big matchings.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Tracebacks please!

[Maarten Derickx]

I want to add to this that including both your operation system and sage 
version are also very useful in this respect (and sometimes even your 
processor type).

On Thursday, 5 October 2017 13:22:36 UTC+2, Jeroen Demeyer wrote:
>
> Hello all Sage developers, 
>
> I am getting more and more annoyed that many people tend to report bugs 
> (both on Trac and on the mailing list) *without* tracebacks. 
>
> Those tracebacks are often crucial information to fix a bug. For a 
> totally reproducible and deterministic bug, this isn't so bad since I 
> can always run the code myself and see what happens. 
>
> But for errors that I cannot reproduce, the traceback is what I need to 
> understand what is going wrong. 
>
> So, please remember: the next time you report a bug, do include the 
> *full* output that you get. 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Profiling memory usage from sage command-line

[Maarten Derickx]

Does the function:

get_memory_usage


Do what you want? If you want to know what objects are in memory then maybe 
something like:

sage: *import* *gc*

sage: gc.get_objects()

Or other related gc commands might give what you want. Or you could use 
https://pypi.python.org/pypi/memory_profiler by doing:

sage -pip install memory_profiler


On Wednesday, 4 October 2017 14:30:59 UTC+2, Rusydi H. Makarim wrote:
>
> Hi
>
> Suppose I have a polynomial Ideal 'J' and I want to call 
> J.groebner_basis() . My goal is to profile the memory usage of groebner 
> basis computation in SageMath. How can I do this from the sage command line 
> ?
>
> Regards,
> Rusydi
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Is trac down?

[Maarten Derickx]

Seems to be back up again.

On Tuesday, 26 September 2017 12:13:38 UTC+2, Jeroen Demeyer wrote:
>
> On 2017-09-26 12:10, Maarten Derickx wrote: 
> > I can't seem to reach trac.sagemath.org , the page seems to take 
> forever 
> > to load. Do other people have this problem as wel? 
>
> Me too. 
>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Is trac down?

[Maarten Derickx]

I can't seem to reach trac.sagemath.org , the page seems to take forever to 
load. Do other people have this problem as wel?

Thanks,
Maarten

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Error installing package pyzmq

[Maarten Derickx]

Hi Tasos, 

Thanks for reporting this. The issue described here 
https://groups.google.com/forum/m/#!topic/sage-devel/2cdsAGTxYm8 might be 
related.

Also one of the deeper underlying reasons might be that sage is not tested 
enough on Open Suse at the moment as you can see on 
https://patchbot.sagemath.org/machines . If you have a machine running open 
Suse, permanently connected to the internet and some CPU cycles to spare then 
it would be very helpful for other Open Suse users if you would consider 
setting up a patchbot for running tests as described at  
https://wiki.sagemath.org/buildbot (after you have fixed the issue at hand of 
course).

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sort ambient spaces by inner product as well?

[Maarten Derickx]

Note that there is no distinction between the FreeModule with 
inner_product_matrix=matrix.identity(1)*2 and FreeQuadraticModusince the 
sage object created in both ways is the same object. Not just equal, but 
literally the same object in memory, so any change will automatically 
affect both.

FreeQuadraticModule(ZZ,1,matrix.identity(1)*2) is 
FreeModule(ZZ,1,inner_product_matrix=matrix.identity(1)*2) 

I think it is good to open a ticket to make == also take the inner product 
matrix into account, and I think no deprecation is needed since it fixes 
something which is mathematically incorrect.

One more subtle question is wether we want:

sage: 
FreeModule(ZZ,1)==FreeModule(ZZ,1,inner_product_matrix=matrix.identity(1))


On Thursday, 21 September 2017 10:13:13 UTC+2, Simon Brandhorst wrote:
>
> Currently, comparison of free_module_generic (and free_quadratic_modules) 
> ignores the inner product matrix
>
> sage: 
> FreeModule(ZZ,1)==FreeModule(ZZ,1,inner_product_matrix=matrix.identity(1)*2)
> True
> sage: 
> FreeQuadraticModule(ZZ,1,matrix.identity(1))==FreeQuadraticModule(ZZ,1,matrix.identity(1)*2)
> True
>
> Especially for FreeQuadraticModules, the inner_product_matrix is essential 
> and two FreeQuadraticModules are certainly different (mathematically) if 
> their inner product is different.
>
> Is that intended behavior? If not, I would like to open a ticket. Do I 
> need a deprecation warning or something for that ? 
>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] proposal: remove libogg and libtheora completely from sage

[Maarten Derickx]

Since the people in the thread "proposal: downgrade libtheora to 
experimental package" 
at https://groups.google.com/forum/#!topic/sage-devel/olOxh1f6-cc were 
quite in favour of going even further then just downgrading it here a 
concrete proposal:

remove the optional libogg and libtheora packages completely from sage.

for motivation one can see the other thread. Short summary, they don't seem 
to add anything a lot of value to sage the library and shipping video and 
audio codecs is not really a goal of sage the distribution, so we should 
not include them even as optional package. Furthermore installing libtheora 
is currently broken.

The main reason why I start this new thread is that I think it should be 
clear from just the subject title what the proposed change is, so that the 
sage developers not reading all the details of a long discussion don't feel 
surprised if these packages are suddenly gone. 

If people have any objections to this please let me know.


-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] proposal: downgrade libtheora to experimental package

[Maarten Derickx]

On Tuesday, 19 September 2017 15:07:23 UTC+2, vdelecroix wrote:
>
> On 19/09/2017 14:22, Maarten Derickx wrote: 
>
> > Currently the optional package libtheora fails to install: see 
> > https://trac.sagemath.org/ticket/23732 for details. 
>
> Actually, I also had troubles on Ubuntu 64 bits (based on debian). 
>
>
>From a logical point of view it should actually fail on any operating 
system where one builds sage from source. The reason is that the version of 
libtheora is incompatible with the version of libpng (standard package) 
that we ship.
 

> Vincent 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] proposal: downgrade libtheora to experimental package

[Maarten Derickx]

Hi Fellow sage devs cc Wilfied Huss,

Currently the optional package libtheora fails to install: see
https://trac.sagemath.org/ticket/23732 for details.

I have looked a bit into this, and I could not find a place where this
package actually enhances the sage library so this would just be a package
that is easy to install in sage the distribution. However I don't really
see what the reason is to have a video processing library in "sage the
distribution" if it is not nicely integrated in sage the library (like
easily creating a video from a sequence of plots or something like that).
Additionally the package maintainer Willfried Huss is not responding on
trac and the ticket where libtheora was created as an optional package
https://trac.sagemath.org/ticket/7297 does not present a strong case for
why it should be in sage.

Therefore I propose to downgrade libtheora to an experimental package.

Is there anyone objecting to this?

Thanks Maarten

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: trying to speed up construction of sets in setpartition

[Maarten Derickx]

The parents being created are the same in your case:

sage: S = SetPartition([[2,3],[1]], check=False)
sage: S
{{1}, {2, 3}}
sage: S.parent()
Set partitions
sage: S2 = SetPartition([[2,3],[1,4]], check=False)
sage: S.parent() is S2.parent()

but I see on trac that you now have Simon King also looking at it. He 
should know everything you need to know about the category framework and 
more.

On Monday, 18 September 2017 10:20:50 UTC+2, Martin R wrote:
>
> I must admit that I don't really know what parents are created.  A profile 
> is at https://trac.sagemath.org/ticket/23877 
> <https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F23877=D=1=AFQjCNH0xVKF--Lpiv7tL3cCaXDDIHfgDQ>
>
> How could I find out?
>
> Am Montag, 18. September 2017 10:17:09 UTC+2 schrieb Maarten Derickx:
>>
>> Hi Martin,
>>
>> Creating a parent might be time consuming the first time. But it should 
>> be cashed so if you recreate the same parent over and over only the first 
>> one should be slow. To test whether caching is working for your parent 
>> create it twice with the same parameters and test whether 'parent1 is 
>> parent2' evaluates to true.
>>
>> If you are creating a lot of distinct parents then it is a more difficult 
>> problem
>>
>>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] trying to speed up construction of sets in setpartition

[Maarten Derickx]

Hi Martin,

Creating a parent might be time consuming the first time. But it should be 
cashed so if you recreate the same parent over and over only the first one 
should be slow. To test whether caching is working for your parent create it 
twice with the same parameters and test whether 'parent1 is parent2' evaluates 
to true.

If you are creating a lot of distinct parents then it is a more difficult 
problem

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Sage building issue

[Maarten Derickx]

You should do "make TARGET=YOUR_CPU" where YOUR_CPU is NEHALEM, HASWELL or 
whatever is appropriate for you CPU. See also 
https://github.com/xianyi/OpenBLAS/issues/983

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] error building sage

[Maarten Derickx]

Also did you install all the prerequisites for building sage in your system? 
The webpage 

http://doc.sagemath.org/html/en/installation/source.html

Shows more detailed instructions how to build sage

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] error building sage

[Maarten Derickx]

Could you give a detailed explanation of the machine you tried to build it on. 
Including at least your operating system and version and type of prosecor?

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] stop feeding the troll!

[Maarten Derickx]

Ok, most errors have been adressed. They turned out to be mostly due to 
some optional packages having dependencies outside of sage, but not 
complaining about these at installation time, but only during runtime.

On Friday, 15 September 2017 22:50:02 UTC+2, Maarten Derickx wrote:
>
> The packages needing packages external to sage to be installed raise the 
> question wether optional packages are allowed to have dependencies other 
> then sage. To me it feels a bit weird if you first need to install 
> something outside of sage before you can install the package, however this 
> seems like a minor issue related to the patchbot failures.
>
> On Friday, 15 September 2017 22:01:40 UTC+2, Maarten Derickx wrote:
>>
>> In my ongoing quest of trying to get fewer patchbot failures I started at 
>> least with installing all optional packages. I now have every optional 
>> package returned by::
>>
>>sage: optional_packages()
>>
>> except the following:
>>
>> gmp - this package installs fine but one has to choose between mpir 
>> and gmp
>> igraph -this needs libxml2 could by solved by apt get libxml2-dev
>> python_igraph - you wouldn't guess, but this depends on igraph
>> libtheora - a known problem #23732
>> mpfrcx - added so recently (#11806) that the tar is not on the mirror 
>> network yet
>>
>> Sage builds fine after this but the documentation suddenly does not build 
>> anymore because it misses Graphviz. The total memory used by this install 
>> is 15 GB (7 GB more then the 8.3 GB it had before installing the optional 
>> packages). 
>>
>> The doctest don't pass anymore, to be precise there are 48 failures, 
>> there were 3 that I saw before and I know the trac tickets of. The other 45 
>> can be found at https://trac.sagemath.org/ticket/23871 if any of the 
>> files affected look familiar and you know an open ticket for it please let 
>> me know. I am now working on sorting out the 45 failures at #23871 .
>>
>>
>>
>>
>> On Friday, 15 September 2017 10:31:58 UTC+2, vdelecroix wrote:
>>>
>>> In case you did not notice, you are just preventing an important 
>>> discussion concerning the management of optional packages to happen... 
>>>
>>> On 15/09/2017 10:28, Jeroen Demeyer wrote: 
>>> > On 2017-09-15 09:00, Jori Mäntysalo wrote: 
>>> >> If so, a 
>>> >> bug in Sage could -- at least in theory -- lead a compromise to the 
>>> >> server. 
>>> > 
>>> > It's a *feature* of Sage (actually Python) that it can run arbitrary 
>>> > code, not a bug. 
>>> > 
>>>
>>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] stop feeding the troll!

[Maarten Derickx]

The packages needing packages external to sage to be installed raise the 
question wether optional packages are allowed to have dependencies other 
then sage. To me it feels a bit weird if you first need to install 
something outside of sage before you can install the package, however this 
seems like a minor issue related to the patchbot failures.

On Friday, 15 September 2017 22:01:40 UTC+2, Maarten Derickx wrote:
>
> In my ongoing quest of trying to get fewer patchbot failures I started at 
> least with installing all optional packages. I now have every optional 
> package returned by::
>
>sage: optional_packages()
>
> except the following:
>
> gmp - this package installs fine but one has to choose between mpir 
> and gmp
> igraph -this needs libxml2 could by solved by apt get libxml2-dev
> python_igraph - you wouldn't guess, but this depends on igraph
> libtheora - a known problem #23732
> mpfrcx - added so recently (#11806) that the tar is not on the mirror 
> network yet
>
> Sage builds fine after this but the documentation suddenly does not build 
> anymore because it misses Graphviz. The total memory used by this install 
> is 15 GB (7 GB more then the 8.3 GB it had before installing the optional 
> packages). 
>
> The doctest don't pass anymore, to be precise there are 48 failures, there 
> were 3 that I saw before and I know the trac tickets of. The other 45 can 
> be found at https://trac.sagemath.org/ticket/23871 if any of the files 
> affected look familiar and you know an open ticket for it please let me 
> know. I am now working on sorting out the 45 failures at #23871 .
>
>
>
>
> On Friday, 15 September 2017 10:31:58 UTC+2, vdelecroix wrote:
>>
>> In case you did not notice, you are just preventing an important 
>> discussion concerning the management of optional packages to happen... 
>>
>> On 15/09/2017 10:28, Jeroen Demeyer wrote: 
>> > On 2017-09-15 09:00, Jori Mäntysalo wrote: 
>> >> If so, a 
>> >> bug in Sage could -- at least in theory -- lead a compromise to the 
>> >> server. 
>> > 
>> > It's a *feature* of Sage (actually Python) that it can run arbitrary 
>> > code, not a bug. 
>> > 
>>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Patchbot failures metaticket

[Maarten Derickx]

On Tuesday, 12 September 2017 18:43:00 UTC+2, vdelecroix wrote:
>
> Hi Marteen, 
>
> Though in an ideal world 
>   - tickets should not be merged if any patchbot is not happy with it 
>

Hi looked a bit more into this stuff and I think that the main reason why 
this happens is that even though we have a lot of patchbots with a lot of 
optional packages, we do not have a buildbot with optional packages. So I 
think that a lot of the current problems can be significantly reduced if we 
manage to setup a buildbot that runs all tests with all optional packages 
installed.

But I think a strict requirement for a buildbot to be added is that is 
should pass all tests, so as an intermediate step we should setup one using 
all currently working optional packages. I'm now doing my best to generate 
a large list of packages passing al doctest.
 

>   - patchbot should also be identified with its set of optional packages 
> installed (for now the server does not make any distinction) 
>   - patchbot should test tickets upgrading an optional package 
>
> Best 
> Vincent 
>
>
 

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] stop feeding the troll!

[Maarten Derickx]

In my ongoing quest of trying to get fewer patchbot failures I started at 
least with installing all optional packages. I now have every optional 
package returned by::

   sage: optional_packages()

except the following:

gmp - this package installs fine but one has to choose between mpir and 
gmp
igraph -this needs libxml2 could by solved by apt get libxml2-dev
python_igraph - you wouldn't guess, but this depends on igraph
libtheora - a known problem #23732
mpfrcx - added so recently (#11806) that the tar is not on the mirror 
network yet

Sage builds fine after this but the documentation suddenly does not build 
anymore because it misses Graphviz. The total memory used by this install 
is 15 GB (7 GB more then the 8.3 GB it had before installing the optional 
packages). 

The doctest don't pass anymore, to be precise there are 48 failures, there 
were 3 that I saw before and I know the trac tickets of. The other 45 can 
be found at https://trac.sagemath.org/ticket/23871 if any of the files 
affected look familiar and you know an open ticket for it please let me 
know. I am now working on sorting out the 45 failures at #23871 .




On Friday, 15 September 2017 10:31:58 UTC+2, vdelecroix wrote:
>
> In case you did not notice, you are just preventing an important 
> discussion concerning the management of optional packages to happen... 
>
> On 15/09/2017 10:28, Jeroen Demeyer wrote: 
> > On 2017-09-15 09:00, Jori Mäntysalo wrote: 
> >> If so, a 
> >> bug in Sage could -- at least in theory -- lead a compromise to the 
> >> server. 
> > 
> > It's a *feature* of Sage (actually Python) that it can run arbitrary 
> > code, not a bug. 
> > 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: yet another sage-python performance puzzle

[Maarten Derickx]

Is it assymptotically 10% or is it 10% for the case in which you are 
testing it? In the first case I would be surprised in the second case it is 
not that weird.

See the late_import function in src/sage/rings/complex_field.py for how you 
can speed up the import statement for the cyclic import case.

On Friday, 15 September 2017 20:31:51 UTC+2, Martin R wrote:
>
> I am now trying to speed up Permutation.to_matrix, which is meanwhile one 
> of the worst offenders in my application.  After some profiling I found the 
> following, which is quite a mystery to me. Apparently it is possible that 
> importing a module in a method costs a significant amount of time!
>
> QUESTION: is this an oversight or is there a good reason to import modules 
> in a relatively fundamental method like MatrixSpace.matrix?
>
> (I checked, moving out the first import makes the whole thing 
> (Permutation.to_matrix()) 10% faster.  I'm not saying that this is huge, 
> but it seems like a significant improvement to me.  Unfortunately, the 
> second module cannot be easily moved out, because of an import loop)
>
> This is #23870
>
> Martin
>
> sage: l = [pi for pi in Permutations(8)]
> sage: %lprun -f Permutation.to_matrix -f MatrixSpace.matrix 
> [pi.to_matrix() for pi in l]
> Timer unit: 1e-06 s
>
> Total time: 41.8048 s
> File: 
> /home/martin/sage-develop/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py
> Function: matrix at line 1354
>
> Line #  Hits Time  Per Hit   % Time  Line Contents
> ==
>   1354   def matrix(self, x=0, 
> coerce=True, copy=True):
>   ...
>   1493362880  2800013  7.7  6.7  if x is None or 
> isinstance(x, (int, integer.Integer)) and x == 0:
>   1494   if 
> self._copy_zero: # faster to copy than to create a new one.
>   1495   return 
> self.zero_matrix().__copy__()
>   1496   else:
>   1497   return 
> self.__matrix_class(self, None, False, False)
>   1498362880  2344112  6.5  5.6  if isinstance(x, 
> (int, integer.Integer)) and x == 1:
>   1499   return 
> self.identity_matrix().__copy__()
>   1500362880  1577558  4.3  3.8  m, n, sparse = 
> self.__nrows, self.__ncols, self.__is_sparse
>   1501362880  1462412  4.0  3.5  if 
> matrix.is_Matrix(x):
>   1502   if x.parent() 
> is self:
>   1503   if 
> x.is_immutable():
>   1504   
> return x
>   1505   else:
>   1506   
> return x.__copy__()
>   1507   else:
>   1508   if 
> x.nrows() == m and x.ncols() == n:
>   1509   if 
> (x.base_ring() == self.base_ring()
>   1510   
> and x.is_sparse() and not sparse):
>   1511   # 
> If x is sparse and large, calling x.dense_matrix()
>   1512   # 
> is much faster than calling x.list(). See #20470.
>   1513   
> return x.dense_matrix()
>   1514   x = 
> x.list()
>   1515   else:
>   1516   raise 
> ValueError("a matrix from %s cannot be converted to "
>   1517 
>"a matrix in %s!" % (x.parent(), self))
>   1518362880  5492940 15.1 13.1  from 
> sage.groups.matrix_gps.group_element import \
>   1519   
> is_MatrixGroupElement
>   1520362880  4978054 13.7 11.9  from 
> sage.modular.arithgroup.arithgroup_element import \
>   1521   
> ArithmeticSubgroupElement
>   1522362880  2613184  7.2  6.3  if 
> is_MatrixGroupElement(x) or isinstance(x, ArithmeticSubgroupElement):
>   1523   return 
> self(x.matrix(), copy=False)
>   1524362880  2036306  5.6  4.9   

[sage-devel] Re: Updating supported platform webpage to mach the current buildbots

[Maarten Derickx]

On Friday, 15 September 2017 18:55:57 UTC+2, Volker Braun wrote:
>
>
> I haven't used it in a while as buildbot, it possibly still has the old 
> domain name configured. But it basically never succeded in building; 32-bit 
> is just too small to build docs and 2+ patchbots in the background. 
>
> I just restarted sagebd09_32s02
>

Hi Volker,

Thanks for the reply, does you not saying anything about the following 
machines

   dehaye 
   mod 
   moufang-1 
   redhawk

mean that you do not intend to use them, or does this mean that the status 
of these bots depends on the answers of their owners? 

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Intrested in working with u guys!!!

[Maarten Derickx]

Hi Shivam,

Thanks for your interest. The first place to start is to clone sage using 
git and trying to build sage from source as described in the developer 
manual:

http://doc.sagemath.org/html/en/developer/walk_through.html

The second step is to find an open ticket on the trac server of sage 
at https://trac.sagemath.org/ that interest you and think you can solve, a 
good place to start looking is among the beginner tickets 
https://trac.sagemath.org/report/38 , if you try 
https://trac.sagemath.org/ticket/23614 then I will actively help you get 
that ticket fixed.

Also any description of your mathematical background would help pointing 
you to interesting places.



On Friday, 15 September 2017 14:53:08 UTC+2, shivam gor wrote:
>
> Hello, I am Shivam .I'm intrested in working with u and want to contribute 
> to open source
> I'm well with C++ and little bit familiar with python
> so where should I start from??
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Updating supported platform webpage to mach the current buildbots

[Maarten Derickx]

Hi Fellow sage devs,

Since the page https://wiki.sagemath.org/SupportedPlatforms is horribly 
outdated I want to at least update the section on fully supported 
platforms. What I plan to do is to update the list with the bots as listed 
on http://build.sagemath.org/#/workers . The changes for Debian, Ubuntu and 
OS X mostly are updating the versions of these systems. For the other 
changes there are a few things I want to ask you however before I make 
these changes:

Currently http://build.sagemath.org/#/workers seems to not list any 
buildbot running on any version of OpenSuse or Solaris on SPARC is it ok if 
their status is changed to expexted to work instead of fully supported? It 
seems like this is already de facto the case, so it seems better that we 
also write it in this way.

Currently the buildbot workers are offline:

dehaye
dima-arando 
mod 
moufang-1 
oxford-arm 
redhawk 
sagebd09_32s02

is this permanent or are they expected to come online again somewhere in 
the future? If they will come online before the release of 8.1 what version 
of which OS will they be running?

Please try to keep this thread focussed on the subjects which platforms we 
support. If the messages here bring up other questions please open a 
separate thread in order to discuss them.

Thanks,
Maarten

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Security in sage (was How much do we support optional packages)

[Maarten Derickx]

Hi Everybody who wants to discuss security in sage:

Please do so in this thread and not in "How much do we support optional 
packages".  So that these two discussions can both be held and without 
cluttering each other.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: sage-python puzzle

[Maarten Derickx]

By the way, if you are doing a lot of optimisation you should consider using 
gprof2dot https://github.com/jrfonseca/gprof2dot . It can turn your python 
profiling data into a really useful grafical visualisation of the call graph, 
instantly showing you which parts of the code to optimize. And I imagine in 
your case also showing you where the differences come from. 

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] How much do we support optional packages.

[Maarten Derickx]

Hi Jeroen and Vincent,

Thanks for your concrete answers to my questions.

If people want to keep discussing security issues of sage feel free to do 
so but please do it in a different thread.  I would like this thread to 
focus on my initial question and not get cluttered by related discussions.

On Thursday, 14 September 2017 18:51:59 UTC+2, vdelecroix wrote:
>
> On 13/09/2017 15:28, Maarten Derickx wrote: 
> > So the main questions: do we consider an optional package not building, 
> not 
> > passing it's own testsuite or causing sage to have doctest failures a 
> bug? 
>
> I do. And as well for me it is the frontier between optional and 
> experimental packages. 
>
> > In the other thread it was mentioned that patchbot failures should be 
> > considered blocker status defects (at least if the failures is not due 
> to a 
> > buggy patchbot/patchbot on an unsupported platform). Does this also hold 
> > for optional packages? 
>
> It does for me. 
>
> Vincent 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: How much do we support optional packages.

[Maarten Derickx]

And related to this, how much do we support pip packages. With this I don't 
mean any random pip package that happens to be on pypi, but just the ones 
that are returned by:

sage -optional 

that happen to be pip packages. At the moment:


['beautifulsoup',

 'biopython',

 'brian',

 'guppy',

 'mercurial',

 'mpi4py',

 'nibabel',

 'pybtex',

 'pyflakes',

 'pyopenssl',

 'sqlalchemy',

 'trac']

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] How much do we support optional packages.

[Maarten Derickx]

Hi Dear fellow sage-developers,

The question in the subject is related to the discussion in the Patchbot 
failures metaticket 

 thread. 

I remember that I read (somewhere a long time ago so my memory might be 
off) that optional packages where expected to always build and not cause 
any doctest failures and pas their own testsuite, because optional packages 
were considered to have the same amount of support as sage itself, the main 
reason that they are not installed by default is just because not everybody 
needs them and installing by default makes the sage install even bigger 
then it already is. However I seem to not be able to find this statement 
anymore in either one of the places [1][2] where I would expect it. The 
fact this level of support does not hold for experimental packages is made 
very clear at [3].

So the main questions: do we consider an optional package not building, not 
passing it's own testsuite or causing sage to have doctest failures a bug?
In the other thread it was mentioned that patchbot failures should be 
considered blocker status defects (at least if the failures is not due to a 
buggy patchbot/patchbot on an unsupported platform). Does this also hold 
for optional packages?

[1] http://files.sagemath.org/spkg/optional/
[2] https://wiki.sagemath.org/spkg
[3] http://files.sagemath.org/spkg/experimental/


-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Patchbot failures metaticket

[Maarten Derickx]

Hi Vincent,

Thanks for pointing out the point of view from a patchbot maintainer, my 
statement "I think a complete burden is highly exaggerated" was made from 
my perspective as a developer not knowing how this looks from a patchbot 
maintainer point of view. And I can see that having to deal with this every 
release instead of just when you are taking time to write or review tickets 
can be a complete burden. I think we should try to find a solution that 
makes both developers and patchbot mainainers happy. Any solution that 
would make people who volunteer to run a patchbot stop doing so because it 
creates a to high burden is clearly no solution.

On Tuesday, 12 September 2017 18:43:00 UTC+2, vdelecroix wrote:
>
> Hi Marteen, 
>
> "complete burden" = "each release". So precisely, we need somebody to 
> volunteer to maintain this list. I already hardly find the energy to 
> fill a ticket for the reasons why my patchbot is not working any more at 
> each new release (including the fact that I need to search for a 
> reason). In case I know the problem, I just send an e-mail on 
> sage-release and in case I find the answer (or somebody finds it) I 
> disable explicitely the package on my patchbot. Here is the list of 11 
> broken optional packages on quasar 
>
> # deformation: 
> https://groups.google.com/forum/#!topic/sage-devel/gEFC-ZwtAGU 
> # normaliz: https://trac.sagemath.org/ticket/23586 
> # giac: https://groups.google.com/forum/#!topic/sage-devel/QMfm3NOBZaI 
> # polytopes_db: 
> https://groups.google.com/forum/#!topic/sage-devel/KI0qtg1kYoA 
> # cbc: https://trac.sagemath.org/ticket/22006 
> # gap_packages, database_gap: https://trac.sagemath.org/ticket/22576 
> # qepcad: https://trac.sagemath.org/ticket/22851 
> # database_cremona_ellcurve: https://trac.sagemath.org/ticket/23840 
> # libtheora?? 
> # sip: https://groups.google.com/forum/#!topic/sage-devel/Jc-5u9YslkI 
> # openblas is not used anywhere 
>
> Though in an ideal world 
>   - tickets should not be merged if any patchbot is not happy with it 
>   - patchbot should also be identified with its set of optional packages 
> installed (for now the server does not make any distinction) 
>   - patchbot should test tickets upgrading an optional package 
>
> Best 
> Vincent 
>
> PS: thank you for willing to work on this. People do not seem to care so 
> much about failing doctests due to installation of optional packages. 
>
> On 12/09/2017 18:28, Maarten Derickx wrote: 
> > Hi Vincent, 
> > 
> > I think "a complete burden" is highly exaggerated, there should not be a 
> > new patchbot ticket to often. And if someone has to create a ticket then 
> > just copy pasting the failing files and the ticket number to the ticket 
> > description should not be to much work. 
> > 
> > As for removing old stuff I am totally happy to volunteer as a 
> maintainer 
> > of the ticket so that failures for old beta's and other releases are 
> > removed from time to time. 
> > 
> > The ticket also has some benefits, namely you see a nice overview of all 
> > the files affected, so this will make checking wether the files for 
> which 
> > you currently have a patchbot failing way faster then clicking on all 
> the 
> > results of a trac query. 
> > 
> > As a summary your solution would make writing new tickets easier, and 
> the 
> > current solution makes checking wether a ticket exists easier. Since the 
> > latter will happen way more often I think the benefits outweigh the 
> costs. 
> > 
> > On Tuesday, 12 September 2017 15:34:11 UTC+2, vdelecroix wrote: 
> >> 
> >> Hi, 
> >> 
> >> I think a meta-ticket is a complete burden to maintain. And as already 
> >> said in other mails, this identification should be done by other means. 
> >> 
> >> Vincent 
> >> 
> >> On 11/09/2017 18:59, Maarten Derickx wrote: 
> >>> Hi all, 
> >>> 
> >>> During the recent writing of new code and reviewing I got annoyed that 
> >> it 
> >>> costs really a lot of effort for me to see if there was already a 
> ticket 
> >>> for a certain patchbot failure. I therefore decided to create a 
> >> metaticket 
> >>> that should serve as an overview of all currently known patchbot 
> >> failures. 
> >>> It can be found here: 
> >>> 
> >>> https://trac.sagemath.org/ticket/23832 
> >>> 
> >>> I think that all patchbot failure tickets should automatically deserve 
> >> the 
> >>> status critical. Since patchbot failures make sage develo

Re: [sage-devel] Trouble while compiling sage---- compiling ends during plot3d

[Maarten Derickx]

Are you sure? The command "make build" skips the building of the documentation. 
So you should not be able to get this error which happens during the building 
of documentation.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Patchbot failures metaticket

[Maarten Derickx]

Hi Vincent,

I think "a complete burden" is highly exaggerated, there should not be a 
new patchbot ticket to often. And if someone has to create a ticket then 
just copy pasting the failing files and the ticket number to the ticket 
description should not be to much work.

As for removing old stuff I am totally happy to volunteer as a maintainer 
of the ticket so that failures for old beta's and other releases are 
removed from time to time.

The ticket also has some benefits, namely you see a nice overview of all 
the files affected, so this will make checking wether the files for which 
you currently have a patchbot failing way faster then clicking on all the 
results of a trac query.

As a summary your solution would make writing new tickets easier, and the 
current solution makes checking wether a ticket exists easier. Since the 
latter will happen way more often I think the benefits outweigh the costs.

On Tuesday, 12 September 2017 15:34:11 UTC+2, vdelecroix wrote:
>
> Hi, 
>
> I think a meta-ticket is a complete burden to maintain. And as already 
> said in other mails, this identification should be done by other means. 
>
> Vincent 
>
> On 11/09/2017 18:59, Maarten Derickx wrote: 
> > Hi all, 
> > 
> > During the recent writing of new code and reviewing I got annoyed that 
> it 
> > costs really a lot of effort for me to see if there was already a ticket 
> > for a certain patchbot failure. I therefore decided to create a 
> metaticket 
> > that should serve as an overview of all currently known patchbot 
> failures. 
> > It can be found here: 
> > 
> > https://trac.sagemath.org/ticket/23832 
> > 
> > I think that all patchbot failure tickets should automatically deserve 
> the 
> > status critical. Since patchbot failures make sage development and 
> > reviewing way more troublesome. Are there any other people with an 
> opinion 
> > on this? 
> > 
> > Thanks, 
> > Maarten 
> > 
> > p.s. Tips on how to search for tickets on trac are welcome! 
> > 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sagemath-admins] git trac connection problems from continental Europe

[Maarten Derickx]

P.s. in case this helps others from making the same mistake as me: don't 
click the branch link on https://github.com/dimpase/sagetrac-mirror/ in 
order to see if all branches are there unless you have a decent system with 
some ram to spare.

On Tuesday, 12 September 2017 14:18:46 UTC+2, Dima Pasechnik wrote:
>
> PS. it's set up using --mirror option of git clone and git push, so 
> it should actually be suitable for running anything (bots too) that 
> only needs read access to the repo. 
>
> In detail, on my desktop I did 
>
> git clone --bare g...@trac.sagemath.org:sage.git 
> cd sage.git/ 
> git push --mirror g...@github.com:dimpase/sagetrac-mirror.git 
>
> to create a github mirror. 
> I understand that to update the mirror locally (on my desktop) 
> I merely need to run 
>
> git remote update 
>
> I am not sure ATM how to push these updates on github, but 
> it must be doable I guess... 
>
>
>
> On Tue, Sep 12, 2017 at 1:10 PM, Dima Pasechnik  > wrote: 
> > It is a snapshot, not constantly updated. 
> > But it does contain all the branches present in the original repo. 
> > 
> > We can look into setting up a constant updating, it 
> > should not be too hard, and would take off load from trac, too. 
> > 
> > Dima 
> > 
> > 
> > On Tue, Sep 12, 2017 at 12:54 PM, Clemens Heuberger 
> >  wrote: 
> >> Am 2017-09-12 um 13:26 schrieb Dima Pasechnik: 
> >>> I've created a trac mirror repo on github: 
> >>> https://github.com/dimpase/sagetrac-mirror 
> >>> Please pull from there, if you have problems with trac's git. 
> >> 
> >> do I understand correctly that this is a snapshot (as indicated on that 
> page: 
> >> 2017-09-12 12:15 UK time), so this is not suitable for running 
> patchbots? 
> >> 
> >> I tried accessing git://trac.sagemath.org/sage.git from two different 
> >> universities in Austria and one virtual server in Germany, no success. 
> >> 
> >> Regards, 
> >> 
> >> Clemens 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Patchbot failures metaticket

[Maarten Derickx]

Hi all,

During the recent writing of new code and reviewing I got annoyed that it 
costs really a lot of effort for me to see if there was already a ticket 
for a certain patchbot failure. I therefore decided to create a metaticket 
that should serve as an overview of all currently known patchbot failures. 
It can be found here:

https://trac.sagemath.org/ticket/23832

I think that all patchbot failure tickets should automatically deserve the 
status critical. Since patchbot failures make sage development and 
reviewing way more troublesome. Are there any other people with an opinion 
on this?

Thanks,
Maarten

p.s. Tips on how to search for tickets on trac are welcome!

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Sage packaging template

[Maarten Derickx]

On Mon, 11 Sep 2017 at 10:30 Jean-Pierre Flori  wrote:

>
> I've made a pull request at
> https://github.com/mmasdeu/sage_package_template/pull/3 with some changes
> and info to skip some of the requirements when using it.
>

I don't have write acces to that repository so I can't accept your pull
request. But Marc Masdue (in the CC) does.
I guess it would be a good idea to put Marc his cookie cutter in the
Sagemath github repo under https://github.com/sagemath so it can be turned
into a more collaborative development experience.


I know the sage_package_template cookie cutter was made based on
sage_sample. It might be a good idea to think about how these can be
developed in parallel.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Fwd: Sage packaging template

[Maarten Derickx]

On Mon, 11 Sep 2017 at 10:30 Jean-Pierre Flori  wrote:

>
> I've made a pull request at
> https://github.com/mmasdeu/sage_package_template/pull/3 with some changes
> and info to skip some of the requirements when using it.
>

I don't have write acces to that repository so I can't accept your pull
request. But Marc Masdue (in the CC) does.
I guess it would be a good idea to put Marc his cookie cutter in the
Sagemath github repo under https://github.com/sagemath so it can be turned
into a more collaborative development experience.


I know the cookie_cutter was made base

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Sage sample / sage packaging template

[Maarten Derickx]

Changed the subject to not clutter Davids thread.



On Sunday, 10 September 2017 12:01:51 UTC+2, Jeroen Demeyer wrote:
>
> On 2017-09-10 06:09, Maarten Derickx wrote: 
> > I plan to work on https://github.com/sagemath/sage_sample quite a bit. 
> For which I hope that it falls under sage packaging ;) 
>
> I think we have 2 or 3 such projects in the mean time. Maybe we should 
> take the best ideas from each. 
>

I actually only know the one I linked to, do you have links to other ones?

p.s. there are two related projects which serve distinct purposes:

1) https://github.com/sagemath/sage-package a utilities/tools python 
package which is meant to be used in sage_sample and other external sage 
python packages.

2) https://github.com/mmasdeu/sage_package_template this is a cookie cutter 
template based on sage_sample .
 

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Online Sage Days

[Maarten Derickx]

Great idea, I especially like:

* python 3
* sage infrastructure
* sage packaging

I plan to work on https://github.com/sagemath/sage_sample quite a bit. For 
which I hope that it falls under sage packaging ;)

For python 3 it would be good to make some more documentation on how to get on 
the python 3 bandwagon, in order to get more momentum. I know that there are 
the meta tickets:

https://trac.sagemath.org/ticket/15530
https://trac.sagemath.org/ticket/15980
https://trac.sagemath.org/ticket/16052

However the only thing on how to get started mentioned there is::

How to try to make sage with python3:

export SAGE_PYTHON3=yes
make build

However these say nothing on how far we are on getting the commands ``sage`` 
and ``sage -t`` working. From reading the mailing list I have got the 
impression that some people already have these things working (albeit with 
significant failures), but the instruction above doesn't cut it for me.

Also might it be good idea to put a py3 develop branch somewhere that contains 
the latest beta + all positive review py3 tickets?

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: SAGE_PATH and PYTHONPATH

[Maarten Derickx]

Hi Ralf, 

Yes but considering you are on sage-devel  I thought there might be a 
reasonable chance that you would run into this issue sooner or later 
(especially if you set pythonpath in your bashrc). I just wanted to shamelessly 
advertise that trac ticket to potentially interested people.


The core issues you talk about is tracked at the ticket already mentioned by 
Nils https://trac.sagemath.org/ticket/23614

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: doctests: non-sorted output

[Maarten Derickx]

Thanks for your input David. We discussed it on trac, and decided to leave the 
situation as is on python 2.7 because it is stable enough as is given the 
pynormaliz fix.

For python 3 we propese to fix the sorting in upstream ipython. Using str based 
sort only if the standard sorting raises an error because things are not 
comparable. This strategy would be like 2.2 both for doctests and for end user 
printing.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: SAGE_PATH and PYTHONPATH

[Maarten Derickx]

In case people start setting pythonpath after reading this thread: you will 
actually get some silly doctest failures if python path is set.


I have made a ticket for this which fixes these doctest: 
https://trac.sagemath.org/ticket/23613

It is a very Small change and it currently needs review. The patchbot shows 
some failing tests but these are known problems with glpk not caused by this 
change.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: 32bit machine needed

[Maarten Derickx]

An account on Arando would work, thanks i'll send a pm.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: doctests: non-sorted output

[Maarten Derickx]

Option 2.3 might be to make solution 2.1 optional and dependent on the 
presence of something like  # unorderedset in the doctest. I actually like 
this the best since it allows us to use it only in the cases where it is 
really needed. So we can have the advantages of 2.1 and 2.2 depending on 
the situation!

On Tuesday, 29 August 2017 17:44:10 UTC+2, Maarten Derickx wrote:
>
> The output of both dict and set are ordered by a display hook from 
> IPython, the problem is that this sorting is done on the basis of __cmp__ 
> and the default way of sorting using __cmp__ is using the id of an object 
> which is not deterministic, so even though the output is sorted it is done 
> on a nondeterministic basis for objects which have this nondeterministic 
> __cmp__.
>
> I see basically 2 options going forward:
>
> 1. Just fix the doctests of pynormaliz themselves by making them 
> deterministic. 
>
> 2. Make the doctesting of sets more robust by ordering the output basted 
> on the string representation instead of __cmp__ . This has two ways of 
> doing it.
> 2.1 Only change the order of the output in the doctesting framework
> 2.2 Change it both in the doctesting framework and the user interface
>
> At https://trac.sagemath.org/ticket/23586 there is a partial solution 
> using 2, I stopped working on this because I want feedback on wether we 
> should do 2.1 or 2.2. But the progress on this ticket is slow.
>
> So I propose doing the quick fix 1 independently of 2, because this will 
> remove a lot of false negatives of the patchbot on other tickets helping 
> greatly in the sage development.
>
> Do people have feedback on 2.1 vs 2.2? 
> Main advantage of 2.1, the user will get more meaningful output in the 
> case where __cmp__ is deterministic. For example with 2.2 the user will get 
> the following awkward output:
>
> sage: set(GF(11)) 
> {0, 1, 10, 2, 3, 4, 5, 6, 7, 8, 9}
>
> The main advantage of 2.2 is that the doctest and the actual output of 
> sage are guaranteed to agree and that the code paths for doctesting and 
> actual output are more similar.
>
> My personal preference is for 2.1 since sets are inherently unordered, but 
> I am open for feedback.
>
> On Friday, 18 August 2017 09:14:55 UTC+2, Daniel Krenn wrote:
>>
>> A patchbot reported two failing doctests because the result is a set and 
>> the elements were in a different order, see 
>>   https://trac.sagemath.org/ticket/23637 
>> <https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F23637=D=1=AFQjCNHgNMW5ruZQKIa174ovsDnStqPcDA>
>>  
>> I somehow remember that such an issue was discussed here and I thought 
>> it was about the output of dict and set being sorted by a display hook. 
>> Am I wrong and this is not done or even not possible? 
>>
>> Best 
>>
>> Daniel 
>>
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: doctests: non-sorted output

[Maarten Derickx]

The output of both dict and set are ordered by a display hook from IPython, 
the problem is that this sorting is done on the basis of __cmp__ and the 
default way of sorting using __cmp__ is using the id of an object which is 
not deterministic, so even though the output is sorted it is done on a 
nondeterministic basis for objects which have this nondeterministic __cmp__.

I see basically 2 options going forward:

1. Just fix the doctests of pynormaliz themselves by making them 
deterministic. 

2. Make the doctesting of sets more robust by ordering the output basted on 
the string representation instead of __cmp__ . This has two ways of doing 
it.
2.1 Only change the order of the output in the doctesting framework
2.2 Change it both in the doctesting framework and the user interface

At https://trac.sagemath.org/ticket/23586 there is a partial solution using 
2, I stopped working on this because I want feedback on wether we should do 
2.1 or 2.2. But the progress on this ticket is slow.

So I propose doing the quick fix 1 independently of 2, because this will 
remove a lot of false negatives of the patchbot on other tickets helping 
greatly in the sage development.

Do people have feedback on 2.1 vs 2.2? 
Main advantage of 2.1, the user will get more meaningful output in the case 
where __cmp__ is deterministic. For example with 2.2 the user will get the 
following awkward output:

sage: set(GF(11)) 
{0, 1, 10, 2, 3, 4, 5, 6, 7, 8, 9}

The main advantage of 2.2 is that the doctest and the actual output of sage 
are guaranteed to agree and that the code paths for doctesting and actual 
output are more similar.

My personal preference is for 2.1 since sets are inherently unordered, but 
I am open for feedback.

On Friday, 18 August 2017 09:14:55 UTC+2, Daniel Krenn wrote:
>
> A patchbot reported two failing doctests because the result is a set and 
> the elements were in a different order, see 
>   https://trac.sagemath.org/ticket/23637 
> 
>  
> I somehow remember that such an issue was discussed here and I thought 
> it was about the output of dict and set being sorted by a display hook. 
> Am I wrong and this is not done or even not possible? 
>
> Best 
>
> Daniel 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] 32bit machine needed

[Maarten Derickx]

Hi all,

At https://patchbot.sagemath.org/ticket/15341/ I changed the way hashing of 
congruence subgroups works in order to make it compatible with == .
However I don't know how to fix the doctests on 32bit machines, since I 
don't know what hashes will be returned on these machines. Is there someone 
who can help with this?

Thanks,
Maarten

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Patchbot raises error but status is still shown as pending.

[Maarten Derickx]

Hi,

At https://patchbot.sagemath.org/ticket/23610/ you can see that the 
patchbot status of two different patchbots is mentioned as pending in all 
the tests listed on that page. However if you look at one of the logs 

 you 
will see that an "SkipTicket("unsafe")" error is raised in both cases. So I 
have two questions:

1) Is this wanted behaviour of the patchbot?
2) Why is the ticket considered unsafe? Is it because the ticket modifies 
the doctesting framework? A more detailed error message would be useful.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Trac update

[Maarten Derickx]

Hi Andrew,

Thanks for upgrading.

Recently we received a request on the sage-trac-account to reset a 
forgotten password, and it seems that it is no longer possible to use the 
webpage: http://trac.sagemath.org/admin/accounts/users to change user 
account (there used to be an update button next to the add button which 
now disapeared.

Another thing that is broken is the reset password button for 
users: http://trac.sagemath.org/reset_password (this is why we need the 
admin page to reset passwords quite often in the first place) but this was 
already broken before the upgrade (see 
https://groups.google.com/forum/#!searchin/sage-trac-account/volker%7Csort:date/sage-trac-account/15Wk1fL2XBI/4eM2GZrMQZgJ
 
).



Le samedi 30 août 2014 04:38:35 UTC+2, R. Andrew Ohana a écrit :

 I'm about to update the trac server with some bug fixes + the initial 
 buildbot support I mentioned in 
 https://groups.google.com/forum/#!topic/sage-devel/zYpEM7W-7cQ, so trac 
 will not be reliable for the next little bit. I'll post back here when I'm 
 done.

 -- 
 Andrew
  

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Heartbleed

[Maarten Derickx]

Sorry for the instability on the trac server the last few minutes, but at 
least it should not be vulnerable anymore.

Le mercredi 9 avril 2014 05:06:28 UTC+2, kcrisman a écrit :


 http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-revealed-728166/

 Apparently this is a real vulnerability in OpenSSL.  So... just fyi.  What 
 version does sagenb, cloud, sage cell use?

 (Also, sagemath.org seems to currently be down?)

 - kcrisman


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] nslookup failing for www.sagemath.org

[Maarten Derickx]

Hi,

I can no longer reach www.sagemath.org . A little digging showed that
it is because nslookup cannot retrieve the ip adress anymore. I looked
whether it was an issue with my local dns setup but some online
service like http://ping.eu/nslookup/ also gives the same error:

$ nslookup www.sagemath.org

Server: 192.168.1.1

Address: 192.168.1.1#53


** server can't find www.sagemath.org: SERVFAIL

Just using my browser to go to http://128.208.160.197/ directly and
hence bypassing dns is working without problems.

Are there other with similar problems?

Thanks,
Maarten

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: nslookup failing for www.sagemath.org

[Maarten Derickx]

It is also back here :)

Le samedi 5 avril 2014 19:29:00 UTC+2, Volker Braun a écrit :

 seems to be back up


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Experimental https version of trac.sagemath.org

[Maarten Derickx]

Hi all,

This is to announce that I've configured apache on trac.sagemath.org to 
also serve a https version of trac. So you should now be able to go to 
https://trac.sagemath.org. It is still experimental in the sense that this 
is temporarily set up with a self signed certificate so your browser might 
show you a warning message. 

Once we have real certificates we will disable the http version of trac and 
fully switch to https, but for now you can choose which version to use. 
Both the http and the https version are configured to use the same wsgi 
backend so the content is exactly the same. The only difference is that the 
https version is encrypted. So if you don't like to send your password as 
plain text over the internet you can now chose to not do this anymore.

Enjoy,
Maarten

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: 404 on Sage Developer Conventions

[Maarten Derickx]

It is now at: http://www.sagemath.org/doc/developer/coding_basics.html

The name of the url changed, but if you look at the 
index http://www.sagemath.org/doc/developer/index.html you can still easily 
find it.

Le mercredi 25 décembre 2013 16:32:22 UTC+1, Darij Grinberg a écrit :

 Hi guys, 

 this site is now 404: 
 http://www.sagemath.org/doc/developer/conventions.html 
 Where has it moved? 

   Best regards, 
   Darij 


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Help in creating trac accounts.

[Maarten Derickx]

Dear All,

As most of you probably know, there is a mailinglist 
sage-trac-accounthttps://groups.google.com/forum/#!forum/sage-trac-account. 
The purpose for this mailinglist is to distribute the task of creating trac 
accounts among several sage devs, so that people needing a trac account wil 
receive one in a timely fashion. However the number of people actively 
creating accounts has dropped, causing potential new sage devs to get their 
trac accounts later then desired. So I'm now asking if there are people 
that would like to help by creating an account say once a week (takes about 
5 min).

The reason the creation process is manual is because the captcha of trac is 
not strong enough so our trac server will get spammed with useless messages 
about certain medicines if we made the process automatic as used to happen 
in the past.

If you are interested in helping out please send a message either to me or 
to the sage-trac-account mailinglist.

Thanks,
Maarten

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: We need a new color?

[Maarten Derickx]

Ok, it's I uploaded a patch at http://trac.sagemath.org/ticket/15246

Le lundi 30 septembre 2013 19:58:39 UTC+2, Benjamin Jones a écrit :

 I will give that a positive review :)

 --
 Benjamin Jones


 On Sun, Sep 29, 2013 at 11:26 PM, Maarten Derickx 
 m.derick...@gmail.comjavascript:
  wrote:

 Speaking of xkcd and easter eggs, I have always thought that since sage 
 already has an xgcd function, we should also have an xkcd function. I 
 already wrote a first version at: 
 https://sage.math.leidenuniv.nl/home/pub/22/

 Le vendredi 27 septembre 2013 18:03:00 UTC+2, kcrisman a écrit :



 On Friday, September 27, 2013 4:57:51 AM UTC+2, kcrisman wrote:

 From a user.  I'm not sure how the matplotlib devels would feel about 
 adding this.  


 I would assume they welcome a patch, especially when you quote xkcd.
 The definitions are here, i think:
 https://github.com/matplotlib/**matplotlib/blob/master/lib/**
 matplotlib/colors.py#L65https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/colors.py#L65


 I've submitted a pull request. https://github.com/**
 matplotlib/matplotlib/pull/**2468https://github.com/matplotlib/matplotlib/pull/2468

 See also 
 http://www.colourlovers.**com/palette/492360/Sagehttp://www.colourlovers.com/palette/492360/Sage

  -- 
 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+...@googlegroups.com javascript:.
 To post to this group, send email to sage-...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: We need a new color?

[Maarten Derickx]

Speaking of xkcd and easter eggs, I have always thought that since sage 
already has an xgcd function, we should also have an xkcd function. I 
already wrote a first version 
at: https://sage.math.leidenuniv.nl/home/pub/22/

Le vendredi 27 septembre 2013 18:03:00 UTC+2, kcrisman a écrit :



 On Friday, September 27, 2013 4:57:51 AM UTC+2, kcrisman wrote:

 From a user.  I'm not sure how the matplotlib devels would feel about 
 adding this.  


 I would assume they welcome a patch, especially when you quote xkcd.
 The definitions are here, i think:

 https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/colors.py#L65


 I've submitted a pull request. 
 https://github.com/matplotlib/matplotlib/pull/2468

 See also http://www.colourlovers.com/palette/492360/Sage


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Inverse of discrete functions

[Maarten Derickx]

I would definitely use such a construction.  It would be nice to have a 
data structure that behaves like 1:1 correspondence or as in your case 1 to 
many correspondances instead of needing to keep two dictionaries. It would 
make life a lot easier because you loose the need of a double 
administration. I.e. if you now want to remove 'c' from d in your example 
you would need to do:

v = d.pop('c')
d_inv[v].remove('c')

it would by much nicer (and less error prone) if one could just do:

del d['c']

Le mercredi 25 septembre 2013 18:08:12 UTC+2, Nathann Cohen a écrit :

 Hell everybody ! 

 I was just messing with dictionaries and lists, and I wonder if we 
 could solve the problem once and for all with an inefficient generic 
 solution. Here's the thing : 

 I often have to define both a function, and its inverse. Something like : 

 d = { 
  'a' : 1, 
  'b' : 2, 
  'c' : 1, 
  'd' : 3 
 } 

 Then, I want to find the list of all elements whose image is a 1, or 
 2, or 3, and end up defining the following dictionary : 

 d_inv = { 
  1 : ['a','c'], 
  2 : ['b'], 
  3 : ['d'] 
 } 

 Aand it would be sooo nice if there was a way to write d**(-1)[2], 
 or something of the kind ! Did you ever write a code like this, and 
 would you be interested by a generic tool for that ? 

 Otherwise I'll just keep on computing the inverse of my dictionaries 
 with a couple of Python lines ;-) 

 Have fn ! 

 Nathann 


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: parallel for loop with minimal forking

[Maarten Derickx]

This indeed seems like a good addition. I'm not aware yet of a place in 
sage where something like this is done.

I would chose a different name though, something like bundled_parallel, 
because naming this one unordered seems to indirectly imply that the other 
one is ordered, which it is absolutely not.

Le vendredi 21 juin 2013 14:28:14 UTC+2, Timo Kluck a écrit :

 Hi everyone,

 I just parallelized a for loop in a way that may be generally useful, and 
 I'm wondering whether I should write an addition to sage.parallel. It's 
 possible that this has been done already and in much better ways than my 
 own, so I'd be very happy to hear your opinions.

 I had a for loop of the form

   for i in iterator:
# do some stuff
# eventually result - f(i)
yield result

 for some long iterator and a short computation i - f(i).

 I tried to parallelize this using @parallel, but the result wasn't any 
 quicker:

   @parallel()
   def f(i):
   # do some stuff
   return result
   for res in f(iterator):
   yield res[1]

 My guess about the lack of speed-up is that every iteration introduces 
 pickling and forking overhead, which adds up to a lot, collectively.

 I tried to mitigate this overhead by not forking for every iteration, but 
 by starting a fork for every cpu and then having that fork loop over its 
 own slice of the iterator:

   @parallel('fork')
   def do_computation(start):
   result = []
   for args in itertools.islice(iterator, start, None, 
 number_of_chunks):
   result.append(function(args))
   return result

   results = do_computation(range(number_of_chunks))
   for res in results:
   for r in res[1]:
   yield r

 This resulted in the expected speedup (~3x for ncpus=4).

 I collected this functionality in a decorator @unordered_parallel that 
 lets you replace

   for i in iterator:
   yield f(i)

 by

   @unordered_parallel(iterator, number_of_chunks)
   def _(i):
   return f(i)
   for res in _: yield res
   
 (As a side note: I'm really happy with how the interface lets you 
 parallelize your
 for loop while hardly changing its body.)  

 Would there be any interest in an addition along these lines to the 
 sage.parallel module?

 Best, Timo



-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: The 2013 Spies Prize winner is...

[Maarten Derickx]

After all his hard and good work Jeroen definitely deservers this!

Gefeliciteerd Jeroen!

Le vendredi 28 juin 2013 12:47:31 UTC+2, Nicolas M. Thiéry a écrit :

 +lots on behalf of the Sage-Combinat community. It's been so helpful 
 to have someone super competent, timely, and rigorous like you! 

 Cheers, 
 Nicolas 
 -- 
 Nicolas M. Thi�ry Isil nth...@users.sf.net javascript: 
 http://Nicolas.Thiery.name/ 


-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: New Trac Server

[Maarten Derickx]

How are things progressing with the move?

Thanks Maarten

Le lundi 22 avril 2013 20:19:44 UTC+2, R. Andrew Ohana a écrit :

 Hey Everyone,

 Sometime in the next couple weeks, we will be moving our trac installation 
 over to a dedicated VM. You can currently access the instance at 
 trac.tangentspace.org -- although note that the database is a snapshot 
 from Sunday evening, so don't do any real development there, since it will 
 all be dropped. There are some (non-insignificant) changes, so please make 
 sure that everything you care about is still there and not broken.

 Changes from current trac.sagemath.org:

 1) update to Trac-1.1.2dev, because of
 2) a few new plugins to handle new git workflow (topic for another post)
 3) new configuration, written from a new clean initialization (our trac 
 configuration was full of a lot of cruft from years of upgrades, and 
 changes in how trac handles things)
 4) database has been stripped of a ridiculous amount of crap (about half 
 of the dump) -- side affect: the users admin panel has a reasonable load 
 time
 5) Sage color scheme has been updated/fleshed out to match the updated 
 trac theme

 -- 
 Andrew
  

-- 
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 to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Univariate quotient ring returning wrong results

[Maarten Derickx]

+1 It's better to raise an error then to fail silently. 

If it turns out that a lot of doctest break because of this change it is 
maybe good to instead create a method called reduce_unique, or add a 
keyword unique to reduce. Here reduce_unique should have the additional 
property that I.reduce_unique(f)==I.reduce_unique(g) if and only if f = g 
mod I.

Le samedi 26 janvier 2013 23:58:54 UTC+1, Volker Braun a écrit :

 A univariate polynomial ring over a field is a PID, but not if its over a 
 general ring. E.g. 2,x in ZZ[x] can't be generated by a single polynomial.



 On Saturday, January 26, 2013 10:45:18 PM UTC, Charles Bouillaguet wrote:

 If I am not mistaken, any ideal I = f_1, …, f_r of R[x] is spanned by 
  a **single** polynomial (which is the gcd of the f_i). So, in your 
 examples, the ideal spanned by x^2 and x^2+x+1 is in fact R[x], because 
 their gcd is one. 



-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] How to automatically download the newest sage?

[Maarten Derickx]

Dear all,

I want to create a script that when I run it automatically downloads the 
latest sage developement version. I was wondering what would be the best 
way to do so?

Thanks Maarten

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: Graph neighbours - room for huge performance boost

[Maarten Derickx]

I decided to do some profiling.  And there is something that worries my 
slightly more then the factor +/-10  difference in iteration speed that 
caused the start of this topici. Namely conversion from a sparse sage graph 
to a networkx graph seems to have quadratic runtime complexity instead of 
linear. As you can see below you see the timings of:

G = graphs.RandomBarabasiAlbert(2^i,2)
E = [(u,v) for u in G for v in G.neighbor_iterator(u)] #and
EE = [(u,v) for u in ggnx for v in ggnx.neighbors_iter(u)] 

seem to double each step as one would expect with linear complexity. 
However the time of 

ggnx = G.networkx_graph()

increases each step by a factor of about 4, indicating quadratic runtime 
complexity :S.

sage: for i in range(10,21):
: print i
: time G = graphs.RandomBarabasiAlbert(2^i,2)
: time E = [(u,v) for u in G for v in G.neighbor_iterator(u)]
: time ggnx = G.networkx_graph()
: time EE = [(u,v) for u in ggnx for v in ggnx.neighbors_iter(u)] 
: 
10
Time: CPU 0.05 s, Wall: 0.05 s
Time: CPU 0.02 s, Wall: 0.02 s
Time: CPU 0.03 s, Wall: 0.03 s
Time: CPU 0.00 s, Wall: 0.00 s
11
Time: CPU 0.09 s, Wall: 0.09 s
Time: CPU 0.03 s, Wall: 0.03 s
Time: CPU 0.07 s, Wall: 0.07 s
Time: CPU 0.01 s, Wall: 0.01 s
12
Time: CPU 0.19 s, Wall: 0.19 s
Time: CPU 0.07 s, Wall: 0.07 s
Time: CPU 0.20 s, Wall: 0.20 s
Time: CPU 0.01 s, Wall: 0.01 s
13
Time: CPU 0.40 s, Wall: 0.40 s
Time: CPU 0.13 s, Wall: 0.13 s
Time: CPU 0.66 s, Wall: 0.66 s
Time: CPU 0.02 s, Wall: 0.02 s
14
Time: CPU 0.92 s, Wall: 0.92 s
Time: CPU 0.27 s, Wall: 0.27 s
Time: CPU 2.45 s, Wall: 2.46 s
Time: CPU 0.04 s, Wall: 0.04 s
15
Time: CPU 1.86 s, Wall: 1.87 s
Time: CPU 0.55 s, Wall: 0.55 s
Time: CPU 8.85 s, Wall: 8.86 s
Time: CPU 0.08 s, Wall: 0.08 s
16
Time: CPU 3.96 s, Wall: 3.96 s
Time: CPU 1.10 s, Wall: 1.10 s
Time: CPU 33.85 s, Wall: 33.85 s
Time: CPU 0.16 s, Wall: 0.16 s
17
Time: CPU 8.29 s, Wall: 8.30 s
Time: CPU 2.21 s, Wall: 2.22 s
Time: CPU 139.72 s, Wall: 140.03 s
Time: CPU 0.35 s, Wall: 0.35 s
18
Time: CPU 18.02 s, Wall: 18.08 s
Time: CPU 4.46 s, Wall: 4.46 s
^C^C

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: Graph neighbours - room for huge performance boost

[Maarten Derickx]

As mentioned on the ticket it might be good to still post your broken 
patch. Not every patch needs to be perfect the first time. By posting your 
code it is easier for people to see exactly what is broken by your faster 
code (probably it is because there are some functions that directly modify 
the graph without using add_edge/delete_edge). It should really be a matter 
of looking at which doctests fail and fix the introduced bugs accordingly.

A pastebin (www.pastebin.com) containing the failing doctest might also be 
usefull.

Le mardi 1 janvier 2013 22:45:32 UTC+1, Jernej Azarija a écrit :

 Hello!

 By profiling Sage scripts involving graphs one can easily see that the 
 bottleneck is usually in computing the list of neighbours  
 (Graph.neighbours). This is somehow to be expected since most 
 graph-theoretical algorithms perform operations on neighbours of vertices. 

 Currently it appears that for each such query, the native graph backed 
 computes the list of neighbours from the list of edges. This can of course 
 be improved by storing a hash map for each vertex and updating its 
 neighbouring vertices on each addition/deletion of an edge and deletion of 
 a vertex. As is, it is often best to first convert the graph to a networkX 
 graph and perform the computation there. Example:

 ==

 sage: G = graphs.RandomBarabasiAlbert(100,2)
 sage: %timeit E = [(u,v) for u in G for v in G.neighbor_iterator(u)]
 125 loops, best of 3: 1.63 ms per loop
 sage: ggnx = G.networkx_graph()
 sage: %timeit EE = [(u,v) for u in ggnx for v in ggnx.neighbors_iter(u)] 
 625 loops, best of 3: 141 µs per loop

 ==

 I don't feel confident enough to simply patch the current graph backed 
 since it appears to be written in a very precise fashion and there are 
 parts of the specification and implementation that I do not understand 
 completely. That said if someone is willing to provide the necessary 
 information (on how and what needs be changed) or is willing to code it 
 himself, here is the relevant trac ticket: 
 http://trac.sagemath.org/sage_trac/ticket/13730

 Best,

 Jernej


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: why is email in sagenb?

[Maarten Derickx]

I've heard quite often now for several things that if something is needed 
in both sage and sagenb then we will need two copies. If there are really 
multiple cases, then maybe it is time to make a small python library called 
something like sage-utilities that contains all the functionality that is 
needed by both sage and sagenb. 

Le jeudi 13 décembre 2012 22:05:06 UTC+1, Keshav Kini a écrit :

 William Stein wst...@gmail.com javascript: writes: 

  Yes, unless it's needed by the notebook for some reason, in which case 
  we have to have two copies, since the notebook is supposed to not 
  depend on sage... 

 Note: Robin Martinjak recently submitted a pull request to sagenb 
 implementing email notifications for sagenb errors, which modifies 
 sagenb.notebook.sage_email : https://github.com/sagemath/sagenb/pull/120 

 -Keshav 



-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Sage doctesting on shared systems insecure (#13579)

[Maarten Derickx]

Maybe it can be fixed by using:

from __future__ import absolute_import

I at least know that python 3 fixed some issues caused by relative imports. 
But I'm not 100% sure if this problem is also solved.

Le mercredi 10 octobre 2012 14:14:22 UTC+2, Jeroen Demeyer a écrit :

 On 2012-10-10 13:59, John Cremona wrote: 
  Would it not be a good idea to disable testing this file (or the bad 
  part in it) until this has been fixed?  In all future testing  
  development releases? 
 The idea is *not* to do any further releases until this gets sorted out. 


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: Trac Server - Reset Password

[Maarten Derickx]

This should be posted to the sage-trac-account mailinglist, but I see you 
already did that.

Le jeudi 4 octobre 2012 01:06:00 UTC+2, Raniere Gaia Silva a écrit :


 Hi,
 sorry for post in this list if it is inappropriate.
 I try to reset my password by using 
 http://trac.sagemath.org/sage_trac/reset_password but the new password 
 that I got don't work.
 Can some one help me? My username is r.gaia.cs

 Thanks,
 Raniere


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: Modular forms membership testing bug

[Maarten Derickx]

The reason is that q_expansion_basis returns power series and not modular 
forms:

sage: M = ModularForms(Gamma0(17), 4)
sage: M.basis()[0].parent()
Modular Forms space of dimension 6 for Congruence Subgroup Gamma0(17) of 
weight 4 over Rational Field
sage: M.basis()[0] in M
True
sage: M.q_expansion_basis()[0].parent()
Power Series Ring in q over Rational Field

Le mercredi 3 octobre 2012 11:20:06 UTC+2, David Loeffler a écrit :

 I just hit this bug in the wild while doing some modular forms 
 computations:

 masiao@fermat:~$ sage
 --
 | Sage Version 5.3, Release Date: 2012-09-08 |
 | Type notebook() for the browser-based notebook interface.|
 | Type help() for help.|
 --
 sage: M = ModularForms(Gamma0(17), 4)
 sage: v = M.q_expansion_basis(prec=10)[0]
 sage: v in M
 False

 Oddly M(v) works if v corresponds to a q-expansion of a form in M, and 
 raises an error if it doesn't -- as it should do -- so there is something 
 going wrong in the code for __contains__. Does anyone know what might be 
 causing this?

 David


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: can't recover user password

[Maarten Derickx]

I have the feeling that it might be due to the new flask notebook that got 
merged in 5.2 (see http://trac.sagemath.org/sage_trac/ticket/11080) this 
changed a lot of login related things. 

Le mercredi 19 septembre 2012 13:29:02 UTC+2, mmarco a écrit :

 I have set up a sage server with several users. The forgot password 
 option worked all right, but after upgrading to sage 5.2, it doesn't 
 work anymore. 

 When i click on forgot password and enter a username, i get the 
 message username is invalid. But the username is accepted to login. 

 Any clues? 


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] 4 year phd position in computer algebra in Eindhoven

[Maarten Derickx]

Dear All,

There is a nice phd position available at the university of Eindhoven. It 
is aimed at someone interested in computer algebra, so I thought there 
might be people here who are interested in it. The position includes a 
decent salary. 

In this position you will among others:

-Assist staff in teaching undergraduate and graduate courses

-Depending on your background you will do research in one of the following 
directions.

   • Gröbner basis in infinitely many variables;
   • tensors of bounded rank;
   • matroids and incidence geometries;
   • modular Lie algebras; and/or
   • realizations of polytopes in real spaces.

For more info see the application web page: 
http://jobs.tue.nl/en/job/phd-student-in-computer-algebra-149428.html

Thanks Maarten

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: misc/functional.py : attribute error bug and patch (I think)

[Maarten Derickx]

Thanks for the report. This seems to be a bug indeed. Do you have a trac 
account and are you willing to upload a patch to trac.sagemath.org? 
Also can you tell us wheter this bug is reproducable and how you triggerd 
it? This will be usefull for writing a small test that ensures it will not 
get broken again in the future.

Le dimanche 26 août 2012 23:09:02 UTC+2, fero a écrit :

 Dear all, I have hit a bug:


 AttributeError at /do/2/
 'module' object has no attribute 'ideal'

 I fixed it by placing

 import sage.rings.ideal

 in

 /opt/sage-5.2/local/lib/python2.7/site-packages/sage/misc/functional.py

 A full backtrace as shown by Django error template, can be read at 
 http://pastebin.com/GTKEm8XQ


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: sagemath cluster

[Maarten Derickx]

  

 At the end of the 2 week camp the students really appreciated learning
 Sage and loved it (according to feedback).  One missing feature they
 would have loved is an integrated chat system, e.g., we did public key
 crypto and a chatroom would have been helpful -- we did end up using
 the sagemath irc room, but irc doesn't have good math support.



 I totally agree with the chat system, but IMHO for that to work you would 
 also need to setup user groups, something like Facebook has. What do you 
 think about that?
  


If you run into similar issues again maybe you could use http://mathim.com/ 
. It is a no login required web based latex enabled chat.  
The source code they wrote to implement that website is also 
available: https://github.com/tommycli/mathim .

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] bug in modular symbols code?

[Maarten Derickx]

I think I found the problem. 
Let M22=ModularSymbols(Gamma1(22)) and S22=M22.cuspidal_subspace()
and similarly let M2=ModularSymbols(Gamma1(2)) and M11=... etc

What goes wrong is that the code calculates the four degeneracy maps:
d1:M2 - M22
d2:M2 - M22
d3:M11 - M22
d4:M11 - M22

and then calculates the S22.oldspace() as:
S22.intersection(d1.image()+d2.image()+d3.image()+d4.image()) . 

I think that what goes wrong is that in the modular symbols world the 
degeneracy maps only really make sense on the level of cuspidal spaces. See 
Example 8.28 of [1] concerning the new and oldspaces on modular symbols 
(not just the cuspidal ones). Here it is stated: The new and old subspaces 
need not be disjoint!

What I think should be done to calculate the old subspace is the following:
d1.restrict(S2).image()+d2.restrict(S2).image()+d3.restrict(S11).image()+d4.restrict(S11).image()

What happens in this particular example is that some linear combination of 
non-cuspidal modular oldsymbols actually becomes a cuspidal modular symbol 
that happens to be new. If we just restrict to the cuspidal modular symbols 
case non of these strange things should arise. 

I hope that someone can confirm that my claim that everything will be ok 
when restricting to the cuspidal modular symbols is right.

Should we raise an error when trying to compute the oldspace on the space 
of all modular symbols ? Or does it have any applications?

Thanks Maarten

[1] William Stein. Modular Forms: A Computational Approach

Le mercredi 4 juillet 2012 12:50:24 UTC+2, David Loeffler a écrit :

  On 4 July 2012 03:05, Maarten Derickx m.derickx.stud...@gmail.com 
 wrote: 
  Dear All, 
  
  Today I was trying to compute some stuff using modular symbols. And I 
 found 
  the following slightly worrying: 

 Yup, this is definitely a bug. The old submodule it calculates isn't 
 Hecke-invariant: 

 sage: M.hecke_matrix(17).restrict(S.old_submodule().free_module()) 
 [...] 
 ArithmeticError: subspace is not invariant under matrix 

 Note that S.old_submodule().hecke_matrix() will return something, but 
 it'll be garbage, because it's restricting a matrix to a non-invariant 
 submodule with checks disabled. 

 Maarten, can you open a ticket for this? 

 David 


-- 
-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: homomorphisms between free modules over different rings

[Maarten Derickx]

This is now http://trac.sagemath.org/sage_trac/ticket/13321

Le samedi 7 juillet 2012 17:02:40 UTC+2, Maarten Derickx a écrit :

 And the following is even more worrying:

 sage: (GF(7)^2).hom([[20,0],[0,21]],ZZ^2)
 Free module morphism defined by the matrix
 [6 0]
 [0 0]
 Domain: Vector space of dimension 2 over Finite Field of size 7
 Codomain: Ambient free module of rank 2 over the principal ideal domain 
 Integer Ring



-- 
-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org