anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
reb` has joined #commonlisp
thuna` has quit [Remote host closed the connection]
<asarch>
So, if you had a programming language 'x', with basic support for OOP and then you use that basic support to create an "API" to give full OOP feature to that language, that "API" would be a Meta-Object Protocol, right?
<asarch>
Just like Moose with Perl, right?
Brucio-61 has quit [Ping timeout: 268 seconds]
scymtym has quit [Ping timeout: 245 seconds]
<reb`>
You have a programming language. The MOP defines a set of classes and protocols that represent methods, classes, inheritance ... and you let a developer substitute different classes in order to redefine what a method or class is or how inheritance works.
<resttime>
Whether it's a lambda and a function doesn't seem to use the VOP I'm expecting but a funcall of a lambda does
<asarch>
I thought it was to improve the programming language
<resttime>
I'm just trying to add two fixnums together, and don't understand the addition isn't happening in all three cases
<resttime>
s/happening/happening the same/g
akoana has quit [Quit: leaving]
<reb`>
asarch: No, it's to provide developers with a way to modify the behavior of the language.
Brucio-61 has joined #commonlisp
skeemer has quit [Quit: Leaving]
<asarch>
Thank you, thank you very much :-)
anticomputer has quit [Ping timeout: 268 seconds]
<Bike>
resttime: i am not an expert on sbcl internals, but i'm reasonably confident that you can't just refer to lisp lexical variables in a vop generator?
anticomputer has joined #commonlisp
<Bike>
i'm kind of surprised that compiles at all
<Bike>
oh, i see, you're inheriting from fast-fixnum-binop which defines the args
<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.
<Bike>
you should probably also check #sbcl instead of here
waleee has quit [Ping timeout: 240 seconds]
asarch has quit [Quit: Leaving]
reb` has quit [Ping timeout: 244 seconds]
torbo has quit [Remote host closed the connection]
pmwals09 has quit [Ping timeout: 268 seconds]
istewart has joined #commonlisp
istewart has quit [Remote host closed the connection]
istewart has joined #commonlisp
pmwals091 has joined #commonlisp
pmwals091 has quit [Ping timeout: 240 seconds]
livoreno has joined #commonlisp
livoreno has quit [Ping timeout: 268 seconds]
rainthree has joined #commonlisp
pmwals09 has joined #commonlisp
causal has quit [Quit: WeeChat 3.6]
pmwals09 has quit [Ping timeout: 245 seconds]
livoreno has joined #commonlisp
istewart has quit [Ping timeout: 255 seconds]
istewart has joined #commonlisp
alvaro121_ has quit [Ping timeout: 268 seconds]
gateway2000 has quit [Remote host closed the connection]
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
_cymew_ has joined #commonlisp
santiagopim has quit [Remote host closed the connection]
karlosz has joined #commonlisp
livoreno has quit [Ping timeout: 268 seconds]
thuna` has joined #commonlisp
livoreno has joined #commonlisp
karlosz has quit [Ping timeout: 268 seconds]
MajorBiscuit has quit [Ping timeout: 245 seconds]
MajorBiscuit has joined #commonlisp
knobo has joined #commonlisp
cel7t has quit [Quit: You have been kicked for being idle]
_cymew_ has quit [Ping timeout: 268 seconds]
knobo has quit [Quit: Client closed]
son0p has joined #commonlisp
chip2n has quit [Ping timeout: 268 seconds]
gateway2000 has quit [Read error: Connection reset by peer]
gateway2000 has joined #commonlisp
jmdaemon has quit [Ping timeout: 268 seconds]
ebrasca has joined #commonlisp
random-nick has joined #commonlisp
gateway2000 has quit [Remote host closed the connection]
gateway2000 has joined #commonlisp
thuna` has quit [Ping timeout: 245 seconds]
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
thuna` has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
scymtym has joined #commonlisp
waleee has joined #commonlisp
Furor has quit [Ping timeout: 245 seconds]
Colere has joined #commonlisp
Furor has joined #commonlisp
dBc has joined #commonlisp
Colere has quit [Ping timeout: 245 seconds]
<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.
SR-71 has quit [Ping timeout: 244 seconds]
SR-71 has joined #commonlisp
<hexology>
nice drmeister! i use jupyterlab for data science all the time, seems like a good match for the common lisp "interactive editing" workflow
<drmeister>
hexology: We are using a lot of widgets as well for molecular visualization, xyplots, drawing molecules etc.
jeosol has quit [Quit: Client closed]
<hexology>
nice. i'd love to do some data science work in common lisp
<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)
<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
qiduo has joined #commonlisp
lanu has quit [Ping timeout: 252 seconds]
<hexology>
what's the cffi equivalent of C `&s` for some `char *s`?
<hexology>
e.g. there's mem-ref to dereference, but i want to "enreference" so to speak
<jackdaniel>
mem-aptr maybe?
<hexology>
oh yep probably, let me see
<hexology>
nope, got a memory integrity error from that one
<hexology>
i'm trying to call `strtod(s, &s)`
<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
<Bike>
so there's no way to get a pointer to an object - you ought to have a pointer already
<Bike>
maybe you could explain what you are doing in more detail?
<Bike>
like do you have a lisp string or c string or what
<Bike>
i think the answer will be with-foreign-object a (:pointer :char) though
<hexology>
i assume i'll be starting from a lisp string. i was using WITH-FOREIGN-STRING
<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
<Bike>
it is
<Bike>
but what i'm saying is that when you do "char *s" in C, there will be an implicit char**, more or less
<Bike>
in cffi you have to be a little more explicit
<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)
<hexology>
hm, okay. is with-foreign-string not sufficient here?
<Bike>
with-foreign-string allocates space for a string, but what you want is space for a pointer to a string.
xaotuk01 has quit [Quit: WeeChat 3.4.1]
<hexology>
i see. there's also with-foreign-pointer, is that less general and not useful here?
<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.
<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
<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?
<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?
<Bike>
Yes on the first, no on the second
<Bike>
you don't need to fill it at all. strtod writes into it, it doesn't read
<Bike>
"it" meaning the char** parameter
<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
<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
<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)
<Bike>
end-str is a pointer to a string, not a string, so you're not filling it with bytes or anything
<hexology>
right, let me try that
<Bike>
this would be like the C "char** end_str; *end_str = str; while (true) { ... strtod(*end_str, end_str); ... }"
Furor is now known as Colere
<hexology>
aha, the c equivalent helps
<hexology>
now i need to figure out how to use call these things properly w/ cffi :)
ebrasca has quit [Remote host closed the connection]
ebrasca has joined #commonlisp
<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)
<hexology>
ah i just need to quote it '
<Bike>
oops, my bad
<hexology>
no i was looking in the docs and it isn't explained there either
<hexology>
never considered putting : at the start of a function name
cage has joined #commonlisp
<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 ,)
<hexology>
well it works! but the result is wrong :) thanks for the assistance w/ the pointers though
<Bike>
no problem
frgo has joined #commonlisp
waleee has quit [Quit: WeeChat 3.6]
razetime has joined #commonlisp
<hexology>
maybe i'll ask on stackoverflow, i doubt i'm the only person to struggle w/ things like this
waleee has joined #commonlisp
jeosol has joined #commonlisp
jeosol has quit [Quit: Client closed]
waleee has quit [Ping timeout: 240 seconds]
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
rainthree3 has joined #commonlisp
rainthree has quit [Read error: Connection reset by peer]
overclucker has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
overclucker has joined #commonlisp
razetime has quit [Ping timeout: 245 seconds]
karlosz has joined #commonlisp
_cymew_ has joined #commonlisp
razetime has joined #commonlisp
irfan has quit [Quit: leaving]
waleee has joined #commonlisp
azimut has quit [Remote host closed the connection]
aartaka has joined #commonlisp
azimut has joined #commonlisp
dBc has quit [Quit: leaving]
NotThatRPG_away has quit [Read error: Connection reset by peer]
_cymew_ has quit [Ping timeout: 252 seconds]
NotThatRPG has joined #commonlisp
razetime has quit [Remote host closed the connection]
ebrasca has quit [Remote host closed the connection]
ebrasca has joined #commonlisp
morganw has joined #commonlisp
ebrasca has quit [Remote host closed the connection]
ebrasca has joined #commonlisp
rainthree33 has joined #commonlisp
rainthree3 has quit [Read error: Connection reset by peer]
orestarod has joined #commonlisp
karlosz71 has joined #commonlisp
karlosz71 has quit [Client Quit]
MajorBiscuit has quit [Ping timeout: 245 seconds]
Catie has quit [Remote host closed the connection]
Catie has joined #commonlisp
Catie has quit [Remote host closed the connection]
Catie has joined #commonlisp
euandreh has quit [Quit: WeeChat 3.6]
Dynom_ has joined #commonlisp
Dynom_ is now known as Guest8760
deadmarshal has quit [Remote host closed the connection]
dirtcastle has quit [Remote host closed the connection]
karlosz has quit [Ping timeout: 252 seconds]
rainthree33 has quit [Ping timeout: 252 seconds]
rainthree has joined #commonlisp
deadmarshal has joined #commonlisp
vassenn has joined #commonlisp
dirtcastle has joined #commonlisp
Catie has quit [Ping timeout: 244 seconds]
Lord_of_Life_ has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
azimut has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
azimut has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 268 seconds]
Lord_of_Life_ is now known as Lord_of_Life
igemnace has quit [Remote host closed the connection]
azimut has quit [Remote host closed the connection]
karlosz has joined #commonlisp
azimut has joined #commonlisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #commonlisp
vassenn has quit [Quit: Good bye!]
causal has joined #commonlisp
_cymew_ has joined #commonlisp
tyson2 has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
jeosol has joined #commonlisp
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
azimut has quit [Ping timeout: 268 seconds]
azimut has joined #commonlisp
Catie has joined #commonlisp
<hexology>
i have a variable (type (integer 0 *) n) and i'm calling (incf x) but i keep getting compiler notes that sbcl is unable to "open-code float conversion in mixed numeric operation" because it apparently doesn't understand the type of the `1` in (+ 1 n). i have tried all manner of contortions like (+ (the (integer * 0) 1) n) but i keep getting the same compiler note. if only for my understanding: what the heck is going on here, and how do i convince
<hexology>
sbcl that i am just trying to increment an unsigned integer?
<hexology>
sorry, (incf n) not (incf x)
<White_Flame>
it can't determine fixnum vs bignum
<White_Flame>
and are you sure that your incf is the same variable?
<Bike>
the notes are kind of dumb sometimes. what sbcl does is try every possible transformation it knows for (+ a b) and tells you if they don't apply. and that includes the float ones.
<White_Flame>
(incf x) vs (incf n)
<Bike>
but yeah the problem with optimizing that is that sbcl can't do much with just (integer 0 *) in that circumstance.
<hexology>
White_Flame: the 'x' was a typo, sorry
<hexology>
https://bpa.st/A7CQ here's my actual code & the actual compiler note
<hexology>
Bike: i see, so it's telling me everything it tried along the way, not necessarily that it ultimately found nothing?
<Bike>
no, if it found a transformation it wouldn't tell you anything.
<hexology>
i see
<hexology>
i don't know why it's even trying to "open-code a float conversion", i'm just working with ints in this case
<Bike>
like i said, it's trying every possible way to get rid of a call to +. you can see it messing around with complexes too
<Bike>
it sees (+ 1 n) and goes, okay, can i make this into (internal::float+ (float 1) n)? no, because n isn't a float. i'd better tell the user this in case they could declare n to be a float
<Bike>
which in this case is obviously (to you and i) not going to happen, but sbcl is not smart enough to realize that since you declared the thing to be an integer, you're probably not going to want it to be a float
<hexology>
i see. i guess that means sbcl not have some fancy optimized operation for incrementing an integer? (it probably is not important for performance anyway, in this code)
<Bike>
well again, in this case all it knows is that n is a nonnegative integer
<Bike>
that means it could be a bignum, which is a big ol multiprecision integer in memory that can't really be dealt with very quickly
<Bike>
if it knew n could fit in a machine word, like a fixnum, it would just do a machine addition, but it doesn't, so it won't
<hexology>
hm. fwiw i get the same compiler notes if i declare it to be fixnum rather than (integer 0 *)
<hexology>
is it because incf could overflow most-positive-fixnum?
<Bike>
you mean doing (type fixnum n-blank), not just using the? right. i think what happens there is that sbcl doesn't believe you, i.e. doesn't believe that (+ n-blank 1) will always be a fixnum
<Bike>
yes
<Bike>
because if it _did_ believe you, and you were mistaken, your program would crash badly
<hexology>
i see, i assumed it would just overflow but i guess that's not a good assumption
<Bike>
if it wrapped around to 0 that could be very weird for your program, since that's violating what + usually does
tyson2 has quit [Remote host closed the connection]
<Bike>
however if you tell it to wrap, like by doing (mod (+ 1 n-blank) ...), that's another story
<Bike>
not gonna lie, arbitrary precision integers make optimization tricky sometimes.
<hexology>
i see. i agree that implicitly wrapping around isn't good (and isn't what i want), but 99.999% of the time this value will actually be in fixnum range. i was about to ask, is there a standard way to handle this? like creating a bignum variable but setting it aside unless you are in danger of overflowing?
<pjb>
hexology: and what occurs if you remove type declarations?
<White_Flame>
handle what? the default case handles the 0.001% of the time where bignums are needed
<Bike>
honestly what most people do is just make it use fixnum arithmetic anyway, which on 64 bit sbcl will go just dandy up until you give it a file with four quintillion lines
<Bike>
in your particular case, i might just remove the type declaration, since i expect fixnum arithmetic is the least of your problems here optimization wise
<Bike>
slowest part will be I/O, next slowest will be the error signals
<hexology>
yeah this definitely isn't a bottleneck at all here
<hexology>
but for the sake of the exercise, how do i convince it that i definitely want to use fixnum arithmetic and that i don't care what happens if i overflow?
<White_Flame>
(the fixnum (+ (the fixnum a) 1))
<White_Flame>
or if A is declared fixnum, you don't need its THE
<Bike>
does that work? i thought that was what hexology was trying.
<White_Flame>
now, the implementation is free to blow up if the THE is violated, I believe
<hexology>
maybe i need both THE's
<White_Flame>
I didn't think hexology was using the outer THE
<White_Flame>
for the result
<White_Flame>
and with INCF, that wouldn't work
<White_Flame>
if you declared a var fixnum, and then INCF'd it, then with safety off would probably just do fixnum math
<Bike>
the implementation is indeed free to blow up if THE is violated, but that would be rude of it, and i think sbcl checks THEs except on low safety
<hexology>
(setq n-blank (the fixnum (+ (the fixnum 1) n-blank))) like this? i hadn't tried that, but i get the same compiler notes if i do that
<Bike>
although i guess it just compile it to use fixnum arithmetic and then cheeck for overflow
<Bike>
it could*
<White_Flame>
hexology: you don't need to declare 1 as fixnum
<Bike>
yeah don't worry, sbcl knows what a constant is.
<White_Flame>
but it needs to know that both the inputs and the results are declared fixnum
<hexology>
aha, this worked, thank you: (setq n-blank (the fixnum (+ 1 (the fixnum n-blank))))
<hexology>
i had misread your message showing the double-THE
<Bike>
ah, k.
<pjb>
hexology: (setq n-blank (the fixnum (+ 1 (the fixnum n-blank)))) is wrong.
<pjb>
hexology: (setq n-blank (if (< n-blank most-positive-fixnum) (the fixnum (+ 1 (the (integer 0 #.(1- most-positive-fixnum)) n-blank))) (the integer (1+ the integer n-blank)))))
<hexology>
that would be the "safe" version?
<pjb>
Types are the Event Horizon of CL.
<pjb>
hexology: yes.
<hexology>
does it matter if you write (< n-blank most-positive-fixnum) or (< n-blank #.most-positive-fixnum) ?
<Bike>
Not really
<White_Flame>
it's a constant, so it _shouldn't_ matter
<White_Flame>
in a really dumb implementation it might matter
<White_Flame>
like, an interpreter-only implementation
<Bike>
The latter means the reader looks up the value of most-positive-fixnum and sticks that in instead of the symbol
<Bike>
but even the very basic compiler i wrote in four hours the other day is smart enough to compile constants as constants, so don't worry about it
<aeth>
White_Flame: what about an implementation that allows for compatibility of its compiled fasls between versions? And the version changes the constant.
<Bike>
then the latter version will break your code
<aeth>
ofc the bug still might show up because it's a constant
<pjb>
hexology: but THE doesn't evaluate the type specifier! So it must be composed at read-time.
<aeth>
9 times out of ten when I use #. I later get rid of it with a deftype, a defmacro, etc.
azimut_ has joined #commonlisp
azimut has quit [Ping timeout: 268 seconds]
<jcowan>
There are two possible interpretations of declarations: "I declare that this value is a fixnum even if sometimes it isn't, and I allow you to send me straight to Hell if it isn't" and "I declare that this is value is a fixnum, and if it isn't, I want you to signal a condition."
<jcowan>
Which you get depends on your Lisp implementation and the optimization settings.
<Bike>
sbcl also offers "i declare that this is a fixnum and i'd appreciate if you checked but like don't worry too much man"
tyson2 has joined #commonlisp
<Bike>
i would also like to implement "I declare that this is a fixnum and if you actually use that information signal a condition, but otherwise who cares" but that's pretty involved to do
<Bike>
signal a condition if it's not*
<aeth>
I think it comes down to there being two kinds of types (at least in CL): types-for-reliability and types-for-performance
<hexology>
i'd love to read some kind of extended guide on this topic
<hexology>
even if it is the event horizon
<Bike>
sbcl documents what it does in its manual, or do you mean like, a general introduction to how compilers can use these kinds of types
<hexology>
and again, i'm sure this is not a bottleneck in most applications unless it's some kind of numerical simulation that doesn't call out to some foreign routine
<White_Flame>
a lot of my microptimization is eliminating function calls and taking advantage of tail calls
<Shinmera>
float traps don't impact performance of code that doesn't trap to begin with.
<aeth>
hexology, when referring to THE and the type system, said "unless it's some kind of numerical simulation that doesn't call out to some foreign routine" then type declarations likely won't be the bottleneck
<aeth>
but a numerical simulation is likely going to use floating point, which is going to be way easier to deal with in the type system than integers, which have to stay within the defined range (x + y will always stay a float, but won't always stay in the defined integer range)
<aeth>
with the added caveat that turning off float traps is probably as important as declaring the type
<aeth>
I suppose it's possible that the simulation would use fixed point instead, though.
<hexology>
that all makes sense
MajorBiscuit has joined #commonlisp
<NotThatRPG>
jcowan: I believe that the spec only makes the first of the two interpretations canonical, but I also believe it leaves the way open for implementations to use the second.
jmd_ has joined #commonlisp
<jcowan>
It says the consequences are undefined, which certainly *allows* a condition to be signaled.
jmdaemon has quit [Ping timeout: 252 seconds]
<jcowan>
But yes.
<jcowan>
Of course, with NaN-boxing there is no need to unbox double-floats, as they are already unboxed.
Guest8760 has quit [Quit: WeeChat 3.6]
<hexology>
re: floats, i'm running into a similar issue with sbcl not being convinced that in my *particular* case, my input to sqrt is always positive and so should sqrt should always return a real number
<hexology>
so i definitely think there's something worth writing about here, if there's expert knowledge to be written down
<Bike>
float traps are a dynamic thing, though
<Bike>
i mean, you can compile the code in different ways if the compiler is allowed to make some assumptions about the floating point environment, but that's not quite the same
<Bike>
hexology: i'm not sure what there would be to write down there beyond that you'll have to declare the input positive... what's going on?
<Shinmera>
(sqrt (the (single-float 0f0) ..))
<Bike>
i have some personal notes on CL arithmetic optimization strategies for my own purposes, but they're pretty sparse and not really directed at programmers
<Bike>
and hopefully i'll be able to break out an interval arithmetic library at some point
<Bike>
and of course i need to do the compiler conditions thing too...
waleee has quit [Ping timeout: 244 seconds]
akoana has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 244 seconds]
MajorBiscuit has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 240 seconds]
MajorBiscuit has joined #commonlisp
azimut_ has quit [Read error: Connection reset by peer]
anticomputer has quit [Remote host closed the connection]
azimut has joined #commonlisp
anticomputer has joined #commonlisp
thuna` has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 268 seconds]
MajorBiscuit has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 268 seconds]
pve has quit [Quit: leaving]
NotThatRPG has quit [Read error: Connection reset by peer]
NotThatRPG has joined #commonlisp
orestarod has quit [Ping timeout: 268 seconds]
Lycurgus has joined #commonlisp
<Lycurgus>
in looking for a state machine thing in cl, i couldn seem to do better than cl-monad-macros