freenode/lisp - IRC Chatlog
Search
15:02:13
jackdaniel
Bike: equal could do that too (under the hood, after realizing that both are strings)
15:02:54
jmercouris
but I think you would be writing something really complex if equal had to realize you were slicing
15:10:20
beach
And yes, string= is more specific, so it falls under the rule that one should always use the more specific construct that will have the desired effect.
15:11:21
pfdietz
One could imagine a sufficiently smart compiler that would transform (equal (subseq s ...) (subseq s2 ...)) into a call to string=, but I don't think any existing compilers do that.
15:11:32
beach
But Common Lisp is not about minimalism. It's about giving the programmer a good toolbox.
15:11:39
jmercouris
pfdietz: that's what I was hinting at with my comment that jackdaniel did not understand
15:35:17
jackdaniel
jmercouris: I've merely corrected you from implying I've said something that I did not. "sufficiently smart compilers" was a fad years before I've started working with common lisp
16:41:03
jmercouris
jackdaniel: I merely corrected you from implying that I implied that you said something which you didn’t
17:13:00
dbotton
Is there documentation / some sort of tutorial on the best way today to handle foreign C code. Seems there are a few paths when last looked.
17:13:58
jackdaniel
cffi is a usual goto answer (it also superseded uffi and provides compatibility layer with it)
17:14:44
jackdaniel
there is also cffi-groveller to generate bindings automatically (cl-autowrap seems to have a similar purpose) - I've never used grovellers though
17:15:06
jackdaniel
cffi has a documentation; when unsure I usually look at tests in the source code
17:16:54
jackdaniel
on ecl there is a special flag to make things faster (by writing inlined calls) it is disabled by default because there is no good translation between pointer types between ecl and cffi (something possible to fix with extra effort)
17:17:29
jackdaniel
basically it boils down to the fact, that modern C compilers won't accept a declaration void*(*)() to a function int*(*)()
17:18:22
dbotton
Would be good to use but don't want for this project anything that is implementation specific
17:19:16
jackdaniel
#+ecl (setf cffi::*that-flag-I-don-t-rememmber-name-of* :static) or something in this spirit
17:20:26
jackdaniel
ecl can do it three ways: dynamic ffi, dlopen ffi and static ffi - cffi implements all three
20:02:52
npfaro
If I have an array with a fill pointer at a certain spot (with more room past the fill pointer) how do I copy another array into where the fill pointer is, advancing the fill pointer
20:05:09
Bike
i would manually increment the fill pointer and then use replace to do the copy, i think.
20:05:53
Bike
(let ((old-fp (fill-pointer dest))) (incf (fill-pointer dest) (length source)) (replace dest source :start1 old-fp))
20:50:52
pfdietz
I had to manually adjust the array; just increasing the fill-pointer doesn't extend the array.
20:51:57
npfaro`
pfdietz: if you were replying to me (i disconnected for a bit sorry) then I already allocated the array to be big enough from the start
20:56:14
VincentVega
kind of silly i haven't figured this one out yet, but in sly/slime how do you go to the line/function where an error occurs (when loading a project)? Looking at the backtrace every time is proving to be a bit of a hassle.
21:00:14
Xach
Oh, like, to skip irrelevant-to-you frames and get to something that might be more meaningful?
21:04:18
Xach
if it's really throwaway i try to work with */**/***, and i'm learning sly's #vN history syntax too.
0:15:10
travv0
you sure that's what's written to the stream and not just your repl printing the return value?