- Dillo-dev - lists.mailman3.com

hypenator.cc errors
by csoren＠isd.net Sept. 6, 2013

Sept. 6, 2013

> On Mo, Sep 02, 2013, Chris Sorenson wrote: > > Greets all, > > > > Another sequence of bads that cropped up using the > > Silicon Graphics MIPSpro compiler, any thoughts? To wit: > > > > cc-1028 CC: ERROR File = hyphenator.cc, Line = 147 > > The expression used must have a constant value. > > > > char chars [l + 1]; > > ^ > > [more similar cases] > > It seems that your compiler does not support arrays with > variable length, which are standard since C99, as far as I > see. It could be fixed by replacing this line (as an > example) by: > > char *chars = new char [l + 1]; > > and later > > delete[] chars; > > However, I'd like to check other possibilities. A short > search lead me to > <http://www.sgi.com/products/software/irix/tools/c.html>, > according to which newer versions support C99. Which > version do you use? > I'm using MIPSpro 7.4.3 (the most current version is 7.4.4) but in C99 mode it can't compile C++ code. Not to worry I'll #ifdef my way around the variable length arrays, I guess I didn't look closely enough to realize that was what those were, thanks!

3 4

Fwd: Re: hypenator.cc errors
by csoren＠isd.net Sept. 6, 2013

Sept. 6, 2013

> > Cris: If you run ./autogen.sh && ./configure, you should > see a line: Can't seem to apply the patch: chris at starhunter:~/src/dls/dillo-3.0.3$ patch < var_len_arr_cxx.diff (Stripping trailing CRs from patch.) patching file configure.ac Hunk #1 succeeded at 105 with fuzz 2. Hunk #2 succeeded at 406 (offset -26 lines). (Stripping trailing CRs from patch.) can't find file to patch at input line 38 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |diff -r 808c0a0fc122 dw/hyphenator.cc |--- a/dw/hyphenator.cc Mon Sep 02 11:31:37 2013 -0400 |+++ b/dw/hyphenator.cc Wed Sep 04 11:15:02 2013 +0200 -------------------------- Do I need to have a mercurial checked out version to use this patch?

2 1

hypenator.cc errors
by csoren＠isd.net Sept. 5, 2013

Sept. 5, 2013

Trying it again with `patch -p1` I get: (Stripping trailing CRs from patch.) patching file configure.ac Hunk #1 succeeded at 105 with fuzz 2. Hunk #2 succeeded at 406 (offset -26 lines). (Stripping trailing CRs from patch.) patching file dw/hyphenator.cc Hunk #1 FAILED at 49. Hunk #2 FAILED at 118. 2 out of 5 hunks FAILED -- saving rejects to file dw/hyphenator.cc.rej (Stripping trailing CRs from patch.) patching file lout/misc.hh

1 0

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c
by jgaffney＠lawrenceville.org Sept. 2, 2013

Sept. 2, 2013

It seems that the dpid children forked by Dpi_start_dpid() in dpi.c are not reaped when they terminate themselves after a period of inactivity while the parent dillo process is still running. The patch below is simply to reap these zombies. The SIGCHLD handler should probably do more, but I am not yet familiar enough with Dillo to know what. I believe this patch adheres to the Dillo rules of coding style, but am new to the list and a novice at Dillo patching. And hence also apologies to Jorge for this duplication of a previous communication by private email (although with one small change to get the patch to compile under OpenBSD as well as Linux). ######## BEGIN PATCH ######## --- a/src/IO/dpi.c 2013-01-27 12:26:38.000000000 -0500 +++ b/src/IO/dpi.c 2013-08-27 14:58:07.995235867 -0400 @@ -33,6 +33,8 @@ #include <netinet/tcp.h> #include <arpa/inet.h> #include <netdb.h> +#include <sys/wait.h> +#include <signal.h> #include "../msg.h" #include "../klist.h" @@ -331,16 +333,33 @@ } } +static void Sigchld_handler (int signum) { + int status; + waitpid (-1, &status, WNOHANG); + } + /* * Start dpid. * Return: 0 starting now, 1 Error. */ static int Dpi_start_dpid(void) { + static int install_sigchld_handler_flag = TRUE; pid_t pid; int st_pipe[2], ret = 1; char *answer; + if ( install_sigchld_handler_flag ) { + /* Install SIGCHLD handler. */ + struct sigaction sa; + sa.sa_handler = Sigchld_handler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = SA_RESTART | SA_NOCLDSTOP; + if (sigaction(SIGCHLD, &sa, 0)) + MSG ("Unable to install SIGCHLD handler.\n"); + install_sigchld_handler_flag = FALSE; + } + /* create a pipe to track our child's status */ if (pipe(st_pipe)) return 1; ######## END PATCH ########

