libera/#sbcl - IRC Chatlog

4:50:15 |3b| what's the fastest way to copy a few kb from a pointer to a typed cl vector in sbcl?

4:50:50 |3b| currently copying by element, but that seems a bit slow for u-b 16

4:59:28 moon-child get sap, call memcpy?

4:59:30 moon-child :P

4:59:45 |3b| yeah, that was my best guess, about to try that

5:01:57 moon-child I mean, could do your own vop, but memcpy is less effort and more portable

5:10:54 |3b| hmm, maybe a bit faster, but not as much as i hoped... back to wishing i had a profiler i guess :p

6:08:33 Josh_2 https://github.com/thephoeron/cl-isaac/issues/10 I put this here to make sbcl devs aware of this

6:08:55 Josh_2 some odd platform specific behaviour happening with (the ..)

6:08:58 Josh_2 something like that

6:23:24 |3b| is the part that sbcl devs would care about that restrict-compiler-policy isn't working on macos?

6:23:52 |3b| that's a lot of text to dig through for that 1 bit if so :/

6:37:51 stassats restrict-compiler-policy not working on some specific platform just can't be true

7:01:40 jackdaniel unless it is macos ;)

7:02:40 stassats even then

7:23:19 hineios5 ** NICK hineios

7:36:21 Josh_2 |3b|: what can I say, thephoeron was started with -vvv

8:03:37 |3b| Josh_2: i meant more "link to a specific comment" at least :)

8:05:55 Josh_2 https://github.com/thephoeron/cl-isaac/issues/10#issuecomment-1567118398 this?

8:07:01 |3b| maybe? i couldn't see a specific bug report in that one though :/

8:07:33 |3b| Josh_2: is the problem that restrict-compiler-policy seems to not be working?

8:08:05 |3b| it also mentions something about THE with high safety, but not /what/ and seems to think it is working as intended so not a bug?

8:09:26 |3b| behavior of THE when the value isn't that type (as in the earlier comments) is undefined, so is expected to be non-portable across implementations

8:19:52 stassats` was the code recompiled after restrict-compiler-policy?

8:24:22 |3b| looks like probably not

8:25:27 Josh_2 Well this is a problem that has been replicated on multiple fresh sbcl installs

8:25:45 stassats` was restrict-compiler-policy actually done?

8:25:53 Josh_2 Yes

8:26:00 stassats` how do you know?

8:26:24 |3b| Josh_2: the pasted examples in the bug don't seem to show the code being recompiled in the macos case

8:26:49 stassats` there's 0% chance restrict-compiler-policy is different on macos

8:27:36 Josh_2 Okay well unfortunately I dont actually know whats going on with cl-isaac itself, I am simply a messenger in this case. However I can say that I have used a build pipeline with gitlab to try and deploy software that was depending on cl-isaac that used restrict-compiler-policy and this problem has occurred when its set to safety 3

8:27:41 |3b| ACTION 's guess was something else changing the restriction, but failing to recompile seems much more likely (and fits the available evidence)

8:28:20 |3b| cl-isaac was apparently broken, as correctly reported by the errors

8:29:09 stassats` the macos version might as well be using different numbers

8:29:27 stassats` it is a random number generator after all...

8:29:59 Josh_2 I think the point is something to do with inconsistent treatment of (the ..) idk

8:30:06 Josh_2 I know I'm not being very help

8:30:08 Josh_2 helpful

8:30:12 |3b| the bug was hidden by using local safety 0

8:30:31 |3b| forcing safety >0 exposed it again

8:30:58 |3b| restricting it without recompiling seems to have caused confusion

8:31:53 |3b| ACTION couldn't find any information about what was wrong with THE, particularly in context of undefined behavior where nothing is 'wrong' at the CL level

8:32:35 |3b| (so SBCL and some other impl can do completely different things and still be 'correct' to their own interpretations, and users can't complain since their code is non conformant)

8:33:38 Josh_2 "Digging into SBCL internals, I discovered some completely non-portable behaviour surrounding the special-form THE when safety >= 2."

8:33:50 |3b| right, which isn't a bug report

8:34:03 stassats` non-portable for other implementations?

8:34:04 |3b| or even a starting point for looking for something about which to file a bug report

8:34:08 stassats` it's certainly portable to macos

8:34:30 |3b| particularly in the context of undefined behavior

8:34:33 jackdaniel it is a conforming behavior to not trust the - undefined consequences are undefined

8:35:01 Josh_2 |3b|: Okay :sunglasses: Thanks for your help

8:35:07 |3b| jackdaniel: it is non-conforming to say (the (unsigned-byte 64) not-a-ub64)

8:35:20 stassats` in the end, there is no test case being submitted

8:35:25 stassats` all this is just conjecture

8:36:10 Josh_2 Yes

8:37:09 stassats` but that the type system treatment is the same across oses is a certainty

8:37:17 jackdaniel |3b|: how do you distinguish the behavior of trusted and untrusted the in a conforming orogram?

8:37:19 stassats` but you might have different types

8:37:31 jackdaniel program*

8:37:54 |3b| jackdaniel: not sure what you mean

8:38:13 |3b| ACTION means "The consequences are undefined if the values yielded by the form are not of the type specified by value-type. "

8:40:02 jackdaniel you are right. I mean that whatever sbcl does with THE is not non-conforming or not portable. reading what you have said earlier we seem to agree :)

8:40:04 |3b| the code in question masks off 64 bits of (the (u-b 64) ...), so pretty obviously doesn't actually expect that value to be u-b 64

8:40:34 |3b| right, sbcl is conformant and internally consistent in how it chooses to behave in that case

8:44:06 stassats` why doesn't trace respect the print variables on function calls, but does so on returns?

8:53:41 stassats` i don't understand (handler-case (make-isaac64-ctx) (error () nil))

8:55:00 jackdaniel perhaps a poor man's ignore-errors?

8:55:12 stassats` but make-isaac64-ctx has no errors in it

8:55:24 stassats` other than, being undefined? running out of memory?

8:58:06 |3b| doesn't look like the rest of the function would work if it did fail anyway

8:58:45 |3b| unless NIL is a valid ctx