[dev] [sent] initialize .img

[Szabolcs Nagy]

without the attached patch ./sent example segfaults here
diff --git a/sent.c b/sent.c
index 1b3b8f2..fb0b56e 100644
--- a/sent.c
+++ b/sent.c
@@ -394,6 +394,8 @@ void load(FILE *fp)
 			die("cannot strdup %u bytes:", strlen(buf)+1);
 		if (slides[i].text[0] == '@')
 			slides[i].img = pngopen(slides[i].text + 1);
+		else
+			slides[i].img = 0;
 		i++;
 	}
 	if (slides)

Re: [dev] [st] Problem linking in OpenBSD

[Szabolcs Nagy]

* Dimitris Papastamos  [2014-07-09 07:10:57 +0100]:
> On Wed, Jul 09, 2014 at 01:16:05AM +0200, FRIGN wrote:
> > On Tue, 8 Jul 2014 22:45:15 +0200
> > "Roberto E. Vargas Caballero"  wrote:
> > 
> > > cannot find -lrt
> > 
> > The fix is rather trivial: Just remove the damn -lrt.
> > Seriously: On OpenBSD, you don't need to include any libs to use
> > time.h; on Linux, this is only necessary for glibc-versions below 2.17.
> 
> They should at least provide an empty -lrt or ignore it.


-l rt is a posix requirement

(certain standard symbols may only be available for linking if the
specified -l flags are given to c99, see the extended description in

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11_13

so yes, to avoid toolchain issues a reasonable libc implemetation
should provide empty versions of the libs required by the standard)

Re: [dev] C coded cross-platform youtube video viewer

[Szabolcs Nagy]

* hiro <23h...@gmail.com> [2014-06-03 21:05:23 +0200]:
> choose a stream, meaning of itags is on wikipedia article of youtube.
> wget -q -O - 'http://www.youtube.com/watch?v=Ux1Za8Wmz_s'|sed
> 's/"/\n/g; s/\\u0026/ /g; s/,/\n/g'|sed -n
> '/url_encoded_fmt_stream_map/,/^$/p; /adaptive_fmts/,/^$/p'
> 

yes, but google likes to change the format occasionally

the urls contain a signature argument which is sometimes stored
separately and without it you'll get 403

the signature is sometimes scrambled with generated, obfuscated
javascript code, with wrong signature you'll get 403

i did the js parsing in yget, but i probably wont keep up with
the changes of youtube in the future
http://www.repo.hu/projects/yget/

> One very nice new thing i discovered by going the manual way without
> the stupid quvi (which sadly randomly stopped working at some point
> for me) was that they now at least they have pure audio files
> together with that adaptive streaming bullshit, so I don't need ffmpeg
> for my purposes any more. Try itag 171 or 140, e.g.
> wget -q -O - 'http://www.youtube.com/watch?v=Ux1Za8Wmz_s'|sed
> 's/"/\n/g; s/\\u0026/ /g; s/,/\n/g'|sed -n '/itag=171/s/^.*url=//p'
> 

yes they had that for a while, but i don't know any player that
can stream from separate video and audio streams reliably
(other than the browsers)

there are text streams too for subtitles but i havent checked how
it works now since the last time they changed the format

> Then you need to remove the percentencoding, I'm sure you guys might
> be able to come up with a C tool for that.

Re: [dev][ubase] Implement switch_root

[Szabolcs Nagy]

