Re: [sage-devel] Re: el capitan statement

[Dima Pasechnik]

On Wednesday, 7 October 2015 11:11:47 UTC-7, David Roe wrote:
>
>
>
> On Wed, Oct 7, 2015 at 2:06 PM, Dima Pasechnik  > wrote:
>
>> On Wednesday, 7 October 2015 11:00:14 UTC-7, Jeroen Demeyer wrote:
>>>
>>> On 2015-10-07 19:31, David Roe wrote: 
>>> > In OS X 10.11, Apple changed the operating system to no longer allow 
>>> > modification of certain system folders, even when logged in as root. 
>>>
>>> Why would Sage need modification to system folders? Sage can be compiled 
>>> as an ordinary user, so I don't see how this is relevant. 
>>>
>>> this is probably indeed irrelevant. What is relevant is they apparently 
>> managed to break LD_LIBRARY_PATH etc things,
>> and this prevents one from doing pretty much anything that relies on this.
>>
>> Also, please note that there are two  different systems OSX 10.11, and OX 
>> 11.? (El Capitan), which both suffer from this.
>>
>
> What is OX 11.?? I know that the Sage thread was titled OS X 11.11, but I 
> thought that was a typo
>

my bad; I didn't check, and my Macs are on the other side of Atlantic at 
the moment.

David 
>
>>
>>
>> -- 
>> 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 http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: el capitan statement

[Dima Pasechnik]

On Wednesday, 7 October 2015 11:57:22 UTC-7, Harald Schilly wrote:
>
> I've added a very short red banner to the download osx/intel download page 
> for all mirrors. It does link back here to sage-devel, to the last two 
> threads I found about that. 
>
> What I don't want is to clutter the main index.html page with this. If 
> this banner is not enough, then we could also add something to the specific 
> download page. 
>
> I don't know how to word this best, but for now there is at least 
> something there. What puzzles me about all this is, that even packages like 
> git are broken. Why is this going on here?
>

that SIP thing breaks LD_LIBRARY_PATH mechanics. That's, you need to do 
something else (RPATH) if you want to have dynamic libraries in 
non-standard locations.
(although AFAIK, /usr/local is OK)


> -- 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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: el capitan statement

[François Bissey]

On 10/08/15 09:42, Dima Pasechnik wrote:



On Wednesday, 7 October 2015 11:57:22 UTC-7, Harald Schilly wrote:

I've added a very short red banner to the download osx/intel
download page for all mirrors. It does link back here to sage-devel,
to the last two threads I found about that.

What I don't want is to clutter the main index.html page with this.
If this banner is not enough, then we could also add something to
the specific download page.

I don't know how to word this best, but for now there is at least
something there. What puzzles me about all this is, that even
packages like git are broken. Why is this going on here?


that SIP thing breaks LD_LIBRARY_PATH mechanics. That's, you need to do
something else (RPATH) if you want to have dynamic libraries in
non-standard locations.
(although AFAIK, /usr/local is OK)


Well my opinion on the need for rpath at the moment is that it is
rubbish - technically it is in the nice to have bucket but it is not
completely the problem. Fixing the install_name makes all those failed
import because I cannot find libsingular.dylib go away.
Now I have a segfault which is not necessarily better but is almost 
certainly not linked to DYLD_LIBRARY_PATH stuff.


Francois

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

[sage-devel] Re: Porting SageMath to Windows 64

[Bill Hart]

Gap built fine for me under MSYS2. There was one warning. (I used MPIR not 
GMP.)

However, I see why Gap built fine. Like Cygwin, MSYS2 sets sizeof(long) to 
8. 

When I earlier said otherwise, I had in fact set up my MSYS2 to use the 
mingw-w64, and this builds things without the posix layer. Of course Gap is 
heavily posix dependent, so requires the MSYS2 gcc. So building with posix 
layer effectively results in sizeof(long) = 8, same as Linux.

So in that regard I'm actually not sure what the advantages are over 
Cygwin64 in terms of native interop are. 

Either way, that's one more project to add to the list that seems to work 
ok on Windows 64.

Bill.

