I bought myself a new laptop the other day, and while I'm happy with it, it came with Windows 8. This wasn't an issue per se, once I looked up on the internet how to find the "shut down" button... Sure, the gestures are a bit annoying when you don't have a touch screen, but I could live with that.
But then I started running into familiar issues again, as I tried to set all the Haskell libraries I needed for a project: libraries not working on Windows, MinGW/MSYS/Cygwin hell, etc... I just couldn't take it anymore. So I guess this is an admission of defeat that when you need work done quickly using a significant number of Haskell libraries, you need a Unix based OS.
So I decided to dual boot the computer with Ubuntu. I don' really know why I chose Ubuntu, from looking around it looked like it was both stable and developer friendly.
I was first pleased to see that Windows would give me tools to resize my main partition. I remember a time where you had to use third party software to to do that!
I burned a DVD with the 12.10 image (I see 13.04 is out, I'll have to upgrade some day I suppose), and went with the Linux Secure install. It didn't recognize that I had a Windows install, so I configured my partitions and tried to understand what the messages about the boot loader meant. But when I restarted, I went straight to Windows as if Ubuntu didn't exist. So I restarted using the DVD, and launched the Boot Repair utility. At the end it told me that I had to change something in the UEFI options of the computer. I went in there and sure enough there was an entry for Ubuntu. Once I selected that, I could now see the dual boot screen, giving me the choice between Ubuntu and Windows, and both work! Success!
After that, not much sweat to report. I quickly appreciated apt-get, as opposed to the various downloads+install procedures you get for windows software. Sure, at the time I installed it, Eclipse was still 3.8 and not 4.2, but I'm not going to complain.
Ho, and the library I needed that I couldn't get to work on Windows? Installed like a charm.
I'm now a Ubuntu Haskell developer, and I don't regret it.
Thursday, May 09, 2013
Monday, March 11, 2013
EclipseFP 2.5.2 released
I'm happy to announce a new bug-fixing release of EclipseFP. You can see the release notes here.
A few issues around the use of cabal-dev were found, as expected, and fixed, and a couple of little feature requests have been put in.
Hope this helps! As usual, just upgrade Eclipse using the update site http://eclipsefp.sf.net/updates.
Happy Haskell Hacking!
A few issues around the use of cabal-dev were found, as expected, and fixed, and a couple of little feature requests have been put in.
Hope this helps! As usual, just upgrade Eclipse using the update site http://eclipsefp.sf.net/updates.
Happy Haskell Hacking!
Friday, March 01, 2013
EclipseFP 2.5.1 released
Quickly on the heels of 2.5.0 I'm releasing 2.5.1. This is mainly to fix an issue that caused the Editor->Syntax preference page to not open.
This release also add the possibility to change the font and colors of the tooltip in the editor (under Preferences->General->Appearance->Colors and Fonts, Haskell). It also searches for executables under $HOME/Library/Haskell/bin, which seems to be a path for executables on MacOS.
Also, some UI enhancements for Eclipse 4.2. The full release notes are here.
To upgrade just point your Eclipse to http://eclipsefp.sf.net/updates. Report any issue to the SourceForge forum.
Happy Haskell Hacking
This release also add the possibility to change the font and colors of the tooltip in the editor (under Preferences->General->Appearance->Colors and Fonts, Haskell). It also searches for executables under $HOME/Library/Haskell/bin, which seems to be a path for executables on MacOS.
Also, some UI enhancements for Eclipse 4.2. The full release notes are here.
To upgrade just point your Eclipse to http://eclipsefp.sf.net/updates. Report any issue to the SourceForge forum.
Happy Haskell Hacking
Tuesday, February 26, 2013
EclipseFP 2.5.0 released
It's my pleasure to announce another release of EclipseFP, the Eclipse plugins for Haskell development.
In this feature, I've added support for cabal-dev, as demonstrated in this video.
I also have added a "organize imports" function on an opened source file. This cleans the import lists by only importing what's really used and formatting it in a manner similar to what stylish-haskell does.
I have also tried to improve the performance of the editor, and fixed all bugs we were made aware of. Syntax highlighting can now highlight more tokens in different colors (non alphanumeric symbols, different types of comment).
Full release notes can be seen here.
As usual, to upgrade just point your Eclipse to http://eclipsefp.sf.net/updates. Report any issue to the SourceForge forum.
Happy Haskell Hacking!
In this feature, I've added support for cabal-dev, as demonstrated in this video.
I also have added a "organize imports" function on an opened source file. This cleans the import lists by only importing what's really used and formatting it in a manner similar to what stylish-haskell does.
I have also tried to improve the performance of the editor, and fixed all bugs we were made aware of. Syntax highlighting can now highlight more tokens in different colors (non alphanumeric symbols, different types of comment).
Full release notes can be seen here.
As usual, to upgrade just point your Eclipse to http://eclipsefp.sf.net/updates. Report any issue to the SourceForge forum.
Happy Haskell Hacking!
Sunday, February 24, 2013
Porting my typeclass game to reactive-banana-sdl
Some time ago I wrote a tiny game called TypeClass, just to experiment with the SDL bindings for Haskell. I was always curious to learn more about FRP, but never really knew where to start. So I just decided to change TypeClass to use reactive-banana, since it looked like a nice library with a dedicated author. And there are SDL bindings too!
It took a bit efforts since I didn't find any sample in reactive-banana-sdl, but I finally got it working. The game is exactly the same from the outside, so it still not that exciting. But I feel I've made progress in understanding events and behaviors and how it all fits together.
I've put the game on github, so anybody else interested in using reactive-banana with SDL can at least have a sample. It requires my own version of reactive-banana.
Happy Haskell Hacking!
It took a bit efforts since I didn't find any sample in reactive-banana-sdl, but I finally got it working. The game is exactly the same from the outside, so it still not that exciting. But I feel I've made progress in understanding events and behaviors and how it all fits together.
I've put the game on github, so anybody else interested in using reactive-banana with SDL can at least have a sample. It requires my own version of reactive-banana.
Happy Haskell Hacking!
Tuesday, February 19, 2013
EclipseFP + cabal-dev
Some of EclipseFP users had a dream: use cabal-dev sandboxing capabilities to manage their Haskell projects in EclipseFP. Well, we're getting there. I've uploaded a video of the current state of EclipseFP and cabal-dev integration. The workflow is as follows:
- Fill in the cabal-dev location in the preferences page. Once this is filled, all your Haskell packages will be sandboxed
- Create projects as you would normally
- In the Cabal editor, local projects will now be available as dependencies. When you select a project as a dependency, a project reference is created by Eclipse. The dependent project is then installed in the current project sandbox
- Building, autocomplete, GHCi sessions, etc. will use the project sandbox
Under the scenes, we're only using cabal-dev install --sandbox=.... Thanks Rogan for the help!
This will be part of EclipseFP 2.5.0. I urge adventurous hackers to get the current version from github and start testing!
- Fill in the cabal-dev location in the preferences page. Once this is filled, all your Haskell packages will be sandboxed
- Create projects as you would normally
- In the Cabal editor, local projects will now be available as dependencies. When you select a project as a dependency, a project reference is created by Eclipse. The dependent project is then installed in the current project sandbox
- Building, autocomplete, GHCi sessions, etc. will use the project sandbox
Under the scenes, we're only using cabal-dev install --sandbox=.... Thanks Rogan for the help!
This will be part of EclipseFP 2.5.0. I urge adventurous hackers to get the current version from github and start testing!
Friday, February 08, 2013
Discovering the value of QuickCheck
I like tests. I like the confidence that you get when you have an extensive test suite so you know you'll be notified when things break. But so far I've used mainly frameworks like HUnit to explicitly state my assertions. I know what the code should produce given the inputs, and I encode that information in tests. So I didn't really see what QuickCheck brought to that. I'm still not that comfortable with the random aspect of it, but I understand that it can find corner cases for you, whereas with assertions the corner cases you need to think of beforehand, or add them when your users encounter them (ouch). But I'm starting to see the value of QuickCheck.
I was working inside the HTF source code, and the goal was to produce a textual representation of a diff between strings similar to what the diff utility does on Unix. I just wanted to have a fallback for machines that don't have diff installed. And Stefan had written a QuickCheck property to verify that the outputs of the pure Haskell code and the utility matched. I used the property to fall back to my comfortable way of working: fire QuickCheck, let it find a failing case, add it to a HUnit TestCase, and try to understand and fix the issue without breaking the rest. So QuickCheck was just a test case generator.
But then Sterling, the maintainer of Diff, convinced me that 100% matches between the code and the utility was an utopian goal, since diff does some tradeoffs for speed and compactness, and rewriting diff with all its quirks wasn't really worthwhile. And that's when I started to like QuickCheck. I thought: we want exact matches most of the time, but it's fine to have differences as long as what we generate is not too big compared to what the diff utility outputs. This is what QuickCheck classify function can do: I first verify if the size of the output is ok (less than 10% bigger that the utility output), and then I classify the test case as an exact match if the two outputs match. And then I use the cover function (not, ahem, covered in the manual ) to ensure that I get at least 90% exact match:
cover (haskDiff == utilDiff) 90 "exact match" $
classify (haskDiff == utilDiff) "exact match"
(div ((length haskDiff)*100) (length utilDiff) < 110)
So the tests are random, yes, but I've pretty good confidence that the output function does what's it's supposed to do. 90% of the time :-).
I was working inside the HTF source code, and the goal was to produce a textual representation of a diff between strings similar to what the diff utility does on Unix. I just wanted to have a fallback for machines that don't have diff installed. And Stefan had written a QuickCheck property to verify that the outputs of the pure Haskell code and the utility matched. I used the property to fall back to my comfortable way of working: fire QuickCheck, let it find a failing case, add it to a HUnit TestCase, and try to understand and fix the issue without breaking the rest. So QuickCheck was just a test case generator.
But then Sterling, the maintainer of Diff, convinced me that 100% matches between the code and the utility was an utopian goal, since diff does some tradeoffs for speed and compactness, and rewriting diff with all its quirks wasn't really worthwhile. And that's when I started to like QuickCheck. I thought: we want exact matches most of the time, but it's fine to have differences as long as what we generate is not too big compared to what the diff utility outputs. This is what QuickCheck classify function can do: I first verify if the size of the output is ok (less than 10% bigger that the utility output), and then I classify the test case as an exact match if the two outputs match. And then I use the cover function (not, ahem, covered in the manual ) to ensure that I get at least 90% exact match:
cover (haskDiff == utilDiff) 90 "exact match" $
classify (haskDiff == utilDiff) "exact match"
(div ((length haskDiff)*100) (length utilDiff) < 110)
So the tests are random, yes, but I've pretty good confidence that the output function does what's it's supposed to do. 90% of the time :-).
Subscribe to:
Posts (Atom)
