This came to mind while considering your interesting point: After such a change, wouldn’t you feel the urge to inspect all users of the stricter return type and remove unnecessary handling of a potential null return?
Good point. In such case I would probably consider leaving the signature as is, even after tightening, and possibly offer a function with stricter signature for new code to use while deprecating the older variant. This would inform the users without rug pulling.
Inferno is not a successor. For example you can have Golang for Plan 9 but doesn’t make much sense on Inferno. You would even run Inferno on Plan 9 on some scenarios. I suspect most people who know about Plan 9 also know about Inferno, but it’s just a different thing, does not supersede it in general.
I suspect you would have to port Go to run on Dis, the VM. C is for the OS. It’s a different design, without mmu. Plan 9 is still a classic OS with hardware isolation
I think they are not ordinary words that consume arguments directly from the stack. They also need to look ahead in the input stream of tokens. With support for quoted code, there seems to be no need for any other words operating at the token stream level, like conditionals and def. They just need to consume the stack. I am still digesting this so happy to be corrected.
Forth is very free-form, it doesn't require that your words be 'ordinary' in that sense. The : word isn't the only one that can consume from the input stream, neither is it the only word that can define words (such words are called defining words). The CONSTANT word, for instance, is a convenient syntax for defining a word to push a constant value onto the stack. [0]
You can even define your own 'mirror' of the : word, which involves some fiddly management of Forth's state, but it's doable. [1]
See also [2] on Forth's execution model and [3] on defining your own defining words.
Oh, I don't know about that. Forth words can take control of the input stream! The ordinary parser eats space-deliminated tokens, sure, but how does the " word work? It takes over the input, and reads until it finds a terminal quote! It's wild: learning forth, you get used to RPN... but then you can implement an infix parser, and your "forth" can bootstrap a C-like language all in one source file.
Indeed using a quote to provide the word’s body seems very intuitive. I was asking about this on the retro forth IRC and turned out it could be bolted on to retro forth like: [ body … ] :name
It can be implemented with dnsmasq but dnsmasq doesn't integrate with DHCP (edit, client) out of the box and requires a restart to apply configuration updates which invalidates query cache.
Edit-
I think split dns more commonly refers to serving different internal/private and external/public zones.
In this case, the DNS servers may return the same results but if I'm connecting to a VPN running some distance away, I don't want to route all DNS requests to that server--only the ones for domains on that network. The Domains directive allows configuring this https://man.archlinux.org/man/systemd.network.5#%5BNETWORK%5...
You can add a dhclient hook to reconfigure dnsmasq with `server=` directives to achieve the same thing, but, as mentioned, that still requires restarting the dnsmasq daemon. That usually manifests as: the VPN connection times out, the hook runs, dnsmasq is restarted, but a random web page or request will fail while the daemon is restarting. Sure, you could do SO_REUSEADDR or something to prevent the disruption, but, once again, this all just works out of the box with systemd-*
I don't get your point. DNSMasq doesn't ship with a client, because it's a server. It's a cacheing resolver and a DHCP server that is usually run locally. I don't know of any system that doesn't come with its own built-in (or standard) DHCP client.
His objection is that it doesn't replace the use case that resolvd is supposed to solve. Which is to provide a local service that can redirect DNS queries dynamically as local interfaces go up and down, which is where the integration with a DHCP client comes in.
Makes sense; a lot of the systemd ecosphere seems to be about hotdesking, plugging things in and unplugging them, moving from one wifi AP to another, hibernating and so on. I don't encounter these use-cases, on the whole, which is probably a large part of why I find systemd so annoying.
reply