cross-posted from: https://lemmy.ml/post/23785552
After nearly 2 years of work, I'm excited to release the first version of bjForth, featuring partial JONESFORTH compatibility and initial Java interop.
Grab it and start hacking: https://github.com/bahmanm/bjforth/releases/tag/v0.0.2
PS: bjForth is a Forth (indirect threaded) written entirely in Java and its execution model is influenced by that of JONESFORTH.
Hey all.
First off, bjForth is a Forth written from the ground up with modern Java and its execution model is largely influenced by that of JONESFORTH.
Currently I'm working on Java inter-op and would like to ask for your opinions/experience on semantics and syntax.
Thanks in advance.
"Announcment"
It used to be quite common on mailing lists to categorise/tag threads by using subject prefixes such as "ANN", "HELP", "BUG" and "RESOLVED".
It's just an old habit but I feel my messages/posts lack some clarity if I don't do it π
I didn't like the capitalised names so configured xdg to use all lowercase letters. That's why ~/opt fits in pretty nicely.
You've got a point re ~/.local/opt but I personally like the idea of having the important bits right in my home dir. Here's my layout (which I'm quite used to now after all these years):
$ ls ~
bin
desktop
doc
downloads
mnt
music
opt
pictures
public
src
templates
tmp
videos
workspace
where
bin is just a bunch of symlinks to frequently used apps from optsrc is where i keep clones of repos (but I don't do work in src)workspace is a where I do my work on git worktrees (based off src)Thanks! So much for my reading skills/attention span π
Which Debian version is it based on?
Something that I'll definitely keep an eye on. Thanks for sharing!
RE Go: Others have already mentioned the right way, thought I'd personally prefer ~/opt/go over what was suggested.
RE Perl: To instruct Perl to install to another directory, for example to ~/opt/perl5, put the following lines somewhere in your bash init files.
export PERL5LIB="$HOME/opt/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"
export PERL_LOCAL_LIB_ROOT="$HOME/opt/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"
export PERL_MB_OPT="--install_base \"$HOME/opt/perl5\""
export PERL_MM_OPT="INSTALL_BASE=$HOME/opt/perl5"
export PATH="$HOME/opt/perl5/bin${PATH:+:${PATH}}"
Though you need to re-install the Perl packages you had previously installed.
Follow up on a previous post: [DISCUSS] Recent momentary outages
I've been working on a simple opt-in solution, primarily for Lemmy end users like me (but also helpful for admins), to easily check the status/health of their favourite instance.
π lemmy-meter.info
You can find the details of the implementation in 
lemmy-meter github repo.
β @admins: would you be interested in adding your instance to lemmy-meter?
You don't need to do anything except confirming - I'll handle the rest. It should only take a few minutes for your instance to show up in lemmy-meter.
Out of the box it will send only 4 HTTP GET requests per minute to your instance. However that is totally configurable if it sounds too much or too little.
PS: I wasn't sure how to reach out to the admins short of messaging them individually.
This is fantastic! π
I use Perl one-liners for record and text processing a lot and this will be definitely something I will keep coming back to - I've already learned a trick from "Context Matching" (9) π
That sounds a great starting point!
π£Thinking out loud here...
Say, if a crate implements the AutomatedContentFlagger interface it would show up on the admin page as an "Automated Filter" and the admin could dis/enable it on demand. That way we can have more filters than CSAM using the same interface.
That was my case until I discovered that GNU tar has got a pretty decent online manual - it's way better written than the manpage. I rarely forget the options nowadays even though I dont' use tar that frequently.
This is quite intriguing. But DHH has left so many details out (at least in that post) as pointed out by @[email protected] - it makes it difficult to relate to.
On the other hand, like DHH said, one's mileage may vary: it's, in many ways, a case-by-case analysis that companies should do.
I know many businesses shrink the OPs team and hire less experienced OPs people to save $$$. But just to forward those saved $$$ to cloud providers. I can only assume DDH's team is comprised of a bunch of experienced well-payed OPs people who can pull such feats off.
Nonetheless, looking forward to, hopefully, a follow up post that lays out some more details. Pray share if you come across it π
TBH I use whatever build tool is the better fit for the job, be it Gradle, SBT or Rebar.
But for some (presumably subjective) reason, I like GNU Make quite a lot. And whenever I get the chance I use it - esp since it's somehow ubiquitous nowadays w/ all the Linux containers/VMs everywhere and Homebrew on Mac machines.
To be fair, here's the complete paragraph which makes sense:
Vagrant public networks are less private than private networks, and the exact meaning actually varies from provider to provider, hence the ambiguous definition. The idea is that while private networks should never allow the general public access to your machine, public networks can.
Good question!
IMO a good way to help a FOSS maintainer is to actually use the software (esp pre-release) and report bugs instead of working around them. Besides helping the project quality, I'd find it very heart-warming to receive feedback from users; it means people out there are actually not only using the software but care enough for it to take their time, report bugs and test patches.