tdelacour: so the resource is the Request

or mmm, possibly the Response here

yeah, that will be the response

tdelacour: no, we don't have direct access to any window or documents in this code. however, requests do have an origin field which is what we can compare against

as it happens, it's the type declaration that's wrong, the uses are all consistent, and they're all void* anyway.

tdelacour: additionally the "fetch redirection chain" is the same as doc.servo.org/net_traits/request/st…t.Request.html#structfield.url_list if i'm not mistaken

jdm: ok makes sense

ajeffrey: awkward!

typedefs, not even once

jdm: have to bail on the wifi for a bit rn but will take a look at these later & see if I can get started! tyvm

thanks for looking into it :)

Okay I do not understand this...

I'm calling egl::egl::MakeCurrent(dpy=0x1, draw=0x400013b56100, read=0x400013b56100, ctx=0x4000138550e0)

but then on the same thread, with no itervening call to eglmakeCurrent

native_context is 0xaaaac4529c74

I iz confuzzled

Oh noes...

the caller args are not the same as the callee params.

this is not going to make for fun debugging :(

standups: The horror the horror. (In this case trying to debug mystery errors creating an EGL context).

wow

Task "Servo daily: macOS x64: WPT update. On failure, ping: SimonSapin, nox, emilio" complete with status 'failed'. Inspect: tools.taskcluster.net/tasks/HNFnLpQ_Tem6dh_eMWfLyA

SimonSapin: does servo/servo #23361 make sense to you?

jdm: looking. The first exception is expected github.com/servo/servo/blob/b1b47d8…etc/taskcluster/decisionlib.py#L266

… but I don’t understand how we could get the second stack "during handling the above exception"

since the `except` block I linked is apparently not on the stack

SimonSapin: yeah, the first stack just ends in the middle of decisionlib which is weird

but I don't understand how there's a taskcluster client in play that doesn't have the right scope

but if we ignore that, you’re trying to start a nightly task from a github push

oh, so normal github push tasks don't use clients that have secret access?

on github pushes, the taskcluster-github service reads .taskcluster.yml and creates tasks with scopes from the corresponding "branch" role: tools.taskcluster.net/auth/roles/re…ub.com%2Fservo%2Fservo%3Abranch%3A*

which is separate from a hook’s role: tools.taskcluster.net/auth/roles/hook-id%3Aproject-servo%2Fdaily

aha

jdm: we can always add more scopes to the branch role, but to test daily tasks I’d prefer to use change GIT_REF and use the Trigger button on tools.taskcluster.net/hooks/project-servo/daily

yep, makes sense

so that we also test that the hook has sufficent scopes

“CSS 2 does not define when a UA may put said element next to the float or by how much said element may become narrower.”

fun times

nice

nox: god i hate the attitude of rfc/internals randos

Gankro: lol

Gankro: I almost wrote a longer comment but decided to keep it short.

jdm: hi, I think I'm done with servo/servo #23322 but you might want to take a look before merging.

Gankro: I don't even understand what they mean by "separate enums" tbh

s/separate/different/

jdm: and regarding servo/servo #22957 is there anything I can read to understand the underlying process? I'm not yet familiar with gl rendering and stuff.

nox: i think maybe they want you to use the same enum for everything which is,,, not

jdm: (besides the code)

Gankro: Oh, "C-like enum of all properties" * "enum of all the possible values"?

pylbrecht: reasonable question. I don't necessarily have any resources for you, but I do have an alternate opportunity which is very similar but doesn't involve anything GL related.

pylbrecht: I just learned about github.com/jrmuizel/raqote yesterday, which theoretically should be possible to just drop in instead of the current use of azure

it's a fully-rust 2d graphics software rendering library

jdm: so I only have to replace the azure code? I remember it being only in one file so far

that would allow us to stop relying on rust-azure and skia entirely

yeah

jdm: that sounds like a more welcomed solution to my problem

:)

I'm spending way too much time on that python urllib3 issue...

It's possible that I did something wrong when installing python and/or virtualenv. But I reinstalled, clobbered, deleted cached directories, with no luck

help?

I initially made a mistake, where I tried to run mach from a msys2 shell. I'm wondering if this could have installed a bad package somewhere. But I think I deleted most of the cached directories.

yuck

paul: my next suggestion would be to make a local clone of mozjs, check out the right revision, and see if you can build that

ok

paul: I've definitely run into things like that when either python3 or the msys python were in the PATH, as some of the build tools seem to grab whatever python.exe they happen to find in the moment. I have also burned wayyyyy too much time on python-related issues with Windows setup.

I did just provision a brand new Windows box from scratch (this week!) and built servo on windows cleanly.

larsberg: yes. I'm 99% sure this is what's happening. I installed msys2, and might have polluted my python packages somehow

I ran the C++ desktop app setup (github.com/microsoft/windows-dev-box-setup-scripts ) then installed the stuff per the servo/servo instructions. I did have to remove python3 from the PATH, as it was installed by that setup script

larsberg: I'm building from a clean `cmd` now, but having a hard time to get back to a clean state

I did not install msys2/cygwin, as that can be a bit of a nightmare to fully isolate (though I *did* do it once...)

larsberg: what shell do you use now on Windows?

paul: just cmd.exe

larsberg: old skule

on my other windows laptop I use msys2 with a special tmux tab that strips all the non-windows path from PATH. This always worked. Until this week...

ajeffrey: I'm 👀 for that new windows terminal they announced at build...

paul: I use conemu when I want something fancier than cmd

I'm gonna settle for cmd for building, and msys2 for vim/tmux/git

I love how over the top this is: youtube.com/watch?v=8gw0rXPMMPE

Meanwhile, the issue I was having ^ with gdb showing that caller arguments != callee params turns out to be an issue with gdb printing, not with the ABI/calling convention.

Yay, I guess.

Back to printf debugging :/

paul: I totally agree! I thought we went a bit overboard with the firefox reality "commercial" but that terminal short was incredible

ajeffrey: yikes

love to not trust my tools

jdm: yay for printf!

ajeffrey: gdb! is the new printf fyi

dbg* ugh

nox: Does dbg! work with non Debug types ?

eijebong: Don't think so.

:/

eijebong: But those are bad types anyway.

It would be nice if it could gen some implementations when used

nox: on magicleap, stdout is /dev/null, so it's actually info! rather than printf!

ajeffrey: not anymore. I landed a commit that redirected stdout to logcat iirc

yep, in servo/servo #23300

jdm: oh that's right, yay I can use printf! again!

standups: lots of taskcluster migration work; standardizing android build on llvm toolchain.

standups: provisioned servo-tc-mac4 and managed CI queue.

Hey. I am seeing if I'm up to taking on the CSS3 extensions to `attr()` (servo/servo #22265), but I can’t get the `attr()` function to work at all. It looks like it is behind a `gecko` feature flag. How do I turn on that feature flag? Whenever I do `./mach build -d --features gecko` I get and error stating there is no such feature.

runarberg: where's the feature flag use?

jdm: I saw it [here](github.com/servo/servo/blob/master/…lues/generics/counters.rs#L214-L215)

btw, I'm a new (potential) contributor ;)

runarberg: I think the most useful thing to do here is file an issue with a testcase with attr() that doesn't work, and I'll CC some people who should be able to provide some pointers to get started

attr looks complex enough that I'm getting lost trying to figure out how it would fit in

runarberg: unless #22265 actually covers the feature entirely that we're talking about

jdm: So not a good first issue :D #22265 is actually just about the extension to the function (that is adding the optional `type` and fallback; i.e. `background-color: attr(data-background color, rebeccapurple)`)

jdm: But if I can create a test with the original syntax that fails, I’ll create an issue regarding that.

yeah, that would be great :)

thanks +1

jdm: I tried deleting the file but it leads to crashing of one more test case

maharsh312: sure, but it's the actual output that appears in the terminal that's interesting

jdm: yes the output in the terminal is something weird

jdm: Is this command right to run test gist.github.com/maharsh312/24fb41ea20678dbf582f3aecf44821e2

maharsh312: only `mach.bat test-wpt tests\wpt\web-platform-tests\offscreen-canvas` should be necessary now

maharsh312: it's probably easiest to run only the single test that's crashing, though

jdm: the above command does not work in windows

maharsh312: what is the output?

maharsh312: oh, you are probably still using a revision that is older than servo/servo #23174

maharsh312: if you rebase on top of a recent master it should work

(after rebuilding, of course0

jdm: Okay I will try that

anyways, if you keep using your current command line that works, that should also be fine

so close to being able to turn on two more tc mac builders

sevo-mac7 is next in line for being paved over

taking 70 minutes to build servo is not acceptable

ah good, it had a rogue test process spinning

jdm: which single test would give me an idea about the crash?

maharsh312: the one that I commented on in the review

woooo

jdm: It passes after I delete the .ini file

maharsh312: that seems like a nice improvement

jdm: So what's the next step?

maharsh312: update the test results with the new expected behaviour and see if any are still crashing

jdm: how is this? servo/servo #23365

there was already a failing wpt-test that I just pointed out in the issue

jdm: For all of the test right? (Using servo.log)

maharsh312: yes

runarberg: great, thanks!

jdm: Tests are still crashing. I ran the offscreen-canvas test and updated it using update-wpt

maharsh312: what does crashing mean, in this case?

the output from a single test that is crashing is the interesting bit

jdm: gist.github.com/maharsh312/9e1f46d0071996474cad6856f3e54010

jdm: yes, as it said test passed and one unexpected result

I recommend finding a single test that is crashing, removing its ini file, and getting the output from running it

jdm: gist.github.com/maharsh312/1f3bda20ed9552cfd05aa01aa0f67d93 I did this for the file you specified

jdm: Running the test opens a servo window saying test passed

maharsh312: sure, and you said that that test passes. since other tests are crashing, I'm saying that you should find one of those tests and look at its output.

jdm: Okay!

jdm: Did it with 2d.transformation.setTransform.nonfinite.html. Error Log: gist.github.com/maharsh312/4c0009406553e04a02038a82830af67d

maharsh312: that doesn't look like a crash to me

that would be an expected failure because you haven't implemented the setTransform API

jdm: Yes

jdm: But it was crashing before I deleted the ini file

that doesn't make sense to me :)

the ini file won't change the behaviour of the test

all it does is allow the testrunner to decide if the behaviour is expected or not

jdm: I'll check it once again

jdm: I did it with offscreen-canvas/compositing/2d.composite.canvas.lighter.html and there is no output. Servo windows opens and closes by itself.

jdm: I checked the ini file before deleting it. It was expected to be crashed

maharsh312: what's the output when you run offscreen-canvas/compositing/2d.composite.canvas.lighter.html without an ini file?

jdm:https://gist.github.com/maharsh312/e0ee50a5dbe23ac4ac65493b9bc3da87

maharsh312: hmm. what if you run two tests in the same mach command, like 2d.transformation.setTransform.nonfinite.html and 2d.composite.canvas.lighter.html?

Grr, been banging my head all morning about magicleap failing to create a shared EGL context.

Calling eglCreateContext results in error code EGL_BAD_CONTEXT.

AFAICT if I call eglCreateContext in the main thread, then all is well, but over in the webGL thread it fails.

jdm: gist.github.com/maharsh312/02600f583d86cda36197411356dcfe6c

aha, now we're talking!

I mean, that's a super weird error but the crashes make sense now!

maharsh312: did you end up rebasing and rebuilding? if so, you could try adding `--binary-arg=--angle` to the command.

jdm: I did rebase and I will rebuild

jdm: "--binary-arg=--angle" this command should be used during build?

maharsh312: no, when running the tests

jdm: I will build and run the command

Manishearth: I see that you deleted a ton of old branches recently

emilio: any clues why I might be getting EGL_BAD_CONTEXT from eglCreateContext in offscreen_gl_context?

ajeffrey: stackoverflow.com/questions/3973241…-between-opengl-contexts-on-android mentions "EGL_BAD_CONTEXT is generated if share_context is not an EGL rendering context of the same client API type as the newly created context and is not EGL_NO_CONTEXT."

jdm: yeah, but they're both created with EGL_CONTEXT_CLIENT_VERSION 3 :/

mmm

standups: submitted ethics paper to arxiv

the config and attribs are the same

ajeffrey: you might see if anybody in #gfx is familiar with EGL pitfalls?

jdm: will do

Looks like this might be a threading issue? If I create the shared context on the main thread it's fine, it just fails if I create the shared context in the web GL thread.

jdm: the webgl thread is also the thread which processes a lot of webvr, getting rid of it will be painful.

indeed

I'm assuming that creating a context on one thread means it can't be used on another thread

jdm: this works in landscape mode, which is what confuses me :/

if that's not the case, that would be a pleasant surprise

jdm: my understanding is that EGL contexts have thread affinity.

I could be wrong of course :/

standups: Fighting eglCreateContext.

jdm: oh did i break something?

i was deleting my branches

tried to make sure i didnt delete anything important

Manishearth: no, it just makes the output of the github closed PRs sorted by date updated confusing

oh lol

whoops

because stuff that merged in the past 2 weeks is intermixed with stuff that merged in 201t6

as it should be

huh, github package registry

yeah, watching that too. only saw the `npm` replacement example but... 🤔

no rust/cargo... yet

jdm: I ran the two test again using command you provided. gist.github.com/maharsh312/e3dd045ae26ec8c3d94949acf2a976e2

maharsh312: what was the full command?

"./mach.bat test-wpt tests\wpt\web-platform-tests\offscreen-canvas\transformations\2d.transf

ormation.setTransform.nonfinite.html tests\wpt\web-platform-tests\offscreen-canvas\compositing\2d.composite.canvas.lighter.html --binar

y-arg=--angle"

oh, hmm, I see why this happens on windows

jdm: gist.github.com/maharsh312/a44cc86200b3e596b4aabce0233f3e13

maharsh312: what happens if you comment out github.com/servo/servo/blob/b13f7ab…glutin/headless_window.rs#L111-L115 and rebuild?

it should be a much quicker build this time

jdm: I'll try

maharsh312: ok, so the bad news here is that it is impossible to run more than one test at a time on windows in servo's current setup, and I don't see that changing in the short term.

maharsh312: so we can make use of CI to run the tests, then download the logs and update the expected results from that. or you can use a linux environment for your work, possibly in a virtual machine.

jdm: I'll try to use linux once again in another laptop. If its not possible I'll try the CI option

standups: Formulated a plan with nical for images, gradients, and clips in Pathfinder.

standups: Unsafe code guidelines work

ajeffrey: immersive-web/webxr #636 btw

this seems to be more your wheelhouse than mine

comments greatly appreciated

Manishearth: interesting...

standups: look at XR test stuff

standups: some XR spec work

standups: read through rust-webvr backend APIs

standups: review servo/media #260