- Dillo-dev - lists.mailman3.com

redirect madness on mobil.bahn.de

by andreas＠kemnade.info

Hi, i have some problems using http://mobil.bahn.de/ with dillo. I do not understand fully what is going on there. The urls accessed are: http://mobil.bahn.de/ http://www.bahn.de/m/view/de/index.shtml (via HTTP redirect) http://www.bahn.de/m/view/de/0/ (=404, accessed using meta redirect) http://www.bahn.de/m/view/de/0/0/ (=404, accessed using meta redirect) http://www.bahn.de/m/view/de/0/0/0/ http://www.bahn.de/m/view/de/0/0/0/0/ ... (after some zeros, m/view/de is appended again) Interesting is this refresh line here (I got it using tcpflow and zcat): <meta http-equiv="Refresh" content="0;http://www.bahn.de/m/;fitScript=0/"> dillo seems to screw it up. I do not know what the standard says here (except that meta redirect is not so nice). calling http://www.bahn.de/m/;fitScript=0/ directly, I can use that page with dillo. Another interesting thing is: That page comes without javascript (and even without that meta redirect! ) when I load it with wget. But it has javascript when accessed with dillo. Greetings Andreas Kemnade

Feb. 18, 2014

JS integration?

by frusen＠gungre.ch

> So, how could I get JS integration for dillo working? It just needs to > be basic, and have at least XHR. Take a look in the mailing list's archive. I read that someone had done some experiments with Simple ECMAScript Engine[0] but it was a while ago. SEE hasn't been updated for a while but take a look at it. Cheers! [0] http://adaptive-enterprises.com/~d/software/see/ -- Lucas Sk?ldqvist (frusen) [2BC57692] 85F7 C267 BC83 6603 66C9 927D AEFB 6AFC 2BC5 7692

Jan. 4, 2014

JS integration?

by ingwie2000＠googlemail.com

Hey hey! Me and a friend are looking out for a very small browser with basic javascript integration. Iknow that dillo is ultra small thanks to FLTK - however, I also know it currently has no JS? So, how could I get JS integration for dillo working? It just needs to be basic, and have at least XHR. Kind regards, Ingwie!

Jan. 4, 2014

[j.rios@laposte.net: Thanks]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Dec. 24, 2013

RTFL

by sgeerken＠dillo.org

Hi! To fulfill this comment in lout/debug.hh: /* * Following is experimental, and will be explained soon. */ See <http://www.dillo.org/~sgeerken/rtfl/> for a short description and a tarball to dowload. This is a re-implementation of a prototype I wrote several years ago, which then proved already very useful for debugging subtleties of "incremental resizing", but was unfortunately lost. I hope that the new version will be equally useful for debugging floats. RTFL is not restricted to dillo, so feel free to use it in other projects. Sebastian

Dec. 1, 2013

Image backgrounds

by sgeerken＠dillo.org

Hi! Image backgrounds are now in the main repository, at <http://hg.dillo.org/dillo>. On Tue, Nov 19, 2013, Sebastian Geerken wrote: > - Displaying image backgrounds at once, not line by line: there is > already an hardcoded option, so changing is simple, even make it a > user option. Drawing instantly is now the default. To change this, modify "drawBackgroundLineByLine" in "dw/style.cc". Sebastian

Nov. 29, 2013

Compatible with mips64el

by frusen＠gungre.ch

Hey! I want to report that Dillo3 is working on mips64el under GNU/Linux so you can add it to the compatibility page. -- Lucas Sk?ldqvist (frusen) [2BC57692] 85F7 C267 BC83 6603 66C9 927D AEFB 6AFC 2BC5 7692

Nov. 26, 2013

Integrate JavaScript and better CSS

by johannes.hofmann＠gmx.de

Hi, On Wed, Nov 20, 2013 at 10:29:34PM +0100, Kevin Ingwersen wrote: > Hey there. > > So now that I can develop and embed dillo, I would like to know if it is possible to do some things: > > - Use a 3rd party JavaScript engine and use it inside dillo Not easy. There are some thoughts about adding scripting (you should find some stuff in the mailling list archives), but having full blown JavaScript support is being worked on. > - Get proper CSS We are constantly working to improve our CSS support. It depends on what exact feature you need. Cheers, Johannes

Nov. 21, 2013

Image backgrounds

by sgeerken＠dillo.org

On Do, Nov 21, 2013, Jorge Arellano Cid wrote: > On Tue, Nov 19, 2013 at 03:59:01PM +0100, Sebastian Geerken wrote: > > I'd like to bring image backgrounds to a (temporary) end; before, I'd > > like to finish these tasks (see also doxygen documentation): > > I'm resuming my work on this issue. Just finished a first read pass > among the large changesets in the new repo (68). I've taken some notes > and have a few comments from it, and some things to review. Good! > Next, I'll review the past emails you sent me focusing on specific > things. The question is, is there anything new/obsolete to review or > focus here now? You might also be interested in the following changes: c7a45fe8a24c: Getting toplevel widgets working. (The new function a_Image_new_with_dw does what a_Image_new did before.) f44e841bb521: Extension of the ImgRenderer interface. This is actually incomplete: a_Image_abort (and so ImgRenderer::abort) is not called in some cases, see documentation (html/dw-images-and-backgrounds.html). Does not play an important role, but the "abort" method could be used by image *widgets* to show that retrieving image data has failed (e. g. by a broken image frame). 9b8435e69e84: Stopping cache clients for background image. (Already mentioned in a mail.) Sebastian

