GSOC project "add dom support to NS" one month summary
by Bo Yang
Hi,
Today is June, 23, it is exactly one month since the start of GSOC
coding phrase. I think it is better to make a progress summary of my
project.
>From the Plan:
1. Complete the missing implementation of Core module and test it.
There are some functions left as unimplemented in the existing Core
module, I will complete these functions firstly. And I think it is
better to test earlier than later, so it is testing time after the
Core module completion. W3C provides a DOM Test Suite at
http://www.w3.org/DOM/Test/ which is used to test whether any DOM
implementation is standard compliant. I will write some XSLT files to
translate the test files, and test the Core implementation. This task
will cost me about one month, I estimate.
The things completed:
1. The DOMTS for Core module;
2. Rewriting string.c node.c attr.c characterdata.c to use lwc_string
3. Add comment.c typeinfo.c
4. Refactoring element.c (nearlly complete except the Namesapce
looking part) namednodemap.c
5. Add a new hash_table to libdom
6. Make many minor changes to the code
The work coming:
1. Rewrite document.c
2. Rewrite doc_fragment.c text.c cdatasection.c entity_ref.c
document_type.c pi.c to use lwc_string
3. Add dom_entity dom_notation
4. Test the dom core implementation
Generally, I am behind the planned schedule. On average, I spend two
or three hours one day on the project. More time will be spent on
after July 18, when my real summer holiday comes.
And I think I have underestimate the workload of the Core module. It
is the most hard part of this project, and I think I need one or two
more weeks to complete the coding and one more week to test it. After
that, the Events and HTML module may be more easy to complete.
Anyway, I am trying my best to design & implement the libdom. I am
confident that I can make a good DOM implement for NS. Thanks!
Regards!
Bo
13 years, 7 months
Review workflow
by Daniel Silverstone
Hiya,
This mail is intended to provide a very very basic hash-up of my review
workflow.
Firstly, there are three tools in SVN in the tools project:
svn://svn.netsurf-browser.org/trunk/tools
In the svn/ directory in there is netsurf-review-{diff{,-list},merge}
To use the tools effectively, check these out somewhere and ensure that
either that dir is on the PATH, or that you symlink the tools into
somewhere which is. (I use symlinks in ~/bin)
The three tools are:
netsurf-review-merge
This tool takes a branch name (of the form person/branch) checks that
the CWD has no local changes, and then determines the point at which the
branch was made and merges that onto the current branch. Don't use this
if you're using svnmerge -- use svnmerge instead. This tool is only
meant for trivial feature branches, not for long-term branches.
netsurf-review-diff
This tool takes the status and formats up a review diff. Review diffs
list each new file, each deleted file and each changed file in different
parts, it also provides a diffstat and if there's a precis for the
branch in /tmp/precis then it includes that in the output.
You can change to a trunk dir, merge your branch, and then use this tool
to look at your change in the same way that a reviewer will look.
netsurf-review-diff-list
This tool uses netsurf-review-diff, offers to allow you to write a
precis if you want (and haven't already) and then attempts to submit it
to the netsurf-dev mailing list with a subject line composed of 'Review:
' and then anything you put on the command line.
It assumes that your local username can be stuffed onto
@netsurf-browser.org to use as a "from" address. If it can't, set
NETSURF_USERNAME to your @netsurf-browser.org local-part. If you don't
have such a local part then you shouldn't be issuing review diffs.
It also assumes that your local gecos is good. If that isn't good, set
NETSURF_REALNAME to your real name (no brackets, no anglebrackets, etc)
You can pass --test as the first argument to netsurf-review-diff-list to
get it to put the mail it would have submitted on stdout instead.
Note that netsurf-review-diff-list relies on a local MTA which
functions. If all else fails, you ought to be able to use it on the
machine which hosts netsurf-browser.org if you have a login.
My workflow
^^^^^^^^^^^
1. Prepare a pristine trunk
2. Merge the branch into this trunk
If there are conflicts which aren't trivial, reject the merge at this
point.
3. Check that the branch does as advertised. i.e. verify it builds,
passes tests, tests any new functionality if appropriate. Ensure it
builds both in release and in debug if appropriate.
If it fails any of this, reject the merge at this point.
4. Run netsurf-review-diff | less and have a very cursory glance over
the diff to ensure there's nothing *huge* like comments with rude words
in, etc.
If there's anything huge, reject the merge at this point.
5. Run netsurf-review-diff-list and give it a suitable subject and
precis.
6. On-list, in your MUA, perform your review as a reply. This ensures
that the review diff is quoted properly etc.
Once the branch is in a state that it's worth merging...
a. Follow 1/2 above
b. Update a version number if needed.
c. Do a final build/run-test in debug and release
d. commit with a message along the lines of:
"merge person/branch rBLAH:OTHER: Feature short desc. r=myusername"
The rfoo:bar is optional if it's a single merge and then the branch is
considered dead. the r=myusername means that we can see if the reviewer
differs from the person doing the merge. E.g. it's quite possible for me
to make a branch, issue a review to the list, jmb could then review it
for me, and then I can commit it r=jmb. Providing the review is done and
a reviewer says "OK" then there's no requirement for the reviewer to be
the person who commits it, providing all of 1 to 6 above is followed,
and then a to d.
I hope this helps with other people who are thinking of doing reviews in
a similar way.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
13 years, 7 months
Review: Final merge variant of lwc_string_hash_value
by Daniel Silverstone
Precis:
This is the final version of Bo Yang's patch, rather than really being a
review, I'm posting this to the list to explain a few things for Bo and for
reference if anyone else works with one of the libs with tests.
Specifically the issue was that Bo hadn't actually tried compiling the tests
and running them. Test suites exist for a reason, which is why I asked for a
test in my first review of Bo's patch. Unfortunately, while tests were added as
per my request, they didn't compile.
It's important to run:
make BUILD=debug test
*AND*
make BUILD=release test
in libraries such as libwapcaplet, because some tests only run in debug mode
because they actually test that the asserts fire. Asserts are, naturally, not
compiled into a release binary.
Also, in something like libwapcaplet, the style is to include every header you
need in your header files directly. i.e. since Bo used uint32_t in the API, he
should have put #include <stdint.h> into it. I didn't catch all this on my
previous reviews because I had made the false assumption that he had compiled
and run the tests. I shall try not to make this mistake in future.
This isn't meant to be a rant, just an indication of some extra work to do
before you request reviews in future. This applies to everyone, not just Bo.
Added files
Changed files
include/libwapcaplet/libwapcaplet.h | 11 +++++++++++
src/libwapcaplet.c | 9 ++++++++-
test/basictests.c | 16 ++++++++++++++++
3 files changed, 35 insertions(+), 1 deletion(-)
Index: test/basictests.c
===================================================================
--- test/basictests.c (revision 6881)
+++ test/basictests.c (working copy)
@@ -174,6 +174,12 @@ START_TEST (test_lwc_string_length_abort
}
END_TEST
+START_TEST (test_lwc_string_hash_value_aborts)
+{
+ lwc_string_hash_value(NULL);
+}
+END_TEST
+
#endif
START_TEST (test_lwc_context_creation_ok)
@@ -381,6 +387,12 @@ START_TEST (test_lwc_extract_data_ok)
}
END_TEST
+START_TEST (test_lwc_string_hash_value_ok)
+{
+ lwc_string_hash_value(intern_one);
+}
+END_TEST
+
/**** And the suites are set up here ****/
void
@@ -444,6 +456,9 @@ lwc_basic_suite(SRunner *sr)
tcase_add_test_raise_signal(tc_basic,
test_lwc_string_length_aborts,
SIGABRT);
+ tcase_add_test_raise_signal(tc_basic,
+ test_lwc_string_hash_value_aborts,
+ SIGABRT);
#endif
tcase_add_test(tc_basic, test_lwc_context_creation_ok);
@@ -471,6 +486,7 @@ lwc_basic_suite(SRunner *sr)
tcase_add_test(tc_basic, test_lwc_context_string_isequal_ok);
tcase_add_test(tc_basic, test_lwc_context_string_caseless_isequal_ok);
tcase_add_test(tc_basic, test_lwc_extract_data_ok);
+ tcase_add_test(tc_basic, test_lwc_string_hash_value_ok);
suite_add_tcase(s, tc_basic);
srunner_add_suite(sr, s);
Index: include/libwapcaplet/libwapcaplet.h
===================================================================
--- include/libwapcaplet/libwapcaplet.h (revision 6881)
+++ include/libwapcaplet/libwapcaplet.h (working copy)
@@ -11,6 +11,7 @@
#include <sys/types.h>
#include <stdbool.h>
+#include <stdint.h>
/**
* Memory allocator type
@@ -126,5 +127,15 @@ extern const char *lwc_string_data(lwc_s
*/
extern size_t lwc_string_length(lwc_string *str);
+/**
+ * Retrieve (or compute if unavailable) a hash value for the content of the string.
+ *
+ * @note This API should only be used as a convenient way to retrieve a hash
+ * value for the string. This hash value should not be relied on to be
+ * unique within an invocation of the program, nor should it be relied upon
+ * to be stable between invocations of the program. Never use the hash
+ * value as a way to directly identify the value of the string.
+ */
+extern uint32_t lwc_string_hash_value(lwc_string *str);
#endif /* libwapcaplet_h_ */
Index: src/libwapcaplet.c
===================================================================
--- src/libwapcaplet.c (revision 6881)
+++ src/libwapcaplet.c (working copy)
@@ -7,7 +7,6 @@
*/
#include <string.h>
-#include <stdint.h>
#include <assert.h>
#include "libwapcaplet/libwapcaplet.h"
@@ -342,3 +341,11 @@ lwc_string_length(lwc_string *str)
return str->len;
}
+
+uint32_t
+lwc_string_hash_value(lwc_string *str)
+{
+ assert(str);
+
+ return str->hash;
+}
Conflicted files
Removed files
13 years, 7 months
Review: Add hash extract feature to libwapcaplet (round 2)
by Daniel Silverstone
Precis:
This is round 2 of the add-hash-extract-to-libwapcaplet stuff for Bo Yang.
Added files
Changed files
include/libwapcaplet/libwapcaplet.h | 10 ++++++++++
src/libwapcaplet.c | 8 ++++++++
test/basictests.c | 16 ++++++++++++++++
3 files changed, 34 insertions(+)
Index: test/basictests.c
===================================================================
--- test/basictests.c (revision 6881)
+++ test/basictests.c (working copy)
@@ -381,6 +381,18 @@ START_TEST (test_lwc_extract_data_ok)
}
END_TEST
+START_TEST (test_lwc_get_hash_value_aborts)
+{
+ lwc_get_hash_value(NULL);
+}
+END_TEST
+
+START_TEST (test_lwc_get_hash_value_ok)
+{
+ lwc_get_hash_value(intern_one);
+}
+END_TEST
+
/**** And the suites are set up here ****/
void
@@ -471,6 +483,10 @@ lwc_basic_suite(SRunner *sr)
tcase_add_test(tc_basic, test_lwc_context_string_isequal_ok);
tcase_add_test(tc_basic, test_lwc_context_string_caseless_isequal_ok);
tcase_add_test(tc_basic, test_lwc_extract_data_ok);
+ tcase_add_test_raise_signal(tc_basic,
+ test_lwc_get_hash_value_aborts
+ SIGABRT);
+ tcase_add_test(tc_basic, test_lwc_get_hash_value_ok);
suite_add_tcase(s, tc_basic);
srunner_add_suite(sr, s);
Index: include/libwapcaplet/libwapcaplet.h
===================================================================
--- include/libwapcaplet/libwapcaplet.h (revision 6881)
+++ include/libwapcaplet/libwapcaplet.h (working copy)
@@ -126,5 +126,15 @@ extern const char *lwc_string_data(lwc_s
*/
extern size_t lwc_string_length(lwc_string *str);
+/**
+ * Retrieve (or compute if unavailable) a hash value for the content of the string.
+ *
+ * @note This API should only be used as a convenient way to retrieve a hash
+ * value for the string. This hash value should not be relied on to be
+ * unique within an invocation of the program, nor should it be relied upon
+ * to be stable between invocations of the program. Never use the hash
+ * value as a way to directly identify the value of the string.
+ */
+extern uint32_t lwc_string_hash_value(lwc_string *str);
#endif /* libwapcaplet_h_ */
Index: src/libwapcaplet.c
===================================================================
--- src/libwapcaplet.c (revision 6881)
+++ src/libwapcaplet.c (working copy)
@@ -342,3 +342,11 @@ lwc_string_length(lwc_string *str)
return str->len;
}
+
+uint32_t
+lwc_string_hash_value(lwc_string *str)
+{
+ assert(str);
+
+ return str->hash;
+}
Conflicted files
Removed files
13 years, 7 months
progress report N° 4
by Mark
Hi All,
well the gtk+ improvement gsoc project is very close to completion,
subject to additional suggestions, it's moving along nicely; Following
our discussion at #netsurf it looks as though I'll be contemplating the
windows port once I've reached that stage, in 5-10 days' time I'd
venture; unless Paul's treeview branch is merged in time, when I'll
[hopefully briefly] address the question of whether the gtk interface
for history/hotlist needs adding to;
Feature
Status Now
/http://www.netsurf-browser.org/developers/gsoc/2009ideas/
Find
Migration from riscos/amiga to core, Implementation in GTK; branch
awaiting review/merger
Bookmarks
Branch development awaiting glade branch review/merger; currently
waiting for Paul B's core work to complete
Improved right-click menu
Improved implementation in GTK; more improvement in toolbar
customisation branch, right-click aspect now complete
Adjust toolbar buttons to match GTK prefs
Now Implemented in trunk
File Uploads
Branch ready for review/merger
View Source
Implemented in GTK; could add features; could migrate to core
Documentation
No progress yet
Favicons
core/GTK implementation branch written; awaiting review/merger
/http://www.netsurf-browser.org/documentation/progress/
Documentation GTK
See above [yet to implement]
Find Text GTK
See above [branch ready]
Full Save GTK
GTK implementation branch written; migration of riscos / amiga
implementations to core; branch awaiting review/merger
History-global GTK
Branch ready for review / merger
Hotlist/Bookmarks GTK
See above [waiting]
Save as text GTK
GTK implementation branch written; awaiting review/merger
Toolbar customisation GTK
prefs complete; full customisation implementation largely complete
Themes GTK
Theme addition from local directory largely complete;
theme from content-type yet to implement; then customisation/theme code
needs tidying / efficiency / memory management / debugging / testing
/Additional/
Web search/ /
core / GTK implementation branch written; awaiting review / merger
Improved tabbed browsing
More implementation dispersed in patches/branches : patch partially
undrawn new tab; view source in new tab; focus new tab, blank new tab;
More progress possible
glade file simplification
more rational organisation of Main NetSurf glade file; made into several
files, one for every GTK window
Best
Mark
http://www.halloit.com
Key ID 046B65CF
13 years, 7 months
Review: Add hash extract feature to libwapcaplet
by Daniel Silverstone
Precis:
This is Bo Yang's first attempt at a patch to add a feature to
libwapcaplet to allow the user of an lwc_string to retrieve a
hash value of the string without necessarily having to compute it
themselves. This allows lwc_string objects to be more usefully
used as keys in tables or put into sets etc.
Added files
Changed files
include/libwapcaplet/libwapcaplet.h | 15 +++++++++++++++
src/libwapcaplet.c | 7 +++++++
2 files changed, 22 insertions(+)
Index: include/libwapcaplet/libwapcaplet.h
===================================================================
--- include/libwapcaplet/libwapcaplet.h (revision 6881)
+++ include/libwapcaplet/libwapcaplet.h (working copy)
@@ -126,5 +126,20 @@ extern const char *lwc_string_data(lwc_s
*/
extern size_t lwc_string_length(lwc_string *str);
+/**
+ * Retrieve the hask value of the string.
+ *
+ * @note The API should be used as a convenient way of get the underlaid
+ * string's hash value. And the hash value should never be used to
+ * identified the string, some code as:
+ *
+ * if (hashvalue == 0xb1ab1a00) {
+ * assume string == "div"
+ * }
+ *
+ * should never appear. The hash value is suitable for a hash table
+ * key.
+ */
+extern uint32_t lwc_string_hash_value(lwc_string *str);
#endif /* libwapcaplet_h_ */
Index: src/libwapcaplet.c
===================================================================
--- src/libwapcaplet.c (revision 6881)
+++ src/libwapcaplet.c (working copy)
@@ -342,3 +342,10 @@ lwc_string_length(lwc_string *str)
return str->len;
}
+
+uint32_t lwc_string_hash_value(lwc_string *str)
+{
+ assert(str);
+
+ return str->hash;
+}
Conflicted files
Removed files
13 years, 7 months
A patch for libwapcaplet
by Bo Yang
Hi,
Sometimes, we need to use the lwc_string as a key of hash_table,
and I think the best key for a lwc_string is the hash value of it. So,
I add a new function to expose the hash value of a lwc_string, please
review it, any comments are welcomed, thanks!
Regards!
Bo
13 years, 7 months
color problem for big endian fixes ??
by Bernd Roesch
Hi,
I dont understand what goes wrong, i test in func
fb_colour_to_pixel that the gfx Card need data in rgba mode.
this testcode give a full red display
static inline uint32_t fb_colour_to_pixel(colour c)
{
c = 0xff000000;
return c;
}
so all should work ok with the netsurf code.But c contain abgr values
instead what i expect argb values
below code work and colors are correct for text, fb_32bpp_fill.So it seem
sure data come in abgr Format.
But colors
are wrong for images.here i need red and blue change because the netsurf
image on welcome page is yellow.but the right rectangle is blue.
please help, what is wrong.
normaly i must add in fb_32bpp_bitmap old code, but this seem not clean.
i find only this place with __BIG_ENDIAN check
//colour abgr
// pixel format rgba
#if __BYTE_ORDER == __BIG_ENDIAN
static inline colour fb_32bpp_to_colour(uint32_t pixel)
{
//return (pixel >> 8) & ~0xFF000000U;
return (((pixel & 0xFF000000) >> 24 ) |
((pixel & 0xFF0000) >> 8) |
((pixel & 0xFF00) << 8));
}
/* convert a colour value to a 32bpp pixel value ready for screen output */
static inline uint32_t fb_colour_to_pixel(colour c)
{
//c = 0xff000000;
//return c;
return (((c & 0xFF) << 24 ) |
((c & 0xFF00) << 8) |
((c & 0xFF0000) >> 8) | ((c & 0xFF000000) >> 24));
}
Bye
13 years, 7 months
GSoC first week
by Paweł Blokus
I am going to spend the first coding week refactoring the tree view
code. With the work I've done in the past few days I realised that it
would be useful to get the global history from riscos available for
other platforms in order to have a testing ground for the widget. The
code needed little changes to work at all but still might need some
better insight. Although it extends the time needed for this part of
my project it's something I would have to do anyway later, so I think
it's a better solution than writing code used solely for testing.
At the end of the week I would like to have done the following things:
- the treeview history working on any platform
- platform dependent code from tree view reduced to a minimum
- sorting option for a tree node
13 years, 7 months
My GSoC proposal/timeline
by Paweł Blokus
As I promised, I am posting my proposal in order to clarify the scope
of my project. This is the original proposal, so it might be a little
outdated. One big difference is that I won't be doing the 'Cache and
config' part.
13 years, 7 months
