- Dillo-dev - lists.mailman3.com

are we officially at feature freeze yet?

by corvid＠lavabit.com

Jorge wrote: > On Mon, Aug 01, 2011 at 04:08:32PM +0000, corvid wrote: > > Jorge wrote: > > > [ok] UI_TEMPORARILY_SHOW_PANELS > > > > Escape isn't hiding the findbar now. > > I try here with: > > Viewport Panels Focus Works > -------------------------------------------------------- > Empty Hidden Findbar OK > Empty Shown Location OK > Empty Shown Findbar OK > > HTML page Shown Findbar OK > HTML page Shown Main OK > HTML page Shown Location OK > HTML page Hidden Findbar OK > HTML page Hidden Main OK > -------------------------------------------------------- > > and it works for every listed case. I made a mistake. Sorry!

Aug. 1, 2011

Re: Debian Packages of 2.2.1

by devidfil＠gmail.com

I'll upload the package in Debian as soon as dillo will be released ;) Devid On Mon, Aug 1, 2011 at 7:41 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi Axel, > > On Mon, Aug 01, 2011 at 12:38:28PM +0200, Axel Beckert wrote: >> Hi Klaumi, hi Jorge, >> >> Klaumi Klingsporn schrieb am Sun, Jul 31, 2011 at 03:32:57PM +0200: >> > only to let you know: I built some Debian packages of the stable >> > release 2.2.1 today which can be found at: >> >> Looks as it the binary package is statically linked against FLTK 2 >> which is not part of the source package nor in the build-dependencies, >> i.e. it must be installed manually to be able to build the package. >> Ugly, but understable. >> >> FLTK 2 never was in Debian mainly because first it had a non-free >> license, and when that was fixed it became deprecated. > > ?Yes, we worked on the license issue with the FLTK team... > >> Being an >> alpha-version was way less the problem. Such things can go into Debian >> Experimental and often also do. > > ?Sure, and policy was the main obstacle for all distros. > (absolutely understandable to my taste). > >> > [...] >> > After doing that I saw, that Axel Beckert just built packages of >> > dillo3 for experimental. >> >> Yep, did that at DebCamp between the timestamp of the 2.2.1 ChangeLog >> (17.7., see http://hg.dillo.org/dillo/file/tip/ChangeLog) and when it >> was uploaded (26.7. according to http://www.dillo.org/download/) So >> the release of 2.2.1 was new to me. (I really should subscribe to the >> Dillo ML. :-) > > ?Or you can subscribe to freshmeat for the announcements. > (and avoid the mailing-list traffic). > >> I packaged Dillo 3 as that's the only Dillo version which currently >> compiles in Debian, i.e. with all build-dependencies available in >> Debian. >> >> > So hopefully Dillo will return to Debian in near future. >> >> As soon as Dillo 3 has been released I plan to upload it to unstable, >> too. FLTK 1.3 is in unstable only for a few weeks yet, too, as the >> final release happened there just recently, too. It was in >> experimental for half a year or so before. > > ?Good! > > ?We have dillo-3.0 scheduled for release in August. > > ?(BTW, fltk-1.3 already made it into squeeze). > > ?Thanks for the update. > > -- > ?Cheers > ?Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 1, 2011

Re: Debian Packages of 2.2.1

by sas＠321.hu

On Mon, Aug 1, 2011 at 7:41 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > ?(BTW, fltk-1.3 already made it into squeeze). wheezy :-) > ?Thanks for the update. Thx for work, pls gettextize (or i14e ;-)) Dillo - thx a lot! -- SZERV?C Attila - composer http://google.com/search?q=szerv?c

Aug. 1, 2011

Re: Debian Packages of 2.2.1

by jcid＠dillo.org

Hi Axel, On Mon, Aug 01, 2011 at 12:38:28PM +0200, Axel Beckert wrote: > Hi Klaumi, hi Jorge, > > Klaumi Klingsporn schrieb am Sun, Jul 31, 2011 at 03:32:57PM +0200: > > only to let you know: I built some Debian packages of the stable > > release 2.2.1 today which can be found at: > > Looks as it the binary package is statically linked against FLTK 2 > which is not part of the source package nor in the build-dependencies, > i.e. it must be installed manually to be able to build the package. > Ugly, but understable. > > FLTK 2 never was in Debian mainly because first it had a non-free > license, and when that was fixed it became deprecated. Yes, we worked on the license issue with the FLTK team... > Being an > alpha-version was way less the problem. Such things can go into Debian > Experimental and often also do. Sure, and policy was the main obstacle for all distros. (absolutely understandable to my taste). > > [...] > > After doing that I saw, that Axel Beckert just built packages of > > dillo3 for experimental. > > Yep, did that at DebCamp between the timestamp of the 2.2.1 ChangeLog > (17.7., see http://hg.dillo.org/dillo/file/tip/ChangeLog) and when it > was uploaded (26.7. according to http://www.dillo.org/download/) So > the release of 2.2.1 was new to me. (I really should subscribe to the > Dillo ML. :-) Or you can subscribe to freshmeat for the announcements. (and avoid the mailing-list traffic). > I packaged Dillo 3 as that's the only Dillo version which currently > compiles in Debian, i.e. with all build-dependencies available in > Debian. > > > So hopefully Dillo will return to Debian in near future. > > As soon as Dillo 3 has been released I plan to upload it to unstable, > too. FLTK 1.3 is in unstable only for a few weeks yet, too, as the > final release happened there just recently, too. It was in > experimental for half a year or so before. Good! We have dillo-3.0 scheduled for release in August. (BTW, fltk-1.3 already made it into squeeze). Thanks for the update. -- Cheers Jorge.-

Aug. 1, 2011

Re: Debian Packages of 2.2.1

by jcid＠dillo.org

Hi, On Sun, Jul 31, 2011 at 03:32:57PM +0200, Klaumi Klingsporn wrote: > Hi folks, > only to let you know: I built some Debian packages of the stable > release 2.2.1 today which can be found at: > > http://apt.klaumikli.de/testing > > After doing that I saw, that Axel Beckert just built packages of dillo3 > for experimental. So hopefully Dillo will return to Debian in near > future. Excellent. Our idea is to get back into Debian with our soon to be released dillo-3.0 (based in fltk-1.3 which already made it into squeeze). > Thanks for the nice program! :-) -- Cheers Jorge.-

Aug. 1, 2011

are we officially at feature freeze yet?

by jcid＠dillo.org

On Mon, Aug 01, 2011 at 04:08:32PM +0000, corvid wrote: > Jorge wrote: > > [ok] UI_TEMPORARILY_SHOW_PANELS > > Escape isn't hiding the findbar now. I try here with: Viewport Panels Focus Works -------------------------------------------------------- Empty Hidden Findbar OK Empty Shown Location OK Empty Shown Findbar OK HTML page Shown Findbar OK HTML page Shown Main OK HTML page Shown Location OK HTML page Hidden Findbar OK HTML page Hidden Main OK -------------------------------------------------------- and it works for every listed case. -- Cheers Jorge.-

Aug. 1, 2011

are we officially at feature freeze yet?

by corvid＠lavabit.com

Jorge wrote: > [ok] UI_TEMPORARILY_SHOW_PANELS Escape isn't hiding the findbar now.

Aug. 1, 2011

are we officially at feature freeze yet?

by jcid＠dillo.org

Hi, Now we have: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ ] the panel problems when resizing from very small. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ ] something other than "ctab%d" for initial tab label. [ ] single close tab button with tooltip. [ ] valgrind logs (needs case by case detail in this list) [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() Just committed patches for the last three items! -- Cheers Jorge.-

Aug. 1, 2011

Re: What's pending in dillo-3.0 for a release

by dennisn＠dennisn.dyndns.org

On Fri, 29 Jul 2011 16:12:12 -0400, Jorge Arellano Cid wrote: > On Fri, Jul 08, 2011 at 10:25:04AM -0400, Dennis Nezic wrote: > > On Wed, 29 Jun 2011 11:37:21 -0400, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > Fltk-1.3 is out there, and we've worked our pending issues list. > > > What's still pending? > > > > /me hopes the Choice5-popup dialog, regarding unverified > > certificates, has been fixed. And/or perhaps an option similar to > > wget's "--no-check-certificate" is implemented :). > > Please check the just committed patch for this (BUG#868). > > Quoting the log: > > "Workaround: request to only check the root URL's certificate (https). Would it save non-verified ones -- or would it ask during every runtime? :)

