sczi

It means how much of the sqlite test suite it passed. They were just measuring correctness, not performance or memory consumption, where of course Zig should win.

But the aim of that experiment was measuring correctness of llm written code in different languages, so used sqlite as a benchmark considering it's fairly complex software with a comprehensive test suite. It is not suggesting that because a language scores better on that benchmark it'd be better suited to writing the next sqlite, due to obvious other factors like performance...

Nice work! A similar vulnerability in 2019 also found by you included the recommendation to update with:

  apt -o Acquire::http::AllowRedirect=false update
  apt -o Acquire::http::AllowRedirect=false upgrade

Since this also involves redirects, would that protect users while updating apt for this one also?

you can just change the urls to https, apt-transport-https isn't needed anymore, it's builtin to apt now.

Has there ever existed a C or C++ codebase of significant size that hasn't had exploitable memory corruption issues? I don't think we can keep saying it's a question of the dev's passion or skill or whatever, if no dev has ever managed to do it.

That's not to say memory corruption issues are the only kind of issues, and rewriting a mature C/C++ codebase into a memory safe language may well introduce more issues than it fixes...

I did the MOOC recently with Pharo 14, there's some changes in the UI but it's easy enough to follow along. The only thing that changed significantly was the TinyBlog part, with some changes in Seaside and a lot of changes to Bootstrap, but I just asked an llm to update the code examples to the latest version and it worked without too much trouble.

Does Glamorous Toolkit work for you? It's pharo with a different rust based GUI stack, and some batteries included for making custom inspector views and such. I don't have a high DPI display so I'm not completely confident, but my understanding is that their rust based GUI works fine with high DPI.

The one thing I've found google's models to be the best at is proofreading text in non-english languages. Probably because I imagine they have the most training data for it as Google probably has the most complete archive of the internet.

Nice solution with dataclass! And for a complete comparison with the blog you can also use a library to do it for you. It's not quite in the official python distribution but it's maintained by pypa as a dependency of pip so you probably have it installed already.

    >>> from packaging.version import Version
    >>> Version("1.2.3") > Version("1.2.2")
    True
    >>> Version("2.0") > Version("1.2.2")
    True

Wow it looks like you are taking reloading to another level I hadn't even considered.

For example in your elephant:main.py test, in swanky python I run do(3): ['Paint 3 canvasses', 'Sing 3 songs', 'Dance for 3 hours']

change songs to songz, and now do(3) is: ['Paint 3 canvasses', 'Sing 3 songs', 'Dance for 3 hours', 'Sing 3 songz']

Rather than changing the earlier songs to songz as jurigged manages to. But any lisp environment would behave the same, we don't have the idea of:

> 3. When a file is modified, re-parse it into a set of definitions and match them against the original, yielding a set of changes, additions and deletions.

We are just evaling functions or whatever sections of code you say to eval, not parsing files and seeing what was modified. So in some cases we might need to make a separate unregister function and call that on the old one. Like in emacs if you use advice-add (adds before, after, and other kinds of hooks to a function), you can't just change the lines adding an advice and save the file to have it modify the old advice, you need to explicitly call advice-remove to unset the old advice, then advice-add with your new advice, if you want to modify it while running without restarting.

When I eval a function again I am evaling all decorators again, in your readme you write the downsides of that:

> %autoreload will properly re-execute changed decorators, but these decorators will return new objects, so if a module imports an already decorated function, it won't update to the new version.

But I think I am handling that, or maybe you have other cases in mind I am missing? ie in a.py:

  def dec(f):
      def wraps():
          return f() + 2
      return wraps

  @dec
  def reload_me():
      return 1

Then in b.py, from a import reload_me, change reload_me in a and slime-eval-defun it, and b is using the new version of reload_me. Basically for all (__module__, __qualname__) I am storing the function object, and all old versions of the function object. Then when there is a new function object with that name I update the code, closure and other attributes for all the old function objects to be the same as the new one.

I'll look into maybe just integrating jurigged for providing the reloading within swanky python. I was using the ipython autoreload extension at first, but ran into various problems with it so ended up doing something custom still mostly based on ipython, which is working for me in practice for now. So as long as I don't run into problems with it I'll focus on the many other parts of swanky python that need work, but sooner or later when I inevitably run into reloading problems I'll evaluate whether to just switch reloading to use jurigged.

Oooh now that is interesting. What I by mean stuff I don't even know that I don't know :)

Yes mine doesn't handle that, it is the same as jupyter there. Smalltalk is supposed to be best at interactive development, I wonder if it will update the old closures. I don't know it to try, but I do know Common Lisp which is also supposed to be quite good, and fwiw it behaves the same, new closures have the new code, but the old ones are not updated:

  (use-package :serapeum)
  (defun adder (x)
    (flet ((inner (y) (/ x y)))
      #'inner))
  
  (defparameter *adders* (dict))
  
  (defun add (x y)
    (ensure (@ *adders* x) (adder x))
    (funcall (@ *adders* x) y))

  (add 3 6) ; => 1/2
  (add 3 9) ; => 1/3
  ;; change / to + in inner
  (add 4 9) ; => 13
  (add 3 10) ; => 3/10

That question clearly says hard labour. I'm sure some people didn't read it, but I think there also may be another effect there, where when talking to people in person, they realize you are morally opposed to forced hard labour, and don't want to seem like a bad person, so they pretend they didn't know. Sort of similar to the recent effect in the US where trump significantly underpolled as many voted for him but don't want to admit it.