Weekly question for Lobsters community: What are you working on this week?
Feel free to champion your projects, personal or professional, ask advice, give feedback, etc.
Writing about values for the book from my talk last year. Playing level 2 of Stockfighter in Haskell; wreq is nice and I’m appreciating the excuse to exercise all the normal Haskell workflow like organizing a Stack project, laying out source files, dealing with errors, etc. Maybe playing some Endless Legend if the writing is done.
At work, possibly shipping code to prod for the first time in 50 weeks, but maybe not. I had three profoundly disorganized clients in a row and am now on a reasonable one. I’m morbidly curious to see if I will go a year of being a 0x developer.
Been a while since I posted in these threads, but I’ve still been busy. (The following is all from the last week and ongoing this week.)
I’m still working on Dylan, but publicly saying a lot less. I’ve talked with a couple of other people who work on Dylan about how the language should move forward and we’ve come to some agreements, but have to write out the detailed proposals and bring them forward for public discussion. This includes plans to extend the type system significantly, improve numerics, consider syntax changes, and look at how we can adopt new(er) ideas in a coherent and consistent way throughout the libraries (like perhaps FRP everywhere).
In a more direct sense, I’ve been working on a new binding for libsodium. I had run into some design issues here as I’m making the binding significantly more type safe than the C API (which treats many things as just being a buffer with no distinction between what goes into those buffers). I had an email out to 3 people who know libsodium better than I, and I’ve since gotten feedback from 2 of them, so I’m free to move forward again.
I’ve also been working on a binding for the Z3 theorem prover. This is pretty exciting / interesting. I’m looking forward to playing with this within the compiler implementation. Again here, I’m looking at how the C API can be improved upon much as I am with libsodium. (The Python API to Z3 is clearly a work of love for someone. It is pretty well done with a lot of effort spent on the details.)
I wrote a microbenchmark last week to hammer on method dispatch in Dylan. In method dispatch, we have multiple code paths, optimized for different conditions. If a generic function is monomorphic (single method inhabiting it), we need only compare that one method. If it is polymorphic (2-4 methods), then we do a linear scan. If it is megamorphic (5 or more methods), then we do a hashed lookup. Unfortunately, this runs into 2 problems: 1) the cut off between the linear and hash based lookups is entirely too low and 2) that cutoff is wrong anyway as I have a case where I have 4 methods but it is already using the hash based lookup. Initial tests of a hack to force me into the correct code path show a ~30% improvement for my microbenchmark. Inspection of the generated assembly code involved in dispatch shows that there are some other gains to be made as well.
Finally, I’ve started some early steps for work on a UI that is similar to some aspects of the Lisp Machine and CLIM (Common Lisp Interface Manager), that permits mixing CLI and GUI operations in a rich manner. I’m taking a different approach to this though than I had before, which will be more language independent on the backend and more heavy lifting on a front end that I’m writing in TypeScript.
Hope y'all have a great week.
I’m cleaning up some of the parser syntax in the MUD that I run, The Last Outpost, in preparation for overhauling the js client so that it works on mobile devices.
The game’s been online for 24 years, running on all kinds of hardware, and I still find things to work on with it!
I’m happy that I’ve finally published a belated blog post announcing that
we’ve open sourced Rib, our Erlang-based demultiplexer for JSON HTTP APIs. Now it’s time to finish the talk for :clojureD and Clojure
Remote, where I’m going to share what we’ve learned when building Rib. Can’t wait!
Still working on my minimal terse lisp implementation (github page: https://github.com/charles-l/po). It’s got a basic parser and some simple functionality. There are lots of bugs and memory leaks that I’ll have to fix eventually, but I at least made some progress over the last week :)
After failing to continue learning Haskell quite a few times i started learning OCaml by reading Real World OCaml and it’s pretty nice.
Real World OCaml
The language is expanding my mind everyday and helps me cope with writing Java @work
Continuing with Exercism in Elixir, although as @pushcx has just reminded me about Stockfighter I might go play with that as well.
On the home network front I want to get something setup to monitor my home internet connection, as it has native v4 & v6 but the v6 appears to drop out occasionally still. (It’s still a beta trial from the ISP, so I’m not bothered, but it’d be nice to track.) Current thinking is getting Smokeping running. Also toying with how else to track & graph things internally, which probably means getting Graphite running somewhere locally. (What fun.)
Having unexpectedly had a month mostly not training on the bike/in the pool, it’s also time to get back into a routine for both. Experimenting with scheduling them in my calendar for a week to see if that helps motivate me (bike is especially irritating at this time of year, UK weather is so variable and the turbo isn’t such a glorious alternative to a rainy ride.)
Instead of graphite, you could try InfluxDB, which is pretty easy to setup. Pretty much just a go binary to run.
Yeah, I was tempted by InfluxDB, I even managed to get it compiled for & running under SmartOS zones. We use graphite at work though, so I can mirror our setup there quite simply. (And provide more value to the company by knowing more of our stack. Being able to mirror the stack at home is more beneficial to me though ;-) ).
I’m still not taken by any of the time series DBs really. What I really want is something like the sqlite of time series DBs. Given the amount of writes that are stored, that’s perhaps the wrong thing to want though. (I guess maybe rrd’s are what I’m after? Who knows.)
Reviewing a NoStarch book at home, have been doing a Django upgrade at work for almost a month now. Boy, has that upgrade been unpleasant. Django loves to break everything for the most frivolous of reasons, renames functions and variables just because it doesn’t like the old names. I probably have a blog post brewing about this. This is my credo on the matter.
I really like the way the Ember project handles removal of things like this. They mark things as deprecated in minor versions, providing a clear upgrade path for all deprecated features. Then in the major version transition, the only change is the actual removal of all things previously marked deprecated. So if your code works without deprecation warnings in the most recent 1.x version, it will work without any change in 2.0. This sort of process is more work than you would othewrwise have, but it makes for a really pleasant upgrade experience (although of course no upgrade is painless).
Django does about the same. I still find it unacceptable. Whatever benefit they got from renaming “query_set” to “queryset” does not seem to warrant the time I and everyone else who uses Django has to figure out why things broke, look for the docs, spend time hunting through all instances that have to be renamed; and do all of this both in my code and the pull requests I have to send upstream to everyone else.
Projects like git, Linux, LLVM and Mercurial instead define a forever-stable API (CLI for git and hg, C API for LLVM, userspace for Linux) and a private, forever unstable internal API (Python for hg, C for git, C++ API for LLVM, non-internal API for Linux) where the developers can act out their urges to change all of the frivolous things.
… I really need to take this to my blog.
 Or nearly so, I only know of one instance in which git has altered its CLI in a backwards incompatible way.