Nov. 21, 2013

Image backgrounds

by jcid＠dillo.org

Hi Sebastian, On Tue, Nov 19, 2013 at 03:59:01PM +0100, Sebastian Geerken wrote: > Hi! > > I'd like to bring image backgrounds to a (temporary) end; before, I'd > like to finish these tasks (see also doxygen documentation): I'm resuming my work on this issue. Just finished a first read pass among the large changesets in the new repo (68). I've taken some notes and have a few comments from it, and some things to review. Next, I'll review the past emails you sent me focusing on specific things. The question is, is there anything new/obsolete to review or focus here now? -- Cheers Jorge.-

Nov. 21, 2013

Integrate JavaScript and better CSS

by ingwie2000＠googlemail.com

Hey there. So now that I can develop and embed dillo, I would like to know if it is possible to do some things: - Use a 3rd party JavaScript engine and use it inside dillo - Get proper CSS Kind regards, Ingwie

Nov. 20, 2013

Compiling error

by ingwie2000＠googlemail.com

Hey. Yes, now it compiled - i have a usable dillo binary in src/ Thank you very much =). Maybe a short macro for what you did could be used. #ifdef __APPLE__ // this is visible int verb() { return 1; } #endif This worked in a test compile - i used gcc -E. Regards, Ingwie Am 20.11.2013 um 21:40 schrieb Johannes Hofmann <Johannes.Hofmann at gmx.de>: > On Wed, Nov 20, 2013 at 05:06:11PM +0100, Kevin Ingwersen wrote: >> Hey. >> >> Now that FLTK is up and working?this happens: >> >> g++ -I/Applications/drag0n/drag0n.app/Contents/System/usr/local/include -I/Applications/drag0n/drag0n.app/Contents/System/usr/local/include/FL/images -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.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 domain.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 -L/Applications/drag0n/drag0n.app/Contents/System/usr/local/lib -lfltk -lpthread -framework Cocoa -lz -liconv >> duplicate symbol __ZN10Fl_Printer8class_idE in: >> ../dw/libDw-fltk.a(libDw_fltk_a-fltkplatform.o) >> /Applications/drag0n/drag0n.app/Contents/System/usr/local/lib/libfltk.a(Fl_Printer.o) >> ld: 1 duplicate symbol for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see invocation) >> make[3]: *** [dillo] Error 1 >> make[2]: *** [all-recursive] Error 1 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 >> >> /Applications/drag0n/drag0n.app/Contents/System includes a copy of my toolchain, also meaning FLTK and others. >> >> What can I do to get rid of this duplicate error? From what I know, a function was declared twice somewhere, but then again I did not study the source code ^^. > > Could you try with attached little patch? > > Cheers, > Johannes > <dillo-macosx.diff>_______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 20, 2013

Compiling error

by Johannes.Hofmann＠gmx.de

On Wed, Nov 20, 2013 at 05:06:11PM +0100, Kevin Ingwersen wrote: > Hey. > > Now that FLTK is up and working?this happens: > > g++ -I/Applications/drag0n/drag0n.app/Contents/System/usr/local/include -I/Applications/drag0n/drag0n.app/Contents/System/usr/local/include/FL/images -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.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 domain.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 -L/Applications/drag0n/drag0n.app/Contents/System/usr/local/lib -lfltk -lpthread -framework Cocoa -lz -liconv > duplicate symbol __ZN10Fl_Printer8class_idE in: > ../dw/libDw-fltk.a(libDw_fltk_a-fltkplatform.o) > /Applications/drag0n/drag0n.app/Contents/System/usr/local/lib/libfltk.a(Fl_Printer.o) > ld: 1 duplicate symbol for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[3]: *** [dillo] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > /Applications/drag0n/drag0n.app/Contents/System includes a copy of my toolchain, also meaning FLTK and others. > > What can I do to get rid of this duplicate error? From what I know, a function was declared twice somewhere, but then again I did not study the source code ^^. Could you try with attached little patch? Cheers, Johannes

Nov. 20, 2013

Compiling error

by ingwie2000＠googlemail.com

