Re: [webkit-dev] javascript unmodified

[Adam Barth]

I'm sorry, but this mailing list is about the development of the
WebKit engine.  You might have more luck emailing webkit-help:

http://lists.webkit.org/mailman/listinfo/webkit-help

Adam


On Mon, Aug 6, 2012 at 10:54 PM, sarath Gude  wrote:
> Hi,
>
> I've been using google chromium and trying to collect javascripts from the
> webpages it browses.
> These scripts are modified by various files in chromium and all those
> modifications were made by webkit.
> when contacted the chromium developers for the file to which the unmodified
> javascript is first fed,
> they suggested me to contact the webkit developers.
> I tried to go through webkit but it is too time consuming and confusing.
> Can you point me to the file to which the scripts are initially passed in
> Webkit.
>
> Thanks,
> Sharath.
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] javascript unmodified

[sarath Gude]

Hi,

I've been using google chromium and trying to collect javascripts from the 
webpages it browses.
These scripts are modified by various files in chromium and all those 
modifications were made by webkit.
when contacted the chromium developers for the file to which the unmodified 
javascript is first fed,
they suggested me to contact the webkit developers.
I tried to go through webkit but it is too time consuming and confusing.
Can you point me to the file to which the scripts are initially passed in  
Webkit.

Thanks,
Sharath.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Build failed for Qt port revision - r124698

[Nilesh Patil]

Hi

I am trying to build Webkit source based on r124698.
It breaks with following linking error. I am currently clueless:

/home/nilesh.patil/Project/WebKit-r124698/WebKitBuild/Debug/lib/libQtWebKit.so:
undefined reference to `WebCore::GlyphPageTreeNode::getRoot(unsigned int)'
/home/nilesh.patil/Project/WebKit-r124698/WebKitBuild/Debug/lib/libQtWebKit.so:
undefined reference to
`WebCore::GlyphPageTreeNode::getChild(WebCore::FontData const*, unsigned
int)'
collect2: ld returned 1 exit status
make[4]: *** [tst_qobjectbridge] Error 1
.
.
.
make: *** [incremental] Error 2

Thanks & Regards
vniles
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] SVG video chat (3)

[Philip Rogers]

SVG WebKittens,

The last video chat was well received and as a group we decided to do it
again. If you'd like to join in please add your name, availability, and
topics you'd like to discuss to the spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdGc5cGJwZTBvVl9taVJZazYteHdnbkE

Thanks,
Philip
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit for Windows x64

[Ryosuke Niwa]

If you wanted to contribute to WebKit, file bugs on bugs.webkit.org and
submit patches there.
Also see http://www.webkit.org/coding/contributing.html

On Mon, Aug 6, 2012 at 1:09 PM, Alex Christensen <
alex.christen...@flexsim.com> wrote:

> I got webkit to compile for Windows x64, and it runs successfully.  For
> anyone that wants to try or help include my changes in webkit, my
> repository is found at  https://github.com/achristensen07/webkit64prep (I'm
> not a webkit committer yet)
>
> --
>
>
>
> Alex Christensen
>
> FlexSim Software Products, Inc.
>
> *1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097*
>
> *Voice: 801-224-6914 | Fax: 801-224-6984*
>
> *Email:* al...@flexsim.com 
>
> *URL:* www.flexsim.com
>
>
>
>
> 
>
> This message may contain confidential information, and is intended
>
> only for the use of the individual(s) to whom it is addressed.
>
> 
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WebKit for Windows x64

[Alex Christensen]

I got webkit to compile for Windows x64, and it runs successfully.  For
anyone that wants to try or help include my changes in webkit, my
repository is found at  https://github.com/achristensen07/webkit64prep (I'm
not a webkit committer yet)

-- 



Alex Christensen

FlexSim Software Products, Inc.

*1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097*

*Voice: 801-224-6914 | Fax: 801-224-6984*

*Email:* al...@flexsim.com 

*URL:* www.flexsim.com





This message may contain confidential information, and is intended

