On Wed, Nov 27, 2002 at 03:55:54PM -, Simon Marlow wrote:
> Those who experience long link times (longer than a few seconds), please
> reply with your
>
> - platform / OS version
> - versions of relevent things (GHC, GCC, binutils).
> - time to link 'main = print "hello"'.
Platform: De
Thanks Simon.
> If you look in the manual you'll see that it says you can only
> compile-time-call a function that is in a separate module. So put
> 'pr/gen/parse' in a separate module and you'll be fine.
My fault really as I only have the raw SGML and it sends me up the wall to
try and read it.
I too am getting link times in the several minutes range for my modestly
sized project, I am on a standalone dual-cpu redhat linux box with
5.04.1 (no nfs, no nuttin')
the project is available at
http://repetae.net/john/computer/ginsu/
I think there is definatly something fishy going on. I don't
On Wed, 27 Nov 2002 15:20:44 -
"Simon Marlow" <[EMAIL PROTECTED]> wrote:
> > The runtime loader stuff I'm working on[1] takes around 10
> > seconds to compile ... and 3 minutes to link it with libHSbase
> > and libHSrts. (This is on a 500MHz PIII). Linking is a huge
> > bottleneck once you s
Simon Marlow wrote:
I don't see the problem with forking a new Haskell thread for each
foreign export, and associating it with the current native thread if
the
foreign export is marked "bound". It does mean we can get multiple
Haskell threads bound to the same native thread, but only one can be
> > > More fun with Haskell-in-the-large: linking time has become the
> > > main bottleneck in our development cycle. The standard solution
> > > would be to use an incremental linker, but it seems that gnu does
> > > not yet support this:-|
> >
> > Hmm, I've never heard of linking being a bottle
> > More fun with Haskell-in-the-large: linking time has become the
> > main bottleneck in our development cycle. The standard solution
> > would be to use an incremental linker, but it seems that gnu does
> > not yet support this:-|
>
> Hmm, I've never heard of linking being a bottleneck. Even G
> On Wed, Nov 27, 2002 at 09:50:56AM -, Simon Marlow wrote:
>
> > > More fun with Haskell-in-the-large: linking time has become the
> > > main bottleneck in our development cycle. The standard solution
> > > would be to use an incremental linker, but it seems that gnu does
> > > not yet suppor
On Wed, Nov 27, 2002 at 09:50:56AM -, Simon Marlow wrote:
> > More fun with Haskell-in-the-large: linking time has become the
> > main bottleneck in our development cycle. The standard solution
> > would be to use an incremental linker, but it seems that gnu does
> > not yet support this:-|
>
> Unfortunately, we're not talking seconds, but coffee-breaks of
> linking times on our Sun (yes, the stuff is in the range of a large
> compiler - we're fortunate enough to be able to build on rather
> substantial third-party packages, think haskell-in-haskell frontend
> distributed over unusually
> Hmm, I've never heard of linking being a bottleneck. Even GHC itself
> links in about 3-4 seconds here. One common problem is that linking on
> a network filesystem takes a *lot* longer than linking objects from a
> local disk. It's always a good idea to keep the build tree on the local
> dis
> Are you sure you intend to change the type of forkIO? Currently it's
> forkIO :: IO () -> IO ThreadId
Sorry, no, I did not.
--
Alastair
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskel
> More fun with Haskell-in-the-large: linking time has become the
> main bottleneck in our development cycle. The standard solution
> would be to use an incremental linker, but it seems that gnu does
> not yet support this:-|
Hmm, I've never heard of linking being a bottleneck. Even GHC itself
l
> When a "bound" foreign exported function is invoked [by
> foreign code],
> the implementation checks whether a Haskell thread is associated with
> the current OS thread.
> If there is one, this Haskell thread is used to execute the callback.
> If there is none, a new Haskell thread is created
| Nice design, Alastair. I've stolen lots of ideas and some text for the
| complete rewrite of the proposal.
I think it is a great idea to rewrite the proposal. A tiny minority
will follow the details of the discussion, and it's essential to record
the outcome in a way comprehensible by someone w
More fun with Haskell-in-the-large: linking time has become the
main bottleneck in our development cycle. The standard solution
would be to use an incremental linker, but it seems that gnu does
not yet support this:-|
Alternative a: use someone else's incremental linker, e.g., Sun's
ild (ghc's -pg
If you look in the manual you'll see that it says you can only
compile-time-call a function that is in a separate module. So put
'pr/gen/parse' in a separate module and you'll be fine.
The manual may not be very clear... pls help me improve it.
S
| -Original Message-
| From: Mike Thomas
Typo:
> Being fresh to Haskell, I suggest that the naming continues to be
> "native" and "free".
I did mean "native" and "green"
Have a nice day, once again.
Johan Steunenberg
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell
18 matches
Mail list logo
