freenode/#lisp - IRC Chatlog
Search
10:57:31
edgar-rft
According to Dennis Ritchie C is the most inappropriate language to write big programs in :-)
13:03:47
grewal
fwiw, for small tools like that I've had luck using a long running lisp image in the background and writing a tiny script that passes command line args through a pipe
13:05:05
grewal
If you have enough tools, you can turn it into a busybox-like sort of thing where the image contains all the tools and it dispatches based on the name used to invoke it
13:29:57
MichaelRaskin
Me, I just have a prebuilt image with the tools I want to invoke, and pass it '--eval'. Start-up overhead is quite low
15:15:10
paines
I am fiddeling around with a smaller project which uses SDL2 and now I am wondering why I cannot call a function which seem to be there, sdl-set-hint\
16:50:44
jcowan
beach: I don't think it's correct to say Python is not a general-purpose programming language. "Scripting language" is basically a way of saying "language I don't like"
16:52:19
jcowan
Indeed, that is not strong enough: there are, it seems, many C interpreters, so C is indeed a scripting language.
16:56:42
scymtym
maybe saying /cpython/ is a scripting /environment/ would be more accurate since it ticks several of the boxes: cannot make (afaik) standalone binaries, does not compile to native code, is effectively single-threaded and arguably executes slower than "non-scripting languages". but i agree that "scripting language" is not a very useful way to categorize languages or even implementations
16:58:58
jcowan
There's a number of tools that let you create Python standalone files. The CPython interpreter is bundled in with necessary .pyc and .so/.dll files, and everything just gets set up.
17:01:41
jcowan
Compiling into native code has the problem that it is neither portable nor stable. Larceny Scheme compiles into 32-bit x86, for which you have to load special libraries on Linux, and I expect support for them to rot over time (already WSL1 does not have it). Fortunately it also compiles to C in a version known as Petit Larceny.
17:14:54
p_l
jcowan: it's possible to make a stable binary on linux - it's the Glibc that doesn't want to cooperate
17:15:29
p_l
(Go for example makes binaries that depend only on kernel being above certain version when you use certain command line flags)
17:34:27
White_Flame
"scripting" tends to indicate that its primary behavior is to invoke behavior of other things outside the script
17:34:51
White_Flame
while "programming" tends to indicate defining the primary behavior in the code itself
17:35:28
White_Flame
while those definitions still exist on a gradient, I think that's likely the common intention of those terms
17:36:42
White_Flame
if what you're doing is managing calls to external C libraries, then probably yeah
17:37:31
White_Flame
while Lisp is kinda weak at scripting, because of its strong focus on its own image
17:37:42
p_l
Well, anything else can quickly hit performance limits that result in red-eyed sysadmin going all BOFH on you
17:42:41
jcowan
The last few jobs have involved programming in Python and occasionally scripting in bash.
18:00:26
beach
I was under the impression that the term was used by the creator of a language to mean "I hav no intention, or not enough knowledge, to make it fast enough for general use."
18:33:15
jasom
I agree that scripting is primarily about automating external tools. The bourne shell is the clasic example of a scripting language. This actually gells with beach's definition because if you spend 90+% of your time in external tools then there really isn't a point in making the language fast enough for general use.
19:57:47
jcowan
p_l: What's bad about Python exception handling other than only having termination semantics?
19:58:43
p_l
jcowan: I don't know if it's just the library I'm using, or the exception system itself, but nested exceptions, or specifically, when you catch an exception inside exception handlers, lead to very hairy failures
20:02:32
jcowan
https://stackoverflow.com/questions/3208566/nested-exceptions shows how a handler within a handler works; it's what you expect from dynamic scope (which in this case happens to be static scope as well).
20:25:29
grewal
The more I use python at work, the more tempted I am to write an implementation of python in cl
20:27:49
p_l
I nearly rewrote a noticeable chunk of a product in DAYJOB[-5] in *anything compiled*... but I was too sleepy from fighting python over night to do so
20:34:52
aeth
grewal: there are a bunch of these projects going on right now (not Python, though, but I think there's at least one ancient Python in CL, probably Python 2) so it's probably best to wait until some common code gets moved into libraries
20:37:28
aeth
Yes, with different approaches. (1) cl-python https://github.com/metawilm/cl-python (implements Python in CL); (2) burgled-batteries https://github.com/pinterface/burgled-batteries (bridges into Python via CFFI); (3) py4cl https://github.com/bendudson/py4cl (uses textual streams to bridge with Python)
20:38:31
aeth
However, cl-python is the one that uses the approach that grewal would want and that's essentially abandoned, is only Python 2 (afaik), and uses the LLGPL (NEVER license your code under a license that isn't FSF and OSI approved! NEVER!)
20:39:08
aeth
It looks like it's more on life support than abandoned, getting patches when it actually breaks, but nothing more. https://github.com/metawilm/cl-python/commits/master
20:40:49
aeth
library #2, burgled-batteries, also looks inactive, but since it's not a complete reimplementation of a living and actively-developed language that would have needed quite a bit of work to keep up, it could just be stable.
20:49:12
aeth
For those unfamiliar with Python, a Python 2 in 2020 (cl-python gives no indication which Python it is even though it should have; its tests use Python 2 syntax, though) basically means it will run no current Python code, but it could be useful to help rewrite a ton of "legacy" Python into CL.
20:54:34
aeth
ah, this... I didn't find that page on my initial look at it. https://common-lisp.net/project/clpython/manual.html
20:55:19
aeth
This is... quite possibly the most important piece of information and should have been in the readme instead of a string in a manual you can only find if you search for it.
21:48:55
phoe
beach: I got a YouTube comment on Creating a Common Lisp implementation (Part 2) saying "Thanks for this series! The not covered topics are really interesting. Consider touching them in the future.
21:50:46
aeth
For those not following #sbcl apparently a lot of code uses NIL for an invalid default value, which SBCL has (afaik) started complaining about. The type-correct alternative is ERROR, but this is often not done because ERROR will quickly pollute your swank/slime API with useless information if you e.g. have 8 mandatory &key arguments with a declared type that doesn't permit NIL.
21:51:39
aeth
I think it's in everything except struct definitions at the moment? But SBCL intends to check everything for that now.
21:52:15
aeth
I think the resolution should be to modify swank to hide the contents of (error ...) defaults by default, to prevent a ton of useless noise in the function API. sort of like *arglist-show-packages* except more like *arglist-show-full-errors* or something. https://github.com/slime/slime/blob/fac8069fc13eb62742c31967b314bddb6da6b6c7/contrib/swank-arglists.lisp
21:53:07
aeth
so instead of seeing &key (foo (error 'your-full-package-name/conditions:whatever :details "foo bar baz" :variable 'your-full-package-name/foobar::quux)) ...
21:54:47
phoe
I mean, (error) signals an error, but it's a PROGRAM-ERROR because the required arg is not provided
21:54:51
aeth
Is anyone familiar enough with swank to be able to modify this? Or would I have to dig into it to try? This is going to affect quite a few packages that will now have to change invalid NILs to ERRORs
21:55:10
phoe
but I'd rather have (error ...) to signal that there's actual args in there that have been elided for readability
21:55:20
aeth
And I don't think my example of the problem, which currently is just &key (foo nil), is an exaggeration
21:58:25
Gnuxie[m]
what do you mean by uses nil for an invalid default value? default value for what? why's it wrong?
22:02:19
aeth
Gnuxie[m]: the shortest thing I can think of is (defun foo (&key foobar) (declare (type integer foobar)) (1+ foobar)) which should (but is not guaranteed to!) error if called as (foo) instead of (foo :foobar 1)
22:02:45
aeth
Gnuxie[m]: But it's one of those things that, when seen in a short example, you'd wonder why anyone would do that, but it could easily happen if someone designed a function API with, say, 10 arguments, some mandatory.
22:03:32
Gnuxie[m]
oh ok, so this is specific to people declaring things as not null without realising?
22:03:35
aeth
Gnuxie[m]: the right thing to do is something more like this: (defun foo (&key (foobar (error "FOOBAR is a required argument"))) (declare (type integer foobar)) (1+ foobar))
22:03:55
aeth
Gnuxie[m]: But a lot of people will explicitly rely on things being NIL as an invalid type because they don't want to take, like, 4 lines or something in SLIME
22:04:21
aeth
Emacs will expand the minibuffer, but it still is pretty annoying, and the only time that ever really happens is with a lot of ERRORs in keys
22:04:35
aeth
When you as the user probably only care that it will error by default, i.e. required argument
22:05:36
aeth
Gnuxie[m]: But SBCL is starting to detect this sort of UB... Idk if it has gotten to this one in particular, but it might have.
22:07:40
aeth
So this is a case of SBCL finally doing the right thing (warning on UB), but the tools encouraging the wrong thing (it really doesn't take many keys for those ERRORs to be really, really annoying in SLIME).
22:09:47
aeth
And on top of that, I think that SLIME translates DEFCLASS :initarg/:initform pairs into keys like this. At least in SBCL, it looks like it does, which is pretty smart of it, because it's working off of (make-instance 'foo ) instead of just a function API.
22:10:04
aeth
Gnuxie[m]: e.g. (defclass foo () ((foobar :initarg :foobar :initform (error "This is a mandatory slot."))))
22:10:26
aeth
But, again, the error could be incredibly verbose, but the user probably only cares that it is an error.
22:14:46
aeth
And with respect to what I have just written in the last 30 minutes of lines here, I waive all copyright and related rights to the extent permitted by law, and otherwise place the text under the CC0 license described here https://creativecommons.org/publicdomain/zero/1.0/ and with the full text here https://creativecommons.org/publicdomain/zero/1.0/legalcode
22:15:59
aeth
phoe: If anyone wants to justify hiding (error ...) like that in SLIME/swank, feel free to copy and paste and plagiarise.
22:23:26
Gnuxie[m]
yeah that, i didn't know it was possible to uhh copyright your irc talkings though and stop people opening issues just because you said it
22:24:01
aeth
Gnuxie[m]: probably allowed under fair use, but there was quite a bit of text here so I was just being safe.
22:25:20
aeth
I'm not a lawyer, but afaik everything you write is automatically copyrighted by you without you having to claim it with e.g. © or (C).
22:26:19
aeth
That's why code without a license is treated as all rights reserved instead of public domain.
22:29:48
White_Flame
huh, I remember getting errors/warnings of this sort of thing a while ago already
22:30:46
White_Flame
as in a few years ago. It must have only been supported in a few places and is spreading now. IIRC, it was struct slots that bit me
22:33:32
aeth
< Xach> hmm, failures with latest (ish) sbcl from git - another increase in type derivation strictness i think? http://report.quicklisp.org/2020-08-29/failure-report/claw.html#claw is one example, many seem to be due to slots with a declared type but a NIL initform.
22:39:16
aeth
So then a patch to swank to hide ERROR verbosity and an update of all library code with invalid default NILs will happen before anyone really notices it.
22:40:31
aeth
I guess I'm going to have to compile the latest SBCL and see which parts of my code break (probably more than I expect)