[sage-devel] Re: Question about libgap_enter/exit

[Nils Bruin]

On Thursday, September 7, 2017 at 9:49:33 AM UTC-7, Volker Braun wrote:
>
> First question: The GAP garbage collector might delete objects, or it 
> might move existing objects around in memory (it is a compacting garbage 
> collector). If your code contains C pointers to GAP objects, bad things 
> will happen after that. Not every libGAP_* function can invoke the garbage 
> collector, and for those that do it will not always run a collection cycle. 
> But there are no documented guarantees that any particular libGAP_* 
> function does not run garbage collection, or may be changed to run garbage 
> collection in the future.
>

Ouch. Gap indeed uses a compactifying garbage collector. But are you saying 
it will adjust the *stack*, for which the garbage collector doesn't know 
the exact layout? Then, if I have an integer on the stack that happens to 
coincide in bit pattern with a pointer to a moved Gap object, this integer 
could get changed. That's a low probability event, but not the kind of 
thing that mathematical software can take chances with. Are you sure it 
does that? (it seems it would have to ...)

A conservative GC like Boehm can get away with interpreting values as 
pointers if in doubt: at the worst it prevents an unreachable object to not 
be GCd because it seems it's reachable, but it won't turn results of valid 
code into nonsense. A compacting GC has to know for sure which values are 
pointers and which are not.

-- 
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] fun quora post using Sage/CC

[kcrisman]

Perhaps this should be linked to on the website as well ... happy elliptic 
curve reading!

https://www.quora.com/How-do-you-find-the-positive-integer-solutions-to-frac-x-y%2Bz-%2B-frac-y-z%2Bx-%2B-frac-z-x%2By-4/answer/Alon-Amit?share=1

-- 
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: Question about libgap_enter/exit

[Simon King]

Hi Vincent,

