freenode/#lisp - IRC Chatlog
Search
3:22:36
LdBeth
ACTION uploaded an image: ima_7a79fe2.jpeg (8KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/kbjWwfdpmsHKlQyBwXnEJHoD >
3:24:35
pjb
LdBeth: this can be done trivially with font-locking. But indeed, the regexp may be complex if you want to avoid strings, (and comments), notably in CL where strings can stand on several lines, and comments can be embedded.
3:32:01
LdBeth
pjb: for my purpose these should be inserted by user and doesn’t mean to be preserved across sessions
3:33:49
pjb
LdBeth: you can let the user type the )))) using paredit, and display them as a single ]
13:35:30
jmercouris
I'm getting the following return value from a funciton in a library I'm using @2019-03-08T15:33:13.000000+01:00
13:40:28
jmercouris
ok, so I'm getting these timestamps from SXQL, I am wondering if instead there is a way to just query by time instead of checking the timestamp
13:46:01
jmercouris
local-time seems pretty handy: (local-time:adjust-timestamp (local-time:today) (offset :day -1))
13:56:40
jmercouris
in case anyone is wondering in the future, you can use local-time objects in SXQL to do date comparisons
14:11:31
jdz
jmercouris: You might be able to do something like (... :created_at < "now() - interval '24 hours'")
14:18:50
aeth
The lack of updates in 25-30 years and the limitations of 16-bit will be painful to work with. Shouldn't be hard to run in DOSBox, though
14:22:09
aeth
The way a Lisp usually works (although 16-bit ones might be different because of necessity) is that they have tag bits on everything, which means that anything that cannot fit in a word *with* the tag bit has to be heap allocated except in niche circumstances.
14:22:13
aeth
e.g. single-floats fit in a 64-bit Lisp's word size, but not double-floats, since 64-bit floats need some tag bits. But in 32-bit Lisps, even single-floats will be heap allocated if they're 32-bit IEEE single-precision floating point
14:23:56
aeth
And a fixnum is basically the largest signed integer that isn't heap allocated on an implementation. So e.g. for 64-bit SBCL that's a 63-bit unsigned integer because it uses one bit as a tag. Unsigned fixnums are used for most minimum sizes, which means at most you get 2 less than the word size in bits, or 62-bit for SBCL.
14:25:42
aeth
So if I'm doing this correctly, then for a 16-bit implementation that uses the absolute largest fixnum like 64-bit SBCL does for 64-bit you get this as your largest non-bignum integer (= (- (expt 2 14) 1) 16383)
14:26:01
aeth
At most 16383. Some implementations might be less, and that doesn't mean that your largest array has 16383 elements because it depends on e.g. how its tagging works.
14:27:02
aeth
The minimum value for array-total-size-limit is 1024. It's definitely possible that the DOS Common Lisp you find does actually have this value. That means some docstrings are too large.
14:32:05
aeth
If you use a 64-bit CL you basically never have to think about limits and this is esoteric knowledge. If you use a 32-bit CL, you might hit certain limits if you're working with e.g. images or video. If you use a 16-bit made-for-DOS CL, you have to change how you write programs to work around certain limits. It doesn't sound like it would give people a good impression of the language at least imo.
15:18:09
edgar-rft
lionrouge: there's an XLISP-PLUS interpreter from 2016 that still runs on MS-DOS at the bottom of the page -> http://www.almy.us/xlisp.html