mozilla :: #layout

12 Sep 2017
16:38sfinkManishearth: would it be good enough to assume that any heap write within the scope of a MutexAutoLock is safe?
16:41Manishearthsfink: not exactly, because you can have two of the same heap write value in different calls that use different mutexes
16:41Manishearthunsure what to do here
16:41sfinkoh, I understand that possibility in programmatic terms
16:41Manishearthcan't be statically checked
16:41sfinkbut in terms of what's useful to report
16:41Manishearthas an approximation yeah i guess it's fine
16:41Manishearthit is
16:41sfinkthis came up because I'm trying to detect all calls to gtk_* or gdk_* and treat them basically as heap writes
16:42sfinkand many of them are only safe because they're guarded by a mutex
16:43sfinkin theory, this *could* be somewhat statically checked, since it looks like those mutexes are things like sServoFontMetricsLock, so I could compare identity of the mutexes
16:43sfinkbut I'm not sure I want to go there
17:36mstangeI'm adding a system color. Which stylo files do I need to regenerate and how?
17:36mstangeservo/components/style/gecko/generated/ seems to have a list of the system colors
17:39mstangeI don't see anything about running bindgen on
17:40mstangeemilio: can you point me to the right place? ^
17:41mstange is an example of such a system color
17:56mstangeI found which I also needed add my color to
18:08emiliomstange: I can look in ~30 minutes, is it fine?
18:09mstangeemilio: sure! I think it's actually working, now that I've made the change
18:09mstangethe build hasn't finished yet, though, so I don't know if it'll run
18:45emiliomstange: I'm back now, did you get it working?
18:45mstangeemilio: the build runs but I'm not certain that it matches up the correct colors
18:46mstange(I haven't tested)
18:46mstangeemilio: do you know what generates and when?
18:46mstangeI probably need to add my color around here:
18:47emiliomstange: yes, it's generated at build time, and your color should end up there in `ojb/dist/rust_bindings/style`
18:47mstangeI see
18:47emiliomstange: those two files are checked-in in the servo repo so we can actually build it without pulling m-c
18:47mstangeI understand now
18:47emiliomstange: but they're not used during the build, they're auto-generated
18:48mstangeso when I land my change, I also need to prepare a pull request to the servo repo?
18:48mstangeby replacing the checked in files with the ones from my objdir?
18:48emiliomstange: have you done other changes to the `servo/` repo?
18:48emiliomstange: *directory
18:48mstangeoh, I see what you're saying
18:48mstangeor, wait
18:48mstangeI have modified
18:49mstangeemilio: I added my color here:
18:49emiliomstange: right. In that case you need to submit that change (and presumably your generated bindings too) as a servo PR.
18:50emiliomstange: (that kinda sucks :/)
18:50mstangeand then just merge them at roughly the same time?
18:50mstangeand have the tree burn in between?
18:50emiliomstange: yeah, when the Servo PR lands, just check in your gecko changes via autoland
18:50mstangeok cool
18:50mstangeemilio: thanks for the help!
18:51emiliomstange: no problem! Sorry this stuff isn't as obvious as it should :(
18:51emiliomstange: I'm aware that the workflow is kinda sucky
18:51emiliomstange: Ideally I plan to move all the gecko-specific stuff into m-c, but that's a pretty decent refactor
18:52mstangeI see
18:52mstangeI'm willing to put up with some suckiness in the run up to 57 :)
18:52mstangebut some documentation along the lines of "I think I need to touch these files, what do I do" would be great
19:07emiliomstange: noted :)
19:12emiliomstange: I added a paragraph to that page (which I hadn't seen before actually). There are a few things that look a bit outdated, I may go through it tomorrow
13 Sep 2017
No messages
Last message: 8 days and 10 hours ago