- Dillo-dev - lists.mailman3.com

1.3 port status

by corvid＠lavabit.com

Roger wrote: > Capi_filters_test: DENY from 'news.google.com' to 'nt3.ggpht.com' If you want all of those, in dillorc, change filter_auto_requests to allow_all.

Jan. 25, 2011

1.3 port status

by corvid＠lavabit.com

Roger wrote: > I was just using hg update (after the initial hg clone $url). hg update is something different. You use hg pull to get changes from a repository. > Here's my description now, pages load, even news.google.com loads! Scrolling > on news.google.com pauses/lags at times. No images loaded on news.google.com. Right now, the scrolling doesn't happen while the cursor wanders outside of the scrollbar bounds. > As for the dillo interface, tabs appear after a few seconds/minutes of mouse > wandering. I do have buttons, but the "File, View, ..." buttons are still > hidden. After mouse wandering? Of their own accord? View?

Jan. 25, 2011

1.3 port status

by rogerx.oss＠gmail.com

> On Mon, Jan 24, 2011 at 09:39:37PM +0000, corvid wrote: >Roger wrote: >> Yup. I performed the 'hg tip' and compared with your times and mine still >> showed older. This is exactly what I was afraid of. svn/cvs update seems so >> much friendlier! >> >> So, I just wiped and re-cloned. > >Had you been using 'hg pull http://hg.dillo.org/dillo_port1.3'? > >I'll take a look at this pthread/lock matter... > >UI brokenness: Is the patch applying cleanly for you? >I'll send you a screenshot of what I see with and without the patch. >It should look rather like ordinary dillo but unpolished. I was just using hg update (after the initial hg clone $url). Totally scratch the buggy GUI description I gave! I forgot to apply 1.3_ui_hardcoded.patch from this thread! Here's my description now, pages load, even news.google.com loads! Scrolling on news.google.com pauses/lags at times. No images loaded on news.google.com. As for the dillo interface, tabs appear after a few seconds/minutes of mouse wandering. I do have buttons, but the "File, View, ..." buttons are still hidden. Images do load for "http://forecast.weather.gov/MapClick.php?zoneid=AKZ222" and www.google.com. But negative images for news.google.com ... no biggy as I only really read text. I'll try the pthread patch next.

Jan. 24, 2011

1.3 port status

by corvid＠lavabit.com

Roger wrote: > Here's that pthread issue again: > g++ -I/usr/include/libpng14 -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W > -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo > dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o > prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o > dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o > styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o > imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a > ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a > ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib -lpng14 > -L/usr/lib/fltk-1.1 -Wl,-rpath,/usr/lib/fltk-1.1 -lfltk -lXext -lXft > -lfontconfig -ldl -lm -lX11 -lz > dns.o: In function `Dns_server_req': > /home/roger/src/dillo/dillo_port1.3/src/dns.c:360: undefined reference to > `pthread_create' Does the attached fix this for you?

Jan. 24, 2011

1.3 port status

by corvid＠lavabit.com

Roger wrote: > Yup. I performed the 'hg tip' and compared with your times and mine still > showed older. This is exactly what I was afraid of. svn/cvs update seems so > much friendlier! > > So, I just wiped and re-cloned. Had you been using 'hg pull http://hg.dillo.org/dillo_port1.3'? I'll take a look at this pthread/lock matter... UI brokenness: Is the patch applying cleanly for you? I'll send you a screenshot of what I see with and without the patch. It should look rather like ordinary dillo but unpolished.

Jan. 24, 2011

1.3 port status

by rogerx.oss＠gmail.com

> On Mon, Jan 24, 2011 at 06:11:31PM +0000, corvid wrote: >Roger wrote: >> 'hg update' && patch from this thread. > >Your backtrace doesn't match up for dw/layout.cc, for instance. >Is there an 'hg pull' in there as well? >(Also, if it wasn't clear, a new version of the UI patch went up >yesterday.) > >> Going from memory, I believe they were window functions calling the old 2.0 >> branch names instead of 1.3. >> >> I believe I already sent you the details, but since they were only test >> programs and didn't hinder dillo from being built, they aren't a high priority. > >I fixed up the Browser test to compile a couple of days ago. Yup. I performed the 'hg tip' and compared with your times and mine still showed older. This is exactly what I was afraid of. svn/cvs update seems so much friendlier! So, I just wiped and re-cloned. Within the following compiler error stdout's, please ignore the "-I/usr/include/fltk-1.1" as the package maintainer for fltk-1.3 ebuilds on bugs.gentoo.org is working to get the library slotted correctly. I only have fltk-1.3 and fltk-2.0 libraries installed here. Here's that pthread issue again: g++ -I/usr/include/libpng14 -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib -lpng14 -L/usr/lib/fltk-1.1 -Wl,-rpath,/usr/lib/fltk-1.1 -lfltk -lXext -lXft -lfontconfig -ldl -lm -lX11 -lz dns.o: In function `Dns_server_req': /home/roger/src/dillo/dillo_port1.3/src/dns.c:360: undefined reference to `pthread_create' Too resolve, ./configure --disable-threaded-dns (or am I missing a dep?... I don't think so.) Here's the Flock() function call to the old fltk-2.0 lock function: g++ -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o downloads.dpi downloads_dpi-downloads.o dpiutil.o -L/usr/lib/fltk-1.1 -Wl,-rpath,/usr/lib/fltk-1.1 -lfltk -lXext -lXft -lfontconfig -ldl -lm -lX11 ../dpip/libDpip.a ../dlib/libDlib.a downloads_dpi-downloads.o: In function `main': /home/roger/src/dillo/dillo_port1.3/dpi/downloads.cc:1105: undefined reference to `Fl::lock()' Test programs compiled without errors. On execute, I see the "Back, Forward, Home, ..." buttons with a slice of the bottom of the "File, View, ..." stuff. Everything else seems frozen. If I'm not mistaken, I can see the toolbar window extend a third of the way down the screen. Then the next 2/3's I see the light grey browser window with slider. Then 3/3 I can see the top slice of "File, View, ..." toolbar window. Oh. I found the hidden "File" button from "File, View, ..." toolbar. But I can't open a url. But did get a new blank tab open. No pages loaded yet. ctrl-s gets me search the web, and ctrl-r seems to be reloading an invisible page (likely google.com as I see it loads two images from the text info). ctrl-l (open file) and ctrl-n (new window) works. ctrl-l fails to open an applet (open url). Looks like pages are loading by looking at the console and the text info detailing "images loaded", but everything is invisible ... windows borking? Looks like rendering pages is being done invisible because the applets/windows are failing.

Jan. 24, 2011

1.3 port status

by corvid＠lavabit.com

Roger wrote: > Just going to www.google.com and doing a search on a name crashes on me. > > Browser buttons are all screwy - or invisible, along with File, Edit, ... > > Tabs do become visible after visiting an html only (text only) website > such as mine. This is with current patch and all current code? > GNU gdb (Gentoo 7.2 p1) 7.2 > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu". Is this system reasonably ordinary 32-bit linux? > I also forgot to briefly mention, I still need to compiled with "./configure > --disable-threaded-dns" and test programs fail to compile. (dillo is compiled, > yet "make" fails to compile extra test programs -- probably should be a > configure option to enable/disable building test programs -- and test programs > be disabled by default?) What was wrong with the test programs?

Jan. 24, 2011

1.3 port status

by rogerx.oss＠gmail.com

I also forgot to briefly mention, I still need to compiled with "./configure --disable-threaded-dns" and test programs fail to compile. (dillo is compiled, yet "make" fails to compile extra test programs -- probably should be a configure option to enable/disable building test programs -- and test programs be disabled by default?)

Jan. 24, 2011

1.3 port status

by rogerx.oss＠gmail.com

> On Sun, Jan 23, 2011 at 07:06:28PM +0000, corvid wrote: >It should be less crashy now when leaving pages with form widgets >in general. > >It still doesn't like complexbutton, and you can get it to segfault if >you play with tabs enough, which might simply be because my UI patch >doesn't take the UI's y() value into account (nonzero once the tabs >shift it down). Just going to www.google.com and doing a search on a name crashes on me. Browser buttons are all screwy - or invisible, along with File, Edit, ... Tabs do become visible after visiting an html only (text only) website such as mine. The following is a backtrace w/ gdb info: ~/src/dillo/dillo_port1.3/src $ gdb dillo GNU gdb (Gentoo 7.2 p1) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Really redefine built-in command "frame"? (y or n) [answered Y; input not from terminal] Really redefine built-in command "thread"? (y or n) [answered Y; input not from terminal] Really redefine built-in command "start"? (y or n) [answered Y; input not from terminal] Reading symbols from /home/roger/src/dillo/dillo_port1.3/src/dillo...done. gdb> run dillo_dns_init: Here we go! (not threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='dpi:/bm/' Nav_open_url: new url='http://www.google.com' Dns_server [0]: www.google.com is 74.125.127.105 74.125.127.104 74.125.127.103 74.125.127.99 74.125.127.147 74.125.127.106 Connecting to 74.125.127.105 ...snip... Program received signal SIGSEGV, Segmentation fault. _______________________________________________________________________________ eax:081548E0 ebx:00000004 ecx:081124C0 edx:08153E98 eflags:00010246 esi:00000080 edi:08113B8C esp:BFFFC0BC ebp:BFFFC108 eip:00000001 cs:0073 ds:007B es:007B fs:0000 gs:0033 ss:007B o d I t s Z a P c [007B:BFFFC0BC]---------------------------------------------------------[stack] BFFFC0EC : 03 00 00 00 10 46 15 08 - 08 0F 15 08 08 00 00 00 .....F.......... BFFFC0DC : C0 24 11 08 10 46 15 08 - B3 02 00 00 98 3E 15 08 .$...F.......>.. BFFFC0CC : 03 00 00 00 3C C1 FF BF - C8 55 15 08 A5 3D 3D 4D ....<....U...==M BFFFC0BC : 46 D5 08 08 E0 48 15 08 - B3 02 00 00 A6 01 00 00 F....H.......... [007B:08113B8C]---------------------------------------------------------[ data] 08113B8C : 04 00 00 00 05 00 00 00 - 00 00 00 00 28 00 00 00 ............(... 08113B9C : 05 00 00 00 0D 00 00 00 - 04 00 00 00 04 00 00 00 ................ [0073:00000001]---------------------------------------------------------[ code] => 0x1: Error while running hook_stop: Cannot access memory at address 0x1 0x00000001 in ?? () gdb> bt #0 0x00000001 in ?? () #1 0x0808d546 in dw::Textblock::getWidgetAtPoint (this=0x8153e98, x=0x2b3, y=0x1a6, level=0x2) at textblock.cc:1895 #2 0x080a4576 in dw::core::Widget::getWidgetAtPoint (this=0x8150f08, x=0x2b3, y=0x1a6, level=0x1) at widget.cc:529 #3 0x0808d546 in dw::Textblock::getWidgetAtPoint (this=0x8166ed8, x=0x2b3, y=0x1a6, level=0x0) at textblock.cc:1895 #4 0x0809c010 in dw::core::Layout::getWidgetAtPoint (this=0x8100298, x=0x2b3, y=0x1a6) at layout.cc:832 #5 0x0809da25 in moveToWidgetAtPoint (this=0x8100298, view=0x80f8828, x=0x2b3, y=0x1a6, state=0) at layout.hh:170 #6 dw::core::Layout::motionNotify (this=0x8100298, view=0x80f8828, x=0x2b3, y=0x1a6, state=0) at layout.cc:773 #7 0x08095e2f in dw::fltk::FltkViewBase::handle (this=0x80f8828, event=0xb) at fltkviewbase.cc:250 #8 0xb7f247f4 in send(Fl_Widget*, int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #9 0xb7f2502d in Fl_Group::handle(int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #10 0xb7f247f4 in send(Fl_Widget*, int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #11 0xb7f2502d in Fl_Group::handle(int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #12 0xb7f247f4 in send(Fl_Widget*, int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #13 0xb7f2502d in Fl_Group::handle(int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #14 0xb7f572d8 in Fl_Tabs::handle(int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #15 0x08052f71 in CustTabGroup::handle (this=0x80c8af8, e=0xb) at uicmd.cc:322 #16 0xb7f247f4 in send(Fl_Widget*, int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #17 0xb7f2502d in Fl_Group::handle(int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #18 0xb7f0b6cd in Fl_Window::handle(int) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #19 0xb7f0ba0c in fl_fix_focus() () from /usr/lib/fltk-1.1/libfltk.so.1.3 #20 0xb7f0c1ad in fl_throw_focus(Fl_Widget*) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #21 0xb7f6b40b in Fl_Widget::~Fl_Widget() () from /usr/lib/fltk-1.1/libfltk.so.1.3 #22 0xb7f12f1d in Fl_Button::~Fl_Button() () from /usr/lib/fltk-1.1/libfltk.so.1.3 #23 0x08091cfb in dw::fltk::ui::FltkResource::~FltkResource (this=0xb7fd6ff4, __in_chrg=<value optimized out>) at fltkui.cc:81 #24 0x080928ca in ~FltkSpecificResource (this=0x8112668, __in_chrg=<value optimized out>) at fltkui.hh:210 #25 dw::fltk::ui::FltkLabelButtonResource::~FltkLabelButtonResource (this=0x8112668, __in_chrg=<value optimized out>) at fltkui.cc:239 #26 0x080a3cdf in dw::core::ui::Embed::~Embed (this=0x81127b0, __in_chrg=<value optimized out>) at ui.cc:44 #27 0x08089d5b in dw::Textblock::~Textblock (this=0x8153e98, __in_chrg=<value optimized out>) at textblock.cc:103 #28 0x08086701 in dw::Table::~Table (this=0x8150f08, __in_chrg=<value optimized out>) at table.cc:78 #29 0x08089d5b in dw::Textblock::~Textblock (this=0x8166ed8, __in_chrg=<value optimized out>) at textblock.cc:103 #30 0x0809dfe1 in dw::core::Layout::setWidget (this=0x8100298, widget=0x81577f8) at layout.cc:282 #31 0x08059196 in a_Web_dispatch_by_type (Type=0x8158e88 "text/html; charset=ISO-8859-1", Web=0x80f9770, Call=0x8115d74, Data=0x8115d78) at web.cc:79 #32 0x0805b402 in Cache_process_queue (entry=0x8115d18) at cache.c:1148 #33 0x0805874f in a_Chain_fcb (Op=0x8153e98, Info=0x8152c40, Data1=0x8115db8, Data2=0x80b397f) at chain.c:113 #34 0x08081488 in Dpi_parse_token (Op=0x2, Branch=0x2, Dir=0x1, Info=0x8152c40, Data1=0x8108ba0, Data2=0x0) at dpi.c:220 #35 Dpi_process_dbuf (Op=0x2, Branch=0x2, Dir=0x1, Info=0x8152c40, Data1=0x8108ba0, Data2=0x0) at dpi.c:339 #36 a_Dpi_ccc (Op=0x2, Branch=0x2, Dir=0x1, Info=0x8152c40, Data1=0x8108ba0, Data2=0x0) at dpi.c:735 #37 0x0805874f in a_Chain_fcb (Op=0x8153e98, Info=0x8150240, Data1=0x8108ba0, Data2=0x0) at chain.c:113 #38 0x08081ab6 in a_IO_ccc (Op=0x2, Branch=0x2, Dir=0x1, Info=0x8150240, Data1=0x80ea168, Data2=0x0) at IO.c:425 #39 0x08081d0c in IO_read (io=0x80ea168) at IO.c:197 #40 0x08081da5 in IO_callback (io=0x81548e0) at IO.c:262 #41 0x08081ee7 in IO_fd_read_cb (fd=0x6, data=0x7) at IO.c:283 #42 0xb7f72ef3 in fl_wait(double) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #43 0xb7f0c8f3 in Fl::wait(double) () from /usr/lib/fltk-1.1/libfltk.so.1.3 #44 0xb7f0ca54 in Fl::run() () from /usr/lib/fltk-1.1/libfltk.so.1.3 #45 0x0804db1f in main (argc=0x1, argv=0xbfffeda4) at dillo.cc:369 gdb>

Jan. 24, 2011

1.3 port status

by Johannes.Hofmann＠gmx.de

On Mon, Jan 24, 2011 at 12:02:58AM +0000, corvid wrote: > With the latest code and a new version of the UI patch, > it has suddenly become gratifyingly non-crashy for me :) > But I'm sure you could find a way! No luck yet - still trying :)

Jan. 24, 2011

1.3 port status

by corvid＠lavabit.com

With the latest code and a new version of the UI patch, it has suddenly become gratifyingly non-crashy for me :) But I'm sure you could find a way!

Jan. 24, 2011

1.3 port status

by corvid＠lavabit.com

It should be less crashy now when leaving pages with form widgets in general. It still doesn't like complexbutton, and you can get it to segfault if you play with tabs enough, which might simply be because my UI patch doesn't take the UI's y() value into account (nonzero once the tabs shift it down).

Jan. 23, 2011

1.3 port status

by corvid＠lavabit.com

I wrote: > Fredrik wrote: > > I've got some errors trying to compile. Is it my fault? > > For the moment, changing the > #if USE_X11 > to > #if 0 > in src/xembed.cc should make that go away. xembed.cc should compile now.

Jan. 23, 2011

1.3 port status

by corvid＠lavabit.com

Fredrik wrote: > I've got some errors trying to compile. Is it my fault? For the moment, changing the #if USE_X11 to #if 0 in src/xembed.cc should make that go away.

Jan. 22, 2011

1.3 port status

by iveqy＠iveqy.com

On Sat, Jan 22, 2011 at 03:59:37AM +0000, corvid wrote: > The fltk-1.3 port is decently usable now if you take > http://hg.dillo.org/dillo_port1.3/ > and apply my quick hacky UI patch > http://www.dillo.org/test/1.3_ui_hardcoded.patch > (Anyone want to write a proper one? :) > > I see that it's segfaulting when leaving pages with > image inputs because of something to do with > complexbutton, but...decently usable, certainly. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev g++ -DHAVE_CONFIG_H -I. -I.. -I.. -DDILLO_SYSCONF='"/usr/local/etc/dillo/"' -DDILLO_DOCDIR='"/usr/local/share/doc/dillo/"' -I/usr/local/include -I/usr/include/libpng12 -I/usr/local/include -DUSE_X11 -D_THREAD_SAFE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o xembed.cc xembed.cc: In member function ?void Xembed::setXembedInfo(long unsigned int)?: xembed.cc:43: error: ?fltk? has not been declared xembed.cc:48: error: ?fltk? has not been declared xembed.cc: In member function ?void Xembed::sendXembedEvent(uint32_t)?: xembed.cc:62: error: ?fltk? has not been declared xembed.cc:64: error: ?fltk? has not been declared xembed.cc:67: error: ?fltk? has not been declared xembed.cc:68: error: ?fltk? has not been declared xembed.cc: In function ?int event_handler(int, Fl_Window*)?: xembed.cc:80: error: ?fltk? has not been declared xembed.cc:82: error: ?fltk? has not been declared xembed.cc:83: error: ?fltk? has not been declared xembed.cc:84: error: ?fltk? has not been declared xembed.cc: In member function ?void Xembed::create()?: xembed.cc:108: error: ?fltk? has not been declared xembed.cc: In member function ?void Xembed::createInternal(uint32_t)?: xembed.cc:113: error: ?fltk? has not been declared xembed.cc:135: error: ?fltk? has not been declared xembed.cc:136: error: ?fltk? has not been declared xembed.cc:140: error: ?fltk? has not been declared xembed.cc:142: error: ?fltk? has not been declared make[3]: *** [xembed.o] Fel 1 make[3]: Leaving directory `/home/iveqy/slask/dillo_port1.3/src' make[2]: *** [all-recursive] Fel 1 make[2]: Leaving directory `/home/iveqy/slask/dillo_port1.3/src' make[1]: *** [all-recursive] Fel 1 make[1]: Leaving directory `/home/iveqy/slask/dillo_port1.3' make: *** [all] Fel 2 I've got some errors trying to compile. Is it my fault? -- Med v?nliga h?lsningar Fredrik Gustafsson tel: 0733-608274 e-post: iveqy(a)iveqy.com

