On Nov 30, 2009, at 11:47 PM, Adam de Boor wrote:
A worker context without the thread is close to what we're after, except for
the bit about how it doesn't do network stuff or timeouts.
Errr, what? Workers can do networking, timeouts -- xhr, setTimeout,
setInterval, etc is available to
On 2009-11-30, at 23:38, Yaar Schnitman wrote:
A sitemap.xml file is a more modern way of telling Google how to crawl a site
and the traffic can be throttled in Google's webmaster tools
(http://www.google.com/webmasters/tools/).
Creating a daily script that generates sitemap.xml for
Is there any overlap there with this project:
http://code.google.com/p/wkhtmltopdf/ ?
On Nov 18, 2009, at 9:01 AM, Patrick Mueller wrote:
Sergiy Temnikov wrote:
Hi,
We are working on a new application server that uses WebKit for
server-side JavaScript execution (and remote JavaScript
On Nov 29, 2009, at 10:27 AM, Kevin Ollivier wrote:
Hi all,
The wx port is starting to look at getting proper support for complex text,
and one of the first places I started looking at was the Win and Mac port
implementations. I noticed that the complex text code in FontWin.cpp and
On Mon, Nov 30, 2009 at 8:08 PM, Maciej Stachowiak m...@apple.com wrote:
Would it be fair to say the goal for SharedScript is just to share code and
data (to reduce memory use of multiple instances of GMail), and not network
connections, timers, or other APIs based on async callbacks
On Tue, Dec 1, 2009 at 9:15 AM, Michael Davidson m...@google.com wrote:
A third improvement: When we adopt the HTML5 notification API for showing
users new mail or incoming chat notifications we will only show one
notification regardless of the number of Gmail tabs that are open. Today
each
One question about version conflicts and how they might get worse; sorry if
it's already been addressed. What happens if a user has an old version of
an application like Gmail open and then tries to open a new window to the
app, after developers have added new features? I presume the new window
Fair enough-- it sounds like SharedScript could improve things in that
sense. Though shutting down the app might now mean hunting down and
closing all the tabs that have it open, if not restarting the browser. (To
be honest, I'm not sure how many copies of Gmail I have open right now, but
I tend
Robots.txt can exclude most of the trac site, and then include the
sitemap.xml. This way you block most of the junk and only give permission to
the important file. All major search engine support sitemap.xml, and those
that don't will be blocked by robots.txt.
A script could generate sitemap.xml
Hi,
I'm using the JavaScriptCore (Mac) API to add some properties into the
javascript environment and would like to make sure that these properties are
read only from the javascript side. From the looks of the API, I thought
adding the properties with calls like this would do the trick:
This email seems like it would be better directed to webkit-help.
In general, that's not possible to create read-only properties in
JavaScript because the environment is so malleable.
Adam
On Tue, Dec 1, 2009 at 11:10 AM, Ryan Grimm gr...@xqdev.com wrote:
Hi,
I'm using the JavaScriptCore
I actually have a giant set of changes that need to be made to the
render tree dumping... many of which are outlined in comments. The
problem is it causes all the test results to have to be updated.
Right now many silly and incorrect things are being dumped right now
just for backwards
I'm sorry about that, I intended to send it to webkit-help but typed in the
wrong address.
--Ryan
On Dec 1, 2009, at 11:15 AM, Adam Barth wrote:
This email seems like it would be better directed to webkit-help.
In general, that's not possible to create read-only properties in
JavaScript
On 2009-12-01, at 11:04, Yaar Schnitman wrote:
Robots.txt can exclude most of the trac site, and then include the
sitemap.xml. This way you block most of the junk and only give permission to
the important file. All major search engine support sitemap.xml, and those
that don't will be
A worker context without the thread is close to what we're after, except for
the bit about how it doesn't do network stuff or timeouts. Fundamentally
what we need is, a place for centralizing network access and significant
amounts of application state, and sharing large amounts of code, that is
On Tue, Dec 1, 2009 at 12:11 AM, Oliver Hunt oli...@apple.com wrote:
On Nov 30, 2009, at 11:47 PM, Adam de Boor wrote:
A worker context without the thread is close to what we're after, except
for the bit about how it doesn't do network stuff or timeouts.
Errr, what? Workers can do
On Tue, 1 Dec 2009, Michael Davidson wrote:
On Mon, Nov 30, 2009 at 8:08 PM, Maciej Stachowiak m...@apple.com wrote:
Would it be fair to say the goal for SharedScript is just to share
code and data (to reduce memory use of multiple instances of GMail),
and not network connections,
On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 1 Dec 2009, Michael Davidson wrote:
No, we definitely want to share network connections. We'd like users to
be able to have an arbitrary number of Gmail windows open without
running into the browser connection limit.
On Tue, 1 Dec 2009, Michael Davidson wrote:
On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 1 Dec 2009, Michael Davidson wrote:
No, we definitely want to share network connections. We'd like users
to be able to have an arbitrary number of Gmail windows open
Sounds like a bug.
Geoff
On Dec 1, 2009, at 11:10 AM, Ryan Grimm wrote:
Hi,
I'm using the JavaScriptCore (Mac) API to add some properties into the
javascript environment and would like to make sure that these properties are
read only from the javascript side. From the looks of the API,
The urls in sitemap.xml are not patterns - there are exact urls the search
engine will retrieve.
So, you would blacklist most urls with blanket rules in robots.txt and
whitelist explicit urls in sitemap.xml. e.g. in robots.txt, blacklist
/changeset/*, and in sitemap.xml whitelist all
A common false positive in the style-queue is as follows:
Code inside a namespace should not be indented. [whitespace/indent] [4]
That's because the namespace indent rule is fairly new and its hard to
fix without touching the whole file. I don't think the style-queue
should be spamming bugs
Just to provide some history...
An intrinsic aspect of the SharedScript proposal is that scripting across
the page / sharedScript boundary should be very fast. When coming up with
the original proposal, we were careful to not require singleton semantics
that would work against that goal (by
(2).
On Dec 1, 2009, at 2:42 PM, Adam Barth wrote:
A common false positive in the style-queue is as follows:
Code inside a namespace should not be indented. [whitespace/indent]
[4]
That's because the namespace indent rule is fairly new and its hard to
fix without touching the whole file.
For (2), are we sure the relevant diff tools can isolate the real
changes to those files amid mass indentation? Most if not all can,
but I don't know about the automatic diffs that may be part of the
webkit build/release/publish process. Not that this is a deal-breaker,
but I wanted to
The pretty diff on Bugzilla knows how to show you what's changed on a
given line (e.g., whitespace).
Adam
On Tue, Dec 1, 2009 at 1:11 PM, Rudi Sherry rshe...@adobe.com wrote:
For (2), are we sure the relevant diff tools can isolate the real changes to
those files amid mass indentation? Most
On 2009-12-01, at 12:31, Yaar Schnitman wrote:
The urls in sitemap.xml are not patterns - there are exact urls the search
engine will retrieve.
They are exact URLs that the crawler will retrieve, but they in no way restrict
the set of URLs that the crawler can retrieve.
So, you would
Hi Geoff,
So I take it that I'm understanding the API correctly? I'm currently using the
WebKit framework bundled with the latest version of Safari. Should I go ahead
and file a bug report?
--Ryan
On Dec 1, 2009, at 12:28 PM, Geoffrey Garen wrote:
Sounds like a bug.
Geoff
On Dec 1,
On Dec 1, 2009, at 2:01 PM, Ryan Grimm wrote:
Hi Geoff,
So I take it that I'm understanding the API correctly? I'm
currently using the WebKit framework bundled with the latest version
of Safari. Should I go ahead and file a bug report?
Please do. Your understanding is correct, what
4) (I think it may be possible to) notice that there are other unchanged
lines that have this problem, and then just not print the error if that
occurs.
dave
On Tue, Dec 1, 2009 at 12:42 PM, Adam Barth aba...@webkit.org wrote:
A common false positive in the style-queue is as follows:
Code
On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt oli...@apple.com wrote:
All that said, Darin, Maciej and I were discussing this on IRC earlier and
it would seem that simply adding getWindowByName (or some such) would gain a
very large amount of the behaviour desired in the {Shared,
Adam's right though: unlike most of the other style changes, if we don't fix
this one all at once, only new files will ever match the style guide. This
is different than most of the other guidelines where things eventually
converge as people touch lines of the file.
On Tue, Dec 1, 2009 at 3:22
Good morning WebKit crowd,
I'd like to enable SVG FIlters support by default. This is the last
remaining piece before we can officially claim SVG 1.0/1.1 support,
in our SVG DOM implementation (through SVG requiredFeatures/
requiredExtensions functionality).
Dirk has done an amazing job,
On Tue, Dec 1, Jeremy Orlow wrote:
Adam's right though: unlike most of the other style changes, if we don't fix
this one all at once, only new files will ever match the style guide. This
is different than most of the other guidelines where things eventually
converge as people touch lines of
I'd like formal clarification about how we enforce our style guide.
On https://bugs.webkit.org/show_bug.cgi?id=31806#c5 , Yong Li was notified
that one of his patches violates a WebKit style rule (no {} on one-line
conditional bodies). He objected to the rule, and George Staikos commented
that
On 2009-12-01, at 21:43, Peter Kasting wrote:
I'd like formal clarification about how we enforce our style guide.
On https://bugs.webkit.org/show_bug.cgi?id=31806#c5 , Yong Li was notified
that one of his patches violates a WebKit style rule (no {} on one-line
conditional bodies). He
On 2009-12-01, at 21:48, Mark Rowe wrote:
On 2009-12-01, at 21:43, Peter Kasting wrote:
I'd like formal clarification about how we enforce our style guide.
On https://bugs.webkit.org/show_bug.cgi?id=31806#c5 , Yong Li was notified
that one of his patches violates a WebKit style rule
On Dec 1, 2009, at 9:43 PM, Peter Kasting wrote:
I'd like formal clarification about how we enforce our style guide.
On https://bugs.webkit.org/show_bug.cgi?id=31806#c5 , Yong Li was
notified that one of his patches violates a WebKit style rule (no {}
on one-line conditional bodies). He
38 matches
Mail list logo
