csl

Yes, I can see how it would make sense to be able to set this in pyproject.toml (typically for private package)

uv is still quite new though. Perhaps you can open an issue and ask for that?

Maybe not exactly what you need (sticky) but you can set UV_NO_BINARY=1

See https://docs.astral.sh/uv/reference/environment/#uv_no_binar...

An excellent article. Bill Gates himself posted a comment: https://www.pagetable.com/?p=43#comment-1033

The way I read it, and I may be wrong, is that they will retain the _interpreted_ results, but now the raw and complete data.

I did basically everything you mention, back in the day, although on a C64.

In many ways, things were much easier back then: Direct access to most of the hardware, flat memory layout, smaller and vastly simpler ISAs, smaller programs (meaning shorter disassemblies to wade through), no protected mode so you could overwrite anything in RAM and so on. And you wouldn't even have to do it live in-memory, just disassemble the program piecewise from disk. People did extraordinary things back then, and you vastly underestimate their capabilities. Sure, you had to write a lot of tooling yourself, but it was simpler times.

I am not trying to detract from the copy protection mechanism, which truly is ingenious. I was just genuinely curious whether I was misunderstanding anything from the article.

Very clever and great article! But it sounds pretty easy to write a cracker for it: Just rewrite the machine code to jump over the check. Or did I miss anything?

Edit: Guess it depends on the details and amount of "obfuscation" that he mentions.

It appears to me that if one wants to make progress in mathematics one should study the masters and not the pupils.

— N.H. Abel (1802–1829)

https://en.m.wikipedia.org/wiki/Backspace#^H

The BFR runs on a mix of liquid oxygen and methane, according to Wikipedia.

Ignoring obvious scalability problems, wouldn’t it be possible to manufacture that with a pretty decent environmental footprint from various carbon neutral bio sources?

Truffle + Graal looks awesome. I looked at some old ZipPy slides (JIT compiler for Python) here: http://socalpls.github.io/archive/2013nov/slides/zippy.pdf

They have an example where this code is compiled:

    def sumitup(n):
        total = 0
        for i in range(n):
            total = total + i
        return total

    def sumitup(n):
        if n < 0:
            return 0
        else:
            return n*(n-1) // 2

That is, the assembly generated by clang seems to be equivalent to

    if n <= 0:
        return 0
    else:
        return ((n-1)*(n-2) >> 1) + (n-1)

What is your impression of libjit? It looks really nice. I've only tried GNU Lightning, and I made Python bindings for it (although, today I would have used cffi to interface with it instead of my ctypes approach, because of the header files): https://github.com/cslarsen/lyn

I'd love to see a comparison of the various JIT libraries. I guess both give you optimizations and register allocation for free. Of course, the JITting speed is quite important as well.

Indeed I had already linked to your really cool project at the end. Perhaps I should have made it stand out more. The AST approach is more stable, as the Python bytecode can change between any release while the AST changes in a slower, evolutionary pace.

Anyway, I've made a follow-up post that shows how to JIT compile a subset of Python, directly based on the previous techniques: https://csl.name/post/python-compiler/

Maybe I need to reread LISP, then. I agree that SICP is laser-focused on Scheme, and thus leaves out general compilation techniques.

I do see your point, but I tried to make it clear that this is compilation in an extremely restricted sense: It specializes and executes a function at runtime. And I wanted to cover the core technique of doing just that.

Perhaps I should have included a small example of compiling a linear list of abstract instructions into machine code. But that again would consist of compiling small templates in a coherent way, just like many actual compilers do.

Anyway, point taken, and maybe I'll expand the article or follow up on it.

Is it really that friendly when starting out, though? I found it brilliant, but quite the challenging read. I'd rather just read chapters four and five of SICP [1] and move on to Queinnec as a follow-up on more advanced topics.

[1]: The book is free as well: https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html...

Almost always in evenings, whenever I have time and feel like it. If you're a student, you're probably hosed with deadlines, so pick very small things to try out — things like really simple interpreters.

This particular project luckily turned out to be quick to get working. Also, I kept the scope very small, calling it a day right before getting big ideas.

Brainfuck is simple enough that you could just write out the machine code directly in memory. I think that would make a really good exercise.

I made one based on GNU Lightning to JIT. Even that can be considered a pretty huge dependency:

https://github.com/cslarsen/brainfuck-jit

