libera/#commonlisp - IRC Chatlog
Search
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
13:57:02
Bike
this would be like the C "char** end_str; *end_str = str; while (true) { ... strtod(*end_str, end_str); ... }"
14:03:48
hexology
hm, what's the right syntax for using (:pointer ...) in with-foreign-object? it says "The function :POINTER is undefined." when i do: (with-foreign-object (s1 (:pointer :char)) nil)
14:07:57
jackdaniel
we should make an addition to the standard that states, that like keywords are self-evaluating, a similar thing happens to functions in the keyword package ,)
14:08:07
hexology
well it works! but the result is wrong :) thanks for the assistance w/ the pointers though
14:25:42
hexology
maybe i'll ask on stackoverflow, i doubt i'm the only person to struggle w/ things like this