Fix GC collecting active fiber during nested janet_continue
If GC triggers inside the inner fiber's execution, the inner fiber is not in any GC root set and can be collected, including its stack memory, while actively running.
It's always a little reassuring when I discover I'm not the only person being plagued by this sort of issue. During recent code reviews, I discovered an eerily similar problem where I couldn't nest import calls because doing that would hide virtual machine instances from the GC.
Note that a lot of the nice libraries that used to be separate are now part of the spork library collection, e.g. https://janet-lang.org/spork/api/sh-dsl.html instead of the sh library the older Janet book recommends in https://janet.guide/scripting/. There's also a spork version of the cmd library that chapter recommends (forget the exact name).
(Oh, you should look at https://janet.guide/ if you haven't yet, just remember that some library references are out of date, and the newer versions have slightly different APIs. Asking an AI might be a good way to sort it out)
For packaging, they are also trying to migrate from jpm to janet-pm that's also a part of spork, https://janet-lang.org/spork/api/pm.html. It's woefully under-documented, but fortunately spork now has most of the stuff I was interested in. Installing spork itself is documented in https://github.com/janet-lang/spork#installation. Installing spork is also a prerequisite for using the new package manager :).
janet-pm can perfectly use jpm stuff, but is meant to implement 90% of obvious stuff, so you can build your own package manager on top of! So we have e.g. https://github.com/pyrmont/jeep/ and others which work on bundles and jpm stuff.
Sogaiu is working on documentation for it. I also wrote: https://janetdocs.org/tutorials/packaging a while ago, but am making a new guide now that I understand much more.
libraries ... now part of spork
We may adopt more into spork, but there hasn't been much need yet. E.g. joy (or at least halo2) for web stuff, but it still works as is. Also, spork creates a bit more permanence, so I quite like the idea of spork just exposing more battle-tested APIs we're confident about. Stuff like https://github.com/LeviSchuck/janetls needs more immediate attention, probably.
I really like Janet. I think it was the first programming language I encountered where there was basically no distinction (in code) between compile time and run time. Just put your code in a global and it runs at compile time without needing any further changes.
If I'm remembering right (it's been a bit) that's exactly what they do with their boot.janet as well. The whole thing is structured so that the bare minimum of environment setup is done in C, just enough to hand it off to boot.janet which handles the rest of it. Boot.janet itself gets pre-compiled at build time so that it doesn't need any parsing at runtime, just start executing the pre-baked VM ops.
That's the feature that made me fall for Janet! The 2nd half of this comment is all about it/the convoluted ways I'd tried to do it in languages before: https://lobste.rs/s/y0euno/why_janet_2023#c_imjhgs
I've been doing some Janet programming for single-user projects at work, as I'm a big Ian Henry fan and have been wanting to learn a Lisp for a while. I previously bounced off several due to what seem to me to be obtuse installation processes—Janet is a nice single binary.
I've had a lot of fun with it! In particular, PEGs are super awesome.
However, it must be said that the documentation is the worst I've ever seen across any language ecosystem. I've been making my way through with a combination of Janet for Mortals, the official website, and JanetDocs but it is a slog. I'm constantly learning about more idiomatic ways of doing things that are written down in only one random place, or running into version issues, etc. Also I wish there was an LSP but that's a whole other can of worms.
In any case, with that rant out of the way, I'm going to get back to programming in Janet. Until I switch to Steel or Clojure, maybe.
Do you have any examples? They shouldn't really come up. Maybe we can squash some misleading stuff. A few of us are working on the documentation, but it's a slog. Generally speaking, any concrete complains, examples of your struggles etc. would be really helpful as we don't have people to do user tests with.
Hah! Feeling silly about the LSP comment, as I clicked on that link and it was already in my history. Wonder why I didn't get it up and running. I use Helix.
On the version issues, I'm having some right now actually. I found a bug in a PEG I wrote, so I tweaked it and have attempted to recompile. I also updated Janet via brew today. Now, when I run jpm build, I see:
/opt/homebrew/lib/janet/jpm/commands.janet:168:1: compile warning (normal): binding rule is shadowing a macro
generating executable c source build/slurp-to-edi.c from init.janet...
error: could not load native /opt/homebrew/lib/janet/spork/json.so: config mismatch - host 1.42.0(0001) vs. module 1.41.2(0000) - native needs to be recompiled!
error: build fail
in pdag [/opt/homebrew/lib/janet/jpm/dagbuild.janet] (tail call) on line 79, column 23
in run-main [boot.janet] on line 4949, column 16
in cli-main [boot.janet] on line 5183, column 17
The first line is in orange and is annoying but doesn't appear to break anything. I am running jpm update-installed in order to try and get Spork recompiled (which seems to me should just happen automatically, but fine) and it fails while trying to update jpm.jdn, after updating Spork. Still doesn't build. Running the file via janet directly fails with the same error.
Fixed it by running:
$ janet --uninstall spork
$ jpm deps
This is a rather fragmented way of solving an issue that simply doesn't exist in other programming languages (like Go, Rust, or Gleam). It's fine, because I hold Janet to a different standard than those much larger and institutionally supported languages (except Gleam), and still think it's fun. But package management is definitely the least fun part.
Compiler warnings got added earlier this year, mostly for shadowing and macro hygiene stuff. Some more details here: https://janetdocs.org/tutorials/misc#binding-metadata (IIRC giving :shadow or something as function metadata also silences it.)
All of this of course... Is a perfect example of the "more idiomatic ways of doing things that are written down in only one random place".
Also, for the record, I appreciate that documentation is a slog and that a random person complaining on the internet can be frustrating. So: I really like Janet! It's been an incredible introduction to a whole new side of programming that I've never encountered before! JanetDocs in particular is a really wonderful source in getting me up and running! Thank you for all you do.
I think those refer to documentation improvements, not syntax changes. (See here.)
In general, though, I defend trying to write commit messages suitable for generating release notes. But perhaps this is an example of that not being a great idea.
edit: what's a bit triggering is that I was just skimming through the PR I linked and I think it's making more changes. I don't like "rider" changes :(
They only impact the documentation, no behavior. Some (positional) parameters have been renamed to be consistant with others, because the parameters are shown in the documentation.
matheusmoreira | 23 hours ago
Congratulations on your release!
It's always a little reassuring when I discover I'm not the only person being plagued by this sort of issue. During recent code reviews, I discovered an eerily similar problem where I couldn't nest
importcalls because doing that would hide virtual machine instances from the GC.These waters really are full of sharks...
ilyagr | 18 hours ago
Note that a lot of the nice libraries that used to be separate are now part of the
sporklibrary collection, e.g. https://janet-lang.org/spork/api/sh-dsl.html instead of theshlibrary the older Janet book recommends in https://janet.guide/scripting/. There's also a spork version of thecmdlibrary that chapter recommends (forget the exact name).(Oh, you should look at https://janet.guide/ if you haven't yet, just remember that some library references are out of date, and the newer versions have slightly different APIs. Asking an AI might be a good way to sort it out)
For packaging, they are also trying to migrate from
jpmtojanet-pmthat's also a part of spork, https://janet-lang.org/spork/api/pm.html. It's woefully under-documented, but fortunately spork now has most of the stuff I was interested in. Installing spork itself is documented in https://github.com/janet-lang/spork#installation. Installing spork is also a prerequisite for using the new package manager :).[OP] veqq | 13 hours ago
janet-pmcan perfectly usejpmstuff, but is meant to implement 90% of obvious stuff, so you can build your own package manager on top of! So we have e.g. https://github.com/pyrmont/jeep/ and others which work on bundles andjpmstuff.Sogaiu is working on documentation for it. I also wrote: https://janetdocs.org/tutorials/packaging a while ago, but am making a new guide now that I understand much more.
We may adopt more into spork, but there hasn't been much need yet. E.g.
joy(or at leasthalo2) for web stuff, but it still works as is. Also,sporkcreates a bit more permanence, so I quite like the idea of spork just exposing more battle-tested APIs we're confident about. Stuff like https://github.com/LeviSchuck/janetls needs more immediate attention, probably.natfu | 17 hours ago
Thanks for the info, from the docs it seems JPM is still the way to go!
ChrisDenton | 19 hours ago
I really like Janet. I think it was the first programming language I encountered where there was basically no distinction (in code) between compile time and run time. Just put your code in a global and it runs at compile time without needing any further changes.
oofoe | 14 hours ago
This can also give you "bundler" functionality for free -- just read in your resources during compile and they're in the final executable.
tonyarkles | 13 hours ago
If I'm remembering right (it's been a bit) that's exactly what they do with their boot.janet as well. The whole thing is structured so that the bare minimum of environment setup is done in C, just enough to hand it off to boot.janet which handles the rest of it. Boot.janet itself gets pre-compiled at build time so that it doesn't need any parsing at runtime, just start executing the pre-baked VM ops.
[OP] veqq | 13 hours ago
That's the feature that made me fall for Janet! The 2nd half of this comment is all about it/the convoluted ways I'd tried to do it in languages before: https://lobste.rs/s/y0euno/why_janet_2023#c_imjhgs
FIGBERT | 13 hours ago
I've been doing some Janet programming for single-user projects at work, as I'm a big Ian Henry fan and have been wanting to learn a Lisp for a while. I previously bounced off several due to what seem to me to be obtuse installation processes—Janet is a nice single binary.
I've had a lot of fun with it! In particular, PEGs are super awesome.
However, it must be said that the documentation is the worst I've ever seen across any language ecosystem. I've been making my way through with a combination of Janet for Mortals, the official website, and JanetDocs but it is a slog. I'm constantly learning about more idiomatic ways of doing things that are written down in only one random place, or running into version issues, etc. Also I wish there was an LSP but that's a whole other can of worms.
In any case, with that rant out of the way, I'm going to get back to programming in Janet. Until I switch to Steel or Clojure, maybe.
[OP] veqq | 13 hours ago
What editor do you use? We have multiple LSPs. Personally I use: https://github.com/CFiggers/janet-lsp via https://github.com/CFiggers/vscode-janet-plus-plus/ which... already has all the features in the "planned features".
Do you have any examples? They shouldn't really come up. Maybe we can squash some misleading stuff. A few of us are working on the documentation, but it's a slog. Generally speaking, any concrete complains, examples of your struggles etc. would be really helpful as we don't have people to do user tests with.
FIGBERT | 12 hours ago
Hah! Feeling silly about the LSP comment, as I clicked on that link and it was already in my history. Wonder why I didn't get it up and running. I use Helix.
On the version issues, I'm having some right now actually. I found a bug in a PEG I wrote, so I tweaked it and have attempted to recompile. I also updated Janet via
brewtoday. Now, when I runjpm build, I see:The first line is in orange and is annoying but doesn't appear to break anything. I am running
jpm update-installedin order to try and get Spork recompiled (which seems to me should just happen automatically, but fine) and it fails while trying to updatejpm.jdn, after updating Spork. Still doesn't build. Running the file viajanetdirectly fails with the same error.Fixed it by running:
This is a rather fragmented way of solving an issue that simply doesn't exist in other programming languages (like Go, Rust, or Gleam). It's fine, because I hold Janet to a different standard than those much larger and institutionally supported languages (except Gleam), and still think it's fun. But package management is definitely the least fun part.
[OP] veqq | 11 hours ago
Ah, that kind of version issue! You need to do
jpm clear-cachebeforejpm update-installedto update the packages. I use this update script although I'll change it later today to removesudovia a different installation path: https://codeberg.org/veqq/setup-linux/src/branch/master/install-newest-janet.shBut we're on it: https://janet.zulipchat.com/#narrow/channel/399615-general/topic/Janet.20Documentation.20Improvements/near/620569238
Compiler warnings got added earlier this year, mostly for shadowing and macro hygiene stuff. Some more details here: https://janetdocs.org/tutorials/misc#binding-metadata (IIRC giving
:shadowor something as function metadata also silences it.)All of this of course... Is a perfect example of the "more idiomatic ways of doing things that are written down in only one random place".
FIGBERT | 12 hours ago
Also, for the record, I appreciate that documentation is a slog and that a random person complaining on the internet can be frustrating. So: I really like Janet! It's been an incredible introduction to a whole new side of programming that I've never encountered before! JanetDocs in particular is a really wonderful source in getting me up and running! Thank you for all you do.
vpr | a day ago
As a occasional Janet user, I will offer some constructive criticism on the "What's changed": Let's get some syntax for
koala | 21 hours ago
I think those refer to documentation improvements, not syntax changes. (See here.)
In general, though, I defend trying to write commit messages suitable for generating release notes. But perhaps this is an example of that not being a great idea.
edit: what's a bit triggering is that I was just skimming through the PR I linked and I think it's making more changes. I don't like "rider" changes :(
[OP] veqq | 12 hours ago
They only impact the documentation, no behavior. Some (positional) parameters have been renamed to be consistant with others, because the parameters are shown in the documentation.
vpr | 11 hours ago
I was using "syntax" in the racket sense, i.e. there should be a macro for that changelog.
koala | 10 hours ago
Ahh, sorry I misunderstood. You mean the commit messages should be more "structured" in some sense?
vpr | 10 hours ago
It was a lisp joke that if you see the same syntax repeated, it should be lifted to a macro/function. Tongue-in-cheek.