Re: [webkit-dev] StyleBuilder vs StyleResolver

[Ryosuke Niwa]

On Thu, Apr 11, 2013 at 9:36 PM, Dirk Schulze  wrote:

> The style of CSS properties is either set in StyleBuilder/CSSProperty or
> in StyleResolver (alias CSSStyleSelector).
>
> StyleResolver has a giant switch statement to handle all CSS property
> values and set the style. It is the historical way to build the style.
>
> StyleBuilder was introduced ~2 years ago. Instead of a giant switch to
> handle all property styles, it has a concept of template to combine CSS
> property handling.


> In these last two years new properties were mainly added to StyleBuilder,
> older properties were left alone in StyleResolver. The concept of
> StyleBuilder was always controversial[1][2]. A lot of people had concerns
> that StyleBuilder is less readable and makes it harder to understand the
> code.
>
> I personally am more worried that we still have two ways to set the style.
> I think it is bad to keep half of the properties in StyleResolver and the
> other half in StyleBuilder. We may use the general "spring cleanup" to
> revalidate the concept of StyleBuilder and StyleResolver and decide to use
> the one or the other concept.
>
> Any thoughts?
>

My thought is that StyleBuilder is a bad idea (in terms of hackability,
readability, performance, etc...), and we should get rid of it in the favor
of the giant switch statement we all love.

I would be posting a patch to do this if I wasn't busy doing all other
stuff like migrating EWS and fixing editing bugs.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] StyleBuilder vs StyleResolver

[Benjamin Poulain]

On Thu, Apr 11, 2013 at 9:36 PM, Dirk Schulze  wrote:

> The style of CSS properties is either set in StyleBuilder/CSSProperty or
> in StyleResolver (alias CSSStyleSelector).
>
> StyleResolver has a giant switch statement to handle all CSS property
> values and set the style. It is the historical way to build the style.
>
> StyleBuilder was introduced ~2 years ago. Instead of a giant switch to
> handle all property styles, it has a concept of template to combine CSS
> property handling.
>
> In these last two years new properties were mainly added to StyleBuilder,
> older properties were left alone in StyleResolver. The concept of
> StyleBuilder was always controversial[1][2]. A lot of people had concerns
> that StyleBuilder is less readable and makes it harder to understand the
> code.
>
> I personally am more worried that we still have two ways to set the style.
> I think it is bad to keep half of the properties in StyleResolver and the
> other half in StyleBuilder. We may use the general "spring cleanup" to
> revalidate the concept of StyleBuilder and StyleResolver and decide to use
> the one or the other concept.
>
> Any thoughts?
>

I agree with you this is an issue.

It would be great to remove StyleBuilder's bazillion classes or at least
change it to something a little more sane.
Are you volunteering to experiment with this? :)

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

[webkit-dev] StyleBuilder vs StyleResolver

[Dirk Schulze]

Hi,

The style of CSS properties is either set in StyleBuilder/CSSProperty or in 
StyleResolver (alias CSSStyleSelector). 

StyleResolver has a giant switch statement to handle all CSS property values 
and set the style. It is the historical way to build the style.

StyleBuilder was introduced ~2 years ago. Instead of a giant switch to handle 
all property styles, it has a concept of template to combine CSS property 
handling.

In these last two years new properties were mainly added to StyleBuilder, older 
properties were left alone in StyleResolver. The concept of StyleBuilder was 
always controversial[1][2]. A lot of people had concerns that StyleBuilder is 
less readable and makes it harder to understand the code.

I personally am more worried that we still have two ways to set the style. I 
think it is bad to keep half of the properties in StyleResolver and the other 
half in StyleBuilder. We may use the general "spring cleanup" to revalidate the 
concept of StyleBuilder and StyleResolver and decide to use the one or the 
other concept.

Any thoughts?

Greetings,
Dirk

[1] https://bugs.webkit.org/show_bug.cgi?id=54707
[2] https://bugs.webkit.org/show_bug.cgi?id=102844
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Buildsystem cleanup

