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

[Dillo-dev]Re: gcc 2.95.4 "compilability" (was: no subject)

by opus＠milneweb.com

Jorge Arellano Cid writes: > The original c99 patch introduced a memory leak, so a fixed > version was commited. > > Yes, we do strive for code compatibility, and this kind of > report is welcomed. > > -- > Cheers > Jorge.- > Thank you for fixing this!! -- Pete http://milneweb.com http://nomorevirus.com

Aug. 15, 2004

Re: [Dillo-dev] gcc 2.95.4 "compilability" (was: no subject)

by Jorge Arellano Cid

On Sun, Aug 15, 2004 at 11:25:59AM +0200, Thomas-Martin Seck wrote: > * David McKee (dmckee(a)jlab.org) > > > The code that is giving you trouble is valid under the new (1999) standard > > for "c", but invalid under the old (1982? ANSI standard, and under the > > original K&R compiler). Versions of gcc from 3.0 on accept c99 syntax, but > > older versions do not. I imagine that Jorge will get around to cleaning it > > up sooner or later. He has fixed this kind of thing in the past. > > As the current mainainer of the dillo FreeBSD port I hope that the code > stays "gcc 2.95 clean" for some time since FreeBSD uses gcc 2.95.4 as > the system compiler on the 4.x series and 4.x is likely to stay around > for quite a while, even after FreeBSD 5 is declared the "STABLE" > development branch. The original c99 patch introduced a memory leak, so a fixed version was commited. Yes, we do strive for code compatibility, and this kind of report is welcomed. -- Cheers Jorge.-

Aug. 15, 2004

Re: [Dillo-dev] gcc 2.95.4 "compilability" (was: no subject)

by Thomas-Martin Seck

* David McKee (dmckee(a)jlab.org) > The code that is giving you trouble is valid under the new (1999) standard > for "c", but invalid under the old (1982? ANSI standard, and under the > original K&R compiler). Versions of gcc from 3.0 on accept c99 syntax, but > older versions do not. I imagine that Jorge will get around to cleaning it > up sooner or later. He has fixed this kind of thing in the past. As the current mainainer of the dillo FreeBSD port I hope that the code stays "gcc 2.95 clean" for some time since FreeBSD uses gcc 2.95.4 as the system compiler on the 4.x series and 4.x is likely to stay around for quite a while, even after FreeBSD 5 is declared the "STABLE" development branch.

Aug. 15, 2004

Re: [Dillo-dev](no subject)

by David McKee

On Sat, 14 Aug 2004, Opus wrote: > On Sat, 14 Aug 2004 19:02:02 -0400 (EDT), David McKee <dmckee(a)jlab.org> wrote: > > Pete, > > This is the problem I reported (and supplied a patch for) under the [snip] > > On Sat, 14 Aug 2004 opus(a)milneweb.com wrote: > > > I am having this issue when I get to 'gmake' doing the CVS build. > > [snip] [snip] > Hey David....thanks. You surely take me for someone that has a clue > what you said means...lol! > > After you said "This is the problem I reported (and supplied a patch > for)" I got lost. I have used CVS for a while now, I am lucky to be > able to get it compiled when things go well. > > Maybe I should skip it now til all is fixed....unless you have a > reasonably 'do-able for me' suggestion. I certainly appreciate your > response though. *;o) Try grabbing the CVS from before the latest patch... man cvs and look for the -D option which lets you set the date spec... BTW- The web access to the CVS archive is the easiest way to learn when that patch was applied. Good luck, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 15, 2004

Re: [Dillo-dev](no subject)

by David McKee

Pete, This is the problem I reported (and supplied a patch for) under the title "c99 coding style...". You can fix it you self by going to the lines where the erros are reported and moving the declarations to the top of their functions. The one in interface.c (the one giving the error below) includes an initiallization that depends on the state of the fuction at line 1350, so you'll have to split it into a declartaion at the top of the function, and an assignment in the current location. The one in url.c can be solved by moving the sanity check at the top of the function below all the declarations. On Sat, 14 Aug 2004 opus(a)milneweb.com wrote: > I am having this issue when I get to 'gmake' doing the CVS build. [snip] > interface.c: In function `Interface_make_search_url': > interface.c:1350: syntax error before `*' > interface.c:1352: `search_url' undeclared (first use in this function) > interface.c:1352: (Each undeclared identifier is reported only once > interface.c:1352: for each function it appears in.) > interface.c:1353: warning: control reaches end of non-void function [snip] > Pete The code that is giving you trouble is valid under the new (1999) standard for "c", but invalid under the old (1982? ANSI standard, and under the original K&R compiler). Versions of gcc from 3.0 on accept c99 syntax, but older versions do not. I imagine that Jorge will get around to cleaning it up sooner or later. He has fixed this kind of thing in the past. Good luck, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 14, 2004

[Dillo-dev](no subject)

by opus＠milneweb.com

