kanaka
Remaining impls to combine eval-ast/macroexpand into eval
Most implementations have been converted via https://github.com/kanaka/mal/pull/592. The following are the remaining implementations to convert:
- [ ] basic
- [x] chuck
- [x] crystal
- [x] fantom
- [x] hy
- [x] io
- [x] janet
- [x] jq
- [x] latex3
- [x] livescript
- [x] lua
- [x] matlab
- [x] objc
- [x] plpgsql
- [ ] plsql (not testable in CI)
- [x] powershell
- [x] purs/purescript (in progress: https://github.com/kanaka/mal/pull/631)
- [x] rexx
- [x] rpython
- [x] rust
- [x] scala
- [x] swift3
- [x] swift4
- [x] swift6 (was swift5)
- [x] vala
- [x] vbs
- [x] wasm
- [x] xslt
- [x] zig (will need to resolve https://github.com/kanaka/mal/pull/591 first)
Swift 2 was originally part of the list but has since been removed from the repo: https://github.com/kanaka/mal/pull/688
What are the remaining issues with awk bbc-basic elixir erlang forth vhdl ? Commit 03389277 was supposed to include them. Also, I suggest to add a commet in the zig line refering to #591.
@asarhaddon You're right, I did a grep for eval_ast and macroexpand and didn't look closely enough at the code or review your commit again when making this list. I've added a comment to zig.
zig problem and eval_ast merge completed here: https://github.com/kanaka/mal/pull/591
I've added a PR to remove Swift 2 ("swift") if the original author doesn't want to get it build/testable in CI: https://github.com/kanaka/mal/pull/688
Swift 2 implementation has now been removed: https://github.com/kanaka/mal/pull/688
Hello.
I would like some help with io and livescript. I have implemented the change locally, but cannot polish/test.
Io has produced no binary compiler for ten years, and some dependencies have changed their Shared Object version meanwhile. The only sensible options seem to rebuild the compiler from a source released in 2017, or to drop this implementation. The error messages are poor, so the current CI is not really an option.
Livescript fails with the current Dockerfile because npm breaks when trying to install ffi-napi. I guess that the same issue affects the js implementation, because node_readline.js is similar with the same dependency on ffi-napi. The issue may be trivial with some knowledge of node.
Could you please take a look, and if possible update the Dockerfile so I can reproduce the steps on a local Debian?
@asarhaddon I got livescript updated (Ubuntu 24.04 and node 18) and switched it to use koffi for the readline/FFI. Most of the JS based implementations use the same node_readine.js code so this should be a reasonable reference for updating the other implementations at some point: https://github.com/kanaka/mal/commit/1ff0671270d31c90bd535da3e9f7df3eb79f6e9a
I'll take a look at the io target (probably be a couple days though). A quick scan of the repo does seem to show that it's mostly dormant since last year. If I can't get something working easily, then I'll do the same as I did with Swift 2 (create a PR deprecating it and gjive the original author an opportunity to support/fix it if they care).
I can look at io's Dockerfile (and then later maybe at merging eval_ast). I understand the publicly downloaded binaries are not working newer Ubuntu. What should we do in this case:
- Clone the C source and build it in our Dockerfile, and then copy the resulting binary interpreter to /usr/bin ?
- Build it somewhere else and publish it (say in my own github repo), and modify the Dockerfile to download from there?
- Other idea?
@dubek Hi! I wasn't going to bother you until I had given in a quick spike. But since you're listening :-D, I would suggest the first option (which is what some implementations already do). The current CI process will build the image once and then cache it to ghcr.io so builds don't take too long. No need to maintain images yourself . You can point to the image if you want others to have quick access to the compiler. Once it's merged, CI will push the image to ghcr.io/kanaka/mal-test-io.
If the io build process or build deps are bulky (I don't think they are particularly for io though), you can always use a multiple stage Dockerfile to build it and then just copy the binaries to the final stage to keep size down if needed. The wasm Dockerfile does that but that's a pretty complicated one so refer to https://docs.docker.com/build/building/multi-stage/ if you're not already familiar with that. But again, you probably won't need this with io. A quick look at the CMakeLists.txt doesn't seem like it will have a lot of deps or be bulky. So let's only attack this if it turns out to be a really big image.
@dubek You may want to start from where I have given up. https://github.com/asarhaddon/mal/commit/37b358a86ce473a2262c6d6110b0d93fa6a21faa
Testing test^io^step0; step file: impls/io/step0_repl.io, test file: tests/step0_repl.mal
Running: env STEP=step0_repl MAL_IMPL=js ../../runtest.py --deferrable --optional --test-timeout 120 --debug-file ../../test-io.debug ../tests/step0_repl.mal -- ../io/run
Exception: OSError(5, 'Input/output error')
Output before exception:
not respond to 'Regex'
---------
Object Regex step0_repl.io 1
More related rpython (with performance optimizations too): https://github.com/kanaka/mal/pull/698
swift6 completed: https://github.com/kanaka/mal/pull/693 (and reversioned from swift5 to swift6)