On 2017-09-07, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> I believe that GAP should also be initialized before calling any 
> non-trivial function using the stack. How do you initalize it? (the call 
> "import sage.libs.gap.libgap should do the job).

I do
   from sage.libs.gap.libgap import libgap
and I guess that's as good as "import sage.libs.gap.libgap".

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: Question about libgap_enter/exit

[Simon King]

Hi!

On 2017-09-07, Simon King  wrote:
> On 2017-09-07, Volker Braun  wrote:
>> Second question: Move the libgap_enter/exit outside of the loop, assuming 
>> that the python functions don't themselves call libgap. If they do, you 
>> will get a  "RuntimeError: Entered a critical block twice". In that case, 
>> move the libgap_enter/exit into the loop as far as necessary to have 
>> non-overlapping libgap_enter/exit blocks.
>
> Since GapElement_List.__getitem__ (and the functions called by it) doesn't
> seem to use it, it will probably be fine (couldn't test it yet, though).

I expected a crash when *not* using libgap_enter/exit. But  actually I am
getting the crash when I *do* use it. I see the message
sig_error() without sig_on()
followed by a lng gdb backtrace.

So, does one need sig_on()/sig_off() in addition to libgap_enter/exit?

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] _richcmp_ versus __eq__ for scheme points

[Nils Bruin]

What is the argument that makes PP(0) == 0 bad? If PP(0) is allowed, I 
don't see how PP(0) == 0 is particularly worse.

Because PP(AA(0)) and PP(BB(0)) should be different points, so it's not so 
clear which one should have precedence. PP(0) happens to choose PP(BB(0)). 
I don't think that's canonical enough to promote to PP(0) == 0 working as 
well.

sage: hash(0)
0
sage: hash(ProjectiveSpace(QQ,1)(0))
3713080549409410656

also suggests that equality is not warranted.

-- 
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: Question about libgap_enter/exit

[Simon King]

Hi Volker,

On 2017-09-07, Volker Braun  wrote:
> First question: The GAP garbage collector might delete objects, or it might 
> move existing objects around in memory (it is a compacting garbage 
> collector). If your code contains C pointers to GAP objects, bad things 
> will happen after that.

If by "pointer to GAP objects" you mean "cdef libGAP_Obj", then my code
does contain such pointers. So, I guess I should better use libgap_enter/exit.

> Second question: Move the libgap_enter/exit outside of the loop, assuming 
> that the python functions don't themselves call libgap. If they do, you 
> will get a  "RuntimeError: Entered a critical block twice". In that case, 
> move the libgap_enter/exit into the loop as far as necessary to have 
> non-overlapping libgap_enter/exit blocks.

Since GapElement_List.__getitem__ (and the functions called by it) doesn't
seem to use it, it will probably be fine (couldn't test it yet, though).

Thank you for your explanations!
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: Question about libgap_enter/exit

[Vincent Delecroix]

On 07/09/2017 18:04, Simon King wrote:

Hi Dima,

On 2017-09-07, Dima Pasechnik  wrote:

I don't think anything special like libgap_enter/exit  is needed when
calling libgap.* stuff from
Python or Cython.


The documentation in sage.libs.gap.libgap says:
"""
In particular, you must call ``libgap_mark_stack_bottom()`` in every
function that calls into the libGAP C functions. The reason is that
the GAP memory manager will automatically keep objects alive that are
referenced in local (stack-allocated) variables.
...
In order to
catch this error, it is recommended that you wrap calls into libGAP in
``libgap_enter`` / ``libgap_exit`` blocks and not call
``libgap_mark_stack_bottom`` manually.
"""

Or perhaps I misunderstood. After reading it again, I shouldn't have
expected a crash but should have checked for memory leaks.


I believe that GAP should also be initialized before calling any 
non-trivial function using the stack. How do you initalize it? (the call 
"import sage.libs.gap.libgap should do the job).


--
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: Question about libgap_enter/exit

[Simon King]

Hi Volker,

On 2017-09-07, Volker Braun  wrote:
> For the record, using the libgap Python interface (i.e. from 
> sage.libs.gap.libgap import libgap) automatically takes care of the 
> libgap_enter/exit business. This is only an issue if you want to the libGAP 
> C API directly, which is what Simon is presumably asking.

Correct.

Cheers,
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: Question about libgap_enter/exit

[Simon King]

Hi Dima,

On 2017-09-07, Dima Pasechnik  wrote:
> I don't think anything special like libgap_enter/exit  is needed when 
> calling libgap.* stuff from
> Python or Cython.

The documentation in sage.libs.gap.libgap says:
"""
In particular, you must call ``libgap_mark_stack_bottom()`` in every
function that calls into the libGAP C functions. The reason is that
the GAP memory manager will automatically keep objects alive that are
referenced in local (stack-allocated) variables.
...
In order to
catch this error, it is recommended that you wrap calls into libGAP in
``libgap_enter`` / ``libgap_exit`` blocks and not call
``libgap_mark_stack_bottom`` manually.
"""

Or perhaps I misunderstood. After reading it again, I shouldn't have
expected a crash but should have checked for memory leaks.

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] _richcmp_ versus __eq__ for scheme points

[Ben Hutz]

Condensing your example; this behavior is clearly bad

sage: PP = ProjectiveSpace(QQ,1)
sage: AA = PP.affine_patch(0)
sage: BB = PP.affine_patch(1)
sage: AA is BB
True  #???

I don't know of any intention to make AffineSpace globally unique, but I'd 
need to look through the code to see what happened here.


What is the argument that makes PP(0) == 0 bad? If PP(0) is allowed, I 
don't see how PP(0) == 0 is particularly worse.

On Thursday, September 7, 2017 at 3:16:56 PM UTC-5, Nils Bruin wrote:
>
> On Thursday, September 7, 2017 at 12:10:40 PM UTC-7, Ben Hutz wrote:
>>
>>
>> Ah. I see the difference. I don't think it is unreasonable for P(0) == 0 
>> to work in dimension 1 as there is a canonical answer. So I would have to 
>> say yes, I'm working on having that coercion work. 
>>
> I think it is unreasonable, and in investigating I noticed that sage is 
> doing  quite severely unreasonable stuff presently:
>
> sage: PP = ProjectiveSpace(1) / QQ
> sage: AA = PP.affine_patch(0)
> sage: PP(AA.projective_embedding()(AA(0)))
> (1 : 0)
> sage: PP(AA(0)) # ??? Really?
> (0 : 1)
> sage: BB = PP.affine_patch(1)
> sage: BB.projective_embedding()
>
> Scheme morphism:
>   From: Affine Space of dimension 1 over Rational Field
>   To:   Projective Space of dimension 1 over Rational Field
>   Defn: Defined on coordinates by sending (x) to
> (x : 1)
> sage: AA.projective_embedding() # @#%@!!
>
> Scheme morphism:
>   From: Affine Space of dimension 1 over Rational Field
>   To:   Projective Space of dimension 1 over Rational Field
>   Defn: Defined on coordinates by sending (x) to
> (x : 1)
> sage: AA is BB # 

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

[Nils Bruin]

On Thursday, September 7, 2017 at 12:10:40 PM UTC-7, Ben Hutz wrote:
>
>
> Ah. I see the difference. I don't think it is unreasonable for P(0) == 0 
> to work in dimension 1 as there is a canonical answer. So I would have to 
> say yes, I'm working on having that coercion work. 
>
I think it is unreasonable, and in investigating I noticed that sage is 
doing  quite severely unreasonable stuff presently:

sage: PP = ProjectiveSpace(1) / QQ
sage: AA = PP.affine_patch(0)
sage: PP(AA.projective_embedding()(AA(0)))
(1 : 0)
sage: PP(AA(0)) # ??? Really?
(0 : 1)
sage: BB = PP.affine_patch(1)
sage: BB.projective_embedding()

Scheme morphism:
  From: Affine Space of dimension 1 over Rational Field
  To:   Projective Space of dimension 1 over Rational Field
  Defn: Defined on coordinates by sending (x) to
(x : 1)
sage: AA.projective_embedding() # @#%@!!

Scheme morphism:
  From: Affine Space of dimension 1 over Rational Field
  To:   Projective Space of dimension 1 over Rational Field
  Defn: Defined on coordinates by sending (x) to
(x : 1)
sage: AA is BB # 

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

[Ben Hutz]

On Thursday, September 7, 2017 at 1:16:12 PM UTC-5, David Roe wrote:
>
>
>
> On Thu, Sep 7, 2017 at 2:00 PM, Ben Hutz  
> wrote:
>
> Once you construct P(0), both a and P(0) are in the same parent, so there 
> are no coercions involved in the test a==P(0).  In your branch, what does 
> sage: a.parent().coerce_map_from(QQ)
> return?
>

I get 'None', so apparently I don't have the coercion framework working 
fully yet.

>  
>
>> You'd be surprised at how often in Sage the shorthand of leaving of the 
>> last coordinate occurs. But, yes, it is just a shorthand and is used in the 
>> __init__() for point.
>>
>
> I certainly agree that leaving off the last coordinate is convenient and 
> common.  But the difference is between *conversion* (where you specify the 
> parent explicitly) and *coercion* (which happens implicitly, like in the 
> equality test you're making above).  Are you trying to add coercions, just 
> for A^1 and P^1?  Or something more?
> David
>
> Ah. I see the difference. I don't think it is unreasonable for P(0) == 0 
to work in dimension 1 as there is a canonical answer. So I would have to 
say yes, I'm working on having that coercion 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.

[sage-devel] Re: SAGE_PATH and PYTHONPATH

[Nils Bruin]

On Wednesday, September 6, 2017 at 2:25:35 AM UTC-7, Ralf Hemmecke wrote:
>
> Since my settings using SAGE_PATH do seemingly not work anymore, I 
> looked for the use of SAGE_PATH in the sources. 
>
> I found in 7.6 some code 
>
> if [ -n "$SAGE_PATH" ]; then 
> PYTHONPATH="$SAGE_PATH:$PYTHONPATH" 
> fi 
>
> but that was removed in commit 
>
> 22e470c2d6941875908f35ff3657843f1fe83f21 
>
> So it looks like SAGE_PATH is not used in 8.0 anymore although the 
> documentation still suggests its use. 
>
> http://doc.sagemath.org/html/en/reference/repl/environ.html 
>
> What exactly is the situation? 
>

For ref:

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

It looks like PYTHONPATH isn't set at all with sage anymore, so you could 
set it yourself. As https://trac.sagemath.org/ticket/22608 explains, it 
looks like having PYTHONPATH set caused problems with differentiating 
between Py2 and Py3, though, so if you do set it yourself, you could get 
trouble from that.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Question about libgap_enter/exit

[Volker Braun]

The change will mostly be to remove the libGAP_ prefix for symbols, so it 
should be pretty easy to sed that out (or use a macro to be compatible with 
both).


On Thursday, September 7, 2017 at 7:45:04 PM UTC+2, Dima Pasechnik wrote:
>
> I would not touch C API to libGAP with a stick, given that it might get 
> changed by GAP people soon, I guess.
> https://github.com/gap-system/gap/pull/1205

-- 
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] _richcmp_ versus __eq__ for scheme points

[David Roe]

On Thu, Sep 7, 2017 at 2:00 PM, Ben Hutz  wrote:

> Yes, but *after* implementing the coercion for the homsets I'm getting the
> behavior above. The 'a==0' doesn't go through the coecion framework, but
> the a==P(0) does. So one returns true and the other false. I'm trying to
> figure out why == is not utilizing the coercion/richcmp in that case.
>

Once you construct P(0), both a and P(0) are in the same parent, so there
are no coercions involved in the test a==P(0).  In your branch, what does
sage: a.parent().coerce_map_from(QQ)
return?


> You'd be surprised at how often in Sage the shorthand of leaving of the
> last coordinate occurs. But, yes, it is just a shorthand and is used in the
> __init__() for point.
>

I certainly agree that leaving off the last coordinate is convenient and
common.  But the difference is between *conversion* (where you specify the
parent explicitly) and *coercion* (which happens implicitly, like in the
equality test you're making above).  Are you trying to add coercions, just
for A^1 and P^1?  Or something more?
David


> On Thursday, September 7, 2017 at 12:53:05 PM UTC-5, David Roe wrote:
>
>>
>>
>> On Thu, Sep 7, 2017 at 1:46 PM, Ben Hutz  wrote:
>>
>>> Yes, I'm working on the coercion now.
>>>
>>> However, isn't a==0 checking coercion from the parent of a to the parent
>>> of 0. In other words, the homset of rational points on P and QQ.
>>>
>>
>> Yes, I got confused by the notation, since normally in Sage P(0) would
>> create an element of P.   But there's still no coercion:
>>
>> sage: a.parent().has_coerce_map_from(QQ)
>> False
>>
>> In dimension 1, there is a canonical coercion, but not in higher
>>> dimensions.
>>>
>>
>> Sure, but only for P^1 and A^1, not other curves.  Is there value in
>> having coercions just for those two, for dynamics for example?
>> David
>>
>> On Thursday, September 7, 2017 at 12:17:57 PM UTC-5, David Roe wrote:

 The reason that a==0 returns false is that there is no coercion map
 from QQ to P:

 sage: P.has_coerce_map_from(QQ)
 False

 I'm not convinced that there should be a coercion, it's pretty rare
 that a scheme has a natural map from its base ring.
 However, it seems like there's also a problem hiding here, probably
 because schemes don't use the coercion model properly:

 sage: P.convert_map_from(QQ)
 Traceback (most recent call last)
 ...
 RuntimeError: BUG in coercion model, no element constructor for >>> 'sage.schemes.projective.projective_space.ProjectiveSpace_
 rational_field_with_category'>

 David

 On Thu, Sep 7, 2017 at 1:11 PM, Ben Hutz  wrote:

> I'm working on implementing coercion for scheme points and had a
> question about how comparison is done. As an explicit example consider the
> following point
>
> P.= ProjectiveSpace (QQ ,1)
> a=P(0)
>
> in particular, the integer 0 is coerced into the projective point
> (0:1). For comparisons it appears that
>
> a == P(0)  (returns to True)
>
> calls the _richcmp_() function so uses the coercion framework, but
>
> a==0  (returns False even though it knows there is a coercion from the
> integer ring to P)
>
> is calling something else. There does not appear to be an  __eq__()
> operator implemented for scheme points, but it does show up in tab
> completion in the notebook, but can't tell me where the code is from. Is
> this an artifact of starting to transition the code to python3. Or this
> just broken somewhere?
>
> Thanks,
>   Ben
>
> --
> 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.
>

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

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

[Ben Hutz]

Yes, but *after* implementing the coercion for the homsets I'm getting the 
behavior above. The 'a==0' doesn't go through the coecion framework, but 
the a==P(0) does. So one returns true and the other false. I'm trying to 
figure out why == is not utilizing the coercion/richcmp in that case.

You'd be surprised at how often in Sage the shorthand of leaving of the 
last coordinate occurs. But, yes, it is just a shorthand and is used in the 
__init__() for point.

On Thursday, September 7, 2017 at 12:53:05 PM UTC-5, David Roe wrote:
>
>
>
> On Thu, Sep 7, 2017 at 1:46 PM, Ben Hutz  
> wrote:
>
>> Yes, I'm working on the coercion now.
>>
>> However, isn't a==0 checking coercion from the parent of a to the parent 
>> of 0. In other words, the homset of rational points on P and QQ.
>>
>
> Yes, I got confused by the notation, since normally in Sage P(0) would 
> create an element of P.   But there's still no coercion:
>
> sage: a.parent().has_coerce_map_from(QQ)
> False
>
> In dimension 1, there is a canonical coercion, but not in higher 
>> dimensions.
>>
>
> Sure, but only for P^1 and A^1, not other curves.  Is there value in 
> having coercions just for those two, for dynamics for example?
> David
>
> On Thursday, September 7, 2017 at 12:17:57 PM UTC-5, David Roe wrote:
>>>
>>> The reason that a==0 returns false is that there is no coercion map from 
>>> QQ to P:
>>>
>>> sage: P.has_coerce_map_from(QQ)
>>> False
>>>
>>> I'm not convinced that there should be a coercion, it's pretty rare that 
>>> a scheme has a natural map from its base ring.
>>> However, it seems like there's also a problem hiding here, probably 
>>> because schemes don't use the coercion model properly:
>>>
>>> sage: P.convert_map_from(QQ)
>>> Traceback (most recent call last)
>>> ...
>>> RuntimeError: BUG in coercion model, no element constructor for >> 'sage.schemes.projective.projective_space.ProjectiveSpace_rational_field_with_category'>
>>>
>>> David
>>>
>>> On Thu, Sep 7, 2017 at 1:11 PM, Ben Hutz  wrote:
>>>
 I'm working on implementing coercion for scheme points and had a 
 question about how comparison is done. As an explicit example consider the 
 following point

 P.= ProjectiveSpace (QQ ,1)
 a=P(0)

 in particular, the integer 0 is coerced into the projective point 
 (0:1). For comparisons it appears that

 a == P(0)  (returns to True)

 calls the _richcmp_() function so uses the coercion framework, but

 a==0  (returns False even though it knows there is a coercion from the 
 integer ring to P)

 is calling something else. There does not appear to be an  __eq__() 
 operator implemented for scheme points, but it does show up in tab 
 completion in the notebook, but can't tell me where the code is from. Is 
 this an artifact of starting to transition the code to python3. Or this 
 just broken somewhere?

 Thanks,
   Ben

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

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

-- 
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] _richcmp_ versus __eq__ for scheme points

[David Roe]

On Thu, Sep 7, 2017 at 1:46 PM, Ben Hutz  wrote:

> Yes, I'm working on the coercion now.
>
> However, isn't a==0 checking coercion from the parent of a to the parent
> of 0. In other words, the homset of rational points on P and QQ.
>

Yes, I got confused by the notation, since normally in Sage P(0) would
create an element of P.   But there's still no coercion:

sage: a.parent().has_coerce_map_from(QQ)
False

In dimension 1, there is a canonical coercion, but not in higher dimensions.
>

Sure, but only for P^1 and A^1, not other curves.  Is there value in having
coercions just for those two, for dynamics for example?
David

On Thursday, September 7, 2017 at 12:17:57 PM UTC-5, David Roe wrote:
>>
>> The reason that a==0 returns false is that there is no coercion map from
>> QQ to P:
>>
>> sage: P.has_coerce_map_from(QQ)
>> False
>>
>> I'm not convinced that there should be a coercion, it's pretty rare that
>> a scheme has a natural map from its base ring.
>> However, it seems like there's also a problem hiding here, probably
>> because schemes don't use the coercion model properly:
>>
>> sage: P.convert_map_from(QQ)
>> Traceback (most recent call last)
>> ...
>> RuntimeError: BUG in coercion model, no element constructor for > 'sage.schemes.projective.projective_space.ProjectiveSpace_
>> rational_field_with_category'>
>>
>> David
>>
>> On Thu, Sep 7, 2017 at 1:11 PM, Ben Hutz  wrote:
>>
>>> I'm working on implementing coercion for scheme points and had a
>>> question about how comparison is done. As an explicit example consider the
>>> following point
>>>
>>> P.= ProjectiveSpace (QQ ,1)
>>> a=P(0)
>>>
>>> in particular, the integer 0 is coerced into the projective point (0:1).
>>> For comparisons it appears that
>>>
>>> a == P(0)  (returns to True)
>>>
>>> calls the _richcmp_() function so uses the coercion framework, but
>>>
>>> a==0  (returns False even though it knows there is a coercion from the
>>> integer ring to P)
>>>
>>> is calling something else. There does not appear to be an  __eq__()
>>> operator implemented for scheme points, but it does show up in tab
>>> completion in the notebook, but can't tell me where the code is from. Is
>>> this an artifact of starting to transition the code to python3. Or this
>>> just broken somewhere?
>>>
>>> Thanks,
>>>   Ben
>>>
>>> --
>>> 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.
>>>
>>
>> --
> 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] _richcmp_ versus __eq__ for scheme points

[Ben Hutz]

Yes, I'm working on the coercion now.

However, isn't a==0 checking coercion from the parent of a to the parent of 
0. In other words, the homset of rational points on P and QQ.

In dimension 1, there is a canonical coercion, but not in higher dimensions.

On Thursday, September 7, 2017 at 12:17:57 PM UTC-5, David Roe wrote:
>
> The reason that a==0 returns false is that there is no coercion map from 
> QQ to P:
>
> sage: P.has_coerce_map_from(QQ)
> False
>
> I'm not convinced that there should be a coercion, it's pretty rare that a 
> scheme has a natural map from its base ring.
> However, it seems like there's also a problem hiding here, probably 
> because schemes don't use the coercion model properly:
>
> sage: P.convert_map_from(QQ)
> Traceback (most recent call last)
> ...
> RuntimeError: BUG in coercion model, no element constructor for  'sage.schemes.projective.projective_space.ProjectiveSpace_rational_field_with_category'>
>
> David
>
> On Thu, Sep 7, 2017 at 1:11 PM, Ben Hutz  
> wrote:
>
>> I'm working on implementing coercion for scheme points and had a question 
>> about how comparison is done. As an explicit example consider the following 
>> point
>>
>> P.= ProjectiveSpace (QQ ,1)
>> a=P(0)
>>
>> in particular, the integer 0 is coerced into the projective point (0:1). 
>> For comparisons it appears that
>>
>> a == P(0)  (returns to True)
>>
>> calls the _richcmp_() function so uses the coercion framework, but
>>
>> a==0  (returns False even though it knows there is a coercion from the 
>> integer ring to P)
>>
>> is calling something else. There does not appear to be an  __eq__() 
>> operator implemented for scheme points, but it does show up in tab 
>> completion in the notebook, but can't tell me where the code is from. Is 
>> this an artifact of starting to transition the code to python3. Or this 
>> just broken somewhere?
>>
>> Thanks,
>>   Ben
>>
>> -- 
>> 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.
>>
>
>

-- 
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: Question about libgap_enter/exit

[Dima Pasechnik]

I would not touch C API to libGAP with a stick, given that it might get changed 
by GAP people soon, I guess.
https://github.com/gap-system/gap/pull/1205

-- 
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] _richcmp_ versus __eq__ for scheme points