only for the use of the individual(s) to whom it is addressed.

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

Re: [webkit-dev] github mirror

[Adam Barth]

On Mon, Aug 6, 2012 at 4:59 AM, KwangYul Seo  wrote:
> What's the current status? Do they still have different hashes?

Yes.

> I am trying to push a few commits to my GitHub WebKit repo from my repo
> cloned from git.webkit.org. It seems I am pushing the entire repo :(

Correct.  That's not going to work well.  Instead you should fork
https://github.com/WebKit/webkit and rebase your changes onto your
fork.

Adam


> On Mon, Apr 30, 2012 at 2:48 AM, Adam Barth  wrote:
>>
>> Tor,
>>
>> I think we should retire the author rewriting script on GitHub.
>>
>> Jame's is right that there's a lot of value in having git.webkit.org
>> and GitHub using the same hashes.  For example, both Eric and Gavin
>> requested that when they started using GitHub.
>>
>> We would have some trouble adopting the author rewriting script on
>> git.webkit.org.  For example, the instructions for using git with
>> WebKit  suggest
>> configuring git-svn to allow you to commit from your git repository.
>> When git-svn imports changes from SVN into your git repository, it
>> won't know to apply the author rewriting script.  That will cause your
>> local repository to diverge from an author-rewriting git.webkit.org,
>> which is bad times.
>>
>> Therefore, it seems like the best way to synchronize the hashes
>> between git.webkit.org and GitHub is to retire the author rewriting
>> script on GitHub and do a non-fastforward push of the unrewritten
>> repository.  That will be somewhat disruptive for folks currently
>> using the GitHub repository, but at least it's only a one-time cost.
>>
>> Adam
>>
>>
>> On Tue, Apr 24, 2012 at 11:06 AM, James Robinson 
>> wrote:
>> > On Tue, Apr 24, 2012 at 7:15 AM, Tor Arne Vestbø
>> > 
>> > wrote:
>> >> On 24.04.12 16:04, ext Shezan Baig wrote:
>> >>> On Tue, Apr 24, 2012 at 9:55 AM, Adam Roben  wrote:
>> > In what situation does this cause issues?
>> 
>> 
>>  Probably the biggest issue is for people who've been using
>>  git.webkit.org and now want to try out GitHub. Since the commits are
>>  distinct between the two repositories, they have to do a full clone
>>  to
>>  make the switch.
>> >>>
>> >>>
>> >>>
>> >>> In theory though, these users should be able to just add a remote to
>> >>> their existing clone.  Then it will just sync the commit objects, and
>> >>> not the trees and blobs.  Not ideal, they would have two different
>> >>> 'masters', but still doable, and not *that* much of an overhead.
>> >>> Switching between the different masters should also be fast since the
>> >>> trees will be the same.
>> >>
>> >>
>> >> Right, a fetch should ideally just pull down the commit objects, but it
>> >> appears git does not have this optimization. If it did, I don't think
>> >> the
>> >> issue of two remote masters would be that big, since you would at some
>> >> point
>> >> likely transition to use one of the mirrors anyways. And if not, having
>> >> multiple mirrors/remotes should be fine -- I'm using both the github
>> >> and
>> >> gitorious mirror without any issues.
>> >>
>> >>
>> >>> But I agree these two repos should probably merge sooner rather than
>> >>> later, just to avoid confusion for new users etc :)
>> >>
>> >>
>> >> I would support that if it means cleaning up the author-script (which
>> >> I'm
>> >> happy to do), and using that on webkit.org.
>> >
>> >
>> > Whatever we decide to do in the future, author rewriting seems like
>> > extremely low value compared to having matching SHA1s.  I think we
>> > should
>> > get a clone on github.com that matches the existing git.webkit.org SHA1s
>> > and
>> > then make sure that they stay in sync (either with rewriting or not, but
>> > whatever webkit.org does).
>> >
>> > - James
>> >
>> >>
>> >>
>> >> tor arne
>> >>
>> >>
>> >> ___
>> >> 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 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/webkit-dev

