Re: help with threadDelay

2006-11-22 Thread Simon Marlow 

Ian Lynagh wrote:

[moving to glasgow-haskell-bugs]

On Wed, Nov 15, 2006 at 11:40:12PM +, Neil Davies wrote:


however when -threaded is used you get some interesting effects,
including returning too early:

Tgt/Actual = 0.000125/0.34s, diff = -0.91s



Thanks for the report; I can reproduce it on Linux/amd64.

OK, so the bug here is that threadDelay n might return after less than n
microseconds.

This looks like it's caused by truncation problems when converting times
to ticks (where a tick is 1/50 of a second), e.g. while trying to sleep
for 1.953125s one run started at 1164157960.773726s which is
  (Int) 1164157960 * 50 + 773726 * 50 / 100
= (Int) 58207898038.6863
= 58207898038 ticks
and woke the thread up at 1164157962.708609s which is
  (Int) 1164157962 * 50 + 708609 * 50 / 100
= (Int) 58207898135.4305
= 58207898135 ticks

The difference is 58207898135 - 58207898038 = 97 ticks.

Meanwhile we're trying to sleep for
  (Int) 50 * 1.953125
= (Int) 97.65625
= 97 ticks

However, 1164157962.708609s - 1164157960.773726s = 1.93488311767578s
which is 0.0182418823242201s too short.

The problem is that we have counted 0.6863 ticks before the start time,
not counted 0.4305 ticks before the finish time and have been waiting
0.65625 ticks too short a time. Thus we have counted
(0.6863-0.4305 + 0.65625) / 50 == 0.018241 too much time.

I think the answer is that

let target = now + usecs `quot` tick_usecs

in GHC/Conc.lhs should be

let target = 1 + now + (usecs + tick_usecs - 1) `quot` tick_usecs

I'm also a bit dubious about the use of the constant 50 for the number
of ticks per second, but the results with +RTS -V0.001 don't look any
more wrong so perhaps I just need to get some sleep.


The hardcoded 50 in GHC/Conc.lhs matches up with TICK_FREQ in 
libraries/base/includes/HsBase.h.  It could probably be made larger without any 
ill effects.  I agree that we should round up the target time to the nearest 
tick rather than rounding down, though.


Cheers,
Simon

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

Re: [GHC] #1021: GHC static libraries are not position independent in OSX

2006-11-22 Thread GHC 
#1021: GHC static libraries are not position independent in OSX
--+-
 Reporter:  guest |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone: 
Component:  Build System  |Version:  6.6
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  powerpc
   Os:  MacOS X   |  
--+-
Comment (by wolfgang):

 There is a flag for Apple's linker, -read_only_relocs suppress, which
 allows you to link bundles with non-position-independent code.
 Position-independent code is *not* strictly required to build a bundle or
 a dynamic library, but:

  * position-dependent bundles/libraries take slightly longer to load,
 because they have to be relocated at load-time
  * if more than one process uses the bundle/library, it has to be loaded
 into memory separately for each process, i.e. the shared library is not
 really shared.

 On the other hand, position-independent code is slightly bigger and slower
 than position-dependent code (on most platforms, including powerpc and
 x86), so -fPIC was left off by default. Everyone, feel free to comment.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1021
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #1022: Add System.FilePath to base

2006-11-22 Thread GHC 
#1022: Add System.FilePath to base
---+
Reporter:  guest   |   Owner: 
Type:  proposal|  Status:  new
Priority:  normal  |   Milestone: 
   Component:  libraries/base  | Version:  6.6
Severity:  normal  |Keywords: 
  Difficulty:  Unknown |Testcase: 
Architecture:  Unknown |  Os:  Unknown
---+
Here is the proposal to add System.FilePath to base. The System.FilePath
 module is located at http://www-
 users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath

 In particular I propose the addition of System.FilePath (a
 cross-platform FilePath manipulation library), System.FilePath.Windows
 (Windows paths on all OS's) and System.FilePath.Posix (Posix paths on
 all OS's). The Version_* stuff is not being proposed for addition.

 http://article.gmane.org/gmane.comp.lang.haskell.libraries/5751

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1022
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1022: Add System.FilePath to base

2006-11-22 Thread GHC 
#1022: Add System.FilePath to base
+---
 Reporter:  guest   |  Owner: 
 Type:  proposal| Status:  new
 Priority:  normal  |  Milestone: 
Component:  libraries/base  |Version:  6.6
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  Unknown
   Os:  Unknown |  
+---
Changes (by guest):

  * cc:  = [EMAIL PROTECTED]

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1022
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1002: ghc-6.6 sometimes hangs under Solaris

2006-11-22 Thread GHC 
#1002: ghc-6.6 sometimes hangs under Solaris
---+
 Reporter:  [EMAIL PROTECTED]  |  Owner:  
 Type:  bug| Status:  closed  
 Priority:  normal |  Milestone:  6.6.1   
Component:  Compiler   |Version:  6.6 
 Severity:  normal | Resolution:  invalid 
 Keywords: | Difficulty:  Unknown 
 Testcase:  N/A|   Architecture:  Multiple
   Os:  Solaris|  
---+
Changes (by [EMAIL PROTECTED]):

  * resolution:  = invalid
  * status:  new = closed

Comment:

 close this bug. I could never observe the hanging behaviour again with the
 threaded RTS. The slow compilation with optimization is gone when I use
 ghc -M and compile the files individually.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1002
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1021: GHC static libraries are not position independent in OSX

2006-11-22 Thread GHC 
#1021: GHC static libraries are not position independent in OSX
--+-
 Reporter:  guest |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone: 
Component:  Build System  |Version:  6.6
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  powerpc
   Os:  MacOS X   |  
--+-
Comment (by [EMAIL PROTECTED]):

 It could surely be fixed by linking with -dynamic.

 That would allow to avoid  -read_only_relocs suppress, but normally ghc
 distributions (macports at least) don't include dynamic libraries.

 See feature request 1020 and http://lists.macosforge.org/pipermail
 /macports-users/2006-November/000728.html (macport request)

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1021
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1020: Build dynamic libraries by default for OSX

2006-11-22 Thread GHC 
#1020: Build dynamic libraries by default for OSX
-+--
 Reporter:  guest|  Owner: 
 Type:  feature request  | Status:  new
 Priority:  normal   |  Milestone: 
Component:  Build System |Version:  6.6
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  MacOS X  |  
-+--
Changes (by guest):

  * os:  Unknown = MacOS X

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1020
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1006: 'impossible' happened in reportNoInstance?

2006-11-22 Thread GHC 
#1006: 'impossible' happened in reportNoInstance?
-+--
 Reporter:  SamB |  Owner: 
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone: 
Component:  Compiler (Type checker)  |Version:  6.7
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:  tcfail171|   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by simonpj):

  * testcase:  = tcfail171

Comment:

 I've fixed this.  Thanks for reporting it.

 tcfail171 tests

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1006
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #962: hptRules crash

2006-11-22 Thread GHC 
#962: hptRules crash
--+-
 Reporter:  guest |  Owner: 
 Type:  bug   | Status:  closed 
 Priority:  normal|  Milestone:  6.6.1  
Component:  Compiler  |Version:  6.6
 Severity:  normal| Resolution:  invalid
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by simonpj):

  * resolution:  = invalid
  * status:  new = closed

Comment:

 I'm going to close this, because it seems to be an interface-file
 consistency problem.  Still, GHC shouldn't crash under those
 circumstances, so I've made a fix that makes GHC emit a WARNING but
 recover in a reasonable way and carry on.

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/962
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1021: GHC static libraries are not position independent in OSX

2006-11-22 Thread GHC 
#1021: GHC static libraries are not position independent in OSX
--+-
 Reporter:  guest |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone: 
Component:  Build System  |Version:  6.6
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  powerpc
   Os:  MacOS X   |  
--+-
Comment (by [EMAIL PROTECTED]):

 Furthermore ... It definitively doesn't make sense to support -fPIC in an
 architecture in which no GHC position independent libraries are available.

 wolfgang says those libraries would be slightly bigger and slower ...

 .. Then a good solution would to provide position independednt libraries
 (appart from the position dependent) for those architectures and only link
 against those when -fPIC is supplied.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1021
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1018: ghci dynamic loading of X11 - unknown symbol `_printf$LDBLStub'

2006-11-22 Thread GHC 
#1018: ghci dynamic loading of X11 - unknown symbol `_printf$LDBLStub'
--+-
 Reporter:  ykardia   |  Owner: 
 Type:  bug   | Status:  closed 
 Priority:  normal|  Milestone:  6.6.1  
Component:  GHCi  |Version:  6.6
 Severity:  normal| Resolution:  fixed  
 Keywords:  X11, dynamic loading  | Difficulty:  Unknown
 Testcase:|   Architecture:  powerpc
   Os:  MacOS X   |  
--+-
Comment (by [EMAIL PROTECTED]):

 For ghc-6.6 built using !MacPorts, I have applied Wolfgang's patch and
 also patched libraries/X11/package.conf.in to include /usr/X11R6/lib in
 the search path.  It seems to work properly:
 {{{
 crossroads-able ghci -package X11
___ ___ _
   / _ \ /\  /\/ __(_)
  / /_\// /_/ / /  | |  GHC Interactive, version 6.6, for Haskell 98.
 / /_\\/ __  / /___| |  http://www.haskell.org/ghc/
 \/\/ /_/\/|_|  Type :? for help.

 Loading package base ... linking ... done.
 Loading package X11-1.1 ... linking ... done.
 Prelude

 }}}

 To get the patched ghc, make sure you are building revision 2 of the
 ghc-6.6 port.  (As always, port info ghc is your friend.)

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1018
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #1023: Core Lint Errors: in result of Simplifier phase 0, iteration 1 out of 4, ss_atJ is out of scope

2006-11-22 Thread GHC 
#1023: Core Lint Errors: in result of Simplifier phase 0, iteration 1 out of 4,
ss_atJ is out of scope
---+
Reporter:  [EMAIL PROTECTED]  |   Owner:  
Type:  bug |  Status:  new 
Priority:  normal  |   Milestone:  
   Component:  Compiler| Version:  6.7 
Severity:  normal  |Keywords:  
  Difficulty:  Unknown |Testcase:  
Architecture:  Multiple|  Os:  Multiple
---+
{{{
 [EMAIL PROTECTED]:~/Work/lambdavm-nofib/real/parser$ 
~/Work/ghc/compiler/ghc-inplace
 -O2 Main.hs
 ghc-6.7: panic! (the 'impossible' happened)
   (GHC version 6.7 for powerpc-apple-darwin):
 initC: srt

 [EMAIL PROTECTED]:~/Work/lambdavm-nofib/real/parser$ 
~/Work/ghc/compiler/ghc-inplace
 -O2 -dcore-lint -v Main.hs
 (Lots of output snipped)
 *** Core Lint Errors: in result of Simplifier phase 0, iteration 1 out of
 4 ***
 no location info:
 In the expression: $slaLayout_s4qC ss_atJ
 ss_atJ is out of scope
 (More snipped output)
 }}}

 Works fine with just -O (instead of -O2) and with ghc-6.6 -O2.

 Main.hs (attached) is right out of nofib/real/parser

 There are a few other tickets mentioning initC: srt. I'm not sure if
 they are related or if the code generator is just failing with the same
 error for different reasons.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1023
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs