On Fri, Jul 31, 2009 at 12:08 PM, Adam Roben aro...@apple.com wrote:
On Jul 31, 2009, at 2:59 PM, Alex Russell wrote:
After a discussion this morning about the potential for parallel CSS
layout with Erik Aarvidson, he pointed out a group at Berkeley doing
research in this area:
On Tue, Jul 28, 2009 at 3:55 PM, Oliver Hunt oli...@apple.com wrote:
Personally i like the idea of having type system/compiler enforced null
checking.
Note that eseidel's proposal is still a runtime check. One could use
template specialization to write a class that gives a compile-time error
On Tue, Jul 28, 2009 at 4:29 PM, Jozwiak, John jjozw...@qualcomm.comwrote:
Isn't the C++ reference annotation
char x;
tantamount to declaration of a pointer
char * x;
to whom NULL assignment, as detectable at compile time, is a compile-time
error?
Remember that you can't reassign a
On Sat, Jul 25, 2009 at 5:59 PM, James Cloos cl...@jhcloos.com wrote:
Do note that, pedantically speaking, int32_t is not required to be 32
bits long, just long enough to store any value which could be stored in
a 32 bit integer. Ie, it is perfectly acceptable for an arch to use a
64 bit
On Fri, Jul 24, 2009 at 12:46 PM, Darin Adler da...@apple.com wrote:
Some of our code uses types like int32_t, uint32_t, int64_t, and uint64_t.
I don’t see the point of doing this. I’d like to suggest that we always use
int where we’d otherwise use int32_t except where there is some issue of
2009/7/22 Jungshik Shin (신정식, 申政湜) js...@chromium.org
This email is to get opinions (for and against) on that in case the
bug is not noticed by many. As pointed out by ap in the bug, perhaps,
we have to bring this up in the WHATWG as well. Before I do that, it
may not be a bad idea to know
If you do not develop on Windows, you may skip to the *** Question ***
portion below.
*** PSA for Windows developers ***
Until now WebKit developers on Windows have had to use the Cygwin version of
svn, rather than a standard Windows svn, due to limitations in the WebKit
scripts, build process,
On Tue, Jul 21, 2009 at 5:06 PM, Adam Barth aba...@webkit.org wrote:
It seems like we should either be consistent and set svn:eol-style:
native in all the appropriate files or remove it from all of them.
Note that you don't always want native (at least I think you don't). For
example, in
On Mon, Jul 20, 2009 at 1:28 PM, Darin Adler da...@apple.com wrote:
My patches look like this now:
$ svn-create-patch
svn: Path '../..' ends in '..', which is unsupported for this operation
This warning was caused by a change of mine that I checked in a fix for at
noon on Friday. It
On Mon, Jul 20, 2009 at 1:55 PM, Eric Seidel esei...@google.com wrote:
It could also be from http://trac.webkit.org/changeset/45939.
Yes. Knowing Darin's repository version would help narrow this down.
I am trying different things to see if I can reproduce locally. Once I can
reproduce I
On Mon, Jul 20, 2009 at 2:03 PM, Adam Barth aba...@webkit.org wrote:
It's kind of sad that we have so many ways of finding the SVN root.
The code in that link isn't right. You need to look at the UUID to
get the right answer. See scm.py.
My update made us look at the Repository Root field
On Mon, Jul 20, 2009 at 2:11 PM, Joseph Pecoraro joepec...@gmail.comwrote:
Yes, I saw scm.py's solution literally yesterday while I was learning how
to use bugzilla-tool because I switched to git. In any case the newer
revision uses a much better approach then the one in this changelog
On Mon, Jul 20, 2009 at 2:40 PM, Peter Kasting pkast...@google.com wrote:
It looks from here like the chdir call is causing curdir() to report the
non-symbolic-link form of things. If that's true, it seems like this
workaround would work:
...
my ($newdir) = @_;
my $before = File::Spec
On Mon, Jul 20, 2009 at 2:52 PM, Darin Adler da...@apple.com wrote:
On Jul 20, 2009, at 2:50 PM, Peter Kasting wrote:
my ($newdir) = @_;
my $before = Cwd::getcwd();
chdir $newdir;
my $after = Cwd::getcwd();
That seems like it ought to work a lot better.
Yes, it does. Hooray!
Awesome
On Tue, Jul 14, 2009 at 9:24 AM, Kevin Ollivier kev...@theolliviers.comwrote:
Of course, the big question is if waf would have the same limitations as
SCons in regards to doing this, but I think it's at least worth exploring.
I'd be interested to know what limitations you guys ran into when
On Tue, Jul 14, 2009 at 11:20 AM, Brent Fulgham bfulg...@gmail.com wrote:
Do we feel that GYP is finally the right tool?
Well, unlike SCons we're actually building all our ports on top of GYP. We
never actually expanded SCons to all platforms or addressed the problems we
had with it.
But I
On Mon, Jul 13, 2009 at 10:40 AM, Darin Fisher da...@chromium.org wrote:
I'd like to propose that we add an ENABLE_FORM_VALIDATION flag (or
something similarly named). I'm writing this to webkit-dev because I want
to make sure that other new web platform features that may be in development
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt hy...@apple.com wrote:
I agree. We should formalize this as policy too in my opinion. Maybe
something time-based, e.g., if you have an implementation of a new Web
technology that is going to take (1month?) to implement, then the feature
should
On Mon, Jul 13, 2009 at 12:24 PM, Mark Mentovai m...@chromium.org wrote:
We also considered CMake, and had it demonstrably working for some of
our smaller projects as well.
BTW, Mark's list of issues with CMake is non-exhaustive (we can share more
if desired), but we're not trying to slag
On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak m...@apple.com wrote:
One belated comment on this topic. It would be neat if some port agreed to
be the guinea pig to see if gyp could plausibly work for more than Google's
ports. The Wx port probably has the lowest resources of any complete
I'm more verbose than Mike, but it seems like people are talking past each
other.
On Tue, Jul 7, 2009 at 3:25 PM, Oliver Hunt oli...@apple.com wrote:
If we see one section of the test taking dramatically longer than another
then we can assume that we have not been paying enough attention to
On Tue, Jul 7, 2009 at 5:08 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 7, 2009, at 4:19 PM, Peter Kasting wrote:
For example, the framework could compute both sums _and_ geomeans, if
people thought both were valuable.
That's a plausible thing to do, but I think there's a downside
On Sat, Jul 4, 2009 at 11:47 AM, Mike Belshe m...@belshe.com wrote:
#3: The SunSpider harness has a variance problem due to CPU power savings
modes.
This one worries me because it decreases the consistency/reproducibility of
test scores and makes it harder to compare engines or to track one
Since this seems to have become the new bikeshed, I'll chime in with my
color preference:
Reviewed by John Smith (jsm...@webkit.org)
https://bugs.webkit.org/show_bug.cgi?id=123456
Fix WebKit being not awesome enough. Make five files more awesome.
FWIW, I agree with those who desire
On Fri, Jul 3, 2009 at 10:55 AM, Darin Adler da...@apple.com wrote:
It's backwards to say that the ChangeLog is a workaround for lack of tools.
Some day we may see a tool that works so well that we’d be willing to forgo
change logs, but we need to see that tool in action first to see that it
On Mon, Jun 29, 2009 at 6:48 AM, tonikitoo (Antonio Gomes)
toniki...@gmail.com wrote:
Since it has been asked, in a soon future we will be also start the
process of trying to get WebKit/EFL [1] port also upstream'ed.
@Olivier: in terms of a new port, how would small patches fit ?
Actually, I
On Mon, Jun 22, 2009 at 7:12 AM, webkit-l...@ericbrunstad.com wrote:
Thank you very much for your reply. It was very helpful. Unfortunately,
I cannot compile your CallJS sample. It appears that the 'afxwin.h' file
is not present on my system. Is it not possible to compile your sample
with
On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiakm...@apple.com wrote:
Your proposed alternative will have different behavior. It will use the
lexical global object of the calling JavaScript function, instead of the
2009/6/15 John Abd-El-Malek j...@google.com
Yes it's possible. The Chromium port runs web views in different
processes. You can look at the design docs and source to see how it's done,
that should give you an idea of what you have to do this on different
threads.
Note that using distinct
On Thu, Jun 11, 2009 at 3:21 PM, Mark Rowe mr...@apple.com wrote:
Given what has been said so far I'm still not clear why Rietvald is a
better option than Review Board.
I think it's because we have a bunch of people who are (a) familiar with
using it and/or (b) work on it and can fix any
2009/6/11 David Jones ds...@163.com
As listed in http://code.google.com/chromium/terms.html#3rdparty ,
there're three different licenses of webkit in chrome:
BSD http://www.opensource.org/licenses/bsd-license.php/LGPL 2/LGPL
2.1http://opensource.org/licenses/lgpl-2.1.php
Why?
For the
This was a long message. I couldn't figure out what it was saying (the
length discouraged me from trying too hard). Perhaps you could summarize in
a sentence or two? It seemed like something about DOM bindings for other
languages and whether or not people care?
I also tried to look at bug
On Fri, Jun 5, 2009 at 11:43 PM, Mark Rowe mr...@apple.com wrote:
Dropping our existing practice of using Bugzilla for patch reviews is one
way of addressing this. Folding the more useful features of Rietveld in to
Bugzilla to improve Bugzilla-based patch reviews is another. We all seem to
Clarifications:
On Sat, Jun 6, 2009 at 3:02 PM, Peter Kasting pkast...@google.com wrote:
I'm not trying to be hyperbolic.
On the other hand, I could simply be flat-out wrong. Although I did re-read
Ojan's email and I don't I see him as saying there'd be a lot of actual
coding needed to try
On Fri, Jun 5, 2009 at 9:13 PM, Darren VanBuren onekop...@gmail.com wrote:
I agree that using RPC is inefficient, and that we don't want to make the
review process any more of a pain. We could also try writing our own code
review software specifically designed to work with Bugzilla, so that we
On Wed, Jun 3, 2009 at 2:12 PM, Roland Steiner rolandstei...@google.comwrote:
I am in the process of implementing ruby (text annotations, mainly used in
East-Asian text), and would welcome if folks could give me feedback on my
design document, esp. regarding the rendering/layouting:
On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner rolandstei...@google.comwrote:
However, if the consensus is that we should rather take those objects out
(Ian Hickson doesn't seem to be a fan of complex ruby, either), then of
course I can remove them from the code. The resulting object model
On Mon, May 25, 2009 at 12:49 AM, Maciej Stachowiak m...@apple.com wrote:
Now, the thing I _would_ like to change is to switch from pathless
#includes to ones with relative paths -- but that's a totally different
thread.
That I definitely wouldn't like. It would make it much more painful to
On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak m...@apple.com wrote:
On May 23, 2009, at 9:38 AM, David Kilzer wrote:
There are essentially two options here:
1. Add #if/#endif guards to entire source files, but include every file in
every build system.
2. Make each build system smart
On Fri, May 22, 2009 at 12:30 PM, Darin Adler da...@apple.com wrote:
Sadly we have not yet found a good verb for the common get or create
idiom.
My own code uses createObjectIfNeeded() and similar variants.
PK
___
webkit-dev mailing list
On Thu, May 21, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com wrote:
If you want to r- a patch for a reason, such as being too big, or having
feedback already that hasn't been addressed, that's fine. But I think it
would be a bad idea to reject patches just because they haven't been
Steve Souders, whom most of you have hopefully heard of due to his work with
YSlow etc., proposed something in one of the Chrome bug trackers that I
thought was more appropriate for WebKit in general, or perhaps HTML5 (Hixie:
CCed you so you can give feedback on where to send this).
I am pretty
On Tue, Apr 28, 2009 at 10:59 AM, Darin Adler da...@apple.com wrote:
Bug 20710: WebKit should support defer and async on script elements
https://bugs.webkit.org/show_bug.cgi?id=20710
Thanks for the link Darin, I had no idea that defer and async were already
in HTML5 :)
Steve, if you have any
2009/3/28 haithem rahmani haithem.rahm...@gmail.com
Hi all,
I noticed that webKit implements its own Gif decoder and doesn't use the
extrenal library libgif.
Safari does not use the GIF decoder in the WebKit tree, but rather uses
CoreGraphics.
Other ports, such as Chromium and the Cairo
On Mon, Feb 16, 2009 at 1:40 AM, zhenghe zhang zhenghe.zh...@gmail.comwrote:
when open a webpage, and there is a gif picture in the webpage, and
the picture doesn't play. If I click the right mouse button, and the
picture
plays.
Have you updated to the very latest sources and
On Wed, Oct 22, 2008 at 10:39 PM, Brent Fulgham [EMAIL PROTECTED] wrote:
I wanted to see if anyone had suggestions for a preferable way to address
this problem, so that I can work on getting this last group of changes
incorporated in WebKit proper for general use.
Have you looked at the work
On Fri, Oct 17, 2008 at 1:35 AM, David Hyatt [EMAIL PROTECTED] wrote:
I believe this to be one of those rare cases. Before making this
decision, however, I would like to hear from representatives for the
other WebKit ports. In the absence of any strong vendor support, I do
not believe we
On Fri, Oct 17, 2008 at 2:52 PM, David Hyatt [EMAIL PROTECTED] wrote:
It's important to recognize that if you flip the EOT switch, you're going
to end up using EOT over TTF in many cases. In fact if IE *does* in end up
skipping TTF files properly, the font you get in Chrome would actually
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Are you planning to test a specific alternate interval?
I believe Mike is raising the Chromium clamp to 4 ms.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Thu, Oct 2, 2008 at 10:00 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Here it is:
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0009.html
Thanks for writing this up, Maciej, it looks great to me.
PK
___
webkit-dev mailing
On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood [EMAIL PROTECTED]wrote:
I'd say define it as a minimum precision of 1ms, but browser
manufacturers can define any precision they wish.
OK, but that only pushes the problem space outward rather than solving it.
Make CPUs 10x faster and then
On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote:
As another drastic anecdotal step, I've turned off javascript on
Safari (my main browser) and turn to other browsers when I find a site
that requires javascript. If I don't do that, I find my Macbook Air
battery eaten away in
On Wed, Oct 1, 2008 at 10:41 PM, Mike Hommey
[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote:
Total size Potential savings
www.cnn.com: 43M
410Kwww.facebook.com:
43M
On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I consider the option of completely
replacing WebKit's URL implementation with an external dependency to
be a nonstarter.
Assume that we wound up in a world where GURL formed the basis of the WebKit
URL
On Thu, Oct 2, 2008 at 3:49 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I would rather we seriously look at a way to unfork the URL parsing code,
before discussing mechanics of how to keep it forked. We don't normally put
ifdef paths in core code in WebKit that the WebKit project is not
On Thu, Oct 2, 2008 at 5:59 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I briefly considered cases like that, but I thought it seemed simple enough
to just cancel the existing timer and start a new one. And it seemed
uncommon enough to me that it didn't need a direct affordance in the API
On Thu, Oct 2, 2008 at 6:11 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
It sounds to me like you are saying that you would not be willing to
consider using the current KURL implementation in Chrome, even it
turns out to be materially better, and it gets exposed with a low-
level interface
On Wed, Oct 1, 2008 at 4:01 PM, Eric Seidel [EMAIL PROTECTED] wrote:
enum Color {
Brown,
Red,
Blue
}
I've always been a fan of this, personally... One can use Color::Brown to
solve ambiguities if necessary, but stick with just Brown in most scenarios.
PK
On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Do we have any measurements of the performance benefit?
Copying verbatim Feng's post on this from the other thread into this one:
***
I did some performance measurement a few weeks ago. I made a version
of Chrome
On Wed, Oct 1, 2008 at 5:11 PM, Paul Pedriana [EMAIL PROTECTED] wrote:
One can use Color::Brown to solve ambiguities if necessary
That would be invalid C++. If a given compiler accepts it then the compiler
is not strictly conforming. See the C++ Standard section 7.2 and section 9.2
p1.
2008/9/30 Mike Belshe [EMAIL PROTECTED]
As for keeping the fan off - if we could keep the CPU idle a 3ms minimum
timeout loop does that resolve your concern?
Followup to my earlier post, based on this.
I realize that one reason why we (Chromium folks) have not been as concerned
about CPU
On Tue, Sep 30, 2008 at 12:17 PM, Rob Burns [EMAIL PROTECTED] wrote:
The problem is not only confined to single processor systems. As others
have mentioned the bigger problem is the waste of resources. The length of
the timeout is not the full piece of the puzzle. There's also problems with
On Tue, Sep 30, 2008 at 1:35 PM, Brady Eidson [EMAIL PROTECTED] wrote:
If we add a new well specified API that all browser vendors agree on,
everybody wins.
No; everybody who's willing and able to change wins.
Everyone else wins or loses depending on whether the new behavior is better
or
On Tue, Sep 30, 2008 at 2:50 PM, David Hyatt [EMAIL PROTECTED] wrote:
Note that these problems in Safari came from having no clamp at all. Even
Chrome has a 1ms clamp.
Right. We weren't proposing making setTimeout() unclamped; just lowering
the clamp. (And I'm sorry for using the word
On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I agree with you that web content authors should have a way to get called
back ASAP. It seems like we have three different proposals identified that
most have agreed are worth pursuing:
1) Design an improved timer
On Fri, Sep 12, 2008 at 2:10 PM, Dave Hyatt [EMAIL PROTECTED] wrote:
You know most Windows users hate that snapback behavior, right? :)
Non-scientific internal polling and internet searches (at the time I did
this) revealed a split of people who liked and disliked it. There were more
people
201 - 266 of 266 matches
Mail list logo