Inspired by dannyfritz/commit-message-emoji
See also gitmoji.
Commit type | Emoji |
---|---|
Initial commit | 🎉 :tada: |
Version tag | 🔖 :bookmark: |
New feature | ✨ :sparkles: |
Bugfix | 🐛 :bug: |
; An example of YNAB-ish envelope budgetting with hledger/ledger | |
; cf https://github.com/simonmichael/hledger/issues/315 | |
; Using accounts like the following: | |
; | |
; assets | |
; business | |
; bank | |
; wf | |
; bchecking |
Inspired by dannyfritz/commit-message-emoji
See also gitmoji.
Commit type | Emoji |
---|---|
Initial commit | 🎉 :tada: |
Version tag | 🔖 :bookmark: |
New feature | ✨ :sparkles: |
Bugfix | 🐛 :bug: |
These use separate document structures instead of HTML, some are more modular libraries than full editors
So I started writing my some swift code and decided to use a NSURLSession with my existing NSURLProtocol implementation instead of the as of now deprecated NSURLConnection. The protocol seemed to be working ok after adding it to the .customProtocols property on the NSURLSession.
However after attempting to run my tests, they were failing... why? I couldn't work out for hours...
I set up a break point in the canInit and startLoading methods. The application broke twice in the startLoading method, but only once in the canInit method... how could this be? Turns out that the NSURLProtocol was being 're-used' by NSURLSession, this mean't I now had to initialize the protocol object on every startLoad, not just when the object was actually initialised....
After making this fix, I noticed even after this the NSURLProtocol was constantly stopped and started mid way transfer, for this reason I decided to abandon using it via NSURLSession all together and explicitly now call startLoading and stopLoading
The following shell transcript shows how to:
It is assumed that the pass
package has been installed on both the first and second computers.
Title | Author(s) | Year |
---|---|---|
Intuitionistic Type Theory | Per Martin-Löf | 1984 |
On the Meanings of the Logical Constants and the Justification of the Logical Laws | Per Martin-Löf | 1996 |
[[http://mat.uab.cat/~kock/crm/h |
All right, here we go! The API is quite a bit different than what we have currently, but it's simpler to use, more general, and the implementation can be much more efficient. The encoding for Tee
, Process1
, Channel
is greatly simplified, these become just regular functions, rather than a Process[F,_]
with a funky F
. Stepping a Process
is now a first-class concept, exposed publicly, in a safe way. The resulting style looks a lot like ordinary list processing, and doing things like a 3-way or N-way merge are trivial.
The algebra and the canonical model for this algebra are given in the attached streams.scala
. The algebra for streams is given by the trait Stream[P[+_[_],+_]]
, and there's a canonical instance, Stream[NF]
, which specifies what the operations mean. A couple notes:
Process[F,A]
data type we have currently would have a Stream
instance. (Name of Stream
TBD)Chunk
type is TBDFree
is just the free monad (well, one formulation of it)Kris Nuttycombe asks:
I genuinely wish I understood the appeal of unityped languages better. Can someone who really knows both well-typed and unityped explain?
I think the terms well-typed and unityped are a bit of question-begging here (you might as well say good-typed versus bad-typed), so instead I will say statically-typed and dynamically-typed.
I'm going to approach this article using Scala to stand-in for static typing and Python for dynamic typing. I feel like I am credibly proficient both languages: I don't currently write a lot of Python, but I still have affection for the language, and have probably written hundreds of thousands of lines of Python code over the years.