I will try to post this again.... I am having this issue when I get to 'gmake' doing the CVS build. [FreeBSD happy.hopto.org 4.10-RELEASE FreeBSD 4.10-RELEASE #0] interface.c: In function `Interface_make_search_url': interface.c:1350: syntax error before `*' interface.c:1352: `search_url' undeclared (first use in this function) interface.c:1352: (Each undeclared identifier is reported only once interface.c:1352: for each function it appears in.) interface.c:1353: warning: control reaches end of non-void function gmake[3]: *** [interface.o] Error 1 gmake[3]: Leaving directory `/usr/home/petie/dillo/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/home/petie/dillo/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/petie/dillo' gmake: *** [all] Error 2 -- Pete http://milneweb.com http://nomorevirus.com

Aug. 14, 2004

Re: [Dillo-dev]thread-safe X at fresco

by robert w hall

In article <Pine.LNX.4.60.0406182239380.5841(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > >On Fri, 18 Jun 2004, robert w hall wrote: > >> The thread-safe versions of XFree3.3.3.1 have disappeared from >> linuxsavvy, (and my own attempts too recompile my own have produced >> useable, but not wholly error-free results)... >> >> But I note that vintage.fresco.org still has two earlier thread-safe >> Xlibs, 3.1.2 and 3.2, linked statically. > > I have REENTRANT 3.3.2 libs that work for me. If you want I can >pack them for you to try... > > Cheers > Jorge.- > > Another thing to watch ( clearly I didn't) is not to let ldconfig pick up the 'wrong' version of libpthread - slack 4 has a version which is libc5 compatible and also a version in the glibc1 package linked to libc6 I think. Brings down the whole caboodle with a seg fault if you get the wrong one. >_______________________________________________ >Dillo-dev mailing list >Dillo-dev(a)lists.auriga.wearlab.de >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- robert w hall

Aug. 13, 2004

[Dillo-dev]dpi preferences suggestion

by David McKee

Folks, I've been thinking a little about my comment the other day to the effect that I prefer more contrast in list views than the new file:// dpi's table mode provided. I wondered if that might be a reasonable candidate for a configurable preference. It's not clear that it is, but it got me thinking about handling preferences in dpi. I suggest that we don't want every dpi implementing it's own preferences scheme. So dpid should handle reading in any preferences for dpis, and pass them to the plugin. The simplest method would be to set environment variables in the new processes execution environment. If we are willing to tolerate having preferences read in only at startup (as with the main program right now) that is the whole of the problem. For reading user preferences from disk we can presumably use the same code that is current employed to get the dillo preferences... Any thoughts? Cheers, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 13, 2004

[Dillo-dev]c99 coding style breaks gcc 2.* in interface.c, url.c

by David McKee

Folks, Some elements of the latest CVS patch breaks older c compilers... Personally I like the "declare when you need it" behavior, but gcc2.95 doesn't. The fix is almost trivial: %%%%%%%%%% diff -pru dillo_c99/src/interface.c dillo/src/interface.c --- dillo_c99/src/interface.c Fri Aug 13 12:25:02 2004 +++ dillo/src/interface.c Fri Aug 13 12:17:50 2004 @@ -1329,6 +1329,7 @@ static gchar *Interface_make_search_url( { gchar *keys = a_Url_encode_hex_str(str), *c = prefs.search_url; GString *newstr = g_string_sized_new(strlen(c)+strlen(keys)); + gchar *search_url; for (; *c; c++) if (*c == '%') @@ -1347,7 +1348,7 @@ static gchar *Interface_make_search_url( g_free(keys); - gchar *search_url = newstr->str; + search_url = newstr->str; g_string_free(newstr, FALSE); return search_url; } diff -pru dillo_c99/src/url.c dillo/src/url.c --- dillo_c99/src/url.c Fri Aug 13 12:25:02 2004 +++ dillo/src/url.c Fri Aug 13 12:22:07 2004 @@ -540,13 +540,12 @@ gchar *a_Url_decode_hex_str(const gchar */ gchar *a_Url_encode_hex_str(const gchar *str) { - if (!str) - return NULL; - static const char *verbatim = "-_.*"; static const char *hex = "0123456789ABCDEF"; - char *newstr = g_new(char, 6*strlen(str)+1), *c; + + if (!str) + return NULL; for (c = newstr; *str; str++) if ((isalnum(*str) && !(*str & 0x80)) || strchr(verbatim, *str)) %%%%%%%%%% -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 13, 2004

[Dillo-dev]Re: Is IO.txt outdated?

by Calvin Yu

>> It says dillo uses threads for DNS querying and reading local >> files, and signal driven I/O for TCP connections. When the socket >> gets ready for transmission, the data is sent using >> g_io_channel_write. But I can't not find the place where >> g_io_channel_write is invoked in the code. > > Yes, once upon a time it used g_io_channel_write, but not >anymore. I'll update this doc ASAP and let you know when its >ready. > >> >> In previous posts I see >> "When using threads and mutexes (pthreads), thread scheduling is >> done by a third thread or by the kernel (depends upon the >> implementation), and it is preemptive. Now, the address space may >> be shared, so the need for mutexes arise, and because of both >> reasons, performance is degraded. >> Using a pseudo-thread (CCC thread), doesn't require scheduling >> by an external process or by the kernel. All is done in the same >> process, but there's no preemption." >> But I do find a thread is spawned in "a_IO_write_chunk()". >> Would you please tell me the reason? > > Otherwise it wouldn't generate IO signals. > >> What does pseudo-thread mean? > > A non-preemptive thread as those handled by CCC. > I don't think it is really parallel. If there are several connections at the same time, one must wait until another one completes data transfer. assume such a case: one connection is responsible for downloading a big image, and other connections are going to download small images. The former one's G_IO_IN event is triggered first and it begins to download the big image. It will take long for it to complete downloading and other connections have to wait. It's unfair for them though they will cost much less time. I don't know whether I'm right. Must other connections wait until one completes or error occurs? >> Is such thread spawned in >> "a_IO_write_chunk()" pseudo-thread? > > No that one is a POSIX thread (or pthread at least ;). > >-- > Cheers > Jorge.-

Aug. 13, 2004