4 7

hypenator.cc errors
by csoren＠isd.net Sept. 2, 2013

Sept. 2, 2013

Greets all, Another sequence of bads that cropped up using the Silicon Graphics MIPSpro compiler, any thoughts? To wit: cc-1028 CC: ERROR File = hyphenator.cc, Line = 147 The expression used must have a constant value. char chars [l + 1]; ^ cc-1028 CC: ERROR File = hyphenator.cc, Line = 185 The expression used must have a constant value. char noHyphens[len - 2 * breaks->size() + 1]; ^ cc-1028 CC: ERROR File = hyphenator.cc, Line = 185 The expression used must have a constant value. char noHyphens[len - 2 * breaks->size() + 1]; ^ cc-1060 CC: ERROR File = hyphenator.cc, Line = 185 The indicated operator is not allowed in an integral constant expression. char noHyphens[len - 2 * breaks->size() + 1]; ^ cc-1059 CC: ERROR File = hyphenator.cc, Line = 185 A function call is not allowed in a constant expression. char noHyphens[len - 2 * breaks->size() + 1]; ^ cc-1028 CC: ERROR File = hyphenator.cc, Line = 316 The expression used must have a constant value. char work[strlen (wordLc) + 3]; ^ cc-1059 CC: ERROR File = hyphenator.cc, Line = 316 A function call is not allowed in a constant expression. char work[strlen (wordLc) + 3]; ^ cc-1028 CC: ERROR File = hyphenator.cc, Line = 316 The expression used must have a constant value. char work[strlen (wordLc) + 3]; ^ 8 errors detected in the compilation of "hyphenator.cc". make: *** [hyphenator.o] Error 2

2 1

compilation error in fltkflatview.cc
by csoren＠isd.net Sept. 2, 2013

Sept. 2, 2013

> > > > 2 errors detected in the compilation of > > "fltkflatview.cc". ---------- > > > > I suspect it needs a 'using namespace' or somesuch here, > > thoughts? > > > > I thought this sounded a little familiar, and I was able > to find > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2013-January/009809.html > that we'd been through this before. > > I think last time I was waiting to see whether anyone > reported that it didn't work for them, or that dw > originally had that for a deep reason, and then I > eventually forgot about it. This time I'll commit it, and > we'll find out. > Sorry I didn't realize this was the same question I posted about before since I assumed that that fix had been committed and back then I was working with pre-3.0 sources, anyway thanks!

1 0

compilation error in fltkflatview.cc
by csoren＠isd.net Sept. 2, 2013

Sept. 2, 2013

Greets all, As I've mentioned previously I'm trying to compile dillo-3.0.3 on Silicon Graphics using the SGI MIPSpro compiler. I'm doing this for a large group of SGI users who reside at nekochan.net. The compilation fails in line 884 in fltkflatview.cc: ---------- cc-3168 CC: ERROR File = fltkui.cc, Line = 884 A name followed by "::" must be a class or namespace name. bool FltkToggleButtonResource<I>::FltkToggleButtonResource::isActivated () ^ cc-1443 CC: ERROR File = fltkui.cc, Line = 884 "dw::fltk::ui::FltkToggleButtonResource<I>::FltkToggleButtonResource" is not a class template. bool FltkToggleButtonResource<I>::FltkToggleButtonResource::isActivated () ^ 2 errors detected in the compilation of "fltkflatview.cc". ---------- I suspect it needs a 'using namespace' or somesuch here, thoughts? Thanks a bunch!

