Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

[Travis Scrimshaw]

On Wednesday, November 2, 2016 at 7:59:42 PM UTC-5, Luca De Feo wrote:
>
> > It is not a bug, but a by product of wanted (with documentation) of the 
> > UniqueRepresentation and the coercion system in Sage. More below. 
>
> This is a bug. 
>
> The fact that it is a consequence of wanted and documented behaviour 
> just shows that the wanted behaviour was badly designed (regardless of 
> how great and useful it is). 
>
> I'm getting dangerously close to the realm of bikeshedding, but bad design 
or (very) subtle behavior is not a bug. A bug is incorrect or unintended 
results.

That being said, I'm not opposed to removing the UniqueRepresentation, but 
I'd like to hear why this was originally put in place. In many ways, what 
you're doing involves additional subtleties due to the coercion framework 
being involved behind the scenes (i.e., as far as equality is concerned, 1 
in ZZ == 1 in GF(13)).

Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L)) 
as you don't need the set of all subsets to be a parent.

Best,
Travis

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

Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

[Jori Mäntysalo]

On Wed, 2 Nov 2016, Johan S. H. Rosenkilde wrote:


for S in Subsets(GF(13).list(), 5):
   if sum(S) == 1:
  print "Monkey"

This code works as expected and prints monkeys galore when evaluating it
in a Sage shell. Now restart Sage and call the following line before
calling the above snippet:

a = list(Subsets(range(13), 5))

And suddenly the first code snippet will never print anything.

Tell me that's not a bug!


To me it seems to be worst than a bug: intentionally broken design. 
Something like this is almost impossible to teach in classroom.


--
Jori Mäntysalo

Re: [sage-devel] Building Sage 7.4 final release on OS X El Capitan

[Francois Bissey]

It is probably not limited to El Capitan it would have been useful to get some 
more details.

Francois

On 3/11/2016, at 2:07 PM, Paul Masson 
> wrote:

I had difficulty over the last couple days getting Sage 7.4 to build. Something 
like ten packages would fail to build, but not always the same ones. It finally 
occurred to me that there might be some race condition going on. Sure enough, 
running make without multiple jobs solved the problem.

Since this is the first time I've encountered this, how common is it on OS X? I 
assume I won't have the problem again with this release, but is it something 
that can be fixed? Or is the only solution a slow make process?


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

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

-- 
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] Building Sage 7.4 final release on OS X El Capitan

[Paul Masson]

I had difficulty over the last couple days getting Sage 7.4 to build. 
Something like ten packages would fail to build, but not always the same 
ones. It finally occurred to me that there might be some race condition 
going on. Sure enough, running make without multiple jobs solved the 
problem.

Since this is the first time I've encountered this, how common is it on OS 
X? I assume I won't have the problem again with this release, but is it 
something that can be fixed? Or is the only solution a slow make process?

-- 
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: Bug in caching mechanism of FiniteEnumeratedSet

[Luca De Feo]

> It is not a bug, but a by product of wanted (with documentation) of the
> UniqueRepresentation and the coercion system in Sage. More below.

This is a bug.

The fact that it is a consequence of wanted and documented behaviour
just shows that the wanted behaviour was badly designed (regardless of
how great and useful it is).

Unpredictable behaviour that can only be understood by someone having
as deep a knowledge of Sage internals as Travis has cannot possibly be
a "feature".

Of course, I have no clue what the fix would be.

Luca

-- 
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: Memory leak coming from MixedIntegerLinearProgram ???

[Saul Schleimer]

Dear Sébastien - 

>
> def get_polytope(M):
> q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
> w = q.new_variable(real = True, nonnegative = True)
> for v in M.rows():
> q.add_constraint( dot_prod(v, w) == 0 )
> return None
>

This also leaks.
 

> def get_polytope(M):
> q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
> w = q.new_variable(real = True, nonnegative = True)
>

This doesn't. 

s.

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

Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

[Travis Scrimshaw]

Hey Johan,


> From my point of view, this can only be considered a bug: extremely 
> surprising behaviour leading to subtle problems in user code (my code). 
> Possibly, the bug is higher up than FiniteEnumeratedSets, though. 
>

It is not a bug, but a by product of wanted (with documentation) of the 
UniqueRepresentation and the coercion system in Sage. More below.

