How to optimize the memory usage of "linking"?

[Magicloud Magiclouds]

Hi,
  When I use ghc to make large project, the almost-final step of
linking takes a lot of memory. This is horrible on host with little
memory (i.e. 512MB).
  Is there any way I can optimize this? Thanks.
-- 
竹密岂妨流水过
山高哪阻野云飞
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: List vs Data.List

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/18/10 13:06 , Serge D. Mechveliani wrote:
> In  ghc-7.0.1,  to import `partition', it is sufficient the line
> 
>import List (partition), 
> 
> but to import `intercalate', it is needed
>import Data.List (intercalate).
> 
> Does  Haskell-2010  differ between  List  and  Data.List  import?

Haskell-2010 specifies Data.List.  List is only for Haskell98.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzliWgACgkQIn7hlCsL25XloQCggEV8ndpBEJp435VQj9ZqMqMp
hicAnjrX7gQs7KYyW97c9HpkJcz3kKHJ
=4yB5
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: libffi was:Re: ANNOUNCE: GHC version 7.0.1

[Tyson Whitehead]

On November 18, 2010 05:12:11 Simon Marlow wrote:
> On 17/11/2010 14:34, Christian Maeder wrote:
> > ghc can be built without and with libffi.
> 
> Which build option are you referring to here?  libffi is required for
> FFI support in GHCi, and for FFI "wrapper" imports.  However on x86 and
> x86_64 we don't normally use libffi for wrappers, because we have a
> native implementation that is a bit faster (this is the
> UseLibFFIForAdjustors build option).

I was hoping someone might comment further on the selinux issues,

I woudl gather from this though that the native implementation must now avoid 
the "selinux doesn't like pages that are both executable and writable" issue?

http://hackage.haskell.org/trac/ghc/ticket/738

(it seems like the solution that closed 738 was to use libffi)

Cheers!  -Tyson


signature.asc
Description: This is a digitally signed message part.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

List vs Data.List

[Serge D. Mechveliani]

In  ghc-7.0.1,  to import `partition', it is sufficient the line

   import List (partition), 

but to import `intercalate', it is needed
   import Data.List (intercalate).

Does  Haskell-2010  differ between  List  and  Data.List  import?

Thank you in advance for explanation,

-
Serge Mechveliani
mech...@botik.ru

 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Using the GHC API: pretty printing with qualified names

[JP Moresmau]

Simon, thanks for the tips! I have changed the code to use nameModule_maybe
and I've verified that using that on a function imported through a qualified
import works.
Claus, Scott, the redirection from one standard package to a GHC package
wasn't my issue. We're in an IDE that uses GHC, so redirecting to the GHC
page instead of the Prelude page is not really an issue, it may just startle
some users. GHCi does the same:
Prelude> :info map
map :: (a -> b) -> [a] -> [b]   -- Defined in GHC.Base
Prelude> :info Prelude.map
map :: (a -> b) -> [a] -> [b]   -- Defined in GHC.Base

But I still would like to find a workaround to be able to jump to the
definition even after the type checking rewrite Simon explains, in GHC
6.10/12. I'll keep poking on how to get from that lambda function to the
real function it calls.

Thanks to all,

JP

On Thu, Nov 18, 2010 at 2:36 PM,  wrote:

> Claus:
>
> Respectfully, "No duh!" as schoolkids here in the US like to say when
> someone points out the obvious to them.
>
> And "impossible" is the right word since the predicate evaluates to a
> boolean. Since false is the outcome, "impossible" refers correctly to the
> status of fetching the documentation.
>
> Yes, we've been looking at the GHC sources. Why else would the question be
> posed with regard to "is there a better way of doing this?" Personally, I've
> had my fun re-implementing cabal package reading, and recreating someone
> else's work is counterproductive.
>
>
> -scooter
> Sent from my Verizon Wireless BlackBerry
>
> -Original Message-
> From: "Claus Reinke" 
> Date: Thu, 18 Nov 2010 10:53:05
> To: ; 
> Subject: Re: Using the GHC API: pretty printing with qualified names
>
> > scion-server mimics a GHCi command line, of sorts. scion-server
> > is used very successfully to syntax-highlight the Eclipse editor,
> > show a source's outline, provide type information when hovering
> > over a name, and provide completions.
>
> > That's not the problem, per se. Let's say I'm hovering over a
> > function that's imported by Data.Map. When resolved, the
> > symbols appear to come from Ghc.Map (if memory serves
> > correctly), which makes finding the correct "haddock" impossible.
>
> "Impossible" is such an ugly word;-)
>
> The problem you encounter is that the GHC API is still, to a
> large part, just an open window into what happens to be
> in GHC. Since GHC's aims as a compiler differ from those
> of IDEs, its exposed functionality will sometimes be too
> limited to serve your purposes (eg, if GHC knows where
> a function is defined, it doesn't need to know how it was
> imported, once it gets past error reporting).
>
> If you tie yourself too closely to GHC's view, some things
> you'd like to do in an IDE will _appear_ to be impossible.
> That is why I recommend looking into the GHCi sources,
> because GHCi's needs are closer to those of an IDE.
>
> I assume you mean things like Data.List.map being a
> re-exported GHC.List.map being a re-exported GHC.Base.map,
> and :info not knowing about  the intended abstractions:
>
>Prelude> :i map
>map :: (a -> b) -> [a] -> [b]   -- Defined in GHC.Base
>
> You can actually get information about possible import
> paths via :browse!
>
>Prelude> :m +Data.List
>Prelude Data.List> :grep map|imported :browse!
>
>-- imported via Data.List
>mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
>mapAccumR :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
>-- imported via Data.List, Prelude
>map :: (a -> b) -> [a] -> [b]
>
> (:browse! is standard GHCi, :grep is non-standard, just to filter
> :browse! output). So the :browse! command seems to be able
> to find more of the information you want.
>
> haskellmode for Vim, on the other hand, has long provided
> haddock lookup, and will offer you a menu of possible
> destinations when your cursor is over 'map'. This menu is
> built from an index of Haddock entries, which is extracted
> from installed Haddock documentation.
>
> Nothing impossible about that, just ugly: so far, the index
> is scraped from Haddock's HTML index files. That route
> breaks occasionally (recent Haddock HTML changes,
> ghc-pkg listing wrong Haddock paths, ..; I'm about to
> publish updated scraping code for GHC-7.0.1's Haddock..).
>
> To get something less ugly, I'm currently recoding the
> extraction by using Haddock's API and .haddock files
> (that'll still break when the API changes, also there is
> a pending bug about ghc-pkg, cabal, and haddock
> disagreeing about filepath formats, meaning that
> .haddock files aren't found on Windows).
>
> I assume that code will be useful to other Haskell IDEs,
> though it is mostly exposing Haddock's internal ability to
> build an index from .haddock files, which I'd like to see
> exposed in Haddock's less-than-well-known API:
>
>http://trac.haskell.org/haddock/ticket/157
>
> Claus
>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgo

Re: Using the GHC API: pretty printing with qualified names

[scooter . phd]

Claus:

Respectfully, "No duh!" as schoolkids here in the US like to say when someone 
points out the obvious to them.

And "impossible" is the right word since the predicate evaluates to a boolean. 
Since false is the outcome, "impossible" refers correctly to the status of 
fetching the documentation.

Yes, we've been looking at the GHC sources. Why else would the question be 
posed with regard to "is there a better way of doing this?" Personally, I've 
had my fun re-implementing cabal package reading, and recreating someone else's 
work is counterproductive.


-scooter
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: "Claus Reinke" 
Date: Thu, 18 Nov 2010 10:53:05 
To: ; 
Subject: Re: Using the GHC API: pretty printing with qualified names

> scion-server mimics a GHCi command line, of sorts. scion-server 
> is used very successfully to syntax-highlight the Eclipse editor, 
> show a source's outline, provide type information when hovering 
> over a name, and provide completions.

> That's not the problem, per se. Let's say I'm hovering over a 
> function that's imported by Data.Map. When resolved, the 
> symbols appear to come from Ghc.Map (if memory serves 
> correctly), which makes finding the correct "haddock" impossible.

"Impossible" is such an ugly word;-)

The problem you encounter is that the GHC API is still, to a 
large part, just an open window into what happens to be 
in GHC. Since GHC's aims as a compiler differ from those 
of IDEs, its exposed functionality will sometimes be too 
limited to serve your purposes (eg, if GHC knows where
a function is defined, it doesn't need to know how it was
imported, once it gets past error reporting). 

If you tie yourself too closely to GHC's view, some things 
you'd like to do in an IDE will _appear_ to be impossible. 
That is why I recommend looking into the GHCi sources, 
because GHCi's needs are closer to those of an IDE.

I assume you mean things like Data.List.map being a 
re-exported GHC.List.map being a re-exported GHC.Base.map, 
and :info not knowing about  the intended abstractions:

Prelude> :i map
map :: (a -> b) -> [a] -> [b]   -- Defined in GHC.Base

You can actually get information about possible import 
paths via :browse!

Prelude> :m +Data.List
Prelude Data.List> :grep map|imported :browse!

-- imported via Data.List
mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
mapAccumR :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
-- imported via Data.List, Prelude
map :: (a -> b) -> [a] -> [b]

(:browse! is standard GHCi, :grep is non-standard, just to filter
:browse! output). So the :browse! command seems to be able
to find more of the information you want.

haskellmode for Vim, on the other hand, has long provided
haddock lookup, and will offer you a menu of possible 
destinations when your cursor is over 'map'. This menu is 
built from an index of Haddock entries, which is extracted 
from installed Haddock documentation. 

Nothing impossible about that, just ugly: so far, the index 
is scraped from Haddock's HTML index files. That route
breaks occasionally (recent Haddock HTML changes, 
ghc-pkg listing wrong Haddock paths, ..; I'm about to 
publish updated scraping code for GHC-7.0.1's Haddock..).

To get something less ugly, I'm currently recoding the 
extraction by using Haddock's API and .haddock files
(that'll still break when the API changes, also there is 
a pending bug about ghc-pkg, cabal, and haddock 
disagreeing about filepath formats, meaning that
.haddock files aren't found on Windows). 

I assume that code will be useful to other Haskell IDEs,
though it is mostly exposing Haddock's internal ability to
build an index from .haddock files, which I'd like to see
exposed in Haddock's less-than-well-known API:

http://trac.haskell.org/haddock/ticket/157

Claus

 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr

[Simon Marlow]

On 18/11/2010 11:31, Mitar wrote:

Hi!

On Wed, Nov 17, 2010 at 12:00 PM, Simon Marlow  wrote:

That's hard to do, because the runtime system has no knowledge of exception
types, and I'm not sure I like the idea of baking that knowledge into the
RTS.


But currently it does have a knowledge of interruptible and
uninterruptible exceptions? So adding another which would ctrl-c
interrupt?


The RTS knows when a thread is blocked, which is when it becomes 
interruptible.  It doesn't need to know about different kinds of 
exeptions.  In fact, when an exception is thrown it might well be 
unevaluated.



The point of maskUninterruptible is for those
hoefully rare rare cases where (a) it's really inconvenient to deal with
async exceptions and (b) you have some external guarantee that the critical
section won't block.


But is it possible to make an uninterruptible code section which can
timeout?


then it isn't uninterruptible, because the timeout can interrupt it.  If 
you can tolerate a timeout exception, then you can tolerate other kinds 
of async exception too.



Because once you enter maskUninterruptible probably
System.Timeout does not work anymore? I see uses of
maskUninterruptible (or some derivation of it, preferably) if:

- user would still be able to interrupt it
- you could specify some timeout or some other condition after which
the code section would be interrupted, so you could try for example to
deal with some cleanup code (and you do not want interrupts there) but
if this cleanup code hangs you still want some way to kill it then

Currently, with this absolute/all approach maskUninterruptible is
really not useful much because it masks too much. But I would see a
lot more useful something which would still allow me (and only me, as
a programmer) to interrupt it or user (because user should know what
he/she does). And this is why I argue for some way of being able to
specify which interrupts you still allow: like mask everything
except... (user interrupts, my special exception meant for cleanup
code hanging conditions...).


My main question is then, why do you want to use maskUninterruptible 
rather than just mask?  Can you give a concrete example?


Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: libffi was:Re: ANNOUNCE: GHC version 7.0.1

[Christian Maeder]

Am 18.11.2010 13:04, schrieb Simon Marlow:
>> also for the official ghc-7.0.1-i386-unknown-linux.tar.bz2 that is
>> linked against libffi (I hope not, unnecessarily). Does this mean that
>> GHCi is based on a different RTS?
> 
> That does seem strange.  My 32-bit GHC here doesn't link against libffi:

You're right, it doesn't link against libffi, I only assumed this,
because utils/ghc-pwd/ghc-pwd was (really unnecessarily?) linked asked
libffi, so that I wasn't able to install the whole.

Sorry for the confusion. The question remains, why is
utils/ghc-pwd/ghc-pwd linked against libffi in the official binary-dist?

Christian

> 
> $ ldd ghc-stage2
> linux-gate.so.1 =>  (0x4001d000)
> libncurses.so.5 => /lib/libncurses.so.5 (0x40029000)
> librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x40061000)
> libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0x4006b000)
> libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x4006f000)
> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40073000)
> libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x400d4000)
> libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x400fa000)
> libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40114000)
> /lib/ld-linux.so.2 (0x4000)

