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,
t
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 differe
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
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.
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 sy
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
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
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
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
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
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 c
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
>
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 c
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.
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 bu
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 l
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 lat
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 s
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
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 n
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 he
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
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, 201
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 per
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
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 Wednesd
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
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,
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, 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'
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 Rec
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
>> eve
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 elepha
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-bordea
>
> 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
>
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
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 s
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 complet
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
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 mu
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
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
> 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
>
>
>> * 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 s
> 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
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.
>>
>
> C
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
la
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
overnigh
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 thi
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 wit
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-d
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 proje
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 bec
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 ha
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 doi
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 somethin
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
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!
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 thin
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 Vol
60 matches
Mail list logo
