http://blog.gmane.org/gmane.comp.web.netsurf.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.web.netsurf.devel/9668 <pre>So, recently we've had a flurry of bizarre emails to our help&lt; at &gt; and webmaster&lt; at &gt; addresses, of which I have attached a selection. Anybody know what's going on? Somebody posted a misleading review somewhere or something? B. </pre> Rob Kendrick 2013-05-23T09:17:56 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9664 <pre>We continue to compile for the Mac OS X cocoa frontend on both PowerPC (OS 10.5 leopard) and x86 (OS 10.6 snow leopard). The Continuous Integration (CI) system uses two real mac mini computers[1] as build slaves as Mac OS X cannot currently be reliably cross compiled for. Recently the PPC CI system build slave (chimera) had a catastrophic hard drive failure and required a complete OS and development tools reinstall. This re-install took an extended period of time as the PPC system is somewhat slow compared to other targets. Generally we use SSD in our build slaves, however I was unwilling to bear the cost of a 2.5inch PATA SSD for this system so its been reinstalled with a reconditioned Seagate 5200 RPM drive. The cocoa frontend currently has no maintainer and I am interested in hearing from any actual users to give an indication as to whether it is worth investing any additional resources on this platform. So any actual users or developers, please speak up now! Note I am not asking for opinion about other considerations such as diversity and how nice it is to have a wide range of platforms supported, purely if there are any actual users. If there are none I shall simply remove these targets from the CI system on the next occasion this rather old and *very* slow hardware fails. [1] http://www.flickr.com/photos/29254252&lt; at &gt;N06/8519229958/in/set-72157626712232414 </pre> Vincent Sanders 2013-05-19T09:16:44 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9663 <pre>I recently had opportunity to integrate a translation platform into the NetSurf workflow[1]. This integration has been performed on the transifex platform, is complete, and does work reasonably. However without real actual translations it is not useful. I would like to invite anyone with translation skills to improve the netsurf project by using this web interface to enter translations[2]. I am especially interested in any of our current developers providing translatiopns who wish to become translation reviewers to ensure we maintain a high quality. The current number of translated/reviewed strings by language is: English: 100%/100% French: 93%/93% Dutch: 92%/92% German: 92%/92% Italian: 92%/92% Spanish: 87%/0% Chinese: 0%/0% The review status is purely based on the existing corpus (i.e. if it is in the current set of translations it is considered reviwed) The spanish translation is currently a pure machine translation althouh we already have some volunteers from the translation community to whom I am grateful for their input. [1] http://vincentsanders.blogspot.co.uk/2013/05/true-art-selects-and-paraphrases-but.html [2] https://www.transifex.com/projects/p/netsurf/ </pre> Vincent Sanders 2013-05-19T08:14:43 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9661 <pre>Hi Netsurf dev, I'd like to extend libcss to parse additional CSS properties such as border-radius. I'd also like to add overflow-x, overflow-y. "overflow" is implemented but not -x, -y variants. I had a quick look at the following file: libcss/src/parse/properties/properties.gen But I couldn't figure quite right what was the syntax of this file even with the whole list of examples. Could you help me figure out? Thanks. </pre> Hoà V. Dinh 2013-05-19T02:09:38 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9660 <pre>Just noticed that Jenkins seems to be stuck due to Chimera being offline again. </pre> Chris Young 2013-05-18T23:03:55 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9658 <pre>Hi. When compiling the libhubbub tests from git master using GCC 4.7.2 I get two warnings, which become errors via -Werror and stop the tests running: error: variable `origlen` set but not used [-Werror=unused-but-set-variable] error: comparison between `parserutils_error` and `enum hubbub_error` [-Werror=enum-compare] The following (git format-) patch makes the errors go away and the test suite pass: https://gist.github.com/craigbarnes/5514898/raw/c2f94d97d26b52b01e5cf45c2ff9a973e2e44a32/0001-Fix-compile-errors-in-tests.patch Aside: I discovered the errors while working on a hubbub package/binding for the Lua language, which can be found at: https://github.com/craigbarnes/lua-hubbub ...if anyone is interested. It's MIT licensed and should be complete in a few days. </pre> Craig Barnes 2013-05-03T23:20:16 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9656 <pre>I'm running NetSurf 3.0 with GTK+ 2.24.17 on OpenBSD. When I go to Edit-&gt;Preferences I'm seeing the translation tokens for labels and such instead of the actual text (en in my case). All other windows and interfaces show the text one would expect. Any hints at what might be causing this? Thanks. Examples: preferencesMainTabtitle preferencesStartupPage preferencesDownloadsLocation </pre> James Turner 2013-05-03T19:20:30 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9654 <pre>Seems to be in a stuck state due to chimera being off-line. </pre> Chris Young 2013-04-28T11:28:23 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9650 <pre>Hi list, Where should I submit new Dutch translations? TIA, Simon Voortman. </pre> Simon Voortman 2013-04-25T17:19:04 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9649 <pre>I've pushed a handful of branches containing some clang warning fixes. libnsfb/rjek/clang-warnings libcss/rjek/clang-warnings nsjsgenbind/rjek/clang-warnings netsurf/rjek/clang-warnings B. </pre> Rob Kendrick 2013-04-25T14:39:42 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9648 <pre>For people who are not on help-A1FYRfCQ4PY&lt; at &gt;public.gmane.org B. </pre> Rob Kendrick 2013-04-24T15:33:17 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9647 <pre>Would it be possible to list the progress on individual Javascript features, in the same way as the CSS features? That way, those of us who are interested can play with features, learn Javascript, and test the features. Or will implementation be an all-or-nothing event - suddenly one day all of Javascript will work? Dave ____________________________________________________________ GET FREE SMILEYS FOR YOUR IM &amp; EMAIL - Learn more at http://www.inbox.com/smileys Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails </pre> Dave Higton 2013-04-24T08:38:44 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9646 <pre>Hi, Several tests use alloca() to allocate memory. But alloca() is not part of C99, and on OpenBSD this leads to linking errors since the NetSurf build system specifies -std=c99: LINK: build-OpenBSD-OpenBSD-release-lib-shared/test_parser cc -o build-OpenBSD-OpenBSD-release-lib-shared/test_parser build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o -Lbuild-OpenBSD-OpenBSD-release-lib-shared/ -lhubbub -g -L/usr/local/lib -liconv -L/usr/local/lib -ljson-c build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o(.text+0x578): In function `run_test': test/parser.c:28: undefined reference to `alloca' collect2: ld returned 1 exit status These are the files that use alloca(): libhubbub: test/parser.c test/tokeniser2.c test/tokeniser3.c test/tree.c libcss: test/css21.c test/parse-auto.c libparserutils: test/cscodec-8859.c test/cscodec-ext8.c test/cscodec-utf8.c test/cscodec-utf16.c </pre> Anthony J. Bentley 2013-04-24T07:25:56 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9645 <pre>Hi, After upgrading to 3.0 on my system, NetSurf-GTK looks like this: http://i.imgur.com/BUr5Tj4.png It turns out this is because LANG is unset in my environment (although LC_CTYPE=en_US.UTF8). If I run "LANG=en netsurf", everything is peachy. Would it be possible to default to "en" if LANG is unset and/or LANG=C? </pre> Anthony J. Bentley 2013-04-24T07:57:49 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9643 <pre> New releases have been made for the libraries: LibCSS 0.2.0 LibDOM 0.0.1 LibHubbub 0.2.0 LibNSBMP 0.1.0 LibNSGIF 0.1.0 LibNSFB 0.1.0 LibParserUtils 0.1.2 LibPencil 0.0.2 LibROSprite 0.1.0 LibRUfl 0.0.2 LibSVGTiny 0.1.0 LibWapcaplet 0.2.0 http://download.netsurf-browser.org/libs/releases/ The new buildsystem used by all the libraries has been released: Buildsystem 1.0 http://download.netsurf-browser.org/libs/releases/ The JavaScript to DOM binding generator has been released: NSGenJSBind 0.0.1 http://download.netsurf-browser.org/libs/releases/ NetSurf 3.0 source release: http://download.netsurf-browser.org/netsurf/releases/source/ NetSurf 3.0 full source release (inc. our libraries): http://download.netsurf-browser.org/netsurf/releases/source-full/ </pre> Michael Drake 2013-04-23T15:07:36 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9639 <pre> Hello, It looks like the current netsurf buildsystem isn't able to compile correct executables for the atari target, this is especially bad when running on coldfire, where the build failure results in illegal instructions (when m68k CPU emulation is turned off). (the sdk build maybe suffers the same problem, but that's another story) On my local box I use Verbose mode of make, to see the actual compiler commands. Let's have a look at the atari support within the netsurf buildsystem: --- snip --- # FreeMiNT / atari ifeq ($(TARGET),atari) ifeq ($(HOST),atari) # Building on FreeMiNT # Nothing to do, as we assume the default tooling works else # Cross compiling for FreeMiNT ATARIARCH ?= 68020-60 GCCSDK_INSTALL_ENV ?= /opt/netsurf/m68k-atari-mint GCCSDK_INSTALL_CROSSBIN ?= /opt/netsurf/m68k-atari-mint/cross/bin CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-gcc CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-g++ AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-ar ifeq ($(ATARIARCH),68000) ARCHFLAGS := ARCHDIR := endif ifeq ($(ATARIARCH),68020-60) ARCHFLAGS := -m$(ATARIARCH) ARCHDIR := /$(ATARIARCH) endif ifeq ($(ATARIARCH),v4e) ARCHFLAGS := -mcpu=5475 ARCHDIR := /m5475 endif CFLAGS := $(CFLAGS) -U__STRICT_ANSI__ -I$(GCCSDK_INSTALL_ENV)/include $(ARCHFLAGS) CXXFLAGS := $(CXXFLAGS) -U__STRICT_ANSI__ -I$(GCCSDK_INSTALL_ENV)/include $(ARCHFLAGS) LDFLAGS := $(LDFLAGS) -L$(GCCSDK_INSTALL_ENV)/lib$(ARCHDIR) PREFIX ?= $(GCCSDK_INSTALL_ENV) endif endif --- snip --- First thing to notice is the fact that it assumes you do pass the environment variable ATARIARCH to specify the CPU type. If you do not specify this variable, the cpu defaults to 68020-60, which is definitly wrong for coldfire compilation. I'm assuming that the netsurf build system does not set ATARIARCH. I'm open for suggestions, how to specify and resolve the CPU type differently, of course. Also look at the output of libcss build: http://ci.netsurf-browser.org/jenkins/job/libcss/TARGET=m5475-atari-mint,label=other/86/consoleText You can not see which compiler was used. You can not see which CFLAGS/LDFLAGS where used. Second thing to notice is the fact that it assumes the m68k-atari-mint toolchain to be used: CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-gcc CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-g++ AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-ar When compiling for coldfire (the way it was meant to be: by setting ATARIARCH) it will fail to find the compiler because the m68k-atari-mint compiler is not located in the coldfire sdk dirs. Of course the script could be adjusted like this: ifeq ($(ATARIARCH),v4e) ARCHFLAGS := -mcpu=5475 ARCHDIR := /m5475 CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-gcc CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-g++ AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-ar endif But that would mean, that the average buildsystem user is not able to compile netsurf on his own box, when he doesn't want to use the m5475-atari-mint-xxx provided by the netsurf sdk build. As an example, just take this simple make command and see how it fails: /media/src/netsurf.git/libnsgif$ GCCSDK_INSTALL_CROSSBIN=/opt/netsurf/m5475-atari-mint/cross/bin GCCSDK_INSTALL_ENV=/opt/netsurf/m5475-atari-mint make TARGET=atari ATARIARCH=v4e /bin/sh: /opt/netsurf/m5475-atari-mint/cross/bin/m68k-atari-mint-gcc: not found /bin/sh: /opt/netsurf/m5475-atari-mint/cross/bin/m68k-atari-mint-gcc: not found /opt/netsurf/m5475-atari-mint/share/netsurf-buildsystem/makefiles/Makefile.tools:466: *** Unable to detect toolchain. Schluss. Using m68k-atari-mint-gcc to compile atari coldfire software is de facto standard and I don't want to explain people that things are different with netsurf ;) However, if this is the only way to implement clean coldfire support in the netsurf buildsystem, I'm happy to take that pill. Can we add the ATARIARCH environment variable, like it is done for the netsurf build? Valid values: ATARIARCH=68020-60 ATARIARCH=v4e The coldfire build will be broken then (look at the example above), because it won't be able to find the toolchain (except it is explicitly set), however, when that happens, I probably already fixed the toolchain names for coldfire within the makefile. </pre> Ole 2013-04-15T22:20:36 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9638 <pre>All I've just created a branch chris/scheduled-fetches because currently when downloading, NetSurf runs in a busy loop fetching data. This really slows down the whole system ounder AmigaOS because NetSurf ends up hogging most of the processor time. In the branch I've changed the main loop so it schedules itself to do an immediate hlcache_poll, rather than directly calling hlcache_poll itself. This means that operating systems with something like Wait(), which will wait for an event to come in, eg. for one of NetSurf's scheduled tasks, will be able to use Wait() rather than dropping out of gui_poll and letting NetSurf busy-loop, and be a bit more multi-tasking friendly. It is certainly working well here, with a minor change to ignore gui_poll's "active" flag. I'm not sure what implications this has for other platforms we target. I don't see that it would cause any problems, as the only real change is that schedule() calls hlcache_poll() rather than the main loop doing it - unless there are some hidden reasons why that is a bad idea? Ideally I'd like to see this in 3.0 if possible, as it has solved something that has been bugging me for ages! Thoughts? Chris </pre> Chris Young 2013-04-15T19:10:02 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9636 <pre>I noticed a display issue on: http://www.lacoop26-07.fr/ (both GTK and Haiku) The main text block (the 2 photos and the text below) seems to disappear when scrolling up, and reappears when scrolling down. It seems scrolling the page totally on the left makes it visible when scrolling up/down, at least on Haiku. François. </pre> François Revol 2013-04-15T13:31:00 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9634 <pre>Is anybody else getting dark green text on the same colour background, on all Kickstart project details? For example, this random one off the front page: http://www.kickstarter.com/projects/andyfei/mini-microsd-reader-for-android-smartphones-and-ta?ref=home_popular Another couple I looked at have the same problem (so I assume they all do). I'm sure it has been working in the past. Chris </pre> Chris Young 2013-04-11T18:21:24 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9630 <pre> We're aiming to have NetSurf 3.0 ready for release on 20 April 2013. Ideally we'll be creating the release tag at least a week before that. Currently the NetSurf 3.0 change log looks like this: http://www.netsurf-browser.org/temp/ChangeLog Please check it over for anything missing, or wrong. Briefly, the big changes in the core are: Using LibDOM instead of LibXML. Fetch, parse of CSS in parallel with HTML. New textareas. And the (disabled by default) limited JS support. Loads of fixes and internal tidying. </pre> Michael Drake 2013-03-26T15:06:42 http://comments.gmane.org/gmane.comp.web.netsurf.devel/9627 <pre>Hi, I just pushed some fixes for BeOS and Haiku: http://source.netsurf-browser.org/netsurf.git/log/?h=mmu_man/beos-fixes (3 commits): * beos: Fix replicants * beos: update copyright years in the version info * beos: Fix nsfont_position_in_string off-by-1 (fixes selecting the 1st letter in a textarea) François. </pre> François Revol 2013-03-21T23:33:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.netsurf.devel