2-3 positions (Associate Professor / Lecturer) in Software Technology at Chalmers University of Technology in Sweden
Chalmers University is advertising 2-3 positions in their division of Software Technology:
Associate Professor in Software Technology http://www.chalmers.se/en/about-chalmers/vacancies/Pages/default.aspx?rmpage=job&rmjob=p2896
Lecturer in Software Technology http://www.chalmers.se/en/about-chalmers/vacancies/Pages/default.aspx?rmpage=job&rmjob=p2899
Application deadline: 2015-04-06.
Please spread the word!submitted by chalmers_job
We're releasing a simple package called executable-hash, which provides the SHA1 hash of the program's executable. In order to avoid computing this hash at runtime, it may be inserted into the binary as a step after compilation.Use Cases
Why might you want this? There are a couple clear usecases, and likely others exist:
Enabling protocols to ensure that different versions of the program don't attempt to communicate. Instead of hoping that the programs' implementation of the serialization and protocol match up, we can catch differing versions early, as part of the initial handshake. This was the motivating usecase for the package.
Allowing logs and bug reports to be tagged in a way that identifies the binary being used. One way to do this is to use the version number / git commit SHA. For example, this code captures this information by using git-embed and cabal-file-th. While this can be quite helpful, it isn't quite as precise as having a hash of the binary, identifying the exact version of the program, taking into account:
Working copy changes
Different dependency versions
Different compiler versions
Note that since shared libraries are not directly included in the executable, differences in shared libraries do not affect the hash.
From this, we see that computeExecutableHash returns Nothing if the program hasn't been compiled to a binary (probably due to it being interpreted by ghci, runhaskell, or the GHC API).Injecting the hash into the binary
If the package just consisted of the above definition, it probably wouldn't be worth announcing! The main nice feature of executable-hash is that it can utilize file-embed to insert the hash into the executable. This way, we don't need to compute it at runtime! This works by generating a ByteString constant in the code, which will also be present in the generated binary. As a step after compilation, we search for this constant and replace it with the executable's hash.
The executableHash function uses the injected hash if available, and otherwise computes it:executableHash :: IO (Maybe BS.ByteString) executableHash = case injectedExecutableHash of Just x -> return (Just x) Nothing -> computeExecutableHash
Note that applications which rely on the hash being the actual SHA1 of the executable shouldn't use executableHash. This is because injecting the hash into the executable modifies its contents, and so modifies the SHA1 that would be computed for it.
See the doc for instructions on how to setup injection of the hash into the executable.
I wrote simple script making simple permutation-based encryption.
Waiting for any suggestions.submitted by artem_ban
[link] [7 comments]
It's easy to find a list of FRP packages, and not too hard to find brief comparisons two or three here or on Stack (usually a couple of years old); but despite people asking fairly often, a good comprehensive comparison is yet to arise.
I'm hoping to fix that, but I need some help from people who actually know what they're talking about. :) I'm only six months in to Haskell and fresh on this particular topic myself. But there's a need here, and I happen to know of a good tool to take a whack at it.
I've set up a topic on Slant.co and added what appear to be the current "live" FRP packages (six of them), plus a few bits of pro/con and descriptive info that I've been able to pick up (ones I feel I understand well enough to comfortably make statements about, heh). It's a pretty bare skeleton right now, and the listing is in no particular order (that's based on recommendations and there aren't any yet), but the format should be fairly self-explanatory, and it's all publicly editable.
The idea is that if anyone knows even a little bit about one library's benefits or drawbacks, it has a place to be shared here, and the pile will add up to something useful. And of course, anyone who knows a lot about several is strongly encouraged to drop by! Sources are a thing, and I've used them for my own entries since so far I'm only regurgitating information anyway, but they're not mandatory and unsourced is better than unshared; it can always be cleaned up later. I'll be keeping an eye on this, playing steward and janitor once there's enough there to need it.
Disclosure: I'm employed by Slant.co. But my interest here is personal, it just happens to be exactly the kind of thing Slant is for. :) And the upside is, I have access to some newer site features that are currently back-end only:
spec tables -- example here (top of each option) -- a better place for the little comments like "arrowized" and "pull-based" that are currently in option descriptions; I'd just like to see those made more complete and any other relevant stuff added before I set up the table.
question notes -- example here (just below page header) -- I could just copy in some of (and/or link to) the FRP haskell-wiki page, but it seems a bit dated, and has no descriptions of e.g. exactly what push- and pull-based imply. If anyone can suggest some good text that applies to the whole topic (specifically, how to decide which library is the best fit for personal workflow and/or the task domain) I've got a place to put it. Edit: Got some notes in place now, suggestions for improvement still welcome.
[link] [2 comments]
Since there aren't that many typeclasses with a generic implementation lying around, and considering how enourmously helpful those are, what do you think of making a list?
Every single generic I've seen so far has entered my toolbox and I think the community could benefit a lot from such a list.submitted by notworkingatall_
[link] [1 comment]