dfawcus

What is the problem? Listening to the piece, the accent itself is quite understandable. Just sounds like they're from the West Country.

The only awkward one was where the bloke was talking about fishing in the bright light, I had to watch the 4 or 5 times before I got the hang of it.

Maybe being English helps?

For non Brits: https://en.wikipedia.org/wiki/West_Country

As I recall, my old Nokia 1616-2 would last over 3 weeks between charges if not used. Only somewhat less if only used for texts, say 2.5 to 3 weeks.

It was actually making calls which cut in to the battery, but still it could last 7-10 days with the pattern of usage I had.

That is really what is needed for simple "feature phones"

One is able to chain calls in C via:

    x()->g()->f();

At least one person at Bell Labs historically used that scheme for some graphics program.

All it requires is that the function returns a pointer to a struct which itself contains function pointers.

C also allows the dot form if you really want it:

    x().g().f()

Simply by returning structs, and for all compilers that I know if, such end up using a hidden pointers to structs.

Now to make it a bit more usable, one needs a bit of planning so that either of these can be done:

    x(&x_out).g(&g_out, x_out).f(&f_out, g_out);

    x(&x_out)->g(&g_out, x_out)->f(&f_out, g_out);

(I'd suggest the latter is now the more readable of the two).

Where there is a VFT in each of the xxx_out structures, and the calls simply returns the VFT, while the whole abstraction is stored/returned via the out arguments.

Also from my experience, 2G feature phones have better battery characteristics, longer standby time.

I've a 4G feature phone, and even when only its 2G modem is enabled, it doesn't last as long as the prior 2G phone did. When the 4G modem is enabled (which also uselessly enables its 3G capabilities), it discharges a lot faster.

There is still a picture of the front of the document available:

https://archive.ph/uXyEf

I've been playing with it hacking a compiler written in C++ to be sort of transliterated to D. Just to see if it then makes the compiler easier to read, while not worrying about the performance yet.

So far in converting the lexer it does make it more comprehensible, it will probably do the same for the parser and AST. The real interesting bit will be once I tackle the later stages.

Designated initialisers and compound literals, sure they have caught on, one just has to know where to look:

    https://github.com/danos/vyatta-dataplane/blob/master/src/npf/config/gpc_hw.c#L600-L623

    https://github.com/danos/vyatta-dataplane/blob/master/src/npf/config/npf_rule_group.c#L252-L280

That is code which is around 4 years old.

For the latter example, one could theoretically avoid declaring the variables 'event' an 'rg_match', instead direcly including the compound literals in the respective function calls. However it is a question of taste, and what is more readable.

(The above have designated initialisers, I'm can't remember if there are any compound literal examples there.

There is however one here, when the BSTR_K macro is also expanded, also the earlier BSTR_INIT:

    https://github.com/danos/vyatta-dataplane/blob/master/src/npf/bstr.h#L199

Playing with D, while reading up on Odin and the various Cyclone papers.

Except surely the UK hasn't?

What they've reportedly demanded is that systems be changed, so that later a demand for data may be be effective. As to if any hypothetical later demand for later would contravene the agreement would seem to simply be speculation for the moment.

Surely the UK could just be careful not make a contravening demand at that time? Which would then make this whole "review" a case of PR on the part of the US politician.

Now it is quite bad that the UK has apparently triggered this bit of the snoopers charter, but it would seem to be othogonal to that agreement.*

* Unless someone bothers to review the agreement, and finds that such meta-demand are covered.

It looks like those versions will continue for some time, at least until Sep 2025 on Win 7-8.1 and macOS 10.12-10.14, given the recent announcement:

    https://www.ghacks.net/2025/02/19/mozilla-extends-firefox-support-for-windows-7-to-september-2025/

and I can confirm that I can now read your site using the native user agent string. (FWIW, I expect to upgrade to FF-128 within the next couple of months.)

Hmm - it still blocks me when my browser reports its native string of:

    Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

however if I override it to the following, the site lets be through:

    Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

Oh dear - bitten by his "scraping" protection.

As his site no longer allows me to view with Firefox-115 ESR, it being deemed as "too old" despite still being a supported release.

We had coal fires, and no central heating when I was a young child.

So we had two (steel) dustbins, and the dust-men would empty them.

I can't remember if the bin wagon had a different name, I shall have to ask my parents.

Bin wagon.

It is the nature of the UK Parliamentary system, that when the party in power has a large majority, it is essentially an elective dictatorship. Then 5 years later we may get a different dictator.

This is a well known issue with the system. There are few checks and balances, it rather depends upon honourable behaviour by the participants.

That honourable behaviour ceased to be practiced from around 2000 onwards, and so things have been deteriorating.

The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain.

Possibly also that a significant portion of the suggested gain may be achievable via other means.

i.e. bounds checking and some simple (RAII-like) allocation/freeing simplifications may be possible without rust, and that those are (from the various papers arguing for Rust / memory safety elsewhere) the larger proportion of the safety bugs which Rust catches.

Possibly just making clang the required compiler, and adopting these extension may give an easier bang-for-buck: https://clang.llvm.org/docs/BoundsSafety.html

Over and above that, there seem to be various complaints about the readability and aesthetics of Rust code, and a desire not to be subjected to such.

Only if one buys such a "goodybag".

My father doesn't and so pays PAYG rates when he uses his. Which probably makes sense for him, given his infrequent use pattern.

> Similar things you'd do with a function without a name - work directly with the data at hand, without having to do the extra round trip to the attic to declare its name or shape.

Note that in Alef, tuples are essentially a dual for an aggr, but with unnamed fields. So one always has to (explicitly, or implicitly via inference) declare its 'shape', in terms of number of members, and type of members.

So one could declare:

    tuple (int, byte *, int) t;

Then manipulate 't', one could also have a function return a tuple as in:

    tuple (int, byte *, int) something(int x) { /* ... */ }

Then handle its return value either as:

    t = something(2);

or

    byte *str; int value;
    (nil, str, value) = something(7);

However the tuple 'shape' is always statically determined. Is that in your view satisfactory, or not?

Or do you desires something where the tuple is an entirely dynamic type, sort of akin to syntax sugar on top of '[]interface{}'? More akin to the sort of dynamic thing which Python offers?

Such that one can potentially have a program run, and each call to a given function returning a tuple may have different numbers of elements, potentially of different types within it. So that for said program, if the function return value depended upon input data, one could not determine the full set of tuples which may be returned?

Sorry, but your response seems to be about consistency, or "purity" at some level.

While what Go has may be inconsistent, what functional impact does that have?

I can't see a need for 'de-structuring' as such, absent tuples. Even if it had real first class tuple types, like Alef did, what would one do with them? As I indicated, I'd not want to store them (other than holding in locals), prior to use.

As I recall, Alef did support de-structuring with tuples, as well as re-structuring. One could assign either way between an unnamed tuple, and an 'aggr' (it's name for a struct).

So at most I'd want to break them apart, which the return value thing gives.

Hence if I was creating Go 2.0, I can't see why I'd want to add first class tuples, but could see a use for adding tagged unions.

Re tuples, I guess you mean the multiple return values, and this assignment form: https://go.dev/play/p/vxm6lV7JS4z

However how would real first class tuples be an improvement in Go? Alef had them, and allowed various manipulations, as well as returning them, and passing them to functions.

I note that they are present in Hare, but not present in Odin. Where the latter has the Go inspired multiple return values, but (AFAICS) no tuples, but does add tagged unions.

Generally I'd not want to store a tuple, preferring a struct with named fields.

So the only uses I can think of are those temporary ones for multiple return values and assignments, which are already covered.

PAYG plans do.

Except Contexts provide a cancellation mechanism which can be used outwith of a specific dynamic call graph.

The documented semantics of the facility (and the implementation) seemed perfect for destroying a dynamic graph of CSP elements, which were exchanging messages. Where the cancellation causes the goroutines within the (think Actor-like) CSP element to clean up, tear down, and exit.

The warning about not storing it in a struct seems to assume it can only be used for one specific type of purpose, say web server processes and/or related database requests.

If I hadn't used it, I would have had to create something almost identical - but without the ability to store a data element.

What do you mean by "won't thread them correctly"?

The specific use case I had was where the context represented the lifetime of a (shared) TCP connection. I then wanted to use its cancellation to drive the destruction of various dynamic graph elements hanging off that shared connection.

Think a graph of muxes/demuxes in a dynamic message graph while the whole program is a CSP style thing.

I needed something to drive destruction, the context provided what I needed.

It does seem an unnecessarily limiting convention.

What will go wrong if one stores a Context in a struct?

I've done so for a specific use case, and did not notice any issues.

mind, it is also possible that they took that from Algol 68, and 'adjusted it':

  $ a68g --strict -e '(INT a = 1 000; print((a,newline)) )'
        +1000

As Algol 68 allows spaces within numbers, as well as within identifiers.

Except ANSI did very little in terms of changing/enhancing the language. It stayed largely as it had been since Nov '78:

Nov 78 Memo: https://www.bell-labs.com/usr/dmr/www/cchanges.pdf

About all that happened with ANSI C was that prototypes were created (the major addition), type promotion rules were altered, plus 'const' and 'volatile' were added. ANSI also added 'void *'.

I've a vague recall about 'void' existing in unix C compilers before that, having read a version of the above memo in a unix manual ('papers' section) and it mentioning 'void'.

It one is going to play with obsolete languages, then wouldn't Algol 68 be a better pick? At least it has types beyond "cell".

Or is the idea that BCPL is quite close to the bare metal?

Algol 68 Genie: https://jmvdveer.home.xs4all.nl/en.algol-68-genie.html

See this, code starts on pg 11: https://jmvdveer.home.xs4all.nl/learning-algol-68-genie.pdf (after 18 pages of preface)

See this for how BCPL begat B which begat C: https://www.bell-labs.com/usr/dmr/www/chist.html

Metaware High-C version 1.2 (Nov 1985) had underscores in floating point and integer literals. Possibly it had that even earlier.

Possibly also taken from Ada, as other text in that section of the manual reference Ada.

See A.3 pg 169 (and 58+) of 235 in: https://bitsavers.org/pdf/metaware/High_C_Language_Reference...

  C (K&R) : 1972 => 53 years ago
  C++     : 1985 => 40 years ago
  D       : 2001 => 23 years ago

Also, https://www.bell-labs.com/usr/dmr/www/chist.html

So D is 30 years younger than C, so I'd disagree with "isn't that much younger".

D was really a reaction to C++, not C, so it is with C++ that it should be compared. The C like subset of D (BetterC) is much more recent.

Note that GCC does (sometimes) detect the misuse of the "int a[static 3]" case, but maybe that is only when the length is a compile time constant; and possibly only with char arrays.

  $ make texe
  cc -g -O2 -std=c11 -Wall -Wextra -Wpedantic -Werror   -c -o test.o test.c
  test.c: In function ‘do_test_formatSmallElem’:
  test.c:108:9: error: ‘matSmallElemFormat’ accessing 8 bytes in a region of size 2 [-Werror=stringop-overflow=]
    108 |         matSmallElemFormat(elem, buffer);
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  test.c:108:9: note: referencing argument 2 of type ‘char *’
  In file included from test.c:8:
  mat/display.h:17:6: note: in a call to function ‘matSmallElemFormat’
     17 | void matSmallElemFormat(mElem elem, char buffer[static matSmallElemLen]);
        |      ^~~~~~~~~~~~~~~~~~~~~
  cc1: all warnings being treated as errors
  make: *** [<builtin>: test.o] Error 1