- Haskell-Cafe - Haskell.org

Hackage checking maintainership of packages
by Petr Pudlák 07 May '13

07 May '13

Hi, on another thread there was a suggestion which perhaps went unnoticed by most: ---------- Forwarded message ---------- > From: Niklas Hambüchen <mail(a)nh2.me> > Date: 2013/5/4 > ... > I would even be happy with newhackage sending every package maintainer a > quarterly question "Would you still call your project X 'maintained'?" > for each package they maintain; Hackage could really give us better > indications concerning this. This sounds to me like a very good idea. It could be as simple as "If you consider yourself to be the maintainer of package X please just hit reply and send." If Hackage doesn't get an answer, it'd just would display some red text like "This package seems to be unmaintained since D.M.Y." Best regards, Petr

14 20

Fwd: Backward compatibility
by Adrian May 06 May '13

06 May '13

Oops, forgot hit hit reply-all the first time, well spotted by Niklas... ---------- Forwarded message ---------- From: Adrian May <adrian.alexander.may(a)gmail.com> Date: 5 May 2013 14:22 Subject: Re: [Haskell-cafe] Backward compatibility To: Niklas Hambüchen <mail(a)nh2.me> > The fact that it doesn't build and that the last change is from 2007 the > *is* the warning that it is completely unmaintained and not the way to > do things today. > > (One could even say that by making it build on 7.6, I have removed this > warning and given the illusion that everything is fine.) > That only makes sense if you assume everybody is familiar with Haskell and its culture. But that neglects trying to make it attractive to people who aren't. Of course I agree that it would be better if there were warnings on > their web sites that said "sorry guys, this project is dead now". > > I would even be happy with newhackage sending every package maintainer a > quarterly question "Would you still call your project X 'maintained'?" > for each package they maintain; Hackage could really give us better > indications concerning this. > > Something like that would make a lot of sense to me. > Still I'd say that in this case, the fact that it did not build, hasn't > had a single change in the last half decade, and that you cannot find > any recent discussion about it anywhere on the Internet, make it pretty > clear what is going on here, even for non-technical people. Half a decade is nothing to most programming cultures. A newbie looks for sample code and blames himself if he can't get it working. > > Please don't say that it's my culture's fault. > > From your story it sounds like you have a problem with developer > simplemindedness and management wars idiocy. Nobody is forcing you to be part of that. There are a lot of places ... Perhaps I'd rather help those who need it than preach to the converted. You summed it up nicely as two problems: (1) bitchy managers and (2) untrained programmers. I'd like to use Haskell to help with (2) but I still have to work around (1). My plan is to start by winning the hearts and minds of the developers before sticking my neck out far enough to get it severed. There's another plan where I'm pitching VCs about a start up, in which case I'd have a lot more control, but I'd still have to prove that my elite imperative squad were willing and able to learn a new trick before committing myself. I've actually learned quite a lot from this discussion and that largely enables me to preempt any Rails-day problems. But that's only me. Lots of people might be flirting with Haskell just out of curiosity and bouncing off it for these reasons. There have been a lot of good ideas suggested about how to minimise that, and I'd also throw in that it would be cool if people could tell the compiler to behave as it did half a decade ago when the code was written so people could prove to themselves that the code works in principle, then they could clock the compiler forward little by little, reading its release notes along the way. That's a lot friendlier than being confronted with an apparently endless series of error messages when you've barely learned to read them, and not even knowing if you're making things better or worse. If the desired compiler/modules version was in the makefile, that, I think, would be a general solution. The FPComplete thing also looks helpful. I could use that to sell the language to newbies. The mercenaries would come later though. Thanks to everybody for helping out with this. Adrian.

8 8

help understanding zlib space leak
by diego souza 06 May '13

06 May '13

