GHC | 1 Aug 2006 19:01
Favicon

Re: [GHC] #672: INLINE pragmas for default methods don't work

#672: INLINE pragmas for default methods don't work
-----------------------+----------------------------------------------------
  Reporter:  simonpj   |          Owner:  simonpj
      Type:  bug       |         Status:  closed 
  Priority:  normal    |      Milestone:  6.6    
 Component:  Compiler  |        Version:  6.4.1  
  Severity:  minor     |     Resolution:  fixed  
  Keywords:            |             Os:  Unknown
Difficulty:  Unknown   |   Architecture:  Unknown
-----------------------+----------------------------------------------------
Changes (by simonpj):

  * resolution:  => fixed
  * status:  new => closed

Comment:

 So far as I can see, this works fine in both 6.4.2 and the HEAD.
 So I'm closing the bug.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/672>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs <at> haskell.org
(Continue reading)

Duncan Coutts | 1 Aug 2006 19:54
Picon
Picon
Favicon

Re: .h files not found when compiling via C

On Sun, 2006-07-23 at 18:09 +0200, Volker Wysk wrote:
> Hello
> 
> When compiling a module, which contains "foreign import" directives, via C, 
> the C compiler needs to be passed a "-I." argument, otherwise the include 
> file mentioned there won't be found.
> 
> You can do this manually with an "-I." argument to ghc (after you figure it 
> out), but since this is always necessary, I consider it a bug.

I believe this behaviour was changed in GHC 6.4 or perhaps it was 6.2. I
forget. Anyway, it was deliberate (I think!). Remember that you can
include things from the system's standard include search path without
specifying -I, so you don't always have to use -I. You only need it if
you are using local .h files, in which case, the argument goes, why not
be explicit about that fact? That's one rationale for the change.

Duncan
Simon Peyton-Jones | 2 Aug 2006 13:50
Picon
Favicon
Gravatar

RE: GHCi on "loosing" its handles takes 100% CPU

Simon and I have no idea what's going on here.  It doesn't happen for me
(on my Windows laptop).

Can anyone else reproduce this behaviour?  If so, is anyone willing to
dive in a bit deeper and find out more about what is going on?

Regardless, creating a Trac bug report would ensure it doesn't lost.

Simon

| -----Original Message-----
| From: glasgow-haskell-bugs-bounces <at> haskell.org
[mailto:glasgow-haskell-bugs-bounces <at> haskell.org]
| On Behalf Of Neil Mitchell
| Sent: 29 July 2006 20:16
| To: glasgow-haskell-bugs <at> haskell.org
| Subject: GHCi on "loosing" its handles takes 100% CPU
| 
| Hi
| 
| On Windows, GHC 6.4.2, the following program:
| 
| import System.Process
| main = runInteractiveCommand "ghc"
| 
| When run terminates immediately, as expected, but leaves an instance
| of ghc running. The ghc process takes up 100% of the CPU time, and
| seemingly does nothing.
| 
| If "ghci" is used as the argument instead of "ghc", then both ghc and
(Continue reading)

GHC | 2 Aug 2006 14:10
Favicon

Re: [GHC] #603: GC-spy connection

#603: GC-spy connection
---------------------------------+------------------------------------------
  Reporter:  simonmar            |          Owner:         
      Type:  task                |         Status:  new    
  Priority:  normal              |      Milestone:         
 Component:  Runtime System      |        Version:  None   
  Severity:  normal              |     Resolution:  None   
  Keywords:                      |             Os:  Unknown
Difficulty:  Difficult (1 week)  |   Architecture:  Unknown
---------------------------------+------------------------------------------
Old description:

> {{{
> (similar to the Front Panel task).  Connect GHC's garbage collector to
> the GC spy tool, which gives a graphical display of heap characteristics
> at runtime.
> }}}

New description:

 Connect GHC's garbage collector to the
 [http://research.sun.com/projects/gcspy/ GC spy tool], which gives a
 graphical display of heap characteristics at runtime.

 (Similar to the Front Panel task.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/603>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
(Continue reading)

GHC | 2 Aug 2006 14:10
Favicon

Re: [GHC] #601: Replace GMP

#601: Replace GMP
---------------------------------+------------------------------------------
  Reporter:  simonmar            |          Owner:         
      Type:  task                |         Status:  new    
  Priority:  normal              |      Milestone:         
 Component:  Compiler            |        Version:  None   
  Severity:  normal              |     Resolution:  None   
  Keywords:                      |             Os:  Unknown
Difficulty:  Difficult (1 week)  |   Architecture:  Unknown
---------------------------------+------------------------------------------
Old description:

> {{{
> GMP is a great multi-precision integer library, but its LGPL license is
> problematic for users of GHC (it prohibits static linking of GHC-compiled
> programs, for example).
>
> One possible alternative would be to use the bignum library from OpenSSL,
> which is available under a BSD-style license.
>
> }}}

New description:

 GMP is a great multi-precision integer library, but its LGPL license is
 problematic for users of GHC (it prohibits static linking of GHC-compiled
 programs, for example).

 One possible alternative would be to use the bignum library from OpenSSL,
 which is available under a BSD-style license.
(Continue reading)

Simon Marlow | 2 Aug 2006 14:14
Picon

Re: forkIO and not -threaded

Duncan Coutts wrote:
> On Sat, 2006-07-29 at 01:29 +0100, Neil Mitchell wrote:
> 
>>Hi,
>>
>>main = do
>>  forkIO $ print "yes"
>>  print "done"
>>
>>Compiled without -threaded, on 6.2.2 gives
>>
>>"yes"
>>"done"
>>
>>on 6.4.2
>>
>>"done"
>>
>>Seems the semantics of forkIO in this case has changed completely?
> 
> 
> Actually what changed is whether all threads have to finish or just the
> main thread.
> 
> So what happens now with your code is that the main thread terminates
> the whole program before the other thread gets a chance to run.

Nothing has really changed here at all: the program has non-deterministic 
behaviour.  The runtime doesn't wait for all threads to finish before exiting, 
it exits as soon as the main thread has finished, see the docs:
(Continue reading)

GHC | 2 Aug 2006 14:19
Favicon

[GHC] #839: Generate documentation for built-in functiuons

#839: Generate documentation for built-in functiuons
-------------------------+--------------------------------------------------
    Reporter:  simonpj   |        Owner:         
        Type:  task      |       Status:  new    
    Priority:  normal    |    Milestone:         
   Component:  Compiler  |      Version:  6.4.2  
    Severity:  normal    |     Keywords:         
          Os:  Unknown   |   Difficulty:  Unknown
Architecture:  Unknown   |  
-------------------------+--------------------------------------------------
GHC has a handful of built-in functions, that are
   * Not primops
   * Are not definable in Haskell
   * But are definable in Core
   * Are defined in the compiler itself, in basicTypes/MkId.lhs
   * Come from the pseudo-module {{{GHC.Prim}}}, like primops and primitive
 types.
 The examples I can think of are
   * unsafeCoerce
   * inline
   * lazy
 Currently they are documented in the
 [http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.html

 (HEAD) user manual], but they are invisible to Haddock, and hence do not
 appear in the online Haddock documentation.  This is bad.

 You might think that the same would be true of the primitive operations
 (primops).  However, the primops are described by a text file
 {{{prelude/primops.txt.pp}}, and there's a preprocessor
 ({{{utils/genprimopcode}}}) that generates the base-package pseudo-module
(Continue reading)

GHC | 2 Aug 2006 14:33
Favicon

[GHC] #840: GHC on "loosing" its handles takes 100% CPU

#840: GHC on "loosing" its handles takes 100% CPU
-------------------------+--------------------------------------------------
    Reporter:  guest     |        Owner:         
        Type:  bug       |       Status:  new    
    Priority:  normal    |    Milestone:         
   Component:  Compiler  |      Version:  6.4.2  
    Severity:  normal    |     Keywords:         
          Os:  Windows   |   Difficulty:  Unknown
Architecture:  x86       |  
-------------------------+--------------------------------------------------
On Windows, GHC 6.4.2, the following program:

 import System.Process
 main = runInteractiveCommand "ghc"

 When run terminates immediately, as expected, but leaves an instance
 of ghc running. The ghc process takes up 100% of the CPU time, and
 seemingly does nothing.

 If "ghci" is used as the argument instead of "ghc", then both ghc and
 ghci are left running, with ghc on 100% CPU time.

 In contrast, if hugs or Yhc or edit (or pretty much any program on my
 system) is run in exactly the same way, they terminate as soon as the
 main program is finished.

 I have replicated this bug on two separate machines, with the following
 similarities/differences.

 Both Windows XP
(Continue reading)

Bulat Ziganshin | 2 Aug 2006 16:09
Picon

Re: [GHC] #840: GHC on "loosing" its handles takes 100% CPU

Hello GHC,

Wednesday, August 2, 2006, 4:33:09 PM, you wrote:

> #840: GHC on "loosing" its handles takes 100% CPU

>  import System.Process
>  main = runInteractiveCommand "ghc"

>  When run terminates immediately, as expected, but leaves an instance
>  of ghc running. The ghc process takes up 100% of the CPU time, and
>  seemingly does nothing.

well, i have similar problem: there are only 256 megs on my machine
and sometimes when ghc compilation uses more than 200 megs and starts
trashing memory, i tries to stop it by hitting Ctrl-C. in this
situation it's rather typical that i got back my console (and rerun
ghc) but old GHC process don't killed and continue to compile program.
i can investigate it further but don't know what to do. at least it
seems that memory trashing is required to uncover this problem. i also
should note that i run "ghc --make" from the .cmd file so there is a
whole stack of processes runned. may be i just kill higher-level ghc
(or even cmd) and lower-level ghc still continue to do it's job? i'm
not sure..

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
GHC | 2 Aug 2006 17:33
Favicon

Re: [GHC] #820: problem compiling a file with top level Template Haskell splice

#820: problem compiling a file with top level Template Haskell splice
-------------------------------+--------------------------------------------
  Reporter:  guest             |          Owner:                
      Type:  bug               |         Status:  new           
  Priority:  normal            |      Milestone:  6.6           
 Component:  Template Haskell  |        Version:  6.4.2         
  Severity:  normal            |     Resolution:                
  Keywords:                    |             Os:  Linux         
Difficulty:  Unknown           |   Architecture:  x86_64 (amd64)
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * milestone:  6.4.2 => 6.6

Comment:

 update milestone (it was 6.4.2)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/820>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Gmane