Re: [GHC] #7447: Stale .hi files affect compilation.
#7447: Stale .hi files affect compilation.
---+
Reporter: int-e | Owner:
Type: bug | Status: new
Priority: high| Milestone: 7.6.2
Component: Compiler| Version: 7.6.1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Incorrect warning at compile-time
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by simonmar):
* priority: normal = high
* difficulty: = Unknown
* milestone: = 7.6.2
* failure: None/Unknown = Incorrect warning at compile-time
Comment:
Reproduced, and it still happens with HEAD. Here's the relevant bit:
{{{
echo 'module Peaker(L(..)) where{ data V = V {-# UNPACK #-} !L; data L =
L V }' Peaker.hs
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
Peaker.hs:1:38: Warning:
Ignoring unusable UNPACK pragma on the first argument of `V'
In the definition of data constructor `V'
In the data declaration for `V'
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
}}}
The warning should have been produced the second time.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7447#comment:1
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] #7447: Stale .hi files affect compilation.
#7447: Stale .hi files affect compilation.
-+--
Reporter: int-e | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
I saw the following odd behaviour while playing with the example from
#7446. Strangely, whether the warning (unusuable UNPACK pragma) is printed
or not depends on the presence and contents of a .hi file despite of
{{{--fforce-recomp}}} and even if the source file was modified.
{{{
rm -f Peaker.*
ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.1
echo 'module Peaker(V(..)) where{ data V = V {-# UNPACK #-} !L; data L =
L V }' Peaker.hs
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
Peaker.hs:1:38: Warning:
Ignoring unusable UNPACK pragma on the first argument of `V'
In the definition of data constructor `V'
In the data declaration for `V'
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
Peaker.hs:1:38: Warning:
Ignoring unusable UNPACK pragma on the first argument of `V'
In the definition of data constructor `V'
In the data declaration for `V'
rm Peaker.hi
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
Peaker.hs:1:38: Warning:
Ignoring unusable UNPACK pragma on the first argument of `V'
In the definition of data constructor `V'
In the data declaration for `V'
echo 'module Peaker(L(..)) where{ data V = V {-# UNPACK #-} !L; data L =
L V }' Peaker.hs
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
Peaker.hs:1:38: Warning:
Ignoring unusable UNPACK pragma on the first argument of `V'
In the definition of data constructor `V'
In the data declaration for `V'
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
rm Peaker.hi
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
Peaker.hs:1:38: Warning:
Ignoring unusable UNPACK pragma on the first argument of `V'
In the definition of data constructor `V'
In the data declaration for `V'
echo 'module Peaker(V(..)) where{ data V = V {-# UNPACK #-} !L; data L =
L V }' Peaker.hs
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
Peaker.hs:1:38: Warning:
Ignoring unusable UNPACK pragma on the first argument of `V'
In the definition of data constructor `V'
In the data declaration for `V'
rm Peaker.hi
ghc -fforce-recomp -O1 Peaker.hs
[1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o )
Peaker.hs:1:38: Warning:
Ignoring unusable UNPACK pragma on the first argument of `V'
In the definition of data constructor `V'
In the data declaration for `V'
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7447
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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell ---+ Reporter: ian.duncan| Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.4.1 Component: Compiler |Version: 7.0.4 Resolution: fixed | Keywords: Os: MacOS X | Architecture: x86 Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: infoneeded = closed * difficulty: = Unknown * resolution: = fixed Comment: No response from submitter, so closing. Please reopen if you think it's still broken in 7.4 or later. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399#comment:9 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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
---+
Reporter: ian.duncan |Owner:
Type: bug | Status: infoneeded
Priority: normal |Milestone: 7.4.1
Component: Compiler| Version: 7.0.4
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86 | Failure: None/Unknown
---+
Changes (by simonmar):
* status: new = infoneeded
* milestone: = 7.4.1
Comment:
Simon and I managed to reproduce the warnings. In order to get past the
type error we made the following change:
{{{
diff -c /home/simonmar/scratch/qtHaskell-1.1.4/Qtc/Core/Attributes.hs\~
/home/simonmar/scratch/qtHaskell-1.1.4/Qtc/Core/Attributes.hs
*** /home/simonmar/scratch/qtHaskell-1.1.4/Qtc/Core/Attributes.hs~
2010-09-02 17:02:32.0 +0100
--- /home/simonmar/scratch/qtHaskell-1.1.4/Qtc/Core/Attributes.hs
2011-09-07 11:19:56.0 +0100
***
*** 580,586
instance (Qstt a (QDialogSc b)) = QsaSlotReject (a) where
slotReject' = (Qslot reject(), \_ - ())
! reject' = slotReject'
class QsaSignalRejected_nt_f w x f where
signalRejected', rejected' :: x - SltConf w f
--- 580,586
instance (Qstt a (QDialogSc b)) = QsaSlotReject (a) where
slotReject' = (Qslot reject(), \_ - ())
! reject' = (Qslot reject(), \_ - ())
class QsaSignalRejected_nt_f w x f where
signalRejected', rejected' :: x - SltConf w f
}}}
We believe that the warnings are related to #5263, which was fixed in
7.2.1. Could you try with 7.2.1 or later please?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399#comment:8
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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
---+
Reporter: ian.duncan |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler| Version: 7.0.4
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86 | Failure: None/Unknown
---+
Comment(by simonmar):
I didn't get as far as module 657, there was a type error at 651:
{{{
[651 of 662] Compiling Qtc.Core.Attributes ( Qtc/Core/Attributes.hs,
dist/build/Qtc/Core/Attributes.o )
Qtc/Core/Attributes.hs:583:13:
Could not deduce (Qstt a (QDialogSc b))
arising from a use of `slotReject''
from the context (Qstt a (QDialogSc b1))
bound by the instance declaration
at Qtc/Core/Attributes.hs:581:10-52
Possible fix:
add (Qstt a (QDialogSc b)) to the context of
the instance declaration
or add an instance declaration for (Qstt a (QDialogSc b))
In the expression: slotReject'
In an equation for `reject'': reject' = slotReject'
In the instance declaration for `QsaSlotReject a'
}}}
any ideas?
BTW, it is unlikely that the Iface Id out of scope warnings would give
rise to any runtime problems, because they simply prevent an unfolding
from being used by the optimiser, which should not change behaviour. I
strongly suspect that the problem you have with labels not showing up
properly is due to something else. Nevertheless these warnings should not
happen, so we'd like to track down the cause.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399#comment:6
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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell ---+ Reporter: ian.duncan |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler| Version: 7.0.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86 | Failure: None/Unknown ---+ Comment(by simonmar): Incedentally, I had to restart the compilation at one point because the GHC process had grown to around 6Gb and was crawling. We clearly have some space leaks in `--make`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399#comment:7 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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell ---+ Reporter: ian.duncan |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler| Version: 7.0.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86 | Failure: None/Unknown ---+ Comment(by simonmar): I think I managed to get to the stage of building the Haskell code under Linux a week or so ago. Simon - let's look at this when you have time. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399#comment:5 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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
---+
Reporter: ian.duncan |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler| Version: 7.0.4
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86 | Failure: None/Unknown
---+
Comment(by simonpj):
OK, I did the following on my Windows machine
* Installed Qt, from [http://qt.nokia.com/products/platform/qt-for-
windows/]
* Downloaded qtHaskell-1.1.4 from [http://qthaskell.berlios.de/]
Then I tried to build:
{{{
cabal install --extra-lib-dirs=c:/fp/QtSDK/mingw/lib --extra-lib-
dirs=c:/fp/QtSDK/mingw/include
Resolving dependencies...
Configuring qt-1.1.4...
cabal.exe: Missing dependencies on foreign libraries:
* Missing C libraries: qtc_core, qtc_gui, qtc_network, qtc_opengl,
qtc_tools,
qtc_script
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the -dev versions). If the
libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they
are.
cabal.exe: Error: some packages failed to install:
qt-1.1.4 failed during the configure step. The exception was:
ExitFailure 1
}}}
I gave it the `--extra-lib-dirs` flag so that it could find the Qt
installation. However this did not work. So I'm stuck on reproducing.
If you can give a sequence of commands to reproduce, I'll gladly execute
them!
Simon
PS: a verbose run of the same attempt is below
{{{
bash$ cd qtHaskell-1.1.4
bash$ cabal install -v --extra-lib-dirs=c:/fp/QtSDK/mingw/lib --extra-lib-
dirs=c:/fp/QtSDK/mingw/include
c:\fp\HP-2010.2.0.0\bin\ghc.exe --numeric-version
looking for package tool: ghc-pkg near compiler in c:\fp\HP-2010.2.0.0\bin
found package tool in c:\fp\HP-2010.2.0.0\bin\ghc-pkg.exe
c:\fp\HP-2010.2.0.0\bin\ghc-pkg.exe --version
c:\fp\HP-2010.2.0.0\bin\ghc.exe --supported-languages
Reading installed packages...
c:\fp\HP-2010.2.0.0\bin\ghc-pkg.exe dump --global
c:\fp\HP-2010.2.0.0\bin\ghc-pkg.exe dump --user
c:\fp\HP-2010.2.0.0\bin\ghc.exe --print-libdir
Reading available packages...
Resolving dependencies...
selecting qt-1.1.4 (hackage)
selecting haskell98-1.0.1.1 (installed or hackage) and discarding
haskell98-1.0, 1.0.1.0, 1.1.0.0 and 1.1.0.1
selecting random-1.0.0.2 (installed or hackage) and discarding
random-1.0.0.0,
1.0.0.1 and 1.0.0.3
selecting time-1.1.4 (installed or hackage) and discarding time-1.0,
1.1.2.0,
1.1.2.1, 1.1.2.2, 1.1.2.3, 1.1.2.4, 1.1.3, 1.2, 1.2.0.1, 1.2.0.2, 1.2.0.3,
1.2.0.4 and 1.2.0.5
selecting process-1.0.1.3 (installed or hackage) and discarding
directory-1.1.0.0, filepath-1.0, process-1.0.0.0, 1.0.1.1, 1.0.1.2,
1.0.1.4
and 1.0.1.5
selecting directory-1.0.1.1 (installed or hackage) and discarding
directory-1.0.0.0, 1.0.0.3, 1.0.1.0, 1.0.1.2 and filepath-1.2.0.0
selecting old-time-1.0.0.5 (installed or hackage) and discarding
old-time-1.0.0.0, 1.0.0.2, 1.0.0.3, 1.0.0.4 and 1.0.0.6
selecting old-locale-1.0.0.2 (installed or hackage) and discarding
old-locale-1.0.0.0 and 1.0.0.1
selecting filepath-1.1.0.4 (installed or hackage) and discarding
filepath-1.1.0.0, 1.1.0.1, 1.1.0.2 and 1.1.0.3
selecting Win32-2.2.0.2 (installed or hackage) and discarding Win32-2.1,
2.1.0.0, 2.2.0.0 and 2.2.0.1
selecting bytestring-0.9.1.7 (installed or hackage) and discarding
bytestring-0.9, 0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1,
0.9.1.2,
0.9.1.3, 0.9.1.4, 0.9.1.5, 0.9.1.6, 0.9.1.8, 0.9.1.9 and 0.9.1.10
selecting ghc-prim-0.2.0.0 (installed)
selecting ffi-1.0 (installed)
selecting rts-1.0 (installed)
selecting array-0.3.0.1 (installed or hackage) and discarding
array-0.1.0.0,
0.2.0.0, 0.3.0.0 and 0.3.0.2
selecting OpenGL-2.2.3.0 (installed or hackage) and discarding OpenGL-2.1,
2.2.1.1, 2.2.2.0, 2.3.0.0, 2.4.0.0 and 2.4.0.1
selecting base-3.0.3.2 (installed) and 4.2.0.2 (installed) and discarding
syb-0.1.0.0, 0.1.0.1, 0.1.0.2, 0.1.0.3, 0.2, 0.2.1, 0.2.2, 0.3, 0.3.1 and
0.3.2
selecting integer-gmp-0.2.0.1 (installed)
selecting syb-0.1.0.2 (installed)
In order, the following would be installed:
qt-1.1.4 (new package)
Configuring qt-1.1.4...
Dependency OpenGL ==2.2.3.0: using OpenGL-2.2.3.0
Dependency base ==3.0.3.2: using base-3.0.3.2
Dependency haskell98 ==1.0.1.1: using haskell98-1.0.1.1
Using Cabal-1.8.0.4 compiled by ghc-6.10
Using compiler: ghc-6.12.3
Using install prefix: C:\Users\simonpj\AppData\Roaming\cabal
Binaries installed in: C:\Users\simonpj\AppData\Roaming\cabal\bin
Libraries
Re: [GHC] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
---+
Reporter: ian.duncan |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler| Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86 | Failure: None/Unknown
---+
Old description:
I installed qtHaskell 1.1.4 by installing Qt 4.7.3 through brew.
I ran ./build --enable-shared for qtHaskell, which failed after compiling
and installing all of the C bindings. I then ran cabal install --disable-
library-for-ghci, per http://hackage.haskell.org/trac/hackage/ticket/791
.
I can successfully build, but I get the following warnings:
[1 of 1] Compiling Main ( Main.hs, dist/build/qtTest/qtTest-
tmp/Main.o )
/Users/ian/Library/Haskell/ghc-7.0.3/lib/qt-1.1.4/lib/Qtc/Gui/QWidget.hi
Declaration for $wa227
Unfolding of Qtc.Gui.QWidget.$wa227
Unfolding of eta:
Iface id out of scope: qtc_QWidget_setWindowTitle
/Users/ian/Library/Haskell/ghc-7.0.3/lib/qt-1.1.4/lib/Qtc/Gui/QLabel.hi
Declaration for $wa141
Unfolding of Qtc.Gui.QLabel.$wa141
Unfolding of eta:
Iface id out of scope: qtc_QLabel_setText
When I run the compiled program, labels do not show up properly, and I'm
pretty sure that it's due to these issues.
New description:
I installed qtHaskell 1.1.4 by installing Qt 4.7.3 through brew.
I ran ./build --enable-shared for qtHaskell, which failed after compiling
and installing all of the C bindings. I then ran cabal install --disable-
library-for-ghci, per http://hackage.haskell.org/trac/hackage/ticket/791 .
I can successfully build, but I get the following warnings:
{{{
[1 of 1] Compiling Main ( Main.hs, dist/build/qtTest/qtTest-
tmp/Main.o )
/Users/ian/Library/Haskell/ghc-7.0.3/lib/qt-1.1.4/lib/Qtc/Gui/QWidget.hi
Declaration for $wa227
Unfolding of Qtc.Gui.QWidget.$wa227
Unfolding of eta:
Iface id out of scope: qtc_QWidget_setWindowTitle
/Users/ian/Library/Haskell/ghc-7.0.3/lib/qt-1.1.4/lib/Qtc/Gui/QLabel.hi
Declaration for $wa141
Unfolding of Qtc.Gui.QLabel.$wa141
Unfolding of eta:
Iface id out of scope: qtc_QLabel_setText
}}}
When I run the compiled program, labels do not show up properly, and I'm
pretty sure that it's due to these issues.
--
Comment(by simonpj):
This is all very odd. Can you give from-scratch instructions for how to
reproduce your problem? I fell at the first fence
{{{
bash$ cabal update
Downloading the latest package list from hackage.haskell.org
simonpj@cam-04-unx:~/tmp$ cabal unpack qt-1.1.4
cabal: There is no package named 'qt'.
You may need to run 'cabal update' to get the latest list of available
packages.
}}}
Also I don't have MacOS -- which may mean I can't run your program, but I
hope I can still compile it.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399#comment:2
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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell ---+ Reporter: ian.duncan |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler| Version: 7.0.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86 | Failure: None/Unknown ---+ Changes (by ian.duncan): * version: 7.0.3 = 7.0.4 Comment: You'll need to have Qt installed, which you can find here: http://qt.nokia.com/products/platform/qt-for-windows/ You can find qtHaskell here: http://qthaskell.berlios.de/ In the qtHaskell-1.1.4 directory, I ran ./build and after building the necessary C libs, the build script errored out due to cabal not supporting the --make flag anymore for compiling Haskell code. According to the online qtHaskell documentation, at this point it was safe to run cabal install as an alternative, which I did, and which produced the issues mentioned above. If you can get qtHaskell to compile, there shouldn't be any reason why the attached program won't run for you. Also, I've since the initial bug report verified that the problem exists on both x86 x86_64 OS X platforms. I'm not sure about other systems. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399#comment:3 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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell ---+ Reporter: ian.duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.0.3 |Keywords: Testcase: | Blockedby: Os: MacOS X |Blocking: Architecture: x86 | Failure: None/Unknown ---+ I installed qtHaskell 1.1.4 by installing Qt 4.7.3 through brew. I ran ./build --enable-shared for qtHaskell, which failed after compiling and installing all of the C bindings. I then ran cabal install --disable- library-for-ghci, per http://hackage.haskell.org/trac/hackage/ticket/791 . I can successfully build, but I get the following warnings: [1 of 1] Compiling Main ( Main.hs, dist/build/qtTest/qtTest- tmp/Main.o ) /Users/ian/Library/Haskell/ghc-7.0.3/lib/qt-1.1.4/lib/Qtc/Gui/QWidget.hi Declaration for $wa227 Unfolding of Qtc.Gui.QWidget.$wa227 Unfolding of eta: Iface id out of scope: qtc_QWidget_setWindowTitle /Users/ian/Library/Haskell/ghc-7.0.3/lib/qt-1.1.4/lib/Qtc/Gui/QLabel.hi Declaration for $wa141 Unfolding of Qtc.Gui.QLabel.$wa141 Unfolding of eta: Iface id out of scope: qtc_QLabel_setText When I run the compiled program, labels do not show up properly, and I'm pretty sure that it's due to these issues. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399 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] #5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell
#5399: GHC 7.0.3 produces corrupt .hi files for qtHaskell ---+ Reporter: ian.duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.0.3 |Keywords: Testcase: | Blockedby: Os: MacOS X |Blocking: Architecture: x86 | Failure: None/Unknown ---+ Comment(by ian.duncan): Here are some relevant warnings (errors?) from building qtHaskell: [651 of 662] Compiling Qtc.Core.Attributes ( Qtc/Core/Attributes.hs, dist/build/Qtc/Core/Attributes.p_o ) The interface for `qt-1.1.4:Qtc.Gui.QAbstractButton' Declaration for $wa147 Unfolding of Qtc.Gui.QAbstractButton.$wa147 Unfolding of eta: Iface id out of scope: qtc_QAbstractButton_setText The interface for `qt-1.1.4:Qtc.Core.QSettings' Declaration for $wa45 Unfolding of Qtc.Core.QSettings.$wa45 Unfolding of eta: Iface id out of scope: qtc_QSettings_value [652 of 662] Compiling Qtc.Core ( Qtc/Core.hs, dist/build/Qtc/Core.p_o ) [653 of 662] Compiling Qtc.Tools.QUiLoader_h ( Qtc/Tools/QUiLoader_h.hs, dist/build/Qtc/Tools/QUiLoader_h.p_o ) [654 of 662] Compiling Qtc.Tools( Qtc/Tools.hs, dist/build/Qtc/Tools.p_o ) [655 of 662] Compiling Qth.Core.Line( Qth/Core/Line.hs, dist/build/Qth/Core/Line.p_o ) [656 of 662] Compiling Qth.Core ( Qth/Core.hs, dist/build/Qth/Core.p_o ) [657 of 662] Compiling Qt.Arthur.Style ( Qt/Arthur/Style.hs, dist/build/Qt/Arthur/Style.p_o ) The interface for `qt-1.1.4:Qtc.Gui.QFontMetrics' Declaration for $wa40 Unfolding of Qtc.Gui.QFontMetrics.$wa40 Unfolding of eta: Iface id out of scope: qtc_QFontMetrics_width1 [658 of 662] Compiling Qt.Arthur.Frame ( Qt/Arthur/Frame.hs, dist/build/Qt/Arthur/Frame.p_o ) The interface for `qt-1.1.4:Qtc.Core.Base' Declaration for $wa6 Unfolding of Qtc.Core.Base.$wa6 Unfolding of eta: Iface id out of scope: qtc_emitSignal_bool The interface for `qt-1.1.4:Qtc.Gui.QTextDocument' Declaration for $wa54 Unfolding of Qtc.Gui.QTextDocument.$wa54 Unfolding of eta: Iface id out of scope: qtc_QTextDocument_setHtml The interface for `qt-1.1.4:Qtc.Gui.QTextEdit' Declaration for $wa168 Unfolding of Qtc.Gui.QTextEdit.$wa168 Unfolding of eta: Iface id out of scope: qtc_QTextEdit_setHtml -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5399#comment:1 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
[Haskell-cafe] Mysterious complaint about .hi files
Hi cafe!
I'm hitting a very strange problem when using haskell-src-exts and
haskell-src-exts-qq. Consider the following module:
\begin{code}
{-# Language QuasiQuotes #-}
module TestBug where
import Language.Haskell.Exts
import Language.Haskell.Exts.QQ
unit = TyTuple Boxed []
ty = [dec| quux :: (a,b) |]
\end{code}
This module doesn't load for me using ghc 7.0.3. I've pasted the full error
message at the end of this email but the error message begins with the
following lines:
TestBug.hs:11:11:
Can't find interface-file declaration for variable
Language.Haskell.Exts.Syntax.Boxed
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
Using -ddump-if-trace didn't help me much.
The funny thing is that if I comment out the last line (the definition of
'ty') then the module loads just fine even though it uses the Boxed type in
the definition of 'unit'. So the problem only manifests itself when I use
tuples from haskell-src-exts-qq. Everything else that I've used from
haskell-src-exts-qq works fine, it's just when I try to use tuples that
things go haywire.
I've tried to remove the packages and reinstall them but it didn't help.
Any clues?
Josef
TestBug.hs:11:11:
Can't find interface-file declaration for variable
Language.Haskell.Exts.Syntax.Boxed
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
In the first argument of `Language.Haskell.Exts.Syntax.TyTuple', namely
`Language.Haskell.Exts.Syntax.Boxed'
In the third argument of `Language.Haskell.Exts.Syntax.TypeSig', namely
`Language.Haskell.Exts.Syntax.TyTuple
Language.Haskell.Exts.Syntax.Boxed
((:)
(Language.Haskell.Exts.Syntax.TyVar
(Language.Haskell.Exts.Syntax.Ident ((:) 'a' [])))
((:)
(Language.Haskell.Exts.Syntax.TyVar
(Language.Haskell.Exts.Syntax.Ident ((:) 'b' [])))
[]))'
In the expression:
Language.Haskell.Exts.Syntax.TypeSig
(SrcLoc
((:)
''
((:)
'u'
((:)
'n'
((:)
'k'
((:)
'n'
((:)
'o'
((:)
'w' ((:) 'n' ((:) '' ((:) '.' ((:) 'h' ((:)
's' []
1
2)
((:)
(Language.Haskell.Exts.Syntax.Ident
((:) 'q' ((:) 'u' ((:) 'u' ((:) 'x' [])
[])
(Language.Haskell.Exts.Syntax.TyTuple
Language.Haskell.Exts.Syntax.Boxed
((:)
(Language.Haskell.Exts.Syntax.TyVar
(Language.Haskell.Exts.Syntax.Ident ((:) 'a' [])))
((:)
(Language.Haskell.Exts.Syntax.TyVar
(Language.Haskell.Exts.Syntax.Ident ((:) 'b' [])))
[])))
Failed, modules loaded: none.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [GHC] #4453: Allow specifying .hi files of imports on command line in batch mode
#4453: Allow specifying .hi files of imports on command line in batch mode -+-- Reporter: duncan|Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.2.1 Component: Compiler | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * milestone: = 7.2.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4453#comment:1 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] #4453: Allow specifying .hi files of imports on command line in batch mode
#4453: Allow specifying .hi files of imports on command line in batch mode
-+--
Reporter: duncan| Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 6.12.3|Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
It is useful for a build agent (e.g. cabal, or makefile) to have full
control over the search path. Reasons you might want to do this are below.
The way a build agent can do this is to instruct ghc not to do any
searching at all, using the flag `-i` which sets the search path to empty.
Then the build agent has to supply ghc with all the `.hs` files that are
needed, e.g.:
{{{
ghc --make -i Foo.hs Bar.hs
}}}
(any imports outside of these modules, or the package modules will fail)
This no-search scheme works in `--make` mode but not in batch mode. For
that we need to be able to say:
{{{
ghc -i -c Foo.hs
ghc -i -c Bar.hs Foo.hi
}}}
That is, we need to be able to specify the .hi files of imported modules
on the command line.
A build agent may want to do this so that it is insulated from the
particular choices of ghc's search path semantics and/or have different
choices. For example, ghc prefers modules in local .hs/.hi files to
package modules while the build agent may want the reverse in some
circumstances.
Apart from search path policy, it makes sense for a build agent to take
this approach simply for correctness and simplicity. A correct build agent
must track dependencies absolutely precisely, so it has to know which
specific .hi files ghc will pick anyway. It is simpler for the build agent
to tell ghc those .hi files rather than trying to precisely arrange things
to match ghc's search behaviour.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4453
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] #3883: --show-iface hangs on certain .hi files
#3883: --show-iface hangs on certain .hi files
---+
Reporter: simonmar | Owner:
Type: bug | Status: closed
Priority: high | Milestone: 6.14.1
Component: Compiler |Version: 6.13
Resolution: fixed | Keywords:
Difficulty:| Os: Unknown/Multiple
Testcase:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Changes (by simonpj):
* status: new = closed
* resolution: = fixed
Comment:
Fixed by
{{{
Mon Mar 1 11:10:40 GMT 2010 simo...@microsoft.com
* Fix pretty-printing of IfaceAnyTc (fixes Trac #3883)
The panic message in ifaceTyConName on IfaceAnyTc
called the pretty-printer, called ifaceTyConName again,
which caused an infinite regress. Stupid.
See
* Note [The Name of an IfaceAnyTc], and
* The Outputable instance for IfaceTyCon
M ./compiler/iface/IfaceType.lhs -6 +10
}}}
Indeed, it's not an issue for the 6.12 branch
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3883#comment:1
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] #3883: --show-iface hangs on certain .hi files
#3883: --show-iface hangs on certain .hi files
-+--
Reporter: simonmar |Owner:
Type: bug | Status: new
Priority: high |Milestone: 6.14.1
Component: Compiler | Version: 6.13
Keywords:| Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
In a GHC build, try
{{{
inplace/bin/ghc-stage2 --show-iface array/dist-
install/build/Data/Array/Base.hi
}}}
This hangs for me, right after
{{{
b0318967c2f8fdf2005760546e36e780
$fIArrayUArrayBool_$cunsafeAccum :: forall i e'.
GHC.Arr.Ix i =
(GHC.Bool.Bool - e' -
GHC.Bool.Bool)
- Data.Array.Base.UArray i
GHC.Bool.Bool
- [(GHC.Types.Int, e')]
- Data.Array.Base.UArray i
GHC.Bool.Bool
{- Arity: 4, HasNoCafRefs, Strictness: ALU()L,
Inline: INLINE{3},^C
}}}
and the GHC process is uninteruptible, which suggests it has gone into an
infinite non-allocating loop.
Appears to be HEAD only.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3883
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: How MD are .hi files?
Matthias Kilian wrote: On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote: for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. The word size is probably the only dependency, but there are many reasons that you can't just take the .hc/.hi files generated by an unregisterised build on one machine and expect them to work on another machine. I really don't expect this. I just decided to be lazy and provide not only .hc files but also .hi files[1] for the OpenBSD port, and then I thought: does this make sense at all? Can it even be of use for porting GHC to other archs on OpenBSD, or for the NetBSD folks working on GHC? Here's a message I wrote quite a while ago on this topic: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-May/008456.html some of that is out of date, but at least it describes most of the issues with having a platform-independen hc bootstrap. [1] Of course, the correct solution would not need the .hi files, but just use the stage1 bootstrapped from .hc files to start rebuilding the libraries. But that would require even more hacking on the Makefiles, and I've already an insane amount of hacks sitting around. If the .hc files were platform independent, then the .hi files would be too, by definition. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How MD are .hi files?
Matthias Kilian wrote: Hi, for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. The word size is probably the only dependency, but there are many reasons that you can't just take the .hc/.hi files generated by an unregisterised build on one machine and expect them to work on another machine. First, you have to watch out for conditional compilation in the original Haskell source file. For example, if the .hs file contains something like #ifdef mingw32_HOST_OS, then the .hc and .hi files will both be Windows-only. There are certainly many instances of this in the libraries right now. Another problem is the configuration information that gets into the build via the autoconf scripts. Things like the size of C types in Foreign.C.Types, or the errno values in Foreign.C.Error might be different on the target machine. I hope I've managed to understand your question correctly... if not please ask again! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How MD are .hi files?
On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote: for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. The word size is probably the only dependency, but there are many reasons that you can't just take the .hc/.hi files generated by an unregisterised build on one machine and expect them to work on another machine. I really don't expect this. I just decided to be lazy and provide not only .hc files but also .hi files[1] for the OpenBSD port, and then I thought: does this make sense at all? Can it even be of use for porting GHC to other archs on OpenBSD, or for the NetBSD folks working on GHC? Ciao, Kili [1] Of course, the correct solution would not need the .hi files, but just use the stage1 bootstrapped from .hc files to start rebuilding the libraries. But that would require even more hacking on the Makefiles, and I've already an insane amount of hacks sitting around. -- It compiles -- let's ship it! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How MD are .hi files?
Hi, for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. TIA Ciao, Kili ps: if you think this sounds like a complete newbie question, you're right; I've been far too busy hacking on boring stuff like Makefiles, and didn't have time to look at the interesting code (i.e. ghc itself). My knowledge of ghc's internals is at the state of 1998, or even older, I really don't remember ;-) -- Options are good. As long as they are optional. -- Artur Grabowski ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Inconsistent .hi files with associated types?
Niklas, = $ runhaskell Setup build Preprocessing library hsp-hjscript-0.3.4... Building hsp-hjscript-0.3.4... [1 of 1] Compiling HSP.HJScript ( HSP/HJScript.hs, dist\build/HSP/HJScript.o ) C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi Declaration for $f35 Unfolding of HSP.Monad.$f35: Can't find interface-file declaration for type constructor or class HSP.Monad.:CoF:R32XML Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi Declaration for $f6 Unfolding of HSP.Monad.$f6: Can't find interface-file declaration for type constructor or class HSP.Monad.:CoF:R5SetResult Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error C:\Program\ghc-6.8.2\bin\ar.exe: creating dist\build\libHShsp- hjscript-0.3.4.a = Could you check whether the problem also occurs with the current GHC 6.9 (development version)? There has been at least on bug that may cause this sort of problem been fixed in 6.9, which may not have been merged back to 6.8. (Remember that we unfortunately cannot support type families (and hence associated types) fully in 6.8 - this has been discussed previously on this and/or the Haskell lists.) Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Inconsistent .hi files with associated types?
Hi all, I'm getting a weird warning/error message from GHC that I don't understand: = $ runhaskell Setup build Preprocessing library hsp-hjscript-0.3.4... Building hsp-hjscript-0.3.4... [1 of 1] Compiling HSP.HJScript ( HSP/HJScript.hs, dist\build/HSP/HJScript.o ) C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi Declaration for $f35 Unfolding of HSP.Monad.$f35: Can't find interface-file declaration for type constructor or class HSP.Monad.:CoF:R32XML Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi Declaration for $f6 Unfolding of HSP.Monad.$f6: Can't find interface-file declaration for type constructor or class HSP.Monad.:CoF:R5SetResult Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error C:\Program\ghc-6.8.2\bin\ar.exe: creating dist\build\libHShsp-hjscript-0.3.4.a = Can anyone explain to me what's up here? I have no .hi-boot files., and -ddump-if-trace gives no further info. Both XML and SetResult are associated types. Both of the instances in question are defined in a different package, which compiles without error. The classes that define the types are in yet another package, which also compiles without error. I note that the compilation of the package continues, so I suppose these are error messages only, even though they sound quite fatal. But what effect will this have on programs using the module? Cheers, /Niklas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #1745: i386 Linux bindist doesn't install .hi files for the ghc package
#1745: i386 Linux bindist doesn't install .hi files for the ghc package -+-- Reporter: igloo |Owner: igloo Type: bug | Status: closed Priority: normal|Milestone: 6.8.1 Component: Build System | Version: 6.8 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Fixed in 20071026. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1745#comment:2 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] #1745: i386 Linux bindist doesn't install .hi files for the ghc package
#1745: i386 Linux bindist doesn't install .hi files for the ghc package -+-- Reporter: igloo |Owner: igloo Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Build System | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1745#comment:1 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] #1745: i386 Linux bindist doesn't install .hi files for the ghc package
#1745: i386 Linux bindist doesn't install .hi files for the ghc package ---+ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.8.1 Component: Build System |Version: 6.8 Severity: normal| Keywords: Difficulty: Unknown | Os: Unknown Testcase:| Architecture: Unknown ---+ The i386 Linux bindist doesn't install .hi files for the ghc package. I haven't tracked down exactly what's going on, but my first impression is that the value of INSTALL_IFACES isn't being set early enough. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1745 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: ghci confused by hi files
I wrote: I have observed the following weird behavior: ...ghci's ability to recognize the methods of the class seems to vary depending on whether or not hi files exist for the modules. Daniel Fischer wrote: Pertinent to this is section 3.4.3 of the user's guide, What's really in scope at the prompt. For compiled modules, only the exports of these are in scope. So this is documented behaviour. OK, thanks, I see that now. But I would have only expected that to apply to modules that are _only_ compiled. If the source code is also available, why should I be penalized for compiling it? Preferring the source code over the compiled code by default would be much more convenient for iterative debugging. But if that cannot be the default, it would be nice if it were at least an option. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci confused by hi files
I have observed the following weird behavior:
When I define an instance of a certain MPTC
in a separate module from the definition of
the class, ghci's ability to recognize the
methods of the class seems to vary depending
on whether or not hi files exist for the modules.
I am using the current Debian build of GHC 6.6.
Below are a set of three files that reproduce the
behavior, and a shell session that demonstrates
it.
Before I compile the program, ghci works fine.
After I compile with ghc - thus generating hi files -
ghci gets confused. Then I delete the hi files
and everything is fine again.
Thanks,
Yitz
-- File Oops.hs
{-# OPTIONS_GHC -fglasgow-exts #-}
module Oops where
class Oops a b c | a - b c where
foo :: a - b - a
-- File Whoops.hs
{-# OPTIONS_GHC -fglasgow-exts #-}
module Whoops where
import Oops
instance Oops String Int Bool where
foo x n = show (x, n)
-- File runWhoops.hs
module Main where
import Whoops
import Oops
main = putStrLn $ foo bar 42
$ ghci Whoops
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
Loading package base ... linking ... done.
[1 of 2] Compiling Oops ( Oops.hs, interpreted )
[2 of 2] Compiling Whoops ( Whoops.hs, interpreted )
Ok, modules loaded: Oops, Whoops.
*Whoops foo baz 7
(\baz\,7)
*Whoops Leaving GHCi.
$ ghc --make runWhoops.hs
[1 of 3] Compiling Oops ( Oops.hs, Oops.o )
[2 of 3] Compiling Whoops ( Whoops.hs, Whoops.o )
[3 of 3] Compiling Main ( runWhoops.hs, runWhoops.o )
Linking runWhoops ...
$ ghci Whoops
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
Loading package base ... linking ... done.
Ok, modules loaded: Oops, Whoops.
Prelude Whoops foo baz 7
interactive:1:0: Not in scope: `foo'
Prelude Whoops Leaving GHCi.
$ rm *.hi
$ ghci Whoops
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
Loading package base ... linking ... done.
[1 of 2] Compiling Oops ( Oops.hs, interpreted )
[2 of 2] Compiling Whoops ( Whoops.hs, interpreted )
Ok, modules loaded: Oops, Whoops.
*Whoops foo baz 7
(\baz\,7)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
reading imports from .hi files?
Hello Duncan, Monday, October 9, 2006, 9:52:34 PM, you wrote: A simple script for the pgmF command May it be that import chasing takes longer now? I noticed quite a gap before ghc started to compile my 624 modules. Yes, since it has to run the pre-processor before it can look at the imports. isn't it possible to check that source files was not changed and look up imports from .hi files in this case? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
.hi files
Hi all, Can any one tell me what is the use of .hi (interface) files. I want to know the steps involved in the compilation of a .hs file. I went thru the what nhc98 roughly does and saw that it generates interface file for each module. Please enlighten as to what is the precise function of interface files. Regards, -- Arun Kumar S Jadhav Masters Student, SIC-309, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk * Never negotiate out of fear Never fear to negotiate * ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: FFI, -O .hi files
Simon Peyton-Jones wrote: [...] a) to make the worker a NOINLINE thing, so it never got inlined anywhere b) allow it to be inlined freely in its own module, but then not export the inlining of any function that now has an embedded ccall. It's a little bit hard to decide between a) and b), because it will probably depend on the actual code which one is the better solution. I'm leaning towards a), but this more a feeling than anything else. Anyway, this is only the second best choice IMHO. c) leave it as it is Bad! d) make it command-line-flag controllable But GHC has too many command line flags already. [...] Granted, but we already have a very suitable one (SimonM, Sigbjorn, don't read any further! ;-) : -funfold-casms-in-hi-file Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
RE: FFI, -O .hi files
| I am not sure whether that issues was discussed already, but | I just noticed that when a module containing foreign import | declarations is compiled with -O, it may bring some of its | `__ccall's into the .hi file for inlining purposes. | The problem is that the `ccall'ed C function | `gtk_adjustment_set_value' will now end up in whatever file | I import the above .hi, and thus, gives these nice | | /tmp/ghc30063.hc:147: warning: implicit declaration of | function `gtk_adjustment_set_value' | | messages. It is unreasonable to assume that every client | module of - in this case - the GTK+ Haskell binding will | slurp in the complete GTK+ C header. 'foreign imports' are already split into a wrapper, and a worker that contains only the ccall itself. It would not be difficult a) to make the worker a NOINLINE thing, so it never got inlined anywhere b) allow it to be inlined freely in its own module, but then not export the inlining of any function that now has an embedded ccall. c) leave it as it is d) make it command-line-flag controllable But GHC has too many command line flags already. I'm quite unsure what the 'right' solution is; there is no technical difficulty I think. Simon
FFI, -O .hi files
I am not sure whether that issues was discussed already, but
I just noticed that when a module containing foreign import
declarations is compiled with -O, it may bring some of its
`__ccall's into the .hi file for inlining purposes. As, for
example, in the following excerpt of one of my .hi files:
3 zdwgtkAdjustmentSetValue :: __forall [adj] = (adj - GtkAdjustment) - adj -
PrelFloat.Float - PrelIOBase.IO PrelBase.Z0T {-## __A 4 __C __S S __U (\ @ adj ww ::
(adj - GtkAdjustment) adj1 :: adj value :: PrelFloat.Float - __coerce (PrelIOBase.IO
PrelBase.Z0T) (\ ds :: (PrelGHC.Statezh PrelGHC.RealWorld) - case __coerce
PrelAddr.Addr (ww adj1) of ds1 { PrelAddr.Azh ds2 - case value of ds3 {
PrelFloat.Fzh ds4 - case __ccall gtk_adjustment_set_value {@ (PrelGHC.Statezh
PrelGHC.RealWorld - PrelGHC.Addrzh - PrelGHC.Floatzh - (# PrelGHC.Statezh
PrelGHC.RealWorld #)) ds ds2 ds4} of wild { (# ds5 #) - (# ds5, PrelBase.Z0T #) } }
})) ##-} ;
The problem is that the `ccall'ed C function
`gtk_adjustment_set_value' will now end up in whatever file
I import the above .hi, and thus, gives these nice
/tmp/ghc30063.hc:147: warning: implicit declaration of function
`gtk_adjustment_set_value'
messages. It is unreasonable to assume that every client
module of - in this case - the GTK+ Haskell binding will
slurp in the complete GTK+ C header.
On the other hand, it is of course very nice that small
wrappers around FFI calls are inlined. It seems that the
best solution would be to inline every but the actual
ccall...
I am currently using the vanilla 4.06 for this.
Manuel
RE: Latest version of GHC can't read it's own .hi files!
A build of GHC downloaded from the anoncvs repository last night and running on Sparc-Solaris produced the following messages. I attach a copy of PrelNumExtra.hi. This one was fixed a couple of days ago. Maybe something is out of date? Cheers, Simon
RE: Mutually Recursive Modules and hi files
OK wise guys, now you've changed (incompatibly) the format of .hi files, how can I rewrite these pre-404 hi-boot files so that they work for 404? Can you summarise the changes? The main change recently was to remove the use of '!' instead of '.' to indicate that a particular identifier should be snaffled from anohter .hi-boot file instead of an .hi file. The compiler now figures this out for itself. So, just change any plings to dots and you should be ok. BTW, there's an "interface file version number" which is currently at 5. You can make your .hi-boot files version specific by calling them .hi-boot-5 or whatever. We use this trick in the compiler so we can stay compatible with ghc 3.02. Cheers, Simon
Mutually Recursive Modules and hi files
OK wise guys, now you've changed (incompatibly) the format of .hi files, how can I rewrite these pre-404 hi-boot files so that they work for 404? Can you summarise the changes?
Re: Speeding up .hi files
Sven Panne wrote:
[ cut ]
Doing a similar thing for GHC would complicate things for implementors
and users. How e.g. would you write your Makefile rules with .hi files
in an archive?
Yes, it would complicate things for implementors, as they'd have to implement
it. However I don't think adding a rule
interfaces.a : $(HS_IFACES)
$(AR) -c $ $
to the standard GHC makefiles, and altering the targets to include
lib/{prelude,std,misc,exts,...}/interfaces.a
would be incredibly onerous for the poor implementors. The poor
old users would not have to do anything to their Makefiles since the old
mechanism would still be available. (Though of course GHC would run
considerably faster for them since it wouldn't have to load in everything in
the standard libraries.) However as a GHC user already I would be
delighted with the new mechanism myself and make use of it to speed up
my compilations, by adding similar rules to the one suggested above. It's
no more complicated than what I already do to construct libraries, and
I would save a lot of time.
Speeding up .hi files
Glasgow Haskell is very slow. I know it needs a lot of CPU time anyway, but when I do ps it is only using 50% of the CPU available, and frequently less. So I think what is happening is that it is spending half of its time waiting for the Network Filing System to open and fstat interface files. I think there is a better way, namely to allow interface files to be stored in archives rather than in directories. There are other solutions. I can store the hi files, or everything, on local disk, but this is tiresome for me, and I shall still spend quite a lot of time reading things off local disk. Or GHC could use either the select function or threading so that it can do other things while waiting for the result of a file operation on an interface file; however I suspect this would be complicated to implement and might not save all that much time. There was a similar situation in my experience with the ML-to-Java compiler; the earlier versions could not read or write ZIP (aka jar) archives, so all classes read in (from the system libraries) and all classes written out (compiled code) were put in their own file. I was persuaded to write a simple Zip file writer in ML and while the bit twiddling was a bit of a chore, it didn't actually take me much more than a day's work to do it, as a result of which the compiler ran about twice as quickly as before. (Later I wrote a simple Zip file reader - which was just as easy - and when the SML/NJ folks get their new foreign function interface sorted out I might do compression/decompression as well, with the help of zlib.)
More problems with .hi files
Well I've updated GHC yet again to solve the last problem, but it's
made things even worse, because GHC has now forgotten an instance
declaration which it remembered before.
Specifically file Interaction.hs contains the line:
instance Event IA where
(etc)
Interaction.hi contains the line:
instance {Event.Event ExternalEvent.IA} = zdfEventIA;
Sensor.hs contains the line
import Interaction
(This wasn't necessary before but I put it in to see if it
made any difference.)
However GHC produces the error message:
Sensor.hs:48:
No instance for `Event IA'
arising from use of `inaction' at Sensor.hs:48
So what has changed in the last few weeks that might cause this?
(I'd like to be more precise than "last few weeks" but
I don't know how to get a single global version number from
the CVS repository.)
Re: _casm_ in .hi-files
Sven Panne [EMAIL PROTECTED] writes: If I understand this correctly, definitions containing _casm_ are *not* emitted to .hi files anymore. Although the reason for doing this, concerning the inclusion of C's .h files, is fairly clear, I strongly urge GHC's implementors to revise this: Libraries containing a large collection of small definitions with _casm_s in it can't be unfolded in the library user's code. This case is not uncommon if the library was written with Green Card. It's not all that bad: _ccall_s are still ok. The cases where _casm_ (as opposed to _ccall_) is really necessary are few. We'll be introducing a new 'primitive' declaration for use with H/Direct which will hopefully remove the need for _casm_ in H/Direct output. An example from beloved spare time project, a Haskell binding for OpenGL: (^^^ Shameless plug! Finished "real soon" :-) The following Haskell callback (a snippet from a Haskell version of texturesurf.c from the Red Book) - display = do clear [ColorBuffer] color3i (1, 1, 1) evalMesh2 Mesh2ModeFill 0 20 0 20 flush - compiles on iX86 platforms essentially to the following assembler code: - pushl $16384 call glClear addl $4,%esp pushl $1 pushl $1 pushl $1 call glColor3i addl $12,%esp pushl $20 pushl $0 pushl $20 pushl $0 pushl $6914 call glEvalMesh2 addl $20,%esp call glFlush - I *love* it :) This is something to show your best friends! :-) gcc -O generates exactly the same code for a similar C function (if it isn't allowed to defer the stack pops, i.e. addls). There's a very boring reason why we don't let gcc defer pops, and it's due to having to mangle away the prologue/epilogue code. If _casm_s are not emitted to interface files, things will be much worse. Aren't these _ccall_s, not _casm_s? As Simon points out, we'd really like this code to be compilable by the native code generator and possibly C-- at some point, so _casm_s are ill-conceived and non-portable anyway. While looking at the code generated by gcc-2.7.2.1 on iX86 platforms, I was slightly puzzled by the way gcc pushes floats on the stack. ... One should expect that the code generated for test1-3 is identical and test4/5 are similar. But strangely enough, it isn't the case: (gcc -O -fomit-frame-pointer -S, some assembler directives omitted) ... Why is test2 handled differently? Can some gcc-guru out there explain this? To me it seems as if gcc is trying to be a little bit too clever about CSE, happily recycling the 1.0 two times in the second case and thereby generating inferior code. I've even seen differences in this area between the code produced by gcc on Linux and gcc on FreeBSD, supposedly the same gcc version. Extremely bizarre. Your point about using 'const' for ccall args is well-taken - I'll look into it. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: _casm_ in .hi-files
Simon L Peyton Jones wrote: Hmm. The difficulty is that things don't work well when you are using a native code generator, or using something entirely different like C-- (see my home page) as a code generator. OK, but if you are using _casm_, you must go via C anyway. And even in the C-- case ghc could output some C-- stub code to interface with the C part (or do something equivalent). I expect the latter to generate much better code than C in due course. So interspersing little fragments of real live C has to go. Just out of curiosity: Is C-- the designated target language for GHC in the future? I don't have a good answer to how to recover that nice inline performance, except by having bigger chunks of C rather than tiny little snippets. Alas, that's not the way to go for Haskell bindings of APIs. casm carries fairly high costs, more than I'd originally bargained for. But gcc does a really good job of throwing away useless code for saving/restoring the machine state between consecutive _casm_s, see the code in my last mail. Admittedly, the cost for a *single* _casm_ is quite high. Simon Marlow wrote: [...] There's a very boring reason why we don't let gcc defer pops, and it's due to having to mangle away the prologue/epilogue code. I guessed that, but that's the price to pay for the mangling hack... uuhhh: "technology"! ;-) Aren't these _ccall_s, not _casm_s? As Simon points out, we'd really like this code to be compilable by the native code generator and possibly C-- at some point, so _casm_s are ill-conceived and non-portable anyway. Hmmm, it's no *me* writing ill-conceived and non-portable code, it's Green Card, so blame Sigbjorn! :-)Sigh, it seems as if H/Direct is the future and Green Card will die a slow death... I wanted to avoid things like OSF DCE IDL or the OMG IIOP CORBA variant of IDL (IDRKWIAWH = I don't really know what I am writing here... just cut and paste from the H/Direct home page :-) as long as possible, but I fear it can't be helped anymore. At a first glance, the .idl files in the H/Direct distribution look a little bit daunting, but at least it is a standard. Any URLs to *short* introductions to COM/CORBA are highly appreciated. Micro$ofts site was already suggested, but it is nearly unbrowsable here due to a slow connection and server-side errors from some Visual-XY-created .asp-pages. To summarize: Personally, I really don't want to intersperse Haskell with C, I just wanted to point out a unfortunate interaction between a tool and a compiler. -- Sven "Performance Junkie" Panne:-)Tel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
_casm_ in .hi-files
Strictly speaking, this is not a bug, but I expect it to be a major
performance hit for some applications: In a moment of curiosity, I
browsed through the diffs between ghc-3.02 and ghc-proto-3.03-7-Jul,
finding amongst other things a new function okToUnfoldInHiFile. If I
understand this correctly, definitions containing _casm_ are *not*
emitted to .hi files anymore. Although the reason for doing this,
concerning the inclusion of C's .h files, is fairly clear, I strongly
urge GHC's implementors to revise this: Libraries containing a large
collection of small definitions with _casm_s in it can't be unfolded
in the library user's code. This case is not uncommon if the library
was written with Green Card.
An example from beloved spare time project, a Haskell binding for OpenGL:
(^^^ Shameless plug! Finished "real soon" :-)
The following Haskell callback (a snippet from a Haskell version of
texturesurf.c from the Red Book)
-
display = do
clear [ColorBuffer]
color3i (1, 1, 1)
evalMesh2 Mesh2ModeFill 0 20 0 20
flush
-
compiles on iX86 platforms essentially to the following assembler code:
-
pushl $16384
call glClear
addl $4,%esp
pushl $1
pushl $1
pushl $1
call glColor3i
addl $12,%esp
pushl $20
pushl $0
pushl $20
pushl $0
pushl $6914
call glEvalMesh2
addl $20,%esp
call glFlush
-
This is something to show your best friends! :-) gcc -O generates
exactly the same code for a similar C function (if it isn't allowed to
defer the stack pops, i.e. addls). If _casm_s are not emitted to
interface files, things will be much worse.
Keeping track of the included .h files in the .hi files would probably
be the right thing, but in the meanwhile I could live with a simple
compiler flag to disable this new "feature".
[ GHC specific stuff ends here, bit fiddling begins... ]
While looking at the code generated by gcc-2.7.2.1 on iX86 platforms,
I was slightly puzzled by the way gcc pushes floats on the stack.
Example:
-
#include GL/glut.h
void test1() {
glColor3f(1.0, 1.0, 1.0);
}
void test2() {
float x = 1.0, y = 1.0, z = 1.0;
glColor3f(x,y,z);
}
void test3() {
const float x = 1.0, y = 1.0, z = 1.0;
glColor3f(x,y,z);
}
void test4() {
float x = 0.1, y = 0.2, z = 0.3;
glColor3f(x,y,z);
}
void test5() {
int x = 1, y = 1, z = 1;
glColor3i(x,y,z);
}
-
One should expect that the code generated for test1-3 is identical
and test4/5 are similar. But strangely enough, it isn't the case:
(gcc -O -fomit-frame-pointer -S, some assembler directives omitted)
-
test1:
pushl $0x3f80
pushl $0x3f80
pushl $0x3f80
call glColor3f
addl $12,%esp
ret
test2:
fld1
subl $4,%esp
fsts (%esp)
subl $4,%esp
fsts (%esp)
subl $4,%esp
fstps (%esp)
call glColor3f
addl $12,%esp
ret
test3:
pushl $0x3f80
pushl $0x3f80
pushl $0x3f80
call glColor3f
addl $12,%esp
ret
test4:
pushl $0x3e9a
pushl $0x3e4d
pushl $0x3dcd
call glColor3f
addl $12,%esp
ret
test5:
pushl $1
pushl $1
pushl $1
call glColor3i
addl $12,%esp
ret
-
Why is test2 handled differently? Can some gcc-guru out there explain
this? To me it seems as if gcc is trying to be a little bit too clever
about CSE, happily recycling the 1.0 two times in the second case and
thereby generating inferior code.
Code like test2 is generated by ghc for _casm_s (perhaps ghc should
output some const modifiers before _ccall_args_?).
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: porting .hi files
Re: Sergey Mechveliani's letter (on .hi-files) the name "interface file" is slightly misleading. unlike .h-files, these files shouldn't be counted as belonging "to the program source", rather they are something that the compiler uses (and generates), much like an object file. the user really should think in terms of "package declaration / package implementation" which (unfortunately) are both in the .hs file. (on cyclic dependencies) sorry, this is a no-answer as well, but: who needs them? in the few cases where i had a cyclic dependency, and i wanted to avoid it (because hugs wouldn't handle it), i re-thought the placement of identifiers and the programm looked generally better afterwards. are there typical cases where cyclic module dependencies are the "natural" solution? best regards, -- Johannes Waldmann Institut fur Informatik FSU D-07740 Jena Germany http://www5.informatik.uni-jena.de/~joe/ mailto:[EMAIL PROTECTED]
