Re: [dev] [st] font fallback
> >That’s only partially true. The array is adding 48k, which another patch > >series will reduce. Most of the additional memory usage is due to the > >font handling. So the inability of font handling in X.org/Fontconfig is > >the reason why too much has to be done over and over again. Yet another > >abstraction layer would hide it but waste the same resources. > > But unless I'm mistaken, the static arrays go in the .data or .bss > section (which also increased, but not by 16x.) The bbs segment is not present in the executable. All the static data not initialized go to this segment, and the first thing that the executable does is a memset to 0 of the bbs segment. The executable only has the definition of the segment, begin address and size. This is the reason why is not the same these declarations: static int dummy; static int dummy = 0; The first goes to bbs and it is not present in the executable, and the second goes to data and it is present in the executable (of course some compilers can optimize it).
Re: [dev] [st] font fallback
On 01/05/2013 09:55 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 18:55:12 +0100 Charlie Kester wrote: Of course, some growth is expected as new features are added, but going from 38k to 618k is hard to swallow. On my system: % ls -hs st-0.3/st 126K st % strip st-0.3/st&& ls -hs st-0.3/st 48K % ls -hs scm/st/st 178K % strip scm/st/st&& ls -hs scm/st/st 91K st Interesting. I get much a much bigger executable with the latest git. So I dug a little deeper and the problem seems to occur when pkg-config adds -lfreetype to the linker flags. Omitting that linker flag gets me a 85k binary after stripping, fwiw. It seems to run OK too. Do I really need to explicitly link to the freetype library? I don't see any complaints from the linker about unresolved symbols... ldd reports that my copy of st built without -lfreetype is using libfreetype.so.6. So it seems that something is already pulling it in. Hmm. I wonder if I was somehow linking to the static version of the freetype library? That might explain the font-related stuff I found in the .rodata section, and maybe the .eh_frame* stuff too. Weird! Sorry for the noise.
Re: [dev] [st] README/Makefile cleanup
Greetings. On Sat, 05 Jan 2013 20:31:13 +0100 Peter Hartman wrote: > Attached. Thanks, the changes were applied. Sincerely, Christoph Lohmann
Re: [dev] [st] font fallback
On Jan 5, 2013 1:21 PM, "Christoph Lohmann" <2...@r-36.net> wrote: > > What are the list's opinions? > Extract the keys to another header, categorize keys somehow, add defines in config.mk to include/exclude different category keys. Or document defines in readme. Possible categories: EXTENDED_FN, NUMPAD... personally, I really like the fn keys --Carlos
Re: [dev] [st] font fallback
Greetings. On Sat, 05 Jan 2013 18:55:12 +0100 Charlie Kester wrote: > Of course, some growth is expected as new features are added, but going > from 38k to 618k is hard to swallow. On my system: % ls -hs st-0.3/st 126K st % strip st-0.3/st && ls -hs st-0.3/st 48K % ls -hs scm/st/st 178K % strip scm/st/st && ls -hs scm/st/st 91K st But I found out what’s causing the 50k(!) increase. It’s the big key[] array. Simply remove it and you get back the old 48k size. So the ques‐ tion is, if this array could be optimized out. The escape codes only partially have a system that could be replaced with ranges. On my system: % ls -hs /usr/bin/xterm /usr/bin/urxvt 1.3M /usr/bin/urxvt 452K /usr/bin/xterm That array gives st a better escape key support than any other terminal, but it bloats it with seldom used features and is now more than 50% of its size. That’s hard to decide. :/ What are the list's opinions? Sincerely, Christoph Lohmann
Re: [dev] [st] font fallback
On 01/05/2013 07:33 AM, Charlie Kester wrote: On 01/05/2013 06:57 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kester wrote: On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bigger. The stripped executable is now 16x the size of that from the 0.3 release -- thanks, no doubt, to these font caches, which are implemented as static arrays. That’s only partially true. The array is adding 48k, which another patch series will reduce. Most of the additional memory usage is due to the font handling. So the inability of font handling in X.org/Fontconfig is the reason why too much has to be done over and over again. Yet another abstraction layer would hide it but waste the same resources. Yes. I took a closer look at the stripped executables using objdump, and most of the increase is in the .rodata section: v0.3: 0cach (3,244) latest git: 16934h (92,468) But unless I'm mistaken, the static arrays go in the .data or .bss section (which also increased, but not by 16x.) So I must take back the allegation that the caches are the main culprit here. I'm also seeing huge (> 20x) increases in the .eh_frame and .eh_frame_hdr sections. .data, on the other hand, increases slightly less than 10x. (But I'd already dropped the Fontcache frc[] array back to 256 elements, backing out the most recent change had which upped it to 2048. It was only after seeing that reverting this had no noticeable effect on the executable size that I started poking around with objdump.) The contents of the .rodata section do seem to have a lot of font-related stuff. I have no idea what's going on with the .eh_frame* sections. Hopefully these issues can be addressed and the size brought back under control. One of the nice things about st 0.3 is that a stripped executable is only 38k. That really helps convey the idea that it's a simple, suckless terminal emulator. Of course, some growth is expected as new features are added, but going from 38k to 618k is hard to swallow.
Re: [dev][surf] searchengine patch against surf git tip
Thanks hiltjo! On Jan 5, 2013 7:29 AM, "Hiltjo Posthuma" wrote: > On Fri, Jan 4, 2013 at 10:44 PM, Carlos Torres > wrote: > > http://sprunge.us/QMMS > > > > someone requested that on IRC and i had it. > > > > Enjoy! > > > > You can also use shellscripting and do something like this: > > #!/bin/sh > > read input > token=$(printf "%s" "$input" | cut -b 1-2) > stuff=$(printf "%s" "$input" | cut -b 3-) > url="$input" > engine="" > if [ "$token" = "g " ]; then > engine="https://encrypted.google.com/search?q=%s"; > elif [ "$token" = "y " ]; then > engine="http://www.youtube.com/results?search_query=%s&aq=f"; > elif [ "$token" = "w " ]; then > engine="http://wikipedia.org/wiki/%s"; > fi > > if [ ! "$engine" = "" ]; then > url=$(printf "$engine" "$stuff") > fi > printf "Url is: |%s|\n" "$url" > > > Kind regards (and happy new year), > Hiltjo > >
Re: [dev] [st] font fallback
On 01/05/2013 06:57 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kester wrote: On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bigger. The stripped executable is now 16x the size of that from the 0.3 release -- thanks, no doubt, to these font caches, which are implemented as static arrays. That’s only partially true. The array is adding 48k, which another patch series will reduce. Most of the additional memory usage is due to the font handling. So the inability of font handling in X.org/Fontconfig is the reason why too much has to be done over and over again. Yet another abstraction layer would hide it but waste the same resources. Yes. I took a closer look at the stripped executables using objdump, and most of the increase is in the .rodata section: v0.3:0cach (3,244) latest git: 16934h (92,468) But unless I'm mistaken, the static arrays go in the .data or .bss section (which also increased, but not by 16x.) So I must take back the allegation that the caches are the main culprit here.
Re: [dev] [st] font fallback
Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kester wrote: > On 12/29/2012 12:20 AM, Kai Hendry wrote: > > Initially I was worried that the newer version was somehow slower to > > the version I was running before. > > Not slower, but definitely bigger. The stripped executable is now 16x > the size of that from the 0.3 release -- thanks, no doubt, to these font > caches, which are implemented as static arrays. That’s only partially true. The array is adding 48k, which another patch series will reduce. Most of the additional memory usage is due to the font handling. So the inability of font handling in X.org/Fontconfig is the reason why too much has to be done over and over again. Yet another abstraction layer would hide it but waste the same resources. Sincerely, Christoph Lohmann
Re: [dev] [st] font fallback
On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bigger. The stripped executable is now 16x the size of that from the 0.3 release -- thanks, no doubt, to these font caches, which are implemented as static arrays. Been using st as my main terminal for a few months now. :) Me too. :)
[dev] [ii] 1.7 release
Hey, way too late, but I just wrapped up the current git head of ii[0] to an 1.7 release. The archive is available at [1]. 1.7 (2013-01-05) - -k now specifies an environment variable that contains the server key. This behaviour has been changed in order to not expose the password in the process list. - Fix parsing of JOIN messages for certain servers. Thanks Ivan Kanakarakis! - Use , rather than _ for slash characters in channel names. As per RFC , is not allowed in a channel name, while _ is. Thanks plomplomplom and Nils Dagsson Moskopp! Thanks everyone for the contributions! [0] http://tools.suckless.org/ii/ [1] http://dl.suckless.org/tools/ii-1.7.tar.gz Cheers Nico pgpXfDhkhiDbV.pgp Description: PGP signature
Re: [dev][surf] searchengine patch against surf git tip
On Fri, Jan 4, 2013 at 10:44 PM, Carlos Torres wrote: > http://sprunge.us/QMMS > > someone requested that on IRC and i had it. > > Enjoy! > You can also use shellscripting and do something like this: #!/bin/sh read input token=$(printf "%s" "$input" | cut -b 1-2) stuff=$(printf "%s" "$input" | cut -b 3-) url="$input" engine="" if [ "$token" = "g " ]; then engine="https://encrypted.google.com/search?q=%s"; elif [ "$token" = "y " ]; then engine="http://www.youtube.com/results?search_query=%s&aq=f"; elif [ "$token" = "w " ]; then engine="http://wikipedia.org/wiki/%s"; fi if [ ! "$engine" = "" ]; then url=$(printf "$engine" "$stuff") fi printf "Url is: |%s|\n" "$url" Kind regards (and happy new year), Hiltjo