Hey. Now that FLTK is up and working?this happens: g++ -I/Applications/drag0n/drag0n.app/Contents/System/usr/local/include -I/Applications/drag0n/drag0n.app/Contents/System/usr/local/include/FL/images -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.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 domain.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 -L/Applications/drag0n/drag0n.app/Contents/System/usr/local/lib -lfltk -lpthread -framework Cocoa -lz -liconv duplicate symbol __ZN10Fl_Printer8class_idE in: ../dw/libDw-fltk.a(libDw_fltk_a-fltkplatform.o) /Applications/drag0n/drag0n.app/Contents/System/usr/local/lib/libfltk.a(Fl_Printer.o) ld: 1 duplicate symbol for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [dillo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 /Applications/drag0n/drag0n.app/Contents/System includes a copy of my toolchain, also meaning FLTK and others. What can I do to get rid of this duplicate error? From what I know, a function was declared twice somewhere, but then again I did not study the source code ^^. Kind regards, Ingwie

Nov. 20, 2013

FLTK won't build on Mac OS

by jcid＠dillo.org

On Wed, Nov 20, 2013 at 03:49:54PM +0100, Kevin Ingwersen wrote: > Hello there. Hi. > I just downloaded Dillo because I wanted to use it for > development, obviously. However, upon building FLTK, i had to > realize its not build-able - and that is more a conflict on > apple?s side. Once the Carbon headers are refferenced, i get a > miles-long error message (it took me a while to find the top of > all that O.o). Which FLTK version are you trying to build? Dillo uses 1.3.x AFAIK, FLTK is buildable on Macs since long ago. Even the newest 3.0 branch. You may ask FLTK developers shall the problem persist. (www.fltk.org) > Will Dillo stay with FLTK or are there plans to move on with a > newer GUI? Plans are to stay with FLTK. -- Cheers Jorge.-

Nov. 20, 2013

FLTK won't build on Mac OS

by ingwie2000＠googlemail.com

Hello there. I just downloaded Dillo because I wanted to use it for development, obviously. However, upon building FLTK, i had to realize its not build-able - and that is more a conflict on apple?s side. Once the Carbon headers are refferenced, i get a miles-long error message (it took me a while to find the top of all that O.o). Will Dillo stay with FLTK or are there plans to move on with a newer GUI? Kind regards, Ingwie

Nov. 20, 2013

FLTK won't build on Mac OS

by dev＠frign.de

On Wed, 20 Nov 2013 15:49:54 +0100 Kevin Ingwersen <ingwie2000 at googlemail.com> wrote: > Hello there. > > I just downloaded Dillo because I wanted to use it for development, obviously. However, upon building FLTK, i had to realize its not build-able - and that is more a conflict on apple?s side. Once the Carbon headers are refferenced, i get a miles-long error message (it took me a while to find the top of all that O.o). > > Will Dillo stay with FLTK or are there plans to move on with a newer GUI? > > Kind regards, > Ingwie Hey Ingwie, always keep in mind: newer =!= better! It would be great if you could provide these "miles-long" error-logs to us so we get an idea what the problem is. It could as well be a problem limited to your system. Back in the old days when I used Mac OS X, it was a daily struggle to even get the simplest program to compile. Now I'm on Gentoo for good reasons. MacPorts offers a build for dillo [1]. You might want to try that out before suggesting us to rewrite big parts of the software or switching toolkits! Cheers FRIGN [1]: https://trac.macports.org/browser/trunk/dports/www/dillo/Portfile -- FRIGN <dev at frign.de>

Nov. 20, 2013

Image backgrounds

by sgeerken＠dillo.org

On Di, Nov 19, 2013, Johannes Hofmann wrote: > On Tue, Nov 19, 2013 at 03:59:01PM +0100, Sebastian Geerken wrote: > > I'd like to bring image backgrounds to a (temporary) end; before, I'd > > like to finish these tasks (see also doxygen documentation): > > Cool! It looks really nice. > > > - Configurability: Should there be new options, additional to > > "load_image"? If yes, there have to be: > > > > 1. a new option, "load_background_image", > > 2. a new entry in the configuration menu, and > > 3. a new entry in the context menu. > > > > The latter will be quite tricky, when applied to single areas for > > which a background image is assigned to, but an entry "load *ALL* > > background images" (emphasis mine) should be simple. > > I think there should be an option to switch off background image > loading, so that by switching it off one can basically get the > current bahavior. > Not sure if we need 2. and 3. I've added 1, and also 2, which was rather simple. Should be enough for now. BTW: I've copied the code from Menu_remote_css_cb, but found out that changing "Use remote CSS" in the tools menu (as well as "Load image backgrounds") is only applied to the current tab, while the change is actually global (which is visible when reloading another tab). That's somewhat confusing. > > - Security/privacy (cookies?): I'm not sure whether there is anything > > left to do. > > It should respect the rules from domainrc, but as far as I tested > it does that. OK. > > > > - Displaying image backgrounds at once, not line by line: there is > > already an hardcoded option, so changing is simple, even make it a > > user option. > > > > "background-attachment" is postponed. Furthermore, other features are > > missing, which make background images look strange, e. g. that you > > only see a part of the logo at <http://google.com>. > > Do you know what missing features cause this? As far as I see, it is the "height" attribute. Often, an area (<div>) is assigned a background image as well as width and height of the image itself. This way, the image (which is regarded as presentation detail) is only defined by CSS, not in HTML. Sebastian

Nov. 20, 2013

Image backgrounds

by Johannes.Hofmann＠gmx.de

Hi Sebastian, On Tue, Nov 19, 2013 at 03:59:01PM +0100, Sebastian Geerken wrote: > Hi! > > I'd like to bring image backgrounds to a (temporary) end; before, I'd > like to finish these tasks (see also doxygen documentation): Cool! It looks really nice. > > - Configurability: Should there be new options, additional to > "load_image"? If yes, there have to be: > > 1. a new option, "load_background_image", > 2. a new entry in the configuration menu, and > 3. a new entry in the context menu. > > The latter will be quite tricky, when applied to single areas for > which a background image is assigned to, but an entry "load *ALL* > background images" (emphasis mine) should be simple. I think there should be an option to switch off background image loading, so that by switching it off one can basically get the current bahavior. Not sure if we need 2. and 3. > > - Security/privacy (cookies?): I'm not sure whether there is anything > left to do. It should respect the rules from domainrc, but as far as I tested it does that. > > - Displaying image backgrounds at once, not line by line: there is > already an hardcoded option, so changing is simple, even make it a > user option. > > "background-attachment" is postponed. Furthermore, other features are > missing, which make background images look strange, e. g. that you > only see a part of the logo at <http://google.com>. Do you know what missing features cause this? Cheers, Johannes

Nov. 19, 2013

Image backgrounds

by sgeerken＠dillo.org

Hi! I'd like to bring image backgrounds to a (temporary) end; before, I'd like to finish these tasks (see also doxygen documentation): - Configurability: Should there be new options, additional to "load_image"? If yes, there have to be: 1. a new option, "load_background_image", 2. a new entry in the configuration menu, and 3. a new entry in the context menu. The latter will be quite tricky, when applied to single areas for which a background image is assigned to, but an entry "load *ALL* background images" (emphasis mine) should be simple. - Security/privacy (cookies?): I'm not sure whether there is anything left to do. - Displaying image backgrounds at once, not line by line: there is already an hardcoded option, so changing is simple, even make it a user option. "background-attachment" is postponed. Furthermore, other features are missing, which make background images look strange, e. g. that you only see a part of the logo at <http://google.com>. Did I forget something important? Sebastian

Nov. 19, 2013

Last couple of patches

by jcid＠dillo.org

On Mon, Nov 18, 2013 at 06:56:04PM +0100, Sebastian Geerken wrote: > Hi! > > On Mo, Nov 18, 2013, Jorge Arellano Cid wrote: > > After changeset 1a8661485c0b and e40f77531b5e, the bookmarks > > page is rendered with the largest width I've seen. As the patches > > deal with table apportioning, probably there's a small bug lurking > > there. > > > > I've also found another couple of test pages of mine (from my > > table apportioning test set) that also show the effect. It happens with > > tables using "width=AUTO with cells widths in percentages". > > This was actually meant as a "cosmetic" change, without changing > functionality. Nevertheless, the recent commit should fix it, at > least, the attached page works now. Yes, I thought so. I'll let you know if something else springs, as now works ok with the last patch. Thanks for the quick fix! BTW, you may s/depricicated/deprecated/ -- Cheers Jorge.-

Nov. 18, 2013

Last couple of patches

by sgeerken＠dillo.org

Hi! On Mo, Nov 18, 2013, Jorge Arellano Cid wrote: > After changeset 1a8661485c0b and e40f77531b5e, the bookmarks > page is rendered with the largest width I've seen. As the patches > deal with table apportioning, probably there's a small bug lurking > there. > > I've also found another couple of test pages of mine (from my > table apportioning test set) that also show the effect. It happens with > tables using "width=AUTO with cells widths in percentages". This was actually meant as a "cosmetic" change, without changing functionality. Nevertheless, the recent commit should fix it, at least, the attached page works now. Sebastian

Nov. 18, 2013

Last couple of patches

by jcid＠dillo.org

Hi Sebastian, After changeset 1a8661485c0b and e40f77531b5e, the bookmarks page is rendered with the largest width I've seen. As the patches deal with table apportioning, probably there's a small bug lurking there. I've also found another couple of test pages of mine (from my table apportioning test set) that also show the effect. It happens with tables using "width=AUTO with cells widths in percentages". Attached it goes. -- Cheers Jorge.-

Nov. 18, 2013

socks proxy possible?

by jcid＠dillo.org

On Sat, Nov 02, 2013 at 11:37:27PM +0100, Johannes Hofmann wrote: > Hi, > > On Fri, Nov 01, 2013 at 01:24:00AM +0000, higuita wrote: > > Hi > > > > On Thu, 31 Oct 2013 11:25:18 +0100, Rudolf Sykora > > <rudolf.sykora at gmail.com> wrote: > > > I wanted to use dillo with a socks proxy (using ssh -D portnumber), > > > however, I was not successful. > > > > In the unix world, to use socks you usually need that the app > > support it... OR use a LD_LIBRARY_PATH preload trick to replace the > > normal network calls with socks one. Its usually called sockify a > > app. > > > > Dante socks have a command called tsocks that does that, just > > run "tsocks dillo" and dillo will support the socks proxy and work > > normally. > > Would it make sense to invest time into native socks support, or is > it ok to rely on tsocks or similar? +1 to document on using tsocks. Sockets are subtle and not easy to code in a portable way. -- Cheers Jorge.-

Nov. 4, 2013

socks proxy possible?

by higuita7＠yahoo.co.uk

Hi On Sat, 2 Nov 2013 23:37:27 +0100, Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > Would it make sense to invest time into native socks support, or is > it ok to rely on tsocks or similar? In my opinion, tsocks works very well, for those that have a socks proxy, it's normal to rely on it, at least on linux, *bsd and most other *nix. For windows its another story, i have no knowledge for something like tsocks for windows but a quick search returns the sockscap as a similar solution: http://www.socksproxychecker.com/sockscap.html So i think its enough to add a reference for this two solutions in the documentation for those that need socks support. Of course, others might have a different opinion :) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Nov. 4, 2013

socks proxy possible?

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Nov 01, 2013 at 01:24:00AM +0000, higuita wrote: > Hi > > On Thu, 31 Oct 2013 11:25:18 +0100, Rudolf Sykora > <rudolf.sykora at gmail.com> wrote: > > I wanted to use dillo with a socks proxy (using ssh -D portnumber), > > however, I was not successful. > > In the unix world, to use socks you usually need that the app > support it... OR use a LD_LIBRARY_PATH preload trick to replace the > normal network calls with socks one. Its usually called sockify a > app. > > Dante socks have a command called tsocks that does that, just > run "tsocks dillo" and dillo will support the socks proxy and work > normally. Would it make sense to invest time into native socks support, or is it ok to rely on tsocks or similar? Cheers, Johannes

Nov. 2, 2013

socks proxy possible?

by higuita7＠yahoo.co.uk

Hi On Thu, 31 Oct 2013 11:25:18 +0100, Rudolf Sykora <rudolf.sykora at gmail.com> wrote: > I wanted to use dillo with a socks proxy (using ssh -D portnumber), > however, I was not successful. In the unix world, to use socks you usually need that the app support it... OR use a LD_LIBRARY_PATH preload trick to replace the normal network calls with socks one. Its usually called sockify a app. Dante socks have a command called tsocks that does that, just run "tsocks dillo" and dillo will support the socks proxy and work normally. Good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Nov. 1, 2013

socks proxy possible?

by rudolf.sykora＠gmail.com

Hello, I wanted to use dillo with a socks proxy (using ssh -D portnumber), however, I was not successful. ( I did export http_proxy=127.0.0.1:portnumber and then ran dillo, but then it sais 'connecting' for any url given and nothing happens. ) Is this somehow possible? Thank you! Ruda

Oct. 31, 2013

Internationalizing user interface

by jcid＠dillo.org

On Wed, Oct 23, 2013 at 01:34:14PM +0200, Johannes Hofmann wrote: > On Wed, Oct 23, 2013 at 11:13:32AM +0200, Petr Pisar wrote: > > On Wed, Oct 23, 2013 at 10:07:09AM +0200, Johannes Hofmann wrote: > > > > > > I like the idea, but we need man-power to create translations and > > > keep them up to date. > > > > No, you don't need. The translations are not done by developers, but done > > by translators. > > Sure, I was just counting translator's man-power too :-) > > > > > Developer publishes updated dillo.pot template, translators send back > > translated message catalogues as <LANG_CODE>.po files. > > > > > Do we have numbers how this affects the memory consumption and > > > install-size? > > > > See /usr/share/locale/*/LC_MESSAGES in any Linux distribution. Some > > distributions allow users to select which language to support which saves > > theirs disk space too. > > > > The memory overhead is negligeble. Gettext mmaps binary version of translated > > catalogue and returns static string on each call. > > good > > > > > > Do we need a compile-time switch to disable it? > > > > The gettext m4 macros provides --{enable|disable}-nls configure option. > > also good > > > > > > How can we keep translation files in sync? > > > > > Register your project at any translations project and use its synchronization > > system. I like <http://translationproject.org/> which provides developers > > rsync interface. > > > > Or use just a mailing list to gather updated translations. Like mutt or gnupg > > does. I do not believe the will such a big traffic with Dillo. > > Ok, so I would suggest we try to get the infrastructure ready and > use the mailing list initially. Later we can switch to something > more fancy if necessary. IMHO the whole idea is worthwhile. It'd be good to test it and coordinate an eventual merge. It causes large trivial code changes that may difficult the merging of the floats branch and others, so it should be scheduled with care. The other important point is to check how our UI reacts to different string lenghts because this is not as automatic in FLTK as it was with GTK. -- Cheers Jorge.-

Oct. 23, 2013

Internationalizing user interface

by johannes.hofmann＠gmx.de

On Wed, Oct 23, 2013 at 11:13:32AM +0200, Petr Pisar wrote: > On Wed, Oct 23, 2013 at 10:07:09AM +0200, Johannes Hofmann wrote: > > > > I like the idea, but we need man-power to create translations and > > keep them up to date. > > No, you don't need. The translations are not done by developers, but done > by translators. Sure, I was just counting translator's man-power too :-) > > Developer publishes updated dillo.pot template, translators send back > translated message catalogues as <LANG_CODE>.po files. > > > Do we have numbers how this affects the memory consumption and > > install-size? > > See /usr/share/locale/*/LC_MESSAGES in any Linux distribution. Some > distributions allow users to select which language to support which saves > theirs disk space too. > > The memory overhead is negligeble. Gettext mmaps binary version of translated > catalogue and returns static string on each call. good > > > Do we need a compile-time switch to disable it? > > The gettext m4 macros provides --{enable|disable}-nls configure option. also good > > > How can we keep translation files in sync? > > > Register your project at any translations project and use its synchronization > system. I like <http://translationproject.org/> which provides developers > rsync interface. > > Or use just a mailing list to gather updated translations. Like mutt or gnupg > does. I do not believe the will such a big traffic with Dillo. Ok, so I would suggest we try to get the infrastructure ready and use the mailing list initially. Later we can switch to something more fancy if necessary. Johannes

