channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

http://bespin.org/~qz/search/?view=1&c=osdev2&y=22&m=5&d=20

Friday, 20 May 2022

00:11:00 <klange> < GeDaMo> I thought it was an Of Mice and Men reference but OK :P ← Parody Displacement
01:02:00 <mrvn> https://godbolt.org/z/88o4hsvbP 1) why isn't the vector constructor using copy elision? 2) Why doesn't reserve move construct? 3) the copy elides, 4) shouldn't this optimize the move away?
01:02:00 <bslsk05> ​godbolt.org: Compiler Explorer
01:03:00 <mrvn> this == v.emplace_back(A{1})
01:05:00 <heat> every time you ask a question it makes me want to rewrite everything in rust
01:05:00 <heat> or C
01:05:00 <mrvn> 1) why isn't the vector constructor using move if it won't elide?
01:05:00 <heat> either a future-is-now-old-man language, or the old man language
01:05:00 <mrvn> heat: I'm getting there.
01:06:00 <mrvn> heat: but is rust any better with avoiding useless copying?
01:06:00 <heat> i hope so?
01:06:00 <gamozo> Rust solves it
01:06:00 <heat> at least it has destructive moves, and thats a good thing
01:06:00 <mrvn> heat: I don't even want to move, I want to constgruct in-place.
01:08:00 <mrvn> ##### A a{A{A{A{A{A{1}}}}}} #####
01:08:00 <mrvn> @0x7ffc8a13ef1b: full A::A(int)
01:08:00 <heat> AAAAAAAAAAAAAAAAAAAAAAAAAAA
01:08:00 <mrvn> When I construct an A then it copy elides all the intermediate constructors perfectly. But not with vectors.
01:09:00 <heat> i write my stuff in C++ for RAII and classes really
01:09:00 <heat> sometimes templates
01:21:00 <geist> AAAAAA
01:21:00 * gamozo segfaults
01:24:00 <heat> gets strikes again
01:25:00 <heat> now we find rop gadgets and RCE gamozo
01:25:00 <gamozo> Don't forget the ASLR bypass
04:02:00 <radens> Does anyone have a copy of the original l3 source code?
04:03:00 <radens> I'm finding a lot of dead links and some things which are not the kernel, which is what I'm after
05:02:00 <geist> hmm, good question
05:03:00 <geist> was a long time back, may have just been before git/etc
06:14:00 <geist> been fiddling with musl for the last hour and i have to say it's pretty easy to work with
06:14:00 <geist> just configure and go, seems to be self contained
06:14:00 <geist> it builds entirely for linux, of course, but it looks *fairly* straightforward to redirect the syscalls to another library
06:15:00 <geist> it builds really fast too, so that's nice
06:15:00 <geist> like 10 seconds on this computer
06:21:00 <geist> also ugh. looks like riscv64-elf toolchain doesn't support creating shared libs for some reason
06:28:00 <geist> lemme see if i can hack that and build a new copy
06:56:00 <geist> seems to be in binutils actually
06:56:00 <geist> https://github.com/bminor/binutils-gdb/blob/master/ld/emulparams/elf32lriscv-defs.sh#L19 seems that shooting that down works fine. <shrug>
06:56:00 <bslsk05> ​github.com: binutils-gdb/elf32lriscv-defs.sh at master · bminor/binutils-gdb · GitHub
11:22:00 <ddevault> navigating the seL4 source code is a nightmare
11:22:00 <ddevault> it goes to extreme measures to hide its data structures from you
11:58:00 <gog> enhanced security by enhanced obscurity
12:20:00 <zid> That's a security feature in itself :P
12:20:00 <zid> If you can't find them in the code you can't dereference pointrs to them
12:23:00 <ddevault> does anyone know of some good technical hangouts where I can chat with seL4 experts to better understand their design?
12:23:00 <ddevault> I'm pretty pleased with its API design but the implementation is super hard to follow
14:36:00 <jafarlihi> Does QEMU generate IRQ of 1 when a key is pressed on the keyboard?
14:45:00 <Mutabah> Since it emulates an 8042 PS2 controller, yes
14:49:00 <jafarlihi> I get IRQ reaction when I do asm("int $33"); but pressing keyboard keys doesn't seem to invoke it. Any ideas why that might be?
15:02:00 <zid> PIT mask
15:02:00 <zid> err PIC
15:02:00 <zid> cli
15:04:00 <heat> geist, generally the -elf targets can't make shared objects
15:04:00 <heat> it's just something you need to enable and then PATCH EVERY LIVING COPY OF LIBTOOL.M4
15:05:00 <heat> glad you're enjoying musl though
15:06:00 <heat> the ./configure is not even a regular configure script, it just creates a config.mak to feed into the manually-written makefile
15:08:00 <mrvn> forgot to EOI it on init?
15:09:00 <heat> chances are it's masked in the PIC or in the eflags
15:15:00 <mrvn> heat: instead of patching it you should remove it and use the systems one to build.
15:18:00 <heat> i'm not patching system files.
15:18:00 <heat> "why does your OS require sudo to build?" "because I'm meddling in your system files" <-- ???
15:22:00 <mrvn> they should already be patches (at some point in the future)
15:22:00 <mrvn> The advanatge is that the system file will keep getting patched so you no longer have to patch every source in the world.
15:23:00 <heat> realistically I'm not about to submit patches to libtool to add my OS to it
15:23:00 <mrvn> Having a patched libtool in your OS is probably good enough for you
15:24:00 <heat> but I'm building Onyx on Linux, not on Onyx
15:24:00 <heat> (yet)
15:24:00 <mrvn> So patch your linux. That's my point. You only need to patch the system you build on, not every source in the world, if the sources use the system libtool.
15:25:00 <heat> well no, my OS builds on every linux
15:25:00 <heat> not just my machine
15:25:00 <heat> that's the point
15:25:00 <mrvn> You have that many users that cross build Onyx? Maybe then you should get a patch into libtool
15:26:00 <heat> i've went to some lengths to get CI set up and everything working perfectly so you could just grab it and build it
15:26:00 <heat> i'm not about to just throw it all away for "nah, nobody's using my crappy system, I'll just patch my system's libtool"
15:27:00 <mrvn> I'm not sure about CIs. But can't you mark the build as depending on libtool so it builds a patched libtool first?
15:27:00 <heat> you also invariably still need to patch all the projects because libtool.m4 is a macro so you need to autogen it
15:27:00 <heat> erm, autoreconf it I mean, just had a brainfart
15:28:00 <mrvn> yes, my suggestion is to make autogen the default.
15:28:00 <heat> huh?
15:28:00 <mrvn> many Debian sources do that by now.
15:28:00 <heat> autoreconf is part of the patch
15:28:00 <heat> not the build
15:29:00 <mrvn> ok, seems like you are doing the right thing already.
15:29:00 <heat> https://github.com/heatd/onyx-package-tree/blob/master/irssi/irssi-1.2.3.patch
15:29:00 <bslsk05> ​github.com: onyx-package-tree/irssi-1.2.3.patch at master · heatd/onyx-package-tree · GitHub
15:30:00 <heat> the actual libtool change isn't that hard once you know what to do, but you need to autoreconf the whole package (so you get a huge 11K patch for the ./configure)
15:30:00 <mrvn> <source>:2:15: error: size of array 'x' exceeds maximum object size '9223372036854775807'
15:30:00 <mrvn> Why is the maximum size (1<<63) - 1? What if I'm the kernel and have control of both halfs of the address space?
15:31:00 <mrvn> heat: many sources in Debian restore or remove the generated files so they don't show up in the diff.
15:32:00 <kingoffrance> mrvn: what would you make size_t ?
15:32:00 <heat> oh sure you can't forget to remove the garbo generated files like the autom4te.cache or whatever that's called
15:32:00 <mrvn> kingoffrance: unitmax_t. Did you mean ssize_t?
15:32:00 <kingoffrance> no
15:32:00 <heat> but you need the other files for the build to succeed, or you just add autoreconf as a build step (and that's just a no for me)
15:33:00 <heat> some Great(tm) packages require specific autoconf and automake versions
15:33:00 <heat> all in all, autotools is a horrible build system
15:33:00 <heat> use meson
15:34:00 <mrvn> heat: sorry to hear that. I have always had far less problems with sources that do run autoreconf than sources that insist on shipping outdated automake/autoconf/libtool files.
15:34:00 <mrvn> The sources that insist on that are usually the ones that break horrible if you ever try to update those files.
15:35:00 <heat> most of them *do* ship the files
15:35:00 <heat> if debian runs autoreconf, that's their problem
15:35:00 <mrvn> and their gain. :)
15:35:00 <heat> no arch linux package does for instance
15:38:00 <kingoffrance> mrvn: a negative offset/address makes sense to me, since it is relative to some point, implying direction. a negative length/size does not
15:39:00 <mrvn> kingoffrance: that's ptrdiff_t. And yes, that would impose a size of intmax_t. Something that breaks on x86.
15:40:00 <heat> real build systems like meson or cmake are self-sufficient and take a single file to help describe your platform/arch
15:40:00 <mrvn> cmake has tons and tons of plugins too.
15:40:00 <heat> there's no "haha now I'm regening files that regen your actual makefile"
15:41:00 <mrvn> well, cmake generates Makefile.
15:41:00 <heat> doesn't matter. If your platform has a platform file, it works
15:41:00 <heat> cmake doesn't generate a script that generates a makefile
15:41:00 <heat> (based on, you guessed it, more files that are generated by running a tool on some other files)
15:42:00 <mrvn> details. The cmake platform file is no different than the systems libtool file. cmake just using fewer steps to go from platform file to building.
15:42:00 <kingoffrance> ^^^ self-sufficiency like portable is just slang for "someone else did the dirty work for you already". does not exist
15:42:00 <kingoffrance> only question is *where* that is done
15:42:00 <kingoffrance> maybe *when*
15:42:00 <mrvn> heat: I don't see cmake sources having an outdated platform file in every source. :)
15:43:00 <heat> normal build systems are 10x as simple as autotools
15:43:00 <mrvn> can't really deny that. Although I can understand Makefiles a lot better than cmake files.
15:43:00 <heat> there's no "hey dawg I heard you like regening files, so I'm regenning the files that regen yo files"
15:43:00 <mrvn> m4 macros not so much
15:44:00 <heat> no shipping of random bits of GNU autotools in the repo, no insane ./configure that sometimes don't hold the same meaning, proper support for system roots and pkgconf
15:45:00 <heat> s/that/optiosn that/g
15:46:00 <heat> given that I supply a proper cross file to meson, this is my patch: https://github.com/heatd/onyx-package-tree/blob/master/glib/glib-2.72.0.patch
15:46:00 <bslsk05> ​github.com: onyx-package-tree/glib-2.72.0.patch at master · heatd/onyx-package-tree · GitHub
15:46:00 <heat> for *glib*
18:26:00 <geist> heat: re: shared. yeah i guess so. but that's not unoiversal
18:27:00 <geist> the arm toolchains seem to
18:27:00 <geist> seems to just be a per arch decision with the idea that you should get a real triple if you want to make shared libs
18:31:00 <heat> gcc iz weird like that
18:32:00 <geist> in this case it's actually binutils which is odd
18:32:00 <geist> i dunno why they'd artificially decide not to let you do it
18:32:00 <geist> unless there's some hidden feature gap there they're trying to protect you from that i'm not aware of
18:34:00 <heat> is it? I remember you had to edit the gcc link spec to pass -shared to the linker for -myos targets
18:35:00 <heat> i686-myos-ld -shared worked
18:37:00 <heat> oh wait yes it is, you pasted the x86_64-elf target spec for binutils
18:37:00 <heat> duh
18:37:00 <heat> the -myos targets you create if you follow the osdev wiki already have that shlib stuff enabled iirc
18:38:00 <heat> geist, btw musl compiles a crt1.o so either rename it or make a -littlekernel target (might be a better option in the long run)
18:39:00 <heat> or just use a fuchsia one, I think it's pretty barebones but still has all the default PIE relro niceties IIRC
18:40:00 <zid> My guess is just that it wants to know about the relocation types that the dynamic linker will use
18:40:00 <zid> and the process of teaching binutils that is called "adding a name to the end of the triple"
18:40:00 <heat> that's part of the ABI
18:40:00 <geist> so it's actually more than that. i just tried the 10 or so arch toolchains i have and only microblaze and riscv-elf binutils dont understand -shared
18:40:00 <geist> all the rest do it
18:41:00 <geist> also yeah i shuild just make a triple, will need to do that soon
18:41:00 <geist> seeing as i already have to patch it for shared lib support, that probably is triple town already
18:41:00 <geist> plus can teach musl build about it that way
18:41:00 <heat> oh oh oh oh
18:41:00 <geist> since i'm going to need to override the way syscalls work there
18:41:00 <heat> use c l a n g
18:42:00 <heat> the liberally licensed C/C++ compiler
18:42:00 <geist> possibly. is it easier to teach clang how to add a new tirple?
18:42:00 <heat> hmm... It's less "touch random weird files and build stuff" and more "write a .cpp making the stuff do the stuff"
18:43:00 <geist> honeslty i'm a little mixed about musl as the thing i want to use now. it seems easy to use, but it's so linux centric i'm unsure if it's the right strategy
18:43:00 <heat> what's the other option?
18:43:00 <geist> and the fact that it explicitly gloms a bunch of things together that i'd kinda rather not be is sort of a meh
18:43:00 <geist> but the rather not be is just a personal opinion, so it's hard to argue against
18:43:00 <heat> wdym?
18:43:00 <geist> ie, not a separate ld.so, networking stuff together, thread stuff together, libm together, etc
18:44:00 <geist> the top page of the musl page says this is an actual goal: make a single lib that does everything, for efficiency purposes
18:45:00 <geist> means it also is a somewhat harder pill to swallow up front, since it has deps on *lots* of syscalls for a bunch of extraneous things whend oing bringup. but i bet i can cut off a bunch of features up front to just get the basics working
18:45:00 <geist> for example just turn off all of the networking features
18:46:00 <heat> since you're using a vdso, make symbols for all the system calls, and stub the ones you don't have
18:46:00 <geist> or at least a separate shared lib yes. and no i'm not using a vdso
18:46:00 <heat> you're not?
18:47:00 <geist> not yet, at least but i have a shared lib i intend to implement the
18:47:00 <geist> i think you overestimage how much stuff i have done
18:47:00 <geist> i literally have like 5 syscalls implemented, and they're all implemented within like a 150 line .cpp file
18:47:00 <heat> s/using/going to use/g was more what I meant
18:48:00 <geist> well, i was at last intending to use a shared/static lib that implements all the syscalls instead of letting code just stamp it out anywhere
18:48:00 <geist> easier to debug that way
18:48:00 <heat> as for the thread stuff, etc: glibc does that too now
18:48:00 <geist> and in the case of musl wanting very linux centric syscalls it'll probably somewhat act like linux
18:48:00 <heat> you don't need to explicitly link with -lrt, -ldl, (possibly -lpthread? can't remember)
18:48:00 <geist> probably has to for the thread stuff since C11 picked up thread features
18:49:00 <geist> oh i totally understand why they do it, it's the trend of modern libcs. you're all going to need ti anyway, and all systems use shared libs, so go ahead and put it in a big shared lib that you get for free
18:49:00 <heat> you underestimate the hackyness of glibc :P
18:49:00 <heat> i bet they had a nice, big giant hack for C11 threads
18:49:00 <geist> but otherwise try to keep the libc stuff modular
18:50:00 <geist> anyway, this is mostly about having fun. so i'm trying to thread a needle because i dont really wnt to write a new libc. was more fun/useful like 20 years ago
18:50:00 <geist> now there's just so much more stuff expected to be done that i'm just not interested in it
18:50:00 <geist> but then i dont want to Just Reimplement Linux
18:50:00 <heat> also fwiw you just need like 10 syscalls for basic musl
18:50:00 <geist> which musl will heavily push you towards
18:51:00 <heat> well... yes I can't disagree with that
18:51:00 <geist> possibly. i mean i'l have to stub out probably 50-100
18:51:00 <heat> but you can definitely resist
18:52:00 <geist> but it seems from radndomly sampling a bunch of it that it has these nice syscall wrappers __syscall(SYS_foo, args) and whatnot that you can probably macroize to call your own function
18:52:00 <geist> looksl ike what we did for fuchsia was basically replace every single one of those with a regular function call
18:52:00 <heat> I was thinking you could automate the stubbing based on the syscalls.h.in
18:52:00 <geist> __syscall(SYS_foo, ) -> foo()
18:52:00 <geist> there was probably some reason for the replacement
18:52:00 <heat> you have like 400 syscalls
18:53:00 <geist> yah i'm not excited about stubbing those out to get to step 1
18:53:00 <heat> what is this, riscv?
18:54:00 <geist> secondly i'm wondering what to do about the built in ld.so. was looking at how it works but it *basically* seems that the way the shared libc.so is linked it expects the kernel to call into it with its entry point
18:54:00 <geist> it seems to expect aux[] and a bunch of stuff already pushed on the stack, etc
18:54:00 <geist> heat: riscv and arm are my first targets, mostly because thats where i have the most support for mmu on LK side
18:55:00 <geist> riscv is so easy to implement core features it's a great place to bootstrap this stuff
18:55:00 <heat> auxv, argv, envp are all part of the ELF(?) ABI
18:55:00 <geist> not sure! AFAIK aux is 100% a linux thing
18:56:00 <heat> you could change those in the entry points
18:56:00 <geist> though maybe not a bad idea per se
18:56:00 <geist> sure, but omg that code is dense as heck. basically like that code we were looking at the other day
18:56:00 <geist> very very unclear what it's doing
18:56:00 <heat> haha
18:56:00 <heat> i know the feeling
18:56:00 <heat> it's 1337 hax0r code
18:57:00 <geist> another strategy is to just not include the ld.so stuff and do my own
18:57:00 <geist> which is frankly kidna fun
18:57:00 <geist> i'm not real keen in the idea that the libc has a built in ld.so
18:57:00 <geist> though for no particular reason, it just seems like it'd be much cleaner to have a simple standalone one
18:58:00 <geist> so that you can, for example not have to implement it if you want some other runtime
18:58:00 <heat> i think roland has a fuchsia ldso branch where he's working on one
18:58:00 <geist> yep
18:58:00 <geist> i forget precisely what we did with that, but anything fuchsia does will bring in tons of C++ and libs and whatnot i'd rather not futz with
18:59:00 <heat> even an ldso?
18:59:00 <geist> i think over the course of the project someone has started a replacement ld.so like 3 times, including a pretty good stab at it in rust
18:59:00 <geist> of course. it is The Way
18:59:00 <heat> fuchsia is slowly rewriting musl huh
18:59:00 <geist> C is almost outright banned in fuchsia, since no one seriously considers it to be a reasonable language
19:00:00 <heat> oh yeah how did nvme.c end up in C?
19:00:00 <geist> tis a shame because anything already written in C is assumed to be hot garbage, even if it isn't. but so it goes
19:00:00 <geist> was written extremely early
19:00:00 <geist> we need a maintainer of it actually
19:00:00 <geist> surprisingly for most of our internal testing we've been generally buying SATA m.2 cards, apparently. just because
19:00:00 <geist> but it's getting such that we can't ignore nvme
19:01:00 <geist> but up until now that driver has been pretty solid so no one has had to fix a bug in it in years really
19:01:00 <clever> it aint broke, dont fix it!
19:03:00 <geist> totes
19:03:00 <geist> mcgotes
19:36:00 <geist> grr, so somewhat annoyingly i stick in an old ryzen cpu to my crashy server and it seems stable
19:36:00 <geist> so... thats sort of the worst case scenario, since that proves nothing at all. if it continued to crash then i know it's probably the motherboard
19:37:00 <geist> but, since it doesn't it proves nothing: could be the cpu, could be the vregs on the motherboard (because the server cpu pulls more power), could be the power supply ( because it pulls more power)
19:40:00 <zid> Overclock the balls off it
19:40:00 <zid> oh wait..
19:41:00 <zid> geist: You can debug my machine if you like it's easier, I think it just needs a psu.
19:43:00 <clever> geist: i'm also starting to suspect voltage on my rpi-zero crashes, i switched to a different usb cable, and now its crashing a lot more
19:43:00 <clever> i need to setup the scope again and monitor the voltages
19:45:00 <GeDaMo> https://www.theregister.com/2022/05/16/arm_runs_on_algae_electricity/
19:45:00 <bslsk05> ​www.theregister.com: Arm CPU ran on electricity generated by algae for six months • The Register
19:47:00 <clever> geist: probably a cortex-m
19:47:00 <clever> oops, GeDaMo ^
19:48:00 <GeDaMo> "Arm Cortex M0+ CPU"
19:49:00 <clever> yeah, those run on much less
19:52:00 <geist> cute!
19:52:00 <GeDaMo> Now, how much algae do I need to run my desktop? :P
19:53:00 <heat> depends if you're running an i9-12900K
19:53:00 <geist> presumably you need to actually keep it alive
19:53:00 <heat> you need an oil tanker for those
19:53:00 <zid> good news is that my psu is out of warranty, it turns out
19:55:00 <geist> yah thankfully there are some really good high quality PSUs nowadays
19:55:00 <geist> in general most of my computer failures i the past have been PSU related
19:55:00 <zid> I bought a good one :(
19:55:00 <zid> I figured it'd last ages
19:55:00 <geist> how do you know it's the psu?
19:56:00 <zid> well there's very little other reason that the mobo's voltage sensors would show the 3.3V rail noticeably dipping under load that I can think of
19:56:00 <geist> ah what sort of dip are you seeing?
19:56:00 <zid> enough that the board shuts down due to a 'power event' :p
19:56:00 <geist> ah
19:57:00 <geist> i tested the psu in mine and it seems solid. theonly part that is a little off is it's reading 3.2 on the 3.3 rail
19:57:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/977296949994741830/unknown.png sensor isn't calibrated so the absolute value is off by like .2V
19:57:00 <zid> but that's what opening prime95 looks like
19:57:00 <geist> OTOH the tester only has 2 significant digits there so could be anywhere
19:58:00 <geist> ah. that being said since modern cpus run on <1V or so it seems strange that the VREGs couldn't deal with that
19:58:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/977299206752587796/unknown.png longer timebase
19:58:00 <geist> alas this mobo doesn't have any power sensors
19:58:00 <kazinsal> I should probably buy a new PSU, this one's uh
19:58:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/977299332128735313/unknown.png affects all the rails actually
19:58:00 <kazinsal> probably 12 years old
19:58:00 <zid> I think the psu is just old and degrading, can't supply the full wattage anymore
19:59:00 <geist> the main transformer or whatnot
19:59:00 <geist> i always forget if startig from 220v is more or less work for a PSU. i think less work because it's less current flow through the transformer, etc
19:59:00 <zid> or the switching circuitry's timing cap or whatever depends how it's set up
20:00:00 <GeDaMo> zid: is it possible it's an external problem?
20:00:00 <zid> 240V is less aggressive current wise so less heat, but you need fancier rated components
20:00:00 <zid> GeDaMo: The mains knows I started prime95 and is dropping to 200V?
20:00:00 <geist> yah
20:00:00 <geist> you browned out your house
20:00:00 <zid> It has a 20kW supply, I hope not
20:01:00 <heat> less me is bad
20:01:00 <geist> only 20kW? that seems pretty low for a house
20:01:00 <zid> 240V * 90A
20:01:00 <zid> A lot of people only get 30A I've found
20:02:00 <geist> yah okay i guess that's right. usually we say amps here for how much a house/building gets but never really multiplied it out
20:02:00 <zid> a dead short aka electric kettle is 3kW
20:02:00 <geist> ie, 120V * 200A
20:02:00 <geist> yah i was doing the math just yesterday on my electric water heater, figuring out how mnay kWh it uses to heat up a full thing
20:03:00 <zid> I found out that the US does 220-240 but it's center tapped so you have to connect hot to hot to get it
20:03:00 <geist> approx 240L capacity, about 5kW heater. to raise a bunch of water from 10-80C is like 19kWh
20:03:00 <zid> 5kW? fancy.
20:03:00 <zid> That'd blow all my fuses.
20:03:00 <geist> yah it's pretty fancy. it's on it's own 220 circuit
20:04:00 <zid> I'd have to put a different breaker on
20:04:00 <geist> you should see the breaker box in his house, it's crazy
20:04:00 <geist> like two full breaker boxes, each with a 200A breaker at the top
20:04:00 <zid> why on earth
20:04:00 <geist> whoever built it went to town
20:04:00 <zid> https://smartelectricians.co.uk/wp-content/uploads/2019/09/Consumer-Unit.jpg UK gear looks identical to this
20:05:00 <zid> bus bars and breakers
20:05:00 <geist> lots of 220 circuits and a whole backup 20kW generator that owns one of the breaker boxes
20:05:00 <zid> bathrooms will generally be on a 30mA RCD
20:05:00 <geist> so they split it by things the generator would take over and the Beefy Stuff like the heat pump, electric water heater, etc
20:06:00 <_Heat> i am a reserved identifier now
20:06:00 <zid> Then a case goes over that lot
20:06:00 <zid> https://www.designingbuildings.co.uk/w/images/7/70/Consumer_unit_photo.JPG
20:07:00 <zid> Then a flip down panel covers the switches
20:07:00 <zid> It's pretty neat and tidy all round, I like it
20:35:00 <mrvn> and power in europe has been rising over time from 220 to 230 to 240. Not sure if that's still ongoing. But old PSU would get more power than they used to.
20:38:00 <mrvn> Why does std::construct_at(p, A{1}) and A{A{1}} produce different function calls, i.e why does the first do a move construct? Shouldn't they copy elide to the same?
20:39:00 <mrvn> Both should be <addr>->A{A{1]] basically
21:02:00 <Griwes> it's conceivable for an implementation to have an optimization pass that optimizes out the move in construct_at, but I am not quite certain that it is actually allowed to elide it there. there's a difference because construct_at takes a reference and that's not transparent to the language
21:04:00 <mrvn> I think it would have to be something specified in the langauge, specifically that placement new may (or must?) copy-elid.
21:05:00 <mrvn> Seems stupid that construction of objects on the stack can elide more than constructing on the heap.
22:44:00 <Griwes> I mean placement new can elide
22:44:00 <Griwes> but construct_at is not *quite* placement new
22:48:00 <mrvn> Griwes: it's a template that calls placement new here.
22:49:00 <mrvn> ##### new(p)A{A{1}} #####
22:49:00 <mrvn> @0xe3eeb0: full A::A(int)
22:49:00 <mrvn> but you are right.
22:50:00 <mrvn> { return ::new((void*)__location) _Tp(std::forward<_Args>(__args)...); }
22:50:00 <Griwes> yes - but functions aren't syntactic macros :P
22:50:00 <mrvn> yeah. I want a NVAO - non value argument optimization.
22:52:00 <mrvn> Griwes: I assume the compiler inlines that completly. So the only thing stopping the compiler from generating code like with a macro must be the standard saying it can't elide there.
23:04:00 <geist> re: raising from 220 to 240, is that an attempt to standardize on a single voltage or something?
23:05:00 <geist> as a side note i read somewhere a theory that UK, etc standardized on 50hz vs 60hz because at the time they had issues with getting high enough quality bearings to run generators at 360rpm or so
23:06:00 <geist> but in general a higher rate is more desirable because of various efficiences
23:06:00 <mrvn> only reason I know is that higher voltage is more efficient.
23:06:00 <mrvn> Conspiracy nuts say it's to burn out old 220V appliance so you buy a new one.
23:07:00 <geist> requires i think smaller capacitors and/or transformers to deal with the swing
23:07:00 <geist> when it flips faster
23:07:00 <mrvn> hehe, that reminds me of when I took my electric clock on board the Destroyer during military service. Germany bought them from the US so naturally they run a 60Hz electrical net.
23:08:00 <mrvn> The clock runs of the electrical frequenzy so it was 20% fast.
23:08:00 <geist> yep anything with an AC motor would have that problem
23:08:00 <mrvn> digital clock
23:09:00 <geist> computer wise i was reading the timer board on a PDP11 (and other similar) basically counts zero crossings of the input mains
23:09:00 <geist> so there's a jumper and/or a separate board for 50 vs 60hz
23:09:00 <zid> why would anybody change from 220 to 240 geist?
23:09:00 <geist> probably same thing with the digital clock: no on board oscillator, just a zero crossing detector, maybe
23:10:00 <geist> zid: i have no idea, mrvn mentioned it
23:10:00 <mrvn> zid: efficiency
23:10:00 <zid> ah that explains that
23:10:00 <mrvn> transmission loss is proportional to voltage.
23:10:00 <mrvn> Ever wonder why the long distance overland lines are like 10kV?
23:10:00 <zid> fun fact about that is that the standard is 230V with error bands, so that the UK can keep using 240 and other places can keep using 220
23:10:00 <zid> and afaik it's assymetrical, like 230 -5% +10%
23:11:00 <geist> i'd tend to think that within the EU there'd have been an incentive to standardize on precisely one voltage so grids could interconnect
23:11:00 <zid> because 240V + error puts it nearer 250 half the time
23:11:00 <zid> it's close enough that it makes no difference, you just buy 500V caps
23:11:00 <zid> and they're all sold by the same company in bulk precisely for the purpose
23:11:00 <geist> except that messes with phase, as substations have to fiddle with all the time
23:12:00 <clever> geist: i think freq is more important then voltage for interconnect, because a multi-tap transformer can deal with the voltage difference
23:12:00 <geist> to keep different patrs of the grid synchronized
23:12:00 <geist> clever: probably true, yes
23:12:00 <zid> They transmit at kilovolt scales anyway
23:12:00 <clever> but frequency differences need a massive ac->dc->ac facility, like the one near me
23:12:00 <zid> it's only local substations that care about the exact frequency, and power supplies in appliances
23:12:00 <geist> its my understanding that a lot of the bulk of those big substations are to adjust the phase of various lines to sync up
23:12:00 <clever> https://en.wikipedia.org/wiki/Eel_River_Converter_Station
23:12:00 <bslsk05> ​en.wikipedia.org: Eel River Converter Station - Wikipedia
23:12:00 <zid> err exact voltage*
23:13:00 <geist> and/or large inverters to deal with DC transmission lines
23:13:00 <clever> geist: at least in NA, there are also "voltage regulators" you can see on the sides of the roads, that re-boost the voltage on long cables
23:13:00 <zid> Almost all of our infra is hidden :(
23:13:00 <geist> yah makes sense
23:14:00 <clever> https://www.electricaleasy.com/2018/04/voltage-control-in-power-system.html
23:14:00 <bslsk05> ​www.electricaleasy.com: Methods of voltage control in power system | electricaleasy.com
23:14:00 <clever> this is a bank of multi-tapped transformers
23:14:00 <zid> There's a small shack near me that is my local substation, it's on a concrete plinth surrounded by atomically clean gravel wrt weeds, then a big fence
23:14:00 <clever> that compensate for the sag on the high voltage lines
23:14:00 <zid> and all the cables are completely underground
23:14:00 <geist> yah i always assume that the power lines pre-local transformer are a kV or something so the transformer has something to step down from
23:14:00 <clever> in my area, its 7200vac phase to ground, 12470 phase to phase, 3 phases total
23:15:00 <zid> https://c8.alamy.com/comp/S2B33P/electricity-substation-uk-S2B33P.jpg
23:15:00 <clever> and 7200->120 is just a /60 division
23:15:00 <zid> Kinda like that
23:15:00 <clever> so a 60:1 transformer gives you 120v
23:15:00 <geist> i was actually kinda wondering how stuff comes into my house to be honest, since i'm in the woods and the power is underground
23:15:00 <zid> Power cables come in, drop down to 240V, go out again
23:15:00 <geist> it doesn't seem intrinsincally obvious where it Goes once it leave smy property
23:15:00 <zid> probably follows the roads geist
23:16:00 <clever> https://openinframap.org/#12.4/48.01252/-66.42803
23:16:00 <bslsk05> ​openinframap.org: Open Infrastructure Map
23:16:00 <clever> this site shows the electrical grid for the entire world
23:16:00 <geist> i'd think that, but then the next obvious road near my house i dont see where it hooks up to the lines
23:16:00 <clever> and these coords are for the eel river converter station
23:16:00 <geist> so thinking it might exit on some other path to another road
23:16:00 <zid> maptiler, never heard of that map provider before
23:16:00 <clever> the quebec grid isnt synced to the nb/ns/pei grid
23:16:00 <clever> zid: its part of OSM
23:17:00 <clever> so, while quebec and nb are both 60hz, they are drifting in and out of phase
23:17:00 <zid> 132kV line serves me apparently
23:17:00 <geist> https://openinframap.org/#11.18/47.6513/-122.5403 is where i live and you see that fork and how there's oe line coming into the island? thats why we lose power a lot
23:17:00 <bslsk05> ​openinframap.org: Open Infrastructure Map
23:17:00 <clever> this converter station does the whole ac->dc->ac conversion
23:17:00 <geist> any one of those lines gets a tree on it, lots of folks are out
23:17:00 <zid> then it's stepped down to 33kV to enter the town itself
23:18:00 <mrvn> If 2 power pants in the whole grid run out of pahse then they would just cancel each other (partially). Power companies are verry accurate with the frequency.
23:18:00 <zid> oh and there's fucking.. 2.7MW solar farm at the back of town? til
23:18:00 <zid> and 9MW of wind turbines, I knew about those, I can see them :p
23:18:00 <kazinsal> oh hey that map works north of the border too, neat
23:18:00 <clever> kazinsal: yep, global database
23:19:00 <zid> Huh that's kinda interesting. The local city has a power station and grind interconnect, the 132kV transmission lines from it go PAST me to a different town, where it is stepped back to 33kV. It then goes underground back toward the power plant to get to me.
23:19:00 <clever> geist: those lines on the map at 115kv feeding the substations, i find it highly unlikely that those get hit by trees
23:19:00 <clever> would be a really expensive accident
23:19:00 <geist> they do. frequently
23:19:00 <zid> trees get vaporized when that happens
23:19:00 <geist> and it takes out that whole arm of the island. to the point that they're basically starting a project to build a bridge by addnig another line to bridge the two substations
23:20:00 <clever> around here, you have massive clearings around those lines
23:20:00 <clever> so there is no risk of that
23:20:00 <geist> yah, the woods here are dense, with tall ass trees
23:20:00 <zid> I've seen helis with enourmous disc cutters dangling down cutting trenches
23:20:00 <geist> i have probably a solid 20 trees just in my yard that are well over 100 feet
23:20:00 <zid> https://i.ytimg.com/vi/lQyeSGqlkOs/maxresdefault.jpg
23:21:00 <zid> I want one.
23:21:00 <kazinsal> interesting, there's no data for point roberts
23:21:00 <kazinsal> kinda wondered where the power there came from
23:21:00 <geist> there's that one guy with the bicycle generator
23:21:00 <geist> and sometimes the people take turns
23:21:00 <clever> kazinsal: yeah, its basically the wikipedia of maps, so users need to add the data, from compatibly licenses sources
23:21:00 <zid> We have a power_line_1 at 400kV apparently, that's all the super power stuff
23:21:00 <geist> that map seems to stop at substatios, so i guess they get non substationed stuff from north of teh border
23:21:00 <clever> geist: this giant scar in the forest is what keeps the power going: https://www.google.ca/maps/@48.0528978,-66.3969106,750m/data=!3m1!1e3
23:21:00 <bslsk05> ​www.google.ca: Google Maps
23:22:00 <kazinsal> I bet PSE just buys a few hundred kilowatts from BC Hydro
23:22:00 <clever> geist: more about if the local OSM users care about mapping every single telephone pole
23:22:00 <geist> but yeah we lose a lot of lines here, though it's getting better
23:22:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/977350650562216006/unknown.png That's cool
23:22:00 <geist> the island likes its woods so you can't have em both, since we'd have to clear like 50-100 feet away from the lines, and that's totally not going to happen
23:23:00 <kazinsal> aha, yep, from the BC Hydro website: "Distribution Line (partially overhead and partially underground) from the Tsawwassen Substation within 56th Street road allowance in Delta, BC to the U.S. Border at Point Roberts, WA"
23:23:00 <clever> geist: diagonal trim the height of the trees?
23:23:00 <clever> no tree is allowed to be taller then the distance from its base to the wires
23:23:00 <geist> https://www.google.com/maps/@47.6690621,-122.5211065,3a,46.1y,32h,110.46t/data=!3m6!1e1!3m4!1s7I1pos60HA7Dygx_sF6Ufw!2e0!7i16384!8i8192 for example is one of the main 115kV lines
23:23:00 <bslsk05> ​www.google.com: Google Maps
23:24:00 <zid> fucking hell
23:24:00 <zid> america what are you doing
23:24:00 <clever> jesus
23:24:00 <geist> woods!
23:24:00 <geist> folks like them some woods!
23:24:00 <clever> thats not how you treat 115kv lines
23:24:00 <geist> but yes this is why my house as a 20kW gasoline generator
23:24:00 <kazinsal> they're insulated, it's fine
23:25:00 <zid> did you all read the oil filled transmission line repair usenet post thing
23:26:00 <zid> https://www.jwz.org/blog/2002/11/engineering-pornography/
23:26:00 <bslsk05> ​www.jwz.org: jwz: engineering pornography
23:26:00 <mrvn> int foo(int a[static 10]); What's the meaning of static there?
23:26:00 <geist> https://www.google.com/maps/@47.6570252,-122.5082134,3a,75y,116.29h,92.02t/data=!3m6!1e1!3m4!1s5yP0c2LKltHuitCT_KBH4Q!2e0!7i16384!8i8192 is why. folks want to live in places like this
23:26:00 <bslsk05> ​www.google.com: Google Maps
23:26:00 <geist> also see seattle in the distance? if it weren't so cloudy you'd also see the Giant Volcano
23:26:00 <moon-child> mrvn: same as int *a, except that a _must_ point to 10 integers
23:26:00 <moon-child> can't be null, can't point to fewer than 10 integers
23:27:00 <moon-child> otherwise ub. But mainly used as a declaration of intent
23:27:00 <clever> geist: you can get similar views in southern nb
23:27:00 <kazinsal> mmm, yep, if I lived in the seattle area and had faang money I would definitely be living on bainbridge and working from home
23:27:00 <geist> looking at the thriving metropolis of.. uh
23:27:00 <mrvn> moon-child: https://godbolt.org/z/E3a9qMqeh Works "fine" with smaller array.
23:27:00 <bslsk05> ​godbolt.org: Compiler Explorer
23:28:00 <mrvn> moon-child: I'm asking about the "static", not the "10".
23:28:00 <kazinsal> the power outage issues we have in my neck of the woods are primarily because this area was originally farmland built on a one mile grid so at best you've got power poles running mostly north-south every mile and occasionally crossing east-west once every few
23:28:00 <clever> geist: hows this view? https://goo.gl/maps/yF4zbJGMv4JHejNF7
23:28:00 <bslsk05> ​redirect -> www.google.com: Google Maps
23:28:00 <moon-child> mrvn: int a[10] is literally the same as int *a. The 'static' is what adds the requirement
23:28:00 <clever> i just dropped the street-cam on a random road within the island
23:29:00 <kazinsal> so if a tree falls into an east-west line it can bonk 15k peoples power offline for four or five hours
23:29:00 <kazinsal> as is the case of what happened to me on wednesday
23:29:00 <moon-child> mrvn: 'works "fine"' yep ... that's ub for you. Notice it does give a warning. But it doesn't have to and the compilers aren't very good about doing it
23:29:00 <geist> clever: oh it's on the bay of fundy! gets a huge tidal interchange. i wonder how bad it is that far south?
23:29:00 <clever> geist: further east, in the gap between NS and NB, is where its the highest
23:30:00 <clever> because the resonant freq of the water sloshing in/out, matches the tides
23:30:00 <mrvn> moon-child: It's UB with or without the static, assuming the function accesses the array. But I do see an extra warning with static: <source>:5:5: warning: argument 1 to 'int[static 40]' is null where non-null expected [-Wnonnull]
23:30:00 <clever> and it adds up
23:30:00 <geist> yah minas basin, etc
23:30:00 <mrvn> moon-child: your description sounds like it should be an error to pass 0 or int[5].
23:30:00 <geist> that island is pretty much open ocean it seems
23:30:00 <geist> anyway, /me lets actual programming discussion occur
23:30:00 <clever> geist: but grand manan is running entirely off underwater power lines
23:31:00 <geist> also ooooh, my esp32-c3 (riscv based esp32) board just showed up in the mail
23:31:00 <moon-child> mrvn: it's ub anyway if the function accesses array[9]. But if you declare as [static 10], then it's ub to _pass_ something null or smaller, even if it's never accessed
23:31:00 <moon-child> mrvn: no, I said it's ub, not an error
23:31:00 <moon-child> if you just declare as int a[10], then it's _exactly_ the same as if you declare as int *a
23:32:00 <mrvn> I'm disapointed by gcc. If I pass int[5] to foo it should eliminate the whole call, that's what gcc always does with UB. Optimize away. :)
23:32:00 <mrvn> moon-child: it's not the same, it just decays to int*. The tyoe still has a size and the compiler can uses that to check for buffer overflows.
23:33:00 <kazinsal> huh, didn't know washington had so much wind power. neat
23:34:00 <mrvn> How about Chicago, the windy city. They must have lots of wind power, right?
23:34:00 <moon-child> mrvn: I was perhaps not clear enough. void f(int a[5]) is exactly the same as void f(int *a)
23:34:00 <moon-child> obviously a naked int *a in a function body is not the same as int a[5] in the same context
23:34:00 <mrvn> moon-child: you where clear but also wrong. Inside f it's a different type.
23:35:00 <mrvn> nm, we agree
23:35:00 <geist> kazinsal: yah the power here is pretty clean, one of the things i like about it
23:35:00 <mrvn> geist: but is it yellow?
23:35:00 <zid> Okay re-read the usenet post, always good fun
23:35:00 <kazinsal> yeah geographically the northern half of the PNW is phenomenal for clean energy
23:35:00 <geist> i pay a bit of a premium with PSE to get 100% clean power. it's a bit of a shell game, but they do a report as to where it all goes, etc
23:36:00 <kazinsal> BC's 95% renewables, with the last 5% being just remote communities in the far north that literally have nothing else available
23:37:00 <geist> yah that generally is an issue with living in some remote ass place
23:37:00 <kazinsal> kinda hope they turn the old burrard natgas power station into a museum now that it's been decommissioned. they did that with the old stave falls powerhouse when they built the new one a couple decades ago
23:38:00 <zid> https://www.gridwatch.templar.co.uk/
23:38:00 <bslsk05> ​www.gridwatch.templar.co.uk: G. B. National Grid status
23:38:00 <zid> 43% wind for the UK right now apparently
23:39:00 <zid> 0% coal, 31% natty gas, 21% nuclear
23:39:00 <mrvn> kazinsal: cheaper that tearing it down and doing an environmental cleanup?
23:40:00 <kazinsal> probably. also a neat educational thing
23:40:00 <kazinsal> burrard thermal was only really meant to be a generating station for peak demands
23:41:00 <kazinsal> as soon as hydro built another powerhouse at one of the main dams on the columbia they decommissioned burrard thermal and it's been dormant since
23:44:00 <geist> they should brew beer there
23:46:00 <clever> zid: https://youtu.be/lQyeSGqlkOs?t=175
23:46:00 <bslsk05> ​'Helicopter air saw trimming trees - Helicopter trimming trees by high tensions lines' by Amazing Tube (00:10:30)
23:48:00 <mrvn> clever: and now a little to the left please. NO, my left.
23:48:00 <clever> :D
23:50:00 <mrvn> .oO(I measure performance on a geological timescale)
23:52:00 <klange> If your program completes before the heat death of the universe, it's fast enough.
23:53:00 <mrvn> I miss the time when you optimized your software by waiting 6 month for the faster hardware.