- Dillo-dev - lists.mailman3.com

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