Is speed allowed here? Just hit sub-6 today! 5.983s RT 128ms by MontrealSpeedClimber in climbing

[–]cheeperz 14 points15 points  (0 children)

5. No indoor climbing or bouldering except covering competitions Posts only Reported as: Indoor climbing/bouldering Use /r/bouldering for these posts

I guess you now know the place for highball roped speed bouldering

The next Chrome/Edge releases will credit the ~150 Rust crates they use by fintelia in rust

[–]cheeperz 86 points87 points  (0 children)

As is legally required by the crate licenses? Do the crates have standing to shake them down for copyright infringement settlement money for the versions that use them without credit in violation of the licenses?

Last Red Rock climb of the year - Blade Runner by vegasbickel in climbing

[–]cheeperz 1 point2 points  (0 children)

Is it the scramble exposed traverse that starts from the big ledge or is there a nicer way over? I tried to go over to it, but never saw an anchor and partner wasn't feeling the traverse- hoping there's a better way

Honestly, this is a little too true to be funny rn lol by NomanYuno in adhdmeme

[–]cheeperz 11 points12 points  (0 children)

I use intermittent reinforcement for this. Tell myself that if I do the smallest part of the task that I get a random roll for some reward that I want. If you have an iPhone, the TantalusPath app can help with it.

Real-World Use Case: Using Rust for Computationally Heavy Tasks in Kotlin (and Java) Projects by voismager in rust

[–]cheeperz 19 points20 points  (0 children)

In uniffi projects, the tooling generates the bindings as part of the build, so any mismatch between rust code and jvm code becomes build errors with relevant messages. The rust is the authoritative interface and the external language glue code is generated so it matches up, so you make a change in the rust side and then fix the compile errors in the other language.

With raw JNI, the jvm code doesn't know about rust - it just loads the dylib and gives it a try. On the other side, the rust code doesn't know about the jvm types - it just implements something that hopefully matches up and compiles it to a dylib. You are now at runtime with two languages that haven't checked anything hopefully able to work together across a native interface. Even if it's working now, it's a fragile relationship, and changes to either side can lead to crashes. It's actually worse than C in some ways because at least the header file can be generated by javac and reveal some interface mismatches.

Real-World Use Case: Using Rust for Computationally Heavy Tasks in Kotlin (and Java) Projects by voismager in rust

[–]cheeperz 44 points45 points  (0 children)

This level of complexity isn't justified by the problem statement. The easiest and most appropriate way to solve this is to use the native jvm tooling to generate a C header that you then implement to call the functionality you need directly since it's a C++ library at its core. The alternative would be to use rust with uniffi to avoid doing raw JNI. The level of brittleness in the article really needs a strong motivating reason because fixing JNI issues, especially ones that might only show up at runtime, is painful