Hello skaller,
Thursday, June 21, 2007, 7:06:09 AM, you wrote:
>> generally speaking, people want to use 64-bit code in order to work
>> with much larger data space, overall speed may be better than using
>> 32-bit version with 2gb limit
> With x86_64, 64 bit programs are usually faster than 32 b
On Wed, 2007-06-20 at 22:59 +0400, Bulat Ziganshin wrote:
> generally speaking, people want to use 64-bit code in order to work
> with much larger data space, overall speed may be better than using
> 32-bit version with 2gb limit
With x86_64, 64 bit programs are usually faster than 32 bit ones
ev
On Wed, 2007-06-20 at 11:40 -0400, Isaac Dupree wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> skaller wrote:
> > (MS and gcc C++ are incompatible).
>
> is this still true? GCC has been standardizing its C++ ABI for a while,
> and I think there actually weren't any ABI changes noted
On Wed, 2007-06-20 at 11:39 -0400, Peter Tanski wrote:
> The largest problem is the build system: GHC uses autoconf with
> custom makefiles.
Well, that needs to be fixed. Autoconf and make are rubbish.
> I have looked into porting the whole thing to a
> Visual Studio project, using SCons (
Hello Simon,
Wednesday, June 20, 2007, 11:51:34 AM, you wrote:
>> really! Simon, how about unregisterised build?
> Unregisterised would still need a C compiler capable of generating 64-bit
> code.
> Are you talking about using the MS compiler for that? Certainly possible,
> but
> I'm not sur
Simon Marlow wrote:
GHC *developers* wouldn't be any better off either. You'd still
need either
Cygwin or MSYS for the build environment. There's no way I'm using
MS build
tools, ugh.
The way I have it set up (so far) is as simple as running configure
and make--all from the command line
| > BTW: I don't really like Windows .. but I want to see Haskell
| > succeed. Trying to do Haskell on Windows without MSVC++ toolchain
| > is like trying to work on Linux without binutils... :)
|
| This is a fine point, and probably the biggest reason for doing a
| Windows native
| port. I'd like
skaller wrote:
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-
bit port of
mingw.
Why do you need mingw?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
skaller wrote:
> (MS and gcc C++ are incompatible).
is this still true? GCC has been standardizing its C++ ABI for a while,
and I think there actually weren't any ABI changes noted between 4.1 and
4.2 for most platforms (I don't know if MS C++ is comp
I would be more than happy to help. Maybe we need to get a sub-team
together and start plowing through this mine-field?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon
Marlow
Sent: Wednesday, June 20, 2007 10:29 AM
To: skaller
Cc: glasgow-haskell-us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Mitchell wrote:
> Typically MS tools are
> well packaged and even if there is a click through license, it usually
> involves checking a box and clicking next. I can't believe that anyone
> is going to have any difficulty installing Visual Studio e
skaller wrote:
GHC needs to target *professional windows programmers*.
They're going to have VS installed already. Haskell is far
too important a language (IMHO) not to have an entry in
the commercial programming arena.
Commercial programming is in a bad way! It NEEDS stuff like
Haskell availab
Neil Mitchell wrote:
Hi
> I'm not sure I understand this. MS tools are free to download
> by anyone, but not redistributable. The binaries needed by
> programs *built* by those tools are not only free to download,
> they're free to redistribute, and they're less encumbered than
> almost all so-
On Wed, 2007-06-20 at 14:42 +0100, Simon Marlow wrote:
> "The binaries needed by programs built by these tools...", you're referring
> to
> the C runtime DLLs? Why does that matter?
>
> Note I said "with no dependencies" above. A Windows native port of GHC would
> require you to go to MS and
Hi
> I'm not sure I understand this. MS tools are free to download
> by anyone, but not redistributable. The binaries needed by
> programs *built* by those tools are not only free to download,
> they're free to redistribute, and they're less encumbered than
> almost all so-called 'free software'
skaller wrote:
On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote:
I don't think we'll be able to drop the mingw route either, mainly because while
the MS tools are free to download, they're not properly "free", and we want to
retain the ability to have a completely free distribution with n
On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote:
> I don't think we'll be able to drop the mingw route either, mainly because
> while
> the MS tools are free to download, they're not properly "free", and we want
> to
> retain the ability to have a completely free distribution with no
>
Marc Weber <[EMAIL PROTECTED]> wrote:
> print $ M.(.!.) [1,2] 1 -- (2)
The parens must enclose the whole varop:
print $ (M..!.) [1,2] 1 -- (2)
Regards,
Malcolm
___
Glasgow-haskell-users
Example:
[EMAIL PROTECTED] /tmp/qual $ ls; cat M.hs main.hs; ghc --make main.hs
M.hi M.hs M.o main.hs
-- module M --
module M where
import Data.List
infixr 9 .!.
f = "dummyf"
(.!.) = (!!)
-- module Main --
module Main where
import quali
Bulat Ziganshin wrote:
Hello skaller,
Tuesday, June 19, 2007, 8:15:19 PM, you wrote:
are you plan to implement 64-bit windows GHC version?
Why do you need mingw? What's wrong with MSVC++?
really! Simon, how about unregisterised build?
Unregisterised would still need a C compiler capable
skaller wrote:
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-bit port of
mingw.
Why do you need mingw? What's w
21 matches
Mail list logo
