November 2012 - Dillo-dev - lists.mailman3.com

fltk linkage

by corvid＠lavabit.com

Jorge wrote: > On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > > > In September 2011, I wrote: > > > Do we still have a reason for telling people to stick with > > > static linkage when building fltk? > > > > I was thinking about what our installation instructions should look like > > these days, and how everyone has a decent chance of having a fltk-1.3 > > package available and it may not be best to tell them to run off and > > compile fltk unless fltk-config --version doesn't tell them any good news > > and they can't get a pkg... and this led me to wonder about the > > necessity/appropriateness of static linking. > > > > All that I found in the archive was me wondering about it last year and > > no one replying to me. Well, except this now. I'm replying to me, if that > > counts. > > FWIW, I build in a Debian system now and: > > $ ldd dillo > [...] > libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2c3e312000) > libfltk.so.1.3 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 (0x00007f2c3dfd0000) > [...] > > I thought this meant it was linked with a shared version of FLTK. > What am I missing? *digs through fltk for a minute* So it's a matter of whether fltk is configured with --enable-shared, then? The main page of the website still says "statically-linked by default!", and all along I've had the impression that it had to do with the form of how we link in the Makefile. I guess it makes sense to rm that mention from the website, then. I could've sworn that it was in our documentation somewhere, too, but I don't see it anywhere at the moment. PS I think we will be able to get rid of the warning about --enable-cairo , since it doesn't seem to do anything bad with fltk-1.3.

Nov. 10, 2012

fltk linkage

by jcid＠dillo.org

On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > In September 2011, I wrote: > > Do we still have a reason for telling people to stick with > > static linkage when building fltk? > > I was thinking about what our installation instructions should look like > these days, and how everyone has a decent chance of having a fltk-1.3 > package available and it may not be best to tell them to run off and > compile fltk unless fltk-config --version doesn't tell them any good news > and they can't get a pkg... and this led me to wonder about the > necessity/appropriateness of static linking. > > All that I found in the archive was me wondering about it last year and > no one replying to me. Well, except this now. I'm replying to me, if that > counts. FWIW, I build in a Debian system now and: $ ldd dillo [...] libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2c3e312000) libfltk.so.1.3 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 (0x00007f2c3dfd0000) [...] I thought this meant it was linked with a shared version of FLTK. What am I missing? -- Cheers Jorge.-

Nov. 10, 2012

fltk linkage

by Johannes.Hofmann＠gmx.de

On Sat, Nov 10, 2012 at 06:07:54PM +0000, corvid wrote: > > In September 2011, I wrote: > > Do we still have a reason for telling people to stick with > > static linkage when building fltk? > > I was thinking about what our installation instructions should look like > these days, and how everyone has a decent chance of having a fltk-1.3 > package available and it may not be best to tell them to run off and > compile fltk unless fltk-config --version doesn't tell them any good news > and they can't get a pkg... and this led me to wonder about the > necessity/appropriateness of static linking. > > All that I found in the archive was me wondering about it last year and > no one replying to me. Well, except this now. I'm replying to me, if that > counts. I would leave the decision to link statically or not to the package maintainers of the various distros. They will do anyway what they consider best.

Nov. 10, 2012

fltk linkage

by corvid＠lavabit.com

In September 2011, I wrote: > Do we still have a reason for telling people to stick with > static linkage when building fltk? I was thinking about what our installation instructions should look like these days, and how everyone has a decent chance of having a fltk-1.3 package available and it may not be best to tell them to run off and compile fltk unless fltk-config --version doesn't tell them any good news and they can't get a pkg... and this led me to wonder about the necessity/appropriateness of static linking. All that I found in the archive was me wondering about it last year and no one replying to me. Well, except this now. I'm replying to me, if that counts.

Nov. 10, 2012

dFree()

by p37sitdu＠lavabit.com

On Fri, Nov 09, 2012 at 05:18:45PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Nov 09, 2012 at 12:47:14AM +0000, corvid wrote: > > > > > > If dFree() is just free() now, is there a good reason not to remove it? > > > > Yes, it matches dNew & dNew0 (mnemonic). > > > > Also, it gets simpler to profile/debug memory allocation, > > by instrumenting those primitives. > > How about #define dFree() as free(), then? Or #define free when you need to debug. Or use LD_PRELOAD.

Nov. 9, 2012

dFree()

by corvid＠lavabit.com

Jorge wrote: > On Fri, Nov 09, 2012 at 12:47:14AM +0000, corvid wrote: > > > > If dFree() is just free() now, is there a good reason not to remove it? > > Yes, it matches dNew & dNew0 (mnemonic). > > Also, it gets simpler to profile/debug memory allocation, > by instrumenting those primitives. How about #define dFree() as free(), then?

Nov. 9, 2012

dFree()

by jcid＠dillo.org

On Fri, Nov 09, 2012 at 12:47:14AM +0000, corvid wrote: > > If dFree() is just free() now, is there a good reason not to remove it? Yes, it matches dNew & dNew0 (mnemonic). Also, it gets simpler to profile/debug memory allocation, by instrumenting those primitives. -- Cheers Jorge.-

Nov. 9, 2012

dFree()

by corvid＠lavabit.com

If dFree() is just free() now, is there a good reason not to remove it?

Nov. 9, 2012

Tab closing order

by jcid＠dillo.org

On Thu, Nov 08, 2012 at 03:22:47AM +0000, corvid wrote: > > The valgrind logs found something with this: > http://starurchin.org/dillo/valgrind/b8b4ffc070d8c2dc439c384f0b9d7a57fe5ee6… > > I think line 337 in Jeremy's dillo corresponds to 326 in stock dillo, which > would be "if (btn->focus_num() > fbtn->focus_num())", so probably tabs that > have never been focused just need a focus_num of 0 or something... Patch committed. -- Cheers Jorge.-

Nov. 8, 2012

hyphenation in dillo

by sgeerken＠dillo.org

On Wed, Nov 07, corvid wrote: > Sebastian wrote: > > On Mon, Sep 10, corvid wrote: > > > I was looking at the src for http://distrowatch.com , and the > > > source page is very wide -- wider than any lines, so far as I > > > could see. > > > > There is one line, which is very long (number 54), but the current > > release breaks this line into multiple ones. Can someone provide > > details about the vsource plugin? > > The vsource page has > <style type="text/css">PRE {white-space: pre-wrap} > and the css2 spec says > "If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces > (U+0020) unbroken by an element boundary is treated as a sequence of > non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity > exists at the end of the sequence." So "pre-wrap" can be broken. Fixed. Sebastian

Nov. 8, 2012