Aug. 1, 2011

valgrind & undeleted windows

by corvid＠lavabit.com

http://starurchin.org/dillo/valgrind/5125438759603857c01a7368aa40cd64873f5e… appears to have to do with the // TODO: free memory //delete window(); in CustTabs::remove_tab()

Aug. 1, 2011

valgrind & Cancel the expected URL after offering a download (BUG#982)

by corvid＠lavabit.com

This one appears to stem from that fix http://starurchin.org/dillo/valgrind/6120526f753eba6e5646cbfe382a68d971c39d…

Aug. 1, 2011

style bug, perhaps

by corvid＠lavabit.com

I reload the following, and the link border around the first image disappears. If the problem's in the style attr copying/comparison/etc., I'm failing to see it. I can see that the style has border type of none and border width of 0. I started to try to watch ":link img, :visited img {border: 1px solid}" get applied, but... <html> <body> <a href="whatever.html"> <img src="whatever.jpg"> </a> <button type='submit' name='button'"> <img src="something.jpg" alt="Search"> </button> </body> </html> BTW, Jeremy's valgrind logs have an interesting variety of 1.3 bugs for us now.

Aug. 1, 2011

Support for title attribute in tooltips

by Johannes.Hofmann＠gmx.de

On Sat, Jul 30, 2011 at 11:38:17PM +0000, corvid wrote: > Rob wrote: > > You are all likely to cringe in horror when you see what I have been > > up to today. I basically wanted to add hover/tooltip functionality > > for elements which contain the title attribute. > > I remember discussing this with Johannes, and I think he had some reason > that he was reluctant to check for the title attr there...? I hope he > remembers because I can't seem to find record of it. I guess you are refering to this discussion: On Wed, Sep 30, 2009 at 05:09:10PM +0200, Johannes Hofmann wrote: > On Wed, Sep 30, 2009 at 04:31:42AM +0000, corvid wrote: > > Johannes wrote: > > > On Sun, Sep 27, 2009 at 06:47:31PM +0000, corvid wrote: > > > > Also, I tried moving the title attribute check > > > > to Html_parse_common_attrs because it's part > > > > of %coreattrs (as the html spec puts it), and > > > > styleengine's style0() gave me an assertion > > > > because now I'm doing too much style computation. > > > > What should I do in light of this? > > > > > > Currently you can call StyleEngine::setNonCssHints() only once per > > > element. So we would need to pass the CssPropertyList that holds the > > > NonCssHints until we have collected them all in html.cc and then set > > > them once. > > > > Another thing to think about if we change the attr stuff > > around is that gprof shows me > > (unoptimized, auto img loading off, remote css off, > > embedded css on) > > > > % cumulative self self total > > time seconds seconds calls ms/call ms/call name > > 7.63 2.26 2.26 259353 0.01 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) > > 4.23 3.51 1.25 rgb_to_565d(unsigned char const*, unsigned char*, int, int) > > 2.40 4.22 0.71 329489 0.00 0.00 dw::Textblock::wordWrap(int) > > 2.27 4.89 0.67 194573 0.00 0.01 CssStyleSheet::apply(CssPropertyList*, Doctree*, DoctreeNode const*) > > 1.93 5.46 0.57 382 1.49 9.67 Html_write_raw(DilloHtml*, char*, int, int) > > 1.62 5.94 0.48 369132 0.00 0.00 lout::object::ConstString::hashValue(char const*) > > 1.32 6.33 0.39 149410 0.00 0.01 dw::core::Widget::queueResize(int, bool) > > 1.22 6.69 0.36 745628 0.00 0.00 Html_tag_compare(char const*, char const*) > > .. > > > > I remember Jorge saying something once about having experimented > > with a more sophisticated/complicated get_attr system long ago > > but it not having been worth the complexity at the time. > > > > Ah yes, I also thought about parsing attrs in one go and storing the > result in some data structure. > Whether this is really faster than the current approach needs to be > tested. I'm not opposed to check for a title attribute in every element, we just need to make sure it doesn't slow things down too much. Cheers, Johannes

