- Dillo-dev - lists.mailman3.com

[Dillo-dev]dillo-0.8.0-rc1.tar.bz2

by Jorge Arellano Cid

Hi, The new 0.8.0-rc1 tarball is ready for download! It is at: http://www.dillo.org/test/dillo-0.8.0-rc1.tar.bz2 Its version string is "0.8.0" instead of "0.8.0-rc1"; to ease the labor of packagers. Unless a problem is reported today, the release will be made tomorrow. Kelson, Phil: I'd wish I could have given you more time for making the packages, but I'm leaving the city tomorrow for a week off! :-) Enjoy Jorge.-

Feb. 8, 2004

Re: [Dillo-dev]AIX problems

by Jorge Arellano Cid

On Sat, 7 Feb 2004, Riccardo wrote: > > > > > > where do I find this tarball? > > > > http://www.dillo.org/test/dillo-0.8.0-pre.Feb02.tar.gz > > > Ok, I recompiled a "patched" gtk+ 1.2.10 and installed it > > I got the aboove tarbal, compiled it without modifications and it > compiled smoothlz (except some warnings about int and long int arguments > and similar). > > but the binary still crashes, unfortunately :-( Please send me the warnings. Cheers Jorge.- PS: Tomorrow I'll upload dillo-0.8.0-rc1 (same as current CVS). Most probably this will be the released one. Last hour testing is welcome :-)

Feb. 8, 2004

Re: [Dillo-dev]AIX problems

by Riccardo

> > > where do I find this tarball? > > http://www.dillo.org/test/dillo-0.8.0-pre.Feb02.tar.gz > Ok, I recompiled a "patched" gtk+ 1.2.10 and installed it I got the aboove tarbal, compiled it without modifications and it compiled smoothlz (except some warnings about int and long int arguments and similar). but the binary still crashes, unfortunately the only backtrace I get is this: which isn't very useful I fear. Program received signal SIGILL, Illegal instruction. 0x0 in ?? () from /usr/local/build/dillo-0.8.0-pre/src/./dillo (gdb) bt #0 0x0 in ?? () from /usr/local/build/dillo-0.8.0-pre/src/./dillo (gdb) Riccardo

Feb. 7, 2004

[Dillo-dev]Last fixes to dpi...

by Jorge Arellano Cid

Hi there! The last fixes to the dpi framework were just commited: <q> + Added install-dpi-local; a script to ease non-system-wide installation of the dpi framework. + Fixed dpid to work correctly with a dpi intallation inside the user's account. + Updated several docs with regard to dpi. </q> I'll chase a minor bug now... Hopefully tomorrow there'll be a dillo-0.8.0-rc1 tarball. Cheers Jorge.-

Feb. 6, 2004

Re: [Dillo-dev]Frame support in CVS

by Jacky Lam

I have an mail from Frank that he has lost interest to keep the patch up-to-date because the maintainer hasn't seriously consider merging of the patch. Is there any reason that Frank's patch is not merged? If there is a proper reason, I think Frank would like to continue the job. Anyway, if you want to try out the patch, please use 0.7.3 release instead of CVS version. It works very well. Thanks. Best wishes, Jacky ----- Original Message ----- From: "Kelson Vibber" <kelson(a)pobox.com> To: <dillo-dev(a)auriga.wearlab.de> Sent: Friday, February 06, 2004 6:05 AM Subject: Re: [Dillo-dev]Frame support in CVS > At 07:39 PM 2/3/2004, Jacky Lam wrote: > > I am new to dillo and I want to use dillo with frame support. I try > > dillo in CVS and find it only show some link pages for each frames > > respectively. Is it the current status? How about Frank patches? > > I don't know. I tried applying the latest version of Frank's patch > (version 16, from November 24), but ended up with about 30 reject files, so > it's clearly *way* out of sync. Unfortunately, Frank hasn't posted here > since early December. > > Does anyone else know what's going on with this? Even if frames aren't > being merged in yet, it would be nice to have a patch that's in sync with > the new release. > > Kelson Vibber > www.hyperborea.org > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 6, 2004

Re: [Dillo-dev]Frame support in CVS

by Kelson Vibber

At 07:39 PM 2/3/2004, Jacky Lam wrote: > I am new to dillo and I want to use dillo with frame support. I try > dillo in CVS and find it only show some link pages for each frames > respectively. Is it the current status? How about Frank patches? I don't know. I tried applying the latest version of Frank's patch (version 16, from November 24), but ended up with about 30 reject files, so it's clearly *way* out of sync. Unfortunately, Frank hasn't posted here since early December. Does anyone else know what's going on with this? Even if frames aren't being merged in yet, it would be nice to have a patch that's in sync with the new release. Kelson Vibber www.hyperborea.org

Feb. 5, 2004

Re: [Dillo-dev]RPM question, and how close is 0.8.0?

by Kelson Vibber

At 06:14 AM 2/5/2004, Jorge Arellano Cid wrote: >The idea is to have it ready this Sunday so the announcement is >made by Monday in the morning. OK! Sooner than I expected! I may be busy this Sunday evening, but I'll at least build the source RPM and the RH8/RH9/FC1 RPM so they'll be ready on Monday. I'll add anything else I have time for, and do the rest Monday evening. (SuSE 9 will have to wait until Monday since I need to build it at work.) > > 2. Include all DPIs in the dillo package. Do require wget. >... > Just as you, my choice is #2. Sounds good. I'll do that. Kelson Vibber www.hyperborea.org

Feb. 5, 2004

Re: [Dillo-dev]RPM question, and how close is 0.8.0?

by Jorge Arellano Cid

Hi Kelson! On Tue, 3 Feb 2004, Kelson Vibber wrote: > At 08:21 AM 2/3/2004, Jorge Arellano Cid wrote: > > I'll start working on it after the 0.8.0 release. > > Any idea how soon that's coming? The idea is to have it ready this Sunday so the announcement is made by Monday in the morning. The newest CVS has the splash screen (grammar corrections are welcome:), and the pending issues are: * dpis should be able to run from ~/.dillo. I'll check that and maybe provide a shell script to install them there for users not having root access. * pthreads is still linked in dpis. This needs a patch but it's not indispensable. The release will be made with or without it. * Maybe it'd be good to mute dpid when started by dillo (to avoid printing to the terminal, specially when it exits). Not sure though and it's also a minor thing. * Expect reports on portability. This has been done to a good extent so I'll not delay the release because of it. After the release I'll take a week off! :-) > I've started making the necessary changes > for the RPM spec based on the current CVS version. With luck I'll be able > to start building as soon as the tarball is ready. I've posted some test > RPMs at http://www.hyperborea.org/software/dillo/pre.html if anyone's > interested. > > Question: I noticed that several of the included DPIs (https, ftp, > download) require wget. However, the main browser does not require > wget. That leads to several choices as far as RPM dependencies go: > > 1. Include all DPIs in the dillo package. Don't require wget. > 2. Include all DPIs in the dillo package. Do require wget. > 3. Separate the FTP, HTTPS, and download DPIs into a separate package > (something like "dillo-protocols") and set that package to require wget. > > Advantages: > #1: Simple installation, most linux distros probably already include wget > #2: Simple installation, lets you know about wget if you haven't installed > it already. > #3: If you don't want wget, you're not forced to install it. If you want > the plugin, you're told wget is needed. > > Problems: > #1: If you don't have wget, installing won't tell you that you need it. > #2: If you don't want to use those DPIs and you don't want wget, you need > to install it anyway. > #3: Installing is more complicated, because you have to download and > upgrade two RPMs. > > I don't think #1 is really an option, because it means people can install > dillo via RPM and not everything will work. > > I'm inclined to choose #2 over #3, just because of the simplicity. If > someone just wants to install Dillo, they already have to look through a > list of about 10 different RPMs for the right system, and sometimes people > miss the one they need. I occasionally get requests to add an RPM for a > system that's already on the list. On the other hand, some people might > consider wget to be unnecessary if they're not going to be using those DPIs. > > Anyway, has anyone got any thoughts on this issue? Just as you, my choice is #2. Cheers Jorge.-

Feb. 5, 2004

Re: [Dillo-dev]AIX problems

by Jorge Arellano Cid

On Wed, 4 Feb 2004, Riccardo wrote: > Hey Jorge, > > ok, I had to use /bin/sh... > > > > > How? > > > > unpack e clean gtk+-1.2.10 > > cd gtk+-1.2.10 > > copy "fix" to this directory > > chmod +x fix > > find -name "*" -exec ./fix {} \; > > find . -name <etc) > > > > Then grab dillo-0.8.0-pre.Feb02.tar.gz from dillo.org/test/ > > and try it! > > > > can I use CVS too? Yes, but CVS requires to run autogen.sh, which needs a properly intalled autoconf/automake pair. > where do I find this tarball? http://www.dillo.org/test/dillo-0.8.0-pre.Feb02.tar.gz Cheers Jorge.-

Feb. 5, 2004

Re: [Dillo-dev]AIX problems

by Riccardo

Hey Jorge, ok, I had to use /bin/sh... > > How? > > unpack e clean gtk+-1.2.10 > cd gtk+-1.2.10 > copy "fix" to this directory > chmod +x fix > find -name "*" -exec ./fix {} \; find . -name <etc) > Then grab dillo-0.8.0-pre.Feb02.tar.gz from dillo.org/test/ > and try it! > can I use CVS too? where do I find this tarball? -Ric

Feb. 4, 2004

