profquail

SIG is hiring for some roles in Sydney: https://careers.sig.com/global-experienced

Pennsylvania has oil and was formerly a British colony: https://en.wikipedia.org/wiki/Pennsylvania_oil_rush

https://en.wikipedia.org/wiki/Synecdoche

Another option is to build your own. You could buy a small ARM board like a NanoPi R6S (<$100) with 2.5GbE ports and run pfSense on it.

Are you using Windows’ built-in Powershell? If so, are you allowed to install the newer Powershell Core (based on .NET Core)? The latter has a lot of fixes and improvements compared to the built-in Powershell.

WinFsp (FUSE for Windows) has an NFS driver: https://github.com/winfsp/nfs-win

zlib-ng also has adler32 implementations optimized for various architectures: https://github.com/zlib-ng/zlib-ng

Might be interesting to benchmark their implementation too to see how it compares.

The complicated number encoding scheme you mentioned is a hexfloat: C has them too.

Hexfloat can be really useful when you need precise/exact floating-point constants for numerical methods. Without them, you end up having to do more-complicated hacks to preserve exact constant values when code gets compiled, or you have to live with compilers (sometimes) subtly altering constants.

I wish more languages supported hexfloats.

Your idea for the secret to prevent spoofing is interesting and reminiscent of the verification secret in the SCTP packet header: https://en.m.wikipedia.org/wiki/SCTP_packet_structure

I think it’s more like Gandiva or DataFusion (both from the Apache Arrow project).

M-DISC: https://en.m.wikipedia.org/wiki/M-DISC

They’re special DVD and Blu-ray discs designed for long-term storage. DVD and Blu-ray are so widely used, it seems likely you’d be able to find some equipment in 30 years that could still read them.

There’s also a company here in Philadelphia that makes custom split-flap displays: https://www.oatfoundry.com/

If you want to do set thread-core affinity in a cross-platform way, hwloc is a good approach: https://www.open-mpi.org/projects/hwloc/doc/v2.7.0/a00166.ph...

https://en.wikipedia.org/wiki/Fermat's_Last_Theorem

Hoogle is pretty neat — you can search by type signature and it’ll find matching APIs from hackage packages: https://hoogle.haskell.org/

Source: https://github.com/ndmitchell/hoogle

Now could be a good time to make this change, in coordination with HPy: https://github.com/hpyproject/hpy

I agree though — it’s tempting to keep extending and stretching the language to be something it was never designed for; but at some point it’s been stretched so far it loses the properties that made it attractive to start with. I like Python, but some of the things people are using it for now, they should really consider another language instead, and write a Python wrapper on top of that if they must use it from Python.

The Opal webcam ($300) looks fairly similar in specification to the new(ish) Dell UltraSharp webcam ($200): https://www.dell.com/en-us/shop/dell-ultrasharp-webcam/apd/3...

What is Opal offering over the Dell webcam for the extra $100?

Lisp machines had hardware/OS-based garbage collection ~40 years ago: https://en.m.wikipedia.org/wiki/Lisp_machine

This was standardized as the L1 Sync feature of IEEE1588:2019, as described here: https://blog.meinbergglobal.com/2020/09/17/whats-new-in-ieee...

Kats looks like a useful library, but I’m a bit surprised to see they’re not enabling parallel execution for the numba kernels. Surely FB must have time-series data large-enough they’d see some performance benefits from parallelism in these functions?

The original code was written in F#, then re-written later in F7 then F* (FStar).

MiTLS is written in FStar, not F#. FStar has some tools (like Kremlin [1]) for extracting C code from the verified FStar, so in theory it wouldn’t be too hard to also extract Rust code too.

[1] https://github.com/FStarLang/kremlin

Maybe more like: next time there’s a downturn, keep the orders if they can afford to. Having the chips on hand when the market picks up again could be a great investment, since they’ll be able to produce vehicles when their competitors can’t. Or they can sell some of the chips they’re holding to their competitors (at the going market rate).

Sure, it’s important for a library to have C source code for portability. That doesn’t exclude implementing the code in another language (such as F*/FStar or Dafny) that has stronger out-of-the-box safety guarantees, then compiling it to portable C source code for distribution.

The 2600 Magazine community is still alive and well:

https://www.2600.com/

You can also use SQL:2011 "System-Version Tables" (a.k.a. temporal databases) supported in most of the major RDBMSs now. You'd just need to keep track of a timestamp when you started querying/paginating and include it as part of the SQL query, which'll give clients a consistent view even if the database is being concurrently modified.

You could use something based on DPDK, like pktgen-dpdk: https://git.dpdk.org/apps/pktgen-dpdk/

oneAPI uses DPC++ (Data-Parallel C++), which is pretty much just SYCL, which itself is a C++ library on top of OpenCL.

From my understanding, the Khronos group realized OpenCL 2.x was much too complicated so vendors just weren’t implementing it, or only implementing parts of it, so they came up with OpenCL 3.0 which is slimmed-down and much more modular. It’s hard to say how much adoption it’ll get, but with Intel focused on DPC++ and oneAPI now, there will definitely be more numerical software coming out in the next few years that compiles down to and runs on OpenCL.

For example, Intel engineers are building a numpy clone on top of DPC++, so unlike regular numpy it’ll take advantage of multiple CPU cores: https://github.com/IntelPython/dpnp

Another approach to solving this issue is with a temporal database (standardized in SQL:2011); supporting a “valid time” in your query gives your user a consistent view of the database tables even if others are modifying it concurrently. It’s also handy if you want to keep audit records of the database (e.g. so users can see who/when/what changes were made).

https://en.wikipedia.org/wiki/SQL:2011

The optimizations get you the following:

* Normalization: this is where "smart constructors" come in handy; having a normal form for the terms allows the caching to work better. This also impacts the compactness of the generated DFA. * Hash-consing: this turns structural equality (in this case) to a simple pointer equality; applied recursively, this makes it much faster to compare two terms for equality, and overall speeds up the DFA generation by a non-trivial amount (I forget the exact numbers, but it was significant). * Dense set implementation: The AVL tree-based data structure in the facio/Reggie code is an implementation of the Discrete Interval Encoding Tree (DIET) data structure from "Diets for fat sets" and "More on Balanced Diets" papers.

Note the optimizations I've mentioned here impact the performance of generating the DFA. Once you have the DFA, it'll run at the same speed as one generated in any other way. Part of the motiviation for my writing this library was to learn about regex/DFAs/grammars, but also to try to improve on the performance of fslex/fsyacc at the time. Using this library, the FSharpLex tool can generate the DFA for the full F# language grammar in well under 1 sec; the code generation takes a bit longer, largely due to having to convert the DFA into a different form for backwards-compatibility with fslex.

Overall, I feel like the derivatives technique is generally better and simpler, and I'm not aware of any real downsides. The only one that comes to mind is if you're wanting to implement things like backreferences and capture groups -- those obviously make the implementation (of the DFA) more complicated, and there's a lot less literature on it (last I saw, maybe only one or two papers on implementing those features on top of a derivatives-based regex engine).