00:16
egg|laptop|egg_ has joined #glasgow
00:20
egg|laptop|egg has quit [Ping timeout: 272 seconds]
01:01
egg|laptop|egg has joined #glasgow
01:04
egg|laptop|egg has quit [Remote host closed the connection]
01:07
egg|laptop|egg has joined #glasgow
02:15
egg|laptop|egg has quit [Remote host closed the connection]
03:39
G33KatWork has quit [Ping timeout: 256 seconds]
03:39
G33KatWork has joined #glasgow
03:42
electronic_eel has quit [Ping timeout: 256 seconds]
03:42
electronic_eel_ has joined #glasgow
04:58
PyroPeter_ has joined #glasgow
05:01
PyroPeter has quit [Ping timeout: 265 seconds]
05:01
PyroPeter_ is now known as PyroPeter
06:14
_whitelogger has joined #glasgow
06:45
electronic_eel has joined #glasgow
07:04
mndza has joined #glasgow
07:43
G33KatWork has quit [Ping timeout: 256 seconds]
07:43
G33KatWork has joined #glasgow
11:19
promach3 has quit [Quit: Bridge terminating on SIGTERM]
11:19
svenpeter has quit [Quit: Bridge terminating on SIGTERM]
11:19
gillesmauve has quit [Quit: Bridge terminating on SIGTERM]
11:19
emily has quit [Quit: Bridge terminating on SIGTERM]
11:19
_alice has quit [Quit: Bridge terminating on SIGTERM]
11:19
eddyb has quit [Quit: Bridge terminating on SIGTERM]
11:19
blazra has quit [Quit: Bridge terminating on SIGTERM]
11:19
jschievink has quit [Quit: Bridge terminating on SIGTERM]
11:19
whitequark[m] has quit [Quit: Bridge terminating on SIGTERM]
11:19
disasm[m] has quit [Quit: Bridge terminating on SIGTERM]
11:19
randomplum has quit [Quit: Bridge terminating on SIGTERM]
11:20
fridtjof[m] has quit [Quit: Bridge terminating on SIGTERM]
11:28
eddyb has joined #glasgow
11:34
promach3 has joined #glasgow
11:34
jschievink has joined #glasgow
11:34
_alice has joined #glasgow
11:34
fridtjof[m] has joined #glasgow
11:34
disasm[m] has joined #glasgow
11:34
blazra has joined #glasgow
11:34
emily has joined #glasgow
11:34
gillesmauve has joined #glasgow
11:35
whitequark[m] has joined #glasgow
11:35
svenpeter has joined #glasgow
11:35
randomplum has joined #glasgow
11:55
midnight has quit [Ping timeout: 240 seconds]
11:57
midnight has joined #glasgow
12:04
egg|laptop|egg has joined #glasgow
12:07
egg|laptop|egg_ has quit [Ping timeout: 240 seconds]
14:27
thaytan has quit [Ping timeout: 256 seconds]
14:34
thaytan has joined #glasgow
16:46
d_olex has quit [Read error: Connection reset by peer]
16:47
d_olex has joined #glasgow
17:03
spacekookie_ is now known as spacekookie
17:58
mndza has quit [Read error: Connection reset by peer]
17:59
mndza has joined #glasgow
19:03
<
cyborg_ar >
I wonder what would be the maximun datarate possible on a datasette using modern encoding and modulation methods.
19:04
<
_whitenotifier >
[glasgow] mndza synchronize pull request #265: Add bitarray implementation to eliminate external dependency -
https://git.io/JtZfr
19:11
mndza has quit [Ping timeout: 260 seconds]
20:25
GNUmoon has quit [Ping timeout: 268 seconds]
22:27
oter has joined #glasgow
22:30
GNUmoon has joined #glasgow
22:47
G33KatWork has quit [Ping timeout: 256 seconds]
22:47
G33KatWork has joined #glasgow
23:32
<
modwizcode >
well that bot might need to be modified slightly :p
23:33
<
d1b2 >
<Attie> 😬 yeah... I'm glad it didn't do every comment i made...
23:33
<
d1b2 >
<Attie> I was expecting a single ding!
23:34
<
modwizcode >
probably github's fault
23:36
<
modwizcode >
kind of random but I can't find an answer anywhere. How does memoryview actually differ from bytearray?
23:37
<
whitequark >
memoryview is like std::string_view and byetarray is like std::string
23:37
<
modwizcode >
Maybe if I have motivation after these qemu patches :/
23:37
<
whitequark >
except without the footguns
23:37
<
modwizcode >
Fun fact I don't actually know how to use std::string_view and when I wanted to it seemed hard to use and annoying
23:37
<
whitequark >
it is an amazingly hazardous interface
23:37
<
whitequark >
LLVM has its own version, StringRef, and that causes no end of crashes
23:38
<
modwizcode >
But like I thought the point of string_view was that you could make it refer to a slice (maybe it wasn't and that's why I found it annoying)
23:38
<
d1b2 >
<Attie> footguns in std::string_view, and missing in memoryview?
23:38
<
whitequark >
you can do that with bytearray
23:38
<
modwizcode >
Ah the beauty of 4 copies of the same bad interface
23:38
<
whitequark >
Attie: memoryview manages the memory itself
23:38
<
d1b2 >
<Attie> oh, i thought it was like a viewport to physical memory, interesting
23:38
<
whitequark >
like, std::string_view is a UAF factory. memoryview is not
23:38
<
d1b2 >
<Attie> (not used it before)
23:38
<
whitequark >
it is a viewport into a bytearray or other buffer object
23:39
<
modwizcode >
I guess I was confused because I assumed that given that bytearray is already mutable how does it differ
23:41
<
d1b2 >
<Attie> right... so what memory management does it do?
23:41
<
d1b2 >
<Attie> seems the docs say resizing is not allowed
23:43
<
whitequark >
it ... keeps the buffer alive, obviously?
23:43
<
whitequark >
what else would it do
23:43
<
d1b2 >
<Attie> oh, i see sorry - i was presuming it'd handle resize and things
23:44
<
d1b2 >
<Attie> (when you said it manages the memory, i was thinking much more hands on than just keeping it alive)
23:44
<
whitequark >
well, std::string_view doesn't even do that
23:45
<
d1b2 >
<Attie> yeah - now i see the glaring footgun you mention 😄
23:45
<
whitequark >
ah! the common mistake of assuming C++ does anything in a way that prevents accidental misuse
23:45
<
d1b2 >
<Attie> hah, yeah... i'm not familiar enough with C++, so i guess i give it the benefit of the doubt (oops)
23:46
<
modwizcode >
yeah I wouldn't give C++ that
23:46
<
whitequark >
don't
*ever* give C++ the benefit of doubt
23:46
<
d1b2 >
<Attie> i'll remember this!
23:47
<
d1b2 >
<Attie> it likely explains away some issues I've had in the distant past
23:47
<
modwizcode >
I am both surprised and not surprised that they didn't mandate design such that it was safe.
23:48
<
whitequark >
C++
*never* does anything just to make it safe.
23:56
egg|laptop|egg has quit [Read error: Connection reset by peer]