klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
troseman has joined #osdev
<klange> < GeDaMo> I thought it was an Of Mice and Men reference but OK :P ← Parody Displacement
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
gog has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
kingoffrance has quit [Ping timeout: 248 seconds]
heat_ has joined #osdev
heat has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
rustyy has quit [Quit: leaving]
heat_ is now known as heat
Likorn has quit [Quit: WeeChat 3.4.1]
<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?
<bslsk05> ​godbolt.org: Compiler Explorer
<mrvn> this == v.emplace_back(A{1})
dude12312414 has joined #osdev
<heat> every time you ask a question it makes me want to rewrite everything in rust
<heat> or C
<mrvn> 1) why isn't the vector constructor using move if it won't elide?
<heat> either a future-is-now-old-man language, or the old man language
<mrvn> heat: I'm getting there.
<mrvn> heat: but is rust any better with avoiding useless copying?
<heat> i hope so?
<gamozo> Rust solves it
<heat> at least it has destructive moves, and thats a good thing
<mrvn> heat: I don't even want to move, I want to constgruct in-place.
<mrvn> ##### A a{A{A{A{A{A{1}}}}}} #####
<mrvn> @0x7ffc8a13ef1b: fullA::A(int)
<mrvn> When I construct an A then it copy elides all the intermediate constructors perfectly. But not with vectors.
<heat> i write my stuff in C++ for RAII and classes really
<heat> sometimes templates
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<geist> AAAAAA
* gamozo segfaults
dh` has quit [Remote host closed the connection]
<heat> gets strikes again
<heat> now we find rop gadgets and RCE gamozo
<gamozo> Don't forget the ASLR bypass
scoobydoob has joined #osdev
scoobydoo has quit [Ping timeout: 248 seconds]
scoobydoob is now known as scoobydoo
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
scoobydoob has joined #osdev
scoobydoo has quit [Ping timeout: 246 seconds]
scoobydoob is now known as scoobydoo
scoobydoob has joined #osdev
scoobydoo has quit [Ping timeout: 276 seconds]
scoobydoob is now known as scoobydoo
les has quit [Quit: Adios]
les has joined #osdev
scoobydoo has quit [Ping timeout: 246 seconds]
scoobydoo has joined #osdev
chart has joined #osdev
chartreus has quit [Read error: Connection reset by peer]
rustyy has joined #osdev
klys has quit [Ping timeout: 260 seconds]
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
gog has quit [Ping timeout: 276 seconds]
heat has quit [Ping timeout: 248 seconds]
chartreus has joined #osdev
chart has quit [Ping timeout: 272 seconds]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
radens has joined #osdev
<radens> Does anyone have a copy of the original l3 source code?
<radens> I'm finding a lot of dead links and some things which are not the kernel, which is what I'm after
troseman has quit [Ping timeout: 240 seconds]
elastic_dog has quit [Ping timeout: 244 seconds]
elastic_dog has joined #osdev
No_File has joined #osdev
wxwisiasdf has joined #osdev
Likorn has joined #osdev
<geist> hmm, good question
<geist> was a long time back, may have just been before git/etc
wxwisiasdf has quit [Quit: leaving]
No_File has quit [Quit: Client closed]
MelMalik is now known as AmyMalik
archenoth has quit [Read error: Connection reset by peer]
archenoth has joined #osdev
orthoplex64 has quit [Ping timeout: 276 seconds]
dormito has quit [Ping timeout: 240 seconds]
dormito has joined #osdev
<geist> been fiddling with musl for the last hour and i have to say it's pretty easy to work with
<geist> just configure and go, seems to be self contained
toluene has quit [Quit: Ping timeout (120 seconds)]
<geist> it builds entirely for linux, of course, but it looks *fairly* straightforward to redirect the syscalls to another library
<geist> it builds really fast too, so that's nice
<geist> like 10 seconds on this computer
orthoplex64 has joined #osdev
toluene has joined #osdev
eroux has joined #osdev
<geist> also ugh. looks like riscv64-elf toolchain doesn't support creating shared libs for some reason
<geist> lemme see if i can hack that and build a new copy
eroux has quit [Quit: Textual IRC Client: www.textualapp.com]
elderK has quit [Quit: Connection closed for inactivity]
the_lanetly_052 has joined #osdev
<geist> seems to be in binutils actually
<bslsk05> ​github.com: binutils-gdb/elf32lriscv-defs.sh at master · bminor/binutils-gdb · GitHub
Likorn has quit [Quit: WeeChat 3.4.1]
eroux has joined #osdev
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eroux has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
radens has quit [Quit: Connection closed for inactivity]
puck has quit [Excess Flood]
puck has joined #osdev
Celelibi has quit [Ping timeout: 260 seconds]
Celelibi has joined #osdev
ethrl has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
Burgundy has joined #osdev
wand has quit [Remote host closed the connection]
wand has joined #osdev
No_File has joined #osdev
GeDaMo has joined #osdev
nyah has joined #osdev
jafarlihi has joined #osdev
henistein has joined #osdev
jafarlihi has quit [Quit: WeeChat 3.5]
gog has joined #osdev
No_File has quit [Quit: Client closed]
<ddevault> navigating the seL4 source code is a nightmare
<ddevault> it goes to extreme measures to hide its data structures from you
bauen1 has joined #osdev
<gog> enhanced security by enhanced obscurity
<zid> That's a security feature in itself :P
<zid> If you can't find them in the code you can't dereference pointrs to them
<ddevault> does anyone know of some good technical hangouts where I can chat with seL4 experts to better understand their design?
<ddevault> I'm pretty pleased with its API design but the implementation is super hard to follow
gildasio has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
vimal has joined #osdev
eroux has quit [Ping timeout: 272 seconds]
scoobydoob has joined #osdev
scoobydoo has quit [Read error: Connection reset by peer]
scoobydoob is now known as scoobydoo
blockhead has quit []
henistein has quit [Quit: Client closed]
Dyskos has joined #osdev
dennis95 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Burgundy has quit [Ping timeout: 276 seconds]
chartreus has quit [Ping timeout: 240 seconds]
pretty_dumm_guy has joined #osdev
jafarlihi has joined #osdev
<jafarlihi> Does QEMU generate IRQ of 1 when a key is pressed on the keyboard?
troseman has joined #osdev
<Mutabah> Since it emulates an 8042 PS2 controller, yes
<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?
gog has quit [Ping timeout: 260 seconds]
heat has joined #osdev
<zid> PIT mask
<zid> err PIC
<zid> cli
<heat> geist, generally the -elf targets can't make shared objects
<heat> it's just something you need to enable and then PATCH EVERY LIVING COPY OF LIBTOOL.M4
jafarlihi has quit [Quit: WeeChat 3.5]
<heat> glad you're enjoying musl though
<heat> the ./configure is not even a regular configure script, it just creates a config.mak to feed into the manually-written makefile
rpnx-phone has joined #osdev
<mrvn> forgot to EOI it on init?
<heat> chances are it's masked in the PIC or in the eflags
Likorn has joined #osdev
<mrvn> heat: instead of patching it you should remove it and use the systems one to build.
<heat> i'm not patching system files.
<heat> "why does your OS require sudo to build?" "because I'm meddling in your system files" <-- ???
<mrvn> they should already be patches (at some point in the future)
<mrvn> The advanatge is that the system file will keep getting patched so you no longer have to patch every source in the world.
<heat> realistically I'm not about to submit patches to libtool to add my OS to it
<mrvn> Having a patched libtool in your OS is probably good enough for you
<heat> but I'm building Onyx on Linux, not on Onyx
<heat> (yet)
<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.
<heat> well no, my OS builds on every linux
<heat> not just my machine
<heat> that's the point
<mrvn> You have that many users that cross build Onyx? Maybe then you should get a patch into libtool
<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
kingoffrance has joined #osdev
<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"
<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?
<heat> you also invariably still need to patch all the projects because libtool.m4 is a macro so you need to autogen it
<heat> erm, autoreconf it I mean, just had a brainfart
<mrvn> yes, my suggestion is to make autogen the default.
<heat> huh?
<mrvn> many Debian sources do that by now.
<heat> autoreconf is part of the patch
<heat> not the build
<mrvn> ok, seems like you are doing the right thing already.
<bslsk05> ​github.com: onyx-package-tree/irssi-1.2.3.patch at master · heatd/onyx-package-tree · GitHub
<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)
<mrvn> <source>:2:15: error: size of array 'x' exceeds maximum object size '9223372036854775807'
<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?
<mrvn> heat: many sources in Debian restore or remove the generated files so they don't show up in the diff.
<kingoffrance> mrvn: what would you make size_t ?
<heat> oh sure you can't forget to remove the garbo generated files like the autom4te.cache or whatever that's called
<mrvn> kingoffrance: unitmax_t. Did you mean ssize_t?
<kingoffrance> no
<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)
<heat> some Great(tm) packages require specific autoconf and automake versions
<heat> all in all, autotools is a horrible build system
<heat> use meson
<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.
<mrvn> The sources that insist on that are usually the ones that break horrible if you ever try to update those files.
<heat> most of them *do* ship the files
<heat> if debian runs autoreconf, that's their problem
<mrvn> and their gain. :)
<heat> no arch linux package does for instance
<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
<mrvn> kingoffrance: that's ptrdiff_t. And yes, that would impose a size of intmax_t. Something that breaks on x86.
<heat> real build systems like meson or cmake are self-sufficient and take a single file to help describe your platform/arch
<mrvn> cmake has tons and tons of plugins too.
<heat> there's no "haha now I'm regening files that regen your actual makefile"
<mrvn> well, cmake generates Makefile.
<heat> doesn't matter. If your platform has a platform file, it works
<heat> cmake doesn't generate a script that generates a makefile
<heat> (based on, you guessed it, more files that are generated by running a tool on some other files)
<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.
<kingoffrance> ^^^ self-sufficiency like portable is just slang for "someone else did the dirty work for you already". does not exist
<kingoffrance> only question is *where* that is done
<kingoffrance> maybe *when*
<mrvn> heat: I don't see cmake sources having an outdated platform file in every source. :)
<heat> normal build systems are 10x as simple as autotools
<mrvn> can't really deny that. Although I can understand Makefiles a lot better than cmake files.
<heat> there's no "hey dawg I heard you like regening files, so I'm regenning the files that regen yo files"
<mrvn> m4 macros not so much
<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
<heat> s/that/optiosn that/g
<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
<bslsk05> ​github.com: onyx-package-tree/glib-2.72.0.patch at master · heatd/onyx-package-tree · GitHub
<heat> for *glib*
sonny has joined #osdev
Dyskos has quit [Quit: Leaving]
rpnx-phone has quit [Ping timeout: 272 seconds]
No_File has joined #osdev
blockhead has joined #osdev
Burgundy has joined #osdev
kingoffrance has quit [Ping timeout: 240 seconds]
troseman has quit [Ping timeout: 240 seconds]
dennis95 has quit [Quit: Leaving]
valerius_ is now known as valerius
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
dh` has joined #osdev
sonny has quit [Remote host closed the connection]
<geist> heat: re: shared. yeah i guess so. but that's not unoiversal
<geist> the arm toolchains seem to
<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
No_File has quit [Quit: Client closed]
<heat> gcc iz weird like that
sonny has joined #osdev
<geist> in this case it's actually binutils which is odd
<geist> i dunno why they'd artificially decide not to let you do it
<geist> unless there's some hidden feature gap there they're trying to protect you from that i'm not aware of
<heat> is it? I remember you had to edit the gcc link spec to pass -shared to the linker for -myos targets
<heat> i686-myos-ld -shared worked
<heat> oh wait yes it is, you pasted the x86_64-elf target spec for binutils
<heat> duh
<heat> the -myos targets you create if you follow the osdev wiki already have that shlib stuff enabled iirc
<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)
<heat> or just use a fuchsia one, I think it's pretty barebones but still has all the default PIE relro niceties IIRC
<zid> My guess is just that it wants to know about the relocation types that the dynamic linker will use
<zid> and the process of teaching binutils that is called "adding a name to the end of the triple"
<heat> that's part of the ABI
<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
<geist> all the rest do it
<geist> also yeah i shuild just make a triple, will need to do that soon
X-Scale has quit [Ping timeout: 256 seconds]
<geist> seeing as i already have to patch it for shared lib support, that probably is triple town already
<geist> plus can teach musl build about it that way
<heat> oh oh oh oh
<geist> since i'm going to need to override the way syscalls work there
<heat> use c l a n g
<heat> the liberally licensed C/C++ compiler
<geist> possibly. is it easier to teach clang how to add a new tirple?
X-Scale` has joined #osdev
<heat> hmm... It's less "touch random weird files and build stuff" and more "write a .cpp making the stuff do the stuff"
X-Scale` is now known as X-Scale
<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
<heat> what's the other option?
<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
<geist> but the rather not be is just a personal opinion, so it's hard to argue against
<heat> wdym?
<geist> ie, not a separate ld.so, networking stuff together, thread stuff together, libm together, etc
<geist> the top page of the musl page says this is an actual goal: make a single lib that does everything, for efficiency purposes
<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
<geist> for example just turn off all of the networking features
<heat> since you're using a vdso, make symbols for all the system calls, and stub the ones you don't have
<geist> or at least a separate shared lib yes. and no i'm not using a vdso
<heat> you're not?
<geist> not yet, at least but i have a shared lib i intend to implement the
<geist> i think you overestimage how much stuff i have done
<geist> i literally have like 5 syscalls implemented, and they're all implemented within like a 150 line .cpp file
<heat> s/using/going to use/g was more what I meant
<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
<geist> easier to debug that way
<heat> as for the thread stuff, etc: glibc does that too now
<geist> and in the case of musl wanting very linux centric syscalls it'll probably somewhat act like linux
<heat> you don't need to explicitly link with -lrt, -ldl, (possibly -lpthread? can't remember)
<geist> probably has to for the thread stuff since C11 picked up thread features
<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
<heat> you underestimate the hackyness of glibc :P
<heat> i bet they had a nice, big giant hack for C11 threads
<geist> but otherwise try to keep the libc stuff modular
<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
<geist> now there's just so much more stuff expected to be done that i'm just not interested in it
<geist> but then i dont want to Just Reimplement Linux
<heat> also fwiw you just need like 10 syscalls for basic musl
<geist> which musl will heavily push you towards
<heat> well... yes I can't disagree with that
<geist> possibly. i mean i'l have to stub out probably 50-100
<heat> but you can definitely resist
<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
<geist> looksl ike what we did for fuchsia was basically replace every single one of those with a regular function call
<heat> I was thinking you could automate the stubbing based on the syscalls.h.in
<geist> __syscall(SYS_foo, ) -> foo()
<geist> there was probably some reason for the replacement
<heat> you have like 400 syscalls
<geist> yah i'm not excited about stubbing those out to get to step 1
<heat> what is this, riscv?
<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
<geist> it seems to expect aux[] and a bunch of stuff already pushed on the stack, etc
<geist> heat: riscv and arm are my first targets, mostly because thats where i have the most support for mmu on LK side
<geist> riscv is so easy to implement core features it's a great place to bootstrap this stuff
<heat> auxv, argv, envp are all part of the ELF(?) ABI
<geist> not sure! AFAIK aux is 100% a linux thing
<heat> you could change those in the entry points
<geist> though maybe not a bad idea per se
<geist> sure, but omg that code is dense as heck. basically like that code we were looking at the other day
<geist> very very unclear what it's doing
<heat> haha
<heat> i know the feeling
<heat> it's 1337 hax0r code
<geist> another strategy is to just not include the ld.so stuff and do my own
<geist> which is frankly kidna fun
<geist> i'm not real keen in the idea that the libc has a built in ld.so
<geist> though for no particular reason, it just seems like it'd be much cleaner to have a simple standalone one
<geist> so that you can, for example not have to implement it if you want some other runtime
<heat> i think roland has a fuchsia ldso branch where he's working on one
<geist> yep
<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
<heat> even an ldso?
<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
<geist> of course. it is The Way
<heat> fuchsia is slowly rewriting musl huh
<geist> C is almost outright banned in fuchsia, since no one seriously considers it to be a reasonable language
<heat> oh yeah how did nvme.c end up in C?
<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
<geist> was written extremely early
<geist> we need a maintainer of it actually
<geist> surprisingly for most of our internal testing we've been generally buying SATA m.2 cards, apparently. just because
<geist> but it's getting such that we can't ignore nvme
<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
<clever> it aint broke, dont fix it!
<geist> totes
<geist> mcgotes
sonny has quit [Remote host closed the connection]
bliminse has quit [Quit: leaving]
the_lanetly_052 has quit [Ping timeout: 244 seconds]
sonny has joined #osdev
bliminse has joined #osdev
<geist> grr, so somewhat annoyingly i stick in an old ryzen cpu to my crashy server and it seems stable
<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
<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)
the_lanetly_052 has joined #osdev
<zid> Overclock the balls off it
<zid> oh wait..
sonny has quit [Ping timeout: 252 seconds]
<zid> geist: You can debug my machine if you like it's easier, I think it just needs a psu.
<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
<clever> i need to setup the scope again and monitor the voltages
<bslsk05> ​www.theregister.com: Arm CPU ran on electricity generated by algae for six months • The Register
the_lanetly_052 has quit [Ping timeout: 272 seconds]
<clever> geist: probably a cortex-m
<clever> oops, GeDaMo ^
sonny has joined #osdev
<GeDaMo> "Arm Cortex M0+ CPU"
<clever> yeah, those run on much less
<geist> cute!
<GeDaMo> Now, how much algae do I need to run my desktop? :P
<heat> depends if you're running an i9-12900K
<geist> presumably you need to actually keep it alive
<heat> you need an oil tanker for those
<zid> good news is that my psu is out of warranty, it turns out
<geist> yah thankfully there are some really good high quality PSUs nowadays
<geist> in general most of my computer failures i the past have been PSU related
<zid> I bought a good one :(
<zid> I figured it'd last ages
<geist> how do you know it's the psu?
<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
<geist> ah what sort of dip are you seeing?
<zid> enough that the board shuts down due to a 'power event' :p
<geist> ah
<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
<zid> https://cdn.discordapp.com/attachments/417023075348119556/977296949994741830/unknown.png sensor isn't calibrated so the absolute value is off by like .2V
<zid> but that's what opening prime95 looks like
<geist> OTOH the tester only has 2 significant digits there so could be anywhere
<geist> ah. that being said since modern cpus run on <1V or so it seems strange that the VREGs couldn't deal with that
<geist> alas this mobo doesn't have any power sensors
<kazinsal> I should probably buy a new PSU, this one's uh
<kazinsal> probably 12 years old
<zid> I think the psu is just old and degrading, can't supply the full wattage anymore
<geist> the main transformer or whatnot
<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
<zid> or the switching circuitry's timing cap or whatever depends how it's set up
<GeDaMo> zid: is it possible it's an external problem?
<zid> 240V is less aggressive current wise so less heat, but you need fancier rated components
<zid> GeDaMo: The mains knows I started prime95 and is dropping to 200V?
<geist> yah
<geist> you browned out your house
<zid> It has a 20kW supply, I hope not
<heat> less me is bad
<geist> only 20kW? that seems pretty low for a house
<zid> 240V * 90A
<zid> A lot of people only get 30A I've found
<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
<zid> a dead short aka electric kettle is 3kW
<geist> ie, 120V * 200A
<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
<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
<geist> approx 240L capacity, about 5kW heater. to raise a bunch of water from 10-80C is like 19kWh
<zid> 5kW? fancy.
<zid> That'd blow all my fuses.
<geist> yah it's pretty fancy. it's on it's own 220 circuit
<zid> I'd have to put a different breaker on
<geist> you should see the breaker box in his house, it's crazy
<geist> like two full breaker boxes, each with a 200A breaker at the top
<zid> why on earth
<geist> whoever built it went to town
<zid> bus bars and breakers
<geist> lots of 220 circuits and a whole backup 20kW generator that owns one of the breaker boxes
<zid> bathrooms will generally be on a 30mA RCD
<geist> so they split it by things the generator would take over and the Beefy Stuff like the heat pump, electric water heater, etc
heat is now known as _Heat
<_Heat> i am a reserved identifier now
<zid> Then a case goes over that lot
<zid> Then a flip down panel covers the switches
<zid> It's pretty neat and tidy all round, I like it
machaddr has joined #osdev
machaddr has quit [Quit: Leaving]
sonny has left #osdev [#osdev]
<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.
_Heat is now known as heat
<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?
<mrvn> Both should be <addr>->A{A{1]] basically
Matt|home has quit [Quit: Leaving]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
Vercas has quit [Write error: Connection reset by peer]
Vercas has joined #osdev
kingoffrance has joined #osdev
<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
<mrvn> I think it would have to be something specified in the langauge, specifically that placement new may (or must?) copy-elid.
varad has joined #osdev
<mrvn> Seems stupid that construction of objects on the stack can elide more than constructing on the heap.
ethrl has quit [Quit: Textual IRC Client: www.textualapp.com]
fwg has quit [Quit: .oO( zzZzZzz ...]
theruran has quit [Quit: Connection closed for inactivity]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
thatcher has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Likorn has quit [Quit: WeeChat 3.4.1]
thatcher has joined #osdev
rpnx-phone has joined #osdev
pie_ has quit []
vancz has quit []
rpnx-phone has quit [Ping timeout: 276 seconds]
pie_ has joined #osdev
vancz has joined #osdev
valerius has quit [Killed (NickServ (GHOST command used by theophilus!~corvus@user/theophilus))]
valerius_ has joined #osdev
Likorn has joined #osdev
rpnx-phone has joined #osdev
<Griwes> I mean placement new can elide
<Griwes> but construct_at is not *quite* placement new
troseman has joined #osdev
<mrvn> Griwes: it's a template that calls placement new here.
<mrvn> ##### new(p)A{A{1}} #####
<mrvn> @0xe3eeb0: fullA::A(int)
<mrvn> but you are right.
<mrvn> { return ::new((void*)__location) _Tp(std::forward<_Args>(__args)...); }
<Griwes> yes - but functions aren't syntactic macros :P
<mrvn> yeah. I want a NVAO - non value argument optimization.
<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.
wolfshappen has joined #osdev
<geist> re: raising from 220 to 240, is that an attempt to standardize on a single voltage or something?
<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
<geist> but in general a higher rate is more desirable because of various efficiences
<mrvn> only reason I know is that higher voltage is more efficient.
<mrvn> Conspiracy nuts say it's to burn out old 220V appliance so you buy a new one.
<geist> requires i think smaller capacitors and/or transformers to deal with the swing
<geist> when it flips faster
<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.
<mrvn> The clock runs of the electrical frequenzy so it was 20% fast.
<geist> yep anything with an AC motor would have that problem
<mrvn> digital clock
<geist> computer wise i was reading the timer board on a PDP11 (and other similar) basically counts zero crossings of the input mains
<geist> so there's a jumper and/or a separate board for 50 vs 60hz
<zid> why would anybody change from 220 to 240 geist?
<geist> probably same thing with the digital clock: no on board oscillator, just a zero crossing detector, maybe
<geist> zid: i have no idea, mrvn mentioned it
<mrvn> zid: efficiency
<zid> ah that explains that
<mrvn> transmission loss is proportional to voltage.
<mrvn> Ever wonder why the long distance overland lines are like 10kV?
<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
<zid> and afaik it's assymetrical, like 230 -5% +10%
<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
<zid> because 240V + error puts it nearer 250 half the time
Burgundy has quit [Ping timeout: 244 seconds]
<zid> it's close enough that it makes no difference, you just buy 500V caps
<zid> and they're all sold by the same company in bulk precisely for the purpose
<geist> except that messes with phase, as substations have to fiddle with all the time
<clever> geist: i think freq is more important then voltage for interconnect, because a multi-tap transformer can deal with the voltage difference
<geist> to keep different patrs of the grid synchronized
<geist> clever: probably true, yes
<zid> They transmit at kilovolt scales anyway
<clever> but frequency differences need a massive ac->dc->ac facility, like the one near me
<zid> it's only local substations that care about the exact frequency, and power supplies in appliances
<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
<bslsk05> ​en.wikipedia.org: Eel River Converter Station - Wikipedia
<zid> err exact voltage*
<geist> and/or large inverters to deal with DC transmission lines
<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
<zid> Almost all of our infra is hidden :(
<geist> yah makes sense
<bslsk05> ​www.electricaleasy.com: Methods of voltage control in power system | electricaleasy.com
<clever> this is a bank of multi-tapped transformers
<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
<clever> that compensate for the sag on the high voltage lines
<zid> and all the cables are completely underground
<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
<clever> in my area, its 7200vac phase to ground, 12470 phase to phase, 3 phases total
<clever> and 7200->120 is just a /60 division
<zid> Kinda like that
<clever> so a 60:1 transformer gives you 120v
<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
<zid> Power cables come in, drop down to 240V, go out again
<geist> it doesn't seem intrinsincally obvious where it Goes once it leave smy property
<zid> probably follows the roads geist
<clever> https://openinframap.org/#12.4/48.01252/-66.42803
<bslsk05> ​openinframap.org: Open Infrastructure Map
<clever> this site shows the electrical grid for the entire world
<geist> i'd think that, but then the next obvious road near my house i dont see where it hooks up to the lines
<clever> and these coords are for the eel river converter station
<geist> so thinking it might exit on some other path to another road
<zid> maptiler, never heard of that map provider before
<clever> the quebec grid isnt synced to the nb/ns/pei grid
<clever> zid: its part of OSM
<clever> so, while quebec and nb are both 60hz, they are drifting in and out of phase
<zid> 132kV line serves me apparently
<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
<bslsk05> ​openinframap.org: Open Infrastructure Map
<clever> this converter station does the whole ac->dc->ac conversion
<geist> any one of those lines gets a tree on it, lots of folks are out
<zid> then it's stepped down to 33kV to enter the town itself
<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.
<zid> oh and there's fucking.. 2.7MW solar farm at the back of town? til
<zid> and 9MW of wind turbines, I knew about those, I can see them :p
<kazinsal> oh hey that map works north of the border too, neat
<clever> kazinsal: yep, global database
<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.
<clever> geist: those lines on the map at 115kv feeding the substations, i find it highly unlikely that those get hit by trees
<clever> would be a really expensive accident
<geist> they do. frequently
<zid> trees get vaporized when that happens
<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
<clever> around here, you have massive clearings around those lines
<clever> so there is no risk of that
<geist> yah, the woods here are dense, with tall ass trees
<zid> I've seen helis with enourmous disc cutters dangling down cutting trenches
<geist> i have probably a solid 20 trees just in my yard that are well over 100 feet
<zid> I want one.
<kazinsal> interesting, there's no data for point roberts
<kazinsal> kinda wondered where the power there came from
<geist> there's that one guy with the bicycle generator
<geist> and sometimes the people take turns
<clever> kazinsal: yeah, its basically the wikipedia of maps, so users need to add the data, from compatibly licenses sources
<zid> We have a power_line_1 at 400kV apparently, that's all the super power stuff
<geist> that map seems to stop at substatios, so i guess they get non substationed stuff from north of teh border
<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
<bslsk05> ​www.google.ca: Google Maps
<kazinsal> I bet PSE just buys a few hundred kilowatts from BC Hydro
<clever> geist: more about if the local OSM users care about mapping every single telephone pole
<geist> but yeah we lose a lot of lines here, though it's getting better
<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
<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"
<clever> geist: diagonal trim the height of the trees?
<clever> no tree is allowed to be taller then the distance from its base to the wires
<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
<bslsk05> ​www.google.com: Google Maps
<zid> fucking hell
<zid> america what are you doing
<clever> jesus
<geist> woods!
<geist> folks like them some woods!
<clever> thats not how you treat 115kv lines
<geist> but yes this is why my house as a 20kW gasoline generator
<kazinsal> they're insulated, it's fine
<zid> did you all read the oil filled transmission line repair usenet post thing
<bslsk05> ​www.jwz.org: jwz: engineering pornography
<mrvn> int foo(int a[static 10]); What's the meaning of static there?
<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
<bslsk05> ​www.google.com: Google Maps
<geist> also see seattle in the distance? if it weren't so cloudy you'd also see the Giant Volcano
<moon-child> mrvn: same as int *a, except that a _must_ point to 10 integers
<moon-child> can't be null, can't point to fewer than 10 integers
<moon-child> otherwise ub. But mainly used as a declaration of intent
<clever> geist: you can get similar views in southern nb
<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
<geist> looking at the thriving metropolis of.. uh
<mrvn> moon-child: https://godbolt.org/z/E3a9qMqeh Works "fine" with smaller array.
<bslsk05> ​godbolt.org: Compiler Explorer
<mrvn> moon-child: I'm asking about the "static", not the "10".
<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
<clever> geist: hows this view? https://goo.gl/maps/yF4zbJGMv4JHejNF7
<bslsk05> ​redirect -> www.google.com: Google Maps
<moon-child> mrvn: int a[10] is literally the same as int *a. The 'static' is what adds the requirement
<clever> i just dropped the street-cam on a random road within the island
<kazinsal> so if a tree falls into an east-west line it can bonk 15k peoples power offline for four or five hours
<kazinsal> as is the case of what happened to me on wednesday
<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
<geist> clever: oh it's on the bay of fundy! gets a huge tidal interchange. i wonder how bad it is that far south?
<clever> geist: further east, in the gap between NS and NB, is where its the highest
<clever> because the resonant freq of the water sloshing in/out, matches the tides
<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]
<clever> and it adds up
<geist> yah minas basin, etc
<mrvn> moon-child: your description sounds like it should be an error to pass 0 or int[5].
<geist> that island is pretty much open ocean it seems
<geist> anyway, /me lets actual programming discussion occur
<clever> geist: but grand manan is running entirely off underwater power lines
<geist> also ooooh, my esp32-c3 (riscv based esp32) board just showed up in the mail
<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
<moon-child> mrvn: no, I said it's ub, not an error
<moon-child> if you just declare as int a[10], then it's _exactly_ the same as if you declare as int *a
<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. :)
<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.
<kazinsal> huh, didn't know washington had so much wind power. neat
<mrvn> How about Chicago, the windy city. They must have lots of wind power, right?
<moon-child> mrvn: I was perhaps not clear enough. void f(int a[5]) is exactly the same as void f(int *a)
<moon-child> obviously a naked int *a in a function body is not the same as int a[5] in the same context
<mrvn> moon-child: you where clear but also wrong. Inside f it's a different type.
<mrvn> nm, we agree
<geist> kazinsal: yah the power here is pretty clean, one of the things i like about it
<mrvn> geist: but is it yellow?
<zid> Okay re-read the usenet post, always good fun
<kazinsal> yeah geographically the northern half of the PNW is phenomenal for clean energy
<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
<kazinsal> BC's 95% renewables, with the last 5% being just remote communities in the far north that literally have nothing else available
<geist> yah that generally is an issue with living in some remote ass place
<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
<bslsk05> ​www.gridwatch.templar.co.uk: G. B. National Grid status
<zid> 43% wind for the UK right now apparently
<zid> 0% coal, 31% natty gas, 21% nuclear
<mrvn> kazinsal: cheaper that tearing it down and doing an environmental cleanup?
<kazinsal> probably. also a neat educational thing
<kazinsal> burrard thermal was only really meant to be a generating station for peak demands
<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
<geist> they should brew beer there
<bslsk05> ​'Helicopter air saw trimming trees - Helicopter trimming trees by high tensions lines' by Amazing Tube (00:10:30)
wolfshappen has quit [Quit: later]
<mrvn> clever: and now a little to the left please. NO, my left.
<clever> :D
<mrvn> .oO(I measure performance on a geological timescale)
<klange> If your program completes before the heat death of the universe, it's fast enough.
<mrvn> I miss the time when you optimized your software by waiting 6 month for the faster hardware.