[webkit-dev] Troubles with Anonymous Blocks
I've been struggling with odd issues with anonymous blocks that I don't quite understand. For example, to build a fraction in MathML I wrap the numerator and denominator in an anonymous block: RenderBlock* row = new (renderArena()) RenderBlock(document()); I then set border, padding, and text-align style properties on the style for that anonymous block. These settings seem to have stopped working in the latest round of work. If I change the construction of the row wrapper to: RenderBlock* row = new (renderArena()) RenderBlock(node()); which is backed by the 'mfrac' element, all the border/etc. style properties work. When I trace through with the debugger, the border properties seem to disappear from the style object when the node is the document node and the block is anonymous. Any ideas on what is happening? I see that there is little code that uses an anonymous blocks directly as I do. Is there are a preferred way to do this? My intended design for fractions was: 1. The mfrac is a inline-block with block flows for its children 2. The numerator and denominator are blocks that stack vertically. 3. The denominator has a border property for the fraction line separator. 4. These wrapper blocks for the numerator and denominator can have arbitrarily complicated flows of their own. Currently, if I use the second construct above and use node() as the backing node for the block wrappers for the numerator and denominator, it almost works. There seem to be situations where the border is drawn short of the overall width--which is a another problem I'm struggling with but may be unrelated to this issue. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] http://webkit.org/pending-commit
In an effort to clean out the list of to-be-committed patches (http://webkit.org/pending-commit) I wrote a small command for webkit-patch to clear r+ flags on obsolete attachments and ran it this afternoon. My apologies to those of you who received a bunch of bug mail as a result. I tried for a while to fix the pending-commit bugzilla query to ignore obsolete attachments, but was unsuccessful. If anyone else has any luck, we can always ask wms to update the alias. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Buildbot Emails
Historically build.webkit.org would email people when their changes broke the tree. This was disabled some time ago. I would very much like to see it re-enabled. Could someone point me as to how that would happen (I'm happy to code up a patch), or flip the magical switch themselves? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbot Emails
On Feb 8, 2010, at 4:45 PM, Eric Seidel wrote: Historically build.webkit.org would email people when their changes broke the tree. This was disabled some time ago. I would very much like to see it re-enabled. Could someone point me as to how that would happen (I'm happy to code up a patch), or flip the magical switch themselves? I'd actually like to see it email a mailing list, in addition to the individuals it guesses are to blame. That could be either webkit-dev or a new list. Maybe some won't want the spam but I bet a lot of people would like to find out about every build break. If it's at all possible, it would be great to email all of the patch author, the reviewer and the committer (if different from the patch author). I also think it would be neat if we could have a bot that alerts about build breaks on IRC in #webkit. And finally, it might be good to have extra notice if a build remains broken for some time (every 24 hours maybe?) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbot Emails
Do you guys think it may be a good idea to bring the concept of tree closure to WebKit? :DG On Mon, Feb 8, 2010 at 5:29 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2010, at 4:45 PM, Eric Seidel wrote: Historically build.webkit.org would email people when their changes broke the tree. This was disabled some time ago. I would very much like to see it re-enabled. Could someone point me as to how that would happen (I'm happy to code up a patch), or flip the magical switch themselves? I'd actually like to see it email a mailing list, in addition to the individuals it guesses are to blame. That could be either webkit-dev or a new list. Maybe some won't want the spam but I bet a lot of people would like to find out about every build break. If it's at all possible, it would be great to email all of the patch author, the reviewer and the committer (if different from the patch author). I also think it would be neat if we could have a bot that alerts about build breaks on IRC in #webkit. And finally, it might be good to have extra notice if a build remains broken for some time (every 24 hours maybe?) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbot Emails
On Feb 8, 2010, at 5:33 PM, Dimitri Glazkov wrote: Do you guys think it may be a good idea to bring the concept of tree closure to WebKit? I'd like to start with more active broadcast notification of build breaks and see if we think we need more changes from there. I prefer to try technology-based approaches before process-based approaches. Right now broken trees linger because you have to go out of your way to notice, meaning the information diffuses slowly. Regards, Maciej :DG On Mon, Feb 8, 2010 at 5:29 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2010, at 4:45 PM, Eric Seidel wrote: Historically build.webkit.org would email people when their changes broke the tree. This was disabled some time ago. I would very much like to see it re-enabled. Could someone point me as to how that would happen (I'm happy to code up a patch), or flip the magical switch themselves? I'd actually like to see it email a mailing list, in addition to the individuals it guesses are to blame. That could be either webkit-dev or a new list. Maybe some won't want the spam but I bet a lot of people would like to find out about every build break. If it's at all possible, it would be great to email all of the patch author, the reviewer and the committer (if different from the patch author). I also think it would be neat if we could have a bot that alerts about build breaks on IRC in #webkit. And finally, it might be good to have extra notice if a build remains broken for some time (every 24 hours maybe?) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbot Emails
On Feb 8, 2010, at 5:29 PM, Maciej Stachowiak wrote: That could be either webkit-dev or a new list. Maybe some won't want the spam but I bet a lot of people would like to find out about every build break. Please make it a new opt-in list. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Buildbot early exit
Good morning crowd, can anyone explain the --exit-after-n-failures=20 default behaviour for the build bots? Background: Today I had to update a lot of SVG *expected.txt files including all platform specific variations (in LayoutTests/platform/gtk/qt/win/mac- *). I landed my patch with updated mac results and planned to wait for the build bots to show me all differences, so I could update all baselines for the individual platforms needing custom layout test results differing from the mac baseline. Though because the bots exit early after 20 test failures it took a long time to identify all differences because I could only fix a maximum of 20 failures per commit - that's odd. I'm aware it's a rare case to update 900+ test results in one shot but I thought it's worth to mention. I think the best way to resolve this problem is to run layout tests on the try bots, so any layout test differences can be identified before comitting. I recall some talk about that in the past, what's the status? Cheers, Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbot early exit
We've had cases of a patch destroying the buildbots by rampaging through thousands of test failures. The 20 limit is a fail-stop to keep the bots rolling. I agree that try servers would be a better way to handle this case than lighting the buildbot on fire. I'd like to extend the EWS to run tests, which could then make the new baselines available. Some other folks have expressed interest in having that work too. If you're interested in helping to make that happen, let me know. Adam On Mon, Feb 8, 2010 at 6:51 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Good morning crowd, can anyone explain the --exit-after-n-failures=20 default behaviour for the build bots? Background: Today I had to update a lot of SVG *expected.txt files including all platform specific variations (in LayoutTests/platform/gtk/qt/win/mac-*). I landed my patch with updated mac results and planned to wait for the build bots to show me all differences, so I could update all baselines for the individual platforms needing custom layout test results differing from the mac baseline. Though because the bots exit early after 20 test failures it took a long time to identify all differences because I could only fix a maximum of 20 failures per commit - that's odd. I'm aware it's a rare case to update 900+ test results in one shot but I thought it's worth to mention. I think the best way to resolve this problem is to run layout tests on the try bots, so any layout test differences can be identified before comitting. I recall some talk about that in the past, what's the status? Cheers, Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MathML Update: Recent Progress
I've just added support for mfrac (fractions) as a separate patch. I've also updated the monster patch with all the latest code against the trunk. You can get this from: https://bugs.webkit.org/show_bug.cgi?id=33703 There are a number of individual patches that need review: https://bugs.webkit.org/show_bug.cgi?id=34277 - munder, mover, and munderover support https://bugs.webkit.org/show_bug.cgi?id=34278 - msubsup, msub, and msup support https://bugs.webkit.org/show_bug.cgi?id=34347 - mrow and stretchy operator support https://bugs.webkit.org/show_bug.cgi?id=34741 - mfrac support All of these patch involve one or two new render objects. The most complex is probably the row/operator support (34347). The others should be straight forward. If these patches can make some progress getting into the trunk, WebKit will be able to do a reasonable job of rendering mathematics for a limited but useable subset of MathML. My next task is to get some kind of root/square root implementation that works reasonably well. I have something now in the monster patch but it has lots of issues. There are plenty of MathML features that do not work as of yet but with the above core those features should be smaller changes based on these pieces as starting points. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Troubles with Anonymous Blocks
Just a stab in the dark here, and without knowledge about recent changes that could have caused your code to break (so this could be wildly off). The difference between the 2 versions AFAICT is whether m_isAnonymous is set or not, which leads me to the question: have you properly overridden createsAnonymousWrapper() in the parent? Cheers, Roland On Tue, Feb 9, 2010 at 6:28 AM, Alex Milowski a...@milowski.org wrote: I've been struggling with odd issues with anonymous blocks that I don't quite understand. For example, to build a fraction in MathML I wrap the numerator and denominator in an anonymous block: RenderBlock* row = new (renderArena()) RenderBlock(document()); I then set border, padding, and text-align style properties on the style for that anonymous block. These settings seem to have stopped working in the latest round of work. If I change the construction of the row wrapper to: RenderBlock* row = new (renderArena()) RenderBlock(node()); which is backed by the 'mfrac' element, all the border/etc. style properties work. When I trace through with the debugger, the border properties seem to disappear from the style object when the node is the document node and the block is anonymous. Any ideas on what is happening? I see that there is little code that uses an anonymous blocks directly as I do. Is there are a preferred way to do this? My intended design for fractions was: 1. The mfrac is a inline-block with block flows for its children 2. The numerator and denominator are blocks that stack vertically. 3. The denominator has a border property for the fraction line separator. 4. These wrapper blocks for the numerator and denominator can have arbitrarily complicated flows of their own. Currently, if I use the second construct above and use node() as the backing node for the block wrappers for the numerator and denominator, it almost works. There seem to be situations where the border is drawn short of the overall width--which is a another problem I'm struggling with but may be unrelated to this issue. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
