I was messing with ghci when I tried to implement a YCombinator as followingλ: \f -> (\x -> f(x x)) (\x -> f(x x)) Occurs check: cannot construct the infinite type: t1 = t1 -> t0
I am not sure why it isn't working? Is it because Haskell is a kind of strongly normalized typed lambda calculi and thus self-application is forbidden (but general r?!)
If anyone can elaborate on what is the issue here, it would be greatly welcomed.
Also, bonus points for implementing a correct Y combinator in Haskell! :)submitted by ahar0n
[link] [6 comments]
Stack remembers things for you so that you don't have to. Here's an example.
I had a trivial change that I wanted to try out adding to http-client. Here are the steps I went through:
- git pull
- stack test # yep, project builds and passes test suites
- <<make change>>
- stack test # yep, it still builds and passes test suites
- git add <<my changes>>
- git commit -m <<explain my changes>>
- git push forked-origin
- <<submit PR on github>>
Notice the things I didn't have to remember to do:
- create a sandbox
- install dependencies
- test the other packages in the repo against my changes to http-client
Stack lowers the barrier to open source contributions. If your open source project comes with a stack.yaml, then it is easy for contributors to jump right in and get the real work done, rather than fiddling with package management. Just instruct contributors to download stack and stack test.
Something which is perhaps less obvious at first is how to get ghci to work with your stack-ified project. It's quite simple once you know:$ stack ghci Configuring GHCi with the following projects: http-client-openssl, http-client-tls, http-client, http-conduit GHCi, version 7.8.4: ... Prelude> :load Network.HTTP.Client Network.HTTP.Client> submitted by drb226
[link] [102 comments]
As vaguely promised before, another update on what I've been working on for the past couple of years:
Specifically, it is in the same space as Gqrx, SDR#, HDSDR, etc.: a program which runs on your computer (as opposed to embedded in a standalone radio) and uses a peripheral device (rtl-sdr, HackRF, USRP, etc.) for the RF interface. Given such a device, it can be used to listen to or otherwise decode a variety of radio transmissions (including the AM and FM broadcast bands everyone knows, but also shortwave, amateur radio, two-way radios, certain kinds of telemetry including aircraft positions, and more as I get around to it).
ShinySDR is basically my “I want my own one of these” project (the UI still shows signs of “I’ll just do what Gqrx did for now”), but it does have some unique features. I'll just quote myself from the README:
I (Kevin Reid) created ShinySDR out of dissatisfaction with the user interface of other SDR applications that were available to me. The overall goal is to make, not necessarily the most capable or efficient SDR application, but rather one which is, shall we say, not clunky.
Here’s some reasons for you to use ShinySDR:
Remote operation via browser-based UI: The receiver can be listened to and remotely controlled over a LAN or the Internet, as well as from the same machine the actual hardware is connected to. Required network bandwidth: 3 Mb/s to 8 Mb/s, depending on settings.
Phone/tablet compatible (though not pretty yet). Internet access is not required for local or LAN operation.
Persistent waterfall display: You can zoom, pan, and retune without losing any of the displayed history, whereas many other programs will discard anything which is temporarily offscreen, or the whole thing if the window is resized. If you zoom in to get a look at one signal, you can zoom out again.
Frequency database: Jump to favorite stations; catalog signals you hear; import published tables of band, channel, and station info; take notes. (Note: Saving changes to disk is not yet well-tested.)
Map: Plot station locations from the frequency database, position data from APRS and ADS-B, and mark your own location on the map. (Caveat: No basemap, i.e. streets and borders, is currently present.)
- Audio: AM, FM, WFM, SSB, CW.
- Other: APRS, Mode S/ADS-B, VOR.
If you’re a developer, here’s why you should consider working on ShinySDR (or: here’s why I wrote my own rather than contributing to another application):
All server code is Python, and has no mandatory build or install step.
Plugin system allows adding support for new modes (types of modulation) and hardware devices.
Demodulators prototyped in GNU Radio Companion can be turned into plugins with very little additional code. Control UI can be automatically generated or customized and is based on a generic networking layer.
On the other hand, you may find that the shiny thing is lacking substance: if you’re looking for functional features, we do not have the most modes, the best filters, or the lowest CPU usage. Many features are half-implemented (though I try not to have things that blatantly don’t work). There’s probably lots of code that will make a real DSP expert cringe.
Now that I've finally written this introduction post, I hope to get around to further posts related to the project.
At the moment, I'm working on adding the ability to transmit (given appropriate hardware), and secondarily improving the frequency database subsystem (particularly to have a useful collection of built-in databases and allow you to pick which ones you want to see).
Side note: ShinySDR may hold the current record for most popular program I've written by myself; at least, it's got 106 stars on GitHub. (Speaking of which: ShinySDR doesn't have a page anywhere on my own web site. Need to fix that — probably starting with a general topics/radio. Eventually I hope to have a publicly accessible demo instance, but there’s a few things I want to do to make it more multiuser and robust first.)
In my opinion I think this is a better proposal for fixing fail, "fail _ = mzero". Pros: Less work MonadPlus is already adopted in the mainstream. Follows the same laws as suggested in the MFP because of this MonadPlus law: mzero >>= f = mzero Almost all monads with sensible fail implementations are instances of MonadPlus and set fail _ = mzero Cons: Some monads use the string argument for error reporting. STM is a monad with a MonadPlus instance but errors out on fail. (I believe this is a mistake but i cant find any literature on it.)submitted by darkroom--
[link] [5 comments]
I didn't take any course on compiler design at the University because my interests lay elsewhere, but now I'd like to be able to design DSLs, create plugins for editors, etc...
In particular, I'm interested in statically typed functional languages such as Haskell or Idris.
There are many books on Compiler Design (e.g. Engineering a Compiler) but I'm afraid they only focus on imperative/OOP languages.
What should I read/study?submitted by Kiuhnm
[link] [22 comments]
I ran 'cabal update' on a device with ram less than 512MB, and it crashed because the machine ran out of memory. How am i supposed to install stuff with cabal now? Can i transfer it from another machine?submitted by Distort3d
[link] [13 comments]
I am currently writing a REST API in Haskell using Yesod. I really like Yesod (and will continue using it for future projects), but it seems a little heavy for a simple REST API.
I'm currently evaluating other possible solutions. After some research it seems like there are generally two approaches people take.
The first approach is to use a REST library/dsl. There seem to be three popular packages following this approach:
- site (with tutorial)
- example of connecting servant and persistent by @ephrion
- /u/jkarni says below that servant should really be considered a web framework, not just a REST api.
The second approach is to use a lightweight web framework and write the REST API yourself. There seem to be three popular web frameworks often used when following this approach:
- small example of JSON REST server for a simple blog
- Not as much functionality out of the box as spock.
What are you using to write your RESTful APIs? I would be very interested in any sort of comparison between rest/servant/restful-snap or spock/snap/scotty.
Also, how are you doing authentication for your REST apis?
Edit: There was a similar thread a couple months agosubmitted by cdep_illabout
[link] [39 comments]
I'm working on an API wrapper for a web REST API service. I've done some of the work, that is created the entities-models and the CRUD methods. They are working properly. Now I have to move on and create an interface for a consumer for my library to actually use it. But I can't figure out
How can I organize the files (hierarchy) better? I mean, should there be the modules such as MyLib/Types/..., MyLib/Client/... and something?
What's the best and easier way to allow a consumer to provide their api key or login/password? The config file? Or something else?
And I have other questions.
I'm looking for decent tutorial explaining how to do all this. I found one at fpcomplete but it was quite small and didn't explain all I wanted.submitted by tomotamo
[link] [6 comments]
I am having a problem while using MVars: in short my code that (seemingly) should not leave an MVar empty is failing to do so, and causing an eventual exception.
I have posted this problem on stack overflow, if anyone could take a look it would be greatly appreciated: http://stackoverflow.com/questions/30881229/thread-blocked-indefinately-in-an-mvar-operationsubmitted by Mattiemus
[link] [6 comments]