libera/#commonlisp - IRC Chatlog
Search
1:59:40
Bike
well, add-vop seems to be returning the first argument in the first two cases. maybe you have to do something else to ensure that the result of add actually gets into the result register.
7:21:40
jackdaniel
i.e https://github.com/fredokun/cl-jupyter (I'm not sure whether this is what they use)
7:22:24
jackdaniel
https://github.com/yitzchak/common-lisp-jupyter/ this seems to be a more likely thing that they use given the list of contributors
13:15:32
drmeister
We use jupyterlab all the time. Use https://github.com/yitzchak/common-lisp-jupyter/ it is way more advanced and updated. I've been supporting development of it for more than a year.
13:26:22
hexology
nice drmeister! i use jupyterlab for data science all the time, seems like a good match for the common lisp "interactive editing" workflow
13:29:07
drmeister
hexology: We are using a lot of widgets as well for molecular visualization, xyplots, drawing molecules etc.
13:29:45
hexology
i don't know much about molecules but i've been working with a lot of geospatial data recently (a new area for me)
13:30:07
hexology
seems like a lot of the heavy lifting is done by c libraries and tools like proj, so i imagine it's "only" a cffi wrapper away from being available in lisp
13:39:31
Bike
cffi is more explicit about pointers than C is. for example when you do the equivalent to declaring an auto variable a la "char s;", you'd do with-foreign-object, which gives you a pointer to s
13:41:54
hexology
this seems to be perfectly valid C as far as i've read the gnu stdlib docs, and i want to do the same from lisp: https://tio.run/##VU5LCsIwFNznFI@K0toPalUIbb2GG0Fi0s@DmJQkulB6dWOKKzczMD@G51wy1Xu/QMXlQ7RQWyck3orhRP401LNEUDm4M1TxU6NI4E0A@MAMrC00EG13ZbE/AKW0oFEVvE4biC2@2qsDDIlNFaiGMlCa/uoAowmrXRwtN8Wxu6goA@uM0yK2GaxsksxDE5mI9x/eSdZbn4dDDafU52cmZcCxFUw55F8
13:42:22
Bike
but what i'm saying is that when you do "char *s" in C, there will be an implicit char**, more or less
13:42:45
hexology
(i'm not 100% sure if it's considered correct to re-use the same pointer, or if it just happens to work by coincidence)
13:44:29
Bike
with-foreign-string allocates space for a string, but what you want is space for a pointer to a string.
13:45:34
hexology
i see. there's also with-foreign-pointer, is that less general and not useful here?
13:46:12
Bike
that would also work, but you give it a raw size in bytes. with-foreign-object will figure out the correct size based on the type.
13:48:01
Bike
another way of thinking about this is that in C, & is not a "real" runtime operation. If you do like, "*s = x" that will be a memory write at runtime, and "x = *s" will be a memory read. but & does not have a runtime equivalent - it's just telling the compiler to use the pointer it's already arranged
13:48:40
hexology
right, that makes sense. it can see at compile time that a pointer is needed, and it can stack-allocate the space for the pointer, right?
13:49:20
hexology
so i would use with-foreign-object of type (:pointer :char) and size being the size in bytes of my lisp string, then i'd (setf (mem-aref ...) ...) repeatedly to fill it with the bytes from my lisp string?
13:51:02
hexology
oh, i had wanted to use the same (non-const) string in the 1st and 2nd arguments, so i could loop over and over until the end of the string
13:52:38
hexology
although conceptually (and my weakness with c is on display here) i guess the string can be const but the pointer can be non-const? gah
13:52:42
Bike
okay. in that case i think what you would do is allocate the string and a :pointer :char end-str, then do one (setf (mem-ref end-str (:pointer :char)) str), then in the loop do (strtod (mem-ref end-str (:pointer :char)) end-str)
13:53:00
Bike
end-str is a pointer to a string, not a string, so you're not filling it with bytes or anything