The dreaded windows path length issue
Hi all, I'm now working for IOHK on the Cardano project. The Cardano code base is large and we are hitting the dreaded windows path length bug. We have already shortned build paths as much as possible but are still hitting this We're currently using ghc-8.0.2 but even ghc-8.2.2 has this issue. A snippet of the logs in included below. I took the liberty of including Tamar on this since he is the known Windows expert. Not having a local Window makes this really difficult to debug. Anyone have any solutions for this? I'm willing to backport patches if needed. I've managed to find a VirtualBox evaluation image on the Microsoft site. Hopefully that will give me enough to debug this issue. Cheers, Erik [01:27:27] -- While building custom Setup.hs for package csl-wallet-new-1.1.1 using: [01:27:27] C:\s\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.w\dist\5c8418a7 build lib:csl-wallet-new exe:cardano-node exe:csl-gen-swagger exe:csl-integ-test test:wallet-new-specs test:wallet-unit-tests --ghc-options " -ddump-hi -ddump-to-file" [01:27:27] Process exited with code: ExitFailure 1 [01:27:27] Logs have been written to: C:\w\.w\logs\csl-wallet-new-1.1.1.log [01:27:27] [01:27:27] Configuring csl-wallet-new-1.1.1... [01:27:27] Preprocessing library for csl-wallet-new-1.1.1.. [01:27:27] Building library for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Linking .w\dist\5c8418a7\build\csl-integ-test\csl-integ-test.exe ... [01:27:27] realgcc.exe: error: CreateProcess: No such file or directory [01:27:27] `gcc.exe' failed in phase `Linker'. (Exit code: 1) [01:27:27] Command "call stack --dump-logs install cardano-sl cardano-sl-tools csl-wallet csl-wallet-new -j 2 --no-terminal --local-bin-path c:\w --test --no-haddock-deps --flag cardano-sl-core:-asserts --flag cardano-sl-tools:for-installer --flag csl-wallet:for-installer --extra-include-dirs="C:\OpenSSL-Win64-v102\include" --extra-lib-dirs="C:\OpenSSL-Win64-v102" --extra-include-dirs="C:\xz_extracted\include" --extra-lib-dirs="C:\xz_extracted\bin_x86-64" --extra-include-dirs="c:\w\rocksdb\include" --extra-lib-dirs="c:\w"" failed with exit code 1. Retrying 4 of 5 -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How to get a heap visualization
Ben Gamari wrote: > Yitzchak Gale <g...@sefer.org> writes: > > > Joachim, first and foremost, thanks for the awesome libraries > > ghc-vis and ghc-heap-view. > > > > The design trade-offs for ghc-vis do make sense if you think of > > it as a didactic tool. But as a debugging tool, the most important > > factor is that it should "Just Work", with no big builds, no fiddling, > > no googling. When you reach for a debugging tool, you are > > *already* in a debugging situation; you don't have patience > > for also debugging the tool. > > > I should point out that there is a differential (D3055) by erikd from > earlier this year which folded ghc-heap-view into GHC. The goal was to > make heap-view a supported library which could be relied upon by third > party tools. As far as I can remember most of the hard work is done; it > just needed some finishing touches. Perhaps you would be interested in > picking it up? Sorry if I gave the wrong impression, but IMO ghc-heap-view is a *long* way from being ready to integrate into GHC. ghc-heap-view currently supports most of the normal/simple heap object types. but has no support for more complex objects. Furthermore, levity polymorphism adds a whole new dimension to the problem. My estimate of the amount of work required to make ghc-heap-view cover all the heap objects was such that I abandoned the project. I would love to see someone pick it up and run with it. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: type (++) = (<>)
Vassil Ognyanov Keremidchiev wrote: > What do you think of making (++) the same as (<>) so we could use ++ as > concatenation of any monoid, not just lists in Haskell 2020? > This will be more intuitive for beginners, too. Two symbolic operators that are synonymous seems a bit of a waste. I would much rather see (++) be deprecated in favour of (<>). At work we have a custom prelude which already does this. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Switching the meanings of the : and :: (was Haskell-prime Digest, Vol 104, Issue 2)
Soham Chowdhury wrote: > Apologies if this question's already been discussed here, but have there > been any discussions about switching the meanings of the : and :: > operators? The rationale here is, of course, that :: is (probably, beware > of anecdata) used a lot more than : is. > > Obviously this would have the effect of breaking essentially every module > ever written if it were done "automatically", but could there not be > something akin to what -XDataKinds did for the * kind? Sorry, from a cost/benefit analysis point of view this doesn't look very promising at all. The costs are very obvious: * Implementation in GHC and ongoing maintenance. * The extra cognitive load put on every developer who has to work on code that has both forms. There are probably others, but as far as I am concerned the second alone far outweights any potential benefit. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Rewrite rules
Joachim Breitner wrote:
> very little. The best one can do right now is to know enough about Core
> and the inliner to predict when things are going to be inlined and when
> not, what else can go wrong (wrappers maybe?), add the necessary
> controls (`NOINLINE [0]` etc.), and then hope for the best. And track
> down any instances of failed rewriting that you learn about.
>
> You might also be able to set up your code so that it fails (at
> runtime, with error) if the desired rules did not fire. This would be
> nicer if we had https://ghc.haskell.org/trac/ghc/ticket/9180.
>
> You can also ask for review if it is public code.
Ok, I'm heading in this direction and then I figure out that the parser
for the rewrite rules doesn't even reject obvious syntax errors.
Say I have a data types:
data Word128 = Word128 Word64 Word64
and inspired by the `fromIntegral` rules for Word64 I write:
{-# RULES
"fromIntegral/Word64->Word128" fromIntegral = \w64 -> Word128 0 w64
#-}
all is fine and dandy. However if I introduce an obvious syntax error
like reversing the `->`:
{-# RULES
"fromIntegral/Word64<-Word128" fromIntegral = \w64 -> Word128 0 w64
#-}
I don't get any warning or anything. I've read the docs for rewrite
rules:
https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html#rewrite-rules
but they are rather sparse and again are very short on guarantees.
Have I just managed to find myself a new project?
Erik
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Rewrite rules
Michael Snoyman wrote: > Could be I'm misunderstanding, but are you looking for -ddump-rule-firings? Wasn't aware of that, but my question was a little more general. If I write a library that includes rewrite rules, how can I ensure that they fire in client code that someone else writes? What guarantees (however loose) are there? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RFC: Removing the `-hb` profiling option
Hi all, After a bit of rather tedious and frustrating debugging I came to the realisation that the code for the `-hb` profiling option is not thread safe. See https://ghc.haskell.org/trac/ghc/ticket/12019 This gives us an opportunity to simply remove it instead of fixing it. If there is anyone that thinks this future is really useful (ie more useful than the other profiling modes) then I'm willing to fix it. But if noone would miss it. I'd much rather remove it. Thoughts? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Looking for GHC compile-time performance tests
Ben Gamari wrote: > So, if you would like to see your program's compilation time improve > in GHC 8.2, put some time into reducing it to something minimal, submit > it to us via a Trac ticket, and let us know in this thread. The vector package is probably a good candidate. Compling vector slowed down signicantly between 7.8 and 7.10, only to speed up again with 8.0. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ETA on 7.10.3?
David Banas wrote: > Does anyone have an ETA for ghc v7.10.3? > (I'm trying to decide between waiting and backing up to 7.8.2, for a > particular project.) I am not aware of any concrete plans for a 7.10.3 release. You should upgrade to 7.10.2. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: simultaneous ghc versions
Evan Laforge wrote: The recent release of ghc 7.10.2 reminded me of something I meant to ask about a long time ago. Most of the binaries ghc installs are versioned (x linked to x-7.10.2), with some exceptions (hpc and hsc2hs). Shouldn't they all be versioned? Also, 'haddock' is inconsistent with all the rest, in that it's haddock linked to haddock-ghc-7.10.2. I maintaing multiple versions of GHC on all the machines I use regularly for Haskell development. I have: * ghc-7.6.3 installed under /usr/lib/ghc-7.6/ * ghc-7.8.4 installed under /usr/lib/ghc-7.8/ * ghc-7.10.2 installed under /usr/lib/ghc-7.10/ To switch between versions all I need to do is modify $PATH to remove say /usr/lib/ghc-7.6/bin and add /usr/lib/ghc-7.10/bin. This lets me have two terminal window side by side with different versions of GHC. I actually have a shell function to to do this PATH mangling. I can document this more fully if anyone is interested. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
Wolfram Kahl wrote: I use essentially the same setup, but found that cabal-install does not play nicely with this: No matter under which prefix I install cabal-install, it always assumes the same global path for its configuration file. I install cabal-install from debian which just puts it in /usr/bin/ which works fine, with and without sandboxes. This is a nuisance in particular when for some reason different versions of GHC need different versions of cabal-install --- apparently older GHCs don't work with newer versions of cabal-install? I have not run into this problem with ghc-7.6.3, ghc-7.8.4 and ghc-7.10.2 installed. I did experiment with cabal-install's -w and sandboxes, and agree with what was previously mentioned: It only helps if you never use GHC without cabal-install. With a recent version of cabal, run 'cabal user-config diff' to display what if different between your ~/.cabal/config and what cabal would install if it didn't exist. Sometimes an older ~/.cabal/config file can cause troubles. Cheers, Erik PS: Please reply to the list and do not CC me. -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Defining a custom newByteArray primop that uses calloc?
Brandon Simmons wrote: In my tests, using calloc from: https://hackage.haskell.org/package/missing-foreign-0.1.1/docs/Foreign-Marshal-MissingAlloc.html was about twice as fast as allocating and zeroing the same amount of memory with `newByteArray` + any of `copy/set/fillMutableByteArray` (all three were nearly identical). Is there a way I can reasonably define my own `newByteArray` that uses calloc? FWIW here are a couple of the benchmarks I'm working with in criterion: arrTestSet :: Int - IO () arrTestSet len = do let eBytes = (P.sizeOf (undefined::Int))*len a - P.newAlignedPinnedByteArray Why pinned memory? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond
Michael Snoyman wrote: On Tue, Apr 1, 2014 at 8:07 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Hi Gershom, We've also seen a lot of interest in distribution and cloud computing. From the articles I've read, efficient concurrent programming involves using node.js, so I think we should put some work into writing a new-new-new-IO Manager built on top of this technology. As a member of Mio developers, I don't understand this sentence. Would you concretely explain what kind of node.js technologies should be taken into new-new-new-IO Manager? It's really simple: node.js is webscale, Mio is not. I'm sorry, but you simply didn't do a good enough job making sure that random packets were lost when sending network traffic, or that writing data to disk may sporadically fail. Better luck next time. I think Michael about sums it up. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RC2 build failures on Debian: sparc
Joachim Breitner wrote: sparc fails differently than in RC1, and very plainly with a segmentation fault in dll-split (which happens to be the first program to be run that is compiled with stage1): https://buildd.debian.org/status/fetch.php?pkg=ghcarch=sparcver=7.8.20140228-1stamp=1393975264 Any ideas? Anyone feeling responsible? It would be shame to loose a lot of architectures in 7.8 compared to 7.6, but I’m not a porter and don’t know much about these part of the compiler, so I have to rely on your support in fixing these problems, preferably before 7.8.1. I've seen this on powerpc64 as well, but I first ran into this well before 7.8.1. See: https://ghc.haskell.org/trac/ghc/ticket/8024 Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Mathieu Boespflug wrote: [Sorry for the multiple reposts - couldn't quite figure out which email address doesn't get refused by the list..] Hi Carter, thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? Indeed, this could be done without touching the compiler at all. We had this response really early on in this discussion. Quite honestly I think that should have been the end of the discussion. The existing GHC release already have a huge workload getting releases out the door and adding to that workload without adding manpower and resources would be a bad idea. You really should try doing this as a library outside of GHC and if GHC needs a few small additional features, they can be added. The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. Once it works outside GHC and has proven useful, then it might be worthwhile add small specific, easily testable/maintainable features to GHC to support what goes on on your library. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
Carter Schonwald wrote: that still requires some discovery though! The idea (i'd hope) would be to make the my first ghc install on a vm (for experts and new folks both) go from #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make install PREFIX=yah #figure out how to install cabal, eg discover wget and then ./bootstrap # cabal install thingsIwannaTry to # install ghc via some wget and make #cabal install nice things Thats basically how I work on Debian based Linux systems: # apt-get install ghc alex happy cabal-install $ cabal install nice-things Where '#' is the root prompt and '$' is the user prompt. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Parallel building multiple targets
John Lato wrote: ghc --make doesn't allow building several binaries in one run, however if you use cabal all the separate runs will use a shared build directory, so subsequent builds will be able to take advantage of the intermediate output of the first build. As long as the ghc-options flags are the same for all the different component sections (I've been bitten by this). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linux deployment requirements for GHC-produced binaries
Brandon Allbery wrote: On Thu, Oct 3, 2013 at 1:10 PM, Yitzchak Gale g...@sefer.org wrote: ldd just says not a dynamic executable. o.O I don't think the ghc runtime uses dlopen() to get at gmp (and I'm not sure that would even work in a static binary). You may need to resort to strace to find out what's trying to pull in libgmp.so.whatever. Unless this program is like xmonad and requires ghc behind the scenes to build something, in which case you would indeed need everything that ghc requires (and, of course, ghc itself). I suspect the OP's exectuable is aleady being compiled static. For the webapp I'm currently working on I get: ldd test-webapp linux-vdso.so.1 (0x7fffcdd91000) libpq.so.5 = /usr/lib/libpq.so.5 (0x7f973e0a8000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f973de9) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f973dc87000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f973da84000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f973d88) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f973d663000) libldap_r-2.4.so.2 = /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x7f973d412000) liblber-2.4.so.2 = /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x7f973d203000) libgmp.so.10 = /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f973cf8a000) libffi.so.6 = /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f973cd82000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f973ca84000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f973c6d7000) libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x7f973c479000) libcrypto.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7f973c087000) libkrb5.so.3 = /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f973bdb2000) libcom_err.so.2 = /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f973bbae000) libgssapi_krb5.so.2 = /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f973b96f000) /lib64/ld-linux-x86-64.so.2 (0x7f973e2f9000) libresolv.so.2 = /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f973b757000) libsasl2.so.2 = /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x7f973b53c000) libgnutls.so.26 = /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x7f973b27c000) libgcrypt.so.11 = /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x7f973affc000) libk5crypto.so.3 = /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7f973add3000) libkrb5support.so.0 = /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f973abc9000) libkeyutils.so.1 = /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7f973a9c5000) libtasn1.so.3 = /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x7f973a7b3000) libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7f973a593000) libgpg-error.so.0 = /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f973a38e000) and libgmp is clearly listed in that. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Conduit : is it possible to write this function?
Michael Snoyman wrote: You can build this up using the = operator[1] in stm-conduit, something like: eitherSrc :: MonadResourceBase m = Source (ResourceT m) a - Source (ResourceT m) b - Source (ResourceT m) (Either a b) eitherSrc src1 src2 = do join $ lift $ Data.Conduit.mapOutput Left src1 = Data.Conduit.mapOutput Right src2 I think this can be generalized to work with more base monads with some tweaks to (=). Thanks Michael, that looks like it will fit the bill! Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Conduit : is it possible to write this function?
Hi all Using the Conduit library is it possible to write the function: eitherSrc :: MonadResource m = Source m a - Source m b - Source m (Either a b) which combines two sources into new output source such that data being produced aysnchronously by the original two sources will be returned as either a Left or Right of tne new source? If so, how? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Custom Setup.hs and Paths module
Daniel Díaz Casanueva wrote: Hello Erik. Yes, that solution may work, but seems ad-hoc to me. I would like to see a way to actually import the Paths module. In the meanwhile, I will be using your idea. Thank you for the response. Anybody knows how to hack the Setup.hs so I can use the real Paths module? I'm almost certain it can't be done. The problem is that the Paths module is generated by the 'cabal configure' process and the configure process needs to run Setup.hs which needs the Paths module etc etc. That's what you might call a circular dependency :-). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Custom Setup.hs and Paths module
Daniel Díaz Casanueva wrote: Hi everyone. I am writing a package where I am using the Paths module that cabal generates automatically. After adding the Paths module to the other-modules section in my cabal file everything worked just fine, until I wanted to write a custom Setup.hs. This Setup.hs just writes a couple of files in the system and then calls defaultMain. The thing is that now cabal install does not find the Paths module, so the package is broken. I ran into the same problem. I ended up fixing it by *not* using the auto generated Paths module and instead parsing the cabal file in Setup.hs. This is not has horrible as it sounds as I used the Cabal insfrastructure to do it. Basically something like this: import Distribution.Simple import Distribution.PackageDescription import Distribution.PackageDescription.Parse (readPackageDescription) import Distribution.Verbosity (silent) version - fmap (showVersion . pkgVersion . package . packageDescription) $ readPackageDescription silent my-package.cabal and then used that version String to write a trivial 5 line file Version.hs. HTH, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LLVM Backend status
B B wrote: Great! Its very very nice to hear that! Has Haskell somewhere a technical documentation focused on LLVM usage? (for exampel about GHC's custom calling convention) Root page of the compiler comentary is here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler with info about the LLVM backend here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM It seems the custom calling convention may only be documented in the code. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Improving GHC's LLVM Backend
Alex, I really suggest you take this to the ghc-devs mailing list. Cheers, Erik Alex Ford wrote: Hello, I'm interested in improving the LLVM backend of GHC by using the existing Haskell LLVM bindings to the C API, as suggested by option 1 in the LLVM FAQ: http://llvm.org/docs/FAQ.html#i-d-like-to-write-a-self-hosting-llvm-compiler-how-should-i-interface-with-the-llvm-middle-end-optimizers-and-back-end-code-generators At the moment, the backend uses the option 2: emitting LLVM assembly code which is then assembled to LLVM bitcode, optimised, and compiled to machine code by standard LLVM tools. Changing this to use the Haskell FFI bindings to the LLVM C API would allow better tracking of any changes to the LLVM IR, and hopefully a reasonable speed increase by avoiding the overhead of first emitting LLVM Assembly to be assembled. In his bachelor's thesis, David Terei considered this approach when initially writing the LLVM backend, but dismissed it due to the existing Haskell bindings being too large and high level to use with GHC. I have not personally looked at the high level Haskell bindings in much depth, but the low level (llvm-base) bindings appear to be somewhat incomplete with respect to LLVM 3.3. Therefore, I plan to extend the FFI bindings to cover more or all of the C API, and then to modify the GHC LLVM backend to use these bindings to call into the LLVM libraries directly. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVMcontains a link to David's thesis, as well as documentation of the LLVM backend. I'd really appreciate it if anyone who knows about the Haskell LLVM bindings or about the GHC LLVM backend could give any advice regarding what sort of work needs to be done with the LLVM bindings to make them more appropriate for use within GHC, or how to approach modifying the existing LLVM backend. Many thanks, Alex -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LLVM Backend status
B B wrote: 1) Is the LLVM Backend actively developed or should I be afraid it will be discontinued or broken? My understanding is that it is being actively developed. Currently for numerical code, the LLVM backend performs better than the native codegen. I also think that the LLVM backend is the only option for ARM. 2) How can I generate the LLVM IR (or bc) files from the compiler? I see that durign compilation with -fllvm -v3 flags the bc files are created but they are immidietly (after usage) deleted - Is it possible to tell the compiler not to delete them? As someone else stated, use `-keep-llvm-files` but be aware that GHC uses a custom calling convention so calling into GHC generated LLVM code is non-trivial. HTH, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LLVM Backend status
Erik de Castro Lopo wrote: B B wrote: 1) Is the LLVM Backend actively developed or should I be afraid it will be discontinued or broken? My understanding is that it is being actively developed. Currently for numerical code, the LLVM backend performs better than the native codegen. I also think that the LLVM backend is the only option for ARM. And there was a lareg set of patches for the LLVM backend applied just now: http://www.haskell.org/pipermail/ghc-commits/2013-June/002324.html and the following 10 or so commit. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] ANN: strict-base-types-0.1
Johan Tibell wrote: For what it's worth, I think we need Data.Maybe.Strict, Data.Tuple.Strict, and Data.Either.Strict in base. Only then will they be accessible enough that we can start using them in APIs in core packages. This will also make it easier to provide type class instances (e.g. Binary) for them without creating odd package dependencies (or packages that depends on everything under the sub). +1 Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Compiled code
MigMit wrote: Suppose I compiled some module and kept it's .hi and .o files. Is it possible to use this module in my program if the source code was deleted for some reason? Seems like the answer is yes The answer is yes as long as the compiler version and the versions of all libraries your orignal .hs file used remain the same. As soon as any of these versions change, you need the full original .hs file. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled code
Erik de Castro Lopo wrote: MigMit wrote: Suppose I compiled some module and kept it's .hi and .o files. Is it possible to use this module in my program if the source code was deleted for some reason? Seems like the answer is yes The answer is yes as long as the compiler version and the versions of all libraries your orignal .hs file used remain the same. As soon as any of these versions change, you need the full original .hs file. If you change the compiler flags (eg optimisation levels) you will also need the full original .hs file. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] attoparsec and backtracking
Evan Laforge wrote:
The first is that it's hard to get the right error msg out. For
instance, I have a parser that tries to parse a number with an
optional type suffix. It's an error if the suffix is unrecognized:
p_num :: A.Parser Score.TypedVal
p_num = do
num - p_untyped_num
suffix - A.option ((:) $ A.letter_ascii)
case Score.code_to_type suffix of
Nothing - fail $ p_num expected suffix in [cdsr]: ++ show suffix
Just typ - return $ Score.Typed typ num
I think the mistake here is to parse something and then decide if
its it valid. It should be the parser which decides whether its
valid. So rather than:
suffix - A.option ((:) $ A.letter_ascii)
try:
typ - A.choice [ {- list or valid suffix parsers -} ]
return $ Score.Typed typ num
However, which error msg shows up depends on the order of the (|)
alternatives, and in general the global structure of the entire
parser, because I think it just backtracks and then picks the last
failing backtrack.
I'm not sure if what I've offered will help, but its worth a try.
Even after carefully rearranging all the parsers
it seems impossible to get this particular error to bubble up to the
top.
Yes, I've found it impossible to force attoparsec to fail a parse.
I think that is intended as a feature.
The thing is, as soon as I see an unexpected suffix I know I can
fail entirely right there, with exactly that error msg, but since
there's no way to turn off backtracking I think there's no way to do
that.
Yes, that's my impression.
snip
I
originally used parsec, but parsing speed is my main bottleneck, so I
don't want to give ground there.
We you using Parsec as a token parser or as a Char parser. Obviously
the second is going to be slow in comparison to the first.
I've heard some good things about traditional alex+happy...
of course it would mean a complete rewrite but might be interesting.
I've user Alex with both Parsec and Happy, where speed was strong
secondary goal. Personally I much prefer Parsec; IMO its easier to debug
and extend and modify that Happy based parsers. I also know some people
prefer Happy.
Has anyone compared the performance of attoparsec vs. alex+happy?
I haven't, nor have I compared those two with alex+parsec. It would
be an interesting experiment.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: io-streams 1.0.0.0
s9gf4ult wrote: Is this something like conduits ? Yes, its also a bit like Iteratee, Enumerator, Pipes and Machines. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is the haksell-pkg-janitors group on github alive?
Jan Stolarek wrote: Does anyone know if haksell-pkg-janitors group on github is alive? I've submitted a pull request a week ago but no response so far. I'm in the haksell-pkg-janitors group. Unfortunately there doesn't seem to be a way of getting pull request notifications. Anyway, applied all your patches. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] performance question
wren ng thornton wrote: Regexes are powerful and concise for recognizing regular languages. They are not, however, very good for *parsing* regular languages; nor can they handle non-regular languages (unless you're relying on the badness of pcre). In other languages people press regexes into service for parsing because the alternative is using an external DSL like lex/yacc, javaCC, etc. Whereas, in Haskell, we have powerful and concise tools for parsing context-free languages and beyond (e.g., parsec, attoparsec). This cannot be emphasized heavily enough. Once you have learnt how to use one or more of these parsec libraries they will become your main tool for parsing everything from complex input languages like haskell itself, all the way down to relatively simple config files. Parsec style parsers are built up out of small composable (and more importantly reusable) combinators, that are easier to read and easier to maintain than anything other than the most trivial regex. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Substantial (1:10??) system dependencies of runtime performance??
Nick Rudnick wrote: thanks for the interesting info. I quite often have processing of CSV file data of about 100M-1G done. What library are you using to process the CSV? I have had problems with excessive laziness causing processing of a 75Meg CSV file consuming 500+ megabytes and after I fixed it memory usage dropped to under a megabyte. Processing time dropped from over 10 minutes to about 2 minutes. I blogged my problem and solution here: http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/my_space_is_leaking.html I probably need to revisit that because the problem can probably be fixed without deepseq-generics and just using BangPatterns. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Substantial (1:10??) system dependencies of runtime performance??
Ozgun Ataman wrote: If you are doing row-by-row transformations, I would recommend giving a try to my csv-conduit I was using csv-conduit. If you're keeping an accumulator around, however, you may still run into issues with too much laziness. This was the problem which I solved with deepseq-generic. However, I suspect deepseq-generic was a bigger hammer than was actually needed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Suggestiong for inter-thread communication
Hi all, I am in the process of writing a Haskell program consisting of two threads, one for performing a calculation and one for an Ncurses UI (haskell-ncurses). The calculation thread needs to feed a stream of numbers back to the UI thread (about 1 value per second) and the UI needs to take input from the user and will pass parameter changes to the calculation thread using an IORef and atomicModifyIORef. However, I'm not sure how to hande the UI thread. The UI thread would normally wait for Ncurses input using getEvent, but I need advice on how to the the data from the calculation thread. Any advice or things to try? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestiong for inter-thread communication
Thiago Negri wrote: Do you need advice on what? I didn't understand your last phrase. Well I have data from two sources, stdin and the calculation thread. If I was doing this in C, I'd probably use a pipe for the calculation data and then do select on the two file descriptors. There is a select package: http://hackage.haskell.org/package/select but I was wondering if there was a more idiomatic Haskell way of dealing with inputs from more than one source. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type error when trying to adapt http-proxy to new conduit
Pieter Laeremans wrote: Hi, The http-proxy package isn't compatible any longer with the latest conduit. Since it is open source, I thought, I might as well try to adapt it and submit a patch. Have you looked int git? It currently compiles from git but there is a space leak that I haven't managed to fix yet. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Tagging subjects of emails sent from the list
Johan Tibell wrote: I'd prefer if they weren't tagged. My mail reader (GMail) can do the tagging for me and I'll end up with duplicated tags and the list of subjects get harder to scan. I'm with Johan. I have tools to sort the list mail and would prefer not to have redundant stuff obscuring the subject line. I see you're using KMail. Surely that has automatic filtering facilities? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
Carter Schonwald wrote: hey all, It seems to me (and i've certainly heard other people echo this sentiment) that: ghc dev chatting gets buried in the huge volume of commit + build report emails, and that creates (perhaps) another barrier to involvement in ghc dev at the hobbyist (rather than part time/full time ) scale? So my question for the community (and of course current ghc devs ) 1) do others agree that theres value in separating the two? 2) would this just be another use of the ghc-users list or would it be worth having a ghc-dev list? 3) most importantly, would the folks actively involved in ghc dev be willing/able to do so? +1 This is a good idea, one that I have solved at my end using Procmail. So even though I have solved it for me, I still approve of this suggestion since it seems silly to push this to the receiver's end when it could so easily be solved by having separate lists. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Cabal failures...
kudah wrote: Personally, I successfully use Wine to build, ship and test for Windows. There are some pitfalls related to -optl-mwindows and encodings, but, if you launch your program with $LANG set to proper windows encoding like cp1251 and the std handles closed with 0- 1- 2-, it should crash on related errors the same way as on windows. I am not (yet) aware of any Haskell programs that don't run under Wine. Thats a very interesting solution. I use Wine to run the test suite when I cross compile one of my C projects from Linux to Wine. Would you consider documenting the process of setting everything up to build Haskell programs under Wine on the Haskell Wiki? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Quasiquotation page on HaskellWiki needs updating
Hi all,
It seems the Quasiquotation page on HaskellWiki
http://www.haskell.org/haskellwiki/Quasiquotation
has fallen behind the actually Quasiquotation implementation that
is in ghc-7.4.2 and later.
Specifically, the QuasiQuoter constructor that the Wiki takes two
parameters:
data QuasiQuoter
= QuasiQuoter
{ quoteExp :: String - Q Exp
, quotePat :: String - Q Pat
}
while the one in ghc-7.4 and later takes four:
data QuasiQuoter
= QuasiQuoter
{ quoteExp :: String - Q Exp
, quotePat :: String - Q Pat
, quoteType :: String - Q Type
, quoteDec :: String - Q [Dec]
}
I'm just starting out with quasquotation and am not yet qualified
to update this page myself.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Survey: What are the more common Haskell IDEs in use ?
Dan wrote: Because I see there are many preferences on what IDE to use for Haskell I've created a quick survey on this topic. Please click here and select your choices from the lists. http://kwiksurveys.com/s.asp?sid=oqr42h4jc8h0nbc53652 Any comments/suggestions are welcome. I use Geany which is not on the list. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal failures...
Albert Y. C. Lai wrote: Clearly, since 90% of computers have Windows, it should be trivial to find one to test on, if a programmer wants to. Surely every programmer is surrounded by Windows-using family and friends? (Perhaps to the programmer's dismay, too, because the perpetual I've got a virus again, can you help? is so annoying?) We are not talking about BeOS. Therefore, if programmers do not test on Windows, it is because they do not want to. I have been an open source contributor for over 15 years. All the general purpose machines in my house run Linux. My father's and my mother-in-law's computers also run Linux (easier for me to provide support). For testing software, I have a PowerPC machine and virtual machines running various versions of Linux, FreeBSD and OpenBSD. What I don't have is a windows machine. I have, at numerous times, spent considerable amounts of time (and even real money for licenses) setting up (or rather trying to) windows in a VM and it is *always* considerably more work to set up, maintain and fix when something goes wrong. Setting up development tools is also a huge pain in the ass. And sooner or later they fail in some way I can't fix and I have to start again. Often its not worth the effort. At my day job we have on-demand windows VMs, but I am not officially allowed (nor do I intend to start) to use those resources for my open source work. So is it difficult for an open source contributor to test on windows? Hell yes! You have no idea how hard windows is in comparison to say FreeBSD. Even Apple's OS X is easier than windows, because I have friends who can give me SSH access to their machines. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal failures...
Albert Y. C. Lai wrote: This counter-argument is flawed. Why limit oneself to one's own household? (Garage? Basement?) Get out more! Visit a friend. If that friend is not a coder, they are unlikely to have the dev tools installed. Talk to an internet cafe owner for a special deal to run one's own programs. Ditto. Rent virtual machine time in the cloud. I've already thrown a bunch of money at the microsoft machine for very poor results. If someone else set up and ran windows VMs and gave me access that would make testing on windows far more attractive. I just found that Amazon AWS has a free teir that includes windows as an option: https://aws.amazon.com/free/ Its still a huge sink of time and effort to set one up to a state where its ready to build haskell packages. Maybe if someone set up a github project that contained a script that could be downloaded onto a bare windows machine and then bootstrap that machine into a full haskell dev machine you might see some progress on this front. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curl package broken in Windows
Kevin Cantu wrote: With the curl package on Hackage, I merely need an SSL enabled version of libcurl, and every Linux distro I've tried this on has several variations of such a package. (You have a choice of OpenSSL or GNUTLS, for example.) I tried the CURL bindings on Linux some time ago and I personally found the thing pretty much un-usable. The API was incomplete, inconsistent and way too close to the C API. However, I have had much better luck with Michael Snoyman's http-conduit package, which being pure Haskell (ie no C) should be much easier to install on windows. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems installing DPH
Janek S. wrote: Gogling the error message leads to various LLVM pages, which suggests that LLVM is the problem. I'm using Debian Squeeze with LLVM 2.6 and I'm thinking that maybe DPH needs newer version. From memory the first version of LLVM to support the GHC custom calling convention was llvm-2.7. Debian Squeeze is also quite old now (ghc-6.12?) and DPH performance has been improved quite significantly in the 7 series of compilers. HTH, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Darcs on Windows 7
Vasili I. Galchin wrote: Hello Haskellers, I installed darcs on a Windows 7 machine. A darcs folder was created under Program Files(x86) folder. However, when I pull up Program... on the left side, darcs not there for me to run it. Why? Is darcs run only from the CLI? Yes, darcs is a command line program. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: GHC 7.6.1 Release Candidate 1
Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 7.6.1: http://www.haskell.org/ghc/dist/7.6.1-rc1/ This includes the source tarball, installers for 32bit and 64bit Windows, and bindists for amd64/Linux, i386/Linux, amd64/OSX and i386/OSX. Please test as much as possible; bugs are much cheaper if we find them before the release! On PowerPc I get this: compiler/nativeGen/X86/Regs.hs:61:1: Warning: The import of `CmmCallConv' is redundant except perhaps to import instances from `CmmCallConv' To import instances alone, use: import CmmCallConv() which in HEAD was fixed by the application of this patch: commit 2f7c578574a9d5e9b4d95847abc3d1cb1b35336d Author: Erik de Castro Lopo er...@mega-nerd.com Date: Wed Aug 8 06:44:00 2012 +1000 Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Benchmark of DFT libraries in Haskell
Takayuki Muranushi wrote: * vector-fftw with wisdom was more than 1/2 times faster than fftw in C with wisdom (and with communication overhead.) I would be suspicious of that result. Calling a C function from a library should be slower from Haskell than from C. Sorry for the confusion, What I meant is that vector-fftw version takes more time than C version, but less than twice. That makes much more sense. Whether you're calling fftw from C or from Haskell, its still the fftw library doing most of the work. As you increase the FFT length, the difference between C and Haskell should decrease. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Benchmark of DFT libraries in Haskell
Takayuki Muranushi wrote: * vector-fftw with wisdom was more than 1/2 times faster than fftw in C with wisdom (and with communication overhead.) I would be suspicious of that result. Calling a C function from a library should be slower from Haskell than from C. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC ARM builds?
Karel Gardas wrote: Last note: GHC/ARM depends on GHC's specific calling convention support in LLVM. Unfortunately for ARM platform it was merged into LLVM 3.0, but not into LLVM HEAD (at that time), so LLVM 3.1 doesn't support GHC/ARM at all. I'm trying to resubmit the support for inclusion here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/051119.html -- but it's still not merged in. Karel, its probably time you pinged them again asking for that to be merged :-). Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] GHC users on PowerPC and *BSD/Darwin?
Hi all, Users of GHC on PowerPC would probably be aware of this bug: http://hackage.haskell.org/trac/ghc/ticket/2972 which causes GHCi to segfault as soon as it was started. Ben M. Collins has come up with a fix for this I am preparing it for submission to the GHC git tree. I have have tested it on linux-powerpc, but would also like to test it on *BSD/Darwin. Anybody out there interested? You will need: * A PowerPC machine running *BSD or Darwin. * A working GHC compiler. If you're interested email me at erikd AT mega-nerd dot com. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] GHC users on PowerPC and *BSD/Darwin?
Hi all, Users of GHC on PowerPC would probably be aware of this bug: http://hackage.haskell.org/trac/ghc/ticket/2972 which causes GHCi to segfault as soon as it was started. Ben M. Collins has come up with a fix for this I am preparing it for submission to the GHC git tree. I have have tested it on linux-powerpc, but would also like to test it on *BSD/Darwin. Anybody out there interested? You will need: * A PowerPC machine running *BSD or Darwin. * A working GHC compiler. If you're interested email me at erikd AT mega-nerd dot com. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC ARM builds?
Austin Seipp wrote: With 7.4.2, the patches for full ARM linker support were merged and released. Are there any official builds of GHC for Linux/ARM yet? I have a PandaBoard ES I'd be willing to contribute for builds and/or testing/development, but I don't know where to get a GHC for bootstrapping. It's also worth asking if there's any page documenting needed prerequisites/expected build environment. If not it should be added to the wiki (I don't see any as of right now.) I'm not sure what linux distro you're rinning on that, but if you run Debian (probably also Ubuntu) then you can apt-get a working GHC. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Which mailing list for GHC hacking discussion?
Hi all, For GHC development questions (ie hacking on GHC, not with GHC) which is the appropriate mailing list ghc-cvs or ghc-users? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Long-running request/response protocol server using enumerator/iterator/iterIO/pipes/conduits/...
Michael Snoyman wrote: That's the reason I added connect-and-resume to conduit. I use the technique in warp[1], which in fact *does* support multiple request/response pairs due to connection keep-alive. But the code base isn't the easiest introduction to the technique. If there's interest, I'll try to put together a blog post on using connect-and-resume to solve this kind of problem. +1 Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cvs-ghc mailing list silently dropping my mails
Hi all, I've been trying to send mail to the cvs-ghc mailng list and the list seems to be silently dropping my emails. I have: a) Made sure I was sending mail with the subscribed from address. b) Unsubscribed and re-subscribed and tried again. All to no avail. Is there a moderation queue on that list that needs to be seen to? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Guide for converting existing code to Conduit 0.4?
Hi all, Is there some sort of a guide for converting existing code Conduit 0.4? What happened to Control.Monad.Trans.Resource.with? What happens to stuff that used to to have a type C.Source m a which now seems to need type C.Pipe Void a (ResourceT m) a? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
Dmitry Olshansky wrote: I transfered my code from 0.3 to 0.4 without any changes. There are type synonyms in Conduit for that. Changes were from 0.2 to 0.3. Michael discribed it here http://www.yesodweb.com/blog/2012/03/announcing-conduit-0-3 Ok, so Control.Monad.Trans.Resource.with gets replaced with Control.Monad.Trans.Resource.allocate. Actually, in 0.4 no changes with Control.Monad.Trans.Resource. type Source m a = Pipe Void a m () old Conduit-API use type synonyms and not changed My code has a lot of low level Conduit stuff and hence I run into a bunch of the lower level issues. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
Michael Snoyman wrote: Hmm... I'd be surprised if you really need the Pipe signature that you're providing. I'm not providing it, the compiler is suggesting it: Network/HTTP/Proxy.hs:835:47: Couldn't match expected type `ByteString' with actual type `()' Expected type: C.Pipe Void ByteString (ResourceT IO) ByteString Actual type: C.Source (ResourceT IO) ByteString In the return type of a call of `requestBody' In the second argument of `($)', namely `requestBody req' For the code: HC.requestBody = HC.RequestBodySource contentLength $ fmap copyByteString $ Wai.requestBody req but the type of the RequestBodySource constructor and Wai.requestBody hasn't changed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal-install problem with alex dependency in bytestring-lexing
Hi all, With a base system with just ghc and cabal-install, if I try to install bytestring-lexing I get: $ cabal install bytestring-lexing Resolving dependencies... Configuring bytestring-lexing-0.4.0... cabal: The program alex version =2.3 is required but it could not be found. cabal: Error: some packages failed to install: bytestring-lexing-0.4.0 failed during the configure step. The exception was: ExitFailure 1 The cabal file for bytestring-lexing contains Build-Tools: alex = 2.3 Is there any way to make the cabal install of bytestring-lexing force the install of alex first? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-install problem with alex dependency in bytestring-lexing
Joachim Breitner wrote: no, cabal-install does not automatically install build-tools at all, only Cabal checks them for compilation. I guess the reason is that build-tools needs to be put on the PATH, and that is beyond the scope of cabal-install. This is rather sub-optimal. One place where people are running into this problem is when installing Yesod. Yesod depends on warp which depends on bytestring-lexing which requires alex at build time. The problem is that many of the people trying out Yesod are newcomers to Haskell. They are going to try cabal install yesod and have it fail because alex is missing. This is not a good introduction Haskell/Yesod. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-install problem with alex dependency in bytestring-lexing
Ivan Lazar Miljenovic wrote: One trivial solution is to assume ~/.cabal/bin is on the PATH and to ignore system-wide packages, which I think is even *more* sub-optimal (why install a new version of alex when it's already available?). The tool should only install alex in ~/.cabal/bin if alex is not already available. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Impact of try on Parsec performance
Omari Norman wrote: So my question is: what is the practical impact of using try? My experience is based mostly on trying to improve the error location reporting in Ben Lippmeier's DDC compiler. What I found was that removing Parsec.try's almost always resulted in the parser generating better location information. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Using 'git bisect' on the GHC tree
Hi all, I am trying to track down a build failure on PowerPC that was introduced some time this year. Usually, the easiest way to do this is by using 'git bisect'. Unfortunately, this doesn't work with the GHC tree since its easy to go to a GHC revision which is incompatible with one of the many GHC sub-modules (eg Cabal). Given a GHC git commit hash, is there a way to get the various libraries into a state where I can build the GHC version specified by the hash? Regards, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using 'git bisect' on the GHC tree
Erik de Castro Lopo wrote: Given a GHC git commit hash, is there a way to get the various libraries into a state where I can build the GHC version specified by the hash? As suggested by this: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate and some help from Igloo on #ghc, I grabbed a build log from http://darcs.haskell.org/ghcBuilder/builders/tn23/534/4.html and generated a fingerprint file from that. I then did ./utils/fingerprint/fingerprint.py restore -f tn23build534.fp and tried to build it, but was still thwarted by the following: Configuring Cabal-1.13.3... ghc-cabal: At least the following dependencies are missing: base =4 3 =2 5, filepath =1 1.3 make[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 make: *** [all] Error 2 At this point I think I basically have to give up on using git bisect which I have found so useful on other projects. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] [Haskell] ANNOUNCE: hs-json-rpc 0.0.0.1
Felipe Almeida Lessa wrote: [Redirecting to haskell-cafe] Congrats on your first release! While I haven't looked into your package in more depth, I'd suggest taking a look at http-conduit [1]. While I don't know of any benchmarks, it should be faster or at least as fast the HTTP package. It's also used by many people everyday (myself included), which means that it has no major bugs and that bugs are promptly solved. It also has some features that HTTP doesn't. +1 on http-conduit. I think the main feature that http-conduit has which HTTP lacks is support for secure HTTPS operations. With http-conduit being part of the Wai/Warp/Yesod stack I believe this is a high tested and rigorously maintained piece of code. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Michael Snoyman wrote: Actually, this is just a setting: you can override with checkStatus[1]. [1] http://hackage.haskell.org/packages/archive/http-conduit/1.2.4/doc/html/Network-HTTP-Conduit.html#v:checkStatus Absolutely! I use that in my http-proxy package [0]. Elegant and easy to use. Erik [0] http://hackage.haskell.org/package/http-proxy -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit experiment: Is this correct?
Ertugrul Söylemez wrote: Thanks a lot. This conduit world is really new to me and feels a bit more complicated than enumerators, but at least I seem to be getting the right intuition. I can assure you that while this may be true for simple cases, it most definitely is not true for at least one more complex case. I have a hackage package http-proxy which initially used Enumerator and now uses Conduit. The Enumerator version was extremely difficult to figure out and eventually required a function like this: enumIteratee :: MonadIO m = Int64 - (Int - Iteratee ByteString m ByteString) - Enumerator ByteString (Iteratee ByteString m) c with an Iteratee nested inside an Enumerator. The Conduit version was much easier to put together because conduits seem to compose much more naturally. IMO, Conduit is a significant improvement over Enumerator but a better solution may still exist (I'm interested in seeing how Pipes work out). Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: bytestring-lexing 0.4.0
wren ng thornton wrote: -- Changes (since 0.3.0) * Data.ByteString.Lex.Integral: added the function readDecimal_ :: Integral a = ByteString - a A variant of readDecimal which does not return the tail of the string, and returns 0 instead of Nothing. This is twice as fast for Int64 on 32-bit systems, but has identical performance to readDecimal for all other types and architectures. Thanks Wren, that is awesome! Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: bytestring-lexing 0.3.0
Wren, I notice that readDecimal has a typesig: readDecimal :: Integral a = ByteString - Maybe (a, ByteString) which I would then use in Warp as: readInt64BSL :: ByteString - Int64 readInt64BSL bs = fst $ fromMaybe (0, ) $ BSL.readDecimal bs However, this version with the fromMaybe and fst is a little slower than if these two extra bits weren't necessary. Would you consider a function with the following signature in bytestring-lexing? readDecimalX :: Integral a = ByteString - a The idea is that it gives something faster for applications like Warp where reading an valid decimal should be as fast as possible, but if the string isn't valid it doesn't really matter what the result is. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
Yves Parès wrote: Yes, and IMO this is a growing problem. Since iteratees were designed, a lot of different libraries providing this kind of service have appeared. Thats mainly because the solution space was new and lots of unexplored terrain. Or else, we have to make sure that each one (iteratee, enumerator, conduit, pipes...) has its own set of associated packages and that each provide equivalent functionalities, but then = combinatorial explosion. There really isn't a combinatorial explosion, but rather a small number of families of packages. ^^ It's just I don't want people to start trolling by applying to Haskell the adage I've heard quite a few times about Java, stating that There are 50 ways to achieve something... none of which is good. Java has been around 20 years. The iteratee/enumerator/iterio/conduit/pipes idea has really only been around for a couple of years and I would be surprised it one of them (or a new one combining the best features of the others) doesn't come out the clear winner in the next year or two. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
Felipe Almeida Lessa wrote: I find it funny that conduit is said to be an iteratee library since it has no iteratees! We've had more than one iteratee library since at least 1.5 years with the iteratee (Mar 2009) and enumerator (Aug 2010) packages, and AFAIK now we have four iteratee libraries: those two, iterIO (May 2011) and pipes (Jan 2012). However, conduit is not the fifth since it has no iteratees, no enumerators, no enumeratees... it's a different concept, not a different implementation. I mostly agree, but I think the real strength of Conduits is that it removes a lot of the complexity of the other Iteratee libraries. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Michael Snoyman wrote: On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: the fromJust should never fail, beceause of the guard statement: | 300 = code code 400 isJust l'' isJust l' = Just $ req Because of the order of the operators, it will only evaluate fromJust after it makes sure that the argument isJust. That function in particular shouldn't throw any exceptions - it should only return Nothing. Knowing that, I don't quite think I understand what your concern is. Can you elaborate? You're right, but I had to squint really hard to prove to myself that you're right. That's the kind of code that could easily be broken in future updates by an unwitting maintainer (e.g., me). To protect the world from me, I'd prefer if the code didn't have the fromJust. This might be a good place to leverage the Monad instance of Maybe. Maybe fromMaybe is a more grokkable function. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: bytestring-lexing 0.3.0
wren ng thornton wrote: * The readDecimal function in particular has been highly optimized. The new version is wicked fast[1] and perfectly suitable for hot code locations like parsing headers for HTTP servers like Warp. In addition, attention has been paid to ensuring that parsing is efficient for larger than native types like Int64 on 32-bit systems (including 64-bit OS X), as well as Integer. The optimization of this function was done in collaboration with Erik de Castro Lopo, Vincent Hanquez, and Christoph Breitkopf following a blog post by Erik[2] and ensuing discussion on Reddit[3] Thanks Wren. I'm pretty sure that Warp will swap over to use your new readDecimal function. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bindings for libvirt
Ilya Portnov wrote: For my current projects, i'd also like to have bindings to libvirt. I even started to write something for them, using c2hs. If someone is interested, i could put my current (very basic) code to, say, github… +1 Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [C][enums][newbie] What is natural Haskell representation of such enum?
Данило Глинський wrote:
What is natural Haskell representation of such enum?
enum TypeMask
{
UNIT,
GAMEOBJECT,
CREATURE_OR_GAMEOBJECT = UNIT | GAMEOBJECT
};
data ObjectType = Unit | GameObject
creatureOrGameObject :: ObjectType - Bool
creatureOrGameObject Unit = True
creatureOrGameObject GameObject = True
creatureOrGameObject _ = False
More sophisticated question is: and what data structures must be used when
converting this naturally one to Haskell?
// 1-byte flaged enum
enum TypeMask
{
// ...
UNIT= 0x0004,
GAMEOBJECT = 0x0008,
// ...
CREATURE_OR_GAMEOBJECT = UNIT | GAMEOBJECT
WORLDOBJECT = UNIT | PLAYER | GAMEOBJECT | DYNAMICOBJECT | CORPSE
// ... even more enum combos ...
};
Pretty much as above, add all the different single bit masks as
constructors to ObjectType and define functions for the ones
that are a combination of one ore more constructor.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can't install hspec
Hi all, I'm trying to cabal install hspec and I get the following: Resolving dependencies... /tmp/hspec-0.9.04062/hspec-0.9.0/Setup.lhs:2:10: Could not find module `System' It is a member of the hidden package `haskell98-2.0.0.0'. Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: hspec-0.9.0 failed during the configure step. The exception was: ExitFailure 1 This is with ghc-7.2.2. Any clues how I can get around this? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Myles C. Maxfield wrote: I am interested in contributing to the http-conduit library. I've been using it for a little while and reading through its source, but have felt that it could be improved with two features: - Allowing the caller to know the final URL that ultimately resulted in the HTTP Source. +1 - Making the redirection aware of cookies. +1 I'd be happy to do both of these things, I made a couple of small contributions to Michael's http-enumerator library via the Github issue tracker and pull-request mechanism. Michael has always responded relatively quickly and seems very open to suggestions for improvements to his library. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit versions of wai and warp?
Michael Snoyman wrote: However, WAI and Warp are mostly ready now, just needing a bit more testing. If people want to give me some feedback on the readiness of them, and would like them released earlier, I'm definitely flexible. Meanwhile: yes, the Github version is conduit-based. Michael, I'm having some trouble getting the right set of dependencies for Conduit versions of wai and warp. At the moment I'm stuck on asn1-data; every version I can find of that seems to depend on enumerator. Is there a simple recipe somewhere for build conduit versions of wai and warp? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit versions of wai and warp?
Michael Snoyman wrote: We can still have a conduit-based version of WAI and Warp, even if an underlying package uses enumerator. The enumerator usage from asn1-data doesn't leak into WAI or Warp at all[1]. We could ask Vincent to consider moving over to attoparsec-conduit instead, but I don't think there's any strong need for this. Ah, got it now. Thanks. Look forward to this stuff hitting Hackage. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Conduit versions of wai and warp?
Hi Michael, The current versions of wai and warp: http://hackage.haskell.org/package/wai http://hackage.haskell.org/package/warp still seem to be the versions that use enumerator. Any idea when the Conduit versions might show up on Hackage? Until then, should I be grabbing these packages from Github? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing a text editor swap file
Matthew Farkas-Dyck wrote: http://hackage.haskell.org/package/bytestring-mmap Since he's editing text, its a pity there isn't a text-mmap package :-). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing a text editor swap file
Martin DeMello wrote: Further question - my internal data representation is a vector of strings (it's a line-based editor). String or ByteString or Text? If its either of the first two, I think you should definitely look at Text. Is there a more efficient strategy to keep an mmap buffer in sync with the vector than simply allocating some large fixed size per line? Very much dependent on whether you are using String or one of the other two I would think. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing a text editor swap file
Martin DeMello wrote: Just plain String, mostly because it's what Gtk.Entry works with. I'll take a look at Text. Ah, maybe not. If your output representation *has* to be String its probably not worth using Text as an internal representation. I suspect that Gtk should really be updated to allow the use of Text instead of String. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bindings for libvirt
Gaius Hammond wrote: The author of libvirt, Richard Jones, is an OCaml hacker. libvirt has many authors. See the git repo commit history: http://libvirt.org/git/?p=libvirt.git;a=summary Richard Jones is however the the main author of the Ocaml bindings: http://libvirt.org/ocaml/ChangeLog.txt Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Browser and Network.TLS
Felipe Almeida Lessa wrote: On Mon, Jan 16, 2012 at 6:28 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I am interested in extending the Network.HTTP code in the HTTP package to support HTTPS via TLS. [snip] I am left with the conclusion that it is impossible to support TLS in Network.Browser without breaking many Haskell programs. It is obviously possible to fork the HTTP library, but I'd like to improve the state of the existing libraries. Likewise, it is possible to create a new module that supports HTTPS but has different typed functions and lots of code duplication with Network.Browser, but that is quite inelegant. If you need Network.Browser's functionality, it would be great if it could be ported to work with http-conduit. I wouldn't consider using HTTP on any production code. +1 Perhaps I should just use the Network.HTTP.Enumerator module and not deal with Network.Browser? Maybe I'm going about this in entirely the wrong way. What are you trying to do? On most cases http-conduit has everything you need. Specifically: http://hackage.haskell.org/packages/archive/http-conduit/latest/doc/html/Network-HTTP-Conduit.html Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage trac broken
Bas van Dijk wrote: On 15 January 2012 12:01, Joachim Breitner nome...@debian.org wrote: Is this known and will it be fixed? It was shut down because of massive spamming: http://www.haskell.org/pipermail/cabal-devel/2012-January/008427.html I have no idea who's working on it and when it will be up again. Aw gee! Now I'm going to get blamed for shutting down the hackage trac when all I did was report spam on it. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bindings for libvirt
Michael Litchard wrote: Due to the direction things are going at work, I have become interested in Haskell bindings for libvirt. Noticed that this hasn't been done yet. Interesting! I was wondering if this was due to lack of motivation, or if there were some difficult hurdles with libvirt that make the project cost-prohibitive. Well there are already Ocaml bindings for libvirt http://libvirt.org/ocaml/ so its most likely the former. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bindings for libvirt
Michael Litchard wrote: That's encouraging! In fact, since FFI bindings are usually easier in GHC Haskell than in Ocaml, you should have it done by the end of the week :-). Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A simple telnet client using Conduit
Hi all, I've written a simple telnet client using Michael Snoyman's Conduit library and was looking for comments as to whether I'm doing it right. In particular, is my usage of a ResourceT to track a thread a good idea, necessary or waste of time. The code is here: https://gist.github.com/1596792 Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple telnet client using Conduit
Thanks for the input Felipe. Felipe Almeida Lessa wrote: On line 29, instead of liftIO $ do mapM_ ... runResourceT $ do Well that was because that whole block needs to run in IO. Regarding threads, you should use resourceForkIO [1] which has a quite nicer interface. I did read about resourceForkIO and it says: Introduce a reference-counting scheme to allow a resource context to be shared by multiple threads. Once the last thread exits, all remaining resources will be released. In my case, I don't have any resources that are shared between threads. All I have is the actual ThreadId returned by forkIO. Since that ThreadId actually isn't used explicitly anywhere (but is implicitly passed to killThread when release releaseThread is called). The other thing about your solution is the question of what happens to the ThreadId returned by resourceForkIO. Rewriting your solution to explicity handle the ThreadId I get: telnet :: String - Int - IO () telnet host port = runResourceT $ do (releaseSock, hsock) - with (connectTo host $ PortNumber $ fromIntegral port) hClose liftIO $ mapM_ (\h - hSetBuffering h LineBuffering) [ stdin, stdout, hsock ] tid - resourceForkIO $ sourceHandle stdin $$ sinkHandle hsock sourceHandle hsock $$ sinkHandle stdout liftIO $ killThread tid release releaseSock The problem here is that I am not sure if the explicit killThread is actually needed and it is, I think my solution, where killThread happens automatically is actually better. If what happens within the outer call to resourceT is a long running process, your solution (in the absence of the explicit killThread) could leave threads lying around that would have been cleaned up much earlier in my soltuion. Thoughts? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple telnet client using Conduit
A new solution that drops two 'runResourceT' calls: telnet :: String - Int - IO () telnet host port = runResourceT $ do (releaseSock, hsock) - with (connectTo host $ PortNumber $ fromIntegral port) hClose liftIO $ mapM_ (\h - hSetBuffering h LineBuffering) [ stdin, stdout, hsock ] (releaseThread, _) - with (forkIO $ runResourceT $ sourceHandle stdin $$ sinkHandle hsock) killThread sourceHandle hsock $$ sinkHandle stdout release releaseThread release releaseSock Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple telnet client using Conduit
Felipe Almeida Lessa wrote: What about inverting which thread gets to do what? _ - resourceForkIO $ sourceHandle hsock $$ sinkHandle stdout sourceHandle stdin $$ sinkHandle hsock release releaseSock Thats an interesting idea. Unfortunately this doesn't work correctly in that if the server disconnects, the client doesn't detect it and hangs with one end of the connection closed. Actually, I'm not sure if my solution is better or worse than yours. The question is how long does it take for the thread to die after hsock gets closed? If the answer is right away, then my solution is simpler =). Otherwise, you solution is less resource-hungry. Well GHC runtime threads are very cheap while sockets/file descriptors are in comparison a very much limited resource. That means that code should be written to clean up sockets/fds in preference to cleaning up threads. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] feed release plan
Simon Michael wrote: - the repo will be moved to github, under my account since I don't think there's a haskell community one Haskell package janitors might be an appropriate one: https://github.com/haskell-pkg-janitors Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Composing Enumeratees in enumerator
Michael Craig wrote: I've been looking for a way to compose enumeratees in the enumerator package, but I've come up with nothing so far. I want this function (=$=) :: Monad m = Enumeratee a0 a1 m b - Enumeratee a1 a2 m b - Enumeratee a0 a2 m b I think part of the problem here is that Enumeratee is defined as: type Enumeratee ao ai m b = Step ai m b - Iteratee ao m (Step ai m b) If you expand out your type signature you get: (=$=) :: Monad m = (Step a1 m b - Iteratee a0 m (Step a1 m b)) - (Step a2 m b - Iteratee a1 m (Step a2 m b)) - (Step a2 m b - Iteratee a0 m (Step a2 m b)) which to me looks rather painful to implement. I've been looking at the iterIO package as a possible alternative, because it seems to allow easy composition of Inums (enumeratees). I'm a little skittish of it because it seems unpopular next to enumerator. Thoughts on these issues? I think these issues are actually common to all implementations of the Iteratee concept. Basically they do not compose as nicely and as cleanly as they would be expected to. I recently ran into this difficulty in composition in my project which was solved by nesting an iteratee inside an enumerator. https://github.com/erikd/http-proxy/commit/7377c1cc695b21b7c13b823abc6c3358a978 There is work being done to address these issues. See Michael Snoyman's work on Conduits: https://github.com/snoyberg/conduit Cheers. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapping an Enumerator
Kannan Goundan wrote: You're right -- now that I think about it, I don't really care what the type of 'r' is. (Boy, I could have saved several hours today if I had realized that earlier :-) I seem to be hitting exactly the same problem. I constrain my types too early and the compiler can't find a solutuon. If I then relax the cionstraints, GCH says ok, here's something that fits, Wonder if I can use a forall in the definition of MyRequestBody to fix things without introducing an externally visible type parameter... That may indeed help. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
MigMit wrote: Dec 20, 2011, в 14:40, Jesse Schalken jesseschal...@gmail.com написал(а): If you think a value might not reduce, return an error in an error monad. Then the caller is forced to handle the case of an error, or propagate the error upwards. The error can also be handled in pure code this way, whereas bottom can only be handled within the IO monad. So... this imaginary language of yours would be able to solve the halting problem? Depends on what you mean solve the halting problem. Agda and Coq are two languages that will only compile programs that can be proven to terminate. Non terminating programs are rejected. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Weird interaction between literate haskell, ghci and OverloadedStrings
Joachim Breitner wrote: it does not seem to be related to literate haskell, if I copy the code from your file into a .hs without the , ghci still does not activate the OverloadedStrings extension when loading the file. I hadn't noticed that. I’d consider this a bug until the developers explain why this should or cannot be different, and suggest you file it as such. I agree. I've lodged a bug report here: http://hackage.haskell.org/trac/ghc/ticket/5673 Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
