Re: [GHC] #1012: ghc panic with mutually recursive modules and template haskell
#1012: ghc panic with mutually recursive modules and template haskell
+---
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component: Compiler|Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: TH_import_loop | Architecture: Multiple
Os: Multiple|
+---
Comment (by simonmar):
This now gives a slightly improved error message, as a result of the fix
for #936:
{{{
[1 of 5] Compiling A[boot] ( A.hs-boot, nothing )
[2 of 5] Compiling C( C.hs, C.o )
[3 of 5] Compiling B( B.hs, B.o )
Loading package base ... linking ... done.
module main:A cannot be linked; it is only available as a boot module
}}}
Simon: please feel free to edit the error message if you can think of a
way to improve it (compiler/ghci/Linker.hs). Should we close this bug?
Perhaps document the shortcoming in the TH docs?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1012
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] #1128: The impossible happened, code commented
#1128: The impossible happened, code commented
--+-
Reporter: humasect | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.6.1
Component: Compiler |Version: 6.6
Severity: major | Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: Unknown
Os: Unknown |
--+-
Old description:
initializeWorld = (\w - do
worldSetGravity w 0 (-1.0) 0
worldSetERP w 0.2
worldSetCFM w 1e-5
worldSetContactMaxCorrectingVel w 0.9
worldSetContactSurfaceLayer w 0.001
worldSetAutoDisableFlag w 1),
these worldSet* functions are unsafe FFI calls. initializeWorld is Ptr
Int - IO ()
commenting this prevents this bug. this code is found in a top level
declaration:
initiailLevel = Level {
...
}
of which contains the record for initializeWorld
New description:
{{{
initializeWorld = (\w - do
worldSetGravity w 0 (-1.0) 0
worldSetERP w 0.2
worldSetCFM w 1e-5
worldSetContactMaxCorrectingVel w 0.9
worldSetContactSurfaceLayer w 0.001
worldSetAutoDisableFlag w 1),
}}}
these worldSet* functions are unsafe FFI calls. initializeWorld is `Ptr
Int - IO ()`
commenting this prevents this bug. this code is found in a top level
declaration:
{{{
initiailLevel = Level {
...
}
}}}
of which contains the record for initializeWorld
Comment (by simonpj):
You need to give us a few more clues! For example, the error message you
get.
But for this one we'll probably need to be able to reproduce your problem.
Can you make a small program that demonstrates it? Thanks
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1128
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] #1012: ghc panic with mutually recursive modules and template haskell
#1012: ghc panic with mutually recursive modules and template haskell +--- Reporter: guest | Owner: Type: merge | Status: new Priority: normal | Milestone: _|_ Component: Compiler|Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_import_loop | Architecture: Multiple Os: Multiple| +--- Changes (by simonpj): * type: bug = merge Comment: I've updated the docs. Ian, please merge. Wed Jan 31 09:14:51 GMT 2007 [EMAIL PROTECTED] * Add note about Template Haskell and mutual recursion Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1012 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] #1012: ghc panic with mutually recursive modules and template haskell
#1012: ghc panic with mutually recursive modules and template haskell +--- Reporter: guest | Owner: Type: merge | Status: closed Priority: normal | Milestone: _|_ Component: Compiler|Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_import_loop | Architecture: Multiple Os: Multiple| +--- Changes (by igloo): * resolution: = fixed * status: new = closed Comment: Merged. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1012 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] #1122: Trying to declare an infix newtype yields ghc panic
#1122: Trying to declare an infix newtype yields ghc panic
--+-
Reporter: guest | Owner: igloo
Type: merge | Status: closed
Priority: normal| Milestone: 6.6.1
Component: Compiler |Version: 6.6
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase: tc173 | Architecture: x86
Os: Linux |
--+-
Changes (by igloo):
* resolution: = fixed
* status: new = closed
Comment:
Merged:
{{{
Wed Jan 31 11:57:46 GMT 2007 Ian Lynagh [EMAIL PROTECTED]
* MERGED: Fix Trac #1122; spot absence of TyCon in data/newtype header
Tue Jan 30 16:13:30 GMT 2007 [EMAIL PROTECTED]
}}}
{{{
Wed Jan 31 11:57:02 GMT 2007 Ian Lynagh [EMAIL PROTECTED]
* MERGED: Add test for infix type constructor
Tue Jan 30 16:10:53 GMT 2007 [EMAIL PROTECTED]
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1122
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] #896: GetLastError/SetLastError in Windows
#896: GetLastError/SetLastError in Windows +--- Reporter: eivuokko| Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | +--- Changes (by igloo): * resolution: = fixed * status: new = closed Comment: Merged. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/896 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] #1129: recvFrom blocking
#1129: recvFrom blocking --+- Reporter: JuanMarcus | Owner: Type: bug| Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.6 Severity: blocker|Keywords: Difficulty: Unknown|Testcase: Architecture: Unknown| Os: Windows --+- Using recvFrom inside a thread on Windows blocks the whole process, instead of blocking only the calling thread. On linux, the same function works perfectly fine. Using only recv works fine on both systems. Windows: latest MinGW, MSYS, GHC 6.6 or 6.4 Linux: gcc 3.3.5, posix threads, ghc 6.2 or 6.4 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1129 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] #1129: recvFrom blocking
#1129: recvFrom blocking ---+ Reporter: JuanMarcus | Owner: Type: bug| Status: new Priority: normal | Milestone: Component: libraries/network |Version: 6.6 Severity: blocker| Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows| ---+ Changes (by JuanMarcus): * architecture: Unknown = x86 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1129 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] #1127: Make mtl lazier
#1127: Make mtl lazier ---+ Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown| ---+ Changes (by igloo): * summary: Make StateT in mtl truly lazy = Make mtl lazier Old description: The StateT monad gives every impression of intending to be lazy, but the absence of a ~ means that it isn't fully lazy. This bit me in the compression library, meaning I currently bundle a LazyStateT module that provides essentially StateT with this change. There was also a recent discussion about it on one of the mailing lists: http://www.haskell.org/pipermail/haskell-cafe/2007-January/021244.html I propose making StateT lazy. Deadline: 28 February 2007. New description: I propose making mtl lazier. Currently the transformers force tuples to WHNF as they put them on the left of - in do blocks. I suspect this was unintentional, and makes them less lazy than their non-transformer counterparts. For example, the StateT monad gives every impression of intending to be lazy, but the absence of a ~ means that it isn't fully lazy. This bit me in the compression library, meaning I currently bundle a LazyStateT module that provides essentially StateT with this change. There was also a recent discussion about it on one of the mailing lists: http://www.haskell.org/pipermail/haskell-cafe/2007-January/021244.html Deadline: 28 February 2007. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1127 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] #1127: Make mtl lazier
#1127: Make mtl lazier ---+ Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown| ---+ Comment (by simonmar): I don't mind whether StateT itself is lazy or not, but I think we should have a strict version. In GHC the implementation should use unboxed tuples, like IO. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1127 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] #418: throwTo to a thread inside 'block'
#418: throwTo to a thread inside 'block' +--- Reporter: remit | Owner: igloo Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System |Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | +--- Changes (by simonmar): * milestone: 6.6.1 = _|_ * summary: unsafeInterleaveIO + Ctrl-C/killThread related segfault = throwTo to a thread inside 'block' Comment: Following discussion with Igloo, both results are acceptable. It depends whether the `putMVar` inside `readMVar` gets to execute before the second `putMVar` in the main thread - there's a race, leading to two possible answers. Leaving the bug open, as there's still a problem (see earlier comments). When we throw an exception to a thread inside 'block', and then restart the computation, the blocked state is not re-instated. This can only happen if the thread was executing `block` inside `unsafePerformIO` or `unsafeInterleaveIO`, so the bug is unlikely to bite many people. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/418 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] #471: Windows HGL Thread problems
#471: Windows HGL Thread problems +--- Reporter: mjthomas| Owner: nobody Type: bug | Status: assigned Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | +--- Comment (by simonmar): These might be related: #1081, #742 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/471 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] #742: Graphics.SOE runs very slowly under win32.
#742: Graphics.SOE runs very slowly under win32. ---+ Reporter: guest | Owner: Type: bug| Status: new Priority: normal | Milestone: 6.6.1 Component: libraries (other) |Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows| ---+ Comment (by simonmar): These might be related: #1081, #471 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/742 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] #1081: HGL indefinite pause with thread blocked indefinitely message
#1081: HGL indefinite pause with thread blocked indefinitely message -+-- Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other)|Version: 6.6 Severity: normal | Resolution: Keywords: hgl thread deadlock | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -+-- Comment (by simonmar): These might be related: #471, #742 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1081 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] #957: No way to use -lgmp from a non-standard location
#957: No way to use -lgmp from a non-standard location --+- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.6.1 Component: Build System |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: FreeBSD | --+- Changes (by simonmar): * summary: Build failure in Cabal/cabal-setup: -lgmp doesn't honor LDFLAGS = No way to use -lgmp from a non- standard location Comment: Changed title to reflect the real bug: we don't have configure options to select an alternative place to look for `-lgmp` or `gmp.h`. See the way we do this for readline, for example, in `libraries/readline/configure.ac`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/957 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] #822: -keep-tmp-files does not keep all temporary files
#822: -keep-tmp-files does not keep all temporary files
-+--
Reporter: [EMAIL PROTECTED] | Owner: igloo
Type: bug | Status: closed
Priority: normal | Milestone: 6.6.1
Component: Driver |Version: 6.4.2
Severity: minor| Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86_64 (amd64)
Os: Linux|
-+--
Changes (by igloo):
* resolution: = fixed
* status: new = closed
Comment:
Fixed in the HEAD and 6.6 branch by
{{{
Wed Jan 31 15:10:58 GMT 2007 Ian Lynagh [EMAIL PROTECTED]
* Always pay attention to -keep-tmp-files when we want to delete files
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/822
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
Visual Haskell install error
Hello, when I try to install Visual Haskell for Visual Studio 2003 I get the following errors: Failed to setup vs_haskell.dll Failed to setup vs_haskell_babel.dll Failed to setup vs_haskell_dlg.dll Is there a solution for this bug? Send instant messages to your online friends http://au.messenger.yahoo.com ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1115: GHC concurrency runtime breaks every 497 (and a bit) days
#1115: GHC concurrency runtime breaks every 497 (and a bit) days +--- Reporter: Neil Davies | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | +--- Changes (by igloo): * status: reopened = new * owner: Neil Davies = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1115 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] #1128: The impossible happened, code commented
#1128: The impossible happened, code commented
--+-
Reporter: humasect | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.6.1
Component: Compiler |Version: 6.6
Severity: major | Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: Unknown
Os: Unknown |
--+-
Comment (by humasect):
More clues found during investigation (use ODE library if needed):
foreign import ccall unsafe dWorldSetContactSurfaceLayer
worldSetContactSurfaceLayer ::
WorldID - Real - IO ()
type WorldID = Int
type Real = Double
initializeWorld = (\w - do
--worldSetGravity w 0 (-1.0) 0
--worldSetERP w 0.2
--worldSetCFM w 1e-5
--worldSetContactMaxCorrectingVel w 0.9
worldSetContactSurfaceLayer w 0.001
), --worldSetAutoDisableFlag w 1),
--- now here is the:
--
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for i386-apple-darwin):
lookupDeprec base:GHC.Real.fromRational{v 01G}
-- Then change worldSetContactSurfaceLayer's second argument to 1.0
bug disappears.
I hope this helps
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/1128
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] #1128: The impossible happened, code commented
#1128: The impossible happened, code commented --+- Reporter: humasect | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: major | Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by humasect): Confirmed to be caused by -fno-implicit-prelude when compiling this file (Level.hs in the attachment file) with ghc --make. -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/1128 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
