February 2004 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]CVS password

by Kelson Vibber

At 01:00 PM 2/24/2004, Jeremy Henty wrote: >I just tried to download from CVS as per the instructions on your CVS >page and I'm getting kicked out. I have tried guessing passwords (my >email, "guest", "anonymous") but nothing works. What am I doing >wrong? (I am running CVS 1.11.11 on Linux 2.4.25 .) Just hit enter. Kelson Vibber www.hyperborea.org

Feb. 24, 2004

[Dillo-dev]CVS password

by Jeremy Henty

Hello people, I just tried to download from CVS as per the instructions on your CVS page and I'm getting kicked out. I have tried guessing passwords (my email, "guest", "anonymous") but nothing works. What am I doing wrong? (I am running CVS 1.11.11 on Linux 2.4.25 .) $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo login Logging in to :pserver:anonymous@auriga.wearlab.de:2401/sfhome/cvs/dillo CVS password: cvs login: authorization failed: server auriga.wearlab.de rejected access to /sfhome/cvs/dillo for user anonymous Cheers, Jeremy

Feb. 24, 2004

[Dillo-dev]Re: Upcoming review.

by Jorge Arellano Cid

[list: this was originally a personal answer to Gavin, but as it has general interest information I'm CC to dillo-dev. It's about a browser comparison article. ] Gavin, > [...] > Thanks, I saw a few of these. I will check out the wording etc. Mine might > not be so in depth, more of a general features thing. But there will be > figures ie load times etc. which I am sure yours will win. :) > Know of any monster sites, that would be a good benchmark for the browsers. I > have ADSL, so banwidth shouldn't be an issue. There're some interesting tests to be done. Which one you choose depends on the time you have, and on what you want to test for. For instance, IMHO, the common "web experience" has four important factors: * Network wait time * Rendering wait time * Time to start seeing content - streamed rendering * Site usability These are key factors; for instance the same site may be unusable depending on whether you're on a dialup or broad band. The same is true for rendering time (influenced by CPU power and available memory); you may end going to some site only when you're sitting at a powerful workstation. The time to start seeing content is also important. If it takes too long, it may exceed the user's patience (there're studies about this). For instance, if a browser needs the whole table to start rendering, some table-based sites will be exceedingly annoying to visit (unless your band-width can mitigate this). The site usability is another key factor. For instance if it's designed for a certain browser, it may be impossible to use with another. Now, getting back to the test suggestions you asked, these points can be isolated. * Network wait time: Get to a site with multiple images, ideally with some coming from other sites. I'm sure you will find a better example for an english speaking audience, but this link illustrates the idea: http://www.lun.com/_portada/contenido.asp * Rendering wait time Very simple, load a semi complex page (like slashdot with comments --a 500KB one), or a large one (as the mysql manual -- I have one which is more than two Megabytes long). Press back, the forward. (you can have some coffee :) * Time to start seeing content - streamed rendering Get to a table-based semi complex page (300Kb-600Kb) and measure the time between asking for the URL and when you can start reading. * Site usability Well, this depends on whether the page respects standards, how broken the site implementation is, the browser's support for the technologies involved, user preferences (javascript may be disabled, same for cookies, a JVM may not be present, same for flash, etc). -- Now that's for having some numbers to show inside a table for people with above the average knowledge about browsers :-) (very interesting, but not massive). Simple usability experience can be explained to less technical people: For instance, take dillo, and dig for something using google. You'll find that the time you use to make different queries and to check for alternative links until you find what you look for is better than with almost anything you've used before. The same is true for browsing local documentation (all of those html files under the /usr/doc or /usr/share/doc directories). This happens because the combined rendering speed and low download time (a filesystem) let you move very quickly, back and forward, make text searches inside the pages, go to another link, saving you lots of time. Going with dillo to any web site is different, if it respects standards (ans so renders OK) its great, but if not, you'll have to resort to a bigger browser. The other important points to consider is to test with different band widths and CPU power. You'll barely notice how fast dillo is on a 2.2 Ghz machine, and if you only test on broad band you'll never know that it's possible to have a good browsing experience with a simple dialup. That's it. Cheers Jorge.-