[Salisbury, Mark]

I'm glad to see there is some interest in using CMake to build on windows.  
Using CMake has made working on Windows easier for me (thank you Patrick!)...  
somewhere on webkit.org there's a page about ideas for making life on windows 
easier and I think the CMake build system addresses a number of the concerns.

Patrick uploaded a patch (https://bugs.webkit.org/show_bug.cgi?id=72816) that 
uses a strategy of separate CMake platforms for the Apple Windows build, for 
Windows Cairo, and for Windows CE.  I think there's a lot of duplication in 
having 3 separate CMake platforms for Windows builds.

I put another patch out there which creates a single PlatformWin.  Build 
switches passed to CMake then generate the platform you want (Apple, WinCairo - 
in the future WinCE).  I'm curious for those who are interested in CMake for 
Windows builds which approach they think makes more sense.  Duplication but 
full isolation or no duplication but more opportunity to collide.  Both patches 
are still works in progress.

- Mark Salisbury

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

Re: [webkit-dev] Google-Apple WebKit infrastructure transition has been completed

[Ryosuke Niwa]

On Thu, Apr 11, 2013 at 4:31 PM, Adam Barth  wrote:

> On Thu, Apr 11, 2013 at 3:29 PM, Ryosuke Niwa  wrote:
>
>> Hello WebKittens,
>>
>> As of April 11th, 2013 10 A.M. (PST), we have completed the migration of
>> the following previously-Google-owned WebKit infrastructures and tools:
>>
>>- WebKit status server: webkit-queues.appspot.com
>>- Commit queue (now uses Mac WebKit port instead of Chromium Linux
>>port)
>>- Feeder queue
>>- Style queue
>>- webkitbot (renamed from sheriffbot)
>>- Flakiness dashboard: webkit-test-resuls.appspot.com
>>
>> ^^^ Is that a typo?  (resuls -> results)
>

Oops, that indeed is a typo. It should read webkit-test-results.appspot.com.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Google-Apple WebKit infrastructure transition has been completed

[Adam Barth]

On Thu, Apr 11, 2013 at 3:29 PM, Ryosuke Niwa  wrote:

> Hello WebKittens,
>
> As of April 11th, 2013 10 A.M. (PST), we have completed the migration of
> the following previously-Google-owned WebKit infrastructures and tools:
>
>- WebKit status server: webkit-queues.appspot.com
>- Commit queue (now uses Mac WebKit port instead of Chromium Linux
>port)
>- Feeder queue
>- Style queue
>- webkitbot (renamed from sheriffbot)
>- Flakiness dashboard: webkit-test-resuls.appspot.com
>
> ^^^ Is that a typo?  (resuls -> results)


> I want to personally thank Adam Barth, Alan Cutter, Eric Seidel, and Ojan
> Vafai for helping us make this transition.  I would have been at loss
> without their help.
>
> While tech journalists may never write an article about how well Chromium
> and non-Chromium ports collaborated over the years, this extremely smooth
> transition of the infrastructure alone demonstrates how well we work
> together.  I have a lot of positive memories of
> cross-port/cross-organizaional collaborations over the years especially as
> someone who worked for both Apple and Google.
>
> I wish you all the best of luck!
>

Thanks Ryosuke!

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

[webkit-dev] Google-Apple WebKit infrastructure transition has been completed

[Ryosuke Niwa]

Hello WebKittens,

As of April 11th, 2013 10 A.M. (PST), we have completed the migration of
the following previously-Google-owned WebKit infrastructures and tools:

   - WebKit status server: webkit-queues.appspot.com
   - Commit queue (now uses Mac WebKit port instead of Chromium Linux port)
   - Feeder queue
   - Style queue
   - webkitbot (renamed from sheriffbot)
   - Flakiness dashboard: webkit-test-resuls.appspot.com


I want to personally thank Adam Barth, Alan Cutter, Eric Seidel, and Ojan
Vafai for helping us make this transition.  I would have been at loss
without their help.

While tech journalists may never write an article about how well Chromium
and non-Chromium ports collaborated over the years, this extremely smooth
transition of the infrastructure alone demonstrates how well we work
together.  I have a lot of positive memories of
cross-port/cross-organizaional collaborations over the years especially as
someone who worked for both Apple and Google.

I wish you all the best of luck!

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Somewhat painful AppEngine transitions coming

[Ryosuke Niwa]

I've re-migrated the status server in
http://trac.webkit.org/changeset/148212.

- R. Niwa

On Wed, Apr 10, 2013 at 6:37 PM, Philip Rogers  wrote:

> Thank you for taking this on Ryosuke. It's no small task and the project
> is in your debt :)
>
> Philip
>
>
> On Wed, Apr 10, 2013 at 6:32 PM, Ryosuke Niwa  wrote:
>
>> Alan has offered us a help to migrate the status data from the old server
>> so I'm going to temporarily move EWS back to the old server until that's
>> done. Sorry for the noise and thank you for your patience.
>>
>> - R. Niwa
>>
>> On Wed, Apr 10, 2013 at 6:02 PM, Ryosuke Niwa  wrote:
>>
>>> Unfortunately, EWS is going to have to re-process all 300+ patches that
>>> are currently up for review again
>>> as there is no easy way for the status server or EWS bots to retrieve
>>> the information from the old status server.
>>>
>>> Please obsolete patches and close bugs as much as we can to reduce the
>>> work load so that EWS can catch up sooner.
>>>
>>> - R. Niwa
>>>
>>>
>>> On Wed, Apr 10, 2013 at 5:14 PM, Ryosuke Niwa  wrote:
>>>
 On Wed, Apr 10, 2013 at 4:20 PM, Ryosuke Niwa  wrote:

> Moving http://webkit-commit-queue.appspot.com is a little tricker
> because it involves moving off EWS bots as well.
>


> My current plan is to modify Bugzilla so that it'll show two sets of
> bubbles for both websites during the transition.
>

 I've done this. Now you see two set of bubbles on each patch. The first
 set (with opacity: 0.3) is from webkit-commit-queue.appspot.com, which
 is going to be turned off. The second set of bubbles is for
 webkit-queues.appspot.com.

 - R. Niwa


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

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Filip Pizlo]

On Apr 11, 2013, at 2:30 PM, Dirk Pranke  wrote:

> On Wed, Apr 10, 2013 at 1:17 PM, Filip Pizlo  wrote:
>> I.e. if you believe that (A) is not a solvable problem, then this 
>> constitutes an argument against ParallelArrays, and not against inferring 
>> that a normal array should behave like a ParallelArray.
> 
> I believe that there are a class of solvable problems for soundness, but it's 
> hard if not impossible to do it generally; that was my main concern. There 
> are certainly languages that make this problem easier, for example (Haskell, 
> J). I agree that the JIT+runtime bailout strategy you discuss gives you more 
> options here.

You're totally right, generality here is super hard.  That's why I'm skeptical 
of ParallelArrays; they don't help in solving that particular problem.

>  
>> - Adding hints to the language results in programming models that nobody 
>> uses.  Have you ever used OpenMP?
> 
> I'm familiar enough with it. I was referring to things more like "restrict", 
> "const", and "pure" which give you (or the compiler) more guarantees about 
> what it is safe to infer about the parameters and functions. I'm not sure 
> these are the same sorts of things you don't like.

I like all of those things, and believe that I could infer them in a JIT!  We 
already infer "const" for global variables and object properties that point to 
functions, since it's crucial for making method dispatch fast.  No reason why 
we couldn't do it for other properties or variables.  We just don't, yet, 
because it hasn't felt super important.  But if you have some JS code that 
would benefit from it, you should file a bug! :-)

"Pure" is not something that we infer now, but the ParallelArray work does 
infer it, the stupid way: write barrier that deoptimizes.  You don't need a 
special "ParallelArray" type to do that for closures passed to forEach(); it's 
an orthogonal thing.  We could get super crazy with this if we wanted to.  
There's a lot of work on transactional memory barriers that can infer purity 
very easily; so if the single most important thing for the web platform was 
writing parallel numerical kernels (lmao yeah right!) then this would probably 
be doable.

"Restrict" is a fun one.  Points-to analysis all of the things!  I did this 
once in a JVM, and have seen others do it, also.  It can work.  It's an 
expensive thing to do, but if we had benchmarks that did benefit from it, then 
I see no reason why not.  As an aside, aliasing in JavaScript is already easier 
to figure out than in C - once our type inference is done we will know that for 
example an access to a property called "foo" cannot alias an access to a 
property called "bar" by virtue of the fact that simple self-properties cannot 
overlap.  In C a thing called "foo" and a thing called "bar" can totally 
overlap and so you need annotations like "restrict" to help deconfuse the poor 
compiler.


>> 
>> Hope my answers help! :-)
>> 
> 
> Yes, thank you for expounding.
> 
> -- Dirk 

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

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Dirk Pranke]

On Wed, Apr 10, 2013 at 1:17 PM, Filip Pizlo  wrote:

> I.e. if you believe that (A) is not a solvable problem, then this
> constitutes an argument against ParallelArrays, and not against inferring
> that a normal array should behave like a ParallelArray.
>
> I believe that there are a class of solvable problems for soundness, but
it's hard if not impossible to do it generally; that was my main concern.
There are certainly languages that make this problem easier, for example
(Haskell, J). I agree that the JIT+runtime bailout strategy you discuss
gives you more options here.


> - Adding hints to the language results in programming models that nobody
> uses.  Have you ever used OpenMP?
>
> I'm familiar enough with it. I was referring to things more like
"restrict", "const", and "pure" which give you (or the compiler) more
guarantees about what it is safe to infer about the parameters and
functions. I'm not sure these are the same sorts of things you don't like.

>
> Hope my answers help! :-)
>
> Yes, thank you for expounding.

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

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Dirk Pranke]

On Thu, Apr 11, 2013 at 10:29 AM, Leandro Pereira wrote:

> dpranke,
>
>
> On 04/11/2013 02:12 PM, Dirk Pranke wrote:
>
>
>> I'm not sure how useful a suggestion this is, but ANTLR has a pretty
>> strong framework for separating parsing from code generation and seems
>> like it would be an ideal fit for this, except that the tool itself is
>> written in Java. Perhaps that is a show-stopper? I'm not actually aware
>> of any similar parser-generator tools that have similar architectures
>> but are in more WebKit/Blink-friendly languages, but maybe they exist?
>>
>
> Pyparsing is a nice little library that requires no code generation
> (grammar is written in pure Python) and is very simple to use.
>
> Their website lives at 
> http://pyparsing.wikispaces.**com/
> .
>
>
That's pretty much the opposite of what I was getting at (I was talking
about ANTLR's use of StringTemplate to separate code generation from the
building of the AST).

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

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Eric Seidel]

I retract my earlier statement.  I think that the constraints here
between WebKit and blink are different enough that we should only
re-examine sharing code after both projects have had a chance to
re-write this subsystem to better fit their needs.  We originally
imported these bindings generators from KDOM (and changed them quite a
bit), but I suspect that they were never really a perfect fit for
WebKit in the first place.

Since we're both theoretically parsing WebIDL here, presumably there
are several good parsers already.  If both WebKit and Blink choose the
same language to re-write their respective bindings generators in,
perhaps we'll end up using the same parser library.

Best of luck!

