Recent submissions

Comment · 1 year ago
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?

Comment · 1 year ago
Comment · 1 year ago
Comment · 2 years ago
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.
Comment · 5 years ago
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.

Comment · 5 years ago
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.

Comment · 6 years ago
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)

Comment · 8 years ago
Comment · 8 years ago
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?

Comment · 9 years ago
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
It was optimized quite well, but still had loops. I know this is a lot to ask, but I would have expected it to be possible to specialize it to a loopless variant:

    def sumitup(n):
        if n < 0:
            return 0
        else:
            return n*(n-1) // 2
Clang 4+ actually finds this optimization, but gcc and icc doesn't seem to: https://godbolt.org/g/v4zhrm

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)
which might even run faster on the CPU, due to the speficic code emitted.
Comment · 9 years ago
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.

Comment · 9 years ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton