Lvl999Noob (u/Lvl999Noob)

Lvl999Noob commented on Using Python for Scripting hypirion.com/musings/use-... · Posted by u/birdculture

two_handfuls · 3 days ago

So cool! I made pawk [1] to get some of the same features, but yours is better! Congrats!

[1] https://github.com/jean-philippe-martin/pawk

Lvl999Noob · 12 hours ago

I am not the author haha. Just someone who found and really liked that library.

Lvl999Noob commented on Using Python for Scripting hypirion.com/musings/use-... · Posted by u/birdculture

theomega · 4 days ago

One thing I can recommend that makes scripting in python with external commands a lot easier is the `sh` module:

https://pypi.org/project/sh/

Basically you can just `from sh import [command]` and then have an installed binary command available as function

  from sh import ifconfig
  print(ifconfig("eth0"))

Lvl999Noob · 4 days ago

And for the opposite, where you keep your main pipeline in shell but want to use python for some parts of it, there is pypyp.

https://pypi.org/project/pypyp/

It takes cares of the input and output boilerplate so you can focus on the actual code that you wanted python for.

    > seq 1 5 | pyp 'sum(map(int, lines))'
    > ls | pyp 'Path(x).suffix'

Lvl999Noob commented on Deprecate like you mean it entropicthoughts.com/depr... · Posted by u/todsacerdoti

Lvl999Noob · 6 days ago

The various projects that say something is deprecated but then don't give a removal timeline or keep delaying the removal (or even explicitly say it won't be removed, just remain deprecated) are the cause of this problem.

IMO, any deprecation should go in the following steps:

1. Decide that you want to deprecate the thing. This also includes steps on how to migrate away from the thing, what to use instead, and how to keep the existing behaviour if needed. This step would also decide on the overall timeline, starting with the decision and ending with the removal.

2. Make the code give out big warnings for the deprecation. If there's a standard build system, it should have support for deprecation warnings.

3. Break the build in an easy to fix way. If there is too much red tape to take one of the recommended steps, the old API is still there, just under a `deprecated` flag or path. Importantly, this means that at this step, 'fixing' the build doesn't require any change in dependencies or (big) change in code. This should be a one line change to make it work.

4. Remove the deprecated thing. This step is NOT optional! Actually remove it. Keep it part of your compiler / library / etc in a way to give an error but still delete it. Fixing the build now requires some custom code or extra dependency. It is no longer a trivial fix (as trivial as the previous step at least).

Honestly, the build system should provide the tools for this. Being able to say that some item is deprecated and should warn or it is deprecated and should only be accessible if a flag is set or it is removed and the error message should say "function foo() was removed in v1.4.5. Refer to the following link:..." instead of just "function foo() not found"

If the build system has the option to treat warnings as errors, it should also have the option to ignore specific warnings from being treated as such (so that package updates can still happen while CI keeps getting the warning). The warning itself shouldn't be ignored.

Lvl999Noob commented on Codemaps: Understand Code, Before You Vibe It cognition.ai/blog/codemap... · Posted by u/janpio

swyx · a month ago

hiya! team noticed your comment and agreed - and it is fixed.

    - const CodeSnippetTwo = `sudo apt-get upgrade windsurf`;
    + const CodeSnippetTwo = `sudo apt-get install windsurf`;

Lvl999Noob · a month ago

Why not use apt?

Lvl999Noob commented on Upcoming Rust language features for kernel development lwn.net/Articles/1039073/... · Posted by u/pykello

William_BB · 2 months ago

What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me?

Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?

Lvl999Noob · 2 months ago

Rust's design eliminates data races completely. It also makes it much easier to write thread safe code from the start. Race conditions are possible but generally less of a thing compared to C++ (at least that's what I think).

Nothing is preventing you from writing correct C++ code. Rust is strictly less powerful (in terms of possible programs) than C++. The problem with C++ is that the easiest way to do anything is often the wrong way to do it. You might not even realize you are sharing a variable across threads and that it needs to be atomic.

Lvl999Noob commented on UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash-masked timestamp) github.com/stateless-me/u... · Posted by u/aabbdev

knome · 3 months ago

