cromo

Mine did. I eventually suffered very limited mobility due to the pain until I got surgery to move the nerve out of the cubital tunnel.

Ah, that sounds like what I have! Subluxation of the ulnar nerve is what they told me it was - I could feel the nerve popping over my medial epicondyle. We tried steroid shots to reduce inflammation, but it came back after about nine months. It got so bad that I couldn't fully extend my arm or bring it in past ~45 degrees from extended. The inflammation showed up on an MRI. I had surgery to relocate the nerve to the inside of my elbow and have largely recovered from it, though it does flare up every so often.

The scare got me very interested in accessibility and I've looked into using Talon with eye tracking and stenography via Plover to improve my ergonomics, but I've never fully committed to any of them, but I'd love to know what communities exist. A Kinesis Advantage and a vertical mouse seem to keep it at bay on all but the longest of work days.

I'll also encourage you to post a link to the source, even if it's not the cleanest code. I've been thinking about trying to make something like this for a while, but using larger-scale cells from a side-on view to simulate plant growth. (To that end, I'm currently reading The Algorithmic Beauty of Plants[1], which performs its generation via L-systems.) I'd love to see how you've put this system together.

[1] http://algorithmicbotany.org/papers/#abop

As for your second point, I think that's somewhat covered by the last few sentences in the article - he makes short lists of what the book was about and the main takeaways. This makes the book a little more permanent, as you have some external memory you can look over to help recall more details.

My zsh is set up (don't know if this is a default or not; I'm using Oh My Zsh) to not run the command if you use any history expansions in a command, instead it'll give you a new prompt line with the substitutions already filled in. That way you can check that the command is correct before running it.

The wording was a bit confusing, but I think they meant "Java-like" and "VM-based" as separate things, not that Dart runs on the JVM.

I've been following the development of this for quite a while, and one feature that is not erm, featured, is that the actual emulator itself is composed of isolated modules. This means that it's possible to swap out say, the graphics implementation to do a high definition drawer, or substitute the processor with a plain Lua script - essentially, it turns the Gameboy itself into a library! This could be used to make higher-level ROM hacks and patches without needing to know the nitty-gritty of the whole system.

This release does, yes. The actual emulation of the system is straight Lua and does not require Löve at all. You could run the emulator completely headless (as I was pestering zeta to do during development for testing), but there's not yet a headless driver. This also means that you just have to provide the hooks for drawing/sound/input/file IO to give it a different front end. Löve is what was used because it's what we're familiar with.

The first bullet point under the Supported Features section in the readme states that it works on any Lua that provides a bit manipulation library. I know LuaJIT comes with one, and Lua 5.3 comes with bitwise operators, so those could be wrapped up into a compatible module.

It's mentioned in the build section in the Readme - the Joey Generation 3.

It's a handy tool, that's for sure! Funny story about it though - when I took it to the maker space where I could use some tools, the two older guys who help run it scoffed at me for using OpenSCAD - they're used to graphical - and admittedly easier to use - tools. They pointed me at another tool they liked called On Shape, but I haven't done much with it. I feel more at home with OpenSCAD for now.

I'm not really concerned about the exhaust heat. There's a decent amount of clearance, and the fans are gonna be way stronger than convective currents. Since it's also at the bottom of the stairs, it also sits in what is usually the coolest part of my apartment.

If I need more support while handling shoes, I just sit on the stairs or lean against the wall or hold on to the railing. In other words, there are an abundance of anchor points that aren't free standing.

And thanks for the kind words. This is the first thing I've fabricated out of wood in years. It was very satisfying to finally finish it - metaphorically, as it's not actually stained or sealed.

The monitor and keyboard were just for initial set up. I soon got an iDRAC and now control the system entirely over the network, so the monitor and keyboard have been relegated back to emergency diagnostic status - that is, they're sitting in my closet for the time being.

Instead, the top surface now holds my daily carry gear and anything I need to take with me in the near future, such as gifts for family.

I built my own rack for my apartment homelab as well. It's just unfinished pine, but it's a horizontal rack instead of the typical vertical rack to make better use of my limited space. Here's the album on imgur: https://imgur.com/a/D0lXM

No need to be sorry - I've been meaning to do that for a while and just haven't gotten around to it. Synesthesia is really something you have to see to understand how useful it is. I'll see about getting a recording up after work today.

I don't remember how those worked. I think it automatically kept a hierarchy of what tab parented other tabs and colored them that way. That gets kinda strange because it's trying to represent a tree in a flat space, and I don't think the colors reflected their heritage. Since a tab could technically be a parent and a child, you lost tabs to one group or another.

Thankfully synesthesia is really simple - match the string, take the md5 of it, lop off some bits and interpret that as a color. There's no additional structure to superimpose on color selection.

The simple tool I wrote that I get the most bang for my buck out of is synesthesia[1]. I spend a lot of my time tracing things down across multiple log files, and having to pick out the important lines visually or trying to isolate them with custom grep incantations was wearing on me. Synesthesia allows you to specify regexes, and it will color matches based on the value of the match itself, meaning that it's stateless and doesn't need to keep a dictionary of strings to colors. This makes keeping track of things like GUIDs easy - you can just keep track of e.g. the orange one and watch it fly by across multiple terminals. It's currently python 2 only and assumes a 256 color terminal, but it has been invaluable.

I've been toying with using the idea for forums so that it is easier to keep track of who is replying to whom[2]. I also would like to try using it as a layer on top of traditional syntax highlighting, perhaps as an emacs minor mode - if those can provide colors to the buffer; I've written hardly any elisp and don't know what capabilities are available.

[1] https://github.com/cromo/synesthesia [2] https://imgur.com/E1N1Zsm

Same, Firefox 49.0.2 on Windows 7.

I opened the quickstart in Chrome and went all the way through without a hitch until the very end - the last code block doesn't appear to do anything. Clicking submit doesn't update the visible output, nor does it clear the form as the code shows it should.

I'm thoroughly liking the environment other than the hiccups though. I'm not familiar with datalog, but have dabbled a bit in prolog and always liked the way unification felt.

A friend and I made a game for the most recent Ludum Dare using LÖVE. It's a top-down racer: https://github.com/zeta0134/ludum-dare-34

I think there may be a misunderstanding here - mal is not the language you make the lisp (or any other language) in, it is the language you are implementing. Indeed, there is an implementation in Racket, and even in mal itself.

The point of mal is to guide an implementer through the steps necessary for making an interpreter using a language they are comfortable in. It gives some insight into how various constructs are implemented, such as closures and tail call optimization. The purpose is not so much to make a lisp-like language (although that is the outcome), but to learn what goes into making an interpreter for one - especially when you can't lean on the constructs that already exist in the host language.

This reminds me of MAL [1], which stands for "Make A Lisp" or Make, A Lisp" depending on whether you're talking about the whole project or just the make version. It branched out into being implementations of a lisp in over two dozen languages, with instructions to help in writing your own. I was working on a haxe version before my motherboard recently bit the dust.

[1] https://github.com/kanaka/mal

The Docco ( http://jashkenas.github.io/docco/ ) family of tools.

I wrote a Python script (called synesthesia)[1] that'll colorize input based on regex matches, and any matched text will be the same color for the same content.

The use case that drove its development was needing to keep track of UUIDs across multiple logs - and grep --color will colorize its matches, but not differentiate between ones that have different content. With this, I could watch both logs as data was passed from one to the other and keep track of e.g. the orange one.

I also thought it would be nice to be able to use patterns from logstash's grok, so I wrote grokpat[2] to find patterns for me. A lot of grok's patterns use atomic groups, which aren't available in Python 2, so I wrote redi[3] to convert them from grok's syntax to Python compatible syntax.

So I can now colorize logs easily as follows:

  tail -F program.log | synesthesia "$(redi "$(grokpat uuid)")"

[1] https://github.com/cromo/synesthesia [2] https://github.com/cromo/grokpat [3] https://github.com/cromo/redi