nitnelave

yes it can: https://github.com/nitnelave/lru_cache

I built the user management UI for my LDAP server implementation like that [0]. It's quite nice (I don't like JS), but it's not super stable yet, the 0.18 update of yew changed many things in an incompatible way. It looks way more like react now, with hooks.

[0]: https://github.com/nitnelave/lldap

It's more that I never properly measured it, but I know that it doesn't use more than that :) I should probably get a more accurate figure in there.

EDIT: From docker stats, I can see the container using about 2.5MB RAM, which is more in line with what I had in mind. It might scale up a bit if you start having 100K users, though :D (but it's really not meant for this and the frontend will crash your browser way before because there's no pagination)

I've been self hosting for nearly 10 years now, and in all this time the biggest pain point I remember is setting up OpenLDAP. That's why I created LLDAP (https://github.com/nitnelave/lldap), a minimalistic LDAP server with a nice web interface that is very easy to set up and configure. It needs a little bit more love before the 1.0 release, but it's already very usable.

It seems they have prerun commands to copy your dotfiles, but you have to specify that you want them. There's an example in the README.

I'm working on a PoC static SQL query builder using generics, but it's pretty opinionated and kinda assumes that the binary is controlling the DB, instead of the DB being independently managed. And since it's static, it would generate every possible reachable permutation at compile time, so yeah :/

EDIT: Now that I think about it, you could have a partially dynamic query that's still statically checked: new WHERE conditions don't change the structure of the query, so as long as they're valid (which can be statically checked) they can be added to the query without changing the type. Same for e.g. ORDER BY or LIMIT. That would make the combinatorial explosion much more manageable, and it would actually represent different code paths (requesting a different set of fields).

It seems to be skewed towards web development, with W3schools as one of the top 3 sources. Selection bias or natural sample bias?

How can you make sure that the walkthroughs are in sync with the code? Especially across repositories. The article is surprisingly light about this.

It kinda reminds me of the rust doc and doctests (snippets in the docs that are valid rust and are run as part of the tests), but across several files/repositories. They can be used to show a pattern, although usually a local one.

I'm working on a dirt-simple LDAP server for self-hosted user management, written in Rust, with the frontend also written in Rust (compiled to WASM): https://github.com/nitnelave/lldap

I had an MVP release last month, and working on compatibility with more services, password reset and so on.

I actually implemented that in Bison a few years ago, using graphs (DAG) rather than a matrix. You could define groups of totally ordered operators, and they were not (by default) cross comparable.

However, given the low popularity of Bison, and that it's mainly used for its old features, I'm not sure that has ever been used in the wild...

I had the... pleasure of meeting M4 while working on GNU Bison (a grammar parser generator): after parsing the grammar, it calls M4 to generate the parser (in C, C++, Java, D or other), defining some variables.

So you get a giant c/c++ file with a parser implementation made of M4 definitions, C preprocessor definitions, includes of generated (lookup tables) or user-written (custom parsing actions) files, and it's absolute hell to debug :D

When life gives you lemons, sue the manufacturer!

Seriously, where does the name of the law come from?

It seems that after years of trying to develop programming languages and architectures to have separation of concerns, with the business logic, the presentation logic, and the data storage separated (or even going to full-blown microservices), this just... bunches everything together?

I get the appeal for a small program that fits in your head, but for anything more complex I don't want the code to take care of everything in a single module/file.

You can multiplex your SSH session and have several ssh commands running on the same connection (without having to type the password/check the security key again). Check the ControlMaster option for SSH.

I remember when teaching a subset of LOGO that we wanted a cool input program for students. So I built reverse logo [1] to turn an image (black-and-white, contiguous) into a logo program that draws it.

[1]: https://github.com/nitnelave/reverse-logo

Author here, I was surprised not to find an LRU cache implementation in common libraries (STL, Boost), so I wanted to make my own. This library is trying to make it easy to experiment with different backends (different maps, lists and so on). The fastest version is based on abseil's node_hash_set, inspired by Java's LinkedHashMap.

Author here, I was surprised not to find an LRU cache implementation in common libraries (STL, Boost), so I wanted to make my own.

This library is trying to make it easy to experiment with different backends (different maps, lists and so on). The fastest version is based on abseil's node_hash_set, inspired by Java's LinkedHashMap.

It seems like you want a reference-counted pointer: you get shared ownership, and the object is deleted when the last reference to the pointer is deleted.

Similar to C++'s std::shared_ptr

Interesting, but there are quite a few bits that are Java-specific. I'm thinking in particular about exposing mutable objects: they mention that even if you expose an immutable reference, the object can still be mutated, same for collections. This is not the case in C++ or Rust, for instance, let alone in Haskell or similar FP languages.

Just a few points that I'd like to answer to this article: - One of the primary concerns of Bison is the speed of the generated parsers. In the section about performance, they say that ALL is 135x faster than GLR. Digging into the original paper, we find that: - 135x is from their best case against the worst GLR they could find - they compare different tools, not different algorithms in the same tool - the grammar they use is optimized for their tool - the best GLR tool they're testing against isn't even running on the same OS - moreover, they mention that the biggest chunk of their performance comes from the fact that they cache temporary results, so theoretically including a cache in a GLR parser could make it even faster. - since there is no grammar analysis, we get back to the classic "static vs dynamic" language debate, where Bison tells you at build time if you have conflicts, and ANTLR relies on your good test coverage. - They only have a passing mention of the fact that their grammar is strictly less powerful than GLR since they don't handle non-direct left recursion.

In a discussion on the usefulness/overuse of operators, I'm surprised nobody has mentioned J. Here's quicksort in J:

  (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

Good luck understanding that!

Advent of code (https://adventofcode.com/2019) is a programming puzzle a day for each day of December, in increasing difficulty.

I chose to start with the more "esoteric" languages to keep the ones I was more familiar with for when the problems are more complex :)

An example of a small Prolog program used in a perfect use-case: the advent of code of this year.

https://github.com/nitnelave/advent_of_code_2019/tree/master...

I'm doing the advent of code in a different language every day, and since the day 4 was about some constraint resolution, Prolog was the perfect tool there.

True, it's not bulletproof. However, with a bit of discipline it's possible to use it safely. And anyway, it's already an improvement over just documentation like "don't call this until you called that"

I wrote something similar in C++, completely compile time that disappears at runtime: https://www.fluentcpp.com/2019/09/24/expressive-code-for-sta...

Although the language itself doesn't guarantee that the value is not used again after a move, good static analyzers will provide a warning in that case, so it can still be safely used.

I'm the author of the article. This came first as an attempt to enforce a protocol at compile-time, in C++.

Feel free to AMA!