Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

2013-04-12 Thread Jarred Nicholls
Argh, sending from the right address this time.


On Fri, Apr 12, 2013 at 4:39 PM, Jarred Nicholls
jarred.nicho...@gmail.comwrote:

 On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo fpi...@apple.com wrote:


 On Apr 12, 2013, at 8:36 AM, Hudson, Rick rick.hud...@intel.com
 wrote:

  I'm assuming that we agree that JavaScript must evolve to leverage the
 hardware's power stingy parallelism.

 True, but there is also the question of how high of a priority we should
 give to this relative to other project goals, and also what opportunity
 costs are introduced from any particular implementation of parallelism that
 we choose.  What you are proposing will only work for code that performs
 non-effectful operations.  This is a limited form of parallelism, and I'm
 not sure that it's a general enough programming model to warrant adding new
 things to the platform.

  For completeness there seems to be the following approaches.
 
  1)Add nothing to the language and rely on increasingly
 sophisticated compilers to detect opportunities to safely parallelize
 computations within the current semantics.
  2)Add methods to Array that provide parallel semantics.
  3)Add syntax and keywords such as parallelFor to introduce
 parallelism.
  4)Add a parallel type (ParallelArray) and associated methods that
 provide parallel semantics.

 You forgot the obvious ones:

 5) Message passing
 6) Shared mutable memory with either threads and locks, or something
 along those lines.

 We sort of already have (5) but it is half baked; I think there is
 opportunity to improve it.

 We don't have (6).  (6) subsumes all of (1), (2), (3), (4), and (5) as it
 would allow the programmer to roll all of those primitives in JS.

 We should not reject shared mutable memory out of hand.  It is the
 prevailing technique for implementing concurrency and parallelism in the
 other languages that people use.

 
  The _nothing_ approach would have to deal with array methods, such as
 map and reduce, that have sequential semantics. For example reduce is
 really reduce right (or fold right) and these semantics defeat
 parallelization. For example the EIC signature for the function/closure
 passed to reduce assumes E === C[I] but the value E could be the result of
 previous invocation of the function.  This approach seems to be strictly
 worse than the methods approach. A similar nothing approach is to analyze
 loops to mechanically discover opportunities for parallelization. While
 there exists decades of literature that have been full of optimism the
 reality is that this approach has not achieved wide spread success.

 Part of that lack of success stems from the fact that most code that does
 things to arrays has subtle loop-carried side-effects.  The closures passed
 to ParallelArray methods could have those, also; and if they did then you
 wouldn't be able to soundly parallelize.

 You haven't convinced me that ParallelArray will be any more successful
 than the full autoparallelization approach.  You also haven't convinced me
 that it will be any more successful than other eclectic ideas, like OpenMP,
 for example.  I don't think that such annotation-based approaches have been
 particularly successful in other languages.  The languages that have seen
 the most success in parallel development are precisely those that give
 *complete* control to the programmer, such as Java, which gives you threads
 and locks combined with a sensible memory model - and allows you to craft
 your algorithm in the way that best suits your problem domain.  Why is this
 approach being rejected?

 
  The _methods_ approach side steps the semantics issue raised in the
 nothing approach but does not compose well with the original methods. For
 example Array has several inherently sequential  methods, such as push and
 pop, that do not have a reasonable parallel semantics since they force
 mutation.
  That said this approach has its proponents. Nico
 http://smallcultfollowing.com/babysteps/blog/2013/02/26/splitting-the-pjs-api/suggested
  that we add unorderedMap and unorderedReduce to indicate that the
 scheduling of the computation be unordered. While the idea is compelling on
 the surface it is likely to lead to the development of algorithms that are
 at first sequential and then hacked to make them parallel. This approach
 will impede the goal of having programmers develop parallel algorithms and
 the appropriate parallel data structures. The methods approach would miss a
 real opportunity here to move programmers away from the sequential models
 and on to parallel models.

 ParallelArray also misses this opportunity.  The only thing that
 ParallelArray does is adds methods that could have been added to Array, and
 requires you to say, when you write your code, if you want parallelization
 or not.  The only problem this solves is inferring the is it profitable to
 parallelize question.  I'm not sure that inferring the answer to this
 question is hard enough

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

2013-04-10 Thread Jarred Nicholls
On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes toniki...@webkit.org wrote:

 Hi

 On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert timb...@adobe.comwrote:


 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 what Benjamin was referring to.

 With WebCL, you are basically writing C style kernels that you load and
 run to drive the computations, initiatives like RiverTrail are more
 restrictive but way more approachable and closer to the web, exposing
 higher level primitives on top of WebCL (ParallelArray for example) and
 integrated at the language level, which makes a lot of sense.


 Security is a primary goal of WebCL, and both WebCL and OpenCL working
 groups are working together to ensure a safe parallel programming
 environment to the Web, as you can see in [1]. If you have specific
 concerns, please raise it in the Khronos working group mailing list ([2])
 or file a bug ([3]) against the draft spec.


Particularly in terms of security, WebCL is to OpenCL as WebGL is to
OpenGL.  Introducing OpenGL (i.e. WebGL) to the web had similar security
concerns, and yet...

With that said, I totally agree that using intrinsic idioms and heuristics
that is more webby would be nice.  But at some point there will be use
cases that do not translate and will require explicit developer control in
one form (WebCL) or another (new ECMAScript idioms).  Detecting and
optimizing all variations of homogenous parallelable operations seamlessly
inside the JS engine is hard, to put it mildly.



 [1]
 https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html#4
 [2] http://www.khronos.org/webcl/public-mailing-list/
 [3] https://www.khronos.org/bugzilla/enter_bug.cgi?product=WebCL

 ___
 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] Compiling WebKit up to 25% faster in Windows?

2013-03-26 Thread Jarred Nicholls
On Tue, Mar 26, 2013 at 2:37 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell brat...@opera.comwrote:

 Is this something that has been talked about in the past, and would you
 be interested in replacing the long list of directories to search for every
 include with paths (relative some good base) directly in the include
 directives?


 Using explicit paths to include files has been talked about in the past;
 e.g.
 https://lists.webkit.org/pipermail/webkit-dev/2011-November/018632.html

 The most convincing counter argument I can remember is that it'll make
 refactoring harder because you'll have to update all #include's when you
 move headers.


A few tailored scripts make that an easier job.  We're all engineers after
all.



 It would be great if we can figure out if this also improves the build
 time on Mac/Linux.


Agreed.  Somewhat apples and oranges of course, but the noticeable slow
down when compiling WebKit versus the rest of Chromium, file to file, is
enormous.  Chromium does a full path include directive from the base of the
src by convention.  I'd love to see Windows builds sped up; definitely the
biggest pain point in continuous integration.



 - 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] Compiling WebKit up to 25% faster in Windows?

2013-03-26 Thread Jarred Nicholls
On Tue, Mar 26, 2013 at 5:17 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote:

 2013/3/26 Ryosuke Niwa rn...@webkit.org:
  On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo fpi...@apple.com wrote:
 
 
  On Mar 26, 2013, at 1:40 PM, Dirk Pranke dpra...@chromium.org wrote:
 
  On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain benja...@webkit.org
  wrote:
 
  On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org
 wrote
 
  If we have consensus that we should just switch to paths relative to
  Source (or maybe a couple different options), that would be (IMO) a
 big win.
  It sounds like Daniel  co. have already done the big bang conversion.
 
 
  I think using full path would be a serious hit regarding hackability.
 
  I would rather spend some time tweaking my compiler to cache each
  directory content than waste time finding where is every single header
 I
  need to include.
 
 
  Interesting. I have the exact opposite experience, having to paw around
 to
  figure out where Font.h actually lives rather than just seeing
  WebCore/platform/graphics/Font.h.
 
  At any rate, to be clear, I would be in favor of that change but I'm not
  expecting it to happen :).
 
 
  I'm with Dirk on this.  Full path would help hackability for me.
 
  I don't use an IDE, so I'll be typing more.  But I spend more time
 reading
  code than typing code.
 
  Also we have a lot of stupid in header file naming right now.  For
 example
  the DFG calls the JSC::DFG::Node header DFGNode.h, and puts it in
  JavaScriptCore/dfg/DFGNode.h.  So we duplicate the namespacing of
  JSC::DFG::Node in both the filename and the directory name.
  Ridiculous!  If
  we had a discipline to always include using paths relative to Source,
 then
  we could just rename it to JavaScriptCore/dfg/Node.h.  That would make
 me
  happy.
 
 
  That'll make me sad because then Xcode will then find both
  WebCore/dom/Node.h and JavaScriptCode/dfg/Node.h when I type Node.h.
 
  Unfortunately, we can't name Node.h in WebCore/dom DOMNode.h because
  DOMNode.h already exists for Objective C bindings.


 IMHO, we should be favoring code readability instead of a tool's feature.

 +1 for full paths.

 -jesus


My sentiment exactly.  And I agree with Dirk and Filip, seeing full paths
improves (my) hackability and clearly shows layer dependencies (and
violations).  I'd say that it would also help people understand where
certain headers live (educational) and to know which header specifically is
being included at compile time rather than it being a guessing game.  This
is just my opinion, but its rendered through experience working in both
chromium code and webkit code.  Having a few files named the same hasn't at
all effected my ability to find the right file (Sublime Text 2), though I
understand that argument.  In fact I'm forced to learn the difference and
distinguish the locations between similarly named files in the code base;
I've found it very helpful.

Jarred



 
  - 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

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


Re: [webkit-dev] New WebKit reviewer: Gyuyoung Kim

2012-08-21 Thread Jarred Nicholls
Congrats!

On Tue, Aug 21, 2012 at 3:38 AM, Kenneth Rohde Christiansen 
kenneth.christian...@gmail.com wrote:

 I’m pleased to announce that Gyuyoung Kim is now a WebKit reviewer.

 Gyuyoung joined the WebKit team as part of an effort to port WebKit to
 the EFL platform. Since then he has taken leadership of the Samsung
 activities in WebKit trunk and helped integrating his team members in
 the community and community practices. Lately, Gyuyoung have been
 focused on adding device API's to WebKit, as well as refocusing the
 EFL efforts on WebKit2.

 Please join me in congratulating him in his new WebKit reviewer role.

 --
 Kenneth Rohde Christiansen
 Senior Engineer, WebKit, Qt, EFL
 Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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

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


Re: [webkit-dev] WebKitQt

2012-08-16 Thread Jarred Nicholls
On Thu, Aug 16, 2012 at 11:42 PM, blake fiddler blake.fidd...@gmail.comwrote:

 Hey!

 I have problem with WebKit  Qt port build.


Please address Qt related questions to the webkit-qt mailing list in the
future.


 Why you disable Qt4.x ??? As I can understand now WebkitQt works only with
 5.0 version?


