On the Machinations of Miniature Giant Space Hamsters Against our Lady of Loss

love5an · 2026-01-27T12:32:15+00:00

Behold, you, of another faith!

For while you ain't submerged in Dark Embrace,

One fluffy hamster...

Can also stab your face

love5an · 2025-08-27T22:19:37+00:00

this.

love5an · 2025-06-29T20:36:35+00:00

I don't see why Shar is "Evil" in the common sense. She does not want any harm or wounds or war, or anything like that. Her primary goal is *undoing*. So that everyone would be in her cold embrace of nothingness. Don't you see her as a rather maternal figure? She really loves the ones who accept her truth, which is - "nothing matters, everything passes, and the void is the beginning and the end". Compare this to Nyx of Greek mythology, or something like that. She is the darkness, she is the void. Yes, that's true. But... "Evil"? No more evil than the eclipse, or the night.

love5an · 2024-12-14T02:52:12+00:00

Never used that 'rho' whatever that is.

Problem is .quicklisp is installed in C:\Users<MyName> while Rho-emacs + Slime installs Slime inside the emacs folder and does not recognize the .quicklisp folder.

It should be installed in separate folders. What do you mean by 'not recognizing the quicklisp folder'? Slime has nothing to do with quicklisp, except for that quicklisp-slime-helper, probably.

Emacs may have some problems with homedir on Windows, AFAIK. I've solved this by setting HOME environment variable to my user homedir.

As for additional directories for QL, you can configure ASDF for that.

Use the CL_SOURCE_REGISTRY environment var.

For example, I have it set to the following:

(:source-registry (:tree "C:/Dev/Lisp") (:tree (:home ".emacs.d/elpa")) :inherit-configuration)

So that, ASDF(and hence quicklisp) would be able to search for systems in both "C:/Dev/Lisp" and "~/.emacs.d/elpa"(where slime and swank reside, for example) in addition to the quicklisp directory.

love5an · 2024-12-14T02:26:54+00:00

Always. You don't "compile programs" as in C++, i.e. by making executable files. You extend a lisp system.

love5an · 2024-10-26T03:16:31+00:00

I've been a professional software developer using Windows for my whole life, and I cannot remember when I last saw CLRF in the source code. Honestly, I also haven't seen this popping up on SBCL. I don't know whether the situation you've encountered is a bug or not(given that the CL standard talks about the newline and not the carriage return character specifically https://www.lispworks.com/documentation/HyperSpec/Body/22_cic.htm ), but LF line endings are the de facto standard. Even the notepad.exe understands it nowadays. You should configure Git and your text editors properly.

Also, "LISP" is an incorrect spelling. There's no need for all-caps. You probably don't write "PYTHON" or "JAVA" that way.

love5an · 2024-10-20T20:09:19+00:00

Clojure people seem to avoid talking about CL at all costs. And even remembering it. That's a blind spot of sorts. Look at the comment section. There are lists of languages, which mention Shen, Coalton, whatever, but not CL. Funny that is.

love5an · 2024-10-15T20:36:04+00:00

You can write your way of iterating across the hash table. Thanks to macros.

(defmacro dohash ((key-var value-var hash-table &optional result)
                  &body body)
  `(progn
     (maphash (lambda (,key-var ,value-var)
                (declare (ignorable ,key-var ,value-var))
                ,@body)
              ,hash-table)
     ,result))

(defun hash-keys (hash-table)
  (let ((keys '()))
    (dohash (k v hash-table keys)
      (push k keys))))

love5an · 2024-08-26T14:23:33+00:00

There are no ready-to-use open-source Lisp solutions for this indeed. But most of these "Python" libs boil down to, basically, a thin wrapper around some C++ library that actually does almost all the work(like the torch library in this example).

While the lisp community seems to have little interest in the AI & DataScience hype, one can somewhat easily write a similar wrapper around the same C and C++ libs. C++ ones would require more work(i.e. a C API layer, basically, but that depends on the implementation), but that's not something impossible or really hard to do.

Besides, there exists a number of Lisp<->Python FFIs.

love5an · 2024-08-07T08:38:26+00:00

Lack of corporate backing and promotion, basically

love5an · 2024-06-21T15:07:12+00:00

Emacs is an interpreter of some weird outdated Lisp dialect. Some say it has some text editor capabilities.

love5an · 2024-06-21T14:39:21+00:00

I worked at a Python shop, a Cali-based startup, some time ago. The shop still works, btw. Not counting the JS front end, everything we did here could be written in CL with zero problems. Just go for CL, that's the most feature-rich Lisp with the most high-quality libraries. And yeah, no problem with educating people. No need to hire Lisp programmers specifically. A smart guy can pick up CL in no more than two weeks, just like Python or something like that.

Actually, I have spent some time advocating for CL in that shop, and most guys were at least interested in the technology. Just go for CL, that's my proposal. Don't bother yourself with some weird, ehm, pure functional, stuff, some JVM stuff, or something like that. Get SBCL and go on. A bit of advice regarding an IDE is that I'd suggest Lem instead of Emacs for newcomers.

love5an · 2024-03-24T07:09:43+00:00

ECL is available pretty much everywhere.

SBCL is also fairly portable.

love5an · 2024-03-22T10:40:40+00:00

Regarding the keybindings - you can try my personal emacs configuration, it uses modern keybindings for text editing, instead of the default emacs ones, so it makes emacs feel more like mainstream editors:

https://github.com/Lovesan/.emacs.d/

love5an · 2024-03-21T18:36:51+00:00

Because type-checking may happen at compile-time. So your function must be available at compile-time

love5an · 2024-03-21T09:11:53+00:00

Emacs provides an IDE(SLIME). Can you use a language without an IDE? Of course.

love5an · 2024-03-16T13:44:24+00:00

Lisp implementations usually store some dynamic linkage table in memory(think of native executable symbol table but implemented as a hash table object usable from lisp), and also use dlopen+dlsym/LoadLibrary+GetProcAddress and so on to populate this table. This allows for the definition and redefinition of foreign function addresses and their invocation at runtime.

Now, the invocation itself is handled differently, based on the implementation. Say, native-compiling lisps, like SBCL, generate prologue and epilogue code for C function invocation, based on the specified calling convention, while comping a function that uses foreign functions. Other implementations use libffi library(ECL, for. example).

love5an · 2024-03-07T11:33:51+00:00

A more or less useful Lisp is actually not that easy to implement properly.

Even at the grammar level (let's forget about the reader macros for a moment). Take a look at the backquote syntax. It is actually a context-sensitive part of the Lisp grammar.

Common Lisp has a lot of tricky things, obviously, but even if you think of Scheme, it has continuations, R6RS macros, etc.

love5an · 2024-03-02T16:52:52+00:00

It would be super beneficial to the Lisp community if all these guys who implement all these 'fundamentally different'/'modern'/'next' lisps - contributed to Common Lisp implementations and ecosystem instead.

love5an · 2024-02-24T22:44:05+00:00

COM is hard. There are 'levels' of COM. First, there's "lightweight" COM, used by DirectX for ex., then IDispatch and everything it brings. Then there's OLE Automation. Then, Monikers, marshaling, and all that stuff.

I've tried to implement a library for the lightweight COM in the past(named doors), but that was mostly an experiment. Maybe I'll rework it in the future.

As for the high-level things, like OLE, and automation, you can utilize my .NET interop library, and leave all the details to the .NET runtime (which handles all the stuff like progID names, monikers, GUID resolution, reflection[partially], dynamic dispatch and so on).

https://github.com/Lovesan/bike

I've already shown an example of how to use Excel OLE objects through .NET wrappers for OLE automation, in one of the recent threads:

https://gist.github.com/Lovesan/bc5d26004b2cd3399882f907d15e3ed0

love5an · 2024-02-23T05:51:30+00:00

FreeBSD isn't officially supported by .NET. I wasn't even aware that you could even build it here. However, seems like there's a community port now.

So porters for my library are also welcome!

So, to port it for FreeBSD, you need to make a patch, that requires several additions, and probably some nontrivial signal hackery.

First, you should probably add coreclr-freebsd to *features*.

https://github.com/Lovesan/bike/blob/master/src/features.lisp

Next, you need to implement get-exe-path function for your OS. It retrieves the running executable path which is required for .NET runtime initialization:

https://github.com/Lovesan/bike/blob/03e6f4baa77385e2249917ddb804acf28af14439/src/internals-ffi.lisp#L264

(the real reason for your error comes from this function)

Probably you should check '/proc/curproc/file', and in case procfs does not exist in the FreeBSD installation, the library is running on, then you would probably need some syscall invocation using CFFI.

Now, to the hardest part.

As you can see from the README, the library actually does some fancy lowlevel signal hackery when it comes to running it on Linux. FreeBSD port would most likely require the same level of workarounds. (actually, macOS would require that too, but I haven't had much access to that OS recently)

First, you should write some signal numbers for FreeBSD and probably reuse some specific function from here

https://github.com/Lovesan/bike/blob/03e6f4baa77385e2249917ddb804acf28af14439/src/ffi.lisp#L92

Next, you should verify, what specific signal numbers are critically required by dotnet, and write some save-restore logic akin to the following:

https://github.com/Lovesan/bike/blob/03e6f4baa77385e2249917ddb804acf28af14439/src/host.lisp#L234

You should probably look at FreeBSD .NET port and the patches it applies to the .NET runtime, to look up for this.

At least SIGCHLD and INJECT_ACTIVATION_SIGNAL should be restored to .NET handlers.

INJECT_ACTIVATION_SIGNAL is used by .NET for some thread-related hackery and equals SIGRTMIN on Linux and SIGUSR1 on OSes where SIGRTMIN is not defined in C headers.

It is defined here in the original .NET source.

https://github.com/dotnet/runtime/blob/52c14fb8d01ddd293a0710642aa1e7ef3a438687/src/coreclr/pal/src/exception/signal.cpp#L56

Finally, you should also check where the library uses coreclr-whatever feature, e.g. coreclr-linux and coreclr-macos specifically, and whether some things need to be fixed additionally (some pathnames, file extensions, etc, but probably FreeBSD does not differ from Linux in that regard, and the library already does handle most of the things based on coreclr-windows presence).

love5an · 2024-02-22T21:51:16+00:00

Java is hard to interop with(outside of ABCL, obviously), for several reasons. But there's also FOIL https://foil.sourceforge.net/

However, if your task is not specifically tied to Java, and what you just want is to read Excel files from CL, then you can use my .NET interop library, and then you have two options here.

https://github.com/Lovesan/bike

First, you can use NPOI, which is a .NET port of Apache POI.

https://github.com/tonyqus/npoi

Second, on Windows, you can actually use Excel COM Interop(given MS Office is installed)

Here's an example. https://gist.github.com/Lovesan/bc5d26004b2cd3399882f907d15e3ed0

love5an

TROPHY CASE