I find the types useful most of the time, for avoiding stupid wrong-coordinate-space errors, but I can imagine cases like getPose where they'd be annoying.

ajeffrey: the problem is they're too specific

we need ways to downcast them to the right specificity

i have a hack

i can't *store* generic types

it's all runtime

eg. i have no way of generically working with doc.servo.org/webxr_api/enum.Views.html while keeping the runtime view information

Manishearth: yes, we might end up having to sprinkle functions around which forgets type information, and if we end up using those everywhere then we may as well not have bothered.

ajeffrey: origin offsets mess this up really badly, too, since it's a kinda sharp corner of the API that relates the native and effective origin

which is just confusing

like, i'm able to even introduce the concept of a viewer space but the origin offset messes with it

ajeffrey: take a look at the last WIP commit in my PR

ugh nope

ajeffrey: can we just get rid of the types completely and add them back in later?

this is becoming way too much

i thought i'd be able to reduce it to a smaller number of spaces but it doesn't work that way either

Manishearth: looking...

ajeffrey: alternatively, some helpers making it easy to cast

idk

like, i kinda want the native/api distinction

i think for now this hack is good enough

lets me make progress

Manishearth: should we just use untyped Euclid where you're using ApiSpace?

ajeffrey: we could

for now i'm not

in case i want to introduce more distinctions

e.g. Viewer would be an okay space to reintroduce *except* originoffset exists

i might end up doing that

for now i'm going to use a separate space so i can change things easily

i think i have a way to make use of Viewer

for this we need euclid to provide easy casting

basically if i model originOffset as a native to native transform it can work

ajeffrey: oh, also, all the f32s should be f64. we should change this later

actually maybe not

Hmm, is it worth introducing a space Custom for cases where the user has specified an originOffset?

so the originOffset would be a native-to-custom transform?

could be

(name not great though)

the distinction is almost zero though

origin offsets show up in one place, it's not worth having that

would allow keeping track of which APIs were in native coords, and which were in native-after-applying-offset.

I used f32s just because that's what rust-webvr had.

hmm

okay

also we might be able to SIMD the f32 versions if we ever wanted to use PF's geometry.

i think DOMPoint uses f64 but we don't have to

but I don't have a strong opinion.

close to having it compiling

yep i think i should be able to reintroduce Viewer

it compiles, except for input

ajeffrey: are you working on mocking? 'cos I can piggyback input on that

eh, might as well add it to my fork for now

without mocking

Manishearth: I think that's going to be tomorrow's job.

ajeffrey: sounds good

i will do input stuff tomorrow

ajeffrey: my PR is not landable yet, but ready for review. i may have a better solution for the origin offset stuff

standups: hook webxr crate into script: servo/servo #23731

also i need to actually test this lol

but i can't on my laptop

Manishearth: welcome to my world

I've been working on webxr without being able to test it, gulp.

hey, at least glwindow works for you!

i can't test anything webxry on my machine because servo can't use webgl bc wayland

i should look into ixing that

fixing

ajeffrey: also probably should start reviewing . we can't land till input and mocking is sorted, but the stuff so far is self contained

Manishearth: okay if that's another job for tomorrow?

ajeffrey: oh of course

Manishearth: np

i'm not asking you to do anything today lol

to be clear

yay for it being 9 at night :)

just trying to understand your priorities for tomorrow and the rest of the week so i can plan accordingly

okay there's not much benefit to separating out the viewer pose

er, viewer space

ajeffrey: View.transform should probably be inverted

the transfrom from viewer space to eye space isn't as useful as the pose of the eye space in viewer space (there are opposite)

hmm, got it working

it also found a bug, i think

yep

Manishearth: not too surprised, that's what happens when code can't be tested!

Task "Servo daily: Linux x64: with Rust Nightly. On failure, ping: SimonSapin, nox, emilio" complete with status 'failed'. Inspect: tools.taskcluster.net/tasks/CR15913nTVKXLOekQs4qLQ

crowbot: explain webxr

