Re: [sage-devel] Re: Upper case letters in Sage Notebook

2014-07-22 Thread v_2e 
On Tue, 22 Jul 2014 13:59:35 -0700 (PDT)
Emmanuel Charpentier  wrote:

> The error message below, however,
> *hints at the problem in the lines that read :
> "line 522, in _user raise LookupError("no user '{}'".format
> (username)) exceptions.LookupError: no user 'V_2e' "
> 
  Sure it does, but the user cannot see the console log. He can only
see the web-GUI. And there is no message about incorrect user name.
Maybe, it is worth adding it there somehow?

  Regards,
Vladimir

- 
 

-- 
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: Upper case letters in Sage Notebook

2014-07-22 Thread Emmanuel Charpentier 
See below.

Le mardi 22 juillet 2014 19:31:49 UTC+2, v_...@ukr.net a écrit :
>
>  Hello! 
>   Today one of my students told me about the problems he experiences 
> trying to login into Sage Notebook server. In short, the problem was 
> that he entered his login name with the first letter in upper case. 
>   I was surprised that Notebook distinguishes between the names with 
> upper case and lower case letters, since it is usually ignored for 
> logins everywhere. 
>

Huh ? That happens on systems trying to emulate Windows' behaviour. 
Grownups' system are usually Unix-based and therefore case-sensitive. And 
Sage is *very* Unix-based (running a Unix VM or a Unix-like layer (Cygwin) 
are currently the *only* way torun it under windows (and only the first has 
reasonable behavior, notwithstanding the heroic eforts of the development 
team...)).  
 

>   However, what is worse, Sage Notebook does not give any message about 
> incorrect (non-existent in this case) login name - just and "Error 500" 
> screen. 
>

There, you have a point ... :-) The error message below, however, *hints at 
the problem in the lines that read :
"line 522, in _user raise LookupError("no user '{}'".format(username)) 
exceptions.LookupError: no user 'V_2e' "

HTH,

--
Emmanuel Charpentier


  Meanwhile in the console log I can see the following message: 
>
>  
>
> 2014-07-22 20:01:15+0300 [-] WSGI application error 
> Traceback (most recent call last): 
>   File 
> "/usr/lib64/python2.7/site-packages/twisted/python/threadpool.py", line 
> 196, in _worker result = context.call(ctx, function, *args, **kwargs) 
> File "/usr/lib64/python2.7/site-packages/twisted/python/context.py", 
> line 118, in callWithContext return self.currentContext 
> ().callWithContext(ctx, func, *args, **kw) File 
> "/usr/lib64/python2.7/site-packages/twisted/python/context.py", line 
> 81, in callWithContext return func(*args,**kw) File 
> "/usr/lib64/python2.7/site-packages/twisted/web/wsgi.py", line 332, in 
> run self.reactor.callFromThread(wsgiError, self.started, *exc_info()) 
> ---  --- 
>   File 
> "/usr/lib64/python2.7/site-packages/twisted/web/wsgi.py", line 315, in 
> run appIterator = self.application(self.environ, self.startResponse) 
> File "/usr/lib64/python2.7/site-packages/flask/app.py", line 1836, in 
> __call__ return self.wsgi_app(environ, start_response) File 
> "/usr/lib64/python2.7/site-packages/flask/app.py", line 1820, in 
> wsgi_app response = self.make_response(self.handle_exception(e)) File 
> "/usr/lib64/python2.7/site-packages/flask/app.py", line 1403, in 
> handle_exception reraise(exc_type, exc_value, tb) File 
> "/usr/lib64/python2.7/site-packages/flask/app.py", line 1817, in 
> wsgi_app response = self.full_dispatch_request() File 
> "/usr/lib64/python2.7/site-packages/flask/app.py", line 1477, in 
> full_dispatch_request rv = self.handle_user_exception(e) File 
> "/usr/lib64/python2.7/site-packages/flask/app.py", line 1381, in 
> handle_user_exception reraise(exc_type, exc_value, tb) File 
> "/usr/lib64/python2.7/site-packages/flask/app.py", line 1475, in 
> full_dispatch_request rv = self.dispatch_request() File 
> "/usr/lib64/python2.7/site-packages/flask/app.py", line 1461, in 
> dispatch_request return self.view_functions[rule.endpoint] 
> (**req.view_args) File 
> "/usr/lib64/python2.7/site-packages/sagenb/flask_version/authentication.py", 
>
> line 42, in login U = g.notebook.user_manager().user(username) File 
> "/usr/lib64/python2.7/site-packages/sagenb/notebook/user_manager.py", 
> line 112, in user return self._user(username) File 
> "/usr/lib64/python2.7/site-packages/sagenb/notebook/user_manager.py", 
> line 522, in _user raise LookupError("no user '{}'".format(username)) 
> exceptions.LookupError: no user 'V_2e' 
>
>  
>
>   Vladimir 
>
> - 
>  > 
>

-- 
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: weird integral behavior

2014-07-22 Thread Emmanuel Charpentier 
See answer in text.

Le samedi 19 juillet 2014 18:25:42 UTC+2, Anne Schilling a écrit :
>
> Hi! 
>
> [ Bandwidth savings ] 

>
> Pulling out e^{2\pi i x} to simplify the integral to a one dimensional 
> integral, 
>

??? Again, I can't follow you. Care to explain ?
 

> Sage can solve this numerically: 
>
> sage: g = lambda x : (1+e^(2*pi*I*x)).abs() 
> sage: numerical_integral(g,0,1) 
> (1.2732395447351625, 1.4155343563970746e-14) 
> sage: n(4/pi) 
> 1.27323954473516 
>
> but not symbolically: 
>
> sage: integral(g,(x,0,1)) 
>

