headers
Simon Hengel | 4 Jul 2011 23:45

non-linear complexity of :reload combined with :module in ghci

Hi all,
I realized that ghci shows non-linear time complexity for a sequence of
:module and :reload commands, say we do multiple times:

  :module *Foo
  :reload

Steps to reproduce:

  time for i in {1..10}; do echo -e ':m Prelude\n:r'; done |ghci
  time for i in {1..99}; do echo -e ':m Prelude\n:r'; done |ghci

On my system the first run uses 1 second of CPU time, the second 39
seconds.  Is this considered a bug?

Cheers,
Simon
Permalink | Reply | 2 comments |
headers
Jonas Almström Duregård | 5 Jul 2011 00:35
Picon
Picon

Reloading and templates

Hi,

In ghci, if you change a module that exports a TH template it will not recompile modules that use the template. Example:

-- In A.hs
{-#LANGUAGE TemplateHaskell#-}
module A where
import Language.Haskell.TH
a = [d|x = 5|]

-- in B.hs
{-#LANGUAGE TemplateHaskell#-}
import A
a

-- As expected in ghci B.hs:
*Main> x
5

-- But if i change the def. of a to [d|x = 4|] and do :r
[1 of 2] Compiling A                ( A.hs, interpreted )
Ok, modules loaded: A, Main.
*Main> x
5

The only workaround i know is to reload all modules. I assume you have the same problem when compiling with ghc. This has caused headaches for me on several occasions lately, is there a ticket for it or should i submit one?

Regards,
Jonas

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Permalink | Reply | 1 comment |
headers
Simon Marlow | 6 Jul 2011 12:00
Picon

Mysterious slowness/crashing in GHCi

Hi folks,

GHCi has some weird behaviour sometimes with one or more of these symptoms:

  - becoming very slow and/or unresponsive
  - gobbling up memory
  - crashing with "thread blocked indefinitely on MVar"

Some people have reported this happening when they weren't even doing 
anything, GHCi was just sitting at the prompt.

e.g. this ticket:

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

All the reports were Windows, but I've seen it happen on Mac too (but 
not Linux).

I really need a way to reproduce this.  If anyone has any clues, or can 
offer any more information (even if it's just a "me too, on platform 
X"), please let us know.

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Greg Steuck | 7 Jul 2011 08:32

Locating extra-libraries

Hello,

I am integrating ghc-7.0.3 into our build system running on
Linux-amd64. One of the features of said build system is full
isolation from the host system. This means we do not use the default
compilers and library paths. We further have separation between
runtime and compile time paths. This means that libm.so is only
available in the compile environment and is not anywhere in rpath of
the ghc binary.

Now, I try to compile a simple TH based program. GHC fails pretty quickly:

<command line>: user specified .o/.so/.DLL could not be loaded
(libm.so: cannot open shared object file: No such file or directory)
Whilst trying to load:  (dynamic) m
Additional directories searched: (none)

After some head scratching I add -L$(dirname $lib.so) to my GHC
command line. Life is good?

Not quite, the next blow is harder, if I try to compile a slightly
more complicated project which requires run time loading of unix
package, I get:

Loading package unix-2.4.2.0 ...
<command line>: can't load .so/.DLL for: pthread (libpthread.so:
cannot open shared object file: No such file or directory)

The unix package config file lists:
extra-libraries: rt util dl pthread

This seems to be the logical consequence of "we agreed that all
extra-libraries should be found either on the search path or on the
package's library-dirs."
(http://hackage.haskell.org/trac/ghc/ticket/3930). Unfortunately my
environment does not satisfy the preconditions. I will also be hard
pressed to pinpoint the compile environment location ahead of time.
Sticking the path into the package .conf is hard. All the compiler
paths are set up with -pgm flags when I invoke GHC.

So, I resort to making this patch

diff --git a/ghc/compiler/ghci/Linker.lhs b/ghc/compiler/ghci/Linker.lhs
index bd0bb35..192d416 100644
--- a/ghc/compiler/ghci/Linker.lhs
+++ b/ghc/compiler/ghci/Linker.lhs
 <at>  <at>  -1026,7 +1026,7  <at>  <at>  linkPackages' dflags new_pks pls = do
 linkPackage :: DynFlags -> PackageConfig -> IO ()
 linkPackage dflags pkg
    = do
-        let dirs      =  Packages.libraryDirs pkg
+        let dirs      =  Packages.libraryDirs pkg ++ libraryPaths dflags

         let libs      =  Packages.hsLibraries pkg
             -- The FFI GHCi import lib isn't needed as

This effectively extends the extra-libraries search path to also
include any -L paths specified on the command lines.

Is there a better way to do what I'm doing? Is there any chance such a
patch can be applied?

Thanks
Greg
Permalink | Reply | 3 comments |
headers
Matthew Farkas-Dyck | 7 Jul 2011 20:44
Picon

Profile: zero total time

I am trying to take a profile of a program, but when I run it, the
total time (as given in the profiling report file) is zero!

total time  =        0.00 secs   (0 ticks  <at>  20 ms)

However, the -s option yields the following data:

   3,429,300,984 bytes allocated in the heap
     210,760,024 bytes copied during GC
      23,647,224 bytes maximum residency (13 sample(s))
       3,536,968 bytes maximum slop
              58 MB total memory in use (0 MB lost due to fragmentation)

  Generation 0:  6339 collections,     0 parallel,  1.14s,  1.42s elapsed
  Generation 1:    13 collections,     0 parallel,  0.28s,  0.34s elapsed

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time   96.60s  (124.50s elapsed)
  GC    time    1.42s  (  1.75s elapsed)
  RP    time    0.00s  (  0.00s elapsed)
  PROF  time    0.00s  (  0.00s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time   98.02s  (126.25s elapsed)

  %GC time       1.4%  (1.4% elapsed)

  Alloc rate    35,498,347 bytes per MUT second

  Productivity  98.5% of total user, 76.5% of total elapsed

The time taken by each cost centre is also zero. The program is
compiled with options "-prof -auto-all -caf-all" by GHC 7.0.3 and run
with RTS options "-p -s".

The true time taken is certainly NOT zero. How is this possible?

Thanks.

Cheers,
Matthew Farkas-Dyck
Permalink | Reply | 5 comments |
headers
Daniel Fischer | 7 Jul 2011 21:03

Re: Profile: zero total time

On Thursday 07 July 2011, 20:44:57, Matthew Farkas-Dyck wrote:
> I am trying to take a profile of a program, but when I run it, the
> total time (as given in the profiling report file) is zero!

If you're on a Mac, it could be

http://hackage.haskell.org/trac/ghc/ticket/5282
Permalink | Reply | 4 comments |
headers
Matthew Farkas-Dyck | 7 Jul 2011 21:45
Picon

Re: Profile: zero total time

Sorry, I ought to have mentioned:

$ uname -sr
Linux 2.6.38

On 7 July 2011 14:03, Daniel Fischer <daniel.is.fischer <at> googlemail.com> wrote:
> On Thursday 07 July 2011, 20:44:57, Matthew Farkas-Dyck wrote:
>> I am trying to take a profile of a program, but when I run it, the
>> total time (as given in the profiling report file) is zero!
>
> If you're on a Mac, it could be
>
> http://hackage.haskell.org/trac/ghc/ticket/5282
>

--

-- 
Matthew Farkas-Dyck
Permalink | Reply | 3 comments |
headers
David Peixotto | 8 Jul 2011 23:27
Favicon
Gravatar

Re: Profile: zero total time

Does it make a difference if you use the threaded vs. non-threaded runtime? I'm seeing the odd behavior on
Mac, but only for the single-threaed runtime.

http://hackage.haskell.org/trac/ghc/ticket/5282#comment:8

On Jul 7, 2011, at 2:45 PM, Matthew Farkas-Dyck wrote:

> Sorry, I ought to have mentioned:
> 
> $ uname -sr
> Linux 2.6.38
> 
> On 7 July 2011 14:03, Daniel Fischer <daniel.is.fischer <at> googlemail.com> wrote:
>> On Thursday 07 July 2011, 20:44:57, Matthew Farkas-Dyck wrote:
>>> I am trying to take a profile of a program, but when I run it, the
>>> total time (as given in the profiling report file) is zero!
>> 
>> If you're on a Mac, it could be
>> 
>> http://hackage.haskell.org/trac/ghc/ticket/5282
>> 
> 
> 
> 
> -- 
> Matthew Farkas-Dyck
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
Permalink | Reply | 2 comments |
headers
Matthew Farkas-Dyck | 9 Jul 2011 14:29
Picon

Re: Profile: zero total time

Yes -- I just tried it threaded, and the profile is true.

Thanks for your help.

Might this warrant another ticket?

On 8 July 2011 16:27, David Peixotto <dmp <at> rice.edu> wrote:
> Does it make a difference if you use the threaded vs. non-threaded runtime? I'm seeing the odd behavior on
Mac, but only for the single-threaed runtime.
>
> http://hackage.haskell.org/trac/ghc/ticket/5282#comment:8
>
> On Jul 7, 2011, at 2:45 PM, Matthew Farkas-Dyck wrote:
>
>> Sorry, I ought to have mentioned:
>>
>> $ uname -sr
>> Linux 2.6.38
>>
>> On 7 July 2011 14:03, Daniel Fischer <daniel.is.fischer <at> googlemail.com> wrote:
>>> On Thursday 07 July 2011, 20:44:57, Matthew Farkas-Dyck wrote:
>>>> I am trying to take a profile of a program, but when I run it, the
>>>> total time (as given in the profiling report file) is zero!
>>>
>>> If you're on a Mac, it could be
>>>
>>> http://hackage.haskell.org/trac/ghc/ticket/5282
>>>
>>
>>
>>
>> --
>> Matthew Farkas-Dyck
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>

--

-- 
Matthew Farkas-Dyck
Permalink | Reply | 1 comment |
headers
Simon Marlow | 11 Jul 2011 14:31
Picon

Re: Reloading and templates

On 04/07/2011 23:35, Jonas Almström Duregård wrote:
> Hi,
>
> In ghci, if you change a module that exports a TH template it will not
> recompile modules that use the template. Example:
>
> -- In A.hs
> {-#LANGUAGE TemplateHaskell#-}
> module A where
> import Language.Haskell.TH <http://Language.Haskell.TH>
> a = [d|x = 5|]
>
> -- in B.hs
> {-#LANGUAGE TemplateHaskell#-}
> import A
> a
>
> -- As expected in ghci B.hs:
> *Main> x
> 5
>
> -- But if i change the def. of a to [d|x = 4|] and do :r
> [1 of 2] Compiling A                ( A.hs, interpreted )
> Ok, modules loaded: A, Main.
> *Main> x
> 5
>
> The only workaround i know is to reload all modules. I assume you have
> the same problem when compiling with ghc. This has caused headaches for
> me on several occasions lately, is there a ticket for it or should i
> submit one?

This is the ticket:

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

please add your comments there.

Cheers,
	Simon
Permalink | Reply | 0 comments |

Gmane