July 31, 2011

moveToWidget

by jcid＠dillo.org

On Sat, Jul 30, 2011 at 02:04:42PM +0000, corvid wrote: > > If there's a link at the very top of the viewport and you move the > mouse cursor up to the panel, the status output isn't cleared as you > leave. Ah, yes. The attached patch fixes it. The interesting part is the amount of code that can be disabled in Layout::leaveNotify(). I've tested it for some time and have found no regressions so far. Please test. -- Cheers Jorge.-

July 31, 2011

Support for title attribute in tooltips

by corvid＠lavabit.com

Rob wrote: > > I remember discussing this with Johannes, and I think he had some reason > > that he was reluctant to check for the title attr there...? I hope he > > remembers because I can't seem to find record of it. > > > > BTW, strictly speaking, we shouldn't be calling Html_parse_common_attrs() > > for every element because I believe there were a few that don't have > > %coreattrs under ATTLIST in the spec. > > Of course you are right. I was too eager to send something in, and > was really swimming over my head. Going back to > Html_parse_common_attrs(), it is plain that this is for all elements > having common attributes, whereas there are a handful of elements that > do not allow for the title attribute, and are therefore excluded. > I'll go back to learning how this thing works, and hopefully Johannes > will have something to add about the conversation you mentioned in the > meantime. Well, it's equally true of the attrs already in there -- id, class, and style, so it's not necessarily a bad place. The declaration or whatever goes: <!ENTITY % coreattrs "id ID #IMPLIED -- document-wide unique id -- class CDATA #IMPLIED -- space-separated list of classes -- style %StyleSheet; #IMPLIED -- associated style info -- title %Text; #IMPLIED -- advisory title --" >

July 31, 2011

Support for title attribute in tooltips

by mr_semantics＠hotmail.com

> I remember discussing this with Johannes, and I think he had some reason > that he was reluctant to check for the title attr there...? I hope he > remembers because I can't seem to find record of it. > > BTW, strictly speaking, we shouldn't be calling Html_parse_common_attrs() > for every element because I believe there were a few that don't have > %coreattrs under ATTLIST in the spec. Of course you are right. I was too eager to send something in, and was really swimming over my head. Going back to Html_parse_common_attrs(), it is plain that this is for all elements having common attributes, whereas there are a handful of elements that do not allow for the title attribute, and are therefore excluded. I'll go back to learning how this thing works, and hopefully Johannes will have something to add about the conversation you mentioned in the meantime. Regards, Rob

July 31, 2011

Support for title attribute in tooltips

by corvid＠lavabit.com

Rob wrote: > You are all likely to cringe in horror when you see what I have been > up to today. I basically wanted to add hover/tooltip functionality > for elements which contain the title attribute. I remember discussing this with Johannes, and I think he had some reason that he was reluctant to check for the title attr there...? I hope he remembers because I can't seem to find record of it. BTW, strictly speaking, we shouldn't be calling Html_parse_common_attrs() for every element because I believe there were a few that don't have %coreattrs under ATTLIST in the spec.

July 31, 2011

Support for title attribute in tooltips

by mr_semantics＠hotmail.com

You are all likely to cringe in horror when you see what I have been up to today. I basically wanted to add hover/tooltip functionality for elements which contain the title attribute. I think I achieved that with the following code: diff -r 49c3e24bf746 dpi/downloads.cc --- a/dpi/downloads.cc Fri Jul 29 20:19:08 2011 -0400 +++ b/dpi/downloads.cc Sat Jul 30 18:58:38 2011 -0400 @@ -516,7 +516,7 @@ // FSM to remove wget's "dot-progress" (i.e. "^ " || "^[0-9]+K") q = log_text + log_len; - for (p = esc_str; (p - esc_str) < esc_len; ++p) { + for (p = esc_str; (size_t)(p - esc_str) < esc_len; ++p) { switch (log_state) { case ST_newline: if (*p == ' ') { diff -r 49c3e24bf746 src/html.cc --- a/src/html.cc Fri Jul 29 20:19:08 2011 -0400 +++ b/src/html.cc Sat Jul 30 18:58:38 2011 -0400 @@ -1788,7 +1788,6 @@ html->styleEngine->backgroundStyle()->backgroundColor->getColor()); } - S_TOP(html)->parse_mode = DILLO_HTML_PARSE_MODE_BODY; } @@ -3455,6 +3454,13 @@ html->styleEngine->setStyle (attrbuf); } + if (prefs.show_tooltip && + (attrbuf = a_Html_get_attr(html, tag, tagsize, "title"))) { + + html->styleEngine->setNonCssHint (PROPERTY_X_TOOLTIP, CSS_TYPE_STRING, + attrbuf); + } + } /* The real ugliness is here: http://www3.sympatico.ca/rsquared/lib/dillo/title.html :P I am not done yet, and I have some ideas of some other little things I can do. But first I want to check with you fellows if you think this is on the right track. I hate to do a bunch of code that works, but doesn't "work" for the rest of you for whatever reason. Regards, Rob

July 31, 2011

Segfault at <CTRL> s

by obeythepenguin＠gmail.com

