Re: [dev] Let's talk about Go, baby
Markus Wichmann wrote: > I have a different problem with Go: Their insistence on reinventing the > wheel. Complaining about reinventing the wheel on this mailing list is a bold and hilarious move. A+ > Would also not be a problem if the Go runtime entirely supplanted the > libc. It can/does? CGO_ENABLED=0 gives you statically linked binaries that don't reference or use libc at all. yours, Bobby
Re: [dev] Coding style: why /* */ and not //?
On Wed, Dec 26, 2018 at 10:44 AM wrote: > Preprocessor. I guess having 2 ways to define comments is not significant, > then better stick to one and the historical one. Better than one way is zero ways -- comments are not semantically significant, so rather than argue about which standards-defined comment style to use it would better to ban them all.
Re: [dev] Xorg implementations
Sylvain Bertrand wrote: > For c++ retards and sub-humans Delete your account.
Re: [dev] Interesting Web Browser Decoupling Concept
Rendov Norra wrote: > Yes, remote arbitrary code execution is already the norm. And if you > ask me, is precisely the reason Web browsers suck as much as they do. > Maybe it could be done well, but you'll have to forgive me, I've been > burned too many times. Fun fact, arbitrary code execution is also occasionally referred to as "executing a program".
Re: [dev] Suckless e-comerce script proposal
Hi Joseph! Joseph Graham wrote: > Hiding the internals of the system just for the sake of hiding them sounds > like > Microsoft's philosophy. Think of it the other way: what is gained by showing the user "/cgi-bin/"? I suggest it conveys 0 bits of useful information to the user, and clutters the URL. > Yep, hand coding. I suggest a static site generator, as it nicely decomposes the creation of content from the styling of the content. > Well it depends what type of shop it is... if it's a computer shop it doesn't > matter since people don't normally order 2 computers at once. Sure - but what if they want a computer and an external mouse? Or a laptop and a bag and an external power adapter? > The thing with card payments is that you give your card details to dosens of > different shopping websites, creating a large "attack surface" for those > details to be > stolen. With bank transfer there's only 1 point of failure instead of dosens. It sounds like wire transfers are more common in Europe. There are also payment processors like Stripe, Braintree, and Paypal who can handle the details of credit card processing for you, so that you don't have to deal with the hassles of securing and documenting your handling of credit card info. > Thanks for feedback I appreciate it. Of course, best of luck :) yours, Bobby
Re: [dev] Suckless e-comerce script proposal
Hi, Jochen Sprickerhof wrote: > That's country specific. In Europe it's really common and with IBAN and > BIC it's working international. Also have a look at FinTS (former HBCI) > where you have public and private keys to communicate with your bank. > And there is open source software to do all this. Are you saying that doing wire transfers in Europe is common, or doing wire transfers to pay for online goods? I'm glad to hear it is less of a horrendous experience, but it still feels like a suck idea to make customers jump through an additional hoop on their own, and expect them to correctly (and without error) copy/paste the correct amount from the order confirmation into a bank transfer form. If you suggest writing a script to automate this: it is suck to suggest customers write software to uniquely interact with your web site. yours, Bobby
Re: [dev] Suckless e-comerce script proposal
Hi Joseph, Joseph Graham wrote: > The principal is: most of the website is static. Static index pages. Static > item description pages. The item description pages link to a CGI script* with > an ID for the product in a query string. So for example > /cgi-bin/order?item=burgundy_shoes_23 First, it sucks to expose the fact that you are using a "common gateway interface" script to the user - Use a URL scheme like "/checkout?item=dope_shoes" or something. So what happens when you are out of stock on something? Do you re-generate the static pages? Or do you throw an error when the user tries to checkout? In the first case - you are re-generating (or re-caching) HTML in response to a user request, in the second, it is a sucky experience. > Becuase payment is by bank transfer user's data does not contain any financial > information, just address, name and email etc. However for privacy perhaps > user's data can be encrypted with asymmetric encryption before writing to > disk? Bank transfer? How is depending on the user to visit another website (which certainly uses JavaScript and all the things you are trying to avoid) decreasing the overall suck your users are experiencing? > -One CGI script, everything else static. Hopefully you are generating/compiling this static content from something, and not hand coding HTML on a ton of different pages. > -Can only buy one item at a time, no shopping basket. For shopping basket we > would need cookies. Buy one thing at a time, and re-enter my info a bunch of times in a row? Suck. > -Payment by bank transfer. Ever wonder why existing web sites don't do this? Because it wire transfers are terrible. Either you force users to use a bank website (Cookies + JavaScript, so you have just lost your moral high ground), or you force them to drive to a bank, or call up a bank. Such suck. If you are just thinking of suck as internal implementation complexity, you have the wrong mindset. You should be making APIs and user experiences that don't suck, even if that means you have some amount of (hidden to the user) internal implementation complexity. I don't care that YOUR life sucks less, I want you to help me make my life suck less. Besides, if you expect users to fill out an identical form for each item they want, and initiate a wire transfer on their own, you are going to go out of business. yours, Bobby
Re: [dev] "Note On Webkit Versions"
Hi, Kamil Cholewiński wrote: > Compiler-level seatbelts are too good not to have! That's how I'd see > THE candidate to replace C: safe by default, full control only when you > need it. Add: actually simple (looking at you, Go, Rust), and we'd > finally have a worthy contender. Go is a _much_ simpler language than C. Go specification: https://golang.org/ref/spec C specification: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf The _implementation_ of Go is less simple, as it includes a userspace scheduler and low-latency GC, but I don't know how you would expect to add seatbelts to C or assembly and not increase _eiter_ the language _or_ implementation complexity. yours, Bobby
Re: [dev] bluetooth without Python
Hello, Pat wrote: > I would like to install bluetooth in a lightweight maneer. > > Under Debian, would you know if it is possible to install bluetooth > without installing Python? > > bluetooth file <-> transfert works with python installed. The Linux Bluetooth stack is called BlueZ, and doesn't depend on Python. On Debian you can install libbluetooth-dev to do Bluetooth development in C. Some discussion of Bluetooth programming in C is here: https://people.csail.mit.edu/albert/bluez-intro/c404.html You may also need the helper programs located in the bluez package - that pulls in DBus + Glib. Not sure. My own limited experience is that bluez has an alright API for traditional bluetooth devices, but is sort of crap when it comes to Bluetooth LE. hope that helps. yours, Bobby
Re: [dev] [sbase] Anoncoreutils
Hi, Prog Rider wrote: > Maybe you can get some ideas from this. > It was done by a person that's all talk and no action, so don't expect > much. It's old! > http://rechan.eu.org/misc/anoncoreutils-20080617-2.tar.bz2 Are there specifics you find interesting, background or anything else you would like to point out about this tarball you're asking people to download and investigate? yours, Bobby
Re: [dev] Suckless web rendering engine
Marc Collin wrote: > Are there any plans for this? Have you tried Google Chrome?
Re: [dev] Project ideas: goblin
Hello, Gregor Best wrote: > While Uriel certainly was one of the loudest proponents of... anything > Uriel proposed, I don't think he was the only one who found Go interesting > and good. I as well find Go interesting and good. > I wouldn't use it for coreutils though, mostly because of the ridiculous > binary size. I can live with some web application or file system or other > long running daemon's binary being well over 6MB in size, but for something > like `cat` or `ls`, I wouldn't want that on my system. I've written a non-trivial program in Go, and rewrote it a year later in C. In Go, the binary size (statically linked) was 2.9 MB - when it ran it had a max of 3.1 MB of RAM resident. C, of course, was better. 59 KB statically linked against musl, 600 KB resident. The runtime is faster too, but that isn't directly comparable, as the C version uses a better algorithm. With that said, I continue to enjoy Go. 2.9 MB is frankly not that large, and it was fun and easy to prototype in. To be clear - I don't support rewriting system utilities in Go. *base are starting to look nice, and statically link down to a very small size. I don't see any wins in rewriting these in Go. Go: https://github.com/bpowers/psm C: https://github.com/bpowers/psm2 yours, Bobby
Re: [dev] [sbase] style
Hello, FRIGN wrote: >> tests (boolean) >> === >> do not test against NULL explicitly (e.g. if (!p) instead of if (p == >> NULL)) >> do not test against 0 explicitly (e.g. if (!strcmp(p, q)) instead of >> if (strcmp(p, q) == 0)) (discuss) > > Yes, yes, yes. See the patches I sent in a few days ago. By default I read if (!functioncall()) as 'if the function call failed'. I like the (strcmp(p, q) == 0) idiom because I don't fall into the trap of reading the statement as 'if the string comparison failed'. It is the one case I can think of where I prefer an explicit comparison to zero. >> early returns/exits >> === > I have no problem with goto. It often simplifies things dramatically > and there's no reason to regulate it or punish its use. Agreed - goto's for cleanup when there is local state or allocations to roll back are a godsend - otherwise use an early return. Everything else I agree with well enough. yours, Bobby
Re: [dev] c++-style comments [was fsbm]
Hello,
FRIGN wrote:
> De gustibus non est disputandum. I personally prefer {/*, */}.
Agreed - taste is taste.
> There are many ways to show why {/*, */} sucks less than {//}. Here is
> one:
> If you take a look at C, everything is block-oriented. The smallest
> linguistic entity is "...;", followed by "(...)" and "{...}". The
> traditional comments "/*...*/" are part of this axiomatic system.
> This approach is not line-oriented. Taking preprocessor
> directives and includes aside, you can literally strip all newlines
> from a given C-source and it would still compile.
Since I'm only interested in writing code that runs on an operating
system with a kernel, there is no time where I would create a binary
from C source code that doesn't #include something. This doesn't seem
to simplify any non-toy compiler implementation.
> Given we at suckless work according
> to the UNIX-philosophy, and even though UNIX-streams are mostly
> line-oriented, a C-source should not depend on non-printable characters
> to function properly (except for includes and preprocessor directives).
There is a lot of except and even though in that statement
> Moreover, if you write multiline-comments and use {/*, */} while at the
> same time using {//} for one-liners can really disrupt code consistency,
> and in the end make code harder to maintain and augment.
I happily concede this, and would have no trouble writing /**/
comments in suckless software.
yours,
Bobby
[dev] c++-style comments [was fsbm]
Hello, Hiltjo Posthuma wrote: > - Don't use C++ style comments (//). I personally find C++ style comments more pleasant on the eyes for single-line comments, and they are part of the C99 spec. Can someone explain why they think /* */ sucks less than // ? It doesn't seem like it is for compatibility when st and dwm require C99 anyway. An internet search did not turn up much, apologies if I've missed an obvious link or previous discussion. yours, Bobby
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
Hello, Sylvain wrote: > As I was asked off-list, please, keep this thread shut down. I think these are appropriate: http://38.media.tumblr.com/tumblr_m51pu9IEYc1qzm5y8o14_r1_250.gif http://38.media.tumblr.com/tumblr_m51pu9IEYc1qzm5y8o1_250.gif yours, Bobby
Re: [dev] harfbuzz
Hi Sylvain, Sylvain wrote: > I started to rewrite it, namely I unrolled the c++ code into > plain C code. But I did it only for basic layout rendering. The > API has a major race condition though (free before access), I did > try to warn the GTK+/pango devs, that was just hitting my head > against a wall. This sounds interesting, but I couldn't find anything in the harfbuzz mailing list archives about a race condition. Do you have links to the email thread? yours, Bobby
[dev] suck-less XML parsing
Hello folks, XML sucks, but I would like to write suckless code for a project that requires reading in someone elses XML. Is there an XML library that others have used that sucks-less than rest? libxml2 currently looks ahead of the pack and has few dependencies, despite its gnome pedigree. yours, Bobby
Re: [dev] What is bad with Python
Hello, Strake wrote: > * Member selection is in some cases cumbersome, in which it would not > be in C, which is related to ¬(variant types) Can you explain more what you mean? yours, Bobby
Re: [dev] [sbase] [patch] Add strlcpy()/strlcat() + refactor recurse()
Hi, sin wrote: > Please pull again from tip. It should work now. Almost. It compiles after applying the attached patch. yours, Bobby 0001-util-undef-strl-cat-cpy-in-their-.c-files.patch Description: Binary data
Re: [dev] [sbase] [patch] Add strlcpy()/strlcat() + refactor recurse()
Hello, sin wrote: > This is in preparation to moving tar(1) over to recurse() > instead of ftw(). On MacOS 10.9, strlcat and strncat are defined as macros, and adding them to sbase breaks the builds. I'm not sure what the easy/nice solution is. Error is below. yours Bobby CC util/afgets.c In file included from util/afgets.c:7: util/../util.h:23:8: error: expected parameter declarator size_t strlcat(char *, const char *, size_t); ^ /usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat' __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest)) ^ /usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz' #define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0) ^ /usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL' #define _USE_FORTIFY_LEVEL 2 ^
Re: [dev] swc: A small Wayland compositor
Hi, Michael Forney wrote: > As discussed in the previous thread (swc library to implement dwm under > Wayland), I've been working on a Wayland compositor library, and after > several redesigns, I'm pretty happy with where it is now. This is very exciting. I hope to play with this in the next few days. yours, Bobby
Re: swc library to implement dwm under Wayland (was Re: [dev] gtk3 support for surf?)
Hello, FRIGN wrote: > -1) Compositor's demands: > Not everyone has a full drm-kms-setup. Hell, I don't even use evdev > on my devices (It's more secure when you strip out the Event Interface > from the Kernel). Can you explain your thinking here on security? Is it just that less compiled code == more secure? > -2) Code-rot: > I know, there are libs, but who guarantees they're still around in a > few years _and_ compatible with the still rather "dynamic" Wayland-API? > Why not just write a Weston-plugin then? Because Weston sucks (PAM, > overengineered, too many features for dwm, ...)! Have you looked much at Weston? PAM integration is limited to 1 file & 3 functions, and could be trivially excised. > In the end, you just give up and implement it yourself, forcing you to > maintain thousands of LOC, risking bugs and wasting your time. How is this different from the tinyx project you mentioned? Ah, right, you like tinyx. yours, Bobby
Re: [dev] gtk3 support for surf?
Hello, Christoph Lohmann wrote: > Are there any arguments against switching to GTK3? Otherwise I will > switch surf to GTK3 using the smootscrolling patch. GTK3's Windows support is pretty new and not as well tested. yours in sarcasm, Bobby
Re: [dev][announce] Optimizing C compiler & c++ compiler/runtime
Hello, I'm surprised no one has mentioned the Plan 9 C compiler. There seems to be a copy here: https://code.google.com/p/ken-cc/ , it is also built as part of the Go build process. And I'm sure it is available elsewhere. Is there something glaring I am missing? yours, Bobby
Re: [dev] Optimizing C compiler & c++ compiler/runtime
Sylvain BERTRAND wrote: > Since its 4.8 version, gcc cannot bootstrap with a C > compiler/minimal runtime, it needs a c++ compiler and runtime. > Making gcc 4.7 series the last "clean" gcc. I think it is amusing that you think that gcc 4.7 is clean and good, because it is written in C. From my understanding it is an incredibly complex piece of software, and I think that it is quite possible that using some C++ will cause the GCC code base to suck less (please note I haven't specified any magnitude of sucking less, or an absolute position on the suck scale).
Re: [dev] alternatives to find for querying the filesystem
Hello, Andrew Gwozdziewycz wrote: >> $ time find / | grep 'bin' > /dev/null >> real0m8.122s >> user0m3.101s >> sys 0m2.519s >> >> $ time find / -regex 'bin' | grep >> real0m18.795s >> user0m3.394s >> sys 0m3.401s I get a different story on Linux 3.12.4: [bpowers@fina ~]$ time find / 2>/dev/null | grep 'bin' > /dev/null real 0m2.316s user 0m1.145s sys 0m1.480s [bpowers@fina ~]$ time find / -regex 'bin' 2>/dev/null real 0m2.132s user 0m0.753s sys 0m1.362s [bpowers@fina ~]$ find --version | head -1 find (GNU findutils) 4.5.11 The find -regex is consistently about 10% faster. Not much, but also not > 2x slower like you see on OSX. yours, Bobby
Re: [dev][announce] slm - music curation
Hello, Martti Kühne wrote: > I had that covered somewhere with bsd's libmagic. We don't need to set > up our own database then, I guess? Eh, I mean I just open each file under ~/Music and see if I can read an ID3 or ATOM tag from it, as both types of tags occur at the start of the file, so I'm really only checking for the magic numbers I need. yours, Bobby
Re: [dev][announce] slm - music curation
Hi, Chris Down wrote: > The file's magic number? Duh, of course. Why didn't I think of that... Implemented. I've also added an option for hardlinks, -h, and fixed a few small problems. yours, Bobby
Re: [dev][announce] slm - music curation
Hi, Branislav Blaskovic wrote: > I would detect file type by mime - not by file extension (function > is_music_file()). But that's not so important. I just remembered that we were > punished at the school when we did this :) How do you figure out mime type from a file? I understand if a server gives you a HTTP header, but if it is a static file on disk, I don't think it is guaranteed to have a mime type as an xattr. Is there a standard way to store/determine mime type? yours, Bobby
Re: [dev][announce] slm - music curation
Hello! Roberto E. Vargas Caballero wrote: > why no a option for hardlinks? Initially because I didn't want to explain to people that the music directory and the farm/db directory had to be on the same partition. An option makes sense, but should it be compile time or runtime? yours, Bobby
Re: [dev][announce] slm - music curation
Hi, Charlie Kester wrote: > Do you also support using other ID3 fields to build the database? My > music files are already stored in artist/album/ subdirectories. What > I'd really like is to have them symlinked to subdirs based on genre. > Maybe year too, in case I'm feeling nostalgic and want to play stuff > from a particlar era. Right now I only use the id3 tags mentioned. It would be pretty trivial to use other ones, but I haven't had a need for it myself. If there is interest I can add (or accept patches) to pull out more id3 tags into the Tags structure, so that personal patches that make additional DB directories are easier to carry. yours, Bobby
Re: [dev][announce] slm - music curation
Hi, Markus Teich wrote: > I would not want compilations from 20 different artists to show up under every > one of those artists. Me neither. >> - consider `&`, `feat`, `feat.`, `featuring`, `,`, &c. as separators >> in the artist field? > > This is also annoying. I've settled with both problems by setting the > albumartist field for every track and choosing just one of the remaining > artists > as the real one. Albumartist may be too complex already, but if you allow > multiple artists per track, it only gets worse. I'm going to look into albumartist, I find this bothersome too. Thanks, Bobby
[dev][announce] slm - music curation
Hello!
This is a followup to last months "music db editor" thread:
http://lists.suckless.org/dev/1310/17781.html
I've completed an initial implementation of a program which parses
music file metadata (currently only ID3 tags for MP3 support,
ATOM/AAC is next) and creates a filesystem-based farm/'DB' of
symlinks. A file at '~/Music/somesong.mp3' that had proper ID3 tags
would result in the following two symlinks being created:
"${FARM_DIR}/artists/Some Artist/The Album/1_The Title.mp3" ->
$HOME/Music/somesong.mp3
"${FARM_DIR}/albums/The Album/1_The Title.mp3" -> $HOME/Music/somesong.mp3
Where FARM_DIR is defined in config.h.
Comments on this approach & the code are very welcome:
https://github.com/bpowers/slm
yours,
Bobby
Re: [dev] [slock] [patch] Set errno to 0 before getpwuid() and check it afterwards
Hello, sin wrote: > Just a small fix. Looks good to me. yours, Bobby
Re: [dev] Suckless remote shell?
2013/11/4 Szabolcs Nagy : > the state-of-the-artedness is not a virtue of a programming language Agreed. At the same time, I don't think 'it is not C' should be an automatic point against a language. C is excellent and quite useful, however Go's language is wonderfully simple and makes expressing certain things quite clear an succinct. > the main problem with go is that (like java and many other high level > languages) it tries to ignore unix legacy while building on it It was written by the people behind plan 9. It is somewhat of an appeal to authority, but I tend to give the Go authors the benefit of the doubt when it comes to the unix legacy. > go is special in that it builds on the binary syscall layer instead of > the somewhat portable c api (the syscall layer is not even expected to > be stable on every unix, openbsd just broke it to have 64bit time_t > on 32bit systems, so go releases and existing go binaries are broken > on the latest 32bit openbsd) As are all statically linked C binaries, Go isn't special here. OpenBSD broke their ABI. > so the go ssh package is not useful for programs written in c (they can > only use it through some ipc mechanism, not in the same process) True, I did not mean to imply it should be used from C, just that it is the only sane SSH implementation I've personally looked at. > go cannot completely replace the c ecosystem in the unix userspace > because of its runtime (gc etc) so we are left with yet another set > of reimplementation of the world, a separate platform to maintain > for eternity Why does the go runtime & GC mean that it cannot replace the C unix userspace? Or are you saying that you see the runtime as overcomplicated, so you do not wish unix userspace to be replaced with a unix userspace written in Go? yours, Bobby
Re: [dev] Some thoughts about XML
2013/10/24, Alexander S. : > Personally, I'm okay with XML, and feel like Archangel Uriel, may he > rest in peace, was slightly exaggerating. XSLT may be horrid, though, > and XML is maybe *too* verbose, but the idea of having a structure as > a building block is totally okay with me. There is expat parser, and > who needs anything else. > Using XML for simple, non-hierarchical config files is just plain > wrong, not because XML is bad, but because it is misapplied. Using XML > for storing Rhythmbox music database is wrong for the same reason. XML > is for documents. I think Russ Cox said it very well[1]: Mapping between XML elements and data structures is inherently flawed: an XML element is an order-dependent collection of anonymous values, while a data structure is an order-independent collection of named values. See [...] json for a textual representation more suitable to data structures. 1 - http://tip.golang.org/src/pkg/encoding/xml/read.go?s=257:579#L7
Re: [dev] Some thoughts about XML
On Fri, Oct 18, 2013 at 3:09 PM, Szymon Olewniczak wrote: > I've started this topic becouse I'm woriking in a small family firm and > we have decided that we need an new application to managing complaints, > documentation, and several other things of our clients (I don't want to > go into detail). So I'm thinking about model that would make it usable > for peoples like me and for non-tech users. XML + XSLT is one > of my ideas, another is "one file web application" based on JSON > calls (maybe its better, what do you think?). I believe that we can make > the web the better place without huge revolutino(such as changing HTTP > to something else) or maybe I am wrong. JSON is much better than XML for passing data structures around and maintaining sanity.
Re: [dev] music db editor
On Tue, Oct 15, 2013 at 11:10 AM, Martti Kühne wrote: > 3.: I don't have any need to collect metadata about my music I run off mpd, > and > if I had the need, I could build symlink trees from my already sane directory > structure: > > music/A/Artist/Album/trackname.flac > > That way I could add whatever metadata I could think of on any point in the > tree - and in actual filesystem metadata, since, that's where metadata goes, > right? As an example, I could list albums by different artists in a "weird" > directory and link all the weird music there, residents, die antwoord, etc. yes, yes, this seems like the way to do it. I like this much better than the sqlite I had been using, thanks for the encouragement. > I myself have a lot of unknown artist id3v2 tags and broken encodings in that > data, but I don't much need to give one, since I know where to find my > stuff... > > Also, where's the code? I'd be interested to try stuff out, especially 3 > figure > SLOC projects as it's tradition in this part of the net... I'm going to work on this later this week, I'll post something with hopefully minimal suck then. yours, Bobby
Re: [dev] I got a fever, and the only prescription ...
On Wed, Oct 16, 2013 at 5:41 AM, Nick wrote: > At the risk of being forever shunned, I actually quite like what I > hear about kdbus. It sounds like a *way* better way of doing what > the dbus people have done so awfully - and very much not just a > "throw it in the kernel 'cos that's faster approach" (though IIRC > they tried that originally). I'm particularly pleased that it looks > like it will be able to replace Android's Binder in a way better and > more secure way. Agreed. The developer behind it also has had (generally) good things to say about suckless: https://plus.google.com/111049168280159033135/posts/fMe7yuaDXKA
Re: [dev] music db editor
I started on a project a while ago that may be a helpful starting
point. It is a daemon written in C that watches a directory with
inotify ("~/Music" by default), tracks metadata about music files in a
sqlite3 database, and responds to HTTP queries about artists and
authors with JSON. It fits my needs perfectly well; I use it every
day to listen to music, although there are certainly aspects that
could be improved. I'm open to suggestions and criticisms. It
currently has 4 deps: taglib, sqlite3, libevent2, and glib. It looks
like the only thing I'm using glib for is URI escaping (this was
written before I was trying to suckless), it could easily be removed.
https://github.com/bpowers/cnote
usage:
$ curl localhost:1969/artists # list all artists, returns array of strings
[
"A Tribe Called Quest",
...
]
$ curl localhost:1969/albums/Soul%20Limbo # info about tracks in an album:
[
{
"album": "Soul Limbo",
"artist": "Booker T. & The M.G.'S",
"path":
"amazonmp3/Booker_T__&_The_M_G_'S/Soul_Limbo/B000UBJSDO_(disc_1)_01_-_Be_Young,_Be_Foolish,_Be_Happy.mp3",
"title": "Be Young, Be Foolish, Be Happy",
"track": "1"
},
...
]
On Sat, Oct 12, 2013 at 7:34 AM, Manolo Martínez
wrote:
>> > on the files to be tagged. Does anyone here use another program for this
>> > purpose?
>>
>> http://musicbrainz.org/doc/MusicBrainz_Picard
>>
>
> Thanks, I'll give it a try.
>
Re: [dev] [PATCH] st: Use ascent + descent for font height to avoid clipping underscores.
Thanks William, I will do that in the future. On Sun, Mar 10, 2013 at 4:52 PM, William Giokas <1007...@gmail.com> wrote: > On Sun, Mar 10, 2013 at 04:28:37PM -0400, Bobby Powers wrote: > > ha, sounds reasonable :) thanks Christoph! > > > > > > On Sun, Mar 10, 2013 at 4:17 PM, Christoph Lohmann <2...@r-36.net> wrote: > > > > > Greetings. > > > > > > On Sun, 10 Mar 2013 21:17:38 +0100 Bobby Powers > > > > wrote: > > > > Has an issue with st where the _'s were being overwritten when text > on > > > > the next line was drawn. This didn't happen in gnome-terminal, which > > > > uses pango for its font rendering. Pango's Xft backend uses ascent + > > > > descent rather than height. This appears to date back to at least > > > > 2004 (pango commit 5bf0c1d0) so I'm not sure their exact reasoning, > > > > but it fixes the Monospace font height issue I am seeing. > > > > > > I applied the patch without the big useless comment. If there would be > a > > > comment about all wrong behaviour of xft and how bad the fontconfig > API > > > is, st would double its raw source size. > > > > > When you send a git patch, you can put a message under the `---` but > above the diffstat and it'll not be included when you run `git am`. I > usually throw descriptions and reasoning in there. > > Thanks, > -- > William Giokas | KaiSforza > GnuPG Key: 0x73CD09CF > Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF >
Re: [dev] [PATCH] st: Use ascent + descent for font height to avoid clipping underscores.
ha, sounds reasonable :) thanks Christoph! On Sun, Mar 10, 2013 at 4:17 PM, Christoph Lohmann <2...@r-36.net> wrote: > Greetings. > > On Sun, 10 Mar 2013 21:17:38 +0100 Bobby Powers > wrote: > > Has an issue with st where the _'s were being overwritten when text on > > the next line was drawn. This didn't happen in gnome-terminal, which > > uses pango for its font rendering. Pango's Xft backend uses ascent + > > descent rather than height. This appears to date back to at least > > 2004 (pango commit 5bf0c1d0) so I'm not sure their exact reasoning, > > but it fixes the Monospace font height issue I am seeing. > > I applied the patch without the big useless comment. If there would be a > comment about all wrong behaviour of xft and how bad the fontconfig API > is, st would double its raw source size. > > > Sincerely, > > Christoph Lohmann > > >
[dev] [PATCH] st: Use ascent + descent for font height to avoid clipping underscores.
My preferred font:
"Monospace:pixelsize=15:antialias=true:autohint=false:hintstyle=hintfull"
Has an issue with st where the _'s were being overwritten when text on
the next line was drawn. This didn't happen in gnome-terminal, which
uses pango for its font rendering. Pango's Xft backend uses ascent +
descent rather than height. This appears to date back to at least
2004 (pango commit 5bf0c1d0) so I'm not sure their exact reasoning,
but it fixes the Monospace font height issue I am seeing.
---
st.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/st.c b/st.c
index fc9ed70..436a60b 100644
--- a/st.c
+++ b/st.c
@@ -2493,7 +2493,12 @@ xloadfont(Font *f, FcPattern *pattern) {
f->lbearing = 0;
f->rbearing = f->match->max_advance_width;
- f->height = f->match->height;
+ /* pango's get_glyph_extents_xft uses ascent + descent rather
+* than height. In some cases ("Monospace:pixelsize=15" at
+* least) height is 1 px smaller than ascent + descent, which
+* leads to underscores getting clipped and appearing as
+* spaces. */
+ f->height = f->ascent + f->descent;
f->width = f->lbearing + f->rbearing;
return 0;
--
1.8.1.4