Dear haskellers, I'd like assistance figuring out a strange space leak using zlib package. To make it easier to reproduce I've come up with the following snippet that pretty much resumes up the problem I'm trying to solve: > -- omitting imports and function signatures > encode = compress . L.fromChunks > > main = do { hSetBinaryMode stdout True > ; hSetBinaryMode stdin True > ; hSetBuffering stdin NoBuffering > ; hSetBuffering stdout NoBuffering > ; loop [] > } > where loop buff > | length buff == 64 = L.hPut stdout (encode buff) >> loop [] > | otherwise = do { eof <- hIsEOF stdin > ; when (not eof) (fmap (: buff) (B.hGetSome stdin 512) >>= loop) > } N.B.: Removing the `compress' function from the above code also removes the space leak. Now, feeding the above program with ~8GB worth of binary data: > $ uname -a Linux mephisto.localhost.localdomain 3.8.7-1-ARCH #1 SMP PREEMPT Sat Apr 13 09:01:47 CEST 2013 x86_64 GNU/Linux > $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 > $ ghc -W -Wall -rtsopts --make -O2 test.hs > $ sudo dd if=/dev/sda bs=4K count=2048K | ./test +RTS -M1M -s >/dev/null ... 8589934592 bytes (8.6 GB) copied, 277.263 s, 31.0 MB/s ... 2 MB total memory in use (0 MB lost due to fragmentation) ... Which is fine. However, monitoring the RSS size is a different story: > $ while pidof test; do ps -o rss= -p $(pidof test); done | tail 16967 25620 16967 25628 16967 25628 16967 25628 16967 # ~16M 0 I know the RSS usually overestimates the memory consumption but the problem is that it is forever growing. The following I found very intriguing: * `+RTS -hc` gives me no hint about whats wrong [at least I couldn't see one]; * `+RTS -M1M` doesn't produce an error; * removing the `compress' functions makes the problem disappear; I couldn't figure these out and I don't think this is matter of strictness, though. Has anyone seen this before? Thanks in advance, ~dsouza

1 1

Follow up on type error diagnosis for DSLs in Haskell
by Jurriaan Hage 06 May '13

06 May '13

Dear all (and in particular Alberto G. Corona and Stephen Tetley), First of all, thanks Stephen for pointing out our work to Alberto. Second, you may be interested to know that I just (as in two weeks ago) obtained a grant to hire a PhD student to scale the work of the ICFP '03 paper (as mentioned by Stephen) up to Haskell 2011 (or whatever variant will be appropriate). The plan is to first prototype this work in the UHC compiler, and, if succesful, build it into the GHC. I shall surely send out a job vancancy on some of the Haskell mailing lists. best, Jurriaan Hage

2 1

[ANN] xmobar 0.17 released
by Jose A. Ortega Ruiz 05 May '13

05 May '13

