January 2011 - Dillo-dev - lists.mailman3.com

Not to name dillo 1.3 & not to drop fltk 2.0 support

by jcid＠dillo.org

On Sun, Jan 16, 2011 at 10:25:07PM +0000, Karsten Witzman wrote: > While this mail is meant as a follow-up to > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-January/007943.html, > I'd first like to tell you that I'm neither a Dillo nor an FLTK > developer, but reading the mails from the archive in this discussion > thread got me the impression that Dillo uses FLTK 2.0 internally and > that it is intended to switch to 1.3. > > I wonder if this would actually make sense with respect to an > anticipated FLTK 3.0, which, following links from the FLTK project > website (http://www.fltk.org/) to the FLTK 3 proposal > (http://www.fltk.org/articles.php?L1031) and from there to the more > detailed explanations' (http://www.fltk.org/links.php?LC+P402+Q) > section 2 (http://www.fltk.org/links.php?V404+Q) is described as > build on the FLTK 2 API with FLTK 1.3 interna for stability in the > last paragraph of the aforementioned text section. > > I'd like to restate that I have no idea in which ways Dillo and FLTK > are actually connected, but it looks to me like it would be a good > idea for Dillo developers to check what's planned with FLTK 3 and > perhaps get in contact with FLTK developers on this before switching > Dillo code based on FLTK 2 to FLTK 1.3, if the only reason for that is > to base Dillo code on an API that will see support in the future. Point taken. I'll get in contact with them. The background is: they've changed plans several times. We got in very close contact before going with F2, and they said it was to be released real soon (as now with F1.3 and F3). Five years later F2 is dead and we're out of distros. At some point they reached consensus and decided to push F1.3 forward, and it's being moving at good pace. Hopefully with a release in this quarter. I agree that having F3 with F2's API would be the best. The doubt is when will this happen if ever. -- Cheers Jorge.-

Jan. 17, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by hulladiho＠googlemail.com

While this mail is meant as a follow-up to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-January/007943.html, I'd first like to tell you that I'm neither a Dillo nor an FLTK developer, but reading the mails from the archive in this discussion thread got me the impression that Dillo uses FLTK 2.0 internally and that it is intended to switch to 1.3. I wonder if this would actually make sense with respect to an anticipated FLTK 3.0, which, following links from the FLTK project website (http://www.fltk.org/) to the FLTK 3 proposal (http://www.fltk.org/articles.php?L1031) and from there to the more detailed explanations' (http://www.fltk.org/links.php?LC+P402+Q) section 2 (http://www.fltk.org/links.php?V404+Q) is described as build on the FLTK 2 API with FLTK 1.3 interna for stability in the last paragraph of the aforementioned text section. I'd like to restate that I have no idea in which ways Dillo and FLTK are actually connected, but it looks to me like it would be a good idea for Dillo developers to check what's planned with FLTK 3 and perhaps get in contact with FLTK developers on this before switching Dillo code based on FLTK 2 to FLTK 1.3, if the only reason for that is to base Dillo code on an API that will see support in the future. Just my two cents, I hope this mail is appropriately placed here, otherwise apologies, for this is my first mail to any mailing list ever and I'm still quite uncertain about how referring to messages in the archived thread actually works. P.S.: The preceding sentence is not entirely true, as I have already tried yesterday to send the above text to the mailing list. As it didn't appear in the archive until now, I've subscribed to the list as a debugging measure and try it again, in case prior subscription to the list is required to send messages to it. In that case, I'd also like to suggest that such a requirement be communicated at the information page (http://www.dillo.org/MListinfo.html)

Jan. 16, 2011

Q: offical bug report address?

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > AC_INIT takes an optional URL for bug reports. Should we use it, > > and what URL would be appropriate? > > Does anything happen beyond PACKAGE_BUGREPORT getting defined, and > developers getting to put it in MSG()s if they so desire? It adds a line "Report bugs to <...>" at the end of the output of "./configure --help". I agree it's not urgent but I tend to prefer following the conventions unless there is good reason not to. Regards, Jeremy Henty

Jan. 15, 2011

[patch]: clean up the build and make d_size.h static.

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > > Found the problem. > > > > The autoconf 2.66 release announcement > > http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html > > includes: > > > > ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and > > AC_TYPE_INT64_T work again. Regression introduced in 2.65. > So is this a reason to hold back this patch? I...don't think so. My thinking went: 1. It broke harmlessly. 2. But maybe it would break seriously for someone else. 3. But if we'd made the change before 2.65 came out, would we do anything about it, or would we say "Well, that's too bad for autoconf-2.65"? No doubt the latter unless we knew of real breakage.

Jan. 14, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

corvid wrote: > Found the problem. > > The autoconf 2.66 release announcement > http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html > includes: > > ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and > AC_TYPE_INT64_T work again. Regression introduced in 2.65. $ autoconf --version autoconf (GNU Autoconf) 2.64 I guess it pays to be behind the times sometimes! > Looking at the announcements, I'm rather surprised how many things > that don't sound obscure are routinely broken. I think that this is a result of being insanely portable to lots of obscure systems - it leads to lots of cases that are rarely tested. I guess that these days most people have modern headers that declare int32_t etc. so the code just compiles even if AC_TYPE_INT32_T is crazy. > I'd think that autoconf would have so much responsibility that they > would have accumulated a huge test suite. Actually, both autoconf and automake (particularly the latter) have very large test suites. Try running "make check" and see! So is this a reason to hold back this patch? Regards, Jeremy Henty

Jan. 14, 2011

[patch]: clean up the build and make d_size.h static.

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > Jeremy wrote: > > > 3: Determine int32_i and friends with autoconf macros and make > > > d_size.h a static file. Now "make distcheck" works at last! > > > (It used to fail because d_size.h was left behind after a > > > clean.) > > > > I noticed that configure complained a little (although the resulting > > dillo works). I do seem to have the usual set in stdint.h. > > That is very strange! Your configure has generated some completely > broken C! What on earth is that "enum" doing there for a start? Or > the "N"? My config.log (excerpt attached) doesn't have anything like > that. Does anything suspicious appear earlier in config.log? What > are your OS and autoconf versions? Found the problem. The autoconf 2.66 release announcement http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html includes: ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and AC_TYPE_INT64_T work again. Regression introduced in 2.65. Looking at the announcements, I'm rather surprised how many things that don't sound obscure are routinely broken. I'd think that autoconf would have so much responsibility that they would have accumulated a huge test suite.

Jan. 14, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > 3: Determine int32_i and friends with autoconf macros and make > > d_size.h a static file. Now "make distcheck" works at last! > > (It used to fail because d_size.h was left behind after a > > clean.) > > I noticed that configure complained a little (although the resulting > dillo works). I do seem to have the usual set in stdint.h. That is very strange! Your configure has generated some completely broken C! What on earth is that "enum" doing there for a start? Or the "N"? My config.log (excerpt attached) doesn't have anything like that. Does anything suspicious appear earlier in config.log? What are your OS and autoconf versions? Regards, Jeremy Henty > from config.log: > > configure:5280: checking for int32_t > configure:5280: gcc -c -g -O2 conftest.c >&5 > conftest.c: In function 'main': > conftest.c:62: error: expected ')' before ';' token > conftest.c:63: error: expected expression before ']' token > configure:5280: $? = 1 > configure: failed program was: > | /* confdefs.h */ > | #define PACKAGE_NAME "dillo" > | #define PACKAGE_TARNAME "dillo" > | #define PACKAGE_VERSION "2.2" > | #define PACKAGE_STRING "dillo 2.2" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE_URL "" > | #define PACKAGE "dillo" > | #define VERSION "2.2" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define SIZEOF_CHAR 1 > | #define SIZEOF_SHORT 2 > | #define SIZEOF_LONG 4 > | #define SIZEOF_INT 4 > | #define SIZEOF_VOID_P 4 > | /* end confdefs.h. */ > | #include <stdio.h> > | #ifdef HAVE_SYS_TYPES_H > | # include <sys/types.h> > | #endif > | #ifdef HAVE_SYS_STAT_H > | # include <sys/stat.h> > | #endif > | #ifdef STDC_HEADERS > | # include <stdlib.h> > | # include <stddef.h> > | #else > | # ifdef HAVE_STDLIB_H > | # include <stdlib.h> > | # endif > | #endif > | #ifdef HAVE_STRING_H > | # if !defined STDC_HEADERS && defined HAVE_MEMORY_H > | # include <memory.h> > | # endif > | # include <string.h> > | #endif > | #ifdef HAVE_STRINGS_H > | # include <strings.h> > | #endif > | #ifdef HAVE_INTTYPES_H > | # include <inttypes.h> > | #endif > | #ifdef HAVE_STDINT_H > | # include <stdint.h> > | #endif > | #ifdef HAVE_UNISTD_H > | # include <unistd.h> > | #endif > | int > | main () > | { > | static int test_array [1 - 2 * !(enum { N = 32 / 2 - 1 }; > | 0 < (int32_t) (((((int32_t) 1 << N) << N) - 1) * 2 + 1))]; > | test_array [0] = 0 > | > | ; > | return 0; > | }