Ahem. This is kinda Mathematica-like syntax. In Sage, one should write 
integrate((1+e^(2*i*pi*x)).abs(),x,0,1), which gives :
sage: integrate((1+e^(2*i*pi*x)).abs(),x,0,1)
1/2*(2*pi - I)/pi + 1/2*I/pi
sage: integrate((1+e^(2*i*pi*x)).abs(),x,0,1).expand()
1

Yay ! A worse problem ?

But I note that your syntax is *also* accepted by Sage (which I didn't 
know) for single variable integration :
sage: integral(x,(x,0,1))
1/2
sage: integral(x*y,(x,0,1),(y,0,1))
---
TypeError Traceback (most recent call last)
[ Bandwith savings : lotsa backtrace... ]
TypeError: cannot coerce arguments: no canonical coercion from  to Symbolic Ring

 A possible enhancement ?

HTH,

--
Emmanuel Charpentier


> Anne 
>

-- 
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: Comparison between str and sage.rings.integer.Integer depends on whether doctest called directly or via Makefile

2014-07-22 Thread Volker Braun 
There is no coercion from string and Integer to a common structure. That 
should be obvious, but we can also check it explicitly:

sage: cm = get_coercion_model()
sage: cm.explain('i', ZZ(0), operator.eq)
Left operand is not Sage element, will try _sage_.
Unknown result parent.

Hence the comparison is by memory position, which is essentially random 
(and very much platform-dependent).




On Tuesday, July 22, 2014 12:57:13 PM UTC-4, Clemens Heuberger wrote:
>
> Can anyone help me understanding the following behaviour: 
>
> A doctest (0 < 'I'; see below) passes when called directly and fails when 
> called 
> via a Makefile, reproduced under sage 6.3.beta6, 6.2, 5.10 (running Linux 
> Mint). 
>
> As pointed out in 
> 
> https://groups.google.com/d/topic/sage-support/KNSzU0JpZgQ/discussion , 
> comparison between str and Integer falls back to comparison between the 
> types. 
>
> Does that simply mean that cmp(str, sage.rings.integer.Integer) is random? 
>
> Is the behaviour reproducible on other systems? 
>
> This problem turned up when trying to find out why Volker Braun has 
> problems 
> with doctests in #16580 which I cannot reproduce. There, we need to 
> somehow sort 
> transitions in a finite state machine; the order itself does not really 
> matter, 
> but for doctests, it is important to always have the same order. 
>
>
> $ cat test-cmp.sage 
> """ 
> :: 
> sage: a = 0 
> sage: b = 'I' 
> sage: type(a) 
>  
> sage: type(b) 
>  
> sage: cmp(type(a), type(b)) 
> -1 
> sage: a < b 
> True 
> """ 
> $ cat Makefile 
>
> doctest: 
> sage -t test-cmp.sage 
>
> $ LANG=C make 
> sage -t test-cmp.sage 
> Running doctests with ID 2014-07-22-18-46-45-0e337b53. 
> Doctesting 1 file. 
> sage -t test-cmp.sage 
> ** 
> File "test-cmp.sage", line 9, in test-cmp 
> Failed example: 
> cmp(type(a), type(b)) 
> Expected: 
> -1 
> Got: 
> 1 
> ** 
> File "test-cmp.sage", line 11, in test-cmp 
> Failed example: 
> a < b 
> Expected: 
> True 
> Got: 
> False 
> ** 
> 1 item had failures: 
>2 of   7 in test-cmp 
> [6 tests, 2 failures, 0.00 s] 
> -- 
> sage -t test-cmp.sage  # 2 doctests failed 
> -- 
> Total time for all tests: 0.0 seconds 
> cpu time: 0.0 seconds 
> cumulative wall time: 0.0 seconds 
> make: *** [doctest] Error 1 
>
> $ sage -t test-cmp.sage 
> Running doctests with ID 2014-07-22-18-47-10-577db6a3. 
> Doctesting 1 file. 
> sage -t test-cmp.sage 
> [6 tests, 0.00 s] 
> -- 
> All tests passed! 
> -- 
> Total time for all tests: 0.0 seconds 
> cpu time: 0.0 seconds 
> cumulative wall time: 0.0 seconds 
>
>

-- 
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: Comparison between str and sage.rings.integer.Integer depends on whether doctest called directly or via Makefile

2014-07-22 Thread Nils Bruin 
On Tuesday, July 22, 2014 11:51:29 AM UTC-7, Clemens Heuberger wrote:
>
>
> May I ask on which system? 
>

Fedora 19 x86_64. I tried your makefile trick and I got consistent results, 
so I haven't been able to nudge sage or python into the comparison 
behaviour you described (for any type, really). Since modern systems try to 
randomize the memory layout of executables, it's very well possible that 
you're just observing a rare event.
 

> My problem is that I need to sort anyway---there, the exact order does not 
> matter, but it does matter to distinguish between 0 and '0' because of a 
> follow-up groupby.


Then you need to make sure that your key-space has an ordering. That means 
you should not be using both 0 and '0'. Sage tried to have "universal 
ordering" of all objects, but I think by now it's recognized that this was 
misguided. It seems to be not possible to have a "<" that agrees with 
mathematical intuition in cases where there is an ordering and is 
consistent across the whole system. Python used to try to have universal 
comparison (which is nice because that meant arbitrary lists could be 
sorted), but this was abandoned for complex numbers and is completely 
abandoned in Python 3.0 (where comparison tends to raise an exception for 
incompatible arguments).
 

> So I cannot use key=str there (and that would be hobbling  according your 
> outlined policy).
>

Indeed, I would not suggest putting any "sorted(... , key = str )" *in the 
code*, but in doctests it would be fine. If you want '0' to sort 
differently from 0, you might try "sorted( ..., key = repr)" instead? 

>
> The closest I could do to follow your suggestion would be a doctest 
> for line in sorted(latex(F).split("\n")) 
> print line 
>

Do you want to doctest the "latex" routine? and do you need F to have a 
well-defined ordering only to be able to doctest "latex(F)"? In that case 
our doctest procedure is broken. I'd solve that by putting a "#random" on 
the thing or by putting "..." wildcards in the output template to test some 
of the non-varying bits of the output (in particular, that it doesn't 
produce an error).
 