You understand correct, sir.  I recommend subscribing to webkit-qt as well,
as this change was discussed.


 But Qt5 isn't stable version - it's beta.


Building WebKit from trunk is the antithesis of stable, so I hardly think
that matters.  I wouldn't dare speak for the QtWebKit team, but I'd imagine
that supporting both major versions became too cumbersome.



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

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


Re: [webkit-dev] Using namespace std

2012-05-16 Thread Jarred Nicholls
On Wed, May 16, 2012 at 3:04 PM, Anders Carlsson ander...@apple.com wrote:


 On May 16, 2012, at 9:31 AM, Darin Adler da...@apple.com wrote:

  On May 16, 2012, at 9:20 AM, Allan Sandfeld Jensen wrote:
 
  there is another conflict which is entirely our own fault. It is
 between WTF::bind and the new std::bind from C++11
 
  We should find a good solution for this. I’d suggest talking with Anders
 Carlsson about it.

 I've run into this and had to use the fully qualified WTF::bind in those
 cases.

 FWIW, I don't think we really need using directives for the std namespace
 - the fully qualified name is short enough and I like the additional
 clarity that we're calling something in the standard library.


Ditto.  After awhile, one gets used to it and I for one especially
appreciate the additional clarity that it brings when reading code in a
very large project.



 - Anders
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] Feature Announcement: Adding iframe seamless

2012-05-02 Thread Jarred Nicholls
On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak m...@apple.com wrote:


 On May 1, 2012, at 4:04 PM, Adam Barth aba...@webkit.org wrote:

  On Tue, May 1, 2012 at 3:50 PM, Maciej Stachowiak m...@apple.com wrote:
  On May 1, 2012, at 3:31 PM, Eric Seidel e...@webkit.org wrote:
  Is your goal to be able to disable the feature to prevent a late-known
  security issue?
 
  Or is your goal to universally disable seamless for a port entirely?
 
  I'm not sure I understand the difference between these. The capability
 I'm looking for is to disable the entire feature if necessary. However, I
 don't expect that any ports Apple is involved with would leave it off
 indefinitely. I hope that answers your questions.
 
  One approach to ENABLE_SEAMLESS is to put the seamless property on
  HTMLIFrameElement behind [Conditional=SEAMLESS] and then to change
  Document::mayDisplaySeamlessWithParent to always return false.  That
  should make the feature invisible to the web.  The changes to the
  layout and navigation algorithms wouldn't be ifdefed, but they'll do
  the same things they do today because the engine won't ever treat an
  iframe as seamless.

 I'm not too picky about how it's done, but I'd feel more comfortable with
 #ifdef protecting the code changes rather than if(). If the changes are so
 entangled that it's not easy to put only the changes in an ifdef, then I
 would be skeptical that they actually have no possible effect on the
 non-seamless case.


Do we not have sufficient tests to lend us more confidence in this area?


 If they aren't that entangled, then adding the right #ifdef should be
 straightforward.

 Regards,
 Maciej

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

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


Re: [webkit-dev] Feature Announcement: Adding iframe seamless

2012-05-02 Thread Jarred Nicholls
On Wed, May 2, 2012 at 2:03 PM, Maciej Stachowiak m...@apple.com wrote:


 On May 2, 2012, at 6:14 AM, Jarred Nicholls jar...@webkit.org wrote:

 On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak m...@apple.com wrote:



 I'm not too picky about how it's done, but I'd feel more comfortable with
 #ifdef protecting the code changes rather than if(). If the changes are so
 entangled that it's not easy to put only the changes in an ifdef, then I
 would be skeptical that they actually have no possible effect on the
 non-seamless case.


 Do we not have sufficient tests to lend us more confidence in this area?


 There's no amount of automated testing that would make me comfortable with
 landing a major feature today and shipping it to customers tomorrow
 (exaggerated case, but this is the kind of thing we're talking about).


I wholeheartedly agree, and agree #ifdefs provide safety in this regard.

I was speaking more towards the skepticism that the runtime conditional
checks were not adversely affecting the non-seamless case.  I would hope to
think that our automated tests were (or will be) abundant and thorough
enough to prove with some level of confidence that what Adam suggests would
work.  If that isn't the outcome, then one could argue tests are worthless
in all situations.

#ifdefs are valuable and necessary for the reasons you stated, particularly
security and bugs in new exposed features.  These things ought to be
gradually exposed, starting with explicit opt-ins.  But, aside from that
and as a separate issue really, I would hope to think that our tests
properly mitigate concern for regressions on code that is being modified.



 Nearly every significant feature has had security holes or site
 compatibility issues discovered post-landing, even if it passes all tests.
 That's why things like this need bake time; it can take from a few weeks to
 a few months of being enabled on trunk for a new feature to get really
 solid. This is not a disparagement of anyone's coding skills or test
 coverage, that's just the reality. The problems that take a while to flush
 out can often be issues due to specific sites doing unexpected and strange
 things.

 Because we don't have a centralized release schedule for WebKit, that
 means there isn't necessarily a single window that is a good time for all
 vendors to take such a risk. That is why ifdefs are valuable even if a
 feature is ready to be on by default in testing builds like WebKit
 nightlies or Chromium canary channel.

 Regards,
 Maciej


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


Re: [webkit-dev] github mirror

2012-04-24 Thread Jarred Nicholls
On Apr 24, 2012, at 9:07 AM, Adam Roben aro...@webkit.org wrote:

 On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls jar...@webkit.org wrote:
 (from correct address)
 
 On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls jar...@sencha.com wrote:
 On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann simon.hausm...@nokia.com 
 wrote:
 On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:
  Hi WebKit,
 
  I've been using a fork of the following repo:
  https://github.com/WebKit/webkit
 
  However, yesterday there was discussion on #webkit that the SHA-1 checksums
  on this repo are different from repo at git.webkit.org, which means folks
  working on both need to have both versions checked out.
 
 I believe the reason for them being different is because in the github repo 
 the
 commit author fields are resolved.
 
 Yeah that's totally it.  So svn.webkit.org = git.webkit.org = github would 
 need to be the mirroring strategy.  Sounds dicey :)
 
  
 I don't see what would be dicey about it. The svn.webkit.org - 
 git.webkit.org step is the fragile one; after that it's just a simple git 
 push to get things over to GitHub. This sounds like a pretty good approach 
 to me, though of course it will cause some havoc for people who have already 
 been doing work using the current GitHub repository.

I was being facetious.  The notion of chaining repos is always fun but 
technically you're right; it's as easy as a push, and that is more or less 
immune to errors i.e. if a push failed due to some network or server issue it 
would just push again the next commit and be back on track.

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


Re: [webkit-dev] Debugging With Xcode

2012-04-23 Thread Jarred Nicholls
On Apr 23, 2012, at 9:03 PM, Eric Seidel e...@webkit.org wrote:

 Does anyone still debug WebKit on Mac OS X with Xcode 4?
 
 
 1.  I don't know how to actually set up Xcode to point to WebKitBuild
 like it used to.
 http://www.webkit.org/building/debug.html
 Mentions a Legacy option which does not exist for me.
 
 Simon Fraser helped me set up WebKitBuild on one of my machines, but I
 don't really know how to repeat that process.
 
 
 2.  Xcode tries to Re-index WebCore, seemingly every time I open
 WebCore.xcodeproj.  This is a hour+ process on my 12-core Mac Pro!
 
 The re-indexing takes a lot of processing power, and seems to render
 both my machine, and Xcode largely unusable.
 
 
 I understand that Xcode isn't really designed for projects as large as
 WebCore, but we've made it work in the past, and I'm curious if anyone
 is still making it work?
 
 
 If the Apple folks have any suggestions or updates to
 http://www.webkit.org/building/debug.html, they would be most
 appreciated. :)
 
 Thanks!
 
 -eric
 
 Xcode 4.2.1
 Build version 4D502
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

I usually create an empty project, add the source files I care about, and then 
attach to the appropriate renderer process - but also use WebCore.xcodeproj 
directly on occasion.  I run the same version as you and once ran into an 
infinite indexing cycle, but after a swift kick from Activity Monitor, I 
haven't seen it again.  Xcode works great as a gdb front end for me.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] github mirror

2012-04-18 Thread Jarred Nicholls
Wouldn't we need to continually mirror git.webkit.org to github as well?  I
presume github is mirroring directly from svn right now.  I'd think the
out-of-sync issue would simply occur again unless we started to mirror git.
webkit.org to github instead of svn to github.

I don't know what all Git takes into account when creating the sha1 outside
of content, tree and commit meta data, so I'm unsure if doing this git.
webkit.org = github forced push would mean that future svn commits - being
mirrored to both repos in parallel - would result in identical sha1 hashes
going forward...?

Jarred

On Wed, Apr 18, 2012 at 6:53 AM, Shezan Baig shezbaig...@gmail.com wrote:

 Hi WebKit,

 I've been using a fork of the following repo:
 https://github.com/WebKit/webkit

 However, yesterday there was discussion on #webkit that the SHA-1
 checksums on this repo are different from repo at git.webkit.org, which
 means folks working on both need to have both versions checked out.

 I believe the answer to this problem is in:
 http://help.github.com/move-a-repo/

 (look at the last section titled Manual clone and push)

 Anyone in the WebKit organization on https://github.com/WebKit should
 be able to push this.  Once this is pushed, we can retire the existing repo
 on github.  This means the existing forks will be unusable, but I think it
 will be good to do this earlier rather than later, so we just have one
 repo, and this will make it easier for existing git.webkit.org users to
 switch to github.

 Thanks,
 -shez-


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


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


Re: [webkit-dev] github mirror

2012-04-18 Thread Jarred Nicholls
(from correct address)

On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls jar...@sencha.com wrote:

 On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann simon.hausm...@nokia.com
  wrote:

 On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:
  Hi WebKit,
 
  I've been using a fork of the following repo:
  https://github.com/WebKit/webkit
 
  However, yesterday there was discussion on #webkit that the SHA-1
 checksums
  on this repo are different from repo at git.webkit.org, which means
 folks
  working on both need to have both versions checked out.

 I believe the reason for them being different is because in the github
 repo the
 commit author fields are resolved.


 Yeah that's totally it.  So svn.webkit.org = git.webkit.org = github
 would need to be the mirroring strategy.  Sounds dicey :)




 Simon
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




 --
 

 *Sencha*
 Jarred Nicholls, Senior Software Architect
 @jarrednicholls
 http://twitter.com/jarrednicholls


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


Re: [webkit-dev] CMake for Apple's Windows port

2012-04-12 Thread Jarred Nicholls
On Thu, Apr 12, 2012 at 3:08 PM, Adam Treat atr...@rim.com wrote:

 If my memory serves me the problem was that Apple couldn't figure out how
 to get cmake installed on the Apple build system machine.