2 1

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c
by jgaffney＠lawrenceville.org Aug. 31, 2013

Aug. 31, 2013

Jorge Arellano Cid <jcid at dillo.org> writes: > Hi Johannes, JG: > [...] > The attached program is a stress test for SIGCHLD. The idea is to > find a formula that works well even in such cases. IIRC both of you > have access to BSD machines so please test it there. > > The program spawns 255 children which sleep 5 seconds and > terminate generating a SIGCHLD avalanche, which should be handled > cleanly. It works OK in Debian. [...] 1) OpenBSD is very strict about compliance with standards, so that, whereas on my (and I believe most if not all) Linux systems wait.h occurs redundantly in /usr/include/ and /usr/include/sys, on OpenBSD wait.h is solely in /usr/include/sys and your code will not compile unless the `#include<wait.h>' line is removed. Then `gcc -W -Wall' compiles it without complaint. 2) OpenSBD is not so extravagant with the resources allocated to unprivileged users (max 128 processes). But spawning 64 rather than 256 children the test is passed with the expected behavior on OpenBSD 5.2 GENERIC.MP#368 amd64. The OpenBSD 5.2 ports include Dillo 2.2 and FLTK2, but I just recently compiled FLTK 1.3.2 and Dillo 3.0.3 from their unmodified source on that machine without (IIRC) any errors. If you were curious more generally to see how they are modifying the Dillo source, the OpenBSD patches for Dillo 3.0.3 (the version currently in ports for OpenBSD 5.3) may be found at http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/

2 1

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c
by jgaffney＠lawrenceville.org Aug. 29, 2013

Aug. 29, 2013

Johannes Hofmann <Johannes.Hofmann at gmx.de> writes: > Hi JG, > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: >> It seems that the dpid children forked by Dpi_start_dpid() in dpi.c >> are not reaped when they terminate themselves after a period of >> inactivity while the parent dillo process is still running. The patch >> below is simply to reap these zombies. The SIGCHLD handler should >> probably do more, but I am not yet familiar enough with Dillo to know >> what. >> >> I believe this patch adheres to the Dillo rules of coding style, but >> am new to the list and a novice at Dillo patching. And hence also >> apologies to Jorge for this duplication of a previous communication by >> private email (although with one small change to get the patch to >> compile under OpenBSD as well as Linux). > > I can reproduce the issue here by killing dpid manually. > For me the following also fixes it: > > diff -r 659dc205c377 src/dillo.cc > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > @@ -329,6 +329,7 @@ > > // Some OSes exit dillo without this (not GNU/Linux). > signal(SIGPIPE, SIG_IGN); > + signal(SIGCHLD, SIG_IGN); > > /* Handle command line options */ > opt_argv = dNew0(char*, numOptions(Options) + 1); > > Can you please check whether it works for you too? It would have the > advantage that we have all signal related stuff in one place. > > Cheers, > Johannes Thank you: your solution is of course not only correct but far simpler and better. (Though I thought that in general sigaction() is to be preferred to signal()?)

1 0

allow_white_bg
by sgeerken＠dillo.org Aug. 21, 2013

Aug. 21, 2013

Hi! It seems that I'm getting old that I tried to set the option "allow_white_bg" to "false"; to find out that the replacement color is hardcoded! If I haven't missed something, and noone objets, I'll add a prefs variable "white_bg_replacement". BTW: is there a reason that there is still a prefs variable "bg_color", while fonts (the actual fonts, not the font classes) are now defined by CSS? Sebastian

2 3