emilio: Lol I forgot about transition events.

nox: yeah, the web rocks :)

emilio: But doesn’t that happen after layout?

nox: sure, but before returning to the script caller

To run the JS you need to be back on the script thread so why would layout still be keeping a reference?

nox: layout would not keep a reference. the thing I want to assert against is { let _ = self.member.borrow(); update_layout(); } ...

nox: maybe layout is not the place for that assertion

nox: but generally keeping _any_ borrow before running arbitrary script is a panic waiting to happen

Yeah I don’t think that’s the right place, I could imagine somewhere some code borrowing stuff and then making a query to layout, and that’s a panic so that fine.

nox: yeah, though borrow_state allows you to assert against that (maybe not during layout), while try_borrow_unguarded doesn't

I don’t completely exclude that we will need a different abstraction later but I understand the sentiment of upstream not wanting general hard-to-explain-the-use methods.

emilio: I’m not sure where you would call borrow_state, and what would that accomplish compared to panicking after layout.

It would just panic where you called borrow_state instead right?

nox: that's fair, I just think that it'd be a useful thing to be able to assert against. I don't think that use-case is too far-fetched, asserting that `borrow_state()` is `Unborrowed` (or whatever the name is) before calling arbitrary code

nox: yeah, but it'll catch the bug earlier (any time you make the mistake), vs. only with some very crafted user inputs

Ah but we can’t do that, remember that the ref cells are all over the place.

nox: yeah, it was an example :)

Gotcha

nox: but anyhow try_borrow_unguarded does the job and is much better than the status quo (and has a stronger justification, "preventing UB" vs. "catching bugs earlier")

Yeah I’m thrilled about it, it’s like some unsafe “beyond Sync” API.

I wanted to see where all the layout traits from script are called in layout_thread today, so I marked them all as deprecated and it worked like a charm hah.

oh, cool

life hack

pcwalton/font-kit #37 <- my current plans to deal with locale stuff

Open to other ideas, and this is one of those areas where I wish there was someone smarter than me who would tell me what to do, but am ok trying to be that person

Also text people please re-review linebender/skribo #2 , I added more stuff

Manishearth: around? 👀

has anyone built the pathfinder 3 demo on windows successfully?

"error LNK2019: unresolved external symbol __imp_SHCreateItemFromParsingName referenced in function..."

cybai: now yes

Manishearth: want to ask a question about #23015

Not sure why I'm also on macOS 10.14.3 with gstreamer 1.14.4, would you think it's related to this line github.com/servo/servo/blob/34fda66…2/python/servo/bootstrap.py#L48-L50 ?

Not familiar with Python subprocess.call, but I try to ran that small script and I get "0"

but if I ran command with `pkg-config "gstreamer-1.0 >= 1.12"`, it won't work 🤔

pcwalton: I'm trying to help bzm3r get started, and I'm having much more basic errors, a ton of "incorrect close delimiters" in simd/src/scalar.rs. The code looks obviously wrong. I'm in the pf3 branch of pcwalton/pathfinder, what am I missing?

I'm guessing there are two problems, this code is wrong, but I should also be compiling this to not use the fallback code.

raph ah yeah, i fixed those errors by using the editor's replace functionality; you'll also have to disable jemalloc

i can put up the changes i made on github, give me a moment

I've worked around both problems myself :)

raph sweet, were you also able to set up SDL2?

No, still stuck on that. The instructions seem pretty rough. It works fine on mac though.

Ok yes it works for me.

I copied SDL2.dll (from SDL2-devel-2.0.9-VC) into demo/native/

I don't think I needed to do anything with the .lib files, the .dll seems enough

it's not hidpi though; on mac it is

raph let me try skipping the *.lib files too

raph yeah, it seems i definitely need the lib files: `LINK : fatal error LNK1181: cannot open input file 'SDL2.lib'`

are you sure you don't already have them under `multirust/toolchain/stable.../lib/rustlib/x86_64.../lib`?

yeah, definitely not there

that's so weird

