My significant other is running Debian stable on her laptop, and it has worked fine for quite a while. But since a week or two, she could not access her University IMAP account via Evolution. Obviously quite a showstopper!
Today I had a closer look, and my suspicion was that the University changed their SSL configuration due to the recent POODLE attack and that Evolution was incompatible with that. After some more searching, I found that Ubuntu had applied a patch, originally from Fedora, two weeks ago. For Debian, there is a bug report but no sign of action.
So I fetched the sources, applied the patch, built the package, installed it and things were working again. Yay for that! But this is obviously not the best way to handle such issues.
I know that Debian is volunteer driven and we often lack the manpower for certain things, so I don’t want to rant about this particular issue. I also continue to be a happy user of Debian unstable on my laptop, and Debian stable on my servers. But I seriously wonder: Can I really recommend Debian stable to users, for their laptops and desktops? If not, what are the alternatives? Ubuntu obviously comes to mind, having some full-time staff for such issues... But that would be giving up on promoting Debian as the universal operating system.
Update (2010-11-3): Laney just uploaded a fixed package. Thanks!
Coming to learn a functional programming which has much attention nowadays and also being mostly a GUI programmer I found a lot of libraries in Haskell (and other FP languages) which decorate an existing and popular choices for writing a cross-platform UI (Qt, Gtk, wx etc). Decoration happens in many possible styles be it FRP, FFI, whatever else I missed.
But I never found a more or less modern library which was built from ground up using an FP idioms and best practices.
I wonder why is it so? Is it because FRP is good for this but kinda not yet figured out exactly? Or is it because FP was used mainly in data manipulation or algorithmic tasks so far, but less in UI? Or some other reason?
Is it even possible to build such a library which would be modern, functional and provide a comprehensive set of widgets to work with? Is it just a question of manpower?
Or did I miss any existing effort to build such a library?submitted by dimsuz
[link] [19 comments]
henn v.t. to write or rewrite (Haskell code) naming types 'T' and classes 'C': to write or rewrite (code, etc.) in any annoying personal idiom
- "It's henned -- those are different 'C's and 'T's."
- "numeric-prelude could be a viable alternative if someone were to dehenn it."
- "It's OK to henn if you're never going to publish it."
- "I do wish he'd stop henning all his packages."
[link] [10 comments]
Yes, all of your Halloween fears are coming true. But this time it's "Migration downtime, not "omg-phone-ringing-things-are-busted downtime" like it was earlier today.
But didn't we do this before?
So, we talked about this a few weeks ago, and Duncan and I attempted it. But didn't quite complete it due to some performance snags. But we're going to do the move in the mean time anyway - it's mostly just a switch being flipped at this point. Performance snags are preferable to "not working"-snags. Duncan has also helpfully identified some server issues in the past two weeks that should help us too in the long run.
Davean and I will do the migration tomorrow - but we will be available in case something catastrophic goes wrong (fingers crossed). Ping #haskell-infrastructure on freenode if you want to complain to us or give moral support or whatnot.
The status site will be kept fairly up to date, and it has the current expected migration timelines already listed in the top (see UTC timeframe): https://status.haskell.org/aseipp
[link] [1 comment]
I've grown quite attached to using vi keybindings in bash, and I have custom vi keybinds in my ~/.inputrc, most notably rebinding "jk" to escape.
I want this functionality in ghci. So far, I've seen a few options to achieve this:
This seems like exactly what I want; wrapping ghci in readline against its wishes. Problems: * rlwrap ghci has no effect. Of course. * rlwrap -a ghci gives me all of my keybindings, but if I ever accidentally wrap a line, say goodbye to that tmux pane. I usually end up having to hit Ctrl-C 5 times and the giving up with Ctrl-D.
I have "editMode: Vi" in my ~/.haskeline file. This sort of has the desired effect, but is unusable for two reasons. * I haven't figured out how to remap "jk" to get to normal mode. * Even when I hit ESC or Ctrl-[ manually, pressing "k" twice in a row quickly will go up one line, then insert the letter "k". This is wrong. I can sometimes get history to work if I wait long enough before pressing "k" the second time, but it's finicky.
Have any other Vi-mode addicts successfully tamed ghci? I thought of asking /r/vim or /r/commandline, but really it's the haskeline library that's causing all of this trouble, and only people with haskell experience would know how to fix it.submitted by the_noodle
[link] [12 comments]
Welcome to the GHC Weekly news. And it's just in time before you go out and eat lots of candy and food.
- David Feuer and Joachim Brietner spent some time this past week talking about more optimizations for Haskell code for fusing code, and creating better consumers and producers. This work includes optimizations of "One shot lambdas" (lambdas used at most once) and Call Arity, which was implemented by Joachim at Microsoft Research. The thread is here - https://www.haskell.org/pipermail/ghc-devs/2014-October/006901.html
The current situation is that Call Arity and One shot analysis tends to have good combined results for exploiting more fusion opportunities, but sometimes these backfire. As a result, Joachim and David have worked on improving the situation - particularly by letting programmers help with a new oneShot primitive (in Phab:D392 & Phab:D393).
- Herbert Valerio Riedel opened up a discussion about the origins of code contributions. In short, we'd like to have some stronger ground to stand on in the face of contributions from contributors - the origin of a change and its legal status is a bit nebulous. The thread is here: https://www.haskell.org/pipermail/ghc-devs/2014-October/006959.html
Overall, there's been a lot of separate points made, including CLAs (unlikely), "Developer Certificates of Origin" a la the Linux Kernel, and reworking how we mark up header files, and keep track of GHC's long history of authors. If you work on a big project where some of these concerns are real, we'd like to hear what you have to say!
- Gintautas Milauskas has done some fantastic work for GHC on Windows lately, including fixing tests, improving the build, and making things a lot more reasonable to use. With his work, we hope GHC 7.10 will finally ship an updated MinGW compiler (a long requested feature), and have a lot of good fixes for windows. Thank you, Gintautas!
- And on that note, the call for Windows developers rages on - it looks like Gintautaus, Austin, Simon, and others will be meeting to discuss the best way to tackle our current woes. Are you a Windows user? Please give us input - having input is a crucial part of the decision making process, so let us know.
- Jan Stolarek had a question about core2core - a lot of questions, in fact. What's the difference between demand, strictness, and cardinality analylsis? Does the demand analyzer change things? And what's going on in some of the implementation? A good read if you're interested in deep GHC optimization magic: https://www.haskell.org/pipermail/ghc-devs/2014-October/006968.html
- Peter Wortmann has put up the new DWARF generation patches for review, in Phab:D396. This is one of the major components we still plan on landing in 7.10, and with a few weeks to spare, it looks like we can make sure it's merged for the STABLE freeze!
- There have been a lot of good changes in the tree this past week:
Thanks to Michael Orlitzky, we plan on adding doctest examples to more modules in 7.10, and increase that coverage further. This is *really* important work, but very low fruit - thanks a ton Michael!
Data.Bifunctor is now inside base! (Phab:D336)
atomicModifyIORef' has been optimized with excellent speedups (as much as 1.7x to 1.4x, depending on the RTS used), thanks to some older work by Patrick Palka (Phab:D315). GHC's internals have been reworked to unwire Integer from GHC, leading not only to a code cleanup, but laying the foundation for further GMP (and non-GMP!) related Integer improvements (Phab:D351).
David Feuer and Joachim have been relentless in improving fusion opportunities, including the performance of take, isSuffixOf, and more prelude improvements, spread over nearly half a dozen patches. And this doesn't even include the work on improving oneShot or Call Arity!
In a slight change to base semantics, David Feuer also finally fixed #9236. This is a change that can expose latent bugs in your program (as it did for Haddock), so be sure to test thoroughly with 7.10 (Phab:D327).
GHC now has support for a new __GLASGOW_HASKELL_TH__ macro, primarily useful for testing bootstrap compilers, or compilers which don't support GHCi.
And there have been many closed tickets: #9549, #9593, #9720, #9031, #8345, #9439, #9435, #8825, #9006, #9417, #9727, #2104, #9676, #2628, #9510, #9740, #9734, #9367, #9726, #7984, #9230, #9681, #9747, and #9236.
Being an open source developer means being an investor. I invest my time in creating, contributing to, and maintaining projects. As an investor, I occasionally need to re-evaluate my portfolio and decide whether it is optimal.
The result of a recent such re-evaluation is that I’ve decided to stop my active involvement in the haskell-suite family of projects.
This decision wasn’t easy. Being a maintainer of haskell-src-exts was a unique experience. During the last two years, 24 people have contributed to the project, which is amazing, given its complexity. During ICFP’14, I met with 4 or 5 contributors and many users of haskell-src-exts. People would approach me in the hallway and ask when the new version would be released or a certain feature added.
Leaving haskell-names behind is also sad. It hasn’t seen as many uses as haskell-src-exts (which has always been puzzling — you can’t do much with a bare parser. But apparently folks prefer to roll their own, incomplete and buggy, name resolution.) Still, it’s used by fay, and I feel bad about letting the fay devs down.
So, why did I choose to stop investing in the haskell suite?
- I have much less spare time these days, so I have to drop something.
- I became involved with the haskell suite because of my interest in developer tools for Haskell (hasfix, ariadne). I am no longer working on those, and I’m not using any haskell-src-exts-powered tools (hlint, stylish-haskell) myself, which means I don’t get big personal returns on my investment.
- The main competitor for the haskell suite is the GHC API. It is now clear to me that we are losing to them in most areas. There is very little hope for the type checker, let alone other parts of the compilation pipeline. The community did a great job in catching up with GHC on the parser side, but we still have less resources than GHC and are bound to lag behind, it seems. On the other side, there has been some work recently (by Alan Zimmerman, in particular) to improve GHC’s AST and catch up with HSE on that front. So, even if I decide to invest in compilers or dev tools in the future, I’m probably going to team up with GHC instead.
What’s going to happen to these projects I’m leaving behind? I’m less worried about haskell-src-exts. Peter Jonsson has been doing some great work on it, and I hope he’ll step in. There’s also Niklas Broberg and all the wonderful contributors.
I’m more worried about haskell-names, haskell-packages, ariadne. If you are willing to take over any of them, let me know (and you can count on my help). Otherwise, I’m going to provide very basic support for them, but nothing more.
Oh, and in case you missed the announcement, I’m dropping support for my test-framework packages, too.
On the other hand (and to end with something positive), I have no intention to stop maintaining tasty in the foreseeable future. Haskell needs at least one decent testing framework, after all! :-) By the way, here’s a cool use case for tasty that Lars Hupel shared for the upcoming edition of HCAR:
Technische Universität München uses Tasty to assess homework submitted for the introductory functional programming course, which is compulsory for second-year Bachelor’s students in computer science. Students can upload their source code to a web application, which compiles them and executes tests (mostly QuickCheck). Graphical reports are generated with ‘tasty-html’ and presented to the students. Grading happens automatically with a custom test reporter, which – roughly speaking – checks that a minimum number of significant tests have passed. This is a huge improvement over the past years, where tests were run by a homegrown framework which offered only textual output. Tasty however is nicely extensible and allows for easy customization to the instructors’ and students’ needs.
... and the code is at lpaste.net/113540
One of the nice things of S-expression syntax is its simplicity. Why isn't it popular with Haskellers?submitted by dmz
[link] [14 comments]