>
> I'll explain: This came about when using Subsets. Basically, I'm doing 
> something like: 
>
> for S in Subsets(GF(13).list(), 5): 
> if sum(S) == 1: 
>print "Monkey" 
>
> This code works as expected and prints monkeys galore when evaluating it 
> in a Sage shell. Now restart Sage and call the following line before 
> calling the above snippet: 
>
> a = list(Subsets(range(13), 5)) 
>
> And suddenly the first code snippet will never print anything. 
>
> Tell me that's not a bug! 
>
>The issue here is that it takes the input and converts it to a 
FiniteEnumeratdSet, which has unique representation behavior. Sage can't 
tell apart, e.g., 1 in ZZ (or the int) from 1 in GF(13) due to coercion 
when doing equality (and they have the same hash). So as far as Sage is 
concerned, it is the same object, and hence, already constructed. I don't 
see a reason a priori to keep the unique representation behavior, but 
perhaps Nicolas knows why this was decided? Until we change that design 
decision, this would be a "feature" and not a bug.

John's workaround is probably the better methodology overall too.

Best,
Travis

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

Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

[John H Palmieri]

On Wednesday, November 2, 2016 at 2:02:18 PM UTC-7, Johan S. H. Rosenkilde 
wrote:
>
> Hi Travis, 
>
> From my point of view, this can only be considered a bug: extremely 
> surprising behaviour leading to subtle problems in user code (my code). 
> Possibly, the bug is higher up than FiniteEnumeratedSets, though. 
>
> I'll explain: This came about when using Subsets. Basically, I'm doing 
> something like: 
>
> for S in Subsets(GF(13).list(), 5): 
> if sum(S) == 1: 
>print "Monkey" 
>

This may or may not be a bug; I'll let others answer that. For a 
workaround, use

   for S in Subsets(GF(13), 5): ...  -- don't use GF(13).list(), just use 
GF(13)

I don't know exactly how FiniteEnumerateSet enters into things:

sage: FiniteEnumeratedSet(GF(13)) == FiniteEnumeratedSet(range(13))
True
sage: Subsets(GF(13)) == Subsets(range(13))
False
sage: Subsets(GF(13).list()) == Subsets(range(13))
True

-- 
John

 

>
> This code works as expected and prints monkeys galore when evaluating it 
> in a Sage shell. Now restart Sage and call the following line before 
> calling the above snippet: 
>
> a = list(Subsets(range(13), 5)) 
>
> And suddenly the first code snippet will never print anything. 
>
> Tell me that's not a bug! 
>
> Best, 
> Johan 
>   
> Travis Scrimshaw writes: 
>
> > Hey Johan, 
> >The problem is that we want finite enumerated sets to be hashable, 
> > picklable, and unique as they get used as keys for 
> CombinatorialFreeModule, 
> > among other things, and it is implemented using UniqueRepresentation. 
> The 
> > problem is that 1 = 1 with the same hash value whether in ZZ or GF(97), 
> so 
> > the enumerated set is the same. However, I would not regard this as a 
> bug, 
> > but a "feature" of the unique behavior and the coercion framework. 
> > 
> >My guess is that you are treating the finite enumerated set as a 
> tuple, 
> > and so I would suggest that you just used tuples (which has far less 
> > overhead). 
> > 
> > Best, 
> > Travis 
> > 
> > 
> > On Wednesday, November 2, 2016 at 12:45:21 PM UTC-5, Johan S. H. 
> Rosenkilde 
> > wrote: 
> >> 
> >> Hi all, 
> >> 
> >> I just tracked down a nasty bug completely messing up my experiments to 
> >> this internal caching mechanism. In a clean Sage type: 
> >> 
> >> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]) 
> >> sage: type(E[0]) 
> >>  
> >> 
> >> Restart Sage and type instead 
> >> 
> >> sage: E = FiniteEnumeratedSet([1,2,3,4,5,6]) 
> >> sage: type(E[0]) 
> >>  
> >> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); 
> >> type(E[0]) 
> >>  
> >> 
> >> Many variations of this theme seem possible. 
> >> 
> >> This was Sage 7.5.beta0. 
> >> 
> >> Someone knowledgeable can help find the cause and possible other places 
> >> the bug could appear? 
> >> 
> >> Best, 
> >> Johan 
> >> 
>
>
> -- 
>

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

Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

[Johan S . H . Rosenkilde]

Hi Travis,

>From my point of view, this can only be considered a bug: extremely
surprising behaviour leading to subtle problems in user code (my code).
Possibly, the bug is higher up than FiniteEnumeratedSets, though.

I'll explain: This came about when using Subsets. Basically, I'm doing
something like:

for S in Subsets(GF(13).list(), 5):
if sum(S) == 1:
   print "Monkey"

This code works as expected and prints monkeys galore when evaluating it
in a Sage shell. Now restart Sage and call the following line before
calling the above snippet:

a = list(Subsets(range(13), 5))

And suddenly the first code snippet will never print anything.

Tell me that's not a bug!

Best,
Johan
 
Travis Scrimshaw writes:

> Hey Johan,
>The problem is that we want finite enumerated sets to be hashable, 
> picklable, and unique as they get used as keys for CombinatorialFreeModule, 
> among other things, and it is implemented using UniqueRepresentation. The 
> problem is that 1 = 1 with the same hash value whether in ZZ or GF(97), so 
> the enumerated set is the same. However, I would not regard this as a bug, 
> but a "feature" of the unique behavior and the coercion framework.
>
>My guess is that you are treating the finite enumerated set as a tuple, 
> and so I would suggest that you just used tuples (which has far less 
> overhead).
>
> Best,
> Travis
>
>
> On Wednesday, November 2, 2016 at 12:45:21 PM UTC-5, Johan S. H. Rosenkilde 
> wrote:
>>
>> Hi all, 
>>
>> I just tracked down a nasty bug completely messing up my experiments to 
>> this internal caching mechanism. In a clean Sage type: 
>>
>> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]) 
>> sage: type(E[0]) 
>>  
>>
>> Restart Sage and type instead 
>>
>> sage: E = FiniteEnumeratedSet([1,2,3,4,5,6]) 
>> sage: type(E[0]) 
>>  
>> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); 
>> type(E[0]) 
>>  
>>
>> Many variations of this theme seem possible. 
>>
>> This was Sage 7.5.beta0. 
>>
>> Someone knowledgeable can help find the cause and possible other places 
>> the bug could appear? 
>>
>> Best, 
>> Johan 
>>


-- 

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

[sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

[Travis Scrimshaw]

Hey Johan,
   The problem is that we want finite enumerated sets to be hashable, 
picklable, and unique as they get used as keys for CombinatorialFreeModule, 
among other things, and it is implemented using UniqueRepresentation. The 
problem is that 1 = 1 with the same hash value whether in ZZ or GF(97), so 
the enumerated set is the same. However, I would not regard this as a bug, 
but a "feature" of the unique behavior and the coercion framework.

   My guess is that you are treating the finite enumerated set as a tuple, 
and so I would suggest that you just used tuples (which has far less 
overhead).

Best,
Travis


On Wednesday, November 2, 2016 at 12:45:21 PM UTC-5, Johan S. H. Rosenkilde 
wrote:
>
> Hi all, 
>
> I just tracked down a nasty bug completely messing up my experiments to 
> this internal caching mechanism. In a clean Sage type: 
>
> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]) 
> sage: type(E[0]) 
>  
>
> Restart Sage and type instead 
>
> sage: E = FiniteEnumeratedSet([1,2,3,4,5,6]) 
> sage: type(E[0]) 
>  
> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); 
> type(E[0]) 
>  
>
> Many variations of this theme seem possible. 
>
> This was Sage 7.5.beta0. 
>
> Someone knowledgeable can help find the cause and possible other places 
> the bug could appear? 
>
> Best, 
> Johan 
>

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

[sage-devel] Re: [sage-support] Re: Symbolic expressions assumptions and simplify in parallel

[Fedor Sumkin]

Hi Nils,

Thanks for suggestion for resolving this issue via process-based
parallelism, this definitely will do the trick!

On Wed, Nov 2, 2016 at 6:16 AM, Nils Bruin  wrote:

> On Tuesday, November 1, 2016 at 1:55:00 PM UTC-4, Fedor Sumkin wrote:
>>
>> Hi all,
>>
>> Faced with a quite sad sage bug which arises with interval based
>> assumptions and  full_simplify()/simplify() in called in parallel.
>>
>>
> Maxima is not threadsafe at all, and the sage design uses a single
> (library) sage session, so is not threadsafe (and indeed, things like
> global parent structures and global coercion graph structures means that
> sage in general is not designed with thread-safety in mind).
>
> Using a little coarser-grained process-based parallellism should be fine,
> and is the approach I think has been used to get parallellism  in sage by
> most people who've tried.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-supp...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-support.
> 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] Caching bug in FiniteEnumeratedSet

[santaphile]

I just tracked down a nasty bug completely messing up my math experiments 
to the following internal caching mechanism. In a clean Sage type:

sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); 
type(E[0])


Restart Sage and type instead

sage: E = FiniteEnumeratedSet([1,2,3,4,5,6])
sage: type(E[0])

sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); 
type(E[0])


Many variations of this theme seem possible.

This was Sage 7.5.beta0.

Can someone knowledgeable help find the root cause and possible other 
places the bug could appear?

Best,
Johan

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

[sage-devel] Bug in caching mechanism of FiniteEnumeratedSet

[Johan S . H . Rosenkilde]

Hi all,

I just tracked down a nasty bug completely messing up my experiments to
this internal caching mechanism. In a clean Sage type:

sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]])
sage: type(E[0])


Restart Sage and type instead

sage: E = FiniteEnumeratedSet([1,2,3,4,5,6])
sage: type(E[0])

sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); type(E[0])


Many variations of this theme seem possible.

This was Sage 7.5.beta0.

Someone knowledgeable can help find the cause and possible other places
the bug could appear?

Best,
Johan

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

[sage-devel] Re: Memory leak coming from MixedIntegerLinearProgram ???

[Sébastien Labbé]

Can you check if the following also leaks?

def get_polytope(M):
q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
w = q.new_variable(real = True, nonnegative = True)
for v in M.rows():
q.add_constraint( dot_prod(v, w) == 0 )
return None

def get_polytope(M):
q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
w = q.new_variable(real = True, nonnegative = True)

so that we can know if the problem is in "q.polyhedron()" or in 
"q.add_constraint(...)".

-- 
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] Singular "share" files

[Jean-Pierre Flori]

Dear all,

We currently repackage singular so merge the source code and help files 
into a single archive (and renaming directories).
Should we stop doing so by creating a "singular_share" package for the 
latter files?

Best,
JPF

-- 
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: Memory leak coming from MixedIntegerLinearProgram ???

[Saul Schleimer]

It seems that:

'CVXOPT', 'PPL', 'GLPK' don't leak 
'COIN' does
'CPLEX', 'Gurobi' are not yet installed on my machine

best,

saul

On Wednesday, November 2, 2016 at 5:23:27 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Wednesday, November 2, 2016 at 11:22:43 AM UTC, Sébastien Labbé wrote:
>>
>> I get: "ImportError: No module named coin_backend".
>>
>> Without solver='Coin', I get:
>>
>> sage: get_memory_usage()
>> 316.6015625
>> sage: fill_memory(2000)
>> sage: get_memory_usage()
>> 341.578125
>> sage: fill_memory(2000)
>> sage: get_memory_usage()
>> 341.578125
>> sage: fill_memory(2000)
>> sage: get_memory_usage()
>> 341.578125
>> sage: fill_memory(2000)
>> sage: get_memory_usage()
>> 341.578125
>> sage: fill_memory(2000)
>> sage: get_memory_usage()
>> 341.578125
>>
>>
> Good catch, so this leak is apparently in coin backend.
> It's interesting to try all the backends for this...
>  
>

-- 
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: R 3.3.1 depends on a SSL/TLS implementation

[Emmanuel Charpentier]

Dear Jean-Pierre,

Le mercredi 2 novembre 2016 11:40:30 UTC+1, Jean-Pierre Flori a écrit :
>
> I would say we even have a shorter-time solution: close the tickets for 
> including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking)
>

?? What do you mean ?
 

> and updating R (modulo adding a 6-line patch to not check for https 
> support,
>

I'm not really comfortable with that, but, for now, it doesn't totally 
cripple R (some repositories are still http-reachable). Nevertheless, we 
still have to depend on libcurl but with no version check.
 

> note that most of the time https will be supported anyway).
>

Okay. But that still implies accepting xz an pcre either as Sage 
dependencies or  as standard packages.

OTOH, depending on R and R library automatically ensures that the run-time 
dependencies are present...

Which ?

--
Emmanuel Charpentier


>
> On Wednesday, November 2, 2016 at 11:19:52 AM UTC+1, Emmanuel Charpentier 
> wrote:
>>
>> So far, the only plan I can propose which is consistent with the various 
>> points that have been stated  is : 
>>
>> I) short-term workaround : add a dependance for Sage, by :
>> a) depending on libcurl and its development files, or
>> b) depending on a systemwide R + its development files
>> II) solve current issues with the pexpexct interface (e. g. graphs in 
>> Jupyter...) and its documentation (e. g. use of RElement to retrieve an R 
>> object).
>>
>> This solves the immediate problem at hand (which is urgent : more and 
>> more R packages won't install on R 3.2.x). But since some have pointed out 
>> the inefficiencies of the current R interface and its documentation, we 
>> could :
>>
>> III) Build some steamlined interface ("newR") to R (via rpy2 ? via 
>> IRkernel ?). Test it
>> IV) Based on newR, build a reasonable wrapper emulating 
>> feature-for-feature the current pexpect interface. Test it.
>> V) replace the pexpect interface by the wrapper.
>>
>> This is not urgent, and can be discussed further.
>>
>> Now, for Ia vs Ib :
>>
>>- Both require modifying the installation documentation and the main 
>>configure file. These do not seem to be large modifications (I just need 
>> to 
>>learn a modicum of autotools in order to do this correctly).
>>- Both allow the current pexpect to remain a standard part of Sage.
>>
>> Ib seems to have two slight advantages on Ia :
>>
>>- R and its development files seem to be well-packaged on the few 
>>(Linux) distributions I have checked, as well as Cygwin, and probably are 
>>elsewhere (other GNU/Linuxes, assorted Unices). The Macintosh case, as 
>>usual, bears a large question mark...
>>- Paradoxically, it is probably easier for an end-user to check this 
>>requirement than to check the suitability of his libcurl...
>>- Ib does not require xz and pcre to become standard packages.
>>
>> Could we have a vote on the I-II block (which *is* urgent), and on the Ia 
>> vs Ib alternative ?
>>
>> HTH,
>>
>> --
>> Emmanuel Charpentier
>>
>> Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit :
>>>
>>> Hi all,
>>>
>>> The latest R versions depends on libcurl and actually more than that: on 
>>> a libcurl with https support.
>>> So we might want to build our own libcurl with https support (see 
>>> #21767) but we then need an SSL/TLS implementation which Sage curretnly 
>>> provides only optionally through openSSL because of license issues so we 
>>> can:
>>> [1] either make R depend on libcurl depend on openssl and they all 
>>> become optional,
>>> [2] or make R depend on libcurl and make them standard and add an 
>>> SSL/TLS implementation and its development headers a prereq,
>>> [3] or make libcurl with https support (and development headers) a 
>>> prereq, which basically means adding an SSL/TLS implementation as a prereq 
>>> as well,
>>> [4] or make R a prereq,
>>> [5] or drop R support,
>>> [6] or patch R not to use curl,
>>> [7] or patch R to use curl but without https support,
>>> [8] or wait until the end of times,
>>> [9] or a mix of all of this,
>>> [10] or do something else.
>>>
>>> What do you think?
>>>
>>> Best,
>>> JPF
>>>
>>

-- 
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: Issue with figures in doc.sagemath.org

[Harald Schilly]

Thanks for reporting that, I'll check what's going on. It's probably some 
issue with symlinks ...

-- h

-- 
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] Impossible to push to trac server !

[William Stein]

On Wed, Nov 2, 2016 at 4:40 AM, 'Paul Mercat' via sage-devel
 wrote:
> Hello,
>
> When I try to push my work on the trac server using the command
> $git trac push
> I get the following error :
>
> git_trac.git_error.GitError: git returned with non-zero exit code (128) when
> executing "git push trac HEAD:refs/heads/u/mercatp/b-adic"
>
> STDERR: @@@
>
> STDERR: @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
>
> STDERR: @@@
>
> STDERR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>
> STDERR: Someone could be eavesdropping on you right now
> (man-in-the-middle attack)!
>
> STDERR: It is also possible that a host key has just been changed.
>
> STDERR: The fingerprint for the ECDSA key sent by the remote host is
>
> STDERR: SHA256:4Op/q3b5792x+F1lHSKRi5UIORAPDlIFVA5cUq9YVXI.
>
> STDERR: Please contact your system administrator.
>
> STDERR: Add correct host key in /Users/mercatp/.ssh/known_hosts to get
> rid of this message.
>
> STDERR: Offending ECDSA key in /Users/mercatp/.ssh/known_hosts:1
>
> STDERR: ECDSA host key for trac.sagemath.org has changed and you have
> requested strict checking.
>
> STDERR: Host key verification failed.
>
> STDERR: fatal: Could not read from remote repository.
>
> STDERR:
>
> STDERR: Please make sure you have the correct access rights
>
> STDERR: and the repository exists.
>
>
> I don't understand where is the problem. My public ssh is on the trac
> server, the server is in the list of know hosts in my computer.
>
>
> When I try the command
>
> $sudo git trac push
>
> I get another error :
>
> git_trac.git_error.GitError: git returned with non-zero exit code (128) when
> executing "git push trac HEAD:refs/heads/u/mercatp/b-adic"
>
> STDERR: Permission denied (publickey).
>
> STDERR: fatal: Could not read from remote repository.
>
> STDERR:
>
> STDERR: Please make sure you have the correct access rights
>
> STDERR: and the repository exists.
>
>
> I previously pushed some commits before with this computer. I don't
> understand why it doesn't work anymore.

The ssh keys changed when I quadrupled the capacity of the machine
recently.  Reset your keys.

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



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

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

[sage-devel] Re: Memory leak coming from MixedIntegerLinearProgram ???

[Dima Pasechnik]

On Wednesday, November 2, 2016 at 11:22:43 AM UTC, Sébastien Labbé wrote:
>
> I get: "ImportError: No module named coin_backend".
>
> Without solver='Coin', I get:
>
> sage: get_memory_usage()
> 316.6015625
> sage: fill_memory(2000)
> sage: get_memory_usage()
> 341.578125
> sage: fill_memory(2000)
> sage: get_memory_usage()
> 341.578125
> sage: fill_memory(2000)
> sage: get_memory_usage()
> 341.578125
> sage: fill_memory(2000)
> sage: get_memory_usage()
> 341.578125
> sage: fill_memory(2000)
> sage: get_memory_usage()
> 341.578125
>
>
Good catch, so this leak is apparently in coin backend.
It's interesting to try all the backends for this...
 

-- 
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] Impossible to push to trac server !

['Paul Mercat' via sage-devel]

Hello,

When I try to push my work on the trac server using the command
$git trac push
I get the following error :

git_trac.git_error.GitError: git returned with non-zero exit code (128) 
when executing "git push trac HEAD:refs/heads/u/mercatp/b-adic"

STDERR: @@@

STDERR: @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

STDERR: @@@

STDERR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

STDERR: Someone could be eavesdropping on you right now 
(man-in-the-middle attack)!

STDERR: It is also possible that a host key has just been changed.

STDERR: The fingerprint for the ECDSA key sent by the remote host is

STDERR: SHA256:4Op/q3b5792x+F1lHSKRi5UIORAPDlIFVA5cUq9YVXI.

STDERR: Please contact your system administrator.

STDERR: Add correct host key in /Users/mercatp/.ssh/known_hosts to get 
rid of this message.

STDERR: Offending ECDSA key in /Users/mercatp/.ssh/known_hosts:1

STDERR: ECDSA host key for trac.sagemath.org has changed and you have 
requested strict checking.

STDERR: Host key verification failed.

STDERR: fatal: Could not read from remote repository.

STDERR: 

STDERR: Please make sure you have the correct access rights

STDERR: and the repository exists.


I don't understand where is the problem. My public ssh is on the trac 
server, the server is in the list of know hosts in my computer.


When I try the command

$sudo git trac push

I get another error :

git_trac.git_error.GitError: git returned with non-zero exit code (128) 
when executing "git push trac HEAD:refs/heads/u/mercatp/b-adic"

STDERR: Permission denied (publickey).

STDERR: fatal: Could not read from remote repository.

STDERR: 

STDERR: Please make sure you have the correct access rights

STDERR: and the repository exists.


I previously pushed some commits before with this computer. I don't 
understand why it doesn't work anymore.

-- 
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: Memory leak coming from MixedIntegerLinearProgram ???

[Sébastien Labbé]

I get: "ImportError: No module named coin_backend".

Without solver='Coin', I get:

sage: get_memory_usage()
316.6015625
sage: fill_memory(2000)
sage: get_memory_usage()
341.578125
sage: fill_memory(2000)
sage: get_memory_usage()
341.578125
sage: fill_memory(2000)
sage: get_memory_usage()
341.578125
sage: fill_memory(2000)
sage: get_memory_usage()
341.578125
sage: fill_memory(2000)
sage: get_memory_usage()
341.578125

-- 
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: R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

I would say we even have a shorter-time solution: close the tickets for 
including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking) 
and updating R (modulo adding a 6-line patch to not check for https 
support, note that most of the time https will be supported anyway).


On Wednesday, November 2, 2016 at 11:19:52 AM UTC+1, Emmanuel Charpentier 
wrote:
>
> So far, the only plan I can propose which is consistent with the various 
> points that have been stated  is : 
>
> I) short-term workaround : add a dependance for Sage, by :
> a) depending on libcurl and its development files, or
> b) depending on a systemwide R + its development files
> II) solve current issues with the pexpexct interface (e. g. graphs in 
> Jupyter...) and its documentation (e. g. use of RElement to retrieve an R 
> object).
>
> This solves the immediate problem at hand (which is urgent : more and more 
> R packages won't install on R 3.2.x). But since some have pointed out the 
> inefficiencies of the current R interface and its documentation, we could :
>
> III) Build some steamlined interface ("newR") to R (via rpy2 ? via 
> IRkernel ?). Test it
> IV) Based on newR, build a reasonable wrapper emulating 
> feature-for-feature the current pexpect interface. Test it.
> V) replace the pexpect interface by the wrapper.
>
> This is not urgent, and can be discussed further.
>
> Now, for Ia vs Ib :
>
>- Both require modifying the installation documentation and the main 
>configure file. These do not seem to be large modifications (I just need 
> to 
>learn a modicum of autotools in order to do this correctly).
>- Both allow the current pexpect to remain a standard part of Sage.
>
> Ib seems to have two slight advantages on Ia :
>
>- R and its development files seem to be well-packaged on the few 
>(Linux) distributions I have checked, as well as Cygwin, and probably are 
>elsewhere (other GNU/Linuxes, assorted Unices). The Macintosh case, as 
>usual, bears a large question mark...
>- Paradoxically, it is probably easier for an end-user to check this 
>requirement than to check the suitability of his libcurl...
>- Ib does not require xz and pcre to become standard packages.
>
> Could we have a vote on the I-II block (which *is* urgent), and on the Ia 
> vs Ib alternative ?
>
> HTH,
>
> --
> Emmanuel Charpentier
>
> Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit :
>>
>> Hi all,
>>
>> The latest R versions depends on libcurl and actually more than that: on 
>> a libcurl with https support.
>> So we might want to build our own libcurl with https support (see #21767) 
>> but we then need an SSL/TLS implementation which Sage curretnly provides 
>> only optionally through openSSL because of license issues so we can:
>> [1] either make R depend on libcurl depend on openssl and they all become 
>> optional,
>> [2] or make R depend on libcurl and make them standard and add an SSL/TLS 
>> implementation and its development headers a prereq,
>> [3] or make libcurl with https support (and development headers) a 
>> prereq, which basically means adding an SSL/TLS implementation as a prereq 
>> as well,
>> [4] or make R a prereq,
>> [5] or drop R support,
>> [6] or patch R not to use curl,
>> [7] or patch R to use curl but without https support,
>> [8] or wait until the end of times,
>> [9] or a mix of all of this,
>> [10] or do something else.
>>
>> What do you think?
>>
>> Best,
>> JPF
>>
>

-- 
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] Issue with figures in doc.sagemath.org

[Eric Gourgoulhon]

Hi, 

Some 3D figures of the inline reference manual are not displayed on 
http://doc.sagemath.org/html/en/reference/
They are replaced by something like

../../../_images/parametric_plot3d-1.png

See for instance
http://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/parametric_plot3d.html

On the contrary, in locally generated doc, the figures are correctly 
displayed (tested with sage.7.4.rc2 and sage.7.5.beta1). 
 
Eric.

-- 
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: R 3.3.1 depends on a SSL/TLS implementation

[Emmanuel Charpentier]

So far, the only plan I can propose which is consistent with the various 
points that have been stated  is : 

I) short-term workaround : add a dependance for Sage, by :
a) depending on libcurl and its development files, or
b) depending on a systemwide R + its development files
II) solve current issues with the pexpexct interface (e. g. graphs in 
Jupyter...) and its documentation (e. g. use of RElement to retrieve an R 
object).

This solves the immediate problem at hand (which is urgent : more and more 
R packages won't install on R 3.2.x). But since some have pointed out the 
inefficiencies of the current R interface and its documentation, we could :

III) Build some steamlined interface ("newR") to R (via rpy2 ? via IRkernel 
?). Test it
IV) Based on newR, build a reasonable wrapper emulating feature-for-feature 
the current pexpect interface. Test it.
V) replace the pexpect interface by the wrapper.

This is not urgent, and can be discussed further.

Now, for Ia vs Ib :

   - Both require modifying the installation documentation and the main 
   configure file. These do not seem to be large modifications (I just need to 
   learn a modicum of autotools in order to do this correctly).
   - Both allow the current pexpect to remain a standard part of Sage.

Ib seems to have two slight advantages on Ia :

   - R and its development files seem to be well-packaged on the few 
   (Linux) distributions I have checked, as well as Cygwin, and probably are 
   elsewhere (other GNU/Linuxes, assorted Unices). The Macintosh case, as 
   usual, bears a large question mark...
   - Paradoxically, it is probably easier for an end-user to check this 
   requirement than to check the suitability of his libcurl...
   - Ib does not require xz and pcre to become standard packages.
   
Could we have a vote on the I-II block (which *is* urgent), and on the Ia 
vs Ib alternative ?

HTH,

--
Emmanuel Charpentier

Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit :
>
> Hi all,
>
> The latest R versions depends on libcurl and actually more than that: on a 
> libcurl with https support.
> So we might want to build our own libcurl with https support (see #21767) 
> but we then need an SSL/TLS implementation which Sage curretnly provides 
> only optionally through openSSL because of license issues so we can:
> [1] either make R depend on libcurl depend on openssl and they all become 
> optional,
> [2] or make R depend on libcurl and make them standard and add an SSL/TLS 
> implementation and its development headers a prereq,
> [3] or make libcurl with https support (and development headers) a prereq, 
> which basically means adding an SSL/TLS implementation as a prereq as well,
> [4] or make R a prereq,
> [5] or drop R support,
> [6] or patch R not to use curl,
> [7] or patch R to use curl but without https support,
> [8] or wait until the end of times,
> [9] or a mix of all of this,
> [10] or do something else.
>
> What do you think?
>
> Best,
> JPF
>

-- 
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] Memory leak coming from MixedIntegerLinearProgram ???

[Saul Schleimer]

Here is a bit of code: 

# foo.py

def dot_prod(v, w):
return sum(x*y for (x, y) in zip(v, w))

def get_polytope(M):
q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
w = q.new_variable(real = True, nonnegative = True)
for v in M.rows():
q.add_constraint( dot_prod(v, w) == 0 )
return q.polyhedron()

M = Matrix([[1,0],[0,1]])

def fill_memory(n):
for i in xrange(n):
P = get_polytope(M)

Now I can do the following:

[Code]$ sage
┌┐
│ SageMath Version 6.8, Release Date: 2015-07-26 │
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for help.│
└┘
sage: attach('foo.py')
sage: get_memory_usage()
288.58984375
sage: fill_memory(2000); get_memory_usage()
300.5859375
sage: fill_memory(2000); get_memory_usage()
302.5859375
sage: fill_memory(2000); get_memory_usage()
303.5859375
sage: fill_memory(2000); get_memory_usage()
305.5859375

It seems like MixedIntegerLinearProgram is leaking memory.  This kills my 
computer during long computations. 

Suggestions?

all the best,

saul

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