Hi all, I just landed a patch that replaces VectorT::iterator and
VectorT::const_iterator with a non-pointer object that is actually memory
safe. Everything _should_ work the same as before, with a few exciting changes:
* begin() and end() can no longer be used transparently as pointers.
On a related note I’ve also got a patch up for review that adds bounds checking
to Vector::iterator, and that vigorously performs bounds and overflow checking.
—Oliver
On Nov 19, 2014, at 2:04 PM, Chris Dumez cdu...@apple.com wrote:
Hi,
I believe the Vector class is already checking for
On May 7, 2014, at 2:41 PM, Rik Cabanier caban...@gmail.com wrote:
When would I as a user, not want a page or web application to be as fast as
possible? Has a user ever complained about a desktop app that uses too many
of his CPU's? I think Oliver's point was that other processes might
On May 7, 2014, at 3:15 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt oli...@apple.com wrote:
On May 7, 2014, at 2:41 PM, Rik Cabanier caban...@gmail.com wrote:
When would I as a user, not want a page or web application to be as fast
On May 5, 2014, at 6:13 PM, Rik Cabanier caban...@gmail.com wrote:
Do you really want a page to know that you have a fancy-pants 24-core Mac
Pro rather than a little Mac mini?
Yes!
If I have 24 cores ready to do work and the page can put them to use, I would
like it to do so.
At the
Could whoever is responsible for the EFL EWS bot please make the bot set the
correct mimetype on the build output.
I've requested this before, but i'm trying again. It is really annoying that
it triggers a download rather than just opening in the browser like the output
from every other bot.
On Dec 7, 2013, at 12:15 PM, Alexei Sholik alcosho...@gmail.com wrote:
The garbage collector scans the C stack.
Hm, let me make sure I understand this correctly.
...
I'm asking because I've never previously dealt with a library that scans the
host application's stack. So it sounds pretty
On Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen k...@carewolf.com wrote:
On Monday 30 September 2013, Oliver Hunt wrote:
On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen k...@carewolf.com wrote:
Some of this is exactly the reason we want to keep Qt WebKit alive. It
may never be possible
On Oct 1, 2013, at 11:56 AM, Martin Robinson mrobin...@webkit.org wrote:
On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen gga...@apple.com wrote:
A 5% regression in page load performance seems pretty serious.
I’m assuming you’re considering the GTK port here, and not the end-of-life
Qt
On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen k...@carewolf.com wrote:
Some of this is exactly the reason we want to keep Qt WebKit alive. It may
never be possible to fully replace Qt WebKit with anything Blink/Chromium
based.
I really don’t understand this, there are only two options:
I believe that there’s a mnemonic that forces alignment that we could (arguably
should?) be using before these labels.
IIRC it’s something like .align N — if we aren’t doing this already we could
make the lint assembler backend emit a .align 16 prior to each global symbol.
—Oliver
On Sep 26,
We may want to hunt through the other cases of default: ASSERT_NOT_REACHED()
and clobber those with RELEASE_ASSERT_NOT_REACHED() as well.
I wonder if it would be easier to have DEFAULT_NOT_REACHED() and DEFAULT_OKAY()
macros, and convince the style bot to require ether a default: block or one
Hurk :-/
I guess there's no nice automate-able to handle everything magically.
Still it would probably be good to replace the default:ASSERT_NOT_REACHED()
cases at least.
--Oliver
On Sep 13, 2013, at 10:33 AM, Darin Adler da...@apple.com wrote:
On Sep 13, 2013, at 10:31 AM, Oliver Hunt oli
On Sep 12, 2013, at 6:38 AM, Thomas Fletcher tho...@cranksoftware.com wrote:
TDLR: Crank Software Supports a NIX port
This is a question of maintenance burden. As Geoff said every port adds a cost
to developing and maintaining webkit. You've said you support a NIX port, but
a quick search
On Sep 6, 2013, at 9:44 AM, youenn fablet youe...@gmail.com wrote:
Hi Ryosuke,
The two points you are mentioning make sense to me.
For starters, most of users wouldn't even know what a local network is; let
alone what discovering media sources, etc... mean.
Most users may not be
On Aug 30, 2013, at 9:15 AM, Brendan Long s...@brendanlong.com wrote:
On 08/29/2013 05:45 PM, Benjamin Poulain wrote:
Can you explain a bit what it is for? What are the common use cases?
This would be useful for certain kinds of web apps. For example,a music
website like Pandora or Spotify
On Aug 30, 2013, at 12:44 PM, Dirk Pranke dpra...@chromium.org wrote:
On Fri, Aug 30, 2013 at 10:06 AM, Oliver Hunt oli...@apple.com wrote:
On Aug 30, 2013, at 9:15 AM, Brendan Long s...@brendanlong.com wrote:
On 08/29/2013 05:45 PM, Benjamin Poulain wrote:
Can you explain a bit what
So wait, is everyone using C++11 now?
I dream of using auto…
:-D
On Jul 28, 2013, at 12:47 PM, Gergely Kis gerg...@homejinni.com wrote:
Hi,
On Sun, Jul 28, 2013 at 7:30 PM, Allan Sandfeld Jensen k...@carewolf.com
wrote:
became required in WebKit2. The only fallout will likely be the
(I meant to send this last night, so many apologies for the delay)
Last night I merged over the FTL branch to trunk, currently the FTL itself is
guarded by ENABLE_FTL_JIT and HAVE_LLVM guards, however the branch does bring
in a lot of general improvements to JSC's existing execution engines.
On Jul 15, 2013, at 4:04 AM, SzymanskiPrzemyslaw p.szymans...@samsung.com
wrote:
Hello.
Valgrind shows that WebGL performance is lowered by WebGL validation methods
like: WebGLRenderingContext::validateRenderingState,
WebGLRenderingContext::validateUniformMatrixParameters or validations
Webkit development occurs on trunk and most communication is on IRC and in
bugs.webkit.org. If you rely on email to see signs of activity I recommend
subscribing to webkit-commits (or whatever that list is called). All it would
have taken is the briefest look at webkit's svn or git
to the webkit project whatsoever. It does, however, make
some very cool and useful technology available to those who choose to use
webkit2. I believe that would qualify as obvious benefit.
On Tue, Jul 9, 2013 at 12:49 PM, Oliver Hunt oli...@apple.com wrote:
Aside from any other issues, my
Aside from any other issues, my recollection was that there had not been any
work to formally specify NaCl or Pepper, has that changed?
I'm also concerned as this adds a significant maintenance burden to the project
for no obvious benefit.
--Oliver
On Jun 30, 2013, at 11:41 PM, halton huo
On May 1, 2013, at 5:29 PM, Antonio Gomes toniki...@webkit.org wrote:
- 4.2 Cross-Origin Information Leakage
WebCL's position is that this be handled by the same mechanism as used for
WebGL, ie https://www.khronos.org/registry/webgl/specs/latest/#4.2 . A bug
will be filed to request update
Before i saw any patches landed i would expect the specification to state
exactly what kernel features are allowed and required.
Additionally the specification language of the security section is fairly weak
- 4.2 doesn't say how CORS will be used to achieve security. Presumably WebCL
just
On Apr 10, 2013, at 9:44 AM, Jarred Nicholls jar...@webkit.org wrote:
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.com wrote:
Yes, leveraging multicore and the power of GPUs for general
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide a bunch of functions
like map, etc where if you restrict your list of language features to a
specific subset, they'll vectorise it.
For instance
was asking Filip how you might
infer that an array could be a ParallelArray.
-- Dirk
On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt oli...@apple.com wrote:
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide
There are plenty of other bindings - Gtk has a set of dom bindings i believe,
there used to be COM (shudder) bindings as well, but those aren't the problem.
We could have as many binding languages as we want, there's no major
architectural reason not to.
But supporting javascript isn't simply
On Feb 6, 2013, at 4:59 PM, Alec Flett alecfl...@chromium.org wrote:
On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com wrote:
I think we should continue to use uint8_t instead of char as the primary way
to represent a raw byte in WebKit. First, it's good to distinguish raw
I take your word for it that it's not possible on Windows.
Given that Chromium has many users on Windows (and other non-Mac
platforms), you should now understand why this design does not fit
well with Chromium's design constraints.
But chromium doesn't use webkit or webkit2, so i'm not
How will we ensure thread safety? Even at just the tokenizing level don't we
use AtomicString? AtromicString isn't threadsafe wrt StringImpl IIRC so this
seems like it sould add a world of hurt.
I realise it's been a long time since I've worked on this so it's completely
possible that I'm
I don't understand why anyone is _speculatively_ rolling out patches.
You should only be rolling it out if you _know_ the patch is bad.
That said if you do rollout a random unrelated patch it is obviously your job
to roll it back in. You can't say i thought this broke something, but i was
On Dec 11, 2012, at 2:17 PM, Peter Kasting pkast...@chromium.org wrote:
On Tue, Dec 11, 2012 at 2:14 PM, Oliver Hunt oli...@apple.com wrote:
I don't understand why anyone is _speculatively_ rolling out patches.
You should only be rolling it out if you _know_ the patch is bad.
Sometimes
Since a common theme people are bringing up is vtable overrides, I do recall
reading about vtable masking being available in some compilers. I'm wondering
if we should push for support for such in compilers we use - I'm not sure what
the vcall perf hit is in such cases, but it would knock kill
On Oct 1, 2012, at 8:47 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Oct 1, 2012 at 7:07 AM, Dirk Schulze k...@webkit.org wrote:
On Monday, October 1, 2012, Gyuyoung Kim wrote:
Hello WebKit folks,
There were build warning related to unused parameter nowadays. I think there
are
at 12:46 PM, Oliver Hunt oli...@apple.com wrote:
What exactly are you trying to test here? The internal serialisation format
isn't exposed anywhere (nor should it be).
By definition newer formats won't be backwards compatible, or are you trying
to ensure that newer deserialisers will be able
My preference would simply be to improve the Clang static analyser - it's free,
open source, etc.
I periodically run that analyzer on JSC, but apparently their ToT code has many
improvements over stable.
--Oliver
On Sep 17, 2012, at 9:20 PM, Brent Fulgham wrote:
Hi Gang,
On Sep 17, 2012,
JSC's SerializedScriptValue has always been versioned (having learned the
horror of no versioning with localStorage :( )
Newer formats (obviously) can't be read by older clients, but the serialisation
is intentionally forwards compatible.
--Oliver
On Sep 18, 2012, at 12:36 PM, Adam Barth
What exactly are you trying to test here? The internal serialisation format
isn't exposed anywhere (nor should it be).
By definition newer formats won't be backwards compatible, or are you trying to
ensure that newer deserialisers will be able to continue to deserialise old
content?
--Oliver
Does the style bot pick up unsigned int etc?
--Oliver
On Sep 13, 2012, at 1:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
Landed in http://trac.webkit.org/changeset/128499 (Thanks ggaren!)
On Thu, Sep 13, 2012 at 12:29 PM, Ryosuke Niwa rn...@webkit.org wrote:
Uploaded a patch on
op_call_NotJSFunction is only referenced during the final linking phase.
Actual compilation requires two distinct operations: 1) planting the call
instruction and 2) linking the call target after the code has been relocated.
Here is the (64-bit) version of the call + link logic:
...
The problem is that as we make changes we end up breaking the SH4, MIPS,
ARMvOld builds, which we are ostensibly not allowed to do, and so have to spend
significant amounts of time trying to ensure that the builds don't break/start
failing horribly, and then having committed the patch[es] we
, could we temporarily freeze the JIT
(perhaps the whole JSC engine somehow) at old versions somehow for
architectures that may take time to catch up?
Regards,
Maciej
On Jun 22, 2012, at 10:52 AM, Oliver Hunt oli...@apple.com wrote:
The problem is that as we make changes we end up
They may have a desire for it, but certainly not a need -- Webkit includes a
well maintained, guaranteed ABI stable JS engine that works on _all_
architectures, with a high performance JIT support available on numerous
architectures and OS's. Being able to support two engines just in webcore
On Apr 16, 2012, at 1:00 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
Could this be an opportunity to design an asynchronous API for fetching the
pixel buffer? It
Last I saw, there hadn't been any attempt to actually define how the content is
encrypted. Has that changed? If it hasn't how do we get interoperable
implementations? The only way for this spec to not break the openness of
video and audio is for the encryption algorithm to be completely
I am all for this change, but a not insubstantial part of that is my general
hate for anything other than me ever changing the focused window and/or element.
--Oliver
On Apr 4, 2012, at 1:31 AM, Jochen Eisinger wrote:
Hey,
Firefox restricts the use of window.blur() and window.focus() (by
I do think that we should also be considering what the responders are doing --
eg. do you work mostly on the core engine (WebCore, JSC, etc) vs. platform
specific engine work (eg.
WebCore/platform/graphics/{cg,cairo,skia,backendofdoom}) vs. WebKit API stuff
vs. release branching, etc
I think
On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote:
Hi all,
If you don't use webkit-patch and Git, you can stop reading now. Otherwise ...
Currently, webkit-patch -g has some special logic for figuring out
what to diff against for Git checkouts.
Specifically, webkit-patch -g commitish
On Dec 16, 2011, at 9:05 AM, Rolando Abarca wrote:
Hi all,
I'm using JavaScriptCore for scripting purposes (isolated from webkit), and
I'm encountering the following problem:
I would like to store a reference to an anonymous function, and later to be
able to call it as a callback,
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
On Dec 8, 2011, at 1:25 PM, Rik Cabanier wrote:
This might no longer be true, but isn't it the case that shaders are designed
to take the same amount of time to execute, no matter what input they get?
ie if you have an if/else block, the time of the shader would be whatever
block takes the
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
On Dec 6, 2011, at 2:55 AM, Anton Muhin 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
On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt oli...@apple.com wrote:
On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:
Good day, everyone!
I am sorry if it didn't sound clear enough in our original message,
but we're not proposing
On Dec 6, 2011, at 11:53 PM, Oliver Hunt wrote:
On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
Those bindings are different because the code that uses them is not
activated from web pages. Looking at the specific posted patches, those
changes seem necessary to support activating
What is the benefit to the project in exposing an additional (non standardized)
language to the web? All the bindings that webkit currently provides to are
either standardized EcmaScript or platform specific bindings used by native
code developers embedding webkit.
Adding an additional web
Previous branches have been used to bring up interestingly complicated
features, or features that had the potential to cause dramatic stability issues
during their early work (such as the old svg-experimental branch). This
project appear to be largely a make work project as it's already
The handwritten parser has numerous benefits over the old bison generated one,
the most basic being:
* It's more than 2 times faster than the bison parser
* It doesn't require complete duplication of the grammar to support strict
mode (and can identify strict mode in the first place)
* It
On Sep 22, 2011, at 7:46 PM, Ian Hickson wrote:
On Thu, 22 Sep 2011, David Levin wrote:
*Summary*: Implementing postMessage with transferable support as
webkitPostMessage.
*Details*:
*Spec*:
http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages
This
On Sep 8, 2011, at 7:21 PM, Alexey Proskuryakov wrote:
08.09.2011, в 12:25, Darin Adler написал(а):
I find the bindings tests quite helpful. Because the perl script is so hard
to read, it’s the changes in bindings script test results that I look at
when reviewing changes to the
On Sep 8, 2011, at 11:55 AM, James Robinson wrote:
We used to not run these tests on the bots. This meant that people would
change the bindings code and not update the expected results, so the expected
results were always massively out of date. This meant when patching the
bindings
On Aug 24, 2011, at 3:20 PM, Tasneem Brutch - Samsung wrote:
Khronos WebCL is not yet a specification, and the WebCL API has not yet been
standardized. The WebCL members are currently discussing the security and
interoperability issues in the WebCL Working Group. Samsung would like to
How has the WebCL spec dealt with the inherent security problems of OpenCL in
the face of untrusted content? In the WebGL working group we spent a lot of
time working on how to adequately restrict GLSL|ES to prevent security
vulnerabilities, and I haven't really heard anything about what
I think considerable effort should be put into building up a suite of
performance tests in advance of the new parser (probably culled from xml
encountered in the wild, but also a number of extreme edge cases wouldn't go a
miss either).
We should also put effort into reducing any/all recursion
On Jun 22, 2011, at 11:38 AM, Eric Seidel wrote:
I think it's better for our reviewers to review only things they're
comfortable with.
A good reviewer shouldn't be reviewing things they aren't comfortable with
anyway -- the whole point of a review is to have someone who has appropriate
On Jun 18, 2011, at 12:24 PM, Darin Adler wrote:
I noticed these three roll-outs:
http://trac.webkit.org/changeset/89190
http://trac.webkit.org/changeset/89191
In the case of these first two patches was any attempt made to actually fix the
qt build? Every other build was apparently
The current debugging mechanism is not particularly pleasant to use, nor is it
very future proof, it has significant performance costs, and it requires the
user to have significant knowledge of the inner workings of JSC.
Before we started considering exposing JS debugging through API (and
carefully thought out, and would probably require multiple
iterations to get to the point where we'd consider the API sufficiently good.
--Oliver
On Jun 14, 2011, at 9:12 AM, demallien wrote:
Is that an official response?
On 14 Jun, 2011,at 06:03 PM, Oliver Hunt oli...@apple.com wrote
A common problem the we're hitting when working on JSC is that the Qt bridge
bindings are implemented in terms of JSC internals. This keeps causing us
problems as no one working on JSC really knows anything about Qt or the API the
bridge objects are intended to provide, and yet we are required
An alternative would be to generate code for optional args along the lines of
(pseudo code):
void foo(Arg1Type arg1, [Optional] Arg2Type arg2);
=
Arg1Type arg1 = toArg1Type(arguments[0]);
if (arguments.length 2)
return impl-foo(arg1);
Arg2Type arg2 = toArg2Type(arguments[1]);
return
, Oliver Hunt wrote:
Don't roll out patches that don't break any core builders, without making
some attempt to diagnose the problem or providing information that will make
it possible to fix the problem.
The GTK bots are core builders.
-Adam
On Apr 13, 2011, at 2:06 PM, Ojan Vafai wrote:
Do we have a single page to point people to for learning to use the
inspector? Would be nice if there were a page that just linked to all the
blog posts.
On Wed, Apr 13, 2011 at 2:02 AM, Yury Semikhatsky yu...@chromium.org wrote:
I
If you use webkit-patch everything just magically works (yay!!)
--Oliver
On Mar 26, 2011, at 11:30 AM, Brent Fulgham wrote:
On Mar 26, 2011, at 10:41 AM, Darin Adler wrote:
On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote:
Sometimes folks commit changes without bug numbers. If
For reference desktop webkit implementations will automatically increase the
canvas backing store resolution as the device:css pixel ratio increases.
--Oliver
On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote:
On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote:
Hi again,
I'm trying
, at 8:51 AM, Oliver Hunt oli...@apple.com wrote:
For reference desktop webkit implementations will automatically increase the
canvas backing store resolution as the device:css pixel ratio increases.
--Oliver
On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote:
On 3/4/2011 1:35 AM
webkit-patch could be made aware of them -- how does the commit-queue handle
it? If a patch doesn't include mime type info i would imagine it's doing
something to prevent the annoying diff spew.
--Oliver
On Mar 3, 2011, at 8:42 AM, Adam Roben wrote:
On Mar 3, 2011, at 11:40 AM, Oliver Hunt
I agree. My hope was always that the OpenGL backend could be shared among all
the webkit ports, my only suggestion is that rather than having a separate
OpenGLExtensionsFunctions class, I think we probably want something like
GraphicsContext3DOpenGL.{h,cpp} for all the common logic
and then
I just discovered that the review tool doesn't save the general comments, only
inline ones (http://webkit.org/b/54121). This just got me when I clicked on
the style bot to see what style checks had failed and lost my feedback :(
This was particularly annoying as i had command-clicked the link
I just discovered that the review tool doesn't save the general comments, only
inline ones (http://webkit.org/b/54121). This just got me when I clicked on
the style bot to see what style checks had failed and lost my feedback :(
This was particularly annoying as i had command-clicked the link
On Dec 21, 2010, at 1:49 PM, Maciej Stachowiak wrote:
And we have JavaScriptCore API tests which are not run automated.
The JSC API tests run as part of run-javascript-tests, which the build bots do
execute
--Oliver
___
webkit-dev mailing list
I really would like to be able to select some text and add a comment that uses
the selection as context, a single line of context is frequently insufficient,
this is about the only thing that still makes the new review tool less
effective than the old review mechanism (for me at least).
On Sep 14, 2010, at 5:56 PM, David Levin wrote:
On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth aba...@webkit.org wrote:
What do you think of the idea of having a re-useable BlobCore module
that all the ports can share?
I don't think this is a good idea. This re-usable module would only be
It would be nice if you could select a block of code and have the comment be
for that block -- last i looked the line by line review basically loses context
for reviews as it pushes the comments to the bottom and only includes a single
line of context.
--Oliver
On Aug 29, 2010, at 11:13 AM,
The reason ImageBuffer::image() makes a copy (be it a deep copy, or CoW) is
almost exclusively for the purpose of ensuring correct behaviour in the case
where a canvas is drawn onto itself, eg.
context = myCanvas.getContext(2d);
context.drawImage(myCanvas, 0, 0);
Off hand I can think of no
On Jul 28, 2010, at 8:45 AM, Joone Hur wrote:
Hello all,
I’m working on a Hangul(Korean alphabet) composition issue in WebKit.
https://bugs.webkit.org/show_bug.cgi?id=40518
By the way, I noticed that WebKit based browsers are inconsistent with
IME composition events.
According to the
Shared-state parallel scripting (and concurrent DOM) seem inevitable
I don't know why you believe this -- there is no intention of having shared
state threading in ES, nor is there any desire in the ES technical committee to
add any for of concurrency primitives to the language.
--Oliver
On Jul 23, 2010, at 4:50 PM, Leo Meyerovich wrote:
I wasn't entirely sure what OP was after of if the reply below
adequately addressed his interests.
WebKit2 seems to have little to do with taking advantage of parallel hardware
in browser algorithms like lexing, parsing, selectors, JS
On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao zhen...@gmail.com wrote:
Maybe I should complain this in a different threads, but recently the commit
bot waiting time is way too long. Several times a patch of mine got the r+
and cq+ and
On Jul 7, 2010, at 7:26 PM, Jeremy Orlow wrote:
On Thu, Jul 8, 2010 at 10:19 AM, Oliver Hunt oli...@apple.com wrote:
On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao zhen...@gmail.com wrote:
Maybe I should complain this in a different
If you have a debug build of jsc, you can run 'jsc -d' and that will dump the
generated bytecode
--Oliver
On May 20, 2010, at 8:42 AM, Nyx wrote:
I've been working on a tool to generate a trace of JavaScript executions,
built on JavaScriptCore. I'm trying to log calls to all functions and
It seems like the majority of this belongs in EcmaScript directly rather than
being restricted to web-oriented uses of ES. I'm also unsure of the relevance
of CommonJS to either WebAPI or ES as CommonJS is not part of either standards
body. For example the use of require implies making
What's your testcase?
One potential issue you could be seeing is that we don't dump the bytecode
until we compile code so the code for a function won't be dumped until you call
it for instance, but you should at the very least be getting an bc dump for the
containing global code.
--Oliver
On Apr 27, 2010, at 2:10 PM, Nyx wrote:
I also tried adding #define ENABLE_JIT 0 at the top of the Interpreter.cpp
file in JavaScriptCore. This builds, but produces a segmentation fault.
This would not work as you would end up with some parts of WebKit compiled with
the jit enabled, and some
looks like ~RenderSVGResourceClipper should be doing deleteAllValues(m_clipper);
--Oliver
On Apr 13, 2010, at 3:48 PM, Maciej Stachowiak wrote:
https://bugs.webkit.org/show_bug.cgi?id=37527
http://trac.webkit.org/changeset/57511
Regards,
Maciej
On Apr 9, 2010, at 2:09 PM, Maciej Stachowiak wrote:
On Apr 9, 2010, at 2:03 PM, Adam Barth wrote:
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote:
We seem to welcome pretty much any port that has an active maintainer.
IMHO, that's a good thing. I wonder if
My bad, fixing now.
--Oliver
On Feb 25, 2010, at 2:47 PM, Maciej Stachowiak wrote:
On Feb 25, 2010, at 2:46 PM, Kenneth Russell wrote:
A change committed some time since yesterday evening has introduced
many crashes in JSC's GC during testing. A representative stack trace
is attached.
If
Update to r55258 or later :D
--Oliver
On Feb 25, 2010, at 2:46 PM, Kenneth Russell wrote:
A change committed some time since yesterday evening has introduced
many crashes in JSC's GC during testing. A representative stack trace
is attached.
If you have made changes in this area recently, can
, 2010, at 2:58 PM, Kenneth Russell wrote:
OK, thanks, that appears to have fixed it.
How about that commit queue? Would have caught the crashes before they
were checked in.
-Ken
On Thu, Feb 25, 2010 at 2:53 PM, Oliver Hunt oli...@apple.com wrote:
Update to r55258 or later :D
--Oliver
On Feb
1 - 100 of 202 matches
Mail list logo
