Re: [webkit-dev] RenderContainer class in webkit source code

[n179911]

Thanks. I am not sure how to use ChangeLogs.

On Fri, Jul 3, 2009 at 5:58 PM, Simon Fraser wrote:
> On Jul 3, 2009, at 5:41 PM, n179911 wrote:
>
>> Hi,
>>
>> Can you please tell me if the RenderContainer class in webkit source
>> code got removed?
>> I notice this class in android's webkit source, but when I check the
>> code in webkit trunk, that class is not there.
>>
>> Can you please if that class got removed? Thank you
>
> Use those ChangeLogs that you've heard so much about. They show
> that RenderContainer was eliminated on 2009-02-04.
>
> Simon
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] RenderContainer class in webkit source code

[Simon Fraser]

On Jul 3, 2009, at 5:41 PM, n179911 wrote:


Hi,

Can you please tell me if the RenderContainer class in webkit source
code got removed?
I notice this class in android's webkit source, but when I check the
code in webkit trunk, that class is not there.

Can you please if that class got removed? Thank you


Use those ChangeLogs that you've heard so much about. They show
that RenderContainer was eliminated on 2009-02-04.

Simon

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

[webkit-dev] RenderContainer class in webkit source code

[n179911]

Hi,

Can you please tell me if the RenderContainer class in webkit source
code got removed?
I notice this class in android's webkit source, but when I check the
code in webkit trunk, that class is not there.

Can you please if that class got removed? Thank you
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[David Kilzer]

On Friday, July 3, 2009 2:19:51 PM, Maciej Stachowiak wrote:

> What I do (and I think many of us do) is use a script that
> automatically fills in the commit message from the ChangeLog.

The script is WebKitTools/Scripts/commit-log-editor.  Setting one of these 
environment variables (depending on whether you're using svn or git) works 
great (replace "$WEBKIT_SRC_DIR" with the path to your webkit source, or just 
set them to "commit-log-editor" if you've added WebKitTools/Scripts to your 
PATH):

GIT_EDITOR=$WEBKIT_SRC_DIR/WebKitTools/Scripts/commit-log-editor
SVN_EDITOR=$WEBKIT_SRC_DIR/WebKitTools/Scripts/commit-log-editor

You'll also want to set the EDITOR environment variable unless you use vi to 
edit your svn/git commit logs.  :)

Dave

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

Re: [webkit-dev] ChangeLog

[David Kilzer]

On Friday, July 3, 2009 1:01:33 PM, Joe Mason wrote:


> Even if sticking with svn, you just need to run svn2cl once when
> you update to  get a local copy of the changelog.


If each developer had to run that command to get a local changelog, I can't 
imagine the svn server would be very responsive if two or more people ran it at 
the same time.

Also, if you're already disconnected from the network, it's "too late" to run 
svn2cl if you want the full history.

--

Personally, I think git is the long-term solution since (a) git-format-patch 
includes the commit log comments in the patch format, which makes them easily 
reviewable and (b) it operates in an off-line mode making not only the log 
comments but the full repository history available.

However, not everyone on the project is comfortable with git (or is willing to 
give up svn), so I don't see a near-term solution at the moment other than 
improving the existing tools (prepare-ChangeLog, resolve-ChangeLogs, etc.).

Finally, I should note that I've found the detailed ChangeLogs created by 
prepare-ChangeLog--and written with the correct level of detail--to be 
extremely valuable in the past, especially when merging commits to a port.  I 
don't think these should ever go away.

Dave

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[David Kilzer]

On Friday, July 3, 2009 3:20:58 AM, Alexey Proskuryakov wrote:

> 02.07.2009, в 18:05, Adam Roben написал(а):
> 
> > Here's an example entry that follows the format that I (and
> > I think Dave) like:
> >
> > +2009-04-20  Adam Roben  
> > +
> > +Change MemoryStream::createInstance to return a COMPtr
> > +
> > +Part of Bug 25294: All WebKit/win classes should return COMPtrs 
> > from
> > +their static constructor members
> > +
> 
> FWIW, I rarely need to know the bug number alone - I need its
> URL to click or to copy/paste. On the other hand, the
> suggested format makes it so that one needs to skip over "Part
> of Bug 25294: " just to read the bug description, which is not
> an improvement.

This probably isn't a typical example since it's a "Part N of M" bug fix, but 
the important part is that the change is summarized on the first line (after 
the date and patch author) to give a quick overview of the patch.

> >>- I like putting angle brackets "<>" around the URL to set
> >>it off visually from other text.
> 
> Typing those brackets is more work. It's also more difficult
> to copy/paste the URL (you could just copy the whole line and
> paste it into Safari address bar when there were no garbage
> symbols around the URL)


Actually, Safari will strip the "<>" characters for you if you paste them into 
the address bar!  I didn't know this until a couple of months ago, either.

Dave

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

[webkit-dev] content policies

[Roger Pack]

Sorry to just join and post in...just wondering if any consideration
had been given to something akin to Gecko's "content policies" for
filtering content.  This would allow things like adblock plus to work
more easily with webkit based browsers [1].

Or is this something like "create a patch and send it in if you want it."?

Thanks much.
=r
[1] http://adblockplus.org/en/faq_internal
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Inheritance in IDL files/JS bindings

[Sam Weinig]

On Fri, Jul 3, 2009 at 2:42 PM, Drew Wilson  wrote:

> I'm working on refactoring some code out of WebCore::Worker into a common
> base class to be shared between SharedWorker and Worker.
> So I've defined a new AbstractWorker.idl and its associated JS bindings.
> AbstractWorker is not intended to be instantiable, so I don't have a
> constructor generated for it.
>
> interface [CustomMarkFunction, Conditional=WORKERS] AbstractWorker {
> ...
> }
>

GenerateConstructor is a slight misnomer unfortunately.  Event
non-instatiatable interfaces should have one so that they can be exposed on
the global object for use with instanceof and accessing the prototype.


>
> I then changed Worker.idl to make the Worker interface derive from the base
> AbstractWorker interface, like so:
>
> interface [CustomMarkFunction, Conditional=WORKERS] Worker :
> AbstractWorker {
>...
> }
>
> Everything compiles just fine, except that at runtime when I instantiate a
> Worker object from Javascript, I seem to get an instance of AbstractWorker
> instead, and referencing things that should be defined on the Worker
> prototype (like Worker::postMessage) yields undefined. I thought at first
> that perhaps I was doing something wrong with the prototype (setup in
> JSWorkerConstructor.cpp) so I wrote some JS tests, which produced the
> expected results:
>
> log(Worker.toString());   => "[object WorkerConstructor]"
> log(Worker.prototype.toString());=> "[object WorkerPrototype]"
> log(Worker.prototype.postMessage.toString());   => "function
> postMessage() { [native code] }"
>
> And yet when I actually instantiate a Worker object:
>
> var worker = new Worker("resources/worker-common.js");
> log (worker.toString());=> "[object *AbstractWorker*]"
> log (typeof worker.postMessage);=> "*undefined*"
>
> Is there anything special I need to do when implementing inheritance in IDL
> files and JS bindings? I *think* I'm correctly following the example of
> other places where we use inheritance (example HTMLElement -> Element ->
> Node), although there are some options defined in the .idl file like
> "GenerateNativeConverter" and "GenerateToJS" that might be relevant but
> which I couldn't find any documentation for.
>
> Anyhow, I'm digging into this further, but I figured people might be able
> to shed some light on possible causes of this behavior.
>

It is hard to say without a full diff.  Nothing you have described seems too
far off.

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

Re: [webkit-dev] Inheritance in IDL files/JS bindings

[Maciej Stachowiak]

On Jul 3, 2009, at 2:42 PM, Drew Wilson wrote:



Is there anything special I need to do when implementing inheritance  
in IDL files and JS bindings? I *think* I'm correctly following the  
example of other places where we use inheritance (example  
HTMLElement -> Element -> Node), although there are some options  
defined in the .idl file like "GenerateNativeConverter" and  
"GenerateToJS" that might be relevant but which I couldn't find any  
documentation for.


Anyhow, I'm digging into this further, but I figured people might be  
able to shed some light on possible causes of this behavior.


Hard to tell without seeing your diff, but based on this I'd guess the  
bug is in the Worker constructor. Is there any chance it could be  
accidentally instantiating the wrong class, or setting the wrong  
prototype?


 - Maciej

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

[webkit-dev] Inheritance in IDL files/JS bindings

[Drew Wilson]

I'm working on refactoring some code out of WebCore::Worker into a common
base class to be shared between SharedWorker and Worker.
So I've defined a new AbstractWorker.idl and its associated JS bindings.
AbstractWorker is not intended to be instantiable, so I don't have a
constructor generated for it.

interface [CustomMarkFunction, Conditional=WORKERS] AbstractWorker {
...
}

I then changed Worker.idl to make the Worker interface derive from the base
AbstractWorker interface, like so:

interface [CustomMarkFunction, Conditional=WORKERS] Worker :
AbstractWorker {
   ...
}

Everything compiles just fine, except that at runtime when I instantiate a
Worker object from Javascript, I seem to get an instance of AbstractWorker
instead, and referencing things that should be defined on the Worker
prototype (like Worker::postMessage) yields undefined. I thought at first
that perhaps I was doing something wrong with the prototype (setup in
JSWorkerConstructor.cpp) so I wrote some JS tests, which produced the
expected results:

log(Worker.toString());   => "[object WorkerConstructor]"
log(Worker.prototype.toString());=> "[object WorkerPrototype]"
log(Worker.prototype.postMessage.toString());   => "function
postMessage() { [native code] }"

And yet when I actually instantiate a Worker object:

var worker = new Worker("resources/worker-common.js");
log (worker.toString());=> "[object *AbstractWorker*]"
log (typeof worker.postMessage);=> "*undefined*"

Is there anything special I need to do when implementing inheritance in IDL
files and JS bindings? I *think* I'm correctly following the example of
other places where we use inheritance (example HTMLElement -> Element ->
Node), although there are some options defined in the .idl file like
"GenerateNativeConverter" and "GenerateToJS" that might be relevant but
which I couldn't find any documentation for.

Anyhow, I'm digging into this further, but I figured people might be able to
shed some light on possible causes of this behavior.

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

Re: [webkit-dev] ChangeLog

[Joe Mason]

Maciej Stachowiak wrote:
I'm not sure why making an extra copy of the info on update is better 
than doing it on checkin. People update their tree more often than they 
commit, so prima facie this seems like a backwards way to do it. Also, 
svn2cl is much slower than a one-time copy of the latest entry from the 
ChangeLog to the source control commit log, or from the commit log to 
the ChangeLog. So overall it seems much cheaper to have the copying 
happen at commit time.


The difference is that only the people who actually want to use the 
ChangeLog rather than the source control commit log need to do this, 
rather than every patch submitter, and since it isn't actually stored in 
source control you don't need to worry about conflicts.


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

Re: [webkit-dev] Some new mailing lists

[Maciej Stachowiak]

On Jul 3, 2009, at 1:34 PM, Eric Seidel wrote:


I wondered after auto-complete failed me this week, and I accidentally
sent Peter's nomination to webkit-dev instead of webkit-reviewers, why
do we have webkit- at the start of all are lists?  That's just 6 more
characters I have to type to make sure that I auto-complete correctly.
:)

Couldn't they just be:

d...@lists.webkit.org
review...@lists.webkit.org
committ...@lists.webkit.org
h...@lists.webkit.org
j...@lists.webkit.org


It's traditional for open source projects to prefix their list even if  
they have a distinguished domain. If projects did otherwise, then your  
autocomplete oopses would be on "dev@" instead of on "webkit-".


 - Maciej

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

Re: [webkit-dev] ChangeLog

[Maciej Stachowiak]

On Jul 3, 2009, at 1:01 PM, Joe Mason wrote:



I like a discipline that results in good comments about changes,  
and ones that are present even outside the source code control  
system. I often quickly find information about changes made long  
ago by searching change logs and doing even simple searches using  
the other tools available are difficult. For one thing most of them  
are client-server tools while ChangeLog is entirely local.


Switching to a vcs that has local workspaces (like git) will take  
care of this worry, and have many other benefits besides.


Even if sticking with svn, you just need to run svn2cl once when you  
update to get a local copy of the changelog.


I'm not sure why making an extra copy of the info on update is better  
than doing it on checkin. People update their tree more often than  
they commit, so prima facie this seems like a backwards way to do it.  
Also, svn2cl is much slower than a one-time copy of the latest entry  
from the ChangeLog to the source control commit log, or from the  
commit log to the ChangeLog. So overall it seems much cheaper to have  
the copying happen at commit time.


Regards,
Maciej

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

Re: [webkit-dev] ChangeLog

[Maciej Stachowiak]

On Jul 3, 2009, at 12:29 PM, Darin Adler wrote:


On Jul 3, 2009, at 12:04 PM, Jeremy Orlow wrote:

Nothing lists out the modified functions like in your ChangeLog,  
but I guess that's just not something people commonly need.


I often search for old relevant changes by searching for function  
names. At least once a week for the last 5 years.


Me too (or class names).

 - Maciej



   -- Darin

___
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] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Jul 3, 2009, at 10:44 AM, Jeremy Orlow wrote:

On Fri, Jul 3, 2009 at 10:24 AM, Peter Kasting   
wrote:
Since this seems to have become the new bikeshed, I'll chime in with  
my color preference:




Reviewed by John Smith (jsm...@webkit.org)

https://bugs.webkit.org/show_bug.cgi?id=123456
Fix WebKit being not awesome enough.  Make five files more awesome.



FWIW, I agree with those who desire to ditch the ChangeLog.  WebKit  
is the only project I've worked on that does such a thing, and I  
have never gotten any benefit out of it, while I've gotten lots of  
headache (merge conflicts especially).  On Chromium, patches are  
given a detailed ChangeLog-esque description which is visible in the  
review tool and becomes the commit log message as well (which links  
back to the review URL, and is also auto-pasted into the original  
bug report).  This way from any of (bug system, commit logs, review  
system) you can find information about a particular patch or search  
for patches matching some comment.  This turns out to work quite  
well in practice.  In WebKit I try to give my patches these sorts of  
comments when I post them for review, but duplicating info between  
the ChangeLog and the review comments always makes me write less  
than I otherwise would, and review comments tend to get buried in  
the sea of noise from bugzilla.


I agree that the ChangeLog really is duplicate information and  
generally a pain to update.


I know that there are some people who really like them.  Why not  
fill them in automatically?  Just have a tool that once a night/hour/ 
checkin generates entries for the new checkins and puts it somewhere  
on the web or checks it in.


What I do (and I think many of us do) is use a script that  
automatically fills in the commit message from the ChangeLog. I'm not  
sure why it would be better to copy from the commit messages to the  
ChangeLog instead of vice versa, or to do it as a separate step  
instead of at commit time. Are the people who find it a pain to update  
copying by hand or something? For people who use git, who have  
presumably already committed their patches locally before posting for  
review, I think it's fine to do it the other way around and generate  
the ChangeLog from the commit message when pushing the change back to  
the master repository. I don't think it's necessary to maintain  
ChangeLog in your private change branches. I would expect git users to  
have made tools for dealing with this. For people who use SVN  
directly, though there's no other place for our tools to pull the log  
message, so things like "bugzilla-tool post-diff " could not  
properly post your diff with a log entry, commit scripts wouldn't be  
able to fill in the log message that you've already had reviewed, etc.




I know one of the concerns was reviews.  What I do anyway is copy  
the ChangeLog description into the optional long description field  
when posting the patch, why not do that?  Maybe it'd even be easy to  
display that somewhere on the review UI, but otherwise it seems fine  
to just open the review in another tab in case you need to refer  
back to it.


It seems like the ChangeLog is just a work-around for a lack of  
tools.  And it seems like it wouldn't be too hard to make the tools  
we've got better.  (And yes, I'll even help out if that's the  
direction everyone chooses to take.  :-)


ChangeLog is in part just a tradition - all GNU projects do it, and  
for a while many free software projects were doing it. I personally  
search ChangeLog for information fairly often and I don't think the  
commit logs or bug tracker would be equally convenient since they are  
not available in time-ordered plaintext form.



Regards,
Maciej

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

Re: [webkit-dev] Some new mailing lists

[Mark Rowe]

On 2009-07-03, at 13:34, Eric Seidel wrote:


I wondered after auto-complete failed me this week, and I accidentally
sent Peter's nomination to webkit-dev instead of webkit-reviewers, why
do we have webkit- at the start of all are lists?  That's just 6 more
characters I have to type to make sure that I auto-complete correctly.
:)


I don't know about you, but my address book has more than just the  
WebKit lists in it.  Changing the list names like you suggest would  
make it more likely that I would send messages to completely unrelated  
people, rather than accidentally sending them to the wrong list.  No  
matter who you're sending email to, you need to look at the auto- 
completed address and make sure you're sending your message to the  
right place.  It's not rocket science.


- Mark



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Some new mailing lists

[Eric Seidel]

I wondered after auto-complete failed me this week, and I accidentally
sent Peter's nomination to webkit-dev instead of webkit-reviewers, why
do we have webkit- at the start of all are lists?  That's just 6 more
characters I have to type to make sure that I auto-complete correctly.
:)

Couldn't they just be:

d...@lists.webkit.org
review...@lists.webkit.org
committ...@lists.webkit.org
h...@lists.webkit.org
j...@lists.webkit.org

?

(I mean, heck, we could even drop the lists. part too. :)

-eric

On Thu, Jul 2, 2009 at 8:02 PM, Maciej Stachowiak wrote:
> Hello folks,
>
> Based on popular demand, we have created two new mailing lists to handle
> some content that's off-topic for webkit-dev. The new lists are:
>
> webkit-help -- requests for help with building webkit, using WebKit's APIs,
> embedding WebKit, porting WebKit, and so forth
>
>  I suggest that anyone who would like to help others with WebKit topics that
> aren't about the development of WebKit itself, or people interested in
> asking such questions, should subscribe. We will gradually migrate this kind
> of material off of webkit-dev.
>
> webkit-jobs -- post about WebKit-related jobs.
>
>  I suggest that anyone who would like to post or hear about WebKit-related
> employment opportunities should subscribe.
>
> I have subscribed to both lists.
>
> 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] [V8] It's time for V8Proxy to come to Jesus

[Aaron Boodman]

+1: Hooray for any attempts to tame V8Proxy.

- a

On Fri, Jul 3, 2009 at 12:23 PM, Adam Barth wrote:
> If you're uninterested in the V8 bindings, you can skip this email.
>
> Clocking in at 3255 lines (plus a 682-line header file), V8Proxy is
> out of control.  Historically a bridge from the V8 bindings to the V8
> engine, V8Proxy is responsible for a number of tasks including:
>
> 1) Creating new contexts
> 2) Implementing security checks
> 3) Supervising garbage collection
> 4) Caching event listeners
> 5) Executing scripts
> 6) Converting between frames, contexts, and global objects
> 7) Manging DOM wrappers
> 8) etc, etc, etc
>
> I propose we separate these concerns into a number of distinct classes
> that have clear, understandable purposes before things get worse.
>
> Please let me know if you have any in-progress patches to V8Proxy.
> I'd like to lock that file sometime next week while I rip it apart and
> put it back together.
>
> Thanks,
> Adam
>
> P.S., FrameLoader: you've escaped for now, but don't think I'm not watching 
> you.
> ___
> 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] ChangeLog

[Joe Mason]

Darin Adler wrote:
My experience on other projects that don’t use ChangeLog is that many 
check-ins don’t have clear comments or descriptions, and the fact that 
these are missing is considerably easier to overlook. Source code 
control comments can be tricky if you can never delete or edit them.


We already have a rigorous review process that checks for good check-in 
descriptions, though.  Every check-in I've looked at has a description 
identical to its ChangeLog entry - isn't that the policy?


Being able to edit source control comments is a good point.  You can 
edit them with git, although then everyone who pulls from the edited 
repository needs to use a special command to deal with the changed 
history, so it should be used sparingly.  I don't know if this is 
possible for other distributed vcs's.


I like a discipline that results in good comments about changes, and 
ones that are present even outside the source code control system. I 
often quickly find information about changes made long ago by searching 
change logs and doing even simple searches using the other tools 
available are difficult. For one thing most of them are client-server 
tools while ChangeLog is entirely local.


Switching to a vcs that has local workspaces (like git) will take care 
of this worry, and have many other benefits besides.


Even if sticking with svn, you just need to run svn2cl once when you 
update to get a local copy of the changelog.


Someone who thinks an automatically-generated ChangeLog would work well 
could get that working to demonstrate how well it works.


I'd have a sample up already, but I don't have admin access to our server...

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

Re: [webkit-dev] ChangeLog

[Jeremy Orlow]

On Fri, Jul 3, 2009 at 12:29 PM, Darin Adler  wrote:

> On Jul 3, 2009, at 12:04 PM, Jeremy Orlow wrote:
>
>  Nothing lists out the modified functions like in your ChangeLog, but I
>> guess that's just not something people commonly need.
>>
>
> I often search for old relevant changes by searching for function names. At
> least once a week for the last 5 years.


 I meant to say "I'm guessing" not "I guess".  In hindsight, it was a stupid
thing to say.  :-)

I stand by the rest of my email, though.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ChangeLog

[Darin Adler]

On Jul 3, 2009, at 12:04 PM, Jeremy Orlow wrote:

Nothing lists out the modified functions like in your ChangeLog, but  
I guess that's just not something people commonly need.


I often search for old relevant changes by searching for function  
names. At least once a week for the last 5 years.


-- Darin

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

[webkit-dev] [V8] It's time for V8Proxy to come to Jesus

[Adam Barth]

If you're uninterested in the V8 bindings, you can skip this email.

Clocking in at 3255 lines (plus a 682-line header file), V8Proxy is
out of control.  Historically a bridge from the V8 bindings to the V8
engine, V8Proxy is responsible for a number of tasks including:

1) Creating new contexts
2) Implementing security checks
3) Supervising garbage collection
4) Caching event listeners
5) Executing scripts
6) Converting between frames, contexts, and global objects
7) Manging DOM wrappers
8) etc, etc, etc

I propose we separate these concerns into a number of distinct classes
that have clear, understandable purposes before things get worse.

Please let me know if you have any in-progress patches to V8Proxy.
I'd like to lock that file sometime next week while I rip it apart and
put it back together.

Thanks,
Adam

P.S., FrameLoader: you've escaped for now, but don't think I'm not watching you.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes since Version 37894 ?

[Adam Barth]

I believe there have been numerous changes since then.  For example, I
believe the JavaScript engine has been completely re-written.

Adam


On Fri, Jul 3, 2009 at 12:03 PM, Elison Smith wrote:
> Hi,
>
> I had checked out a version of the WebKit codebase last November (version
> 37894) and have done some dev around that.
>
> I now want to sync back with the current head, to be able to make use of all
> the improvements that have gone in since then - due to the contributions of
> the people here.
>
> Can someone please tell me if any "big" changes have gone in since then
> (architectural changes, directory reorganizations) - that will make me
> invest more time into understanding the "new" webkit ?
>
> Thanks.
>
>
> ___
> 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] ChangeLog

[Jeremy Orlow]

To be more clear: Rietveld + gcl (the way Chromium does reviews/checkins)
has you specify a group of files which is called a change list.  Part of
each change list is a description.  Reviewers use and critique this
description, which is much like what's done with the ChangeLog.

Nothing lists out the modified functions like in your ChangeLog, but I guess
that's just not something people commonly need.  (And this could still be
done by an automated script or a new search tool if that'd still be helpful
to people.)

If you haven't taken a look at http://codereview.chromium.org I strongly
suggest you do so.  Rietveld + gcl really do make life easier for us on
Chromium--especially if you're a reviewer.  (It would also solve the 3 lines
of context issue that Julie brought up the other day.)

J

On Fri, Jul 3, 2009 at 10:59 AM, Peter Kasting  wrote:

> On Fri, Jul 3, 2009 at 10:55 AM, Darin Adler  wrote:
>
>> It's backwards to say that the ChangeLog is a workaround for lack of
>> tools. Some day we may see a tool that works so well that we’d be willing to
>> forgo change logs, but we need to see that tool in action first to see that
>> it functions so well it obviates the need for ChangeLog.
>>
>
> I once again suggest Rietveld, which has been suggested here before.
>
> PK
>
> ___
> 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] Changes since Version 37894 ?

[Elison Smith]

Hi,

I had checked out a version of the WebKit codebase last November (version
37894) and have done some dev around that.

I now want to sync back with the current head, to be able to make use of all
the improvements that have gone in since then - due to the contributions of
the people here.

Can someone please tell me if any "big" changes have gone in since then
(architectural changes, directory reorganizations) - that will make me
invest more time into understanding the "new" webkit ?

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[John Sullivan]

On Jul 2, 2009, at 12:40 AM, Eric Seidel wrote:


Agreed.  Although, Darin Adler is about the only person I ever see
fill in per-file/per-function information. :)


Darin is certainly more conscientious about this than most people, but  
a quick glance at WebCore's ChangeLog shows that many other people  
also fill in per-file/per-function information.


I've found this information invaluable on many occasions when tracking  
down why a change was made, not just when.


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

Re: [webkit-dev] ChangeLog

[Peter Kasting]

On Fri, Jul 3, 2009 at 10:55 AM, Darin Adler  wrote:

> It's backwards to say that the ChangeLog is a workaround for lack of tools.
> Some day we may see a tool that works so well that we’d be willing to forgo
> change logs, but we need to see that tool in action first to see that it
> functions so well it obviates the need for ChangeLog.
>

I once again suggest Rietveld, which has been suggested here before.

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

Re: [webkit-dev] ChangeLog

[Darin Adler]

On Jul 3, 2009, at 10:44 AM, Jeremy Orlow wrote:


I agree that the ChangeLog really is duplicate information [...]


The WebKit project change log was inspired by GNU project change logs:  
.


I don’t like ChangeLog specifically.

My experience on other projects that don’t use ChangeLog is that many  
check-ins don’t have clear comments or descriptions, and the fact that  
these are missing is considerably easier to overlook. Source code  
control comments can be tricky if you can never delete or edit them.


I like a discipline that results in good comments about changes, and  
ones that are present even outside the source code control system. I  
often quickly find information about changes made long ago by  
searching change logs and doing even simple searches using the other  
tools available are difficult. For one thing most of them are client- 
server tools while ChangeLog is entirely local.


It's backwards to say that the ChangeLog is a workaround for lack of  
tools. Some day we may see a tool that works so well that we’d be  
willing to forgo change logs, but we need to see that tool in action  
first to see that it functions so well it obviates the need for  
ChangeLog.


Someone who thinks an automatically-generated ChangeLog would work  
well could get that working to demonstrate how well it works.


-- Darin

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Jeremy Orlow]

On Fri, Jul 3, 2009 at 10:24 AM, Peter Kasting  wrote:

> Since this seems to have become the new bikeshed, I'll chime in with my
> color preference:
> 
>
> Reviewed by John Smith (jsm...@webkit.org)
>
> https://bugs.webkit.org/show_bug.cgi?id=123456
> Fix WebKit being not awesome enough.  Make five files more awesome.
>
> 
>
> FWIW, I agree with those who desire to ditch the ChangeLog.  WebKit is the
> only project I've worked on that does such a thing, and I have never gotten
> any benefit out of it, while I've gotten lots of headache (merge conflicts
> especially).  On Chromium, patches are given a detailed ChangeLog-esque
> description which is visible in the review tool and becomes the commit log
> message as well (which links back to the review URL, and is also auto-pasted
> into the original bug report).  This way from any of (bug system, commit
> logs, review system) you can find information about a particular patch or
> search for patches matching some comment.  This turns out to work quite well
> in practice.  In WebKit I try to give my patches these sorts of comments
> when I post them for review, but duplicating info between the ChangeLog and
> the review comments always makes me write less than I otherwise would, and
> review comments tend to get buried in the sea of noise from bugzilla.
>

I agree that the ChangeLog really is duplicate information and generally a
pain to update.

I know that there are some people who really like them.  Why not fill them
in automatically?  Just have a tool that once a night/hour/checkin generates
entries for the new checkins and puts it somewhere on the web or checks it
in.

I know one of the concerns was reviews.  What I do anyway is copy the
ChangeLog description into the optional long description field when posting
the patch, why not do that?  Maybe it'd even be easy to display that
somewhere on the review UI, but otherwise it seems fine to just open the
review in another tab in case you need to refer back to it.

It seems like the ChangeLog is just a work-around for a lack of tools.  And
it seems like it wouldn't be too hard to make the tools we've got better.
(And yes, I'll even help out if that's the direction everyone chooses to
take.  :-)

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Peter Kasting]

Since this seems to have become the new bikeshed, I'll chime in with my
color preference:


Reviewed by John Smith (jsm...@webkit.org)

https://bugs.webkit.org/show_bug.cgi?id=123456
Fix WebKit being not awesome enough.  Make five files more awesome.



FWIW, I agree with those who desire to ditch the ChangeLog.  WebKit is the
only project I've worked on that does such a thing, and I have never gotten
any benefit out of it, while I've gotten lots of headache (merge conflicts
especially).  On Chromium, patches are given a detailed ChangeLog-esque
description which is visible in the review tool and becomes the commit log
message as well (which links back to the review URL, and is also auto-pasted
into the original bug report).  This way from any of (bug system, commit
logs, review system) you can find information about a particular patch or
search for patches matching some comment.  This turns out to work quite well
in practice.  In WebKit I try to give my patches these sorts of comments
when I post them for review, but duplicating info between the ChangeLog and
the review comments always makes me write less than I otherwise would, and
review comments tend to get buried in the sea of noise from bugzilla.

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

Re: [webkit-dev] how to extend the javascript native object?

[Jack Wootton]

To add, it maybe useful to look at the following files in the
JavaScriptCore (Although, personally I didn't find them particularly
easy to understand.)

JavaScriptCore\API\testapi.c
testapi.js


There are also some example programs that do what you want to do, only
with different objects.

JSPong: http://developer.apple.com/SampleCode/JSPong/index.html

JSInterpreter: http://developer.apple.com/samplecode/JSInterpreter/index.html

More programs can be found here:

http://developer.apple.com/SampleCode/Cocoa/idxInternetWeb-date.html



2009/7/3 Jack Wootton :
> Are you saying you wan to add a 'widget' property to the Window
> object?  If so, then the JavaScriptCore API has methods that will
> help you:
>
> Here is the API:
>
> http://gemma.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/index.html#//apple_ref/doc/framework/javascriptcore_fw
>
> If this is what you wish to do, then the following is a rough guide of
> what you need to do:
>
> 1. Create an empty class definition, you can create an empty class
> definition using kJSClassDefinitionEmpty.
> 2. Use the class definition with the JSCoreAPI method "JSClassCreate"
> to create your class.
> 3. Use your new class with JSObjectMake to create your new JSObject
> (this will be your widget object).
> 4  Use JSObjectSetProperty to add your new JSObject as a property of
> the Window object.
>
>
> On Fri, Jul 3, 2009 at 4:51 PM, 胡 波 wrote:
>> I want to extend the javascript native object,such as widget object,and
>> make it inherit window object. That is to say,when the widget object is
>> extended, and we can use it by the window.widget.(method/property) in the
>> html document?
>> 
>> 好玩贺卡等你发，邮箱贺卡全新上线！
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
>
>
> --
> Regards
> Jack
>



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

Re: [webkit-dev] how to extend the javascript native object?

[Jack Wootton]

Are you saying you wan to add a 'widget' property to the Window
object?  If so, then the JavaScriptCore API has methods that will
help you:

Here is the API:

http://gemma.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/index.html#//apple_ref/doc/framework/javascriptcore_fw

If this is what you wish to do, then the following is a rough guide of
what you need to do:

1. Create an empty class definition, you can create an empty class
definition using kJSClassDefinitionEmpty.
2. Use the class definition with the JSCoreAPI method "JSClassCreate"
to create your class.
3. Use your new class with JSObjectMake to create your new JSObject
(this will be your widget object).
4  Use JSObjectSetProperty to add your new JSObject as a property of
the Window object.


On Fri, Jul 3, 2009 at 4:51 PM, 胡 波 wrote:
> I want to extend the javascript native object,such as widget object,and
> make it inherit window object. That is to say,when the widget object is
> extended, and we can use it by the window.widget.(method/property) in the
> html document?
> 
> 好玩贺卡等你发，邮箱贺卡全新上线！
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



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

[webkit-dev] how to extend the javascript native object?

[胡 波]

    I want to extend the javascript native object,such as widget object,and 
make it inherit window object. That is to say,when the widget object is 
extended, and we can use it by the window.widget.(method/property) in the html 
document?


  ___ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
http://card.mail.cn.yahoo.com/___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Alexey Proskuryakov]

02.07.2009, в 18:05, Adam Roben написал(а):

- I prefer having "Bug N: " before the actual bug description  
so I don't have to parse the URL myself for the bug number.  It  
also acts as a visual marker when I read the ChangeLog entry.


<...>

Here's an example entry that follows the format that I (and I think  
Dave) like:



+2009-04-20  Adam Roben  
+
+Change MemoryStream::createInstance to return a COMPtr
+
+Part of Bug 25294: All WebKit/win classes should return  
COMPtrs from

+their static constructor members
+





FWIW, I rarely need to know the bug number alone - I need its URL to  
click or to copy/paste. On the other hand, the suggested format makes  
it so that one needs to skip over "Part of Bug 25294: " just to read  
the bug description, which is not an improvement.


- I like putting angle brackets "<>" around the URL to set it off  
visually from other text.


Typing those brackets is more work. It's also more difficult to copy/ 
paste the URL (you could just copy the whole line and paste it into  
Safari address bar when there were no garbage symbols around the URL)


- I generally move the "Reviewed by" line after the bug number/ 
description/URL.  When you're reading a ChangeLog entry/commit  
message (especially an older one), it's generally much more  
interesting which bug is being fixed rather than knowing who  
reviewed it.  (Also, putting the bug description first makes git's  
one-line description of each commit much more useful than either  
having a list of dates and the person who wrote the patch or having  
a list of patch reviewers.)


No strong opinion about this one. It seems natural to have the  
reviewer mentioned close to contributor (which is what we have now).


- WBR, Alexey Proskuryakov

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

[webkit-dev] JavaScriptCore enhancements

[Zoltan Herczeg]

Hi,

we hope the general arm-jit will soon go to mainline, so we could have
enough time to countinue our work on other JSC enhancements. We would like
to hear your opinion about them (Are they still valid? Has someone else
already been working on it? Which one is important for you?):

- runtime switching between JIT and interpreter: we still owe you a patch 
- which only choose between JIT and interpreter at the creation time of
the global object - will post it soon. We plan to extend this mechanism as
far as we can: real switch in both directions during runtime. Currently
the JavaScript calls are not implemented as real function calls, since the
JavaScript call stack is stored on the RegisterFile. Perhaps we should
extend the entrly leave mechanism somehow.

  Requirements:
- always keep the SF byte code
- always generate the vPC vector

- fast path for math functions (especially floor(a/b)): implementing in a
similar way to the JS apply() function. Detecting in AST level.

- threading: multi core (SMP) architectures are spreading, even for
embedded systems. Is there any (large) parts of WebKit which can be
readesigned to be thread safe? It would help to expolit the advantages of
SMP architectures without significantly increase the memory consumption.

- Could we help you in future JSC enhancements?

Thanks,
Zoltan


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