From corvid at lavabit.com Sun Aug 2 03:04:26 2009 From: corvid at lavabit.com (corvid) Date: Sun Aug 2 03:07:47 2009 Subject: [Dillo-dev] experimental patch: Re: dillo2 wrapping Chinese In-Reply-To: <144aa14b0908011503h670c8a78nced5c55bd160a51a@mail.gmail.com> References: <20081110185710.GA16730@local.gobigwest.com> <49192930.1000508@tom.com> <20081111215424.GA19355@local.gobigwest.com> <144aa14b0811111455p6422950bgf59806fff8ec6e5e@mail.gmail.com> <20090603142253.GD28743@local.gobigwest.com> <144aa14b0906052037w6b4b6ee4sbe6266b2925eae23@mail.gmail.com> <20090727203138.GM26610@local.gobigwest.com> <144aa14b0907271617i17c1d357uf8f355ec82a97540@mail.gmail.com> <20090727234711.GN26610@local.gobigwest.com> <144aa14b0908011503h670c8a78nced5c55bd160a51a@mail.gmail.com> Message-ID: <20090802010426.GD17894@local.gobigwest.com> I made yet another version of this patch the other day, and furaisanjin was kind enough to run on it a bit and ensure it's doing what we want. With the previous version, compiling without optimization, gprof showed 3-4% loss of speed on a page that's mostly English text. - I removed the strdup/free from the common case. - For nonideographic, it goes character by character instead of checking every byte. This should help for, e.g., Russian, but means some 'unnecessary' length-checking in the mostly-ASCII case. And gprof suggested the slowdown might be 3% now, although at this point, unless someone is paying you to perform a lot of careful, drudgery-filled runs, it gets hard to pick the signal out of the noise when examining the time spent in relevant functions. I tried adding in some code to bypass the ideographic call for ASCII, but 1) it made the code a little messy 2) it looked like it might be saving a few tenths of a percent 3) the compiler might perform optimizations under certain circumstances making my efforts unnecessary or counterproductive. I could definitely be talked into this one, though. I tried adding an addText() with a length argument and thought it might help by saving me the trouble of writing NULL bytes into the strings and saving the trouble of some strlen()ning in dw. I couldn't see any difference in speed, although it did make things cleaner and I would want to add it in eventually if this all makes it into the repository. There will be a duplicated ideographic() test, for instance, if a word starts with digits and ends with some Japanese characters. 1) uncommon 2) complexity This patch is really two patches because it also handles the case where whitespace numeric character references are inside a word, but I wanted to see the effects of both and they are each an excuse for the overhead of the loop. I'd split it into two pieces if committing it. -------------- next part -------------- diff -r 680722126b9e src/html.cc --- a/src/html.cc Sun Jul 26 19:25:42 2009 +0000 +++ b/src/html.cc Mon Jul 27 20:13:12 2009 +0000 @@ -1122,7 +1122,12 @@ static void Html_process_space(DilloHtml * Entities are parsed (or not) according to parse_mode. * 'word' is a '\0'-terminated string. */ +#if 0 +could preserve constness by adding an addText() that takes length... static void Html_process_word(DilloHtml *html, const char *word, int size) +#else +static void Html_process_word(DilloHtml *html, char *word, int size) +#endif { int i, j, start; char *Pword, ch; @@ -1167,12 +1172,16 @@ static void Html_process_word(DilloHtml dFree(Pword); } else { + char *Pword_end; + if (!memchr(word,'&', size)) { /* No entities */ - HT2TB(html)->addText(word, html->styleEngine->wordStyle ()); + Pword = word; + Pword_end = Pword + size - 1; } else { /* Collapse white-space entities inside the word (except  ) */ Pword = a_Html_parse_entities(html, word, size); + Pword_end = Pword + strlen(Pword) - 1; /* Collapse adjacent " \t\f\n\r" characters into a single space */ for (i = j = 0; (Pword[i] = Pword[j]); ++i, ++j) { if (strchr(" \t\f\n\r", Pword[i])) { @@ -1183,9 +1192,36 @@ static void Html_process_word(DilloHtml ; } } - HT2TB(html)->addText(Pword, html->styleEngine->wordStyle ()); + } + for (start = i = 0; Pword[i]; start = i) { + int len; + + if (isspace(Pword[i])) { + while (Pword[++i] && isspace(Pword[i])) ; + Html_process_space(html, Pword + start, i - start); + } else if (a_Utf8_ideographic(Pword+i, Pword_end, &len)) { + i += len; + ch = Pword[i]; + Pword[i] = '\0'; + HT2TB(html)->addText(Pword + start, + html->styleEngine->wordStyle ()); + Pword[i] = ch; + html->PrevWasSPC = false; + } else { + do { + i += len; + } while (Pword[i] && !isspace(Pword[i]) && + (!a_Utf8_ideographic(Pword+i, Pword_end, &len))); + ch = Pword[i]; + Pword[i] = 0; + HT2TB(html)->addText(Pword + start, + html->styleEngine->wordStyle ()); + Pword[i] = ch; + html->PrevWasSPC = false; + } + } + if (word != Pword) dFree(Pword); - } } html->PrevWasSPC = false; diff -r 680722126b9e src/utf8.cc --- a/src/utf8.cc Sun Jul 26 19:25:42 2009 +0000 +++ b/src/utf8.cc Mon Jul 27 20:13:12 2009 +0000 @@ -11,6 +11,7 @@ #include +#include "../dlib/dlib.h" /* TRUE/FALSE */ #include "utf8.hh" // C++ functions with C linkage ---------------------------------------------- @@ -64,3 +65,31 @@ int a_Utf8_test(const char* src, unsigne { return utf8test(src, srclen); } + +/* + * Does s point to a UTF-8-encoded ideographic character? + * + * This is based on http://unicode.org/reports/tr14/#ID plus some guesses + * for what might make the most sense for Dillo. Surprisingly, they include + * Hangul Compatibility Jamo, but they're the experts, so I'll follow along. + */ +bool_t a_Utf8_ideographic(const char *s, const char *end, int *len) +{ + bool_t ret = FALSE; + + if ((uchar_t)*s >= 0xe2) { + /* Unicode char >= U+2000. */ + unsigned unicode = a_Utf8_decode(s, end, len); + + if (unicode >= 0x2e80 && + ((unicode <= 0xa4cf) || + (unicode >= 0xf900 && unicode <= 0xfaff) || + (unicode >= 0xff00 && unicode <= 0xff9f))) { + ret = TRUE; + } + } else { + *len = 1 + (int)a_Utf8_end_of_char(s, 0); + } + return ret; +} + diff -r 680722126b9e src/utf8.hh --- a/src/utf8.hh Sun Jul 26 19:25:42 2009 +0000 +++ b/src/utf8.hh Mon Jul 27 20:13:12 2009 +0000 @@ -19,6 +19,7 @@ uint_t a_Utf8_decode(const char*, const uint_t a_Utf8_decode(const char*, const char* end, int* len); int a_Utf8_encode(unsigned int ucs, char *buf); int a_Utf8_test(const char* src, unsigned int srclen); +bool_t a_Utf8_ideographic(const char *s, const char *end, int *len); #ifdef __cplusplus } From jcid at dillo.org Sun Aug 2 03:42:01 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Aug 2 03:42:45 2009 Subject: [Dillo-dev] experimental patch: Re: dillo2 wrapping Chinese In-Reply-To: <20090802010426.GD17894@local.gobigwest.com> References: <49192930.1000508@tom.com> <20081111215424.GA19355@local.gobigwest.com> <144aa14b0811111455p6422950bgf59806fff8ec6e5e@mail.gmail.com> <20090603142253.GD28743@local.gobigwest.com> <144aa14b0906052037w6b4b6ee4sbe6266b2925eae23@mail.gmail.com> <20090727203138.GM26610@local.gobigwest.com> <144aa14b0907271617i17c1d357uf8f355ec82a97540@mail.gmail.com> <20090727234711.GN26610@local.gobigwest.com> <144aa14b0908011503h670c8a78nced5c55bd160a51a@mail.gmail.com> <20090802010426.GD17894@local.gobigwest.com> Message-ID: <20090802014201.GA25513@dillo.org> On Sun, Aug 02, 2009 at 01:04:26AM +0000, corvid wrote: > I made yet another version of this patch the other day, > and furaisanjin was kind enough to run on it a bit and > ensure it's doing what we want. > > With the previous version, compiling without optimization, > gprof showed 3-4% loss of speed on a page that's mostly > English text. > > - I removed the strdup/free from the common case. > - For nonideographic, it goes character by character instead of > checking every byte. This should help for, e.g., Russian, > but means some 'unnecessary' length-checking in the > mostly-ASCII case. > > And gprof suggested the slowdown might be 3% now, although > at this point, unless someone is paying you to perform a > lot of careful, drudgery-filled runs, it gets hard to pick the > signal out of the noise when examining the time spent in relevant > functions. I wouldn't go with complex code for 1% gain. > I tried adding in some code to bypass the ideographic call for > ASCII, but 1) it made the code a little messy 2) it looked like > it might be saving a few tenths of a percent 3) the compiler > might perform optimizations under certain circumstances making > my efforts unnecessary or counterproductive. > I could definitely be talked into this one, though. Please leave the messy part out. > I tried adding an addText() with a length argument and thought > it might help by saving me the trouble of writing NULL bytes into > the strings and saving the trouble of some strlen()ning in dw. > I couldn't see any difference in speed, although it did make > things cleaner and I would want to add it in eventually if this > all makes it into the repository. Considering it makes things cleaner I'm for it. > There will be a duplicated ideographic() test, for instance, if > a word starts with digits and ends with some Japanese characters. > 1) uncommon 2) complexity Not worth the trouble of. > This patch is really two patches because it also handles the > case where whitespace numeric character references are > inside a word, but I wanted to see the effects of both > and they are each an excuse for the overhead of the loop. > I'd split it into two pieces if committing it. OK. (i.e. please consider the above comments, split and commit). BTW: I'm working on the limit concurrent connections patch prototype. -- Cheers Jorge.- From corvid at lavabit.com Sun Aug 2 19:14:47 2009 From: corvid at lavabit.com (corvid) Date: Sun Aug 2 19:18:06 2009 Subject: [Dillo-dev] Re: dillo bug 916 In-Reply-To: <20090802165352.GA30232@mutt.xyzz.org> References: <20090710144756.GB3433@local.gobigwest.com> <20090714052450.GC9373@mutt.xyzz.org> <20090802155400.GF17894@local.gobigwest.com> <20090802165352.GA30232@mutt.xyzz.org> Message-ID: <20090802171447.GH17894@local.gobigwest.com> Scott wrote: > As far as I can tell, it works correctly with the patch applied. :) Scott had reported: "Dillo sometimes raises its window when clicked, instead of letting the window manager do its job. Usually if I have a window partially hidden, I don't want it raised... Apps should not try to do their own window management." fltk's Window::handle() has: #if USE_X11 case PUSH: // Unused clicks should raise the window. Windows unfortunatly // raises the window on *all* clicks so we don't bother except on X. if (shown()) XMapRaised(xdisplay, i->xid); #endif Aforementioned patch attached. -------------- next part -------------- diff -r d4442192d3ed src/uicmd.cc --- a/src/uicmd.cc Tue Jul 14 06:15:17 2009 +0000 +++ b/src/uicmd.cc Tue Jul 14 06:29:10 2009 +0000 @@ -309,7 +309,15 @@ public: /* Ignore this event */ return 1; } - return TabGroup::handle(e); + int ret = TabGroup::handle(e); + + if (e == PUSH) { + /* Don't let the window's event handler see it. On X, it raises + * the window. + */ + ret = 1; + } + return ret; } void remove (Widget *w) { From jcid at dillo.org Sun Aug 2 19:40:17 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Aug 2 19:41:03 2009 Subject: [Dillo-dev] limit number of concurrent connections Message-ID: <20090802174017.GA5222@dillo.org> Hi, Here's a prototype patch that does the work. It's not yet optimized nor polished nor throughly tested, and it leaks Web structures, but it illustrates very well the idea, and finishing it shouldn't be hard. As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-) -- Cheers Jorge.- -------------- next part -------------- A non-text attachment was scrubbed... Name: limitConn.ok3.diff Type: text/x-diff Size: 7198 bytes Desc: not available Url : /pipermail/attachments/20090802/f695913f/limitConn.ok3.bin From jcid at dillo.org Sun Aug 2 19:42:45 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Aug 2 19:43:29 2009 Subject: [Dillo-dev] Re: dillo bug 916 In-Reply-To: <20090802171447.GH17894@local.gobigwest.com> References: <20090710144756.GB3433@local.gobigwest.com> <20090714052450.GC9373@mutt.xyzz.org> <20090802155400.GF17894@local.gobigwest.com> <20090802165352.GA30232@mutt.xyzz.org> <20090802171447.GH17894@local.gobigwest.com> Message-ID: <20090802174245.GB5222@dillo.org> On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > Scott wrote: > > As far as I can tell, it works correctly with the patch applied. :) > > Scott had reported: > "Dillo sometimes raises its window when clicked, instead > of letting the window manager do its job. > Usually if I have a window partially hidden, I don't want it raised... > Apps should not try to do their own window management." Sorry, I don't get the idea of the bug. IIUC the problem is that a partially hidden Dillo window raises upon clicking it. I hesitate because Firefox and even terminals here behave that way. Please explain. -- Cheers Jorge.- From corvid at lavabit.com Sun Aug 2 21:27:54 2009 From: corvid at lavabit.com (corvid) Date: Sun Aug 2 21:31:12 2009 Subject: [Dillo-dev] Re: dillo bug 916 In-Reply-To: <20090802174245.GB5222@dillo.org> References: <20090710144756.GB3433@local.gobigwest.com> <20090714052450.GC9373@mutt.xyzz.org> <20090802155400.GF17894@local.gobigwest.com> <20090802165352.GA30232@mutt.xyzz.org> <20090802171447.GH17894@local.gobigwest.com> <20090802174245.GB5222@dillo.org> Message-ID: <20090802192754.GI17894@local.gobigwest.com> Jorge wrote: > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > Scott wrote: > > > As far as I can tell, it works correctly with the patch applied. :) > > > > Scott had reported: > > "Dillo sometimes raises its window when clicked, instead > > of letting the window manager do its job. > > Usually if I have a window partially hidden, I don't want it raised... > > Apps should not try to do their own window management." > > Sorry, I don't get the idea of the bug. IIUC the problem is > that a partially hidden Dillo window raises upon clicking it. > I hesitate because Firefox and even terminals here behave that > way. Please explain. Other windows don't for me. Dillo does if it's a new window/new tab or if I'm clicking below the bottom of the text when the page is very short. I imagine your WM must be set to do it... From jcid at dillo.org Mon Aug 3 18:17:35 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Aug 3 18:18:20 2009 Subject: [Dillo-dev] Re: dillo bug 916 In-Reply-To: <20090802192754.GI17894@local.gobigwest.com> References: <20090710144756.GB3433@local.gobigwest.com> <20090714052450.GC9373@mutt.xyzz.org> <20090802155400.GF17894@local.gobigwest.com> <20090802165352.GA30232@mutt.xyzz.org> <20090802171447.GH17894@local.gobigwest.com> <20090802174245.GB5222@dillo.org> <20090802192754.GI17894@local.gobigwest.com> Message-ID: <20090803161735.GC5222@dillo.org> On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > Scott wrote: > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > Scott had reported: > > > "Dillo sometimes raises its window when clicked, instead > > > of letting the window manager do its job. > > > Usually if I have a window partially hidden, I don't want it raised... > > > Apps should not try to do their own window management." > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > that a partially hidden Dillo window raises upon clicking it. > > I hesitate because Firefox and even terminals here behave that > > way. Please explain. > > Other windows don't for me. Dillo does if it's > a new window/new tab or if I'm clicking below the bottom > of the text when the page is very short. > I imagine your WM must be set to do it... Oh, now I see it (with TWM). Please commit. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Mon Aug 3 18:20:50 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Mon Aug 3 18:22:56 2009 Subject: [Dillo-dev] Re: dillo bug 916 In-Reply-To: <20090803161735.GC5222@dillo.org> References: <20090710144756.GB3433@local.gobigwest.com> <20090714052450.GC9373@mutt.xyzz.org> <20090802155400.GF17894@local.gobigwest.com> <20090802165352.GA30232@mutt.xyzz.org> <20090802171447.GH17894@local.gobigwest.com> <20090802174245.GB5222@dillo.org> <20090802192754.GI17894@local.gobigwest.com> <20090803161735.GC5222@dillo.org> Message-ID: <20090803162049.GA1138@blob.baaderstrasse.com> On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > Scott wrote: > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > Scott had reported: > > > > "Dillo sometimes raises its window when clicked, instead > > > > of letting the window manager do its job. > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > Apps should not try to do their own window management." > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > that a partially hidden Dillo window raises upon clicking it. > > > I hesitate because Firefox and even terminals here behave that > > > way. Please explain. > > > > Other windows don't for me. Dillo does if it's > > a new window/new tab or if I'm clicking below the bottom > > of the text when the page is very short. > > I imagine your WM must be set to do it... > > Oh, now I see it (with TWM). > Please commit. Yes, but we should mark it as a workaround for an FLTK issue and report it to FLTK. From jcid at dillo.org Mon Aug 3 18:31:36 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Aug 3 18:32:21 2009 Subject: [Dillo-dev] Re: dillo bug 916 In-Reply-To: <20090803162049.GA1138@blob.baaderstrasse.com> References: <20090710144756.GB3433@local.gobigwest.com> <20090714052450.GC9373@mutt.xyzz.org> <20090802155400.GF17894@local.gobigwest.com> <20090802165352.GA30232@mutt.xyzz.org> <20090802171447.GH17894@local.gobigwest.com> <20090802174245.GB5222@dillo.org> <20090802192754.GI17894@local.gobigwest.com> <20090803161735.GC5222@dillo.org> <20090803162049.GA1138@blob.baaderstrasse.com> Message-ID: <20090803163136.GD5222@dillo.org> On Mon, Aug 03, 2009 at 06:20:50PM +0200, Johannes Hofmann wrote: > On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > > Scott wrote: > > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > > > Scott had reported: > > > > > "Dillo sometimes raises its window when clicked, instead > > > > > of letting the window manager do its job. > > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > > Apps should not try to do their own window management." > > > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > > that a partially hidden Dillo window raises upon clicking it. > > > > I hesitate because Firefox and even terminals here behave that > > > > way. Please explain. > > > > > > Other windows don't for me. Dillo does if it's > > > a new window/new tab or if I'm clicking below the bottom > > > of the text when the page is very short. > > > I imagine your WM must be set to do it... > > > > Oh, now I see it (with TWM). > > Please commit. > > Yes, but we should mark it as a workaround for an FLTK issue and > report it to FLTK. Exactly! (even though I have more hope for their 1.3 branch). -- Cheers Jorge.- From corvid at lavabit.com Mon Aug 3 20:57:01 2009 From: corvid at lavabit.com (corvid) Date: Mon Aug 3 21:00:26 2009 Subject: [Dillo-dev] Re: dillo bug 916 In-Reply-To: <20090803163136.GD5222@dillo.org> References: <20090710144756.GB3433@local.gobigwest.com> <20090714052450.GC9373@mutt.xyzz.org> <20090802155400.GF17894@local.gobigwest.com> <20090802165352.GA30232@mutt.xyzz.org> <20090802171447.GH17894@local.gobigwest.com> <20090802174245.GB5222@dillo.org> <20090802192754.GI17894@local.gobigwest.com> <20090803161735.GC5222@dillo.org> <20090803162049.GA1138@blob.baaderstrasse.com> <20090803163136.GD5222@dillo.org> Message-ID: <20090803185701.GL17894@local.gobigwest.com> Jorge wrote: > On Mon, Aug 03, 2009 at 06:20:50PM +0200, Johannes Hofmann wrote: > > On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > > > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > > > Scott wrote: > > > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > > > > > Scott had reported: > > > > > > "Dillo sometimes raises its window when clicked, instead > > > > > > of letting the window manager do its job. > > > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > > > Apps should not try to do their own window management." > > > > > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > > > that a partially hidden Dillo window raises upon clicking it. > > > > > I hesitate because Firefox and even terminals here behave that > > > > > way. Please explain. > > > > > > > > Other windows don't for me. Dillo does if it's > > > > a new window/new tab or if I'm clicking below the bottom > > > > of the text when the page is very short. > > > > I imagine your WM must be set to do it... > > > > > > Oh, now I see it (with TWM). > > > Please commit. > > > > Yes, but we should mark it as a workaround for an FLTK issue and > > report it to FLTK. > > Exactly! > > (even though I have more hope for their 1.3 branch). Judging from the comment I mentioned: > fltk's Window::handle() has: > #if USE_X11 > case PUSH: > // Unused clicks should raise the window. Windows unfortunatly > // raises the window on *all* clicks so we don't bother except on X. > if (shown()) XMapRaised(xdisplay, i->xid); > #endif they seem to view it as correct, although it seems strangely arbitrary to me. From jcid at dillo.org Wed Aug 5 03:11:14 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Aug 5 03:12:01 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090802174017.GA5222@dillo.org> References: <20090802174017.GA5222@dillo.org> Message-ID: <20090805011114.GB2444@dillo.org> On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > As said in CCCwork.txt it would be good to build the > whole chain in one single step (for simplicity) and to > define a standard way to end/abort the CCC (which I've > given some thought). If muses decide to pay me a visit, > I may develop a patch for this soon. :-) Good news. I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :) Bottom line: don't waste much time with the CCC and its docs in current repo, most probably they will be replaced soon. -- Cheers Jorge.- From corvid at lavabit.com Wed Aug 5 05:07:54 2009 From: corvid at lavabit.com (corvid) Date: Wed Aug 5 05:11:23 2009 Subject: [Dillo-dev] Re: patch: media_type pref In-Reply-To: <20090318142555.GC4019@local.gobigwest.com> References: <20090216053736.GC2979@local.gobigwest.com> <20090318133642.GE10134@dillo.org> <20090318142555.GC4019@local.gobigwest.com> Message-ID: <20090805030754.GO17894@local.gobigwest.com> I wrote, some months ago: > Jorge wrote: > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > It makes more sense to have a pref that the user can > > > control than for us to guess what they might like > > > based on screen size or whatever, I think. > > > > I hesitate on this. For instance: if media_type is defined to > > "handheld" and there's no such remote CSS, at least it should > > fallback to "screen". > > If there is a handheld style sheet available and dillo is running > on a handheld, it would be a shame not to use it. I'm hoping that > the page author would have the sense to supply something for type "all". > > > Maybe it's more practical to provide custom stylesheets (as the > > current "style.css". e.g. small_screen.css, print.css) and to > > allow switching among them from the "Tools" menu. > > > > What do you think? > > I think someone using handheld would want to use both the page > author's handheld-specific code and a user style suitable for > their device. > > I'll send this to the list in case anyone with experience using > such devices with the web has opinions to share. I never was able to talk Jorge into this one, but I might as well make the code available so that people with handhelds can have it if they wish. -------------- next part -------------- diff -r 0760652cf05e dillorc --- a/dillorc Tue Aug 04 03:51:05 2009 +0000 +++ b/dillorc Wed Aug 05 03:01:37 2009 +0000 @@ -25,6 +25,11 @@ # Change this if you want to disable parsing of embedded CSS initially. # (While browsing, this can be changed from the tools/settings menu.) #parse_embedded_css=YES + +# Change the CSS media type. +# Different style sheets are applied for different types of media. +# The most useful are screen, handheld, and print. +#media_type=screen # Change the buffering scheme for drawing # 0 no double buffering - useful for debugging diff -r 0760652cf05e src/html.cc --- a/src/html.cc Tue Aug 04 03:51:05 2009 +0000 +++ b/src/html.cc Wed Aug 05 03:01:37 2009 +0000 @@ -1671,11 +1671,10 @@ static void Html_tag_open_style(DilloHtm html->loadCssFromStash = false; } if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "media")) && - dStrcasecmp(attrbuf, "all") && !dStristr(attrbuf, "screen")) { + dStrcasecmp(attrbuf, "all") && !dStristr(attrbuf, prefs.media_type)) { /* HTML 4.01 sec. 6.13 says that media descriptors are case-sensitive, * but sec. 14.2.3 says that the attribute is case-insensitive. * TODO can be a comma-separated list. - * TODO handheld. */ html->loadCssFromStash = false; } @@ -2959,9 +2958,6 @@ void a_Html_load_stylesheet(DilloHtml *h * Parse the LINK element (Only CSS stylesheets by now). * (If it either hits or misses, is not relevant here; that's up to the * cache functions) - * - * TODO: How will we know when to use "handheld"? Ask the html->bw->ui for - * screen dimensions, or a dillorc preference. */ static void Html_tag_open_link(DilloHtml *html, const char *tag, int tagsize) { @@ -2991,7 +2987,7 @@ static void Html_tag_open_link(DilloHtml if (((attrbuf = a_Html_get_attr(html, tag, tagsize, "type")) && dStrcasecmp(attrbuf, "text/css")) || ((attrbuf = a_Html_get_attr(html, tag, tagsize, "media")) && - !dStristr(attrbuf, "screen") && dStrcasecmp(attrbuf, "all"))) + !dStristr(attrbuf, prefs.media_type) && dStrcasecmp(attrbuf, "all"))) return; if (!(attrbuf = a_Html_get_attr(html, tag, tagsize, "href")) || diff -r 0760652cf05e src/prefs.c --- a/src/prefs.c Tue Aug 04 03:51:05 2009 +0000 +++ b/src/prefs.c Wed Aug 05 03:01:37 2009 +0000 @@ -51,6 +51,7 @@ void a_Prefs_init(void) prefs.limit_text_width = FALSE; prefs.load_images=TRUE; prefs.load_stylesheets=TRUE; + prefs.media_type = dStrdup("screen"); prefs.middle_click_drags_page = TRUE; prefs.middle_click_opens_new_tab = TRUE; prefs.no_proxy = NULL; @@ -95,6 +96,7 @@ void a_Prefs_freeall(void) a_Url_free(prefs.http_proxy); dFree(prefs.http_proxyuser); dFree(prefs.http_referer); + dFree(prefs.media_type); dFree(prefs.no_proxy); dFree(prefs.save_dir); dFree(prefs.search_url); diff -r 0760652cf05e src/prefs.h --- a/src/prefs.h Tue Aug 04 03:51:05 2009 +0000 +++ b/src/prefs.h Wed Aug 05 03:01:37 2009 +0000 @@ -79,6 +79,7 @@ struct _DilloPrefs { bool_t load_stylesheets; bool_t parse_embedded_css; int32_t buffered_drawing; + char *media_type; char *font_serif; char *font_sans_serif; char *font_cursive; diff -r 0760652cf05e src/prefsparser.cc --- a/src/prefsparser.cc Tue Aug 04 03:51:05 2009 +0000 +++ b/src/prefsparser.cc Wed Aug 05 03:01:37 2009 +0000 @@ -69,6 +69,7 @@ int PrefsParser::parseOption(char *name, { "limit_text_width", &prefs.limit_text_width, PREFS_BOOL }, { "load_images", &prefs.load_images, PREFS_BOOL }, { "load_stylesheets", &prefs.load_stylesheets, PREFS_BOOL }, + { "media_type", &prefs.media_type, PREFS_STRING }, { "middle_click_drags_page", &prefs.middle_click_drags_page, PREFS_BOOL }, { "middle_click_opens_new_tab", &prefs.middle_click_opens_new_tab, From jcid at dillo.org Wed Aug 5 07:00:22 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Aug 5 07:01:08 2009 Subject: [Dillo-dev] Re: patch: media_type pref In-Reply-To: <20090805030754.GO17894@local.gobigwest.com> References: <20090216053736.GC2979@local.gobigwest.com> <20090318133642.GE10134@dillo.org> <20090318142555.GC4019@local.gobigwest.com> <20090805030754.GO17894@local.gobigwest.com> Message-ID: <20090805050022.GC2444@dillo.org> On Wed, Aug 05, 2009 at 03:07:54AM +0000, corvid wrote: > I wrote, some months ago: > > Jorge wrote: > > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > > It makes more sense to have a pref that the user can > > > > control than for us to guess what they might like > > > > based on screen size or whatever, I think. > > > > > > I hesitate on this. For instance: if media_type is defined to > > > "handheld" and there's no such remote CSS, at least it should > > > fallback to "screen". > > > > If there is a handheld style sheet available and dillo is running > > on a handheld, it would be a shame not to use it. I'm hoping that > > the page author would have the sense to supply something for type "all". > > > > > Maybe it's more practical to provide custom stylesheets (as the > > > current "style.css". e.g. small_screen.css, print.css) and to > > > allow switching among them from the "Tools" menu. > > > > > > What do you think? > > > > I think someone using handheld would want to use both the page > > author's handheld-specific code and a user style suitable for > > their device. > > > > I'll send this to the list in case anyone with experience using > > such devices with the web has opinions to share. > > I never was able to talk Jorge into this one, but I > might as well make the code available so that people > with handhelds can have it if they wish. I don't have a handheld and seldom use one. Despite my efforts, my attempts to try to give good advice on it in the past have proved clumsy and of no much use, so I prefer to follow the advice from the ones using them all the time (e.g. Andreas Kemnade). -- Cheers Jorge.- From corvid at lavabit.com Thu Aug 6 07:20:04 2009 From: corvid at lavabit.com (corvid) Date: Thu Aug 6 07:23:27 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090805011114.GB2444@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> Message-ID: <20090806052004.GQ17894@local.gobigwest.com> Jorge wrote: > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > As said in CCCwork.txt it would be good to build the > > whole chain in one single step (for simplicity) and to > > define a standard way to end/abort the CCC (which I've > > given some thought). If muses decide to pay me a visit, > > I may develop a patch for this soon. :-) > > Good news. > > I already have dillo running on CCCs that build in one step > (both for HTTP and DPI), and also updated the documentation. It's > quite stable and behaves very well. Now I have to think what to > do with the gained simplicity. :) Something isn't working right in the new code for Abort. If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault. (interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.) From jcid at dillo.org Thu Aug 6 18:19:50 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Aug 6 18:20:36 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090806052004.GQ17894@local.gobigwest.com> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> Message-ID: <20090806161950.GD22510@dillo.org> On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) Good! This will hopefully help me clean some old ad-hoc bindings. A simple way to avoid the segfault is to comment the line at http.c:497 (i.e. leave it as it was). Now, my idea is to standardize OpAbort, and have a uniform way to call it and thus avoid ad-hoc calls/non-calls that nobody understands. This may take some time or just a bit (we'll see..). The plan is to include the empty-cache-entry removal feature and improve OpStop once things are uniform. Stay tuned... -- Cheers Jorge.- From jcid at dillo.org Fri Aug 7 00:10:32 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Aug 7 00:11:20 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090806052004.GQ17894@local.gobigwest.com> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> Message-ID: <20090806221032.GA5452@dillo.org> On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) > [...] > Now after dns resolution times out, retrying in a new window/tab > doesn't seem to work. Please try the current tip. It's not definitive, but it looks like with some API polish it may be. -- Cheers Jorge.- From corvid at lavabit.com Fri Aug 7 22:16:02 2009 From: corvid at lavabit.com (corvid) Date: Fri Aug 7 22:19:22 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090806221032.GA5452@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> Message-ID: <20090807201602.GW17894@local.gobigwest.com> Jorge wrote: > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > whole chain in one single step (for simplicity) and to > > > > define a standard way to end/abort the CCC (which I've > > > > given some thought). If muses decide to pay me a visit, > > > > I may develop a patch for this soon. :-) > > > > > > Good news. > > > > > > I already have dillo running on CCCs that build in one step > > > (both for HTTP and DPI), and also updated the documentation. It's > > > quite stable and behaves very well. Now I have to think what to > > > do with the gained simplicity. :) > > > > Something isn't working right in the new code for Abort. > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > fails to resolve, I get a segfault. > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > ** WARNING **: CCC: call on already finished chain.) > > > [...] > > Now after dns resolution times out, retrying in a new window/tab > > doesn't seem to work. > > Please try the current tip. It's not definitive, but it looks > like with some API polish it may be. Oh, there still is a bug after all. If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault. From jcid at dillo.org Sat Aug 8 00:34:52 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Aug 8 00:35:44 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090807201602.GW17894@local.gobigwest.com> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> Message-ID: <20090807223452.GB24560@dillo.org> On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > whole chain in one single step (for simplicity) and to > > > > > define a standard way to end/abort the CCC (which I've > > > > > given some thought). If muses decide to pay me a visit, > > > > > I may develop a patch for this soon. :-) > > > > > > > > Good news. > > > > > > > > I already have dillo running on CCCs that build in one step > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > quite stable and behaves very well. Now I have to think what to > > > > do with the gained simplicity. :) > > > > > > Something isn't working right in the new code for Abort. > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > fails to resolve, I get a segfault. > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > ** WARNING **: CCC: call on already finished chain.) > > > > > [...] > > > Now after dns resolution times out, retrying in a new window/tab > > > doesn't seem to work. > > > > Please try the current tip. It's not definitive, but it looks > > like with some API polish it may be. > > Oh, there still is a bug after all. Yes, it's the same bug BTW. I added a new function call to the CCC API (wrapping the trick of the previous patch) and used it in three parts of the code. Please check the tip. > If I'm not connected and I try to go to a host that > I have listed in /etc/hosts, then ^Q gives me a segfault. Another SEGFAULT path was: load dillo home disconnect Internet click 9years press stop All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks. -- Cheers Jorge.- From corvid at lavabit.com Mon Aug 10 14:42:05 2009 From: corvid at lavabit.com (corvid) Date: Mon Aug 10 14:45:25 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090807223452.GB24560@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> Message-ID: <20090810124205.GE4402@local.gobigwest.com> Jorge wrote: > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > > whole chain in one single step (for simplicity) and to > > > > > > define a standard way to end/abort the CCC (which I've > > > > > > given some thought). If muses decide to pay me a visit, > > > > > > I may develop a patch for this soon. :-) > > > > > > > > > > Good news. > > > > > > > > > > I already have dillo running on CCCs that build in one step > > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > > quite stable and behaves very well. Now I have to think what to > > > > > do with the gained simplicity. :) > > > > > > > > Something isn't working right in the new code for Abort. > > > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > > fails to resolve, I get a segfault. > > > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > > ** WARNING **: CCC: call on already finished chain.) > > > > > > > [...] > > > > Now after dns resolution times out, retrying in a new window/tab > > > > doesn't seem to work. > > > > > > Please try the current tip. It's not definitive, but it looks > > > like with some API polish it may be. > > > > Oh, there still is a bug after all. > > Yes, it's the same bug BTW. > > I added a new function call to the CCC API (wrapping the trick > of the previous patch) and used it in three parts of the code. > Please check the tip. > > > If I'm not connected and I try to go to a host that > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > Another SEGFAULT path was: > load dillo home > disconnect Internet > click 9years > press stop > > All of these should be working now. Please report any further > problem you find. I'll try to make the empty cache entries removal > now, and then look for a way to hook the concurrent connection limit > without memory leaks. I don't know whether it's a problem, but I just noticed a difference in behaviour in that my form testcase that submits to localhost (there's no server listening) only prints "submitting multipart/form-data!" and I have to press stop to get '** WARNING **: IO_write, closing with pending data not sent' and see the query. From heisermi at hs-albsig.de Wed Aug 12 16:51:13 2009 From: heisermi at hs-albsig.de (Heiser Michael) Date: Wed Aug 12 16:52:09 2009 Subject: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin Message-ID: Hi guys, Currently I'm searching for a small footprint webbrowser to use on my blackin device. This device is driven by uClinux. The first positive I can tell you is, that I compiled fltk2 for blackfin with success. I followed the instructions on tw.myblog.yahoo.com/stevegigijoe/article to compile and run fltk2. My modifications can be read at https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=35676&action=ForumBrowse&forum_id=39 So now I'm facing a problem with the configure script of dillo. I had to make few changes to configure.in to recognize crosscompiled Fltk2 lib. These changes went ok but when configure checks libz, then it crashes because it can't find right version of the library. So my question is, how can I tell configure to search in my uClinux directory where the library already is persistent for use with uClinux. Best Regards from Germany, Michae -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20090812/fb54832a/attachment.htm From corvid at lavabit.com Thu Aug 13 01:45:27 2009 From: corvid at lavabit.com (corvid) Date: Thu Aug 13 01:49:11 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090807223452.GB24560@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> Message-ID: <20090812234527.GI4402@local.gobigwest.com> Jorge wrote: > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > > whole chain in one single step (for simplicity) and to > > > > > > define a standard way to end/abort the CCC (which I've > > > > > > given some thought). If muses decide to pay me a visit, > > > > > > I may develop a patch for this soon. :-) > > > > > > > > > > Good news. > > > > > > > > > > I already have dillo running on CCCs that build in one step > > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > > quite stable and behaves very well. Now I have to think what to > > > > > do with the gained simplicity. :) > > > > > > > > Something isn't working right in the new code for Abort. > > > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > > fails to resolve, I get a segfault. > > > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > > ** WARNING **: CCC: call on already finished chain.) > > > > > > > [...] > > > > Now after dns resolution times out, retrying in a new window/tab > > > > doesn't seem to work. > > > > > > Please try the current tip. It's not definitive, but it looks > > > like with some API polish it may be. > > > > Oh, there still is a bug after all. > > Yes, it's the same bug BTW. > > I added a new function call to the CCC API (wrapping the trick > of the previous patch) and used it in three parts of the code. > Please check the tip. > > > If I'm not connected and I try to go to a host that > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > Another SEGFAULT path was: > load dillo home > disconnect Internet > click 9years > press stop > > All of these should be working now. Please report any further > problem you find. I'll try to make the empty cache entries removal > now, and then look for a way to hook the concurrent connection limit > without memory leaks. I just got a segfault on NULL Info when going to the https url for the uclinux page: #0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x83e5ab0, Data2=0x0) at capi.c:522 #2 0x08063028 in Capi_conn_resume () at capi.c:172 #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, Data1=0x0, Data2=0x8122730) at capi.c:577 #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, Data2=0x8122730) at chain.c:113 #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, Data1=0x8b8d260, Data2=0x0) at dpi.c:625 #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, Data2=0x0) at chain.c:136 #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, cmd=0x8ee2400 " > now, and then look for a way to hook the concurrent connection limit > > without memory leaks. > > I don't know whether it's a problem, but I just noticed > a difference in behaviour in that my form testcase that > submits to localhost (there's no server listening) > only prints "submitting multipart/form-data!" and > I have to press stop to get > '** WARNING **: IO_write, closing with pending data not sent' > and see the query. Yes, I'm yet to look into it. BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!). The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this? -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Thu Aug 13 21:43:22 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Aug 13 21:45:34 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090813015449.GD5788@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090810124205.GE4402@local.gobigwest.com> <20090813015449.GD5788@dillo.org> Message-ID: <20090813194322.GA965@blob.baaderstrasse.com> On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote: > > Jorge wrote: > > > [...] > > > All of these should be working now. Please report any further > > > problem you find. I'll try to make the empty cache entries removal > > > now, and then look for a way to hook the concurrent connection limit > > > without memory leaks. > > > > I don't know whether it's a problem, but I just noticed > > a difference in behaviour in that my form testcase that > > submits to localhost (there's no server listening) > > only prints "submitting multipart/form-data!" and > > I have to press stop to get > > '** WARNING **: IO_write, closing with pending data not sent' > > and see the query. > > Yes, I'm yet to look into it. > > BTW, just committed a patch for an elusive bug. Now it's > possible to browse (& populate DNS cache), disconnect, click a > link, have the abort operation on no network condition, reconnect > and click it again (and it will work!). > > The only bit missing is how to make the link return to its > normal color. a_Nav_repush() can do it easily but looks like an > overkill. Maybe Johannes has a good idea on this? Not sure why it should change it's color. It's still a visited link after all. Or does the link color have another semantics (like page is in cache) in dillo? Anyway, the real solution would need the DOM-tree which is currently not available. The DOM-tree would also be needed for :hover, :active, and for Javascript. However we could add a hack similar to the one to compute html->visited_color in Html_tag_open_body(). It assumes that there is just one visited_color in the whole page. Cheers, Johannes From heisermi at hs-albsig.de Fri Aug 14 09:00:39 2009 From: heisermi at hs-albsig.de (Heiser Michael) Date: Fri Aug 14 09:01:17 2009 Subject: AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: <20090813000958.GJ4402@local.gobigwest.com> References: <20090813000958.GJ4402@local.gobigwest.com> Message-ID: Hey guys, I think I'm near on getting dillo2 working on blackfin uClinux. My concurrent problem is, that there are some Errors linking the project. Undefined reference ..... I'll give you my compile log: make[3]: F?r das Ziel ?all? ist nichts zu tun. make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src/IO' make[3]: Entering directory `/home/mheiser/dillo-2.1.1/src' bfin-linux-uclibc-g++ -I.. -I/home/mheiser/uClinux/uClinux/uclinux-dist/staging/usr/include/libpng12 -I/home/mheiser/fltk-2.0.x-r6841 -I/home/mheiser/uClinux/uclinux-dist/staging/usr/include/freetype2 -I/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45/X11/include -Wno-non-virtual-dtor -O2 -pipe -isystem /home/mheiser/uClinux/uclinux-dist/staging/usr/include -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -lpng12 -L/home/mheiser/fltk-2.0.x-r6841/lib -Wl,-rpath,/home/mheiser/bfin-fltk2/lib -lfltk2_images -lpng -lfltk2_images -ljpeg -lz -lfltk2 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/src/lib -L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -lX11 -lpthread -lm -lnano-X -lsupc++ -lz -liconv /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_Xutf8LookupString' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XFreeDeviceList' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_wcstombs' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_mbstowcs' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XOpenDevice' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XGetExtensionVersion' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XListInputDevices' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XSelectExtensionEvent' collect2: ld gab 1 als Ende-Status zur?ck make[3]: *** [dillo] Fehler 1 make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/home/mheiser/dillo-2.1.1/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/mheiser/dillo-2.1.1' make: *** [all] Fehler 2 Can you give me an advice? I don't know exactly where I should begin searching for advice.... Regards Michael -----Urspr?ngliche Nachricht----- Von: corvid [mailto:corvid@lavabit.com] Gesendet: Donnerstag, 13. August 2009 02:10 An: Heiser Michael Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin If you get it working from that document mentioned on the uclinux forum, let us know so that I can add to Compatibility.html :) Von AVG ?berpr?ft - www.avg.de Version: 8.5.386 / Virendatenbank: 270.13.53/2299 - Ausgabedatum: 08/12/09 18:12:00 From newman.x at gmail.com Fri Aug 14 12:35:33 2009 From: newman.x at gmail.com (Michal Nowak) Date: Fri Aug 14 12:36:26 2009 Subject: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: References: <20090813000958.GJ4402@local.gobigwest.com> Message-ID: <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> On Fri, Aug 14, 2009 at 9:00 AM, Heiser Michael wrote: > Hey guys, > ?I think I'm near on getting dillo2 working on blackfin uClinux. My concurrent problem is, that there are some Errors linking the project. Undefined reference ..... > I'll give you my compile log: > > make[3]: F?r das Ziel ?all? ist nichts zu tun. > make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src/IO' > make[3]: Entering directory `/home/mheiser/dillo-2.1.1/src' > bfin-linux-uclibc-g++ -I.. -I/home/mheiser/uClinux/uClinux/uclinux-dist/staging/usr/include/libpng12 -I/home/mheiser/fltk-2.0.x-r6841 -I/home/mheiser/uClinux/uclinux-dist/staging/usr/include/freetype2 -I/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45/X11/include -Wno-non-virtual-dtor -O2 -pipe -isystem /home/mheiser/uClinux/uclinux-dist/staging/usr/include -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions ?-L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -o dillo ?dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -lpng12 -L/home/mheiser/fltk-2.0.x-r6841/lib -Wl,-rpath,/home/mheiser/bfin-fltk2/lib -lfltk2_images -lpng -lfltk2_images -ljpeg -lz -lfltk2 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/src/lib -L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -lX11 -lpthread -lm -lnano-X -lsupc++ -lz -liconv > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_Xutf8LookupString' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XFreeDeviceList' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_wcstombs' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_mbstowcs' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XOpenDevice' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XGetExtensionVersion' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XListInputDevices' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XSelectExtensionEvent' Aren't you missing libXi-devel? Regards, Michal > collect2: ld gab 1 als Ende-Status zur?ck > make[3]: *** [dillo] Fehler 1 > make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src' > make[2]: *** [all-recursive] Fehler 1 > make[2]: Leaving directory `/home/mheiser/dillo-2.1.1/src' > make[1]: *** [all-recursive] Fehler 1 > make[1]: Leaving directory `/home/mheiser/dillo-2.1.1' > make: *** [all] Fehler 2 > > Can you give me an advice? I don't know exactly where I should begin searching for advice.... > > Regards > > Michael > > -----Urspr?ngliche Nachricht----- > Von: corvid [mailto:corvid@lavabit.com] > Gesendet: Donnerstag, 13. August 2009 02:10 > An: Heiser Michael > Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin > > If you get it working from that document mentioned on > the uclinux forum, let us know so that I can add to > Compatibility.html :) > > > > Von AVG ?berpr?ft - www.avg.de > Version: 8.5.386 / Virendatenbank: 270.13.53/2299 - Ausgabedatum: 08/12/09 18:12:00 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > From heisermi at hs-albsig.de Fri Aug 14 13:18:20 2009 From: heisermi at hs-albsig.de (Heiser Michael) Date: Fri Aug 14 13:18:58 2009 Subject: AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> Message-ID: LibXi is part of nxlib and nxlib maps XInputs to nano-X lib. So I had to replace libXi. By the way I handled the compiling for Blackfin!! I will give you soon an advice how to make it :) It's now only on testing dillo on our device..... That seems to be tricky -----Urspr?ngliche Nachricht----- Von: dillo-dev-bounces@dillo.org [mailto:dillo-dev-bounces@dillo.org] Im Auftrag von Michal Nowak Gesendet: Freitag, 14. August 2009 12:36 An: dillo-dev@dillo.org Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin On Fri, Aug 14, 2009 at 9:00 AM, Heiser Michael wrote: > Hey guys, > ?I think I'm near on getting dillo2 working on blackfin uClinux. My concurrent problem is, that there are some Errors linking the project. Undefined reference ..... > I'll give you my compile log: > > make[3]: F?r das Ziel ?all? ist nichts zu tun. > make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src/IO' > make[3]: Entering directory `/home/mheiser/dillo-2.1.1/src' > bfin-linux-uclibc-g++ -I.. -I/home/mheiser/uClinux/uClinux/uclinux-dist/staging/usr/include/libpng12 -I/home/mheiser/fltk-2.0.x-r6841 -I/home/mheiser/uClinux/uclinux-dist/staging/usr/include/freetype2 -I/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45/X11/include -Wno-non-virtual-dtor -O2 -pipe -isystem /home/mheiser/uClinux/uclinux-dist/staging/usr/include -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions ?-L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -o dillo ?dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -lpng12 -L/home/mheiser/fltk-2.0.x-r6841/lib -Wl,-rpath,/home/mheiser/bfin-fltk2/lib -lfltk2_images -lpng -lfltk2_images -ljpeg -lz -lfltk2 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/src/lib -L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -lX11 -lpthread -lm -lnano-X -lsupc++ -lz -liconv > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_Xutf8LookupString' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XFreeDeviceList' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_wcstombs' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_mbstowcs' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XOpenDevice' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XGetExtensionVersion' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XListInputDevices' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XSelectExtensionEvent' Aren't you missing libXi-devel? Regards, Michal > collect2: ld gab 1 als Ende-Status zur?ck > make[3]: *** [dillo] Fehler 1 > make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src' > make[2]: *** [all-recursive] Fehler 1 > make[2]: Leaving directory `/home/mheiser/dillo-2.1.1/src' > make[1]: *** [all-recursive] Fehler 1 > make[1]: Leaving directory `/home/mheiser/dillo-2.1.1' > make: *** [all] Fehler 2 > > Can you give me an advice? I don't know exactly where I should begin searching for advice.... > > Regards > > Michael > > -----Urspr?ngliche Nachricht----- > Von: corvid [mailto:corvid@lavabit.com] > Gesendet: Donnerstag, 13. August 2009 02:10 > An: Heiser Michael > Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin > > If you get it working from that document mentioned on > the uclinux forum, let us know so that I can add to > Compatibility.html :) > > > > Von AVG ?berpr?ft - www.avg.de > Version: 8.5.386 / Virendatenbank: 270.13.53/2299 - Ausgabedatum: 08/12/09 18:12:00 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > _______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev Eingehende eMail ist virenfrei. Von AVG ?berpr?ft - www.avg.de Version: 8.5.392 / Virendatenbank: 270.13.55/2301 - Ausgabedatum: 08/13/09 18:16:00 From heisermi at hs-albsig.de Fri Aug 14 15:38:35 2009 From: heisermi at hs-albsig.de (Heiser Michael) Date: Fri Aug 14 15:39:15 2009 Subject: AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> Message-ID: Hey guys, I got it! Dillo2 is running on our Blackfin device and I'll send you a little manual as attachment for implementing it to uClinux! Regards Michael!!! -----Urspr?ngliche Nachricht----- Von: dillo-dev-bounces@dillo.org [mailto:dillo-dev-bounces@dillo.org] Im Auftrag von Heiser Michael Gesendet: Freitag, 14. August 2009 13:18 An: dillo-devel-list (dillo-dev@dillo.org) Betreff: AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin LibXi is part of nxlib and nxlib maps XInputs to nano-X lib. So I had to replace libXi. By the way I handled the compiling for Blackfin!! I will give you soon an advice how to make it :) It's now only on testing dillo on our device..... That seems to be tricky -----Urspr?ngliche Nachricht----- Von: dillo-dev-bounces@dillo.org [mailto:dillo-dev-bounces@dillo.org] Im Auftrag von Michal Nowak Gesendet: Freitag, 14. August 2009 12:36 An: dillo-dev@dillo.org Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin On Fri, Aug 14, 2009 at 9:00 AM, Heiser Michael wrote: > Hey guys, > ?I think I'm near on getting dillo2 working on blackfin uClinux. My concurrent problem is, that there are some Errors linking the project. Undefined reference ..... > I'll give you my compile log: > > make[3]: F?r das Ziel ?all? ist nichts zu tun. > make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src/IO' > make[3]: Entering directory `/home/mheiser/dillo-2.1.1/src' > bfin-linux-uclibc-g++ -I.. > bfin-linux-uclibc-g++ -I/home/mheiser/uClinux/uClinux/uclinux-dist/sta > bfin-linux-uclibc-g++ ging/usr/include/libpng12 > bfin-linux-uclibc-g++ -I/home/mheiser/fltk-2.0.x-r6841 > bfin-linux-uclibc-g++ -I/home/mheiser/uClinux/uclinux-dist/staging/usr > bfin-linux-uclibc-g++ /include/freetype2 > bfin-linux-uclibc-g++ -I/home/mheiser/uClinux/uclinux-dist/user/microw > bfin-linux-uclibc-g++ in/nxlib/nxlib-0.45/X11/include > bfin-linux-uclibc-g++ -Wno-non-virtual-dtor -O2 -pipe -isystem > bfin-linux-uclibc-g++ /home/mheiser/uClinux/uclinux-dist/staging/usr/i > bfin-linux-uclibc-g++ nclude -Wall -W -Wno-unused-parameter -fno-rtti > bfin-linux-uclibc-g++ -fno-exceptions ? > bfin-linux-uclibc-g++ -L/home/mheiser/uClinux/uclinux-dist/staging/usr > bfin-linux-uclibc-g++ /lib -o dillo ?dillo.o paths.o ui.o uicmd.o bw.o > bfin-linux-uclibc-g++ cookies.o auth.o colors.o misc.o history.o > bfin-linux-uclibc-g++ prefs.o prefsparser.o keys.o url.o bitvec.o > bfin-linux-uclibc-g++ klist.o chain.o utf8.o timeout.o dialog.o web.o > bfin-linux-uclibc-g++ nav.o cache.o decode.o dicache.o capi.o css.o > bfin-linux-uclibc-g++ cssparser.o styleengine.o plain.o html.o form.o > bfin-linux-uclibc-g++ table.o bookmark.o dns.o gif.o jpeg.o png.o > bfin-linux-uclibc-g++ imgbuf.o image.o menu.o dpiapi.o findbar.o > bfin-linux-uclibc-g++ xembed.o ../dlib/libDlib.a ../dpip/libDpip.a > bfin-linux-uclibc-g++ IO/libDiof.a ../dw/libDw-widgets.a > bfin-linux-uclibc-g++ ../dw/libDw-fltk.a ../dw/libDw-core.a > bfin-linux-uclibc-g++ ../lout/liblout.a -ljpeg -lpng12 > bfin-linux-uclibc-g++ -L/home/mheiser/fltk-2.0.x-r6841/lib > bfin-linux-uclibc-g++ -Wl,-rpath,/home/mheiser/bfin-fltk2/lib > bfin-linux-uclibc-g++ -lfltk2_images -lpng -lfltk2_images -ljpeg -lz > bfin-linux-uclibc-g++ -lfltk2 > bfin-linux-uclibc-g++ -L/home/mheiser/uClinux/uclinux-dist/user/microw > bfin-linux-uclibc-g++ in/nxlib/nxlib-0.45 > bfin-linux-uclibc-g++ -L/home/mheiser/uClinux/uclinux-dist/user/microw > bfin-linux-uclibc-g++ in/src/lib > bfin-linux-uclibc-g++ -L/home/mheiser/uClinux/uclinux-dist/staging/usr > bfin-linux-uclibc-g++ /lib -lX11 -lpthread -lm -lnano-X -lsupc++ -lz > bfin-linux-uclibc-g++ -liconv > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_Xutf8LookupString' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XFreeDeviceList' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_wcstombs' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_mbstowcs' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XOpenDevice' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XGetExtensionVersion' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XListInputDevices' > /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XSelectExtensionEvent' Aren't you missing libXi-devel? Regards, Michal > collect2: ld gab 1 als Ende-Status zur?ck > make[3]: *** [dillo] Fehler 1 > make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src' > make[2]: *** [all-recursive] Fehler 1 > make[2]: Leaving directory `/home/mheiser/dillo-2.1.1/src' > make[1]: *** [all-recursive] Fehler 1 > make[1]: Leaving directory `/home/mheiser/dillo-2.1.1' > make: *** [all] Fehler 2 > > Can you give me an advice? I don't know exactly where I should begin searching for advice.... > > Regards > > Michael > > -----Urspr?ngliche Nachricht----- > Von: corvid [mailto:corvid@lavabit.com] > Gesendet: Donnerstag, 13. August 2009 02:10 > An: Heiser Michael > Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin > > If you get it working from that document mentioned on the uclinux > forum, let us know so that I can add to Compatibility.html :) > > > > Von AVG ?berpr?ft - www.avg.de > Version: 8.5.386 / Virendatenbank: 270.13.53/2299 - Ausgabedatum: > 08/12/09 18:12:00 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > _______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev Eingehende eMail ist virenfrei. Von AVG ?berpr?ft - www.avg.de Version: 8.5.392 / Virendatenbank: 270.13.55/2301 - Ausgabedatum: 08/13/09 18:16:00 Eingehende eMail ist virenfrei. Von AVG ?berpr?ft - www.avg.de Version: 8.5.392 / Virendatenbank: 270.13.55/2301 - Ausgabedatum: 08/13/09 18:16:00 -------------- next part -------------- Manual for implementing dillo2 with fltk2 library in uClinux ============================================================ you need the sources for dillo2.1.1 (http://www.dillo.org) and the latest version of fltk2 (http://www.fltk.org) and a working uClinux development platform (http://blackfin.uclinux.org), cause you need libraries of the distro First step: =========== Compiling uClinux with following libs activated by xconfig: libiconv, libpng12, libz, libjpeg6b, nxlib und nano-X/microwindows Before you compile uClinux you have to change stub.c in /path/to/microwin/nxlib/nxlib-0.45. Add following code to it: int Xutf8LookupString(){ printf("XutfLookupString called\n"); return 0; } int XFreeDeviceList(){ printf("XFreeDeviceList called\n"); return 0; } int XOpenDevice(){ printf("XOpenDevice called\n"); return 0; } int XGetExtensionVersion(){ printf("XGetExtensionVersion called\n"); return 0; } int XListInputDevices(){ printf("XListInputDevices called\n"); return 0; } int XSelectExtensionEvent(){ printf("XSelectExtensionEvent called\n"); return 0; } This Add prevents flkt2 from crashing at linking the lib! Second step: ============ Compiling fltk2 cd path/to/fltk2 type following into youre terminal CFLAGS='-O2 -pipe -isystem /path/to/staging/usr/include' CXXFLAGS='-O2 -pipe -isystem /path/to/staging/usr/include -I/path/to/microwin/nxlib/nxlib-0.45/X11/include' LDFLAGS='-L/path/to/staging/usr/lib -L/path/to/microwin/nxlib/nxlib-0.45/X11/include -L/path/to/microwin/src/lib' CXX=bfin-linux-uclibc-g++ CC=bfin-linux-uclibc-gcc AR=bfin-linux-uclibc-ar ./configure --host=bfin-linux-uclibc --target=bfin-linux-uclibc --prefix=/path/to/installDIR --enable-shared --with-x --disable-gl --disable-cygwin --x-includes=/path/to/microwin/nxlib/nxlib-0.45/X11/include --x-libraries=/path/to/microwin/nxlib/nxlib-0.45/X11/include --cache-file=/dev/null When configure has ended you have to check all necessary options and Compilerflags in makeinclude. Espacially you have to change following options -lXi and -lxext to -lX11 and -lnano-X then you have to change src/utf.c. Change all wchar_t * to char * and comment if-else statements including the functions wcstombs() and mbstowcs(). make; make install Third step: =========== Compiling Dillo2 cd path/to/dillo first you have to patch configure.in of dillo --- configure.in.orig 2009-07-01 19:55:34.000000000 +0200 +++ configure.in 2009-08-12 12:10:44.000000000 +0200 @@ -145,12 +145,18 @@ dnl ---------------------- dnl dnl For debugging and to be user friendly + +dnl Check if the user hasn't set the variable $FLTK2_CONFIG + if test -z "$FLTK2_CONFIG"; then + PNG_CONFIG=`which fltk2-config` + fi + AC_MSG_CHECKING([FLTK2]) if sh -c "fltk2-config --version" >/dev/null 2>&1 then AC_MSG_RESULT(yes) - LIBFLTK_CXXFLAGS=`fltk2-config --cxxflags` - LIBFLTK_CFLAGS=`fltk2-config --cflags` - LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` + LIBFLTK_CXXFLAGS=`$FLTK2_CONFIG --cxxflags` + LIBFLTK_CFLAGS=`$FLTK2_CONFIG --cflags` + LIBFLTK_LIBS=`$FLTK2_CONFIG --use-images --ldflags` else AC_MSG_RESULT(no) AC_ERROR(FLTK2 must be installed!) fi type following into your terminal FLTK2_CONFIG=path/to/fltk2-config CFLAGS='-O2 -pipe -isystem /path/to/staging/usr/include' CXXFLAGS='-O2 -pipe -isystem /path/to/staging/usr/include -I/path/to/microwin/nxlib/nxlib-0.45/X11/include' LDFLAGS='-L/path/to/staging/usr/lib -L/path/to/microwin/nxlib/nxlib-0.45/X11/include -L/path/to/microwin/src/lib' CC=bfin-linux-uclibc-gcc CXX=bfin-linux-uclibc-g++ AR=bfin-linux-uclibc-ar ./configure --host=bfin-linux-uclibc --target=bfin-linux-uclibc --cache-file=/dev/null when configure has ended you have to check ALL makefiles for -p compiler-flags and get rid of it! Else it would crash at linking the app! Then you have to check one more time ALL makefiles for correct include and lib paths! If necessary change the values by hand. make Fourth step: ============ Running the browser the binary of dillo can be found in dillo2.1.1/src/ The necessary libraries have to be persistent and correctly linked on your target system: libX11.so.6, libfltk2.so, libfltk2_images.so, libibconv.so.2 and libpng12.so nano-X has to be installed copy dillorc to /usr/local/etc/dillo/dillorc on your target dillorc is the file where you make all settings for dillo Have Fun!!! From heisermi at hs-albsig.de Fri Aug 14 16:05:23 2009 From: heisermi at hs-albsig.de (Heiser Michael) Date: Fri Aug 14 16:05:30 2009 Subject: AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: <37367b3a0908140701x49a8c40fg77a841605980a946@mail.gmail.com> References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> <37367b3a0908140701x49a8c40fg77a841605980a946@mail.gmail.com> Message-ID: By the way, what I forgot to mention!! You have to change all fork() to vfork() cause there is no MMU on blackfin systems!!! Thanks Alan, it was a pleasure to me :) Regards Michael -----Urspr?ngliche Nachricht----- Von: Alan Carvalho de Assis [mailto:acassis@gmail.com] Gesendet: Freitag, 14. August 2009 16:02 An: Heiser Michael Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin Great work Michael, Thank you for sharing it. I hope someone implement these missing functions. NXLib is a nice project, I am sad to see this project stalled. Regards, Alan On 8/14/09, Heiser Michael wrote: > Hey guys, > > I got it! Dillo2 is running on our Blackfin device and I'll send you a > little manual as attachment for implementing it to uClinux! > > Regards Michael!!! > > -----Urspr?ngliche Nachricht----- > Von: dillo-dev-bounces@dillo.org [mailto:dillo-dev-bounces@dillo.org] Im > Auftrag von Heiser Michael > Gesendet: Freitag, 14. August 2009 13:18 > An: dillo-devel-list (dillo-dev@dillo.org) > Betreff: AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin > > LibXi is part of nxlib and nxlib maps XInputs to nano-X lib. So I had to > replace libXi. By the way I handled the compiling for Blackfin!! I will give > you soon an advice how to make it :) It's now only on testing dillo on our > device..... > > That seems to be tricky > > -----Urspr?ngliche Nachricht----- > Von: dillo-dev-bounces@dillo.org [mailto:dillo-dev-bounces@dillo.org] Im > Auftrag von Michal Nowak > Gesendet: Freitag, 14. August 2009 12:36 > An: dillo-dev@dillo.org > Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin > > On Fri, Aug 14, 2009 at 9:00 AM, Heiser Michael > wrote: >> Hey guys, >> I think I'm near on getting dillo2 working on blackfin uClinux. My >> concurrent problem is, that there are some Errors linking the project. >> Undefined reference ..... >> I'll give you my compile log: >> >> make[3]: F?r das Ziel ?all? ist nichts zu tun. >> make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src/IO' >> make[3]: Entering directory `/home/mheiser/dillo-2.1.1/src' >> bfin-linux-uclibc-g++ -I.. >> bfin-linux-uclibc-g++ -I/home/mheiser/uClinux/uClinux/uclinux-dist/sta >> bfin-linux-uclibc-g++ ging/usr/include/libpng12 >> bfin-linux-uclibc-g++ -I/home/mheiser/fltk-2.0.x-r6841 >> bfin-linux-uclibc-g++ -I/home/mheiser/uClinux/uclinux-dist/staging/usr >> bfin-linux-uclibc-g++ /include/freetype2 >> bfin-linux-uclibc-g++ -I/home/mheiser/uClinux/uclinux-dist/user/microw >> bfin-linux-uclibc-g++ in/nxlib/nxlib-0.45/X11/include >> bfin-linux-uclibc-g++ -Wno-non-virtual-dtor -O2 -pipe -isystem >> bfin-linux-uclibc-g++ /home/mheiser/uClinux/uclinux-dist/staging/usr/i >> bfin-linux-uclibc-g++ nclude -Wall -W -Wno-unused-parameter -fno-rtti >> bfin-linux-uclibc-g++ -fno-exceptions >> bfin-linux-uclibc-g++ -L/home/mheiser/uClinux/uclinux-dist/staging/usr >> bfin-linux-uclibc-g++ /lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o >> bfin-linux-uclibc-g++ cookies.o auth.o colors.o misc.o history.o >> bfin-linux-uclibc-g++ prefs.o prefsparser.o keys.o url.o bitvec.o >> bfin-linux-uclibc-g++ klist.o chain.o utf8.o timeout.o dialog.o web.o >> bfin-linux-uclibc-g++ nav.o cache.o decode.o dicache.o capi.o css.o >> bfin-linux-uclibc-g++ cssparser.o styleengine.o plain.o html.o form.o >> bfin-linux-uclibc-g++ table.o bookmark.o dns.o gif.o jpeg.o png.o >> bfin-linux-uclibc-g++ imgbuf.o image.o menu.o dpiapi.o findbar.o >> bfin-linux-uclibc-g++ xembed.o ../dlib/libDlib.a ../dpip/libDpip.a >> bfin-linux-uclibc-g++ IO/libDiof.a ../dw/libDw-widgets.a >> bfin-linux-uclibc-g++ ../dw/libDw-fltk.a ../dw/libDw-core.a >> bfin-linux-uclibc-g++ ../lout/liblout.a -ljpeg -lpng12 >> bfin-linux-uclibc-g++ -L/home/mheiser/fltk-2.0.x-r6841/lib >> bfin-linux-uclibc-g++ -Wl,-rpath,/home/mheiser/bfin-fltk2/lib >> bfin-linux-uclibc-g++ -lfltk2_images -lpng -lfltk2_images -ljpeg -lz >> bfin-linux-uclibc-g++ -lfltk2 >> bfin-linux-uclibc-g++ -L/home/mheiser/uClinux/uclinux-dist/user/microw >> bfin-linux-uclibc-g++ in/nxlib/nxlib-0.45 >> bfin-linux-uclibc-g++ -L/home/mheiser/uClinux/uclinux-dist/user/microw >> bfin-linux-uclibc-g++ in/src/lib >> bfin-linux-uclibc-g++ -L/home/mheiser/uClinux/uclinux-dist/staging/usr >> bfin-linux-uclibc-g++ /lib -lX11 -lpthread -lm -lnano-X -lsupc++ -lz >> bfin-linux-uclibc-g++ -liconv >> /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to >> `_Xutf8LookupString' >> /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to >> `_XFreeDeviceList' >> /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to >> `_wcstombs' >> /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to >> `_mbstowcs' >> /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to >> `_XOpenDevice' >> /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to >> `_XGetExtensionVersion' >> /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to >> `_XListInputDevices' >> /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to >> `_XSelectExtensionEvent' > > Aren't you missing libXi-devel? > > Regards, > Michal > >> collect2: ld gab 1 als Ende-Status zur?ck >> make[3]: *** [dillo] Fehler 1 >> make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src' >> make[2]: *** [all-recursive] Fehler 1 >> make[2]: Leaving directory `/home/mheiser/dillo-2.1.1/src' >> make[1]: *** [all-recursive] Fehler 1 >> make[1]: Leaving directory `/home/mheiser/dillo-2.1.1' >> make: *** [all] Fehler 2 >> >> Can you give me an advice? I don't know exactly where I should begin >> searching for advice.... >> >> Regards >> >> Michael >> >> -----Urspr?ngliche Nachricht----- >> Von: corvid [mailto:corvid@lavabit.com] >> Gesendet: Donnerstag, 13. August 2009 02:10 >> An: Heiser Michael >> Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin >> >> If you get it working from that document mentioned on the uclinux >> forum, let us know so that I can add to Compatibility.html :) >> >> >> >> Von AVG ?berpr?ft - www.avg.de >> Version: 8.5.386 / Virendatenbank: 270.13.53/2299 - Ausgabedatum: >> 08/12/09 18:12:00 >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev@dillo.org >> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > Eingehende eMail ist virenfrei. > Von AVG ?berpr?ft - www.avg.de > Version: 8.5.392 / Virendatenbank: 270.13.55/2301 - Ausgabedatum: 08/13/09 > 18:16:00 > > Eingehende eMail ist virenfrei. > Von AVG ?berpr?ft - www.avg.de > Version: 8.5.392 / Virendatenbank: 270.13.55/2301 - Ausgabedatum: 08/13/09 > 18:16:00 > Eingehende eMail ist virenfrei. Von AVG ?berpr?ft - www.avg.de Version: 8.5.392 / Virendatenbank: 270.13.55/2301 - Ausgabedatum: 08/13/09 18:16:00 From corvid at lavabit.com Fri Aug 14 17:05:25 2009 From: corvid at lavabit.com (corvid) Date: Fri Aug 14 17:09:13 2009 Subject: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> Message-ID: <20090814150525.GK4402@local.gobigwest.com> Michael wrote: > LibXi is part of nxlib and nxlib maps XInputs to nano-X lib. So I had to replace libXi. I know there's a USE_XIM in fltk's config.h. It's possible that changing that might accomplish something. > then you have to change src/utf.c. Change all wchar_t * to char * and comment if-else statements including the functions wcstombs() and mbstowcs(). Do multibyte characters work at all? > @@ -145,12 +145,18 @@ > dnl ---------------------- > dnl > dnl For debugging and to be user friendly > + > +dnl Check if the user hasn't set the variable $FLTK2_CONFIG > + if test -z "$FLTK2_CONFIG"; then > + PNG_CONFIG=`which fltk2-config` > + fi > + ? Also, do the DPIs work? (e.g., ftp, https...) From Johannes.Hofmann at gmx.de Fri Aug 14 21:11:39 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Fri Aug 14 21:13:53 2009 Subject: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> Message-ID: <20090814191139.GA1145@blob.baaderstrasse.com> On Fri, Aug 14, 2009 at 03:38:35PM +0200, Heiser Michael wrote: > Hey guys, > > I got it! Dillo2 is running on our Blackfin device and I'll send you a little manual as attachment for implementing it to uClinux! Nice! What exactly is that Blackfin device? Cheers, Johannes From heisermi at hs-albsig.de Fri Aug 14 21:31:25 2009 From: heisermi at hs-albsig.de (Heiser Michael) Date: Fri Aug 14 21:32:23 2009 Subject: AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: <20090814150525.GK4402@local.gobigwest.com> References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> , <20090814150525.GK4402@local.gobigwest.com> Message-ID: I will make the change for USE_XIM on monday. what do you understand under multibyte chars. My problem is that the toolchain for blackfin doesn't support type wchar_t. And as it seems there is also no support for wcstombs and mbstowcs in stdlib.h. I don' know how to do a workaround. Perhaps you can show me how to do..... ________________________________________ Von: dillo-dev-bounces@dillo.org [dillo-dev-bounces@dillo.org] im Auftrag von corvid [corvid@lavabit.com] Gesendet: Freitag, 14. August 2009 17:05 An: dillo-devel-list (dillo-dev@dillo.org) Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin Michael wrote: > LibXi is part of nxlib and nxlib maps XInputs to nano-X lib. So I had to replace libXi. I know there's a USE_XIM in fltk's config.h. It's possible that changing that might accomplish something. > then you have to change src/utf.c. Change all wchar_t * to char * and comment if-else statements including the functions wcstombs() and mbstowcs(). Do multibyte characters work at all? > @@ -145,12 +145,18 @@ > dnl ---------------------- > dnl > dnl For debugging and to be user friendly > + > +dnl Check if the user hasn't set the variable $FLTK2_CONFIG > + if test -z "$FLTK2_CONFIG"; then > + PNG_CONFIG=`which fltk2-config` > + fi > + ? Also, do the DPIs work? (e.g., ftp, https...) _______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev From heisermi at hs-albsig.de Fri Aug 14 21:32:04 2009 From: heisermi at hs-albsig.de (Heiser Michael) Date: Fri Aug 14 21:35:30 2009 Subject: AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: <20090814191139.GA1145@blob.baaderstrasse.com> References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> , <20090814191139.GA1145@blob.baaderstrasse.com> Message-ID: The device is a BF537 with 8MB flash and 64 MB SDRAM with an additonal epson 13513 framebuffer device. The hardware is developed by the company I'm working at moment as working student. ________________________________________ Von: dillo-dev-bounces@dillo.org [dillo-dev-bounces@dillo.org] im Auftrag von Johannes Hofmann [Johannes.Hofmann@gmx.de] Gesendet: Freitag, 14. August 2009 21:11 An: dillo-dev@dillo.org Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin On Fri, Aug 14, 2009 at 03:38:35PM +0200, Heiser Michael wrote: > Hey guys, > > I got it! Dillo2 is running on our Blackfin device and I'll send you a little manual as attachment for implementing it to uClinux! Nice! What exactly is that Blackfin device? Cheers, Johannes _______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev From corvid at lavabit.com Sat Aug 15 01:12:31 2009 From: corvid at lavabit.com (corvid) Date: Sat Aug 15 01:15:54 2009 Subject: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> <20090814150525.GK4402@local.gobigwest.com> Message-ID: <20090814231231.GL4402@local.gobigwest.com> Michael wrote: > I will make the change for USE_XIM on monday. what do you understand under multibyte chars. My problem is that the toolchain for blackfin doesn't support type wchar_t. And as it seems there is also no support for wcstombs and mbstowcs in stdlib.h. I don' know how to do a workaround. Perhaps you can show me how to do..... I've never had to deal with that bit of FLTK, so I don't know offhand to what degree things still work if this stuff is changed. From jcid at dillo.org Sat Aug 15 06:18:13 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Aug 15 06:19:17 2009 Subject: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin In-Reply-To: <20090814191139.GA1145@blob.baaderstrasse.com> References: <20090813000958.GJ4402@local.gobigwest.com> <5e9a80350908140335j71306a68s44a4728202d992fd@mail.gmail.com> <20090814191139.GA1145@blob.baaderstrasse.com> Message-ID: <20090815041813.GD4201@dillo.org> On Fri, Aug 14, 2009 at 09:11:39PM +0200, Johannes Hofmann wrote: > On Fri, Aug 14, 2009 at 03:38:35PM +0200, Heiser Michael wrote: > > Hey guys, > > > > I got it! Dillo2 is running on our Blackfin device and I'll > > send you a little manual as attachment for implementing it to > > uClinux! It's very good to know it's running on uClinux. It'd be good to have a link to the recipy from the compatibility page once details are polished. -- Cheers Jorge.- From cnicholas at planet9.com Tue Aug 18 20:02:01 2009 From: cnicholas at planet9.com (Chris Nicholas) Date: Tue Aug 18 19:51:53 2009 Subject: [Dillo-dev] newbie question about main loop... Message-ID: <1250618521.30733.34.camel@localhost.localdomain> Just learning about dillo; looks neat! We are investigating how best to "embed" html links within a 3D world, in much the same way old-time 'anchor nodes' were embedded in VRML. We were just thinking to have a separate tab, or if we got fancy, play with OpenGL transforms, etc. Unfortunately, one of the libraries we use for avatars (www.edgelib.com) *must* have the main loop, with everything else called during onRedraw(), etc. Is it even conceivable to use dillo in this manner? best regards - Chris Nicholas From jcid at dillo.org Tue Aug 18 20:46:51 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Aug 18 20:47:59 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090812234527.GI4402@local.gobigwest.com> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> Message-ID: <20090818184651.GA5295@dillo.org> On Wed, Aug 12, 2009 at 11:45:27PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > > Jorge wrote: > > > > I added a new function call to the CCC API (wrapping the trick > > of the previous patch) and used it in three parts of the code. > > Please check the tip. > > > > > If I'm not connected and I try to go to a host that > > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > > > Another SEGFAULT path was: > > load dillo home > > disconnect Internet > > click 9years > > press stop > > > > All of these should be working now. Please report any further > > problem you find. I'll try to make the empty cache entries removal > > now, and then look for a way to hook the concurrent connection limit > > without memory leaks. > > I just got a segfault on NULL Info when going > to the https url for the uclinux page: > > #0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, > Branch=1, Dir=2, Info=0x0) at chain.c:191 > #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, > Data1=0x83e5ab0, Data2=0x0) at capi.c:522 > #2 0x08063028 in Capi_conn_resume () at capi.c:172 > #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, > Data1=0x0, Data2=0x8122730) at capi.c:577 > #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, > Data2=0x8122730) at chain.c:113 > #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, > Data1=0x8b8d260, Data2=0x0) at dpi.c:625 > #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, > Data2=0x0) at chain.c:136 > #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, > Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 > #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, > cmd=0x8ee2400 " References: <20090720144705.GD26631@dillo.org> <20090720234136.GA20645@britannica.bec.de> Message-ID: <20090818185102.GB5295@dillo.org> On Tue, Jul 21, 2009 at 01:41:36AM +0200, Joerg Sonnenberger wrote: > On Mon, Jul 20, 2009 at 10:47:05AM -0400, Jorge Arellano Cid wrote: > > I'm quite happy to let you know that yesterday 19 Aug, > > my first daughter Lisa was born! > > Congratulation! In which category of parent hacker will you now fall? > "I have no time for anything else now" or "I have lots of spare time in > the middle of the night while nursing the baby"? It depends on Lisa! Sometimes I have spare time between feeds, and others there's no time. The best time span happens after nursing her very early in the morning. -- Cheers Jorge.- From corvid at lavabit.com Tue Aug 18 20:55:33 2009 From: corvid at lavabit.com (corvid) Date: Tue Aug 18 20:59:00 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090818184651.GA5295@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> Message-ID: <20090818185533.GA14990@local.gobigwest.com> Jorge wrote: > BTW: I don't remember whether a fix for the uClinux URL above was > already committed. It didn't SEGFAULT when testing tip. I had gone there a few times, and it had only crashed that one time. From jcid at dillo.org Wed Aug 19 02:42:28 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Aug 19 02:43:36 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090813194322.GA965@blob.baaderstrasse.com> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090810124205.GE4402@local.gobigwest.com> <20090813015449.GD5788@dillo.org> <20090813194322.GA965@blob.baaderstrasse.com> Message-ID: <20090819004228.GD5295@dillo.org> On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote: > On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > > On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote: > > > Jorge wrote: > > > > [...] > > > > All of these should be working now. Please report any further > > > > problem you find. I'll try to make the empty cache entries removal > > > > now, and then look for a way to hook the concurrent connection limit > > > > without memory leaks. > > > > > > I don't know whether it's a problem, but I just noticed > > > a difference in behaviour in that my form testcase that > > > submits to localhost (there's no server listening) > > > only prints "submitting multipart/form-data!" and > > > I have to press stop to get > > > '** WARNING **: IO_write, closing with pending data not sent' > > > and see the query. > > > > Yes, I'm yet to look into it. > > > > BTW, just committed a patch for an elusive bug. Now it's > > possible to browse (& populate DNS cache), disconnect, click a > > link, have the abort operation on no network condition, reconnect > > and click it again (and it will work!). > > > > The only bit missing is how to make the link return to its > > normal color. a_Nav_repush() can do it easily but looks like an > > overkill. Maybe Johannes has a good idea on this? > > Not sure why it should change it's color. It's still a visited link > after all. AFAIS: clicked, not visited! (it was clicked and aborted before the data stream came in). > Or does the link color have another semantics (like page is in > cache) in dillo? Currently, it means exactly that: "page is in cache". That's why our FAQ links appear in visited color: http://www.dillo.org/FAQ.html If there's a good reason to change it, it should be simple. I see little difference for broadband users; dialup users may like the hint of what's available without connection. No strong feelings on this. > Anyway, the real solution would need the DOM-tree which is currently > not available. The DOM-tree would also be needed for :hover, :active, > and for Javascript. > However we could add a hack similar to the one to compute > html->visited_color in Html_tag_open_body(). > It assumes that there is just one visited_color in the whole page. Maybe a repush is not as bad a solution after all. ;) BTW, I hope you're comfortable in your new flat. -- Cheers Jorge.- From corvid at lavabit.com Wed Aug 19 05:37:17 2009 From: corvid at lavabit.com (corvid) Date: Wed Aug 19 06:06:31 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090819004228.GD5295@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090810124205.GE4402@local.gobigwest.com> <20090813015449.GD5788@dillo.org> <20090813194322.GA965@blob.baaderstrasse.com> <20090819004228.GD5295@dillo.org> Message-ID: <20090819033717.GB14990@local.gobigwest.com> Jorge wrote: > On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote: > > On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > > > BTW, just committed a patch for an elusive bug. Now it's > > > possible to browse (& populate DNS cache), disconnect, click a > > > link, have the abort operation on no network condition, reconnect > > > and click it again (and it will work!). > > > > > > The only bit missing is how to make the link return to its > > > normal color. a_Nav_repush() can do it easily but looks like an > > > overkill. Maybe Johannes has a good idea on this? > > > > Not sure why it should change it's color. It's still a visited link > > after all. > > AFAIS: clicked, not visited! > (it was clicked and aborted before the data stream came in). > > > Or does the link color have another semantics (like page is in > > cache) in dillo? > > Currently, it means exactly that: "page is in cache". > That's why our FAQ links appear in visited color: > http://www.dillo.org/FAQ.html > > If there's a good reason to change it, it should be simple. > I see little difference for broadband users; dialup users may > like the hint of what's available without connection. > No strong feelings on this. If we really care, I guess there's always alink/active: From jcid at dillo.org Wed Aug 19 16:46:46 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Aug 19 16:47:54 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090819033717.GB14990@local.gobigwest.com> References: <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090810124205.GE4402@local.gobigwest.com> <20090813015449.GD5788@dillo.org> <20090813194322.GA965@blob.baaderstrasse.com> <20090819004228.GD5295@dillo.org> <20090819033717.GB14990@local.gobigwest.com> Message-ID: <20090819144646.GA22691@dillo.org> On Wed, Aug 19, 2009 at 03:37:17AM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote: > > > On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > > > > BTW, just committed a patch for an elusive bug. Now it's > > > > possible to browse (& populate DNS cache), disconnect, click a > > > > link, have the abort operation on no network condition, reconnect > > > > and click it again (and it will work!). > > > > > > > > The only bit missing is how to make the link return to its > > > > normal color. a_Nav_repush() can do it easily but looks like an > > > > overkill. Maybe Johannes has a good idea on this? > > > > > > Not sure why it should change it's color. It's still a visited link > > > after all. > > > > AFAIS: clicked, not visited! > > (it was clicked and aborted before the data stream came in). > > > > > Or does the link color have another semantics (like page is in > > > cache) in dillo? > > > > Currently, it means exactly that: "page is in cache". > > That's why our FAQ links appear in visited color: > > http://www.dillo.org/FAQ.html > > > > If there's a good reason to change it, it should be simple. > > I see little difference for broadband users; dialup users may > > like the hint of what's available without connection. > > No strong feelings on this. > > If we really care, I guess there's always alink/active: I think the point is: do we follow Firefox and present links in "visited" color only once the user's been there? Is there any advantage of one scheme over the other? Is expected behaviour (FF) more relevant? If users would like to keep dillo's behaviour. Is it worth a preference? (dialup or for any other reason) -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Wed Aug 19 19:57:24 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Aug 19 19:59:38 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090819004228.GD5295@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090810124205.GE4402@local.gobigwest.com> <20090813015449.GD5788@dillo.org> <20090813194322.GA965@blob.baaderstrasse.com> <20090819004228.GD5295@dillo.org> Message-ID: <20090819175723.GB889@blob.baaderstrasse.com> On Tue, Aug 18, 2009 at 08:42:28PM -0400, Jorge Arellano Cid wrote: > On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote: > > On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > > > On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > [...] > > > > > All of these should be working now. Please report any further > > > > > problem you find. I'll try to make the empty cache entries removal > > > > > now, and then look for a way to hook the concurrent connection limit > > > > > without memory leaks. > > > > > > > > I don't know whether it's a problem, but I just noticed > > > > a difference in behaviour in that my form testcase that > > > > submits to localhost (there's no server listening) > > > > only prints "submitting multipart/form-data!" and > > > > I have to press stop to get > > > > '** WARNING **: IO_write, closing with pending data not sent' > > > > and see the query. > > > > > > Yes, I'm yet to look into it. > > > > > > BTW, just committed a patch for an elusive bug. Now it's > > > possible to browse (& populate DNS cache), disconnect, click a > > > link, have the abort operation on no network condition, reconnect > > > and click it again (and it will work!). > > > > > > The only bit missing is how to make the link return to its > > > normal color. a_Nav_repush() can do it easily but looks like an > > > overkill. Maybe Johannes has a good idea on this? > > > > Not sure why it should change it's color. It's still a visited link > > after all. > > AFAIS: clicked, not visited! > (it was clicked and aborted before the data stream came in). True. Perhaps we could change the link color to "visited" only after first data has arrived? Then we would not need to undo it on abort. > > > Or does the link color have another semantics (like page is in > > cache) in dillo? > > Currently, it means exactly that: "page is in cache". > That's why our FAQ links appear in visited color: > http://www.dillo.org/FAQ.html > > If there's a good reason to change it, it should be simple. > I see little difference for broadband users; dialup users may > like the hint of what's available without connection. > No strong feelings on this. > > > Anyway, the real solution would need the DOM-tree which is currently > > not available. The DOM-tree would also be needed for :hover, :active, > > and for Javascript. > > However we could add a hack similar to the one to compute > > html->visited_color in Html_tag_open_body(). > > It assumes that there is just one visited_color in the whole page. > > Maybe a repush is not as bad a solution after all. ;) I'd like to try the DOM-thing. It's not very complicated, but it will use some memory on large pages. > > BTW, I hope you're comfortable in your new flat. Yes, thanks. We're slowly getting back to normal :) Cheers, Johannes From Johannes.Hofmann at gmx.de Wed Aug 19 20:03:09 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Aug 19 20:05:22 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090818184651.GA5295@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> Message-ID: <20090819180309.GC889@blob.baaderstrasse.com> On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > On Wed, Aug 12, 2009 at 11:45:27PM +0000, corvid wrote: > > Jorge wrote: > > > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > > I added a new function call to the CCC API (wrapping the trick > > > of the previous patch) and used it in three parts of the code. > > > Please check the tip. > > > > > > > If I'm not connected and I try to go to a host that > > > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > > > > > Another SEGFAULT path was: > > > load dillo home > > > disconnect Internet > > > click 9years > > > press stop > > > > > > All of these should be working now. Please report any further > > > problem you find. I'll try to make the empty cache entries removal > > > now, and then look for a way to hook the concurrent connection limit > > > without memory leaks. > > > > I just got a segfault on NULL Info when going > > to the https url for the uclinux page: > > > > #0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, > > Branch=1, Dir=2, Info=0x0) at chain.c:191 > > #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, > > Data1=0x83e5ab0, Data2=0x0) at capi.c:522 > > #2 0x08063028 in Capi_conn_resume () at capi.c:172 > > #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, > > Data1=0x0, Data2=0x8122730) at capi.c:577 > > #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, > > Data2=0x8122730) at chain.c:113 > > #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, > > Data1=0x8b8d260, Data2=0x0) at dpi.c:625 > > #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, > > Data2=0x0) at chain.c:136 > > #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, > > Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 > > #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, > > cmd=0x8ee2400 " > It's the long waited for "empty cache entries removal". Now > it's done automatically on clicking a new link, and manually with > the Stop button. > > It doesn't sound impressive, but for instance, if you hit a > blog site full of heavy images, hitting the Stop button will > abort all the empty connections (not only stop rendering as in > the past). This allows for much faster browsing, especially with > low bandwidth, as the bandwidth is "rescued" from unwanted > contents. > > Another gain happens when a requested link takes a long time to > start flowing (e.g. ignored request by a busy browser). Just > press stop, click the link again and there you are. > > Please test, and enjoy! Excellent! Especially as I have a slow internet connection atm. > > > BTW: I don't remember whether a fix for the uClinux URL above was > already committed. It didn't SEGFAULT when testing tip. I got some segfaults recently. I will try to get a proper stack trace. Cheers, Johannes From Johannes.Hofmann at gmx.de Wed Aug 19 20:07:06 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Aug 19 20:09:16 2009 Subject: [Dillo-dev] newbie question about main loop... In-Reply-To: <1250618521.30733.34.camel@localhost.localdomain> References: <1250618521.30733.34.camel@localhost.localdomain> Message-ID: <20090819180706.GD889@blob.baaderstrasse.com> Hello, On Tue, Aug 18, 2009 at 11:02:01AM -0700, Chris Nicholas wrote: > Just learning about dillo; looks neat! > > We are investigating how best to "embed" html links within a 3D world, > in much the same way old-time 'anchor nodes' were embedded in VRML. We > were just thinking to have a separate tab, or if we got fancy, play with > OpenGL transforms, etc. > > Unfortunately, one of the libraries we use for avatars (www.edgelib.com) > *must* have the main loop, with everything else called during > onRedraw(), etc. Is it even conceivable to use dillo in this manner? I think you would need a process or a thread dedicated to dillo, as it loads html pages in the background. If you only want to render html that is already available you might get away with just calling some dillo code within the onRedraw() method. But you would need to dive into the dillo code for that. Best Regards, Johannes From jcid at dillo.org Wed Aug 19 20:19:44 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Aug 19 20:20:51 2009 Subject: [Dillo-dev] newbie question about main loop... In-Reply-To: <20090819180706.GD889@blob.baaderstrasse.com> References: <1250618521.30733.34.camel@localhost.localdomain> <20090819180706.GD889@blob.baaderstrasse.com> Message-ID: <20090819181944.GB22691@dillo.org> On Wed, Aug 19, 2009 at 08:07:06PM +0200, Johannes Hofmann wrote: > Hello, > > On Tue, Aug 18, 2009 at 11:02:01AM -0700, Chris Nicholas wrote: > > Just learning about dillo; looks neat! > > > > We are investigating how best to "embed" html links within a 3D world, > > in much the same way old-time 'anchor nodes' were embedded in VRML. We > > were just thinking to have a separate tab, or if we got fancy, play with > > OpenGL transforms, etc. > > > > Unfortunately, one of the libraries we use for avatars (www.edgelib.com) > > *must* have the main loop, with everything else called during > > onRedraw(), etc. Is it even conceivable to use dillo in this manner? > > I think you would need a process or a thread dedicated to dillo, as > it loads html pages in the background. > If you only want to render html that is already available you might > get away with just calling some dillo code within the onRedraw() > method. But you would need to dive into the dillo code for that. Another technique that may fit is to call FLTK's main loop periodically using fltk::check() or fltk::wait(). http://www.fltk.net/doc/ref13/classFl.html#1dbb83f1d52001c152ccf8415e3ee6f0 -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Thu Aug 20 20:03:57 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Aug 20 20:06:12 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090819180309.GC889@blob.baaderstrasse.com> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> <20090819180309.GC889@blob.baaderstrasse.com> Message-ID: <20090820180357.GA849@blob.baaderstrasse.com> On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > already committed. It didn't SEGFAULT when testing tip. > > I got some segfaults recently. I will try to get a proper stack > trace. Ok here it is. It happend after a couple of hours: Core was generated by `dillo'. Program terminated with signal 11, Segmentation fault. #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { (gdb) bt #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) at capi.c:537 #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, Data2=0x80f7669) at capi.c:178 #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, Data2=0x0) at dpi.c:625 #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, cmd=0x86cf328 "", server=0x8e2ff90 "bookmarks", flags=) at capi.c:493 #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 #10 0x080e22dc in fltk::Widget::send () #11 0x080d3935 in fltk::TabGroup::handle () #12 0x08054538 in CustTabGroup::handle (this=, e=) at uicmd.cc:312 #13 0x080e22dc in fltk::Widget::send () #14 0x080b2c0f in fltk::Group::handle () #15 0x080e4439 in fltk::Window::handle () #16 0x080e22dc in fltk::Widget::send () #17 0x080c7749 in fltk::handle () #18 0x080cac10 in fltk::handle () #19 0x080cc32d in do_queued_events () #20 0x080cc5a8 in fltk::wait () #21 0x080cc784 in fltk::run () #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 Current language: auto; currently c (gdb) Cheers, Johannes From devidfil at gmail.com Sat Aug 22 18:40:03 2009 From: devidfil at gmail.com (Devid Antonio Filoni) Date: Sat Aug 22 18:40:29 2009 Subject: [Dillo-dev] Switch to fltk1.3? Message-ID: <64a208ca0908220940x15ad5a59ldb4aa2f043444656@mail.gmail.com> Hi, is possible to switch to fltk1.3? I sent a lot of emails to fltk developers trying to get the license issue of fltk2 (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but I still (after months of sent emails) haven't gotten a reply. dillo is going to be removed from Debian and Ubuntu repositories because it depends on removed packages and the newest dillo release cannot be uploaded because fltk2 is not in the repositories and it cannot be accepted due to the license issue. Is possible to switch to fltk1.3 or to another toolkit please? Thanks, Devid Antonio Filoni From corvid at lavabit.com Sat Aug 22 21:42:14 2009 From: corvid at lavabit.com (corvid) Date: Sat Aug 22 21:45:45 2009 Subject: [Dillo-dev] Switch to fltk1.3? In-Reply-To: <64a208ca0908220940x15ad5a59ldb4aa2f043444656@mail.gmail.com> References: <64a208ca0908220940x15ad5a59ldb4aa2f043444656@mail.gmail.com> Message-ID: <20090822194213.GA22820@local.gobigwest.com> Devid wrote: > is possible to switch to fltk1.3? I sent a lot of emails to fltk > developers trying to get the license issue of fltk2 > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but > I still (after months of sent emails) haven't gotten a reply. dillo is > going to be removed from Debian and Ubuntu repositories because it > depends on removed packages and the newest dillo release cannot be > uploaded because fltk2 is not in the repositories and it cannot be > accepted due to the license issue. Is possible to switch to fltk1.3 or > to another toolkit please? Does anyone know how close 1.3 is to being usable? ISTR that, the last time the matter of 1.3 came up, someone among the regulars here felt that it was closer than I had thought it was going to be. I know there's http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3/TODO.utf8 but I don't know whether it reflects the current state of things. From jcid at dillo.org Sun Aug 23 15:43:26 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Aug 23 15:44:38 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090820180357.GA849@blob.baaderstrasse.com> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> <20090819180309.GC889@blob.baaderstrasse.com> <20090820180357.GA849@blob.baaderstrasse.com> Message-ID: <20090823134326.GA31778@dillo.org> On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > already committed. It didn't SEGFAULT when testing tip. > > > > I got some segfaults recently. I will try to get a proper stack > > trace. > > Ok here it is. It happend after a couple of hours: > > Core was generated by `dillo'. > Program terminated with signal 11, Segmentation fault. > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > at chain.c:191 > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > (gdb) bt > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > at chain.c:191 > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > at capi.c:537 > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > Data2=0x80f7669) at capi.c:178 > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > Data2=0x0) at dpi.c:625 > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > cmd=0x86cf328 "", server=0x8e2ff90 "bookmarks", > flags=) at capi.c:493 > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > #10 0x080e22dc in fltk::Widget::send () > #11 0x080d3935 in fltk::TabGroup::handle () > #12 0x08054538 in CustTabGroup::handle (this=, e=) > at uicmd.cc:312 > #13 0x080e22dc in fltk::Widget::send () > #14 0x080b2c0f in fltk::Group::handle () > #15 0x080e4439 in fltk::Window::handle () > #16 0x080e22dc in fltk::Widget::send () > #17 0x080c7749 in fltk::handle () > #18 0x080cac10 in fltk::handle () > #19 0x080cc32d in do_queued_events () > #20 0x080cc5a8 in fltk::wait () > #21 0x080cc784 in fltk::run () > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > Current language: auto; currently c > (gdb) Good. This is hard to track and I spent a lot of time trying to figure a way for it to happen. I don't yet find it, but at least saw there may be a small race window while the conn is unref'ed twice. Protection committed. Please test. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Mon Aug 24 23:29:46 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Mon Aug 24 23:32:02 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090823134326.GA31778@dillo.org> References: <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> <20090819180309.GC889@blob.baaderstrasse.com> <20090820180357.GA849@blob.baaderstrasse.com> <20090823134326.GA31778@dillo.org> Message-ID: <20090824212945.GA1924@blob.baaderstrasse.com> On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote: > On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > > already committed. It didn't SEGFAULT when testing tip. > > > > > > I got some segfaults recently. I will try to get a proper stack > > > trace. > > > > Ok here it is. It happend after a couple of hours: > > > > Core was generated by `dillo'. > > Program terminated with signal 11, Segmentation fault. > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > at chain.c:191 > > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > > (gdb) bt > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > at chain.c:191 > > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > > at capi.c:537 > > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > > Data2=0x80f7669) at capi.c:178 > > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > > Data2=0x0) at dpi.c:625 > > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > > cmd=0x86cf328 "", server=0x8e2ff90 "bookmarks", > > flags=) at capi.c:493 > > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > > #10 0x080e22dc in fltk::Widget::send () > > #11 0x080d3935 in fltk::TabGroup::handle () > > #12 0x08054538 in CustTabGroup::handle (this=, e=) > > at uicmd.cc:312 > > #13 0x080e22dc in fltk::Widget::send () > > #14 0x080b2c0f in fltk::Group::handle () > > #15 0x080e4439 in fltk::Window::handle () > > #16 0x080e22dc in fltk::Widget::send () > > #17 0x080c7749 in fltk::handle () > > #18 0x080cac10 in fltk::handle () > > #19 0x080cc32d in do_queued_events () > > #20 0x080cc5a8 in fltk::wait () > > #21 0x080cc784 in fltk::run () > > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > > Current language: auto; currently c > > (gdb) > > Good. > > This is hard to track and I spent a lot of time trying to > figure a way for it to happen. I don't yet find it, but at least > saw there may be a small race window while the conn is unref'ed > twice. > > Protection committed. Please test. > No crash so far! I will keep testing. Thanks, Johannes From corvid at lavabit.com Wed Aug 26 06:55:05 2009 From: corvid at lavabit.com (corvid) Date: Wed Aug 26 06:58:40 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090818184651.GA5295@dillo.org> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> Message-ID: <20090826045505.GC22820@local.gobigwest.com> Jorge wrote: > Just committed a patch that's being a delight to test! :) > > It's the long waited for "empty cache entries removal". Now > it's done automatically on clicking a new link, and manually with > the Stop button. > > It doesn't sound impressive, but for instance, if you hit a > blog site full of heavy images, hitting the Stop button will > abort all the empty connections (not only stop rendering as in > the past). This allows for much faster browsing, especially with > low bandwidth, as the bandwidth is "rescued" from unwanted > contents. > > Another gain happens when a requested link takes a long time to > start flowing (e.g. ignored request by a busy browser). Just > press stop, click the link again and there you are. > > Please test, and enjoy! I just noticed that if I press Stop when an image is partly loaded, leave the page, and return, the image is gone. I wanted the image to stay because it was an image map and the part I cared about had already been received. From jcid at dillo.org Wed Aug 26 15:15:45 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Aug 26 15:17:01 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090826045505.GC22820@local.gobigwest.com> References: <20090802174017.GA5222@dillo.org> <20090805011114.GB2444@dillo.org> <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> <20090826045505.GC22820@local.gobigwest.com> Message-ID: <20090826131545.GA4492@dillo.org> On Wed, Aug 26, 2009 at 04:55:05AM +0000, corvid wrote: > Jorge wrote: > > Just committed a patch that's being a delight to test! :) > > > > It's the long waited for "empty cache entries removal". Now > > it's done automatically on clicking a new link, and manually with > > the Stop button. > > > > It doesn't sound impressive, but for instance, if you hit a > > blog site full of heavy images, hitting the Stop button will > > abort all the empty connections (not only stop rendering as in > > the past). This allows for much faster browsing, especially with > > low bandwidth, as the bandwidth is "rescued" from unwanted > > contents. > > > > Another gain happens when a requested link takes a long time to > > start flowing (e.g. ignored request by a busy browser). Just > > press stop, click the link again and there you are. > > > > Please test, and enjoy! > > I just noticed that if I press Stop when an > image is partly loaded, leave the page, and > return, the image is gone. I wanted the image > to stay because it was an image map and the > part I cared about had already been received. Yes, that's the expected behaviour. Resume on HTTP connections is not implemented. This case is the only downside of the patch I've found. It's not a common case and the workaround is simple (just let the images you care for load before stopping or simply stop and keep the tab/page open). OTOH implementing HTTP resume is big work for just this bug. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Fri Aug 28 21:06:06 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Fri Aug 28 21:08:20 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090824212945.GA1924@blob.baaderstrasse.com> References: <20090806052004.GQ17894@local.gobigwest.com> <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> <20090819180309.GC889@blob.baaderstrasse.com> <20090820180357.GA849@blob.baaderstrasse.com> <20090823134326.GA31778@dillo.org> <20090824212945.GA1924@blob.baaderstrasse.com> Message-ID: <20090828190606.GA2076@blob.baaderstrasse.com> On Mon, Aug 24, 2009 at 11:29:45PM +0200, Johannes Hofmann wrote: > On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote: > > On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > > > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > > > already committed. It didn't SEGFAULT when testing tip. > > > > > > > > I got some segfaults recently. I will try to get a proper stack > > > > trace. > > > > > > Ok here it is. It happend after a couple of hours: > > > > > > Core was generated by `dillo'. > > > Program terminated with signal 11, Segmentation fault. > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > at chain.c:191 > > > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > > > (gdb) bt > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > at chain.c:191 > > > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > > > at capi.c:537 > > > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > > > Data2=0x80f7669) at capi.c:178 > > > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > > > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > > > Data2=0x0) at dpi.c:625 > > > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > > > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > > > cmd=0x86cf328 "", server=0x8e2ff90 "bookmarks", > > > flags=) at capi.c:493 > > > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > > > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > > > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > > > #10 0x080e22dc in fltk::Widget::send () > > > #11 0x080d3935 in fltk::TabGroup::handle () > > > #12 0x08054538 in CustTabGroup::handle (this=, e=) > > > at uicmd.cc:312 > > > #13 0x080e22dc in fltk::Widget::send () > > > #14 0x080b2c0f in fltk::Group::handle () > > > #15 0x080e4439 in fltk::Window::handle () > > > #16 0x080e22dc in fltk::Widget::send () > > > #17 0x080c7749 in fltk::handle () > > > #18 0x080cac10 in fltk::handle () > > > #19 0x080cc32d in do_queued_events () > > > #20 0x080cc5a8 in fltk::wait () > > > #21 0x080cc784 in fltk::run () > > > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > > > Current language: auto; currently c > > > (gdb) > > > > Good. > > > > This is hard to track and I spent a lot of time trying to > > figure a way for it to happen. I don't yet find it, but at least > > saw there may be a small race window while the conn is unref'ed > > twice. > > > > Protection committed. Please test. > > > > No crash so far! I will keep testing. > I can't crash it anymore. I guess we can consider this fixed :) BTW, is the CCC simplification related to the connection limit patch? Cheers, Johannes From corvid at lavabit.com Fri Aug 28 22:34:39 2009 From: corvid at lavabit.com (corvid) Date: Fri Aug 28 22:38:16 2009 Subject: [Dillo-dev] userinfo in uri authority Message-ID: <20090828203439.GA31054@local.gobigwest.com> With an url like http://user:pass@example.com, do you think the userinfo should be used? Or ripped out? From jcid at dillo.org Sat Aug 29 04:51:31 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Aug 29 04:52:49 2009 Subject: [Dillo-dev] Re: limit number of concurrent connections In-Reply-To: <20090828190606.GA2076@blob.baaderstrasse.com> References: <20090806221032.GA5452@dillo.org> <20090807201602.GW17894@local.gobigwest.com> <20090807223452.GB24560@dillo.org> <20090812234527.GI4402@local.gobigwest.com> <20090818184651.GA5295@dillo.org> <20090819180309.GC889@blob.baaderstrasse.com> <20090820180357.GA849@blob.baaderstrasse.com> <20090823134326.GA31778@dillo.org> <20090824212945.GA1924@blob.baaderstrasse.com> <20090828190606.GA2076@blob.baaderstrasse.com> Message-ID: <20090829025130.GA8101@dillo.org> On Fri, Aug 28, 2009 at 09:06:06PM +0200, Johannes Hofmann wrote: > On Mon, Aug 24, 2009 at 11:29:45PM +0200, Johannes Hofmann wrote: > > On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote: > > > On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > > > > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > > > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > > > > already committed. It didn't SEGFAULT when testing tip. > > > > > > > > > > I got some segfaults recently. I will try to get a proper stack > > > > > trace. > > > > > > > > Ok here it is. It happend after a couple of hours: > > > > > > > > Core was generated by `dillo'. > > > > Program terminated with signal 11, Segmentation fault. > > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > > at chain.c:191 > > > > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > > > > (gdb) bt > > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > > at chain.c:191 > > > > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > > > > at capi.c:537 > > > > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > > > > Data2=0x80f7669) at capi.c:178 > > > > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > > > > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > > > > Data2=0x0) at dpi.c:625 > > > > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > > > > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > > > > cmd=0x86cf328 "", server=0x8e2ff90 "bookmarks", > > > > flags=) at capi.c:493 > > > > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > > > > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > > > > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > > > > #10 0x080e22dc in fltk::Widget::send () > > > > #11 0x080d3935 in fltk::TabGroup::handle () > > > > #12 0x08054538 in CustTabGroup::handle (this=, e=) > > > > at uicmd.cc:312 > > > > #13 0x080e22dc in fltk::Widget::send () > > > > #14 0x080b2c0f in fltk::Group::handle () > > > > #15 0x080e4439 in fltk::Window::handle () > > > > #16 0x080e22dc in fltk::Widget::send () > > > > #17 0x080c7749 in fltk::handle () > > > > #18 0x080cac10 in fltk::handle () > > > > #19 0x080cc32d in do_queued_events () > > > > #20 0x080cc5a8 in fltk::wait () > > > > #21 0x080cc784 in fltk::run () > > > > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > > > > Current language: auto; currently c > > > > (gdb) > > > > > > Good. > > > > > > This is hard to track and I spent a lot of time trying to > > > figure a way for it to happen. I don't yet find it, but at least > > > saw there may be a small race window while the conn is unref'ed > > > twice. > > > > > > Protection committed. Please test. > > > > > > > No crash so far! I will keep testing. > > > > I can't crash it anymore. I guess we can consider this fixed :) Good. > BTW, is the CCC simplification related to the connection limit > patch? Yes and no. Yes: it may help with memory handling. No : the simplification was originally meant to help with stop. (and it has served to iron and clean other bugs too). -- Cheers Jorge.- From jcid at dillo.org Sun Aug 30 15:30:39 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Aug 30 15:31:57 2009 Subject: [devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?] In-Reply-To: <20090829110636.GA1451@blob.baaderstrasse.com> References: <20090829110636.GA1451@blob.baaderstrasse.com> Message-ID: <20090830133039.GC3984@dillo.org> On Sat, Aug 29, 2009 at 01:06:36PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > do you plan to answer this mail? Sorry I've been lost with other activities. > My point here is that we should > stick with fltk2 until there is an official release of fltk1.3. Yes. I agree. We went with unreleased FLTK2 and it has caused lots of problems (despite statical linking). > If there are license issues with fltk2 they should be handled > between debian and the fltk community. Of course we could try to > help. It looks like FLTK2 is quite stalled. Of course we can knock the door again. Maybe this is also a good time to ask for fltk1.3's timeline again. The last time, the optimistic release date was near the middle of 2009. > Date: Sat, 22 Aug 2009 18:40:03 +0200 > From: Devid Antonio Filoni > Subject: [Dillo-dev] Switch to fltk1.3? > To: dillo-dev@dillo.org > > Hi, > is possible to switch to fltk1.3? I sent a lot of emails to fltk > developers trying to get the license issue of fltk2 > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but > I still (after months of sent emails) haven't gotten a reply. dillo is > going to be removed from Debian and Ubuntu repositories because it > depends on removed packages and the newest dillo release cannot be > uploaded because fltk2 is not in the repositories and it cannot be > accepted due to the license issue. Is possible to switch to fltk1.3 or > to another toolkit please? > > Thanks, > Devid Antonio Filoni Hi Devid, We plan to switch to fltk1.3 soon. The point is to have a solid release date to start the port. When we started with fltk2 it was supposed to be released soon... :P I'm writing to the fltk1.3 team. Stay tuned. -- Cheers Jorge.-