This is the weekly thread to discuss what you’ve done recently and are working on this week.
Please be descriptive and don’t hesitate to ask for help, advice or other guidance.
Make Rust’s regexes faster.
Over the long weekend, as a birthday treat to myself, I also started messing around with a multi-producer/multi-consumer queue with “select” in Rust. It’s grotesquely inefficient, but I’m more interested in the abstraction at this point (and seeing how far I can get without unsafe).
Getting the MVP of Roost, my package manager and build system for Swift, ready for prime time. If Apple really is going to free Swift from the limits of Mac and iOS apps then the community will need an open, extensible platform for developing, building, and deploying Swift programs.
The Venmo iOS team will love this. Do you want an intro?
Sure! Would love to get other people’s input on this and make something really useable for the community.
Inspired by Bunnie Huang’s DIY laptop, I am researching low-power displays in order to create a mobile device with extreme battery life.
The best “traditional” display for this purpose is probably the Pixel Qi, originally developed for the One Laptop Per Child project. They are color TFT monitors, but can also operate in greyscale mode if you turn the backlight off. Power draw is roughly 5W with the backlight on, and 2W with it off.
The more interesting and difficult option is to use an epaper display. Information on driving these is sparse, and the displays are becoming cheaper but are still quite expensive.
The blog post Kindleberry Pi was the first to pique my interest in epaper displays, however repurposing a Kindle that way does not suit my needs. The Kindle is still running independently, it merely provides an SSH terminal view on top of Amazon’s software. I would prefer the epaper screen to be attached directly to my device, as the primary screen.
I would rather avoid mucking about with waveforms and voltages to drive the epaper display manually. That leaves very few options. Some of Freescale’s i.MX line of processors have integrated “EPD” (epaper display) controllers, but I have no idea which displays they are compatible with, or how to connect them to any given Freescale board.
If I had to purchase an epaper display right this minute, I might get an MpicoSys display with included controller. They only support 1-bit color (black or white, no greyscale), but can be driven via SPI and are the only “easy” way to get started that I’ve yet found.
I may just wait until Freescale’s upcoming i.MX 7 line begins production in November. They’re anticipated to revolutionize the e-reader industry by implementing all your epaper controlling needs directly in hardware, including dithering, animation support, and so on.
I’ve been looking for a usable 8+“ eInk-ish display for a while (another
backburner project, never seem to run out of those), but nothing so far.
That MpicoSys panel looks nice and SPI is pretty easy to work with. It’s
a bit smaller than what I wanted but it looks to be the best I’ve seen
If you find anything bigger, I’d be keen to hear about it; I don’t mind
building a controller for it.
MpicoSys also has a 10.2" display, but the only supplier link that works is Densipaper, who is currently charging £298 GBP ($465 USD). You could save a little by building your own controller, but the display alone is still $385.
On the upside, MpicoSys seems to have pretty solid documentation (PDF).
This thread is perhaps as good a place as any to collate information.
I’ve done a little more research in the past four days, for example looking into “fast mode” for the B&N Nook. I’m not sure how it works at a low level. Although I did find Java source code to one “hack” which enables the setting, it appears to just toggle a hidden option. My guess is that B&N, Amazon, and other e-reader manufacturers have experimented with this but leave it disabled and closed-source. I’m not sure of the impact on battery life, or whether it will wear out the screen.
I did find a great blog post by another person on the quest: http://bke.ro/attempts-source-large-e-ink-screens-for-a-laptop-like-device/
Bunnie/Xobs of the Kosagi Novena open laptop project clued me in to the fact that the iMX6 SoC present in the aforementioned device contains an EPD (Electronic Paper Display) controller. Although the pins on the chip likely aren’t broken out to the board, it gives me hope. My hope is that in the future devices such as the Raspberry Pi, CubieBoard, or other single-board computers will break out the controller to a header on the main board.
It sounds as though there is no way (yet) for DIY makers to use an i.MX 6 to drive an epaper display. I’m still hopeful for the i.MX 7, though. God forbid I have to find a way to print my own PCB.
I’m back at work(ish) two weeks after the baby was born. Right now, I’m catching up on what other people have done while I was running silent, and repatching some local OpenCV related stuff that broke in the last few builds. I’m also piecing together the bits for a big SP CUDA machine for the house, which means reading a lot of semi-literate, overly paginated “reviews” on “enthusiast” tech sites. It’s … a thing.
In non-work stuff, mostly trying to sleep and spell my wife who is the one who’s really doing the work around here. I’m also writing up a (finite but unbounded) list of iTunes bugs and misfeatures, just because.
congrats on the new arrival! also - here’s a bug that drove me up a wall where sync was failing to work properly. not sure if it’s still present or not. http://apple.stackexchange.com/q/162525/7087
Congratulations on the new arrival!
I think I’m safe in saying that she’s better than a billion C++.
Tomorrow: meetings in town.
Rest of week: reading, ‘riting, not much 'rithmetic. Def some farm stuff too.
Full speed on generating really cool coasters via a genetic algorithm!
I’ve written basic mutation and crossover algorithms, there are two components of the project left:
Writing a good fitness function! Any coaster needs to have its fitness evaluated, so we can evolve our way toward better coasters. There are three core parts to this:
After this there are more interesting pieces of evaluation, like G forces (sharp turns at high speeds make people sick), number of drops, more things that line up with the in-game rating system.
In-browser coaster viewer - I built a super basic in-browser coaster viewer using three.js, but it’s hard to see vs. a frame of reference, there’s no zoom/rotate, etc. Would be super cool if this could give you a good sense for what a coaster looks like - just needs some tweaking to get the view parameters right.
If you want to get involved, please get in touch via Lobsters message or at email@example.com. Super cool opportunity to play around with Go code, learn a little more about genetic algorithms, etc, and most of the background dirty work has been done already. Now just need to write a good fitness/search function to find those cool coasters :)
Any screenshots of generated coasters?
not yet… will share when I have them!
My company’s aiming for partial Haskellization (10% developer mind share would be success, and 20% would be fantastic) and so we have a lot of programmers who want to learn Haskell. What started as an intern class ballooned into an all-dev class, then spread beyond the company, and is now getting posted to Youtube. Slides and video for the first 2 classes are on Github here.
Currently, I’m trying to unbreak a broken Lisp interpreter (I tried to do something clever with macros, it didn’t work) that will be featured in next month’s lab exercises and I’m finishing up Lecture #6 (wherein I finally attack Mt. Monad).
I haven’t chimed in on one of these in awhile.
I’m pleased to report I’m working more on Hython again. I’d like to clean up what I have, as it’s quite messy. Luckily, it’s not huge (interpreter portion is about 1.5 KLOC). I’m playing with using free monads to implement the interpreter guts (name resolution, exceptions, etc) and pull it apart from the evaluation of expressions and statements. How well this will go, I’m not sure. (If it goes kablam, I can always use a vanilla Interpreter monad).
I’m moving this week, so we’ll see what happens. I kind of enjoy having time to mull things rather than type. I expect to be quite tired; I don’t tolerate change well.
I’ve just put together a Docker image for Google’s Deepdream. I know, I know - a gazillion people did the same thing, but mine will run it as a command-line process, instead of opening an IPython notebook.
With Rust, I’m starting to turn my focus away from the long-form documentation, and towards the API documentation. I’ve started off with https://github.com/rust-lang/rust/pull/26828 , for example. I’m going to be knocking out bugs that were filed too, but I really want to make headway on IO, as it doesn’t have a lot and is important.
Over the weekend my partner and I did a ton of work on a long-term side project of mine, “Artisan Assistant.” The history is basically this: my oldest friend is married to my tattoo artist, and she does the administrative work for his tattoo shop. I saw her messing with some intense Google Docs shenanigans, and said “dear $DIETY please let me write you some software”. This ended up taking a weekend, and it’s just a basic little CRM. She started showing it to other shops, and they were like “where do I put in my credit card.”
Anyway, code is all here: https://github.com/artisan-tattoo/
I’m working on adding Xapian bindings for Perl 6.
I switched a project at $work over to postcss with css-modules(webpack) and cssnext, so I’m putting the finishing touches on the PR. It’s working really well so far but it’s been only a couple people touching the new code.
With the addition of the new CSS structure, all the pieces are in place to deploy a radically simpler component library across the company. That will be my next large piece of work.
I’m also building out a bot whose job is to continuously run processes against and collect stats about our code. There’s a plugin system which basically spawns new docker containers from GitHub webhooks to run against PRs and communicate the info back on the PR. This will hopefully keep our main build process lightweight while allowing us to “scale” PRs with linting, static analysis, statistics, etc
Working on porting the object system in BEAST (music synthesis app) from GObject to IDL-based C++ classes. Quite laborious, given that an object system is ingrained so deeply into an app and library.
But it’ll definitely be worth it once completed and allow new scripting facilities and a badly needed renovation of the GUI to match state of the art DAWs. I’ve summarized the beginning of the efforts in a recent DevLog: https://testbit.eu/rapicorn-idl-moving-into-beast/
Back from a good vacation. I had an idea on how to turn my todo list web app muda into a learning tool. I will have more info once my ideas are flushed out.
i’m reading about machine learning, and that’s about it.
At work I’ve more or less finished up my work on the white box testing team, and have moved over to fixing up our drive management code. The person working on it before me was about 95% of the way through a complete rewrite when she left. The good news is that the new code is a lot better than the old code, so it should be pretty easy to pick up. I hope.
Outside of work I want to do more with my Raspberry Pi and/or Arduino. A while back I wrote a Common Lisp wrapper around WiringPi, and tested it out with a few sensors, but after that I never did much with it. I’d like to get some motors connected and make some kind of robot.
Also been reading quite a bit.
This week at $work getting up to speed on some saltstack stuff, proactively fixing a ton of unit tests that are going to break with some db changes in the pipe. Can’t say I much enjoy fixing all these crufty old unit tests that have accreted over time…like some kind of sick game of Katamari Damacy.
At !$work got some new hardware for the pfsense firewall. Will probably swap that out sometime this week. Migrated from ezjail to iocage this past week – need to do a bit of cleanup there yet. So far iocage is super nice.
Finally getting around to reinstalling my $work laptop, as it got to the point of hard crashing every 30 minutes or so this morning. (It’s been a weekly occurrence for months, I’m just lazy.) Going to take the opportunity to build out my own ansible playbook for setting up my dev environment (instead of my current bash script[s]).
Outside of $work, React Europe had some pretty awesome ideas. Definitely liking the sound of GraphQL, and it’s gotten me fired up again for some side projects. Also been playing with Lotusrb as an alternative to Rails/Sinatra for my own stuff. Liking what I’ve managed so far with it, now to mash it up with React on the frontend too.
can you share your ansible playbook when you get it running! i have a pretty hacky bash script I use to install things, would be great to find a replacement.
I’ve just started writing an interpreter for a small DSL with types and functions in Go. It will run in several steps:
– Unrelated to work!+
.. hopefully that gets done this week. Then I need to seed the lawn with shady grass seed.
It’s my last week in the current workplace. Then I get one week off, and then it’s back to work in a new workplace! It’s a bit stressful. I intend to do nothing computer-related in my vacation. Except maybe reading a book about a programming language or something.
congrats on the new job! hope it goes well! mind if I ask where you are starting?
I’m gonna be working there and it looks awesome.
Working on a rails app doing a thing which basically adds up to “make some things only be visible on a user-defined schedule” which is only hard because there are several people working on the same thing and we keep mis-communicating. It is not currently a fulfilling experience.
Side project: read all of the bundler code and make one minor refactoring PR, basically for no reason except there are a few easy wins and I want something positive in my life. No PR yet.
Life stuff: Helping mentor a current App Academy student who is staying on my couch (college friend, re-career-ing)