ralph

They're either the output of --help turned into -man macros or more noise than signal. Damn info!

If you want an ed(1) tutorial why not try Brian Kernighan's original? http://nietzschegym.com/edtut.pdf

Yes, I'm a user of ed regularly as well when I would like to mingle interacting with it with my other before and after command line use. If you use vim then `:set t_ti= t_te=' may be of interest to stop it switching to the terminal's other buffer and back; that way on exiting the file's content remains to copy-and-paste from.

The article was OK. I'm not sure it mentioned addressing line 0 for the start of the file, and comma is more common than % for all lines. ed(1) is brief and lots can be learned from it.

As for structural regular expressions as used in sam(1), see Rob Pike's paper. http://doc.cat-v.org/bell_labs/structural_regexps/

I'd just point out that I'm not complaining about something trivial, e.g. open braces on their own line, or a matter of taste, but something fundamentally weird, unexpected, and almost designed to mislead.

I gave up reading this very early on. The striving for compactness of the source, in both C and Go, makes it misleading to read. Take

    if (argc < 2) puts("y"); else {
      for(int i = 1; i < argc; i++) {
        if (i > 1) putchar(' ');
        printf("%s", argv[i]);
      }
      putchar('\n');
    }

A casual skim sees the if followed by an indented block, but that isn't the then-path but the else-path. Now yes, I can read it carefully and follow it, just as if I was debugging someone else's poorly formatted code, but in doing so my attention is being distracted from the main point of the article and frankly I have a huge pile of other things to read that are potentially more rewarding.

PHP has all the beauty of Perl with none of the power.

I think part of the reason folks pillory PHP is their annoyance that people are using it as their first language and may never move beyond it to the better alternatives available.

A key indicator of that is it treating ASCII LF as a line separator not a line terminator, creating text files that don't end in LF.

Why the test of both $# and $1?

    tr -dc '!-~' </dev/urandom | head -c ${1-12}; echo

Change to A-Za-z0-9, etc., to suit.

I pointed out the Protocol Buffers comparison to a friend on IRC. He came back with:

"They rolled their own "high-level" serializer and deserializer for PB, built on top the lower-level stuff the documentation advises you not to use. Using the recommended interfaces, PB is faster than in their test. It is still slower than msgpack. Not sure why they'd make their test look cooked when they win in a fair test anyway. Further examination shows that the test is _mainly_ a test of std::string, for protobuf. std::string is required to use contiguous storage, whilst msgpack's test uses a msgpack-specific rope type."

Why blacklist rather than whitelist?

    LC_ALL=C egrep '^[[:lower:]]{4,8}$' /usr/share/dict/words |
    shuf --random-source=/dev/random -n4 |
    fmt

That's picking from ~35,000 words, which I think is still good enough but avoids ending up with "interpreters incredibility disciplinary constitutionality". (I need the C locale to stop this old GNU grep being painfully slow.)

And note that assumes there are about 2,048 common words to choose from, not the 171,000 you can find in a dictionary.

The font is nice but I'd like one with a sexy `' pair, like they used to be before ASCII went all 8-bit on us. ;-) Also, a dollar that only has the vertical line(s) beyond the S avoids it becoming too heavy compared to glyphs around it.

Oh, OK, I agree, for 2-3 machines reliability isn't an issue, I was thinking more dozens.

They're using pigz on [1] so they are compressing?

I thought it wasn't a great idea. OK for an on-the-fly solution to the problem but bittorrent or multicast would seem better; the serial route between machines isn't very fault tolerant requiring a start-from-scratch on failure.

socat > nc BTW, and does multicast.

As for ssh, it's a shame the "no encryption" option was removed.

Yes, it's a good habit to get into because . is allowed in user and group names whereas : can't be; it's the field separator in /etc/{passwd,group}.

See if bash's ignoredups and erasedups helps.

tmpfs for mysqld's tmpdir is a similar option, perhaps even better if, as I'd hope, tmpfs's internals are simpler and faster because it has an easier job to do that ext3-sans-journal. Obviously needs the RAM though.

