Wait, why the fuck is ./mach fmt putting multiple arguments on their own single line?

It's not even documented…

eijebong: I'm sorry but I need to duplicate a bunch of dependencies.

nox: >_<

Image related ?

Nah.

Ok is this just me,

or rustfmt reordering imports is completely fucked up?

nox: arguments on their own line is probably the line length limit

auscompgeek: The opposite.

Multiple arguments per line, on their own line.

This is not documented.

oh. weird.

I've seen black (the Python autoformatter) do that, but never rustfmt

auscompgeek: servo/servo #22202/commits/1e2a72abfe0d5183a95c7edfa92e531dadd488b0#diff-7637bdaee356e2d89fec3a68089d9175R500

eijebong: I needed gleam 0.6.7,

eijebong: and that brings gl_generator 0.10.

eijebong: I can't be arsed to try to do a glutin bump on a Friday so I'll just whitelist gl_generator/khronos_api/xml_rs.

nox: I have it in the pipes

eijebong: Cool!

Just waiting for the webvr bump to be pubished

Oh.

But I can't publish it because there's only one person with the rights on crates.io

jdm sent them a message yesterday on your slack or somehting

I wouldn't know about that, I'm not on Slack.

Yeah, that doesn't surprise me :p Just telling you about it, hopefully it'll be released today and i'll be able to finish that bump

nox: github.com/rust-lang-nursery/rustfm…r/Configurations.md#fn_args_density maybe

auscompgeek: We don't set it.

yeah, I can see the confusion

auscompgeek: Our only conf is: match_block_trailing_comma = true / binop_separator = "Back" / reorder_imports = true

jdm: My PR is ready to be reviewed.

k

I'll do the actual useful bits after lunch.

eijebong: you should be able to publish rust-webvr now

jdm: Yay ! \o/

nox: ^

jdm: Published, perfect !

nox: Just making sure it builds and then I'll open my PR. You might not have to dupe anything :p

standups: Tracking down Magic Leap release build crash at startup.

standups: reviewing background hang monitor PR.

Debugging an application without a debugger what fun.

ajeffrey: Wait, you don't have access to println ?

eijebong: :)

ajeffrey: what about MagicLeap/mlsdk/v0.17.0/tools/mldb and MagicLeap/mlsdk/v0.17.0/debug ?

jdm: they need the .exe to have debug symbols.

huh

so I'd need to fight mabu for a release build but with debug symbols.

mldb log works, which would help if there was a panic that Rust could log, but isn't much use if it's the C++ app that's SEGVing.

docs.rs/codemap-diagnostic/0.1.0/codemap_diagnostic is now a thing, I kinda wish we had a WebIDL parser using that :3

crates.io/crates/codemap-diagnostic rather

jdm: About the image update, should I mark is as a failure and open an issue ?

eijebong: yeah, I don't really see any other useful outcome

jdm: OK, trying to debug the release build crash, like you said it does't crash using a debug build of the ML app but a release build of Servo.

Even passing -O3 in!

fascinating

jdm: weird isn't it?

I wonder if there's some sandbox the ML puts debug apps in?

Oh, also the ML app without initializing servo doesn't crash.

that's a useful data point

ajeffrey: have you tried a release lumin build with a debug servo?

just to explore the full problem space ;)

jdm: on it...

jdm: got confirmation from magicleap that we can't control native UI elements using the laser pointer. Apparently this is on the road map though.

grumble

ajeffrey: sounds like it's time to build our UI in html >:D

jdm: what a great idea, we could call it something like "browser.html" :)

boot2magicleap

:)

standups: strategic planning writeup.

with leapsona login

jdm: a release ML app with a debug Servo works :/

so only release+release is broken

so weird

ajeffrey: can you force the lumin release build to have debug symbols with -g?

and then maybe use the debugger?

jdm: the debugger won't launch a release ML app, even if it's built with -g, sigh.

mmm

jdm: Next up... seeing if I can find out which C++ flags are being passed into clang for a release build vs a debug build.

ajeffrey: what if you add ml:debuggable="true" to the <application> in Servo2D/manifest.xml?

jdm: I'll give it a whirl...

jdm: looking at the manifest for the debug application, there doesn't seem to be a debuggable flag...

ajeffrey: right, but I am suggesting adding it

since that is what android tools do under the hood

jdm|f00ding: OK, I'll give it a shot.

jdm|f00ding: Adding the debuggable flag gives an error, presumably on XML schema validation...

bah

OK, the commands run by mabu in release mode are...

and in debug mode are...

Somewhere in that mess of clang command line args is a SEGV :/

The link command has -g in debug mode, which may be what's causing us not to be able to use the debugger on the release build?

Typically, passing -g in release mode should give indeed give you debug symbols, modulo they are totally wrong where optimizations do wonky things the symbolic info can't handle (e.g., expression-level inlining)

Oh look what I found...

mabu: setting tail data: /Users/ajeffrey/MagicLeap/mlsdk/v0.17.0/tools/python3/bin/python3.5 /Users/ajeffrey/MagicLeap/mlsdk/v0.17.0/tools/mabu/src/taildata_v3.py --sbox USER --debuggable --devcert /Users/ajeffrey/MagicLeap/TempSharedCert/TempSharedCert.cert /Users/ajeffrey/github/asajeffrey/servo/target/aarch64-linux-android/debug/Servo2D.mpk

A python script that "sets tail data" called with a --debuggable flag for debug builds.

ajeffrey: oh, fascinating

jdm: looks like an .mpk isn't just a zip file, it's a zip file with some taildata at the end, for things like the signature.

sounds like firefox's omnijars

oh no not those

i think you can still construct omnijars if you use a sufficiently modern zip program with like 5 flags

Well at least I now know how the debugger is distinguishing a debuggable app from a non-debuggable one.

Oh great, and building a release build, but editing the taildata_v3.py script with is_debuggable=1 causes the crash to go away.

wat

OK, mabu really really really doesn't want me using this flag...

and indeed it doesn't show up in mabu --help, but...

mabu -o target/aarch64-linux-android/release -t lumin_release support/magicleap/Servo2D/Servo2D.package -s /Users/ajeffrey/MagicLeap/TempSharedCert/TempSharedCert.cert -v --add-tail-data-args=--debuggable

generates a release Servo app that doesn't SEGV.

horrifying

also, nothing like reviewing code that uses static mut, atomic booleans, and signal handlers on a friday afternoon

i keep on thinking whether it's a good idea to implement an executor on all our event loops, specifically the script thread

no wait, that's probably the wrong word

what i really want is to have the script thread run futures

because currently we don't really have a good way to compose tasks that are supposed to run one after another

right

currently we have manual task! within task! things

and for anything that needs to wait on a response from another thread, the code ends up living in separate places in response to events that are received

i bumped into this while i was trying to implement module scripts last week

i guess when futures stabilize, we can start talking about implementation plans

standups: Working around startup crash in release builds of Magic Leap Servo. servo/servo #22210

jdm: Should ^ close #22188, or should we leave it open till we find a less sticky-tape-and-string solution?

ajeffrey: might be worth posting to the ML forums about your discoveries

jdm: indeed.

ajeffrey: let's keep it open for now

jdm: ok

uh oh

why are my builders inactive

sigh, everything's ready to merge but no merge

jdm: do we gate on status-taskcluster?

Manishearth: yes

standups: Working on unsafe code guidelines. rust-rfcs/unsafe-code-guidelines #16