Jan. 22, 2011

1.3 port status

by corvid＠lavabit.com

The fltk-1.3 port is decently usable now if you take http://hg.dillo.org/dillo_port1.3/ and apply my quick hacky UI patch http://www.dillo.org/test/1.3_ui_hardcoded.patch (Anyone want to write a proper one? :) I see that it's segfaulting when leaving pages with image inputs because of something to do with complexbutton, but...decently usable, certainly.

Jan. 22, 2011

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

by rogerx.oss＠gmail.com

>>At this point I'm half-tempted to throw together an API wrapper myself, >>just so we can have something and save ourselves the trouble of rewriting >>Dillo (again). > >Ditto. I've tinkering around just trying to compile Dillo against fltk-1.3 >here on Gentoo for kicks. Got a running bug here with not being able to enter >keyboard text within fields after switching virtual desktop in DWM (aka tags). Changed the following to use fltk(1-3) libs instead of fltk-2. File: configure.in dnl ---------------------- dnl Test for FLTK library dnl ---------------------- dnl dnl For debugging and to be user friendly AC_MSG_CHECKING([FLTK2]) if sh -c "fltk-config --version" >/dev/null 2>&1 then AC_MSG_RESULT(yes) LIBFLTK_CXXFLAGS=`fltk-config --cxxflags` LIBFLTK_CFLAGS=`fltk-config --cflags` LIBFLTK_LIBS=`fltk-config --ldflags` else AC_MSG_RESULT(no) AC_MSG_ERROR(FLTK2 must be installed!) fi ./autogen && ./configure && make Resulted in a large number of function changes. (aka underfined reference errors) Now I can see why you're dragging your feet on just creating a CVS/SVN repository for fltk-1.3! -- Roger http://rogerx.freeshell.org/