[Dillo-dev]Frame support in CVS

by Jacky Lam

Hi, all, I am new to dillo and I want to use dillo with frame support. I try dillo in CVS and find it only show some link pages for each frames respectively. Is it the current status? How about Frank patches? Thanks. Best regards, Jacky

Feb. 4, 2004

[Dillo-dev]RPM question, and how close is 0.8.0?

by Kelson Vibber

At 08:21 AM 2/3/2004, Jorge Arellano Cid wrote: > I'll start working on it after the 0.8.0 release. Any idea how soon that's coming? I've started making the necessary changes for the RPM spec based on the current CVS version. With luck I'll be able to start building as soon as the tarball is ready. I've posted some test RPMs at http://www.hyperborea.org/software/dillo/pre.html if anyone's interested. Question: I noticed that several of the included DPIs (https, ftp, download) require wget. However, the main browser does not require wget. That leads to several choices as far as RPM dependencies go: 1. Include all DPIs in the dillo package. Don't require wget. 2. Include all DPIs in the dillo package. Do require wget. 3. Separate the FTP, HTTPS, and download DPIs into a separate package (something like "dillo-protocols") and set that package to require wget. Advantages: #1: Simple installation, most linux distros probably already include wget #2: Simple installation, lets you know about wget if you haven't installed it already. #3: If you don't want wget, you're not forced to install it. If you want the plugin, you're told wget is needed. Problems: #1: If you don't have wget, installing won't tell you that you need it. #2: If you don't want to use those DPIs and you don't want wget, you need to install it anyway. #3: Installing is more complicated, because you have to download and upgrade two RPMs. I don't think #1 is really an option, because it means people can install dillo via RPM and not everything will work. I'm inclined to choose #2 over #3, just because of the simplicity. If someone just wants to install Dillo, they already have to look through a list of about 10 different RPMs for the right system, and sometimes people miss the one they need. I occasionally get requests to add an RPM for a system that's already on the list. On the other hand, some people might consider wget to be unnecessary if they're not going to be using those DPIs. Anyway, has anyone got any thoughts on this issue? Kelson Vibber www.hyperborea.org

Feb. 3, 2004

[Dillo-dev]Bookmarks shortcut

by Jorge Arellano Cid

Hi, I was updating the help page for dillo, and when making a keyboard shortcuts table, just realized that Alt-B for bookmarks didn't belong anymore so I replaced it with the much more orthogonal Ctrl-B. Just visit the new help page to see. BTW, is anyone using the alternative ";" for bookmarks? I very seldom use it, but rely heavily on "." and ",". Cheers Jorge.-

Feb. 3, 2004

Re: [Dillo-dev] Re: https dpi

by Jorge Arellano Cid

Hi Madis, On Tue, 27 Jan 2004, Madis Janson wrote: > > On Mon, 3 Nov 2003, Jorge Arellano Cid wrote: > > > On Sat, 25 Oct 2003, Madis Janson wrote: > > > > > Also, there seems to be one process for one connection, which makes hard > > > to implement SSL session cache. > > > > Yes, that happens with dpi filters. The idea in this case is to > > have an http dpi that's able to handle several connections at the > > same time (like the downloads dpi). That is: a dpi server instead > > of a dpi filter. With that scheme session cache is easy to > > implement. > > > > (and BTW much easier for the developer because he can arrange > > things much more freely than when patching inside dillo). > > > > > content-type > > > > (as above). > > > > The https dpi would need to listen the HTTP stream and so has > > access to the content-type sent by the remote https server. > > > > (http://article.gmane.org/gmane.comp.web.dillo.devel/1407) > > if someone would create non-ssl dpi proxy plugin (that just makes > http requests), i will add the ssl part to it (i have working ssl proxy > code, which currently works using a patched dillo). Interesting idea! I'll start working on it after the 0.8.0 release. Cheers Jorge.- PS : Dylan knows crypt stuff. You may work together on it. PS2: He's on dillo-dev.

Feb. 3, 2004

[Dillo-dev]Looking inside the cache

by Jorge Arellano Cid

Hi there! On Mon, 26 Jan 2004, Dylan Dawkins wrote: (it took some days, I'm pushing the next release...) > Its extremely fast and has a small footprint (very important). Yes. I ask because very often, appart from the speed, people mention: stability, simple&easy UI, clean code and that it works OK on low CPU/memory systems. > For my > patch I actually only use the urls that are currently held within the > history list already. So you're trying to find an URL in the cache... > But I can see how that trying to match what's in > the history list to what the user is typing could yield some small loss > of security (if anyone is peeking over the users shoulder). I thought you were to keep an archive with the visited URLs; clearly a privacy problem, but if it only scans what's on memory, it is not much different from what we have now (stack history). > The problem > being solved, is not having to type long urls out all the time. And I > suppose the bookmark idea solves that problem, except when the number of > bookmarks becomes large enough that typing the beginning of your url, is > quicker than looking for the specific bookmark. Looking inside the cache has several interfaces in browsers: * Tabs * Cache list (stack history back/fwd) * History list (full list of the cache) * Predictive URL input * Search dialogs Every one of them have good points and some weaker ones; I assume that's why there're so many mechanisms! :) Given the nature of Dillo, having them all is not a good idea. The point is to find a few that cleanly solve the problem (i.e: enough to solve the problem, and that integrate well with the UI model). I'm not quite sure of what should it be at the moment... For instance, a long time ago we thought with Eric that having a "linear history" menu was a good idea (all the visited URLs sorted by time of visit). That's why we have history.[ch]. It should pop up with the current one highlighted and a right click would make a new popup, this time filtered by the highlighted URL's host (all the visited URLs coming from that host). An interesting idea that has been waiting for a proper implementation. It has the plus of allowing access to the whole list of visited URLs, but may start to get clumsy as the URL list grows. At this point, I believe the best interface is a search dialog: Search cache: In Url : _______ In Title : _______ [Search] [Clear] [Cancel] It can be hooked to a right click menu on the (Web) Search icon. That would also allow to add other search URLs as dictionaries, packages or whatever, configurable from dillorc. One feature of the cache search would be to return the linear history when the input camps are empty. Maybe this interface, plus tabs (or page marks; think of tabs listed in a popup menu) is all we need. > > I wouldn't mind working on the https part of the browser. My skills are > mainly with C++,C embedded coding. I have good experience with the > security > Like SSL tunnels VPN rijndael support in VPN, elliptic curve > cryptography (just a hobby). I am a computer scientist and a Linux > devotee, that started using Linux fulltime from RedHat Linux 6.0. Great. After the release, I'll be preparing the basis of the https dpi server (as requested by Madis) so you both can work on it. By now you can study the downloads server to get the idea of how it all works (of course you'll need to read the dpi docs too). After you get enogh knowledge and are confident enough, you can start working with Madis on https or I can send you a grphical download plugin that needs polishing. > I have not worked with FLTK, but it looks like a good idea. After a testing a prototype GTK2 Dillo, and also after probing the GTK2 version of XFCE, I believe the best path is to abandon GTK2. There's an interesting thread in the list. FLTK would certainly come with a lot of porting work, but I believe there will be enough developers to do it! We're waiting for Sebastian's green light on it to start. He's the main author of Dw, so he's the person that knows best what it would take to port Dw to FLTK. > I have > subscribed already. What specifically is your role in this project? Founder, mantainer, lead developer, webmaster, ... :-) Cheers Jorge.

Feb. 3, 2004

[Dillo-dev]Searching dillo-dev

by Jorge Arellano Cid

Hi, I just noticed that the old "search" link for dillo-dev stopped working so I made a new custom page to use GMANE's engine. Available from: http://www.dillo.org/MList.html specifically at: http://www.dillo.org/search-dillo-dev.html HTH Jorge.-

Feb. 2, 2004

Re: [Dillo-dev]AIX problems

by Jorge Arellano Cid

On Sun, 1 Feb 2004, Riccardo wrote: > Hello, > > since upgrading to 1.2.10 did not help, I pathed manually every file > including gtk.h by doing #undef func_data before. > > - I notice I get 'stcasecmp' implicit declaration warning. Fixed in CVS. > - the vsnprintf was already reported and shouldn't be a matter. Yes. > > at the final linking inside "src" I get errors about duplicate symbols > (.strcmp, strcmp, .pov) ?? > This time I got the WAIT_ANY error on aix too (I wonder why I didn't get > it last time!, maybe because I am using gnu-make ?) and subsituted it > with -1. Probably because you didn't use the CVS code. The CVS code is free of WAIT_ANY. Well, I made a new tarball with it... With regard to glib/gtk 1.2.10, effectively glib has no func_data inside, but gtk+ is full of it! Maybe simply undefining it in dillo (or any source) yields some obscure side-effects. You can re-compile gtk+-1.2.10 using something like this script: <q> #!/bin/bash # # Call with: find -name "*" -exec ./fix {} \; # if test -n "`echo $1 | sed 's/l$//' | grep "\.[chp]$"`"; then echo $1 mv $1 $1.BAK sed 's/$[^_]$func_data/\1func_par/g' $1.BAK > $1 rm $1.BAK fi </q> It will replace "func_data" with "func_par" all along the code. That way, you'll not need to tweak dillo or any other program with regard to func_data. How? unpack e clean gtk+-1.2.10 cd gtk+-1.2.10 copy "fix" to this directory chmod +x fix find -name "*" -exec ./fix {} \; ./configure make ... Then grab dillo-0.8.0-pre.Feb02.tar.gz from dillo.org/test/ and try it! Cheers Jorge.-

