October 2010 - Dillo-dev - lists.mailman3.com

Re: Dillo config in LTIB
by vic＠smartqsys.com 14 Oct '10

14 Oct '10

Hi Johannes, Right, after editing etc/resolv.conf and setting nameserver ip after dillo is launched, it can now resolve WLAN addresses but still remains unreachable. However, local LAN published web pages can now display. So I'm sure wget will work within LAN but not WLAN. It looks like a gateway ip/ routing issue at this point. Is there a gateway ip related variable much like what nameserver is for the dns ip? Btw, does dillo support printing initiated via the web page's html script? Thanks so much, Vic Message: 4 Date: Thu, 14 Oct 2010 09:13:40 +0200 From: Johannes Hofmann Subject: Re: [Dillo-dev] Re: Dillo config in LTIB To: dillo-dev(a)dillo.org Message-ID: <20101014071340.GB934(a)blob.baaderstrasse.com> Content-Type: text/plain; charset=us-ascii On Thu, Oct 14, 2010 at 12:00:47AM +0800, vic wrote: > Hi Jorge, > > Thanks for the prompt reply. I'm using ltib Linux kernel 2.6.34 on an Embedded Artists LPC3250 development board, no firewall. The board is connected to a gateway router. > > Does "ping www.dillo.org" resolve? > It does not, it responds with "unreachable destination". However, a ping to a host in the local LAN is fine and a link to a host in the local LAN has this response... > > > Nav_open_url: new url='http://192.168.1.6:88' > > Dns_server [0]: 192.168.1.6 is 192.168.1.6 > > Connecting to 192.168.1.6 > > ** WARNING **: IO_write, closing with pending data not sent > > ** WARNING **: "GET / HTTP/1.1\x0D > > I read from a thread to place "nameserver=dns ip" in /etc/resolv.conf but nothing changed. I took a look at dns.c but I can't figure out where it's getting the value of "nameserver" from or whether it's really using that module. I think it's resolving fine, so it's probabely not a DNS issue. Can you install e.g. wget and try wget http://192.168.1.6:88 Cheers, Johannes

1 0

Re: Dillo config in LTIB
by vic＠smartqsys.com 14 Oct '10

14 Oct '10

Hi Jorge, Thanks for the prompt reply. I'm using ltib Linux kernel 2.6.34 on an Embedded Artists LPC3250 development board, no firewall. The board is connected to a gateway router. Does "ping www.dillo.org" resolve? It does not, it responds with "unreachable destination". However, a ping to a host in the local LAN is fine and a link to a host in the local LAN has this response... > Nav_open_url: new url='http://192.168.1.6:88' > Dns_server [0]: 192.168.1.6 is 192.168.1.6 > Connecting to 192.168.1.6 > ** WARNING **: IO_write, closing with pending data not sent > ** WARNING **: "GET / HTTP/1.1\x0D I read from a thread to place "nameserver=dns ip" in /etc/resolv.conf but nothing changed. I took a look at dns.c but I can't figure out where it's getting the value of "nameserver" from or whether it's really using that module. Thanks, Vic Message: 1 Date: Tue, 12 Oct 2010 09:20:50 -0300 From: Jorge Arellano Cid Subject: Re: [Dillo-dev] Dillo config in LTIB To: dillo-dev(a)dillo.org Message-ID: <20101012122050.GB2862(a)dillo.org> Content-Type: text/plain; charset=us-ascii Hi, On Mon, Oct 11, 2010 at 08:12:09PM -0700, Vic wrote: > Hi, > > I installed Dillo in LTIB and while the splash page went up, > clicking links reported a dns error. I checked out dillorc and > saw no setting related to dns. Dillo uses getaddrinfo(). It depends on the OS. > Trying a link to localhost also > gave I/O errors. This is strange... > My trace as follows: > > Nav_open_url: new url='http://www.dillo.org/' > DNS error: TRY_AGAIN > Dns_server [0]: www.dillo.org is (nil) Does "ping www.dillo.org" resolve? > Using localhost: > > Nav_open_url: new url='http://localhost:88' > Dns_server [0]: localhost is 127.0.0.1 > Connecting to 127.0.0.1 > ** WARNING **: IO_write, closing with pending data not sent > ** WARNING **: "GET / HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: localhost:88\x0D > Referer: http://localhost:88/\x0D > User-Agent: Dillo/2.1\x0D > \x0D > " > > Thanks for any help. It looks like something external closed the connection. Firewall? -- Cheers Jorge.-

2 1

Dillo config in LTIB
by vic＠smartqsys.com 14 Oct '10

14 Oct '10

