I've run into many of the problems mentioned with Apple Feedback and gave up on using them many years ago. It's pretty disheartening when you spend a bunch of time getting an OS crashing bug to reproduce in a small amount of code to submit in a bug report for them to neither confirm that they can repeat it, or consider it worth fixing.
If you want to use stable diffusion t2i and i2i today via an self-hosted api it's very easy to do so with auto1111, just click the api link at the bottom of the gradio app and there's extensive documentation on the endpoints.
I think it can only use other APIs itself. Looks like they want to make it work with a1111's api and they will ship a plugin that talks to stability's pay api.
Covers the right sort of thing. It makes a guess at what a function call will be, inlined that guess, and if it turned out to be wrong restarts from the start of the function in the interpreter. Doesn't explicitly call out the function calling convention but guarded inlining has much the same effect.
Maybe worth noting that inlining a fexpr is semantically very close to expanding a macro. Identical if symbol renaming is done the same way for each.
Think of it like how the expectation for apps is that there'll be a screenshot (or video!) on the homepage of the app doing its job — i.e. of the user experience of the app.
The first thing you should shove in my face, when I land on the home page of a programming language, is the user experience of writing code in the language. Which is to say: the syntax.
But also, if your language has a REPL, or an IDE, or a weird graphical virtual machine like Smalltalk, then that's part of the language's UX as well — so show that too! (And if you can, integrate the two together. Show me a cohesive example of what the syntax looks like inside the REPL/IDE.)
Everybody else (Rust, PHP, Java, Lua, etc.) gets an eyebrow raised in suspicion, because their home-pages feel like they're ashamed of what their syntax looks like :)
That might be contentious. I don't care at all what the syntax is, I want to know what choices have been made in the language design space, and if they look reasonable/interesting, how sound the implementation looks. The top level about link followed by source was ideal for that. Only after sanity checking the implementation source would I look for some example of what the language looks like.
On the other hand, language A but looks like language B is definitely a thing and I suppose those should put syntax front and center as it's their selling point.
I'm pretty sure, if the user experience of coding in a language is bad enough, that you wouldn't use said language, no matter how interesting it is design-wise. There's a threshold below which most programmers would rather reimplement the cool design features in a different language with better syntax than use the original language.
Does anyone write in APL? No; it's basically impossible, given the syntax requires characters that aren't on your keyboard. But maybe you write in J. Or, more likely, you use a vector-operations/dataframe library in some arbitrary language.
Do people write in Erlang? Well, some do; but many others think that connecting expressions with semicolons and commas is too painful to want to deal with (though not me; I enjoy "systems Prolog.") And some of those people got together to design Elixir, so they could use the Erlang runtime without having to write Erlang.
Does anyone voluntarily pick up IBM JCL these days? Or COBOL? RPG? MUMPS? These archaic 1970s languages all have interesting design choices — heck, MUMPS assumes a database as part of the language runtime! — but they're just too awful to actually write in. It's far easier to just read about these languages as historical artefacts, and then implement their good ideas into a new language, than to actually use them.
Does anyone use FORTRAN? Well, yes, if they have to, to extend OpenBLAS with something. But mostly as little as possible. And there are fewer reasons to do so these days, with e.g. cuBLAS not being written in FORTRAN.
You put a syntax example on the home-page not to impress people with how cool your language looks; but rather, to show that you're not trying to bait-and-switch a prospective developer, by talking them into using a language by describing its cool features, only to reveal at the last moment that the syntax is awful.
I think this is pretty close to Smalltalk from before classes were added. Is that basically right? Syntax looks simpler and there's the same slightly off-putting "macros aren't necessary because our syntax is flexible" sentiment.
Thanks! The inheritance model is definitely from Self. I'm having some trouble finding the compiler/jit infra in the github repo, would be really interested to see if you've gone down the same dynamic optimisation path Self did
The environment I grew up in (NeXTstep with Miller Column FileBrowser + Edit + InterfaceBuilder) effectively did, but I'd love to see them tightly integrated.
Economics is more complicated that a short term price move.
If there is sufficient unpayable dollar denominated debt, the central banks and governments will be forced to once again print trillions to re-inflate the debt bubble, incentivizing exponentially more bad debt. How do you suppose this process ends?
Where would the weak array be stored? Ephemerons are often used when you can't attach data directly to either the key object or the value object. It's the simplest efficient primitive that lets you encode "if object A is reachable, object B also is" without otherwise affecting the visibility of A (or B), altering A, or needing multiple GC cycles to settle.
Except that the implementation described in the post does use multiple GC cycles to settle if I read it correctly. It will only be an issue if you have reference cycles through ephemeron edges, though, like a key associated with a value that is itself or refers to an otherwise-dead WeakMap which contains a key associated with... etc.
Multiple cycles are not fundamental to ephemeron collection, though. If you keep all of your unmarked keys (specifically, keys of ephemeron tables that have been marked) in a lookup table, then in theory every time you mark anything you could look it up in that table to see if you need to traverse an ephemeron edge. In practice, you probably don't want to do those lookups until you've traversed the "easy" part of the heap that doesn't require traversing ephemerons to get to.
On the instance. My understanding is that in this example, the instance itself is the key and is only stored in a dictionary owned by the related class. Maybe there are other or broader use cases, but for this particular case, storing dependents on the instance seems to (AFAICS) solve the problem without adding complexity.
Agreed. If the dictionary is owned by the related class, and classes aren't collected themselves, then there's no point in using an ephemeron table. From a GC perspective, an ephemeron table entry can be seen as a tuple <M, K, V> where V is alive if both M and K are alive. Sort of a strong edge to V from the conjunction of M and K. (A regular strong edge is a tuple <K, V> where V is alive if K is alive.) So if the ephemeron table M is known to be alive, then it collapses down to a regular strong edge, the simplest forms of which are plain properties or dictionaries mapping Ks to Vs.
I have to admit, given the obviousness of that solution, I decided that they must have some constraint we don't know preventing it. I don't know why they didn't use it here. The broader design and use-cases have been better described by sfink in these threads.