[David Roe]

The reason that a==0 returns false is that there is no coercion map from QQ
to P:

sage: P.has_coerce_map_from(QQ)
False

I'm not convinced that there should be a coercion, it's pretty rare that a
scheme has a natural map from its base ring.
However, it seems like there's also a problem hiding here, probably because
schemes don't use the coercion model properly:

sage: P.convert_map_from(QQ)
Traceback (most recent call last)
...
RuntimeError: BUG in coercion model, no element constructor for 

David

On Thu, Sep 7, 2017 at 1:11 PM, Ben Hutz  wrote:

> I'm working on implementing coercion for scheme points and had a question
> about how comparison is done. As an explicit example consider the following
> point
>
> P.= ProjectiveSpace (QQ ,1)
> a=P(0)
>
> in particular, the integer 0 is coerced into the projective point (0:1).
> For comparisons it appears that
>
> a == P(0)  (returns to True)
>
> calls the _richcmp_() function so uses the coercion framework, but
>
> a==0  (returns False even though it knows there is a coercion from the
> integer ring to P)
>
> is calling something else. There does not appear to be an  __eq__()
> operator implemented for scheme points, but it does show up in tab
> completion in the notebook, but can't tell me where the code is from. Is
> this an artifact of starting to transition the code to python3. Or this
> just broken somewhere?
>
> Thanks,
>   Ben
>
> --
> 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] _richcmp_ versus __eq__ for scheme points