@WebKitMemes you're up


 
 From: webkit-dev-boun...@lists.webkit.org [
 webkit-dev-boun...@lists.webkit.org] on behalf of Dirk Pranke [
 dpra...@chromium.org]
 Sent: Thursday, April 12, 2012 2:06 PM
 To: Patrick Gansterer
 Cc: WebKit Development
 Subject: Re: [webkit-dev] CMake for Apple's Windows port

 I think this is great; I've been meaning to spend some time on the
 apple win port trying to fix the remaining bugs holding up the switch
 to NRWT, but the fact that the apple win port still uses VS2005 is
 definitely an impediment (yes, I can probably just pull the binaries
 down from a bot for my purposes, but I'd really like to be able to
 build it).

 Patrick, have you documented what all you need to install on a Win box
 in order to be able to run CMake and do the build?

 Can someone from Apple weigh in on whether switch to CMake would be
 feasible?

 -- Dirk

 On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer par...@paroga.com
 wrote:
  Hi,
 
  it's more than a year since the last discussion about the build system
 of Apple's Windows port. In the meantime I merged most of the general
 changes into the CMake files in the repository and have a working patch
 with a few CMake files at [1] as written in [2]. I don't think that it is
 ready to replace the existing vcproj files already, but I like to hear all
 points needed to do that.
  Adding CMake files for the WinCairo port (which uses the vcproj files
 too) will be very easy when the Apple version has been added.
 
  Here some benefits to the CMake version:
  1) Shared build system: The shared files are already used by the
 Blackberry, EFL and WinCE port, so only the list of platform specific files
 needs to be maintained.
  2) No dependency on cygwin [3]: The CMake build system searches for the
 Win32 version of the required executables (bison, gperf, flex, perl and
 python) like the WinCE port does already (see [4]).
  3) Less Solution targets: Some of he current vcproj files only used for
 triggering Makefiles. The vcproj generates more native vcproj files, which
 e.g. allows clicking on one of the IDL files to generate the corresponding
 files.
  4) Easy creation of Visual Studio 2010 project files [5]: Using CMake
 allows an easy transition to other (newer) Visual Studio versions, since
 every developer can choose his preferred version.
  5) It's possibe to create Makefiles: The output of the windows buildbots
 shows much unwanted messages. Using Makefiles on the bots can produce
 cleaner logs and take advantage of all cores when used with JOM [7].
 
  Would be great if people who use the current VS Solution can give the
 CMake version a try and provide some feedback about it.
 
  BTW: There is also a patch to switch Wx to CMake at [8], but it did not
 get a positive response.
 
  [1] https://bugs.webkit.org/show_bug.cgi?id=72816
  [2]
 https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html
  [3] https://bugs.webkit.org/show_bug.cgi?id=48166
  [4] http://trac.webkit.org/wiki/WinCE#Build
  [5] https://bugs.webkit.org/show_bug.cgi?id=53445
  [6]
 https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html
  [7] http://qt-project.org/wiki/jom
  [8] https://bugs.webkit.org/show_bug.cgi?id=73100
 
  -- Patrick
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from
 your system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] check-webkit-style should remind folks to update the results for run-bindings-tests

2012-04-09 Thread Jarred Nicholls
[From the correct email]

On Mon, Apr 9, 2012 at 12:26 PM, Jarred Nicholls jar...@sencha.com wrote:

 On Mon, Apr 9, 2012 at 12:18 PM, Ryosuke Niwa rn...@webkit.org wrote:

 We have discussed this before:
 https://lists.webkit.org/pipermail/webkit-dev/2011-September/017868.html

 A better change would be for us to generate the diff on EWS, and get rid
 of binding tests step from build bots since they aren't really testing
 anything. The primary use case of run-bindings-tests is to see the diff
 before/after a code generator change and it has no business running on the
 bot or in check-webkit-style.


 Either way, we concluded that running the binding tests is very quick and
 cheap, so wherever it is still effective to prevent regressions in code
 generation is fine by me; on an as-needed basis (EWS) is clearly ideal,
 rather than on all builds.



 - Ryosuke

 On Mon, Apr 9, 2012 at 6:39 AM, Vineet Chaudhary rgf...@motorola.comwrote:

  Hi All,


 It is observed that if changes are made in Codegenerator*.pm we need to
 rebase results of run-bindings-tests.

 Many times authors forgot to update these binding results.


 IMO we should add check in ./check-webkit-style  to warn/(give a chance)
 author to run run-bindings-tests if Codegenerator is modified.

 I have filed bug for this https://bugs.webkit.org/show_bug.cgi?id=83354.


 Please let me know if any suggestions to make this change.

 Thanks,
 Vineet


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



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




 --
 

 *Sencha*
 Jarred Nicholls, Senior Software Architect
 @jarrednicholls
 http://twitter.com/jarrednicholls


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


Re: [webkit-dev] trac.webkit.org is down

2012-03-19 Thread Jarred Nicholls
On Mon, Mar 19, 2012 at 8:37 AM, Mike Lawther mikelawt...@google.comwrote:

 On 19 March 2012 22:44, Alexis Menard alexis.men...@openbossa.org wrote:

 Hi,

 On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com
 wrote:
  This should be fixed now.

 trac is down today for us.


Yeah it's gotta be the server.
http://www.downforeveryoneorjustme.com/trac.webkit.org  It's 6:30am PST so
we just need to have patience.



 bugs.webkit.org is also down with this error :


 I'm also seeing them down with the same symptoms from my home connection
 in Sydney. Traceroutes appended:

 traceroute to bugs.webkit.org (17.254.20.233), 64 hops max, 52 byte
 packets
  1  192-168-1-254 (192.168.1.254)  2.607 ms  0.875 ms  0.652 ms
  2  syd-sot-ken2-bras2-lo20 (10.20.21.199)  18.653 ms  18.283 ms  18.731 ms
  3  syd-sot-ken2-csw2-tg-3-1 (202.7.214.29)  18.890 ms  18.652 ms  18.288
 ms
  4  syd-sot-ken2-crt2-ge-9-0-0 (203.29.135.173)  17.809 ms  19.238 ms
  18.143 ms
  5  te9-1.ccr02.lax04.atlas.cogentco.com (38.104.210.53)  227.246 ms
  207.515 ms  207.168 ms
  6  te0-2-0-7.ccr21.lax01.atlas.cogentco.com (154.54.24.69)  207.495 ms
 te0-3-0-7.ccr21.lax01.atlas.cogentco.com (154.54.1.9)  208.140 ms
  208.054 ms
  7  te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185)  221.802 ms
 te9-3.mpd01.sjc01.atlas.cogentco.com (154.54.25.186)  222.440 ms
 te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185)  374.174 ms
  8  38.104.134.70 (38.104.134.70)  220.819 ms  220.666 ms  220.254 ms
   9  border1.t7-1-bbnet1.sje.pnap.net (66.151.144.4)  391.199 ms  292.140
 ms  255.343 ms
 10  * * *
 11  * * *
 [etc]

 traceroute to trac.webkit.org (17.254.20.241), 64 hops max, 52 byte
 packets
  1  192-168-1-254 (192.168.1.254)  3.605 ms  0.754 ms  3.930 ms
  2  syd-sot-ken2-bras2-lo20 (10.20.21.199)  18.515 ms  18.350 ms  18.426 ms
  3  syd-sot-ken2-csw2-tg-3-1 (202.7.214.29)  19.037 ms  18.247 ms  18.236
 ms
  4  syd-sot-ken2-crt1-ge-9-0-0 (202.7.171.173)  18.632 ms  18.394 ms
  18.429 ms
  5  ix-8-3-0-0.tcore2.lvw-losangeles.as6453.net (64.86.252.125)  200.775
 ms  200.856 ms  200.622 ms
  6  xe-8-0-0.edge1.losangeles9.level3.net (4.68.62.117)  201.657 ms
  201.147 ms  200.371 ms
  7  vlan60.csw1.losangeles1.level3.net (4.69.144.62)  203.967 ms
 vlan80.csw3.losangeles1.level3.net (4.69.144.190)  200.859 ms
 vlan90.csw4.losangeles1.level3.net (4.69.144.254)  205.358 ms
  8  ae-83-83.ebr3.losangeles1.level3.net (4.69.137.41)  203.072 ms
  200.655 ms
 ae-93-93.ebr3.losangeles1.level3.net (4.69.137.45)  200.738 ms
  9  ae-3-3.ebr1.sanjose1.level3.net (4.69.132.9)  211.694 ms  211.626 ms
  212.040 ms
 10  ae-71-71.csw2.sanjose1.level3.net (4.69.153.6)  221.184 ms
 ae-61-61.csw1.sanjose1.level3.net (4.69.153.2)  211.839 ms
 ae-71-71.csw2.sanjose1.level3.net (4.69.153.6)  218.424 ms
 11  ae-41-80.car1.sanjose2.level3.net (4.69.152.139)  212.528 ms
 ae-21-60.car1.sanjose2.level3.net (4.69.152.11)  212.445 ms
 ae-31-90.car1.sanjose2.level3.net (4.69.152.203)  212.433 ms
 12  * * *
 13  * * *
  [etc]

 mike

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


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


Re: [webkit-dev] Using GitHub to Contribute to WebKit (Experimental)

2012-03-16 Thread Jarred Nicholls
On Fri, Mar 16, 2012 at 3:41 PM, Ariya Hidayat ariya.hida...@gmail.comwrote:

  See point 3  of Landing your code. Reviewer adds a link to pull
  request  in changelog.

 But now it means I have to search in two places: Bugzilla and Github,
 in case I want to look up some past issues/problems.

 In fact, Github does not a way to search for review comments.


GitHub's API has hooks/events for comments on issues  PRs to where it
would be possible to integrate WebKit's GitHub mirror with Bugzilla so that
all comments on PRs could post back to the related Bugzilla bug.  Some
convention would be necessary in the PR title or description to figure out
which bug # it relates to, and a little work would be necessary to write
out the comment into Bugzilla with some code for context (by taking the
diff that's sitting on GitHub).

Definitely work involved, but doable.







 --
 Ariya Hidayat, http://ariya.ofilabs.com
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] Git/SVN is slow

2012-03-15 Thread Jarred Nicholls
Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies.  Pings to
svn.webkit.org succeed in acceptable times however, for me.  Perhaps the
hops following ae-11-70 and ae-21-60 simple aren't able to reply with
proper ICMP packets; no real conclusion to based on that info alone, but
maybe worth passing off to the provider and/or directly to Level3.

Jarred

On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub le...@google.com wrote:

 Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates
 are dog slow :(

  6  pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230)  4.306 ms  4.966
 ms *
  7  xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153)  20.116 ms  3.031
 ms  3.056 ms
  8  ae-31-90.car1.sanjose2.level3.net (4.69.152.203)  4.316 ms
 ae-11-70.car1.sanjose2.level3.net (4.69.152.75)  4.239 ms
 ae-21-60.car1.sanjose2.level3.net (4.69.152.11)  4.545 ms
  9  * * *
 10  * * *
 11  * * *


 On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers p...@google.com wrote:

 Bill,

 I'm currently pulling from svn.webkit.org at what feels like 5kbps, and
 poor http://build.webkit.org/console hits the page refresh before it's
 even able to render to the bottom :(

 Below is a traceroute to webkit.org:
 traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte
 packets
   1  DD-WRT (192.168.2.1)  0.233 ms  0.297 ms  0.371 ms
  2  10.1.10.1 (10.1.10.1)  2.446 ms  2.445 ms  2.518 ms
  3  96.176.191.1 (96.176.191.1)  24.451 ms  25.398 ms  28.688 ms
  4  xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177)
  14.588 ms  15.541 ms  15.733 ms
  5  xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57)
  16.563 ms  16.929 ms  16.946 ms
  6  pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201)  17.967
 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125)  14.599
 ms  11.428 ms
  7  4.28.24.77 (4.28.24.77)  15.973 ms  17.858 ms  17.307 ms
  8  vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  19.688 ms
 vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126)  14.891 ms
 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  15.116 ms
  9  ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.651 ms
 ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241)  13.767 ms
 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.955 ms
 10  ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21)  34.004 ms  36.807 ms
  34.950 ms
 11  ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77)  66.601 ms  65.766
 ms  66.692 ms
 12  ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202)  78.577 ms  78.007 ms
  78.175 ms
 13  ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109)  78.594 ms  78.520
 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142)  81.371 ms
 14  ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  71.989 ms
 ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138)  77.341 ms
 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  77.662 ms
 15  ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18)  80.375 ms
 ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2)  87.895 ms
 ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10)  77.137 ms
 16  ae-31-90.car1.SanJose2.Level3.net (4.69.152.203)  77.660 ms
 ae-41-80.car1.SanJose2.Level3.net (4.69.152.139)  78.313 ms
 ae-21-60.car1.SanJose2.Level3.net (4.69.152.11)  77.746 ms
 17  * * *
 18  * * *
 19  * * *
 20  * * *
 21  * * *
 22  * * *
 23  * * *
 24  * * *
 25  * * *
 26  * * *
 27  * * *
  28  * * *
 29  * * *
 30  * * *

 Thanks for looking into this.
 Philip

 On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist 
 wsiegr...@apple.comwrote:

 Our network provider did not find anything wrong. If anyone is currently
 seeing slow download times, I would like to see a traceroute to the server.

 Thanks,
 -Bill


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



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



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


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


Re: [webkit-dev] Git/SVN is slow

2012-03-15 Thread Jarred Nicholls
Well I was just about to follow up that from the east coast on Comcast
bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s.
 That's about as fast as it's always been.  Same goes for nightly.webkit.org
.

There's a number of possible issues that would result in slow response
times and slow downloads.  E.g., it could be sheer packet loss between
carrier backbones and not necessarily tapped bandwidth.

On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa rn...@webkit.org wrote:

 I don't really think checking the latency is interesting. What's killing
 us is bandwidth. As far as I tested yesterday, the ping at my work (Google
 SF office) gives me a reasonable time as well.

 There's something that's killing our bandwidth. Does anyone know some
 tools to investigate this?

 - Ryosuke


 On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls jar...@webkit.orgwrote:

 Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies.  Pings to
 svn.webkit.org succeed in acceptable times however, for me.  Perhaps the
 hops following ae-11-70 and ae-21-60 simple aren't able to reply with
 proper ICMP packets; no real conclusion to based on that info alone, but
 maybe worth passing off to the provider and/or directly to Level3.

 Jarred


 On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub le...@google.com wrote:

 Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN
 updates are dog slow :(

  6  pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230)  4.306 ms  4.966
 ms *
  7  xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153)  20.116 ms  3.031
 ms  3.056 ms
  8  ae-31-90.car1.sanjose2.level3.net (4.69.152.203)  4.316 ms
 ae-11-70.car1.sanjose2.level3.net (4.69.152.75)  4.239 ms
 ae-21-60.car1.sanjose2.level3.net (4.69.152.11)  4.545 ms
  9  * * *
 10  * * *
 11  * * *


 On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers p...@google.com wrote:

 Bill,

 I'm currently pulling from svn.webkit.org at what feels like 5kbps,
 and poor http://build.webkit.org/console hits the page refresh before
 it's even able to render to the bottom :(

 Below is a traceroute to webkit.org:
 traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte
 packets
   1  DD-WRT (192.168.2.1)  0.233 ms  0.297 ms  0.371 ms
  2  10.1.10.1 (10.1.10.1)  2.446 ms  2.445 ms  2.518 ms
  3  96.176.191.1 (96.176.191.1)  24.451 ms  25.398 ms  28.688 ms
  4  xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177)
  14.588 ms  15.541 ms  15.733 ms
  5  xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57)
  16.563 ms  16.929 ms  16.946 ms
  6  pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201)
  17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net(68.86.93.125)  
 14.599 ms  11.428 ms
  7  4.28.24.77 (4.28.24.77)  15.973 ms  17.858 ms  17.307 ms
  8  vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  19.688 ms
 vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126)  14.891 ms
 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  15.116 ms
  9  ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.651 ms
 ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241)  13.767 ms
 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.955 ms
 10  ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21)  34.004 ms  36.807 ms
  34.950 ms
 11  ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77)  66.601 ms
  65.766 ms  66.692 ms
 12  ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202)  78.577 ms  78.007
 ms  78.175 ms
 13  ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109)  78.594 ms
  78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142)  81.371 ms
 14  ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  71.989 ms
 ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138)  77.341 ms
 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  77.662 ms
 15  ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18)  80.375 ms
 ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2)  87.895 ms
 ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10)  77.137 ms
 16  ae-31-90.car1.SanJose2.Level3.net (4.69.152.203)  77.660 ms
 ae-41-80.car1.SanJose2.Level3.net (4.69.152.139)  78.313 ms
 ae-21-60.car1.SanJose2.Level3.net (4.69.152.11)  77.746 ms
 17  * * *
 18  * * *
 19  * * *
 20  * * *
 21  * * *
 22  * * *
 23  * * *
 24  * * *
 25  * * *
 26  * * *
 27  * * *
  28  * * *
 29  * * *
 30  * * *

 Thanks for looking into this.
 Philip

 On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist wsiegr...@apple.com
  wrote:

 Our network provider did not find anything wrong. If anyone is
 currently seeing slow download times, I would like to see a traceroute to
 the server.

 Thanks,
 -Bill


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



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



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http

Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Jarred Nicholls
On Thu, Mar 8, 2012 at 7:46 AM, Sergio Villar Senin svil...@igalia.comwrote:

 En 08/03/12 13:35, Ashod Nakashian escribiu:
  WebKittens,
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and
  infrastructure, against my better judgement, I'd like to distract you
  from being productive by bringing up this topic (again).

 Please correct me if I'm wrong but IIRC the main blocker was that any
 user with an standard OS X setup should be able to start hacking on
 WebKit without having to install any additional dependency. SVN is
 shipped with OS X and git is not.


A version of git ships with Xcode, and without Xcode I don't think anyone
attempting to hack on WebKit will get very far :3



 Anyway I'd be really pleased if that move happens.

 BR

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

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


Re: [webkit-dev] git.webkit.org problem

2012-02-29 Thread Jarred Nicholls
On Wed, Feb 29, 2012 at 3:38 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Feb 29, 2012 at 11:32 AM, Lucas Forschler lforsch...@apple.comwrote:

 I am looking into improving performance of build.webkit.org.  After
 doing some initial research I feel that buildbot isn't the most efficient
 in terms of processing a large number of requests.  I believe requests are
 processed serially, and not in parallel.  The buildbot documentation
 mentions a limit to the number of slaves that can be supported, but doesn't
 give any specific numbers.  As webkit has grown, and the number of builds
 and slaves we are supporting has increased, it seems the server is showing
 signs of reaching this capacity.  We may have reached a limit on the number
 of slaves we can handle with our current configuration.


 On Chromium side, buildbot appears to leak a great amount of memory. e.g.
 we end up running out of memory at some point because buildbot keeps
 leaking some memory over time :(  Do you see the same issue on your
 buildbot?

 -Upgrades to hardware.  It's possible faster hardware could alleviate some
 problems.  It is unclear if this is really the limiting factor, or how much
 additional capacity this would provide.


 My understanding is that we use a really fast server but still experience
 a similar problem.


 -Updating the way files are transferred
 (https://bugs.webkit.org/show_bug.cgi?id=73484)


 Would it make sense to have a separate apache server, etc... for receiving
 these files? twistd doesn't appear to be a cut out for
 uploading/downloading megabytes of data.

 -Upgrade the version of buildbot. (0.8.3 - 0.8.5).
 Version 0.8.4 and higher supposedly has a threading improvement, but it's
 unclear how much it would benefit us since it looks to be mostly database
 related.


 I've been told that upgrading buildbot didn't improve the performance. But
 upgrading it to 0.8.5 is probably a good nonetheless since it fixes various
 bugs I've encountered while maintaining Chromium bots and also when I ran
 buildbot locally.

 -Investigating some kind of apache caching layer on top of buildbot


 MUST DO THIS. This will greatly reduce the latency for most people.

 -Adding a second master to the buildbot system.
 buildbot supports multi-master mode.  We could potentially split out
 build and test onto two separate masters.
  build.webkit.org and test.webkit.org ?


 build.chromium.org takes this approach. But then we won't be able to see
 both build and test step at once though... Would it make more sense to
 split per port? e.g. Apple Mac  Apple Win, Qt  Gtk, Chromium  misc or
 something along that line?


If this is pursued, then I would tend to agree with a per-port split vs a
vertical split.  But, it would mean more masters and more places to keep an
eye on when doing cross-port changes, which could get out of hand.



 - Ryosuke


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


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


Re: [webkit-dev] optimising png files in LayoutTests - an experiment

2012-01-25 Thread Jarred Nicholls
On Wed, Jan 25, 2012 at 4:57 PM, Elliot Poger epo...@google.com wrote:

 In deciding whether to just let the PNGs get shrunk over time or to do a
 pass over all of them at once, I think we should decide what we are trying
 to optimize for.  (Download time for initial checkout of the webkit tree?


For git users, the history is there and so initial checkout is not really
going to change afaik.


  Time for existing developers to update their trees?  Storage space in the
 repository?)

 I would think that, except for initial checkout of the webkit repository,
 the others would be optimized by lazily converting the files (waiting until
 we need to check in new baselines, instead of shrinking them all at once).


 On Wed, Jan 25, 2012 at 1:12 PM, Dirk Pranke dpra...@chromium.org wrote:

 I like the idea. I'm not sure I agree w/ Adam that I'd roll the code
 into DRT, insofar as I don't know how big it is and I would definitely
 want the code shared across all of the DRT implementations. I'd
 probably also do a pass over all of the existing PNGs at some point
 rather than wait for them to be updated as necessary.

 -- Dirk

 On Tue, Jan 24, 2012 at 10:43 PM, Mike Lawther mikelawt...@chromium.org
 wrote:
  Hi guys,
 
  Just thought I'd share the results of an experiment I did in optimising
 the
  png files in LayoutTests.
 
  I used a tool on Mac called ImageOptim (http://imageoptim.pornel.net/)
 which
  tries a set of different png lossless optimising tools (like pngcrush -
 I
  also downloaded and included PNGOUT). Note that this strips out some of
 the
  stuff we need, like the hash, so if doing this for real we'd have to
 watch
  out for that.
 
  My results were:
 
  Before:
  $ ls -laR LayoutTests/ | grep png$ | awk '{total = total + $5}END{print
  total}'
  1220535840
 
  Test:
  $ find LayoutTests/ | grep png$ | xargs open -a ImageOptim.app
 
  After:
  $ ls -laR LayoutTests/ | grep png$ | awk '{total = total + $5}END{print
  total, 1220535840 - total}'
  937198328 283337512
 
  So this has saved ~280MB (~23% of the original size).
 
  Based on this, it seems worthwhile to include a png optimiser somewhere
 in
  the patch upload/submit toolchain, and also (separately) to optimise the
  existing pngs.
 
  Thoughts?
 
  mike
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



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


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


Re: [webkit-dev] *.webkit.org is down

2012-01-19 Thread Jarred Nicholls
On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard
alexis.men...@openbossa.orgwrote:

 Hi,

 It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org,
 …).


I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up.



 Here in Brazil we can't access to any of them. I tried two different
 internet providers with their own DNS and I even tried google DNS with no
 luck.


Might you try OpenDNS?  208.67.222.222/208.67.220.220


 Talking to some people in #webkit it seems that not everyone is affected
 (maybe only people outside US?).

 Anyone who knows where the servers sits would mind to have a look at them?

 Thank you very much.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] Moving WTF out of JavaScriptCore

2012-01-10 Thread Jarred Nicholls
On Tue, Jan 10, 2012 at 5:41 AM, Alexis Menard
alexis.men...@openbossa.orgwrote:

 On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard
 alexis.men...@openbossa.org wrote:
  On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote:
  We've been talking about moving WTF out of JavaScriptCore for a long
  time.  We believe we're nearly there.
  https://bugs.webkit.org/show_bug.cgi?id=75673
 
  This will mean that WTF will be built as a separate static library on
 all ports.
 
  The plan is to do this move all in one piece, after work hours PST,
  when the tree is least active.
 
  It won't be the most beautiful transition (as we're likely to break at
  least one port in the process), but we'll try not to make too much of
  a mess.
 
  We believe all the ports are ready for the move, except AppleWin:
  https://bugs.webkit.org/show_bug.cgi?id=75897
 
  Once AppleWin is ready we'll schedule a date for the transition and
  announce it one this thread.
 
  Hi Eric,
 
  Is there a patch somewhere or you are still working on it? The bug
  link contains nothing.
 
  I would like to apply it here and test the Qt port so you'll get a bit
  more confidence before landing it. I believe other ports are
  interested too.

 Nevermind wtf is already a static lib for Qt :D.

 /me is going to hide himself for not opening wtf.pro for a while.


To be clear, if we're talking about moving Source/JavaScriptCore/wtf =
Source/WTF, there would still be project file changes necessary to support
that move, so testing it wouldn't hurt :)

-Jarred



 
  Thanks.
 
 
  Thanks!
 
  -eric
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 
  --
  Alexis Menard (darktears)
  Software Engineer
  INdT Recife Brazil



 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] ietestcenter tests

2012-01-10 Thread Jarred Nicholls
On Tue, Jan 10, 2012 at 5:22 PM, Adam Barth aba...@webkit.org wrote:

 Hi webkit-dev,

 As you're probably aware, our friend at Microsoft have posted a bunch
 of standards compliance tests on
 http://samples.msdn.microsoft.com/ietestcenter/.  In the spirit of
 good-natured competition, I thought we might try to get a higher score
 than the latest beta of IE10.  (WebKit's score is already higher than
 IE9, so there's not much of a challenge there.)

 I've compiled a spreadsheet of the tests we're failing:


 https://docs.google.com/spreadsheet/ccc?key=0AppchfQ5mBrEdHAtbzNvcFdfSlBBbGN0NjY1UFlLYlE

 Many of these bugs look to be pretty easy to fix, so if you're just
 starting out in WebKit or looking to learn about a new area of the
 project, these might be good places to start.  Seasoned contributors
 are also welcome, of course.  :)

 Happy hacking,
 Adam


Good deal, thanks for sharing Adam.

Jarred


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

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


Re: [webkit-dev] chromium image tests on lion

2012-01-09 Thread Jarred Nicholls
Thanks Ojan.  There is an older issue for this that I went ahead and
starred: http://code.google.com/p/chromium/issues/detail?id=101398

Thanks all for the replies.

Cheers,
Jarred

On Mon, Jan 9, 2012 at 1:41 PM, Ojan Vafai o...@chromium.org wrote:

 For those who want to follow along, I filed
 http://code.google.com/p/chromium/issues/detail?id=109637 for getting a
 Lion chromium bot running.


 On Mon, Jan 9, 2012 at 10:38 AM, Ojan Vafai o...@chromium.org wrote:

 Chromium lacks a builder for Lion, so I expect there are likely many
 failures that noone has taken the time to look into.


 On Mon, Jan 9, 2012 at 1:05 AM, Jochen Eisinger joc...@chromium.orgwrote:



 On Mon, Jan 9, 2012 at 7:47 AM, Simon Fraser simon.fra...@apple.comwrote:

 This could have been me:

 http://trac.webkit.org/changeset/104351


 That changeset does not affect the chromium port

 -jochen



 Ideally we'd turn on mock scrollbars everywhere and then regenerate all
 the results (checking for actual failures). Not sure if I'll have time to
 do that though.

 Simon

 On Jan 7, 2012, at 8:44 AM, Jarred Nicholls wrote:

  Hey all,
 
  I'm running the layout tests for chromium on lion, and pretty much
 all of them is failing.  LayoutTestHelper fails to set the generic RGB
 color profile, but after setting it manually the image diffs are very
 subtle (mostly around test rendering, but not too much on color).  Related
 to Skia change and/or just outdated expectations?
 
  Given that Lion isn't a core test runner for chromium and it's been
 red since who knows when, I suppose this is to be expected for now.
 
  Appreciate any comments so I can safely overlook this, thanks!
  Jarred
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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



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




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


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


[webkit-dev] chromium image tests on lion

2012-01-07 Thread Jarred Nicholls
Hey all,

I'm running the layout tests for chromium on lion, and pretty much all of
them is failing.  LayoutTestHelper fails to set the generic RGB color
profile, but after setting it manually the image diffs are very subtle
(mostly around test rendering, but not too much on color).  Related to Skia
change and/or just outdated expectations?

Given that Lion isn't a core test runner for chromium and it's been red
since who knows when, I suppose this is to be expected for now.

Appreciate any comments so I can safely overlook this, thanks!
Jarred
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] js-test-(pre|post).js in http tests

2011-12-19 Thread Jarred Nicholls
Any particular reason we aren't using js-test-pre and js-test-post harness
code in our http tests, other than the fact that it's additional http
resources loaded per test?

I could spend a year improving our current tests; they are completely fugly.

Thanks,
Jarred
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] js-test-(pre|post).js in http tests

2011-12-19 Thread Jarred Nicholls
On Mon, Dec 19, 2011 at 1:57 PM, Adam Klein ad...@chromium.org wrote:

 Which tests are you referring to? I've certainly written HTTP tests that
 use the JS test harness, e.g.,
 http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/filesystem/resolve-uri.html.
 Note the resources are in fact copied to a special '/js-test-resources/'
 directory to make them accessible via HTTP.


Ahh beautiful, I was unaware the resources were copied to an accessible
path prior to the test run.  A did a physical search for the files and a
poor grep for their potential use in http/tests.  Thanks Adam for the tip!



 - Adam

 On Mon, Dec 19, 2011 at 7:08 AM, Jarred Nicholls jar...@webkit.orgwrote:

 Any particular reason we aren't using js-test-pre and js-test-post
 harness code in our http tests, other than the fact that it's additional
 http resources loaded per test?

 I could spend a year improving our current tests; they are completely
 fugly.

 Thanks,
 Jarred

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



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


Re: [webkit-dev] Incremental steps towards moving WebCore/platform out of WebCore

2011-12-14 Thread Jarred Nicholls
On Thu, Dec 15, 2011 at 1:55 AM, Adam Barth aba...@webkit.org wrote:

 I was working backwards from what's going to be needed to move
 WebCore/platform out of WebCore, and it occurred to me that we'll
 probably want a separate namespace for the code once it's outside of
 WebCore, just like WTF has a separate namespace from JSC.

 It seems like introducing the new namespace before the move would be
 beneficial because it would help us sort out whatever layering
 violations we have today (as they'd become apparent because of the
 explicit mention of the WebCore namespace).

 What would be an appropriate name for the namespace?  My first
 instinct is Platform to match the name of the new directory, but I'm
 open to suggestions.


I think Platform is good.  When explaining it to an outsider, I refer to it
as the Client Interface or Port Interface.  If Platform doesn't resonate
well with everyone then maybe something around that verbiage would fit.
 But honestly I can't think of anything better than Platform.



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

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


[webkit-dev] Internal JSON Parsing

2011-12-08 Thread Jarred Nicholls
Hey webkittens,

I'm working on https://bugs.webkit.org/show_bug.cgi?id=73648 to support the
json response entity from XHR.response.  Unless I'm mistaken (the purpose
of this inquiry) we don't appear to have a VM-agnostic interface for
internal JSON parsing, i.e., straight to the parsers.  If so, what does
everyone think about adding in that basic interface?  What I'd like to
avoid is preprocessor branches directly in XHR talking to JSC and V8
directly; instead, what would be ideal I think is an interface to parse and
return a ScriptObject.

Any additional input is surely welcomed.

Thanks,
Jarred
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Internal JSON Parsing

2011-12-08 Thread Jarred Nicholls
That's precisely what I wanted to do initially.  I had conflicting feelings
on this, but my first intuition was to cache in the bindings the value
directly parsed and state managed by the respective VM.  I don't see this
value being used by a different binding layer in parallel.

On Thu, Dec 8, 2011 at 12:08 PM, Oliver Hunt oli...@apple.com wrote:

 It's not safe to use ScriptObject for values that are kept alive by JS
 objects as it leads to cycles in the collector.

 Also the cached value for an attribute should be in the binding classes,
 not the implementation classes.  The easiest way to understand why is to
 ask yourself how a non-js (objc, gobject, etc) binding layer would use the
 same cached value.

 I suspect you can probably just kill off the no custom
 getter+CachedAttribute check in the code generator as I think i was simply
 being conservative when i wrote that code.

 --Oliver

 On Dec 8, 2011, at 8:39 AM, Jarred Nicholls wrote:

 Hey webkittens,

 I'm working on https://bugs.webkit.org/show_bug.cgi?id=73648 to support
 the json response entity from XHR.response.  Unless I'm mistaken (the
 purpose of this inquiry) we don't appear to have a VM-agnostic interface
 for internal JSON parsing, i.e., straight to the parsers.  If so, what does
 everyone think about adding in that basic interface?  What I'd like to
 avoid is preprocessor branches directly in XHR talking to JSC and V8
 directly; instead, what would be ideal I think is an interface to parse and
 return a ScriptObject.

 Any additional input is surely welcomed.

 Thanks,
 Jarred
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



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


Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

2011-12-06 Thread Jarred Nicholls
On Tue, Dec 6, 2011 at 5:55 AM, Anton Muhin ant...@chromium.org wrote:

 Good day, everyone!

 I am sorry if it didn't sound clear enough in our original message,
 but we're not proposing a new language support, but we're proposing a
 patch which allows others runtimes to run along with JS in the
 browser.

 Of course, we're doing this because of our work on Dart, but our
 intent was to solicit a feedback from the WebKit community if there is
 any interest in supporting runtimes additional to JS (and not JS +
 Dart) in the first place.

 And we're not only talking about the browsers proper, our hope was,
 for example, that people embedding WebKit into apps may benefit from
 hopefully tight integration or, another idea, if we can provide better
 isolation for JS proper using similar approach.

 And sure, this patch--- https://bugs.webkit.org/show_bug.cgi?id=73897
 ---is only a tiny step in this direction---Fillip is absolutely right
 that integrating several GCing VMs is tricky---we're pretty much aware
 of this and hope we can address this, but, again, the patch is only
 initial infrastructure to enable more than a single runtime.

 If consensus in the community is nobody needs more than JS runtime in
 the browser (for any reason), so it be---we looked for feedback from
 the community and we got it.  If the community response is idea is
 good, but you need to account for..., great, we're happy to do that.
 Maybe it'll make this patch feel less experimental and Geoff would be
 less reluctant to see it on the branch.


It would be easier to just host the branch in a mirror somewhere else,
continue experiments there, and report back to the community.  Many others
do this, e.g., Samsung and WebCL.



 And I can definitely understand concerns which are raised by Dart in
 the browser, but I really hope it's a separate issue.

 Thank you very much all for your feedback!

 yours,
 anton.

 On Tue, Dec 6, 2011 at 8:24 AM, Oliver Hunt oli...@apple.com wrote:
  No.  People are using EcmaScript on the web.
 
  They have languages that compile to EcmaScript as an intermediate
 language.  Dart could also do this (emscripten demonstrates that raw C can
 be compiled to EcmaScript), so if people wished they could do that.  These
 are also not a significant proportion of websites at all.  If we were to
 decide to support one of these natively it would make sense to support the
 most popular and widely used languages, but currently none of the languages
 that compile to ES have made any significant headway -- mostly because ES
 is actually a pretty good language (yes it has rough edges, but the same is
 true of _all_ languages).
 
  Adding direct and exposed support for a non-standard language is hostile
 to the open-web by skipping any form consensus driven language
 development that might happen (say the path taken by json2.js - the native
 JSON object), and foisting whatever language we want on the web instead.
  This implicitly puts any browser that supports additional proprietary
 extensions in the same position as a browser supporting something like
 vbscript, and has the same effect: breaking the open web by making content
 that only works effectively in a single product.
 
  For example back in the 90s Netscape had a feature called layers any
 browser could display the pages, but they would only look good in
 netscape.  If we were to natively support some other language on the web
 say OliversAwesomeWebLanguage, and provided a tool to compile OAWL to ES
 any site that used OAWL would perform significantly worse on other browsers
 than on our own (this is a given as the only argument in favour of native
 support vs. compilation to JS is that native support is meant faster than
 going through JS).
 
  If OAWL did become a big enough platform then other vendors _might_ end
 up reversing engineering it and reimplementing it themselves, put us back
 in the position of the 90s browsers and the many variants of what is now
 called EcmaScript.
 
  On Dec 5, 2011, at 10:43 PM, Vijay Menon wrote:
 
  On Mon, Dec 5, 2011 at 7:28 PM, Oliver Hunt oli...@apple.com wrote:
 
  The issue here isn't can we make multiple vms live in webkit it's
 can we
  expose multiple languages to the web, to the former i say obviously
 as we
  already do, to the latter I say that we don't want to.
 
  People are already using multiple languages on the web.  E.g.,
 
 https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
 .
  Native runtime support is a natural next step.
 
  WebKit does support multiple VMs, but it does not support them
  concurrently at runtime.  That is essentially what we want to enable.
 
  WebKit does support multiple bindings concurrently at runtime -- a lot
 of mac clients make use of the obj-c dom bindings while JS is executing,
 some also make use of the JS-ObjC bridge so that you have two different
 sets of bindings for the same objects at the same time, being used together
 in beautiful 

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

2011-12-06 Thread Jarred Nicholls
On Tue, Dec 6, 2011 at 8:17 AM, Anton Muhin ant...@chromium.org wrote:

 Thanks a lot, Jarred.

 We're fine w/ hosting in other repo (but we'll be happier to live
 close to the WebKit).  What would you suggest as a measure of success
 for this extra-repo branch?


I think that's a fair question.  Based on current dialogue, there are some
points to be proven such as no performance degradation or large increase of
memory consumption to run the status quo, hackability, etc.

Posting the patches was a good first step to viewing the changes, but the
separate repo would allow those interested to follow along without the
worries (on both sides) of how the separate branch affects WebKit proper.
 From the performance/memory standpoint, one good measure of success is
empirical evidence that neither are compromised when running the current
VMs.  Even if no additional VMs are supported in WebKit proper, I
understand the benefits to having the interface available for other
consumers of the engine in closed/embedded scenarios, regardless of the
controversial issues of what's best for the open web (it reminds me of the
controversies around supported video codecs for the video element and
what a nightmare that is for the open web).

I'm fairly new to the WebKit community myself, so I'm just suggesting what
I would do that would be frictionless :)



 yours,
 anton.

 On Tue, Dec 6, 2011 at 2:10 PM, Jarred Nicholls jar...@webkit.org wrote:
  On Tue, Dec 6, 2011 at 5:55 AM, Anton Muhin ant...@chromium.org wrote:
 
  Good day, everyone!
 
  I am sorry if it didn't sound clear enough in our original message,
  but we're not proposing a new language support, but we're proposing a
  patch which allows others runtimes to run along with JS in the
  browser.
 
  Of course, we're doing this because of our work on Dart, but our
  intent was to solicit a feedback from the WebKit community if there is
  any interest in supporting runtimes additional to JS (and not JS +
  Dart) in the first place.
 
  And we're not only talking about the browsers proper, our hope was,
  for example, that people embedding WebKit into apps may benefit from
  hopefully tight integration or, another idea, if we can provide better
  isolation for JS proper using similar approach.
 
  And sure, this patch--- https://bugs.webkit.org/show_bug.cgi?id=73897
  ---is only a tiny step in this direction---Fillip is absolutely right
  that integrating several GCing VMs is tricky---we're pretty much aware
  of this and hope we can address this, but, again, the patch is only
  initial infrastructure to enable more than a single runtime.
 
  If consensus in the community is nobody needs more than JS runtime in
  the browser (for any reason), so it be---we looked for feedback from
  the community and we got it.  If the community response is idea is
  good, but you need to account for..., great, we're happy to do that.
  Maybe it'll make this patch feel less experimental and Geoff would be
  less reluctant to see it on the branch.
 
 
  It would be easier to just host the branch in a mirror somewhere else,
  continue experiments there, and report back to the community.  Many
 others
  do this, e.g., Samsung and WebCL.
 
 
 
  And I can definitely understand concerns which are raised by Dart in
  the browser, but I really hope it's a separate issue.
 
  Thank you very much all for your feedback!
 
  yours,
  anton.
 
  On Tue, Dec 6, 2011 at 8:24 AM, Oliver Hunt oli...@apple.com wrote:
   No.  People are using EcmaScript on the web.
  
   They have languages that compile to EcmaScript as an intermediate
   language.  Dart could also do this (emscripten demonstrates that raw
 C can
   be compiled to EcmaScript), so if people wished they could do that.
  These
   are also not a significant proportion of websites at all.  If we were
 to
   decide to support one of these natively it would make sense to
 support the
   most popular and widely used languages, but currently none of the
 languages
   that compile to ES have made any significant headway -- mostly
 because ES is
   actually a pretty good language (yes it has rough edges, but the same
 is
   true of _all_ languages).
  
   Adding direct and exposed support for a non-standard language is
 hostile
   to the open-web by skipping any form consensus driven language
 development
   that might happen (say the path taken by json2.js - the native JSON
   object), and foisting whatever language we want on the web instead.
   This implicitly puts any browser that supports additional proprietary
   extensions in the same position as a browser supporting something like
   vbscript, and has the same effect: breaking the open web by making
 content
   that only works effectively in a single product.
  
   For example back in the 90s Netscape had a feature called layers any
   browser could display the pages, but they would only look good in
   netscape.  If we were to natively support some other language on the
 web say

Re: [webkit-dev] getComputedStyle returns percentage values for left / right / top / bottom

2011-11-22 Thread Jarred Nicholls
Indeed it is correct.  The CSS W3 draft also states that those properties
return the specified value, which if a percentage should return a
percentage by definition.

On Mon, Nov 21, 2011 at 10:49 PM, Xianzhu Wang (王显著) 
wangxian...@chromium.org wrote:

 Sorry my previous post might be misleading. Just verified that in the
 CSSOM draft the list of properties that getComputedStyle() may return the
 used value doesn't include left/right/top/bottom. That is, according to the
 draft, WebKit's current behavior about left/right/top/bottom is correct.


 On Tue, Nov 22, 2011 at 10:50 AM, Xianzhu Wang (王显著) 
 wangxian...@chromium.org wrote:

 A related bug is: https://bugs.webkit.org/show_bug.cgi?id=42799
 It's about the problem of pixelXXX CSS properties. Is these pixelXXX
 properties a workaround of bug 29084? I think after we fix 29084 we can
 drop the pixelXXX properties.

 The current draft CSSOM says getComputedStyle() should return the
 resolved values, and for width, height etc., if the property applies to
 the element or pseudo-element and the resolved value of the 'display'
 property is not none, the resolved value is the used value. Otherwise the
 resolved value is the computed value.

 On Tue, Nov 22, 2011 at 8:02 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Per bugzilla discusion, FF, IE, and Opera all return pixel values so we
 should just fix this bug.

 - Ryosuke

 On Mon, Nov 21, 2011 at 3:19 PM, Mike Sherov mike.she...@gmail.comwrote:

 I'd like to begin working on this bug (
 https://bugs.webkit.org/show_bug.cgi?id=29084), and making sure that
 getComputedStyle() always returns a pixel value used value when expected,
 although I suspect this is a controversial change, and
 http://www.webkit.org/coding/contributing.html#writecode says to ask
 in this mailing list before making a controversial change. Can anyone give
 me some feedback here on whether or not I can and should move forward on
 this?
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



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




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




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] getComputedStyle returns percentage values for left / right / top / bottom

2011-11-22 Thread Jarred Nicholls
2011/11/22 Jarred Nicholls jar...@sencha.com

 Indeed it is correct.  The CSS W3 draft also states that those properties
 return the specified value, which if a percentage should return a
 percentage by definition.


By that I meant the *older* CSS drafts - the point being that it's always
been defined in that way for those properties.




 On Mon, Nov 21, 2011 at 10:49 PM, Xianzhu Wang (王显著) 
 wangxian...@chromium.org wrote:

 Sorry my previous post might be misleading. Just verified that in the
 CSSOM draft the list of properties that getComputedStyle() may return the
 used value doesn't include left/right/top/bottom. That is, according to the
 draft, WebKit's current behavior about left/right/top/bottom is correct.


 On Tue, Nov 22, 2011 at 10:50 AM, Xianzhu Wang (王显著) 
 wangxian...@chromium.org wrote:

 A related bug is: https://bugs.webkit.org/show_bug.cgi?id=42799
 It's about the problem of pixelXXX CSS properties. Is these pixelXXX
 properties a workaround of bug 29084? I think after we fix 29084 we can
 drop the pixelXXX properties.

 The current draft CSSOM says getComputedStyle() should return the
 resolved values, and for width, height etc., if the property applies to
 the element or pseudo-element and the resolved value of the 'display'
 property is not none, the resolved value is the used value. Otherwise the
 resolved value is the computed value.

 On Tue, Nov 22, 2011 at 8:02 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Per bugzilla discusion, FF, IE, and Opera all return pixel values so we
 should just fix this bug.

 - Ryosuke

 On Mon, Nov 21, 2011 at 3:19 PM, Mike Sherov mike.she...@gmail.comwrote:

 I'd like to begin working on this bug (
 https://bugs.webkit.org/show_bug.cgi?id=29084), and making sure that
 getComputedStyle() always returns a pixel value used value when 
 expected,
 although I suspect this is a controversial change, and
 http://www.webkit.org/coding/contributing.html#writecode says to ask
 in this mailing list before making a controversial change. Can anyone give
 me some feedback here on whether or not I can and should move forward on
 this?
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



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




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




 --
 

 *Sencha*
 Jarred Nicholls, Senior Software Architect
 @jarrednicholls
 http://twitter.com/jarrednicholls




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)

2011-11-02 Thread Jarred Nicholls
On Wed, Nov 2, 2011 at 4:23 PM, Adam Barth aba...@webkit.org wrote:

 As discussed previously, I think it would benefit the project to move
 WTF out of JavaScriptCore:

 https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html
 https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html

 Previously, we've been unable to do this because of Apple's internal
 build process.  In thinking about this problem again recently, I
 wonder if the following would work:

 1) Move JavaScriptCore.xcodeproj from
 Source/JavaScriptCore/JavaScriptCore.xcodeproj to
 Source/JavaScriptCore.xcodeproj.
 2) Change how Apple submits JavaScriptCore to the internal build
 process to submit Source as the code for JavaScriptCore instead of
 Source/JavaScriptCore.
 3) Move Source/JavaScriptCore/WTF to Source/WTF.

 Mark, do you have a sense for whether this plan is feasible?  If not,
 is there another approach that would work better?

 (If my understanding is correct, we could also apply this approach to
 the other xcodeproj files, which would let us get rid of
 ForwardingHeaders and move Source/WebCore/platform to
 Source/Platform.)


That'd be most excellent.  ChangeLog would be cleanly split out as a nice
side effect to doing this, as well as w/ WTF vs. JavaScriptCore.



 Thanks,
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Please use platform prefixes in bug titles

2011-10-05 Thread Jarred Nicholls
On Wed, Oct 5, 2011 at 9:56 PM, Martin Robinson mrobin...@webkit.orgwrote:

 On Wed, Oct 5, 2011 at 6:09 PM, David Levin le...@chromium.org wrote:

  btw, I'm not planning to work on this for now but would be happy to give
  advice if someone took it up.

 A queryable mapping of which source directories and files apply to
 which ports could be quite useful indeed.


+1



 --Martin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] pthreads and other threading primitives

2011-09-26 Thread Jarred Nicholls
On Mon, Sep 26, 2011 at 1:47 PM, Alexey Proskuryakov a...@webkit.org wrote:


 In the wake of Geoff's work to simplify threading ifdefs, and Adam's review
 of supported ports, I'm curious what people think about maintaining many
 platform branches in our WTF and JavaScriptCore threading code.

 Right now, it feels rather non-systemic, with some code built upon
 pthreads, Qt or Gtk libraries, and some calling into Win32 API directly.
 Some specific examples:
 - JavaScriptCore/heap/MachineStackMarker.h only works with pthreads;
 - FastMalloc works with pthreads or Win32 API;
 - ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API;
 - code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely
 custom. Chromium doesn't even use supposedly cross-platform parts in
 MainThread.cpp.

 Supporting multiple implementation has a high cost, both in the work
 directly applied to that, and in having subtle behavior differences.
 Checking svn blame for ThreadingQt.cpp and ThreadingGtk.cpp for example, I
 see that most lines are last touched by people who are not directly
 affiliated with these ports.

 I remember that performance was given as the primary reason to not use
 pthreads everywhere. What pthreads functionality in particular needs to be
 reimplemented in WTF for performance? And are there big reasons to use
 anything except for POSIX and Win32 APIs for us?


IMHO, I think JSC should go right to the metal rather than be abstracted
with port specific threading classes.  In other words, it should be broken
out by platform threading libs - POSIX and Win32 - and not by port.  After a
very rudimentary scan, I saw no reason to not use straight Win32 and POSIX.
 This would arguably reduce port barrier-to-entry and maintenance, on top of
the obvious code simplicity and slight performance increase.


 Do we want to require that platforms support pthreads, so that code that
 isn't performance critical could have just one implementation?


That's the status quo :)  MachineStackMarker only works with pthreads, so
QtWin32 and Win ports need pthreads-win32 right now.  pthreads is the least
common denominator at the moment.  Though there are performance reasons for
getting away from that, there is also the fact that pthreads-win32 is an
unmaintained project whose last update was 5 years ago.



 - WBR, Alexey Proskuryakov


Definitely worth a full reviewer analysis and vote I think.  This is one of
the many WebKit cleanup tasks to consider.



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




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?

2011-09-13 Thread Jarred Nicholls
On Tue, Sep 13, 2011 at 11:27 AM, Eric Seidel e...@webkit.org wrote:

 Folks can track the general task of feature removal at:
 https://bugs.webkit.org/show_bug.cgi?id=68012


Nice this is helpful, thanks.




 I will link all the Remove ENABLE_* bugs to that one.

 -eric

 On Tue, Sep 13, 2011 at 11:20 AM, Eric Seidel e...@webkit.org wrote:
  Hearing no objections to removing any of the sub-defines, I will post
  a patch to do so shortly.
 
  I'll leave the ENABLE_SVG define for now.
 
  -eric
 
  On Tue, Sep 13, 2011 at 11:12 AM, Baldeva, Arpit abald...@ea.com
 wrote:
  Same here. We disable SVG for code size reasons as well. It would be
 nice to continue to have the top level define for that purpose.
 
  Thanks!
 
  -Original Message-
  From: webkit-dev-boun...@lists.webkit.org [mailto:
 webkit-dev-boun...@lists.webkit.org] On Behalf Of Dan Minor
  Sent: Monday, September 12, 2011 7:07 AM
  To: webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?
 
  When doing ports to various embedded systems we often disable SVG to
 reduce the size of the resulting library.  It would be nice to retain the
 top level ENABLE_SVG define for this purpose.
 
  Thanks,
 
  Dan
 
  On 09/09/2011 05:42 PM, Eric Seidel wrote:
  I am interested in removing the ENABLE_SVG define, and all associated
  sub-defines
 
  ENABLE_SVG_ANIMATION
  ENABLE_SVG_AS_IMAGE
  ENABLE_SVG_FONTS
  ENABLE_SVG_FOREIGN_OBJECT
  ENABLE_SVG_USE
 
  SVG is part of HTML5, and all major ports compile and ship with SVG
  enabled (and have for years).
 
  Please let me know if you are compiling with ENABLE_SVG disabled.
 
  -eric
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Jarred Nicholls
On Mon, Sep 12, 2011 at 11:57 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Also, I often encounter regressions or bugs only reproduce on certain ports
 but I haven't been able to confirm those bugs because I don't have a luxury
 of building those ports just to confirm bugs.  Providing nightlies for those
 ports will greatly enhance our ability to narrow down regression windows and
 triage bugs.


Massive point.



 - Ryosuke

 On Mon, Sep 12, 2011 at 11:38 AM, Kaustubh Atrawalkar hwn...@motorola.com
  wrote:

 Yes, I second Ryosuke and really would like to support this idea. Not even
 just end user but developers like us would also like to have sneak in these
 nightly builds. It will not only help to test the nightly on daily basis but
 also will help to improve and contribute more. I m ready to help for this in
 any way possible.

 - Kaustubh

 On 12-Sep-2011, at 11:43 PM, Ryosuke Niwa rn...@webkit.org wrote:

 An excellent idea!

 - Ryosuke

 On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth  aba...@webkit.org
 aba...@webkit.org wrote:

 Do any ports besides the Apple ports produce nightly builds that
 end-users might be interested in using?  If so, it might make sense to
 expand the offerings on http://nightly.webkit.org/
 http://nightly.webkit.org/ to include more
 choices.  For example, Linux users might enjoy a nightly build that
 runs on Linux.

 Adam
 ___
 webkit-dev mailing list
  webkit-dev@lists.webkit.orgwebkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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



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




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] More ports on nightly.webkit.org?

2011-09-12 Thread Jarred Nicholls
On Mon, Sep 12, 2011 at 12:53 PM, Konstantin Tokarev annu...@yandex.ruwrote:



 12.09.2011, 23:18, Leandro Pereira:

  OTOH, providing binary packages for Linux isn't an easy task. Different
  packaging standards, ABI differences, etc, makes binary distribution a
  nightmare: even if a new set of libraries are installed, there is no
  warranty that the browsers will pick those up or even if it will work at
  all (not really an issue for nightly builds but annoying nonetheless).

 Not really. One can perform a build on CentOS 5 and bundle every library
 ldd shows with resulting binaries (with exception of libc, libdl, and
 librt) with
 application.