Feb. 2, 2004

Re: [Dillo-dev]solaris 2.6 works

by Peter Sinn

Hello, Am 1. February 2004 17:52 Uhr schrieb Riccardo: > with the latest configure patches to correctly link, the solaris version > of dillo finishes build and seems to work pretty as much as 0.7.3 did. yes, I can confirm that it works. I had posted prematurely, just after posting I found that by substituting WAIT_ANY with -1 and by adding -lsocket -lnsl to the compile directives everythig runs just smoothly. Thanks for the quick fix. Peter

Feb. 2, 2004

[Dillo-dev]AIX problems

by Riccardo

Hello, since upgrading to 1.2.10 did not help, I pathed manually every file including gtk.h by doing #undef func_data before. - I notice I get 'stcasecmp' implicit declaration warning. - the vsdnprintf was already reported and shouldn't be a matter. at the final linking inside "src" I get errors about duplicate symbols (.strcmp, strcmp, .pov) This time I got the WAIT_ANY error on aix too (I wonder why I didn't get it last time!, maybe because I am using gnu-make ?) and subsituted it with -1. Compile ends. As the last time dillo crashes with an illegal instruction and GDB doesn't return me a useful backtrace. I am quite clueless. Can I compile dillo with debug? -Ric

Feb. 1, 2004

Re: [Dillo-dev]user agent and OS

by Riccardo

Kelson Vibber wrote: > > On Sunday 01 February 2004 9:03 am, Riccardo wrote: > > I'd like to see dillo reporting the OS in the User-agent, this can be > > interesting for statistics (and a reason ov proudness for lesser-known > > platforms, heh). > > I suggested this sometime last year, and provided a small patch, but Jorge > eventually rejected the idea for privacy reasons. Almost every browser I know of can do this. Some have a switch for it, a rpeference option. Maybe a compile-time option. I'd like a way to do it. Of course it is a minor thing regards to display problems or portability. -R

Feb. 1, 2004

Re: [Dillo-dev]user agent and OS

by Kelson Vibber

On Sunday 01 February 2004 9:03 am, Riccardo wrote: > I'd like to see dillo reporting the OS in the User-agent, this can be > interesting for statistics (and a reason ov proudness for lesser-known > platforms, heh). I suggested this sometime last year, and provided a small patch, but Jorge eventually rejected the idea for privacy reasons. -- Kelson Vibber www.hyperborea.org

Feb. 1, 2004

Re: [Dillo-dev]AIX : illegal instruction

by Riccardo

Andreas Schweitzer wrote: > > At least check where the illegal instrucution comes from ... > the backtrace stopped there! that was the problem. > maybe that's why I kept the "patch" to myself :-) ... I used > an older pre-packaged version of GTK and was too lazy to upgrade. > > And since Ricardo told us in another mail that he isn't using > 1.2.10 either .... I removed 1.2.9 and recompiled 1.2.10 and run also "make check" before installing. I tried building from a clean 30-Jan 0.8.0 tarball and it didn't work, I still get errors in the headers. I try applying your patch manually again and see if it helps. -Ric

Feb. 1, 2004

Re: [Dillo-dev]AIX : illegal instruction

by Andreas Schweitzer

Hi, On Sun, Feb 01, 2004 at 05:04:17PM +0100, Riccardo wrote: > Andreas Schweitzer wrote: > > About the WAIT_ANY : > AIX didn't complain... the fix was for solaris. :-) ... I only grep'ed through /usr/include and did not find it ... > > > But startup fails, GDB gives me the following: > > > (gdb) bt > > > #0 0x0 in ?? () from /usr/local/build/dillo-0.8.0-pre/src/./dillo > > > > and now I'm lost ... is this all the output ? > Yes, that's all. > > Maybe I should make clean and log the build output? Maybe some compiler > warnings could be instructive. At least check where the illegal instrucution comes from ... On Sun, Feb 01, 2004 at 12:27:11PM -0300, Jorge Arellano Cid wrote: > On Sun, 1 Feb 2004, Andreas Schweitzer wrote: > > <problems about func_data and GTK in AIX ...> > AIX defines func_data in timer.h, and GTK also used it. > > Is an AIX/GTK problem and was solved in GTK+-1.2.10. > (http://www.aoindustries.com/docs/glib-1.2.10/ChangeLog) maybe that's why I kept the "patch" to myself :-) ... I used an older pre-packaged version of GTK and was too lazy to upgrade. And since Ricardo told us in another mail that he isn't using 1.2.10 either .... Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Feb. 1, 2004

[Dillo-dev]user agent and OS

by Riccardo

Hello, I'd like to see dillo reporting the OS in the User-agent, this can be interesting for statistics (and a reason ov proudness for lesser-known platforms, heh). Like netscape on my sun box reports: User-Agent: Mozilla/4.79 [en] (X11; U; SunOS 5.6 sun4u) while dillo only: User-Agent: Dillo/0.8.0-pre Since I write a small webserver with its log-analyzer I noticed this. Btw, some advertising... it is a small webserver, quite portable across unix and it weigths around 30k depending on the options and on the platform. It makes a nice match with dillo! With both you can have fun of the www on a 25Mhz computer again :) http://sourceforge.net/projects/pserv/ The matched log-analywer "p-reporter" reports dillo as a rocgnized web-browser :) -Ric

Feb. 1, 2004

[Dillo-dev]solaris 2.6 works

by Riccardo

Hello, with the latest configure patches to correctly link, the solaris version of dillo finishes build and seems to work pretty as much as 0.7.3 did. The problems I currently encounter are: - color problems. I have 256 colors. If the colors are already reserved say from Netscape or another applicaiton, images (but only those) are displayed with mangled colors, they don't get remapped to the neares color available. If the full palette is available, images are dithered as expected. - authenticaiton problem with www.blender.org to the forums. I insert my data, login.. I get a page with a meta-refresh which should me login, Dillo gives me the link, I follow it and I result not logged in. The specs for "wait any" on solaris are the following: If pid is equal to (pid_t)-1, status is requested for any child process. I think so that a cast of -1 to the correct type wouldn't hurt. Riccardo PS: I try building and isntalling glib/gtk 1.2.10 instead of the current 1.2.9 on AIX. One never knows, it could help.

Feb. 1, 2004

Re: [Dillo-dev]AIX : illegal instruction

by Riccardo

