libera/#commonlisp - IRC Chatlog
Search
14:04:20
nij-
With shell command `cat file > sha1sum` I can get the sha1 of the content of the file. How to do that in CL?
14:14:16
nij-
(sha1:sha1-digest "abc") ;; => (169 153 62 54 71 6 129 106 186 62 37 113 120 80 194 108 156 208 216 157)
14:19:01
scymtym
the ironclad equivalent is (ironclad:byte-array-to-hex-string (ironclad:digest-sequence :sha1 (babel:string-to-octets (format nil "abc~%")))) => "03cfd743661f07975fa2f1220c5194cbaff48451"
14:25:08
nij-
Your example immediately teaches me how to use ironclad, by comparing to a tool that I'm more familiar with :)
15:38:53
splittist
nij-: presumably the first avoids starting a new cat process - the shell is doing the redirection itself
15:42:56
nij-
I'm not sure about apt-install, but I remembered some pain when I relied on pacman for sbcl back then.
16:06:54
pjb
nij-: indeed, cat | sha1sum need to for two processes instead of one, and to create a pipe. In the shell "repl" it doesn't matter much, but in shell scripts this could slow down the script. Furthermore, cat doesn't always copy the file byte-for-byte. It has options to do some formatting.
16:08:27
pjb
somebody could have: alias cat='/bin/cat -s -v' so that when it's used in the terminal to dump a file, adjacent empty lines be squeezed, and control characters printed as ^X. sha1-summing that wouldn't be meaningful.
16:48:42
pjb
One of the atomic type specifiers short-float, single-float, double-float, or long-float, or else some other type specifier defined by the implementation to be acceptable.
17:37:55
pjb
now the funny thing is that ratio gives a double-float result (in ccl), instead of ratio. On the other hand, rational gives a ratio result (in ccl)…
19:46:39
jackdaniel
some fun with parsing xml documents: http://turtleware.eu/static/paste/5869320d03049391e91f2d69e7991cffa118d062-xkb.lisp
20:31:01
phoe
it's more convenient for me to write 199.99 than fixed-point 19999 or direct ratio 19999/100
20:31:24
phoe
this way I avoid using floats for fixed-point numbers which is a known recipe for disaster
20:49:04
pjb
phoe: now, there's a problem, because is it $199.99 or 199.99€ ? Hence my reader macro: #m199.99 (using the *default-currency* or with explicit currencies: '(#840m199.99 #978m199.99) --> (199.99 USD 199.99 EUR)
20:56:26
phoe
but still, (pln 199.99) would also work for a one-arg constructor that creates an instance of PLN currency
21:06:36
pjb
(setf com.informatimago.common-lisp.invoice.invoice::*default-currency* (com.informatimago.common-lisp.cesarum.iso4217:find-currency "PLN")) --> ("PLN" 985 2 "Zloty") ; then:
21:20:13
jackdaniel
is (mod (lognot x) (integer-length x)) the right way to negate insigned integer bitwise?
22:24:09
kakuhen
sounds right to me... `(ldb (byte (integer-length x) 0) (lognot x))` is what I would've guessed
22:40:03
White_Flame
jackdaniel: I think that the numeric width should be irrelevant to the current value's bit width
22:40:22
kakuhen
well, the more i think about it, i dont think integer-length is a very good idea, because you may want to negate e.g. #b010 and expect #b101 instead of #b01 (which is what my suggestion would give)
22:41:47
kakuhen
yeah, so something like (defun unsigned-negate (byte length) (logand (1- (ash 1 length)) (lognot byte)))
22:49:40
pjb
jackdaniel: the negate operator in CL is - (let ((unsigned-integer 42)) (- unsigned-integer)) #| --> -42 |# what do you have against it?
22:50:54
pjb
phoe: my point, the length needs to be known before hand. And therefore (logand #xffffffff (lognot x)) eg if it's 32.
22:52:20
pjb
42 is …000101010 in binary; it's bitwise negation should be …111010101 ; computing …000101010 --> …000010101 seems meaningless to me.
22:54:22
pjb
Now, you may consider 1-complement, or 2-complement, with a predetermined word length. (logand #xff (lognot 42)) #| --> 213 |# may seem strange, but bitwise is clear: 00101010 --> 11010101
23:03:38
ldb
ACTION just completed adding lisp symbol index to CLtL2, would not consider add the glossary
23:27:17
morganw
I'm pretty sure that the Winston and Horn book has a section which implements an infix form converter.
23:31:09
White_Flame
most lisp infix tools deal with (1 + 2 * 3) sorts of forms, not strings, so breaking apart the string will be a separate issue.
23:31:38
ldb
as these days there are plenty of parser generator I just recommand to try build one with them, like https://github.com/eugeneia/maxpc