Jan. 14, 2011

[patch]: clean up the build and make d_size.h static.

by corvid＠lavabit.com

Jeremy wrote: > 3: Determine int32_i and friends with autoconf macros and make > d_size.h a static file. Now "make distcheck" works at last! (It > used to fail because d_size.h was left behind after a clean.) I noticed that configure complained a little (although the resulting dillo works). I do seem to have the usual set in stdint.h. from config.log: configure:5280: checking for int32_t configure:5280: gcc -c -g -O2 conftest.c >&5 conftest.c: In function 'main': conftest.c:62: error: expected ')' before ';' token conftest.c:63: error: expected expression before ']' token configure:5280: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "dillo" | #define PACKAGE_TARNAME "dillo" | #define PACKAGE_VERSION "2.2" | #define PACKAGE_STRING "dillo 2.2" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define PACKAGE "dillo" | #define VERSION "2.2" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define SIZEOF_CHAR 1 | #define SIZEOF_SHORT 2 | #define SIZEOF_LONG 4 | #define SIZEOF_INT 4 | #define SIZEOF_VOID_P 4 | /* end confdefs.h. */ | #include <stdio.h> | #ifdef HAVE_SYS_TYPES_H | # include <sys/types.h> | #endif | #ifdef HAVE_SYS_STAT_H | # include <sys/stat.h> | #endif | #ifdef STDC_HEADERS | # include <stdlib.h> | # include <stddef.h> | #else | # ifdef HAVE_STDLIB_H | # include <stdlib.h> | # endif | #endif | #ifdef HAVE_STRING_H | # if !defined STDC_HEADERS && defined HAVE_MEMORY_H | # include <memory.h> | # endif | # include <string.h> | #endif | #ifdef HAVE_STRINGS_H | # include <strings.h> | #endif | #ifdef HAVE_INTTYPES_H | # include <inttypes.h> | #endif | #ifdef HAVE_STDINT_H | # include <stdint.h> | #endif | #ifdef HAVE_UNISTD_H | # include <unistd.h> | #endif | int | main () | { | static int test_array [1 - 2 * !(enum { N = 32 / 2 - 1 }; | 0 < (int32_t) (((((int32_t) 1 << N) << N) - 1) * 2 + 1))]; | test_array [0] = 0 | | ; | return 0; | }

Jan. 13, 2011

Q: offical bug report address?

by corvid＠lavabit.com

Jeremy wrote: > AC_INIT takes an optional URL for bug reports. Should we use it, and > what URL would be appropriate? Does anything happen beyond PACKAGE_BUGREPORT getting defined, and developers getting to put it in MSG()s if they so desire? My opinion is that we have no particular need for it.

Jan. 13, 2011

Q: offical bug report address?

by onepoint＠starurchin.org

AC_INIT takes an optional URL for bug reports. Should we use it, and what URL would be appropriate? Regards, Jeremy Henty

Jan. 13, 2011