Andreas Schweitzer wrote: > > Hi, > > I followed the progress on the mailing list, but was always > too late ;-) ... > > About the WAIT_ANY : AIX 4.3.3 (and Ricardo's 4.2.X) indeed > does not define WAIT_ANY. I checked man-pages on several OS's > and neither says anything about this being standard, but all > agree that "-1" is standard, so "-1" is probably the way to go. AIX didn't complain... the fix was for solaris. Unfortunately it seems thjat I don't have the full developer manpages on AIX, so Ic ouldnt' check further. > *If* that ever wants to go into dillo, a cleaner way would be to > enclose it in "#ifdef _AIX" - but I don't know about AIX5 It should go into dillo... maybew check for AIX4 ? Is it possible? It should > > But startup fails, GDB gives me the following: > > (gdb) bt > > #0 0x0 in ?? () from /usr/local/build/dillo-0.8.0-pre/src/./dillo > > and now I'm lost ... is this all the output ? Yes, that's all. Maybe I should make clean and log the build output? Maybe some compiler warnings could be instructive. -Riccardo

Feb. 1, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Jorge Arellano Cid

On Sun, 1 Feb 2004, Riccardo wrote: > Jorge Arellano Cid wrote: > > > > > Some Solaris seem not to have it. :( > > I decided to replace WAIT_ANY with -1 as in dillo.c; commited. > > > > Please test it on aix and sparc. Use the Jan30 tarball and > > just replace WAIT_ANY with -1 in: > > > > dpi/downloads.c and > > dpid/dpid.c > Yes, I checked solaris doc and it says to use (pid_t)-1. > > Build stops howewer with: > gcc -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 > -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter > -Waggregate-return -R/usr/local/lib -L/usr/local/lib -R/usr/lib > -L/usr/lib -L/usr/local/lib -lposix4 -o dpid dpi.o dpi_service.o > dpi_socket_dir.o dpid.o dpid_common.o main.o misc_new.o -L/usr/local/lib > -lglib -lpthread > Undefined first referenced > symbol in file > socket dpid.o > accept main.o > bind dpid.o > listen dpid.o > connect dpid.o > ld: fatal: Symbol referencing errors. No output written to dpid > > > this alomst certainly means that -lsocket is not included (maybe -lnsl > too). I thought configure should take care of this? It usually does. I included a check for those. Please download: http://www.dillo.org/test/configure use it in Jan30 tarball and tell us how it goes. Cheers Jorge.- PS: Sorry Riccardo for the duplicated email, my mistake.

Feb. 1, 2004

Re: [Dillo-dev]AIX : illegal instruction

by Jorge Arellano Cid

Riccardo, Andreas: On Sun, 1 Feb 2004, Andreas Schweitzer wrote: > Hi, > > I followed the progress on the mailing list, but was always > too late ;-) ... > > About the WAIT_ANY : AIX 4.3.3 (and Ricardo's 4.2.X) indeed > does not define WAIT_ANY. I checked man-pages on several OS's > and neither says anything about this being standard, but all > agree that "-1" is standard, so "-1" is probably the way to go. That's what I put in CVS. > > > I compiled dillo 0.80 Jan-30 tarball after having applied the patches by > > Andreas (namely undefining func_data before ever gtk.h include) > > I never dug deep enough to find out if this is the right way > to solve this problem. Apparently, both AIX-internals and GTK define > this "func_data", I only remember that the AIX definition was for > something we don't need - but I don't remember the details. > > > > % grep func_data * > > browser.h:#undef func_data > > dns.h:#undef func_data > > web.h:#undef func_data > > *If* that ever wants to go into dillo, a cleaner way would be to > enclose it in "#ifdef _AIX" - but I don't know about AIX5 AIX defines func_data in timer.h, and GTK also used it. Is an AIX/GTK problem and was solved in GTK+-1.2.10. (http://www.aoindustries.com/docs/glib-1.2.10/ChangeLog) > > > The compilation ends (although I saw some wanrings about vsnprintf > > implicitly declared... > > > > But startup fails, GDB gives me the following: > > (gdb) bt > > #0 0x0 in ?? () from /usr/local/build/dillo-0.8.0-pre/src/./dillo > > and now I'm lost ... is this all the output ? Well, <q> dnl From: mlaster(a)metavillage.com (Mike Laster) dnl AIX 4.1.4.x does not have header files for snprintf/vsnprintf dnl So using the internal versions generates a load of warnings dnl during compile. </q> AFAIU it makes noise only. Cheers Jorge.-

Feb. 1, 2004

Re: [Dillo-dev]AIX : illegal instruction

by Andreas Schweitzer

Hi, I followed the progress on the mailing list, but was always too late ;-) ... About the WAIT_ANY : AIX 4.3.3 (and Ricardo's 4.2.X) indeed does not define WAIT_ANY. I checked man-pages on several OS's and neither says anything about this being standard, but all agree that "-1" is standard, so "-1" is probably the way to go. > I compiled dillo 0.80 Jan-30 tarball after having applied the patches by > Andreas (namely undefining func_data before ever gtk.h include) I never dug deep enough to find out if this is the right way to solve this problem. Apparently, both AIX-internals and GTK define this "func_data", I only remember that the AIX definition was for something we don't need - but I don't remember the details. > > % grep func_data * > browser.h:#undef func_data > dns.h:#undef func_data > web.h:#undef func_data *If* that ever wants to go into dillo, a cleaner way would be to enclose it in "#ifdef _AIX" - but I don't know about AIX5 > The compilation ends (although I saw some wanrings about vsnprintf > implicitly declared... > > But startup fails, GDB gives me the following: > (gdb) bt > #0 0x0 in ?? () from /usr/local/build/dillo-0.8.0-pre/src/./dillo and now I'm lost ... is this all the output ? Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Feb. 1, 2004

[Dillo-dev]AIX : illegal instruction

by Riccardo

Hello, I compiled dillo 0.80 Jan-30 tarball after having applied the patches by Andreas (namely undefining func_data before ever gtk.h include) % grep func_data * browser.h:#undef func_data dns.h:#undef func_data web.h:#undef func_data The compilation ends (although I saw some wanrings about vsnprintf implicitly declared... But startup fails, GDB gives me the following: (gdb) bt #0 0x0 in ?? () from /usr/local/build/dillo-0.8.0-pre/src/./dillo cheers, Riccardo

Feb. 1, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Jorge Arellano Cid

On Sat, 31 Jan 2004, Riccardo wrote: > > > > What could be the problem? > > > > A missing header! Fix is commited. > > Please test it and tell us how it works. > > > > -- > > To test, I had to use the CVS of course. I run autogen.sh and > > if gcc -DHAVE_CONFIG_H -I. -I. -I.. > -DDPIDRC_SYS='"/usr/local/etc/dpidrc"' -I/usr/local/include > -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 > -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter > -Waggregate-return -MT dpid.o -MD -MP -MF ".deps/dpid.Tpo" \ > -c -o dpid.o `test -f 'dpid.c' || echo './'`dpid.c; \ > then mv ".deps/dpid.Tpo" ".deps/dpid.Po"; \ > else rm -f ".deps/dpid.Tpo"; exit 1; \ > fi > dpid.c: In function `handle_sigchld': > dpid.c:562: error: `WAIT_ANY' undeclared (first use in this function) > dpid.c:562: error: (Each undeclared identifier is reported only once > dpid.c:562: error: for each function it appears in.) > make[2]: *** [dpid.o] Error 1 Hmmm.... > Is there still something missing in cvs? WHy is it not there? Maybe > release me a new tarball so I can test it on both aix and sparc, or tell > me how to build cleanly from CVS. > Or WAIT_ANY is not declared on solaris? hmm :-) Some Solaris seem not to have it. :( I decided to replace WAIT_ANY with -1 as in dillo.c; commited. Please test it on aix and sparc. Use the Jan30 tarball and just replace WAIT_ANY with -1 in: dpi/downloads.c and dpid/dpid.c Cheers Jorge.- PS: there's no need to CC me. I'm on dillo-dev.

Jan. 31, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Riccardo

> > What could be the problem? > > A missing header! Fix is commited. > Please test it and tell us how it works. > > -- To test, I had to use the CVS of course. I run autogen.sh and if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDPIDRC_SYS='"/usr/local/etc/dpidrc"' -I/usr/local/include -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter -Waggregate-return -MT dpid.o -MD -MP -MF ".deps/dpid.Tpo" \ -c -o dpid.o `test -f 'dpid.c' || echo './'`dpid.c; \ then mv ".deps/dpid.Tpo" ".deps/dpid.Po"; \ else rm -f ".deps/dpid.Tpo"; exit 1; \ fi dpid.c: In function `handle_sigchld': dpid.c:562: error: `WAIT_ANY' undeclared (first use in this function) dpid.c:562: error: (Each undeclared identifier is reported only once dpid.c:562: error: for each function it appears in.) make[2]: *** [dpid.o] Error 1 Is there still something missing in cvs? WHy is it not there? Maybe release me a new tarball so I can test it on both aix and sparc, or tell me how to build cleanly from CVS. Or WAIT_ANY is not declared on solaris? hmm :-) -Ric

Jan. 31, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Jorge Arellano Cid

On Sat, 31 Jan 2004, Peter Sinn wrote: > > Hi, > > first let me say that I have been using Dillo on my Sun Ultra 10 for > quite some time now and like it very much! Thanks for the comment Peter! > Am 31. January 2004 12:14 Uhr schrieb Jorge Arellano Cid: > > > There's no PF_LOCAL in the CVS tarball. Please try it. > > > > (http://www.dillo.org/test/dillo-0.8.0-pre.Jan30.tar.gz) > > > > dillo 7.3 compiles without problems on my machine, therefore I have > just tried to compile the new version. But unfortunately, with > dillo-0.8.0-pre.Jan30 I get the following compile error (gcc version > 3.3.2, SPARC/Solaris 9): > > if gcc -DHAVE_CONFIG_H -I. -I. -I.. > -DDPIDRC_SYS='"/usr/local/etc/dpidrc"' -I/usr/local/include > -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 > -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter > -Waggregate-return -MT dpid.o -MD -MP -MF ".deps/dpid.Tpo" \ > -c -o dpid.o `test -f 'dpid.c' || echo './'`dpid.c; \ > then mv -f ".deps/dpid.Tpo" ".deps/dpid.Po"; \ > else rm -f ".deps/dpid.Tpo"; exit 1; \ > fi > dpid.c: In function `handle_sigchld': > dpid.c:561: error: `WAIT_ANY' undeclared (first use in this function) > dpid.c:561: error: (Each undeclared identifier is reported only once > dpid.c:561: error: for each function it appears in.) > make[2]: *** [dpid.o] Error 1 > > > What could be the problem? A missing header! Fix is commited. Please test it and tell us how it works. -- Ah, I also fixed the handling of the <P> element for the bug-meter. It fixes the problem of wrong messages like this one: "HTML warning: line 200, unexpected closing tag: </p>. -- expected </ol>" (now this part should be release-ready) -- Thanks for the quick feedback Jorge.- PS: There's no need to CC me.

Jan. 31, 2004

Re: [Dillo-dev] Automake and dynamic linking

by robert of northworthige

In message <Pine.LNX.4.58.0401301144290.732(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > >Jorgen, >Andreas, >Riccardo, >Matti, >Bob >(portability issues here): > snip >PS2: >--- >> [Bob wrote] >> - my experience of recent cvs, compiled on the playstion2, (blackrhino >> 2.2.21 kernel), apparently shows a disconcerting feature. After a few >> minutes of scrolling up and down standard web-sites the whole system >> will hang (eg it's unpingable, and doesn't respond to any keyboard >> input), and needs a hard reset :-( >> >> Anyone else currently testing on the ps2 please (and hopefully had >> better experiences, or a fix)?? > > I don't have a PS2, but when testing on libc5, there was a >similar problem (crash after scrolling, or crash instants after >starting) when _some_ of the libraries used by the X server where >compiled reentrant and some others not. In fact I was upgrading >slk3.6's with the ones at: http://www.linuxsavvy.com/resources/ >and some links pointed to the old ones. > > Most probably these problems stem from an static errno. > > Another source can be a non reentrant gethostbyname. > > If dillo-0.7.3 work right on it, I'm puzzled. Today's cvs, run _locally_ on the ps2, looks fine so far (I _can_ induce a crash, by running remotely from _two_ machines at once; I recollect that when I got crashes a week or two ago I was running remotely from only one machine - (an old 486 running slack 4, which is libc5-based...) - but I can't reproduce that result ) Let's assume all is fixed unless I shout. Bob -- robert of northworthige

Jan. 31, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Jorge Arellano Cid

On Sat, 31 Jan 2004, Riccardo Mottola wrote: > on 1/28/04 5:58 PM, Andreas Schweitzer at > Andreas.Schweitzer(a)hs.uni-hamburg.de wrote: > > >>> > >>> and there I just found : > >>> > >>> http://aixpdslib.seas.ucla.edu/packages/gtk+.html > >> Unfortunately, aix 4.2 is quite out of date (but my original rs/6000 is > >> beginning to show its age too). > > > > I just checked. Back then on that machine I had/have : > > > > $ lslpp -l | egrep -i gtk > > freeware.gtk+.rte 1.2.8.0 COMMITTED Gimp ToolKit GUI Library > > freeware.gtk+.rte 1.2.8.0 COMMITTED Gimp ToolKit GUI Library > > > > So, I took it from one of these sites :-) > > > > Anyways, my hunch yesterday was right when I suspected a small patch > > for AIX. I have a diff for AIX lying around which is attached. > > > The fix produced a result: in fact build stops this way now: > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include > -I/usr/local/includ > e/gtk-1.2 -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 > -D_ > REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -c `test -f 'dpi.c' || > echo '. > /'`dpi.c > dpi.c: In function `Dpi_get_server_uds_name': > dpi.c:497: `PF_LOCAL' undeclared (first use in this function) > dpi.c:497: (Each undeclared identifier is reported only once > dpi.c:497: for each function it appears in.) > dpi.c: In function `a_Dpi_bye_dpid': > dpi.c:749: `PF_LOCAL' undeclared (first use in this function) > gmake[1]: *** [dpi.o] Error 1 There's no PF_LOCAL in the CVS tarball. Please try it. (http://www.dillo.org/test/dillo-0.8.0-pre.Jan30.tar.gz) Cheers Jorge.-

Jan. 31, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Riccardo Mottola

on 1/28/04 5:58 PM, Andreas Schweitzer at Andreas.Schweitzer(a)hs.uni-hamburg.de wrote: >>> >>> and there I just found : >>> >>> http://aixpdslib.seas.ucla.edu/packages/gtk+.html >> Unfortunately, aix 4.2 is quite out of date (but my original rs/6000 is >> beginning to show its age too). > > I just checked. Back then on that machine I had/have : > > $ lslpp -l | egrep -i gtk > freeware.gtk+.rte 1.2.8.0 COMMITTED Gimp ToolKit GUI Library > freeware.gtk+.rte 1.2.8.0 COMMITTED Gimp ToolKit GUI Library > > So, I took it from one of these sites :-) > > Anyways, my hunch yesterday was right when I suspected a small patch > for AIX. I have a diff for AIX lying around which is attached. > The fix produced a result: in fact build stops this way now: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/includ e/gtk-1.2 -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 -D_ REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -c `test -f 'dpi.c' || echo '. /'`dpi.c dpi.c: In function `Dpi_get_server_uds_name': dpi.c:497: `PF_LOCAL' undeclared (first use in this function) dpi.c:497: (Each undeclared identifier is reported only once dpi.c:497: for each function it appears in.) dpi.c: In function `a_Dpi_bye_dpid': dpi.c:749: `PF_LOCAL' undeclared (first use in this function) gmake[1]: *** [dpi.o] Error 1

Jan. 31, 2004

Re: [Dillo-dev] Automake and dynamic linking

by Riccardo

Jorge Arellano Cid wrote: > > Jorgen, > Andreas, > Riccardo, > Matti, > Bob > (portability issues here): > > Hi, here is a brief covering the latest portability patches now > in CVS. These are not final an certainly need testing, so lets > try to get it straight. > > Issues: libpng, pthreads, proper linking, AF_LOCAL, libc5, PS2 > I untarred and run configure, it configured to the end so it didn't stop on pthread or linpng. I didn't attempt to build since there is this GTK header problem. I try tp apply old Andreas' patch manually and check the effect. Bye

Jan. 31, 2004

Re: [Dillo-dev] Automake and dynamic linking

by Jorge Arellano Cid

Jorgen, Andreas, Riccardo, Matti, Bob (portability issues here): Hi, here is a brief covering the latest portability patches now in CVS. These are not final an certainly need testing, so lets try to get it straight. Issues: libpng, pthreads, proper linking, AF_LOCAL, libc5, PS2 libpng: ------ On Wed, 14 Jan 2004, Jorgen Viksell wrote: > Hi! > > tis 2004-01-06 klockan 16.01 skrev Jorge Arellano Cid: > > [...] > > We can't rely on libpng-config because it would break support > > for older distros (for instance slackware 3.9), and there're > > plenty of dillo users with old distros on laptops. > > Fair enough. Using Debian unstable I tend to forget about those people > stuck with non-evolving distros. > > > The current png detection routine has come a long way to be > > able to detect the library on a wide range of SW/HW combinations. > > Maybe the best approach is to try libpng-config first, and when > > not present, try the older libs. > > I made it do so. Could you please try out the fallback code, using: > PNG_CONFIG=foobar ./configure > And if it still fails could you send me the config.log file. Sorry for taking a long time to answer, I got a lot of troubles installing an old libc5 distro (Slackware 3.6) for testing. These were unrelated to the distro and not worth to detail here! ;) The simple fallback-test passed on my slk current, but the old installation payed off quickly, because it failed on it. For instance: <q> checking for libpng-config... missing checking png.h usability... yes checking png.h presence... yes checking for png.h... yes checking libpng/png.h usability... yes checking libpng/png.h presence... yes checking for libpng/png.h... yes checking for png_check_sig in -lpng... no configure: WARNING: *** No libpng found. Disabling PNG images *** </q> Fixed, added "-lm" and a "&& break" to avoid the second header test when the first is present. The version in CVS works both with the current and libc5 distros. As for the image disabling, although I don't see much use for it, I left to avoid some work at this stage. The one thing I don't like is the #ifdef stuff. Well, if it's not worth it can be removed. pthreads: -------- I added the "pthreads" (with an 's') to the search list as Andreas suggested. Riccardo: please test if this works for you. I made a tarball so you don't need to play with autoconf/automake/autogen. URL: http://www.dillo.org/test/dillo-0.8.0-pre.Jan30.tar.gz Note: there's still some work to do with this one, read below. proper linking: -------------- Now the linked libraries are ok (the problem was that dpis and dpid got all of the libraries used by dillo linked in). ...except for pthread that is till present on dpi, dpis. AF_LOCAL: -------- After studying the history of the socket library development and socket.h for linux, BSD, HURD, etc, it seems that all these are (should be) the same: PF_UNIX : old BSD name for PF_LOCAL PF_LOCAL : POSIX for AF_LOCAL PF_FILE : seldom used POSIX for AF_UNIX AF_LOCAL : somewhat old but the most compatible. AF_UNIX : oldest. Fixed this for the whole tarball. It works on both of my testing environments. Should work for everyone. libc5: ----- Now it compiles cleanly with libc5. Except for a warning on a repeated symbol between libjpeg and autoconf. --innocuous though PS2: --- > [Bob wrote] > - my experience of recent cvs, compiled on the playstion2, (blackrhino > 2.2.21 kernel), apparently shows a disconcerting feature. After a few > minutes of scrolling up and down standard web-sites the whole system > will hang (eg it's unpingable, and doesn't respond to any keyboard > input), and needs a hard reset :-( > > Anyone else currently testing on the ps2 please (and hopefully had > better experiences, or a fix)?? I don't have a PS2, but when testing on libc5, there was a similar problem (crash after scrolling, or crash instants after starting) when _some_ of the libraries used by the X server where compiled reentrant and some others not. In fact I was upgrading slk3.6's with the ones at: http://www.linuxsavvy.com/resources/ and some links pointed to the old ones. Most probably these problems stem from an static errno. Another source can be a non reentrant gethostbyname. If dillo-0.7.3 work right on it, I'm puzzled. That's it. This CVS should work on the same platforms than before and with a few more. Please test and report. Best Jorge.- PS: Those that have had problems with 0.7.3, please test this CVS version, or tarball: URL: http://www.dillo.org/test/dillo-0.8.0-pre.Jan30.tar.gz PS2: Ah there's also a fix to include "dpidc". It fixes "make dist".

Jan. 30, 2004

Re: [Dillo-dev] ASK FOR HELP:"view source" and edit data to send.

by Madis Janson

On Fri, 2 Jan 2004, FUN TOES wrote: > Some websites can't be visited by dillo.So I think of writing a patch > to view the raw data(including header) from the server and send the raw > data modified manually to the server. > > It is very easy to edit the data to send by modifying the function > Http_send_query().But I do not know how to get the > raw http data from the server.What is the function that I need read > deeply? And I do not think IO_read()is a good > selection.The function send raw data to html parse maybe > a good selection.But I am a newbie,and I have difficuty in finding the > correct function. Would you like help me find it?Appreciation for your > help. > Cache_process_io maybe? It basically gets raw network data and calls functions that will parse HTTP headers / body data. Cache_get_header/Cache_parse_header should deal with headers and iirc Cache_process_queue forwarded data to the image/html parsers...

Jan. 30, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Riccardo

Andreas Schweitzer wrote: > 1) In /usr/lib : Link libpthreads.a to libpthread.a > 2) Don't just call configure but do the following : > export LDFLAGS='-lpthreads' ; ./configure > 3) Apply one of the attached patches. If you use 0.7.3, try the > patch against configure (configure.diff), if you run CVS use > the patch against configure.in (configure.in.diff3) > > Note to all: the latter patch should be considered for general > inclusion ! > > Please test, as I have VERY limited ways of testing that. I will try the patch way since that is probably the most general way to fix dillo. I am using 0.7.3 and unfortunately the patch gets rejected (using patch -i configure.diff) I will get now cvs version and try that with the other patch. -Ric PS: and yes, I subscribed to the list, since I have to report some problems on Solaris too... I thought this is the best way, hoping in a low volume, high-profile list.

Jan. 27, 2004

Re: [Dillo-dev]Buggy HTML, the new parser and webmasters

by Kelson Vibber

>On Sun, Jan 25, 2004 at 08:53:17PM -0800, Eugenia Loli-Queru wrote: > > "Creating an HTML browser and a Web browser are two different things. The > > first one just needs to do the job right and parse HTML correctly, the > other > > one just has to be able to render web pages in any possible mean. These are > > two different beasts and targets --unfortunately." For some other commentary on the effects of buggy HTML, you might be interested in some recent postings on Surfin' Safari: http://weblogs.mozillazine.org/hyatt/archives/2004_01.html Dave Hyatt has a series of posts on how to best handle XML errors, and he talks about the difficulty of getting WebCore to handle all the broken HTML filling the web today. One of his key points: "The #1 reason that HTML pages render incorrectly in alternate browsers is because of differences in error handling and recovery." He describes his experiences trying to make Safari handle broken HTML the same way IE does (much as IE originally had to handle broken HTML the same way Netscape did). His main point is about XML error handling (specifically, if all XML browsers insist on well-formed documents from the start, no one will have to deal with the nightmare of different error-correction schemes), but he has some interesting comments on dealing with broken HTML. Kelson Vibber www.hyperborea.org

Jan. 27, 2004

Re: [Dillo-dev]Buggy HTML, the new parser and webmasters

by Thorben Thuermer

On Tue, 27 Jan 2004 14:01:14 +0100 Andreas Schweitzer <Andreas.Schweitzer(a)hs.uni-hamburg.de> wrote: > On Sat, Jan 24, 2004 at 06:36:27PM -0800, Eugenia Loli-Queru wrote: [...] > > So, the reason I close the form outside that table is because I am trying to > > go around bugs on Netscape 4 and IE. As you can see, the cell that holds the > > form has a black background color. If I close the form inside that cell, IE > > and NS4 create a new paragraph inside that cell, even if my code never asked > > for it. And that looks ugly. > [...] > > So, the "trick" that many web developers of my time use a lot (see: > > hand-written HTML), is to close the </FORM> outside of tables or places > > where it screws up the design. It is a well-known trick, and so your new > > parser is going to meet it a number of times in the future. I suggest you http://www.cs.tut.fi/~jkorpela/forms/extraspace.html (maybe forward this?) i had that problem myself... personally i went for the CSS solution, as dillo (non-css capable) doesn't have that "feature" anyway. when playing with the more more less valid options, i even found some combinations where *mozilla* would NOT display the form AT ALL, while IE still did. Greetings, Thorbem Thuermer

Jan. 27, 2004

RE: [Dillo-dev] worried about dillo (cathedral and bazaar)

by Indan Zupancic

> A few months ago a few individual started submitting patches against the > advices of the core developers. The features were sometimes interesting, > sometimes not. The code style did not integrate well the rest of Dillo's > code. (not to mention the form in which the patches were presented). Oh that's really great, to hear such things now instead of when such feedback was wanted. 1. I had never any advice from any of the core developers, I was simply ignored. Maybe I should have taken the hint sooner, sorry for that. 2. As I said, I had no feedback, so really don't know what you thought about the code style. Perhaps I didn't make use of the wonderful CCC nightmare construction, so you're right, my code style didn't integrate well with the rest of at least Dillo's IO code. 3. Form of patches? I used the recommended diff options. Other than that, I could have split up the patches into smaller ones, but no one asked for that so why even bother. > The maintainers of Dillo decided these contributions were not good for > Dillo, for many reasons. While you might disagree, similar decisions were > made during the development of Dillo, and the result is the great browser we > have now. We have the focus and we have a plan. Pardon me, but the main problem is that you don't communicate, at least not with me and many other patch makers (Kiyo, anyone? See mailinglist archive for more examples). I have no problems with rejections, but I can tell you that silent rejections can be rather frustrating. People spend time writing a patch for Dillo, they try to improve it, and you in return simply ignore them. Rejecting a patch is unfortunately something you must do most of the times, but at least explain what your problem is with it. Don't ignore it and then afterwards say what you just said please. Dillo has some really ugly code in it, but if you say that loud and clear you will be insulted and spit at. If you try to clean it up a bit you'd be ignored. You may have a focus and a plan, but oh so nice of you to share it with all of us. Last time I looked on the site one of the main focus was to get money. > Not to take control to see the one feature they like be included. Https is a feature that not only I like to have, but is an essential feature for a browser. I never tried to push it, if you thought so then you understood it wrong. I only tried to convince why my way of implementing it is better than some other ways, but that discussion died an early death by lack of any feedback. I also didn't try to push the "united Dillo" patch through someone's throat, it was discussed on the mailinglist and the conclusion was that it may be a useful feature, but that it shouldn't be the default behaviour. I don't know what one feature the IO.c cleanup patch tried to push, I can only imagine. > I understand how a Linus Torvald saying no to a patch for Linux might induce > more respect to young coders than for a smaller project like Dillo. But you > should learn to repect Jorge, Sebatian, Livio, and the others contributors > (and not only the so-called "core developer"). These people put a lot of > their energy and sweat into Dillo over the years, because that's what it > takes to make a successful project. As I said above, you don't even bother saying no. And I do respect people, but I can't help it if criticism on _code_ is takes as a personal attack. I honestly never expected that, must be my naivete. You are the ones that are insulting people, stabbing them in their back when they turn away, with the official announcement and emails like this. I can only speak for myself, but from my point of view I was totally ignored, and when I gave up and went away, I get one insult after to other thrown after me. Hidden in general speak so that you can still claim to be respectful, with your mud dirty hands hidden behind your back. > Dillo is an Open Source project, and anybody whom's not happy with the > development policy could start his own project with it. And he'll be > welcome. But nobody did so far, and I take it as a confirmation that one > needs more than being vocal in mailing list to maintain a project like > Dillo. It takes dedication and talent. This is really a low comment. If all went as you make it seem then you could perhaps say this, but you chronically ignore any outside efforts. I was encouraged by the text on the website to contribute to Dillo. Personally I missed https, so I wrote a https patch. I first wanted to make a https dpi, but that turned out to be rather hard, at least it couldn't be done very elegantly with a dpi, so I added it to Dillo. That got me rolling and I also started doing some more, like cleaning up io.c. I really start repeating myself, but as I said, I had no feedback at all, so in the end gave up. Now you make it seem like I'm not happy with the development policy, but how must I know what it is? If I follow the information on Dillo's website then I did follow Dillo's development policy. I was willing to spend a lot of time in Dillo, also in the future, I didn't gave up so soon as most other patch makers, so I don't see how I was lacking in dedication. Now you say that because I'm not happy with a for me unknown policy, I could have started my own project, while all I wanted was to improve Dillo... And because I didn't that suddenly means that you are dedicated and have talent? May I also remind you that the mailinglist is the Dillo developer mailinglist, so actually the only communication way for outside developers? And you also seem to imply that I'm only vocal on the mailinglist, ignoring the fact that most of those mails are patch or Dillo code related. Only way I'm too vocal is that I write damn long emails somehow, but I really can't help that. > "The main job of a maintainer is to say No", said Linus Torvald. That's > what happened. Nothing more: people were not happy to see their patch > rejected and they tried to push back. Dillo's still active, and not less > than it was before: do not confuse bubbling in the mailing list with > activity. Out-of-control patch submissions is not equivalent to improvement. That is simply a lie. That is NOT what happened. What happened is that you ignored all patches and almost all our emails. And then suddenly out of thin air post a very aggressive insulting official announcement from the "core developers". If you disagree then you live in another universe or are talking about other people than Frank and me. If that bubbling on the mailinglist had gotten more attention, Dillo could by now have utf-8, https, ftp, frames, tabs, I18N and a lot other things that I can't think of right now, and probably even more because less people would be scared away. Nice to call it "out-of-control" patch submission, perhaps you should control it? Maybe giving a short reply to such patches like "no, we don't like this, don't submit such stupid patches" would cure the problem? Maybe a healthy outside curiosity and patch submission is indeed evil, but somehow I doubt that... Also to compare how Dillo developers say no (by ignoring it) with Linus Torvals' way of saying no (actually saying "no" with explanation) is a bit lame. > The people who made Dillo are still there, and new contributors are > joining. Those whom wanted their features included so badly prefered to > leave rather than change their attitude and work the issues. Makes me really wonder who here really has an attitude problem. First you more or less demand that we leave, and now you say that we prefer to leave instead of doing something about our attitude, while your attitude is the one that should change. Good start would be to grow up and handle criticism on code sanely instead of handling it as personal attacks, bad attitude and what else. In the time that I followed the mailinglist there was no one that tried to push his code into Dillo, all they did was implement features they would like to have and shared it with the rest. > I guess we're back to normal: a sane and nice working environment. Please > keep contributing. You made it very clear that you in reality don't appreciate real contributions, good luck with keeping up the facade. But everyone can read the mailinglist archive and see for their self how it really went. Unfortunately most won't and will trust what you say, lucky you. I may be wrong and maybe there is active development going on, but if so, it all happens in the background, hidden from us. All we see is a rather silent mailinglist and very little CVS activity for quite a while now. I really hope that the "core developers" will see the light once, but I don't have too much hope. I'm aware that it's impossible to reason with you, so I won't even try. That is also why I ignored the announcement, it was just a flamebait. Good luck, also with Dillo, Indan

Jan. 27, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Jorge Arellano Cid

On Tue, 27 Jan 2004, Andreas Schweitzer wrote: > Hi, > > Since I'm still not sure if you are subscribed I send it to you > and the list :-) > > > configure reports: > > checking target system type... rs6000-ibm-aix4.2.1.0 > > > > as far the system concerns. > > > > The error during configure is: > > checking whether threads work with -pthread... no. Now we will try some > > libraries. > > checking for library containing pthread_create... no > > configure: WARNING: *** No pthreads found. *** > > I have a slightly later version of the AIX native threads library. > And as you hinted in your previous mail, the name of the library > is slightly different. (libpthread.a vs. libpthreads.a). However, > on *my* system, both libraries exist as a link and point to a third > file. > > > gcc -v yields: > > Reading specs from > > /usr/local/lib/gcc-lib/rs6000-ibm-aix4.2.1.0/2.95.3/specs > > gcc version 2.95.3 20010315 (release) > > Too bad that your version of gcc does not know the -pthread > option and react accordingly. > At least for relatively recent versions, gcc can be configured > to be called with -pthread and do the OS-correct thing. > > Anyways, so far this doesn't really help you :-). Here are possible > solutions : > > 1) In /usr/lib : Link libpthreads.a to libpthread.a > 2) Don't just call configure but do the following : > export LDFLAGS='-lpthreads' ; ./configure > 3) Apply one of the attached patches. If you use 0.7.3, try the > patch against configure (configure.diff), if you run CVS use > the patch against configure.in (configure.in.diff3) > > Note to all: the latter patch should be considered for general > inclusion ! > > Please test, as I have VERY limited ways of testing that. Excellent Andreas! Please let me know when Riccardo confirms the patch to work on his system to include it in CVS. Cheers Jorge.-

