Re: [dev] dwm taskbar icons via pcf font
Thanks Bryan, your icons work, but only in my terminal not xterm when I choose Tamsyn2 font and echo -e \xC1, however when I edited your font with my gbdfed, saved, reconverted, and put it into /usr/share/fonts/local/, ran my terminal and echo -e \xA1(my added icon) didn't show up, but produced empty string, however , when I replaced your icon under C1 index and tried the same it did show up with my icon. So newly added icons do not work, when modifying your icons work, ahh, this is so jinxed. This is the only way I got it all working, do you have any ideas why)? You could try to call xset fp rehash after you installed the new font. X caches font information, so a rehash might show up new font glyphs. -- Eckehard Berns
Re: [dev] TermKit
On Fri, May 20, 2011 at 10:06 AM, Nick suckless-...@njw.me.uk wrote: On Fri, May 20, 2011 at 12:23:39AM +0200, hiro wrote: https://github.com/unconed/TermKit no comment, only sorry. indeed. i read about it yesterday. makes me want to vomit. Certainly the general implementation, the language and the architecture do seem nasty. OTOH, it always depresses me that it's kind of taken as a virtue that the interactive shell and the terminal are know almost nothing about each other (at least for almost all modern computing devices, I can see if you genuinely are using a 1970's dumb terminal you don't have the wiggle room for more). At the very least, it would be very productive to 1. Have a terminal/shell combination that, upon resizing, actually redisplays text properly rather than just chops off stuff in vanished/newly visible space. 2. Had the _option_ for shell history to pop up in another window, rather than _only_ being available as a command output, so that it scrolls other stuff you've been doing off the screen. 3. Had more flexible context-sensitive cutting support. (Eg, let me somehow copy a sequence of commands text without including either the prompt or command output.) Obviously it's not clear what the best way to provide greater information flow between interactive shells and terminals, and it may/may not be that the Plan9 or emacs-shell approach is the way to go, but it'd be nice if there was some increase in terminal productivity in the coming years. (Of course, the other problem is it's a large number of shells and terminals to change, and if additional metadata needs adding to commands that's a huge number of programs to change, so it's unlikely to happen...) -- cheers, dave tweed__ computer vision reasearcher: david.tw...@gmail.com while having code so boring anyone can maintain it, use Python. -- attempted insult seen on slashdot
Re: [dev] TermKit
Hey, On 20 May 2011 12:51, David Tweed david.tw...@gmail.com wrote: Certainly the general implementation, the language and the architecture do seem nasty. OTOH, it always depresses me that it's kind of taken as a virtue that the interactive shell and the terminal are know almost nothing about each other fwiw, I agree. TermKit appears to be a very glossy turd, but there are certainly outstanding issues in our terminals, which is why in Plan 9 they tried to fix them by pairing a plaintext-only Rio term with graphical windows which actually replace the spawning term. It's not perfect, but the plaintext / graphics dichotomy does make things simpler in some ways. I think the way to solve this problem is not to add structure to pipes (which tend to be simple to use *because* they have no real structure), but to allow commands to draw directly to the terminal if they wanted. So the standard input / output piping system would remain unchanged, and all commands -- except those which rely on unhygienic escape codes, like curses -- would work just like normal. However, if the command would like it could communicate directly to the term and say show this diagram, or whatever. The term would basically be an ever-downward-scrolling canvas, which shows mostly text but may occasionally display simple graphics too. It would need some experimentation to find out what the best system would be, but ultimately it's just the Plan 9 approach except the drawn information is printed onto the term itself, and thus scrolls with it, rather than replacing the term entirely. This doesn't inherently solve every problem you mentioned, David, but it would probably be a good first step toward an innovative new terminal, and would be less vain than TermKit's approach. Thanks, cls
Re: [dev] TermKit
On Fri, May 20, 2011 at 2:26 PM, Connor Lane Smith c...@lubutu.com wrote: I think the way to solve this problem is not to add structure to pipes (which tend to be simple to use *because* they have no real structure), but to allow commands to draw directly to the terminal if they wanted. So the standard input / output piping system would remain unchanged, and all commands -- except those which rely on unhygienic escape codes, like curses -- would work just like normal. rxvt implements basic drawing primitives via escape codes[1]. It's disabled at compile time by default but you can find some poc in the source distribution that plots stuff. I think it has been dropped in urxvt. It's ok for very simple stuff but I really don't think it's scalable for anything remotely useful. 1: http://www.usf.uos.de/infoservice/doc/localhtml/rxvt/refer.html#Graphics
Re: [dev] TermKit
On Fri, May 20, 2011 at 1:26 PM, Connor Lane Smith c...@lubutu.com wrote: fwiw, I agree. TermKit appears to be a very glossy turd, but there are certainly outstanding issues in our terminals, which is why in Plan 9 they tried to fix them by pairing a plaintext-only Rio term with graphical windows which actually replace the spawning term. It's not perfect, but the plaintext / graphics dichotomy does make things simpler in some ways. That's an interesting proposal. The areas for improvement I tend to see revolve more around text and the information-loss going between the interactive shell and the terminal (so that this information is only accessible via typing shell commands). Eg, the shell knows which bits are the input, output, prompt but by the time the terminal has displayed it it's all one big block of text. -- cheers, dave tweed__ computer vision reasearcher: david.tw...@gmail.com while having code so boring anyone can maintain it, use Python. -- attempted insult seen on slashdot
Re: [dev] sltar c
It's on my working copy. Looks very promising, thank you ;) Am 19.05.2011 um 20:15 schrieb Connor Lane Smith: Hey all, I've written a quick patch for sltar which lets you create archives as well as extract and list them. (It reads the files' paths in through stdin.) I've not tested it extensively, but it seems to work well. Maybe Enno could apply it to the sltar repo? Thanks, cls sltar.patch
Re: [dev] TermKit
On Fri, 20 May 2011 14:40:39 +0100 Connor Lane Smith c...@lubutu.com wrote: On 20 May 2011 14:27, Dieter Plaetinck die...@plaetinck.be wrote: I think a fd to write something to like here's an image, please render it somewhere is better than cls's suggestion of having apps directly write to the terminal. I think the latter idea would get messy quickly. It's as if X windows would draw themself to the screen rather then having a window manager take care of it. I disagree. Your approach is as if X windows would have no control over their interface besides draw me now! My approach would probably involve Xembed: the program creates a new window, the terminal embeds it into the right place, and then the program can draw to this (like how tabbed works, only downward-scrolling). Each process can ask for a little space in the canvas and they can draw only within that. I think I misunderstood your previous mail. If you mean that the terminal/shell is the one who can say this region is where you can draw your image, and the app can draw the image, that's fine for me. Maybe that's even better (less complicated) than the app passing an image to the shell/terminal and asking to draw it. This is in fact mandatory for apps who want to draw nice graphs/graphics/interfaces, the terminal isn't even able to do that anyway. I thought earlier you meant that the apps should decide also _where_ (as in: position on screen / inside terminal window) they write output to.
Re: [dev] TermKit
On Fri, May 20, 2011 at 9:40 AM, Connor Lane Smith c...@lubutu.com wrote: I suppose that could be a useful interface, so long as it was clear which commands are associated with which output. Otherwise stdout could get a little messy. Also, by default stdout and stderr ought to be combined, perhaps with stderr in yellow or something. I don't understand why. If you want stderr to be combined into stdout, suffix 21 to your command. By default, I think different filehandles should land in different outputs. As for associating commands with their output, that would be trivial. Typing in your command script in the input window and causing it to be executed should start a subshell. Captured output from stdout should be rendered in the output window, perhaps with a box around it, possibly numbered. Then you can go back to the input window to browse your command history, and selecting a history entry should be able to bring up the output of that command. when you have a clean separation between filehandles, and you're not just dumping all three into one bidirectional window, maintaining the relationships between data in each should be much, much easier. This obviously ignores the problem of backgrounded tasks, but even that would be nicer: instead of just getting shit dumped on the screen with a pid prefix, the terminal could just open another output window. The more I think about this interface the more I want to write it. -- # Kurt H Maier
Re: [dev] TermKit
On 20 May 2011 14:54, Kurt H Maier karmaf...@gmail.com wrote: I don't understand why. If you want stderr to be combined into stdout, suffix 21 to your command. By default, I think different filehandles should land in different outputs. I just think the stdout and stderr ought to be visible at the same time. Or perhaps it would suffice to show stderr above stdout, or automatically switch, or something. Typing in your command script in the input window and causing it to be executed should start a subshell. Captured output from stdout should be rendered in the output window, perhaps with a box around it, possibly numbered. Then you can go back to the input window to browse your command history, and selecting a history entry should be able to bring up the output of that command. That sounds good to me. And you could head each 'output box' with the command which produced it. (Though numbering could be useful too.) I'm considering writing a 'next gen' 9term, if you'll excuse the expression, and these ideas (a terminal 'canvas', and separated streams) sound like they would be a very nice fit. cls
Re: [dev] TermKit
On Fri, 20 May 2011 15:19:00 +0100 Connor Lane Smith c...@lubutu.com wrote: On 20 May 2011 14:54, Kurt H Maier karmaf...@gmail.com wrote: I don't understand why. If you want stderr to be combined into stdout, suffix 21 to your command. By default, I think different filehandles should land in different outputs. I just think the stdout and stderr ought to be visible at the same time. Or perhaps it would suffice to show stderr above stdout, or automatically switch, or something. this could be configurable by the user. or at least changeable at runtime.
Re: [dev] TermKit
2011/5/20 Hadrian Węgrzynowski hadr...@hawski.com: Sometimes I would like to display some graphics inside terminal window. We could draw directly in terminal's window or place graphics inline with text. I would prefer second method. I think the way I described it in my first email was a little confusing. As I clarified to Dieter, what I meant was that the program would request a space in which to draw, and the term would place this drawing space in-line (i.e., as graphics within text), so that it scrolls with the output, and so on. One of the key features of text terminals is monospaced font - that makes everything easier to align and easier to code. As I said I would like to display some graphics, but I don't want to give up on grid aligned display. I would prefer to display graphics within text. But for this to make sense program in many cases needs to know width and height of image in terminal characters. I don't think so. If the term is handling the placement of images, it can maintain the monospaced columns without the drawing process having to know anything about character size. Instead, the image is drawn, and the term simply continues drawing characters in the next column, so everything still lines up fine. We also don't have to reinvent the wheel with escape codes, since we can just use Xembed. Upon receiving an Xembed request the term would just stick that window in-line, with the appropriate size and everything, and that's dandy. (I checked, btw, and it seems you can XCopyArea from child windows, which is necessary for this approach.) cls
Re: [dev] dwm taskbar icons via pcf font
That font encoding is pretty arbitrary - I chose the encoding that Tamsyn already carried. I don't require too much more than ASCII due to my locale (en_US), so I stuck with en_US.ISO8859-1. If you needed to, you could copy the glyphs over into another font, say Terminus, that has better support for your locale. You'd just need to place them differently so that they wouldn't overlap characters that you use regularly. The rehash needs to be done every time you want to reload the font, so just setting it in .xinitrc wouldn't help if you wanted to 'live' test your changes. You'd need to rerun the rehash every time.
[dev] [st] maps window before setting the title, confuses dwm's matching
Hi all,
In the current version of st, when invoked with the -t option, it
would map the window before setting its title, which would prevent dwm
(or any other dynamic wm) from matching its rules against it. Here's a
patch that fixed the thing for me:
diff -r 1eb3e1b6a8d0 st.c
--- a/st.c Sat May 14 17:47:37 2011 +0200
+++ b/st.c Fri May 20 18:59:38 2011 +0300
@@ -1632,9 +1632,9 @@
(XColor){.red = 0x, .green = 0x, .blue = 0x},
(XColor){.red = 0x, .green = 0x, .blue = 0x});
+ XStoreName(xw.dpy, xw.win, opt_title ? opt_title : st);
XMapWindow(xw.dpy, xw.win);
xhints();
- XStoreName(xw.dpy, xw.win, opt_title ? opt_title : st);
XSync(xw.dpy, 0);
}
Thanks,
Kamil
Re: [dev] TermKit
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati sun...@gmail.com wrote:
history | xmessage -file -
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(STDIN){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i=0;$i--){print $o[$i];}' | dmenu -b`
}
--Andrew Hills
Re: [dev] TermKit
On 20 May 2011 17:24, Suraj N. Kurapati sun...@gmail.com wrote: Use /dev/tty to draw to the terminal independently of std streams: date | sh -c 'read; echo $REPLY /dev/tty' /dev/null Your graphics look suspiciously like text. (I think you missed the point.) cls
Re: [dev] TermKit
On 5/20/11, Andrew Hills hills...@gmail.com wrote:
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(STDIN){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i=0;$i--){print $o[$i];}' | dmenu -b`
}
I'm sorry for my total lack of 1337ness, but what does the perl part do?
Re: [dev] TermKit
On Fri, May 20, 2011 at 12:47 PM, Bjartur Thorlacius svartma...@gmail.com wrote: I'm sorry for my total lack of 1337ness, but what does the perl part do? Strips the numbers off the start of each line, reverses the order (for most recent first), and skips the first (last) entry (which is the command you typed to bring up the history). --Andrew Hills
Re: [dev] TermKit
On Fri, 20 May 2011, Andrew Hills wrote:
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati wrote:
history | xmessage -file -
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(STDIN){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i=0;$i--){print $o[$i];}' | dmenu -b`
}
Yikes. Ugly indeed. Unsolicited (sort of... something wrong on the
internet 'n all), but:
'for($i=$#o-1;$i=0;$i--){print $o[$i];}'
is better written:
'pop @o; print for reverse @o'
or
'print for reverse @o[0..$#o-1]'
Plus it's easier to reverse the whole thing outside of Perl (via tac),
and you can use '-n' to avoid the 'while(STDIN){}', so the whole thing
becomes:
h()
{
`history | perl -nwe 's/\s+\d+\s+//; print unless eof' | tac | dmenu -b`
}
Don't have `tac` installed? (I think it's in linux-utils or core-utils,
but maybe it's linux- and/or GNU-centric.)
tac () { perl -nwe 'unshift @o, $_; END { print for @o }' }
--
Best,
Ben
Re: [dev] TermKit
Thanks for the Perl-readability tip. On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell suckl...@benizi.com wrote: Don't have `tac` installed? (I think it's in linux-utils or core-utils, but maybe it's linux- and/or GNU-centric.) I do most of my work on Solaris, and it's not really worth the effort to install tac to use it in one place. --Andrew Hills
Re: [dev] TermKit
On Fri, 20 May 2011, Andrew Hills wrote: Thanks for the Perl-readability tip. No prob. On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell wrote: Don't have `tac` installed? (I think it's in linux-utils or core-utils, but maybe it's linux- and/or GNU-centric.) I do most of my work on Solaris, and it's not really worth the effort to install tac to use it in one place. Agreed. I might drop the substitute I listed into ~/.zsh/autoload/tac (can't live w/o syncing at least my shell startup files to systems I use). The wikipedia article on `tac` (first result when googling to see if it was indeed linux-specific) mentioned `tail -r` as a possible substitute. Anyone know what `tail`s support '-r' ( == reverse? )? or more generally, anyone have a good reference for differences in common commands across posix-like O/S'es? -- Best, Ben
Re: [dev] TermKit
On Fri, May 20, 2011 at 1:42 PM, Andrew Hills hills...@gmail.com wrote: Not supported by default on Solaris 5.8, Solaris 5.10, RHEL 4(NU7), RHEL 5.6, or Arch Linux (updated an hour ago). According to [0], only BSD tail has the reverse option. Any reason not to sort(1) them before you feed them to perl? And don't get me wrong: perl is my favorite language, but wouldn't something akin to history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//' work just as well? -- # Kurt H Maier
Re: [dev] TermKit
On Fri, May 20, 2011 at 2:21 PM, Andrew Hills hills...@gmail.com wrote: (Don't forget to escape your asterisks in sed.) I just pasted the output of TermKit. -- # Kurt H Maier
Re: [dev] TermKit
On Fri, May 20, 2011 at 2:22 PM, Kurt H Maier karmaf...@gmail.com wrote: I just pasted the output of TermKit. Something tells me to suspect that this is untrue. --Andrew Hills
Re: [dev] TermKitjkjkjn
Subject: Re: [dwm] TermKitjkjkjn dwm's focus rules still surprise me sometimes (mainly in monocle mode where urxvt doesn't occupy the entire screen, due to the screen not being evenly divisible by character cells). The jkjkjn tacked on to the subject there was me trying to 'shake' an apparently-frozen vim session, which inadvertently sent email from the window I couldn't see...
Re: [dev] TermKitjkjkjn
On 20 May 2011 19:58, Benjamin R. Haskell suckl...@benizi.com wrote: dwm's focus rules still surprise me sometimes (mainly in monocle mode where urxvt doesn't occupy the entire screen, due to the screen not being evenly divisible by character cells). static const Bool resizehints = False; ;) cls
Re: [dev] TermKitjkjkjn
On Fri, 20 May 2011, Connor Lane Smith wrote: On 20 May 2011 19:58, Benjamin R. Haskell wrote: dwm's focus rules still surprise me sometimes (mainly in monocle mode where urxvt doesn't occupy the entire screen, due to the screen not being evenly divisible by character cells). static const Bool resizehints = False; ;) Awesome. Never knew what that was about. -- Thanks, Ben
Re: [dev] sltar c
Quoth Connor Lane Smith: I've written a quick patch for sltar which lets you create archives as well as extract and list them. (It reads the files' paths in through stdin.) I've not tested it extensively, but it seems to work well. Maybe Enno could apply it to the sltar repo? Well really, that's most annoying. I've had a local patch of sltar to add create support for ages now, but had never quite cleaned it up to a state that I was happy sharing it, and here you come along with a fresh patch which is much nicer and cleaner than mine ever could have been. Thanks ;) One thing which could be considered would be allowing specifying file / directory names on argv. While it complicates the code, and is a less flexible way of specifying things, it does add compatibility with a lot of scripts which will expect it. They will also expect recursive directory traversal, so 'tar c mydir/' will tar up everything under mydir. I know backwards compatibility, particularly with the unix ecosystem, is a dangerous rabbithole to jump in to, but this feature is probably worth it. Another feature which would be nice would be stripping of leading / and .. from path names when creating and extracting archives. So that things cannot be too impolite /dangerous. Nick pgpaeQnCZcEFF.pgp Description: PGP signature
Re: [dev] sltar c
On 20 May 2011 21:51, Nick suckless-...@njw.me.uk wrote:
One thing which could be considered would be allowing specifying
file / directory names on argv.
Another feature which would be nice would be stripping of leading /
and .. from path names when creating and extracting archives.
Attached!
I also fixed a bug in my patch, and a bug in tip.
cls
diff -r fadca8e2d4d0 sltar.c
--- a/sltar.c Fri May 20 22:12:58 2011 +0100
+++ b/sltar.c Fri May 20 23:39:53 2011 +0100
@@ -3,6 +3,7 @@
*
* See LICENSE for further informations
*/
+#include dirent.h
#include stdlib.h
#include unistd.h
#include stdio.h
@@ -14,22 +15,23 @@
SUM = 148, TYPE = 156, LINK = 157, MAJ = 329, MIN = 337, END = 512
};
+static int appenddir(const char *dir);
static int append(const char *file);
static int cksum(unsigned char *b);
-static int create(void);
-static int xtract(char a);
+static int create(int argc, char *argv[]);
+static int xtract(int argc, char *argv[], char a);
int
main(int argc, char *argv[]) {
char a;
- if(argc == 2 strlen(argv[1]) == 1)
+ if(argc 1 strlen(argv[1]) == 1)
switch((a = argv[1][0])) {
case 'c':
- return create();
+ return create(argc-2, argv[2]);
case 'x':
case 't':
- return xtract(a);
+ return xtract(argc-2, argv[2], a);
}
/* should not reach */
@@ -44,7 +46,7 @@
char buf[END];
size_t n;
struct stat st;
- FILE *fp;
+ FILE *fp = NULL;
if(stat(file, st) == -1) {
fprintf(stderr, %s: cannot stat\n, file);
@@ -78,23 +80,45 @@
fprintf(stderr, %s: unsupported file type\n, file);
return EXIT_FAILURE;
}
- if(buf[TYPE] == '3' || buf[TYPE] == '4') {
+ if(S_ISCHR(st.st_mode) || S_ISBLK(st.st_mode)) {
snprintf(buf[MAJ], 8, %07o, major(st.st_rdev));
snprintf(buf[MIN], 8, %07o, minor(st.st_rdev));
}
snprintf(buf[SUM], 8, %06o, cksum((unsigned char *)buf));
buf[SUM+7] = ' ';
- if(!(fp = fopen(file, r))) {
+ if(S_ISREG(st.st_mode) !(fp = fopen(file, r))) {
fprintf(stderr, %s: cannot open\n, file);
return EXIT_FAILURE;
}
- for(n = 1; n 0; n = fread(buf, 1, sizeof buf, fp)) {
+ for(n = 1; n 0; n = fp ? fread(buf, 1, sizeof buf, fp) : 0) {
fwrite(buf, sizeof buf, 1, stdout);
memset(buf, 0, sizeof buf);
}
- fclose(fp);
- return EXIT_SUCCESS;
+ if(fp)
+ fclose(fp);
+ return S_ISDIR(st.st_mode) ? appenddir(file) : EXIT_SUCCESS;
+}
+
+int
+appenddir(const char *dir)
+{
+ char buf[BUFSIZ];
+ int ret = EXIT_SUCCESS;
+ struct dirent *d;
+ DIR *dp;
+
+ if(!(dp = opendir(dir))) {
+ fprintf(stderr, %s: cannot opendir\n, dir);
+ return EXIT_FAILURE;
+ }
+ while((d = readdir(dp)))
+ if(strcmp(d-d_name, .) != 0 strcmp(d-d_name, ..) != 0) {
+ snprintf(buf, sizeof buf, %s/%s, dir, d-d_name);
+ if(append(buf) == EXIT_FAILURE)
+ret = EXIT_FAILURE;
+ }
+ return ret;
}
int
@@ -108,32 +132,47 @@
}
int
-create(void) {
+create(int argc, char *argv[]) {
char buf[BUFSIZ], *p;
- int ret = EXIT_SUCCESS;
+ int i, ret = EXIT_SUCCESS;
- while(fgets(buf, sizeof buf, stdin)) {
- if((p = strchr(buf, '\n')))
+ for(i = 0; argc ? i argc : fgets(buf, sizeof buf, stdin) != NULL; i++) {
+ if(!argc (p = strchr(buf, '\n')))
*p = '\0';
- if(append(buf) == EXIT_FAILURE)
+ if(append(argc ? argv[i] : buf) == EXIT_FAILURE)
ret = EXIT_FAILURE;
}
return ret;
}
int
-xtract(char a) {
- int l;
- char b[END],fname[101],lname[101];
+xtract(int argc, char *argv[], char a) {
+ int i, l;
+ char b[END], fname[101], lname[101], *p;
FILE *f = NULL;
for(lname[100] = fname[100] = l = 0; fread(b,END,1,stdin); l -= END)
- if(l = 0) {
+ if(l = 0) {
if(*b == '\0')
break;
- memcpy(fname,b,100);
+ for(p = b; *p == '/'; p++);
+ memcpy(fname, p, 100);
+
+ for(i = 0; i argc; i++)
+if(!strcmp(argv[i], fname))
+ break;
+
memcpy(lname,b + LINK,100);
- l = strtoull(b + SIZE,0,8) + END;
+
+ if(b[TYPE] == '0')
+l = strtoull(b + SIZE,0,8) + END;
+ else
+l = END;
+ if(argc i == argc) {
+if(a == 'x' b[TYPE] == '0' !(f = fopen(/dev/null, w)))
+ perror(/dev/null);
+continue;
+ }
if(a == 't') {
puts(fname);
continue;
Re: [dev] sltar c
On 20 May 2011 23:42, Connor Lane Smith c...@lubutu.com wrote: Another feature which would be nice would be stripping of leading / and .. from path names when creating and extracting archives. Oh, I didn't do the '..' bit though. I couldn't be bothered, basically. Shouldn't be too difficult, though, with strstr memmove. cls
[dev] Making Apps That Don't Suck by Mike Lee
Hello, Here is an interesting and relevant talk on suckless design: Making Apps That Don't Suck by Mike Lee on May 20, 2011 (~1hr) http://www.infoq.com/presentations/Making-Apps-That-Dont-Suck Cheers. -- In less than a century, computers will be making substantial progress on ... the overriding problem of war and peace. -- James Slagle signature.asc Description: PGP signature
