Re: [webkit-dev] Using C++ constant local variables in WebKit

On Wed, Nov 30, 2011 at 6:43 PM, Ryosuke Niwa wrote: > On Wed, Nov 30, 2011 at 6:26 PM, Ojan Vafai wrote: > >> On Wed, Nov 30, 2011 at 5:12 PM, Alexey Proskuryakov wrote: >> >>> >>> 30.11.2011, в 17:00, David Kilzer написал(а): >>> >>> -char* bufferStart = bufferPos; >>> +

Re: [webkit-dev] Using C++ constant local variables in WebKit

On Wed, Nov 30, 2011 at 6:26 PM, Ojan Vafai wrote: > On Wed, Nov 30, 2011 at 5:12 PM, Alexey Proskuryakov wrote: > >> >> 30.11.2011, в 17:00, David Kilzer написал(а): >> >> -char* bufferStart = bufferPos; >> +char* const bufferStart = bufferPos; >> >> >> FWIW, work

Re: [webkit-dev] Using C++ constant local variables in WebKit

On Wed, Nov 30, 2011 at 5:12 PM, Alexey Proskuryakov wrote: > > 30.11.2011, в 17:00, David Kilzer написал(а): > > -char* bufferStart = bufferPos; > +char* const bufferStart = bufferPos; > > > FWIW, working with code that parses strings is when I also always find >

[webkit-dev] EWS bots don't run when missing binary data in diff [was Re: Style bot complains of missing binary data in diff when deleting .png test results]

On Wed, Nov 30, 2011 at 5:42 PM, Alan Stearns wrote: > David, > > This is a bug where I accidentally turned on a pixel result, then needed > to remove the .pngs when I fixed the problem: > > https://bugs.webkit.org/show_bug.cgi?id=73343 > > The patch had two lines like this: > > Binary files

Re: [webkit-dev] Style bot complains of missing binary data in diff when deleting .png test results

David, This is a bug where I accidentally turned on a pixel result, then needed to remove the .pngs when I fixed the problem: https://bugs.webkit.org/show_bug.cgi?id=73343 The patch had two lines like this: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.pn

Re: [webkit-dev] Style bot complains of missing binary data in diff when deleting .png test results

Perhaps you could give a bug that has an example of what you are talking about. For me it is hard to guess at what the complaint by the style bot is. dave On Wed, Nov 30, 2011 at 5:20 PM, Alan Stearns wrote: > > If I delete a .png test result and I make a git diff without using the > --binary

[webkit-dev] Style bot complains of missing binary data in diff when deleting .png test results

If I delete a .png test result and I make a git diff without using the --binary flag, the style EWS bot complains. I can see why it would complain if I were rebasing the file - you need the binary data to see what's changed. It makes less sense to me to add the binary data to the diff if the file

Re: [webkit-dev] Using C++ constant local variables in WebKit

30.11.2011, в 17:00, David Kilzer написал(а): > -char* bufferStart = bufferPos; > +char* const bufferStart = bufferPos; FWIW, working with code that parses strings is when I also always find myself eager to use const local variables (pointers or indices). - WBR,

Re: [webkit-dev] const_iterator

On Nov 30, 2011, at 1:35 PM, David Levin wrote: > All of this seems to apply equally to const_iterator as well. I don’t think it does. > Are you mildly opposed to it as well? Or is something different about it? It seems to me that const_iterator is analogous to pointer-to-const and const membe

Re: [webkit-dev] Using C++ constant local variables in WebKit

On Nov 29, 2011, at 6:44 PM, Ryosuke Niwa wrote: > On Tue, Nov 29, 2011 at 6:42 PM, Ryosuke Niwa wrote: >> - Prevents misuse of variable in a later patch (by a different author) >> through enforcement of const-ness. > > Prevents one specific type of misuse: Setting the variable to another va

Re: [webkit-dev] [GTK] Buildslave changes

On Nov 30, 2011, at 4:34 PM, Philippe Normand wrote: > Can we get new buildbot credentials for the new slave or can we reuse > the 32-bits Debug ones? It'd be great if we can coordinate on this > migration soon :) Credentials are a slave name/password pair. If you're using the old slave name for

Re: [webkit-dev] Using C++ constant local variables in WebKit

On Tue, Nov 29, 2011 at 6:19 PM, Darin Adler wrote: > On Nov 28, 2011, at 1:38 PM, David Kilzer wrote: > > In a discussion on Bug 71921, > Antti, Darin Adler and I started a discussion about using C++ constant > pointers in WebKit. Does the WebKit c

[webkit-dev] SFX:machine-dependent optimizations

I'm investigating SFX, and find out that is doesn't support machine-dependent(for instance arm) optimizations, because of it's "macroassembler" structure. So first I want to know am I right? And second. I find out that SFX supports ARM Neon instructions set but how can I be sure that neon in

[webkit-dev] [GTK] Buildslave changes

Hi! Igalia recently purchased new hardware to improve the GTK Debug bots situation. Here's the plan: - Drop 32-bits Debug - Keep current 64-bits Debug - Add a 64-bits Release (which will run on the new hardware) A full build on the new machine takes at most 7:30 minutes and tests using NRWT run

Re: [webkit-dev] Hanging builds

On 2011-11-29, at 10:00, Adam Roben wrote: > On Nov 28, 2011, at 6:35 PM, Adam Roben wrote: > >> On Nov 26, 2011, at 3:34 AM, Nikolas Zimmermann wrote: >> >>> Good morning WebKit folks, >>> >>> I'm looking at build.webkit.org/waterfall, and see several bots which are >>> idle, but still repor

Re: [webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.

Hello. Dear Maciej Stachowiak, As Soo-Hyun mentioned, it seems Opera will take care of this feature. And these new APIs will make the Custom Handler specification more useful. So, I think we need to add these new valuable APIs into WebKit. Dear Alexey Proskuryakov, As you recommended, we've had

Re: [webkit-dev] What is the reason for changing JavaScript parser from bison parser(LR) to Top-To-Down Recursion parser?

I'm sorry, but this thread is somewhat off-topic for this mailing list. If you have a patch that implements an LR parser that is faster than our current parser, please feel encouraged to upload it to bugs.webkit.org together with benchmark scores. Discussion of the theoretical advantages or disad

Re: [webkit-dev] What is the reason for changing JavaScript parser from bison parser(LR) to Top-To-Down Recursion parser?

Thanks for your advice. Do you mean that auto-generated bison parser is implemented more complex than handwritten parser. So, although LR parser is faster than Top-To-Down parser, handwritten which implements Top-To-Down parser is faster than bison parser. At 2011-11-30 16:04:15,"Konstantin

Re: [webkit-dev] What is the reason for changing JavaScript parser from bison parser(LR) to Top-To-Down Recursion parser?

30.11.2011, 12:00, "PandaCanFly" : > In my opinion, the bison parser implements LR analyzer, handwritten parser > implements Top-To-Down analyzer. I remember some compiling book says "LR > analyzer is better and faster than Top-To-Down analyzer". IMHO, this phrase doesn't mean that *any* LR anal

Re: [webkit-dev] What is the reason for changing JavaScript parser from bison parser(LR) to Top-To-Down Recursion parser?

In my opinion, the bison parser implements LR analyzer, handwritten parser implements Top-To-Down analyzer. I remember some compiling book says "LR analyzer is better and faster than Top-To-Down analyzer". So, your opinon confuses me. Could you give me more information about speed of handwritten

Re: [webkit-dev] What is the reason for changing JavaScript parser from bison parser(LR) to Top-To-Down Recursion parser?

The handwritten parser has numerous benefits over the old bison generated one, the most basic being: * It's more than 2 times faster than the bison parser * It doesn't require complete duplication of the grammar to support strict mode (and can identify strict mode in the first place) * It fixe