Jan. 27, 2004

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3

by Andreas Schweitzer

Hi, Since I'm still not sure if you are subscribed I send it to you and the list :-) > configure reports: > checking target system type... rs6000-ibm-aix4.2.1.0 > > as far the system concerns. > > The error during configure is: > checking whether threads work with -pthread... no. Now we will try some > libraries. > checking for library containing pthread_create... no > configure: WARNING: *** No pthreads found. *** I have a slightly later version of the AIX native threads library. And as you hinted in your previous mail, the name of the library is slightly different. (libpthread.a vs. libpthreads.a). However, on *my* system, both libraries exist as a link and point to a third file. > gcc -v yields: > Reading specs from > /usr/local/lib/gcc-lib/rs6000-ibm-aix4.2.1.0/2.95.3/specs > gcc version 2.95.3 20010315 (release) Too bad that your version of gcc does not know the -pthread option and react accordingly. At least for relatively recent versions, gcc can be configured to be called with -pthread and do the OS-correct thing. Anyways, so far this doesn't really help you :-). Here are possible solutions : 1) In /usr/lib : Link libpthreads.a to libpthread.a 2) Don't just call configure but do the following : export LDFLAGS='-lpthreads' ; ./configure 3) Apply one of the attached patches. If you use 0.7.3, try the patch against configure (configure.diff), if you run CVS use the patch against configure.in (configure.in.diff3) Note to all: the latter patch should be considered for general inclusion ! Please test, as I have VERY limited ways of testing that. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Jan. 27, 2004