Oct. 23, 2013

Internationalizing user interface

by petr.pisar＠atlas.cz

On Wed, Oct 23, 2013 at 10:07:09AM +0200, Johannes Hofmann wrote: > > I like the idea, but we need man-power to create translations and > keep them up to date. No, you don't need. The translations are not done by developers, but done by translators. Developer publishes updated dillo.pot template, translators send back translated message catalogues as <LANG_CODE>.po files. > Do we have numbers how this affects the memory consumption and > install-size? See /usr/share/locale/*/LC_MESSAGES in any Linux distribution. Some distributions allow users to select which language to support which saves theirs disk space too. The memory overhead is negligeble. Gettext mmaps binary version of translated catalogue and returns static string on each call. > Do we need a compile-time switch to disable it? The gettext m4 macros provides --{enable|disable}-nls configure option. > How can we keep translation files in sync? > Register your project at any translations project and use its synchronization system. I like <http://translationproject.org/> which provides developers rsync interface. Or use just a mailing list to gather updated translations. Like mutt or gnupg does. I do not believe the will such a big traffic with Dillo. -- Petr

Oct. 23, 2013

Internationalizing user interface

by johannes.hofmann＠gmx.de

On Wed, Oct 23, 2013 at 12:10:44AM +0200, corvid wrote: > Petr wrote: > > I notice Dillo is in English only, so I prepared an example how to > > internationalize the code using gettext. > > > > The initial patch is quite huge due to standard m4 macros supporting the > > gettext configuration: > > [snip] > > > 30 files changed, 5524 insertions(+), 39 deletions(-) > > > > I don't know what everything you want to track in the hg. > > > > The ABOUT-NLS, config.rpath m4/*, and maybe some files under po/ could get > > installed through ./autogen.sh by calling gettextize --force --no-changelog. > > > > My proof of concept shows internationalized and the localized into Czech > > language the `dillo --help' usage and the `File' menu in the GUI. > > > > Should I send the (possibly compressed) patch to this mailing list? > > > > If you liked the patch, I'm willing to walk through all the sources and mark > > all the stringing suitable for translation. > > I looked in the archive to refresh my memory on where everyone stood on > gettext. Jorge felt positively toward it in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008658.html > I was curious about it and tried a small experiment in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008685.html > And no one else expressed an opinion. So that's a good sign, anyway. I like the idea, but we need man-power to create translations and keep them up to date. Do we have numbers how this affects the memory consumption and install-size? Do we need a compile-time switch to disable it? How can we keep translation files in sync? Cheers, Johannes

Oct. 23, 2013

Internationalizing user interface

by petr.pisar＠atlas.cz

On Wed, Oct 23, 2013 at 12:10:44AM +0200, corvid wrote: > Petr wrote: > > I notice Dillo is in English only, so I prepared an example how to > > internationalize the code using gettext. > > > > The initial patch is quite huge due to standard m4 macros supporting the > > gettext configuration: > > [snip] > > > 30 files changed, 5524 insertions(+), 39 deletions(-) > > > > I don't know what everything you want to track in the hg. > > > > The ABOUT-NLS, config.rpath m4/*, and maybe some files under po/ could get > > installed through ./autogen.sh by calling gettextize --force --no-changelog. > > > > My proof of concept shows internationalized and the localized into Czech > > language the `dillo --help' usage and the `File' menu in the GUI. > > > > Should I send the (possibly compressed) patch to this mailing list? > > > > If you liked the patch, I'm willing to walk through all the sources and mark > > all the stringing suitable for translation. > > I looked in the archive to refresh my memory on where everyone stood on > gettext. Jorge felt positively toward it in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008658.html > I was curious about it and tried a small experiment in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008685.html > And no one else expressed an opinion. So that's a good sign, anyway. > > The convention here for large patches is to put them somewhere else and > give the url. > Here it is: <http://xpisar.wz.cz/dillo/dillo-i18n.diff>. -- Petr