(that you aren't getting the *.lib error)

it may have found it because I was setting the LIB environment variable, but I'm confused what actually happened with that

worked fine on debian as soon as i did `apt-get install libsdl2-dev`

although there were artifacts on the first paint. probably should report that

(all the solid color tiles rendered as black; this resolves itself after the first paint)

Hi All, does a debian build of servo work on ubuntu touch mobile?

I got this error when trying to bootstrap for android paste.ubuntu.com/p/XSkY5P2jQM

rust compiler using 100% of 4 cpu while trying to build and it's heating up the system a lot. Is it possible to reduce the cpu usage

standups: finally unbroke WPT manifest checking code.

jdm: Nice.

standups: Started contributing to Victor a bit and began writing my talk abstract for RustLab.

jdm: Yeah! Cheers!

weird

our android build machines are ~30 seconds ahead of the aws machines

the /css/CSS2/text/white-space-003.xht also failed at 15-03-2019 wpt sync 👀

cybai: My brain reached a point where if it sees "👀" it assumes it's you writing the message.

The heuristic has yet to be proven wrong so far.

nox: haha, you might notice the emoji more on GitHub after they shipped it for comments 😂

Nice!

cybai: I started using it too because of you. :D github.com/nox/inert/blob/master/CHANGELOG.md#020

nox: XDDD Cool! I love this changelog so much!!!

cybai: Thanks! I'm hyped about landing it one day in Servo.

nox: the first sentence in "How is this sound?" is so interesting XD

cybai: I am so bad at documenting that I forgot to s/Neutralize/NeutralizeUnsafe/ in the README.

nox: I'm good at sending typo PR 😂 Let me create a cybai-patch-1 for inert!

Aw thanks. :D

cybai: On github.com/servo/servo/compare/inert I made use of inert to reimplement all the *LayoutHelpers traits that are defined in script, if you want to see how I plan to use that. I didn't write any code that actually make use of my reimplementations yet, and I'm focusing on Victor this week so I'm not going to go back to it soon.

The thing I'm the happiest about is how Inert<T> can exist even if T isn't NeutralizeUnsafe, and how Inert::get_ref lets you access the T safely if it's Sync. Let me use inert only in script, and still be able to access types that are defined in other crates that don't implement any inert trait.

nox: here it is :D nox/inert #19

cybai++

nox: cool! thanks for pointing me to that branch! I will try to check the branch this weekend!

> Let me use inert only in script, and still be able to access types that are defined in other crates that don't implement any inert trait.

this sounds mind-blown to me 🤯

will see how you achieve that!

cybai: The most unsafe part of the inert crate is that Inert<T> is always Sync, even if T isn't, and then it derefs to <T as NeutralizeUnsafe>::Output, where NeutralizeUnsafe obviously needs to be carefully implemented to not expose the !Sync parts of T,

cybai: but if T is Sync, there was nothing unsafe about exposing it in the first place, so you can just access it through Inert::get_ref.

It's verbose, but safe, which is better than the short unsafe code we have currently. :)

nox: ahh, I think you explain very clearly! thanks! it sounds great to use it for getting safer code :D

Aw, thank you!

cybai: You may be interested by the discussions in rust-lang/rust #59211 too

nox: Will read it!

thanks!

how do I set this up for an android build PATH=$PATH:$ANDROID_SDK/platform-tools

I have sdk and ndk like this ANDROID_SDK="/home/arun/Android/Sdk"

ANDROID_NDK="/home/arun/Android/Sdk/ndk-bundle"

where should I exactly add the above paths in the bash.rc file?

arunkumar413: anywhere in .bashrc will work

Proposing a plan for smallvec 1.0 servo/rust-smallvec #73

meant to link to my comment at the bottom: servo/rust-smallvec #73#issuecomment-474893998

Is it mandatory that I use android ndk 12 version.

pcwalton: do you mind if I take over font-kit for a while? there's a bunch of stuff that needs to happen there, of which fallback font is the big one

raph: sure. let me give you access

raph: I added you as a collaborator

thanks! expect chaos

SimonSapin: I wonder if we should use Vector<T> in Victor.

That being said Vector<T> doesn't implement ParallelExtend,

nox: which kind?

SimonSapin: The Sync ones,

I mention that because Vector<T> internally uses chunks,

and parallel extend works on chunks.

nox: from what crate ?

SimonSapin: Oh, bodil's, from im-rs.

raph: I'm excited actually -- haven't had enough time to give font-kit the attention it deserves and glad to have you helping out

i'm also optimistic, it feels like this could be a really vital part of the infra for gaming, gui, and other stuff

another thing that has me positive is snl's own mikey day reviewing the design and showing interest

kinda star-struck, not every day such celebrities take interest in my work

i added something about small caps to linebender/skribo #2 btw - it's in scope but complex enough not to make the first cut at implementation

will merge that, likely today, if i don't get any more feedback

raph: oh that reminds me, I had some questions that boil down to "can shaping results be reused for different layouts of the same text/style with different line breaks"

I’ll file an issue with details

yes, issue is good. this is a question i've thought about a lot, as it's very relevant on android

(in particular, CSS needs to compute min and max "intrinsic sizes" based on taking all or none of the break oportunities)

(what android does is very cache-intensive, to try to keep things less stateful. this kinda works but it's very likely possible to do better)

standups: start going through the chromium impl

everyone being at gdc is the best time to have questions about the xr spec

arunkumar413: yes

raph: linebender/skribo #4

Thanks for filing. I'll think on it a bit and answer

Ok, wrote my answer, hope that is reasonably clear

how to make cache lookup cheap is another question - I have ideas for that

standups: fielding GSoC questions

standups: Refactored pathfinder to allow the device to set the viewport/size for each eye.

That was a head-scratcher, the pf3 demo really really wanted to be in charge of VR viewports.

which is fine on devices where the eyes are drawn next to each other, but not for devices where the eyes are drawn to different textures.

I thiiiink that's most of the work needed to get ML1 to work with pf3 demo/common.

jdm do you know if anyone else is looking at the webdriver issue as of now for gsoc?

ejmg: I have had one person send me a draft proposal, and two other people have asked to work on starter issues in preparation

oh shoot, dang

well that better meets my original expectations. i took the silence in here as kinda weird/expected more interest in mozilla x rust projets.

Anywho, so I have another question regarding the options parsion. As of now `from_cmdline_args()` eventually takes everything parsed out of opts and initializes a Opt struct out of them before doing some other important stuff like `set_options(opts)` and `prefs::add_user_prefs()`. How should I go about delaying this so that I can properly extract t

he embedder specific opts stuff from the global engine opts? jdm

ejmg: why do those need to be delayed?

Okay! So! That's something I presumed, lol.

My bad. I was thinking the final configuration of all opts had to be put together before doing the rest of the stuff that was occurring in from `from_cmdline_args()`, so my bad.

I was imagining that from_cmdline_args can eagerly return any failed parsing, and otherwise extract all of the options it knows about from the result, set the global opts, set the preferences, then return the result

jdm to check my understanding of both the code and issue, what `from_cmdline_args()` is doing really is mostly global engine stuff, so not having those embedded specific things figured out yet is okay and can be handled in the (correctly parsed) result value we are refactoring it to

yep!

the point is to remove the embedding-specific things from the global stuff entirely

there may be a couple uses of opts::get().headless in components/ that we need to remove

I think servo/servo #23057 would get rid of one

that would get rid of the other

Okay okay okay, so that definitely clarifies the concern I was voicing. I'll jot this down and hopefully get some more changes pushed up on that branch later for feedback.

Servo remains this leviathan beast that I poke with a stuck to learn from

heh heh

we all feel like that

there are still parts of it that I barely understand

wrt the 2 issues you linked above, should I add those changes as a part of my PR for #23061?

(don't see how i would otherwise without breaking things but want to check lol)

pcwalton: You are about to get PRs for pathfinder from me.

pcwalton: Any chance you could either merge pcwalton/pathfinder #109 or push your local commits?

ejmg: yes, either that or don't extract headless as part of your PR.

K

might make sense to leave headless for the time being

rather than blocking all of the work on fixing those

OH. Okay, I'll uh... unassign? Not sure I can do that, actually

Otherwise... I would leave headless in there for now, finish this, then jump in with another PR to fix headless usage.

building servo puts 100% stress on all the cores of the processor. Is it possible to reduce this

arunkumar413_: you can use `-j1` to only build with one core

Should pivot to real world concerns, I'll be back in later today or tomorrow. Thanks for the clarification on my question and pls unassign me from those issues I just took re: headless if that's for best for not blocking jdm. Bye ya'll 👋

will do!

stuck at this Building [=====================================================> ] 590/595: script

yeah, it takes a lot of time and memory to build script

it's taking long time. If I run on only one core will it take more time

that's generally expected

it should take the same amount of time to build script using -j1 or not

It will be pain if this has to done for every small change in code

can we share this burden just like we do torrent download?

arunkumar413_: sorry, it's caused by the way our code is organized. the script crate is very large, and any changes to that code need to recompile all of it.

build failed and got this error paste.ubuntu.com/p/xpyMRPkny8

help my computer is accumulating clones of browser engines

.... even a --depth 1 clone of chromium takes a while to download on office wifi

(i gave up on non-depth-1 clones a long time ago)

arunkumar413_: what did you run that produced that error?

jdm: servo/servo #23028 I was solving this issue and when I tried exposing a getter I got a borrow error for the owner.

crowbot: ./mach build --release --android

arunkumar413_: weird :(

sbansal: what was the error and what was the code?

sbansal: you probably want to make the getter return &Element, and do that with &*self.owner

jdm: tried again, this time it's just null pointer exception paste.ubuntu.com/p/wNM7tN3W2T

yikes

arunkumar413_: try changing the invoking of gradlew in package_commands.py to add --stacktrace and --debug

now running ./mach build --release --android --debug

arunkumar413_: that's not what I mean

arunkumar413_: there is code in python/servo/package_commands.py that runs gradlew

arunkumar413_: you should add --stacktrace and --debug to the arguments that are passed to gradlew in that file

jdm: I'll try again tomorrow. It's late night here. I got exhausted trying to build this

sorry it's causing you trouble!

Is it safe to quit the building process and start again tomorrow

yes

do I need to do any cleanup?

nope

cool

jdm: there was some progress made on speeding up the script build no?

jdm: thanks I will try that

fabrice: there was the project from last year which didn't finish merging

oh joy

hmm, the taskcluster check isn't working correctly

SimonSapin: FYI twitter.com/nokusu/status/1108461107478433792

nox: usual thing about implementing a trait from a crate for a type from another crate and they don’t depend on each other

SimonSapin: im already depends on rayon. :)

oh ok

but Vector does not implement ParallelExtend?

nox: Vector requires Clone for items

SimonSapin: Yeah, because it wants you to use refcounting or small values for the things inside.

But IIRC many operations don't use the Clone impl.

that sounds incompatible with pointer identity being meaningful… oh ok maybe not if the items are Arc

SimonSapin: Damn I forgot to change StrTendril to the Sync one.

ajeffrey: pushed up the lens distortion stuff

I should make it optional

woo, I have servo profiling output appearing in the ml log now

for your use case

time to see if anything interesting appears

nox: feel free to make that String

pcwalton: OK, hopefully I'm not too conflicted :)

jdm: man, programming in python is so much different than programming in rust

nox: I might change this anyway, to do (naive) shaping at box construction time, and store glyphs rather than text

KiChjang: trufax

i wouldn't have known where to look for the SSL stuff if you didn't point it out heh

SimonSapin: I did a type alias named Text.

SimonSapin: Ugh never mind I forgot h5e wants StrTendril everywhere, I'll make it String.

SimonSapin: Should I use rayon::prelude::*?

your call

jdm: for the issue #23028, I jave to use the new getter to change the argument at this line? github.com/servo/servo/blob/master/…ents/script/dom/cssrulelist.rs#L111

sbansal: yep

Thanks again

sbansal: if you look at github.com/servo/servo/blob/master/…style/stylesheets/rule_list.rs#L178 it's passed to the parser, and eventually hits this: github.com/servo/servo/blob/8de1b8d…yle/stylesheets/rule_parser.rs#L258

via github.com/servo/servo/blob/master/…nents/style/stylesheets/mod.rs#L283

jdm: ok so I just have to basically send the stylesheet's owner in this argument ?

standups: Submitted PRs for pathfinder, laying the groundwork for the magicleap demo PR.

pcwalton: now to sort out the merge conflicts...

sbansal: oh, I missed a step in the explanation - you can use StylesheetLoader::for_element and pass the owner element

pcwalton: rebased the PRs.

ajeffrey: cool, thanks

That barrel distortion is pretty extreme!

jdm: I am facing the following error "no method named `get_owner` found for type `&dom::window::Window` in the current scope

--> components/script/dom/cssrulelist.rs:104:59

|

104 | let loader = StylesheetLoader::for_element(window.get_owner());

| ^^^^^^^^^

error[E0308]: mismatched types

--> components/script/dom/cssrulelist.rs:113:17

|

113 | loader,

| ^^^^^^ expected enum `std::option::Option`, found struct `stylesheet_loader::StylesheetLoader`

|

= note: expected type `std::option::Option<&dyn style::stylesheets::StylesheetLoader>`

found type `stylesheet_loader::StylesheetLoader<'_>`

error: aborting due to 2 previous errors "

sbansal: look at the members of CSSRuleList

you added the method to Element, not Window

jdm: And what about the second issue?

sbansal: doc.rust-lang.org/book/ch06-01-defi…and-its-advantages-over-null-values

standups: ICFP industrial chair work.

standups: Fixing subpixel AA in Pathfinder 3 and porting to PenTile displays.

jdm: for the method added to elements, should I do something like "self.parent_stylesheet.get_owner()"

sbansal: yes

This again gives me a new error that htmlElement expected, found Element in this line

hmm

sbansal: oh, I see a more effective way. call Element::as_stylesheet_owner instead of StylesheetLoader::for_element

that returns Option<&dyn StylesheetOwner> which is exactly what you need

standups: poking at ANGLE, spidermonkey, and learning more about EGL

jdm: mismatched types

--> components/script/dom/cssrulelist.rs:113:17

|

113 |                 loader,

|                 ^^^^^^ expected trait `style::stylesheets::StylesheetLoader`, found trait `stylesheet_loader::StylesheetOwner`

|

= note: expected type `std::option::Option<&dyn style::stylesheets::StylesheetLoader>`

found type `std::option::Option<&dyn stylesheet_loader::StylesheetOwner>`

oh, boo

you're right

What should I do then?

sbansal: ok, you can go back to StylesheetLoader::for_element and use owner.downcast::<HTMLElement>().unwrap()

what are you asking about?

Yes I was askung about this error only.

Asking *

sbansal: I suggested a solution

jdm: no method named `downcast` found for type `&dom::element::Element` in the current scope

--> components/script/dom/cssrulelist.rs:105:56

|

105 |         let owner = self.parent_stylesheet.get_owner().downcast::<HTMLElement>().unwrap();

|                                                        ^^^^^^^^

|

= help: items from traits can only be used if the trait is in scope

= note: the following trait is implemented but not in scope, perhaps add a `use` for it:

`use crate::dom::bindings::inheritance::Castable;`

sbansal: luckily, that message tells you what the solution is

jdm: hi, re: #23068 sorry I'm new here :P I see the homu failure (not sure where to go to investigate exactly what failed) but I don't see a merge. Where does that show up?

millertime: oh, weird. I totally lied.

millertime: so you can click the taskcluster link from #23045 to see the various jobs that failed

millertime: and clicking each of those will take you to a screen where you can click Task Run 0 (latest)

er, Run Logs

millertime: however, I've looked at the failures and they're all spurious

so I will retry it

ah okay thanks!

jdm: I am still facing this error. Are youbsure wh have to use StyleSheetLoader::for_element ? "expected enum `std::option::Option`, found struct `stylesheet_loader::StylesheetLoader`

|

= note: expected type `std::option::Option<&dyn style::stylesheets::StylesheetLoader>`

found type `stylesheet_loader::StylesheetLoader<'_>` "

ajeffrey: partially SIMD-ified your quaternion code and pushed it

sorry for being difficult

pcwalton: ta