afranchuk

For what it's worth, Firefox has had most of these features built into their PDF.js viewer for a while. I believe signatures were recently added. I'm not sure whether there's capability to remove pages or merge PDFs, though.

Here's an excerpt (which is in a map passed to peg/compile) for numeric parsing:

    :nonzero-int (* (range "19") (any (range "09")))
    :int (+ "0" :nonzero-int)
    :decimal (cmt (* (? (<- :int)) "." (<- (some (range "09")))) ,parse-decimal)
    :fraction (cmt (\* (? (\* (number :nonzero-int) :s+)) (number :nonzero-int)
 "/" (number :nonzero-int)) ,parse-fraction)
    :integer (cmt (number :nonzero-int) ,parse-integer)
    :num (+ :decimal :fraction :integer)

Writing DSLs is very easy, and fun! The PEG grammars are very elegant to build up. I wrote a language for programmatic recipes (think scaling, unit conversion, etc) with it and it was a delight. I'd provide an example but I haven't taken the time to write a README so I haven't published it publicly yet.

I've enjoyed the selection on Qobuz, which is all DRM-free and allows mp3 or lossless flac formats.

Note that Firefox profile management is getting an overhaul right now, including an easy profile switching UI. I'm not sure when it will be landing in release, but it is being actively built!

I'm the author of this blog post, feel free to ask any questions!

I forget how I got Trump (it was a different formulation than others mentioned though). But Trump + Titanic = Sinking Ship

Are you perhaps referring to eagle mode?

https://eaglemode.sourceforge.net/

The persona I generated is a Christmas tree light company targeting nuclear physicists. The results were surprisingly cohesive!

However, there is a bug: it seems to insert a newline after every punctuation, including after "Dr." (the persona was "Dr. Thomas").

I built an LFS system during one weekend my first semester of freshman year of college. I had too much free time I guess...

At the time I made it a 32-bit system since LFS didn't (doesn't?) support multilib and I knew I would need some 32-bit libraries.

I used that as my main system for quite a long time, upgrading software or installing based on BLFS or my own intuition as necessary. It worked pretty well! It was an invaluable experience in the development of my Linux expertise.

After about 5 years I got frustrated with the 32-bit system so I did an in-place upgrade to 64-bit. It was thrilling to come out the other end of that, to say the least (seriously). The training wheels were definitely off, but LFS had educated me enough to be confident in doing it. Also I kept around all the 32-bit stuff of course, so I could incrementally upgrade things.

After a few more years (maybe 2018ish?) I grew weary and changed to Arch (now I use void) :)

All that being said, I highly recommend LFS!

Well just today I found unsoundness in a crate I was auditing. It turned out that the crate had since removed the entire module of functionality in question so I couldn't submit a bug, but it led me to take steps to remove use of the crate entirely.

Funny, for the last week I've been trying various self hosted photo apps every night on my home server. Tonight was going to be Photoprism and then I see it pop up here! I've just wanted something that allows me to organize and tag photos, but that also has some sort of API or easy access to the database. I've been looking for something because I realized it'd be nice to see photos on a regular basis in my house: I want to set up a photo frame to display random photos from my family collection that have a particular tag. Otherwise I feel like I'm not going back and appreciating them enough, just taking pictures that are never seen again. Though photo app "memories" address that. I really like Photostructure's approach of always displaying a random sampling of photos when you're at higher organizational levels, that's a fun way to see different stuff.

Storage volumes can be much cheaper. For instance, Backblaze B2 will run you around $6/TB/mo, IIRC. And some providers (usually the smaller ones) have discounts for bulk purchases (e.g. a year). Many self hosted apps support cloud storage.

This is great!

For those unaware, the abi_stable crate makes stable ABIs (even with complex features like trait objects) pretty easy and, importantly, verifiable. It is primarily useful for rust-to-rust abi stability (for instance when creating a plugin system).

I especially liked the one for the works page itself! Very fun.

I agree with the significance. I've liked the additions over the past few years of course, but the last time I felt a release was this significant was async, I believe 1.39, about 3 years ago.

And coincidentally, the times I've wanted to reach for GATs have been when dealing with Futures (specifically dealing with lifetimes of Futures produced by Fns; basically what gates async functions in traits). I'm excited to be able to finally use them in my APIs!

