egg changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Cesàro. We currently target both 1.2.2 and 1.3. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/
icefire_ has joined #principia
icefire_ has quit [Client Quit]
e_14159 has quit [Ping timeout: 186 seconds]
e_14159 has joined #principia
<awang>
egg|zzz|egg: More image of my ballistic lunar transfer, including an one with the ECSA frame of reference
<GH>
[Principia] pleroy commented on issue #1604: Are you running with an option that causes `make` to execute actions in parallel? That would be the only explanation for a "race condition". The Makefile is certainly not ready to do that. We see similar issues on Windows when building in parallel. When that happens, just retry, we are not going to implement filesystem locking. https://git.io/vdXxe
<GH>
[Principia] aw1621107 commented on issue #1604: Yep, running `make -j <n>`. Didn't know that that isn't supported. Sorry! https://git.io/vdXxf
<GH>
[Principia] aw1621107 closed issue #1604: Possible race condition in Makefile? https://git.io/vdXAO
<egg|zzz|egg>
awang: for that crash with the absurly-far-away rocket, could you reproduce it while journalling and send us the journal? we're having trouble understanding what is happening
<awang>
egg|zzz|egg: Sure, let me finish up this bug report for the SIGILL/EXC_BAD_ACCESS
<egg|zzz|egg>
awang: no need for a bug report on that one
<egg|zzz|egg>
awang: we have no way of reproducing it
<egg|zzz|egg>
awang: (if you do a journal do it exactly at a release btw, not at some random place in the tree, because there are journal-incompatible sometimes between releases)
<awang>
:(
<awang>
Alright I'll get on the journal thing then
<awang>
Luckily, the crash with super-rocket was using lamont's build
<awang>
So we should be good for that at least
<awang>
egg|zzz|egg: It'll take a while for KSP to boot up
<awang>
Don't have a MM cache handy
<awang>
I think
<awang>
Blame blowfish
icefire has quit [Read error: Connection reset by peer]
<GH>
[Principia] pleroy tagged 2017101919-Chasles at 8d526e1: https://git.io/vdXho
<awang>
egg|zzz|egg: Do you want the INFO file too?
<awang>
Or just the journal?
xShadowx|2 has joined #principia
xShadowx has quit [Ping timeout: 200 seconds]
<awang>
The journal is also 462MB
<awang>
Also, do you need KSP.log and/or Player.log?
<awang>
Something wonky seems to be going on with Dropbox right now, so can't upload the journal :(
<egg|zzz|egg>
awang: the journal will suffice
<egg|zzz|egg>
awang: and yeah, journals are big
<egg|zzz|egg>
awang: try Google Drive?
<awang>
egg|zzz|egg: Wow, completely forgot that that was a thing
<awang>
ETA 15 minutes
HebaruSan has quit [Remote host closed the connection]
HebaruSan has joined #principia
<GH>
[Principia] aw1621107 commented on issue #1595: Alright, got another crash. This time, KSP didn't crash immediately upon resetting the camera from the Sun back to the vessel, but it eventually crashed after jumping between the Sun, Mercury (hit tab one time too many a few times), and the vessel in map mode, as well as switching in and out of map mode.... https://git.io/vd1vX
<awang>
egg|zzz|egg: Done!
egg|cell|egg has quit [Ping timeout: 200 seconds]
<egg|zzz|egg>
awang: did you also have a test that sigilled, or was it only in-game? I don't remember
<GH>
[Principia] eggrobin commented on issue #1595: The actual check in the failure above (from the stderr) is... https://git.io/vd1U7
<egg|zzz|egg>
!tell lamont we have tagged Chasles, can you make a mac build there?
<Qboid>
egg|zzz|egg: I'll redirect this as soon as they are around.
<Qboid>
[#14418] title: First issues with macOS 10.13 High Sierra | This is with Developer Beta of macOS 10.13, using Xcode 9 beta, `Apple LLVM version 9.0.0 (clang-900.0.22.8)`.... | https://github.com/Homebrew/homebrew-core/issues/14418
<lamont>
but using lldb the code that blows up appears to be related to WE_LOVE_228
<lamont>
apparently we do not love 228 that much on macs
<lamont>
(wtf is 228?)
<egg|zzz|egg>
#228
<Qboid>
[#228] title: Keep the whole history | For the moment we compute the histories using `sampling_period == 0`, which results in large gaps in the trajectory at high timewarp (rendered as long straight line segments, see below). We should use `sampling_period == 1` instead, and downsample ourselves as needed when rendering.... | https://github.com/mockingbirdnest/Principia/issues/228
<egg|zzz|egg>
lamont: oh crap you don't love 228 on mac? that's a bug Ꙩ_ꙩ
<awang>
lamont: Yep, I saw the 228 thing in my crashes too
<egg|zzz|egg>
wait awang's screenshots do show 228 still in action, so your Cesàro build must have loved 228
<awang>
Another potentially interesting thing is that the SIGILL was raised by a ud2 instruction
<egg|zzz|egg>
lamont: is it the threading code?
<awang>
egg|zzz|egg: You mean the threading for rendering histories of multiple vessels?
<egg|zzz|egg>
there's no threading there
<egg|zzz|egg>
the threading is in the integration
<egg|zzz|egg>
but last_state_228_ is thread local
<egg|zzz|egg>
maybe that's confusing things?
<awang>
I thought that you disabled that on macOS due to missing shared_mutex for versions < 10.12?
<awang>
Or am I confusing features?
<egg|zzz|egg>
that's the actual mutices
<egg|zzz|egg>
the thread_local variables are still thread_local
<egg|zzz|egg>
as they must be
<awang>
I see
<lamont>
yeah i’m trying a build now that un-disables shared mutexes to see if that actually helps on 10.13
<lamont>
egg: and yeah WE_LOVE_228 is enabled on mac, its inside those define blocks that it blows up on last_state_228_
<lamont>
so we LOVE it but we don’t love it…
<egg|zzz|egg>
lamont: hah
<egg|zzz|egg>
lamont: well we'd like to properly get rid of 228 in 陈景润 fwiw
<egg|zzz|egg>
lamont: do you know which define block?
<lamont>
egg: do you have any rk4 code that also propagates the variation (i think thats the right term)?
<awang>
lamont: Trying the same thing, actually :D
<awang>
Still waiting for the test suite
<awang>
egg|zzz|egg: ephemeris_body.hpp:526 for me
<egg|zzz|egg>
lamont: yeah so accessing a thread_local variable
<egg|zzz|egg>
lamont: is thread_local borked?
<lamont>
for rk4 specifically: “First variations of burn and coast arcs are computed concurrently with the arcs themselves”
<lamont>
so good news is that shared mutexes work fine on 10.13
<lamont>
bad news is we’re still SIGILLIN
<egg|zzz|egg>
aargh
<egg|zzz|egg>
lamont: try replacing the static thread_local with a static in those 228 variables (it will be incorrect and a data race and all kinds of bad, don't make a release out of that, but I want to understand what the hell is going on)
<lamont>
or more precisely i think i want runge-kutta-fehlberg rkf45 and then want to… turn the error estimate into δx?
<awang>
Uh
<egg|zzz|egg>
?
<awang>
How does the google test filter work?
<awang>
I'm trying to run a specific test, but the test executable seems to not want to run any tests at all
<egg|zzz|egg>
awang: put stars before and after, otherwise it matches the full thing
<awang>
Ohhhh
<egg|zzz|egg>
lamont: I feel like I'm missing context for the integration questions (also maybe ask them in kspacademia so you can get bofh's insights)
<awang>
At least on my install the SIGILL appears to come from МолнияOrbitTest.Satellite
<lamont>
so i need to integrate a trajectory with adaptive step size, and rkf45 works good for that
<lamont>
but then i need to run the thing through newton’s method to refine the guess based on the error, and based on the ‘slope’ of the function
<lamont>
so i need to know by how much the trajectory varies based on the partials w.r.t the intiial state + costate conditions
<egg|zzz|egg>
ask bofh
<lamont>
(don’t worry about the word costate, its just a thing ‘cuz calculus of variations mumble mumble potrayagin something...)
<egg|zzz|egg>
pontryagin!
<lamont>
yep
<UmbralRaptor>
Calculus of variations?
<egg|zzz|egg>
Понтрягин!
<UmbralRaptor>
AAAAAAAAAAAA
<egg|zzz|egg>
lamont: anyway, I guess try building Chasles on 10.12 and hopefully we'll have fixed 228 in 陈景润 so you won't need to do that next time...
<lamont>
right i should do that and make sure it doesn’t blow up, got fixed on 10.13
<egg|zzz|egg>
lamont: what do you mean by "got fixed"
<lamont>
*fixated
<egg|zzz|egg>
well I mean it would be good to resolve that, but it seems tricky
<egg|zzz|egg>
it's good to know that shared_mutex will work tho, means that if we can kill 228 and its asociated sigil(l), we can move on to 10.13 and have parallelism
<lamont>
yep
<lamont>
looks like the term i’m looking for is “sensitivities"
<lamont>
ah google results are now finally starting to look better
<lamont>
egg: removing thread_local fixed the compile
icefire has quit [Quit: Leaving]
<egg|zzz|egg>
lamont: that's good to know
<egg|zzz|egg>
lamont: so then we'll try not to add thread_local stuff (and to kill 228) for the next version so you can upgrade :-p
<awang>
thread_local is actually implemented in the libc++ shared lib, right?
<awang>
Wonder if using "real" Clang would fix the issue
<awang>
Or just make things worse due to mixing two different libc++ implementations
<lamont>
(or rather, fixed the tests)
<egg|zzz|egg>
lamont: funny that it seems to work on 10.11
<lamont>
10.11 seems to have been a good vintage year for clang on mac
<egg|zzz|egg>
:D
Jesin has quit [Quit: Leaving]
<awang>
Uh
<awang>
Pretty sure I'm doing something wrong
<awang>
But I took thread_local off of last_state_228_
<awang>
But still end up with SIGILL
<awang>
Do I need to take off thread_local from the std::vector variable too?
<egg|zzz|egg>
yeah, seems that thread_local breaks thnig
<awang>
thread_local on both variables, it seems?
<egg|zzz|egg>
not specific to one variable, it's just thread_local itself
<awang>
Oh
<awang>
Is thread_local only used for WE_LOVE_228?
<egg|zzz|egg>
no actually
<egg|zzz|egg>
but the other thread_local things are local variables rather than class members so maybe it's that
<lamont>
yeah you’re probably doing something overly clever with thread_local
<GH>
[Principia] lamont-granquist opened pull request #1605: only support >= 10.11 (master...lcg/bump-macosx-version-min) https://git.io/vd1gW
<GH>
[Principia] pleroy commented on issue #1605: Can one of the admins verify this patch? https://git.io/vd1gR
<egg|zzz|egg>
lamont: why are the makefile changes needed?
<egg|zzz|egg>
(I mean they make sense, but didn't it work fine before?)
<lamont>
yeah it does
<lamont>
its really weird having them not agree though
<lamont>
and since upgrading mac doesn’t cost any $$$ nearly all users upgrade
<lamont>
and the last bit hardware switch was 64-bit and any 32-bit users have been unsupported
<egg|zzz|egg>
lamont: yeah I agree with the pull request, it's mostly that in principle I like the release we ship to be at the tag so it doesn't say "one commit after Chasles" which might confuse people
<lamont>
oh i’m not doing that
<egg|zzz|egg>
ok, sounds good
<lamont>
i rechecked out the tag and i’m rebuilding clean
<lamont>
that’s for next release
<egg|zzz|egg>
hopefully before the next release (陈景润) we can bump that to 13 :D
<lamont>
if a 10.10 user actually shows up we can consider backiung that back down
<lamont>
yeah, although there’s probably still a lot of 10.12 users
<lamont>
10.13 dropped like 2 weeks ago
<egg|zzz|egg>
ah right, but .12 is the one with shared_mutex right?
<egg|zzz|egg>
or is it in .11 already?
<lamont>
i think that’s clang support?
<lamont>
it seemed to compile fine with a 10.11 floor on 10.13 with the shared mutexes
<GH>
[Principia] pleroy commented on issue #1595: This was a tough one to analyze, and your journal was absolutely critical, thanks a lot for taking the time to record it and send it to us.... https://git.io/vd12e
<lamont>
(but yeah i think 10.12 had shared mutexes but had that other screwy header file compilation problem)
<egg|zzz|egg>
lamont: oh ok, I thought we had an error message about the floor being too low for shared_mutex at some point
<lamont>
hrm, dunno
<awang>
Pretty sure I remember said error
<lamont>
its possible i had the floor removed when i removed the disble-shared-mutex bit….
<lamont>
anywhoo gotta get it compiling on 10.13 first
<egg|zzz|egg>
yeah
<awang>
I "fixed" it by switching to LLVM instead of Apple clang at th etime
<awang>
Hmmm
<awang>
Compiling with -L<path-to-LLVM-libs> causes the test binary to link against the LLVM libc++ shared library
<awang>
But the Apple libc++abi
<awang>
Even though the LLVM libc++ and libc++abi are both in the same directory
<awang>
Or wait
<awang>
Never mind, I'm dumb
<awang>
Reading through things too fast and read libc++.1.0.dylib as libc++abi.dylib
<awang>
Oops
icefire has joined #principia
<GH>
[Principia] pleroy opened pull request #1606: Don't lose accuracy when computing the times in the integrators (master...1595) https://git.io/vd12p
<GH>
[Principia] pleroy commented on issue #1605: ok to test https://git.io/vd1ak
<egg|zzz|egg>
awang: thanks for the bug report and journal on that stupidly fast sounding rocket thing btw, it uncovered an actual bug fairly deep down
<xShadowx|2>
egg found a bug deep down......theres a joke in there somewhere
<awang>
egg|zzz|egg: No problem! Glad that it was useful
<awang>
Also, bad news: compiling with LLVM Clang and linking against LLVM libc++ still results in SIGILL :(
<egg|zzz|egg>
Fun
<awang>
Just tried building with GCC
<awang>
GCC does not like a lot of things about the Principia codebase
<awang>
Including UTF-8, it seems?
<awang>
"./geometry/r3_element.hpp:45:22: error: stray '\302' in program"
<awang>
Why in the world does GCC not support UTF-8 in identifiers...
<egg|zzz|egg>
~gcc~
<egg|zzz|egg>
awang: don't go to gcc, it's a silly place
<awang>
What makes you say that?
<awang>
Genuinely curious
<GH>
[Principia] pleroy closed pull request #1605: only support macosx >= 10.11 (master...lcg/bump-macosx-version-min) https://git.io/vd1gW
<egg|zzz|egg>
awang: that sort of blatant noncompliance (they even document their lack of unicode support)
<egg|zzz|egg>
like, msvc is full of annoying weirdness, but they're working on it
<awang>
Any other examples?
<awang>
I've heard of MSVC's quirks (and had to deal with some of them when porting Visual Studio 6 code), but I'm not as aware of GCC's
<awang>
Most controversial thing I've heard about GCC is complaints that they were pushing undefined behavior too far
<egg|zzz|egg>
nothing specific (since we have Unicode everywhere we haven't tried very far with GCC), but I hear it's a very quirky compiler too
<egg|zzz|egg>
awang: anyway, we'll get rid of the thread_local class members while stabbing 218 and that'll be the end of this story, definitely not looking for other compilers (clang is nice and its error messages are nice)
<awang>
How much work remains before 228 can be laid to rest?
<awang>
I wasn't really looking to trying to add support for another compiler; more just seeing if GCC pops up warnings that Clang doesn't that may help point to how exactly thread_local is screwing things up
<awang>
And switching to clang/c2 means more c++17 features, right? :D