Re: [webkit-dev] Snow Leopard Bot went down

[Eric Seidel]

The ICE appears to have spread to other bots as well:

..\..\..\JavaScriptCore\runtime\ArrayPrototype.cpp: In function 'void*
JSC::arrayProtoFuncJoin(JSC::ExecState*)':
..\..\..\JavaScriptCore\runtime\ArrayPrototype.cpp:263:30: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

http://build.webkit.org/builders/Qt%20Windows%2032-bit%20Release/builds/4266/steps/compile-webkit/logs/stdio

On Fri, Jul 9, 2010 at 3:22 PM, Tony Gentilcore  wrote:
> No theories. But another data point; Tiger started doing the same a few
> revisions earlier:
>
> /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm:
> In function 'void -[WebView(WebPrivate)
> _commonInitializationWithFrameName:groupName:usesDocumentViews:](WebView*,
> objc_selector*, NSString*, NSString*, BOOL)':
> /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm:628:
> internal compiler error: Segmentation fault
>
> On Fri, Jul 9, 2010 at 3:13 PM, Eric Seidel  wrote:
>>
>>
>> /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release/build/WebCore/config.h:212:
>> fatal error: error writing to -: Broken pipe
>> compilation terminated.
>> i686-apple-darwin10-gcc-4.2.1: Internal error: Segmentation fault (program
>> as)
>> Please submit a full bug report.
>> See http://developer.apple.com/bugreporter> for instructions.
>>
>>
>> http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Build)/builds/13344/steps/compile-webkit/logs/stdio
>>
>> Any theories?
>> ___
>> 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] Bugzilla Question - Master Bug vs Component?

[Adam Barth]

On Fri, Jul 9, 2010 at 6:19 PM, David Kilzer  wrote:
> On Jul 9, 2010, at 7:34 AM, Adam Roben  wrote:
>
> On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote:
>
> Should we keep the master bug?
>
> Should we use it only for our implementation efforts and not
>
> make it depend on every random bug filed for the MathML
>
> component?
>
> I think an important question to ask is, "When will you move the master bug
> to Resolved/Fixed?" This is basically another way of saying, "What task(s)
> does the master bug represent?" Once you know that answer, the answers to
> your other questions may be obvious.
>
> IMO, it should be closed once MathML is enabled in the WebKit nightly builds
> and/or most ports.

Out of curiosity, is there an estimate of when that might be?  There's
some interaction with the new HTML5 parser because it supports
MathML-in-HTML.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

[David Kilzer]

On Jul 9, 2010, at 7:34 AM, Adam Roben  wrote:

> On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote:
> 
>> Should we keep the master bug?
>> 
>> Should we use it only for our implementation efforts and not
>> make it depend on every random bug filed for the MathML
>> component?
> 
> I think an important question to ask is, "When will you move the master bug 
> to Resolved/Fixed?" This is basically another way of saying, "What task(s) 
> does the master bug represent?" Once you know that answer, the answers to 
> your other questions may be obvious.

IMO, it should be closed once MathML is enabled in the WebKit nightly builds 
and/or most ports.

Dave
--
Sent from my iPhone 3GS
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

[Ojan Vafai]

This has landed. Squashing is now the default behavior. --git-commit/-g
operates on the commit(s) listed as a single commit. --git-commit=HEAD..
operates on the working copy.

Ojan

On Mon, May 24, 2010 at 5:10 PM, Ojan Vafai  wrote:

> I posted a patch to https://bugs.webkit.org/show_bug.cgi?id=39624. Which
> prompted further discussion on #webkit. We came to a different conclusion.
> The basic idea is that webkit-patch should work right without any flags for
> some workflow. We can make it work right for the branch-per-bug workflow and
> write a separate wrapper script to make the commit-per-bug workflow work.
> Specifically the behavior would be the following:
>
>- Squashing should be the default behavior. In cases where squashing
>might do something unexpected (e.g. commit multiple local changes), we'll
>prompt the user to see if they want to continue. The prompt can be avoided
>by adding webkit-patch.squash to the git config. There won't be any 
> --squash
>or --no-squash commands.
>- --git-commit will work as outlined below except that * will no longer
>mean squash.
>
> Unless I hear objections, I'll change my patch for bug 39624 to implement
> the above.
>
> Ojan
>
> On Mon, May 17, 2010 at 2:21 PM, Ojan Vafai  wrote:
>
>> On Sun, May 16, 2010 at 10:38 AM, Chris Jerdonek wrote:
>>
>>> On Sun, May 16, 2010 at 8:26 AM, Ojan Vafai  wrote:
>>> > On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek 
>>> > wrote:
>>> >>  In particular, --git-commit=HEAD.. should be just the
>>> >> uncommitted changes (staged and unstaged).
>>> >
>>> > This one I'm a bit iffy on. Should this include the commit at head? I
>>> think
>>> > it should.
>>>
>>> Currently, when using check-webkit-style for example, I need to pass
>>> --git-commit=HEAD^.. to include the commit at head.  In other words,
>>> it operates on ranges like the above exclusively with respect to the
>>> endpoint.  This is similar to how git-diff behaves and is described
>>> here:
>>>
>>> http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
>>>
>>> Were you thinking about changing this behavior?
>>
>>
>> Someone also pointed out off thread that including working copy changes
>> doesn't match any existing git commands. I think we should try to stay as
>> close to git semantics as possible.  So, I'm revising the proposal.
>>
>> It weirds me out the --git-commit=head~3..head~2 and --git-commit=head~2
>> do the same thing, but it turns out most git commands work that way.
>>
>> I propose:
>> default: operate on working copy changes. Errors if there are no working
>> copy changes or if there are committed changes. Gives a nice error message
>> saying what to do.
>> --git-commit=*  operate on all changes in your branch as a single commit,
>> including working copy changes
>> --git-commit=head~2  operate on head~2
>> --git-commit=head~2..  operate on head~2, head~1 and head
>> --git-commit=head~4..head~2  operate on head~3 and head~2 as a single
>> commit
>>
>> Sound good?
>>
>> Ojan
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Snow Leopard Bot went down

