I just tried asking ChatGPT on how to "force PhotoSync to not upload images to a B2 bucket that are already uploaded previously", and all it could do is hallucinate options that don't exist and webpages that are irrelevant. This is with the latest model and all the reasoning and researching applied, and across multiple messages in multiple chats. So no, hallucination is still a huge problem.
Thank you so very much. This is the first time monads have made sense to me, and now its clear why. People who try to explain them usually end up adding all kinds of Haskell minutia (the top post is another example), rather than actually explain the concept and why we need it. Your comment is the first time I actually understand what it is, and why it might be useful.
More specifically, Lua allows you to inject your own memory allocator function, so one can get Lua to use a real-time allocator like TLSF operating out of a fixed memory block in such contexts.
The key idea here seems to be to use function pointer's type to enforce type safety rather than using the data "handle" type (that is often found in implementations inspired by Sean Barrett's strechy_buffers).
> One annoying thing about C is that it does not consider these two variables to have the same type
Author here. Not quite. The key idea is about using a union to associate type information with a generic data type. Type casting a function is not the only way to use that type information. I discuss that as well as the C23 changes in the footnotes and the "typeof on old compilers" section.
FWIW, as far back as 2015 my feature check library documents Visual Studio as supporting "__typeof".[1] Note the leading but not trailing underscores. Perhaps I was mistaken, but I usually tested that sort of thing. It's also possible __typeof had slightly different semantics.
msvc 19.39 is the first to support it, which I mention in the article. You can confirm it didn't work up through 19.38 in godbolt [1]. I don't use Visual Studio, so I don't know what version of that first started using msvc 19.39
Playing with MSVC's typeof, I've just discovered that its docs [1] have an example that has never worked with any released version of MSVC... MSVC doesn't support `typeof` applied on function types and function pointers! (bug report [2] [3]). Is there anyone from the compiler team around here? :)
So somehow I had the impression Visual Studio .NET 2003 (7.1)[1] added __typeof. I'm still holding out hope someone will come to my rescue and reply that once upon a time MSVC had __typeof, but removed it. But for now it seems past me is gaslighting present me.
EDIT: Ah ha! It seems Microsoft did support __typeof, but perhaps only for "managed" C++ (aka C++ .NET)?
> One thing to watch out for when using the __typeof operator in managed C++ is that __typeof(wchar_t) can return different values depending on the compilation options.
Will this create more nasal demons? I always disable strict aliasing, and it's not clear to me after reading the whole article whether provenance is about making sane code illegal, or making previously illegal sane code legal.
All C compilers have some notion of pointer provenance embedded in them, and this is true going back decades.
The problem is that the documented definitions of pointer provenance (which generally amount to "you must somehow have a data dependency from the original object definition (e.g., malloc)") aren't really upheld by the optimizer, and the effective definition of the optimizer is generally internally inconsistent because people don't think about side effects of pointer-to-integer conversion. The one-past-the-end pointer being equal (but of different provenance) to a different object is a particular vexatious case.
The definition given in TS6010 is generally the closest you'll get to a formal description of the behavior that optimizers are already generally following, except for cases that are clearly agreed to be bugs. The biggest problem is that it makes pointer-to-int an operation with side effects that need to be preserved, and compilers today generally fail to preserve those side effects (especially when pointer-to-int conversion happens more as an implicit operation).
The practical effect of provenance--that you can't magic a pointer to an object out of thin air--has always been true. This is largely trying to clarify what it means to actually magic a pointer out of thin air; it's not a perfect answer, but it's the best answer anyone's come up with to date.
It's standardizing the contract between the programmer and the compiler.
Previously a lot of C code was non-portable because it relied on behaviour that wasn't defined as part of the standard. If you compiled it with the wrong compiler or the wrong flags you might get miscompilations.
The provenance memory model draws a line in the sand and says "all C code on this side of the line should behave in this well defined way". Any optimizations implemented by compiler authors which would miscompile code on that side of the line would need to be disabled.
Assuming the authors of the model have done a good job, the impact on compiler optimizations should be minimized whilst making as much existing C code fall on the "right" side of the line as possible.
For new C code it provides programmers a way to write useful code that is also portable, since we now have a line that we can all hopefully agree on.
This is basically a formalization of the general understanding one already had when reading the C standard thoroughly 25 years ago. At least I was nodding along throughout the article. It cleans up the parts where the standard was too imprecise and handwavy.
Sure! Just compile with nim c --lineDir=on or drop `lineDir=on` in your $HOME/.config/nim/nim.cfg (or per project NimScript .nims or per file foo.nim.cfg or ...) and source-level debugging with gdb on Linux works..
mostly at the level of Nim source, although various things are likely to "leak through" like mangled names (though in fairness, lower-level assembly notions leak through in "C source level" debugging...).
Beware, though, that since around Spring 2024 this can make the tinycc/tcc backend infinite loop (but otherwise tcc can be a nice way to get fast development iteration).
Also recently Nim’s generated C code started using Itanium name mangling, which oddly has become the defacto name mangling method for C++ on Linux and other platforms.
Meaning you get pretty function names with generic types and all included with debuggers that support it. Works better with ldb as gdb seems to refuse to recognize it.
Is WASM a good target for REPL-driven programming? I haven't studied it in detail, but I do remember that it was Harvard architecture. Would that mean that code can't be updated at runtime in real implementations?
I'd use the analogy of current dynamic language VMs being written C. You're not modifying structs at runtime or creating C functions as a user of the dynamic language. But the creators of the VM are providing as thin a layer as possible on top of that to give the runtime behavior it's dynamism.
There's an often repeated line that WebAssembly isn't really "assembly" and it's not "web". There's a lot of truth to that. I dove in hoping for a cross platform, web enabled assembly. It looks a lot like an assembly but I find it's relatively few restrictions like lack of a true jump command rippling out more than one would have expected. It's also sortuva stack machine and sortuva register machine at the same time.
It does share a lot with the internal VMs in many places like the JVM, Python's VM, .net, etc.
ECL features native code and bytecodes vm for targets without incremental compilation support - both native and bytecode can be freely mixed at runtime.
That means that you may interactively use repl to call functions that were compiled ahead of time and to add new functions even on uncooperative targets.
After you've finished prototyping you may compile the finished library to native ahead of time.
It is, actually! I didn’t realize that until I read the handwritten WASM s-expression source code of WAForth.
Languages like Lisp or Forth that run on WASM — or even handwritten s-expression-style WASM code like in the WAForth kernel — can dynamically compile and assemble new WASM bytecode and data. They can then call back to the JavaScript host to create and link entirely new WASM modules on the fly, and immediately call into them from the current module or others. A single WASM context can juggle many dynamic modules, large and small, all generated and linked at runtime!
So you can compile new code in Forth or Lisp and immediately link and call it using indirect cross-module calls. It’s not the fastest way to call into WASM, but a metacompiler — like Mitch Bradley’s ForthMacs / OpenFirmware — could recompile the whole system into one efficient, monolithic WASM module that uses direct calls.
Reading the source code of "WAForth" (Forth for WebAssembly) really helped me learn about how WebAssembly works deep down, from the ground up.
It demonstrates the first step of what the article says about bootstrapping a Forth system, and it has some beautiful hand written WebAssembly code implementing the primitives and even the compiler and JavaScript interop plumbing. We discussed the possibility of developing a metacompiler in the reddit discussion.
I posted this stuff about WAForth and a link to a reddit discussion with its author in the hn discussion of "Ten influential programming languages (2020)":
It's a lovingly crafted and hand written in well commented WebAssembly code, using Racket as a WebAssembly macro pre-processor.
I learned so much about WebAssembly by reading this and the supporting JavaScript plumbing.
The amazing thing is that the FORTH compiler dynamically compiles FORTH words into WebAssembly byte codes, and creates lots of tiny little WebAssembly modules dynamically that can call each other, by calling back to JavaScript to dynamically create and link modules, which it links together in the same memory and symbol address space on the fly! A real eye opener to me that it was possible to do that kind of stuff with dynamically generated WebAssembly code! It has many exciting and useful applications in other languages than FORTH, too.
Lots more discussion and links in the reddit article.
If you can't be bothered to install VS Code, you can have a look at a standalone version of the example notebook (in a 26kB self-contained page).
And if you're planning to go to FOSDEM 2023, come say hi: I'll be giving a talk there on WebAssembly and Forth in the Declarative and Minimalistic Computing devroom.
DonHopkins:
I really love your tour-de-force design and implementation of WAForth, and I have learned a lot about WebAssembly by reading it. Never before have I seen such beautiful meticulously hand written and commented WebAssembly code.
Especially the compiler and runtime plumbing you've implemented that dynamically assembles bytecode and creates WebAssembly modules for every FORTH word definition, by calling back to JavaScript code that pulls the binary bytecode of compiled FORTH words out of memory and creates a new module with it pointing to the same function table and memory.
WebAssembly is a well designed open standard that's taking over the world in a good way, and it also runs efficiently not just in most browsers and mobile smartphones and pads, but also on the desktop, servers, cloud edge nodes, and embedded devices. And those are perfect target environments for FORTH!
What you've done with FORTH and WebAssembly is original, brilliant, audacious, and eye-opening!
I'd read the WebAssembly spec before, and used and studied the Unity3D WebAssembly runtime and compiler to integrate Unity3D with JavaScript, and I also studied the AssemblyScript subset of TypeScript targeting WebAssembly and its runtime, and also Aaron Turner's awesome wasmboy WebAssembly GameBoy emulator .
I first saw your project a few years ago and linked to it in this Hacker News discussion about Thoughts on Forth Programming because I thought it was cool, but it's come a long way in three years, and I'm glad I finally took the time to read some of your code, which was well worth the investment of time.
Until reading your code, I didn't grasp that it was possible to integrate WebAssembly with JavaScript like that, and use it to dynamically generate code the way you have!
Also, the way you used Racket as a macro assembler for WebAssembly was a practical and beautiful solution to the difficult problem of writing maintainable WebAssembly code by hand.
Even for people not planning on using FORTH, WAForth is an enlightening and useful example for learning about WebAssembly and its runtime, and a solid proof of concept that it's possible to dynamically generate and run WebAssembly code on the fly, and integrate a whole bunch of tiny little WebAssembly modules together.
Playing with and reading through your well commented code has really helped me understand WebAssembly and TypeScript and the surface between them at a much deeper level. Thank you for implementing and sharing it, and continuing to improve it too!
remco:
Wow, thanks a lot, I really appreciate that! It makes me very happy that I was able to get someone to learn something about WebAssembly by reading the source code, which is exactly what I was going for.
[More links and discussion of WAForth, WebAssembly, and Forth Metacompilers:]
DonHopkins on Jan 13, 2023 | parent | context | favorite | on: What the hell is Forth? (2019)
This is a great article! I love his description of Forth as "a weird backwards lisp with no parentheses".
Reading the source code of "WAForth" (Forth for WebAssembly) really helped me learn about how WebAssembly works deep down, from the ground up.
It demonstrates the first step of what the article says about bootstrapping a Forth system, and it has some beautiful hand written WebAssembly code implementing the primitives and even the compiler and JavaScript interop plumbing. We discussed the possibility of developing a metacompiler in the reddit discussion.
I posted this stuff about WAForth and a link to a reddit discussion with its author in the hn discussion of "Ten influential programming languages (2020)":
It's a lovingly crafted and hand written in well commented WebAssembly code, using Racket as a WebAssembly macro pre-processor.
I learned so much about WebAssembly by reading this and the supporting JavaScript plumbing.
The amazing thing is that the FORTH compiler dynamically compiles FORTH words into WebAssembly byte codes, and creates lots of tiny little WebAssembly modules dynamically that can call each other, by calling back to JavaScript to dynamically create and link modules, which it links together in the same memory and symbol address space on the fly! A real eye opener to me that it was possible to do that kind of stuff with dynamically generated WebAssembly code! It has many exciting and useful applications in other languages than FORTH, too.
Lots more discussion and links in the reddit article.
If you can't be bothered to install VS Code, you can have a look at a standalone version of the example notebook (in a 26kB self-contained page).
And if you're planning to go to FOSDEM 2023, come say hi: I'll be giving a talk there on WebAssembly and Forth in the Declarative and Minimalistic Computing devroom.
DonHopkins:
I really love your tour-de-force design and implementation of WAForth, and I have learned a lot about WebAssembly by reading it. Never before have I seen such beautiful meticulously hand written and commented WebAssembly code.
Especially the compiler and runtime plumbing you've implemented that dynamically assembles bytecode and creates WebAssembly modules for every FORTH word definition, by calling back to JavaScript code that pulls the binary bytecode of compiled FORTH words out of memory and creates a new module with it pointing to the same function table and memory.
WebAssembly is a well designed open standard that's taking over the world in a good way, and it also runs efficiently not just in most browsers and mobile smartphones and pads, but also on the desktop, servers, cloud edge nodes, and embedded devices. And those are perfect target environments for FORTH!
What you've done with FORTH and WebAssembly is original, brilliant, audacious, and eye-opening!
I'd read the WebAssembly spec before, and used and studied the Unity3D WebAssembly runtime and compiler to integrate Unity3D with JavaScript, and I also studied the AssemblyScript subset of TypeScript targeting WebAssembly and its runtime, and also Aaron Turner's awesome wasmboy WebAssembly GameBoy emulator .
I first saw your project a few years ago and linked to it in this Hacker News discussion about Thoughts on Forth Programming because I thought it was cool, but it's come a long way in three years, and I'm glad I finally took the time to read some of your code, which was well worth the investment of time.
Until reading your code, I didn't grasp that it was possible to integrate WebAssembly with JavaScript like that, and use it to dynamically generate code the way you have!
Also, the way you used Racket as a macro assembler for WebAssembly was a practical and beautiful solution to the difficult problem of writing maintainable WebAssembly code by hand.
Even for people not planning on using FORTH, WAForth is an enlightening and useful example for learning about WebAssembly and its runtime, and a solid proof of concept that it's possible to dynamically generate and run WebAssembly code on the fly, and integrate a whole bunch of tiny little WebAssembly modules together.
Playing with and reading through your well commented code has really helped me understand WebAssembly and TypeScript and the surface between them at a much deeper level. Thank you for implementing and sharing it, and continuing to improve it too!
remco:
Wow, thanks a lot, I really appreciate that! It makes me very happy that I was able to get someone to learn something about WebAssembly by reading the source code, which is exactly what I was going for.
[More links and discussion of WAForth, WebAssembly, and Forth Metacompilers:]
>Yes, I agree FORTH should be probably be on the list, at least if the list was a few languages longer, for as influential as it's been.
Forth has not been influential, at all. If it was your first or second encounter with computers, it might have been influential on you, which is a great thing for you, but it was not influential on the industry.
the late 70's-early 80's was the beginning of the microprocessor era. This opened the door to computers for people who would be interested in computers but had no access prior. But the "leading" people in computer science at that time were the people who did already have access to computers. This created a bifurcation between the people who were, say, pursuing lisp since 1960 because of what they had learned about lambda calculus before, and people pursuing Forth who had never heard of Lisp, but had heard of Pascal but didn't realize that UCSD Pascal was a p-code stack machine just like Forth was; if they had realized it there might have been overlap, there wasn't. Programmable HP calculators were already more advanced since the HP-65
(please don't nitpick me, if you remember that time, you know what i'm talking about.) The much revered Dr Dobbs and Byte magazine were not on the reading list of people who were at MIT or Carnegie or Stanford. If you graduated at that time (hint hint) you had this choice of working at a place like Microsoft (DOShit in the boonies) or Apple (8-bit 6502 nonsense on an OS nobody remembers) or at DEC or HP or Xerox or BBN, companies pursuing excellence based on the already-history of CS.
because microprocessor "ate the world", the early history of microprocessors seems "important": it wasn't, except for what it became
when Apple and Microsoft borrowed ideas from Xerox PARC to create MacOs and Microsoft Windows, they were borrowing from programmable microcode architectures which are still more interesting than amd64
The answer was, of course, number two! (cut to stock film of Women's Institute applauding) I'm afraid there's been an error in our computer. The correct answer should of course have been number four, and not Katy Boyle. Katy Boyle is not a loony, she is a television personality. (fanfare as for historical pageant; a historical-looking shield comes up on screen) And now it's time for 'Spot the Loony, historical adaptation'. (historical music) And this time it's the thrilling medieval romance 'Ivanoe'... a stirring story of love and war, violence and chivalry, set midst the pageantry and splendour of thirteenth-century England. All you have to do is, 'Spot the Loony'.
And now a word from our sponsors, Looney Labs, makers of fine card games whose rules and conditions for winning change throughout the game, including the most popular among machine learning AI enthusiasts, Python FLUXX, the first set to have the Meta Rule subtype card, which stemmed from a FLUXX Tournament rule:
>Yes, that crazy card game where the rules keep changing has joined forces with Monty Python to create the Looneyest card game ever! Help King Arthur and his Knights find the Holy Grail. Bring a Shrubbery to the Knights Who Say Ni! Lob the Holy Hand Grenade at the Killer Rabbit with Nasty Big Teeth! Just do it quick, before the Goal changes again!
>Doctor Who Fluxx takes Fluxx through Time And Relative Dimension In Space. Join with various regenerations of the Doctor, some companions, Gallifreyan tech, and K-9 (but beware of Cybermen, Daleks, Weeping Angels, and the Master) and play the most ever-changingest, timey-wimey version of Fluxx ever created. Doctor Who Fluxx: you'll play it time after time after time after time...
>Put on some good music and line up some snacks... Stoner Fluxx is a game about toking with your friends, getting the munchies, and changing the rules.
>Our country seems to be moving closer to finally legalizing marijuana at the national level, so we have completely removed the warning messages on the cards instead of only adjusting them a bit like we have with each print run in the past.
>Looney Labs was founded in 1997 by two former NASA engineers named Looney. The husband and wife team have been creating fun ever since, with Andy inventing the games, and Kristin running the company. Along with the help of four other full-time employees, several part-timers, and an army of fans, the Looneys are changing the way you play!
>Fluxx is a card game published by Looney Labs. It is different from most other card games, in that the rules and the conditions for winning are altered throughout the game, via cards played by the players.
Modern WASM implementations use JIT compilation with dynamic code generation capabilities that effectively bypass the Harvard architecture limitations, allowing for runtime code updates through module instantiation and function replacement.
reply