Re: [webkit-dev] Enable MICRODATA feature by default

[Adam Barth]

Arko,

You might already be aware, but I wanted to mention this to make sure
your expectations are set correctly.  At least for the Chromium port,
there's a difference between enabling a feature on trunk and promoting
the feature to the beta and/or stable channel.  We make the former
decision via WebKit's code review process.  For the latter decision,
however, there's also an additional review process that's internal to
the Chromium project.

Adam


On Mon, Aug 6, 2012 at 12:23 AM, Arko Saha  wrote:
> I have filed a bug to address W3C failed test-cases :
> https://bugs.webkit.org/show_bug.cgi?id=92986
> This issue will track all investigation related to Microdata test failures
> and make sure that we pass as many test as possible.
>
> Regards,
> Arko
>
>
> On Wed, Aug 1, 2012 at 12:16 AM, Ian Hickson  wrote:
>>
>> On Tue, 31 Jul 2012, Arko Saha wrote:
>> >
>> > test(function () {
>> > assert_equals( makeEl('div',{itemtype:' '}).itemType[0],
>> > window.undefined );
>> > }, 'itemType[index] must be undefined for out-of-range index');
>> >
>> > DOMSettableTokenList returns null for out-of-range index.
>>
>> This is incorrect. While it is true that item() returns null when
>> called with an out-of-range index, item() is never invoked in the example
>> above. See Web IDL for details.
>>
>> I highly doubt that the other 80+ failing tests are implementation-
>> specific either. If any of them _are_, then before ignoring them, you
>> should ask for them to be corrected in the test suite.
>>
>> --
>> Ian Hickson   U+1047E)\._.,--,'``.fL
>> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] DFG Idom relation

[Filip Pizlo]

Sure, go ahead and submit a patch. 

-Filip

On Aug 6, 2012, at 2:11 AM, Nare Karapetyan  wrote:

> Hi. 
> What are you thinking about building idom structure in DFGDominators? I 
> suggest add  idom relation(i.e. dominators tree), since that's much used in 
> global optimizations. Isn't it ? 
> I can submit patch.
> 
> --
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] github mirror

[KwangYul Seo]

Hi, Adam.

What's the current status? Do they still have different hashes?

I am trying to push a few commits to my GitHub WebKit repo from my repo
cloned from git.webkit.org. It seems I am pushing the entire repo :(

Regards,
Kwang Yul Seo


On Mon, Apr 30, 2012 at 2:48 AM, Adam Barth  wrote:

> Tor,
>
> I think we should retire the author rewriting script on GitHub.
>
> Jame's is right that there's a lot of value in having git.webkit.org
> and GitHub using the same hashes.  For example, both Eric and Gavin
> requested that when they started using GitHub.
>
> We would have some trouble adopting the author rewriting script on
> git.webkit.org.  For example, the instructions for using git with
> WebKit  suggest
> configuring git-svn to allow you to commit from your git repository.
> When git-svn imports changes from SVN into your git repository, it
> won't know to apply the author rewriting script.  That will cause your
> local repository to diverge from an author-rewriting git.webkit.org,
> which is bad times.
>
> Therefore, it seems like the best way to synchronize the hashes
> between git.webkit.org and GitHub is to retire the author rewriting
> script on GitHub and do a non-fastforward push of the unrewritten
> repository.  That will be somewhat disruptive for folks currently
> using the GitHub repository, but at least it's only a one-time cost.
>
> Adam
>
>
> On Tue, Apr 24, 2012 at 11:06 AM, James Robinson 
> wrote:
> > On Tue, Apr 24, 2012 at 7:15 AM, Tor Arne Vestbø <
> tor.arne.ves...@nokia.com>
> > wrote:
> >> On 24.04.12 16:04, ext Shezan Baig wrote:
> >>> On Tue, Apr 24, 2012 at 9:55 AM, Adam Roben  wrote:
> > In what situation does this cause issues?
> 
> 
>  Probably the biggest issue is for people who've been using
>  git.webkit.org and now want to try out GitHub. Since the commits are
>  distinct between the two repositories, they have to do a full clone to
>  make the switch.
> >>>
> >>>
> >>>
> >>> In theory though, these users should be able to just add a remote to
> >>> their existing clone.  Then it will just sync the commit objects, and
> >>> not the trees and blobs.  Not ideal, they would have two different
> >>> 'masters', but still doable, and not *that* much of an overhead.
> >>> Switching between the different masters should also be fast since the
> >>> trees will be the same.
> >>
> >>
> >> Right, a fetch should ideally just pull down the commit objects, but it
> >> appears git does not have this optimization. If it did, I don't think
> the
> >> issue of two remote masters would be that big, since you would at some
> point
> >> likely transition to use one of the mirrors anyways. And if not, having
> >> multiple mirrors/remotes should be fine -- I'm using both the github and
> >> gitorious mirror without any issues.
> >>
> >>
> >>> But I agree these two repos should probably merge sooner rather than
> >>> later, just to avoid confusion for new users etc :)
> >>
> >>
> >> I would support that if it means cleaning up the author-script (which
> I'm
> >> happy to do), and using that on webkit.org.
> >
> >
> > Whatever we decide to do in the future, author rewriting seems like
> > extremely low value compared to having matching SHA1s.  I think we should
> > get a clone on github.com that matches the existing git.webkit.orgSHA1s and
> > then make sure that they stay in sync (either with rewriting or not, but
> > whatever webkit.org does).
> >
> > - James
> >
> >>
> >>
> >> tor arne
> >>
> >>
> >> ___
> >> 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 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/webkit-dev

Re: [webkit-dev] Trac/Svn Migration - Friday the 27th, 7-9am PDT

[Osztrogonac Csaba]

Many thanks, it works for me. ( similar to timezone settings :) )


Yuta Kitamura írta:
As a workaround, try this: log in to trac, and 
visit https://trac.webkit.org/prefs/language to change the UI language.


Apparently this preference page is hidden, but seems to work.

Thanks,
Yuta


On Mon, Aug 6, 2012 at 8:16 PM, Osztrogonac Csaba > wrote:


Hi,

With the new Trac I noticed two little bit annoying thing:

language:
--
trac.webkit.org  uses my browsers default
language. Hungarian translation
of Trac is terrible. :( Of course I could change my browsers default
language,
but it would affect all other websites too ...

Can't we make Trac to use english always? I don't think if any
developer really wants to use Trac in his/her native language.

Author name:
-
https://trac.webkit.org/__browser/trunk


As far as I remember before the update we could see the full email
addresses of the authors.
Now we can see only the email addresses before "@". It makes harder
to identify the author.

Can we get the full mail address (and/or IRC nick, full name)
somehow? (It seems we still
get full mail addresses for wiki:
https://trac.webkit.org/wiki/__WikiStart?action=history
 )

br,
Ossy

William Siegrist írta:

All done.
-Bill


On Jul 26, 2012, at 12:32 PM, William Siegrist
mailto:wsiegr...@apple.com>> wrote:

The Trac and subversion servers are being migrated to the
new hardware Friday (tomorrow) morning at 7am PDT. The whole
process should take 1-2 hours. Trac and svn will be
unavailable for most of that time.
-Bill

_
webkit-dev mailing list
webkit-dev@lists.webkit.org 
http://lists.webkit.org/__mailman/listinfo/webkit-dev





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

Re: [webkit-dev] Trac/Svn Migration - Friday the 27th, 7-9am PDT

[Yuta Kitamura]

As a workaround, try this: log in to trac, and visit
https://trac.webkit.org/prefs/language to change the UI language.

Apparently this preference page is hidden, but seems to work.

Thanks,
Yuta


On Mon, Aug 6, 2012 at 8:16 PM, Osztrogonac Csaba wrote:

> Hi,
>
> With the new Trac I noticed two little bit annoying thing:
>
> language:
> --
> trac.webkit.org uses my browsers default language. Hungarian translation
> of Trac is terrible. :( Of course I could change my browsers default
> language,
> but it would affect all other websites too ...
>
> Can't we make Trac to use english always? I don't think if any
> developer really wants to use Trac in his/her native language.
>
> Author name:
> -
> https://trac.webkit.org/**browser/trunk
>
> As far as I remember before the update we could see the full email
> addresses of the authors.
> Now we can see only the email addresses before "@". It makes harder to
> identify the author.
>
> Can we get the full mail address (and/or IRC nick, full name) somehow? (It
> seems we still
> get full mail addresses for wiki: https://trac.webkit.org/wiki/**
> WikiStart?action=history)
>
> br,
> Ossy
>
> William Siegrist írta:
>
>  All done.
>> -Bill
>>
>>
>> On Jul 26, 2012, at 12:32 PM, William Siegrist 
>> wrote:
>>
>>  The Trac and subversion servers are being migrated to the new hardware
>>> Friday (tomorrow) morning at 7am PDT. The whole process should take 1-2
>>> hours. Trac and svn will be unavailable for most of that time.
>>> -Bill
>>>
>> __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Trac/Svn Migration - Friday the 27th, 7-9am PDT

[Osztrogonac Csaba]

Hi,

With the new Trac I noticed two little bit annoying thing:

language:
--
trac.webkit.org uses my browsers default language. Hungarian translation
of Trac is terrible. :( Of course I could change my browsers default language,
but it would affect all other websites too ...

Can't we make Trac to use english always? I don't think if any
developer really wants to use Trac in his/her native language.

Author name:
-
https://trac.webkit.org/browser/trunk

As far as I remember before the update we could see the full email addresses of 
the authors.
Now we can see only the email addresses before "@". It makes harder to identify 
the author.

Can we get the full mail address (and/or IRC nick, full name) somehow? (It 
seems we still
get full mail addresses for wiki: 
https://trac.webkit.org/wiki/WikiStart?action=history )

br,
Ossy

William Siegrist írta:
All done. 


-Bill


On Jul 26, 2012, at 12:32 PM, William Siegrist  wrote:

The Trac and subversion servers are being migrated to the new hardware Friday (tomorrow) morning at 7am PDT. The whole process should take 1-2 hours. Trac and svn will be unavailable for most of that time. 


-Bill

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

Re: [webkit-dev] paged media update?

[Milian Wolff]

Hello David,

I wanted to ask whether you are still working on this? Is there a rough 
estimate on when one could start to work on paged media support?

Thanks

On Wednesday 16 May 2012 14:25:20 David Hyatt wrote:
> The difficulty with implementing paged media right now is that I'm beginning
> work on re-architecting pagination to unify columns, pages and regions. You
> can see the beginnings of this with the new multi-column classes that have
> been added to the tree.
> 
> The basic idea is that multi-column layout is being separated from
> RenderBlock and moved to a subclass, RenderMultiColumnBlock. Similar to how
> regions work, the content is represented by a flow thread and by regions
> that the flow thread is placed into. In order to avoid creating thousands
> of regions for columns, I've introduced the concept of a "region set",
> i.e., RenderMultiColumnSet.
> 
> Pages ultimately need to be rebuilt to work the same way, i.e., to have a
> RenderPageFlowThread and a RenderPageSet. Once we have actual renderers
> that represent these objects, it will be a lot easier to make real boxes
> for things like margins, headers, footers, etc. The idea is that a set
> represents a contiguous run of objects that can all be rendered
> identically. If you're forced to have a different kind of object, e.g., a
> page with a different width/height or different style, then you break up
> the RenderPageSet and have multiple sets for each (this is similar to how
> regions work by default, although I hope to apply the same optimization to
> regions eventually as well if runs of same width/height regions are
> detected that are also siblings in the render tree).
> 
> dave
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] broken build.webkit.org?

[Osztrogonac Csaba]

Hi,

Your patch is unrelated to build.webkit.org breakage. Your patch only revealed 
a bug
near watchlist. I filed a new bug for it: 
https://bugs.webkit.org/show_bug.cgi?id=93250

br,
Ossy

Gyuyoung Kim írta:

Hello Ossy,

I'm sorry. It looks  my commit made this problem. I just rolled out my
r124728 in r124738.
But, it is not adjust to buildbot first. Does anyone how to solve this
problem?

I'm sorry again.

Gyuyoung.



-Original Message-
From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
boun...@lists.webkit.org] On Behalf Of Osztrogonac Csaba
Sent: Monday, August 06, 2012 4:17 PM
To: WebKit Development
Subject: [webkit-dev] broken build.webkit.org?

Hi,

It seems something happened with build.webkit.org. The latest build
was http://trac.webkit.org/changeset/124728 on slaves. And now there
are 7-10 pending builds on each slaves, but nothing happens. I think
a master restart would solve this problem.

Bill or Lucas, could you check what happened, please?

br,
Ossy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev




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

Re: [webkit-dev] broken build.webkit.org?

[Osztrogonac Csaba]

It works again after http://build.webkit.org/changes/5632

Osztrogonac Csaba írta:

Hi,

It seems something happened with build.webkit.org. The latest build
was http://trac.webkit.org/changeset/124728 on slaves. And now there
are 7-10 pending builds on each slaves, but nothing happens. I think
a master restart would solve this problem.

Bill or Lucas, could you check what happened, please?

br,
Ossy

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

[webkit-dev] DFG Idom relation

[Nare Karapetyan]

Hi. What are you thinking about building idom structure in DFGDominators?
I suggest add  idom relation(i.e. dominators tree), since that's much
used in global optimizations. Isn't it ? I can submit patch.

-- 
You Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 4GB of Storage!

http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=116748&STATUS=MAIN
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] broken build.webkit.org?

[Gyuyoung Kim]

Hello Ossy,

I'm sorry. It looks  my commit made this problem. I just rolled out my
r124728 in r124738.
But, it is not adjust to buildbot first. Does anyone how to solve this
problem?

I'm sorry again.

Gyuyoung.


> -Original Message-
> From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
> boun...@lists.webkit.org] On Behalf Of Osztrogonac Csaba
> Sent: Monday, August 06, 2012 4:17 PM
> To: WebKit Development
> Subject: [webkit-dev] broken build.webkit.org?
> 
> Hi,
> 
> It seems something happened with build.webkit.org. The latest build
> was http://trac.webkit.org/changeset/124728 on slaves. And now there
> are 7-10 pending builds on each slaves, but nothing happens. I think
> a master restart would solve this problem.
> 
> Bill or Lucas, could you check what happened, please?
> 
> br,
> Ossy
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Enable MICRODATA feature by default

[Arko Saha]

I have filed a bug to address W3C failed test-cases :
https://bugs.webkit.org/show_bug.cgi?id=92986
This issue will track all investigation related to Microdata test failures
and make sure that we pass as many test as possible.

Regards,
Arko

On Wed, Aug 1, 2012 at 12:16 AM, Ian Hickson  wrote:

> On Tue, 31 Jul 2012, Arko Saha wrote:
> >
> > test(function () {
> > assert_equals( makeEl('div',{itemtype:' '}).itemType[0],
> > window.undefined );
> > }, 'itemType[index] must be undefined for out-of-range index');
> >
> > DOMSettableTokenList returns null for out-of-range index.
>
> This is incorrect. While it is true that item() returns null when
> called with an out-of-range index, item() is never invoked in the example
> above. See Web IDL for details.
>
> I highly doubt that the other 80+ failing tests are implementation-
> specific either. If any of them _are_, then before ignoring them, you
> should ask for them to be corrected in the test suite.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] broken build.webkit.org?

[Osztrogonac Csaba]

Hi,

It seems something happened with build.webkit.org. The latest build
was http://trac.webkit.org/changeset/124728 on slaves. And now there
are 7-10 pending builds on each slaves, but nothing happens. I think
a master restart would solve this problem.

Bill or Lucas, could you check what happened, please?

br,
Ossy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev