Thanks I will try webkit-help
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Dear WebKit Developers,
Thank you for your support in getting LLINT for MIPS accepted into trunk.
There are still a few patches that need review in order to get webkit trunk
running on MIPS:
1. DFG JIT: https://bugs.webkit.org/show_bug.cgi?id=101328
We did the changes requested by the reviewers.
On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa wrote:
> On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita wrote:
>
>> The history aside, I think it makes sense to use the export macro
>> specifically for Mac WebCore because
>>
>> - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/Web
On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa wrote:
> Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I
> thought all symbols used in Internals need to be exported there.
WebKitGTK+ does not need to export symbols from WebCore for WebKit2,
because WebCore is built as a
On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita wrote:
> The history aside, I think it makes sense to use the export macro
> specifically for Mac WebCore because
>
> - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
> separation.
> Other ports like GTK or Chromium build s
It would be nice if, in the shared library build of chromium, webcore and
perhaps the modules and platform were separate DLLs.
On Jan 31, 2013 4:15 PM, "Eric Seidel" wrote:
> I believe that it's a design mistake for WebCore to need to know
> anything about it's embedder, more than that there is a
The history aside, I think it makes sense to use the export macro
specifically for Mac WebCore because
- As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
separation.
Other ports like GTK or Chromium build single "WebKit" library which has
both WebCore and WebKit API includ
I believe that it's a design mistake for WebCore to need to know
anything about it's embedder, more than that there is a defined set of
platform APIs and callbacks which it talks to (which should be the
exact same for every embedder).
(The export dependency dates back to the WebCore/WebKit separat
31.01.2013, в 15:15, Dirk Pranke написал(а):
>> I don't have concrete examples, and I don't know how big an effect on
>> performance increasing the number of exports would have. It's something to
>> keep an eye on, not a reason to avoid trying.
>
> I'm not parsing your reply properly -- avoid
On Thu, Jan 31, 2013 at 3:12 PM, Alexey Proskuryakov wrote:
>
> 31.01.2013, в 14:57, Dirk Pranke написал(а):
>
>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>> the number of exports for each port, because it would export symbols that
>> are only needed for
On Thu, Jan 31, 2013 at 2:57 PM, Dirk Pranke wrote:
> On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov wrote:
> >
> > 31.01.2013, в 14:45, Dirk Pranke написал(а):
> >
> One thing to keep an eye on with WEBCORE_EXPORT is that it can
> increase
> the number of exports for each port,
31.01.2013, в 14:57, Dirk Pranke написал(а):
> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
> the number of exports for each port, because it would export symbols that
> are only needed for other ports.
>>>
>>> I'm not sure I understand the concern h
On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov wrote:
>
> 31.01.2013, в 14:45, Dirk Pranke написал(а):
>
One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
the number of exports for each port, because it would export symbols that
are only needed for other
31.01.2013, в 14:45, Dirk Pranke написал(а):
>>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>>> the number of exports for each port, because it would export symbols that
>>> are only needed for other ports.
>>
>
> I'm not sure I understand the concern here. Is the
On Thu, Jan 31, 2013 at 9:48 AM, Ryosuke Niwa wrote:
> On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov wrote:
>>
>>
>> 31.01.2013, в 0:17, Ryosuke Niwa написал(а):
>>
>>> I did it for WTF and JSC with kevino@.
>>> https://bugs.webkit.org/show_bug.cgi?id=72855
>>> I hope I had had time to ex
Hi Nico,
You wrote:
> I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know,
> nobody ever shipped this and nobody intents to.
Sounds good.
Ted
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/l
See
https://bugs.webkit.org/show_bug.cgi?id=61773
https://bugs.webkit.org/show_bug.cgi?id=64149
On Thu, Jan 31, 2013 at 12:36 PM, Nico Weber wrote:
> This is a lovely discussion to have every now and then :-)
>
> Maybe the file add/move/delete tool that someone wrote could land
> without xcode
This is a lovely discussion to have every now and then :-)
Maybe the file add/move/delete tool that someone wrote could land
without xcode support for now? Then the pain of moving files is
reduced to two systems (xcode and everyone else), and that's something
that's at least tractable.
Nico
On T
On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke wrote:
> On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer
> wrote:
> >
> > Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
> >
> >
> > On Jan 31, 2013, at 1:56 AM, Patrick Gansterer
> wrote:
> >
> > Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>
On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer wrote:
>
> Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
>
>
> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer wrote:
>
> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>
> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger
> wrote:
>>
>> Another
On Thursday, January 31, 2013 06:14:20 PM Patrick Gansterer wrote:
> Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
> > On Jan 31, 2013, at 1:56 AM, Patrick Gansterer wrote:
> >> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
> >>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger
> >>> wrote: An
On Thu, Jan 31, 2013 at 12:10 PM, Patrick Gansterer wrote:
>
> Am 31.01.2013 um 21:07 schrieb Dirk Pranke:
>
>> On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
>> wrote:
>>> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
On Jan 30, 2013, at 3:24 PM, Dirk Pranke wrot
Am 31.01.2013 um 21:07 schrieb Dirk Pranke:
> On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
> wrote:
>> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
>>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke wrote:
On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
> T
On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
wrote:
> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke wrote:
>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
>> >> Thanks for sharing this.
>> >>
>> >> On Jan 30, 2013,
Hi Kiran,
I'm afraid, this is not the right place to ask questions like that. Try
asking webkit-help.
On 31 January 2013 19:34, Kiran K wrote:
> HI All,
>
> I am working on QtWebKit on Media Server development. Basic Idea is to
> run Gstreamer in seperate process which acts like a Media server
On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
> On Jan 30, 2013, at 3:24 PM, Dirk Pranke wrote:
> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
> >> Thanks for sharing this.
> >>
> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel wrote:
> >>
> >> I wish we only had one
Basically WebKit runs in the event thread(main thread) of the porting(qt,gtk).
WebKit node data structures will be created and destroyed only from the
mainthread. Also WebKit's timer scheduled from the main thread. Are u running
multiple instance of webview from multiple threads? If so it shoul
30.01.2013, в 17:14, Dirk Pranke написал(а):
> CMake was originally considered a non-starter for chromium since the
> XCode and VS projects it produced didn't look or feel like native
> projects.
I think that this is the key consideration here. Whatever the pains of
modifying multiple build sy
On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov wrote:
>
> 31.01.2013, в 0:17, Ryosuke Niwa написал(а):
>
> I did it for WTF and JSC with kevino@.
>> https://bugs.webkit.org/show_bug.cgi?id=72855
>> I hope I had had time to extend the work to WebCore, which was my
>> original goal :-/
>>
>
HI All,
I am working on QtWebKit on Media Server development. Basic Idea is to run
Gstreamer in seperate process which acts like a Media server. The calls
from WebKit in MediaPlayerPrivateGStreamer.cpp are routed to Media Server
via DBUS. Media Server implements the methods in
MediaPlayerPrivateG
Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
>
> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer wrote:
>
>> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>>
>>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger
>>> wrote:
>>> Another option is to add a webkit-patch command for modifying
On Jan 31, 2013, at 1:56 AM, Patrick Gansterer wrote:
> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>
>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger wrote:
>> Another option is to add a webkit-patch command for modifying the build
>> files. That way, the syntax doesn't need to be overly
On Jan 31, 2013, at 12:49 AM, Patrick Gansterer wrote:
> Hi,
>
> Am 31.01.2013 um 09:25 schrieb Mark Rowe:
>
>>> Regarding "(b) The generated project invokes only tools that are part
>>> of the default Mac OS X install": invoking tools that are checked into
>>> the WK repo is also possible, ri
On Thu, Jan 31, 2013 at 4:16 AM, Alexis Menard wrote:
> On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel wrote:
> >
> > I wish we didn’t have to worry about platforms we couldn’t test.
> >
> > It can’t be the job of the core maintainers to care about all the
> peripheral
> > ports which contribute v
On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel wrote:
> I wish we only had one build system (it were easy to add/remove/move files).
>
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy sign for the project. Adam is not the only person who has chosen
> to empty files
On Thu, Jan 31, 2013 at 10:37 AM, Ryosuke Niwa wrote:
> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger wrote:
>
>> Another option is to add a webkit-patch command for modifying the build
>> files. That way, the syntax doesn't need to be overly human friendly. There
>> was also some attempt to w
On Thu, Jan 31, 2013 at 6:56 AM, Patrick Gansterer wrote:
> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>
> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger
> wrote:
>>
>> Another option is to add a webkit-patch command for modifying the build
>> files. That way, the syntax doesn't need to be ov
Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger wrote:
> Another option is to add a webkit-patch command for modifying the build
> files. That way, the syntax doesn't need to be overly human friendly. There
> was also some attempt to write a tool
On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger wrote:
> Another option is to add a webkit-patch command for modifying the build
> files. That way, the syntax doesn't need to be overly human friendly. There
> was also some attempt to write a tool to add files automatically:
> https://bugs.webkit.
On Thu, Jan 31, 2013 at 10:12 AM, Mark Rowe wrote:
>
> On 2013-01-31, at 00:59, Jochen Eisinger wrote:
>
>
>
> On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe wrote:
>
>>
>> On 2013-01-31, at 00:48, Adam Barth wrote:
>>
>> >>> I would consider changing or improving gyp's syntax to be on the table
>
On 2013-01-31, at 01:07, Hajime Morrita wrote:
> In my understanding, it doesn't matter whether Apple Mac port supports ninja
> or not. We could use GNU make if some meta-build system is adopted because
> Mac OS has it installed. The problem here is that the neither CMake and GYP
> isn't easy
On 2013-01-31, at 00:59, Jochen Eisinger wrote:
>
>
> On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe wrote:
>
> On 2013-01-31, at 00:48, Adam Barth wrote:
>
> >>> I would consider changing or improving gyp's syntax to be on the table
> >>> if it was needed to reach the goal.
> >>
> >> For what
In my understanding, it doesn't matter whether Apple Mac port supports
ninja or not. We could use GNU make if some meta-build system is adopted
because Mac OS has it installed. The problem here is that the neither CMake
and GYP isn't easy to adopt for reasons discussed in this thread.
My personal
On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer wrote:
> Hi,
>
> Am 31.01.2013 um 09:25 schrieb Mark Rowe:
> >> CMake was originally considered a non-starter for chromium since the
> >> XCode and VS projects it produced didn't look or feel like native
> >> projects. However, we've since switche
On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe wrote:
>
> On 2013-01-31, at 00:48, Adam Barth wrote:
>
> >>> I would consider changing or improving gyp's syntax to be on the table
> >>> if it was needed to reach the goal.
> >>
> >> For what it’s worth, I also find the gyp syntax to be unpleasant. It
On 2013-01-31, at 00:48, Adam Barth wrote:
>>> I would consider changing or improving gyp's syntax to be on the table
>>> if it was needed to reach the goal.
>>
>> For what it’s worth, I also find the gyp syntax to be unpleasant. It feels
>> as though it was optimized for being processed by a
Hi,
Am 31.01.2013 um 09:25 schrieb Mark Rowe:
>> CMake was originally considered a non-starter for chromium since the
>> XCode and VS projects it produced didn't look or feel like native
>> projects. However, we've since switched to ninja for most things so
>> I'm less sure how important this is n
On Thu, Jan 31, 2013 at 12:25 AM, Mark Rowe wrote:
> On 2013-01-30, at 17:14, Dirk Pranke wrote:
>> On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak wrote:
>>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke wrote:
On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
> Thanks for sharing th
On 2013-01-30, at 17:14, Dirk Pranke wrote:
> On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak wrote:
>>
>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke wrote:
>>
>>> On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
Thanks for sharing this.
On Jan 30, 2013, at 1:28 PM, Eric
On Thu, Jan 31, 2013 at 12:09 AM, Hajime Morrita wrote:
> I did it for WTF and JSC with kevino@.
> https://bugs.webkit.org/show_bug.cgi?id=72855
> I hope I had had time to extend the work to WebCore, which was my original
> goal :-/
>
> I did it through an automation but the tool was so slow and
(From the right address)
I did it for WTF and JSC with kevino@.
https://bugs.webkit.org/show_bug.cgi?id=72855
I hope I had had time to extend the work to WebCore, which was my original
goal :-/
I did it through an automation but the tool was so slow and hacky that it
was not capable for large Web
From: ext Eric Seidel mailto:e...@webkit.org>>
I wish we didn’t have to worry about platforms we couldn’t test.
It can’t be the job of the core maintainers to care about all the peripheral
ports which contribute very little core code. Our code needs to be structured
in such a manner that its
52 matches
Mail list logo