On Wed, Apr 10, 2013 at 3:36 PM, Eric Seidel  wrote:
> I know some folks in our TOK office have expressed strong interest in
> re-writing it in python for Blink.  Perhaps there is an opportunity
> for some x-project collaboration here.
>
> On Wed, Apr 10, 2013 at 3:32 PM, Ryosuke Niwa  wrote:
>> Hi,
>>
>> Can we rewrite CodeGenerator*.pm in Ruby or Python?  I feel that the current
>> code is very hard to understand and hack on.  In particular we have
>> CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been
>> removed), and we need to merge them anyway.
>>
>> I've seen many people expressing their inability to improve the binding code
>> because of its being written in Perl.
>>
>> I'm not necessarily volunteering to do the work myself at this moment but I
>> wanted to see if there is any interest in this idea or not.
>>
>> - R. Niwa
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Leandro Pereira]

dpranke,

On 04/11/2013 02:12 PM, Dirk Pranke wrote:



I'm not sure how useful a suggestion this is, but ANTLR has a pretty
strong framework for separating parsing from code generation and seems
like it would be an ideal fit for this, except that the tool itself is
written in Java. Perhaps that is a show-stopper? I'm not actually aware
of any similar parser-generator tools that have similar architectures
but are in more WebKit/Blink-friendly languages, but maybe they exist?


Pyparsing is a nice little library that requires no code generation 
(grammar is written in pure Python) and is very simple to use.


Their website lives at http://pyparsing.wikispaces.com/.

Leandro


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

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Tim Mahoney]

On Apr 11, 2013, at 10:12 AM, Dirk Pranke  wrote:

> I'm not sure how useful a suggestion this is, but ANTLR has a pretty strong 
> framework for separating parsing from code generation and seems like it would 
> be an ideal fit for this…

Speaking of other tools, this might be a nice use for SWIG 
(http://www.swig.org). It could generate Objective-C bindings out of the box, 
and it looks like someone started binding it to JavaScriptCore 
(https://github.com/Neha03/gsoc2012-javascript/tree/master/Lib/javascript/jsc).

-Tim

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

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Ryosuke Niwa]

On Thu, Apr 11, 2013 at 10:12 AM, Dirk Pranke  wrote:

> On Thu, Apr 11, 2013 at 9:51 AM, Darin Adler  wrote:
>
>> On Apr 11, 2013, at 5:02 AM, Thiago Marcos P. Santos 
>> wrote:
>>
>> > Would be great if both projects could share the same generators.
>>
>> The part that would be OK to share would be the parsing.
>>
>> The actual code generation needs to change all the time as the internal
>> architecture of WebKit and of the JavaScript engine and other things we’re
>> binding change, so we should not try to change that.
>>
>>
> I'm not sure how useful a suggestion this is, but ANTLR has a pretty
> strong framework for separating parsing from code generation and seems like
> it would be an ideal fit for this, except that the tool itself is written
> in Java. Perhaps that is a show-stopper? I'm not actually aware of any
> similar parser-generator tools that have similar architectures but are in
> more WebKit/Blink-friendly languages, but maybe they exist? It certainly
> would be nice not to have to roll your own framework here.
>

We used to use Bison for CSS parsing and we might still use it somewhere.
 Having said that, C/C++ might be an overkill for writing a binding code
generator.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Dirk Pranke]

On Thu, Apr 11, 2013 at 9:51 AM, Darin Adler  wrote:

> On Apr 11, 2013, at 5:02 AM, Thiago Marcos P. Santos 
> wrote:
>
> > Would be great if both projects could share the same generators.
>
> The part that would be OK to share would be the parsing.
>
> The actual code generation needs to change all the time as the internal
> architecture of WebKit and of the JavaScript engine and other things we’re
> binding change, so we should not try to change that.
>
>
I'm not sure how useful a suggestion this is, but ANTLR has a pretty strong
framework for separating parsing from code generation and seems like it
would be an ideal fit for this, except that the tool itself is written in
Java. Perhaps that is a show-stopper? I'm not actually aware of any similar
parser-generator tools that have similar architectures but are in more
WebKit/Blink-friendly languages, but maybe they exist? It certainly would
be nice not to have to roll your own framework here.

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

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Darin Adler]

