pheasantquiff

Russ Cox, core developer on unix, plan9, plan9port and golang, does a video series on

AdventOfCode[2021] using sed,prolog and ivy (APL-like) among other languages.

Russ Cox, core developer on unix, plan9, plan9port and golang,

does a video series on AdventOfCode[2021] using sed,prolog and ivy(APL-like) among other languages.

Long, interesting and thoughtful comment chain created by posting an, effectively, empty link on HN.

(reached the first page too!)

I see a possible solution. Have a tool which posts to your blog _and_ to twitter.

You get the engagement on twitter and also have the information in the open for other people to read too (you can link the blog post at the end of the inlined twitter long form post).

Eat your cake and still have it.

Thank you so much for doing this (or, at least, intending to) and apologies for calling you "not tech-aware" :)

Also thanks to our anonymous benefactor who actually uploaded the books to archive.org.

This looks really interesting.

Can some kind soul please upload (at least one) of these books to archive.org? That seems a much better place for Public Domain works than google drive.

I understand that the people releasing the books may not be tech-aware enough to realize that many people will not download them from google drive (this is not for technical reasons).

xv6/unix-like teaching OS - Lecture Series

This is a clear, informative, university-style, lecture series on the MIT xv6 teaching OS (based on unix v6).

While I understand the point about displaying a time in a given timezone (output/strftime)

I don't see how specifying a timezone on a epoch count makes any sense (input/strptime).

A 'number of seconds since epoch' (%s) is a _duration_, not a time. It makes no sense to attach a time zone to it. (This seems to have been the initial response from the project maintainer).

From the original article the reported "bug" is about _parsing_ an epoch duration, not about displaying a time.

DateTime.strptime('0 +0100', '%s %z')

Probably I am missing something but I've re-read the original article and I cannot see this point addressed directly (examples are given but they have to do with displaying/output, not parsing).

This!

I too, have resorted to the same techniques, making me feel like a "master forger" at his painstaking art.

I was imagining a tool which would just let me create an interactive overlay on a PDF. It sounds like Xournal might be just the thing I need. So, thanks for the tip.

The de-anonymizing attack is very interesting. Thank you for highlighting it.

The creator name is 'feature creep' about a future use scenario. People were trying to add uniqueness by changing the creator name, so I added it to the key generation hash.

Instead I should have removed the creator name field from the interface.

My first paying customer! Happy Day!

Srsly tho. at the moment I don't have those features, but neither did the PDF form experience I'm trying to beat. It's a low bar, but we are still expected to fill out PDF forms today, in the future year of 2022.

