winny314

    def create_a_file(filename, size):
        if len(filename) > 16:
            raise ValueError("Invalid filename, more than 16 bytes")
        account = tb.Account(
            id=int.from_bytes(filename.encode()),
            ...
        ...

Is `filename` a str? In which case `len(str)` returns the number of codepoints in the unicode string, not the number of bytes in an encoded representation. Yup the `filename.encode()` sounds like `str.encode()` which itself returns a `bytes` object. Not sure if it matters, but semantically it bugs the heck out of me.

Comment · 3 years ago

Do you have experience with illness related to eating sprouts?

Comment · 3 years ago

SEEKING WORK | MILWAUKEE, WI, USA | REMOTE / HYBRID

I am a Devops engineer; "fierce" to the process. Let's unblock those blockers and make those pipelines green! I will ensure your project goes smoothy!

https://winny.tech/resume/

Comment · 3 years ago

Agreed. We want the wiki to listen to the community's needs and ensure continuity of it. This means a team is likely needed.

Comment · 3 years ago

I share your concerns. I've been chatting with a few people about this and made various false starts... It might not be my project, but I felt I could write down the risks I saw in how the wiki is ran: https://nixos.wiki/wiki/User:Winny/WikiRisks (including vulnerable server software)

Comment · 3 years ago

> I don't know why it would take 18 hours, and I don't see a bug report linked.

It seem systematic to the current architecture or developer experience - since the build environment is different than the local environment, there's going to be stuff that leaks through. For example, missing info.rktd dependencies, native dependencies, not pushing changes to dependencies that were on your local machine but not on pkgs.racket-lang.org yet (breaking api changes, additions), sometimes one gets 5xx errors from the frontend so that doesn't help.

When one clicks the "rebuild" button it simply queues the package to be rebuilt. Then you wait and hope everything is working. And come back to address the above issues.

> Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.

Bottom line, any language that tries to break away from filesystem semantics of your host OS, is going to cause footguns. Sometimes it's okay to break backwards compatibility.

> What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/

My rule is if it isn't packaged in my OS, it doesn't exist in a redistributable form. Racket isn't quite there yet; there's some effort underway to package Racket packages on various operating systems such as Nix, Gentoo, and so on.

> The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.

It's true, however a formal process to discuss feedback and next steps for Racket would help folks like myself feel confident in the direction of Racket. Otherwise it's just people on the internet saying "trust me".

> Talk to the developer of that third-party package?

Unfortunately I have found not everyone is interested in fixing their packages. I think this problem might be best fixed by making changes to the package manager to improve the developer experience. My usual work around is to vendor code.

> Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.

Is it possible to set up a unloadable plugin architecture without signatures and units?

> There's more than that, including doing spectacular productivity and importance, but there's not many.

I look forward to learning more about these users.

Comment · 3 years ago

> It would be interesting if the author post in github a feature request for the 3 missing packages that are more painful. (3 is a good numbers to find someone else that care about one of them, more than 3 or 4 would be annoying)

here's a few that come to mind.

1. mumble client

2. CLI framework similar to cobra, click, etc

3. Bot framework similar to Cinch

4. WebRTC

5. off the shelf plugin framework

6. ssh library

7. gopher library (or just libcurl)

8. ntlk (natural language toolkit)

9. file/libmagic clone

10. image manipulation library

11. expect-like library for automation

12. probably more, these came to mind

> I use continuations only as an emergency exit inside nested fors, no fancy stuff. (I agree the fancy stuff is weird.)

Part of the racket web server requires continuations to use - so that's a blocker for anyone wanting to check out the racket web server in its entirety.

If one needs to do anything nontrivial with state, one might end up wanting dynamic-unwind, which means understanding continuations. (Example https://github.com/winny-/umask/blob/master/umask-lib/umask/... )

> I think units/signatures is almost deprecated. It will be there forever to keep backward compatibility, but I expect new code to use modules instead of units.

Can you do plugin architecture without signatures/units?

Comment · 3 years ago

> I hope though, that people who run into any shortages with Racket consider building the thing they are missing, if they are able to, to add to the ecosystem and to avoid the next person running into the same thing lacking. If no one ever writes their own, we will only ever stick with the status quo in terms of programming languages. (And fortunately people do write their own often.)

Leadership needs to involve the community, then this can happen. Right now it seems that decisions around Racket are made at will - no process or formal discussion.

Comment · 3 years ago

100% this. It was a risk taken and it didn't pay off.

Comment · 3 years ago

Op here.

It's important to recognize pain points so we do not become complacent with low quality developer experiences. Worse, complacency with software lifecycle at scale - will our product deploy on a cluster? Will our software be maintainable 5 years from now?

Better we look at the pain points now than accept a poor DX for years to come.