- Dillo-dev - lists.mailman3.com

experimental patch: image loading options "same domain", "same host"

by corvid＠lavabit.com

Jorge wrote: > On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > > I just put together a somewhat hacky patch to > > add "same host" and "same domain" for image loading > > from the tools button (or dillorc) > > http://www.dillo.org/test/img_loading_options.patch > > > > I ran on it as long as I could tolerate images over > > dialup (not long :), so here it is, and I will clean > > it up if there is interest shown in getting it into > > dillo. > > Good! I've had a similar idea for a long time. > > Since before the url filtering thread, I believe a simple > blocking scheme based on same host/domain cuts most of the > problem (bandwidth, privacy, tracking, web bugs etc). > > I'd suggest to add the filtering function in Capi. This is > to make a_Capi_open_url() call a check function, e.g. > > if (Capi_filters_check_url(...) < 0) > /* abort */ > > (you may add a ParentUrl DilloUrl to the webstructure). > > The point is to be able to reuse and improve the filter. > (e.g. for CSS urls, sound streams, etc). > > > > (I would probably want to change the names of the > > dillorc choices for image loading, make the internal > > value into an enum, look at the loadImages/autoload_image > > code duplication, etc., etc... Oh, and look up how > > to fix the tools menu width...) > > Something like: > > filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > > should be enough to get started. I made a new one: http://www.dillo.org/test/filtering.1.patch It doesn't have the menu stuff, so you have to set the preference.

Sept. 12, 2009

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by Johannes.Hofmann＠gmx.de

On Thu, Sep 10, 2009 at 12:59:30PM -0400, Jorge Arellano Cid wrote: > Hi there, > > > On Sun, Aug 30, 2009 at 09:30:39AM -0400, Jorge Arellano Cid wrote: > > 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 <devidfil(a)gmail.com> > > > Subject: [Dillo-dev] Switch to fltk1.3? > > > To: dillo-dev(a)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. > > > Excellent news on this thread! > > > On Thu, Sep 10, 2009 at 09:17:52AM +0200, Matthias Melcher wrote: > > > > On 09.09.2009, at 17:35, Jorge Arellano Cid wrote: > > > >> Hi, > >> > >> Devid confirmed the proposed patch is OK! > > > > "Updated license to remain in the spirit of the original FLTK 2 license, > > but at the same time complying to Debian license requirements." > > > AFAIU this means the next FLTK2 snapshot will have the license > change, and distros can package it with no concerns. > > Details here: > > http://fltk.org/newsgroups.php?s4036+gfltk.commit+v4055+T0 > > To us, it means we can untroubledly keep our fltk2-based dillo > until fltk-1.3 sees an official release, and have it packaged by > the main distros, without any legal troubles. > > :-) Great! Thanks to everybody involved to get this resolved! Cheers, Johannes

Sept. 10, 2009

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by jcid＠dillo.org

Hi there, On Sun, Aug 30, 2009 at 09:30:39AM -0400, Jorge Arellano Cid wrote: > 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 <devidfil(a)gmail.com> > > Subject: [Dillo-dev] Switch to fltk1.3? > > To: dillo-dev(a)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. Excellent news on this thread! On Thu, Sep 10, 2009 at 09:17:52AM +0200, Matthias Melcher wrote: > > On 09.09.2009, at 17:35, Jorge Arellano Cid wrote: > >> Hi, >> >> Devid confirmed the proposed patch is OK! > > "Updated license to remain in the spirit of the original FLTK 2 license, > but at the same time complying to Debian license requirements." AFAIU this means the next FLTK2 snapshot will have the license change, and distros can package it with no concerns. Details here: http://fltk.org/newsgroups.php?s4036+gfltk.commit+v4055+T0 To us, it means we can untroubledly keep our fltk2-based dillo until fltk-1.3 sees an official release, and have it packaged by the main distros, without any legal troubles. :-) -- Cheers Jorge.-

Sept. 10, 2009

experimental patch: image loading options "same domain", "same host"

by jcid＠dillo.org

