<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
<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
<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>
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.
<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>
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
<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
<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
<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
<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
<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