Thanks for telling me
@DennisMitchell Thank you.
Did you have problems running phase0 or did you try to build latest Pyret version?
Looks like machine with a lot of RAM is needed to build it (
Compiler flags are in src/arr/compiler/pyret.arr,
Did you have problems running phase0 or did you try to build latest Pyret version?
Looks like machine with a lot of RAM is needed to build it (
-max-old-space-size in Makefile is 8GB).Compiler flags are in src/arr/compiler/pyret.arr,
-compiled-dir is useful for the wrapper not to write to /opt/pyret/compiled/ (I didn't try it myself).
@stasoid I was able to build phaseA and phaseB just fine; TIO's 2 GiB of RAM and 4 GiB of zram seem to be sufficient. phaseC didn't build, but not because of lack of RAM.
While it worked most of time, it sometimes failed to run for no apparent reason. I got stuck on that and didn't even try to make it work in the sandbox...
While it worked most of time, it sometimes failed to run for no apparent reason. I got stuck on that and didn't even try to make it work in the sandbox...
@Helen0903 Pulled.
Saved me a lot of confusion later on
It's released
@DennisMitchell Can we change DOBELA implementation to this one? Old asm interpreter doesn't follow the spec
in some cases, which has bitten me once already. I believe new implementation is better in many respects, including maintainability, following the spec and
handling many corner cases which dobelx64 doesn't. Currently DOBELA answers exist only in Hello World and Add a language to a polyglot threads.
Changing the interpreter will break several old polyglot answers (207-210, all of them are mine) and the program provided in the comments of Hello World answer.
All these breakages are due to dobelx64 not following the spec. If this is a problem I can fix all those answers for new interpreter, but I see no point in doing this.
If that is fine, I'll write a pull request.
in some cases, which has bitten me once already. I believe new implementation is better in many respects, including maintainability, following the spec and
handling many corner cases which dobelx64 doesn't. Currently DOBELA answers exist only in Hello World and Add a language to a polyglot threads.
Changing the interpreter will break several old polyglot answers (207-210, all of them are mine) and the program provided in the comments of Hello World answer.
All these breakages are due to dobelx64 not following the spec. If this is a problem I can fix all those answers for new interpreter, but I see no point in doing this.
If that is fine, I'll write a pull request.
This example does not typecheck due to old compiler impl
@ice1000 I'll have to update to Fedora 30 to update Agda (so it will take a while), but even Fedora 30 is still on Agda 2.5.4. When was Adga 2.6 released?
@DennisMitchell No, dobelx64 behaves strangely due to bug(s?), not because it deliberately deviates from spec. The author of dobelx64 is actually the one who wrote the spec.
Now that I think of it, dobelx64 has some value of being a "classical" implementation, so it's better to keep it. I will write a PR today or tomorrow.
Now that I think of it, dobelx64 has some value of being a "classical" implementation, so it's better to keep it. I will write a PR today or tomorrow.
Suggestion for a programming language: the esolang UBFIM (https://esolangs.org/wiki/Ultimate_bf_instruction_minimalization!). The only current interpreter there is is one wrote in Basic (https://esolangs.org/wiki/UBFIM_interpreter) so it'd be useful to have it on here
(if you want to add it, friend me on Discord (i'm more active there, and probably won't get notifs here), my tag is
RailRunner16#7053)
i can send you a link @DennisMitchell (if you want)