[Dillo-dev]Buggy HTML, the new parser and webmasters

by Andreas Schweitzer

Hi all, First : my apologees for a rather large mail ! Now, that the bug counter is in dillo, and with Madis' last post, it's a good coincidence that I just tried to convince webmasters of 3 sites I usually visit to fix their HTML. From 2 I haven't heard a thing (and they are not even THAT huge), but from www.osnews.com I got a reply very fast - and it turned out to be an extremely interesting conversation. I asked her for permission to forward it to the list, and here it goes. I sorted it chronolically, with some comments of mine in between. I omitted my first mail - it was just the HTML warnings of the new parser along with a kind request to fix the page. WARNING, BIG REMINDER : Don't flame her - it's not about this individual site, it's about general practice and the general attitude towards standards ... After all, the e-mail conversation started in privat and she didn't have in mind that a lot of people would read it. And I think she deserves credit for taking her time and lay out her arguments and explaining everything in a very friendly manner. On Sat, Jan 24, 2004 at 06:36:27PM -0800, Eugenia Loli-Queru wrote: > Hello Andreas, > thanks for the heads up. > I looked at the error messages, and I know what is wrong. Please note that > all forms and tables ARE closing in the code, it is just that your parser is > not realizing it. > You see, I start the form inside a table's cell, but I close the form > outside the table. This is not 100% valid code, but it is like that for a > reason. This is causing your parser to spit all these errors (all the errors > below the form error are just a side effect of the first error). > So, the reason I close the form outside that table is because I am trying to > go around bugs on Netscape 4 and IE. As you can see, the cell that holds the > form has a black background color. If I close the form inside that cell, IE > and NS4 create a new paragraph inside that cell, even if my code never asked > for it. And that looks ugly. Up to here, you could argue a lot about how to design a web page, to not wanting to dictate how the page looks and leave it to the browser, to us CSS and whatnot. With enough arguing one could even convince this very author to change (not likely though, see below). BUT : the interesting part comes now : > So, the "trick" that many web developers of my time use a lot (see: > hand-written HTML), is to close the </FORM> outside of tables or places > where it screws up the design. It is a well-known trick, and so your new > parser is going to meet it a number of times in the future. I suggest you The above is frightening .... > fix your parser to understand "non-normal" code like that, and realize that > the form does close as expected. Of course, for us that's not fixing but breaking ;-) .... Here is now my reply (rather long, and you will know the arguments if you follow the lamiling list) : > Hi Eugenia, > > Thanks for the reply and explanation. > First of all : I am not a core developer of that browser - just > a steady user and occasional contributor. > > However, if this mail came from one of the developers or if I told > them to follow your advice, you would either be ignored or flamed ;-) ... > I will try to do neither. So please do keep in mind that my response > is meant as a friendly food for thought or possibly some constructive > criticism. > > Discussions about fixing broken HTML do come up on the mailing list > from time to time. And the consent is to just not do it - for a number > of reasons (I probably will forget some). > - what good are standards if nobody conforms to them, and instead an > own (not very strict !) psuedo-standard develops ? > - It's not a browser's job to guess what the author wanted to have displayed. > - It costs man-power and CPU cycles to detect and fix broken HTML. > We prefer to spend the man-power on developing something useful instead > of broekn HTML-detection code. And we prefer to give the CPU cycles > to the user (BTW, dillo is the snappiest grafic browser I know - maybe Links2) > > All right, but we already detect the problem of your page, you may say :-) .. > and indeed, the *old* parser was closing out of order. In fact, I could > configure dillo to still use the old parser and your page will look great. > BUT : then other pages break :-( - they have buggy HTML, too. And there, > closing tags with the new method is better then with the old method. > So, in chosing which parser to use, the default is the standards complying > method of interpreting HTML (also, the old parser was buggy and not quite > right). Oh - and if we care about the web sites we also tell/told the > authors if these other pages that they have buggy code ! > Now, why then are Mozilla or the other browsers displaying all correctly ? > Probably because they did spend man-power and CPU-cycles to guess what the > author wanted. > I had to smile when you wrote, "Fix your parser to understand non-normal HTML", > because I thought, "That's not fixing it, that's breaking it". > > When I design web pages, I usually make them pass (if possible) > validator.w3.org and if they look ugly in ancient - and buggy ! - browsers, > bad luck ! I realize, my pages are nothing professional like your site, > but still, is it worth to support buggy broswers ? How many visitors > are actually using Netscape 4 ? Probably more than dillo, but the comparison > should be non-buggy vs. buggy browsers. About IE - are all versions > of IE bahving like this ? Then my argument would be, why support MS's > interpretation of standards ? (and outside of HTML you probably will > agrre ;-) ... after all, don't we all know lots of alternatives and fight > for them ?) You as a professional web site probably do have to support > buggy broswers, but the question still may be asked. > > Finally, some links to archived previous discussions : > http://news.gmane.org/group/gmane.comp.web.dillo.devel/thread=1324/force_lo… > (if you don't want to read all of it, read at least Eric Gaudet's posts) > And here is the explanation of the new parser : > http://article.gmane.org/gmane.comp.web.dillo.devel/1434 > > By now, you know that the other problematic site was slashdot ;-) ... > (among others !) which displays ok with the current parser - but also is > buggy HTML - and they know it ! > > And before I forget : Yes, I saw a lot of pages that look quite ugly > with the strict interpretation. And I also only tell the webmasters > of pages for which I care :-) > > And as a really last word : the new parser may indeed have room for > improvement, and some more closing may indeed be possible as a compromise, > BUT, as I said, I'm not a core developer. > > As I said in the beginning, this was meant as food for thought, not flaming. > If you should decide to change HTML after all, that would be fantastic. If > not, hopefully I at least did explain myself well. > > Cheers > Andreas And here is her 2nd answer: > Thank you for the email Andreas, > however, I must say that the code in that form won't change. IE has more > than 70,000 viewers daily on osnews, and Dillo has about 20. So, as you can > understand, being compatible with the broken IE is more important to us, > even if that means that we have to not be validated. In fact, not being > validated, it is a given for big sites, because in order to give a > specific/certain look, you have to do tricks like the one I described to you > in order to render the same on all big browsers. Now you could, of course, go and say "screw this site" .... but the following is at least ineresting food for thought. I don't fully agree, but I can understand the point of view. > Also, please put in mind: my husband is in the browser business. He is a web > browser developer for OpenWave.com among his team. They don't have the > specific problem of out-of-order-tag-closing because they know that many > sites are like that, so they have to go around this problem, OR they won't > be able to sell their browser to anyone. > > This is a market. Even for the free Dillo. Dillo's job is not create the > most "correct" parser in the world, but to render most sites in the world. > If the first was true, then Dillo is nothing but an "Amaya", a test, a proof > of concept. But if the second is true, then Dillo is really a usable by > people browser. > > So, depends what its developers want. If they want a proof of concept, no > problem with me, osnews and most other sites won't work. If they want a > browser that works for most people, they need to sit down and go around > buggy HTML (created by either amateur developers or from developers that > they had to go around bugs). For example, IE even goes around this bug <a/> > and understands that the developer wanted to write </a> instead. Big > browsers do such error checking and go around buggy HTML, because it is the > only way they can be widely used. In my case of course, it was me that I had > to go around their bugs. > > So, it all depends what the Dillo people want. It is not what I, or you, > want, but what their real targets are: proof of concept project or a real > USABLE browser. > > If that was me, it would have being the second. And it ain't my fault that > IE has these bugs that I have to go around, it is my job to make sure my > page renders well for most of my readers. :) > > Rgds, > Eugenia > > --- > Editor in Chief > http://www.OSNews.com When I asked her for permission to forward her mails to the list she added another intersting quote : On Sun, Jan 25, 2004 at 08:53:17PM -0800, Eugenia Loli-Queru wrote: > You can go ahead and quote some of the stuff I said. > BTW, I discussed the matter with my husband (who as I said is in the browser > business) and he told me: > > "Creating an HTML browser and a Web browser are two different things. The > first one just needs to do the job right and parse HTML correctly, the other > one just has to be able to render web pages in any possible mean. These are > two different beasts and targets --unfortunately." > > I am afraid this is the reality of any product though, not just browsers... > Reality market... :( > > Eugenia > Bottom line : it may be possible to convince individual sites to fix their HTML, but what about really big sites that use these ... err ... "workarounds" ? Do they really care how a little browser interprets their HTML ? They care if HTML looks good in IE - reality sucks. It's extremely frustrating. And even more so, when I have to look at garbeled pages ;-) .... The situation may improve over time when more and more sites use CSS and don't have to rely on such dirty formating tricks - but then again, how many bugs has IE there, that authors want/will work around ? And to repeat my reminder : Don't flame her - it's not about this individual site, it's about general practice and the general attitude towards standards ... And again I think she deserves credit for taking her time and lay out her arguments and explaining everything in a very friendly manner. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Jan. 27, 2004