(just between you and me, I was planning on ignoring the suggestions for extra libraries and "modernisation"; also it's a feature that it doesn't use a gui form designer. ssshh don't tell anyone...)

Thanks for the Milligram suggestion. I will look into it. It may even fix your mobile experience.

Also thanks for for the mobile test feedback. Can I ask what mobile device you tested on? Such data points would be really useful to me.

I actually did test on my phone first, Android/Chrome and _in landscape_ it appeared usable. The PDF also produced OK. It was not an _amazing_ experience but compared the PDF form experience I had it was a delight. I don't consider a phone when I have to fill out a form but in an emergency it would have been possible.

Editing in PDF sounds like a good idea.

I just tried it in Firefox (latest/postmodern, Linux) and none (not a single one) of the form's fields are editable. It's an even worse experience than Libreoffice.

> Is no code a marketing term for code

Yes.

I could have said "low-code" and probably have been able to look at myself in the mirror. Now I am thoroughly ashamed of myself.

Thanks. I did a re-release and deleted the database of forms. Link is now updated.

(creating the identical form twice is not allowed; not really a problem in real world scenarios)

Yes. Certainly interesting ideas I will look into.

Thanks. I did a re-release and deleted the database of forms. Link is now updated.

Hate PDF Forms? Check out my No Code solution!

Create a form using text markup. Get an URL pointing to the form and mail it to your customers.

I recently received a PDF form (created by M$ Word). I use Linux and managed to open it with Libreoffice (Draw!). The text entry boxes were misaligned or just missing. Digits each had a separate text field. Tiresome... By the time I had re-exported it to PDF with the fields filled, some of the formatting had been changed/lost.

So I made this.

I'd rather fill out forms in my browser. Browsers can print PDF. What could go wrong?

Tell me in the comments below.

Does this mean I can now develop iOS (iphone/ipad) apps, start to finish, without asking Apple's

permission _at any stage_, and then sideload these apps onto my personal iphone/ipad?

(assuming as mentioned elsewhere that I can develop such apps on linux, without needing MacOS)

Thanks for [ncdu]. I like it and had not heard of it.

I see no mention of [KDirStat] http://kdirstat.sourceforge.net/ of which, the much more famous, but later, [WinDirStat], is a clone.

For those in-twitter-visible, here is a, poorly formatted, copy of the twitter thread, for a forth with some interesting ideas:

I want to talk a little about my JIT forth compiler -- the one that sometimes manages to beat C. I want to talk about how what is going on, because I think it's interesting & have some ideas for how to build on it. The idea for this engine was to take the STC (Subroutine Threaded Code) technique and adapt it to a register machine with a single stack, like x86. The big idea is that each word will be given a "type signature", and it will take its inputs & outputs entirely in registers. To this end I defined these immediate words: If the type signature is given, the word doesn't have to receive any arguments on the stack, it receives them all in registers.

Likewise, all the word's outputs are given in registers instead of the stack. The word never needs to dig into the stack for any of its operation. This means we can actually leave the return address on the stack! I.e. when we call a word like FIB, the compiler leaves the return address on the stack, so that "RET" just works as usual. It's a simple CALL/RET. By contrast, if we didn't have any of the "type signatures", like in a standard forth, we need two stacks -- one for passing data and one for return addresses. This works well for the compiler, because it can manage registers (e.g. using a finite state machine, which is what I did) when compiling a definition. But forth systems also include an interpreter, which is used to interpret the text file in the first place.

There's also the question of words like EXECUTE, which have to work with any XT (execution token -- basically a pointer to a word). How does the interpreter (or EXECUTE) manage all the different ways needed to call a word? Well, there's a very nice solution. Actually I didn't change the text interpreter (or EXECUTE) at all when I adapted my STC engine to this new approach. As far as they are concerned, this is still a typical forth system with two stacks. How it works is that each word's XT actually points to a "preamble" that will expose a uniform calling convention for this word. This preamble is responsible for popping inputs from the stack into registers, calling the word, and then pushing the word's outputs on the stack. Thus each word has two entry points: the preamble which has a uniform calling convention that fits well with the surrounding forth system, and the actual word definition which has a calling convention tailored to this specific word. This also allows us to mix "typed" and "untyped" word. An untyped word simply doesn't have the second entry, it uses the uniform calling convention, and anyone can call it if they push the (virtual) stack values on the actual stack.

But when the compiler sees a word with a type signature, it bypasses the preamble. So we only pay for the preamble when we use the uniform calling convention, e.g. in the text interpreter, or when calling EXECUTE. Actually it would be possible to have a typed EXECUTE, one for each type signature. E.g. EXECUTE-(X--X), which would skip the preamble. I didn't implement this because I don't need to, but it's a possibility. So, this pretty much describes how I managed to make a forth engine that compiles fast machine code. There's lots more details about, e.g., how to pick registers, how to inline primitives, dealing with branches, optimization ... But it's too much for this thread. What I did want to talk about is how working on this implementation finally gave me a good idea for how to integrate a type system into forth! One of the challenges of adding a type system to forth, is that forth is very dynamic. There's a complex mixture of execution and compilation going on at all times. E.g. you are compiling a word, say "dup", so now you have to execute dup's compiler, which is also a word. A dynamic type system, like Lisp or Python, would work fine, but it kind of clashes with the idea that forth is a low level language.

Also it doesn't solve the issue of type checking, which is more critical in forth IMO than in those languages, because of its stack-y nature. OTOH a fully static type system doesn't make it easy to implement the dynamic text interpreter, or compile time execution in general. I implemented a fully statically typed forth and it missed this side of the language completely. So my idea is to adapt the approach that worked well for "calling conventions". Each word will actually have two entry points: a "dynamic" entry point, which is the preamble, and a "static" entry point, which is the main definition of the word. Values on the data stack will actually be tagged with their type (& size), like they would be in a dynamic language. But once you call a compiled word with a type signature, the preamble will check that the tag is acceptable, and pass along only the payload, in a register. This would also let us have values that are larger than one cell, e.g. an array slice can be passed around as a single value that takes up two cells on the return stack, and so has two registers. So with this approach we can have this weird mixture of strong statically typed code, with lots of dynamic hooks into it, and a dynamic text interpreter. This is a kind of gradual typing, I guess.

It seems very promising as an approach for building a typed forth engine. Anyway, I'm super excited to try this out! Thanks for reading! If you're interested in this "typed forth" that I'm working on, and want to support me, please join my Patreon!

I love the core (almost forth-like) idea of spawn'ing sections of the argv[] to 'interpret' sub-blocks

rather than having a central interpreter.

(very suckless)

(since no one has mentioned it yet). This project's name sounds a lot like GNUSTO,

a magic word used in the Infocom/Sorcerer games to record an incantation in your spell book.

https://en.wikipedia.org/wiki/Sorcerer_(video_game)

Sometimes you just want to write a quick, useful tool without worrying about all the rules.