libera/#commonlisp - IRC Chatlog
Search
2:26:09
White_Flame
it all depends on the complexity you want. macroexpansion is fine for literal expansion with no further analysis
2:26:51
White_Flame
but really, any analysis you perform could either be done at compile time or at evaluation time, all depends on where the function calls are made
2:28:06
White_Flame
but once your macro reaches a certain size, it's certainly helpful to break out a bunch of functions to handle the various subclauses. these functions can either be called by the macroexpander, or by the expanded code, or externally if your macro just generates a datastructure
2:35:20
Josh_2
if you have a macro that expands out the entire thing then it should be trivial to add a compiler macro
3:33:03
White_Flame
sm2n: oh sorry, didn't read that as "compiler macro" originally. I haven't done that approach
5:04:21
yottabyte
either one. I was trying to use remove-if/delete-if but yeah. I could do what mfiano is saying
5:06:47
Bike
the remove/delete-if incantation would be something like (remove-if (constantly t) sequence :start n :count 1), i guess
5:20:17
mfiano
I'd use them all in different parts of the code, to please and displease everyone all at once.
5:22:31
mfiano
My original solution was to do it without walking twice. I'm not sure how remove-if/delete-if is usually implemented, but that is certainly more readable, if not more efficient than that one ^
5:23:38
White_Flame
if you walk once, you're going to be allocating as you go, and tail share the rest. if the element is not found, then those copies are redundant
5:24:49
White_Flame
also, if you're removing the first element, that's a special case as it's not the CDR of anything
5:27:23
White_Flame
you can (let ((temp-list (cons nil list))) ...setf cdr stuff... (cdr temp-list)) to operate in full cdr mode without special case for removing the head
11:23:46
Guest50
hello, I could use some eyes on a simple ironclad encryption test. https://plaster.tymoon.eu/view/2910/raw?password
11:26:07
flip214
Guest50: my guess is that cipher is modified during encryption... you might need to copy it for decryption
11:27:33
flip214
Guest50: also, the ciphertext will be rounded up to the cipher block size, won't it? so 7 bytes ("testing") are too small?
11:30:13
Guest50
flip214 I haven't read anything about the ciphertext rounding up, but I'll look into it. If that's the case then plaintext needs to be 16 bytes min?
11:33:41
Guest50
from my understanding (which is marginal) there would be no padding since this is an aes cipher with a ctr mode
11:34:37
phoe
if the length of the ciphertext is not an exact multiple of the key size then there will be some padding nonetheless, AES operates on blocks of data of predefined size
11:34:38
flip214
yeah, but the counter gets incremented per cipher block and not per byte, so you'll need whole cipher blocks?
11:35:57
phoe
for aes-256 you need 32 bytes of data per block, so for 7 bytes you'll likely get a plaintext that looks like #x(01 23 45 67 89 ab cd 00 00 00 00 00 00 00 00 00)
11:44:41
Guest50
would I need to check the length of the encrypted data to see if its a multiple of the key size and remove any extra bytes?
11:46:44
phoe
or include a message length in your plaintext, and then truncate the decrypted output to size
13:15:47
chrnybo
My server process, written in Lispworks, holds too many file descriptors. Guess I'm sloppy when closing them. Can I map from the TID (thread id) listed by unix' lsof to something useful within the lisp to help me locate the error?
13:21:25
chrnybo
Feels like submitting a ticket to support while certain that the problem sits in my chair.
13:42:25
rotateq
beach: Even for all the incoming company support? ^^ Okay than one real advanced sorcerer employed for that may be cheaper.
13:44:01
chrnybo
I suppose a sufficiently advanced GPT-n may well keep me entertained with adequate support replies.