Feb. 24, 2004

Re: [Dillo-dev]Frame support in CVS

by Kelson Vibber

On Saturday 21 February 2004 5:19 am, Andreas Kemnade wrote: > I have tried to update Frank's patch. It is not well tested or cleaned > up yet but I simply need to take a deep breath. Thanks! I tried to do that a week or so ago, but didn't get far enough for it to be useful. The patch you posted works so far here (minus obvious things like the incomplete splash page). I've posted some test RPMs in the usual spot, if anyone's interested. > The patch has one big problem. It is too big. Not that it bloats dillo, > but it is hard to review such a big patch. Perhaps it can be split up > and then be committed piece by piece. Has anyone ideas how to split it? > Perhaps in the DilloDoc/BrowserWindow separation, the kbnav thing and > frame support? Agreed. My suggestion would be to pare it down to just what's needed for frames and tabs. Rip out the kbnav changes, the splash screen changes, and everything else. Once that's done, maybe separate the pieces further just to make the pieces easier to review. Maybe three chunks: the doc/window split, frames support, and tabs support. > So what's the way to get frames into cvs? I suspect that the smaller and easier-to-review the patch is, the better chance it'll have of getting accepted. (But I'm just an interested end-user and packager, not a core developer, so what do I know?) > I would not like to see Frank's effort lost. Neither would I! -- Kelson Vibber www.hyperborea.org

Feb. 23, 2004

Re: [Dillo-dev]Italian help translation

by Lupino

Jorge Arellano Cid wrote: > > Hi, list! > > I'm a new user of Dillo, and I found it GREAT! It's handy at > > home, my PII-400 likes it; at the university is EVEN BETTER (we > > have PI-133, so you can imagine how sluggish is netscape..). > > Yes I can! > > Thanks for the encouraging. > > Would you mind telling us more about the lab with PI-133 you're > deploying dillo at? It's a lab in which they install Windows in good computers, and Linux is installed only in OLD machines, namely all PI-133. So Linux is used only by a few people, including me (it's entertaining to round up a good and fast system with a PI-133, especially when you don't have root privileges ;) So I use wmaker/dillo, I have a 20MB home, but I use /tmp to compile my programs, and it works because I ./configure --prefix=/home/../me all the programs/libs. Thanks for your interest and your efforts. :) > > I'm writing to ask if I can translate Dillo help in Italian: is > > there someone else that is translating in italian? If there > > isn't, which files should I translate, and where should I send them? > > Get: > > http://www.dillo.org/dillo-help.html.in > > and send me the translated version. I'm going to download it! I'll send it translated as soon as I have time to do it (in this period I have exams...). -- [ Andrea Spadaccini a.k.a. Lupino / Lupin85 - from Catania ] [ MAIL: lupin85(at)email.it - ICQ#: 91528290 - Linux 2.6.3 ] [ Linux Registered User #313388 - Powered by Slackware 9.1 ]

Feb. 22, 2004

Re: [Dillo-dev]0.8.0 issue

by Jorge Arellano Cid

On Sat, 14 Feb 2004, Johannes Hofmann wrote: > Some more info on the BSD dpid problem: > Actually, there is no need for any changes in the dillo sources. The problem > comes from dpid beeing linked with the "-pthread" flag, which has strange > consequences on the inherited file descriptors. If "-pthread" is used, one > cannot close the inherited file descriptors anymore (one gets EBADF). > I don't know, if this is a bug or a feature of the BSD thread implementation. > > To avoid the problem, one can simple link dpid manually without the > "-pthread" flag and everything works fine, at least for me. Very interesting. AFAIU gcc has a way to set its behaviour with respect to the -pthread flag; that way it can be properly set for each OS. Now, in my experience BSD developers are very competent with regard to technical issues, so if it was done on purpose there may be good reasons behind. If that's the case (and not a misconfigured gcc), we can add a check in our configure.in. Cheers Jorge.-