On Sat, 30 Jul 2011 17:18:53 -0400, corvid <corvid(a)lavabit.com> wrote: > Staying away from the google monster when reasonably possible seems most > consistent with the Dillo project's objectives. > > (To be fair, on one hand, the duckduckgo guy talks, in the context of > that project, a lot about privacy and such, but when I've read about what > he's been up to in general, he sounds kind of > rah-rah-hacker-news-let's-sell- > a-start-up-to-a-huge-company-and-be-rich, like he knows the talk to > talk.) You might consider Scroogle (http://www.scroogle.org) which doesn't filter results and isn't a buzzword-savvy startup. As an added bonus, it uses simple HTML code that renders quite nicely in Dillo. :-) Frankly, though, I think a lot of it is just paranoia. Google does push the boundaries of what's acceptable from time to time, and I maintain a healthy skepticism, but I don't outright distrust them. Anyway, at least they're established, unlike duckduckgo: as the saying goes, you don't trade the devil you know for the devil you don't know. ~Benjamin

July 31, 2011

Segfault at <CTRL> s

by corvid＠lavabit.com

Benjamin wrote: > On Sat, 30 Jul 2011 15:57:20 -0400, Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > > Yes, after trying both, I strongly tend to a non-filtered search. > > > > I was about to ask the same question. Personally, after all > >these months, > >I'm all for making non-filtered duckduckgo our default: > > > > search_url="http://duckduckgo.com/html?kp=-1&q=%s" > > > > (we can move google somewhere after it). > > Of course, then you risk frustrating users who want/expect Google as > the default. > > I always set the defaults in my software to things the average user > would want or expect, even if it differs from my own preferences -- > if I want to change it, I can set it in my personal configuration. > The way I see it, I'm just a software developer; I'm here to write > useful code, not to inflict my way of doing things on the world. Staying away from the google monster when reasonably possible seems most consistent with the Dillo project's objectives. (To be fair, on one hand, the duckduckgo guy talks, in the context of that project, a lot about privacy and such, but when I've read about what he's been up to in general, he sounds kind of rah-rah-hacker-news-let's-sell- a-start-up-to-a-huge-company-and-be-rich, like he knows the talk to talk.)

July 30, 2011

Segfault at <CTRL> s

by obeythepenguin＠gmail.com

On Sat, 30 Jul 2011 15:57:20 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Yes, after trying both, I strongly tend to a non-filtered search. > > I was about to ask the same question. Personally, after all these > months, > I'm all for making non-filtered duckduckgo our default: > > search_url="http://duckduckgo.com/html?kp=-1&q=%s" > > (we can move google somewhere after it). Of course, then you risk frustrating users who want/expect Google as the default. I always set the defaults in my software to things the average user would want or expect, even if it differs from my own preferences -- if I want to change it, I can set it in my personal configuration. The way I see it, I'm just a software developer; I'm here to write useful code, not to inflict my way of doing things on the world. Just a thought, ~Benjamin

July 30, 2011

Segfault at <CTRL> s

by jcid＠dillo.org

On Sat, Jul 30, 2011 at 06:44:11PM +0000, corvid wrote: > Jorge wrote: > > BTW, from some time I'm using duckduckgo (see dillorc) as my > > default search engine. It has served me very well, and recently > > discovered it also has plenty of handy macros: > > Do you think we should add to its search string to disable safe search? > At least in English, it likes to take out anything that can be construed > as a rude word, which irritates me -- or sometimes you look up a quotation > that does have strong language in it, and it should just give the results > instead of acting like you're doing something immoral. Yes, after trying both, I strongly tend to a non-filtered search. I was about to ask the same question. Personally, after all these months, I'm all for making non-filtered duckduckgo our default: search_url="http://duckduckgo.com/html?kp=-1&q=%s" (we can move google somewhere after it). -- Cheers Jorge.-

July 30, 2011

Segfault at <CTRL> s

by corvid＠lavabit.com

Jorge wrote: > BTW, from some time I'm using duckduckgo (see dillorc) as my > default search engine. It has served me very well, and recently > discovered it also has plenty of handy macros: Do you think we should add to its search string to disable safe search? At least in English, it likes to take out anything that can be construed as a rude word, which irritates me -- or sometimes you look up a quotation that does have strong language in it, and it should just give the results instead of acting like you're doing something immoral.

July 30, 2011

Segfault at <CTRL> s

by jcid＠dillo.org

On Sat, Jul 30, 2011 at 09:40:29AM +0200, Alexander Voigt wrote: > Hi Jorge and Corvid. > > On Fri, Jul 29, 2011 at 08:24:30PM -0400, Jorge Arellano Cid wrote: > > Please try the current repo (it has a better patch). > > Thank you for the fast reply. The current repository fixes the > segfault for me. Good. > (By the way, the idea of switchable search engines > is great!) Thanks. This is the first positive feedback I get so far on it. I'm a bit surprised on the lack of them given the flexibility of the feature. BTW, from some time I'm using duckduckgo (see dillorc) as my default search engine. It has served me very well, and recently discovered it also has plenty of handy macros: http://duckduckgo.com/bang.html (just in case you feel like experimenting). -- Cheers Jorge.-

July 30, 2011

moveToWidget

by corvid＠lavabit.com

If there's a link at the very top of the viewport and you move the mouse cursor up to the panel, the status output isn't cleared as you leave.

July 30, 2011

dpi/downloads.cc patch

by corvid＠lavabit.com

Rob wrote: > I built the latest version, and I can confirm that Jorges patch for > the search dialogue seems to be working nicely. When I built it > though, I got a warning from Clang. The following seems to quiet the > warning in Clang, and does not seem to generate any issues with gcc > for the compile: Committed.

July 30, 2011

dpi/downloads.cc patch

by mr_semantics＠hotmail.com

Hello all, I have been away for a bit, and had to catch up with some of the mail on the list. Looks like you are moving things along quite nicely! I built the latest version, and I can confirm that Jorges patch for the search dialogue seems to be working nicely. When I built it though, I got a warning from Clang. The following seems to quiet the warning in Clang, and does not seem to generate any issues with gcc for the compile: diff -r 49c3e24bf746 dpi/downloads.cc --- a/dpi/downloads.cc Fri Jul 29 20:19:08 2011 -0400 +++ b/dpi/downloads.cc Sat Jul 30 08:19:02 2011 -0400 @@ -516,7 +516,7 @@ // FSM to remove wget's "dot-progress" (i.e. "^ " || "^[0-9]+K") q = log_text + log_len; - for (p = esc_str; (p - esc_str) < esc_len; ++p) { + for (p = esc_str; (size_t)(p - esc_str) < esc_len; ++p) { switch (log_state) { case ST_newline: if (*p == ' ') { Regards, Rob

July 30, 2011

Segfault at <CTRL> s

by Hole.destructor＠gmx.de

Hi Jorge and Corvid. On Fri, Jul 29, 2011 at 08:24:30PM -0400, Jorge Arellano Cid wrote: > Please try the current repo (it has a better patch). Thank you for the fast reply. The current repository fixes the segfault for me. (By the way, the idea of switchable search engines is great!) Kind regards, Alexander

July 30, 2011

Segfault at <CTRL> s

by jcid＠dillo.org

On Fri, Jul 29, 2011 at 07:02:17PM -0400, Jorge Arellano Cid wrote: > On Sat, Jul 30, 2011 at 12:14:30AM +0200, Alexander Voigt wrote: > > Dear Dillo developers, > > > > since some days I get a segfault when starting the web search via > > <CTRL>s (using the dillo 3.0 trunk). Here is the backtrace: > > [...] > > Does this fix it? > > dialog.cc:167 > > - if (a_Misc_parse_search_url(source, &label, &url) < 0) > + if (!source || a_Misc_parse_search_url(source, &label, &url) < 0) Please try the current repo (it has a better patch). -- Cheers Jorge.-

July 30, 2011

Segfault at <CTRL> s

by jcid＠dillo.org

On Sat, Jul 30, 2011 at 12:14:30AM +0200, Alexander Voigt wrote: > Dear Dillo developers, > > since some days I get a segfault when starting the web search via > <CTRL>s (using the dillo 3.0 trunk). Here is the backtrace: > > > $ gdb ./dillo > GNU gdb (GDB) 7.0.1-debian > Copyright (C) 2009 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 "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /PATH/TO/DILLO/dillo...done. > (gdb) r > Starting program: /PATH/TO/DILLO/dillo > [Thread debugging using libthread_db enabled] > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > Nav_open_url: new url='http://www.google.de' > [New Thread 0x7ffff5111700 (LWP 21693)] > Dns_server [0]: www.google.de is 74.125.43.106 74.125.43.104 74.125.43.99 74.125.43.147 74.125.43.105 74.125.43.103 > [Thread 0x7ffff5111700 (LWP 21693) exited] > Connecting to 74.125.43.106 > > <snip>Now I press <CTRL> s</snip> > > Program received signal SIGSEGV, Segmentation fault. > __strrchr_sse2 () at ../sysdeps/x86_64/multiarch/../strrchr.S:33 > 33 ../sysdeps/x86_64/multiarch/../strrchr.S: Can't find file or directory. > in ../sysdeps/x86_64/multiarch/../strrchr.S > Current language: auto > The current source language is "auto; currently asm". > (gdb) l > 28 in ../sysdeps/x86_64/multiarch/../strrchr.S > (gdb) bt > #0 __strrchr_sse2 () at ../sysdeps/x86_64/multiarch/../strrchr.S:33 > #1 0x0000000000410640 in a_Misc_parse_search_url (source=0x0, > label=0x7fffffffdb58, urlstr=0x7fffffffdb50) at misc.c:395 > #2 0x0000000000414ddf in a_Dialog_input (msg=<value optimized out>) > at dialog.cc:167 > #3 0x000000000040d137 in a_UIcmd_search_dialog (vbw=0x774180) at uicmd.cc:820 > #4 0x000000000040a9fd in UI::handle (this=0x7951a0, event=12) at ui.cc:821 > #5 0x000000000046451b in send(int, Fl_Widget*, Fl_Window*) () > #6 0x0000000000465415 in Fl::handle_(int, Fl_Window*) () > #7 0x000000000046533c in Fl::handle_(int, Fl_Window*) () > #8 0x0000000000485530 in fl_handle(_XEvent const&) () > #9 0x000000000048558d in do_queued_events() () > #10 0x00000000004857ac in fl_wait(double) () > #11 0x0000000000465c23 in Fl::wait(double) () > #12 0x0000000000465c93 in Fl::run() () > #13 0x0000000000407f14 in main (argc=1, argv=0x7fffffffe3c8) at dillo.cc:429 Does this fix it? dialog.cc:167 - if (a_Misc_parse_search_url(source, &label, &url) < 0) + if (!source || a_Misc_parse_search_url(source, &label, &url) < 0) -- Cheers Jorge.-

July 30, 2011

are we officially at feature freeze yet?

by jcid＠dillo.org

On Fri, Jul 29, 2011 at 03:53:45PM -0400, Jorge Arellano Cid wrote: > On Tue, Jul 26, 2011 at 07:48:18PM +0000, corvid wrote: > > > > It would be nice just to make some fixes and get 3.0 out... So far we have: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ ] UI_TEMPORARILY_SHOW_PANELS [ ] the panel problems when resizing from very small. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ ] something other than "ctab%d" for initial tab label. [ ] single close tab button with tooltip. [ ] segfault with Ctrl-s (web search) I'm working on the last one... -- Cheers Jorge.-

