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-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: [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: [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
[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
[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
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
[Haskell-cafe] Weird interaction between literate haskell, ghci and OverloadedStrings
Hi,
I'm working on a literate haskell document (actually TeX, but the
example below is just test) and I'm using ByteStrings in the code.
I know I can do:
ghci -XOverloadedStrings file.lhs
or, after ghci is running I can do:
Main :set -XOverloadedStrings
but I'd like to embed a directive in the file so that when loaded
in GHCi, I will automatically get OverloadedStrings. This is mainly
so that it JustWorks(tm) when I pass the file on to someone else.
Is there a way to do this?
There is a short example file below. I'm using ghc-7.0.4 from Debian
testing.
Cheers,
Erik
--8--8--8--8--
{-# LANGUAGE OverloadedStrings #-}
This is just text that that ghc/ghci should ignore
import Data.ByteString (ByteString)
import qualified Data.ByteString.Char8 as BS
Simple function:
newlineCount :: ByteString - Int
newlineCount bs = BS.foldl foldFun 0 bs
where foldFun s ch = if ch == '\n' then s + 1 else s
Once this file is loaded, I should be able to do this:
newlineCount abcd\ncdead\nasdasd\n
--8--8--8--8--
--
--
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
Ivan Lazar Miljenovic wrote: Add :set -XOverloadedStrings to a (possibly local) .ghci file? It doesn't contain it within the same document, but then if it's a local one you could also add :load file.lhs in there so that you just have to type ghci. Unfortunately, thats no better than telling people do: ghci -XOverloadedStrings file.lhs Probably worse actually. 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] Poll: Do you want a mascot?
heathmatlock wrote: Question: Do you want a mascot? No. I also really think this poll should have been in a web site somewhere and not on this 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] Proposed change to mime-mail
Erik Hesselink wrote: Hi all, I've found and solved a problem with mime-mail, and Michael Snoyman asked me to send a request for feedback to -cafe, so here goes. In short, the issue is with address headers containing 'special' (non-ascii) characters. In mime-mail, these are automatically encoded according to RFC 2047. However, the email address part of an address header is not allowed to be encoded. My patch adds 'from', 'to', 'cc' and 'bcc' fields to the Mail data type, and creates correct headers from these fields. This does make the Mail type a bit larger, so I've also added a smart constructor with initializes these fields with empty lists (only 'from' is required). For more details, see my initial bug report [1] and my patches in the pull request [2]. If you have any comments on this change, please let me know. +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] Is SmallCheck maintained?
wren ng thornton wrote: I don't know whether it's being maintained either, but I'm willing to help with the janitorial work since I use smallcheck and lazy-smallcheck quite a lot and think they should be better advertised/used. Hi Wren, Sounds like a job for the haskell-pkg-janitors group: https://github.com/haskell-pkg-janitors/ Feel free to join in. 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] hello Haskell
R J wrote: hey Haskell this is nuts http://www.business10i.com hey Haskell this is nuts ://xxx.xxx.xxx Maybe its time to moderate all newcomers to this list, at least until they post one non-spam message to the list. If you need volunteers to do this moderation I'll stick my hand up. 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] haskell-janitors (was Re: New rss maintainer)
Conrad Parker wrote: I like the janitors idea because it is practical, and I also like the ideal world where every package has an active maintainer. How about we set up the haskell-janitors github group as Vincent suggests, with some basic rules like: Just to make its intent more obvious, I would suggest the name haskell-pkg-janitors. 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] hello Haskell
Daniel Fischer wrote: On Monday 24 October 2011, 03:54:09, Erik de Castro Lopo wrote: R J wrote: hey Haskell this is nuts http://www.business10i.com hey Haskell this is nuts ://xxx.xxx.xxx Maybe its time to moderate all newcomers to this list, at least until they post one non-spam message to the list. Just for the record, not a newcomer, and has non-spam messages, e.g. http://www.haskell.org/pipermail/haskell-cafe/2010-May/077871.html http://www.haskell.org/pipermail/haskell-cafe/2010-May/078054.html That suggests a hijacked account. Such accounts could still be put under moderation. 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 New primop
Paul Monday wrote: I didn't know about glasgow-haskell-users, thanks! Actually the ghc-cvs list may be even better. 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] ghc 7.2.1 and super simple DPH
Peter Braam wrote:
Hi -
I'm trying to compile DotP.hs from
http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell#A_simple_example
(see
below)
The compiler complains and says (twice in fact):
DotP.hs:17:33: Not in scope: `fromPArrayP'
Could someone help me out please? Thanks a lot!
The code you posted had some wrapping issues and was missing an
import. I've included a version of the code that compiles for
me here (using ghc fromgit HEAD) using:
ghc -c -Odph -fdph-par DotP.hs
HTH,
Erik
{-# LANGUAGE ParallelArrays #-}
{-# OPTIONS_GHC -fvectorise #-}
module DotP (dotp_wrapper) where
import qualified Prelude
import Data.Array.Parallel
import Data.Array.Parallel.Prelude
import Data.Array.Parallel.Prelude.Double
dotp_double :: [:Double:] - [:Double:] - Double
dotp_double xs ys = sumP [:x * y | x - xs | y - ys:]
dotp_wrapper :: PArray Double - PArray Double - Double
{-# NOINLINE dotp_wrapper #-}
dotp_wrapper v w = dotp_double (fromPArrayP v) (fromPArrayP w)
--
--
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] ghc 7.2.1 and super simple DPH
Erik de Castro Lopo wrote: The code you posted had some wrapping issues and was missing an import. I should have also mentioned how I figured out what the missing import was. Firstly, I tried hoogle [0] but couldn't find it. I then realised that it must be part of DPH and that I had a copy of the DPH sources on my machine. Going to the DPH source tree I did: find . -name \*.hs | xargs grep ^fromPArrayP which showed up this: dph-common/Data/Array/Parallel.hs:fromPArrayP :: PArray a - [:a:] Cheers, Erik [0] http://www.haskell.org/hoogle/ -- -- 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] Haskell Cloud and Closures
Fred Smith wrote: I've built a little program to compute the plus function remotely by using Cloud Haskell: http://pastebin.com/RK4AcWFM but i faced an unfortunate complication, what i would like to do is to send a function to another host, no matter if the function is locally declared or at the top level. In seems to me that in cloud haskell library the function's closures can be computed only with top-level ones, is it possible to compute the closure at runtime of any function and to send it to another host? I was at the Haskell Symposium where this paper was presented. This limitation is a known limitation and cannot currently be worked around other than my moving whatever is required to the top level. 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] I for one welcome our new Robotic Overlords
Karel Gardas wrote: Hi, On 09/28/11 10:35 AM, Joachim Breitner wrote: Am Mittwoch, den 28.09.2011, 09:30 +0200 schrieb Karel Gardas: Please note GHCi support is still missing... which implies that Template Haskell does not work. So if you are considering using TH in your library when it is avoidable, remember that you are making your code unusable on most non-x86-architectures. Following http://hackage.haskell.org/trac/ghc/wiki/Platforms -- it seems GHCi should be working on x86, x86_64, PowerPC and SPARC. There is ongoing work to make it working on ARM. I happen to know (because I'm trying to fix it) that GHCI is broken (since about 6.8) on PowerPC. 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] Solving the configuration problem with parametrized modules
Joachim Breitner wrote: The big downside is the verbosity of the approach: A lot of parameters need to be passed, and if one such value is suddenly required in a function where it was not before, this function’s signature and all functions using it have to be modified. Also, I expect that the explicit passing causes a small performance penalty. Can't this be mostly solved by putting all these configuration parameters in a struct and then using implicit parameters: http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#implicit-parameters The nice thig about this approach is that is not a single unsafe operation 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
Re: [Haskell-cafe] Decompressing and http-enumerator
Brandon Allbery wrote: On Mon, Aug 29, 2011 at 04:08, Michael Snoyman mich...@snoyman.com wrote: So one possible solution is to just add an option to never decompress response bodies, but that's a bit of a hack. The real question is: what's the correct way to handle these tarballs? Web browsers seem to know not to decompress them, but AFAICT http-enumerator is correctly following the spec by decompressing. Another possibility is to Seem to is pretty much correct; it took years for some browsers to reliably handle them correctly. (Anyone else remember Mozilla saving compressed tarballs uncompressed?) Yes, it was a pain in the neck. 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] Decompressing and http-enumerator
Michael Snoyman wrote: I'm wondering what the most appropriate way to handle this is. Just to get my thoughts in order I'll back track a little. In the HTTP repsonse, we have two header fields, content-type and content-encoding. For the later (which may be absent) we can have encodings of gzip or chunked (possibly others). Some examples: content-type content-encoding current practice === text/html gzip gunzip it in H.E. text/html chunkedunchunk it in H.E. For the case where H.E might be used as part of a HTTP proxy we also have a rawBody option that disables both the unchunking and the gunzipping. This rawBody functionality works now; I'm using it. We now add to the above a file type where the content-type is application/x-tar and the content-encoding is gzipped but from the filename part of the URL, a user may well expect that we get a tar.gz file but where H.E. currently gunzips it on the fly. So, on to your suggestion: Maybe a dontDecompress record, looking like: type ContentType = ByteString dontDecompress :: ContentType - Bool Then browser behavior would be: browserDecompress = (== application/x-tar) and current behavior would be: defaultDecompress = const False I think we should invert the logic of this (to avoid double negatives) so we have: type ContentType = ByteString decompress :: ContentType - Bool browserDecompress = (/== application/x-tar) defaultDecompress = const True Was the idea that this decompress field then gets added to the Request record? If so, would simpleHttp be modified to be: simpleHttp :: String - (ContentType - Bool) - m L.ByteString and exporting both browserDecompress and defaultDecompress so they can be used as two sane defaults for the second parameter? 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] Decompressing and http-enumerator
Michael Snoyman wrote: I think we should invert the logic of this (to avoid double negatives) so we have: type ContentType = ByteString decompress :: ContentType - Bool browserDecompress = (/== application/x-tar) defaultDecompress = const True No objections from me. Was the idea that this decompress field then gets added to the Request record? Yes. If so, would simpleHttp be modified to be: simpleHttp :: String - (ContentType - Bool) - m L.ByteString and exporting both browserDecompress and defaultDecompress so they can be used as two sane defaults for the second parameter? I don't want to go this route actually. I think simpleHttp should have the exact same type signature it has route now (thus living up to the name simple). It likely makes sense to use browserDecompress as the default for simpleHttp, and defaultDecompress as the default for parseUrl. Though I don't really have a strong opinion on this either. In either case, I'm thinking we should rename defaultDecompress to alwaysDecompress (my mistake to start off with), to properly indicate what it does. Ok, I'll prepare a patch along these lines and submit a github pull request. 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] Seeking Don Stewart
wren ng thornton wrote: Hello all, Sorry for the spam. I'm trying to get ahold of Don Stewart, but it looks like there's some hiccup at Galois. When I mail him I get: d...@galois.com: host mail.galois.com[69.30.63.196] said: 550 5.1.1 d...@galois.com... User unknown (in reply to RCPT TO command) Don recently left Galois and is now working for a bank in NYC. Find him on google+. 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] Cleaner way to write code and handle errors?
Ivan Lazar Miljenovic wrote: I don't think you need all those return () everywhere... And at the end, why do you do line - getLine when you don't use the result? The hlint program would have flagged both of those and possibly others. See: http://community.haskell.org/~ndm/hlint/ 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] Software patents covered in GHC?
Manuel M T Chakravarty wrote: That's right, but it doesn't help any of us anything. The costs of defending against a patent claim (even if the claim can eventually be overturned) are much to high to bear for anybody, but major corporations. In other words, it doesn't matter if you are right or wrong if you can't pay the legal bill. This is not just theory as a fair number of mobile app developer recently found out: http://fosspatents.blogspot.com/2011/05/lodsys-sues-7-app-developers-in-eastern.html Yep, patents are a bitch for small independant developers stuck between Apple's onerous AppStore conditions and patent trolls like Lodsys. However, for open source projects like GHC, there are a number of organisations like the Software Freedom Law Center: http://www.softwarefreedom.org/ that provide (at least some) patent defense for open source projects. Its also possible for open source projects to 'design around' patent issues. For instance there was a patent on the VFAT file format implementaion in the Linux kernel that was avoided by careful reading of the patent and working around the patents specifics: http://lwn.net/Articles/338981/ 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] Software patents covered in GHC?
Manuel M T Chakravarty wrote: In fact, you are better of not to know. Given that GHC (like all non-trivial software) surely infringes on some patents, the damages that a patent holder can sue you for are less if you do not know about the patents you are infringing on. IIRC, a plaintiff can triple the charges if they can reasonably show that you have been aware of the patents that you are infringing on. Nasty business! ON the up side, the fact that GHC is Open Source software available from a public repository and a lot of what is in GHC is published in papers which are widely and freely available on the internet means that stuf fthat was in GHC first can never be patented (or at least can be successfully challenged when it is). 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] best way to use ghc-7.0 under debian stable
Hi, bri...@aracnet.com wrote: Currently debian stable installs ghc 6.12.1. Is there any reason you're not using say Debian testing? The Debian Haskell Group (of which I am one of the less active members) is doing a magnificent job in bringing Haskell packages to Debian in the form of proper Debian packages. Debian testing already has ghc-7.0.3 and a huge bunch of libraries. I'd like to use the latest version of repa which is built on ghc 7.0, and my attempts to placate cabal's complaints about the installation of various packages isn't going anywhere. If you are willing to give up Debian packages for all Haskell related stuff you can install the haskell platform from a binary tarball and then use cabal to manage the various Haskell packages. It's not obvious to me that there's an advantage to using debian for ghc Personally, I consider Debian stable really only for critical production servers and low maintenance desktop systems. For a developer, Debian testing or Debian unstable (which is really much more stable than the name suggests) is a better option. Finally, there is the option of pulling Debian source packages from Debian unstable, building them and loading them into your own private repository. I have done that for instance to get ghc-6.12.3 onto a bunch of Ubuntu 8.04 systems. If you are familiar with the Debian packaging system and running a repository, this can work quite well. 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] Reformatter for Show
Ozgur Akgun wrote: Hi Alexey, On 2 May 2011 21:01, Alexey Khudyakov alexey.sklad...@gmail.com wrote: My question is there any tool for reformatting result of show so it could be read by human beings? http://hackage.haskell.org/package/pretty-show Just use ppShow, instead of show. ppShow also has a command line tool called ppsh. I run ppsh in an xterm, paste the Show output into the xterm and then hit Control-d to see the formatted output. 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] Wai and http-enumerator not as lazy as I'd like
Michael Snoyman wrote: On Fri, Apr 29, 2011 at 2:49 AM, Erik de Castro Lopo Has anyone done anything like this and care to shed some light? It's a little bit complicated, but hopefully this should help out: Thats Michael. I've tried it and it works. Now to study it and figure out 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] Wai and http-enumerator not as lazy as I'd like
Antoine Latter wrote: None of the lbs functions in http-enumerator can operate in constant space - they are all built on top of the utility function lbsIter which provides a warning: Convert the HTTP response into a Response value. Even though a Response contains a lazy bytestring, this function does not utilize lazy I/O, and therefore the entire response body will live in memory. If you want constant memory usage, you'll need to write your own iteratee and use http or httpRedirect directly. Thanks Antoine. I know I read the documention a number of times but still managed to fall into that trap. I think it was because I tired using httpDirect, couldn't figure it out and then fell back to using the non-lazy lbs version. Basically I need a serveRequest function with a signature: import qualified Network.HTTP.Enumerator as HE import qualified Network.Wai as Wai serveRequest :: (MonadControlIO m, Failure HE.HttpException m) = HE.Request m - m Wai.Response that calls httpRedirect to do a lazy download of the specified data and returns it as a Wai.Response using the ResponseEnumerator constructor. Unfortunately, I've tried a bunch if stuff and nothing I've come up with even comes close t type checking. Has anyone done anything like this and care to shed some light? 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] How to make ghc 7 with llvm?
Magicloud Magiclouds wrote: As I recalled, ghc started to support llvm from version 7. Yes. But there is a problem: there is no option to make ghc with llvm. Its not an option, its a feature that is compiled in by default and enabled by using -fllvm on the ghc command line. So Library within ghc source will be in gcc's binary format. It is my understanding that libraries compiled via the native code generator (NCG) are fully compatible with libraries compiled with -fllvm. Then when I install other packages, they may complain that the binary format is not llvm, so they install some libraries again. You seem to think there is a problem where this is no problem :-). 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] Wai and http-enumerator not as lazy as I'd like
Hi all, I'm using Wai and http-enumerator to build a http proxy. The core of the code looks like this: import qualified Network.HTTP.Enumerator as HE import qualified Network.Wai as Wai serveRequest :: forall (m :: * - *). (MonadControlIO m, Failure HE.HttpException m) = HE.Request m - m Wai.Response serveRequest request = do HE.Response sc rh bs - HE.withManager $ HE.httpLbsRedirect request return $ Wai.responseLBS (mkStatus sc) rh bs This works but does not run in constant space as I would have hoped. The thing is, HE.httpLbsRedirect returns a lazy ByteString and Wai.responseLBS writes a lazy ByteString, so why isn't the whole thing lazy? I'd appreciate any clues. 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
