Re: [sage-devel] behavior of (multivariate) polynomial division

[Johan S . H . Rosenkilde]

Hi,

>   1- is it desirable for quo_remo and _floordiv_ to be equivalent for 
> all of R1, R2, R3 and R4?
>   2- what is the most reasonable behavior?

I wouldn't expect those rings to behave the same. Defining the
multivariate ring in steps indirectly gives a position-over-term
ordering in the quo_rem operations.

For instance, the following behaviour, currently in Sage, is exactly as
I would expect:

sage: A1 = QQ['a']['b']
sage: a = A1.base_ring().gen(); b = A1.gen()
sage: ( (a+1)*b ).quo_rem(a*b)

...
ArithmeticError: Division non exact (consider coercing to polynomials over the 
fraction field)

sage: ( (a+1)*b ).quo_rem(a)
...
ArithmeticError: Division non exact (consider coercing to polynomials over the 
fraction field)

sage: A2 = QQ['a','b']
sage: A2( (a+1) * b ).quo_rem(A2(a*b))
(1, b)
sage: A2( (a+1) * b ).quo_rem(A2(a))
(b, b)
sage: B1 = QQ('a')['b']
sage: B1( (a+1)*b ).quo_rem(B1(a*b))
((a+1)/a, 0)



>   3- Are there operations where it is desirable to go to R1 instead?

When you're really considering univariate polynomials in one variable
'c' over whatever ring:

sage: R1 = QQ['a']['b']['c']
sage: R4 = QQ['a','b','c']
sage: c = R1.gen()
sage: # Make a big element of R1
sage: R11 = R1.base_ring()
sage: R111 = R11.base_ring()
sage: p1 = R1([ R11([ R111.random_element(degree=50) for i in range(50) ]) for 
j in range(50) ])
sage: %timeit p1(c=1)
sage: 
sage: p4 = R4(str(p1))
sage: c4 = R4(c)
sage: %timeit p4(c=1)


Best,
Johan

-- 
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: Installing optional packages

[leif]

Andrew wrote:
> On Wednesday, 27 July 2016 18:13:44 UTC+10, leif wrote:
> 
> Andrew wrote:
> > I just installed an optional package but it took me a while to
> remember
> > how to do it. Of course, it is completely straightforward but I just
> > forgot
> 
> Ahem, './sage --help'?
> 
> Sure that's what I did when I didn't find it i the manual. The point is
> that it should ALSO be in the manual.

Sure.  I was just surprised you didn't try that first, but then you
wouldn't have noticed our documentation being incomplete. :-)

(Not sure whether the help messages are at all up-to-date; they're at
least still ugly or inconsistent regarding short and long options, and
old-style vs. new-style packages I think.)


-leif


-- 
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 notifications again

[leif]

leif wrote:
> It seems I'm again not getting any trac notifications since about 20:00
> UTC yesterday (July 24th).
> 
> (And no, I didn't change my preferences...)

Orthogonal to that, but also annoying is that we do no longer get
notifications when a ticket gets closed.

Is this a bug or a feature?


-leif


-- 
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: Installing optional packages

[Andrew]

On Wednesday, 27 July 2016 18:13:44 UTC+10, leif wrote:
>
> Andrew wrote: 
> > I just installed an optional package but it took me a while to remember 
> > how to do it. Of course, it is completely straightforward but I just 
> > forgot 
>
> Ahem, './sage --help'? 
>
> Sure that's what I did when I didn't find it i the manual. The point is 
that it should ALSO be in the manual.
 

> That points you to './sage --advanced' (advanced help) as well, which 
> gives 
>
> Installing packages and upgrading: 
>   -package [args] -- call the new package manager with given 
> arguments. 
>  Run without arguments for package-specific help. 
>   -experimental   -- list all experimental packages that can be 
> installed 
>   -f [opts] [packages]-- shortcut for -i -f: force build of the given Sage 
>  packages 
>   -i [opts] [packages]-- install the given Sage packages.  Options: 
>-c -- run the packages' test suites 
>-d -- only download, do not install packages 
>-f -- force build: install the packages even 
>  if they are already installed 
>-s -- do not delete the temporary build 
> directories 
>  after a successful build 
>   -p [opts] [packages]-- install the given Sage packages, without 
> dependency 
>  checking and with support for old-style spkgs. 
>  Options are -c, -d and -s with the same meaning 
> as 
>  for the -i command 
>   -info [packages]-- print the SPKG.txt of the given packages 
>   --location  -- if needed, fix paths to make Sage relocatable 
>   -optional   -- list all optional packages that can be installed 
>   -standard   -- list all standard packages that can be installed 
>   -installed  -- list all installed packages 
>   -upgrade [version]  -- download, build and install the given version. 
> Here, 
>  'version' is a git branch or tag name. Useful 
> values 
>  are 'master' (the current development version, 
> this 
>  is the default) or a version number like '5.13'. 
>   -pip [...]  -- invoke pip, the Python package manager 
>
>
> besides further usage help on other topics. 
>
>
> -leif 
>
>
>

-- 
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] behavior of (multivariate) polynomial division

[Vincent Delecroix]

Hello,

We have isomorphism between the following rings

R1 = QQ['a']['b']['c']
R2 = QQ['a','b']['c']
R3 = QQ['a']['b','c']
R4 = QQ['a','b','c']

However, sage treats them differently.

sage: R1('a').quo_rem(R1('b'))
Traceback (most recent call last):
...
ArithmeticError: Division non exact (consider coercing to polynomials 
over the fraction field)


versus

sage: R4('a').quo_rem(R4('b'))
(0, a)

In #21106 and #21108 we mostly fill the gap to make R3 behaves as R4. 
However:


 1- is it desirable for quo_remo and _floordiv_ to be equivalent for 
all of R1, R2, R3 and R4?

 2- what is the most reasonable behavior?

Moreover, given a ring method on one of these polynomial ring there is 
the choice of going to R1 or to R4 (assuming the method is available 
there). I guess that operations in R4 are faster (if available in 
Singular). I have the following baby example


sage: p1 = R1.random_element()
sage: p2 = R1.random_element()
sage: p = p1*p2
sage: %timeit (p1*p2).quo_rem(p1); (p1*p2).quo_rem(p2)
100 loops, best of 3: 7.02 ms per loop
sage: p1 = R4(str(p1))
sage: p2 = R4(str(p2))
sage: p = R4(str(p))
sage: assert p == p1*p2
sage: %timeit (p1*p2).quo_rem(p1); (p1*p2).quo_rem(p2)
100 loops, best of 3: 1.72 ms per loop

Hence

 3- Are there operations where it is desirable to go to R1 instead?

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] Re: symbolic computation with Chevalley generators for algebraic groups

[Joseph Hundley]

Awesome. Thank you!  

Out of curiosity is there a reason .norm_squared() doesn't just divide by 2 
for us? 

Joe

On Tuesday, July 26, 2016 at 4:29:00 PM UTC-4, Travis Scrimshaw wrote:
>
>
>
> On Tuesday, July 26, 2016 at 3:07:04 PM UTC-5, Joseph Hundley wrote:
>>
>> I recently looked at Computing in Groups of Lie Type  
>> by
>>  
>> Cohen, Murray and Taylor. The basic approach to representation and 
>> calculation which is taken there is essentially the one I had in mind. Plus 
>> they've worked a number of details I thought I would have to work out. It 
>> appears that this article was written as the algorithms in question were 
>> being implemented in Magma. I wonder firstly whether it would be considered 
>> "kosher" to reimplement them in Sage, and secondly whether it would be 
>> considered desirable.
>>
>
> Yes and possibly yes. It depends on how much of the algorithms depends on 
> doing linear algebra (or other aspects of Sage). If the answer is very 
> little to none, I would do it as a separate package in C++ for the speed 
> and then construct an iterface to it using Sage. Although we can always do 
> it in Sage and extract things out afterwards.
>  
>
>> Naively, it seems to me that the article would not have been written if 
>> the algorithms were to be treated as protected intellectual property. And 
>> I'd already stumbled across quite a bit of it independently by following my 
>> nose. Still I'm fairly new to programming and have not yet learned the 
>> ethos around such things. 
>>
>
> Its a published research paper, so we (i.e., anyone) are free to provide 
> our own implementation.
>
>>
>> If I were going forward with this, I think a reasonable first step would 
>> be to equip root systems with the ability to compute a few key integral 
>> invariants of roots and pairs of roots. Including: 
>> (1) the (normalized integral) norm square (always 1 for short roots, 2 or 
>> three for long...)
>>
>
> This is essentially already in Sage; you just need to divide by 2:
>
> sage: al = RootSystem(['B',4]).root_lattice().simple_roots()
> sage: al[1].norm_squared()
> 4
> sage: al[4].norm_squared()
> 2
> sage: al = RootSystem(['G',2]).root_lattice().simple_roots()
> sage: al[1].norm_squared()
> 2
> sage: al[2].norm_squared()
> 6
>  
>
>> (2) the largest integer k (given roots a and b) such that a+kb is a root.
>> (3) the smallest integer k (given roots a and b) such that a+kb is a root.
>>
>
> I've done these ad-hoc for the classical Lie algebras (see #16821), but it 
> would be good to have these as general methods.
>  
>
>> (4) integral structure constants of the Chevalley presentation. These are 
>> not uniquely determined by the system, but there is a fairly standard way 
>> of selecting them-- described for example in Cohen Murray Taylor or a 1988 
>> article of Gilkey and Seitz-- which depends only on the system, and 
>> therefore seems to me like a method which should live in class "root 
>> system."
>>
>
> If I am understanding what you want, see the structure coefficients for 
> the classical groups in #16821. We can probably extract that out as 
> separate functions, but I would not have them be a method of a root system 
> since it is specialized for Lie algebras and groups of Lie type.
>
> We might be better at this point moving the discussion to a trac ticket.
>
> 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.

[sage-devel] Re: Trac attachment limit

[leif]

William Stein wrote:
> On Wed, Jul 27, 2016 at 11:51 AM, Andrey Novoseltsev  
> wrote:
>> On Tuesday, 26 July 2016 20:13:56 UTC-6, William wrote:
>>>
>>> On Tue, Jul 26, 2016 at 1:04 PM, Paul Masson  wrote:
 What about a "packages" repository on GitHub just to store files?
>>>
>>> I was also going to suggest that.  A drawback is we would have to add
>>> all trac users to the Github repo, so hundreds and hundreds of people,
>>> many probably not even on github right now. So the overhead of a
>>> common repo that everyone uses would be prohibitive.
>>>
>>> Of course, people could just put their own packages in a repo and post
>>> a link to that.  I assume this was already obvious to Andrey though,
>>> and he considers it to be too much of a pain.
>>>
>>>  -- William
>>>
>>
>> Actually, it was not (in my defence I didn't give it much sort). What I used
>> to do was copy it to sage.math.washington.edu and post a link (which was
>> conveniently wget-able). It was obvious and easy to do. Uploading a file to
>> trac would be even easier and more obvious and would not require any extra
>> setup/thinking/knowledge on my part. It also would be so obvious, that there
>> would be no need to even document it somehow. Any other service/solution
>> needs to be explained in the documentation guide and kept up-to-date when
>> something changes.
>>
>> So personally I really really prefer being able to upload bigger files to
>> trac directly from the ticket page. What's the point of backing up
>> attachments there forever anyway? With mercurial attachments were patches.
>> Now I think they tend to be some screenshots or log files or something which
>> is not quite as crucial. With disk snapshots there is a fallback and a more
>> resilient backup can be concerned only with what people have typed, i.e. the
>> code and discussions themselves. Perhaps it is also possible just keep the
>> current 2MB limits for picking attachments that have to be backed up in case
>> we do care about screenshots.
>>
> 
> Great argument.  

Indeed.

> I think we should increase the attachment limit,
> but not backup the big attachments using bup.

So here's the current top-9 of our /standard/ packages (>= 10 MB):

86 MB   upstream/gcc-4.9.3.tar.bz2
31 MB   upstream/jmol-14.2.11_2015.01.20.tar.bz2
29 MB   upstream/R-3.2.4-revised.tar.gz
29 MB   upstream/maxima-5.35.1.tar.gz
16 MB   upstream/python-2.7.10.tar.gz
15 MB   upstream/ppl-1.2.tar.bz2
15 MB   upstream/matplotlib-1.5.1.tar.bz2
12 MB   upstream/scipy-0.17.1.tar.gz
11 MB   upstream/Pillow-3.3.0.tar.gz


Wondering whether we should delete at least larger binary attachments
from trac after some time (not necessarily immediately after a ticket
has been merged).


-leif


-- 
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: Trac attachment limit

[William Stein]

On Wed, Jul 27, 2016 at 11:51 AM, Andrey Novoseltsev  wrote:
> On Tuesday, 26 July 2016 20:13:56 UTC-6, William wrote:
>>
>> On Tue, Jul 26, 2016 at 1:04 PM, Paul Masson  wrote:
>> > What about a "packages" repository on GitHub just to store files?
>>
>> I was also going to suggest that.  A drawback is we would have to add
>> all trac users to the Github repo, so hundreds and hundreds of people,
>> many probably not even on github right now. So the overhead of a
>> common repo that everyone uses would be prohibitive.
>>
>> Of course, people could just put their own packages in a repo and post
>> a link to that.  I assume this was already obvious to Andrey though,
>> and he considers it to be too much of a pain.
>>
>>  -- William
>>
>
> Actually, it was not (in my defence I didn't give it much sort). What I used
> to do was copy it to sage.math.washington.edu and post a link (which was
> conveniently wget-able). It was obvious and easy to do. Uploading a file to
> trac would be even easier and more obvious and would not require any extra
> setup/thinking/knowledge on my part. It also would be so obvious, that there
> would be no need to even document it somehow. Any other service/solution
> needs to be explained in the documentation guide and kept up-to-date when
> something changes.
>
> So personally I really really prefer being able to upload bigger files to
> trac directly from the ticket page. What's the point of backing up
> attachments there forever anyway? With mercurial attachments were patches.
> Now I think they tend to be some screenshots or log files or something which
> is not quite as crucial. With disk snapshots there is a fallback and a more
> resilient backup can be concerned only with what people have typed, i.e. the
> code and discussions themselves. Perhaps it is also possible just keep the
> current 2MB limits for picking attachments that have to be backed up in case
> we do care about screenshots.
>

Great argument.   I think we should increase the attachment limit,
but not backup the big attachments using bup.

 -- William

-- 
William (http://wstein.org)

-- 
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: Trac attachment limit

[Andrey Novoseltsev]

On Tuesday, 26 July 2016 20:13:56 UTC-6, William wrote:
>
> On Tue, Jul 26, 2016 at 1:04 PM, Paul Masson  > wrote: 
> > What about a "packages" repository on GitHub just to store files? 
>
> I was also going to suggest that.  A drawback is we would have to add 
> all trac users to the Github repo, so hundreds and hundreds of people, 
> many probably not even on github right now. So the overhead of a 
> common repo that everyone uses would be prohibitive. 
>
> Of course, people could just put their own packages in a repo and post 
> a link to that.  I assume this was already obvious to Andrey though, 
> and he considers it to be too much of a pain. 
>
>  -- William 
>
>  
Actually, it was not (in my defence I didn't give it much sort). What I 
used to do was copy it to sage.math.washington.edu and post a link (which 
was conveniently wget-able). It was obvious and easy to do. Uploading a 
file to trac would be even easier and more obvious and would not require 
any extra setup/thinking/knowledge on my part. It also would be so obvious, 
that there would be no need to even document it somehow. Any other 
service/solution needs to be explained in the documentation guide and kept 
up-to-date when something changes.

So personally I really really prefer being able to upload bigger files to 
trac directly from the ticket page. What's the point of backing up 
attachments there forever anyway? With mercurial attachments were patches. 
Now I think they tend to be some screenshots or log files or something 
which is not quite as crucial. With disk snapshots there is a fallback and 
a more resilient backup can be concerned only with what people have typed, 
i.e. the code and discussions themselves. Perhaps it is also possible just 
keep the current 2MB limits for picking attachments that have to be backed 
up in case we do care about screenshots.

Thank you,
Andrey

-- 
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: patchbot server not responding

[Thierry]

Hi,

On Tue, Jul 26, 2016 at 11:46:03AM -0700, Frédéric Chapoton wrote:
> Hello,
> 
> I can log on patchbot.sagemath.org (as well as R. Bradshaw, R. A. Ohana and 
> M. Marco)
> 
> I do not have the technical comptetence to move the patchbot server 
> elsewhere. This probably involves at least setting up a web server and 
> copying the report database (which is at least 20GB large, and run with 
> mongodb).

I will have a look next week, and at least document things.

Ciao,
Thierry

 
> I can provide root access to anybody able to do that.
> 
> Frederic
> 
> Le jeudi 21 juillet 2016 20:56:19 UTC+2, William a écrit :
> >
> > Hi, 
> >
> > I rebooted the host machine and both  fileserver.sagemath.org and 
> > patchbot.sagemath.org respond to ssh requests. 
> >
> > I do NOT have any clue how to actually login to either machine. 
> > I was also completely unable to login to the machine that hosts them as 
> > well. 
> > Yes, I tried using a rescue disk and changing the password, but it's 
> > some really weird setup (that I know nothing about) using CentOS and 
> > ZFS, so that doesn't work either.There might be encryption as 
> > well... 
> >
> > The host machine has IP 128.208.160.134, but ssh isn't possible, and 
> > no account I have works on the physical login prompt. 
> >
> > If anybody can login to  fileserver.sagemath.org and/or 
> > patchbot.sagemath.org, please do so and let me know. 
> >
> > To be crystal clear, I'm really sick of this mess: 
> >
> > *** I AM GOING TO DELETE ABSOLUTELY EVERYTHING FROM ALL COMPUTERS I 
> > HAVE AT UW LATER THIS SUMMER. *** 
> >
> > In particular, the only goal regarding fileserver.sagemath.org and/or 
> > patchbot.sagemath.org is to get them off the UW machines.  I don't 
> > even *know* what fileserver.sagemath.org is at this point. 
> >
> > I will then setup a single kubernetes cluster on the bare metal 
> > machines, and people who are allocated credentials will be able to run 
> > containers that way. I'm not sure what I'll do about persistent 
> > storage (if anything). 
> >
> > William 
> >
> > On Thu, Jul 21, 2016 at 1:22 AM, leif  
> > wrote: 
> > > Volker Braun wrote: 
> > >> Please check up on fileserver.sagemath.org, too, while you are at 
> > it... 
> > > 
> > > Yes, their IPs differ by just one... ;-) 
> > > 
> > > 
> > > -leif 
> > > 
> > > 
> > >> On Thursday, July 21, 2016 at 2:20:17 AM UTC+2, William wrote: 
> > >> 
> > >> On Wed, Jul 20, 2016 at 12:39 PM, Frédéric Chapoton 
> > >>  wrote: 
> > >> > Anything new on the patchbot server status ? 
> > >> 
> > >> I will have physical access tomorrow. 
> > >> 
> > >> > 
> > >> > Frederic 
> > >> > 
> > >> > Le jeudi 14 juillet 2016 17:53:23 UTC+2, William a écrit : 
> > >> >> 
> > >> >> On Thu, Jul 14, 2016 at 4:16 AM, Frédéric Chapoton 
> > >>  
> > >> >> wrote: 
> > >> >> > Since a few hours maybe, the patchbot server is not longer 
> > >> responding, 
> > >> >> > and I 
> > >> >> > cannot connect. 
> > >> >> > 
> > >> >> > https://patchbot.sagemath.org 
> > >> >> > 
> > >> >> > It is currently hosted at UW, I think. 
> > >> >> 
> > >> >> Thanks for reporting this.  I can't do anything about this for 
> > the 
> > >> >> next week, as I'm not in the US. 
> > >> >> 
> > >> >> William 
> > > 
> > > 
> > > -- 
> > > 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. 
> >
> >
> >
> > -- 
> > William (http://wstein.org) 
> >
> 
> -- 
> 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.

-- 
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 on Bash on Ubuntu on Windows

[Erik Bray]

On Wed, Jul 27, 2016 at 8:11 AM, Nicolas M. Thiery
 wrote:
> On Tue, Jul 26, 2016 at 06:29:22PM +0200, Erik Bray wrote:
>> >> OS bashing will not be tolerated.
>> >
>> > But company bashing will... ;-)
>>
>> That's not really okay either--constructive criticisms are fine
>
> +1
>
>> but you never know where your next funding source will come from...
>
> This argument is a bit dangerous, as it suggests that we, as a
> community, would shut up for money.

It's just the first example I reached for.

> Granted, bashing any group
> whatsoever can be very counter productive by alienating potential
> users and collaborators; this is one practical reason to avoid it. But
> the main reason is that it's unethical and non scientific.

Yes, you also never know who you're collaborating with or what their
background is.

-- 
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: survey ==> Python3

[Erik Bray]

On Tue, Jul 26, 2016 at 9:46 PM, Francesco Biscani  wrote:
>> That would be difficult to substantiate I think.
>
>
> If you look at languages with "true" multithreading, what they provide are
> not only the basic building blocks which Python also has (threads, locks,
> mutexes, condition variables, etc.), but also a whole conceptual model of
> how a multi-threaded abstract machine is supposed to behave. The memory
> model, guarantees on instruction reordering by the compiler/interpreter,
> definition of the conditions for data races, atomic operations, and all that
> jazz.
>
> Correct me if I am wrong, but my understanding is that Python is currently
> lacking a formal model for threading. Even if the GIL were to be removed
> from CPython, Python would still lack crucial parts to make it really
> useable as a portable multithreaded language.

You changed the topic from "parallel programming" to multi-threading.
Multi-threading is not the only paradigm for parallelism...

-- 
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: Trac attachment limit

[Erik Bray]

On Tue, Jul 26, 2016 at 9:16 PM, leif  wrote:
> William Stein wrote:
>> On Tue, Jul 26, 2016 at 6:44 AM, leif  wrote:
>>> Samuel Lelievre wrote:
 Maybe we could create packages.sagemath.org?
>>>
>>> And/or create a trac plug-in which saves uploaded spkgs there/elsewhere,
>>> i.e., to a location which doesn't get backed up [the way trac
>>> attachments currently get].
>>
>> Good idea -- in fact, if the attachments are in a clear location  it
>> would probably be easy to change the bup backup script to not back
>> them up.
>
> The "non-raw" links to attachments trac also creates
> (https://trac.sagemath.org/attachment/ticket//) don't
> make sense for binary files, so it's worth to differentiate attachments
> by file type anyway (although there might be processors in trac to
> /view/ attachments like e.g. *.tar.gz or compressed log files as well).

It's not a problem for binary files--it just doesn't display them if
it doesn't know how.

> Don't know how hard this is to implement, but I presume this mainly
> boils down to adding "Binary attachments:" and an "Attach binary file"
> button to trac tickets, more or less adding a clone of what's already
> there (also with a different file size limit perhaps).

I'm still not seeing the problem here.

>> Incidentally, I'm making two types of backups: bup ones that get moved
>> offsite, and full disk image level snapshots, which get deleted after
>> a while...
>>
>> William
>
>
> --
> 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.

-- 
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: Installing optional packages

[leif]

Andrew wrote:
> I just installed an optional package but it took me a while to remember
> how to do it. Of course, it is completely straightforward but I just
> forgot

Ahem, './sage --help'?

That points you to './sage --advanced' (advanced help) as well, which gives

Installing packages and upgrading:
  -package [args] -- call the new package manager with given arguments.
 Run without arguments for package-specific help.
  -experimental   -- list all experimental packages that can be
installed
  -f [opts] [packages]-- shortcut for -i -f: force build of the given Sage
 packages
  -i [opts] [packages]-- install the given Sage packages.  Options:
   -c -- run the packages' test suites
   -d -- only download, do not install packages
   -f -- force build: install the packages even
 if they are already installed
   -s -- do not delete the temporary build
directories
 after a successful build
  -p [opts] [packages]-- install the given Sage packages, without dependency
 checking and with support for old-style spkgs.
 Options are -c, -d and -s with the same meaning as
 for the -i command
  -info [packages]-- print the SPKG.txt of the given packages
  --location  -- if needed, fix paths to make Sage relocatable
  -optional   -- list all optional packages that can be installed
  -standard   -- list all standard packages that can be installed
  -installed  -- list all installed packages
  -upgrade [version]  -- download, build and install the given version.
Here,
 'version' is a git branch or tag name. Useful
values
 are 'master' (the current development version, this
 is the default) or a version number like '5.13'.
  -pip [...]  -- invoke pip, the Python package manager


besides further usage help on other topics.


-leif


-- 
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: No longer able to build 7.2 or 7.3 betas on Mac OS X El Capitan

[leif]

leif wrote:
> Paul Masson wrote:
>> As I recall I did checkout that ticket (21006) by accident when I wanted
>> one (21008) a couple digits away. That's the source of the problem.
>>
>> Why can't the build system recognize an empty folder and pass over it?
> 
> That's a genuine bug in Sage's 'configure'.  Not only that it doesn't
> ignore empty folders, but doesn't even bail out with an error as
> intended, since the 'exit 1' terminates the loop / function, but not the
> 'configure' script (hence just the package list gets truncated, and
> 'configure' later exits normally).
> 
> I'll open a ticket unless someone beats me in doing so.  (IMHO worth a
> blocker, but I don't know how far Volker is in preparing the 7.3 release
> candidate.)

Done.  Needs review:

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


-leif


>> On Tuesday, July 26, 2016 at 1:20:38 PM UTC-7, Volker Braun wrote:
>>
>> You tried the ipython 5.0 ticket, I presume.
>>
>> This left an empty directory lying around. Git doesn't know about
>> empty directories, but our build system assumes that it is a
>> package. And then fails and writes an incomplete makefile. You need
>> to delete build/pkgs/prompt_toolkit, either by hand or via "git
>> clean -fdx" (the latter will throw away everything that isn't
>> checked in).


-- 
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] Incorrect links to external references in doc build

[Erik Bray]

On Wed, Jul 27, 2016 at 8:06 AM, Jeroen Demeyer  wrote:
> On 2016-07-26 18:52, Erik Bray wrote:
>>
>> Is this a known issue?  Has anyone encountered this before?
>
> Given that it's caught by a doctest, probably not. I added that doctest
> specifically while working on Sphinx-related tickets to ensure that links
> would work.

Given https://trac.sagemath.org/ticket/21044, it may not just be me.
This seems kind of similar--the link is mysteriously incorrect.  The
way Sage's docs are built in parallel by default, I've found, can lead
to a lot of inconsistencies in outcome.  For example, I've found a lot
of issues in the docs that occur when building them in serial, in a
single process, that don't show up in parallel builds mostly by
chance.

-- 
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] Incorrect links to external references in doc build

[Erik Bray]

On Tue, Jul 26, 2016 at 9:20 PM, Paul Masson  wrote:
> This Trac ticket looks related: https://trac.sagemath.org/ticket/21044

Thanks--I agree, that looks possibly related.  I'm working on investigating...

-- 
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 on Bash on Ubuntu on Windows

[Nicolas M. Thiery]

On Tue, Jul 26, 2016 at 06:29:22PM +0200, Erik Bray wrote:
> >> OS bashing will not be tolerated.
> >
> > But company bashing will... ;-)
> 
> That's not really okay either--constructive criticisms are fine

+1

> but you never know where your next funding source will come from...

This argument is a bit dangerous, as it suggests that we, as a
community, would shut up for money. Granted, bashing any group
whatsoever can be very counter productive by alienating potential
users and collaborators; this is one practical reason to avoid it. But
the main reason is that it's unethical and non scientific.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Incorrect links to external references in doc build

[Jeroen Demeyer]

On 2016-07-26 18:52, Erik Bray wrote:

Is this a known issue?  Has anyone encountered this before?
Given that it's caught by a doctest, probably not. I added that doctest 
specifically while working on Sphinx-related tickets to ensure that 
links would work.


--
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.