Hi Jorge, The EA lpc3250 is connected to a gateway router with IP 192.168.1.4. pinging local LAN hosts is fine but WLAN host are unreachable. I tried editing etc/resolv.conf with nameserver 192.168.1.4 , but this time after dillo is up instead and not before launching dillo. It is able to resolve but this is what I get... [root@nxp /]# ping www.dillo.org -c 4 PING www.dillo.org (134.102.206.165): 56 data bytes ping: sendto: Network is unreachable [root@nxp /]# Nav_open_url: new url='http://www.dillo.org' Dns_server [0]: www.dillo.org is 134.102.206.165 Connecting to 134.102.206.165 Http_connect_socket ERROR: Network is unreachable Thanks, Vic > > Message: 1 > Date: Tue, 12 Oct 2010 09:20:50 -0300 > From: Jorge Arellano Cid <jcid(a)dillo.org> > Subject: Re: [Dillo-dev] Dillo config in LTIB > To: dillo-dev(a)dillo.org > Message-ID: <20101012122050.GB2862(a)dillo.org> > Content-Type: text/plain; charset=us-ascii > > Hi, > > On Mon, Oct 11, 2010 at 08:12:09PM -0700, Vic wrote: >> Hi, >> >> I installed Dillo in LTIB and while the splash page went up, >> clicking links reported a dns error. I checked out dillorc and >> saw no setting related to dns. > > Dillo uses getaddrinfo(). It depends on the OS. > >> Trying a link to localhost also >> gave I/O errors. > > This is strange... > >> My trace as follows: >> >> Nav_open_url: new url='http://www.dillo.org/' >> DNS error: TRY_AGAIN >> Dns_server [0]: www.dillo.org is (nil) > > Does "ping www.dillo.org" resolve? > > >> Using localhost: >> >> Nav_open_url: new url='http://localhost:88' >> Dns_server [0]: localhost is 127.0.0.1 >> Connecting to 127.0.0.1 >> ** WARNING **: IO_write, closing with pending data not sent >> ** WARNING **: "GET / HTTP/1.1\x0D >> Connection: close\x0D >> Accept-Charset: utf-8,*;q=0.8\x0D >> Accept-Encoding: gzip\x0D >> Host: localhost:88\x0D >> Referer: http://localhost:88/\x0D >> User-Agent: Dillo/2.1\x0D >> \x0D >> " >> >> Thanks for any help. > > It looks like something external closed the connection. > Firewall? > > -- > Cheers > Jorge.- > > >

1 0

Dillo config in LTIB
by vic＠smartqsys.com 12 Oct '10

12 Oct '10

Hi, I installed Dillo in LTIB and while the splash page went up, clicking links reported a dns error. I checked out dillorc and saw no setting related to dns. Trying a link to localhost also gave I/O errors. My trace as follows: Nav_open_url: new url='http://www.dillo.org/' DNS error: TRY_AGAIN Dns_server [0]: www.dillo.org is (nil) Using localhost: Nav_open_url: new url='http://localhost:88' Dns_server [0]: localhost is 127.0.0.1 Connecting to 127.0.0.1 ** WARNING **: IO_write, closing with pending data not sent ** WARNING **: "GET / HTTP/1.1\x0D Connection: close\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: localhost:88\x0D Referer: http://localhost:88/\x0D User-Agent: Dillo/2.1\x0D \x0D " Thanks for any help. Vic

2 1

Re: project list for sponsoring test period
by jcid＠dillo.org 11 Oct '10

11 Oct '10

On Mon, Oct 04, 2010 at 02:16:57PM +0200, Johannes Hofmann wrote: > On Mon, Oct 04, 2010 at 07:59:45AM -0400, Jorge Arellano Cid wrote: > > On Sun, Oct 03, 2010 at 09:16:30PM +0200, Johannes Hofmann wrote: > > > [...] > > > BTW, what do you think about adding the css_compat/ directory to the > > > repo (under doc)? That would give us version control and it would > > > document our progress. > > > > Having the test cases visible as HTML from the site is very > > helpful IMHO. Unfortunately I don't yet know of a way of browsing > > raw files from hg web interfaces (it may be doable). > > For my own website I have > > [hooks] > changegroup = hg up > > in the .hgrc. So everytime I push to it, the files are updated. > We could do the same for the CSS tests. Yes, it seems fair enough. FWIW, so long we've had the HTML test suite, and the personal test pages each one of us develops. As you explained, the problem is how to automate HTML rendering tests. I hesitate to include an html test-page collection in the tarball because it would grow bigger and bigger and nobody would apply to test each one everytime a relevant change is made! :) I like the CSS checklist we have because it is sorted by property and provides test-cases we can reference by URL, and it lives outside the tarball so its size can grow independently. A fast way to check the tests is to provide an image with the correct rendering in the test page (maybe with an explanation too). It takes more time to prepare though, and each time you update the page you have to also update the screenshot. Quite a burden. I don't have a good solution yet. These days I've been working with Gecko and Dillo. Having the test page showed in both provides for a "dynamic screenshot" from Gecko. This avoids the burden of updating the image, with the advantage of showing how Gecko renders unespecified parts of the SPEC. An HTML test-page, with written explanations of what to check for, and two browsers is the fastest/simplest solution I see so far. (It also has the advantage of almost anyone being able to do the test). If we have it online (i.e. with http URLs), better, and if we had some version control it may be what we need. > > > > Besides that I don't see the benefits of having css_compat/ > > under version control, and our progress is more or less in the hg > > log, but I see it can be more tightly coupled with the test case > > if the extended comment makes a reference to it for instance. > > Please explain me a bit because it may be I don't see the gains > > because of lack of knowledge on my side! > > Basically I like to do almost everything under version control. Just > yesterday I almost overwrote your vertical-align.html with my own > version! > Also just pushing my changes to dillo.org would be faster than > copying the files manually. > Do you have root on dillo.org? If so, you could install mercurial > and I will set up a repo for the CSS tests. > We can decide later whether we want to integrate it into the main > dillo repo or not. Not me, but you can ask Andreas Kemnade. He's our savvy sysadmin. > > OTOH, yes, I see dillo would be in better shape test-wise if we > > could include an [automated] test framework in the tarball. This > > wasn't done because it takes some time and needs manpower we > > didn't have. > > At "Henning's company" we are also thinking about automated tests > for dillo. > My current idea is to create a new view, that writes text that can > easily be compared with expected results. That would be more flexible > than to compare bitmaps of rendered output, which might give to many > false positves. > If this works out we can think about integrating the framework into > dillo mainline, but currently it's just an idea. I have some automated tests too (e.g. URL resolver), but rendering is a different beast. That's my thoughts. -- Cheers Jorge.-

