“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 opt
• src 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?

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.

NB: I have never had the fortune to write Lisp in a professional setup.

For years, I used to use SBCL snippets for a whole set of automation tasks in my daily workflow, like updating git repos in batch, checking failing CI/CD pipelines per repo, organising my music collection, etc.

But gradually I switched to more specialised tools and, yes, Emacs Lisp to do what I needed to do. It just felt more ergonomic in my case.

The last time I seriously used SBCL was to solve some of Project Euler’s challenges back in 2018: https://github.com/bahmanm/euler-cl

Nowadays, I’ve got no non-elisp code left 🙂 🤷‍♂️

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.

I cross-posted the same questions on Matrix and got the answer there.

The hook I’m using is invoked before the minor modes are setup - that’s why it’s being overridden. The suggestion was to have a hook function for each minor mode that I want to control. It’s not clean but gets the job done.

Here’s the working snippet:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defun bahman/helm-major-mode.hook ()
 (display-line-numbers-mode -1)
 (puni-mode -1))

(add-hook 'helm-major-mode-hook
         #'bahman/helm-major-mode.hook)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defvar bahman/display-line-numbers-mode.disabled-modes
 '(vterm-mode erlang-shell-mode)
 "Disable `display-line-numbers' for the specified modes.")

(defun bahman/display-line-numbers-mode.hook ()
 (when (seq-contains-p bahman/display-line-numbers-mode.disabled-modes
                       major-mode)
     (display-line-numbers-mode -1)))

(add-hook 'display-line-numbers-mode-hook
         #'bahman/display-line-numbers-mode.hook)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defvar bahman/puni-mode.disabled-modes
 '(vterm-mode)
 "Disable `puni-mode' for the specificied modes.")

(defun bahman/puni-mode.hook ()
 (when (seq-contains-p bahman/puni-mode.disabled-modes
                       major-mode)
   (puni-mode -1)))

(add-hook 'puni-mode-hook
         #'bahman/puni-mode.hook)

Thanks all for your feedback 🙏

I’m going to stick to “version 2” which, to my mind, reads more naturally. I’ll definitely consider the iterative suggestions for the sake of performance if I ever decide to submit a patch upstream. But for now, what I’ve got does the job for me dealing w/ sequences w/ less than 50 elements.

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.

Love the attitude 💪 Let me know if you need help in your quest.

I see.

So what do you think would help w/ this particular challenge? What kinds of tools/facilities would help counter that?

Off the top of my head, do you think

• The sign up process should be more rigorous?
• The first couple of posts/comments by new users should be verified by the mods?
• Mods should be notified of posts/comments w/ poor score?

cc @PrettyFlyForAFatGuy@lemmy.ml

Interesting topic - I’ve seen it surface up a few times recently.

I’ve never been a mod anywhere so I can’t accurately think what workflows/tools a mod needs to be satisfied w/ their, well, mod’ing.

For the sake of my education at least, can you elaborate what do you consider decent moderation tools/workflows? What gaps do you see between that and Lemmy?

PS: I genuinely want to understand this topic better but your post doesn’t provide any details. 😅

tests assertions top level

Noted. Makes sense.

Yes, that’s essentially the snippet in my post 👍

Oh!? And I was under the impression that the code reads more naturally than the initial version 😂

Let me try putting it in words and see if it makes sense to you:

Given sequences seq1 and seq2 and sequence of sequences sequences, seq-intersect-p should return non-nil if at least one pair of the input sequences have got an intersection.

1. If seq1 and seq2 intersect return t
2. Recursively check if seq1 intersects w/ any element in sequences. If it does, return t. Otherwise we know seq1 is safe to be ignored - no intersection whatsoever.
3. Recursively check if seq2 intersects w/ any element in sequences. If they don’t, we know seq2 is safe to be ignored too.
4. Recursively check if any elements of sequences intersect w/ each other.

There’s no caching or optimisation in this version. So it’s always O(n²).

That single line of Lisp is probably (defmacro generate-compiler (...) ...) which GCC folks call every time they decide to implement a new compiler 😆

Thanks for the code review and feedback. Here’s a 2nd attempt: https://pastebin.com/WBqs9u8L

I essentially threw away my bloated Java/C#'esq implementation and started from scratch. Please let me know what you think 🙏