July 30, 2011

Segfault at <CTRL> s

by Hole.destructor＠gmx.de

Dear Dillo developers, since some days I get a segfault when starting the web search via <CTRL>s (using the dillo 3.0 trunk). Here is the backtrace: $ gdb ./dillo GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 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 "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /PATH/TO/DILLO/dillo...done. (gdb) r Starting program: /PATH/TO/DILLO/dillo [Thread debugging using libthread_db enabled] dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='http://www.google.de' [New Thread 0x7ffff5111700 (LWP 21693)] Dns_server [0]: www.google.de is 74.125.43.106 74.125.43.104 74.125.43.99 74.125.43.147 74.125.43.105 74.125.43.103 [Thread 0x7ffff5111700 (LWP 21693) exited] Connecting to 74.125.43.106 <snip>Now I press <CTRL> s</snip> Program received signal SIGSEGV, Segmentation fault. __strrchr_sse2 () at ../sysdeps/x86_64/multiarch/../strrchr.S:33 33 ../sysdeps/x86_64/multiarch/../strrchr.S: Can't find file or directory. in ../sysdeps/x86_64/multiarch/../strrchr.S Current language: auto The current source language is "auto; currently asm". (gdb) l 28 in ../sysdeps/x86_64/multiarch/../strrchr.S (gdb) bt #0 __strrchr_sse2 () at ../sysdeps/x86_64/multiarch/../strrchr.S:33 #1 0x0000000000410640 in a_Misc_parse_search_url (source=0x0, label=0x7fffffffdb58, urlstr=0x7fffffffdb50) at misc.c:395 #2 0x0000000000414ddf in a_Dialog_input (msg=<value optimized out>) at dialog.cc:167 #3 0x000000000040d137 in a_UIcmd_search_dialog (vbw=0x774180) at uicmd.cc:820 #4 0x000000000040a9fd in UI::handle (this=0x7951a0, event=12) at ui.cc:821 #5 0x000000000046451b in send(int, Fl_Widget*, Fl_Window*) () #6 0x0000000000465415 in Fl::handle_(int, Fl_Window*) () #7 0x000000000046533c in Fl::handle_(int, Fl_Window*) () #8 0x0000000000485530 in fl_handle(_XEvent const&) () #9 0x000000000048558d in do_queued_events() () #10 0x00000000004857ac in fl_wait(double) () #11 0x0000000000465c23 in Fl::wait(double) () #12 0x0000000000465c93 in Fl::run() () #13 0x0000000000407f14 in main (argc=1, argv=0x7fffffffe3c8) at dillo.cc:429 Kind regards, Alexander