* Dimitris Papastamos  [2014-04-15 17:57:25 +0100]:
> On Tue, Apr 15, 2014 at 06:44:54PM +0200, Markus Wichmann wrote:
> > Why switch_root and not pivot_root? Here's a sh mockup of how to do what
> > you wrote with pivot_root:
> > 
> > set -e
> > new_root=$1
> > put_old=$2
> > [ -d $put_old ] || made_dir=1
> > mkdir -p $put_old
> > cd $new_root
> > pivot_root $new_root $put_old
> > chroot $new_root
> > umount ${put_old#$new_root}
> > [ $made_dir ] && rm -rf ${put_old#$new_root}
> 
> Because if it is a shell script then it cannot be included in ubase-box

i just note that pivot_root is a linux system call
so implementing that tool is a one-liner in c

so it is easy to add if it's missing from ubase

Re: [dev] What is bad with Python

[Szabolcs Nagy]

* Silvan Jegen  [2014-03-04 21:30:47 +0100]:
> On Tue, Mar 04, 2014 at 08:56:18PM +0100, Szabolcs Nagy wrote:
> > dont expect fast opengl access from go) and you cannot really
> > use it for quick scripting tasks
> 
> Why should Go not be suited for quick scripting tasks? I use Go to parse
> text files, reformat them and/or sending them to restful services. It
> really works quite well.

eg i have various awk, lua and sh scripts on my router
to do things, if there is some bug in them i can log in
to the router and fix them right there or try them on
another host

i don't need a cross compiler toolchain for this or
complicated setup for deploying different binaries
to different systems
(not to mention that a statically linked go executable
would not even fit on the target and the compiler would
pedantically complain about unused package imports or
other issues that does not matter in a single-use script)

for me scripting means that you can write one-liners to
a command prompt or edit a single text file with iterative
updates and don't need development tools to execute it

maybe go has a better http library than other languages,
so you can easily automate such tasks, but that does not
make it a scripting language imo

Re: [dev] What is bad with Python

[Szabolcs Nagy]

* Silvan Jegen  [2014-03-04 14:27:26 +0100]:
> On Tue, Mar 4, 2014 at 9:25 AM, FRIGN  wrote:
> > A question to everyone on this list: What do you think about the
> > Go-language?
> 
> I used Python for all my scripting needs before Golang hit version 1.0

i hear this a lot and don't quite understand

you use python as a glue language (between dynamically
loadable extensions written in c and wrapped so one can
use them from python: the drawback here is that as usual
the heavy python runtime has unspecified interactions with
the c runtime eg. if you load a lib that starts threads and
then you call os.fork() from python) or for writting
scripts/single shot programs/prototypes (where the simple
syntax, dynamic types, repl etc helps)

go is not very good for either of these: it cannot directly
interact with anything written in c (it has a hack (cgo) to
initialize the c runtime in a separate thread but that's
rather fragile and slower than a direct function call, eg.
dont expect fast opengl access from go) and you cannot really
use it for quick scripting tasks

go can be used when you interface with software across
network or process boundaries (it cannot interface with
existing libraries easily so they have to rewrite every
userspace lib in go, however it can interface with os
syscalls as long as the syscall abi is stable: it is not
on some systems such as openbsd)

> It is not without its problems though:
> 
> * There are no generics (it is not clear at the moment whether they

i dont get this either

you can do a lot of things without generics and
just generate code when that's what you need..

> * The XML/JSON unmarshaling is cumbersome (I think I prefer the

i dont think this is the bigest issue in go..

it has segmented stack and you cannot handle reliably if
a goroutine stackgrow fails to allocate (and it is slower
than just using huge stack in a 64bit address space), it has
userspace n:m task scheduling with it's known issues (no
preemptive scheduling etc) and a gc with potentially large
memory overhead and high latency so you cannot use it for
anything with hard-realtime constraints, it does not have fenv
access semantics or long doubles on hw that supports this, so
not really suitable for scientific computing (well barely
anything can do this other than c, fortran or asm) the math
library is not very high quality either and various builtin
packages are much less optimized than the ones available in c
(big, crypto, regex, image..), so often simple python scripts
can beat go in performance, heavy usage of go interfaces and
runtime type information can make things slow as well

Re: [dev][PATCH][quark] Clean up the log-facility

[Szabolcs Nagy]

* FRIGN  [2014-03-03 19:39:13 +0100]:
> +static void log(int type, const char *errstr, ...);

note that stdlib.h may include math.h which declares log
with a different type

such namespace issues can be fixed by using another name or

 #undef log
 #define log quark_log

after the header includes and before the declarations

Re: [dev] XML vs HTML (was: Article about suckless on root.cz)

[Szabolcs Nagy]

* FRIGN  [2014-02-21 12:03:00 +0100]:
> I really don't see your point why exactly XML should be bad for the
> web.
> If you write proper, well-formed markup, nothing really changes for
> you, except that the browser _knows_ it's dealing with proper markup
> and doesn't have to "fire up" it's forgiving but sloppy SGML-parser.
> 
> It may not be clear here that switching from SGML to XML parsing only
> incorporates changing the MIME-type from text/html to application/xhtml
> +xml.

xml is not just markup but

http://www.w3.org/TR/REC-xml/#charencoding
(mandatory utf-8 and utf-16 support with bom)

https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
(xml injection, unauthorized document access)

https://en.wikipedia.org/wiki/Billion_laughs
(DoS: exp or quadratic blowup of entities)

and various xml validation issues and implementation bugs..

it's much better to use a restricted specific language
with simple well defined semantics than generic things
like sgml and xml (with arbitrary long tag and attribute
names), once you do this the origin (sgml, xml,..) does
not matter

Re: [dev] Announcing sinit - the suckless init

[Szabolcs Nagy]

* sin  [2014-02-07 21:26:11 +]:
> On Fri, Feb 07, 2014 at 05:26:54PM +0100, Szabolcs Nagy wrote:
> > note that strake got that init code is from Rich Felker
> > and there is more to it than that code.. (you may find
> > related discussions on the musl mailing list archive,
> > he also planned to write about reliable init systems on
> > ewontfix.com so you may want to check that out as well)
> > 
> > > [2] https://github.com/strake/init
> > 
> > compare to
> > https://gist.github.com/rofl0r/6168719
> 
> nsz, thanks for clarifying!  I will give proper credit
> to Rich Felker and check out the discussions.

and here is the promised writing

 http://ewontfix.com/14/

(see "So how should init be done right?" section)

Re: [dev] Announcing sinit - the suckless init

[Szabolcs Nagy]

* sin  [2014-02-06 12:32:59 +]:
> As part of experimenting with a toy distro I wanted to get rid of
> busybox's init, so I hacked together sinit[1].  sinit is based on Strake's
> init[2].

note that strake got that init code is from Rich Felker
and there is more to it than that code.. (you may find
related discussions on the musl mailing list archive,
he also planned to write about reliable init systems on
ewontfix.com so you may want to check that out as well)

> [2] https://github.com/strake/init

compare to
https://gist.github.com/rofl0r/6168719

Re: [dev] [sbase] [patch] Add strlcpy()/strlcat() + refactor recurse()

[Szabolcs Nagy]

* Bobby Powers  [2014-01-30 09:38:23 -0800]:
> 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.

all standard interfaces may be also defined as macros
so this is nothing special (eventhough strl* arent standard)

the correc way to declare anything that may appear in a
standard header is to #undef or protect the declaration like

 #undef strlcat
 size_t strlcat(char*,const char*,size_t);

or

 size_t (strlcat)(char*,const char*,size_t);

Re: [dev] [PATCH][RFC] Add a basic version of tr

[Szabolcs Nagy]

* Silvan Jegen  [2014-01-15 22:32:28 +0100]:
> On Wed, Jan 15, 2014 at 09:36:07PM +0100, Szabolcs Nagy wrote:
> > > +handleescapes(char *s)
> > > +{
> > > + switch(*s) {
> > > + case 'n':
> > > + *s = '\x0A';
> > > + break;
> > > + case 't':
> > > + *s = '\x09';
> > > + break;
> > > + case '\\':
> > > + *s = '\x5c';
> > 
> > what's wrong with '\n' etc here?
> 
> I am not sure what you mean. My interpretations:
> 

i mean instead of *s='\x0a' you can write *s='\n' and it's clearer
same for '\t' and '\\'

> a cold so that has to wait...). I noticed that it uses the threadsafe
> version of the mbtowc function. Do you think that is advisable in
> general?

the point of mbrtowc is not to be thread-safe but to be able to
restart the decoding (it records the decoding state)

so you can feed a buffer into mbrtowc by looping until the end
and continue later even if the buffer ended in the middle of a
character sequence (or you can use it to decode the input one
char at a time)

mbtowc reports an error on an incomplete sequence and you don't
know if it's an illegal sequence or you just need more input
(not a problem if you have all input in one buffer)

Re: [dev] [PATCH][RFC] Add a basic version of tr

[Szabolcs Nagy]

* Silvan Jegen  [2014-01-15 20:43:54 +0100]:
> Note, though, that GNU's tr does not seem to handle Unicode at all[1]
> while this version of tr, according to "perf record/report", seems to
> spend most of its running time in the Unicode handling functions of glibc.

multi-byte string decoding is known to be slow in glibc

eg see the utf8 decoding benchmark in
http://www.etalabs.net/compare_libcs.html

> By no means was this any serious benchmarking but eliminating the function
> pointer did not seem to make an obvious difference.

note that recent gcc (4.7?) can do function pointer inlining
if it can infere that the function is in the same tu
(and with lto it can probably do cross-tu inlining)

> +void
> +handleescapes(char *s)
> +{
> + switch(*s) {
> + case 'n':
> + *s = '\x0A';
> + break;
> + case 't':
> + *s = '\x09';
> + break;
> + case '\\':
> + *s = '\x5c';

what's wrong with '\n' etc here?

btw a fully posix conformant tr implementation is available here:
http://git.musl-libc.org/cgit/noxcuse/tree/src/tr.c

(but this is probably outside of the scope of sbase)

Re: [dev] Suckless remote shell?

[Szabolcs Nagy]

* Alexander S.  [2013-11-08 08:22:37 +0400]:
> There seems to be some misunderstanding about what is type-safety and
> when checks are made.

as i said this static type-checking fantasy does not work without
runtime type information, not because you need any further checks
at runtime, but because each type has different representation
(abi call type class, inmemory alignment, size, etc)

(x86_64 type classes with different argument and return value passing
methods: memory, integer, sse, sseup, x87, x87up, complex_x87, no_class)

> They are actually made when you are calling a function with signature
> described above. I used higher-order lambda to express the notion
> that, for example, an extra argument in pthread_create is the same
> type as the only argument to its entry point. To the *implementation*,
> these are just opaque pointers. We don't get our typechecking by
> substituting templates and checking that calls don't violate the
> rules; something more beautiful is going on here. (C++ templates don't
> support type lambdas, sadly).

the opaque pointers work if you convert them to void* and back
(the c way), you could make that safer probably in this particular
case, but only for single object pointers, not what you described
earlier (passing arbitrary number of arbitrary objects)

the callback still has to accept a void* argument, but a
parametrized void*: the representation and call abi would be
as if void* is passed, but the type-checker can take the
parameter as a hint about the type that is implicitly converted
to this void*

as you can see it's more complicated and less useful than what
you described, different pointers are not the same (eventhough on
most architecture they are, the compilers treat them differently
for various reasons)

you can fix a few type-unsafe cases with this, but not all, and
the consequence is that the type of the caller and the callback
functions become much more complicated (it's already hard to write
down function pointer types in c, there is a reason why ml had to
invent type inference, you don't want to go there with c)

> Structures are usually passed by pointer anyway if they don't fit in
> 64-bit register, I believe?

no

you underestimate the complexity of what you want to do and
overestimate its benefits

any solution should take into account the current c call abi on
widely used architectures, otherwise it's useless, unfortunately
modern languages approach the problem from high-level abstract
type-theory (which is the easy part of the challenge) instead of
the hard facts about the arch abis (making it a pain to interact
with existing systems if that's possible at all)

Re: [dev] Suckless remote shell?

[Szabolcs Nagy]

* Alexander S.  [2013-11-08 02:10:49 +0400]:
> 2013/11/7 Szabolcs Nagy :
> > with a single pointer arg this assumes that all pointers have
> > the same representation or that you create a separate version
> > of pthread_create for every type used
> Pthread_create doesn't need to know anything about the type of the
> pointer! In fact, nobody except the typechecker needs to.

if different pointers have different representations
then the caller needs to know that at runtime to pass
the argument to the callback

> Runtime information is only needed if you are going to actually
> introspect that arbitrary number of args. If you are going to plop
> them back onto the stack, the only thing you need to know is a total
> size, which can be calculated in compile time.

that's not how the function call abi works

and what you describe can be done now in c without the syntax:
allocate a char array on the stack serialize everything into it,
and pass the pointer and size

you don't get typesafety, but that cannot be done in general
accross a serialize/deserialize step, you could only type
check a few special case of that at best.. by making things
more complicated

> expansion C varargs undergo. But, I suppose, asking that all arguments
> be either floating-point or pointer-size isn't asking too much. It is
> doable.

the size is not all

there are function pointers, structures with alignment requirements,
paddings and bitfields, some implementations support more than three
different floating-point types..

in the end you either have runtime type information to be able to
unpack the arguments and construct calls with them or you have what
c has now

Re: [dev] Suckless remote shell?

[Szabolcs Nagy]

* Alexander S.  [2013-11-07 16:55:35 +0400]:
> Context pointers for callbacks... well, they exist because of the
> limitations of the type system. I'd rather see
> ?A,[Types...].pthread_create(pthread_t*, A(*callback)(Types...), Types
> args...) (so, arbitrarily many additional args for callbacks). A
> type-checker can properly check it, and even in current calling
> conventions, it's quite fast to handle: you just copy a chunk of
> memory fro and to stack, wholesale. Failing that, there's always
> ?A,B.pthread_create(pthread_t*, A(*callback)(B), B arg).

with a single pointer arg this assumes that all pointers have
the same representation or that you create a separate version
of pthread_create for every type used

arbitrary number of args does not work: you need runtime type
information for that (which is complex, slow and problematic
to define the binary interface), var arg calls are not just
passing a chunk of memory on the stack (would be suboptimal
on archs like x86_64 with lot of registers)

> mmap is another matter, but whether for turning file into RAM or for
> IPC, it tends to have some structure, I guess?

you can allocate memory with mmap and reuse it several times for
different type of objects or you may need to parse the mmaped
data so you don't know static types

Re: [dev] Suckless remote shell?

[Szabolcs Nagy]

* Alexander S.  [2013-11-07 04:27:26 +0400]:
> Seriously, simple parametric types wouldn't hurt C. Not at all. No
> need for that automatic pointer conversion, additional parameters to
> sort() and alike, and such. (I'm going to make a confession, I really
> think C would benefit from C++ templates, even in their current
> state).

c has no implicit pointer conversion other than for void*

void* is important to represent pointers in a generic way,
parametric types do not help with this, those assume a
statically known type which is not always the case

the way c++ eliminated the implicit conversion is actually
less safe than the c semantics: in c++ one has to use casts
to convert void* and this turns off the type-checker

there are plenty source for void pointers: mmap, dlsym,
context pointers for callbacks, etc. if you incorrectly
assume in c that a pointer is void* then you get a type error,
in c++ your cast will mask this error so it can go unnoticed,
in c a cast is a code smell that alarms you, in c++ they are
not uncommon at all in code interacting with the os, actually
c++ has at least 4 different casts with different semantics
based on what you cast, this is not how to improve safety

parametric types have problems on their own: eg the type
parameters have to be encoded into the name of the interface
which gives rise to name mangling with all its warts
(c++ name mangling is not specified so you get a fragile binary
interface with names so long that the hash lookups by the elf
dynamic loader becomes a bottleneck..)

Re: [dev] Suckless remote shell?

[Szabolcs Nagy]

* Louis Santillan  [2013-11-04 23:19:21 -0800]:
> I wasn't suggesting anybody use newlib.  Rather, I was suggesting that
> all the interface a C, or Go, or Java, or ASM program ever needs
> between it and the "POSIX" OS is contained in 17 syscalls.  That's
> about as minimal, or suckless as you can get.  The fact that the
> newlib folks identified that fact is inconsequential.

newlib can be useful for baremetal or other embedded work

but you don't get far with 17 syscalls on unix, pretending
you do is just delusional

(with the listed syscalls you cannot even select for events,
or implement bsd socket api or any other networking stack
even if you try to export every os interface to the filesystem
like plan9 does you still don't have mount, you don't have
large file support, no hi res timer, no interrupt handling,
no clone or thread support etc)

i recommend you to strace a java hello world to see how many
syscalls java need.. (don't forget to use -f, it will create
threads)

Re: [dev] Suckless remote shell?

[Szabolcs Nagy]

* Bobby Powers  [2013-11-04 13:10:56 -0500]:
> 2013/11/4 Szabolcs Nagy :
> > 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.

if the abi is not a public interface then any project depending
on it should expect breakage, static c code can be recompiled
and it will work (assuming portable c code)

but it is not enough to recompile the go runtime, they have to
update their syscall wrappers

since go is not maintained together with the os they have to
worry about different versions of the os vs different versions
of the go runtime working together otherwise go programs and
go programmers are in trouble on openbsd

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

i don't mind if the c userspace is replaced with somehing else
i just think it's hard to do and go cannot do it
(note that go was never advertised as a c replacement, the authors
wanted it for specific applications in mind: mostly large scale
networked systems software running on servers i guess)

avoiding dynamic allocations, working correctly even when the
system runs out of memory, directly handling signals without
userspace scheduling overhead, accessing the floating-point
environment are all difficult or impossible in go

and there is performance overhead inherent to the language
(gc and scheduler are not in the application's control,
interfaces require runtime type information, no inline asm
means arch specific code has func call overhead, etc)

these are relevant to some applications and libraries

it is also a lot of work to rewrite everything (there are
closed video drivers on linux linked against glibc, lot of
programming languages and tools depend on the behaviour of
the c runtime which should be reinvented not just
reimplemented, and getting a usable toolchain for every
relevant architecture is difficult enough)

Re: [dev] Suckless remote shell?

[Szabolcs Nagy]

* Alexander S.  [2013-11-04 17:11:40 +0300]:
> 2013/11/4 FRIGN :
> >
> > No one ever said it, because it is expected to be in C.
> > Go is a disgrace and I'm glad every time I see a Go-Project bit-rot to
> > death.
> >
> Don't want to start a flame, but C isn't exactly state of the art
> language. I shall agree that Go has problems, but why it would be a
> disgrace any worse than a living fossil C is?

the state-of-the-artedness is not a virtue of a programming language

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

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)

the consequence is that you cannot use go libraries from c code and using
c libraries from go code is a hack (relies on internal libc api behaviour
and currently on linux it only works with glibc) because the go runtime
cannot work with the c runtime in the same process

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)

as you can see the problem is not related to the modernity of the
language, but to the interoperability with the existing ecosystem

self-contained tools can be written in go (those can be developed in
any language) but if you want to share code with other projects you
have a problem

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

Re: [dev] [sbase] [patch] Add sha256sum(1)

[Szabolcs Nagy]

* Galos, David  [2013-07-20 00:50:25 -0400]:
> >> +/*
> >> + * public domain sha256 crypt implementation
> >> + *
> >> + * original sha crypt design: 
> >> http://people.redhat.com/drepper/SHA-crypt.txt
> >> + * in this implementation at least 32bit int is assumed,
> >> + * key length is limited, the $5$ prefix is mandatory, '\n' and ':' is 
> >> rejected
> >> + * in the salt and rounds= setting must contain a valid iteration count,
> >> + * on error "*" is returned.
> >> + */
> >
> > this comment for the sha2 based crypt implementation
> > not for the hash function
> 
> Is there some replacement text that you suggest? I figure we might as well
> note where this sha2 implementation originates from. Is anything further
> than the fact that it's public domain known?

/* public domain sha256 implementation based on fips180-3 */

you may add that it's from the crypt code of musl libc
in case somebody wants to check upstream changes

Re: [dev] [sbase] [patch] Add sha256sum(1)

[Szabolcs Nagy]

* sin  [2013-07-19 16:34:07 +0300]:
> +/*
> + * public domain sha256 crypt implementation
> + *
> + * original sha crypt design: http://people.redhat.com/drepper/SHA-crypt.txt
> + * in this implementation at least 32bit int is assumed,
> + * key length is limited, the $5$ prefix is mandatory, '\n' and ':' is 
> rejected
> + * in the salt and rounds= setting must contain a valid iteration count,
> + * on error "*" is returned.
> + */

this comment for the sha2 based crypt implementation
not for the hash function

(it turns out the sha2 based password hashing, widely
used on linux systems (default on most distributions),
has atrociously bad design so we had to make some
changes in musl hence the comment)

Re: [dev] coreutils / moreutils - DC a directory counter

[Szabolcs Nagy]

* Szabolcs Nagy  [2013-07-18 18:51:09 +0200]:
> PATH_MAX is posix and should be defined in limits.h
> FILENAME_MAX is iso c and is defined in stdio.h (usually PATH_MAX-1)

sorry i was wrong about the -1
FILENAME_MAX is buffer size, not string length

Re: [dev] coreutils / moreutils - DC a directory counter

[Szabolcs Nagy]

* Markus Teich  [2013-07-18 18:37:57 +0200]:
> 
> isn't PATH_MAX a GNU extension?
> 

no, actually gnu hurd was a proponent of unlimited paths
(so any file operation has unbounded latency on hurd only limited by
the address space)

PATH_MAX is posix and should be defined in limits.h
FILENAME_MAX is iso c and is defined in stdio.h (usually PATH_MAX-1)

Re: [dev] Re: coreutils / moreutils - DC a directory counter

[Szabolcs Nagy]

* Calvin Morrison  [2013-07-17 16:43:00 -0400]:
> On 17 July 2013 16:32, Christian Neukirchen  wrote:
> >> calvin@ecoli:~/big_folder> time ls file2v1dir/ | wc -l
> >> 687560
> >>
> >> real0m7.798s
> >> user0m7.317s
> >> sys 0m0.700s
> >>
> >> calvin@ecoli:~/big_folder> time ~/bin/dc file2v1dir/
> >> 687560
> >>
> >> real0m0.138s
> >> user0m0.057s
> >> sys 0m0.081s
> >>
> >> What do you think?
> >> Calvin
> >
> > What's the bottle neck here?
> 
> Looking up the filenames and reading them, printing them to standard
> out and then wc parsing for all the \n characters.
> 

if it's coreutils ls|wc then most of the time is
locale specific code (strcoll and encoding related),
try

export LC_ALL=C
ls -f |wc -l

Re: [dev] [sbase] Patch to make md5 and sha1 more similar

[Szabolcs Nagy]

* Jens Nyberg  [2013-07-15 16:51:29 +0200]:
> Hehe and I almost thought about changing to (x & 0x3f) instead of (x % 64)
> but decided to skip that one =)
> 

note that
x&63 and x%64
x>>6 and x/64
x<<6 and x*64
are not the same when x might be negative

(if x is negative then x&63 depends on the signed int representation,
but guaranteed to be in [0,63] while x%64 is in [-63,0], x>>6 is
implementation defined and usually very different from x/64 and
x<<6 is undefined while x*64 is only undefined when it overflows)

so the compiler (and you) can only interchange these freely
if it can be proven that x cannot be negative
(eg because its type is unsigned)

Re: [dev] [sbase] [patch v3] Add md5sum

[Szabolcs Nagy]

* sin  [2013-07-03 14:43:24 +0300]:
> That's cool.  I will spend some time today or tomorrow to re-write the
> code and send in patch v4.
> 
> If that's fine then I can also proceed with sha1sum(1).
> 

i have cleaned up sha1 as well, but that was not audited for musl

http://port70.net/~nsz/crypt/

Re: [dev] [sbase] [patch v3] Add md5sum

[Szabolcs Nagy]

* Robert Ransom  [2013-07-03 10:26:03 +]:
> On 7/3/13, Galos, David  wrote:
> >> Added LICENSE.lpl as well and updated the license and copyright details
> >> for
> >> the md5 code.
> >
> > I am considering applying this patch. The license is why I have to take
> > time to think. I'm worried about setting a precedent which allows external
> > differently-licensed software to be swept into sbase. It is clean code,
> > which is a large part of why I am considering it.
> 
> Why not use the public-domain MD5 implementation from libtomcrypt?
> 

here is a cleaned up version

http://git.musl-libc.org/cgit/musl/tree/src/crypt/crypt_md5.c

the libtomcrypt version has gratuitous optimizations
ifdef configurations and useless failure modes

Re: [dev] lisp

[Szabolcs Nagy]

* Louis-Guillaume Gagnon  [2013-06-29 
13:35:58 -0400]:
> It's worth noting that the R5RS scheme standard is only ~50 pages
> long: http://www.schemers.org/Documents/Standards/R5RS/
> In comparison, the C99 standard is ~550 pages. I would say that the
> scheme dialect is pretty simple.

r5rs is much more limited in scope than c99, it has a synthetic
design that provides the bare minimum to express high level
computations, while c99 has an ugly pragmatic design, the result
of long evolution and contradicting constraints

the scheme spec does not give you enough semantics to reason
about resource usage, latency of operations or to handle
related failures, it cannot control the interaction with the
underlying system without serious language extensions

this is not a big problem for scheme as it is not a
systems programming language, but a scripting language

i think the lack of syntax in scheme helps understanding
certain concepts (and makes the spec simpler), but is not
comfortable in practice, a language like lua (with simple
syntax for associative arrays) goes a long way to be more
practical

but the fundamental reason why we see more mention of c than
lisp is that all relevant operating systems have a unix like
api for which the only detailed spec is posix, a superset of
c99, while a lisp implementation needs to do a lot to bridge
the gap and its abstractions are leaky and costly

but there is good news for those who think c is bad: there are
emerging platforms which may give rise to different languages:
jvm on mobile and enterprise systems and the web with js..

Re: [dev] daemon for DWM

[Szabolcs Nagy]

* Viola Zolt?n  [2013-06-27 08:52:11 -0400]:
> possibilities, very lot, and to them I need C++ for the objectoriented
> programming. And, I preferred the "//" not the /*... */

// comment is valid in c
(since 1999 it's even standardized)

i don't think you need object oriented programming in your daemon
but an extensive code clean up could help

most of what you are doing can be achieved by

while true
do
xsetroot -name "`stats`"
done &

the implementation of the stats command is left as an exercise

Re: [dev] [sbase] [patch v2] Add md5sum

[Szabolcs Nagy]

* sin  [2013-06-19 15:00:43 +0300]:
> > Integer promotion rules are nasty!  I think something like
> > the following would still be ok?
> > 
> > unsigned f(unsigned int c) { return c<<24U; }
> 
> Although in this case we still have undefined behaviour
> because unsigned int can be 2 bytes by the standard.
> 
> Depending on the ABI this might or might not be an issue.

don't worry about 2byte int, that does not work on linux
(and posix platforms in general)

bit shift does not do arithmetic conversion:
the signedness of the right operand does not matter,
integer promotion is applied independently to the two
sides

the usual way to do the char shift is

(uint32_t)c<<24

or

uint32_t w = c;
w << 24

Re: [dev] [sbase] [patch v2] Add md5sum

[Szabolcs Nagy]

* stateless  [2013-06-19 11:38:00 +0100]:
> This is a version of md5sum(1) using the md5 routines from 9base - slightly
> adapted to compile.
> 

be careful with integer arithmetics in crypto code

your code invokes undefined behaviour because of
signed int overflow:

 unsigned f(unsigned char c) { return c<<24; }

c is promoted to int not unsigned in the left shift

it will work in practice (usually) but that's only
by accident

you should cast c to the right type

Re: [dev] [sbase] 64-bit type for split

[Szabolcs Nagy]

* Galos, David  [2013-06-14 22:39:12 -0500]:
> > Or are you limiting this to pure ansi instead of posix?
> I'm just trying to conform with the rest of sbase. The CFLAGS include
> `-ansi -pedantic -Wall` and I don't want my code to compile with
> warnings.
> 

you can get rid of the warning in strict ansi mode by

#ifdef __GNUC__
 __extension__
#endif
typedef long long foo;

> > How exactly do you think you are going to be able to work with / create
> > files larger than whatever off_t type is provided by the environment
> > supports?
> 
> I actually didn't think of `off_t`. I just knew that `long` wouldn't
> cut it, and that

note that you need -D_FILE_OFFSET_BITS=64
to get 64 bit off_t on glibc on 32 bit archs
(some distros add this by default, but you
cannot count on that)

Re: [dev] [sbase] 64-bit type for split

[Szabolcs Nagy]

* Galos, David  [2013-06-11 13:10:37 -0500]:
> Right, but '-ansi -pedantic' is strictly C89. GCC doesn't complain,
> but I could imagine there being trepidation around using a C99 header
> in a C89 environment (where it is not required).
> 
> 2013/6/11 Thorsten Glaser :
> > Galos, David dixit:
> >
> >>On GNU systems stdint.h still provides uint64_t, but I have no idea
> >>how portable this is.
> >
> >  is C99.

if you want c89 compatibility then indeed you
should not include stdint.h, but

long long was supported in practice before c99
(c++ didn't have it until recently, but usually
it is supported as an extension)

i think you should only avoid long long if you
are specifically targetting a system without
long long support

Re: [dev] [st] minor config.def.h fix

[Szabolcs Nagy]

a more complete patch that removes some
unnecessary inline keywords

(gcc in c99 mode incorrectly assumes that an
inline function definition has external linkage
even if a prior static declaration exists)

since it is enough to specify inline only
once i removed it from the function definition
(i think this also has the expected behaviour
with the gnu and c++ inline semantics if anyone
cares)
diff --git a/config.def.h b/config.def.h
index 6b2737e..2a9c114 100644
--- a/config.def.h
+++ b/config.def.h
@@ -139,7 +139,7 @@ static KeySym mappedkeys[] = { -1 };
  * Which bits of the state should be ignored. By default the state bit for the
  * keyboard layout (XK_SWITCH_MOD) is ignored.
  */
-uint ignoremod = XK_SWITCH_MOD;
+static uint ignoremod = XK_SWITCH_MOD;
 
 /* key, mask, output, keypad, cursor, crlf */
 static Key key[] = {
diff --git a/st.c b/st.c
index 2811876..61bf86c 100644
--- a/st.c
+++ b/st.c
@@ -685,7 +685,7 @@ selsort(void) {
 	sel.ne.y = MAX(sel.ob.y, sel.oe.y);
 }
 
-static inline bool
+bool
 selected(int x, int y) {
 	if(sel.ne.y == y && sel.nb.y == y)
 		return BETWEEN(x, sel.nb.x, sel.ne.x);
@@ -3360,7 +3360,7 @@ focus(XEvent *ev) {
 	}
 }
 
-inline bool
+bool
 match(uint mask, uint state) {
 	state &= ~(ignoremod);
 

[dev] [st] minor config.def.h fix

[Szabolcs Nagy]

config.def.h fix: ignoremod is const

-uint ignoremod = XK_SWITCH_MOD;
+static const uint ignoremod = XK_SWITCH_MOD;

Re: [dev] [slcon] Call for Papers 2013

[Szabolcs Nagy]

* Christoph Lohmann <2...@r-36.net> [2013-03-17 13:39:54 +0100]:
> 
> Please send the papers for those two presentations to c...@suckless.org.
> 

ok i registered, but the final form
of the papers will be only ready the
night before the talk..

Re: [dev] [slcon] Call for Papers 2013

[Szabolcs Nagy]

* Christoph Lohmann <2...@r-36.net> [2013-03-17 09:40:30 +0100]:
> The call for registration is over. With 12 registered attendees the con???
> ference is going to be a nice and productive  meeting  of  all  suckless
> people.
> 
> People  now registering for the event should register a talk too. Other???
> wise it???s unfair.

umm so the registration is not over yet

i havent seen the conference discussed here much yet and
it would be nice to see some

> * Send the title and a description of what you will present to con@MAILHOST
>   until 2013-04-15.

i was thinking about two topics i could give a talk on,
one is about musl libc and another about general
programming language issues

1) Bugs found by musl
(what happens when a high quality libc meets our modern
software ecosystem)
i plan to pick a few issues and show how a new libc can
be (and is) beneficial, an assorted list for the curious:
http://nsz.repo.hu/musl/bugs.html

2) The costs of abstraction
(why still c is the only serious programming language)
i dont have much to show for this yet, but i wrote about
a memory management issue recently that is related:
http://port70.net/~nsz/41_oom.html

these topics are only tangentially relevant to suckless
so i thought i'll put them out here before registering

Re: [dev] st bug

[Szabolcs Nagy]

* Woldemar ShiPa  [2012-11-18 20:29:14 +0400]:
> Hello. I've got a st bug trying to execute st -e mc command. Sometimes it 
> works
> as expected and mc runs fullscreen, sometimes used only a half of st window.

does it get solved after you resize st?

i observed similar behaviour and i think that's because the
terminal is not yet resized by the wm when mc starts drawing
and i guess mc does not handle the window size change during
its startup

(mc does the same here in rxvt and urxvt)

Re: [dev] [st] 0.3 release

[Szabolcs Nagy]

* Brandon Invergo  [2012-11-05 11:45:09 +0100]:
> The problem is that in its drawing functions, st does *at least* one xlib call
> per terminal line. When you factor in any change in text properties
> (color, italics, etc), then you get even more xlib calls per line. When
> you're scrolling, and thus redrawing the entire terminal repeatedly,
> that adds up to a hell of a lot of library calls.
> 

it seems to me that scrolling could be implemented using a blit
operation (essentially memmove) and only the last (or first) lines
need to be drawn

(the cursor may need to be fixed before the blit)

i guess scrolling is worth special casing

Re: [dev] [st] 0.3 release

[Szabolcs Nagy]

another patch: fixes meta+return
diff -r 1266d6a1062c st.c
--- a/st.c	Sat Nov 03 14:05:45 2012 +0100
+++ b/st.c	Sat Nov 03 18:30:26 2012 +0100
@@ -2694,6 +2694,8 @@
 selpaste();
 			break;
 		case XK_Return:
+			if(meta)
+ttywrite("\033", 1);
 			if(IS_SET(MODE_CRLF)) {
 ttywrite("\r\n", 2);
 			} else {

Re: [dev] [st] 0.3 release

[Szabolcs Nagy]

attached patch fixes X2COL and Y2ROW
(not the cleanest possible)

borderpx changed to signed int in the default config
(other coords are signed and mixing unsigned in can
cause surprises)

diff -r 88ca50b8e7f7 config.def.h
--- a/config.def.h	Fri Nov 02 23:19:56 2012 +0100
+++ b/config.def.h	Sat Nov 03 03:12:12 2012 +0100
@@ -2,7 +2,7 @@
 
 /* appearance */
 static char font[] = "Liberation Mono:pixelsize=12:antialias=false:autohint=false";
-static unsigned int borderpx = 2;
+static int borderpx = 2;
 static char shell[] = "/bin/sh";
 
 /* double-click timeout (in milliseconds) between clicks for selection */
diff -r 88ca50b8e7f7 st.c
--- a/st.c	Fri Nov 02 23:19:56 2012 +0100
+++ b/st.c	Sat Nov 03 03:12:12 2012 +0100
@@ -72,8 +72,6 @@
 #define ATTRCMP(a, b) ((a).mode != (b).mode || (a).fg != (b).fg || (a).bg != (b).bg)
 #define IS_SET(flag) (term.mode & (flag))
 #define TIMEDIFF(t1, t2) ((t1.tv_sec-t2.tv_sec)*1000 + (t1.tv_usec-t2.tv_usec)/1000)
-#define X2COL(x) (((x) - borderpx)/xw.cw)
-#define Y2ROW(y) (((y) - borderpx)/xw.ch)
 
 #define VT102ID "\033[?6c"
 
@@ -404,6 +402,9 @@
 static char *usedfont = NULL;
 static int usedfontsize = 0;
 
+static int X2COL(int x) { x -= borderpx; x /= xw.cw; return LIMIT(x, 0, term.col-1); }
+static int Y2ROW(int y) { y -= borderpx; y /= xw.ch; return LIMIT(y, 0, term.row-1); }
+
 ssize_t
 xwrite(int fd, char *s, size_t len) {
 	size_t aux = len;

Re: [dev] Re: obase - Sta.li moving forward?

[Szabolcs Nagy]

* Jens Staal  [2012-06-06 09:49:02 +0200]:
> - binaries do not execute (!) - the Arch GCC bug for musl recently discussed?

you mean the .gnu.hash nonsense?

that should not matter for statically linked programs..

if you have contact with the arch packagers then
tell them not to hard code --hash-style=gnu into
the compiler

gnu hash is non-standard and does not make much sense
(unless you use broken programs like firefox or
openoffice with large amount of symbols in dso
outside the main executable for no good reason,
then it can be 2x faster to load than standard sysv
hash however there is --hash-style=both for
situations like that)

> -not built in bin:
...

why?
most of the listed tools are known to work with gcc+musl


> ... so compared to the previous glibc (main) branch there are some
> serious costs at the moment...
> Hopefully the missing functionality can be fixed.
> (I will also try to get heirloom static against musl)

heirloom tools can be compiled with musl
after some minor cleanups

> Ps. sorry if this starts to be off topic for the suckless dev list Ds.

i suggest sending arch specific complaints
to an arch list and musl specific ones to
the musl mailing list

btw there are various musl based distros
https://github.com/rofl0r/sabotage
https://github.com/pikhq/bootstrap-linux
https://bitbucket.org/GregorR/snowflake

Re: [dev] network usage graphs

[Szabolcs Nagy]

* hiro <23h...@googlemail.com> [2011-12-24 02:00:47 +0100]:
> Deleting the first line of my log is currently done with sed 1d
> temp; mv temp original.dat. Is there no better way?

sed -i 1d original.dat

Re: [dev] [dwm] Fullscreen programs in tile mode

[Szabolcs Nagy]

* mikshaw  [2011-11-24 07:05:31 -0800]:
> A recent update (to Gtk, I assume) has caused the Geeqie image viewer to 
> become annoying in fullscreen mode.  It apparently will not allow itself to 
> be made tiled either.  If it's in fullscreen and I try to view a different 
> tag, Geeqie remains in front of everything else, yet will not accept keyboard 
> input (toggling fullscreen, for example) until i select its tag again (which 
> I usually end up having to guess at).
> 

sounds like a bug

now trying to move a fullscreen mplayer
to another monitor it seems dwm does
not handle this situation well

(it seems mplayer is logically moved to another
monitor and it is marked as floating on the status
bar there, but the fullscreen display window stays
on the original monitor often without focus

i'm not sure where is the issue but it needs
investigation)

(moving mplayer between tags or changing
tags while it was fullscreen worked here
as expected)

Re: [dev] [dwm] 2000 SLOC

[Szabolcs Nagy]

* Martin Kopta  [2011-10-30 08:53:48 +0100]:
> First 25 LOC is license and there is some whitespace too, however

i'd like to point out that the first 25 lines are not license
but documentation as it should be in any program code

the fact that you skipped the text without reading it just
shows the destructive effect of widespread superfluous
comments in source code

license text in source code hurts everyone everywhere

Re: [dev] [dwm] ncol layout

[Szabolcs Nagy]

* Thomas Dahms  [2011-10-29 14:11:59 +0200]:
> Concerning bstack, I don't find any use for this with wide screens
> (16:10 or even 16:9) becoming mainstream.
> 

some ppl use rotated screens
even a 3:4 aspect ratio makes
vertical splitting bad
not to mention 9:16

Re: [dev] Futaba Linux

[Szabolcs Nagy]

* Valentin Ochs  [2011-09-21 01:24:36 +0200]:
> On Tue, Sep 20, 2011 at 10:54:25PM +0100, Nick wrote:
> > Quoth Sir Cyrus:
> > > http://alrig.ht/newfutaba.html
> > 
> > Sounds really nice. Pity they can't use musl, as ARM support is an 
> > important use-case.
> 
> musl has ARM support.

for almost four whole days now! :)

Re: [dev] [dmenu] dmenu_run improvements

[Szabolcs Nagy]

* Dave Reisner  [2011-07-24 10:09:58 -0400]:
> http://pubs.opengroup.org/onlinepubs/95399/utilities/test.html
> 

this is the third time today that i see link to the old posix specs

you may want to update your bookmarks to the newer one
http://pubs.opengroup.org/onlinepubs/9699919799/

Re: [dev] [dmenu] dmenu_run improvements

[Szabolcs Nagy]

* Anselm R Garbe  [2011-07-24 09:40:12 +0100]:
> On 24 July 2011 08:38, anonymous  wrote:
> >
> > There is a difference:
> >
> >    % echo `echo '\\'`
> >    \
> >    % echo $(echo '\\')
> >    \\
> 
> Yes, but bash'isms are a NO GO in suckless.org shell scripts :)
> 

$(cmd) is not bashism anymore (it was added to posix long ago)

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03

Re: [dev] Experimental editor

[Szabolcs Nagy]

* Andrew Hills  [2011-06-15 11:51:17 -0400]:
> On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley  wrote:
> > I own a keyboard that has no pgup/pgdn, or arrow keys.
> 
> Did you steal it from a museum?

you don't have to go to a musem for that

http://en.wikipedia.org/wiki/File:T-Mobile_G1_launch_event_2.jpg

[dev] Re: [hackers] [dwm] fixing some minor issues, next week is dwm-5.9 release time || garbeam

[Szabolcs Nagy]

* h...@suckless.org  [2011-06-11 09:33:24 +0200]:
> -while xsetroot -name "`date` `uptime | sed 's/.*,//'`"
> +while xsetroot -name "`date` `uptime | sed 's/.*,//'`
>  do

was this intentional?

Re: [dev] Re: sbase

[Szabolcs Nagy]

* Anthony J. Bentley  [2011-06-09 19:22:47 -0600]:
> Don???t we have /dev/stdin for that anyway?
> 

no
/dev/stdin, /dev/fd/0, /proc/self/fd/0 are non standard and
not always available (even on linux systems)

Re: [dev] [dwm] non-ASCII characters in status bar?

[Szabolcs Nagy]

* Sir Cyrus  [2011-05-30 20:56:43 +0100]:
> Is it possible to have the status bar in dwm show non-ASCII
yes

> http://i.imgur.com/4S0EJ.png
> 
> Should show a right pointing single guillemet (U+203A) after 'WordPress'.
encoding matters
locale settings matter
xlocale settings matter
font settings matter
font coverage matters
etc
all the things you don't want to know about

Re: [dev] sbase

[Szabolcs Nagy]

* Connor Lane Smith  [2011-05-23 03:15:43 +0100]:
> thumb is to only include flags present in both POSIX and Plan 9, thus
> making a sweet little subset. There are exceptions to this, like grep

scripts will break

(eg autoconf generated scripts depend on all sort of flags
and lot of software uses autoconf..)

[dev] [9base] another cosmetic patch

[Szabolcs Nagy]

to make diff/Makefile consistent with other Makefiles
diff -r 3314f6c2b58a diff/Makefile
--- a/diff/Makefile	Sun May 08 08:26:38 2011 +
+++ b/diff/Makefile	Sun May 22 00:52:01 2011 +0200
@@ -1,35 +1,8 @@
-# diff - diff shell unix port from plan9
+# diff - diff unix port from plan9
 # Depends on ../lib9
 
 TARG  = diff
 OFILES= diffdir.o diffio.o diffreg.o main.o
 MANFILES  = diff.1
 
-include ../config.mk
-
-all: ${TARG}
-	@strip ${TARG}
-	@echo built ${TARG}
-
-install: ${TARG}
-	@mkdir -p ${DESTDIR}${PREFIX}/bin
-	@cp -f ${TARG} ${DESTDIR}${PREFIX}/bin/
-	@chmod 755 ${DESTDIR}${PREFIX}/bin/${TARG}
-	@mkdir -p ${DESTDIR}${MANPREFIX}/man1
-	@cp -f ${MANFILES} ${DESTDIR}${MANPREFIX}/man1
-	@chmod 444 ${DESTDIR}${MANPREFIX}/man1/${MANFILES}
-
-uninstall:
-	rm -f ${DESTDIR}${PREFIX}/bin/${TARG}
-	rm -f ${DESTDIR}${MANPREFIX}/man1/${MANFILES}
-
-.c.o:
-	@echo CC $*.c
-	@${CC} ${CFLAGS} -I../lib9 -I${PREFIX}/include -I../lib9 $*.c
-
-clean:
-	rm -f ${OFILES} ${TARG}
-
-${TARG}: ${OFILES}
-	@echo LD ${TARG}
-	${CC} ${LDFLAGS} -o ${TARG} ${OFILES} -lm -L../lib9 -L${PREFIX}/lib -l9
+include ../std.mk
diff -r 3314f6c2b58a std.mk
--- a/std.mk	Sun May 08 08:26:38 2011 +
+++ b/std.mk	Sun May 22 00:52:01 2011 +0200
@@ -10,7 +10,7 @@
 	@echo built ${TARG}
 
 install: install-default post-install
-   
+
 install-default: ${TARG}
 	@mkdir -p ${DESTDIR}${PREFIX}/bin
 	@cp -f ${TARG} ${DESTDIR}${PREFIX}/bin/

[dev] [9base] fmt vs PLAN9PORT

[Szabolcs Nagy]

i was playing with pcc+musl and compiled various
libs including 9base with them

i found that there are two versions of the fmt lib
in 9base/plan9port: plan9 style and ansi style
(former is used when PLAN9PORT is defined)

the problem is that all the commands seem to
expect the plan9 style fmt

eg unsigned decimal and unsigned hexadecimal
formating is different:
plan9: %ud %ux
ansi: %u %x

this can cause all sort of issues eg ls -l or du
prints file sizes with a 'd' suffix

so essentially the tools are unusable if
PLAN9PORT is not defined (ansi style fmt,
the default in 9base)

imho this should be fixed in p9p by using ifdef
PLAN9PORT in all the tools where necessary
(as it is done in some places under lib9/)

in 9base we either define PLAN9PORT (it has some
other effects beyond the formatting style..)
or manually fix the formats in the source to use
the ansi style


i also attached a patch i used to be able to compile
with musl
diff -r 3314f6c2b58a lib9/_p9dir.c
--- a/lib9/_p9dir.c	Sun May 08 08:26:38 2011 +
+++ b/lib9/_p9dir.c	Sat May 21 21:51:37 2011 +0200
@@ -1,3 +1,4 @@
+#define _FILE_OFFSET_BITS 64
 #include 
 #define NOPLAN9DEFINES
 #include 
@@ -61,38 +62,17 @@
 	return (vlong)lab.d_partitions[n].p_size * lab.d_secsize;
 }
 
-#elif defined(__linux__)
-#include 
-#include 
-#include 
-#undef major
-#define major(dev) ((int)(((dev) >> 8) & 0xff))
+#else
+#include 
 static vlong
 disksize(int fd, struct stat *st)
 {
-	u64int u64;
-	long l;
-	struct hd_geometry geo;
+	off_t n;
 
-	memset(&geo, 0, sizeof geo);
-	l = 0;
-	u64 = 0;
-#ifdef BLKGETSIZE64
-	if(ioctl(fd, BLKGETSIZE64, &u64) >= 0)
-		return u64;
-#endif
-	if(ioctl(fd, BLKGETSIZE, &l) >= 0)
-		return l*512;
-	if(ioctl(fd, HDIO_GETGEO, &geo) >= 0)
-		return (vlong)geo.heads*geo.sectors*geo.cylinders*512;
-	return 0;
-}
-
-#else
-static vlong
-disksize(int fd, struct stat *st)
-{
-	return 0;
+	n = lseek(fd, 0, SEEK_END);
+	if (n == -1)
+		return 0;
+	return n;
 }
 #endif
 
diff -r 3314f6c2b58a lib9/dirfwstat.c
--- a/lib9/dirfwstat.c	Sun May 08 08:26:38 2011 +
+++ b/lib9/dirfwstat.c	Sat May 21 21:51:37 2011 +0200
@@ -4,9 +4,19 @@
 #include 
 #include 
 
-#if defined(__FreeBSD__) || defined(__APPLE__) || defined(__OpenBSD__) || defined(__linux__)
+#if defined(__FreeBSD__) || defined(__APPLE__) || defined(__OpenBSD__)
 /* do nothing -- futimes exists and is fine */
 
+#elif defined(__linux__)
+static int
+futimes(int fd, struct timeval *tv)
+{
+	char name[32];
+
+	sprint(name, "/dev/fd/%d", fd);
+	return utimes(name, tv);
+}
+
 #elif defined(__SunOS5_9__)
 /* use futimesat */
 static int
diff -r 3314f6c2b58a lib9/dirread.c
--- a/lib9/dirread.c	Sun May 08 08:26:38 2011 +
+++ b/lib9/dirread.c	Sat May 21 21:51:37 2011 +0200
@@ -7,16 +7,11 @@
 extern int _p9dir(struct stat*, struct stat*, char*, Dir*, char**, char*);
 
 #if defined(__linux__)
+#include 
 static int
 mygetdents(int fd, struct dirent *buf, int n)
 {
-	off_t off;
-	int nn;
-
-	/* This doesn't match the man page, but it works in Debian with a 2.2 kernel */
-	off = p9seek(fd, 0, 1);
-	nn = getdirentries(fd, (void*)buf, n, &off);
-	return nn;
+	return syscall(SYS_getdents, fd, (void*)buf, n);
 }
 #elif defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__)
 static int
diff -r 3314f6c2b58a lib9/libc.h
--- a/lib9/libc.h	Sun May 08 08:26:38 2011 +
+++ b/lib9/libc.h	Sat May 21 21:51:37 2011 +0200
@@ -7,7 +7,7 @@
 #define _LIBC_H_ 1
 #if defined(__cplusplus)
 extern "C" {
-#endif
+#endif
 
 #include 
 #include 
diff -r 3314f6c2b58a lib9/readcons.c
--- a/lib9/readcons.c	Sun May 08 08:26:38 2011 +
+++ b/lib9/readcons.c	Sat May 21 21:51:37 2011 +0200
@@ -2,7 +2,7 @@
 #define NOPLAN9DEFINES
 #include 
 #include 
-#include 
+//#include 
 
 static int
 rawx(int fd, int echoing)
diff -r 3314f6c2b58a lib9/utf/utfecpy.c
--- a/lib9/utf/utfecpy.c	Sun May 08 08:26:38 2011 +
+++ b/lib9/utf/utfecpy.c	Sat May 21 21:51:37 2011 +0200
@@ -11,7 +11,7 @@
  * ANY REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
  * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
  */
-#define _BSD_SOURCE 1	/* memccpy */
+#define _XOPEN_SOURCE 1000	/* memccpy */
 #include 
 #include 
 #include "plan9.h"

Re: [dev] Suckless UML

[Szabolcs Nagy]

* Uriel  [2011-05-12 19:54:26 +0200]:
> Fortunately somebody already has done some writing on the topic:
> 
> http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html
> 

it is also worth noting that even original contributors of uml
find it problematic

http://port70.net/~nsz/articles/other/harel_rumpe_visual_pl_semantics_uml_2004.pdf

Re: [dev] [dwm] fix status bar cropping on screen resize

[Szabolcs Nagy]

* Mark Williams  [2011-02-24 17:22:03 -0800]:
> Definitely an edge case, but it's happened to me enough times that
> three possible fixes came to mind (listed in ascending preference):
> 
> 1) Put a note in the BUGS section of the man page that mentions that
i think this can be fixed

> 2) The bar gets cut off because configurenotify() expects updategeom()
> to return true only if the ConfigureEvent reports a change to the root
> window's dimensions.  While updategeom() does this correctly when
i don't quite understand why the reported width is not the
full display width there

> 3) Interestingly, the current code and the previous solution create a
> dc.drawable pixmap that's as wide as the aggregate horizontal
> resolution across all monitors.  That makes sense for the non-Xinerama
> code, where the bar stretches from monitor to monitor, but it doesn't
> when each has its own bar.  In the latter case the pixmap only has to
> be as wide as the largest monitor's horizontal resolution.  The second
this seems reasonable

i'd use a max-monitor-width global instead of dc.dw
(like sw and sh it's a display geometry related var,
not a dc internal)
imho updategeom shouldn't modify dc or if it does
then do all the work there (createpixmap, updatebars)

> Even though this happens because of other people's weak code, I think
> 3 (or 2) is the best solution since dwm itself seems to be making some
> incorrect assumptions; however, if the BUGS entry is the right
> solution I'll be happy to write the explanation.
thanks for looking into this

Re: [dev] [quark] patch

[Szabolcs Nagy]

* Bjartur Thorlacius  [2011-02-08 19:10:48 +]:
> Anyhow, I believe you should be using HTTP headers, If- or not, as the
> hashes don't identify the referenced resource, and thusly shouldn't be
> in the URI.
hm i think i'll go with the suggested '?'
using a query parameter seems fine to me
and wastes less space than a header

Re: [dev] [quark] patch

[Szabolcs Nagy]

* Bjartur Thorlacius  [2011-02-05 22:59:02 +]:
> As you don't need compatibility with browsers, you should be using a
> HTTP header starting with If-. See
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

thanks for reminding me these

i discarded if- headers because they have different semantics
from what i want (they may return 304 or 412 status), but it's
worth checking out how much of this is supported in existing
proxies..

Re: [dev] [quark] patch

[Szabolcs Nagy]

* Robert Ransom  [2011-02-05 05:35:29 -0800]:
> Yes it is.  See RFC 2616 (section 5.1.2) and RFC 3986 (section 4).
> 
you are right the uri spec does not allow it so lets go with '?'
or '/' or '.' or.. i'll use something when i get there

> If you expect groups of servers to be disconnected for extended periods
> of time, there are fancy algorithms that may help; look for 'set
> reconciliation' in .
this is not needed

> If you ever do care about anonymity, a well-designed mix-net system can
anonymity is simply not a concern at this point

Re: [dev] [quark] patch

[Szabolcs Nagy]

* Robert Ransom  [2011-02-04 18:56:48 -0800]:
> > -> GET /key#hash-of-data HTTP/1.0\r\n\r\n
> > <- [waiting..]
> 
> The server will never see the fragment identifier (the "#" and text
> following it).

there is no such restriction in http nor in urls
(it's not a reserved character)

your browser strips fragments away, which is good: we don't want
to use this protocol from a browser, but if you insist on using one
it's better not to keep the connection open but reply immediately
(this is one of the reasoning behind using #)

altough i might choose another character (in case proxies etc
do not handle it properly), the separator does not really matter
much

> > communication here the communicated data does not know its destination)
> 
> But the server does.

the data you put somewhere is (x,data) the
server sees (hash(x), encrypt(data,x), yourip)
neithr yourip nor hash(x) is stored
only hash(hash(x)) and encrypt(data,x) is stored

of course if a server keeps track which client requested which
keys then it can associate the communicating parties

but that will be solved with replication: if data does not know
its destination and is only identified by a key then it can be
replicated without issues. there will be no single server which
knows the source and destination as well

eg clients sitting behind a router requesting the same data
do not necessarily connect to a server: the router can cache
the data (integrity and authenticity of the data can be easily
verified, the freshness is more difficult (eg add timestamp
and expiration?))

full replication is of course not simple to implement efficiently
especially with notifications in mind, but this part is not
designed yet
(at this point you can use simple mirroring techniques for replication
and polling for notification like in rss feeds)

(btw tor is not very useful here: it adds encryption layers
during routing we don't need, and in the end sends the original
data to the original target, so it needs to know the data and
target, we only know the (already encrypted) data, there is no
target.
we don't want strong anonymity guarantees at this point, only privacy.
tor only gives anonymity iff the entry and exit nodes are not
compromised)

[dev] [quark] patch

[Szabolcs Nagy]

i recently implemented a webserver and used some code from quark in it
meanwhile i found minor issues in the code so here is a patch
(some modifications are bugfixes others are debateble,
i leave it to arg to sort it out)


offtopic:

the webserver i'm implementing is used to do secure messaging:
it accepts PUT /key and GET /key requests which store and retrieve
exactly 1K data (so it looks like a key-value store)

(server does not remember the key only the hash of the key,
if GET asks an invalid key then 1K random is generated and stored
under the key)

(the uploaded data is garbage collected: eg after 1 month it gets
deleted from the store, so this is not yet another storage solution,
it's for communication, there are no strong durability guarantees)

the next step is to implement GET /key#hash requests:
the server only answers if the (sha1) hash of the data is different
than the provided one, this can be a communication channel:

-> PUT /key HTTP/1.0\r\nContent-Length: 1024\r\n\r\ndata..
<- HTTP/1.0 200 OK\r\nContent-Type: text/plain\r\n\r\n
-> GET /key#hash-of-data HTTP/1.0\r\n\r\n
<- [waiting..]

at this point both client and server keeps the connection open
until someone modifies the data under the given key, and then
the GET request is answered with the new data

<- HTTP/1.0 200 OK\r\nContent-Type: application/octet-stream..

two client can communicate by sharing a key and updating
the data under the key
(actually many client can follow the communication and
get notification by keeping a connection alive with the
last seen hash, to solve other communication issues
higher level layers can be used ie. data format with meta info)

(security can be ensured by sending requests (keys) over a secure
channel (tls) and sharing keys using eg diffie-hellman method

actually one can encrypt the 1K data with x then use hash(x) as key
so it is enough to share x between the communicating parties
which the server does not even know, decrypting the 1K data is not
possible by just using hash(x).. of course eve can overwrite the
data using PUT /hash(x), but then alice and bob may get notified..

well the design is not complete yet, but probably a secure distributed
communication system can be built on top of this: unlike ip level
communication here the communicated data does not know its destination)

some initial code is available here:
svn co https://www.epointsystem.org/svn/epoint_wallet/trunk/messaging/prototype
(folks here at epointsystem plan to use it for some secure mobile sms thing)

(this is not yet useful in any way but i posted in case someone is interested)

diff -r a4ca37cfe934 config.def.h
--- a/config.def.h	Sat Apr 10 21:34:05 2010 +0100
+++ b/config.def.h	Fri Feb 04 15:15:33 2011 +0100
@@ -5,7 +5,7 @@
 static const char docroot[]= ".";
 static const char docindex[]   = "index.html";
 static const char user[]   = "nobody";
-static const char group[]  = "nobody";
+static const char group[]  = "nogroup";
 static const char cgi_dir[]= "/var/www/werc-dev/bin";
 static const char cgi_script[] = "./werc.rc";
 static const int  cgi_mode = 0;
diff -r a4ca37cfe934 quark.c
--- a/quark.c	Sat Apr 10 21:34:05 2010 +0100
+++ b/quark.c	Fri Feb 04 15:15:33 2011 +0100
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,9 +39,10 @@
 
 static ssize_t writetext(const char *buf);
 static ssize_t writedata(const char *buf, size_t buflen);
+static void atomiclog(int fd, const char *errstr, va_list ap);
 static void die(const char *errstr, ...);
-void logmsg(const char *errstr, ...);
-void logerrmsg(const char *errstr, ...);
+static void logmsg(const char *errstr, ...);
+static void logerrmsg(const char *errstr, ...);
 static void response(void);
 static void responsecgi(void);
 static void responsedir(void);
@@ -68,7 +70,7 @@
 
 	while(offset < buf_len) {
 		if((r = write(cfd, buf + offset, buf_len - offset)) == -1) {
-			logerrmsg("%s: client %s closed connection\n", tstamp(), host);
+			logerrmsg("client %s closed connection\n", host);
 			return -1;
 		}
 		offset += r;
@@ -82,12 +84,27 @@
 }
 
 void
+atomiclog(int fd, const char *errstr, va_list ap) {
+	static char buf[512];
+	int n;
+
+	/*
+	assemble the message in buf and write it in one pass
+	to avoid interleaved concurrent writes on a shared fd.
+	*/
+	n = snprintf(buf, sizeof buf, "%s: ", tstamp());
+	n += vsnprintf(buf + n, sizeof buf - n, errstr, ap);
+	if (n >= sizeof buf)
+		n = sizeof buf - 1;
+	write(fd, buf, n);
+}
+
+void
 logmsg(const char *errstr, ...) {
 	va_list ap;
 
-	fprintf(stdout, "%s: ", tstamp());
 	va_start(ap, errstr);
-	vfprintf(stdout, errstr, ap);
+	atomiclog(STDOUT_FILENO, errstr, ap);
 	va_end(ap);
 }
 
@@ -95,9 +112,8 @@
 logerrmsg(const char *errstr, ...) {
 	va_list ap;
 
-	fprintf(stderr, "%s: ", tstamp());
 	va_start(ap, errstr);
-	vfprintf(stderr, errstr, ap);
+	atomiclog(STDERR_FILENO, errstr, ap);
 	va_end(ap);
 }
 
@@ -105,9 +121,8 @@
 die(const char *errstr, 

Re: [dev] [sta.li] Minimalist Live Distro

[Szabolcs Nagy]

* Bjartur Thorlacius  [2010-11-10 00:03:05 +]:
> WebApp VM is a DHTML virtual machine, or a JavaScript VM that
> implements DOM, CSS, HTML, XML and related W3C and WHATWG
> technologies.

your webapp wm is a full blown web browser
i don't think there is a way around that

eg a js interpreter on its own is not very useful
as most js code is about interacting with a browser:
handling browser events, manipulating site related
states, drawing stuff on screen, issuing browser commands

so the output is the interactive shiny ui itself
without that output the vm is not very useful
with that output it is a full blown web browser

[dev] [OT] ubuntu moves to wayland from xorg

[Szabolcs Nagy]

they try to leave xorg+gnome for wayland+unity

seems ubuntu follows apple: own gui, drop x, hw accelerated eyecandy

http://www.markshuttleworth.com/archives/551
also on /.
http://linux.slashdot.org/story/10/11/05/137212/Ubuntu-Dumps-X-For-Unity-On-Wayland

Re: [dev] Re: dwm puzzle [fixed; with blame]

[Szabolcs Nagy]

* Peter John Hartman  [2010-09-12 10:52:12 -0400]:
> > > -   focus(wintoclient(ev->window));
> > > +   focus((wintoclient(ev->window)));
> > 
> 
> Ok, I haven't done this yet, but a little update.  It turns out that this
> patch /didn't/ fix the problem; or, at least, it partially did.  On

either do back that silly change
or send the dwm.s.diff for examination

Re: [dev] Re: dwm puzzle [fixed; with blame]

[Szabolcs Nagy]

* Peter John Hartman  [2010-09-11 15:23:18 -0400]:
> This fixes it:
> 
> diff -r 050d521d66d8 -r c361034c5a1c dwm.c
> --- a/dwm.c Tue Aug 24 13:13:20 2010 +0100
> +++ b/dwm.c Sat Sep 11 19:00:18 2010 +
> @@ -799,7 +799,7 @@
> unfocus(selmon->sel, True);
> selmon = m;
> }
> -   focus(wintoclient(ev->window));
> +   focus((wintoclient(ev->window)));
>  }
> 
> But evidently that's odd.  
> gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2)  
> 
> I use the default config.mk (without XINERAMA stuff) and config.h.
> 
> In any case, that fixes the bug and now openoffice and firefox behave.
> 
> Thoughts?
> Peter

can you please add -S to CFLAGS and send the diff -u of the resulting
dwm.s in the parenthesis vs no parenthesis case?

i'm interested in the problem

Re: [dev] [OT] What's wrong with C++?

[Szabolcs Nagy]

* Nikhilesh S  [2010-09-10 20:19:38 +0300]:
> Is C++ broken because no one really understands it fully? Is allowing
> multiple paradigms in a single langauge a problem? Should language
> enforce paradigm?
> 
> Could you elaborate in detail, what exactly are your problems with C++?
> Thanks. :)

i once looked into this, here is what i've found:
http://port70.net/~nsz/16_c++.html

Re: [dev] "channel" construct for inter-thread communication in C programs

[Szabolcs Nagy]

* Corey Thomasson  [2010-09-09 08:01:46 -0400]:
> libtask [ http://swtch.com/libtask/ ] implements something
> similar/same; however, it's a coroutine lib and I'm pretty sure it
> will not work with multiple threads.

that's not similar/same

the entire point of the excersise is to do messaging when you need to
exploit modern multicore buzzword compliant architectures

libtask does no such thing
libthread does i guess

Re: [dev] libdraw development

[Szabolcs Nagy]

* pancake  [2010-09-07 16:49:20 +0200]:
>  Another hacky option is to embed all functions in .h include files
> as 'static inline'.

then you'd have to include all code in the .h which would
make compilation slow whereever draw.h is included

the separate files are fine

[dev] [OT] c syntax tree dumping tool

[Szabolcs Nagy]

i'm involved in a c parsing tool project, c99tree,
and pleased to announce its first release

http://repo.hu/projects/libporty

it is in early development, but it can parse c99 code
(without includes and preprocessor tokens) and print
an abstract syntax tree

eg useful for listing function calls of a .c file etc
(the current form is very sensitive to undefined
type ids this will be fixed up later)

c99tree knows c99 grammar very well (and a fair amount
of gcc extensions), but it does not try to check syntax
errors or semantic problems, just dumps a tree or fails

the difficult part will be the preprocessor
some part of it is scheduled for the next release

for suckless it maybe useful for code analysis and
code audit as it tells a bit more than a wc -l :)

the grammar is based on the .y and .l files of pcc
http://pcc.ludd.ltu.se

(actually http://golang.org/src/cmd/cc/cc.y is cleaner,
but seemed more work to cut out and make c99/gcc
compatible, might take another look at it later..)

Re: [dev] libdraw development

[Szabolcs Nagy]

* Uriel  [2010-08-31 23:21:54 +0200]:
> WTF is this 'libdraw' thing? So are you guys not only duplicating
> existing functionality implemented by p9p, but you are also
> confusingly using the same names?
> 
> libdraw should be: http://man.cat-v.org/p9p/3/draw and that is what
> should be used as a portable drawing backend, and if more

your outrage is not justified

libdraw is not a drawing backend, xlib is the drawing backend
as far as i can see libdraw hides certain xlib primitives

it does not try to be a general purpose bitmap manipulation api,
but a widget handling lib with font loading, window resizing, etc
with minimal drawing support

the name could have been chosen with more care, but sane names
are usually taken

Re: [dev] Stripping html from email

[Szabolcs Nagy]

* Antoni Grzymala  [2010-08-26 12:39:33 +0200]:
> [1] uri://some.url...
> 
> notation, so that I can actually fish out the links. Is that possible
> in w3c as well?
> 

in interactive mode with 'L' you can list links and images
but i don't think there is a command line switch for that
in general w3m does not have too many command line options

to fish out urls i guess unix tools can help with that
 |tr '<' '\n' |grep -i href=

Re: [dev] sfc - a flashcards program to learn languages

[Szabolcs Nagy]

* Valentin  [2010-08-24 22:43:59 +0200]:
> [2] http://0au.de/hgweb.cgi/sfc

#include 
...
#include 
#include 

that's the painful way to work with strings..
this part of the c99 standard is not very nice
i guess there are not much choice if you don't want to
depend on external code like plan9 utf and fmt support

i'm not sure why you needed signal.h

Re: [dev] flo - a command line program for organizing events, to-dos, and deadlines

[Szabolcs Nagy]

* Alexander Teinum  [2010-08-17 09:01:00 +0200]:
> s/ISO 6801 date/ISO 6801 week/
s/6801/8601/

Re: [dev] [vp] A media website video player/fetcher

[Szabolcs Nagy]

* Kris Maglione  [2010-08-15 05:18:55 -0400]:

> This is a cleaned up version of some of the scripts I've been using
> for a long time to play videos from sites like YouTube. I use a key

this is my solution:
http://repo.hu/projects/yget/

this only supports youtube, but knows a bit more
can handle playlists
can handle more url formats
yurl prints infos (title, tags, length, avail formats..)
yget downloads
yplay streams

uses sh and awk (+wget, +mplayer for yget and yplay)

> For now, the only sites supported are YouTube and Revision3, but I'm
i have one script for vimeo as well but i rarely use it so it's not
cleaned up

Re: [dev] Suckless Way to Learn How To Program

[Szabolcs Nagy]

* Brandon LaRocque  [2010-08-13 18:20:17 -0400]:
> My son is interested in computer programming, and given the way that
> programming is being taught, I don't think it's the right way to go
> about learning.What would you guys here suggest for a self-learning
> curriculum that I could set up for him? By this, I mean languages,
> ideas, projects. I would really appreciate any help in the matter.

i pondered about how to learn programming myself and started
collecting links to answer it
http://port70.net/~nsz/00_prog.html
looking back now it seems like a random collection of things

i think the hard part of preparing useful course material is
to provide interesting and motivating problems with increasing
difficulty and challenges (which depends on personal taste and
changes over time, playing with qbasic used to be exciting but
i would not go back there now)

sicp used to be the basic book for teaching programming as
well as the k&r book for teaching c, however i'm not sure how
much do these motivate children nowadays (these books still
give a good understanding of a programming language and the
ways to build abstractions in relatively few pages)
the software stack got so many layers over time that the good
old low level introductions do not give a clear insight into
current systems (web, 3d, etc) which are probably the most
interesting topics right now

the advice that kernighan gives is

  No matter what, the way to learn to program is to write code,
  and rewrite it, and see it used, and rewrite again. Reading
  other people's code is invaluable as well.

Re: [dev] Suckless design in Games

[Szabolcs Nagy]

* Chidambaram Annamalai  [2010-08-11 13:12:46 +0530]:
> Have you even bothered to look through the sources? You really have
yes
although it was a couple of years ago last time i used bgl

> to decouple the storage schemes from the algorithms so that you can write
> O(M + N) code to support O(M*N) template instances. And there is no point if
> this abstraction had a severe penalty on the runtime performance. BGL
> exactly knows which algorithm to use for a particular storage mode because
> intelligence is built into it using traits. The hierarchial design (which is
this is a misconception about bgl and c++ generic programming in general

you can treat certain aspects of the algorithms but not everything
genericity is only available where the designers thought about it
(eg you cannot reuse a stack in dfs graph traversals of various graphs
because it is hardcoded in boost)

this usually ends up in a lot of configurability where users don't
need it, but the result is still not flexible enough for practical
problems

that's why everyone ends up implementing their own containers instead
of using stl in a bigger c++ project
(eg by adding concurrency support or using different tradeoffs in the
algorithm design, so eventhough stl is very generic it is still not
flexible enough)

intuition tells that generic code allows easy replacement of components
but this is a fallacy:
- the designer must know how the code will be used in advance
and decompose the algorithms that way
- the users need to know a lot more about the internal implementation,
how an abstract component interacts with others
(the more fine grained the generic code the more difficult to use it)
(it's not true that you can easily write your own graph represantation
to use it with boost you need to know a lot of details)
(from the docs a lot of semantic detail is not clear, eg can you modify
a graph from a visitor? boost uses iterators and in many datastructure
modifications invalidates them)
- when an algorithm is used in the most simple and usual way, genericity
causes a lot of unnecessary boilerplate, confusion about the api, and
cryptic compiler error messages
(to find the shortest path in a simple directed graph with int edge
weights, i still have to fill the template arguments
http://www.boost.org/doc/libs/1_43_0/libs/graph/example/dijkstra-example.cpp
this is not elegant code)

i experimented with various types of genericity for algorithms
here is one approach:
implement the algorithm in the simplest way for the most useful types
etc. then when you need it for a specific task then copy the code and
apply appropriate modifications in the source (often s/type1/type2/g)

it turns out that with this approach it's often easier to change
a component without screwing things up than by understanding all
the gory details of a generic api like boost

adapting an algorithm for your usecase usually takes less than an hour
and the result is readable customized code, easy to debug, easy to edit

> Template metaprogramming uses static polymorphism which is an entirely
> different beast from OO inheritance that uses dynamic polymorphism.
yes, each of them has quirks and the user of the library should deal
them
(using various concepts together the complexity of the result is the
product of the complexity of each part, not the sum)

my argument is that this amount of abstraction just not worth the effort
(at least in c++)

Re: [dev] Suckless design in Games

[Szabolcs Nagy]

* Chidambaram Annamalai  [2010-08-11 03:26:22 +0530]:
> I didn't argue BGL was simple. But I'd certainly consider it elegant. Of

no it's not elegant

graph algorithms are too versatile to do elegantly what boost tries to do
(eg boost tries to operate on a generic graph type which cannot work
as different graph representations often require different algorithms
also space-time and other important tradoffs cannot be expressed this way)

in bgl a shortest path algorithm has 12 arguments some of them are type
parameters some of them are objects with various methods defined on them
generic programming is mixed with oo inheritence all over the place
(good luck figuring out the error message you get when you miss something)

the entire library is implemented in header files
(so compile time is guaranteed to be huge)

using boost involves a fair amount of c++ trickery and boilerplate
looking at boost examples i can not believe someone found this elegant
elegant code reads like pseudo code
boost is nothing like the code you find in algorithm books
(i hoped that you were just trolling)

Re: [dev] fossil scm

[Szabolcs Nagy]

* pancake  [2010-08-10 15:49:16 +0200]:
>  I have found that scm to be quite interesting (www.fossil-scm.org).

there is still no good issue tracking system!

web based project documentation solutions can
be improved but it's not such a big deal
(wiki, man2html, ..)

integrating these into the vcs is not right imho
(project hosting is a more centralized thing
and different from versioning the source code)

about issue tracking:
using only web base issue management is limiting
eg i can imagine an smtp based solution as well where
one can send messages to an address with a given
subject format for opening an issue, adding comment
to an issue etc

Re: [dev] Suckless design in Games

[Szabolcs Nagy]

* Matthew Bauer  [2010-08-09 21:02:53 -0500]:
> What game libraries are suckless? (SDL, OpenGL)
> 
> What programming language is best for games? (C, Python, or Go)

i consider this approach fairly nice and simple for 'flashgames':
http://repo.hu/projects/animator/

reads drawing commands from stdin
(optionally) writes events to stdout

so game logic can be a separate process in whatever language

(of course it has limitations eg only vector graphics,
no bitmap operations like blitting and audio has to be
handled separately)

Re: [dev] wrap: minimalist archiving tool

[Szabolcs Nagy]

* David Tweed  [2010-08-09 04:54:25 +0100]:
> The one thing that leaps out at me is that there's no checksumming of

to some extent this can be worked around
find dir -type f | xargs sha1sum >dir.sum
find dir -type f | xargs wrap c dir.sum >dirwithsum.a

or even
sha1sum dir.a >dir.a.sum

but yes, depending on the application one might need more builtins
(even for source code it might be useful to have executable flags,
creation time or symlinks)
(also it is not checked if a path is truncated or if the same path
name appears multiple times)
(when used for moving files between platforms warnings about path
name issues might be useful)

Re: [dev] wrap: minimalist archiving tool

[Szabolcs Nagy]

* Connor Lane Smith  [2010-08-06 15:10:29 +0100]:

> I've written a tiny archiver, which I've called "wrap" for lack of a

looks nice (nicer than tar, cpio or gnu ar)

> I'm not quite sure of the use case for this, but I don't know, someone

i'm not sure either

but it'd be unixy to do
find dir | xargs | wrap c | sflate -c >dir.a

Re: [dev] wrap: minimalist archiving tool

[Szabolcs Nagy]

* Connor Lane Smith  [2010-08-06 15:10:29 +0100]:

> Interestingly during testing the best compression results came from
> our very own sflate.

there was a bug in the encoder, it could corrupt your data
(i noticed it after rewriting a few things, but forgot to backport the fix to 
the repo on suckless.org)

i've just committed a fix, but be careful with sflate there might be other 
issues

Re: [dev] [surf] site-specific css?

[Szabolcs Nagy]

* Rob Mason  [2010-07-24 11:14:36 -0400]:

> Hi, I'm wondering how to have custom css for a specific site, specifically
> like the css here: http://userstyles.org/styles/31211

mozilla has @-moz-document css extension to define domain specific styles
https://developer.mozilla.org/en/CSS:@-moz-document

i guess webkit has a similar and most likely incompatible solution

Re: [dev] Problem building dmenu tip

[Szabolcs Nagy]

* Anselm R Garbe  [2010-07-19 07:45:16 +0100]:

> On 18 July 2010 21:40, Josh Rickmar  wrote:
> > CC -o dinput
> > /usr/lib/crt0.o(.text+0x9d): In function `___start':
> > : undefined reference to `main'
> > collect2: ld returned 1 exit status
> > *** Error code 1
> >
> > Stop in /home/joshua/src/dmenu (line 28 of Makefile)
> 
> Make sure to
> 
> hg clone http://hg.suckless.org/libdraw
> cd libdraw
> make install
> 
> before you build dmenu. Does this fix your issues?

i assume without libdraw he would get lot of undefined symbol errors during 
compilation

this seems a general linking problem to me

Re: [dev] Problem building dmenu tip

[Szabolcs Nagy]

On 7/18/10, Josh Rickmar  wrote:
> in the irc channel said he remembers a similar problem when linking with
> ld on Linux.  Any ideas?

nah, that's not what i meant

i just noted that you get similar error when you link with ld in general like
ld -o foo -lc foo.o

> /usr/lib/crt0.o(.text+0x9d): In function `___start':
> : undefined reference to `main'
> collect2: ld returned 1 exit status
> *** Error code 1

does other stuff compile fine? eg try
cc -c -o foo.o foo.c
cc -o foo -lc foo.o

Re: [dev] dwm-5.8.2 / 9base-6

[Szabolcs Nagy]

On 6/5/10, Szabolcs Nagy  wrote:
> On 6/5/10, David DEMELIER  wrote:
>> I'm sorry to disturb you again, but the fullscreen problem is still
>> here with mplayer. Even fstype=non in mplayer.conf still does'nt scale
>> the mplayer fullscreen window.
>
> works here fine, without additional settings
>
> 2 monitor setup, one tilted (1024x1280), the other is svga (1024x768)
> mplayer fullscreen wokrs on both of them with dwm 5.8.2
> tested with videos with various size, tiled and floating windows as well
>

i take this back

if i fullscreen an mplayer and change view it gets out of fullscreen
state, in case of tiled mplayer this can result in inconsistent states
(mplayer tiled but it's on top of the bar)

Re: [dev] dwm-5.8.2 / 9base-6

[Szabolcs Nagy]

On 6/4/10, ilf  wrote:
> As I reported with Firefox before, also Xpdf's fullscreen behaviour
> changed. The most obvious change is that both clients now also cover the
> dwm status bar when in fullscreen.
>
> Xpdf seems even a little more aggressive. When in fullscreen, it uses
> the entire screen, no matter what. Before, dwm was able to tile multiple
> fullscreen Xpdf clients.

i can confirm these observations

in tiled mode xpdf works as it used to, so i'm not terribly annoyed

Re: [dev] dwm-5.8.2 / 9base-6

[Szabolcs Nagy]

On 6/5/10, David DEMELIER  wrote:
> I'm sorry to disturb you again, but the fullscreen problem is still
> here with mplayer. Even fstype=non in mplayer.conf still does'nt scale
> the mplayer fullscreen window.

works here fine, without additional settings

2 monitor setup, one tilted (1024x1280), the other is svga (1024x768)
mplayer fullscreen wokrs on both of them with dwm 5.8.2
tested with videos with various size, tiled and floating windows as well

Re: [dev][surf]

[Szabolcs Nagy]

On 5/26/10, Christophe-Marie Duquesne  wrote:
> Sorry, I know this topic is old, but I was wondering: Why is YAML
> considered harmful? It's on http://harmful.cat-v.org/software/, but I

it is built on similar ideas as xml (tries to be a generic something)
it has many inconsistent syntax elements (like a "feature rich" wiki)

compare
http://yaml.org/spec/1.2/spec.html
and
http://www.json.org/

yaml has complicated grammar rules which makes it hard to parse for
both human and machine readers and does not seem to solve any
particular problem

Re: [dev] [surf] User-Agent string.

[Szabolcs Nagy]

On 5/18/10, Marvin Vek  wrote:
>> the user agent string is unnecessary
>
> According to the RFC, it's required.

"User agents SHOULD include this field with requests."

SHOULD: "This word, or the adjective "RECOMMENDED", mean that there
 may exist valid reasons in particular circumstances to ignore.."

there is only one header that "MUST" be present in a http 1.1 request
and that's the "Host:" header field
(btw this is a stupid requirement as well and was not present in http 1.0)

Re: [dev] [surf] User-Agent string.

[Szabolcs Nagy]

On 5/18/10, Marvin Vek  wrote:
> Would love to hear what you think about it, and especially if this
> would be subject for implementation in the surf sources directly.

i think unnecessary headers are bad

the user agent string is unnecessary

also it reminds me the recent eff research
http://www.eff.org/press/archives/2010/05/13

Re: [dev] SDL fullscreen problems in dwm

[Szabolcs Nagy]

On 5/14/10, hessi...@hessiess.com  wrote:
> Its because SDL is resolution dependent(non resizeable).

what do you mean by non resizeable?

Re: [dev] SWK: The simple widget kit

[Szabolcs Nagy]

On 5/13/10, pancake  wrote:
> Check t/ui.c and you will understand why SwkWindow is not global variable.
>
> Do somebody noticed this file? I mean..the UI can be done not only by code..

i've noticed that

can't you just manipulate an extern global swkwindow the same way?
i didn't mean to hide the swk window internals, just not pass it
around but access it directly

Re: [dev] SWK: The simple widget kit

[Szabolcs Nagy]

On 5/12/10, Rory Rory  wrote:
> Right now it's not obvious what the widgets actually are. The
> textboxes look identical to the buttons and it's hard to know where to
> type into.

don't care about the visual representation
that's the last thing you wish to design

the question is if the programming model is simple and powerful enough

* there is "box" and "event"
* each box has an event handler and that's the only thing that
determines the behaviour of the box (visual behaviour and internal
state).
* the event handler gets called with events that occured over the area
of the box.
* there is no parent/child of a box so you cannot pass events around
(as in most toolkits), you have to handle or ignore them
* the area of a box is determined by the toolkit, only the box layout
should be described (boxes per rows), so not just fixed resolution
pixel based representation is possible

btw if there is strictly one window per application (the container of
boxes) then the window can be a global variable, you don't have to
pass it around in every swk function and struct.

Re: [dev] MaxFloat support?

[Szabolcs Nagy]

On 4/22/10, Yue Wu  wrote:
> is. But,
> sometimes I want some windows can be always maximized after running and
> still
> is a floating window, so my question is, how to make dwm can auto-maximize
> this type of windows and still keep them be 'isfloating'? Maybe can add a
> feature that can assign them a type of 'ismaxfloating' property? The
> 'monocle'
> layout isn't what I want at all, in this mode, every window will be
> maximized.

if a window is maximized then i'm not sure what does it matter if it's
floating or not

if you need a layout which is similar to monocle but maximizes
isfloating windows as well, then i guess you need to hack dwm.c a lot
since floating windows are handled specially (eg resizehints is always
on for them, they are raised on top of other windows in manage and
restack..)

if you don't want a new layout just maximization on when it's opened,
then you should hack manage() to set up the window size, but there is
no guarantee that the window will not set its size later

Re: [dev] sed 10q or sed 11q

[Szabolcs Nagy]

On 4/12/10, Uriel  wrote:
> What is your question?

he just pointed out that 'sed 11q' incorrectly listed as an alternative
to 'head' on cat-v (the correct alternative would be 'sed 10q')

but it's a minor detail..

Re: [dev] sed 10q or sed 11q

[Szabolcs Nagy]

On 4/11/10, markus schnalke  wrote:
> Now I actually must assume, Uriel might be wrong. *eek*
>
> But is this possible?

yes