On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > I just put together a somewhat hacky patch to > add "same host" and "same domain" for image loading > from the tools button (or dillorc) > http://www.dillo.org/test/img_loading_options.patch > > I ran on it as long as I could tolerate images over > dialup (not long :), so here it is, and I will clean > it up if there is interest shown in getting it into > dillo. Good! I've had a similar idea for a long time. Since before the url filtering thread, I believe a simple blocking scheme based on same host/domain cuts most of the problem (bandwidth, privacy, tracking, web bugs etc). I'd suggest to add the filtering function in Capi. This is to make a_Capi_open_url() call a check function, e.g. if (Capi_filters_check_url(...) < 0) /* abort */ (you may add a ParentUrl DilloUrl to the webstructure). The point is to be able to reuse and improve the filter. (e.g. for CSS urls, sound streams, etc). > (I would probably want to change the names of the > dillorc choices for image loading, make the internal > value into an enum, look at the loadImages/autoload_image > code duplication, etc., etc... Oh, and look up how > to fix the tools menu width...) Something like: filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} should be enough to get started. -- Cheers Jorge.-

Sept. 7, 2009

experimental patch: image loading options "same domain", "same host"

by corvid＠lavabit.com

I just put together a somewhat hacky patch to add "same host" and "same domain" for image loading from the tools button (or dillorc) http://www.dillo.org/test/img_loading_options.patch I ran on it as long as I could tolerate images over dialup (not long :), so here it is, and I will clean it up if there is interest shown in getting it into dillo. (I would probably want to change the names of the dillorc choices for image loading, make the internal value into an enum, look at the loadImages/autoload_image code duplication, etc., etc... Oh, and look up how to fix the tools menu width...)

Sept. 7, 2009

nytimes links and redirection

by corvid＠lavabit.com

I'd been in the habit of letting wget retrieve nytimes links, but today I finally fought with it long enought to learn a few things. - wget works because it remembers cookies while redirecting. I was sure that enabling cookies required a flag, but nope. - If I increase the maximum redirect level in dillo, it gets up to 9 before nytimes relents and figures out that I don't want to give it any cookies and provides me with the page. - If I change the www to www10, it works immediately and doesn't bother with redirection at all.

Sept. 5, 2009

perhaps an iterator bug

by Johannes.Hofmann＠gmx.de

On Thu, Sep 03, 2009 at 01:28:57PM -0400, Jorge Arellano Cid wrote: > On Thu, Sep 03, 2009 at 04:45:29PM +0000, corvid wrote: > > I wrote, back in February: > > > I was trying the new search functionality a bit more > > > and found this (it's also present in my Dec 2008 dillo*). > > > > > > With the page: > > > > > > <table> > > > <tr><td>no close-tr > > > <tr><td>has a close-tr</tr> > > > <tr><td>here's another line</tr> > > > </table> > > > > > > if I search for "rh", it finds one instance of it > > > split between the second and third table rows. > > > > At the time, I didn't recognize what the exact problem was. > > Now it dawns on me that the difference is really that > > line 2's text has whitespace before the next tag, > > and line 3's doesn't. > > > > It would be nice if the iterators thought of cells > > as being separated by whitespace, but I don't know yet > > whether there's a good and simple way to do that... > > A whitespace suffix with width=0 comes to mind... Or perhaps TableIterator() could generate some separators?

Sept. 3, 2009

perhaps an iterator bug

by jcid＠dillo.org

On Thu, Sep 03, 2009 at 04:45:29PM +0000, corvid wrote: > I wrote, back in February: > > I was trying the new search functionality a bit more > > and found this (it's also present in my Dec 2008 dillo*). > > > > With the page: > > > > <table> > > <tr><td>no close-tr > > <tr><td>has a close-tr</tr> > > <tr><td>here's another line</tr> > > </table> > > > > if I search for "rh", it finds one instance of it > > split between the second and third table rows. > > At the time, I didn't recognize what the exact problem was. > Now it dawns on me that the difference is really that > line 2's text has whitespace before the next tag, > and line 3's doesn't. > > It would be nice if the iterators thought of cells > as being separated by whitespace, but I don't know yet > whether there's a good and simple way to do that... A whitespace suffix with width=0 comes to mind... -- Cheers Jorge.-

Sept. 3, 2009

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by jcid＠dillo.org

Hi there, Here comes the rest of the story, and the steps we're taking. On Sun, Aug 30, 2009 at 09:30:39AM -0400, Jorge Arellano Cid wrote: > 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 <devidfil(a)gmail.com> > > Subject: [Dillo-dev] Switch to fltk1.3? > > To: dillo-dev(a)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. I wrote to Matthias Melcher and this is what happened: > [On Sep 2, Matthias wrote:] > > OK, here is the history of the license additions which should make things > clearer: > > All initial authors of FLTK (Bill, Mike, myself) had commercial > applications in mind or were actively working on them. GPL was out of > question. LGPL mostly fit Bill's ideas, but it had to be shoe-horned so > that "Nuke", the commercial product of his employer "Digital Domain" would > be satisfied. > > DD'd first problem was that they were afreid the Nuke would be seen as > derived work and hence require the source to be opened (yes, I know, but > that such is lawyer logic). > > The second issue was that DD did not want t have to mention any of that > brand new LGPL licensing stuff (LGPL was pretty much brand new 15 years ago > and highly disputed). > > Thirdly, Mike back then owned his own business, and he wanted to support > FLTK, but avoid similar risks. IIRC he added the ammendments. > > So here is my suggestion: > I will not be able to completely remove the ammendments, but I doubt that > there will be much of a fight if we change some wording. If I read the > artikles right, the May version would be acceptable for FLTK 2. If that is > so, I will push that through with the team. If neither wording works, > please have someone suggest a version in the light of the explanations > above. Devid, you're surely in a better position to judge the legal aspect of using the May version of the license. At least you can ask Debian legal! If that's enough to get FLTK2 packaged, we can push it forward this way. If not, I can talk the problem with the fltk-1.3 development team, try to get a release estimation date and speed up the port to fltk-1.3 accordingly. AFAIU the 1.3 branch has no license issues. I'll be expecting your answer to get back to fltk devs. TIA. -- Cheers Jorge.-

Sept. 3, 2009

whattheinternetknowsaboutyou

by Johannes.Hofmann＠gmx.de

On Wed, Sep 02, 2009 at 08:47:59PM +0000, corvid wrote: > Johannes wrote: > > this http://wtikay.com/docs/details.html is quite interesting. Dillo > > is not vulnerable, but we should keep this in mind when implementing > > background image support. > > Are background images the only way for them to > pull that off? The other way they describe uses Javascript. But it would also be possible to make links visible/invisible depending on whether the user has visited a site (see below). From what the user then clicks one might get a clue about his browser history. But this is not automatic and only one piece of history information per click. Cheers, Johannes <html> <head> <style type="text/css"> body {background-color: white} a {color: white} :visited #bad {color: red} :link #good {color: red} </style> <body> <a href="http://wikileaks.org"><a href="hevisitedwikileaks.html" id="bad">click here</a></a> <br/> <a href="http://wikileaks.org"><a href="heisok.html" id="good">click here</a></a> </body> </html>

Sept. 3, 2009

perhaps an iterator bug

by corvid＠lavabit.com

I wrote, back in February: > I was trying the new search functionality a bit more > and found this (it's also present in my Dec 2008 dillo*). > > With the page: > > <table> > <tr><td>no close-tr > <tr><td>has a close-tr</tr> > <tr><td>here's another line</tr> > </table> > > if I search for "rh", it finds one instance of it > split between the second and third table rows. At the time, I didn't recognize what the exact problem was. Now it dawns on me that the difference is really that line 2's text has whitespace before the next tag, and line 3's doesn't. It would be nice if the iterators thought of cells as being separated by whitespace, but I don't know yet whether there's a good and simple way to do that...

Sept. 3, 2009

whattheinternetknowsaboutyou

by corvid＠lavabit.com

Johannes wrote: > this http://wtikay.com/docs/details.html is quite interesting. Dillo > is not vulnerable, but we should keep this in mind when implementing > background image support. Are background images the only way for them to pull that off?

Sept. 2, 2009

whattheinternetknowsaboutyou

by Johannes.Hofmann＠gmx.de

Hi, this http://wtikay.com/docs/details.html is quite interesting. Dillo is not vulnerable, but we should keep this in mind when implementing background image support. Cheers, Johannes

Sept. 2, 2009

horizontal scrolling while searching

by Johannes.Hofmann＠gmx.de

On Wed, Sep 02, 2009 at 05:02:28PM +0000, corvid wrote: > Johannes wrote: > > corvid, you have just fixed an issue with horizontal scrolling > > during search. > > While testing it I realized, that horizontal scrolling during search > > does not work at all with plain text. Any idea why? > > Actually, I made a patch for that last night (attached). > > getAllocation() determines the boundaries and position > of a Word, and then Iterator's scrollTo() figures out how > to place it. > > But for plain text, the whole line is a Word, so scrollTo > was just positioning the line as a whole and considering its > work done. > > In the patch, I take start and end into account to figure out > what part of the Word we really want to see. > (The current behaviour of showing the whole word is a little > bit nicer for html with "normal"-sized Words, but...) > Cool! Please commit. Cheers, Johannes

Sept. 2, 2009

horizontal scrolling while searching

by corvid＠lavabit.com

Johannes wrote: > corvid, you have just fixed an issue with horizontal scrolling > during search. > While testing it I realized, that horizontal scrolling during search > does not work at all with plain text. Any idea why? Actually, I made a patch for that last night (attached). getAllocation() determines the boundaries and position of a Word, and then Iterator's scrollTo() figures out how to place it. But for plain text, the whole line is a Word, so scrollTo was just positioning the line as a whole and considering its work done. In the patch, I take start and end into account to figure out what part of the Word we really want to see. (The current behaviour of showing the whole word is a little bit nicer for html with "normal"-sized Words, but...)

Sept. 2, 2009

Planning

by jcid＠dillo.org

On Tue, Sep 01, 2009 at 09:30:54PM +0200, Johannes Hofmann wrote: > On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > > Hi, > > > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Here are some pending issues which I've partially sorted by > > > priority (at least the top half). Please add the missing ones and > > > let's try to finish sorting it, with a view to planify our work. > > > > > > > > > * Make DIV-based pages render correctly. > > > This is the most visible rendering fault in Dillo. The > > > textblock doesn't have a way to handle it (not implemented). > > > IIRC I'm willing to dig into it and Johannes will help. > > > e.g. http://www.advogato.org/faq.html > > > > With DIV-based pages you mean floats as in > > http://www.w3.org/TR/CSS21/visuren.html#floats? > > Yes, this is the most obvious rendering problem atm. > > > > > > > > * Add blocker (this also has to do with privacy). > > > A full RE-based one may have significant overhead (test > > > required), but simple string-matching may do most of the trick. > > > I've also thought for a long time that a "don't load from > > > other sites" preference may help a lot. The whole topic needs > > > some thought but it's not hard to implement. > > > e.g. doubleclick. > > > > > > * Handle negative values in CSS. e.g. wikipedia. > > > > Actually it's dw/* that needs to be adapted to handle negative > > margins. This might be related to the floats stuff. > > > > > > > > * What will we do with xhtml? To render or not to render... > > > FF doesn't validate. BUG#732 > > > One solution is to add a notification widget area below the > > > control panel that hides/unhides as the find bar, to warn when a > > > xhtml file has detected bugs (we'd also move the meta refresh > > > warning to display here). I already have a simple patch to add > > > xhtml rendering. The widget implemetation is the missing part. > > > It should be much simpler than the close button in each tab. :-) > > > e.g. http://planet.postgresql.org/ > > > > > > * Jump to #anchor doesn't work correctly. > > > It looks like a timing issue, but the idle-call API needs a > > > review as a whole. > > > > > > * dpi for "view page source" (it re-uses search capability). > > > This requires a check of the current data-passing inside DPIP. > > > > > > * Improve the DPI development/debug framework. > > > > > > * https dialog bombing issue. BUG#868 > > > AKA make https dpi a server (i.e. not a filter dpi). > > > > > > * Render bug at http://www.directfb.org/ (and its links). The > > > table has too wide a first column. Back/Fwd solves it. > > > > Yes, I've seen this on several pages. > > > > > > > > *   handling in fltk.org > > > The relevant point is to define a consistent way to handle > > > whitespace in the textblock. > > > > Can you explain the problem a bit? > > > > > > > > * FTP download doesn't work?! > > > > wget - based downloads work mostly fine for me. Where do you see an > > issue? > > > > I've got one more point: > > > > * Add clipping to the fltk drawing code, so that e.g. margins of huge > > boxes don't cause X11 coordinate overflows. > > E.g. on http://alpen-panoramen.de/newcomments.php > > I will try to fix that. > > Ok fix committed. This took a lot longer than expected. I almost had > full polygon clipping implemented which is quite complex, until I > realized that it is much simpler to change Style::drawBorder() to > use rectangles and triangles instead of a single polygon for each > side. > That way we can easily clip the large part of the border (the > rectangle) and avoid X11 coordinate overflows. > It also seems that this makes dillo a bit snappier. Good, I also feel the extra snappiness! -- Cheers Jorge.-

Sept. 2, 2009

horizontal scrolling while searching

by Johannes.Hofmann＠gmx.de

corvid, you have just fixed an issue with horizontal scrolling during search. While testing it I realized, that horizontal scrolling during search does not work at all with plain text. Any idea why? Cheers, Johannes

Sept. 2, 2009

Planning

by Johannes.Hofmann＠gmx.de

On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > Hi, > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Here are some pending issues which I've partially sorted by > > priority (at least the top half). Please add the missing ones and > > let's try to finish sorting it, with a view to planify our work. > > > > > > * Make DIV-based pages render correctly. > > This is the most visible rendering fault in Dillo. The > > textblock doesn't have a way to handle it (not implemented). > > IIRC I'm willing to dig into it and Johannes will help. > > e.g. http://www.advogato.org/faq.html > > With DIV-based pages you mean floats as in > http://www.w3.org/TR/CSS21/visuren.html#floats? > Yes, this is the most obvious rendering problem atm. > > > > > * Add blocker (this also has to do with privacy). > > A full RE-based one may have significant overhead (test > > required), but simple string-matching may do most of the trick. > > I've also thought for a long time that a "don't load from > > other sites" preference may help a lot. The whole topic needs > > some thought but it's not hard to implement. > > e.g. doubleclick. > > > > * Handle negative values in CSS. e.g. wikipedia. > > Actually it's dw/* that needs to be adapted to handle negative > margins. This might be related to the floats stuff. > > > > > * What will we do with xhtml? To render or not to render... > > FF doesn't validate. BUG#732 > > One solution is to add a notification widget area below the > > control panel that hides/unhides as the find bar, to warn when a > > xhtml file has detected bugs (we'd also move the meta refresh > > warning to display here). I already have a simple patch to add > > xhtml rendering. The widget implemetation is the missing part. > > It should be much simpler than the close button in each tab. :-) > > e.g. http://planet.postgresql.org/ > > > > * Jump to #anchor doesn't work correctly. > > It looks like a timing issue, but the idle-call API needs a > > review as a whole. > > > > * dpi for "view page source" (it re-uses search capability). > > This requires a check of the current data-passing inside DPIP. > > > > * Improve the DPI development/debug framework. > > > > * https dialog bombing issue. BUG#868 > > AKA make https dpi a server (i.e. not a filter dpi). > > > > * Render bug at http://www.directfb.org/ (and its links). The > > table has too wide a first column. Back/Fwd solves it. > > Yes, I've seen this on several pages. > > > > > *   handling in fltk.org > > The relevant point is to define a consistent way to handle > > whitespace in the textblock. > > Can you explain the problem a bit? > > > > > * FTP download doesn't work?! > > wget - based downloads work mostly fine for me. Where do you see an > issue? > > I've got one more point: > > * Add clipping to the fltk drawing code, so that e.g. margins of huge > boxes don't cause X11 coordinate overflows. > E.g. on http://alpen-panoramen.de/newcomments.php > I will try to fix that. Ok fix committed. This took a lot longer than expected. I almost had full polygon clipping implemented which is quite complex, until I realized that it is much simpler to change Style::drawBorder() to use rectangles and triangles instead of a single polygon for each side. That way we can easily clip the large part of the border (the rectangle) and avoid X11 coordinate overflows. It also seems that this makes dillo a bit snappier. Cheers, Johannes

Sept. 1, 2009

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by jcid＠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 <devidfil(a)gmail.com> > Subject: [Dillo-dev] Switch to fltk1.3? > To: dillo-dev(a)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.-

Aug. 30, 2009

Re: limit number of concurrent connections

by jcid＠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 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > > > > flags=<value optimized out>) 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=<value optimized out>, e=<value optimized out>) > > > > 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.-

Aug. 29, 2009

userinfo in uri authority

by corvid＠lavabit.com

With an url like http://user:pass@example.com, do you think the userinfo should be used? Or ripped out?

Aug. 28, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

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 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > > > flags=<value optimized out>) 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=<value optimized out>, e=<value optimized out>) > > > 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

