On Tue, 22 May 2012 19:08:02 +0100
Bill Hart wrote:
> On Tuesday, 22 May 2012, Bill Hart
> wrote:
> >
> >
> > On Tuesday, 22 May 2012, Jeroen Demeyer
> > wrote:
> >> On 2012-05-22 15:37, Bill Hart wrote:
> >>> We could then
> >>> ditch building Yasm on Linux, which would save some headaches for
On Mon, May 21, 2012 at 1:14 PM, Bill Hart wrote:
> At last there is a serious alternative for users of Git on Windows:
> https://github.com/blog/1127-github-for-windows
Have you looked at Git Extensions? I find it a very useful GUI for Windows:
http://code.google.com/p/gitextensions/
Jeff.
--
On Tuesday, 22 May 2012, Bill Hart wrote:
>
>
> On Tuesday, 22 May 2012, Jeroen Demeyer wrote:
>> On 2012-05-22 15:37, Bill Hart wrote:
>>> We could then
>>> ditch building Yasm on Linux, which would save some headaches for
>>> Sage.
>> I don't really think that yasm is a problem for Sage. It's
On Tuesday, 22 May 2012, Bill Hart wrote:
>
>
> On Tuesday, 22 May 2012, Jeroen Demeyer wrote:
>> On 2012-05-22 15:37, Bill Hart wrote:
>>> We could then
>>> ditch building Yasm on Linux, which would save some headaches for
>>> Sage.
>> I don't really think that yasm is a problem for Sage. It's
On Tuesday, 22 May 2012, Jeroen Demeyer wrote:
> On 2012-05-22 15:37, Bill Hart wrote:
>> We could then
>> ditch building Yasm on Linux, which would save some headaches for
>> Sage.
> I don't really think that yasm is a problem for Sage. It's true that
> sometimes a Sage build might build because
On Tuesday, 22 May 2012, Jeroen Demeyer wrote:
> On 2012-05-22 15:37, Bill Hart wrote:
>> We could then
>> ditch building Yasm on Linux, which would save some headaches for
>> Sage.
> I don't really think that yasm is a problem for Sage. It's true that
> sometimes a Sage build might build because
On 2012-05-22 15:37, Bill Hart wrote:
> We could then
> ditch building Yasm on Linux, which would save some headaches for
> Sage.
I don't really think that yasm is a problem for Sage. It's true that
sometimes a Sage build might build because of a problem with yasm, but
it's more because MPIR/YASM
On Tuesday, 22 May 2012, Bill Hart wrote:
>
>
> On Tuesday, 22 May 2012, Brian Gladman wrote:
>> On Tue, 22 May 2012 16:53:07 +0100
>> Bill Hart wrote:
>>
>>> On 22 May 2012 16:37, Brian Gladman wrote:
>>> > On Tue, 22 May 2012 15:19:52 +0100
>>> > Bill Hart wrote:
>>> >
>>> >> Well spotted. I
On Tuesday, 22 May 2012, Brian Gladman wrote:
> On Tue, 22 May 2012 16:53:07 +0100
> Bill Hart wrote:
>
>> On 22 May 2012 16:37, Brian Gladman wrote:
>> > On Tue, 22 May 2012 15:19:52 +0100
>> > Bill Hart wrote:
>> >
>> >> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not
>> >>
On Tue, 22 May 2012 16:53:07 +0100
Bill Hart wrote:
> On 22 May 2012 16:37, Brian Gladman wrote:
> > On Tue, 22 May 2012 15:19:52 +0100
> > Bill Hart wrote:
> >
> >> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not
> >> the linux assembly code. So indeed, for MinGW support, we
On 22 May 2012 16:37, Brian Gladman wrote:
> On Tue, 22 May 2012 15:19:52 +0100
> Bill Hart wrote:
>
>> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
>> linux assembly code. So indeed, for MinGW support, we probably have
>> little choice but to use a portable assembler. So
On Tue, 22 May 2012 15:19:52 +0100
Bill Hart wrote:
> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
> linux assembly code. So indeed, for MinGW support, we probably have
> little choice but to use a portable assembler. So it looks like we are
> stuck with Yasm, unless we w
On Tue, 22 May 2012 15:20:53 +0100
Bill Hart wrote:
> We could still use GCC only on linux. But we'd have to be careful that
> yasm still got built on MinGW.
That would depend on which assembler code mingw64 uses - if it uses my
assembler code and I move to MASM, it might get left 'high and dry'
We could still use GCC only on linux. But we'd have to be careful that
yasm still got built on MinGW.
Bill.
On 22 May 2012 15:19, Bill Hart wrote:
> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
> linux assembly code. So indeed, for MinGW support, we probably have
> littl
Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
linux assembly code. So indeed, for MinGW support, we probably have
little choice but to use a portable assembler. So it looks like we are
stuck with Yasm, unless we wanted to duplicate all the Windows
assembly code (something I
On Tue, 22 May 2012 14:37:26 +0100
Bill Hart wrote:
> I agree with that explanation. However, I should add that it is
> largely for historical reasons.
>
> MPIR originally planned to support MSVC out-of-the-box (as did Sage
> once). One reason for this is that many Windows developers use MSVC.
>
I agree with that explanation. However, I should add that it is
largely for historical reasons.
MPIR originally planned to support MSVC out-of-the-box (as did Sage
once). One reason for this is that many Windows developers use MSVC.
Brian Gladman has been successfully providing that ability (actua
On 22 May 2012 10:10, Jeroen Demeyer wrote:
> Within the Sage project, we discovered several issues with the
> CPU/CFLAGS/MPN_PATH configuration code in MPIR-2.4.0. The code mostly
> works well, but there are a few things I would like to change.
>
> I would also like to add a configuration option
On Tue, 22 May 2012 11:14:51 +0200
Jeroen Demeyer wrote:
> What is the reason that MPIR uses yasm to build *some* of its assembly
> files? It seems that most assembly files are built using gcc, i.e.
> the system assembler. Why use two different assemblers?
Originally it was hoped that using YA
What is the reason that MPIR uses yasm to build *some* of its assembly
files? It seems that most assembly files are built using gcc, i.e. the
system assembler. Why use two different assemblers?
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To
Within the Sage project, we discovered several issues with the
CPU/CFLAGS/MPN_PATH configuration code in MPIR-2.4.0. The code mostly
works well, but there are a few things I would like to change.
I would also like to add a configuration option to build a "generic"
binary meaning one which would r
21 matches
Mail list logo