True enough, I also build my products on CentOS 5 and it works on all the
other major distributions quite well.  It's got sufficiently old glibc, etc.
 But, there's the occasional issue in edge distros.



 --
 Regards,
 Konstantin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk

2011-09-12 Thread Jarred Nicholls
On Mon, Sep 12, 2011 at 1:48 PM, Adam Barth aba...@webkit.org wrote:

 Leandro's recent message reminded me that there was some discussion on
 this list about the burden caused by storing and maintaining pixel
 baselines for an ever-growing list of configurations.  I've been
 working on a proposal for moving pixel baselines to a branch so that
 they don't bother most folks.

 Unfortunately, I haven't been able to work out all the details yet.
 Here's a somewhat rough, work-in-progress proposal.  If you like this
 approach, I can spend more time trying to solve the remaining
 problems.

 == Motivation ==

 Maintaining pixel test results in svn.webkit.org for the various
 Chromium configuration imposes a number of costs on the WebKit
 community:

 All members of the community need to store these results locally when
 they create a checkout of WebKit.
 Updating the pixel results creates churn in the project that increases
 the time required to update a working copy and makes it more difficult
 to understand what is actually changing in the project.

 As the Chromium port grows in complexity, there is pressure from the
 Chromium project to expand the number of test configurations,
 increasing these costs on the WebKit community.

 == Proposal (Work-in-progress) ==

 One option is to stop running pixel test altogether, but that
 decreases test coverage and costs correctness.  Another possibility is
 to store the pixel results in a location where they are largely
 invisible to the rest of the WebKit community.  For example, we could
 store the pixel results for chromium-linux the following location:

 http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux

 Chromium contributors could then use gclient and DEPS to map these
 results into their working copies and non-chromium contributors could
 safely ignore any changes in the PixelResults “branch”.

 FIXME: What about non-platform specific results?

 == Problems ==

 The main reason this proposal is half-baked is I haven't quite been
 able to work out how folks can do some common operations:

 1) Land patch with expected image failures (+ revert)
 2) Land patch with new image baselines (+ revert)
 3) Land new baselines

 Because the pixel results and trunk are in the same SVN repo, we
 should be able to do these things atomically, but dealing with the
 sparse checkout is kind of tricky.

 Another big question mark is how this would work for contributors who
 use git.  When git mirrors an SVN repro, it only mirrors trunk, so
 the PixelResults directory wouldn't exist in the git version of the
 repository.


git-svn would be the fallback - I'd rather take razor blades to my eyes.
 But this is a noble effort in general, thanks.

Do we need to do anything to alleviate history in the git mirror?  I'd love
to clone 25MB and not 2.1GB.



 Thoughts?
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] run-bindings-tests

2011-09-09 Thread Jarred Nicholls
On Fri, Sep 9, 2011 at 12:07 PM, Adam Barth aba...@webkit.org wrote:

 run-layout-tests?

too obvious.  as an ode to Paul, I propose
run-the-mother-effing-layout-tests

http://mothereffinghsl.com/

;)


  On Sep 9, 2011 8:04 AM, Adam Roben aro...@apple.com wrote:
  On Sep 9, 2011, at 10:59 AM, Adam Roben wrote:
 
  On Sep 9, 2011, at 10:52 AM, Eric Seidel wrote:
 
  On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote:
  On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote:
 
  I'm happy to write a run-all-tests script which runs all known tests
 that platform can handle. :)
 
  I think run-webkit-tests should be this. We can come up with a new
 name for the “just run the tests in the LayoutTests directory” tool.
 
  I would like that too. But there are going to be stages to get here.
  If we did this today, bots would break if nothing else.
 
  I'll see about adding a run-all-tests script soon and we can work to
  have it replace run-webkit-tests. (new-new-run-webkit-tests anyone?)
 
  An alternate path to success would be:
 
  1) Decide what to call the script that just runs tests from LayoutTests
  2) Rename run-webkit-tests to that new name and add a new script called
 run-webkit-tests that just calls the renamed script
  3) Slowly make run-webkit-tests call out to other test-running scripts
 
  I of course forgot:
 
  2.5) Change the bots to call the renamed script
 
  -Adam
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] make-script-test-wrappers not being maintained

2011-09-08 Thread Jarred Nicholls
On Thu, Sep 8, 2011 at 10:58 AM, Eric Seidel e...@webkit.org wrote:

 We could also teach DumpRenderTree to lie about what / is, so we
 could include the scripts like this:

 script href=/fast/js/resources/js-test-pre.js


+1  But this goes back to solving the problem of deriving a path to the
LayoutTests, other than via the DRT executable's location.

These bugs are regarding remapping /tmp/LayoutTests requests, but the same
idea applies to remapping any URL to something real:

https://bugs.webkit.org/show_bug.cgi?id=67239
https://bugs.webkit.org/show_bug.cgi?id=65781



 On Thu, Sep 8, 2011 at 1:14 AM, Adam Barth aba...@webkit.org wrote:
  On Thu, Sep 8, 2011 at 12:41 AM, Maciej Stachowiak m...@apple.com
 wrote:
  Do you have an idea for how to avoid needing to adjust the number of
 ../
  path segments in the path to the harness? That's the most annoying step
 of
  the current copy/paste solution, and it does not seem like simplifying
 the
  boilerplate as you suggest resolves that issue.
 
  One approach is to have an inline script that examines the URL and
  sets the base URL appropriately:
 
  script
  document.write('base href=' + location.href.substr(0,
  location.href.lastIndexOf('LayoutTests/') + 'LayoutTests/'.length) +
  '');
  /script
 
  Of course, you could make the script more readable if you were willing
  to have it extend to more than one line.  If you wanted to get really
  fancy, you could restore the original base URL after loading the
  appropriate test harness scripts.
 
  Adam
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] make-script-test-wrappers not being maintained

2011-09-08 Thread Jarred Nicholls
On Thu, Sep 8, 2011 at 11:04 AM, Tom Zakrajsek t...@codeaurora.org wrote:

 Wouldn't that make it so that the tests would *only* work in DRT?


Yeah that's not good ;)





 On 09/08/2011 07:58 AM, Eric Seidel wrote:

 We could also teach DumpRenderTree to lie about what / is, so we
 could include the scripts like this:

 script href=/fast/js/resources/js-**test-pre.js

 On Thu, Sep 8, 2011 at 1:14 AM, Adam Barthaba...@webkit.org  wrote:

 On Thu, Sep 8, 2011 at 12:41 AM, Maciej Stachowiakm...@apple.com
  wrote:

 Do you have an idea for how to avoid needing to adjust the number of
 ../
 path segments in the path to the harness? That's the most annoying step
 of
 the current copy/paste solution, and it does not seem like simplifying
 the
 boilerplate as you suggest resolves that issue.

 One approach is to have an inline script that examines the URL and
 sets the base URL appropriately:

 script
 document.write('base href=' + location.href.substr(0,
 location.href.lastIndexOf('**LayoutTests/') + 'LayoutTests/'.length) +
 '');
 /script

 Of course, you could make the script more readable if you were willing
 to have it extend to more than one line.  If you wanted to get really
 fancy, you could restore the original base URL after loading the
 appropriate test harness scripts.

 Adam
 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

  __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Implementing HTML5 menu element

2011-09-06 Thread Jarred Nicholls
Consider that menu and dir were both deprecated in HTML4 in 1999[1], and are
obsolete with HTML5.  HTML4 Transitional/loose DTD still recognizes them.

Jarred

[1]: http://www.w3.org/TR/html4/struct/lists.html#h-10.4

On Tue, Sep 6, 2011 at 5:40 AM, Antaryami Pandia xqb...@motorola.comwrote:

 Hi,
 We are intending to implement the HTML5 menu tag.

 The related specs can be found at:-
-
 http://www.whatwg.org/specs/web-apps/current-work/#the-menu-element
-
 http://dev.w3.org/html5/spec/interactive-elements.html#the-menu-element .

 A bug for the purpose is already logged at webkit bugzilla (
 https://bugs.webkit.org/show_bug.cgi?id=58454).

 Currently webkit does have a support for menu tag (not html5) with below
 interface:-

 interface HTMLMenuElement : HTMLElement {
 attribute [Reflect] boolean compact;
 };

 Where as the proposed new implementation will have the interface as:-

 interface HTMLMenuElement : HTMLElement {
attribute DOMString type;
attribute DOMString label;
};

 So my question is should we also support the earlier menu tag
 implementation?

 Regards,
 -Antaryami






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




-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Implementing HTML5 menu element

2011-09-06 Thread Jarred Nicholls
I don't know how to answer that, as I don't know the policy at this given
moment.  But I did want to provide some information for the deciders.  I'm
just as curious; I'm not sure if or when the last time a name clash like
this has occurred.

Jarred

On Tue, Sep 6, 2011 at 8:09 AM, Antaryami Pandia xqb...@motorola.comwrote:

 So moving forward should we modify the existing HTMLMenuElement class or
 keep it in some way for backward compatibility.

 Regards,
 -Antaryami


 On Tue, Sep 6, 2011 at 5:06 PM, Jarred Nicholls jar...@sencha.com wrote:

 Consider that menu and dir were both deprecated in HTML4 in 1999[1], and
 are obsolete with HTML5.  HTML4 Transitional/loose DTD still recognizes
 them.

 Jarred

 [1]: http://www.w3.org/TR/html4/struct/lists.html#h-10.4

 On Tue, Sep 6, 2011 at 5:40 AM, Antaryami Pandia xqb...@motorola.comwrote:

 Hi,
 We are intending to implement the HTML5 menu tag.

 The related specs can be found at:-
-
 http://www.whatwg.org/specs/web-apps/current-work/#the-menu-element
-
 http://dev.w3.org/html5/spec/interactive-elements.html#the-menu-element.

 A bug for the purpose is already logged at webkit bugzilla (
 https://bugs.webkit.org/show_bug.cgi?id=58454).

 Currently webkit does have a support for menu tag (not html5) with below
 interface:-

 interface HTMLMenuElement : HTMLElement {
 attribute [Reflect] boolean compact;
 };

 Where as the proposed new implementation will have the interface as:-

 interface HTMLMenuElement : HTMLElement {
attribute DOMString type;
attribute DOMString label;
};

 So my question is should we also support the earlier menu tag
 implementation?

 Regards,
 -Antaryami






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




 --
 

 *Sencha*
 Jarred Nicholls, Senior Software Architect
 @jarrednicholls
 http://twitter.com/jarrednicholls





-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev