- We have a few updates from the Google Summer of Code projects. Alejandro Gadea about history reordering:
- Marcio Diaz about the cache system:
- Incremental fast-export is now provided to ease maintenance of git mirrors:
- issue2244 Ale Gadea
- darcs tag should warn about duplicate tags
- issue2314 Benjamin Franksen
- output-auto-name in defaults file
- issue2361 Ale Gadea
- optimize --reorder runs forever with one repository
- issue2364 Sergei Trofimovich
- fix file corruption on double fetch
- issue2364 Sergei Trofimovich
- don't break list of 'bad sources'
- issue2388 Owen Stephens
- check if inventories dir has been created
- issue2394 Guillaume Hoffmann
- make optimize a supercommand
- issue2396 Guillaume Hoffmann
- make convert a supercommand and enhance help strings
Most everyone I talk to about haskell is already a programmer with their own favorite languages. What are some small, interesting/amazing things I can show people on a whiteboard to explain the power of haskell?
I'm looking (vaguely) for examples somewhat like 2.3 and 3.3 from here, or maybe like these examples I found. But, I'm hoping to find examples that can be given more on the fly, and at a somewhat high-language level to "evangelize" with, for lack of a better term.
Ideally the examples would be plain word examples that could be scratched out on a whiteboard impromptu. So for the above I might describe it something along the lines of "you could write out the sheep linage as "sheep, dad, dad's mom" ... etc. But if one of the sheep didn't have a parent, the entire chain would return "nothing". However in haskell you can write out monads to simplify the entire thing down to "grandma = sheep's mom's mom" and it takes care of all the possible lack of parents because of the monad class ... etc."
I realize haskell's true power comes from the paradigm shift you experience when programming, and from other things that are not as easy to explain, especially briefly or high-level, but rather have to be somewhat experienced on your own. That being said, can you guys think of any examples, even so?submitted by thang1thang2
[link] [69 comments]
Decided to play with TChan last night, made a little worker pool + queue example. How would you improve it?
Primary concerns are on practicality, production readiness, etc. without making example too verbose.
Things I already know could be done:
- Use TQueue (more efficient)
- Use TBQueue (bounded and more efficient - back-pressure is difficult to do right)
- Instead of sinking into side effects, send results as Async promises downstream or back to worker supervisor
- Rate limiting (I mean above and beyond limiting worker pool size)
- Dynamic adjustment of worker pool size in response to workload
- Worker status updates, monitoring - I was thinking of maybe checking queue/chan size and submission of "time to complete last task" rolling metrics to get an idea of "how backed up are we?"
- Use Pipes, pipes-concurrency, MVC, Conduit, Iteratees, io-streams, or simple-conduit - using any of these wouldn't change my operational/visibility concerns.
It's fine if you want to elaborate on any of the above, but they don't need mentioned now that I have.
Any ideas? This was inspired by a friend diving into Pipes recently to see if he could be happier with some Haskell code he was using at work. I was partly trying to see if the CSP'ish patterns I'm accustomed to "translate" to Haskell nicely.
I'm quite satisfied so far, but I know it's very naïve still.submitted by Mob_Of_One
[link] [8 comments]
Rust introduced it's package manager Cargo , and has the following feature:If I have three packages: - uno depends on json 1.3.6 - dos depends on json 1.4.12 - tres depends on json 2.1.0 Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres.
I don't believe Cabal works like this (encouraging the use of SemVer  to version and aid dependency resolution of packages)
I know the way Cabal works is well-thought out. Would we want to do the same for Cabal, or is it trying to solve a harder problem (and what do we gain)?
(I looked at http://www.haskell.org/cabal/FAQ.html#dependencies-conflict briefly)Platz
[link] [13 comments]
Chapters 4 and 5 capture much of the experience of transitioning and of being trans, respectively. These are the chapters which so many trans memoirs convey in their narration, though often they avoid stating it quite so directly. Both chapters do a good job of conveying the lived experience of trans women, and are well worth reading by cis audiences for that reason.
( Read more... )
Chapter 5 especially was nice to read as it cuts to the core of the fact that there are both conscious and subconscious components to our experiences of (our own) gender. ( Read more... )