[Tony Gentilcore]

No theories. But another data point; Tiger started doing the same a few
revisions earlier:

/Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm:
In function 'void -[WebView(WebPrivate)
_commonInitializationWithFrameName:groupName:usesDocumentViews:](WebView*,
objc_selector*, NSString*, NSString*, BOOL)':
/Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm:628:
internal compiler error: Segmentation fault


On Fri, Jul 9, 2010 at 3:13 PM, Eric Seidel  wrote:

>
> /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release/build/WebCore/config.h:212:
> fatal error: error writing to -: Broken pipe
> compilation terminated.
> i686-apple-darwin10-gcc-4.2.1: Internal error: Segmentation fault (program
> as)
> Please submit a full bug report.
> See http://developer.apple.com/bugreporter> for instructions.
>
>
> http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Build)/builds/13344/steps/compile-webkit/logs/stdio
>
> Any theories?
> ___
> 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] Snow Leopard Bot went down

[Eric Seidel]

/Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release/build/WebCore/config.h:212:
fatal error: error writing to -: Broken pipe
compilation terminated.
i686-apple-darwin10-gcc-4.2.1: Internal error: Segmentation fault (program as)
Please submit a full bug report.
See http://developer.apple.com/bugreporter> for instructions.

http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Build)/builds/13344/steps/compile-webkit/logs/stdio

Any theories?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

[Beth Dakin]

On Jul 9, 2010, at 7:34 AM, Adam Roben wrote:

> I think an important question to ask is, "When will you move the master bug 
> to Resolved/Fixed?" This is basically another way of saying, "What task(s) 
> does the master bug represent?" Once you know that answer, the answers to 
> your other questions may be obvious.

I think this is great feedback. Personally, I think the master bug should 
represent only bugs that would prevent MathML from being turned on in the build 
by default. It would also be a very valuable exercise to consider what those 
bugs might be.

-Beth
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] STIX Fonts and MathML Tests

[Sausset François]

I filled a bug and submitted a patch with fonts and license only:
https://bugs.webkit.org/show_bug.cgi?id=41961

Does anyone could tell if this license is compatible with the WebKit one?

François Sausset


Le 7 juil. 2010 à 21:25, Dan Bernstein a écrit :

> 
> On Jul 7, 2010, at 11:17 AM, Sausset François wrote:
> 
>> If every is OK with licenses, how DumpRenderTree needs to be modified to use 
>> custom fonts?
> 
> This is where the Mac version activates test fonts:
> http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L218
> 
> and this is where the Windows version does it:
> http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/win/DumpRenderTree.cpp#L275
> 
> You will also need to modify the build system to copy the additional fonts to 
> the right places.
> 
>> And where the fonts have to be stored?
> 
> Most are here:
> http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/fonts
> 
> Ahem is currently in
> http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/qt/fonts
> but had better be moved to the cross-platform location.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Commit Queue Love

[Ryosuke Niwa]

On Fri, Jul 9, 2010 at 7:39 AM, Timothy Hatcher  wrote:

> Some of the glaring reasons I don't use the commit queue have been resolved
> (svn blame mainly), but the fact that there is no control over when the path
> lands is my chief reason.


I agree.  When my patch has a potential to affect the other parts of WebKit,
I have to watch waterfall and commit myself to see all builders pass all the
tests so that I can FIX them as needed.

I didn't take Alex's post offensive though.

Best,
Ryosuke Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Commit Queue Love

[Alex Milowski]

On Fri, Jul 9, 2010 at 3:39 PM, Timothy Hatcher  wrote:
> On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote:
>
>> Being able to go around the commit queue means you can cheat.  That
>> seems like something that should be reserved for more severe problems
>> where we know the process used by the commit queue will fail.
>
> That is not how I see it at all. And calling it "cheating" is quite offensive 
> to me. Just because I want control over when and how my patch is committed is 
> suddenly considered cheating?

Sorry, that wasn't meant to be offensive.

It is going around a process.  That said, not everyone has committed
to using that process.  So, you're right.  It isn't "cheating".

All I'm advocating is using the commit queue much more often.

I don't have any control over when my code hits the trunk.  Somehow, it all
works out in the end.

-- 
--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] Commit Queue Love

[Timothy Hatcher]

On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote:

> Being able to go around the commit queue means you can cheat.  That
> seems like something that should be reserved for more severe problems
> where we know the process used by the commit queue will fail.

That is not how I see it at all. And calling it "cheating" is quite offensive 
to me. Just because I want control over when and how my patch is committed is 
suddenly considered cheating?

Some of the glaring reasons I don't use the commit queue have been resolved 
(svn blame mainly), but the fact that there is no control over when the path 
lands is my chief reason. Often I need to update Apple's internal bug database 
when I make a change to WebKit, so I just can't rely on the commit bot to close 
the bugzilla bug. That means holding a bug open and knowing go back days later 
when it finally lands to close the internal bug. Other times there are internal 
deadlines that need to be meet and hours matter. As well as keeping patches 
that span WebKit and Safari in-sync.

So until the commit queue solves these issues, I will keep exercising my right 
to svn commit and be responsive to problems my commits might bring. But please 
lets stop calling it "cheating".

— Timothy Hatcher

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

[Adam Roben]

On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote:

> For MathML we have a master bug 3251 that we've been making depend
> on every new patch for MathML.  That is a very nice in that as new patches
> are added and committed, you can get notifications of the changes
> in status.

If all you're concerned about is getting email notifications, we can add you to 
the default CC list for the MathML component.

> We also have the MathML component that all bugs should be associated
> with.  As time goes but, bugs should get filed against the MathML
> component but they won't be associated with the master bug for MathML.
> 
> What is the preferred process here?
> 
> Should we keep the master bug?
> 
> Should we use it only for our implementation efforts and not
> make it depend on every random bug filed for the MathML
> component?

I think an important question to ask is, "When will you move the master bug to 
Resolved/Fixed?" This is basically another way of saying, "What task(s) does 
the master bug represent?" Once you know that answer, the answers to your other 
questions may be obvious.

-Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DerivedSources.make & CPP DOM Bindings

[David Kilzer]

On Jul 8, 2010, at 11:04 AM, Kevin Ollivier  wrote:

> I'm working on making the CPP DOM bindings accessible to the wx port, and 
> while I've got the whole thing building, one thing I have yet to sort out is 
> how to add building of the CPP DOM bindings to the build system. 
> DerivedSources.make seems to be the appropriate place to put the code, and 
> it's where I've put things for now, but I wasn't sure if others would feel 
> this is the right place.

DerivedSources.make is the appropriate place for this.

> If I do add it, what is the appropriate way to do it? Should generation be 
> conditional on some define the port will set, like MAKE_CPP_BINDINGS, or 
> should we just directly check for BUILDING_ defines?

I would use BUILDING_ for now until such time as another port wants to 
enable it.

Dave
--
Sent from my iPhone 3GS
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Commit Queue Love

[Alex Milowski]

Independently of the other long thread, I'd like to express my "love" of
the commit queue.  It is actually quite a nice feature for someone like
myself who is "off in a corner".

I don't want commit access.  I'd rather my changes go through some
process like the commit queue to ensure that it doesn't break other
people's code or block forward development in some way.

It is very frustrating sometimes when your patch is stuck in the commit
queue for days.  I don't necessarily see that as being caused by the
commit queue.  That is directly because it isn't getting the "love" it
deserves! :)

Being able to go around the commit queue means you can cheat.  That
seems like something that should be reserved for more severe problems
where we know the process used by the commit queue will fail.

If committers need some kind of specialized access, maybe they
just need a "fast track" commit queue, a higher priority, or some
additional options, so that the policies for building and testing can
be uniformly applied while still meeting their needs.

-- 
--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] Bugzilla Question - Master Bug vs Component?

[Alex Milowski]

For MathML we have a master bug 3251 that we've been making depend
on every new patch for MathML.  That is a very nice in that as new patches
are added and committed, you can get notifications of the changes
in status.

We also have the MathML component that all bugs should be associated
with.  As time goes but, bugs should get filed against the MathML
component but they won't be associated with the master bug for MathML.

What is the preferred process here?

Should we keep the master bug?

Should we use it only for our implementation efforts and not
make it depend on every random bug filed for the MathML
component?

I certainly have my opinion on this.  I'd rather not associated everything
that gets reported with the master bug.  Instead, I'd rather we only
associated our implementation efforts or issues describing "sub-features"
related to implementation of certain "features" of MathML (e.g. glyph
inspection to tighten under/over placement).  We can then make the
bugs filed by random users depend on such implementation efforts
associated with the master bug.

I expect to get a lot of bugs like "my MathML is messed up, here's
an example" where the specifics of "why" will be associated with
a number of different specific technical issues.

Basically, my preference is:

master bug -> feature or technical issue <- user bug

-- 
--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