[dev] [sent] initialize .img
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
* Dimitris Papastamos s...@2f30.org [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 k...@shike2.com 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
* 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
* Dimitris Papastamos d...@spl9.org [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
* Silvan Jegen s.je...@gmail.com [2014-03-04 14:27:26 +0100]: On Tue, Mar 4, 2014 at 9:25 AM, FRIGN d...@frign.de 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] What is bad with Python
* Silvan Jegen s.je...@gmail.com [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][PATCH][quark] Clean up the log-facility
* FRIGN d...@frign.de [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)
* FRIGN d...@frign.de [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
* sin s...@2f30.org [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
* sin s...@2f30.org [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()
* Bobby Powers bobbypow...@gmail.com [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
* Silvan Jegen s.je...@gmail.com [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] [PATCH][RFC] Add a basic version of tr
* Silvan Jegen s.je...@gmail.com [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] Suckless remote shell?
* Alexander S. alex0pla...@gmail.com [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?
* Alexander S. alex0pla...@gmail.com [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?
* Alexander S. alex0pla...@gmail.com [2013-11-08 02:10:49 +0400]: 2013/11/7 Szabolcs Nagy n...@port70.net: 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?
* Alexander S. alex0pla...@gmail.com [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?
* Alexander S. alex0pla...@gmail.com [2013-11-04 17:11:40 +0300]: 2013/11/4 FRIGN d...@frign.de: 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] Suckless remote shell?
* Bobby Powers bobbypow...@gmail.com [2013-11-04 13:10:56 -0500]: 2013/11/4 Szabolcs Nagy n...@port70.net: 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] [sbase] [patch] Add sha256sum(1)
* Galos, David galos...@students.rowan.edu [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)
* sin s...@2f30.org [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] Re: coreutils / moreutils - DC a directory counter
* Calvin Morrison mutanttur...@gmail.com [2013-07-17 16:43:00 -0400]: On 17 July 2013 16:32, Christian Neukirchen chneukirc...@gmail.com 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] coreutils / moreutils - DC a directory counter
* Markus Teich markus.te...@stusta.mhn.de [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] coreutils / moreutils - DC a directory counter
* Szabolcs Nagy n...@port70.net [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] [sbase] Patch to make md5 and sha1 more similar
* Jens Nyberg jens.nyb...@gmail.com [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 x63 and x%64 x6 and x/64 x6 and x*64 are not the same when x might be negative (if x is negative then x63 depends on the signed int representation, but guaranteed to be in [0,63] while x%64 is in [-63,0], x6 is implementation defined and usually very different from x/64 and x6 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
* Robert Ransom rransom.8...@gmail.com [2013-07-03 10:26:03 +]: On 7/3/13, Galos, David galos...@students.rowan.edu 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] [sbase] [patch v3] Add md5sum
* sin s...@2f30.org [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] lisp
* Louis-Guillaume Gagnon louis.guillaume.gag...@gmail.com [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
* Viola Zolt?n violaz...@gmail.com [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
* sin s...@2f30.org [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 c24U; }
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)c24
or
uint32_t w = c;
w 24
Re: [dev] [sbase] 64-bit type for split
* Galos, David galos...@students.rowan.edu [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
* Galos, David galos...@students.rowan.edu [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 t...@mirbsd.de: Galos, David dixit: On GNU systems stdint.h still provides uint64_t, but I have no idea how portable this is. stdint.h 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
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);
Re: [dev] [slcon] Call for Papers 2013
* 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
* Woldemar ShiPa vovab...@rambler.ru [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
* Brandon Invergo bran...@invergo.net [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
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] Re: obase - Sta.li moving forward?
* Jens Staal staal1...@gmail.com [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
* hiro 23h...@googlemail.com [2011-12-24 02:00:47 +0100]: Deleting the first line of my log is currently done with sed 1d original.dattemp; mv temp original.dat. Is there no better way? sed -i 1d original.dat
Re: [dev] [dwm] ncol layout
* Thomas Dahms thmsd...@googlemail.com [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
* Valentin Ochs a...@0au.de [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
* Anselm R Garbe garb...@gmail.com [2011-07-24 09:40:12 +0100]: On 24 July 2011 08:38, anonymous p37si...@lavabit.com 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] [dmenu] dmenu_run improvements
* Dave Reisner d...@falconindy.com [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] Experimental editor
* Andrew Hills hills...@gmail.com [2011-06-15 11:51:17 -0400]: On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley weat...@gmail.com 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] [9base] fmt vs PLAN9PORT
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 u.h
#define NOPLAN9DEFINES
#include libc.h
@@ -61,38 +62,17 @@
return (vlong)lab.d_partitions[n].p_size * lab.d_secsize;
}
-#elif defined(__linux__)
-#include linux/hdreg.h
-#include linux/fs.h
-#include sys/ioctl.h
-#undef major
-#define major(dev) ((int)(((dev) 8) 0xff))
+#else
+#include unistd.h
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 sys/time.h
#include sys/stat.h
-#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 sys/syscall.h
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 utf.h
#include fmt.h
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 libc.h
#include termios.h
-#include sys/termios.h
+//#include sys/termios.h
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 stdarg.h
#include string.h
#include plan9.h
[dev] [9base] another cosmetic patch
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/
Re: [dev] Suckless UML
* Uriel ur...@berlinblue.org [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
* Mark Williams markrwilli...@gmail.com [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
* Robert Ransom rransom.8...@gmail.com [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)
Re: [dev] [quark] patch
* Robert Ransom rransom.8...@gmail.com [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 http://cs.nyu.edu/~dodis/ps/fuzzy.pdf. 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
* Bjartur Thorlacius svartma...@gmail.com [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..
[dev] [quark] patch
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 netdb.h
#include netinet/in.h
#include pwd.h
+#include grp.h
#include signal.h
#include stdarg.h
#include stdio.h
@@ -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 @@
Re: [dev] [sta.li] Minimalist Live Distro
* Bjartur Thorlacius svartma...@gmail.com [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
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]
* Peter John Hartman peterjohnhart...@gmail.com [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]
* Peter John Hartman peterjohnhart...@gmail.com [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++?
* Nikhilesh S s.nikhil...@gmail.com [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] libdraw development
* pancake panc...@youterm.com [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
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
* Uriel ur...@berlinblue.org [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
* Antoni Grzymala ant...@chopin.edu.pl [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
* Valentin a...@0au.de [2010-08-24 22:43:59 +0200]: [2] http://0au.de/hgweb.cgi/sfc #include locale.h ... #include wchar.h #include wctype.h 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] [vp] A media website video player/fetcher
* Kris Maglione maglion...@gmail.com [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
* Brandon LaRocque larocque.bran...@gmail.com [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 kr 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
* Chidambaram Annamalai quantumeli...@gmail.com [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] Suckless design in Games
* Chidambaram Annamalai quantumeli...@gmail.com [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
* Matthew Bauer mjbaue...@gmail.com [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] fossil scm
* pancake panc...@youterm.com [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] wrap: minimalist archiving tool
* David Tweed david.tw...@gmail.com [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
* Connor Lane Smith c...@lubutu.com [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] wrap: minimalist archiving tool
* Connor Lane Smith c...@lubutu.com [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] [surf] site-specific css?
* Rob Mason necromancer@gmail.com [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
On 7/18/10, Josh Rickmar joshua_rick...@eumx.net 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] Problem building dmenu tip
* Anselm R Garbe garb...@gmail.com [2010-07-19 07:45:16 +0100]: On 18 July 2010 21:40, Josh Rickmar joshua_rick...@eumx.net 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] dwm-5.8.2 / 9base-6
On 6/5/10, David DEMELIER demelier.da...@gmail.com 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] dwm-5.8.2 / 9base-6
On 6/4/10, ilf i...@zeromail.org 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
On 6/5/10, Szabolcs Nagy nszabo...@gmail.com wrote: On 6/5/10, David DEMELIER demelier.da...@gmail.com 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][surf]
On 5/26/10, Christophe-Marie Duquesne chm.duque...@gmail.com 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.
On 5/18/10, Marvin Vek l...@onedot.nl 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] [surf] User-Agent string.
On 5/18/10, Marvin Vek l...@onedot.nl 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] SDL fullscreen problems in dwm
On 5/14/10, hessi...@hessiess.com 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
On 5/12/10, Rory Rory tirar...@googlemail.com 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] SWK: The simple widget kit
On 5/13/10, pancake panc...@youterm.com 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] MaxFloat support?
On 4/22/10, Yue Wu vano...@gmail.com 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
On 4/11/10, markus schnalke mei...@marmaro.de wrote: Now I actually must assume, Uriel might be wrong. *eek* But is this possible? yes
Re: [dev] goblin (9base in Go)
On 3/30/10, yy yiyu@gmail.com wrote: 2010/3/29 Jeff Shipley jeffquipa...@gmail.com: The primary reason I went with the optparse library instead of using flag is that flag doesn't support multiple values for the same flag. grep -e expression1 -e expression2 -e expression3 would be completely broken when using the flag package. You can always parse the flags from your program. Gonga reads input files with the -w flag using a 'with' bool var [1]. solved: http://groups.google.com/group/golang-nuts/msg/6acf77085182189b
Re: [dev] goblin (9base in Go)
On 3/29/10, Jeff Shipley jeffquipa...@gmail.com wrote: I've been thinking about it, and I'm actually inclined to simplify grep (and eventually sed). It seems completely unnecessary to support multiple -e arguments. The 9base man page doesn't say anything about grep supporting multiple -e arguments, it simply states that -e makes it easier to specify patterns that might confuse argument parsing. dropping multiple -e support seems to be a reasonable solution for now btw have you looked at doc/progs in the go source? http://go.googlecode.com/hg/doc/progs/ there are some initial codes
window system (Re: [dev] GSoC 2010)
On 3/4/10, pancake panc...@youterm.com wrote: window system a friend of me, who is a enlightenment developer is writing a new graphical system to replace X windows, it is not suckless, but really minimal, well designed and much more well done than the Xwindowing system (its not that hard to do it better :P) I can talk to him so maybe we can push this project. Its design supports multiple local/remote graphical devices, its everything done in userland, even framebuffer drivers for two ARM boards and SDL for normal testing. Actually is focusing on 2D, but will support XV and shaders for opengl-es at some point, he doesnt wants to fill the stack will the current shit of X11 where there are several layers to do the same shit. Another thing that could be implemented is a seamless X11 integration, so you can run X11 apps by grabbing the buffer of the window and rendering it into the graphical server. So it will not be 'that hard' to move from Xorg to it. sounds interesting link/more info? how will he handle the driver issue?
Re: [dev] GSoC 2010
On 3/3/10, Antoni Grzymala ant...@chopin.edu.pl wrote: $ strings /tmp/grep | /tmp/grep -i network Machine is not on the network Name not unique on network Network is down Network is unreachable Network dropped connection on reset and valuable Xenix support: Not a XENIX named type file No XENIX semaphores available :) i guess these come from linked libc functions.. funny nevertheless
Re: [dev] AfD discussion of dwm Wikipedia article
On 2/24/10, Jason Ryan jasonwr...@gmail.com wrote: markus schnalke wrote: Maybe one should list all WMs that see dwm as their primary influence. It points to a deficiency in the way Wikipedia views notability: it is quite at odds with the notion of influence and derivation that powers free and open source software... i don't know about the policy of wikipedia but it seems to me it is full of irrelevant articles ..and i don't see why would that hurt anyone the dwm article often got out of sync with the project and it had lots of false info, meanwhile it got translated into 10 languages for me this shows that it was not the developers who maintained it but ppl who cared enough ..i thought that's the definition of being a relevant article anyway i don't really care about that article much, it just seems odd to me that they want to delete it now
Re: [dev] [dwm] Re: SHCMD(cmd): this may be a stupid question, but...
On 1/6/10, Thayer Williams thay...@gmail.com wrote:
{ MODKEY, XK_z, spawn, BASHCMD(commandname) },
s/BASHCMD/SHCMD/;s/commandname/shell script/
spawn used to run the specified command in a shell in ancient dwm,
so SHCMD macro is a convenience and backward compatibility feature
in the default config
[dev] [dmenu] bug
$ echo a | dmenu X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 1 (X_CreateWindow) Value in failed request: 0x0 Serial number of failed request: 36 Current serial number in output stream: 39 this happens when the pointer is in an invisible area in a multihead setup ltrace tail: XCreateFontSet(0x8cf9ee8, 0x804aceb, 0xbfb0a98c, 0xbfb0a988, 0xbfb0a990) = 0x8d05e90 XFreeStringList(0x8d066a0, 65407, 0x8d040fa, 0x8d040fa, 1) = 1 XExtentsOfFontSet(0x8d05e90, 65407, 0x8d040fa, 0x8d040fa, 1) = 0x8d05eb8 XFontsOfFontSet(0x8d05e90, 0xbfb0a984, 0xbfb0a980, 0x8d040fa, 1) = 3 XineramaIsActive(0x8cf9ee8, 0xbfb0a984, 0xbfb0a980, 0x8d040fa, 1) = 1 XineramaQueryScreens(0x8cf9ee8, 0xbfb0a998, 0x804aceb, 0x804aceb, 1) = 0x8d071f0 XQueryPointer(0x8cf9ee8, 177, 0xbfb0a97c, 0xbfb0a97c, 0xbfb0a9a0) = 1 XFree(0x8d071f0, 0xbfb0a998, 0x804aceb, 0x804aceb, 1) = 1 XCreateWindow(0x8cf9ee8, 177, -16903, 0, 0) = 0x141 XCreatePixmap(0x8cf9ee8, 177, 0, 16, 24) = 0x142 XCreateGC(0x8cf9ee8, 177, 0, 0, 1) = 0x8d07210 XSetLineAttributes(0x8cf9ee8, 0x8d07210, 1, 0, 1) = 1 XmbTextExtents(0x8d05e90, 0x8d042a0, 1, 0, 0xbfb0a908X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 1 (X_CreateWindow) Value in failed request: 0x0 Serial number of failed request: 36 Current serial number in output stream: 39 unfinished ... +++ exited (status 1) +++
[dev] [9base] troff/tmac path problem
in 9base/troff/tmac/ some macro files contain the /home/anselm/plan9port/tmac/ path in it instead of /usr/local/plan9/lib/troff/tmac/
Re: [dev] Less Sucking X Window System?
On 12/15/09, Dieter Plaetinck die...@plaetinck.be wrote: On Tue, 15 Dec 2009 10:54:03 +0100 Frederik Caulier aed...@gmail.com wrote: Some of you might be interested in alternatives to the X Window System, so I thought I'd just share [0] with you. there are also: http://en.wikipedia.org/wiki/Wayland_%28display_server%29 http://en.wikipedia.org/wiki/MicroXwin which may or may not be[come] less sucky then Xorg resp X11 i think the possible alternatives were explored and the conclusion was to write a new one http://hg.suckless.org/dws/ but it would be a huge work, so won't happen anytime soon..
Re: [dev] a suckless computer algebra system
suckless calculators: bc, hoc On 11/20/09, Alex Ghitza aghi...@gmail.com wrote: In the end, it depends on what you want to do with your CAS. If you want something very precise, there is good specialised software around (Pari was already mentioned for number theory, GAP is the way to go for group theory, Macaulay2 for algebraic geometry, Singular for commutative algebra, mpmath for special functions, R for statistics, etc.) +1 for pari/gp and gap system R and octave are for numerical calculations (float64) so i would not call them cas they tend to use lots of other libs optimization: lpsolve, glpk, cvxopt, sedumi computational geometry: qhull, cgal ..
Re: [dev] a suckless computer algebra system
On 11/20/09, Jukka Ruohonen jruoho...@iki.fi wrote: On Thu, Nov 19, 2009 at 02:23:35PM -0600, A.J. Gardner wrote: Anyone know of any suckless math software out there in the tubes? As for algebra, the king of the hill is without doubt LAPACK. But since LAPACK is about floating point computations, it has nothing to do with algebra numerical linear algebra != abstract algebra (ieee floats aren't even a group: eg Nans have no additive inverse)
Re: [dev] a suckless computer algebra system
On 11/20/09, Anselm R Garbe ans...@garbe.us wrote: Why not? I think it should be possible to have very minimalist and specialized CAS', they managed to do that in the 50s and 60s, why not today? ah good old reduce
[dev] [dwm] ff - enter root - selmon change bug
i think i found an issue with monitor focusing:
in enternotify monitor change events are checked
if((m = wintomon(ev-window)) m != selmon) {
unfocus(selmon-sel);
selmon = m;
}
firefox has a clever address bar with a dropdown menu that grabs
keys and everything. it occasionally generates enternotify events for
the root window (i havent't yet figured out when and why) so if i left
the mouse pointer on the other monitor and start typing into the
address bar selmon sometimes changes leaving ff unfocused etc
not sure if it's fixable..
[dev] Re: [dwm] ff - enter root - selmon change bug
On 11/17/09, Szabolcs Nagy nszabo...@gmail.com wrote:
i think i found an issue with monitor focusing:
in enternotify monitor change events are checked
if((m = wintomon(ev-window)) m != selmon) {
unfocus(selmon-sel);
selmon = m;
}
another related corner case:
moving window to another monitor does not move the focus
but when the mouse pointer is on the other monitor and no window is
there yet then monitor focus changes too
Re: [dev] dmc news
On 11/10/09, Anders Andersson pipat...@gmail.com wrote: Why rewrite it in C? What will you gain with this? There's a lot of code in the shell interpreter, and everyone will have one (even in an embedded environment you'll have busybox ash or similar). Use the code that's already there. :) usually true but shell can be hideous resulting non-trivial security and portability issues
