I guess you could fairly easily write a macro that automatically created a lexical scope and added some prefixes to variable used within its body - Doug Hoyte's "Let over lambda" book has #CommonLisp examples of this kind of approach as way to cut down the syntactic overhead of using gensym in macros. Without much thought, I'd assume something similar could be done in #EmacsLisp
@The ol' tealeg 🐡 I'm thinking something a little more robust involving using a symbol's property list to store everything contained within that namespace.
I'm probably biting off more than I can chew at this point in my understanding of elisp, but I'm sure this idea will stick around in my brain until I have enough of an understanding to pull it (or something comparable) off.
...or I find some already existing thing that does what I want (which is more likely).
SBCL, for example, has the in-package macro set the value of the special variable *PACKAGE* which, I guess, would then ultimately get used in every definition and reference.
I haven't having looked at it, but I imagine that it mostly comes down to switching out in-buffer eval functions to those which are current-package aware. If you resolve and swap out all symbols with their "absolute" versions during definition, you should be able to call that code from different namespaces without problems.
where (:use nil) serves the same purpose as (:use :cl) in Common Lisp.
Afterwards, you can either do
(in-namespace :foo) ...
or
(with-namespace :foo ...)
You should also be able to file-locally set `buffer-namespace', but I haven't tried it.
Here's a working snippet:
(define-namespace :foo (:use nil) (:export bar setq nil))
(define-namespace :baz (:use :foo) (:export bar))
(with-namespace :foo (setq foo 2))
foo:bar ;; => 2
(with-namespace :baz (setq bar 5) (setq quux 10))
foo:bar ;; => 5 baz:bar ;; => 5 baz:quux ;; => 10
although you'll need to patch elisp--preceding-sexp for C-x C-e to see the individual values. Here's the code you need to evaluate (at least on my version, I suggest trying this in a fresh emacs in case something goes wrong): 0x0.st/84sj.txt
I have fleshed it out more (or rather, ported over CL's packages): git.sr.ht/~thuna/cl-package (this is still the same repo, but I've changed the name).
The demo is: - require cl-package / load cl-package.el - require cl-package-reader / load cl-package-reader.el - go to a new buffer (or the scratch buffer) - M-x cl-package-activate-reader RET - Insert the snippet - Do eval-buffer, or after applying the same patch as before (replace `(read...)' with `(funcall load-read-function...)' in `elisp--preceding-sexp') go through each form (you can skip cl-in-package) one by one with C-x C-e - Have fun
The snippet is:
(cl-defpackage test (:use :global) (:shadow baz) (:export baz))
Where the second nil means that no symbol with the literal name "test:baz" exists in emacs, and that the symbol we're referring to with test:baz is something else entirely, which you can also see with:
(eq (intern "test:baz") 'test:baz) => nil
There are probably a lot of problems, some of which are: - defpackage does not play nice with redefinitions (or rather, you can't do it at all), just pop cl-package-registry (but not completely, always leave the last item, if you want to fully reset it set it to (list obarray)) and redefine it again - I have the elisp runtime in the pseudo-package :global, but trying to use :global in your own package will force it to check all (tens of thousands of!) symbols for conflicts, so it'll take a couple seconds during the defpackage in the snippet. I will later define packages containing the various elisp packages for proper modularity, so it should get better - Once you evaluate cl-in-package, eval-buffer starts with cl-in-package, which it probably shouldn't be doing, but I don't know and who knows how many more!
@screwtape Oh come on you understand the situation perfectly ;) You can write hacks to make it look like there are namespaces, but at the end of the day, they are just hacks.
There has been multiple discussions about it on emacs-devel, and there is no way to get elisp out of the dark ages until the usual suspects are replaced. Which is not happening any time soon.
@screwlisp @Nicolas Martyanoff If you think I'd actually have anything interesting to say. I feel I can't really hold a candle to some of your previous guests. I'm just aimlessly noodling around with stuff.
You know I like to set an extremely low bar for quality personally. And after all, everyone eats at your sushi place every week...!
It's also interesting to everyone to get opinions on common lisp from the outside or somewhat recent arrivals. I think you and jeremy_list are both interesting as sort of Haskell/MOO/emacs/common lispers.
Counterpointing the "golang for serious business" long-time lisp-heads like @galdor
So, I've finally settled on a technique to keep shimmer inks from clogging my #FountainPens and it's working well, but it's not exactly condusive to writing in #teeline which is what I use 90% of the time these days.
It looks like I wasn't moving the pen enough. As I would keep writing, the shimmer would collect in the feed until it just straight-up clogged. I didn't realize I had to periodically roll the pen around even while I was actively using it. This should have been obvious by the fact that my writing kept getting more and more, well... shimmery before the ink stopped flowing.
I'll try this approach in the future.
Rookie mistake, but in my defense, I didn't even know that shimmer inks were even a thing until late last year.
In a recent episode of The Cult Vault Podcast, I had the incredible opportunity to sit down with Wendy Baker, a former member of the infamous Source Family.
It always amuses me whenever I think about the fact that I got one of my favourite #FountainPens for free with a bottle of ink. It's even more amusing that I've never inked that pen up with that ink.
@Kate McDonald It's a bit of a pain to work with because I only use it with a dip pen* and have to juggle that with a UV flashlight. That aside, it works really well. Completely invisible under normal lighting conditions and shows up really well under UV.
* Because I feel that cleaning it out of a regular pen would be a pain.
In this episode of the Cult Vault podcast, host Kacey speaks with Wendy Baker, a former member of the Source Family and daughter-in-law to the leader, about her
So, with this past #Inkvent calendar, I've found myself in possession of a bunch of shimmering inks. Problem is that they tend to clog my #FountainPens. Are there any inexpensive pens that handle shimmering inks well?
I've found that my Wing Sung 3008s don't clog up much anyway, and when they do they're easy to take apart to clean them, at least once you know how. Also cheap enough to be disposable once they break. 😀 The downside is that they're known for cracking and/or the screw in the cap rusting, hence the importance of being cheap.
I've cleaned out two this weekend - I can't usually get the last little bits of glitter out, but what's left doesn't seem to block it when reassembled.
It looks like I wasn't moving the pen enough. As I would keep writing, the shimmer would collect in the feed until it just straight-up clogged. I didn't realize I had to periodically roll the pen around even while I was actively using it. This should have been obvious by the fact that my writing kept getting more and more, well... shimmery before the ink stopped flowing.
I'll try this approach in the future.
Rookie mistake, but in my defense, I didn't even know that shimmer inks were even a thing until late last year.
@redbanjer 🪕🇺🇦🇨🇦🇬🇱🇲🇽 Yeah, dip pens were my go-to solution. It's just annoying to have to keep mixing up the ink in the bottle in addition to continually dipping the pen.
I have successfully built my first #Emacs package. I want to clean it up a bit before I consider releasing it though. Also, while I can build a simple (single file) package, buildig a multi-file one is still eluding me.
When I try to install it, I get the following (less than helpful) error message: Wrong type argument: stringp, nil
Is there a way I can get more detail on why this is failing?
If you use M-x toggle-debug-on-error, you should get a full stack trace showing what was called, with what value and from where. That should at least get you started.
So getting a stack trace doesn't seem to have provided any useful additional information, but I have a potential starting point. When I look at the auto-generated *-pkg.el file from the installed single file version, I notice that there are some additional parameters passed to define-package that were not mentioned in the elisp documentation.
To demonstrate that I'm not crazy, this is from section 42.3 of the elisp manual: Function: define-package name version &optional docstring requirements
This is from the documentation for define-package: (define-package NAME-STRING VERSION-STRING &optional DOCSTRING REQUIREMENTS &rest EXTRA-PROPERTIES)
So Katy has a #Jinhao10 and today the clicker seems to be jamming. When pressed, it seems to resist extending or retracting the nib. I'm giving it a cleaning right now to make sure there was no debris or anything in there stopping it from working, but I don't know if that'll fix it.
Has anyone experienced this before? Is there a fix?
Is the trap door opening/closing properly? It could be wedged somehow. You should be able to poke the nib unit through it manually with the top removed and see if it works as expected.
Also when it's apart you can press the rear of the nib unit up into the tail and press the button and see if it operates normally that way.
Then you at least know which end of the pen is misbehaving.
@Jim P. It looks like there was some debris caught in the mechanism. A good cleaning seems to have resolved the issue. I'm a little confused as to where it came from though.
Coming down off a panic attack relapse. I'm medicated and laying in bed in the dark. I don't know of this was the right strategy, but I needed to stop the fireworks in my brain, and shutting out as much external stimulus as possible seemed the right thing to do.
As a side note, I'm now pretty much convinced I'm somewhere on the spectrum. This felt a lot like the way I've heard an autistic meltdown to be. Sounds were particularly jarring. Katy was packing up her equipment to send back to her old job and the sound of the packing tape was actually painful.
I can think of a number of other incidents where I've become seemingly irrationally agitated at something that should have been a minor thing, and any form of external stimulus whatsoever only made it worse (which really sucks when people try to "help").
That's very much an AS response. Some noises, physical sensations, environments are just intolerable, as if they're actively attacking your brain the way allergens do your immune system.
Finding out that my responses to things were *real*, and not just me being temperamental, was a big help.
From survival to storytelling—how one woman is shedding light on institutional abuse.In this gripping episode of The Cult Vault Podcast, host Kacey welcomes Kari Bunn, a survivor of the infamous CEDU reform school and a vocal advocate exposing the da…
Katy likes these YouTube channels where they teach about canning and such. One of the people in one of these videos is wearing a shirt with what looks like an AR-15 that says "defense is not a crime".
What in the cinnamon toast fuck do you need an AR-15 to defend yourself from?
How about: The current version of the Stazi (rhymes with mice), PB and III%er paramilitary and the right wing meal team 6 deplorables who are itching to use one of the 20 million AR’s that are out there right now. If you don’t want one, don’t buy one. Hope this helps
Got my hair cut for the first time in probably a year because I have an interview tomorrow for a job I really want to get (and think I have a pretty good shot at).
It looks decent, but has revealed a good deal more grey than I'm accustomed to seeing.
This morning Katy noticed a rash all around my neck. I can only attribute it to the new (to me) shirt I wore yesterday. It's like my body has revolted against wearing a shirt and tie ever again.
In this episode of the Cult Vault Podcast, host Kacey speaks with author Beth Granger, a cult survivor and representative plaintiff in a landmark class action l
From indoctrination to liberation—one woman's fight to be heard.On this powerful episode of The Cult Vault Podcast, host Kacey sits down with Beth Granger—cult survivor, memoirist, and the representative plaintiff in a landmark class action lawsuit—t…
We just filled out the card for my niece's wedding. We took some time to figure out the perfect wording, select the right ink and nib, practice my handwriting so that it was on point, and after all that, I finally came to the realisation that I'm not certain as to whether or not she's old enough to have been taught cursive.
In this episode of the Cult Vault podcast, host Kacey speaks with Madison McGhee, the creator of the Ice Cold Case podcast, which investigates her father's unsolved murder.
In this episode, Shanny shares her journey of growing up in a high-control religious cult, her experiences navigating life outside of it, and the challenges of parenting while healing from past trauma.
TRIGGER WARNING THIS EPISODE CONTAINS THEMES OF CHILD ABUSE. LISTEN WITH CAUTION!!!In this episode of the Cult Vault podcast, host Kacey speaks with Brenda, who shares her harrowing experiences of childhood sexual abuse within the cult-like environme…
What if your childhood cartoons were banned and your toys labelled demonic? What if you believed your school friends would die in an impending Armageddon?In the latest episode of The Cult Vault, host Kacey sits down with Lloyd Evans, former Jehovah’s…
In this episode of the Cult Vault Podcast, host Kacey speaks with Lloyd Evans, a former Jehovah's Witness and current activist, about his journey out of the org
TIL that Instacart now charges a "membership" to get higher priority on assignment of batches. This does not guarantee you anything, it just allows them to further exploit a workforce they're already working to the bone.
Do they not realize that many (if not most) of the people who are working this job are doing it because they don't really have any other options? And they expect them to pay for the privilege now?
Just when I thought they couldn't possibly get any more predatory, they pull this shit.
Also, I get the whole "don't bite the hand that feeds you" thing. I might take that more seriously if it was actually feeding me. Mostly it just slaps me in the face.
@Karsten Johansson I'd say so. When I say Real World, I mean somewhere where one can earn a living with it. Sadly, I know next to nothing about quantum computing though.
Yep, quite a few places, though they generally don’t talk about it much. Quantum computing, chip design, logistics, and drug discovery are a few that come to mind.
If I were to make a broad generalization, they tend to be fields where deep subject and algorithmic expertise is more valuable than relatively more-easily-replaced developers.
Which is, of course, not to say that e.g. Python/JavaScript/etc developers don’t also need subject matter expertise, but the necessary understanding is generally shallower and less entangled with the algorithmic complexity.
(Again, painting with a very broad brush here.)
There’s also an axis of software lifecycle, too. If you’re constantly changing requirements it’s less valuable to remember last year’s nuances. Different economics than if you need to ship something stable for years.
@curtosis I have to say, the kind of job that would be looking for Lisp developers sounds like the kind of environment I might actually want to work in. I've been pretty depressed about the state of the modern tech industry.
The last dev job I had kinda burnt me out because every month or so, I was on to an entirely different project and never had a chance to develop that deep level of domain knowledge on anything. It was very frustrating.
We gather example companies that we find here: github.com/azzamsa/awesome-lis… Mind you it's nothing official. There are job offers sometimes on reddit, but also on the two LinkedIn groups, sometimes on Twitter alone, and sometimes you get a direct message (happened).
There are many in the quantum space, such as HLR labs. reddit's /u/stylewarning works for it. They released the impressive Coalton and even contribute to SBCL.
HLR, Ravenpack and Keepit are probably still hiring.
Personally, as a solo developer, I use CL more and more in my stack, ditching Python the more I can. I wrote about it: lisp-journey.gitlab.io/blog/ru…
Instead of extending a Python software I write independent modules in CL. It works well for standalone scripts too (read a DB, process data, send everything to a FTP, to a web service, by email…) It's such a joy.
Recently, the awesome-lisp-companies list was posted on HN, more people got to know it (look, this list is fan-cooked and we add companies when we learn about one, often by chance, don’t assume it’s anything “official” or exhaustive), and Alex Nygren…
I used Common-Lisp on a few professional production projects; a data transformation system for moving data between two companys' different systems. An event processing engine that applies weird complex rules to GPS tracking locations. A web micro-service or two to support some mobile apps. All of those services, except maybe the first, are still running in production. Plus, of course, a few personal projects here and there.
For all the fancy climbers and beds and such that we've gotten for the cat, his two favourite places to hang out are a random paper bag and our boot tray.
Got a rejection letter form one of the jobs I'd applied for. I have to say, I'm not terribly broken up about this one. I applied because I'm trying not to be overly picky, but I don't see myself as having been happy there long-term.
“He told me maybe the drinking was just a game—a test. That’s when I knew something was deeply wrong.”Don Johnson’s story starts like many others: a spiritual seeker, a young idealist, someone hungry for meaning in a chaotic world.
Harald
in reply to Jonathan Lamothe • • •Currently there are two options which help for the underlying problem:
gnu.org/software/emacs/manual/…
gnu.org/software/emacs/manual/…
I use both here:
codeberg.org/harald/eglot-supp…
For the shorthands, check the last few lines of the file.
But, no doubt, some real namespace with an export/import convention would be great.
eglot-supplements/eglot-selran.el at main
Codeberg.orgThe ol' tealeg 🐡
in reply to Jonathan Lamothe • • •Jonathan Lamothe
in reply to The ol' tealeg 🐡 • •@The ol' tealeg 🐡 I'm thinking something a little more robust involving using a symbol's property list to store everything contained within that namespace.
I'm probably biting off more than I can chew at this point in my understanding of elisp, but I'm sure this idea will stick around in my brain until I have enough of an understanding to pull it (or something comparable) off.
...or I find some already existing thing that does what I want (which is more likely).
The ol' tealeg 🐡
in reply to Jonathan Lamothe • • •Vassil Nikolov | Васил Николов
in reply to The ol' tealeg 🐡 • • •@tealeg
Just a sidenote, but `in-package' and Co. are Common Lisp things, not just SBCL's.
And `*package*' is mainly used by the reader.
#CommonLisp
The ol' tealeg 🐡
in reply to Vassil Nikolov | Васил Николов • • •@vnikolov the specific macro expansion can differ though, right?
Really I was just quickly checking by doing `(macroexpand ‘(in-package foo))`, I never really thought much about the implementation before now.
Vassil Nikolov | Васил Николов
in reply to The ol' tealeg 🐡 • • •@tealeg
tealeg@mastodon.online> the specific macro expansion can differ though, right?
Yes, and it often does (and it may well contain implementation-specific items, of course).
And `macroexpand' is certainly a good way to explore things; just consult the specification as well (in this case the excellent Hyperspec, CLHS).
#CommonLisp
#CommonLispHyperSpec
Thuna
in reply to Jonathan Lamothe • • •Thuna
in reply to Thuna • • •Ok, here's a working(?) proof-of-concept for
#emacs namespaces: git.sr.ht/~thuna/namespace-el
In order to use it, go to your scratch buffer (or just any elisp
buffer), do M-x enable-namespace. Then, define a namespace via
(define-namespace :foo
(:use nil)
(:export my-symbols...))
where (:use nil) serves the same purpose as (:use :cl) in Common Lisp.
Afterwards, you can either do
(in-namespace :foo)
...
or
(with-namespace :foo
...)
You should also be able to file-locally set `buffer-namespace', but I
haven't tried it.
Here's a working snippet:
(define-namespace :foo
(:use nil)
(:export bar setq nil))
(define-namespace :baz
(:use :foo)
(:export bar))
(with-namespace :foo
(setq foo 2))
foo:bar ;; => 2
(with-namespace :baz
(setq bar 5)
(setq quux 10))
foo:bar ;; => 5
baz:bar ;; => 5
baz:quux ;; => 10
although you'll need to patch elisp--preceding-sexp for C-x C-e to see
the individual values. Here's the code you need to evaluate (at least
on my version, I suggest trying this in a fresh emacs in case
something goes wrong): 0x0.st/84sj.txt
Thuna
in reply to Thuna • • •I have fleshed it out more (or rather, ported
over CL's packages): git.sr.ht/~thuna/cl-package (this is
still the same repo, but I've changed the name).
The demo is:
- require cl-package / load cl-package.el
- require cl-package-reader / load cl-package-reader.el
- go to a new buffer (or the scratch buffer)
- M-x cl-package-activate-reader RET
- Insert the snippet
- Do eval-buffer, or after applying the same patch as before (replace `(read...)' with `(funcall load-read-function...)' in `elisp--preceding-sexp') go through each form (you can skip cl-in-package) one by one with C-x C-e
- Have fun
The snippet is:
(cl-defpackage test
(:use :global)
(:shadow baz)
(:export baz))
(cl-in-package :test)
(setq test:baz 10)
(message "%S" test:baz) ;; => 10
(intern-soft "test:baz") ;; => nil
Where the second nil means that no symbol with the literal name
"test:baz" exists in emacs, and that the symbol we're referring to
with test:baz is something else entirely, which you can also see with:
(eq (intern "test:baz") 'test:baz) => nil
There are probably a lot of problems, some of which are:
- defpackage does not play nice with redefinitions (or rather, you can't do it at all), just pop cl-package-registry (but not completely, always leave the last item, if you want to fully reset it set it to (list obarray)) and redefine it again
- I have the elisp runtime in the pseudo-package :global, but trying to use :global in your own package will force it to check all (tens of thousands of!) symbols for conflicts, so it'll take a couple seconds during the defpackage in the snippet. I will later define packages containing the various elisp packages for proper modularity, so it should get better
- Once you evaluate cl-in-package, eval-buffer starts with cl-in-package, which it probably shouldn't be doing, but I don't know
and who knows how many more!
#emacs
Nicolas Martyanoff
in reply to Jonathan Lamothe • • •vintage screwlisp account
in reply to Nicolas Martyanoff • • •@galdor
Nicolas Martyanoff
in reply to vintage screwlisp account • • •@screwtape
Oh come on you understand the situation perfectly ;) You can write hacks to make it look like there are namespaces, but at the end of the day, they are just hacks.
There has been multiple discussions about it on emacs-devel, and there is no way to get elisp out of the dark ages until the usual suspects are replaced. Which is not happening any time soon.
vintage screwlisp account
in reply to Nicolas Martyanoff • • •@galdor
jlamothe did say the words introducing rudimentary...!
By the way, should I interview you ("interview") some time?
@me
Jonathan Lamothe
in reply to vintage screwlisp account • •vintage screwlisp account
in reply to Jonathan Lamothe • • •You know I like to set an extremely low bar for quality personally. And after all, everyone eats at your sushi place every week...!
It's also interesting to everyone to get opinions on common lisp from the outside or somewhat recent arrivals. I think you and jeremy_list are both interesting as sort of Haskell/MOO/emacs/common lispers.
Counterpointing the "golang for serious business" long-time lisp-heads like @galdor
Jonathan Lamothe likes this.
Jonathan Lamothe
in reply to Jonathan Lamothe • •Greg A. Woods
in reply to Jonathan Lamothe • • •Have you read this yet?
emacs.stackexchange.com/questi…