Re: [webkit-dev] Function & Property Names
I'm looking for a way to map the bytecodes that the interpreter is running back to source positions, not the machine code generated by the JIT. At the very least, I'd like to know if I can uniquely identify specific bytecode instructions by their offset and the source id of the code block they belong to. Can multiple code blocks have the same source id, and can there be multiple code blocks for the same source code? - Maxime Zoltan Herczeg wrote: > > Hi, > > https://bugs.webkit.org/show_bug.cgi?id=32561 > > Zoltan > >> >> Is there any way to map specific bytecode instruction instances to the >> position in the source code of the JavaScript code they correspond to? >> -- >> View this message in context: >> http://old.nabble.com/Function---Property-Names-tp28394250p28429934.html >> Sent from the Webkit mailing list archive at Nabble.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 > > -- View this message in context: http://old.nabble.com/Function---Property-Names-tp28394250p28435520.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Function & Property Names
ext Nyx wrote: I'm looking for a way to map the bytecodes that the interpreter is running back to source positions, not the machine code generated by the JIT. Have a look at bytecodeOffsetForPC(), CodeBlock::lineNumberForBytecodeOffset(), and Interpreter::throwException(). Kent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Help with review of EFL CMake patches?
Hi all, As some of you know, the EFL port is almost all merged, we just lack a build system in SVN by now. We initially started with automake, sharing with GTK, but it was quite slow and the Gtk guys had the willing to get it clean before any changes were made, in order to avoid it to get worse. We did an initial cleanup, but then we figured out CMake would be a better option. By the time we were almost done with CMake build system, this mail list started discussing build systems and CMake was one of the considered options, making us quite happy at the time. We got the system done, but then people just started to move files in SVN making our lives quite hard these last weeks. Fortunately things are calm now and the system compiles quite well. We did the patches splitting the common and EFL specific parts, so people may add new ports with minimum effort. Of course as more systems are added, we should rearrange things that we overlooked at first, but that should be easy. What we need know is someone to review https://bugs.webkit.org/show_bug.cgi?id=37945 and land it to SVN. Note that we're trying to get EFL to build with SVN, not to build the most perfect CMake build system ever. So let's be reasonable with comments and suggestions, particularly those to make it "generic" as we consider that these should come when people start moving their ports to CMake. We surely can help with such tasks, we have a partially working GTK port that we may finish one day and suggest to webkit-gtk the move to it. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Bill, could you look over these CMake files and give it an informal review? On Monday 03 May 2010 02:37:22 pm Gustavo Sverzut Barbieri wrote: > Hi all, > > As some of you know, the EFL port is almost all merged, we just lack a > build system in SVN by now. We initially started with automake, > sharing with GTK, but it was quite slow and the Gtk guys had the > willing to get it clean before any changes were made, in order to > avoid it to get worse. We did an initial cleanup, but then we figured > out CMake would be a better option. > > By the time we were almost done with CMake build system, this mail > list started discussing build systems and CMake was one of the > considered options, making us quite happy at the time. > > We got the system done, but then people just started to move files in > SVN making our lives quite hard these last weeks. Fortunately things > are calm now and the system compiles quite well. We did the patches > splitting the common and EFL specific parts, so people may add new > ports with minimum effort. Of course as more systems are added, we > should rearrange things that we overlooked at first, but that should > be easy. > > What we need know is someone to review > https://bugs.webkit.org/show_bug.cgi?id=37945 and land it to SVN. > > Note that we're trying to get EFL to build with SVN, not to build the > most perfect CMake build system ever. So let's be reasonable with > comments and suggestions, particularly those to make it "generic" as > we consider that these should come when people start moving their > ports to CMake. We surely can help with such tasks, we have a > partially working GTK port that we may finish one day and suggest to > webkit-gtk the move to it. > > BR, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] HitTest'ing scrollbars
Hi.
While working on bug 16809 (Clicking a scrollbar blurs the currently
focused element), a couple of questions raised about the current
behavior of mouse clicks on scrollbars.
On ports that do *not* use platform/native widgets for rendering
scrollbars (including Qt, Windows, Chromium):
1) clicking on a frame scrollbar will hitTest WebCore at the position
of this main frame scrollbar but won't set HitTest::scrollbar, while
hitTest'ing an in-frame scrollbar (e.g. a scrollbar of a scrollbable
div) does set it. Is this behavior by design?
Due to that, snippets like the following are needed in certain cases:
EventHandler::handleMousePressEvent(PlatformMouseEvent&)
{
(...)
FrameView* view = m_frame->view();
Scrollbar* scrollbar = view ?
view->scrollbarAtPoint(mouseEvent.pos()) : 0;
if (!scrollbar)
scrollbar = mev.scrollbar();
(...)
}
It seems strange that we have to rely on scrollbarAtPoint of FrameView
and fallback to HitTest::scrollbar . Maybe the former should not be
necessary if HitTest::scrollbar got set properly.
2) Clicking on main frame scrollbars will set as
HitTest::targetNode . This seems like an intentional behavior
according to the comment in the snippet below:
bool RenderLayer::hitTest(const HitTestRequest& request, HitTestResult& result)
{
(...)
RenderLayer* insideLayer = hitTestLayer(this, 0, request, result, boundsRect,
result.point(), false);
if (!insideLayer) {
// We didn't hit any layer. If we are the root
// layer and the mouse is -- or just was -- down,
// return ourselves. We do this so mouse events
// continue getting delivered after a drag has
// exited the WebView, and so hit testing over
// a scrollbar hits the content document.
if ((request.active() || request.mouseUp()) && renderer()->isRenderView())
{
renderer()->updateHitTestResult(result, result.point());
insideLayer = this;
}
}
(...)
But due to that, some "side effects" like [1] shows up. I would like
to confirm if this is also an intentional behavior before marking bugs
as INVALID or WONTFIX.
3) HitTest'ing a frame scrollbar bar will dispatch, MouseDown event,
but not MousePress and MouseUp. It seems different from what other
vendors do currently (run this testcase in various browsers [2],
including not webkit based ones). Why this behaviour?
[1] https://bugs.webkit.org/show_bug.cgi?id=29484 ("[Qt] Clicking on
the frame's scrollbar trigger a click event in the page.")
[2] https://bugs.webkit.org/attachment.cgi?id=20748
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Hi, the file from Gustavo are mainly for the EFL port. It's not a general buildsystem and some parts are not real "CMake style" in the moment. I did some "cleanup" for the JavaScriptCore files already, but for the WebCore and WebKit parts it is a bigger task. As I already wrote at [1] I will help creating a general, not EFL specific, CMake buildsystem, but I didn't get any responses until now. - Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012599.html On Mon, 3 May 2010 15:23:11 -0400, Adam Treat wrote: > Bill, could you look over these CMake files and give it an informal review? > > On Monday 03 May 2010 02:37:22 pm Gustavo Sverzut Barbieri wrote: >> Hi all, >> >> As some of you know, the EFL port is almost all merged, we just lack a >> build system in SVN by now. We initially started with automake, >> sharing with GTK, but it was quite slow and the Gtk guys had the >> willing to get it clean before any changes were made, in order to >> avoid it to get worse. We did an initial cleanup, but then we figured >> out CMake would be a better option. >> >> By the time we were almost done with CMake build system, this mail >> list started discussing build systems and CMake was one of the >> considered options, making us quite happy at the time. >> >> We got the system done, but then people just started to move files in >> SVN making our lives quite hard these last weeks. Fortunately things >> are calm now and the system compiles quite well. We did the patches >> splitting the common and EFL specific parts, so people may add new >> ports with minimum effort. Of course as more systems are added, we >> should rearrange things that we overlooked at first, but that should >> be easy. >> >> What we need know is someone to review >> https://bugs.webkit.org/show_bug.cgi?id=37945 and land it to SVN. >> >> Note that we're trying to get EFL to build with SVN, not to build the >> most perfect CMake build system ever. So let's be reasonable with >> comments and suggestions, particularly those to make it "generic" as >> we consider that these should come when people start moving their >> ports to CMake. We surely can help with such tasks, we have a >> partially working GTK port that we may finish one day and suggest to >> webkit-gtk the move to it. >> >> BR, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
On Mon, May 3, 2010 at 5:21 PM, Patrick Roland Gansterer wrote: > Hi, > > the file from Gustavo are mainly for the EFL port. It's not a general > buildsystem and some parts are not real "CMake style" in the moment. > I did some "cleanup" for the JavaScriptCore files already, but for the > WebCore and WebKit parts it is a bigger task. > > As I already wrote at [1] I will help creating a general, not EFL > specific, CMake buildsystem, but I didn't get any responses until now. > > - Patrick > > [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012599.html Patrick, Did you see this new version? Leandro did the work on top of yours. However he removed the .h from the source list, he did it before he read that it may be useful to get some IDE to show it. If mandatory we can add them back. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Hi,
On Mon, 3 May 2010 17:33:45 -0300, Gustavo Sverzut Barbieri
wrote:
> Did you see this new version? Leandro did the work on top of yours.
> However he removed the .h from the source list, he did it before he
> read that it may be useful to get some IDE to show it. If mandatory we
> can add them back.
Yes, I've seen it. He did a great job, but there a some parts which are
not good for a "general buildsystem".
E.g. INCLUDE(Options${PORT}) doesn't support different ports well, since
ports share some parts. (There some other points too; I'll post them on the
bug)
My vision is that the root CMake file will do all the "WTF_USE_*" stuff.
It has to decide all "port specific stuff". All other CMake files should
only use this "defines". This will provide a central to switch the
different implementations (e.g. switch between pthread and native threads
on windows).
I already run in some problem with my JavaScriptCore CMake files, but I
hoped for some feedback I didn't get.
My big question is if CMake should be added as a universal buildsystem (to
get rid of some other buildsystems) or if it is only for the EFL port?
I think this depends on ther progress in the CMake vs. GYP discussion. The
last post on the mailing list was [1].
- Patrick
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012662.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
On Mon, May 3, 2010 at 6:09 PM, Patrick Roland Gansterer
wrote:
> Hi,
>
> On Mon, 3 May 2010 17:33:45 -0300, Gustavo Sverzut Barbieri
> wrote:
>> Did you see this new version? Leandro did the work on top of yours.
>> However he removed the .h from the source list, he did it before he
>> read that it may be useful to get some IDE to show it. If mandatory we
>> can add them back.
> Yes, I've seen it. He did a great job, but there a some parts which are
> not good for a "general buildsystem".
> E.g. INCLUDE(Options${PORT}) doesn't support different ports well, since
> ports share some parts. (There some other points too; I'll post them on the
> bug)
>
> My vision is that the root CMake file will do all the "WTF_USE_*" stuff.
> It has to decide all "port specific stuff". All other CMake files should
> only use this "defines". This will provide a central to switch the
> different implementations (e.g. switch between pthread and native threads
> on windows).
The point is to split this off to some ports as these things are
likely to get huge. As said we did some for GTK and EFL, although they
share a lot, the checks became big to make the file a PITA to read.
Although CMake does provide if() and indentation, the branches tend to
be quite long.
also, each folder, like JavaScriptCore/CMakeLists.txt have a
port-specific file included, that may be used to filter or extend the
lists, or to change some variables. This way we can turn on "*core
libraries as shared objects" and have libJavaScriptCoreGtk.so and
libJavaScriptGtk.so installed. This is not so useful for deployment,
but definitely useful for development where link times tend to be
quite long if you don't have lots of RAM for linking.
Also, this is done in a way that we don't need to anticipate all kind
of different platform behaviors, they can just change the behavior as
intended.
> I already run in some problem with my JavaScriptCore CMake files, but I
> hoped for some feedback I didn't get.
Well, the bits you did were quite unchanged, except by delegating the
options to their own files due the above reasons. So consider these
patches as feedback that works (in the sense of you can try it)
> My big question is if CMake should be added as a universal buildsystem (to
> get rid of some other buildsystems) or if it is only for the EFL port?
> I think this depends on ther progress in the CMake vs. GYP discussion. The
> last post on the mailing list was [1].
>
> - Patrick
>
> [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012662.html
As I said, I really want to get out of the universal thing otherwise
it will not be merged. IMHO it is a much saner approach to do one
example and passively convert those that are willing to use CMake (ie:
Xan said if Gtk works without loss, then he'd be fine to use it).
Alternatively, if moving to GYP will make our build system be accepted
more easily, then just say and we'll take the burden of going that
route. We just want to have all we need in SVN, say to users "get svn,
type this and it is done". Also, maintaining the build off tree proved
painful over the last weeks when files were moved and we had to play
catch up (to fix this we need stuff in svn AND a build bot, i know...
but we'll get there).
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Function & Property Names
Is there any way to get the number of parameters a function has declared from a JSFunction object? I'm asking because I want to get the argument values a function is receiving in an op_call (in the interpreter). I copied this snipper of code for the case where a host function is called: Register* thisRegister = callFrame->registers() - RegisterFile::CallFrameHeaderSize - argCount; ArgList args(thisRegister + 1, argCount - 1); The problem is that argCount is the number of arguments passed, and so, if the function takes 5 arguments and 3 are passed, I'm not getting the first 2, only the last 3, two of which show up as "undefined". Hence I believe I would need the number of arguments the function declares takes to properly compute the register offset. -- View this message in context: http://old.nabble.com/Function---Property-Names-tp28394250p28442878.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