[Ben Hutz]

I'm working on implementing coercion for scheme points and had a question 
about how comparison is done. As an explicit example consider the following 
point

P.= ProjectiveSpace (QQ ,1)
a=P(0)

in particular, the integer 0 is coerced into the projective point (0:1). 
For comparisons it appears that

a == P(0)  (returns to True)

calls the _richcmp_() function so uses the coercion framework, but

a==0  (returns False even though it knows there is a coercion from the 
integer ring to P)

is calling something else. There does not appear to be an  __eq__() 
operator implemented for scheme points, but it does show up in tab 
completion in the notebook, but can't tell me where the code is from. Is 
this an artifact of starting to transition the code to python3. Or this 
just broken somewhere?

Thanks,
  Ben

-- 
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: From SageNB to jupyter

[Volker Braun]

You can share worksheets just by uploading them to github, for example:

http://nbviewer.jupyter.org/github/vbraun/torsion_cup_product/blob/master/Y0_cohomology_ring.ipynb
 
https://github.com/vbraun/torsion_cup_product/blob/master/Y0_cohomology_ring.ipynb


On Thursday, September 7, 2017 at 1:56:35 PM UTC+2, Enrique Artal wrote:
>
> And probably the ability of sharing worksheets, I did not find it in 
> jupyter or jupyterhub; of course SMC would be OK but I see only the option 
> of campus accounts or personal docker copies.
>
> El jueves, 7 de septiembre de 2017, 13:32:02 (UTC+2), Jori Mäntysalo 
> escribió:
>>
>> On Thu, 7 Sep 2017, Dima Pasechnik wrote: 
>>
>> > What exactly are you missing from jupyter nb, or jupyter hub, or some 
>> version of SMC 
>> > people managed to get running on their intranets? 
>>
>> I don't actually know; SageNB has just been a working piece of software. 
>>
>> What we need is 
>>
>> - User management from LDAP or Shibboleth, so that everyone with an 
>> account on them can just sign in to Sage. 
>> - Local user accounts too. 
>> - Security, so that a user A can not see worksheets for user B. 
>> - Importing SageNB worksheet to a new system worksheet. 
>>
>> -- 
>> Jori Mäntysalo
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Question about libgap_enter/exit

[Volker Braun]

For the record, using the libgap Python interface (i.e. from 
sage.libs.gap.libgap import libgap) automatically takes care of the 
libgap_enter/exit business. This is only an issue if you want to the libGAP 
C API directly, which is what Simon is presumably asking.

On Thursday, September 7, 2017 at 4:01:47 PM UTC+2, Dima Pasechnik wrote:
>
> Hi Simon,
>
> I don't think anything special like libgap_enter/exit  is needed when 
> calling libgap.* stuff from
> Python or Cython.
> We do quite a few libgap calls in graphs/strongly_regular_db.pyx
> and in graphs/generators/classical_geometries.py
> so this all seems to work just fine.
>
> Do you mean something else?
> Dima
>
> On Thursday, September 7, 2017 at 1:30:29 PM UTC+1, Simon King wrote:
>>
>> My questions are about how/when to use libgap_enter/exit 
>> when calling a libGAP_* function. 
>>
>> First question: What should happen if one doesn't use 
>> libgap_enter/exit? I ask since I called libGAP_EQ without 
>> libgap_enter/exit, but there is no crash and it just works. 
>> So, can one do without it, in some cases? 
>>
>> Second question: What should one do if one has a loop 
>> containing both several python and libGAP_* calls? Put 
>> libgap_enter/exit around each individual libGAP_* call? 
>> Or is it possible to have Python calls (and a whole 
>> "for" loop) between enter and exit? 
>>
>> 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: Question about libgap_enter/exit

[Volker Braun]

First question: The GAP garbage collector might delete objects, or it might 
move existing objects around in memory (it is a compacting garbage 
collector). If your code contains C pointers to GAP objects, bad things 
will happen after that. Not every libGAP_* function can invoke the garbage 
collector, and for those that do it will not always run a collection cycle. 
But there are no documented guarantees that any particular libGAP_* 
function does not run garbage collection, or may be changed to run garbage 
collection in the future.

Second question: Move the libgap_enter/exit outside of the loop, assuming 
that the python functions don't themselves call libgap. If they do, you 
will get a  "RuntimeError: Entered a critical block twice". In that case, 
move the libgap_enter/exit into the loop as far as necessary to have 
non-overlapping libgap_enter/exit blocks.



Snip from docs:

Using the libGAP C library from Cython
==

The lower-case ``libgap_foobar`` functions are ones that we added to
make the libGAP C shared library. The ``libGAP_foobar`` methods are
the original GAP methods simply prefixed with the string
``libGAP_``. The latter were originally not designed to be in a
library, so some care needs to be taken to call them.

In particular, you must call ``libgap_mark_stack_bottom()`` in every
function that calls into the libGAP C functions. The reason is that
the GAP memory manager will automatically keep objects alive that are
referenced in local (stack-allocated) variables. While convenient,
this requires to look through the stack to find anything that looks
like an address to a memory bag. But this requires vigilance against
the following pattern::

cdef f()
  libgap_mark_stack_bottom()
  libGAP_function()

cdef g()
  libgap_mark_stack_bottom();
  f()#  f() changed the stack bottom marker
  libGAP_function()  #  boom

The solution is to re-order ``g()`` to first call ``f()``. In order to
catch this error, it is recommended that you wrap calls into libGAP in
``libgap_enter`` / ``libgap_exit`` blocks and not call
``libgap_mark_stack_bottom`` manually. So instead, always write

cdef f()
  libgap_enter()
  libGAP_function()
  libgap_exit()

cdef g()
  f()
  libgap_enter()
  libGAP_function()
  libgap_exit()

If you accidentally call ``libgap_enter()`` twice then an error
message is printed to help you debug this::

sage: from sage.libs.gap.util import error_enter_libgap_block_twice
sage: error_enter_libgap_block_twice()
Traceback (most recent call last):
...
RuntimeError: Entered a critical block twice


On Thursday, September 7, 2017 at 2:30:29 PM UTC+2, Simon King wrote:
>
> Hi! 
>
> My questions are about how/when to use libgap_enter/exit 
> when calling a libGAP_* function. 
>
> First question: What should happen if one doesn't use 
> libgap_enter/exit? I ask since I called libGAP_EQ without 
> libgap_enter/exit, but there is no crash and it just works. 
> So, can one do without it, in some cases? 
>
> Second question: What should one do if one has a loop 
> containing both several python and libGAP_* calls? Put 
> libgap_enter/exit around each individual libGAP_* call? 
> Or is it possible to have Python calls (and a whole 
> "for" loop) between enter and exit? 
>
> 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: Question about libgap_enter/exit

