[00:52:39] I'd also be delighted to tweak the final paragraph if the reader function is connected by then. (re @vrandecic: Thank you! That looks great to me. I'm happy to pull it in this week, unless there's some process I should be waiting for) [01:29:54] Z21925 Z21642 [02:15:10] Omggg cool!!! Thanks for making that! :) (re @Feeglgeef: First Lua implementation: Z21924) [02:15:22] I wonder what other languages we should support? [02:16:04] I saw something recently that clang (and clang++) can compile itself to wasm, and then be used with wasm to generate wasm from C/C++ files [02:18:04] Also as WasmGC is becoming more widespread perhaps for js/python (I know there's already a working python to WasmGC compiler) instead of using a systems language based interpreter compiled to wasm non-gc we should just compile these files straight to WasmGC [02:18:53] Perhaps both for the interim to provide a fallback? I'm not really sure, just brainstorming here [02:38:53] Oooh just found this: https://docs.r-wasm.org/webr/latest/ [02:39:08] R would be HUGE is getting more adoption from scientists [02:58:02] For rationals, Z21930 now calls Z19866 for all languages, so can be added as the reader function. (re @u99of9: I'd also be delighted to tweak the final paragraph if the reader function is connected by then. Because they need language param...) [03:47:52] R is in 14th by popularity. Something like Go, C, or Java would be better choices (re @MolecularPilot: R would be HUGE is getting more adoption from scientists) [08:10:08] Stated by TIOBE? (re @Feeglgeef: R is in 14th by popularity. Something like Go, C, or Java would be better choices) [08:46:41] In science, it's 1st, probably then followed by python at 2nd. Though not all users are scientists is something to consider, but using Wikifunctions for scientific purposes is potentially a major usecase. There's definitely a lot to way up in deciding the next language I think, but yes JVM support would be huge (re @Feeglgeef: R is in 14th by popularity. [08:46:41] Something like Go, C, or [08:46:42] Java would be better choices) [08:47:43] Oooh found this for potential JVM support: https://labs.leaningtech.com/blog/cheerpj-3.0 [08:48:12] I think JVM support would be good because it's not just java, but you also add support for kotlin, scala and the other JVM languages [08:50:02] Thanks for suggesting it! :) [08:50:36] I might try to code new support for another language into wikilamda tomorrow, I've been looking for something to do while I wait for my media wiki core patch to be reviewed [08:51:18] (I've been working a lot on that patch recently, that's why I been a bit less active on Wikifunctions, sorry!) [09:21:21] what does your wiki core patch do? [13:08:38] Is there also a display function I can connect? (re @u99of9: I'd also be delighted to tweak the final paragraph if the reader function is connected by then. Because they need language param...) [13:09:10] I am happy to connect display and read functions for both float and rational, just trying to make sure I get the right ones. [21:39:50] Sure, it's number one in science, but our priority should not be something that's popular in one group but nowhere else. JavaScript, Python, Lua, and Go are good choices because they are very very multi-purpose. (re @MolecularPilot: In science, it's 1st, probably then followed by python at 2nd. Though not all users are scientists is something to consider, but...) [21:43:24] "JVM" isn't a language and I don't see that working out well (re @MolecularPilot: I think JVM support would be good because it's not just java, but you also add support for kotlin, scala and the other JVM langu...) [21:45:32] I think for each Z60 we should have one implementation of that programming languages. If the executor randomly picked between CPython and RustPython some bugs would be really annoying to figure out [21:46:05] Z61* [21:46:15] /delete@wikilinksbot [22:19:01] Here's one for float64. For all languages it's currently using the vanilla python str(), which I want to sometime tweak to distinguish between nan/snan/qnan. We could also consider making it look fancier when it uses exponential notation, or if we want to show a minus symbol instead of an apostrophe. But I think it's ready to put in place as a simple first pass. [22:19:01] Z21956 (re @vrand [22:19:02] ecic: I am happy to connect display and read functions for both float and rational, just trying to make sure I get the right ones.) [22:19:47] I'll pull one together for rationals. [23:26:23] Here's Z21971. If any language wants to set up a custom display, feel free to set up a configuration by language. Choices I made in this generic: (1) It displays with a full minus sign instead of a hyphen. Looks better but harder to reuse. (2) It displays unsimplified (so has no connected code implementations) - if returning from a function, this won't show any [23:26:23] difference, but fo [23:26:24] r tests involving unsimplified fractions, it helps to see what they really are. [23:41:44] I wouldn't use a configuration for less than 5 options, just hardcoding would be better. (re @u99of9: Here's Z21971. If any language wants to set up a custom display, feel free to set up a configuration by language. Choices I made...) [23:43:46] Yes, there's a tipping point in there somewhere. Hopefully we eventually reach more than 5 options when non-Arabic scripts have custom displays. (re @Feeglgeef: I wouldn't use a configuration for less than 5 options, just hardcoding would be better.) [23:45:05] Scripts without Arabic numbers* (re @u99of9: Yes, there's a tipping point in there somewhere. Hopefully we eventually reach more than 5 options when non-Arabic scripts have ...)