<hayley>
mzan: w.r.t day2b, (ecase cmd ('forward ...)) will so happen to work, because that is equivalent to (ecase cmd ((quote forward) ...)). The "cases" in each clause are written using a list of values, and none are evaluated.
<rotateq>
nice
<hayley>
There's also a few dangling parens which are distracting admittedly.
<mzan>
hayley: are you saying that the "(ecase cmd ('forward ..))" is an error?
<hayley>
It's not an error per se, but it is not doing what you expect.
<hayley>
e.g. (ecase cmd ((+ 2 2) (print "blah")) doesn't print "blah" if cmd is 4.
<mzan>
I were thinking to this: "(ecase cmd ('forward 10))" is equivalent to "(cond ((eq cmd 'forward) 10))"
<mzan>
BTW ``(ecase cmd ("forward" 10))`` is error-prone because only symbols are singletone values (i.e. correctly comparable by "eq"), while strings are distinct references. So "case" in CL is rather error-prone.
<mzan>
THe value semantic of Haskell is less tricky sometime.
<Xach>
mzan: are you quoting something re: case?
<Xach>
I don't think it's correct to say CASE is error-prone.
<Xach>
Also, CASE does not use EQ.
Krystof has quit [Ping timeout: 252 seconds]
<mzan>
I expanded "case" and yes it is doing something of completely unexpected to me
<mzan>
@Xach: yes you are right. "case" is not error-prone, because I will avoid to use it right-now :-)
<rotateq>
as i saw upto now CASE uses EQL
<rotateq>
and from what the other people said, that's why #. can sometimes be useful in a CASE expression when you want to match on parameters that are defined in the toplevel for example
<mzan>
Probably I also not understanding correctly the usage of ``'forward``. Probably I'm using quoting, but it is better using some other keyword-like symbol.
<rotateq>
when you would use :forward that would match as expected
<mzan>
yes
<mzan>
I thought that ":key" was only/mainly used for ":key value"
<mzan>
and not standalone
igemnace has quit [Remote host closed the connection]
<rotateq>
keywords can be very useful and expressive on their own
<hayley>
And having "value" or "reference" semantics does not make the problem of defining equality much simpler.
<_death>
if you are prone to making errors when using case, use cond, until you learn how to use case without making errors
<mzan>
To be fair, if I expanded my "ecase" usage, I would notice immediately the problem. So if I'm in doubt with some complex macro, I can double-check in CL.
<mzan>
hayley: ok but in CL I had to remember that numbers, symbols are values, while strings are references.
<mzan>
To be fair in CL the majority of things are references, so it is not difficult to remember.
taiju has joined #commonlisp
<hayley>
Not really. Symbols are also mutable objects.
<mzan>
To be fair, I don't know CL :-)
<rotateq>
i thought you studied CLOS ^^
<mzan>
A little
<hayley>
And reference equality on strings can be useful, though the most common use is as a quick test before comparing characters.
<hayley>
i.e. (defun string= (x y) (or (eq x y) (and (= (length x) (length y)) (every #'char= x y)))) to a zeroth approximation.
dra_ has joined #commonlisp
dra has quit [Ping timeout: 252 seconds]
<Alfr>
hayley, your string= also accepts other things: (string= (list #\a #\b) (list #\a #\b)) => T
<hayley>
Hence "to a zeroth approximation".
<Alfr>
I don't know what a zeroth approximation means here.
<hayley>
I'm just illustrating using EQ to check before performing a slower structural test.
<Alfr>
Understood.
<mzan>
hayley: yes yes. THe choices of CL make sense. It is only fun that after programming too much in Haskell (a pure FP) one like me expect that a string is a value inside "case", while obviously in a programming language like CL (that is also a system-level PL), the best choice is a reference. And as said, the majority of things in CL are references.
<rotateq>
at some point Simon Peyton-Jones called Haskell the most imperative programming language :D
<georgy>
the best imperative programming language in the world, IIRC :)
<mzan>
the most funny quote about Haskell is: the Haskell motto is "avoid success at all costs" but it is not clear if it is "avoid $ success at all costs" or "avoid success $ at all costs" :-)
<rotateq>
georgy: höhö
<_death>
mzan: the choices of whether to evaluate keys or not, or whether to compare using equal or eql are not wrong, and throughout Lisp history there have been many variations.. for example Lisp Machine Lisp had a SELECTQ operator that's like CASE (the q is for "quoting", i.e. not evaluating.. there was also a CASEQ alias), but also a SELECT operator that did evaluate the keys.. it also had a SELECTOR operator which allowed you to specify the
<_death>
comparison function.. it also had a few other similar operators
<_death>
mzan: so every Lisp makes some choices.. what's nice is that Lisp lets you come up with your own operators if you need something else
<_death>
I meant "not wrong or right"
Guest74 has joined #commonlisp
dra_ has quit [Ping timeout: 268 seconds]
Oladon has joined #commonlisp
<mzan>
_death: I'm not criticizing CL. It is a very old PL, and it is still relevant. But if you study Eiffel, during the design of the language, the creator tried to avoid error-prone features and concepts. If your life depends on some code written in CL or Eiffel, you would like the fact that the programmer can not confuse an (case (nil ...)) with (case ((nil) ...)).
<mzan>
Some CL features are more error-prone than in other languages.
<mzan>
But it is ok.
<_death>
mzan: in my experience, you can make a mess with every language.. and you will, even NASA does
<mzan>
yes
<rotateq>
that's with contracts, i see those as a thing similar to dependent types
<_death>
mzan: for example, you keep using the term "error-prone", but it means "in the habit of making errors".. so that's better applied to a person than to an operator
<mzan>
changes nothing. The sense remain the same.
<georgy>
to be fair I'm not a huge fan of "we have 4 equality functions, and we hope you can guess what we meant"
<_death>
mzan: though Don Norman did elaborate on the concept of "affordance".. obviously some features are easier to misuse than others
<georgy>
five if you count =
<_death>
mzan: but you are not really in a good position to judge whether something is misused or not, because you are a newbie
<rotateq>
georgy: different types of equality :)
<_death>
mzan: I remember some people did have an issue with (nil) and ().. and these people decided to always use a list to specify keys
<_death>
mzan: but personally it's not an issue I see often in the wild
<mzan>
yes, I agree
<mzan>
But ...
<mzan>
there are modern PL were you can not overrides variables names in the lexical-scope. Doing this, they are less error-prone.
<_death>
it's more common to see some code that has 'foo keys though.. but my guess is that it's a result of the person not understanding CASE, rather than a typo or a thinko
<mzan>
In case of "case", there is also a mine problem. I considered case a friendly instruction, similar to Haskell or "switch", but it was a false friend: in reality it has a different semantic.
<mzan>
It is a mine problem, and not of the instruction.
<mzan>
Now I know, and zero problem.
<mzan>
Ah: thanks for the hint!!!
<hayley>
case does not evaluate patterns in Haskell. You can't do "case 4 of 2 + 2 -> ..." or approximate (I forget the exact syntax of ML languages).
<mzan>
In Haskell I used case in an error-prone way to... :_)
<mzan>
hayley: something like ``let x = 5 in case y of x -> "I'm 5"``
jstoddard has quit [Quit: Going home]
<mzan>
but "case .. of x" introduces a new variable "x" that overrides the "let x = 5" one.
<mzan>
In a PL where it was not possible to override variables, the problem will be signaled.
<rotateq>
and switch-case is just ridicolous and bad design
<georgy>
case in haskell is used for matching constructors and deconstructing data. for things like 2 + 2 multiway if could be used. or guards
<rotateq>
mzan: in CASE you can even use an OR expression as this is a macro and not a function
<mzan>
georgy: yes. But in my "stupid mind", ``case y of x -> ..." were equal to ``if y == x then ...``
<mzan>
Instead ``case y of x -> ...`` is equavalent to ``x match y`` so ``x become y``.
<georgy>
yeah, case y of x -> will match any y and assign it to x
<_death>
I don't understand why you keep comparing CL to Haskell though.. this is a recipe for failure, because when you learn a language you should ditch such "friends" and learn it as it is.. it's a kind of "suspension of disbelief"
king has joined #commonlisp
<rotateq>
and everything new should be for also widening the horizont :)
kakuhen has joined #commonlisp
<mzan>
_death: I also cited Eiffel.
<_death>
unfortunately many people are stuck on one side of the static/dynamic divide and just can't reconcile with the other.. this creates a lot of noise
<mzan>
IN my case, I compared valued semantic of Haskell with reference semantic of CL. So the type system in my case was not cited. But your point remain valid.
<mzan>
And I cited other examples of constructs, that can be more or less error-prone. Obviously if you are a good programmer, you can avoid any problem.
<_death>
mzan: but your argument is based on an abstract theory you have about "error-prone", not empirical evidence.. in practice Lisps have been (are) used by NASA, Boeing, etc.. so was (is) assembly.. so maybe it's more about process, less about language features.. and if you can't afford such a process, maybe you don't need such guarantees anyway.. besides, it's not the only measure
<mzan>
And I have personal problems with "case" in every language :-) When I read "case", I see "==" everywhere :-)
<mzan>
_death: yes sorry. "case" in CL is perfect!
<_death>
mzan: of course it's perfect
<rotateq>
even this "==" isn't very accurate, like "=" for assignment
igemnace has joined #commonlisp
<rotateq>
be it as it is
<mzan>
AdventOfCase :-)
<_death>
mzan: personally, my life depends much more on CL than Eiffel btw ;)
<rotateq>
i think not only yours
<mzan>
_death: I'm not interested to discuss about life-dependency of an user called _death :-)
karlosz has joined #commonlisp
<dre>
mzan, I'm on day 3 as well
<_death>
once, sbcl even babysitted my kitten
<dre>
but i have no time to complete the rest of aoc haha
<dre>
day 7 is apparently easy
<mzan>
I read day4 and I have a plan
<dre>
I implemented day4 but realised that i misread the problem :P
<dre>
when bingo is called, you sum all the numbers that aren't marked. I thought you sum the winning row.
<mzan>
dre: you can always adopt my behaviour/attitude: you misread the problem because CL is error-prone! :-)
karlosz has quit [Ping timeout: 265 seconds]
<rotateq>
that's what the powerful condition system is for
<mzan>
unwind the specification
<mzan>
I go to bed, but I want to add this observation (_death will kill me): ``case`` is error-prone in Lisp, because it is the only Lisp macro that accepts too few parens! :-)
<White_Flame>
and to correct the correctly diagnosed newbie root cause, this is not an issue with CASE, but with the NIL/() equivalence
<rotateq>
the parentheses aren't even really there :P
<etimmons>
fe[nl]ix: ^ (sorry it's a screenshot. I have a crazy setup needed to access that machine at the moment)
<fe[nl]ix>
etimmons: can you run a few more commands ?
<etimmons>
Also note that there are no libssl.* (or libcrypto.*) in /usr/lib
<etimmons>
They live Somewhere Else now
<etimmons>
Sure
<ldb>
yes, is is linked by some magic settings since system integrity support
<fe[nl]ix>
echo 'int main(){}' > test.c ; cc -o test test.c -lssl ; otool -L test
<ldb>
ld: library not found for -lssl
<ldb>
seems Cook doesn't want us to use the openssl lib shipped with mac
<etimmons>
same. Note I do not have homebrew (or fink or macports or ...) installed on here
<ldb>
neither I do
<fe[nl]ix>
I was just about to ask that
<fe[nl]ix>
how does Xcode link against openssl then ?
<fe[nl]ix>
di you have Xcode installed ?
<fe[nl]ix>
maybe that will install libssl.dylib
<ldb>
no, and I probably won't want to install that, because that's huge
<fe[nl]ix>
ok, so I need somebody with Xcode now :D
<kakuhen>
this is reminding me of some libssl issue that appeared elsewhere in a common lisp software on later macs
<etimmons>
I don't either. But I know from looking at this myself that libssl.dylib is there (in the linker cache). It's just a stub that crashes the process.
<kakuhen>
in short, big sur moves all libraries to a single dyld_shared_cache file, and the actual libraries in /usr/lib are simply stubs referencing points in the shared cache, and this causes some software to behave strangely
<kakuhen>
i forget where exactly the same libcrypto problem appeared; I think it was in Nyxt?
<etimmons>
But I did read somewhere (can't find it at the moment) that binaries signed by Apple (such as the bundled python) can load libssl.dylib (unversioned) without crashing
<fe[nl]ix>
so Apple doesn't want you to load libssl directly, but presumably only as a dependency of one of their frameworks ?
qhong_ has joined #commonlisp
<etimmons>
You can load libssl directly, so long as it's libssl.X.dylib, where X is some integer
<fe[nl]ix>
right, but when linking a C binary, how does one do that ?
<etimmons>
fe[nl]ix: I *like* the :pkg-config option in the unix entry. is that new?
<fe[nl]ix>
kakuhen: I know, that's the exact issue I'm trying to fix: endlessly hard-coding ever changing paths
<fe[nl]ix>
ldb: that's what I suspected, the change to use stubs makes sense in light of that. Apple are trying to make openssl just an implementation detail
<beach>
Good morning everyone!
<fe[nl]ix>
etimmons: yes, it's basically the same syntax as cffi:define-foreign-library, except that this file is processed as an ASDF extension and the code tries to resolve the actual library pointed to by pkg-config
<fe[nl]ix>
morning beach
<beach>
mzan: Are you around?
<kakuhen>
fe[nl]ix: i think the only "easy" way out of this is to require a mac user to install openssl on their own, kind of like how iolib requires users to install libfixposix
<kakuhen>
I just checked Network.framework and there is no dylibs offered by it for you to link against, so I think the chances of avoiding hard-coding different paths depending on OS X version is very very low
<fe[nl]ix>
kakuhen: perhaps, but I wouldn't declare defeat right away
<fe[nl]ix>
ldb: are the Openssl symbols globally visible when loading Network.framework ?
<fe[nl]ix>
if yes, the easy solution for cl+ssl would be to just load Network.framework instead
<ldb>
fe[nl]ix: I find libboringssl.tbd, which includes some of the symbols
<ldb>
_OPENSSL_cleanse, _OPENSSL_free, _OPENSSL_malloc, etc.
pdietz has joined #commonlisp
<etimmons>
fe[nl]ix: I don't know how much you've been following it/if this will affect you at all. But on Monterey, if you dlopen any nonexistent path that ends in lib{ssl,crypto}.dylib your process will be aborted
<fe[nl]ix>
ldb: thanks. how did you obtain that output ?
<fe[nl]ix>
etimmons: which is why the cl+ssl of probing libraries won't work
<fe[nl]ix>
*cl+ssl approach
<fe[nl]ix>
but I need to blog about it
<etimmons>
Yep. It's unfortunate. Anton pushed a change that checks for the existence of non-system SSL dylibs before loading them. I think it works, but it just makes the macOS code even more nasty than it already was.
<ldb>
fe[nl]ix: I'm greping the MacOSX.sdk shipped with CommandLineTools
<ldb>
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib there are some symbol tables there.
<fe[nl]ix>
interesting that the main init functionss, OPENSSL_init_ssl and OPENSSL_init_crypto, are missing
<ldb>
yea I find other crypto related libraries there.
contrapunctus has joined #commonlisp
ldb has quit [Quit: ERC (IRC client for Emacs 27.2)]
king has quit [Quit: king]
semz has quit [Ping timeout: 265 seconds]
semz has joined #commonlisp
karlosz has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
Alfr has quit [Quit: Leaving]
asarch has joined #commonlisp
tophullyte has joined #commonlisp
georgy has quit [Quit: CGI:IRC (EOF)]
jstoddard has quit [Quit: ERC (IRC client for Emacs 27.1)]
karlosz has quit [Quit: karlosz]
hineios has quit [Quit: Ping timeout (120 seconds)]
hineios has joined #commonlisp
Alfr has joined #commonlisp
s-liao has quit [Quit: Client closed]
asarch has quit [Quit: Leaving]
king has joined #commonlisp
king has quit [Client Quit]
notzmv has quit [Ping timeout: 265 seconds]
Guest74 has quit [Ping timeout: 252 seconds]
treflip has joined #commonlisp
euandreh has quit [Ping timeout: 268 seconds]
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
pdietz has quit [Quit: Client closed]
Cymew has joined #commonlisp
|3b|` has joined #commonlisp
anticomputer_ has joined #commonlisp
anticomputer has quit [Ping timeout: 276 seconds]
|3b| has quit [Ping timeout: 240 seconds]
anddam has quit [Ping timeout: 256 seconds]
d4ryus has quit [Ping timeout: 256 seconds]
d4ryus has joined #commonlisp
zacque has joined #commonlisp
|3b|` is now known as |3b|
anddam has joined #commonlisp
karlosz has joined #commonlisp
pillton` has joined #commonlisp
attila_lendvai has joined #commonlisp
rain3 has joined #commonlisp
pillton has quit [Ping timeout: 260 seconds]
Algernon69 has joined #commonlisp
treflip has quit [Read error: Connection reset by peer]
<mzan>
White_Flame: true. (I didn't thinked to these reason). In reality, my point were that too few parens in case are misleading. Case should avoid ``(case x (1 ...))`` from the beginning and accept only ``(case x ((1) ...))``. "case" can also avoid ``(case x (() ..)`` and ``(case x (nil ..))`` because it is never executed. But obviously, I'm only introducing noise. At this point is a semi-joke/trolling about "case". I understood the behaviour of case,
<mzan>
it is acceptable/right, and also I missinterpreted a quotation like 'forward instead of using a symbol like :forward.
amb007 has joined #commonlisp
<mzan>
beach: hi
<beach>
mzan: Never mind. I was going to point out some more style issues, but you have already been told them, and you didn't seem interested in fixing them.
<mzan>
beach: you miss-interpreted. I linked old code. If you read the end of the file, I adopted the new style you suggested. At least I hope.
<mzan>
I add code to the file at each exsercise.
<beach>
But it would be a good exercise to fix the previous one too, and it would help people reading the code, because they don't know where the old starts and the new begins.
<mzan>
The file start with
<mzan>
; Study Common Lisp (CL) using AoC 2021 as exsercise.
<mzan>
; This code makes no justice of CL, because I'm a newbie.
<mzan>
BTW, I fixed the "ecase" error, because it was an error, and doing this I fixed also the style. But I didn't commit yet.
<mzan>
Because there is also temporary code for the day 4.
gaqwas has quit [Ping timeout: 252 seconds]
<beach>
mzan: I do not keep track of the details of your code, such as the day that it was written compared to the day you were given style advice, and I don't think I'm alone. But that's OK. Don't worry about it.
<mzan>
AoC are 25 exsercise. Many use it for learning a new PL. So the style and tricks used in last exsercise will be very different from the style used in first exsercise. It is like reading a diary.
frgo has joined #commonlisp
Cymew has quit [Ping timeout: 240 seconds]
Cymew has joined #commonlisp
karlosz has quit [Ping timeout: 252 seconds]
pillton` has quit [Remote host closed the connection]
frgo has quit [Ping timeout: 240 seconds]
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
treflip has quit [Quit: time to work]
karlosz has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
notzmv has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
karlosz has quit [Ping timeout: 256 seconds]
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
edgar-rft has quit [Quit: Leaving]
voltron has joined #commonlisp
s-liao has joined #commonlisp
Cymew has quit [Ping timeout: 240 seconds]
voltron has quit [Remote host closed the connection]
Cymew has joined #commonlisp
karlosz has joined #commonlisp
dre has quit [Ping timeout: 265 seconds]
karlosz has quit [Quit: karlosz]
OlCe` has quit [Remote host closed the connection]
OlCe has joined #commonlisp
White_Flame has quit [Remote host closed the connection]
White_Flame has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life has joined #commonlisp
_paul0 has quit [Remote host closed the connection]
_paul0 has joined #commonlisp
VincentVega has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
treflip has quit [Remote host closed the connection]
<jdz>
The spec says what numbers are included in the set denoted by this type, but not their "representation".
<jdz>
Implementation details are usually left to implementations. But I'm also curious about the answer to Xach's question.
<_73>
I just wanted to know
<Bike>
sbcl does not encode numbers in the same way in every context
<jdz>
I bet the representation depends on the machine type SBCL (and C) are running on, but most of the time I'd expect the implementations to use "native" representations.
<Bike>
in a typed array on a 64 bit system they might be stored as untagged machine words. on a 32 bit system, two machine words. if the type is less clear, it could fall back to using bignums
<Nilby>
_73: I don't think rely on it. It can depend on how it's compiled. If you need to be compatible with C, you can (cffi:convert-to-foreign x :int64) where x is declared an (signed-byte 64), and if you're lucky it might only take 1 instruction.
idurand has joined #commonlisp
ldb has joined #commonlisp
idurand has quit [Client Quit]
<Bike>
if you compile with high SPEED optimization, it will give you many notes when it can't figure out how to avoid representing things optimally
<Bike>
er
<Bike>
"how to represent thigns optimally"
s-liao has joined #commonlisp
idurand has joined #commonlisp
<Bike>
spelling. hard.
Cymew has quit [Ping timeout: 265 seconds]
treflip has joined #commonlisp
idurand has quit [Ping timeout: 260 seconds]
s-liao has quit [Quit: Client closed]
<jackdaniel>
planet ape reference?
Algernon666 has joined #commonlisp
amb007 has quit [Ping timeout: 265 seconds]
<Nilby>
_73: There's also cffi:with-pointer-to-vector-data which could be transparent, or even not require swizzling if everything goes well.
amb007 has joined #commonlisp
<_73>
Nilby: Thanks, I'll remember to use cffi if I need to be compatible with C, which could be possible for my project.
Algernon91 has quit [Ping timeout: 240 seconds]
ldb has quit [Quit: ERC (IRC client for Emacs 27.2)]
<Nilby>
_73: Implementations generally need complete freedom to do data encoding however they want, so you can have a CL interpreter or run on top of other languages (e.g. ABCL), unusual architectures, etc.
<Bike>
having a bijection from language types to machine representations would be far too limiting. even in C you have packed vs unpacked structures and stuff.
taiju has quit [Read error: Connection reset by peer]
taiju has joined #commonlisp
euandreh has quit [Ping timeout: 268 seconds]
rain3 has joined #commonlisp
<Nilby>
I like to imagine one could constuct a purely mechanical hand-cranked but compliant CL.
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<pjb>
Nilby: indeed.
aartaka has quit [Ping timeout: 240 seconds]
zacque has quit [Quit: Goodbye :D]
euandreh has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
aartaka has joined #commonlisp
aartaka has quit [Read error: Connection reset by peer]
aartaka has joined #commonlisp
derelict is now known as tetrahedron
aartaka has quit [Ping timeout: 265 seconds]
tyson2 has joined #commonlisp
aartaka has joined #commonlisp
VincentV` has quit [Ping timeout: 265 seconds]
cosimone has joined #commonlisp
idurand has joined #commonlisp
makomo has joined #commonlisp
srhm has quit [Remote host closed the connection]
srhm has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
<utis>
is there a straightforward way to loop for i from* a to* be when one doesn't know which of a and b is greatest?
Catie has joined #commonlisp
pranavats has joined #commonlisp
chrnybo has quit [Remote host closed the connection]
idurand has quit [Ping timeout: 265 seconds]
jstoddard has joined #commonlisp
<fe[nl]ix>
luis: ping
<Xach>
utis: (loop for with step = (signum (- b a)) for a* = a then (+ a* step) until (= a* b) do ...)
<Xach>
"Straightforward"
<utis>
hehe . . thanks
waleee has quit [Quit: WeeChat 3.3]
tyson2 has quit [Remote host closed the connection]
Guest74 has joined #commonlisp
waleee has joined #commonlisp
<Bike>
(loop for i from (min a b) to (max a b) ...)?
<beach>
Not quite conforming to the specification.
<Bike>
it's not?
<beach>
That one might loop from b to a, but it was specified that the loop should be from a to b.
<Bike>
oh, like the specification of the problem. yeah, maybe i didn't understand it
cage has joined #commonlisp
igemnace has quit [Ping timeout: 240 seconds]
<Guest74>
I guess you could always write a macro around it to test which is greater and stick a :to or :downto accordingly. this is usually when I reach for DO.
<Xach>
I don't see signum much in my normal course of lisping so it's always fun to use it.
igemnace has joined #commonlisp
<Guest74>
i use it so infrequently I keep forgetting about it. Then when I see it again, i think i should make more frequent use of it.
<Xach>
a function that used signum and revappend would be doubly blessed. ldiff too? trebly.
<Guest74>
I'd love to so a practical example of those, especially ldiff. Never used either.
<Guest74>
but then again, every time I use append something goes wrong.
tophullyte has quit [Ping timeout: 240 seconds]
<_73>
then surely everything will go right when you use revappend
<Guest74>
rewords wish, a practical self contained example. :) seriously though, I'll look at that later I think I'll have to understand more of where it's used. busy writing a visualization right now. lol, though it basically requires picking colours .
<Bike>
it takes a lambda list with &optional in it, and gets a list of the elements before the &optional.
gko has quit [Remote host closed the connection]
gko has joined #commonlisp
<Guest74>
this sounds useful to me. does it return it in the order written?
<Bike>
Yes. like, (a b c &optional d) => (a b c)
<Guest74>
that sounds like something I can use. Hopefully I can remember it when the time comes.
<Bike>
the downside is it traverses the list twice, but at least it's ismple to write
leo_song has quit [Ping timeout: 245 seconds]
tophullyte has joined #commonlisp
pdietz has quit [Quit: Client closed]
treflip has quit [Quit: good night ✨]
<Guest74>
and usually very small lists
phossil has joined #commonlisp
tophullyte has quit [Ping timeout: 265 seconds]
tyson2 has joined #commonlisp
VincentVega has joined #commonlisp
VincentV` has joined #commonlisp
VincentVega has quit [Ping timeout: 240 seconds]
_73 has quit [Remote host closed the connection]
<jackdaniel>
uh oh, sbcl in safe code "Unhandled memory fault at #x5E8ECA8." :) but I'll need to test with a newer release
<rotateq>
pretty rare such a thing, isn't it? like a shiny pokemon
_73 has joined #commonlisp
<jackdaniel>
well, it seems that I have a recent release and it broke after the system built it, I'll try with local build and narrow the issue
Guest74 has quit [Ping timeout: 256 seconds]
igemnace has quit [Ping timeout: 256 seconds]
gaqwas has joined #commonlisp
Guest74 has joined #commonlisp
_73 has quit [Remote host closed the connection]
rain3 has quit [Ping timeout: 252 seconds]
Algernon666 has quit [Ping timeout: 240 seconds]
Guest74 has quit [Quit: Ping timeout (120 seconds)]
Guest74 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
Algernon666 has joined #commonlisp
<Guest74>
I really need to fix my recording functions. recording this https://youtu.be/zgXHWmBH00o has brought my laptop to a crawl. a single thread running an ffmpeg process shouldn't cause this should it? I wonder if sbcl is reading all the output? Shouldn't this slowdown go away after the thread is killed?
<Guest74>
I'm going to have to reboot, it's still slow like half an hour after.
Guest74 has quit [Quit: Connection closed]
tyson2 has joined #commonlisp
VincentV` has quit [Remote host closed the connection]
specbot has quit [Remote host closed the connection]
minion has quit [Read error: Connection reset by peer]
minion has joined #commonlisp
specbot has joined #commonlisp
phossil has quit [Ping timeout: 256 seconds]
minion has quit [Remote host closed the connection]
minion has joined #commonlisp
specbot has quit [Killed (NickServ (GHOST command used by specbot1))]
minion has quit [Remote host closed the connection]
minion has joined #commonlisp
specbot has joined #commonlisp
VincentVega has joined #commonlisp
VincentV` has joined #commonlisp
VincentVega has quit [Ping timeout: 268 seconds]
varjag has joined #commonlisp
Jach has joined #commonlisp
phossil has joined #commonlisp
phossil has quit [Client Quit]
happy-dude has quit [Ping timeout: 250 seconds]
akater[m] has quit [Ping timeout: 250 seconds]
paulapatience has quit [Ping timeout: 252 seconds]
etimmons has quit [Ping timeout: 250 seconds]
yitzi has quit [Ping timeout: 240 seconds]
zbrown[m] has quit [Ping timeout: 252 seconds]
Duuqnd has quit [Ping timeout: 240 seconds]
Mrtn[m] has quit [Ping timeout: 250 seconds]
rudi has quit [Ping timeout: 260 seconds]
Gnuxie has quit [Ping timeout: 250 seconds]
luis` has quit [Ping timeout: 250 seconds]
Arcsech has quit [Ping timeout: 250 seconds]
icepic1984[m] has quit [Ping timeout: 260 seconds]
CodeBitCookie[m] has quit [Ping timeout: 260 seconds]
MatrixTravelerbo has quit [Ping timeout: 250 seconds]
hayley has quit [Ping timeout: 250 seconds]
sp has quit [Ping timeout: 250 seconds]
Spawns_Carpet[m] has quit [Ping timeout: 240 seconds]
sepanko has quit [Ping timeout: 252 seconds]
loke[m] has quit [Ping timeout: 260 seconds]
dieggsy has quit [Ping timeout: 260 seconds]
katco has quit [Ping timeout: 268 seconds]
Inline has joined #commonlisp
saltrocklamp[m] has quit [Ping timeout: 268 seconds]
saltrocklamp[m] has joined #commonlisp
pdietz has joined #commonlisp
loke[m] has joined #commonlisp
dieggsy has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
sp has joined #commonlisp
MatrixTravelerbo has joined #commonlisp
pve has quit [Quit: leaving]
tyson2 has quit [Remote host closed the connection]
aartaka has quit [Ping timeout: 265 seconds]
cosimone has quit [Ping timeout: 265 seconds]
sepanko has joined #commonlisp
paulapatience has joined #commonlisp
Spawns_Carpet[m] has joined #commonlisp
yitzi has joined #commonlisp
theothornhill has joined #commonlisp
katco has joined #commonlisp
dre has joined #commonlisp
theothornhill has quit [Remote host closed the connection]
skeemer__ has quit [Quit: Leaving]
zbrown[m] has joined #commonlisp
dre has quit [Ping timeout: 260 seconds]
_73 has joined #commonlisp
dra_ has joined #commonlisp
katco has quit [Read error: Connection reset by peer]
yitzi has quit [Remote host closed the connection]
Spawns_Carpet[m] has quit [Read error: Connection reset by peer]
zbrown[m] has quit [Read error: Connection reset by peer]
saltrocklamp[m] has quit [Write error: Connection reset by peer]
paulapatience has quit [Read error: Connection reset by peer]
loke[m] has quit [Write error: Connection reset by peer]
dieggsy has quit [Write error: Connection reset by peer]
sepanko has quit [Write error: Connection reset by peer]
MatrixTravelerbo has quit [Read error: Connection reset by peer]
sp has quit [Read error: Connection reset by peer]
katco has joined #commonlisp
varjag has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
leo_song has joined #commonlisp
dre has joined #commonlisp
luis` has joined #commonlisp
sepanko has joined #commonlisp
happy-dude has joined #commonlisp
rudi has joined #commonlisp
etimmons has joined #commonlisp
dieggsy has joined #commonlisp
Gnuxie has joined #commonlisp
saltrocklamp[m] has joined #commonlisp
Mrtn[m] has joined #commonlisp
yitzi has joined #commonlisp
paulapatience has joined #commonlisp
MatrixTravelerbo has joined #commonlisp
akater[m] has joined #commonlisp
hayley has joined #commonlisp
sp has joined #commonlisp
zbrown[m] has joined #commonlisp
Duuqnd has joined #commonlisp
loke[m] has joined #commonlisp
Arcsech has joined #commonlisp
CodeBitCookie[m] has joined #commonlisp
Spawns_Carpet[m] has joined #commonlisp
icepic1984[m] has joined #commonlisp
Guest74 has joined #commonlisp
tyson2 has joined #commonlisp
dra_ has quit [Remote host closed the connection]
euandreh has quit [Ping timeout: 240 seconds]
MatrixTravelerbo has quit [Quit: Client limit exceeded: 20000]
Mrtn[m] has quit [Quit: Client limit exceeded: 20000]
happy-dude has quit [Quit: Client limit exceeded: 20000]
loke[m] has quit [Quit: Client limit exceeded: 20000]
sepanko has quit [Quit: Client limit exceeded: 20000]
katco has quit [Quit: Client limit exceeded: 20000]
luis` has quit [Quit: Client limit exceeded: 20000]
etimmons has quit [Quit: Client limit exceeded: 20000]
paulapatience has quit [Quit: Client limit exceeded: 20000]
saltrocklamp[m] has quit [Quit: Client limit exceeded: 20000]
Spawns_Carpet[m] has quit [Quit: Client limit exceeded: 20000]
zbrown[m] has quit [Quit: Client limit exceeded: 20000]
Duuqnd has quit [Quit: Client limit exceeded: 20000]
sp has quit [Quit: Client limit exceeded: 20000]
Arcsech has quit [Quit: Client limit exceeded: 20000]
dieggsy has quit [Quit: Client limit exceeded: 20000]