It doesn't seem so. While not immediately clear, this article doesn't seem to be claiming ownership of the project. It is a third-party review/introduction. They link to the project after the first section.

I think an interesting distinction is this: it's not that 90% of the typing you do is necessarily useless, it's that it's been done before. Copilot is, in a sense, drawing from a corpus of prior work. In that way you are kind of using it as if you found a published library for your more specific use cases. So it's allowing you to draw on prior work without necessarily having external packages split up with the granularity of many variations of functions (which, ideally, would allow you to pull in exactly what you need from prior work, but would certainly be onerous in practice).

That being said, I've never used Copilot myself, so I can't speak very confidently about it. But from what I've seen, it kind of allows you to incorporate every library that's ever been made open source into your project, but in a more granular fashion. Which naturally would save you some typing :)

P.S. I realize Copilot isn't necessarily copying other code verbatim, though I assume pretty often it basically ends up doing that, at least in pieces.

I think sweet-expressions[0] address this, though they haven't caught on much.

[0]: https://dwheeler.com/readable/readable-s-expressions.html

If I'm interpreting "cutting whole lines" correctly, in vim that's "dd" in normal mode. Then you can paste (put) with "p".

I agree discoverability is not great; to be honest I can't remember how I discovered the plethora of commands I use, though I do have a habit of reading the help a decent amount. That's how I discovered "g?" (Rot13) :D

Cool! This reminds me of S.js [0] which I've used a decent amount to great effect, but it seems about half the size. I'll have to look at how they compare (though if someone knows off the top of their head that'd be appreciated). S.js is nice because it has a helper library (surplus) for dom things.

[0]: https://github.com/adamhaile/S

Yes! For the same reason it does the right thing in C APIs. Which many people don't realize (understandably) until they read the fine print in docs.

If you read the specification of std::endl, it simply sends a "\n" and flushes.

Best to try it to figure it out. I tried compiling a trivial main function with `zig c++` (without cross compile) and the produced binary crashed when run. I think it's far more battle tested for C. But I look forward to C++ being improved as well.

I'm not at all disagreeing with the premise, but I'd like to point out that having the ANSI escape codes written to the (in this example) log file shouldn't be that much of a problem. Many tools support them (though I admit that sometimes it's not default behavior). For example, I often use `less -R` for this purpose.

I don't know about other people, but my tokenizer is parameterized over string slice types. So I tokenize from a slice (be it &str or ropey's RopeSlice) and some of the returned tokens have subslices. This allows tokenization to do no heap allocation.

Cool! I was surprised to see ropey as a dependency, I agree those utility functions should be inlined.

I'm currently using ropey to keep the server side state of documents in an LSP server. I recommend you add at least a slice type, as that's typically desirable. But looks great otherwise!

Thanks for bringing that up! I suspected that nix did that, but wasn't sure. This language is also a "task runner" (being used for build systems mainly), so it's not surprising that it behaves like nix does.

Really neat. I've been working on a lazy parallel language and so I read the "HOW" document closely to see the secret sauce. What's exciting to me is that, while I'm not familiar with the academia behind their decisions, it seems that I arrived at the same result with regard to their lazy clones: I realized early in the language that caching the eval results would make things really fast, and this caching ends up doing exactly what their lazy clones achieves!

Of course one place I don't cache is in function application because the language is not pure (so we want side effects to occur again), but this makes me think it might be really good to derive which functions/subexpressions are pure and allow the cache to be retained through function calls for those.

I'm gonna keep a close watch on this. I should probably read more white papers :)

Thanks for filling in the blanks. To clarify (hopefully): I think it's a bit odd to refer to fexprs as if they are an expression themselves. A language could potentially implement it as a flag on an expression to indicate how it should be evaluated, but normally one says that a language/expression has fexpr semantics, meaning that it is passed unevaluated forms.

If a language has fexpr semantics, you can for instance implement both macros and "normal" functions (among many other things) in very similar ways, since the only difference is that a normal function will first evaluate its arguments and then use the results of evaluation, whereas a macro may not do that (or may conditionally evaluate them!).

Hope that helps a little...

Very cool. At work we have a lang (hoping to make OSS eventually) which fills this space and is also a lisp at heart, though with some syntax sugar to avoid parens in common cases. It is also closer to GNU make in purpose right now but with a few extra utilities it could fit in CI/CD just as nicely. Exciting time and exciting technologies coming out!