At least the test-results.appspot.com instance is also used by chromium and
blink bots.
best
-jochen
On Thu, Apr 11, 2013 at 8:48 AM, Osztrogonác Csaba wrote:
> Hi,
>
> Just out of curiosity, isn't simpler deliver the ownership of
> these apps from Google to Apple instead of starting new apps?
Hi,
Just out of curiosity, isn't simpler deliver the ownership of
these apps from Google to Apple instead of starting new apps?
Ossy
Ryosuke Niwa írta:
Hi,
I've started moving Google owned http://test-results.appspot.com
and http://webkit-commit-queue.appspot.com to Apple
owned http://webki
Hi Patrick,
On Apr 10, 2013, at 8:12 PM, Patrick Gansterer wrote:
[snip]
>> 1. There's also the Wx port, but they don't seem very interested in
>> switching and it seems the build system is very low maintenance.
>
> There is still a patch at webkit.org/b/73100 for adding CMake files for Wx.
Th
Am 11.04.2013 um 00:30 schrieb Roger Fong:
> Hi Patrick,
> A few questions I have about the CMake system, being someone who's never used
> it before.
>
> -I would like to keep all of the unified properties settings that the VS2010
> property sheets hierarchy provided.
> Can we still maintain th
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 unti
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 go
If a rewrite does happen, it would be nice to have some generic functionality
abstracted away from the specific language generators. For example, the
function to add an #include statement to the generated implementation file is
currently replicated for every language. JS and V8 have "AddToImplIn
On Apr 10, 2013, at 8:17 PM, Kentaro Hara wrote:
> Now that JSC is the only engine in WebKit and V8 is the only engine in V8, we
> both can remove a bunch of unnecessary abstractions and IDL attributes that
> had existed to share code between JSC and V8. In short-term, this kind of
> clean-up
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
lo
>
> I've seen many people expressing their inability to improve the binding
> code because of its being written in Perl.
Although I agree that the complexity of the binding code partly comes from
the fact that it's written in Perl, another big reason is that current code
generators are more compl
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.
On Wed, Apr 10, 2013 at 4:59 PM, Timothy Hatcher wrote:
>
> On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa wrote:
>
> 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 CodeGenerator
As a person who does not know any of Perl, Python or Ruby very well, I find
unfamiliar Python the easiest to understand (even though I have more experience
with Perl). I feel this would be worthwhile, if not necessarily a top priority.
I do hope that this could be done without undue increase in
On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa wrote:
> 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
this is kind of what 'bind' is for, no?
it's a little wordy, but you can just pass:
console.log.bind(console)
instead of the closure.
its been around quite a while:
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Function/bind
personally as a web dev, it would frus
On Apr 10, 2013, at 3:02 PM, Victor Costan wrote:
> Dear WebKit devs,
>
>
> I would like to make console.log and related functions work without
> requiring that "this" is set to the console object. This would make
> debugging from Web Inspector easier, because console.log could be
> passed dir
>
> I know some folks in our TOK office have expressed strong interest
> in re-writing it in python for Blink.
Yeah, I'm planning (but in low priority) to rewrite it in Python after
cleaning up IDLs and code generators. The difficulty is that
CodeGenerator*.pm are not the only target for rewritin
Hi,
I've started moving Google owned http://test-results.appspot.com and
http://webkit-commit-queue.appspot.com to Apple owned
http://webkit-test-results.appspot.com and
http://webkit-queues.appspot.comrespectively.
Ojan and I have already moved the flakiness dashboard to
http://webkit-test-resul
On Wed, Apr 10, 2013 at 3:30 PM, Roger Fong wrote:
> If my above concerns can be resolved and the example you posted works fine
> for us (I'll try to take a look at it soon), it's probably okay to start
> checking in stuff to get ready for the move to CMake. I don't think we
> really have the reso
Hi everyone:
Sent from my iPhone
On Apr 10, 2013, at 3:30 PM, Roger Fong wrote:
> 2. If you're working on Windows, open up the solution with Visual Studio and
> do work as usual, unless you want to add files in which case you go through
> the CMake scripts again before moving on.
> Woul
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 fe
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 th
Hi Patrick,
A few questions I have about the CMake system, being someone who's never used
it before.
-I would like to keep all of the unified properties settings that the VS2010
property sheets hierarchy provided.
Can we still maintain that through CMake easily?
-How does CMake handle different
On Wed, Apr 10, 2013 at 3:24 PM, Victor Costan wrote:
> Thank you for the very quick response, Ryosuke!
>
> My main concerns with custom binding code is that I'd like to cover
> the related functions in console (debug, error, info, warn, dir,
> dirxml, table, trace, count), and I think something
Thank you for the very quick response, Ryosuke!
My main concerns with custom binding code is that I'd like to cover
the related functions in console (debug, error, info, warn, dir,
dirxml, table, trace, count), and I think something like LenientThis
can be useful for making other functions more de
You can also write a custom binding code instead of adding a new IDL
keyword for this specific use case.
- R. Niwa
On Wed, Apr 10, 2013 at 3:02 PM, Victor Costan wrote:
> Dear WebKit devs,
>
>
> I would like to make console.log and related functions work without
> requiring that "this" is set
Dear WebKit devs,
I would like to make console.log and related functions work without
requiring that "this" is set to the console object. This would make
debugging from Web Inspector easier, because console.log could be
passed directly to functions that require a callback, instead of
having to pa
On Apr 10, 2013, at 1:03 PM, Dirk Pranke wrote:
> Right, you need some way to ensure that the functions applied to the array
> are "pure", the array doesn't mutate, etc. I thought perhaps your
> ParallelArray() type would be ensuring this (e.g., by enforcing type checking
> and freezing the a
On Apr 10, 2013, at 1:15 PM, Filip Pizlo wrote:
>
> On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote:
>
>>
>>
>>
>> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote:
>>
>>
>> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail"
>> wrote:
>>
>> >
>> >
>> >> Why not infer ParallelArrays
On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote:
>
>
>
> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote:
>
>
> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail"
> wrote:
>
> >
> >
> >> Why not infer ParallelArrays automatically?
> > Sorry, did not get it. Could you please elaborate
Right, you need some way to ensure that the functions applied to the array
are "pure", the array doesn't mutate, etc. I thought perhaps your
ParallelArray() type would be ensuring this (e.g., by enforcing type
checking and freezing the array), but maybe I misunderstood you? Even then,
I'm not sure
I'm not sure what you mean here: a parallel array is simply an array of
numbers; there is nothing "magic" about it.
If we _really_ wanted to be blunt about it, we could simply say (in Array.map)
if (length >= giant && function.isEasyPeasy() && everything in the array is a
number)
return doHa
Right, I get how ParallelArrays would work. I was asking Filip how you
might infer that an array could be a ParallelArray.
-- Dirk
On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt wrote:
> The parallel arrays apis aren't a magic "make my code parallel" wand.
>
> They don't make general code parall
The parallel arrays apis aren't a magic "make my code parallel" wand.
They don't make general code parallel, they simply provide a bunch of functions
like map, etc where if you restrict your list of language features to a
specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3
On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote:
>
>
> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail" <
> mikhail.pozdnya...@intel.com> wrote:
>
> >
> >
> >> Why not infer ParallelArrays automatically?
> > Sorry, did not get it. Could you please elaborate?
>
> Normal JS arrays. You use the
On Apr 10, 2013, at 9:44 AM, Jarred Nicholls wrote:
> On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes wrote:
> Hi
>
> On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert wrote:
>
> Yes, leveraging multicore and the power of GPUs for general computations is
> great and very powerful but first,
On Wed, Apr 10, 2013 at 1:46 AM, Eric Seidel wrote:
> If we create an emeritus class in committers.py, we also have a whole
> bunch of old (long-webkit-retired) Apple committers/reviewers (ken,
> vicki, cblu, gramps, etc.) which should go there. :) Then the tools
> (including validate-committer-
On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes wrote:
> Hi
>
> On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert wrote:
>
>>
>> Yes, leveraging multicore and the power of GPUs for general computations
>> is great and very powerful but first, securing such kernels is hard, and
>> authoring these w
On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail"
wrote:
>
>
>> Why not infer ParallelArrays automatically?
> Sorry, did not get it. Could you please elaborate?
Normal JS arrays. You use them with pure computation. Profiler notices this.
And then the same things that you have in the Paral
Hi
On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert wrote:
>
> Yes, leveraging multicore and the power of GPUs for general computations
> is great and very powerful but first, securing such kernels is hard, and
> authoring these would be pretty brutal to most web developers, I think this
> is w
Thanks for clarification. I also agree that this is better :-)
BR,
Mikhail
From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa
[rn...@webkit.org]
Sent: Wednesday, April 10, 2013 12:38 PM
To: Pozdnyakov, Mikhail
Cc: Filip Pizlo;
On Wed, Apr 10, 2013 at 2:29 AM, Pozdnyakov, Mikhail <
mikhail.pozdnya...@intel.com> wrote:
>
>
> > Why not infer ParallelArrays automatically?
> Sorry, did not get it. Could you please elaborate?
>
> I'm not insisting on this concrete proposal, my point is just that it
> would be more safe and na
> Why not infer ParallelArrays automatically?
Sorry, did not get it. Could you please elaborate?
I'm not insisting on this concrete proposal, my point is just that it would be
more safe and natural to enhance
ECMAScript (enable parallel calculations there) rather than make developers to
int
If we create an emeritus class in committers.py, we also have a whole
bunch of old (long-webkit-retired) Apple committers/reviewers (ken,
vicki, cblu, gramps, etc.) which should go there. :) Then the tools
(including validate-committer-lists) would be less confused by their
presence in ChangeLogs
I don't know if this is in line with what you and Dmitry were thinking, but
here's what I like about a symbolic "emeritus" status: it takes care of the
possible drive-by review problem while also continuing to recognize the person
within the project. It's symbolic, and it feels nicer than just
Why not infer ParallelArrays automatically? What is the specific reason for
requiring a new type?
-Filip
On Apr 10, 2013, at 12:16 AM, "Pozdnyakov, Mikhail"
wrote:
> Hi,
>
> As far as I'm concerned WebCL would have serious security issues as it lets
> web app to provide OpenCL target code
Unrelated to Dmitry's suggestion, but since I brought up "emeritus
contributors" earlier in the thread, I should explain my usage. The
"emeritus" class proposed in the ancient webkit-reviewers thread about
sunsetting was simply to answer the fact that committers.py has two
purposes:
1. It exists
Hi,
As far as I'm concerned WebCL would have serious security issues as it lets web
app to provide OpenCL target code (which is really unsafe),
besides its using requires OpenCL knowledge and hence might be too complex for
a web developer.
Good alternative could be enabling parallel calculations
48 matches
Mail list logo
