libera/#commonlisp - IRC Chatlog
Search
7:42:00
beach
rdrg109: Do you have any particular reason for using GNU CLISP over other implementations?
8:59:46
susam
By the way, I still keep CLISP around because (1) nostalgia (2) testing out if some implementation-dependent behaviour behaves differently with CLISP. That is, SBCL as the primary implementation and CLISP to test out my programs to weed out any bad habits of writing implementation-dependent code.
9:31:43
kakuhen
i became really angry when doing this for a certain cl project because a bunch of really really simple functions that reinvented already-existing functions in the CL spec were using sbcl extensions
9:33:25
kakuhen
but after patching out that mess... i am now just angry at one thing: every CL implementation seems to have its own posix interface and export symbols for errors and signals, but neither uiop nor osicat-posix have decided to have wrappers for this
9:34:21
susam
kakuhen: Any example you can remember? I am trying to understand why a function in CL spec would use sbcl extension and even if it did why it would matter as long as it conforms to the spec.
9:35:09
kakuhen
(defun get-decoded-system-time () (decode-universal-time (+ (encode-universal-time 0 0 0 1 1 1970 0) (sb-posix:time))))
9:36:45
kakuhen
the macro i was dealing with was the result of some guy who took a perfectly fine macro using CFFI and decided "hmm let me just write out the pure sb-alien calls instead"
9:37:08
kakuhen
lots of stuff that originally used bordeaux threads for no reason were rewritten to just use sb-thread
9:39:22
kakuhen
i've been writing a set of patches in order to bring *at least* CCL support back, and hopefully expand portability
9:39:47
phoe
https://github.com/stumpwm/stumpwm/blob/7fe59c00810b35843139194525db444a2c26aa72/time.lisp#L126-L128
9:40:04
susam
kakuhen: Okay. I think I get your point now. You meant that another software tool (stumpwm, in this case) decided to rely on SBCL ext instead of the spec. Problematic, of course. I see what you mean.
9:40:35
kakuhen
yeah, I don't mind what phoe suggested earlier, that is, (defun foo () #+sbcl ... #-sbcl ...)
9:41:08
kakuhen
but in this case it's a mixture of, I guess oversight(?) on some committers parts, and then people deciding to just force sbcl hard deps
9:41:45
kakuhen
i havent sent my patches yet because I am waiting till I can get stump running fine on CCL, and then I will essentially send the maintainers every single patch
9:42:05
kakuhen
that way they are a bit more open to the idea of changing things for sake of portability
9:42:30
kakuhen
no point fixing that time function when there's still a dozen other sbcl-specific code left to patch; etc etc
9:43:13
kakuhen
the number is staying positive only because it DOES make sense in some scenarios to use sbcl extensions
9:43:50
kakuhen
and I found a bunch of stuff by some Javier guy to intentionally rewrite things to be sbcl-specific
9:44:12
phoe
there is an explicit #-sbcl (error "This lisp implementation is not supported.") in the code, so
9:44:35
kakuhen
you'll see a bunch of "portable" code just get deleted and they leave the #+sbcl line remaining
9:45:55
kakuhen
but yeah -- im still in the process of patching the main io loop so that it works on CCL
9:47:14
kakuhen
a lot of what they did for main-io-loop can be done with ccl, though because of the lack of a "good" posix wrapper for errors and signals, I had to write really ugly lines so that I don't throw in magic numbers in place of actual error/signal symbols
9:47:43
loke[m]
phoe: I don't recall. It's been a few years. But I was working on the timer support at that time, and it was pretty difficult to get it to work right in anything but the SBCL backend.
9:49:01
kakuhen
because I noticed some comments about SBCL lacking some feature for I/O multiplexing
9:49:38
kakuhen
though this library is a recent thing (i.e. didnt really exist 3-4 years ago) and I'm not sure if anyone will be interested in refactoring the main io loop when it already works for most users.
10:07:33
loke[m]
kakuhen: libfixposix is a huge problem, since it's not available in most repositories either, people have to seek it out.
10:07:59
loke[m]
In theory, it would be possible to compile libfixposix from the ASD file, although that is only marginally better.
11:09:37
phoe
as always with inheritance, it is up to you to resolve all interactions between your superclasses