freenode/lisp - IRC Chatlog
Search
11:48:04
ebzzry
Using ASDF, is there a way to determine the name of the system that is currently being loaded?
12:34:17
beach
jprajzne: Not necessarily. If the existing software is written in an unsafe language, or in a language that makes the software difficult to maintain, or in a language that is not supported by some operating system we are thinking of, then writing a better version is justified.
12:35:31
jackdaniel
English term "reinventing the wheel" is terrible at what it tries to illustrate, because wheel was reinvented many times for many reasons (i.e we do not drive on wooden wheels)
12:37:51
jprajzne
beach: yes, in reality. but aside from that, if it was good to run in production, we should be able to reuse it
12:38:36
jprajzne
but i rarely see people taking implementation x and reusing it with much of writing new code somewhere else?
12:42:24
jackdaniel
oh, thank you, I didn't know that. next time I'll bring that up against the "wheels" instead of Polish idiom
13:06:42
flip768
just read https://lwn.net/SubscriberLink/793253/6ff74ecfb804c410/, didn't know that C was already _that_ messy... Seems that writing things in C is only doable with -O0 now.
13:23:37
beach
dlowe: Me neither, or at least I don't think so. But I found several sites on the net claiming it is an idiom.
13:25:37
ck_
ACTION activates stopwatch to see at what point someone is checking google ngrams or equivalent
13:48:45
Xach
cron runs "screen -c daily.screenrc -dmS daily-build" and daily.screenrc runs sbcl with the right options.
17:10:11
Xach
portable allegroserve changing from aserve to paserve has broken a number of things that are very old and unlikely to be fixed
17:15:16
ck_
do you know, as in do you collect stats for, how often these are requested through quicklisp?
17:17:42
ck_
do the broken legacy ones appear in any significant way? If some authors are no longer contactable, maybe someone else would take over and do the p-port
17:22:14
ck_
anyway has this happened before in quicklisps lifetime? Are there -legacy repositories where the maintainership has changed?
22:13:11
nullnullnull
man, I just wanted to try lisp and im stuck on the debugger console :| exiting the debugger is a serious business
22:25:53
Oladon_work
See how it says "restarts (invokable by number or by possibly-abbreviated name):" ?
22:26:54
Oladon_work
Yeah, what no-defun-allowed said — you're good for now, but you should learn how to use the debugger for the future
22:34:48
Oladon_work
Hehe, nullnullnull: the REPL there is reacting to your SIGINT and dropping you down into the debugger
22:45:30
aeth
nullnullnull: You'll want to use GNU Emacs with SLIME. That gives you a separate buffer (in-Emacs frame) for the debugger instead of having to deal with command line input there. It also gives you readline-like control in the REPL (since readline defaults to Emacs-style keys) without having to do rlwrap (which is the in-terminal option... if you're using it in the terminal, you should setup rlwrap)
22:47:03
aeth
nullnullnull: Also, current SBCL is 16 releases ahead of 1.4.5 so you might want to use Debian's SBCL to compile the latest SBCL (it requires a CL compiler to compile) because there might be bugfixes and other improvements since then.
22:47:51
aeth
nullnullnull: If you're using another editor other than Emacs+SLIME, then the important thing is that you're using an editor with Swank integration, since Swank is the TCP protocol that's used to communicate between the editor/IDE and the implementation. Vim probably has the second best support, but vscode might have something.
22:49:28
aeth
It's possible that there might be some LSP (Language Server Protocol) layer on top of or instead of Swank, idk, I've never looked into that.
22:51:16
aeth
nullnullnull: Well, you have two different CLs, the development CL and the deployment CL. You usually develop CL interactively from the REPL with editor integration. Then, you can have some launch file that will call your main function when run with your implementation-specific launch command
22:52:22
aeth
You can build a standalone executable, which is heavyweight but means the user doesn't need CL installed. This basically bundles the whole implementation with the script. Or you can have a script file. With SBCL you can just run it with a #! but the problem is that you need to hardcode the path and it could be in /usr/bin or /bin or somewhere else.
22:53:07
aeth
For running a script with SBCL --script works, but for some reason I prefer "sbcl --non-interactive --load path/to/script.lisp" instead of --script. Slight difference in semantics, I guess.
22:54:06
aeth
That doesn't work in SBCL unless you make it a bilingual file that is both bash and CL, which actually can work since #| .. |# is a block comment in SBCL and # is a line comment in bash, so #| will be ignored, and then in bash everything after a line that contains "exit" will be ignored
22:55:32
aeth
The easiest thing to do for scripting without a hardcoded implementation path would be to have a shell script that contains one line with the line being something like this: sbcl --non-interactive --load path/to/script/entry/point.lisp
22:55:54
aeth
You would only run that file when running as a script, not in development, since that file will probably include something like a top-level (main) call
22:56:36
aeth
Well, you can do --eval but it's easier to put it in its own file imo if it's anything more complicated than a simple --eval "(main)"
22:57:59
aeth
That's because the script file will probably be doing a bunch of (ql:quickload :foo) which you normally wouldn't do.
22:59:06
aeth
then launch.lisp could be as simple as: (ql:quickload :your-script-system) (your-script-package:main)
22:59:43
aeth
Eval could technically work but it will probably bloat past a one-liner as things tend to do.
23:01:13
aeth
It might not run faster. launch.lisp after first run will be compiled and placed in the cache at ~/.cache/common-lisp/your-implementation-name/path/to/script/launch.fasl (if not SBCL, the extension won't be fasl)
23:01:41
aeth
I mean, for a one-liner it might still be faster to just eval it, but that's kind of a microoptimization
23:02:01
nullnullnull
so at first time will be normal but second run: the load will be faster because it's saved on cache right?
23:02:22
aeth
For a large enough file. There might be an upfront overhead that makes eval faster for simple enough commands.
23:03:54
nullnullnull
why im asking u this: because in javascript for example they used to convert code to onliner script to load page faster (it's like a production code)
23:06:01
aeth
With typical CL, after the first compilation you won't see the text again and will just load the FASL, unless the dependencies have changed or you delete the cache or you upgrade your implementation. Although, I'm actually not sure if launch.lisp would experience that because this might be done through ASDF. The vast majority of your program would be an ASDF system defined in an asdf:defsystem in a foo.asd file, though.
23:09:18
aeth
You'll probably have four files at a minimum if you're going for a script with this approach, which isn't the only approach. (The shell script that launches it from the shell, the launch.lisp that it calls, the your-project.asd that defines your project, and the script.lisp... but there would usually be at least one more, called package.lisp, where you do the defpackage... especially if there's more than one file that shares one package)
23:11:38
aeth
In development, you'd usually use the REPL directly and skip the first two steps, which is part of the reason why you'd want to have the separate files.
23:12:37
aeth
If you can't expect the target machine to have CL, you can build a binary which bundles the implementation with it, which would make the deployment process different. There are portability libraries that handle this use.
23:13:29
nullnullnull
yeah, I'm only worrying about the packages atm (need to install on every development machine)