Jan. 18, 2011

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

by rogerx.oss＠gmail.com

> On Mon, Jan 17, 2011 at 10:21:18AM -0500, Benjamin Johnson wrote: >On Mon, 17 Jan 2011 09:32:09 -0500, Jorge Arellano Cid <jcid(a)dillo.org> >wrote: > >> 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. Although I'm just a bystander concerning Dillo (my favorite all time browser), I agree. The way they're wording is published on the FLTK website concerning F3, it won't ever likely happen (unless things really take off with F1.3.) >At this point I'm half-tempted to throw together an API wrapper myself, >just so we can have something and save ourselves the trouble of rewriting >Dillo (again). Ditto. I've tinkering around just trying to compile Dillo against fltk-1.3 here on Gentoo for kicks. Got a running bug here with not being able to enter keyboard text within fields after switching virtual desktop in DWM (aka tags). >As an aside, I wish just one of the major toolkits would get its act >together; we all know about GTK+, and I'm still using Qt 3 because 4.x is >such a mess. It's sad when coding directly against native APIs -- Win32, >Cocoa, pure Xlib -- is almost the more attractive option. Ditto. FLTK has a great idea, but seems to be low on man power. Qt just makes me ill to be stomach -- to Qt for me. Don't care about flowers, just gimme something to clickity-click on! -- Roger http://rogerx.freeshell.org/