> But if cmp(type(0), type('I')) is indeed random: why not using str at this 
> place in sage.structure.element.Element._richcmp ? (and see what doctests 
> break 
> then)?
>

Because that's fixing something that's very broken already. If anything, we 
should be throwing an exception when it comes to this. I'm sure we'll 
slowly get rid of the universal ordering attempt eventually, perhaps 
if/when we transition to Python 3, since there it's not expected anyway. 
There comparing types indeed raises an exception.

-- 
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: Comparison between str and sage.rings.integer.Integer depends on whether doctest called directly or via Makefile

2014-07-22 Thread Clemens Heuberger 
Am 2014-07-22 20:34, schrieb Nils Bruin:
> Would you be working on a 32-bit system by any chance?

no, 64-bit system.

> Is the behaviour reproducible on other systems?
> 
> Not on my 64 bit machine.

May I ask on which system?

>  
> 
> This problem turned up when trying to find out why Volker Braun has 
> problems
> with doctests in #16580 which I cannot reproduce. There, we need to 
> somehow
> sort
> transitions in a finite state machine; the order itself does not really 
> matter,
> but for doctests, it is important to always have the same order.
> 
> 
> It's not important to have the object itself ordered; you should just make 
> sure
> that the string that is doctested against is sorted. So rather than doctesting
> the, say, dictionary, you doctest a sorted list of items from the dict, i.e.,
> 
> sage: T=dict( (a^2,a) for a in range(10))
> sage: T # random
> {0: 0, 1: 1, 4: 2, 9: 3, 16: 4, 25: 5, 36: 6, 49: 7, 64: 8, 81: 9}
> sage: sorted( T.items(), key = str)
> [(0, 0),
>  (1, 1),
>  (16, 4),
>  (25, 5),
>  (36, 6),
>  (4, 2),
>  (49, 7),
>  (64, 8),
>  (81, 9),
>  (9, 3)]
> 
> This sorts the items according to their str representations, so the sort only
> compares strings with strings, which has a well-defined (lexicographical)
> result. Don't hobble your implementation with arbitrary fixed orders just to
> satisfy a doctest requirement. Instead, write the doctest to take care of
> possible arbitrariness.

My problem is that I need to sort anyway---there, the exact order does not
matter, but it does matter to distinguish between 0 and '0' because of a
follow-up groupby. So I cannot use key=str there (and that would be hobbling
according your outlined policy).

The closest I could do to follow your suggestion would be a doctest
for line in sorted(latex(F).split("\n"))
print line
and I'd hate to do that (compared to latex(F), as it is now): it is ugly
and would result in a code which is not compilable by latex.

But if cmp(type(0), type('I')) is indeed random: why not using str at this
place in sage.structure.element.Element._richcmp ? (and see what doctests break
then)?

-- 
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: Comparison between str and sage.rings.integer.Integer depends on whether doctest called directly or via Makefile

2014-07-22 Thread Nils Bruin 
On Tuesday, July 22, 2014 9:57:13 AM UTC-7, Clemens Heuberger wrote:
>
> Does that simply mean that cmp(str, sage.rings.integer.Integer) is random? 
>

My guess is that it would be. However, I have not found a type on my system 
that compares as less than str and I haven't found a type that has id(str) 
> id( Is the behaviour reproducible on other systems? 
>

Not on my 64 bit machine.
 

> This problem turned up when trying to find out why Volker Braun has 
> problems 
> with doctests in #16580 which I cannot reproduce. There, we need to 
> somehow sort 
> transitions in a finite state machine; the order itself does not really 
> matter, 
> but for doctests, it is important to always have the same order. 
>

It's not important to have the object itself ordered; you should just make 
sure that the string that is doctested against is sorted. So rather than 
doctesting the, say, dictionary, you doctest a sorted list of items from 
the dict, i.e.,

sage: T=dict( (a^2,a) for a in range(10))
sage: T # random
{0: 0, 1: 1, 4: 2, 9: 3, 16: 4, 25: 5, 36: 6, 49: 7, 64: 8, 81: 9}
sage: sorted( T.items(), key = str)
[(0, 0),
 (1, 1),
 (16, 4),
 (25, 5),
 (36, 6),
 (4, 2),
 (49, 7),
 (64, 8),
 (81, 9),
 (9, 3)]

This sorts the items according to their str representations, so the sort 
only compares strings with strings, which has a well-defined 
(lexicographical) result. Don't hobble your implementation with arbitrary 
fixed orders just to satisfy a doctest requirement. Instead, write the 
doctest to take care of possible arbitrariness.

-- 
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] Upper case letters in Sage Notebook

2014-07-22 Thread v_2e 
  Hello!
  Today one of my students told me about the problems he experiences
trying to login into Sage Notebook server. In short, the problem was
that he entered his login name with the first letter in upper case.
  I was surprised that Notebook distinguishes between the names with
upper case and lower case letters, since it is usually ignored for
logins everywhere.
  However, what is worse, Sage Notebook does not give any message about
incorrect (non-existent in this case) login name - just and "Error 500"
screen.
  Meanwhile in the console log I can see the following message:



2014-07-22 20:01:15+0300 [-] WSGI application error
Traceback (most recent call last):
  File
"/usr/lib64/python2.7/site-packages/twisted/python/threadpool.py", line
196, in _worker result = context.call(ctx, function, *args, **kwargs)
File "/usr/lib64/python2.7/site-packages/twisted/python/context.py",
line 118, in callWithContext return self.currentContext
().callWithContext(ctx, func, *args, **kw) File
"/usr/lib64/python2.7/site-packages/twisted/python/context.py", line
81, in callWithContext return func(*args,**kw) File
"/usr/lib64/python2.7/site-packages/twisted/web/wsgi.py", line 332, in
run self.reactor.callFromThread(wsgiError, self.started, *exc_info())
---  ---
  File
"/usr/lib64/python2.7/site-packages/twisted/web/wsgi.py", line 315, in
run appIterator = self.application(self.environ, self.startResponse)
File "/usr/lib64/python2.7/site-packages/flask/app.py", line 1836, in
__call__ return self.wsgi_app(environ, start_response) File
"/usr/lib64/python2.7/site-packages/flask/app.py", line 1820, in
wsgi_app response = self.make_response(self.handle_exception(e)) File
"/usr/lib64/python2.7/site-packages/flask/app.py", line 1403, in
handle_exception reraise(exc_type, exc_value, tb) File
"/usr/lib64/python2.7/site-packages/flask/app.py", line 1817, in
wsgi_app response = self.full_dispatch_request() File
"/usr/lib64/python2.7/site-packages/flask/app.py", line 1477, in
full_dispatch_request rv = self.handle_user_exception(e) File
"/usr/lib64/python2.7/site-packages/flask/app.py", line 1381, in
handle_user_exception reraise(exc_type, exc_value, tb) File
"/usr/lib64/python2.7/site-packages/flask/app.py", line 1475, in
full_dispatch_request rv = self.dispatch_request() File
"/usr/lib64/python2.7/site-packages/flask/app.py", line 1461, in
dispatch_request return self.view_functions[rule.endpoint]
(**req.view_args) File
"/usr/lib64/python2.7/site-packages/sagenb/flask_version/authentication.py",
line 42, in login U = g.notebook.user_manager().user(username) File
"/usr/lib64/python2.7/site-packages/sagenb/notebook/user_manager.py",
line 112, in user return self._user(username) File
"/usr/lib64/python2.7/site-packages/sagenb/notebook/user_manager.py",
line 522, in _user raise LookupError("no user '{}'".format(username))
exceptions.LookupError: no user 'V_2e' 



  Vladimir

- 
 

-- 
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] Comparison between str and sage.rings.integer.Integer depends on whether doctest called directly or via Makefile

2014-07-22 Thread Clemens Heuberger 
Can anyone help me understanding the following behaviour:

A doctest (0 < 'I'; see below) passes when called directly and fails when called
via a Makefile, reproduced under sage 6.3.beta6, 6.2, 5.10 (running Linux Mint).

As pointed out in
https://groups.google.com/d/topic/sage-support/KNSzU0JpZgQ/discussion ,
comparison between str and Integer falls back to comparison between the types.

Does that simply mean that cmp(str, sage.rings.integer.Integer) is random?

Is the behaviour reproducible on other systems?

This problem turned up when trying to find out why Volker Braun has problems
with doctests in #16580 which I cannot reproduce. There, we need to somehow sort
transitions in a finite state machine; the order itself does not really matter,
but for doctests, it is important to always have the same order.


$ cat test-cmp.sage
"""
::
sage: a = 0
sage: b = 'I'
sage: type(a)

sage: type(b)

sage: cmp(type(a), type(b))
-1
sage: a < b
True
"""
$ cat Makefile

doctest:
sage -t test-cmp.sage

$ LANG=C make
sage -t test-cmp.sage
Running doctests with ID 2014-07-22-18-46-45-0e337b53.
Doctesting 1 file.
sage -t test-cmp.sage
**
File "test-cmp.sage", line 9, in test-cmp
Failed example:
cmp(type(a), type(b))
Expected:
-1
Got:
1
**
File "test-cmp.sage", line 11, in test-cmp
Failed example:
a < b
Expected:
True
Got:
False
**
1 item had failures:
   2 of   7 in test-cmp
[6 tests, 2 failures, 0.00 s]
--
sage -t test-cmp.sage  # 2 doctests failed
--
Total time for all tests: 0.0 seconds
cpu time: 0.0 seconds
cumulative wall time: 0.0 seconds
make: *** [doctest] Error 1

$ sage -t test-cmp.sage
Running doctests with ID 2014-07-22-18-47-10-577db6a3.
Doctesting 1 file.
sage -t test-cmp.sage
[6 tests, 0.00 s]
--
All tests passed!
--
Total time for all tests: 0.0 seconds
cpu time: 0.0 seconds
cumulative wall time: 0.0 seconds

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

Re: [sage-devel] Re: flint revert_series

2014-07-22 Thread Jonas Jermann 

On 22.07.2014 14:42, Fredrik Johansson wrote:> On Tue, Jul 22, 2014 at
> The reversion of t - t^3 + O(t^5) to length n = 5 should be t + t^3 +
> O(t^5). This is what I get when I call flint directly from a C
> program. Are you getting something different?

I meant to write revert_series(6) which didn't produce the t^5 term
with flint but did with sage's reversion.

> Note that the current implementation requires that 1, 2, ..., n-1 are
> invertible (this restriction is documented in the flint manual). So
> for polynomials over GF(5), n = 6 would be invalid input. You could
> insert some code that checks this and either raises an exception or
> computes over Z or Q and converts back.

Oh right. Thanks, I didn't realize that. That seems like a pretty 
serious restriction. :(


I added support for flint's revert_series with that restriction.


Best
Jonas

--
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: speaking spanish or catalan ?

2014-07-22 Thread mmarco 
The author is south american? 

There are several expressions that sound funny to people from Spain. Even 
there are some that i am not sure they are correct.

El martes, 22 de julio de 2014 15:43:01 UTC+2, Frédéric Chapoton escribió:
>
> Hello,
>
> is there any spanish (native) speaker there, to have a quick look at 
> http://trac.sagemath.org/ticket/7192 that needs review ?
>
> and maybe a catalan (native) speaker to look at 
> http://trac.sagemath.org/ticket/12847 ?
>
> Thanks,
>
> Frederic
>

-- 
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] speaking spanish or catalan ?

2014-07-22 Thread Frédéric Chapoton 
Hello,

is there any spanish (native) speaker there, to have a quick look at 
http://trac.sagemath.org/ticket/7192 that needs review ?

and maybe a catalan (native) speaker to look at 
http://trac.sagemath.org/ticket/12847 ?

Thanks,

Frederic

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

Re: [sage-devel] Re: flint revert_series

2014-07-22 Thread Jean-Pierre Flori 


On Tuesday, July 22, 2014 2:05:30 PM UTC+2, Jonas Jermann wrote:
>
> Hi 
>
> On 21.07.2014 13:10, Fredrik Johansson wrote: 
> > On Mon, Jul 21, 2014 at 7:37 AM, Jonas Jermann  > wrote: 
> >> I agree, but somehow the "flint import" details are slightly different. 
> >> I also saw a different name somewhere, "reverse_series". So I was not 
> >> sure how to exactly import it for nmod. I would appreciate if someone 
> >> familiar with flint could do that (or leave it out for now). 
> > 
> > You could use some other method in polynomial_zmod_flint.pyx as a 
> > template; reverse() for example. 
> > 
> > I guess you saw "reverse_series" in nmod_poly.pxd. This file is just 
> > out of date and should be updated to match the nmod_poly.h in the 
> > latest flint. 
>
> I added the zmod revert_series but somehow the result is wrong(?), even 
> if I increase the precision. Attached is a patch against the current 
> ticket with the failing doctest. Maybe revert_series does not exactly do 
> what we/I expect for finite fields, it seems to drop the t^5 term over 
> GF(5)? 
>
> >>> Another idea (perhaps for a separate update) would be to add a sage 
> >>> implementation of flint's algorithm for reversion over generic base 
> >>> ring. This is Algorithm 1: "Fast Lagrange inversion" in 
> >>> http://www.ams.org/journals/mcom/-000-00/S0025-5718-2014-02857-3/ 
> >>> (if you can't access it, http://arxiv.org/abs/1108.4772). The generic 
> >>> code would be a little slower than flint's implementations over Z, Q 
> and 
> >>> Z/nZ, so you definitely want to special-case those. But in general, 
> this 
> >>> should be much faster than sage's current implementation for 
> polynomials 
> >>> of high degree. 
> >> 
> >> 
> >> I am not familiar with the details but I assume that the algorithm 
> >> heavily depends on the performance of power series operations like 
> >> multiplication or inversion. See e.g. fredrikj.net/math/rev.pdf 
> > 
> > The fast reversion algorithm basically does fewer polynomial 
> > multiplications than the naive algorithm (O(n^0.5) instead of O(n)), 
> > so it's an improvement regardless of whether polynomial multiplication 
> > is slow or fast. 
>
> That's very nice and only positive change. :) 
> It's an independent modification of the current ticket though, right? 
>
> My point of view is "let's make one step at a time" or we'll just never 
include anything in Sage.
So I think the little wrapper you submitted is a good inclusion.
For sure we should also implement all that Fredrik and you suggested, but 
let's already include what you already did. 

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

Re: [sage-devel] Re: flint revert_series

2014-07-22 Thread Fredrik Johansson 
On Tue, Jul 22, 2014 at 9:05 PM, Jonas Jermann  wrote:
> Hi
>
>
> On 21.07.2014 13:10, Fredrik Johansson wrote:
>>
>> On Mon, Jul 21, 2014 at 7:37 AM, Jonas Jermann 
>> wrote:
>>>
>>> I agree, but somehow the "flint import" details are slightly different.
>>> I also saw a different name somewhere, "reverse_series". So I was not
>>> sure how to exactly import it for nmod. I would appreciate if someone
>>> familiar with flint could do that (or leave it out for now).
>>
>>
>> You could use some other method in polynomial_zmod_flint.pyx as a
>> template; reverse() for example.
>>
>> I guess you saw "reverse_series" in nmod_poly.pxd. This file is just
>> out of date and should be updated to match the nmod_poly.h in the
>> latest flint.
>
>
> I added the zmod revert_series but somehow the result is wrong(?), even if I
> increase the precision. Attached is a patch against the current ticket with
> the failing doctest. Maybe revert_series does not exactly do what we/I
> expect for finite fields, it seems to drop the t^5 term over GF(5)?

The reversion of t - t^3 + O(t^5) to length n = 5 should be t + t^3 +
O(t^5). This is what I get when I call flint directly from a C
program. Are you getting something different?

Note that the current implementation requires that 1, 2, ..., n-1 are
invertible (this restriction is documented in the flint manual). So
for polynomials over GF(5), n = 6 would be invalid input. You could
insert some code that checks this and either raises an exception or
computes over Z or Q and converts back.

 Another idea (perhaps for a separate update) would be to add a sage
 implementation of flint's algorithm for reversion over generic base
 ring. This is Algorithm 1: "Fast Lagrange inversion" in
 http://www.ams.org/journals/mcom/-000-00/S0025-5718-2014-02857-3/
 (if you can't access it, http://arxiv.org/abs/1108.4772). The generic
 code would be a little slower than flint's implementations over Z, Q and
 Z/nZ, so you definitely want to special-case those. But in general, this
 should be much faster than sage's current implementation for polynomials
 of high degree.
>>>
>>>
>>>
>>> I am not familiar with the details but I assume that the algorithm
>>> heavily depends on the performance of power series operations like
>>> multiplication or inversion. See e.g. fredrikj.net/math/rev.pdf
>>
>>
>> The fast reversion algorithm basically does fewer polynomial
>> multiplications than the naive algorithm (O(n^0.5) instead of O(n)),
>> so it's an improvement regardless of whether polynomial multiplication
>> is slow or fast.
>
>
> That's very nice and only positive change. :)
> It's an independent modification of the current ticket though, right?

Sure.

> I still feel the best long-term solution would be to use
> flint for power series. That would give a huge performance boost.
> But again, that's an independent question: The ticket could be applied even
> if flint was already used for power series.

True.

Fredrik

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

Re: [sage-devel] Re: flint revert_series

2014-07-22 Thread Jonas Jermann 

Hi

On 21.07.2014 13:10, Fredrik Johansson wrote:

On Mon, Jul 21, 2014 at 7:37 AM, Jonas Jermann  wrote:

I agree, but somehow the "flint import" details are slightly different.
I also saw a different name somewhere, "reverse_series". So I was not
sure how to exactly import it for nmod. I would appreciate if someone
familiar with flint could do that (or leave it out for now).


You could use some other method in polynomial_zmod_flint.pyx as a
template; reverse() for example.

I guess you saw "reverse_series" in nmod_poly.pxd. This file is just
out of date and should be updated to match the nmod_poly.h in the
latest flint.


I added the zmod revert_series but somehow the result is wrong(?), even 
if I increase the precision. Attached is a patch against the current 
ticket with the failing doctest. Maybe revert_series does not exactly do 
what we/I expect for finite fields, it seems to drop the t^5 term over 
GF(5)?



Another idea (perhaps for a separate update) would be to add a sage
implementation of flint's algorithm for reversion over generic base
ring. This is Algorithm 1: "Fast Lagrange inversion" in
http://www.ams.org/journals/mcom/-000-00/S0025-5718-2014-02857-3/
(if you can't access it, http://arxiv.org/abs/1108.4772). The generic
code would be a little slower than flint's implementations over Z, Q and
Z/nZ, so you definitely want to special-case those. But in general, this
should be much faster than sage's current implementation for polynomials
of high degree.



I am not familiar with the details but I assume that the algorithm
heavily depends on the performance of power series operations like
multiplication or inversion. See e.g. fredrikj.net/math/rev.pdf


The fast reversion algorithm basically does fewer polynomial
multiplications than the naive algorithm (O(n^0.5) instead of O(n)),
so it's an improvement regardless of whether polynomial multiplication
is slow or fast.


That's very nice and only positive change. :)
It's an independent modification of the current ticket though, right?

I still feel the best long-term solution would be to use
flint for power series. That would give a huge performance boost.
But again, that's an independent question: The ticket could be applied 
even if flint was already used for power series.



Best
Jonas

--
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.
diff --git a/src/sage/libs/flint/nmod_poly.pxd b/src/sage/libs/flint/nmod_poly.pxd
index e99a228..3926a6c 100644
--- a/src/sage/libs/flint/nmod_poly.pxd
+++ b/src/sage/libs/flint/nmod_poly.pxd
@@ -68,6 +68,8 @@ cdef extern from "flint/nmod_poly.h":
 cdef void nmod_poly_one(nmod_poly_t res)
 cdef void nmod_poly_truncate(nmod_poly_t poly, long len)
 cdef void nmod_poly_reverse(nmod_poly_t output, nmod_poly_t input, long m)
+cdef void nmod_poly_revert_series(nmod_poly_t output, nmod_poly_t intput, long m)
+
 cdef int nmod_poly_equal(nmod_poly_t a, nmod_poly_t b)
 
 # Powering
diff --git a/src/sage/rings/polynomial/polynomial_zmod_flint.pyx b/src/sage/rings/polynomial/polynomial_zmod_flint.pyx
index 1856be1..254501c 100644
--- a/src/sage/rings/polynomial/polynomial_zmod_flint.pyx
+++ b/src/sage/rings/polynomial/polynomial_zmod_flint.pyx
@@ -767,3 +767,39 @@ cdef class Polynomial_zmod_flint(Polynomial_template):
 else:
 nmod_poly_reverse(&res.x, &self.x, nmod_poly_length(&self.x))
 return res
+
+def revert_series(self, n):
+r"""
+Return a polynomial `f` such that `f(self(x)) = self(f(x)) = x mod x^n`.
+
+EXAMPLES::
+
+sage: R. =  GF(5)[]
+sage: f = t - t^3 + t^5
+sage: f.revert_series(5)  # todo: this fails (needs to be fixed)!
+t + t^3 + 2*t^5
+
+sage: f.revert_series(-1)
+Traceback (most recent call last):
+...
+ValueError: argument n must be a non-negative integer, got -1
+
+sage: g = - t^3 + t^5
+sage: g.revert_series(6)
+Traceback (most recent call last):
+...
+ValueError: self must have constant coefficient 0 and a unit for coefficient 1
+"""
+cdef Polynomial_zmod_flint res = self._new()
+cdef unsigned long m
+if n < 0:
+raise ValueError("argument n must be a non-negative integer, got %s" % n)
+m = n
+if not self[0].is_zero() or not self[1].is_unit():
+raise ValueError("self must have constant coefficient 0 and a unit for coefficient 1")
+
+sig_on()
+nmod_poly_revert_series(&res.x, &self.x, m)
+sig_off()
+
+re

Re: [sage-devel] Re: Solving rational inequality should give simplified result

2014-07-22 Thread Robert Pollak 
I wrote that qepcad cannot deal with terms like '-6 != 0'. This shows as 
follows:


sage: qepcad(-6 != 0, vars='(x)')
---
ValueErrorTraceback (most recent call last)
 in ()
> 1 qepcad(-Integer(6) != Integer(0), vars='(x)')

/home/robert/bin/sage-6.2-i686-Linux/local/lib/python2.7/site-packages/sage/interfaces/qepcad.pyc
 in qepcad(formula, assume, interact, solution, vars, **kwargs)
   1406 use_witness = True
   1407 
-> 1408 qe = Qepcad(formula, vars=vars, **kwargs)
   1409 if assume is not None:
   1410 qe.assume(assume)

/home/robert/bin/sage-6.2-i686-Linux/local/lib/python2.7/site-packages/sage/interfaces/qepcad.pyc
 in __init__(self, formula, vars, logfile, verbose, memcells, server)
749 # and ensure they match up with the variables in the 
formula.
750 if frozenset(varlist) != (fvars | frozenset(fqvars)):
--> 751 raise ValueError("specified vars don't match vars 
in formula")
752 if len(fqvars) and varlist[-len(fqvars):] != fqvars:
753 raise ValueError("specified vars don't match 
quantified vars")

ValueError: specified vars don't match vars in formula


(I see the same on sagecell.sagemath.org, which probably has qepcad-1.50.)

I have also tried the following version:
sage: qepcad(-6 != 0)
Here  qepcad.py comes as far as to to try starting the qepcad binary, which 
unfortunately fails on my machine.
On sagecell.sagemath.org, this version causes the evaluation to hang forever.


However, standalone qepcad can solve this, as shown in the following log. 
(Probably qepcad-1.50 could also solve this.)
So the first version certainly could be improved in qepcad.py.



robert@rpmint32 ~/bin $ qepcad
===
Quantifier Elimination 
  in   
Elementary Algebra and Geometry
  by   
  Partial Cylindrical Algebraic Decomposition  
   
   Version B 1.69, 16 Mar 2012
   
  by   
   Hoon Hong   
  (hh...@math.ncsu.edu)
   
With contributions by: Christopher W. Brown, George E. 
Collins, Mark J. Encarnacion, Jeremy R. Johnson
Werner Krandick, Richard Liska, Scott McCallum,
Nicolas Robidoux, and Stanly Steinberg 
===
Enter an informal description  between '[' and ']':
[]
Enter a variable list:
(x)
Enter the number of free variables:
1
Enter a prenex formula:
[-6 /= 0]
.


===

Before Normalization >
go

At the end of projection phase >
go

Before Choice >
go

Before Solution >
go

An equivalent quantifier-free formula:

TRUE


=  The End  ===

-
0 Garbage collections, 0 Cells and 0 Arrays reclaimed, in 0 milliseconds.
493089 Cells in AVAIL, 50 Cells in SPACE.

System time: 12 milliseconds.
System time after the initialization: 8 milliseconds.
-



-- 
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: Solving rational inequality should give simplified result

2014-07-22 Thread Dima Pasechnik 
On 2014-07-22, Robert Pollak  wrote:
> Am 22.07.2014 10:29, schrieb Dima Pasechnik:
>> perhaps a newer qepcad can deal with more things (Sage's qepcad 1.50
>> is quite outdated by now). Care to make an update of the corresponding
>> spkg?
>
> I have been thinking about it.
>
> As a first step I have built qepcad-B-1.69 and its dependency, the
> current saclib-2.2.6 (as static lib), under a clean install of
> Linuxmint-17-32bit (a derivative of Ubuntu 14.04 LTS). I could
> successfully compute one of the examples from the qepcad website. Then
> I have added qepcad to the path.
>
> Now for some reason my sage instance (from sage-6.2-i686-Linux-
> Ubuntu_13.04_i686.tar.lzma) still says "RuntimeError: Unable to start
> QEPCAD". How can I debug this?

perhaps the qepad executables (or links to them) should be in 
SAGE_LOCAL/bin ?
Then, there is a script sage-qepad installed by qepad 1.50 spkg,
which does stuff, and might interfere here.
(it also sets an env. var. QE...)



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

Re: [sage-devel] Re: Solving rational inequality should give simplified result

2014-07-22 Thread Robert Pollak 
Am 22.07.2014 10:29, schrieb Dima Pasechnik:
> perhaps a newer qepcad can deal with more things (Sage's qepcad 1.50
> is quite outdated by now). Care to make an update of the corresponding
> spkg?

I have been thinking about it.

As a first step I have built qepcad-B-1.69 and its dependency, the
current saclib-2.2.6 (as static lib), under a clean install of
Linuxmint-17-32bit (a derivative of Ubuntu 14.04 LTS). I could
successfully compute one of the examples from the qepcad website. Then
I have added qepcad to the path.

Now for some reason my sage instance (from sage-6.2-i686-Linux-
Ubuntu_13.04_i686.tar.lzma) still says "RuntimeError: Unable to start
QEPCAD". How can I debug this?

Here is my log:

robert@rpmint32 ~/bin/sage-6.2-i686-Linux $ 
PATH=$PATH:/home/robert/bin/qepcad-B.1.69/bin
robert@rpmint32 ~/bin/sage-6.2-i686-Linux $ export PATH
robert@rpmint32 ~/bin/sage-6.2-i686-Linux $ which qepcad
/home/robert/bin/qepcad-B.1.69/bin/qepcad
robert@rpmint32 ~/bin/sage-6.2-i686-Linux $ ./sage
┌┐
│ Sage Version 6.2, Release Date: 2014-05-06 │
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for help.│
└┘
sage: qepcad(x^2<4,vars='(x)')
---
RuntimeError  Traceback (most recent call last)
 in ()
> 1 qepcad(x**Integer(2) 1408 qe = Qepcad(formula, vars=vars, **kwargs)
   1409 if assume is not None:
   1410 qe.assume(assume)

/home/robert/bin/sage-6.2-i686-Linux/local/lib/python2.7/site-packages/sage/interfaces/qepcad.pyc
 in __init__(self, formula, vars, logfile, verbose, memcells, server)
764 
765 qex = Qepcad_expect(logfile=logfile)
--> 766 qex._send('[ input from Sage ]')
767 qex._send('(' + ','.join(varlist) + ')')
768 qex._send(str(free_vars))

/home/robert/bin/sage-6.2-i686-Linux/local/lib/python2.7/site-packages/sage/interfaces/expect.pyc
 in _send(self, cmd)
206 def _send(self, cmd):
207 if self._expect is None:
--> 208 self._start()
209 E = self._expect
210 self.__so_far = ''

/home/robert/bin/sage-6.2-i686-Linux/local/lib/python2.7/site-packages/sage/interfaces/expect.pyc
 in _start(self, alt_message, block_during_init)
446 self._session_number = BAD_SESSION
447 failed_to_start.append(self.name())
--> 448 raise RuntimeError("Unable to start %s"%self.name())
449 self._expect.timeout = None
450 with gc_disabled():

RuntimeError: Unable to start QEPCAD


-- 
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: Solving rational inequality should give simplified result

2014-07-22 Thread Dima Pasechnik 
On 2014-07-18, Robert Pollak  wrote:
>
> On Monday, July 1, 2013 11:37:02 AM UTC+2, I wrote:
>>
>> solve(abs((x-1)/(x-5)) <= 1/3, x) 
>>
> [...]
>> The main issue is that the result should be 
>>
>> [[-1 <= x, x <= 2]] 
>>
>  
> I have found a way to get this! A little term massaging gives me the 
> equivalent:
> sage: qepcad((x-1)^2 <= (1/3)^2 * (x-5)^2, vars='(x)')
> x + 1 >= 0 /\ x - 2 <= 0
>
> Also, qepcad can be used for cleaning up some results of 'solve':
> sage: qepcad(qepcad_formula.or_(x == 1, qepcad_formula.and_(1 < x, x < 2)), 
> vars='(x)')
> x - 1 >= 0 /\ x - 2 < 0
> but it cannot deal with the '-6 != 0' terms.
>
perhaps a newer qepcad can deal with more things (Sage's qepcad 1.50
is quite outdated by now). Care to make an update of the corresponding
spkg?



-- 
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: Build error in Sage-6.2: pynac-0.3.2

2014-07-22 Thread Jean-Pierre Flori 
Hey Stephen,

I'll take this occasion to ask you whether all patches needed to build Sage 
on FreeBSD are currently submitted on our trac?
If so, I might update my FreeBSD vms, try them and review them.
It would be very nice to be able to build Sage on FreeBSD from scratch.
IIRC at some point I could do it, the most problematic stuff were some 
distuils stuff in numpy(?) looking for atlas libs with a wrong name, and 
maybe building ATLAS itself but I'm sure Iresolved that issue.

Best,
JP

-- 
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: Build error in Sage-6.2: pynac-0.3.2

2014-07-22 Thread Dima Pasechnik 
On 2014-07-21, Montgomery-Smith, Stephen  wrote:
> Hey people,
>
> FreeBSD people do like to build their ports as root.  The problem
> described below could be easily fixed by simply removing the group write
> permissions of all the files in the tarball upstream/pynac-0.3.2.tar.bz2.
>
> It's not such a great deal if this isn't fixed by the time sage-6.3
> comes out, but it would be nice.
one can just put this fix into 
build/pkgs/pynac
(either as a patch to be applied, or directly into spkg-install)

feel free to cc me on the corresponding trac ticket.


>
> On 06/06/2014 08:15 PM, Alasdair wrote:
>> Here's the error as reported during the compilation process:
>> 
>> checking for python... /opt/sage-6.2/local/bin/python
>> checking for a version of Python >= '2.1.0'... sys:1:
>> RuntimeWarning: not adding directory '' to sys.path since it's
>> writable by an untrusted group.
>> Untrusted users could put files in this directory which might then
>> be imported by your Python code. As a general precaution from
>> similar exploits, you should not execute Python code from this directory
>> yes
>> checking for the distutils Python package... no
>> configure: error: cannot import Python module "distutils".
>> Please check your Python installation. The error was:
>> sys:1: RuntimeWarning: not adding directory '' to sys.path since
>> it's writable by an untrusted group.
>> Untrusted users could put files in this directory which might then
>> be imported by your Python code. As a general precaution from
>> similar exploits, you should not execute Python code from this directory
>> make[3]: Entering directory
>> `/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2/src'
>> make[3]: *** No targets specified and no makefile found.  Stop.
>> make[3]: Leaving directory
>> `/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2/src'
>> Error building pynac.
>> 
>> real0m0.869s
>> user0m0.528s
>> sys 0m0.384s
>> 
>> Error installing package pynac-0.3.2
>> 
>> Please email sage-devel (http://groups.google.com/group/sage-devel)
>> explaining the problem and including the relevant part of the log file
>>   /opt/sage-6.2/logs/pkgs/pynac-0.3.2.log
>> Describe your computer, operating system, etc.
>> If you want to try to fix the problem yourself, *don't* just cd to
>> /opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2 and type 'make'
>> or whatever is appropriate.
>> Instead, the following commands setup all environment variables
>> correctly and load a subshell for you to debug the error:
>>   (cd '/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2' &&
>> '/opt/sage-6.2/sage' --sh)
>> When you are done debugging, you can type "exit" to leave the subshell.
>> 
>> make[2]: ***
>> [/opt/sage-6.2/local/var/lib/sage/installed/pynac-0.3.2] Error 1
>> make[2]: Leaving directory `/opt/sage-6.2/build'
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory `/opt/sage-6.2/build'
>> 
>> real150m50.768s
>> user131m18.168s
>> sys 17m8.948s
>> ***
>> Error building Sage.
>> 
>> The following package(s) may have failed to build:
>> 
>> package: pynac-0.3.2
>> log file: /opt/sage-6.2/logs/pkgs/pynac-0.3.2.log
>> build directory: /opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2
>> 
>> The build directory may contain configuration files and other
>> potentially
>> helpful information. WARNING: if you now run 'make' again, the build
>> directory will, by default, be deleted. Set the environment variable
>> SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
>> 
>> make: *** [build] Error 1
>> 
>> 
>> I'm attempting this on a new installation of kubuntu 14.04 64-bit.  This
>> is the first time, in maybe 20 Sage compilations over the years, that
>> I've encountered an error.  I've aso checked that I do have distutils,
>> it was installed when I installed Python initially (version 2.7); there
>> is also distutils for Python 3.4; I imagine loaded as part of the Sage
>> compile process.
>> 
>> Any advice?
>> 
>> -- 
>> 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/op