Willem Robert van Hage <[EMAIL PROTECTED]> wrote,
> I'm trying out GHC along with gtk+hs and iHaskell
> and I was surprised that a simple example with a list of selectable
> distribution names generated a binary of 2Mb.
> So I tried a simple hello world example exactly like the one
> I saw somewh
| Surely the executable itself is only linked with the
| functions that are actually used by the program?
AFAIUI the GNU linker is not clever enough to remove junk
on a per-function basis, only on a per-object basis. This is
why we do object-splitting -- by breaking libraries up into
thousa
> > Is there any chance of a MacOSX binary release?
>
> We're not planning to make one ourselves, but hopefully one of our
> friends with MacOS X expertise will help out: Atze, Sebastien - any
> plans?
I have started building one, it should be ready in a few days.
--
Sebastien
_
> Is there any chance of a MacOSX binary release?
We're not planning to make one ourselves, but hopefully one of our
friends with MacOS X expertise will help out: Atze, Sebastien - any
plans?
Cheers,
Simon
___
Glasgow-haskell-users mailing lis
There's a proper package of 5.02 for FreeBSD/x86 4.4-STABLE here:
http://www.haskell.org/ghc/dist/5.02/ghc-5.02.tgz
Please let me know whether it does/doesn't work for you.
I've submitted the port to the FreeBSD folks, but it may be a while
before they integrate it.
Cheers,
Sim
> "Julian Seward (Intl Vendor)" <[EMAIL PROTECTED]> writes:
>
> > On Linux and probably most Unixes, the text and data segments
> > of the executable are loaded page-by-page into memory on
> > demand. So having a lot of unused junk in the executable doesn't
> > necessarily increase the memory us
"Julian Seward (Intl Vendor)" <[EMAIL PROTECTED]> writes:
> On Linux and probably most Unixes, the text and data segments
> of the executable are loaded page-by-page into memory on
> demand. So having a lot of unused junk in the executable doesn't
> necessarily increase the memory used, either r
| OTOH when you start using and reusing larger libraries, like
| Gtk+, the waste accumulates, and it's possibly you don't need
| to run too many GTK+HS programs before you see performance decrease
| due to memory exhaustion.
On Linux and probably most Unixes, the text and data segments
of th
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> We don't have support for shared libraries under Unix at the moment. It
> has been investigated at various times in the past, and I believe the
> story is that we couldn't do it without at least losing some performance
Of course, dynamic linking only
> > > -rwxr-xr-x1 willem users 201453 Sep 29 09:55 hello
> > > -rw-r--r--1 willem users 51 Sep 29 09:54 hello.hs
> > > -rw-r--r--1 willem users1468 Sep 29 09:55 hello.o
> >
> > Probably, the executable hello is 1000 times larger than object
> > one becaus
Simon Peyton-Jones <[EMAIL PROTECTED]>
writes on my recent bug reports
> Simon is going to look into the storage management bug.
> I believe that it does not show up if you do not use the
> (new) compacting garbage collector, correct?
>
> We'll produce 5.02.1 when we know what the cause is;
> m
Simon is going to look into the storage management bug.
I believe that it does not show up if you do not use the
(new) compacting garbage collector, correct?
We'll produce 5.02.1 when we know what the cause is;
meanwhile, can you just switch off compacting GC?
(Admittedly, that would be easier
12 matches
Mail list logo