Jan. 18, 2011

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

by onepoint＠starurchin.org

corvid wrote: > 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. So is it OK to push? Does anyone else have comments? Regards, Jeremy Henty

Jan. 17, 2011

Q: offical bug report address?

by onepoint＠starurchin.org

I wrote: > 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. Any other opinions from the devs? Regards, Jeremy Henty

Jan. 17, 2011

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

by obeythepenguin＠gmail.com

On Mon, 17 Jan 2011 09:32:09 -0500, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > 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. At this point I'm half-tempted to throw together an API wrapper myself, just so we can have something and save ourselves the trouble of rewriting Dillo (again). As an aside, I wish just one of the major toolkits would get its act together; we all know about GTK+, and I'm still using Qt 3 because 4.x is such a mess. It's sad when coding directly against native APIs -- Win32, Cocoa, pure Xlib -- is almost the more attractive option. ~Benjamin

Jan. 17, 2011

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

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

by onepoint＠starurchin.org

These patches clean up the build system some more and then address the issue raised here[1], by using autoconf to define int32_t etc. and turning d_size.h into a static source file instead of building it. A nice simplification! Note that it depends on adding -I.$(top_srcdir) to AM_CPPFLAGS so that d_size.h can be #include-ed anywhere. 1: Finish the work begun in changeset 90603f572f75 by replacing paths that use ../ with full paths from $(top_builddir). 2: Add -I$(top_srcdir) to AM_CPPFLAGS everywhere. (This is necessary to allow the next change.) 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.) Comments are welcome. Regards, Jeremy Henty [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005135.html

Jan. 13, 2011

[patch]: more spring cleaning of configure.in

by Johannes.Hofmann＠gmx.de

On Mon, Jan 10, 2011 at 09:58:43PM +0000, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > On Sat, Jan 08, 2011 at 11:31:56PM +0000, Jeremy Henty wrote: > > > corvid wrote: > > > > Jeremy wrote: > > > > > Time to retire some more obsolete autoconf macros. See [1] > > > > > for details. > > > > > > > > > > 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . > > > > > > > > > > 2: Replace AC_ERROR with AC_MSG_ERROR . > > > > > > > > > > 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / > > > > > AC_LANG_PROGRAM . > > > > > > > > > > This doesn't break for me, but it affects some > > > > > host-dependent parts of configure.in . It would be good > > > > > to know that this works on hosts with unusual socket / > > > > > iconv library routines. > > > > > > > > > > 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL > > > > > . > > > > > > > > > > This only affects target OSes *other* than linux, solaris, > > > > > osf1 and minix. Can anyone test on such a thing? > > > > > > > > > > 5: Indentation tweak for consistency. > > > > > > > > Works without giving me any problems... > > > > > > OK. Does anyone else have any concerns? Is this OK to push? > > > > +1 > > All pushed. I hope that anyone building Dillo on non-Linux systems > will report any problems as soon as possible. I can only test on > Linux so I rely on others to tell me if I break the build on other > systems. No problems here on DragonFly BSD. Regards, Johannes

Jan. 12, 2011

[patch]: more spring cleaning of configure.in

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Sat, Jan 08, 2011 at 11:31:56PM +0000, Jeremy Henty wrote: > > corvid wrote: > > > Jeremy wrote: > > > > Time to retire some more obsolete autoconf macros. See [1] > > > > for details. > > > > > > > > 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . > > > > > > > > 2: Replace AC_ERROR with AC_MSG_ERROR . > > > > > > > > 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / > > > > AC_LANG_PROGRAM . > > > > > > > > This doesn't break for me, but it affects some > > > > host-dependent parts of configure.in . It would be good > > > > to know that this works on hosts with unusual socket / > > > > iconv library routines. > > > > > > > > 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL > > > > . > > > > > > > > This only affects target OSes *other* than linux, solaris, > > > > osf1 and minix. Can anyone test on such a thing? > > > > > > > > 5: Indentation tweak for consistency. > > > > > > Works without giving me any problems... > > > > OK. Does anyone else have any concerns? Is this OK to push? > > +1 All pushed. I hope that anyone building Dillo on non-Linux systems will report any problems as soon as possible. I can only test on Linux so I rely on others to tell me if I break the build on other systems. Regards, Jeremy Henty

Jan. 10, 2011