I've just released version 0.17 of xmobar, a lightweight system monitor written in Haskell. Homepage: http://xmobar.org Release notes: http://xmobar.org/releases.html _New features_ - Icons support: it's now possible to insert bitmaps in the template (Edward O'Callaghan, Alexander Polakov and Tomáš Janoušek). - Initial support for reacting to mouse clicks (Alexander Polakov). - New `TopP` and `BottomP` alignments, taking left and right paddings (thanks to Dmitry Malikov). - New `<freeratio>` field for memory monitor (Peter Simons). - New `allDesktops` and `overrideRedirect` configuration options, providing dock behaviour in tiling WMs (when set to True and False respectively). Cf. discussion at [github #105]. - Experimental `-d` (start as a dock) option, may address [github #67] in some window managers. _Bug fixes_ - Partial (as reports go) fix for [github #77]. - Safer volume plugin (Dmitry Malikov). - Battery percentage capped at 100% (RJ Regenold). Enjoy! -- I always pass on good advice. It's the only thing to do with it. It is never any use to oneself. -Oscar Wilde

1 0

runhaskell flags: What is going on?
by Niklas Hambüchen 04 May '13

04 May '13

> runhaskell -fno-warn-unused-matches Myfile.hs [some compile error] > runhaskell -fno-warn-unused-matches Myfile.hs [no output whatsoever but exit code 127] > runhaskell -asdf Myfile.hs ghc: unrecognised flags: -asdf > runhaskell -fasdf Myfile.hs [no output whatsoever but exit code 127] Not sure if that's how it should work or missing error reporting? Thanks Niklas

3 4

ANNOUNCE: grid 5.0
by Amy de Buitléir 04 May '13

04 May '13

I'm happy to announce a new major release of the grid package: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) WHAT'S NEW: * Octagonal grids (just the thing for tiling that hyperbolic bathroom floor!) * Want to use the square grid, but need diagonal movement too? Try the octagonal grid. See the userguide for more information. * Updated the userguide to reflect the changes. ABOUT GRID: Grid provides tools for working with regular arrangements of tiles, such as might be used in a board game or self-organising map (SOM). Grid currently supports triangular, square, hexagonal, and octagonal tiles, with various 2D and toroidal layouts. If you need a tile shape or layout that isn't currently provided, please let me know. See Math.Geometry.Grid for an example of how to use the package. Suggestions for improvement are welcome.

1 0

Backward compatibility
by Adrian May 04 May '13

04 May '13

Hi All, Please don't interpret this as a rant: I'm just feeling a bit disappointed about probably having to give up on Haskell. Let's face it: this decision to change the default syntax in GHC7 means that right now Haskell looks about as stable as Ruby on Rails. I just tried to use Flippi. It broke because of the syntax change so I tried WASH. I couldn't even install it because of the syntax change. I persisted for a while but gave up because getPackageId doesn't exist in any form at all anymore. This was only the install script: what would WASH itself have in store for me to get my brain around? What are my choices here: 1) Revert to GHC6 or put pragmas and compiler switches everywhere, switch 2010 off globally with cabal or even make an alias of ghc: That means I'll gradually clash with people who decide ... 2) Convert all my code and a lot of other peoples' to the new syntax, thereby exacerbating the problem that ruled out 1. Either way, we're looking at a long period during which a large portion of the libraries will be incompatible with the other portion, and nobody will know which style to write. I don't know if or when WASH or any other library will convert, or even if I'd prefer that to happen sooner or later, because that would depend on when other libraries do and how I'd worked around it in the meantime. Altogether that means I can't sensibly decide to rely on any library, so I can't use Haskell. I'll just have to go back to fumbling around in XSL, PHP and the like. Is Haskell 2010 really so much better that it justifies this? I just saw that movie "The Words": the moral of the story is that you shouldn't try to change your mistakes. ... Apparently it's not only 2010. I now find that buildng the Haskell Platform wants GHC 7.4.2, not 7.4.1 because of the line "import Prelude" (if I remember rightly,) and even when I follow the rules precisely I still get several different deprecation warnings. The prelude is not exactly obscure. If you deprecate that you've broken everything. Is it really impossible to keep such a basic mantra meaningful from one minor version to the next? Java was fond of deprecating things in the early days, but when they said "deprecated" they didn't mean "switched off", let alone that it would lead to a syntax error. They just meant "not trendy anymore." It's a very common illusion to believe that the central thing in your life is also the central thing in everybody else's. That's why things like Norton take over your whole machine: those guys believe that the only reason you bought the computer was to fight viruses, because that's what most of the machines in their office were bought for. There seems to be something similar going on in the way Haskellers are expected to update all their code whenever GHC decide to issue an update. But in reality we have jobs of our own. I'd like to choose Haskell over XSL because I think it'll enable me to write web sites more efficiently, not because I want to forget all about my job and savour the brilliance of the latest Haskell version. But in reality I'm just sitting here waiting for the Platform to compile just in case it's the Ubuntu package's fault, but I know it won't help. I'll just get other problems instead. Reality is that the whole ecosytem is in disarray because of this lack of respect for backward compatibility. At least Rails can plead that it's relatively new, but Haskell has been around for over 20 years. I understand that progress has to be made, and it would be nice if people did just update all their code quickly so you could switch off old stuff and move on. But it's not hard to survey the code that's out there and see how much stuff you'd be breaking if you did. If it's not a lot, then switching it off to wake them up would be an acceptable compromise. But it looks to me as if a lot of very important stuff is still failing on the GHC from November 2010, so clearly things are going too fast. Adding new stuff is great, and sometimes the new stuff clashes with the old stuff. But how much of that deprecated stuff really *needed* to be switched off, and couldn't the new stuff have been designed so as not to force that? In principle this is the best language on the planet, but with all these version gotchas I don't know that I can use it anymore. What a tragedy. I can't even think of a suggestion as to how Haskell should try to get out of this mess now. Adrian.

30 80

BayHac '13
by Mark Lentczner 04 May '13

04 May '13

Please join us for a weekend of Haskell hacking: *BayHac '13* *May 17th ~ 19th, 2013* *Hacker Dojo* *Mountain View, CA* Full details on the Haskell Wiki: BayHac '13<http://www.haskell.org/haskellwiki/BayHac2013> - Mark

2 2

Lambda Calculus question on equivalence
by Ian Price 04 May '13

04 May '13

Hi, I know this isn't perhaps the best forum for this, but maybe you can give me some pointers. Earlier today I was thinking about De Bruijn Indices, and they have the property that two lambda terms that are alpha-equivalent, are expressed in the same way, and I got to wondering if it was possible to find a useful notion of function equality, such that it would be equivalent to structural equality (aside from just defining it this way), though obviously we cannot do this in general. So the question I came up with was: Can two normalised (i.e. no subterm can be beta or eta reduced) lambda terms be "observationally equivalent", but not alpha equivalent? By observationally equivalent, I mean A and B are observationally equivalent if for all lambda terms L: (L A) is equivalent to (L B) and (A L) is equivalent to (B L). The definition is admittedly circular, but I hope it conveys enough to understand what I'm after. My intuition is no, but I am not sure how to prove it, and it seems to me this sort of question has likely been answered before. Cheers -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"

7 13