On Wednesday, 7 October 2015 19:54:30 UTC+2, Dima Pasechnik wrote:
>
>
>
> On Wednesday, 7 October 2015 07:35:22 UTC-7, Bill Hart wrote:
>>
>> HI all,
>>
>> William Stein recently bemoaned the fact that SageMath currently only 
>> runs natively on some brands of Linux, and not natively on the latest 
>> Windows or OSX (that is to say nothing of BSD). [1]
>>
>> Until recently, a port of SageMath to Windows has seemed like a pipe 
>> dream. However, things have changed a lot, and I think it would now be 
>> possible to achieve this (for some definition of the word "native").
>>
>> I've tried VM's before and it has always ended in disaster. They either 
>> screw up my networking, they have performance issues, or don't support my 
>> mouse properly, or change my keyboard layout, or it's impossible to get 
>> files from my hard drive into the system easily, or they take up too much 
>> disk space or need to be constantly downloaded to update them, or some 
>> features don't work, or people stop supporting them, etc. The disadvantages 
>> of VMs are so numerous I hardly need to enumerate them. And even if it is a 
>> solution for users, it's hardly a solution for serious Windows developers.
>>
>> As some people know, I've been recently working on a Julia based 
>> "computer algebra system" for a much more limited subset of "computer 
>> algebra" than Sage targets. What people may not know is that that entire 
>> technology stack works natively on Windows.
>>
>> I can't express how fantastic it was to be sitting on a train recently, 
>> with no web access whatsoever and to be able to do work on my Windows 10 
>> (64 bit) laptop on the train. And everything ran as fast, or in some cases 
>> faster, than my Linux server. That's the first time that has happened since 
>> I started doing computational stuff about 10 years ago!
>>
>> MSYS2 as a solution
>> 
>>
>> The new technology that makes all this work is MSYS2. Here are some of 
>> its features:
>>
>> * Installing MSYS2 on Windows couldn't be easier. [2]
>> * It supports proper Windows exception handling protocols.
>> * It has an amazing command line package manager called Pacman, which 
>> Just Works TM.
>> * Unlike Cygwin, it's very minimal, and takes little time to install.
>> * It's fast. Very fast.
>> * Parallel make works.
>> * The resulting binaries are fast, sometimes faster on my laptop than on 
>> the Linux server I usually use for development.
>> * MSYS2 provides a posix layer! (Applications can be distributed with an 
>> MSYS2 dll for this.)
>> * Multithreading using pthreads Just Works TM (Applications can be 
>> distributed with a winthreads dll for this. I've actually used this, no 
>> patching required, so I am not speaking theoretically here.)
>> * Like native Windows, sizeof(long) = 4 and sizeof(long long) = 8 on 
>> MSYS2. This means interop with native Windows applications or assembly 
>> objects is a cynch.
>> * The resulting applications can be run on Windows as essentially native 
>> applications. They don't have to be run from within the MSYS2 shell. They 
>> can also be distributed as binary packages for those that don't care about 
>> the source code. But here's the thing: it's not *necessary* to distribute 
>> them as binary packages. It's now quite feasible for developers to actually 
>> *build* packages on Windows. And let's face it, this is the type of 
>> developer we actually want on the Windows platform. Simply supporting users 
>> and not developers is just going to increase the maintenance burden for 
>> people who work on other platforms. We want actual Windows developers, not 
>> just users!
>>  
>> The only bad thing about MSYS2 is that autotools is still incredibly slow 
>> (Flint roll-your-own configure takes 5s at most on Windows, whereas 
>> autotools can take some minutes to configure a package). Note: make is not 
>> slow (at least not on Windows 64 -- it's not as fast on 32 bit Windows, but 
>> fortunately almost no one is using Windows 32 any more anyway).
>>
>
> If  MSYS2 has (Cygwin's?) fork(), it should not differ much from Cygwin, 
> in the sense of porting of Sage.
> fork() was the major pain on Win32, as building Python extensions results 
> in huge number of dlls that have hard time
> fitting into the (32bit) address space, so 

Re: [sage-devel] Re: Nauty vs SageMath speed comparisons?

[Dima Pasechnik]

On Wednesday, 7 October 2015 00:31:39 UTC-7, Jori Mäntysalo wrote:
>
> On Wed, 7 Oct 2015, Jeroen Demeyer wrote: 
>
> > I don't see any evidence of that. I don't think that he was asked 
> further 
> > clarification. Given that you already communicated with him for #14110, 
> maybe 
> > you could ask? 
>
> But I know a little about programming, nothing about copyright laws or 
> psychology! Anybody else to volunteer...? 
>
> I've just asked Brendan. We'll see.
 

> -- 
> 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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Porting SageMath to Windows 64

[Bill Hart]

OK, after more reading I find that these are the main benefits of MSYS2 
over Cygwin:

* Support for interop with mingw-w64 built packages.
* Ability to switch from MSYS to MinGW mode by setting an environment 
variable (MSYSTEM).
* Automatic conversion on the fly in the msys2.0.dll between different path 
formats.
* Automatic handling in the msys2.0.dll of the different line endings 
(posix vs Windows).
* A direct recompilation of the Arch Linux package manager (Pacman).
* Various other more technical things.

The main benefit as explained by an MSYS2 person is that with MSYS2 you'll 
use a lot more natively compiled binaries, which will be faster.

The main benefits over MinGW are:

* It's actually being developed.
* It is regularly synced with the Cygwin project.
* MSYS2 bash is not inferior to Cygwin bash. 

Bill.

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

Re: [sage-devel] Re: el capitan statement

[François Bissey]

On 10/08/15 09:56, François Bissey wrote:

On 10/08/15 09:42, Dima Pasechnik wrote:



On Wednesday, 7 October 2015 11:57:22 UTC-7, Harald Schilly wrote:

I've added a very short red banner to the download osx/intel
download page for all mirrors. It does link back here to sage-devel,
to the last two threads I found about that.

What I don't want is to clutter the main index.html page with this.
If this banner is not enough, then we could also add something to
the specific download page.

I don't know how to word this best, but for now there is at least
something there. What puzzles me about all this is, that even
packages like git are broken. Why is this going on here?


that SIP thing breaks LD_LIBRARY_PATH mechanics. That's, you need to do
something else (RPATH) if you want to have dynamic libraries in
non-standard locations.
(although AFAIK, /usr/local is OK)


Well my opinion on the need for rpath at the moment is that it is
rubbish - technically it is in the nice to have bucket but it is not
completely the problem. Fixing the install_name makes all those failed
import because I cannot find libsingular.dylib go away.
Now I have a segfault which is not necessarily better but is almost
certainly not linked to DYLD_LIBRARY_PATH stuff.



There is now a dedicated ticket for this.
http://trac.sagemath.org/ticket/19370

Francois

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

Re: [sage-devel] Nauty vs SageMath speed comparisons?

[Nathann Cohen]

> Cool. I'm up for doing that. So.. I need to bring nauty using cython and
> call the is_isomorphic function?

If Nauty proves much better than our current implementation then that
is what we will need: a fast way to call Nauty. And that means Cython.

This being said, writing a cython interface with Nauty may not be
exactly "quick and clean": thus, if you need to have an idea of how
fast you can expect it to be, you can first try to call Nauty "the
dirty way", by creating a file on which you would then call the
executable. It's up to you.

Also, be aware that we currently have an interface with a software
called bliss, which is used (when installed) in
Graph.automorphism_group and can also compute a canonical labelling
(though that part is not exposed at the moment).

It may be quicker to test (though it's a different software) as all
main pieces are available (the package, a cython file defining the
right structures, etc).

Nathann

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

Re: [sage-devel] Nauty vs SageMath speed comparisons?

[Jori Mäntysalo]

On Wed, 7 Oct 2015, Nathann Cohen wrote:

If Nauty proves much better than our current implementation then that is 
what we will need: a fast way to call Nauty. And that means Cython.


I know nothing, but to cite Wikipedia: "There are several competing 
practical algorithms for graph isomorphism, due to McKay (1981) - - While 
they seem to perform well on random graphs, a major drawback of these 
algorithms is their exponential time performance in the worst case."


So maybe we should have both current algorithm and Nauty.

--
Jori Mäntysalo

Re: [sage-devel] Re: Nauty vs SageMath speed comparisons?

[Jori Mäntysalo]

On Wed, 7 Oct 2015, Jeroen Demeyer wrote:

I don't see any evidence of that. I don't think that he was asked further 
clarification. Given that you already communicated with him for #14110, maybe 
you could ask?


But I know a little about programming, nothing about copyright laws or 
psychology! Anybody else to volunteer...?


--
Jori Mäntysalo

Re: [sage-devel] Re: Nauty vs SageMath speed comparisons?

[Jeroen Demeyer]

On 2015-10-07 07:49, Jori Mäntysalo wrote:

Yes, there was. However his statement was very vague, it was not clear
what he really meant. I don't think that anybody ever asked for further
clarification.


I think that somebody did, but I am not sure.


I don't see any evidence of that. I don't think that he was asked 
further clarification. Given that you already communicated with him for 
#14110, maybe you could ask?


Jeroen.

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

Re: [sage-devel] Re: el capitan

[Francois Bissey]

Haven’t checked yet but so far I have dealt with libsingular, zn_poly and
cliquer.

For some reason git doesn’t want to build in my current run.

Do we have a ticket for El Capitan where I can push things for
other brave people?

François

> On 7/10/2015, at 19:40, kcrisman  wrote:
> 
> For some time there has been a known issue that a number of 
> components shipped with sage do not set up proper "install_name" 
> for their libraries. libsingular is one such library. 
> 
> 
> R as well? 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [sage-devel] Re: threejs

[Thierry Dumont]

Le 07/10/2015 08:42, kcrisman a écrit :
> >
> 
> MMMhhh, interesting!
> 
> Do you think it would be possible to replace jmol by jsmol in sage?
> or keep both and choose which on to use?
> 
> 
> This is already possible!  In the notebook - thanks to tons of work by
> Jonathan and Volker.  I don't know how that would work from command line
> though, as it would have to open a browser or something? 
> 
> -- 


Great, yes, but how do I proceed to switch to jsmol?

yours
t.

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

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

Re: [sage-devel] Nauty vs SageMath speed comparisons?

[Nathann Cohen]

> So maybe we should have both current algorithm and Nauty.

In my own experience, the isomorphism test has *never* been either
slow nor the slowest part of my code.

If it was too slow for your usage then having new interfaces makes
sense, otherwise it would just be for the sake of collecting them.

Nathann

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

[sage-devel] Re: el capitan

[kcrisman]

>
> For some time there has been a known issue that a number of 
> components shipped with sage do not set up proper "install_name" 
> for their libraries. libsingular is one such library. 
>
>
R as well? 

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

Re: [sage-devel] Porting SageMath to Windows 64

[Peter Luschny]

 7. Oktober 2015 20:05:11 UTC+2, bluescarni:
>
> Practically, it's an architecture that supports "natively" 64 bit ints but 
> the pointers are 32 bits wide. AFAIK, this is supposed to improve 
> performance for pointer-heavy workloads that do not need to allocate much 
> RAM but still benefit from the 64 bit ints.
>

Wasn't it initiated by Donald Knuth's flame: "It is absolutely idiotic to 
have 64-bit pointers 
when I compile a program that uses less than 4 gigabytes of RAM." 

Peter

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

4GB of Ram should be enough for anyone. :-)

On Wednesday, 7 October 2015 21:24:01 UTC+2, Peter Luschny wrote:
>
>  7. Oktober 2015 20:05:11 UTC+2, bluescarni:
>>
>> Practically, it's an architecture that supports "natively" 64 bit ints 
>> but the pointers are 32 bits wide. AFAIK, this is supposed to improve 
>> performance for pointer-heavy workloads that do not need to allocate much 
>> RAM but still benefit from the 64 bit ints.
>>
>
> Wasn't it initiated by Donald Knuth's flame: "It is absolutely idiotic to 
> have 64-bit pointers 
> when I compile a program that uses less than 4 gigabytes of RAM." 
>
> Peter
>
>

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

Re: [sage-devel] el capitan

[Francois Bissey]

Yes R need to be checked over but it will have to be more elaborate than
the ad hoc things I put for the others.
R also suffers from http://trac.sagemath.org/ticket/18254 on OS X 10.11.
The fix was only applied on 10.10 and I think that was not well thought
out. It won’t get better without something radical happening.

The fix for openssl for git 2.3.0 is ineffective and I had to replace it
with something a bit less subtle.

So I don’t have the crash because of libraries that cannot be found
anymore but I have this segfault and I will have to rebuild again with
debugging enabled. I am including the patch with the state of my branch 
so other people can try it while I catch some .

François

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


el_capitan.patch
Description: el_capitan.patch


> On 7/10/2015, at 19:52, Francois Bissey  
> wrote:
> 
> Haven’t checked yet but so far I have dealt with libsingular, zn_poly and
> cliquer.
> 
> For some reason git doesn’t want to build in my current run.
> 
> Do we have a ticket for El Capitan where I can push things for
> other brave people?
> 
> François
> 
>> On 7/10/2015, at 19:40, kcrisman  wrote:
>> 
>> For some time there has been a known issue that a number of 
>> components shipped with sage do not set up proper "install_name" 
>> for their libraries. libsingular is one such library. 
>> 
>> 
>> R as well? 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-devel@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: threejs

[mmarco]

I think it is already the default way to show 3d graphics in the notebook 
in the last versions. Isn't it?

El miércoles, 7 de octubre de 2015, 9:28:32 (UTC+2), tdumont escribió:
>
> Le 07/10/2015 08:42, kcrisman a écrit : 
> > > 
> > 
> > MMMhhh, interesting! 
> > 
> > Do you think it would be possible to replace jmol by jsmol in sage? 
> > or keep both and choose which on to use? 
> > 
> > 
> > This is already possible!  In the notebook - thanks to tons of work by 
> > Jonathan and Volker.  I don't know how that would work from command line 
> > though, as it would have to open a browser or something? 
> > 
> > -- 
>
>
> Great, yes, but how do I proceed to switch to jsmol? 
>
> yours 
> t. 
>
> > 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 http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Figuring out imports required when moving from a .sage to a .py file?

[Simon King]

Hi Tom!

In addition to Travis' reply:

On 2015-10-06, Tom Kitchen  wrote:
> I have recently installed sage from source and am trying to implement 
> fourier transforms. I wrote a piece of sage code which does the job for 
> some function f. 
>
>
> var('t', 'k','x','a')

As much as I know, just doing var('t') in an interactive session will create
a variable called t *and* will insert it into the global name space, so
that subsequently if the user types "t" then the variable t is returned.

However, that's not possible when you create a .py module. There, you
need to assign the resulting symbolic variables to Python variables, which of
course do not necessarily have the same name as the symbolic variables.
So, you could do
  X,Y,Z = var('x', 'y', 'z')
(but probably your symbolic and Python variables should have the same
name, thus, x,y,z=var('x','y','z'))

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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

Some random thoughts:

- I am not so convinced the strategy of automatic long -> long long
patching is actually feasible, I think in practice this is gonna be a big
can of worms. Pushing upstream to fix their code is a much better long-term
solution IMO (and I'd rather have nothing to do with projects which refuse
portability and code-quality patches, but that's just me :)
- mingw-w64 is a high quality compiler. I recently had to develop for a
while on a Windows 64 machine, and had to recompile a full stacks of
dependencies (MPFR, GMP, Boost, etc.). It was not so easy (most issues were
related to build systems), but the end result was pretty impressive
performance-wise.
- While for C code you can probably interoperate with libraries compiled
with MSVC, for C++ you will end up having issues related, e.g., to
different implementations of exception handling. My suggestion would be to
forget about MSVC and compile the full stack of dependencies exclusively
with mingw.
- Python on windows 64 does not play properly with mingw due to some
long-standing issues in some header files. If you want to compile Python
C/C++ extensions on Win64 you will have to patch slightly the Python
headers and re-generate the definitions of the Python library. The issue is
explored, e.g., here:

http://ascend4.org/Setting_up_a_MinGW-w64_build_environment#Setup_Python_for_compilation_of_extensions

Generally speaking, mingw-w64 is a really good option for C/C++ development
on Windows. The biggest problem is the proliferation of distributions
(mingw-w64, TDM mingw, mingw-build, msys2, etc.), but the toolchain is
solid. clang is getting there as well, so it's worth keeping it in mind for
the future.

Cheers,

  Francesco.


On 7 October 2015 at 16:35, Bill Hart  wrote:

> HI all,
>
> William Stein recently bemoaned the fact that SageMath currently only runs
> natively on some brands of Linux, and not natively on the latest Windows or
> OSX (that is to say nothing of BSD). [1]
>
> Until recently, a port of SageMath to Windows has seemed like a pipe
> dream. However, things have changed a lot, and I think it would now be
> possible to achieve this (for some definition of the word "native").
>
> I've tried VM's before and it has always ended in disaster. They either
> screw up my networking, they have performance issues, or don't support my
> mouse properly, or change my keyboard layout, or it's impossible to get
> files from my hard drive into the system easily, or they take up too much
> disk space or need to be constantly downloaded to update them, or some
> features don't work, or people stop supporting them, etc. The disadvantages
> of VMs are so numerous I hardly need to enumerate them. And even if it is a
> solution for users, it's hardly a solution for serious Windows developers.
>
> As some people know, I've been recently working on a Julia based "computer
> algebra system" for a much more limited subset of "computer algebra" than
> Sage targets. What people may not know is that that entire technology stack
> works natively on Windows.
>
> I can't express how fantastic it was to be sitting on a train recently,
> with no web access whatsoever and to be able to do work on my Windows 10
> (64 bit) laptop on the train. And everything ran as fast, or in some cases
> faster, than my Linux server. That's the first time that has happened since
> I started doing computational stuff about 10 years ago!
>
> MSYS2 as a solution
> 
>
> The new technology that makes all this work is MSYS2. Here are some of its
> features:
>
> * Installing MSYS2 on Windows couldn't be easier. [2]
> * It supports proper Windows exception handling protocols.
> * It has an amazing command line package manager called Pacman, which Just
> Works TM.
> * Unlike Cygwin, it's very minimal, and takes little time to install.
> * It's fast. Very fast.
> * Parallel make works.
> * The resulting binaries are fast, sometimes faster on my laptop than on
> the Linux server I usually use for development.
> * MSYS2 provides a posix layer! (Applications can be distributed with an
> MSYS2 dll for this.)
> * Multithreading using pthreads Just Works TM (Applications can be
> distributed with a winthreads dll for this. I've actually used this, no
> patching required, so I am not speaking theoretically here.)
> * Like native Windows, sizeof(long) = 4 and sizeof(long long) = 8 on
> MSYS2. This means interop with native Windows applications or assembly
> objects is a cynch.
> * The resulting applications can be run on Windows as essentially native
> applications. They don't have to be run from within the MSYS2 shell. They
> can also be distributed as binary packages for those that don't care about
> the source code. But here's the thing: it's not *necessary* to distribute
> them as binary packages. It's now quite feasible for developers to actually
> *build* packages on Windows. And let's face it, this is the type of
> developer we actually 

Re: [sage-devel] Porting SageMath to Windows 64

[Jeroen Demeyer]

Is there any reason to assume that porting using MSYS2 is easier than 
porting using Cygwin? Because the latter is already hard enough.


I can the main "elephant in the room" is the POSIX layer. Many pieces of 
Sage assume some kind of POSIX environment.


Jeroen.

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

[sage-devel] Porting SageMath to Windows 64

[Bill Hart]

HI all,

William Stein recently bemoaned the fact that SageMath currently only runs 
natively on some brands of Linux, and not natively on the latest Windows or 
OSX (that is to say nothing of BSD). [1]

Until recently, a port of SageMath to Windows has seemed like a pipe dream. 
However, things have changed a lot, and I think it would now be possible to 
achieve this (for some definition of the word "native").

I've tried VM's before and it has always ended in disaster. They either 
screw up my networking, they have performance issues, or don't support my 
mouse properly, or change my keyboard layout, or it's impossible to get 
files from my hard drive into the system easily, or they take up too much 
disk space or need to be constantly downloaded to update them, or some 
features don't work, or people stop supporting them, etc. The disadvantages 
of VMs are so numerous I hardly need to enumerate them. And even if it is a 
solution for users, it's hardly a solution for serious Windows developers.

As some people know, I've been recently working on a Julia based "computer 
algebra system" for a much more limited subset of "computer algebra" than 
Sage targets. What people may not know is that that entire technology stack 
works natively on Windows.

I can't express how fantastic it was to be sitting on a train recently, 
with no web access whatsoever and to be able to do work on my Windows 10 
(64 bit) laptop on the train. And everything ran as fast, or in some cases 
faster, than my Linux server. That's the first time that has happened since 
I started doing computational stuff about 10 years ago!

MSYS2 as a solution


The new technology that makes all this work is MSYS2. Here are some of its 
features:

* Installing MSYS2 on Windows couldn't be easier. [2]
* It supports proper Windows exception handling protocols.
* It has an amazing command line package manager called Pacman, which Just 
Works TM.
* Unlike Cygwin, it's very minimal, and takes little time to install.
* It's fast. Very fast.
* Parallel make works.
* The resulting binaries are fast, sometimes faster on my laptop than on 
the Linux server I usually use for development.
* MSYS2 provides a posix layer! (Applications can be distributed with an 
MSYS2 dll for this.)
* Multithreading using pthreads Just Works TM (Applications can be 
distributed with a winthreads dll for this. I've actually used this, no 
patching required, so I am not speaking theoretically here.)
* Like native Windows, sizeof(long) = 4 and sizeof(long long) = 8 on MSYS2. 
This means interop with native Windows applications or assembly objects is 
a cynch.
* The resulting applications can be run on Windows as essentially native 
applications. They don't have to be run from within the MSYS2 shell. They 
can also be distributed as binary packages for those that don't care about 
the source code. But here's the thing: it's not *necessary* to distribute 
them as binary packages. It's now quite feasible for developers to actually 
*build* packages on Windows. And let's face it, this is the type of 
developer we actually want on the Windows platform. Simply supporting users 
and not developers is just going to increase the maintenance burden for 
people who work on other platforms. We want actual Windows developers, not 
just users!
 
The only bad thing about MSYS2 is that autotools is still incredibly slow 
(Flint roll-your-own configure takes 5s at most on Windows, whereas 
autotools can take some minutes to configure a package). Note: make is not 
slow (at least not on Windows 64 -- it's not as fast on 32 bit Windows, but 
fortunately almost no one is using Windows 32 any more anyway).

Proposal
===

What I propose is to begin porting Sage dependencies to Windows (note that 
by Windows, I mean Windows 64, i.e. what everyone is using). What this 
would mean is porting them to MSYS2 (at least initially). Note it's not a 
big step from there to MinGW or MSVC if people want to do that later. 
Microsoft have made MSVC much, much more friendly to GNU conventions, 
recently. (For some users, porting to Windows natively is synonymous with 
supporting MSVC using Visual Solution files. But I'm not suggesting we do 
that.)

Since we know that many upstream projects simply will not accept thousands 
of patches to their repositories for supporting Windows 64, much less do 
they have developer resources to support them on an ongoing basis, here is 
what I think needs to be done:

1) Automagically patch their source trees at build time so that long 
becomes long long and unsigned long becomes unsigned long long on Windows.
2) Automagically patch their source trees at build time so that 
printf/scanf("%ld") becomes printf/scanf("%lld") on Windows.
3) Send a very small number of "Windows" patches upstream for the few 
instances of nonportable code that probably doesn't work anywhere except 
Linux, let alone on Windows.

Is this feasible? 

Yes it is. Note that libpari still 

Re: [sage-devel] Re: el capitan statement

[David Roe]

The only reports I've seen, on
https://groups.google.com/forum/#!topic/sage-devel/OBv5x1v3_6M, have been
positive.  What conflicting reports have you received?  I haven't tried it
myself; I'm still running 10.9.

Here's a summary for how to disable it:

1. Reboot, holding down Cmd-R to start in Recovery Mode.
2. In a terminal window, execute csrutil disable
3. Reboot back into non-Recovery Mode.

Here's a warning for why you might hesitate (this is my understanding of
the issue; someone please correct me if I'm wrong):

In OS X 10.11, Apple changed the operating system to no longer allow
modification of certain system folders, even when logged in as root.  They
made this change to make it more difficult for malware to affect the
operating system, but it has the side effect of disrupting Sage's current
build process.  Disabling system integrity protection may allow you to
build Sage, but it also disables a security feature of your operating
system.

David

On Wed, Oct 7, 2015 at 12:52 PM, William Stein  wrote:

>
>
> On Wednesday, October 7, 2015, David Roe  wrote:
>
>> Do you want to mention the possibility of disabling system integrity
>> protection, or are you purposefully avoiding that option?
>> David
>>
>
>
> To what extent does it actually really work?  To what extent?  I've got
> conflicting reports.
>
> I think we should mention it.
>
>
>>
>> On Wed, Oct 7, 2015 at 12:38 PM, William Stein  wrote:
>>
>>> Hi,
>>>
>>> We need to post a statement on the Sagemath.org website about the El
>>> Capitan os x 10.11 situation, since I'm getting (or will be getting)
>>> emails "left and right" from people freaking out about this.
>>> Here's one answer -- how could it be reworded to be right?
>>>
>>> ---
>>> Hi,
>>>
>>> As far as I know, there is no way to run Sage on OS X anymore (except
>>> by using VirtualBox), and I don't know when/if this will change.
>>> Here's one recent discussion of ongoing work:
>>>
>>> https://groups.google.com/forum/#!topic/sage-devel/-ZVSh5adEkY
>>>
>>> Basically apple made many fundamental changes to OS X  10.11 that
>>> fundamentally breaks a large ecosystem of open source software.
>>>
>>> Fixing these things will take time, and I have no idea how long.
>>>
>>> William
>>> ---
>>>
>>> --
>>> William (http://wstein.org)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "sage-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to sage-devel+unsubscr...@googlegroups.com.
>>> To post to this group, send email to sage-devel@googlegroups.com.
>>> Visit this group at http://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 http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Sent from my massive iPhone 6 plus.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

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

[sage-devel] Re: el capitan statement

[William Stein]

On Wednesday, October 7, 2015, David Roe  wrote:

> The only reports I've seen, on
> https://groups.google.com/forum/#!topic/sage-devel/OBv5x1v3_6M, have been
> positive.  What conflicting reports have you received?
>
>
>

I think Tom Judson said it doesn't work.


>
> I haven't tried it myself; I'm still running 10.9.
>
> Here's a summary for how to disable it:
>
> 1. Reboot, holding down Cmd-R to start in Recovery Mode.
> 2. In a terminal window, execute csrutil disable
> 3. Reboot back into non-Recovery Mode.
>
> Here's a warning for why you might hesitate (this is my understanding of
> the issue; someone please correct me if I'm wrong):
>
> In OS X 10.11, Apple changed the operating system to no longer allow
> modification of certain system folders, even when logged in as root.  They
> made this change to make it more difficult for malware to affect the
> operating system, but it has the side effect of disrupting Sage's current
> build process.  Disabling system integrity protection may allow you to
> build Sage, but it also disables a security feature of your operating
> system.
>
> David
>
> On Wed, Oct 7, 2015 at 12:52 PM, William Stein  > wrote:
>
>>
>>
>> On Wednesday, October 7, 2015, David Roe > > wrote:
>>
>>> Do you want to mention the possibility of disabling system integrity
>>> protection, or are you purposefully avoiding that option?
>>> David
>>>
>>
>>
>> To what extent does it actually really work?  To what extent?  I've got
>> conflicting reports.
>>
>> I think we should mention it.
>>
>>
>>>
>>> On Wed, Oct 7, 2015 at 12:38 PM, William Stein  wrote:
>>>
 Hi,

 We need to post a statement on the Sagemath.org website about the El
 Capitan os x 10.11 situation, since I'm getting (or will be getting)
 emails "left and right" from people freaking out about this.
 Here's one answer -- how could it be reworded to be right?

 ---
 Hi,

 As far as I know, there is no way to run Sage on OS X anymore (except
 by using VirtualBox), and I don't know when/if this will change.
 Here's one recent discussion of ongoing work:

 https://groups.google.com/forum/#!topic/sage-devel/-ZVSh5adEkY

 Basically apple made many fundamental changes to OS X  10.11 that
 fundamentally breaks a large ecosystem of open source software.

 Fixing these things will take time, and I have no idea how long.

 William
 ---

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

 --
 You received this message because you are subscribed to the Google
 Groups "sage-devel" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://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 http://groups.google.com/group/sage-devel.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Sent from my massive iPhone 6 plus.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com
>> 
>> .
>> To post to this group, send email to sage-devel@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com
> 
> .
> To post to this group, send email to sage-devel@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from my massive iPhone 6 plus.

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

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

PARI requires (required?) sizeof(mp_limb_t)==sizeof(void*), which is not
guaranteed and not enforceable by PARI (as it's up to GMP to decide what
exactly an mp_limb_t is).

On 7 October 2015 at 19:03, Bill Hart  wrote:

>
>
> On Wednesday, 7 October 2015 18:37:41 UTC+2, Jean-Pierre Flori wrote:
>>
>>
>>
>> On Wednesday, October 7, 2015 at 6:35:36 PM UTC+2, bluescarni wrote:
>>>
>>>
> * PARI which assumes that sizeof(long) == sizeof(void*), there is an
> experimental branch fixing this:
> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>

 I am using Pari (not GP) today on Windows 64. It was minimal effort on
 my part to do so. I am not using a special branch.

>>>
>>> This was a problem for the x32 architecture as well. See, e.g., here:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320
>>>
>>> Glad that the PARI devs fixed this eventually.
>>>
>> It was not fixed by an "actual" PARI dev, but what's important is that
>> some code is now publicly available.
>>
>
> I read through that entire Debian issue and still haven't got a clue what
> the issue was. There seems to have been a lot of arguing there about whose
> fault this actually was. None of these people is a dummy, so I don't
> understand why they couldn't figure it out.
>
> Anyway, x32 is not something I'm interested in supporting. It's great that
> GMP does, and some other software does, and Flint is moving towards
> supporting it. But it's not a priority.
>
> Bill.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 19:11:35 UTC+2, Jeroen Demeyer wrote:
>
> On 2015-10-07 18:50, Bill Hart wrote: 
> > 
> > 
> > On Wednesday, 7 October 2015 18:33:01 UTC+2, Jeroen Demeyer wrote: 
> > 
> > On 2015-10-07 18:23, Bill Hart wrote: 
> >  > Cygwin also provides a POSIX environment, so I'm not sure I 
> > understand 
> >  > why this is an "elephant in the room". 
> > 
> > It's an elephant in the room because your original post completely 
> > seems 
> > to ignore any possible problems with the POSIX layer, while the 
> POSIX 
> > layer is where most of the problems on Cygwin come from. 
> > 
> > 
> > You mean there were bugs in the way posix was implemented in Cygwin? 
> Well, it's not really bugs. The problem is that some things just don't 
> have a Windows equivalent. fork() is a good example, that just doesn't 
> exist on Windows. 
>

Sure, but this doesn't make porting to Windows impossible. MSYS2 of course 
emulates fork/exec just like Cygwin. And yes, you still have the BLODA (big 
list of dodgy apps) that can cause fork to fail.

Whilst there are some Windows shells that try to deal with this issue, they 
aren't gaining much mindshare. 

In many cases, one can find an alternative to fork/exec (which apparently 
isn't even the most efficient way to do things on Linux much of the time 
that it is used).

In the end, a truly native Windows app wouldn't use fork. But I'm not 
advocating going the whole hog right away. There needs to be some 
intermediate steps between no Windows support and complete native Windows 
support. MSYS2 is a practical approach which serious Windows developers 
will take seriously (unlike Cygwin).

Bill.

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

Re: [sage-devel] Re: threejs

[kcrisman]

>
> > 
>
> MMMhhh, interesting! 
>
> Do you think it would be possible to replace jmol by jsmol in sage? 
> or keep both and choose which on to use? 
>

This is already possible!  In the notebook - thanks to tons of work by 
Jonathan and Volker.  I don't know how that would work from command line 
though, as it would have to open a browser or something? 

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 18:18:02 UTC+2, Jean-Pierre Flori wrote:
>
> As far as I remember, apart from the lack of POSIX compatibility on 
> Windows/MSYS, the main obstacle to "natively" compile Sage on Windows 64 
> were:
>

Just to clarify, I'm not talking about MSYS. That's a different thing 
entirely. MSYS2 has a posix layer.
 

> * PARI which assumes that sizeof(long) == sizeof(void*), there is an 
> experimental branch fixing this: 
> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>

I am using Pari (not GP) today on Windows 64. It was minimal effort on my 
part to do so. I am not using a special branch.


> * GAP memory allocation, no sure this is actually an issue, see 
> https://groups.google.com/d/msg/sage-devel/QXy_2KMbP1k/Z3cfpCieYzgJ for 
> "details".
>

Gasman might be an issue. My understanding is it tries to allocate all 
available memory up front. It's also not threadsafe. But this is already an 
issue for HPC Gap (so they use Boehm instead, as I understand it, albeit at 
a small performance cost).

Bill. 

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

Re: [sage-devel] Porting SageMath to Windows 64

[Jean-Pierre Flori]

On Wednesday, October 7, 2015 at 6:23:21 PM UTC+2, Bill Hart wrote:
>
>
>
> On Wednesday, 7 October 2015 17:15:14 UTC+2, Jeroen Demeyer wrote:
>>
>> Is there any reason to assume that porting using MSYS2 is easier than 
>> porting using Cygwin? Because the latter is already hard enough. 
>>
>
> Cygwin is personally of no use to me (native applications like Julia can't 
> work with it). I don't think I've ever downloaded a Sage Cygwin binary. For 
> one, it's bloated and too slow.
>
> Cygwin in not considered a native environment by serious Windows 
> developers. It's a Linux on Windows, nothing more. It doesn't even try to 
> play nice with native applications or the Windows ABI.
>
> The main reason for the existence of the MSYS2 project in their own words 
> is "better interoperability with native Windows software".
>
> You skipped the "based on modern Cygwin (POSIX compatibility layer) and 
MinGW-w64" part, that's not very fair :p

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

Re: [sage-devel] Porting SageMath to Windows 64

[Jean-Pierre Flori]

As far as I remember, apart from the lack of POSIX compatibility on 
Windows/MSYS, the main obstacle to "natively" compile Sage on Windows 64 
were:
* PARI which assumes that sizeof(long) == sizeof(void*), there is an 
experimental branch fixing this: 
http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
* GAP memory allocation, no sure this is actually an issue, see 
https://groups.google.com/d/msg/sage-devel/QXy_2KMbP1k/Z3cfpCieYzgJ for 
"details".

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 17:15:14 UTC+2, Jeroen Demeyer wrote:
>
> Is there any reason to assume that porting using MSYS2 is easier than 
> porting using Cygwin? Because the latter is already hard enough. 
>

Cygwin is personally of no use to me (native applications like Julia can't 
work with it). I don't think I've ever downloaded a Sage Cygwin binary. For 
one, it's bloated and too slow.

Cygwin in not considered a native environment by serious Windows 
developers. It's a Linux on Windows, nothing more. It doesn't even try to 
play nice with native applications or the Windows ABI.

The main reason for the existence of the MSYS2 project in their own words 
is "better interoperability with native Windows software".

It also has a proper package manager. It's really, really fast. It has a 
posix layer. It has proper Windows exception handling (including zero 
overhead exceptions) and supports a couple of different threading models. 
Basically it's an extremely high quality piece of software engineering. 


> I can the main "elephant in the room" is the POSIX layer. Many pieces of 
> Sage assume some kind of POSIX environment. 
>

Cygwin also provides a POSIX environment, so I'm not sure I understand why 
this is an "elephant in the room".

Bill.
 

>
> Jeroen. 
>

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

Perhaps I should also say that our long term plans for the Julia project I 
mentioned definitely include Gap and Singular, so we will be investing time 
and expertise into solving any issues with these, I am sure.

It's a long term strategy for sure, but not one that is going to disappear 
overnight or bitrot.

Bill.

On Wednesday, 7 October 2015 18:29:49 UTC+2, Bill Hart wrote:
>
>
>
> On Wednesday, 7 October 2015 18:18:02 UTC+2, Jean-Pierre Flori wrote:
>>
>> As far as I remember, apart from the lack of POSIX compatibility on 
>> Windows/MSYS, the main obstacle to "natively" compile Sage on Windows 64 
>> were:
>>
>
> Just to clarify, I'm not talking about MSYS. That's a different thing 
> entirely. MSYS2 has a posix layer.
>  
>
>> * PARI which assumes that sizeof(long) == sizeof(void*), there is an 
>> experimental branch fixing this: 
>> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>>
>
> I am using Pari (not GP) today on Windows 64. It was minimal effort on my 
> part to do so. I am not using a special branch.
>
>
>> * GAP memory allocation, no sure this is actually an issue, see 
>> https://groups.google.com/d/msg/sage-devel/QXy_2KMbP1k/Z3cfpCieYzgJ for 
>> "details".
>>
>
> Gasman might be an issue. My understanding is it tries to allocate all 
> available memory up front. It's also not threadsafe. But this is already an 
> issue for HPC Gap (so they use Boehm instead, as I understand it, albeit at 
> a small performance cost).
>
> Bill. 
>

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

Re: [sage-devel] Porting SageMath to Windows 64

[Jeroen Demeyer]

On 2015-10-07 18:23, Bill Hart wrote:

Cygwin also provides a POSIX environment, so I'm not sure I understand
why this is an "elephant in the room".


It's an elephant in the room because your original post completely seems 
to ignore any possible problems with the POSIX layer, while the POSIX 
layer is where most of the problems on Cygwin come from.


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

[sage-devel] Re: Porting SageMath to Windows 64

[Jean-Pierre Flori]

On Wednesday, October 7, 2015 at 8:08:30 PM UTC+2, Bill Hart wrote:
>
>
>
> On Wednesday, 7 October 2015 19:54:30 UTC+2, Dima Pasechnik wrote:
>>
>>
>>
>> On Wednesday, 7 October 2015 07:35:22 UTC-7, Bill Hart wrote:
>>>
>>> HI all,
>>>
>>> William Stein recently bemoaned the fact that SageMath currently only 
>>> runs natively on some brands of Linux, and not natively on the latest 
>>> Windows or OSX (that is to say nothing of BSD). [1]
>>>
>>> Until recently, a port of SageMath to Windows has seemed like a pipe 
>>> dream. However, things have changed a lot, and I think it would now be 
>>> possible to achieve this (for some definition of the word "native").
>>>
>>> I've tried VM's before and it has always ended in disaster. They either 
>>> screw up my networking, they have performance issues, or don't support my 
>>> mouse properly, or change my keyboard layout, or it's impossible to get 
>>> files from my hard drive into the system easily, or they take up too much 
>>> disk space or need to be constantly downloaded to update them, or some 
>>> features don't work, or people stop supporting them, etc. The disadvantages 
>>> of VMs are so numerous I hardly need to enumerate them. And even if it is a 
>>> solution for users, it's hardly a solution for serious Windows developers.
>>>
>>> As some people know, I've been recently working on a Julia based 
>>> "computer algebra system" for a much more limited subset of "computer 
>>> algebra" than Sage targets. What people may not know is that that entire 
>>> technology stack works natively on Windows.
>>>
>>> I can't express how fantastic it was to be sitting on a train recently, 
>>> with no web access whatsoever and to be able to do work on my Windows 10 
>>> (64 bit) laptop on the train. And everything ran as fast, or in some cases 
>>> faster, than my Linux server. That's the first time that has happened since 
>>> I started doing computational stuff about 10 years ago!
>>>
>>> MSYS2 as a solution
>>> 
>>>
>>> The new technology that makes all this work is MSYS2. Here are some of 
>>> its features:
>>>
>>> * Installing MSYS2 on Windows couldn't be easier. [2]
>>> * It supports proper Windows exception handling protocols.
>>> * It has an amazing command line package manager called Pacman, which 
>>> Just Works TM.
>>> * Unlike Cygwin, it's very minimal, and takes little time to install.
>>> * It's fast. Very fast.
>>> * Parallel make works.
>>> * The resulting binaries are fast, sometimes faster on my laptop than on 
>>> the Linux server I usually use for development.
>>> * MSYS2 provides a posix layer! (Applications can be distributed with an 
>>> MSYS2 dll for this.)
>>> * Multithreading using pthreads Just Works TM (Applications can be 
>>> distributed with a winthreads dll for this. I've actually used this, no 
>>> patching required, so I am not speaking theoretically here.)
>>> * Like native Windows, sizeof(long) = 4 and sizeof(long long) = 8 on 
>>> MSYS2. This means interop with native Windows applications or assembly 
>>> objects is a cynch.
>>> * The resulting applications can be run on Windows as essentially native 
>>> applications. They don't have to be run from within the MSYS2 shell. They 
>>> can also be distributed as binary packages for those that don't care about 
>>> the source code. But here's the thing: it's not *necessary* to distribute 
>>> them as binary packages. It's now quite feasible for developers to actually 
>>> *build* packages on Windows. And let's face it, this is the type of 
>>> developer we actually want on the Windows platform. Simply supporting users 
>>> and not developers is just going to increase the maintenance burden for 
>>> people who work on other platforms. We want actual Windows developers, not 
>>> just users!
>>>  
>>> The only bad thing about MSYS2 is that autotools is still incredibly 
>>> slow (Flint roll-your-own configure takes 5s at most on Windows, whereas 
>>> autotools can take some minutes to configure a package). Note: make is not 
>>> slow (at least not on Windows 64 -- it's not as fast on 32 bit Windows, but 
>>> fortunately almost no one is using Windows 32 any more anyway).
>>>
>>
>> If  MSYS2 has (Cygwin's?) fork(), it should not differ much from Cygwin, 
>> in the sense of porting of Sage.
>> fork() was the major pain on Win32, as building Python extensions results 
>> in huge number of dlls that have hard time
>> fitting into the (32bit) address space, so (semi)automatic running of 
>> rebase during the build was necessary...
>>
>
> I am really, really uninterested in Windows 32, as are, I imagine, most 
> Windows developers these days. Given that Sage is so very far behind the 
> ball game on Windows, I would skip it entirely. You will likely have to 
> visit a museum to get a working Win32 box by the time the port is complete. 
> (This was already the case back when Sage started its Cygwin port).
>
Same issue for Windows64, that's basically the way DLLs work which 

[sage-devel] Re: el capitan statement

[Harald Schilly]

I've added a very short red banner to the download osx/intel download page 
for all mirrors. It does link back here to sage-devel, to the last two 
threads I found about that. 

What I don't want is to clutter the main index.html page with this. If this 
banner is not enough, then we could also add something to the specific 
download page. 

I don't know how to word this best, but for now there is at least something 
there. What puzzles me about all this is, that even packages like git are 
broken. Why is this going on here?

-- 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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

Actually, now I'm not even sure I understand what x32 is.

I looked it up and found this page and found considerable disagreement on 
what it is:

http://stackoverflow.com/questions/7635013/difference-between-x86-x32-and-x64-architectures

I think I'll give it a miss for a while.

Bill.

On Wednesday, 7 October 2015 19:03:18 UTC+2, Bill Hart wrote:
>
>
>
> On Wednesday, 7 October 2015 18:37:41 UTC+2, Jean-Pierre Flori wrote:
>>
>>
>>
>> On Wednesday, October 7, 2015 at 6:35:36 PM UTC+2, bluescarni wrote:
>>>
>>>
> * PARI which assumes that sizeof(long) == sizeof(void*), there is an 
> experimental branch fixing this: 
> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>

 I am using Pari (not GP) today on Windows 64. It was minimal effort on 
 my part to do so. I am not using a special branch.

>>>
>>> This was a problem for the x32 architecture as well. See, e.g., here:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320
>>>
>>> Glad that the PARI devs fixed this eventually.
>>>
>> It was not fixed by an "actual" PARI dev, but what's important is that 
>> some code is now publicly available.
>>
>
> I read through that entire Debian issue and still haven't got a clue what 
> the issue was. There seems to have been a lot of arguing there about whose 
> fault this actually was. None of these people is a dummy, so I don't 
> understand why they couldn't figure it out.
>
> Anyway, x32 is not something I'm interested in supporting. It's great that 
> GMP does, and some other software does, and Flint is moving towards 
> supporting it. But it's not a priority.
>
> Bill. 
>

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

Re: [sage-devel] Re: el capitan statement

[Jeroen Demeyer]

On 2015-10-07 19:31, David Roe wrote:

In OS X 10.11, Apple changed the operating system to no longer allow
modification of certain system folders, even when logged in as root.


Why would Sage need modification to system folders? Sage can be compiled 
as an ordinary user, so I don't see how this is relevant.


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

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

Practically, it's an architecture that supports "natively" 64 bit ints but
the pointers are 32 bits wide. AFAIK, this is supposed to improve
performance for pointer-heavy workloads that do not need to allocate much
RAM but still benefit from the 64 bit ints.

On 7 October 2015 at 19:54, Bill Hart  wrote:

> Actually, now I'm not even sure I understand what x32 is.
>
> I looked it up and found this page and found considerable disagreement on
> what it is:
>
>
> http://stackoverflow.com/questions/7635013/difference-between-x86-x32-and-x64-architectures
>
> I think I'll give it a miss for a while.
>
> Bill.
>
> On Wednesday, 7 October 2015 19:03:18 UTC+2, Bill Hart wrote:
>>
>>
>>
>> On Wednesday, 7 October 2015 18:37:41 UTC+2, Jean-Pierre Flori wrote:
>>>
>>>
>>>
>>> On Wednesday, October 7, 2015 at 6:35:36 PM UTC+2, bluescarni wrote:


>> * PARI which assumes that sizeof(long) == sizeof(void*), there is an
>> experimental branch fixing this:
>> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>>
>
> I am using Pari (not GP) today on Windows 64. It was minimal effort on
> my part to do so. I am not using a special branch.
>

 This was a problem for the x32 architecture as well. See, e.g., here:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320

 Glad that the PARI devs fixed this eventually.

>>> It was not fixed by an "actual" PARI dev, but what's important is that
>>> some code is now publicly available.
>>>
>>
>> I read through that entire Debian issue and still haven't got a clue what
>> the issue was. There seems to have been a lot of arguing there about whose
>> fault this actually was. None of these people is a dummy, so I don't
>> understand why they couldn't figure it out.
>>
>> Anyway, x32 is not something I'm interested in supporting. It's great
>> that GMP does, and some other software does, and Flint is moving towards
>> supporting it. But it's not a priority.
>>
>> Bill.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

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

[sage-devel] Re: el capitan statement

[William Stein]

On Wednesday, October 7, 2015, David Roe  wrote:

> I'm confused by that as well, but apparently some people have succeeded at
> building Sage after making this change.  Maybe there are other ways that
> disabling SIP affects Sage's build.  I was trying to describe the reasons
> that users might hesitate to adapt this workaround.
> David
>

SIP also doesn't pass certain environment variables down on fork, which
breaks running or building sage completely.


>
> On Wed, Oct 7, 2015 at 2:00 PM, Jeroen Demeyer  > wrote:
>
>> On 2015-10-07 19:31, David Roe wrote:
>>
>>> In OS X 10.11, Apple changed the operating system to no longer allow
>>> modification of certain system folders, even when logged in as root.
>>>
>>
>> Why would Sage need modification to system folders? Sage can be compiled
>> as an ordinary user, so I don't see how this is relevant.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com
>> 
>> .
>> To post to this group, send email to sage-devel@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com
> 
> .
> To post to this group, send email to sage-devel@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from my massive iPhone 6 plus.

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

[sage-devel] Re: Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 19:54:30 UTC+2, Dima Pasechnik wrote:
>
>
>
> On Wednesday, 7 October 2015 07:35:22 UTC-7, Bill Hart wrote:
>>
>> HI all,
>>
>> William Stein recently bemoaned the fact that SageMath currently only 
>> runs natively on some brands of Linux, and not natively on the latest 
>> Windows or OSX (that is to say nothing of BSD). [1]
>>
>> Until recently, a port of SageMath to Windows has seemed like a pipe 
>> dream. However, things have changed a lot, and I think it would now be 
>> possible to achieve this (for some definition of the word "native").
>>
>> I've tried VM's before and it has always ended in disaster. They either 
>> screw up my networking, they have performance issues, or don't support my 
>> mouse properly, or change my keyboard layout, or it's impossible to get 
>> files from my hard drive into the system easily, or they take up too much 
>> disk space or need to be constantly downloaded to update them, or some 
>> features don't work, or people stop supporting them, etc. The disadvantages 
>> of VMs are so numerous I hardly need to enumerate them. And even if it is a 
>> solution for users, it's hardly a solution for serious Windows developers.
>>
>> As some people know, I've been recently working on a Julia based 
>> "computer algebra system" for a much more limited subset of "computer 
>> algebra" than Sage targets. What people may not know is that that entire 
>> technology stack works natively on Windows.
>>
>> I can't express how fantastic it was to be sitting on a train recently, 
>> with no web access whatsoever and to be able to do work on my Windows 10 
>> (64 bit) laptop on the train. And everything ran as fast, or in some cases 
>> faster, than my Linux server. That's the first time that has happened since 
>> I started doing computational stuff about 10 years ago!
>>
>> MSYS2 as a solution
>> 
>>
>> The new technology that makes all this work is MSYS2. Here are some of 
>> its features:
>>
>> * Installing MSYS2 on Windows couldn't be easier. [2]
>> * It supports proper Windows exception handling protocols.
>> * It has an amazing command line package manager called Pacman, which 
>> Just Works TM.
>> * Unlike Cygwin, it's very minimal, and takes little time to install.
>> * It's fast. Very fast.
>> * Parallel make works.
>> * The resulting binaries are fast, sometimes faster on my laptop than on 
>> the Linux server I usually use for development.
>> * MSYS2 provides a posix layer! (Applications can be distributed with an 
>> MSYS2 dll for this.)
>> * Multithreading using pthreads Just Works TM (Applications can be 
>> distributed with a winthreads dll for this. I've actually used this, no 
>> patching required, so I am not speaking theoretically here.)
>> * Like native Windows, sizeof(long) = 4 and sizeof(long long) = 8 on 
>> MSYS2. This means interop with native Windows applications or assembly 
>> objects is a cynch.
>> * The resulting applications can be run on Windows as essentially native 
>> applications. They don't have to be run from within the MSYS2 shell. They 
>> can also be distributed as binary packages for those that don't care about 
>> the source code. But here's the thing: it's not *necessary* to distribute 
>> them as binary packages. It's now quite feasible for developers to actually 
>> *build* packages on Windows. And let's face it, this is the type of 
>> developer we actually want on the Windows platform. Simply supporting users 
>> and not developers is just going to increase the maintenance burden for 
>> people who work on other platforms. We want actual Windows developers, not 
>> just users!
>>  
>> The only bad thing about MSYS2 is that autotools is still incredibly slow 
>> (Flint roll-your-own configure takes 5s at most on Windows, whereas 
>> autotools can take some minutes to configure a package). Note: make is not 
>> slow (at least not on Windows 64 -- it's not as fast on 32 bit Windows, but 
>> fortunately almost no one is using Windows 32 any more anyway).
>>
>
> If  MSYS2 has (Cygwin's?) fork(), it should not differ much from Cygwin, 
> in the sense of porting of Sage.
> fork() was the major pain on Win32, as building Python extensions results 
> in huge number of dlls that have hard time
> fitting into the (32bit) address space, so (semi)automatic running of 
> rebase during the build was necessary...
>

I am really, really uninterested in Windows 32, as are, I imagine, most 
Windows developers these days. Given that Sage is so very far behind the 
ball game on Windows, I would skip it entirely. You will likely have to 
visit a museum to get a working Win32 box by the time the port is complete. 
(This was already the case back when Sage started its Cygwin port).
 

>
> (Note that on Cygwin (like elsewhere) Sage does not use Cygwin's python, 
> it uses its own Python, which
> seems to be quite different from Cygwin's Python)
>

Seriously? So SageMath also risks not even having a supported Python in 

Re: [sage-devel] Re: el capitan statement

[David Roe]

On Wed, Oct 7, 2015 at 2:06 PM, Dima Pasechnik  wrote:

> On Wednesday, 7 October 2015 11:00:14 UTC-7, Jeroen Demeyer wrote:
>>
>> On 2015-10-07 19:31, David Roe wrote:
>> > In OS X 10.11, Apple changed the operating system to no longer allow
>> > modification of certain system folders, even when logged in as root.
>>
>> Why would Sage need modification to system folders? Sage can be compiled
>> as an ordinary user, so I don't see how this is relevant.
>>
>> this is probably indeed irrelevant. What is relevant is they apparently
> managed to break LD_LIBRARY_PATH etc things,
> and this prevents one from doing pretty much anything that relies on this.
>
> Also, please note that there are two  different systems OSX 10.11, and OX
> 11.? (El Capitan), which both suffer from this.
>

What is OX 11.?? I know that the Sage thread was titled OS X 11.11, but I
thought that was a typo
David

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

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 20:05:11 UTC+2, bluescarni wrote:
>
> Practically, it's an architecture that supports "natively" 64 bit ints but 
> the pointers are 32 bits wide. AFAIK, this is supposed to improve 
> performance for pointer-heavy workloads that do not need to allocate much 
> RAM but still benefit from the 64 bit ints.
>

I could be wrong, but this doesn't sound like it includes SageMath. :-)
 

>
> On 7 October 2015 at 19:54, Bill Hart  > wrote:
>
>> Actually, now I'm not even sure I understand what x32 is.
>>
>> I looked it up and found this page and found considerable disagreement on 
>> what it is:
>>
>>
>> http://stackoverflow.com/questions/7635013/difference-between-x86-x32-and-x64-architectures
>>
>> I think I'll give it a miss for a while.
>>
>> Bill.
>>
>> On Wednesday, 7 October 2015 19:03:18 UTC+2, Bill Hart wrote:
>>>
>>>
>>>
>>> On Wednesday, 7 October 2015 18:37:41 UTC+2, Jean-Pierre Flori wrote:



 On Wednesday, October 7, 2015 at 6:35:36 PM UTC+2, bluescarni wrote:
>
>
>>> * PARI which assumes that sizeof(long) == sizeof(void*), there is an 
>>> experimental branch fixing this: 
>>> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>>>
>>
>> I am using Pari (not GP) today on Windows 64. It was minimal effort 
>> on my part to do so. I am not using a special branch.
>>
>
> This was a problem for the x32 architecture as well. See, e.g., here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320
>
> Glad that the PARI devs fixed this eventually.
>
 It was not fixed by an "actual" PARI dev, but what's important is that 
 some code is now publicly available.

>>>
>>> I read through that entire Debian issue and still haven't got a clue 
>>> what the issue was. There seems to have been a lot of arguing there about 
>>> whose fault this actually was. None of these people is a dummy, so I don't 
>>> understand why they couldn't figure it out.
>>>
>>> Anyway, x32 is not something I'm interested in supporting. It's great 
>>> that GMP does, and some other software does, and Flint is moving towards 
>>> supporting it. But it's not a priority.
>>>
>>> Bill. 
>>>
>> -- 
>> 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 http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 20:06:41 UTC+2, bluescarni wrote:
>
> I think in FLINT you also have the issue that you are using tagged 
> pointers (last time I checked anyway).
>

Yeah, we merged some patches recently to fix some of the issues here. I 
don't think we got them all yet.

Sometimes compilers actually give warnings about this, but in a few cases 
I'm pretty convinced the compiler warning is actually incorrect.

Eventually we'll sort it out.
 

>
> On 7 October 2015 at 20:03, Bill Hart  > wrote:
>
>>
>>
>> On Wednesday, 7 October 2015 19:48:54 UTC+2, bluescarni wrote:
>>>
>>> PARI requires (required?) sizeof(mp_limb_t)==sizeof(void*), which is not 
>>> guaranteed and not enforceable by PARI (as it's up to GMP to decide what 
>>> exactly an mp_limb_t is).
>>>
>>
>> I think I understand now. I was misled by the person claiming Pari 
>> required sizeof(long) == sizeof(void*) and Bill Allombert debunking it. 
>> Bill was of course correct (he is a Pari dev).
>>
>> As for assuming sizeof(mp_limb_t) == sizeof(void*) we probably have the 
>> same issue in Flint. We will very slowly address this and have been making 
>> patches here and there. It's not a priority.
>>
>> However, that issue is entirely irrelevant to MSYS2. By default on that 
>> system both sizeof(mp_limb_t) and sizeof(void*) are 8 on Windows 64.
>>
>> The x32 issue is only affecting people who are wanting to support this 
>> trendy new ABI.
>>
>> Bill.
>>
>> -- 
>> 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 http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Jean-Pierre Flori]

On Wednesday, October 7, 2015 at 8:03:15 PM UTC+2, Bill Hart wrote:
>
>
>
> On Wednesday, 7 October 2015 19:48:54 UTC+2, bluescarni wrote:
>>
>> PARI requires (required?) sizeof(mp_limb_t)==sizeof(void*), which is not 
>> guaranteed and not enforceable by PARI (as it's up to GMP to decide what 
>> exactly an mp_limb_t is).
>>
>
> I think I understand now. I was misled by the person claiming Pari 
> required sizeof(long) == sizeof(void*) and Bill Allombert debunking it. 
> Bill was of course correct (he is a Pari dev).
>
Pari also needed till recently sizeof(long) == sizeof(void*)
Look at 
http://pari.math.u-bordeaux.fr/cgi-bin/gitweb.cgi?p=pari.git;a=blob;f=src/headers/parigen.h;h=b8347dcfedd3e98154238faa4cb6eb04ce80d810;hb=HEAD#l16
This is dark magic to ensure that long get defined as long long on Windows 
64.
This is also mentioned at page 5 here: raim2013.lip6.fr/theme/PDF/*PARI*-
*GP*/[Belabas]*PARI*_*GP*.pdf

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

[sage-devel] Re: Porting SageMath to Windows 64

[Dima Pasechnik]

On Wednesday, 7 October 2015 07:35:22 UTC-7, Bill Hart wrote:
>
> HI all,
>
> William Stein recently bemoaned the fact that SageMath currently only runs 
> natively on some brands of Linux, and not natively on the latest Windows or 
> OSX (that is to say nothing of BSD). [1]
>
> Until recently, a port of SageMath to Windows has seemed like a pipe 
> dream. However, things have changed a lot, and I think it would now be 
> possible to achieve this (for some definition of the word "native").
>
> I've tried VM's before and it has always ended in disaster. They either 
> screw up my networking, they have performance issues, or don't support my 
> mouse properly, or change my keyboard layout, or it's impossible to get 
> files from my hard drive into the system easily, or they take up too much 
> disk space or need to be constantly downloaded to update them, or some 
> features don't work, or people stop supporting them, etc. The disadvantages 
> of VMs are so numerous I hardly need to enumerate them. And even if it is a 
> solution for users, it's hardly a solution for serious Windows developers.
>
> As some people know, I've been recently working on a Julia based "computer 
> algebra system" for a much more limited subset of "computer algebra" than 
> Sage targets. What people may not know is that that entire technology stack 
> works natively on Windows.
>
> I can't express how fantastic it was to be sitting on a train recently, 
> with no web access whatsoever and to be able to do work on my Windows 10 
> (64 bit) laptop on the train. And everything ran as fast, or in some cases 
> faster, than my Linux server. That's the first time that has happened since 
> I started doing computational stuff about 10 years ago!
>
> MSYS2 as a solution
> 
>
> The new technology that makes all this work is MSYS2. Here are some of its 
> features:
>
> * Installing MSYS2 on Windows couldn't be easier. [2]
> * It supports proper Windows exception handling protocols.
> * It has an amazing command line package manager called Pacman, which Just 
> Works TM.
> * Unlike Cygwin, it's very minimal, and takes little time to install.
> * It's fast. Very fast.
> * Parallel make works.
> * The resulting binaries are fast, sometimes faster on my laptop than on 
> the Linux server I usually use for development.
> * MSYS2 provides a posix layer! (Applications can be distributed with an 
> MSYS2 dll for this.)
> * Multithreading using pthreads Just Works TM (Applications can be 
> distributed with a winthreads dll for this. I've actually used this, no 
> patching required, so I am not speaking theoretically here.)
> * Like native Windows, sizeof(long) = 4 and sizeof(long long) = 8 on 
> MSYS2. This means interop with native Windows applications or assembly 
> objects is a cynch.
> * The resulting applications can be run on Windows as essentially native 
> applications. They don't have to be run from within the MSYS2 shell. They 
> can also be distributed as binary packages for those that don't care about 
> the source code. But here's the thing: it's not *necessary* to distribute 
> them as binary packages. It's now quite feasible for developers to actually 
> *build* packages on Windows. And let's face it, this is the type of 
> developer we actually want on the Windows platform. Simply supporting users 
> and not developers is just going to increase the maintenance burden for 
> people who work on other platforms. We want actual Windows developers, not 
> just users!
>  
> The only bad thing about MSYS2 is that autotools is still incredibly slow 
> (Flint roll-your-own configure takes 5s at most on Windows, whereas 
> autotools can take some minutes to configure a package). Note: make is not 
> slow (at least not on Windows 64 -- it's not as fast on 32 bit Windows, but 
> fortunately almost no one is using Windows 32 any more anyway).
>

If  MSYS2 has (Cygwin's?) fork(), it should not differ much from Cygwin, in 
the sense of porting of Sage.
fork() was the major pain on Win32, as building Python extensions results 
in huge number of dlls that have hard time
fitting into the (32bit) address space, so (semi)automatic running of 
rebase during the build was necessary...

(Note that on Cygwin (like elsewhere) Sage does not use Cygwin's python, it 
uses its own Python, which
seems to be quite different from Cygwin's Python)

OK, let me try to see if one gets anywhere with GAP on MSYS2...

Cheers,
Dima


Proposal
> ===
>
> What I propose is to begin porting Sage dependencies to Windows (note that 
> by Windows, I mean Windows 64, i.e. what everyone is using). What this 
> would mean is porting them to MSYS2 (at least initially). Note it's not a 
> big step from there to MinGW or MSVC if people want to do that later. 
> Microsoft have made MSVC much, much more friendly to GNU conventions, 
> recently. (For some users, porting to Windows natively is synonymous with 
> supporting MSVC using Visual Solution files. But I'm 

Re: [sage-devel] Re: el capitan statement

[David Roe]

I'm confused by that as well, but apparently some people have succeeded at
building Sage after making this change.  Maybe there are other ways that
disabling SIP affects Sage's build.  I was trying to describe the reasons
that users might hesitate to adapt this workaround.
David

On Wed, Oct 7, 2015 at 2:00 PM, Jeroen Demeyer 
wrote:

> On 2015-10-07 19:31, David Roe wrote:
>
>> In OS X 10.11, Apple changed the operating system to no longer allow
>> modification of certain system folders, even when logged in as root.
>>
>
> Why would Sage need modification to system folders? Sage can be compiled
> as an ordinary user, so I don't see how this is relevant.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 19:48:54 UTC+2, bluescarni wrote:
>
> PARI requires (required?) sizeof(mp_limb_t)==sizeof(void*), which is not 
> guaranteed and not enforceable by PARI (as it's up to GMP to decide what 
> exactly an mp_limb_t is).
>

I think I understand now. I was misled by the person claiming Pari required 
sizeof(long) == sizeof(void*) and Bill Allombert debunking it. Bill was of 
course correct (he is a Pari dev).

As for assuming sizeof(mp_limb_t) == sizeof(void*) we probably have the 
same issue in Flint. We will very slowly address this and have been making 
patches here and there. It's not a priority.

However, that issue is entirely irrelevant to MSYS2. By default on that 
system both sizeof(mp_limb_t) and sizeof(void*) are 8 on Windows 64.

The x32 issue is only affecting people who are wanting to support this 
trendy new ABI.

Bill.

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

[sage-devel] Re: el capitan statement

[William Stein]

On Wednesday, October 7, 2015, Thomas Judson  wrote:

> I understand the problem a bit better now, but I haven’t tried disabling
> the system integrity protection yet.
>
>
Oh good.  I thought you had.  Very good to know disability sip works.



> Tom
>
> > On Oct 7, 2015, at 12:38 PM, William Stein  > wrote:
> >
> >
> >
> > On Wednesday, October 7, 2015, David Roe  > wrote:
> > The only reports I've seen, on
> https://groups.google.com/forum/#!topic/sage-devel/OBv5x1v3_6M, have been
> positive.  What conflicting reports have you received?
> >
> >
> >
> >
> > I think Tom Judson said it doesn't work.
> >
> >
> > I haven't tried it myself; I'm still running 10.9.
> >
> > Here's a summary for how to disable it:
> >
> > 1. Reboot, holding down Cmd-R to start in Recovery Mode.
> > 2. In a terminal window, execute csrutil disable
> > 3. Reboot back into non-Recovery Mode.
> >
> > Here's a warning for why you might hesitate (this is my understanding of
> the issue; someone please correct me if I'm wrong):
> >
> > In OS X 10.11, Apple changed the operating system to no longer allow
> modification of certain system folders, even when logged in as root.  They
> made this change to make it more difficult for malware to affect the
> operating system, but it has the side effect of disrupting Sage's current
> build process.  Disabling system integrity protection may allow you to
> build Sage, but it also disables a security feature of your operating
> system.
> >
> > David
> >
> > On Wed, Oct 7, 2015 at 12:52 PM, William Stein  > wrote:
> >
> >
> > On Wednesday, October 7, 2015, David Roe  > wrote:
> > Do you want to mention the possibility of disabling system integrity
> protection, or are you purposefully avoiding that option?
> > David
> >
> >
> > To what extent does it actually really work?  To what extent?  I've got
> conflicting reports.
> >
> > I think we should mention it.
> >
> >
> > On Wed, Oct 7, 2015 at 12:38 PM, William Stein  > wrote:
> > Hi,
> >
> > We need to post a statement on the Sagemath.org website about the El
> > Capitan os x 10.11 situation, since I'm getting (or will be getting)
> > emails "left and right" from people freaking out about this.
> > Here's one answer -- how could it be reworded to be right?
> >
> > ---
> > Hi,
> >
> > As far as I know, there is no way to run Sage on OS X anymore (except
> > by using VirtualBox), and I don't know when/if this will change.
> > Here's one recent discussion of ongoing work:
> >
> > https://groups.google.com/forum/#!topic/sage-devel/-ZVSh5adEkY
> >
> > Basically apple made many fundamental changes to OS X  10.11 that
> > fundamentally breaks a large ecosystem of open source software.
> >
> > Fixing these things will take time, and I have no idea how long.
> >
> > William
> > ---
> >
> > --
> > William (http://wstein.org)
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com .
> > To post to this group, send email to sage-devel@googlegroups.com
> .
> > Visit this group at http://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 http://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > Sent from my massive iPhone 6 plus.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com .
> > To post to this group, send email to sage-devel@googlegroups.com
> .
> > Visit this group at http://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com .
> > To post to this group, send email to sage-devel@googlegroups.com
> .
> > Visit this group at http://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > 

Re: [sage-devel] Re: el capitan statement

[Dima Pasechnik]

On Wednesday, 7 October 2015 11:00:14 UTC-7, Jeroen Demeyer wrote:
>
> On 2015-10-07 19:31, David Roe wrote: 
> > In OS X 10.11, Apple changed the operating system to no longer allow 
> > modification of certain system folders, even when logged in as root. 
>
> Why would Sage need modification to system folders? Sage can be compiled 
> as an ordinary user, so I don't see how this is relevant. 
>
> this is probably indeed irrelevant. What is relevant is they apparently 
managed to break LD_LIBRARY_PATH etc things,
and this prevents one from doing pretty much anything that relies on this.

Also, please note that there are two  different systems OSX 10.11, and OX 
11.? (El Capitan), which both suffer from 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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

I think in FLINT you also have the issue that you are using tagged pointers
(last time I checked anyway).

On 7 October 2015 at 20:03, Bill Hart  wrote:

>
>
> On Wednesday, 7 October 2015 19:48:54 UTC+2, bluescarni wrote:
>>
>> PARI requires (required?) sizeof(mp_limb_t)==sizeof(void*), which is not
>> guaranteed and not enforceable by PARI (as it's up to GMP to decide what
>> exactly an mp_limb_t is).
>>
>
> I think I understand now. I was misled by the person claiming Pari
> required sizeof(long) == sizeof(void*) and Bill Allombert debunking it.
> Bill was of course correct (he is a Pari dev).
>
> As for assuming sizeof(mp_limb_t) == sizeof(void*) we probably have the
> same issue in Flint. We will very slowly address this and have been making
> patches here and there. It's not a priority.
>
> However, that issue is entirely irrelevant to MSYS2. By default on that
> system both sizeof(mp_limb_t) and sizeof(void*) are 8 on Windows 64.
>
> The x32 issue is only affecting people who are wanting to support this
> trendy new ABI.
>
> Bill.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

On 7 October 2015 at 20:13, Bill Hart  wrote:

> I could be wrong, but this doesn't sound like it includes SageMath. :-)
>

Probably :)

I am not sure about the allocation limit, as the limit might only apply to
large contiguous allocations. Or there might be other memory addressing
tricks at play. Not 100% sure.

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

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

>
>
>> * PARI which assumes that sizeof(long) == sizeof(void*), there is an
>> experimental branch fixing this:
>> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>>
>
> I am using Pari (not GP) today on Windows 64. It was minimal effort on my
> part to do so. I am not using a special branch.
>

This was a problem for the x32 architecture as well. See, e.g., here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320

Glad that the PARI devs fixed this eventually.

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

Re: [sage-devel] Re: threejs

[kcrisman]

> I think it is already the default way to show 3d graphics in the notebook 
> in the last versions. Isn't it?
>
> Correct.  But I think he means how to use it from the *command line* - 
yes?  I wouldn't know about this; one would have to autolaunch a browser, I 
guess, and other annoyances, not to mention creating things... but it 
should be possible without any new packages or anything.
 

> El miércoles, 7 de octubre de 2015, 9:28:32 (UTC+2), tdumont escribió:
>>
>> Le 07/10/2015 08:42, kcrisman a écrit : 
>> > > 
>> > 
>> > MMMhhh, interesting! 
>> > 
>> > Do you think it would be possible to replace jmol by jsmol in sage? 
>> > or keep both and choose which on to use? 
>> > 
>> > 
>> > This is already possible!  In the notebook - thanks to tons of work by 
>> > Jonathan and Volker.  I don't know how that would work from command 
>> line 
>> > though, as it would have to open a browser or something? 
>> > 
>> > -- 
>>
>>
>> Great, yes, but how do I proceed to switch to jsmol? 
>>
>> yours 
>> t. 
>>
>> > 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 http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Jean-Pierre Flori]

On Wednesday, October 7, 2015 at 6:35:36 PM UTC+2, bluescarni wrote:
>
>
>>> * PARI which assumes that sizeof(long) == sizeof(void*), there is an 
>>> experimental branch fixing this: 
>>> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>>>
>>
>> I am using Pari (not GP) today on Windows 64. It was minimal effort on my 
>> part to do so. I am not using a special branch.
>>
>
> This was a problem for the x32 architecture as well. See, e.g., here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320
>
> Glad that the PARI devs fixed this eventually.
>
It was not fixed by an "actual" PARI dev, but what's important is that some 
code is now publicly available.

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 17:38:00 UTC+2, bluescarni wrote:
>
> Some random thoughts:
>
> - I am not so convinced the strategy of automatic long -> long long 
> patching is actually feasible, I think in practice this is gonna be a big 
> can of worms. Pushing upstream to fix their code is a much better long-term 
> solution IMO (and I'd rather have nothing to do with projects which refuse 
> portability and code-quality patches, but that's just me :)
>

I agree that's better if they will allow it. But I'm not sure some of the 
things SageMath depends on are even still maintained, let alone do all 
projects have the resources to keep maintaining such things, which is 
eventually what they get asked to do. Moreover, not all developers feel 
equally warm and fuzzy when you mention Windows. Some people are positively 
against supporting Windows. So what I am suggesting is a pragmatic 
compromise. And based on what I've seen with Pari, it works quite well. (I 
am sorry, I just haven't had the chance to look up when this porting work 
was done and how often it has been maintained, but I think it was something 
like 2008 or 2010 and with zero maintenance since, and it still works 
today).
 

> - mingw-w64 is a high quality compiler. I recently had to develop for a 
> while on a Windows 64 machine, and had to recompile a full stacks of 
> dependencies (MPFR, GMP, Boost, etc.). It was not so easy (most issues were 
> related to build systems), but the end result was pretty impressive 
> performance-wise.
> - While for C code you can probably interoperate with libraries compiled 
> with MSVC, for C++ you will end up having issues related, e.g., to 
> different implementations of exception handling. My suggestion would be to 
> forget about MSVC and compile the full stack of dependencies exclusively 
> with mingw.
> - Python on windows 64 does not play properly with mingw due to some 
> long-standing issues in some header files. If you want to compile Python 
> C/C++ extensions on Win64 you will have to patch slightly the Python 
> headers and re-generate the definitions of the Python library. The issue is 
> explored, e.g., here:
>
>
> http://ascend4.org/Setting_up_a_MinGW-w64_build_environment#Setup_Python_for_compilation_of_extensions
>
> Generally speaking, mingw-w64 is a really good option for C/C++ 
> development on Windows. The biggest problem is the proliferation of 
> distributions (mingw-w64, TDM mingw, mingw-build, msys2, etc.), but the 
> toolchain is solid. clang is getting there as well, so it's worth keeping 
> it in mind for the future.
>
> Cheers,
>
>   Francesco.
>
>
> On 7 October 2015 at 16:35, Bill Hart  > wrote:
>
>> HI all,
>>
>> William Stein recently bemoaned the fact that SageMath currently only 
>> runs natively on some brands of Linux, and not natively on the latest 
>> Windows or OSX (that is to say nothing of BSD). [1]
>>
>> Until recently, a port of SageMath to Windows has seemed like a pipe 
>> dream. However, things have changed a lot, and I think it would now be 
>> possible to achieve this (for some definition of the word "native").
>>
>> I've tried VM's before and it has always ended in disaster. They either 
>> screw up my networking, they have performance issues, or don't support my 
>> mouse properly, or change my keyboard layout, or it's impossible to get 
>> files from my hard drive into the system easily, or they take up too much 
>> disk space or need to be constantly downloaded to update them, or some 
>> features don't work, or people stop supporting them, etc. The disadvantages 
>> of VMs are so numerous I hardly need to enumerate them. And even if it is a 
>> solution for users, it's hardly a solution for serious Windows developers.
>>
>> As some people know, I've been recently working on a Julia based 
>> "computer algebra system" for a much more limited subset of "computer 
>> algebra" than Sage targets. What people may not know is that that entire 
>> technology stack works natively on Windows.
>>
>> I can't express how fantastic it was to be sitting on a train recently, 
>> with no web access whatsoever and to be able to do work on my Windows 10 
>> (64 bit) laptop on the train. And everything ran as fast, or in some cases 
>> faster, than my Linux server. That's the first time that has happened since 
>> I started doing computational stuff about 10 years ago!
>>
>> MSYS2 as a solution
>> 
>>
>> The new technology that makes all this work is MSYS2. Here are some of 
>> its features:
>>
>> * Installing MSYS2 on Windows couldn't be easier. [2]
>> * It supports proper Windows exception handling protocols.
>> * It has an amazing command line package manager called Pacman, which 
>> Just Works TM.
>> * Unlike Cygwin, it's very minimal, and takes little time to install.
>> * It's fast. Very fast.
>> * Parallel make works.
>> * The resulting binaries are fast, sometimes faster on my laptop than on 
>> the Linux server I 

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 18:33:01 UTC+2, Jeroen Demeyer wrote:
>
> On 2015-10-07 18:23, Bill Hart wrote: 
> > Cygwin also provides a POSIX environment, so I'm not sure I understand 
> > why this is an "elephant in the room". 
>
> It's an elephant in the room because your original post completely seems 
> to ignore any possible problems with the POSIX layer, while the POSIX 
> layer is where most of the problems on Cygwin come from. 
>

You mean there were bugs in the way posix was implemented in Cygwin?

I would have to see some examples to be able to judge how serious a problem 
this would be. I suspect Lisp might be problematic. But how many features 
of Sage that the average user makes use of hit these issues?

Anyway, the alternative is pretty much to do nothing. 

Bill.

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

[sage-devel] Re: el capitan statement

[William Stein]

On Wednesday, October 7, 2015, David Roe  wrote:

> Do you want to mention the possibility of disabling system integrity
> protection, or are you purposefully avoiding that option?
> David
>


To what extent does it actually really work?  To what extent?  I've got
conflicting reports.

I think we should mention it.


>
> On Wed, Oct 7, 2015 at 12:38 PM, William Stein  > wrote:
>
>> Hi,
>>
>> We need to post a statement on the Sagemath.org website about the El
>> Capitan os x 10.11 situation, since I'm getting (or will be getting)
>> emails "left and right" from people freaking out about this.
>> Here's one answer -- how could it be reworded to be right?
>>
>> ---
>> Hi,
>>
>> As far as I know, there is no way to run Sage on OS X anymore (except
>> by using VirtualBox), and I don't know when/if this will change.
>> Here's one recent discussion of ongoing work:
>>
>> https://groups.google.com/forum/#!topic/sage-devel/-ZVSh5adEkY
>>
>> Basically apple made many fundamental changes to OS X  10.11 that
>> fundamentally breaks a large ecosystem of open source software.
>>
>> Fixing these things will take time, and I have no idea how long.
>>
>> William
>> ---
>>
>> --
>> William (http://wstein.org)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com
>> 
>> .
>> To post to this group, send email to sage-devel@googlegroups.com
>> .
>> Visit this group at http://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 http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from my massive iPhone 6 plus.

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 18:33:58 UTC+2, Jean-Pierre Flori wrote:
>
>
>
> On Wednesday, October 7, 2015 at 6:23:21 PM UTC+2, Bill Hart wrote:
>>
>>
>>
>> On Wednesday, 7 October 2015 17:15:14 UTC+2, Jeroen Demeyer wrote:
>>>
>>> Is there any reason to assume that porting using MSYS2 is easier than 
>>> porting using Cygwin? Because the latter is already hard enough. 
>>>
>>
>> Cygwin is personally of no use to me (native applications like Julia 
>> can't work with it). I don't think I've ever downloaded a Sage Cygwin 
>> binary. For one, it's bloated and too slow.
>>
>> Cygwin in not considered a native environment by serious Windows 
>> developers. It's a Linux on Windows, nothing more. It doesn't even try to 
>> play nice with native applications or the Windows ABI.
>>
>> The main reason for the existence of the MSYS2 project in their own words 
>> is "better interoperability with native Windows software".
>>
>> You skipped the "based on modern Cygwin (POSIX compatibility layer) and 
> MinGW-w64" part, that's not very fair :p
>

I really meant, the main reason given that Cygwin already exists. I think 
that the posix compatibility layer and MinGW-w64 are both features, but 
don't explain why it exists in the presence of other such projects.

Bill. 

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

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

>
> I agree that's better if they will allow it. But I'm not sure some of the
> things SageMath depends on are even still maintained, let alone do all
> projects have the resources to keep maintaining such things, which is
> eventually what they get asked to do. Moreover, not all developers feel
> equally warm and fuzzy when you mention Windows. Some people are positively
> against supporting Windows. So what I am suggesting is a pragmatic
> compromise. And based on what I've seen with Pari, it works quite well. (I
> am sorry, I just haven't had the chance to look up when this porting work
> was done and how often it has been maintained, but I think it was something
> like 2008 or 2010 and with zero maintenance since, and it still works
> today).
>

I think we risk of mixing different things up. One thing is actively
supporting a Windows port from the point of view of build systems,
providing binary packages, and so on (which people might or might not want
to do due to personal inclinations, time/effort tradeoffs, etc.), another
thing is code quality. The issue above with PARI, for instance, was
affecting Linux x32 as well and it is just poor engineering in general.

I think that a high-quality project not providing support for on a OS as a
"first-class citizen" is fixable with relatively little effort, even if
upstream is not cooperative. To some extent, that is what the packagers of
linux distributions do. But it becomes orders of magnitude more difficult
if the project relies on platform-dependent system calls, libraries, or if
it just happens to work only on specific arch/OS setups.

Personally I don't care about Windows or OSX as a user, but I make sure my
software does compile and run properly on those platforms as a matter of
code quality. Also, as you pointed out, it helps a lot if one starts doing
this early in the development.

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

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 18:56:47 UTC+2, bluescarni wrote:
>
> I agree that's better if they will allow it. But I'm not sure some of the 
>> things SageMath depends on are even still maintained, let alone do all 
>> projects have the resources to keep maintaining such things, which is 
>> eventually what they get asked to do. Moreover, not all developers feel 
>> equally warm and fuzzy when you mention Windows. Some people are positively 
>> against supporting Windows. So what I am suggesting is a pragmatic 
>> compromise. And based on what I've seen with Pari, it works quite well. (I 
>> am sorry, I just haven't had the chance to look up when this porting work 
>> was done and how often it has been maintained, but I think it was something 
>> like 2008 or 2010 and with zero maintenance since, and it still works 
>> today).
>>
>
> I think we risk of mixing different things up. One thing is actively 
> supporting a Windows port from the point of view of build systems, 
> providing binary packages, and so on (which people might or might not want 
> to do due to personal inclinations, time/effort tradeoffs, etc.), another 
> thing is code quality. The issue above with PARI, for instance, was 
> affecting Linux x32 as well and it is just poor engineering in general.
>
> I think that a high-quality project not providing support for on a OS as a 
> "first-class citizen" is fixable with relatively little effort, even if 
> upstream is not cooperative. To some extent, that is what the packagers of 
> linux distributions do. But it becomes orders of magnitude more difficult 
> if the project relies on platform-dependent system calls, libraries, or if 
> it just happens to work only on specific arch/OS setups.
>
> Personally I don't care about Windows or OSX as a user, but I make sure my 
> software does compile and run properly on those platforms as a matter of 
> code quality. Also, as you pointed out, it helps a lot if one starts doing 
> this early in the development.
>

Those are fair comments. But I'm not talking about the theoretical 
possibility of maybe thinking about Windows support. I'm actually right now 
building and using software on Windows.

What I'm trying to get started is a discussion about SageMath actually 
supporting Windows.

There's no practical way that can happen if we just decide that it's poor 
software engineering to not support a variety of OS's and that the reason 
nothing happens on Windows is because Sage picked a whole pile of 
dependencies that were designed by people who were poor software engineers. 
That won't lead to a practical solution to the problem. Sage is clearly not 
going to decide that these projects should no longer be used and kick them 
out. We are stuck with the choices that were made, for better or for worse 
(though I have personally learned a lot from the mistakes that have been 
made!)

As upstream packages are sometimes quite hostile to the idea of supporting 
Windows the proper way, it's clearly not pragmatic to impose the 
responsibility of fixing the problem on them. And experience shows they 
won't even accept the patches if you do it yourself.

The only practical solution in such instances is to do the patching in an 
automated way. You most certainly do not want to have an ongoing 
maintenance burden.

Bill.

 

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

[sage-devel] Re: Porting SageMath to Windows 64

[kcrisman]

> William Stein recently bemoaned the fact that SageMath currently only runs 
> natively on some brands of Linux, and not natively on the latest Windows or 
> OSX (that is to say nothing of BSD). [1]
>
>  
Sage works on FreeBSD, or did recently, anyway; I haven't heard anything 
recently. 
 See http://trac.sagemath.org/query?status=!closed=porting%3A+BSD 
for some tickets, perhaps some outdated.
 

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

[sage-devel] el capitan statement

[William Stein]

Hi,

We need to post a statement on the Sagemath.org website about the El
Capitan os x 10.11 situation, since I'm getting (or will be getting)
emails "left and right" from people freaking out about this.
Here's one answer -- how could it be reworded to be right?

---
Hi,

As far as I know, there is no way to run Sage on OS X anymore (except
by using VirtualBox), and I don't know when/if this will change.
Here's one recent discussion of ongoing work:

https://groups.google.com/forum/#!topic/sage-devel/-ZVSh5adEkY

Basically apple made many fundamental changes to OS X  10.11 that
fundamentally breaks a large ecosystem of open source software.

Fixing these things will take time, and I have no idea how long.

William
---

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

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

Re: [sage-devel] el capitan statement

[David Roe]

Do you want to mention the possibility of disabling system integrity
protection, or are you purposefully avoiding that option?
David

On Wed, Oct 7, 2015 at 12:38 PM, William Stein  wrote:

> Hi,
>
> We need to post a statement on the Sagemath.org website about the El
> Capitan os x 10.11 situation, since I'm getting (or will be getting)
> emails "left and right" from people freaking out about this.
> Here's one answer -- how could it be reworded to be right?
>
> ---
> Hi,
>
> As far as I know, there is no way to run Sage on OS X anymore (except
> by using VirtualBox), and I don't know when/if this will change.
> Here's one recent discussion of ongoing work:
>
> https://groups.google.com/forum/#!topic/sage-devel/-ZVSh5adEkY
>
> Basically apple made many fundamental changes to OS X  10.11 that
> fundamentally breaks a large ecosystem of open source software.
>
> Fixing these things will take time, and I have no idea how long.
>
> William
> ---
>
> --
> William (http://wstein.org)
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Bill Hart]

On Wednesday, 7 October 2015 18:37:41 UTC+2, Jean-Pierre Flori wrote:
>
>
>
> On Wednesday, October 7, 2015 at 6:35:36 PM UTC+2, bluescarni wrote:
>>
>>
 * PARI which assumes that sizeof(long) == sizeof(void*), there is an 
 experimental branch fixing this: 
 http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html

>>>
>>> I am using Pari (not GP) today on Windows 64. It was minimal effort on 
>>> my part to do so. I am not using a special branch.
>>>
>>
>> This was a problem for the x32 architecture as well. See, e.g., here:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320
>>
>> Glad that the PARI devs fixed this eventually.
>>
> It was not fixed by an "actual" PARI dev, but what's important is that 
> some code is now publicly available.
>

I read through that entire Debian issue and still haven't got a clue what 
the issue was. There seems to have been a lot of arguing there about whose 
fault this actually was. None of these people is a dummy, so I don't 
understand why they couldn't figure it out.

Anyway, x32 is not something I'm interested in supporting. It's great that 
GMP does, and some other software does, and Flint is moving towards 
supporting it. But it's not a priority.

Bill. 

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

Re: [sage-devel] Porting SageMath to Windows 64

[Jeroen Demeyer]

On 2015-10-07 18:50, Bill Hart wrote:



On Wednesday, 7 October 2015 18:33:01 UTC+2, Jeroen Demeyer wrote:

On 2015-10-07 18:23, Bill Hart wrote:
 > Cygwin also provides a POSIX environment, so I'm not sure I
understand
 > why this is an "elephant in the room".

It's an elephant in the room because your original post completely
seems
to ignore any possible problems with the POSIX layer, while the POSIX
layer is where most of the problems on Cygwin come from.


You mean there were bugs in the way posix was implemented in Cygwin?
Well, it's not really bugs. The problem is that some things just don't 
have a Windows equivalent. fork() is a good example, that just doesn't 
exist on Windows.


Jeroen.

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