holy crap

that's almost a real diagram

standups: rust-lang/rust #62528 Add joining slices of slices with a slice separator, not just a single item

wow the webxr diagram is so cool!

oh *that*'s what webxr is!

standups: rust-lang/rust #62530 Account for coercions in trait resolution?

jdm: around 👀?

crowbot: yep!

ha!

jdm: I'd like to ask, I'm trying to figure out how to load cyclic module records and I saw Gecko did it after loading top level module at searchfox.org/mozilla-central/sourc…m/script/ScriptLoader.cpp#1271-1274. what do you think the equivalent behavior in Servo? 🤔 Should I do it inside `process_response_eof`?

cybai: if you stored some kind of handle in the module map for pending requests, then process_response_eof could resolve all of them

jdm: could you elaborate more? 🙋‍♂️ do you mean saving kind of functions in the module map and execute them in process_response_eof? I think fetching descendants should be executed before doing those like `document.asap_script_loaded`

cybai: I mean storing _something_ which will end up triggering the appropriate promise job for each duplicate request. maybe that means storing Promise values?

cybai: so ModuleObject::Fetching could be something like ModuleObject::Fetching(Vec<Rc<Promise>>)

cybai: oh, I guess it's a bit different than what I imagined when I look at fetch_single_module_script

jdm: hmm, yeah 🤔 because we must do the first fetch and see the module record if it includes any other modules, maybe we can't store something like ModuleObject::Fetching(Vec<Rc<Promise>>) 👀?

Oh that's new to me, github supports draft PRs? irccloud.mozilla.com/file/c9sq56FW/…%20from%202019-07-09%2008-54-58.png

cybai: the goal here is that ModuleObject::Fetching stores whatever is necessary to notify any cyclic requests that are waiting on a result

TIL about github.blog/2019-02-14-introducing-draft-pull-requests

jdm: oh!! I see! I think I got your point. Let me think about how to do it! Thanks!

:)

standups: looking into supporting debugmozjs on windows.

cybai: btw 👍 on the recent playground PR (and all the ones before that 👀) :D

lqd: ha, that's an easy one I can do during busy time 👀

thanks!

:)

amazing, a month since the webrender upgrade started and there have been no breaking changes in the webrender APIs

jdm: Nice

How is the upgrade going ?

eijebong: waiting on a WPT sync to finish merging and the PR I just opened to be merged upstream

otherwise ready to go

Nice

I wonder how much work it would be to introduce serializable tasks to script?

github.com/servo/servo/blob/56f1e7c…b4f47/components/script/task.rs#L42 has TaskBox: Send

with typetag we could have a TaskBox that is serializable too.

that would allow us to avoid using ROUTER, and save on context switches.

fun fact: if you have a rust-lang/rust clone that you last pushed to in 2012 and there have been ~84k commits since, the git push operation is pretty slow

only required pushing 351mb upstream, however

standups: created PRs for rustc and libc to support debugmozjs on windows.

ajeffrey: i considered doig this, it's a lot of work to get correctly

serializing tasks is not the problem, serializing DOM objects is

i think the right solution is to have a registry of Any objects in a hashmap somewhere (address-keyed because why not)

and the ability to create a ScriptPinger<T> that internally contains a ScriptThreadSender, but can only send messages of type T (cast to ScriptThreadMsg::Custom(Box<T as Any>)

and when you receive it it does all the downcasting

and creates a task

the hashmap registry thing also contains task sources and cancellers

Manishearth: yeah, something like that, plus some checks that you're back at the originating process, in the same way as Trusted checks you're back at the originating thread.

quite a bit of hoop-jumping to avoid a context switch, probably not worth doing right away.

yeah

ajeffrey: well.

ajeffrey: no need for those checks, this is literally in the script thread

like, only script can receive these

yes

i sketched a rough design and then decided that i didn't want to open that can of yak shaves

i can write out the design if you want

Manishearth: there's more than one content process though, and addresses aren't unique across processes.

ajeffrey: i don't see why that's a problem

you're handing out IPC senders to the content process itself

not some new kind of sender

(is that safe?)

ajeffrey: also yeah i def want oneshot tasks in the api

Manishearth: ah, that would work, if the IPC sender is bundled with a payload that is guaranteed to be run by that script thread.

it was part of my Plan

ajeffrey: yep.

well, more like this

fn create_task_callback<T>(FnOnce(T), TaskSource) -> ScriptPinger<T>

ScriptPinger<T> has a function send(T)

ScriptPinger<T> is {IpcSender<ScriptThreadMsg>, id: usize}, and send(T) does self.sender.send(ScripTTHreadMsg::Custom(Box::new(T) as Box<Any>))

does my terrible pseudocode make sense?

ajeffrey: where's to_untyped?

Manishearth: docs.rs/euclid/0.19.9/euclid/struct…dTransform3D.html#method.to_untyped

turns out rigid transforms don't have it though :(

ajeffrey: i'm not on typedtransform

yep

and i can't add it without also adding one to TypedRotation

it's ugly

Manishearth: oh, and TypedTranslation only has one type argument, not two?

euclid treats spaces that only disagree in their origin as being the same.

*TypedVector

ajeffrey: yep

Manishearth: sigh

i think typed units are good provided there are easy ways to cast

so euclid's types won't catch errors like originOffset.

originOffset is a full transform

i feel like a .cast_src() and .cast_dst() and then .cast() would make this easy to work with

Manishearth: yes, you need some way to switch off the type system when needed.

typed units are good, but really there's no way to do it perfectly (Vectors are a great example of this) since there will *always* be a confusion between "transformation in a space" and "transformation between spaces"

and often they're interchangeable

furthermore the order flips when you're talking about transformations as origins (as in, position, orientation pairs)

this stuff plagued the webxr spec

and led to frequent confusions, till i pointed it out

in physics we use covariance and contravariance to talk about this, but that's only in tensor math

> furthermore the order flips when you're talking about transformations as origins

i.e. you have two ways of talking about a transform

"the transformation that you apply to coordinates in base space to get coordinates in viewer space"

and

Manishearth: yeah, I can imagine the cries of anguish if we start putting too much algebra in the euclid types.

"the transformation you apply to the *coordinate grid* of base space to get the *coordinate grid* of viewer sace"

these are inverses

the problem is that both use the from/to language

so it's confusing

basis-change transformations (i.e. things which transform coordinate grids) are covariant

er

sorry, the opposte

Manishearth: somewhat off-topic, but have you read bentnib.org/conservation-laws.html ?

things which transform coordinates are covariant, whereas things which transform coordinate spaces are contravariant

it's what happens if you really push on putting algebra into the types for linear algebra.

ajeffrey: i've seen it, because i had the same rough idea once :)

noether's theorem is a mathematical result so at some point i realized you could apply it to programming

Manishearth: :)

didn't know enough about type theory to actually *do* that, but i did google it and find the paper

Manishearth: we could implement the cast on rigid transforms by pulling them apart then putting them back together again,

and hoping that the compiler is smart enough to realize it's just an identity function.

yep

rotations don't have cast either iirc

nope

Manishearth: yes, we'd need to do something like Rotation::new(rot.i, rot.j, rot.k, rot.r) sigh.

yep

Manishearth: for the mocking api... would you rather have something that looks like rust-webvr/mock or like github.com/immersive-web/webxr-test-api ?

ajeffrey: rust-webvr/mock is webxr-test-api

i wrote both

yeah, just copy over rust-webvr/mock

ajeffrey: we already have the DOM apis for mocking

Manishearth: ok

i'll note down my planned design for the ipc thingy

ajeffrey: github.com/servo/mozjs/compare/windebug?expand=1 !!!

er, more excitingly: ci.appveyor.com/project/jdm/mozjs/builds/25855239

jdm: a+ commit names

standups: read through the code and docs in the skribo repository, rebased and merged open PRs

hmmm, looks like the script event loop doesn't listen to IPC?

ajeffrey: ^ looks like the script thread currently doesn't have any way to receive messages over IPC without a context switch

it uses a router for constellation

yeah, we can't select over ipc and non-ipc without a router

in that case idk how much this matters

we can still reduce the number of channels in the ipc router though

jdm: oooh, debugmozjs on windows

Manishearth: yes, select is only on intra-process channels, not IPC so the only way to listen to multiple channels some of which are IPC is to use ROUTER.

Sigh.

is it still worth investigating if we have to router anyway?

not atm at least,

cool

I think it would take a pretty radical overhaul of how servo does IPC.

okay

Trying to make servo use less threads is a bit of a losing battle.

Oh well, at least we're not spawning one thread per mouse event any more.

lol

omar: github.com/servo/servo/blob/18477d1…e6663320897/ports/glutin/app.rs#L54

ajeffrey: there?

gonna grab lunch soon and also set up a dentist appointment, but how would you think an events api would look?

to do input *properly*, we need to listen for input devices being connected

Manishearth: should input devices be independent of displays?

or are they tightly coupled?

it's probably easier if they're independent, that way we can just have the registry handle them.

ajeffrey: in webxr? coupled

in webvr? independent

er

so XRInputSources are coupled

they contain gamepads, which can exist without a session

for now i was going to make this only handle input devices connected to the session

Manishearth: can we assume each input device knows which output device it

's associated with?

as in?

If you connect an oculus gamepad, it knows to register itself with the oculus device.

backend's responsibility imo

hmm, so when a gamepad is connected, we iterate through all the Discovery objects finding one that knows how to handle it?

no, i mean that the device backend knows how to detect a gamepad is connected

there's no generic "a gamepad was connected" api the system gives us

what if two back ends recognize the device?

"oops"

:)

we need a good solution for this eventually, i don't think we should now though

you only have one sessio nat a time though

so that session is the one that detects devices

inline is complicated

inline shouldn't have input sources aside from screenspace input i guess

wait no it can

Manishearth: yes, every time I see that I think "that's something that's going to change"

e.g. two-player games with two HMDs attached to the same host.

ajeffrey: alternatively for now i can build it on the assumption that input sources are set on creation

which is what rust-webvr did

and we can transition this in a followup

(all our backends do this anyway)

wait we need to listen for events anyway though

hm

ajeffrey: i'll just make it an event

actually no

i also need to set inputs on creation anyway

uh, i'll do the event thing later

this shouldn't be so bad, since we're running an rAF loop anyway, we don't have to worry about a waker API, polling is fine.

yeah so the actual input state gets sent in the raf loop

Manishearth: dumb naming question... Mock* vs Fake*

opinions about which naming scheme webxr should use?

Fock

Feck

(for all you Father Ted fans out there)

Peck, for the Willow fans out there

ajeffrey: Mock

no strong opinion

the api doesn't mirror the test api, it provides the underlying things necessary to do so

Manishearth: neither have I, hence the question :)

standups: wrote gsoc blog post: georgeroman.github.io/posts/2019-07-09-gsoc-servo-weeks-5-and-6.html

georgeroman++

georgeroman: also some feedback on reddit.com/r/servo/comments/c1r6ce/gsoc_with_servo_week_3

jdm: That's really cool, thanks!

ajeffrey: so what i think ill do is for now on initialization give information on what input sources exist and let the session request input info on each frame

or, eh, i can just send it unconditionally for now

Manishearth: so the SessionThread will poll the Device?

I just wanna thank everyone for naming threads in Servo. It's super useful!

> 0:02.73 pid:22786 thread_id not initialized (thread WRRenderBackend#0, at src/libcore/option.rs:1034)

<3

Manishearth: current state of the mock API... asajeffrey/webxr 06ee9b0

omar: :D

standups: Working on a mock API for webxr testing.

standups: removing non-UWP-safe gstreamer plugins from UWP app.

standups: work on GetElementProperty wd command