.hgignore

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > corvid wrote: > > > Jeremy wrote: > > > > +^dpi/[^/]*\.dpi$ > > > > > > I get mixed up by the differences in the various regexps out > > > there. Is this "[^/]" intended as a *looks up the term* bracket > > > expression? > > > > > > The hgignore page says it uses Python/Perl syntax, and the first > > > regexp page that I find ( > > > http://www.greenend.org.uk/rjk/2002/06/regexp.html ) seems to > > > say that Perl and Python just do character classes when given > > > brackets. > > > > [^...] is a negated class. [^/] matches any charar#cter other > > than /. If I got it right this matches all *.dpi files in the > > dpi/ directory. > > I'm familiar with negation, but it wasn't clear from that page that > _all_ regexps work that way. Oh sorry, I didn't realise that was your concern. I have always taken it for granted that negation with [^...] would work in any of the popular scripting languages. It just didn't occur to me to worry whether Python regexps might be any different. > But putting a dpi file in a subdir now, it does exactly what we > want. Ah, experimentation, it's a beautiful thing... Looks like I got away with it then :-) . I have pushed the patch because I think it's a no-brainer (but I'll be happy to revert/amend it if others disagree). Regards, Jeremy Henty

Jan. 10, 2011

regular expressions

by gsavix＠gmail.com

very good mails articles about regular expressions. congratulations! i learn lots in these mails. thanks for all! debian lenny 5.0.6 (i386) -- gilberto dos santos alves (11) 8646-5049 s?o paulo - SP - Brasil

Jan. 9, 2011

[patch]: more spring cleaning of configure.in

by jcid＠dillo.org

On Sun, Jan 09, 2011 at 01:37:54PM -0300, Jorge Arellano Cid wrote: > [...] > The real feedback should arrive once we have a fltk-1.3 based > release. Let's hope it happens soon. BTW, we have rc3 [1]. [1] http://fltk.org/articles.php?L1033 -- Cheers Jorge.-

Jan. 9, 2011

[patch]: more spring cleaning of configure.in

by jcid＠dillo.org

On Sat, Jan 08, 2011 at 11:31:56PM +0000, Jeremy Henty wrote: > corvid wrote: > > Jeremy wrote: > > > Time to retire some more obsolete autoconf macros. See [1] for > > > details. > > > > > > 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . > > > > > > 2: Replace AC_ERROR with AC_MSG_ERROR . > > > > > > 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / AC_LANG_PROGRAM . > > > > > > This doesn't break for me, but it affects some host-dependent > > > parts of configure.in . It would be good to know that this works > > > on hosts with unusual socket / iconv library routines. > > > > > > 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL . > > > > > > This only affects target OSes *other* than linux, solaris, osf1 > > > and minix. Can anyone test on such a thing? > > > > > > 5: Indentation tweak for consistency. > > > > Works without giving me any problems... > > OK. Does anyone else have any concerns? Is this OK to push? +1 The real feedback should arrive once we have a fltk-1.3 based release. Let's hope it happens soon. -- Cheers Jorge.-

Jan. 9, 2011

[patch]: more spring cleaning of configure.in

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > Time to retire some more obsolete autoconf macros. See [1] for > > details. > > > > 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . > > > > 2: Replace AC_ERROR with AC_MSG_ERROR . > > > > 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / AC_LANG_PROGRAM . > > > > This doesn't break for me, but it affects some host-dependent > > parts of configure.in . It would be good to know that this works > > on hosts with unusual socket / iconv library routines. > > > > 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL . > > > > This only affects target OSes *other* than linux, solaris, osf1 > > and minix. Can anyone test on such a thing? > > > > 5: Indentation tweak for consistency. > > Works without giving me any problems... OK. Does anyone else have any concerns? Is this OK to push? Regards, Jeremy Henty

Jan. 9, 2011

.hgignore

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > Jeremy wrote: > > > +^dpi/[^/]*\.dpi$ > > > > I get mixed up by the differences in the various regexps out there. > > Is this "[^/]" intended as a *looks up the term* bracket expression? > > > > The hgignore page says it uses Python/Perl syntax, and the first > > regexp page that I find ( http://www.greenend.org.uk/rjk/2002/06/regexp.html ) > > seems to say that Perl and Python just do character classes when > > given brackets. > > [^...] is a negated class. [^/] matches any charar#cter other than /. > If I got it right this matches all *.dpi files in the dpi/ directory. I'm familiar with negation, but it wasn't clear from that page that _all_ regexps work that way. But putting a dpi file in a subdir now, it does exactly what we want. Ah, experimentation, it's a beautiful thing...

Jan. 8, 2011

.hgignore

by rogutes＠googlemail.com

corvid (2011-01-08 17:30): > Jeremy wrote: > > +^dpi/[^/]*\.dpi$ > > I get mixed up by the differences in the various regexps out there. > Is this "[^/]" intended as a *looks up the term* bracket expression? "[/]*" matches 0 or more "/" characters "[^/]*" matches 0 or more characters that are not "/". It may as well be [a-z] versus [^a-z]. So the purpose of brackets isn't changed here, i.e. they are still used to match character classes, and "^" is merely a negation. And I believe it is supported by basic, extended and pcre regexps. -- -- Rogut?s Sparnuotos

Jan. 8, 2011

.hgignore

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > +^dpi/[^/]*\.dpi$ > > I get mixed up by the differences in the various regexps out there. > Is this "[^/]" intended as a *looks up the term* bracket expression? > > The hgignore page says it uses Python/Perl syntax, and the first > regexp page that I find ( http://www.greenend.org.uk/rjk/2002/06/regexp.html ) > seems to say that Perl and Python just do character classes when > given brackets. [^...] is a negated class. [^/] matches any charar#cter other than /. If I got it right this matches all *.dpi files in the dpi/ directory. Regards, Jeremy Henty

Jan. 8, 2011

.hgignore

by corvid＠lavabit.com

Jeremy wrote: > +^dpi/[^/]*\.dpi$ I get mixed up by the differences in the various regexps out there. Is this "[^/]" intended as a *looks up the term* bracket expression? The hgignore page says it uses Python/Perl syntax, and the first regexp page that I find ( http://www.greenend.org.uk/rjk/2002/06/regexp.html ) seems to say that Perl and Python just do character classes when given brackets.

Jan. 8, 2011

.hgignore

by onepoint＠starurchin.org

corvid wrote: > These should be in .hgignore, shouldn't they? > > $ hg status > ? dpi/vsource.filter.dpi > ? dpid/dpidc > ? dpid/dpidrc I agree. Suggested patch attached. Regards, Jeremy Henty

Jan. 8, 2011

.hgignore

by corvid＠lavabit.com

These should be in .hgignore, shouldn't they? $ hg status ? dpi/vsource.filter.dpi ? dpid/dpidc ? dpid/dpidrc

Jan. 8, 2011

hg repo

by corvid＠lavabit.com

The downloads DPI is working fairly well now (although I have to resize it before it begins to display anything). It's nice to have something that compiles and runs!

Jan. 8, 2011

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

by corvid＠lavabit.com

Benjamin wrote: > I understand the arguments for switching, but I'm not convinced the needs > are really all that pressing, or that Dillo can really afford another such > drastic overhaul right now. Well, as I've mentioned, being out of distributions has been really bad for us, http://www.dillo.org/stats/ and becoming totally irrelevant is no good.

Jan. 7, 2011

hg repo

by Johannes.Hofmann＠gmx.de

On Fri, Jan 07, 2011 at 12:45:12PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote: > > Johannes wrote: > > > I would go with a separate repo for fltk-1.3 development. It's still > > > a branch, so we can use 3-way merging to keep things in sync with > > > mainline. The only difference is that you don't get fltk-1.3 > > > development stuff automatically when cloning the main repo - which I > > > think is a good thing. > > > Once it's ready we pull it over in the main repo. That's the same > > > procedure we used for the CSS-experimental branch. > > > > Andreas added a repository for me. > > > > I've done most of the really mindless parts now, so now we > > merely need to do all of the hard parts! > > What are the coordinates of the repo? Check http://hg.dillo.org/ Cheers, Johannes

Jan. 7, 2011

hg repo

by jcid＠dillo.org

On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote: > Johannes wrote: > > I would go with a separate repo for fltk-1.3 development. It's still > > a branch, so we can use 3-way merging to keep things in sync with > > mainline. The only difference is that you don't get fltk-1.3 > > development stuff automatically when cloning the main repo - which I > > think is a good thing. > > Once it's ready we pull it over in the main repo. That's the same > > procedure we used for the CSS-experimental branch. > > Andreas added a repository for me. > > I've done most of the really mindless parts now, so now we > merely need to do all of the hard parts! What are the coordinates of the repo? -- Cheers Jorge.-

Jan. 7, 2011

hg repo

by Johannes.Hofmann＠gmx.de

On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote: > Johannes wrote: > > I would go with a separate repo for fltk-1.3 development. It's still > > a branch, so we can use 3-way merging to keep things in sync with > > mainline. The only difference is that you don't get fltk-1.3 > > development stuff automatically when cloning the main repo - which I > > think is a good thing. > > Once it's ready we pull it over in the main repo. That's the same > > procedure we used for the CSS-experimental branch. > > Andreas added a repository for me. > > I've done most of the really mindless parts now, so now we > merely need to do all of the hard parts! Great. I hope we don't hit any showstoppers...

Jan. 7, 2011