<GreeningGalaxy>
might be worth dropping some extra $ for the high-gain versions with external antennae, too; the range of these with just a simple on-board antenna is a good few meters (probably like 20, I haven't measured) so we might do really well with bigger antennae and higher transmission power
<GreeningGalaxy>
SnoopJeDi: I saw that. Is it really legitimately working on production vehicles, or is it modified in some way?
<SnoopJeDi>
it's just some artist's funny idea, his car is in no way self-driving
<SnoopJeDi>
but the point he makes is a valid one
<GreeningGalaxy>
ah
<GreeningGalaxy>
I could easily imagine very effective self-driving car traps by bending and obscuring road sidelines
GreeningGalaxy has quit [Ping timeout: 190 seconds]
* UmbralRaptor
really needs to stop drinking large amounts of coffee on an empty stomach.
* UmbralRaptor
jitters.
e_14159 has quit [Ping timeout: 180 seconds]
e_14159 has joined #kspacademia
GreeningGalaxy has joined #kspacademia
Majiir is now known as Snoozee
GreeningGalaxy has quit [Ping timeout: 190 seconds]
ferram4 has quit [Ping timeout: 206 seconds]
<egg|zzz|egg>
!wpn UmbralRaptor
* Qboid
gives UmbralRaptor a Norman hug
<egg|zzz|egg>
!wpn whitequark
* Qboid
gives whitequark an IEEE 754 infinity
<egg|zzz|egg>
nice
<egg|zzz|egg>
!wpn bofh
* Qboid
gives bofh a Kozai roasted snakehead
<egg|zzz|egg>
!wpn e_14159
* Qboid
gives e_14159 a numeric molybdenum pounce
<whitequark>
!wpn egg|zzz|egg
* Qboid
gives egg|zzz|egg a conducting reader-writer door
<whitequark>
egg|zzz|egg: do you not stop sleeping lately
<egg|zzz|egg>
whitequark: that is not hatched which can eternal zzz
<egg|zzz|egg>
so, I guess I could blame my bug on the Dämmerungsgötter? would the bugfix then be the Dämmerungsgötterdämmerung?
<egg|zzz|egg>
whitequark: btw, we may have found the source of our unreplayability/nondeterminism bug
<egg|zzz|egg>
it's subtle
<e_14159>
!wpn egg
* Qboid
gives egg an expression-like projector
<egg|zzz|egg>
so we have |std::set|s of pointers; the order in there is not deterministic, but while that's not really a good idea, the order didn't seem to matter: on the few instances where we did iterate there, we performed operations that seemed to commute (physics doesn't depend on the order of addresses of the vessels after all). But, it turns out that we compute barycentres, and that means we add a whole lot of
<egg|zzz|egg>
floating-point numbers together, in an order that depends on the ordering of the sets. Nonassociativity of floating point addition caused the bug we were seeing
<egg|zzz|egg>
couldn't have been stomping, that would be unlikely to always be as low as 300ish ULPs; couldn't have been redirected rounding, that yields 1-2 ULPs, and does so very quickly
<egg|zzz|egg>
but nonassociativity + cancellation can completely explain that order of magnitude
<whitequark>
nice
<egg|zzz|egg>
!wpn -add:adj associative
<Qboid>
egg|zzz|egg: Adjective added!
<egg|zzz|egg>
huh, that wasn't in?
<egg|zzz|egg>
!wpn -add:adj commutative
<Qboid>
egg|zzz|egg: Adjective already added!
<egg|zzz|egg>
!wpn -add:adj invertible
<Qboid>
egg|zzz|egg: Adjective added!
<egg|zzz|egg>
!wpn -add:adj idempotent
<Qboid>
egg|zzz|egg: Adjective added!
<egg|zzz|egg>
!wpn -add:adj nilpotent
<Qboid>
egg|zzz|egg: Adjective added!
<whitequark>
!wpn -add:wpn isomorphism
<Qboid>
whitequark: Weapon already added!
<whitequark>
!wpn -add:wpn zygomorphism
<Qboid>
whitequark: Weapon added!
<egg|zzz|egg>
I think there's a fair number of morphisms in there
<whitequark>
!wpn -add:wpn histomorphism
<Qboid>
whitequark: Weapon added!
<egg|zzz|egg>
!wpn -add:wpn diffeomorphism
<Qboid>
egg|zzz|egg: Weapon added!
<whitequark>
!wpn -add:wpn dynamorphism
<Qboid>
whitequark: Weapon added!
<whitequark>
!wpn -add:wpn prepromorphism
<Qboid>
whitequark: Weapon added!
<egg|zzz|egg>
O_o
<egg|zzz|egg>
what the hell are those morphisms
<egg|zzz|egg>
strange CS things apparently? o_O
<whitequark>
~*~ haskell ~*~
<UmbralRaptor>
!wpn egg|zzz|egg
* Qboid
gives egg|zzz|egg an IEEE 488 completely harmless submersion
<egg|zzz|egg>
whitequark: as a mathematician I would like to state that Haskell appears to involve very abstract nonsense and very nonsensical abstraction :-p
<whitequark>
!wpn -add:wpn spectrometer
<Qboid>
whitequark: Weapon already added!
<whitequark>
!wpn -add:wpn spectrophotometer
<Qboid>
whitequark: Weapon added!
<egg|zzz|egg>
!wpn -add:adj holomorphic
<Qboid>
egg|zzz|egg: Adjective added!
<whitequark>
!wpn -add:adj quadrupole
<Qboid>
whitequark: Adjective already added!
* whitequark
squints
<egg|zzz|egg>
J2 \o/
<egg|zzz|egg>
whitequark: why the squinting?
<whitequark>
is someone else here a fan of quadrupole mass filters
<egg|zzz|egg>
ah I think I added that when I was looking at gravitational quadrupole moment
<egg|zzz|egg>
oblate bodies
<UmbralRaptor>
whitequark: It's from back when I was fitting sersic profiles to galaxies. >_>
<Qboid>
egg|zzz|egg: I added the explanation for this acronym.
<egg|zzz|egg>
!wpn UmbralRaptor
* Qboid
gives UmbralRaptor a tagged bombe
<egg|zzz|egg>
!wpn whitequark
* Qboid
gives whitequark a Hittite algebra
<egg|zzz|egg>
today's episode of "the KSP API": in OrbitPhysicsManager, public bool degub;
<egg|zzz|egg>
another episode of "the KSP API": a vessel has a situation and a BestSituation
<egg|zzz|egg>
ookay, now I've changed the bug to a state where I *do* bounce endlessly around the atmosphere, but at least I don't pick up speed while doing so
pizzamobile has joined #kspacademia
pizzamobile is now known as pizzaoverhead
pizzaoverhead has quit [Client Quit]
<egg|zzz|egg>
e_14159: so, I think I'm going to make a pull request called Dämmerungsgötterdämmerung >_>
<Qboid>
egg|zzz|egg: current time in Kansas City, Missouri, United States: 6:44:53 am CDT | Monday, March 20, 2017
<egg|zzz|egg>
EarlyRaptor
<UmbralRaptor>
Well, it's not 0 sleep, but close enough. >_<
<e_14159>
egg|zzz|egg: The float-thingy, right?
<egg|zzz|egg>
e_14159: nah, the float-thingy is #1274
<Qboid>
[#1274] title: Try to fix the non-deterministic replay by making the ordering of maps and sets deterministic | The theory is that the computations (e.g., of barycentres) that are done in map/set order yield different results when the order changes due to vessels/parts landing at different addresses. To confir... | https://github.com/mockingbirdnest/principia/issues/1274
<UmbralRaptor>
!wpn egg|zzz|egg
* Qboid
gives egg|zzz|egg a nitrogen infinite router
<egg|zzz|egg>
e_14159: this is vessels getting bounced around at the edge of the atmosphere and acquiring ridiculous speeds, but *only if they leave the atmosphere on the orbit-trailing "evening" side of the earth*
<egg|zzz|egg>
e_14159: the explanation is therefore crepuscular gods
<e_14159>
Why did it happen?
<egg|zzz|egg>
hmm, probably the earth not being in the right place at the right time? maybe? stabbing it to force it to be in the right place seems to work
<egg|zzz|egg>
(crepuscular gods seem to be the best explanation)
<egg|zzz|egg>
(but I appear to have defeated them! hence the Dämmerungsgötterdämmerung)
<UmbralRaptor>
egg|zzz|egg: Please bear in mind that cats are crepuscular gods.
<e_14159>
Makes sense.
<egg|zzz|egg>
UmbralRaptor: cats paw at your vessel until it shoots off at 60 km/s? sounds reasonable
<UmbralRaptor>
>_>
<e_14159>
egg|zzz|egg: 60km/s? Sounds like a great propulsion method.
<UmbralRaptor>
e_14159: You underestimate the chaotic nature of felines.
GreeningGalaxy has joined #kspacademia
<UmbralRaptor>
!wpn GreeningGalaxy
* Qboid
gives GreeningGalaxy a solenoidal wyvern
<GreeningGalaxy>
!wpn UmbralRaptor
* Qboid
gives UmbralRaptor a Jeans coffee
* UmbralRaptor
watches the coffee collapse under self-gravitation.
<GreeningGalaxy>
I can't tell if good laptops have ever actually gotten cheaper, or if there are just more shitty ones now
<GreeningGalaxy>
I mean I've seen evidence of people getting a good, well-built machine for like $500, but so far everything I've been able to find that isn't obviously crap is in the neighborhood of $1k
<egg|zzz|egg>
!wpn GreeningGalaxy
* Qboid
gives GreeningGalaxy a fluorine oscilloscope which vaguely resembles a reactor
<bofh>
yay fluorine
<bofh>
!wpn egg|zzz|egg
* Qboid
gives egg|zzz|egg a Sharp periwinkle
<bofh>
not a Sharpless periwinkle? :P
<Iskierka>
GG: base model thinkpads aren't very expensive and the silly-size battery upgrade is like $15
<Iskierka>
a little more than $500 new though, but under $1k. Though a model upgrade has pushed it up a bit
<UmbralRaptor>
So, my 8 am class got cancelled at 8:01…
<egg|zzz|egg>
!wpn UmbralRaptor
* Qboid
gives UmbralRaptor a Gaussian eta projection
<UmbralRaptor>
So, drive home and sleep until quantum?
<whitequark>
GreeningGalaxy: what counts as "good" has advanced over the years
<whitequark>
I got ux32vd in 2011 or so, when it was top of the line
<whitequark>
only the $1700 model had an IPS panel. worth it
<whitequark>
I got this xps13 a few weeks ago, which is when it's top of the line
<whitequark>
and only the $1800 model has a QHD panel. (worth it)
<UmbralRaptor>
QHD or qHD?
<whitequark>
QHD
<whitequark>
3200x1800
<whitequark>
and 270 DPI
<egg|zzz|egg>
!wpn whitequark
* Qboid
gives whitequark an unitary copper DIAC
<egg|zzz|egg>
!wpn UmbralRaptor
* Qboid
gives UmbralRaptor a combinatorial ion channel
<egg|zzz|egg>
!wpn Iskierka
* Qboid
gives Iskierka a xi kitten
<GreeningGalaxy>
Iskierka: yeah I was considering thinkpads
<GreeningGalaxy>
I do like the silly-size battery
<GreeningGalaxy>
My toughbook isn't going anywhere, I just would like something with a little more actual CPU power.
<GreeningGalaxy>
and I also really want something with more than 768 pixels vertical. 3K would be nice but I'd easily settle for 1080
<UmbralRaptor>
MBAs get you silly size battery. Also limited ports and 1440x900 ?
<GreeningGalaxy>
MBAs?
<GreeningGalaxy>
oh, macbook air
<GreeningGalaxy>
honestly thinness is the one specification I care the least about
<e_14159>
GreeningGalaxy: Have you checked student prices?
<GreeningGalaxy>
for Thinkpads? No, I didn't know there were any.
<e_14159>
At least here there are.
<Iskierka>
I thought MBA is a fairly small battery with aggressive saving
<GreeningGalaxy>
Iskierka: I assumed Umbral meant "silly" the other direction.
<Iskierka>
so the MBA wouldn't, for instance, manage 6-7 hours at maximum CPU & iGPU usage with no dGPU, or 4-5 hours with max CPU & dGPU
<Iskierka>
that's also possible
<egg|zzz|egg>
!choose food|principia bugs
<Qboid>
egg|zzz|egg: Your options are: food, principia bugs. My choice: food
<egg|zzz|egg>
;choose food|principia bugs
<kmath_>
egg|zzz|egg: principia bugs
<egg|zzz|egg>
hmm
<whitequark>
!choose Qboid|kmath_
<Qboid>
whitequark: Your options are: Qboid, kmath_. My choice: kmath_
<whitequark>
;choose Qboid|kmath_
<kmath_>
whitequark: kmath_
<whitequark>
egg|zzz|egg: principia bugs it is
<GreeningGalaxy>
Iskierka: what model is it that you have that gives you those battery specs?
<Iskierka>
T560 with a few non-base specs, so it did total bout £950
TonyC1 has joined #kspacademia
<Iskierka>
the T460 (out of production) gets slightly less but comparable (internal battery is smaller)
<Iskierka>
there's T470 replacing it but iunno what cost or variations are available
TonyC has quit [Ping timeout: 204 seconds]
<GreeningGalaxy>
I wish I'd had enough to afford a laptop when I went to Shenzhen. That would've been a perfect place to get a fairly good machine fresh off the assembly line for a bargain rate (with a bootlegged copy of Windows 10 which I would've wiped out immediately anyway)
<egg|zzz|egg>
... fuck you KSP
<egg|zzz|egg>
so the newest issue is that I fail a check because I try to add an existing part (and I check that it's not pre-existing)
<egg|zzz|egg>
it's the potatoroid of some asteroid
<egg|zzz|egg>
here are the vessels currently in KSP:
<egg|zzz|egg>
Ast. FQT-931
<egg|zzz|egg>
Ast. FQT-931
<egg|zzz|egg>
and all the potatoroids have partid A122B336
<egg|zzz|egg>
(erm, that's little endian)
<egg|zzz|egg>
now to stare at the potatoroid code and cry
<Iskierka>
GG: pretty sure my customised one shipped from shenzen. was certainly in the area when starting
<Iskierka>
hrrmmmmmm there's a refurbished 3K screen in the UK for £99
<egg|zzz|egg>
and apparently under some circumstances they can have the same part
<GreeningGalaxy>
KSP asteroids are balloons that someone sprayed with a mixture of glue and regolith, and then went "look, asteroids!"
<UmbralRaptor>
Aerogel ore
<Iskierka>
GG: what kind of battery does system76 offer?
<GreeningGalaxy>
60 Wh
<GreeningGalaxy>
for the Oryx, don't remember for the others
<Iskierka>
116 in thinkpad. Also, that's just the price for a new one - several people here are getting thinkpads just 1-2 generations older at significantly lower price
<GreeningGalaxy>
hmm
<Iskierka>
same durability and so long as it's not too many gens back the charger & batteries are compatible so all-new parts are readily available
<Iskierka>
(first digit is 1x" screen, second is core i generation in it, for getting broad impressions quickly)
<whitequark>
>In versions prior to 1.1, it was possible to break the game by connecting to a klaw that is not on the active vessel. The celestial body being orbited would disappear as soon as the klaw connects (see image in sidebar).
<whitequark>
how do you even get this bug
<Iskierka>
KSP
<egg|zzz|egg>
pretty much
<egg|zzz|egg>
whitequark: do not underestimate the madness of KSP
<Iskierka>
there's T420s on ebay for like £120-£200
<egg|zzz|egg>
(I still have no idea why vessels have a situation and a BestSituation)
<egg|zzz|egg>
the BestSituation is the situation unless the lastSituation was FLYING
<Iskierka>
with a decent choice of SSD or large HDD
<egg|zzz|egg>
in which case it's FLYING
<egg|zzz|egg>
none of that is documented of course
* Iskierka
checks that T420 does use compatible pieces
<Iskierka>
ah, different power connector on T420
<GreeningGalaxy>
oh yes, I remember Danny or whoever playing with that to "destroy" planets
<GreeningGalaxy>
if you did it on the surface, you'd start falling through where the surface used to be and then explode
<egg|zzz|egg>
yup
<Iskierka>
T440 uses current
<Iskierka>
and looks like current battery
<egg|zzz|egg>
whitequark: Danny is someone who makes YouTube videos dedicated to breaking KSP in strange ways
<egg|zzz|egg>
there are many strange ways to break KSP
<kmath_>
YouTube - Kerbal Space Program: Over 9000
<egg|zzz|egg>
whitequark: so I think my recommendation for the potatoroid thing is to disable potatoroids, by renaming the part.cfg in gamedata/squad/misc/potatoroid to something that's not a cfg
<egg|zzz|egg>
that fixes the bug and the asteroids are silly anyway
<UmbralRaptor>
Career puts in funding limits. Also building unlocks which are a bit too silly.
<SnoopJeDi>
I should actually play Kerman Species Pogram
<GreeningGalaxy>
I've never had patience for career, and the science system has always seemed kind of silly. I've only played sandbox.
<GreeningGalaxy>
well, seriously anyway. I've tried to play career but gotten bored of strapping things to SRBs and jumping for money
<whitequark>
I found career fun actually
<whitequark>
contracts can be rather challenging, and they encourage me doing things I never did before
<whitequark>
like building planes
<GreeningGalaxy>
I do like the contract mechanic, just not, like.... the rest of career mode.
<whitequark>
ah
<GreeningGalaxy>
I have had fun with a career mode modified to start with a stupidly large amount of money and a solid chunk of science, so I can start with enough stuff to actually build spacecraft and not have to worry about building upgrades
<GreeningGalaxy>
but I think about when I started doing that was pretty close to when research started taking up all my time and I stopped playing games very much
<GreeningGalaxy>
speaking of which, I need to go to school. brb.
GreeningGalaxy has quit [Ping timeout: 206 seconds]
<egg|zzz|egg>
brb food
<SnoopJeDi>
egg|egg|egg?
<egg|zzz|egg>
SnoopJeDi: nah, tomato and burrata; but there's a problem
<egg|zzz|egg>
no bread
<egg|zzz|egg>
now there *is* brioche
<egg|zzz|egg>
the problem with that is that it has sugar on top
<UmbralRaptor>
Lettuce? Avocado?
<SnoopJeDi>
that sounds light and delicious
<egg|zzz|egg>
UmbralRaptor: nah, just a sliced tomato with a burrata and some olive oil
<egg|zzz|egg>
(and the bread issue was resolved by using the bottom of the brioche, which wasn't covered in sugar, as bread)
<egg|zzz|egg>
!wpn -add:wpn brioche
<Qboid>
egg|zzz|egg: Weapon added!
<egg|zzz|egg>
!wpn whitequark
* Qboid
gives whitequark a cabbage
<egg|zzz|egg>
!wpn SnoopJeDi
* Qboid
gives SnoopJeDi a flipped counter with a ? attachment
<egg|zzz|egg>
!wpn UmbralRaptor
* Qboid
gives UmbralRaptor a Norman completely harmless group
<UmbralRaptor>
Completely harmless?
<UmbralRaptor>
!wpn
* Qboid
gives UmbralRaptor a nominal piston
<egg|zzz|egg>
UmbralRaptor: has Nomal been thinking about pistons?
* UmbralRaptor
feela anxious about isentropic compression.
Thomas|AWAY is now known as Thomas
<egg|zzz|egg>
Thomas: I feel like my answer to the asteroid thing is going to be "fuck asteroids"
<egg|zzz|egg>
Thomas: ... so they have something that guarantees that they don't generate the same flight ID twice, and instead with the asteroid spawning code they use a random generator
<Thomas>
Squad(tm)
<egg|zzz|egg>
so they rely on the state of Unity's random generator
<egg|zzz|egg>
which probably doesn't get reset in the same way as the rest of the game when you reload
<egg|zzz|egg>
I'm going to assume that this explains why they give the parts identical ids
ferram4 has quit [Read error: Connection reset by peer]
<egg|zzz|egg>
and say "fuck asteroids"
ferram4 has joined #kspacademia
<Thomas>
egg|zzz|egg: Well, there is a chance that you could get this fixed for 1.3
<egg|zzz|egg>
Thomas: I'm not in preview anymore though :-p
<Thomas>
a) I could open the report for you b) Its prerelease time
GreeningGalaxy has joined #kspacademia
<egg|zzz|egg>
Thomas: I'm not in exp either
<Thomas>
No
<Thomas>
I mean public prerelease
<egg|zzz|egg>
oh is it?
<Thomas>
Yup
<Thomas>
Called 1.2.9
<egg|zzz|egg>
Thomas: I'm too lazy for that anyway :D
<Thomas>
For reasons
<egg|zzz|egg>
>_<
<egg|zzz|egg>
Thomas: so if you want to look into it, have a stare at ScenarioDiscoverableObjects.SpawnAsteroid() (and SpawnLastAsteroid() I guess but that one isn't the one bothering me right now)
* Thomas
doesnt want to care about it because he is happy with his reimplementation (which is totally not based on decompiled code *whistle*)
<egg|zzz|egg>
Thomas: does your reimplementation disable the stock thing?
<Thomas>
it does
<egg|zzz|egg>
Thomas: and what does it do other than that? :-p
<Thomas>
Loads the asteroids from a config file
<egg|zzz|egg>
aha
<Thomas>
So you can have asteroids wherever you want
<egg|zzz|egg>
Thomas: so, is there a trivial way to kill the stock asteroid spawning? that way if people want asteroids they install your thing
<egg|zzz|egg>
and if they don't well they don't get them :_p
<Thomas>
And then there was custom asteroids, the author just copied my code and suggested that kopernicus deactivates its module when custom asteroids is installed
* Thomas
remembers when he had a bug there that managed to kill principia
<egg|zzz|egg>
ah yes
<GreeningGalaxy>
cool, this crystal oscillator stays ringing for like 15 ms after power is cut
<GreeningGalaxy>
that's a good deal longer than I expected
<egg|zzz|egg>
Thomas: uh, right, that's LGPL; but fortunately you're the sole contributor to that file. Can you give me a nonexclusive license to use, copy, modify, merge, publish, distribute, sublicense, and/or sell those 13 lines? :-p
<Thomas>
Actually, I am not the only contributor (got a bugfix pr there at some point), but do whatever you want. Its not like theese 13 lines are very original or hard to write
* Thomas
wants to move Kopernicus to MIT, but then he would have to get the ok of every contributor :<
<egg|zzz|egg>
Thomas: that won't kill asteroids that are already out there though right?
<Thomas>
Nope
<Thomas>
Just prevent new ones
<egg|zzz|egg>
hmm
<egg|zzz|egg>
Thomas: wait what happens to the flightIDs in your code
<egg|zzz|egg>
you also appear to be feeding the seed as the id
<egg|zzz|egg>
but then that's CreatePartNode, that only sets the mid and the uid, not the flightID? O_o
<egg|zzz|egg>
where does the flightID come from then
<egg|zzz|egg>
ah right uid is flightID
<egg|zzz|egg>
Thomas: but then it seems you're doing the same sort of thing as KSP?
<Thomas>
I am
<Thomas>
My code is almost 100% a KSP ripoff
<egg|zzz|egg>
but... that's bad :-p
<egg|zzz|egg>
you risk spawning the same part twice
<egg|zzz|egg>
(like KSP does >_>)
<Thomas>
And I can blame Squad for it
<Thomas>
I dont really want to fix KSP :P
<egg|zzz|egg>
Thomas: sure, but that's not KSP, that's your personal KSP ripoff
<egg|zzz|egg>
flightIDs should come from GetUniqueFlightID(FlightState flightState), that checks if the ID isn't there already
<whitequark>
!wpn egg|zzz|egg
* Qboid
gives egg|zzz|egg a frequentist superheterodyne induction which vaguely resembles a prepromorphism
<egg|zzz|egg>
!wpn whitequark
* Qboid
gives whitequark an americium pen holder
<whitequark>
ow
<egg|zzz|egg>
it is briefly going to hold your pen
<whitequark>
Qboid, did you get taken over by FSB
<egg|zzz|egg>
didn't that one change acronym again?
<whitequark>
FSB?
<egg|zzz|egg>
ah no, it's just that the SVR is getting folded back into the FSB
<egg|zzz|egg>
!wpn
* Qboid
gives egg|zzz|egg an epsilon cathedral
<egg|zzz|egg>
whitequark: ah, that reminds me, I wanted to look at the range of values of Kerbin J2 that would allow Kerbin nice heliosynch orbits
<egg|zzz|egg>
(I'm not sure how it reminds me of that)
<whitequark>
!wpn egg|zzz|egg
* Qboid
gives egg|zzz|egg an invalid paywall
<whitequark>
LOL
* egg|zzz|egg
tries sci-hub
<whitequark>
bofh: xmpp?
<egg|zzz|egg>
?
<whitequark>
egg|zzz|egg: i'm summoning bofh
<egg|zzz|egg>
bofh, thou hast been summoned
<egg|zzz|egg>
d20 -- whitequark summons bofh
<Soozee>
egg|zzz|egg: 17
<UmbralRaptor>
Using the liquid drop model, how oblate should Kerbin be?
<egg|zzz|egg>
UmbralRaptor: oh that's an interesting question; is that model worth anything though
<egg|zzz|egg>
UmbralRaptor: ?
<bofh>
whitequark: sec
<egg|zzz|egg>
;rpn gravitational parameter of kerbin
<kmath_>
egg|zzz|egg: 0.0
<egg|zzz|egg>
;c gravitational parameter of kerbin
<SnoopJeDi>
yea liquid drop model mostly says nucleus to me, but then, I never took any astro courses :P
<egg|zzz|egg>
"[the actual ellipticity] is substantially smaller than Newton's prediction. The discrepancy is due to the fact that the Earth is strongly inhomogeneous, being much denser at its core than in its outer regions.
<egg|zzz|egg>
"
<egg|zzz|egg>
so that's also a concern
<egg|zzz|egg>
though at least that would give a reasonable upper bound
<egg|zzz|egg>
it's unlikely that you'd *exceed* that ellipticity
<egg|zzz|egg>
mantle denser than the core poses issues
<egg|zzz|egg>
UmbralRaptor: so I find ~1/155 for the ellipticity of a liquid Kerbin
<egg|zzz|egg>
compared to Earth's 1/294
<egg|zzz|egg>
UmbralRaptor: that's pretty much exactly Mars's ellipticity? O_o
<egg|zzz|egg>
so for heliosynch at 100 km alt. I need Kerbin to have Mars's dynamical oblateness, and assuming a liquid Kerbin it has Mars's ellipticity...
<egg|zzz|egg>
but Mars isn't a liquid; is that ellipticity consistent with that dynamical oblateness?
<egg|zzz|egg>
this looks like a very boring paper, but p. 347 seems to have the answer
<egg|zzz|egg>
another paper in the sea of paper
<egg|zzz|egg>
paper jam
<egg|zzz|egg>
oh that paper is from the CNES
<egg|zzz|egg>
I need a stapler that can handle more pages
<egg|zzz|egg>
!wpn UmbralRaptor
* Qboid
gives UmbralRaptor a dæmon
<egg|zzz|egg>
!wpn whitequark
* Qboid
gives whitequark a greening thyristor
<egg|zzz|egg>
!wpn GreeningGalaxy
* Qboid
gives GreeningGalaxy a beta ghost
<GreeningGalaxy>
!wpn egg|zzz|egg
* Qboid
gives egg|zzz|egg a port torch
<GreeningGalaxy>
port torch?
* GreeningGalaxy
doesn't know what that is, but thinks it must belong to whitequark
<whitequark>
lol
<whitequark>
!wpn GreeningGalaxy
* Qboid
gives GreeningGalaxy a FORTRAN phototransistor
<bofh>
lol thank
<GreeningGalaxy>
PHOTRAN
<GreeningGalaxy>
or FORTOTRANSISTOR
<egg|zzz|egg>
PHOTRAN
<egg|zzz|egg>
that looks like viet with missing diacritics
<egg|zzz|egg>
(and a missing space, but this is FORTRAN SPA CESDON OT MAT TER)
<egg|zzz|egg>
CNES?
<Qboid>
egg|zzz|egg: [CNES] => Centre National d'Études Spatiales
<Iskierka>
SNES?
<Iskierka>
):
<egg|zzz|egg>
DORIS?
<egg|zzz|egg>
!acr -add:DORIS Détermination d'Orbite et Radiopositionnement Intégré par Satellite
<Qboid>
egg|zzz|egg: I added the explanation for this acronym.
<egg|zzz|egg>
or Doppler Orbitography and Radiopositioning Integrated by Satellite because they managed to find a dual-language acronym
<egg|zzz|egg>
!acr -update:DORIS Détermination d'Orbite et Radiopositionnement Intégré par Satellite / Doppler Orbitography and Radiopositioning Integrated by Satellite
<Qboid>
egg|zzz|egg: I updated the explanation for DORIS
<egg|zzz|egg>
STARLETTE?
<egg|zzz|egg>
!ACR -ADD:STARLETTE Satellite de Taille Adaptée avec Réflecteurs Laser pour les ÉTudes de la TErre
<Qboid>
egg|zzz|egg: I added the explanation for this acronym.
<GreeningGalaxy>
I'm trying to make a function return an array in C++, but the IDE is warning me "Returning pointer to local variable" and later on when I try to assign a new variable to the output of the function it fails ("expression must be a modifiable lvalue")
<GreeningGalaxy>
I feel like fixing the first problem will fix the second, but... what's going on, why is it returning a pointer, what does that mean, and how do I get it to not?
<egg|zzz|egg>
GreeningGalaxy: don't use C arrays
<GreeningGalaxy>
use what, then?
<egg|zzz|egg>
GreeningGalaxy: either a unique_ptr<T[]>, otherwise a std::vector<T>
<GreeningGalaxy>
why don't C arrays work?
<egg|zzz|egg>
GreeningGalaxy: well, first, it means you need to remember to delete
<egg|zzz|egg>
(which you won't and shouldn't have to)
<egg|zzz|egg>
GreeningGalaxy: it's a good idea to use ownership semantics; you should probably ask whitequark for eggsplanations of why and why C is awful etc.
<egg|zzz|egg>
quarksplanations?
<egg|zzz|egg>
that doesn't sound right
<egg|zzz|egg>
GreeningGalaxy: now, I don't know how you declare your array in your code, but if you put it on the stack in your function, it's going to die when control leaves the function
<egg|zzz|egg>
so returning it (which means returning a pointer, because morally that's pretty much all there is to a C array) means returning a dangling pointer
<egg|zzz|egg>
afaik you can't return arrays on the stack in C? you can in Ada, but I digress
<egg|zzz|egg>
so you have to allocate
<egg|zzz|egg>
GreeningGalaxy: and since you don't want to leak, and since you're writing C++ (hopefully modern C++) and not writing C, you use an object that owns the memory it allocates
<egg|zzz|egg>
std::unique_ptr<T[]> being the simplest wrapper you can have around that
<egg|zzz|egg>
GreeningGalaxy: well there's a different option, if the size of your array is a compile-time constant
<egg|zzz|egg>
you can use std::array<T, size>
<GreeningGalaxy>
this is on a microcontroller, security against other applications reading the memory is not my biggest concern
<egg|zzz|egg>
GreeningGalaxy: this is not about security
<egg|zzz|egg>
none of this has to do with security, it's about correctness, and not going insane from having to track ownership manually
<GreeningGalaxy>
okay, what is ownership exactly
<egg|zzz|egg>
GreeningGalaxy: you don't want to fill up your memory with crap you've allocated, so you don't want to have memory leaks
<egg|zzz|egg>
GreeningGalaxy: afknomz
<egg|zzz|egg>
GreeningGalaxy: will eggsplain after dinner
<egg|zzz|egg>
unless whitequark beats me to it
<whitequark>
um
<whitequark>
heads-up unique_ptr<T[]> is horribly broken in MSVC
<whitequark>
until at least 2013
<whitequark>
and I think in 2015 too?
<whitequark>
GreeningGalaxy: anyway what egg said is all right
<whitequark>
let me make some food and I'll maybe talk about ownership
* egg|zzz|egg
is back
<egg|zzz|egg>
GreeningGalaxy: hah, whitequark did the same thing :D
<egg|zzz|egg>
whitequark: dunno, we use unique_ptr<T[]> a bit in our code
<egg|zzz|egg>
we're on 2015 fwiw
<egg|zzz|egg>
!choose eggsplain ownership to GreeningGalaxy|the colourless fermion will do it better
<Qboid>
egg|zzz|egg: Your options are: eggsplain ownership to GreeningGalaxy, the colourless fermion will do it better. My choice: the colourless fermion will do it better
<egg|zzz|egg>
;choose eggsplain ownership to GreeningGalaxy|the colourless fermion will do it better
<kmath_>
egg|zzz|egg: eggsplain ownership to GreeningGalaxy
<kmath_>
<daisyowl> if you ever code something that "feels like a hack but it works," just remember that a CPU is literally a rock that we tricked into thinking
<whitequark>
egg|zzz|egg: I think the problem is a move constructor or something
<egg|zzz|egg>
whitequark: ach. in 2013 move conversion was broken
<whitequark>
try uhhhh putting a struct with an unique_ptr<T[]> field into a std::vector
<egg|zzz|egg>
whitequark: works in hte 2017 that godbolt has, feeling a bit too lazy to set up a project in my 2015 for that
<egg|zzz|egg>
s/hte/the
<Qboid>
egg|zzz|egg meant to say: whitequark: works in the 2017 that godbolt has, feeling a bit too lazy to set up a project in my 2015 for that
<Thomas>
It is funny how Qboid and kmath_ always have different opinions :D
<SnoopJeDi>
Entangled bots!
<GreeningGalaxy>
bah. I was so close to having it working, but it kept failing for borked reasons, and then I gave up to go do something else -- and then I discovered when I came back that I'd forgot to attach the MCU to a common ground with the chip it's meant to be operating. >_<
<egg|zzz|egg>
GreeningGalaxy: so should I try to eggsplain ownership? or should I let whitequark do it?
<SnoopJeDi>
I...this software throws an error, but it appears to depend on the size of the fieldmap and is not a memory ceiling problem?
<whitequark>
GreeningGalaxy: I made that mistake a disturbing amount of times
<SnoopJeDi>
Good thing it reports the exact file and line number of the error without any contextual information, so that I have to dig out the right version of the file in the repo
<SnoopJeDi>
since `master` doesn't actually have any history and each version has its own branch
* egg|zzz|egg
pokes GreeningGalaxy with a stick
<GreeningGalaxy>
egg|zzz|egg: go for it?
<GreeningGalaxy>
I think I did what I was trying to do with the SPI bus but for some reason the chip isn't listening
<GreeningGalaxy>
but yeah I do want to hear what ownership is in C++
<egg|zzz|egg>
GreeningGalaxy: well, it's not just in C++, it's a general thing (and whitequark would be able to talk about how it works in rust and how rust is a paradise tessellated with unicorns, but I don't know rust)
<whitequark>
egg|zzz|egg: ownership in rust and in c++ is remarkably similar
<whitequark>
actually from some of the things you said earlier I assumed you somehow knew rust
<egg|zzz|egg>
whitequark: yeah, but C++ has no borrowcheka
<egg|zzz|egg>
GreeningGalaxy: so, in C (or things with similarly bad memory management), the way you work with allocated memory is you do p = malloc(some number of bytes please); /*do some work with p*/ free(p); /*don't refer to the memory that was pointed to by p again*/
<egg|zzz|egg>
GreeningGalaxy: now, control flow is rarely that linear; you may have (as in your case) a function that produces an array; then you have to document that the caller is responsible for deleting the result (so p = make_me_an_array(); do_stuff(p); free(p))
<egg|zzz|egg>
GreeningGalaxy: eventually things may get complicated, and you run into the risk of forgetting to free
<egg|zzz|egg>
GreeningGalaxy: in C++, you'd say new instead of malloc and delete instead of free, but it's the same thing
<egg|zzz|egg>
GreeningGalaxy: but that's only an issue with allocated memory: if you have a really big struct that you return on the stack, and you play with it for a while, it will go out of scope eventually, and that will kill it
regex has joined #kspacademia
<egg|zzz|egg>
GreeningGalaxy: the idea is to have an object that *owns* some allocated memory: when it dies (from going out of scope, or being removed from a container, etc.), it frees that memory
<egg|zzz|egg>
GreeningGalaxy: to the user that behaves very much as if the object were a big struct that actually contained that memory (but it's still allocated memory somewhere else, and the object really only has a pointer to that)
<GreeningGalaxy>
whitequark: (don't worry egg I'm still listening) is it normal for an SPI bus to sort of pause for a few microseconds after every byte (CS is still low, it's just an extra long clock cycle)
<GreeningGalaxy>
I'm embarrassed to say I don't remember, and this chip sure isn't excited about responding
<egg|zzz|egg>
GreeningGalaxy: for instance, in C++, std::unique_ptr<T*> is a pointer to T that will delete itself when it goes out of scope or is otherwise destroyed. std::unique_ptr<T[]> is pretty much the same thing except it owns a C array. std::vector is <whatever implementation-defined> that's a resizeable array, which again owns some chunk of memory (typically larger than the part actually in use). Same for std::string,
<egg|zzz|egg>
or other containers: when the container dies, the stuff it contains is freed without you needing to worry about it
<egg|zzz|egg>
GreeningGalaxy: now, if we go back to the beginning p = malloc(some number of bytes please); /*do some work with p*/ free(p); /*don't refer to the memory that was pointed to by p again*/ this takes care of forgetting to free. There is another, much more complicated issue
<egg|zzz|egg>
which is accidentally using that memory after freeing it
<egg|zzz|egg>
(forgetting to free is called leaking. Using the memory after freeing it is called use-after-free, conveniently enough)
<egg|zzz|egg>
GreeningGalaxy: this is much harder.
<egg|zzz|egg>
GreeningGalaxy: and it is, in a sense, worse: if you leak, you fill up your memory: if you use-after-free, you stomp random bits of the memory with crap, or read crap, and all goes to hell
<egg|zzz|egg>
GreeningGalaxy: a solution to this is Rust's, which afaict does some smart static analysis to tell whether you don't refer to things after they have been freed (and also prevents race conditions on allocated memory and other fancy things). Ask whitequark for details. Other solutions have existed: for instance since leaking is bad, but use-after-free is incorrect, you can imagine having pools restricted to scopes
<egg|zzz|egg>
wherein you allocate a lot (and leak in the pool), but only refer to the pool within its scope; when the pool goes out of scope all of it gets freed. This was Ada's solution (with an escape hatch for manual freeing with Unchecked_Deallocation). Let's say that it was modern in 83 and leave it at that.
<egg|zzz|egg>
GreeningGalaxy: and then you have managed languages, where if someone has kept a reference the thing just isn't deallocated, but you're probably familiar with that (it poses its own share of problems)
<egg|zzz|egg>
GreeningGalaxy: did that make sense?
<egg|zzz|egg>
whitequark: also, did that make sense?
* egg|zzz|egg
likes how these two questions have a different meaning :-p
<whitequark>
as long as you are within timing constraints you can use any clock waveform at all
<whitequark>
egg|zzz|egg: it makes sense but it's not the essence of ownership
<egg|zzz|egg>
right, I should say that this formalizes the C technique of having at any time one pointer that's responsible for being the one through which deletion will occur
<whitequark>
the essence of ownership is that you're building a (mostly) tree out of your data structures
<whitequark>
yeah
<GreeningGalaxy>
egg|zzz|egg: it sort of made sense but I still don't understand why my code didn't work
<whitequark>
oh
<whitequark>
the array thing?
<whitequark>
there's no inherent reason, C is just stupid around arrays
<egg|zzz|egg>
your array was on the stack I think?
<whitequark>
you can return an array in rust just fine
<egg|zzz|egg>
and yes, C is bad at arrays.
<whitequark>
there's literally no reason other than "c is shit"
<egg|zzz|egg>
indeed.
<whitequark>
and "c arrays are fake actually"
<egg|zzz|egg>
that, too :D
<egg|zzz|egg>
(they literally decay to pointers)
ferram4 has quit [Ping timeout: 206 seconds]
<GreeningGalaxy>
although the new problem now is that my circuit does the same thing with this chip plugged in as it does with it pulled out
<GreeningGalaxy>
♪ oh you plug the IC in, and pull the IC out, and the circuit doesn't work it's just the same! ♬ just the same, just the same...♪
<egg|zzz|egg>
GreeningGalaxy: also I am very confused by the fact that you're not @GreeningGalaxy anymore
<GreeningGalaxy>
for a second I thought you were saying I wasn't opped anymore
<egg|zzz|egg>
GreeningGalaxy: I could, but it wouldn't change things, I don't actually look at my timeline
<egg|zzz|egg>
I randomly go to twitter.com/whomever
<SnoopJeDi>
GreeningGalaxy does tweet good tweets
<SnoopJeDi>
would follow again
<GreeningGalaxy>
sometimes I do, sometimes it's just griping about the person across from me on the train
<GreeningGalaxy>
I should do that less but eh
<SnoopJeDi>
I mostly just RT misc things
* Iskierka
also just has a couple twitter tabs that cycle through a few interesting people
<SnoopJeDi>
yea, twitter got better when I put all the news/news commentary on quarantined lists
<SnoopJeDi>
except for a handful of people whose opinions about those things I *really* respect
<SnoopJeDi>
Although I guess I accidentally produced OC with my numpy meshgrid thingy
<egg|zzz|egg>
GreeningGalaxy: right, so to clarify, in light of what whitequark said, what ownership *is*, as opposed to how you should implement it in modern C++/Rust: say you have your array p = make_me_an_array(please); and some object in your code needs to look at that array, so keeps a pointer to that nosy_object.q = p; both the object that contains p and the one that contains q have a life of their own, and eventually
<egg|zzz|egg>
you write the code that does cleanup: which one is responsible for clearing that memory? you don't want to free p if q is still going to be looked at (they're the same memory), and vice-versa (and in C you also don't want to double-free, because C is awful). Now, what you do is that you decide, e.g., that p is the owner, and that deletion will occur through that one: that means that you have to ensure that
<egg|zzz|egg>
nosy_object.q isn't dereferenced after p gets freed, and so in a simple case this may mean that the nosy object should have a shorter lifetime than p's
<soundnfury>
egg|zzz|egg: alternatively, you use reference counting and allow *multiple* pointers to own an object
<soundnfury>
also, fake arrays are best arrays ♥
<egg|zzz|egg>
GreeningGalaxy: yes, I was about to type what soundnfury said: you can also have shared ownership
<egg|zzz|egg>
multiple pointers being responsible for the deletion of an object, the last one to die doing the deletion (with potentially additional non-owning pointers looking at the mess)
<egg|zzz|egg>
(of course that requires the last one to die to know that it is the last one, so typically reference counting)
<egg|zzz|egg>
and in a sense Ada's pools are shared ownership too, except it's really at the type level; all pointers of some type may own anything in the pool, and they all cease to exist when the pool does (though in narrower scopes you may also hold non-owning pointers to an outer pool)
<SnoopJeDi>
wouldn't surprise me if there was `h5_open_file3()` as well ?
<egg|zzz|egg>
whitequark: I sort of want to retweet "C arrays are fake actually" >_>
<egg|zzz|egg>
!u ?
<Qboid>
U+1F612 UNAMUSED FACE (?)
<Iskierka>
are any arrays not fake?
<egg|zzz|egg>
there are languages where arrays aren't shown as the rotting guts of pointer arithmetic (and they don't even have to be that underneath, you can have packed arrays)
<whitequark>
egg|zzz|egg: i'm not sure how to tweet it with context
<egg|zzz|egg>
there are languages where arrays know their bounds
<whitequark>
lol rotting guts
<GreeningGalaxy>
great, the stlink on one of my nucleo boards just randomly fried itself
<GreeningGalaxy>
MCU itself is still fine, but now I can't program it
<egg|zzz|egg>
whitequark: dunno, you are very good at tweeting things devoid of context :-)
<whitequark>
egg|zzz|egg: really?
<whitequark>
I even add footnotes to my tweets with citations
<egg|zzz|egg>
whitequark: I did that once
<egg|zzz|egg>
well it was a thread with a bibliography
<egg|zzz|egg>
(frankly even though I read twitter a lot I still have no idea how to use it: that was an attempt at using it to tweet a short proof)
<kmath_>
<eggleroy> Cute elementary proof of the closed-form for Cₙ: to get a full binary tree on n+1 leaves, draw a cladogram on n+1 species, remove the names.
<whitequark>
I do that fairly regularly, not that twitter actually lets me search for ¹
<whitequark>
(they normalize it to NFC I think)
<egg|zzz|egg>
whitequark: yeah, I saw that in your tweets several times
Thomas is now known as Thomas|AWAY
<GreeningGalaxy>
tz... any idea how I might go about converting two bytes of char (e.g. something between 0x0000 and 0xFFFF) into a float between zero and one?
<kmath_>
<eggleroy> the n+1 labels may appear in (n+1)! different orders. Thus the number of trees (the nth Catalan number) is Cₙ = 2ⁿ (2n-1)‼︎ / (n+1)!. ∎
<GreeningGalaxy>
I've completely lost track of types tbh
<soundnfury>
GreeningGalaxy: it the endianness specified?
<Iskierka>
iunno how many languages agree but char can cast to int in java (numerically a subset) and int to float
<soundnfury>
s/it/is
<Qboid>
soundnfury meant to say: GreeningGalaxy: is the endianness specified?
<GreeningGalaxy>
analogin.u16_read() is supposed to produce an int, but assigning a char to it worked, and so did sending that char over the air
<GreeningGalaxy>
but I can't figure out how to pick it up on the other end
<GreeningGalaxy>
soundnfury: um, probably? it's an STM32 Nucleo L432KC. I have heard the word Endianness before but don't know what it means.
<egg|zzz|egg>
GreeningGalaxy: you can assign an int to a char, but if it overflows the behaviour is undefined
<soundnfury>
char foo[2] = {0, 1}; *(uint16_t)foo; // 1 or 256, according to taste
<egg|zzz|egg>
GreeningGalaxy: or do you mean a char array?
<GreeningGalaxy>
I don't know
<egg|zzz|egg>
that's well-defined because character types are magic
<egg|zzz|egg>
*summons the aliasing rules*
<egg|zzz|egg>
GreeningGalaxy: show us the code? this discsusion gets mildly confusing
<GreeningGalaxy>
I know it looks like a burning bus
<egg|zzz|egg>
it looks like C mostly
<soundnfury>
uh, that is not reading two chars
<egg|zzz|egg>
I think whitequark has an opinion on C++ that looks like C
<soundnfury>
or if it is, it's still sticking it in one char
<GreeningGalaxy>
yeah I didn't think so
<soundnfury>
what is the prototype of this read_u16 function?
<GreeningGalaxy>
the prototype?
<egg|zzz|egg>
the signature
<egg|zzz|egg>
what does it take and return
<soundnfury>
assuming it is uint16_t (*read_u16)(void);
<soundnfury>
you will want uint16_t something = knob0.read_u16();
<egg|zzz|egg>
soundnfury: mind you it's a member function of something, that's not *quite* C :-p
<GreeningGalaxy>
it's a method of an AnalogIn object or whatever that thing is, it returns a sixteen-bit int
<egg|zzz|egg>
soundnfury: thus drop the (void) please :-p
<soundnfury>
egg|zzz|egg: the _type_ is still function pointer, C++ is just a fugly preprocessor :P
<egg|zzz|egg>
GreeningGalaxy: right, you're converting a 16-bit int to a presumably 8-bit thing
<soundnfury>
nrf0.write(GIBBER_PIPE_P0, &cpu_to_le16(something),2); // or something like that
<GreeningGalaxy>
okay, how do I split it up
<egg|zzz|egg>
(we shall henceforth assume that bytes are 8 bits)
<soundnfury>
(also cpu_to_le16 doesn't actually necessarily exist. Maybe htons would be better, use Network Byte Order)
<whitequark>
soundnfury: the type of a member function is not a function pointer
<whitequark>
it's a pointer-to-member
<whitequark>
uint16_t (*X::read_u16)()
<egg|zzz|egg>
GreeningGalaxy: store in an uint16_t variable, reinterpret_cast that to a pointer-to-character
<egg|zzz|egg>
and yes, what whitequark said
<soundnfury>
whitequark: the type of the function itself is function type, and because C++ method dispatch is compile-time that's a meaningful statement
<GreeningGalaxy>
egg|zzz|egg: do what?
<soundnfury>
so it's something like uint16_t (*read_u16)(AnalogIn *); // maybe
<whitequark>
soundnfury: incorrect
<soundnfury>
egg|zzz|egg: don't just reinterpret_cast it, you need an htons in there
<soundnfury>
because endians
<whitequark>
the ABI of function pointers and pointers-to-member is different
<whitequark>
and you can't convert between those without invoking ub
<soundnfury>
whitequark: well that makes no sense
<egg|zzz|egg>
GreeningGalaxy: soundnfury makes a good point about endianness, which we shall ignore for a second; std::uint16_t two_friendly_bytes = knob0.read_u16();
<soundnfury>
clearly C++ is a wretched skive of vum and hillany
<whitequark>
soundnfury: I think the reason it's done like that is basically 32-bit x86
<egg|zzz|egg>
soundnfury: your noise to signal ratio is a bit high today
<GreeningGalaxy>
what's two_friendly_bytes? An array?
<egg|zzz|egg>
an integer
<egg|zzz|egg>
a 16-bit unsigned integer
<egg|zzz|egg>
hence uint16_t
<whitequark>
soundnfury: e.g. MSVC uses a special "thiscall" convention for member functions that stuffs this into ecx
<whitequark>
the fact that they can have different ABIs is probably not particularly useful anymore and hasn't been for a while
<whitequark>
with std::bind, the `this` argument is just another argument, even
<egg|zzz|egg>
GreeningGalaxy: mind you uint8_t is (probably) unsigned char, rather than char; you may want to use char depending on what you need, I tend to try to use uint8_t whenever I'm just handling bytes
<egg|zzz|egg>
rather than say bytes-from-an-utf-8-string
<whitequark>
egg|zzz|egg: uint8_t is definitely an unsigned char
<egg|zzz|egg>
whitequark: is that truly mandated by the standard?
<whitequark>
(it's not permitted to exist on architectures with non-octet chars)
<soundnfury>
you really don't need to break the type system for this, you know
<egg|zzz|egg>
whitequark: it has to be 8-bit, but can it be a non-character type when char is an octet
<egg|zzz|egg>
I think that's technically a possibility
<egg|zzz|egg>
that can screw you for strict aliasing
<GreeningGalaxy>
ugh fine I'll just learn how to use the nRF directly without the library
<soundnfury>
you could just say unsigned char txq[2] = {two_friendly_bytes & 0xff, two_friendly_bytes >> 8};
<whitequark>
egg|zzz|egg: hmm
<egg|zzz|egg>
and that's uninteresting in practice
<GreeningGalaxy>
then I can just feed it the int directly
<egg|zzz|egg>
because it's always unsigned char
<whitequark>
also what soundnfury says
<whitequark>
that avoids aliasing issues
<whitequark>
erm
<whitequark>
endianness issues
<egg|zzz|egg>
ah yes
<egg|zzz|egg>
there are no aliasing issues unless uint8_t is profoundly evil though :-p
<egg|zzz|egg>
whitequark: also that thread about 13-bit char etc. was really funny :-p
<soundnfury>
basically, in C you hardly ever actually need to cast (dunno about C++)
<egg|zzz|egg>
~ULP distance~
<egg|zzz|egg>
(but you actually need to memcpy for that)
<egg|zzz|egg>
(because aliasing rules)
<whitequark>
egg|zzz|egg: interestingly you are right
<whitequark>
uint8_t doesn't have to be a char
<whitequark>
*however* a char has to be the minimal addressable unit
<GreeningGalaxy>
the transmit function won't take an unsigned char, just a regular one
<whitequark>
so if you can have a pointer to uint8_t it can't be smaller than char
<GreeningGalaxy>
did, and it did at least compile
<whitequark>
I suppose it could be *larger* than char
<whitequark>
which is insane
<egg|zzz|egg>
:D
<egg|zzz|egg>
whitequark: 7-bit chars maybe?
<egg|zzz|egg>
GreeningGalaxy: and do what soundnfury/whitequark says because endians
<GreeningGalaxy>
but now how do I pick it up on the other end and turn two chars into a float?
<whitequark>
egg|zzz|egg: no
<egg|zzz|egg>
whitequark: ah they have to be at least 8?
<egg|zzz|egg>
whitequark: right so then uint8_t has to be exactly 8 bits, it's just that it may not be a character type (it can be another type that's exactly the same as unsigned char except for the aliasing rules)
<GreeningGalaxy>
imagine if this were python, I could just be like str(int(knobvalue,16))[1]
<egg|zzz|egg>
(that would be profoundly evil)
<whitequark>
hm, the only requiremnet on char is that the basic execution character set must fit in it
<whitequark>
ugh
<whitequark>
c is disgusting
<egg|zzz|egg>
so char *can* be 7 bits :_p
<whitequark>
GreeningGalaxy: whats on the other end
<egg|zzz|egg>
can it fit in 6?
<GreeningGalaxy>
whitequark: the other transceiver and MCU
<egg|zzz|egg>
with trigraphs or whatever?
<whitequark>
hm
<whitequark>
the canonical way to cast between a float and its constituent bytes is uh
<GreeningGalaxy>
so I get to pull down two chars from the xceiver and I would sort of like to turn them into a PWM duty cycle
<whitequark>
union { float f; uint8_t b[4]; } conv;
<egg|zzz|egg>
whitequark: but I think in C++ you have additional requirements that make it so that char is 8 bits? Stratege had looked into that
<egg|zzz|egg>
whitequark: that's UB
<whitequark>
egg|zzz|egg: what?
<egg|zzz|egg>
not in C, but in C++ it is
<whitequark>
oh
<whitequark>
ugh
<egg|zzz|egg>
there are no compatible types in C++
<whitequark>
okay, then reinterpret_cast.
<egg|zzz|egg>
whitequark: yup. but for ULPs, you want to actually subtract ints
<whitequark>
so *ideally* reinterpret_cast and then manually stuff the bytes into an array
<whitequark>
but if the endpoints are identical
<egg|zzz|egg>
so you would cast to uint64_t, and *bleep* violate aliasing rules
<GreeningGalaxy>
I knew type conversion outside the sheltered garden of Python was scary but I didn't know it was this insane
<whitequark>
egg|zzz|egg: oh right
<whitequark>
*sigh*
<whitequark>
GreeningGalaxy: no it's just c
<whitequark>
c is Bad
<egg|zzz|egg>
GreeningGalaxy: what whitequark said.
<whitequark>
few other languages come anywhere close
<soundnfury>
GreeningGalaxy: type-casting is like using the struct module with different struct definitions
<soundnfury>
whitequark: C represents what your machine has to actually do. The reason few modern languages do that is because C is so damn _good_ at it that it became a category killer
<GreeningGalaxy>
and I still don't know how I killed this programmer
<egg|zzz|egg>
GreeningGalaxy: I mean you've fallen into a nest of people who actually look at the strict aliasing rules, and know a bit about language design, so we're pretty much spewing the worst at you here
<egg|zzz|egg>
ah my client still does this rewrite of "lol"
<whitequark>
soundnfury: C represents a series of instructions for the C abstract machine. that's it
<egg|zzz|egg>
whitequark: maybe relatively close to some PDP? maybe? I don't know enough about these old machines
<whitequark>
egg|zzz|egg: nope
<whitequark>
this is a much later development
<egg|zzz|egg>
!acr -add:PDP Programmed Data Processor
<Qboid>
egg|zzz|egg: I already know an explanation for PDP! (Update it with !acr -update:PDP Programmed Data Processor)
<whitequark>
in PDP days, before the C specification, before anything but peephole optimization, C *was*, largely, what soundnfury thinks it still is
<whitequark>
of course, if C remained like that, it wouldn't actually be known as "the fast language" like it is commonly referred to today
<egg|zzz|egg>
whitequark: right, I mean the language was designed as that (and then modern compilers and modern architecture and language evolution made it no longer that)
<whitequark>
right.
<whitequark>
egg|zzz|egg: also, correction: I don't know the strict aliasing rules.
<egg|zzz|egg>
whitequark: neither do I.
<whitequark>
they're the second dumbest part of C, right after the fact that provably infinite loops are UB
<egg|zzz|egg>
whitequark: but we know *about* the strict alialing rules.
<whitequark>
(C11 carved out an exemption for while(1){} specifically, which just made the whole thing more ridiculous)
<egg|zzz|egg>
and thus we're exposing GreeningGalaxy to the deepest madnesses of C right as she starts looking outside of her snake
<whitequark>
egg|zzz|egg: see, this is why so many people writing C are assholes
<egg|zzz|egg>
GreeningGalaxy: really, the world outside the snake is nice
<whitequark>
they suffered, and now they feel that you also should suffer
<egg|zzz|egg>
GreeningGalaxy: C isn't
<whitequark>
"everyone should know C" is really just a hazing ritual.
<egg|zzz|egg>
I haven't written any C per se
<egg|zzz|egg>
languages in order: VB6, VB .NET, C#, Ada 95, a bit of Java, C++
<egg|zzz|egg>
I shan't count the matlab I did at ETH nor the few lines of R in there
<soundnfury>
whitequark: I'll just point out that most of the crazy optimisation compilers do is either wrong ("the standard allows us to assume your program is shit, so we used -fstrict-aliasing and compiled your program to be shit") or not actually helpful (OoO processors can do it without compiler help)
<whitequark>
soundnfury: that's irrelevant.
<soundnfury>
whitequark: and I set the hazing bar _far_ higher than just knowing C. More like "everyone should write a Linux kernel patch and get it accepted" :P
<whitequark>
if you claim to write portable code, you have to write it against the C standard
<whitequark>
if you claim to write code that works with specific version of gcc's C dialect, sure, go ahead
<whitequark>
also, lol, OoO
<egg|zzz|egg>
(that looks like a cute smiley though)
<whitequark>
did you know that every single OoO processor ever brought to market has a watchdog that, when (not if) it locks up, flushes all of its internal state and tries again
<SnoopJeDi>
I like snakeland
<whitequark>
which happens with disturbing regularity, and results in massive latency spikes
<egg|zzz|egg>
SnoopJeDi: it's nice out of snakeland; but don't jump into C-land, it's madness
<SnoopJeDi>
I'm sure it is
<egg|zzz|egg>
and if you must jump into C++ land, don't jump into the C end of it
<SnoopJeDi>
I just have no compelling reason to go there at the moment
<soundnfury>
whitequark: there exist de-facto 'standards' that lie somewhere between "gcc version 4.08.wombats (x86_64, lolbuntu4)" and "ISO:IEC9899"
<soundnfury>
whitequark: hence why the kernel, which is distinctly *not* standard C, can be compiled with many gcc, llvm, possibly also tcc or lcc or something, probably icc as well.
<whitequark>
soundnfury: you forgot one more level of emphasizing that these aren't actually standards, and you cannot actually rely on them in a robust way.
<whitequark>
try another layer of quotes.
<GreeningGalaxy>
so uh, I tried something, and it compiled and ran, but instead of the LED wired up to the PWM output dimming when I turned the knob on the other controller, the one connected to the SCLK pin of the SPI bus dimmed instead
<whitequark>
compiling the kernel with clang was a fairly nontrivial undertaking.
<GreeningGalaxy>
I'm just going to give up, flash these with some innocuous program, and run away screaming
ferram4 has quit [Read error: Connection reset by peer]
<egg|zzz|egg>
GreeningGalaxy: no! don't go back to snakeland just yet! :-p
<whitequark>
among other things, the linux kernel relied on gcc's idoitic mixup of optimization and builtin expansion stages
<soundnfury>
whitequark: in the real world (yeah, I know, taboo subject in #kspacademia) engineers have to accept something other than high-church ivory-tower strictly-conforming bees.
<GreeningGalaxy>
egg|zzz|egg: the SPI SCLK duty cycle is never supposed to change. I think I need to lie down for a while
ferram4 has joined #kspacademia
<whitequark>
soundnfury: in the world of competent people, engineers actually conform to standards.
<egg|zzz|egg>
soundnfury: uhm, you could try to think about who actually is in this channel, and be a fair bit more decent.
<whitequark>
pick, ummm, literally any other abstract machine than C
<whitequark>
JVM, CLR, ...
<whitequark>
JVM also had a decent memory model way before C did, incidentally.
<whitequark>
something something describing what the machine should do.
<soundnfury>
egg|zzz|egg: I'm a kernel hacker, I'm *supposed* to be rude, condescending and opinionated. It's in the rules
<whitequark>
Linux was a mistake
<soundnfury>
whitequark: JVM gets to define that because it's a VM and isn't expected to be fast on every hw
<whitequark>
lol
<egg|zzz|egg>
soundnfury: the egg gets it, but the egg ran uncomfortably close to not being amused.
<soundnfury>
C's memory model was originally defined as "yeah, read your processor's architecture documentation, don't bug us about it"
<whitequark>
the Java machine and the C machine are exactly equivalent to each other
<soundnfury>
and arguably that's *better* than having the language know about it. Same reason as why C leaves so many *other* things implementation-defined
<GreeningGalaxy>
I'm going to go see if Micro center has Python microcontrollers (aka Pi Zeros) in stock.
<whitequark>
so you're saying that being able to write portable lockless algorithms is worthless.
<whitequark>
gotcha
<soundnfury>
whitequark: that depends entirely on your definition of "portable".
<SnoopJeDi>
all hail MicroCenter
<soundnfury>
and also on whether you have a decent arch/ mechanism
<whitequark>
pffff
<soundnfury>
(ACCESS_ONCE and RCU work on all the arches Linux supports, which, in case you hadn't looked recently, is quite many)
<GreeningGalaxy>
SnoopJeDi: they're complete thieves but at least they sometimes have Pi Zeros.
<SnoopJeDi>
I think their pricing is reasonable factoring in the B&M overhead
<soundnfury>
the point is that it's not up to the _language_ to define the memory model
<SnoopJeDi>
which obviously can't compete with online, but it's not supposed to
<SnoopJeDi>
(not on a price basis)
<GreeningGalaxy>
they charge like the better part of a dollar for a single 2N3904
<GreeningGalaxy>
egg|zzz|egg: Principia for microcontrollers when?
<whitequark>
GreeningGalaxy: right now? :p
<GreeningGalaxy>
right, all CPUs are microcontrollers
<whitequark>
starting with Haswell, Intel CPUs suit the definition of a "microcontroller"
<GreeningGalaxy>
okay, Principia for AVR when?
<whitequark>
and probably even before that but *definitely* post-Haswell
<whitequark>
GreeningGalaxy: well, you could emulate x86 on an AVR
<egg|zzz|egg>
AVR?
<whitequark>
someone booted Linux on ARM emulated on an AVR
<whitequark>
uclinux, but still
<whitequark>
so you could for example
<whitequark>
to avoid implementing x86's MMU yourself
<whitequark>
you could run principia in qemu on uclinux on an arm emulated by an avr
<egg|zzz|egg>
I vaguely wonder whether Principia could (this is stupid and theoretical mind you) benefit from some dedicated coprocessor fpga; I don't think we have anything quite slow enough (and parallelizable/vectorizable) for that to be worthwile though
<whitequark>
what's in the profile
<egg|zzz|egg>
evaluating whatever series :-p
<egg|zzz|egg>
s/whatever/Чебышёв/
<Qboid>
egg|zzz|egg meant to say: evaluating Чебышёв series :-p
<whitequark>
mmm
<egg|zzz|egg>
but tbh that's liable to change, as I tweeted to you a while ago
<egg|zzz|egg>
tweeted at you? to you? in your general direction?
<egg|zzz|egg>
we need a treatise on twitter grammar
<egg|zzz|egg>
we'd probably want to reduce the order of the polynomials eventually
<egg|zzz|egg>
e.g. x^5 + 2 x^17 has order 5 and degree 17
<egg|zzz|egg>
I like how we switch from talking about strict aliasing to assemblers to cat tongues to FPGAs to polynomials within an hour :D
<egg|zzz|egg>
whitequark: as an invariant, I'd expect the main expense to be some sort of floating-point business
<egg|zzz|egg>
if it's integration, it's quite sequential
<egg|zzz|egg>
if it's changing the frame of an integrated trajectory for plotting, that's embarassingly parallel
<egg|zzz|egg>
but it's not *that* costly
<egg|zzz|egg>
I think for now the biggest cost is the integration unless we're just plotting too many points
<egg|zzz|egg>
(we should decimate the points in a smart way)
GreeningGalaxy has quit [Ping timeout: 190 seconds]
<egg|zzz|egg>
whitequark: re. tweeting context-free things, I think that's mostly your "OH" tweets; but then you were the one saying it, so I guess that would logically mean I should tweet that...
<egg|zzz|egg>
hmm.
<egg|zzz|egg>
!wpn
* Qboid
gives egg|zzz|egg an int DDOS/projection hybrid
<egg|zzz|egg>
!wpn whitequark
* Qboid
gives whitequark an acyclic pig with a field attachment
regex has quit [Remote host closed the connection]
<soundnfury>
!wpn
* Qboid
gives soundnfury a polonium modem
<soundnfury>
+ATIRRADIATE
<egg|zzz|egg>
!choose zzz|DF
<Qboid>
egg|zzz|egg: Your options are: zzz, DF. My choice: DF
<egg|zzz|egg>
;choose zzz|DF
<kmath_>
egg|zzz|egg: DF
<egg|zzz|egg>
hmm
<egg|zzz|egg>
that can't be right, the bots agree?