creating your uuids client side has a risk of clients toying with the uuids.

creating them server-side risks having a network error cause a client to have requested a resource be created without receiving its id due to a network error before receiving the response, risking double submissions and generally bad recovery options from the UI.

if you need users to provide uuids for consistent network operations, you can have an endpoint responsible for generating signed uuids that expire after a short interval, thereby controlling uuid-time drift (must be used within 1-5 minutes, perhaps), ensuring the client can't forge them to mess with your backend, and still provide a nice and stable client-side-uuid system.

for the uuidv47 thing, you would apply their XOR trick prior to sending the UUID to the user. you presumably just reverse the XOR trick to get the UUIDv7 back from the UUIDv4 you passed them.

Lvl999Noob · 3 months ago

Why not have a transient client generated ID for idempotency but a server generated ID for long term reference and storage?

Lvl999Noob commented on UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash-masked timestamp) github.com/stateless-me/u... · Posted by u/aabbdev

the_mitsuhiko · 3 months ago

You're missing the point here. You can always go from ordered to randomness. You cannot go from randomness to ordered. So by intentionally removing the useful properties of UUIDv7, you're taking away some external API consumers' hypothetical possibility to leverage benefits. If I know (as an API consumer) that I have a database that for whatever reason prefers evenly distributed primary keys or something similar, I can always accomplish that by hashing. I just can never go the other way.

Lvl999Noob · 3 months ago

Never use someone else's synthetic key as your primary key. If you want ordered keys, even if the API is giving out sequential integers, you should still use your own sequential IDs.

Lvl999Noob commented on Float Exposed float.exposed/... · Posted by u/SomaticPirate

burnt-resistor · 3 months ago

No, just no. And, never use sscanf().

This is totally pointless when serialization to and from an unsigned integer that's binary equivalent would be perfectly reversible and therefore wouldn't lose any information.

    double f = 0.0/0.0; // might need some compiler flags to make this a soft error.
    double g;
    char s[9];

    assert(sizeof double == sizeof uint64_t);

    snprintf(s, 9, "%0" PRIu64, *(uint64_t *)(&f));

    snscanf(s, 9, "%0" SCNu64, (uint64_t *)(&g));

If you want something shorter, apply some sort of heuristic that doesn't sacrifice faithful reproduction of the original representation, e.g., idempotency.

Lvl999Noob · 3 months ago

Off-topic, For this kind of pointer casting, shouldn't you be using a union? I believe this is undefined behaviour, as written.

Lvl999Noob commented on Stop writing CLI validation. Parse it right the first time hackers.pub/@hongminhee/2... · Posted by u/dahlia

8n4vidtmkvmk · 3 months ago

Everyone seems hung up on the type system, but I think the validity of the data is the important part. I'd still want to convert strings to ints, trim whitespace, drop extraneous props and all of that jazz even if I was using plain JS without types.

I still wouldn't need to check the inputs again because I know it's already been processed, even if the type system can't help me.

Lvl999Noob · 3 months ago

Pure js without typescript also has "types". Typescript doesn't give you nominal types either. It's only structural. So when you say that you "know it's already been processed", you just have a mental type of "Parsed" vs "Raw". With a type system, it's like you have a partner dedicated to tracking that. But without that, it doesn't mean you aren't doing any parsing or type tracking of your own.

Lvl999Noob commented on Stop writing CLI validation. Parse it right the first time hackers.pub/@hongminhee/2... · Posted by u/dahlia

ffsm8 · 3 months ago

I dont disagree with the desire to get a good API like that. I was just pointing out that this was the core of the desire the author had, as 12_throw_away was correctly pointing out that _true_ parsing and making invalid state unrepresentable forces you to error out on the first missmatch, which makes it impossible to raise multiple issues. the only way around that is to allow invalid state during the input phase.

zod also allows invalid state as input, then attempts to shoehorn them into the desired schema, which still runs these validations the author was complaining about - just not in the code he wrote.

Lvl999Noob · 3 months ago

Why does "true" parsing have to error out on the very first problem? It is more than possible (though maybe not easy) to keep parsing and collecting errors as they appear. Zod, as the given example in the post, does it.