If you are pulling your hair out because Devise’s HTTP authentication doesn’t seem to work after an hour or so, don’t despair, I have the solution for you…
If you can see a warning in your log saying something like:
DEPRECATION WARNING: ActiveSupport::Base64.decode64 is deprecated. Use Base64.decode64 instead.
It is not just a warning, the HTTP Auth will fail miserably if you have this issue. The simple solution is to use a Devise version that has this commit applied, preferably version 2.0.4 on your Gemfile would do
You welcome.
The answer is no…
Currently I’m reading the Google Closure: The definitive guide, in order to better use the Clojurescript (cljs) language .
On of the things I was a confused about, was on how cljs managed to handle dependencies on the cljs files, as I didn’t see any options regarding the calcdeps.py on the cljs.closure/build function.
After failing on finding a nice Google search result that would help me on this, I went straight to the source code of cljs.closure/build looking for answers.
The current status is that the calcdeps.py script provided by Google Closure was discarded altogether by an implementation of it in Clojure. This has some limitations given that you won’t be able (as far as I’m concern) to use different --output-mode as given by the calcdeps.py script.
The only options available are either, passing an :optimizations key to the cljs.closure/build function with a value of :whitespace, :simple or :advanced, or don’t pass any at all, in the latter case the result would be a deps file, the same the --output-mode=deps would return, which is very useful on development mode.
If you want to know more, I really suggest checking out the source of the cljs.closure namespace, it is really understandable code and it will answer a lot of questions in the comments.
Some friends and myself decided to formalize a study group we were having for learning Clojure, at this point I think there is enough people that could comfortably work on open source projects.
The idea is to join and share projects as a group to gain more feedback from others, this way if a group checks and uses the libraries instead of individuals this libraries will definitely get more traction.
Hopefully this initiative will bring really great OS projects to life.
Most of times when I was coding Haskell code, I always implemented the Show classtype whenever I wanted to print things on the screen in a nice and fashionable way.
It seems however this is a really bad practice that hasn’t been taught enough in the Haskell community. I discovered this in a StackOverflow question that had nothing to do with pretty printing, but the discussion led to that1.
A user named Matt Fenwick suggested that for whatever reason the guy who asked the question shouldn’t implement the Show classtype, later on I started to comment:
Me: Why not declare Show classtype for the Expr? just curious?
hammar: Show is meant as a form of lightweight serialization. It’s not meant for pretty-printing, although people often abuse it that way. In particular, if a Read instance is also defined, one should be able to expect that read . show is the identity function.
After that realization, I went out and looked over for different pretty printing solutions in Haskell. This was quite frustrating, for some reason I didn’t find any library that would define pretty printing functions for basic containers like List, Set, Map.
The closest I’ve found to an out of the box pretty printing solution was the pretty-show package. However this doesn’t create a new classtype for pretty printing, making it really limiting IMO.
There is also the well established pretty package, This one provides combinators to create pretty printing functions easily, however, it doesn’t provide a classtype or a default implementation for the containers mentioned above.
Lastly the most promising package I’ve found is called GenericPretty. This one provides a classtype for pretty printing and implements some Prelude ADT, however no containers whatsoever and no combinators for generating pretty printing.
In conclusion, the pretty printing solutions are so, so… yet there is potential for something new raising up in the future.
1 | Because of this the title was later changed to Show and Pretty-Printing
When using Clojure’s repeatedly function to read lines from a terminal, or when trying to do IO of some sort, the behavior won’t be as expected
This is because repeatedly instead of calling the action n times, it generates a lazy seq for each time the action function gets called. Given that it is a lazy seq, if you don’t force the evaluation of the list, all but the first element will not be executed.
In order to avoid this, you have to use the dorun function, this is going to force evaluation for each element on a lazy seq, and it will discard the result of the seq altogether, this is because this function is expecting the action body to be for side-effects only
if you come from Haskell land, the idiom (dorun (repeatedly n body-fn)) would be the equivalent to call the function repeatM_.
An example:
At a random time on my development cycle, I was using the awesome Fugitive plugin developed by Tim Pope, and I got the following strange error:
Error detected while processing function 51_Commit:
line 52:
E480: No match: `=msgfile`
Press ENTER or type command to continue
After some googling, I found out the reason was that I installed just a few days ago the also awesome ctrlp plugin. When you were setting up ctrlp, you did something like this:
set wildignore=*/.git/*,*/.hg/*,*/dist/*,*/cabal-dev/*
Well… it seems Fugitive plugin doesn’t like that very much, if you remove the git portion from that setting, Fugitive will work as expected again
Thanks Interwebz