2 2

small-caps
by jcid＠dillo.org 09 Oct '10

09 Oct '10

Hi, Just committed a patch for CSS' small-caps, http://www.dillo.org/css_compat/tests/font-variant.html I had to use mbrtowc() because for some reason utf8decode() didn't work for me. I tried: diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h> #include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size); @corvid: do you see why? -- Cheers Jorge.-

3 8

A Dillo-Win32 update
by obeythepenguin＠gmail.com 04 Oct '10

04 Oct '10

On Sat, 02 Oct 2010 17:31:07 -0400, Diego . <darkspirit5000(a)gmail.com> wrote: > Your solution only works for downloads. Your downloader can be made a > DPI and you can chose wich to use. Actually downloads do not stop if > dillo close. I'm well aware how DPI is implemented, and that downloads continue when Dillo is exited. My solution is intended in part as a temporary measure, since I need downloads to function regardless of whether DPI is available or not. I do have concerns, however, with both the specific implementation and general (perceived) necessity of DPI. > If the problems are dup2 and sockets dpid can be change to work on > windows. > Dillo always ask the dpi that serves a service before conect to it. > dpid run the DPI so can send dillo the right fd, socket, file or do > other thing. I've been working on that, but with very limited success. dup2 and sockets are the most immediate problem, but there are larger problems beyond that (for example, packaging Dillo/DPI). > dpid avoid to load in every dillo code to handle DPIs or external > programs that will use only one and avoid the synchronize thing. I don't think basic functionality like local file browsing and HTTPS is unnecessary "load in every dillo code". If there's any situation where it's undesired, perhaps the code could be #ifdef'd out and a new autoconf option added (--disable-local-files, etc.) As far as sharing bookmarks, cookies, etc. between browser processes: most major browsers (IE, Firefox, Opera, probably Chrome) allow one browser process running, and if a second is started, it signals the first to take some action (create a new window, for instance). That would still require some amount of IPC, but it's less complicated than DPI, and certainly less wasteful since you don't have multiple instances loading the same UI, static libraries, etc. ~Benjamin

2 2

A Dillo-Win32 update
by obeythepenguin＠gmail.com 04 Oct '10

04 Oct '10

The browser patch is about as stable as I can get it, so I thought I'd send it in for your consideration. First the patch, then my comments: http://dillo-win32.sourceforge.net/files/dillo-r1705-win32-20100913-merge.d… I'd consider this "merge-ready" in terms of completeness, though I haven't much tested stability, and I'd need your opinion on coding style. This is a long patch (~1740 lines), with a lot of separate but closely-interconnected changes. I'd split it into smaller subpatches, but I'm not really sure how practical (or possible) that would be, so my apologies in advance for the length. I've run into a major impasse with DPI. Simply put, DPI is not portable to non-Unix systems. Specifically, there are two main problems as far as Windows is concerned: (1) lack of Unix signals, and (2) non-interchangeability of file and socket descriptors. Since I'm aiming for a native port, an emulation layer such as Cygwin is absolutely not an option. I'm faced with a bit of a dilemma here. The two options I see are to either redesign DPI, or ditch it altogether; and I don't think anyone is too keen on either idea. I've considered a fork, but I'm opposed to the idea on both practical and philosophical grounds (my goal's to help, not to hurt upstream). Any suggestions? Thanks & cheers, ~Benjamin

3 10