On Apr 11, 2013, at 9:51 AM, Darin Adler  wrote:

> The actual code generation needs to change all the time as the internal 
> architecture of WebKit and of the JavaScript engine and other things we’re 
> binding change, so we should not try to change that.

I meant “we should not try to share that or have it live outside the main 
project”.

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

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Darin Adler]

On Apr 11, 2013, at 5:02 AM, Thiago Marcos P. Santos  
wrote:

> Would be great if both projects could share the same generators.

The part that would be OK to share would be the parsing.

The actual code generation needs to change all the time as the internal 
architecture of WebKit and of the JavaScript engine and other things we’re 
binding change, so we should not try to change that.

> People writing device API bindings for web runtimes that are injected at 
> runtime could also use it.

I understand, but I think there are different requirements there.

For these things injected at runtime we’d want the API to be stable, whereas 
for inside the project we want the best possible performance even if many 
implementation details are exposed.

WebKitTestRunner does something like this, and do I think that it has 
requirements very similar to other “injected at runtime” uses.

> Would be interesting if we could have the bindings generators as a 
> separated/standalone project.

That does not sound like a good idea to me for the specific reasons I mentioned 
above.

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

[webkit-dev] unsubscribe

[Louis Meadows]

 Original Message 
Subject:Re: [webkit-dev] Debugging in Windows Port
Date:   Thu, 11 Apr 2013 06:21:18 -0700 (PDT)
From:   felixs 
To: webkit-dev@lists.webkit.org



Compile the webkit with debug version, then use the gdb to run it. set the
breakpoint in where you want to stop.



--
View this message in context: 
http://mac-os-forge.2317878.n4.nabble.com/Debugging-in-Windows-Port-tp180143p215042.html
Sent from the Webkit mailing list archive at Nabble.com.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev



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

Re: [webkit-dev] Debugging in Windows Port

[felixs]

Compile the webkit with debug version, then use the gdb to run it. set the
breakpoint in where you want to stop.



--
View this message in context: 
http://mac-os-forge.2317878.n4.nabble.com/Debugging-in-Windows-Port-tp180143p215042.html
Sent from the Webkit mailing list archive at Nabble.com.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rewriting binding code generator, maybe?

[Thiago Marcos P. Santos]

On Thu, Apr 11, 2013 at 1:36 AM, Eric Seidel  wrote:
> I know some folks in our TOK office have expressed strong interest in
> re-writing it in python for Blink.  Perhaps there is an opportunity
> for some x-project collaboration here.

Would be great if both projects could share the same generators.

People writing device API bindings for web runtimes that are injected
at runtime could also use it. Would be interesting if we could have
the bindings generators as a separated/standalone project.

Cheers,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Somewhat painful AppEngine transitions coming [Caution: Message contains Suspicious URL content]

[Adam Barth]

On Thu, Apr 11, 2013 at 12:07 AM, Ryosuke Niwa  wrote:
> On Wed, Apr 10, 2013 at 11:48 PM, Osztrogonác Csaba 
> wrote:
>> Just out of curiosity, isn't simpler deliver the ownership of
>> these apps from Google to Apple instead of starting new apps?
>
> We can't because both of them are special Google accounts.  As to why or how
> they're special, I don't think I'm allowed to say anything about it.

It's nothing mysterious.  They're just set up for internal billing.

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

Re: [webkit-dev] Somewhat painful AppEngine transitions coming [Caution: Message contains Suspicious URL content]

[Ryosuke Niwa]

On Wed, Apr 10, 2013 at 11:48 PM, Osztrogonác Csaba wrote:

> Just out of curiosity, isn't simpler deliver the ownership of
> these apps from Google to Apple instead of starting new apps?
>

We can't because both of them are special Google accounts.  As to why or
how they're special, I don't think I'm allowed to say anything about it.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev