Hi, First I'd like to quickly introduce myself. I'm David, from Newcastle, England, and have recently graduated from a MSc in Internet and Distributed Systems, at the University of Durham. I'd like like to get involved in WebKit development to gain some much needed experience, and help improve something I use frequently and that I'm interested in. As I've limited knowledge of C/Obj-C (i'm mainly a Java developer), I though one of the best places to start would be on the code clean up and documentation. Is there any timeframe when or if WebKit will compile on 10.3.9? I don't have access to Tiger and can't afford to buy it, so I can't make any changes until it compiles. I don't have access to the Tiger DVD to get the missing header files either. At one stage JavaScriptCore compiled on Panther (it fails again now), so I decided to have a go at cleaning up that part of the project. Unfortunately it took two days to clean up every class, and by that stage when I performed the regression test, there were a number (even though I didn't make any real changes). It seemed that it actually passed many more than the master copy though. I thought I would submit the changes anyway, but i followed the steps on the site to produce a patch file, but it only created a blank file. I'm not sure if that was something to do with the app not compiling, or if I did anything wrong. Most the changes were just white-space changes. While working on the code cleanup there were a number of areas that different programmers implemted differently which were not covered by the style guidelines. Maybe there should be some guidelines to cover these: 1. Should first level statements after the method name be indented 4 spaces too? mostly they are indented twice e.g. methodName(param) { statement; } instead of methodName(param) { statement; } 2. Case statements do not seem to be mentioned. some use {} and some don't, even in the same switch block. Should all case statments have or not have braces? if they should, should they be like : } case CSSSelector::List: { OR case CSSSelector::List: { statemnts; } case ... 3. Braces are not mandatory when the statements are only one line for 'if and 'for' etc. Sometimes no braces are used and sometimes not. Should there be a guideline to keep this consistent. Personally I prefer always using braces, as it is clearer, but not everyone may agree. 4. There should possibly be a guideline for how many spaces to indent when wrapping a line that is too long to fit on one line. 5. Often code goes on for pages without any line breaks at all. Possibly there should be a guideline on when to leave a line space between blocks of code, such as leaving a line before a return statement at the end of a method or between and if or for block. 6. Not really knowing C, i wasn't sure what the '#if apple changes' -- and other such if constructs that xCode highlights in red -- are for? I wasn't sure if these should be indented like a normal if statement? 7. There are no guidelines for casting. I personally prefere: var = (cast) methodName(param, otherParam); but often they were formatted without the space, such as : var = (cast)methodName(param, otherParam); I think that is it for the moment. sorry for going on, but after spending two days at code reformatting, I noticed a few things. Thanks for your time, hopefully in the future will be able to make some contribution to the project, Regards, David ------------------------------------------------------ David Storey University of Durham ------------------------------------------------------
On 6/25/05, David Storey <storey.david@gmail.com> wrote:
Is there any timeframe when or if WebKit will compile on 10.3.9? I don't have access to Tiger and can't afford to buy it, so I can't make any changes until it compiles.
Unfortunately the only people who can do it at the moment are Apple engineers, since it will require a different libWebKitSystemInterface.a - last I heard Hyatt was almost there, but busy. So *shrug*.
At one stage JavaScriptCore compiled on Panther (it fails again now),
Odd. It compiled on Panther about 48 hours ago for me, with no changes. -- Finlay
On Jun 25, 2005, at 5:03 PM, David Storey wrote:
At one stage JavaScriptCore compiled on Panther (it fails again now), so I decided to have a go at cleaning up that part of the project. Unfortunately it took two days to clean up every class, and by that stage when I performed the regression test, there were a number (even though I didn't make any real changes). It seemed that it actually passed many more than the master copy though. I thought I would submit the changes anyway, but i followed the steps on the site to produce a patch file, but it only created a blank file. I'm not sure if that was something to do with the app not compiling, or if I did anything wrong. Most the changes were just white-space changes.
Try "cvs diff -u" in the JavaScriptCore directory. However, this will NOT include any "new" files, which was the purpose of the script (if I remember correctly). It won't include "new" files because you can't run "cvs add" on the files with read-only access. I know Panther's version of the cvs command-line tool was based on version 1.10.x. This version is now called "ocvs" (for old cvs) in Tiger, and the cvs command is now version 1.11.x. This may explain why the script didn't work for you. You might try compiling a newer version of cvs for Panther (or look at installing Fink or Darwin Ports). If you make sure it appears "first" in your $PATH environment variable, then the script make start working.
While working on the code cleanup there were a number of areas that different programmers implemted differently which were not covered by the style guidelines. Maybe there should be some guidelines to cover these:
If you look at the webkit.opendarwin.org web site, there is a page for coding style guidelines: http://webkit.opendarwin.org/coding/coding-style.html
6. Not really knowing C, i wasn't sure what the '#if apple changes' -- and other such if constructs that xCode highlights in red -- are for? I wasn't sure if these should be indented like a normal if statement?
The #if and #endif stuff are "pre-processor" directives. Unlike Java, compiling C, C++, Obj-C, and Obj-C++ involves a "pre-processor" stage that processes the source code before the compiler parses it. The #include statements are processed during this stage as well (even though they're roughly equivalent to import statements in Java). Dave
participants (3)
-
David D. Kilzer
-
David Storey
-
Finlay Dobbie