RE: [Dillo-dev] worried about dillo (cathedral and bazaar)

by Eric GAUDET

-- En reponse de "[Dillo-dev] worried about dillo (cathedral and bazaar)" de linux seaq, le 26-Jan-2004 : ... > I recently re-read the cathedral and bazar paper, and thought to my > self that dillo was heading in another direction. It seems to me that > there's no intention to receive help from others, or get into account > other's contributions. I believed that the main force behind a project > weren't its main developers but its users and contributors. That mix > made projects grow and grow. And dillo rejected that "magical" force. > > I'm just writing these thoughts, because as i said, i'm worried about > dillo. ... I wanted to react to that now the dust has settled. Dillo is back to normal. Even an (arguably) small project like Dillo takes a lot of time and energy to maintain, to develop and to get right. A few months ago a few individual started submitting patches against the advices of the core developers. The features were sometimes interesting, sometimes not. The code style did not integrate well the rest of Dillo's code. (not to mention the form in which the patches were presented). The maintainers of Dillo decided these contributions were not good for Dillo, for many reasons. While you might disagree, similar decisions were made during the development of Dillo, and the result is the great browser we have now. We have the focus and we have a plan. Of course Dillo is not finished, and your contributions are still welcome. Countless contributions have been made since dillo was started, and the mailing list has always been courteous and people helpful. Dillo is that good now not only thanks to the core developers, but also to many contributors helping with the spirit of being part of a group. Not to take control to see the one feature they like be included. I understand how a Linus Torvald saying no to a patch for Linux might induce more respect to young coders than for a smaller project like Dillo. But you should learn to repect Jorge, Sebatian, Livio, and the others contributors (and not only the so-called "core developer"). These people put a lot of their energy and sweat into Dillo over the years, because that's what it takes to make a successful project. Dillo is an Open Source project, and anybody whom's not happy with the development policy could start his own project with it. And he'll be welcome. But nobody did so far, and I take it as a confirmation that one needs more than being vocal in mailing list to maintain a project like Dillo. It takes dedication and talent. "The main job of a maintainer is to say No", said Linus Torvald. That's what happened. Nothing more: people were not happy to see their patch rejected and they tried to push back. Dillo's still active, and not less than it was before: do not confuse bubbling in the mailing list with activity. Out-of-control patch submissions is not equivalent to improvement. The people who made Dillo are still there, and new contributors are joining. Those whom wanted their features included so badly prefered to leave rather than change their attitude and work the issues. I guess we're back to normal: a sane and nice working environment. Please keep contributing. Best, Eric PS: even if you're not a coder you can contribute, by doing bug reports for instance.