[Nils Bruin]

On Thursday, September 7, 2017 at 7:01:47 AM UTC-7, Dima Pasechnik wrote:
>
> Hi Simon,
>
> I don't think anything special like libgap_enter/exit  is needed when 
> calling libgap.* stuff from
> Python or Cython.
> We do quite a few libgap calls in graphs/strongly_regular_db.pyx
> and in graphs/generators/classical_geometries.py
> so this all seems to work just fine.
>
> Do you mean something else?
> Dima
>

Reading the documentation of sage.lib.gap.libgap, it seems that one of the 
functions of libgap_enter is to mark which part of the C stack should be 
searched for pointers to objects that should be considered live by the gap 
garbage collector. So it would seem to be that as long as you make sure 
that all your libgap objects have a pointer to them in the libgap heap you 
might be fine, but otherwise you might end up with unpredictable failures 
(when an object only kept alive by being referenced by a local variable 
undergoes garbage collection). So I wouldn't be too encouraged by the 
observation that all seems to work just fine.

-- 
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: From SageNB to jupyter

[Dima Pasechnik]

did you see this:
https://benjamin-hackl.at/2016/01/16/jupyterhub-with-sagemath-kernel/

It seems that all of the requirements you list are there...

On Thursday, September 7, 2017 at 12:32:02 PM UTC+1, Jori Mäntysalo wrote:
>
> On Thu, 7 Sep 2017, Dima Pasechnik wrote: 
>
> > What exactly are you missing from jupyter nb, or jupyter hub, or some 
> version of SMC 
> > people managed to get running on their intranets? 
>
> I don't actually know; SageNB has just been a working piece of software. 
>
> What we need is 
>
> - User management from LDAP or Shibboleth, so that everyone with an 
> account on them can just sign in to Sage. 
> - Local user accounts too. 
> - Security, so that a user A can not see worksheets for user B. 
> - Importing SageNB worksheet to a new system worksheet. 
>
> -- 
> Jori Mäntysalo

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Question about libgap_enter/exit

[Dima Pasechnik]

Hi Simon,

I don't think anything special like libgap_enter/exit  is needed when 
calling libgap.* stuff from
Python or Cython.
We do quite a few libgap calls in graphs/strongly_regular_db.pyx
and in graphs/generators/classical_geometries.py
so this all seems to work just fine.

Do you mean something else?
Dima

On Thursday, September 7, 2017 at 1:30:29 PM UTC+1, Simon King wrote:
>
> My questions are about how/when to use libgap_enter/exit 
> when calling a libGAP_* function. 
>
> First question: What should happen if one doesn't use 
> libgap_enter/exit? I ask since I called libGAP_EQ without 
> libgap_enter/exit, but there is no crash and it just works. 
> So, can one do without it, in some cases? 
>
> Second question: What should one do if one has a loop 
> containing both several python and libGAP_* calls? Put 
> libgap_enter/exit around each individual libGAP_* call? 
> Or is it possible to have Python calls (and a whole 
> "for" loop) between enter and exit? 
>
> 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] Question about libgap_enter/exit

[Simon King]

Hi!

My questions are about how/when to use libgap_enter/exit
when calling a libGAP_* function.

First question: What should happen if one doesn't use
libgap_enter/exit? I ask since I called libGAP_EQ without
libgap_enter/exit, but there is no crash and it just works.
So, can one do without it, in some cases?

Second question: What should one do if one has a loop
containing both several python and libGAP_* calls? Put
libgap_enter/exit around each individual libGAP_* call?
Or is it possible to have Python calls (and a whole
"for" loop) between enter and exit?

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: From SageNB to jupyter

[Enrique Artal]

And probably the ability of sharing worksheets, I did not find it in 
jupyter or jupyterhub; of course SMC would be OK but I see only the option 
of campus accounts or personal docker copies.

El jueves, 7 de septiembre de 2017, 13:32:02 (UTC+2), Jori Mäntysalo 
escribió:
>
> On Thu, 7 Sep 2017, Dima Pasechnik wrote: 
>
> > What exactly are you missing from jupyter nb, or jupyter hub, or some 
> version of SMC 
> > people managed to get running on their intranets? 
>
> I don't actually know; SageNB has just been a working piece of software. 
>
> What we need is 
>
> - User management from LDAP or Shibboleth, so that everyone with an 
> account on them can just sign in to Sage. 
> - Local user accounts too. 
> - Security, so that a user A can not see worksheets for user B. 
> - Importing SageNB worksheet to a new system worksheet. 
>
> -- 
> Jori Mäntysalo

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: From SageNB to jupyter

[Jori Mäntysalo]

On Thu, 7 Sep 2017, Dima Pasechnik wrote:


What exactly are you missing from jupyter nb, or jupyter hub, or some version 
of SMC
people managed to get running on their intranets?


I don't actually know; SageNB has just been a working piece of software.

What we need is

- User management from LDAP or Shibboleth, so that everyone with an 
account on them can just sign in to Sage.

- Local user accounts too.
- Security, so that a user A can not see worksheets for user B.
- Importing SageNB worksheet to a new system worksheet.

--
Jori Mäntysalo

Re: [sage-devel] Re: SageNB, publishing and error 500

[Dima Pasechnik]

Jori, 
sorry for crying out loud, but noone is going to work on sagenb, besides 
maybe you, I think.
Messing around with 11 years old web technology is very hard indeed.

What exactly are you missing from jupyter nb, or jupyter hub, or some 
version of SMC
people managed to get running on their intranets?

Dima

PS. Reverting to an older sagenb should work, via reverting the 
corresponding commits, etc...



On Thursday, September 7, 2017 at 6:24:07 AM UTC+1, Jori Mäntysalo wrote:
>
> On Wed, 6 Sep 2017, kcrisman wrote: 
>
> > I suspect perhaps 
> https://github.com/sagemath/sagenb/commit/9dd5c0f8c783de7cb0ae21c9f445ab8260b5a0ac
>  
> is the culprit, and 
> > put something on #432 to the author of that change.  It seems like the 
> kind of thing that might happen when a module is 
> > updated, as that change did, though I could be barking up the wrong tree 
> too.  Thanks for pursuing this. 
>
> Another question: Can I downgrade SageNB when waiting correction for this 
> bug? Is so, how? 
>
> -- 
> Jori Mäntysalo

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] hash issue in python3 experimental branch

[Erik Bray]

On Thu, Sep 7, 2017 at 11:06 AM, Jeroen Demeyer  wrote:
> On 2017-09-06 17:24, Erik Bray wrote:
>>
>> Interpreting
>> "str" as "bytes" is the only way it can be if language_level=2.
>
>
> I think you are misunderstanding. You didn't post the complete C code
> generated by Cython:
>
>   __pyx_t_4 = __Pyx_PyBytes_FromString(__pyx_v_s); if (unlikely(!__pyx_t_4))
> __PYX_ERR(0, 2076, __pyx_L1_error)
>   __Pyx_GOTREF(__pyx_t_4);
>   __pyx_t_3 = PyTuple_New(1); if (unlikely(!__pyx_t_3)) __PYX_ERR(0, 2076,
> __pyx_L1_error)
>   __Pyx_GOTREF(__pyx_t_3);
>   __Pyx_GIVEREF(__pyx_t_4);
>   PyTuple_SET_ITEM(__pyx_t_3, 0, __pyx_t_4);
>   __pyx_t_4 = 0;
>   __pyx_t_4 = __Pyx_PyObject_Call(((PyObject *)(_Type)), __pyx_t_3,
> NULL); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 2076, __pyx_L1_error)
>   __Pyx_GOTREF(__pyx_t_4);
>   __Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
>   __pyx_v_k = __pyx_t_4;
>   __pyx_t_4 = 0;
>
> So, what this does is to interpret a char* as bytes, because a char* really
> is just bytes. And then it calls str() on the result. So you get str(b"1").
>
> I don't think that this has anything to do with the language_level.

Ah, you're right, I didn't see that I just saw the PyBytes_FromString.
So it least "str" is really treated as "str" on Python 3. That's less
terribly confusing than I thought.  I'd still like to play around with
language_level=3 more though.  It still makes for a more consistent
porting experience (e.g. string literals are unicode on Python 3).

-- 
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] Upgrade PARI to git master

[Jeroen Demeyer]

Hello all,

In order to keep distributions happy, I managed to do the PARI upgrade 
in such a way that compatibility with PARI-2.9.3 will remain.


I specifically created a new ticket 
https://trac.sagemath.org/ticket/23796 for this. After this ticket, the 
only doctest failures with PARI master are in


https://git.sagemath.org/sage.git/commit/?id=85f51b48a14caa15b3c928aab0fd8e57374ed482

--
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-packaging] Re: [sage-devel] Upgrade PARI to git master

[Jeroen Demeyer]

On 2017-09-06 17:28, Ximin Luo wrote:

If there is no "normalise" function for that context, perhaps there is at least 
a method to check that two objects represent the same mathematical group, so:


I sort of agree in principle, but this is easier said than done. In many 
cases, the mathematics is hard (certainly too hard for me to understand 
what is going on). Second, in some cases, heuristic algorithms are used 
which may work with one version but fail with a different version. Since 
the algorithms are heuristic, this should not be considered a bug.


Then there is also the issue that doctests serve both as documentation 
and tests. So we should not forget that the documentation must remain 
understandable.


--
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] hash issue in python3 experimental branch

[Jeroen Demeyer]

On 2017-09-06 17:24, Erik Bray wrote:

Interpreting
"str" as "bytes" is the only way it can be if language_level=2.


I think you are misunderstanding. You didn't post the complete C code 
generated by Cython:


  __pyx_t_4 = __Pyx_PyBytes_FromString(__pyx_v_s); if 
(unlikely(!__pyx_t_4)) __PYX_ERR(0, 2076, __pyx_L1_error)

  __Pyx_GOTREF(__pyx_t_4);
  __pyx_t_3 = PyTuple_New(1); if (unlikely(!__pyx_t_3)) __PYX_ERR(0, 
2076, __pyx_L1_error)

  __Pyx_GOTREF(__pyx_t_3);
  __Pyx_GIVEREF(__pyx_t_4);
  PyTuple_SET_ITEM(__pyx_t_3, 0, __pyx_t_4);
  __pyx_t_4 = 0;
  __pyx_t_4 = __Pyx_PyObject_Call(((PyObject *)(_Type)), 
__pyx_t_3, NULL); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 2076, 
__pyx_L1_error)

  __Pyx_GOTREF(__pyx_t_4);
  __Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
  __pyx_v_k = __pyx_t_4;
  __pyx_t_4 = 0;

So, what this does is to interpret a char* as bytes, because a char* 
really is just bytes. And then it calls str() on the result. So you get 
str(b"1").


I don't think that this has anything to do with the language_level.

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