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.
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)
The next big problem with NixOS documentation is that there are a lot of smaller tutorials scattered around the web. Every page with a different style, focus, and depth.
What we need is one central wiki, where any problem search can begin.
This is what makes the Arch wiki so great.
Because forking is also expensive and people would need to discover the new domain. Otherwise I would already have done it. We already have the issue of having too many different sources of documentation. And hacking the wiki is the last thing I want to do... I don't want get visits from the police from $someone.
> 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.
The package server maintains a catalog of available packages.
When you submit a new package, it is more or less immediately
registered in the catalog. This means other users can
try your package quickly.
What takes time is the build server.
The build server builds every package available on the package server.
The build server
- builds the package in a sandboxed environment
- builds documentation
This takes time, since packages can refer to each other.
The advantage is that the documentation can use scope information
to link all identifiers to the correct sentry in the docs.
It would be nice for some improvements though:
- getting a mail when the build is done
- incremental build of packages that no other packages rely on
> 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.
> 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?
Is someone still using gopher? It's weird that there is no libcurl wrapper. I expected to find one. (I used the http libraries that are included in the main distribution, but some people may prefer to use libcurl instead.)
> 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.
Yes, and the webserver has two kind of continuations. In one type the info is stored inside the memory of the racket webserver. In the other type the info is stored in the URL or something, but you must use a subset of Racket to be encoding friendly.
I use the webserver, but I just ignored both of them. Each webpage is a different rkt file. So fancy servlets, no continuations. All the info is stored in cookies or the hard disk.
> 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.
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.
reply