Jan. 27, 2004

Re: [Dillo-dev] Re: https dpi

by Madis Janson

On Mon, 3 Nov 2003, Jorge Arellano Cid wrote: > On Sat, 25 Oct 2003, Madis Janson wrote: > > > Also, there seems to be one process for one connection, which makes hard > > to implement SSL session cache. > > Yes, that happens with dpi filters. The idea in this case is to > have an http dpi that's able to handle several connections at the > same time (like the downloads dpi). That is: a dpi server instead > of a dpi filter. With that scheme session cache is easy to > implement. > > (and BTW much easier for the developer because he can arrange > things much more freely than when patching inside dillo). > > > content-type > > (as above). > > The https dpi would need to listen the HTTP stream and so has > access to the content-type sent by the remote https server. > (http://article.gmane.org/gmane.comp.web.dillo.devel/1407) if someone would create non-ssl dpi proxy plugin (that just makes http requests), i will add the ssl part to it (i have working ssl proxy code, which currently works using a patched dillo).

Jan. 27, 2004

Re: [Dillo-dev] small politically incorrect html parser patch

by Madis Janson

On Tue, 27 Jan 2004, Madis Janson wrote: > > when you want to use dillo for browsing instead of html test tool, then > this little patch is useful for many stupid webs, which randomly close > or not close font tags whenever happens and whereever happens... > sorry for spam, but in the mean time i (re)found better one... diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in dillo-tab/src/html.c dillo/src/html.c --- dillo-tab/src/html.c 2004-01-25 04:37:21.000000000 +0200 +++ dillo/src/html.c 2004-01-27 04:27:18.000000000 +0200 @@ -1176,7 +1183,8 @@ static void Html_tag_cond_cleanup(DilloH while (stack_idx && strcmp(Html_tags_get_name(html->CurrTagIdx), html->stack[stack_idx].tag) && - (old_mode || + ((old_mode && + !Html_match_tag(html->stack[stack_idx].tag, "table>", 6)) || Html_tags_get_endtag(html->stack[stack_idx].tag_idx) == 'O')){ --stack_idx; e_pop = 1; and to the dillorc file: use_old_parser=YES only note: when you use it, don't whine to list that it renders something incorrectly - look the output with use_old_parser=NO and you'll probably discover why...

Jan. 27, 2004

small politically incorrect html parser patch

by Madis Janson

when you want to use dillo for browsing instead of html test tool, then this little patch is useful for many stupid webs, which randomly close or not close font tags whenever happens and whereever happens... diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in dillo-tab/src/html.c dillo/src/html.c --- dillo-tab/src/html.c 2004-01-25 04:37:21.000000000 +0200 +++ dillo/src/html.c 2004-01-27 04:27:18.000000000 +0200 @@ -4280,7 +4372,7 @@ static const TagInfo Tags[] = { {"dt", 'O', Html_tag_open_dt, Html_tag_close_par}, {"em", 'R', Html_tag_open_em, Html_tag_close_default}, /* fieldset */ - {"font", 'R', Html_tag_open_font, Html_tag_close_default}, + {"font", 'O', Html_tag_open_font, Html_tag_close_default}, {"form", 'R', Html_tag_open_form, Html_tag_close_form}, {"frame", 'F', Html_tag_open_frame, Html_tag_close_nop}, {"frameset", 'R', Html_tag_open_frameset, Html_tag_close_default}, It makes a bit less likely, that the font tags screw up every other one (like tables and forms)...

Jan. 27, 2004