I want to take X inputs from a source, feed each one through a different conduit, then combine the outputs in the same order to a single output conduit. What would be the best (best means most effecient in this case) way to do that? To better explain the question, see this image.submitted by Unknownloner
[link] [2 comments]
Welcome for the latest entry in the GHC Weekly News. It's been a little while, but here we are!
And your author has finally returned from his 8 week sabbatical, too! So without any futher ado, lets get going...8.0.1 release roadmap
So HEAD has been steaming along pretty smoothly for the past few months now. After talking with Simon last week, we decided that the best course of action would be to release 8.0.1 (a super-major release) sometime around late February, which were the plans for 7.10 (modulo a few weeks due to the FTP debates). The current schedule is roughly:
- November: Fork the new ghc-8.0 STABLE branch
- At this point, master development will probably slow as we fix bugs.
- This gives us 2 months or so until branch, from Today.
- This is nice as the branch is close to the first RC.
- December: First release candidate
- Mid/late February: Final release.
"Why call it 8.0.1?", you ask? Because we have a lot of excellent features planned! I'm particularly partial to Richard's work for merging types and kinds (Phab:D808). But there's a lot of other stuff.
For all the nitty gritty details, be sure to check 8.0.1 status page to keep track of everything - it will be our prime source of information and coordination. And be sure to read my email to `ghc-devs` for more info.... and a 7.10.3 release perhaps?
On top of this, we've been wondering if another release in the 7.10 branch should be done. Ben did the release shortly after I left, and for the most part looked pretty great. But there have been some snags, as usual.
So we're asking: who needs GHC 7.10.3? We'd really like to know of any major showstoppers you've found with 7.10 that are preventing you from using it. Especially if you're stuck or there's no clear workaround.
Currently, we're still not 100% committed to this course of action (since the release will take time away from other things). However, we'll keep the polls open for a while - so please get in touch with us if you need it! (Be sure to read my email for specific information.)List chatter
(Over the past two weeks)
- Bartosz Nitka writes to ghc-devs about the ongoing work to try and fix deterministic compilation in GHC (the dreaded ticket #4012). There's a very detailed breakdown of the current problems and issues in play, with responses from others - https://mail.haskell.org/pipermail/ghc-devs/2015-September/009964.html
- Richard Eisenberg wants to know - how can I download all of Hackage to play with it? GHC developers are surely interested in this, so they can find regressions quickly - https://mail.haskell.org/pipermail/ghc-devs/2015-September/009956.html
- I wrote to the list about the upcoming tentative 7.10.3 plans, as I mentioned above. https://mail.haskell.org/pipermail/ghc-devs/2015-September/009953.html
- I also wrote to the list about the tentative 8.0.1 plans, too. https://mail.haskell.org/pipermail/ghc-devs/2015-September/009952.html
- Johan Tibell asks about his ongoing work for implementing unboxed sum types - in particular, converting unboxed sum types in StgCmm. https://mail.haskell.org/pipermail/ghc-devs/2015-September/009926.html
- Ryan Scott wrote a proposal for the automatic derivation of Lift through GHC's deriving mechanism, specifically for template-hasekll users. The response was positive and the code is going through review now (Phab:D1168). https://mail.haskell.org/pipermail/ghc-devs/2015-September/009838.html
- Andrew Gibiansky writes in with his own proposal for a new "Argument Do" syntax - a change which would allow do to appear in positions without ($) or parenthesis, essentially changing the parser to insert parens as needed. The code is up at Phabricator for brave souls (Phab:D1219). https://mail.haskell.org/pipermail/ghc-devs/2015-September/009821.html
- Edward Yang started a monstrous thread after some discussions at ICFP about a future for unlifted data types in GHC. These currently exist as special magic, but the proposals included would allow users to declare their own types as unlifted, and make unlifted values more flexible (allowing newtype for example). See wiki:UnliftedDataTypes and Edward's thread for more. https://mail.haskell.org/pipermail/ghc-devs/2015-September/009799.html
(Over the past several weeks)
- Commit 374457809de343f409fbeea0a885877947a133a2 - Injective Type Families
- Commit 8ecf6d8f7dfee9e5b1844cd196f83f00f3b6b879 - Applicative Do notation
- Commit 6740d70d95cb81cea3859ff847afc61ec439db4f - Use IP-based CallStack in error and undefined
- Commit 43eb1dc52a4d3cbba9617f5a26177b8251d84b6a - Show MINIMAL complete definition in GHCi's :info
- Commit 296bc70b5ff6c853f2782e9ec5aa47a52110345e - Use a response file for linker command line arguments
- Commit 4356dacb4a2ae29dfbd7126b25b72d89bb9db1b0 - Forbid annotations when Safe Haskell is enabled
- Commit 7b211b4e5a38efca437d76ea442495370da7cc9a - Upgrade GCC/binutils to 5.2.0 release for Windows (i386/amd64)
(Over the past two weeks)
#10834, #10830, #10047, #9943, #1851, #1477, #8229, #8926, #8614, #10777, #8596, #10788, #9500, #9087, #10157, #10866, #10806, #10836, #10849, #10869, #10682, #10863, #10880, #10883, #10787, #8552, #10884, #7305, #5757, #9389, #8689, #10105, #8168, #9925, #10305, #4438, #9710, #10889, #10885, #10825, #10821, #10790, #10781, #9855, #9912, #10033, #9782, #10035, #9976, #10847, and #10865.
Dear someone, I am trying to use the Graphics.Gnuplot.Simple-package for Haskell (I could gladly use the advanced too), but I only find some using plotList (on Hackage), and some comments on forums. Now I for instance dont know how to save the plot to file. Can someone recommend some good tutorials (either on youtube or as pdf)? that would be very appreciated.submitted by stianhotboi
[link] [1 comment]
I think Haskell has spoiled me. Now whenever I'm writing code in other languages, I'm constantly thinking how much shorter and more elegant it would be in Haskell. Anyone else feel an intense loathing for other programming languages after learning Haskell?submitted by elliottneversleeps
[link] [41 comments]
With Python 3.5 released, the thing that drew my attention is the support for asynchronous programming through PEP 0492 -- Coroutines with async and await syntax, which added awaitable objects, coroutine functions, asynchronous iteration, and asynchronous context managers. I found the mailing list discussions (look both above and below) particularly helpful in understanding what exactly is going on.
In writing library functions, what is the best way these days to let users handle errors how they want to? In times past you could simply use the much hated (for good reason) fail function and then the user could simply instantiate with the monad they wanted for the kind of error handling they required (e.g. if they didn't need to know why something failed they could use Maybe, they could use Either if they wanted the message or even IO if they wanted a crash).
But since the fail definition has been removed from the Either monad definition, this strategy doesn't work anymore. What is the correct way to do this now? Everything I've read seems to explain how to explicitly use different kinds of errors (e.g. EitherT, MaybeT and so on) but that's exactly what I don't want to do.submitted by haskellUser
[link] [20 comments]
I'm sure I'm not the only person who's noticed that discussions about the stack build tool seem to have permeated just about any discussion on this subreddit with even a tangential relation to package management or tooling. Personally, I love stack, and am happy to discuss it with others quite a bit.
That said, I think it's quite unhealthy for our community for many important topics to end up getting dwarfed in rehash of the same stack discussion/debate/flame war that we've seen so many times. The most recent example was stealing the focus from Duncan's important cabal talk, for a discussion that really is completely unrelated to what he was saying.
Here's my proposal: let's get it all out in this thread. If people bring up the stack topic in an unrelated context elsewhere, let's point them back to this thread. If we need to start a new thread in a few months (or even a few weeks) to "restart" the discussion, so be it.
And if we can try to avoid ad hominems and sensationalism in this thread, all the better.
Finally, just to clarify my point here: I'm not trying to stop new threads from appearing that mention stack directly (e.g., ghc-mod adding stack support). What I'm asking is that:
- Threads that really aren't about stack don't bring up "the stack debate"
- Threads that are about stack try to discuss new things, not discuss the exact same thing all over again (no point polluting that ghc-mod thread with a stack vs cabal debate, it's been done already)
[link] [281 comments]
There was recently a post, [Haskell-cafe] GSoC Retrospective; so I ask, "GSoC participants, how was your experience and what would you like to tell us about your results?"submitted by rpglover64
[link] [6 comments]
Because of the reccomendations of bitemyapp github page I tried to learn haskell by the Craft book.
The explanation was fine the only thing that makes my grazy was that a lot of exercises were written on a way that was not clear what was the meaning of the exercise.
Now I wonder.
Is there a book with a lot of exercises where I can learn Haskell.
I have looked at LYAH but there no exercises.
Roelofsubmitted by roelofwobben
[link] [18 comments]
Guido van Rossum reminisces a bit about early discussions of generators in the Python community (read the other messages in the thread as well). I think we talked about the articles he mentions way back when. Earlier still, and beyond the discussion by Guido here, was Icon, a clever little language that I have a soft spot for. i don't think we ever fully assessed its influence on Python and other languages.
PeachPy is a Python framework for writing high-performance assembly kernels.
PeachPy aims to simplify writing optimized assembly kernels while preserving all optimization opportunities of traditional assembly.
You can use the same code to generate assembly for Windows, Unix, and Golang assembly. The library handles the various ABIs automatically. I haven't seen this cool project before.
Among the cool features is the ability to invoke the generated assembly as regular Python functions. Nice.
I am imagining that the change happened in Windows 8.1 and a solved problem became unsolved, so how do I do this today? It seems like a relatively fundamental thing, so maybe it would make sense to have this kind of thing in the already portable System.Directory library which currently has things like getModificationTime anyway?
edit: looks like System.IO.hFileSize is what I was looking for. Seems obvious now :P And it appears to be O(1) and all, so hopefully next time I know where to look now :)submitted by wheatBread
[link] [10 comments]