Aug. 28, 2009

Re: limit number of concurrent connections

by jcid＠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.-

Aug. 26, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.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.

Aug. 26, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

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 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > > flags=<value optimized out>) 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=<value optimized out>, e=<value optimized out>) > > 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

Aug. 24, 2009

Re: limit number of concurrent connections

by jcid＠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 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > flags=<value optimized out>) 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=<value optimized out>, e=<value optimized out>) > 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.-

Aug. 23, 2009

Switch to fltk1.3?

by corvid＠lavabit.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.

Aug. 22, 2009

Switch to fltk1.3?

by devidfil＠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

Aug. 22, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

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 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", flags=<value optimized out>) 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=<value optimized out>, e=<value optimized out>) 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

Aug. 20, 2009

newbie question about main loop...

by jcid＠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.-

Aug. 19, 2009

newbie question about main loop...

by Johannes.Hofmann＠gmx.de

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

Aug. 19, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

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 "<cmd='open_url' url='https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=F…' query='GET /gf/project/uclinux-dist/fo"..., > > server=0x8b8d260 "proto.https", flags=1) at capi.c:482 > > [snip] > > 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! 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

Aug. 19, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

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

Aug. 19, 2009

Re: limit number of concurrent connections

by jcid＠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.-

Aug. 19, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.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:

Aug. 19, 2009

Re: limit number of concurrent connections

by jcid＠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.-

Aug. 19, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.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.

Aug. 18, 2009

Happy announcement (not SW)

by jcid＠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.-

Aug. 18, 2009

Re: limit number of concurrent connections

by jcid＠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 "<cmd='open_url' url='https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=F…' query='GET /gf/project/uclinux-dist/fo"..., > server=0x8b8d260 "proto.https", flags=1) at capi.c:482 > [snip] 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! BTW: I don't remember whether a fix for the uClinux URL above was already committed. It didn't SEGFAULT when testing tip. -- Cheers Jorge.-

Aug. 18, 2009

newbie question about main loop...

by cnicholas＠planet9.com

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

Aug. 18, 2009

Crosscompiling Dillo2 for uClinux on Blackfin

by jcid＠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.-

Aug. 15, 2009

Crosscompiling Dillo2 for uClinux on Blackfin

by corvid＠lavabit.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.

Aug. 15, 2009

AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

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(a)dillo.org [dillo-dev-bounces(a)dillo.org] im Auftrag von Johannes Hofmann [Johannes.Hofmann(a)gmx.de] Gesendet: Freitag, 14. August 2009 21:11 An: dillo-dev(a)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(a)dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Aug. 14, 2009

AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

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(a)dillo.org [dillo-dev-bounces(a)dillo.org] im Auftrag von corvid [corvid(a)lavabit.com] Gesendet: Freitag, 14. August 2009 17:05 An: dillo-devel-list (dillo-dev(a)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(a)dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Aug. 14, 2009

Crosscompiling Dillo2 for uClinux on Blackfin

by Johannes.Hofmann＠gmx.de

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

Aug. 14, 2009

Crosscompiling Dillo2 for uClinux on Blackfin

by corvid＠lavabit.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...)

Aug. 14, 2009

AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

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 <heisermi(a)hs-albsig.de> 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(a)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(a)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(a)dillo.org [mailto:dillo-dev-bounces@dillo.org] Im > Auftrag von Michal Nowak > Gesendet: Freitag, 14. August 2009 12:36 > An: dillo-dev(a)dillo.org > Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin > > On Fri, Aug 14, 2009 at 9:00 AM, Heiser Michael<heisermi(a)hs-albsig.de> > 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(a)dillo.org >> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)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

Aug. 14, 2009

AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

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(a)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(a)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(a)dillo.org [mailto:dillo-dev-bounces@dillo.org] Im Auftrag von Michal Nowak Gesendet: Freitag, 14. August 2009 12:36 An: dillo-dev(a)dillo.org Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin On Fri, Aug 14, 2009 at 9:00 AM, Heiser Michael<heisermi(a)hs-albsig.de> 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(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > _______________________________________________ Dillo-dev mailing list Dillo-dev(a)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

Aug. 14, 2009

AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

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(a)dillo.org [mailto:dillo-dev-bounces@dillo.org] Im Auftrag von Michal Nowak Gesendet: Freitag, 14. August 2009 12:36 An: dillo-dev(a)dillo.org Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin On Fri, Aug 14, 2009 at 9:00 AM, Heiser Michael<heisermi(a)hs-albsig.de> 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(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > _______________________________________________ Dillo-dev mailing list Dillo-dev(a)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

Aug. 14, 2009

Crosscompiling Dillo2 for uClinux on Blackfin

by newman.x＠gmail.com

On Fri, Aug 14, 2009 at 9:00 AM, Heiser Michael<heisermi(a)hs-albsig.de> 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(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 14, 2009