Re: [Haskell] ANN: Hackage Account Registration Changes
Hi, On Thu, Feb 22, 2018 at 05:54:33PM -0500, Gershom B wrote: > In the meantime, as a short term measure, we have changed new account > registration policies on hackage. > > Users can still register as before, but new users do _not_ have upload > rights until they explicitly request them and are granted them by a > human being. > > (This is actually how we had configured hackage to work on initial > deployment -- we loosened things up for some years as the extra step > seemed unnecessary). Does this mean that before the todays change, anyone (or anything) could register and upload packages without any review and without any acknowledgement for trustfulness by another person? Does it maen that one can't trust *any* package on hackage.haskell.org at least a little bit (based on trust between acknowledging persons and reputation) without reviewing the package's source code? Ciao, Kili ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
GHC and Haskell-Platform on OpenBSD
Hi, I'd like to know wether anyone here is using GHC on OpenBSD *and* relying on the Haskell-Platform meta package for OpenBSD. If there's no need for the HP meta package, I could just start to update GHC and all related packages for OpenBSD, but if there are a lot of people who prefer to stick to the HP, I'd to wait until the official update of the HP. So, if you love running pkg_add haskell-platform on OpenBSD, please speak up. And if you don't care an just run pkg_add ghc please speak up too ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Hi, On Tue, Nov 27, 2012 at 08:15:59PM +, Ian Lynagh wrote: Regarding Question 7 (enable dynamic by default on other platforms) and OpenBSD: as long as it's easy to disable it again, I'll be happy with *any* decision. It will be easy to turn it off, but depending on the platform we might have removed support for GHCi when it's turned off. Does ghci work for you currently? Yes, but I'm still at ghc-7,4.2. Not enough time to catch up with recent ghc development :-( Is this a registerised or unregisterised build? Registerised, working on i386 and amd66 (or x86 and x86_64 in the non-bsd-world). That's partially because currently we've even a patch explicitely disabling shared library support in our ports/packages system (last time I tried with shared lib support, I got some segfaults in the midst of the build, and unfortunately I'm still too short of time to debug/fix it). That's a bit bizarre. With shared libraries enabled, there still won't be any dynamically linked programs actually run. No worry. There were a lot of changes in OpenBSD during the last 6 months (including dl.so, pthreads, whatever). Wether there's a bug in the GHC build system, or in the (heavily patched) OpenBSD port, or in the binaries we use for bootstrapping, I really dont't know. I wouldn't ve surprised if it's some breakage on my side (with the bootstrappers i supply). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Announce: Haskell Platform 2012.2.0.0
On Sun, Jun 03, 2012 at 09:24:42AM -0700, Mark Lentczner wrote: We're pleased to announce the next release of Haskell Platform: a single, standard Haskell distribution for everyone. Download Haskell Platform 2012.2.0.0: http://haskell.org/platform/ The specification, along with installers (including Windows, Macintosh, and Unix installers for a full Haskell environment) are available. The link to the cabal file in the changelog points to github.com, while the previous version was (a darcs repository) on code.haskell.org. Is there any chance to either also update the latter, too? Or just to remove it and decide on where the official haskell-platform.cabal file will reside in the future? Ciao, Kili ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: renamed GMP symbols in GHC
On Wed, Jan 04, 2012 at 12:31:23PM +, Joachim Breitner wrote: One potential problem is that some Linux distributions really don't like it if you bundle modified versions of external libraries. However, I just don't see a way around this: [...] [...] I guess this means me... Indeed Debian has the policy to avoid modified bundled libraries, if somehow possible. For example, we patch the build system to use the system-provided libffi. This policy isn't even specific to linux distributions ;-) I don't know about the package building infrastructure for debian or fedora, but for openbsd (where i'm doing a lot of haskell stuff), it would be enough if the ghc sources would include not only a (patched or unpatched) gmp source tree but also the ghc-specific patches to gmp. The rationale behind this polcicy (for openbsd, i can't speak for debian): if there are 42 packages where the source distribution files contain their own (probably patched) version of gmp, and suddenly a critical patch has to be applied to gmp, we would have to apply it 43 times (for gmp itself and for all the 42 packages using a bundled gmp). If the source distribution files contained diffs for gmp, we could (at least try to) extract our patched gmp and apply the diff on top of it. = less work, any openbsd-specific patch automatically will be applied to all 42 packages. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Completely reproducible Haskell builds
On Fri, May 27, 2011 at 04:35:17PM +0100, Simon Marlow wrote: Next best idea is to make GHC use repeatable temporary .c .o file names for each invocation. There is already a unique temporary directory where all the the temporary files are created. This suggests I do not need to worry about adversarial races. So GHC just need to avoid racing with itself. I see a couple of options: 1) newTempName should create a new subdirectory for each call and the return a fixed name inside of this (so /tmp/ghc28016_0/ghc28016_0.c above would become /tmp/ghc28016_0/0/dummy.c) 2) mkExtraCObj could compute some hash function of its xs argument (C program text) and then create a file named, e.g. /tmp/ghc28016_0/38eb8d8eb0abe9c828ba60983e2a97f7a069ec41.c Which of these two looks better? Other ideas? The first is easier, and would be fine with me. An alternative could be to just strip the single `symbol' off the object file (using something like strip -N ...). I didn't yet test this for real. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] select(2) or poll(2)-like function?
On Sun, Apr 17, 2011 at 01:44:50PM -0700, Don Stewart wrote: `forkIO` is based on epoll. So threadWaitFD and friends are using epoll. Or (on non-Linux systems) on kqueue or poll, as i learned from grep(1) and the folowups here. (And sorry for the noise; I really didn't expect such a flamebait) At least now i know what should be changed for frameworks like wai/warp to listen on multible sockets. Ciao, Kili ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] select(2) or poll(2)-like function?
Hi, is there something like select(2) or poll(2) available in the standard (HP) libraries? I hoogled around a little bit but didn't find anything. (Something like this will be crucial for networking stuff listening on v4 and v6 sockets at the same time) Ciao, Kili ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Rebuilding ghc changes interface hashes?
On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote: I still have to find my noticeses about wether cBooterVersion affects more than only the ghc lib. Did a quick test the other day; bootstrapping ghc-7.0.3 from ghc-6.12.3 with two different VERSION_DATE files. The only visible change was in the ghc library, so this part indeed isn't worth any work. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Wed, Apr 06, 2011 at 12:40:45PM +0100, Ian Lynagh wrote: compiler/stage2/build/Config.hs includes cBooterVersion, so if you boot with a different version then you get different code = different ABI. We could just remove this. In theory, stage2 won't be affected by the bootstrapping compiler at all anyway. Alternatively, if we make a config file (as we were discussing for putting the paths to gcc and ar in) then it could go in there, and then wouldn't be part of the ABI. Even if Simon prefers the config file approach (and there's still the question wether the booter version is useful at all), attached is an old patch in darcs format i found on my disk (dated april 24th 2010). Just in case anyone wants to play with it. I still have to find my noticeses about wether cBooterVersion affects more than only the ghc lib. Ciao, Kili 1 patch for repository http://darcs.volkswurst.de/ghc-6.12/ghc: Sat Apr 24 20:46:21 CEST 2010 Matthias Kilian k...@outback.escape.de * Zap cBooterVersion, in an attempt to fix #4012 Note: this is obviously just a workaround, not a real fix. New patches: [Zap cBooterVersion, in an attempt to fix #4012 Matthias Kilian k...@outback.escape.de**20100424184621 Ignore-this: 18bf356e798b3c26bd4c8d2f2bc79789 Note: this is obviously just a workaround, not a real fix. ] { hunk ./compiler/ghc.mk 50 @echo cProjectVersionInt= \$(ProjectVersionInt)\ $@ @echo cProjectPatchLevel:: String $@ @echo cProjectPatchLevel= \$(ProjectPatchLevel)\ $@ - @echo cBooterVersion:: String $@ - @echo cBooterVersion= \$(GhcVersion)\ $@ @echo cStage:: String $@ @echo cStage= show (STAGE :: Int) $@ @echo cIntegerLibrary :: String $@ hunk ./compiler/main/DynFlags.hs 2419 compilerInfo :: [(String, Printable)] compilerInfo = [(Project name,String cProjectName), (Project version, String cProjectVersion), -(Booter version, String cBooterVersion), (Stage, String cStage), (Have interpreter,String cGhcWithInterpreter), (Object splitting,String cSplitObjs), hunk ./ghc/Main.hs 646 do hPutStr stderr Glasgow Haskell Compiler, Version hPutStr stderr cProjectVersion hPutStr stderr , for Haskell 98, stage - hPutStr stderr cStage - hPutStr stderr booted by GHC version - hPutStrLn stderr cBooterVersion + hPutStrLn stderr cStage -- We print out a Read-friendly string, but a prettier one than the -- Show instance gives us } Context: [Fix the GHC API link in the main doc index.html Ian Lynagh ig...@earth.li**20100422213226] [Set RELEASE to NO Ian Lynagh ig...@earth.li**20100422160416] [Fix Trac #3950: unifying types of different kinds simo...@microsoft.com**20100412151845 Ignore-this: d145b9de5ced136ef2c39f3ea4a04f4a I was assuming that the unifer only unified types of the same kind, but now we can defer unsolved constraints that invariant no longer holds. Or at least is's more complicated to ensure. This patch takes the path of not assuming the invariant, which is simpler and more robust. See Note [Mismatched type lists and application decomposition] ] [Fix Trac #3943: incorrect unused-variable warning simo...@microsoft.com**20100412151630 Ignore-this: 52459f2b8b02c3cb120abe674dc9a060 In fixing this I did the usual little bit of refactoring ] [Convert boot and boot-pkgs to perl Ian Lynagh ig...@earth.li**20100415143919 This stops us having to worry about sh/sed/... portability. ] [Use $(MAKE), not make, when recursively calling make Ian Lynagh ig...@earth.li**20100415121453] [Update the user guide so it talks about the newer do rec notation everywhere Ian Lynagh ig...@earth.li**20100416205416 Some of the problems highlighted in trac #3968. ] [Fix typo Ian Lynagh ig...@earth.li**20100416205412] [Implement try10Times in Makefile Ian Lynagh ig...@earth.li**20100420165909 Avoid using seq, as FreeBSD has jot instead. ] [Give the right exit code in darcs-all Ian Lynagh ig...@earth.li**20100421171339 Our END block was calling system, which alters $?. So now we save and restore it. ] [TAG old-time 1.0.0.4 release Ian Lynagh ig...@earth.li**20100422124334] Patch bundle hash: fcf362722a7a7aa3c874e458349988857690c5e4 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. http://hackage.haskell.org/trac/ghc/ticket/4012 Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote: On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. In general changes can creep in randomly, there's no direct link between changing the bootstrap compiler and getting different compilation results (as far as I know), but there are some small elements of randomness. Oh, I confused those two problems again :-( But memories come back, and IIRC the problem with the bootstrapping compiler is caused by the Booter version (as printed by ghc --info) passed up to the stage2 compiler. Wasn't the plan (about a year ago) to remove this? If time permits, I'll send a patch in a few days, but I first have to follow the switch to git, and I also want to update our (OpenBSDs) ports to ghc-7.0.3 and hp-2011.2. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
System.Posix.Signals weirdness
Hi, I'd expect the following program (compiled with ghc and without any specieal flags) to produce Just (Exited ExitSuccess) True but it produces Just (Exited ExitSuccess) False on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current (ghc=7.0 from the 7.0 branch). module Main where import Data.IORef import System.Posix.Process import System.Posix.Signals import System.Posix.Unistd main = do caughtCHLD - newIORef False installHandler sigCHLD (Catch $ writeIORef caughtCHLD True) Nothing pid - forkProcess $ sleep 2 return () s - sleep 8 getProcessStatus False False pid = print readIORef caughtCHLD = print The sigCHLD handler is never called in this program. Is this expected behaviour? If so, why? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.2 Release Candidate 1
Hi, On Thu, Dec 16, 2010 at 06:36:55PM +, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc1/ Some random notes for OpenBSD: - No close look at the test suite results yet, but at least I didn't notice any strangeness like the threading problems back in ghc-6.12. - BTW: it would be nice if snapshot sources or at least release candidate sources would also contain a tarball of the testsuite. I don't know about other distributors, but at least for OpenBSD we're including the testsuite into the files to download; I rolled my own testsuite-7.0.1.20101215.tar.bz2 from the darcs repo, but that's a little bit inconvenient ;-) - After working on updates of several Haskell packages and programs in the OpeNBSD ports tree, I didn't notice anything bad (at least not related to GHC). No strange compiler errors, no strange threading problems (as we had with early ghc-6.12 versions). - Probably a stupid one: the module list in .../html/libraries/index.html) is completely empty. This may be (and probably is) some breakage local to my machine, but: is anyone else seeing this? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] haskell.org migration complete
On Fri, Dec 03, 2010 at 12:48:58AM +0100, Claus Reinke wrote: Beginning this week, the majority of mails from haskell.org lists seem to end up in my ISP's spam filter. That would be Yahoo! - I wonder whether others here have seen a similar effect when checking their spam filters? That's provider stupidity. [...] So it might be related to the new server. Is whitelisting something the mailing list hosting service should deal with, or is that left to the customer? To the customer. Think about it for a minute. What if you want to run a mailinglist, and gazillions of mail providers start bouncing (or even just quarantining, without you even noticing) mails from your list server? Or even some complain about too many rcpt-to entries, whereas others complain about too many consecutive connections (which happens if you reduce the number of recipients per smtp session to mitigate the former problem)? Ciao, Kili ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Fixing LDAP lib compilation on OpenBSD
On Sat, Oct 30, 2010 at 07:28:40PM +0200, Julien Dessaux wrote: I'm using the LDAP lib for one of my projects and I found a problem while building it on an OpenBSD system. It wouldn't compile because there is a macro named differently in the ldap.h include file. Under linux, this macro is named LDAP_X_PROXY_AUTHZ_FAILURE but on OpenBSD (and probably other BSD flavours), it's named LDAP_PROXY_AUTHZ_FAILURE. I attached the diff I wrote in order to compile the lib on OpenBSD, but it's not a patch I can submit cause it now won't compile on Linux. How can I amend this in order to have a code that would compile on both systems? How is it possible to specify such conditional system dependent stuff for a C binding? You can use different CC-Options in LDAP.cabal depending on the OS. For example if os(openbsd) CC-Options: -DLDAP_X_PROXY_AUTHZ_FAILURE=LDAP_PROXY_AUTHZ_FAILURE else CC-Options: -DLDAP_DEPRECATED=1 Or, if LDAP_X_PROXY_AUTHZ_FAILURE is only used on Linux, just do it reverse, i.e. patch the sources to use LDAP_PROXY_AUTHZ_FAILURE and conditionally define it as LDAP_X_PROXY_AUTHZ_FAILURE on Linux; whatever fits better. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Haskell Platform, Hackage and Cabal : The 2nd Year : Status Report
On Fri, Oct 01, 2010 at 09:29:32PM +0100, Malcolm Wallace wrote: The slides are here: http://donsbot.wordpress.com/2010/10/01/hackage-cabal-and-the-haskell-platform-the-second-year/ And the video is here: http://www.vimeo.com/15462768 And is there any way to just *download* the video? For people not using adobe flash? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Introducing The Monads Presentation Slides
On Fri, Sep 17, 2010 at 12:54:29PM -0500, aditya siram wrote: Slides shared and Reddited! Feedback is very welcome! http://www.reddit.com/r/haskell/comments/dfazp/introducing_the_monads_a_practical_tour_of/ Oh, come on. A site where you need a flash player to download (or view) a PDF? This is the most stupid concept I've seen in the last 24 hours. Ciao, Kili ps: if you mail your pdf (as an attachment) to k...@dead-parrot.de, I'll put it online for download there. -- Die Umwelt verlangt von den Jugendlichen ja gar nicht mehr, lesen zu können. Da sind nur noch Bilder, Comics. -- Walter Tomann, Erziehungswissenschaftler, in der Sendung Hintergrund Politik zur PISA-Studie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
On Fri, May 28, 2010 at 10:05:36PM +0100, Simon Marlow wrote: hReady002(ghci) == did not investigate yet. failure details below This one is a known failure right now (I need to clean it up). Good to know. Thanks for the info. num009(normal,optc,hpc,optasm,ghci) == no idea. failure details below Suspicious... If in doubt, suspect OpenBSD here; this is not the first time I've seen strange differences between our math and the math on other systems. But it's reall strange that there are different failures for different ways. I'll try to find what's going on. signals002(normal,optc,hpc,optasm,ghci) == wrong exit code (150, expected 0). not yet investigated. Could be that signals are being delivered too quickly and overflowing the IO manager's pipe. We see this failure on our x86/Linux box too, but not on x86_64. Summary: if it's lost signals due to the pipe filling up, it's a known issue. Also good to know. I'll have a closer look wether it's the problem you mention (but I'm still short of time, so this may have to wait). As always, please don't let any problems specific to OpenBSD delay your release. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
On Sun, May 23, 2010 at 07:42:21PM +0100, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 6.12.3: [...] Please test as much as possible; bugs are much cheaper if we find them before the release! Here are some test results on OpenBSD/amd64, with an 800 MB data size liimit and with pthread support disabled (several people had serious trouble with pthread support enabled for ghc-6.12.2, so I disabled it in our port until I've time to debug that problem). I've used the ghc-6.12 branch from the darcs repository for it; a build with the official release candidate (plus the --with-gmp-* patch recently pushed) is still running. Executive summary: looks quite good. The only failure that *really* puzzles me is the num009 one. I've added some remarks to the list of unexpected failures below. OVERALL SUMMARY for test run started at Thu May 27 19:11:36 CEST 2010 2383 total tests, which gave rise to 7689 test cases, of which 0 caused framework failures 1605 were skipped 5872 expected passes 178 expected failures 0 unexpected passes 34 unexpected failures Unexpected failures: concprog001(ghci) == out of memory (probably harmless) getUserEntryForName(normal,optc,hpc,optasm,ghci) == known (by me) issue. probably a bug/incompatibility in OpenBSD hClose003(normal,optc,hpc,optasm,ghci) == did not investigate yet. failure details (for the normal way) below hReady002(ghci) == did not investigate yet. failure details below num009(normal,optc,hpc,optasm,ghci) == no idea. failure details below openFile008(normal,optc,hpc,optasm,ghci) == too many open files. limits were too tight on my system, I'll have to retest with higher limits queryfdoption01(normal,optc,hpc,optasm) == unsupported operation. rings a bell here, I'll look at it next weekend signals002(normal,optc,hpc,optasm,ghci) == wrong exit code (150, expected 0). not yet investigated. simpl015(optc,optasm) == out of memory (in the compiler). (probably harmless) testblockalloc(normal) == out of memory. (probably harmless) Details: = hClose003(normal) 1002 of 2383 [0, 1, 0] cd ./lib/IO '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o hClose003 hClose003.hs -package unix hClose003.comp.stderr 21 cd ./lib/IO ./hClose003/dev/null hClose003.run.stdout 2hClose003.run.stderr Actual stdout output differs from expected: --- ./lib/IO/hClose003.stdout.normalisedThu May 27 19:35:14 2010 +++ ./lib/IO/hClose003.run.stdout.normalisedThu May 27 19:35:14 2010 @@ -1,4 +1,4 @@ Right () False -Left file descriptor: X: hClose: resource vanished (Broken pipe) +Right () False *** unexpected failure for hClose003(normal) = hReady002(ghci) 1015 of 2383 [0, 6, 0] cd ./lib/IO sleep 1 | '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output hReady002.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS hReady002.genscript 1hReady002.interp.stdout 2hReady002.interp.stderr Actual stderr output differs from expected: --- /dev/null Thu May 27 19:35:59 2010 +++ ./lib/IO/hReady002.run.stderr.normalisedThu May 27 19:35:59 2010 @@ -0,0 +1 @@ +hReady002: stdin: hWaitForInput: end of file *** unexpected failure for hReady002(ghci) = num009(normal) 1072 of 2383 [0, 12, 0] cd ./lib/Numeric '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o num009 num009.hsnum009.comp.stderr 21 cd ./lib/Numeric ./num009/dev/null num009.run.stdout 2num009.run.stderr Actual stdout output differs from expected: --- ./lib/Numeric/num009.stdout.normalised Thu May 27 19:39:12 2010 +++ ./lib/Numeric/num009.run.stdout.normalised Thu May 27 19:39:12 2010 @@ -1 +1,6 @@ +tanf +-Infinity +NaN +(-8388608,105) +(-12582912,105) Done *** unexpected failure for num009(normal) = num009(optc) 1072 of 2383 [0, 13, 0] cd ./lib/Numeric '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o num009 num009.hs -O -fvia-C num009.comp.stderr 21 cd ./lib/Numeric ./num009/dev/null num009.run.stdout 2num009.run.stderr Actual stdout output differs from expected: --- ./lib/Numeric/num009.stdout.normalised Thu May 27 19:39:13 2010 +++ ./lib/Numeric/num009.run.stdout.normalised Thu May 27 19:39:13 2010 @@ -1 +1,6 @@ +tanf +NaN +NaN +(-12582912,105) +(-12582912,105) Done *** unexpected failure for num009(optc) = num009(hpc) 1072 of 2383 [0, 14, 0] cd ./lib/Numeric '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o num009
Re: Output character encoding for ghc on OpenBSD
On Mon, Apr 19, 2010 at 02:57:00PM +0100, Simon Marlow wrote: A few of the tests in the test suite assume a UTF-8 locale, so you're probably falling foul of that. We could fix the tests - but we do want to test that the locale encoding is being respected in some way, so just adding hSetEncoding to those tests would be wrong. Nah, don't touch the tests because of this. For the IO library, I expect you should default the encoding to Latin-1 on OpenBSD. I've some (rather horrible) patch that tries to make sense out of LC_ALL or LC_CTYPE if set. And if it isn't set, I'm currently defaulting to 646//TRANSLIT (which is ASCII with translation of some non-ASCII characters to ASCII art, like `(c)' for \xa9). But Latin-1 may be a more usable default. Thanks for the suggestion. (No, I'm not going to send this patch to cvs-ghc, it's really too horrid). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Output character encoding for ghc on OpenBSD
Hi, as some of you may know, I'm working on an update of OpenBSDs ghc port to 6.12.2, currently chasing down the last remaining testsuite failures. Yesterday, I ran into a problem which I have a fix for, but only a really ugly fix, and I need some opinions of what users would prefer. The problem is that Haskell uses unicode characters internally (ghc itself uses UTF-32 internally, where the endianess depends on the architecture it's running on), and that any Haskell program (including ghc and ghci) has to convert between the internal representation and the actual locale settings of the system it's running on. Unfortunately, OpenBSD is really bad if it comes to locale support; the only supported locales are the C and the POSIX locales, so even if you set LC_ALL or LC_CTYPE to something like, for example, de_DE.iso88591, this would have no effect on OpenBSD. Anyway, the short story is that I have to either hard-code the character set to something like utf-8, or ghc will start to behave really strange (for example, ghci would terminate immediately if you just *type* a non-ASCII character). So what would you prefer? - Use utf-8 and only utf-8 (i.e. hardcoded)? - Use something like iso-8859-15 (hardcoded)? - Make it configurable via some non-standard environment variable (GHC_CODESET, for example). If so, what should be the default if the environment variable isn't set? Back to 7 bit (ASCII)? utf-8? Some of the latin variants? Your suggestions are appreciated. Thanks in advance. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Output character encoding for ghc on OpenBSD
Hi, On Sun, Apr 18, 2010 at 10:53:22AM -0700, Judah Jacobson wrote: Anyway, the short story is that I have to either hard-code the character set to something like utf-8, or ghc will start to behave really strange (for example, ghci would terminate immediately if you just *type* a non-ASCII character). That sounds like it might be something to do with the haskeline package, which ghci uses for user interaction. Haskeline makes its own FFI calls to translate raw input bytes into Unicode Chars. Oh, this may indeed be a second problem. However, the encoding problem itself also manifests in the `openTempFile001' test of the testsuite. For example, with an unpatched ghc-6.12, the test fails with the following output: = openTempFile001(normal) 1048 of 2375 [0, 38, 0] cd ./lib/IO '/usr/obj/ports/ghc-6.12.2/ghc-6.12.2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o openTempFile001 openTempFile001.hsopenTempFil e001.comp.stderr 21 cd ./lib/IO ./openTempFile001/dev/null openTempFile001.run.stdout 2openTempFile001.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: openTempFile001: ./test22236.txt: hClose: invalid argument (Illegal byte sequence) *** unexpected failure for openTempFile001(normal) Can you elaborate further on what exactly the issue is with OpenBSD's locale support? In particular, there's several components used by Haskeline: - call set_locale(LC_CTYPE) Problem number 1: set_locale(LC_CTYPE) fails (i.e. returns NULL) for any locale except `C` or `POSIX'. Did I mention that OpenBSD is really bad with locales? ;-) - call nl_langinfo(CODESET) Always returns `646' (ASCII). Duh. - pass the resulting string (which should be, e.g., $LANG) to iconv_open iconv_open appears to need the *codeset* name, not a complete locale. Note that OpenBSD uses GNU libiconv-1.13, which AFAIK differs from the one included in glibc. Even worse, I have to pass something like UTF-8, whereas UTF8 doesn't work. - call iconv on user input (which may be malformed) I wrote a little C program that does the following (some error checks omitted here): char *inp, outp; size_t insz, outsz; unsigned char in[] = {0xa9, 0, 0, 0}; char out[512]; inp = in; outp = out; insz = sizeof(in); outsz = sizeof(out) - 1; setlocale(LC_CTYPE, ); ic = iconv_open(, UTF-32LE); if (iconv(ic, inp, insz, outp, outsz) == -1) { ... bail out (perror() etc.) ... } iconv_close(ic); *outp = 0; puts(out); And it just doesn't work, regardless what I set LC_CTYPE to. The only way to get it printing the copyright symbol is to explicitely use UTF-8 (or ISO-8859-1 or something else that knows about that symbol) as the first argument to iconv_open(). Is the problem that setting $LC_ALL or $LANG has no effect on the string returned by nl_langinfo, so the translation fails? Yes, see above. If so, haskeline is supposed to output ?s in that case, so there might be a bug in the package. It fails (or rather: ghci fails, since I didn't yet do any separate haskeline tests) with the same error as the test mentioned above, with the difference that it fails on hPutChar instead of hClose for obvious reasons. Finally, when you say you have to hard-code the character set, are you talking about ghc, haskeline, the base library, or somewhere else? I'm talking about libraries/base/GHC/IO/Encoding/Iconv.hs See? There just is no non-hackerish way to fix this (except of course improving locale support on OpenBSD, but that's beyond my scope currently). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.12.2 Release Candidate 1
On Fri, Apr 16, 2010 at 04:02:03PM +0900, Jens Petersen wrote: Just for the record let me report the following build failure for f14 (rawhide): http://koji.fedoraproject.org/koji/taskinfo?taskID=2107186 [...] I have reproduced this now also with ghc-6.12.1 inplace/bin/ghc-stage1 -prof -H32m -O-package-name base- ^ Here! -hide-all-packages -i -ilibraries/base3-compat/. [...] libraries/base3-compat/Data/IORef.hs:1:0: Bad interface file: libraries/base3-compat/dist-install/build/Prelude.p_hi Something is amiss; requested module base-:Prelude differs from name found in the interface file base-3.0.3.2:Prelude make[1]: *** [libraries/base3-compat/dist-install/build/Data/IORef.p_o] Error 1 make: *** [all] Error 2 [...] What should one make of Something is amiss; requested module base-:Prelude differs from name found in the interface file base-3.0.3.2:Prelude here when building ghc?? I don't know why, but for some reason something's going wrong with creating libraries/base3-compat/dist-install/package-data.mk, which *should* contain the correct version number (i.e. libraries/base3-compat_dist-install_VERSION = 3.0.3.2). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testing 6.12.2-pre
On Wed, Apr 14, 2010 at 08:44:29PM +0200, Matthias Kilian wrote: module Main(main) where import System.IO import System.Process main = do hin - openBinaryFile /dev/null ReadMode hp - runProcess /bin/ls [-l] Nothing Nothing (Just hin) Nothing Nothing r - waitForProcess hp print r IF I run this on OpenBSD (amd64), I get foo: /bin/ls: runProcess: unsupported operation (Operation not supported by device) I found it. I'll send a patch as soon as I've tested the fix. The neat thing is that darcs send probably doesn't work without the fix ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testing 6.12.2-pre
On Fri, Apr 09, 2010 at 05:48:17PM +0400, Serge D. Mechveliani wrote: I have tested ghc-6.12.1.20100330 on Debian Linux, i386-family, on the DoCon test, without profilig. It looks all right. Even if I reported to Ian that everything is fine on OpenBSD, I just found some strangeness with openBinaryFile and runProcess when testing darcs-2.4 built with the (still not really released) ghc-6.12.2. Here's a small test program: module Main(main) where import System.IO import System.Process main = do hin - openBinaryFile /dev/null ReadMode hp - runProcess /bin/ls [-l] Nothing Nothing (Just hin) Nothing Nothing r - waitForProcess hp print r IF I run this on OpenBSD (amd64), I get foo: /bin/ls: runProcess: unsupported operation (Operation not supported by device) Tracing the process shows the following hints (File handle 0x6 is the one from /dev/null): 25151 foo CALL ioctl(0x6,TIOCGETA,0x7f7e1da0) 25151 foo RET ioctl -1 errno 19 Operation not supported by device 25151 foo CALL fcntl(0x6,0x4,0x4) 25151 foo RET fcntl -1 errno 19 Operation not supported by device I'm not sure about the ioctl call, but the fcntl tries to set the handle to nonblocking mode. There's already some comment about this (on FreeBSD) in the code, but I'm unsuere what exactly to do about it. I'd really like to see the result of this program on FreeBSD and/or NetBSD, so we know wether it's specific to OpenBSD or wether it happens on all BSD-like systems. Ciao, Kili ps: GHC guys, please don't let this stop you from going on with the ghc-6.12.2 release process. Problems like this can be easily fixed by package maintainers. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Are there any female Haskellers?
On Sun, Mar 28, 2010 at 01:14:44PM -0700, Jason Dagit wrote: And as Luke Palmer suggests, perhaps you can ignore/filter these discussions that you do not enjoy :) Or just unsubscribe, like I did. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
Hi, On Fri, Mar 05, 2010 at 01:16:18AM +0300, Bulat Ziganshin wrote: [...] The SFLC holds that a library that depends on a GPL'd library must in turn be GPL'd, even if the library is only distributed as source and not in binary form. Was this a general statement yes. it's soul of GPL idea, and it's why BG called GPL a virus :) Oh, BSD3 or ISC licensed code is viral as well, but only on the source code level ;-) (if you redistribute the sources, you have to leave the license and the copyright marker intact) Anyway, I really think the SFLC people are telling lies here (or, as someone else wrote in this thread, are telling what they whish the GPL to imply). Applying some common sense tells me: If you write some code (library or program) that depends on some GPL licensed library, you can still redistribute your *source code* under whatever license you want, as long as your source code distribution does not contain copies (original or modified) from the GPL'd stuff it depends on. For binary products created from such a library combo, you have to apply the GPL, which should be fine if *your* code is BSD3 or ISC or something similar. But nobody can force you to apply a specific license to your *source code*, even if the binary (links against/calls functions provided by) a GPL'd library. Oh, and for the discussion about wether APIs may be license-worth, which also popped up in this thread; /* * Copyright (c) 2010 Matthias Kilian k...@outback.escape.de * * All rights reserverd. */ extern int foo(double bar); If you ever dare to write some C function `foo' that takes a double and returns an int, I'll sue you to death ;-) Yes, there are APIs more inventive than that example above, but they're just *interfaces*. There has to be a lot of brain used on some interface to make it a creative work. (Oh, monads jump to mind) Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
On Thu, Mar 04, 2010 at 11:34:24AM -0600, Tom Tobin wrote: [...] The SFLC holds that a library that depends on a GPL'd library must in turn be GPL'd, even if the library is only distributed as source and not in binary form. Was this a general statement or specific to the fact that (at least GHC) is doing heavy inlining? Anyway, I think the SFLC is the wrong institution to ask, since they're biased. Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] listing mountpoints and getting their properties in Haskell
On Sat, Feb 27, 2010 at 06:27:19PM -0500, Brandon S. Allbery KF8NH wrote: I don't know of any Haskell bindings offhand, but getmntent() and friends are the standard library interface for identifying mountpoints and statfs()/statvfs() are the interface for getting information about them. Be aware that the latter can be fairly system-dependent. getmntent() isn't in any standard I know about. IMHO, getting information about mounted filesystems will always be system dependent. Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: cross-compiling ghc to openbsd
On Fri, Jan 29, 2010 at 06:10:52PM +0100, Nicolas Martyanoff wrote: I'm trying to cross-compile GHC as follows: Host: Linux, x86_64, GHC 6.12.1 Target: OpenBSD 4.6 stable, i386 IMHO, you shouldn't go that way, because it adds much more complexity than you already have with OpenBSD as host *adn* target. During my last tests back in december, not even OpenBSD/i386 - OpenBSD/i386 worked with .hc files. That should be fixed first. Then, something like OpenBSD/i386 - OpenBSD-amd64 (and vice versa) should be done. And if this works, it's questionable wether one should work on cross building with .hc files using differen host an target operating systems or wether it would be more useful to start getting GHC running on other OpenBSD archs. I follow the guide at: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran the following commands: export AUTOCONF_VERSION=2.62 export AUTOMAKE_VERSION=1.9 cp /bin/pwd utils/ghc-pwd/ghc-pwd sh boot ./configure --enable-hc-boot --build=i386-unknown-openbsd --host=i386-unknown-openbsd --target=i386-unknown-openbsd [...] IIRC there where some discussions (or even patches pushed?) about the build/host/target combo, so you may try to pull ghc sources with darcs (head or the 6.12 branch). The latest fails, with the following trace: http://pastebin.ca/1770926 The following errors are quite interesting: includes/stg/Types.h:103:2: #error GHC untested on this architecture: sizeof(void *) != 4 or 8 includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P Your build is (re)creating includes/ghcautoconf.h -- this looks very wrong to me, since ghcautoconf.h is supposed to be created by a former configure / make bootstrapping-files on the target platform and then used on the host for creating the .hc files. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross-compiling ghc to openbsd
On Fri, Jan 29, 2010 at 09:42:27PM +0100, Nicolas Martyanoff wrote: This probably means some type identifier used at that point hasn't been declared, or macro defined or whatever. You'd have to see what it is, and maybe it will be more obvious what went wrong. It seems that SIZEOF_VOID_P isn't defined anywhere. It's defined in includes/ghcautoconf.h (which is created during configure and make bootstrapping-files on the target platform). All right, I'll try again with the last darcs version when I get access to a i386 Linux machine. You don't need any linux machine for this. The current darcs port for OpenBSD may be a little bit outdated, but it still works. In the mean time, I'll try to run a GHC 6.6 - 6.10 - 6.12 build chain, 6.6 being the latest version available in OpenBSD's ports. I sent you a (admittedly horrible) script to do this chain. Use it. If it doesn't work, sent complaints. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC 6.10.* on OpenBSD
On Sat, Dec 12, 2009 at 05:30:44AM +0200, Thanos Tsouanas wrote: Up to now I've only used binary versions of GHC, but since my operating system's (OpenBSD) version of GHC is lagging behind (currently at 6.6.1), I need to update it. I tried using my system's ghc-6.6.1 to compile ghc-6.10.4 but it failed due to haskeline not being installed (and trying to install it also failed). I don't know wether the release tarball contains haskeline, but you could always download the sources via darcs and use the darcs-all script from the ghc tree to fetch all necessary libraries. Here are some scripts I'm using to build all kinds of ghc versions (6.10, 6.12, head, bootstrapping stuff etc.): http://darcs.volkswurst.de/build/ You may have to edit the scripts for your purposes. Or just wait for an update of the port ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC 6.10.* on OpenBSD
On Sat, Dec 12, 2009 at 09:22:56AM +0100, Karel Gardas wrote: I somehow managed to first install everything what's required on system provided 6.6.1 to compile 6.10. I'm not sure if I went step by step 6.6.1-6.8.3-6.10.3 as you try. No need for 6.8, you can build 6.10 straight with 6.6. IMHO cross-compilation is no go in this case since I hope I'm right assuming this is not supported in 6.10, but was fixed in 6.12 again. Kind of. There are still issues with *real* porting to other platforms (#3472, probably more), but it's possible to create hc bootstrapping filesets and use them to bootstrap on the same platform. Even if this sounds kind of useless, it'll help a lot updating the OpenBSD port. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC 6.10.* on OpenBSD
On Sat, Dec 12, 2009 at 03:29:09PM +0200, Thanos Tsouanas wrote: No need for 6.8, you can build 6.10 straight with 6.6. Ok, I guess I didn't try hard enough.. Probably just --with-iconv-includes=/usr/local/include \ --with-iconv-libraries=/usr/local/lib missing to ./configure. Everything else should work fine nowadays. IMHO cross-compilation is no go in this case since I hope I'm right assuming this is not supported in 6.10, but was fixed in 6.12 again. Kind of. There are still issues with *real* porting to other platforms (#3472, probably more), but it's possible to create hc bootstrapping filesets and use them to bootstrap on the same platform. Even if this sounds kind of useless, it'll help a lot updating the OpenBSD port. Then it's worth a shot. How would I create those hc bootstrapping filesets? Using the system's ghc-6.6.1? If all you want is a working ghc-6.10, please don't waste your time with bootstrapping filesets. Just use ghc-6.6.1 and build ghc-6.10 from it (and, if you want to, build ghc-6.12 from ghc-6.10). BTW: if you're using my scripts, you'll probably also have to install (apart from ghc-6.6.1) alex, darcs, gmake, haddock, happy, hscolour and python (version 2.5). All available as precompiled packages for OpenBSD (amd64 and i386). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling to ANSI C
On Sun, Nov 08, 2009 at 10:19:26AM +0300, Bulat Ziganshin wrote: seems that wizards are on holiday ATM, so i will help a little - ghc ports are divided into registerized (working with cpu registers) and unregisterized (just a C code generated). I wouldn't touch the *registerized* variant using intermediate C files, because that means you probably would also have to modify the evil mangler, which is -- evil. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Haskell Weekly News
On Fri, Oct 09, 2009 at 05:46:15PM +0900, Benjamin L.Russell wrote: 2) Instead of posting separately to the Haskell and Haskell-Cafe mailing lists, it might be better to cross-post, since that way, readers using newsreaders can have the cross-posted article automatically marked read in the mailing list where it has not been read. That may be my fault -- I suggested to send out the HWN in separate mails to simplify the sending scripts. Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (mostly OT) Strange patterns of commas
Fibonacci numbers are always surprising. Try this on a terminal that's 159 characters wide (using a properly sized xterm(1) may be a good idea): let f = 1 : 1 : zipWith (+) f (tail f) in take 780 f Ciao, Kili -- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: no-Haddock GHC build
On Tue, Sep 22, 2009 at 07:34:53AM -0700, Donn Cave wrote: I'm thinking it would be expedient to omit Haddock while building a ghc 6.11 snapshot, per bug ticket #3531 From my basic understanding of its purpose there, that ought to work out fine - I mean, not to undervalue documentation, but the compiler should be able to function without it. But not well versed in the intricacies of the GHC build, so please set me straight if I'm about to waste a lot of time untangling it in the makefiles. I sent a patch for this to cvs-ghc@: http://www.haskell.org/pipermail/cvs-ghc/2009-September/050255.html I wasn't even aware of that ticket ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
On Thu, Sep 17, 2009 at 09:17:35AM +0100, Simon Marlow wrote: Glad you got it going. I notice there are a few test failures, many of which could be fixed easily, e.g. --- ./lib/IO/hClose002.stdout.normalisedWed Sep 16 14:08:09 2009 +++ ./lib/IO/hClose002.run.stdout.normalisedWed Sep 16 14:08:09 2009 @@ -1,4 +1,4 @@ -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) +Left hClose002.tmp: hClose: invalid argument (Bad file number) Right () Right () Right () *** unexpected failure for hClose002(normal) that just needs a platform-specific expected output file (hClose002.stdout-i386-unknown-solaris2). BTW: is there an easy way to do some general output filtering on *all* tests for different platforms? It may not be helpful for the above test, but for some differences (like stderr in case of several types of core dumps on different operating systems, or the typical linker warnings about strcat(3), strcpy(3) etc. on OpenBSD) it may be less maintainance work to filter or modify the output on specific platforms. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
On Wed, Sep 16, 2009 at 10:23:58AM +0200, Karel Gardas wrote: Before going to trace anything I've compared sparky and my setup and it seems I've had forgotten libiconv library in /usr/local/lib and LD_LIBRARY_PATH contained this lib. So I've modified LD_LIBRARY_PATH to exclude /usr/local/lib and now surprisingly base configure fails with: checking for library containing iconv... no configure: error: iconv is required on non-Windows platforms make[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 Running the build bot with ICONV_INCLUDE_DIRS=/usr/local/include ICONV_LIB_DIRS=/usr/local/lib in the environment fixes the iconv problems, at least on OpenBSD. (I need some more environment tweaks but that's really related to my OS) Ciao, Kili -- Manch Massenmörder macht auch immer mal gern einen Abstecher. -- Dieter Brügmann in dtjd, 20.2.2001 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] (weird stuff) Kernel Modules in Haskell ;-)
A fellow openbsd developer told me the URL below... I hope this hasn't been posted on this list already (at least I didn't find it in my local archives): http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ Ciao, Kili -- Logging should be in debug mode only. If every network driver did a dmesg printf everytime they came up, would that be a better world? -- Theo de Raadt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Plans for GHC 6.12.1: release candidate 14 September 2009
On Tue, Aug 18, 2009 at 03:03:43PM +0100, Ian Lynagh wrote: This is a summary of our plans for GHC 6.12.1. We are aiming to have the first release candidate out on the 14th September 2009. Until then, we plan to focus on the bugs in the 6.12.1 milestone, marked high priority; they are listed here: http://hackage.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedpriority=highestpriority=highmilestone=6.12.1order=priority Would it be better if I break my stable build slave in favor of the head build slave then? IIRC, I've to tweak some environment variables to make head build again, but it would break the stable builds. Ciao, Kili -- _|_ is pronounced 'bottom', and is the greatest lower bound of a complete lattice. -- Nick Williams in comp.lang.functional ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: use gtar and not tar under solaris
On Thu, Aug 06, 2009 at 12:30:51PM +0100, Duncan Coutts wrote: I've just been informed that unpacking the binary (i386) solaris distribution using bunzip2 and tar: It may work better in future if you use a non-GNU tar to pack it up in the first place. GNU tar uses a non-standard tar format by default. Solaris tar would likely have more luck unpacking a POSIX/USTAR tar format file. It's also possible to use gnu tar to make standard tar format files, using --format ustar rather than gnu tar's default of --format gnu. Is there something like pax(1) available on solaris? If so, it should be be preferred, because it's a POSIX tool, so there's some hope that it behaves the same on different systems. pax(1) should be available on all BSD systems, and to my knowledge, there's a pax package available at least for Debian Linux. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: use gtar and not tar under solaris
On Thu, Aug 06, 2009 at 08:54:49PM +0200, Christian Maeder wrote: Is there something like pax(1) available on solaris? If so, it should be be preferred, because it's a POSIX tool, so there's some hope that it behaves the same on different systems. Yes, pax is available under solaris. I thought GNU tar is the standard packer under unix. Depends on what `standard' means ;-) - tar has been there forever on unices, with several slightly incompatible format extensions - GNU tar is just another implementation, typically used on Linux, and it has its own incompatible format extensions. - pax is (or should be) available everywhere, its behaviour is defined by POSIX, it should (by default) create archives readable by most tar implemenations, but almost nobody knows about it ;-) http://www.opengroup.org/onlinepubs/9699919799/utilities/pax.html I wonder wether Duncan did read and understood that bit of documentation, I didn't even read all of it ;-) (The usage message of pax is less clear.) The manpage (and of course the POSIX definition) are hard stuff, too. However, to create an archive, you can use something like $ pax -wf foo.tar directory Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.10.3-prerelease failed build log for freebsd7.2
On Wed, May 06, 2009 at 08:48:04PM +0100, Ian Lynagh wrote: H Kili, On Mon, May 04, 2009 at 09:36:00PM +0200, Matthias Kilian wrote: In your case, it doesn't find libiconv, thus isn't built, and causes failure later. In my case (a buildbot running OpenBSD-4.5 on i386), the haskeline build itself fails (see `kili-stable' on darcs.haskell.org/buildbots), Is iconv installed somewhere on that machine? If so, where is it? (both the library and the header file) Binary in /usr/local/bin/iconv, library in /usr/local/lib, header in /usr/local/include. The strange thing isn't that it isn't detected correctly (linking is done a little bit differently on OpenBSD, you have to explicitely specify depending libs), but that the overall build doesn't fail on my fast build machine at home (which i still have to turn into a buildslave) Anyway, i'll look into this next weekend. Don't hold back the release because of this. For FreeBSD, there should be no problem to add some small patches (or probably just some additional arguments to configure), and for OpenBSD, ir just doesn't matter (because I'll wait for ghc 6.12 with our port). Ciao, Kili -- Automake and autoconf deserve to wither and die, but unfortunately noone at GNU seems to make much of an effort to euthanasize them. -- Han-Wen Nienhuys, on Lilypond-devel mailing list ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.10.3-prerelease failed build log for freebsd7.2
Hi, On Sun, May 03, 2009 at 11:03:49PM -0700, brad clawsie wrote: after some trying, i was unable to get the 6.10.3 prerelease to build on freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. i saved the output of the entire build from ./configure to the point of failure. it is too long too attach here, you can see it at: http://www.b7j0c.org/ghc-6.10.3.log.txt Interesting. haskeline seems to break the build in different ways and at different places (and sometimes it doesn't fail at all). In your case, it doesn't find libiconv, thus isn't built, and causes failure later. In my case (a buildbot running OpenBSD-4.5 on i386), the haskeline build itself fails (see `kili-stable' on darcs.haskell.org/buildbots), but at the same time on OpenBSD-current on an amd64 the haskeline build complains about a missing libiconv but builds nevertheless. This all is a little bit confusing, but it should be fixable by telling configure where to find libivonv (i didn't yet have the time to look what's going on for real here). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Standard C available in cabal package
On Fri, Jan 30, 2009 at 09:40:02PM +0100, Achim Schneider wrote: POSIX? Is that portable for non-unix? I think cabal does work on some non-unix systems. Even windows provides POSIX, it's _the_ C standard. If you are going to find a common set of C functions, that'll be it. Don't expect windows to have a fifo or block file type, though. Sorry, but the standard libraries defined by all the C standards are just a small subset of POSIX. If you want to be portable beyond POSIX compliant systems, you've to stick to something like C99. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: testsuite boot failure [was: Re: Solaris/x86 bot failing on stage2 haddock installation.]
On Sun, Jan 11, 2009 at 10:36:56PM +0100, Karel Gardas wrote: A fix from Conal Elliott has already been pushed by Ian. Indeed! Now compilation aborts on booting testsuite with following output: make: Entering directory `/buildbot/ghc/kgardas/build/testsuite' make: *** No rule to make target `boot'. Stop. make: Leaving directory `/buildbot/ghc/kgardas/build/testsuite' This is strange: $ darcs changes --last=1 Sat Jan 10 22:42:04 CET 2009 Ian Lynagh ig...@earth.li * Add a boot target, and tidy up the Makefile a bit Yet the file in question (testsuite/mk/test.mk) isn't included by testsuite/Makefile nor testsuite/mk/boilerplate.mk. Did I ever complain about how broken the ghc build system is? ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: pthread mutex error building 6.10 on NetBSD
Hi, On Thu, Jan 01, 2009 at 11:46:31AM +0100, Matthias Kilian wrote: pthread_mutex_unlock() is called, evidently from fileLock(), with an invalid mutex. NetBSD's pthread implementation differs from Linux in its intolerance of such things. I have found errors where someone forgets that a mutex was never used and tries to unlock it. I guess you could do that all day long on Linux without noticing anything, but NetBSD aborts the program. In the present case, I don't see anything like that wrong in rts/FileLock.c, though. I'm stumped. So I'm checking, has anyone else built 6.10 on NetBSD? Could you (and anyone else on any operating system using pthreads) please try to build with the patch below? It checks the return values of pthread_mutex_lock() and pthread_mutex_unlock() by default (even if DEBUG isn't defined) and contains some other uncluttering. Seems to work fine here on OpenBSD (for ghc-head), but before I send out a darcs patch, I'd like to see some results on other systems.[1] Of course, the patch won't fix the problem for NetBSD, but it may give some more hints. Ciao, Kili [1] and if you insist in darcs patches, just pull from http://darcs.volkswurst.de/users/kili/ghc-6.10/ghc/ or http://darcs.volkswurst.de/users/kili/ghc/ diff -x _darcs -rNup ../ghc/includes/OSThreads.h ./includes/OSThreads.h --- ../ghc/includes/OSThreads.h Sun Jan 4 22:28:46 2009 +++ ./includes/OSThreads.h Sun Jan 4 22:11:34 2009 @@ -23,6 +23,7 @@ #else #include pthread.h +#include errno.h typedef pthread_cond_t Condition; typedef pthread_mutex_t Mutex; @@ -34,47 +35,26 @@ typedef pthread_key_t ThreadLocalKey; #define INIT_COND_VAR PTHREAD_COND_INITIALIZER #ifdef LOCK_DEBUG +#define LOCK_DEBUG_BELCH(what, mutex) \ + debugBelch(%s(0x%p) %s %d\n, what, mutex, __FILE__, __LINE__) +#else +#define LOCK_DEBUG_BELCH(what, mutex) /* nothing */ +#endif +/* Always check the result of lock and unlock. */ #define ACQUIRE_LOCK(mutex) \ - debugBelch(ACQUIRE_LOCK(0x%p) %s %d\n, mutex,__FILE__,__LINE__); \ - pthread_mutex_lock(mutex) -#define RELEASE_LOCK(mutex) \ - debugBelch(RELEASE_LOCK(0x%p) %s %d\n, mutex,__FILE__,__LINE__); \ - pthread_mutex_unlock(mutex) -#define ASSERT_LOCK_HELD(mutex) /* nothing */ - -#elif defined(DEBUG) defined(linux_HOST_OS) -#include errno.h -/* - * On Linux, we can use extensions to determine whether we already - * hold a lock or not, which is useful for debugging. - */ -#define ACQUIRE_LOCK(mutex) \ + LOCK_DEBUG_BELCH(ACQUIRE_LOCK, mutex); \ if (pthread_mutex_lock(mutex) == EDEADLK) { \ barf(multiple ACQUIRE_LOCK: %s %d, __FILE__,__LINE__); \ } + #define RELEASE_LOCK(mutex) \ + LOCK_DEBUG_BELCH(RELEASE_LOCK, mutex); \ if (pthread_mutex_unlock(mutex) != 0) { \ barf(RELEASE_LOCK: I do not own this lock: %s %d, __FILE__,__LINE__); \ } #define ASSERT_LOCK_HELD(mutex) ASSERT(pthread_mutex_lock(mutex) == EDEADLK) - -#define ASSERT_LOCK_NOTHELD(mutex) \ - if (pthread_mutex_lock(mutex) != EDEADLK) { \ - pthread_mutex_unlock(mutex); \ - } else { \ -ASSERT(0); \ - } - - -#else - -#define ACQUIRE_LOCK(mutex) pthread_mutex_lock(mutex) -#define RELEASE_LOCK(mutex) pthread_mutex_unlock(mutex) -#define ASSERT_LOCK_HELD(mutex) /* nothing */ - -#endif #endif // CMINUSMINUS ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: pthread mutex error building 6.10 on NetBSD
On Wed, Dec 31, 2008 at 10:44:07PM -0800, Donn Cave wrote: I tried to build GHC 6.10.1 on NetBSD 4.0 this afternoon, and ran into an error, where cabal-bin calls the stage2 ghc in utils/installPackage. pthread_mutex_unlock() is called, evidently from fileLock(), with an invalid mutex. NetBSD's pthread implementation differs from Linux in its intolerance of such things. I have found errors where someone forgets that a mutex was never used and tries to unlock it. I guess you could do that all day long on Linux without noticing anything, but NetBSD aborts the program. In the present case, I don't see anything like that wrong in rts/FileLock.c, though. I'm stumped. So I'm checking, has anyone else built 6.10 on NetBSD? Only on OpenBSD, and there it builds fine (when bootstrapping from either ghc-6.6 or -6.10). But what's interesting is that in includes/OSThreads.h the return values of pthread_mutex_lock(3) and pthread_mutex_unlock(3) aren't checked except apparently on Linux when building with DEBUG defined. You could either try to build with LOCK_DEBUG defined, so you see exactly when a lock is acquired and released, or try to build with DEBUG defined and that ` defined(linux_HOST_OS)' removed from OSThreads.h to see what's going wrong. BTW: is there any pthread implementation still in the wild where pthread_mutex_{,un}lock() does NOT indicate a deadlock by EDEADLK? If not, the DEBUG part of OSThreads.h could be used for all systems, not only Linux. Ciao, Kili -- A typo a day, keeps the dictionnary away. -- Miod Vallat ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] The Haskell re-branding exercise
On Sun, Dec 21, 2008 at 01:23:33PM -0800, Don Stewart wrote: Would you be willing to set up a little online voting system (or do you know of one) so we can implement this? Assume there'll be 10 candidates. What about www.doodle.com? Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Time for a new logo?
On Wed, Dec 17, 2008 at 09:34:15PM +, Andrew Coppin wrote: - I very much like the concept of this. It's clean, simple, elegant. Like Haskell! But Haskell isn't Clean. (SCNR) Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal (was: Compilers)
On Fri, Nov 28, 2008 at 08:51:45PM -0800, Jason Dagit wrote: Personally, I look at it this way. Both build systems have different advantages that the other cannot provide but they are not mutually exclusive. I don't see any advantage in Cabal, except that a .cabal file provides some metadata and dependency information that can help the build. Also, the effort to keep them both working for the respective groups of users is rather small in practice. At least in ghc, the mixture of make and Cabal was a huge failure. Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal (was: Compilers)
On Sat, Nov 29, 2008 at 11:31:52AM -0800, Don Stewart wrote: I don't see any advantage in Cabal, except that a .cabal file provides some metadata and dependency information that can help the build. And we have tools to automate the packaging of cabal-specified code. So for example, there are already native packages of LHC, but not of JHC. http://aur.archlinux.org/packages.php?ID=21749 Because of the automatic packaging for cabal-specified software. Oh, maybe I'll write similar tools for OpenBSD ports some day (when I've enough time). Yet I consider this (useful) configuration and dependency information metadata. IMHO, Cabal is nice for specifying this metadata, it maybe nice wrt hackage, some people even may like to just cabal-install something and go ahead, but this are already too much tasks it's trying to fulfill, leaving alone Cabal as a *build* tool. I'm probably biased, because I had so much trouble with ghc and the Cabal/make maze, so I may be a little bit unfair (because ghc's requirements are more complicated than just an ordinary program or library). However, I really believe in the unix philosophy (one tool for one task), and Cabal clearly doesn't follow it. There's an example for a tool capable of dependency and (to a certain degree) configuration management in the java world: ivy (http://ant.apache.org/ivy/). Well, they added a lot of bload since they moved to apache, and of course one could question why everything has to be XML, but the basic idea was: deal with dependencies, add support for repositories containing dependencies in several versions, but nothing more. No build tool, no packaging or install tool. Yes, it's tightly coupled with apache-ant, but if you have an ivy-file, there's nothing stopping you from converting the information contained in this file to some includable makefile snippet. I didn't have a very close look at the ghc-new-build-system yet, but I think the idea here is basically the same: use the .cabal files (and the Cabal library) to generate files that then are used by make(1) to do the real work. I hope that I make at least a little bit sense. The problem I've with Cabal is that it tries to be the swiss army knife of dependency and configuration management, building, packaging and installation, but like those swiss army knifes on steroids (with too much features), it doesn't fit in you pocket any longer. Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On Wed, Nov 26, 2008 at 09:35:01PM +, Andrew Coppin wrote: It is a fork of the JHC compiler, which should be easier to look up. There is also Hugs, as you mentioned. In addition, you may want to look at YHC and NHC. Yeah, the implementations page on the Wiki basically says that there's GHC and Hugs, and there's also these things called YHC, NHC and JHC. All the documentation I've read makes these latter compilers sound highly experimental and unusable. I would't call nhc experimental; it's quite usable, at least for standard Haskell-98 stuff (plus some language extensions). Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Linking error during stage2
On Tue, Nov 11, 2008 at 06:38:02PM +0100, dermiste wrote: I've successfully built GHC-6.10.1 from 6.6.1 on OpenBSD 4.4, and would like now to generate a hc-file-bundle to build it without pre-existing GHC. I followed the instructions in [1], but I'm stuck with this error : Linking dist-install/build/installPackage/installPackage ... /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/unix/dist/build/libHSunix-2.3.1.0.a(Semaphore.o)(.text+0xac): In function `unixzm2zi3zi1zi0_SystemziPosixziSemaphore_zdwa_info': : undefined reference to `sem_trywait' [...] Obviously, the linker skips entirely /usr/lib/libpthread.a, as all the symbols defined in semaphore.h are into it. A quick hack I used for my work on ghc-6.8: just disable System.Posix.Semaphore. --- libraries/unix/System/Posix.hs.orig Sat May 3 19:25:32 2008 +++ libraries/unix/System/Posix.hs Sun May 18 14:37:13 2008 @@ -26,7 +26,6 @@ module System.Posix ( module System.Posix.Time, module System.Posix.User, module System.Posix.Resource, - module System.Posix.Semaphore, module System.Posix.SharedMem ) where @@ -43,7 +42,6 @@ import System.Posix.Terminal import System.Posix.Time import System.Posix.User import System.Posix.Resource -import System.Posix.Semaphore import System.Posix.SharedMem {- TODO --- libraries/unix/unix.cabal.orig Sat May 3 19:25:32 2008 +++ libraries/unix/unix.cabal Sun May 18 13:44:08 2008 @@ -32,7 +32,6 @@ exposed-modules: System.Posix.User System.Posix.Signals System.Posix.Signals.Exts -System.Posix.Semaphore System.Posix.SharedMem extra-source-files: configure.ac configure It's not a proper solution, but it may help for getting the build a little bit farther (and OpenBSD doesn't support sem_open(3) anyway). Ciao, Kili -- It's a Barrier Of Entry issue: if you can't figure out which floppy to boot from, go run Gentoo. -- Matthew Jenove on [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6?
On Wed, Oct 29, 2008 at 12:11:22PM +1100, Trent W. Buck wrote: To my mind, the benefit is negligible, because: Then we still have OpenBSD users. means we can't drop GHC 6.6 support. Also, note that Lenny has 6.8, and it is scheduled to become stable Real Soon Now. Ok, it all depends on when the next release of darcs will be ready and when I (or someone else) gets ghc-6.8 or 6.10 done for OpenBSD (yes, I'm working on this, even after I dropped maintainership from our ghc port). I *hope* to get a working ghc-6.10 port for OpenBSD to the end of this year, and I guess that's a short enough timeline that darcs could drop 6.6 support if it's really necessary. Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6?
Hi, On Tue, Oct 28, 2008 at 10:11:53AM -0700, Jason Dagit wrote: Debian is nice in some ways and it's really great that stable lives up to its name, but I am sad that Debian has such old software for so long. It's this reason that has always forced me to run testing and pull packages from unstable while still building some things from source. I hear things are better in the Ubuntu world. AFAIK, ghc-6.6 is two years old. I wouldn't call this old. Ciao, Kili -- For some reason some communities are using the uptime of a machine as a compensation for something else being small. -- Artur Grabowski (http://www.blahonga.org/~art/diffs/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6?
On Mon, Oct 27, 2008 at 07:24:31PM -0700, Jason Dagit wrote: I would like to find out if any darcs users who build from the source are still using ghc 6.6? If you are such a user, please let me know. Yep. OpenBSD is still at ghc-6.6. Ciao, Kili -- Trust your brain, not the machine. -- Nick Holland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: GHC 6.10.1 beta
On Mon, Sep 29, 2008 at 10:26:35PM +0200, Matthias Kilian wrote: A full test log is available at http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log Same for openbsd-amd64, built from sources pulled from the darcs repository at 15/Oct/2008:13:00:00 +0200: http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-amd64.log OVERALL SUMMARY for test run started at Wed Oct 15 21:07:08 CEST 2008 2252 total tests, which gave rise to 12108 test cases, of which 0 caused framework failures 2301 were skipped 8846 expected passes 128 expected failures 0 unexpected passes 833 unexpected failures And for ghc-head (pulled an hour later): http://openbsd.dead-parrot.de/ghctests/ghc-head-openbsd-amd64.log OVERALL SUMMARY for test run started at Thu Oct 16 12:36:23 CEST 2008 2252 total tests, which gave rise to 12108 test cases, of which 0 caused framework failures 2294 were skipped 8917 expected passes 128 expected failures 0 unexpected passes 769 unexpected failures Most failures are caused by ghci which is still broken for openbsd-amd64. Unfortunately, I don't have enough time to look at the other failures now. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] ANNOUNCE: darcs 2.1.0 (corrected!)
On Thu, Oct 09, 2008 at 05:11:17PM +0100, Eric Kow wrote: This is a correction to my previous announcement. I had misgrepped the ChangeLog. There are only 20 bug fixes and 7 new features since 2.0.2. Nevermind. It's way better than 2.0.2, anyway ;-) Ciao, Kili -- the story in pthread_rwlockattr_destory() shoudl be destroyed -- Otto Moerbeek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: GHC 6.10.1 beta
On Mon, Sep 29, 2008 at 10:46:34AM +0100, Ian Lynagh wrote: BTW: I had some problems running the testsuite some weeks ago, because some autoconf'd stuff was missing. When building from the repository (*not* from the source tarballs), are there any additional steps beyond sh boot ./configure --prefix=... gmake install required? I'm not sure if running gmake install without first running gmake works. Also, note that if you are building the extralibs then you need to run sh boot after getting them. I was sloppy in my mail. Actually I'm even building stage1 and stage2 explicitely before installing. From my script: nice time gmake stage1 nice time gmake stage2 nice time gmake install And my problem with the testsuite was a PEBKAC (of course): on OpenBSD, python is installed as python-2.3, python-2.4, python-2.5 (you can have several versions installed in parallel), which isn't found by configure, which in turn lets the testsuite bail out. Setting PythonCmd during configure fixed it. I've yet to evaluate the results of the testsuite. I'll post it in a few hours. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
On Mon, Sep 29, 2008 at 07:07:33PM +0200, Matthias Kilian wrote: And my problem with the testsuite was a PEBKAC (of course): on OpenBSD, python is installed as python-2.3, python-2.4, python-2.5 (you can have several versions installed in parallel), which isn't found by configure, which in turn lets the testsuite bail out. Setting PythonCmd during configure fixed it. I've yet to evaluate the results of the testsuite. I'll post it in a few hours. Summary (skipping all the details): OVERALL SUMMARY for test run started at Sun Sep 28 17:57:33 CEST 2008 2233 total tests, which gave rise to 12011 test cases, of which 0 caused framework failures 2244 were skipped 9324 expected passes 140 expected failures 20 unexpected passes 283 unexpected failures This looks more scary than it is; many unexpected failures are caused by a change in Rational formatin (17%42 vs. 17 % 42), some others are probably caused by OpenBSD specific stuff (e.g., warnings about the use of unsafe functions like strcpy(3), different output behaviour on signals like SIGSEGV, and, well the unicode (causing unexpected passes) and some threading differences are most probably also OS-dependent candidates). Some problems are not strictly OpenBSD specific, but just triggered due to the more restrictive default limits (number of open file descriptors, datasize, etc.). Finally, some tests just did time out (this isn't the fastest machine in the universe). A full test log is available at http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log And a shorter log (using a really horrible awk script for stripping down the full log): http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.shortlog Fallout from the following tests looks a little bit suspicious: num009 num012 galois_raytrace (well, I didn't read the whol diff ;-)) driver019 (I think a fix for this has been pushed during the last 24 hours) ffi009 tough all the hpc stuff copyFile001 (but there was a push for it recently, IIRC) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
Hi, On Mon, Sep 22, 2008 at 01:35:43AM +0100, Ian Lynagh wrote: We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a beta release of GHC 6.10.1. [...] Please test as much as possible; bugs are much cheaper if we find them before the release! Not quite the beta snapshot, but from HEAD about the same time you tagged and branched, I got the following positive results on OpenBSD/i386: 1) Build it up to stage2 and make install from ghc-6.6: ok 2) The same again with the result of 1): ok 3) Full build including all extralibs with the result of 2): ok I'll restart the whole process with what's in the ghc-6.10 branch now (hopefully that's ok for you, since some fixes have been already committed to the branch), and I'll also try to run the testsuite after step 3). BTW: I had some problems running the testsuite some weeks ago, because some autoconf'd stuff was missing. When building from the repository (*not* from the source tarballs), are there any additional steps beyond sh boot ./configure --prefix=... gmake install required? Ciao, Kili ps: I've also an amd64 (aka x86_64) at work and will run the tests on it next week. Wether I'll be able to fix the ghci problem in time: no idea. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
Hi, On Tue, Sep 23, 2008 at 03:38:56PM +0200, Christian Maeder wrote: The error far below is caused by -perm /a+x in mk/bindist.mk during find: I've changed it to -perm -111 Unfortunately, this will only find files with the executable bit set for user, group and owner, so it should be -perm +111. However, even more unfortunately, at least the find(1) on OpenBSD doesn't support the +mode pattern. This isn't a problem, because bindist isn't very useful at all on OpenBSD, but it may be a problem on other systems (I don't know what implementation of find(1) are used on FreeBSD, NetBSD and MacOS X). A workaround *may* be to use -perm -100 (setting the execute bit for group and others but not for the user would be really weird). Then make install could not replace links: ln -s runghc /local/home/maeder/bin/runhaskell ln: cannot create /local/home/maeder/bin/runhaskell: File exists gmake[2]: *** [install] Error 2 ln -fs should do the job. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
On Tue, Sep 23, 2008 at 08:34:36PM +0200, Matthias Kilian wrote: I've changed it to -perm -111 Unfortunately, this will only find files with the executable bit set for user, group and owner, so it should be -perm +111. However, even more unfortunately, at least the find(1) on OpenBSD doesn't support the +mode pattern.[...] According to http://www.opengroup.org/onlinepubs/95399/utilities/find.html `-perm +onum' (where onum is an octal number) seems to be yet another gnuism, so `-perm -100' is probably the most portable (and least breaking) option for any system not using gfind. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
On Mon, Sep 22, 2008 at 03:32:40PM +0200, Christian Maeder wrote: I've tried to build a binary dist on x86 under Solaris and did not succeed. make binary-dist failed with 1. for FILE in ; do if [ -e $FILE ]; then echo ghc-6.10.0.20080921/gmp/$FILE /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list ; fi; done /bin/sh: syntax error at line 1: `;' unexpected gmake[1]: *** [binary-dist] Error 2 I added strip to bindist.mk: ifneq $(strip $(BINDIST_EXTRAS)) This part could be done a little bit different (without the conditional): ... # And enything else echo $(BINDIST_EXTRAS) | \ xargs -n1 | \ sed '/^$/d;s/.*/test -e \\ echo $(WHERE_AM_I)\//' | \ sh $(BIND_DIST_LIST) (untested!) 2. /bin/sh: test: argument expected gmake[1]: *** [binary-dist] Error 1 -e does not work for test under sh, so I changed it to -r: ... if [ -r $$FILE ]; then ... I doubt `-e' doesn't work on Solaris, because `-e' is POSIX. Does this argument expected still appear with your fix to 1.? 3. tar hcf /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/ghc-6.10.0. 20080921-i386-unknown-solaris2.tar -T /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list tar: -T: No such file or directory gmake: *** [binary-dist] Error 1 I changed tar to gtar Or use pax(1), which in contrast to tar(1) and gtar(1) is POSIX: pax -hwf $(BIN_DIST_TAR) $(BIN_DIST_LIST) (also untested, but should work) 4. gtar: ghc-6.10.0.20080921/gmp/{}: Cannot stat: No such file or directory The file bindist-list contained {} instead of filenames, so I changed find to gfind. Or just omit all the -exec echo ${WHERE_AM_I}/{} goo and use find(1) and sed(1), e.g.: find $(WHATEVER) -print | sed 's/^/$(WHERE_AM_I}\//' 5. When trying to install the binary distribution I got: Installing executable(s) in /local/home/maeder/bin installPackage: dist-install/build/installPackage/installPackage: copyFile: does not exist (No such file or directory) Maybe fallout from some of the above problems? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Wed, Aug 13, 2008 at 09:03:34AM +0100, Simon Marlow wrote: Yes, it relies only on the Cabal metadata, but the output is a Makefile only useful for building GHC. Ok, this statement is plainly not true, since I can use 'cabal makefile' to build any package outside of the GHC build tree. So perhaps I've misunderstood your point? No, I was confused (a little bit over-worked). $ ./Setup mkmetadata -prefix foo- which just produces some simple variable declarations like foo-impl-ghc-build-depends = rts foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases [...] Yes, we could use this to implement GHC's build system. It's somewhat similar to the scheme I suggested in the other thread, but more generic. I'd be completely happy to do it this way if the functionality would be useful to others outside GHC too. I've a little bit spare time from august 25th to august 31th. This should be enough time for implementing it (in Cabal and in the GHC build system) to see how it feels. Ciao, Kili -- CRM114 isn't ugly like PERL. It's a whole different kind of ugly. -- John Bowker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Tue, Aug 12, 2008 at 11:59:37AM +0100, Simon Marlow wrote: Well, at least the Makefile creation was a step (the first step?) into the wrong direction, IMHO. I'll run a GHC build to get some of those generated Makefiles and followup on cvs-ghc, but for a starter, Cabal shouldn't know anything about implementation-specific internal build systems; instead it should rely only on it's own metadata. I'm not completely sure, but I think you may have misunderstood how Cabal's makefile generation currently works. It has no specific knowledge of GHC's build system, and it does rely on its own metadata. I mean the GHC-specific template used for building the Makefile (Distribution/Simple/GHC/Makefile.in) and the function `makefile` in Distribution/Simple/GHC.hs (this function even spills out some some make rules in addition to what's in Makefile.in, which looks very wrong to me). Yes, it relies only on the Cabal metadata, but the output is a Makefile only useful for building GHC. It'd be better to be able to run $ ./Setup mkmetadata -prefix foo- which just produces some simple variable declarations like foo-impl-ghc-build-depends = rts foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases ... ... foo-exposed-modules = Control.Applicative Control.Arrow ... ... foo-c-sources = cbits/PrelIOUtils.c cbits/WCsubst.c ... ... foo-windows-extra-libaries = wsock32 msvcrt kernel32 user32 shell32 foo-extensions = CPP foo-ghc-options = -package-name base foo-nhc98-options = -H4M -K3M Basically, the .cabal file is just converted into some other format that may be included by another Makefile. And since it's a really simple output format, it could even be used by different implementations of make(1) or even other build tools. The `foo-' prefix just shields variables in the including Makefile. Take this output, write it to some cabalmetadata.mk, and then use a (GHC-specific) Makefile copied over into all library directories that does an include cabalmetadata.mk ... GHC_OPTS += $(foo-ghc-options) EXPOSED_MODULES = $(foo-exposed-modules) $(foo-impl-ghc-exposed-modules) EXTRA_LIBS = $(foo-extra-libraries) $(foo-$(HostOS_CPP)-extra-libraries) Thus, Cabal dumps the metadata, without knowing how it's used. All the remaining stuff are some (implementation specific) Makefiles relying on recursive variable expansion. I'll implement this for GHC when I've a little bit more spare time (in three or four weeks). (in my other message I'm suggesting moving the Makefile generation into GHC's build system so that it could be made specific to GHC, though). Generated files should be as simple, primitive and portable as possible. Generating complete Makefiles make things more difficult. And it doesn't matter wether they're generated by Cabal or by GHC's build system. If you've to tweak the build system, you don't want to tweak generators but just an existing Makefile. Implementation-specific stuff (such as how to run the compiler) should be supplied by the implementation, not by Cabal. This is what makes me unsure. Implementation of what? The Haskell compiler. Or, to be more exact, the Cabal library shipped with the Haskell compiler (or some supplementary compiler-specific library -- I didn't think much about this part yet). However, my main concern is the usage of Cabal from within the GHC build system, so please just forget this part ;-) Are you suggesting a redesign of Cabal, or just changing the way something works? I don't think that a large redesign is necessary. It should just try to be as implementation-agnostic as possible. Ciao, Kili -- do yourself a favor and let the le(4)s rot on the junkpile of history... -- Henning Brauer ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Tue, Aug 12, 2008 at 10:29:03PM +0200, Matthias Kilian wrote: Basically, the .cabal file is just converted into some other format that may be included by another Makefile. Oops! I again read your (SimonM's) proposal on changing Cabal and the GHC build system in exactly this way. Sorry for the noise. Ciao, Kili ___ 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: [Haskell-cafe] haskell compiler on NetBSD amd64
On Sat, May 10, 2008 at 03:03:39PM -0700, Don Stewart wrote: I've to admit that the ghc port for OpenBSD is a little bit weird ;-) (but not as weird as my current work on ghc-6.8 for OpenBSD) What's your plan for the OpenBSD port, Kili? * Proper bootstrapping from .hc files. * Think about a better way to build the libraries; I understand why the GHC developers do it using the makefiles generated by Cabal, but I'd really prefer something less intrusive (i.e. let Cabal generate only some makefile snippets with dependencies, special flags etc. and include those snippets from a classical Makefile that fits better into the good old fptools framework). * Port it to more archs (arm, powerpc, maybe alpha and vax, and, if I'll ever be at that point, to everything else, at least unregisterised). * Omit as many core libraries as possible from the build, and make separate ports for them. * Improve ghc.port.mk to make ports of standard stuff on hackage more simple. Currently all GHC-depending ports are a real mess, for example xmonad: http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/xmonad/ With the new ghc.port.mk, all the do-something targets will vanish, and the xmonad Makefile will just contain a line like MODGHC_BUILD= cabal hackage haddock register which means: use Cabal (Setup.hs or Setup.lhs), fetch sources from hackage, use haddock to build the documentation, create register/unregister scripts that update package.conf on installation/deinstallation. Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell compiler on NetBSD amd64
On Sat, May 10, 2008 at 12:13:16PM -0700, Don Stewart wrote: I wonder if it is still possible to use the .hc files already generated for the OpenBSD/amd64 port, and use those to do the port to NetBSD/amd64. http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ If nobody tries, we'll never know. Ciao, Kili -- Do with this info and this argument what u will - as u always do. Delete it. -- Jeffrey Lim and Theo de Raadt in The famous t-shirt thread ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell compiler on NetBSD amd64
On Sat, May 10, 2008 at 02:36:43PM -0700, Donn Cave wrote: I wonder if it is still possible to use the .hc files already generated for the OpenBSD/amd64 port, and use those to do the port to NetBSD/amd64. http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ That sounds fine to me, if I understand you right - I managed to install an OpenBSD partition this afternoon, but if I can skip that step, that's fine with me. I don't see any .hc files at that link, though. Here you go: http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2 I've to admit that the ghc port for OpenBSD is a little bit weird ;-) (but not as weird as my current work on ghc-6.8 for OpenBSD) Actually, with headers starting to diverge, it might make more sense to just generate the amd64/netbsd .hc files from i386/netbsd -- where there's already a working ghc. I have ghc 6.4.1 on NetBSD 3.0 i386. That's the idea, right? If possible, start with ghc 6.6.1, even if that means to install a newer version of NetBSD. as apparently 6.8 is known to not build from .hc files. I don't understand `with headers starting to diverge'. Nor do I, but I guess Don meant significant differences in system libraries (between NetBSD and OpenBSD). Ciao, Kili -- Weg mit dieser verfluchten Demokratie wo alles das Wort führen will. -- Georg Christoph Lichtenberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The range operator
On Fri, Apr 04, 2008 at 08:58:06PM +0100, PR Stanley wrote: [x, y..z] What's the role of x? It's the first argument passed to enumFromThenTo. See sections 3.10 and 6.3.4 of the Haskell report. Ciao, Kili -- There's a limit to how many buttons a shirt should have. -- Theo de Raadt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Bootstrapping for Leopard
On Mon, Feb 04, 2008 at 12:18:01PM +, Simon Marlow wrote: Porting is simply broken for various reasons at the moment - in particular the switch to Cabal for building the libraries broke it. We knew this at the time, but felt it was more important to make the switch now and fix bootstrapping later. Be prepared: I'll send some comments and (probably silly) questions on cvs-ghc@ in a few minutes ;-) For pwd, I imagine the best way forward is to use a C program, I don't think there are any deep issues there. Unless some windows people have the time to step in and help make it work with simple shell stuff, some C helpers would be just fine. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping for Leopard
On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote: [Philip K.F. Hölzenspies:] make hc-file-bundle Making the hc-file-bundle target failed, because not all rts/*.cmm had rts/*.hc counterparts after the build. The make fails because of this fragment from the Makefile (part of the hc-file-bundle target, starting from line 513): for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/rts -name *.cmm -follow -print` ; do \ if test x$$f !=3D x; then \ echo `echo $$f | sed 's/cmm$$/hc/g' ` hc-files-to-go ; \ fi; \ done; This is strange. I've all kinds of trouble getting hc-bootstrapping back (for OpenBSD, but also in general), and I didn't see *that* problem. checking for path to top of build tree... ./configure: line 2651: - v0: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory [...] This is due to a change of the configure stage that AFAIK was made to easy building on windows. Instead, of using shell commands/scripts (as GHC did previously) to obtain some configuration information (here the file path at which the top of the GHC build tree is located), the build system now uses small Haskell programs/scripts. This makes the build more portable ** if there is already a Haskell compiler on the system **. But it just doesn't make sense at all. You need a good set of shell commands at all, since they're used by configure as well as in Makefiles. I really can't believe that simple stuff like this doesn't work on windos: --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 +++ aclocal.m4 Sun Jan 20 17:10:07 2008 @@ -1098,20 +1098,14 @@ AC_REQUIRE([AC_PROG_CC]) AC_DEFUN([FP_FIND_ROOT],[ AC_MSG_CHECKING(for path to top of build tree) -dnl This would be -dnl make -C utils/pwd clean make -C utils/pwd -dnl except we don't want to have to know what make is called. Sigh. -if test ! -f utils/pwd/pwd test ! -f utils/pwd/pwd.exe; then - cd utils/pwd - rm -f *.o - rm -f *.hi - rm -f pwd - rm -f pwd.exe - $WithGhc -v0 --make pwd -o pwd - cd ../.. -fi - -hardtop=`utils/pwd/pwd forwardslash` +case $HostPlatform in +*cygwin32|*mingw32) + hardtop=`pwd | tr \\ /` + ;; +*) + hardtop=`pwd` + ;; +esac if ! test -d $hardtop; then AC_MSG_ERROR([cannot determine current directory]) ifBuildable.hs is similar; it can be replaced by a shell script or even done within libraries/Makefile using very basic shell commands. The only solution that I see is to replace the Haskell scripts by vanilla shell scripts in HC bundles. Even if that causes problems on windows (without cygwin), it would make HC bundles viable on Unix systems again. How is ghc currently built on windows without something like cygwin? From the source distribution, the only way to build ghc seems to be via configure and (GNU) make. So there must be some shell environment available. Or am I missing something really crucial here? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on host machine when trying to cross-compile an unregistered build
On Mon, Jan 21, 2008 at 03:23:54PM +, Simon Marlow wrote: First thing to note is that bootstrapping from HC files has bitrotted in 6.8.x, see http://hackage.haskell.org/trac/ghc/ticket/1346. I've updated the wiki instructions to say this. You should go back to 6.6.x, or be prepared to fix things... I thought I remembered someone saying recently they were looking into getting bootstrapping working again, but I can't seem to find it now. That may be me. I've some local patches for obvious offending stuff (like utils/pwd or libraries/ifBuildable), and similar more or less trivia in libraries/Makefile, but I didn't yet even hit the problems I expect for the GNUmakefiles generated by cabal (which I tend to include in a pre-build HC file bundle), not speaking of *real* problems that may (will?) happen on the HC files themselves when all the make issues have been fixed. I asked igloo the other day, and now I ask here: if anyone has *any* attempts for the make problems, even if they don't work, just mail your diffs to me. No promises, no timeline[1], but I really want to get HC bootstrapping back. Ciao, Kili [1] Everytime I expect to have some more time to work on things I want to work on, something bad happens that stops me from doing so. At least within the last 14 months. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: network package
On Fri, Jan 11, 2008 at 09:32:20AM -0800, Don Stewart wrote: I have just built and installed ghc-6.8.2 on my linux box but I can't find the network package. Has it been moved or left out? It's not installed by default. You can find it on hackage.haskell.org, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-2.1.0.0 Yet it's still available in the extralibs tarball. Real slackers just extract extralibs on top of the normal ghc source tarball to get most (not all) of the beloved packages built for free. Just FYI, here are some notes I scribbled down for myself a few days ago when I did some work on the OpenBSD port of GHC (comparing 6.6.1 against 6.8.2 and comparing that against hackage.haskell.org): New (wrt 6.6.1): array, bytestring, containers, directory, hpc, old-locale, old-time, packedstring, parallel, pretty, process, random. Removed from the ghc sources (make separate ports fetching them from hackage): HGL, X11. Note that X11-extras (i.e. port x11/hs-x11-extras) is obsolete now. Available in the extralibs distfile: HUnit, OpenGL, QuickCheck, cgi, fgl, haskell-src, html, mtl, network, parallel, parsec, regex-base, regex-compat, regex-posix, stm, time, xhtml. Version info for packages (no version in Hackage column means same version as for GHC-6.8.2): NameDistGHC-6.8.2 Hackage Cabal base1.2.3.0 HUnit extra 1.2.0.0 OpenGL extra 2.2.1.1 QuickCheck extra 1.1.0.0 array base0.1.0.0 basebase3.0.1.0 n/a bytestring base0.9.0.1 0.9.0.3 cgi extra 3001.1.5.1 containers base0.1.0.1 0.1.0.0 (!) directory base1.0.0.0 fgl extra 5.4.1.1 filepathbase1.1.0.0 ghc base6.8.2 n/a haskell-src extra 1.0.1.1 haskell98 base1.0.1.0 hpc base0.5.0.0 htmlextra 1.0.1.1 mtl extra 1.1.0.0 network extra 2.1.0.0 old-locale base1.0.0.0 old-timebase1.0.0.0 packedstringbase0.1.0.0 parallelextra 1.0.0.0 parsec extra 2.1.0.0 pretty base1.0.0.0 process base1.0.0.0 random base1.0.0.0 readlinebase1.0.1.0 regex-base extra 0.72.0.10.91 regex-compatextra 0.71.0.10.90 regex-posix extra 0.72.0.20.91 rts base1.0 n/a stm extra 2.1.1.0 template-haskellbase(!) 2.2.0.0 timeextra 1.1.2.0 unixbase2.3.0.0 2.2.0.0 (!) xhtml extra 3000.0.2.1 Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on NetBSD Alpha - Dynamic link dependency?
On Fri, Jan 11, 2008 at 11:06:57AM +, Jim Burton wrote: In file included from Stg.h:150, from Rts.h:19, from mkDerivedConstants.c:23: Regs.h:30:45: gmp.h: No such file or directory For a starter, look at http://hackage.haskell.org/trac/ghc/ticket/2009 No idea wether it fixes your problem; you may have to add some more similar changes. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on NetBSD Alpha - Dynamic link dependency?
On Wed, Jan 09, 2008 at 10:41:23PM +, jim burton wrote: Thanks for that, the configure script gets to the end with that help. Following the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewplatform , I then try to make includes but get a big stream of errors from make. Why is this? The GHC build backs on gmake(1). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on NetBSD Alpha - Dynamic link dependency?
On Wed, Jan 09, 2008 at 07:42:21PM +, jim burton wrote: I'm trying to build unregistered 6.8.2 on NetBSD Alpha 2.1.0_STABLE -- I have the following problem which seems to be same as this one - http://hackage.haskell.org/trac/ghc/ticket/1860 No, I think it's another problem. $ ./configure --enable-hc-boot --enable-hc-boot-unregistered [...] checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure[3201]: -v0: not found ./configure[3203]: utils/pwd/pwd: not found configure: error: cannot determine current directory What happens here is that configure tries to compile some utility program (utils/pwd/pwd) using an existing ghc, which of course is impossible when you're porting ghc a platform not already running ghc. Similar problems are located in libraries and the Cabal-generated GNUmakefiles. For the utils/pwd/pwd problem, I really don't understand why that thing is required at all, since it does little more than get the pwd and add some slash or backslash escaping/quadrupling depending on the argument passed to it. You may try the patch below (and don't forget to re-run autoconf). Note that this is the quick hack I did for OpenBSD. If the forward slash hack of util/pwd is really required (for Windows builds?), something like hardtop=`pwd | tr '\\' /` would be more appropriate. And the other sanity checks I deleted may be necessary in some cases, too, but I really don't see the point in them. Ciao, Kili ps: IMHO, libaries/ifBuildable.hs should die a horrible death, too. It can replaced with a few lines of shell commands.. --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 +++ aclocal.m4 Fri Jan 4 13:58:49 2008 @@ -1098,28 +1098,7 @@ AC_REQUIRE([AC_PROG_CC]) AC_DEFUN([FP_FIND_ROOT],[ AC_MSG_CHECKING(for path to top of build tree) -dnl This would be -dnl make -C utils/pwd clean make -C utils/pwd -dnl except we don't want to have to know what make is called. Sigh. -if test ! -f utils/pwd/pwd test ! -f utils/pwd/pwd.exe; then - cd utils/pwd - rm -f *.o - rm -f *.hi - rm -f pwd - rm -f pwd.exe - $WithGhc -v0 --make pwd -o pwd - cd ../.. -fi - -hardtop=`utils/pwd/pwd forwardslash` - -if ! test -d $hardtop; then - AC_MSG_ERROR([cannot determine current directory]) -fi - -dnl Remove common automounter nonsense -dnl -hardtop=`echo $hardtop | sed 's|^/tmp_mnt.*\(/local/.*\)$|\1|' | sed 's|^/tmp_mnt/|/|'` +hardtop=`pwd` AC_SUBST(hardtop) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 port on FreeBSD-amd64?
On Sun, Jan 06, 2008 at 05:20:18PM +, Ian Lynagh wrote: Prologue junk?: .type s32x_ret, @function s32x_ret: pushl %ebp movl%esp, %ebp I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the gcc-3.3.5 included in its base system. Presumably this also happens if you do a normal build with -fvia-C, i.e. it's not specific to building from an HC file bundle? That's right, it's just -fvia-C that triggers the bug. [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, it should be -fviaC -keep-hc-files. Someone let me know if I should correct this in the wiki. GHC will act as if -fvia-C is given if -keep-hc-files is given. It would be nice to update the wiki to say -fvia-C rather than -fasm to avoid confusion, though. Done. ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's a must-have for the OpenBSD port. Note that there is a plan to drop the registerised via-C way of compiling GHC at some point, so this isn't going to work in the long term (unless you want to bootstrap via an unregisterised compiler). I think I'll be happy with unregisterised bootstrap, too, even if the actual build of the port will take longer. Would it not be possible to have a ghc-bin package in OpenBSD, which contains a precompiled binary that can be used to compile a ghc source package? I think Gentoo does something like that. AFAIK, FreeBSD does it in a similar way. However, this isn't the way we do ports for OpenBSD, so I'll work towards the unregisterised bootstrap. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 port on FreeBSD-amd64?
[Note: already shortly discussed with Wilhelm] On Fri, Nov 23, 2007 at 12:30:06PM +, Wilhelm B. Kloke wrote: ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include HsUnix.h -#include execvpe.h -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi Prologue junk?: .type s32x_ret, @function s32x_ret: pushl %ebp movl%esp, %ebp I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the gcc-3.3.5 included in its base system. Regardless of wether there's something wrong with the generated code or wether it's just a bug in the mangler, it's possible to build Process.c with -fviaC *and* -O0.[1] For now, I'm able to build a HC file bundle with this settings in build.mk and running gmake stage1 hc-file-bundle: SRC_HC_OPTS=-H64 -O -fvia-C -keep-hc-files GhcLibHcOpts= -O0 # Workaround the mangler problem GhcLibWays= GhcRTSWays= SplitObjs= NO I'd appreciate any reports wether people see the same problem on other systems (if so: what gcc version are you using?) and wether GhcLibHcOpts=-O0 fixes it. Ciao, Kili [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, it should be -fviaC -keep-hc-files. Someone let me know if I should correct this in the wiki. ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's a must-have for the OpenBSD port. Apart from the HC file bundle, this will require some more hacking especially on library/Makefile and the Cabal-generated GNUmakefiles (and/or Makefile.local). pps: I guess, cvs-ghc would be the more correct list for sending patches and discussing the bootstrapping stuff, right? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Cabal, Haddock, and the location of documentation
Hi, probably a PEBCAK, but working on updating all our Haskell-related OpenBSD ports, I've currently the problem, that, e.g. for Crypto the Haddock-generated documentation doesn't gets installed where I want it installed ;-) The default obviously is something like $prefix/share/Crypto-$VERSION/doc/html, but I want $prefix/share/doc/Crypto-$VERSION, or, even preferrable, just $prefix/share/doc/Crypto. That's: - $prefix/share/doc as base directory for all documentation, since that's the default on OpenBSD. - no html subdirectory if not strictly necessary, because I don't like a doc directory containing nothing but a html directory. - no version number in the directory name, because typically we don't have different versions of the same software installed at the same time -- there are exceptions from this rule, but I really don't plan to start maintaining several versions of one ore more Haskell packages ;-) Is this configurable at Cabal/Haddock runtime? I'd try to play with --datadir, but this appears a little bit dangerous as a general approach, since some packages my actually come with real data, which should *not* go into $prefix/share/doc, of course. Or do I have to patch Cabal? If so, what about adding just another FilePath like docdir to Distribution.SimpleLocalBuildInfo and use it for the documentation? Ciao, Kili ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
On Tue, May 29, 2007 at 04:15:29PM +0100, Simon Marlow wrote: What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. No ringing bells here I'm afraid. What you're seeing is a failure from the code that checks for memory leaks, which is only enabled by -debug (the threaded1 test way uses -threaded -debug). It reckons you have 508 blocks allocated from the OS, but can only account for 255 of them. You could try enabling some more debugging options, e.g. +RTS -DSb will enable sanity-checking and debugging messages from the block allocator. This, and with some more debugging output and gdb sessions, helped. The problem is that in hs_init(), initAdjustor() is called *before* initStorage(). initAdjustor() is a NOOP everywhere except for OpenBSD/i386, where it calls allocateExec(). Later in hs_init(), when initStorage() is invoked, the free_list is reset, but mblocks_allocated is still 1 = bummer. Now my GHC knowledge is still very rusty (I didn't look at it for years), so I really don't know wether that initAdjustor() is still needed nor what it's good for, or if its invocation can be moved after initStorage(). Any hint appreciated. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
Hi, I'm currently working on updating the GHC port to 6.6.1 for OpenBSD, and when I run the testsuite (ghc-regress), all test cases for the way threaded1, i.e. debug + threaded bail out with an assertion failure: Blocks: 132 live + 123 free = 255 total (508 around) conc010: internal error: ASSERTION FAILED: file Storage.c, line 1174 The numbers vary slightly, but there's always a total of 255 and 508 blocks around, except for one test case (con012), where there are a total of 763 blocks (1016 around). What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. Ciao, Kili -- CRM114 isn't ugly like PERL. It's a whole different kind of ugly. -- John Bowker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testsuite for GHC version 6.6.1?
On Fri, May 04, 2007 at 02:48:13PM +0200, Christian Maeder wrote: How or where can I pick up the testsuite for this new version? I want to test my own builds. http://www.haskell.org/ghc/dist/6.6.1/ghc-testsuite-6.6.1.tar.gz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] translation of kind
On Mon, Jun 20, 2005 at 01:11:27PM +0200, Andreas Rossberg wrote: Indeed. Moreover, my impression is that many Germans rather tend to say die Kind instead when they have to, maybe because that is the gender you have for Sorte, Art, and Gattung. ^^^ Well, then what about Gattung? Ciao, Kili ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Why are strings linked lists?
On Fri, Nov 28, 2003 at 11:31:51AM +0100, Wolfgang Jeltsch wrote: On my machine replicate 500 'a' will use 90MB of space! You have to take into account that Chars (in GHC) take 4 bytes of memory because they denote Unicode codepoints. 5,000,000 times 4 bytes is already 20 MB. (The rest is only a constant factor. ;-)) No, in the above example there's only one single 'a' but 500 (:) and one [] heap-allocated cells. For example, let f = replicate 500 in f (f 'a') will use only about twice (and not 500 times) the memory of the initial example. Exactly: 1000 * size of (:) + size of 'a' + size of []. So the only relevant thing is the list constructor (:) which needs two pointers to its arguments, and typically another pointer for housekeeping (depending on the runtime implementation). That typically makes 12 bytes per constructor (on a 32 bit architecture). Regards, Kili -- Denken ist schwer, darum urteilen die meisten. [Carl Gustav Jung] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: old easter egg
On Sat, 2 Dec 2000, Jon Fairbairn wrote: hash "HASKELL%98" hash "Haskell Ninety Eight !!" Here's the who;e truth: hash "Turing!" Kili -- Nunja! Wenn man erst einmal anfängt zu denken, dann ist es wie eine Sucht. Man kommt nicht mehr los davon. [WoKo in dag°, 28.11.2000] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Usability of M$ specs [was: Haskell and the NGWS Runtime]
On Sat, 9 Sep 2000, Erik Meijer wrote: With the SDK that you can download from MS comes a 500 page specification of the runtime and the IL. So if you have a free Saturday and you want to get famous, then give that Linux implementation a try. But is this specification sound and complete? I'd a look at the C# speccifcation, which is a bad joke. For example, there's a section about the switch statement, which elaborates on the "fall-through" problem. From my memory (I don't have the specs at home): To prevent accidently fall-throughs by a forgotten "break", each case has to be ended cleanly, either by an explicit "break", or by a "goto label", or by a return statement, or by throwing an exception, or by doing anything else the compiler can prove that the next case block isn't reached. For example, the following is legal: switch(foo(x)) { case 42: while(true) { .. } case 43: ... } From the Specs: "Obviously, the loop in the 42-case does not terminate, so it's legal to omit the break after the loop." With this nice example, M$ either forces a C# compiler to solve the halting problem (since it has to decide wether a certain piece of code terminates or not), or makes the decision about what is legal code an implementation depenent one. (What about the body of the loop? What about "while(f(x)) {...}"?) If the runtime specifications of .NET are of the same quality, there's no way to port it to another system. Ciao, Kili -- Auf deutschem Boden darf nie wieder ein Joint ausgehen. [Wolfgang Neuss]
Re:
On Sun, 6 Aug 2000, Mirko Pracht wrote: average x | null x= 0.0 What does you make thinking the average of an empty list is 0? Its' obviously _|_, thus average xs = sum xs / length xs [which is inefficient, but simple] Kili -- _|_ is pronounced 'bottom', and is the greatest lower bound of a complete lattice. Nick Williams in comp.lang.functional
perl frontend for ghc
Hi! I hope this isn't a FAQ, but AFAIR this hasn't been asked in the past: Are there plans to replace the ghc frontend (driver), which is currently written in perl, by a version implemented in Haskell? I know that perl is nice for fiddling with command line options, but on the other hand, it's a very chaotic programming language. So, are there any reasons beyond speed and/or the simple fact that nobody did port the frontend to Haskell? Bye, Kili -- signature intentionally left blank
Wanted: mmap or other fast IO
Hello, Is there any interface to mmap(2) available? Something that behaves like an immutable array would be great. An mmap may have a signature like mmap :: Ix a, ?? b = Handle - IO (Array a b) I've no idea what types should be allowed for b. It has to be some fixed size type, e.g. Int, but this would require the mmapped file's size to be a multiple of the size of Ints. Bye, Kili
Re: ANNOUNCE: GHC 4.06 released
Hi! I wonder what the cvs release naming strategy is. Ist 4.06 on the main cvs branch, or is there a special tag for official releases, or what else? A `cvs up -dPA -r 4.06' in the fptools directory simply removed everything (don't worry, I did make a copy before the update). Bye, Kili
Re: ANNOUNCE: GHC 4.06 released
Hi! I wonder what the cvs release naming strategy is. Ist 4.06 on the main cvs branch, or is there a special tag for official releases, or what else? A `cvs up -dPA -r 4.06' in the fptools directory simply removed everything (don't worry, I did make a copy before the update). Bye, Kili
Graph reduction and lambda lifting
Hi! Where can I find papers on the topics "graph reduction", "lambda lifting", "g-machine", "TIM", etc. in the web? The only paper I could find at home was the paper on STG and something about Turner's combinator reduction. Kili -- de: Signaturen erzeugen Krebs. en: Signatures cause cancer. es: Signaturas provocan cáncer. latin: Cancerem signatura faciunt. se: Signaturer förorsaka cancer.fr: Les signatures provoquent le cancer. ro: Signaturile produc cancer. ru: Podpis'ki razvivaút rak.