freenode/#lisp - IRC Chatlog
Search
12:32:22
MichaelRaskin
Yes, as a terminal command — check if there is an environment variable with such contents
12:33:10
jmercouris
echo $PATH -> /Users/jmercouris/User:/opt/local/sbin:/opt/local/bin:/opt/local/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin:/Library/Apple/usr/bin:/Applications/Wireshark.app/Contents/MacOS
12:33:12
MetaYan
jmercouris: That paste doesn't show cffi:*foreign-library-directories* . You see, on my macOS I have (CFFI::DARWIN-FALLBACK-LIBRARY-PATH), which adds /opt/local/lib
12:33:52
jmercouris
MetaYan: yes it does, CFFI: Foreign Library directories (/Users/jmercouris/Source/Lisp/xyz/bin/xyz.app/Contents/MacOS/../Resources/
12:35:37
jmercouris
it should not be touching that though unless *foreign-library-directories* is not set, which it is
12:38:24
jackdaniel
since we discuss cffi pats not really related to common lisp, any idea why after enabling terminal raw mode, if the very first input is i.e C-c it is delivered as a signal?
12:41:55
MetaYan
And the output of (print cffi:*foreign-library-directories*) doesn't give something like https://termbin.com/3g28 ?
12:43:50
jmercouris
yeah, it is expanded: (#P"/Users/jmercouris/Source/Lisp/xyz/bin/xyz.app/Contents/MacOS/../Resources/" #P"/Users/jmercouris/Source/Lisp/xyz/bin/xyz.app/Contents/MacOS/")
13:21:38
beach
ACTION hesitates to tell jmercouris about the very simple technique for avoiding all those FFI problems.
13:27:02
phoe
ACTION hesitates to tell beach about the very simple technique of failing to create a web browser following today's HTML5/CSS/JC standards
13:27:54
beach
ACTION hesitates to tell phoe that there are other projects than web browsers that need to be worked on.
13:27:55
jackdaniel
I'm not hestitating to say, that tracking OSX linking problems (even with cffi) is not very ontopic on this channel
13:29:44
jackdaniel
I've tried to signal it with a joke about terminal in raw mode and interrupts, but I think I've failed communication-wise
13:57:53
beach
doomlist3: (push <value> <place>) is roughly the same as (setf <place> (cons <value> <place>))
13:59:24
pjb
doomlist3: and beware with (let ((x '(1))) (push 4.4 x) x) #| --> (4.4 1) |# because only the first cons is mutable! The last cons is (1) which must be considered immutable since you quoted it!
14:00:27
pjb
so it would be better to use (list 4.4 1) #| --> (4.4 1) |# to get a fully mutbale list!
14:06:45
beach
doomlist3: Your problems are so basic that you should probably move your questions to #clschool.
14:25:31
beach
doomlist3: Also, it would be good if you would at least acknowledge that you saw the advice that was given to you, and even better if you would tell us whether you understood it or not.
14:41:29
Bike
https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/common-lisp.lisp#L10 nice typo
14:43:18
jmercouris
I bet a good tool to detect typos could be used when you cant do real code analysis
14:43:22
jackdaniel
I'm sure that the macro uiop/package:define-package code-walks its arguments and fixes all uoip typos
14:51:57
luis
Speaking of CFFI, mid-30s-luis is quite disappointed at some of early-20s-luis's design decisions and particularly angry at late-20s-luis's integration of foreign-structs-by-value...
14:52:54
jmercouris
I've written: (cffi:load-foreign-library (library-name library) :search-path "/Users/jmercouris/Source/Lisp/xyz/bin/xyz.app/Contents/MacOS/../Resources/")
14:52:59
jmercouris
dyld: loaded: <9C53D76D-70B1-346A-992A-E5E4D60225EA> /opt/local/lib/libssl.dylib
14:54:09
jmercouris
can you perhaps look into your crystal ball into the path and explain to me why that is happening?
14:54:29
luis
jmercouris: ISTR search-path is only used as a fallback if dlopen() fails to find your library the first time around
14:56:25
luis
jmercouris: but younger-fe[nl]ix is the one to blame for adding that feature and not documenting it in the manual!
14:56:59
jackdaniel
luis: pay attention, it's not fe[nl]ix but younger-fe[nl]ix who should be put at shame! ;-)
14:58:28
jackdaniel
speaking of: fe[nl]ix is there any chance for marging mailbox support to bordeaux-threads?
15:41:53
jmercouris
luis: I'm just wondering why it doesn't look in the foreign library directories and instead tries these random paths
15:42:02
jmercouris
well, they aren't random, but they are not in the cffi foreign library directories
15:42:55
jmercouris
I wish there was at least an option to only look in the foreign-library search paths because the reason I have had this strugge is because libssl HAPPENS to be supplid on Darwin, but my Lisp is using a different version
15:43:37
xristos
jmercouris: looking at the code usually provides definitive answers to these sort of questions
16:03:20
pjb
jackdaniel: the trick is that those 427 volunteers do indeed look at the code to get the definitive answers!
16:05:18
jackdaniel
ACTION makes a shocked face and leaves to make some tea (in a shocked manner of walking)
16:06:14
fe[nl]ix
jmercouris: luis was right. the point of the search path is to have a list of often used directories, as a fallback
16:06:30
fe[nl]ix
if you already know the exact location of the library, just construct an absolute pathname and load that
16:11:06
jmercouris
and if you didn't have a habit of trying to make people look stupid and making snarky comments, you would see that
16:14:50
phoe
jmercouris: I assume that this would be to solve a problem that is the inverse of yours: CFFI being unable to find libraries on Darwin even if they were located in directories available by default
16:14:50
jackdaniel
I don't remember when I have last used moderator privigiles, but it is a fact that I'm sometimes tempted to kick and ban you, and some of the reasons are even valid :) that said I'm not overly attached to the '@' sign.
16:15:40
phoe
while you want to avoid loading libraries from /opt/ as a software deployer, some other people might want to load libraries from /opt/ as software developers
16:16:24
phoe
"if you can't find it in the list of CFFI dirs, fall back to the default list; if you can find it there, good, and if you can't find it there, signal an error"
16:16:27
fe[nl]ix
jmercouris: because especially on OSX, there are package managers like MacPorts, Brew, etc... which can install libraries in locations that are not in the default search path of libc
16:16:29
jmercouris
phoe: well, they are located in that directory by default, but of course the system supplied libraries are frequently out of date
16:17:07
jmercouris
fe[nl]ix: I am asking why we can't prioritize the paths in foreign-library-directories and THEN try others
16:17:21
jmercouris
why that choice? why offer the user the ability to set it when it will ignore it?
16:18:21
fe[nl]ix
and if you already know the exact location, building an absolute path is one make-pathname away
16:18:56
theseb
OMG i took a peak at Let Over Lambda....that seems like it is going to be an amazing read...I love the author's passion.....Don't be ashamed of macros...rather, turn them up to an 11 and let you "freak flag" fly!
16:19:23
jmercouris
I understand now the idea behind specify absolute path, but it is a little bit problematic in the case of an app bundle
16:19:56
phoe
theseb: Let Over Lambda is a wonderful exercise in mind-bending macros that you will likely never use in actual application code
16:20:05
xristos
jmercouris: nobody is obligated to spend his personal time and educate you for free, but your manners imply otherwise
16:20:41
jmercouris
xristos: I'll reply RTFM next time someone asks me a question on my channel too, I'm sure that will win me many friends
16:21:27
jmercouris
fe[nl]ix: for example, I've set foreign library directories to be a relative dir within my app bundle, it will behave as expected for libs not found on a typical system, however when I get to a lib that IS on a typical system it will try to use that one, which may be differenet
16:21:30
phoe
I enjoyed the read, but I never really came back to the book afterwards; it was certainly a good read to see what the Lisp macro system is capable of, but it has little "replayability value" to me since the author's style does not really align with the contemporary Lisp style that I know
16:22:20
jmercouris
fe[nl]ix: so the result is I cannot rely on foreign library directories and must always calculate an absolute path to every shared library within my app bundle to avoid potentially using the wrong system library
16:22:29
phoe
jmercouris: you seem to be trying to solve the problem of deploying applications and ensuring that the libraries that you bundle are going to be loaded
16:22:48
phoe
I remember Shinmera cursing multiple times when he was working on Portacle due to a similar problem
16:23:06
phoe
it wasn't CFFI but emacs loading up stuff that it wasn't bundled with, but the idea is the same
16:23:37
jmercouris
and the last thing I want to hear is a comment about "read the source code" as if I haven't been
16:28:18
fe[nl]ix
you write a wrapper shell script that sets up the environment and calls your binary
16:28:38
samlamamma
jmercouris:You probably already know this, but can't you just bundle your shared libraries as a pre-determined relative path to your application?
16:29:51
phoe
and the issue is that the /opt/ ones are prioritized anyway, and these are the ones that get loaded
16:33:10
phoe
I bet that if macOS bundling worked in this exact way, we wouldn't see any of that frustration or sparks that start flying off the channel
16:34:03
phoe
there's going to be people deploying Lisp apps for macOS with foreign dependencies in the future; they might stumble upon a similar issue
16:41:08
luis
fe[nl]ix: what do you think about augmenting CFFI's :string type to accept a special variable name that can be looked up at runtime so that each library can control their own encoding? E.g., (defcfun foo (:string :encoding mylibrary:*foreign-encoding*) ...)
16:45:04
fe[nl]ix
this is potentially slow because it defeats all compiler-macro optimizations in babel
16:45:54
luis
My motivation is some FFI for accessing a database that sometimes wants one encoding sometimes others, depending on the environment.
16:47:39
luis
You have to look up the encoder/decoder by name. Note that by default, :string will go through *default-foreign-encoding*
16:52:20
luis
This is probably not Oracle's fault. You can write whatever bytes you want in the database. Some clients use one encoding, other clients use a different one... Clients have control over these settings like it's the 1990s ¯\_(ツ)_/¯
16:53:39
phoe
blessings of the elder gods upon you who needs to interface with that bullsh#<error printing vowel>t
17:37:25
Bike
can anyone think of a situation in which the transform (if (not [test]) [then] [else]) => (if [test] [else] [then]) is not valid?
17:38:32
phoe
hmmmm. if [test] returns no values then the missing value is coerced into NIL, which still works correctly after that transformation
17:38:59
phoe
if control is transferred out of the test, neither option is evaluated, same thing after the transformation
17:51:36
Bike
well, i'm seeing it not be equivalent, basically. and no obvious example of a [test] it's not working for, of course.
17:53:10
Bike
i mean there is such an example (or something else is going wrong), i just don't know what it is because the error isn't anything obvious.
18:02:00
jackdaniel
Bike: maybe (if [test] foo) is transformed to (if (not [test]) foo) due to i.e calling reverse on "rest" args?
18:02:44
Bike
no, that should be handled. not a bad idea though, it's probably something dumb on my part like that
18:07:39
yottabyte
if I want to use Drakma to make a request and work with a json response, what's the best way to do that? for example, if I make the request (drakma:http-request "http://ip.jsontest.com/") which returns a simple json response, it's received as an octet stream. is the best way to use some library to turn this into a map? how would I do that? I tried using yason like the Drakma guide did, but I got an SSL exception
18:09:22
yottabyte
An I/O error occurred: undocumented reason (return code: 5). SSL error queue is empty. [Condition of type CL+SSL::SSL-ERROR-SYSCALL]
18:14:01
pve
Is it allowed to subclass standard-method and add an instance of the subclass to an instance of standard-generic-function? When I try it, the method goes in, but upon inspection of the generic function, it shows the method to be of type standard-method instead of the subclass.
18:15:45
yottabyte
so phoe: that returns a list, but it doesn't appear to be a plist, how do I work with it? should I really look to make a map out of it instead of a plist?
18:28:04
_death
yottabyte: actually yason has the same defect as cl-json.. sigh, just use something with a sane default such as com.gigamonkeys.json
18:43:29
pjb
Bike: assuming it's a 3 argument IF, and assuming [then] and [else] don't have read-time side-effects, yes.
19:25:28
pve
Bike: ok I can see the method subclass getting added to the gf now, the weirdness was caused by a little thinko. Won't bore you with the details..
19:52:46
ralt
I feel like I understood it to be one thing, but it looks like it can't do half of it, so I'm not sure it is supposed to be doing. IOW I'd like to know which problem it's solving, and guess its limitations from there.
20:01:18
ralt
as I understand it, it is building an object file for every cffi-(grovel|wrapper)-file, bundling them all into a static library, then linking that static library with sbcl.o (or w/e is relevant to your implementation) to build an image.
20:10:05
aeth
Yes, but on the other hand it's not a widely used library yet, so even though it's probably offered by your distro, it's also unlikely to be installed. (e.g. I don't have it installed, I just checked)
20:11:15
Shinmera
portable deployment on linux is impossible so you're better off just cutting your losses and focusing on more useful work.
20:11:46
dlowe
honestly more things should use libfixposix instead of re-implementing the wheel themselves
20:12:19
phoe
Would it make sense to add numbers to CLHS dictionaries? Like, System Class LIST would become 14.2.1, System Class NULL - 14.2.2, etc..
20:12:34
aeth
Portable deployment on Linux is possible in a dozen different ways. The three most popular are Flatpak, Snap, and AppImage. You can also use something remarkably heavyweight like Nix. Games usually use the Steam runtime.
20:12:53
aeth
I suppose the real issue is that there's no consolidation in portable deployment on Linux. There's just... a dozen different ways.
20:13:30
specbot
The Conses Dictionary: http://www.lispworks.com/reference/HyperSpec/Body/c_conses.htm
20:13:31
aeth
Shinmera: I mean, I could probably make a Linux distro that can't run any of those, but it's probably also a Linux distro that desktop users aren't going to be using.
20:13:33
Shinmera
linux makes pretty much nil guarantees about what the system will look like and you're just fucked.
20:13:54
Shinmera
so just cut your losses and do more useful work instead of wasting it on below 1% users.
20:14:29
aeth
Shinmera: Literally any of the methods I listed, except maybe Nix, will cover > 95% of Linux desktop users. Just because you can't cover 100% doesn't mean you should give up.
20:14:56
aeth
Shinmera: This isn't even taking into account writing your code entirely in a portable language, like Java or, say, Common Lisp
20:15:32
Shinmera
my point is that this obsession with creating a 'portable application' is a waste of time beyond those 95% of users.
20:16:08
aeth
Just use Flatpak. Gnome bundles it so most people probably have it installed without even realizing that they have it installed.
20:17:05
aeth
(And nearly every distro will support Gnome even if it's not a Gnome-defaulting distro)
20:18:27
ralt
I guess my main issue is one of misunderstanding -- "static-program-op" doesn't really make you think "shared binary with some embedded libraries, and not even all of them"
20:19:20
ralt
Not being able to statically build libsqlite is ok. Looks like that's what all distros are forcing.
20:20:24
ralt
when https://common-lisp.net/project/cffi/manual/html_node/Static-Linking.html says "To dump a statically linked executable standalone application", it really brings a lot of confusion :)
20:29:48
fe[nl]ix
my plan is to automate it and distribute SBCL with libfixposix and openssl statically linked
20:30:38
ralt
if you could get a static sbcl binary that doesn't end up with thousands of memory corrupted errors, that'd be nice
20:31:04
ralt
I could add more static libraries on top of it, dump images, and distribute static binaries
20:34:07
fe[nl]ix
dlowe: I should probably write some documentation and a nice website for libfixposix
20:44:49
phoe
Fare: you and no-defun-allowed need to talk more often about kill-9ing posix and unix stuffs in general
20:45:43
ralt
ok, the main issue I seem to have at the moment is that (1) if I keep static-program-op as is, it still tries to load the foreign libraries that were statically embedded, but if (2) I unload all saved libraries before dumping the image, the binary doesn't know how to load it after restoring
20:46:49
Fare
ralt, maybe you can propose a better name for static-program-op. Or at least, better documentation.
20:48:16
Fare
I remember doing that unloading and reloading at ITA before UIOP existed to provide such portable hooks.
20:50:19
ralt
with cffi-toolchain I have the nice advantage that I can just put :static-program-op in my .asd and everything is magic
20:51:38
ralt
essentially I just need to do a (loop for library in (cffi:list-foreign-libraries) unless (eq (cffi:foreign-library-type library) :system) do (cffi:close-foreign-library library))
20:52:27
Fare
ralt: #:*image-restore-hook* #:*image-prelude* #:*image-entry-point* #:*image-postlude* #:*image-dump-hook*
20:52:57
ralt
I actually used *image-entry-point* the other day, should've noticed those ones as well
20:52:59
Fare
jackdaniel, any reason not to "just" adopt ASDF 3.3.5 or whatever comes next with all the fixes?
20:53:29
jackdaniel
there is plenty of reasons, the most pressing one is that last time I've checked "new" asdf plenty of things didn't work, most notably bundles
20:54:29
Fare
if anything doesn't work about bundles, that's definitely a but. I remember spending a LOT of time making sure bundles would keep working on ECL and MKCL as well as on the other image-based Lisps.
20:55:19
jackdaniel
so freezing just before 3.2 puts a cap on it. if someone wants to upgrade their asdf, then they load it as any other library
20:55:30
Fare
jackdaniel, it's the purpose creep of ASDF, well described and explained in my ASDF3 paper. It has stopped when I left the helm.
20:56:36
ralt
> First, finalize the image, by evaluating the POSTLUDE as per EVAL-INPUT, then calling each of the functions in DUMP-HOOK, in reverse order of registration by REGISTER-DUMP-HOOK.
20:56:38
Fare
yup, ASDF3's ability to self-upgrade means that you can focus on stability, and people who need more features can "just" install a new ASDF in a registered path.
20:57:55
Fare
upgradability was a cost to pay, but it was paid for long ago. That part of ASDF just works, nowadays.
20:58:59
Fare
Fare, imagine the world before ASDF2, where you couldn't upgrade, but you couldn't not upgrade either. No Lisp scripting was possible without being your own system administrator.
21:00:53
Fare
These days, between ASDF, cl-launch, quicklisp, etc., scripting in Lisp is quite easy (though CL has a higher barrier to entry than most languages).
21:01:01
jackdaniel
I'm sure there is a verbose explanation of each decision you took, I don't have plans to argue with them; I simply don't like huge chunks of the end effect
21:03:01
jackdaniel
either way, thanks to a great feature of upgradability, there is no pressing need to update asdf version bundled with ecl
21:03:28
ralt
Fare: sorry, it looks like I cannot login on gitlab.common-lisp.net, so I couldn't open an issue explaning that UIOP:DUMP-IMAGE's docstring is mentioning an apparently dead function (REGISTER-DUMP-HOOK)
21:13:50
Fare
jackdaniel, yup, as long as it's stable and bug fixes get ported between the branches, your fork is most welcome and not a hindrance in any way (except for that lingering doubt about whether indeed all the bug fixes were ported).
21:14:59
Fare
jackdaniel, I remember my explanation: "it was not feature creep, it was mission creep"
21:16:04
Fare
jackdaniel, there certainly have been plenty of bugs in the 3.3 series. It looks much more stable now, though.
21:17:37
ralt
alright, this seems to work, and I'm pretty happy with it https://gitlab.com/ralt/ballish/-/blob/master/ballish.asd#L33-43
21:22:44
ralt
Fare: any thoughts on the link? does that look like the correct way to go? IOW does it fit your understanding of static-program-op as well?
21:25:19
Fare
ralt: you're doing it for all systems. Don't you want to do it just for one system? (say with an eql specializer)?
21:25:43
Fare
ralt, also, a system should be able to specify a :entry-point instead of setting it like that.
21:26:21
Fare
rpg, ralt found a bug in UIOP docstring, s/REGISTER-DUMP-HOOK/REGISTER-IMAGE-DUMP-HOOK/
21:26:24
ralt
Fare: that would make a lot of sense :) what about the idea behind closing those foreign libraries in a static-program-op?
21:27:06
ralt
the :entry-point thing is because calling (call-next-method) was failing, I assume because it's a :before, and cffi-toolchain is setting it that way in a :before. It's really my lack of Lisp knowledge, there.
21:27:27
Fare
ralt, it sounds to me like it makes sense, as long as you devise a sensible mechanism to reopen in a new properly initialized environment.
21:28:07
Fare
if you don't have a universal such mechanism, it can't become the default for cffi-toolchain.
21:31:24
luis
ralt: It's definitely weird that static-program-op leaves these libraries open when dumping.
21:32:24
ralt
rpg: slime-edit-definition is leading me to the giant asdf.lisp file, can't help with the line number, sorry
21:33:19
Fare
ralt: there is a recipe on how to do better in the asdf/README.md -- (map () 'load (asdf:input-files :monolithic-concatenate-source-op "asdf/defsystem"))
21:35:44
Fare
luis: There were ways around it. I could use `DEFUN*` and `DEFMETHOD*` and `DEFTYPE*` etc. at each statement instead of the wrapping.
21:37:09
rpg
luis -- I think this may be somewhat a problem with SLIME rather than anything else. I don't think it's WITH-UPGRADEABILITY specifically, since that's effectively just EVAL-WHEN.
21:38:59
Fare
it's eval-when, but also declaring every function notinline and other shenanigans to ensure functions can be upgraded.
21:43:20
Fare
a few of the with-upgradability shenanigans with :supersede might have been made obsolete by how ASDF3 preemptively upgrades ASDF early on then restarts if upgraded, vs ASDF2 that was trying to heroically upgrade itself mid-build (and failing in the hard cases).
21:44:41
ralt
luis: should I open a PR with essentially this small loop closing foreign-libraries, but leaving the system ones?
21:44:57
rpg
luis: Does M-. work the same in all lisp implementations? If not, are you specifically talking about SBCL?
21:46:03
luis
rpg: I'm specifically talking about SBCL. I /think/ it's SBCL's SB-INTROSPECT:FIND-DEFINITION-SOURCES-BY-NAME that's returning wrong results for defun* and defgeneric*
21:46:40
Fare
luis: not for defun* and defgeneric*, but for the specific content of an expanded eval-when.
21:47:27
rpg
luis: To debug slime, I have to figure out how to restore my configuration on top of master, including my waiting-for-more-than-six-years pull request :-P
21:48:35
fe[nl]ix
you don't need it if you have a way of loading the latest ASDF first thingg in the .rc file
21:49:14
Fare
fe[nl]ix, "the" .rc file? Good luck convincing 15 different vendors to agree on "the" rc file.
21:52:28
Fare
ralt, cffi-toolchain was supposed to run on SBCL, ECL, MKCL, CLISP -- and could support more with work. Be sure to keep all targets working...
21:53:17
rpg
luis: I don't know -- to be honest. I have been applying this patch on top of slime and running with it ever since.
21:54:46
rpg
I wonder if I meant to make it easier to switch back and forth? Right now one just gets to specify if one prefers the original slime behavior or the ELI behavior (merging history instead of replacing).
21:55:42
ralt
Fare: do you have a trick to run all of those? I know about roswell but am not particularly fan of fukamachi's work.
21:57:15
rpg
luis: WRT finding definitions, I'm not sure how SLIME + SBCL does this. Allegro had 2 halves to it -- the compiler recorded only the source file, I believe, and then there was a way of declaring definition forms that ELI would use to search the corresponding file buffer to find the input definition. I believe SBCL stores file position as well as just the filename. Does slime just jump to the file position? That would account for why it gets
21:58:38
Fare
ralt, roswell is not my style (I wrote cl-launch instead), but basically, you could use what comes with you debian or homebrew or nixpkgs distribution, to start with.
21:59:44
Fare
Then in fare-scripts, I wrote my own scripts to rebuild each of the implementations I care for from source, in the cases where I need recent modifications to the implementation (which was the case a lot when I was writing ASDF3 and discovering plenty of implementation bugs)
22:00:24
ralt
I'm surprised that MKCL is part of your implementations -- the little information I gathered from mailing lists and such showed little to no usage
22:00:26
Fare
(or writing cffi-toolchain and depending on Google-originated patches that hadn't made it to upstream SBCL yet)
22:01:20
Fare
ralt, it has at least one user. It also provided an alternative to ECL in the "linking, not dumping" style, so my code would remain properly abstracted.
22:02:32
rpg
luis: Cool. Tell you what, though -- if we can work out why it is that WITH-UPGRADEABILITY is confusing SBCL, I'm happy to work with you to help fix it. Do you think it's as simple as SBCL looking up to find the enclosing top level form when it decides what the definition's file position is?
22:04:15
Fare
rpg, my understanding of the WITH-UPGRADABILITY issue is that SBCL doesn't remember position information for individual forms (like CCL) but only for toplevel forms, so you'd need to break the with-upgradability into individual forms to have a different toplevel form per function.
22:04:45
Fare
At which point, you'd use defun*, etc., directly, except hoisting the eval-when in them, if still needed.
22:05:25
Fare
the ASDF3 upgrade strategy, as opposed to ASDF2, might remove the need for some eval-when's -- or not.
22:06:33
Fare
and/or you could further specialize the way ASDF upgrades itself from source, so that it does NOT call perform on each file (which breaks without the eval-when) but specially emulates their behavior without the CLOS infrastructure, specially, just when bootstrapping ASDF.
22:07:53
Fare
I don't see any great clean way to do that, and you'll have to be careful not to break the bundle operations.
22:09:14
Fare
OK. well the inner-forms are themselves expanded. When expanding, does SBCL propagate to the post-expansion forms the information from the pre-expansion forms?
22:15:58
rpg
Fare: I think that ACL ELI's way of doing this was better -- record the source file and then parse it at search time (with the ability to specify defining forms for things like your DEFUN*). Recording textual position is super-brittle if one interactively compiles forms (as, being someone who learned to program on a Symbolics, is something I do *all the time*).
22:16:37
rpg
Recording source file position is great for C, but for a non-batch-compiled language... meh
22:19:44
rpg
luis: BTW, the other long-deferred PR is one that fixes compilation from strings on Allegro.
22:20:18
pjb
rpg: true. However, lisp projects still contain a lot of static and rarely changing code. So this can still be useful 90% of the time even with lisp.
22:23:13
luis
rpg: slime's find-definition doesn't rely on position alone, so it deals perfectly well with chaging source files
22:23:48
rpg
luis: Does it? I find that for example, my compiler warnings start to wander around the file after a number of C-c c
22:24:32
luis
rpg: that's because you're using ACL and a 6-year-old SLIME :) I've fixed that in the meantime
22:24:36
rpg
I think my patch for ACL addresses this by spoofing file names (from the buffer file) when compiling interactively.
22:25:02
rpg
I don't think my SLIME is actually 6 years old -- just my PR. I have rebased it a few times since then.
22:26:09
luis
rpg: I've fixed a bunch of bugs with ACL warning positioning somewhere in the past 2-3 years
22:36:18
ralt
if someone has a hardcoded .so file somewhere, and loads it with cffi:load-foreign-library, does it become a system library?
22:42:49
luis
fe[nl]ix: what's the foreign-library type for? Yet another undocumented feature by young fe[nl]ix :)
22:45:17
yottabyte
question on yason and drakma: this works: (yason:parse (drakma:http-request "https://jsonplaceholder.typicode.com/posts/1" :want-stream t)) but if I don't have the :want-stream t, it fails. but I thought even without the :want-stream, a flexistream is returned
22:49:58
no-defun-allowed
yottabyte: possibly as one of the other values, but it may be closed already as Hunchentoot consumed the contents from it
22:55:24
Fare
if rpg is ok with expanding the with-upgradability into a tens of the same, then fine. IIRC, that slowed down compilation a bit, but that shouldn't matter much.
22:55:57
Fare
It's mostly, do we want to rewrite every defun into a defun*, every defgeneric, maybe every defmethod, etc.
22:56:44
rpg
Fare: If this can be automated, or if someone else does it, fine. But I don't have a weekend to spend grinding on that by hand.
22:58:21
Fare
luis: it might be that the support for :supersede t / nil is what's breaking things, but it looks like this support is not really used anymore in ASDF3, so could be done away with.
23:00:02
rpg
I haven't counted, but presumably the CHARACTER-OFFSET is to the start of the initial WITH-UPGRADEABILITY, not the nested DEFUN.
23:00:22
Fare
This were necessary when upgrading from ASDF2, something less and less relevant, and I believe not used anymore
23:01:03
luis
rpg: the character offset seems to be from the beginning of the file excluding whitespace and comments or something weird like that
23:02:25
Fare
problem: to actually test that nothing is breaking, you must identify the worst old implementation / old asdf combination.
23:06:15
yottabyte
no-defun-allowed: the return of the Drakma request isn't a string without :want-stream t. it's a Flexi-streams either way seemingly. yason can work with json strings, though
23:09:45
luis
Fare, rpg: so, understandably in retrospect, SBCL stores the position of the nearest read (i.e. non-consed) form. And that's with-upgradability.
23:11:06
rpg
luis: I guess what I don't understand is that if that's all it does, why is there even a FORM-PATH?
23:36:46
luis
Fare, rpg: mutation works. (defmacro sort-of-like-upgradability (&body body) (setf (first (first body)) 'defun*) `(progn ,@body)) not sure what the spec has to say about it, though.
23:47:49
Fare
I'm pretty sure the standard says that it's unspecified what happens if you modify a source form.
23:51:29
Fare
IIRC, the problem that the EVAL-WHEN is fixing is to handle the case where an old ASDF compiles a new one, hasn't loaded it yet, and now tries to use the CLOS functions that are super confused between the old and the new state. And then there's the case when the gf is defined in one file, but some of the methods used by ASDF are defined in the next file, but are not available anymore (and that's why we use concatenate-source-op).
0:04:33
luis
but that's not a problem for find-definition. defclass and defmethod, it's when the macro discards the defun cons and replaces it with a new defun* cons that we get into trouble
0:05:06
luis
so if defun* actually accepted the defun form as input and included it in the expansion that'd work
0:05:07
Fare
well, it will still do it, but this the toplevel read form will have only one thing in it, no problem.
0:07:55
Fare
there are historical reasons why the forms are grouped in a common eval-when, but I don't think there is any current constraint why they must remain so.
0:09:11
Fare
if the forms are separate, then no matter how confused SBCL is about the macroexpansion, it will remember the position of the toplevel form, which will happen to be the location you need.
0:10:14
Fare
it's the grouping that's an issue, not the eval-when as such. You could have individual eval-whens.
0:11:03
luis
ok, I see what you mean now. Still, find-definition would still point at with-upgradability instead of defun. It'd be a little bit less wrong, but still wrong.
0:18:08
solrize
does anyone know if there's a way to increase the max allowed recursion depth in clisp ?
0:27:12
solrize
dlowe, hmm that's the process stack, i'll try that but i didn't think that was the issue