July 30, 2011

Re: What's pending in dillo-3.0 for a release

by obeythepenguin＠gmail.com

On Fri, 29 Jul 2011 16:12:12 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > This avoids the dialog bombing that stems from loading multiple > https images/resources in a single page. A proper fix would take > either to implement the https-dpi as a server (with state), > or to move back https handling into dillo. > > As both paths would take considerable effort, and taking into > account that even deciding which approach/library to use is non > trivial, the workaround looks like a good compromise. Actually, the second one's already done -- I implemented it as part of Dillo-Win32. The patches of interest are: http://dillo-win32.sourceforge.net/files/03-dillo-r1819.dsock.diff http://dillo-win32.sourceforge.net/files/22-dillo-r1819.https.diff http://dillo-win32.sourceforge.net/files/24-dillo-r1819.sslconfig.diff The first one introduces dsock, a sockets abstraction layer patterned on dlib, which I originally wrote to add Windows networking support. The next one extends dsock to provide SSL support: all you need to do is tell it to "go secure," then dsock handles read/write operations transparently. So you get both portability *and* security, with only minimal modification to the existing Dillo code. The last patch is optional -- it just modifies the ./configure script so it can link against CyaSSL[1], an embedded SSL library. It's probably not as useful on Unix, since every distro these days ships OpenSSL, but it's nice on Windows since it dramatically reduces the binary's download size. There are a couple caveats: the HTTP CONNECT code is a mess right now, because I couldn't figure how to hook that through the CCC's, and I haven't yet added the SSL dialogs. But both of those should be relatively easy to fix. [1] http://www.yassl.com/yaSSL/Home.html Just thought I'd share, ~Benjamin

July 29, 2011

Re: What's pending in dillo-3.0 for a release

by jcid＠dillo.org

On Fri, Jul 08, 2011 at 10:25:04AM -0400, Dennis Nezic wrote: > On Wed, 29 Jun 2011 11:37:21 -0400, Jorge Arellano Cid wrote: > > Hi there, > > > > Fltk-1.3 is out there, and we've worked our pending issues list. > > What's still pending? > > /me hopes the Choice5-popup dialog, regarding unverified certificates, > has been fixed. And/or perhaps an option similar to wget's > "--no-check-certificate" is implemented :). Please check the just committed patch for this (BUG#868). Quoting the log: "Workaround: request to only check the root URL's certificate (https). This avoids the dialog bombing that stems from loading multiple https images/resources in a single page. A proper fix would take either to implement the https-dpi as a server (with state), or to move back https handling into dillo." As both paths would take considerable effort, and taking into account that even deciding which approach/library to use is non trivial, the workaround looks like a good compromise. -- Cheers Jorge.-

July 29, 2011

are we officially at feature freeze yet?

by jcid＠dillo.org

On Tue, Jul 26, 2011 at 07:48:18PM +0000, corvid wrote: > > It would be nice just to make some fixes and get 3.0 out... Just committed a patch for one of my pet peeves: "After going back or forward to any page, there were two redraws: one from the origin and another from the scroll position. This patch avoids flicker, and makes rendering 100% faster in this case." A good way to test this is to load a page with a colorful image at its top, then scroll away the image, and go to bookmars (no images here). Then go back and forward with the keyboard; w/o the patch you'll see the image flash before the page is drawn at the scroll position it was left at. So far, I'm very happy with it! :-) -- Cheers Jorge.-

July 29, 2011

Images Not Updating (Using Cache on Page Reload)

by rogerx.oss＠gmail.com

I just noticed, dillo_port1.3 using fltk-1.3 is not refreshing/reloading images when page Reload is pressed. The images I noticed not reloading are found on my weather forecast page: http://forecast.weather.gov/MapClick.php?zoneid=AKZ222 (... thinking, this might be more in depth such as the images being embedded in javascript or something which mitigates this issue.) -- Roger http://rogerx.freeshell.org/

July 29, 2011

are we officially at feature freeze yet?

by corvid＠lavabit.com

> - UI_TEMPORARILY_SHOW_PANELS > > - the panel problems when resizing from very small. > > - remove large panel - something other than "ctab%d" for initial tab label

July 28, 2011

experimental patch: allow alt text to wrap

by johannes.hofmann＠gmx.de

On Wed, Jul 27, 2011 at 07:51:53PM -0400, Jorge Arellano Cid wrote: > On Tue, Jul 19, 2011 at 09:39:32PM +0000, corvid wrote: > > > > Just tried this, and I like the results quite a bit. > > After some testing, it looks like a worthy addition. > Sites w/o images become more "readable" with it. I also like it. I would prefer to use our own methods for word wrapping (i.e. Textblock), but couldn't come up with anything really working until now, so I'm happy with the drawSimpleWrappedText(). We could still change it in the future. Cheers, Johannes

July 28, 2011

experimental patch: allow alt text to wrap

by jcid＠dillo.org

On Tue, Jul 19, 2011 at 09:39:32PM +0000, corvid wrote: > > Just tried this, and I like the results quite a bit. After some testing, it looks like a worthy addition. Sites w/o images become more "readable" with it. BTW, using SHADING_DARK for drawSimpleWrappedText() helps too. > - "simple" insofar as it doesn't bother with the letter-spacing and > font-variant code. > > - it's a separate path from drawText() because this many-argument version > of fl_draw() in fl_draw.cxx is rather a long function so that it can > deal with wrapping and images and symbols and all kinds of alignment in > general. > > - if the wrapped text fits into the box, we do some unnecessary clipping. > Would it be worth the trouble to add an interface to get fl_measure() > information? It doesn't look worth the effort. If you see no further problems, please commit. -- Cheers Jorge.-

July 28, 2011