Oct. 23, 2013

Internationalizing user interface

by corvid＠dillo.org

Petr wrote: > I notice Dillo is in English only, so I prepared an example how to > internationalize the code using gettext. > > The initial patch is quite huge due to standard m4 macros supporting the > gettext configuration: [snip] > 30 files changed, 5524 insertions(+), 39 deletions(-) > > I don't know what everything you want to track in the hg. > > The ABOUT-NLS, config.rpath m4/*, and maybe some files under po/ could get > installed through ./autogen.sh by calling gettextize --force --no-changelog. > > My proof of concept shows internationalized and the localized into Czech > language the `dillo --help' usage and the `File' menu in the GUI. > > Should I send the (possibly compressed) patch to this mailing list? > > If you liked the patch, I'm willing to walk through all the sources and mark > all the stringing suitable for translation. I looked in the archive to refresh my memory on where everyone stood on gettext. Jorge felt positively toward it in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008658.html I was curious about it and tried a small experiment in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008685.html And no one else expressed an opinion. So that's a good sign, anyway. The convention here for large patches is to put them somewhere else and give the url.

Oct. 22, 2013

Internationalizing user interface

by petr.pisar＠atlas.cz

Hello, I notice Dillo is in English only, so I prepared an example how to internationalize the code using gettext. The initial patch is quite huge due to standard m4 macros supporting the gettext configuration: ABOUT-NLS | 1282 ++++++++++++++++++++++++++++++++++++++++++++++++ Makefile.am | 6 +- config.rpath | 690 +++++++++++++++++++++++++ configure.ac | 3 +- m4/gettext.m4 | 401 +++++++++++++++ m4/iconv.m4 | 268 ++++++++++ m4/lib-ld.m4 | 119 ++++ m4/lib-link.m4 | 777 +++++++++++++++++++++++++++++ m4/lib-prefix.m4 | 224 ++++++++ m4/nls.m4 | 32 + m4/po.m4 | 452 ++++++++++++++++ m4/progtest.m4 | 91 +++ po/Makefile.in.in | 453 ++++++++++++++++ po/Makevars | 53 + po/POTFILES.in | 4 + po/Rules-quot | 47 + po/boldquot.sed | 10 + po/cs.po | 163 ++++++ po/en at boldquot.header | 25 + po/en at quot.header | 22 + po/insert-header.sin | 23 + po/quot.sed | 6 + po/remove-potcdate.sin | 19 + src/Makefile.am | 2 + src/dillo.cc | 64 +- src/gettext.h | 287 ++++++++++ src/menu.cc | 13 +- src/msg.h | 3 +- src/nls.h | 17 + src/ui.cc | 7 +- 30 files changed, 5524 insertions(+), 39 deletions(-) I don't know what everything you want to track in the hg. The ABOUT-NLS, config.rpath m4/*, and maybe some files under po/ could get installed through ./autogen.sh by calling gettextize --force --no-changelog. My proof of concept shows internationalized and the localized into Czech language the `dillo --help' usage and the `File' menu in the GUI. Should I send the (possibly compressed) patch to this mailing list? If you liked the patch, I'm willing to walk through all the sources and mark all the stringing suitable for translation. -- Petr

