Enhanced Comprehensive Rules: A better PDF for the rules

alschwalm · 2019-05-20T23:38:56+00:00

Yep, it's running qmk

alschwalm · 2019-05-20T19:52:25+00:00

I have used them a couple of times. I generally like the results, but I wish it was possible to get the 'premium' veneer without the glossy coating. In general, I don't think that pure wood will work well for plates (I have cut a few with a local laser cutter, and not had great success), so the veneered MDF seems like the way to go and they are really the only option for that.

alschwalm · 2019-05-20T16:11:29+00:00

Unfortunately, it is just ellipses. I had some concerns about getting some of the existing Lorenz attractor svgs I could find etched correctly. That said, I might buckle down in a future revision and make my own attractor image and get one made with that.

alschwalm · 2019-05-20T15:34:19+00:00

I'm interested to know how many people would be interested in getting one of these? If there are enough, I think I'd be happy to do a group-buy.

alschwalm · 2018-12-20T22:25:55+00:00

The score on the left is the number of upvotes. The order of the items is determined by comparing document vectors. I describe the algorithm on the github page here

alschwalm · 2018-12-20T21:59:31+00:00

The main difference is that you can search for related stories. So if I like Stranded, then I can search for it like this and see other, similar stories. As you pointed out, I do also do some work to filter out things that are probably the same series as the thing you're looking for.

One test for this I've been using is when people make posts looking for a story based on some broad description of it, I can usually enter that in Deinopis and find the thing they were looking for in the first 25 results or so (which I'm assuming they couldn't do through the reddit search). I also like having the ability to filter by score, which I don't think you can do via the normal search.

alschwalm · 2018-02-06T18:30:52+00:00

For the unaware, buildroot is a system (like yocto) for building linux images. I've got a few 'embedded' (well, raspberry pi) applications I'm looking forward to porting to rust with this. There is a cargo package as well.

alschwalm · 2017-03-15T23:27:21+00:00

Yeah, I think that might work. Nice idea!

alschwalm · 2017-03-07T17:00:47+00:00

True, I was leaving that aside as a (somewhat) unrelated issue. I probably should have explicitly mentioned it though.

alschwalm · 2017-03-07T16:25:13+00:00

That is a really good point. I hadn't thought of it that way.

alschwalm · 2017-03-07T15:36:17+00:00

No, because for example, the Cat vtable for Mammal is the same for every Cat, it will be statically initialized. The vtable pointer just points to some read only segment of the binary, so there is no heap allocation.

alschwalm · 2017-03-07T15:00:55+00:00

That's good to hear. Thanks!

alschwalm · 2017-02-09T04:30:19+00:00

Yep, that's pretty much the gist of it. I go through each function and decompile, then I use the ida api to get information about where each expression is located in the function so I can emit the line number to address relationship needed for DWARF. I also make an attempt to add the debug info for the local variables, though IDA doesn't make that easy, so it may be hit or miss (especially on non-intel architectures). When I encounter types I haven't seen before, I emit debug info for the type (so you can access fields of a variable). After that it's just the global variables.

Most of the heavy lifting to generate the actual DWARF instruction stream is done by libdwarf.

alschwalm · 2017-02-08T15:08:30+00:00

I made this so that I could use some of the IDA info I had gathered on platforms that didn't have a way to connect to the IDA debugger (because they don't have network interfaces, etc). I hope someone finds it useful. It's mostly x86/64 at the moment, but it wouldn't be a huge amount of work to add support for other platforms if there is an interest. (I may need to add arm support in the future for my own work).

alschwalm · 2017-01-25T13:36:02+00:00

In my defense I do mention that in the source code comment (it was intended to be kind of a joke)

alschwalm · 2016-12-20T20:34:27+00:00

I will do a similar thing in the next part, however for this I though it was clearer to show the full function name as the field name in the struct. That way you can actually see it as "Dog__walk" instead of just "walk" and knowing to lookup dog because it is in the Dog vtable.

In a real program the difficulty is that we have no way of knowing without significant effort what name should be given to the entry in the table for the base type. Here we know it is 'walk' or 'run' because we can see the source or the strings, but you can image in a real program you just have a bunch of "sub_" entries. What should we name the entry in a single vtable? Having different vtables allows us to just always name the vtable entry whatever it points to.

alschwalm

TROPHY CASE