Feb. 22, 2004

Re: [Dillo-dev]Italian help translation

by Jorge Arellano Cid

On Thu, 12 Feb 2004, Andrea Spadaccini wrote: > Hi, list! > I'm a new user of Dillo, and I found it GREAT! It's handy at > home, my PII-400 likes it; at the university is EVEN BETTER (we > have PI-133, so you can imagine how sluggish is netscape..). Yes I can! Thanks for the encouraging. Would you mind telling us more about the lab with PI-133 you're deploying dillo at? > > I'm writing to ask if I can translate Dillo help in Italian: is > there someone else that is translating in italian? If there > isn't, which files should I translate, and where should I send them? Get: http://www.dillo.org/dillo-help.html.in and send me the translated version. > Thanks for you great work! :-) Cheers Jorge.-

Feb. 22, 2004

Re: [Dillo-dev]progress on AIX?

by Jorge Arellano Cid

On Sat, 14 Feb 2004, Riccardo wrote: > Hello, > > I posted the buildlog I got on AIX... did someone had a look at it to > see if there are some warnings or errors that could explain the > brokeness of dillo on aix? Of course the right way to fix the socklen_t issue is to have: TYPE_SOCKLEN_T in configure.in, or to define it like this: AC_DEFUN([TYPE_SOCKLEN_T], [AC_CACHE_CHECK([for socklen_t], ac_cv_type_socklen_t, [ AC_TRY_COMPILE( [#include <sys/types.h> #include <sys/socket.h>], [socklen_t len = 42; return 0;], ac_cv_type_socklen_t=yes, ac_cv_type_socklen_t=no) ]) if test $ac_cv_type_socklen_t != yes; then AC_DEFINE(socklen_t, int) fi ]) I just want to know it it solves the problem before changing the configure script. Cheers Jorge.-

Feb. 22, 2004

Re: [Dillo-dev]progress on AIX?

by Jorge Arellano Cid

On Sat, 14 Feb 2004, Riccardo wrote: > Hello, > > I posted the buildlog I got on AIX... did someone had a look at it to > see if there are some warnings or errors that could explain the > brokeness of dillo on aix? Yes I did. The only thing capable of producing an illegal instruction I can think of by reading the gcc compile log is: <q> main.c:298: warning: passing arg 3 of `naccept' from incompatible pointer type bookmarks.c:1824: warning: passing arg 3 of `naccept' from incompatible pointer type downloads.c:176: warning: passing arg 3 of `naccept' from incompatible pointer type </q> The third argument of accept() is of socklen_t * type. If the size of the pointed-to value is smaller than the actual type, memory corruption can happen. If AIX doesn't provide socklen_t, dillo blithely defines it as: <q> IO/http.c: #define socklen_t guint32 ../dpi/downloads.c: #define socklen_t guint32 ../dpid/dpi.h: #define socklen_t guint32 </q> Please try changing these to int. This is: #define socklen_t int The other warnings worth of considering at this point are: <q> ld: 0711-224 WARNING: Duplicate symbol: .strcmp ld: 0711-224 WARNING: Duplicate symbol: strcmp ld: 0711-224 WARNING: Duplicate symbol: .pow ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. </q> Hope this helps Jorge.-

Feb. 22, 2004

[Dillo-dev]Resuming...

by Jorge Arellano Cid

Hi there, I'm back from my week off! It was very nice with plenty of good times in the southern part of Chile. A bit short but reassuring! In fact it was a few days ago that I started moving the large stack of emails and pending issues... Those still waiting for an answer, please be patient, just keep sending periodic remainders to the mailing list just in case I get lost in the email pile. ;) (email is kind of an entropic activity: the more you write, the more you receive). One of the already answered was a request from LinuxDevices. Now you can check their coverage of 0.8.0 release here: http://linuxdevices.com/news/NS6109819427.html Greetings to everyone Jorge.-

Feb. 22, 2004