> ./configure failed with:
>
> checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error
> while loading shared libraries: libffi.so.5: cannot open shared object
> file: No such file or directory
> configure: error: cannot determine current directory
>
> ldd utils/ghc-pwd/ghc-pwd
>   linux-gate.so.1 =>(0xe000)
>   libutil.so.1 =>   /lib/libutil.so.1 (0xb7718000)
>   libdl.so.2 =>   /lib/libdl.so.2 (0xb7713000)
>   libm.so.6 =>   /lib/libm.so.6 (0xb76e9000)
>   libffi.so.5 =>   not found
>   libgmp.so.3 =>   /usr/lib/libgmp.so.3 (0xb7693000)
>   librt.so.1 =>   /lib/librt.so.1 (0xb7689000)
>   libc.so.6 =>   /lib/libc.so.6 (0xb751e000)
>   /lib/ld-linux.so.2 (0xb7745000)
>   libpthread.so.0 =>   /lib/libpthread.so.0 (0xb7503000)
>
> The 64Bit version works, though.
>
> Christian
>
>
> Am 16.11.2010 01:09, schrieb Ian Lynagh:
>> How to get it
>> ~
>>
>> The easy way is to go to the web page, which should be
>> self-explanatory:
>>
>>   http://www.haskell.org/ghc/
>>
>>
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: libffi was:Re: ANNOUNCE: GHC version 7.0.1

[Christian Maeder]

Am 18.11.2010 13:04, schrieb Simon Marlow:
>> "ghc-pkg describe rts" only lists:
>>   extra-libraries: m rt dl
> 
> $ ghc-pkg field rts depends
> depends: builtin_ffi
> 
> $ ghc-pkg describe ffi
> name: ffi
> version: 1.0
> id: builtin_ffi
> ...

this entry does not say that it wants to link against libffi (and in
fact it does not). Everything is part of libHSffi

C.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: libffi was:Re: ANNOUNCE: GHC version 7.0.1

[Simon Marlow]

On 18/11/2010 11:24, Christian Maeder wrote:

Am 18.11.2010 11:12, schrieb Simon Marlow:

On 17/11/2010 14:34, Christian Maeder wrote:

ghc can be built without and with libffi.


Which build option are you referring to here?


I did not use any explicit build option, but just created a
binary-distribution from sources without having /usr/lib/libffi.


We ship GHC with a copy of libffi, you don't need it installed on your 
system.  Indeed, GHC shouldn't ever use the installed one.



libffi is required for
FFI support in GHCi, and for FFI "wrapper" imports.  However on x86 and
x86_64 we don't normally use libffi for wrappers, because we have a
native implementation that is a bit faster (this is the
UseLibFFIForAdjustors build option).


What advantage do I gain in
the latter case? The packages that come with ghc (displayed by "ghc-pkg
dump") don't use it.


The RTS should depend on it.


"ghc-pkg describe rts" only lists:
  extra-libraries: m rt dl


$ ghc-pkg field rts depends
depends: builtin_ffi

$ ghc-pkg describe ffi
name: ffi
version: 1.0
id: builtin_ffi
...


also for the official ghc-7.0.1-i386-unknown-linux.tar.bz2 that is
linked against libffi (I hope not, unnecessarily). Does this mean that
GHCi is based on a different RTS?


That does seem strange.  My 32-bit GHC here doesn't link against libffi:

$ ldd ghc-stage2
linux-gate.so.1 =>  (0x4001d000)
libncurses.so.5 => /lib/libncurses.so.5 (0x40029000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x40061000)
libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0x4006b000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x4006f000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40073000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x400d4000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x400fa000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40114000)
/lib/ld-linux.so.2 (0x4000)

Cheers,
Simon




C.



Cheers,
 Simon



Thanks Christian


Am 16.11.2010 13:03, schrieb Christian Maeder:

http://new-www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.bz2


./configure failed with:

checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error
while loading shared libraries: libffi.so.5: cannot open shared object
file: No such file or directory
configure: error: cannot determine current directory

ldd utils/ghc-pwd/ghc-pwd
  linux-gate.so.1 =>(0xe000)
  libutil.so.1 =>   /lib/libutil.so.1 (0xb7718000)
  libdl.so.2 =>   /lib/libdl.so.2 (0xb7713000)
  libm.so.6 =>   /lib/libm.so.6 (0xb76e9000)
  libffi.so.5 =>   not found
  libgmp.so.3 =>   /usr/lib/libgmp.so.3 (0xb7693000)
  librt.so.1 =>   /lib/librt.so.1 (0xb7689000)
  libc.so.6 =>   /lib/libc.so.6 (0xb751e000)
  /lib/ld-linux.so.2 (0xb7745000)
  libpthread.so.0 =>   /lib/libpthread.so.0 (0xb7503000)

The 64Bit version works, though.

Christian


Am 16.11.2010 01:09, schrieb Ian Lynagh:

How to get it
~

The easy way is to go to the web page, which should be
self-explanatory:

  http://www.haskell.org/ghc/



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr

[Mitar]

Hi!

On Wed, Nov 17, 2010 at 12:00 PM, Simon Marlow  wrote:
> That's hard to do, because the runtime system has no knowledge of exception
> types, and I'm not sure I like the idea of baking that knowledge into the
> RTS.

But currently it does have a knowledge of interruptible and
uninterruptible exceptions? So adding another which would ctrl-c
interrupt?

> The point of maskUninterruptible is for those
> hoefully rare rare cases where (a) it's really inconvenient to deal with
> async exceptions and (b) you have some external guarantee that the critical
> section won't block.

But is it possible to make an uninterruptible code section which can
timeout? Because once you enter maskUninterruptible probably
System.Timeout does not work anymore? I see uses of
maskUninterruptible (or some derivation of it, preferably) if:

- user would still be able to interrupt it
- you could specify some timeout or some other condition after which
the code section would be interrupted, so you could try for example to
deal with some cleanup code (and you do not want interrupts there) but
if this cleanup code hangs you still want some way to kill it then

Currently, with this absolute/all approach maskUninterruptible is
really not useful much because it masks too much. But I would see a
lot more useful something which would still allow me (and only me, as
a programmer) to interrupt it or user (because user should know what
he/she does). And this is why I argue for some way of being able to
specify which interrupts you still allow: like mask everything
except... (user interrupts, my special exception meant for cleanup
code hanging conditions...).


Mitar
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: libffi was:Re: ANNOUNCE: GHC version 7.0.1

[Christian Maeder]

Am 18.11.2010 11:12, schrieb Simon Marlow:
> On 17/11/2010 14:34, Christian Maeder wrote:
>> ghc can be built without and with libffi.
> 
> Which build option are you referring to here? 

I did not use any explicit build option, but just created a
binary-distribution from sources without having /usr/lib/libffi.

> libffi is required for
> FFI support in GHCi, and for FFI "wrapper" imports.  However on x86 and
> x86_64 we don't normally use libffi for wrappers, because we have a
> native implementation that is a bit faster (this is the
> UseLibFFIForAdjustors build option).
> 
>> What advantage do I gain in
>> the latter case? The packages that come with ghc (displayed by "ghc-pkg
>> dump") don't use it.
> 
> The RTS should depend on it.

"ghc-pkg describe rts" only lists:
 extra-libraries: m rt dl

also for the official ghc-7.0.1-i386-unknown-linux.tar.bz2 that is
linked against libffi (I hope not, unnecessarily). Does this mean that
GHCi is based on a different RTS?

C.

> 
> Cheers,
> Simon
> 
> 
>> Thanks Christian
>>
>>
>> Am 16.11.2010 13:03, schrieb Christian Maeder:
>>> http://new-www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.bz2
>>>
>>>
>>> ./configure failed with:
>>>
>>> checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error
>>> while loading shared libraries: libffi.so.5: cannot open shared object
>>> file: No such file or directory
>>> configure: error: cannot determine current directory
>>>
>>> ldd utils/ghc-pwd/ghc-pwd
>>>  linux-gate.so.1 =>   (0xe000)
>>>  libutil.so.1 =>  /lib/libutil.so.1 (0xb7718000)
>>>  libdl.so.2 =>  /lib/libdl.so.2 (0xb7713000)
>>>  libm.so.6 =>  /lib/libm.so.6 (0xb76e9000)
>>>  libffi.so.5 =>  not found
>>>  libgmp.so.3 =>  /usr/lib/libgmp.so.3 (0xb7693000)
>>>  librt.so.1 =>  /lib/librt.so.1 (0xb7689000)
>>>  libc.so.6 =>  /lib/libc.so.6 (0xb751e000)
>>>  /lib/ld-linux.so.2 (0xb7745000)
>>>  libpthread.so.0 =>  /lib/libpthread.so.0 (0xb7503000)
>>>
>>> The 64Bit version works, though.
>>>
>>> Christian
>>>
>>>
>>> Am 16.11.2010 01:09, schrieb Ian Lynagh:
 How to get it
 ~

 The easy way is to go to the web page, which should be
 self-explanatory:

  http://www.haskell.org/ghc/


>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Non-exhaustive pattern match(es) warning in lambda functions

[Mitar]

Hi!

On Wed, Nov 17, 2010 at 11:52 AM, Sittampalam, Ganesh
 wrote:
> If GHC added support "or" patterns, you could write them out quite
> concisely:
>
> bar Foo1 Foo2 Foo3 = ...
> bar (Foo1|Foo2|Foo3) (Foo1|Foo2|Foo3) (Foo1|Foo2|Foo3) = error "..."

Uh. Still no nice solution.

But this is a form of closed world assumption. When you write _ as a
case you in fact use this assumption. But when you later on extend the
"world" with some new case, this assumption could not really hold
anymore.


Mitar
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: libffi was:Re: ANNOUNCE: GHC version 7.0.1

[Simon Marlow]

On 17/11/2010 14:34, Christian Maeder wrote:

ghc can be built without and with libffi.


Which build option are you referring to here?  libffi is required for 
FFI support in GHCi, and for FFI "wrapper" imports.  However on x86 and 
x86_64 we don't normally use libffi for wrappers, because we have a 
native implementation that is a bit faster (this is the 
UseLibFFIForAdjustors build option).



What advantage do I gain in
the latter case? The packages that come with ghc (displayed by "ghc-pkg
dump") don't use it.


The RTS should depend on it.

Cheers,
Simon



Thanks Christian


Am 16.11.2010 13:03, schrieb Christian Maeder:

http://new-www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.bz2

./configure failed with:

checking for path to top of build tree... utils/ghc-pwd/ghc-pwd: error
while loading shared libraries: libffi.so.5: cannot open shared object
file: No such file or directory
configure: error: cannot determine current directory

ldd utils/ghc-pwd/ghc-pwd
 linux-gate.so.1 =>   (0xe000)
 libutil.so.1 =>  /lib/libutil.so.1 (0xb7718000)
 libdl.so.2 =>  /lib/libdl.so.2 (0xb7713000)
 libm.so.6 =>  /lib/libm.so.6 (0xb76e9000)
 libffi.so.5 =>  not found
 libgmp.so.3 =>  /usr/lib/libgmp.so.3 (0xb7693000)
 librt.so.1 =>  /lib/librt.so.1 (0xb7689000)
 libc.so.6 =>  /lib/libc.so.6 (0xb751e000)
 /lib/ld-linux.so.2 (0xb7745000)
 libpthread.so.0 =>  /lib/libpthread.so.0 (0xb7503000)

The 64Bit version works, though.

Christian


Am 16.11.2010 01:09, schrieb Ian Lynagh:

How to get it
~

The easy way is to go to the web page, which should be self-explanatory:

 http://www.haskell.org/ghc/



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Using the GHC API: pretty printing with qualified names

[Claus Reinke]

scion-server mimics a GHCi command line, of sorts. scion-server 
is used very successfully to syntax-highlight the Eclipse editor, 
show a source's outline, provide type information when hovering 
over a name, and provide completions.


That's not the problem, per se. Let's say I'm hovering over a 
function that's imported by Data.Map. When resolved, the 
symbols appear to come from Ghc.Map (if memory serves 
correctly), which makes finding the correct "haddock" impossible.


"Impossible" is such an ugly word;-)

The problem you encounter is that the GHC API is still, to a 
large part, just an open window into what happens to be 
in GHC. Since GHC's aims as a compiler differ from those 
of IDEs, its exposed functionality will sometimes be too 
limited to serve your purposes (eg, if GHC knows where

a function is defined, it doesn't need to know how it was
imported, once it gets past error reporting). 

If you tie yourself too closely to GHC's view, some things 
you'd like to do in an IDE will _appear_ to be impossible. 
That is why I recommend looking into the GHCi sources, 
because GHCi's needs are closer to those of an IDE.


I assume you mean things like Data.List.map being a 
re-exported GHC.List.map being a re-exported GHC.Base.map, 
and :info not knowing about  the intended abstractions:


   Prelude> :i map
   map :: (a -> b) -> [a] -> [b]   -- Defined in GHC.Base

You can actually get information about possible import 
paths via :browse!


   Prelude> :m +Data.List
   Prelude Data.List> :grep map|imported :browse!

   -- imported via Data.List
   mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
   mapAccumR :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y])
   -- imported via Data.List, Prelude
   map :: (a -> b) -> [a] -> [b]

(:browse! is standard GHCi, :grep is non-standard, just to filter
:browse! output). So the :browse! command seems to be able
to find more of the information you want.

haskellmode for Vim, on the other hand, has long provided
haddock lookup, and will offer you a menu of possible 
destinations when your cursor is over 'map'. This menu is 
built from an index of Haddock entries, which is extracted 
from installed Haddock documentation. 

Nothing impossible about that, just ugly: so far, the index 
is scraped from Haddock's HTML index files. That route
breaks occasionally (recent Haddock HTML changes, 
ghc-pkg listing wrong Haddock paths, ..; I'm about to 
publish updated scraping code for GHC-7.0.1's Haddock..).


To get something less ugly, I'm currently recoding the 
extraction by using Haddock's API and .haddock files
(that'll still break when the API changes, also there is 
a pending bug about ghc-pkg, cabal, and haddock 
disagreeing about filepath formats, meaning that
.haddock files aren't found on Windows). 


I assume that code will be useful to other Haskell IDEs,
though it is mostly exposing Haddock's internal ability to
build an index from .haddock files, which I'd like to see
exposed in Haddock's less-than-well-known API:

   http://trac.haskell.org/haddock/ticket/157

Claus


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Terminate unused worker threads

[Simon Marlow]

On 17/11/2010 18:55, Ryan Newton wrote:

Hi all,

Apologies for commenting before understanding Capability.c very well.
  But it seems that this file uses locking quite heavily.  Has there
been an analysis of whether atomic memory ops and lock free algorithms
could play any role here?


The locks here are mostly used when handing over the Capability between 
OS threads, or when an OS thread is going idle, and neither of these are 
going to be made faster by using lock-free data structures.  In fact, 
the lock on the Capability is only used to protect a very few fields - 
most of the fields are private to the Capability and require no locking.


However, there is one place that I think a better implementation could 
be used.  Each Capability has a message queue, which needs to behave 
like a multiple-writer single-reader buffer (order is unimportant). 
Currently it's a linked list protected by a lock, and this is bad - 
multiple writers contend for the lock with the reader.  Having the 
reader take the whole buffer in one go was an improvement, but doesn't 
completely solve the problem.  Something I need to be careful of is that 
the Capability should never go idle when the queue is non-empty (we 
don't want a lost wakeup), so presumably the lock is needed when the 
queue goes from empty to non-empty, but otherwise a lock-free operation 
to add items should suffice.


I haven't trawled the literature yet - is there a known data structure 
that would be good here?


Cheers,
Simon



Simon mentioned keeping track of the number of items in the queue so as
not to have to traverse it while holding the lock.  That, for example,
seems that it could be accomplished with an atomically modified counter.

Cheers,
   -Ryan

On Wed, Nov 17, 2010 at 10:25 AM, Edward Z. Yang mailto:ezy...@mit.edu>> wrote:

Excerpts from Simon Marlow's message of Wed Nov 17 06:15:46 -0500 2010:
 > I suggest keeping track of the number of items in the queue.

Ok, I added a spare_workers_no field to the Capability struct.

 > So I think the main thing missing is a call to workerTaskStop().

Added.

 > It would be really nice if we could arrange that in the case where we
 > have too many spare workers, the extra workers exit via the same
route,
 > but I suspect that might not be easy.

Do you mean, spare workers that have useful tasks to do?

Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users