I started writing some gopher support code out of boredom...
Not too bad but the current code fails to handle items that are split over several chunks of incoming data, since it hooks into the curl fetcher.
On first hand I wanted to write a content renderer but it seems quite overkill for something that can easily be converted to html.
Though after looking at the css and image handlers I'm thinking maybe I could just fake one with only a convert function that would just replace itself with html content.
I'm not sure how to handle it without screwing up the internal state though...
possibly the html data could get the gopher source as parent content ?
I noticed the cocoa build attempts to cp -R some files to the NetSurf.app bundle, but fails with it already existed on some files in .svn/ folders...
I thought gcp had a --exclude option unlike the BSD cp, but it doesn't either, so someone will have to use tar I guess...
The membership list for the society stands as per my previous email. I have
received no resignations nor applications.
I received nominations and seconds for the current committee, as such the
following is the agenda for the AGM, scheduled for 13:00 UTC (14:00 UK, 15:00
CEST) on Saturday 16th April 2011.
2. Secretary's Report
2. Treasurer's Report
3. Chairman's Report
4. Committee Election
5. Project steering
The only nominations I have received for the committee is that of the
incumbents, thus the committee being voted upon is:
Chairman: Michael Drake
Secretary: Daniel Silverstone
Treasurer: John-Mark Bell
If you are unable to attend and wish to register a vote for or against those
nominations then please email me before the meeting starts.
The Project steering item is to review goals for NetSurf 3.0 and our current
situation regarding those goals.
NetSurf Society Secretary
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Thanks to the Secretary and Treasurer for their continued work in these
roles this past year.
Year in review
Approximately this time last year we released NetSurf 2.5. In the last 12
months we have developed and released NetSurf 2.6 and we are on the verge
of releasing NetSurf 2.7. Both of these releases have done much to
advance the state of the project. The changes introduced in them have had
quite a wide scope, improving many aspects of the browser and our
Improvements made to NetSurf's core have affected many areas including
page layout, fetching, content caching, rendering, memory usage and
performance. Perhaps the most obvious new feature has been the addition
of core-controlled windows for global history, hotlist (bookmarks), and
cookie management. These are available for use by all front ends, and
have increased the user-facing functionality on several platforms.
There has been an increasing practice of profiling the browser to direct
development attention to specific aspects of performance.
Some work has been done this year as part of an on-going effort to
simplify and improve the core/front end interface. This work has helped
remove some of the complexity that was previously required in front ends.
NetSurf front ends
The year has seen the implementation of two new front ends. The Mac OS X
front end in particular was written very swiftly, and is already
considered release-ready. The new Atari front end is also showing great
promise, extending the potential userbase for NetSurf further. These
developments further demonstrate the portability of NetSurf.
The Windows port has continued to mature over the last 12 months, however
it lacks an actual maintainer at the moment. This has reduced the
potential for its advancement. By contrast, the RISC OS front end, which
was without a maintainer last year, now has a maintainer and much work has
been done to make the RISC OS code easier to work with.
Some work has been put into creating an environment for automated
cross-compilations of NetSurf for various platforms. This work is still
Much effort has been put into our core libraries. LibCSS in particular
has been improved substantially. These advances have included the
addition of support for certain features of CSS3.
Part of the work carried out on our core libraries has focused on
rationalising their APIs. As yet, none of the core libraries' APIs are
considered fully stable. This means they have not reached "release"
versioning (i.e. 1.x) in this period.
We have seen third party projects making use of some of our core libraries.
Little work has been done on LibDOM in the last 12 months. However, some
recent decisions have established what work is required for LibDOM to
reach the state were NetSurf can start using it.
The main story of NetSurf's development plan since NetSurf 1.x has been
shared widely before. Here it is again:
| 1. New HTML parser (hubbub)
| 2. New CSS engine (libcss)
| 3. New DOM implementation (libdom) < We are here now
| 4. New layout engine
|  was introduced with NetSurf 2.0
|  was introduced with NetSurf 2.5
|  is intended for NetSurf 3.0
|  is intended for NetSurf 4.0
|  is intended for NetSurf 5.0
The practice of profiling NetSurf has identified CSS selection as a
significant performance issue. The reason for this is understood, and
performance is expected to be vastly improved once NetSurf uses LibDOM
instead of LibXML. Since this coincides with the general plan, the
development focus after NetSurf 2.7 is expected to centre around LibDOM.
The next 12 months
It will be ideal if we are in a position to release NetSurf 3.0 with
LibDOM in the next year. We should certainly aim to make progress on this
during the period.
In addition to working toward milestone 3, as outlined above in the main
story of NetSurf's development, we can also complete some side quests this
year. Some good candidates for attention that have been mentioned before
+ Moving frames handling to the core.
(Requested by several front end maintainers.)
+ Rewriting URL handling.
(Frequently comes up amongst core developers.)
+ Making the core a library.
(Routinely sought-after by front end and core developers alike.)
There are many others on the Development Plan wiki page:
Continued work on automated cross-compilation and also automated testing
will be of great value to the project.
Finally we should produce a roadmap for LibSVGTiny. Currently it is not
released alongside our other libraries. Could it use LibCSS? Maybe Expat
and LibDOM instead of LibXML? Support for more SVG features? Output
shape as polygon, rather than path, when shape has only straight lines?
NetSurf project steering will be discussed at the forthcoming AGM.
Thanks to everyone involved in the project for their contributions over
the last 12 months!
Michael Drake (tlsa) http://www.netsurf-browser.org/
Indeed my goal is to help you making netsurf better. Please see the attached valgrind log. (compressed with gzip).
Also the other files which will help you identify my system configuration - a standard Ubuntu 10.04.
-------- Original-Nachricht --------
> Datum: Thu, 7 Apr 2011 09:50:32 +0100
> Von: Daniel Silverstone <dsilvers(a)netsurf-browser.org>
> An: Frank Gerlach <frankgerlach22(a)gmx.de>
> CC: NetSurf Development Discussion List <netsurf-dev(a)netsurf-browser.org>
> Betreff: Re: Fwd: Please Test Netsurf With valgrind
> On Thu, Apr 07, 2011 at 09:06:11AM +0200, Frank Gerlach wrote:
> > I grabbed your email addresses indiscriminately from netsurf source
> code. I
> > do think this does not amount to spamming, as it is security-related:
> Why did you not stop to think about (a) which frontends you were
> about, and (b) whether or not the project had an appropriate mailing list
> > The problem: Lots of illegal memory operations while executing Netsurf.
> > How to reproduce:
> > A) get current Netsurf code
> > B) get all prerequesites (xml parsers and all that)
> > C) Compile A) and B) on Ubuntu 10.04
> Compile which frontend? Certainly the implication of Ubuntu means you
> not have been sending this email to the AmigaOS frontend developers, or
> any of
> the other uniquely-frontend-only developers who aren't related to what I
> will be a GTK build of NetSurf.
> > E) run with
> > valgrind <netsurf executable>
> > F) Surf the net. (spiegel.de, bbc.co.uk, wired.com, slashdot,
> > G) Look at the valgrind output. Looks extremely bad (illegal free()s and
> > of other nasty errors).
> It would have been significantly more useful if you'd attached the errors
> are concerned about, but never mind.
> > Valgrind is an excellent tool to "cheaply" improve source quality and I
> > suggest you use it before you check in code. All checked in code should
> > report valgrind errors (with the procedure described above). Valgrind is
> > normally very accurate !
> If you think we do not use valgrind regularly, both in memcheck and
> modes, then you are sorely mistaken. Your approach to this message, and
> language you used, was actually strongly offensive (and did get caught in
> several people's spam traps since it was an identical message to several
> addresses which boiled down to the same person). I will give you the
> of the doubt and assume you were honestly trying to help rather than to
> our development practices and rant at us.
> You will find that NetSurf 2.7 has been branched, along with its
> libraries, within our SVN repository and we are gearing up for a release.
> you honestly want to help us along the way, please join us on #netsurf on
> Freenode IRC network and help us to track down and correct the issues you
> able to identify for us.
> Daniel Silverstone http://www.simtec.co.uk/
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
On Thu, Apr 07, 2011 at 09:06:11AM +0200, Frank Gerlach wrote:
> I grabbed your email addresses indiscriminately from netsurf source code. I
> do think this does not amount to spamming, as it is security-related:
Why did you not stop to think about (a) which frontends you were complaining
about, and (b) whether or not the project had an appropriate mailing list for
> The problem: Lots of illegal memory operations while executing Netsurf.
> How to reproduce:
> A) get current Netsurf code
> B) get all prerequesites (xml parsers and all that)
> C) Compile A) and B) on Ubuntu 10.04
Compile which frontend? Certainly the implication of Ubuntu means you should
not have been sending this email to the AmigaOS frontend developers, or any of
the other uniquely-frontend-only developers who aren't related to what I assume
will be a GTK build of NetSurf.
> E) run with
> valgrind <netsurf executable>
> F) Surf the net. (spiegel.de, bbc.co.uk, wired.com, slashdot, theregister)
> G) Look at the valgrind output. Looks extremely bad (illegal free()s and lots
> of other nasty errors).
It would have been significantly more useful if you'd attached the errors you
are concerned about, but never mind.
> Valgrind is an excellent tool to "cheaply" improve source quality and I
> suggest you use it before you check in code. All checked in code should not
> report valgrind errors (with the procedure described above). Valgrind is
> normally very accurate !
If you think we do not use valgrind regularly, both in memcheck and callgrind
modes, then you are sorely mistaken. Your approach to this message, and the
language you used, was actually strongly offensive (and did get caught in
several people's spam traps since it was an identical message to several
addresses which boiled down to the same person). I will give you the benefit
of the doubt and assume you were honestly trying to help rather than to slander
our development practices and rant at us.
You will find that NetSurf 2.7 has been branched, along with its prerequisite
libraries, within our SVN repository and we are gearing up for a release. If
you honestly want to help us along the way, please join us on #netsurf on the
Freenode IRC network and help us to track down and correct the issues you seem
able to identify for us.
Daniel Silverstone http://www.simtec.co.uk/
I'm working on libCSS just now, implementing support for some of the 'page' properties (page-break-before, page-break-after etc). I've noticed what I think is a bug in css_computed_style_compose, and I wanted to run it past the experts before trying to fix it, in case I've got the wrong end of the stick.
The symptoms are that properties that should by default /not/ inherit are inheriting.
The cause, I think, is in css_computed_style_compose. It happens when 'child' and 'result' point to the same object, and parent has 'page' group properties set (I think this will apply equally to the current 'uncommon' group), but the child does not. In the loop, when we get to the first set property in a group, it is composed (because the group in parent is not NULL), which causes the group to be allocated in the result object (the setters allocate the group if it doesn't already exist), and memset to 0. This meant that, because 'child' and 'result' are the same, all the other properties in 'child' are now set to 0 (by the memset when the group is set up). 0 is 'inherit'. Properties that /should/ have a non-inherit initial value are now set to inherit erroneously.
The solution is either to call initial_... for all the properties in the group when it's set up (in the "ENSURE_PAGE" macro, or equivalent), or maybe to change the docs to state that child and result may NOT be the same object.
Does this sound like a plausible diagnosis?