Re: [sage-devel] Re: Questions on (optional) packages

2018-04-05 Thread Jeroen Demeyer

On 2018-04-05 19:59, Simon King wrote:

But couldn't the same happen when putting $(SAGERUNTIME) into the list
of dependencies?


Of course. I never claimed to have a solution for the meataxe problem. I 
am only identifying and explaining the 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] Re: Questions on (optional) packages

2018-04-05 Thread Simon King
Dear Jeroen,

On 2018-04-05, Jeroen Demeyer  wrote:
> On 2018-04-05 17:53, Simon King wrote:
>> for the problem at #18514 it
>> would be fine to have `sage -b` *before* building p_group_cohomology.
>
> I'm not entirely sure which "problem at #18514" you are talking about, 
> but that won't fix the "ImportError: No module named meataxe" problem.

Yes, that is what I was talking about.

> Imagine that sagelib is built before p_group_cohomology. Then packages 
> could be built in the following order:
>
> sagelib
> meataxe
> p_group_cohomology
>
> This way, sagelib would not build the meataxe interface.

But couldn't the same happen when putting $(SAGERUNTIME) into the list
of dependencies?

Best regards,
Simon

-- 
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: Questions on (optional) packages

2018-04-05 Thread Jeroen Demeyer

On 2018-04-05 17:53, Simon King wrote:

for the problem at #18514 it
would be fine to have `sage -b` *before* building p_group_cohomology.


I'm not entirely sure which "problem at #18514" you are talking about, 
but that won't fix the "ImportError: No module named meataxe" problem.


Imagine that sagelib is built before p_group_cohomology. Then packages 
could be built in the following order:


sagelib
meataxe
p_group_cohomology

This way, sagelib would not build the meataxe interface.

--
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: Questions on (optional) packages

2018-04-05 Thread Jeroen Demeyer

On 2018-04-05 17:55, Simon King wrote:

And if both are supported: What are the differences?


Both "sagelib" and "$(SAGERUNTIME)" are supported.

The difference is that "sagelib" does not contain run-time dependencies 
of Sage. For example, running Sage requires pexpect, so pexpect is part 
of $(SAGERUNTIME). In your case, testing actually runs Sage, so you need 
$(SAGERUNTIME).


--
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: Compilation error sage-8.1

2018-04-05 Thread 'Paul Mercat' via sage-devel


Le mercredi 4 avril 2018 18:13:50 UTC+2, Dima Pasechnik a écrit :
>
> Could you post your patch here?
> It might 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.
--- a/numpy/distutils/fcompiler/gnu.py	2018-04-04 16:10:47.278903223 +0200
+++ b/numpy/distutils/fcompiler/gnu.py	2018-04-04 16:11:33.839744609 +0200
@@ -35,8 +35,9 @@
 def gnu_version_match(self, version_string):
 """Handle the different versions of GNU fortran compilers"""
 # Strip warning(s) that may be emitted by gfortran
-while version_string.startswith('gfortran: warning'):
-version_string = version_string[version_string.find('\n')+1:]
+#while version_string.startswith('gfortran: warning'):
+#version_string = version_string[version_string.find('\n')+1:]
+	version_string = "7.2.0"
 
 # Gfortran versions from after 2010 will output a simple string
 # (usually "x.y", "x.y.z" or "x.y.z-q") for ``-dumpversion``; older


[sage-devel] Re: Questions on (optional) packages

2018-04-05 Thread Simon King
PS:

On 2018-04-05, Jeroen Demeyer  wrote:
>> Suggested syntax: Including `sagelib` into the list of dependencies
>> of a package should trigger `sage -b` before installation.
>
> That is already supported. The problem is that you want *after*, not 
> *before*.

Do you mean the exact syntax that I gave (i.e., including sagelib in the
`dependencies` file)? Or do you mean $(SAGERUNTIME) should be inserted
instead of sagelib? And if both are supported: What are the differences?

Best regards,
Simon

-- 
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: Questions on (optional) packages

2018-04-05 Thread Simon King
Hi Jeroen,

On 2018-04-05, Jeroen Demeyer  wrote:
>> Suggested syntax: Including `sagelib` into the list of dependencies
>> of a package should trigger `sage -b` before installation.
>
> That is already supported. The problem is that you want *after*, not 
> *before*.

It depends on what spkg we are talking about. Ideally, `sage -b` would
be executed *after* building meataxe, but for the problem at #18514 it
would be fine to have `sage -b` *before* building p_group_cohomology.

Best regards,
Simon

-- 
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: Questions on (optional) packages

2018-04-05 Thread Jeroen Demeyer

On 2018-04-05 12:57, Simon King wrote:

If it is ok that an optional package directly does `sage -b`


No, that is not OK. When you do that, you will spawn an independent 
build of the Sage library. This happens while "make" is still running, 
so "make" might also be building the Sage library at the same time.



Suggested syntax: Including `sagelib` into the list of dependencies
of a package should trigger `sage -b` before installation.


That is already supported. The problem is that you want *after*, not 
*before*.


--
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] Gauss sum for the Dirichet character modulo 1

2018-04-05 Thread David Loeffler
Sounds reasonable to me. Can you open a trac ticket for this?

On 28 March 2018 at 18:01, Nicolás Sirolli  wrote:

> The Gauss sum for the Dirichlet character modulo 1 is equal to 1, but:
>
> sage: G = DirichletGroup(1)
> sage: chi = G.list()[0]
> sage: chi.gauss_sum()
> 0
>
> The output is zero because the gauss_sum function in modular/dirichlet.py,
> after some preliminaries, computes the following:
>
> for c in chi.values()[1:]:
> z *= zeta
> g += L(c)*z
> return g
>
>
> If chi.modulus() > 1, then chi.values()[0] equals 0, so it can be skipped
> in the sum above. But in this case, it equals 1 and needs to be included in
> the sum
>
> I'm using 8.2 beta 7.
>
> Best,
> Nicolás.
>
> --
> 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: Questions on (optional) packages

2018-04-05 Thread Simon King
Hi Dima,

On 2018-04-05, Dima Pasechnik  wrote:
> On Thursday, April 5, 2018 at 11:06:26 AM UTC+2, Simon King wrote:
>> So, question: Do I need to manually change the permissions of scripts 
>> generated by autotools in my spkg? 
>>
>
> This looks strange to me. Where are the sources of the spkg in question, 
> could you post a link?

http://users.minet.uni-jena.de/cohomology/p_group_cohomology-3.0.tar.xz

The tarball comprises two source folders:
- pyxsources, for a bunch of pip-installable python and cython modules
- csources, for an autotoolized c-library-with-some-executables. This is
  where one can also find install.sh that autotools didn't make
  executable, which is no problem on my ubuntu laptop but is a problem on
  John's OS X machine.

>> John also reports that when installing the package, its two dependencies 
>> have been *automatically* installed. 
>> Question: Is that really what should happen? I expected that a missing 
>> dependency would just give rise to an error, with a message stating 
>> what dependencies the user should install. 
>>
>
> No, why? What's wrong with automatic installation of dependencies? 
> How would you even expect Sage building to work without it?

Good point.

Or maybe I wasn't expecting an error but a question: "Installing foo has
bar as a dependency. Do you want to install bar or abort"

But then again expecting the user to answer questions is not good for
automatic building.

So, I think we better forget about my original expectation...

>> Moreover, the automatic installation of one of the dependencies (namely 
>> meataxe) was incomplete: One needs `sage -b` to make meataxe work, 
>> but the automatic installation of dependencies didn't do `sage -b`. 
>> Question: How to deal with that?
>
>
> Perhaps ./sage -b must be run in spkg-install of the meataxe?

If it is ok that an optional package directly does `sage -b` then I'll
open a ticket for it.

>> Anyway, it should be possible for an optional package to require 
>> `sage -b` before or after its installation. 
>> Suggested syntax: Including `sagelib` into the list of dependencies 
>> of a package should trigger `sage -b` before installation. 
>>
>
> hmm, before or after? 

If sagelib is a dependency of package foo, then I'd expect `sage -b` to
happen *before* foo is built.

On the other hand, as it was pointed out by Jeroen on the ticket, I
should append $(SAGERUNTIME) to build/pkgs/p_group_cohomology/dependencies,
if running the tests requires sage -b

Best regards,
Simon

-- 
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: Questions on (optional) packages

2018-04-05 Thread Dima Pasechnik


On Thursday, April 5, 2018 at 11:06:26 AM UTC+2, Simon King wrote:
>
> Hi! 
>
> Related with #18514 (Upgrade of group cohomology spkg), two or three 
> questions came up: 
>
> One part of the spkg is an autotoolised library. Autotools generates 
> some install.sh script, whose permission do not include execution. 
> Nonetheless on my machine the package installs fine, whereas John 
> Palmieri reports that he had to change permissions first before getting 
> it to work on OS X. 
> So, question: Do I need to manually change the permissions of scripts 
> generated by autotools in my spkg? 
>

This looks strange to me. Where are the sources of the spkg in question, 
could you post a link?
 

>
> John also reports that when installing the package, its two dependencies 
> have been *automatically* installed. 
> Question: Is that really what should happen? I expected that a missing 
> dependency would just give rise to an error, with a message stating 
> what dependencies the user should install. 
>

No, why? What's wrong with automatic installation of dependencies? 
How would you even expect Sage building to work without it?


> Moreover, the automatic installation of one of the dependencies (namely 
> meataxe) was incomplete: One needs `sage -b` to make meataxe work, 
> but the automatic installation of dependencies didn't do `sage -b`. 
> Question: How to deal with that?


Perhaps ./sage -b must be run in spkg-install of the meataxe?
 

>
>
> Should maybe the installation of a package automatically trigger `sage 
> -b`, provided that the package installation happens after installation 
> of the sage library? 
>
> Anyway, it should be possible for an optional package to require 
> `sage -b` before or after its installation. 
> Suggested syntax: Including `sagelib` into the list of dependencies 
> of a package should trigger `sage -b` before installation. 
>

hmm, before or after? 
 

>
> Best regards, 
> Simon 
>
>

-- 
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] Questions on (optional) packages

2018-04-05 Thread Simon King
Hi!

Related with #18514 (Upgrade of group cohomology spkg), two or three
questions came up:

One part of the spkg is an autotoolised library. Autotools generates
some install.sh script, whose permission do not include execution.
Nonetheless on my machine the package installs fine, whereas John
Palmieri reports that he had to change permissions first before getting
it to work on OS X.
So, question: Do I need to manually change the permissions of scripts
generated by autotools in my spkg?

John also reports that when installing the package, its two dependencies
have been *automatically* installed.
Question: Is that really what should happen? I expected that a missing
dependency would just give rise to an error, with a message stating
what dependencies the user should install.

Moreover, the automatic installation of one of the dependencies (namely
meataxe) was incomplete: One needs `sage -b` to make meataxe work,
but the automatic installation of dependencies didn't do `sage -b`.
Question: How to deal with that?

Should maybe the installation of a package automatically trigger `sage
-b`, provided that the package installation happens after installation
of the sage library?

Anyway, it should be possible for an optional package to require
`sage -b` before or after its installation.
Suggested syntax: Including `sagelib` into the list of dependencies
of a package should trigger `sage -b` before installation.

Best regards,
Simon

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