It was very fast, and the built-in assembler and easy integration of your code from BASIC, e.g. [.mol% mov r0, #42:mov pc, r14]:PRINT USR mol%, meant there were easy options when it wasn't quite fast enough.

But then you've got to remember that Sophie Wilson wrote the 16KiB 6502 BASIC interpreter for the BBC micro, and the BASIC for the Z80 second processor IIRC, and then brought that experience to bear when designing the ARM instruction set. Having done so, she then wrote BBC BASIC V in ARM; hardly surprising if it knew every little nuance and could wring speed out of it.

In later years, the BBC BASIC code, 6502 and ARM, were good stress tests for emulators because of her wide use of the instruction sets.

Strictly speaking, it wasn't P. being expanded to PRINT at the time of LIST but the byte representing the tokenised PRINT being expanded then. The P. was turned into that byte earlier.

Oh, apologies, I was forgetting Arc's whitec doesn't handle Unicode things like U+2002. The youtube URL needs " The" removing from the end.

Yes, in BASIC you could enter keywords abbreviated with a . to save typing. The tokeniser would turn it into the byte or two representing PRINT ready for it to be interpreted.

I think you're thinking of the four volume RISC OS Programmers' Manual, plus slim index, that came in a big white cardboard sleeve. Augmented later by a Volume 5 of changes with later OS versions to save re-printing costs. BASIC itself was introduced in the User Guide that came with the machine IIRC and had a one-volume reference manual of its own at additional cost.

* causes OSCLI to handle the rest of the line. Dot was an abbreviation for Cat, short for catalogue, IOW ls(1). P. is presumably at the BASIC prompt; it abbreviated the PRINT keyword. OPT had the filing system set some options stored on the current disk; 4 was how to handle the !Boot file. 0, do nothing; 1, load; 2, run; 3, exec, i.e. pretend it had been typed.

The drag-and-drop of the file icons with the sender not needing to know whether it was going to another running program or a filing system? Yes, that was nice. You know of the ROX Desktop? RISC OS on X. http://roscidus.com/desktop/

There's some confusion here. The Arthur OS ROMs, starting with 0.2 on EPROM, that's why Acorn wanted them back on the upgrade to 0.3 on ROM, were written in assembler, including `modules' like the filing systems, BASIC, and the Wimp that gave SWIs like Wimp_CreateIcon. More as a demo of WIMP rather than anything useful there was a Desktop program stored in the ROM, written in BASIC, that used the Wimp module to present a crude selection of calculator, etc. Nothing like the later drag-and-drop RISC OS desktop; no other programs could run with the Arthur version. So there was some BASIC in the OS but only as one stores sprites and other data files too.

The source of RISC OS was opened up. https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources... shows part of the BASIC module which has pedigree going back to when Sophie Wilson, designer of the ARM instruction set, wrote it.

That was Chocks Away, a video that doesn't do it justice is http://www.youtube.com/watch?v=G0x5JbmU6HU. The dog fights were good and the missions had you shooting up balloons and moving trains too. You could link two machines with a serial cable and fly in the same airspace. A friend that worked at an Acorn dealer and I used to visit the shop after hours, he had keys, to play it until early morning, day after day, until we had completed them all. Great fun shouting at one another about who was taking on what in a dogfight. If the machine had an ARM 3 then the graphics had a bit more detail.

A few errors (corrections sent) but worth a read. It was the first computer shipped containing an ARM, the ARM 2. Ignore the crummy looking screenshots of Arthur; the WIMP was usable in Arthur for single-tasked applications but a very-nice co-operative multi-tasking desktop came with RISC OS 2.0.

It had features I still miss today, e.g. drag a scrollbar thumb with Adjust (X's Button3) instead of Select (B1) and you were panning that scrollbar and its partner in the other axis. Adjust often did similar to Select but with a tweak, e.g. the pop-up context menu with Menu (B2) could have an item selected with Select and would disappear but use Adjust and the menu, possibly several deep, remained opened. How often today do you have to re-navigate to a nearby place to select a second item? Select on a scrollbar's up arrow scrolls up, Adjust down; no need to move to the other end of the bar. Same goes with paging by clicking to the side of the thumb.

If speed matters more than compression then consider lzop(1).

Neither? _Bell Labs and CSP Threads_ by Russ Cox, http://swtch.com/~rsc/thread/, as used in #golang.

As a link, http://websocket.us/

If you find the many slides with little text on each frustrating then `lynx -dump $url' gets you just the text to quickly skim.