Which FLTK2 version for dillo-2.1.1 ^W dillo-2.2.1?

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Wed, Jul 27, 2011 at 07:04:47PM +0100, Jeremy Henty wrote: > > > > corvid wrote: > > > > > In README, it has "The recommended version is >= r6916. and <=r7513". > > > > Then we have a problem as the FLTK site's download area doesn't have > > tarballs for any releases < r8323. Perhaps dillo.org could host a > > recommended version? > > Just noticed the subject of this thread says "dillo-2.1.1", > instead of "dillo-2.2.1". D'oh! A typo on my part. > dillo-2.2.1's README, does exactly what you suggest. So it does! I have updated the BLFS wiki pages[1][2]. Has the list of installed files changed between versions 2.2 and 2.2.1? Looking forward to creating a BLFS wiki page for Dillo 3! Regards, Jeremy "First person to run Dillo under Linux 3" Henty [1] http://wiki.linuxfromscratch.org/blfs/wiki/dillo2 [2] http://wiki.linuxfromscratch.org/blfs/wiki/fltk2

July 27, 2011

are we officially at feature freeze yet?

by jcid＠dillo.org

On Wed, Jul 27, 2011 at 06:00:18PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Jul 26, 2011 at 07:48:18PM +0000, corvid wrote: > > > - UI_TEMPORARILY_SHOW_PANELS > > > Not exactly important: > > > - the panel problems when resizing from very small. > > > > and > > > > - alt text wrapping (which looks like a nice feature) > > > > - remove large panel > > - The findbar input doesn't know about Ctrl-A, etc. BTW, does anybody have a working URL for BUG#868? (I had a different one as test case, but it went nil...). -- Cheers Jorge.-

July 27, 2011

are we officially at feature freeze yet?

by jcid＠dillo.org

On Wed, Jul 27, 2011 at 06:00:18PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Jul 26, 2011 at 07:48:18PM +0000, corvid wrote: > > > - UI_TEMPORARILY_SHOW_PANELS > > > Not exactly important: > > > - the panel problems when resizing from very small. > > > > and > > > > - alt text wrapping (which looks like a nice feature) > > > > - remove large panel > > - The findbar input doesn't know about Ctrl-A, etc. Done. -- Cheers Jorge.-

July 27, 2011

Which FLTK2 version for dillo-2.1.1?

by jcid＠dillo.org

On Wed, Jul 27, 2011 at 07:04:47PM +0100, Jeremy Henty wrote: > > corvid wrote: > > > In README, it has "The recommended version is >= r6916. and <=r7513". > > Then we have a problem as the FLTK site's download area doesn't have > tarballs for any releases < r8323. Perhaps dillo.org could host a > recommended version? Just noticed the subject of this thread says "dillo-2.1.1", instead of "dillo-2.2.1". dillo-2.2.1's README, does exactly what you suggest. -- Cheers Jorge.-

July 27, 2011

Which FLTK2 version for dillo-2.1.1?

by onepoint＠starurchin.org

corvid wrote: > In README, it has "The recommended version is >= r6916. and <=r7513". Then we have a problem as the FLTK site's download area doesn't have tarballs for any releases < r8323. Perhaps dillo.org could host a recommended version? Regards, Jeremy Henty

July 27, 2011

are we officially at feature freeze yet?

by corvid＠lavabit.com

Jorge wrote: > On Tue, Jul 26, 2011 at 07:48:18PM +0000, corvid wrote: > > - UI_TEMPORARILY_SHOW_PANELS > > Not exactly important: > > - the panel problems when resizing from very small. > > and > > - alt text wrapping (which looks like a nice feature) > > - remove large panel - The findbar input doesn't know about Ctrl-A, etc.

July 27, 2011

are we officially at feature freeze yet?

by obeythepenguin＠gmail.com

On Wed, 27 Jul 2011 00:54:45 -0400, corvid <corvid(a)lavabit.com> wrote: > Benjamin wrote: >> I'd say just reintroduce the close button alongside click-to-close. > > I would say that a nice patch that does this -- or, better yet, puts > one on each tab -- would be accepted with a smile. I'll try to take a look if I have time (I haven't updated my local copy to dillo-3.0 yet). ~Benjamin

July 27, 2011

are we officially at feature freeze yet?

by jcid＠dillo.org

On Tue, Jul 26, 2011 at 10:53:55PM -0400, Benjamin Johnson wrote: > On Tue, Jul 26, 2011 at 8:16 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > On Tue, Jul 26, 2011 at 11:23:49PM +0000, corvid wrote: > >> > >> Do you think the tabs should have a tooltip indicating that they > >> can be closed with a click? Somehow it's hard for me to remember > >> that that feature exists. > > > > ?Yeah, it's probably a good idea. > > ?(something like the clear URL button). > > I'd say just reintroduce the close button alongside click-to-close. > That way you're not changing a familiar, intuitive user interface > users would expect from other applications, but you've still got a > useful shortcut for more advanced users. AFAIS, this idea looks like the best trade off so far. Although I'd hoped a tooltip label to be enough hint, the single close button to the right is more obvious, and it can bear a tooltip that lists the other ways to close a tab. The tooltip is effective because almost everything in the panel has one, so at some point the user will explore them. As for one close button per tab label, I'd prefer not to. > [...] > Dillo's way is quite convenient once you get used to it, but > it's harder for new users because it breaks with other > applications' conventions. -- Cheers Jorge.-

July 27, 2011

Which FLTK2 version for dillo-2.1.1?

by corvid＠lavabit.com

Jeremy wrote: > > I want to update the BLFS pages for Dillo-2.2.1 so I need to know > which version(s) of FLTK2 to recommend. I remember there was a recent > discussion but I can't find it in the list archives (strangely, > searches for "fltk2" and "fltk version" turn up next to nothing - is > search working?). In README, it has "The recommended version is >= r6916. and <=r7513". I'd noticed earlier that search was misbehaving, which was strange because it's been working well for a long time now...

July 27, 2011

Which FLTK2 version for dillo-2.1.1?

by onepoint＠starurchin.org

I want to update the BLFS pages for Dillo-2.2.1 so I need to know which version(s) of FLTK2 to recommend. I remember there was a recent discussion but I can't find it in the list archives (strangely, searches for "fltk2" and "fltk version" turn up next to nothing - is search working?). Regards, Jeremy Henty

July 27, 2011

Questions about beta testing

by rogerx.oss＠gmail.com

> On Tue, Jul 26, 2011 at 11:26:37PM -0400, Benjamin Johnson wrote: >On Tue, Jul 26, 2011 at 10:43 PM, Walter Dnes <waltdnes(a)waltdnes.org> wrote: >> Hi all; >> >> ?I joined the list recently. ?It's been a long time since I last ran >> beta software consistently. ?Ironically, it was the Phoenix browser beta >> (later to become Firebird, and then Firefox). ?I was unhappy about how >> bloated the major browser had become, and I wanted a lightweight browser. >> It looks like I've come full circle. >> >> ?Iam not a C programmer. ?I'm a "power user" instead. ?I remember about >> extracting the tarball, going into its directory and then executing... >> >> ./configure --with-various-options && make && make install >> >> ...but that's about all. ?Like the subject says, I have some questions >> >> 1) I assume that all files that go into /usr/whatever in a normal >> install under a package manager, will end up in /usr/local/whatever if >> I build from the tarball. ?Is that correct? > >By default, yes. You can change that using the ./configure --prefix= option. What I do here on my Gentoo boxes with CVS/SVN or tarballs, --prefix=$HOME/install" or --prefix=$HOME/src/{program_name}/install Now I can manually remove the installed files easily if the Makefile doesn't include a "make uninstall" routine. I then edit Dillo's dpidrc file: $ cat .dillo/dpidrc #dpi_dir=/usr/lib/dillo/dpi dpi_dir=/home/roger/src/dillo/install/lib/dillo/dpi If you really want to install system wide, I think /usr/local/ is the more appropriate place, but even some Gentoo packages routinely install to /usr/local -- as such, you might not be able to easily uninstall if a Makefile doesn't have an uninstall routine. >> 2) How do I uninstall the program? ?Or can I simply install new versions >> over top of old ones? > >Assuming you've kept your Dillo build directory, just go back and run >"make uninstall". > >You can install a newer Dillo on top of the old one, though check the >FAQ about dpid: > http://www.dillo.org/FAQ.html#q14 > >> 3) Can I assume that the configure defaults are the reverse of the >> options? ?E.g. if the "configure" file has... >> ?--enable-ssl ? ? ? ? ? ?Enable ssl, https (ALPHA CODE) >> ?--enable-ipv6 ? ? ? ? ? Build with support for IPv6 >> ?--disable-cookies ? ? ? Don't compile support for cookies >> ?--disable-png ? ? ? ? ? Disable support for PNG images >> ...then are the defaults --disable-ssl --disable-ipv6 --enable-cookies >> --enable-png ? > >Yes. > >> ?Which one is the default here? ?Hopefully the "enable" version. >> ?--disable-dependency-tracking ?speeds up one-time build >> ?--enable-dependency-tracking ? do not reject slow dependency extractors > >Offhand, I believe the "disable" option, but to be honest I'm not >sure. I think you'd only need that on if you were hacking on Dillo >and drastically changing the interdependencies between source files; >I've never had any use for it myself. > >Either way, the resulting executable is exactly the same. As a >general rule, if you don't need it (or don't know if you need it), >your safest bet is to leave it out completely and let ./configure go >with the defaults. > >> 4) I run Gentoo linux, in 64-bit mode on an Intel i3. ?The first 4 >> statements in my /etc/make.conf are... >> >> CFLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe" >> CXXFLAGS="${CFLAGS}" >> CHOST="x86_64-pc-linux-gnu" >> MAKEOPTS="-j1" >> >> I believe that CFLAGS and CXXFLAGS are read directly by gcc. ?Is CHOST >> used outside of Gentoo's package-management? ?And how do I pass MAKEOPTS >> to make? ?Yes, I know that "-j1" slows down the build process slightly. >> But the final binary is just as fast. ?And the first time you waste a >> couple of hours on mysterious failures during the build process, you >> lose all the time you "saved" with a higher "-j" value. ?I see it every >> so often on the Gentoo mailing list. Type: $ export or $ export |grep CFLAG You'll see CFLAGS/CHOST within /etc/make.conf on Gentoo seems to be only read by gcc. Or: $ echo CHOST >First of all, passing your own CFLAGS isn't going to make Dillo any >faster, because it doesn't do any intensive computation. The only >time you'll *ever* see a noticeable difference is in >computation-intensive software like multimedia, cryptography, etc., >and those programs usually come with their own recommended >optimizations. If you're wondering where the program is spending most of it's time, you can run Dillo through or attach to it by using ltrace. I found ELinks spent almost all of it's time running through strings (ie. strcat) -- which ate CPU resources like crazy. Since there were no more optimizations for these standard libs, -O2/-O3 did nothing for ELinks light weight browser. (x86 here). >Personally, I use and recommend "-Os" with Dillo, since it gets the >same performance but a slightly smaller file size. You could also >keep "-pipe"; that makes the compilation itself a bit faster, but it >won't change the Dillo executable in any way. > >I also wouldn't worry about custom make options. It might not get the >most efficient performance, but it's generally reliable, since make's >defaults are designed to be safe for most any machine. If I don't >know how it works, and it ain't broke, there's no need for me to break >it! > >I've never seen CHOST before, so I'd assume that's a Gentoo-ism. Leave it. > >> ?Here is what I'm looking at to automate the build process... >> >> #!/bin/bash >> export CFLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe" >> export CXXFLAGS="${CFLAGS}" >> ./configure --enable-ssl && make && make install >> >> ?Any comments? > >You'd pass your custom MAKEOPTS by exporting them, just like with >CFLAGS and CXXFLAGS. (But again, I wouldn't mess with it if you don't >have to. I'm a software developer and even I rarely mess with that >stuff, since I know my own code but I'm certainly no expert on make.) $CHOST is a preset variable within the /etc/make.conf. I don't think you need to mess with $CHOST unless you're cross compiling? The above looks good and basically the type of simple build scripts I have here for SVN/CVS ... I usually omit the CFLAGS/CXXFLAGS and only specify these flags when needing debugging : CFLAGS="-g -Wall -ggdb" And then run the program through gdb. -- Roger http://rogerx.freeshell.org/

July 27, 2011