Oct. 21, 2013

Image backgrounds

by sgeerken＠dillo.org

Hi! At <http://flpsed.org/hgweb/dillo_background_image>, you'll find a version of dillo which supports background images. 'Background- attachement' is missing, which I'll postpone, but the rest is nearly complete. I'll soon resume my work on floats. Sebastian

Oct. 14, 2013

patch: binding to add bookmark

by jcid＠dillo.org

On Mon, Sep 16, 2013 at 06:20:38PM +0200, corvid wrote: > Another simple one from the bug tracker. I don't use bookmarks heavily > enough to have much need for this, but I can see that it could be > convenient. > It looks like the user wants the feature as a workaround, so he can quickly bookmark the tabs he has open, with a view to recover them later. See BUG #1136, #1137 and #1139. IMHO, it would be great to contact the submitter to understand the real problem (or use case) he has, and try to aim directly at it. -- Cheers Jorge.-

Sept. 20, 2013

patch: binding to add bookmark

by corvid＠dillo.org

Another simple one from the bug tracker. I don't use bookmarks heavily enough to have much need for this, but I can see that it could be convenient.

Sept. 16, 2013

patch: show_ui_tooltip

by jcid＠dillo.org

On Fri, Sep 13, 2013 at 09:08:23AM +0200, Johannes Hofmann wrote: > On Thu, Sep 12, 2013 at 04:14:04PM +0200, Sebastian Geerken wrote: > > On Mi, Sep 11, 2013, Johannes Hofmann wrote: > > > On Wed, Sep 11, 2013 at 05:34:06PM +0200, corvid wrote: > > > > Someone in the bug tracker was asking about turning off the ui's tooltips. > > > > > > What about using the existing prefs.show_tooltip variable for both > > > types of tooltips? I would guess that someone either likes / wants > > > tooltips or not independent of whether it's for the UI or the page > > > contents. > > > > Tooltips are useful to get an idea what an (simple to recognize, but > > otherwise per se unrelated to the meaning) icon is for. (At least for > > me, the text "Reload" makes much more sense than two bent arrows > > pointing to each other's tail). > > > > After some while, a user remembers the icon, so she does not need the > > text anymore; and I guess that icons are faster to realise than text. > > On the other hand, this argument does not count for (new) web pages, > > where the meaning of the icons is not yet known. > > > > For this reason, my opinion is that a distinction is not completely > > pointless. > > Ok, I'm fine with two separate variables too. +1 -- Cheers Jorge.-

Sept. 13, 2013

patch: show_ui_tooltip

by johannes.hofmann＠gmx.de

On Thu, Sep 12, 2013 at 04:14:04PM +0200, Sebastian Geerken wrote: > On Mi, Sep 11, 2013, Johannes Hofmann wrote: > > On Wed, Sep 11, 2013 at 05:34:06PM +0200, corvid wrote: > > > Someone in the bug tracker was asking about turning off the ui's tooltips. > > > > What about using the existing prefs.show_tooltip variable for both > > types of tooltips? I would guess that someone either likes / wants > > tooltips or not independent of whether it's for the UI or the page > > contents. > > Tooltips are useful to get an idea what an (simple to recognize, but > otherwise per se unrelated to the meaning) icon is for. (At least for > me, the text "Reload" makes much more sense than two bent arrows > pointing to each other's tail). > > After some while, a user remembers the icon, so she does not need the > text anymore; and I guess that icons are faster to realise than text. > On the other hand, this argument does not count for (new) web pages, > where the meaning of the icons is not yet known. > > For this reason, my opinion is that a distinction is not completely > pointless. Ok, I'm fine with two separate variables too. Johannes

Sept. 13, 2013

patch: show_ui_tooltip

by sgeerken＠dillo.org

On Mi, Sep 11, 2013, Johannes Hofmann wrote: > On Wed, Sep 11, 2013 at 05:34:06PM +0200, corvid wrote: > > Someone in the bug tracker was asking about turning off the ui's tooltips. > > What about using the existing prefs.show_tooltip variable for both > types of tooltips? I would guess that someone either likes / wants > tooltips or not independent of whether it's for the UI or the page > contents. Tooltips are useful to get an idea what an (simple to recognize, but otherwise per se unrelated to the meaning) icon is for. (At least for me, the text "Reload" makes much more sense than two bent arrows pointing to each other's tail). After some while, a user remembers the icon, so she does not need the text anymore; and I guess that icons are faster to realise than text. On the other hand, this argument does not count for (new) web pages, where the meaning of the icons is not yet known. For this reason, my opinion is that a distinction is not completely pointless. Sebastian

Sept. 12, 2013

patch: show_ui_tooltip

by Johannes.Hofmann＠gmx.de

On Wed, Sep 11, 2013 at 05:34:06PM +0200, corvid wrote: > Someone in the bug tracker was asking about turning off the ui's tooltips. What about using the existing prefs.show_tooltip variable for both types of tooltips? I would guess that someone either likes / wants tooltips or not independent of whether it's for the UI or the page contents. Cheers, Johannes

Sept. 11, 2013

patch: show_ui_tooltip

by corvid＠dillo.org

Someone in the bug tracker was asking about turning off the ui's tooltips.

Sept. 11, 2013

hypenator.cc errors

by sgeerken＠dillo.org

On Fr, Sep 06, 2013, Jorge Arellano Cid wrote: > On Fri, Sep 06, 2013 at 11:46:10AM +0200, Sebastian Geerken wrote: > > > > [...] > > > > > > Thinking about it again, variable length arrays are a feature of C, > > > but not of C++, although it seems that most C++ compilers support it. > > > Since this is a nice feature, but standard C++ should be supported, > > > I've thought of testing it by the configure script, and then hide two > > > different implementations behind a macro. See attached patch, which > > > should be applied to the current hg repository. > > > > > > What do you think? [...] > > > > Third round: I agree with Jorge that this is quite too complex; and > > profiling shows no performance gain of using the heap over using the > > stack, so I've replaced it by new and delete. Cris: please test the > > latest version from hg, it should compile now. > > There's a memory problem with the sizeof(buf) because it returns > the pointer size, not the array length! > > Please see the attached test case for details. > > (Compile with: g++ -W -Wall size3.cc -o size3) That's why paths are limited to 7 characters. :-) Loading hyphenation patterns for language 'de' from '/usr/lo' and exceptions from '/usr/lo' ... Anyway, fixed now. Sebastian

Sept. 6, 2013

hypenator.cc errors

by jcid＠dillo.org

On Fri, Sep 06, 2013 at 11:46:10AM +0200, Sebastian Geerken wrote: > > > [...] > > > > Thinking about it again, variable length arrays are a feature of C, > > but not of C++, although it seems that most C++ compilers support it. > > Since this is a nice feature, but standard C++ should be supported, > > I've thought of testing it by the configure script, and then hide two > > different implementations behind a macro. See attached patch, which > > should be applied to the current hg repository. > > > > What do you think? [...] > > Third round: I agree with Jorge that this is quite too complex; and > profiling shows no performance gain of using the heap over using the > stack, so I've replaced it by new and delete. Cris: please test the > latest version from hg, it should compile now. There's a memory problem with the sizeof(buf) because it returns the pointer size, not the array length! Please see the attached test case for details. (Compile with: g++ -W -Wall size3.cc -o size3) -- Cheers Jorge.-

Sept. 6, 2013

Fwd: Re: hypenator.cc errors

by sgeerken＠dillo.org

On Mi, Sep 04, 2013, Chris Sorenson wrote: > > > > 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? Yes, this patch is against the latest hg version; things may have changed there. Sebastian

Sept. 6, 2013

hypenator.cc errors

by sgeerken＠dillo.org

> > [...] > > Thinking about it again, variable length arrays are a feature of C, > but not of C++, although it seems that most C++ compilers support it. > Since this is a nice feature, but standard C++ should be supported, > I've thought of testing it by the configure script, and then hide two > different implementations behind a macro. See attached patch, which > should be applied to the current hg repository. > > What do you think? [...] Third round: I agree with Jorge that this is quite too complex; and profiling shows no performance gain of using the heap over using the stack, so I've replaced it by new and delete. Cris: please test the latest version from hg, it should compile now. I've tried to force g++ to raise an error in this case, by using this example: --- #include <stdlib.h> int main() { int n = rand() % 10 + 1; char c[n]; } --- but both "g++ -std=c++98 test.cc" and "g++ -std=c++11 test.cc" do not complain. Does someone have an idea? ("g++ --version" => "g++ (Debian 4.7.2-5) 4.7.2") Sebastian

Sept. 6, 2013

hypenator.cc errors

by csoren＠isd.net

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

Sept. 5, 2013

Fwd: Re: hypenator.cc errors

by csoren＠isd.net

> > 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?

Sept. 5, 2013

hypenator.cc errors

by sgeerken＠dillo.org

On Mo, Sep 02, 2013, Chris Sorenson wrote: > > 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! Thinking about it again, variable length arrays are a feature of C, but not of C++, although it seems that most C++ compilers support it. Since this is a nice feature, but standard C++ should be supported, I've thought of testing it by the configure script, and then hide two different implementations behind a macro. See attached patch, which should be applied to the current hg repository. What do you think? Cris: If you run ./autogen.sh && ./configure, you should see a line: checking for support of variable length arrays in C++... no Is this correct? Sebastian

Sept. 4, 2013