The interesting part is how slow a one-to-one translation of Brainfuck code to machine code will run without any optimizations. That's where the speed comes from, entirely based on those sweet optimizations. So writing one yourself is a rite of passage, like writing a Mandelbrot renderer.

The above project, from the looks of it, looks quite mature, and therefore interesting in its own right.

Depending on how you plan to use it, a bitset may be more efficient (at least memory wise). E.g. https://gist.github.com/cslarsen/1590498

How can the results be old when the paper is from 2017?

Thanks, I see now that the whole section is very clumsily written.

IIRC, a Busy Beaver may halt or not. You only care about those that _do_ halt, though, and the _champion_ is the one with the most number of 1s on the tape. The whole problem is determining if a given machine will halt or not. Which we know, by the halting theorem, is possible to prove on a case-by-case basis, but not in the general case (i.e., you cannot create an algorithm to determine it).

So you resort to heuristics. E.g., if a machine never has a "go to the halt state" in its transition table, you know that it can't ever halt. But as the machines grow, you'll have to cover an infinite amount of such heuristics, hence the incomputable nature of them.

If anyone is interested, I attempted to plot the first few Busy Beaver iterations: https://github.com/cslarsen/busy-beaver

When 23andMe took down their health reports, I reimplemented most of them myself: https://github.com/cslarsen/arv/

(I.e., arv is a newer version of the older dna-traits, which includes the actual health reports: https://github.com/cslarsen/dna-traits/)

Just `pip install arv`, `python -m arv --example genome.txt` and you're good to go (it's fast as well, parses in 60-70ms).

Note: The following is complete speculation and probably bullshit. Please correct me!

I can't find the actual paper for this one. But reading an older study [0], also about TMEM106B, it seems they had already established an association between three SNPs and frontotemporal lobar degeneration (FTLD) risk.

However, the surprise discovery back then seemed to be the large discrepancy between the controls and the subgroup FTLD-GNR (those with FTLD and GNR mutations) for TT rs6966915 and CC rs1990622. See table 2 in [0], and look at the odds ratios. They are remarkably low for TT/CC, which invites further study that may lead to understand how to protect against FTLD (by understanding possible protective mechanisms, even therapies and so on).

As for listing out those odds ratios for your 23andMe genome, you can do it with arv [1]. For table 1 in the study (unless you know you have GNR mutations):

  import arv
  
  genome = arv.load("genome.txt")
  
  rsid = "rs6966915"
  gt = genome.get_snp(rsid).genotype # plus orientation
  print("%s %s" % (rsid, arv.unphased_match(gt, {
      "CC": "CC - OR 0.94",
      "CT": "CT - OR 1.04",
      "TT": "TT - OR 0.74"})))
  
  rsid = "rs1990622"
  gt = ~genome.get_snp(rsid).genotype # minus orientation
  print("%s %s" % (rsid, arv.unphased_match(gt, {
      "TT": "TT - OR 0.93",
      "CT": "CT - OR 1.04",
      "CC": "CC - OR 0.74"})))

[0] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3034409/

[1] https://github.com/cslarsen/arv

There seems to be a preprint on that chapter from here: http://www.hackersdelight.org/divcMore.pdf

I recommend the book as well, it's got a lot of really awesome tricks!

So, a consultancy company then? Which we all know only scales with the number of employees.

Most people in Europe use Gmail, right? So they must already have figured out this stuff.

I think adding sources would not only be polite, but make it easier for interested readers to delve more deeply into the matter. E.g., as in https://gist.github.com/jboner/2841832

Alexander Fleming gave the following warning, way back in his 1945 Nobel speech:

  It is not difficult to make microbes resistant to
  penicillin in the laboratory by exposing them to
  concentrations not sufficient to kill them, and the
  same thing has occasionally happened in the body.

BBC did a very good radio segment about the penicillin discovery in their "50 Things That Made the Modern Economy" radio series: http://www.bbc.co.uk/programmes/p04pfn2z

Yep, that's a condensed version of the universal edibility test.

It's on page 103 in the FM 21-76 US ARMY SURVIVAL MANUAL: http://www.preppers.info/uploads/FM21-76_SurvivalManual.pdf

This seems to use modulus. The whole point of the mmap trick is to get the kernel/MMU to do the work for you, IIRC.

EDIT: Oops, I see they use mirrored memory here as well.