freenode/#lisp - IRC Chatlog
Search
3:47:31
jasom
Technically Nul is not one of the standard characters so an implementation could fail to support embedded Nul characters
3:48:16
Bike
i didn't mention that since that makes the scenario more fanciful. also if there is a character it would have to support putting that character in a string
4:26:12
easye
ABCL could really use a release that optimizes loading times: the new implementation of loading things in abcl-1.8.0 slowed things down by a factor of 2x-3x.
4:30:54
beach
easye: Yes, I know. I just don't know whether it is good to work a lot (and not get much done) or work less (for the same amount of work).
4:32:24
beach
In the past I often had students who complained about mediocre grades on some homework, saying they put in a lot of work. But I told them, it's the result that counts, not how tired you are.
7:42:34
White_Flame
so when using ql libs that pull in .so/.dynlib, are there tools or best practices on how to get an actual executable that doesn't die on startup on another machine without a bunch of stuff natively installed?
8:01:36
moon-child
White_Flame: bundle all the libs you need. You should be able to use strace (or similar) to see everything that gets loaded
8:03:12
White_Flame
as I've not done this before, is it common across OSes to search for dynamic libraries in the executable's directory?
8:07:36
moon-child
also if you put the libs in a separate dir from the executable (which is imo cleaner), the variable to set on windows is PATH
15:29:20
Josh_2
Whats the go to way to update already dumped lisp images? Do you normally just tell users there is a new version and get them to swap them out? Surely they could just update their running image?
15:32:38
Josh_2
I dont want to tell a user that they have to keep changing out their lisp image, I'd rather they just ran a script and it updated itself while running, I'm sure someone has done this before
15:36:02
etimmons
Josh_2: I don't know of any way to switch images while running. But if you distributed fasls you could load those into a running image to "patch" it.
15:36:39
Josh_2
sorry I wasn't clear enough, I don't mean swap images, thats equivalent to just getting and starting a new binary
15:37:37
Nilby
Updating from code is fairly easy, but can have problems. Most Lisp's can't update the image and keep running said code.
15:38:49
etimmons
White_Flame: If you're going to distribute a MacOS binary that depends on libssl, I'd recommend using the OS provided libs instead of the ones from Homebrew.
15:38:55
phoe
you could also architect your image in a way that allows it to check for updates before running everything
15:39:30
etimmons
White_Flame: IIRC, Homebrew's openssl doesn't integrate with the system keychain to get certificates and such.
15:39:59
phoe
etimmons: AFAIK libcrypto.dylib fails on modern macos/apple silicon because it has an unversioned API and Apple decided to make this a breaking change
15:40:00
Josh_2
phoe: that could work because the program is user facing and could just receive a command to update which would stop and restart it
15:40:08
Nilby
I would just reload with asdf, and the next time it got a request it would run the new code.
15:41:10
Josh_2
I also want to be able to hotload code straight into my running image, so that modules can be added/removed from my project as the user chooses
15:41:55
etimmons
phoe: There's a patch to fix it in https://github.com/cl-plus-ssl/cl-plus-ssl/pull/115. You can also work around it until the PR is merged by loading the versioned dylib yourself and pushing :cl+ssl-foreign-libs-already-loaded to *features*
15:41:58
Josh_2
Okay cool beans. I've know very little about fasls files, I guess It's time to change that
15:43:18
etimmons
White_Flame: your pastebin has /usr/local/opt/openssl/lib/libcrypto.dylib as the path it's trying to load. I think that's the Homebrew path
15:44:18
White_Flame
hmm, so at startup sbcl doesn't search the library path for dylibs, but rather just hits the exact same path that was used when the image was saved?
15:44:36
etimmons
Nothing wrong with that per se, but if you're going to share it with people that don't have Homebrew installed, I think they'll have a not-so-great time when that lib looks for trusted certs where Homebrew installs them
15:46:12
etimmons
So if you load the foreign lib "libssl.so" then it'll search again on startup. But if you give an absolute path, it'll try using that path exactly