Re: [Haskell] [ANNOUNCE] GHC 9.2.4 released
Hi, > On a Mac it is still necessary to do > > xattr -rc . > > before doing > > sudo make install For 9.2.4, "xattr -rc ." is not good enough on my Mac (upgraded to v12.5 today). "sudo spctl --global-disable" is necessary, sigh. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
Hi George, > I've duplicated the issue on both of my machines. It would be good to know > if anybody else is seeing it. Kazu, I know you have seen this in the past. > Do you get the same error installing rc1? > When I run sudo make install I get a popup that says: I had no problem on 9.4.1-rc1. "xattr -rc ." and "make install" worked perfectly. macOS Monterey v12.4 Xcode 13.4.1 --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.2.2 is not available
Hi George, FYI: https://twitter.com/kazu_yamamoto/status/1500643489985761282 --Kazu > Thanks Ben > > When I do an install on macos Monterey 12.2.1 (Intel) I get > > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified > > > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari wrote: > >> >> The GHC developers are very happy to at announce the availability of GHC >> >> 9.2.2. Binary distributions, source distributions, and documentation are >> >> available at downloads.haskell.org: >> >>https://downloads.haskell.org/ghc/9.2.2 >> >> This release includes many bug-fixes and other improvements to 9.2.1 >> including: >> >> * A number of bug-fixes in the new AArch64 native code generator >> >> * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is >> handled >>correctly on platforms lacking support for unaligned memory accesses >>(#21015, #20987). >> >> * Improvements to the compatibility story in GHC's migration to the >>XDG Base Directory Specification (#20684, #20669, #20660) >> >> * Restored compatibility with Windows 7 >> >> * A new `-fcompact-unwind` flag, improving compatibility with C++ >> libraries on >>Apple Darwin (#11829) >> >> * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime >> bounds >>checking of array primops (#20769) >> >> * Unboxing of unlifted types (#20663) >> >> * Numerous improvements in compiler performance. >> >> * Many, many others. See the [release notes] for a full list. >> >> As some of the fixed issues do affect correctness users are encouraged to >> >> upgrade promptly. >> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous >> contributors whose on-going financial and in-kind support has >> facilitated GHC maintenance and release management over the years. >> Moreover, this release would not have been possible without the hundreds >> >> of open-source contributors whose work comprise this release. >> >> As always, do open a [ticket][] if you see anything amiss. >> >> Happy compiling, >> >> - Ben >> >> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [release notes]: >> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 8.6.1 released
Hi Evan, >> Has anyone installed the OS X binary distribution? I get: >> >> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy >> libraries/ghc-prim dist-install "strip" '' '/usr/local' >> '/usr/local/lib/ghc-8.6.1' >> '/usr/local/share/doc/ghc-8.6.1/html/libraries' 'v p dyn' >> dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib >> Referenced from: >> /usr/local/src/hs/ghc-8.6.1/libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.1.dylib >> Reason: image not found > > I met the same problem. See https://ghc.haskell.org/trac/ghc/ticket/15769 for workaround. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 8.6.1 released
Hi Evan, > Has anyone installed the OS X binary distribution? I get: > > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy > libraries/ghc-prim dist-install "strip" '' '/usr/local' > '/usr/local/lib/ghc-8.6.1' > '/usr/local/share/doc/ghc-8.6.1/html/libraries' 'v p dyn' > dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib > Referenced from: > /usr/local/src/hs/ghc-8.6.1/libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.1.dylib > Reason: image not found I met the same problem. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1
Hi, If I understand correctly, OverloadedRecordFields has not been merged yet. Are there any chances to merge it into GHC 7.10.1? --Kazu We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ This includes the source tarball and bindists for 64bit/32bit Linux and Windows. Binary builds for other platforms will be available shortly. (CentOS 6.5 binaries are not available at this time like they were for 7.8.x). These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 release sometime in February of 2015. We expect another RC to occur during January of 2015. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1
No, it is a big change and the merge window is closed now. This question was just asked on reddit: http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/ Greg, thank you for this info. But it is really disappointing. I was silent about this because it is promised that ORF is included in GHC 7.10. If I knew that active feedback was necessary, I could be vocal. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8.3 release
Hi Austin, I ask this because my time to dedicate to GHC is a bit thin right now, so you must help me decide what's important! So please let me know - just a general vote in favor of doing it within some X timeframe (even 'real soon' or 'a week would be great') would be nice. Would you give a look at: http://www.haskell.org/pipermail/ghc-devs/2014-May/004990.html http://www.haskell.org/pipermail/ghc-devs/2014-May/004993.html yesod-bin cannot be compiled with the coming GHC 7.8.3 yet. I believe regression was introduced. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] [Haskell] ANNOUNCE: GHC version 7.8.1
* Massive scalability improvements to the I/O manager Just a brief note from the front lines - I recompiled a heavily threaded program with (a recent pre-release) of 7.8.1 and got a 10% performance increase over 7.6.3. Nothing like free lunches - so thanks again for the great work! Did you run you program on a multicore system? If so, did you specify +RTS -Nx option? If your program uses MVar heavily, you need to re-design your program. For more information, please read: http://www.yesodweb.com/blog/2014/01/new-fast-logger --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New GHC Features for 7.10.1 and Beyond
Hi Gershom, We've also seen a lot of interest in distribution and cloud computing. From the articles I've read, efficient concurrent programming involves using node.js, so I think we should put some work into writing a new-new-new-IO Manager built on top of this technology. As a member of Mio developers, I don't understand this sentence. Would you concretely explain what kind of node.js technologies should be taken into new-new-new-IO Manager? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
desugarModule
Hi,
The document of GHC API says that desugarModule displays warnings of
pattern matching even if HscNothing is specified:
http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:HscTarget
Unfortunately, I cannot get warnings of pattern matching. To
demonstrate this, I attached two files:
- Main.hs -- using desugarModule
- B.hs-- a target file: top level signature is missing,
pattern is imcompleted
When I run Main.hs with:
% runghc -- -package --ghc-arg=ghc -Wall Main
I only got:
B.hs:6:1: Warning:
Top-level binding with no type signature: main :: IO ()
Does anyone know how to display warnings of pattern matching with
HscNothing?
--Kazu
Main
-- runghc -- -package --ghc-arg=ghc A
module Main where
import GHC
import GHC.Paths (libdir)
import DynFlags
main :: IO ()
main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ runGhc (Just
libdir) $ getWarings B.hs B
getWarings :: String - String - Ghc ()
getWarings targetFile targetModule = do
dflags - getSessionDynFlags
let dflags' = dflags {
ghcLink = NoLink
, hscTarget = HscNothing
}
dflags'' = foldl wopt_set dflags'
[Opt_WarnMissingSigs,Opt_WarnIncompletePatterns]
_ - setSessionDynFlags dflags''
target - guessTarget targetFile Nothing
setTargets [target]
_ - load LoadAllTargets
modSum - getModSummary $ mkModuleName targetModule
p - parseModule modSum
t - typecheckModule p
_ - desugarModule t
return ()
/Main
B
module B where
myHead :: [Int] - Int
myHead (x:_) = x
main = do
print $ myHead [1,2,3]
/B
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
Hi, Now I understand what is right and why I misunderstood. - GHC 7.8 provides three kinds of libraries: - static libraries - dynamic libraries - static libraries for profiling - GHCi uses dynamic libraries. - Programs complied with GHC 7.8 use static libraries. - When a library package is complied, both static one and dynamic one are created. - When -p or --enabling-executable-profiling are specified to cabal, static libraries for profiling are also created and used. So, we don't have to specify --enable-shared/--disable-shared to cabal in normal situation. There is no bug. Just I misunderstood. * Why did I misunderstand that programs are linked dynamically? I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally. At the beginning, doctest cannot pass many tests if --enable-shared is not specified. This was fixed: https://github.com/sol/doctest-haskell/issues/58 Now, --enable-shared is not necessary even for doctest. * Why did I misunderstand that compiling programs for profiling fails? I specified --ghc-options=-prof -fprof-auto. -prof lets GHC 7.8 to produce both static and dynamic libraries for profiling. This resulted in build failure. Right procedure for profiling are: % cabal install -p --enable-executable-profiling --ghc-options=-fprof-auto -j3 or % cabal install -p --ghc-options=-fprof-auto --only-dependencies -j3 % cabal configure --enable-executable-profiling % cabal build --Kazu On 09/09/13 08:14, Edward Z. Yang wrote: Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 19:36:19 -0700 2013: % make show VALUE=GhcLibWays make -r --no-print-directory -f ghc.mk show GhcLibWays=v p dyn Yes, it looks like you are missing p_dyn from this list. I think this is a bug in the build system. When I look at ghc.mk it only verifies that the p way is present, not p_dyn; and I don't see any knobs which turn on p_dyn. However, I must admit to being a little confused; didn't we abandon dynamic by default and switch to only using dynamic for GHCi (in which case the profiling libraries ought not to matter)? I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
Hi, Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug? I'm not completely sure yet. GHCi 7.8 uses dynamic linking. This is true. So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they supposed to use dynamic linking? Or, static linking? If dynamic linking is used, GHC should provide dynamic libraries for profiling. If static linking is used, cabal-install should stop using dynamic libraries for profiling. And of course, I can make a ticket when I'm convinced. P.S. Since doctest uses GHCi internally, I might misunderstand GHC 7.8 uses dynamic linking. Anyway, I don't understand what is right yet. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
Hi Austin, I would like to ask about profiling and dynamic linking. If I understand correctly, GHC 7.8 with cabal-install 1.18.x.x uses dynamic linking by default (except on FreeBSD). But GHC 7.8 provides a profile library only for static linking. An example is the base library: libHSbase-4.7.0.0.a libHSbase-4.7.0.0-ghc7.7.20130907.so* libHSbase-4.7.0.0_p.a Profile libraries for dynamic linking are not provided. So, I got troubles when I tried to take profile of my programs. I need to specify --disable-shared explicitly to cabal-install. (This sometime fails if Build-Type: is Custom.) Is this intentional? Are there any technical reasons to not provide dynamic profile libraries? --Kazu Friends, After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow. Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing. Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch. However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything: * Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here? * Trevor and Iavor are also working on kinds without data. Any word here? * Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great. * Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so. * Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great. * Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week. * I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams. IMO, most of these look to be in good shape, I think. If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week. In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular. Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
Austin, Dynamic should be available with anything, including profiling. This is probably more an artifact of your mk/build.mk setup. My mk/build.mk contains just one line: InstallExtraPackages = YES If you have a build tree, you can do: $ make show VALUE=GhcLibWays which should print out a string containing the enabled Ways. It printed: % make show VALUE=GhcLibWays make -r --no-print-directory -f ghc.mk show GhcLibWays=v p dyn This does not install dynamic libraries for profiling in my environment. What's are missing? And why aren't they set by default? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
runghc -fdefer-type-errors
Hello, Doesn't runghc support the -fdefer-type-errors option? Consider this code: module Main where main :: IO () main = do -- putStrLn は文字列を取る putStrLn Hello, world! putStrLn 1 -- 型エラー If I use runghc with -fdefer-type-errors, Hello, world! is not printed. Is this a bug? If this behavior is intended, I would like to change it. If GHC can run code like dynamically typed languages, it would be appealing to new Haskell programmers from their community. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: runghc -fdefer-type-errors
Hi, When I ran this code (ghc 7.6.1), I did get the Hello, world! printout. That line was sandwiched between the compile-time warning from the type error and the run-time exception from the type error, but the output was there: Thank you for letting me know this. I'm also using GHC 7.6.1. I should try to find why the incorrect behavior happens in my environment. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: runghc -fdefer-type-errors
When I ran this code (ghc 7.6.1), I did get the Hello, world! printout. That line was sandwiched between the compile-time warning from the type error and the run-time exception from the type error, but the output was there: Thank you for letting me know this. I'm also using GHC 7.6.1. I should try to find why the incorrect behavior happens in my environment. I noticed that -- is necessary. runghc -- -fdefer-type-errors Main.hs --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Validate of GHC HEAD freezes on FreeBSD
Could you please file a ticket about this as well? I registered this a while ago. http://hackage.haskell.org/trac/ghc/ticket/7652 --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
Hi Ian, Please test as much as possible; bugs are much cheaper if we find them before the release! A good news is that GHC 7.6.2 can be compiled on FreeBSD 9.1. But this problem exists: http://hackage.haskell.org/trac/ghc/ticket/7592 Typing gmake -j10 again completes the building. A bad new is that test is not completed. - Compiling T5001 uses CPU 100% - signals004 is waiting for something forever Killing these two processes completes tests. The result is as follows: Unexpected failures: ../../libraries/base/tests/Concurrent Chan002 [bad exit code] (normal) ../../libraries/directory/testsgetPermissions001 [bad exit code] (normal) ../../libraries/process/tests 3994 [bad exit code] (threaded1) ../../libraries/unix/tests signals004 [bad exit code] (normal) ../../libraries/unix/tests/libposixposix004 [bad exit code] (normal) ../../libraries/unix/tests/libposixposix005 [bad stdout] (normal) concurrent/should_run conc070 [bad exit code] (ghci) driver dynHelloWorld [bad exit code] (dyn) dynlibsT3807 [bad exit code] (normal) dynlibsT5373 [bad stdout] (normal) ffi/should_run 4038 [bad exit code] (normal) perf/compiler T3294 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) pluginsplugins01 [bad exit code] (normal) pluginsplugins02 [stderr mismatch] (normal) pluginsplugins03 [stderr mismatch] (normal) rtsT2615 [bad stdout] (normal) rtsderefnull [bad exit code] (normal) rtsdivbyzero [bad exit code] (normal) rtsexec_signals [bad stdout] (normal) safeHaskell/check/pkg01ImpSafeOnly01 [exit code non-0] (normal) safeHaskell/check/pkg01ImpSafeOnly02 [exit code non-0] (normal) safeHaskell/check/pkg01ImpSafeOnly03 [stderr mismatch] (normal) safeHaskell/check/pkg01ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01ImpSafeOnly05 [stderr mismatch] (normal) safeHaskell/check/pkg01ImpSafeOnly06 [exit code non-0] (normal) safeHaskell/check/pkg01ImpSafeOnly07 [stderr mismatch] (normal) safeHaskell/check/pkg01ImpSafeOnly08 [stderr mismatch] (normal) safeHaskell/check/pkg01ImpSafeOnly09 [stderr mismatch] (normal) safeHaskell/check/pkg01ImpSafeOnly10 [exit code non-0] (normal) safeHaskell/check/pkg01safePkg01 [bad exit code] (normal) --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Validate of GHC HEAD freezes on FreeBSD
Hi Páli, On a related note, I have just (about a month ago) switched to GCC 4.6 for the GHC maintained in the FreeBSD Ports Collection (7.4.2, as part of the Haskell Platform), and I did not experience any problem with it, I am currently using it on my netbook, together with numerous ports I have for it. Thank you for your reply. Just in case, I would summarize what I'm talking about. There are two issues on FreeBSD: 1) Building GHC stops This is the problem which we are discussing in http://hackage.haskell.org/trac/ghc/ticket/7592 2) Tests freeze I confirmed that GHC 7.4.2, GHC HEAD, GHC 7.6.2RC2 has the same problem. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Validate of GHC HEAD freezes on FreeBSD
Hi, When I execute the following command (after GHC is build): % THREADS=1 sh validate --testsuite-only the following test command always freezes: cd ./concurrent/should_run '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history conc070.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS conc070.genscript 1conc070.interp.stdout 2conc070.interp.stderr The GHC command is consuming CPU 100%. I tested this GHC 4.6/GHC 4.7 to make GHC and GNU make 3.81/3.82. But nothing changed. Does nobody execute the validate script on FreeBSD before? --Kazu From: Kazu Yamamoto (山本和彦) k...@iij.ad.jp Subject: Re: Validate of GHC HEAD freezes on FreeBSD OK. I found an alternative timeout command written in Haskell. And insert unblockSignals fullSignalSet to it. Now validate can finish. I guess that one process (possibly GNU make) set signal mask and its children inherit it. What is a right solution for this? --Kazu I confirmed that testsuite/timeout/install-inplace/bin/timeout.py does not receive SIGALRM, so it is waiting forever. Any suggestions to fix this? --Kazu Hello, The validate script against GHC HEAD freezes on FreeBSD 9.1. After sync-all, I did as follow: % config_args=--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 CPUS=10 sh validate This stopped quickly due to this problem: http://hackage.haskell.org/trac/ghc/ticket/7592 Then I executed validate with --no-clean again. % config_args=--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 CPUS=10 sh validate --no-clean GHC could be compiled and tests started. But this resulted in: cd ../../libraries/base/tests '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hsqsemn001.comp.stderr 21 cd ../../libraries/base/tests ./T5962/dev/null T5962.run.stdout 2T5962.run.stderr cd ../../libraries/base/tests ./5943/dev/null 5943.run.stdout 25943.run.stderr cd ../../libraries/base/tests ./T7034/dev/null T7034.run.stdout 2T7034.run.stderr cd ../../libraries/base/tests ./qsem001/dev/null qsem001.run.stdout 2qsem001.run.stderr cd ../../libraries/base/tests ./qsemn001/dev/null qsemn001.run.stdout 2qsemn001.run.stderr Wrong exit code (expected 0 , actual 9 ) Stdout: Stderr: *** unexpected failure for Chan002(normal) And waiting for something forever. Does anyone understand what happened? Note that I can build GHC HEAD by typing gmake (v3.82 installed by the ports system) twice. This is a serious problem for us since we want to merge our code to GHC HEAD. validate against GHC with our code on Linux and Mac passed so far. But validate against even vanilla GHC freezes. P.S. On FreeBSD, I applied the following patch for validate since unused-but-set-variable is not available. diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index 399bf0e..378a3e6 100644 --- a/mk/validate-settings.mk +++ b/mk/validate-settings.mk @@ -13,7 +13,7 @@ HADDOCK_DOCS= YES # Debian doesn't turn -Werror=unused-but-set-variable on by default, so # we turn it on explicitly for consistency with other users ifeq $(GccLT46) NO -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline endif --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users
Re: Validate of GHC HEAD freezes on FreeBSD
Hi, Even testsuite for GHC 7.4.2 (gmake fast) freezes: * Consuming CPU 100% - compiling conc070.hs - 367_letnoes - throwto001 - Chan002 * Waiting for somting forever - signals004 I can reproduce this phenomena both for GHC HEAD and GHC 7.4.2 100%. --Kazu Hi, When I execute the following command (after GHC is build): % THREADS=1 sh validate --testsuite-only the following test command always freezes: cd ./concurrent/should_run '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history conc070.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS conc070.genscript 1conc070.interp.stdout 2conc070.interp.stderr The GHC command is consuming CPU 100%. I tested this GHC 4.6/GHC 4.7 to make GHC and GNU make 3.81/3.82. But nothing changed. Does nobody execute the validate script on FreeBSD before? --Kazu From: Kazu Yamamoto (山本和彦) k...@iij.ad.jp Subject: Re: Validate of GHC HEAD freezes on FreeBSD OK. I found an alternative timeout command written in Haskell. And insert unblockSignals fullSignalSet to it. Now validate can finish. I guess that one process (possibly GNU make) set signal mask and its children inherit it. What is a right solution for this? --Kazu I confirmed that testsuite/timeout/install-inplace/bin/timeout.py does not receive SIGALRM, so it is waiting forever. Any suggestions to fix this? --Kazu Hello, The validate script against GHC HEAD freezes on FreeBSD 9.1. After sync-all, I did as follow: % config_args=--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 CPUS=10 sh validate This stopped quickly due to this problem: http://hackage.haskell.org/trac/ghc/ticket/7592 Then I executed validate with --no-clean again. % config_args=--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 CPUS=10 sh validate --no-clean GHC could be compiled and tests started. But this resulted in: cd ../../libraries/base/tests '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hsqsemn001.comp.stderr 21 cd ../../libraries/base/tests ./T5962/dev/null T5962.run.stdout 2T5962.run.stderr cd ../../libraries/base/tests ./5943/dev/null 5943.run.stdout 25943.run.stderr cd ../../libraries/base/tests ./T7034/dev/null T7034.run.stdout 2T7034.run.stderr cd ../../libraries/base/tests ./qsem001/dev/null qsem001.run.stdout 2qsem001.run.stderr cd ../../libraries/base/tests ./qsemn001/dev/null qsemn001.run.stdout 2qsemn001.run.stderr Wrong exit code (expected 0 , actual 9 ) Stdout: Stderr: *** unexpected failure for Chan002(normal) And waiting for something forever. Does anyone understand what happened? Note that I can build GHC HEAD by typing gmake (v3.82 installed by the ports system) twice. This is a serious problem for us since we want to merge our code to GHC HEAD. validate against GHC with our code on Linux and Mac passed so far. But validate against even vanilla GHC freezes. P.S. On FreeBSD, I applied the following patch for validate since unused-but-set-variable is not available. diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index 399bf0e..378a3e6 100644 --- a/mk/validate-settings.mk +++ b/mk/validate-settings.mk @@ -13,7 +13,7 @@ HADDOCK_DOCS= YES # Debian doesn't turn -Werror=unused-but-set-variable on by default, so # we turn it on explicitly for consistency with other users ifeq $(GccLT46) NO -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline endif --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman
Re: Validate of GHC HEAD freezes on FreeBSD
Hi, I confirmed that testsuite/timeout/install-inplace/bin/timeout.py does not receive SIGALRM, so it is waiting forever. Any suggestions to fix this? --Kazu Hello, The validate script against GHC HEAD freezes on FreeBSD 9.1. After sync-all, I did as follow: % config_args=--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 CPUS=10 sh validate This stopped quickly due to this problem: http://hackage.haskell.org/trac/ghc/ticket/7592 Then I executed validate with --no-clean again. % config_args=--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 CPUS=10 sh validate --no-clean GHC could be compiled and tests started. But this resulted in: cd ../../libraries/base/tests '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hs qsemn001.comp.stderr 21 cd ../../libraries/base/tests ./T5962/dev/null T5962.run.stdout 2T5962.run.stderr cd ../../libraries/base/tests ./5943/dev/null 5943.run.stdout 25943.run.stderr cd ../../libraries/base/tests ./T7034/dev/null T7034.run.stdout 2T7034.run.stderr cd ../../libraries/base/tests ./qsem001/dev/null qsem001.run.stdout 2qsem001.run.stderr cd ../../libraries/base/tests ./qsemn001/dev/null qsemn001.run.stdout 2qsemn001.run.stderr Wrong exit code (expected 0 , actual 9 ) Stdout: Stderr: *** unexpected failure for Chan002(normal) And waiting for something forever. Does anyone understand what happened? Note that I can build GHC HEAD by typing gmake (v3.82 installed by the ports system) twice. This is a serious problem for us since we want to merge our code to GHC HEAD. validate against GHC with our code on Linux and Mac passed so far. But validate against even vanilla GHC freezes. P.S. On FreeBSD, I applied the following patch for validate since unused-but-set-variable is not available. diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index 399bf0e..378a3e6 100644 --- a/mk/validate-settings.mk +++ b/mk/validate-settings.mk @@ -13,7 +13,7 @@ HADDOCK_DOCS= YES # Debian doesn't turn -Werror=unused-but-set-variable on by default, so # we turn it on explicitly for consistency with other users ifeq $(GccLT46) NO -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline endif --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Validate of GHC HEAD freezes on FreeBSD
OK. I found an alternative timeout command written in Haskell. And insert unblockSignals fullSignalSet to it. Now validate can finish. I guess that one process (possibly GNU make) set signal mask and its children inherit it. What is a right solution for this? --Kazu I confirmed that testsuite/timeout/install-inplace/bin/timeout.py does not receive SIGALRM, so it is waiting forever. Any suggestions to fix this? --Kazu Hello, The validate script against GHC HEAD freezes on FreeBSD 9.1. After sync-all, I did as follow: % config_args=--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 CPUS=10 sh validate This stopped quickly due to this problem: http://hackage.haskell.org/trac/ghc/ticket/7592 Then I executed validate with --no-clean again. % config_args=--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 CPUS=10 sh validate --no-clean GHC could be compiled and tests started. But this resulted in: cd ../../libraries/base/tests '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hsqsemn001.comp.stderr 21 cd ../../libraries/base/tests ./T5962/dev/null T5962.run.stdout 2T5962.run.stderr cd ../../libraries/base/tests ./5943/dev/null 5943.run.stdout 25943.run.stderr cd ../../libraries/base/tests ./T7034/dev/null T7034.run.stdout 2T7034.run.stderr cd ../../libraries/base/tests ./qsem001/dev/null qsem001.run.stdout 2qsem001.run.stderr cd ../../libraries/base/tests ./qsemn001/dev/null qsemn001.run.stdout 2qsemn001.run.stderr Wrong exit code (expected 0 , actual 9 ) Stdout: Stderr: *** unexpected failure for Chan002(normal) And waiting for something forever. Does anyone understand what happened? Note that I can build GHC HEAD by typing gmake (v3.82 installed by the ports system) twice. This is a serious problem for us since we want to merge our code to GHC HEAD. validate against GHC with our code on Linux and Mac passed so far. But validate against even vanilla GHC freezes. P.S. On FreeBSD, I applied the following patch for validate since unused-but-set-variable is not available. diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index 399bf0e..378a3e6 100644 --- a/mk/validate-settings.mk +++ b/mk/validate-settings.mk @@ -13,7 +13,7 @@ HADDOCK_DOCS= YES # Debian doesn't turn -Werror=unused-but-set-variable on by default, so # we turn it on explicitly for consistency with other users ifeq $(GccLT46) NO -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline endif --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RULES for ByteString are not fired
Hello,
I seems to us (my friends and me) that term rewriting rules for
ByteString are not fired in recent GHCs.
6.12.3OK
7.0.4 NG
7.4.1 NG
7.6.1RC1 NG
For example, with the example from this ticket
http://hackage.haskell.org/trac/ghc/ticket/3703
results in as follows:
% ghc -O -ddump-simpl-stats --make breakOn.hs
14 RuleFired
4 Class op showsPrec
2 Class op show
2 eqChar#-case
2 unpack
2 unpack-list
1 Class op ==
1 Class op
There is no ByteString rules.
Is this a bug or intention?
--Kazu
{-# LANGUAGE OverloadedStrings #-}
import qualified Data.ByteString.Char8 as B
main :: IO ()
main = do
let string1 = B.pack This is a string
string2 = B.pack This is another string
print (breakOn ' ' string1)
print (breakOn ' ' string2)
breakOn :: Char - B.ByteString - (B.ByteString, B.ByteString)
breakOn c = B.break (c==)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
strange behavior of let in ghci
Hello, I met strange behavior of let in ghci 7.0.4. The following works well. :m Data.List let compFst (n1,s1) (n2,s2) = compare n1 n2 maximumBy compFst [(1, boo), (3, foo), (2, woo)] (3,foo) But if I bind maximumBy compFst to chooseMax with let, it causes error: let chooseMax = maximumBy compFst chooseMax [(1,boo),(3,foo),(2,woo)] interactive:1:33: No instance for (Num ()) arising from the literal `2' Possible fix: add an instance declaration for (Num ()) In the expression: 2 In the expression: (2, woo) In the first argument of `chooseMax', namely `[(1, boo), (3, foo), (2, woo)]' It's very strange to me. Why does this happen? :t says: :t maximumBy compFst maximumBy compFst :: Ord a = [(a, t)] - (a, t) :t chooseMax chooseMax :: [((), t)] - ((), t) I'm writing a tutorial of Haskell and I would like to define chooseMax in ghci with let without specifying its signature. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: strange behavior of let in ghci
Antoine, You're running into the monomorphism restriction: http://www.haskell.org/haskellwiki/Monomorphism_restriction Oh. Thanks. You can also turn off the restriction at the command-line with the argument '-XNoMonomorphismRestriction', I think. I will use ghci -XNoMonomorphismRestriction in my tutorial. Thank you again. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: secret of light-weight user thread
Simon, Thank you for explanation. - We have an accurate GC, which means that the Haskell stack can be movable, whereas the C stack isn't. So we can start with small stacks and enlarge them as necessary. What is the difference between the Haskell stack and the C stack? I guess that the C stack means CPU's stack. Is the Haskell stack a virtual stack for a virtual machine (STG machine or something)? I quickly read several papers but I have no idea. - We only preempt threads at safe points. This means that the context we have to save at a context switch is platform-independent and typically much smaller than the entire CPU context. Safe points are currently on allocation, which is frequent enough in GHC for this to be indistinguishable (most of the time) from true preemption. I seems to me that StgRun saves CPU registers. You mean that StgRun depends on CPU a bit but the rest part of context is CPU independent? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: secret of light-weight user thread
Hello Simon, Now everything is clear to me. I wrote a blog article on this in Japanese. Thanks. --Kazu On 07/09/2011 08:13, Kazu Yamamoto (山本和彦) wrote: Simon, Thank you for explanation. - We have an accurate GC, which means that the Haskell stack can be movable, whereas the C stack isn't. So we can start with small stacks and enlarge them as necessary. What is the difference between the Haskell stack and the C stack? I guess that the C stack means CPU's stack. Is the Haskell stack a virtual stack for a virtual machine (STG machine or something)? There's no fundamental difference between the Haskell stack and the C stack, they are both just runtime data structures used by compiled code. We designed the Haskell stack so that pointers within it can be identified by the GC, that's all. When running Haskell code there's a register that points to the top of the Haskell stack, just like when running C code (it's a different register, but in principle there's no reason it has to be different). I quickly read several papers but I have no idea. - We only preempt threads at safe points. This means that the context we have to save at a context switch is platform-independent and typically much smaller than the entire CPU context. Safe points are currently on allocation, which is frequent enough in GHC for this to be indistinguishable (most of the time) from true preemption. I seems to me that StgRun saves CPU registers. You mean that StgRun depends on CPU a bit but the rest part of context is CPU independent? StgRun is the interface between the C world and the Haskell world, which have different ABIs. In particular, the C ABI requires that function calls do not modify certain registers (the callee-saves registers), whereas in Haskell there are no callee-saves registers. So StgRun saves the callee-saves registers while running Haskell code, that's all. It may have to do other things depending on what specific conventions are used by C or Haskell code on the current platform. This is just something we have to do so that we can call Haskell code from C. It's not related to threads, except that the GHC scheduler is written in C so we have to go through StgRun every time we start or stop a Haskell thread. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
secret of light-weight user thread
Hello, Recently I exchanged information about user threads with Ruby community in Japan. The user threads of Ruby 1.8 are heavy weight and Ruby 1.9 switched to kernel threads. The reason why user threads of Ruby 1.8 are heavy weight is *portability*. Since Ruby community does not want to prepare assembler to change stack pointers for each supported CPU architecture, Ruby 1.8 copies the stack of user threads on context switch. Because I need to explain why the user threads of GHC are light weight, I gave a look at GHC's source code and found the loadThreadState function in compiler/codeGen/StgCmmForeign.hs. In this function, the stack pointer is changed in the Cmm level. So, my interpretation is as follows: Since GHC has Cmm backend, it is easy to provide assembler to change stack pointers for each supported CPU architecture. That's why GHC can provide light weight user threads. Is my understanding correct? Thanks in advance. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: alternative to loadWithLogge
Judah, ghc-mod, IDE-like back-end for Emacs, uses warning related APIs including loadWithLogger and getWarnings in GHC 7.0.3 API. I found that they disappeared in GHC 7.2.1 API. What should I use to handle warnings in GHC 7.2.1 API? You can set the log_action field of the session's DynFlags to a custom handler. Its value is type LogAction = Severity - SrcSpan - PprStyle - Message - IO () The Severity parameter will let you tell whether a message is a warning or an error. Thank you very much for this information. Now ghc-mod can be complied with GHC 7.2.1! --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
alternative to loadWithLogge
Hello, ghc-mod, IDE-like back-end for Emacs, uses warning related APIs including loadWithLogger and getWarnings in GHC 7.0.3 API. I found that they disappeared in GHC 7.2.1 API. What should I use to handle warnings in GHC 7.2.1 API? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs on Mac
Hello, Not directly. hsc2hs calls the C compiler to determine these numbers. It seems it is calling gcc-4.0 rather than gcc-4.2. It might be a bug that it is calling the wrong compiler, but that might just be misconfiguration in your environment, or in the Haskell Platform. gcc-4.0 says sizeof (struct stat) is 108 while gcc-4.2 (default) says that is 144. It presumably depends on whether you're using the 32 or 64-bit version of GHC. Which is it? % file /Library/Frameworks/GHC.framework/Versions/7.0.3-i386/usr/lib/ghc-7.0.3/ghc /Library/Frameworks/GHC.framework/Versions/7.0.3-i386/usr/lib/ghc-7.0.3/ghc: Mach-O executable i386 So, it's 32bit. (If 64bit, file displays 64bit.) --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hsc2hs on Mac
Hello, I'm using Haskell Platform 2011.2.0.1 on MacOS (Snow Leapard). hsc2hs converts (#const sizeof(struct stat)) (#peek struct stat, st_mtimespec) to 108 36 but the correct values are 144 32. Is this a bug of hsc2hs? gcc-4.0 says sizeof (struct stat) is 108 while gcc-4.2 (default) says that is 144. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
entries in profile results
Hello, I'm taking profile for my program with -auto-all -caf-all. I found that I don't understand what entries means. An IO function in my program should be called N times but entries shows 3N. I inserted putStrLn in that function and ensured that it was called just N times. Please tell me what entries mean exactly. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
a message from Tokyo
Dear GHC users and Haskell community members, I'm writing this message to tell you the situation of Japan. As you know, the biggest earthquake since 1900 occurred. North-east of Japan is now like hell. Many towns were destroyed due to Tsunami. Many fires still continue. I guess some of you have been to Sendai which is a central town of North-east of Japan. The situation of Sendai is really really bad. I'm concerning whether or not people of Tohoku University are safe. Thanks to twitter, Eijiro Sumii, who is the chair of ICPF 2011 programming contest is safe. Fortunately, Tokyo is fine. I was working at my office in Tokyo and experienced the biggest earthquake in my life. 16 years ago, I was living in a place which is 200 km away from Kobe. At the time, the earthquake was the biggest for me, of course. But this time, quake was worse than that. All trains and subways in Tokyo stopped. Some people had to stay in their companies. Some chose to walk for many hours. Some had to stay in schools which were opened to everybody. In my case, I got home by my bicycle. I could not communicate with my wife by mobile phone. But my wife walked for four hours with our son and finally got together yesterday. All members of Haskell community in Tokyo are fine. Some of them are twitting. Probably we will be able to hold a study meeting on Yesod tommorrow. I believe this earthquake will not stop ICPF 2011 since Tokyo had little damage. I hope people living in North-east Japan can go home as quickly as possible and their town will recover. If you have any questions, please tell me by e-mail or twitter(@kazu_yamamoto). And I hope you kindly pray for them. Sincerely, --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bin-package-db
Simon, Thank you for your reply. This package is used internally by ghc-pkg and ghc to read and write the binary package database cache, it shouldn't be necessary for anyone else to use it - just invoke ghc-pkg to do any operations on the database. OK. We started using the Cabal library instead of bin-package-db. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
bin-package-db
Hello, The release note of GHC 7.0.2 says: 1.5.6.3. bin-package-db This is an internal package, and should not be used. What is the intention of this change? The author of cabal-delete hesitates to register cabal-delete into HackageDB due to this words. Shouldn't a package-maintenance command even use this package? If so, what package should be used? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal install network was: Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2
Ah, yes this one works, although with: checking whether AI_NUMERICSERV is declared... no even if hsc2hs does not contain this isysroot stuff. Where does cabal get its flags from? (hardcoded?) Ah, this also happened to me. checking whether AI_ADDRCONFIG is declared... yes checking whether AI_ALL is declared... yes checking whether AI_NUMERICSERV is declared... no checking whether AI_V4MAPPED is declared... yes I'm using Mac 64bit version of GHC 7.0.2 rc1 on Snow Leopard. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal install network was: Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2
Hello, The problem (below) is caused by the new flags -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 inside hsc2hs that have been added to fix http://hackage.haskell.org/trac/ghc/ticket/4860. ./configure for the network package does not use these flags. So AI_NUMERICSERV is defined for 10.6 but not for 10.5. You need the latest Cabal library. % cabal --version cabal-install version 0.9.5 using version 1.10.1.0 of the Cabal library With this the cabal-install command, you can install the network package. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal install network was: Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2
Just to double check. Is there a problem with the network library that I need to fix or is this just GHC/Cabal related? If HP will provide the latest Cabal library and cabal, there is no problem. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: a compiled program is slower than byte code
Hello, My stats look very different. 6 RuleFired 1 ++ 2 =# 1 foldr/app 1 unpack 1 unpack-list Are your libraries compiled with -O2? I don't know. How can I check? I just installed ghc-7.0 by perl boot; configure; make; make install. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: a compiled program is slower than byte code
Hello Simon, $ ghc-nightly2 ./kazu.hs -O2 -fforce-recomp; time ./kazu [1 of 1] Compiling Main ( kazu.hs, kazu.o ) Linking kazu ... 4.17s real 4.16s user 0.01s system 99% ./kazu OK. I ran it on 32bit Linux. 6.12.3 runghc -- 2.22s user 0.40s system 96% cpu 2.724 total ghc -- 1.96s user 0.14s system 97% cpu 2.151 total ghc -O -- 2.18s user 0.10s system 97% cpu 2.333 total ghc -O2 -- 2.27s user 0.07s system 97% cpu 2.393 total ghc-7.0 runghc -- 3.43s user 0.35s system 97% cpu 3.861 total ghc -- 5.11s user 0.07s system 97% cpu 5.299 total ghc -O -- 5.38s user 0.03s system 97% cpu 5.534 total ghc -O2 -- 5.54s user 0.10s system 97% cpu 5.783 total ghc-7.0 is slower than 6.12.3. And if the code is compiled with ghc-7.0, it is slower than runghc. HEAD is more than twice as fast on this program. Fusion not working, perhaps? Here is the results of ghc -O -ddump-simpl-stats: ghc-7.0: 19 RuleFired 6 ++ 2 =# 1 fold/build 5 foldr/app 1 foldr/augment 1 foldr/single 1 map 1 unpack 1 unpack-list 6.12.3: 25 RuleFired 6 ++ 2 =# 3 fold/build 6 foldr/app 1 foldr/augment 1 map 2 repeat 2 take 1 unpack 1 unpack-list They are exactly the same on Linux and Mac. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
a compiled program is slower than byte code
Hello, If I compile the attach code with GHC of the newest ghc-7.0 darcs branch, the compiled program is much slower than byte code. This phenomenon does not exist in GHC 6.12.3. 6.12.3 runghc -- 6.23s user 0.59s system 98% cpu 6.912 total ghc -- 5.72s user 0.70s system 99% cpu 6.422 total ghc -O -- 5.70s user 0.67s system 99% cpu 6.376 total ghc -O2 -- 5.69s user 0.67s system 99% cpu 6.373 total ghc-7.0 runghc -- 6.43s user 0.10s system 99% cpu 6.593 total ghc -- 9.20s user 0.09s system 99% cpu 9.302 total ghc -O -- 9.20s user 0.09s system 99% cpu 9.298 total ghc -O2 -- 9.38s user 0.09s system 99% cpu 9.478 total Is this a bug? My environment is Mac which runs Snow Leopard. --Kazu import System.IO n :: Int n = 1 main :: IO () main = withFile /dev/null WriteMode $ \h - hPutStr h . foldr1 (++) . replicate n . replicate n $ 'a' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
Hello, Yes, it's still on in GHC by default, but Cabal specifies Haskell98 if a language isn't given in the .cabal file. network probably wants to give NondecreasingIndentation as an extension if impl(ghc = 7.1). I'm not asking how to fix packages. Actually the layout of the network package on github has been fixed today. I'm asking why GHC breaks backward compatibility (e.g. FlexibleInstances and BangPatterns) and why maintainers of packages should do boring fixes. What are benefits of such overhead? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
backward compatibility
Hello, I have been using GHC HEAD for some months and am suffering from the breaks of backward compatibility. 1) MANY packages cannot be complied with GHC HEAD because of lack of FlexibleInstances and BangPatterns. 2) The network package on github cannot be compiled because the layout handling of GHC HEAD became more severe. For instance, here is such code from Network/Socket.hsc. allocaBytes (2 * sizeOf (1 :: CInt)) $ \ fdArr - do _ - throwSocketErrorIfMinus1Retry socketpair $ c_socketpair (packFamily family) (packSocketType stype) protocol fdArr Of course, indentation is necessary before _. But this can be compiled with GHC 7.0.1 but cannot with GHC HEAD. I sent feedback to some maintainers of packages. Some quickly fixed it and registered it again. But others did not respond. That is reality. So, my question is why GHC HEAD does not maintain backward compatibility? What are befits for giving it up? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: git repos for testing
Hello Simon, I've made git mirrors of the current GHC HEAD repos (all of them), so people can try out their workflows with git. Hopefully this should work: git clone http://darcs.haskell.org/ghc-git/ghc.git cd ghc perl sync-all get Thank you for this work. I cloned the git repository and tried to compile GHC. But perl boot does not work. % perl boot Unpacking time Failed to open stamp file: No such file or directory at boot-pkgs line 41. Running boot-pkgs failed: 512 at boot line 23. How can I create the configure script with GHC from this repository? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
network programming with GHC 7
Hello, When I compiled a network server with GHC 7 without the -threaded option and ran it, I got the following error. file descriptor 5496824 out of range for select (0--1024). I have read the paper Scalable Event Handling for GHC and understand that this new IO manger assumes the -threaded option. Does this mean that we need the -threaded option to GHC 7 for networking programming and GHC 7 does not maintain backward compatibility? If so, this should be documented. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: three dots of :browse
| data R = R {x :: Char, y :: Int, z :: Float}
| data R = R {x :: Char, ...}
| data R = R {..., y :: Int, ...}
| data R = R {..., z :: Float}
|
| which cannot be parsed.
That's a bug, plain and simple. I know why it happens, too, though
I will not bore you with the details. I'll make a Trac ticket.
Thanks.
Another related question: :browse Prelude of GHC 6.12 displays:
data Integer
= integer-gmp:GHC.Integer.Type.S# GHC.Prim.Int#
| integer-gmp:GHC.Integer.Type.J# GHC.Prim.Int# GHC.Prim.ByteArray#
That of GHC 6.10 displays:
data Integer
= GHC.Integer.Internals.S# GHC.Prim.Int#
| GHC.Integer.Internals.J# GHC.Prim.Int# GHC.Prim.ByteArray#
Is the additional prefix of integer-gmp: intentional or a bug?
--Kazu
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: three dots of :browse
Hello,
*Test :browse! Test
-- defined locally
data R = R {x :: Char, y :: Int, z :: Float}
R :: Char - Int - Float - R
x :: R - Char
y :: R - Int
z :: R - Float
is the answer?
Thank you for your reply. Unfortunately, the answer is NO.
:browse! cannot be used for my program.
I want to use :browse.
Again, my question is: suppose the following code is given:
module Test (R(..)) where
data R = R { x :: Char, y :: Int, z :: Float }
and :browse of GHC 6.12 displays:
data R = R {x :: Char, y :: Int, z :: Float}
data R = R {x :: Char, ...}
data R = R {..., y :: Int, ...}
data R = R {..., z :: Float}
which cannot be parsed. But :browse of GHC 6.10 displays:
data R = R {x :: Char, y :: Int, z :: Float}
which can be parsed.
Is this intentional change or a bug of GHC 6.12?
--Kazu
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: three dots of :browse
Q1) What is the intention of ...?
I believe it's related to the module export list.
module Test (y) where
data R = R { x :: Char, y :: Int, z :: Float }
*Test :browse
data Test.R = Test.R {..., y :: Int, ...}
Thank you for your reply.
The target module exposes like this:
module Test (R(..)) where
So, this is not the case which you referred to.
--Kazu
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
three dots of :browse
Hello,
If I use :browse a module with GHC 6.12, it sometimes displays
garbage. Here is an example:
Prelude :browse Data.IP
data AddrRange a
= iproute-0.2.0:Data.IP.Range.AddrRange {addr :: a,
mask :: a,
mlen :: Int}
(snip)
data AddrRange a
= iproute-0.2.0:Data.IP.Range.AddrRange {..., mask :: a, ...}
data AddrRange a
= iproute-0.2.0:Data.IP.Range.AddrRange {..., mlen :: Int}
... is the garbage. Due to this, I cannot parse the output of
:browse. This is not displayed with GHC 6.10.
Q1) What is the intention of ...?
Q2) How to prevent it so that I can obtain output which I can parse?
--Kazu
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to know data size in UDP?
Hello, If my understating is correct, I cannot use recvFrom since it calls recvfrom() with FFI. So, I use socketToHandle to translate a socket to a handle. Sorry. This is my misunderstanding. recvFrom does not stop other threads at least on UNIX. So, my problem is solved. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to know data size in UDP?
Hello,
I'm trying to implement DNS resolver without any external C libraries
for my daemon program which uses DNS lookup.
I know the hsdns library exists. But since it calls GNU asynchronous
DNS resolver library by FFI, all threads of Haskell are blocked on
non-threaded RTS.
If the threaded RTS is used, forkProcess kills the IO thread. With the
threaded RTS of at least GHC 6.10.4, we cannot make our program as a
daemon nor use pre-fork mechanism.
Thus, I decided to implement DNS resolver only with non-blocking
Haskell functions.
I use a *connected* UDP socket like this:
proto - getProtocolNumber udp
let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_NUMERICHOST,
AI_PASSIVE]
, addrSocketType = Datagram
, addrProtocol = proto }
a:_ - getAddrInfo (Just hints) (Just An IP address of DNS server) (Just
domain)
sock - socket (addrFamily a) (addrSocketType a) (addrProtocol a)
connect sock (addrAddress a)
h - socketToHandle sock ReadWriteMode
hSetBuffering h NoBuffering
hSetBinaryMode h True
If my understating is correct, I cannot use recvFrom since it calls
recvfrom() with FFI. So, I use socketToHandle to translate a socket to
a handle.
Since the handle is associated with UDP, the entire data size should
be known when a UDP packet arrived. But I cannot find a way to know
data size. (I want a function like hFileSize.) Note that hGetContents
blocks.
Without data size in advance, a program to handle network protocols on
UDP becomes quite dirty or sometime cannot be implemented. So, please
tell me how to know data size associated with a handler of UDP?
--Kazu
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: buildFdSets: file descriptor out of range
Hello, I have a standalone (i.e. not integrated into the RTS yet) proof of concept working using kqueue. However, to be portable we still need to fall back to select on systems that don't support anything better. This implies that if you want to write portable code you still suffer from this limit. If portability is important, how about falling back to poll(), not epoll()? I've been unable to hack lately due to an injury but I'll be able to get back to it next week. Take care. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: buildFdSets: file descriptor out of range
Hello, Reduce this to 1024, otherwise the runtime will eventually find itself dealing with file descriptors beyond the select() limit mentioned above. Someone with more knowledge of the Haskell runtime will have to advise as to possible ways around it if you really need more than 1024 file descriptors. There's no easy workaround. We could have the IO library switch to using blocking read() calls for the out-of-range FDs to avoid the error from the IO manager, but that is likely to lead to a different problem: too many OS threads. Thank you for reply. I changed forkIO to forkOS. But I received the following error. ERRORCannot create OS thread. I want to decrease the stack size of threads to increase the number of threads to be created. How can I do this? I tried to decrease ResourceStackSize and tried the RTS -k option but both does not increase the number of threads... --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
buildFdSets: file descriptor out of range
Hello, If this is not a right place to ask this question, please tell me another place to ask. I'm developing a mail server with GHC 6.10.3 on Linux. The server is running well at the beginning. But after several hours, it receives an error, buildFdSets: file descriptor out of range. Please tell me what happened? And please suggest me how to fix this problem. Here is brief description of the server. - linked with ADNS. - complied with the -threaded option since ADNS requires it. - uses forkIO to produce threads. - does not use deamonize of System.Posix.Daemonize since it uses forkProcess. I execute my server as foreground process. - Because there are so many nasty SMTP clients, most SMTP connections are time out. Handles of the SMTP connections disappear, so I cannot use hClose to close the handles. - pushes the limit of file descriptors to 65536 with setResourceLimit. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: buildFdSets: file descriptor out of range
I believe the runtime uses select(), which has a hard limit (enforced by the kernel) that the maximum file descriptor id be 1023. (select() uses bitmasks and there is a limit on the size of a bitmask; see FD_SETSIZE.) I understand. Thank you. Reduce this to 1024, otherwise the runtime will eventually find itself dealing with file descriptors beyond the select() limit mentioned above. Someone with more knowledge of the Haskell runtime will have to advise as to possible ways around it if you really need more than 1024 file descriptors. I used to execute my server with the limit of 1024 since this is the default limit of my machine. At that time, I suffered from the following errors: rpf: user error (Cannot create OS thread.) rpf: accept: resource exhausted (Too many open files) So, I pushed the limit to 65536. I don't believe my server receives 1024 connections at once. So, I guess file descriptors leak. Does anyone know what happens when a TCP connection is reset by the peer and its handle disappears. Does the file descriptor bound to the handle leak? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Unicode's greek lambda
Hello, When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? Regards, --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
Hello, First of all, thank you for those who replied kindly. When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? The greek lambda is a normal lower-case alphabetic character - it can be used in identifier names. OK. I understand. But it could be a reserved word synonymous with \. After all, \ can occur in operator symbols, but the operator \ is reserved. Presumably that would let you do (\ x - ...) but not (\x - ) since the \x would run together and lexically it would be one identifier. If we reserve the greek lambda as special like '\', the lexer can separate lambdax into two tokens: lambda and 'x', I guess. Some people may want to use the greek lambda in identifiers. And some would want to use the greek lambda as an alternative of '\'. So, how about providing a new option to make the greek lambda special? P.S. I want to type the examples in Programming in Haskell as is. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
Hello, If we reserve the greek lambda as special like '\', the lexer can separate lambdax into two tokens: lambda and 'x', I guess. Not without redefining it as a symbol instead of a lowercase letter, which won't be done as previously discussed. OK. Fine with me since this topic was previously discussed. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