With the Rust FAQ now live (and receiving good reviews, about which I am exceedingly pleased), I am moving on to my next effort in the Rust community: the creation of a guide to starting and maintaining a quality crate (Rust package). It is still in its early stages, but I hope to have a first draft available for input soon. Like the FAQ, this will be something with a lot of community input. I am particularly interested in talking to major crate maintainers about the things they do that have worked for them, and what they feel is the most important part of the process.
I’ve also started work on a new project to create an embedded Scheme for Rust (similar to the relationship between Lua and C), called Ruse. The project is brand new and very little code is written so far, but I am opting to do this in the open to both solicit feedback and learn. If you’re interested in contributing or have any ideas or questions for me, let me know. This will be my first time implementing a language from scratch, so I am going to do a lot of things wrong or suboptimally. I’d love to hear when I do.
Ruse looks nice, I have access to the main maintainer of Gambit lisp here at my university. I’ll mention the project to him if I ever meet him at the weekly colloques.
Working on contract on a new social iOS app, shoring up the API in the final week of the sprint.
Traveling to Texas for the first time. Brisket, baby.
Writing a new blog post
Hitting up the Compose Conference this week; otherwise, just chilling with my family on a road trip through Montreal and Boston and New York.
Still working on my keyboards, when I have time to do so. Got the keycaps, desoldered half of my poker 3 for plate paint stripping, thinking about getting blue gaterons for the clear dome on the switch to complement the acrylic case on the poker. Also prototyping out a project for a usb-multiplexing keyboard that can switch between multiple computers (/usb outputs) carrying all attached usb devices with it.
A blurry, half awake 2am picture of the layout the Matias V60 is getting (along with the keycaps for the poker under the case for the poker under the case for the Matias V60, which is also pending paint stripping): https://pbs.twimg.com/media/CaH4dUjUUAAWIn0.jpg:large
Disclaimer: I am not handling paint stripping chemicals with bare hands. The orange goop is there for my bikes!
Finally managed to put together my little shell-based launcher for dwm, but then I found out another project has the same name, so I’m making some adjustments. Also, I decided to be somewhat responsible and use it for an extended period of time before releasing it.
There are good odds I will be switching jobs. As my “Zen time” contemplating my options, I am working through various Project Euler questions in C, for some reason.
I’m going to work to improve my Perl 6 Kafka client PKafka. Specifically allow the user to query metadata.
Long time no post…
Just finished writing instructions for using Travis-CI with Monkey Test It. This week I’m going to try to add screenshot support to the report view.
Thinking about making my own Scheme implementation that would compile to Rust in a similar fashion to CHICKEN Scheme. The Scheme programs would compile to Rust programs that instead of returning at the end, would just call a continuation upward the stack. Once the top of the stack is reached the GC can be initiated. Of course, it would all start with an interpreter first.
I’d like the language to implement R7RS fully and then have first-class support for concurrency and a good record and module system, eventually. That would be fun. Also add Rust interoperability to the list.
A little bit of hardware hacking: turning a Raspberry Pi and a Sparkfun Big Dome Switch into an Octoalert fo rmy 4yo’s birthday party. It appears that I have forgotten more than I ever thought I knew about discrete components (transistors and resistors and LEDs and so on)