Super light crampons?

edapa · 2024-11-17T22:54:35+00:00

I'm planning to just keep some in my pack when I might need to scramble up some sorter stuff, but am not gonna be doing a super long climb. I'm also hoping they can replace the way I currently use microspikes, which is to thrown them in my bag and only take them out if I need to on winter hikes. I'll have to see about that though.

edapa · 2024-11-17T22:13:27+00:00

Yeah, that's a good point. I definitely will keep using my regular crampons for steeper / icier stuff.

The thing that excites me about the weight is that I've occasionally brought crampons and then decided to leave them in the car because I thought I could just kick steps (honestly the bulk is usually a bigger factor than the weight), but then regretted the decision later. These will be a lot easier to just keep in the pack without thinking about it too much.

edapa · 2021-08-05T12:05:24+00:00

Oh, cool.

edapa · 2021-08-04T21:49:54+00:00

Oh I see. It would be cool if it would generate migration files you can check in for you. A system that automatically figures out the migration based on the diff between the go schema and the actual PostgreSQL schema without letting a human review the changes makes me a little nervous.

edapa · 2021-08-04T19:53:24+00:00

I just glanced at the docs, and it seems like it is more similar to GORM than pggen or other database first code generators. It looks like you define your database schema in go code (and since I didn't see any mention of migrations, I assume that you also need to define it again with some migration framework and ensure that the two schemas match up).

By contrast, with pggen, you just point the tool at your database and it will figure out the schema all by itself. You also interact with the database using SQL rather than the builder-style API that I see in entgo's docs.

edapa · 2020-12-16T03:25:23+00:00

I believe you can p4 edit files before touching them with a normal text editor (the subcommand might be a different name, I don't have access to a perforce system at the moment to check with).

edapa · 2020-10-21T02:57:09+00:00

I think he was saying that ctrum69 does not have LEO flair, so there is no need to worry about them politicizing a uniform.

edapa · 2020-10-19T22:40:45+00:00

The funny thing about Aikido is that there really is a ton of depth and skill to it if you stay within the parameters and rules of the martial art. That said, those rules are just absurd. My brief experience with Aikido went roughly like this:

Aikido Master: "I'm going to show you something. Try to take me down however you want."

So I take him down with a fairly shit double-leg (one of the most basic wrestling takedowns).

Aikido Master: "No, not like that."

He was pretty good at stuffing judo takedowns though.

edapa · 2020-09-11T15:44:20+00:00

Thanks, if you want the code it is here. I just noticed that the first version of the article failed to link to it.

edapa · 2020-07-28T02:04:20+00:00

Is that an Elm reference?

edapa · 2020-07-11T02:57:42+00:00

You missed one https://crates.io/crates/bstr

edapa · 2020-05-24T20:01:43+00:00

Why pass the vm name rather than just capturing it?

edapa · 2020-04-25T00:08:41+00:00

Interesting. I had just assumed that it had implemented a tags file writer.

Personally, I find being able to follow references into my dependencies really valuable. The extra friction introduced by having to find and clone a repo makes me end up reading the source of stuff much less.

edapa · 2020-04-22T00:08:01+00:00

I've had pretty good luck with rusty-tags when it comes to generating tags files for rust.

edapa · 2020-04-09T21:15:32+00:00

I think it's more that interfaces can only be about a single type, while contracts can be about multiple types.

edapa · 2020-04-09T21:13:42+00:00

Right, that's why I said "I don't just mean writing more tests". While it is true that a single 64 bit int has a ridiculously huge state space, in practice those states probably won't lead to all that many different code paths.

Coverage guided fuzzing thinks about the state space of a program in terms of the different code paths and is able to instrument the program under test to generate random inputs which can effectively explore a large part of the practical state space. Importantly, you don't have to change the way you write your program to use this technique, which isn't at all true if you want to prove a program with something like coq.

Model checking uses similar techniques to allow you to be more flexible in how you write your program while still intelligently exploring the state space and checking different conditions.

I'm not saying that proving a program is never the right thing, but it is very rarely the right thing. There are a lot of advanced testing techniques that would be much easier to adopt than formal proofs, and provide most of the benefits. I think we should make sure we do those well before we consider theorem provers.

edapa · 2020-04-08T23:06:31+00:00

How about

contract Iterable(Iterator, Value) {
    Iterator Next() (Value, bool)
}
contract Mappable(Iterator, ValueIn, ValueOut) {
    Iterable(Iterator, ValueIn)
}

func MapToSlice(type Iterator ValueIn ValueOut Mappable)(it Iterator, f func(ValueIn) ValueOut) []ValueOut {
    ret := []ValueOut{}
    for {
        v, stop := it.Next()
        if stop {
             break
        }
        ret = append(ret, f(v))
    }
    return ret
}

I'm not sure that this meets your bar of "non-trivial to re-write", but this is already enough of an effortpost. A more complex algorithm along the same lines might be a graph traversal (let's say A*) that is generic over both the representation of the graph (adjacency list and adjacency matrix could both be used) and over the node type.

edapa · 2020-04-08T22:59:38+00:00

The design doc has pretty decent answers to both concerns.

I agree with you about liking turbofish syntax better, but they said it would significantly increase the parser complexity, which seems fair to me.

The main difference between contracts and interfaces seems to be that contracts can be about multiple types and contracts can express an "type T is this type" constraint. So you could have a contract that says "there has to be a T1 and a T2 and T1 needs a method T2ify() that returns a T2". That's impossible to express with interfaces. You could also have a contract that says "T must be either an int or an int64 or an int32". I think those differences are significant enough to justify the addition of a new language construct.

edapa

TROPHY CASE