From sam-fans-owner Wed Nov 18 20:24:38 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2795>; Wed, 18 Nov 1992 20:24:21 -0500 To: sam-fans Subject: Welcome to the sam-fans mailing list Date: Wed, 18 Nov 1992 20:24:08 -0500 From: Chris Siebenmann Message-Id: <92Nov18.202421est.2795@hawkwind.utcs.toronto.edu> Well, a lot more people asked for a copy of my patches than I thought would, so I made a mailing list. Feel free to use it for more patches, discussion, questions, or the usual. Deletion or addition requests to sam-fans-request@hawkwind.utcs.toronto.edu; feel free to tell other people you think might be interested about it. - cks From sam-fans-owner Wed Nov 18 20:42:21 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2795>; Wed, 18 Nov 1992 20:42:07 -0500 To: sam-fans Subject: My patches Date: Wed, 18 Nov 1992 20:42:01 -0500 From: Chris Siebenmann Message-Id: <92Nov18.204207est.2795@hawkwind.utcs.toronto.edu> Here are my patches (and my readme for them). All diffs are relative to the current source on research.att.com. README.cks: I've made various modifications to the sam source in these directories, originally from research.att.com:/dist/sam. This is an attempt to sort of describe them. libXg: - sweeping out a rectangle will now grab the pointer from the X server; this means that you can swipe from outside the sam window, making sure your windows line up neatly with the boundary of the sam window. - sam (more properly, samterm) will now attempt to use both old and new style X selections; it always writes to both new and old-style, and attempts to read from the old-style selection if the new-style one is empty. - menus no longer force the mouse to center on them; the pointer stays where it was when you selected the menu. libframe: - some small diddling to work with Ultrix better - u.h's exits() and _exits() macros fixed to a form more palatable to the Sun ANSI compiler (v!=0 checks vs (v)). - u.h: map exec() to execvp(), not execv(), so our $PATH will get searched if necessary samterm: - change to mesg.c to center a searched-for selection in the window (change by Byron) I don't think there are any other bugs or real problems left in sam and/or samterm, but I haven't used it TOO much. Patches: *** /tmp/,RCSt1a09176 Wed Nov 18 20:21:28 1992 --- libXg/getrect.c Mon Nov 16 17:44:04 1992 *************** *** 20,29 **** --- 20,30 ---- but = 1<<(but-1); cursorswitch(&sweep); while(m->buttons) *m = emouse(); + _grabpointer(); while(!(m->buttons & but)){ *m = emouse(); if(m->buttons & (7^but)) goto Return; } *************** *** 42,48 **** --- 43,50 ---- if(m->buttons & (7^but)){ rc.min.x = rc.max.x = 0; while(m->buttons) *m = emouse(); } + _ungrabpointer(); return rc; } *** /tmp/,RCSt1a09176 Wed Nov 18 20:21:29 1992 --- libXg/libgint.h Mon Nov 16 17:44:05 1992 *************** *** 35,44 **** --- 35,48 ---- extern GC _getcopygc(Fcode, Bitmap*, Bitmap*, int*); /* balloc without zero init (which uses a gc!) */ extern Bitmap *_balloc(Rectangle, int); + /* grab and ungrab the pointer. might be safe to make externally visible, + but really only around for getrect(). */ + extern void _grabpointer(void), _ungrabpointer(void); + /* X Display for this application's connection */ extern Display *_dpy; /* screen depth foreground and background for this application */ extern unsigned long _fgpixel, _bgpixel; *** /tmp/,RCSt1a09176 Wed Nov 18 20:21:30 1992 --- libXg/menuhit.c Mon Nov 16 17:44:05 1992 *************** *** 76,86 **** font, item, S); } bflush(); lasti = menusel(menur, m->xy); r = menurect(menur, menu->lasthit); ! cursorset(divpt(add(r.min, sub(r.max, Pt(0,Vspacing))), 2)); bitblt(&screen, r.min, &screen, r, F&~D); for(;;){ *m = emouse(); if(!(m->buttons & (1<<(but-1)))) break; --- 76,86 ---- font, item, S); } bflush(); lasti = menusel(menur, m->xy); r = menurect(menur, menu->lasthit); ! /* cursorset(divpt(add(r.min, sub(r.max, Pt(0,Vspacing))), 2)); */ bitblt(&screen, r.min, &screen, r, F&~D); for(;;){ *m = emouse(); if(!(m->buttons & (1<<(but-1)))) break; *** /tmp/,RCSt1a09176 Wed Nov 18 20:21:31 1992 --- libXg/xtbinit.c Mon Nov 16 17:44:04 1992 *************** *** 642,651 **** --- 642,659 ---- int snarfswap(char *s, int n, char **t) { *t = GwinSelectionSwap(widg, s); + if ((*t && strlen(*t) == 0) || !*t) { + int l; + /* Might be using old-style selections. */ + *t = XFetchBytes(_dpy, &l); + } + /* Cope with really old clients: write into old selection + buffer too. */ + XStoreBytes(_dpy, s, n); if (*t) return strlen(*t); return 0; } *************** *** 662,666 **** --- 670,690 ---- v.foreground, v.background, v.function, v.fill_style, v.font, v.tile, v.stipple); } #endif + void + _grabpointer(void) + { + /* Grab X server with an iron hand. */ + while (XGrabPointer(_dpy, XtWindow(widg), False, + ButtonPressMask|ButtonReleaseMask|ButtonMotionMask| + StructureNotifyMask|ExposureMask|KeyPressMask, + GrabModeAsync, GrabModeAsync, None, None, CurrentTime) + != GrabSuccess) + (void) sleep(2); + } + void + _ungrabpointer(void) + { + XUngrabPointer(_dpy, CurrentTime); + } *** /tmp/,RCSt1a09176 Wed Nov 18 20:21:32 1992 --- libframe/u.h Mon Nov 16 17:44:05 1992 *************** *** 91,100 **** --- 91,105 ---- #define WEXITSTATUS(s) (((s)>>8)&0xFF) #define NEEDMEMMOVE #define NEEDSTDARG #endif /* DYNIX */ + #ifdef __ultrix + typedef unsigned long ulong; + #define NEEDSTDARG + #endif + #ifdef v10 typedef unsigned short ushort; typedef unsigned long ulong; #endif *************** *** 105,120 **** #define sprint sprintf #define dup(a,b) dup2(a,b) #define seek(a,b,c) lseek(a,b,c) #define create(name, mode, perm) creat(name, perm) ! #define exec(a,b) execv(a,b) #define USED(a) #define SET(a) ! #define exits(v) if (v) exit(1); else exit(0) ! #define _exits(v) if (v) _exit(1); else _exit(0) enum { OREAD = 0, /* open for read */ OWRITE = 1, /* open for write */ --- 110,125 ---- #define sprint sprintf #define dup(a,b) dup2(a,b) #define seek(a,b,c) lseek(a,b,c) #define create(name, mode, perm) creat(name, perm) ! #define exec(a,b) execvp(a,b) #define USED(a) #define SET(a) ! #define exits(v) if (v!=0) exit(1); else exit(0) ! #define _exits(v) if (v!=0) _exit(1); else _exit(0) enum { OREAD = 0, /* open for read */ OWRITE = 1, /* open for write */ *** /tmp/,RCSt1a09176 Wed Nov 18 20:21:33 1992 --- samterm/mesg.c Wed Nov 18 15:16:57 1992 *************** *** 492,502 **** { Text *t = whichtext(m); Flayer *l = &t->l[t->front]; if(p0origin || p0-l->origin>l->f.nchars*9/10) ! outTsll(Torigin, m, p0, 2L); } void hcheck(int m) { --- 492,502 ---- { Text *t = whichtext(m); Flayer *l = &t->l[t->front]; if(p0origin || p0-l->origin>l->f.nchars*9/10) ! outTsll(Torigin, m, p0, l->f.nlines / 2L); } void hcheck(int m) { From sam-fans-owner Wed Nov 18 21:55:57 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2795>; Wed, 18 Nov 1992 21:55:42 -0500 Received: by mod.civil.su.oz.au id <28683>; Thu, 19 Nov 1992 13:54:58 +1100 From: John (For the colours are many, but the light is one.) Mackin Date: Wed, 18 Nov 1992 21:12:05 -0500 To: Sam Fans Subject: good move Chris In-Reply-To: <92Nov18.204207est.2795@hawkwind.utcs.toronto.edu> Message-ID: <199211191312.1153.sam.babaf@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Thanks for creating this list. One day perhaps I will have time to do something with the new sam. If anyone _does_ do scrolling menus please let me know, else I will have to do it myself, in my copious spare time. Should an article advertising the existence of this list be posted to comp.editors? Now, finally, I have an audience to ask a question that has been bothering me for YEARS. Historical background: I first used sam on a Jerq in 1989, hosted by a VAX-11/780 running Eighth Edition. That version of sam (the `Pike original') didn't have what I call `tagged REs'; you could use parentheses as you liked as grouping operators in REs, but that was _all_ they did. You could not use \ on the right hand side of an s command to represent `what the n'th paren part matched.' I have always wanted to believe that Pike designed the command language of sam (composition of structural REs) with great precision, and I was disturbed to find, in the V8 days, that there appeared to be absolutely no way to accomplish the standard two-column interchange of ed: suppose you have a file with two words per line separated by one space, and you want to exchange them on each line, you [[NOTE, this is an _ed_ command]] 1,$s/\(.*\) \(.*\)/\2 \1/ I found that literally _impossible_ in the Pike original sam. I tried hard, but always ended up with the dread "changes out of sequence". The further history of this is that my friend and colleague Noel Hunt (you on this list, Noel? If not, you should be!) decided that he was going to add tagged REs to sam, and he did it. That code got sent back to Pike, and it appears now in the version of sam that they've distributed. I have always wondered (but never been brave enough to bother Pike) what the full story is. Challenge: can anyone find a sam command to accomplish the exchange _without_ using \ on the right side of an s command? (Note: please don't mail me any _theories_ about this; I worked at it for some days, and have already tried whatever you have theorised. I'm only interested if you have tested it in sam and it worked.) OK, John. From sam-fans-owner Thu Nov 19 01:15:55 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2795>; Thu, 19 Nov 1992 01:14:28 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA17029; Wed, 18 Nov 92 22:10:49 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA05538; Wed, 18 Nov 92 22:12:44 PST Date: Thu, 19 Nov 1992 01:12:44 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211190612.AA05538@netapp.netapp.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: interchange of two words I know this sounds cheeky, but there was *always* a way to get your favorite ed command to work on a particular sam line: ,x g/pattern/ | sed command But as far as I know there was no way to do it with the old command language. (Actually, I didn't even realize tagged RE's were part of sam now. Great. In general, I'm glad there's only one RE syntax on plan9. Clearly the way to go.) From sam-fans-owner Thu Nov 19 09:53:08 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu with SMTP id <2795>; Thu, 19 Nov 1992 09:52:59 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA03299; Thu, 19 Nov 92 09:52:47 -0500 Received: by earth.osf.org (5.65/4.7) id AA05642; Thu, 19 Nov 92 09:52:45 -0500 Date: Thu, 19 Nov 1992 09:52:45 -0500 From: rsalz@osf.org Message-Id: <9211191452.AA05642@earth.osf.org> To: sam-fans@hawkwind.utcs.toronto.edu Subject: coding error in gwin.c? *(Atom*) *ans = XA_STRING; Isn't that wrong? Shouldn't it be { Atom *t = (Atom*)*ans; *t = XA_STRING; } From sam-fans-owner Thu Nov 19 10:32:08 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu with SMTP id <2795>; Thu, 19 Nov 1992 10:31:55 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA04927; Thu, 19 Nov 92 10:31:41 -0500 Received: by earth.osf.org (5.65/4.7) id AA05933; Thu, 19 Nov 92 10:31:40 -0500 Date: Thu, 19 Nov 1992 10:31:40 -0500 From: rsalz@osf.org Message-Id: <9211191531.AA05933@earth.osf.org> To: john@civil.su.oz.au Subject: Re: Byron's comments Cc: sam-fans@hawkwind.utcs.toronto.edu Modifying sam to use, for example, ctags, might be more of a challenge. Well, Samuel sounds real cool, but... The following script has reasonable speed. If it ends a tags file entry it outputs the set of commands that would make sam open that file and (more or less) move to the right place. I say more or less because I just turn Sam's re metachars into dots. Here's how to use it. In the command window type "!samtag Cmd", for example. Then select the two lines that it outputs: !samtag Cmd B ../sam/parse.h /^typedef struct Cmd Cmd;$/ then click "send" on the middle menu. If you have xcb (get it get it get it) then you can jump from text, too. Double-click on a function, then on the middle menu click "snarf" then "exch". Then click to the ~~sam~~ window and type "!samtag" and use as before. #! /bin/rc ## Output a series of commands that will make same go to the tag named on ## the command line. If no argument, use the word in the current X ## selection. The best way to get the selection is to install xcb; available ## as contrib/xcb-2.1.tar.Z on export.lcs.mit.edu. ## Useful variables ~ $#tagspath 0 && tagspath = (. .. /usr/lib/tags) nl = ' ' tab=' ' ## Get the current X selection. I strongly recommend xcb; if ( ~ $#* 0 ) { function = `{xcb -p 0} } else { function = $1 } function = $function ^ ' ' for (i in $tagspath) test -f $i ^ /tags && { line = `` ($nl) { look $function $i ^ /tags ; echo $status } ~ $#line 2 && ~ $line(2) 0 && { * = `` ($tab $nl) { echo $line(1) } if ( ~ $i . || ~ $2 /* ) { dir = '' } else { dir = $i ^ '/' } echo B $dir ^ $2 shift ; shift # Gross hack... echo $* | tr '()*' '...' exit 0 } } exit 1 From sam-fans-owner Thu Nov 19 14:56:46 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2798>; Thu, 19 Nov 1992 14:56:26 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA08291; Thu, 19 Nov 1992 13:56:14 -0600 Message-Id: <9211191956.AA08291@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Pipe problem? Date: Thu, 19 Nov 1992 14:56:13 -0500 From: Alan Watson X-Mts: smtp Before I investigate further, has anyone come across this sort of a problem with the pipe (|) command: ; sam -d a Hello world! . ,p Hello world! |/bin/cat ?warning: exit status not 0 ! ,p Hello world! |wc ?warning: exit status not 0 ! ,p 1 2 13 q ?changed files q ; I checked "waitfor", and the child processes really are exiting with non-zero status! I'm on a Decstation running Ultrix 4.3, and I compiled sam with gcc in POSIX mode. Alan. From sam-fans-owner Thu Nov 19 17:22:26 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2798>; Thu, 19 Nov 1992 17:22:09 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2601>; Thu, 19 Nov 1992 17:21:26 -0500 To: Chris Siebenmann cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: My patches In-reply-to: Your message of "Wed, 18 Nov 92 20:42:01 EST." <92Nov18.204207est.2795@hawkwind.utcs.toronto.edu> Date: Thu, 19 Nov 1992 17:21:05 -0500 From: Scott Schwartz Message-Id: <92Nov19.172126est.2601@groucho.cs.psu.edu> | Here are my patches (and my readme for them). All diffs are relative | to the current source on research.att.com. | libXg: | - sweeping out a rectangle will now grab the pointer from the | X server; this means that you can swipe from outside the sam | window, making sure your windows line up neatly with the | boundary of the sam window. Something in there makes my server unhappy: (MIT R5, twm) ; ./sam -t ./samterm (type B ../sam/sam.c) X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 26 (X_GrabPointer) Value in failed request: 0xa00d Serial number of failed request: 338 Current serial number in output stream: 338 | - menus no longer force the mouse to center on them; the pointer | stays where it was when you selected the menu. That looks kind of ugly, IMHO. From sam-fans-owner Thu Nov 19 17:33:46 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2798>; Thu, 19 Nov 1992 17:33:40 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2601>; Thu, 19 Nov 1992 17:32:43 -0500 To: rsalz@osf.org cc: john@civil.su.oz.au, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Byron's comments In-reply-to: Your message of "Thu, 19 Nov 92 10:31:40 EST." <9211191531.AA05933@earth.osf.org> Date: Thu, 19 Nov 1992 17:32:17 -0500 From: Scott Schwartz Message-Id: <92Nov19.173243est.2601@groucho.cs.psu.edu> | Here's how to use it. In the command window type "!samtag Cmd", for | example. Then select the two lines that it outputs: | !samtag Cmd | B ../sam/parse.h | /^typedef struct Cmd Cmd;$/ | then click "send" on the middle menu. Hrm. I'd rather type something like ``@samtag Cmd'', and have sam execute the output of Cmd. Now that @ is no longer magical, it could be used for that. From sam-fans-owner Thu Nov 19 19:38:45 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2798>; Thu, 19 Nov 1992 19:38:34 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA17223; Thu, 19 Nov 1992 18:38:24 -0600 Message-Id: <9211200038.AA17223@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Pipe problem? Date: Thu, 19 Nov 1992 19:38:23 -0500 From: Alan Watson X-Mts: smtp There appears to be at least two things going on here. There is a simple bug in sam, which causes the "producer" process which feeds dot into the "consumer" process created by the pipe command, to exit with the wrong status. The diffs to correct this bug are below. However, waitfor should filter out this non-zero status, as it does not come from the "consumer" process; apparently it does behave correctly under SunOS, but not under Ultrix 4.2 or 4.3. I can neither fault waitfor's logic nor reproduce this behaviour with a simple program. I'm giving up for now, but if anyone can figure this one out I'd very much like to hear an explanation. Alan. *** shell.c Thu Nov 19 18:22:18 1992 --- ../Orig/sam/shell.c Thu Nov 19 18:19:55 1992 *************** *** 79,85 **** free(c); } } ! exits(retcode? 0 : "error"); } if(pid==-1){ fprint(2, "Can't fork?!\n"); --- 79,85 ---- free(c); } } ! exits(retcode? "error" : 0); } if(pid==-1){ fprint(2, "Can't fork?!\n"); From sam-fans-owner Mon Nov 23 14:53:03 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with SMTP id <2802>; Mon, 23 Nov 1992 14:52:48 -0500 Received: from sco.sco.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11709; Mon, 23 Nov 92 14:52:37 -0500 Received: from scocan.scocan.sco.COM by sco.sco.COM id aa26059; Mon, 23 Nov 92 11:53:22 PST Received: from imp.scocan.sco.COM by scocan.scocan.sco.COM id aa21055; 23 Nov 92 14:49 EST To: sam-fans@hawkwind.utcs.toronto.edu Subject: samterm for MGR? Date: Mon, 23 Nov 1992 14:49:06 -0500 From: Bob Gibson Message-Id: <9211231449.aa01769@imp.scocan.sco.COM> Does anybody know of an implementation of samterm for the MGR window manager? - rjg -- Bob Gibson Internet: rjg@sco.com SCO Canada Inc. UUCP: ...!uunet!sco!rjg From sam-fans-owner Mon Nov 23 16:52:13 1992 Received: from gatech.edu ([128.61.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2802>; Mon, 23 Nov 1992 16:52:06 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA19320 for sam-fans@hawkwind.utcs.toronto.edu; Mon, 23 Nov 92 16:51:45 EST Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA25672; for sam-fans@hawkwind.utcs.toronto.edu; Mon, 23 Nov 92 16:51:42 EST Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA04194; Mon, 23 Nov 92 16:51:16 EST From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9211232151.AA04194@penfold.cc.gatech.edu> Date: Mon, 23 Nov 1992 16:51:15 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: sam-fans@hawkwind.utcs.toronto.edu Subject: saved replacement texts? System V versions of ed have a saved replacement text, so that one can do the following: /foo/s//bar/ //s//%/ or in vi: ://s Where the `%' means the last replacement text I used. Vi uses the `~' for this purpose. Is there anything analogous in sam for either the c or s commands? Is there a reason (other than minimalism for the sake of minimalism) that there shouldn't be such a thing? Am I missing something obvious, or even something subtle that's not apparent from the command language tutorial? Thanks, Arnold From sam-fans-owner Mon Nov 23 16:57:10 1992 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu with SMTP id <2802>; Mon, 23 Nov 1992 16:56:58 -0500 Received: by quux.es.su.oz.au id <14648>; Tue, 24 Nov 1992 08:56:31 +1100 From: noel@es.su.oz.au Date: Mon, 23 Nov 1992 16:53:48 -0500 to: arnold@cc.gatech.edu (Arnold Robbins), sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? In-Reply-To: <9211232151.AA04194@penfold.cc.gatech.edu> Message-ID: <199211232153.24350.out.babuv@es.su.oz.au> From: arnold@cc.gatech.edu (Arnold Robbins) Subject: saved replacement texts? System V versions of ed have a saved replacement text, so that one can do the following: /foo/s//bar/ //s//%/ or in vi: ://s Where the `%' means the last replacement text I used. Vi uses the `~' for this purpose. Is there anything analogous in sam for either the c or s commands? Is there a reason (other than minimalism for the sake of minimalism) that there shouldn't be such a thing? Am I missing something obvious, or even something subtle that's not apparent from the command language tutorial? Thanks, Arnold use the mouse; in the case above, select and send in the command window. is this difficult? From sam-fans-owner Mon Nov 23 18:32:38 1992 Received: from gatech.edu ([128.61.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2805>; Mon, 23 Nov 1992 18:32:24 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA21594 for sam-fans@hawkwind.utcs.toronto.edu; Mon, 23 Nov 92 18:32:15 EST Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA28921; for sam-fans@hawkwind.utcs.toronto.edu; Mon, 23 Nov 92 18:32:13 EST Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA06316; Mon, 23 Nov 92 18:31:50 EST From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9211232331.AA06316@penfold.cc.gatech.edu> Date: Mon, 23 Nov 1992 18:31:50 -0500 In-Reply-To: noel@es.su.oz.au's 38-line message on Nov 24, 8:53am X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? > [ Are there saved replacement texts? -- me ] > > use the mouse; in the case above, select and send in the command window. > is this difficult? No, I was just wondering, and hoping to avoid the extra mousing/typing. Arnold From sam-fans-owner Mon Nov 23 18:45:01 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 18:44:48 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA26125; Mon, 23 Nov 92 15:40:28 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA24462; Mon, 23 Nov 92 14:03:01 PST Date: Mon, 23 Nov 1992 17:03:01 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211232203.AA24462@netapp.netapp.com> To: arnold@cc.gatech.edu, noel@es.su.oz.au, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? Actually, this is a gripe of mine also. Forcing the user to use the mouse is poor design, IMO. e.g., I think that 99% of the time the overlapping windows in sam are useless. Hence I think it's particularly pointless that I have to open a file by typing "B file" and then using the mouse to "sweep" out the new area, when all I'm going to do is click on the 3rd mouse button. Why isn't that action the default? From sam-fans-owner Mon Nov 23 19:17:45 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 19:17:32 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2601>; Mon, 23 Nov 1992 19:16:42 -0500 To: byron@netapp.com (Byron Rakitzis) cc: arnold@cc.gatech.edu, noel@es.su.oz.au, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? In-reply-to: Your message of "Mon, 23 Nov 92 17:03:01 EST." <9211232203.AA24462@netapp.netapp.com> Date: Mon, 23 Nov 1992 19:16:20 -0500 From: Scott Schwartz Message-Id: <92Nov23.191642est.2601@groucho.cs.psu.edu> | IMO. e.g., I think that 99% of the time the overlapping windows in | sam are useless. One thing that bothers me is that only the top window has focus, so letting them peek out from under is unhelpful. I wind up tiling them, or just switching back and forth with button-3. Multiple toplevel X windows, are probably a better idea for something like sam. Mxedit does that, and it works pretty well. Epoch doesn't do so well, mostly because people do heavyweight blocking operations (like reading news!) in one window which block the others; in emacs, since the windows are in the same frame, it's more obvious that there is one thread of control for the lot of them. It's also annoying that moving a window is implemented by resizing, which makes it hard to just move it without resizing. From sam-fans-owner Mon Nov 23 21:04:23 1992 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 21:04:09 -0500 Received: by quux.es.su.oz.au id <14648>; Tue, 24 Nov 1992 13:03:30 +1100 From: noel@es.su.oz.au Date: Mon, 23 Nov 1992 21:02:03 -0500 to: byron@netapp.com (Byron Rakitzis), arnold@cc.gatech.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? In-Reply-To: <9211232203.AA24462@netapp.netapp.com> Message-ID: <199211240202.25949.out.badag@es.su.oz.au> From: byron@netapp.com (Byron Rakitzis) Subject: Re: saved replacement texts? pointless that I have to open a file by typing "B file" and then using the mouse to "sweep" out the new area, when all I'm going to do is click on the 3rd mouse button. Why isn't that action the default? if that were the default, how would you specify that you _really_ want to sweep a window? From sam-fans-owner Mon Nov 23 21:11:55 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 21:11:44 -0500 To: sam-fans Subject: Re: saved replacement texts? In-reply-to: noel's message of Mon, 23 Nov 92 21:02:03 -0500. <199211240202.25949.out.badag@es.su.oz.au> Date: Mon, 23 Nov 1992 21:11:38 -0500 From: Chris Siebenmann Message-Id: <92Nov23.211144est.2806@hawkwind.utcs.toronto.edu> Automatic placement of new windows probably isn't the default because Pike didn't have a good way to do it, especially in sam (it's also somewhat against the model). I don't really see how to fix that. - cks From sam-fans-owner Mon Nov 23 21:40:18 1992 Received: from munnari.oz.au ([128.250.1.21]) by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 21:40:13 -0500 Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA19865; Tue, 24 Nov 1992 13:39:39 +1100 (from jeremy@sw.oz.au) Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP id AA01462; Tue, 24 Nov 92 13:41:24 AES (5.59) (from jeremy@sw.oz.au for cks%hawkwind.utcs.toronto.edu@munnari.oz.au) Received: by chao.sw.oz.au (4.1/SMI-4.1) id AA21759; Tue, 24 Nov 92 13:41:18 EST From: jeremy@sw.oz.au (Jeremy Fitzhardinge) Message-Id: <9211240241.AA21759@chao.sw.oz.au> Subject: Re: saved replacement texts? To: cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) Date: Mon, 23 Nov 1992 21:41:17 -0500 Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <92Nov23.211144est.2806@hawkwind.utcs.toronto.edu> from "Chris Siebenmann" at Nov 23, 92 09:11:38 pm Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE Automatic placement of new windows probably isn't the default because > Pike didn't have a good way to do it, especially in sam (it's also > somewhat against the model). I don't really see how to fix that. An interesting paper to read by Pike is the one on his "Help" system. He takes quite a different approach based on "sensible defaults" and "minimal actions". This means that there is no click to type, because the click used to type has no purpose, other than as a click. Likewise, there are no menus, because pulling up a menu is a waste of a click. Clicking on a word selects the word, rather than having to drag, since selecting words is the default action to match the most common operation. Selecting words is also the way you perform operations. If you want to open a file, you select the word "open" anywhere it appears, and do something to act upon it (can't quite remember). Therefore, if you want a menu, you open up a text buffer, and type the menu you want. Text buffers can be linked to underlying programs, talking through a special file heirachy (plan 9, of course). "Underlying programs" means normal tool-type programs, with rc scripts doing any glueing needed. "Sensible defaults" also means automatic placement of windows. While it's very much a prototype with heavy experimentation, it looks very usable. There was talk of it being distributed with the academic Plan 9 release. Is this so (Matty?)? J From sam-fans-owner Mon Nov 23 21:43:11 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2807>; Mon, 23 Nov 1992 21:42:55 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2625>; Mon, 23 Nov 1992 21:42:08 -0500 To: Chris Siebenmann cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? In-reply-to: Your message of "Mon, 23 Nov 92 21:11:38 EST." <92Nov23.211144est.2806@hawkwind.utcs.toronto.edu> Date: Mon, 23 Nov 1992 21:41:55 -0500 From: Scott Schwartz Message-Id: <92Nov23.214208est.2625@groucho.cs.psu.edu> | Automatic placement of new windows probably isn't the default because | Pike didn't have a good way to do it, especially in sam (it's also | somewhat against the model). I don't really see how to fix that. Just for the sake of argument, he could have done what rms did with emacs, namely replace the current window with the new one. (Maybe I'm just hopelessly tainted, but I think a number of emacs' features are reasonable. :-) In another instance, if you arrange to get a new toplevel window then placement is a window manager function, rather than an application function. (Insert Rob's complaints about X window managers here. :-) By the way, maybe we should have a plan-9-wanna-be BOF at usenix? From sam-fans-owner Mon Nov 23 21:47:20 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 21:47:14 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2625>; Mon, 23 Nov 1992 21:46:24 -0500 To: jeremy@sw.oz.au (Jeremy Fitzhardinge) cc: cks@hawkwind.utcs.toronto.edu (Chris Siebenmann), sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? In-reply-to: Your message of "Mon, 23 Nov 92 21:41:17 EST." <9211240241.AA21759@chao.sw.oz.au> Date: Mon, 23 Nov 1992 21:46:09 -0500 From: Scott Schwartz Message-Id: <92Nov23.214624est.2625@groucho.cs.psu.edu> | An interesting paper to read by Pike is the one on his "Help" system. | He takes quite a different approach based on "sensible defaults" and | "minimal actions". A similar system (which Pike cites in that paper) is Wirth's Oberon system. You can ftp it from neptune.inf.ethz.ch. It's pretty neat, well worth playing with for a while, but you need a sparc to run it on. From sam-fans-owner Mon Nov 23 21:51:31 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 21:51:18 -0500 Received: by mod.civil.su.oz.au id <28680>; Tue, 24 Nov 1992 13:50:50 +1100 From: John (For the colours are many, but the light is one.) Mackin Date: Mon, 23 Nov 1992 21:47:06 -0500 To: The sam Mailing List Subject: Re: saved replacement texts? In-Reply-To: <92Nov23.214208est.2625@groucho.cs.psu.edu> Message-ID: <199211241347.8224.sam.babaz@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Just for the sake of argument, he could have done what rms did with emacs, namely replace the current window with the new one. (Maybe I'm just hopelessly tainted, but I think a number of emacs' features are reasonable. :-) Scott, This suggestion, I am afraid, is just plain stupid, emacs or no. You don't want the command window replaced with the window you just said B about. Pike did an excellent job designing the sam interface. The single click to place the usual edit window is just what you want. Sometimes, you want to put the command window in the middle of the top-level window, and have edit windows above and below. If you want them to overlap, you can, although as has been observed here before, tiling is usually more useful. It's not broken and doesn't need any fixing. OK, John. From sam-fans-owner Mon Nov 23 22:11:23 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 22:11:09 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2625>; Mon, 23 Nov 1992 22:10:21 -0500 To: John Mackin (For the colours are many, but the light is one.) cc: The sam Mailing List Subject: Re: saved replacement texts? In-reply-to: Your message of "Mon, 23 Nov 92 21:47:06 EST." <199211241347.8224.sam.babaz@civil.su.oz.au> Date: Mon, 23 Nov 1992 22:10:13 -0500 From: Scott Schwartz Message-Id: <92Nov23.221021est.2625@groucho.cs.psu.edu> | This suggestion, I am afraid, is just plain stupid, emacs or no. | | You don't want the command window replaced with the window you just | said B about. Oh come now: Emacs doesn't let you replace the minibuffer either. If there is no file window open, then you would get a fresh one, just as if you had clicked button-3. Otherwise, the previously selected file window would be covered with a new one. | It's not broken and doesn't need any fixing. I wasn't suggesting that anyone start hacking on it, only pointing out that there are alternatives to the current style interface. (p.s. I typed this with vi, so there. :-) From sam-fans-owner Mon Nov 23 22:21:29 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2806>; Mon, 23 Nov 1992 22:21:14 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA14210; Mon, 23 Nov 92 19:16:59 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA04748; Mon, 23 Nov 92 19:05:26 PST Date: Mon, 23 Nov 1992 22:05:26 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211240305.AA04748@netapp.netapp.com> To: arnold@cc.gatech.edu, noel@es.su.oz.au, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? >if that were the default, how would you specify that you _really_ >want to sweep a window? by reshaping it, of course. From sam-fans-owner Mon Nov 23 22:21:46 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2808>; Mon, 23 Nov 1992 22:21:34 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA14220; Mon, 23 Nov 92 19:17:02 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA07803; Mon, 23 Nov 92 19:19:58 PST Date: Mon, 23 Nov 1992 22:19:58 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211240319.AA07803@netapp.netapp.com> To: john@civil.su.oz.au, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? >This suggestion, I am afraid, is just plain stupid, emacs or no. Oh, come off your high-horse. Emacs has a command-line which is separate from the current window. Obviously Scott was not talking about replacing the command window with the new file. >Pike did an excellent job designing the sam interface. I agree. But I don't think he achieved perfection, nor do I think that suggestions for improvement are inappropriate. >The single click to place the usual edit window is just what you want. I'm sorry, maybe it's what you want, but it's not what I want. >Sometimes, you want to put the command window in the middle of the top-level >window, and have edit windows above and below. Yes, about 1% of the time. Does it make sense to have the user interface revolve around this remote possibility? >It's not broken and doesn't need any fixing. Obviously a matter of opinion. I would prefer either of two options: 1) automatic placement 2) non-placement, i.e., leaving the files in the menu with a minus-sign. (this makes opening the file into a two-click operation, assuming that sam points the "lasthit" of the menu at the newly opened file) In both cases, it means that I don't have to automatically reach for the mouse after typing B. (though I prefer solution #1) For example, I often want to make a quick change to a file with commands of the form B file cmd D at *least* as often as I want to tile or otherwise futz with the sam layers. From sam-fans-owner Mon Nov 23 23:24:57 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2807>; Mon, 23 Nov 1992 23:24:40 -0500 Received: by mod.civil.su.oz.au id <28680>; Tue, 24 Nov 1992 15:24:18 +1100 From: John (For the colours are many, but the light is one.) Mackin Date: Mon, 23 Nov 1992 23:02:50 -0500 To: The sam Mailing List Subject: Re: saved replacement texts? In-Reply-To: <9211240319.AA07803@netapp.netapp.com> Message-ID: <199211241502.8417.sam.babek@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Oh, come off your high-horse. Emacs has a command-line which is separate from the current window. Obviously Scott was not talking about replacing the command window with the new file. Well, hell. How about cutting me some slack, Byron? I can only go by what the words in the mail actually say. If I were being deliberately obtuse, you'd have a case. I wasn't. _I_ don't know how emacs's user interface works -- I've never had to use the damned thing. I thought this was the sam list, not the emacs list. What may be `obvious' to someone who's used the software is by no means obvious to someone who hasn't. I agree. But I don't think he achieved perfection, nor do I think that suggestions for improvement are inappropriate. What I think would be appropriate would be for people who've just started using the editor since it's been available free to accumulate four years worth of experience with it before leaping to suggest how it should be improved. It would also be as well to remember that sam's interface was designed to integrate nicely with its surrounding window system environment, viz. mux on the Jerq. Since ordinary X environments are nothing like that, and since X literally _cannot_ be made to be _precisely_ like that (I tried very hard), sam tends not be that well-integrated with the usual X environment. Of course, it's the X environment that's wrong here (grin). OK, John. From sam-fans-owner Tue Nov 24 00:23:37 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2808>; Tue, 24 Nov 1992 00:23:10 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA23085; Mon, 23 Nov 92 21:18:52 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA02410; Mon, 23 Nov 92 21:18:33 PST Date: Tue, 24 Nov 1992 00:18:33 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211240518.AA02410@netapp.netapp.com> To: john@civil.su.oz.au, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: saved replacement texts? >How about cutting me some slack, Byron? I got hot because you called Scott's idea "stupid". If you are going to call something stupid, you should probably know what you're doing first. On this side of the Pacific, those are strong words. >What I think would be appropriate would be for people who've just started >using the editor since it's been available free to accumulate four years >worth of experience with it before leaping to suggest how it should be >improved. I've used sam here and there for about that long. I have a pretty good idea of how it works, and I also have a pretty good idea of what I want. >It would also be as well to remember that sam's interface was designed >to integrate nicely with its surrounding window system environment, viz. >mux on the Jerq. I am baffled by one point regarding sam: why is it that it must implement its own mini-window system internally? I agree that it "integrates" well with mux: by imitating it! Unfortunately this means that sam is a misfit in just about any other environment. (For comparision, check out the NeXT editor. It is a multi-file editor (no command language to speak of though) that opens a separate window for each file.) From sam-fans-owner Thu Nov 26 20:34:47 1992 Received: from munnari.oz.au ([128.250.1.21]) by hawkwind.utcs.toronto.edu with SMTP id <2825>; Thu, 26 Nov 1992 20:34:22 -0500 Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA15067; Fri, 27 Nov 1992 12:34:10 +1100 (from jeremy@sw.oz.au) Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP id AA03608; Fri, 27 Nov 92 12:36:09 AES (5.59) (from jeremy@sw.oz.au for sam-fans%hawkwind.utcs.toronto.edu@munnari.oz.au) Received: by chao.sw.oz.au (4.1/SMI-4.1) id AA21018; Fri, 27 Nov 92 12:36:06 EST From: jeremy@sw.oz.au (Jeremy Fitzhardinge) Message-Id: <9211270136.AA21018@chao.sw.oz.au> Subject: Pie menus To: sam-fans@hawkwind.utcs.toronto.edu (Sam Fans) Date: Thu, 26 Nov 1992 20:36:05 -0500 Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE; Thu, 26 Nov 1992 21:27:57 -0500 Received: from sisters.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP id AA09433 (5.65/IDA-1.4.2 for sam-fans@hawkwind.utcs.toronto.edu); Thu, 26 Nov 92 18:27:46 -0800 Received: by sisters.cs.uoregon.edu (5.61/UofO CS 27-Mar-91) id AA02830; Thu, 26 Nov 92 18:25:24 -0800 Date: Thu, 26 Nov 1992 21:25:24 -0500 From: mike@sisters.cs.uoregon.edu Message-Id: <9211270225.AA02830@sisters.cs.uoregon.edu> To: jeremy@sw.oz.au Subject: Re: Pie menus Cc: sam-fans@hawkwind.utcs.toronto.edu > [ Pie menus ] >much more easily than moving down a linear menu. Also, it's much faster, >since the mouse pointer starts in the right place for all the menu items, >rather than having the "last chosen" hack currently used. Note that "last chosen" is not quite the hack you think it is. It has a very desirable user-interface property. On the average, you end up moving the mouse up about half the time, and down half the time. This keeps the mouse on your desk. By contrast, using J. Random X utility, you continually drift off the bottom, and have to lift the mouse up and recenter it on your desk. Repeatedly selecting the same item in a pie menu (imagine a "page forward" command in ghostview, for example) would still exhibit this drifting property. So you'd still want some sort of "last chosen" default. >How hard would it be to add a new menu type to sam/libXg? Try it and see... From sam-fans-owner Thu Nov 26 22:02:54 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2825>; Thu, 26 Nov 1992 22:02:48 -0500 Received: by mod.civil.su.oz.au id <28680>; Fri, 27 Nov 1992 14:02:25 +1100 From: John (For the colours are many, but the light is one.) Mackin Date: Thu, 26 Nov 1992 21:58:00 -0500 To: The sam Mailing List Subject: Re: Pie menus In-Reply-To: <9211270225.AA02830@sisters.cs.uoregon.edu> Message-ID: <199211271358.21155.sam.babes@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Mike is dead right. "Last chosen" is abolutely not a `hack.' I'd be pleased if Mr Fitzhardinge was a little more careful with his epithet-slinging. Not only does it keep the mouse in the same place on the table, but it also happens to contribute greatly to the editor's usability, since a single click on B2 repeats the last B2 action, which is often just what you want for searching and pasting. >How hard would it be to add a new menu type to sam/libXg? Try it and see... Hear, hear! You want it? You do it. OK, John. From sam-fans-owner Mon Nov 30 22:09:13 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2840>; Mon, 30 Nov 1992 22:08:16 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA14736; Mon, 30 Nov 1992 18:40:45 -0600 Message-Id: <9212010040.AA14736@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Lines and last lines. Date: Mon, 30 Nov 1992 19:40:45 -0500 From: Alan Watson X-Mts: smtp I'm struggling with sam's supposed break from the line-oriented nature of most Unix utilities. Relevant parts of the man page are [1] \n Match newline. ^ Match the null string immediately after a newline. $ Match the null string immediately before a newline. and later [2] (The peculiar properties of a last line without a newline are tem- porarily undefined.) and later still [3] x/regexp/ command For each match of the regular expression in the range, run the com- mand with dot set to the match. Set dot to the last match. If the regular expression and its slashes are omitted, /.*\n/ is assumed. Null string matches potentially occur before every character of the range and at the end of the range. My first comment is that [2] is somewhat against sam's philosophy that files are arbitrary byte streams; it does impose a structure on the file (i.e., that the final character must be \n). Secondly, let's investigate the interactions of [2] and [3]: ; sam -d a/abcd\n/ a/efgh\n/ a/ijkl/ ,p abcd efgh ijkl <- cursor here ,x/.*\n/p abcd efgh <- cursor here ,x p abcd efgh ijkl <- cursor here These last two might be expected to give the same output, given the stated default for x. Finally, lets investigate the interaction of [1] and [2]: ,x /^.*/p efghijklabcd <- cursor here ,x /.*$/p efghabcdabcd <- cursor here Okay, my point is that it might have been better to define different semantics for ^ and $, namely that they match the start of a line (i.e., the null string at the start of the file and the null string after a \n not at the end of the file) and the end of a line (i.e., the null string before a \n not at the end of the file and the null string at the end of the file). The default for x might then have been /^.*$/, and this might have helped to define the semantics of a final line without a newline. From sam-fans-owner Tue Dec 1 00:10:28 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2841>; Tue, 1 Dec 1992 00:09:55 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA02434; Mon, 30 Nov 92 21:05:31 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA15071; Mon, 30 Nov 92 21:08:21 PST Date: Tue, 1 Dec 1992 00:08:21 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212010508.AA15071@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Lines and last lines. >My first comment is that [2] is somewhat against sam's philosophy that >files are arbitrary byte streams; it does impose a structure on the >file (i.e., that the final character must be \n). Unfortunately, sam's philosophy is most emphatically not that files are arbitrary byte streams. e.g.: ; sam -d B /bin/ls -. /bin/ls ?warning: null characters elided and this is an improvement(!) on the previous situation (pre-unicode?), which was that any "non-ascii" characters got elided. I'm not sure if that meant nul+any-characters-with-the-8th-bit-set or what. Anyway, in case you haven't noticed, I think this is one of sam's more serious design flaws. It's one of the few reasons why I still want emacs available on the Unix machines I use. (other reasons: gdb support and glass tty support, i.e., the Poor Man's Window System.) From sam-fans-owner Tue Dec 1 00:47:07 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2843>; Tue, 1 Dec 1992 00:46:59 -0500 To: sam-fans Subject: Re: Lines and last lines. In-reply-to: alan's message of Mon, 30 Nov 92 19:40:45 -0500. <9212010040.AA14736@oldp.astro.wisc.edu> Date: Tue, 1 Dec 1992 00:46:48 -0500 From: Chris Siebenmann Message-Id: <92Dec1.004659est.2843@hawkwind.utcs.toronto.edu> sam is happy with lines that don't end in newlines; it warns when you write them out, but otherwise leaves them alone. The 'peculiar properties' are probably that '$' does not match the end of a line not terminated in one. The manual page is not quite correct as to x/y's default selection; there is an explicit routine that loops over all lines, using the usual uncommented code. - cks From sam-fans-owner Tue Dec 1 02:02:14 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2847>; Tue, 1 Dec 1992 02:02:07 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA19067; Tue, 1 Dec 1992 01:01:57 -0600 Message-Id: <9212010701.AA19067@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Lines and last lines. Date: Tue, 1 Dec 1992 02:01:57 -0500 From: Alan Watson X-Mts: smtp Messing around with this, I think I've found a bug: ; sam -d a/abcd\nefgh\nijkl/ ,x /.*$/p efghabcdabcd,x/.*$/p abcdefgh The only thing different between the two x commands is the space between the x and the RE. I would very much appreciate it if someone more familiar with the code than myself take it upon themselves to investigate this. Alan. From sam-fans-owner Tue Dec 1 02:11:50 1992 Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by hawkwind.utcs.toronto.edu with SMTP id <2849>; Tue, 1 Dec 1992 02:11:31 -0500 Received: from pacifix.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP id AA02751 (5.65/IDA-1.4.2 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 30 Nov 92 23:11:07 -0800 Date: Tue, 1 Dec 1992 02:11:07 -0500 From: Michael John Haertel Message-Id: <9212010711.AA02751@skinner.cs.uoregon.edu> To: alan@oldp.astro.wisc.edu Subject: Re: Lines and last lines. Cc: sam-fans@hawkwind.utcs.toronto.edu "x " followed by a space means "for all lines"; it is not a bug, it is a documented (see sam.tut.ms) feature. From sam-fans-owner Tue Dec 1 02:59:03 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2856>; Tue, 1 Dec 1992 02:58:49 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA13740; Mon, 30 Nov 92 23:54:40 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA18624; Mon, 30 Nov 92 23:57:19 PST Date: Tue, 1 Dec 1992 02:57:19 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212010757.AA18624@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Lines and last lines. This is a feature, not a bug: x is the same thing as x/.*\n/ (modulo the RE weirdness that's being argued right now which I don't want to get tied up with --- i.e., in short, x splits the current selection into lines. This *is* documented in the tutorial if not in the man page as well.) BTW, it is a *very* handy shortcut for emulating ed commands: ,x g/foo/d is the same as ed's g/foo/d PS I just checked the man page and it says that "If the regular expression and its slashes are omitted, /.*\n/ is assumed." but of course this is not the whole story since sam barfs on ,xg/foo/d (Another mini-gripe I have with sam: the lexical analyzer, such as it is, sure is weird. What's the point of having delimiters between one- letter commands like x and g anyway? Isn't that almost the point of one-letter commands? I guess, he says sarcastically, the delimiters are there to disambiguate "c d" and "cd" (the only multicharacter command in sam that I know of).) (BTW, to the religious: my negative comments about sam are meant as constructive criticism. I don't think Rob Pike is God, and I don't think he achived perfection with sam. He did come fairly close though, didn't he?) From sam-fans-owner Tue Dec 1 14:28:29 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2843>; Tue, 1 Dec 1992 14:28:12 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA21580; Tue, 1 Dec 1992 13:28:00 -0600 Message-Id: <9212011928.AA21580@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Lines and last lines. Date: Tue, 1 Dec 1992 14:27:59 -0500 From: Alan Watson X-Mts: smtp Several points. Yes, I should have said that the undefined semantics of a final line without a newline went somewhat against sam's philosophy that files are arbitrary streams of TEXT. The default for x is more subtle that I at first supposed, and is useful not just when the final line of the FILE is not terminated by a newline, but also when the final line of the RANGE is a partial line. As to the behaviour of "x /RE/", clearly I misread the somewhat contradictory documentation. The sam paper states on page 6 that "blanks in these examples are to improve readability; sam neither requires nor interprets them." The sam tutorial states on page 11 "if x is followed immediately by a space, the pattern .*\n is assumed." The man page states on page 5 that "if the regular expression and its slashes are omitted /*.\n/ is assumed." Is putting a space between the x and the RE really an omission of the RE? Apparently it is. I don't like white-space to have sematic content (other than to serve as a separator and terminator). While I like the default for x ... I think I might have prefered x /RE/... to be equivalent to x/RE/... but I guess one might argue that the difference is needed to disambiguate x/RE/ ... and x /RE/... although the latter could have been written without ambiguity as x { /RE/... } Can anyone think of a situation where one might want to use "x /RE/..."? Many a time I too have blessed emacs for allowing me to edit binary files. Howevere, all is not lost with sam, due to it's superbly flexible shell escapes. All one needs a filter which takes a binary file and writes out octal, and vice verse; one then uses ",<" and ",>" to read an write binary, whilst editing the octal representation. Alan. From sam-fans-owner Tue Dec 1 14:57:28 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2845>; Tue, 1 Dec 1992 14:57:16 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA05683; Tue, 1 Dec 92 11:52:57 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA03668; Tue, 1 Dec 92 11:54:39 PST Date: Tue, 1 Dec 1992 14:54:39 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212011954.AA03668@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Lines and last lines. The treatment of whitespace in the sam lexical analyzer is very idiosynchratic. Here are the features: B means "open a new file". x is the RE hack we talked about. This applies to y, X and Y as well. Also it means that either an RE or a space is *required* between "x" and any other command. This is why I think the comment in the man page about omitting the RE reads so poorly. BTW, x also works, and seems to be equivalent to x/(\n|.)*/p Here are some more dubious features: f sets the current filename to null. w prints ?no file name which is consistent with "f" setting the filename to null, at least. Otherwise, whitespace *seems* to be optional. Did I cover all the cases? BTW, reading and writing an octal dump a binary editor does not make. I can do exactly the same with vi (the editor that the labs people detest), including the bit about piping the whole file through an octal dumper & undumper. From sam-fans-owner Thu Dec 3 21:43:12 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2237>; Thu, 3 Dec 1992 21:42:43 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2516>; Thu, 3 Dec 1992 21:41:53 -0500 To: Sam Fans Subject: send Date: Thu, 3 Dec 1992 21:41:34 -0500 From: Scott Schwartz Message-Id: <92Dec3.214153est.2516@groucho.cs.psu.edu> Picture this. In one buffer you have some text, which is selected as dot. In the sam window you have some stuff, including ``|fmt''. In the sam window, you sweep out ``|fmt'' and select "send" twice in a row. The second time, the command fails, because the output of the pipe has become the text to send. Does anyone else find that odd? From sam-fans-owner Thu Dec 3 21:47:33 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2645>; Thu, 3 Dec 1992 21:47:21 -0500 To: Sam Fans Subject: Re: send In-reply-to: schwartz's message of Thu, 03 Dec 92 21:41:34 -0500. <92Dec3.214153est.2516@groucho.cs.psu.edu> Date: Thu, 3 Dec 1992 21:47:06 -0500 From: Chris Siebenmann Message-Id: <92Dec3.214721est.2645@hawkwind.utcs.toronto.edu> I don't think it's particularly odd; it's a consequence of some decisions about what goes in the cut buffer (I think that if you'll check you'll find that what you get is the text before the |fmt, not the pipe's output). - cks From sam-fans-owner Fri Dec 4 01:45:01 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Fri, 4 Dec 1992 01:44:53 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2516>; Fri, 4 Dec 1992 01:44:01 -0500 To: Sam Fans Subject: how to make it stop? Date: Fri, 4 Dec 1992 01:43:41 -0500 From: Scott Schwartz Message-Id: <92Dec4.014401est.2516@groucho.cs.psu.edu> In lesser editors, like emacs, one can hit ^G to interrupt an operation that is taking a long time. It turns out that sam takes a very long time to process ,x v/^#//viewpoint/+- on a buffer containing /etc/termcap, but there doesn't seem to be any way to make it give up. The menus have stopped working, and ps says it's blocked writing to a socket, so it's probably deadlocked. Sigh. From sam-fans-owner Fri Dec 4 02:18:50 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Fri, 4 Dec 1992 02:18:39 -0500 Received: by mod.civil.su.oz.au id <28685>; Fri, 4 Dec 1992 18:18:17 +1100 From: John (Deceased persons have no earning capacity) Mackin Date: Fri, 4 Dec 1992 02:03:35 -0500 To: Sam Fans cc: Solid Hogan Subject: Re: send In-Reply-To: <92Dec3.214153est.2516@groucho.cs.psu.edu> Message-ID: <199212041803.6362.sam.babin@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Picture this. In one buffer you have some text, which is selected as dot. In the sam window you have some stuff, including ``|fmt''. In the sam window, you sweep out ``|fmt'' and select "send" twice in a row. The second time, the command fails, because the output of the pipe has become the text to send. Does anyone else find that odd? Chris is right. No former mux user would ever find this odd :). The way it works is: "send" sends whatever is in the snarf buffer, _unless_ there is a non-null selection in the window where you are doing the "send"ing, in which case it sends the selection instead. This is good design: you don't want to have to go select, "snarf", "send". So, you select |fmt and then send. Now this replaces the snarf buffer with what gets cut -- just as Chris said -- and you will notice that the selection in the sam window goes away. This is a necessary consequence of the way the frame library works; since there's going to be an insertion in the sam window (that is, the "!" indicating that the command completed -- preceded by the head of its standard error, if any), it moves the insertion point (i.e. the selection) to the end and makes it zero-length. I can well understand that this might seem a little unnatural to people whose minds have been polluted by the Horror of X, where the insertion point and the selection are largely decoupled. However, this is by far the more natural model, IMHO. It certainly works better in practise. It's _much_ nicer to be able to edit your windows and then just "send" than it is to have to piece together a command on the command line the way you have to with xterm -- and even then you can't go back and edit it with the mouse before you hit newline, since the canonicalisation is happening all the way back in the tty line discipline in the kernel. This is just horrendous. Now that we have a freely-distributable frame library, one day I'll get a better terminal program out to the world. One day... :) By the way, I'm currently doing a version of Michael's scrolling menu that has a fixed upper part, like the jtools version of sam. If anyone else is doing that, mail me so we can avoid duplicating the effort. I'll send it to the list when it's done. Enough for now. OK, John. From sam-fans-owner Fri Dec 4 11:41:01 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Fri, 4 Dec 1992 11:40:45 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA06395; Fri, 4 Dec 1992 10:40:33 -0600 Message-Id: <9212041640.AA06395@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Streaming sam. Date: Fri, 4 Dec 1992 11:40:32 -0500 From: Alan Watson X-Mts: smtp I have a recollection that a streaming version of sam a la sed is mentioned somewhere in the sam documentation, but I cannot find this reference now. Was this ever implemented, and what was it's syntax and semantics? I'm using the following (the error handling of which might be better), but I wonder if there is a precedent to follow. This version doesn't really stream in the sense that I am used to (meaning set up some commands and then stream the entire file past the commands), but it is more flexible. For example, to reverse a file one can use: ; ssam ',x m0' [1=2] Usage: ssam commands ... exit 1 } FIFO=/usr/tmp/ssam.$pid.rd mkfifo $FIFO { echo 'r '$FIFO while ( ! ~ $#* 0 ) { echo $1 shift } echo ',p' } | sam -d >[2=] & cat >$FIFO wait $apid rm -f $FIFO exit 0 # end-of-file From sam-fans-owner Fri Dec 4 11:44:52 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Fri, 4 Dec 1992 11:44:39 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA06540; Fri, 4 Dec 1992 10:44:20 -0600 Message-Id: <9212041644.AA06540@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Streaming sam. Date: Fri, 4 Dec 1992 11:44:20 -0500 From: Alan Watson X-Mts: smtp Sigh. The reverse trick doesn't work. It's been a bad month. Try: ; ssam ',x m$' ; Fri, 4 Dec 1992 12:57:52 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA08403; Fri, 4 Dec 1992 11:57:35 -0600 Message-Id: <9212041757.AA08403@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Streaming sam. Date: Fri, 4 Dec 1992 12:57:35 -0500 From: Alan Watson X-Mts: smtp Scrub that. Try the following awful hack: ; cat rev ,x/\\/ i/\\/ ,x/\// i/\\/ ,x i/0i\// ,x s/\n/\\n\/\n/ $a/,p\n/ ,|sam -d ; ifs = $nl ssam `{ cat rev } rev2 ; ifs = $nl ssam `{ cat rev } rev3 ; diff rev rev3 ; A free email message to anyone who can do better. I think I'd better lie down. From sam-fans-owner Fri Dec 4 14:13:41 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Fri, 4 Dec 1992 14:13:19 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA03354; Fri, 4 Dec 92 11:12:41 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA03176; Fri, 4 Dec 92 11:10:06 PST Date: Fri, 4 Dec 1992 14:10:06 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212041910.AA03176@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Streaming sam. I've written a very basic stream sam, more of a toy than anything else, just to see how it would feel. I think there are some basic problems with the command language as applied to streams that the idea doesn't work. I don't want to duke it out on the list; I don't have time. My source is available to anyone who cares. It's a couple of hundred lines of C and implements x, y, a, c, and i. I use Henry's regexp package with hacks to make $ and ^ work on newlines, not just beginning- and end-of- string. From sam-fans-owner Tue Dec 8 21:12:37 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2732>; Tue, 8 Dec 1992 21:11:51 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2535>; Tue, 8 Dec 1992 21:10:59 -0500 To: Sam Fans Subject: how to shrink dot Date: Tue, 8 Dec 1992 21:10:28 -0500 From: Scott Schwartz Message-Id: <92Dec8.211059est.2535@groucho.cs.psu.edu> Given foo{ stuff } if you click on a brace dot is set to the text between them. Then how do you ask to shrink dot to include only whole lines within? .-0+1,.+0-1 doesn't work. .-1+2,.+1-2 works, though I'd expect it to fail at the top and bottom of the file, which it seems not to. On the other hand, if dot includes the entire top line, it fails. Strange. From sam-fans-owner Tue Dec 8 23:16:50 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2732>; Tue, 8 Dec 1992 23:16:35 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2541>; Tue, 8 Dec 1992 23:15:52 -0500 To: Sam Fans Subject: regexps Date: Tue, 8 Dec 1992 23:15:21 -0500 From: Scott Schwartz Message-Id: <92Dec8.231552est.2541@groucho.cs.psu.edu> Hmm. No syntax for matching word boundaries? Sigh. That comes up a lot. From sam-fans-owner Tue Dec 8 23:31:13 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2732>; Tue, 8 Dec 1992 23:31:03 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA04514; Tue, 8 Dec 92 20:30:50 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA08969; Tue, 8 Dec 92 20:28:27 PST Date: Tue, 8 Dec 1992 23:28:27 -0500 From: Paul Haahr Message-Id: <9212090428.AA08969@utopia.mv.us.adobe.com> To: schwartz@groucho.cs.psu.edu Subject: Re: regexps Cc: sam-fans@hawkwind.utcs.toronto.edu beginning of word: (^|[^a-zA-Z0-9]) end of word: ($|[^a-zA-Z0-9]) 'course, you still have to narrow dot by one then. your definition of word may be different from mine, of course, so, maybe (^|[ \t]) and ($|[ \t]) would be more appropriate. (i don't think sam takes \t, but it's much clearer for purposes of the example.) From sam-fans-owner Tue Dec 8 23:40:05 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2732>; Tue, 8 Dec 1992 23:39:39 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2541>; Tue, 8 Dec 1992 23:38:45 -0500 To: Paul Haahr cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: regexps In-reply-to: Your message of "Tue, 08 Dec 92 23:28:27 EST." <9212090428.AA08969@utopia.mv.us.adobe.com> Date: Tue, 8 Dec 1992 23:38:20 -0500 From: Scott Schwartz Message-Id: <92Dec8.233845est.2541@groucho.cs.psu.edu> | beginning of word: (^|[^a-zA-Z0-9]) | end of word: ($|[^a-zA-Z0-9]) I lust for \< and \>. In vi, something like %s/\/gnu/ is wonderfully concise. | 'course, you still have to narrow dot by one then. Hey, no fair leaving parts out. :-) From sam-fans-owner Tue Dec 8 23:56:15 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2732>; Tue, 8 Dec 1992 23:56:09 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2541>; Tue, 8 Dec 1992 23:55:17 -0500 To: Paul Haahr , sam-fans@hawkwind.utcs.toronto.edu Subject: Re: regexps Date: Tue, 8 Dec 1992 23:54:47 -0500 From: Scott Schwartz Message-Id: <92Dec8.235517est.2541@groucho.cs.psu.edu> Here's another question: Given a file containing foo dir foo bar dir bar ,x/[^a-z]dir[^a-z]/s/dir/path/ yields foo path foo bar path bar and leaves "r path" in the last line selected. That's odd, because running ,x/[^a-z]dir[^a-z]/p leaves " dir " selected, and then running s/dir/path leaves " path " selected, as I would have expected. From sam-fans-owner Wed Dec 9 01:18:43 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2740>; Wed, 9 Dec 1992 01:18:24 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA04741; Tue, 8 Dec 92 22:18:08 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA09031; Tue, 8 Dec 92 22:15:45 PST Date: Wed, 9 Dec 1992 01:15:45 -0500 From: Paul Haahr Message-Id: <9212090615.AA09031@utopia.mv.us.adobe.com> To: schwartz@groucho.cs.psu.edu Subject: Re: regexps Cc: sam-fans@hawkwind.utcs.toronto.edu as i remember, the rules in sam for where the selection goes after an x command that modified data were pretty vague. the justification that i came up with for this (which may or may not have anything to do with the code) was the way in which all modifications which are supposed to happen under an x// are batched and happen in a second pass. From sam-fans-owner Wed Dec 9 16:35:01 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2738>; Wed, 9 Dec 1992 16:34:40 -0500 To: sam-fans Subject: new menuhit.c Date: Wed, 9 Dec 1992 16:34:38 -0500 From: Chris Siebenmann Message-Id: <92Dec9.163440est.2738@hawkwind.utcs.toronto.edu> Apparently I forgot to point this out to the list. Some time back, Mike Haertel (mike@mystix.cs.uoregon.edu) posted a reimplementation of libXg/menuhit.c that did scrolling menus to comp.editors. Since the article has no doubt long since expired (posted 25 Nov), I've attached it here. I've been running this code for some time without problems. - cks /* Article 7064 of comp.editors: Path: utcsri!rpi!usenet.coe.montana.edu!ogicse!cs.uoregon.edu!mystix.cs.uoregon.edu!mike From: mike@mystix.cs.uoregon.edu (Michael John Haertel) Newsgroups: comp.editors Subject: Scrolling menus for Sam Summary: use at your own risk Message-ID: <1992Nov25.081302.26508@cs.uoregon.edu> Date: 25 Nov 92 08:13:02 GMT Article-I.D.: cs.1992Nov25.081302.26508 Sender: news@cs.uoregon.edu (Netnews Owner) Organization: University of Oregon Computer and Information Sciences Dept. Lines: 188 One day in a particularly large source directory I typed "sam *.[ch]", and the resulting menu of buffers exceeded what could fit vertically in my screen. So I decided to implement scrolling menus. Enclosed is a replacement for "menuhit.c" in the libXg/ subdirectory of the Sam distribution. It is a from-scratch implementation by me rather than being a modification of the old menuhit.c. It is a two hour hack so don't expect anything polished. Use it at your own risk... Mike */ #include "libg.h" enum { Scrollbar = 15, /* width of scrollbar in pixels */ Scrollthresh = 12, /* #items before we introduce a scrollbar. */ Border = 1, /* thickness of border on menu */ Inset = 2, /* inset of actual menu */ Vskip = 1, /* space between lines */ }; static char * genitem(Menu *menu, int i) { if (menu->item) return menu->item[i]; else return (*menu->gen)(i); } static Rectangle adjrect(Rectangle r) { if (r.max.x > screen.r.max.x) r = rsubp(r, Pt(r.max.x - screen.r.max.x, 0)); if (r.max.y > screen.r.max.y) r = rsubp(r, Pt(0, r.max.y - screen.r.max.y)); if (r.min.x < screen.r.min.x) r = raddp(r, Pt(screen.r.min.x - r.min.x, 0)); if (r.min.y < screen.r.min.y) r = raddp(r, Pt(0, screen.r.min.y - r.min.y)); return r; } static void highlight(Rectangle menur, int imin, int item) { if (item == -1) return; menur.min.y += (item - imin) * (font->height + Vskip); menur.max.y = menur.min.y + font->height; bitblt(&screen, menur.min, &screen, menur, ~D); } static void drawbar(Rectangle r, int imin, int imax, int nitems, Fcode f) { int h, b, e; Rectangle dorect; if (nitems == 0) return; h = r.max.y - r.min.y; b = (int) ((float) imin / nitems * h); e = (int) ((float) imax / nitems * h); dorect.min.x = r.min.x; dorect.max.x = r.max.x; dorect.min.y = r.min.y + b; dorect.max.y = r.min.y + e; bitblt(&screen, dorect.min, &screen, dorect, f); } static void draw(Menu *m, Rectangle r, Rectangle scrollr, int imin, int imax, int nitems) { char *s; Point p; Rectangle liner; int i; if (Dx(scrollr) != 0) bitblt(&screen, scrollr.min, &screen, Rpt(scrollr.min, r.max), Zero); else bitblt(&screen, r.min, &screen, r, Zero); if (Dx(scrollr) != 0) { bitblt(&screen, scrollr.min, &screen, scrollr, Zero); drawbar(scrollr, imin, imax, nitems, ~D); } liner.min = r.min; liner.max = add(r.min, Pt(Dx(r), font->height)); p = Pt(0, font->height + Vskip); for (i = imin; i < imax; ++i) { s = genitem(m, i); string(&screen, add(liner.min, Pt(Dx(liner) / 2 - strwidth(font, s) / 2, 0)), font, s, F); liner = raddp(liner, p); } } int menuhit(int but, Mouse *mouse, Menu *menu) { Rectangle totalr, menur, scrollr, itemr; int n, w, maxw, imin, imax, newimin, newimax, lasthit, hit; char *s; Bitmap *saveb; Point p; maxw = 0; for (n = 0; genitem(menu, n); ++n) { w = strwidth(font, genitem(menu, n)); if (w > maxw) maxw = w; } if (n == 0) return -1; /* maybe should wait for mouse released? */ lasthit = menu->lasthit; if (lasthit < 0 || lasthit >= n) lasthit = 0; imin = 0; imax = n > Scrollthresh ? Scrollthresh : n; if (imax <= lasthit) imin = lasthit - Scrollthresh / 2, imax = imin + Scrollthresh; if (imax > n) imin -= imax - n, imax -= imax - n; totalr.min = Pt(0,0); totalr.max.x = maxw + (n > Scrollthresh ? Scrollbar : 0) + 2 * Inset; totalr.max.y = (imax - imin) * (font->height + Vskip) - Vskip + 2 * Inset; p.x = (n > Scrollthresh ? Scrollbar : 0) + maxw / 2 + Inset; p.y = (lasthit - imin) * (font->height + Vskip) + (font->height + Vskip) / 2 + Inset; totalr = raddp(totalr, sub(mouse->xy, p)); totalr = adjrect(totalr); menur = inset(totalr, Inset); if (n > Scrollthresh) { scrollr = menur; scrollr.max.x = menur.min.x + Scrollbar - 1; menur.min.x += Scrollbar; } else scrollr.max.x = scrollr.min.x; saveb = balloc(totalr, screen.ldepth); if (!saveb) saveb = &screen; bitblt(saveb, saveb->r.min, &screen, totalr, S); border(&screen, totalr, Border, F); border(&screen, inset(totalr, Border), Inset - Border, Zero); draw(menu, menur, scrollr, imin, imax, n); cursorset(add(totalr.min, p)); highlight(menur, imin, lasthit); for (;;) { *mouse = emouse(); if ((mouse->buttons & (1 << but - 1)) == 0) break; if (ptinrect(mouse->xy, menur)) hit = (mouse->xy.y - menur.min.y) / (font->height + Vskip) + imin; else hit = -1; if (hit != lasthit) { highlight(menur, imin, lasthit); if (hit == imin && imin > 0) { --imin, --imax; draw(menu, menur, scrollr, imin, imax, n); cursorset(add(mouse->xy, Pt(0, font->height + Vskip))); } else if (hit == imax - 1 && imax < n) { ++imin, ++imax; draw(menu, menur, scrollr, imin, imax, n); cursorset(sub(mouse->xy, Pt(0, font->height + Vskip))); } highlight(menur, imin, hit); } if (ptinrect(mouse->xy, scrollr)) { newimin = (float) (mouse->xy.y - scrollr.min.y) / Dy(scrollr) * n; newimax = newimin + Scrollthresh; while (newimax > n) --newimin, --newimax; if (imin != newimin) { imin = newimin; imax = newimax; draw(menu, menur, scrollr, imin, imax, n); } } lasthit = hit; } if (lasthit != -1) menu->lasthit = lasthit; bitblt(&screen, totalr.min, saveb, totalr, S); bfree(saveb); return lasthit; } From sam-fans-owner Sun Dec 13 22:57:44 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2745>; Sun, 13 Dec 1992 22:57:27 -0500 Received: by mod.civil.su.oz.au id <28680>; Mon, 14 Dec 1992 14:57:02 +1100 From: John (I don't want no teenage queen / I just want my M-fourteen) Mackin Date: Sun, 13 Dec 1992 22:47:48 -0500 To: Scott Schwartz cc: Sam Fans Subject: Re: how to shrink dot In-Reply-To: <92Dec13.215944est.2516@groucho.cs.psu.edu> Message-ID: <199212141447.5855.sam.babom@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Scott and I are talking about shrinking dot. At first, I wanted to change the indentation of the stuff in between the inner braces in something like for (..) { for (..) { stuff } } where it was easier to double click on the brace than sweep out exactly the right lines. You don't need to shrink dot for this to work. This was the kind of thing I thought you would have in mind. All you have to do is to pick the whole lines first. Try this, tested in the very sam I am writing this mail in: Snarf this command, then double-click inside the first brace, change to the sam window and send: x/^.*$/ x/^/a/ / As you can see, it works on the inner lines only, as we want. More generally, it is easy to select a region with delimiters, but it you want to process the stuff between the delimiters you have to exclude them from dot. I don't understand this. When you use double-click to `select a region with delimiters' sam _does_ exclude them from the selection: there is no way to get it to _include_ them. Maybe you mean if you are using an x command -- can you give me another concrete example? OK, John. From sam-fans-owner Tue Dec 15 23:16:57 1992 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Tue, 15 Dec 1992 23:13:39 -0500 From: rob@research.att.com Date: Tue, 15 Dec 1992 23:04:40 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <92Dec15.231339est.2701@hawkwind.utcs.toronto.edu> trimming the edges of dot in sam is actually pretty easy, especially using +0 and -0 as addresses. these move to the nearest end or beginning of a line. if you've just double clicked the braces in for(;;){ ... } and you want to trim it to the whole lines within, just say -0+,+0- it looks funny but it means something: move the beginning of dot to the beginning of the previous line, then advance it a line, ending up at the first line boundary within dot, and symmetrically for the end of dot. you may of course include a command, as in -0+,+0- x/^ /d or, what i prefer, -0+,+0- s/^ //g because dot stays put. when you're learning this stuff, though, don't use a command: just try the address to see what gets selected. another trick: adjusting to the null string at the beginning or end of dot using +#0 and -#0, an exercise i leave to the reader. since this is my first message to this group, i should take the opportunity to say how encouraged i am by the attention sam seems to have acquired and delight at how creatively people seem to be using it. also, i would like to make an announcement that the public release of sam would not and could not have happened without the generous and able assistance of bob flandrena, who did all the work of making the plan 9 sam (the only one i use) portable to the many flavors of unix out there. -rob pike From sam-fans-owner Fri Dec 18 21:36:14 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Fri, 18 Dec 1992 21:35:59 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2535>; Fri, 18 Dec 1992 21:35:11 -0500 To: John Mackin cc: Sam Fans Subject: Re: how to shrink dot In-reply-to: Your message of "Sun, 13 Dec 92 22:47:48 EST." <199212141447.5855.sam.babom@civil.su.oz.au> Date: Fri, 18 Dec 1992 21:34:53 -0500 From: Scott Schwartz Message-Id: <92Dec18.213511est.2535@groucho.cs.psu.edu> [sorry for the delay replying; its been one of those weeks] John writes: | You don't need to shrink dot for this to work. This was the kind of thing | I thought you would have in mind. All you have to do is to pick the whole | lines first. ... x/^.*$/ x/^/a/ / Workarounds, workarounds. :-) Suppose I want to do the formatting by pipeing to some program? Then I need the selection to be correct beforehand. | I don't understand this. When you use double-click to `select a region | with delimiters' sam _does_ exclude them from the selection: there is no | way to get it to _include_ them. Maybe you mean if you are using an x | command -- can you give me another concrete example? There I was thinking of something like clipping mailbox entries. If you select one with something like /^From /;/^From / you need to trim the top and bottom to get the actual message excluding the From line. From sam-fans-owner Fri Dec 18 22:21:24 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Fri, 18 Dec 1992 22:21:11 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2535>; Fri, 18 Dec 1992 22:20:06 -0500 To: rob@research.att.com cc: sam-fans@hawkwind.utcs.toronto.edu In-reply-to: Your message of "Tue, 15 Dec 92 23:04:40 EST." <92Dec15.231339est.2701@hawkwind.utcs.toronto.edu> Date: Fri, 18 Dec 1992 22:19:44 -0500 From: Scott Schwartz Message-Id: <92Dec18.222006est.2535@groucho.cs.psu.edu> | since this is my first message to this group, i should take the | opportunity to say how encouraged i am by the attention sam seems | to have acquired and delight at how creatively people seem to be | using it. Thanks, Rob and Bob, for giving us the chance to play with it. From sam-fans-owner Tue Jan 12 22:47:35 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2408>; Tue, 12 Jan 1993 22:47:14 -0500 Received: by mod.civil.su.oz.au id <28687>; Wed, 13 Jan 1993 14:46:45 +1100 From: John (Most modern computers would break if you stood on them) Mackin Date: Tue, 12 Jan 1993 22:41:05 -0500 To: Sam Fans Subject: undo and the snarf buffer Message-ID: <199301131441.8607.sam.babot@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ This is something I have been wondering about for a couple of years, and since just noticed it again I thought I'd see what people think. At the moment, doing "undo" on button two doesn't affect the contents of the snarf buffer. I think there is a good argument that it should. On the theoretical side, you're asking sam to restore its state to a previous state. That shouldn't be just the state of the buffer being edited, it should be all the state you can get at. On the practical side, this bites me when I do a "cut" accidentally when I meant a "paste". What I think I should be able to do is "undo" just once -- which would undo the cut -and- back out the snarf buffer to have what it had before the cut was done -- and then do "paste". Instead I have to re-snarf what I had before, which often involves undoing further back to get it back in the buffer again if I had cut it originally. Thoughts? OK, John. From sam-fans-owner Mon Jan 18 12:50:36 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Mon, 18 Jan 1993 12:47:44 -0500 Received: by ux2.cso.uiuc.edu id AA43459 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 18 Jan 1993 11:47:32 -0600 Date: Mon, 18 Jan 1993 12:47:32 -0500 From: Ed Kubaitis - CCSO Message-Id: <199301181747.AA43459@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam X11 extensions Hi, When Chris Siebenmann told me about sam-fans, he warned that most people on it were probably "more purist in their approach" than me. So sam-fans may be a poor place for this. Anyway, I have developed mods to support additional features in sam's X11 interface. Perhaps some of you might be interested in some of them. If so I welcome your comments. The man page is attached. The materials are available from uxc.cso.uiuc.edu in pub/sam/samx1.0.shar. They apply to the 11/13/92 sam from att.research.com in dist/sam/bundle.Z. The samKeys feature requires perl for a script invoked by samterm. Ed ---------------------------------- Ed Kubaitis (ejk@ux2.cso.uiuc.edu) Computing & Communications Services Office - University of Illinois, Urbana =============================================================================== SAMX(1L) ConvexOS Man Pages SAMX(1L) NAME samx - X11 extensions to the sam text editor. SYNOPSIS Optional sam X11 features selectable by resources in $HOME/Sam or $HOME/.Xdefaults. DESCRIPTION The resources below enable optional features in sam's X11 interface (samterm). The features required modifications to the standard sam source distribution and are thus not avail- able on systems without the modifications installed. Features are requested by including resources in $HOME/Sam or $HOME/.Xdefaults. If no features are requested, sam should behave identically to a standard, unmodified sam. RESOURCES samterm*samKeys: on Enables user-tailorable key definitions in $HOME/Samkeys. If the file doesn't exist, one is created with example entries and comments describing the format. The file maps keyboard keys to samterm actions and sam commands. More than thirty actions are provided for window selection, simulated typing, scrolling, cursor control, and most menu items. samterm*autoIndent: on Enables vi-like autoindent when a newline is entered from the keyboard in a file window. Unlike vi though, one can simply backspace over the provided automatic whitespace. samterm*autoStart: on Automatically selects the first file (alphabeti- cally) in the list of files provided on the sam com- mand line. Use of this feature causes a spurious ?blank expected message in the sam command window. samterm*autoSweep: on Uses a default window when a file is first selected rather than prompting for a rectangle to be swept with the mouse. The Reshape menu 2 item turns autosweep off. The Samkeys autosweep action toggles autosweep on and off. samterm*autoSweepWindow: top,bottom Sets the size and location of the default window used when autosweep is in effect. The parameters are fractions (from 0 through 1) of the full height of the sam screen. The default value is .2,1. That is, the bottom 80% of the screen. samterm*samWindow: top,bottom Sets the initial size and location of the sam com- mand window. The parameters are fractions (from 0 through 1) of the full height of the sam screen. The default value is 0,.2. That is, the top 20% of the screen. samterm*samWindowAlt: top,bottom Sets an alternate size and location for the sam com- mand window. The Samkeys samalt action toggles the sam window between the two locations. The default value is .4,.6. That is, the middle 20% of the screen. samterm*fileTitle: on Requests display of the current file name in the X11 window manager title bar. samterm*shiftWidth: n Sets the shiftwidth (0; Tue, 19 Jan 1993 07:44:23 -0500 Received: by ux2.cso.uiuc.edu id AA46496 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Tue, 19 Jan 1993 06:44:10 -0600 Date: Tue, 19 Jan 1993 07:44:10 -0500 From: Ed Kubaitis - CCSO Message-Id: <199301191244.AA46496@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam X11 extensions Sites with a version of perl earlier than 4.035 will need the attached patch (from Bob Gibson ) Ed ------------------------------------------------------------------------------- *** samkeys_parse- Mon Jan 18 19:14:37 1993 --- samkeys_parse Mon Jan 18 19:00:56 1993 *************** *** 74,80 **** warn "Multiple key symbols in $Source:\n$line\n"; next SourceLine; } ! else { $keyhex = $Key{$k} }; } elsif ($m = $Mod{$k}) { $mod |= $m; } else { --- 74,80 ---- warn "Multiple key symbols in $Source:\n$line\n"; next SourceLine; } ! else { $keyhex = $Key{$k}; } } elsif ($m = $Mod{$k}) { $mod |= $m; } else { ------------------------------------------------------------------------------- From sam-fans-owner Mon Feb 15 11:29:13 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2756>; Mon, 15 Feb 1993 11:28:37 -0500 To: sam-fans Subject: sam on DEC OSF/1 Alpha? Date: Mon, 15 Feb 1993 11:28:22 -0500 From: Chris Siebenmann Message-Id: <93Feb15.112837est.2756@hawkwind.utcs.toronto.edu> Has anyone got sam (especially samterm) running on this platform? sam itself seems to work fine for me, but samterm is core dumping in odd places for apparently inexplicable reasons (dbx is being unhelpful). - cks From sam-fans-owner Mon Feb 15 19:34:11 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2763>; Mon, 15 Feb 1993 19:33:59 -0500 To: sam-fans Subject: Re: sam on DEC OSF/1 Alpha? Date: Mon, 15 Feb 1993 19:33:44 -0500 From: Chris Siebenmann Message-Id: <93Feb15.193359est.2763@hawkwind.utcs.toronto.edu> Well, thanks to John Mackin, I now have the problem identified. Pointers in DEC Alpha OSF/1 are 64 bits (as is 'long'), and the sam to samterm protocol passes pointers around, lopped to 32 bits. Naturally this causes problems when samterm gets a lopped pointer back and attempts to use it. Unfortunately, I'm not quite sure of the best way to fix this. Time to go spelunkering the sources. - cks From sam-fans-owner Mon Feb 15 19:49:23 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2763>; Mon, 15 Feb 1993 19:49:07 -0500 From: rob@research.att.com Date: Mon, 15 Feb 1993 19:47:52 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Feb15.194907est.2763@hawkwind.utcs.toronto.edu> it's probably that the host and terminal exchange a pointer in the protocol and it's known to fit in 4 bytes. you'll need to fuss with the protocol, making it incompatible with other architectures. sigh. -rob From sam-fans-owner Mon Feb 15 20:26:33 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2763>; Mon, 15 Feb 1993 20:26:24 -0500 Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08637; Mon, 15 Feb 93 20:26:07 -0500 Received: from localhost.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA15916; Mon, 15 Feb 93 17:26:07 PST Message-Id: <9302160126.AA15916@cygnus.com> To: Chris Siebenmann Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam on DEC OSF/1 Alpha? In-Reply-To: Your message of "Mon, 15 Feb 93 19:33:44 EST." <93Feb15.193359est.2763@hawkwind.utcs.toronto.edu> Date: Mon, 15 Feb 1993 20:26:07 -0500 From: brendan@cygnus.com > Well, thanks to John Mackin, I now have the problem identified. > Pointers in DEC Alpha OSF/1 are 64 bits (as is 'long'), and the sam to > samterm protocol passes pointers around, lopped to 32 bits. Naturally > this causes problems when samterm gets a lopped pointer back and > attempts to use it. > > Unfortunately, I'm not quite sure of the best way to fix this. > Time to go spelunkering the sources. One of the best ways to handle this that I've found is to prototype all of the functions, then find where integers are being passed as pointers, and visa-versa. (ptrs are 64 bits, ints are 32...if you pass `0' where a pointer is expected, it'll be bogus) Then when you compile with an ANSIish compiler (use gcc :) ), it'll tell you about all of the violations. Brendan -- Brendan Kehoe brendan@cygnus.com Cygnus Support, Mountain View, CA +1 415 903 1400 ``In a cruel and imperfect world,'' says critic Rex Reed, ``[Audrey Hepburn] was living proof that God could still create perfection.'' From sam-fans-owner Mon Feb 15 20:59:16 1993 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <2763>; Mon, 15 Feb 1993 20:58:57 -0500 Received: from moria.cs.su.OZ.AU (for hawkwind.utcs.toronto.edu) with MHSnet; Tue, 16 Feb 1993 12:58:45 +1100 From: David Hogan Date: Mon, 15 Feb 1993 20:11:21 -0500 To: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <93Feb15.194907est.2763@hawkwind.utcs.toronto.edu> Message-ID: <199302161211.25219.out.babun@cs.su.oz.au> > it's probably that the host and terminal exchange a pointer > in the protocol and it's known to fit in 4 bytes. > you'll need to fuss with the protocol, making it > incompatible with other architectures. sigh. > -rob One way of doing this would be to replace the pointers in the protocol with 32 bit offsets from the start of the arena. That way, unless the arena grows to be greater than 4 gigabytes (!) 4 bytes will still be adequate, and the modified samterm should still interoperate with sams on other architectures. From sam-fans-owner Mon Feb 15 21:10:42 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2763>; Mon, 15 Feb 1993 21:10:27 -0500 From: rob@research.att.com Date: Mon, 15 Feb 1993 21:06:45 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Feb15.211027est.2763@hawkwind.utcs.toronto.edu> i used the wrong word; i should have said 'versions'. in the last round, i added the exchange of version number between host and terminal, so changes can be made compatibly. the issue is letting old sams and samterms operate with new samterms and sam. in this case, at the point the addresses are exchanged, the version number could be checked and either 64-bit addresses used (the most general answer) or an offset. -rob From sam-fans-owner Mon Feb 15 22:01:48 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2763>; Mon, 15 Feb 1993 22:01:34 -0500 To: sam-fans Subject: Re: sam on DEC OSF/1 Alpha? Date: Mon, 15 Feb 1993 22:01:24 -0500 From: Chris Siebenmann Message-Id: <93Feb15.220134est.2763@hawkwind.utcs.toronto.edu> This is probably a naive question, but is there any reason the protocol has to pass around the addresses instead of tokens, except for convenience and to avoid another lookup table? As far as I can tell from a quick scan, sam itself never uses the fact that the magic tokens are addresses, it just passes them around; only samterm cares. Indeed, it might be that only a relatively minor modification to samterm/mesg.c would be needed. Am I missing something here? - cks From sam-fans-owner Mon Feb 15 22:47:39 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2763>; Mon, 15 Feb 1993 22:47:28 -0500 From: rob@research.att.com Date: Mon, 15 Feb 1993 22:44:32 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Feb15.224728est.2763@hawkwind.utcs.toronto.edu> you're missing nothing except the possibility of incompatibility with existing binaries of sam and samterm, which is probably a minor issue for most sam users, who are in the small minority in their local shops. oh, and the fact that '32 bit address' is a fine token when you're implementing sam on a vax 750 in 1985. -rob From sam-fans-owner Wed Feb 17 15:07:17 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2748>; Wed, 17 Feb 1993 15:06:52 -0500 To: sam-fans Subject: an archive of list traffic to date is now available via ftp Date: Wed, 17 Feb 1993 15:06:39 -0500 From: Chris Siebenmann Message-Id: <93Feb17.150652est.2748@hawkwind.utcs.toronto.edu> As /pub/sam/sam-fans-list on ftp.sys.utoronto.ca (128.100.2.220). Enjoy. - cks From sam-fans-owner Fri Feb 19 09:28:11 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2753>; Fri, 19 Feb 1993 09:27:55 -0500 Received: by ux2.cso.uiuc.edu id AA35622 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Fri, 19 Feb 1993 08:27:44 -0600 Date: Fri, 19 Feb 1993 09:27:44 -0500 From: Ed Kubaitis - CCSO Message-Id: <199302191427.AA35622@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: A fan in Russia I received an inquiry about the sam X11 extensions from Dimitri Doronin of the Research & Production Centre (SAPSAN) in Moscow. "I have sam and I love it" he says. I told him about sam-fans. Perhaps we'll be hearing from him. The thought of a Cyrillic sam put me in mind of something else. The samx extensions stole the X11 Mod1 modifier (usually Alt) for Samkeys, thus making the undocumented Latin1 or unicode composition feature unavailable. I spent some time investigating how to provide alternative access to at least latin1 composition when Samkeys is used, but couldn't manage to get them displayed properly even with a vanilla sam. There was always an 'A' preceding the composed character. Is this a bug, an unfinished project, or a misunderstanding of the feature/code on my part? Ed ---------------------------------- Ed Kubaitis (ejk@ux2.cso.uiuc.edu) Computing & Communications Services Office - University of Illinois, Urbana From sam-fans-owner Fri Feb 19 11:30:39 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2753>; Fri, 19 Feb 1993 11:30:25 -0500 From: rob@research.att.com Date: Fri, 19 Feb 1993 11:13:22 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Feb19.113025est.2753@hawkwind.utcs.toronto.edu> sam is already cyrillic (if that's an adjective), as any plan 9 user will tell you. i question the judgement of the person who broke the ability to input foreign characters and replaced it with racing stripes and streamers on the handlebars. -rob From sam-fans-owner Fri Feb 19 13:06:01 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2756>; Fri, 19 Feb 1993 13:05:48 -0500 Received: by ux2.cso.uiuc.edu id AA33443 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Fri, 19 Feb 1993 12:05:34 -0600 Date: Fri, 19 Feb 1993 13:05:34 -0500 From: Ed Kubaitis - CCSO Message-Id: <199302191805.AA33443@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: A fan in Russia rob@research.att.com - writes: |sam is already cyrillic (if that's an adjective), as any plan 9 user |will tell you. i question the judgement of the person who broke the |ability to input foreign characters and replaced it with racing stripes |and streamers on the handlebars. Guilty of adding racing stripes perhaps, but not of breaking compose. Composed characters are not displayed properly in the 11/13/92 Unix/X11 sam from att.research.com. ---------------------------------- Ed Kubaitis (ejk@ux2.cso.uiuc.edu) Computing & Communications Services Office - University of Illinois, Urbana From sam-fans-owner Sat Feb 20 03:09:09 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Sat, 20 Feb 1993 03:08:45 -0500 Received: by mod.civil.su.oz.au id <28687>; Sat, 20 Feb 1993 19:08:34 +1100 From: John Mackin Date: Sat, 20 Feb 1993 02:52:09 -0500 To: Sam Fans Subject: A point about ^ and $ in sam regexps Message-ID: <199302201852.6794.sam.badab@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ In Rob's paper `Structural Regular Expressions,' found in doc/se.ps in recent distributions of sam by ftp from research.att.com (I don't think it was there in the version that was put up right at the beginning), there is the following statement on p. 4: The program to capitalize `i's should be writable as x/[A-Za-z]+/ g/^i$/ c/I/ That is, the definition of ^ and $ should reflect the structure of the input. For compatibility and because of some problems in the implementation, however, ^ and $ in sam always match line boundaries. When I first read this I distantly agreed with it. Distantly because I remember some years ago when first learning to edit with sam's command language being often frustrated by the fact that ^ and $ couldn't be persuaded to match the beginning and end of a structural piece rather than a line boundary; only distantly since it's been a long time since I felt the need to do that, and I find I have no requirement for it any more, having learned to think in the way the command language works. The point of this mail is that this morning I had what seems to me a definite need for the way it works at the moment, and therefore I thought I should put in a positive word for always matching a line boundary -- or perhaps someone will tell me a nicer way to do this without using that feature. I had some text (whole lines) selected which was indented by several spaces on each line. I wanted to reduce all embedded runs of spaces to single spaces without affecting the indentation. The command x/ +/ v/^/ c/ / came naturally to hand, and of course worked as I wanted. Would there be as natural a way of expressing this if the meaning of ^ were to change? OK, John. From sam-fans-owner Sat Feb 20 10:10:59 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Sat, 20 Feb 1993 10:10:25 -0500 From: rob@research.att.com Date: Sat, 20 Feb 1993 10:08:54 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Feb20.101025est.2748@hawkwind.utcs.toronto.edu> x/\n? +/ v/\n/ c/ / -rob From sam-fans-owner Sun Feb 21 05:06:01 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Sun, 21 Feb 1993 05:05:49 -0500 Received: by mod.civil.su.oz.au id <28686>; Sun, 21 Feb 1993 21:05:23 +1100 From: John (Most modern computers would break if you stood on them) Mackin Date: Sun, 21 Feb 1993 05:02:04 -0500 To: Sam Fans Subject: ^ and $ Message-ID: <199302212102.8405.sam.badak@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Unfortunately, x/\n? +/ v/\n/ c/ / doesn't mean the same thing as x/ +/ v/^/ c/ / as long as the selection consists of whole lines, as I posited. I thought along those paths before sending my first mail. The suggested command chews up the indentation of the first line, since there is no \n inside the selection for the x command to match there. I think there may be no way to express this without a way to match the null string at the beginning of a line, the current meaning of `^'. OK, John. From sam-fans-owner Sun Feb 21 11:23:35 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Sun, 21 Feb 1993 11:23:16 -0500 From: rob@research.att.com Date: Sun, 21 Feb 1993 11:19:40 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Feb21.112316est.2748@hawkwind.utcs.toronto.edu> x s2/ +/ /g From sam-fans-owner Sun Feb 21 18:36:02 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Sun, 21 Feb 1993 18:35:51 -0500 Received: by mod.civil.su.oz.au id <28685>; Mon, 22 Feb 1993 10:35:29 +1100 From: John (Most modern computers would break if you stood on them) Mackin Date: Sun, 21 Feb 1993 18:33:45 -0500 To: Sam Fans Subject: A new pleasure In-Reply-To: <93Feb21.112316est.2748@hawkwind.utcs.toronto.edu> Message-ID: <199302221033.858.sam.badan@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ x s2/ +/ /g Hey thanks a lot. I had never thought before of combining s's number modifier with its g modifier. I will now though. OK, John. From sam-fans-owner Sun Feb 21 21:30:08 1993 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Sun, 21 Feb 1993 21:29:48 -0500 Received: from moria.cs.su.OZ.AU (for hawkwind.utcs.toronto.edu) with MHSnet; Mon, 22 Feb 1993 13:29:24 +1100 From: David Hogan Date: Sun, 21 Feb 1993 21:17:41 -0500 To: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <93Feb21.112316est.2748@hawkwind.utcs.toronto.edu> Message-ID: <199302221317.24582.out.babup@cs.su.oz.au> X-Face: "mmQCpqDtPafky^DZk|$l[`q{gw{Au4c>b/k]-H]fvn[nY@JvvEM^nP-ja^O5\bw!4~x\OH RKu~gL$=J$ From: rob@research.att.com > x s2/ +/ /g I don't want to be a party pooper, but this doesn't work if there is a line which doesn't start with whitespace at all. How about: y/^ +/ x/ +/ c/ / From sam-fans-owner Sun Feb 21 23:55:24 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2758>; Sun, 21 Feb 1993 23:55:16 -0500 From: rob@research.att.com Date: Sun, 21 Feb 1993 23:48:41 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Feb21.235516est.2758@hawkwind.utcs.toronto.edu> How about: y/^ +/ x/ +/ c/ / that's using ^ again; i thought the exercise was to avoid it. at least, that is the exercise i've been working on. when i made my suggestion x s2/ +/ /g i implicitly assumed, as i think did the original poster, that each line began with white space. as i sit here now, i can't find a clean-enough-to-use version that doesn't use ^. the magic thing about ^ is that it works at the beginning of the file; otherwise i could cheat. the poster said he had whole lines, hence: -#1,. x/\n?.+/ v/\n/ x/ +/ c/ / but this is already too silly. -rob From sam-fans-owner Mon Feb 22 22:37:14 1993 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <2766>; Mon, 22 Feb 1993 22:37:00 -0500 Received: from moria.cs.su.OZ.AU (for hawkwind.utcs.toronto.edu) with MHSnet; Tue, 23 Feb 1993 14:36:37 +1100 From: David Hogan Date: Mon, 22 Feb 1993 22:26:28 -0500 To: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <93Feb21.235516est.2758@hawkwind.utcs.toronto.edu> Message-ID: <199302231426.26622.out.babus@cs.su.oz.au> X-Face: "mmQCpqDtPafky^DZk|$l[`q{gw{Au4c>b/k]-H]fvn[nY@JvvEM^nP-ja^O5\bw!4~x\OH RKu~gL$=J$ From: rob@research.att.com > y/^ +/ x/ +/ c/ / > that's using ^ again; i thought the exercise was to avoid it. > at least, that is the exercise i've been working on. I thought the point was to avoid using it in sub-commands. Although the command we are trying to find might have to be the sub-command of another x command, I suppose. > when i made my suggestion > x s2/ +/ /g > i implicitly assumed, as i think did the original poster, that > each line began with white space. >[...] Hmmm, I missed that when I first read the post. Anyway, here's another way to do it: x/[^ ].*/ s/ +/ /g (Dang! That ^ is unavoidable :-) From sam-fans-owner Tue Feb 23 14:17:03 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2759>; Tue, 23 Feb 1993 14:16:38 -0500 Received: by ux2.cso.uiuc.edu id AA48500 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Tue, 23 Feb 1993 13:16:20 -0600 Date: Tue, 23 Feb 1993 14:16:20 -0500 From: Ed Kubaitis - CCSO Message-Id: <199302231916.AA48500@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: X11 Extended Character Display Support for X11 display of characters beyond ASCII-7 is available from uxc.cso.uiuc.edu in pub/sam/latin.shar. This support was developed for the next version of the samx extensions, but I thought some might like it separately. It's a small mod (~120 lines) to two libXg modules. There's a README that briefly describes extended character handling. It hasn't been exhaustively tested, so let me know if problems. Ed ---------------------------------- Ed Kubaitis (ejk@ux2.cso.uiuc.edu) Computing & Communications Services Office - University of Illinois, Urbana From sam-fans-owner Sun Mar 7 14:52:32 1993 Received: from nexus.yorku.ca ([130.63.9.66]) by hawkwind.utcs.toronto.edu with SMTP id <2778>; Sun, 7 Mar 1993 14:51:53 -0500 Received: from ursa.sis.yorku.ca ([130.63.245.12]) by nexus.yorku.ca with SMTP id <9226>; Sun, 7 Mar 1993 14:51:39 -0500 Received: by sis.yorku.ca (4.1/SMI-4.1) id AA21550; Sun, 7 Mar 93 14:50:08 EST Date: Sun, 7 Mar 1993 14:50:08 -0500 From: "Ozan Yigit" Message-Id: <9303071950.AA21550@sis.yorku.ca> To: sam-fans@hawkwind.utcs.toronto.edu Subject: auto-scroll? Sam design seem to have left out a window auto-scroll while selecting a region [or at least the X version has]. It is one of those facilities that is so familiar from other mouse-based editors I have used over the years, [especially Mac ones] that its absence [for me] seriously weakens the use of the mouse. Any thoughts on this? Is it merely fancy handles? I happen to think not. ... oz --- In evolution, a negative gradient operates | electric: oz@sis.yorku.ca in the perfecting of structural solutions. | ph:[416] 736 2100 x 33976 -- from Golem's Inaugural Lecture From sam-fans-owner Sun Mar 7 15:36:11 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2778>; Sun, 7 Mar 1993 15:36:00 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2542>; Sun, 7 Mar 1993 15:34:37 -0500 To: "Ozan Yigit" cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: auto-scroll? In-reply-to: Your message of "Sun, 07 Mar 1993 14:50:08 EST." <9303071950.AA21550@sis.yorku.ca> Date: Sun, 7 Mar 1993 15:34:07 -0500 From: Scott Schwartz Message-Id: <93Mar7.153437est.2542@groucho.cs.psu.edu> | Any thoughts on this? Is it merely fancy handles? I happen to think not. I (strongly) agree with you, but I can also see how, if one were sitting in front of a blit connected to a vax/750 at 4800 baud, one might not want to wait for all of /etc/termcap to be sent over every time one drags the scrollbar to the bottom. From sam-fans-owner Sun Mar 7 16:13:54 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2782>; Sun, 7 Mar 1993 16:13:35 -0500 From: rob@research.att.com Date: Sun, 7 Mar 1993 16:05:49 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Mar7.161335est.2782@hawkwind.utcs.toronto.edu> it would be nice, you're right. the problem lies in sam's design: splitting the text between host and terminal makes it a logistical nightmare to handle the scrolling during selection. it has been tried but the communications in the middle made it too slow to install. so engineering, rather than intention, forced the omission of the feature. -rob From sam-fans-owner Tue Mar 9 09:11:31 1993 Received: from relay.eunet.fi ([192.26.119.4]) by hawkwind.utcs.toronto.edu with SMTP id <2784>; Tue, 9 Mar 1993 09:11:00 -0500 Received: from sequent.kiae.su by relay.eunet.fi with UUCP id AA01685 (5.65c/IDA-1.4.4 for sam-fans@hawkwind.utcs.toronto.edu); Tue, 9 Mar 1993 16:00:34 +0200 Received: by sequent.kiae.su; Tue, 9 Mar 93 15:19:10 +0300 Received: by sapsan.msk.su; Tue, 9 Mar 93 15:25:28 +0300 (MSD) Received: by soft.sapsan.msk.su; Tue, 9 Mar 93 15:21:57 +0300 (MSD) From: To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: Organization: Research & Production Centre SAPSAN Illegal-Object: Syntax error in From: address found on hawkwind.utcs.toronto.edu: From: ddw@soft.sapsan.msk.su(0000-Admin(0000))) ^-missing closing ')' in token Date: Tue, 9 Mar 1993 07:21:56 -0500 Subject: silly question Hi! Does anybody know the sam-term part of sam for usualy terminals? Is there the sam-term part based on curses anywere in the nature? Is it very silly question? Dmitry Doronin. -- Dmitry W. Doronin | RUSSIA, MOSCOW 281-4703, 581-2039(HOME) | ddw@sapsan.msk.su The geographic area formely known as the Union of Soviet Socialist Republics From sam-fans-owner Wed Mar 10 09:29:21 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2787>; Wed, 10 Mar 1993 09:28:20 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA13278; Wed, 10 Mar 93 09:28:14 -0500 Date: Wed, 10 Mar 1993 09:28:14 -0500 From: plexus!mdash@uunet.uu.net Message-Id: <9303101428.AA13278@relay2.UU.NET> Received: from plexus.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 092746.6663; Wed, 10 Mar 1993 09:27:46 EST To: sam-fans@hawkwind.utcs.toronto.edu Content-Type: text Content-Length: 87 Please add me to the mailing list. --Mike Scheer, 908-273-1885, mdash@plexus-sys.com From sam-fans-owner Wed Mar 10 11:42:30 1993 Received: from nexus.yorku.ca ([130.63.9.66]) by hawkwind.utcs.toronto.edu with SMTP id <2787>; Wed, 10 Mar 1993 11:41:46 -0500 Received: from ursa.sis.yorku.ca ([130.63.245.12]) by nexus.yorku.ca with SMTP id <9226>; Wed, 10 Mar 1993 11:41:12 -0500 Received: by sis.yorku.ca (4.1/SMI-4.1) id AA07444; Wed, 10 Mar 93 11:39:39 EST Date: Wed, 10 Mar 1993 11:39:39 -0500 From: "Ozan Yigit" Message-Id: <9303101639.AA07444@sis.yorku.ca> To: sam-fans@hawkwind.utcs.toronto.edu Subject: huh? works: ,x/arglist_opt/ c/opt_arglist/ complains: , x /arglist_opt/ c /opt_arglist/ ?changes not in sequence I am not sure if I understand this. The only difference is the spaces... Have I missed a subtle point about them? ... oz --- With diligence, it is possible to make | electric: oz@sis.yorku.ca anything run slowly. --Tom Duff | ph:[416] 736 2100 x 33976 From sam-fans-owner Wed Mar 10 11:54:30 1993 Received: from mail-relay-1 ([130.248.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2789>; Wed, 10 Mar 1993 11:54:09 -0500 Received: by mail-relay-1; id AA11724; Wed, 10 Mar 93 08:54:02 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA04978; Wed, 10 Mar 93 08:53:29 PST Date: Wed, 10 Mar 1993 11:53:29 -0500 From: Paul Haahr Message-Id: <9303101653.AA04978@utopia.mv.us.adobe.com> To: oz@sis.yorku.ca Subject: Re: huh? Cc: sam-fans@hawkwind.utcs.toronto.edu > works: > ,x/arglist_opt/ c/opt_arglist/ > complains: > , x /arglist_opt/ c /opt_arglist/ i believe the difference is that ``x'' without a pattern immediately following it uses an implicit /^.*\n/ From sam-fans-owner Wed Mar 10 12:07:20 1993 Received: from nexus.yorku.ca ([130.63.9.66]) by hawkwind.utcs.toronto.edu with SMTP id <2788>; Wed, 10 Mar 1993 12:07:07 -0500 Received: from ursa.sis.yorku.ca ([130.63.245.12]) by nexus.yorku.ca with SMTP id <9229>; Wed, 10 Mar 1993 12:05:26 -0500 Received: from localhost.yorku.ca by sis.yorku.ca (4.1/SMI-4.1) id AA07530; Wed, 10 Mar 93 12:02:46 EST Message-Id: <9303101702.AA07530@sis.yorku.ca> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: huh? In-Reply-To: Your message of "Wed, 10 Mar 93 08:53:29 PST." <9303101653.AA04978@utopia.mv.us.adobe.com> Date: Wed, 10 Mar 1993 12:02:45 -0500 From: "Ozan S. Yigit" > i believe the difference is that ``x'' without a pattern > immediately following it uses an implicit /^.*\n/ Ah, now I found it in page 8 of the tutorial. Grumble, all this time, I have been using it without this shorthand. It goes to show that one must always read Bell Labs tutorials with care. ;-) oz --- We only know... what we know, and | email: oz@sis.yorku.ca that is very little. --Dan Rather | ph:416 736 2100 x33976 From sam-fans-owner Wed Mar 10 14:46:14 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2789>; Wed, 10 Mar 1993 14:45:52 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2539>; Wed, 10 Mar 1993 14:44:36 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: huh? Date: Wed, 10 Mar 1993 14:44:04 -0500 From: Scott Schwartz Message-Id: <93Mar10.144436est.2539@groucho.cs.psu.edu> > i believe the difference is that ``x'' without a pattern > immediately following it uses an implicit /^.*\n/ That convention is somewhat inconsistent, since spaces are ignored elsewhere. Now that @ is no longer used for fat-dot, maybe it could be used instead. I.e. use ``x@'' instead of ``x '', to mean x/^.*\n/ and ignore spaces between tokens. From sam-fans-owner Fri Mar 12 12:23:11 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2793>; Fri, 12 Mar 1993 12:21:43 -0500 From: bobf@research.att.com Date: Fri, 12 Mar 1993 11:57:46 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Mar12.122143est.2793@hawkwind.utcs.toronto.edu> A new version of sam is available in dist/sam on research.att.com. It contains many bug fixes and a new facility allowing commands to be injected into a running sam from an external source. I trust the readers of this list will give it their customary stress test and report anomalies to me. Thanks to those of you who have contributed code or testing to this release; I hope the acknowledgements in the README file have not inadvertantly missed anyone. From sam-fans-owner Fri Mar 12 15:25:07 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2795>; Fri, 12 Mar 1993 15:24:46 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2539>; Fri, 12 Mar 1993 15:23:22 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Subject: tmpfs strikes again In-reply-to: Your message of "Fri, 12 Mar 1993 11:57:46 EST." <93Mar12.122143est.2793@hawkwind.utcs.toronto.edu> Date: Fri, 12 Mar 1993 15:22:42 -0500 From: Scott Schwartz Message-Id: <93Mar12.152322est.2539@groucho.cs.psu.edu> The new pipe-to-sam feature is interesting. Unfortunately users of Byron Rakitzis' rc (yay!) who also use SunOS tmpfs (boo!) will revisit the old tmpfs-fifo problem: fifo's don't always work in tmpfs (depending on open mode or something) and that's where sam puts one. As a workaround, the changes in samterm/unix.c to put the fifo in /usr/tmp instead are obvious. From sam-fans-owner Fri Mar 12 15:34:27 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2800>; Fri, 12 Mar 1993 15:34:14 -0500 From: bobf@research.att.com Date: Fri, 12 Mar 1993 15:26:58 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Mar12.153414est.2800@hawkwind.utcs.toronto.edu> re: B command in Boyd's original implmentation the pipe was in the home directory, but i moved to /tmp to prevent network accesses on the pipe and to have it automatically removed after a system or program crash. scott's observation confirms my experience: the location of the named pipe is site-dependent. i'll update the README file accordingly. of course, in plan 9 we avoid the problem completely: by convention the pipe is placed in a convenient place in the namespace. From sam-fans-owner Mon Mar 15 09:37:07 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2793>; Mon, 15 Mar 1993 09:36:20 -0500 Received: by ux2.cso.uiuc.edu id AA26564 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 15 Mar 1993 08:36:06 -0600 Date: Mon, 15 Mar 1993 09:36:06 -0500 From: Ed Kubaitis - CCSO Message-Id: <199303151436.AA26564@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: HPUX mods for 3/12/93 sam Attached are patches for 3/12 sam on HPUX 8.07. Ed =============================================================================== *** libXg/gwin.c- Mon Mar 15 07:06:06 1993 --- libXg/gwin.c Mon Mar 15 07:18:06 1993 *************** *** 1,6 **** /* Copyright (c) 1992 AT&T - All rights reserved. */ #include ! #ifdef v10 typedef char* caddr_t; #endif #include --- 1,6 ---- /* Copyright (c) 1992 AT&T - All rights reserved. */ #include ! #if defined(v10) || defined(HPUX) typedef char* caddr_t; #endif #include *** sam/B.sh- Mon Mar 15 07:05:22 1993 --- sam/B.sh Mon Mar 15 08:19:31 1993 *************** *** 9,14 **** --- 9,17 ---- fi dir=`/bin/pwd` + if [ "$USER" = "" ]; then + USER=$LOGNAME + fi pipe=/tmp/.sam.$USER if [ $DISPLAY != "" ]; then *** samterm/unix.c- Mon Mar 15 07:05:57 1993 --- samterm/unix.c Mon Mar 15 08:23:37 1993 *************** *** 15,20 **** --- 15,25 ---- #define S_IFIFO _IFIFO #endif + #ifdef HPUX + #define S_IFMT _S_IFMT + #define S_IFIFO _S_IFIFO + #endif + #if defined(UMIPS) || defined(SUNOS) #define atexit(p) /* sigh */ #endif From sam-fans-owner Mon Mar 15 11:32:01 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2800>; Mon, 15 Mar 1993 11:31:45 -0500 Received: by ux2.cso.uiuc.edu id AA61475 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 15 Mar 1993 10:31:22 -0600 Date: Mon, 15 Mar 1993 11:31:22 -0500 From: Ed Kubaitis - CCSO Message-Id: <199303151631.AA61475@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: AIX mods for 3/12/93 sam Attached is one small patch for compiling 3/12 sam on AIX 3.2. It seems both AIX and HPUX only define these symbols under -D_XOPEN_SOURCE. But using that flag in the Makefiles led to other problems. Ed =============================================================================== *** samterm/unix.c- Mon Mar 15 08:49:25 1993 --- samterm/unix.c Mon Mar 15 09:56:47 1993 *************** *** 15,20 **** --- 15,25 ---- #define S_IFIFO _IFIFO #endif + #ifdef AIX + #define S_IFMT _S_IFMT + #define S_IFIFO _S_IFIFO + #endif + #if defined(UMIPS) || defined(SUNOS) #define atexit(p) /* sigh */ #endif From sam-fans-owner Mon Mar 15 12:14:12 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2793>; Mon, 15 Mar 1993 12:14:05 -0500 Received: by ux2.cso.uiuc.edu id AA30350 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 15 Mar 1993 11:14:02 -0600 Date: Mon, 15 Mar 1993 12:14:02 -0500 From: Ed Kubaitis - CCSO Message-Id: <199303151714.AA30350@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Apollo mods for 3/12/93 sam *** samterm/unix.c- Mon Mar 15 10:41:45 1993 --- samterm/unix.c Mon Mar 15 11:07:19 1993 *************** *** 15,20 **** --- 15,26 ---- #define S_IFIFO _IFIFO #endif + #ifdef APOLLO + #define S_IFMT __S_IFMT + #define S_IFIFO __S_IFIFO + #define O_NONBLOCK O_NDELAY + #endif + #if defined(UMIPS) || defined(SUNOS) #define atexit(p) /* sigh */ #endif From sam-fans-owner Mon Mar 15 14:27:37 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2801>; Mon, 15 Mar 1993 14:27:22 -0500 Received: by ux2.cso.uiuc.edu id AA31323 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 15 Mar 1993 13:27:07 -0600 Date: Mon, 15 Mar 1993 14:27:07 -0500 From: Ed Kubaitis - CCSO Message-Id: <199303151927.AA31323@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Convex & Dynix mods for 3/12/93 sam 3/12 sam on ConvexOS 10.1 only needed the suggested alternative for tempnam() in the comments for sam/unix.c:newtmp(). The latin1.c change mentioned in the README for Convex 9.1 is not necessary. Sequent Dynix 3 is a much sadder case. It compiled with a couple defs in samterm/unix.c for O_NONBLOCK and atexeit(). But samterm hung with its window unresponsive to mouse or keyboard. I think the problem is Dynix 3 (according to the fcntl(2) man page) only supports non-blocking I/O for tty's, not named pipes or sockets. Hard coding a 'return;' at the beginning of samterm/unix.c:exstart(), got rid of the hang, but at the cost of tossing the main 3/12 feature overboard. Sigh. Ed From sam-fans-owner Tue Mar 16 15:05:07 1993 Received: from nexus.yorku.ca ([130.63.9.66]) by hawkwind.utcs.toronto.edu with SMTP id <2789>; Tue, 16 Mar 1993 15:04:05 -0500 Received: from ursa.sis.yorku.ca ([130.63.245.12]) by nexus.yorku.ca with SMTP id <9225>; Tue, 16 Mar 1993 15:00:44 -0500 Received: from localhost.yorku.ca by sis.yorku.ca (4.1/SMI-4.1) id AA25626; Tue, 16 Mar 93 14:57:15 EST Message-Id: <9303161957.AA25626@sis.yorku.ca> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: huh? Date: Tue, 16 Mar 1993 14:57:14 -0500 From: "Ozan S. Yigit" Scott Schwartz wrote: > > i believe the difference is that ``x'' without a pattern > > immediately following it uses an implicit /^.*\n/ > > That convention is somewhat inconsistent, since spaces are ignored > elsewhere. Now that @ is no longer used for fat-dot, maybe it could be > used instead. I.e. use ``x@'' instead of ``x '', to mean x/^.*\n/ > and ignore spaces between tokens. I note "l" (for "line") is unused: [addr]x -> [addr]l ?? oz From sam-fans-owner Wed Mar 17 12:59:56 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2408>; Wed, 17 Mar 1993 12:59:25 -0500 Received: by ux2.cso.uiuc.edu id AA13269 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Wed, 17 Mar 1993 11:59:12 -0600 Date: Wed, 17 Mar 1993 12:59:12 -0500 From: Ed Kubaitis - CCSO Message-Id: <199303171759.AA13269@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: scripts using 3/12 sam command pipe? Here's a pretty obvious one. Anyone else have one to share? Ed =============================================================================== #! /usr/local/bin/perl # # samtag - generate Sam commands from ctags(1) tags file # # usage: !samtag tag -OR- (select-tag-with-mouse) # >samtag $user = $ENV{'USER'}; $user = $ENV{'LOGNAME'} unless $user; $user || die "samtag: no USER or LOGNAME environment variable.\n"; $pipe = ".sam.$user"; $pipe .= ".$ENV{'DISPLAY'}" if $ENV{'DISPLAY'}; $Pipe = "/tmp/$pipe"; $Pipe = "/usr/tmp/$pipe" unless -p $Pipe; -p $Pipe || die "samtag: no sam pipe($pipe) in /tmp or /usr/tmp\n"; $Tag = shift; $Tag = unless $Tag; die "samtag: no tag specified." unless $Tag; open(Tags, "tags") || die "samtag: tags: $!\n"; while() { /^([^\t]+)\t([^\t]+)\t(.+)$/; $tag = $1; $file =$2; $re =$3; last if $tag eq $Tag } die "samtag: tag <$Tag> not found.\n" unless $tag eq $Tag; $re =~ s/([()*[\]])/\\$1/g; # escape metacharacters in re open(Pipe, ">$Pipe") || die "samtag: $Pipe: $!\n"; print Pipe "B $file\n$re\n"; close(Pipe); From sam-fans-owner Wed Mar 17 13:28:56 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu with SMTP id <2664>; Wed, 17 Mar 1993 13:28:40 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA06028; Wed, 17 Mar 93 13:28:25 -0500 Received: by earth.osf.org (5.65/4.7) id AA06894; Wed, 17 Mar 93 13:28:23 -0500 Date: Wed, 17 Mar 1993 13:28:23 -0500 From: rsalz@osf.org Message-Id: <9303171828.AA06894@earth.osf.org> To: ejk@ux2.cso.uiuc.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: scripts using 3/12 sam command pipe? I had a test copy of Boyd's stuff and have been using this for a while. Similar but written in rc (uses look and sed). You'll have to edit the "sp=" line ... It is probably just that I haven't been able to really wrap my mind around structural R.E.'s all that much, but find that I am not using them all that much. I use the multi-file aspect all the time; it is my primary reason for using sam. As a result, I am often writing little shell snippets like this: for (i in stderr stdout nolog console) { echo 'X/./ ,g/svc_c_' ^ $i ^ '/ {' echo ',x/svc_c_' ^ $i ^ '/ x/svc_c_/ a/route_/' echo '}' } >>$h/.sam.rsalz Actually, I often write those snippets in an "unnamed" window, select them, and then do ">rc >$sp" where sp is an envvar naming the sam pipe. /r$ #! /bin/rc ## Output a series of commands that will make same go to the tag named on ## the command line. If no argument, use the word in the current X ## selection. The best way to get the selection is to install xcb; available ## as contrib/xcb-2.1.tar.Z on export.lcs.mit.edu. ## Useful variables ~ $#tagspath 0 && tagspath = (. .. /usr/lib/tags) nl = ' ' tab=' ' cat=() ## Print usage message and exit. fn usage { echo Usage: $0 '[-o] [-i | tag]' >[1=2] exit 1 } ## Parse flags. while ( ! ~ $#* 0 ) { switch ( $1 ) { case -i ! ~ $#function 0 && usage function = `` ($nl) {sed 1q} case -o cat=cat case -* usage case * ! ~ $#function 0 && usage function = $1 } shift } ## Sending to sam? ~ $#cat 0 && { ~ $#sp 0 && { sp=$home/.sam.$USER ! ~ $#DISPLAY 0 && sp=$sp.$DISPLAY } test -r $sp || { echo 'No sam fifo' >[1=2] usage } cat='cat >$sp' } ## Get the current X selection. ~ $#function 0 && function = `{xcb -p 0} function = $function ^ $tab for (dir in $tagspath) test -f $dir ^ /tags && { line = `` ($nl) { look $function $dir ^ /tags ; echo $status } ~ $#line 2 && ~ $line(2) 0 && { { * = `` ($tab $nl) { echo $line(1) } if ( ~ $dir . || ~ $2 /* ) { echo B $2 ^ $nl ^ b $2 } else { echo B $dir ^ '/' ^ $2 ^ $nl ^ b $dir ^ '/' ^ $2 } shift ; shift { echo -n $1 while (shift && ! ~ $#* 0) echo -n $tab ^ $1 echo } | sed -e 's/\[/\\[/g' \ -e 's/[].+?|()*$^]/\\&/g' \ -e 's/\/\\\^/\/\^/' \ -e 's/\\\$\/$/\$\//' \ -e 's/ / +/g' } | eval $cat exit 0 } } exit 1 From sam-fans-owner Fri Mar 26 00:06:12 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2712>; Fri, 26 Mar 1993 00:05:21 -0500 To: sam-fans Subject: trap #2 for compiling sam on a DEC OSF/1 Alpha Date: Fri, 26 Mar 1993 00:05:14 -0500 From: Chris Siebenmann Message-Id: <93Mar26.000521est.2712@hawkwind.utcs.toronto.edu> shorts and ushorts are the traditional 2 bytes, so a Block is 4 bytes long, which breaks the assumptions behind stuffing Blocks into lists. This is going to be ugly to fix in a general way, no doubt; I punted and stuck an '#ifdef __alpha' into sam.h, since I wanted to get it running (I dislike vi and my ed is rusty). Oh, and the Etmpovfl check in bkalloc() (disc.c) seems to need to use '1l<<' instead of '1<<' if you increase the size of things in a Block instead of just padding it. - cks From sam-fans-owner Sat Mar 27 17:23:22 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2746>; Sat, 27 Mar 1993 17:14:39 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2539>; Sat, 27 Mar 1993 17:12:59 -0500 To: Sam Fans Subject: 9fans? Date: Sat, 27 Mar 1993 17:12:08 -0500 From: Scott Schwartz Message-Id: <93Mar27.171259est.2539@groucho.cs.psu.edu> Now that plan9 has shipped, has anyone thought about a 9fans mailing list? From sam-fans-owner Sat Mar 27 20:00:06 1993 Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by hawkwind.utcs.toronto.edu with SMTP id <2749>; Sat, 27 Mar 1993 19:54:23 -0500 Received: from mystix.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP id AA02352 (5.65/IDA-1.4.2 for sam-fans@hawkwind.utcs.toronto.edu); Sat, 27 Mar 93 16:53:33 -0800 Received: from localhost.cs.uoregon.edu by mystix.cs.uoregon.edu (4.1/UofO CS 27-Mar-91) id AA01929; Sat, 27 Mar 93 16:53:28 PST Message-Id: <9303280053.AA01929@mystix.cs.uoregon.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9fans? Date: Sat, 27 Mar 1993 19:53:27 -0500 From: mike@mystix.cs.uoregon.edu I'd be interested in such a mailing list. I at least have had some, er, "exciting" times setting up Plan 9. The CS department cannot afford to dedicate a machine as a full time Plan 9 file server. Thus I've been running the terminal kernels off the Unix based file server u9fs. The version of u9fs that was distributed has lots of deficiencies (it doesn't even fully implement Plan 9 file system semantics), which I've been gradually correcting. In the long run I'm either going to have to write a completely new file server, or talk the department into dedicating a couple of machines to run the Plan 9 file server and CPU server kernels. Right now I can use Plan 9 quite comfortably, but non-experts would quickly get hopelessly stuck. I would be very interested in hearing about other peoples' experiences. Rob, if you're reading this, two simple improvements to u9fs that you can easily make are: 1) set the Qid version from the file's mtime this makes executable caching do the right thing when you recompile something 2) honor the ORCLOSE open flag then temp files created by, e.g., sam, go away properly. From sam-fans-owner Wed Mar 31 15:23:42 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <2724>; Wed, 31 Mar 1993 15:22:32 -0500 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA12048 (5.65c/IDA-1.4.4 for ); Wed, 31 Mar 1993 15:22:06 -0500 Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA01237; Wed, 31 Mar 93 15:21:57 EST From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9303312021.AA01237@penfold.cc.gatech.edu> Date: Wed, 31 Mar 1993 15:21:57 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam windows I admit to being very much a sam novice, but am really coming to like this editor. That said, has anyone looked into making it possible to have sam's various windows be full blown X windows? I'd like to do the multi-file editing stuff, but be able to place the windows wherever I want on the screen, and not have them limited to being within the larger sam background window. Is there a major design reason I'm overlooking, or is the current behaviour just a side-effect of the X implementation (which I suspect it is)? Much thanks, Arnold Robbins --- College of Computing Georgia Tech, Atlanta, GA 30332-0280 Phone: +1 404 894 9214 E-mail: arnold.robbins@cc.gatech.edu FAX: +1 404 853 9378 "He's not dead, he's metaphysically challenged." - Mystery Science Theatre 3000 From sam-fans-owner Wed Mar 31 18:52:13 1993 Received: from alpha.xerox.com ([13.1.64.93]) by hawkwind.utcs.toronto.edu with SMTP id <2735>; Wed, 31 Mar 1993 18:52:02 -0500 Received: from NightTrain.wbst129.xerox.xns by alpha.xerox.com via XNS id <11928>; Wed, 31 Mar 1993 15:51:29 PST X-NS-Transport-ID: 0000AA0081442A9C2F5F Date: Wed, 31 Mar 1993 18:51:22 -0500 From: Marc_Rocas.Wbst129@xerox.com Subject: Extensions to Sam and is this mailing list archived? To: sam-fans@hawkwind.utcs.toronto.edu Reply-to: Marc_Rocas.Wbst129@xerox.com Message-ID: <"31-Mar-93 18:51:22 EST".*.Marc_Rocas.Wbst129@Xerox.com> Received: by gizmo.wbst129.xerox.COM (4.1/SMI-4.0) id AA04461; Wed, 31 Mar 93 18:51:14 EST Hi, I was wondering if this mailing list is archived anywhere and secondly, whether Ed Kubaitis' extension to samterm is the only one of its kind. Thanks in advance for your time. --Marc From sam-fans-owner Wed Mar 31 20:10:34 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2724>; Wed, 31 Mar 1993 20:10:15 -0500 To: sam-fans Subject: Re: Extensions to Sam and is this mailing list archived? In-reply-to: Marc_Rocas.Wbst129's message of Wed, 31 Mar 93 18:51:22 -0500. <"31-Mar-93 18:51:22 EST".*.Marc_Rocas.Wbst129@Xerox.com> Date: Wed, 31 Mar 1993 20:10:14 -0500 From: Chris Siebenmann Message-Id: <93Mar31.201015est.2724@hawkwind.utcs.toronto.edu> The sam-fans traffic to date can be ftp'd from ftp.sys.utoronto.ca as /pub/sam/sam-fans-list. - cks From sam-fans-owner Thu Apr 8 15:34:34 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2738>; Thu, 8 Apr 1993 15:33:32 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Thu, 8 Apr 1993 15:32:01 -0400 To: Sam Fans Subject: plan9-fans Date: Thu, 8 Apr 1993 15:31:25 -0400 From: Scott Schwartz Message-Id: <93Apr8.153201edt.2538@groucho.cs.psu.edu> I asked the keepers of psuvax1 if we could set up the plan9-fans mailing list there, and they agreed. Actually, they asked me why Bell Labs didn't do it, and since I didn't have a good answer to that, I was appointed list maintainer. :-) So anyway, I have about O(1) cycles to spare for this, but if people send mail to , we can get the thing slowly rolling. -- Scott From sam-fans-owner Mon Apr 12 14:15:43 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu with SMTP id <2752>; Mon, 12 Apr 1993 14:15:13 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA24533; Mon, 12 Apr 93 14:15:09 -0400 Received: by earth.osf.org (5.65/4.7) id AA00709; Mon, 12 Apr 93 14:15:08 -0400 Date: Mon, 12 Apr 1993 14:15:08 -0400 From: rsalz@osf.org Message-Id: <9304121815.AA00709@earth.osf.org> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Synchronous editing? I use Boyd's remote-command part of sam (i.e., the named pipe) a lot. I'd like to write a small "editor" that is really a shell script that calls the B script to ship the file to sam. How do I tell the "editor" that I'm done editing? I can only think of doing something like this: #! /bin/sh B $1 echo "Type return when done: " | tr -d '\012' read LINE exit (Shown via sh rather than rc for pedagogy :-) Any other suggestions? /r$ From sam-fans-owner Mon Apr 12 20:17:17 1993 Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by hawkwind.utcs.toronto.edu with SMTP id <2755>; Mon, 12 Apr 1993 20:17:00 -0400 Received: from atlantix.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP id AA27428 (5.65/IDA-1.4.2 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 12 Apr 93 17:16:44 -0700 Date: Mon, 12 Apr 1993 20:16:44 -0400 From: Michael John Haertel Message-Id: <9304130016.AA27428@skinner.cs.uoregon.edu> To: sam-fans@hawkwind.utcs.toronto.edu rsalz wrote: >How do I >tell the "editor" that I'm done editing? This is the best solution I've come up with. #! /bin/sh B $1 waitforchanges $1 where "waitforchanges" is the following small C program: #include #include main(int argc, char *argv[]) { struct stat ost, nst; if (argc != 2) exit(1); if (stat(argv[1], &ost) < 0) exit(1); for (;;) { sleep(3); if (stat(argv[1], &nst) < 0) exit(1); if (nst.st_mtime != ost.st_mtime) break; } exit(0); } From sam-fans-owner Mon Apr 12 20:40:50 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2755>; Mon, 12 Apr 1993 20:40:37 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA18030; Mon, 12 Apr 93 17:40:43 PDT Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA01842; Mon, 12 Apr 93 17:32:37 PDT Date: Mon, 12 Apr 1993 20:32:37 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9304130032.AA01842@netapp.netapp.com> To: mike@skinner.cs.uoregon.edu, sam-fans@hawkwind.utcs.toronto.edu This doesn't work if you compulsively write out dirty files in the middle of an edit session. (I don't think I'm the only one who does this.) What's the real problem? That sam doesn't start up fast enough for a true synchonous edit? I have my sam dimensions and coordinates predefined so that a new sam pops up in the same location every time. The only problem I have is that a new sam takes too long to start up. I suspect this is partly sam's design (2 processes need to run instead of 1) and general Unix and X11 bloat. In general I don't use B because I want to associate a particular directory with each instance of sam. Ideally sam would just take over the terminal window in which it is invoked, but I think it would take a different window system for that to happen. From sam-fans-owner Mon Apr 12 20:43:20 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Mon, 12 Apr 1993 20:43:13 -0400 Received: by mod.civil.su.oz.au id <28713>; Tue, 13 Apr 1993 10:42:42 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Mon, 12 Apr 1993 20:36:14 -0400 To: Sam Fans Subject: sam as a synchronous thing In-Reply-To: <9304130016.AA27428@skinner.cs.uoregon.edu> Message-ID: <199304131036.1127.sam.badil@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ waitforchanges $1 Danger, Will Robinson! Seriously, that will work in some sense but I think there are some problems with it. Clearly, that commits you to saying your $EDITOR finishes the instant you write your changes out. I have what I think is a good habit of writing out changes to files at random times while I'm editing. This will totally discourage people developing that habit, and that means they're all the more likely to lose their editing if something goes bad. Yes, we do have sam.save, but sam doesn't always get a chance to do that. I think that no matter what editor you're using, writing out your file frequently is a good habit to have, and one that shouldn't be discouraged. I have some ideas for other solutions which I will send mail about when I have thought over them some more. They're not solid enough to send out yet. OK, John. From sam-fans-owner Mon Apr 12 20:54:05 1993 Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by hawkwind.utcs.toronto.edu with SMTP id <2755>; Mon, 12 Apr 1993 20:53:53 -0400 Received: from majestix.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP id AA27661 (5.65/IDA-1.4.2 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 12 Apr 93 17:53:37 -0700 Date: Mon, 12 Apr 1993 20:53:37 -0400 From: Michael John Haertel Message-Id: <9304130053.AA27661@skinner.cs.uoregon.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: "B" synchronous Several people have observed that my simple solution does not work for people who compulsively write out their changes. It all boils down to what you want to do with synchronous "B". If it's just quick and dirty mail replies, I think my solution is fine. If you want to call the sam for long haul jobs there are are some other problems with "B", as Byron observed. My usage pattern under Plan 9 is, in fact, precisely what he suggests: I start a new sam up in whatever window I happen to be working in, and so it just naturally gets the correct current directory. The X design, where each program you start creates a new window, gets in the way of this style. I don't know a good solution. It might be possible to write a hack that figures out the geometry of your current window and passes it as an argument to sam... From sam-fans-owner Tue Apr 13 10:39:35 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu with SMTP id <2752>; Tue, 13 Apr 1993 10:39:18 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA00532; Tue, 13 Apr 93 10:39:03 -0400 Received: by earth.osf.org (5.65/4.7) id AA04387; Tue, 13 Apr 93 10:39:02 -0400 Date: Tue, 13 Apr 1993 10:39:02 -0400 From: rsalz@osf.org Message-Id: <9304131439.AA04387@earth.osf.org> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Naming the pipe I think the following patch to samterm/unix.c is a good idea. It allows the environment variable $sampipe, if set, to specify the name of the fifo. *** unix.c.save Tue Apr 13 10:31:46 1993 --- unix.c Tue Apr 13 10:33:25 1993 *************** *** 70,84 **** int fd; int flags; ! user = getuser(); ! disp = getenv("DISPLAY"); ! if (disp) { ! exname = (char *)alloc(4 + 6 + strlen(user) + 1 + strlen(disp) + 1); ! sprint(exname, "/tmp/.sam.%s.%s", user, disp); ! } else { ! exname = (char *)alloc(4 + 6 + strlen(user) + 1); ! sprint(exname, "/tmp/.sam.%s", user); } /* Make the named pipe. Multiple sams with the same user/display share the same pipe */ --- 70,90 ---- int fd; int flags; ! disp = getenv("sampipe"); ! if (disp == 0) { ! user = getuser(); ! disp = getenv("DISPLAY"); ! if (disp) { ! exname = (char *)alloc(4 + 6 + strlen(user) + 1 + strlen(disp) + 1); ! sprint(exname, "/tmp/.sam.%s.%s", user, disp); ! } else { ! exname = (char *)alloc(4 + 6 + strlen(user) + 1); ! sprint(exname, "/tmp/.sam.%s", user); ! } ! } else { ! exname = (char *)alloc(strlen(disp) + 1); ! strcpy(exname, disp); } /* Make the named pipe. Multiple sams with the same user/display share the same pipe */ From sam-fans-owner Sat Apr 17 14:00:33 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2751>; Sat, 17 Apr 1993 14:00:01 -0400 Received: by ux2.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA34369; Sat, 17 Apr 1993 12:59:43 -0500 Date: Sat, 17 Apr 1993 13:59:43 -0400 From: ejk@ux2.cso.uiuc.edu (Ed Kubaitis - CCSO) Message-Id: <9304171759.AA34369@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam extensions version 2 On uxc.cso.uiuc.edu in pub/sam/samx2.shar.Z. The materials apply to the 3/12/93 Unix/X11 sam from research.att.com. Bug fixes plus: o Tags, block indent, text justify, case change (perl scripts and key mappings) o Option to preserve context when command window scrolls o Autoscroll for Samkeys up/down and new left/right word actions o Samkeys actions for keyboard text select o ISO 8859-1 (Central European - Latin1) display and composition o Support for precompiled Samkeys files o Patches for minor 3/12/93 sam build problems on HP-UX, AIX, Apollo Domain, Convex, and Sequent Dynix. Also, makefiles and patch for Sequent PTX V2.0.3. Ed From sam-fans-owner Sun Apr 25 13:14:37 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2774>; Sun, 25 Apr 1993 13:14:06 -0400 Received: by ux2.cso.uiuc.edu id AA64824 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Sun, 25 Apr 1993 12:13:48 -0500 Date: Sun, 25 Apr 1993 13:13:48 -0400 From: Ed Kubaitis - CCSO Message-Id: <199304251713.AA64824@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: substitute delimited words Here's a script that uses the sam command pipe to save keystrokes when substituting delimited words. Ed ============================================================================== #! /usr/local/bin/perl # # sam_sw - generate sam command to substitute delimited words # # usage: !sam_sw [-X] [-,] from to while($_ = $ARGV[0], /^-/) { shift; if (m!^-X$!) { $XFlag++; $CommaFlag++; } elsif (m!^-,$!) { $CommaFlag++; } else { &usage; } } ($from,$to, @toomany) = @ARGV; &usage if @toomany || !$from || !$to; $command = "X " if $XFlag; $command .= "," if $CommaFlag; $from =~ s/([()*[\]\\^\$+?!])/\\$1/g; # escape meta characters $to =~ s/([()*[\]\\^\$+?!])/\\$1/g; $command .= "s!(^|[^A-Za-z0-9_])$from(\$|[^A-Za-z0-9_])!\\1$to\\2!g\n"; &sampipe($command); sub sampipe { local($commands) = @_; $user = $ENV{'USER'}; $user = $ENV{'LOGNAME'} unless $user; $user || die "$0: no USER or LOGNAME environment variable.\n"; $pipe = ".sam.$user"; $pipe .= ".$ENV{'DISPLAY'}" if $ENV{'DISPLAY'}; $Pipe = "/tmp/$pipe"; $Pipe = "/usr/tmp/$pipe" unless -p $Pipe; -p $Pipe || die "$0: no sam pipe($pipe) in /tmp or /usr/tmp\n"; open(Pipe, ">$Pipe") || die "$0: $Pipe: $!\n"; print Pipe "$commands"; close(Pipe); } sub usage { die "usage: !sam_sw [-X] [-,] from to\n"; } From sam-fans-owner Tue Apr 27 14:19:32 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2776>; Tue, 27 Apr 1993 14:18:00 -0400 Received: by ux2.cso.uiuc.edu id AA44973 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Tue, 27 Apr 1993 13:17:53 -0500 Date: Tue, 27 Apr 1993 14:17:53 -0400 From: Ed Kubaitis - CCSO Message-Id: <199304271817.AA44973@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Samterm coredumps on AIX Samterm built with AIX xlc V1.2.1 (distributed with AIX 3.2.3) coredumps during startup. Problem is miscompiled conditional expression in the second call to border() in samterm/flayer.c:flborder(). Fix is to upgrade to the latest version of xlc (V1.2.1.4). Or, compile samterm/flayer.c (at least) with -O. In man-bites-dog fashion, it's a *no*-optimizer bug. Ed From sam-fans-owner Mon May 24 14:49:51 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Mon, 24 May 1993 14:49:05 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2580>; Mon, 24 May 1993 14:47:33 -0400 To: Sam Fans Subject: quit with modified files Date: Mon, 24 May 1993 14:48:36 -0400 From: Scott Schwartz Message-Id: <93May24.144733edt.2580@groucho.cs.psu.edu> Is this a bug? ; sam -d B /etc/fstab -. /etc/fstab i a b c . B /etc/motd -. /etc/motd n - '- /etc/fstab -. /etc/motd q ; From sam-fans-owner Mon May 24 16:31:22 1993 Received: from p.lanl.gov ([128.165.4.4]) by hawkwind.utcs.toronto.edu with SMTP id <2688>; Mon, 24 May 1993 16:31:02 -0400 Received: from raptor.lanl.gov by p.lanl.gov (5.65/1.14) id AA08834; Mon, 24 May 93 14:30:45 -0600 Received: by raptor.lanl.gov.t13net (4.1/SMI-4.1) id AA05982; Mon, 24 May 93 14:30:52 MDT Date: Mon, 24 May 1993 16:30:52 -0400 From: ronnie@raptor.lanl.gov (Ronnie Mainieri) Message-Id: <9305242030.AA05982@raptor.lanl.gov.t13net> To: sam-fans@hawkwind.utcs.toronto.edu Subject: changes not in sequence Dear Sam fans, I'm still a little confused about the ``?changes not in sequence'' error message. Is it that I'm not allowed to modify text that has just been modified? My vi instincts frequently lead me to this error message, and I can't see what I'm doing wrong. Could someone post an explanation of the modifications that lead to this error message? Thanks for the help, Ronnie Mainieri ronnie@raptor.lanl.gov From sam-fans-owner Tue May 25 19:08:32 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2688>; Tue, 25 May 1993 19:07:41 -0400 To: Sam Fans Subject: Re: quit with modified files In-reply-to: schwartz's message of Mon, 24 May 93 14:48:36 -0400. <93May24.144733edt.2580@groucho.cs.psu.edu> Date: Tue, 25 May 1993 19:07:35 -0400 From: Chris Siebenmann Message-Id: <93May25.190741edt.2688@hawkwind.utcs.toronto.edu> It's a bug. It happens if you call in a clean file and immediately try to quit; edit() in sam/sam.c doesn't set the global dirty file state quite right. I've attached a patch. - cks *** /tmp/,RCSt1a04954 Tue May 25 19:05:06 1993 --- sam/sam.c Tue May 25 18:47:16 1993 *************** *** 331,337 **** f->ndot.r.p1 = addr.r.p2, f->ndot.r.p2 = addr.r.p2+p; else f->ndot.r.p1 = f->ndot.r.p2 = 0; ! quitok = f->closeok = empty; state(f, empty && !nulls? Clean : Dirty); if(cmd == 'e') filename(f); --- 331,337 ---- f->ndot.r.p1 = addr.r.p2, f->ndot.r.p2 = addr.r.p2+p; else f->ndot.r.p1 = f->ndot.r.p2 = 0; ! quitok = quitok ? (f->closeok = empty) : FALSE; state(f, empty && !nulls? Clean : Dirty); if(cmd == 'e') filename(f); From sam-fans-owner Tue May 25 23:49:32 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Tue, 25 May 1993 23:49:19 -0400 From: rob@research.att.com Date: Tue, 25 May 1993 23:48:47 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Subject: changes not in sequence Message-Id: <93May25.234919edt.2714@hawkwind.utcs.toronto.edu> rhubarb rhubarb. it's just a bug that i never saw my way through to fix. what the message means is that you've generated a list of changes to be made atomically that don't occur in increasing non-overlapping addresses in the file. this is hard to do unless you put addresses inside commands, e.g. x/./ -d this particular example is an error - it will delete the same line many times - but there are more complex examples that should work but don't. the bug should be easy to fix, but it's not. in principle, you (that is, i) just sort the transcript list and execute it in order. (if the changes occur out of order, the address arithmetic in the update routine will screw up.) the problem is that, for vital efficiency, nearby changes are folded together so many small adjacent modifications can be done in one disk i/o (say), which makes it impossible to keep them separate in order to be able to sort them. hence the message. i always intended to fix the problem; i never saw how. i have a whole new system now that contains much more efficient code to do all this stuff, obviating the need for the extra level of cache and hence making it possible to sort the changes (as in fact i do in this new system). the code could be retrofitted but it's a huge job and i think my time and others' is better spent on other things, such as getting this new system working. apologies. -rob From sam-fans-owner Wed May 26 00:30:43 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2714>; Wed, 26 May 1993 00:30:30 -0400 To: sam-fans Subject: Re: quit with modified files Date: Wed, 26 May 1993 00:30:27 -0400 From: Chris Siebenmann Message-Id: <93May26.003030edt.2714@hawkwind.utcs.toronto.edu> Scott Schwartz kindly pointed out that my patch had a small bug. Please discard it and use this one instead: *** /tmp/,RCSt1a13201 Wed May 26 00:22:53 1993 --- sam/sam.c Wed May 26 00:10:47 1993 *************** *** 331,337 **** f->ndot.r.p1 = addr.r.p2, f->ndot.r.p2 = addr.r.p2+p; else f->ndot.r.p1 = f->ndot.r.p2 = 0; ! quitok = f->closeok = empty; state(f, empty && !nulls? Clean : Dirty); if(cmd == 'e') filename(f); --- 331,338 ---- f->ndot.r.p1 = addr.r.p2, f->ndot.r.p2 = addr.r.p2+p; else f->ndot.r.p1 = f->ndot.r.p2 = 0; ! f->closeok = empty; ! quitok = quitok ? f->closeok : FALSE; state(f, empty && !nulls? Clean : Dirty); if(cmd == 'e') filename(f); - cks From sam-fans-owner Wed May 26 16:21:30 1993 Received: from nexus.yorku.ca ([130.63.9.66]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Wed, 26 May 1993 16:21:08 -0400 Received: from ursa.sis.yorku.ca ([130.63.245.12]) by nexus.yorku.ca with SMTP id <9218>; Wed, 26 May 1993 16:20:48 -0400 Received: from localhost.yorku.ca by sis.yorku.ca (4.1/SMI-4.1) id AA13783; Wed, 26 May 93 16:18:37 EDT Message-Id: <9305262018.AA13783@sis.yorku.ca> To: rob@research.att.com Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: changes not in sequence In-Reply-To: Your message of "Tue, 25 May 93 23:48:47 EDT." <93May25.234919edt.2714@hawkwind.utcs.toronto.edu> Date: Wed, 26 May 1993 16:18:37 -0400 From: "Ozan S. Yigit" > i have a whole new system now that contains much more efficient code > to do all this stuff, obviating the need for the extra level of cache > and hence making it possible to sort the changes (as in fact i do in > this new system). the code could be retrofitted but it's a huge job ... are there any other improvements in the new system we can borrow for sam? the message protocol between the term and the editor proper? any new commands and/or interface ideas? oz From sam-fans-owner Wed May 26 20:22:03 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2706>; Wed, 26 May 1993 20:21:52 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2620>; Wed, 26 May 1993 20:20:13 -0400 To: Sam Fans Subject: Re: quit with modified files In-reply-to: Your message of "Tue, 25 May 1993 19:07:35 EDT." <93May25.190741edt.2688@hawkwind.utcs.toronto.edu> Date: Wed, 26 May 1993 20:21:12 -0400 From: Scott Schwartz Message-Id: <93May26.202013edt.2620@groucho.cs.psu.edu> Thanks for the patch Chris. But now I have a second question. :-) Consider this: ; sam/sam -d B /etc/fstab -. /etc/fstab i foo . D /etc/fstab ?changes to "/etc/fstab" B /etc/svdtab -. /etc/svdtab D /etc/fstab q In other words, the second close attempt on a file will always succeed, even if other operations have taken place in the meantime. That seems rather aggressive to me; when the man page talks about a ``subsequent D'', I expected that it meant an immediately subsequent one. From sam-fans-owner Mon Jun 7 17:18:01 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Mon, 7 Jun 1993 17:16:58 -0400 Received: by ux2.cso.uiuc.edu id AA76627 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Mon, 7 Jun 1993 16:16:53 -0500 Date: Mon, 7 Jun 1993 17:16:53 -0400 From: Ed Kubaitis - CCSO Message-Id: <199306072116.AA76627@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Plan 9 fonts Why doesn't AT&T let Matty Farrow distribute X11 versions of a few Plan 9 fonts with his unicode libXg? Ed From sam-fans-owner Mon Jun 7 17:22:39 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Mon, 7 Jun 1993 17:22:19 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA25427 (5.65c/IDA-1.4.4 for ); Mon, 7 Jun 1993 17:22:12 -0400 Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA16022; Mon, 7 Jun 93 17:22:12 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9306072122.AA16022@penfold.cc.gatech.edu> Date: Mon, 7 Jun 1993 17:22:11 -0400 In-Reply-To: Ed Kubaitis - CCSO's 20-line message on Jun 7, 5:16pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Plan 9 fonts The fonts are copyright by a Charles(?) Bigelow, who has not responded yet to Matty's request to distribute them. Apparently ATT has the right to use them and distribute them w/Plan 9, but Plan 9 requires a license... From sam-fans-owner Mon Jun 7 19:11:26 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Mon, 7 Jun 1993 19:11:10 -0400 Received: by mod.civil.su.oz.au id <28693>; Tue, 8 Jun 1993 09:10:45 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Mon, 7 Jun 1993 19:03:51 -0400 To: Sam Fans cc: James Matthew Farrow Subject: Re: Plan 9 fonts In-Reply-To: <9306072122.AA16022@penfold.cc.gatech.edu> References: <19930607161445.16146.frobozz@orthanc.cs.su.OZ.AU> Message-ID: <199306080903.8692.sam.badon@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Arnold wrote: The fonts are copyright by a Charles(?) Bigelow, who has not responded yet to Matty's request to distribute them. Read, `had' not responded. I got this yesterday: From: matty@cs.su.oz.au (James Matthew Farrow) Date: Mon, 7 Jun 1993 16:14:45 +1000 To: "Score!" Subject: 9term... Message-ID: <19930607161445.16146.frobozz@orthanc.cs.su.OZ.AU> [...] PS: I got permission to distribute the fonts. and can only conclude that the reason he hasn't yet changed the mode of the file on the FTP site is just because he hasn't gotten around to it. What about it, Matty? Dem dere FTP users want dose fonts! OK, John. From sam-fans-owner Thu Jun 17 10:18:33 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Thu, 17 Jun 1993 10:15:41 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA20407 (5.65c/IDA-1.4.4 for ); Thu, 17 Jun 1993 10:15:32 -0400 Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA00671; Thu, 17 Jun 93 10:15:34 EDT Date: Thu, 17 Jun 1993 10:15:34 -0400 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9306171415.AA00671@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.utoronto.ca Subject: a possibly simple question My long time ed-trained fingers want to type s/"\([^"]+\)"/``\1''/g to pull out stuff between quotes and give them ``-'' quotes. I will admit to a weak grasp of the sam command language, but a quick glance at the doc didn't show anything revealing. My question is, how do you do this in sam? A separate question. 9term has snarfe 0x81 in libXg as a Page-Up key, which I miss terribly in sam - any chance of that getting added in to the "next" release? Much thanks, Arnold From sam-fans-owner Thu Jun 17 10:31:55 1993 Received: from daedalus.dcrt.nih.gov ([128.231.129.209]) by hawkwind.utcs.toronto.edu with SMTP id <2765>; Thu, 17 Jun 1993 10:29:40 -0400 Received: from localhost (weisen@localhost) by daedalus.dcrt.nih.gov (ALPHA-6.58/6.28) id KAA27793; Thu, 17 Jun 1993 10:29:22 -0400 Message-Id: <199306171429.KAA27793@daedalus.dcrt.nih.gov> To: arnold@cc.gatech.edu (Arnold Robbins) cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: a possibly simple question In-reply-to: Your message of "Thu, 17 Jun 1993 10:15:34 EDT." <9306171415.AA00671@penfold.cc.gatech.edu> X-Mailer: MH [6.8+MIME] Date: Thu, 17 Jun 1993 10:29:21 -0400 From: Neil Weisenfeld I'm sure that someone out there has a better solution, but if you can train your ed fingers to forget the backslash before the parenthesis, you've got it made. Sam has an s command, too. With dot set to: this is just to say "hello goodbye" to you. we can do: s/"([^"]*)"/``\1''/ and get: p this is just to say ``hello goodbye'' to you. Regards, Neil From sam-fans-owner Tue Jun 29 13:38:01 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2744>; Tue, 29 Jun 1993 13:35:07 -0400 To: sam-fans Subject: new sam tricks from Usenix Date: Tue, 29 Jun 1993 13:35:05 -0400 From: Chris Siebenmann Message-Id: <93Jun29.133507edt.2744@hawkwind.utcs.toronto.edu> Does anyone who was at the Usenix sam/vi/emacs panel feel like summarizing any new sam tricks that got demonstrated there? - cks From sam-fans-owner Tue Jun 29 13:43:55 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2752>; Tue, 29 Jun 1993 13:41:32 -0400 Received: from hillside.co.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) id ; Tue, 29 Jun 1993 18:41:08 +0100 To: Chris Siebenmann Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: new sam tricks from Usenix In-Reply-To: Your message of Tue, 29 Jun 1993 13:35:05 -0400 . <93Jun29.133507edt.2744@hawkwind.utcs.toronto.edu> From: Peter Collinson Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA Phone: +44 227 761824 Fax: +44 227 762554 Date: Tue, 29 Jun 1993 13:41:03 -0400 Message-Id: <17467.741375663@hillside.co.uk> Sender: pc@hillside.co.uk There were none. It's hard to explain tricks to an audience who doesn't understand sam. From sam-fans-owner Tue Jun 29 14:34:09 1993 Received: from nexus.yorku.ca ([130.63.9.66]) by hawkwind.utcs.toronto.edu with SMTP id <2744>; Tue, 29 Jun 1993 14:33:53 -0400 Received: from ursa.sis.yorku.ca ([130.63.74.12]) by nexus.yorku.ca with SMTP id <9219>; Tue, 29 Jun 1993 14:33:29 -0400 Received: from localhost.yorku.ca by sis.yorku.ca (4.1/SMI-4.1) id AA00318; Tue, 29 Jun 93 14:30:46 EDT Message-Id: <9306291830.AA00318@sis.yorku.ca> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: new sam tricks from Usenix Date: Tue, 29 Jun 1993 14:30:45 -0400 From: "Ozan S. Yigit" Ok, how about a summary of the panel discussion, never mind the tricks? Were there any interesting discussions? oz From sam-fans-owner Tue Jun 29 15:40:13 1993 Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2744>; Tue, 29 Jun 1993 15:39:45 -0400 From: rob@research.att.com Date: Tue, 29 Jun 1993 15:20:32 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Jun29.153945edt.2744@hawkwind.utcs.toronto.edu> here's my opening joke from the editor panel, which i made up in real time as i approached the podium, upon realizing i didn't have an opening joke. three programmers go into a bar. the sam user is there because he's finished the day's work and wants to relax. the vi user is there because he's going to be working all night and needs a break. the emacs user is there because there's nothing else he can do: both his hands are in splints because of carpal tunnel syndrome. From sam-fans-owner Tue Jun 29 16:02:56 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2744>; Tue, 29 Jun 1993 16:02:41 -0400 Received: from hillside.co.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) id ; Tue, 29 Jun 1993 21:02:16 +0100 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: new sam tricks from Usenix In-Reply-To: Your message of Tue, 29 Jun 1993 14:30:45 -0400 . <9306291830.AA00318@sis.yorku.ca> From: Peter Collinson Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA Phone: +44 227 761824 Fax: +44 227 762554 Date: Tue, 29 Jun 1993 16:02:10 -0400 Message-Id: <17767.741384130@hillside.co.uk> Sender: pc@hillside.co.uk I did a review for ;login. it was commissioned by Usenix and belongs to them until it's published. I am sure you will understand. The opening para sums up what happened... I guess that the idea here was to generate an entertaining argument on the religious topic of editor choice. It didn't really generate the necessary blood and detached human parts that most people were there to see. The participants were too reasonable. Rob tried to brandish his sabre and lop off a few bits but his attempts were foiled by complete equanimity from the others. -------------------------------- I think we may see a few people join the sam users club however. From sam-fans-owner Thu Jul 1 11:45:15 1993 Received: from gateway.morgan.com ([138.20.30.3]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Thu, 1 Jul 1993 11:43:22 -0400 Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41385>; Thu, 1 Jul 1993 11:43:10 -0400 Received: from osun.Morgan.COM by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA19735; Thu, 1 Jul 93 11:43:02 EDT Date: Thu, 1 Jul 1993 11:43:02 -0400 From: ber@fid.morgan.com (Brian Redman) Message-Id: <9307011543.AA19735@rs2.fid.morgan.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Make.aix AIX 3.2.3: cc -DAIX -D_POSIX_SOURCE -D_ANSI_C_SOURCE -D_LIBXG_EXTENSION -I../include -c gwin.c -o gwin.o "/usr/include/unistd.h", line 119.26: 1506-010 (W) Macro dup invoked with a null argument. "/usr/include/unistd.h", line 119.28: 1506-046 (S) Syntax error. It's the #define dup(a,b) dup2(a,b) in libc.h conflicting with the extern int dup(int fildes) in /usr/include/unistd.h I see a number of solutions but would like to know what others have done. ber From sam-fans-owner Thu Jul 1 16:10:23 1993 Received: from gateway.morgan.com ([138.20.30.3]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Thu, 1 Jul 1993 16:10:01 -0400 Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41385>; Thu, 1 Jul 1993 16:09:37 -0400 Received: from osun.Morgan.COM by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA27549; Thu, 1 Jul 93 16:09:24 EDT Date: Thu, 1 Jul 1993 16:09:24 -0400 From: ber@fid.morgan.com (Brian Redman) Message-Id: <9307012009.AA27549@rs2.fid.morgan.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: scrolling menus Would the author please send me their implementation of a scrolling file menu? Or a cascading menu. or perhaps a menu that execs another sam to select a file when the list would be to large to fit in the file menu. ber From sam-fans-owner Thu Jul 1 16:33:13 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Thu, 1 Jul 1993 16:33:01 -0400 Received: from a.gec-epl.co.uk by ben.uknet.ac.uk via PSS with NIFTP (PP) id ; Thu, 1 Jul 1993 21:32:29 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA00635; Thu, 1 Jul 93 21:33:35 BST Date: Thu, 1 Jul 1993 16:33:35 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9307012033.AA00635@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: scrolling menus X-Sun-Charset: US-ASCII Content-Length: 993 the original version of sam had menus that scrolled when the file menu got too long (what determined when it was "too long", i don't know) - see the V10 Research UNIX Programmer's Manual, Volume II. About p399, if i remember correctly:-). anyway, when i had the chance to see it, it didn't look too pleasant to use, because there was too much unpredictability in how the menu scrolled. i don't know, maybe it was just me. but i don't like the idea of cascading menus either (too much holding down of the button again). i think the simplest method would be to just have a "more files" option, just above "~~sam~~", which cycles through which set of files appear in the menu. it's not complicated to use, and probably not complicated to implement either (i haven't looked at the menu code for a while, but it wasn't that difficult). the main problem is that getting to your file could take n selections from the menu, and you know how much rob hates unnecessary user interaction... :-) steve From sam-fans-owner Thu Jul 1 19:08:22 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2766>; Thu, 1 Jul 1993 19:08:06 -0400 To: sam-fans Subject: Re: scrolling menus In-reply-to: ber's message of Thu, 01 Jul 93 16:09:24 -0400. <9307012009.AA27549@rs2.fid.morgan.com> Date: Thu, 1 Jul 1993 19:08:03 -0400 From: Chris Siebenmann Message-Id: <93Jul1.190806edt.2766@hawkwind.utcs.toronto.edu> There's a replacement libXg/menuhit.c file in the mailing list archives that does scrolling menus; it works quite nicely. The mailing list archives are ftpable from ftp.sys.utoronto.ca in /pub/sam-fans. - cks From sam-fans-owner Thu Jul 1 19:10:23 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2769>; Thu, 1 Jul 1993 19:10:13 -0400 To: sam-fans Subject: Re: scrolling menus In-reply-to: cks's message of Thu, 01 Jul 93 19:08:03 -0400. <93Jul1.190806edt.2766@hawkwind.utcs.toronto.edu> Date: Thu, 1 Jul 1993 19:10:04 -0400 From: Chris Siebenmann Message-Id: <93Jul1.191013edt.2769@hawkwind.utcs.toronto.edu> In the 'is my face red' department: the mailing list is in /pub/sam on ftp.sys.utoronto.ca, not /pub/sam-fans. - cks From sam-fans-owner Thu Jul 1 22:14:53 1993 Received: from sylvester.cc.utexas.edu ([128.83.135.63]) by hawkwind.utcs.toronto.edu with SMTP id <2771>; Thu, 1 Jul 1993 22:12:29 -0400 Received: by sylvester.cc.utexas.edu id AA04276 (5.65c/IDA-1.4.4 for sam-fans@hawkwind.utcs.toronto.edu); Thu, 1 Jul 1993 21:12:20 -0500 Date: Thu, 1 Jul 1993 22:12:20 -0400 From: rob Message-Id: <199307020212.AA04276@sylvester.cc.utexas.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Auto-raise in samterm Well, I just got my hands on sam (I've known about it for 1.5 years but I didn't know where to get it), and I'm pretty happy with it. I'm using it on a SPARC 1+ under X11R5. I've applied the samx patch. Anyway, one thing I really didn't like about samterm was the click-to-type business. I really hate that. So I came up with a little patch that eliminates click-to-type, which I have included below. rob ----- cut here ----- *** virgin/samterm/main.c Thu Jul 1 20:35:04 1993 --- samterm/main.c Tue Jun 29 22:11:32 1993 *************** *** 101,106 **** --- 146,153 ---- scroll(which, fwdbut == 3 ? 3 : 1); else menu3hit(); + }else if(nwhich && nwhich!=which){ + current(nwhich); } mouseunblock(); } ----- cut here ----- From sam-fans-owner Thu Jul 1 22:41:06 1993 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Thu, 1 Jul 1993 22:38:46 -0400 Received: by quux.es.su.oz.au id <1074>; Fri, 2 Jul 1993 12:38:06 +1000 From: noel@es.su.oz.au Date: Thu, 1 Jul 1993 22:37:51 -0400 to: rob , sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Auto-raise in samterm In-Reply-To: <199307020212.AA04276@sylvester.cc.utexas.edu> Message-ID: <199307021237.13989.out.bagib@es.su.oz.au> oh my god! From sam-fans-owner Thu Jul 1 22:46:02 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2766>; Thu, 1 Jul 1993 22:43:44 -0400 Received: by mod.civil.su.oz.au id <28692>; Fri, 2 Jul 1993 12:43:26 +1000 From: John Mackin To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Jul2.124326est.28692@mod.civil.su.oz.au> Date: Thu, 1 Jul 1993 22:43:15 -0400 + }else if(nwhich && nwhich!=which){ + current(nwhich); And may the Lord have mercy upon your soul. If you have one. From sam-fans-owner Thu Jul 1 23:59:15 1993 Received: from nexus.yorku.ca ([130.63.9.66]) by hawkwind.utcs.toronto.edu with SMTP id <2769>; Thu, 1 Jul 1993 23:56:56 -0400 Received: from ursa.sis.yorku.ca ([130.63.74.12]) by nexus.yorku.ca with SMTP id <9221>; Thu, 1 Jul 1993 23:56:39 -0400 Received: from localhost.yorku.ca by sis.yorku.ca (4.1/SMI-4.1) id AA06529; Thu, 1 Jul 93 23:53:59 EDT Message-Id: <9307020353.AA06529@sis.yorku.ca> To: John Mackin Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: Your message of "Thu, 01 Jul 93 22:43:15 EDT." <93Jul2.124326est.28692@mod.civil.su.oz.au> Date: Thu, 1 Jul 1993 23:53:59 -0400 From: "Ozan S. Yigit" > And may the Lord have mercy upon your soul. just because he eliminated click-to-type? But look what Rob later wrote[1]: "Several interrelated rules were followed in the design of the interface. These rules are intented to make the system as efficient and comfortable as possible for its _users_. First, _brevity_: there should be no actions in the interface - button clicks or other gestures - that do not directly affect the system. Thus, help is not a `click-to-type' system because that click is wasted; there are no pop-up menus because the gesture required to make them appear is wasted; and so on." so, sam is halfclick there. ;-) oz --- [1] R. Pike A Minimalist Global User Interface Proceedings of the Summer 1991 Usenix Conference Nashwille, Tenn. From sam-fans-owner Fri Jul 2 00:23:18 1993 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <2770>; Fri, 2 Jul 1993 00:20:41 -0400 Received: from moria.cs.su.OZ.AU (for hawkwind.utcs.toronto.edu) with MHSnet; Fri, 02 Jul 1993 14:20:19 +1000 From: David Hogan Date: Fri, 2 Jul 1993 00:01:45 -0400 To: "Ozan S. Yigit" Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <9307020353.AA06529@sis.yorku.ca> Message-ID: <199307021401.2654.out.badub@cs.su.oz.au> > > And may the Lord have mercy upon your soul. > just because he eliminated click-to-type? But look what Rob > later wrote[1]: > [...help quote elided...] Yes, but help is not sam, and sam is not help. Abandoning click-to-type worked well for help, because every bit of text on the screen is a potential command for help to execute, so instead of having pop-up menus you have windows with commands in them. It's part of the overall design. Sam was designed to have a click-to-type policy, and it works very well the way it is. And besides, there is a long tradition of sam users who have enjoyed its very click-to-type-ness, and probably view this change as an act of desecration (I know I do :-). ``We're all in it together'' - Brazil From sam-fans-owner Fri Jul 2 00:39:40 1993 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu with SMTP id <2775>; Fri, 2 Jul 1993 00:37:22 -0400 Received: by quux.es.su.oz.au id <1078>; Fri, 2 Jul 1993 14:36:55 +1000 From: noel@es.su.oz.au Date: Fri, 2 Jul 1993 00:25:46 -0400 to: sam-fans@hawkwind.utcs.toronto.edu Subject: click-to-type In-Reply-To: <199307021401.2654.out.badub@cs.su.oz.au> Message-ID: <199307021425.13763.out.bagig@es.su.oz.au> From: David Hogan it is. And besides, there is a long tradition of sam users who have enjoyed its very click-to-type-ness, and probably view this change as an act of desecration (I know I do :-). you are being too kind, david; it is hideous, execrable, heinous. From sam-fans-owner Fri Jul 2 00:48:22 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2777>; Fri, 2 Jul 1993 00:46:07 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA02383; Thu, 1 Jul 1993 23:46:03 -0500 Message-Id: <9307020446.AA02383@oldp.astro.wisc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Date: Fri, 2 Jul 1993 00:46:02 -0400 From: Alan Watson X-Mts: smtp I find it difficult to believe that there is only one right way to design and use an editor based on an exquisitely powerful langauge and an elegant mouse and windows interface; without doubt, Rob Pike has found a way more right than wrong with sam, but it isn't going to suit everyone, and neither should we expect it to. And now, back to your regularly scheduled programming. From sam-fans-owner Fri Jul 2 06:50:25 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2773>; Fri, 2 Jul 1993 06:47:55 -0400 Received: from a.gec-epl.co.uk by ben.uknet.ac.uk via PSS with NIFTP (PP) id ; Fri, 2 Jul 1993 11:47:31 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA00919; Fri, 2 Jul 93 09:23:09 BST Date: Fri, 2 Jul 1993 04:23:09 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9307020823.AA00919@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: re: auto-raising X-Sun-Charset: US-ASCII Content-Length: 542 i'm not entirely sure what rob's patch does, but i'd guess that it just pulls to the front the window currently under the mouse. ugh. i can almost hear the monitor going "ping!" every time that happens. my own samterm hack keeps the click-to-type, but doesn't pull the window forward when you click on it - it just gives it the focus. A second click pulls it forward. I find this essential if i'm editing text from one window, but i'm basing it on the contents of another window. might consider incorporating rob's patch :-) [duck]. steve From sam-fans-owner Fri Jul 2 17:50:36 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2765>; Fri, 2 Jul 1993 17:49:54 -0400 To: sam-fans Subject: Re: Auto-raise in samterm In-reply-to: mayoff's message of Thu, 01 Jul 93 22:12:20 -0400. <199307020212.AA04276@sylvester.cc.utexas.edu> Date: Fri, 2 Jul 1993 17:49:44 -0400 From: Chris Siebenmann Message-Id: <93Jul2.174954edt.2765@hawkwind.utcs.toronto.edu> For all the vituperation so far, it's worth remembering that sam's click-to-focus policy was created on a system where click-to-focus was the overall focus policy as well (to use X terminology). It may well make sense to switch to mouse-based focusing inside sam if your X window manager also uses mouse-based focusing. - cks From sam-fans-owner Fri Jul 2 19:27:04 1993 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.toronto.edu with SMTP id <2765>; Fri, 2 Jul 1993 19:26:52 -0400 Received: by ux2.cso.uiuc.edu id AA22267 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Fri, 2 Jul 1993 18:26:37 -0500 Date: Fri, 2 Jul 1993 19:26:37 -0400 From: Ed Kubaitis - CCSO Message-Id: <199307022326.AA22267@ux2.cso.uiuc.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Auto-raise in samterm Rob's *real* crime was "...I've applied the samx patch...". Happy 4th to those of the USA persuasion. Ed ----------------------------------------- Sam Stripes & Streamers, Inc No feature too fatuous. No hack too ugly. From sam-fans-owner Sat Jul 3 17:13:07 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2768>; Sat, 3 Jul 1993 17:12:43 -0400 Return-Path: osf.org!rsalz Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu with SMTP id <2768>; Sat, 3 Jul 1993 12:58:23 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA24866; Sat, 3 Jul 93 12:58:20 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA05823; Sat, 3 Jul 93 12:59:51 -0400 Date: Sat, 3 Jul 1993 12:59:51 -0400 From: rsalz@osf.org Message-Id: <9307031659.AA05823@sulphur.osf.org> To: sam-fans-owner Subject: Re: Auto-raise in samterm Resent-To: sam-fans Resent-Date: Sat, 3 Jul 1993 17:12:35 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93Jul3.171243edt.2768@hawkwind.utcs.toronto.edu> >Rob's *real* crime was "...I've applied the samx patch...". huynh? From sam-fans-owner Sun Jul 4 11:23:35 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2768>; Sun, 4 Jul 1993 11:23:03 -0400 Received: by mod.civil.su.oz.au id <28693>; Mon, 5 Jul 1993 01:22:38 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Sun, 4 Jul 1993 11:19:48 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Auto-raise in samterm In-Reply-To: <93Jul2.174954edt.2765@hawkwind.utcs.toronto.edu> Message-ID: <199307050119.4549.sam.badus@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Chris points out: For all the vituperation so far, it's worth remembering that sam's click-to-focus policy was created on a system where click-to-focus was the overall focus policy as well (to use X terminology). It may well make sense to switch to mouse-based focusing inside sam if your X window manager also uses mouse-based focusing. Did anyone _forget_ that? There's another alternative, of course. You can throw out your hideous real-estate-driven window manager and use one that implements click-to-focus, the One True Focus Policy. I know _I_ did. (Hell, I wonder why my X terminal behaves so much like a Blit running mux... must be _some_ reason...) OK, John. From sam-fans-owner Mon Jul 5 03:58:24 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2769>; Mon, 5 Jul 1993 03:58:05 -0400 Received: from a.gec-epl.co.uk by ben.uknet.ac.uk via PSS with NIFTP (PP) id ; Mon, 5 Jul 1993 08:57:49 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA01334; Mon, 5 Jul 93 08:58:53 BST Date: Mon, 5 Jul 1993 03:58:53 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9307050758.AA01334@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: no-auto-raise patch X-Sun-Charset: US-ASCII Content-Length: 965 a number of people have expressed a vague interest in my patch to stop windows auto-raising when selected with the mouse. ok, i though, i may as well post it. steve diff -c orig/main.c hacked/main.c *** orig/main.c Fri Jul 2 14:12:21 1993 --- hacked/main.c Mon Jul 5 08:56:20 1993 *************** *** 127,133 **** flborder(which, 0); if(nw){ flushtyping(1); ! flupfront(nw); flborder(nw, 1); buttons(Up); t=(Text *)nw->user1; --- 127,133 ---- flborder(which, 0); if(nw){ flushtyping(1); ! /* flupfront(nw); smk */ flborder(nw, 1); buttons(Up); t=(Text *)nw->user1; diff -c orig/menu.c hacked/menu.c *** orig/menu.c Fri Jul 2 14:12:20 1993 --- hacked/menu.c Fri Jul 2 14:12:52 1993 *************** *** 175,180 **** --- 175,181 ---- i = 0; while(i!=t->front && t->l[i].textfn==0); current(&t->l[i]); + flupfront(&t->l[i]); /* smk */ }else sweeptext(0, tag[m-NMENU3]); break; From sam-fans-owner Wed Jul 7 11:03:59 1993 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <2772>; Wed, 7 Jul 1993 11:02:41 -0400 From: mhw@minster.york.ac.uk Date: Wed, 7 Jul 1993 12:01:15 -0400 Message-ID: >From: Mark H. Wilkinson Subject: sam -r * To: sam-fans@hawkwind.utcs.toronto.edu Illegal-Object: Syntax error in Sender: address found on hawkwind.utcs.toronto.edu: Sender: Mark H.Wilkinson ^ ^-illegal period in phrase \-phrases containing '.' must be quoted X-Mailer: Sendmail/ream v4.12bv I've always found it strange that ``sam -r machine'' was mutually exclusive with ``sam [option ...] [files].'' A quick look at the source revealed that it could easily be changed to allow the -r option to pass the list of files to sam on the remote machine. Here's the patch: diff -C 2 -r old.sam/sam/io.c new.sam/sam/io.c *** old.sam/sam/io.c Wed Jul 7 13:34:43 1993 --- new.sam/sam/io.c Wed Jul 7 15:44:21 1993 *************** *** 215,221 **** void ! connectto(char *machine) { int p1[2], p2[2]; if(pipe(p1)<0 || pipe(p2)<0){ --- 215,222 ---- void ! connectto(char *machine, int fargc, char **fargv) { int p1[2], p2[2]; + char **nargv, **fp, **tp; if(pipe(p1)<0 || pipe(p2)<0){ *************** *** 227,230 **** --- 228,239 ---- switch(fork()){ case 0: + tp = nargv = emalloc((4+fargc)*sizeof(char *)); + *tp++ = RX; + *tp++ = machine; + *tp++ = rsamname; + *tp++ = "-R"; + fp = fargv; + while (*tp++ = *fp++) + ; dup(p2[0], 0); dup(p1[1], 1); *************** *** 233,237 **** close(p2[0]); close(p2[1]); ! execl(RXPATH, RX, machine, rsamname, "-R", (char*)0); dprint("can't exec %s\n", RXPATH); exits("exec"); --- 242,246 ---- close(p2[0]); close(p2[1]); ! exec(RXPATH, nargv); dprint("can't exec %s\n", RXPATH); exits("exec"); *************** *** 246,253 **** void ! startup(char *machine, int Rflag, char **argv, char **end) { if(machine) ! connectto(machine); if(!Rflag) bootterm(machine, argv, end); --- 255,262 ---- void ! startup(char *machine, int Rflag, char **argv, char **end, int fargc, char **fargv) { if(machine) ! connectto(machine, fargc, fargv); if(!Rflag) bootterm(machine, argv, end); diff -C 2 -r old.sam/sam/sam.c new.sam/sam/sam.c *** old.sam/sam/sam.c Wed Jul 7 13:35:03 1993 --- new.sam/sam/sam.c Wed Jul 7 15:28:01 1993 *************** *** 95,99 **** home = "/"; if(!dflag) ! startup(machine, Rflag, arg, ap); Fstart(); notify(notifyf); --- 95,99 ---- home = "/"; if(!dflag) ! startup(machine, Rflag, arg, ap, argc, argv); Fstart(); notify(notifyf); diff -C 2 -r old.sam/sam/sam.h new.sam/sam/sam.h *** old.sam/sam/sam.h Wed Jul 7 13:35:05 1993 --- new.sam/sam/sam.h Wed Jul 7 15:30:18 1993 *************** *** 286,290 **** void snarf(File*, Posn, Posn, Buffer*, int); void sortname(File*); ! void startup(char*, int, char**, char**); void state(File*, int); int statfd(int, ulong*, ulong*, long*, long*); --- 286,290 ---- void snarf(File*, Posn, Posn, Buffer*, int); void sortname(File*); ! void startup(char*, int, char**, char**, int, char**); void state(File*, int); int statfd(int, ulong*, ulong*, long*, long*); From sam-fans-owner Thu Jul 8 14:51:55 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.edu with SMTP id <2774>; Thu, 8 Jul 1993 14:50:39 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2601>; Thu, 8 Jul 1993 14:49:04 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: no-auto-raise patch In-reply-to: Your message of "Mon, 05 Jul 1993 03:58:53 EDT." <9307050758.AA01334@zombie.gec-epl.co.uk> Date: Thu, 8 Jul 1993 14:49:58 -0400 From: Scott Schwartz Message-Id: <93Jul8.144904edt.2601@groucho.cse.psu.edu> | a number of people have expressed a vague interest in my patch to stop | windows auto-raising when selected with the mouse. ok, i though, i may | as well post it. It's different, but I think I like it. Thanks Steve. From sam-fans-owner Fri Jul 9 04:37:56 1993 Received: from mail.cs.tu-berlin.de ([130.149.17.13]) by hawkwind.utcs.toronto.edu with SMTP id <2782>; Fri, 9 Jul 1993 04:37:09 -0400 Received: from gimli.cs.tu-berlin.de by mail.cs.tu-berlin.de with SMTP id AA24005 (5.65c8/IDA-1.4.4(mail.m4[1.12]) for ); Fri, 9 Jul 1993 10:35:41 +0200 From: "Robert T. Raschke" Message-Id: <199307090835.AA24005@mail.cs.tu-berlin.de> Subject: Re: no-auto-raise patchjhdgjdghjqqqqqqqq To: schwartz@groucho.cse.psu.edu (Scott Schwartz) Date: Fri, 9 Jul 1993 04:35:40 -0400 Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <93Jul8.144904edt.2601@groucho.cse.psu.edu> from "Scott Schwartz" at Jul 8, 93 02:49:58 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 429 Hallo, das shell-script B in /home/pub/bin ist ein Teil von sam, einem cut and paste Editor fuer X. Wenn sam gestartet wird, legt es eine pipe an, in die sam-Kommandos geschickt werden koennen. In sam gibt es ein Befehl B um Dateien zu laden. Das shell-script, macht nun nichts anderes als eine Datei in den bestehenden sam zu laden (von einer shell aus). Dies ist im Prinzip das Gleiche wie emacs-client fuer emacs. Robby From sam-fans-owner Fri Jul 9 05:01:14 1993 Received: from mail.cs.tu-berlin.de ([130.149.17.13]) by hawkwind.utcs.toronto.edu with SMTP id <2784>; Fri, 9 Jul 1993 05:00:56 -0400 Received: from gimli.cs.tu-berlin.de by mail.cs.tu-berlin.de with SMTP id AA24432 (5.65c8/IDA-1.4.4(mail.m4[1.12]) for ); Fri, 9 Jul 1993 10:59:51 +0200 Date: Fri, 9 Jul 1993 04:59:51 -0400 From: "Robert T. Raschke" To: Message-Id: <199307090859.AA24432@mail.cs.tu-berlin.de> Apparently-To: ooops From sam-fans-owner Sun Jul 18 18:25:16 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.edu with SMTP id <2809>; Sun, 18 Jul 1993 18:21:57 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2579>; Sun, 18 Jul 1993 18:20:24 -0400 To: Sam Fans Subject: scrollForwardR is buggy (+patch) Date: Sun, 18 Jul 1993 18:21:05 -0400 From: Scott Schwartz Message-Id: <93Jul18.182024edt.2579@groucho.cse.psu.edu> Greetings all, In the Bell Labs distribution, if the X resource database contains Sam*scrollForwardR:false then scrolling will malfunction. As distributed, scrollForwardR works by having samterm/main.c lie to scroll() about which button was pressed, if it was 1 or 3. Unfortunately, scroll() detects the lie at line 122 when it calls button(but); it will always exit the loop at that point since the real mouse won't match but. My fix was to have the scrolling logic in samterm check to see which is the forward-scrolling button in the three places it needs to know that. *** 1.1 1993/07/18 21:23:20 --- main.c 1993/07/18 22:00:31 *************** *** 21,26 **** --- 21,28 ---- char lock = 1; char hasunlocked = 0; + int fwdbut = 3; /* an X resource may set this to 1 */ + void main(int argc, char *argv[]) { *************** *** 29,36 **** Rectangle r; Flayer *nwhich; - int fwdbut; - getscreen(argc, argv); fwdbut = scrollfwdbut(); iconinit(); --- 31,36 ---- *************** *** 81,87 **** if(nwhich!=which) current(nwhich); else if(scr) ! scroll(which, fwdbut == 3 ? 1 : 3); else{ t=(Text *)which->user1; if(flselect(which)){ --- 81,87 ---- if(nwhich!=which) current(nwhich); else if(scr) ! scroll(which, 1); else{ t=(Text *)which->user1; if(flselect(which)){ *************** *** 98,104 **** menu2hit(); }else if((mouse.buttons&4)){ if(scr) ! scroll(which, fwdbut == 3 ? 3 : 1); else menu3hit(); } --- 98,104 ---- menu2hit(); }else if((mouse.buttons&4)){ if(scr) ! scroll(which, 3); else menu3hit(); } *************** *** 287,302 **** { Text *t=(Text *)l->user1; ! switch(but){ ! case 1: outTsll(Torigin, t->tag, l->origin, p0); ! break; ! case 2: outTsll(Torigin, t->tag, p0, 1L); ! break; ! case 3: horigin(t->tag,p0); - } } int --- 287,298 ---- { Text *t=(Text *)l->user1; ! if (but == BCKBUT) outTsll(Torigin, t->tag, l->origin, p0); ! else if (but == SETBUT) outTsll(Torigin, t->tag, p0, 1L); ! else if (but == FWDBUT) horigin(t->tag,p0); } int *** 1.1 1993/07/18 21:30:30 --- samterm.h 1993/07/18 22:00:33 *************** *** 5,10 **** --- 5,14 ---- #define MAXFILES 256 #define NL 5 + #define BCKBUT (4-fwdbut) + #define SETBUT (2) + #define FWDBUT (fwdbut) + enum{ Up, Down *************** *** 67,72 **** --- 71,77 ---- extern long snarflen; extern Mouse mouse; extern long modified; + extern int fwdbut; Rune *gettext(Flayer*, long, ulong*); void *alloc(ulong n); *** 1.1 1993/07/16 20:06:17 --- scroll.c 1993/07/18 22:05:39 *************** *** 100,114 **** my = s.max.y; if(!eqpt(mouse.xy, Pt(x, my))) cursorset(Pt(x, my)); ! if(but == 1){ p0 = l->origin-frcharofpt(&l->f, Pt(s.max.x, my)); rt = scrpos(l->scroll, p0, p0+l->f.nchars, tot); y = rt.min.y; ! }else if(but == 2){ y = my; if(y > s.max.y-2) y = s.max.y-2; ! }else if(but == 3){ p0 = l->origin+frcharofpt(&l->f, Pt(s.max.x, my)); rt = scrpos(l->scroll, p0, p0+l->f.nchars, tot); y = rt.min.y; --- 100,114 ---- my = s.max.y; if(!eqpt(mouse.xy, Pt(x, my))) cursorset(Pt(x, my)); ! if(but == BCKBUT){ p0 = l->origin-frcharofpt(&l->f, Pt(s.max.x, my)); rt = scrpos(l->scroll, p0, p0+l->f.nchars, tot); y = rt.min.y; ! }else if(but == SETBUT){ y = my; if(y > s.max.y-2) y = s.max.y-2; ! }else if(but == FWDBUT){ p0 = l->origin+frcharofpt(&l->f, Pt(s.max.x, my)); rt = scrpos(l->scroll, p0, p0+l->f.nchars, tot); y = rt.min.y; *************** *** 118,137 **** r = raddp(scr, Pt(0, y-scr.min.y)); scrflip(l, r); } ! } }while(button(but)); if(in){ h = s.max.y-s.min.y; scrflip(l, r); p0 = 0; ! if(but == 1) p0 = (long)(my-s.min.y)/l->f.font->height+1; ! else if(but == 2){ if(tot > 1024L*1024L) p0 = ((tot>>10)*(y-s.min.y)/h)<<10; else p0 = tot*(y-s.min.y)/h; ! }else if(but == 3){ p0 = l->origin+frcharofpt(&l->f, Pt(s.max.x, my)); if(p0 > tot) p0 = tot; --- 118,137 ---- r = raddp(scr, Pt(0, y-scr.min.y)); scrflip(l, r); } ! } }while(button(but)); if(in){ h = s.max.y-s.min.y; scrflip(l, r); p0 = 0; ! if(but == BCKBUT) p0 = (long)(my-s.min.y)/l->f.font->height+1; ! else if(but == SETBUT){ if(tot > 1024L*1024L) p0 = ((tot>>10)*(y-s.min.y)/h)<<10; else p0 = tot*(y-s.min.y)/h; ! }else if(but == FWDBUT){ p0 = l->origin+frcharofpt(&l->f, Pt(s.max.x, my)); if(p0 > tot) p0 = tot; From sam-fans-owner Wed Jul 21 11:24:34 1993 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Wed, 21 Jul 1993 11:21:43 -0400 From: pete@minster.york.ac.uk Date: Wed, 21 Jul 1993 12:11:48 -0400 Message-ID: To: 9fans@cs.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: libXg and caps lock on Sun type V keyboard under openwindows Not sure which of these lists (9fans or sam-fans) is more appropriate, but here goes: Running 9term or samterm under Openwindows (sparcstation elc; type 5 keyboard; openwindows 2; sunos 4.1.1) I find that the Caps Lock key is interpreted as Shift Lock -- i.e. 123 comes out as !"# and so on. It looks like a libXg bug to me... As far as I'm concerned this is only a minor irritant -- Caps Lock is pointless anyway in these days of OPERATING SYSTEMS THAT DON'T REQUIRE YOU TO SHOUT -- but I wondered if anyone else had noticed this bug-ette and/or had a fix for it? pete -- Peter Fenelon - Research Associate - High Integrity Systems Engineering Group, Dept. of Computer Science, University of York, York, Y01 5DD (+44/0)904 433388 pete@minster.york.ac.uk `Today keeps slipping by me, it leaves no aftertaste.' From sam-fans-owner Wed Jul 21 13:48:27 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Wed, 21 Jul 1993 13:48:03 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2591>; Wed, 21 Jul 1993 13:46:25 -0400 To: pete@minster.york.ac.uk cc: 9fans@cs.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: libXg and caps lock on Sun type V keyboard under openwindows In-reply-to: Your message of "Wed, 21 Jul 1993 12:11:48 EDT." Date: Wed, 21 Jul 1993 13:47:07 -0400 From: Scott Schwartz Message-Id: <93Jul21.134625edt.2591@groucho.cse.psu.edu> | As far as I'm concerned this is only a minor irritant -- Caps Lock is | pointless anyway in these days of OPERATING SYSTEMS THAT DON'T REQUIRE | YOU TO SHOUT -- but I wondered if anyone else had noticed this bug-ette | and/or had a fix for it? It doesn't show up here, running MIT X11. In terms of shouting, if you use MODULA-3, encrusted as it is with upper case keywords, caps-lock is about the only alternative (and a poor one at that) to a context sensitive editor like emacs. From sam-fans-owner Wed Jul 21 17:02:07 1993 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Wed, 21 Jul 1993 17:01:38 -0400 From: pete@minster.york.ac.uk Date: Wed, 21 Jul 1993 17:52:49 -0400 Message-ID: To: pete@minster.york.ac.uk, schwartz@groucho.cse.psu.edu Subject: Re: libXg and caps lock on Sun type V keyboard under openwindows Cc: 9fans@cs.psu.edu, sam-fans@hawkwind.utcs.toronto.edu >From schwartz@groucho.cse.psu.edu Wed Jul 21 13:47:07 0400 1993 [I said] >| As far as I'm concerned this is only a minor irritant -- Caps Lock is >| pointless anyway in these days of OPERATING SYSTEMS THAT DON'T REQUIRE >| YOU TO SHOUT -- but I wondered if anyone else had noticed this bug-ette >| and/or had a fix for it? >It doesn't show up here, running MIT X11. I tried re-linking against MIT X11R4 libraries rather than the Openwindows ones, with the same result. I guess it's an Openwindows 2 server ``feature''. Sigh. >In terms of shouting, if you use MODULA-3, encrusted as it is with >upper case keywords, caps-lock is about the only alternative (and a >poor one at that) to a context sensitive editor like emacs. Hmmm.... I think if I was using sam to edit a language which required upper case I'd knock together some sort of filter to do the capitalisation and pipe the file through it before a write... that's what the '|' command is there for! Couple of extra keystrokes perhaps (maybe only one if you're using the keyboard extensions to sam) and it avoids the dreaded emacs... pete -- Peter Fenelon - Research Associate - High Integrity Systems Engineering Group, Dept. of Computer Science, University of York, York, Y01 5DD +44 (0)904 433388 EMAIL: pete@minster.york.ac.uk `There's no room for enigmas in built-up areas' From sam-fans-owner Fri Jul 23 12:38:41 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Fri, 23 Jul 1993 12:37:38 -0400 Received: from a.gec-epl.co.uk by ben.uknet.ac.uk via PSS with NIFTP (PP) id ; Fri, 23 Jul 1993 17:36:56 +0100 Received: by zombie. (5.0/SMI-SVR4) id AA00513; Fri, 23 Jul 93 17:37:00 BST Date: Fri, 23 Jul 1993 12:37:00 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Illegal-Object: Syntax error in Message-Id: value found on hawkwind.utcs.toronto.edu: Message-Id: <9307231637.AA00513@zombie.> ^-illegal subdomain in domain To: sam-fans@hawkwind.utcs.toronto.edu Subject: setting sam's font X-Sun-Charset: US-ASCII Content-Length: 374 i've just upgraded (for want of a better word) to solaris 2.2, and this has screwed the fonts being used by sam and 9term. 9term i can get round, by putting "-font fixed" on the cmd line. but there doesn't seem to be a way to persuade sam to explicitly grab another font. since i'm not in any way an x hacker (for obvious reasons), i'm out of ideas. any suggestions? steve From sam-fans-owner Fri Jul 23 12:51:52 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Fri, 23 Jul 1993 12:51:34 -0400 Received: from hillside.co.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) id ; Fri, 23 Jul 1993 17:51:15 +0100 To: steve@gec-epl.co.uk (Steve_Kilbane) Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: setting sam's font In-Reply-To: Your message of Fri, 23 Jul 1993 12:37:00 -0400 . <2849.9307231640@hillside.co.uk> From: Peter Collinson Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA Phone: +44 227 761824 Fax: +44 227 762554 Date: Fri, 23 Jul 1993 12:51:12 -0400 Message-Id: <2882.743446272@hillside.co.uk> Sender: pc@hillside.co.uk Install a file called Sam in /usr/openwin/lib/app-defaults *width: 500 *height: 600 *font: screenpc *scrollForwardR: false *saveUnder: true *backingStore: WhenMapped Add your desired font name in there. I use a modified version of Sun's screen-14 font. From sam-fans-owner Fri Jul 23 13:00:52 1993 Received: from alpha.xerox.com ([13.1.64.93]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Fri, 23 Jul 1993 13:00:34 -0400 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <11902>; Fri, 23 Jul 1993 10:00:00 PDT Received: by reynaldo.parc.xerox.com id <25545>; Fri, 23 Jul 1993 09:47:47 -0700 From: Berry Kercheval To: steve@gec-epl.co.uk (Steve_Kilbane) Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: setting sam's font In-Reply-To: <93Jul23.093931pdt.11867@alpha.xerox.com> References: <93Jul23.093931pdt.11867@alpha.xerox.com> Reply-To: kerch@parc.xerox.com Message-Id: <93Jul23.094747pdt.25545@reynaldo.parc.xerox.com> Date: Fri, 23 Jul 1993 12:47:41 -0400 I've had good luck putting samterm*font: fixed in my X resources file, or by feeding that line into xrdb: echo 'samterm*font: fixed' | xrdb -merge (the '-merge' is important, as otherwise xrdb will assume you want to set all your resources and helpfully delete everything else...) --berry From sam-fans-owner Wed Aug 4 11:51:54 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <2223>; Wed, 4 Aug 1993 11:48:11 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA20489 (5.65c/IDA-1.4.4 for ); Wed, 4 Aug 1993 11:47:57 -0400 Received: by penfold.cc.gatech.edu id AA11664 (5.65c/IDA-1.4.4 for sam-fans@hawkwind.utcs.utoronto.ca); Wed, 4 Aug 1993 11:47:55 -0400 From: Arnold Robbins Message-Id: <199308041547.AA11664@penfold.cc.gatech.edu> Date: Wed, 4 Aug 1993 11:47:54 -0400 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: sam-fans@hawkwind.utcs.utoronto.ca Subject: sam getting out of sync? I'm using the march 93 sam, using Matty's unicode libframe and libXg, and X11R5 at the latest patchlevel. Recently, I've noticed that sam seems to lose track of what's in the window. Two symptoms have manifested. 1) I'll page down in the file and sam will not update the screen, starting somewhere in the middle of a line in the middle of the window, the rest of the window will be blank. 2) Where the mouse is and where the line is gets off by a single character from the left side of the window - sam thinks the line starts one character's width into the window. This is on a rather large file - over 500,000 characters. This only started happening in the past day or two, as I've moved towards the end of the file. Q. Has anyone seen this phenonmenon before? Q. If so, is there a fix? I really don't want to break this file apart... Please help, I don't want to have to go back to vi... :-( Thanks in advance, Arnold Robbins --- Continuing Education, College of Computing Georgia Tech, Atlanta, GA 30332-0280 Phone: +1 404 894 9214 (has voice mail) E-mail: arnold.robbins@cc.gatech.edu FAX: +1 404 853 9378 "He's not dead, he's metaphysically challenged." - Mystery Science Theatre 3000 From sam-fans-owner Wed Aug 4 15:01:26 1993 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <2237>; Wed, 4 Aug 1993 15:01:06 -0400 From: forsyth@minster.york.ac.uk Date: Wed, 4 Aug 1993 14:15:35 -0400 To: sam-fans@hawkwind.utcs.utoronto.ca Message-ID: subject: teaching novices to use sam if they like its style, it's fairly easy to get experienced programmers to use sam happily. has anyone, perhaps at a university, any experience in trying to get novices (ie, students) to use sam as a first editor? (some, but not all, will actually have used fairly simple minded editors under Windows and similar systems at home and at school.) i made sam and a few other mouse-based editors available to students during the last academic year, but because many were taught vi (not by me) as the first editor, i suspect they never bothered to switch. others found difficulty getting to grips with the mouse (quite likely because it wasn't a good make of mouse). what experiences have others had/seen? From sam-fans-owner Thu Aug 5 20:32:56 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Thu, 5 Aug 1993 20:29:12 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05379; Thu, 5 Aug 93 20:29:02 -0400 Date: Thu, 5 Aug 1993 20:29:02 -0400 From: plexus-sys!mdash@uunet.uu.net Message-Id: <9308060029.AA05379@relay2.UU.NET> Received: from plexus-sys.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 202757.11319; Thu, 5 Aug 1993 20:27:57 EDT To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term Content-Type: text Content-Length: 71 What is the availability of 9term? --Mike Scheer, mdash@plexus-sys.com From sam-fans-owner Thu Aug 5 21:05:22 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2685>; Thu, 5 Aug 1993 21:03:11 -0400 Received: by mod.civil.su.oz.au id <28694>; Fri, 6 Aug 1993 11:02:27 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Thu, 5 Aug 1993 20:59:50 -0400 To: forsyth@minster.york.ac.uk cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: teaching novices to use sam In-Reply-To: Message-ID: <199308061059.7101.sam.bafey@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ has anyone, perhaps at a university, any experience in trying to get novices (ie, students) to use sam as a first editor? Yes. They did (are still doing?) research on this at the Basser Department of Computer Science here at the University of Sydney. You might want to ask Judy Kay () about it directly; I suspect she's not on this list, but I believe she is/was involved with the research. OK, John. From sam-fans-owner Fri Aug 13 12:22:39 1993 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <2685>; Fri, 13 Aug 1993 12:21:52 -0400 From: mhw@minster.york.ac.uk Date: Fri, 13 Aug 1993 13:14:57 -0400 Message-ID: Subject: Help-style cut and paste. To: sam-fans@hawkwind.utcs.toronto.edu Sender: "Mark H. Wilkinson" X-Mailer: Sendmail/ream v4.12bv I've been using Rob's help system under Plan 9 a bit recently and have become so used to using mouse button chords to cut and paste that returning to a system where these operations are selected from a menu or with key presses feels awkward. Hence this patch, which puts this feature of help into samterm. For those who haven't seen help, mouse chords work like this: you select some text by dragging with the left button down, or by double clicking, as normal. While holding the left button down at the end of the selection operation you can immediately cut it by clicking the middle button or paste over it by clicking the right button. Running these two actions together (i.e. while holding the left button click the middle button and then the right button) is equivalent to snarf. Share and enjoy... -Mark. diff -C 2 -r sam-dist/libframe/frselect.c sam-hack/libframe/frselect.c *** sam-dist/libframe/frselect.c Thu Aug 5 14:29:19 1993 --- sam-hack/libframe/frselect.c Thu Aug 5 18:22:09 1993 *************** *** 42,46 **** f->p0 = p1, f->p1 = p0; frgetmouse(); ! }while(m->buttons & 1); } /* it is assumed p0<=p1 and both were generated by frptofchar() */ --- 42,46 ---- f->p0 = p1, f->p1 = p0; frgetmouse(); ! }while((m->buttons & 7) == 1); } /* it is assumed p0<=p1 and both were generated by frptofchar() */ diff -C 2 -r sam-dist/samterm/flayer.c sam-hack/samterm/flayer.c *** sam-dist/samterm/flayer.c Thu Aug 5 14:17:06 1993 --- sam-hack/samterm/flayer.c Thu Aug 5 18:22:11 1993 *************** *** 236,248 **** if(l->visible!=All) flupfront(l); frselect(&l->f, &mouse); if(l->f.p0==l->f.p1){ ! if(mouse.msec-l->clickf.p0+l->origin==l->p0){ ret = 1; l->click = 0; ! }else l->click = mouse.msec; ! }else l->click = 0; l->p0 = l->f.p0+l->origin, l->p1 = l->f.p1+l->origin; return ret; --- 236,254 ---- if(l->visible!=All) flupfront(l); + if(mouse.msec-l->clickf, &mouse); if(l->f.p0==l->f.p1){ ! if(ret == 1 && l->f.p0+l->origin==l->p0){ ret = 1; l->click = 0; ! }else{ ! ret = 0; l->click = mouse.msec; ! } ! }else{ ! ret = 0; l->click = 0; + } l->p0 = l->f.p0+l->origin, l->p1 = l->f.p1+l->origin; return ret; diff -C 2 -r sam-dist/samterm/main.c sam-hack/samterm/main.c *** sam-dist/samterm/main.c Thu Aug 5 12:16:09 1993 --- sam-hack/samterm/main.c Thu Aug 5 18:31:03 1993 *************** *** 21,24 **** --- 21,25 ---- char lock = 1; char hasunlocked = 0; + int chord = 0; void *************** *** 77,81 **** if(mouse.buttons) flushtyping(1); ! if(mouse.buttons&1){ if(nwhich){ if(nwhich!=which) --- 78,86 ---- if(mouse.buttons) flushtyping(1); ! if(chord == 1 && !mouse.buttons) ! chord = 0; ! if(chord) ! chord |= mouse.buttons; ! else if(mouse.buttons&1){ if(nwhich){ if(nwhich!=which) *************** *** 90,93 **** --- 95,100 ---- }else if(t!=&cmd) outcmd(); + if(mouse.buttons&1) + chord = mouse.buttons; } } *************** *** 104,107 **** --- 111,128 ---- } mouseunblock(); + } + if(chord){ + t = (Text *)which->user1; + if(!t->lock){ + int w = which-t->l; + if(chord&2){ + cut(t, w, 1, 1); + chord &= ~2; + } + if(chord&4){ + paste(t, w); + chord &= ~4; + } + } } } From sam-fans-owner Fri Aug 13 12:29:54 1993 Received: from research.att.com ([192.20.225.3]) by hawkwind.utcs.toronto.edu with SMTP id <2685>; Fri, 13 Aug 1993 12:29:45 -0400 From: rob@research.att.com Date: Fri, 13 Aug 1993 12:29:14 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Aug13.122945edt.2685@hawkwind.utcs.toronto.edu> in my latest, somewhat help-like system, i worked a lot harder on the mouse button chords. the main advance is that if, while holding 1 down, you press 2, release, then press 3, or press 3, release, then press 2, the second button is not a cut or a paste but rather an true undo of the previous operation. thus, 2+3 gives you snarf without modifying the file; 3+2 gives you a way to recover from a buggered paste. it's harder to do in sam, but you might find a way. -rob From sam-fans-owner Thu Sep 9 11:11:17 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <2752>; Thu, 9 Sep 1993 11:10:26 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA12647 (5.65c/IDA-1.4.4 for ); Thu, 9 Sep 1993 11:10:15 -0400 Received: by penfold.cc.gatech.edu id AA06179 (5.65c/IDA-1.4.4 for sam-fans@hawkwind.utcs.utoronto.ca); Thu, 9 Sep 1993 11:10:11 -0400 Date: Thu, 9 Sep 1993 11:10:11 -0400 From: Arnold Robbins Message-Id: <199309091510.AA06179@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.utoronto.ca Subject: feature request I have been using 9term quite happily for some months now, and have gotten addicted to the "page up" button ("review" in the button 3 menu) in the recent versions. I desperately, desperately miss being able to use the same facility in sam. Is there anyone out there who knows something about all this magic X stuff that could supply a patch to make this work? Matty uses 0x81 for the page up key code in libXg. Thanks, Arnold Robbins --- Continuing Education, College of Computing Georgia Tech, Atlanta, GA 30332-0280 Phone: +1 404 894 9214 (has voice mail) E-mail: arnold.robbins@cc.gatech.edu FAX: +1 404 853 9378 "He's not dead, he's metaphysically challenged." - Mystery Science Theatre 3000 From sam-fans-owner Thu Sep 23 17:15:23 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2706>; Thu, 23 Sep 1993 16:57:42 -0400 To: sam-fans Subject: has anyone hacked sam to use VM instead of disk temporaries? Date: Thu, 23 Sep 1993 16:57:32 -0400 From: Chris Siebenmann Message-Id: <93Sep23.165742edt.2706@hawkwind.utcs.toronto.edu> Sam can chew up a lot of disk space for its editor temporaries (in one test just now, about 6 megs to do a change on a 728K file); in the near future I'm not going to have that sort of disk space lying around, although I'll have plenty of VM space. Has anyone already done the work to make disc.c and/or buffer.c just stick everything in VM? - cks [yes, I know this is probably heretical.] From sam-fans-owner Sun Sep 26 10:00:56 1993 Received: from research.att.com ([192.20.225.3]) by hawkwind.utcs.toronto.edu with SMTP id <2702>; Sun, 26 Sep 1993 09:59:15 -0400 From: bobf@research.att.com Date: Sun, 26 Sep 1993 09:58:31 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Sep26.095915edt.2702@hawkwind.utcs.toronto.edu> a new distribution of sam is available in dist/sam/bundle.Z from research.att.com. simultaneously, 9term, the X11 emulation of an 8-1/2 window, is available via anonymous ftp in directory /matty/unicode at cs.su.oz.au. included in the 9term distribution are a font conversion program and several unicode fonts usable in sam and 9term. as a convenience, a copy of the same sam bundle available at research.att.com is also available here. this release of sam adopts the unicode font support added to libXg at the university of sydney. the distribution source tree has been reorganized to easily accommodate 9term and any other program using libXg and libframe. many bugs have been fixed, but other than the X11 unicode font support, there is no new functionality. changes to 9term include support for additional architectures and much improved pseudo-tty handling. the documentation has been cleaned up in both packages. comments and complaints about the 9term distribution should be directed to matty@orthanc.cs.su.oz.au. comments and complaints about sam, libframe, or libXg should be directed to bobf@research.att.com. the README file contains information about tcs, a publicly available unix utility written by Andrew Hume, which converts input from one user-specified character set to output in another user-specified character set. it is useful for converting files in a variety of standard encodings to UTF, the input encoding accepted by libXg. there is a known bug in sam that is devilishly difficult to reproduce. it happens occasionally during routine editing operations and results in a protocol lock-up (indicted by parentheses in the button 2 menu) and the cursor being off-by-one character in the window being edited. if this bug bites you and you are able to reproduce it or provide a detailed description of your editing actions, please notify bobf. we would like to acknowledge the help of Ed Kubaitis, Scott Scwartz, Arnold Robbins and Chris Siebenmann who endured the beta-test of this software. Matty Farrow matty@orthanc.cs.su.oz.au. Bob Flandrena bobf@research.att.com From sam-fans-owner Tue Oct 5 06:04:58 1993 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Tue, 5 Oct 1993 06:02:37 -0400 From: forsyth@minster.york.ac.uk Date: Tue, 5 Oct 1993 05:11:12 -0400 To: sam-fans@hawkwind.utcs.utoronto.ca Message-ID: subject: window managers for x11 has anyone written a small usable window manager for x11? something with the user interface of 8-1/2 would be fine. 9term deals with a single window; i'd like something to replace olwm, twm, etc. From sam-fans-owner Tue Oct 5 06:33:00 1993 Received: from holly.cam.harlequin.co.uk ([193.128.4.58]) by hawkwind.utcs.toronto.edu with SMTP id <2683>; Tue, 5 Oct 1993 06:31:37 -0400 Received: from piaget.harlequin.co.uk (piaget.cam.harlequin.co.uk) by holly.cam.harlequin.co.uk; Tue, 5 Oct 1993 11:32:27 +0100 Received: from fin.harlequin.co.uk by piaget.harlequin.co.uk; Tue, 5 Oct 93 11:32:15 BST From: Paul Hudson Date: Tue, 5 Oct 1993 06:32:15 -0400 Message-Id: <17113.9310051032@fin.harlequin.co.uk> To: forsyth@minster.york.ac.uk Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: window managers for x11 In-Reply-To: References: forsyth> has anyone written a small usable window manager for x11? forsyth> something with the user interface of 8-1/2 would be fine. forsyth> 9term deals with a single window; i'd like something to replace olwm, twm, etc. I use fvwm which is extensively used by Linux people because it's small. I find it rather neat - it can be nmade to look at behave rather like mwm (which I also like) but it's also a virtual WM. P. From sam-fans-owner Tue Oct 5 14:48:06 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Tue, 5 Oct 1993 14:47:45 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 5 Oct 1993 19:45:33 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA10584; Tue, 5 Oct 93 19:44:51 BST Date: Tue, 5 Oct 1993 14:44:51 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9310051844.AA10584@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam patches X-Sun-Charset: US-ASCII Content-Length: 381 > From: bobf%research.att.com@gec-epl.co.uk > Date: Sun, 26 Sep 1993 09:58:31 -0400 > To: sam-fans@hawkwind.utcs.toronto.edu > > a new distribution of sam is available in dist/sam/bundle.Z > from research.att.com. anybody have the various patches (scrolling file menu, key bindings, mouse chords, etc) ported to this release yet? if so/not, where are they available from? steve From sam-fans-owner Tue Oct 5 14:58:31 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Tue, 5 Oct 1993 14:58:17 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA25346 (5.65c/IDA-1.4.4 for ); Tue, 5 Oct 1993 14:58:06 -0400 Received: by penfold.cc.gatech.edu id AA04214 (5.65c/IDA-1.4.4 for sam-fans@hawkwind.utcs.toronto.edu); Tue, 5 Oct 1993 14:58:04 -0400 From: Arnold Robbins Message-Id: <199310051858.AA04214@penfold.cc.gatech.edu> Date: Tue, 5 Oct 1993 14:58:03 -0400 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: latest sam FYI, I was a pretester of the latest sam & 9term. Before blindly patching in the previous sets of patches, it would pay to note two things. 1) A ``page-up'' key is now suppoted in both samterm and 9term, supplied to the app from libXg as 0x81. I helped graft the one major line from Ed's samx patches into samterm. (This is the biggest win for me personally.) 2) Sam, samterm, and 9term all now do full Unicode/UTF. I *think* this obsoletes the latin1 part of Ed's samx patches. The other things (scrolling menus etc) haven't changed, so I'm not saying that the patches aren't needed, just that two big things aren't needed anymore... (I'm also one of the people who keeps getting hit w/the protocol bug. sigh.) It's a lot of fun to type alt-1-2 and get B= (b:) [ Install the unicode fonts and then look at this note (and pray no high bits get stripped) ]. Arnold From sam-fans-owner Tue Oct 5 15:14:26 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Tue, 5 Oct 1993 15:14:14 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2580>; Tue, 5 Oct 1993 15:13:48 -0400 To: Arnold Robbins cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: latest sam In-reply-to: Your message of "Tue, 05 Oct 1993 14:58:03 EDT." <199310051858.AA04214@penfold.cc.gatech.edu> Date: Tue, 5 Oct 1993 15:13:38 -0400 From: Scott Schwartz Message-Id: <93Oct5.151348edt.2580@groucho.cse.psu.edu> | 1) A ``page-up'' key is now suppoted in both samterm and 9term, supplied to | the app from libXg as 0x81. I helped graft the one major line from Ed's | samx patches into samterm. (This is the biggest win for me personally.) Yes, it is nice. | 2) Sam, samterm, and 9term all now do full Unicode/UTF. One thing to watch out for is editing iso-8859-1 files, which sam will now mutate, since they typically contain invalid utf. For a fun time, snarf the tcs stuff from research and look at the test files. I tried to collect people who could read all of them. :-) | It's a lot of fun to type alt-1-2 and get B= (b:) [ Install the unicode fonts | and then look at this note (and pray no high bits get stripped) ]. Well, they did. (My mailer is 8 bit clean, so someone else's must have done it.) You can also use the compose key (Multi_key in X-speak) if you have one, like this... ½:) From sam-fans-owner Tue Oct 5 16:19:59 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2699>; Tue, 5 Oct 1993 16:18:28 -0400 To: sam-fans Subject: Re: sam patches In-reply-to: steve's message of Tue, 05 Oct 93 14:44:51 -0400. <9310051844.AA10584@zombie.gec-epl.co.uk> Date: Tue, 5 Oct 1993 16:18:26 -0400 From: Chris Siebenmann Message-Id: <93Oct5.161828edt.2699@hawkwind.utcs.toronto.edu> All of my standard patches dropped in cleanly, for a data point. If people are interested, I can send my readme on them to the list. And the UTF support and scroll-backwards key are very nice new features. - cks From sam-fans-owner Tue Oct 5 16:23:33 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Tue, 5 Oct 1993 16:23:21 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 5 Oct 1993 21:22:57 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA11118; Tue, 5 Oct 93 21:22:46 BST Date: Tue, 5 Oct 1993 16:22:46 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9310052022.AA11118@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam patches X-Sun-Charset: US-ASCII Content-Length: 372 > All of my standard patches dropped in cleanly, for a data point. > If people are interested, I can send my readme on them to the list. well, i'm obviously interested.:-) > And the UTF support and scroll-backwards key are very nice new features. haven't got as far as checking that out yet - still trying to get 9term running smoothly under solaris 2.2 again (#$@%!) From sam-fans-owner Tue Oct 5 16:38:49 1993 Received: from research.att.com ([192.20.225.3]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Tue, 5 Oct 1993 16:38:32 -0400 From: bobf@research.att.com Date: Tue, 5 Oct 1993 16:27:59 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Oct5.163832edt.2679@hawkwind.utcs.toronto.edu> please apply the following patch to samterm/mesg.c to fix the protocol synchronization problem: 562a561 < t->lock++; the context of the change is: panic("hcheck request==0"); outTsls(Trequest, m, a, (int)n); outTs(Tcheck, m); > t->lock++; t->lock++; reqd++; the bug has existed for a long time; it is probably a remnant of the original design where text-locks were non-accumulative. the bug usually manifests itself when there is a slow channel between sam and samterm. From sam-fans-owner Tue Oct 5 16:50:27 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Tue, 5 Oct 1993 16:50:00 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 5 Oct 1993 21:49:30 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA11162; Tue, 5 Oct 93 21:49:17 BST Date: Tue, 5 Oct 1993 16:49:17 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9310052049.AA11162@zombie.gec-epl.co.uk> To: forsyth Subject: Re: window managers for x11 Cc: sam-fans@hawkwind.utcs.toronto.edu X-Sun-Charset: US-ASCII Content-Length: 432 > From: forsyth%minster.york.ac.uk@gec-epl.co.uk > has anyone written a small usable window manager for x11? > something with the user interface of 8-1/2 would be fine. > 9term deals with a single window; i'd like something to replace olwm, twm, etc. well, i notice in the TODO file of the 9term distribution: > - add support for interaction with 9wm is 9wm in the TODO list too, or does it actually exist somewhere? what gives? From sam-fans-owner Wed Oct 6 09:27:21 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2683>; Wed, 6 Oct 1993 09:26:39 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Wed, 6 Oct 1993 14:26:25 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA12492; Wed, 6 Oct 93 14:26:11 BST Date: Wed, 6 Oct 1993 09:26:11 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9310061326.AA12492@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: printing utf X-Sun-Charset: US-ASCII Content-Length: 287 ok, so i've got sam and 9term running with the utf fonts - having produced some files with utf in them, any idea how i'd print them on a postscript printer..? [ this is probably a dumb question, but then it took me 2.5 hours last night just to get the X fonts installed. sigh. ] steve From sam-fans-owner Wed Oct 6 10:14:30 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Wed, 6 Oct 1993 10:14:02 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA21394 (5.65c/IDA-1.4.4 for ); Wed, 6 Oct 1993 10:13:50 -0400 Received: by penfold.cc.gatech.edu id AA04629 (5.65c/IDA-1.4.4 for sam-fans@hawkwind.utcs.toronto.edu); Wed, 6 Oct 1993 10:13:48 -0400 From: Arnold Robbins Message-Id: <199310061413.AA04629@penfold.cc.gatech.edu> Date: Wed, 6 Oct 1993 10:13:47 -0400 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: simple acting window managers John Mackin (now no longer on the net, I believe) put together a window manager that looks very ``blit'' like. He did this using gwm (the generic window manager) which allows you to customize the window manager's behaviour by writing scripts in WOOL (Windows Object Oriented Lisp). (E.g., gwm comes with both twm and mwm emulations, which I haven't tried.) His code relies on gwm 1.7i, which is somewhat behind the current version of gwm (1.7o, I believe). He also included a blit.bdf file for a font that looks an awful lot like the original font in the rom of the DMD 5620. (Whether the blit font is a bug or a feature is a matter of opinion -- personally, I much prefer the Plan 9 fonts Matty's distributing.) I have been using his code for ~ a month or so and it's nice and simple, and although not exactly blindingly fast, it's not intorlerably slow either. ANYWAY, ``can you get this?'' The answer is yes. As of today, it could still be ftp'ed from the root directory of ftp.civil.su.oz.au, in the file gwm-dist.tar. If it ever disappears from there, I'll make it available. This file is not compressed, since its major contents are the compressed gwm distribution. Basically, get it, untar gwm, apply John's patch, and then build. Follow the rest of his instructions to install the stuff. You will have to manually patch John's gwm code to a) use the pelm.latin1.9 fonts in the menus instead of the blit font, and b) use 9term as the default terminal emulator (John used xterm). This is not hard, and if pressed, I will supply a patch to the mailing list. You will also have to supply an `rxterm' program that spawns xterms on remote systems. This is also not hard to do. You're better off using it with R5 than R4 - under R4 I've had weird behaviour dealing with colormaps and stuff. (I'm not an X jock, so I can't be more specific. When it comes to X, I type 'make' and pray that it works. :-) 9wm exists, but it is apparently in rather ``alpha'' shape at the moment. (I was told that it was crashing daily.) I don't have a copy of it, and don't know what the scoop is on its progress. Until it happens, John's blit+gwm is probably a good bet for most folks. In between it, 9term, and sam, I feel like I *finally* have a clean simple windowing environment. Enjoy, Arnold Robbins --- Continuing Education, College of Computing Georgia Tech, Atlanta, GA 30332-0280 Phone: +1 404 894 9214 (has voice mail) E-mail: arnold.robbins@cc.gatech.edu FAX: +1 404 853 9378 "He's not dead, he's metaphysically challenged." - Mystery Science Theatre 3000 P.S. If someone would just port libg to MGR, we'd all be in even better shape. From sam-fans-owner Wed Oct 6 13:04:41 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2683>; Wed, 6 Oct 1993 13:04:17 -0400 To: sam-fans Subject: Re: simple acting window managers In-reply-to: arnold's message of Wed, 06 Oct 93 10:13:47 -0400. <199310061413.AA04629@penfold.cc.gatech.edu> Date: Wed, 6 Oct 1993 13:04:05 -0400 From: Chris Siebenmann Message-Id: <93Oct6.130417edt.2683@hawkwind.utcs.toronto.edu> You can also get gwm-dist.tar from ftp.sys.utoronto.ca in /pub/9term. - cks From sam-fans-owner Thu Oct 7 15:05:47 1993 Received: from mail.cs.tu-berlin.de ([130.149.17.13]) by hawkwind.utcs.toronto.edu with SMTP id <2683>; Thu, 7 Oct 1993 15:04:11 -0400 Received: from gimli.cs.tu-berlin.de by mail.cs.tu-berlin.de with SMTP id AA03063 (5.65c8/IDA-1.4.4(mail.m4[1.12]) for ); Thu, 7 Oct 1993 16:24:31 +0100 From: "Robert T. Raschke" Message-Id: <199310071524.AA03063@mail.cs.tu-berlin.de> Subject: Where can I find 9term in Europe ? To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 7 Oct 1993 11:24:29 -0400 X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 409 Hi, having read all the postings about 9term, blit like window managers, and the fonts for UTF encoded files, I want to join in on the fun. Connections outside of Europe are very trying, though. So I would appreciate pointers to locations where I can find all these things here in Europe. Thanks for any help, Robert. -- Robert Raschke TU Berlin, Germany rraschke@cs.tu-berlin.de From sam-fans-owner Fri Oct 8 02:55:56 1993 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Fri, 8 Oct 1993 02:55:29 -0400 Received: from orthanc.cs.su.OZ.AU by joyce.cs.su.OZ.AU (for sam-fans@hawkwind.utcs.toronto.edu) with MHSnet; Thu, 07 Oct 1993 14:23:50 +1000 To: sam-fans@hawkwind.utcs.toronto.edu Message-ID: <19931007141502.24890.frobozz@orthanc.cs.su.OZ.AU> In-Reply-To: <9310061326.AA12492@zombie.gec-epl.co.uk> From: matty@cs.su.oz.au (James Matthew Farrow) Date: Thu, 7 Oct 1993 00:15:02 -0400 Organisation: Basser Dept of Computer Science, Sydney University, Australia X-Name: James Matthew Farrow X-Face: B>D@!+;vE|ETmR!+pig${%L"["]tFj(v@m_F%@}o2q03)'6{jCds#> #sO^kokjP\LcmO}sB(,^SzSSq@v0x~UXrC \GJ3=i7FUOBLO}]EIuK(K4}LMg,=R7(#B3G&<"r1U~mct?!;M\z:lV To: sam-fans@hawkwind.utcs.toronto.edu Subject: printing utf X-Sun-Charset: US-ASCII Content-Length: 287 ok, so i've got sam and 9term running with the utf fonts - having produced some files with utf in them, any idea how i'd print them on a postscript printer..? [ this is probably a dumb question, but then it took me 2.5 hours last night just to get the X fonts installed. sigh. ] steve Currently to print I am doing two things. I have a latin1 `device' for troff which uses ISOLatin1Encoding for PostScript fonts rather than the Adobe StandardEndcoding. I have a filter which reads utf files and can produce plain ascii approximations (`;-)' for `☺' (a smiley) for example) or troff codes when asked, so `→' (that's a right arrow) becomes `\(->'). It's a hack, but hey, it gets Welsh poetry printed with wcirumflex and ycircumflex! I can make this available but it's written using bio at the moment and I can't release that so I'd have to rewrite it. I also want a more general solution to the problems `unutf' tackles. I originally intended it for use in our department here as a MIME decoder for utf-2 so the members of our department without 9terms could handle utf-2 mail. A more general solution again I've thought about but requires a rethinking to some extent of the tools people use when printing. To handle the printing of utf-2 strings in PostScript you'd need something to decode the encoding at the PostScript level if you want to include them in the strings themselves, perhaps something akin to `(general utf string) utfshow'. Matty. -- James Matthew Farrow | "For in that moment I beheld the ruin matty@cs.su.OZ.AU | of my existence. My world fell dark Basser Department of Computer Science | and my life became a shallow dream. Sydney University - FAX: +61 2 692 3838 | `Odi et amo. Excrucior.'" - Tlindah From sam-fans-owner Sat Oct 9 05:42:15 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Sat, 9 Oct 1993 05:41:08 -0400 Received: from moscvax.demos.su by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11557; Sat, 9 Oct 93 05:40:53 -0400 Received: by moscvax.demos.su id AA01066 (5.65c/IDA-1.4.4 for sam-fans@hawkwind.utcs.toronto.edu); Fri, 8 Oct 1993 21:15:54 +0300 Received: by kremvax.hq.demos.su; Fri, 8 Oct 1993 20:45:31 +0300 Received: by phreak.ex952.demos.su; Fri, 8 Oct 1993 18:43:58 +0300 Received: by ibs.msk.su (UUPC/@ v5.09gamma, 14Mar93); Fri, 8 Oct 1993 15:44:52 +0300 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: Organization: Intermicro BS From: DDW@ibs.msk.su (Dmitry Doronin) Date: Fri, 8 Oct 1993 07:44:52 -0400 Return-Receipt-To: ddw@ibs.msk.su X-Mailer: dMail (Demos Mail v1.13a) Subject: unsubscribe me! Lines: 3 Please delete me from this list! -ddw From sam-fans-owner Mon Oct 11 04:49:02 1993 Received: from emory.mathcs.emory.edu ([128.140.110.1]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Mon, 11 Oct 1993 04:48:02 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.12) via UUCP id AA08385 ; Mon, 11 Oct 93 04:19:31 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Mon, 11 Oct 93 04:18 EDT Message-Id: Date: Mon, 11 Oct 1993 04:18:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: sam-fans@hawkwind.utcs.toronto.edu Subject: ring my bell Matty has the bell code in 9term disabled - you have to define BEEP and you only get a bell if in Unix mode. Me, I like to start a long running job and then echo '^G' when I'm done to tell me I can come back to my system. So, here's a patch for 9term.c that makes beeping a button 3 item, independent of the unix/plan 9 keyboard mode. Not beeping is the default behaviour, so this won't affect you if you don't want bells anyway. And hey, if you consider this a trivial patch, don't apply it, but don't bother to flame me about it. It makes my life easier. :-) Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold@skeeve.ATL.GA.US | exponentially in the UUCP: { gatech, emory }!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins --------- *** 9term.h.orig Sat Sep 11 00:37:27 1993 --- 9term.h Mon Oct 11 04:05:03 1993 *************** *** 17,22 **** --- 17,23 ---- extern int comm_fd; extern int slave_fd; extern int kbdmode; + extern int dobeep; extern int utmpentry; extern Rune intrchar; *** 9term.c.orig Sat Sep 11 00:38:34 1993 --- 9term.c Mon Oct 11 04:11:09 1993 *************** *** 30,36 **** mSCROLL }; ! static char *modenames[] = {"fwd","bkwd","suspend","view","review",0,0}; static Menu kmode = {modenames} ; enum { mFWD, mBKWD, --- 30,36 ---- mSCROLL }; ! static char *modenames[] = {"fwd","bkwd","suspend","view","review",0,0,0}; static Menu kmode = {modenames} ; enum { mFWD, mBKWD, *************** *** 37,46 **** --- 37,48 ---- mSUSP, mVIEW, mREVIEW, + mBEEP, mMODE }; int kbdmode = PLAN9; + int dobeep = 0; static Cursor whitearrow = { {0, 0}, *************** *** 283,291 **** FLUSHBUF(); *q++ = *p; break; - #ifdef BEEP case 0x07: ! if (kbdmode == UNIX) beep(); else { if (q >= &buf[EMAXMSG]) /* buffer full? */ --- 285,292 ---- FLUSHBUF(); *q++ = *p; break; case 0x07: ! if (dobeep) beep(); else { if (q >= &buf[EMAXMSG]) /* buffer full? */ *************** *** 293,299 **** *q++ = *p; } break; - #endif case '\b': /* backspace at output point */ if (q > buf) q--; --- 294,299 ---- *************** *** 432,437 **** --- 432,438 ---- { kmode.item[mMODE] = (kbdmode == PLAN9) ?"unix":"plan 9"; kmode.item[mSUSP] = suspended ? "resume" : "suspend"; + kmode.item[mBEEP] = dobeep ? "nobeep" : "beep"; switch (menuhit(3, m, &kmode)) { case mFWD: *************** *** 451,456 **** --- 452,460 ---- break; case mREVIEW: textset(text, _backnl(text, text->base, text->f.maxlines/2)); + break; + case mBEEP: + dobeep = ! dobeep; break; case mMODE: if (kbdmode == UNIX) From sam-fans-owner Mon Oct 11 23:29:30 1993 Received: from daedalus.dcrt.nih.gov ([128.231.129.209]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Mon, 11 Oct 1993 23:29:13 -0400 Received: from localhost (weisen@localhost) by daedalus.dcrt.nih.gov (ALPHA-6.58/6.28) id XAA16822; Mon, 11 Oct 1993 23:28:11 -0400 Message-Id: <199310120328.XAA16822@daedalus.dcrt.nih.gov> To: DDW@ibs.msk.su (Dmitry Doronin) cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: unsubscribe me! In-reply-to: Your message of "Fri, 08 Oct 1993 07:44:52 EDT." X-Mailer: MH [6.8+MIME] Date: Mon, 11 Oct 1993 23:28:07 -0400 From: Neil Weisenfeld In message , Dmitry Doronin writes: > Please delete me from this list! > -ddw Send it to sam-fans-request (!). --neil From sam-fans-owner Tue Oct 12 12:01:57 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Tue, 12 Oct 1993 11:52:05 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA05606; Tue, 12 Oct 93 11:51:45 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA02194; Tue, 12 Oct 93 11:52:16 -0400 Date: Tue, 12 Oct 1993 11:52:16 -0400 From: rsalz@osf.org Message-Id: <9310121552.AA02194@sulphur.osf.org> To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term on hpux9.0 Has anyone got 9term running on hpux 9.0? I'm a little too harried to figure out yet another pty scheme/"portable ioctl" scheme right now and pty.c won't compile. Tnx. /r$ From sam-fans-owner Fri Oct 15 10:07:41 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2723>; Fri, 15 Oct 1993 09:54:17 -0400 Received: by mod.civil.su.oz.au id <28693>; Fri, 15 Oct 1993 23:53:36 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Fri, 15 Oct 1993 09:41:05 -0400 To: Sam Fans Subject: Rumours of my net.death (somewhat) exaggerated :) In-Reply-To: <199310061413.AA04629@penfold.cc.gatech.edu> Message-ID: <199310152341.15549.sam.bagas@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I wanted to post a few clarifications regarding Arnold's recent message about the gwm stuff that I've worked on. Most of what he says is quite correct; I just want to set the record straight on some minor points. First off, thanks to Arnold for his positive comments, and for being interested in trying out the code. I'm very pleased that he likes it and continues to use it. John Mackin (now no longer on the net, I believe) Well, I'm still (barely) here. A little. For another couple of weeks... When I have really left, I will still be mailable at , although I will eventually cut down to reading that only now and then and consequently I will be leaving all the lists that I'm on... but I haven't quite done that yet. John Mackin ... put together a window manager that looks very ``blit'' like. He did this using gwm (the generic window manager) Credits department: I did all the initial work on this stuff, but its further development and design was done in collaboration with David Hogan. Some of the newer parts (e.g., icon menus) are purely David's. Noel Hunt used the code for a long time and helped get bugs out of it. ANYWAY, ``can you get this?'' The answer is yes. As of today, it could still be ftp'ed from the root directory of ftp.civil.su.oz.au, in the file gwm-dist.tar. I won't remove this. I should update it but probably won't get time. 9wm exists, but it is apparently in rather ``alpha'' shape at the moment. David wrote this from the ground up. He hasn't worked on it in a while. It's not 100% solid and is fairly incomplete, ICCC-wise, although the basic core WM is there. Good luck, people. Drop me a note if you like the gwm stuff. OK, John. From sam-fans-owner Fri Oct 29 05:10:32 1993 Received: from ccub.wlv.ac.uk ([134.220.1.20]) by hawkwind.utcs.toronto.edu with SMTP id <32811>; Fri, 29 Oct 1993 05:06:27 -0400 Received: by ccub.wlv.ac.uk (UK-Smail 3.1.28.1/9) id ; Fri, 29 Oct 93 09:09 GMT X-NUPop-Charset: English Date: Fri, 29 Oct 1993 05:09:31 -0400 From: "Max Caines" Sender: in1012@ccub.wlv.ac.uk Message-Id: <32972.in1012@ccub.wlv.ac.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Patches I have just put up a copy of 'sam' after reading about it in the UK magazine .EXE. The writer mentions that there are some patches available to implement 'move to type' on the mouse pointer rather than 'click to type'. As I have used X this way for some time, I'd like to put those patches in. Can anyone point me to them? I'm running it on a Sun with SunOS 4.1.2. Please send replies to me direct, as I'm not on the mailing list (yet, anyway). I do have access to USENET news, if it simplifies things at all. Looks like a nice package, by the way - my appreciation to those who support it. Thanks +-------------------------------------------------------------------+ | Max Caines | M.B.Caines@CCUB.WLV.AC.UK | | Technical Services Manager | JANET: M.B.Caines@UK.AC.WLV.CCUB | | Computer Centre | Phone: 0902 322245 | | Wolverhampton University | Fax: 0902 322777 | +-------------------------------------------------------------------+ From sam-fans-owner Wed Nov 3 18:31:45 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <32814>; Wed, 3 Nov 1993 18:21:26 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA12528; Wed, 3 Nov 93 18:21:03 -0500 Date: Wed, 3 Nov 1993 18:21:03 -0500 From: plexus-sys!mdash@uunet.uu.net Message-Id: <9311032321.AA12528@relay2.UU.NET> Received: from plexus-sys.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 182000.19405; Wed, 3 Nov 1993 18:20:00 EST To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term on SVR4 Content-Type: text Content-Length: 763 Using sources picked up about a month ago, I built 9term on an i486 box running SVR4.0 (MicroPort, but that shouldn't matter). When output fills the window, the terminal emulator dies deep in the innards of libX11 (MIT R5 sources vintage about mid-1992). The server is NCD's latest. The eread is the first one to follow the window filling. Stack and diagnostics are below. Familiar? --Mike Scheer, mdash@plexus-sys.com _XError() _XEventsQueued() XEventsQueued() XtAppPending() eread() run() X Error of failed request: BadPixmap (invalid Pixmap parameter) Major opcode of failed request: 56 (X_ChangeGC) Resource id in failed request: 0x0 Serial number of failed request: 452 Current serial number in output stream: 459 From sam-fans-owner Thu Nov 4 08:14:45 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <32814>; Thu, 4 Nov 1993 08:13:22 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23315; Thu, 4 Nov 93 08:13:12 -0500 Received: from rexago8.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 081129.12012; Thu, 4 Nov 1993 08:11:29 EST Received: by summitis.com (smail2.5) id AA21944; 4 Nov 93 07:36:41 EST (Thu) Received: from beirnek by rserv1.YYY; Thu, 4 Nov 1993 07:37 EST Received: by beirnek (AIX 3.2/UCB 5.64/4.03) id AA17977; Thu, 4 Nov 1993 07:35:12 -0500 From: hc05%beirnek@uunet.UU.NET (Beirne Konarski) Message-Id: <9311041235.AA17977@beirnek> Subject: I give up To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 4 Nov 1993 07:35:10 -0500 X-Mailer: ELM [version 2.3 PL9] Content-Type: text Content-Length: 963 OK, I have been using SAM for a week now, trying to figure out why it is a good editor to use. I am now giving up. The documentation implies that it is better than vi(my favorite) or emacs, but I cannot figure out why. Sure, it has a clever command language and it has not internal limits, but it is hard to use for heavy-duty writing and editing. It doesn't autoindent, and I need three hands to operate the keyboard and the mouse. I can see using it in some special cases, like when I need to work with a big file, but it makes no sense otherwise. Is there something I am missing? Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Thu Nov 4 10:56:49 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <32814>; Thu, 4 Nov 1993 10:56:14 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA07994; Thu, 4 Nov 93 10:56:07 -0500 Date: Thu, 4 Nov 1993 10:56:07 -0500 From: plexus-sys!mdash@uunet.uu.net Message-Id: <9311041556.AA07994@relay1.UU.NET> Received: from plexus-sys.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 105513.25294; Thu, 4 Nov 1993 10:55:13 EST To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term on SVR4 again Content-Type: text Content-Length: 536 I earlier wrote: Using sources picked up about a month ago, I built 9term on an i486 box running SVR4.0 (MicroPort, but that shouldn't matter). When output fills the window, the terminal emulator dies deep in the innards of libX11... etc. So I learned a little about debugging 9term and X11. I hadn't defined POSIXPTYS, ended up with ttmode.c_cc too small, and gttymodes stepped on _dkgrey. New issue: Is, ahem, cursor addressability feasible with 9term? No flames, please; sam is only one of several editors I use. From sam-fans-owner Thu Nov 4 11:04:31 1993 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <32815>; Thu, 4 Nov 1993 11:04:12 -0500 From: pete@minster.york.ac.uk Date: Thu, 4 Nov 1993 10:58:44 -0500 Message-ID: To: hc05%beirnek@uunet.UU.NET, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: I give up Autoindent can be hacked in (one of the many patches that have been posted handles this, if you really want it). Have you also tried the keyboard patches which allow a slightly more "conventional" user interface? "Pure" sam is a bit uncompromising; many people find it too austere for their taste. I've _applied_ most of the patches, but don't find myself using most of them (with the exception of cursor keys and cut/copy/paste).... pete From sam-fans-owner Thu Nov 4 13:13:49 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <32817>; Thu, 4 Nov 1993 13:13:29 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29476; Thu, 4 Nov 93 13:13:06 -0500 Received: from rexago8.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 131200.18919; Thu, 4 Nov 1993 13:12:00 EST Received: by summitis.com (smail2.5) id AA00799; 4 Nov 93 12:53:47 EST (Thu) Received: from beirnek by rserv1.YYY; Thu, 4 Nov 1993 12:54 EST Received: by beirnek (AIX 3.2/UCB 5.64/4.03) id AA11890; Thu, 4 Nov 1993 12:52:12 -0500 From: hc05%beirnek@uunet.UU.NET (Beirne Konarski) Message-Id: <9311041752.AA11890@beirnek> Subject: Re: patches To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 4 Nov 1993 12:52:11 -0500 In-Reply-To: <9311041711.AA38107@rexsrvr2.summitis.com>; from "sam-fans-owner@rexago8.YYY" at Nov 4, 93 12:12 pm X-Mailer: ELM [version 2.3 PL9] Content-Type: text Content-Length: 877 >Autoindent can be hacked in (one of the many patches that have been posted >handles this, if you really want it). Have you also tried the keyboard >patches which allow a slightly more "conventional" user interface? > >"Pure" sam is a bit uncompromising; many people find it too austere for their >taste. I've _applied_ most of the patches, but don't find myself using most >of them (with the exception of cursor keys and cut/copy/paste).... The patches sound promising. How do I get them? Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Thu Nov 4 19:01:59 1993 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu with SMTP id <32815>; Thu, 4 Nov 1993 19:00:30 -0500 Received: by quux.es.su.oz.au id <1304>; Fri, 5 Nov 1993 10:48:01 +1100 From: noel@es.su.oz.au Date: Thu, 4 Nov 1993 18:45:27 -0500 to: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term on SVR4 again In-Reply-To: <9311041556.AA07994@relay1.UU.NET> Message-ID: <199311051045.10994.out.badiy@es.su.oz.au> From: plexus-sys!mdash@uunet.uu.net Subject: 9term on SVR4 again New issue: Is, ahem, cursor addressability feasible with 9term? No flames, please; sam is only one of several editors I use. oh my god! From sam-fans-owner Thu Nov 11 11:44:16 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <32818>; Thu, 11 Nov 1993 11:40:27 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24142; Thu, 11 Nov 93 11:40:05 -0500 Date: Thu, 11 Nov 1993 11:40:05 -0500 From: plexus-sys!mdash@uunet.uu.net Message-Id: <9311111640.AA24142@relay2.UU.NET> Received: from plexus-sys.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 113859.25085; Thu, 11 Nov 1993 11:38:59 EST To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term sttys Content-Type: text Content-Length: 352 Has anyone else seen 9term get confused saving and restoring termios? I see it getting into a state where application-issued sttys are lost; this first came to my attention with /bin/su echoing the password. It appears to be timing-related. Debugging is complicated by the large number of tcsetattrs/TCSETAs done. --Mike Scheer, mdash@plexus-sys.com From sam-fans-owner Fri Nov 12 03:47:48 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <32822>; Fri, 12 Nov 1993 03:47:09 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Fri, 12 Nov 1993 08:46:45 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA13816; Fri, 12 Nov 93 08:46:26 GMT Date: Fri, 12 Nov 1993 03:46:26 -0500 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9311120846.AA13816@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term sttys X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 165 what platform are you running it on, and which version are you using? i did have some problems with an earlier version, but the utf version seems fine to me. steve From sam-fans-owner Fri Nov 12 07:37:05 1993 Received: from mail.cs.tu-berlin.de ([130.149.17.13]) by hawkwind.utcs.toronto.edu with SMTP id <32823>; Fri, 12 Nov 1993 07:36:18 -0500 Received: from gandalf.cs.tu-berlin.de by mail.cs.tu-berlin.de with SMTP id AA20109 (5.65c8/IDA-1.4.4(mail.m4[1.12]) for ); Fri, 12 Nov 1993 11:40:01 +0100 From: "Robert T. Raschke" Message-Id: <199311121040.AA20109@mail.cs.tu-berlin.de> Subject: Re: 9term sttys To: sam-fans@hawkwind.utcs.toronto.edu Date: Fri, 12 Nov 1993 05:39:59 -0500 X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 768 Hello, I have somewhat similar problems on SunOS 4.1.3 with the new utf version of 9term. For some reason the slave pseudo tty does not return anything when queried by tcgetattr. Especially ICANON and ECHO appear not to be set. Thus I cannot use the suspend mode, which is my main motivation for using 9term. Another problem I encounter happens when I switch to unix mode. Characters will only appear in chunks of 4. I type three characters and nothing happens and when I type the fourth all four characters appear. I have not looked into the utf character handling, but I suspect it has something to do with that. Sometimes 9term will just die when I switch between unix and plan9 modes. Any help out there ? Robert -- Robert Raschke rraschke@cs.tu-berlin.de From sam-fans-owner Fri Nov 12 09:09:12 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <32824>; Fri, 12 Nov 1993 09:08:50 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Fri, 12 Nov 1993 14:08:11 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA14236; Fri, 12 Nov 93 14:07:49 GMT Date: Fri, 12 Nov 1993 09:07:49 -0500 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9311121407.AA14236@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term sttys X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 1734 > I have somewhat similar problems on SunOS 4.1.3 with the new utf version > of 9term. For some reason the slave pseudo tty does not return anything when > queried by tcgetattr. Especially ICANON and ECHO appear not to be set. > Thus I cannot use the suspend mode, which is my main motivation for using > 9term. hmm. are you rlogged into another machine when this happens, or is that always the case? when you rlogin to another machine 9term's pty goes into raw mode, and suspend is not allowed then (you get round this by rlogging in, then running 9term on the remote machine with DISPLAY set). of course, if you're using plan9 mode on a unix box, things might not work as you expect anyway. i'd stick to unix mode all the time if i were you. > Another problem I encounter happens when I switch to unix mode. Characters > will only appear in chunks of 4. I type three characters and nothing happens > and when I type the fourth all four characters appear. I have not looked > into the utf character handling, but I suspect it has something to do with > that. Sometimes 9term will just die when I switch between unix and plan9 > modes. could be due to your terminal settings. here's what i use... speed 9600 baud, 23 rows, 90 columns parenb -parodd cs7 -cstopb -hupcl cread -clocal -crtscts -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc ixon -ixany -ixoff imaxbel isig iexten icanon -xcase echo echoe echok -echonl -noflsh -tostop echoctl -echoprt echoke opost -olcuc -onlcr -ocrnl -onocr onlret -ofill -ofdel -tabs erase kill werase rprnt flush lnext susp intr quit stop eof ^? ^U ^W ^R ^O ^V ^Z/^Y ^C ^\ ^S/^Q ^D hope this helps. steve From sam-fans-owner Fri Nov 12 10:44:12 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <32825>; Fri, 12 Nov 1993 10:43:41 -0500 Return-Path: uunet.UU.NET!plexus-sys!mdash Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <32824>; Fri, 12 Nov 1993 07:20:16 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA22895; Fri, 12 Nov 93 07:20:02 -0500 Date: Fri, 12 Nov 1993 07:20:02 -0500 From: plexus-sys!mdash@uunet.uu.net Message-Id: <9311121220.AA22895@relay1.UU.NET> Received: from plexus-sys.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 071904.870; Fri, 12 Nov 1993 07:19:04 EST To: uunet!hawkwind.utcs.toronto.edu!sam-fans-owner@uunet.UU.NET (Steve_Kilbane) Subject: Re: 9term sttys Content-Type: text Content-Length: 266 Resent-To: sam-fans Resent-Date: Fri, 12 Nov 1993 10:43:34 -0500 Resent-From: Chris Siebenmann Resent-Message-Id: <93Nov12.104341est.32825@hawkwind.utcs.toronto.edu> I'm running the utf version on SVR4 on an intel box. It looks to me like the problem is inherent in the design of 9term, and have sent mail to Matty Farrow. I'd rather let him respond than to start pointing the finger publicly. --Mike Scheer, mdash@plexus-sys.com From sam-fans-owner Fri Nov 12 16:48:51 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <32826>; Fri, 12 Nov 1993 16:45:12 -0500 To: sam-fans Subject: Re: 9term sttys In-reply-to: steve's message of Fri, 12 Nov 1993 09:07:49 -0500. <9311121407.AA14236@zombie.gec-epl.co.uk> Date: Fri, 12 Nov 1993 16:44:57 -0500 From: Chris Siebenmann Message-Id: <93Nov12.164512est.32826@hawkwind.utcs.toronto.edu> | of course, if you're using plan9 mode on a unix box, things might not work | as you expect anyway. i'd stick to unix mode all the time if i were you. I haven't had any particular problems with plan 9 mode on our Unix machines; switching to unix mode unfortunately loses a bunch of neat features. - cks From sam-fans-owner Sun Nov 14 23:03:23 1993 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <32822>; Sun, 14 Nov 1993 23:02:13 -0500 Received: from orthanc.cs.su.OZ.AU by joyce.cs.su.OZ.AU (mail from matty for sam-fans@hawkwind.utcs.toronto.edu) with MHSnet; Mon, 15 Nov 1993 15:01:57 +1100 To: sam-fans@hawkwind.utcs.toronto.edu Message-ID: <19931115145800.4852.frobozz@orthanc.cs.su.OZ.AU> From: matty@cs.su.oz.au (James Matthew Farrow) Date: Sun, 14 Nov 1993 23:58:00 -0500 Organisation: Basser Dept of Computer Science, Sydney University, Australia X-Name: James Matthew Farrow X-Face: B>D@!+;vE|ETmR!+pig${%L"["]tFj(v@m_F%@}o2q03)'6{jCds#> #sO^kokjP\LcmO}sB(,^SzSSq@v0x~UXrC \GJ3=i7FUOBLO}]EIuK(K4}LMg,=R7(#B3G&<"r1U~mct?!;M\z:lV; Wed, 17 Nov 1993 19:25:50 -0500 Received: by sis.yorku.ca (4.1/SMI-4.1) id AA23241; Wed, 17 Nov 93 19:21:21 EST Date: Wed, 17 Nov 1993 19:21:21 -0500 From: "Ozan S. Yigit" Message-Id: <9311180021.AA23241@sis.yorku.ca> To: sam-fans@hawkwind.utcs.toronto.edu Subject: undo positioning? should undo position the current window such that whatever is being undone is always in view? ie. blind undo considered harmful. oz From sam-fans-owner Wed Nov 17 19:57:46 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.edu with SMTP id <23982>; Wed, 17 Nov 1993 19:48:47 -0500 Received: from localhost by groucho.cse.psu.edu with SMTP id <2516>; Wed, 17 Nov 1993 19:47:46 -0500 To: "Ozan S. Yigit" cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: undo positioning? In-reply-to: Your message of "Wed, 17 Nov 1993 19:21:21 EST." <9311180021.AA23241@sis.yorku.ca> Date: Wed, 17 Nov 1993 19:47:22 -0500 From: Scott Schwartz Message-Id: <93Nov17.194746est.2516@groucho.cse.psu.edu> | should undo position the current window such that whatever is being undone | is always in view? ie. blind undo considered harmful. Strongly agreed. From sam-fans-owner Thu Nov 18 17:14:56 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <23980>; Thu, 18 Nov 1993 17:10:50 -0500 Received: from penfold.cc.gatech.edu (penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id RAA29587 for ; Thu, 18 Nov 1993 17:10:27 -0500 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id RAA26972 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 18 Nov 1993 17:10:25 -0500 From: Arnold Robbins Message-Id: <199311182210.RAA26972@penfold.cc.gatech.edu> Date: Thu, 18 Nov 1993 17:10:25 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term scrolling Does anyone have some simple advice and/or diffs on how to improve the scrolling speed in 9term? Scrolling is not an issue in sam, when you want to study one page at a time, but 9term is dreadfully slow (and jumpy), particularly in comparison to xterm. Thanks, Arnold From sam-fans-owner Tue Nov 23 14:04:13 1993 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.toronto.edu with SMTP id <23978>; Tue, 23 Nov 1993 14:03:06 -0500 Via: uk.ac.edinburgh.epcfta; Tue, 23 Nov 1993 16:52:14 +0000 From: Andrew Higham Date: Tue, 23 Nov 1993 11:52:09 -0500 Message-Id: <2431.9311231652@epcfta.ed.ac.uk> Subject: patches (FAQ?) To: sam-fans@hawkwind.utcs.toronto.edu Organisation: Edinburgh Portable Compilers Ltd. Phone: +44 31 225 6262 Over the last few weeks various patches for sam have been mentioned. How can I get hold of them? --------------------------------------------------------------------------- Andrew Higham Edinburgh Portable Compilers, 17 Alva St., Edinburgh, EH2 4PH, Scotland, UK andrew@epc.ed.ac.uk phone: +44 31 225 6262 fax: +44 31 225 6644 --------------------------------------------------------------------------- From sam-fans-owner Wed Nov 24 18:25:24 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <23978>; Wed, 24 Nov 1993 18:24:07 -0500 To: sam-fans Subject: Re: patches (FAQ?) In-reply-to: andrew's message of Tue, 23 Nov 1993 11:52:09 -0500. <2431.9311231652@epcfta.ed.ac.uk> Date: Wed, 24 Nov 1993 18:24:03 -0500 From: Chris Siebenmann Message-Id: <93Nov24.182407est.23978@hawkwind.utcs.toronto.edu> All the patches to date have either been posted to the mailing list or had ftp locations mentioned there. The mailing list archives can be ftp'd from ftp.sys.utoronto.ca in /pub/sam, and I can mail them to people who prefer that. - cks From sam-fans-owner Fri Nov 26 15:34:20 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <23980>; Fri, 26 Nov 1993 15:33:16 -0500 To: sam-fans Subject: Wierd problem with sam on an RS/6000 AIX machine Date: Fri, 26 Nov 1993 15:33:13 -0500 From: Chris Siebenmann Message-Id: <93Nov26.153316est.23980@hawkwind.utcs.toronto.edu> I'm trying to get sam up and running on an RS/6000 AIX machine and I'm having a problem with mike@cs.uoregon.edu's scrolling menus version of menuhit.c, namely that they come up as OR'd into the existing text, instead of overlaying them. The standard menuhit.c doesn't have this problem (but of course doesn't scroll). I've tried a few things but rapidly reached my level of X/libXg knowledge. Has anyone seen this before, either on or off AIX machines? Does anyone have Mike's menuhit.c working on an AIX machine? Does anyone have ideas about what to look for? - cks From sam-fans-owner Thu Dec 2 20:02:13 1993 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.toronto.edu with SMTP id <23989>; Thu, 2 Dec 1993 20:00:56 -0500 Received: from localhost (castor@localhost) by drizzle.Stanford.EDU (8.6.4/8.6.4) id RAA02232 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 2 Dec 1993 17:00:43 -0800 From: Castor Fu Message-Id: <199312030100.RAA02232@drizzle.Stanford.EDU> Subject: what patches do you find useful? To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 2 Dec 1993 20:00:42 -0500 X-Mailer: ELM [version 2.4 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 1193 After upgrading to version 4.1 of sam from version3 + Ed Kubaitis' patches, I've been thinking a little about what pieces of each I like the best, or find the most useful. The only change which I've bothered to make to sam version 4.1 is to modify the title for the window to reflect the current file. I find this handy when working with two similar files. The next patch which I will probably carry over is one which moves the keystroke translation table into an X resource. I find it gross to have to recompile libXg and samterm to support additional characters. Finally, a couple of questions about the design of sam. 1. How do you know the location of the start of sam's command input stream? I sometimes get myself confused when pasting together a command, and do a "send" on material which is part of a pending command, with unpredictable results. Do other people ever have this problem? This could be easily fixed with a second cursor, at the sacrifice of some of sam's minimalism. 2. Any particular reasons for not having an "undo" menu item? Maybe I make to many mistakes, but I find the undo sequence awkward if the ~~sam~~ window is not visible. -castor From sam-fans-owner Thu Dec 2 21:34:59 1993 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.toronto.edu with SMTP id <23991>; Thu, 2 Dec 1993 21:34:43 -0500 Received: from localhost (castor@localhost) by drizzle.Stanford.EDU (8.6.4/8.6.4) id SAA03152 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 2 Dec 1993 18:34:36 -0800 From: Castor Fu Message-Id: <199312030234.SAA03152@drizzle.Stanford.EDU> Subject: Bug in samterm -- bad dot visible when dot off screen. To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 2 Dec 1993 21:34:36 -0500 X-Mailer: ELM [version 2.4 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 174 Samterm on my system sometimes shows a vertical bar on a window even when dot is off the screen. Does anyone else have this problem? It's sometimes misleading. -castor From sam-fans-owner Sat Dec 11 00:13:56 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24006>; Sat, 11 Dec 1993 00:12:12 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24743; Sat, 11 Dec 93 00:12:04 -0500 Received: from rexago8.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 001011.24532; Sat, 11 Dec 1993 00:10:11 EST Received: by summitis.com (smail2.5) id AA16113; 10 Dec 93 23:41:03 EST (Fri) Received: from summitis.com by rserv1.YYY; Fri, 10 Dec 1993 23:10 EST Received: by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA32090; Fri, 10 Dec 1993 23:10:11 -0500 From: hc05@summitis.com (Beirne Konarski) Message-Id: <9312110410.AA32090@rexsrvr2.summitis.com> Subject: Why people like sam To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 950 Date: Sat, 11 Dec 1993 00:12:05 -0500 Well, I put out a message a month ago asking why people liked sam, since I couldn't see any benefits to it. No one told me why, but it was recommended that I get some of the extension patches. I installed samx-2, which made the editor usable on a daily basis, and I think I now understand. The key is that sam is designed to be fun for programmers. In this case the fun is having a puzzle to solve every few minutes as you try to figure out how to achieve a modification with regular expressions. This is turning out to be more interesting than a lot of my real work. Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Sat Dec 11 06:34:28 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <24009>; Sat, 11 Dec 1993 06:31:39 -0500 Received: from hillside.co.uk by ben.britain.eu.net via UKIP with SMTP (PP) id ; Sat, 11 Dec 1993 11:31:20 +0000 To: hc05@summitis.com (Beirne Konarski) Subject: Re: Why people like sam Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: Your message of Sat, 11 Dec 1993 00:12:05 -0500 . <9312110410.AA32090@rexsrvr2.summitis.com> From: Peter Collinson Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA Phone: +44 227 761824 Fax: +44 227 762554 Date: Sat, 11 Dec 1993 06:31:17 -0500 Message-Id: <5288.755609477@hillside.co.uk> Sender: pc@hillside.co.uk Editors are a religious topic. Whether you like them or not is probably irrational. From sam-fans-owner Sat Dec 11 15:09:39 1993 Received: from research.att.com ([192.20.225.3]) by hawkwind.utcs.toronto.edu with SMTP id <24011>; Sat, 11 Dec 1993 15:09:03 -0500 From: rob@research.att.com Date: Sat, 11 Dec 1993 14:29:42 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Dec11.150903est.24011@hawkwind.utcs.toronto.edu> Sarcasm aside, which editor one chooses is a matter of taste, not reasoned argument. They all edit text, but they do it in different ways that appeal to different sensibilities. The choice cannot be explained, only understood. -rob From sam-fans-owner Sat Dec 11 19:23:40 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24006>; Sat, 11 Dec 1993 19:23:16 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10946; Sat, 11 Dec 93 19:23:03 -0500 Received: from rexago8.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 192120.24504; Sat, 11 Dec 1993 19:21:20 EST Received: by summitis.com (smail2.5) id AA28355; 11 Dec 93 17:25:27 EST (Sat) Received: from summitis.com by rserv1.YYY; Sat, 11 Dec 1993 17:23 EST Received: by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA29896; Sat, 11 Dec 1993 17:23:01 -0500 From: hc05@summitis.com (Beirne Konarski) Message-Id: <9312112223.AA29896@rexsrvr2.summitis.com> Subject: An explanation of my last message To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1273 Date: Sat, 11 Dec 1993 19:23:04 -0500 Thanks to those of you who replied to my message on why people like sam. My earlier sincere request wondering why people like sam did not generate clear answers, so now that I am using it and am finding things about it that I like I figured I would post my theory. My view that users like solving regular expression puzzles came from personal experience, and was not meant to start a religious war. I save those for Emacs users :-). In any case, once I got samx, which made simple tasks like going up a line easy from the keyboard, I actually grew to like sam, although I could not explain why. The puzzle theory came out of the first concrete fun aspect of sam I discovered. I do like one feature, its distributed nature, enough that I am working on an equivalent of rsh for SNA so that I can use sam over our 9600 baud lines to edit and view files on our remote systems around the country. Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Fri Dec 17 03:59:30 1993 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.toronto.edu with SMTP id <24026>; Fri, 17 Dec 1993 03:53:20 -0500 Via: uk.ac.durham; Fri, 17 Dec 1993 08:52:37 +0000 Received: from dust0.dur.ac.uk by durham.ac.uk; Fri, 17 Dec 93 08:52:34 GMT From: Andy Vick Date: Fri, 17 Dec 1993 03:53:31 -0500 Message-Id: To: sam-fans@hawkwind.utcs.toronto.edu Subject: Building sam Has anyone out there built sam on a DEC Alpha ? Also, does anyone know how hard it would be to get samterm running under MS-Windows using winsock ? Andy Vick. ------------------------------------------------------------------------------- Andy Vick, E-mail: A.J.Vick@durham.ac.uk Department of Physics, University of Durham, Tel: 091-374-2000 (Switchboard) South Road, 091-374-2105 (Direct) DURHAM, DH1 3LE Fax: 091-374-3749 ------------------------------------------------------------------------------- From sam-fans-owner Fri Dec 17 04:12:01 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <24027>; Fri, 17 Dec 1993 04:11:41 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Fri, 17 Dec 1993 09:11:30 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA12246; Fri, 17 Dec 93 09:11:02 GMT Date: Fri, 17 Dec 1993 04:11:02 -0500 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9312170911.AA12246@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Building sam X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 508 > Also, does anyone know how hard it would be to get samterm > running under MS-Windows using winsock ? glurk. you're talking about porting samterm to windows? Aaaahahahahahahaa! now, win32, mebbe. but you've got to port libg first, and you need to be able to do things like allocating and deallocating memory without losing your sanity. out of curiosity, how would you cope with the three-button problems - one of the nice things about sam is the mouse chords patch, which makes it such a pleasure. steve From sam-fans-owner Sat Dec 18 05:24:21 1993 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <24030>; Sat, 18 Dec 1993 05:23:37 -0500 Received: from orthanc.cs.su.OZ.AU by joyce.cs.su.OZ.AU (mail from matty for sam-fans@hawkwind.utcs.toronto.edu) with MHSnet; Sat, 18 Dec 1993 21:23:42 +1100 To: sam-fans@hawkwind.utcs.toronto.edu Message-ID: <19931218212010.27232.frobozz@orthanc.cs.su.OZ.AU> In-Reply-To: From: matty@cs.su.oz.au (James Matthew Farrow) Date: Sat, 18 Dec 1993 06:20:10 -0500 Organisation: Basser Dept of Computer Science, Sydney University, Australia X-Name: James Matthew Farrow X-Face: B>D@!+;vE|ETmR!+pig${%L"["]tFj(v@m_F%@}o2q03)'6{jCds#> #sO^kokjP\LcmO}sB(,^SzSSq@v0x~UXrC \GJ3=i7FUOBLO}]EIuK(K4}LMg,=R7(#B3G&<"r1U~mct?!;M\z:lV Date: Fri, 17 Dec 1993 03:53:31 -0500 Subject: Building sam Has anyone out there built sam on a DEC Alpha ? Andy Vick. I had a go. A problem seems to be that sam & samterm pass around identifiers for things and use the pointer to the object to do so. They pass 4 bytes. This is fine when pointers are 4 bytes but tends to fall apart on the alpha. I concluded this after an afternoon of frustration trying to get 9term/sam compiled in our alpha environment some time ago. I would not bet on being right. Someone please correct me if I'm wrong. Matty. -- James Matthew Farrow | "For in that moment I beheld the ruin matty@cs.su.OZ.AU | of my existence. My world fell dark Basser Department of Computer Science | and my life became a shallow dream. Sydney University - FAX: +61 2 692 3838 | `Odi et amo. Excrucior.'" - Tlindah From sam-fans-owner Sat Dec 18 11:24:33 1993 Received: from research.att.com ([192.20.225.3]) by hawkwind.utcs.toronto.edu with SMTP id <24030>; Sat, 18 Dec 1993 11:24:10 -0500 From: rob@research.att.com Date: Sat, 18 Dec 1993 11:23:02 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <93Dec18.112410est.24030@hawkwind.utcs.toronto.edu> sam's biggest engineering mistake is the passing of pointers across the connection. it worsens the problem by assuming a pointer fits in a 4-byte word. it's easy to fix, though, if you're willing to change the protocol to pass longer values for longs. see the routines in mesg.c on both sides with names like inlong() and so on. you can do this in a way that will remain compatible among all your local machines but you will become incompatible with external machines. i'm pretty sure this is the major problem with the alpha. a variant of the problem occurred on the cray long ago. you also might need to change the structures Block and List or else change the Block management not to use the List routines. -rob From sam-fans-owner Wed Dec 22 14:51:39 1993 Received: from netcomsv.netcom.com ([163.179.1.8]) by hawkwind.utcs.toronto.edu with SMTP id <24034>; Wed, 22 Dec 1993 14:50:33 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id LAA28484; Wed, 22 Dec 1993 11:38:38 -0800 Received: from ghoti.netapp.com by netapp.com (4.1/SMI-4.1) id AA01460; Wed, 22 Dec 93 11:37:51 PST Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA16454; Wed, 22 Dec 93 11:37:41 PST Date: Wed, 22 Dec 1993 14:37:41 -0500 From: byron@ghoti.netapp.com (Byron Rakitzis) Message-Id: <9312221937.AA16454@ghoti.netapp.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam on alpha - OSF/1 I got sam to come up on OSF/1 v1.3 by compiling sam "-taso". This is the "Truncated Address Support Option" which DEC supports in v1.3: they map all addresses in the linked object to a 32 bit address space, so even though a pointer is still 64 bits, you can cast from a pointer to an int and back again and still have it work. From sam-fans-owner Thu Dec 23 11:39:03 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <24035>; Thu, 23 Dec 1993 11:38:29 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19571; Thu, 23 Dec 93 11:38:10 -0500 Received: from rexago8.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 113634.18505; Thu, 23 Dec 1993 11:36:34 EST Received: by summitis.com (smail2.5) id AA09011; 23 Dec 93 11:32:36 EST (Thu) Received: from summitis.com by rserv1.YYY; Thu, 23 Dec 1993 11:27 EST Received: by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA61932; Thu, 23 Dec 1993 11:26:53 -0500 From: hc05@summitis.com (Beirne Konarski) Message-Id: <9312231626.AA61932@rexsrvr2.summitis.com> Subject: rsh replacement To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 897 Date: Thu, 23 Dec 1993 11:38:26 -0500 I am attempting to run sam over SNA rather than TCP/IP. This means that I had to write an rsh equivalent for LU6.2. I have it done as near as I can tell(I can do ed with it), but sam does not work. From looking at the line trace I find that no data is moving between samterm and sam. My question is, what is sam expecting from rsh? Does sam send lines back and forth? Should my rsh replacement read a character at a time from sam? I am trying to send blocks of data rather than individual characters over the line. Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Thu Dec 23 23:38:22 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24035>; Thu, 23 Dec 1993 23:37:43 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09879; Thu, 23 Dec 93 23:38:05 -0500 Received: from rexago8.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 233627.13836; Thu, 23 Dec 1993 23:36:27 EST Received: by summitis.com (smail2.5) id AA12321; 23 Dec 93 23:31:38 EST (Thu) Received: from summitis.com by rserv1.YYY; Thu, 23 Dec 1993 23:26 EST Received: by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA65798; Thu, 23 Dec 1993 23:25:46 -0500 From: hc05@summitis.com (Beirne Konarski) Message-Id: <9312240425.AA65798@rexsrvr2.summitis.com> Subject: More SNA trouble To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Content-Type: binary Content-Length: 1144 Date: Thu, 23 Dec 1993 23:37:42 -0500 I have more detail to followup my earlier question. I fixed up my LU6.2 rsh some so that it is not line-oriented on the way back, but now I get the following error when I run sam: samterm: host mesg: count 63279 1x 47x 247x y|...ignored f9 fc samterm: host mesg: count 63279 1x 47x 247x y|...ignored f9 fc samterm: host mesg: count 63279 1x 47x 247x y|...ignored f9 fc samterm: host mesg: count 63279 1x 47x 247x y|...ignored f9 fc type 1 count 63279 samterm:panic: count>DATASIZE: Error 0 I have looked through the code to try to figure out what is going on, and while I can see how the numbers work, I don't know where the data is coming from. If someone who has been through the code before me has any pointers I would be greatly appreciative. Thanks again, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Sat Dec 25 14:08:01 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <24030>; Sat, 25 Dec 1993 14:06:51 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23239; Sat, 25 Dec 93 14:07:02 -0500 Received: from rexago8.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 140555.16333; Sat, 25 Dec 1993 14:05:55 EST Received: by summitis.com (smail2.5) id AA06997; 25 Dec 93 13:58:17 EST (Sat) Received: from summitis.com by rserv1.YYY; Sat, 25 Dec 1993 13:52 EST Received: by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA46346; Sat, 25 Dec 1993 13:51:53 -0500 From: hc05@summitis.com (Beirne Konarski) Message-Id: <9312251851.AA46346@rexsrvr2.summitis.com> Subject: Ignore my last two messages To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 736 Date: Sat, 25 Dec 1993 14:06:36 -0500 You can ignore my last two messages. I now have sam working over a 19200 baud SNA line. It takes a little bit of getting used to, but so far it is working OK. I have already used it to modify my LU6.2 rsh replacement at the other end and I had no problems. It also works for 9term, but 9term is flaky on the RS/6000, so I don't know how much I will use it. Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Fri Jan 7 02:29:32 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.toronto.edu with SMTP id <24070>; Fri, 7 Jan 1994 02:28:26 -0500 Received: from localhost (castor@localhost) by drizzle.Stanford.EDU (8.6.4/8.6.4) id XAA01305 for sam-fans@hawkwind.utcs.utoronto.ca; Thu, 6 Jan 1994 23:28:17 -0800 From: Castor Fu Message-Id: <199401070728.XAA01305@drizzle.Stanford.EDU> Subject: mysterious behavior with 'r' on a "new" file. To: sam-fans@hawkwind.utcs.utoronto.ca Date: Fri, 7 Jan 1994 02:28:16 -0500 X-Mailer: ELM [version 2.4 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 443 Sam seems to behave oddly when operating on an unnamed file with the 'r' command. I find that the current file name gets set to the name of the file read in. This strikes me as unexpected behavior, because the "r" command normally means 'r'ead the contents of file into '.'. Do other people see this behavior or find it peculiar? Maybe I'm being odd by operating on unnamed files. I'm using a Sony NEWS machine under SVR4. . . -castor From sam-fans-owner Fri Jan 7 11:24:36 1994 Received: from udel.edu ([128.175.1.3]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Fri, 7 Jan 1994 11:24:02 -0500 Received: from sol.cis.udel.edu by louie.udel.edu id aa29232; 7 Jan 94 11:19 EST Received: from louie.udel.edu by sol.cis.udel.edu id aa02867; 7 Jan 94 16:17 GMT Received: from sol.cis.udel.edu by oin.cis.udel.edu id aa09064; 7 Jan 94 16:16 GMT To: sam-fans@hawkwind.utcs.toronto.edu Subject: Newbie Question about Sam, and keyboard operations From: "Mark C. Carroll" Date: Fri, 7 Jan 1994 11:15:59 -0500 Sender: carroll@udel.edu Message-ID: <9401071616.aa09064@oin.cis.udel.edu> Greetings! I've just discovered Sam, and I'm rather intensely impressed by it. It seems to be a really beautiful editor. I've got one question about it, which I can't find an answer to in the manuals. When you're typing text inside of the file window, is there any way to perform any cursor movement without using the mouse? It seems that the only options are to either reposition the cursor using the mouse, or mouse into the command window, and use a positioning command from there to shift. This is very cumbersome for routine editing tasks. From sam-fans-owner Fri Jan 7 17:34:46 1994 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Fri, 7 Jan 1994 17:34:02 -0500 Received: by quux.es.su.oz.au id <336>; Sat, 8 Jan 1994 09:33:45 +1100 From: noel@es.su.oz.au Date: Fri, 7 Jan 1994 17:31:56 -0500 to: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Newbie Question about Sam, and keyboard operations In-Reply-To: <9401071616.aa09064@oin.cis.udel.edu> Message-ID: <199401080931.16004.out.babak@es.su.oz.au> From: "Mark C. Carroll" Subject: Newbie Question about Sam, and keyboard operations When you're typing text inside of the file window, is there any way to perform any cursor movement without using the mouse? It seems that the only options are to either reposition the cursor using the mouse, or mouse into the command window, and use a positioning command from there to shift. This is very cumbersome for routine editing tasks. yes, there is a way to perform cursor movement without using the mouse. use emacs. From sam-fans-owner Fri Jan 7 18:19:16 1994 Received: from netcomsv.netcom.com ([163.179.1.17]) by hawkwind.utcs.toronto.edu with SMTP id <24073>; Fri, 7 Jan 1994 18:18:28 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id PAA11013; Fri, 7 Jan 1994 15:08:07 -0800 Received: from ghoti.netapp.com by netapp.com (4.1/SMI-4.1) id AA00609; Fri, 7 Jan 94 15:03:07 PST Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA24306; Fri, 7 Jan 94 15:02:44 PST Date: Fri, 7 Jan 1994 18:02:44 -0500 From: byron@ghoti.netapp.com (Byron Rakitzis) Message-Id: <9401072302.AA24306@ghoti.netapp.com> To: noel@es.su.oz.au, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Newbie Question about Sam, and keyboard operations >yes, there is a way to perform cursor movement without using the mouse. >use emacs. Ha ha, very funny. It's intolerant sarcasm like this that makes labs religion so much fun, eh? From sam-fans-owner Sat Jan 8 12:58:56 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Sat, 8 Jan 1994 12:55:48 -0500 Received: from localhost (castor@localhost) by drizzle.Stanford.EDU (8.6.4/8.6.4) id JAA07192 for sam-fans@hawkwind.utcs.toronto.edu; Sat, 8 Jan 1994 09:55:38 -0800 From: Castor Fu Message-Id: <199401081755.JAA07192@drizzle.Stanford.EDU> Subject: not a bug in code after all To: sam-fans@hawkwind.utcs.toronto.edu Date: Sat, 8 Jan 1994 12:55:37 -0500 X-Mailer: ELM [version 2.4 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 229 The behavior which I mentioned earlier, where an unnamed buffer takes on the name an 'r' command, is actually mentioned in the tutorial. It's simply not documented in the manual page. So it's a bug in documentation. -castor From sam-fans-owner Sat Jan 8 18:18:04 1994 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu with SMTP id <24073>; Sat, 8 Jan 1994 18:17:36 -0500 Received: by quux.es.su.oz.au id <337>; Sun, 9 Jan 1994 10:17:25 +1100 From: noel@es.su.oz.au Date: Sat, 8 Jan 1994 18:13:24 -0500 to: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Newbie Question about Sam, and keyboard operations In-Reply-To: <9401072302.AA24306@ghoti.netapp.com> Message-ID: <199401091013.16023.out.babab@es.su.oz.au> From: byron@ghoti.netapp.com (Byron Rakitzis) Subject: Re: Newbie Question about Sam, and keyboard operations >yes, there is a way to perform cursor movement without using the mouse. >use emacs. Ha ha, very funny. It's intolerant sarcasm like this that makes labs religion so much fun, eh? i am afraid that the earlier correspondent has failed to see something very basic in the design of sam. if my chiding takes the form of sarcasm, that hardly amounts to intolerance. From sam-fans-owner Tue Jan 11 09:43:33 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Tue, 11 Jan 1994 09:41:33 -0500 Received: from penfold.cc.gatech.edu (penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id JAA28402 for ; Tue, 11 Jan 1994 09:41:07 -0500 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id JAA00369 for sam-fans@hawkwind.utcs.utoronto.ca; Tue, 11 Jan 1994 09:41:04 -0500 Date: Tue, 11 Jan 1994 09:41:04 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199401111441.JAA00369@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.utoronto.ca Subject: arrow keys on sparc type 5 keyboard? Anybody have the appropriate mods to libXg to recognize the ``Industry Standard'' arrow keys on the sun type 5 keyboard? The current arrow keys are in the numeric keypad, which is now much further to the right than on the old keyboard. It's not a big deal, since I may switch back to the old keyboard anyway, but I thought I'd ask. (Now, if only someone would do the plan 9 port to the LX...) Thanks, Arnold From sam-fans-owner Tue Jan 11 12:43:36 1994 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Tue, 11 Jan 1994 12:43:02 -0500 Received: from localhost by groucho.cse.psu.edu with SMTP id <2625>; Tue, 11 Jan 1994 12:42:22 -0500 To: arnold@cc.gatech.edu (Arnold Robbins) cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: arrow keys on sparc type 5 keyboard? In-reply-to: Your message of "Tue, 11 Jan 1994 09:41:04 EST." <199401111441.JAA00369@penfold.cc.gatech.edu> X-Face: /:c""]'pLDG"M1[[aEFnkj?8sKTY0V4gnpT.D;CY]!sUJ*+uJ02!OX?zLxM_cn`#G`H,|2L \?RsN=DhXG9*!ZMr#.S=c>[ Message-Id: <94Jan11.124222est.2625@groucho.cse.psu.edu> | Anybody have the appropriate mods to libXg to recognize the ``Industry | Standard'' arrow keys on the sun type 5 keyboard? You can use xmodmap to bind them to the right keysyms. From sam-fans-owner Mon Jan 17 05:15:10 1994 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Mon, 17 Jan 1994 05:07:30 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAvzfk26339; Mon, 17 Jan 94 05:07:25 -0500 Received: from rexago8.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 004136.13461; Mon, 17 Jan 1994 00:41:36 EST Received: by summitis.com (smail2.5) id AA07089; 17 Jan 94 00:28:10 EST (Mon) Received: from beirnek by rserv1.YYY; Mon, 17 Jan 1994 00:25 EST Received: by beirnek (AIX 3.2/UCB 5.64/4.03) id AA18744; Fri, 14 Jan 1994 08:39:56 -0500 From: hc05%beirnek@uunet.UU.NET (Beirne Konarski) Message-Id: <9401141339.AA18744@beirnek> Subject: How do I reference carriage returns? To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 905 Date: Mon, 17 Jan 1994 05:07:30 -0500 I am getting better at sam now and am using it daily, but I have come up with a simple problem I can't solve. I have a file with CR-NL at the the of each line and I want to remove the carriage returns. I of course know how to do it with a variety of other tools, including vi. I like working on files with sam, though. The problem is that I cannot select the carriage returns. The usual tricks like \r and \015 didn't give them to me. Is there a way to select them? Or am I supposed to pipe the file through tr, like in rc? Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Mon Jan 17 05:37:56 1994 Received: from cortex.physiol.su.oz.au ([129.78.139.131]) by hawkwind.utcs.toronto.edu with SMTP id <24073>; Mon, 17 Jan 1994 05:35:36 -0500 Received: by cortex.physiol.su.oz.au (5.57/Ultrix3.0-C) id AA27218; Mon, 17 Jan 94 21:35:22 +1100 From: John (Farewell Horizontal!) Mackin Date: Mon, 17 Jan 1994 05:26:51 -0500 To: Sam Fans Subject: Re: How do I reference carriage returns? In-Reply-To: <9401141339.AA18744@beirnek> Message-Id: <199401172126.27123.sam.babad@physiol.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ [Just making a guest appearance on the Sam Fans list.] This is a good question. The fact is that sam handles control characters rather well, always excepting null characters, but control-M presents a particular problem because (at least on UNIX under most conditions) you can't _type_ it. If you could type it, you could just deal with it directly -- try this with characters like control-A, control-G, et al. They work great, inserting themselves when typed, and functioning correctly inside commands. (You may have problems _displaying_ these characters, since they come down to the font you are using, presumably under X -- try to use a font which displays control characters somehow.) To return to control-M, though, you can't deal with it since there is no way to type it. This isn't too bad, usually, since in the typical case the file you want to fix up has a control-M as the last character of _every_ line, and so the trivial ,x/.$/d deals with it very effectively. If you aren't convinced that every line ends with control-M, then yes, old faithful tr is the best solution. OK, John. From sam-fans-owner Mon Jan 17 11:54:47 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Mon, 17 Jan 1994 11:54:20 -0500 Received: from localhost (castor@localhost) by drizzle.Stanford.EDU (8.6.4/8.6.4) id IAA29249; Mon, 17 Jan 1994 08:54:09 -0800 From: Castor Fu Message-Id: <199401171654.IAA29249@drizzle.Stanford.EDU> Subject: Re: How do I reference carriage returns? To: john@physiol.su.oz.au (John) Date: Mon, 17 Jan 1994 11:54:08 -0500 Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <199401172126.27123.sam.babad@physiol.su.oz.au> from "John" at Jan 17, 94 05:26:51 am X-Mailer: ELM [version 2.4 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 407 > They work great, inserting themselves when typed, and functioning correctly > inside commands. (You may have problems _displaying_ these characters, > since they come down to the font you are using, presumably under X -- > try to use a font which displays control characters somehow.) > Of course, once you display them, you can cut and paste them pretty easily. This is what I usually do. -castor From sam-fans-owner Mon Jan 17 15:46:43 1994 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Mon, 17 Jan 1994 15:46:00 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAvzha12985; Mon, 17 Jan 94 15:45:06 -0500 Received: from rexago8.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 144202.4497; Mon, 17 Jan 1994 14:42:02 EST Received: by summitis.com (smail2.5) id AA25497; 17 Jan 94 14:40:42 EST (Mon) Received: from beirnek by rserv1.YYY; Mon, 17 Jan 1994 14:38 EST Received: by beirnek (AIX 3.2/UCB 5.64/4.03) id AA19390; Mon, 17 Jan 1994 14:39:03 -0500 From: hc05%beirnek@uunet.UU.NET (Beirne Konarski) Message-Id: <9401171939.AA19390@beirnek> Subject: Removing carriage returns To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 880 Date: Mon, 17 Jan 1994 15:45:45 -0500 Forwarded message: >> They work great, inserting themselves when typed, and functioning correctly >> inside commands. (You may have problems _displaying_ these characters, >> since they come down to the font you are using, presumably under X -- >> try to use a font which displays control characters somehow.) >> > >Of course, once you display them, you can cut and paste them pretty >easily. This is what I usually do. > > -castor Cut-and-paste, what an idea. Why didn't I think of that? Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Mon Jan 17 22:25:51 1994 Received: from netcomsv.netcom.com ([163.179.1.8]) by hawkwind.utcs.toronto.edu with SMTP id <24090>; Mon, 17 Jan 1994 22:25:14 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id TAA18250; Mon, 17 Jan 1994 19:13:13 -0800 Received: by netapp.com (4.1/SMI-4.1) id AA05320; Mon, 17 Jan 94 18:47:20 PST Date: Mon, 17 Jan 1994 21:47:20 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9401180247.AA05320@netapp.com> To: john@physiol.su.oz.au, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: How do I reference carriage returns? If you have the ^M on the screen, you can snarf it with the mouse from the text window, then go to the command window: ,x/ [PASTE] ,x/^M/d and run the command. No reason to guess about where the ^M's might be, you just need to locate one visually. Granted, though, 99% of the time they are on the end of the line. It's just that this is a neat hack for dealing with any character you can see but you don't know how to generate. Byron. From sam-fans-owner Tue Jan 18 09:30:41 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <24091>; Tue, 18 Jan 1994 09:27:45 -0500 Received: from penfold.cc.gatech.edu (penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id JAA29864 for ; Tue, 18 Jan 1994 09:27:28 -0500 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id JAA01077 for sam-fans@hawkwind.utcs.toronto.edu; Tue, 18 Jan 1994 09:27:26 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199401181427.JAA01077@penfold.cc.gatech.edu> Date: Tue, 18 Jan 1994 09:27:26 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: control-m's I have no problem getting at CRs by actually typing control-m instead of the return key on my keyboard. I use the pelm.latin1.9 unicode font, and it shows up as the little CR on a diagonal. MUCH less work than cut-and-paste. This is SunOS 4.1.3, X11R4, not OpenWindows. I'm 99% sure it works under X11R5 as well, but that's on my home system and I'm at work at the moment. Cheers, Arnold From sam-fans-owner Wed Jan 19 04:52:17 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <24094>; Wed, 19 Jan 1994 04:51:10 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Wed, 19 Jan 1994 09:50:25 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA17476; Tue, 18 Jan 1994 12:22:28 +0000 Date: Tue, 18 Jan 1994 07:22:28 -0500 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9401181222.AA17476@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: hiding sam window X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 581 a word of warning for anyone using mark wilkinson's patch to add a "hide" option to menu 3 - don't hide the sam window! having done this once deliberately while editing lots of files, sam crashed *very* soon afterwards, but that could have been just my bad luck. however, if you hide the sam window, then reopen it, the menu2 is the same as for normal text files, and sam isn't entirely clear about the output point. the correct fix, of course, is to extend mark's patch to ignore closes on the sam window, but right now i don't have the time to think about this. cheers, steve From sam-fans-owner Wed Jan 19 10:19:11 1994 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <24096>; Wed, 19 Jan 1994 10:15:51 -0500 Date: Wed, 19 Jan 1994 10:01:42 -0500 Message-ID: From: "Mark H. Wilkinson" Subject: Re: hiding sam window To: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: Steve_Kilbane's message of Tue, 18 Jan 1994 07:22:28 -0500 Sender: "Mark H. Wilkinson" X-Mailer: Sendmail/ream v4.12bv > a word of warning for anyone using mark wilkinson's patch to add a "hide" > option to menu 3 - don't hide the sam window! Just to clarify, Steve's talking about a patch which never actually got posted to this list. The hide option removed a window without removing a file from sam's internal list; unfortunately sam and samterm disagree about whether this is a good thing and a core dump can result. If anyone else has a copy of the patch I'd recommend removing it for the time being. -Mark. From sam-fans-owner Mon Jan 24 09:39:03 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <24092>; Mon, 24 Jan 1994 09:37:33 -0500 Received: from penfold.cc.gatech.edu (penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id JAA07767 for ; Mon, 24 Jan 1994 09:37:27 -0500 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id JAA03568 for sam-fans@hawkwind.utcs.toronto.edu; Mon, 24 Jan 1994 09:37:25 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199401241437.JAA03568@penfold.cc.gatech.edu> Date: Mon, 24 Jan 1994 09:37:25 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam + ptys, anyone? I hope this idea doesn't strike anyone as too bizarre. I've been using sam and 9term almost exclusively for about a year now. In 9term, I often find myself wanting to highlight some text, make a global substitution on it, or otherwise munge it like I might from the sam command window, and then paste it back into the intput. Has anyone looked at what it might take to turn a sam window into one that can drive a pty? Sort of a merger of sam & 9term. This is undoubtedly like emacs with its shell windows (although I've never used emacs, just read a bit about it), and thus it smacks of creeping featurism, non-minimalism etc. On the other hand, it is also a logical extension of the current ability to manually edit text in a "shell window" and then resubmit it. Anyway, this is just sort of strawman to stimulate discussion. I'm willing to be convinced it's a bad idea; I'm also willing to be called "brilliant", "visionary", etc. (:-) Thanks, Arnold From sam-fans-owner Mon Jan 24 11:44:17 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <24092>; Mon, 24 Jan 1994 11:43:44 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Mon, 24 Jan 1994 16:43:03 +0000 Received: by cuthbert.sdd (4.1/SMI-4.1) id AA13692; Mon, 24 Jan 94 16:41:24 GMT Date: Mon, 24 Jan 1994 11:41:24 -0500 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9401241641.AA13692@cuthbert.sdd> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam + ptys, anyone? i've often wondered about this, but the 'emacs-ism' of it all has put me off. plus, of course, it would complicate sam no end, i suspect. i think a better way to do it would be to just get Help (or whatever rob's latest GUI was). Kind of layer shell, terminal driver, editor, window system and sam system, so that it takes the capability into account, rather than it being kludged in. Of course, if you can do it in a 10-line patch, i'll use it. :-) steve From sam-fans-owner Mon Jan 24 11:52:15 1994 Received: from plan9.att.com ([192.20.225.252]) by hawkwind.utcs.toronto.edu with SMTP id <24108>; Mon, 24 Jan 1994 11:51:44 -0500 From: rob@plan9.att.com To: Date: Mon, 24 Jan 1994 11:50:59 -0500 Message-Id: <94Jan24.115144est.24108@hawkwind.utcs.toronto.edu> see my paper on acme in the latest usenix proceedings. not available electronically yet. -rob From sam-fans-owner Mon Jan 24 13:01:42 1994 Received: from hp.com ([15.255.152.4]) by hawkwind.utcs.toronto.edu with SMTP id <24092>; Mon, 24 Jan 1994 13:00:08 -0500 Received: from hpwcsvp.mayfield.hp.com by hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA15146; Mon, 24 Jan 1994 09:59:52 -0800 Received: from localhost by hpwcsvp.mayfield.hp.com with SMTP (1.36.108.7/15.5+ECS 3.3) id AA03918; Mon, 24 Jan 1994 09:14:31 -0800 Message-Id: <9401241714.AA03918@hpwcsvp.mayfield.hp.com> To: steve@gec-epl.co.uk (Steve_Kilbane) Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam + ptys, anyone? X-Mailer: Xmh+mh6.7 In-Reply-To: Your message of Mon, 24 Jan 94 11:41:24 -0500. <9401241641.AA13692@cuthbert.sdd> Date: Mon, 24 Jan 1994 12:14:30 -0500 From: Peter Huang > i've often wondered about this, but the 'emacs-ism' of it all has put me > off. plus, of course, it would complicate sam no end, i suspect. i think > Did you look at samkey patch? I agree it is very hard to break out of 'emacs-ism'. I'm using sam to write this mail, however, I patched with samkey so I can bind ctrl-a to dotbol (for the simple reason that I don't want to lift my hand off keyboard to use the mouse to correct a mistake.) I also have a emacs(lucid) running to do source code viewing. I like sam a lot and use it everyday, however, it is not a one for all editor. ============================================================ Peter Huang HP Response Center Lab Phone: (415)691-3417 Email: huangp@mayfield.HP.COM 100 Mayfield Avenue, MS 37MA, Mountain View, CA 94043 ============================================================ From sam-fans-owner Mon Jan 24 16:23:39 1994 Received: from Legato.COM ([137.39.92.2]) by hawkwind.utcs.toronto.edu with SMTP id <24092>; Mon, 24 Jan 1994 16:13:19 -0500 Received: from quattro.Legato.COM by Legato.COM (4.1/SMI-4.0) id AA03609 for rob@plan9.att.com; Mon, 24 Jan 94 13:05:13 PST Received: by quattro.Legato.COM (4.1/SMI-4.1) id AA21952; Mon, 24 Jan 94 13:05:12 PST From: dbecker@Legato.COM (Doug Becker) Message-Id: <9401242105.AA21952@quattro.Legato.COM> Subject: Re: acme To: rob@plan9.att.com (Rob Pike) Date: Mon, 24 Jan 1994 16:05:12 -0500 Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <94Jan24.115144est.24108@hawkwind.utcs.toronto.edu> from "rob@plan9.att.com" at Jan 24, 94 11:50:59 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 249 see my paper on acme in the latest usenix proceedings. not available electronically yet. When it *is* available electronically, could you post a message to sam-fans? (And when will the source be available for us still stuck with UNIX? :-) From sam-fans-owner Tue Jan 25 06:56:36 1994 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <24092>; Tue, 25 Jan 1994 06:55:55 -0500 From: pete@minster.york.ac.uk Date: Tue, 25 Jan 1994 06:39:49 -0500 Message-ID: To: sam-fans@hawkwind.utcs.toronto.edu Subject: Important Features and Alternative Samterms This is to some extent prompted by the "creeping featurism" debate, and is as much an attempt to straighten out in my own mind what _is_ Sam-like and what isn't... I would say the _key_ features of Sam are (in roughly the order I exploit them): * its regular expression handling * the distributed editing paradigm it implements * easy multi-file operation Most of the discussions on this list, though, are about particular user-interface features of samterm, when, theoretically, anything which can talk to a Sam running on a remote host could be a samterm -- it just so happens that at present the only samterms in existence are near-clones of the original... Now enter the realms of heresy: It seems to me that it should be possible for, say, someone using a Mac or a PC with appropriate networking software to build a front-end to Sam which conforms to all the usual user-interface conventions on their particular machine (the full horrors of pull-down menus, appalling widgetry and even, God forbid, dialogue boxes) yet still speaks the same protocol as samterm. Not that I'd want to use them! Since the most common complaint on this list seems to be that newcomers "love the regular expressions but hate the user interface" or similar, perhaps samterms with more familiar interfaces might be the way to tempt newcomers into the Sam world; perhaps after using such "presentational suger" for a while they might realise that Rob's original is quite a lot more elegant than the baroque junk that Windows/Mac/Motif etc. place in the way of the user... pete -- Peter Fenelon - Research Associate - High Integrity Systems Engineering Group, Dept. of Computer Science, University of York, York, Y01 5DD +44 (0)904 433388 EMAIL: pete@minster.york.ac.uk ``Art is a science with more than 7 variables'' From sam-fans-owner Tue Jan 25 10:29:50 1994 Received: from ursa.sis.yorku.ca ([130.63.74.12]) by hawkwind.utcs.toronto.edu with SMTP id <24092>; Tue, 25 Jan 1994 10:29:27 -0500 Received: from localhost.yorku.ca by sis.yorku.ca (4.1/SMI-4.1) id AA27137; Tue, 25 Jan 94 10:23:10 EST Message-Id: <9401251523.AA27137@sis.yorku.ca> To: pete@minster.york.ac.uk Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Important Features and Alternative Samterms Date: Tue, 25 Jan 1994 10:23:09 -0500 From: "Ozan S. Yigit" > Since the most common complaint on this list seems to be that newcomers > "love the regular expressions but hate the user interface" or similar, > perhaps samterms with more familiar interfaces might be the way to > tempt newcomers into the Sam world; perhaps after using such > "presentational suger" for a while they might realise that Rob's > original is quite a lot more elegant than the baroque junk that > Windows/Mac/Motif etc. place in the way of the user... i do not think "presentational sugar just for a while" strategies ever work the way we expect them to. people do not get that sudden "realization" one would expect, but rather, they stick to the sugar [no pun intended]. what was meant to be temporary becomes permanent. i happen to think it is a good idea to build other sams and samterms, so that we can explore other ideas in editing environments. sugar coating the existing one to make it easier to swallow is a waste of time. oz --- In der Kunst ist es schwer etwas zu sagen, | electric: oz@sis.yorku.ca was so gut ist wie: nichts zu sagen. - LW | ph: [416] 736 2100 x33976 From sam-fans-owner Wed Jan 26 10:35:37 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <24092>; Wed, 26 Jan 1994 10:33:16 -0500 Received: from penfold.cc.gatech.edu (penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id KAA11091 for ; Wed, 26 Jan 1994 10:33:05 -0500 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id KAA05176 for sam-fans@hawkwind.utcs.toronto.edu; Wed, 26 Jan 1994 10:33:03 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199401261533.KAA05176@penfold.cc.gatech.edu> Date: Wed, 26 Jan 1994 10:33:03 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: yet another creeping feature suggestion The discussion about sam features and alternate samterms brings to mind the "feature" I'd really like to see in samterm, which is some way to add things to the button 3 menu. In particular, I'd like to be able to add some way to send my own strings at the sam command window. This comes up most often when I'm hacking text, and I'd love to be able to use a menu item to send ``|fmt'' at the command window. As an aside, what I like about sam is the *combination* of the point and click to type model with the powerful command language of ed. The two together are (as in so many things from the btl research group) a whole that is greater than the sum of the parts. Arnold P.S. And no, it should not be done as X resources! Gack. A .samtermrc suits me fine. From sam-fans-owner Wed Jan 26 11:06:20 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.toronto.edu with SMTP id <24108>; Wed, 26 Jan 1994 11:05:56 -0500 Received: from localhost (castor@localhost) by drizzle.Stanford.EDU (8.6.4/8.6.4) id IAA20920; Wed, 26 Jan 1994 08:05:43 -0800 From: Castor Fu Message-Id: <199401261605.IAA20920@drizzle.Stanford.EDU> Subject: Re: yet another creeping feature suggestion To: arnold@cc.gatech.edu (Arnold Robbins) Date: Wed, 26 Jan 1994 11:05:42 -0500 Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <199401261533.KAA05176@penfold.cc.gatech.edu> from "Arnold Robbins" at Jan 26, 94 10:33:03 am X-Mailer: ELM [version 2.4 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 929 Arnold Robbins (sp?) says > > The discussion about sam features and alternate samterms brings to mind > the "feature" I'd really like to see in samterm, which is some way to > add things to the button 3 menu. In particular, I'd like to be able to > add some way to send my own strings at the sam command window. This comes > up most often when I'm hacking text, and I'd love to be able to use a > menu item to send ``|fmt'' at the command window. > > P.S. And no, it should not be done as X resources! Gack. A .samtermrc > suits me fine. > Great. . . Seriously, while X-windows resource formats can be ugly, I am not convinced that they have to be worse than learning yet another startup file format. Perhaps the correct solution for those wanting more "customization" would be to build a samterm interface to tcl/Tk. Then the interface code would be in a format that at least some people could easily modify. -castor From sam-fans-owner Wed Jan 26 11:29:52 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <24109>; Wed, 26 Jan 1994 11:29:33 -0500 Received: from penfold.cc.gatech.edu (penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id LAA13365; Wed, 26 Jan 1994 11:29:15 -0500 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id LAA05255; Wed, 26 Jan 1994 11:29:12 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199401261629.LAA05255@penfold.cc.gatech.edu> Date: Wed, 26 Jan 1994 11:29:11 -0500 In-Reply-To: Pete Fenelon's 34-line message on Jan 26, 4:05pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: pete@minster.york.ac.uk (Pete Fenelon), arnold@cc.gatech.edu (Arnold Robbins) Subject: Re: yet another creeping feature suggestion Cc: sam-fans@hawkwind.utcs.toronto.edu > What's wrong with opening up a separate window with your favourite Sam commands > in and using snarf/paste to execute them in the command window? Absolutely nothing. I didn't think of it. Of course, I didn't put a whole lot of effort into it either. :-) > Some of the samkeys patches also take care of parts of what you're after (at > least sending things to the command window). I'll take a harder look at samkeys. It seemed a little to bell&whistle for me (personal opinion, no criticsms implied). About all it has that I sort of miss is auto-indent, and I find myself not missing it as much as I do in vi. Thanks all. From sam-fans-owner Wed Jan 26 11:30:19 1994 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <24110>; Wed, 26 Jan 1994 11:30:00 -0500 Message-ID: X-Sender: pete@minster.york.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Jan 1994 11:05:22 -0500 To: arnold@cc.gatech.edu (Arnold Robbins) From: pete@minster.york.ac.uk (Pete Fenelon) Subject: Re: yet another creeping feature suggestion Cc: sam-fans@hawkwind.utcs.toronto.edu X-Mailer: >The discussion about sam features and alternate samterms brings to mind >the "feature" I'd really like to see in samterm, which is some way to >add things to the button 3 menu. In particular, I'd like to be able to >add some way to send my own strings at the sam command window. This comes >up most often when I'm hacking text, and I'd love to be able to use a >menu item to send ``|fmt'' at the command window. What's wrong with opening up a separate window with your favourite Sam commands in and using snarf/paste to execute them in the command window? Some of the samkeys patches also take care of parts of what you're after (at least sending things to the command window). pete -- Peter Fenelon: Research Associate: High Integrity Systems Engineering Group, Dept of Computer Science, University of York, York, Y01 5DD +44/0 904 433388 Email:pete@minster.york.ac.uk *There's no room for enigmas in built up areas From sam-fans-owner Thu Jan 27 13:55:35 1994 Received: from plan9.att.com ([192.20.225.252]) by hawkwind.utcs.toronto.edu with SMTP id <24092>; Thu, 27 Jan 1994 13:52:37 -0500 From: rob@plan9.att.com To: Date: Thu, 27 Jan 1994 13:46:50 -0500 Message-Id: <94Jan27.135237est.24092@hawkwind.utcs.toronto.edu> postscript versions of the two papers we presented at the USENIX conference last week are now available by anonymous FTP from research.att.com, directory dist/plan9man. an old version of acid is part of the plan 9 distribution. acme is unobtainable at the moment. -rob From sam-fans-owner Tue Feb 1 12:14:05 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <24117>; Tue, 1 Feb 1994 12:11:00 -0500 Received: from penfold.cc.gatech.edu (penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id MAA14355 for ; Tue, 1 Feb 1994 12:10:51 -0500 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id MAA07865 for sam-fans@hawkwind.utcs.toronto.edu; Tue, 1 Feb 1994 12:10:49 -0500 Date: Tue, 1 Feb 1994 12:10:49 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199402011710.MAA07865@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: any gotchas for sam / 9term on solaris 2.3 Greetings. Before I go breaking my head, are there any gotchas to watch out for when compiling sam and 9term on solaris 2.3? My sunos 4.1.3 9term binary runs, but echo is turned off and stays off. Also, should I use gcc or the sun cc? Email responses are fine & I'll summarize to the list. Thanks, Arnold P.S. I'm principally interested in 9term (and es too, actually); most of my editing w/sam is still on sunos. From sam-fans-owner Tue Feb 1 12:47:42 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <24119>; Tue, 1 Feb 1994 12:47:25 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 1 Feb 1994 17:24:32 +0000 Received: from zombie.gec-epl.co.uk by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA01467; Tue, 1 Feb 1994 17:26:23 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA00572; Tue, 1 Feb 1994 17:23:44 +0000 Date: Tue, 1 Feb 1994 12:23:44 -0500 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9402011723.AA00572@zombie.gec-epl.co.uk> To: arnold Subject: Re: any gotchas for sam / 9term on solaris 2.3 Cc: sam-fans@hawkwind.utcs.toronto.edu X-Sun-Charset: US-ASCII Content-Length: 290 well, i spent quite a reasonable amount of time getting 9term up and running on Solaris 2.x. The main problem was the pty code (which is completely different from SunOS 4.1.x). Sam was no trouble at all (as far as I can recall). Has anyone else been running 9term on Solaris 2.x? steve From sam-fans-owner Tue Feb 1 18:59:06 1994 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu with SMTP id <24116>; Tue, 1 Feb 1994 18:58:08 -0500 Received: by quux.es.su.oz.au id <340>; Wed, 2 Feb 1994 10:57:22 +1100 From: noel@es.su.oz.au Date: Tue, 1 Feb 1994 18:55:43 -0500 to: steve@gec-epl.co.uk (Steve_Kilbane), arnold cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: any gotchas for sam / 9term on solaris 2.3 In-Reply-To: <9402011723.AA00572@zombie.gec-epl.co.uk> Message-ID: <199402021055.12441.out.babas@es.su.oz.au> > Has anyone else been running 9term on Solaris 2.x? yes, i have built 9term on Solaris 2.3. i'm not convinced yet it is stable. From sam-fans-owner Thu Feb 3 12:54:22 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto.edu with SMTP id <24122>; Thu, 3 Feb 1994 12:52:36 -0500 Received: from penfold.cc.gatech.edu (penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id MAA17251 for ; Thu, 3 Feb 1994 12:52:15 -0500 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id MAA09213 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 3 Feb 1994 12:52:14 -0500 Date: Thu, 3 Feb 1994 12:52:14 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199402031752.MAA09213@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: smileys Unicode has two smileys and a saddy, but they're up at some absolutely awful hex addresses I can never remeber. So I broke down and added alt codes to libXg to handle them. ☺ Apply this diff to latin1.c in libXg and recompile 9term. I haven't tested samterm yet but it oughta work. Bobf, can we get these into "the next release" whenever that will be? Enjoy, (☻) Arnold ---------------- *** latin1.c.orig Tue Sep 28 11:31:50 1993 --- latin1.c Thu Feb 3 12:45:03 1994 *************** *** 208,213 **** --- 208,216 ---- 0x22a8, 'T','u', /* valid */ 0x22c4, 'l','z', /* lozenge */ 0x22ef, 'e','l', /* ellipses */ + 0x2639, ':','(', /* saddy */ + 0x263a, ':',')', /* white-face smiley */ + 0x263b, ';',')', /* dark-face smiley */ 0, 0, }; From sam-fans-owner Tue Feb 8 10:03:22 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24133>; Tue, 8 Feb 1994 09:59:59 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwcjj16760; Tue, 8 Feb 94 09:59:34 -0500 Received: from rexago8.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 094043.17694; Tue, 8 Feb 1994 09:40:43 EST Received: by summitis.com (smail2.5) id AA18297; 8 Feb 94 09:27:42 EST (Tue) Received: from summitis.com by rserv1.YYY; Tue, 8 Feb 1994 09:25 EST Received: from beirnek by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA43599; Tue, 8 Feb 1994 09:25:52 -0500 Received: by beirnek (AIX 3.2/UCB 5.64/4.03) id AA17435; Tue, 8 Feb 1994 09:25:51 -0500 From: hc05@summitis.com Message-Id: <9402081425.AA17435@beirnek> Subject: How does exch work? To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 720 Date: Tue, 8 Feb 1994 09:59:49 -0500 >From time to time it looks like exch would be useful, but I cannot get it to work. My understanding is that I snarf some text in one window, move to another window with a selected section, hit the exch entry in menu #2, and the snarf text will replace the highlighted text in the new window. Is this correct? If not, what does it do? Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Tue Feb 8 10:40:06 1994 Received: from daedalus.dcrt.nih.gov ([128.231.129.209]) by hawkwind.utcs.toronto.edu with SMTP id <24134>; Tue, 8 Feb 1994 10:39:44 -0500 Received: from localhost (weisen@localhost) by daedalus.dcrt.nih.gov (8.6.4/8.6.4(neil-1.0)) with SMTP id KAA10502; Tue, 8 Feb 1994 10:38:46 -0500 Message-Id: <199402081538.KAA10502@daedalus.dcrt.nih.gov> To: hc05@summitis.com cc: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) Subject: Re: How does exch work? In-reply-to: Your message of "Tue, 08 Feb 1994 09:59:49 EST." <9402081425.AA17435@beirnek> X-Mailer: MH [6.8+MIME] Date: Tue, 8 Feb 1994 10:38:42 -0500 From: Neil Weisenfeld In message <9402081425.AA17435@beirnek>, hc05@summitis.com writes: > new window. Is this correct? If not, what does it do? > "Exch" exchanges Sam's snarf buffer with that of the window system. If you have something snarfed in Sam and then highlight something in an Xterm (obviously, I'm talking about Sam under X11), then using paste in Sam will replace dot with what was selected under the Xterm and clicking to paste in the Xterm will insert what was in Sam's snarf buffer. Using "Paste" will replace dot with the contents of the snarf buffer. --Neil From sam-fans-owner Tue Feb 8 10:47:57 1994 Received: from daedalus.dcrt.nih.gov ([128.231.129.209]) by hawkwind.utcs.toronto.edu with SMTP id <24135>; Tue, 8 Feb 1994 10:47:42 -0500 Received: from localhost (weisen@localhost) by daedalus.dcrt.nih.gov (8.6.4/8.6.4(neil-1.0)) with SMTP id KAA10609; Tue, 8 Feb 1994 10:47:00 -0500 Message-Id: <199402081547.KAA10609@daedalus.dcrt.nih.gov> To: hc05@summitis.com cc: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) Subject: Re: How does exch work? In-reply-to: Your message of "Tue, 08 Feb 1994 10:38:42 EST." <199402081538.KAA10502@daedalus.dcrt.nih.gov> X-Mailer: MH [6.8+MIME] Date: Tue, 8 Feb 1994 10:46:57 -0500 From: Neil Weisenfeld Don't you wish that you could recall e-mail? Sorry about the need for a clarification. --Neil In message <199402081538.KAA10502@daedalus.dcrt.nih.gov>, Neil Weisenfeld write s: > > "Exch" exchanges Sam's snarf buffer with that of the window system. If > you have something snarfed in Sam and then highlight something in an > Xterm (obviously, I'm talking about Sam under X11), then using paste in > Sam will replace dot with what was selected under the Xterm and ^^ after using exch > clicking to paste in the Xterm will insert what was in Sam's snarf ^^ (before the exch) > buffer. > > Using "Paste" will replace dot with the contents of the snarf buffer. > > > --Neil From sam-fans-owner Thu Feb 10 05:26:00 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <24139>; Thu, 10 Feb 1994 05:16:33 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Thu, 10 Feb 1994 10:15:57 +0000 Received: from zombie.gec-epl.co.uk by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA03385; Thu, 10 Feb 1994 10:18:20 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA03848; Thu, 10 Feb 1994 10:13:57 +0000 Date: Thu, 10 Feb 1994 05:13:57 -0500 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9402101013.AA03848@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: setting x resources X-Sun-Charset: US-ASCII Content-Length: 397 this is a X question really, but sam's the application it applies most to. running sam on solaris 2.3, whenever i run sam locally, the window's size is defined by /usr/openwin/lib/app-defaults/Sam. fine. when i set DISPLAY and run it remotely, it ignores such settings, and comes up full-size. is there any way to persuade an X application to use the defaults from the X server's machine? steve From sam-fans-owner Thu Feb 10 12:45:52 1994 Received: from hp.com ([15.255.152.4]) by hawkwind.utcs.toronto.edu with SMTP id <24140>; Thu, 10 Feb 1994 12:42:29 -0500 Received: from hpwcsvp.mayfield.hp.com by hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA10734; Thu, 10 Feb 1994 09:42:10 -0800 Received: from localhost by hpwcsvp.mayfield.hp.com with SMTP (1.36.108.7/15.5+ECS 3.3) id AA10759; Thu, 10 Feb 1994 09:38:02 -0800 Message-Id: <9402101738.AA10759@hpwcsvp.mayfield.hp.com> To: steve@gec-epl.co.uk (Steve_Kilbane) Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: setting x resources X-Mailer: Xmh+mh6.7 In-Reply-To: Your message of Thu, 10 Feb 94 05:13:57 -0500. <9402101013.AA03848@zombie.gec-epl.co.uk> Date: Thu, 10 Feb 1994 12:38:01 -0500 From: Peter Huang > this is a X question really, but sam's the application it applies most to. > > running sam on solaris 2.3, whenever i run sam locally, the window's size > is defined by /usr/openwin/lib/app-defaults/Sam. fine. when i set DISPLAY > and run it remotely, it ignores such settings, and comes up full-size. > is there any way to persuade an X application to use the defaults from the > X server's machine? > The app-defaults stuff is used per client basis, i.e. when you start a client, it will look at app-defaults for resource hints. To have uniform client resource whereever you log on, you need to load those resource hints into Xserver, this can be done by using 'xrdb -merge Sam'. look at xrdb man page for details. ============================================================ Peter Huang HP Response Center Lab Phone: (415)691-3417 Email: huangp@mayfield.HP.COM 100 Mayfield Avenue, MS 37MA, Moutain View, CA 94043 ============================================================ DISCLAIMER: this message is the my personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard. From sam-fans-owner Fri Feb 11 10:04:08 1994 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.toronto.edu with SMTP id <24143>; Fri, 11 Feb 1994 10:01:22 -0500 From: mhw@minster.york.ac.uk Date: Fri, 11 Feb 1994 09:58:32 -0500 Message-ID: >From: Mark H. Wilkinson Subject: samterm's bitmap depths. To: sam-fans@hawkwind.utcs.toronto.edu Sender: "Mark H. Wilkinson" X-Mailer: Sendmail/ream v4.12bv i've recently moved from a mono machine to a colour machine. having built sam on this new machine i find that when i get a few windows open within sam the machine starts to swap and generally get sluggish. what i think is happening is that samterm is allocating all its bitmaps to be 8 bits deep (even though they're all monochrome) and it's clogging up the server. i think 9term uses 1 bit deep bitmaps no matter what display it runs on. i've played around setting X resources, but to no effect (other than BadMatch errors). anyone else experienced this and found a work around or patch? or do colour suns just go slow? -Mark. From sam-fans-owner Fri Mar 11 21:02:38 1994 Received: from news.std.com ([192.74.137.2]) by hawkwind.utcs.toronto.edu with SMTP id <24167>; Fri, 11 Mar 1994 21:00:03 -0500 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA17404; Fri, 11 Mar 1994 20:59:59 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA16942; Fri, 11 Mar 1994 20:59:58 -0500 From: jrs@world.std.com (Rick Sladkey) To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam.el: please don't laugh Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 2195 Message-Id: <941311.205736.jrs@world.std.com> Date: Fri, 11 Mar 1994 20:57:37 -0500 Last summer I read the Plan 9 manuals out of curiosity. I read about Sam and was a little interested since `ed' was the editor of choice when I started using Unix and Sam reminded me of `ed'. During December, I got the idea to rewrite Sam from scratch to see what it was really like. Just from reading the manual page. So I cobbled together an emulation of Sam in Emacs Lisp over one weekend. I was right about the similarity of Sam to `ed' and I sort of liked it. Many of the details of interaction were probably wrong but it was a fun way to kill a few weekends. Shortly thereafter, I discovered by coincidence that Sam was free. So I got the real thing and tried it out. I spent a couple of days making the emulation better and fixing undocumented behaviors. Then I got bored with the project and haven't worked on it since. I realize that the type of person who would like Sam would in general hate Emacs so maybe the exercise was pointless. Please do not feel compelled to remark that it was worse than pointless. Anyway, I myself use Emacs, `vi', and `ed' interchangably but haven't really managed to become comfortable with Sam for day-to-day use yet. Most of the things Sam would be good for I use throw-away `sed' or `awk' programs. So the incentive is not quite powerful enough yet to convert me. Anyway, this message is just to announce that it is available if anyone could find a use for it. I could see it being useful for Sam types when logged in from a character-based terminal, on systems where Sam isn't available or doesn't run, or someone who likes the idea of Sam in principal but needs to work with Emacs for other reasons. For example, you can just `sam' a buffer, make some quick changes and get on with it. If you are good with Sam you will already know in what situations in which using the Sam language would be the language of choice. If there is enough demand, I can mail it to the list (it's about 40k). Then you all can have a good laugh ridiculing it, me, and Emacs. I don't subscribe to this list so if you want to me to send the code to you, to see any comments, or for me to send you a reply, be sure to cc any messages to me. Thanks, Rick From sam-fans-owner Sat Mar 12 15:52:20 1994 Received: from news.std.com ([192.74.137.2]) by hawkwind.utcs.toronto.edu with SMTP id <24167>; Sat, 12 Mar 1994 15:51:20 -0500 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA28733; Sat, 12 Mar 1994 15:51:09 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA23236; Sat, 12 Mar 1994 15:42:24 -0500 From: jrs@world.std.com (Rick Sladkey) To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam.el: please don't laugh In-Reply-To: jrs@world.std.com's message of Fri, 11 Mar 1994 20:57:37 EST References: <941311.205736.jrs@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 37424 Message-Id: <941312.155129.jrs@world.std.com> Date: Sat, 12 Mar 1994 15:51:29 -0500 OK, I have received quite a few requests and so I am sending my sam.el the sam-fans mailing list. I would be happy to try to answer any questions anyone may have. Snicker away, Rick ----- ;;; sam.el -- emulate the sam text editor -*- Emacs-Lisp -*- ;;; Copyright (C) 1993 Rick Sladkey ;; This file is not part of Emacs but is distributed under ;; the same conditions as Emacs. ;; Emacs is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; Emacs is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; LCD Archive Entry: ;; sam|Rick Sladkey|jrs@world.std.com| ;; Emulate the sam text editor Using Emacs| ;; 11-Dec-1993|0.5|~/modes/sam.el.Z| (defconst sam-version "sam v0.5 - 93-12-11") ;; Problems or Omissions: ;; can insert-buffer-substring be useful? ;; command grouping ;; missing simultaneous undo in multiple buffers ;; current directory for shell commands ;; buffer commands should use buffer-file-name ;; no support for a named pipe for commands ;; none of the special mouse features are implemented ;; multiple windows into a file don't really have separate dots ;; gracefully handle more syntax errs (e.g. "s") ;; gracefully handle empty or missing editing buffer ;; syntax errors cause unclearable in progress commands ;;; Variables and keymaps. (defvar sam-command-mode-map nil "Keymap used in sam command mode.") (if sam-command-mode-map () (setq sam-command-mode-map (make-sparse-keymap)) (define-key sam-command-mode-map "\r" 'sam-eval-last-command)) (defvar sam-command-assoc '(;; Text commands ("a" . sam-append) ("c" . sam-change) ("i" . sam-insert) ("d" . sam-delete) ("s" . sam-substitute) ("m" . sam-move) ("t" . sam-copy) ;; Display commands ("p" . sam-print) ("=" . sam-value) ;; File commands ("b" . sam-switch-buffer) ("B" . sam-visit-files) ("n" . sam-buffer-menu) ("D" . sam-kill-buffers) ;; I/O commands ("e" . sam-edit) ("r" . sam-read) ("w" . sam-write) ("f" . sam-file) ("<" . sam-pipe-in) (">" . sam-pipe-out) ("|" . sam-pipe-thru) ("!" . sam-shell) ("cd" . sam-cd) ;; Loops and conditionals ("x" . sam-for-each) ("y" . sam-except-each) ("X" . sam-for-each-buffer) ("Y" . sam-except-each-buffer) ("g" . sam-when) ("v" . sam-unless) ;; Misc commands ("k" . sam-set-reference) ("q" . sam-quit) ("u" . sam-undo) ("{" . sam-compound) ("" . sam-default)) "Association list used to look up sam commands.") (defvar sam-operator-assoc '(("+" . sam-plus) ("-" . sam-minus) ("," . sam-comma) (";" . sam-semi)) "Association list used to look up sam address operators.") (defvar sam-precedence-assoc '((sam-plus . 2) (sam-minus . 2) (sam-comma . 1) (sam-semi . 1)) "Association list used to look up the precedence of sam address operators.") (defvar sam-command-buffer nil "The name of the buffer used to issue sam commands.") (defvar sam-edit-buffer nil "The name of the buffer currently being edited by sam.") (defvar sam-last-command nil "Last command issued from the sam command window.") (defvar sam-last-regexp nil "Last sam regexp, used when a regexp is empty.") (defvar sam-last-shell-command nil "Last sam shell command, used when a command is empty.") (defvar sam-reference nil "The address mark for each sam editing buffer.") (make-variable-buffer-local 'sam-reference) (defvar sam-please-go-away nil "Non-nil means sam is not wanted anymore.") (defvar sam-affected-buffers nil "List of buffers affected since the last top-level sam command.") (defvar sam-edit-mode nil "Non-nil if the buffer is being edited by sam.") (or (assq 'sam-edit-mode minor-mode-alist) (nconc minor-mode-alist (list '(sam-edit-mode " Sam-Edit")))) (put 'sam-edit-mode 'permanent-local t) (defvar sam-edit-buffer-name nil "Name of buffer currently being editing by sam.") (or (assq 'sam-edit-buffer-name minor-mode-alist) (nconc minor-mode-alist (list '(sam-edit-buffer-name (" Editing: " sam-edit-buffer-name))))) (defvar sam-command-in-progress nil "String used to build up multi-line commands.") ;;; User-visible. (defvar sam-command-mode-hook nil "*Hooks to run when sam command mode is started.") (defvar sam-edit-mode-hook nil "*Hooks to run when sam edit mode is started.") (defvar sam-command-buffer-name "~~sam~~" "*Name of the buffer used to issue sam commands.") (defvar sam-case-fold-search nil "*Non-nil if searches should ignore case.") (defvar sam-emacs-style-regexps nil "*Non-nil if sam should use emacs-style regexps instead of egrep-style.") ;;; Buffer mode support functions. ;;;###autoload (defun sam () "Edit the current buffer using the sam text editor emulation package." (interactive) (setq sam-please-go-away nil) (save-excursion (set-buffer (setq sam-command-buffer (get-buffer-create sam-command-buffer-name))) (or (eq major-mode 'sam-command-mode) (sam-command-mode))) (sam-edit-mode) (pop-to-buffer sam-command-buffer)) (defun sam-command-mode () "Major mode for the sam text editor command language buffer." (interactive) (kill-all-local-variables) (use-local-map sam-command-mode-map) (setq major-mode 'sam-command-mode mode-name "Sam-Command") (run-hooks 'sam-command-mode-hook)) (defun sam-edit-mode () "Make the current buffer be the buffer affected by sam commands." (interactive) (and sam-edit-buffer (sam-leave-edit-mode)) (setq sam-edit-buffer (current-buffer)) (set (make-local-variable 'sam-edit-mode) t) (save-excursion (set-buffer sam-command-buffer) (set (make-local-variable 'sam-edit-buffer-name) (buffer-name sam-edit-buffer))) (run-hooks 'sam-edit-mode-hook)) (defun sam-leave-edit-mode () (save-excursion (set-buffer sam-command-buffer) (set (make-local-variable 'sam-edit-buffer-name) nil)) (save-excursion (and sam-edit-buffer (buffer-name sam-edit-buffer) (progn (set-buffer sam-edit-buffer) (set (make-local-variable 'sam-edit-mode) nil)))) (setq sam-edit-buffer nil)) ;;; Address structure constructors and accessors. (defmacro sam-make-addr (buffer beg end) (` (cons (, buffer) (cons (, beg) (, end))))) (defmacro sam-addr-buffer (addr) (` (car (, addr)))) (defmacro sam-addr-beg (addr) (` (car (cdr (, addr))))) (defmacro sam-addr-end (addr) (` (cdr (cdr (, addr))))) ;;; Command run-time support functions. (defmacro sam-command (addr &rest body) (` (progn (set-buffer (sam-addr-buffer (, addr))) (or (memq (current-buffer) sam-affected-buffers) (setq sam-affected-buffers (cons (current-buffer) sam-affected-buffers))) (,@ body)))) (put 'sam-command 'lisp-indent-function 1) (defmacro sam-get-dot () '(let ((mark (or (marker-position (mark-marker)) (point))) (point (point))) (cons (min mark point) (max mark point)))) (defmacro sam-set-dot (&optional beg end) (or beg (setq beg '(point))) (or end (setq end '(point))) (` (progn (set-mark (, beg)) (goto-char (, end))))) (defmacro sam-highlight-dot () '(setq mark-active (not (eq (marker-position (mark-marker)) (point))))) ;;; Text commands. (defun sam-append (addr str) (sam-command addr) (goto-char (sam-addr-end addr)) (insert-before-markers str) (sam-set-dot (sam-addr-end addr))) (defun sam-change (addr str) (sam-command addr) (kill-region (sam-addr-beg addr) (sam-addr-end addr)) (goto-char (sam-addr-beg addr)) (insert-before-markers str) (sam-set-dot (sam-addr-beg addr))) (defun sam-insert (addr str) (sam-command addr) (goto-char (sam-addr-beg addr)) (insert-before-markers str) (sam-set-dot (sam-addr-beg addr))) (defun sam-delete (addr) (sam-command addr) (kill-region (sam-addr-beg addr) (sam-addr-end addr)) (sam-set-dot)) (defun sam-substitute (addr n regexp replac global) (sam-command addr) (let ((limit (copy-marker (sam-addr-end addr))) (case-fold-search sam-case-fold-search) (substituted-something nil) (continuing t)) (goto-char (sam-addr-beg addr)) (if global (while (and continuing (re-search-forward regexp limit t n)) (setq substituted-something t) (setq continuing (< (point) limit)) (replace-match replac) (and (> (point) limit) (set-marker limit (point))) (and (= (match-beginning 0) (match-end 0)) (< (point) limit) (forward-char 1)) (setq n 1)) (and (re-search-forward regexp limit t n) (progn (setq substituted-something t) (replace-match replac))) (or substituted-something (error "Nothing substituted."))) (sam-set-dot (sam-addr-beg addr) limit) (set-marker limit nil))) (defun sam-move (addr1 addr2) (let ((where (progn (sam-command addr2) (copy-marker (sam-addr-end addr2)))) (text (progn (sam-command addr1) (buffer-substring (sam-addr-beg addr1) (sam-addr-end addr1))))) (kill-region (sam-addr-beg addr1) (sam-addr-end addr1)) (set-buffer (sam-addr-buffer addr2)) (goto-char where) (let ((beg (point))) (insert-before-markers text) (sam-set-dot beg)) (set-marker where nil))) (defun sam-copy (addr1 addr2) (sam-command addr2) (let ((text (save-excursion (set-buffer (sam-addr-buffer addr1)) (buffer-substring (sam-addr-beg addr1) (sam-addr-end addr1))))) (goto-char (sam-addr-end addr2)) (insert-before-markers text) (sam-set-dot (sam-addr-end addr2)))) ;;; Display commands. (defun sam-print (addr) (sam-command addr) (sam-set-dot (sam-addr-beg addr) (sam-addr-end addr)) (let ((text (buffer-substring (sam-addr-beg addr) (sam-addr-end addr)))) (set-buffer sam-command-buffer) (insert-before-markers text))) (defun sam-value (addr char-addr-only) (set-buffer (sam-addr-buffer addr)) (let* ((mark (1- (sam-addr-beg addr))) (point (1- (sam-addr-end addr))) (text (if char-addr-only (if (eq point mark) (format "#%d\n" point) (format "#%d,#%d\n" mark point)) (let* ((mark-line (save-excursion (1+ (count-lines (point-min) (progn (goto-char (1+ mark)) (beginning-of-line) (point)))))) (point-line (if (= mark point) mark-line (save-excursion (1+ (count-lines (point-min) (progn (goto-char point) (beginning-of-line) (point)))))))) (cond ((eq point mark) (format "%d; #%d\n" point-line point)) ((eq point-line mark-line) (format "%d; #%d,#%d\n" point-line mark point)) (t (format "%d,%d; #%d,#%d\n" mark-line point-line mark point))))))) (set-buffer sam-command-buffer) (insert-before-markers text))) ;;; File commands. (defun sam-switch-buffer (file-list) (or file-list (error "File list is empty.")) (while (and file-list (not (get-buffer (car file-list)))) (setq file-list (cdr file-list))) (or file-list (error "No matching buffers.")) (save-excursion (set-buffer (car file-list)) (sam-edit-mode)) (display-buffer (car file-list))) (defun sam-visit-files (file-list) (or file-list (error "File list is empty.")) (let ((list file-list)) (while list (or (get-buffer (car list)) (find-file (car list))) (setq list (cdr list)))) (save-excursion (set-buffer (car file-list)) (sam-edit-mode)) (display-buffer (car file-list))) (defun sam-buffer-menu () (let ((buffer-list (sam-buffer-list)) buffer) (set-buffer sam-command-buffer) (while buffer-list (setq buffer (car buffer-list) buffer-list (cdr buffer-list)) (insert-before-markers (sam-buffer-menu-line buffer))))) (defun sam-buffer-list () (let ((buffer-list (buffer-list)) (new-list nil) buffer) (while buffer-list (setq buffer (car buffer-list) buffer-list (cdr buffer-list)) (and (not (string-match "\\`[ *]" (buffer-name buffer))) (not (string= (buffer-name buffer) sam-command-buffer-name)) (save-excursion (set-buffer buffer) (not (eq major-mode 'dired-mode))) (setq new-list (cons buffer new-list)))) (nreverse new-list))) (defun sam-buffer-menu-line (buffer) (format "%s%s%s %s\n" (if (buffer-modified-p buffer) "'" " ") "+" (if (eq buffer sam-edit-buffer) "." " ") (buffer-name buffer))) (defun sam-kill-buffers (file-list) (or file-list (error "File list is empty.")) (let (buffer) (while file-list (and (setq buffer (get-buffer (car file-list))) (progn (and (eq buffer sam-edit-buffer) (sam-leave-edit-mode)) (kill-buffer buffer))) (setq file-list (cdr file-list))))) (defun sam-file-list (str) (and (string-match "\\`<" str) (save-excursion (set-buffer (get-buffer-create " *shell*")) (erase-buffer) (shell-command (substring str 1) t) (setq str (buffer-substring (point-min) (point-max))))) (let ((list nil)) (while (not (string= str "")) (setq str (sam-split-white str) list (cons (car str) list) str (cdr str))) (nreverse list))) ;;; I/O commands. (defun sam-edit (filename) (and (string= filename "") (setq filename (buffer-file-name sam-edit-buffer))) (pop-to-buffer sam-edit-buffer) (sam-leave-edit-mode) (find-alternate-file filename) (sam-edit-mode) (pop-to-buffer sam-command-buffer)) (defun sam-read (addr filename) (and (string= filename "") (setq filename (buffer-file-name sam-edit-buffer))) (sam-command addr) (kill-region (sam-addr-beg addr) (sam-addr-end addr)) (goto-char (sam-addr-beg addr)) (let ((old-point-max (point-max)) (beg (point))) (insert-file-contents filename) (forward-char (- (point-max) old-point-max)) (sam-set-dot beg))) (defun sam-write (addr filename) (set-buffer (sam-addr-buffer addr)) (if (string= filename "") (save-buffer) (write-region (sam-addr-beg addr) (sam-addr-end addr) filename)) (and (string= filename "") (setq filename (buffer-name sam-edit-buffer))) (set-buffer sam-command-buffer) (insert-before-markers (format "%s: #%d\n" filename (- (sam-addr-end addr) (sam-addr-beg addr))))) (defun sam-file (filename) (or (string= filename "") (save-excursion (set-buffer sam-edit-buffer) (set-visited-file-name filename))) (set-buffer sam-command-buffer) (insert-before-markers (sam-buffer-menu-line sam-edit-buffer))) (defun sam-pipe-in (addr command) (setq command (sam-last-shell-command command)) (sam-command addr) (kill-region (sam-addr-beg addr) (sam-addr-end addr)) (shell-command-on-region (sam-addr-beg addr) (sam-addr-beg addr) command t) (sam-set-dot (sam-addr-beg addr))) (defun sam-pipe-out (addr command) (setq command (sam-last-shell-command command)) (let ((text (save-excursion (set-buffer (sam-addr-buffer addr)) (buffer-substring (sam-addr-beg addr) (sam-addr-end addr))))) (save-excursion (set-buffer (get-buffer-create " *shell*")) (erase-buffer) (insert-before-markers text) (shell-command-on-region (point-min) (point-max) command t) (setq text (buffer-substring (point-min) (point-max))) (erase-buffer)) (set-buffer sam-command-buffer) (insert-before-markers text) (insert-before-markers "!\n"))) (defun sam-pipe-thru (addr command) (setq command (sam-last-shell-command command)) (sam-command addr) (shell-command-on-region (sam-addr-beg addr) (sam-addr-end addr) command t) (sam-set-dot (sam-addr-beg addr))) (defun sam-shell (command) (setq command (sam-last-shell-command command)) (set-buffer sam-command-buffer) (let ((old-point-max (point-max))) (shell-command command t) (forward-char (- (point-max) old-point-max)) (insert-before-markers "!\n"))) (defun sam-cd (directory) (set-buffer sam-command-buffer) (and (string= directory "") (setq directory "~/")) (cd directory) (force-mode-line-update)) (defun sam-last-shell-command (command) (or (string= command "") (setq sam-last-shell-command command)) (or sam-last-shell-command (error "No remembered shell command.")) sam-last-shell-command) ;;; Loops and conditionals. (defun sam-for-each (addr regexp cmd) (set-buffer (sam-addr-buffer addr)) (goto-char (sam-addr-beg addr)) (let ((limit (copy-marker (sam-addr-end addr))) beg (end (make-marker)) (continuing t) matches-something (case-fold-search sam-case-fold-search)) (while (and continuing (re-search-forward regexp limit t) (or (setq matches-something (/= (setq beg (match-beginning 0)) (set-marker end (point)))) (setq continuing (/= end limit)) (not (bolp)))) (sam-set-dot beg) (eval cmd) (set-buffer (sam-addr-buffer addr)) (goto-char end) (or matches-something (and continuing (forward-char 1)))) (set-marker end nil) (set-marker limit nil))) (defun sam-except-each (addr regexp cmd) (set-buffer (sam-addr-buffer addr)) (goto-char (sam-addr-beg addr)) (let ((last-end (copy-marker (sam-addr-beg addr))) (limit (copy-marker (sam-addr-end addr))) beg (end (make-marker)) (continuing t) matches-something (case-fold-search sam-case-fold-search)) (while (and continuing (re-search-forward regexp limit t) (or (setq matches-something (/= (setq beg (match-beginning 0)) (set-marker end (point)))) (setq continuing (/= end limit)) (not (bolp)))) (sam-set-dot last-end beg) (eval cmd) (set-buffer (sam-addr-buffer addr)) (goto-char end) (or matches-something (and continuing (forward-char 1)))) (sam-set-dot last-end limit) (eval cmd) (set-marker last-end nil) (set-marker limit nil) (set-marker end nil))) (defun sam-for-each-buffer (regexp cmd) (let ((buffer-list (sam-buffer-list)) buffer) (while buffer-list (setq buffer (car buffer-list) buffer-list (cdr buffer-list)) (and (string-match regexp (buffer-name buffer)) (let ((sam-edit-buffer buffer)) (eval cmd)))))) (defun sam-except-each-buffer (regexp cmd) (let ((buffer-list (sam-buffer-list)) buffer) (while buffer-list (setq buffer (car buffer-list) buffer-list (cdr buffer-list)) (or (string-match regexp (buffer-name buffer)) (let ((sam-edit-buffer buffer)) (eval cmd)))))) (defun sam-when (addr regexp cmd) (set-buffer (sam-addr-buffer addr)) (and (save-excursion (goto-char (sam-addr-beg addr)) (let ((case-fold-search sam-case-fold-search)) (re-search-forward regexp (sam-addr-end addr) t))) (progn (sam-set-dot (sam-addr-beg addr) (sam-addr-end addr)) (eval cmd)))) (defun sam-unless (addr regexp cmd) (set-buffer (sam-addr-buffer addr)) (or (save-excursion (goto-char (sam-addr-beg addr)) (let ((case-fold-search sam-case-fold-search)) (re-search-forward regexp (sam-addr-end addr) t))) (progn (sam-set-dot (sam-addr-beg addr) (sam-addr-end addr)) (eval cmd)))) ;;; Misc commands. (defun sam-quit () (setq sam-please-go-away t)) (defun sam-set-reference (addr) (set-buffer (sam-addr-buffer addr)) (setq sam-reference addr)) (defun sam-undo (addr n) (sam-command addr) (and (eq sam-last-command 'sam-undo) (setq last-command 'undo)) (undo n) (sam-set-dot)) (defun sam-goto (addr &optional was-defaulted) (sam-command addr) (and was-defaulted (let ((new-addr (sam-plus addr 0))) (and (equal addr new-addr) (setq new-addr (sam-plus addr 1))) (setq addr new-addr) (let ((text (buffer-substring (sam-addr-beg addr) (sam-addr-end addr)))) (save-excursion (set-buffer sam-command-buffer) (insert text))))) (sam-set-dot (sam-addr-beg addr) (sam-addr-end addr)) (sam-print-addr addr)) (defun sam-print-addr (addr) (let ((beg (1- (sam-addr-beg addr))) (end (1- (sam-addr-end addr)))) (if (eq beg end) (message "%s: #%d" (sam-addr-buffer addr) end) (message "%s: #%d,#%d" (sam-addr-buffer addr) beg end)))) ;;; Address run-time support functions. (defun sam-pos (buffer n) (setq n (1+ n)) (and (or (< n (point-min)) (> n (point-max))) (error "Address out of range.")) (sam-make-addr buffer n n)) (defun sam-line (buffer n) (save-excursion (set-buffer buffer) (goto-char (point-min)) (forward-line (1- n)) (sam-entire-line))) (defun sam-point-min (buffer) (save-excursion (set-buffer buffer) (sam-make-addr buffer (point-min) (point-min)))) (defun sam-point-max (buffer) (save-excursion (set-buffer buffer) (sam-make-addr buffer (point-max) (point-max)))) (defun sam-all (buffer) (sam-comma (sam-point-min buffer) (sam-point-max buffer))) (defun sam-dot (buffer) (set-buffer buffer) (let ((dot (sam-get-dot))) (sam-make-addr buffer (car dot) (cdr dot)))) (defun sam-reference (buffer) (set-buffer buffer) (or sam-reference (error "No mark set in this buffer.")) sam-reference) (defun sam-plus (addr offset) (save-excursion (set-buffer (sam-addr-buffer addr)) (goto-char (sam-addr-end addr)) (cond ((numberp offset) (if (bolp) (forward-line (1- offset)) (forward-line offset)) (sam-entire-line)) ((stringp offset) (let ((case-fold-search sam-case-fold-search) (start (point))) (or (and (re-search-forward offset nil t) (or (/= (match-beginning 0) (match-end 0)) (/= start (point)) (and (< (point) (point-max)) (progn (forward-char 1) (re-search-forward offset nil t))))) (progn (goto-char (point-min)) (re-search-forward offset)))) (sam-entire-match)) ((consp offset) (forward-char (car offset)) (sam-make-addr (current-buffer) (point) (point)))))) (defun sam-minus (addr offset) (save-excursion (set-buffer (sam-addr-buffer addr)) (goto-char (sam-addr-beg addr)) (cond ((numberp offset) (forward-line (- offset)) (sam-entire-line)) ((stringp offset) (let ((case-fold-search sam-case-fold-search) (start (point))) (or (and (re-search-backward offset nil t) (or (/= (match-beginning 0) (match-end 0)) (/= start (point)) (and (> (point) (point-min)) (progn (backward-char 1) (re-search-backward offset nil t))))) (progn (goto-char (point-max)) (re-search-backward offset)))) (sam-entire-match)) ((consp offset) (backward-char (car offset)) (sam-make-addr (current-buffer) (point) (point)))))) (defun sam-comma (addr1 addr2) (and (not (eq (sam-addr-buffer addr1) (sam-addr-buffer addr2))) (error "A comma cannot join addresses in different buffers.")) (sam-make-addr (sam-addr-buffer addr1) (sam-addr-beg addr1) (sam-addr-end addr2))) (defun sam-semi (addr) (sam-goto addr) addr) (defun sam-last-regexp (regexp) (or (string= regexp "") (setq sam-last-regexp regexp)) (or sam-last-regexp (error "No remembered search string.")) sam-last-regexp) (defun sam-regexp-to-buffer (regexp) (let ((buffer-list (buffer-list)) name (buffer nil)) (while buffer-list (and (not (string-match "\\` " (setq name (buffer-name (car buffer-list))))) (string-match regexp name) (if buffer (error "Regexp matches more than one buffer: %s and %s." buffer (car buffer-list)) (setq buffer (car buffer-list)))) (setq buffer-list (cdr buffer-list))) buffer)) (defun sam-entire-line () (sam-make-addr (current-buffer) (progn (beginning-of-line) (point)) (progn (end-of-line) (or (eobp) (forward-char 1)) (point)))) (defun sam-entire-match () (sam-make-addr (current-buffer) (match-beginning 0) (match-end 0))) ;;; Command compilation functions. (defun sam-compile-command (str &optional default-command) (or default-command (setq default-command 'sam-goto)) (let ((addr (sam-compile-address str)) (real-addr nil) (cmd nil)) (setq str (cdr addr) real-addr (car addr) addr (sam-fix-default real-addr 'sam-dot)) ;; irregular syntax, arghh (string-match "\\`\\(cd\\|.?\\)" str) (setq cmd (substring str 0 (match-end 0)) str (sam-skip-white (substring str (match-end 0)))) (let ((fun (cdr (assoc cmd sam-command-assoc)))) (or fun (error "Invalid sam command `%s'." cmd)) (and (eq fun 'sam-default) (setq fun default-command)) (cond ((eq fun 'sam-compound) (error "Compound commands don't really word yet.") (let ((text (and (string-match "\\`\n\\(\\(.*\n\\)*\\)}\\'" str) (substring str (match-beginning 1) (match-end 1))))) (and text (list fun addr text)))) ((memq fun '(sam-append sam-change sam-insert)) (let ((text (if (string-match "\\`$" str) (and (string-match "\\`\n\\(\\(\\(\\|[^.\n]\\|..+\\)\n\\)*\\)\\.\\'" str) (substring str (match-beginning 1) (match-end 1))) (sam-parse-text (car (sam-parse-string str)))))) (and text (list fun addr text)))) ((memq fun '(sam-delete sam-print sam-set-reference)) (list fun addr)) ((eq fun 'sam-goto) (list fun addr (not (sam-fix-default real-addr nil)))) ((eq fun 'sam-value) (list fun addr (string-match "\\`#" str))) ((memq fun '(sam-move sam-copy)) (list fun addr (or (car (sam-compile-address str)) '(sam-dot sam-edit-buffer)))) ((eq fun 'sam-substitute) (let* ((n (if (string-match "\\`[1-9][0-9]* *" str) (prog1 (string-to-number str) (setq str (substring str (match-end 0)))) 1)) (pair1 (sam-parse-string str)) (regexp (sam-parse-regexp (car pair1))) (pair2 (sam-parse-string (concat (substring (car pair1) 0 1) (cdr pair1)))) (replac (sam-parse-replac (car pair2))) (global (and (string-match "g" (cdr pair2)) t))) (list fun addr n regexp replac global))) ((memq fun '(sam-for-each sam-except-each)) (let* ((pair (sam-parse-string str)) (regexp (sam-parse-regexp (car pair) "^.*\n?")) (cmd (sam-compile-command (cdr pair) 'sam-print))) (and cmd (list fun addr regexp (list 'quote cmd))))) ((memq fun '(sam-for-each-buffer sam-except-each-buffer)) (let* ((pair (sam-parse-string str)) (regexp (sam-parse-regexp (car pair) ".*")) (cmd (sam-compile-command (cdr pair) 'sam-file))) (and cmd (list fun regexp (list 'quote cmd))))) ((memq fun '(sam-when sam-unless)) (let* ((pair (sam-parse-string str)) (regexp (sam-parse-regexp (car pair))) (cmd (sam-compile-command (cdr pair) nil))) (and cmd (list fun addr regexp (list 'quote cmd))))) ((eq fun 'sam-undo) (list fun addr (if (string= str "") 1 (string-to-number str)))) ((memq fun '(sam-quit sam-buffer-menu)) (list fun)) ((memq fun '(sam-switch-buffer sam-visit-files sam-kill-buffers)) (list fun (list 'sam-file-list str))) ((memq fun '(sam-edit sam-file sam-cd sam-shell)) (list fun str)) ((memq fun '(sam-read sam-write sam-pipe-in sam-pipe-out sam-pipe-thru)) (and (eq fun 'sam-write) (setq addr (sam-fix-default real-addr 'sam-all))) (list fun addr str)) (t (error "Don't yet know how to compile that command.")))))) ;;; Address compilation functions. (defun sam-compile-address (str) (let ((addrs nil) (ops nil) (parsing t) addr op buffer) (while parsing (setq str (sam-skip-white str)) (setq addr nil) ;; "regexp" (if (sam-match-delimited-string "\"" str) (setq buffer (list 'sam-regexp-to-buffer (sam-parse-regexp (substring str 0 (match-end 1)))) str (substring str (match-end 0))) (setq buffer 'sam-edit-buffer)) (cond ;; #n ((string-match "\\`# *\\([0-9]*\\)" str) (let ((n (if (eq (match-beginning 1) (match-end 1)) 1 (string-to-number (substring str 1))))) (setq addr (list 'sam-pos buffer n)))) ;; n ((string-match "\\`[0-9]+" str) (let ((n (string-to-number str))) (setq addr (if (zerop n) (list 'sam-point-min buffer) (list 'sam-line buffer n))))) ;; /regexp/ ((sam-match-delimited-string "/" str) (setq addr (list 'sam-forward buffer (sam-parse-regexp (substring str 0 (match-end 1)))))) ;; ?regexp? ((sam-match-delimited-string "?" str) (setq addr (list 'sam-backward buffer (sam-parse-regexp (substring str 0 (match-end 1)))))) ;; $ ((string-match "\\`\\$" str) (setq addr (list 'sam-point-max buffer))) ;; . ((string-match "\\`\\." str) (setq addr (list 'sam-dot buffer))) ;; ' ((string-match "\\`'" str) (setq addr (list 'sam-reference buffer)))) (and addr (setq str (sam-skip-white (substring str (match-end 0))))) (or addr (setq addr (list 'sam-default buffer))) (and nil (null addr) (not (eq buffer 'sam-edit-buffer)) (setq addr (list 'sam-dot buffer))) (setq addrs (cons addr addrs)) ;; implicit + (and addr (string-match "\\`[#0-9/?$.'\"]" str) (setq str (concat "+" str))) (if (string-match "\\`[-+,;]" str) (progn (setq op (cdr (assoc (substring str 0 1) sam-operator-assoc)) str (substring str 1)) (and ops (>= (cdr (assq (car ops) sam-precedence-assoc)) (cdr (assq op sam-precedence-assoc))) (setq addr (sam-addr-node (car ops) (car (cdr addrs)) (car addrs)) addrs (cons addr (cdr (cdr addrs))) ops (cdr ops))) (setq ops (cons op ops))) (setq parsing nil))) (while ops (setq addr (sam-addr-node (car ops) (car (cdr addrs)) (car addrs)) addrs (cons addr (cdr (cdr addrs))) ops (cdr ops))) (setq addr (sam-fix-search (car addrs))) (cons addr str))) (defun sam-addr-node (op addr1 addr2) (cond ((memq op '(sam-plus sam-minus)) (setq addr1 (sam-fix-search (sam-fix-default addr1 'sam-dot)) addr2 (sam-fix-default addr2 1)) (and (consp addr2) (let ((op2 (car addr2))) (cond ((eq op2 'sam-pos) (setq addr2 (list 'quote (list (car (cdr (cdr addr2))))))) ((eq op2 'sam-line) (setq addr2 (car (cdr (cdr addr2))))) ((eq op2 'sam-point-min) (setq addr2 0)) ((memq op2 '(sam-forward sam-backward)) (and (eq op2 'sam-backward) (setq op (if (eq op 'sam-plus) 'sam-minus 'sam-plus))) (setq addr2 (car (cdr (cdr addr2))))))))) ((memq op '(sam-comma sam-semi)) (setq addr1 (sam-fix-search (sam-fix-default addr1 'sam-point-min)) addr2 (sam-fix-search (sam-fix-default addr2 'sam-point-max))) (and (eq op 'sam-semi) (setq addr1 (list 'sam-semi addr1) op 'sam-comma)))) (list op addr1 addr2)) (defun sam-fix-default (addr default) (and (consp addr) (eq (car addr) 'sam-default) (setq addr (if (and default (symbolp default)) (list default (car (cdr addr))) default))) addr) (defun sam-fix-search (addr) (and (consp addr) (memq (car addr) '(sam-forward sam-backward)) (setq addr (list (if (eq (car addr) 'sam-forward) 'sam-plus 'sam-minus) (list 'sam-dot (car (cdr addr))) (car (cdr (cdr addr)))))) addr) ;;; Misc compilation functions. (defun sam-skip-white (str) (if (string-match "\\`[ \t]*" str) (substring str (match-end 0)) str)) (defun sam-split-white (str) (if (string-match "[ \t\n]+" str) (cons (substring str 0 (match-beginning 0)) (substring str (match-end 0))) (cons str ""))) (defun sam-match-delimited-string (str text) (let* ((c (substring str 0 1)) (re-c (regexp-quote c))) (string-match (concat "\\`" re-c "\\(\\([^" c "\\\\\n]\\|\\\\.\\)*\\)" re-c "?") text))) (defun sam-parse-string (str) (setq str (sam-skip-white str)) (if (string-match "\\`[^A-Za-z0-9\n]" str) (if (sam-match-delimited-string str str) (cons (substring str 0 (match-end 1)) (substring str (match-end 0))) (cons str "")) (cons nil str))) (defun sam-parse-regexp (regexp &optional default) (if regexp (if sam-emacs-style-regexps (sam-last-regexp (sam-parse-text regexp)) (setq regexp (append regexp nil)) (let ((new nil) (delim (car regexp)) c) (setq regexp (cdr regexp)) (while (and regexp (progn (setq c (car regexp) regexp (cdr regexp)) (not (eq c delim)))) (cond ((memq c '(?\( ?\) ?|)) (setq new (cons c (cons ?\\ new)))) ((eq c ?\[) (let ((special nil) (rest nil) (complement nil)) (and (eq (car regexp) ?^) (setq complement t regexp (cdr regexp) rest (list ?\n))) (while (and regexp (progn (setq c (car regexp) regexp (cdr regexp)) (not (eq c ?\])))) (cond ((eq c ?\\) (setq c (car regexp) regexp (cdr regexp)) (if (memq c '(?- ?\] ?^)) (or (memq c special) (setq special (cons c special))) (setq rest (cons c rest)))) ((eq c ?^) (or (memq c special) (setq special (cons c special)))) (t (setq rest (cons c rest))))) (if (and (not complement) (null rest) (equal special '(?^))) (setq new (cons ?^ new)) (setq new (cons ?\[ new)) (and complement (setq new (cons ?^ new))) (and (memq ?\] special) (setq new (cons ?\] new))) (setq new (nconc rest new)) (and (memq ?^ special) (setq new (cons ?^ new))) (and (memq ?- special) (setq new (cons ?- new))) (setq new (cons ?\] new))))) ((eq c ?\\) (setq c (car regexp) regexp (cdr regexp)) (cond ((eq c ?n) (setq new (cons ?\n new))) ((eq c delim) (setq new (cons c new))) ((memq c '(?. ?* ?+ ?\[ ?\] ?\\ ?^ ?$)) (setq new (cons c (cons ?\\ new)))) (t (setq new (cons c new))))) (t (setq new (cons c new))))) (setq new (mapconcat (function char-to-string) (nreverse new) "")) (sam-last-regexp new))) default)) (defun sam-parse-replac (replac) (setq replac (append replac nil)) (let ((new nil) (delim (car replac)) c) (setq replac (cdr replac)) (while (and replac (progn (setq c (car replac) replac (cdr replac)) (not (eq c delim)))) (cond ((eq c ?&) (setq new (cons c (cons ?\\ new)))) ((eq c ?\\) (setq c (car replac) replac (cdr replac)) (cond ((eq c ?n) (setq new (cons ?\n new))) ((eq c delim) (setq new (cons c new))) ((and (>= c ?0) (<= c ?9)) (setq new (cons c (cons ?\\ new)))) (t (setq new (cons c (cons ?\\ (cons ?\\ new))))))) (t (setq new (cons c new))))) (mapconcat (function char-to-string) (nreverse new) ""))) (defun sam-parse-text (str) (setq str (append str nil)) (let ((new nil) (delim (car str)) c) (setq str (cdr str)) (while (and str (progn (setq c (car str) str (cdr str)) (not (eq c delim)))) (cond ((eq c ?\\) (setq c (car str) str (cdr str)) (cond ((eq c ?n) (setq new (cons ?\n new))) ((eq c delim) (setq new (cons c new))) (t (setq new (cons c (cons ?\\ new)))))) (t (setq new (cons c new))))) (mapconcat (function char-to-string) (nreverse new) ""))) ;;; Command evaluation functions. (defun sam-eval-command (cmd) (let ((buffer (current-buffer))) (unwind-protect (eval cmd) (set-buffer buffer)) (setq sam-last-command (car cmd))) (save-excursion (while sam-affected-buffers (let* ((buffer (car sam-affected-buffers)) (window (get-buffer-window buffer))) (set-buffer buffer) (set-window-start window (save-excursion (goto-char (window-start window)) (beginning-of-line) (point)) t) (set-window-point window (point)) (undo-boundary) (sam-highlight-dot)) (setq sam-affected-buffers (cdr sam-affected-buffers))))) (defun sam-eval-last-command () (interactive) (let* ((str (buffer-substring (progn (beginning-of-line) (point)) (progn (end-of-line) (point)))) (cmd (condition-case nil (let ((case-fold-search nil)) (setq sam-command-in-progress (concat sam-command-in-progress str)) (sam-compile-command sam-command-in-progress)) (error (setq sam-command-in-progress nil) nil)))) (end-of-line) (or (and cmd (string= str "")) (if (eobp) (insert-before-markers "\n") (forward-char 1))) (if cmd (progn (setq sam-command-in-progress nil) (sam-eval-command cmd) (or (bolp) (insert-before-markers "\n")) (and sam-please-go-away (progn (sam-leave-edit-mode) (kill-buffer sam-command-buffer)))) (setq sam-command-in-progress (concat sam-command-in-progress "\n"))))) ;;; End of sam.el. From sam-fans-owner Thu Mar 17 19:28:46 1994 Received: from math.tau.ac.il ([132.67.64.4]) by hawkwind.utcs.toronto.edu with SMTP id <24181>; Thu, 17 Mar 1994 19:25:49 -0500 Return-Path: Received: from virgo.math.tau.ac.il by math.tau.ac.il (5.67/math.tau-930921) id AA13145; Fri, 18 Mar 94 02:25:35 +0200 Comments: The BITNET node taurus.bitnet will cease to exist as of March 1994. If you are still using the address user@taurus.bitnet please convert it to user@math.tau.ac.il Received: by virgo.math.tau.ac.il (5.67/math.sub-st921020) id AA23449; Fri, 18 Mar 94 02:25:34 +0200 From: laden@math.tau.ac.il Message-Id: <9403180025.AA23449@virgo.math.tau.ac.il> Subject: samx2 patches To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 17 Mar 1994 19:25:33 -0500 X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 493 hi, has anyone applied the samx2 patches to the current (4.1) version of sam? i get 3 failures from 'patch', not to mention real bugs probably introduced. if anyone has done this already, could they post them to the list. btw: a useful patch i have not seen is the removal of 'click-to-type' i am _very_ new to sam so i dont realy know if this would somehow break some functionality, but it seems like a simple fix which could save plenty of mouse clicks. anyone done this? thanks, guy. From sam-fans-owner Fri Mar 18 05:52:41 1994 Received: from nac.no ([129.240.2.40]) by hawkwind.utcs.toronto.edu with SMTP id <24181>; Fri, 18 Mar 1994 05:52:01 -0500 Received: from betsy.texcel.no by nac.no with SMTP (PP) id <29686-0@nac.no>; Fri, 18 Mar 1994 11:30:21 +0100 Received: from texcel.no by betsy.texcel.no (4.1/SMI-4.1) id AA14441; Fri, 18 Mar 94 11:32:58 +0100 Received: from cymru.uk by texcel.no.texcel.no (4.1/SMI-4.1) id AA07615; Fri, 18 Mar 94 10:19:25 GMT Date: Fri, 18 Mar 1994 05:19:25 -0500 From: mdr@texcel.no (Mark Robinson) Message-Id: <9403181019.AA07615@texcel.no.texcel.no> To: sam-fans@hawkwind.utcs.toronto.edu Subject: binding commands to keys hi i guess the thing that bugs me most about sam is that cursor movement and editing commands cannot be bound to key strokes. are there any patches to correct this? or have i missed something? feel free to flame if i'm being stupid :-o cheers mark From sam-fans-owner Fri Mar 18 06:22:46 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <24182>; Fri, 18 Mar 1994 06:22:27 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Fri, 18 Mar 1994 10:59:49 +0000 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA07682; Fri, 18 Mar 1994 11:02:42 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA12430; Fri, 18 Mar 1994 10:57:58 +0000 Date: Fri, 18 Mar 1994 05:57:58 -0500 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9403181057.AA12430@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: binding commands to keys X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 498 > i guess the thing that bugs me most about sam is that cursor movement > and editing commands cannot be bound to key strokes. > > are there any patches to correct this? or have i missed something? well, i believe the xsam patches fixed this, but as was pointed out, they were for an earlier release. strangely enough, i don't find myself missing the cursor keys at all, except when editing single characters (when my eyes really strain:-( ). In general use, i just seem to not use them much. From sam-fans-owner Fri Mar 18 10:07:57 1994 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.toronto.edu with SMTP id <24181>; Fri, 18 Mar 1994 10:07:05 -0500 Via: uk.ac.edinburgh.epcfta; Fri, 18 Mar 1994 13:52:04 +0000 From: Andrew Higham Date: Fri, 18 Mar 1994 08:51:18 -0500 Message-Id: <4422.9403181351@epcfta.ed.ac.uk> Subject: Re: samx2 patches To: laden@math.tau.ac.il, sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: laden@il.ac.tau.math's message of Thu, 17 Mar 1994 19:25:33 -0500 Organisation: Edinburgh Portable Compilers Ltd. Phone: +44 31 225 6262 > btw: a useful patch i have not seen is the removal of 'click-to-type' > i am _very_ new to sam so i dont realy know if this would somehow break > some functionality, but it seems like a simple fix which could save plenty > of mouse clicks. anyone done this? The following patch is a combination of a couple of patches discussed here before. Sam works fine without click-to-type. The only small problem is that it is a bit too easy to change the focus of commands by moving the mouse pointer through another file window on its way to the ~sam~ window. But I find the default click-to-type has more problems for someone who uses a point-to-type window manager. Andrew # to apply: patch -d newsam -p1 < thispatch *** sam4.1/samterm/main.c Fri Mar 18 11:37:28 1994 --- newsam/samterm/main.c Fri Mar 18 12:25:02 1994 *************** *** 102,107 **** --- 102,109 ---- scroll(which, 3, fwdbut == 3 ? 3 : 1); else menu3hit(); + }else if(nwhich && nwhich!=which){ + current(nwhich); } mouseunblock(); } *************** *** 128,134 **** flborder(which, 0); if(nw){ flushtyping(1); - flupfront(nw); flborder(nw, 1); buttons(Up); t = (Text *)nw->user1; --- 130,135 ---- *** sam4.1/samterm/menu.c Fri Mar 18 11:37:28 1994 --- newsam/samterm/menu.c Fri Mar 18 12:25:06 1994 *************** *** 178,183 **** --- 178,184 ---- i = 0; while(i!=t->front && t->l[i].textfn==0); current(&t->l[i]); + flupfront(&t->l[i]); }else if(!lock) sweeptext(0, tag[m-NMENU3]); break; From sam-fans-owner Fri Mar 18 10:11:47 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.toronto.edu with SMTP id <24182>; Fri, 18 Mar 1994 10:11:22 -0500 From: rob@plan9.research.att.com Date: Fri, 18 Mar 1994 10:10:59 -0500 To: Subject: Re: binding commands to keys Message-Id: <94Mar18.101122est.24182@hawkwind.utcs.toronto.edu> i thought it was clear that part of the point of sam was to separate functionality: input from the keyboard, control from the mouse. with the exception of the scroll key, which i did because of strong pressure and never use myself, the division is firm and worked out well. if you want to type funny characters at your editor to make things happen, there's a wide variety of editors out there. don't compromise the one editor that takes a different stand. -rob From sam-fans-owner Fri Mar 18 10:24:42 1994 Received: from sequent.kiae.su ([144.206.136.6]) by hawkwind.utcs.toronto.edu with SMTP id <24183>; Fri, 18 Mar 1994 10:24:21 -0500 Received: by sequent.kiae.su id AA14392 (5.65.kiae-1 for sam-fans@hawkwind.utcs.toronto.edu); Fri, 18 Mar 1994 18:01:24 +0300 Received: by sovcom.kiae.su; Fri, 18 Mar 94 17:53:49 +0300 To: sam-fans@hawkwind.utcs.toronto.edu (Sam fans) Subject: archive Return-Receipt-To: nms@saukh.suug.msk.su Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <690.763996225.1@saukh.suug.msk.su> Date: Fri, 18 Mar 1994 08:10:26 -0500 Message-Id: <691.763996226@saukh.suug.msk.su> From: Nickolay Saukh Is there archive for patches/mods/....? I would like to add support for russian, but without reinventing the wheel. I have sources of version 4.1. Thanks From sam-fans-owner Fri Mar 18 11:47:50 1994 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <24181>; Fri, 18 Mar 1994 11:47:18 -0500 Received: from uucp6.UU.NET by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhtz03729; Fri, 18 Mar 94 11:46:59 -0500 Date: Fri, 18 Mar 1994 11:46:59 -0500 From: plexus-sys!mdash@uunet.uu.net Message-Id: <9403181646.AAwhtz03729@relay2.UU.NET> Received: from plexus-sys.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 18 Mar 1994 11:47:02 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Subject: version Content-Type: text Content-Length: 235 Recent posts refer to "version 4.1" of sam. I don't recall seeing point release naming applied to sam before. The latest source I picked up is vintage ca. September 93. Is a later tree available? --Mike Scheer, mdash@plexus-sys.com From sam-fans-owner Fri Mar 18 12:03:21 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.toronto.edu with SMTP id <24181>; Fri, 18 Mar 1994 12:02:56 -0500 From: rob@plan9.research.att.com To: Date: Fri, 18 Mar 1994 12:02:17 -0500 Message-Id: <94Mar18.120256est.24181@hawkwind.utcs.toronto.edu> the "4.1" naming convention is new to me. as for russian, the posted sam sources support the unicode character set as encoded by the plan 9 UTF byte-stream encoding, now called UTF-8 by ISO. the russian poster probably has his own character set and encoding. to support them, it should be sufficient to modify the encoding/decoding routines at the periphery; the system will handle the rest. sam has been used like this in greece since 1986, long before unicode. the core of the editor doesn't care about the character set as long as values 0-127 are ASCII. now for our russian friend, that might not be true, in which case he has a problem. i'd suggest converting to unicode and UTF - why not be able to edit english AND russian with the same editor? -rob From sam-fans-owner Fri Mar 18 12:11:52 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.toronto.edu with SMTP id <24182>; Fri, 18 Mar 1994 12:11:33 -0500 From: bobf@plan9.research.att.com To: Date: Fri, 18 Mar 1994 12:03:29 -0500 Message-Id: <94Mar18.121133est.24182@hawkwind.utcs.toronto.edu> the last version of sam i released is version 4.1 dated October 8, 1993. there should be a file named "version" in the top-level directory of the distribution with a version stamp. i have no plans to release another version anytime soon. From sam-fans-owner Fri Mar 18 12:26:22 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24183>; Fri, 18 Mar 1994 12:25:50 -0500 Received: from uucp6.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhub00554; Fri, 18 Mar 94 12:25:38 -0500 Date: Fri, 18 Mar 1994 12:25:37 -0500 From: plexus-sys!mdash@uunet.uu.net Message-Id: <9403181725.AAwhub00554@relay1.UU.NET> Received: from plexus-sys.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 18 Mar 1994 12:25:40 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Content-Type: text Content-Length: 207 I'd overlooked the version file. Now that I see it, it shows my tree to be Version 4.0 built Thu Sep 23 16:20:22 EDT 1993. What are the differences between 4.1 and 4.0? --Mike Scheer, mdash@plexus-sys.com From sam-fans-owner Fri Mar 18 14:14:45 1994 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <24182>; Fri, 18 Mar 1994 14:11:34 -0500 To: sam-fans (Sam fans) Subject: Re: archive In-reply-to: nms's message of Fri, 18 Mar 1994 08:10:26 -0500. <691.763996226@saukh.suug.msk.su> Date: Fri, 18 Mar 1994 14:11:23 -0500 From: Chris Siebenmann Message-Id: <94Mar18.141134est.24182@hawkwind.utcs.toronto.edu> There's the mailing list archive itself, on ftp.sys.utoronto.ca in /pub/sam. No one has had the energy to pull out just the patches; if someone does, I'll happily make it ftpable. - cks From sam-fans-owner Sat Mar 19 01:12:05 1994 Received: from sequent.kiae.su ([144.206.136.6]) by hawkwind.utcs.toronto.edu with SMTP id <24182>; Sat, 19 Mar 1994 01:11:04 -0500 Received: by sequent.kiae.su id AA21752 (5.65.kiae-1 for sam-fans@hawkwind.utcs.toronto.edu); Sat, 19 Mar 1994 09:08:15 +0300 Received: by sovcom.kiae.su; Sat, 19 Mar 94 09:04:08 +0300 To: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: Your message of "Fri, 18 Mar 1994 20:02:17 +0300." <94Mar18.120256est.24181@hawkwind.utcs.toronto.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <169.764056190.1@saukh.suug.msk.su> Date: Sat, 19 Mar 1994 00:49:51 -0500 Message-Id: <170.764056191@saukh.suug.msk.su> From: Nickolay Saukh > the russian poster probably has his own character > set and encoding. to support them, it should be sufficient to modify the > encoding/decoding routines at the periphery; Well, my message was unclear. I would like to modify input method (translation from X keycodes). From sam-fans-owner Mon Mar 21 10:12:54 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24184>; Mon, 21 Mar 1994 10:11:28 -0500 Received: from uucp4.uu.net (via uucp4-le1.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwieu00909; Mon, 21 Mar 94 10:11:13 -0500 Received: from rexago8.UUCP by uucp4.uu.net with UUCP/RMAIL ; Mon, 21 Mar 1994 10:11:15 -0500 Received: by summitis.com (smail2.5) id AA04611; 21 Mar 94 09:52:42 EST (Mon) Received: from summitis.com by rserv1.YYY; Mon, 21 Mar 1994 09:50 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA50844; Mon, 21 Mar 1994 09:51:09 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA21526; Mon, 21 Mar 1994 09:51:08 -0500 From: hc05@summitis.com Message-Id: <9403211451.AA21526@cheetah> Subject: Long lists of files To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 725 Date: Mon, 21 Mar 1994 10:11:26 -0500 >From time to time I need to edit lots of files in sam, so many, in fact, that the file list on button 3 can not fit them all on the screen. I gather from sam.ps that I am supposed to get a scrollbar on this list but I don't, so I can only choose some of the open files. Is there something I have done wrong? Sam is running on an RS/6000. Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Mon Mar 21 10:29:51 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.toronto.edu with SMTP id <24186>; Mon, 21 Mar 1994 10:29:32 -0500 From: rob@plan9.research.att.com To: Date: Mon, 21 Mar 1994 10:29:20 -0500 Message-Id: <94Mar21.102932est.24186@hawkwind.utcs.toronto.edu> sam on the blit had scrolling menus because someone else implemented them in the library that sam linked with. i found them unusably fussy to navigate so when sam moved off the blit scrolling menus were left behind. a good implementation might save the idea but that is harder than most realize. the simpler solution, the one we apply here, is to keep the list of files manageable. this means the menu works equally well for all files all the time. of course, this is a matter of taste. you have the source. -rob From sam-fans-owner Tue Mar 22 03:41:25 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <24184>; Tue, 22 Mar 1994 03:40:19 -0500 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 22 Mar 1994 08:39:16 +0000 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA29876; Tue, 22 Mar 1994 08:41:58 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA13193; Tue, 22 Mar 1994 08:37:10 +0000 Date: Tue, 22 Mar 1994 03:37:10 -0500 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9403220837.AA13193@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: scrolling menus X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 1426 > sam on the blit had scrolling menus because someone > else implemented them in the library that sam linked > with. i found them unusably fussy to navigate so when > sam moved off the blit scrolling menus were left > behind. a good implementation might save the idea > but that is harder than most realize. they are awkward, this is true. but they do work. > the simpler solution, the one we apply here, is to keep > the list of files manageable. this means the menu works > equally well for all files all the time. hmm. not entirely a suitable solution. "sam *.c" is a common invocation, and it's irritating to have to quit again, just because the menu's too large. > of course, this is a matter of taste. you have the > source. indeed. one approach i tried was to have a "more" option on menu three. the number of files listed in menu three were limited by the size of the main window, and the "more" option cycled the files that were available. It worked, but it was even more sloppy than the scrolling menu, which is what i use now. out of curiosity, has anyone tried menus that required a double click? First click pulls the menu up, second selects an option or dismisses the menu (if outside of the menu). if the menu had a scrollbar, it would function like a normal window's scrollbar. of course, this goes against the "minimum action from the user" principles in rob GUIs, but it's just a thought... steve From sam-fans-owner Tue Mar 22 12:43:20 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24187>; Tue, 22 Mar 1994 12:42:24 -0500 Received: from uucp6.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwiiw14373; Tue, 22 Mar 94 12:42:13 -0500 Received: from rexago8.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 22 Mar 1994 12:42:15 -0500 Received: by summitis.com (smail2.5) id AA20016; 22 Mar 94 12:22:28 EST (Tue) Received: from summitis.com by rserv1.YYY; Tue, 22 Mar 1994 12:19 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA86034; Tue, 22 Mar 1994 12:20:39 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA10709; Tue, 22 Mar 1994 12:20:37 -0500 From: hc05@summitis.com Message-Id: <9403221720.AA10709@cheetah> Subject: Thanks for menuhit advice To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 650 Date: Tue, 22 Mar 1994 12:42:20 -0500 Thanks to all for the menuhit advice. I just compiled it and it works fine, even with samx2. Since sam does such a good job of avoiding arbitrary limits, I am glad not to be limited in the number of files I can easily work with (yes I know I can always type "b filename"). Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Tue Mar 22 13:40:13 1994 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by hawkwind.utcs.toronto.edu with SMTP id <24187>; Tue, 22 Mar 1994 13:39:50 -0500 Received: from utis179.cs.utwente.nl by utrhcs.cs.utwente.nl (4.1/RBCS-2.6mx) id AA19317; Tue, 22 Mar 94 19:39:23 +0100 Received: by utis179.cs.utwente.nl (4.1/RBCS-1.0.1) id AA01677; Tue, 22 Mar 94 19:39:20 +0100 Message-Id: <9403221839.AA01677@utis179.cs.utwente.nl> To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) Subject: Re: Thanks for menuhit advice In-Reply-To: Your message of "Tue, 22 Mar 1994 12:42:20 -0500." <9403221720.AA10709@cheetah> From: Axel Belinfante X-Organisation: University of Twente, Dept. of Computer Science, Tele Informatics Group, PO Box 217, NL-7500 AE Enschede, The Netherlands X-Phone: +31 53 893774 X-Telefax: +31 53 333815 Date: Tue, 22 Mar 1994 13:39:19 -0500 Sender: belinfan@cs.utwente.nl Beirne Konarski writes: > Thanks to all for the menuhit advice. I just compiled it and it works > fine, even with samx2. Since sam does such a good job of avoiding > arbitrary limits, I am glad not to be limited in the number of files I > can easily work with (yes I know I can always type "b filename"). Well, there _is_ a limit (or did i miss something???): samterm/samterm.h:#define MAXFILES 256 (which i found when i did something like 'sam */*.[ch]' - after sam panic-ed ("menuins"), i checked and found that i tried to load > 1000 files... :-) That 'panic' surprised me a bit, though - i second above praise about avoided arbitrary limits: i use to 'sam first, ask questions later' (like: 'how many files i'm loading?') and it (almost :-) always works!! Axel. tel. +31 53 893774 fax. +31 53 333815 University of Twente, Tele-Informatics & Open Systems Group P.O. Box 217 NL-7500 AE Enschede The Netherlands "ili ne sciis ke estas neebla do ili simple faris" -- Loesje From sam-fans-owner Thu Mar 24 13:31:34 1994 Received: from sequent.kiae.su ([144.206.136.6]) by hawkwind.utcs.toronto.edu with SMTP id <24181>; Thu, 24 Mar 1994 13:28:37 -0500 Received: by sequent.kiae.su id AA12893 (5.65.kiae-1 for sam-fans@hawkwind.utcs.toronto.edu); Thu, 24 Mar 1994 21:18:45 +0300 To: sam-fans@hawkwind.utcs.toronto.edu (Sam fans) Subject: extra national support for X Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <458.764532651.1@saukh.suug.msk.su> Date: Thu, 24 Mar 1994 13:10:52 -0500 Message-Id: <459.764532652@saukh.suug.msk.su> From: Nickolay Saukh This set of patches introduce table of translations from X keycodes to runes. It is handy if you already solved national problem for X ;-). All changes protected by #ifdef KEYMAP ... #endif. The table looks like X_keycode Unicode Codes converted by strtol, so octal, decimal, hexadecimal numbers are allowed. diff --new-file --unified --recursive sam-4.1.orig/libXg/Gwin.h plan9/libXg/Gwin.h --- sam-4.1.orig/libXg/Gwin.h Thu Mar 24 20:47:32 1994 +++ plan9/libXg/Gwin.h Thu Mar 24 20:42:55 1994 @@ -16,6 +16,10 @@ #define XtCP9font "P9font" #define XtNcomposeMod "composeMod" #define XtCComposeMod "ComposeMod" +#if defined(KEYMAP) +#define XtNp9keymap "p9keymap" +#define XtCP9keymap "P9keymap" +#endif /* External reference to the class record pointer */ extern WidgetClass gwinWidgetClass; diff --new-file --unified --recursive sam-4.1.orig/libXg/GwinP.h plan9/libXg/GwinP.h --- sam-4.1.orig/libXg/GwinP.h Thu Mar 24 20:47:33 1994 +++ plan9/libXg/GwinP.h Thu Mar 24 20:42:55 1994 @@ -17,6 +17,9 @@ Mousefunc gotmouse; /* Notify app of mouse change */ String selection; /* Current selection */ String p9font; +#if defined(KEYMAP) + String p9keymap; +#endif int compose; } GwinPart; diff --new-file --unified --recursive sam-4.1.orig/libXg/gwin.c plan9/libXg/gwin.c --- sam-4.1.orig/libXg/gwin.c Thu Mar 24 20:47:38 1994 +++ plan9/libXg/gwin.c Thu Mar 24 20:42:56 1994 @@ -48,6 +48,10 @@ Offset(selection), XtRString, (XtPointer) NULL}, {XtNp9font, XtCP9font, XtRString, sizeof(String), Offset(p9font), XtRString, (XtPointer) NULL}, +#if defined(KEYMAP) + {XtNp9keymap, XtCP9keymap, XtRString, sizeof(String), + Offset(p9keymap), XtRString, (XtPointer) NULL}, +#endif {XtNcomposeMod, XtCComposeMod, XtRInt, sizeof(int), Offset(compose), XtRImmediate, (XtPointer) 0} }; @@ -213,7 +217,11 @@ } if(k == NoSymbol) return; - if(k&0xFF00){ +#if defined(KEYMAP) + if((k & 0xFF00) == 0xFF00){ +#else + if((k & 0xFF00)){ +#endif switch(k){ case XK_BackSpace: case XK_Tab: @@ -254,7 +262,7 @@ k = 0x81; /* PREVIEW -- "Scroll back" */ break; default: - return; /* not ISO-1 or tty control */ + return; /* not tty control */ } } /* Compensate for servers that call a minus a hyphen */ @@ -268,6 +276,22 @@ && composing == -2) composing = -1; if (composing > -2) { +#if defined(KEYMAP) + if((c = keyxlate(k)) == -1) { + if((k & 0xFF00)) + return; + } else if((c & 0xff00)) { + k = (unsigned short)c; + composing++; + STUFFCOMPOSE(); + composing = -2; + f = ((GwinWidget)w)->gwin.gotchar; + if(f) + (*f)(k); + + } else + k = (unsigned short)c; +#endif compose[++composing] = k; if ((*compose == 'X') && (composing > 0)) { if ((k < '0') || (k > 'f') || @@ -296,8 +320,18 @@ composing++; STUFFCOMPOSE(); } - c = (unsigned short)k; composing = -2; +#if defined(KEYMAP) + c = keyxlate(k); + if(c == -1) { + if((k & 0xFF00)) + return; + else + c = (unsigned short)k; + } +#else + c = (unsigned short)k; +#endif } if (composing >= -1) diff --new-file --unified --recursive sam-4.1.orig/libXg/libgint.h plan9/libXg/libgint.h --- sam-4.1.orig/libXg/libgint.h Thu Mar 24 20:47:39 1994 +++ plan9/libXg/libgint.h Thu Mar 24 20:42:56 1994 @@ -90,3 +90,23 @@ UseCopyPlane, UseFillRectangle }; + +#if defined(KEYMAP) + +typedef struct Keymap Keymap; +typedef struct KeyXtab KeyXtab; + +struct Keymap { + int nkeys; + KeyXtab* keyxtab; +}; + +struct KeyXtab { + unsigned long xkey; + Rune ukey; +}; + +Keymap* rdkeymapfile(char* name); + +extern Keymap *_keymap; +#endif diff --new-file --unified --recursive sam-4.1.orig/libXg/rdkeymapfile.c plan9/libXg/rdkeymapfile.c --- sam-4.1.orig/libXg/rdkeymapfile.c Thu Jan 1 03:00:00 1970 +++ plan9/libXg/rdkeymapfile.c Thu Mar 24 20:42:56 1994 @@ -0,0 +1,109 @@ +#if defined(KEYMAP) +#include +#include +#include "libgint.h" +#include +#include +#include + +static char* +skip(char *s) +{ + while (*s==' ' || *s=='\n' || *s=='\t') + s++; + return s; +} + +static int +keyxcmp(const void* n1, const void* n2) +{ + return (int)(((const KeyXtab *)n1)->xkey - + ((const KeyXtab *)n2)->xkey); +} + +Keymap * +rdkeymapfile(char *name) +{ + Keymap *keymap; + KeyXtab* c; + int fd, i; + char *buf, *s; + struct stat sbuf; + unsigned long xcode, ucode; + + fd = open(name, O_RDONLY); + if (fd < 0) + return 0; + if (fstat(fd, &sbuf) < 0) + { + Err0: + close(fd); + return 0; + } + buf = (char *)malloc(sbuf.st_size+1); + if (buf == 0) + goto Err0; + buf[sbuf.st_size] = 0; + i = read(fd, buf, sbuf.st_size); + close(fd); + if (i != sbuf.st_size) + { + Err1: + free(buf); + return 0; + } + + s = buf; + keymap = (Keymap *)malloc(sizeof(Keymap)); + if (keymap == 0) + goto Err1; + memset((void*)keymap, 0, sizeof(Keymap)); + + do { + xcode = strtol(s, &s, 0); + s = skip(s); + ucode = strtol(s, &s, 0); + while(*s && *s++ != '\n') + ; + if(ucode>=65536) { + Err3: + if(keymap->keyxtab) + free(keymap->keyxtab); + free(keymap); + return 0; + } + if (keymap->keyxtab) + keymap->keyxtab = (KeyXtab *)realloc(keymap->keyxtab, (nkeys+1)*sizeof(KeyXtab)); + else + keymap->keyxtab = (KeyXtab *)malloc(sizeof(KeyXtab)); + if (keymap->keyxtab == 0) { + /* realloc manual says keymap->keyxtab may have been destroyed */ + keymap->nkeys = 0; + goto Err3; + } + c = &keymap->keyxtab[keymap->nkeys]; + c->xkey = xcode; + c->ukey = ucode; + keymap->nkeys++; + } while(*s); + free(buf); + qsort(keymap->keyxtab, keymap->nkeys, sizeof(KeyXtab), keyxcmp); + return keymap; +} + +int +keyxlate(unsigned long key) +{ + KeyXtab *xup; + KeyXtab datum; + + if(_keymap == 0) + return (-1); + datum.xkey = key; + xup = (KeyXtab *) bsearch(&datum, _keymap->keyxtab, + _keymap->nkeys, sizeof(KeyXtab), keyxcmp); + if(xup == 0) + return (-1); + return xup->ukey; +} +#endif /* defined(KEYMAP) */ diff --new-file --unified --recursive sam-4.1.orig/libXg/xtbinit.c plan9/libXg/xtbinit.c --- sam-4.1.orig/libXg/xtbinit.c Thu Mar 24 20:47:45 1994 +++ plan9/libXg/xtbinit.c Thu Mar 24 20:42:57 1994 @@ -43,6 +43,9 @@ unsigned long _ld2dmask[6] = { 0x1, 0x3, 0xF, 0xFF, 0xFFFF, 0xFFFFFFFF }; Colormap _libg_cmap; int _cmap_installed; +#if defined(KEYMAP) +Keymap *_keymap; +#endif /* xbinit implementation globals */ #ifndef R3 @@ -112,6 +115,10 @@ static XrmOptionDescRec optable[] = { {"-p9fn", "*p9font", XrmoptionSepArg, (caddr_t)NULL}, {"-p9font", "*p9font", XrmoptionSepArg, (caddr_t)NULL}, +#if defined(KEYMAP) + {"-p9km", "*p9keymap", XrmoptionSepArg, (caddr_t)NULL}, + {"-p9keymap", "*p9keymap", XrmoptionSepArg, (caddr_t)NULL}, +#endif }; void @@ -126,6 +133,9 @@ char *p; XSetWindowAttributes attr; int compose; +#if defined(KEYMAP) + String keymapname; +#endif if(!class && argv[0]){ p = strrchr(argv[0], '/'); @@ -158,6 +168,9 @@ XtSetArg(args[n], XtNfont, &xf); n++; XtSetArg(args[n], XtNp9font, &fontname); n++; XtSetArg(args[n], XtNcomposeMod, &compose); n++; +#if defined(KEYMAP) + XtSetArg(args[n], XtNp9keymap, &keymapname); n++; +#endif XtGetValues(widg, args, n); if (compose < 0 || compose > 5) { @@ -192,6 +205,12 @@ subfont = XFontStructtoSubfont(xf); font = mkfont(subfont); } +#if defined(KEYMAP) + _keymap = 0; + if(keymapname) { + _keymap = rdkeymapfile(keymapname); + } +#endif /* leave screen rect at all zeros until reshaped() sets it */ while(!exposed) { XFlush(_dpy); From sam-fans-owner Thu Apr 7 21:11:11 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.toronto.edu with SMTP id <24210>; Thu, 7 Apr 1994 21:08:22 -0400 Received: from hassle.Stanford.EDU (hassle.Stanford.EDU [36.59.0.161]) by drizzle.Stanford.EDU (8.6.4/8.6.4) with ESMTP id SAA06104 for ; Thu, 7 Apr 1994 18:08:07 -0700 From: Castor Fu Received: from localhost (castor@localhost) by hassle.Stanford.EDU (8.6.5/8.6.4) id SAA18926 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 7 Apr 1994 18:06:55 -0700 Message-Id: <199404080106.SAA18926@hassle.Stanford.EDU> Subject: UTF tools To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 7 Apr 1994 21:06:55 -0400 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 272 Anyone have the equivalent of enscript for UTF? I've been commenting my code using the unicode character set, and I've got the urge to print it. . . . I don't really need a full character set, but something which could handle the math ones would be nice. . . -castor From sam-fans-owner Mon Apr 11 15:12:56 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24214>; Mon, 11 Apr 1994 15:11:50 -0400 Received: from uucp3.uu.net by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwley13269; Mon, 11 Apr 94 15:11:45 -0400 Received: from rexago8.UUCP by uucp3.uu.net with UUCP/RMAIL ; Mon, 11 Apr 1994 15:11:46 -0400 Received: by summitis.com (smail2.5) id AA01063; 11 Apr 94 15:03:07 EDT (Mon) Received: from summitis.com by rserv1.YYY; Mon, 11 Apr 1994 15:02 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA80456; Mon, 11 Apr 1994 15:01:37 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA17038; Mon, 11 Apr 1994 15:01:36 -0400 From: hc05@summitis.com Message-Id: <9404111901.AA17038@cheetah> Subject: tr using c To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 637 Date: Mon, 11 Apr 1994 15:11:49 -0400 Page 10 of the sam tutorial gives an example of how to convert lower case to upper case using a pipe through tr. It then says: "Of course, you could do this more efficiently with a simple c command...". How would I do this without using 26 c commands? Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Mon Apr 11 15:29:49 1994 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu with SMTP id <24214>; Mon, 11 Apr 1994 15:29:13 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA16612; Mon, 11 Apr 94 15:28:43 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA14607; Mon, 11 Apr 94 15:27:42 -0400 Date: Mon, 11 Apr 1994 15:27:42 -0400 From: rsalz@osf.org Message-Id: <9404111927.AA14607@sulphur.osf.org> To: sam-fans-owner@hawkwind.utcs.toronto.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: tr using c >would I do this without using 26 c commands? you could write a script to create the 26 c commands and feed them into the sam pipe... From sam-fans-owner Tue May 10 07:51:36 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <23978>; Tue, 10 May 1994 07:48:05 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 10 May 1994 11:25:14 +0100 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA27595; Tue, 10 May 1994 11:28:37 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA04203; Tue, 10 May 1994 11:23:05 +0000 Date: Tue, 10 May 1994 07:23:05 -0400 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9405101023.AA04203@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: menu line characters X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 580 minor gripe: the menu lines use '+' and '*' to indicate the number of windows open on a file. wouldn't it make more sense to use characters that don't have special meanings within a regular expression? that would save on escaping these characters on the odd occasion they're used in a command. The following are available (I think): ! # % : ; " < > ~ Although it's a pretty arbitrary decision about which should be used ('-+*' makes some sense, since each character has more used pixels than the previous one), '-:;' '-%#' and '-<>' make a small amount of sense to me.... steve From sam-fans-owner Wed May 18 11:47:39 1994 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <23989>; Wed, 18 May 1994 11:43:41 -0400 Received: from uucp3.uu.net by relay3.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA12567; Wed, 18 May 94 11:43:27 -0400 Received: from rexago8.UUCP by uucp3.uu.net with UUCP/RMAIL ; Wed, 18 May 1994 11:43:27 -0400 Received: by summitis.com (smail2.5) id AA16066; 18 May 94 11:28:51 EDT (Wed) Received: from summitis.com by rserv1.YYY; Wed, 18 May 1994 11:28 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA68927; Wed, 18 May 1994 11:28:26 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA13025; Wed, 18 May 1994 11:28:24 -0400 From: hc05@summitis.com Message-Id: <9405181528.AA13025@cheetah> Subject: First character of selected space To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 789 Date: Wed, 18 May 1994 11:43:30 -0400 I have a set of C identifiers for which I would like to make the first letter capital, through a pipe to tr. The problem is selecting the first character from the currently selected text, so I can pipe on it. As an example, I want to take id1, xl2, rs4, a and turn them into Id1, Il2, Is4, A Is there a way to select the first character of each identifier so I can pipe it to tr "[a-z]" "[A-Z]"? Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Wed May 18 13:42:36 1994 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <23989>; Wed, 18 May 1994 13:42:16 -0400 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25163; Wed, 18 May 94 13:42:08 -0400 Received: from rexago8.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Wed, 18 May 1994 13:42:09 -0400 Received: by summitis.com (smail2.5) id AA16994; 18 May 94 13:36:10 EDT (Wed) Received: from summitis.com by rserv1.YYY; Wed, 18 May 1994 13:35 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA65647; Wed, 18 May 1994 13:35:49 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA17043; Wed, 18 May 1994 13:35:46 -0400 From: hc05@summitis.com Message-Id: <9405181735.AA17043@cheetah> Subject: Re: First character of selected space To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) In-Reply-To: <9405181528.AA13025@cheetah> from "Beirne Konarski" at May 18, 94 11:43:30 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 567 Date: Wed, 18 May 1994 13:42:08 -0400 Boy, there's nothing like reading your own mail! The example should show id1, xl2, rs4, a becoming Id1, Xl2, Rs4, A rather than the meaningless set of values I used. Sorry and Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Wed May 18 14:04:22 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <23989>; Wed, 18 May 1994 14:04:00 -0400 From: rob@plan9.research.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Wed, 18 May 1994 14:03:45 -0400 Message-Id: <94May18.140400edt.23989@hawkwind.utcs.utoronto.ca> the trick here is knowing about +#0 and -#0, which go to the end of the address. (-0 and +0 go to the end of the line). ,x/[a-zA-Z0-9]+/ -#0,+#1 | tr a-z A-Z From sam-fans-owner Thu May 19 10:18:59 1994 Received: from uucp1.UU.NET ([153.39.4.41]) by hawkwind.utcs.utoronto.ca with SMTP id <23989>; Thu, 19 May 1994 10:18:14 -0400 Received: from rexago8.UUCP by uucp1.UU.NET with UUCP (5.61/UUNET-uucp-primary) id AA03984; Thu, 19 May 94 09:45:38 -0400 Received: by summitis.com (smail2.5) id AA04509; 19 May 94 09:40:33 EDT (Thu) Received: from summitis.com by rserv1.YYY; Thu, 19 May 1994 09:39 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA67525; Thu, 19 May 1994 09:39:53 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA19795; Thu, 19 May 1994 09:39:52 -0400 From: hc05@summitis.com Message-Id: <9405191339.AA19795@cheetah> Subject: Re: First character of selected space To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 707 Date: Thu, 19 May 1994 10:18:05 -0400 Forwarded message: >the trick here is knowing about +#0 and -#0, which go to the >end of the address. (-0 and +0 go to the end of the line). > >,x/[A-ZA-Z0-9]+/ -#0,+#1 | tr A-Z A-Z I tried this but did not get good results. I found that the whole word was being capitalized, not just the first letter. Am I missing something? Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Thu May 19 10:46:49 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <23990>; Thu, 19 May 1994 10:46:27 -0400 From: rob@plan9.research.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 19 May 1994 10:46:00 -0400 Message-Id: <94May19.104627edt.23990@hawkwind.utcs.utoronto.ca> (whoops; sent that to 9fans (plan 9 mailing list) by mistake. i shouldn't send mail before noon.) yes, i made a mistake transcribing the command. the comma should be a semicolon. how you got all capital letters in your version, though, i don't understand. ,x/[a-zA-Z0-9_]+/ -#0;+#1 | tr a-z A-Z From sam-fans-owner Thu May 19 10:59:15 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <23991>; Thu, 19 May 1994 10:58:52 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Thu, 19 May 1994 15:57:57 +0100 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA18151; Thu, 19 May 1994 16:01:24 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA01763; Thu, 19 May 1994 15:55:45 +0000 Date: Thu, 19 May 1994 11:55:45 -0400 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9405191455.AA01763@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: capitalisation X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 478 > yes, i made a mistake transcribing the command. the comma > should be a semicolon. how you got all capital letters in your > version, though, i don't understand. well, that's what happens. I 'new' a window, type 'this is a test line\n' into it, and then do ",x/[a-z]+/-#0,+#1|tr '[a-z]' '[A-Z]'", and i get a whole line capitalised ('scuse the SVR4 tr...) > > ,x/[a-zA-Z0-9_]+/ -#0;+#1 | tr a-z A-Z > now, this *does* work, and definitely worth remembering.... steve From sam-fans-owner Thu May 19 12:49:00 1994 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.utoronto.ca with SMTP id <23992>; Thu, 19 May 1994 12:48:23 -0400 Via: uk.ac.edinburgh.epcfta; Thu, 19 May 1994 16:25:09 +0100 From: Andrew Higham Date: Thu, 19 May 1994 11:24:16 -0400 Message-Id: <18985.9405191524@epcfta.ed.ac.uk> Subject: Re: capitalisation To: steve@cegelec-projects-ltd.co.uk (Steve_Kilbane), sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: Steve_Kilbane's message of Thu, 19 May 1994 11:55:45 -0400 Organisation: Edinburgh Portable Compilers Ltd. Phone: +44 31 225 6262 > > > > ,x/[a-zA-Z0-9_]+/ -#0;+#1 | tr a-z A-Z > > > > now, this *does* work, and definitely worth remembering.... actually it only works for a and z. For all letters try... ,x/[a-zA-Z0-9_]+/ -#0;+#1 | tr '[a-z]' '[A-Z]' --------------------------------------------------------------------------- Andrew Higham Edinburgh Portable Compilers, 17 Alva St., Edinburgh, EH2 4PH, Scotland, UK andrew@epc.ed.ac.uk phone: +44 31 225 6262 fax: +44 31 225 6644 --------------------------------------------------------------------------- From sam-fans-owner Thu May 19 12:57:26 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <23993>; Thu, 19 May 1994 12:57:06 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Thu, 19 May 1994 17:56:29 +0100 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA20022; Thu, 19 May 1994 18:00:03 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA02674; Thu, 19 May 1994 17:54:25 +0000 Date: Thu, 19 May 1994 13:54:25 -0400 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9405191654.AA02674@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: capitalisation X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 329 > actually it only works for a and z. For all letters try... > > ,x/[a-zA-Z0-9_]+/ -#0;+#1 | tr '[a-z]' '[A-Z]' this depends on which version of unix you're using (or whether you're using plan 9, i guess - does it have tr?) - but that's just details in tr itself; the important thing is the sam command that feeds it. steve From sam-fans-owner Thu May 19 13:05:22 1994 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.utoronto.ca with SMTP id <23994>; Thu, 19 May 1994 13:04:56 -0400 From: pete@minster.york.ac.uk Date: Thu, 19 May 1994 13:57:17 -0400 Message-ID: To: andrew@epcfta.edinburgh.ac.uk, sam-fans@hawkwind.utcs.toronto.edu, steve@cegelecproj.co.uk Subject: Re: capitalisation > actually it only works for a and z. For all letters try... Depends upon how broken your version of `tr' is. Sensible ones recognise a-z as a character class.... daft ones don't. pete From sam-fans-owner Mon May 23 10:34:31 1994 Received: from zag.netlab.london.sco.com ([150.126.4.77]) by hawkwind.utcs.utoronto.ca with SMTP id <23989>; Mon, 23 May 1994 10:33:02 -0400 Received: from zag.netlab.london.sco.com by zag.netlab.london.sco.com id aa10902; 23 May 94 15:30 BST To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam for att730 X-Face: "?v.huY]?B[a4C|xid!Tx8TpwOQe6]C(I}h8Vo1z6'9soM_Xvq2f3u::[F~rW>GWj6; IfU,10H;B&1JDE/H8?``q4XH4~!\_z{n3RDmkC;9d!Yx3O7n?9,[CE;TWB!F8.e5fc0 dJXikU'v1qFVTfptB7xe$y*t#jx4`I44n,ypMQg@.|Z^ycJ:G]{dR~E}_.T1^shwC%T 4eRGVu%h+J7lBzb>m20==Q*OPAf^~@6Lj^)rI9Tb*m*L}}HC~{>/__Od\I=[|aP6s}B %BhqtE-9uGJ0J3jchjcyJz5fW[i0$RfPv7Zp=!a+0pR MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10896.769703408.1@sco.com> Date: Mon, 23 May 1994 10:30:09 -0400 From: Dave Edmondson Message-ID: <9405231530.aa10902@zag.netlab.london.sco.com> i have an att730mtg, and i'd like to get hold of the bits necessary to run sam on it. i have sam running under X, so i guess i need a samterm and samterm.m which apply to the 730. at the moment i don't have a 68k devkit for the 730, so binaries for the .m part would be almost essential. any suggestions ? dave. From sam-fans-owner Tue May 31 14:49:42 1994 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.utoronto.ca with SMTP id <24008>; Tue, 31 May 1994 14:44:08 -0400 Received: by mail.swip.net (8.6.8/2.01) id UAA29098; Tue, 31 May 1994 20:43:48 +0200 Received: from walker.UUCP by enea.se (4.1/SMI-4.0) id AA17196; Tue, 31 May 94 19:40:14 +0200 Received: from walker.UUCP by pallas.enea.se (4.1/SMI-4.0) id AA00926; Tue, 31 May 94 19:34:05 +0200 Received: from dragos.enea.se by ose.enea.se (5.0/SMI-SVR4) id AA15508; Tue, 31 May 1994 19:43:08 --100 Received: by dragos.enea.se (4.1/SMI-4.1) id AA28275; Tue, 31 May 94 19:37:54 +0200 Date: Tue, 31 May 1994 13:37:54 -0400 From: bekl@dragos.ose.enea.se (Bengt Kleberg) Message-Id: <9405311737.AA28275@dragos.enea.se> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Greetings, Content-Length: 344 Since the beginning of this year I have been a happy 9term user. Very nice interface and no crashes. With the advent of Solaris2 on our network I find that sam/samterm provided Makefiles for solaris2, but, alas, 9term only has sun (as in sunos4). Does anybody know what Makefile that would be 'best' to use for Solaris2? Best Wishes, Bengt From sam-fans-owner Wed Jun 1 22:33:05 1994 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24014>; Wed, 1 Jun 1994 22:31:27 -0400 Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from matty for sam-fans@hawkwind.utcs.toronto.edu) with MHSnet; Thu, 02 Jun 1994 12:31:08 +1000 To: bekl@dragos.ose.enea.se Message-ID: <19940602122515.21383.frobozz@staff.cs.su.oz.au> From: matty@cs.su.oz.au (James Matthew Farrow) Date: Wed, 1 Jun 1994 22:25:15 -0400 Organisation: Basser Dept of Computer Science, Sydney University, Australia X-Name: James Matthew Farrow X-Face: B>D@!+;vE|ETmR!+pig${%L"["]tFj(v@m_F%@}o2q03)'6{jCds#> #sO^kokjP\LcmO}sB(,^SzSSq@v0x~UXrC \GJ3=i7FUOBLO}]EIuK(K4}LMg,=R7(#B3G&<"r1U~mct?!;M\z:lV To: matty@cs.su.oz.au Subject: 9term for Solaris2 Content-Length: 349 Greetings, Since the beginning of this year I have been a happy 9term user. Very nice interface and no crashes. With the advent of Solaris2 on our network I find that sam/samterm provided Makefiles for solaris2, but, alas, 9term only has sun (as in sunos4). Do you know what Makefile that would be 'best' to use for Solaris2? Best Wishes, Bengt I've done a bit more work on 9term. There is a distribution which some might like to look at available as ftp://ftp.cs.su.oz.au/matty/unicode/9term.1.5.1.tar.Z This includes a Makefile for Solaris as well as some improved handling of interrupts and echo/noecho modes. If anyone can tell me a way of getting read notification from inside a stream to a user program I would be grateful. (John Mackin suggested poking the bits in the kernel but I'm loathe to try that ;-). The documentation we have with Solaris is not that helpful. It seems to hit that it's possible but it also implies that it's impossible. Matty. -- James Matthew Farrow | "For in that moment I beheld the ruin matty@cs.su.OZ.AU | of my existence. My world fell dark Basser Department of Computer Science | and my life became a shallow dream. Sydney University - FAX: +61 2 692 3838 | `Odi et amo. Excrucior.'" - Tlindah From sam-fans-owner Thu Jun 2 10:58:22 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24015>; Thu, 2 Jun 1994 10:57:07 -0400 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id KAA27933 for ; Thu, 2 Jun 1994 10:56:46 -0400 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id KAA06236 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 2 Jun 1994 10:56:51 -0400 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199406021456.KAA06236@penfold.cc.gatech.edu> Date: Thu, 2 Jun 1994 10:56:50 -0400 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term fix for sunos 4.1.3 This is what I had to do to compile 9term.1.5.1 on SunOS 4.1.3. Arnold --------------- ; diff -c pty.c.orig pty.c *** pty.c.orig Thu Jun 2 01:35:31 1994 --- pty.c Thu Jun 2 10:41:53 1994 *************** *** 414,420 **** --- 414,422 ---- void flushstream(void) { + #ifdef SOLARIS ioctl(comm_fd, I_FLUSH, FLUSHW); + #endif } void From sam-fans-owner Thu Jun 2 11:17:36 1994 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.utoronto.ca with SMTP id <24016>; Thu, 2 Jun 1994 11:17:15 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA10591; Thu, 2 Jun 94 11:17:07 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA15337; Thu, 2 Jun 94 11:15:30 -0400 Date: Thu, 2 Jun 1994 11:15:30 -0400 From: rsalz@osf.org Message-Id: <9406021515.AA15337@sulphur.osf.org> To: <@hawkwind.utcs.utoronto.ca:sam-fans-owner@hawkwind.utcs.toronto.edu>, sam-fans@hawkwind.utcs.toronto.edu Subject: 9term fix for HP This is what I had to do to get 9term to comiple on the HP. I think it subsumes arnold's fix. *** 9term/Make.hpux.save Thu Jun 2 08:50:14 1994 --- 9term/Make.hpux Thu Jun 2 08:50:26 1994 *************** *** 12,18 **** # Define BSDPTYS for BSD-style pty support # Define POSIXPTYS for POSIX ptys ! OS=-DHPUX -Aa -DPOSIXPTYS -DBSDPTYS -D_POSIX_SOURCE -DXLIB_ILLEGAL_ACCESS -D_INCLUDE_XOPEN_SOURCE -D_INCLUDE_HPUX_SOURCE # where we'll install it BINDIR=. --- 12,18 ---- # Define BSDPTYS for BSD-style pty support # Define POSIXPTYS for POSIX ptys ! OS=-DHPUX -Aa -DPOSIXPTYS -DBSDPTYS -D_POSIX_SOURCE -DXLIB_ILLEGAL_ACCESS -D_INCLUDE_XOPEN_SOURCE -D_INCLUDE_HPUX_SOURCE -DUSE_SYSCONF # where we'll install it BINDIR=. *** 9term/display.c.save Thu Jun 2 07:48:35 1994 --- 9term/display.c Thu Jun 2 07:50:39 1994 *************** *** 37,43 **** extern Display *_dpy; extern Widget _toplevel; ! static int ninewm; static Cursor whitearrow = { {0, 0}, {0xFF, 0xE0, 0xFF, 0xE0, 0xFF, 0xC0, 0xFF, 0x00, --- 37,43 ---- extern Display *_dpy; extern Widget _toplevel; ! int ninewm; static Cursor whitearrow = { {0, 0}, {0xFF, 0xE0, 0xFF, 0xE0, 0xFF, 0xC0, 0xFF, 0x00, *************** *** 64,72 **** {"+ut", "*utmp", XrmoptionNoArg, "false"}, {"-9", "*kbdMode", XrmoptionNoArg, "plan9"}, {"-unix", "*kbdMode", XrmoptionNoArg, "unix"}, ! {"-label", "*label", XrmoptionSepArg, (caddr_t)NULL}, ! {"-high", "*highwater", XrmoptionSepArg, (caddr_t)NULL}, ! {"-low", "*lowwater", XrmoptionSepArg, (caddr_t)NULL}, {"-9wm", "*9wm", XrmoptionNoArg, "true"}, {"-beep", "*beep", XrmoptionNoArg, "plan9 unix"}, {"-debug", "*debug", XrmoptionNoArg, "true"}, --- 64,72 ---- {"+ut", "*utmp", XrmoptionNoArg, "false"}, {"-9", "*kbdMode", XrmoptionNoArg, "plan9"}, {"-unix", "*kbdMode", XrmoptionNoArg, "unix"}, ! {"-label", "*label", XrmoptionSepArg, 0}, ! {"-high", "*highwater", XrmoptionSepArg, 0}, ! {"-low", "*lowwater", XrmoptionSepArg, 0}, {"-9wm", "*9wm", XrmoptionNoArg, "true"}, {"-beep", "*beep", XrmoptionNoArg, "plan9 unix"}, {"-debug", "*debug", XrmoptionNoArg, "true"}, *** 9term/pty.c.save Thu Jun 2 07:53:11 1994 --- 9term/pty.c Thu Jun 2 08:50:10 1994 *************** *** 60,65 **** --- 60,70 ---- # define V_WERAS VWERASE # define V_FLUSH VFLUSH #endif + #ifdef HPUX + # define V_START VSTART + # define V_STOP VSTOP + # define V_SUSP VSUSP + #endif #ifdef POSIXPTYS # include *************** *** 146,152 **** { "weras", 5, V_WERAS, ctrl('w'), ctrl('w') }, { "lnext", 5, VLNEXT, ctrl('v'), ctrl('v') }, #endif ! #ifndef IRIX { "flush", 5, V_FLUSH, ctrl('o'), ctrl('o') }, #endif #ifdef VQUOTE --- 151,157 ---- { "weras", 5, V_WERAS, ctrl('w'), ctrl('w') }, { "lnext", 5, VLNEXT, ctrl('v'), ctrl('v') }, #endif ! #ifdef V_FLUSH { "flush", 5, V_FLUSH, ctrl('o'), ctrl('o') }, #endif #ifdef VQUOTE *************** *** 414,420 **** --- 419,427 ---- void flushstream(void) { + #ifdef I_FLUSH ioctl(comm_fd, I_FLUSH, FLUSHW); + #endif } void *************** *** 573,579 **** */ slot = 0; while(read(fd, &utmp, sizeof(utmp)) == sizeof(utmp)) { ! if (!strncmp(ttyname, &utmp.ut_line, sizeof(utmp.ut_line))) { lseek(fd, -sizeof(utmp), 1); break; } --- 580,586 ---- */ slot = 0; while(read(fd, &utmp, sizeof(utmp)) == sizeof(utmp)) { ! if (!strncmp(ttyname, utmp.ut_line, sizeof(utmp.ut_line))) { lseek(fd, -sizeof(utmp), 1); break; } *************** *** 712,716 **** --- 719,731 ---- default: fprintf(stderr, "unknown %02x\n", e->data[0]); } + } + #endif + + #ifdef USE_SYSCONF + int + getdtablesize() + { + return sysconf(_SC_OPEN_MAX); } #endif *** /dev/null Thu Jun 2 09:19:00 1994 --- libtext/Make.hpux Thu Jun 2 08:47:27 1994 *************** *** 0 **** --- 1,38 ---- + # + # Prototype Sun Makefile for libtext + # + # Additionally, -D_POSIX_SOURCE (or its equivalent) may be specified + # if your compiler supports posix-compatible compilation + OS=-DHPUX -Aa -D_POSIX_SOURCE -DXLIB_ILLEGAL_ACCESS -D_INCLUDE_XOPEN_SOURCE -D_INCLUDE_HPUX_SOURCE + + # add -Iincludedir for any include directories that need to be searched + # for posix header files + INCS=-I. -I../include + + # add name of library orderer - use ":" if none exists + RANLIB=: + + # add name of library + AR=ar + + CFLAGS=-c $(OS) $(INCS) -D_LIBXG_EXTENSION + + LIB=libtext.a + + OBJ=click.o scroll.o text.o + + all: $(LIB) + + $(LIB): $(OBJ) + $(AR) rv $(LIB) $(OBJ) + $(RANLIB) $(LIB) + + clean: + rm -f *.o + + nuke: clean + rm -f $(LIB) + + install: $(LIB) + + $(OBJ): ../include/u.h ../include/libc.h ../include/libg.h ../include/frame.h ../include/text.h From sam-fans-owner Thu Jun 2 15:19:49 1994 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24018>; Thu, 2 Jun 1994 15:19:06 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <3032>; Thu, 2 Jun 1994 15:18:38 -0400 To: arnold@cc.gatech.edu (Arnold Robbins) cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term fix for sunos 4.1.3 In-reply-to: Your message of "Thu, 02 Jun 1994 10:56:50 EDT." <199406021456.KAA06236@penfold.cc.gatech.edu> Date: Thu, 2 Jun 1994 15:18:24 -0400 From: Scott Schwartz Message-Id: <94Jun2.151838edt.3032@groucho.cse.psu.edu> | This is what I had to do to compile 9term.1.5.1 on SunOS 4.1.3. An alternative fix is to #include inside the #ifdef SUNOS near the top. If you link with X11R6, you'll need to compile with -DXLIB_ILLEGAL_ACCESS since something pokes around inside the display structure, and they decided to make it opaque now. From sam-fans-owner Thu Jun 2 15:23:00 1994 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24019>; Thu, 2 Jun 1994 15:22:31 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <3029>; Thu, 2 Jun 1994 15:21:57 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term fix for sunos 4.1.3 In-reply-to: Your message of "Thu, 02 Jun 1994 10:56:50 EDT." <199406021456.KAA06236@penfold.cc.gatech.edu> Date: Thu, 2 Jun 1994 15:21:45 -0400 From: Scott Schwartz Message-Id: <94Jun2.152157edt.3029@groucho.cse.psu.edu> Another fix: diff -ur libtext/click.c libtext-/click.c --- libtext/click.c Sat Jun 5 23:30:14 1993 +++ libtext-/click.c Wed Nov 10 17:17:44 1993 @@ -4,12 +4,12 @@ #include #include -static Rune l1[] = { '{', '[', '(', '<', '\253', 0}; +static Rune l1[] = { '{', '[', '(', '<', 0253, 0}; static Rune l2[] = { '\n', 0}; static Rune l3[] = { '\'', '"', '`', 0}; Rune *left[]= { l1, l2, l3, 0}; -static Rune r1[] = {'}', ']', ')', '>', '\273', 0}; +static Rune r1[] = {'}', ']', ')', '>', 0273, 0}; static Rune r2[] = {'\n', 0}; static Rune r3[] = {'\'', '"', '`', 0}; Rune *right[]= { r1, r2, r3, 0}; From sam-fans-owner Fri Jun 3 04:53:49 1994 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by hawkwind.utcs.utoronto.ca with SMTP id <23991>; Fri, 3 Jun 1994 04:52:47 -0400 Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from matty for sam-fans@hawkwind.utcs.toronto.edu) with MHSnet; Fri, 03 Jun 1994 18:52:28 +1000 To: sam-fans@hawkwind.utcs.toronto.edu Message-ID: <19940603183848.10089.frobozz@staff.cs.su.oz.au> From: matty@cs.su.oz.au (James Matthew Farrow) Date: Fri, 3 Jun 1994 04:38:48 -0400 Organisation: Basser Dept of Computer Science, Sydney University, Australia X-Name: James Matthew Farrow X-Face: B>D@!+;vE|ETmR!+pig${%L"["]tFj(v@m_F%@}o2q03)'6{jCds#> #sO^kokjP\LcmO}sB(,^SzSSq@v0x~UXrC \GJ3=i7FUOBLO}]EIuK(K4}LMg,=R7(#B3G&<"r1U~mct?!;M\z:lV; Fri, 3 Jun 1994 05:01:14 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Fri, 3 Jun 1994 10:00:37 +0100 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA23006; Fri, 3 Jun 1994 10:04:19 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA10074; Fri, 3 Jun 1994 09:58:30 +0000 Date: Fri, 3 Jun 1994 05:58:30 -0400 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9406030858.AA10074@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9wm X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 458 matty writes: > There is also some code (hopefully never compiled) left from > experiments with the pckt module under Solaris and an aborted > experiment in talking with 9wm. Speaking of 9wm, I have no idea when > it will be released (David, are you listening?) but some people around > here seem to be using it with a modicum of success and enjoyment. [foam. gibber]. if it's not due for release, any chance of parole, or possibly a breakout? :-) steve From sam-fans-owner Fri Jun 3 10:49:42 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24015>; Fri, 3 Jun 1994 10:49:03 -0400 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id KAA05554 for ; Fri, 3 Jun 1994 10:48:41 -0400 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id KAA07077 for sam-fans@hawkwind.utcs.toronto.edu; Fri, 3 Jun 1994 10:48:47 -0400 Date: Fri, 3 Jun 1994 10:48:47 -0400 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199406031448.KAA07077@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: unicode smileys I made this mod to my copy of libXg a while back. I sent it to bobf, but I thought the list might like it too. *** latin1.c.orig Tue Sep 28 11:31:50 1993 --- latin1.c Thu Feb 3 12:45:03 1994 *************** *** 208,213 **** --- 208,216 ---- 0x22a8, 'T','u', /* valid */ 0x22c4, 'l','z', /* lozenge */ 0x22ef, 'e','l', /* ellipses */ + 0x2639, ':','(', /* saddy */ + 0x263a, ':',')', /* white-face smiley */ + 0x263b, ';',')', /* dark-face smiley */ 0, 0, }; From sam-fans-owner Tue Jul 5 17:00:48 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24033>; Tue, 5 Jul 1994 16:58:33 -0400 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id QAA14191 for ; Tue, 5 Jul 1994 16:58:22 -0400 Received: from localhost (arnold@localhost) by penfold.cc.gatech.edu (8.6.4/8.6.4) id QAA00131 for sam-fans@hawkwind.utcs.toronto.edu; Tue, 5 Jul 1994 16:58:18 -0400 Date: Tue, 5 Jul 1994 16:58:18 -0400 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199407052058.QAA00131@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: postscript for unicode characters, and tex? Is it possible, without undue jumping through hoops, to get the equivalent of the unicode smileys into and through TeX, and into postscript? This is on a Unix system, but I'd like to be able to discuss using Unicode, and provide a demo of a regexp character class of all three smileys. In particular, I'll be using the GNU projects Texinfo macros, not LaTeX. Thanks! Arnold P.S. Is it "smileys" or "smilies"? ☺ From sam-fans-owner Mon Jul 25 13:16:00 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.utoronto.ca with SMTP id <24060>; Mon, 25 Jul 1994 13:13:37 -0400 Received: from hassle.Stanford.EDU (hassle.Stanford.EDU [36.59.0.161]) by drizzle.Stanford.EDU (8.6.4/8.6.4) with ESMTP id KAA13221 for ; Mon, 25 Jul 1994 10:13:04 -0700 From: Castor Fu Received: (castor@localhost) by hassle.Stanford.EDU (8.6.8/8.6.4) id KAA06147 for sam-fans@hawkwind.utcs.toronto.edu; Mon, 25 Jul 1994 10:13:55 -0700 Message-Id: <199407251713.KAA06147@hassle.Stanford.EDU> Subject: sam on 24 bit X displays? To: sam-fans@hawkwind.utcs.toronto.edu Date: Mon, 25 Jul 1994 13:13:55 -0400 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 213 Has anyone made the patches to get samterm running correctly on an X display where the default visual is 24 bits? I have a hack, but it's not very pretty, and I"m not sure it will work in all cases. -castor From sam-fans-owner Wed Aug 17 10:45:49 1994 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24088>; Wed, 17 Aug 1994 10:43:18 -0400 Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxdiw13886; Wed, 17 Aug 1994 10:42:59 -0400 Received: from rexago8.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Wed, 17 Aug 1994 10:43:01 -0400 Received: by summitis.com (smail2.5) id AA22308; 17 Aug 94 09:01:37 EDT (Wed) Received: from summitis.com by rserv1.summitis.com; Wed, 17 Aug 1994 09:00 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA86628; Wed, 17 Aug 1994 09:02:33 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA21593; Wed, 17 Aug 1994 09:02:31 -0400 From: hc05@summitis.com Message-Id: <9408171302.AA21593@cheetah> Subject: samx2 and sam 3/12/93 To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 815 Date: Wed, 17 Aug 1994 10:43:08 -0400 I have been happily using sam with the samx2 extensions. One problem, though, keeps me from recommending it to others. It dies periodically, scaring off the fainthearted. I have the October 1993 version of sam, which the patches don't support, and with good reason since they produce 4 reject files in libXg. My question is can I get the 3/12/93 version of sam anywhere, or has anyone reconciled samx2 with the October version of sam? Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Thu Aug 18 01:45:47 1994 Received: from ugw.utcc.utoronto.ca ([128.100.102.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24089>; Thu, 18 Aug 1994 01:45:14 -0400 Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by ugw.utcc.utoronto.ca with SMTP id <9063>; Thu, 18 Aug 1994 01:45:01 -0400 Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A7621GAC@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 6912; Thu, 18 Aug 1994 07:43:56 +0100 Date: Thu, 18 Aug 1994 02:40:34 -0400 From: Werner Lemberg Subject: Re: samx2 and sam 3/12/93 To: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: Your message of Wed, 17 Aug 1994 10:43:08 -0400 Message-Id: <94Aug18.014501edt.9063@ugw.utcc.utoronto.ca> What is samx2 and where can I find it ? Another question: Has anybody ported sam(term) to Linux? After some tries I succeeded in porting, but I'm not familiar with UNIX programming, and indeed I really don't know exactly what I've done :-) Werner From sam-fans-owner Thu Aug 18 05:33:02 1994 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.utoronto.ca with SMTP id <24089>; Thu, 18 Aug 1994 05:32:03 -0400 Message-ID: X-Sender: pete@minster.york.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Aug 1994 05:21:39 -0400 To: Werner Lemberg From: pete@minster.york.ac.uk (Pete Fenelon) Subject: Re: samx2 and sam 3/12/93 Cc: sam-fans@hawkwind.utcs.toronto.edu X-Mailer: > >What is samx2 and where can I find it ? Samx2 is a set of patches which give some keyboard customisation facilities to sam. The author is at uiuc.edu, but I can't remember the ftp site where the patch lives; if the worst comes to the worst I could mail you a copy. > >Another question: Has anybody ported sam(term) to Linux? After some tries >I succeeded in porting, but I'm not familiar with UNIX programming, and >indeed I really don't know exactly what I've done :-) Yes -- I have done a working port, but there's still one minor problem with named pipes that means I have to start sam up in a slightly nonstandard way! I started from the defines for IRIX -- the Silicon Graphics OS is one of the closest to POSIX and therefore Linux that I've ever come across -- and fixed it on that basis. I think the startup bug is probably due to the interaction of some of the patches I have in my sam; I'll investigate further. Basically, I have to chuck a carriage return down the named pipe before Sam will do anything... however, from then on it's perfect! pete -- Peter Fenelon - Research Associate - High Integrity Systems Engineering Group, Dept. of Computer Science, University of York, York, YO1 5DD (+44/0)904 433388 From sam-fans-owner Thu Aug 18 06:36:22 1994 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24089>; Thu, 18 Aug 1994 06:34:56 -0400 Received: from faui01.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA27362 (5.65c-6/7.3w-FAU); Thu, 18 Aug 1994 12:34:45 +0200 Received: from faui04d.informatik.uni-erlangen.de by cip.informatik.uni-erlangen.de with SMTP; id AA07306 (5.65c-6/7.3m-FAU); Thu, 18 Aug 1994 12:34:40 +0200 From: "Markus Friedl (CIP 92)" Message-Id: <199408181034.AA07306@faui01.informatik.uni-erlangen.de> Subject: Re: samx2 and sam 3/12/93 To: pete@minster.york.ac.uk (Pete Fenelon) Date: Thu, 18 Aug 1994 06:34:38 -0400 Cc: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) In-Reply-To: from "Pete Fenelon" at Aug 18, 94 05:21:39 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1135 > >Another question: Has anybody ported sam(term) to Linux? After some tries > >I succeeded in porting, but I'm not familiar with UNIX programming, and > >indeed I really don't know exactly what I've done :-) > > Yes -- I have done a working port, but there's still one minor problem with > named pipes that means I have to start sam up in a slightly nonstandard way! > I started from the defines for IRIX -- the Silicon Graphics OS is one of the > closest to POSIX and therefore Linux that I've ever come across -- and fixed > it on that basis. > > I think the startup bug is probably due to the interaction of some of the > patches I have in my sam; I'll investigate further. Basically, I have to > chuck a carriage return down the named pipe before Sam will do anything... > however, from then on it's perfect! which version of sam are you using ?? i tried the october-93 version (4.1) (w/o patches) and started from the Solaris Makefiles. all works fine. cu --markus ps: BTW: you may ftp my makefiles from ftp://131.188.190.131/pub/unix/sam/Make.linux.shar -- Markus Friedl msfriedl@cip.informatik.uni-erlangen.de From sam-fans-owner Thu Aug 18 09:14:09 1994 Received: from louie.udel.edu ([128.175.1.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24089>; Thu, 18 Aug 1994 09:13:31 -0400 Received: from sol.cis.udel.edu by louie.udel.edu id ab24528; 18 Aug 94 9:04 EDT Received: from louie.udel.edu by sol.cis.udel.edu id aa21177; 18 Aug 94 13:02 GMT Received: from sol.cis.udel.edu by hercules.cis.udel.edu id aa20494; 18 Aug 94 13:01 GMT To: "Markus Friedl (CIP 92)" cc: Pete Fenelon , Sam mailing list Subject: Re: samx2 and sam 3/12/93 In-reply-to: Your message of Thu, 18 Aug 1994 06:34:38 -0400. <199408181034.AA07306@faui01.informatik.uni-erlangen.de> From: "Mark C. Chu-Carroll" Date: Thu, 18 Aug 1994 09:01:07 -0400 Sender: carroll@louie.udel.edu Message-ID: <9408181301.aa20494@hercules.cis.udel.edu> I also compiled Sam for Linux starting from the Solaris makefiles. Even with the samx2 extensions, it compiled cleanly, and works like a charm. From sam-fans-owner Thu Aug 18 13:49:14 1994 Received: from flaubert.bellcore.com ([192.4.7.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24090>; Thu, 18 Aug 1994 13:47:29 -0400 Received: from localhost.bellcore.com (localhost.bellcore.com [127.0.0.1]) by flaubert.bellcore.com (8.6.4/8.6.4) with SMTP id NAA19455; Thu, 18 Aug 1994 13:46:36 -0400 Message-Id: <199408181746.NAA19455@flaubert.bellcore.com> X-Authentication-Warning: flaubert.bellcore.com: Host localhost.bellcore.com didn't use HELO protocol To: Werner Lemberg cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: samx2 and sam 3/12/93 In-reply-to: Your message of "Thu, 18 Aug 1994 02:40:34 EDT." <94Aug18.014501edt.9063@ugw.utcc.utoronto.ca> Date: Thu, 18 Aug 1994 13:46:24 -0400 From: Norman Ramsey > Another question: Has anybody ported sam(term) to Linux? After some tries > I succeeded in porting, but I'm not familiar with UNIX programming, and > indeed I really don't know exactly what I've done :-) I had no trouble compiling the current ATT&T sam distribution for linux. I used the default makefiles with -DLINUX -ansi -D_POSIX_SOURCE. I didn't have to touch and code. From sam-fans-owner Thu Sep 8 01:24:37 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.utoronto.ca with SMTP id <24118>; Thu, 8 Sep 1994 01:23:07 -0400 Received: from hassle.Stanford.EDU (hassle.Stanford.EDU [36.59.0.161]) by drizzle.Stanford.EDU (8.6.8/8.6.4) with ESMTP id WAA03301 for ; Wed, 7 Sep 1994 22:21:21 -0700 From: Castor Fu Received: (castor@localhost) by hassle.Stanford.EDU (8.6.8/8.6.4) id WAA15341 for sam-fans@hawkwind.utcs.toronto.edu; Wed, 7 Sep 1994 22:23:56 -0700 Message-Id: <199409080523.WAA15341@hassle.Stanford.EDU> Subject: sam and tiling To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 8 Sep 1994 01:23:56 -0400 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 828 Do people like the window creation mechanism on sam? I found that more often then not, I didn't really want to choose a particular window size, but simply wanted to put one somewhere. However, the current behavior with the single click didn't seem to quite agree with me. Taking a cue from Oberon and acme, I decided to patch getr in samterm/main.c by adding the following in the appropriate place: modifying the code like so: if (p.y <= r.min.y) rp->max.y = r.min.y; else if (p.y >= r.max.y) rp->min.y = r.max.y; else { rp->min.y = r.min.y; rp->max.y = r.max.y; } [and similarly for the x coords]. This allows the command window to define 8 other sectors, which don't overlap. I've been working with it for a few hours now, and I feel the screen real estate is better utilized. -castor From sam-fans-owner Thu Sep 15 11:58:10 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.utoronto.ca with SMTP id <24127>; Thu, 15 Sep 1994 11:56:00 -0400 Received: from sni.ca by relay1.UU.NET with SMTP id QQxhmd22271; Thu, 15 Sep 1994 11:55:17 -0400 Received: from silver.sni.ca by sni.ca (5.61/1.34.0) id AA14913; Thu, 15 Sep 94 08:54:24 -0700 Received: by silver.sni.CA (5.61/smail2.5/02-09-92) id AA24979; Thu, 15 Sep 94 11:54:20 -0400 From: "Ozan Yigit" Message-Id: <9409151554.AA24979@silver.sni.CA> To: sam-fans@hawkwind.utcs.utoronto.ca Subject: (click) undo Date: Thu, 15 Sep 1994 03:54:19 -0400 does anyone see any problems with adding Tundo into sam message protocol so that samterm can have an undo item on the ops menu? [i would like to think that this is not creeping feeturism, but rather making an appearently very common (!) sam operation somewhat easier to get at. :-] oz --- choose your rut carefully: you will be in it | electric: oz@sni.ca for the next seven miles. -SF trail signpost | [416] 449 9449 x154 From sam-fans-owner Fri Sep 16 00:55:42 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <24130>; Fri, 16 Sep 1994 00:30:06 -0400 From: rob@plan9.research.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Fri, 16 Sep 1994 00:29:35 -0400 Subject: Re: (click) undo Message-Id: <94Sep16.003006edt.24130@hawkwind.utcs.utoronto.ca> don't dissimulate: of course it's creeping featurism. that's not a good enough reason to reject doing it, however. there are better ones. the frequency of using undo when not already typing commands anyway is not high enough to justify making the button 2 menu larger, at least in my experience. i'm confused by your 'apparently very common' remark. perhaps you undo nearly as frequently as you do the other operations on button 2. that strikes me as odd. in any case, putting something on the menu just because it's common begs another question: is there something even more common that should be there? global substitute? indent? reverse indent? go to matching brace? pipe through formatter? and so on. better to leave the worms in the can. -rob From sam-fans-owner Sun Sep 18 23:42:07 1994 Received: from nexus.yorku.ca ([130.63.9.66]) by hawkwind.utcs.utoronto.ca with SMTP id <24130>; Sun, 18 Sep 1994 23:37:43 -0400 Received: by nexus.yorku.ca id <9224>; Sun, 18 Sep 1994 23:37:33 -0400 From: "ozan s. yigit" To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: (click) undo Message-Id: <94Sep18.233733edt.9224@nexus.yorku.ca> Date: Sun, 18 Sep 1994 23:37:22 -0400 indeed, i undo with some frequency, and a good portion of those undoes are necessiated outside the sam window, which means going back and forth between the sam window and the current window. i cannot however use my own odd editing activities as a basis good design, and i also think that there may be more than one design issue involved here. i still wonder what other sam-fans think. what is the typical undo activity of an average sam user? on a related topic: undo is also omitted from the protocol, which of course reflects the needs of the current samterm. a more general protocol would probably include it. oz From sam-fans-owner Mon Sep 19 03:32:25 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <24130>; Mon, 19 Sep 1994 03:31:49 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Mon, 19 Sep 1994 08:30:51 +0100 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA07937; Mon, 19 Sep 1994 08:34:51 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA07914; Mon, 19 Sep 1994 08:27:43 +0000 Date: Mon, 19 Sep 1994 04:27:43 -0400 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9409190727.AA07914@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: (click) undo X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 1575 > indeed, i undo with some frequency, and a good portion of those undoes > are necessiated outside the sam window, which means going back and forth > between the sam window and the current window. I'm not sure what you mean by this - in my experience, undo is done in the following circumstances: - as part of a cmd-u-cmd-u sequence, as i try to get the cmd *just* right. - in a long sequence of u,u,u,u... as i decide that what i've done for the last ten minutes is the wrong tack - just once, because i'm forgotten to change the focus before typing. I don't see that there's a great need for repetition that justifies changing both menu and protocol. The nearest case I can think of is application of the second case (lots of undos), where it's necessary to scroll the target window to see how much of the sequence you've unwound. However, the fault here is in samterm - it should scroll to display dot after an undo. 'Course, that's another can of worms, because samterm doesn't know it's an undo... > i cannot however use my own > odd editing activities as a basis good design, and i also think that there > may be more than one design issue involved here. i still wonder what other > sam-fans think. as i've mentioned before, I think the command language is lacking in the areas of snarfing, cutting and pasting - i've tried to emulate them with copies to a scratch window, but i almost always run up against "?addresses out of order" (or whatever it is). I don't know whether there's a solid reason for their absence, or just original preference. rob? steve From sam-fans-owner Mon Sep 19 04:35:26 1994 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24130>; Mon, 19 Sep 1994 04:34:52 -0400 Via: uk.ac.edinburgh.epcfta; Mon, 19 Sep 1994 09:34:44 +0100 From: Andrew Higham Date: Mon, 19 Sep 1994 04:31:53 -0400 Message-Id: <29881.9409190831@epcfta.ed.ac.uk> Subject: Re: (click) undo To: Steve_Kilbane , sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: Steve_Kilbane's message of Mon, 19 Sep 1994 04:27:43 -0400 Organisation: Edinburgh Portable Compilers Ltd. Phone: +44 31 225 6262 > I'm not sure what you mean by this - in my experience, undo is done in the > following circumstances: > - as part of a cmd-u-cmd-u sequence, as i try to get the cmd *just* > right. > - in a long sequence of u,u,u,u... as i decide that what i've done for > the last ten minutes is the wrong tack > - just once, because i'm forgotten to change the focus before typing. I find cut-cut-"oh dear"-undo-undo quite common as well, which is when undo on the menu would be useful. --------------------------------------------------------------------------- Andrew Higham Edinburgh Portable Compilers, 17 Alva St., Edinburgh, EH2 4PH, Scotland, UK andrew@epc.ed.ac.uk phone: +44 31 225 6262 fax: +44 31 225 6644 --------------------------------------------------------------------------- From sam-fans-owner Mon Sep 19 05:39:12 1994 Received: from cheviot.ncl.ac.uk ([128.240.2.10]) by hawkwind.utcs.utoronto.ca with SMTP id <24130>; Mon, 19 Sep 1994 05:38:47 -0400 Received: from ncl.bygate (bygate.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Mon, 19 Sep 1994 10:38:35 +0100 From: Gerry.Tomlinson@newcastle.ac.uk Message-Id: Subject: Re: (click) undo To: sam-fans@hawkwind.utcs.toronto.edu Date: Mon, 19 Sep 1994 05:38:28 -0400 In-Reply-To: <29881.9409190831@epcfta.ed.ac.uk> from "Andrew Higham" at Sep 19, 94 04:31:53 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1301 > > > I'm not sure what you mean by this - in my experience, undo is done in the > > following circumstances: > > - as part of a cmd-u-cmd-u sequence, as i try to get the cmd *just* > > right. > > - in a long sequence of u,u,u,u... as i decide that what i've done for > > the last ten minutes is the wrong tack > > - just once, because i'm forgotten to change the focus before typing. > and you can do each of a long sequence with a single mouse click once you've selected the "u". i must say that running sam under X11, i've found it much easier to use since: a) using 9term - which means i'm using the same input model most of the time when entering commands - eg. previously i found it hard to get the hang of the `output point' in the sam command window, now it seems perfectly natural. b) adding the patch which gives "mouse-to-type" - so it matches my window manager and other windowing applications. previously i frequently typed in the "wrong" window requiring a subsequent "undo". i also now find it less irksome going to the command window for a single command, gerry --- Gerry.Tomlinson@newcastle.ac.uk Department of Computing Science, University of Newcastle, Tel: +44 191 222 8139 Newcastle upon Tyne, NE1 7RU, United Kingdom. Fax: +44 191 222 8232 From sam-fans-owner Thu Sep 29 04:54:31 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <24136>; Thu, 29 Sep 1994 04:53:04 -0400 Received: from cegelecproj.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Thu, 29 Sep 1994 09:52:39 +0100 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA09301; Thu, 29 Sep 1994 09:57:13 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA04787; Thu, 29 Sep 1994 09:49:58 +0000 Date: Thu, 29 Sep 1994 05:49:58 -0400 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9409290849.AA04787@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam.ps X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 163 I tried viewing the sam paper with ghostview yesterday, and it barfed. I'm running ghostview 1.5, which ghostscript 2.6.1. Any ideas why this is happening? Steve From sam-fans-owner Mon Oct 3 20:20:00 1994 Received: from cooper.edu ([199.98.16.5]) by hawkwind.utcs.utoronto.ca with SMTP id <24141>; Mon, 3 Oct 1994 20:16:50 -0400 From: To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam archives on www Content-Length: 329 Message-Id: <94Oct3.201650edt.24141@hawkwind.utcs.utoronto.ca> Date: Mon, 3 Oct 1994 20:15:19 -0400 Mon Oct 3 19:59:49 EDT 1994 the sam and rc mail archives can ne accessed at URL: http://cooper.edu:9000/~rp/plan9/plan9-info.html from here, you can go to the appropiate lists. PS this machine is officially up during the following hours - M-F 8:45 to 22:00 EST Sat 13:00 to 18:00 EST Sun 15:00 to 21:00 EST micro From sam-fans-owner Mon Oct 31 11:06:29 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <24182>; Mon, 31 Oct 1994 10:54:28 -0500 Received: from cegelecproj.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Mon, 31 Oct 1994 15:42:23 +0000 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA15652; Mon, 31 Oct 1994 15:47:15 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA24660; Mon, 31 Oct 1994 15:39:29 +0000 Date: Mon, 31 Oct 1994 10:39:29 -0500 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9410311539.AA24660@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term and shells X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 244 Just out of curiosity, does everyone who uses 9term use either rc or es as their shell, or do some people use the more baroque shells? It just seems to me that 9term's mode of interaction would discourage people who liked such shells... steve From sam-fans-owner Mon Oct 31 11:36:59 1994 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.utoronto.ca with SMTP id <24182>; Mon, 31 Oct 1994 11:36:11 -0500 From: pete@minster.york.ac.uk Date: Mon, 31 Oct 1994 11:16:16 -0500 Message-ID: To: sam-fans@hawkwind.utcs.toronto.edu, steve@cegelecproj.co.uk Subject: Re: 9term and shells rc -- on the basis that it's the only shell I use in _any_ Unix environment if at all possible! The only other shell that would really make sense in a 9term would be the Bourne shell; I can't see {t}csh, bash or [kz]sh being worthwhile under 9term as it doesn't provide the sort of terminal emulation they want for all their fancy completion/editing facilities. (incidentally, has anyone got a _good_ port of 9term to Linux? -- I did a DIY one which gets very confused occasionally...) pete From sam-fans-owner Mon Nov 7 16:49:05 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.utoronto.ca with SMTP id <23982>; Mon, 7 Nov 1994 16:42:45 -0500 Received: from hassle.Stanford.EDU (hassle.Stanford.EDU [36.59.0.161]) by drizzle.Stanford.EDU (8.6.8/8.6.4) with ESMTP id NAA01925 for ; Mon, 7 Nov 1994 13:42:17 -0800 From: Castor Fu Received: (castor@localhost) by hassle.Stanford.EDU (8.6.8/8.6.4) id NAA01283 for sam-fans@hawkwind.utcs.toronto.edu; Mon, 7 Nov 1994 13:44:32 -0800 Message-Id: <199411072144.NAA01283@hassle.Stanford.EDU> Subject: Japanese input and Sam To: sam-fans@hawkwind.utcs.toronto.edu Date: Mon, 7 Nov 1994 16:44:31 -0500 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 465 Has anyone hacked japanese input methods into 'sam'? If I were to do this, what I would probably do is mash a tcl interpreter into libXg and handle the input translations in tcl. Then the code in 'latin1.c' would be moved into an area which could be edited without recompiling sam. I suppose purists would feel this was sacreligious, but when using a large character set like Unicode, I think having hard coded tables like sam uses is sort of silly. -castor From sam-fans-owner Mon Nov 7 17:54:26 1994 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <23982>; Mon, 7 Nov 1994 17:53:35 -0500 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12686>; Mon, 7 Nov 1994 17:53:08 -0500 To: Castor Fu cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Japanese input and Sam In-reply-to: Your message of "Mon, 07 Nov 1994 16:44:31 EST." <199411072144.NAA01283@hassle.Stanford.EDU> Date: Mon, 7 Nov 1994 17:53:04 -0500 From: Scott Schwartz Message-Id: <94Nov7.175308est.12686@galapagos.cse.psu.edu> | Has anyone hacked japanese input methods into 'sam'? Since libXg already uses libXt, you might as well use the X11 style input methods (assuming anyone can figure them out :-)) instead of inventing yet another thing or messing with tcl. From sam-fans-owner Mon Nov 7 18:19:54 1994 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.utoronto.ca with SMTP id <23985>; Mon, 7 Nov 1994 18:19:18 -0500 Received: (castor@localhost) by drizzle.Stanford.EDU (8.6.8/8.6.4) id PAA02889; Mon, 7 Nov 1994 15:18:50 -0800 From: Castor Fu Message-Id: <199411072318.PAA02889@drizzle.Stanford.EDU> Subject: Re: Japanese input and Sam To: schwartz@galapagos.cse.psu.edu (Scott Schwartz) Date: Mon, 7 Nov 1994 18:18:49 -0500 Cc: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <94Nov7.175308est.12686@galapagos.cse.psu.edu> from "Scott Schwartz" at Nov 7, 94 05:53:04 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1760 > | Has anyone hacked japanese input methods into 'sam'? > > Since libXg already uses libXt, you might as well use the > X11 style input methods (assuming anyone can figure them out :-)) > instead of inventing yet another thing or messing with tcl. This might be the right solution. However, it scares me. When looking through libXg, it seems that libXg tries sufficiently hard to NOT to look like an Xt widget that anyone wanting to fix this has a lot of work ahead of themselves. As for the question of using the X11 i18n mechanisms, I'll quote a few portions of some relevant docs: >From the X11R5 i18n docs: Bear in mind that input methods are a technology that has prviously been used only in {\em ad hoc} ways for specific languages. . . One frustration is the ambiguity, in places of the XIM specification. . .. . None of the input methods that are shipped with X11R5 are part of the core distribution, and none are fully robust or well documented (not in English, at least). . . >From the X11R6 release notes: The IM Protocol is a completely new protocol, based on experience with R5's sample implementations. The following new features are added, beyond the mechanisms in the R5 sample implementations . . . I agree that one doesn't want to re-invent the wheel; the question is, which wheel do you want? One of the input mechanisms which is widely used, (SKK) is apparently NOT tied to X11, was designed under Emacs-lisp, and has even been ported to the DOS environment. It looks vastly simpler than any of the XIM based methods. By using TCL appropriate interface might be able to support either system. Trying to use one of the X11Rn methods sounds like a sure way to guarantee compatibility problems. -castor From sam-fans-owner Fri Nov 11 09:46:05 1994 Received: from ugw.utcc.utoronto.ca ([128.100.102.3]) by hawkwind.utcs.utoronto.ca with SMTP id <23987>; Fri, 11 Nov 1994 09:34:41 -0500 Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by ugw.utcc.utoronto.ca with SMTP id <8990>; Fri, 11 Nov 1994 09:34:23 -0500 Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A7621GAC@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 1494; Fri, 11 Nov 1994 15:33:06 +0100 Date: Fri, 11 Nov 1994 09:31:06 -0500 From: Werner Lemberg Subject: actual samx patch To: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <94Nov11.093423est.8990@ugw.utcc.utoronto.ca> Where can I find the samx patches which apply to the latest sam version (i.e. with libXg for unicode). A few weeks ago there was a question of a Linux port of 9term - any results? Werner From sam-fans-owner Thu Nov 24 08:58:08 1994 Received: from emory.mathcs.emory.edu ([128.140.110.1]) by hawkwind.utcs.utoronto.ca with SMTP id <23999>; Thu, 24 Nov 1994 08:45:03 -0500 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.9) via UUCP id AA06647 ; Thu, 24 Nov 94 08:44:45 -0500 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Thu, 24 Nov 94 08:25 EST Message-Id: Date: Thu, 24 Nov 1994 08:25:00 -0500 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: sam-fans@hawkwind.utcs.toronto.edu Subject: structural regexps just for searching I want to look for function calls where there is a space after the function name and before the left paren. But I like spaces between my keywords and the right paren. I try something like this in the command window: /[a-z0-9_]+ \(/ v/if|for|while|switch|return/ This will find the next match, but the file window does not scroll to show . the way it would for just a plain search. Is there a way to get it to do this? I'm a bit leary of just making a sweeping change , /[a-z0-9_]+ \(/ v/if|for|while|switch|return/ s/ // Although it would probably work ok. Please reply by mail, my home address is not on the list. Thanks, Arnold From sam-fans-owner Thu Nov 24 09:39:26 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <24001>; Thu, 24 Nov 1994 09:38:48 -0500 From: rob@plan9.research.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 24 Nov 1994 09:38:21 -0500 Subject: Re: structural regexps just for searching Message-Id: <94Nov24.093848est.24001@hawkwind.utcs.utoronto.ca> it's easy to get it to scroll to the next match. follow the command by an address, . : /[a-z0-9_]+ \(/ v/if|for|while|switch|return/ . it's just like saying 23 to have it show you line 23 -rob From sam-fans-owner Fri Nov 25 09:46:13 1994 Received: from emory.mathcs.emory.edu ([128.140.110.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24002>; Fri, 25 Nov 1994 09:44:53 -0500 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.9) via UUCP id AA25005 ; Fri, 25 Nov 94 09:44:40 -0500 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Fri, 25 Nov 94 09:17 EST Message-Id: From: arnold@skeeve.atl.ga.us Date: Fri, 25 Nov 1994 09:17:26 -0500 In-Reply-To: emory!plan9.research.att.com!rob's 27-line message on Nov 24, 9:38am X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rob@plan9.research.att.com, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: structural regexps just for searching > it's easy to get it to scroll to the next match. follow the command > by an address, . : > > /[a-z0-9_]+ \(/ v/if|for|while|switch|return/ > . > > it's just like saying > > 23 > > to have it show you line 23 This works, but suprisingly (to me, anyway), it does not wrap around the file... Arnold From sam-fans-owner Mon Nov 28 12:23:23 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24018>; Mon, 28 Nov 1994 12:20:00 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id MAA16684 for ; Mon, 28 Nov 1994 12:19:48 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id MAA26765 for sam-fans@hawkwind.utcs.toronto.edu; Mon, 28 Nov 1994 12:19:46 -0500 Date: Mon, 28 Nov 1994 12:19:46 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199411281719.MAA26765@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9menu program available With considerable help from David Hogan, I have written `9menu.' It is like xmenu, in that you provide menu items and commands that go with them on the command line. 9menu pops up a window containing the list of items, and executes the corresponding command when a button is pressed. It was inspired by the GWM blit code's way of starting up remote windows, I wanted something similar to use under 9wm (yes, it exists, and is due to be released RSN. I've been beta-testing it). 9menu allows you to write your own menus and customize the behavior to suit you, without the headaches of a .twmrc or .mwmrc. It is real easy to have one item spawn another, giving a similar effect to pull-right menus. Here is how I use it, one for remote systems, the other for programs I may want to run. Being lazy, I have xterm in both. I still use the 'rxterm' script, but that's mostly for convenience. (This is from my .xinitrc. The -geometry strings are to get 9wm to place the windows iconified.) 9menu -geometry 67x136-4+477 -iconic -popdown -label Remotes \ 'solaria:rxterm solaria.cc.gatech.edu' \ 'burdell:rxterm burdell.cc.gatech.edu' \ 'chrome:rxterm chrome.cc.gatech.edu' \ 'emory:rxterm emory.mathcs.emory.edu' \ 'acme:rxterm acme.gatech.edu' \ 'gnu:rxterm gate.gnu.ai.mit.edu' \ 'xterm:rxterm xterm' \ exit & 9menu -geometry 103x102-3+624 -iconic -popdown -label 'X programs' \ 'xterm:rxterm xterm' \ xtetris xlock '9wm restart:9wm restart' '9wm exit:9wm exit' exit & This isn't as earth-shattering as sam, 9term, or 9wm, but for me, at least, it fills a previously empty hole in the total environment. Oh yes, where to get it: ftp.cc.gatech.edu:/pub/people/arnold/9menu.shar.gz Let me know if there are any questions are problems, I've only tested it under SunOS 4.1.3 with X11R5. Arnold From sam-fans-owner Mon Nov 28 22:09:34 1994 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24123>; Mon, 28 Nov 1994 22:08:53 -0500 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Mon, 28 Nov 1994 22:08:39 -0500 To: Sam Fans Subject: 9menu Date: Mon, 28 Nov 1994 22:08:29 -0500 From: Scott Schwartz Message-Id: <94Nov28.220839est.12684@galapagos.cse.psu.edu> As long as we are being 9fans, how about this: --- 1.1 1994/11/29 03:02:07 +++ 9menu.c 1994/11/29 03:02:53 @@ -228,7 +228,7 @@ return; close(ConnectionNumber(dpy)); - execl("/bin/sh", "sh", "-c", com, NULL); + execl("/bin/rc", "rc", "-c", com, NULL); _exit(1); } From sam-fans-owner Tue Nov 29 04:37:32 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <24123>; Tue, 29 Nov 1994 04:37:02 -0500 Received: from cegelecproj.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 29 Nov 1994 09:35:35 +0000 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA28233; Tue, 29 Nov 1994 09:40:49 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA02664; Tue, 29 Nov 1994 09:32:41 +0000 Date: Tue, 29 Nov 1994 04:32:41 -0500 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9411290932.AA02664@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9menu program available X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 1153 > I wanted something similar to use under 9wm (yes, it exists, > and is due to be released RSN. I've been beta-testing it). [drool] > This isn't as earth-shattering as sam, 9term, or 9wm, but for me, at least, > it fills a previously empty hole in the total environment. Interesting. I think it could possibly do with some feedback to the user, though - 9term appears really quickly, but something like xrn takes quite a while, and I'd hate to think what will happen when I'm running on one of my heavily-loaded machines. Perhaps the window label could change temporarily to "spawning", or something.... > Let me know if there are any questions are problems, I've only tested > it under SunOS 4.1.3 with X11R5. Well, I'm running it under SunOS 5.3 (so all bets are off, yeah, I know, still), and as usual, 9term's giving funny stty behaviour. If I spawn a 9term with args "-p9font fixed -unix" from Sun's menu, I get a reasonable pty. If I spawn one with the same args from 9menu, I need to reset intr and erase to ^C and ^?, respectively. I haven't looked into detail yet why this might be, but I was wondering if anyone's got any ideas. steve From sam-fans-owner Tue Nov 29 04:51:38 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <24124>; Tue, 29 Nov 1994 04:51:15 -0500 Received: from cegelecproj.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 29 Nov 1994 09:50:47 +0000 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA28763; Tue, 29 Nov 1994 09:56:03 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA02789; Tue, 29 Nov 1994 09:47:54 +0000 Date: Tue, 29 Nov 1994 04:47:54 -0500 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9411290947.AA02789@zombie.gec-epl.co.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9menu program available X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 644 I wrote: > If I spawn > one with the same args from 9menu, I need to reset intr and erase to ^C and ^?, > respectively. I haven't looked into detail yet why this might be, but I was > wondering if anyone's got any ideas. scratch that. it appears to be ok, now. I think what happened is that I started 9menu from a 9term, and then exited the 9term itself. So perhaps 9menu's own pty settings were being reset by the system, and future 9terms inherited these. Having 9menu starting up along with everything else means that 9menu gets the console's settings, and they're ok. This may be complete gibberish, but it sounds reasonable. :-) steve From sam-fans-owner Tue Nov 29 10:11:48 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24018>; Tue, 29 Nov 1994 10:11:00 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id KAA10656; Tue, 29 Nov 1994 10:10:50 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id KAA27318; Tue, 29 Nov 1994 10:10:48 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199411291510.KAA27318@penfold.cc.gatech.edu> Date: Tue, 29 Nov 1994 10:10:48 -0500 In-Reply-To: Scott Schwartz's 25-line message on Nov 28, 10:08pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Scott Schwartz , Sam Fans Subject: Re: 9menu Cc: arnold@skeeve.atl.ga.us I sent the announcement to sam-fans since that seems to be where most of the discussion of 9term takes place. I figured 9fans was more for discussion of the real thing, not faking it under Unix. As to this: > To: Sam Fans > Subject: 9menu > Date: Mon, 28 Nov 1994 22:08:29 -0500 > From: Scott Schwartz > > As long as we are being 9fans, how about this: > > --- 1.1 1994/11/29 03:02:07 > +++ 9menu.c 1994/11/29 03:02:53 > @@ -228,7 +228,7 @@ > return; > > close(ConnectionNumber(dpy)); > - execl("/bin/sh", "sh", "-c", com, NULL); > + execl("/bin/rc", "rc", "-c", com, NULL); > _exit(1); > } That's not unreasonable, what I should probably do is fix 9menu to just use ${SHELL:-/bin/sh}. If I find some spare time I'll probably do that. If someone wishes to beat me to it and mail me a patch, that's fine too. Arnold From sam-fans-owner Tue Nov 29 10:32:59 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24124>; Tue, 29 Nov 1994 10:32:32 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id KAA11774 for ; Tue, 29 Nov 1994 10:32:25 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id KAA27391 for sam-fans@hawkwind.utcs.toronto.edu; Tue, 29 Nov 1994 10:32:24 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199411291532.KAA27391@penfold.cc.gatech.edu> Date: Tue, 29 Nov 1994 10:32:23 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9menu A comment about starting 9term from 9menu; that'll work, for now. 9wm's "New" menu item will start 9term by default, and then xterm if it's not there, with a command line option to change what terminal program should be run (e.g., you might like xvt (== xterm on a diet)). The point being, 9wm will do that in the long run. I don't intend to fix it to change window labels or icon labels or anything like that for feedback while a program is spawning. Write a shell program to do it and have 9menu call that shell program... 9menu has enough bells and whistles as it is. :-) I'm told that 9wm should be out REALLY RSN... Arnold From sam-fans-owner Tue Nov 29 11:11:45 1994 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24018>; Tue, 29 Nov 1994 11:11:00 -0500 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Tue, 29 Nov 1994 11:10:41 -0500 To: arnold@cc.gatech.edu (Arnold Robbins) cc: Sam Fans , arnold@skeeve.atl.ga.us Subject: Re: 9menu In-reply-to: Your message of "Tue, 29 Nov 1994 10:10:48 EST." <199411291510.KAA27318@penfold.cc.gatech.edu> Date: Tue, 29 Nov 1994 11:10:27 -0500 From: Scott Schwartz Message-Id: <94Nov29.111041est.12684@galapagos.cse.psu.edu> | That's not unreasonable, what I should probably do is fix 9menu to | just use ${SHELL:-/bin/sh}. I don't know... Isn't it better to have a definate syntax that 9menu will use, rather than have it depend on some environment variable? (Think about makefiles that need SHELL=/bin/sh at the top to get around some versions of make doing this.) If anything, a command line option is better than importing SHELL, I think. From sam-fans-owner Tue Nov 29 12:09:50 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24124>; Tue, 29 Nov 1994 12:09:23 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id MAA17167; Tue, 29 Nov 1994 12:09:09 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id MAA27471; Tue, 29 Nov 1994 12:09:08 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199411291709.MAA27471@penfold.cc.gatech.edu> Date: Tue, 29 Nov 1994 12:09:07 -0500 In-Reply-To: Scott Schwartz's 22-line message on Nov 29, 11:10am X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Scott Schwartz Subject: Re: 9menu Cc: Sam Fans > | That's not unreasonable, what I should probably do is fix 9menu to > | just use ${SHELL:-/bin/sh}. > > I don't know... Isn't it better to have a definate syntax that 9menu > will use, rather than have it depend on some environment variable? > (Think about makefiles that need SHELL=/bin/sh at the top to get around > some versions of make doing this.) If anything, a command line option > is better than importing SHELL, I think. I agree, a command line option is better. Again, patches welcome, if not I'll try to tackle it over the next week or so. Arnold From sam-fans-owner Tue Nov 29 12:22:56 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <24126>; Tue, 29 Nov 1994 12:22:28 -0500 From: rob@plan9.research.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Tue, 29 Nov 1994 12:10:14 -0500 Subject: Re: 9menu Message-Id: <94Nov29.122228est.24126@hawkwind.utcs.utoronto.ca> i disagree: the SHELL variable is conventionally just what you want: an indication of what interactive shell the user desires. the argument about make is spurious because make's functioning requires a standard shell; 9menu is for interactive applications, a different subject entirely. From sam-fans-owner Tue Nov 29 20:24:12 1994 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24126>; Tue, 29 Nov 1994 20:22:57 -0500 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12686>; Tue, 29 Nov 1994 20:22:36 -0500 To: rob@plan9.research.att.com cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9menu In-reply-to: Your message of "Tue, 29 Nov 1994 12:10:14 EST." <94Nov29.122228est.24126@hawkwind.utcs.utoronto.ca> Date: Tue, 29 Nov 1994 20:22:23 -0500 From: Scott Schwartz Message-Id: <94Nov29.202236est.12686@galapagos.cse.psu.edu> | i disagree: the SHELL variable is conventionally just what you want: | an indication of what interactive shell the user desires. the argument | about make is spurious because make's functioning requires a | standard shell; 9menu is for interactive applications, a different | subject entirely. That's the crucial point: is 9menu itself an interactive application, or is it a tool that that should support a standard syntax? My impression is that the latter is the more useful view, because it permits users to exchange 9menu command lines without depending upon which interactive shell each of them uses. From sam-fans-owner Wed Nov 30 10:59:55 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24132>; Wed, 30 Nov 1994 10:59:15 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id KAA16848 for ; Wed, 30 Nov 1994 10:59:06 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id KAA28311 for sam-fans@hawkwind.utcs.toronto.edu; Wed, 30 Nov 1994 10:59:05 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199411301559.KAA28311@penfold.cc.gatech.edu> Date: Wed, 30 Nov 1994 10:59:04 -0500 In-Reply-To: Scott Schwartz's 28-line message on Nov 29, 8:22pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9menu >| == Rob > == Scott > | i disagree: the SHELL variable is conventionally just what you want: > | an indication of what interactive shell the user desires. the argument > | about make is spurious because make's functioning requires a > | standard shell; 9menu is for interactive applications, a different > | subject entirely. > > That's the crucial point: is 9menu itself an interactive application, > or is it a tool that that should support a standard syntax? My > impression is that the latter is the more useful view, because it > permits users to exchange 9menu command lines without depending upon > which interactive shell each of them uses. I have to admit that this is mostly how I envision 9menu, as a tool, not an interactive application. (It's interactive through the mouse, but that's orthogonal to the issue here.) My own expectation is that 9menu commands would run shell scripts that execute the larger tasks, and those scripts can be in any shell you like, via !#. This has the major advantage that you can edit the shell script without having to restart 9menu each time. I haven't completely decided yet how to deal with this. I'm semi-leaning towards a command line option -shell, instead of $SHELL. Arnold From sam-fans-owner Thu Dec 1 18:11:16 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24123>; Thu, 1 Dec 1994 18:07:40 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id SAA21417; Thu, 1 Dec 1994 18:07:30 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id SAA29418; Thu, 1 Dec 1994 18:07:28 -0500 Date: Thu, 1 Dec 1994 18:07:28 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199412012307.SAA29418@penfold.cc.gatech.edu> To: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: rc, es, and 9term under Linux? Hi. I apologize in advance for the triple posting, since I know there's a lot of membership overlap, but I wanted to not miss anyone. I'm writing an article on sam/9term/9wm/rc/es for Linux Journal, and have hit the Linux specific part. Unfortunately (and ironically) I don't have a Linux system. So I need some help. 1. Does rc compile out of the box under Linux? If not, what has to be done to make it work? 1. Does es compile out of the box under Linux? If not, what has to be done to make it work? 3. Does 9term work under Linux? I know that it takes some work to get it to compile, but does it run ok, or are there problems? Thanks! Arnold From sam-fans-owner Thu Dec 1 19:10:18 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.utoronto.ca with SMTP id <24125>; Thu, 1 Dec 1994 19:09:51 -0500 Received: from uucp5.UU.NET by relay1.UU.NET with SMTP id QQxsls17709; Thu, 1 Dec 1994 19:09:34 -0500 Date: Thu, 1 Dec 1994 19:09:33 -0500 From: plexus-sys!mdash@uunet.uu.net Message-Id: Received: from plexus-sys.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Thu, 1 Dec 1994 19:09:51 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term bug Content-Type: text Content-Length: 993 Has anybody else seen this race in 9term? Here's an excerpt from sendrunes: if (p > s) while (write(comm_fd, s, p-s) < 0 && errno == EAGAIN) ; /* reinstate echo mode, if we disabled it above */ if (echo) { ttmode.c_lflag |= ECHO; IOSETATTR(slave_fd, &ttmode); } The IOSETATTR can race with the line discipline's processing of characters written on comm_fd. When the IOSETATTR beats the input processing, some suffix of the input is echoed an extra time. I've seen this only on some multiprocessors, but it seems theoretically possible in other settings. My workaround is nondeterministic, but it works on the hosts where I've tried it. if (echo) { tcdrain(comm_fd); ttmode.c_lflag |= ECHO; IOSETATTR(slave_fd, &ttmode); } Anybody got a better way to handle this? --Mike Scheer, 908-273-1885, mdash@plexus-sys.com From sam-fans-owner Fri Dec 2 11:20:38 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24123>; Fri, 2 Dec 1994 11:15:24 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id LAA29657; Fri, 2 Dec 1994 11:15:14 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id LAA29901; Fri, 2 Dec 1994 11:15:12 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199412021615.LAA29901@penfold.cc.gatech.edu> Date: Fri, 2 Dec 1994 11:15:12 -0500 In-Reply-To: Arnold Robbins's 35-line message on Dec 1, 6:07pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: rc, es, and 9term under Linux? (summary) Again, apologies for the triple post. I'll try not to do it again, except perhaps to announce the availability of the article when it's done. Thanks to everyone who replied. The upshot is that rc compiles with little problem, requiring minor changes to generate the sigmsgs.c file. es is similar, but this is noted in a comment in the Makefile. 9term can be made to compile under Linux, but apparently does not work quite right yet. At least one person is working on it but has not released his port yet. For those of you who asked "What is 9wm, and where can I get it?". The answer is that 9wm is an X11 window manager that completes the sam+9term+rc picture, emulating the window management policies of 8-1/2 (8½ for you unicode folks ☺ :-), hiding windows instead of iconifying them, click to type, thick border on the current window, etc. As to the second part of the question, you can't get it, yet. I've been beta-testing it. It is due for release REALLY REALLY REALLY SOON NOW, but as I'm not the author, I can't say when. (My article has around a two-month lead time before it's published, so by then 9wm should be out.) Rob, Bobf, Byron, Paul, Matty, and David, I would like to send you a copy to review when it's done. If you're not interested, please let me know. Thanks, Arnold Robbins "What's GNU" columnist for Linux Journal (Yet Another Alternate Identity) From sam-fans-owner Tue Dec 6 16:26:17 1994 Received: from jli ([199.2.111.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24132>; Tue, 6 Dec 1994 16:23:52 -0500 Received: from cumulus by jli with uucp (Smail3.1.28.1 #23) id m0rF7ME-000IgDC; Tue, 6 Dec 94 13:23 PST From: trost@cloud.rain.com (Bill Trost) Message-Id: Received: by emacs (GNU Emacs 19.22.5) with vm; Tue, 06 Dec 1994 13:15:37 PST To: 9fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: acme for X? Date: Tue, 6 Dec 1994 16:22:27 -0500 [Sorry for the posting to multiple lists, but someone suggested this would be the best place to look for an answer to my question.] Does anyone know if there's been an implementation of acme for X? Acme, you'll recall, is a "programming environment" (I guess that's the right word) that Rob Pike implemented for Plan 9 and described in a USENIX paper. I've had a chance to play with it a bit under Plan 9, and it's just an amazingly wonderful interface. In any event, I'd be interested if anyone has, is, or was working on such a thing. I'd rather not have to try to implement it myself, but if nothing materializes, I might just have to.... From sam-fans-owner Tue Dec 6 18:04:44 1994 Received: from Legato.COM ([137.69.1.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24131>; Tue, 6 Dec 1994 18:04:13 -0500 Received: from jupiter.Legato.COM by Legato.COM (4.1/SMI-4.0) id AA20239 for sam-fans@hawkwind.utcs.toronto.edu; Tue, 6 Dec 94 15:03:57 PST Received: from leo.Legato.COM by jupiter.Legato.COM (4.1/SMI-4.1) id AA05245; Tue, 6 Dec 94 15:03:57 PST From: dbecker@jupiter.Legato.COM (Doug Becker) Message-Id: <9412062303.AA05245@jupiter.Legato.COM> Subject: Re: acme for X? To: plan9-fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Date: Tue, 6 Dec 1994 18:03:56 -0500 In-Reply-To: <94Dec6.171159est.295241@psuvax1.cse.psu.edu> from "philw@plan9.research.att.com" at Dec 6, 94 05:02:24 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 497 Not that Phil's response is in any way lacking (I had no idea of the port of ALEF to UNIX), but I asked Rob the same question a couple of weeks ago, and his response was that Acme is "pretty deeply wedded" to concepts in Plan 9 that have no analog in UNIX. (This seems fairly obvious from the various papers.) I too would love to see some sort of Acme under UNIX (or even Plan 9. :-) Heck, just the general availability of Acme's ALEF source would be enough to appease me for a few weeks... :-) From sam-fans-owner Tue Dec 6 22:35:30 1994 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24131>; Tue, 6 Dec 1994 22:34:49 -0500 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12685>; Tue, 6 Dec 1994 22:34:27 -0500 To: plan9-fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: acme for X? In-reply-to: Your message of "Tue, 06 Dec 1994 18:03:56 EST." <9412062303.AA05245@jupiter.Legato.COM> Date: Tue, 6 Dec 1994 22:34:20 -0500 From: Scott Schwartz Message-Id: <94Dec6.223427est.12685@galapagos.cse.psu.edu> Anyone who is interested in acme should take a look at Oberon, the system that inspired it. Wirth has written a book and a number of papers about it. You can ftp it from neptune.inf.ethz.ch; they have binaries for sparc and some other systems. The system runs in an X window and more or less acts like that window is the screen of a Ceres workstation. It's a little like running smalltalk---Oberon is its own user interface, programming language, and operating system. Anyway, the system is amazingly efficient and elegant. Everyone I've shown it to has said "Wow.", so go check it out while we're waiting for the next Plan 9 cd to arrive. From sam-fans-owner Wed Dec 7 06:25:10 1994 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.utoronto.ca with SMTP id <24131>; Wed, 7 Dec 1994 06:24:37 -0500 From: pete@minster.york.ac.uk Date: Wed, 7 Dec 1994 06:11:58 -0500 Message-ID: To: plan9-fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu, schwartz@galapagos.cse.psu.edu Subject: Re: acme for X? Scott says: >Anyone who is interested in acme should take a look at Oberon, the >system that inspired it. Wirth has written a book and a number of >papers about it. You can ftp it from neptune.inf.ethz.ch; they have >binaries for sparc and some other systems. I'd agree with this -- Oberon is an interesting and very slick system which is well worth investigating -- anything that manages to pack a GUI, word processor, compiler, drawing program, mail tool, paint program, terminal emulator and so on into a few meg is _very_ impressive.. >Anyway, the system is amazingly efficient and elegant. Everyone I've >shown it to has said "Wow.", so go check it out while we're waiting >for the next Plan 9 cd to arrive. Yes, Oberon is elegant, but not in the same way that Help and Acme are -- it's hard to create ``ad hoc'' tools in Oberon without a fair bit of programming... It's a nice environment for building and documenting Oberon programs but I wouldn't want to spend all day in it! pete -- Peter Fenelon - Research Associate - High Integrity Systems Engineering Group, Dept. of Computer Science, University of York, York, Y01 5DD +44 (0)904 433388 EMAIL: pete@minster.york.ac.uk `There's no room for enigmas in built-up areas' From sam-fans-owner Thu Dec 8 11:37:16 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24132>; Thu, 8 Dec 1994 11:35:46 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id LAA09886 for ; Thu, 8 Dec 1994 11:35:39 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id LAA04772 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 8 Dec 1994 11:35:38 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199412081635.LAA04772@penfold.cc.gatech.edu> Date: Thu, 8 Dec 1994 11:35:37 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam and varios mail programs Greetings. I use 'mush' as my mail program, and I have my EDITOR environment variable set to use sam. The problem comes when I have a sam running, and then I go to read mail. When I edit my file, it cranks up another sam. But when that sam quits, it removes the fifo in /tmp that the `B' command uses. At that point, I can no longer use `B' to communicate with my orignal sam. My question is, how do *you* handle this? Does anyone have a shell script that runs B on their temporary mail file such that things stay in sync after the file is written back out with sam? (This has probably been discussed before...) Thanks! Arnold From sam-fans-owner Thu Dec 8 11:56:00 1994 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.utoronto.ca with SMTP id <24133>; Thu, 8 Dec 1994 11:53:57 -0500 Received: from sulphur.osf.org (sulphur.osf.org [130.105.5.36]) by postman.osf.org (8.6.9/8.6.x) with SMTP id LAA08641; Thu, 8 Dec 1994 11:53:54 -0500 From: Rich Salz Received: by sulphur.osf.org (1.37.109.4/4.7) id AA06397; Thu, 8 Dec 94 11:50:24 -0500 Date: Thu, 8 Dec 1994 11:50:24 -0500 Message-Id: <9412081650.AA06397@sulphur.osf.org> To: arnold@cc.gatech.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam and varios mail programs I modified sam so that when creating the fifo it first did getenv("sampipe") and if that existed it used that as the name of the pipe. I set that variable in my .rcrc which is sourced by my X startup stuff. For editing I set VISUAL to $home/bin/callsam, which is this: #! /bin/rc ~ $#* 1 || { echo Usage: `{basename $0} file >[1=2] exit 1 } ~ $#sampipe 0 && { sampipe=$home/.sam.$USER ! ~ $#DISPLAY 0 && sampipe=$sampipe.$DISPLAY } ! test -r $sampipe && { echo `{basename $0} ^ ': No pipe "' ^ $sampipe ^ '" to sam' >[1=2] exit 1 } { switch ($1) { case /* echo B $1 case * echo B `{builtin pwd} ^ / ^ $1 } }>$sampipe echo Type EOF when done: cat # Could use "sed 1q" to get just a newline but I prefer the EOF. From sam-fans-owner Thu Dec 8 11:57:04 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24136>; Thu, 8 Dec 1994 11:56:44 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id LAA10733 for ; Thu, 8 Dec 1994 11:56:36 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id LAA04852 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 8 Dec 1994 11:56:35 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199412081656.LAA04852@penfold.cc.gatech.edu> Date: Thu, 8 Dec 1994 11:56:35 -0500 In-Reply-To: rob@plan9.research.att.com's 15-line message on Dec 8, 11:48am X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam and varios mail programs > (various?) *I* can spell. My keyboard can't, though. ☺ > why not change your EDITOR variable to be a script > that uses B to get the file into sam, This is the easy part. > and some other > signal or watchdog to get it back? This is the hard part. It happens that if I do something like this with mush, and simply wait until I've finished with the editor, I'm ok, but it's pretty fragile. That's why I was wondering if someone else had beat me to inventing this wheel. From sam-fans-owner Thu Dec 8 13:03:16 1994 Received: from fire.ml.com ([192.246.100.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24137>; Thu, 8 Dec 1994 13:02:50 -0500 Received: from ml.com ([146.125.4.24]) by fire.ml.com (8.6.3/8.6.3) with ESMTP id NAA14898; Thu, 8 Dec 1994 13:02:52 -0500 Received: from disney.etcore.ml.com (disney.etcore.ml.com [146.125.98.230]) by ml.com (8.6.3/8.6.3) with SMTP id NAA00508; Thu, 8 Dec 1994 13:01:16 -0500 Received: from belfast.ml.com by disney.etcore.ml.com (4.1/SMI-4.1) id AA13967; Thu, 8 Dec 94 13:02:39 EST Received: by belfast.ml.com (5.0/SMI-SVR4) id AA03140; Thu, 8 Dec 1994 12:55:49 +0500 Date: Thu, 8 Dec 1994 02:55:49 -0500 From: shopiro@disney.etcore.ml.com (Jonathan Shopiro) Message-Id: <9412081755.AA03140@belfast.ml.com> To: arnold@cc.gatech.edu Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam and varios mail programs Content-Length: 2377 I use mailx with sam as my editor. I only have one instance of sam on my workstation. It works like this: I invoke mailx with the following command: crt=50 PAGER=Bcat VISUAL=BB mailx "crt=50" means if it's longer than 50 lines run it through the pager. "PAGER=Bcat" means use Bcat (a shell script; see below) to display long messages. "VISUAL=BB" means use BB (ditto) as the message editor Then when I try to read a long message it appears in sam. When I compose a message I can type "~v" and the message so far appears in sam. I edit it until its perfect, select write, and go back to the mailx window where I hit return and then send it. It's a mess, really, but it beats mailtool and textedit (no characterization sufficiently derogatory). Now for my question: has anybody gotten to work reliably with sam and 9term under Solaris? It seems to work for a while after rebooting but then it doesn't work anymore. I poked through the code to some X function about swapping selections and then I gave up. Also, is it supposed to work to snarf in one 9term window and paste (the snarfed text) into another? That never works for me. -- Jonathan Shopiro Merrill Lynch & Co. Here are the shell scripts (simple modifications of B, both of them): Bcat: #!/bin/sh file=$HOME/tmp/Bcat$$ files=$file line="none" if [ $# != 0 ]; then echo 'usage: Bcat' 1>&2 exit 1 fi dir=`/bin/pwd` if [ "$USER" = "" ]; then USER=$LOGNAME fi pipe=/tmp/.sam.$USER if [ $DISPLAY != "" ]; then pipe=$pipe.$DISPLAY fi if [ ! -r $pipe ]; then echo `basename $0`": No pipe \""$pipe"\" to sam." 1>&2 exit 1 fi cat - >$file echo "B $files" >> $pipe if [ $line != "none" ]; then echo $line >> $pipe fi read dummy BB: #!/bin/sh files= line="none" if [ $# = 0 ]; then echo 'usage: BB [-nnnn] files...' 1>&2 exit 1 fi dir=`/bin/pwd` if [ "$USER" = "" ]; then USER=$LOGNAME fi pipe=/tmp/.sam.$USER if [ $DISPLAY != "" ]; then pipe=$pipe.$DISPLAY fi if [ ! -r $pipe ]; then echo `basename $0`": No pipe \""$pipe"\" to sam." 1>&2 exit 1 fi for i in $* do case "$i" in /*) files="$files $i" ;; -*) line=`echo $i | sed 's/.//'` ;; *) files="$files $dir/$i" ;; esac done echo "B $files" >> $pipe if [ $line != "none" ]; then echo $line >> $pipe fi read dummy From sam-fans-owner Thu Dec 8 16:20:13 1994 Received: from localhost by hawkwind.utcs.utoronto.ca with SMTP id <24140>; Thu, 8 Dec 1994 16:17:59 -0500 Return-Path: uunet.uu.net!rexago8!rserv1!rexago8!hc05 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24138>; Thu, 8 Dec 1994 13:12:24 -0500 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQxtkq24553; Thu, 8 Dec 1994 13:12:06 -0500 Received: from rexago8.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 8 Dec 1994 13:12:07 -0500 Received: by summitis.com (smail2.5) id AA00772; 8 Dec 94 12:54:53 EST (Thu) Received: from summitis.com by rserv1.summitis.com; Thu, 8 Dec 1994 12:53 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA148734; Thu, 8 Dec 1994 12:53:51 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA17166; Thu, 8 Dec 1994 12:53:48 -0500 From: hc05@summitis.com Message-Id: <9412081753.AA17166@cheetah> Subject: Re To: sam-fans-owner In-Reply-To: <9412081718.AA119815@rexsrvr2.summitis.com> from "sam-fans-owner@hawkwind.utcs.toronto.edu" at Dec 8, 94 12:17:00 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 1788 Date: Thu, 8 Dec 1994 13:12:18 -0500 Resent-To: sam-fans Resent-Date: Thu, 8 Dec 1994 16:17:54 -0500 Resent-From: Chris Siebenmann Resent-Message-Id: <94Dec8.161759est.24140@hawkwind.utcs.utoronto.ca> >Greetings. I use 'mush' as my mail program, and I have my EDITOR environment >variable set to use sam. The problem comes when I have a sam running, and >then I go to read mail. When I edit my file, it cranks up another sam. But >when that sam quits, it removes the fifo in /tmp that the `B' command uses. >At that point, I can no longer use `B' to communicate with my orignal sam. > >My question is, how do *you* handle this? Does anyone have a shell script >that runs B on their temporary mail file such that things stay in sync >after the file is written back out with sam? I rewrote B to handle this and it works fairly well. Its written in perl, but you are welcome to rewrite it in other shell languages if you like. Beirne #!/usr/local/perl @files = (); if (@ARGV == 0) { print STDERR "usage: B [-nnnn] files...\n"; exit 1; } $dir = `/bin/pwd`; chop $dir; ($name) = getpwuid($>); $pipe = '/tmp/.sam.'.$name.'.'.$ENV{'DISPLAY'}; foreach (@ARGV) { if (m#^/#o) { push(@files, $_); } elsif (m#^-#o) { $line = substr($_, 1); } else { push(@files, $dir.'/'.$_); } } if (defined($ENV{'DISPLAY'}) && -w $pipe) { open(PIPE, '>'.$pipe) || die "Can't open $pipe: $!"; print PIPE "B ", join(' ', @files), "\n"; print PIPE $line, "\n" if (defined($line)); close(PIPE); } elsif (defined($ENV{'DISPLAY'})) { exec 'sam', @files; } else { $editor = 'vi'; exec $editor, "+$line", @files; } -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Mon Dec 12 04:41:44 1994 Received: from lore.plan9.cs.su.oz.au ([129.78.96.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24145>; Mon, 12 Dec 1994 04:39:50 -0500 Date: Mon, 12 Dec 1994 19:36:23 -0500 From: dhog@plan9.cs.su.oz.au (David Hogan) To: plan9-fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: 9wm: A Lightweight X Window Manager in the style of 8 1/2 Message-Id: <94Dec12.043950est.24145@hawkwind.utcs.utoronto.ca> I have just released version 1.0 of my X window manager, 9wm. 9wm attempts to capture the look and feel of the Plan 9 windowing system "8 1/2". This provides a minimal yet comfortable user interface. 9wm is particularly handy for users who are constantly moving back and forth between Plan 9 and X windows, but it should also appeal to non-Plan 9 users, particularly those who are sick of the amount of time that certain other window managers take to start up ;-) 9wm should be appearing on comp.sources.x soon, if all goes well. In the meantime, you can get it via anonymous ftp from ftp.cs.su.oz.au, in the directory /dhog/9wm. 9wm is freely available. From sam-fans-owner Tue Dec 13 03:48:02 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto.ca with SMTP id <24145>; Tue, 13 Dec 1994 03:46:14 -0500 Received: from cegelecproj.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Tue, 13 Dec 1994 08:45:46 +0000 Received: from zombie.cegelecproj.co.uk (zombie.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA00457; Tue, 13 Dec 1994 08:51:11 +0000 Received: by zombie.cegelecproj.co.uk (5.0/SMI-SVR4) id AA00324; Tue, 13 Dec 1994 08:42:51 +0000 Date: Tue, 13 Dec 1994 03:42:51 -0500 From: steve Message-Id: <9412130842.AA00324@zombie.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: dhog Subject: Re: 9wm: A Lightweight X Window Manager in the style of 8 1/2 Cc: sam-fans@hawkwind.utcs.toronto.edu X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Content-Length: 234 > In > the meantime, you can get it via anonymous ftp from ftp.cs.su.oz.au, > in the directory /dhog/9wm. Could you provide me with some filenames, too? My only access to ftp is via relays, so browsing's extremely difficult. steve From sam-fans-owner Wed Dec 14 00:46:06 1994 Received: from lore.plan9.cs.su.oz.au ([129.78.96.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24145>; Wed, 14 Dec 1994 00:45:03 -0500 Date: Wed, 14 Dec 1994 15:41:41 -0500 From: David Hogan To: steve cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9wm: A Lightweight X Window Manager in the style of 8 1/2 Message-Id: <94Dec14.004503est.24145@hawkwind.utcs.utoronto.ca> >Could you provide me with some filenames, too? My only access to ftp is >via relays, so browsing's extremely difficult. Just get 9wm-1.0.shar.Z From sam-fans-owner Wed Dec 14 12:34:13 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24145>; Wed, 14 Dec 1994 12:32:31 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id MAA28767; Wed, 14 Dec 1994 12:32:15 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id MAA10895; Wed, 14 Dec 1994 12:32:10 -0500 Date: Wed, 14 Dec 1994 12:32:10 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199412141732.MAA10895@penfold.cc.gatech.edu> To: 9fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: new version of 9menu available In ftp://ftp.cc.gatech.edu/people/arnold/9menu-1.1.shar.gz is a new version of 9menu. This uses XTextWidth for the menu, and adds a -shell option. Enjoy, Arnold From sam-fans-owner Wed Dec 14 13:08:07 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24145>; Wed, 14 Dec 1994 13:07:34 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id NAA00194; Wed, 14 Dec 1994 13:07:22 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id NAA10964; Wed, 14 Dec 1994 13:07:21 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199412141807.NAA10964@penfold.cc.gatech.edu> Date: Wed, 14 Dec 1994 13:07:20 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: 9fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: 9menu, permissions Ooops. Fixed the permissions. Sorry 'bout that. --Arnold From sam-fans-owner Sun Dec 18 12:42:42 1994 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24149>; Sun, 18 Dec 1994 12:41:30 -0500 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxuvm09076; Sun, 18 Dec 1994 12:41:16 -0500 Received: from rexago8.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Sun, 18 Dec 1994 12:41:11 -0500 Received: by summitis.com (smail2.5) id AA19757; 18 Dec 94 12:16:48 EST (Sun) Received: from summitis.com by rserv1.summitis.com; Sun, 18 Dec 1994 12:15 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA78676; Sun, 18 Dec 1994 12:14:51 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA16943; Sun, 18 Dec 1994 12:14:50 -0500 From: hc05@summitis.com Message-Id: <9412181714.AA16943@cheetah> Subject: 9term & AIX To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 1765 Date: Sun, 18 Dec 1994 12:41:18 -0500 I ported 9term to AIX 3.2.5. This is the third time I have tried it and I think I have it working well. I have a few questions, though, to see if it is working the way it should be: Should the suspend (^z), interrupt(DEL or ^c) and other interrupt keys do the usual UNIX things? I am seeing them passed through to the shell without having the intended effects of job control or program termination. If I do an rlogin to another machine, though, they work fine. How do I set the modes resource? I found that I have to make sure I set icanon, which only occurs if I start a 9term under xterm. If I start it under 9wm I get my prompt redrawn whenever I start a command and newlines don't work right. I'm setting this for now in my $ENV file in ksh, but I would like to put it in my resource file. I tried things like this but they didn't work: 9Term*p9TtyModes: icanon 9Term*ttyModes: icanon One final unrelated question: what is es? I know about 9wm, sam, rc, and 9term but don't know what es is. Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Sun Dec 25 13:15:39 1994 Received: from plan9.research.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <24152>; Sun, 25 Dec 1994 13:14:10 -0500 From: bobf@plan9.research.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Sun, 25 Dec 1994 13:13:05 -0500 Message-Id: <94Dec25.131410est.24152@hawkwind.utcs.utoronto.ca> I have a couple of announcements. First, we have reorganized our distribution directory and the location of the sam release has changed. It can now be found at ftp://netlib.att.com/netlib/research/sam.msg.Z or, equivalently ftp netlib.att.com cd netlib/research get sam.msg.Z The old release location now contains a pointer to this directory. Second, a new distribution of sam is now available. It contains a couple of minor bug fixes and two changes: scrolling menus and protocol modifications to support processors with 64-bit addresses. Dave Hanson not only removed the 32-bit dependencies from the protocol but also graciously tested the code after it was integrated into our master version. He deserves the thanks of Alpha owners everywhere. Although the protocol now accommodates 64-bit addresses, some alignment dependencies remain. If you are planning to install sam on a 64-bit processor, please read the paragraph in the README file (at approximately line 160) that describes the nature of these dependencies. No modifications should be needed for 32-bit processors. The protocol change makes the new sam incompatible with the previous version. This should only make a difference if you do a `sam -r' to a machine running an incompatible version. If you are maintaining sam on several systems, I recommend that you update all of them simultaneously. Finally, the protocol works for a remote sam when one processor is 32-bit and the other is 64-bit. From sam-fans-owner Sun Dec 25 16:48:07 1994 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24153>; Sun, 25 Dec 1994 16:47:41 -0500 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Sun, 25 Dec 1994 16:47:17 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Date: Sun, 25 Dec 1994 16:47:13 -0500 From: Scott Schwartz Message-Id: <94Dec25.164717est.12684@galapagos.cse.psu.edu> Hi gang, I've made some changes to Matty's 9term v1.6.2 which I thought I'd share. The changes are: * Fix the Xrm stuff to not poke around inside the display structure, so that it will work with X11R6. * Export the (correct) DISPLAY variable to the shell, like xterm does. * Under SUNOS, make utmp entries using ttyslot, like xterm and others do. * Don't put null host fields in utmp, even for local displays. * The tcdrain fix(?) that someone else posted. -- Scott *** 1.1 1994/12/13 04:33:24 --- display.c 1994/12/20 23:37:44 *************** *** 29,40 **** #include "9term.h" - #ifdef __alpha - # define XRDB (((_XPrivDisplay)_dpy)->db) - #else - # define XRDB (_dpy->db) - #endif - extern Display *_dpy; extern Widget _toplevel; --- 29,34 ---- *************** *** 136,142 **** sprintf(str1, "%s.%s", resource, rname); sprintf(str2, "%s.%s", class, cname); ! if (XrmGetResource(XRDB, str1, str2, &str_type, &value) == True) { strncpy(result, value.addr, (int)value.size); return result; } --- 130,138 ---- sprintf(str1, "%s.%s", resource, rname); sprintf(str2, "%s.%s", class, cname); ! if (XrmGetResource( ! XrmGetDatabase(_dpy), ! str1, str2, &str_type, &value) == True) { strncpy(result, value.addr, (int)value.size); return result; } *************** *** 209,214 **** --- 205,211 ---- void init_display(int *argc, char **argv, char **shargv, char *resource) { + XrmDatabase rdb; XrmDatabase cmd; char **cp; char id[512]; *************** *** 225,231 **** xtbinit(0, resource, argc, argv, fallbacks); /* we're still not done with the command line */ ! XrmMergeDatabases(cmd, &XRDB); #ifdef DEBUG_X XSynchronize(_dpy, True); XSetErrorHandler(abort); --- 222,229 ---- xtbinit(0, resource, argc, argv, fallbacks); /* we're still not done with the command line */ ! rdb = XrmGetDatabase(_dpy); ! XrmMergeDatabases(cmd, &rdb); #ifdef DEBUG_X XSynchronize(_dpy, True); XSetErrorHandler(abort); *************** *** 233,238 **** --- 231,238 ---- /* export window id to environment */ sprintf(id, "%d", XtWindow(_toplevel)); setenv("WINDOWID", id, 1); + /* make the display env var match the actual display */ + setenv("DISPLAY", XDisplayString(_dpy), 1); /* register mouse and keyboard events */ einit(Ekeyboard | Emouse); *** 1.1 1994/12/13 20:51:08 --- pty.c 1994/12/25 21:31:13 *************** *** 409,414 **** --- 409,415 ---- ; #if !defined(PCKT) && !defined(REMOTE) /* reinstate echo mode, if we disabled it above */ + tcdrain (comm_fd); if (echo) { ttmode.c_lflag |= ECHO; IOSETATTR(slave_fd, &ttmode); *************** *** 573,583 **** --- 574,586 ---- char *user, *display, *cp; struct utmp utmp; int fd; + int save_fd; user = getuser(); fd = open("/etc/utmp", O_RDWR); if (fd < 0) return; + #ifndef SUNOS /* * search for existing entry or add a new entry * to the end of the file if one is not found. *************** *** 590,607 **** --- 593,632 ---- } slot++; } + #else /* SUNOS */ + /* XXX - ttyslot assumes that fd 0 is already attached to the + 9term pty, so we jump thru some hoops to make it so, and + then put it back. Since we don't use stdin, we could probably + leave off the last bit. */ + #undef dup + save_fd = dup (0); + if (save_fd < 0) + goto done; + dup2 (slave_fd, 0); + slot = ttyslot (); + dup2 (save_fd, 0); + close (save_fd); + if (slot <= 0) + goto done; + + lseek (fd, slot*sizeof(utmp), SEEK_SET); + #endif /* SUNOS */ + /* build the entry and write it */ strncpy(utmp.ut_line, ttyname, sizeof(utmp.ut_line)); strncpy(utmp.ut_name, user, sizeof(utmp.ut_name)); display = getenv("DISPLAY"); if (display) { + /* cp = strchr(display, ':'); if (cp) *cp = 0; + */ strncpy(utmp.ut_host, display, sizeof(utmp.ut_host)); } time(&utmp.ut_time); write(fd, &utmp, sizeof(utmp)); + done: close(fd); } From sam-fans-owner Tue Dec 27 13:34:01 1994 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.utoronto.ca with SMTP id <24152>; Tue, 27 Dec 1994 13:31:47 -0500 Received: from sulphur.osf.org (sulphur.osf.org [130.105.1.123]) by postman.osf.org (8.6.9/8.6.x) with SMTP id NAA27624 for ; Tue, 27 Dec 1994 13:31:45 -0500 From: Rich Salz Received: by sulphur.osf.org (1.37.109.4/4.7) id AA16601; Tue, 27 Dec 94 13:27:59 -0500 Date: Tue, 27 Dec 1994 13:27:59 -0500 Message-Id: <9412271827.AA16601@sulphur.osf.org> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Diffs to latest sam Thanks, as always, for the update Bob! The "install" rules for all the makefiles in the "sam" directory have a typo in the last line. I think the stanze should be: install: sam cp sam $(SAMDIR)/$(RSAMNAME) cp samsave $(SAMESAVDIR)/samesave chmod +x $(SAMESAVEDIR)/samesave ^^^^^^^^^^^^^^^ missing It would be nice if SAM and SAMTERMDIR in samterm/Makefile were more similar to RSAMNAME, TERMNAME, SAMDIR, and SAMSAVEDIR in sam/Makefile. Finally, I always put this patch back in. If $sampipe exists, it names the pipe sam uses for its command channel. I set it in my .rcrc *** unix.c.save Tue Dec 27 12:58:51 1994 --- unix.c Tue Dec 27 13:01:27 1994 *************** *** 90,97 **** user = getuser(); disp = getenv("DISPLAY"); ! if (disp) { exname = (char *)alloc(4 + 6 + strlen(user) + 1 + strlen(disp) + 1); sprint(exname, "/tmp/.sam.%s.%s", user, disp); } else { --- 90,102 ---- user = getuser(); disp = getenv("DISPLAY"); + exname = getenv("sampipe"); ! if (exname) { ! exname = (char *)alloc(strlen(exname) + 1); ! strcpy(exname, getenv("sampipe")); ! } ! else if (disp) { exname = (char *)alloc(4 + 6 + strlen(user) + 1 + strlen(disp) + 1); sprint(exname, "/tmp/.sam.%s.%s", user, disp); } else { From sam-fans-owner Fri Dec 30 17:00:57 1994 Received: from louie.udel.edu ([128.175.1.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24154>; Fri, 30 Dec 1994 16:58:10 -0500 Received: from sol.cis.udel.edu by louie.udel.edu id aa23253; 30 Dec 94 16:44 EST Received: from louie.udel.edu by sol.cis.udel.edu id aa27305; 30 Dec 94 21:44 GMT Subject: where are the samx2 patches? To: sam-fans@hawkwind.utcs.toronto.edu Date: Fri, 30 Dec 1994 16:44:26 -0500 From: "Mark C. Chu-Carroll" X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 512 Message-ID: <9412302144.aa12286@kili.cis.udel.edu> Greetings, all. I'm happily using sam with the samx2 patches, but I somehow managed to trash my original copy of the sam sources. Now that there's been an upgrade, I'd like to get hold of the samx2 patches again, and see if I can graft them onto the newest version of sam. Could someone tell me where the heck they live? (I know that to purists, the samx patches are sacriledge, but I can't live without the ability to navigate my file and make small changes without reaching for the mouse.) Thanks! From sam-fans-owner Sat Dec 31 13:03:16 1994 Received: from louie.udel.edu ([128.175.1.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24156>; Sat, 31 Dec 1994 13:00:25 -0500 Received: from sol.cis.udel.edu by louie.udel.edu id aa06750; 31 Dec 94 12:57 EST Received: from louie.udel.edu by sol.cis.udel.edu id aa09584; 31 Dec 94 17:57 GMT Subject: Compiling the new release of Sam To: sam-fans@hawkwind.utcs.toronto.edu Date: Sat, 31 Dec 1994 12:57:36 -0500 From: "Mark C. Chu-Carroll" X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 433 Message-ID: <9412311757.aa14995@kili.cis.udel.edu> Has anyone successfully compiled the new release of Sam on SunOS? I've got it compiled and woking smoothly on my solaris machine, but on my SunOS machine, it crashes. When sam goes to load samterm on my SunOS machine, it pops the window up, and then immediately crashes with samterm:panic: flnew: Invalid argument I'm really not up to figuring out the internals enough to fix this... Does anyone have any clues? Thanks, From sam-fans-owner Sat Dec 31 14:23:31 1994 Received: from louie.udel.edu ([128.175.1.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24157>; Sat, 31 Dec 1994 14:23:01 -0500 Received: from sol.cis.udel.edu by louie.udel.edu id aa08748; 31 Dec 94 14:19 EST Received: from louie.udel.edu by sol.cis.udel.edu id aa10055; 31 Dec 94 19:18 GMT Subject: Ooops - ignore sam problems on Sun! To: sam-fans@hawkwind.utcs.toronto.edu Date: Sat, 31 Dec 1994 14:18:37 -0500 From: "Mark C. Chu-Carroll" X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 308 Message-ID: <9412311918.aa15083@kili.cis.udel.edu> Oops! Please ignore my last message... I have copies of both the original, untouched sam sources, and a working copy. I accidentally ran the sun patch on the untouched sources, *not* on the copy that I compiled. So of course, it didn't work. Please feel free to call me an idiot; I deserve it! :-) From sam-fans-owner Wed Jan 4 15:19:54 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24158>; Wed, 4 Jan 1995 15:13:37 -0500 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQxxgq20888; Wed, 4 Jan 1995 15:13:26 -0500 Received: from rexago8.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 4 Jan 1995 15:13:29 -0500 Received: by summitis.com (smail2.5) id AA06487; 4 Jan 95 14:43:35 EST (Wed) Received: from summitis.com by rserv1.summitis.com; Wed, 4 Jan 1995 14:42 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA59829; Wed, 4 Jan 1995 14:42:45 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA19462; Wed, 4 Jan 1995 14:42:42 -0500 From: hc05@summitis.com Message-Id: <9501041942.AA19462@cheetah> Subject: 9wm & labels To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 927 Date: Wed, 4 Jan 1995 15:13:35 -0500 I've been happily using 9wm on my RS/6000 for several weeks now, but I have one question. I don't generally miss the borders of windows, but sometimes I lose track of which window is which, especially when I am rlogin'd in several windows. If the windows are hidden I just pick the window off of the menu, but if it is visible I don't know a convenient way to identify the label for the window, which would tell me what I need to know. I have an entry in 9menu to run xwininfo, but this seems somewhat the kludge. What do other people do? Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Sun Jan 8 13:17:47 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24158>; Sun, 8 Jan 1995 13:15:27 -0500 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.11) via UUCP id AA28959 ; Sun, 8 Jan 95 13:15:22 -0500 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Sun, 8 Jan 95 12:51 EST Message-Id: From: arnold@skeeve.atl.ga.us Date: Sun, 8 Jan 1995 12:51:55 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: latest 9menu 9menu 1.3 is available in ftp.cc.gatech.edu:/people/arnold/9menu-1.3.shar.gz. It fixes some portability problems with SIGCHLD (At least, I hope it fixes them). Enjoy, Arnold From sam-fans-owner Sat Jan 14 01:56:44 1995 Received: from lore.plan9.cs.su.oz.au ([129.78.96.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24001>; Sat, 14 Jan 1995 01:55:47 -0500 Date: Sat, 14 Jan 1995 16:41:56 -0500 From: dhog@plan9.cs.su.oz.au (David Hogan) To: plan9-fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: 9wm: version 1.1 now available Message-Id: <95Jan14.015547est.24001@hawkwind.utcs.utoronto.ca> A new version of 9wm is now available. This fixes most of the bugs that have been reported. (The major exception is that multi-screen displays are still unsupported). The problem with popups of Open Look clients not appearing has been resolved. The new version may be obtained by anonymous ftp from ftp.cs.su.oz.au, in directory /usr/ftp/dhog/9wm. Get patch1.Z if you already have version 1.0, otherwise get 9wm-1.1.shar.Z. Thanks to all the people who contributed bug reports and fixes. From sam-fans-owner Thu Jan 19 01:46:45 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24004>; Thu, 19 Jan 1995 01:45:23 -0500 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.11) via UUCP id AA01336 ; Thu, 19 Jan 95 01:45:11 -0500 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Wed, 18 Jan 95 22:02 EST Message-Id: From: arnold@skeeve.atl.ga.us Date: Wed, 18 Jan 1995 22:02:21 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: X11R6? Greetings. I've been wondering if X11R6 has enough new stuff / performance enhancements to be worth the switch? I have a Sun IPC (low end sparc) at home with X11R5 fully patched (NOT OpenWindoze), and the performance is OK. Is R6 worth the trouble to get, compile overnight, rebuild sam/9term/9wm, and in general switch? I have the latest gcc, if that makes a difference in the performance. Thanks, Arnold From sam-fans-owner Thu Jan 19 02:31:21 1995 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24005>; Thu, 19 Jan 1995 02:31:01 -0500 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12685>; Thu, 19 Jan 1995 02:30:34 -0500 To: arnold@skeeve.atl.ga.us cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: X11R6? In-reply-to: Your message of "Wed, 18 Jan 1995 22:02:21 EST." Date: Thu, 19 Jan 1995 02:30:21 -0500 From: Scott Schwartz Message-Id: <95Jan19.023034est.12685@galapagos.cse.psu.edu> | Greetings. I've been wondering if X11R6 has enough new stuff / performance | enhancements to be worth the switch? It's definately bigger and not noticably faster. The most concrete advantages are that the fonts are somewhat nicer and the font server works a little better, and it supports the Sun type 5 keyboard properly. (Properly means all the keys have keysyms bound, and there are keysyms like SunXK_VideoLowerBrightness to go with the new keys.) | Is R6 worth the trouble to get, compile overnight, rebuild sam/9term/9wm, | and in general switch? How bored are you feeling? :-) From sam-fans-owner Thu Jan 19 18:37:54 1995 Received: from ugw.utcc.utoronto.ca ([128.100.102.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24005>; Thu, 19 Jan 1995 18:36:43 -0500 Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by ugw.utcc.utoronto.ca with SMTP id <8903>; Thu, 19 Jan 1995 18:36:14 -0500 Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A7621GAC@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 8059; Fri, 20 Jan 1995 00:35:27 +0100 Date: Thu, 19 Jan 1995 18:32:40 -0500 From: Werner Lemberg Subject: Announcing CJK 2.5 (Chin/Jap/Kor for LaTeX2e) To: unicode@unicode.org, soft-authors@ifcss.org, ctan-ann@shsu.edu, linux-asia@orac.iinet.com.au, sam-fans@hawkwind.utcs.toronto.edu Message-Id: <95Jan19.183614est.8903@ugw.utcc.utoronto.ca> This is the LaTeX2e style package CJK Version 2.4 (3-Jan-1995) =============================================================== It contains the following files: history.txt Package history CJK.txt This file CJK.sty A LaTeX2e style file to enable CJK (Chinese/Japanese/Korean) logographs (i.e. Hanzi/Kanji/Hangul) with LaTeX2e CJK.enc Master Encoding File standard.enc Bg5.enc Bg5pp.enc KS.enc utf8.enc pmCsmall.enc pmCsmpp.enc pmCbig.enc Encoding scheme files Bg5.chr standard.chr hangul.chr utf8.chr pmC.chr Character encoding files Bg5conv.tex preprocessor for Big 5 encoded text files bg5latex.bat a batch file (for DOS) to demonstrate use of Bg5conv.tex CNS.sty CNS.enc CNS.chr CNS encoding to be used together with a different CJK encoding following Christian Wittern's CEF (Chinese Encoding Framework) UBg5.fd UGBs.fd UGBt.fd Font definition files for Chinese (examples only!) UJIS.fd Font definition file for Japanese (example only!) Uhangul.fd Font definition file for standard Hangul fonts Uhanja.fd Font definition file for Hanja font (example only!) Uutf8.fd Font definition file for Unicode font (example only!) UpmC-Bg5.fd UpmC-GBs.fd UpmC-GBt.fd UpmC-JIS.fd UpmC-KS.fd Font definition files for (old) pmC-fonts UCNS-1.fd UCNS-2.fd UCNS-3.fd UCNS-4.fd UCNS-5.fd UCNS-6.fd UCNS-7.fd Font definition files for CNS fonts (examples only!) vf/*.vf tfm/*.tfm virtual fonts and metric files for hangul standard fonts to use in combination with the font libraries lj_han and lj_han1 (available at the CTAN hosts) utils/hbf2gf.w CWEB source file for hbf2gf utils/hbf2gf.c C code file extracted from the CWEB source files utils/hbf2gf.dvi Documentation extracted from the CWEB source files utils/hbf2gf.cfg Configuration file example utils/hbf2gf.exe Bound executable for DOS and OS/2 utils/hbf.h utils/hbf.c Ross Paterson's HBF API (with small extensions) utils/Makefile Makefile for hbf2gf utils/emx.exe utils/emx.dll utils/rsx.exe Runtime binaries for DOS and OS/2 (must be in the path) This is freely distributable under the GNU Public License. Use --- Use CJK.sty as a package, e.g. \documentclass{article} \usepackage{CJK} . Two new environments \begin{CJK}{encoding}{shape} ... \end{CJK} and \begin{CJK*}{encoding}{shape} ... \end{CJK*} are defined: encoding the following encodings are currently implemented in CJK.enc (for CNS encoding see below): Bg5 (Big 5) GBs (GuoBiao with simplified characters, G1 = GB 2312-80) GBt (GuoBiao with traditional characters, G1 = GB 12345-90) JIS (Japanese Industry Standard, G1 = JIS X0208-1990) KS (hangul and hanja, G1 = KSC 5601-1987) utf8 (UTF 8 (Unicode Transformation format 8), also called UTF 2 or FSS-UTF) The encodings (except Big 5 and UTF 8) are simplified EUC (Extended UNIX Code) character sets without single shifts. The character set slot G1 stands for two byte encodings with byte values taken from the GR (Graphic Right) character range 0xA1-0xFE (as defined in ISO 2022). For compatibility with the pmC package these additional encodings are defined: pmC-Bg5, pmC-GBs, pmC-GBt, pmC-JIS, and pmC-KS. It's not encouraged to use these encodings because of wasting fonts. If possible, convert your original CJK-bitmaps with hbf2gf (see below) to CJK-encodings. shape It is impossible to know what fonts are available at your site; look at the example .fd-files how to create appropriate .fd-files suiting your needs. If you use the KS environment, this parameter is unused (see below). The CJK* environment will swallow unprotected spaces and newlines after a CJK character, whereas CJK will not. This is a very realistic example: \begin{CJK*}{GBs}{kai} ... Text in GuoBiao encoding ... \end{CJK*} How it works ------------ Asiatic logographs can't be represented with one byte per character. (At least) two bytes are needed, and the most common encoding schemes (GB, Big 5, JIS, KS etc.) have a certain range for the first byte (usually 0xA1-OxFE or a part of it) which signales that this and the next byte represents an Asiatic logograph. This means that plain ASCII-text (i.e. characters between 0x00 and 0x7F) will be left undisturbed, and most characters of the extended ASCII character set (0x80-0xFF) will be assigned to a CJK encoding. Due to the internal architecture of TeX it is impossible to support ISO 2022 escape sequences as used with MULE (Multi Language Emacs). MULE is a common extension of GNU-Emacs to support many non-English scripts, including Chinese, Japanese, Korean, Hebrew etc. CJK.sty will make the characters 0xA1-OxFE active inside of an environment and assigns the macros \CJK@char and \CJK@charx to the active characters which select the proper font. The real mechanism is a bit more complicated to assure robustness (it was borrowed and modified from german.sty) and correct handling of punctuation characters. The encodings ------------- CJK.sty defines internally \CJK@standardEncoding, \CJK@Bg5Encoding, \CJK@KSEncoding, \CJK@utf8Encoding, and for compatibility with pmC, \CJK@pmCsmallEncoding and \CJK@pmCbigEncoding. \CJK@standardEncoding will be used for encodings with the second byte in the range 0xA0-0xFE (GB, JIS). \CJK@Bg5Encoding will be used for Big 5 encoding (e.g. NTU fonts) with the second byte in the range 0x40-0xFE. \CJK@KSEncoding will be used for KS encoding. Two sets of subfonts are defined, one for Hangul syllables and elements, and a second for Hanja. For more details see below. \CJK@utf8Encoding will be used for Unicode in UTF 8. The first byte is in the range 0xC0-0xDF for two byte values and in the range 0xE0-0xEF for three byte values. The other bytes are in the range 0x80-0xBF. Note that CJK expects two hexadecimal digits as a running number in the font name instead of two decimal digits. Use the option `unicode on' if you use hbf2gf to transform bitmap fonts in HBF format to .pk fonts as used by CJK.sty . \CJK@pmCsmallEncoding and \CJK@pmCbigEncoding can be activated with \pmCsmall (this is the default) and \pmCbig inside the CJK environment. Note that the original pmC fonts have two character sizes per font (the bigger ones with an offset of -128); pmC-Big 5 encoded fonts cannot contain big characters. The names of the fonts in the UpmC-xxx.fd files reflect the modifications added by Marc Leisher to the original poor man's Chinese (pmC) package written by Thomas Ridgeway . The fonts --------- CJK.sty uses NFSS (New Font Selection Scheme, now part of LaTeX2e) which has some advantages over the font selection offered with pmC (for plain TeX and LaTeX 2.09): o TeX fonts are loaded only on demand. This is especially useful with Asiatic logographs. If you have e.g. three Chinese characters in your text, pmC must load the whole Chinese font (about 85 TeX fonts), whereas LaTeX2e loads only three fonts normally. o As long as the limit of 256 TeX fonts will not be exceeded, you can use as many CJK fonts as you like (e.g. simplified and traditional Chinese characters together with Japanese fonts in different sizes) --- pmC is limited to two sizes and can only have two CJK fonts at the same time. In the web2c-TeX package (for UNIX) you will find a patch which allows the use of more than 256 TeX fonts. o You need not to care about the right size of CJK fonts in footnotes etc. They will obey the NFSS (although changing other attributes except font series and size will be done with \CJKenc and \CJKshape). For Hangul font selection see below. Of course you must have access to bitmap CJK fonts --- use hbf2gf to convert them to .pk-fonts. See the last section for availability of precompiled fonts. If you chose one font per active character as with the pmC macros, you would waste character space (256 characters per font are possible with TeX 3). Therefore CJK.sty expects the whole Asiatic font splitted in TeX subfonts with 256 characters each. An example: GuoBiao-encoded simplified characters in song style at 12pt: ^ ^ ^^ ^^ first byte second byte TeX font offset ---------------------------------------------- 0xA1 0xA1-OxFE gsso1201 0 0xA2 0xA1-0xFE gsso1201 94 0xA3 0xA1-0xE4 gsso1201 188 0xA3 0xE5-0xFE gsso1202 0 0xA4 0xA1-0xFE gsso1202 26 0xA5 0xA1-0xFE gsso1202 120 . . . 0xFE 0xA1-OxFE gsso1235 38 For converting to .pk-files with hbf2gf, you must get the appropriate HBF (Hanzi Bitmap Font) header files from ifcss.org (or create if you can't find the right one); almost all Chinese bitmap fonts in the public domain together with their HBF headers are collected there. These HBF files document CJK fonts completely. Using hbf2gf ------------- hbf2gf converts CJK bitmaps with an HBF header file into .gf-files (and consequently into .pk fonts). Syntax: hbf2gf configuration_file Keywords in the configuration file must start a line, the appropriate values being on the same line separated with one or more blanks or tabs. Here is an example configuration file jfs56.cfg (please refer to hbf2gf.dvi for a description of the keywords): hbf_header jfs56.hbf mag_x 1.482 x_offset 3 y_offset -8 comment jianti fansongti 56x56 pixel font magnified and adapted for 10pt nmb_files -1 output_name gsfs10 checksum 123456789 dpi_x 600 dpi_y 600 coding codingscheme GB 2312-80 encoded TeX text pk_directory d:\china\pixel.ljh\600dpi\ tfm_directory d:\china\tfm\ rm_command del cp_command copy long_extension off job_extension .cmd And here the results: input files: jfs56.a - jfs56.e, jfs56.hbf program call: hbf2gf jfs56.cfg intermediate files: gsfs10.cmd, gsfs1001.gf - gsfs1032.gf, gsfs10.pl batch file call: gsfs10.cmd output files: d:\china\pixel.ljh\600dpi\gsfs1001.pk - gsfs1032.pk, d:\china\tfm\gsfs1001.tfm - gsfs1032.tfm [gsfs: GuoBiao simple encoded FanSong style ^ ^ ^ ^ It's hard to overcome the DOS restriction of 8 characters in a file name if you need two characters as a running number...] This would be a correct entry in UGBs.fd: \DeclareFontShape{U}{GBs}{m}{fansong}{ <-10> CJKfixed * gsfs10 <10> sCJKfixed * gsfs10 <10.95> sCJKfixed * gsfs12 <12> sCJKfixed * gsfs12 <14.4> sCJKfixed * gsfs14 <17.28> sCJKfixed * gsfs17 <20.74-> CJKfixed * gsfs17}{} assuming that you have created fonts for 10, 12, 14.4, and 17.28pt. Korean input ------------ (The status of this feature is experimental. I can't speak Korean and would be glad to hear comments from people who have any idea what is happening here :-) There are already different packages handling Hangul: hlatex, htex etc.; there is one package which also can handle hanja: jhtex. The great difference of the packages just mentioned compared to CJK is the use of a preprocessor which converts text files containing KS encoded text into a TeX file. To do so has some advantages, but the output is completely unreadable. Additionally the output lines become rather lengthy (a two byte character code will be converted into a string up to 11 characters long), which may confuse some editors; and if you have a text which contains Chinese or Japanese also, you can't use KS to TeX converters because the code ranges overlap and converters are not able to recognize which is Korean and which is not. In contrast, CJK does not need a preprocessor and the problems mentioned above are nonexistent, but you get nothing for free: CJK uses the virtual font mechanism to map the hangul syllables onto Hangul Elements (11 virtual fonts map to 2 real fonts), whereas preprocessors directly use the real fonts. If you want a complete Korean environment, I recommend jhtex. There you will also find a hangul.sty which modifies (among others) the sectioning commands to enable Korean chapter counting and Korean headers. To use KS encoding, say \begin{CJK}{KS}{} ... \end{CJK} . These font switches are available inside the environment: fonts from hLaTeX: * \mj MyoungJo (default) \gt Gothic \gs BootGulssi \gr Graphic \dr Dinaru fonts from jhTeX: * \hgt Hangul Gothic * \hmj Hangul MyoungJo (MunHwaBu fonts) * \hpg Hangul Pilgi \hol Hangul Outline (MyoungJo) If a font is marked with a star, bold series are available. You will find the hangul fonts in the lj_han and lj_han1 packages. These are emTeX libraries for 300 dpi resolution which can be easily converted back to .pk fonts using the fontlib package of emTeX. If you need different resolutions, you must obtain the original metafont sources of the hlatex_mf.tar.gz and the jhtex packages. Note that the shapes of Hangul elements are not satisfactory. You find the needed virtual fonts and virtual metric files in the vf and tfm directories. Move the .tfm files into a directory TeX will scan. You need a dvi driver which understands virtual fonts -- move the .vf files into a directory your dvi driver will scan. For non-hangul characters inside the KS environment (i.e. the first byte in the ranges 0xA1-0xAF except 0xA4 and 0xC9-0xFD), fonts are taken from Uhanja.fd . This enables the use of many hangul fonts and perhaps only one or two different hanja fonts. If you don't want the overlay of hangul fonts from Uhangul.fd, say \CJKhanja. The opposite command is \CJKhangul. Archaic hangul elements (KS 0xA4D5-0xA4FE) and the character KS 0xA4D4 are only accessible if \CJKhanja is active. You should convert your KS hanja fonts using hbf2gf as described above. Bg5conv.tex ----------- Using the Bg5text environment is a mess. Having an external preprocessor needs access to a compiler, which is not always the case. Thus I wrote Bg5conv.tex, a preprocessor for Big 5 characters to overcome the restrictions of the Bg5text environment. Each Big 5 character `XY' will be converted into the form `XZZZ.'; ZZZ is a decimal number followed by a dot. The use of Bg5conv.tex is completely transparent, no changes to your document are necessary. The use is simple: before calling Bg5text you must define \CJKin (and optionally \CJKout); after conversion the output file will be processed like a normal input file. Bg5conv.tex inserts additionally the (empty) macro \CJKpreproc as the first line of the output. Here is an example batch file (bg5latex.bat) for DOS which demonstrates the use of Bg5conv.tex . Note that you must not use an extension for the input file here (I am too lazy to write a sophisticated shell program - any volunteers are welcome) (default names for \CJKin and \CJKout are `Bg5input.tex' and `Bg5input.cjk' respectively): call latex \def\CJKin{%1} \def\CJKout{%1.cjk} \input Bg5conv.tex call latex %1.cjk You say bg5latex mytext to get mytext.tex processed. It's not possible to mix Big 5 encoding with different encodings (except CNS) if Bg5conv.tex is used (and I doubt whether this should be ever necessary). CNS.sty ------- (The status of this feature is experimental.) Christian Wittern develops CEF, the Chinese Encoding Framework. This will enable the use of Big 5 as the primary encoding with CNS 11643-1992 as a secondary character set for characters not included in Big 5. Inputting CNS characters into a text will be done with a data base. To facilitate this, the first bytes of the three byte CNS encoding are mapped onto the characters 0x81-0x87. Say \usepackage[options]{CNS} to use CNS (CJK.sty will be loaded automatically). If you need to specify options for CJK, say \usepackage[options]{CJK} \usepackage[options]{CNS} The possible options for CNS.sty are `compressed' and `uncompressed' to indicate the use of compressed (256 characters per font a la CJK.sty) or uncompressed fonts (94 characters per plane as in pmC). Default is compressed. CNS encoding is available only in CJK environments; the commands \CNSchar (of course with three parameters for byte 1 to 3) and \CNSshape are similar to their CJK counterparts. Default value of \CNSshape is `song'. Uncompressed fonts should be named equal to pmC fonts (font names ending with hex numbers). The .fd-files ------------- CJK fonts can be installed as easy as normal TeX fonts! CJK.sty defines four new size commands: CJK corresponds to `' (empty) sCJK corresponds to `s' CJKfixed corresponds to `fixed' sCJKfixed corresponds to `sfixed' . The difference between these size functions and the original commands defined by LaTeX2e is that a CJK size function defines a class of fonts. If you say as an example \DeclareFontShape{U}{Bg5}{m}{song}{<6> <7> <8> sCJKfixed * b5so07}{} , LaTeX2e searches for fonts named b5so0701 - b5so0758 if the font size is 6, 7 or 8 pt; with other words, the CJK size functions append two digits to select the proper subfonts. These digits are defined in the \CJK@...Encoding macros; the macro \CJK@plane holds the current value (in pmC compatibility mode, \CJK@plane holds hexadecimal numbers). See the example .fd files how to define font substitutions additionally. Caveats ------- o You can of course use CJK-environments inside of a CJK-environment, but it is possible that you must increase the so called save size (with emTeX you can adjust this with -ms=...). The CJK package has optional arguments which controls the scope of CJK environments: lowercase If you want to use \lowercase with encodings inside CJK environments. You need less save size using the `encapsulated' option if `lowercase' is not set. You must use Bg5conv.tex to use Big 5 characters with this option. global \lccode (if `lowercase' set), \uccode, \catcode and the activation of the characters 0xA1-0xFE will be globally modified (\lccode and \uccode reset to 0). This is the most economical mode concerning save size, but you can't have CJK environments inside of CJK environments or other environments which manipulate the character range 0xA1-0xFE. Packages which change some of the above values only once (e.g. in the preamble) will also not work after the first use of a CJK environment. local Only \lccode (if `lowercase' set) and \uccode will be modified globally. This is the default. You can stack environments. encapsulated If you want to use DC fonts outside of the CJK environment with \uppercase and \lowercase working correctly, you must use this option. All values mentioned above will be local, so you can stack environments. This option probably causes an overflow of the save size. Say \usepackage[option]{CJK} to activate `option'. o There is an other way to overcome the problem of stacked environments. CJK implements two low level CJK attribute switches: \CJKenc and \CJKshape, which take the same arguments as the corresponding values of the CJK environment. If you need two different encodings/shapes at the same output line, you must use these macros. An example: \begin{CJK}{GBs}{song} ... Text in GBs song ... \CJKenc{GBt} ... Text in GBt song ... \CJKshape{kai} ... Text in GBt kai ... \end{CJK} Contrary to \begin{CJK}{...}{...} it's not necessary to start a new line after \CJKenc. o The characters \, {, and } are used as second bytes in the Big 5 encoding. If you write Big 5 text mixed with other encodings, you should use the Bg5text environment which changes the category codes of these characters. The command prefix is now the forward slash `/', and the grouping characters are `(' and `)' respectively. An example: \begin{CJK}{Bg5}{song} \begin{Bg5text} .... /begin(center) .... /end(center) .... /end(Bg5text) \end{CJK} To get the `/', `(', and `)' characters, write `//', `/(', and `/)' inside the Bg5text environment. This environment is ugly, and some commands like \newcommand will not work in it. o Instead of using the Bg5text environment you can protect the offending second bytes with a backslash, i.e. \{, \}, \\ (using a non- Chinese editor). This will not increase the readability of the Chinese text, but for short texts it's perhaps more comfortable. Alas, it doesn't work in page header commands because the macros \{ etc. will not be expanded. o Be careful not to use any commands inside the Bg5text environment which write something into an external file (commands like \chapter etc.). o If it's not possible to avoid Big 5 character codes with \, {, or } outside of the Bg5text environment (e.g. having Big 5-text in a \chapter or \section command), you can replace them with the \CJKchar macro manually: \section{This is a problematic Big 5 character: \CJKchar{169}{92}} The parameters are the first and second byte of the Big 5 character code. You can also use hexadecimal or octal notation. o A similar command is \Unicode{byte1}{byte2} to access Unicode characters (not in UTF 8) directly; the parameters are the first and second byte of the Unicode. o CJK will disable \uppercase (preserving the command as \CJKuppercase) if you select Big 5 encoding without using Bg5conv.tex . This affects the headers of the standard classes and \Roman only in standard LaTeX2e. Be aware that some packages and style files may use \uppercase for dirty tricks (e.g. to define macros for active characters). o \uppercase and \lowercase will work with NONE of the CJK encoding schemes if you use DC fonts because these 8-bit fonts have most \lccode's and \uccode's set in the range 0x80-0xFF. o You should define for each TeX font size a CJK font (as an example, use sCJKfixed for good sizes and CJKfixed for bad sizes, and LaTeX2e will complain loudly about wrong sizes on the screen). LaTeX2e will also do the job if some size definitions are missing (using defined sizes), but expect a font warning for each (!) CJK character affected under certain circumstances. Possible errors --------------- o If you write Chinese (or Japanese) text, don't forget to suppress the linefeed character with a trailing `%' in the CJK environment, otherwise you get unwanted spaces in the output. On the other side, say `\ ' or something similar inside the CJK* environment to get a space after a CJK character. o To prevent a line break before a CJK character (e.g. between an opening (non-CJK) parenthesis and a CJK character), say \CJKkern. This command prevents the insertion of \CJKglue before the CJK character. You may wonder about the curious name: a small kern (1 sp) between two CJK characters signales that the first one is a punctuation character. o If you get the error message: "\CJK@min (or \CJK@max) undefined", you should insert \newpage before saying \end{CJK}. This can happen if LaTeX writes the headers (or footers) of a page containing CJK characters after closing the CJK environment. o If you get overfull hboxes caused by CJK characters, try to increase \CJKglue. It defines the glue between CJK characters; the default definition is \newcommand{\CJKglue}{\hskip 0pt plus 0.08\baselineskip} . \CJKglue will be inserted by CJK before each Chinese character (except punctuation characters as defined in the punctuation tables; see CJK.enc), and none after. You should separate non-Chinese text from CJK characters with spaces to enable hyphenation. o If you get overfull hboxes caused by Hangul syllables, try to increase \CJKtolerance. The default definition is \newcommand{\CJKtolerance}{400} . o If you encounter a TeX stack overflow caused by {\CJKenc{new_encoding} ....}, you should write \CJKenc{new_encoding} ... \CJKenc{old_encoding} instead. Or (better) increase the stack size as discussed above. How to get CJK and related software ----------------------------------- o You will find CJK and software related to TeX at the CTAN hosts (Comprehensive TeX Archive Network). These completely identical ftp servers (concerning TeX software) are ftp.shsu.edu Sam Houston University Texas (USA) ftp.dante.de DANTE (Deutsche Anwendervereinigung fuer TeX) Heidelberg (Germany) ftp.tex.ac.uk Cambridge University Cambridge (England) You should use the nearest one, or even better, a local mirror of a CTAN host. CJK will be found unpacked. To receive the complete package, go to the parent directory of CJK and say get CJK.zip or (whichever is appropriate for your system) get CJK.tar.gz The CJK directory and all subdirectories will be sent to you in compressed form. Be aware that not all mirrors of CTAN sites support compression of directories. o The main site for Chinese related software is ifcss.org (USA). Mirrors are ftp.edu.tw (Taiwan), cnd.org (USA) and kth.se (Sweden). Here you find free Chinese fonts, Text editors etc. Note that while updating this text (3-Jan-1994) ifcss.org has still stopped ftp access due to networking problems. o The main site for Korean related software is cair-archive.kaist.ac.kr (Korea). I don't know any mirror sites of this host. At ifcss.org you will find a 24x24 hanja font with HBF header in /software/fonts/misc/hbf. o Sam Chiu compiled the fonts jfs56 (GBs encoded) and ntu_kai48 (Big 5 encoded) for various sizes with 600dpi resolution. You will find them (about 22 MByte uncompressed!) at the CTAN hosts in /tex-archive/fonts/chinese Author ------ Werner Lemberg Goldschlagstr. 52/14 A-1150 Vienna Austria/Europe Please report any errors or suggestions to this email-address. From sam-fans-owner Thu Jan 19 18:56:49 1995 Received: from ugw.utcc.utoronto.ca ([128.100.102.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24005>; Thu, 19 Jan 1995 18:55:40 -0500 Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by ugw.utcc.utoronto.ca with SMTP id <8801>; Thu, 19 Jan 1995 18:55:24 -0500 Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A7621GAC@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 8555; Fri, 20 Jan 1995 00:54:59 +0100 Date: Thu, 19 Jan 1995 18:53:59 -0500 From: Werner Lemberg Subject: Addendum to CJK 2.4 (!) To: unicode@ifcss.org, linux-asia@orac.iinet.com.au, ctan-ann@shsu.edu, sam-fans@hawkwind.utcs.toronto.edu Message-Id: <95Jan19.185524est.8801@ugw.utcc.utoronto.ca> I just have uploaded the newest version of CJK to ftp.tex.ac.uk . It should be available soon in tex-archive/languages/chinese/CJK on all CTAN hosts (ftp.dante.de, pip.shsu.edu, ftp.tex.ac.uk) and its mirrors. In a separate posting you will find a complete description of CJK. Happy TeXing! Werner ============================================================================== Version 2.4: new: 3-Jan-1995 UTF 8 (Unicode) scheme added. option `unicode' to hbf2gf added: if `on', a two-digit hexadecimal number will be used as a running number starting with the value of the first byte of the first code range. Bg5conv.tex added: this is a small preprocessor which converts Big 5 encoded characters `XY' into the form `XZZZ.' . Now you can use Big 5 encoding without the annoying Bg5text environment. Auxiliary files: Bg5pp.enc, pmCsmpp.enc, and bg5latex.bat . changed: new versions of emx.exe, emx.dll (ver. 0.9a) and rsx.exe (rel. 5) errors: hbf2gf sometimes drew one pixel too much (You Rey-Jer ). pmC encodings didn't work (Zhang Zhengyou ). \CJK@charToHex and \CJK@numbToHex could erroneously change page counter (Li Yu-Ray ). From sam-fans-owner Tue Feb 7 08:18:26 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24011>; Tue, 7 Feb 1995 08:14:44 -0500 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA01143; Tue, 7 Feb 95 13:15:24 GMT Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA27750; Tue, 7 Feb 1995 13:18:09 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA06143; Tue, 7 Feb 1995 12:59:20 +0000 Date: Tue, 7 Feb 1995 07:59:20 -0500 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9502071259.AA06143@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term/9wm hacks Content-Length: 2274 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 I've been playing with some small hacks to 9term and 9wm which I thought I'd mention to the list, since they might be of interest. Basically, I was wondering how some of the characteristics of 8½ and Help could be implemented using the existing arrangement. Basically I was after some level of programmability without having to change the tools much (or do much work:-)). In 9term, I've implemented command inputs via a pipe, similar to the command pipe sam uses. Each 9term creates a named pipe with the name /tmp/.9terms.$USER.$DISPLAY/$WINDOWID. Characters read from this pipe get sent to the shell, and also appear on the screen. The directory that the pipes are created in is mode 700, as a nod towards security, but how safe this is, I don't know. In 9wm, each time a window is made current the file /tmp/.9wm-windows is re-written, containing a line for each window. Each line contains . The lines are written in the same order as the window focus list, so the current window is the first line, the previous current window is the second line, and so on. >From here on in, it's just script writing. The most common script determines which 9term was the most recently used, and sends its arguments to that 9term's pipe. Another script is similar, but uses xv_get_sel to determine text that was last snarfed, and uses that in the command. Scripts are normally run from 9menu popped up from the main 9menu. One contains the commands used while producing a document with latex, another has commands often used while building an instance of the current program I'm working on, and a third pops up the last 15 commands from $history, for re-execution. Although I haven't done this, 9menus could be created which send commonly-used commands to the current instance of sam (personally, I don't have many sam commands I use a lot). It's not a perfect system. Security is bound to be a problem, the 9wm file should have a more unique name, and if you send text to a 9term pipe it doesn't currently set dot first, so the text appears in the wrong place. The command still works, though. Finally, the hacks aren't to the most recent version of 9term (they're to 1.3.2, and I know that matty's up to at least 1.5). Comments are welcome. steve From sam-fans-owner Sun Feb 19 11:09:08 1995 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoronto.ca with SMTP id <24014>; Sun, 19 Feb 1995 11:04:37 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.249]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id LAA16942 for ; Sun, 19 Feb 1995 11:04:34 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id LAA03834 for sam-fans@hawkwind.utcs.toronto.edu; Sun, 19 Feb 1995 11:04:32 -0500 Date: Sun, 19 Feb 1995 11:04:32 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199502191604.LAA03834@penfold.cc.gatech.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: article on Plan 9 interface for Unix Greetings. I have placed the original ascii of a two part article I wrote on sam, 9term, 9wm, 9menu, rc and es up for ftp. This article is for Linux Journal. The first part was just published, the second part will come out next month. Most people on the list know all about what's in the article already, but it may be useful to give to others whom you wish to proselytize, er, "help be more productive." (:-) It's available from ftp.cc.gatech.edu in /pub/people/arnold, in the file plan9.interface.for.unix. Enjoy, Arnold From sam-fans-owner Tue Feb 21 14:14:34 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24025>; Tue, 21 Feb 1995 14:08:32 -0500 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyebs26133; Tue, 21 Feb 1995 14:08:26 -0500 Received: from rexago8.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Tue, 21 Feb 1995 14:08:12 -0500 Received: by summitis.com (smail2.5) id AA04687; 21 Feb 95 13:57:31 EST (Tue) Received: from summitis.com by rserv1.summitis.com; Tue, 21 Feb 1995 13:55 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA183124; Tue, 21 Feb 1995 13:52:56 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA17856; Tue, 21 Feb 1995 13:52:54 -0500 From: hc05@summitis.com Message-Id: <9502211852.AA17856@cheetah> Subject: 9menu and sam To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 2208 Date: Tue, 21 Feb 1995 14:08:25 -0500 I read the excellent article on the UNIX Plan 9 tools this weekend and realized that I can extend sam. I understand why basic sam doesn't have macro capability, but there are some things that I do a lot that would be nice to do with the mouse. I use samx2, and wouldn't use sam without it, but while it has macro capability, I'm not big on learning lots of arbitrary key sequences, even my own. For these reasons I've put together a 9menu containing some basic sam commands that I need. When I want one, I go out to the 9wm menu, bring up 9menu, and make my choice. It has made things much easier. I include the script here in case anyone is interested. Some of the specific macros may be useful to others, and some will only be meaningful to me, but I figured I would include some examples. I wrote this in perl because I haven't gotten far enough into the 9 tools to use rc. Beirne ---------------------------------------------------------------------- #!/usr/local/perl ($name) = getpwuid($>); $pipe = '/tmp/.sam.'.$name.'.'.$ENV{'DISPLAY'}; $pipe =~ s/:0$/:0\.0/; $pipe =~ s/\.0$// if (! -r $pipe); exit if ($pipe =~ /^\s*$/); $ENV{'SAMPIPE'} = $pipe; exec "9menu", "-label", "sam menu", "-popdown", "-iconic", "-geometry", "+0+0", 'dashed line:echo "i/----------------------------------------------------------------------\\\\\n" >'.$ENV{'SAMPIPE'}, 'eroff memo template:echo "r $T/ermemo\n,x/Your_name/c/B. Konarski" >'.$ENV{'SAMPIPE'}, 'eroff preview:echo ",>preview" >'.$ENV{'SAMPIPE'}, 'eroff print:echo ",>tbl -D | eroff -mm -mr" >'.$ENV{'SAMPIPE'}, 'format:echo "|fmt" >'.$ENV{'SAMPIPE'}, 'shift left:echo "x/^ /d" >'.$ENV{'SAMPIPE'}, 'shift right:echo "x/^/a/ /" >'.$ENV{'SAMPIPE'}, 'spell:echo ",|cspell" >'.$ENV{'SAMPIPE'}, "exit" ---------------------------------------------------------------------- -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Wed Mar 8 12:33:34 1995 Received: from drizzle.Stanford.EDU ([36.59.0.16]) by hawkwind.utcs.utoronto.ca with SMTP id <24048>; Wed, 8 Mar 1995 12:27:00 -0500 Received: (castor@localhost) by drizzle.Stanford.EDU (8.6.8/8.6.4) id JAA18686 for sam-fans@hawkwind.utcs.toronto.edu; Wed, 8 Mar 1995 09:30:40 -0800 From: Castor Fu Message-Id: <199503081730.JAA18686@drizzle.Stanford.EDU> Subject: sam or tk bug? To: sam-fans@hawkwind.utcs.toronto.edu Date: Wed, 8 Mar 1995 12:30:40 -0500 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 983 I've started using sam on RS 6000's recently and have been getting the following error relatively often (3 times in the past two days): Xlib: sequence lost (0x10006 > 0xfcb) in reply type 0x0! X Error of failed request: 0 Major opcode of failed request: 0 () Serial number of failed request: 6 Current serial number in output stream: 4043 Then samterm exits. Has anyone seen this before? I think this might be connected with a Tk tool which I hacked together. It provides some of the functionality of emacs's M-x compile, by searching the results of a 'make' for errors, and sending in sam commands through the named pipe. It also has hooks for the AT&T Toolchest 'cscope' program, to provide source browsing capability. To make it more useful, it would be nice to have easier X selection features in 'sam'. I think there were some chording patches a while back. Maybe those would be most appropriate? I guess I'll have to dig through the archives. -castor From sam-fans-owner Wed Mar 8 13:23:32 1995 Received: from ssec.ssec.wisc.edu ([144.92.108.61]) by hawkwind.utcs.utoronto.ca with SMTP id <24048>; Wed, 8 Mar 1995 13:22:33 -0500 Received: from localhost by ssec.ssec.wisc.edu; id AA84430; AIX 3.2/UCB 5.64/42; Wed, 8 Mar 1995 12:22:00 -0600 Message-Id: <9503081822.AA84430@ssec.ssec.wisc.edu> To: Castor Fu Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam or tk bug? In-Reply-To: Your message of "Wed, 08 Mar 1995 12:30:40 EST." <199503081730.JAA18686@drizzle.Stanford.EDU> Date: Wed, 8 Mar 1995 13:21:51 -0500 From: "DaviD W. Sanderson" Castor Fu wrote: # I've started using sam on RS 6000's recently and have been getting # the following error relatively often (3 times in the past two days): # # Xlib: sequence lost (0x10006 > 0xfcb) in reply type 0x0! This is probably a bug in your X server. We encountered it when we upgraded to AIX 3.2.5. There is a patch available from IBM. Here is an extract of some instructions we sent our customers: McIDAS-X sites using IBM RISC System/6000 workstations running AIX version 3.2.5 may elect to apply the IBM Program Temporary Fix (PTF) U425811 or U424375 to lpp package X11rte.obj.1.2.3. The lpp correction package U425811 replaces package U424375. [...] Users may see the problem at random intervals. When it occurs, an error message similar to the one shown below is displayed. Xlib: sequence lost (0x10000 > 0x103) in reply type 0x0! You can tell if you have the U425811 or U424375 PTF installed by doing lslpp -h -c | egrep 'U425811|U424375' It should print out something like /usr/lib/objrepos:X11rte.obj:U425811:01.02.0003.0000:COMPLETE:APPLY:07/14/94:08;31;11:root /etc/objrepos:X11rte.obj:U425811:01.02.0003.0000:COMPLETE:APPLY:07/14/94:08;37;37:root DaviD W. Sanderson dws@ssec.wisc.edu Space Science and Engineering Center University of Wisconsin-Madison "The Noah Webster of smileys" - The Wall Street Journal, 15 Sep 1992 From sam-fans-owner Wed Mar 8 14:13:10 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24048>; Wed, 8 Mar 1995 14:12:30 -0500 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQygfc12677; Wed, 8 Mar 1995 14:12:24 -0500 Received: from rexago8.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 8 Mar 1995 14:12:09 -0500 Received: by summitis.com (smail2.5) id AA13908; 8 Mar 95 13:43:07 EST (Wed) Received: from summitis.com by rserv1.summitis.com; Wed, 8 Mar 1995 13:40 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA62610; Wed, 8 Mar 1995 13:40:28 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA20542; Wed, 8 Mar 1995 13:40:27 -0500 From: hc05@summitis.com Message-Id: <9503081840.AA20542@cheetah> Subject: sam or tk bug? To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 1233 Date: Wed, 8 Mar 1995 14:12:20 -0500 > >I've started using sam on RS 6000's recently and have been getting >the following error relatively often (3 times in the past two days): > > Xlib: sequence lost (0x10006 > 0xfcb) in reply type 0x0! > X Error of failed request: 0 > Major opcode of failed request: 0 () > Serial number of failed request: 6 > Current serial number in output stream: 4043 > >Then samterm exits. Has anyone seen this before? I used to get a lot of X errors like this in sam on the RS/6000, but I don' anymore. I never figured out for sure why, but I think getting X11R5 helped me (we were on X11 R4 for a long time). In any case, I can't remember the last time it died on me. It could be a sam version issue too. Unfortunately I don't know how to tell what version I have. I think it is the one before the recent release, with the samx2 patches added in. Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Wed Mar 8 19:51:13 1995 Received: from email.nla.gov.au ([192.102.239.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24048>; Wed, 8 Mar 1995 19:50:20 -0500 Received: by email.nla.gov.au id AA105571 (5.65c/IDA-1.4.4); Thu, 9 Mar 1995 10:45:44 +1000 From: "Michael F. Ledwidge" Subject: Re: sam or tk bug? To: hc05@summitis.com Cc: Sam mailing list In-Reply-To: <9503081840.AA20542@cheetah> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 8 Mar 1995 19:50:08 -0500 On Wed, 8 Mar 1995 hc05@summitis.com wrote: > > > >Then samterm exits. Has anyone seen this before? > > I used to get a lot of X errors like this in sam on the RS/6000, but I > don' anymore. I never figured out for sure why, but I think getting > X11R5 helped me (we were on X11 R4 for a long time). In any case, I > can't remember the last time it died on me. It could be a sam version > issue too. Unfortunately I don't know how to tell what version I have. I > think it is the one before the recent release, with the samx2 patches added > in. > Where is the latest release kept? Our RS6000 binary has always being shaky and it has a lot of trouble with spurious control characters. Actually, just checking, we're still using Version 3. Pointers please! Thanx, .M. *********************************************************************** Michael Ledwidge National Library of Australia From sam-fans-owner Fri Mar 10 16:33:05 1995 Received: from halon.sybase.com ([192.138.151.33]) by hawkwind.utcs.utoronto.ca with SMTP id <24051>; Fri, 10 Mar 1995 16:27:38 -0500 Received: from sybase.com (sybgate.sybase.com) by halon.sybase.com (5.0/SMI-SVR4/SybFW4.0) id AA04090; Fri, 10 Mar 1995 07:27:09 -0800 Received: from constantine.sybgate.sybase.com by sybase.com (4.1/SMI-4.1/SybH3.4) id AA13313; Fri, 10 Mar 95 07:25:02 PST Received: by constantine.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.2) id AA20483; Fri, 10 Mar 95 15:25:00 GMT Date: Fri, 10 Mar 1995 10:25:00 -0500 From: mgm@sybase.com (Mike McKenna) Message-Id: <9503101525.AA20483@constantine.sybgate.sybase.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Printing postscript? content-length: 0 Does anyone know how to take a plain-text FSS-UTF file created with sam and print it out to a postscript printer? I can't seem to be able to get the non-ASCII characters to print out correctly. I'm running on Sun/OS 4.1.x. I need to be able to print the accented roman characters used in Eastern Europe, as well as Russian and Greek. I even tried converting them to raw Unicode via tcs, then sending them over to a Windows/NT box, but that didn't work either :-( Thanx for any suggestions! Mike____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Michael G. McKenna mgm@sybase.com Globalisation Architect Global Products Group Mike.McKenna@Sybase.Com Sybase (UK) Limited (+)44 (0)628 597125 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From sam-fans-owner Sun Mar 12 01:20:47 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24053>; Sun, 12 Mar 1995 01:19:14 -0500 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.12) via UUCP id AA15114 ; Sun, 12 Mar 95 01:19:00 -0500 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Sat, 11 Mar 95 23:14 EST Message-Id: From: arnold@skeeve.atl.ga.us Date: Sat, 11 Mar 1995 23:14:27 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: handlebar streamers Does anyone have a good idea as to how hard it would be to get sam/samterm to change the icon name to the current file? That way if I have several samterms running (from, say, different machines) and hidden with 9wm, I can tell by looking at the 9wm menu which one I want to restore. Yet Another Random Thought, Arnold From sam-fans-owner Mon Mar 13 04:23:31 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24054>; Mon, 13 Mar 1995 04:09:22 -0500 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA12315; Mon, 13 Mar 95 08:43:34 GMT Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA01416; Mon, 13 Mar 1995 08:49:32 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA08311; Mon, 13 Mar 1995 08:29:08 +0000 Date: Mon, 13 Mar 1995 03:29:08 -0500 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9503130829.AA08311@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: handlebar streamers Content-Length: 843 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 *What* is this subject about? Arnold writes: > Does anyone have a good idea as to how hard it would be to get sam/samterm > to change the icon name to the current file? Hmm. Shouldn't be *too* difficult - if you want a *really* easy hack, put a call to the icon-setting function in the menu-line creation function. After all, it has to know the name and whether the file is current (ugh!). > That way if I have several > samterms running (from, say, different machines) and hidden with 9wm, I can > tell by looking at the 9wm menu which one I want to restore. Ah, in that case, there's a simpler way - you could do it from outside sam. I don't mean having the icon name changed automatically, but you could use 9term's "label" to change the icon name of samterm. If you wanted, you could also have it send a "b" to sam's pipe. :-) steve From sam-fans-owner Wed Mar 15 02:47:22 1995 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24062>; Wed, 15 Mar 1995 02:45:32 -0500 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Wed, 15 Mar 1995 02:45:17 -0500 To: Sam Fans Subject: MAXFILES, ouch! Date: Wed, 15 Mar 1995 02:45:16 -0500 From: Scott Schwartz Message-Id: <95Mar15.024517est.12684@galapagos.cse.psu.edu> void menuins(int n, uchar *s, Text *t, int m, int tg) { int i; if(nname == MAXFILES) panic("menuins"); Panic? Ouch! That's a pretty harsh penalty for a software tool to exact for exceeding arbitrary limits. (perror then gets to say "Not a tty", or the local equivalent, just before samterm stops being a tty. ☺) From sam-fans-owner Fri Mar 17 08:09:05 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24065>; Fri, 17 Mar 1995 08:07:20 -0500 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA01327; Fri, 17 Mar 95 13:07:01 GMT Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA09852; Fri, 17 Mar 1995 12:03:49 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA03171; Fri, 17 Mar 1995 11:43:12 +0000 Date: Fri, 17 Mar 1995 06:43:12 -0500 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9503171143.AA03171@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: Subject: fixed bug? Content-Length: 530 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 In the version of sam that I'm using, if I do the following: - sam * - think, "hmm, that includes a binary - i'll delete it" - D then sam attempts to open a window on a file. Not only is this not necessarily what I want, but on occasion, it's done this on the file I'm deleting. It's irritating enough, but last night I did this on a 10MB file, and it took *ages*. So, since I consider this a bug, has it been fixed in the latest release? I haven't upgraded yet, since everything else works fine... steve From sam-fans-owner Fri Mar 17 09:11:56 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24065>; Fri, 17 Mar 1995 09:11:33 -0500 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.12) via UUCP id AA26856 ; Fri, 17 Mar 95 09:11:08 -0500 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Tue, 14 Mar 95 09:31 EST Message-Id: From: arnold@skeeve.atl.ga.us Date: Tue, 14 Mar 1995 09:31:21 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu Subject: samx patches? Hi. I just tried uxc.cso.uiuc.edu, the alleged home of the samx patches, anddd could not anonymous ftp login. Can someone mail me the patches, or point me to the location? Thanks, Arnold From sam-fans-owner Fri Mar 17 09:26:36 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24065>; Fri, 17 Mar 1995 09:26:08 -0500 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA02467; Fri, 17 Mar 95 14:25:44 GMT Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA12088; Fri, 17 Mar 1995 14:32:17 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA03277; Fri, 17 Mar 1995 14:11:39 +0000 Date: Fri, 17 Mar 1995 09:11:39 -0500 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9503171411.AA03277@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Subject: fixed bug? Content-Length: 1079 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 rob replied with the following, and asked me to forward it. steve > From rob@plan9.research.att.com Fri Mar 17 14:21 GMT 1995 > From: rob@plan9.research.att.com > To: Steve_Kilbane@cegelecproj.co.uk > Date: Fri, 17 Mar 1995 09:14:41 EST > Subject: Re: Subject: fixed bug? > > when you type a command, it must be to an open file, but not an open window. > i tried what you said and it made no attempt to open a window on the file. > it did, however, load it in. is that a bug? maybe. but not the one you think. > sam needs just *some* file to talk to; give it one, and > D file > will just delete that file. the problem you're having is that sam is grabbing > the first file on your list when you type that command because it wants some > file to be attached to the command (that is very hard to fix, i think); it just > happened to be a big ugly one in your case. find another file first, or make > one with "new", and things will behave well. > > there's talk of mapping acme's buffer management stuff into sam, which > will make sam much faster at loading files. > From sam-fans-owner Fri Mar 17 09:29:30 1995 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24066>; Fri, 17 Mar 1995 09:29:13 -0500 Received: by ux2.cso.uiuc.edu id AA75514 (5.67a/IDA-1.5 for sam-fans@hawkwind.utcs.toronto.edu); Fri, 17 Mar 1995 08:29:24 -0600 Date: Fri, 17 Mar 1995 09:29:24 -0500 From: Ed Kubaitis - CCSO Message-Id: <199503171429.AA75514@ux2.cso.uiuc.edu> To: arnold@skeeve.atl.ga.us, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: samx patches? |Hi. I just tried uxc.cso.uiuc.edu, the alleged home of the samx patches, |anddd could not anonymous ftp login. Can someone mail me the patches, or |point me to the location? Hi. They are in ftp://vixen.cso.uiuc.edu/pub/sam/ You'll get a few rejected hunks in libXg in the latest sam distribution. But the rejected pieces are no longer needed with Matty Farrow's libXg, so ignore the rejections and do the build. Ed From sam-fans-owner Fri Mar 17 09:57:07 1995 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.utoronto.ca with SMTP id <24065>; Fri, 17 Mar 1995 09:56:44 -0500 Received: from sco.sco.COM by relay1.UU.NET with SMTP id QQyhlr28210; Fri, 17 Mar 1995 09:56:20 -0500 Received: from scocan.scocan.sco.COM by sco.sco.COM id ac20171; Fri, 17 Mar 95 6:42:57 PST Received: from bluenote.scocan.sco.COM by scocan.scocan.sco.COM id aa13065; 17 Mar 95 9:51 EST Received: from localhost by bluenote.scocan.sco.COM id aa01558; 17 Mar 95 9:51 EST To: Ed Kubaitis - CCSO Cc: arnold@skeeve.atl.ga.us, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: samx patches? Date: Fri, 17 Mar 1995 09:51:51 -0500 From: Bob Gibson Message-ID: <9503170951.aa01558@bluenote.scocan.sco.COM> | Hi. They are in | | ftp://vixen.cso.uiuc.edu/pub/sam/ | | You'll get a few rejected hunks in libXg in the latest sam distribution. | But the rejected pieces are no longer needed with Matty Farrow's libXg, | so ignore the rejections and do the build. I also found that patch was confused by the fact that libg.h has moved from ~sam/libXg to ~sam/include. From sam-fans-owner Fri Mar 17 11:24:11 1995 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.utoronto.ca with SMTP id <24065>; Fri, 17 Mar 1995 11:23:24 -0500 From: pete@minster.york.ac.uk Date: Fri, 17 Mar 1995 09:16:01 -0500 Message-ID: To: arnold@skeeve.atl.ga.us, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: samx patches? I've got a copy. I'll mail them to Arnold. pete From sam-fans-owner Mon Mar 27 11:21:59 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24071>; Mon, 27 Mar 1995 11:13:05 -0500 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyiwu25327; Mon, 27 Mar 1995 11:12:47 -0500 Received: from rexago8.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 27 Mar 1995 11:12:46 -0500 Received: by summitis.com (smail2.5) id AA04909; 27 Mar 95 10:56:36 EST (Mon) Received: from summitis.com by rserv1.summitis.com; Mon, 27 Mar 1995 10:54 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA57516; Mon, 27 Mar 1995 10:54:26 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA16463; Mon, 27 Mar 1995 10:54:24 -0500 From: hc05@summitis.com Message-Id: <9503271554.AA16463@cheetah> Subject: Editors compendium & sam To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 4232 Date: Mon, 27 Mar 1995 11:12:53 -0500 I just read the editors compendium in comp.editors, which is a tabular comparison of lots of editors, and saw a lot of holes in the sam column. I was going to write to the guy and fill them in, but figured I'd post my views here first to make sure I'm not missing something. I list the items below that were blank in the compendium, with my opinion on the correct answer. I welcome any corrections. I also list a few where I think the compendium is wrong. I added descriptions where I thought they were needed for because the title wasn't clear enough. If anyone wants to see the whole compendium I can send it to them or post it to the list. It is of course also available in comp.editors. Beirne ---------------------------------------------------------------------- Enter ASCII codes by #: Use command '; Mon, 27 Mar 1995 11:46:02 -0500 From: rob@plan9.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Mon, 27 Mar 1995 11:45:07 -0500 Subject: Re: Editors compendium & sam Message-Id: <95Mar27.114602est.24072@hawkwind.utcs.utoronto.ca> it seems that sam doesn't fit their model very well, which doesn't surprise me. one thing they can't encompass is that the mouse language and command language solve different sets of problems. general comments: there is no such thing (in sam as i wrote it, at least) as a sam macro, so i'm not sure what you mean by the word 'macro'. details: Goto column number: It says you can do this, but I don't know how. I know I can put the cursor anywhere I want with the mouse, but don't know how to go to the nth column on a line. sam has no notion of column, only characters. Goto begin next line: ? + Goto begin prev line: ? - Prog lang senstive mode: This says yes, but I don't know of any direct features for this. no Tag search: Yes, with the help of an external program. if the program's not there, does that count? Interactive debugging: No. with acid, the external B command does a nice job. Syntax highlighting: No. it's really 'no', but i don't miss it in C because of the double-clicking rules Binary editor: They give three categories. I think this one is closest: "displays binary characters doesn't do CR/LF conversion on binary files" sam throws away nuls; it can't be used on binary files. Invertcase curr word: A macro could be written to do this. Uppercase curr word: A macro could be written to do this. Lowercase curr word: A macro could be written to do this. command, not macro. Indent selected region: Yes, using a macro. command Srch select region: No. x/pattern/p List all occurances: Yes. occurrences. tell me this is your typo. Internationalization: No. although it works with any character set and is supported with Unicode. Printing: This means "Many editors allow you to print selected text directly to a printer". Yes, with a macro. command From sam-fans-owner Mon Mar 27 12:02:47 1995 Received: from sartre.minerva.bah.com ([156.80.175.13]) by hawkwind.utcs.utoronto.ca with SMTP id <24076>; Mon, 27 Mar 1995 12:00:15 -0500 Received: from pigsnose by sartre.minerva.bah.com (NX5.67d/NX3.0M) id AA05655; Mon, 27 Mar 95 12:01:06 -0500 Date: Mon, 27 Mar 1995 12:01:06 -0500 From: Erik Quanstrom To: Message-Id: <9503271701.AA05655@sartre.minerva.bah.com> Apparently-To: Apparently-To: >Enter ASCII codes by #: Use command ' location. also 0Xnnnn will insert any the utf-8 character of number nnnn at the current location. this is a superset of ascii, so the answer is yes. >Goto column number: It says you can do this, but I don't know how. I know > I can put the cursor anywhere I want with the mouse, but don't know > how to go to the nth column on a line. -/^/+#10 go to 10th column >Goto begin next line: ? +,/^/ (0th postion on next line) but for god sakes, use the mouse. >Goto begin prev line: ? - -,/^/ >Move cursor up by page: yes, using the mouse on the scrollbar. using up on keyboard, too >Move cursor dn by page: yes, using the mouse on the scrollbar. using down on keyboard, too >Scroll curr line to TOS/MOS/BOS: Yes/No/No. use the mouse >Binary editor: They give three categories. I think this one is closest: > "displays binary characters doesn't do CR/LF conversion on binary files" elides \0. From sam-fans-owner Mon Mar 27 12:05:04 1995 Received: from sartre.minerva.bah.com ([156.80.175.13]) by hawkwind.utcs.utoronto.ca with SMTP id <24077>; Mon, 27 Mar 1995 12:02:42 -0500 Received: from pigsnose by sartre.minerva.bah.com (NX5.67d/NX3.0M) id AA05659; Mon, 27 Mar 95 12:01:14 -0500 Date: Mon, 27 Mar 1995 12:01:14 -0500 From: Erik Quanstrom Message-Id: <9503271701.AA05659@sartre.minerva.bah.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Editors compendium & sam >Enter ASCII codes by #: Use command ' location. also 0Xnnnn will insert any the utf-8 character of number nnnn at the current location. this is a superset of ascii, so the answer is yes. >Goto column number: It says you can do this, but I don't know how. I know > I can put the cursor anywhere I want with the mouse, but don't know > how to go to the nth column on a line. -/^/+#10 go to 10th column >Goto begin next line: ? +,/^/ (0th postion on next line) but for god sakes, use the mouse. >Goto begin prev line: ? - -,/^/ >Move cursor up by page: yes, using the mouse on the scrollbar. using up on keyboard, too >Move cursor dn by page: yes, using the mouse on the scrollbar. using down on keyboard, too >Scroll curr line to TOS/MOS/BOS: Yes/No/No. use the mouse >Binary editor: They give three categories. I think this one is closest: > "displays binary characters doesn't do CR/LF conversion on binary files" elides \0. From sam-fans-owner Mon Mar 27 12:15:22 1995 Received: from plan9.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <24078>; Mon, 27 Mar 1995 12:12:49 -0500 From: rob@plan9.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Mon, 27 Mar 1995 12:12:19 -0500 Message-Id: <95Mar27.121249est.24078@hawkwind.utcs.utoronto.ca> oh yes, i missed the 'begin' : >Goto begin next line: ? +0+#0 >Goto begin prev line: ? -0-#0 From sam-fans-owner Mon Mar 27 15:43:40 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24079>; Mon, 27 Mar 1995 15:40:56 -0500 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyixm06084; Mon, 27 Mar 1995 15:40:42 -0500 Received: from rexago8.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Mon, 27 Mar 1995 15:40:41 -0500 Received: by summitis.com (smail2.5) id AA07733; 27 Mar 95 15:16:03 EST (Mon) Received: from summitis.com by rserv1.summitis.com; Mon, 27 Mar 1995 15:14 EST Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA113230; Mon, 27 Mar 1995 15:13:48 -0500 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA21809; Mon, 27 Mar 1995 15:13:46 -0500 From: hc05@summitis.com Message-Id: <9503272013.AA21809@cheetah> Subject: Re: Editors compendium & sam To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 4611 Date: Mon, 27 Mar 1995 15:40:47 -0500 Thanks for the replies so far on the editor compendium. I'll respond to both Erik & Rob here. A few of the suggestions don't work in all situations, so we'll have to decide how to state them. Beirne From: Erik Quanstrom >>Goto column number: It says you can do this, but I don't know how. I know >> I can put the cursor anywhere I want with the mouse, but don't know >> how to go to the nth column on a line. >-/^/+#10 > >go to 10th column Good, but it won't work on the first line, if this matters. >>Goto begin next line: ? >+,/^/ (0th postion on next line) This doesn't work if you are at the beginning of a line. How about just /^/ > >but for god sakes, use the mouse. Agreed. > >>Goto begin prev line: ? >- >-,/^/ This selects the previous and current lines. > >>Move cursor up by page: yes, using the mouse on the scrollbar. >using up on keyboard, too >>Move cursor dn by page: yes, using the mouse on the scrollbar. >using down on keyboard, too Of course! > >>Scroll curr line to TOS/MOS/BOS: Yes/No/No. >use the mouse You can use the mouse to move the current line to the top of the screen, but there is not a simple way to move the current line to the middle or bottom, short of a bunch of trial-and-error clicks, unless there is something I am missing. > >>Binary editor: They give three categories. I think this one is closest: >> "displays binary characters doesn't do CR/LF conversion on binary files" >elides \0. Good. I'll have to remember this. From: uunet!plan9.att.com!rob >it seems that sam doesn't fit their model very well, which doesn't surprise me. >one thing they can't encompass is that the mouse language and command >language solve different sets of problems. > I agree, since sam has almost no features and almost infinite capabilities. >general comments: there is no such thing (in sam as i wrote it, at least) as a >sam macro, so i'm not sure what you mean by the word 'macro'. I looked at the compendium again, and found a better choice than to say macros, which is to use the following, so I will substitute this wherever I said macro. ^ The editor does not have a specific command to do this, but it can be very easily done with a couple of keystrokes. I.e. Clear buffer may be implemented as: select buffer contents command, delete selection. The compendium does have one item as being implemented with a macro, which is "Spell check select text". I did this with an external script that I wrote that is a front end to ispell, but this should go in the filter category in the compendium rather than as a macro. > >details: > > Goto column number: It says you can do this, but I don't know how. I know > I can put the cursor anywhere I want with the mouse, but don't know > how to go to the nth column on a line. >sam has no notion of column, only characters. > Goto begin next line: ? This highlights the next line. >+ > Goto begin prev line: ? >- This highlights the previous line. > Tag search: Yes, with the help of an external program. >if the program's not there, does that count? Good question. I just looked, and I got the tag program with the samx extensions, which I am not counting here, although I couldn't live without them. > > Interactive debugging: No. >with acid, the external B command does a nice job. Is acid available for UNIX? This does make me realize that I should add Plan 9 to the OS list. > > Syntax highlighting: No. >it's really 'no', but i don't miss it in C because of the double-clicking rules Agreed. Also, I've found regular expressions to convey the C constructs I care about. > Srch select region: No. >x/pattern/p This one could be a yes. It depends on what they mean. This command selects the last occurrence in the selected region, which may be fine. > > List all occurances: Yes. >occurrences. tell me this is your typo. Its not my typo. I cut & pasted it from the compendium. oh yes, i missed the 'begin' : >Goto begin next line: ? +0+#0 Good, but it won't work if you are at the beginning of a line. >Goto begin prev line: ? -0-#0 Good, but it won't work if you are at the beginning of a line. -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Mon Mar 27 16:15:46 1995 Received: from plan9.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <24080>; Mon, 27 Mar 1995 16:13:05 -0500 From: rob@plan9.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Mon, 27 Mar 1995 16:02:32 -0500 Subject: Re: Editors compendium & sam Message-Id: <95Mar27.161305est.24080@hawkwind.utcs.utoronto.ca> wait for them to characterize acme this way. From sam-fans-owner Tue Mar 28 02:06:56 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24071>; Tue, 28 Mar 1995 02:05:05 -0500 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA05082; Tue, 28 Mar 95 08:04:49 BST Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA18393; Tue, 28 Mar 1995 08:11:30 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA04125; Tue, 28 Mar 1995 07:50:23 +0000 Date: Tue, 28 Mar 1995 02:50:23 -0500 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9503280650.AA04125@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Editors compendium & sam Content-Length: 188 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 For going to the beginning of previous line, I find --#0 works better. however, it seems better to say "yes, but using the mouse is easier", because it saves misrepresenting sam... steve From sam-fans-owner Thu Mar 30 20:18:00 1995 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24071>; Thu, 30 Mar 1995 20:15:23 -0500 Received: by galapagos.cse.psu.edu id <12683>; Thu, 30 Mar 1995 20:14:57 -0500 From: Scott Schwartz To: sam-fans@hawkwind.utcs.toronto.edu Subject: umask Message-Id: <95Mar30.201457est.12683@galapagos.cse.psu.edu> Date: Thu, 30 Mar 1995 20:14:49 -0500 I run with 022, but some things I'd rather have tighter control over. Sam makes temp files at various times that don't really need to be group or world writable. Hence this suggestion: =================================================================== RCS file: RCS/mesg.c,v retrieving revision 1.1 diff -r1.1 mesg.c 83c83 < fd = create("/tmp/sam.out", 1, 0666L); --- > fd = create("/tmp/sam.out", 1, 0600L); =================================================================== RCS file: RCS/sam.c,v retrieving revision 1.1 diff -r1.1 sam.c 153c153 < io = create(buf, 1, 0777); --- > io = create(buf, 1, 0700); =================================================================== RCS file: RCS/shell.c,v retrieving revision 1.1 diff -r1.1 shell.c 37c37 < fd = create(errfile, 1, 0666L); --- > fd = create(errfile, 1, 0600L); From sam-fans-owner Wed Apr 5 05:55:23 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24081>; Wed, 5 Apr 1995 05:53:30 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA14982; Wed, 5 Apr 95 10:53:24 BST Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA09996; Wed, 5 Apr 1995 11:00:10 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA10913; Wed, 5 Apr 1995 10:38:38 +0000 Date: Wed, 5 Apr 1995 06:38:38 -0400 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9504050938.AA10913@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: sweeping sam? Content-Length: 273 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Is there any way to get sam to allow its window to be swept, when it starts up under 9wm? currently i specify dimensions in app-defaults/Sam, but if i remove these, I just get an error because the window is then zero width/height. This, btw, is under Solaris 2.3... steve From sam-fans-owner Fri Apr 7 03:51:52 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24081>; Fri, 7 Apr 1995 03:50:04 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA24866; Fri, 7 Apr 95 08:49:54 BST Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA05194; Fri, 7 Apr 1995 08:48:54 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA01265; Fri, 7 Apr 1995 08:49:42 +0000 Date: Fri, 7 Apr 1995 04:49:42 -0400 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9504070749.AA01265@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term mark patch Content-Length: 1870 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 This is a patch for 9term 1.6.3. It adds another toggled option to menu button 2, with the values "mark" and "select". The former records the current position of selected text, while the latter selects all text between the saved position and the current selection, inclusive. Enjoy, steve diff -c orig/9term.c hacked/9term.c *** orig/9term.c Fri Apr 7 08:39:32 1995 --- hacked/9term.c Fri Apr 7 08:42:08 1995 *************** *** 25,36 **** int waterquantum; int beepmask; int ninewm; ! static char *items[] = { "cut", "paste", "snarf", "send", "scroll", 0 }; static Menu edit = {items}; enum { mCUT, mPASTE, mSNARF, mSEND, mSCROLL }; --- 25,39 ---- int waterquantum; int beepmask; int ninewm; + static long mark0, mark1; + static int markset; ! static char *items[] = { "cut", "paste", "snarf", "mark", "send", "scroll", 0 }; static Menu edit = {items}; enum { mCUT, mPASTE, mSNARF, + mMARK, mSEND, mSCROLL }; *************** *** 398,403 **** --- 401,407 ---- static Rune nl[] = { '\n', 0 }; specialchars(slave_fd); + edit.item[mMARK] = markset?"select":"mark"; edit.item[mSCROLL] = text->scrolling?"noscroll":"scroll"; switch (menuhit(2, m, &edit)) { *************** *** 415,420 **** --- 419,440 ---- if (text->snarfed) { textdelete(text, text->p0, text->p1); inputrune(text, text->snarfed, text->snarflen); + } + break; + case mMARK: /* save point, or select to point */ + if (markset) { + ulong m0, m1; + + m0 = (mark0 < text->p0)? mark0 : text->p0; + m1 = (mark1 > text->p1)? mark1 : text->p1; + markset = 0; + if (m0 < text->base || text->end < m0) + textset(text, _backnl(text, m0, 3)); + texthighlight(text,m0,m1, F & ~D); + } else { + mark0 = text->p0; + mark1 = text->p1; + markset = 1; } break; case mSEND: From sam-fans-owner Fri Apr 7 05:23:04 1995 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.utoronto.ca with SMTP id <24081>; Fri, 7 Apr 1995 05:22:22 -0400 Message-ID: From: mhw@minster.york.ac.uk (Mark H. Wilkinson) Date: Fri, 7 Apr 1995 06:14:02 -0400 X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-Url: http://Dcpu1.cs.york.ac.uk:6666/mhw/ X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu (sam mailing list) Subject: sam's memory allocator In the SP&E paper about sam it's mentioned that sam uses a custom memory allocator which allocates strings in a garbage-compacted heap. The version which is released these days uses just malloc() and realloc(). What was the reason for throwing the custom allocator away? -Mark. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark H. Wilkinson : Research student in user University of York, England : interface management systems From sam-fans-owner Fri Apr 7 11:42:31 1995 Received: from plan9.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <24081>; Fri, 7 Apr 1995 11:40:57 -0400 From: rob@plan9.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Fri, 7 Apr 1995 11:40:39 -0400 Subject: Re: sam's memory allocator Message-Id: <95Apr7.114057edt.24081@hawkwind.utcs.utoronto.ca> The original allocator was a residue of life on the Blit. When I moved the program to a Unicode character set and had to redo the allocation, it seemed superfluous. From sam-fans-owner Mon Apr 17 16:52:35 1995 Received: from noc.tor.hookup.net ([165.154.1.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24101>; Mon, 17 Apr 1995 16:43:12 -0400 Received: (Upuka@localhost) by noc.tor.hookup.net (8.6.12/1.340) id QAA11834; Mon, 17 Apr 1995 16:43:02 -0400 Received: from jaguar.staveley.com by staveley.com (4.1/MSC-1.2 (SMI-4.1)) id AA19339; Mon, 17 Apr 95 16:12:32 EDT Received: by jaguar.staveley.com (5.x/SMI-SVR4) id AA08486; Mon, 17 Apr 1995 16:12:28 -0400 Date: Mon, 17 Apr 1995 16:12:28 -0400 From: marc@puka.staveley.com (Marc Staveley) Message-Id: <9504172012.AA08486@jaguar.staveley.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: help Reply-To: marc@staveley.com (Marc Staveley) X-Sun-Charset: US-ASCII please add ML-sam@staveley.com to the sam-fans mailing list. ...marc _______________ Marc Staveley marc@staveley.com Marc Staveley Consulting P.O Box 261 Buckhorn, Ontario (705) 657-3617 [voice] K0L 1J0 Canada (705) 657-2270 [fax] From sam-fans-owner Thu Apr 20 07:46:29 1995 Received: from sangam.ncst.ernet.in ([144.16.11.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24104>; Thu, 20 Apr 1995 07:44:41 -0400 Received: from soochak.ncst.ernet.in (soochak.ncst.ernet.in [144.16.11.100]) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with ESMTP id RAA01933 for ; Thu, 20 Apr 1995 17:13:43 +0530 Received: from iisc.ernet.in (iisc.iisc.ernet.in [144.16.64.3]) by soochak.ncst.ernet.in (8.6.8.1/8.6.5) with SMTP id RAA07139 for ; Thu, 20 Apr 1995 17:13:31 +0530 Received: from sasi.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA15687; Thu, 20 Apr 95 17:18:12+0530 Received: from india29.sasi by sasi.ernet.in (4.1/SMI-4.1) id AA12095; Thu, 20 Apr 95 14:22:46+050 From: kp@sasi.ernet.in (Kiran Pamnany) Return-Receipt-To: Received: (kp@localhost) by india29.sasi (8.6.11/SMI-4.1) id OAA06624 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 20 Apr 1995 14:20:35 +0500 Date: Thu, 20 Apr 1995 05:20:35 -0400 Message-Id: <199504200920.OAA06624@india29.sasi> To: sam-fans@hawkwind.utcs.toronto.edu Subject: any 9term patches? hi can someone point me at a location for patches for 9term? i'm particularly interested in a keyboard interface to the menu commands -- something like samx does for sam. so also for 9wm?? thanx kiran From sam-fans-owner Thu Apr 20 12:22:21 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24104>; Thu, 20 Apr 1995 12:21:17 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA03680; Thu, 20 Apr 95 17:20:54 BST Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA02918; Thu, 20 Apr 1995 17:20:51 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA02372; Thu, 20 Apr 1995 17:20:46 +0000 Date: Thu, 20 Apr 1995 13:20:46 -0400 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9504201620.AA02372@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam's pipe Content-Length: 1296 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Does anyone actually use sam's input pipe, apart from with the B command? Generally, I've hardly used it at all, but I was reading Rob's Acme paper the other day, and it mentioned sam interacting with the compiler and debugger, and I thought, why not? Took about five minutes to write a script for handling compiler errors: the script reads error messages to its stdin, and tells sam to go to the appropriate file/line. The input "make" is an exception; it does just that. feels quite nice. And no, I haven't done anything about debugger interaction.:-) So, I was just wondering if anyone else has written any other useful applications with sam's pipe.... steve #!/bin/rc # Script for going to lines with errors in. Usage: run with # no arguments, and the error lines to stdin. Sends # commands to sam's pipe. # First bit comes straight from 'B': if (~ $#USER 0) USER=$LOGNAME pipe=/tmp/.sam.$USER if (! ~ $#DISPLAY 0) pipe=$pipe.$DISPLAY if (! test -r $pipe) { echo `{basename $0}^': No pipe "'$pipe'" to sam.' >[1=2] exit 1 } while (cmd = `line) { if (~ $cmd '') { exit } if (~ $cmd (make exit)) { $cmd } else { cmd = `{echo $cmd | sed -ne 's/^"\([^"]*\)", line \([0-9]*\).*/f=''\1''; line=\2/p'} eval $cmd echo B $f >> $pipe echo $line >> $pipe } } From sam-fans-owner Thu Apr 20 15:43:16 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24105>; Thu, 20 Apr 1995 15:42:03 -0400 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQymhy08175; Thu, 20 Apr 1995 15:41:47 -0400 Received: from rexago8.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 20 Apr 1995 15:41:48 -0400 Received: by summitis.com (smail2.5) id AA10980; 20 Apr 95 15:39:45 EDT (Thu) Received: from summitis.com by rserv1.summitis.com; Thu, 20 Apr 1995 15:38 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA11602; Thu, 20 Apr 1995 15:38:37 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA19245; Thu, 20 Apr 1995 15:38:34 -0400 From: hc05@summitis.com Message-Id: <9504201938.AA19245@cheetah> Subject: sam pipes To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 1002 Date: Thu, 20 Apr 1995 15:41:51 -0400 Forwarded message: >Does anyone actually use sam's input pipe, apart from with >the B command? Generally, I've hardly used it at all, but I >was reading Rob's Acme paper the other day, and it mentioned >sam interacting with the compiler and debugger, and I thought, >why not? I've used it to add a menu to sam that contains some common command sequences I use, like shifting left, or running text through a spell checker. None of it is especially tricky, but it helps me keep my hands off of the keyboard. I basically get the pipe name and build a 9menu. I like your script. I'll have to get rc, or rewrite it in perl. Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Thu Apr 20 20:32:40 1995 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.utoronto.ca with SMTP id <24105>; Thu, 20 Apr 1995 20:31:54 -0400 Message-ID: From: mhw@minster.york.ac.uk (Mark H. Wilkinson) Date: Thu, 20 Apr 1995 18:09:35 -0400 In-Reply-To: Steve_Kilbane's message, dated Apr 20, 1:20pm X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-Url: http://Dcpu1.cs.york.ac.uk:6666/mhw/ X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane), sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam's pipe Steve_Kilbane wrote: > Subject: sam's pipe > > Does anyone actually use sam's input pipe, apart from with > the B command? I've been using this rc function for a while: fn mk { if (test -f Errors) { builtin mk $* |[2] tee Errors test -s Errors && { { echo b Errors ; echo e } | samsend } } else { builtin mk $* } } samsend is a stripped-down version of B which sends stdin to the pipe, rsh'ing to a remote machine if necessary to avoid NFS problems. I also have scripts to do B, D and cd operations from rc using samsend. -Mark. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark H. Wilkinson : Research student in user University of York, England : interface management systems From sam-fans-owner Fri Apr 21 04:35:41 1995 Received: from sartre.minerva.bah.com ([156.80.175.13]) by hawkwind.utcs.utoronto.ca with SMTP id <24104>; Fri, 21 Apr 1995 04:34:35 -0400 Received: from pigsnose by sartre.minerva.bah.com (NX5.67d/NX3.0M) id AA28559; Fri, 21 Apr 95 04:35:48 -0400 Date: Fri, 21 Apr 1995 04:35:48 -0400 From: Erik Quanstrom Message-Id: <9504210835.AA28559@sartre.minerva.bah.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: more funky things to do with sam's pipe this is a little, really unsophisticated mail reader that i cooked up using rc/sam/9menu. i had to do a few ugly things because 9menu doesn't look at $SHELL. (like create a directory $h/m with dummy files 0 D d h n p q rest s w) but what it does is use se's to split $MAIL into records. you can delete forward or delete backward. (FIFO or LIFO). in retrospect, i should have hacked 9term. also, running in unix, the sam pipe is a pain to use. it would be nice if 1] writes to sampipe would block until the command actually finished. 2] writes to sampipe would fail if the command didn't succede. this would allow one to deal correctly with the first and last message in the file. i just don't know how to do either of those with unix. ::$h/m/cmd:: #!/tmp/rc # get pipe if (~ $sampipe ()) { if (~ $#USER 0) { USER=$LOGNAME } sampipe=/tmp/.sam.$USER if (! ~ $#DISPLAY 0) { sampipe=$sampipe.$DISPLAY } if (! test -p $sampipe) { sam & sleep 1 # this is a timing problem } } # run command if (! echo $* >> $sampipe) { echo >[1=2] sam command failed exit 1 } ::$h/m/^(0 D d h n p q rest s w):: #!/tmp/rc $0 $* ::sam_mail:: #!/tmp/rc . $h/bin/sam_mail_ cd $h/m sleep 1 cmd '$' cmd '-/^From /;$' 9menu delete:d next:n previous:p delete:D rest:rest top:0 hee:h save:s write:'rc -c ''cmd w''' quit:q exit ::sam_mail-:: #!/tmp/rc pipe=`{sampipe} echo fu if (~ $USER ()){ USER=$LOGNAME } if (~ $MAIL ()) { B /usr/spool/mail/$USER }else{ B $MAIL } fn cmd { echo $* >> $pipe || echo 'write to sam failed' >[1=2]} fn mail_select {cmd '/^From /;/^From /-1' } fn mail_select_previous {cmd '-/^From [a-zA-Z]*/;/^From /-1' } fn rest {cmd '.,$'} fn debug {} fn 0 {cmd 0} fn d {cmd d;n} fn D {cmd d; cmd k ; cmd '-/^From [a-zA-Z]*/;''' } fn h {cmd '.,$ x/^From .*\n/ p'} fn q {cmd w ; cmd q} fn delay {cat /etc/motd > /dev/null} fn n { if (~ $#* 0) { mail_select return } for (i) { switch ($i) { case [1-9]* if (! echo -n $i | grep '[1-9][0=9]*'>/dev/null) { echo 'bad numeric argument' >[1=2] return 1 } # evil, i know. # if you've got better ideas go for it! eval `{yes mail_select';' | sed $i^q} case * mail_select $i } } } fn p { if (~ $#* 0) { mail_select_previous return } for (i) { switch ($i) { case [1-9]* if (! echo -n $i | grep '[1-9][0=9]*'>/dev/null) { echo 'bad numeric argument' >[1=2] return 1 } # evil, i know. # if you've got better ideas go for it! eval `{yes mail_select_previous';' | sed $i^q} case * mail_select_previous $i } } } fn s { if (! ~ $#* 0 1) { echo 's takes 0/1 argument' >[1=2] return 1 } else if (~ $#* 0) { file = /tmp/sammail$pid } else { file = $1 if (test -f $file) { echo >[1=2] $file 'exists; won''t overwrite.' return 1; } } debug $file cmd '> cat > ' $file delay test -f $file || { echo >[1=2] could not create temporary file $file^. return 1 } if (~ $#* 0) { file_sam_mail $file } } #!/tmp/rc # sam_mdisperse # object: file away all email carefully # erik quanstrom, 14. oct 94 # nl = ' ' xlate = ``$nl {cat $home/.mxlate | sed 's/#.*//g'} fn getdate { awk '/^From ./ {printf "%s-%s-%s\n", $5, $4, substr($7,3,2)}' < $1 | \ tr '[A-Z]' '[a-z]' } fn xl { n=() site=() name=() i =() j=() { n=``('@' $nl){echo $1} site=$n(2) # what's a ``host''? name=$n(1) for(i in $xlate){ if(~ $i *^$name^*^$site^*){ j=`{echo $i} echo $j(3) break } } } } #sed -n 's/^From \([A-Za-z][A-Za-z!]*@[A-Za-z.][A-Za-z.]*\).*/\1/p' fn parse_addr { sed 's/^From \([A-Za-z][A-Za-z]*@[A-Za-z.][A-Za-z.]*\).*/\1/'$nl'q' <$1 } fn file_sam_mail {folder = () which=() name=() date=() dest=(){ for (folder in $*) { which = from name = `{xl `{parse_addr $folder} } if (~ $name ()) { echo >[2=1] unrecognized name $name^. $folder not moved. return 1 } else { if (test -f $folder) { date = `{getdate $folder} dest = $home/e-letters/$which-$name/$which-$name-$date echo >[2=1] $folder $dest mv $folder $dest return $status } else { echo >[2=1] 'folder does not exist' return 1 } } } }} From sam-fans-owner Fri Apr 21 14:23:06 1995 Received: from minster.york.ac.uk ([144.32.128.41]) by hawkwind.utcs.utoronto.ca with SMTP id <24104>; Fri, 21 Apr 1995 14:16:37 -0400 Message-ID: From: mhw@minster.york.ac.uk (Mark H. Wilkinson) Date: Fri, 21 Apr 1995 15:00:33 -0400 X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-Url: http://Dcpu1.cs.york.ac.uk:6666/~mhw/ X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sam-fans@hawkwind.utcs.toronto.edu (sam mailing list) Subject: mailbox commands While we're on the subject of mail, here's a command I use fairly regularly to strip the Received: lines out of mail headers. Obviously you can apply it to all your mailing list archives using the X command, hence freeing up lots of disk space. ,y/^[ ]*\n/g/^From .*\n(^[a-zA-Z\-]+:.*\n(( | ).*\n)*)+/x/^Received: .*\n(( | ).*\n)*/d or in other words, , # select the whole file y/^[ ]*\n/ # loop over the bits between all the blank lines g/^From .*\n(^[a-zA-Z\-]+:.*\n(( | ).*\n)*)+/ # ensure the current bit matches this regexp which # describes a mail header (I think!) x/^Received: .*\n(( | ).*\n)*/ # loop over Received: header lines, handling continuation # to subsequent lines d # delete -Mark. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark H. Wilkinson : Research student in user University of York, England : interface management systems From sam-fans-owner Fri Apr 28 14:07:50 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24107>; Fri, 28 Apr 1995 14:02:29 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA03451; Fri, 28 Apr 95 18:50:19 BST Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA02331; Fri, 28 Apr 1995 18:50:02 +0000 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA01956; Fri, 28 Apr 1995 18:49:57 +0000 Date: Fri, 28 Apr 1995 14:49:57 -0400 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9504281749.AA01956@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9wm/9term cmdpipes Content-Length: 30278 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 A while ago, I mentioned some hacks I'd done to 9term to add a command pipe, like sam's. Rich $alz commented that 9wm could do with something similar, and I couldn't resist. This is the result, including patches for both 9term and 9wm. There are probably bugs, but they work ok for me. :-) A README file is included. Steve PS Rich: I've made some improvements since I sent you the sample patches, so this lot is different. #!/bin/sh # to extract, remove the header and type "sh filename" if `test ! -s ./9term.patch` then echo "writing ./9term.patch" cat > ./9term.patch << '\Rogue\Monster\' *** orig/9term/9term.c Fri Jun 3 09:35:39 1994 --- hacked/9term/9term.c Fri Apr 21 08:14:28 1995 *************** *** 16,36 **** #include "9term.h" int flushing; int suspended; Event e; ulong Erc; int highwater = 50000; int lowwater = 40000; int waterquantum; int beepmask; int ninewm; ! static char *items[] = { "cut", "paste", "snarf", "send", "scroll", 0 }; static Menu edit = {items}; enum { mCUT, mPASTE, mSNARF, mSEND, mSCROLL }; --- 16,48 ---- #include "9term.h" + #define PIPEDIRENV "NINETERMPIPE" + #define PIPEDIRDEF "/tmp/.9terms." + int flushing; int suspended; Event e; ulong Erc; + ulong Epipe; + static char *exname; + static int exlen; int highwater = 50000; int lowwater = 40000; int waterquantum; int beepmask; int ninewm; + static long mark0, mark1; + static int markset; ! void removeextern(void); ! static void pipeinput(Event *e); ! ! static char *items[] = { "cut", "paste", "snarf", "mark", "send", "scroll", 0 }; static Menu edit = {items}; enum { mCUT, mPASTE, mSNARF, + mMARK, mSEND, mSCROLL }; *************** *** 167,173 **** --- 179,273 ---- run(); } + /* + * create a named pipe for this 9term to accept commands on. + * This function is mainly copied from samterm... + */ + + static + void init_ninepipe(void) + { + #ifndef NOFIFO + char *ninepipedir; + char *disp; + char *user; + int fd; + int flags; + extern ulong windowid; + + if ((ninepipedir = getenv(PIPEDIRENV)) == 0) { + /* user hasn't specified a directory - make up a name */ + /* exname is PIPEDIR.user.display/wid or PIPEDIR.user/wid */ + user = getuser(); + disp = getenv("DISPLAY"); + + if (disp) { + exlen = strlen(PIPEDIRDEF) + strlen(user) + 1 + strlen(disp); + if ((exname = (char *)malloc(exlen + 20)) == 0) + return; + sprintf(exname, "%s%s.%s", PIPEDIRDEF, user, disp); + } else { + exlen = strlen(PIPEDIRDEF) + strlen(user); + if ((exname = (char *)malloc(exlen + 20)) == 0) + return; + sprintf(exname, "%s%s", PIPEDIRDEF, user); + } + } else { + /* use user's specified directory */ + exlen = strlen(ninepipedir); + if ((exname = (char *)malloc(exlen + 20)) == 0) + return; + strcpy(exname,ninepipedir); + } + + /* Create a directory for the pipes to exist in, if necessary. */ + (void)mkdir(exname,0700); + + /* add the next level - the pid */ + sprintf(exname+exlen,"/%d",windowid); + + /* Make the named pipe */ + if (mkfifo(exname, 0600) == -1) { + removeextern(); + return; + } + + fd = open(exname, O_RDONLY | O_NONBLOCK); + if (fd == -1) { + removeextern(); + return; + } + + /* + * Turn off no-delay and provide ourselves as a lingering + * writer so as not to get end of file on read. + */ + flags = fcntl(fd, F_GETFL, 0); + if (flags == -1 || fcntl(fd, F_SETFL, flags & ~O_NONBLOCK) == -1 + || open(exname, O_WRONLY) == -1) { + (void)close(fd); + removeextern(); + return; + } + + Epipe = estart(0, fd, 8192); + atexit(removeextern); + return; + #endif + } + + void + removeextern(void) + { + if (exname) { + (void)unlink(exname); + exname[exlen] = 0; + (void)rmdir(exname); + } + } + + /* * Register command output stream and handle events */ #define MAXMSG 128 *************** *** 179,184 **** --- 279,285 ---- ulong type; Erc = estart(0, comm_fd, MAXMSG + MAXFDATA); + init_ninepipe(); for (;;) { /* disable shell output when more than one buffer ahead */ /* *************** *** 204,210 **** } #endif shelloutput(Erc, &e); ! } } } --- 305,312 ---- } #endif shelloutput(Erc, &e); ! } else if (type == Epipe) ! pipeinput(&e); } } *************** *** 234,239 **** --- 336,371 ---- } /* + * Handle command pipe event + */ + + static void + pipeinput(Event *e) + { + Rune r; + char *c; + Text *t = text; + + /* XXX - should do something like: + if (e->n) + t->p0 = t->p1 = t->end; + or whatever, to make sure we're inserting at the end. */ + + if (e->n) + t->p0 = t->p1 = t->length; + for (c = (char *)e->data; e->n--; c++) { + chartorune(&r, c); + /* ignore eof or eol */ + if (r == eofchar || r == eolchar) + continue; + textinsert(t, &r, (&r)+1, t->p0); + textshow(t, t->p0, 1); + sendrunes(&r,1); + } + texthighlight(text,t->p0,t->p1, F & ~D); + } + + /* * Handle command output event */ static void *************** *** 398,403 **** --- 530,536 ---- static Rune nl[] = { '\n', 0 }; specialchars(slave_fd); + edit.item[mMARK] = markset?"select":"mark"; edit.item[mSCROLL] = text->scrolling?"noscroll":"scroll"; switch (menuhit(2, m, &edit)) { *************** *** 428,433 **** --- 561,582 ---- inputrune(text, text->snarfed, text->snarflen); if (text->snarfed[text->snarflen-1] != '\n') inputrune(text, nl, 1); + } + break; + case mMARK: /* save point, or select to point */ + if (markset) { + ulong m0, m1; + + m0 = (mark0 < text->p0)? mark0 : text->p0; + m1 = (mark1 > text->p1)? mark1 : text->p1; + markset = 0; + /* if (m0 < text->base || text->end < m0) + textset(text, _backnl(text, m0, 3)); */ + texthighlight(text,m0,m1, F & ~D); + } else { + mark0 = text->p0; + mark1 = text->p1; + markset = 1; } break; case mSCROLL: /* toggle scroll state */ *** orig/9term/display.c Thu Dec 15 14:48:28 1994 --- hacked/9term/display.c Wed Mar 29 12:42:36 1995 *************** *** 52,57 **** --- 52,58 ---- static void delwin(Widget, XEvent*, String*, Cardinal*); Text *text; /* the main and only text buffer */ + ulong windowid; /* too many X options */ static XrmOptionDescRec optable[] = { *************** *** 229,235 **** XSetErrorHandler(abort); #endif /* export window id to environment */ ! sprintf(id, "%d", XtWindow(_toplevel)); setenv("WINDOWID", id, 1); /* register mouse and keyboard events */ --- 230,237 ---- XSetErrorHandler(abort); #endif /* export window id to environment */ ! windowid = XtWindow(_toplevel); ! sprintf(id, "%d", windowid); setenv("WINDOWID", id, 1); /* register mouse and keyboard events */ \Rogue\Monster\ else echo "will not over write ./9term.patch" fi if `test ! -s ./9wm.patch` then echo "writing ./9wm.patch" cat > ./9wm.patch << '\Rogue\Monster\' *** orig/9wm/9wm.c Tue Mar 28 16:37:51 1995 --- hacked/9wm/9wm.c Tue Apr 18 14:45:52 1995 *************** *** 14,20 **** char *version[] = { ! "9wm version 1.1, Copyright (c) 1994 David Hogan", 0, }; Display *dpy; --- 14,22 ---- char *version[] = { ! "9wm version 1.1, Copyright (c) 1994 David Hogan", ! "cmdpipe extensions by Steve Kilbane", ! 0, }; Display *dpy; *************** *** 51,57 **** --- 53,61 ---- Atom _9wm_hold_mode; void usage(), sighandler(), getevent(); + static int do_select(); + char *fontlist[] = { "lucm.latin1.9", "blit", *************** *** 221,226 **** --- 225,232 ---- nofocus(); scanwins(); + init_ninepipe(); /* smk */ + for (;;) { getevent(&ev); *************** *** 443,448 **** --- 449,455 ---- e->value_mask |= CWBorderWidth; XConfigureWindow(dpy, e->window, e->value_mask, &wc); + wins_changed |= wm_configurereq; } void *************** *** 479,484 **** --- 486,492 ---- unhidec(c, 1); break; } + wins_changed |= wm_mapreq; } void *************** *** 506,511 **** --- 514,520 ---- } c->reparenting = 0; } + wins_changed |= wm_unmap; } void *************** *** 532,537 **** --- 541,547 ---- c->dy = e->height; c->border = e->border_width; } + wins_changed |= wm_newwindow; } void *************** *** 551,556 **** --- 561,567 ---- ignore_badwindow = 1; XSync(dpy, False); ignore_badwindow = 0; + wins_changed |= wm_destroy; } void *************** *** 657,662 **** --- 668,674 ---- if (c == current) cmapfocus(c); } + wins_changed |= wm_property; } void *************** *** 684,689 **** --- 696,702 ---- if (c != 0 && (c->parent == root || withdrawn(c))) rmclient(c); } + wins_changed |= wm_reparent; } #ifdef SHAPE *************** *** 698,703 **** --- 711,717 ---- return; setshape(c); + wins_changed |= wm_shape; } #endif *************** *** 728,755 **** XEvent *e; { int fd; - fd_set rfds; - struct timeval t; if (!signalled) { ! if (QLength(dpy) > 0) { ! XNextEvent(dpy, e); return; } fd = ConnectionNumber(dpy); ! FD_ZERO(&rfds); ! FD_SET(fd, &rfds); ! t.tv_sec = t.tv_usec = 0; ! if (select(fd+1, &rfds, NULL, NULL, &t) == 1) { ! XNextEvent(dpy, e); return; - } XFlush(dpy); ! FD_SET(fd, &rfds); ! if (select(fd+1, &rfds, NULL, NULL, NULL) == 1) { ! XNextEvent(dpy, e); return; - } if (errno != EINTR || !signalled) { perror("9wm: select failed"); exit(1); --- 742,761 ---- XEvent *e; { int fd; if (!signalled) { ! if (QLength(dpy) > 0) { /* if there are X events, handle them */ ! XNextEvent(dpy, e); /* may mean pipe never gets a look in */ return; } + if (wins_changed) + update_windows_list(); fd = ConnectionNumber(dpy); ! if (do_select(fd,e,0)) return; XFlush(dpy); ! if (do_select(fd,e,1)) return; if (errno != EINTR || !signalled) { perror("9wm: select failed"); exit(1); *************** *** 758,761 **** --- 764,801 ---- cleanup(); fprintf(stderr, "9wm: exiting on signal\n"); exit(1); + } + + static int + do_select(fd, e, i) + int fd; + XEvent *e; + int i; + { + int nfds, r; + fd_set rfds; + struct timeval t; + + for (;;) { /* stay here until we get an X event */ + FD_ZERO(&rfds); + FD_SET(fd, &rfds); + if (ninepipefd != -1) { + FD_SET(ninepipefd, &rfds); + nfds = ninepipefd > fd? ninepipefd : fd; + } else { + nfds = fd; + } + t.tv_sec = t.tv_usec = 0; + if ((r = select(nfds+1, &rfds, NULL, NULL, i? NULL : &t)) < 1) { + return 0; + } + if (ninepipefd != -1 && FD_ISSET(ninepipefd,&rfds)) { + pipecmd(); + continue; + } + if (FD_ISSET(fd,&rfds)) { + XNextEvent(dpy, e); + return 1; + } + } } *** orig/9wm/client.c Tue Mar 28 16:37:53 1995 --- hacked/9wm/client.c Tue Apr 18 14:45:52 1995 *************** *** 68,73 **** --- 68,74 ---- } #endif + void active(c) Client *c; *************** *** 94,99 **** --- 95,101 ---- if (debug) dump_revert(); #endif + wins_changed |= wm_active; } void *************** *** 123,128 **** --- 125,131 ---- } XSetInputFocus(dpy, w, RevertToPointerRoot, timestamp()); cmapfocus(0); + wins_changed |= wm_nofocus; } Client * *** orig/9wm/dat.h Tue Mar 28 16:37:55 1995 --- hacked/9wm/dat.h Tue Apr 18 15:00:54 1995 *************** *** 115,117 **** --- 115,137 ---- /* error.c */ extern int ignore_badwindow; + + /* pipe.c - smk */ + extern int ninepipefd; + extern int wins_changed; + + #define wm_configurereq 0x1 + #define wm_mapreq 0x2 + #define wm_unmap 0x4 + #define wm_newwindow 0x8 + #define wm_destroy 0x10 + #define wm_property 0x20 + #define wm_reparent 0x40 + #define wm_shape 0x80 + #define wm_active 0x100 + #define wm_nofocus 0x200 + #define wm_hide 0x400 + #define wm_unhide 0x800 + #define wm_renamec 0x1000 + #define wm_creshape 0x2000 + #define wm_cmove 0x4000 *** orig/9wm/fns.h Tue Mar 28 16:37:55 1995 --- hacked/9wm/fns.h Tue Apr 18 14:15:42 1995 *************** *** 73,75 **** --- 73,81 ---- /* cursor.c */ void initcurs(); + + /* pipe.c - smk */ + void pipecmd(); + void init_ninepipe(); + void remove9pipe(); + void update_windows_list(); *** orig/9wm/manage.c Tue Mar 28 16:37:52 1995 --- hacked/9wm/manage.c Tue Apr 18 13:59:40 1995 *************** *** 88,94 **** /* Now do it!!! */ ! if (doreshape) { cmapfocus(0); if (!(fixsize ? drag(c) : sweep(c)) && c->is9term) { XDestroyWindow(dpy, c->window); --- 88,94 ---- /* Now do it!!! */ ! if (doreshape && (! dohide || ! fixsize)) { cmapfocus(0); if (!(fixsize ? drag(c) : sweep(c)) && c->is9term) { XDestroyWindow(dpy, c->window); *** orig/9wm/menu.c Tue Mar 28 16:37:52 1995 --- hacked/9wm/menu.c Tue Apr 18 15:10:18 1995 *************** *** 108,114 **** fprintf(stderr, "9wm: exec %s", shell); perror(" failed"); } ! execlp("9term", "9term", "-9wm", 0); execlp("xterm", "xterm", "-ut", 0); perror("9wm: exec 9term/xterm failed"); exit(1); --- 108,114 ---- fprintf(stderr, "9wm: exec %s", shell); perror(" failed"); } ! execlp("9term", "9term", "-unix", "-9wm", 0); execlp("xterm", "xterm", "-ut", 0); perror("9wm: exec 9term/xterm failed"); exit(1); *************** *** 186,191 **** --- 186,192 ---- b3items[B3FIXED+numhidden] = c->label; numhidden++; b3items[B3FIXED+numhidden] = 0; + wins_changed |= wm_hide; } void *************** *** 220,225 **** --- 221,227 ---- b3items[B3FIXED+i] = b3items[B3FIXED+i+1]; } b3items[B3FIXED+numhidden] = 0; + wins_changed |= wm_unhide; } void *************** *** 248,253 **** --- 250,256 ---- if (name == 0) name = "???"; c->label = name; + wins_changed |= wm_renamec; if (!hidden(c)) return; for (i = 0; i < numhidden; i++) \Rogue\Monster\ else echo "will not over write ./9wm.patch" fi if `test ! -s ./README` then echo "writing ./README" cat > ./README << '\Rogue\Monster\' This sharfile contains four files: README (this file) 9term.patch (cmdpipe support for 9term) 9wm.patch (first part of cmdpipe support for 9wm) pipe.c (second part) The 9term patch is against 1.6.3, while the 9wm patch is against 1.1. I've used these changes on Solaris 2.3 for quite a while now, and they seem stable as far as daily use goes. Mind you, they don't *much* use daily... incidentally, there's a bug in 9term 1.6.3 under solaris 2.3 - occasionally the cursor starts up in the wrong place (between two shell prompts), and input results in complaints about null characters. This is in the standard 9term release, and I haven't been able to track it down. 9term changes ============= Each 9term creates a pipe which can be used for input, in the manner of sam's pipe. The name of the pipe is given by $NINETERMPIPE, if set. If not, the pipes go into the directory /tmp/.9terms.$USER.$DISPLAY, if $DISPLAY is set, or /tmp/.9terms.$USER, if not. Within the directory, the pipe's name is $WINDOWID. The directory is created if required, and when 9term exits, the pipe is removed, and so is the directory, if empty. Text written to the pipe is inserted to 9term's window as though it had been typed by the user - it is sent to the shell, too. The cursor is moved to the end of the window first, if necessary. This patch also includes the mark/select toggle on the second menu: mark saves the current selection, and select selects all text between the saved and current selections, inclusive. Caveat: I don't bother to set $NINETERMPIPE, using the default pipe name. Therefore, I haven't actually got around to testing this bit of code. :-) Bug: Text set to the pipe is always sent straight to the shell, too. This means that if you've, say, typed "echo hello " so far, and you squirt "world\n" into the pipe, you'll get "world: no such file or directory", and then when you press return, you get "hello world" appear. This doesn't bother me too much, since I normally only send text to the pipe while I'm between commands anyway. 9wm changes =========== 9wm creates a file which contains the current state of the windows 9wm knows about. The name of the file is $NINEWINDOWS, or /tmp/.9wm-windows by default. Each line of the file contains wid s x y dx dy l where: wid is $WINDOWID s is the state of the window (n = normal, h = hidden) x y are the coords of the window's position dx dy are the window's dimensions l is the window's label The windows' details are added in the same order as the current window stack. Thus, the current window will always be the first line in the file, and so on. If a window's never been current, it'll be one of the last lines in the file. This file is updated whenever the details in it have changed. I've tried to catch all the cases, and have probably been a little eager - it can get updated an awful lot when some X events are going on, even though there's no visible change on the screen. However, 9wm is still a lot faster than olwm... 9wm also creates a pipe, name from $NINEPIPE, or /tmp/.9wm-pipe by default. This pipe is used for sending commands to 9wm itself. Commands are: none Just used for testing. reshape wid x y dx dy change position and size of window wid resize wid dx dy change size of window wid move wid x d change position of window wid front wid move window wid to the front, and make current hide wid hides window wid delete wid deletes window wid label wid str sets label of window wid to str This all seems to work on my system. I haven't tested the label command *too* much, and I suspect that there may be problems in the interaction between X's memory allocations and mine. I haven't seen any evidence of this, it's just that I've probably got it wrong somewhere. :-) Caveats: Again, I use the default names, so I haven't tested the $NINEWINDOWS/$NINEPIPE code. The update code for the windows file is a little eager. Label memory handling could be dodgy. What's the point? ================= I've used these changes, along with 9menu, for adding a few interesting things. Menu options for doing "front" and "back" commands are trivial, and since I use the es shell, other 9menus can repeat the last command or list my recent command history for occasional selection. The most extreme application is 9vwm, a virtual window manager for 9wm written in es. It mostly works, but since I don't have much of a tendency to have many windows anyway, there's no inclination to finish it off. But it was fun. Future directions ================= Sooner or later David Hogan's going to release 9wm 1.2, which has got some fairly extensive changes in it, so I'll have to upgrade to that. :-( I'm considering adding kill/unkill commands to 9wm, so that 9wm can be told of a list of daemons that are interested in being told when the windows file has changed (via a kill()). This might make it easier to write programs that follow manual changes to the window structure. It might be nice to have the windows file contain the arguments to the window, too. That way saving workspaces would be a doddle. It's probably a good idea for 9wm to have both "exit" and "exit!", or something similar - the latter is the current behaviour, while the former just complains to stderr if there are any windows currently hidden. It would probably have to ignore 9menu, though.... Steve Kilbane \Rogue\Monster\ else echo "will not over write ./README" fi if `test ! -s ./pipe.c` then echo "writing ./pipe.c" cat > ./pipe.c << '\Rogue\Monster\' /* Copyright (c) 1995 Steve Kilbane. See README for details */ #include #include #include #include #include #include #include #include "dat.h" #include "fns.h" #include #include #define NINEWINDOWSDEF "/tmp/.9wm-windows" #define NINEWINDOWSENV "NINEWINDOWS" #define PCMDMAX 80 #define PIPENAMEENV "NINEPIPE" #define PIPENAMEDEF "/tmp/.9wm-pipe" typedef enum { pNone, pReshape, pResize, pMove, pHide, pFront, pDelete, pLabel, pError } PipeCmd; #define XY 1 #define DXY 2 #define STR 4 static struct cmdinfo { PipeCmd cmd; char *name; char *fmt; int nconvs; unsigned short flags; } names[] = { { pNone, "none", "", 0, 0 }, { pReshape, "reshape", "%lu%d%d%d%d", 5, (XY|DXY) }, { pResize, "resize", "%lu%d%d", 3, DXY }, { pMove, "move", "%lu%d%d", 3, XY }, { pFront, "front", "%lu", 1, 0 }, { pHide, "hide", "%lu", 1, 0 }, { pDelete, "delete", "%lu", 1, 0 }, { pLabel, "label", "%lu%*[ \t]%n", 1, STR }, { pNone, 0, 0, 0, 0 } }; static struct LabelStr { char *s; struct LabelStr *n; int f; } *labelstrs = NULL; static Client *findc(); static Client *setsize(); static PipeCmd parsepipecmd(); static PipeCmd parse(); static Client *freelabelstr(); static char *getlabelstr(); static void creshape(); static void cmove(); static char *pipename; static pid_t serverpid; int ninepipefd = -1; int wins_changed = 0; static struct { int i; char *s; } reasons[] = { { wm_configurereq, "configurereq" }, { wm_mapreq, "mapreq" }, { wm_unmap, "unmap" }, { wm_newwindow, "newwindow" }, { wm_destroy, "destroy" }, { wm_property, "property" }, { wm_reparent, "reparent" }, { wm_shape, "shape" }, { wm_active, "active" }, { wm_nofocus, "nofocus" }, { wm_hide, "hide" }, { wm_unhide, "unhide" }, { wm_renamec, "renamec" }, { wm_cmove, "cmove" }, { wm_creshape, "creshape" }, { 0, 0 } }; static void print_reason() { int x; fprintf(stderr,"9wm: reason"); for (x = 0; reasons[x].s ; x++) if (wins_changed & reasons[x].i) fprintf(stderr," %s",reasons[x].s); fprintf(stderr,"\n"); } static int write_window_line(c,fd) Client *c; int fd; { static char *buffer; static int maxlen; int len; char state; if (c->label == 0) return 0; len = 45 + strlen(c->label); if (len >= maxlen) { maxlen = len + 1; buffer = buffer? realloc(buffer,maxlen) : malloc(maxlen); if (buffer == 0) { maxlen = 0; return 1; } } state = hidden(c)? 'h' : 'n'; /* ignore withdrawn */ sprintf(buffer,"%lu %c %d %d %d %d %s\n",c->window,state,c->x,c->y,c->dx,c->dy,c->label); (void)write(fd,buffer,strlen(buffer)); return 0; } void update_windows_list(void) { static char *ninewindows, *ninewindowstmp; Client *c, *cc; int fd; /* print_reason(); */ wins_changed = 0; if (ninewindowstmp == 0) { if ((ninewindows = getenv(NINEWINDOWSENV)) == 0) ninewindows = NINEWINDOWSDEF; if ((ninewindowstmp = malloc(strlen(ninewindows)+5)) == 0) { fprintf(stderr,"9wm: cannot alloc tmpfile name for %s\n",ninewindows); return; } sprintf(ninewindowstmp,"%s.tmp",ninewindows); } if ((fd = creat(ninewindowstmp, 0744)) < 0) { fprintf(stderr,"9wm: cannot create '%s'\n",ninewindowstmp); return; } /* write clients that have been selected first, in active order */ for (c = current; c; c = c->revert) if (write_window_line(c,fd)) { close(fd); (void)unlink(ninewindowstmp); return; } /* now do those that have never been selected, in any order */ for (c = clients; c; c = c->next) { for (cc = current; cc; cc = cc->revert) if (cc == c) break; if (cc == 0) if (write_window_line(c,fd)) { close(fd); (void)unlink(ninewindowstmp); return; } } close(fd); (void)rename(ninewindowstmp,ninewindows); return; } void pipecmd() { static char data[PCMDMAX]; int x, y, dx, dy; int len; Window winid; char *text; Client *c; char *ptr; if ((len = read(ninepipefd,data,PCMDMAX)) < 1) return; ptr = data; for (;;) { switch (parsepipecmd(&ptr,&len,&winid,&x,&y,&dx,&dy,&text)) { case pNone: return; case pReshape: creshape(setsize(findc(winid),x,y,dx,dy,1,1)); break; case pResize: creshape(setsize(findc(winid),0,0,x,y,1,0)); break; case pMove: cmove(setsize(findc(winid),x,y,0,0,0,1)); break; case pHide: hide(findc(winid)); break; case pFront: c = findc(winid); if (c == 0) break; if (hidden(c)) unhidec(c,1); else { XMapRaised(dpy, c->parent); active(c); } break; case pDelete: delete(findc(winid),1); break; case pLabel: c = findc(winid); if (c == 0) break; renamec(freelabelstr(c),getlabelstr(text)); break; default: fprintf(stderr,"9wm: unparsed command: %s\n",text); return; } XFlush(dpy); } } static Client * findc(w) Window w; { Client *c; for (c = clients; c; c = c->next) if (c->window == w) return c; fprintf(stderr,"9wm: invalid window id %lu\n",w); return 0; } static Client * setsize(c,x,y,dx,dy,resizing,moving) Client *c; int x, y, dx, dy, resizing, moving; { if (c == 0) return 0; if (resizing) { if (dx < 0) dx = -dx; if (dy < 0) dy = -dy; /* following nicked from grab.c:sweepcalc() */ dx -= 2*BORDER; dy -= 2*BORDER; if (!c->is9term) { if (dx < c->min_dx) dx = c->min_dx; if (dy < c->min_dy) dy = c->min_dy; } if (dx < 4) dx = 4; if (dy < 4) dy = 4; if (c->size.flags & PResizeInc) { dx = c->min_dx + (dx-c->min_dx)/c->size.width_inc*c->size.width_inc; dy = c->min_dy + (dy-c->min_dy)/c->size.height_inc*c->size.height_inc; } if (c->size.flags & PMaxSize) { if (dx > c->size.max_width) dx = c->size.max_width; if (dy > c->size.max_height) dy = c->size.max_height; } /* end of nicked code */ c->dx = dx + 2*BORDER; c->dy = dy + 2*BORDER; } if (moving) { if (x < 0) x = 0; if (y < 0) y = 0; c->x = x; c->y = y; } return c; } /* * this function's fun. the event is pretty much going to be a character * at a time, but we don't know this. Therefore, we're called each time * with the new additions to the buffer, and we read until we get a * newline. At this point, we check the line length is ok, and then * start parsing. If we haven't got a newline yet, we return pNone once * we've saved the characters. If we find an error, we set *text to point * to the buffer, so that we can display it in the error message. */ static PipeCmd parsepipecmd(data, n, w, x, y, dx, dy, text) char **data; int *n; Window *w; int *x, *y, *dx, *dy; char **text; { static char buff[PCMDMAX]; static int len; char c; if (*n == 0) return pNone; *text = buff; while ((*n)--) { c = *(*data)++; if (c == '\n' || c == '\r') { if (len < PCMDMAX) { buff[len] = 0; len = 0; return parse(buff,w,x,y,dx,dy,text); } else { len = 0; return pError; } } buff[len++] = c; } return pNone; } static PipeCmd parse(buff, w, x, y, dx, dy, text) char *buff; Window *w; int *x, *y, *dx, *dy; char **text; { struct cmdinfo *p; char *str; unsigned int len; int r; for (p = names; p->name; p++) { len = strlen(p->name); if (strncmp(buff,p->name,len) == 0 && isspace(buff[len])) { break; } else { } } if (p->name == 0) { return pError; } str = buff + len + 1; if (p->flags & STR) r = sscanf(str,p->fmt,w,&len); else r = sscanf(str,p->fmt,w,x,y,dx,dy); if (r < p->nconvs) return pError; if (p->flags & STR) *text = str + len; return p->cmd; } /* * following is largely nicked from my hacks to 9term.c, which * in turn were swiped from samterm. */ void init_ninepipe() { #ifndef NOFIFO int fd; int flags; extern char *getenv(); serverpid = getpid(); if ((pipename = getenv(PIPENAMEENV)) == 0) pipename = PIPENAMEDEF; if (mkfifo(pipename, 0600) == -1) return; if ((fd = open(pipename, O_RDONLY | O_NONBLOCK)) < 0) { remove9pipe(); return; } flags = fcntl(fd, F_GETFL, 0); if (flags == -1 || fcntl(fd,F_SETFL, flags & ~O_NONBLOCK) == -1 || open(pipename, O_WRONLY) == -1) { (void)close(fd); remove9pipe(); return; } ninepipefd = fd; atexit(remove9pipe); return; #endif } void remove9pipe() { if (pipename && serverpid == getpid()) { (void)unlink(pipename); pipename = 0; } return; } static char * getlabelstr(s) char *s; { struct LabelStr *l; if (s == 0) return s; if ((l = (struct LabelStr *)malloc(sizeof(*l))) == 0) return s; l->n = labelstrs; labelstrs = l; if ((l->s = strdup(s)) == 0) l->s = s; l->f = (l->s == s); return l->s; } static Client * freelabelstr(c) Client *c; { char *s = c->label; struct LabelStr *l, **p = &labelstrs; while (*p && (*p)->s != s) p = &((*p)->n); if (*p) { l = *p; *p = l->n; if (l->f) (void)free(l->s); (void)free(l); } return c; } static void cmove(c) Client *c; { if (c == 0) return; active(c); XRaiseWindow(dpy, c->parent); XMoveWindow(dpy, c->parent, c->x-BORDER, c->y-BORDER); sendconfig(c); wins_changed |= wm_cmove; } static void creshape(c) Client *c; { if (c == 0) return; active(c); XRaiseWindow(dpy, c->parent); XMoveResizeWindow(dpy, c->parent, c->x-BORDER, c->y-BORDER, c->dx+2*(BORDER-1), c->dy+2*(BORDER-1)); XMoveResizeWindow(dpy, c->window, BORDER-1, BORDER-1, c->dx, c->dy); wins_changed |= wm_creshape; } \Rogue\Monster\ else echo "will not over write ./pipe.c" fi echo "Finished archive 1 of 1" exit From sam-fans-owner Fri Apr 28 16:43:01 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24107>; Fri, 28 Apr 1995 16:42:05 -0400 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQynlq15298; Fri, 28 Apr 1995 16:41:49 -0400 Received: from rexago8.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 28 Apr 1995 16:41:50 -0400 Received: by summitis.com (smail2.5) id AA26104; 28 Apr 95 16:40:05 EDT (Fri) Received: from summitis.com by rserv1.summitis.com; Fri, 28 Apr 1995 16:38 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA61842; Fri, 28 Apr 1995 16:38:44 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA13616; Fri, 28 Apr 1995 16:38:40 -0400 From: hc05@summitis.com Message-Id: <9504282038.AA13616@cheetah> Subject: 9term/9wm hacks To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 1560 Date: Fri, 28 Apr 1995 16:41:53 -0400 >Subject: 9wm/9term cmdpipes >X-Face: Iqsa(US9p?)Y^W+6Ff[Z] 8!$T`8QNfKrM"uFE) > lFDjag1e]\/#2 >Content-Type: text >Content-Length: 30278 > 8!$T`8QNfKrM"uFE) > lFDjag1e]\/#2 > >A while ago, I mentioned some hacks I'd done to 9term to add a >command pipe, like sam's. Rich $alz commented that 9wm could do >with something similar, and I couldn't resist. This is the >result, including patches for both 9term and 9wm. There are >probably bugs, but they work ok for me. :-) A README file >is included. > >Steve I've loaded the patches to both 9term & 9wm on an RS/6000 running AIX 3.2.5. 9term worked fine, but I had trouble with 9wm. I lost the ability to use the mouse to anything but bring up the root menu or a 9menu. The mouse would not work for scrolling, selecting text, or bringing up a window. I had to write to the pipe to bring up an xterm so I could exit. I otherwise like the idea, though, and am not complaining. I think I'll use the 9term pipe to see if I can work elm from a 9menu. Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon ------------------------------------------------------------------------------- From sam-fans-owner Mon May 1 03:21:36 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24108>; Mon, 1 May 1995 03:18:56 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA22825; Mon, 1 May 95 08:18:48 BST Received: by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA17654; Mon, 1 May 1995 08:18:42 +0000 Date: Mon, 1 May 1995 04:18:42 -0400 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9505010718.AA17654@vampire.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: hc05@summitis.com Subject: Re: 9term/9wm hacks Cc: sam-fans@hawkwind.utcs.toronto.edu Content-Length: 659 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 > From: hc05@summitis.com > I've loaded the patches to both 9term & 9wm on an RS/6000 running AIX > 3.2.5. 9term worked fine, but I had trouble with 9wm. I lost the > ability to use the mouse to anything but bring up the root menu or a > 9menu. The mouse would not work for scrolling, selecting text, or > bringing up a window. Interesting. I suspect the either the select() or FIFO handling, since they seem like areas AIX could be broken in, but since I've never used AIX I can't comment. select() seems the most likely, since if there was a FIFO problem it would probably hang completely. Does anyone with more AIX experience have any pointers? steve From sam-fans-owner Thu May 25 07:16:40 1995 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24167>; Thu, 25 May 1995 07:14:37 -0400 Via: uk.ac.edinburgh.epcfta; Thu, 25 May 1995 12:12:28 +0100 From: Robert Raschke Date: Thu, 25 May 1995 06:33:06 -0400 Message-Id: <9250.9505251033@epcfta.ed.ac.uk> To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam warning about files being aliased ??? Hi, I have just received a warning message from sam : ?warning: files might be aliased `file1' and `file2' Does anyone know what this might mean? Thanks, Robby -- robby@epc.ed.ac.uk From sam-fans-owner Thu May 25 07:22:40 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24168>; Thu, 25 May 1995 07:22:20 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA03302; Thu, 25 May 95 12:21:55 BST Received: from spirit.cegelecproj.co.uk (spirit.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA11683; Thu, 25 May 1995 12:21:47 +0100 Received: by spirit.cegelecproj.co.uk (5.0/SMI-SVR4) id AA02610; Thu, 25 May 1995 12:21:42 +0100 Date: Thu, 25 May 1995 07:21:42 -0400 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9505251121.AA02610@spirit.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: robby@epcfta.edinburgh.ac.uk Subject: Re: sam warning about files being aliased ??? Cc: sam-fans@hawkwind.utcs.toronto.edu Content-Length: 160 X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 It means that you've opened file2, and sam thinks that it's the same file as file1, already open for editing. E.g. ; cd /etc ; sam passwd B /etc/passwd steve From sam-fans-owner Mon May 29 11:48:36 1995 Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by hawkwind.utcs.utoronto.ca with SMTP id <24171>; Mon, 29 May 1995 11:45:42 -0400 Received: from ibch10.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA21469; Mon, 29 May 1995 17:43:57 +0200 Received: by ibch10.inf.tu-dresden.de (5.67b+/DEC-Ultrix/4.3) id AA10449; Mon, 29 May 1995 17:43:55 +0200 Date: Mon, 29 May 1995 11:43:55 -0400 Message-Id: <199505291543.AA10449@ibch10.inf.tu-dresden.de> To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam confused, Q: arrow keys From: Joerg Wittenberger Organisation: University of Technology Dresden X-Url: http://www.inf.tu-dresden.de/~jw6 X-Attribution: jfw Hello, I got sam a couple of days ago. I guess it's a nice thing. But I ran into two problems with it: 1) sometimes I end up in a situation when the whole editing menu (second mouse key) is displayed with parens around the topics and none of the commands typed into the ~sam~ window has any effect. I neither understand how I get into this situation nor how to escape from. All I can do is to terminate sam. Any help? 2) The arrow keys: I'm sitting in front of an AIX. When I try to move the cursor using the arrow keys they seem to have all the effect of page up/down. I can't move character or line wise. How can I get an usable key binding? 3) On different point (unrelated to sam): I attempt to compile 9term for the AIX, but I failed. I had to change some code to open a pty (as usual with AIX everything is a little different) into a mix of the two kinds already in the file pty.c. After doing so I ended up with an executable which opened a window. But the shell was obviewsly started on a complete different pty!! (After some tries starting and killing the 9term, I was left with a window where a couple of shells shared ONE pty. Fancy.) Any idea where to look? Did someone succed to compile 9term for the AIX (version 3)? One more Q: what I really can't understand: I promise that I got a executable one day. Since this day I can't link it any more. (Well, I changed something and didn't keep track of.) Whenever I try to link it now I end up with: cc -o 9term 9term.o command.o display.o pty.o ../libtext/libtext.a ../l ibframe/libframe.a ../libXg/libXg.a -lXt -lX11 -lm 0706-317 ERROR: Unresolved or undefined symbols detected: Symbols in error (followed by references) are dumped to the load map. The -bloadmap: option will create a load map. .XrmGetDatabase But I don't know where the XrmGetDatabase could come from (nor how it could ever have been resolved). Thanks /Jerry From sam-fans-owner Tue May 30 08:41:46 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24171>; Tue, 30 May 1995 08:40:41 -0400 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyryo18625; Tue, 30 May 1995 08:40:32 -0400 Received: from rexago8.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 30 May 1995 08:40:32 -0400 Received: by summitis.com (smail2.5) id AA26604; 30 May 95 08:32:25 EDT (Tue) Received: from summitis.com by rserv1.summitis.com; Tue, 30 May 1995 08:30 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA163109; Tue, 30 May 1995 08:29:58 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA12761; Tue, 30 May 1995 08:29:55 -0400 From: hc05@summitis.com Message-Id: <9505301229.AA12761@cheetah> X-Mailer: exmh version 1.6 4/21/95 To: sam-fans@hawkwind.utcs.toronto.edu Cc: hc05@summitis.com Subject: Re: sam confused, Q: arrow keys In-Reply-To: (Your message of Mon, 29 May 95 11:43:55 D.) <9505291641.AA71874@rexsrvr2.summitis.com> <199505291543.AA10449@ibch10.inf.tu-dresden.de> Mime-Version: 1.0 Date: Tue, 30 May 1995 09:29:53 -0400 Content-Type: text/plain Content-Length: 2273 > Hello, > > I got sam a couple of days ago. I guess it's a nice thing. But I ran > into two problems with it: > > 1) sometimes I end up in a situation when the whole editing menu > (second mouse key) is displayed with parens around the topics and none > of the commands typed into the ~sam~ window has any effect. I neither > understand how I get into this situation nor how to escape from. All I > can do is to terminate sam. Any help? This means that sam is trying to process a command and hasn't finished. The fact that you are stuck there is bad. > > 2) The arrow keys: I'm sitting in front of an AIX. When I try to move > the cursor using the arrow keys they seem to have all the effect of > page up/down. I can't move character or line wise. How can I get an > usable key binding? You should first understand how sam was designed. The idea is that you use the keyboard for entering text, and the mouse for control. You are supposed to use the mouse to move the cursor, not the keyboard. Having said that, you can get the samx patches for sam, which give you arrow keys like you expect, the ability to define macros, and autoindent. I use the package mainly for autoindent (I would have quit using sam without it), but the arrow keys are handy too. BTW, I don't know offhand where to get the samx patches, but others do. > > 3) On different point (unrelated to sam): I attempt to compile 9term > for the AIX, but I failed. I had to change some code to open a pty (as > usual with AIX everything is a little different) into a mix of the two > kinds already in the file pty.c. After doing so I ended up with an > executable which opened a window. But the shell was obviewsly started > on a complete different pty!! (After some tries starting and killing > the 9term, I was left with a window where a couple of shells shared > ONE pty. Fancy.) Any idea where to look? Did someone succed to compile > 9term for the AIX (version 3)? I have a mostly working 9term for AIX 3.2.5. I had to rewrite the pty logic. It works mostly. The things that need work are the special keys like INTR and job-control, and it dies occasionally. I can send it to you if you want to tinker more. I don't use 9term much, so I haven't gotten around to finishing it. Beirne From sam-fans-owner Tue May 30 10:13:06 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24171>; Tue, 30 May 1995 10:12:40 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.13) via UUCP id AA27507 ; Tue, 30 May 95 10:12:35 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Tue, 30 May 95 10:00 EDT Message-Id: Date: Tue, 30 May 1995 10:00:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam confused, Q: arrow keys In-Reply-To: <199505291543.AA10449@ibch10.inf.tu-dresden.de> X-Mailer: [XMailTool v3.1.2] > I got sam a couple of days ago. I guess it's a nice thing. But I ran > into two problems with it: > > 1) sometimes I end up in a situation when the whole editing menu > (second mouse key) is displayed with parens around the topics and none > of the commands typed into the ~sam~ window has any effect. I neither > understand how I get into this situation nor how to escape from. All I > can do is to terminate sam. Any help? This is called a "protocol lock". There is a protocol between samterm, which controls the display you interact with, and sam, which actually does the editing. Occasionally, they get out of sync and there's nothing you can do. This usually happens to me after I've used the page-up or page-down keys and then started typing before samterm has finished updating the screen. I can usually switch to the sam window and send a 'w' and 'q' and then start a new session. Unfortunately, the Bell Labs guys can't seem to reproduce it... Sigh. Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold@skeeve.ATL.GA.US | exponentially in the UUCP: emory!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins From sam-fans-owner Thu Jun 1 10:14:53 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24173>; Thu, 1 Jun 1995 10:12:28 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.14) via UUCP id AA00153 ; Thu, 1 Jun 95 10:12:25 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Thu, 1 Jun 95 09:42 EDT Message-Id: Date: Thu, 1 Jun 1995 09:42:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: sam-fans@hawkwind.utcs.utoronto.ca Subject: 9menu - advice sought X-Mailer: [XMailTool v3.1.2] Greetings. I have been sent code to have 9menu warp itself to wear the mouse is when it is de-iconified, the idea being that it "pops up" to where the mouse is. I'm trying to decide if I want to incorporate this behavior (probably under a `-warp' command line option), OR have the menu stay where it was originally placed, and instead have 9menu warp the mouse to where it is when it pops up. This second way is how I'm leaning at the moment, although the angle of my leaning is very slight. Anyway, I'd like to hear your opinion, particularly if you're using 9menu now. Thanks, Arnold From sam-fans-owner Thu Jun 1 17:43:18 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24173>; Thu, 1 Jun 1995 17:42:34 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.14) via UUCP id AA20213 ; Thu, 1 Jun 95 17:42:27 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Thu, 1 Jun 95 17:35 EDT Message-Id: Date: Thu, 1 Jun 1995 17:35:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: sam-fans@hawkwind.utcs.utoronto.ca Subject: 9menu & mouse warping The sentiment so far is for 9menu not to warp the mouse. I'm half tempted to make the option such that it will warp the mouse, and then warp it back to where it was when done (a sort of mouse stack... :-), mainly 'cause I like to leave 9menu in one place. However, that probably wouldn't go over too well either. :-) OK, so is it possible under X to get a MapNotify event from the window manager but avoid the actual mapping of the window until after I've moved it to the new location? The current code blinks the menu at the old location before moving it to under the mouse; I thought I'd ask for advice about this before trying to do any hacking on it. (dhog?) Keep those cards and letters coming, folks. Thanks, Arnold From sam-fans-owner Fri Jun 2 16:57:34 1995 Received: from dam.CharlesView.COM ([199.103.137.242]) by hawkwind.utcs.utoronto.ca with SMTP id <24175>; Fri, 2 Jun 1995 16:51:07 -0400 Received: (from smap@localhost) by dam.CharlesView.COM (8.6.11/1.0ckc) id QAA31947 for ; Fri, 2 Jun 1995 16:50:13 -0400 Received: from ray(199.103.137.241) by dam via smap (V1.3) id sma031941; Fri Jun 2 16:49:48 1995 Received: (calvin@localhost) by ray.charlesview.com (8.6.11/8.6.10) id QAA01112; Fri, 2 Jun 1995 16:51:58 -0400 Date: Fri, 2 Jun 1995 16:51:58 -0400 Message-Id: <199506022051.QAA01112@ray.charlesview.com> From: Calvin Clark To: sam-fans@hawkwind.utcs.toronto.edu Subject: Where can get current version of UNIX sam port? What I have now dates back a couple of years (from research.att.com's ftp site.) Is there something more recent I should be running? -Calvin From sam-fans-owner Mon Jun 19 23:46:02 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24181>; Mon, 19 Jun 1995 23:43:59 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.14) via UUCP id AA02773 ; Mon, 19 Jun 95 23:43:43 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Mon, 19 Jun 95 23:26 EDT Message-Id: Date: Mon, 19 Jun 1995 23:26:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: sam-fans@hawkwind.utcs.utoronto.ca Subject: new 9menu available I have updated 9menu to version 1.4. It's available from ftp.cc.gatech.edu in /pub/people/arnold/9menu-1.4.shar.gz. It does not unpack into a separate directory. Besides a bug fix or two, this version adds -teleport and -warp options. The -teleport option causes the menu to follow the mouse around, which is how everyone said they wanted it to work. The -warp option brings the mouse to the menu, and then puts it back, which is how I want it to work for me. (:-) Would the folks who are mirroring 9menu please pick it up and put it on their systems? I may not have the use of the Ga Tech system for much longer, and I'd like 9menu to survive. ("the software that men do lives after them" or some such nonsense) Enjoy, Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold@skeeve.ATL.GA.US | exponentially in the UUCP: emory!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins From sam-fans-owner Mon Jun 26 10:45:07 1995 Received: from sartre.minerva.bah.com ([156.80.175.13]) by hawkwind.utcs.utoronto.ca with SMTP id <24198>; Mon, 26 Jun 1995 10:42:04 -0400 Received: by sartre.minerva.bah.com (NX5.67d/NX3.0M) id AA05666; Mon, 26 Jun 95 10:37:36 -0400 Date: Mon, 26 Jun 1995 10:37:36 -0400 From: goon Message-Id: <9506261437.AA05666@sartre.minerva.bah.com> To: Subject: s cmd lossage Apparently-To: sam-fans@hawkwind.utcs.toronto.edu this s command lost with the latest (straight from at&t) version of sam. s:(([A-Z][a-z]*[ ]?)+)[ ]+([0-9]+):NAME \1\nPHONE 205 \2\n:g ^- space tab what happened was that \2 was set to \1. i rewrote the command without the nested parens (i really hadn't expected the command to work), and things were Happy. the working rewritten command is s:([A-Za-z ]+)[ ]+([0-9]+):NAME \1\nPHONE 205 \2\n:g From sam-fans-owner Fri Jun 30 16:21:25 1995 Received: from hermes.intel.com ([143.183.152.3]) by hawkwind.utcs.utoronto.ca with SMTP id <23978>; Fri, 30 Jun 1995 16:18:41 -0400 Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 30 Jun 95 13:18:33 -0700 Received: from pdx404 by ichips.intel.com (5.64+/10.0i); Fri, 30 Jun 95 13:18:05 -0700 Received: by pdx404.intel.com (AIX 3.2/UCB 5.64/10.0i); Fri, 30 Jun 1995 13:17:55 -0700 Date: Fri, 30 Jun 1995 16:17:55 -0400 From: haertel@ichips.intel.com Message-Id: <9506302017.AA28543@pdx404.intel.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Sam crash Running sam under AIX 3.2, I get a samterm panic from the following sequence of commands typed in the command window: B /etc/termcap ,x/:am/ { /:am/ /:am/ c/FOO/ } Does anybody else observe this behavior? From sam-fans-owner Sat Jul 1 12:23:01 1995 Received: from minster.cs.york.ac.uk ([144.32.16.26]) by hawkwind.utcs.utoronto.ca with SMTP id <23978>; Sat, 1 Jul 1995 12:21:52 -0400 From: mhw@minster.york.ac.uk Message-ID: >From: mhw@minster.york.ac.uk (Mark H. Wilkinson) Date: Sat, 1 Jul 1995 13:18:59 -0400 In-Reply-To: haertel@ichips.intel.com's message, dated Jun 30, 4:17pm X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-Url: http://Dcpu1.cs.york.ac.uk:6666/~mhw/ X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: haertel@ichips.intel.com, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Sam crash Cc: bobf@research.att.com haertel@ichips.intel.com wrote: > Subject: Sam crash > > Running sam under AIX 3.2, I get a samterm panic from the following > sequence of commands typed in the command window: > > B /etc/termcap > ,x/:am/ { > /:am/ > /:am/ > c/FOO/ > } > > Does anybody else observe this behavior? > [end of included message] Yes, I've seen this. What's probably happening is that sam core dumps and samterm panics because the pipe to sam dries up. The reason sam core dumps is that there's a bug in the execution of brace commands in cmdexec() in xec.c. It calls lookup() (in cmd.c) to get the command number of a command character then uses the returned value as an index into cmdtab (also in cmd.c). '{' isn't in cmdtab though so lookup() returns -1 and so the array access looks at a potentially bad address. A patch to fix this is attached. I've also had problems with sam core dumping in Fupdate() called from update() in sam.c. I think there's a dubious piece of code here which appears to delete() a file and then potentially perform operations on the free()d memory. A patch to fix this is also attached. I guess the occurence of these two bugs depends on the malloc implementation and the compiler you're using. I've been bitten by them though, and the fixes seem to work for me. -Mark. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark H. Wilkinson : Research student in user University of York, England : interface management systems Index: sam/sam.c diff -c sam/sam.c:1.3 sam/sam.c:1.4 *** sam/sam.c:1.3 Mon Apr 3 12:07:11 1995 --- sam/sam.c Wed Apr 12 16:34:40 1995 *************** *** 303,310 **** f = tempfile.filepptr[i]; if(f==cmd) /* cmd gets done in main() */ continue; ! if(f->deleted) delete(f); if(f->mod==modnum && Fupdate(f, FALSE, downloaded)) anymod++; if(f->rasp) --- 303,312 ---- f = tempfile.filepptr[i]; if(f==cmd) /* cmd gets done in main() */ continue; ! if(f->deleted){ delete(f); + continue; + } if(f->mod==modnum && Fupdate(f, FALSE, downloaded)) anymod++; if(f->rasp) Index: sam/xec.c diff -c sam/xec.c:1.1.1.1 sam/xec.c:1.2 *** sam/xec.c:1.1.1.1 Sun Jul 31 17:36:14 1994 --- sam/xec.c Wed Apr 12 16:36:33 1995 *************** *** 31,37 **** cp->cmdc!=('c'|0x100) && !(cp->cmdc=='D' && cp->ctext)) error(Enofile); i = lookup(cp->cmdc); ! if(cmdtab[i].defaddr != aNo){ if((ap=cp->addr)==0 && cp->cmdc!='\n'){ cp->addr = ap = newaddr(); ap->type = '.'; --- 31,37 ---- cp->cmdc!=('c'|0x100) && !(cp->cmdc=='D' && cp->ctext)) error(Enofile); i = lookup(cp->cmdc); ! if(i >= 0 && cmdtab[i].defaddr != aNo){ if((ap=cp->addr)==0 && cp->cmdc!='\n'){ cp->addr = ap = newaddr(); ap->type = '.'; From sam-fans-owner Tue Jul 11 03:59:13 1995 Received: from reef.cs.jcu.edu.au ([137.219.17.26]) by hawkwind.utcs.utoronto.ca with SMTP id <24080>; Tue, 11 Jul 1995 03:55:31 -0400 Received: by reef.cs.jcu.edu.au; id AA32380; Tue, 11 Jul 1995 17:55:10 +1000 Message-Id: <9507110755.AA32380@reef.cs.jcu.edu.au> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Sam on alphas? Reply-To: tony@cs.jcu.edu.au Organisation: Dept. of Computer Science, James Cook University Date: Tue, 11 Jul 1995 03:55:09 -0400 From: tony@reef.cs.jcu.edu.au X-Mts: smtp Hi folks, I've just started using sam on a DEC Alpha running OSF1/3.0. I grabbed the latest distrib from AT&T but unfortunately it crashes periodically. Before I attempt to track down the problem, is anyone else using it successfully on this platform? Also, can someone point me to the Sam extension patches? I lost my record of the site. Thanks in advance, Tony Sloane Tony Sloane tony@cs.jcu.edu.au Department of Computer Science, James Cook University From sam-fans-owner Wed Jul 12 19:18:11 1995 Received: from reef.cs.jcu.edu.au ([137.219.17.26]) by hawkwind.utcs.utoronto.ca with SMTP id <24080>; Wed, 12 Jul 1995 19:13:03 -0400 Received: by reef.cs.jcu.edu.au; id AA26419; Thu, 13 Jul 1995 09:12:51 +1000 Message-Id: <9507122312.AA26419@reef.cs.jcu.edu.au> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Sam on alphas? In-Reply-To: Your message of "Tue, 11 Jul 95 03:55:09 -0400." <9507110755.AA32380@reef.cs.jcu.edu.au> Reply-To: tony@cs.jcu.edu.au Organisation: Dept. of Computer Science, James Cook University Date: Wed, 12 Jul 1995 19:12:50 -0400 From: tony@reef.cs.jcu.edu.au X-Mts: smtp Hi, I guess it's bad form to answer my own mail, but oh well... > I've just started using sam on a DEC Alpha running OSF1/3.0. I > grabbed the latest distrib from AT&T but unfortunately it crashes > periodically. Before I attempt to track down the problem, is anyone > else using it successfully on this platform? It turns out that the compile on OSF1/3.0 has a different set of predefined processor symbols. Hence the line in sam/sam.h that says: #ifdef __alpha__ should be #if defined(__alpha__) || defined(__alpha) With this change made I haven't had a crash. > Also, can someone point me to the Sam extension patches? I lost my > record of the site. Still looking for these... Cheers, Tony From sam-fans-owner Wed Jul 26 11:36:16 1995 Received: from plan9.att.com ([192.20.225.252]) by hawkwind.utcs.utoronto.ca with SMTP id <24103>; Wed, 26 Jul 1995 11:31:50 -0400 From: rob@plan9.att.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Wed, 26 Jul 1995 11:29:33 -0400 Subject: Re: s cmd lossage Message-Id: <95Jul26.113150edt.24103@hawkwind.utcs.utoronto.ca> some time ago - i'm catching up on old sam mail - quanstro@sartre.minerva.bah.com said: this s command lost with the latest (straight from at&t) version of sam. s:(([A-Z][a-z]*[ ]?)+)[ ]+([0-9]+):NAME \1\nPHONE 205 \2\n:g ^- space tab what happened was that \2 was set to \1. i've tried it here and it works as written. let me explain what's going on, because i think you're also seeing it work correctly but it's confusing you. i tried this source: ABCD 01234 and got NAME ABCD PHONE 205 D which is correct. as it says in the manual, the \digit operators on the right side of a substitution refer to the text matched by the subexpression beginning at the digit-th left parenthesis. here \1 would refer to the match of (([A-Z][a-z]*[ ]?)+) which would be ABCD and \2 would refer to the most recent match of ([A-Z][a-z]*[ ]?) which is D confusion comes because of the nesting -- whose meaning is defined by the manual -- and the repetition operator (+) -- whose meaning is not but should be clear from any thought about the implementation. referring to the implementation is the last refuge of the writer of incomplete documentation, but i believe the behavior is reasonable. you wrote a near-nonsense expression and got near-nonsense results. i see no bug here. now you may have some input text that shows other behavior, but if so please interpret the answer carefully before deciding there's a bug. i don't deny there could be one, but nested repeated regexps can be fertile sources of confusion as well as errors. -rob From sam-fans-owner Fri Aug 4 15:15:40 1995 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24107>; Fri, 4 Aug 1995 15:12:36 -0400 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzbjg01864; Fri, 4 Aug 1995 15:12:27 -0400 Received: from rexago8.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Fri, 4 Aug 1995 15:12:19 -0400 Received: by summitis.com (smail2.5) id AA18105; 4 Aug 95 14:56:23 EDT (Fri) Received: from summitis.com by rserv1.summitis.com; Fri, 4 Aug 1995 14:55 EDT Received: from cheetah by rexsrvr2.summitis.com (AIX 3.2/UCB 5.64/4.03) id AA08749; Fri, 4 Aug 1995 14:54:56 -0400 Received: by cheetah (AIX 3.2/UCB 5.64/4.03) id AA18826; Fri, 4 Aug 1995 14:54:55 -0400 From: hc05@summitis.com Message-Id: <9508041854.AA18826@cheetah> X-Mailer: exmh version 1.6 4/21/95 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Matching shortest string in se's Date: Fri, 4 Aug 1995 15:54:54 -0400 Content-Type: text Content-Length: 467 Is there an easy way that I have missed to match blocks of code bounded by tags of multiple characters using sam? Examples would be C comments (/*..*/) or HTML tags (
...
). I've done the comments in the past by typing out the combinations of things that I don't want to match in between ,x#/\*([^*/]|\n|[^*]/|\*[^/]|\*\n)+\*/#d but the combinations expand rapidly as I try to match longer tags. Is there something else I should try? Thanks, Beirne From sam-fans-owner Thu Aug 10 15:40:12 1995 Received: from localhost by hawkwind.utcs.utoronto.ca with SMTP id <24109>; Thu, 10 Aug 1995 15:36:10 -0400 To: sam-fans Subject: Sun type 4 keyboards, X11R6, and 9term Date: Thu, 10 Aug 1995 15:36:06 -0400 From: Chris Siebenmann Message-Id: <95Aug10.153610edt.24109@hawkwind.utcs.utoronto.ca> I've recently had to move from a DEC LK201 keyboard to a Sun type 4 keyboard (on a Sparcstation 1+ running SunOS 4.1.4 and X11R6) and, while it has some virtues, I can't get the damn PageUp and PageDown keys to work in 9term (or sam, or xterm) -- which makes it much less nicer. Does anyone have the magic xmodmap or whatever incantations necessary to get them back? Many thanks in advance. - cks From sam-fans-owner Thu Aug 10 16:56:47 1995 Received: from cannon.ecf.toronto.edu ([128.100.8.5]) by hawkwind.utcs.utoronto.ca with SMTP id <24109>; Thu, 10 Aug 1995 16:55:55 -0400 Received: by cannon.ecf.toronto.edu id <3658>; Thu, 10 Aug 1995 16:55:41 -0400 From: Steve Kotsopoulos To: Chris Siebenmann Subject: Re: Sun type 4 keyboards, X11R6, and 9term Cc: sam-fans@hawkwind.utcs.toronto.edu Message-Id: <95Aug10.165541edt.3658@cannon.ecf.toronto.edu> Date: Thu, 10 Aug 1995 16:55:35 -0400 We added the following to xdm/Xsession under X11R6: # xmodmap -e "keycode 27 = Up" xmodmap -e "keycode 34 = Down" xmodmap -e "keycode 31 = Left" xmodmap -e "keycode 35 = Right" From sam-fans-owner Sun Aug 27 11:03:06 1995 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24128>; Sun, 27 Aug 1995 10:59:40 -0400 Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from gary for sam-fans@hawkwind.utcs.toronto.edu) with MHSnet; Mon, 28 Aug 1995 00:59:26 +1000 Received: from staff.cs.su.OZ.AU. by staff.cs.su.OZ.AU.; Mon, 28 Aug 1995 00:59:22 +1000 To: sam-fans@hawkwind.utcs.toronto.edu cc: trost@cloud.rain.com Subject: Acme for X Date: Sun, 27 Aug 1995 10:59:21 -0400 From: Gary Capell Message-Id: <95Aug27.105940edt.24128@hawkwind.utcs.utoronto.ca> Bill Trost and myself have written a lot of an Acme workalike for X. It's called wily. It's not ready for general release, but hackers can grab what's there and have a play. Canned blurb follows: What is Wily? Wily is an program for Unix/X/C which attempts to provide the functionality of Acme (http://plan9.att.com/plan9/doc/acme.html), which is built on Plan9/Alef. Acme/Wily provide an integrated programming/editing environment which makes good use of a 3-button mouse, with several interesting features. What state is it in? Certainly far from plug'n'play. A few people here (Basser) are using it pretty heavily already, but there's still quite a lot of work remaining. Grab it if you want to have a look/play, but expect (and please mail me) bugs. Please mail me portability fixes (but not problems). It's being jointly written on a Solaris and a FreeBSD machine. Documentation? Check out http://www.cs.su.oz.au/~gary/hobby/wily/auug.html Where do you get it? ftp://www.cs.su.oz.au/gary/wily.tgz (tar'ed, gzip'ed file) From sam-fans-owner Tue Sep 5 06:46:52 1995 Received: from emory.mathcs.emory.edu ([128.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24134>; Tue, 5 Sep 1995 06:44:06 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.16) via UUCP id AA20066 ; Tue, 5 Sep 95 06:43:55 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Tue, 5 Sep 95 06:02 EDT Message-Id: Date: Tue, 5 Sep 1995 06:02:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: 9fans@cse.purdue.edu, sam-fans@hawkwind.utcs.utoronto.ca Subject: wily under SunOS [Apologies to those of you who'll see this twice.] Here is what I had to do to get wily going under SunOS. Your mileage may vary, as a lot of this was done after initial compiles, and most of this is from memory. It should be enough though to get you going. Wily comes up and stays up, I didn't do any actual editing with it yet. First, make this change to include/u.h: *** u.h.orig Tue Sep 5 05:48:40 1995 --- u.h Mon Sep 4 23:13:54 1995 *************** *** 45,52 **** --- 45,55 ---- #endif /* UMIPS */ #ifdef SUNOS + #ifdef _POSIX_SOURCE typedef unsigned short ushort; + #endif typedef unsigned long ulong; + typedef unsigned int uint; extern char *strerror(int); extern void *memmove(void*, const void*, size_t); extern void *memcpy(void*, const void*, size_t); Second, cut this file out and put it in the top level directory as `sun.ed' and run it. ----------------------- cut here ------------------------- #!/bin/sh echo "patching libframe/frbox.c" cp -p libframe/frbox.c libframe/frbox.c.dist ed libframe/frbox.c << EOF /.*f->box.*=.*realloc/c f->box = f->box ? realloc(f->box, f->nalloc*sizeof(Frbox)) : malloc(f->nalloc*sizeof(Frbox)); From sam-fans-owner Thu Sep 14 08:55:09 1995 Received: from cegelecproj.co.uk ([159.245.72.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24148>; Thu, 14 Sep 1995 08:52:36 -0400 Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA13224; Thu, 14 Sep 95 13:52:21 BST Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4) id AA16703; Thu, 14 Sep 1995 13:52:18 +0100 Received: from phantom (localhost) by phantom.cegelecproj.co.uk (5.0/SMI-SVR4) id AA29674; Thu, 14 Sep 1995 13:52:14 +0100 Message-Id: <9509141252.AA29674@phantom.cegelecproj.co.uk> X-Mailer: exmh version 1.6.1 5/23/95 To: sam-fans@hawkwind.utcs.toronto.edu Subject: @ X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 X-Planation: X-Faces can be viewed with Faces from cs.indiana.edu. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Sep 1995 08:52:13 -0400 From: Steve_Kilbane Content-Length: 205 The original sam paper says that '@' means "any character" in regexps, but this is not supported in the versions currently available (UNIX and Plan 9). I was just wondering why it was taken out... steve From sam-fans-owner Tue Oct 24 14:29:02 1995 Received: from minster.cs.york.ac.uk ([144.32.16.26]) by hawkwind.utcs.utoronto.ca with SMTP id <24226>; Tue, 24 Oct 1995 14:24:25 -0400 From: mhw@minster.york.ac.uk Message-ID: >From: mhw@minster.york.ac.uk (Mark H. Wilkinson) Date: Tue, 24 Oct 1995 14:02:16 -0400 X-Url: http://Dcpu1.cs.york.ac.uk:6666/~mhw/ X-PGP-Fingerprint: 8E 43 1E D7 85 42 E0 C5 D3 8C B6 B1 EE 06 95 64 X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: sam-fans@hawkwind.utcs.toronto.edu (sam mailing list) Subject: gcc -fno-builtin The Makefiles which come with sam have traditionally mandated the -fno-builtin flag for gcc to stop it creating special versions of some functions. Does anyone know the reason behind this? Does gcc generate bad code without the flag? Does anyone have a stable version of sam compiled by gcc without this flag set? -Mark. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark H. Wilkinson : Research student in user University of York, England : interface management systems From sam-fans-owner Sat Nov 25 14:22:22 1995 Received: from taurus.math.tau.ac.il ([132.67.64.4]) by hawkwind.utcs.utoronto.ca with SMTP id <24226>; Sat, 25 Nov 1995 14:01:54 -0500 Received: from scorpio.math.tau.ac.il (laden@scorpio.math.tau.ac.il [132.67.64.13]) by taurus.math.tau.ac.il (8.6.10/math) with ESMTP id UAA17068 for ; Sat, 25 Nov 1995 20:59:34 +0200 From: Guy Laden Received: (laden@localhost) by scorpio.math.tau.ac.il (8.6.9/8.6.9) id UAA18125 for sam-fans@hawkwind.utcs.toronto.edu; Sat, 25 Nov 1995 20:59:32 +0200 Message-Id: <199511251859.UAA18125@scorpio.math.tau.ac.il> Subject: Structural regular expressions To: sam-fans@hawkwind.utcs.toronto.edu Date: Sat, 25 Nov 1995 13:59:32 -0500 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 280 People on this list might be interested in a new tool called 'cgrep'. Its a simple and very expressive grep-like tool which fans of sam-like regexps will enjoy. Its available from ftp://plg.uwaterloo.ca/pub/mt/cgrep. Browse around under .../mt/.. for some relevant papers. guy. From sam-fans-owner Tue Dec 5 10:27:06 1995 Received: from gateway.roadway.com ([198.83.130.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24238>; Tue, 5 Dec 1995 10:14:37 -0500 Received: by gateway.roadway.com id AA03713 (InterLock SMTP Gateway 3.0 for sam-fans@hawkwind.utcs.toronto.edu); Tue, 5 Dec 1995 10:14:01 -0500 Message-Id: <199512051514.AA03713@gateway.roadway.com> Received: by gateway.roadway.com (Internal Mail Agent-1); Tue, 5 Dec 1995 10:14:01 -0500 From: beirnek@roadway.com (Beirne Konarski) Subject: Where is samx2? To: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) Date: Sat, 27 Jun 1970 10:28:01 -0400 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 425 Someone asked me where the samx patches are, so I looked and couldn't find them at uiuc. Do they still exist somewhere? Thanks, Beirne -- ------------------------------------------------------------------------------- Beirne Konarski | Reading maketh a full man, conference a beirnek@summitis.com | ready man, and writing an exact man. "Untouched by Scandal" | -- Francis Bacon From sam-fans-owner Tue Dec 5 18:32:58 1995 Received: from mumrik.nada.kth.se ([130.237.226.10]) by hawkwind.utcs.utoronto.ca with SMTP id <24239>; Tue, 5 Dec 1995 18:28:43 -0500 Received: from localhost (d92-dne@localhost) by mumrik.nada.kth.se (8.6.10/8.6.9) with ESMTP id AAA24845; Wed, 6 Dec 1995 00:28:30 +0100 Message-Id: <199512052328.AAA24845@mumrik.nada.kth.se> To: beirnek@roadway.com (Beirne Konarski) cc: sam-fans@hawkwind.utcs.toronto.edu (Sam mailing list) Subject: Re: Where is samx2? In-reply-to: Your message of "Sat, 27 Jun 1970 10:28:01 -0400." <199512051514.AA03713@gateway.roadway.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24843.818206106.1@mumrik.nada.kth.se> Date: Tue, 5 Dec 1995 18:28:28 -0500 From: Daniel Neri I found them at ftp://ftp.funet.fi/pub/unix/editors/sam/samx2/ /Daniel -- Daniel Neri d92-dne@nada.kth.se (MIME) From sam-fans-owner Wed Jan 31 16:01:12 1996 Received: from alpha.xerox.com ([13.1.64.93]) by hawkwind.utcs.utoronto.ca with SMTP id <23978>; Wed, 31 Jan 1996 15:55:45 -0500 Received: from clam.Intran.Xerox.COM ([13.243.212.2]) by alpha.xerox.com with SMTP id <15099(5)>; Wed, 31 Jan 1996 12:54:47 PST Received: from mangrove.swamp (mangrove.Intran.Xerox.COM) by clam.Intran.Xerox.COM (4.1/SMI-4.1) id AA03028; Wed, 31 Jan 96 14:58:02 CST Date: Wed, 31 Jan 1996 15:58:02 -0500 From: seebs@intran.xerox.com (Peter Seebach) Message-Id: <9601312058.AA03028@clam.Intran.Xerox.COM> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Help with libXg, sunos 4.1.4, X11R6... libXg, as distributed with my version-free sam.msg (shell archive) builds without complaints, but linked with my X11R6 libs, gets mysterious errors from the test program, and fatal coredumping ones from samterm. It appeared to work with openwin's libXt. Can anyone suggest a way to figure out whether this is a bug in libXg, or a bug in libXt? -s From sam-fans-owner Wed Feb 28 23:54:32 1996 Received: from oldp.nmsu.edu ([128.123.26.31]) by hawkwind.utcs.utoronto.ca with SMTP id <24028>; Wed, 28 Feb 1996 23:44:18 -0500 Received: by oldp.nmsu.edu; id AA26267; Wed, 28 Feb 1996 21:43:44 -0700 Date: Wed, 28 Feb 1996 23:43:44 -0500 From: Alan Watson Message-Id: <9602290443.AA26267@oldp.nmsu.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term & rlogin I've just compiled 9term v1.6.6 on a DEC Alpha OSF/1 v3.2. I used a Makefile identical Makefile.matty.alpha with the exception of BINDIR. I can't seem to get rlogin to work with it. The rc on the remote machine runs .rcrc, spits out a prompt, and then the connection gets closed. rlogin works fine from an xterm and telnet works fine from both an xterm and a 9term. The behaviour is the same connecting to both OSF/1 and Solaris machines. Bright ideas, anyone? Alan From sam-fans-owner Thu Feb 29 00:05:36 1996 Received: from solutions.solon.com ([192.129.84.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24029>; Thu, 29 Feb 1996 00:01:45 -0500 Received: (from seebs@localhost) by solutions.solon.com (8.6.12/8.6.12) id XAA04791; Wed, 28 Feb 1996 23:02:21 -0600 Date: Thu, 29 Feb 1996 00:02:21 -0500 From: Peter Seebach Message-Id: <199602290502.XAA04791@solutions.solon.com> To: alan@oldp.nmsu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term & rlogin Hmm. That's better than I got; on SunOS 4.1.3, I couldn't even get it to run consistently. (Although I've since found that a lot of libXg apps were failing because of bugs in my X server, and this may apply to other stuff too.) What's the canonical site to pick up new versions of all these things from? -s From sam-fans-owner Sat Mar 2 02:41:55 1996 Received: from oldp.nmsu.edu ([128.123.26.31]) by hawkwind.utcs.utoronto.ca with SMTP id <24028>; Sat, 2 Mar 1996 02:34:57 -0500 Received: by oldp.nmsu.edu; id AA01907; Fri, 1 Mar 1996 23:22:56 -0700 Date: Sat, 2 Mar 1996 01:22:56 -0500 From: Alan Watson Message-Id: <9603020622.AA01907@oldp.nmsu.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term and rlogin Running rlogin 8-bit clean seems to have fixed the problem. I have no idea why. Alan From sam-fans-owner Mon Jun 24 14:55:44 1996 Received: from research.att.com ([192.20.225.4]) by hawkwind.utcs.utoronto.ca with SMTP id <35213>; Mon, 24 Jun 1996 14:43:40 -0400 Received: from slocum by ns; Wed Apr 3 01:07:30 EST 1996 Date: Wed, 3 Apr 1996 01:07:00 -0500 From: Russ Cox To: sam-fans@hawkwind.utcs.toronto.edu Subject: 8 1/2 for Unix? Message-Id: <96Jun24.144340edt.35213@hawkwind.utcs.utoronto.ca> In rob's paper on 8 1/2, he suggests that someone port it to Unix just to show that its not plan9 dependant. Has anyone seen such a port? (I know of 9wm, 9term, etc, but I mean an actual window system, not something that sits on X). If this is the wrong place, let me know. Thanks. Russ From sam-fans-owner Mon Jun 24 14:58:58 1996 Received: from lendal.york.ac.uk ([144.32.128.21]) by hawkwind.utcs.utoronto.ca with SMTP id <35215>; Mon, 24 Jun 1996 14:58:17 -0400 Received: from ebor.york.ac.uk by lendal.york.ac.uk with SMTP (PP); Thu, 4 Apr 1996 19:46:44 +0100 Received: by ebor.york.ac.uk (950511.SGI.8.6.12.PATCH526/940406.SGI) id TAA16029; Thu, 4 Apr 1996 19:48:09 +0100 To: sam-fans@hawkwind.utcs.toronto.edu Subject: samterm dumping core on {} From: stephen Date: Thu, 4 Apr 1996 13:44:24 -0500 Message-ID: <199604041944.15598.out.badel@york.ac.uk> X-Url: http://www.york.ac.uk/~sp106/ samterm seems to respond fairly badly to an input of {} if it has no files open. ; samterm: host mesg: count 4864 1x 0x 19x ...ignored 2 samterm: host mesg: count 4864 1x 0x 19x ...ignored 2 samterm: host mesg: count 4864 1x 0x 19x ...ignored 2 samterm: host mesg: count 4864 1x 0x 19x ...ignored 2 type 1 count 4864 samterm:panic: count>DATASIZE: Error 0 this doesn't occur if either you run sam -d, or sam has a file open. i don't know the samterm source well enough to track the problem down in a reasonable amount of time. any ideas? stephen ps. i havn't heard from this group for a long time, is it inactive or have i merly been unsubscribed somehow? From sam-fans-owner Mon Jun 24 14:59:20 1996 Received: from eurogate.bnr.co.uk ([192.100.101.3]) by hawkwind.utcs.utoronto.ca with SMTP id <35217>; Mon, 24 Jun 1996 14:59:04 -0400 Received: from hedera.bnr.co.uk (actually innergate.bnr.co.uk) by eurogate.bnr.co.uk with SMTP (PP); Thu, 25 Apr 1996 14:18:52 +0100 Received: from bhars54b.bnr.co.uk by hedera.bnr.co.uk with SMTP (PP); Thu, 25 Apr 1996 14:18:45 +0100 Sender: P.W.McMahon@bnr.co.uk Message-ID: <317F7BB2.7DE14518@nortel.co.uk> Date: Thu, 25 Apr 1996 09:18:42 -0400 From: Paul W McMahon Organization: Nortel Technology X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam colours Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit How do I set the page colour of Sam. At the moment it is set to white but I prefer other colours. -- P.W.McMahon@nortel.co.uk From sam-fans-owner Mon Jun 24 15:19:21 1996 Received: from localhost by hawkwind.utcs.utoronto.ca with SMTP id <24391>; Mon, 24 Jun 1996 15:07:05 -0400 To: es, rc, sam-fans Subject: Status of the es/rc/sam-fans mailing lists Date: Mon, 24 Jun 1996 15:06:21 -0400 From: Chris Siebenmann Message-Id: <96Jun24.150705edt.24391@hawkwind.utcs.utoronto.ca> They're back (as you can see). I've resurrected all the messages for them from the time they were down. Unfortunately, they are still not being run under a mailing list manager, so there's no restriction on who can send messages; fortunately spam sent to them appears to have died down (AOL apparently obtained a fairly strong injuction against the major spammer). They will be converted to subscribers-only posting at some point in the future; I just thought it would be better to have them existing in the mean time. - cks From sam-fans-owner Mon Jun 24 17:03:29 1996 Received: from alpha.xerox.com ([13.1.64.93]) by hawkwind.utcs.utoronto.ca with SMTP id <24403>; Mon, 24 Jun 1996 16:58:05 -0400 Received: from moose.intran.xerox.com ([13.243.212.3]) by alpha.xerox.com with SMTP id <15446(6)>; Mon, 24 Jun 1996 13:23:10 PDT Received: from mangrove.swamp (mangrove.intran.xerox.com) by moose.intran.xerox.com (4.1/SMI-4.1) id AA03236; Mon, 24 Jun 96 14:21:55 CDT Date: Mon, 24 Jun 1996 15:21:55 -0400 From: seebs@intran.xerox.com (Peter Seebach) Message-Id: <9606241921.AA03236@moose.intran.xerox.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 8 1/2 for Unix? I haven't seen one. You could implement one which sat on X, but which basically opened the root window and took it over. You would have a *very* hard time avoiding that dependancy, as graphics hardware varies. But if you wrote one which used a window, you could do pretty well. -s From sam-fans-owner Mon Jun 24 17:54:44 1996 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24392>; Mon, 24 Jun 1996 17:52:59 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12684>; Mon, 24 Jun 1996 17:52:46 -0400 To: stephen cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: samterm dumping core on {} In-reply-to: Your message of "Thu, 04 Apr 1996 13:44:24 EST." <199604041944.15598.out.badel@york.ac.uk> Date: Mon, 24 Jun 1996 17:52:39 -0400 From: Scott Schwartz Message-Id: <96Jun24.175246edt.12684@galapagos.cse.psu.edu> Wasn't there a fix for this on the 9fans list? From sam-fans-owner Mon Jun 24 17:56:45 1996 Received: from lendal.york.ac.uk ([144.32.128.21]) by hawkwind.utcs.utoronto.ca with SMTP id <24395>; Mon, 24 Jun 1996 17:56:28 -0400 Received: from ebor.york.ac.uk by lendal.york.ac.uk with SMTP (PP); Mon, 24 Jun 1996 22:53:59 +0100 Received: by ebor.york.ac.uk (950511.SGI.8.6.12.PATCH526/940406.SGI) id WAA28643; Mon, 24 Jun 1996 22:55:53 +0100 To: Scott Schwartz Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: samterm dumping core on {} From: stephen Date: Mon, 24 Jun 1996 17:54:03 -0400 In-Reply-To: <96Jun24.175246edt.12684@galapagos.cse.psu.edu> Message-ID: <199606242254.28447.out.bajey@york.ac.uk> X-Url: http://www.york.ac.uk/~sp106/ > Wasn't there a fix for this on the 9fans list? yes. the post to samfans was before the one to 9fans, but the one to samfans has only just surfaced. stephen From sam-fans-owner Tue Jun 25 12:44:44 1996 Received: from plan9.bell-labs.com ([204.178.16.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24393>; Tue, 25 Jun 1996 12:43:09 -0400 From: "bob flandrena" To: sam-fans@hawkwind.utcs.toronto.edu Date: Tue, 25 Jun 1996 12:21:17 -0400 Message-Id: <96Jun25.124309edt.24393@hawkwind.utcs.utoronto.ca> > samterm seems to respond fairly badly to an input of {} > if it has no files open. i posted a fix to this several months ago: % diff /n/dump/1995/0401/sys/src/cmd/sam/xec.c xec.c 29c29 < !utfrune("bBnqUXY!{", cp->cmdc) && --- > !utfrune("bBnqUXY!", cp->cmdc) && 33c33 < if(cmdtab[i].defaddr != aNo){ --- > if(i >= 0 && cmdtab[i].defaddr != aNo){ there are several other bug patches for sam in the boddle package available by anonymous ftp at plan9.att.com in plan9/update/cmd/sam/829146783.rc. the diff's are relative to the plan 9 version of sam and require rc to unpack, but are easy to extract by hand and apply to the unix version. From sam-fans-owner Thu Jul 11 12:45:35 1996 Received: from oldp.nmsu.edu ([128.123.26.31]) by hawkwind.utcs.utoronto.ca with SMTP id <24401>; Thu, 11 Jul 1996 12:38:02 -0400 Received: by oldp.nmsu.edu; id AA15151; Thu, 11 Jul 1996 10:37:33 -0600 Date: Thu, 11 Jul 1996 12:37:33 -0400 From: Alan Watson Message-Id: <9607111637.AA15151@oldp.nmsu.edu> To: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Subject: UTF support for mailx Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I've hacked together support for UTF in mailx. It does the things you might expect: converting to and from 7-bit MIME encodings and the ISO-8859-X character sets where appropriate. See http://charon.nmsu.edu/~awatson/utf-mailx/ I've been using it for a few months now, so it should be fairly stable. If you find bugs, though, please let me know. Alan From sam-fans-owner Sat Aug 3 02:47:51 1996 Received: from comoro.yorku.ca ([130.63.236.55]) by hawkwind.utcs.utoronto.ca with SMTP id <24432>; Sat, 3 Aug 1996 02:40:17 -0400 Received: from nexus.yorku.ca (nexus.yorku.ca [130.63.236.20]) by comoro.yorku.ca (8.6.12/8.6.11) with ESMTP id CAA25487 for ; Sat, 3 Aug 1996 02:40:03 -0400 Received: from localhost (localhost.yorku.ca [127.0.0.1]) by nexus.yorku.ca (8.6.11/8.6.11) with SMTP id CAA11455 for ; Sat, 3 Aug 1996 02:40:00 -0400 Message-Id: <199608030640.CAA11455@nexus.yorku.ca> To: sam-fans@hawkwind.utcs.toronto.edu Date: Sat, 3 Aug 1996 02:40:00 -0400 From: "ozan s. yigit" > there are several other bug patches for sam in > the boddle package available by anonymous > ftp at plan9.att.com in plan9/update/cmd/sam/829146783.rc. here is a version that patch understands, so somewhat easier to extract and apply: *** cmd.c.orig Sat Aug 3 02:08:53 1996 --- cmd.c Sat Aug 3 02:09:23 1996 *************** *** 220,223 **** --- 220,226 ---- (ocurfile!=curfile || (!loaded && curfile->state!=Unread))) outTs(Hcurrent, curfile->tag); + /* don't allow type ahead on files that aren't bound */ + if(downloaded && curfile && curfile->rasp == 0) + terminp = termoutp; } } *** mesg.c.orig Sat Aug 3 02:08:52 1996 --- mesg.c Sat Aug 3 02:09:23 1996 *************** *** 257,260 **** --- 257,261 ---- case Tstartfile: + termlocked++; f = whichfile(inshort()); if(!f->rasp) /* this might be a duplicate message */ *************** *** 264,268 **** outTs(Hcurrent, f->tag); journaln(0, f->tag); - termlocked++; if(f->state == Unread) load(f); --- 265,268 ---- *************** *** 447,454 **** c = 0; i = 0; ! rp = malloc((snarfbuf->nrunes)*sizeof(Rune)); if(rp){ ! Bread(snarfbuf, rp, snarfbuf->nrunes, 0); ! c = Strtoc(tmprstr(rp, snarfbuf->nrunes)); free(rp); i = strlen(c); --- 447,459 ---- c = 0; i = 0; ! m = snarfbuf->nrunes; ! if(m > 32000) { /* tmprstr stores len in a short */ ! m = 32000; ! dprint("?warning: snarf buffer truncated\n"); ! } ! rp = malloc(m*sizeof(Rune)); if(rp){ ! Bread(snarfbuf, rp, m, 0); ! c = Strtoc(tmprstr(rp, m)); free(rp); i = strlen(c); *** sam.c.orig Sat Aug 3 02:08:50 1996 --- sam.c Sat Aug 3 02:09:24 1996 *************** *** 304,309 **** if(f==cmd) /* cmd gets done in main() */ continue; ! if(f->deleted) delete(f); if(f->mod==modnum && Fupdate(f, FALSE, downloaded)) anymod++; --- 304,311 ---- if(f==cmd) /* cmd gets done in main() */ continue; ! if(f->deleted) { delete(f); + continue; + } if(f->mod==modnum && Fupdate(f, FALSE, downloaded)) anymod++; *** xec.c.orig Sat Aug 3 02:08:50 1996 --- xec.c Sat Aug 3 02:09:24 1996 *************** *** 28,36 **** load(f); if(f==0 && (cp->addr==0 || cp->addr->type!='"') && ! !utfrune("bBnqUXY!{", cp->cmdc) && cp->cmdc!=('c'|0x100) && !(cp->cmdc=='D' && cp->ctext)) error(Enofile); i = lookup(cp->cmdc); ! if(cmdtab[i].defaddr != aNo){ if((ap=cp->addr)==0 && cp->cmdc!='\n'){ cp->addr = ap = newaddr(); --- 28,36 ---- load(f); if(f==0 && (cp->addr==0 || cp->addr->type!='"') && ! !utfrune("bBnqUXY!", cp->cmdc) && cp->cmdc!=('c'|0x100) && !(cp->cmdc=='D' && cp->ctext)) error(Enofile); i = lookup(cp->cmdc); ! if(i >= 0 && cmdtab[i].defaddr != aNo){ if((ap=cp->addr)==0 && cp->cmdc!='\n'){ cp->addr = ap = newaddr(); From sam-fans-owner Wed Aug 7 06:47:51 1996 Received: from emory.mathcs.emory.edu ([199.76.28.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24435>; Wed, 7 Aug 1996 06:45:42 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.22) via UUCP id AA13341 ; Wed, 7 Aug 96 06:45:21 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Wed, 7 Aug 96 06:31 EDT Message-Id: Date: Wed, 7 Aug 1996 06:31:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: sam-fans@hawkwind.utcs.toronto.edu In-Reply-To: <199608030640.CAA11455@nexus.yorku.ca> Subject: changes to sam X-Mailer: [XMailTool v3.1.2] > > there are several other bug patches for sam in > > the boddle package available by anonymous > > ftp at plan9.att.com in plan9/update/cmd/sam/829146783.rc. > > here is a version that patch understands, so somewhat easier > to extract and apply: Bobf has kindly packaged up a fresh distribution. It's at the usual place, ftp://netlib.bell-labs.com/research/dist/sam.shar.Z (or something close, that's from memory). I'm running it now. Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold@skeeve.ATL.GA.US | exponentially in the UUCP: emory!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins From sam-fans-owner Wed Aug 7 12:45:24 1996 Received: from orpheus.amdahl.com ([129.212.11.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24436>; Wed, 7 Aug 1996 12:44:36 -0400 Received: from amdahl.uts.amdahl.com by orpheus.amdahl.com with smtp (Smail3.1.29.1 #3) id m0uoBhv-0001Z5C; Wed, 7 Aug 96 09:43 PDT Received: by amdahl.uts.amdahl.com (/\==/\ Smail #25.1) id ; Wed, 7 Aug 96 17:44 BST Message-Id: X-Mailer: exmh version 1.6.7 5/3/96 To: arnold@skeeve.atl.ga.us (Arnold D. Robbins) cc: sam-fans@hawkwind.utcs.utoronto.ca Subject: Re: changes to sam In-reply-to: Your message of "Wed, 07 Aug 1996 06:31:00 EDT." X-URL: http://www.ccc.amdahl.com/~azcb0/agc.html X-Face: #XtQ?n%i%L2\|+cxl=,udz?jb=ZdVifqKtWh\j%[t%SpPO/J;r0V7jB2Q4[YOM6-\GQJf1- \}3/^-jzZl.WT^3-W\?aB::;?9B:FE53y > Bobf has kindly packaged up a fresh distribution. It's at the > usual place, ftp://netlib.bell-labs.com/research/dist/sam.shar.Z > (or something close, that's from memory). At the risk of seeming retentive in the bottom department, the URL is ftp://netlib.bell-labs.com/netlib/research/sam.shar.Z Looks like there's also a fairly new awk bundle there too. Alistair From sam-fans-owner Wed Aug 7 13:14:12 1996 Received: from emory.mathcs.emory.edu ([199.76.28.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24437>; Wed, 7 Aug 1996 13:13:42 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.22) via UUCP id AA21221 ; Wed, 7 Aug 96 13:13:13 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Wed, 7 Aug 96 12:54 EDT Message-Id: Date: Wed, 7 Aug 1996 12:54:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: new sam dist > From: erik qunastrom > > >ftp://netlib.bell-labs.com/research/dist/sam.shar.Z > > it's not there. the newest sam i could find anywhere > was in /plan9/... /sam.unix. it was dated oct 1995. Ooops. It's /netlib/research/sam.shar.Z. Enjoy. Arnold From sam-fans-owner Wed Aug 7 23:41:57 1996 Received: from netra.soft.net ([164.164.128.17]) by hawkwind.utcs.utoronto.ca with SMTP id <24437>; Wed, 7 Aug 1996 23:40:01 -0400 Received: from samar.sas.soft.net (sas.sas.soft.net) by netra.soft.net (5.x/SMI-SVR4) id AA27475; Thu, 8 Aug 1996 09:06:11 +0500 Received: from sassun20.sas.soft.net (sassun20 [164.164.56.20]) by samar.sas.soft.net (8.7.5/8.7.5) with ESMTP id JAA13403 for ; Thu, 8 Aug 1996 09:09:34 +0500 Received: from sassun6.soft.net (sassun6 [164.164.56.6]) by sassun20.sas.soft.net (8.7.1/8.7.1) with SMTP id JAA19896 for ; Thu, 8 Aug 1996 09:11:22 +0500 (GMT+0500) Date: Thu, 8 Aug 1996 00:11:22 -0400 From: Kiran Pamnany Message-Id: <199608080411.JAA19896@sassun20.sas.soft.net> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: changes to sam | > Bobf has kindly packaged up a fresh distribution. It's at the | > usual place, ftp://netlib.bell-labs.com/research/dist/sam.shar.Z | > (or something close, that's from memory). | | At the risk of seeming retentive in the bottom department, the URL is | ftp://netlib.bell-labs.com/netlib/research/sam.shar.Z | Look what happened when I tried to get it: --- snip --- samar:~$ ftp netlib.bell-labs.com. Connected to netlib.bell-labs.com. 20 Plan 9 FTP server ready Name (netlib.bell-labs.com.:kp): anonymous 421 Service not available, remote server has closed connection Login failed. No control connection for command: No such file or directory ftp> quit samar:~$ --- snip --- This happened many times, yesterday and today. I'm trying to ftp from sas.sas.soft.net. What's wrong? --Kiran From sam-fans-owner Mon Aug 12 01:26:29 1996 Received: from emory.mathcs.emory.edu ([199.76.28.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24436>; Mon, 12 Aug 1996 01:24:40 -0400 Received: from skeeve.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.22) via UUCP id AA16112 ; Mon, 12 Aug 96 01:24:24 -0400 Return-Path: arnold@skeeve.atl.ga.us Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Sun, 11 Aug 96 22:53 EDT Message-Id: Date: Sun, 11 Aug 1996 22:53:00 -0400 From: arnold@skeeve.atl.ga.us (Arnold D. Robbins) Subject: Re: changes to sam In-Reply-To: To: sam-fans@hawkwind.utcs.toronto.edu X-Mailer: [XMailTool v3.1.2] > At the risk of seeming retentive in the bottom department, the URL is > ftp://netlib.bell-labs.com/netlib/research/sam.shar.Z > > Looks like there's also a fairly new awk bundle there too. Yes, the awk is bwk's latest. Has a number of minor but useful gawk extensions in it, many of which I motivated bwk to include. :-) Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold@skeeve.ATL.GA.US | exponentially in the UUCP: emory!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins From sam-fans-owner Mon Aug 19 19:55:40 1996 Received: from answerman.mindspring.com ([204.180.128.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24445>; Mon, 19 Aug 1996 19:49:35 -0400 Received: from borg.mindspring.com (borg.mindspring.com [204.180.128.14]) by answerman.mindspring.com (8.6.12/8.6.12) with ESMTP id TAA24193 for ; Mon, 19 Aug 1996 19:49:20 -0400 Received: from infographix.com (mail.infographix.com [205.245.85.25]) by borg.mindspring.com (8.6.12/8.6.12) with SMTP id TAA14961 for ; Mon, 19 Aug 1996 19:49:16 -0400 Received: by infographix.com (5.x/SMI-SVR4) id AA20485; Mon, 19 Aug 1996 19:45:34 -0400 Date: Mon, 19 Aug 1996 19:45:34 -0400 From: arnold@infographix.com (Arnold D. Robbins) Message-Id: <9608192345.AA20485@infographix.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term and $DISPLAY Should 9term be putting the current display (from -display) into the environment? I find it frustrating to start up a 9term from a remote machine to my local one (I have scripts and stuff from 9menu to do it) and have to set my DISPLAY each time so I can run sam or other things. Any reason not to? It seems that xterm does, for whatever that's worth. Arnold From sam-fans-owner Tue Aug 20 00:08:03 1996 Received: from galapagos.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.ca with SMTP id <24447>; Tue, 20 Aug 1996 00:07:20 -0400 Received: from localhost by galapagos.cse.psu.edu with SMTP id <12690>; Tue, 20 Aug 1996 00:06:55 -0400 To: arnold@infographix.com (Arnold D. Robbins) cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term and $DISPLAY In-reply-to: Your message of "Mon, 19 Aug 1996 19:45:34 EDT." <9608192345.AA20485@infographix.com> Date: Tue, 20 Aug 1996 00:06:43 -0400 From: Scott Schwartz Message-Id: <96Aug20.000655edt.12690@galapagos.cse.psu.edu> arnold@infographix.com (Arnold D. Robbins) writes: | Should 9term be putting the current display (from -display) into | the environment? I find it frustrating to start up a 9term from a remote | machine to my local one (I have scripts and stuff from 9menu to do it) | and have to set my DISPLAY each time so I can run sam or other things. | | Any reason not to? It seems that xterm does, for whatever that's worth. It definately should. I've been running with this (in display.c) for a long time now: setenv("DISPLAY", XDisplayString(_dpy), 1); I thought I sent out patches for that, but maybe I forgot. From sam-fans-owner Sun Aug 25 15:31:30 1996 Received: from itchy.mindspring.com ([204.180.128.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24454>; Sun, 25 Aug 1996 15:29:00 -0400 Received: from borg.mindspring.com (borg.mindspring.com [204.180.128.14]) by itchy.mindspring.com (8.7.5/8.7.3) with ESMTP id PAA10488 for ; Sun, 25 Aug 1996 15:28:50 -0400 (EDT) Received: from infographix.com (mail.infographix.com [205.245.85.25]) by borg.mindspring.com (8.6.12/8.6.12) with SMTP id PAA16714 for ; Sun, 25 Aug 1996 15:28:48 -0400 Received: by infographix.com (5.x/SMI-SVR4) id AA25678; Sun, 25 Aug 1996 15:24:50 -0400 Date: Sun, 25 Aug 1996 15:24:50 -0400 From: arnold@infographix.com (Arnold D. Robbins) Message-Id: <9608251924.AA25678@infographix.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term & solaris, interupt char Is it just me, or does the latest 9term (1.6.6) not do interupt characters on solaris? I would almost swear that it used to work just fine, then I switched recently to the latest version. I'm pretty sure it works ok at home under SunOS 4.1.3... Thanks, Arnold From sam-fans-owner Tue Oct 29 15:05:53 1996 Received: from itchy.mindspring.com ([204.180.128.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24520>; Tue, 29 Oct 1996 14:58:04 -0500 Received: from colorstar.com. (borg.mindspring.com [204.180.128.14]) by itchy.mindspring.com (8.7.5/8.7.3) with SMTP id OAA04738 for ; Tue, 29 Oct 1996 14:57:22 -0500 (EST) Received: by colorstar.com. (5.x/SMI-SVR4) id AA18029; Tue, 29 Oct 1996 14:52:12 -0500 Date: Tue, 29 Oct 1996 14:52:12 -0500 From: arnold@colorstar.com (Arnold D. Robbins) Illegal-Object: Syntax error in Message-Id: value found on hawkwind.utcs.utoronto.ca: Message-Id: <9610291952.AA18029@colorstar.com.> ^-illegal subdomain in domain To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term on linux? I have sam compiled and running on SparcLinux. I'd like to get 9term going. Does anyone have any patches for 9term? Linux 2.0.22, Redhat 4.0. Thanks, Arnold Robbins Star Imaging L.L.C. Phone: +1-404-523-4944 250 Williams Street, Suite 1120, Atlanta, GA 30303 Fax: +1-404-523-4882 E-mail: arnold.robbins@colorstar.com "Oh! Look at all those zeros!" --- Chana Robbins, at age 3.5 From sam-fans-owner Tue Nov 26 14:42:27 1996 Received: from nbivms.nbi.dk ([130.225.212.16]) by hawkwind.utcs.utoronto.ca with SMTP id <24588>; Tue, 26 Nov 1996 14:37:21 -0500 Received: from felix.nbi.dk by nbivms.nbi.dk (PMDF V5.0-7 #14490) id <01ICAUH0FWFK8WZUJX@nbivms.nbi.dk> for sam-fans@hawkwind.utcs.toronto.edu; Tue, 26 Nov 1996 12:00:44 +0100 Received: by felix.nbi.dk (NX5.67d/NX3.0S) id AA00659; Tue, 26 Nov 1996 11:58:47 +0100 Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) Date: Tue, 26 Nov 1996 05:58:47 -0500 From: Ronnie Mainieri Subject: Sam on Alpha To: sam-fans@hawkwind.utcs.toronto.edu Reply-to: ronnie@nbi.dk Message-id: <9611261058.AA00659@felix.nbi.dk> Content-transfer-encoding: 7BIT Dear Sam Fans, I need help compiling sam on a Alpha machine. I am a new user to a DEC Alpha machine runing Digital UNIX V3.2D-1 and could use the Makefiles and any diffs. When I compile sam I run into a malloc(p, n) error. I changed the malloc to malloc(n) and compiled it. It seems to run OK until at one point I get a sam: panic: Bread samterm: host mesg: count 28514 65x 98x 111x rt process (core dumped) < stuff deleted> samterm:panic: count>DATASIZE: Error 0 The error occurs while a samterm runing on another machine is talking to the sam on the Alpha. Any suggestions appreciated. Ronnie From sam-fans-owner Fri Jan 3 14:49:47 1997 Received: from mule0.mindspring.com ([204.180.128.166]) by hawkwind.utcs.utoronto.ca with SMTP id <24607>; Fri, 3 Jan 1997 14:47:23 -0500 Received: from colorstar.com. (mail.infographix.com [205.245.85.25]) by mule0.mindspring.com (8.8.4/8.8.4) with SMTP id OAA24524 for ; Fri, 3 Jan 1997 14:47:18 -0500 Received: by colorstar.com. (5.x/SMI-SVR4) id AA19250; Fri, 3 Jan 1997 14:40:40 -0500 Date: Fri, 3 Jan 1997 14:40:40 -0500 From: arnold@colorstar.com (Arnold D. Robbins) Illegal-Object: Syntax error in Message-Id: value found on hawkwind.utcs.utoronto.ca: Message-Id: <9701031940.AA19250@colorstar.com.> ^-illegal subdomain in domain To: sam-fans@hawkwind.utcs.utoronto.ca Subject: sam for WinNT? I know this has been asked before, but I haven't paid attention. I expect to soon be working on WindozeNT, and would prefer to not have to leave sam behind. I would hope that a libg for NT would be enough to get the rest of sam going, but don't know. Does anyone know of a port of sam to NT? [ I probably won't reply for a while; heading to USENIX next week. ] Thanks, Arnold Robbins Star Imaging L.L.C. Phone: +1-404-523-4944 250 Williams Street, Suite 1120, Atlanta, GA 30303 Fax: +1-404-523-4882 E-mail: arnold.robbins@colorstar.com "Oh! Look at all those zeros!" --- Chana Robbins, at age 3.5 From sam-fans-owner Fri Jan 3 16:04:17 1997 Received: from ux2.cso.uiuc.edu ([128.174.5.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24607>; Fri, 3 Jan 1997 16:03:43 -0500 Received: from 128.174.23.216 (canberra-10.slip.uiuc.edu) by ux2.cso.uiuc.edu with SMTP id AA11581 (5.67a/IDA-1.5 for ); Fri, 3 Jan 1997 15:03:30 -0600 Message-Id: <32CD749C.26F1@uiuc.edu> Date: Fri, 3 Jan 1997 16:05:42 -0500 From: Ed Kubaitis Reply-To: ejk@uiuc.edu Organization: University of Illinois - CCSO X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) Mime-Version: 1.0 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam for WinNT? References: <199701031949.AA87304@ux2.cso.uiuc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arnold D. Robbins wrote: > > I know this has been asked before, but I haven't paid attention. I expect > to soon be working on WindozeNT, and would prefer to not have to leave > sam behind. > > I would hope that a libg for NT would be enough to get the rest of sam > going, but don't know. Does anyone know of a port of sam to NT? Boy, that would be great if someone did a port. But a couple weeks ago when an NT 4.0 box landed on my desk (for a port of some security related Perl CGI stuff), I figured 'a libg for NT' was one of those things much easier said than done, especially on a platform where a C compiler is the exception rather than the rule, and didn't bother to ask:-) FWIW, I'm told that a $27 shareware editor called TextPad is probably what I want. See http://www.textpad.com/ -------------------------- Ed Kubaitis - ejk@uiuc.edu University of Illinois - Urbana - CCSO From sam-fans-owner Fri Jan 10 16:21:25 1997 Received: from bungo.wago.de ([193.101.191.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24084>; Fri, 10 Jan 1997 16:12:56 -0500 Received: by bungo.wago.de (5.0/GEN-1.2.0) via EUnet for hawkwind.utcs.toronto.edu id AA02897; Fri, 10 Jan 1997 13:11:16 --100 >Received: from cc-smtp1.wago.de by donau.wago.de (SMI-8.6/SMI-SVR4) id MAA02401; Fri, 10 Jan 1997 12:50:10 +0100 Received: from cc-smtp1.wago.de by donau.wago.de (SMI-8.6/SMI-SVR4) id MAA02401; Fri, 10 Jan 1997 12:50:10 +0100 Received: from cc:Mail by cc-smtp1.wago.de id AA852897003; Fri, 10 Jan 97 12:50:03 CET Date: Fri, 10 Jan 1997 06:50:03 -0500 From: "Simon Turner" Message-Id: <9700108528.AA852897003@cc-smtp1.wago.de> To: sam-fans@hawkwind.utcs.toronto.edu, arnold@colorstar.com (Arnold D. Robbins) Subject: Re: sam for WinNT? Content-Type: text Content-Length: 1328 Hello, I have ported sam to W95 and I use this editor most of the time. This port may well be ok for WinNT. My port of sam has left the source files a little untidy. At some point I intend to revisit the source code, make it presentable and then make it available. How soon do you need sam? For other sam-fans: Is anybody else interested in a Win95/WinNT version? I would appreciate help in testing the ported editor as I've become blind to many of it's failings. Please let me know if you are interested. simon ______________________________ Reply Separator _________________________________ Subject: sam for WinNT? Author: arnold@colorstar.com (Arnold D. Robbins) at WG-ENI-SMTP Date: 03/01/97 21:15 I know this has been asked before, but I haven't paid attention. I expect to soon be working on WindozeNT, and would prefer to not have to leave sam behind. I would hope that a libg for NT would be enough to get the rest of sam going, but don't know. Does anyone know of a port of sam to NT? [ I probably won't reply for a while; heading to USENIX next week. ] Thanks, Arnold Robbins Star Imaging L.L.C. Phone: +1-404-523-4944 250 Williams Street, Suite 1120, Atlanta, GA 30303 Fax: +1-404-523-4882 E-mail: arnold.robbins@colorstar.com "Oh! Look at all those zeros!" --- Chana Robbins, at age 3.5 From sam-fans-owner Fri Jan 10 16:57:07 1997 Received: from plan9.cs.bell-labs.com ([204.178.16.2]) by hawkwind.utcs.utoronto.ca with SMTP id <23978>; Fri, 10 Jan 1997 16:56:11 -0500 From: bobf@plan9.bell-labs.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Fri, 10 Jan 1997 16:41:40 -0500 Subject: Re: sam for WinNT? Message-Id: <97Jan10.165611est.23978@hawkwind.utcs.utoronto.ca> one of the guys in our group, sean quinlan, has a version of sam that works on NT. he started from the plan 9 version of sam, which is based on libg and not libXg, and hacked the bitblt and font handling in at a fairly low level. he plans to make it available in binary form, which should be ok for NT, when he gets the time to package it up. i have no idea when that will be, but sean or i will post an announcement to this list when it is available. From sam-fans-owner Mon Jan 13 03:04:06 1997 Received: from symbionics.co.uk ([158.43.6.17]) by hawkwind.utcs.utoronto.ca with SMTP id <23978>; Mon, 13 Jan 1997 03:02:57 -0500 Received: from symnt3.symbionics.co.uk by symbionics.co.uk (4.1/SMI-4.1) id AA16018; Mon, 13 Jan 97 08:02:28 GMT Received: by symnt3.symbionics.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC0128.36068D90@symnt3.symbionics.co.uk>; Mon, 13 Jan 1997 08:03:07 -0000 Message-Id: From: Nigel Roles To: "'sam-fans@hawkwind.utcs.toronto.edu'" , "'simon.turner@wago.de'" Subject: RE: sam for WinNT? Date: Mon, 13 Jan 1997 03:03:05 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 8 TEXT I can think of two people here who would willingly pawn their mother-in-laws for sam on W95. Can the source be available, as it needs hacks to meet our company coding standard? Nigel Roles, Symbionics Ltd.. > From sam-fans-owner Tue Jan 14 15:00:06 1997 Received: from plan9.cs.bell-labs.com ([204.178.16.2]) by hawkwind.utcs.utoronto.ca with SMTP id <23978>; Tue, 14 Jan 1997 14:56:32 -0500 From: bobf@plan9.bell-labs.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Tue, 14 Jan 1997 14:52:26 -0500 Message-Id: <97Jan14.145632est.23978@hawkwind.utcs.utoronto.ca> i asked sean and he said that the reason he wasn't considering releasing the source is that he doesn't have the time to properly package it. ------ forwarded message follows ------ >From hawkwind.utcs.toronto.edu!sam-fans-owner Mon Jan 13 03:06:48 EST 1997 Received: from hawkwind.utcs.utoronto.ca by plan9; Mon Jan 13 03:06:48 EST 1997 Received: from symbionics.co.uk ([158.43.6.17]) by hawkwind.utcs.utoronto.ca with SMTP id <23978>; Mon, 13 Jan 1997 03:02:57 -0500 Received: from symnt3.symbionics.co.uk by symbionics.co.uk (4.1/SMI-4.1) id AA16018; Mon, 13 Jan 97 08:02:28 GMT Received: by symnt3.symbionics.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC0128.36068D90@symnt3.symbionics.co.uk>; Mon, 13 Jan 1997 08:03:07 -0000 Message-Id: From: Nigel Roles To: "'sam-fans@hawkwind.utcs.toronto.edu'" , "'simon.turner@wago.de'" Subject: RE: sam for WinNT? Date: Mon, 13 Jan 1997 03:03:05 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 8 TEXT I can think of two people here who would willingly pawn their mother-in-laws for sam on W95. Can the source be available, as it needs hacks to meet our company coding standard? Nigel Roles, Symbionics Ltd.. > From sam-fans-owner Wed Feb 12 15:08:43 1997 Received: from plan9.cs.bell-labs.com ([204.178.16.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24614>; Wed, 12 Feb 1997 15:05:01 -0500 From: seanq@plan9.bell-labs.com To: sam-fans@hawkwind.utcs.toronto.edu Date: Wed, 12 Feb 1997 14:53:14 -0500 Message-Id: <97Feb12.150501est.24614@hawkwind.utcs.utoronto.ca> By request, there is now a Windows 95/NT version of Sam. This version of sam is currently distributed in binary form only. The packaged can by obtained from http://netlib.bell-labs.com/netlib/research/index by selecting the file sam-win.zip Comments and bug reports can be sent to seanq@research.bell-labs.com From sam-fans-owner Mon Feb 17 11:32:20 1997 Received: from oberon.info-com.com ([194.72.127.140]) by hawkwind.utcs.utoronto.ca with SMTP id <24620>; Mon, 17 Feb 1997 11:28:59 -0500 Received: from goose.info-com.com (localhost [127.0.0.1]) by oberon.info-com.com (8.7.5/8.7.2) with SMTP id QAA15328 for ; Mon, 17 Feb 1997 16:26:38 GMT Message-Id: <3.0.32.19970217162635.006bb15c@oberon.info-com.com> X-Sender: pete@oberon.info-com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Feb 1997 11:26:39 -0500 To: sam-fans@hawkwind.utcs.toronto.edu From: Pete Fenelon Subject: sam for 95/nt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" In summary -- a lovely piece of work. Just what we've all been waiting for. One minor caveat, though -- under 95 (don't know about NT) it adopts the Unix-y (and indeed right-thinking) LF as newline.... which means it's not ideal for editing Windows text files which use CR/LF -- (A) it shows the CR half of CR/LF as a CR character and (B) it makes it a tad tricky to use files produced with Sam with utilities that aren't wise to the rest of the world's conventions on newline... I suppose this is the *logically* correct behaviour, but to push Sam as an editor which the Windows-user community will use, perhaps it should do the wrong but *visually* sensible thing :) Thoughts -- would it be difficult to bodge sam to treat CR/LF as one rune under Windows? pete -- Pete Fenelon, Infocom UK Ltd. pete.fenelon@info-com.com --MimeMultipartBoundary-- From sam-fans-owner Mon Feb 17 11:35:59 1997 Received: from symbionics.co.uk ([194.32.100.60]) by hawkwind.utcs.utoronto.ca with SMTP id <24626>; Mon, 17 Feb 1997 11:35:41 -0500 Received: from symnt3.symbionics.co.uk by symbionics.co.uk (4.1/SMI-4.1) id AA03917; Mon, 17 Feb 97 16:35:18 GMT Received: by symnt3.symbionics.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC1CF0.8D1BF640@symnt3.symbionics.co.uk>; Mon, 17 Feb 1997 16:35:14 -0000 Message-Id: From: Nigel Roles To: "'sam-fans@hawkwind.utcs.toronto.edu'" Subject: RE: sam for 95/nt Date: Mon, 17 Feb 1997 11:35:13 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 33 TEXT I modified the UNIX version to do CRLF translation, N space indentation, and tab to space conversion to observe our company coding standard. Not difficult. --------------- Nigel Roles, Symbionics Ltd.. >---------- >From: Pete Fenelon[SMTP:pete.fenelon@info-com.com] >Sent: 17 February 1997 16:26 >To: sam-fans@hawkwind.utcs.toronto.edu >Subject: sam for 95/nt > >In summary -- a lovely piece of work. Just what we've all been waiting for. > >One minor caveat, though -- under 95 (don't know about NT) it adopts the >Unix-y (and indeed right-thinking) LF as newline.... which means it's not >ideal for editing Windows text files which use CR/LF -- (A) it shows the CR >half of CR/LF as a CR character and (B) it makes it a tad tricky to use >files produced with Sam with utilities that aren't wise to the rest of the >world's conventions on newline... > >I suppose this is the *logically* correct behaviour, but to push Sam as an >editor which the Windows-user community will use, perhaps it should do the >wrong but *visually* sensible thing :) > >Thoughts -- would it be difficult to bodge sam to treat CR/LF as one rune >under Windows? > >pete >-- >Pete Fenelon, Infocom UK Ltd. pete.fenelon@info-com.com > From sam-fans-owner Mon Feb 17 11:57:44 1997 Received: from p9att.att.com ([135.205.33.187]) by hawkwind.utcs.utoronto.ca with SMTP id <24620>; Mon, 17 Feb 1997 11:55:07 -0500 From: rsc@research.att.com Date: Mon, 17 Feb 1997 11:54:19 -0500 To: pete.fenelon@info-com.com, sam-fans@hawkwind.utcs.toronto.edu Subject: re: sam for 95/nt Message-Id: <97Feb17.115507est.24620@hawkwind.utcs.utoronto.ca> One minor caveat, though -- under 95 (don't know about NT) it adopts the Unix-y (and indeed right-thinking) LF as newline.... which means it's not ideal for editing Windows text files which use CR/LF -- (A) it shows the CR half of CR/LF as a CR character and (B) it makes it a tad tricky to use files produced with Sam with utilities that aren't wise to the rest of the world's conventions on newline... Making a file with the commands ,s///g ,s/$//g is helpful, the sam equivalent of /acme/edit/guide. (I haven't figured out how to type a CR, and just copy them from other text files). Another way to add CR's is to open and close the file in MS-DOS Edit. One thing that would be very nice is if Shift-Right Button brought up the middle button menu (cut-paste-etc.), as it does in Plan 9. Russ From sam-fans-owner Mon Feb 17 12:03:57 1997 Received: from kissimmee.infomkt.ibm.com ([204.146.129.20]) by hawkwind.utcs.utoronto.ca with SMTP id <24627>; Mon, 17 Feb 1997 12:03:41 -0500 Received: from dingler.dev.infomkt.ibm.com (dingler.dev.infomkt.ibm.com [204.146.132.31]) by kissimmee.infomkt.ibm.com (8.6.10/8.6.10) with ESMTP id LAA25238 for ; Mon, 17 Feb 1997 11:58:11 -0500 Received: (from quanstro@localhost) by dingler.dev.infomkt.ibm.com (8.7.5/8.7.3) id MAA106172 for sam-fans@hawkwind.utcs.toronto.edu; Mon, 17 Feb 1997 12:01:05 -0500 Date: Mon, 17 Feb 1997 12:01:05 -0500 Message-Id: <199702171701.MAA106172@dingler.dev.infomkt.ibm.com> To: sam-fans@hawkwind.utcs.toronto.edu From: erik quanstrom Subject: re: sam for 95/nt >(I haven't figured out how to type a CR, and just copy them from other text files). X000d where is usually the key. i don't know if this works on the win{nt,95} version From sam-fans-owner Mon Feb 17 12:19:07 1997 Received: from irwell.zetnet.co.uk ([194.72.245.189]) by hawkwind.utcs.utoronto.ca with SMTP id <24628>; Mon, 17 Feb 1997 12:18:07 -0500 Received: from goose.info-com.com (148.info-com.com [194.72.127.148]) by irwell.zetnet.co.uk (8.7.6/8.7.3) with SMTP id RAA13021; Mon, 17 Feb 1997 17:17:28 GMT Message-Id: <3.0.32.19970217171441.006d4e98@mail.zetnet.co.uk> X-Sender: pete.fenelon@mail.zetnet.co.uk X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Feb 1997 12:15:13 -0500 To: quanstro@Infomkt.ibm.com From: Pete Fenelon Subject: re: sam for 95/nt Cc: sam-fans@hawkwind.utcs.toronto.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:01 17/02/97 -0500, you wrote: >>(I haven't figured out how to type a CR, and just copy them from other text files). > > X000d > >where is usually the key. i don't know if this works on the win{nt,95} >version ALT-nnn (using the numeric keypad keys) is the way of entering characters by code under Windows. ALT-013 duplicates the effects of the RETURN key, however, and for some odd reason ALT-010 inserts the C/R character -- not quite what I'd expect! Strange but true :) pete -- Pete Fenelon, 39 Broadway, Fulford, York, YO1 4JP Tel: +44 1904 670334 pete.fenelon@zetnet.co.uk "I could tell you, but only at consultancy rates". From sam-fans-owner Mon Feb 17 23:44:12 1997 Received: from star.vec.net ([208.133.32.5]) by hawkwind.utcs.utoronto.ca with SMTP id <24629>; Mon, 17 Feb 1997 23:41:42 -0500 Received: from skeeve by vec.net (MX V4.2 VAX) with UUCP; Mon, 17 Feb 1997 23:40:00 EST Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Mon, 17 Feb 97 23:02 EST Message-ID: Date: Mon, 17 Feb 1997 23:02:00 -0500 From: To: sam-fans@hawkwind.utcs.toronto.edu Subject: re: sam for 95/nt X-Mailer: [XMailTool v3.1.2] > (I haven't figured out how to type a CR, and just copy them from other > text files). Control-m works just fine for me under Unix. Haven't tried the NT version yet. Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold@gnu.ai.mit.edu | exponentially in the UUCP: dragon!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins From sam-fans-owner Fri Feb 21 09:34:02 1997 Received: from orpheus.amdahl.com ([129.212.11.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24623>; Fri, 21 Feb 1997 09:31:22 -0500 Received: from juts.ccc.amdahl.com by orpheus.amdahl.com with smtp (Smail3.1.29.1 #3) id m0vxw0H-00011dC; Fri, 21 Feb 97 06:31 PST Received: by juts.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.6) id ; Fri, 21 Feb 97 06:31 PST Received: by juno.ccc.amdahl.com (/\==/\ Smail #25.1) id ; Fri, 21 Feb 97 06:31 PST Message-Id: X-Mailer: exmh version 1.6.9 8/22/96 To: sam-fans@hawkwind.utcs.utoronto.ca Subject: ssam-1.6 and libutf-2.7 X-Face: #XtQ?n%i%L2\|+cxl=,udz?jb=ZdVifqKtWh\j%[t%SpPO/J;r0V7jB2Q4[YOM6-\GQJf1- \}3/^-jzZl.WT^3-W\?aB::;?9B:FE53y [This has already been posted to the wily list. At the risk of offending those people who will thus see this message twice, I thought some folks here might be interested. - agc] I've made available new versions of libutf, some utf routines including UTF-aware regular expressions, and ssam, a stream editor using the sam command set. Please note the namechange, and the new URLs: http://www.westley.demon.co.uk/ssam-1.6.tar.gz http://www.westley.demon.co.uk/utf-2.7.tar.gz A complete list of changes follows at the end of this mail, but the changes to ssam are mainly cosmetic and bug fixes, whilst I have started implementing language-specific matching and ordering, using a function called utflangcmp(). Many thanks to Bengt Kleberg (Bengt.Kleberg@uab.ericsson.se) for the provision of Swedish, Finnish, Danish and Norwegian alphabets. As usual, the correct way to install the software is: % tar xvzf utf-2.7.tar.gz % cd utf-2.7 % ./configure % make tst % make install % cd .. % tar xvzf ssam-1.6.tar.gz % cd ssam-1.6 % ./configure % make tst % make install This release has been tested on UTS 4.3.2 (S390 mainframe), Solaris 2.4 (SS5), and NetBSD/i386 1.2C. Take care, Alistair ssam-1.6 changes + tarted up explanation code, and added a test + moved stuff around in ssam() + moved ure match arrays from the program stack to within ssam_t. We now allocate space for the match offsets when we know how many we'll need. This removes the hardcoded limit on subexpressions. + implemented a saner way of introducing default `p' command. We now do this when parsing, rather than on execution. Removes some cruft from execution functions. + ran gcc -Wall again, and cleaned up miscellaneous warnings, changing configure.in etc on the way. + added code to free match array, if requested via flags. Modify existing free checks, so that de-allocation takes place if storage was allocated, not if it was used. + re-code 'x' and 'y' commands to take advantage of improved ure ^ matching code. 'g', 'v' and 's' commands are unaffected. This is actually a significant speedup, especially when searching for anchored matches in large strings/files. + split writing files part of ssam() out into ssamcommit(), and call it accordingly. This gives us more control over file writing. + changed Makefile to track change to the name of the library + deleted "urelang.h", which doesn't exist anymore, and added "utf.h" utf-2.7 changes + fixed a bug in ^ matching - anchored searches were only tried once, which didn't take into account the case where the string to be matched included newline characters. + re-arrange tests so that error tests are done at end. Add a test for anchored beginning of line matching + added utflangcmp function, with a couple of supporting functions to get ordinal number of bits. Added findword test program, and one extra test case. + Swedish and Finnish alphabets from Bengt.Kleberg@uab.ericsson.se (Bengt Kleberg) + changed langcoll.utf file so that letters in brackets [] in an alphabet have the same collation ordering (e.g. v and w in Swedish) Modified all utf functions that use utfrune on the alphabets accordingly + bug fix for definition of ETCDIR - not incorporated in previous changes from Alan Watson (my mistake) + renamed library from libure to libutf (at suggestion of Alan Watson). Changed Makefile to make this possible. + fixed bug where v and w in Swedish weren't comparing as the same letter. + Norwegian and Danish alphabets from Bengt.Kleberg@uab.ericsson.se (Bengt Kleberg) + fixed a bug whereby language names were occasionally misconstrued (the old "English not found, using English" problem) From sam-fans-owner Sun Feb 23 19:17:09 1997 Received: from oldp.nmsu.edu ([128.123.26.31]) by hawkwind.utcs.utoronto.ca with SMTP id <24623>; Sun, 23 Feb 1997 19:15:09 -0500 Received: by oldp.nmsu.edu; id AA28769; Sun, 23 Feb 1997 17:15:03 -0700 Date: Sun, 23 Feb 1997 19:15:03 -0500 From: Alan Watson Message-Id: <9702240015.AA28769@oldp.nmsu.edu> To: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Subject: utftools-1.4 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I've written UTF-aware versions of wc, fmt, expand, and unexpand for UNIX. You can grab them from: http://www.pobox.com/~amw/software/utftools-1.5.tar.gz You will need Alistair Crooks' libutf, which you can get from: http://www.westley.demon.co.uk/utf-2.7.tar.gz Many thanks to Alistair for pointing out numerous errors and typos in the v1.1 man pages and an incompatibility between the behaviour of my wc and traditional UNIX wcs. Alan Watson From sam-fans-owner Mon Feb 24 11:37:27 1997 Received: from orpheus.amdahl.com ([129.212.11.6]) by hawkwind.utcs.utoronto.ca with SMTP id <24623>; Mon, 24 Feb 1997 11:29:47 -0500 Received: from juts.ccc.amdahl.com by orpheus.amdahl.com with smtp (Smail3.1.29.1 #3) id m0vz3HY-00018SC; Mon, 24 Feb 97 08:29 PST Received: by juts.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.6) id ; Mon, 24 Feb 97 08:29 PST Received: by juno.ccc.amdahl.com (/\==/\ Smail #25.1) id ; Mon, 24 Feb 97 08:29 PST Message-Id: X-Mailer: exmh version 1.6.9 8/22/96 To: wilyfans@jli.com cc: sam-fans@hawkwind.utcs.utoronto.ca Subject: libutf-2.8 and ssam-1.7 X-Face: #XtQ?n%i%L2\|+cxl=,udz?jb=ZdVifqKtWh\j%[t%SpPO/J;r0V7jB2Q4[YOM6-\GQJf1- \}3/^-jzZl.WT^3-W\?aB::;?9B:FE53y It was pointed out to me that my implementation of chartorune() was braindead, and I can only agree, and I've since also discovered that my implementation of fullrune() was lacking, to such a degree that it was just plain wrong. Apologies, as this hinders Alan Watson's wc from working correctly. I've also cleaned up a bug in utf_snprintf, which was also downright silly. The new versions have been uploaded to: http://www.westley.demon.co.uk/libutf-2.8.tar.gz http://www.westley.demon.co.uk/ssam-1.7.tar.gz although they're only visible from "close of business" (my ISP's words, not mine) today, 24th February, 17:00 GMT. As usual, the correct way to install the software is as follows: % tar xvzf libutf-2.8.tar.gz % cd libutf-2.8 % ./configure % make tst % make install % cd .. % tar xvzf ssam-1.7.tar.gz % cd ssam-1.7 % ./configure % make tst % make install A list of the changes appears at the end of this mail. This has been tested on UTS 4.3.2 (S390 mainframe), Solaris 2.4 (SS5), and NetBSD/i386 1.2C. Sorry about the bugs, Alistair ssam-1.7 changes + corrected spelling of Byron Rakitzis' name in ssam.1 manual page libutf-2.8 changes + added error checking to chartorune, at suggestion of Rob Pike (rob@plan9.bell-labs.com) - now recognise `error runes', and return the Runeerror character, with unity length. The previous code ignored error runes, and blindly gave them a length of 3 bytes, probably pushing the following runes in the string `out of sync'. Woops. + added a test for error runes + check for null expressions, which can cause gurep to coredump when dereferenced on some platforms e.g. Solaris. + added a test for null expressions given as args to gurep + corrected my implementation of fullrune(), which was just plain wrong. Shown up by testing Alan Watson's UTF-aware wc. + fixed a bug whereby I didn't zero-byte-terminate the buffer in utf_snprintf - this caused occasional "language not found" errors. From sam-fans-owner Tue Feb 25 13:48:06 1997 Received: from oldp.nmsu.edu ([128.123.26.31]) by hawkwind.utcs.utoronto.ca with SMTP id <24623>; Tue, 25 Feb 1997 13:44:47 -0500 Received: by oldp.nmsu.edu; id AA25458; Tue, 25 Feb 1997 11:44:32 -0700 Date: Tue, 25 Feb 1997 13:44:32 -0500 From: Alan Watson Message-Id: <9702251844.AA25458@oldp.nmsu.edu> To: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Subject: utftools-1.6 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit New versions of my UTF-aware wc, fmt, expand, and unexpand for UNIX are available from: http://www.pobox.com/~Alan.Watson/software/utftools-1.6.tar.gz You will need Alistair Crooks libutf library, which can be obtained from: http://www.westley.demon.co.uk/software.html The major change has been to add basic functionality checks (invoked by make check). Hopefully, that should guard against a repeat performance of the problems with v1.5, for which I apologise. Alan Watson From sam-fans-owner Mon May 5 15:06:55 1997 Received: from antaries.vec.net ([208.133.32.10]) by hawkwind.utcs.utoronto.ca with SMTP id <24655>; Mon, 5 May 1997 14:52:35 -0400 Received: from skeeve by vec.net (MX V4.2 VAX) with UUCP; Mon, 05 May 1997 06:41:39 EST Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) id ; Mon, 5 May 97 06:16 EDT Message-ID: Date: Mon, 5 May 1997 06:16:00 -0400 To: sam-fans@hawkwind.utcs.utoronto.ca Subject: new 9menu available From: arnold@gnu.ai.mit.edu X-Mailer: [XMailTool v3.1.2] I have updated my 9menu program with -fg and -bg options (contributed code). ftp://ftp.mathcs.emory.edu/pub/arnold/9menu-1.5.shar.gz is the code. Credits contained therein. Enjoy. -- Arnold Robbins Internet: arnold@gnu.ai.mit.edu IMPORTANT: The address arnold@skeeve.atl.ga.us will be GOING AWAY soon. Please make a note to change any references to me to the above GNU address. From sam-fans-owner Mon May 26 20:09:20 1997 Received: from mumrik.nada.kth.se ([130.237.226.10]) by hawkwind.utcs.utoronto.ca with SMTP id <24651>; Mon, 26 May 1997 19:30:32 -0400 Received: (from d92-dne@localhost) by mumrik.nada.kth.se (8.8.5/8.6.9) id AAA16026; Tue, 27 May 1997 00:20:27 +0200 (MET DST) To: sam-fans@hawkwind.utcs.toronto.edu Subject: where is win32 sam? From: Daniel Neri Date: Mon, 26 May 1997 18:11:10 -0400 Message-ID: <199705270011.15889.out.babod@nada.kth.se> Organization: Royal Institute of Technology, Stockholm, Sweden Greetings, I have now spent a considerable amount of time searching through my mail archives for the announcement of winNT/95 sam that was sent to this list some time ago. No luck so far, so I thought I'd ask if any of you could give me a pointer? (maybe I deleted it, thinking I would never need it ;-). TIA /Daniel From sam-fans-owner Tue May 27 04:06:57 1997 Received: from velcro.inrs-telecom.uquebec.ca ([192.26.211.119]) by hawkwind.utcs.utoronto.ca with SMTP id <24656>; Tue, 27 May 1997 01:42:35 -0400 Received: from someware.inrs-telecom.uquebec.ca by velcro.inrs-telecom.uquebec.ca with SMTP id AA06152 (5.67a/IDA-1.5 for ); Mon, 26 May 1997 21:28:53 -0400 Received: by someware.INRS-Telecom.UQuebec.CA (SMI-8.6/SMI-SVR4) id VAA10860; Mon, 26 May 1997 21:27:30 -0400 Date: Mon, 26 May 1997 21:27:30 -0400 From: gregoire@inrs-telecom.uquebec.ca (Jean Charles Gregoire) Message-Id: <199705270127.VAA10860@someware.INRS-Telecom.UQuebec.CA> To: sam-fans@hawkwind.utcs.toronto.edu Subject: RE: where is win32 sam? Daniel, Sean posted the following URL for it: http://netlib.bell-labs.com/netlib/research/index tcs doesn't seem to be bundled in though, although it would be nice for us accented letters-addicts to have a windows 95/NT binary handy (hint?). jcg From sam-fans-owner Tue May 27 16:51:09 1997 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24656>; Tue, 27 May 1997 16:48:36 -0400 Received: from pgrad.cs.su.OZ.AU. by staff.cs.su.OZ.AU.; Tue, 27 May 1997 13:00:45 +1000 X-Claimed-Received: from pgrad.su.oz.au Received: by pgrad.su.oz.au (SMI-8.6/SMI-SVR4) id NAA08483; Tue, 27 May 1997 13:00:44 +1000 Date: Mon, 26 May 1997 23:00:44 -0400 Message-Id: <199705270300.NAA08483@pgrad.su.oz.au> From: Gary Capell In-Reply-To: <199705270011.15889.out.babod@nada.kth.se> To: Daniel Neri Cc: Subject: Re: where is win32 sam? http://netlib.bell-labs.com/netlib/research/index.html Is there a sam-fans FAQ someplace? From sam-fans-owner Mon Jul 14 21:24:01 1997 Received: from abacus.plexsys.com ([207.207.206.50]) by hawkwind.utcs.utoronto.ca with SMTP id <24670>; Mon, 14 Jul 1997 21:17:55 -0400 Received: from localhost (mdash@localhost) by abacus.plexsys.com (8.7.3/8.7.3) with SMTP id AAA11963 for ; Tue, 15 Jul 1997 00:26:36 GMT From: mdash@abacus.plexsys.com Message-Id: <199707150026.AAA11963@abacus.plexsys.com> X-Authentication-Warning: abacus.plexsys.com: Host mdash@localhost didn't use HELO protocol To: sam-fans@hawkwind.utcs.toronto.edu Subject: win32 sam again IReply-to: mdash@plexsys.com Date: Mon, 14 Jul 1997 20:25:59 -0400 Any news on the win32 sam front? As nice as seanq's work is, the binary from the ftp site does not support an external B equivalent or pipe through commands. This matter has acquired a new urgency since I started a contract in an NT-only development shop. In more fork/exec-friendly environments, I frequently pipe stuff from sam through commands, but am now hobbled. --Mike Scheer, mdash@plexsys.com From sam-fans-owner Wed Jul 16 16:22:00 1997 Received: from orpheus.amdahl.com ([159.199.101.3]) by hawkwind.utcs.utoronto.ca with SMTP id <24674>; Wed, 16 Jul 1997 15:58:24 -0400 Received: from minerva.amdahl.com by orpheus.amdahl.com with smtp (Smail3.1.29.1 #3) id m0woWkC-0004kbC; Wed, 16 Jul 97 09:16 PDT Received: from juts.ccc.amdahl.com by minerva.amdahl.com with smtp (Smail3.1.29.1 #5) id m0woWjv-0002JtC; Wed, 16 Jul 97 09:15 PDT Received: by juts.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.6) id ; Wed, 16 Jul 97 09:16 PDT Received: by juno.ccc.amdahl.com (/\==/\ Smail #25.1) id ; Wed, 16 Jul 97 09:16 PDT Message-Id: To: wilyfans@jli.com cc: sam-fans@hawkwind.utcs.utoronto.ca Subject: libutf-2.9 and ssam-1.8 X-Face: #XtQ?n%i%L2\|+cxl=,udz?jb=ZdVifqKtWh\j%[t%SpPO/J;r0V7jB2Q4[YOM6-\GQJf1- \}3/^-jzZl.WT^3-W\?aB::;?9B:FE53y I've finally got around to doing some things that were on the back burner - changes outlined below, but they're just bug fixes, with some extra tests added for good measure. The new versions have been uploaded to: http://www.westley.demon.co.uk/src/libutf-2.9.tar.gz http://www.westley.demon.co.uk/src/ssam-1.8.tar.gz As usual, the correct way to install the software is as follows: % tar xvzf libutf-2.9.tar.gz % cd libutf-2.9 % ./configure % make tst % make install % cd .. % tar xvzf ssam-1.8.tar.gz % cd ssam-1.8 % ./configure % make tst % make install A list of the changes appears at the end of this mail. This has been tested on UTS 4.3.2 (S390 mainframe), Solaris 2.4 (SS5), and NetBSD/i386 1.2G. Sorry about the bugs, Alistair ssam-1.8 changes + Alan Watson (alan@oldp.nmsu.edu) pointed out a bug whereby two sequential commands cause changes to happen, and these changes cause the carefully ordered stack to be unordered. This only manifests itself where more than one pass over the file takes place. Added code to sort the changes into `from' address order, and order on deletion and insertion within that. + Added symbolic constants to the parse tables. This pushes column indentation out a bit, at the expense of making things much more understandable. + Byron Rakitzis (byron@netapp.com) pointed out an anomaly with sam, whereby a nul-byte terminated expression was allowed in sam, but produced an error in ssam. Eventually found time to fix this. Removed UnterminatedArg error constant and message, and change tests accordingly. libutf-2.9 changes + zero-byte terminate the arrays we copy in utfcpy + sort out utf_snprintf so that stdargs are handled correctly - I don't know if it's just gcc, but shorts and chars are put on the stack as ints, so, when we pop them off the stack, pop them off as ints. From sam-fans-owner Tue Jul 29 20:32:34 1997 Received: from plan9.bell-labs.com ([204.178.31.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24651>; Tue, 29 Jul 1997 20:11:53 -0400 From: seanq@plan9.bell-labs.com Date: Tue, 29 Jul 1997 17:25:55 -0400 To: 9fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Message-Id: <97Jul29.201153edt.24651@hawkwind.utcs.utoronto.ca> For those of you that use Sam on Windows 95/NT: There is a new version which can be installed by running the self extracting executable available thru netlib. Go to http://netlib.bell-labs.com/netlib/research and select the file sam.exe, or more directly, http://netlib.bell-labs.com/netlib/research/sam.exe Major changes from the previous release include: *) The commands that run external programs now work, i.e. '<', '>', '|', '!'. Included with the distribution are several command line programs that are useful with sam, such as: pwd, echo, fmt, and sort. *) There is a 'B' command that enables sam to receive file open requests from other programs. Let me know any problems you have. seanq@research.bell-labs.com From sam-fans-owner Wed Aug 27 18:14:59 1997 Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24664>; Wed, 27 Aug 1997 16:44:03 -0400 Date: Wed, 27 Aug 1997 05:27:20 -0400 From: bruce@staff.cs.su.oz.au (Bruce Janson) To: sam-fans@hawkwind.utcs.toronto.edu Subject: libXg Message-Id: <97Aug27.164403edt.24664@hawkwind.utcs.utoronto.ca> Hi, Has anyone modified libXg so that it supports screens of ldepth > 3? Regards, Bruce Janson Email: bruce@cs.usyd.edu.au Basser Department of Computer Science Phone: +61-2-9351-3423/4 University of Sydney, N.S.W., 2006, AUSTRALIA Fax: +61-2-9351-3838 From sam-fans-owner Tue Sep 16 03:02:33 1997 Received: from grolsch.cs.ubc.ca ([142.103.6.9]) by hawkwind.utcs.utoronto.ca with SMTP id <24650>; Tue, 16 Sep 1997 02:49:53 -0400 Received: from harpo.cs.ubc.ca (harpo.cs.ubc.ca [142.103.9.5]) by grolsch.cs.ubc.ca (8.8.5/8.6.9) with ESMTP id SAA02555 for ; Mon, 15 Sep 1997 18:19:08 -0700 (PDT) Message-Id: <199709160119.SAA02555@grolsch.cs.ubc.ca> To: sam-fans@hawkwind.utcs.utoronto.ca Subject: Sam for Windows 95 and extensions Date: Mon, 15 Sep 1997 21:17:11 -0400 From: "Paul A. Lalonde" I've recently started work in a Windows-only environment, and spent part of the day installing sam (and other useful tools), but am missing the extensions I had installed in my prior existance. In particular, I'm missing being able to use the escape key to switch from the current window to the sam window. Is there an easy way to get this functionality in the Windows 95 version? Thanks, Paul Internet: lalonde@cs.ubc.ca Web: http://www.cs.ubc.ca/spider/lalonde/homepage.html "On ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux" - Antoine de St.-Exupery From sam-fans-owner Tue Oct 28 17:56:31 1997 Received: from finch.cse.psu.edu ([130.203.12.29]) by hawkwind.utcs.utoronto.ca with SMTP id <24684>; Tue, 28 Oct 1997 17:43:51 -0500 Received: (qmail 21504 invoked by uid 991); 28 Oct 1997 06:32:35 -0000 Message-ID: <19971028063235.21502.qmail@finch.cse.psu.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term bug Date: Tue, 28 Oct 1997 01:32:35 -0500 From: Scott Schwartz Hi all, I don't recall if this has been reported or not, but libtext from fails to initialize everything in a newly allocated Text. (bcheck is your friend.) =================================================================== RCS file: RCS/text.c,v retrieving revision 1.1 diff -c -r1.1 text.c *** /tmp/T0a005Fs Tue Oct 28 01:30:37 1997 --- text.c Tue Oct 28 01:23:56 1997 *************** *** 47,52 **** --- 47,53 ---- berror("textalloc: calloc"); t->length = 0; t->base = 0; + t->end = 0; t->p0 = 0; t->p1 = 0; t->pout = 0; From sam-fans-owner Fri Oct 31 19:37:31 1997 Received: from mn1.swip.net ([192.71.180.97]) by hawkwind.utcs.utoronto.ca with SMTP id <24687>; Fri, 31 Oct 1997 19:33:41 -0500 Received: by mn1.swip.net (8.8.8/2.01) id QAA03390; Fri, 31 Oct 1997 16:08:47 GMT Received: (from bengt@localhost) by trillian.softwell.se (8.8.3/8.8.3) id QAA22933; Fri, 31 Oct 1997 16:53:28 +0100 Date: Fri, 31 Oct 1997 10:53:28 -0500 From: Bengt Kleberg Message-Id: <199710311553.QAA22933@trillian.softwell.se> To: sam-fans@hawkwind.utcs.toronto.edu, schwartz@finch.cse.psu.edu Subject: Re: 9term bug > From: Scott Schwartz > I don't recall if this has been reported or not, but libtext from fails Greetings, I recompiled 9term (and libtext) to correct this bug (that had never bitten me IFAIK). During recompile I noticed something I had forgotten since last time (ages ago, since 9term is stable enough not to warrant updates every month). When compiling under linux there are some #defines, but no makefile. Has anybody produced an official one? I could submit mine, but I get warnings... Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Sat Nov 1 08:51:21 1997 Received: from milawa.psrg.cs.usyd.EDU.AU ([129.78.8.50]) by hawkwind.utcs.utoronto.ca with SMTP id <24649>; Sat, 1 Nov 1997 08:47:28 -0500 Received: (from matty@localhost) by milawa.psrg.cs.usyd.EDU.AU (8.8.7/8.8.4) id LAA28615; Sat, 1 Nov 1997 11:47:24 +1100 (EST) From: James Matthew Farrow Message-Id: <199711010047.LAA28615@milawa.psrg.cs.usyd.EDU.AU> Subject: Re: 9term bug To: bengt@softwell.se (Bengt Kleberg) Date: Fri, 31 Oct 1997 19:47:24 -0500 Cc: sam-fans@hawkwind.utcs.toronto.edu, schwartz@finch.cse.psu.edu In-Reply-To: <199710311553.QAA22933@trillian.softwell.se> from "Bengt Kleberg" at Oct 31, 97 10:53:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit > > I don't recall if this has been reported or not, but libtext from fails > > I recompiled 9term (and libtext) to correct this bug (that had > never bitten me IFAIK). During recompile I noticed something I had > forgotten since last time (ages ago, since 9term is stable enough > not to warrant updates every month). When compiling under linux > there are some #defines, but no makefile. Has anybody produced an > official one? I could submit mine, but I get warnings... I have a whole pile of bits and pieces that I've started looking at pulling together now that I've been officially released from the bondage of my Ph.D. Things are going slowly (I still feel guilty working on things I enjoy ;-) but getting there. If you want to send me stuff I'll look at putting out a new version with some of the patches I've been given over the last while. Matty. -- James Matthew Farrow | "For in that moment I beheld the ruin matty@cs.usyd.edu.au | of my existence. My world fell dark Basser Department of Computer Science | and my life became a shallow dream. Sydney University - Fax: +61 2 9351 3838| `Odi et amo. Excrucior.'" - Tlindah From sam-fans-owner Mon Nov 17 18:58:30 1997 Received: from venus.ubs.com ([207.25.52.67]) by hawkwind.utcs.utoronto.ca with SMTP id <24673>; Mon, 17 Nov 1997 18:51:00 -0500 Received: by venus.ubs.com; id LAA23510; Mon, 17 Nov 1997 11:49:50 -0500 (EST) Received: from unknown(192.168.122.22) by venus.ubs.com via smap (3.2) id xma023505; Mon, 17 Nov 97 11:49:42 -0500 Received: from ns1.ny.ubs.com by hedy.ny.ubs.com (SMI-8.6/SMI-SVR4) id LAA28283; Mon, 17 Nov 1997 11:46:33 -0500 Received: from ny.ubs.com (rousseau.ny.ubs.com [161.239.153.13]) by ns1.ny.ubs.com (8.7.3/8.7.3) with ESMTP id KAA21240; Mon, 17 Nov 1997 10:58:15 -0500 (EST) Sender: mkr@ny.ubs.com Message-ID: <3470698F.405334B5@ny.ubs.com> Date: Mon, 17 Nov 1997 10:58:07 -0500 From: "Michael K. Rosenberg" X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Pete Fenelon CC: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam for 95/nt References: <3.0.32.19970217162635.006bb15c@oberon.info-com.com> Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" --MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit has anyone dealt with this problem? in my opinion, the best solution would be that sam on nt writes a cr/lf when you hit return, and does not show the cr character. this makes the files different from ones created on unix systems, but, makes them consistent with all other text files and text utilities on nt, such as printing utilities. i guess this is what pete meant in his suggestion below. i'm keeping my fingers crossed that there is a better nt version of sam out there somewhere....otherwise, i think i'm going to be stuck with notepad. mike Pete Fenelon wrote: > One minor caveat, though -- under 95 (don't know about NT) it adopts the > Unix-y (and indeed right-thinking) LF as newline.... which means it's not > ideal for editing Windows text files which use CR/LF -- (A) it shows the CR > half of CR/LF as a CR character and (B) it makes it a tad tricky to use > files produced with Sam with utilities that aren't wise to the rest of the > world's conventions on newline... > > I suppose this is the *logically* correct behaviour, but to push Sam as an > editor which the Windows-user community will use, perhaps it should do the > wrong but *visually* sensible thing :) > > Thoughts -- would it be difficult to bodge sam to treat CR/LF as one rune > under Windows? --MimeMultipartBoundary-- From sam-fans-owner Fri Nov 28 23:38:09 1997 Received: from finch.cse.psu.edu ([130.203.12.29]) by hawkwind.utcs.utoronto.ca with SMTP id <24696>; Fri, 28 Nov 1997 22:56:25 -0500 Received: (qmail 6505 invoked by uid 991); 28 Nov 1997 22:52:38 -0000 Message-ID: <19971128225238.6504.qmail@finch.cse.psu.edu> Date: Fri, 28 Nov 1997 17:52:38 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Subject: libXg font handling improvement Date: Fri, 28 Nov 1997 17:52:38 -0500 From: Scott Schwartz Hi, As you know, libXg looks for fonts based on a filename, normally given in your xdefaults file, containing a Plan 9 style font map. That works if and only if all your X clients have the same filesystem namespace. Normally, with local NFS, that's the case, but if you ever log into some remote machine and try to run sam or 9term, the fonts probably won't be where sam has been told to look. So this patch arranges to store the font map in the X resources database. Combined with using the x font server to hold the actual fonts, this makes things work fairly nicely, without recourse to the filesystem(s). In my xinitrc I run the following to set things up: name = (char *)malloc(strlen(name)+1); if (fnt->name==0) --- 42,75 ---- free(buf); return 0; } + return buf; + } ! Font * ! rdfontfile(char *name, int ldepth) ! { ! return rdfontstring(name, file2string(name), ldepth); ! } ! ! Font* ! rdfontstring(char *name, char *s, int ldepth) ! { ! Font *fnt; ! Cachesubf *c; ! int i; ! char *buf, *t; ! struct stat sbuf; ! unsigned long min, max; ! ! buf = s; ! if (buf == 0) ! return 0; fnt = (Font *)malloc(sizeof(Font)); ! if (fnt == 0) { ! Err1: ! free(buf); ! return 0; ! } memset((void*)fnt, 0, sizeof(Font)); fnt->name = (char *)malloc(strlen(name)+1); if (fnt->name==0) *** /tmp/T0a001XK Fri Nov 28 15:05:48 1997 --- libXg/xtbinit.c Thu Nov 20 19:52:10 1997 *************** *** 181,187 **** font = 0; subfont = 0; if (fontname) { ! font = rdfontfile(fontname, screen.ldepth); if (!font || charwidth(font, (Rune) ' ') == 0) { subfont = getsubfont(fontname); if (!subfont) --- 181,189 ---- font = 0; subfont = 0; if (fontname) { ! font = (fontname[0] == '.' || fontname[0] == '/') ! ? rdfontfile(fontname, screen.ldepth) ! : rdfontstring("p9font", fontname, screen.ldepth); if (!font || charwidth(font, (Rune) ' ') == 0) { subfont = getsubfont(fontname); if (!subfont) *** /tmp/T0a001XK Fri Nov 28 15:05:48 1997 --- include/libg.h Thu Nov 20 19:43:54 1997 *************** *** 203,208 **** --- 203,209 ---- extern int bitbltclip(void*); extern Subfont* getsubfont(char*); extern Font *rdfontfile(char*, int); + extern Font *rdfontstring(char*, char*, int); extern void ffree(Font*); extern Font *mkfont(Subfont*); extern void subffree(Subfont*); From sam-fans-owner Fri Jan 30 18:14:00 1998 Received: from bio.cse.psu.edu ([130.203.12.29]) by hawkwind.utcs.utoronto.ca with SMTP id <24718>; Fri, 30 Jan 1998 17:05:33 -0500 Received: (qmail 19842 invoked by uid 991); 27 Jan 1998 21:47:56 -0000 Message-ID: <19980127214756.19841.qmail@bio.cse.psu.edu> Date: Tue, 27 Jan 1998 16:47:56 -0500 To: sam-fans@hawkwind.utcs.toronto.edu From: schwartz+sam-fans@bio.cse.psu.edu Subject: 9term buffer overflow Date: Tue, 27 Jan 1998 16:47:55 -0500 Sender: schwartz@bio.cse.psu.edu 9term "1.6.6 Nov 1995" (the latest?) has a problem in display.c, where a static buffer can overflow. (The font improvements for libXg that I posted a while ago can exercise this; since no one has complained I guess no one has tried those either (hmmm.)) *** /tmp/T0a004pS Tue Jan 27 16:43:03 1998 --- display.c Tue Jan 27 16:33:46 1998 *************** *** 121,126 **** --- 121,137 ---- _killpg(SIGHUP); } + static char * + str_ndup(char *p, unsigned int n) + { + char *s = malloc(n+1); + if (!s) + error("malloc failure"); + strncpy(s, p, n); + s[n] = 0; + return s; + } + /* * try to extract an X resource under a variety of names */ *************** *** 128,134 **** get_resource(char *resource, char *class, char *rname, char *cname) { char str1[256], str2[256]; - static char result[512]; XrmValue value; char *str_type; --- 139,144 ---- *************** *** 137,144 **** if (XrmGetResource( XrmGetDatabase(_dpy), str1, str2, &str_type, &value) == True) { ! strncpy(result, value.addr, (int)value.size); ! return result; } return 0; } --- 147,153 ---- if (XrmGetResource( XrmGetDatabase(_dpy), str1, str2, &str_type, &value) == True) { ! return str_ndup(value.addr, value.size); } return 0; } *************** *** 155,165 **** --- 164,176 ---- s = get_resource(resource, class, "debug", "Debug"); if (s && strcasecmp(s, "true")) { + free(s); XSetErrorHandler(error_handler); XSetIOErrorHandler(io_error_handler); } s = get_resource(resource, class, "login", "Login"); if (s && !strcasecmp(s, "true")) { + free(s); /* Change argv[0] if this is a login shell */ new = (char *)malloc(strlen(shargv[0])+2); if (!new) *************** *** 169,206 **** shargv[0] = new; } s = get_resource(resource, class, "scroll", "Scroll"); ! if (s && !strcasecmp(s, "true")) scrolling = 1; s = get_resource(resource, class, "utmp", "Utmp"); ! if (s && !strcasecmp(s, "true")) utmpentry = 1; if (s = get_resource(resource, class, "label", "Label")) { XStoreName(_dpy, XtWindow(_toplevel), s); XSetIconName(_dpy, XtWindow(_toplevel), s); XFlush(_dpy); } ! if (s = get_resource(resource, class, "ttyModes", "TtyModes")) parsettymodes(UNIX, s); ! if (s = get_resource(resource, class, "p9TtyModes", "P9TTyModes")) parsettymodes(PLAN9, s); ! if (s = get_resource(resource, class, "kbdMode", "KbdMode")) if (!strcasecmp(s, "unix")) kbdmode = UNIX; else if (!strcasecmp(s, "plan9")) kbdmode = PLAN9; ! if (s = get_resource(resource, class, "p9font", "P9font")) setenv("font", s, 1); ! if (s = get_resource(resource, class, "highwater", "Highwater")) highwater = atoi(s); ! if (s = get_resource(resource, class, "lowwater", "Lowwater")) lowwater = atoi(s); ! if (s = get_resource(resource, class, "9wm", "9Wm")) ninewm = !strcasecmp(s, "true"); if (s = get_resource(resource, class, "beep", "Beep")) { if (strstr(s, "unix")) beepmask |= UNIX; if (strstr(s, "plan9")) beepmask |= PLAN9; } } /* --- 180,237 ---- shargv[0] = new; } s = get_resource(resource, class, "scroll", "Scroll"); ! if (s && !strcasecmp(s, "true")) { ! free(s); scrolling = 1; + } s = get_resource(resource, class, "utmp", "Utmp"); ! if (s && !strcasecmp(s, "true")) { ! free(s); utmpentry = 1; + } if (s = get_resource(resource, class, "label", "Label")) { XStoreName(_dpy, XtWindow(_toplevel), s); XSetIconName(_dpy, XtWindow(_toplevel), s); XFlush(_dpy); + free(s); } ! if (s = get_resource(resource, class, "ttyModes", "TtyModes")) { parsettymodes(UNIX, s); ! free(s); ! } ! if (s = get_resource(resource, class, "p9TtyModes", "P9TTyModes")) { parsettymodes(PLAN9, s); ! free(s); ! } ! if (s = get_resource(resource, class, "kbdMode", "KbdMode")) { if (!strcasecmp(s, "unix")) kbdmode = UNIX; else if (!strcasecmp(s, "plan9")) kbdmode = PLAN9; ! free(s); ! } ! if (s = get_resource(resource, class, "p9font", "P9font")) { setenv("font", s, 1); ! free(s); ! } ! if (s = get_resource(resource, class, "highwater", "Highwater")) { highwater = atoi(s); ! free(s); ! } ! if (s = get_resource(resource, class, "lowwater", "Lowwater")) { lowwater = atoi(s); ! free(s); ! } ! if (s = get_resource(resource, class, "9wm", "9Wm")) { ninewm = !strcasecmp(s, "true"); + free(s); + } if (s = get_resource(resource, class, "beep", "Beep")) { if (strstr(s, "unix")) beepmask |= UNIX; if (strstr(s, "plan9")) beepmask |= PLAN9; + free(s); } } /* From sam-fans-owner Thu May 7 16:37:47 1998 Received: from plan9.bell-labs.com ([204.178.31.2]) by hawkwind.utcs.utoronto.ca with SMTP id <24706>; Thu, 7 May 1998 16:35:12 -0400 Date: Thu, 7 May 1998 14:24:30 -0400 To: sam-fans@hawkwind.utcs.toronto.edu From: "bob flandrena" Message-Id: <98May7.163512edt.24706@hawkwind.utcs.utoronto.ca> a new sam bundle is available at ftp://plan9.bell-labs.com/netlib/research/sam.shar.gz there is no new functionality; just a couple of minor bugs fixed since the last release and references to AT&T in the boilerplate changed to Lucent. This version is almost completely untested, so the usual use-at-your-own-risk warnings apply. as a bonus, the package contains a port of the Plan 9 regular expression library. it is not used by sam, but is provided for play. From sam-fans-owner Thu Sep 17 03:42:20 1998 Received: from post.mail.demon.net ([194.217.242.40]) by hawkwind.utcs.utoronto.ca with SMTP id <24851>; Thu, 17 Sep 1998 02:29:59 -0400 Received: from [212.228.106.206] (helo=kremvax.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.02 #1) id 0zJ4wT-0001xm-00; Tue, 15 Sep 1998 23:55:34 +0000 Received: (from mhw@localhost) by kremvax.demon.co.uk (8.8.7/8.8.7) id AAA29001; Wed, 16 Sep 1998 00:18:51 +0100 To: bobf@research.bell-labs.com cc: sam-fans@hawkwind.utcs.toronto.edu Subject: libXg bug fix From: "Mark H. Wilkinson" Date: Tue, 15 Sep 1998 19:03:28 -0400 Message-ID: <199809160003.28896.out.badoz@kremvax.demon.co.uk> X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 This fixes a bug in ffree() in sam's libXg. c is a pointer to a structure within an array of such structures, and as such shouldn't be free'd. The later call to free(f->subf) frees the whole array. I should point out that sam doesn't actually call ffree() anywhere, so it's not going to fall over because of this. Other programs might. -Mark. Index: rdfontfile.c =================================================================== RCS file: /u/cvs/9libs/libXg/rdfontfile.c,v retrieving revision 1.4 retrieving revision 1.5 diff -C4 -r1.4 -r1.5 *** rdfontfile.c 1998/08/11 00:20:44 1.4 --- rdfontfile.c 1998/09/15 23:03:22 1.5 *************** *** 126,134 **** c = f->subf+i; if (c->f) subffree(c->f); free(c->name); - free(c); } free(f->subf); free(f); } --- 126,133 ---- From sam-fans-owner Wed Jan 20 19:52:02 1999 Received: from mail.eclipse.net ([207.207.192.13]) by hawkwind.utcs.utoronto.ca with SMTP id <25135>; Wed, 20 Jan 1999 18:51:44 -0500 Received: from cnj1-06-48.eclipse.net (cnj1-06-48.eclipse.net [207.207.244.48]) by mail.eclipse.net (8.9.1a/8.9.1) with SMTP id JAA20369 for ; Wed, 20 Jan 1999 09:02:13 -0500 (EST) From: mdash@plexsys.com (Michael D. Scheer) To: sam-fans@hawkwind.utcs.toronto.edu Subject: sam on win32 Date: Wed, 20 Jan 1999 09:02:11 -0500 Message-ID: <36a5e163.219826@mail.eclipse.net> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Is this list still active? I haven't seen traffic in months, it seems. What is the current state of efforts to get sam onto win32? seanq's port does not seem to have been updated in a while. Anybody tried the X11 version over Korn's uwin or Cygnus's cygwin? Thanks. --Mike Scheer, mdash@plexsys.com, 908-273-1885 From sam-fans-owner Thu Jan 21 16:29:12 1999 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.utoronto.ca with SMTP id <24723>; Thu, 21 Jan 1999 15:44:14 -0500 Received: (qmail 7491 invoked by uid 991); 21 Jan 1999 00:54:59 -0000 Message-ID: <19990121005459.7490.qmail@g.bio.cse.psu.edu> Date: Wed, 20 Jan 1999 19:54:59 -0500 to: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam on win32 In-reply-to: Your message of "Wed, 20 Jan 1999 09:02:11 EST." <36a5e163.219826@mail.eclipse.net> Date: Wed, 20 Jan 1999 19:54:59 -0500 From: Scott Schwartz mdash@plexsys.com (Michael D. Scheer) writes: | Is this list still active? I haven't seen traffic in months, it | seems. That's the benefit of ancient and stable software. :-) From sam-fans-owner Thu Jan 21 16:29:17 1999 Received: from repop2.jps.net ([209.63.224.239]) by hawkwind.utcs.utoronto.ca with SMTP id <24881>; Thu, 21 Jan 1999 15:45:23 -0500 Received: from 6625hvt3r227 (209-239-201-39.oak.jps.net [209.239.201.39]) by repop2.jps.net (8.9.0/8.8.5) with ESMTP id KAA12011; Thu, 21 Jan 1999 10:47:29 -0800 (PST) Message-Id: <199901211847.KAA12011@repop2.jps.net> From: "Chaotrope" To: "Michael D. Scheer" , Subject: Re: sam on win32 Date: Thu, 21 Jan 1999 13:39:52 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On: Wednesday, January 20, 1999: ---------- > From: Michael D. Scheer > To: sam-fans@hawkwind.utcs.toronto.edu > Subject: sam on win32 > What is the current state of efforts to get sam onto win32? seanq's > port does not seem to have been updated in a while. I don't understand the 'problem' - I use the seanq version in a Win95 system with no problem (alright, it will hang sometimes, but I blame that on B. Gates) so why would it need updating? I'm so happy with sam that I've even thought of buying my own i386 clone system (work pays for what I currently use) just to run the Linux p9 "emulation" (ie, sam, wily, rc/es, 9term,9wm), even tho I swore years back that I wouldn't spend my own money on computer junk any more - too much stuff collecting in closets. - kim BTW did you notice that 'rc' is in the /bin? Nice undocumented treat. From sam-fans-owner Thu Jan 21 16:29:23 1999 Received: from blackusi03.belrose.visionet.com.au ([210.0.31.9]) by hawkwind.utcs.utoronto.ca with SMTP id <24660>; Thu, 21 Jan 1999 15:41:49 -0500 Received: from ishtek.com ([210.0.3.138]) by blackusi03.belrose.visionet.com.au (Netscape Mail Server v2.01) with SMTP id AAA4571 for ; Thu, 21 Jan 1999 11:29:58 +1100 X-Mailer: Ishtek MeeMail 2.1 In-Reply-To: <36a5e163.219826@mail.eclipse.net> Date: Wed, 20 Jan 1999 19:31:53 -0500 From: Alex Danilo Subject: Re: sam on win32 To: sam-fans@hawkwind.utcs.toronto.edu X-Face: 3}u>)koHh${W+XV18fV{i/@Sw_Cvi'3hS04kL'J-3Qoz{?D R>c6<6{LbeD5'D9+C\lUPtNBF=h=yrnT,zMx$o3YbL/p;|UGb}@0^{Tr7ppFE_sk;'p[W9,gpJ$`N2 Sp?E#o2R Message-Id: <99Jan21.154149est.24660@hawkwind.utcs.utoronto.ca> >What is the current state of efforts to get sam onto win32? seanq's >port does not seem to have been updated in a while. Anybody tried the >X11 version over Korn's uwin or Cygnus's cygwin? Yep - I had a bash at it, and it doesn't work very well. The current uwin stuff is a bit flaky as far as the X stuff goes. However, both uwin and cygnus blow up on the call to XtAppIinitialize in libXg/xtbinit.c. I also compiled up X11R6.4 and it did the same thing. Given that you need to run an X-server to get that version to run anyway, I've found it easier to just run an NFS server on the Winoze box, then run sam on another UNIX box and edit that way. Ugly, but it works. Alex P.S. I asked seanq if we could have the source of his port, but he won't release it. P.P.S. I bashed in the cursor keys, ctrl-x/c/v and Windows style delete key if anyone wants those changes. -- Alex Danilo http://www.ishtek.com/alex PO Box 333 Forestville NSW 2087 +61-2-9975-2297 From sam-fans-owner Wed Jan 27 17:41:17 1999 Received: from cssun.mathcs.emory.edu ([170.140.150.1]) by hawkwind.utcs.utoronto.ca with SMTP id <25250>; Wed, 27 Jan 1999 16:56:23 -0500 Received: from dilbert.mathcs.emory.edu (dilbert [170.140.150.6]) by cssun.mathcs.emory.edu (8.9.1b+Sun/8.9.1) with ESMTP id KAA23791 for ; Tue, 26 Jan 1999 10:43:28 -0500 (EST) Received: from gold2.gezernet.co.il (gold2.gezernet.co.il [192.115.7.75]) by dilbert.mathcs.emory.edu (8.9.1b+Sun/8.9.1) with SMTP id KAA20063 for ; Tue, 26 Jan 1999 10:43:05 -0500 (EST) Message-Id: <199901261543.KAA20063@dilbert.mathcs.emory.edu> From: Aharon Robbins Date: Tue, 26 Jan 1999 10:35:45 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Subject: 9term under Linux? I know this has come up before, but I don't remember the answers... Has anyone got patches to 9term 1.6.6 for Linux? I have it built, but hold mode isn't working. And with the latest rc as the shell, input characters are not echoed. I'm using Redhat 5.2, if that matters. Thanks, Arnold -- Aharon (a.k.a. Arnold) Robbins arnold@gnu.org P.O. Box 354 Home Phone: +972 8 979-0381 Nof Ayalon Cell Phone: +972 51 297-545 D.N. Shimshon 99784 Laundry increases exponentially in the ISRAEL number of children. -- Miriam Robbins From sam-fans-owner Wed Jan 27 17:50:26 1999 Received: from repop1.jps.net ([209.63.224.238]) by hawkwind.utcs.utoronto.ca with SMTP id <24767>; Wed, 27 Jan 1999 16:42:43 -0500 Received: from 6625hvt3r227 (209-239-204-85.oak.jps.net [209.239.204.85]) by repop1.jps.net (8.8.5/8.8.5) with ESMTP id PAA22622; Thu, 21 Jan 1999 15:56:41 -0800 (PST) Message-Id: <199901212356.PAA22622@repop1.jps.net> From: "Chaotrope" To: "Alex Danilo" , Subject: Re: sam on win32 Date: Thu, 21 Jan 1999 18:57:41 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wednesday, January 20, 1999 > Alex Danilo > To: sam-fans@hawkwind.utcs.toronto.edu > Subject: Re: sam on win32 said > P.S. I asked seanq if we could have the source of his port, but he won't > release it. > P.P.S. I bashed in the cursor keys, ctrl-x/c/v and Windows style delete key > if anyone wants those changes. > -- > Alex Danilo http://www.ishtek.com/alex > PO Box 333 Forestville NSW 2087 +61-2-9975-2297 > seanq's Win95/NT version of sam implements the Crtl-X/C/V as well as allowing Crl-W to delete the word to the left of the cursor, and Ctrl-U to delete leftwards to beginning of line (I think these are remnants of 8-1/2). And if you want source, I remember in the list-archives a mail from someone who had ported sam to Win; they might be willing to pass it on. (and speaking of source, even if someone gets the Win32.exe, they should also get sam.shar because that includes a troff -ms encoded tutorial on using sam, something that is sorely needed, especially as the PDF of the 1987 paper doesn't print back-ticks (') so the one big example of changing 'n' to 'num' reads incorrectly) - kim From sam-fans-owner Thu Jan 28 11:34:42 1999 Received: from cssun.mathcs.emory.edu ([170.140.150.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24927>; Thu, 28 Jan 1999 11:21:17 -0500 Received: from dilbert.mathcs.emory.edu (dilbert [170.140.150.6]) by cssun.mathcs.emory.edu (8.9.1b+Sun/8.9.1) with ESMTP id IAA26672 for ; Thu, 28 Jan 1999 08:35:41 -0500 (EST) Received: from gold2.gezernet.co.il (gold2.gezernet.co.il [192.115.7.75]) by dilbert.mathcs.emory.edu (8.9.1b+Sun/8.9.1) with SMTP id IAA19617 for ; Thu, 28 Jan 1999 08:34:52 -0500 (EST) Message-Id: <199901281334.IAA19617@dilbert.mathcs.emory.edu> From: Aharon Robbins Date: Thu, 28 Jan 1999 08:02:48 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Subject: more on my 9term Hmmm. Control-c for interrupt doesn't work on the 9term I just built.... Maybe Bengt's version is better? I tried to build 9term 1.6.3 with the research!rsc patch file, and it is still much worse than the patched 1.6.6. Sigh. Nothing like portability. ☺ Arnold -- Aharon (a.k.a. Arnold) Robbins arnold@gnu.org P.O. Box 354 Home Phone: +972 8 979-0381 Nof Ayalon Cell Phone: +972 51 297-545 D.N. Shimshon 99784 Laundry increases exponentially in the ISRAEL number of children. -- Miriam Robbins From sam-fans-owner Thu Jan 28 11:38:28 1999 Received: from cssun.mathcs.emory.edu ([170.140.150.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24917>; Thu, 28 Jan 1999 11:16:05 -0500 Received: from dilbert.mathcs.emory.edu (dilbert [170.140.150.6]) by cssun.mathcs.emory.edu (8.9.1b+Sun/8.9.1) with ESMTP id GAA23241; Thu, 28 Jan 1999 06:46:05 -0500 (EST) Received: from gold2.gezernet.co.il (gold2.gezernet.co.il [192.115.7.75]) by dilbert.mathcs.emory.edu (8.9.1b+Sun/8.9.1) with SMTP id GAA19439; Thu, 28 Jan 1999 06:45:42 -0500 (EST) Message-Id: <199901281145.GAA19439@dilbert.mathcs.emory.edu> From: Aharon Robbins Date: Thu, 28 Jan 1999 06:33:33 -0500 To: Jim.Robinson@Stanford.Edu Subject: Re: 9term under Linux? Cc: sam-fans@hawkwind.utcs.toronto.edu Me: > > I know this has come up before, but I don't remember the answers... > > Has anyone got patches to 9term 1.6.6 for Linux? I have it built, but > > hold mode isn't working. And with the latest rc as the shell, > > input characters are not echoed. > > > > I'm using Redhat 5.2, if that matters. From: "James A. Robinson" > Yes, I have it working. As I recall, I had to nab a patch off the net. A > quick search gave this: http://cm.bell-labs.com/who/rsc/linux/9term.patch > which I think is what I used. This is for 1.6.3. But it was enough to get me started. After a whopping 5 minutes of testing, rc and hold mode work. Here's a diff against the 1.6.6 sources. I can supply the makefile I used too, if anyone wants it; the main thing is to define _POSIX_SOURCE and LINUX. Now, to try restarting X with 9wm as the window manager... Much thanks! Arnold -------------------------------- *** 9term.c.dist Thu Sep 28 06:16:15 1995 --- 9term.c Thu Jan 28 13:15:36 1999 *************** *** 10,16 **** #include #include ! #ifdef SOLARIS #include #else #include --- 10,16 ---- #include #include ! #if defined SOLARIS || defined LINUX #include #else #include *** 9term.h.dist Tue Nov 28 07:27:04 1995 --- 9term.h Thu Jan 28 13:14:56 1999 *************** *** 30,35 **** --- 30,39 ---- extern int echo; extern int isig; + #if defined(LINUX) + #define setenv p9term_setenv + #endif + extern void specialchars(int); extern int setenv(char *, char *, int); extern void init_display(int *, char **, char**, char*); *************** *** 87,90 **** --- 91,99 ---- #if defined(SOLARIS) #define POSIXPTYS #define REMOTE + #endif + + #if defined(LINUX) + #define POSIXPTYS + #define BSDPTYS #endif *** display.c.dist Thu Oct 5 09:55:54 1995 --- display.c Thu Jan 28 13:10:28 1999 *************** *** 275,280 **** --- 275,287 ---- { int width, height; + static int called=0; + + if (called) { + /*fprintf(stderr, "ereshaped called twice\n");*/ + return; + } + called = 1; if (ninewm) { /* work around textsetrects wierdness */ r = inset(r, -3); *************** *** 286,291 **** --- 293,299 ---- tty_set_size(comm_fd, width, height, Dx(text->r), Dy(text->r)); setborder(); } + called = 0; } /* *** pty.c.dist Tue Nov 28 07:30:45 1995 --- pty.c Thu Jan 28 13:22:07 1999 *************** *** 60,73 **** # define V_FLUSH VFLUSH #endif ! #ifdef linux # define V_START VSTART # define V_STOP VSTOP # define V_SUSP VSUSP # define V_DSUSP VDSUSP # define V_RPRNT VREPRINT # define V_WERAS VWERASE - # define V_FLUSH VFLUSH #endif #ifdef HPUX --- 60,73 ---- # define V_FLUSH VFLUSH #endif ! #ifdef LINUX ! #include # define V_START VSTART # define V_STOP VSTOP # define V_SUSP VSUSP # define V_DSUSP VDSUSP # define V_RPRNT VREPRINT # define V_WERAS VWERASE #endif #ifdef HPUX *************** *** 304,309 **** --- 304,312 ---- ttmode.c_lflag |= ECHO; ttmode.c_oflag &= ~(ONLCR); ttmode.c_oflag |= ONLRET; + #ifdef LINUX + ttmode.c_lflag |= ICANON; + #endif } else { ttmode.c_iflag = BRKINT | IGNPAR | ICRNL | IXON; ttmode.c_oflag = OPOST | ONLRET; -- Aharon (a.k.a. Arnold) Robbins arnold@gnu.org P.O. Box 354 Home Phone: +972 8 979-0381 Nof Ayalon Cell Phone: +972 51 297-545 D.N. Shimshon 99784 Laundry increases exponentially in the ISRAEL number of children. -- Miriam Robbins From sam-fans-owner Thu Jan 28 11:39:01 1999 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24907>; Thu, 28 Jan 1999 11:13:33 -0500 Received: from trillian.softwell.se (trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.8.5/8.8.5) with ESMTP id IAA13664; Thu, 28 Jan 1999 08:45:29 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id IAA28290; Thu, 28 Jan 1999 08:45:29 +0100 Date: Thu, 28 Jan 1999 02:45:29 -0500 From: Bengt Kleberg Message-Id: <199901280745.IAA28290@trillian.softwell.se> To: arnold@gnu.org, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term under Linux? > Has anyone got patches to 9term 1.6.6 for Linux? I have it built, but > hold mode isn't working. And with the latest rc as the shell, > input characters are not echoed. I have a 9term that works under Linux. Both hold mode and latest rc. Unfortunatly I do not remember how I built it! If nobody else steps forward with the right thing I could try and find out. Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Thu Jan 28 11:40:18 1999 Received: from aubrey.stanford.edu ([36.48.0.102]) by hawkwind.utcs.utoronto.ca with SMTP id <24660>; Thu, 28 Jan 1999 11:09:28 -0500 Received: (qmail 21358 invoked from network); 27 Jan 1999 22:24:31 -0000 Received: from localhost.stanford.edu (HELO aubrey.stanford.edu) (jimr@127.0.0.1) by localhost.stanford.edu with SMTP; 27 Jan 1999 22:24:31 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: Aharon Robbins cc: sam-fans@hawkwind.utcs.toronto.edu Dcc: Subject: Re: 9term under Linux? In-reply-to: Message from Aharon Robbins of "Tue, 26 Jan 1999 10:35:45 EST."References: <199901261543.KAA20063@dilbert.mathcs.emory.edu> <199901261543.KAA20063@dilbert.mathcs.emory.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21346.917475870.1@aubrey.stanford.edu> Date: Wed, 27 Jan 1999 17:24:31 -0500 Sender: jimr@aubrey.stanford.edu Message-Id: <99Jan28.110928est.24660@hawkwind.utcs.utoronto.ca> > I know this has come up before, but I don't remember the answers... > Has anyone got patches to 9term 1.6.6 for Linux? I have it built, but > hold mode isn't working. And with the latest rc as the shell, > input characters are not echoed. > > I'm using Redhat 5.2, if that matters. Yes, I have it working. As I recall, I had to nab a patch off the net. A quick search gave this: http://cm.bell-labs.com/who/rsc/linux/9term.patch which I think is what I used. I've got 9term, 9wm, 9menu, wily, sam, and rc working on my system. I really love the interface! =) Jim From sam-fans-owner Thu Jan 28 11:41:21 1999 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24919>; Thu, 28 Jan 1999 11:18:40 -0500 Received: from trillian.softwell.se (trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.8.5/8.8.5) with ESMTP id NAA14462; Thu, 28 Jan 1999 13:28:31 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id NAA32236; Thu, 28 Jan 1999 13:28:30 +0100 Date: Thu, 28 Jan 1999 07:28:30 -0500 From: Bengt Kleberg Message-Id: <199901281228.NAA32236@trillian.softwell.se> To: arnold@gnu.org, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term under Linux? > Has anyone got patches to 9term 1.6.6 for Linux? I have recreated my 9term with working hold mode and echoed input characters in rc. I have a patch (created with diff -Naur as per recommendation). _However_, there is a catch. I build 9term against 9libs, by Mark Wilkinson Ok? Anybody still wants the patch? Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Thu Jan 28 16:53:12 1999 Received: from aubrey.stanford.edu ([36.48.0.102]) by hawkwind.utcs.utoronto.ca with SMTP id <24700>; Thu, 28 Jan 1999 12:27:41 -0500 Received: (qmail 24925 invoked from network); 28 Jan 1999 16:55:17 -0000 Received: from localhost.stanford.edu (HELO aubrey.stanford.edu) (jimr@127.0.0.1) by localhost.stanford.edu with SMTP; 28 Jan 1999 16:55:17 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: Aharon Robbins cc: sam-fans@hawkwind.utcs.toronto.edu Dcc: Subject: Re: more on my 9term In-reply-to: Message from Aharon Robbins of "Thu, 28 Jan 1999 08:02:48 EST."References: <199901281334.IAA19617@dilbert.mathcs.emory.edu> <199901281334.IAA19617@dilbert.mathcs.emory.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24917.917542517.1@aubrey.stanford.edu> Date: Thu, 28 Jan 1999 11:55:17 -0500 Sender: jimr@aubrey.stanford.edu Message-Id: <99Jan28.122741est.24700@hawkwind.utcs.utoronto.ca> > Hmmm. Control-c for interrupt doesn't work on the 9term I just built.... > Maybe Bengt's version is better? The default "intr" key for the 9term is Del. What I have in my .rcrc to deal with that is: if (~ `{tty} /dev/ttyp* && ~ $TERM 9term) { stty erase '^H' > /dev/null >[2=1] stty intr '^?' > /dev/null >[2=1] } else { if ( ! ~ $TERM ()) { stty sane > /dev/null >[2=1] } } From sam-fans-owner Thu Jan 28 16:54:09 1999 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24694>; Thu, 28 Jan 1999 12:24:45 -0500 Received: from trillian.softwell.se (trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.8.5/8.8.5) with ESMTP id RAA15204; Thu, 28 Jan 1999 17:42:04 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id RAA18319; Thu, 28 Jan 1999 17:42:03 +0100 Date: Thu, 28 Jan 1999 11:42:03 -0500 From: Bengt Kleberg Message-Id: <199901281642.RAA18319@trillian.softwell.se> To: arnold@gnu.org, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: more on my 9term > I tried to build 9term 1.6.3 with the research!rsc patch file, and it is still > much worse than the patched 1.6.6. AFAIK there where no patches applied to my 9term (before I added some for linux). From sam-fans-owner Tue Feb 2 15:43:55 1999 Received: from repop2.jps.net ([209.63.224.239]) by hawkwind.utcs.utoronto.ca with SMTP id <24748>; Tue, 2 Feb 1999 15:38:44 -0500 Received: from 6625hvt3r227 (209-239-194-114.oak.jps.net [209.239.194.114]) by repop2.jps.net (8.9.0/8.8.5) with ESMTP id QAA13600; Mon, 1 Feb 1999 16:26:40 -0800 (PST) Message-Id: <199902020026.QAA13600@repop2.jps.net> From: "Chaotrope" To: , "Aharon Robbins" Cc: Subject: Re: 9term under Linux? Date: Mon, 1 Feb 1999 19:25:45 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 99.01.27 > James A. Robinson replied to > Aharon Robbins > Cc: sam-fans@hawkwind.utcs.toronto.edu on the > Subject: Re: 9term under Linux? saying > I've got 9term, 9wm, 9menu, wily, sam, and rc working on my > system. I really love the interface! =) > > Jim This plan9 interface that Jim has is exactly what started me a few months back investigating getting a Linux system even tho I swore a number of years ago that I'd no longer spend my own money on computer stuff (I've got two closets full of junk already!). I read some articles of Aharon's (Arnold's) in 1995 "Linux Journal" and had the old R. Pike 'sam' article, and have been 'window shopping' (where in this case 'window' has nothing to do with Microsoft) with the intent of maybe putting together some no name x86 system. So when I read here that Arnold has difficulties, I think, Maybe I'm over my head, if *HE* has problems, what am I going to run into?! Thus far, Debian is the only Linux dist that has p9 emu binaries at its ftp site (Red Hat has 'sam' only). The NeBSD/FreeBSD people even have a 'plan9' directory at their ftp sites, just like an 'editors' and a 'TeX' directory. So I'm leaning toward BSD rather than Linux just because that indicates to me that these people are "thinking" along those lines. So my question is, e.g., Jim, what are you using? Is there a general consensus on ease of installation, whatever, getting this p9 'look and feel grafted on top of what version of Unix? Are there known problems with (obviously) RedHat vs. whatever? TIA, - kim BTW, Aharon/Arnold: I enjoyed your LJ articles enough that I'm planning to get your AWK book just because I assume it will be well written also. From sam-fans-owner Tue Feb 2 15:46:03 1999 Received: from post.mail.demon.net ([194.217.242.38]) by hawkwind.utcs.utoronto.ca with SMTP id <24842>; Tue, 2 Feb 1999 15:40:15 -0500 Received: from [212.228.106.206] (helo=kremvax.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.11 #1) id 107lKi-0005xc-00; Tue, 2 Feb 1999 19:18:02 +0000 Received: (from mhw@localhost) by kremvax.demon.co.uk (8.8.7/8.8.7) id TAA06797; Tue, 2 Feb 1999 19:17:57 GMT To: Bengt Kleberg , arnold@gnu.org, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term under Linux? From: "Mark H. Wilkinson" Date: Tue, 2 Feb 1999 14:11:51 -0500 In-Reply-To: <199901281228.NAA32236@trillian.softwell.se> Message-ID: <199902021911.6770.sam.bagiv@kremvax.demon.co.uk> X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-PGP-Fingerprint: 8E 43 1E D7 85 42 E0 C5 D3 8C B6 B1 EE 06 95 64 > > Has anyone got patches to 9term 1.6.6 for Linux? > I have recreated my 9term with working hold mode and echoed input characters > in rc. > I have a patch (created with diff -Naur as per recommendation). > _However_, there is a catch. I build 9term against 9libs, by Mark Wilkinson > > Ok? Anybody still wants the patch? Me :-) Bit of clarification here: 9libs is basically libXg and libframe with an autoconf/automake/libtool build system. We (Bengt and I) have versions of sam and wily which have compatible build systems. You can build the whole source tree with the usual `configure;make;make install,' even on Linux. 9term will come next... I think that we're close to releasing what we have. More soon. -Mark. From sam-fans-owner Tue Feb 2 15:47:08 1999 Received: from cssun.mathcs.emory.edu ([170.140.150.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24797>; Tue, 2 Feb 1999 15:39:42 -0500 Received: from dilbert.mathcs.emory.edu (dilbert [170.140.150.6]) by cssun.mathcs.emory.edu (8.9.1b+Sun/8.9.1) with ESMTP id HAA21121; Tue, 2 Feb 1999 07:27:21 -0500 (EST) Received: from gold2.gezernet.co.il (gold2.gezernet.co.il [192.115.7.75]) by dilbert.mathcs.emory.edu (8.9.1b+Sun/8.9.1) with SMTP id HAA12648; Tue, 2 Feb 1999 07:26:56 -0500 (EST) Message-Id: <199902021226.HAA12648@dilbert.mathcs.emory.edu> From: Aharon Robbins Date: Tue, 2 Feb 1999 01:49:04 -0500 To: chaotrope@jps.net Subject: Re: 9term under Linux? Cc: sam-fans@hawkwind.utcs.toronto.edu > I read some articles of Aharon's (Arnold's) in 1995 "Linux Journal" > and had the old R. Pike 'sam' article, and have been 'window shopping' > (where in this case 'window' has nothing to do with Microsoft) with > the intent of maybe putting together some no name x86 system. > > So when I read here that Arnold has difficulties, I think, Maybe I'm > over my head, if *HE* has problems, what am I going to run into?! Don't be discouraged. The patches I posted to sam-fans for 9term do the trick. My problem with interrupts were 1) I forgot that 9term uses DEL, not ^C, and 2) I was running es-0.84 in the 9term, not rc. I will be switching to rc. > So my question is, e.g., Jim, what are you using? Is there a general > consensus on ease of installation, whatever, getting this p9 'look and > feel grafted on top of what version of Unix? Are there known problems > with (obviously) RedHat vs. whatever? I sent bobf Make.linux files and diffs to u.h for linux so that will be in the sam distribution soon. (Patches available on request, but they're pretty easy to do on your own.) The patches I sent for 9term 1.6.6 seem to do the trick. I am now happily running the 9wm/9term/9menu/sam/rc combination. After 1.5 years without X, it's like having an old friend back. :-) To answer your question, for my money, stick w/Linux. (No, I don't want to start a religious war. To each his own, etc.) > BTW, Aharon/Arnold: I enjoyed your LJ articles enough that I'm > planning to get your AWK book just because I assume it will be well > written also. Thanks. *I* think it's pretty good, but I'm sorta biased. OTOH, I have yet to have anyone tell me it sucked... :-) Arnold -- Aharon (a.k.a. Arnold) Robbins arnold@gnu.org P.O. Box 354 Home Phone: +972 8 979-0381 Nof Ayalon Cell Phone: +972 51 297-545 D.N. Shimshon 99784 Laundry increases exponentially in the ISRAEL number of children. -- Miriam Robbins From sam-fans-owner Tue Feb 2 15:47:31 1999 Received: from aubrey.stanford.edu ([36.48.0.102]) by hawkwind.utcs.utoronto.ca with SMTP id <24753>; Tue, 2 Feb 1999 15:39:20 -0500 Received: (qmail 30503 invoked from network); 2 Feb 1999 02:01:28 -0000 Received: from localhost.stanford.edu (HELO aubrey.stanford.edu) (jimr@127.0.0.1) by localhost.stanford.edu with SMTP; 2 Feb 1999 02:01:28 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "Chaotrope" cc: sam-fans@hawkwind.utcs.toronto.edu Dcc: Subject: Re: 9term under Linux? In-reply-to: Message from "Chaotrope" of "Mon, 01 Feb 1999 16:25:45 PST."References: <199902020026.QAA13600@repop2.jps.net> <199902020026.QAA13600@repop2.jps.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30490.917920887.1@aubrey.stanford.edu> Date: Mon, 1 Feb 1999 21:01:28 -0500 Sender: jimr@aubrey.stanford.edu Message-Id: <99Feb2.153920est.24753@hawkwind.utcs.utoronto.ca> > 'editors' and a 'TeX' directory. So I'm leaning toward BSD rather > than Linux just because that indicates to me that these people are > "thinking" along those lines. > > So my question is, e.g., Jim, what are you using? Is there a general > consensus on ease of installation, whatever, getting this p9 'look and > feel grafted on top of what version of Unix? Are there known problems > with (obviously) RedHat vs. whatever? Hi, I'm using a heavily modified, stripped down, and generally munged version of RedHat 5.0 here at work. At home I'm running a customized Slackware 3.0 setup. I've got a /usr/local/src/plan9 tree on the home machine which has the source for 9menu 1.4, 9wm 1.2, es 0.90beta1, sam 4.3, 9term 1.6.6, rc 1.5b2, and wily 0.13.41. I've fiddled with the various make files and source so that they all compile without any problem on my box. As I recall, 9term is the hardest to compile. 9wm, 9menu, the editors, and the shells compiled without any trouble. 9term now compiles, but it does tend to give off quite a few "seems to be harmless" errors. Oh yeah, all the little tools that wily comes with were a pain in the ass to compile. But I got win, and tools/shell/* to compile. So, if people want to download entire 1.0 meg binaries and 2.9 meg source tree, grab it from http://highwire.stanford.edu/~jimr/plan9/plan9.bin.tar.gz http://highwire.stanford.edu/~jimr/plan9/plan9.src.tar.gz The only thing missing from the tars are the Xg unicode fonts. It doesn't have a clear distribution-rights copyright statement, so I can't bundle it in the archive. I'm not even sure where I got them from originally, so you'll have to hunt them up. =( If you unarchive both from your root, they will go into /opt/plan9/^(bin doc lib man) for the binaries, and /usr/local/src/plan9/^(9menu-1.4 9term-1.6.6 9wm-1.2 es-0.90beta1 rc-1.5b2 sam-4.3 wily-0.13.41) for the source. Jim From sam-fans-owner Tue Feb 2 15:52:19 1999 Received: from localhost by hawkwind.utcs.utoronto.ca with SMTP id <24855>; Tue, 2 Feb 1999 15:41:42 -0500 To: sam-fans Subject: Re: 9term under Linux? Date: Tue, 2 Feb 1999 15:41:27 -0500 From: Chris Siebenmann Message-Id: <99Feb2.154142est.24855@hawkwind.utcs.utoronto.ca> | So my question is, e.g., Jim, what are you using? Is there a general | consensus on ease of installation, whatever, getting this p9 'look and | feel grafted on top of what version of Unix? Are there known problems | with (obviously) RedHat vs. whatever? I find that my version of 9term (it started out at 1.6.6 and grew) is about equally easy to bring up on anything. The fiddling required is usually to set up the V_* defines, almost always to not use TCSADRAIN, and some functions that are prototyped in standard header files in ways that clash with u.h et al. I have similar results for sam and rc (generally). They're all Unix. They all work. - cks, who's lost count of how many Unixes he's made 9term run on From sam-fans-owner Wed Feb 3 20:32:13 1999 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24837>; Wed, 3 Feb 1999 20:28:36 -0500 Received: from trillian.softwell.se (trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.8.5/8.8.5) with ESMTP id IAA03765; Wed, 3 Feb 1999 08:19:47 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id IAA13132; Wed, 3 Feb 1999 08:19:46 +0100 Date: Wed, 3 Feb 1999 02:19:46 -0500 From: Bengt Kleberg Message-Id: <199902030719.IAA13132@trillian.softwell.se> To: cks@hawkwind.utcs.toronto.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9term under Linux? > - cks, who's lost count of how many Unixes he's made 9term run on BSD too? My 9term for BSD does not work properly (unexplainable freezes at times). May I look at your 9term, please? Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Mon Feb 8 19:56:19 1999 Received: from post.mail.demon.net ([194.217.242.38]) by hawkwind.utcs.utoronto.ca with SMTP id <25055>; Mon, 8 Feb 1999 18:55:57 -0500 Received: from [212.228.106.206] (helo=kremvax.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.11 #1) id 108s3Q-0004gd-00; Fri, 5 Feb 1999 20:40:44 +0000 Received: (from mhw@localhost) by kremvax.demon.co.uk (8.8.7/8.8.7) id UAA01299; Fri, 5 Feb 1999 20:39:34 GMT To: wilyfans@jli.com, sam-fans@hawkwind.utcs.toronto.edu Subject: 9libs-0.3, wily, sam test distributions From: "Mark H. Wilkinson" Date: Fri, 5 Feb 1999 15:04:45 -0500 Message-ID: <199902052004.1048.9libs.babul@kremvax.demon.co.uk> X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-PGP-Fingerprint: 8E 43 1E D7 85 42 E0 C5 D3 8C B6 B1 EE 06 95 64 We (myself and Bengt Kleberg) have been doing some work on adding a more modern build system to the Plan 9 tools which are available. The result is a distribution called 9libs which includes the graphics library libXg, the text frame library libframe and a fledgling accumulation of other Plan 9 work-a-like functions called libplan9c. I've also reworked the build system for wily to work with 9libs, and Bengt Kleberg has done the same for sam. The overall aim of the 9libs distribution is to allow libXg and libframe to be distributed separately from the programs which rely on it, and hopefully to make it easier to build a number of different programs which all use libXg and libframe. We also aim to bring the build system up to date with modern Unix systems so that it will build out of the box on more systems. Given that many people use more than one out of sam, wily, 9term, 9wm and so on, this should make building the basic tools of your windowing environment simpler. We're making a test distribution available to try and thrash out any remaining portability problems on machine types we haven't been able to lay our hands on. If all goes well we intend to do a 9libs-1.0 release pretty soon. The distributions are available from the following URLs: ftp://ftp.cs.york.ac.uk/pub/mhw/experimental/9libs-0.3.tar.gz ftp://ftp.cs.york.ac.uk/pub/mhw/experimental/sam-9libs.tar.gz ftp://ftp.cs.york.ac.uk/pub/mhw/experimental/wily-9libs.tar.gz Instructions for building are included in the distribution. If you can't follow them, let me know how they could be improved. If the build system doesn't work for you, submit a bug report to me and I'll see what can be done. I'm on holiday for the next two weeks so you might not get a reply straight away, but I'll look into any problems reported. To get you interested, here's a brief installation synopsis: ; gzcat 9libs-0.3.tar.gz | tar xf - ; cd 9libs-0.3 ; gzcat ../sam-9libs.tar.gz | tar xf - ; gzcat ../wily-9libs.tar.gz | tar xf - ; ./configure ; make ; make install That will compile and install the libraries, sam and wily. Good things: * You can build shared libraries without much trouble. * You can build binaries for multiple architectures from the same source tree without much trouble. * You will be able to build 9term and co with no extra effort someday soon. * wily gains a more complete implementation of the Font builtin which lets you use any font (X or libXg font file) you have on your system. The p9fixed resource is gone; use -F instead like you would with acme. Current problems, off the top of my head: * There's a problem linking the sam executable against shared libraries: the build system tries to link it with libXg, libframe and libplan9c when only libplan9c is necessary. libXg and libframe contain undefined symbols, so the link fails. You can workaround it by editing sam-9libs/sam/Makefile and removing libXg and libframe from the LIBS variable. * The implementation of the Plan 9 print() routines in libplan9c is incomplete (it doesn't cover floating point). I'm intending to finish it soon. It does include string formatting, so you can write Unicode aware command line programs and see their output in 9term. * The build system contains more lines of text than the source code that makes up the libraries. Largely a side effect of using autoconf, automake and libtool, I'm afraid. Just think of the bonuses which it gets you. Enjoy, -Mark. From sam-fans-owner Mon Feb 8 20:15:35 1999 Received: from repop1.jps.net ([209.63.224.238]) by hawkwind.utcs.utoronto.ca with SMTP id <25030>; Mon, 8 Feb 1999 18:54:50 -0500 Received: from 6625hvt3r227 (209-239-201-189.oak.jps.net [209.239.201.189]) by repop1.jps.net (8.8.5/8.8.5) with ESMTP id JAA22064; Fri, 5 Feb 1999 09:51:48 -0800 (PST) Message-Id: <199902051751.JAA22064@repop1.jps.net> From: "Chaotrope" To: "wilyfans" , "samfans" Subject: History Is Just Old Stuff Date: Fri, 5 Feb 1999 12:52:25 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit While cleaning out useless outdated computer junk from my closets, so I can have space to store more useless outdated computer junk in the closets, in order to have room in my "living" space for the Linux system I'm aiming to get because it will include: sam, wily, rc/es, 9term, 9menu, & 9wm which are all going to work together with no problems, with absolutely no problems. . . Anyhow, while cleaning I came across this old article I'd saved (along with a 300 baud modem and some other really useful items!), an interview with Bill Joy from the August 1984 issue of 'Unix Review'. I was surprised at how much of what was mentioned during the course of the interview is still applicable today, they even touched on sam and acme/wily! First question of course was, "How did vi come about?" Joy told how he had come to Berkeley in 1975 and they were first hacking on 'ed' and then someone brought 'em' ('editor for mortals') which they combined into 'en' and eventually 'ex'. When they got the first glass terminals (1976) they were just playing with them, nothing planned, kids showing off: 'I can clear the screen and home the cursor,' that kind of accrued into "features" that eventually became vi. He says a Mike Horton came from Bell Labs around that time with 'hed' (Horton's editor) but it arrived too late and vi already had a sizeable following. Joy talks about getting a manual page and stealing ideas from (this is a direct quote): "the Toronto version of ed, which I think Rob Pike had something to do with." And he mentions "looking forward to the editor Warren Teitelman is working on. Having editing functionally everywhere..." Teitelman's work became the Cedar system that Wirth saw and developed into the Oberon interface, which Pike saw that influenced Acme, and so on, and so on. Joy even presages 'sam' somewhat, saying he'd toyed with writing an editor for bitmap and mouse that had "almost no commands, (just a) Smalltalk editing menu, a scroll bar and a thumb bar." Why? asks the interviewer. Joy answers: "Since I sort of invented the editor that was the most complicated, I thought I would compensate by also designing the editor that was the most simple." But then Berkeley got that VAX and Bill became busy doing other things. Still, before the article ends they do get in the old, "Real programmers use cat as their editor." Some things never change. - kim From sam-fans-owner Mon Feb 8 20:40:11 1999 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.utoronto.ca with SMTP id <24694>; Mon, 8 Feb 1999 20:38:32 -0500 Received: (qmail 29432 invoked by uid 991); 9 Feb 1999 00:41:49 -0000 Message-ID: <19990209004149.29431.qmail@g.bio.cse.psu.edu> Date: Mon, 8 Feb 1999 19:41:49 -0500 To: "Mark H. Wilkinson" cc: wilyfans@jli.com, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: 9libs-0.3, wily, sam test distributions In-reply-to: Your message of "Fri, 05 Feb 1999 15:04:45 EST." <199902052004.1048.9libs.babul@kremvax.demon.co.uk> Date: Mon, 8 Feb 1999 19:41:49 -0500 From: Scott Schwartz "Mark H. Wilkinson" writes: | * The implementation of the Plan 9 print() routines in libplan9c is | incomplete (it doesn't cover floating point). I'm intending to finish | it soon. It does include string formatting, so you can write Unicode | aware command line programs and see their output in 9term. The version of print that I submitted to comp.sources.unix a while ago is fairly complete. With a little help from David Gay's fp code from netlib, it prints floating point very nicely. From sam-fans-owner Tue Mar 23 16:52:14 1999 Received: from blackusi03.belrose.visionet.com.au ([210.0.31.9]) by hawkwind.utcs.utoronto.ca with SMTP id <24733>; Tue, 23 Mar 1999 16:46:38 -0500 Received: from ishtek.com ([210.0.3.138]) by blackusi03.belrose.visionet.com.au (Netscape Mail Server v2.01) with SMTP id AAA13776 for ; Tue, 23 Mar 1999 23:15:26 +1100 X-Mailer: Ishtek MeeMail 2.1 Date: Tue, 23 Mar 1999 07:13:14 -0500 From: Alex Danilo Subject: sam on Solaris To: sam-fans@hawkwind.utcs.toronto.edu X-Face: 3}u>)koHh${W+XV18fV{i/@Sw_Cvi'3hS04kL'J-3Qoz{?D R>c6<6{LbeD5'D9+C\lUPtNBF=h=yrnT,zMx$o3YbL/p;|UGb}@0^{Tr7ppFE_sk;'p[W9,gpJ$`N2 Sp?E#o2R Message-Id: <99Mar23.164638est.24733@hawkwind.utcs.utoronto.ca> Hi, Has anyone had success running Sam on Solaris. I know there are Make.solaris files, and yes, the out of the box distribution compiles fine. But, when you run it, it locks up the X-server. Note, that I've built the 'test' program in libXg, which runs fine, but sam barfs the moment you try to use the menus. All help appreciated. Alex P.S. Seems to lock up when processing the next X event. -- Alex Danilo http://www.ishtek.com/alex PO Box 333 Forestville NSW 2087 +61-2-9975-2297 From sam-fans-owner Fri Mar 26 16:18:19 1999 Received: from finch-post-12.mail.demon.net ([194.217.242.41]) by hawkwind.utcs.utoronto.ca with SMTP id <24797>; Fri, 26 Mar 1999 15:41:28 -0500 Received: from [212.228.106.206] (helo=kremvax.demon.co.uk) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 10QKlZ-000Fof-0C; Fri, 26 Mar 1999 00:46:29 +0000 Received: (from mhw@localhost) by kremvax.demon.co.uk (8.8.7/8.8.7) id AAA04805; Fri, 26 Mar 1999 00:46:28 GMT To: Alex Danilo , sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam on Solaris From: "Mark H. Wilkinson" Date: Thu, 25 Mar 1999 18:57:36 -0500 In-Reply-To: <99Mar23.164638est.24733@hawkwind.utcs.utoronto.ca> Message-ID: <199903252357.4232.sam.bagon@kremvax.demon.co.uk> X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-PGP-Fingerprint: 8E 43 1E D7 85 42 E0 C5 D3 8C B6 B1 EE 06 95 64 > Hi, > Has anyone had success running Sam on Solaris. I know there are > Make.solaris files, and yes, the out of the box distribution compiles fine. > But, when you run it, it locks up the X-server. > Note, that I've built the 'test' program in libXg, which runs fine, > but sam barfs the moment you try to use the menus. All help appreciated. Just a guess, but are you running on a 15bpp X server? libXg only supports screens whose depth is a power of 2. Popping up a menu trys to create a bitmap with depth 16 to store part of the screen bitmap; the X server faults the request, causing sam to bomb out. -Mark. From sam-fans-owner Wed Jun 2 19:08:30 1999 Received: from apollo.le.ac.uk ([143.210.16.125]) by hawkwind.utcs.utoronto.ca with SMTP id <25041>; Wed, 2 Jun 1999 18:53:05 -0400 Received: from happy.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 2.12 #1) id 10pCMU-0004TO-00 for sam-fans@hawkwind.utcs.toronto.edu; Wed, 2 Jun 1999 15:51:22 +0100 Received: (qmail 17260 invoked from network); 2 Jun 1999 14:51:43 -0000 Received: from ltpcg.star.le.ac.uk (tjg@143.210.36.203) by happy.star.le.ac.uk with SMTP; 2 Jun 1999 14:51:43 -0000 To: wilyfans@jli.com, 9fans-request@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Release of rc-1.6 Date: Wed, 2 Jun 1999 10:51:42 -0400 From: Tim Goodwin Message-ID: I've just made a new full release of the rc shell, rc-1.6. For furhter information, please see my rc web page. http://www.star.le.ac.uk/~tjg/rc/ Apologies to those who've already seen the announcement elsewhere... Tim. From sam-fans-owner Sun Jun 13 21:15:42 1999 Received: from finch-post-10.mail.demon.net ([194.217.242.38]) by hawkwind.utcs.utoronto.ca with SMTP id <24836>; Sun, 13 Jun 1999 20:42:32 -0400 Received: from kremvax.demon.co.uk ([212.228.106.206]) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 10sF83-0006U3-0A; Fri, 11 Jun 1999 00:25:04 +0000 Received: (from mhw@localhost) by kremvax.demon.co.uk (8.8.7/8.8.7) id BAA25160; Fri, 11 Jun 1999 01:23:05 +0100 To: Sam Fans , 9fans@cse.psu.edu, wilyfans@jli.com Subject: 9libs, new sam release, experimental wily release From: "Mark H. Wilkinson" Date: Thu, 10 Jun 1999 19:04:28 -0400 Message-ID: <199905110004.4944.9libs.badoj@kremvax.demon.co.uk> X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-PGP-Fingerprint: 8E 43 1E D7 85 42 E0 C5 D3 8C B6 B1 EE 06 95 64 We would like to announce the release of the following bundles of code: * 9libs-1.0, a collection of libraries which emulate some parts of the Plan 9 programming environment under Unix and the X Window System. * sam-9libs, a new release of Rob Pike's editor, sam, which uses 9libs-1.0. * wily-9libs, an experimental release of Gary Capell's editor, wily, which emulates the functionality of Rob's editor "acme" from Plan 9. Again, wily-9libs uses 9libs. 9libs-1.0 is a repackaging of libXg, libframe and libregexp from the last release of sam. It replaces the collection of Makefiles with a build system which uses a GNU-style configure script and which will build shared libraries using GNU libtool. The intention is to make it easier to compile and install the libraries (and applications which use them) on modern Unix systems. It also adds some new implementations of Plan 9 functions (notably the print() functions) which have been grouped with libregexp into a new library called libplan9c. sam-9libs is a new release of sam which links against the libraries from 9libs-1.0. Other than changes in the build system there is only one new feature: sam uses the value of the environment variable TABSTOP to set the size of its tabstop. It is intended that this release of sam become the "official" release: the version of samterm which Bell Labs run on brazil uses a newer graphics model than that provided by libg (and libXg). As such it is growing increasingly difficult for them to support this older version. wily-9libs is an experimental (as in "not official") release of wily-0.13.43 which has been modified to build against 9libs. It also adds an implementation of the Font builtin which more closely emulates the same builtin in acme. You can get the code from the following locations: ftp://netlib.bell-labs.com/netlib/research/9libs ftp://ftp.demon.co.uk/pub/unix/plan9 Why would you want to use this? Basically, it makes your life easier. You can compile and install 9libs, sam and wily separately if you want. You can also build the whole lot together: it's as simple as this: ; gunzip -c 9libs-1.0.tar.gz | tar xf - ; cd 9libs-1.0 ; gunzip -c ../sam-9libs.tar.gz | tar xf - ; gunzip -c ../wily-9libs.tar.gz | tar xf - ; ./configure ; make The build system also supports building for multiple architectures from one directory tree. Enjoy! Mark Wilkinson Bengt Kleberg From sam-fans-owner Tue Jun 15 19:27:00 1999 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.utoronto.ca with SMTP id <25108>; Tue, 15 Jun 1999 17:58:47 -0400 Received: (qmail 8334 invoked by uid 991); 15 Jun 1999 00:39:48 -0000 Message-ID: <19990615003948.8333.qmail@g.bio.cse.psu.edu> Date: Mon, 14 Jun 1999 20:39:48 -0400 To: "Mark H. Wilkinson" cc: Sam Fans , Bengt Kleberg Subject: Re: 9libs, new sam release, experimental wily release In-reply-to: Your message of "Mon, 14 Jun 1999 20:46:50 BST." <199906142046.20514.9libs.badum@kremvax.demon.co.uk> Date: Mon, 14 Jun 1999 20:39:48 -0400 From: Scott Schwartz "Mark H. Wilkinson" writes: | It looks like your patches hadn't made it into the Bell Labs source, | although I do remember some of them being posted to sam-fans. If you | forward them to Bengt and myself we'll get them integrated. Here they are. (Hopefully I haven't introduced any new problems today; I did tweak some things.) The program I use in my xinitrc to load the font property looks like this: #!/bin/rc F=``(){sed -e 's/$/ \\n\\/'} { echo -n '*p9font: ' echo $F echo -n '*p9fixed: ' echo $F } | xrdb -merge I use it like: load9font <$home/lib/unicode.9.font Wily users might want to do this slightly differently, since that requires a proportional font for one case. cd ./libXg =================================================================== RCS file: rdfontfile.c,v retrieving revision 1.1 diff -c -r1.1 rdfontfile.c *** /tmp/T0s0Qol_ Mon Jun 14 20:25:00 1999 --- rdfontfile.c Mon Jun 14 18:06:11 1999 *************** *** 13,27 **** return s; } ! Font * ! rdfontfile(char *name, int ldepth) { ! Font *fnt; ! Cachesubf *c; ! int fd, i; ! char *buf, *s, *t; struct stat sbuf; ! unsigned long min, max; fd = open(name, O_RDONLY); if (fd < 0) --- 13,25 ---- return s; } ! char * ! file2string(char* name) { ! int fd; struct stat sbuf; ! char *buf; ! int i; fd = open(name, O_RDONLY); if (fd < 0) *************** *** 44,54 **** free(buf); return 0; } ! s = buf; fnt = (Font *)malloc(sizeof(Font)); ! if (fnt == 0) ! goto Err1; memset((void*)fnt, 0, sizeof(Font)); fnt->name = (char *)malloc(strlen(name)+1); if (fnt->name==0) --- 42,73 ---- free(buf); return 0; } + return buf; + } ! Font * ! rdfontfile(char *name, int ldepth) ! { ! return rdfontstring(name, file2string(name), ldepth); ! } ! ! Font* ! rdfontstring(char *name, char *s, int ldepth) ! { ! Font *fnt; ! Cachesubf *c; ! int i; ! char *t; ! struct stat sbuf; ! unsigned long min, max; ! ! if (s == 0) ! return 0; fnt = (Font *)malloc(sizeof(Font)); ! if (fnt == 0) { ! Err1: ! return 0; ! } memset((void*)fnt, 0, sizeof(Font)); fnt->name = (char *)malloc(strlen(name)+1); if (fnt->name==0) *************** *** 97,117 **** c->min = min; c->max = max; t = s; ! while (*s && *s!='\n' && *s!='\t') s++; ! *s++ = 0; c->f = (Subfont *)0; ! c->name = (char *)malloc(strlen(t)+1); if (c->name == 0) { free(c); goto Err3; } ! strcpy(c->name, t); s = skip(s); fnt->nsubf++; } while(*s); - free(buf); return fnt; } --- 116,139 ---- c->min = min; c->max = max; t = s; ! while (*s && *s!='\n' && *s!='\t' && *s!=' ') s++; ! /* *s++ = 0; */ c->f = (Subfont *)0; ! c->name = (char *)malloc(s-t+1); if (c->name == 0) { free(c); goto Err3; } ! { int i; ! for (i = 0; i < s-t; ++i) c->name[i] = t[i]; ! c->name[i] = 0; ! } ! /* strcpy(c->name, t); */ s = skip(s); fnt->nsubf++; } while(*s); return fnt; } *************** *** 127,132 **** --- 149,155 ---- if (c->f) subffree(c->f); free(c->name); + free(c); } free(f->subf); free(f); =================================================================== RCS file: xtbinit.c,v retrieving revision 1.1 diff -c -r1.1 xtbinit.c *** /tmp/T0s0Qol_ Mon Jun 14 20:25:00 1999 --- xtbinit.c Mon Jun 14 17:24:10 1999 *************** *** 185,191 **** font = 0; subfont = 0; if (fontname) { ! font = rdfontfile(fontname, screen.ldepth); if (!font || charwidth(font, (Rune) ' ') == 0) { subfont = getsubfont(fontname); if (!subfont) --- 185,193 ---- font = 0; subfont = 0; if (fontname) { ! font = (fontname[0] == '.' || fontname[0] == '/') ! ? rdfontfile(fontname, screen.ldepth) ! : rdfontstring("p9font", fontname, screen.ldepth); if (!font || charwidth(font, (Rune) ' ') == 0) { subfont = getsubfont(fontname); if (!subfont) cd ./include =================================================================== RCS file: libg.h,v retrieving revision 1.1 diff -c -r1.1 libg.h *** /tmp/T0gdJVh_ Mon Jun 14 20:25:01 1999 --- libg.h Mon Jun 14 02:15:54 1999 *************** *** 201,206 **** --- 201,207 ---- extern int bitbltclip(void*); extern Subfont* getsubfont(char*); extern Font *rdfontfile(char*, int); + extern Font *rdfontstring(char*, char*, int); extern void ffree(Font*); extern Font *mkfont(Subfont*); extern void subffree(Subfont*); cd ./sam-9libs/sam =================================================================== RCS file: sam.c,v retrieving revision 1.1 diff -c -r1.1 sam.c *** /tmp/T002r2br Mon Jun 14 20:25:01 1999 --- sam.c Mon Jun 14 02:27:09 1999 *************** *** 151,157 **** continue; if(io == -1){ sprint(buf, "%s/sam.save", home); ! io = create(buf, 1, 0777); if(io<0) return; } --- 151,157 ---- continue; if(io == -1){ sprint(buf, "%s/sam.save", home); ! io = create(buf, 1, 0700); if(io<0) return; } =================================================================== RCS file: shell.c,v retrieving revision 1.1 diff -c -r1.1 shell.c *** /tmp/T002r2br Mon Jun 14 20:25:01 1999 --- shell.c Mon Jun 14 02:28:37 1999 *************** *** 34,40 **** remove(errfile); if((pid=fork()) == 0){ if(downloaded){ /* also put nasty fd's into errfile */ ! fd = create(errfile, 1, 0666L); if(fd < 0) fd = create("/dev/null", 1, 0666L); dup(fd, 2); --- 34,40 ---- remove(errfile); if((pid=fork()) == 0){ if(downloaded){ /* also put nasty fd's into errfile */ ! fd = create(errfile, 1, 0600L); if(fd < 0) fd = create("/dev/null", 1, 0666L); dup(fd, 2); cd ./sam-9libs/samterm =================================================================== RCS file: samterm.h,v retrieving revision 1.1 diff -c -r1.1 samterm.h *** /tmp/T00P2og_ Mon Jun 14 20:25:01 1999 --- samterm.h Mon Jun 14 17:51:13 1999 *************** *** 2,8 **** #define SAMTERM #define RUNESIZE sizeof(Rune) ! #define MAXFILES 256 #define NL 5 enum{ --- 2,8 ---- #define SAMTERM #define RUNESIZE sizeof(Rune) ! #define MAXFILES (4*1024) #define NL 5 enum{ From sam-fans-owner Tue Jun 15 19:36:29 1999 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.utoronto.ca with SMTP id <25101>; Tue, 15 Jun 1999 17:58:37 -0400 Received: (qmail 7755 invoked by uid 991); 15 Jun 1999 00:10:04 -0000 Message-ID: <19990615001004.7754.qmail@g.bio.cse.psu.edu> Date: Mon, 14 Jun 1999 20:10:04 -0400 To: "Mark H. Wilkinson" cc: Sam Fans , Bengt Kleberg Subject: Re: 9libs, new sam release, experimental wily release In-reply-to: Your message of "Mon, 14 Jun 1999 20:46:50 BST." <199906142046.20514.9libs.badum@kremvax.demon.co.uk> Date: Mon, 14 Jun 1999 20:10:04 -0400 From: Scott Schwartz "Mark H. Wilkinson" writes: | > * In libXg, "fontfile" is specified by the X client app. In general | > that cannot work: unlike in Plan 9, the X terminal usually won't | > share any filesystem with the machine on which the X app is | > running, so *no* filename can be valid for "-p9font". The fix is | > to store the unicode font map in an X property which is set by your | > xinitrc. | | By this, do you mean the case where you're logging into remote machines | and running sam & samterm on the remote machine? Yes. | ... but I guess you're after a | solution which is easier to manage, using the X server as shared storage. Yup. | That sounds reasonable, but I'd like to retain the existing mechanism | too: it works well in networks where the file system is common to all | machines to some degree. Of course. The patch does that. It checks to see if the fontfile starts with '.' or '/', and if so, reads that file. Otherwise it treats it as the literal contents of the font file. In either case, as before, it falls back to using a literal X font name if the previous steps don't resolve to a font file. | That would be great! I'll have them ready soon. I got diverted hacking on 9term today. From sam-fans-owner Tue Jun 15 19:42:32 1999 Received: from finch-post-10.mail.demon.net ([194.217.242.38]) by hawkwind.utcs.utoronto.ca with SMTP id <25085>; Tue, 15 Jun 1999 17:58:18 -0400 Received: from kremvax.demon.co.uk ([212.228.106.206]) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 10tfDK-000MWD-0A; Mon, 14 Jun 1999 22:28:22 +0000 Received: (from mhw@localhost) by kremvax.demon.co.uk (8.8.7/8.8.7) id XAA20899; Mon, 14 Jun 1999 23:27:17 +0100 To: Scott Schwartz Cc: Sam Fans , Bengt Kleberg Subject: Re: 9libs, new sam release, experimental wily release From: "Mark H. Wilkinson" Date: Mon, 14 Jun 1999 15:46:50 -0400 In-Reply-To: <19990614064432.24527.qmail@g.bio.cse.psu.edu> Message-ID: <199906142046.20514.9libs.badum@kremvax.demon.co.uk> X-Face: Bsp[Ds(Y#/{==j:Cv'"IK4R^D0_z]{'OYtp2^EYqpG)88CsdBm&LJ{idLZWx}AKf}E4#|@4DT4cX3 ?!>aIVcxmd#1 X-PGP-Fingerprint: 8E 43 1E D7 85 42 E0 C5 D3 8C B6 B1 EE 06 95 64 > "Mark H. Wilkinson" writes: > | 9libs-1.0, sam-9libs, wily-9libs > Thanks. I have a couple of complaints, though. Several of my > favorite bugs (patches posted ages ago) have been resurrected > in this new release. It looks like your patches hadn't made it into the Bell Labs source, although I do remember some of them being posted to sam-fans. If you forward them to Bengt and myself we'll get them integrated. > They are: > * In samterm, MAXFILES is too small. (I've been using 4K.) Sounds reasonable. The "sam" program uses a variable length list to hold open files whilst the "samterm" program uses a fixed size array. A better solution might be to replace the fixed size array with a variable sized list, but upping the limit looks fine for the time being. > * In sam, private temp files are world readable/writable. Yup, I remember this one too. Again, sounds Ok to me. > * In libXg, "fontfile" is specified by the X client app. In general > that cannot work: unlike in Plan 9, the X terminal usually won't > share any filesystem with the machine on which the X app is > running, so *no* filename can be valid for "-p9font". The fix is > to store the unicode font map in an X property which is set by your > xinitrc. By this, do you mean the case where you're logging into remote machines and running sam & samterm on the remote machine? You can always get round the problem by making sure the font file you want to use is available on each of the machines you connect to, but I guess you're after a solution which is easier to manage, using the X server as shared storage. That sounds reasonable, but I'd like to retain the existing mechanism too: it works well in networks where the file system is common to all machines to some degree. It also has utility in wily where the Font builtin can be used to switch between font files dynamically. > I'll dig the diffs out of my RCS files tomorrow and sent them along. That would be great! Cheers, -Mark. From sam-fans-owner Tue Jun 15 19:50:57 1999 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.utoronto.ca with SMTP id <24846>; Tue, 15 Jun 1999 17:53:36 -0400 Received: (qmail 24528 invoked by uid 991); 14 Jun 1999 06:44:32 -0000 Message-ID: <19990614064432.24527.qmail@g.bio.cse.psu.edu> Date: Mon, 14 Jun 1999 02:44:32 -0400 To: "Mark H. Wilkinson" cc: Sam Fans , 9fans@cse.psu.edu, wilyfans@jli.com Subject: Re: 9libs, new sam release, experimental wily release In-reply-to: Your message of "Thu, 10 Jun 1999 19:04:28 EDT." <199905110004.4944.9libs.badoj@kremvax.demon.co.uk> Date: Mon, 14 Jun 1999 02:44:31 -0400 From: Scott Schwartz "Mark H. Wilkinson" writes: | 9libs-1.0, sam-9libs, wily-9libs Thanks. I have a couple of complaints, though. Several of my favorite bugs (patches posted ages ago) have been resurrected in this new release. They are: * In samterm, MAXFILES is too small. (I've been using 4K.) * In sam, private temp files are world readable/writable. * In libXg, "fontfile" is specified by the X client app. In general that cannot work: unlike in Plan 9, the X terminal usually won't share any filesystem with the machine on which the X app is running, so *no* filename can be valid for "-p9font". The fix is to store the unicode font map in an X property which is set by your xinitrc. I'll dig the diffs out of my RCS files tomorrow and sent them along. From sam-fans-owner Tue Aug 31 02:01:53 1999 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.utoronto.ca with SMTP id <24920>; Tue, 31 Aug 1999 01:35:15 -0400 Received: from aubrey.stanford.edu (aubrey.Stanford.EDU [36.48.0.102]) by highwire.stanford.edu (8.8.5/8.7.1) with ESMTP id LAA18626 for ; Sun, 29 Aug 1999 11:41:18 -0700 (PDT) Message-Id: <199908291841.LAA18626@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: sam-fans@hawkwind.utcs.toronto.edu Subject: paper referenced in The Text Editor sam MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31043.935952078.1@aubrey.stanford.edu> Date: Sun, 29 Aug 1999 14:41:18 -0400 Sender: jimr@aubrey.stanford.edu I've been hunting around the web to see if the following has been publisher online: Structural Regular Expressions Proceedings of the EUUG Spring 1987 Conference, p21-28 Helsinki May, 1987 I've had no luck. Anyone know if it is available online, or would I have to interlibrary loan it? I assume the EUUG is the European Unix User's Group, the only other reference I saw was Estonian Unix User's Group. =) Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James A. Robinson jim.robinson@stanford.edu Stanford University HighWire Press http://highwire.stanford.edu/ 650-723-7294 (W) 650-725-9335 (F) From sam-fans-owner Tue Aug 31 03:47:43 1999 Received: from mail-blue.research.att.com ([135.207.30.102]) by hawkwind.utcs.utoronto.ca with SMTP id <24840>; Tue, 31 Aug 1999 03:45:47 -0400 Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 898154CE05; Tue, 31 Aug 1999 02:03:34 -0400 (EDT) Received: from plan9.cs.bell-labs.com (castle4040.research.att.com [135.207.228.40]) by postal.research.att.com (8.8.7/8.8.7) with SMTP id CAA05084; Tue, 31 Aug 1999 02:03:23 -0400 (EDT) Message-Id: <199908310603.CAA05084@postal.research.att.com> From: "Russ Cox" Subject: Re: paper referenced in The Text Editor sam Date: Tue, 31 Aug 1999 02:03:12 -0400 To: Jim.Robinson@Stanford.Edu, sam-fans@hawkwind.utcs.toronto.edu MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit netlib.bell-labs.com/cm/cs/doc/87/3-se.ps.gz From sam-fans-owner Tue Aug 31 03:48:06 1999 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.utoronto.ca with SMTP id <24824>; Tue, 31 Aug 1999 03:44:11 -0400 Received: from aubrey.stanford.edu (aubrey.Stanford.EDU [36.48.0.102]) by highwire.stanford.edu (8.8.5/8.7.1) with ESMTP id WAA06077 for ; Mon, 30 Aug 1999 22:59:52 -0700 (PDT) Message-Id: <199908310559.WAA06077@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: paper referenced in The Text Editor sam In-reply-to: Message from "James A. Robinson" of "Sun, 29 Aug 1999 14:41:18 EDT."References: <199908291841.LAA18626@highwire.stanford.edu> <199908291841.LAA18626@highwire.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29791.936079192.1@aubrey.stanford.edu> Date: Tue, 31 Aug 1999 01:59:52 -0400 Sender: jimr@aubrey.stanford.edu > Structural Regular Expressions > Proceedings of the EUUG Spring 1987 Conference, p21-28 > Helsinki > May, 1987 So never mind. It was hidden in the very sam archive from bell-labs under the name "se.ps" -- the README even says "se.ps is further documentation" (It just didn't say anything else). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James A. Robinson jim.robinson@stanford.edu Stanford University HighWire Press http://highwire.stanford.edu/ 650-723-7294 (W) 650-725-9335 (F) From sam-fans-owner Wed Sep 1 03:55:07 1999 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.utoronto.ca with SMTP id <24916>; Wed, 1 Sep 1999 01:27:49 -0400 Received: from aubrey.stanford.edu (aubrey.Stanford.EDU [36.48.0.102]) by highwire.stanford.edu (8.8.5/8.7.1) with ESMTP id IAA06460 for ; Tue, 31 Aug 1999 08:47:28 -0700 (PDT) Message-Id: <199908311547.IAA06460@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam Fans" Subject: formatting HTML tables in ascii MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26591.936114448.1@aubrey.stanford.edu> Date: Tue, 31 Aug 1999 11:47:28 -0400 Sender: jimr@aubrey.stanford.edu I'm trying to format an HTML table using sam's regexp commands. What I wanted was a single line for each row, with each column seperated by a tab. I can handle single-line columns in a row like a a a b b b b b c c c c c d d d d d e e e e e e e e f f without a problem using , y/\n[A-Za-z0-9]/ x/\n/ d , x/ +/ c/ / But how do I craft a regexp to handle a blob of a multicolumn lines? 01F6 1 LATIN CAPITAL LETTER HWAIR 97-May-29 Accepted 98-Oct-22 Stage 6 01F7 1 LATIN CAPITAL LETTER WYNN 97-May-29 Accepted 98-Oct-22 Stage 6 I can match the blobs with , x/^[A-Za-z0-9]+ *\n( +([A-Za-z0-9\- ]+)+\n)+/ But is there any way to craft a regxp that, in the above example, replaces 'HWAIR\n' with 'HWAIR\t' but replaces '97-May-29\n' with '97-May-29 ' (a column sep vs a line join)? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James A. Robinson jim.robinson@stanford.edu Stanford University HighWire Press http://highwire.stanford.edu/ 650-723-7294 (W) 650-725-9335 (F) From sam-fans-owner Thu Sep 2 04:55:24 1999 Received: from mailgate.cadence.com ([158.140.2.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24769>; Thu, 2 Sep 1999 04:26:38 -0400 Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id BAA28322; Wed, 1 Sep 1999 01:09:09 -0700 (PDT) Received: from symnt3.Cadence.COM(194.32.101.100) by mailgate.cadence.com via smap (mjr-v1.2) id xma936173348.028309; Wed, 1 Sep 99 01:09:08 -0700 Received: by symnt3.cadence.com with Internet Mail Service (5.5.2232.9) id ; Wed, 1 Sep 1999 09:07:55 +0100 Message-ID: <1E485299309FD211A2100090271E27A4143246@symnt3.cadence.com> From: Nigel Roles To: "'Jim.Robinson@Stanford.Edu'" , sam Fans Subject: RE: formatting HTML tables in ascii Date: Wed, 1 Sep 1999 04:07:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" My HTML might be a bit weak, but this will swap all the \n's in the blob to \t's. ,x/^[A-Za-z0-9]+ *(\n +([A-Za-z0-9\- ]+)+)+/x/\n/c/ / -----Original Message----- From: James A. Robinson [mailto:Jim.Robinson@Stanford.Edu] Sent: Tuesday, August 31, 1999 4:47 PM To: sam Fans Subject: formatting HTML tables in ascii I'm trying to format an HTML table using sam's regexp commands. What I wanted was a single line for each row, with each column seperated by a tab. I can handle single-line columns in a row like a a a b b b b b c c c c c d d d d d e e e e e e e e f f without a problem using , y/\n[A-Za-z0-9]/ x/\n/ d , x/ +/ c/ / But how do I craft a regexp to handle a blob of a multicolumn lines? 01F6 1 LATIN CAPITAL LETTER HWAIR 97-May-29 Accepted 98-Oct-22 Stage 6 01F7 1 LATIN CAPITAL LETTER WYNN 97-May-29 Accepted 98-Oct-22 Stage 6 I can match the blobs with , x/^[A-Za-z0-9]+ *\n( +([A-Za-z0-9\- ]+)+\n)+/ But is there any way to craft a regxp that, in the above example, replaces 'HWAIR\n' with 'HWAIR\t' but replaces '97-May-29\n' with '97-May-29 ' (a column sep vs a line join)? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James A. Robinson jim.robinson@stanford.edu Stanford University HighWire Press http://highwire.stanford.edu/ 650-723-7294 (W) 650-725-9335 (F) From sam-fans-owner Fri Oct 15 03:30:23 1999 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.utoronto.ca with SMTP id <25694>; Fri, 15 Oct 1999 02:50:58 -0400 Received: from aubrey.stanford.edu (aubrey.Stanford.EDU [36.48.0.102]) by highwire.stanford.edu (8.8.5/8.7.1) with ESMTP id HAA11298 for ; Thu, 14 Oct 1999 07:03:41 -0700 (PDT) Message-Id: <199910141403.HAA11298@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam Fans" Subject: large file in sam? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19370.939909820.1@aubrey.stanford.edu> Date: Thu, 14 Oct 1999 10:03:40 -0400 Sender: jimr@aubrey.stanford.edu >From my reading of Pike's main paper on sam, I got the impression that sam could handle very large files. I thought it only read in the blocks being worked on, as it needed access to them. I find that when I try and open an 80mb text file, I get a message 'write: ?I/O error: "Success"', and no file appears. =( Anyone know if this is just a limitation of the sam port to linux? Or if there is some way around the problem (other than split(1)!)? Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James A. Robinson jim.robinson@stanford.edu Stanford University HighWire Press http://highwire.stanford.edu/ 650-723-7294 (W) 650-725-9335 (F) From sam-fans-owner Tue Oct 19 02:26:25 1999 Received: from fw2.softwell.se ([193.15.236.44]) by hawkwind.utcs.utoronto.ca with SMTP id <24747>; Tue, 19 Oct 1999 02:14:27 -0400 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw2.softwell.se (8.9.3/8.8.7) with ESMTP id NAA12391 for ; Fri, 15 Oct 1999 13:19:08 +0200 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id NAA27244 for sam-fans@hawkwind.utcs.toronto.edu; Fri, 15 Oct 1999 13:19:07 +0200 Date: Fri, 15 Oct 1999 07:19:07 -0400 From: Bengt Kleberg Message-Id: <199910151119.NAA27244@trillian.softwell.se> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: large file in sam? I have updated sam-9libs to accept the env var TMPDIR. This is slightly better than always using /tmp. The new sam-9libs is sent to "Mark H. Wilkinson" and will get a place at ftp://ftp.demon.co.uk/pub/unix/plan9 when time permits. Those in a hurry could get their copy by email from me. Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Thu Feb 10 15:08:34 2000 Received: from smtp-out1.bellatlantic.net ([199.45.39.156]) by hawkwind.utcs.utoronto.ca with SMTP id <25517>; Thu, 10 Feb 2000 14:50:40 -0500 Received: from client-117-21.bellatlantic.net (client-117-21.bellatlantic.net [151.198.117.21]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with SMTP id RAA07046 for ; Wed, 9 Feb 2000 17:14:14 -0500 (EST) From: "Michael D. Scheer" To: sam-fans@hawkwind.utcs.toronto.edu Subject: NT4 Service Pack 6 Organization: Plexus Systems Inc. Reply-To: mdash@plexsys.com Message-ID: X-Mailer: Forte Agent 1.7/32.534 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2000 17:16:49 -0500 I recently installed SP6. Sam (seanq's july 1997 binaries) now hangs on startup. I'm thinking the service pack may be the cause. Thoughts/experience? --Mike Scheer From sam-fans-owner Mon Feb 14 02:22:20 2000 Received: from spdmraab.compuserve.com ([149.174.206.155]) by hawkwind.utcs.utoronto.ca with SMTP id <26009>; Mon, 14 Feb 2000 02:14:36 -0500 Received: (from mailgate@localhost) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.2) id VAA28073 for sam-fans@hawkwind.utcs.toronto.edu; Sat, 12 Feb 2000 21:09:01 -0500 (EST) Sender: humans@ishtek.com Received: from ishtek.com (hkg-tgn-rwd-vty39.as.wcom.net [63.12.173.39]) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.2) with SMTP id VAA28002 for ; Sat, 12 Feb 2000 21:08:51 -0500 (EST) Message-Id: <200002130208.VAA28002@spdmraab.compuserve.com> X-Mailer: Ishtek MeeMail 2.1 In-Reply-To: Date: Sun, 30 Jan 2000 19:06:16 -0500 From: Alex Danilo Subject: Re: NT4 Service Pack 6 To: sam-fans@hawkwind.utcs.toronto.edu X-Face: 3}u>)koHh${W+XV18fV{i/@Sw_Cvi'3hS04kL'J-3Qoz{?D R>c6<6{LbeD5'D9+C\lUPtNBF=h=yrnT,zMx$o3YbL/p;|UGb}@0^{Tr7ppFE_sk;'p[W9,gpJ$`N2 Sp?E#o2R "Michael D. Scheer" wrote: >I recently installed SP6. Sam (seanq's july 1997 binaries) now hangs >on startup. I'm thinking the service pack may be the cause. >Thoughts/experience? I have SP6 on NT4 installed and have never seen any problem with Sam. It works fine. Naybe you should re-install it:-) Alex -- Alex Danilo http://www.ishtek.com/alex PO Box 333 Forestville NSW 2087 +61-2-9975-2297 From sam-fans-owner Mon Feb 14 02:22:27 2000 Received: from ejk.cso.uiuc.edu ([130.126.112.162]) by hawkwind.utcs.utoronto.ca with SMTP id <25291>; Mon, 14 Feb 2000 02:11:21 -0500 Received: (qmail 15000 invoked from network); 10 Feb 2000 20:33:22 -0000 Received: from archbald-17.slip.uiuc.edu (HELO uiuc.edu) (130.126.26.141) by ejk.cso.uiuc.edu with SMTP; 10 Feb 2000 20:33:22 -0000 Sender: ejk Message-ID: <38A3208B.C8188CBF@uiuc.edu> From: Ed Kubaitis Organization: CCSO - University of Illinois - Urbana-Champaign X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: NT4 Service Pack 6 References: Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Date: Thu, 10 Feb 2000 15:33:49 -0500 "Michael D. Scheer" wrote: > > I recently installed SP6. Sam (seanq's july 1997 binaries) now hangs > on startup. I'm thinking the service pack may be the cause. > Thoughts/experience? > --Mike Scheer Absolutely no help for this problem but FWIW, we found SP6 problematic in a totally unrelated area: adherance to the Common Gateway Interface specs in SP6 IIS. And advised departmental IIS web server administrators to avoid SP6 for the time being. If there's no pertinent help forthcoming from sam-fans, and you don't absolutely require something in SP6, backing out of SP6 might be plan B. -------------------------- Ed Kubaitis - ejk@uiuc.edu CCSO - University of Illinois at Urbana-Champaign From sam-fans-owner Wed Mar 1 13:29:34 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.utoronto.ca with SMTP id <25867>; Wed, 1 Mar 2000 13:09:36 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id IAA19806; Wed, 1 Mar 2000 08:17:16 -0800 (PST) Message-Id: <200003011617.IAA19806@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: Bengt Kleberg cc: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Dcc: Subject: Re: ssam, again In-reply-to: Message from Bengt Kleberg of "Wed, 01 Mar 2000 16:01:39 +0100."References: <200003011501.QAA08510@trillian.softwell.se> <200003011501.QAA08510@trillian.softwell.se> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <19165.951927435.0@aubrey.stanford.edu> Sender: jimr@aubrey.stanford.edu Date: Wed, 1 Mar 2000 11:17:51 -0500 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19165.951927435.1@aubrey.stanford.edu> > There has been previous incarnations of a stream version of sam. I have > used one by Alistair Crooks agc@westley.demon.co.uk. Here is a new one, > implemented as a rc script using sam -d. Since the fans email list is > low volume I hope that you will all survive that I email b oth the script > and the man page in seperate emails :-) > > I have thought about including this script with sam-9libs. Is it > sufficiently useful, or does it detract so much from sam that it > should be kept hidden? It's always nice to see useful wily scripts. I don't know if I ever posted or sent this one out, but I have a copy of a sam script someone posted to sam-fans ages ago. It is neat in that it uses a FIFO instead of a temporary file. It is no where near as flexibly as what you posted, but I thought you might be interested... ------- =_aaaaaaaaaa0 Content-Type: text/plain; name="wsam"; charset="us-ascii" Content-ID: <19165.951927435.2@aubrey.stanford.edu> Content-Description: FIFO based sam #!/opt/plan9/bin/rc umask 077 if ( ~ $#* 0) { echo >[1=2] Usage: wsam commands ... builtin exit 1 } if ( test -d /usr/tmp ) { tmp_dir=/usr/tmp } else if ( test -d /var/tmp ) { tmp_dir=/var/tmp } else if ( test -d /tmp ) { tmp_dir=/tmp } else if ( test -d $HOME ) { tmp_dir=$HOME } else { echo >[1=2] wsam: I cannot find a nice place to put my FIFO builtin exit 1 } FIFO=$tmp_dir^'/'^wsam.$pid.rd mkfifo -m 0700 $FIFO { echo 'r '$FIFO while ( ! ~ $#* 0 ) { echo $1 shift } echo ',p' } | sam -d >[2=] & cat >$FIFO wait $apid rm -f $FIFO builtin exit 0 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19165.951927435.3@aubrey.stanford.edu> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James A. Robinson jim.robinson@stanford.edu Stanford University HighWire Press http://highwire.stanford.edu/ 650-723-7294 (W) 650-725-9335 (F) ------- =_aaaaaaaaaa0-- From sam-fans-owner Wed Mar 1 13:29:52 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <25860>; Wed, 1 Mar 2000 13:08:32 -0500 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id QAA10613; Wed, 1 Mar 2000 16:03:12 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id QAA08517; Wed, 1 Mar 2000 16:03:13 +0100 From: Bengt Kleberg Message-Id: <200003011503.QAA08517@trillian.softwell.se> To: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Subject: ssam, script Date: Wed, 1 Mar 2000 10:04:04 -0500 #! /usr/local/plan9/bin/rc cmd_name = $0 fn usage { echo Usage: $cmd_name [-n] [-e script ] [-f sfile ] [ script ] [--] [ file ] ... } # directory for saving all text to be edited # use /tmp or TMPDIR if set tmp_dir=/tmp if (! ~ $TMPDIR ()) { tmp_dir=$TMPDIR } # file for saving all text to be edited tmp_file = $tmp_dir/ssam.$pid.XXXXXXXX # if OpenBSD mktemp exist, use it if (test -x /usr/bin/mktemp) { tmp_file = `{/usr/bin/mktemp $tmp_file} } # clean up on signals fn sighup { rm $tmp_file exit 3 } fn sigint { rm $tmp_file exit 3 } fn sigquit { rm $tmp_file exit 3 } # default values for variables printall = 1 edit_script = () edit_type = () # parse command line arguments while ({~ $1 -*} && {! ~ $1 --}) { switch ($1) { case -n printall = 0 shift case -e shift edit_script = ($edit_script $1) edit_type = ($edit_type e) shift case -f shift if (test -f $1) { edit_script = ($edit_script $1) edit_type = ($edit_type f) shift } else { echo $0: No such sfile: $1 exit 2 } case * usage exit 1 } } # anything left that is not a file is a (single) edit script if (! test -f $1) { edit_script = ($edit_script $1) edit_type = ($edit_type e) shift } # anything left is file(s) to be edited, otherwise use stdin if (~ $#* 0) { cat >> $tmp_file } else { cat $* >> $tmp_file } # send edit scripts to sam and contents of edit files # then print contents, unless -n argument # quit (twice since file has probably not been saved) i = 1 max = `{expr $#edit_script + 1} { while (! ~ $i $max) { switch ($edit_type($i)) { case e echo $edit_script($i) case f cat $edit_script($i) } i = `{expr $i + 1} } if (~ $printall 1) { echo '1,$ p' } echo q echo q } | sam -d $tmp_file >[2] /dev/null #} rm $tmp_file exit 0 From sam-fans-owner Wed Mar 1 13:29:58 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <25859>; Wed, 1 Mar 2000 13:09:20 -0500 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id QAA10609; Wed, 1 Mar 2000 16:01:39 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id QAA08510; Wed, 1 Mar 2000 16:01:39 +0100 From: Bengt Kleberg Message-Id: <200003011501.QAA08510@trillian.softwell.se> To: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Subject: ssam, again Date: Wed, 1 Mar 2000 10:04:05 -0500 There has been previous incarnations of a stream version of sam. I have used one by Alistair Crooks agc@westley.demon.co.uk. Here is a new one, implemented as a rc script using sam -d. Since the fans email list is low volume I hope that you will all survive that I email both the script and the man page in seperate emails :-) I have thought about including this script with sam-9libs. Is it sufficiently useful, or does it detract so much from sam that it should be kept hidden? Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Wed Mar 1 13:30:04 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <25861>; Wed, 1 Mar 2000 13:09:28 -0500 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id QAA10624; Wed, 1 Mar 2000 16:04:02 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id QAA08527; Wed, 1 Mar 2000 16:04:02 +0100 From: Bengt Kleberg Message-Id: <200003011504.QAA08527@trillian.softwell.se> To: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Subject: ssam , man page Date: Wed, 1 Mar 2000 10:04:28 -0500 .TH SSAM 1 "2000-01-01" .SH NAME ssam \- stream editor .SH SYNOPSIS .B ssam .RB [ \-n ] .RB [ \-e .IR script ] .RB [ \-f .IR sfile ] .RB [ \-\- ] .RB [ script ] .RI [ file " ..." ] .SH DESCRIPTION .I ssam pretends to be a stream version of .IR sam (1). .PP It saves all input, stdin and files, into a single file and then uses sam \-d to edit this file. So, despite the name, it is not a stream editor. But it does allow for text to be piped into it and edited with the editing commands used in sam. This is useful if one is spending most of ones time in .IR wily (1), instead of sam. .PP A single editing script may be specified as the last argument to ssam, before any subsequent files. Multiple editing scripts may be specified by using the -e or -f options. All editing scripts are applied to the input in the order they are specified. .SS Editing scripts Editing scripts are made from the commands described in .IR sam (1). .SH OPTIONS .TP .B \-n By default, all input is echoed to the standard output after all of the commands have been applied to it. The \-n option suppresses this behavior. .TP .B \-e " script" Append the editing script specified by the script argument to the list of editing scripts. .TP .B \-e " sfile" Append the editing scripts found in the file sfile to the list of editing scripts. .TP .B \-\- One can use the special argument \-\- to terminate the options. This allows the use of file names beginning with a dash. .SH ENVIRONMENTAL VARIABLES .TP .B TMPDIR The location used to store temporary files. If not set, /tmp is used. .SH FILES .TP .B /tmp/ssam.$pid.XXXXXXXX The file used to store all of the text to be edited. On systems that has .IR mktemp (1), (eg OpenBSD), this utility is used to further randomize the file name. .SH SEE ALSO .IR sam (1), .IR wily (1), .IR rc (1), .IR mktemp (1). .SH BUGS .PP Despite its name this is not a stream editor. It saves all input, stdin and files, into a single file and then uses sam \-d to edit this file. Since sam itself makes a copy of the file to be edited this means that there are 2 copies of all of the text. Ssam is clearly of no help if problems with disk space stops the use of sam. .PP Ssam is not written in .IR sh (1). Instead it uses .IR rc (1). This is actually more of a feature than a bug. Most sam users already have rc. If not, get it from http://www.star.le.ac.uk/~tjg/rc/. From sam-fans-owner Sat Mar 11 22:45:38 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <26323>; Sat, 11 Mar 2000 21:32:23 -0500 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id MAA19972; Mon, 6 Mar 2000 12:05:36 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id MAA22737; Mon, 6 Mar 2000 12:05:36 +0100 From: Bengt Kleberg Message-Id: <200003061105.MAA22737@trillian.softwell.se> To: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Subject: Re: ssam, again Date: Mon, 6 Mar 2000 06:06:49 -0500 Thanks to suggestion and code by "James A. Robinson" I have managed to cut disk usage in 1/2, using a fifo instead of a tmp file. I now think it is good enough to ship with sam-9libs. Any one aginst? (it is still not a stream editor, and would not work if /tmp is 50 MB and the file to edit is 50 MB, too) script follows: #! /usr/local/plan9/bin/rc cmd_name = $0 fn usage { echo Usage: $cmd_name [-n] [-e script ] [-f sfile ] [ script ] [--] [ file ] ... } # directory for saving all text to be edited # use /tmp or TMPDIR if set tmp_dir=/tmp if (! ~ $TMPDIR ()) { tmp_dir=$TMPDIR } # file for saving all text to be edited tmp_file = $tmp_dir ^ /ssam.$pid.XXXXXXXX # if OpenBSD mktemp exist, use it if (test -x /usr/bin/mktemp) { tmp_file = `{/usr/bin/mktemp $tmp_file} # there is no change-file-into-pipe cmd, so remove it before mkfifo # this allows for a denial-of-service attack, but mkfifo -m protect against disclosure rm $tmp_file } mkfifo -m 0700 $tmp_file if (! ~ $status 0) { echo mkfifo failed, someone is deliberatly "stealing" your filename echo this indicates an attempt to read the text you want to edit exit 4 } # clean up on signals fn sighup { rm $tmp_file exit 3 } fn sigint { rm $tmp_file exit 3 } fn sigquit { rm $tmp_file exit 3 } # default values for variables printall = 1 edit_script = () edit_type = () # parse command line arguments while ({~ $1 -*} && {! ~ $1 --}) { switch ($1) { case -n printall = 0 shift case -e shift edit_script = ($edit_script $1) edit_type = ($edit_type e) shift case -f shift if (test -f $1) { edit_script = ($edit_script $1) edit_type = ($edit_type f) shift } else { echo $0: No such sfile: $1 exit 2 } case * usage exit 1 } } # anything left that is not a file is a (single) edit script if (! test -f $1) { edit_script = ($edit_script $1) edit_type = ($edit_type e) shift } # send edit scripts to sam and contents of edit script files # then print contents, unless -n argument # quit (twice since file has probably not been saved) i = 1 max = `{expr $#edit_script + 1} { echo r $tmp_file while (! ~ $i $max) { switch ($edit_type($i)) { case e echo $edit_script($i) case f cat $edit_script($i) } i = `{expr $i + 1} } if (~ $printall 1) { echo '1,$ p' } echo q echo q } | sam -d >[2] /dev/null & #} sam_pid = $apid # anything left is file(s) to be edited, otherwise use stdin if (~ $#* 0) { cat >> $tmp_file } else { cat $* >> $tmp_file } wait $sam_pid rm $tmp_file exit 0 From sam-fans-owner Sat Mar 11 22:46:08 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.utoronto.ca with SMTP id <26331>; Sat, 11 Mar 2000 21:54:19 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id QAA19570; Mon, 6 Mar 2000 16:35:37 -0800 (PST) Message-Id: <200003070035.QAA19570@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: sam-fans@hawkwind.utcs.toronto.edu, wilyfans@jli.com Dcc: Subject: Re: ssam, again In-reply-to: Message from Bengt Kleberg of "Mon, 06 Mar 2000 12:05:36 +0100."References: <200003061105.MAA22737@trillian.softwell.se> <200003061105.MAA22737@trillian.softwell.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23496.952389336.1@aubrey.stanford.edu> Sender: jimr@aubrey.stanford.edu Date: Mon, 6 Mar 2000 19:36:39 -0500 > Thanks to suggestion and code by "James A. Robinson" > I have managed to cut disk usage in 1/2, > using a fifo instead of a tmp file. Credit for the original code should go to Alan Watson , not to me. Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James A. Robinson jim.robinson@stanford.edu Stanford University HighWire Press http://highwire.stanford.edu/ 650-723-7294 (W) 650-725-9335 (F) From sam-fans-owner Wed Mar 22 18:19:17 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.utoronto.ca with SMTP id <26714>; Wed, 22 Mar 2000 17:31:08 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id VAA13856 for ; Fri, 17 Mar 2000 21:23:13 -0800 (PST) Message-Id: <200003180523.VAA13856@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam Fans" Dcc: Subject: shorter struct regex? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23843.953356993.1@aubrey.stanford.edu> Sender: jimr@aubrey.stanford.edu Date: Sat, 18 Mar 2000 00:24:24 -0500 I'm starting to develop some mild RSI problems, and am trying to move away from the mouse. This leads me to look at editors like vi or sam instead of wily. In wily I end up using a pipe to sam half the time anyway, so I'm working through using structured regular expressions while editing my code in sam. I just worked through a problem, and am wondering if there was a shorter way to solve it. I had a bunch of arrays defined in a java file: ... public Hashtable return() throws MissingRequiredValueException { String[] req = { "order-id", "amount" }; String[] opt = { "card-number", "card-exp", "card-name", "card-address", "card-city", "card-zip" }; return processRequest("return", req, opt); } ... I wanted to expand the elements of the arrays to one per line. This is what I used: ,x/{\n([^}]+\n)+ }/x/, +[^\n]/x/ +/c/\n / Is there way I could of done this with less work? Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James A. Robinson jim.robinson@stanford.edu Stanford University HighWire Press http://highwire.stanford.edu/ 650-723-7294 (W) 650-725-9335 (F) From sam-fans-owner Wed Mar 22 22:25:48 2000 Received: from proxy2.ba.best.com ([206.184.139.14]) by hawkwind.utcs.utoronto.ca with SMTP id <28302>; Wed, 22 Mar 2000 22:02:58 -0500 Received: from peanut.rakitzis.com (dynamic59.pm01.san-mateo.best.com [205.149.174.59]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA18816; Wed, 22 Mar 2000 16:02:20 -0800 (PST) Received: (from byron@localhost) by peanut.rakitzis.com (8.8.7/8.8.7) id QAA24942; Wed, 22 Mar 2000 16:00:35 -0800 From: Byron Rakitzis Message-Id: <200003230000.QAA24942@peanut.rakitzis.com> To: jim.robinson@stanford.edu Subject: Re: shorter struct regex? Cc: sam-fans@hawkwind.utcs.toronto.edu Date: Wed, 22 Mar 2000 19:05:47 -0500 > public Hashtable return() > throws MissingRequiredValueException > { > String[] req = > { > "order-id", "amount" > }; > > String[] opt = > { > "card-number", "card-exp", "card-name", "card-address", "card-city", > "card-zip" > }; > return processRequest("return", req, opt); > } > .... > > I wanted to expand the elements of the arrays to one per line. This is > what I used: > > ,x/{\n([^}]+\n)+ }/x/, +[^\n]/x/ +/c/\n / > > Is there way I could of done this with less work? > > > Jim Jim, One of my favorite tricks is a pipe to fmt. Fmt will preserve leading whitespace (well, it can be trickier than that since fmt tries to do pharagraph indentation as well). To force one-column output, you only need to do "fmt -1", which strictly speaking denotes one-CHARACTER output, but fmt does the right thing. So: "card-number", "card-exp", "card-name", "card-address", "card-city", "card-zip" piped through "fmt -1" gives (at least on this linux machine): "card-number", "card-exp", "card-name", "card-address", "card-city", "card-zip" Of course, you still have the problem about selecting the braced-in regions without using the mouse. Perhaps another out-of-the-box approach is to pipe your entire code through a C beautifier. "indent" has so many options, I would be surprised if array initializers one-per-line was not one of them. Byron. From sam-fans-owner Thu Mar 23 01:29:17 2000 Received: from sgi.com ([192.48.153.1]) by hawkwind.utcs.utoronto.ca with SMTP id <25894>; Thu, 23 Mar 2000 01:25:43 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA01232 for <@external-mail-relay.sgi.com:sam-fans@hawkwind.utcs.toronto.edu>; Wed, 22 Mar 2000 16:57:49 -0800 (PST) mail_from (pj@sam.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA10957 for <@cthulhu.engr.sgi.com:sam-fans@hawkwind.utcs.toronto.edu>; Wed, 22 Mar 2000 16:57:48 -0800 (PST) mail_from (pj@sam.engr.sgi.com) Received: (from pj@localhost) by sam.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA92854 for sam-fans@hawkwind.utcs.toronto.edu; Wed, 22 Mar 2000 16:57:19 -0800 (PST) From: pj@sam.engr.sgi.com (Paul Jackson) Message-Id: <200003230057.QAA92854@sam.engr.sgi.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Applying old samx patch to newer sam? Date: Wed, 22 Mar 2000 22:30:41 -0500 Summary: The only samx patch I could find was old, and didn't entirely apply to the latest sam code. But it (the samkey features) seem to work. Should I worry? Is there a more recent samx patch? Background: I've just stumbled onto sam and samx, while casting about for a 'decent' editor for use on Linux, Irix and occassionally Windows. For the last few years, I had used 'ed' for global work, and Rick Davis' jot (aka zip) for mouse work. But jot only runs on Irix, and now I am working more with Linux. So off to look for another editor. Thanks especially to all who have contributed to this email list over the years -- the ~500 messages in the archives were very useful in getting up to speed quickly. Sam and samx are great - I am glad I found them. Details: The only samx patches I could find were: Samx Version 2: Extensions to the Unix/X11 Sam Editor ----------------------------------------------------- Ed Kubaitis (ejk@uiuc.edu) 17 April 1993 from: ftp://ftp.funet.fi/pub/unix/editors/sam/samx2/ I've managed to apply these patches to the most recent sam that I could find, circa April 1999, under: ftp://ftp.demon.co.uk/pub/unix/plan9/sam-9libs.* and the result seems to work, after a little futzing around, _except_ that the following piece of the patch seems to be quite inapplicable. The old samx patch would change the file strwidth.c thusly: *************** *** 13,18 **** l = 0; n = f->n; info = f->info; if(s) while(c = *s++) if(c < n) --- 13,28 ---- l = 0; n = f->n; info = f->info; + if (Keydefs && s) { + while (*s) { + unsigned short r; + s += chartorune(&r, s); + if (r >= n || info[r].width == 0) + r = 0x7e; + l += info[r].width; + } + return Pt(l,f->height); + } if(s) while(c = *s++) if(c < n) Should I worry that I could find no place resembling the above location to add this code? ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Thu Mar 23 16:45:40 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.utoronto.ca with SMTP id <28311>; Thu, 23 Mar 2000 16:43:28 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id HAA06451 for ; Thu, 23 Mar 2000 07:18:16 -0800 (PST) Message-Id: <200003231518.HAA06451@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam Fans" Dcc: Subject: Re: shorter struct regex? In-reply-to: Message from "Russ Cox" of "Wed, 22 Mar 2000 19:26:06 EST."References: <200003230026.TAA06530@smtp3.fas.harvard.edu> <200003230026.TAA06530@smtp3.fas.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10134.953824696.1@aubrey.stanford.edu> Sender: jimr@aubrey.stanford.edu Date: Thu, 23 Mar 2000 10:19:04 -0500 > ,x/{\n([^}]+\n)+ }/x/, +[^\n]/x/ +/c/\n / > > Is there way I could of done this with less work? > > > In sam, highlight the suspect arrays and then ,s/, */,\n /g > would work. This is a case where I think using the mouse > makes more sense than typing all the gook. Ah, but the point was to do this without the mouse. =) Not because I'm perverse, but because I had about 30 of these arrays in my program. Plus I'm writing it in noweb, so I had a mix of latex documentation mixed in with the code (which about doubles the size of the file). > But if you want > to type the gook, can't you just say > > ,x/{([^}]|\n)+}/,s/, */,\n /g The extra ',' in there before s/// would mess things up. But with a few tweaks, like making sure it doesn't add a newline if one already exists: ,x/{([^}]|\n)+}/s/, *[^\n]/,\n /g It works and would have saved 8 characters. Thank you! Jim From sam-fans-owner Thu Mar 23 16:45:55 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <28302>; Thu, 23 Mar 2000 16:42:49 -0500 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id LAA27359; Thu, 23 Mar 2000 11:26:21 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id LAA20000; Thu, 23 Mar 2000 11:26:20 +0100 From: Bengt Kleberg Message-Id: <200003231026.LAA20000@trillian.softwell.se> To: pj@sam.engr.sgi.com, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Applying old samx patch to newer sam? Date: Thu, 23 Mar 2000 05:26:47 -0500 Greetings, Please note that I am trying to 'maintain' sam-9libs. So if I seem reluctant to make any changes it could be plain lazyness :-) ANyway, samx was news to me. I think (afer having read the man page and so for a short while) that I rahter not include this in sam-9libs. 1 sam is supposed to be mouse driven, not keyboard driven. 2 auto placing of windows is something that acme/wily does (and I think they are better at user interfaceing than sam anyway) 3 auto indent, see 2 4 the perl scripts would be nice to include though. Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Thu Mar 23 16:46:01 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <24747>; Thu, 23 Mar 2000 16:42:10 -0500 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id KAA27287 for ; Thu, 23 Mar 2000 10:49:48 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id KAA19813 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 23 Mar 2000 10:49:48 +0100 From: Bengt Kleberg Message-Id: <200003230949.KAA19813@trillian.softwell.se> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: shorter struct regex? Date: Thu, 23 Mar 2000 04:51:53 -0500 > From: "James A. Robinson" > I wanted to expand the elements of the arrays to one per line. > ,x/{\n([^}]+\n)+ }/x/, +[^\n]/x/ +/c/\n / This might be totally wrong, but I assume that since you have 'hard coded' the 2 #\tab in the final c// expression I am allowed the same kind of works-for-this-problem solution :-). Presumable there is a way to get hold of the amount of #\tab and then use t to copy it to the right place... Anyway, my suggestion would be: ,x/ +".+\n/ x/ +/ c/\n / Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Thu Mar 23 16:46:23 2000 Received: from deliverator.sgi.com ([204.94.214.10]) by hawkwind.utcs.utoronto.ca with SMTP id <28314>; Thu, 23 Mar 2000 16:43:36 -0500 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA07556; Thu, 23 Mar 2000 08:57:55 -0800 (PST) mail_from (pj@sam.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA64038; Thu, 23 Mar 2000 09:02:31 -0800 (PST) mail_from (pj@sam.engr.sgi.com) Received: (from pj@localhost) by sam.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA99286; Thu, 23 Mar 2000 09:01:34 -0800 (PST) From: pj@sam.engr.sgi.com (Paul Jackson) Message-Id: <200003231701.JAA99286@sam.engr.sgi.com> To: Bengt Kleberg Subject: Re: Applying old samx patch to newer sam? Cc: sam-fans@hawkwind.utcs.toronto.edu Date: Thu, 23 Mar 2000 12:03:28 -0500 Bengt wrote: |> Please note that I am trying to 'maintain' sam-9libs. Thank-you and bless you! |> I rather not include this [samx] in sam-9libs. That's fine - I wasn't expecting sam-9libs to accomodate samx. I acknowledge that samx is "controversial". I should have been clearer that I was more looking for feedback from other samx users as to whether I should worry about the failed chunk of the patch. |> 1 sam is supposed to be mouse driven, not keyboard driven. It is common-place for the finest tools to be written with a focused vision, and then for users to turn around and do the darndest things with them. Life is good. ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Sat Mar 25 01:30:47 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.toronto.edu with SMTP id <28359>; Sat, 25 Mar 2000 01:00:42 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id NAA22426 for ; Fri, 24 Mar 2000 13:25:07 -0800 (PST) Message-Id: <200003242125.NAA22426@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam Fans" Dcc: Subject: the obvious. =) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9897.953933106.1@aubrey.stanford.edu> Date: Fri, 24 Mar 2000 16:25:07 -0500 Sender: jimr@aubrey.stanford.edu I just have to shout to the world (well, to sam fans) that this editor is wonderful! Now that I'm actually working directly in sam instead of just using it via a pipe (from wily), I'm amazed at how much easier it is to do stuff. One of the things I tend to do in Java is write a method with name X that takes no args, X(), or takes N args, X(N). X() tends to just pass some sort of defaults on to X(N). When writing JavaDoc comments for each method, it's a major pain a lot of it tends to be a straight copy and paste one to the other Now, with sam, I can just write the top java doc comment, and when I'm finally ready I can just write ,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/ To copy the top comment down to the second method. e.g. /** * 1-5 lines describing Foo */ public void X() { ... } public void X(N) { ... } turns into /** * 1-5 lines describing Foo */ public void X() { ... } /** * 1-5 lines describing Foo */ public void X(N) { ... } sam's slogan ought to be 'Making your life easier through structured regular expressions.' =) Jim From sam-fans-owner Sat Mar 25 01:33:46 2000 Received: from ejk.cso.uiuc.edu ([130.126.112.162]) by hawkwind.utcs.toronto.edu with SMTP id <28337>; Sat, 25 Mar 2000 01:00:08 -0500 Received: (qmail 24505 invoked from network); 24 Mar 2000 12:32:33 -0000 Received: from localhost (HELO uiuc.edu) (ejk@127.0.0.1) by localhost with SMTP; 24 Mar 2000 12:32:33 -0000 Sender: ejk Message-ID: <38DB6061.3F9125E9@uiuc.edu> Date: Fri, 24 Mar 2000 07:32:33 -0500 From: Ed Kubaitis Organization: CCSO - University of Illinois at Urbana-Champaign X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Applying old samx patch to newer sam? References: <200003231701.JAA99286@sam.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, AFAIK, the failed pieces in the samx patch can be ignored. As I recollect, the failed pieces were applying changes which the new (circa 1993) libXg provided in a different way/place. I've been using versions of sam + samx patch since then, building it most recently a few months ago for Redhat Linux 6.1 and have not seen any problems. Ed -------------------------- Ed Kubaitis (ejk@uiuc.edu) CCSO - University of Illinois - Urbana-Champaign Paul Jackson wrote: > > Bengt wrote: > |> Please note that I am trying to 'maintain' sam-9libs. > > Thank-you and bless you! > > |> I rather not include this [samx] in sam-9libs. > > That's fine - I wasn't expecting sam-9libs to accomodate > samx. I acknowledge that samx is "controversial". > > I should have been clearer that I was more looking > for feedback from other samx users as to whether > I should worry about the failed chunk of the patch. > > |> 1 sam is supposed to be mouse driven, not keyboard driven. > > It is common-place for the finest tools to be written > with a focused vision, and then for users to turn around > and do the darndest things with them. Life is good. > > ======================================================================= > I won't rest till it's the best ... Software Production Engineer > Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Mon Mar 27 00:40:07 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.toronto.edu with SMTP id <25342>; Mon, 27 Mar 2000 00:24:55 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id TAA02299 for ; Sun, 26 Mar 2000 19:35:10 -0800 (PST) Message-Id: <200003270335.TAA02299@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam Fans" Dcc: Subject: Re: the obvious. =) In-reply-to: Message from "kim kubik" of "Sun, 26 Mar 2000 12:54:17 PST."References: <01bf9765$97d9fd00$a4d2efd1@pkwksj.sjna.corp.dom> <01bf9765$97d9fd00$a4d2efd1@pkwksj.sjna.corp.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16178.954128110.1@aubrey.stanford.edu> Date: Sun, 26 Mar 2000 22:35:10 -0500 Sender: jimr@aubrey.stanford.edu > # Do these guys: &, <, > : > [,x/&|<|>/{ > g/&/c/&/ > g/ g/>/c/>/ > }] > > where double clicking inside the last [bracket] backhilites this > section (but not the [ ] brackets), snarf it, click in the text > file, sam it, and send it. Bang, end of story. That's a pretty good idea. Coming off of using wily (an Acme clone), one of the things I thought about doing was writing a set of guide files for sam. It's really too bad one can't have a real acme clone (with the same neat file handling) with a sam command window! =) > # BOLD FACE DOT: > [s/./&/ > a/<\/b>/ ] Since you have dot selected, why not just [s/.+/&<\/b>/]? > If you're at the EOF when you dot-out of text entry, it's easy to > get back; otherwise one can type e.g. zz, then dot out, make the > correction, and get right back to zz and continue on. Is there any vi influance here (zz)? =) I'm wondering if you really enter most of your text via the command window? I'd find it hard to go back and hunt down previous commands from the scroll-back. Does anyone have a nice make system in place to use from sam, or perhaps etags support? I'm thinking of writing up a make script that will dump the results to an ERRORS file and open it up using sam's pipe. If it exists one could send 'e ERRORS' and stuff as well, I suppose. Jim P.S. In case folks are interested, here is a diff of changes I had to make against sam.1 in order to read the man page on my Linux box (the original works fine under Solaris, but linux's groff barfs on it). *** sam.1.orig Wed Mar 22 12:36:06 2000 --- sam.1 Wed Mar 22 12:39:24 2000 *************** *** 20,26 **** .de TF .br .IP "" \w'\fB\\$1\ \ \fP'u ! .PD0 .. .de EX .CW --- 20,26 ---- .de TF .br .IP "" \w'\fB\\$1\ \ \fP'u ! .PD .. .de EX .CW *************** *** 71,77 **** the editor's file until it first becomes the current file\(emthat to which editing commands apply\(emwhereupon its menu entry is printed. The options are ! .TF "\-r machine " .TP .B \-d Do not download the terminal part of --- 71,77 ---- the editor's file until it first becomes the current file\(emthat to which editing commands apply\(emwhereupon its menu entry is printed. The options are ! .TF .TP .B \-d Do not download the terminal part of *************** *** 105,111 **** to represent newlines. A regular expression may never contain a literal newline character. The elements of regular expressions are: ! .TF "[^abc] " .TP .B . Match any character except newline. --- 105,111 ---- to represent newlines. A regular expression may never contain a literal newline character. The elements of regular expressions are: ! .TF .TP .B . Match any character except newline. *************** *** 145,151 **** and .I r2 are regular expressions. ! .TF "r1|r2 " .TP .BI ( r1 ) Match what --- 145,151 ---- and .I r2 are regular expressions. ! .TF .TP .BI ( r1 ) Match what *************** *** 210,216 **** All files always have a current substring, called dot, that is the default address. .SS Simple Addresses ! .TF ?regexp? .TP .BI # n The empty string after character --- 210,216 ---- All files always have a current substring, called dot, that is the default address. .SS Simple Addresses ! .TF .TP .BI # n The empty string after character *************** *** 223,229 **** .IR n . .TP .BI / regexp / ! .PD0 .TP .BI ? regexp ? The substring that matches the regular expression, --- 223,229 ---- .IR n . .TP .BI / regexp / ! .PD .TP .BI ? regexp ? The substring that matches the regular expression, *************** *** 272,278 **** and .I a2 are addresses. ! .TF "a1+a2 " .TP .IB a1 + a2 The address --- 272,278 ---- and .I a2 are addresses. ! .TF .TP .IB a1 + a2 The address *************** *** 413,419 **** .br .ne 1.2i .SS Text commands ! .PD0 .TP .BI a/ text / .TP --- 413,419 ---- .br .ne 1.2i .SS Text commands ! .PD .TP .BI a/ text / .TP *************** *** 526,532 **** Print a menu of files. The format is: .RS ! .TF "XorXblankXX" .TP .BR ' " or blank" indicating the file is modified or clean, --- 526,532 ---- Print a menu of files. The format is: .RS ! .TF .TP .BR ' " or blank" indicating the file is modified or clean, *************** *** 791,797 **** provides the following operators, each of which uses one or more cursors to prompt for selection of a window or sweeping of a rectangle. ! .TF "reshape " .TP .B new Create a new, empty file: --- 791,797 ---- provides the following operators, each of which uses one or more cursors to prompt for selection of a window or sweeping of a rectangle. ! .TF .TP .B new Create a new, empty file: *************** *** 873,879 **** quoted strings or bracketed strings, depending on the text at the click. .PP Button 2 provides a menu of editing commands: ! .TF "/regexp" .TP .B cut Delete dot and save the deleted text in the snarf buffer. --- 873,879 ---- quoted strings or bracketed strings, depending on the text at the click. .PP Button 2 provides a menu of editing commands: ! .TF .TP .B cut Delete dot and save the deleted text in the snarf buffer. From sam-fans-owner Mon Mar 27 00:40:27 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.toronto.edu with SMTP id <25205>; Mon, 27 Mar 2000 00:24:43 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id RAA22703; Sat, 25 Mar 2000 17:51:46 -0800 (PST) Message-Id: <200003260151.RAA22703@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "kim kubik" cc: "sam Fans" Dcc: Subject: Re: the obvious. =) In-reply-to: Message from "kim kubik" of "Sat, 25 Mar 2000 15:47:54 PST."References: <01bf96b4$8a262aa0$7dc9efd1@pkwksj.sjna.corp.dom> <01bf96b4$8a262aa0$7dc9efd1@pkwksj.sjna.corp.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3671.954035506.1@aubrey.stanford.edu> Date: Sat, 25 Mar 2000 20:51:46 -0500 Sender: jimr@aubrey.stanford.edu > >,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/ > > this just ran up against my (mis)understanding of > sam's regexp's. I'm sure when first using sam I did > something similar to your example above and the > 'greedy' little bastard (.+\n)+ would (to my way > of thinking) eat the whole file, that is, never see > the closing */ of the commment because the .+ should > just keep on going. Here's what I *think* is going on, but I'm no regex guru... A '(.*\n)+' would keep it going to the end of the file. With '(.+\n)+' I'm specifying that there must be at least one character before the newline. So this match ends at the first blank line. I think the engine then backtracks until it finds a match for ' \*\/' -- which is the end of the comment. I believe the previous match of a newline ensures that it will not hit the comments within the blocks (as those are '\n\t *'). And yes, I do space indent my comments so the '*' lines up with the topmost one. I thought that was in my post, though I did tab-indent the whole block. Perhaps my mailer munged it. Jim From sam-fans-owner Mon Mar 27 00:40:38 2000 Received: from smtp6.jps.net ([216.119.0.86]) by hawkwind.utcs.toronto.edu with SMTP id <25324>; Mon, 27 Mar 2000 00:24:49 -0500 Received: from pkwksj.sjna.corp.dom (209-239-210-164.oak.jps.net [209.239.210.164]) by smtp6.jps.net (8.9.3/8.9.0) with SMTP id MAA24750; Sun, 26 Mar 2000 12:54:39 -0800 (PST) From: "kim kubik" To: Cc: "sam Fans" Subject: Re: the obvious. =) Date: Sun, 26 Mar 2000 15:54:17 -0500 Message-ID: <01bf9765$97d9fd00$a4d2efd1@pkwksj.sjna.corp.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 -----Original Message----- From: James A. Robinson To: kim kubik Cc: sam Fans Date: Saturday, March 25, 2000 5:54 PM Subject: Re: the obvious. =) >> >,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/ >> >> this just ran up against my (mis)understanding of >> sam's regexp's. > > >Here's what I *think* is going on, but I'm no regex guru... A '(.*\n)+' >would keep it going to the end of the file. With '(.+\n)+' I'm specifying >that there must be at least one character before the newline. So this >match ends at the first blank line. I think the engine then backtracks >until it finds a match for ' \*\/' Jim - I tried a couple of different scenarios on before I posted and *think* a blank line was one of the first I tried since the . in (.+\n)+ obviously needs to match something "real". Since I can't remember exactly, my best guess is that what I tried must have been something like: /** * stuff about foo * * and the above is a "blank" line * only if you're a total moron. . . */ which should put me in the forefront of those nominated for the Homer Simpson Award, Year 2000 ("Doooh!"). Since you seem to like to pass around neat SREs, there are times when it's necessary to convert a txt file to html and using a sam "macro" file that I stick off to the side next to the txt file (and using # faux-comments to remind me what each does), there are things in txt2htm.sam like: # Do these guys: &, <, > : [,x/&|<|>/{ g/&/c/&/ g//c/>/ }] where double clicking inside the last [bracket] backhilites this section (but not the [ ] brackets), snarf it, click in the text file, sam it, and send it. Bang, end of story. And when casually perusing the text, if I note something worth embolding, backhiliting the text of interest and snarfing this from the "macro" file, sam-ing the text file and sending: # BOLD FACE DOT: [s/./&/ a/<\/b>/ ] does just that. And tho old habits are difficult to break, I've learned (but still find myself forgetting) that one does not need the samX cursor-arrow keys if you just STAY IN THE SAM COMMAND WINDOW and move around using /re and -/re. It is so much easier than cursoring around, trying to remember which -Duh moves right one word, whatever. You're looking at 'miscake' and want it to be 'mistake' and almost as if sam can read one's mind, you just dot-out and send the cursor there in one move, make the correction, and get back where you were. If you're at the EOF when you dot-out of text entry, it's easy to get back; otherwise one can type e.g. zz, then dot out, make the correction, and get right back to zz and continue on. Maybe all this is obvious to everyone but me. . . most things are. - kim From sam-fans-owner Mon Mar 27 00:40:45 2000 Received: from smtp5.jps.net ([216.119.0.85]) by hawkwind.utcs.toronto.edu with SMTP id <25114>; Mon, 27 Mar 2000 00:24:09 -0500 Received: from pkwksj.sjna.corp.dom (209-239-201-125.oak.jps.net [209.239.201.125]) by smtp5.jps.net (8.9.3/8.9.0) with SMTP id PAA05678; Sat, 25 Mar 2000 15:47:52 -0800 (PST) From: "kim kubik" To: , "sam Fans" Subject: Re: the obvious. =) Date: Sat, 25 Mar 2000 18:47:54 -0500 Message-ID: <01bf96b4$8a262aa0$7dc9efd1@pkwksj.sjna.corp.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 -----Original Message----- From: James A. Robinson To: sam Fans Date: Friday, March 24, 2000 10:26 PM Subject: the obvious. =) >I just have to shout to the world (well, to sam fans) that this editor >is wonderful>I'm finally ready I can just write > >,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/ > >To copy the top comment down to the second method. e.g. > Jim (or anyone): this just ran up against my (mis)understanding of sam's regexp's. I'm sure when first using sam I did something similar to your example above and the 'greedy' little bastard (.+\n)+ would (to my way of thinking) eat the whole file, that is, never see the closing */ of the commment because the .+ should just keep on going. But I tried what you have and it works, so obviously all this time the way I've been getting around this, using addresses, e.g. ,x/re/{ .,/re2/do stuff } isn't necessary. So what am I missing? - kim PS: in your example there's a space after the second + that shouldn't be there, right? At least by your example, but probably you do comments as: /* * so there really is a space * before the last splat. * */ And the example left this out. From sam-fans-owner Mon Mar 27 15:40:08 2000 Received: from plan9.cs.bell-labs.com ([204.178.31.2]) by hawkwind.utcs.toronto.edu with SMTP id <25324>; Mon, 27 Mar 2000 15:22:20 -0500 From: "rob pike" Subject: Re: the obvious. =) Date: Mon, 27 Mar 2000 09:37:26 -0500 To: sam-fans@hawkwind.utcs.toronto.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <00Mar27.152220est.25324@hawkwind.utcs.toronto.edu> ,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/ Regular expressions have their limitations, which is why Sam also has addresses. These provide a simpler and safer way to match multi-line things like comments: ,x/^\/\*/ .,/\*\/\n/ t /}\n/ This one works even if there are no blank lines. Here's a troff paragraph-at-a-time pattern: ,x/^\.PP/ .,/^\.(PP|SH)/- ... Also if there's a slash in the pattern, you can use another character as the delimiter and save a backslash, as in this example for C++ // comments: x/\/\// goes to x;//; Have fun. -rob From sam-fans-owner Mon Mar 27 15:40:19 2000 Received: from web3207.mail.yahoo.com ([204.71.202.204]) by hawkwind.utcs.toronto.edu with SMTP id <25205>; Mon, 27 Mar 2000 15:19:35 -0500 Message-ID: <20000327135218.17756.qmail@web3207.mail.yahoo.com> Received: from [204.68.140.35] by web3207.mail.yahoo.com; Mon, 27 Mar 2000 05:52:18 PST Date: Mon, 27 Mar 2000 08:52:18 -0500 From: Jim Crigler Subject: sam-9libs vs. Linux (RH 6.0) To: sam-fans@hawkwind.utcs.toronto.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hmmm ... I asked this on comp.editors a couple of weeks ago, and was pointed here as a place to subscribe for real sam help. Under RedHat 6.0 I can run sam -d fine, but when I attempt to start the "gui" version, samterm shows up and then disappears. The sam process then dies with a "broken pipe" message. Where can I go from here? BTW, sam works on Solaris (at work) with no problems at all. -- Jim Crigler __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From sam-fans-owner Mon Mar 27 18:18:49 2000 Received: from smtp5.jps.net ([216.119.0.85]) by hawkwind.utcs.toronto.edu with SMTP id <25225>; Mon, 27 Mar 2000 17:57:50 -0500 Received: from pkwksj.sjna.corp.dom (209-239-207-129.oak.jps.net [209.239.207.129]) by smtp5.jps.net (8.9.3/8.9.0) with SMTP id OAA02049; Mon, 27 Mar 2000 14:38:25 -0800 (PST) From: "kim kubik" To: , "sam Fans" Subject: Re: the obvious. =) (to everyone but kim) Date: Mon, 27 Mar 2000 17:39:41 -0500 Message-ID: <01bf983d$578f4f60$1ec5efd1@pkwksj.sjna.corp.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 -----Original Message----- From: James A. Robinson To: sam Fans Date: Sunday, March 26, 2000 9:45 PM Subject: Re: the obvious. =) J.A.R. wrote: >one of the things I thought about doing was writing a set of guide >files for sam. It's really too bad one can't have a real acme clone >(with the same neat file handling) with a sam command window! =) > that's sort of what gave me the idea of these sam "macro" files, the acme/wily guide files. I just put the oft-used command sequences in a little window about the shape of a vertical Hershey candy bar off to the right and then snarf what I need. >> # BOLD FACE DOT: >> [s/./&/ >> a/<\/b>/ ] >Since you have dot selected, why not just [s/.+/&<\/b>/]? > I *think* that the above will work on text in one line ONLY. My memory is that I tried a number of convoluted SREs (well, the number I could come up with is still a small integer) and finally had to settle on the a/<\/b> as being necessary if I wanted to backhilite any arbitrary section of possibly multi-line text which could possibly include multi \n\n+ 's. >Is there any vi influance here (zz)? =) I'm wondering if you really >enter most of your text via the command window? I'd find it hard to go >back and hunt down previous commands from the scroll-back. Like I said originally, old habits die hard; I still shove the mouse cursor into the text window, click and start typing, but I really really try to do it in the sam window. And yes, every once in a while I need to telnet to a Unix system and so have to remember some vi, but the zz idea actually came from a much older editor, called creatively EDIT, described in Software-P&E (1971)v1, p73-81, the author being a guy at Cambridge (UK) name of S.R. Bourne, before he came across the pond to play with that other OS. EDIT used a lone z to get out of text entry mode and enter command mode and had a cute way of walking thru the whole file, executing commands if you prefaced the command sequence with a 0 (similar to sam's , ). Being almost thirty years ago, one had to give a small line number range at startup which would be kept in core and edited; the rest of the file remained unaltered on disc. Over the years the editor got altered by various people including maybe Chris Fraser. While EDIT did't have re's, Marting Richards did publish an algorithm "strongly influenced by ... Thompson" (S-P&E (1979)v9,p527-534) later on (a student onced described Richards as the dullest lecturer he had in his whole time at Cambridge). Anyhow, I hope some of this helps someone. - kim PS: Jim I also have a number of SREs that walk through a file and delete those little copywrite notices and things like that which you Elsevier people seem to be so keen on including. :-) From sam-fans-owner Mon Mar 27 18:18:57 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.toronto.edu with SMTP id <25166>; Mon, 27 Mar 2000 17:57:31 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id MAA11002; Mon, 27 Mar 2000 12:54:45 -0800 (PST) Message-Id: <200003272054.MAA11002@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: Jim Crigler cc: sam-fans@hawkwind.utcs.toronto.edu Dcc: Subject: Re: sam-9libs vs. Linux (RH 6.0) In-reply-to: Message from Jim Crigler of "Mon, 27 Mar 2000 08:52:18 EST."References: <20000327135218.17756.qmail@web3207.mail.yahoo.com> <20000327135218.17756.qmail@web3207.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17534.954190485.1@aubrey.stanford.edu> Date: Mon, 27 Mar 2000 15:54:45 -0500 Sender: jimr@aubrey.stanford.edu > Hmmm ... I asked this on comp.editors a couple of weeks ago, and was > pointed here as a place to subscribe for real sam help. Under RedHat > 6.0 I can run sam -d fine, but when I attempt to start the "gui" version, > samterm shows up and then disappears. The sam process then dies with a > "broken pipe" message. I think I responded to your post in Usenet, but in case you didn't see it: check your color depth. I found that samterm had problems with (I think) 24 bit depth. I normally use 16, and that works fine. I think 32 should also work. Try running 'xwininfo' and clicking on the root window to see what depth it is running at. Jim From sam-fans-owner Tue Mar 28 18:56:49 2000 Received: from highwire.stanford.edu ([171.64.249.40]) by hawkwind.utcs.toronto.edu with SMTP id <26299>; Tue, 28 Mar 2000 18:20:38 -0500 Received: from aubrey.stanford.edu (jimr@aubrey.Stanford.EDU [171.64.31.58]) by highwire.stanford.edu (8.9.3/HIGHWIRE2.0) with ESMTP id KAA18140; Tue, 28 Mar 2000 10:28:56 -0800 (PST) Message-Id: <200003281828.KAA18140@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: Jim Crigler cc: sam-fans@hawkwind.utcs.toronto.edu Dcc: Subject: Re: sam-9libs vs. Linux (RH 6.0) In-reply-to: Message from Jim Crigler of "Tue, 28 Mar 2000 10:15:41 PST."References: <20000328181541.26330.qmail@web3203.mail.yahoo.com> <20000328181541.26330.qmail@web3203.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19312.954268136.1@aubrey.stanford.edu> Date: Tue, 28 Mar 2000 13:28:56 -0500 Sender: jimr@aubrey.stanford.edu > 16-bit X works, thanks. Neither 24 nor 32 works, > however. Is this likely to be a libXg problem or > something in samterm per se? I seem to recall it was a libXg problem. Someone explained that part of the code expects the depth to be have some properties that don't apply to 24bit depth (or, I guess, 32bit). I'm sorry that I don't remember the details. Jim From sam-fans-owner Tue Mar 28 18:56:56 2000 Received: from web3203.mail.yahoo.com ([204.71.202.200]) by hawkwind.utcs.toronto.edu with SMTP id <26298>; Tue, 28 Mar 2000 18:20:02 -0500 Message-ID: <20000328181541.26330.qmail@web3203.mail.yahoo.com> Received: from [192.31.86.34] by web3203.mail.yahoo.com; Tue, 28 Mar 2000 10:15:41 PST Date: Tue, 28 Mar 2000 13:15:41 -0500 From: Jim Crigler Subject: Re: sam-9libs vs. Linux (RH 6.0) To: jim.robinson@stanford.edu Cc: sam-fans@hawkwind.utcs.toronto.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- "Jim Robinson" wrote: > > Hmmm ... I asked this on comp.editors a couple of > weeks ago, and was > > pointed here as a place to subscribe for real sam > help. Under RedHat > > 6.0 I can run sam -d fine, but when I attempt to > start the "gui" version, > > samterm shows up and then disappears. The sam > process then dies with a > > "broken pipe" message. > > I think I responded to your post in Usenet, but in > case > you didn't see it: check your color depth. I found > that > samterm had problems with (I think) 24 bit depth. > > I normally use 16, and that works fine. I think 32 > should also work. Try running 'xwininfo' and > clicking > on the root window to see what depth it is running > at. 16-bit X works, thanks. Neither 24 nor 32 works, however. Is this likely to be a libXg problem or something in samterm per se? -- Another Jim __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From sam-fans-owner Mon Apr 3 18:49:56 2000 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.toronto.edu with SMTP id <24954>; Mon, 3 Apr 2000 18:34:14 -0400 Received: (qmail 26971 invoked by uid 991); 29 Mar 2000 05:10:33 -0000 Message-ID: <20000329051033.26969.qmail@g.bio.cse.psu.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: sam-9libs vs. Linux (RH 6.0) In-Reply-To: Message from "James A. Robinson" of "Tue, 28 Mar 2000 13:28:56 EST." <200003281828.KAA18140@highwire.stanford.edu> Date: Wed, 29 Mar 2000 00:10:32 -0500 From: Scott Schwartz | I seem to recall it was a libXg problem. Someone explained that part of | the code expects the depth to be have some properties that don't apply | to 24bit depth (or, I guess, 32bit). I'm sorry that I don't remember | the details. Yes, exactly. The bug was, libXg only does power-of-two depths, so 24 bits doesn't work. Annoyingly, most X servers don't let you ask for more than one depth visual, which would be the obvious workaround for something like sam. From sam-fans-owner Mon Apr 3 18:50:09 2000 Received: from ratatosk.utfors.se ([195.58.103.123]) by hawkwind.utcs.toronto.edu with SMTP id <24865>; Mon, 3 Apr 2000 18:32:59 -0400 Received: from nowhere (md469203b.utfors.se) by ratatosk.utfors.se (Sun Internet Mail Server sims.3.5.1999.07.30.00.05.p8) with ESMTP id <0FS500309PSDPA@ratatosk.utfors.se> for sam-fans@hawkwind.utcs.toronto.edu; Wed, 29 Mar 2000 02:09:50 +0200 (MET DST) Received: (qmail 25170 invoked by uid 1000); Wed, 29 Mar 2000 00:07:54 +0000 Date: Tue, 28 Mar 2000 19:07:54 -0500 From: Daniel Neri Subject: Re: sam-9libs vs. Linux (RH 6.0) In-reply-to: "James A. Robinson"'s message of "Tue, 28 Mar 2000 13:28:56 -0500" To: jim.robinson@stanford.edu Cc: Jim Crigler , sam-fans@hawkwind.utcs.toronto.edu Message-id: <87wvmm8wpx.fsf@nowhere.mayonnaise.net> Organization: mayonnaise.net -- a safe european home MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6 Lines: 18 References: <200003281828.KAA18140@highwire.stanford.edu> "James A. Robinson" writes: > I seem to recall it was a libXg problem. Someone explained that part of > the code expects the depth to be have some properties that don't apply > to 24bit depth (or, I guess, 32bit). I'm sorry that I don't remember > the details. FWIW, sam(term) works fine for me at 24bit depth (running on OpenBSD/i386 and XFree86 3.3.5). Though this is "plain sam", not based on 9libs. Best wishes, /Daniel -- Daniel Neri dne@mayonnaise.net From sam-fans-owner Mon Apr 3 18:50:17 2000 Received: from smtp6.jps.net ([216.119.0.86]) by hawkwind.utcs.toronto.edu with SMTP id <25423>; Mon, 3 Apr 2000 18:34:20 -0400 Received: from pkwksj.sjna.corp.dom (209-239-201-230.oak.jps.net [209.239.201.230]) by smtp6.jps.net (8.9.3/8.9.0) with SMTP id RAA06831; Thu, 30 Mar 2000 17:11:51 -0800 (PST) From: "kim kubik" To: "kim kubik" , , "sam Fans" Subject: Re: the obvious. =) (to everyone but kim) Date: Thu, 30 Mar 2000 20:12:53 -0500 Message-ID: <01bf9aae$3d654fe0$e6c9efd1@pkwksj.sjna.corp.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 -----Original Message----- From: James A. Robinson To: kim kubik Date: Monday, March 27, 2000 2:55 PM Subject: Re: the obvious. =) (to everyone but kim) (kim wrote): >> PS: Jim I also have a number of SREs that walk through a file and >> delete those little copywrite notices and things like that which >> you Elsevier people seem to be so keen on including. :-) (and Jim replied): > Elsevier??? What gave you the idea I was an Elsevier person? > I work for HighWire Press, Elsevier is the antithesis of us. > > Jim Ooops, guess I stuck my foot in it again! Sorry if there are any implications I'm unaware of vis-a-vis Highwire & Elsevier, like maybe Elsevier publishes only to the pederast trade, while Highwire has loftier aspirations. On a safer topic the re you gave for bolding dot in an html file just needed a tiny addition to work in (I think, a dubious activity at best and not equating to 'I am') that s/(.+\n*)*/&<\/b>/ will surround any amount of backhilited text with ..., not just text on one line, and the text may include blank lines. So thank you and sorry about the faux pas. - kim From sam-fans-owner Mon Apr 3 18:50:24 2000 Received: from web3202.mail.yahoo.com ([204.71.202.199]) by hawkwind.utcs.toronto.edu with SMTP id <24931>; Mon, 3 Apr 2000 18:34:08 -0400 Message-ID: <20000329041205.767.qmail@web3202.mail.yahoo.com> Received: from [64.1.54.123] by web3202.mail.yahoo.com; Tue, 28 Mar 2000 20:12:05 PST Date: Tue, 28 Mar 2000 23:12:05 -0500 From: Jim Crigler Subject: Re: sam-9libs vs. Linux (RH 6.0) To: Daniel Neri , jim.robinson@stanford.edu Cc: sam-fans@hawkwind.utcs.toronto.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > "James A. Robinson" > writes: > > > I seem to recall it was a libXg problem. Someone > explained that part of > > the code expects the depth to be have some > properties that don't apply > > to 24bit depth (or, I guess, 32bit). I'm sorry > that I don't remember > > the details. > > FWIW, sam(term) works fine for me at 24bit depth > (running on > OpenBSD/i386 and XFree86 3.3.5). Though this is > "plain sam", not based > on 9libs. Hmm ... I compiled sam-9libs at the same time as wily-9libs, and wily seems to have no problem (modulo not getting caps lock when it's pressed under wily). -- Jim Crigler __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From sam-fans-owner Mon Apr 3 18:50:29 2000 Received: from web3202.mail.yahoo.com ([204.71.202.199]) by hawkwind.utcs.toronto.edu with SMTP id <25484>; Mon, 3 Apr 2000 18:34:27 -0400 Message-ID: <20000331154744.5873.qmail@web3202.mail.yahoo.com> Received: from [192.31.86.34] by web3202.mail.yahoo.com; Fri, 31 Mar 2000 07:47:44 PST Date: Fri, 31 Mar 2000 10:47:44 -0500 From: Jim Crigler Subject: Input buffer limit??? To: sam-fans@hawkwind.utcs.toronto.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii The other day I was typing in some text via the "sam" (command) window and after a few tens of lines (don't know how many; sorry), I suddenly got a message in the command window like "?out of buffer memory" or some such. Is this a known characteristic of sam? Where should I have looked in the docs to find it? -- Jim Crigler __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From sam-fans-owner Wed Apr 12 01:04:36 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.toronto.edu with SMTP id <24785>; Wed, 12 Apr 2000 00:52:11 -0400 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id MAA25126; Wed, 5 Apr 2000 12:51:38 +0200 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id MAA03109; Wed, 5 Apr 2000 12:51:37 +0200 Date: Wed, 5 Apr 2000 06:51:37 -0400 From: Bengt Kleberg Message-Id: <200004051051.MAA03109@trillian.softwell.se> To: criglerj@yahoo.com, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Input buffer limit??? > From: Jim Crigler > The other day I was typing in some text via the "sam" > (command) window and after a few tens of lines (don't > know how many; sorry), I suddenly got a message in the > command window like "?out of buffer memory" Greetings, I ahve tried various combinations. Many lines work fine, I have > 60 lines with > 1500 characters after an a command. But, 1 long line does have problem after 512 characters. It appears that sam can only send 512 bytes to samterm. As a workaround, could you limit your lines to 512 characters and then join them together after they have arrived in the file? Presumably it should be possible to change this limit if it is a problem... Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Fri Apr 14 17:39:30 2000 Received: from deliverator.sgi.com ([204.94.214.10]) by hawkwind.utcs.toronto.edu with SMTP id <25463>; Fri, 14 Apr 2000 17:35:24 -0400 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA00900 for <@external-mail-relay.sgi.com:sam-fans@hawkwind.utcs.toronto.edu>; Thu, 13 Apr 2000 16:04:52 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA74538 for <@cthulhu.engr.sgi.com:sam-fans@hawkwind.utcs.toronto.edu>; Thu, 13 Apr 2000 16:09:33 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: (from pj@localhost) by sam.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA02307 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 13 Apr 2000 16:09:09 -0700 (PDT) Date: Thu, 13 Apr 2000 19:09:09 -0400 From: pj@sam.engr.sgi.com (Paul Jackson) Message-Id: <200004132309.QAA02307@sam.engr.sgi.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: reworked samx patch, plus softtab feature [sorry for the email a few minutes ago w/o a Subject, I botched an email session ... pj ] Bengt in particular, but anyone -- I invite comment on where (or if) to publicize these 3 sam and samx patches. -- I would like to make available the following three patches: samx.a.patch -- upgrade sam to samx (samx2 for 9libs) samx.b.patch -- fix compiler warnings samx.c.patch -- add softtab feature to samx These three patches apply to the Editor "sam", in the "9libs" for maintained by Bengt Kleberg , and distributed from: ftp://ftp.demon.co.uk/pub/unix/plan9/sam-9libs.* These three patches update the "samx2" extensions for Sam, and add one more feature: softtabs. -- What is samx: Samx Version 2 (samx2) adds some extensions to the sam editor. So far as I can find, the only samx patches are: Samx Version 2: Extensions to the Unix/X11 Sam Editor ----------------------------------------------------- Ed Kubaitis (ejk@uiuc.edu) 17 April 1993 from: ftp://ftp.funet.fi/pub/unix/editors/sam/samx2/ Samx provides several additional gui editing features, and a "samkeys" facility for mapping these features to the desired keyboard or mouse input. -- What each patch does: samx.a.patch: This patch reworks the old "samx2" patch for application to the current (as of May 1999) 9libs version of the sam editor. The old 1993 samx patch no longer applied cleanly to this current sam. samx.b.patch: Recompiling the above current 9libs sam on my system (SGI Irix 6.5.7m) generated several compiler warnings, mostly for (1) unused variables (2) missing enum typecasts and (3) missing 'int' in declarations. This patch corrects these warnings. samx.c.patch: This patch adds a "softtab" capability, to let you work with 4 space (the '4' is configurable) soft tabs, while maintaining compatibility with 8 space (the '8' was already hardcoded in sam, and continues to be so) hardware (or display manager) tabs. The details of these softtabs are given below. -- Applying these patches: These three patches are intended to be applied sequentially to the 9libs sam base. The following instructions are overly specific in several places -- I figure it is easier for the reader to generalize the specific than to attempt these instructions in their full generality. 1) Obtain 9libs and sam-9libs, from: ftp://ftp.demon.co.uk/pub/unix/plan9/9libs-1.0.tar.gz ftp://ftp.demon.co.uk/pub/unix/plan9/sam-9libs.tar.gz 2) Obtain samx2, from: ftp://ftp.funet.fi/pub/unix/editors/sam/samx2/samx2.shar.Z 3) Obtain these samx.[abc].patch patches, from: ??? Not publically available yet -- would it make sense to put these patches on ftp.demon.co.uk or ftp.funet.fi or SourceForge.net (perhaps we should establish a "sam" project there) or oss.sgi.com (my employers Open Source site). I can email or otherwise deliver these patches, but want to give the sam old-timers, especially Bengt, a chance to comment and express preferences before putting them up on a public site. My preference would be to create a SourceForge.net project, and put all the pieces (sam, samx and my three patches) there. But I'm quite flexible. 4) Unpack 9libs: gunzip 9libs-1.0.tar.gz tar xvf 9libs-1.0.tar 5) Unpack sam-9libs: gunzip sam-9libs.tar.gz cd 9libs-1.0 tar xvf ../sam-9libs.tar 6) Unpack samx2 (for the documentation and example configuration, not for the patch, which samx.a.patch replaces): cd .. gunzip samx2.shar.Z mkdir samx mv samx2.shar samx cd samx sh samx2.shar 7) Apply patches. They are intended to be applied in order. You can apply just a, or a and b, and all three a, b and c. cd .. patch < samx.a.patch patch < samx.b.patch patch < samx.c.patch 8) Configure, make and install: cd 9libs-1.0 ./configure make su make install -- Details of softtabs: These softtabs emulate tabs at a specified spacing, while assuming that the actual tab character '\t' has a fixed 8 column spacing. These softtabs _only_ apply in the left margin (in the horizontal whitespace immediately following a new line or beginning of file). The "softtab" key spaces to the next column, modulo "softtabWidth", and rewrites all the preceeding horizontal whitespace on that line to use as many hard tab '\t' characters as there is space for, given the hardcoded assumption that hard tabs are 8 columns. The "softbackspace" key (in the left margin) backs up to the previous soft tab stop, converting hard tabs to spaces and removing spaces, as need be. Outside of the left margin, or if softtabs are not enabled or if softtabwidth is not > 0, softtab and softbackspace behave like simple tab and backspace (adding a tab char, and deleting the previous char, whatever it is). The X11 resource samterm*softtabWidth controls the soft tab width. Attempts to set softtabWidth to any number greater than 16 are silently forced to set it to 16. The resource samterm*softTab controls the initial setting of whether softtabs are enabled or not. The Samkey softtabtoggle toggles whether softtabs are enabled. -- Configuring softtabs: The following settings, copied from my .Xresources and Samkeys files, control and bind softtabs: ............ .Xresources ................ samterm*softtabWidth: 4 samterm*softTab: on ............ Samkeys ................ BackSpace : softbackspace Tab : softtab Delete : softbackspace ctrl h : softbackspace ctrl i : softtab alt Tab : softtabtoggle ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Fri Apr 14 17:39:46 2000 Received: from deliverator.sgi.com ([204.94.214.10]) by hawkwind.utcs.toronto.edu with SMTP id <25462>; Fri, 14 Apr 2000 17:34:09 -0400 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA29468 for <@external-mail-relay.sgi.com:sam-fans@hawkwind.utcs.toronto.edu>; Thu, 13 Apr 2000 15:52:09 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA71525 for <@cthulhu.engr.sgi.com:sam-fans@hawkwind.utcs.toronto.edu>; Thu, 13 Apr 2000 15:56:44 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: (from pj@localhost) by sam.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA27205 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 13 Apr 2000 15:56:20 -0700 (PDT) Date: Thu, 13 Apr 2000 18:56:20 -0400 From: pj@sam.engr.sgi.com (Paul Jackson) Message-Id: <200004132256.PAA27205@sam.engr.sgi.com> To: sam-fans@hawkwind.utcs.toronto.edu Bengt in particular, but anyone -- I invite comment on where (or if) to publicize these 3 sam and samx patches. -- I would like to make available the following three patches: samx.a.patch -- upgrade sam to samx (samx2 for 9libs) samx.b.patch -- fix compiler warnings samx.c.patch -- add softtab feature to samx These three patches apply to the Editor "sam", in the "9libs" for maintained by Bengt Kleberg , and distributed from: ftp://ftp.demon.co.uk/pub/unix/plan9/sam-9libs.* These three patches update the "samx2" extensions for Sam, and add one more feature: softtabs. -- What is samx: Samx Version 2 (samx2) adds some extensions to the sam editor. So far as I can find, the only samx patches are: Samx Version 2: Extensions to the Unix/X11 Sam Editor ----------------------------------------------------- Ed Kubaitis (ejk@uiuc.edu) 17 April 1993 from: ftp://ftp.funet.fi/pub/unix/editors/sam/samx2/ Samx provides several additional gui editing features, and a "samkeys" facility for mapping these features to the desired keyboard or mouse input. -- What each patch does: samx.a.patch: This patch reworks the old "samx2" patch for application to the current (as of May 1999) 9libs version of the sam editor. The old 1993 samx patch no longer applied cleanly to this current sam. samx.b.patch: Recompiling the above current 9libs sam on my system (SGI Irix 6.5.7m) generated several compiler warnings, mostly for (1) unused variables (2) missing enum typecasts and (3) missing 'int' in declarations. This patch corrects these warnings. samx.c.patch: This patch adds a "softtab" capability, to let you work with 4 space (the '4' is configurable) soft tabs, while maintaining compatibility with 8 space (the '8' was already hardcoded in sam, and continues to be so) hardware (or display manager) tabs. The details of these softtabs are given below. -- Applying these patches: These three patches are intended to be applied sequentially to the 9libs sam base. The following instructions are overly specific in several places -- I figure it is easier for the reader to generalize the specific than to attempt these instructions in their full generality. 1) Obtain 9libs and sam-9libs, from: ftp://ftp.demon.co.uk/pub/unix/plan9/9libs-1.0.tar.gz ftp://ftp.demon.co.uk/pub/unix/plan9/sam-9libs.tar.gz 2) Obtain samx2, from: ftp://ftp.funet.fi/pub/unix/editors/sam/samx2/samx2.shar.Z 3) Obtain these samx.[abc].patch patches, from: ??? Not publically available yet -- would it make sense to put these patches on ftp.demon.co.uk or ftp.funet.fi or SourceForge.net (perhaps we should establish a "sam" project there) or oss.sgi.com (my employers Open Source site). I can email or otherwise deliver these patches, but want to give the sam old-timers, especially Bengt, a chance to comment and express preferences before putting them up on a public site. My preference would be to create a SourceForge.net project, and put all the pieces (sam, samx and my three patches) there. But I'm quite flexible. 4) Unpack 9libs: gunzip 9libs-1.0.tar.gz tar xvf 9libs-1.0.tar 5) Unpack sam-9libs: gunzip sam-9libs.tar.gz cd 9libs-1.0 tar xvf ../sam-9libs.tar 6) Unpack samx2 (for the documentation and example configuration, not for the patch, which samx.a.patch replaces): cd .. gunzip samx2.shar.Z mkdir samx mv samx2.shar samx cd samx sh samx2.shar 7) Apply patches. They are intended to be applied in order. You can apply just a, or a and b, and all three a, b and c. cd .. patch < samx.a.patch patch < samx.b.patch patch < samx.c.patch 8) Configure, make and install: cd 9libs-1.0 ./configure make su make install -- Details of softtabs: These softtabs emulate tabs at a specified spacing, while assuming that the actual tab character '\t' has a fixed 8 column spacing. These softtabs _only_ apply in the left margin (in the horizontal whitespace immediately following a new line or beginning of file). The "softtab" key spaces to the next column, modulo "softtabWidth", and rewrites all the preceeding horizontal whitespace on that line to use as many hard tab '\t' characters as there is space for, given the hardcoded assumption that hard tabs are 8 columns. The "softbackspace" key (in the left margin) backs up to the previous soft tab stop, converting hard tabs to spaces and removing spaces, as need be. Outside of the left margin, or if softtabs are not enabled or if softtabwidth is not > 0, softtab and softbackspace behave like simple tab and backspace (adding a tab char, and deleting the previous char, whatever it is). The X11 resource samterm*softtabWidth controls the soft tab width. Attempts to set softtabWidth to any number greater than 16 are silently forced to set it to 16. The resource samterm*softTab controls the initial setting of whether softtabs are enabled or not. The Samkey softtabtoggle toggles whether softtabs are enabled. -- Configuring softtabs: The following settings, copied from my .Xresources and Samkeys files, control and bind softtabs: ............ .Xresources ................ samterm*softtabWidth: 4 samterm*softTab: on ............ Samkeys ................ BackSpace : softbackspace Tab : softtab Delete : softbackspace ctrl h : softbackspace ctrl i : softtab alt Tab : softtabtoggle ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Mon Apr 17 16:31:35 2000 Received: from web3205.mail.yahoo.com ([204.71.202.202]) by hawkwind.utcs.toronto.edu with SMTP id <25571>; Mon, 17 Apr 2000 16:22:00 -0400 Message-ID: <20000417145820.14626.qmail@web3205.mail.yahoo.com> Received: from [192.31.86.35] by web3205.mail.yahoo.com; Mon, 17 Apr 2000 07:58:20 PDT Date: Mon, 17 Apr 2000 10:58:20 -0400 From: Jim Crigler Subject: wily-9libs and sam-9libs on 24-bit Linux display To: Sam Fans , Wily Fans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Before I delve into the particulars, is does anyone know in advance why wily-9libson a 24-bit Linux display works fine (modulo I can't use the capslock key), while sam-9libs (samterm, actually) balks? They were built in the same 9libs hierarchy at the same time. -- Jim Crigler __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com From sam-fans-owner Tue Apr 25 04:18:06 2000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by hawkwind.utcs.toronto.edu with SMTP id <25475>; Tue, 25 Apr 2000 04:08:39 -0400 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA02984 for <@external-mail-relay.sgi.com:sam-fans@hawkwind.utcs.toronto.edu>; Thu, 20 Apr 2000 19:13:03 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA90061 for <@cthulhu.engr.sgi.com:sam-fans@hawkwind.utcs.toronto.edu>; Thu, 20 Apr 2000 19:08:56 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: (from pj@localhost) by sam.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA48323 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 20 Apr 2000 19:08:30 -0700 (PDT) Date: Thu, 20 Apr 2000 22:08:30 -0400 From: pj@sam.engr.sgi.com (Paul Jackson) Message-Id: <200004210208.TAA48323@sam.engr.sgi.com> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Samx - one more time ... I continue to work in my spare time (slowly) adding features to sam+samx. I worry that I might be "splintering" sam - creating a fork of development off the main stream. But so far as I can tell, no one else is touching the code. I'd like to openly consider desires and directions suggested by others. But so far as I can tell, no one else cares. If anyone is interested, or worried, let me know. Meanwhile, I'm having fun adding some sugar to a really fine editor. -- My most recent completed change is: This patch adds two Samkeys to push and pop the current Sam window, so that Samkeys macros can safely restore the current window after intentionally switching to another. This way, Samkey macros don't have to assume that they are only invoked in the work window, say. I have also gotten my patches working cleanly on Linux, in addition to Irix, where I started. I am seeking to make this work available on SGI's Open Source Server, http://oss.sgi.com - perhaps within the next month or two, at the leisurely pace this is proceeding. If anyone wants it by other means or sooner, let me know. Or if Bengt or anyone objects to this, let me know. Later on, if there is interest, and if I get to it, I might also include this on SGI's freeware, so that it is accessible to our Irix users as well (oss.sgi.com is focused on Linux users). -- My current, biased entirely to my idiosyncracies, "todo" list is: 1) Add KD_pushwin/KD_popwin so can write Samkeys macros that don't assume starting in work window, but can always return to whatever was the starting window. [Done - April 17, 2000] 2) KD_markline that extends dot to full lines, and that always extends right end of dot at least one char. Hence repeated invocations cause dot to grow forward by another line. 3) KD_reverselook - search upward for dot 4) debug loss of samterm/sam sync. 5) package sam+samx onto http://oss.sgi.com reasonably. 6) add samd, samb to package (for situation where you want to control foreground vs separate window display: samd invokes "sam -d", for when invoking from other tools that expect an editor to not fork; samb goes background if DISPLAY is set, else foreground, for when invoking from other tools that should behave differently depending on whether coming from the X11 server (gfx head) or remotely (rsh/ssh/telnet/...). [samb, samd coded and working on March 27, 2000. Need to package.] 7) Finish the above samkeys_parse stuff, and add Makefile that will install sam*_* scripts as part of install, fixing #!...perl... header along the way. [Done - April 14, 2000] 8) Need updated samparse_keys, and add Makefile configure stuff to handle samx as part of sam-9libs. [Done April 13, 2000] 9) Package as rpm (source and Linux binary) with patches called out. 10) Adapt configure/Makefile.in so that it picks up X headers and libraries on Linux from /usr/include/X11 (or where ever X11 headers normally go) and from /usr/X11R6/lib (in addition to /usr/lib for other libraries). 11) Brief like Home & End key KD_BriefHome, KD_BriefEnd support (press Home 1, 2 or 3 times to go to beginning of line, page or file). 12) Do something about undo working off screen, and not undoing pure motion. As it works now, I find it surprising that doing (a) a change, (b) another change, then (c) large motion, followed by an undo appears to do nothing (but undoes (b)), and if the undo is repeated, again appears to do nothing (but undoes (a)). Either motion should be considered an undoable event, or undo should force some part of what it changes on screen, or ... 13) Redo sure would be nice, if I can learn sam well enough to implement it. For one, it would help ameliorate the botch that I get into with item (12), undoing more than I realize or can easily recall. 14) Just as with Python's Idle (at least until recent changes in the developers branch), it seems too easy to get the cursor off the command line in the sam window, and get confused as to what it means to press enter. I'd like a tighter control by sam of the sam window cursor, more like working at a shell prompt, or at least along the lines of what I hear tell has recently been done to Idle to improve its interface there. 15) More X11 like mouse behaviour, at least when on X11, would be nice. Though its not clear I have the skills to implement this. The middle mouse thing is a minor unpleasant complication. 16) The Rick Davis jot (aka zip, only on Irix) editor had several accessible buffers for what was most recently entered, removed, ..., making it easy to do things like entering the same text in multiple places - typing it once, and using the mouse and Insert key to place duplicates of it. I miss that. ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Wed Apr 26 18:00:58 2000 Received: from deliverator.sgi.com ([204.94.214.10]) by hawkwind.utcs.toronto.edu with SMTP id <25762>; Wed, 26 Apr 2000 17:13:43 -0400 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA19862; Wed, 26 Apr 2000 13:22:11 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA28571; Wed, 26 Apr 2000 13:26:53 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: (from pj@localhost) by sam.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA74945; Wed, 26 Apr 2000 13:25:47 -0700 (PDT) Date: Wed, 26 Apr 2000 16:25:47 -0400 From: pj@sam.engr.sgi.com (Paul Jackson) Message-Id: <200004262025.NAA74945@sam.engr.sgi.com> To: sam-fans@hawkwind.utcs.toronto.edu, Bengt Kleberg Subject: Re: Samx - one more time ... Bengt wrote: |> I am (very low-key) maintaining sam as it is, ... and grateful we are for your work |> Perhaps we complement each other? I maintain sam as it is, |> you enhance it? As I concluded in a private email thread that branched off this public thread: Seems like what I am dreaming of is really yet-another-editor, likely using sam+samx as a code base, and for its core design element integrating the gui and command interface, but undergoing some major surgery, aimed entirely at X11 environments. Looks like I should choose yet-another-name for such a beast, if it ever gets past being my private toy. I will read the license that comes with Sam again, to be sure I am fitting comfortably within its terms. Not sure if I will go down this path or not - if you're uncomfortable with it, let me know. I might call it 'tam' -- because 't' comes after 's', and because I used to work with a fine chap called Sam Tam. ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Wed Apr 26 18:01:06 2000 Received: from proxy2.ba.best.com ([206.184.139.14]) by hawkwind.utcs.toronto.edu with SMTP id <24945>; Wed, 26 Apr 2000 17:11:15 -0400 Received: from ishtek.com (co3001671-a.belrs1.nsw.optushome.com.au [203.164.12.105]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id DAA03351 for ; Tue, 25 Apr 2000 03:58:48 -0700 (PDT) Message-Id: <200004251058.DAA03351@proxy2.ba.best.com> X-Mailer: Ishtek MeeMail 2.5 In-Reply-To: <200004210208.TAA48323@sam.engr.sgi.com> Date: Tue, 25 Apr 2000 06:59:10 -0400 From: Alex Danilo Subject: Re: Samx - one more time ... To: sam-fans@hawkwind.utcs.toronto.edu X-Face: _H@C|CDucW'FeI!o@eNy]QydT!"gdD,Xv&JAv^*tM/y@pY>~0@nw0O7$>v!wTPjXQFHs#5_ Y,7bd!O43rX(n1G}C+T,Befs7r,Ur%MrgK8_.p) ,^{ pj@sam.engr.sgi.com (Paul Jackson) wrote: >I continue to work in my spare time (slowly) adding features >to sam+samx. > >I worry that I might be "splintering" sam - creating a fork of >development off the main stream. But so far as I can tell, no >one else is touching the code. I'm sure there are many people 'touching' the code, it's just that there is no formalised source project base on the 'sam' distribution, it's just an 'as-is' release. >From what I've seen, there is a huge reluctance by the developers (i.e. Rob) to add any 'features'. This is in line with the original interface which is mouse for movement, and keyboard for entry only. It is minimalistic, and is meant to be so - things like auto-indent were never meant to be in 'sam', it isn't a user-interface ideal. The released code was supposed to be just that - a release, and if you want to add stuff to it, then go for it, but it won't be part of 'sam' proper. I offered some simple mods to do implement cursor keys a while ago in the comp.os.plan9 list, but no-one wanted it. So, what I'm saying is that anything that changes 'sam' from the Lucent release makes it not sam. So, if you want to add 'features', that should be done as some alternate project, like 'samx' which is of course sam with Xtensions. >I am seeking to make this work available on SGI's Open Source >Server, http://oss.sgi.com - perhaps within the next month or I'd honestly consider creating a new project on SourceForge, as that is (sort-of) vendor-neutral, and it can be maintained after you leave SGI. > 4) debug loss of samterm/sam sync. This, as far as I can see is the only bad bug which exists in the Lucent release. If you open a big batch of files, and do something like: X/.*/,x//d to nuke carriage returns in all your source files, sam and samterm get out of sync and barf. This is a really nasty bug, and the Windows version created by Sean Quinlan doesn't seem to exhibit it - so I guess it may have been fixed internally to the Labs, but never made it out into the public release. By all means add new features if you wish, but it should be made a distinct stream of development from that which we know as 'sam'. Perhaps we could call it son-of-sam:-) Alex -- Alex Danilo http://www.ishtek.com/alex PO Box 333 Forestville NSW 2087 +61-2-9975-2297 From sam-fans-owner Wed Apr 26 18:01:41 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.toronto.edu with SMTP id <25238>; Wed, 26 Apr 2000 17:13:36 -0400 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id QAA04143; Tue, 25 Apr 2000 16:38:52 +0200 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id QAA08798; Tue, 25 Apr 2000 16:38:51 +0200 Date: Tue, 25 Apr 2000 10:38:51 -0400 From: Bengt Kleberg Message-Id: <200004251438.QAA08798@trillian.softwell.se> To: pj@sam.engr.sgi.com, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Samx - one more time ... > pj@sam.engr.sgi.com > I worry that I might be "splintering" sam I am (very low-key) maintaining sam as it is, just doing bug fixes and adding ports (ie making sure that configure works for any new platforms). Sometime in the future, if time permits, I will try to remove any hardcoded limits (like the 512 characters samterm -> sam message limit). I will not attempt to add features. You have clearly a much broader scoop in your interest for sam. Perhaps we complement each other? I maintain sam as it is, you enhance it? Effectivly creating two sams, ofcourse. Presumably sam-as-it-is will stop beeing used, and that does not matter to me since I am not doing anyhting anyway. However, have you looked at wily? This is generally considered as a alternative to sam, and it has loads of the things you seem (to me) to be interested in. Perhaps it would be better to devout your energy to wily instead? Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Wed Apr 26 18:01:48 2000 Received: from plan9.cs.bell-labs.com ([204.178.31.2]) by hawkwind.utcs.toronto.edu with SMTP id <25043>; Wed, 26 Apr 2000 17:12:03 -0400 From: "rob pike" Subject: Re: Samx - one more time ... Date: Tue, 25 Apr 2000 08:42:32 -0400 To: sam-fans@hawkwind.utcs.toronto.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <00Apr26.171203edt.25043@hawkwind.utcs.toronto.edu> Around here, we spend most of our time avoiding adding sam features. But we did add one recently: Redo. Sean Dorward and I plugged Acme's file management stuff into Sam a few months ago. This made it much faster (a factor of 6 or 7) at reading big files, and made redo possible. (The command syntax is u with a negative count; u- redoes the last undone change). There have been many other changes triggered by changes in Plan 9, rendering the Plan 9 source quite different from the publicly available version of Sam, but if someone is interested in doing the work I will send them the code. -rob From sam-fans-owner Thu Apr 27 12:37:10 2000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by hawkwind.utcs.toronto.edu with SMTP id <25762>; Thu, 27 Apr 2000 12:24:24 -0400 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA08102; Wed, 26 Apr 2000 15:31:50 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA75177; Wed, 26 Apr 2000 15:27:37 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: (from pj@localhost) by sam.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA76824; Wed, 26 Apr 2000 15:26:30 -0700 (PDT) Date: Wed, 26 Apr 2000 18:26:30 -0400 From: pj@sam.engr.sgi.com (Paul Jackson) Message-Id: <200004262226.PAA76824@sam.engr.sgi.com> To: sam-fans@hawkwind.utcs.toronto.edu, Alex Danilo Subject: Re: Samx - one more time ... |> So, what I'm saying is that anything that changes 'sam' |> from the Lucent release makes it not sam. Yes - that agrees with my conclusions so far. Ah but I'll miss the name 'sam'. That's my son's name ... |> SGI's Open Source Server [vs] SourceForge If it gets to the point that either I am not at SGI or that there is enough to involve others, then definitely SourceForge. And if it happens that I left SGI unexpectedly and suddenly, I can certainly start the SourceForge project at that time, from the SGI OSS base. Perhaps sooner to SourceForge, perhaps not. Doesn't matter much yet. ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Thu Apr 27 12:37:25 2000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]) by hawkwind.utcs.toronto.edu with SMTP id <25768>; Thu, 27 Apr 2000 12:25:43 -0400 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05557; Wed, 26 Apr 2000 15:39:56 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA78804; Wed, 26 Apr 2000 15:35:42 -0700 (PDT) mail_from (pj@sam.engr.sgi.com) Received: (from pj@localhost) by sam.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA76725; Wed, 26 Apr 2000 15:34:41 -0700 (PDT) Date: Wed, 26 Apr 2000 18:34:41 -0400 From: pj@sam.engr.sgi.com (Paul Jackson) Message-Id: <200004262234.PAA76725@sam.engr.sgi.com> To: sam-fans@hawkwind.utcs.toronto.edu, "rob pike" Subject: Re: Samx - one more time ... |> Around here, we spend most of our time avoiding adding |> sam features. it's already pretty damn good. |> But we did add one recently: Redo. excellent |> but if someone is interested in doing the work I will If I am able to free up a block of time, and if Bengt is willing to pick up the merge (this would be pure 'sam', no samx or whatever I'm doing), then I'd like to do that. But I can't right now. If I did that for the public sam fans, then I would feel better about using this code base for my own endeavors - which tend to blend Rick Davis's zip (jot) with sam, focused on X11. If someone else gets there first - more power to them. ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Thu Apr 27 12:37:33 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.toronto.edu with SMTP id <25801>; Thu, 27 Apr 2000 12:30:53 -0400 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id KAA08881; Thu, 27 Apr 2000 10:04:14 +0200 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id KAA14913; Thu, 27 Apr 2000 10:04:14 +0200 Date: Thu, 27 Apr 2000 04:04:14 -0400 From: Bengt Kleberg Message-Id: <200004270804.KAA14913@trillian.softwell.se> To: rob@plan9.bell-labs.com, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Samx - one more time ... > From: "rob pike" > There have been many other changes triggered by > changes in Plan 9, rendering the Plan 9 source quite > different from the publicly available version of Sam, > but if someone is interested in doing the work I will > send them the code. Yes please. I would like to try updateing sam to the current Plan9 version. One thing: Does this mean that libXg also needs changes? As is perhaps known I only look after sam/samterm, not libXg. The latter is handled by a skilled person by the name of Mark H Wilkinson. Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From sam-fans-owner Fri Apr 28 00:11:20 2000 Received: from plan9.cs.bell-labs.com ([204.178.31.2]) by hawkwind.utcs.toronto.edu with SMTP id <24768>; Thu, 27 Apr 2000 23:22:09 -0400 From: "Russ Cox" Date: Thu, 27 Apr 2000 16:17:43 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: Samx - one more time ... MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <00Apr27.232209edt.24768@hawkwind.utcs.toronto.edu> One thing: Does this mean that libXg also needs changes? The graphics model has changed quite a bit, and there is not currently anything approximating libXg, at least in such a form. I have vague notions of it being a nice thing to have a libXg equivalent for the new graphics model, and I do have many of the pieces, but not all, and they're not packaged correctly. Rob should correct me if I'm wrong, but I believe that the protocol between sam and samterm has not changed, so that you could pick up the aforementioned sam changes and keep using the current samterm, if you were not inclined to do battle with X. Russ From sam-fans-owner Mon May 8 18:57:05 2000 Received: from anchor-post-32.mail.demon.net ([194.217.242.90]) by hawkwind.utcs.toronto.edu with SMTP id <25878>; Mon, 8 May 2000 18:52:20 -0400 Received: from kremvax.demon.co.uk ([212.228.106.206] helo=kremvax.kremvax.net) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 12ovzh-0001T9-0W; Mon, 8 May 2000 23:27:23 +0100 Received: from bijou.kremvax.net (bijou.kremvax.net [192.168.144.20]) by kremvax.kremvax.net (Postfix) with ESMTP id 5022E4C; Mon, 8 May 2000 23:22:26 +0100 (BST) Received: from kremvax.net (kremvax.kremvax.net [192.168.144.24]) by bijou.kremvax.net (Postfix) with ESMTP id 982819413; Mon, 8 May 2000 23:22:24 +0100 (BST) Sender: mhw@kremvax.net Message-ID: <39173E20.77F0D49@kremvax.net> Date: Mon, 8 May 2000 18:22:24 -0400 From: "Mark H. Wilkinson" X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jim Crigler Cc: Sam Fans , Wily Fans Subject: Re: wily-9libs and sam-9libs on 24-bit Linux display References: <20000417145820.14626.qmail@web3205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim Crigler wrote: > Before I delve into the particulars, is does anyone know in advance why > wily-9libson a 24-bit Linux display works fine (modulo I can't use the capslock > key), while sam-9libs (samterm, actually) balks? They were built in the same > 9libs hierarchy at the same time. Probably because sam allocates new bitmaps for things like pop-up menus while wily doesn't (not having menus) - if you run the libXg test program does it crash when it gets to the menu test on the same display? libXg just doesn't work with some bitmap depths, notably 15bpp. However, I thought it worked Ok on 24bpp displays so I'd like to dig a bit more to find out what's going on. -Mark. From sam-fans-owner Tue May 9 19:02:19 2000 Received: from ejk.cso.uiuc.edu ([130.126.112.162]) by hawkwind.utcs.toronto.edu with SMTP id <25878>; Tue, 9 May 2000 18:51:58 -0400 Received: (qmail 15990 invoked from network); 8 May 2000 23:18:41 -0000 Received: from castle-89.slip.uiuc.edu (HELO uiuc.edu) (ejk@130.126.28.89) by ejk.cso.uiuc.edu with SMTP; 8 May 2000 23:18:41 -0000 Sender: ejk Message-ID: <39174AE2.CEC76A4@uiuc.edu> Date: Mon, 8 May 2000 19:16:50 -0400 From: Ed Kubaitis Organization: CCSO - University of Illinois at Urbana-Champaign X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sam Fans CC: Wily Fans Subject: Re: wily-9libs and sam-9libs on 24-bit Linux display References: <20000417145820.14626.qmail@web3205.mail.yahoo.com> <39173E20.77F0D49@kremvax.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Mark H. Wilkinson" wrote: > > Jim Crigler wrote: > > > Before I delve into the particulars, is does anyone know in advance why > > wily-9libson a 24-bit Linux display works fine (modulo I can't use the capslock > > key), while sam-9libs (samterm, actually) balks? They were built in the same > > 9libs hierarchy at the same time. > > Probably because sam allocates new bitmaps for things like pop-up menus while wily > doesn't (not having menus) - if you run the libXg test program does it crash when > it gets to the menu test on the same display? > > libXg just doesn't work with some bitmap depths, notably 15bpp. However, I thought > it worked Ok on 24bpp displays so I'd like to dig a bit more to find out what's > going on. > > -Mark. FWIW, on RH Linux 6.2 recently, I had to backoff 24bpp to 16 to make an ancient (circa 1993-4) version of libXg/samterm functional. -------------------------- Ed Kubaitis (ejk@uiuc.edu) CCSO - University of Illinois at Urbana-Champaign From sam-fans-owner Fri May 26 15:27:11 2000 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.toronto.edu with SMTP id <26700>; Fri, 26 May 2000 15:14:48 -0400 Received: (qmail 24795 invoked by uid 991); 25 May 2000 19:37:07 -0000 Message-ID: <20000525193707.24793.qmail@g.bio.cse.psu.edu> To: sam-fans@hawkwind.utcs.toronto.edu Subject: new sam for unix MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <24790.959283335.0@bio.cse.psu.edu> Date: Thu, 25 May 2000 15:37:07 -0400 From: Scott Schwartz ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24790.959283335.1@bio.cse.psu.edu> Hi all, Rob Pike was kind enough to send me the source for the new sam, and I've gone through and made the changes necessary to get it to compile under unix. I found one bug in the process, so I hope everyone else will look things over carefully too. The changes: - replaced anonymous unions with ansi-std ones. - used a plan9-flavor print library instead of stdio (mostly). - the sam err file in tmp is now given a unique name, to avoid symlink races. mktemp used where necessary. - all plumbing is stubbed out. maybe we can revisit this after the next edition of plan 9 is published. This version appears to work with samterm, but it does exercise what I think is a problem with the X11 version of that. If I create a large file, all lines the same length, and make a global substitution, and then repeatedly undo and redo, samterm appears to miss some characters. ------- =_aaaaaaaaaa0 Content-Type: application/octet-stream Content-ID: <24790.959283335.2@bio.cse.psu.edu> Content-Description: sam.tar.gz Content-Transfer-Encoding: base64 c2FtMmsvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwNDA3NTUAMDAwMTcz NwAwMDAwMTUxADAwMDAwMDAwMDAwADA3MTEyMDI3MTIxADAwMTI3NTQANQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAw MjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABz YW0yay9NYWtlZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAxNzM3 ADAwMDAxNTEAMDAwMDAwMDAyMDYAMDcxMTIwMjcyMDYAMDAxNDQxMwAwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwc2Nod2FydHoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABnY3NlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwNDAAMDAwMDAy NwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFs bDoKCWNkIGxpYjsgbWFrZSAKCWNkIHNhbTsgbWFrZQoKY2xlYW46CgljZCBsaWI7IG1ha2UgY2xl YW4KCWNkIHNhbTsgbWFrZSBjbGVhbgoKdGFyOiBjbGVhbgoJdGFyIC1jdmYgLi4vc2FtMmstdW5p eC50YXIgLUMgLi4gc2FtMmsKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2Ft MmsvaW5jbHVkZS8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwNDA3NTUAMDAwMTczNwAw MDAwMTUxADAwMDAwMDAwMDAwADA3MTEyMDI3MTE0ADAwMTQ0MDEANQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzYW0y ay9pbmNsdWRlL2xpYmMuaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAxNzM3ADAw MDAxNTEAMDAwMDAwMDI2MDQAMDcxMTE2NDAwNDMAMDAxNTQ2MwAwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwc2Nod2FydHoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABnY3NlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwNDAAMDAwMDAyNwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNpZm5k ZWYgTElCQzlfSAojZGVmaW5lIExJQkM5X0gKCi8qIENvcHlyaWdodCAoYykgMTk5MiBBVCZUIC0g QWxsIHJpZ2h0cyByZXNlcnZlZC4gKi8KLyogQ2hhbmdlcyBieSBTY290dCBTY2h3YXJ0eiwgMjAw MCAqLwoKCS8qIFBsYW4gOSBDIGxpYnJhcnkgaW50ZXJmYWNlICovCgojZGVmaW5lCWR1cChhLGIp CQkJZHVwMihhLGIpCiNkZWZpbmUJc2VlayhhLGIsYykJCQlsc2VlayhhLGIsYykKI2RlZmluZQll eGVjKGEsYikJCQlleGVjdihhLGIpCiNkZWZpbmUJZ2V0d2QoYSxiKQkJCWdldGN3ZChhLGIpCiNk ZWZpbmUJVVNFRChhKQojZGVmaW5lIFNFVChhKQoKZW51bQp7CglPUkVBRAk9CTAsCQkvKiBvcGVu IGZvciByZWFkICovCglPV1JJVEUJPQkxLAkJLyogb3BlbiBmb3Igd3JpdGUgKi8KCU9SRFdSCT0J MiwJCS8qIG9wZW4gZm9yIHJlYWQvd3JpdGUgKi8KCUVSUkxFTgk9CTY0CQkvKiBsZW5ndGggb2Yg ZXJyb3IgbWVzc2FnZSAqLwoJLE9DRVhFQwk9CTQKCSxPUkNMT1NFID0JOAoJLERJUkxFTiAgPSAg ICA4MTkyCn07CgplbnVtCnsKCVVURm1heAkJPSAzLAkJLyogbWF4aW11bSBieXRlcyBwZXIgcnVu ZSAqLwoJUnVuZXN5bmMJPSAweDgwLAkJLyogY2Fubm90IHJlcHJlc2VudCBwYXJ0IG9mIGEgdXRm IHNlcXVlbmNlICg8KSAqLwoJUnVuZXNlbGYJPSAweDgwLAkJLyogcnVuZSBhbmQgdXRmIHNlcXVl bmNlcyBhcmUgdGhlIHNhbWUgKDwpICovCglSdW5lZXJyb3IJPSAweDgwCQkvKiBkZWNvZGluZyBl cnJvciBpbiB1dGYgKi8KfTsKCi8qCiAqIG5ldyBydW5lIHJvdXRpbmVzCiAqLwpleHRlcm4JaW50 CXJ1bmV0b2NoYXIoY2hhciosIFJ1bmUqKTsKZXh0ZXJuCWludAljaGFydG9ydW5lKFJ1bmUqLCBj aGFyKik7CmV4dGVybglpbnQJcnVuZWxlbihsb25nKTsKZXh0ZXJuCWludAlmdWxscnVuZShjaGFy KiwgaW50KTsKCi8qCiAqIHJ1bmUgcm91dGluZXMgZnJvbSBjb252ZXJ0ZWQgc3RyIHJvdXRpbmVz CiAqLwpleHRlcm4JbG9uZwl1dGZsZW4oY2hhciopOwkJLyogd2FzIGNvdW50cnVuZSAqLwpleHRl cm4JY2hhcioJdXRmcnVuZShjaGFyKiwgbG9uZyk7CmV4dGVybgljaGFyKgl1dGZycnVuZShjaGFy KiwgbG9uZyk7CmV4dGVybgljaGFyKgl1dGZ1dGYoY2hhciosIGNoYXIqKTsKLyoKICoJTWlzY2Vs bGFuZW91cyBmdW5jdGlvbnMKICovCi8qZXh0ZXJuCXZvaWQJZnByaW50KGludCwgY2hhciAqLCAu Li4pOyovCmV4dGVybglpbnQJbm90aWZ5ICh2b2lkKCopKHZvaWQgKiwgY2hhciAqKSk7CmV4dGVy bglpbnQJZXJyc3RyKGNoYXIgKik7CmV4dGVybgljaGFyKglnZXR1c2VyKHZvaWQpOwpleHRlcm4J dm9pZAlleGl0cyhjaGFyKik7CmV4dGVybgl2b2lkCV9leGl0cyhjaGFyKik7CmV4dGVybiAgaW50 ICAgICBjcmVhdGUoY2hhciAqLCBpbnQsIGludCk7CgojZW5kaWYKAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNhbTJrL2lu Y2x1ZGUvdS5oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDE3MzcAMDAwMDE1 MQAwMDAwMDAwNTUzNgAwNzExMTY0NjYyMgAwMDE1MDM2ADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI2lmbmRlZiBV OV9ICiNkZWZpbmUgVTlfSAovKiBDb3B5cmlnaHQgKGMpIDE5OTIgQVQmVCAtIEFsbCByaWdodHMg cmVzZXJ2ZWQuICovCi8qIENoYW5nZXMgMjAwMCBieSBTY290dCBTY2h3YXJ0eiAqLwoKLyogRGVm aW5pdGlvbnMgZnJvbSB0aGUgdW5kZXJseWluZyBzeXN0ZW0sIHRvIHN1cHBvcnQgdGhlCiAgIFBs YW4gOSBpbnRlcmZhY2VzIGRlc2NyaWJlZCBsaWJjLmggKi8KCiNpbmNsdWRlIDx1bmlzdGQuaD4K I2luY2x1ZGUgPHN5cy93YWl0Lmg+CiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KI2luY2x1ZGUgPHN5 cy9zdGF0Lmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVk ZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHN0ZGFyZy5oPgojaW5jbHVkZSA8c2lnbmFsLmg+CiNpbmNs dWRlIDxzZXRqbXAuaD4KI2luY2x1ZGUgPHB3ZC5oPgojaW5jbHVkZSA8bGltaXRzLmg+CiNpbmNs dWRlIDxmY250bC5oPgojaW5jbHVkZSA8ZXJybm8uaD4KI2luY2x1ZGUgPGFzc2VydC5oPgogCiNp bmNsdWRlICJwcmludC5oIgoKCS8qIFN5c3RlbSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgKi8K CiNkZWZpbmUgbmlsIDAKdHlwZWRlZiB1bnNpZ25lZCBjaGFyICAgICAgICAgICB1Y2hhcjsKdHlw ZWRlZiB1bnNpZ25lZCBzaG9ydCAgICAgICAgICBSdW5lOwoKI2lmZGVmCVNZU1ZSMwojaW5jbHVk ZQk8bWFsbG9jLmg+CnR5cGVkZWYJdW5zaWduZWQgc2hvcnQJdXNob3J0Owp0eXBlZGVmIHVuc2ln bmVkIGxvbmcJdWxvbmc7CiNkZWZpbmUJcmVtb3ZlKHYpCQkJdW5saW5rKHYpCiNkZWZpbmUJV0VY SVRTVEFUVVMocykJCQkoKChzKT4+OCkmMHhGRikKZXh0ZXJuCWNoYXIgKmdldGVudihjaGFyKik7 CmV4dGVybgljaGFyICpnZXRsb2dpbih2b2lkKTsKZXh0ZXJuCWNoYXIgKnN0cmVycm9yKGludCk7 CmV4dGVybgl2b2lkICptZW1tb3ZlKHZvaWQqLCBjb25zdCB2b2lkKiwgc2l6ZV90KTsKI2RlZmlu ZQlORUVETUVNTU9WRQojZGVmaW5lCU5FRURTVFJFUlJPUgojZGVmaW5lCU5FRURWQVJBUkcKI2Vu ZGlmCS8qIFNZU1ZSMyAqLwoKI2lmZGVmCUlSSVg1CnR5cGVkZWYJdW5zaWduZWQgc2hvcnQJdXNo b3J0Owp0eXBlZGVmIHVuc2lnbmVkIGxvbmcJdWxvbmc7CiNlbmRpZgkvKiBJUklYNSAqLwoKI2lm ZGVmCUlSSVgKZXh0ZXJuCXZvaWQgKm1lbW1vdmUodm9pZCosIGNvbnN0IHZvaWQqLCBzaXplX3Qp OwojZGVmaW5lCU5FRURNRU1NT1ZFCiNlbmRpZgkvKiBJUklYICovCgojaWZkZWYJVU1JUFMKdHlw ZWRlZiB1bnNpZ25lZCBsb25nCXVsb25nOwp0eXBlZGVmCXVuc2lnbmVkIHNob3J0CXVzaG9ydDsK I2RlZmluZQljb25zdAkJCS8qIG1pcHMgY29tcGlsZXIgZG9lc24ndCBzdXBwb3J0IGNvbnN0ICov CmV4dGVybgljaGFyICpzdHJlcnJvcihpbnQpOwpleHRlcm4Jdm9pZCAqbWVtbW92ZSh2b2lkKiwg Y29uc3Qgdm9pZCosIHNpemVfdCk7CiNkZWZpbmUJTkVFRE1FTU1PVkUKI2RlZmluZQlORUVEU1RS RVJST1IKI2RlZmluZQlORUVEVkFSQVJHCiNkZWZpbmUJTk9GSUZPCQkJLyogdHVybiBvZmYgZXhz dGFydCBpbiBzYW10ZXJtL3VuaXguYyAqLwojZW5kaWYJLyogVU1JUFMgKi8KCiNpZmRlZglTVU5P Uwp0eXBlZGVmCXVuc2lnbmVkIHNob3J0CXVzaG9ydDsKdHlwZWRlZiB1bnNpZ25lZCBsb25nCXVs b25nOwpleHRlcm4JY2hhciAqc3RyZXJyb3IoaW50KTsKZXh0ZXJuCXZvaWQgKm1lbW1vdmUodm9p ZCosIGNvbnN0IHZvaWQqLCBzaXplX3QpOwpleHRlcm4Jdm9pZCAqbWVtY3B5KHZvaWQqLCBjb25z dCB2b2lkKiwgc2l6ZV90KTsKI2RlZmluZQlORUVETUVNTU9WRQojZGVmaW5lCU5FRURTVFJFUlJP UgojZW5kaWYJLyogU1VOT1MgKi8KCiNpZmRlZglTT0xBUklTCnR5cGVkZWYJdW5zaWduZWQgc2hv cnQJdXNob3J0Owp0eXBlZGVmIHVuc2lnbmVkIGxvbmcJdWxvbmc7CiNlbmRpZgoKI2lmZGVmCUFJ WAp0eXBlZGVmCXVuc2lnbmVkIHNob3J0CXVzaG9ydDsKdHlwZWRlZiB1bnNpZ25lZCBsb25nCXVs b25nOwojZW5kaWYJLyogQUlYICovCgojaWZkZWYJT1NGMQp0eXBlZGVmCXVuc2lnbmVkIHNob3J0 CXVzaG9ydDsKdHlwZWRlZiB1bnNpZ25lZCBsb25nCXVsb25nOwpleHRlcm4Jdm9pZCAqbWVtbW92 ZSh2b2lkKiwgY29uc3Qgdm9pZCosIHNpemVfdCk7CiNlbmRpZgkvKiBPU0YxICovCgojaWZkZWYg IEhQVVgKdHlwZWRlZgl1bnNpZ25lZCBzaG9ydAl1c2hvcnQ7CnR5cGVkZWYgdW5zaWduZWQgbG9u Zwl1bG9uZzsKI2RlZmluZQlORUVEU1RSRVJST1IKI2VuZGlmICAvKiBIUFVYICovCgojaWZkZWYg IEFQT0xMTwp0eXBlZGVmCXVuc2lnbmVkIHNob3J0CXVzaG9ydDsKdHlwZWRlZiB1bnNpZ25lZCBs b25nCXVsb25nOwojZW5kaWYgIC8qIEFQT0xMTyAqLwoKI2lmZGVmICBDT05WRVgKdHlwZWRlZiB1 bnNpZ25lZCBsb25nCXVsb25nOwojZW5kaWYgIC8qIENPTlZFWCAqLwoKI2lmZGVmICBEWU5JWAoj ZGVmaW5lCVNJR19FUlIJCUJBRFNJRwojZGVmaW5lCU5FRURNRU1NT1ZFCiNkZWZpbmUJcmVtb3Zl KHYpCQkJdW5saW5rKHYpCiNkZWZpbmUJV0VYSVRTVEFUVVMocykJCQkoKChzKT4+OCkmMHhGRikK I2RlZmluZQlORUVETUVNTU9WRQojZGVmaW5lCU5PRklGTwkJCS8qIHR1cm4gb2ZmIGV4c3RhcnQg aW4gc2FtdGVybS91bml4LmMgKi8KI2VuZGlmICAvKiBEWU5JWCAqLwoKI2lmZGVmCVBUWAp0eXBl ZGVmCXVuc2lnbmVkIHNob3J0CXVzaG9ydDsKdHlwZWRlZiB1bnNpZ25lZCBsb25nCXVsb25nOwoj ZW5kaWYJLyogUFRYICovCgojaWZkZWYJQlNEaQp0eXBlZGVmIHVuc2lnbmVkIGxvbmcgICB1bG9u ZzsKI2VuZGlmCS8qIEJTRGkgKi8KCiNpZmRlZgl2MTAKdHlwZWRlZgl1bnNpZ25lZCBzaG9ydAl1 c2hvcnQ7CnR5cGVkZWYgdW5zaWduZWQgbG9uZwl1bG9uZzsKI2VuZGlmCgojZW5kaWYKAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvaW5jbHVkZS9w bHVtYi5oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAw MDAwNDY3ADA3MTExNjQ2NTI3ADAwMTU3MTMAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2Nz ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaWZuZGVmIFNBTV9QTFVN Ql9ICiNkZWZpbmUgU0FNX1BMVU1CX0gKCnR5cGVkZWYgc3RydWN0IFBsdW1ibXNnIFBsdW1ibXNn OwoKc3RydWN0IFBsdW1ibXNnIHsKCWNoYXIgKnNyYzsKCWNoYXIgKmRzdDsKCWNoYXIgKndkaXI7 CgljaGFyICp0eXBlOwoJY2hhciAqYXR0cjsKCWNoYXIgKmRhdGE7CglpbnQgbmRhdGE7Cn07Cgpj aGFyICpwbHVtYnVucGFja2F0dHIoY2hhciopOwpjaGFyICpwbHVtYnBhY2soUGx1bWJtc2cgKiwg aW50ICopOwppbnQgcGx1bWJmcmVlKFBsdW1ibXNnICopOwpjaGFyICpjbGVhbm5hbWUoY2hhciop OwoKI2VuZGlmCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNhbTJrL2luY2x1ZGUvcHJp bnQuaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNDQ0ADAwMDE3MzcAMDAwMDE1MQAwMDAwMDAw NTE3MgAwNzExMTQyNzQzNgAwMDE1NzIwADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdjc2UA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyogZnJvbSByYyAxLjQgLSBj b2RlIGJ5IEJ5cm9uIGFuZCBQYXVsIGFuZCBTY290dCAqLwojaWZuZGVmIF9fbmljZXJfcHJpbnRf aAojZGVmaW5lIF9fbmljZXJfcHJpbnRfaAoKI2luY2x1ZGUgPHN0ZGFyZy5oPgoKI2lmbmRlZiBT SVpFX1QKdHlwZWRlZiB1bnNpZ25lZCBsb25nIGludCBTSVpFX1Q7CiNlbmRpZgoKZW51bSB7CiAg LyogcmV0dXJuIHZhbHVlcyBvZiBjb252ZXJzaW9uIGZ1bmN0aW9ucyAqLwogIEZNVF9mbGFnID0g MCwJCQkvKiB1aGwjLS5bMC05XSAqLwogIEZNVF92ZXJiID0gMSwJCQkvKiBzY2RveHIgKi8KICBG TVRfZXJyb3IgPSAyLCAgCQkvKiBlcnJvciBkdXJpbmcgZm9ybWF0dGluZyAqLwoKICAvKiBzaXpl cyBvZiB2YXJpb3VzIHRoaW5ncyAqLwogIEZNVF9NQVhDT05WID0gMjU2LAkgIAkvKiBudW1iZXIg b2YgY29udmVyc2lvbiBjaGFyYWN0ZXJzICovCiAgRk1UX1BSSU5UX0FMTE9DU0laRSA9IDY0LAkv KiBncm93IGJ5IHRoaXMgbWFueSBieXRlcyB3aGVuIG5lY2Vzc2FyeSAqLwogIEZNVF9TUFJJTlRf QlVGU0laID0gMTAyNAkvKiBieXRlcyAqLwp9OwoKdHlwZWRlZiBjaGFyKiAoKkFsbG9jKShjaGFy ICosIFNJWkVfVCk7Cgp0eXBlZGVmIHN0cnVjdCBGb3JtYXQgRm9ybWF0Owp0eXBlZGVmIGludCAo KkZtdGNvbnYpKEZvcm1hdCAqLCBpbnQpOwoKc3RydWN0IEZvcm1hdCB7CgkvKiBmb3IgdGhlIGZv cm1hdHRpbmcgcm91dGluZXMgKi8KCXZhX2xpc3QgYXJnczsKCWxvbmcgZmxhZ3MsIGYxLCBmMjsK CUZtdGNvbnYqIGZtdHRhYjsKCS8qIGZvciB0aGUgYnVmZmVyIG1haW50YWluZW5jZSByb3V0aW5l cyAqLwoJY2hhciAqYnVmLCAqYnVmYmVnaW4sICpidWZlbmQ7CglpbnQgZmx1c2hlZDsKCWludCAo Kmdyb3cpKEZvcm1hdCAqLCBTSVpFX1QpOwoJaW50IGVycm9yOwoJaW50IHJlcWxlbjsKCXVuaW9u IHsgaW50IG47IHZvaWQgKnA7IH0gdTsKCS8qIGZvciB0aGUgc2FrZSBvZiByZWVudHJhbmN5ICov Cgl2b2lkKiBjbGllbnRfZGF0YTsKfTsKCi8qIEZvcm1hdC0+ZmxhZ3MgdmFsdWVzICovCmVudW0g ewoJRk1UX2xvbmcJPSAoMTw8MCksCS8qICVsICovCglGTVRfc2hvcnQJPSAoMTw8MSksCS8qICVo ICovCglGTVRfdW5zaWduZWQJPSAoMTw8MiksCS8qICV1ICovCglGTVRfemVyb3BhZAk9ICgxPDwz KSwJLyogJTAgKi8KCUZNVF9sZWZ0c2lkZQk9ICgxPDw0KSwJLyogJS0gKi8KCUZNVF9hbHRmb3Jt CT0gKDE8PDUpLAkvKiAlIyAqLwoJRk1UX2Yxc2V0CT0gKDE8PDYpLAkvKiAlPG4+ICovCglGTVRf ZjJzZXQJPSAoMTw8NykJLyogJS48bj4gKi8KfTsKCmV4dGVybiBpbnQgZm10cHV0YyhGb3JtYXQg KmYsIGNvbnN0IGNoYXIgYyk7CmV4dGVybiBpbnQgZm10YXBwZW5kKEZvcm1hdCAqZm9ybWF0LCBj b25zdCBjaGFyICpzLCBTSVpFX1QgbGVuKTsKZXh0ZXJuIGludCBmbXRjYXQoRm9ybWF0ICpmb3Jt YXQsIGNvbnN0IGNoYXIgKnMpOwpleHRlcm4gRm10Y29udiBmbXRpbnN0YWxsKGludCBjLCBGbXRj b252IGYpOwpleHRlcm4gaW50IGZtdGVuZ2luZShGb3JtYXQgKmZvcm1hdCwgY29uc3QgY2hhciAq Zm10KTsKZXh0ZXJuIGludCBmbXRwcmludChGb3JtYXQgKmZvcm1hdCwgY29uc3QgY2hhciAqZm10 LC4uLik7CmV4dGVybiBpbnQgZm10X2ZwcmludF9mbHVzaCAoRm9ybWF0ICpmb3JtYXQsIFNJWkVf VCBtb3JlKTsKZXh0ZXJuIGludCB2ZnByaW50KGludCBmZCwgY29uc3QgY2hhciAqZm10LCB2YV9s aXN0IGFwKTsKZXh0ZXJuIGludCBmcHJpbnQoaW50IGZkLCBjb25zdCBjaGFyICpmbXQsLi4uKTsK ZXh0ZXJuIGludCBwcmludChjb25zdCBjaGFyICpmbXQsLi4uKTsKZXh0ZXJuIGludCBlcHJpbnQo Y29uc3QgY2hhciAqZm10LC4uLik7CmV4dGVybiBjaGFyICpmbXRfbWVtcHJpbnQgKEZvcm1hdCAq Zm9ybWF0LCBjb25zdCBjaGFyICpmbXQsIFNJWkVfVCogbGVuKTsKZXh0ZXJuIGludCBmbXRfbWVt cHJpbnRfZ3JvdyAoRm9ybWF0ICpmb3JtYXQsIFNJWkVfVCBtb3JlKTsKZXh0ZXJuIGNoYXIgKnZz bXByaW50IChBbGxvYyBhLCBTSVpFX1QqIGxlbiwgY29uc3QgY2hhciogZm10LCB2YV9saXN0IGFw KTsKZXh0ZXJuIGNoYXIgKnNtcHJpbnQgKEFsbG9jIGFsbG9jLCBTSVpFX1QqIGxlbiwgY29uc3Qg Y2hhciogZm10LCAuLi4pOwpleHRlcm4gaW50IGZtdF9zbnByaW50X2dyb3cgKEZvcm1hdCAqZm9y bWF0LCBTSVpFX1QgbW9yZSk7CmV4dGVybiBjaGFyKiBwYWxsb2MgKGNoYXIqIHAsIFNJWkVfVCBz aXplKTsKZXh0ZXJuIGNoYXIgKm1wcmludChjb25zdCBjaGFyICpmbXQsLi4uKTsKZXh0ZXJuIGlu dCB2c25wcmludChjaGFyICpidWYsIGludCBidWZsZW4sIGNvbnN0IGNoYXIgKmZtdCwgdmFfbGlz dCBhcCk7CmV4dGVybiBpbnQgc25wcmludChjaGFyICpidWYsIGludCBidWZsZW4sIGNvbnN0IGNo YXIgKmZtdCwuLi4pOwpleHRlcm4gaW50IHNwcmludChjaGFyICpidWYsIGNvbnN0IGNoYXIgKmZt dCwuLi4pOwoKZXh0ZXJuIGludCBwcmludF9pbmFkZHJfY29udiAoRm9ybWF0KiwgaW50KTsKZXh0 ZXJuIGludCBwcmludF9jcXVvdGVfY29udiAoRm9ybWF0KiwgaW50KTsKZXh0ZXJuIGludCBwcmlu dF9yY3F1b3RlX2NvbnYgKEZvcm1hdCosIGludCk7CgpleHRlcm4gdm9pZCBmbXRfaW5zdGFsbF9y dW5lY29udiAoKTsKCiNlbmRpZiAvKiBfX25pY2VyX3ByaW50X2ggKi8KAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvaW5jbHVkZS91bml4LmgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDAxMTIzADA3 MTEyMDMwNDYzADAwMTU1MzAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaWZuZGVmIFNBTV9VTklYX0gKI2RlZmlu ZSBTQU1fVU5JWF9ICgojaWZuZGVmIFJTQU1OQU1FCiNkZWZpbmUgUlNBTU5BTUUgInNhbSIKI2Vu ZGlmCiNpZm5kZWYgVEVSTU5BTUUKI2RlZmluZSBURVJNTkFNRSAiL3Vzci9sb2NhbC9iaW4vc2Ft dGVybSIKI2VuZGlmCiNpZm5kZWYgSE9NRURJUgojZGVmaW5lIEhPTUVESVIgICJIT01FIgojZW5k aWYKI2lmbmRlZiBUTVAKI2RlZmluZSBUTVAgICAgICAiL3RtcCIKI2VuZGlmCiNpZm5kZWYgU0hF TExOQU1FCiNkZWZpbmUgU0hFTExOQU1FICJzaCIKI2VuZGlmCiNpZm5kZWYgU0hFTExQQVRICiNk ZWZpbmUgU0hFTExQQVRIICIvYmluL3NoIgojZW5kaWYKI2lmbmRlZiBSWE5BTUUKI2RlZmluZSBS WE5BTUUgInNzaCIKI2VuZGlmCiNpZm5kZWYgUlhQQVRITkFNRQojZGVmaW5lIFJYUEFUSE5BTUUg Ii91c3IvbG9jYWwvYmluL3NzaCIKI2VuZGlmCiNpZm5kZWYgU0FNU0FWRURJUgojZGVmaW5lIFNB TVNBVkVESVIgIi91c3IvbG9jYWwvYmluIgojZW5kaWYKI2lmbmRlZiBTQU1TQVZFCiNkZWZpbmUg U0FNU0FWRSAiL2Jpbi9zaFxuIiBTQU1TQVZFRElSICIvc2Ftc2F2ZSIKI2VuZGlmCgojZW5kaWYK AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvbGliLwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADAwNDA3NTUAMDAwMTczNwAwMDAwMTUxADAwMDAwMDAwMDAwADA3MTEy MTE3NzI2ADAwMTM1MzUANQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzYW0yay9saWIvcnVuZS5jAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAxNzM3ADAwMDAxNTEAMDAwMDAwMDUyNzYAMDcxMTE2 MzcyNDcAMDAxNDY2NQAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHVzdGFyADAwc2Nod2FydHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnY3NlAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADAwMDAwNDAAMDAwMDAyNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8qIENvcHlyaWdodCAoYykgMTk5MiBBVCZUIC0g QWxsIHJpZ2h0cyByZXNlcnZlZC4gKi8KI2luY2x1ZGUJPHUuaD4KI2luY2x1ZGUJPGxpYmMuaD4K CmVudW0KewoJQml0MQk9IDcsCglCaXR4CT0gNiwKCUJpdDIJPSA1LAoJQml0Mwk9IDQsCglCaXQ0 CT0gMywKCglUMQk9ICgoMTw8KEJpdDErMSkpLTEpIF4gMHhGRiwJLyogMDAwMCAwMDAwICovCglU eAk9ICgoMTw8KEJpdHgrMSkpLTEpIF4gMHhGRiwJLyogMTAwMCAwMDAwICovCglUMgk9ICgoMTw8 KEJpdDIrMSkpLTEpIF4gMHhGRiwJLyogMTEwMCAwMDAwICovCglUMwk9ICgoMTw8KEJpdDMrMSkp LTEpIF4gMHhGRiwJLyogMTExMCAwMDAwICovCglUNAk9ICgoMTw8KEJpdDQrMSkpLTEpIF4gMHhG RiwJLyogMTExMSAwMDAwICovCgoJUnVuZTEJPSAoMTw8KEJpdDErMCpCaXR4KSktMSwJCS8qIDAw MDAgMDAwMCAwMTExIDExMTEgKi8KCVJ1bmUyCT0gKDE8PChCaXQyKzEqQml0eCkpLTEsCQkvKiAw MDAwIDAxMTEgMTExMSAxMTExICovCglSdW5lMwk9ICgxPDwoQml0MysyKkJpdHgpKS0xLAkJLyog MTExMSAxMTExIDExMTEgMTExMSAqLwoKCU1hc2t4CT0gKDE8PEJpdHgpLTEsCQkJLyogMDAxMSAx MTExICovCglUZXN0eAk9IE1hc2t4IF4gMHhGRiwJCQkvKiAxMTAwIDAwMDAgKi8KCglCYWQJPSBS dW5lZXJyb3IKfTsKCmludApjaGFydG9ydW5lKFJ1bmUgKnJ1bmUsIGNoYXIgKnN0cikKewoJaW50 IGMsIGMxLCBjMjsKCWxvbmcgbDsKCgkvKgoJICogb25lIGNoYXJhY3RlciBzZXF1ZW5jZQoJICoJ MDAwMDAtMDAwN0YgPT4gVDEKCSAqLwoJYyA9ICoodWNoYXIqKXN0cjsKCWlmKGMgPCBUeCkgewoJ CSpydW5lID0gYzsKCQlyZXR1cm4gMTsKCX0KCgkvKgoJICogdHdvIGNoYXJhY3RlciBzZXF1ZW5j ZQoJICoJMDA4MC0wN0ZGID0+IFQyIFR4CgkgKi8KCWMxID0gKih1Y2hhciopKHN0cisxKSBeIFR4 OwoJaWYoYzEgJiBUZXN0eCkKCQlnb3RvIGJhZDsKCWlmKGMgPCBUMykgewoJCWlmKGMgPCBUMikK CQkJZ290byBiYWQ7CgkJbCA9ICgoYyA8PCBCaXR4KSB8IGMxKSAmIFJ1bmUyOwoJCWlmKGwgPD0g UnVuZTEpCgkJCWdvdG8gYmFkOwoJCSpydW5lID0gbDsKCQlyZXR1cm4gMjsKCX0KCgkvKgoJICog dGhyZWUgY2hhcmFjdGVyIHNlcXVlbmNlCgkgKgkwODAwLUZGRkYgPT4gVDMgVHggVHgKCSAqLwoJ YzIgPSAqKHVjaGFyKikoc3RyKzIpIF4gVHg7CglpZihjMiAmIFRlc3R4KQoJCWdvdG8gYmFkOwoJ aWYoYyA8IFQ0KSB7CgkJbCA9ICgoKChjIDw8IEJpdHgpIHwgYzEpIDw8IEJpdHgpIHwgYzIpICYg UnVuZTM7CgkJaWYobCA8PSBSdW5lMikKCQkJZ290byBiYWQ7CgkJKnJ1bmUgPSBsOwoJCXJldHVy biAzOwoJfQoKCS8qCgkgKiBiYWQgZGVjb2RpbmcKCSAqLwpiYWQ6CgkqcnVuZSA9IEJhZDsKCXJl dHVybiAxOwp9CgppbnQKcnVuZXRvY2hhcihjaGFyICpzdHIsIFJ1bmUgKnJ1bmUpCnsKCWxvbmcg YzsKCgkvKgoJICogb25lIGNoYXJhY3RlciBzZXF1ZW5jZQoJICoJMDAwMDAtMDAwN0YgPT4gMDAt N0YKCSAqLwoJYyA9ICpydW5lOwoJaWYoYyA8PSBSdW5lMSkgewoJCXN0clswXSA9IGM7CgkJcmV0 dXJuIDE7Cgl9CgoJLyoKCSAqIHR3byBjaGFyYWN0ZXIgc2VxdWVuY2UKCSAqCTAwODAtMDdGRiA9 PiBUMiBUeAoJICovCglpZihjIDw9IFJ1bmUyKSB7CgkJc3RyWzBdID0gVDIgfCAoYyA+PiAxKkJp dHgpOwoJCXN0clsxXSA9IFR4IHwgKGMgJiBNYXNreCk7CgkJcmV0dXJuIDI7Cgl9CgoJLyoKCSAq IHRocmVlIGNoYXJhY3RlciBzZXF1ZW5jZQoJICoJMDgwMC1GRkZGID0+IFQzIFR4IFR4CgkgKi8K CXN0clswXSA9IFQzIHwgIChjID4+IDIqQml0eCk7CglzdHJbMV0gPSBUeCB8ICgoYyA+PiAxKkJp dHgpICYgTWFza3gpOwoJc3RyWzJdID0gVHggfCAgKGMgJiBNYXNreCk7CglyZXR1cm4gMzsKfQoK aW50CnJ1bmVsZW4obG9uZyBjKQp7CglSdW5lIHJ1bmU7CgljaGFyIHN0clsxMF07CgoJcnVuZSA9 IGM7CglyZXR1cm4gcnVuZXRvY2hhcihzdHIsICZydW5lKTsKfQoKaW50CmZ1bGxydW5lKGNoYXIg KnN0ciwgaW50IG4pCnsKCWludCBjOwoKCWlmKG4gPiAwKSB7CgkJYyA9ICoodWNoYXIqKXN0cjsK CQlpZihjIDwgVHgpCgkJCXJldHVybiAxOwoJCWlmKG4gPiAxKQoJCQlpZihjIDwgVDMgfHwgbiA+ IDIpCgkJCQlyZXR1cm4gMTsKCX0KCXJldHVybiAwOwp9CgpjaGFyKgp1dGZydW5lKGNoYXIgKnMs IGxvbmcgYykKewoJbG9uZyBjMTsKCVJ1bmUgcjsKCWludCBuOwoKCWlmKGMgPCBSdW5lc3luYykJ CS8qIG5vdCBwYXJ0IG9mIHV0ZiBzZXF1ZW5jZSAqLwoJCXJldHVybiBzdHJjaHIocywgYyk7CgoJ Zm9yKDs7KSB7CgkJYzEgPSAqKHVjaGFyKilzOwoJCWlmKGMxIDwgUnVuZXNlbGYpIHsJLyogb25l IGJ5dGUgcnVuZSAqLwoJCQlpZihjMSA9PSAwKQoJCQkJcmV0dXJuIDA7CgkJCWlmKGMxID09IGMp CgkJCQlyZXR1cm4gczsKCQkJcysrOwoJCQljb250aW51ZTsKCQl9CgkJbiA9IGNoYXJ0b3J1bmUo JnIsIHMpOwoJCWlmKHIgPT0gYykKCQkJcmV0dXJuIHM7CgkJcyArPSBuOwoJfQoJcmV0dXJuIDA7 Cn0KCmxvbmcKdXRmbGVuKGNoYXIgKnMpCnsKCWludCBjOwoJbG9uZyBuOwoJUnVuZSBydW5lOwoK CW4gPSAwOwoJZm9yKDs7KSB7CgkJYyA9ICoodWNoYXIqKXM7CgkJaWYoYyA8IFJ1bmVzZWxmKSB7 CgkJCWlmKGMgPT0gMCkKCQkJCXJldHVybiBuOwoJCQlzKys7CgkJfSBlbHNlCgkJCXMgKz0gY2hh cnRvcnVuZSgmcnVuZSwgcyk7CgkJbisrOwoJfQoJcmV0dXJuIDA7Cn0KAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNhbTJrL2xpYi9NYWtlZmlsZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAwMTAwNjQ0ADAwMDE3MzcAMDAwMDE1MQAwMDAwMDAwMDM0MwAwNzExMjExNjQzNwAw MDE1MTcwADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIA MDBzY2h3YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAU1JDPXJ1bmUuYyBtaXNjLmMgcGx1bWIuYyBwcmludC5jIHJ1 bmVjb252LmMKT0JKPXJ1bmUubyBtaXNjLm8gcGx1bWIubyBwcmludC5vIHJ1bmVjb252Lm8KCkNG TEFHUz0tSS4gLUkuLi9pbmNsdWRlCkNDPWdjYyAtV2FsbCAtTzMJIyBHY2MKI0NDPWNjIC14Q0Mg LXYgLWZhc3QJIyBTb2xhcmlzCgoKbGliOiAkKE9CSikKCWFyIGNydiBsaWIuYSAkKE9CSikKCmNs ZWFuOgoJcm0gLWYgKi5vICouYQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABzYW0yay9saWIvcnVuZWNvbnYuYwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAMDEwMDY0NAAwMDAxNzM3ADAwMDAxNTEAMDAwMDAwMDM1MjYAMDcxMTIxMTY2NzQAMDAx NTU0NAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAw c2Nod2FydHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnY3NlAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAADAwMDAwNDAAMDAwMDAyNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHN0YXRpYyBjb25zdCBjaGFyIHJjc2lkW10gPSAKIkAoIykkSWQ6 IHJ1bmVjb252LmMsdiAxLjQgMTk5NS8wNy8wNCAxODoyNDo1MiBzY2h3YXJ0eiBFeHAgJCI7Cgov KiBDb250cmlidXRlZCBieSBFcmlrIFF1YW5zdHJvbSA8cXVhbnN0cm9Ac2FydHJlLm1pbmVydmEu YmFoLmNvbT4gKi8KCiNpbmNsdWRlICJwcmludC5oIgoKI2luY2x1ZGUgInUuaCIKI2luY2x1ZGUg ImxpYmMuaCIKCnN0YXRpYyB2b2lkIHBhZCAoRm9ybWF0ICpmb3JtYXQsIFNJWkVfVCBsZW4sIGlu dCBjKSB7CiAgICBkbzsgd2hpbGUgKGxlbi0tICE9IDAgJiYgZm10cHV0YyAoZm9ybWF0LCBjKSk7 Cn0KCnN0YXRpYyBTSVpFX1QgUnVuZWxlbiAoY29uc3QgUnVuZSAqcikgewoJY29uc3QgUnVuZSAq cyA9IHI7Cgl3aGlsZSAoKnIpIHIrKzsKCXJldHVybiByLXM7Cn0KCi8qIGRlbGV0ZSB0aGlzIHdo ZW4geW91IGdldCBhIGRlY2VudCBjb21waWxlciAqLwpzdGF0aWMgUnVuZSBzdHVwaWRbXSA9IHsg OTIzLCAwfTsKCnN0YXRpYyBpbnQgU2NvbnYgKEZvcm1hdCAqZm9ybWF0LCBpbnQgYykgewogICAg U0laRV9UIG1heHJ1bmVzLCBtaW53aWR0aCwgZXh0cmE7CiAgICBSdW5lICpSID0gdmFfYXJnIChm b3JtYXQtPmFyZ3MsIFJ1bmUqKTsKICAgIGNoYXIgc1tVVEZtYXhdOyAKICAgIGludCBpOwoKLyog ICAgaWYgKCFSKSBSID0gTCLOmyI7ICBzb21lIGNvbXBpbGVycyBjaG9rZSBvbiB0aGlzKi8KICAg IGlmICghUikgUiA9IHN0dXBpZDsKCiAgICBpZiAoZm9ybWF0LT5mbGFncyAmIEZNVF9hbHRmb3Jt KSB7CgltYXhydW5lcyA9IChmb3JtYXQtPmZsYWdzICYgRk1UX2Yyc2V0KSA/IGZvcm1hdC0+ZjIg OiBSdW5lbGVuIChSKTsKCS8qIG1heHJ1bmVzIG1heSBvdmVycnVuIFIsICBidXQgdGhpcyB3YXkg d2UgZG9uJ3QgaGF2ZSAKCSAgIHRvIGFzc3VtZSB0aGF0IFIgaXMgbnVsbCB0ZXJtaW5hdGVkIHdo ZW4gZjIgaXMgc2V0LiAqLwogICAgfSBlbHNlIHsKCS8qIGRvIGYyIGxpa2UgcHJpbnRmICovCglt YXhydW5lcyA9IFJ1bmVsZW4gKFIpOwoJaWYgKChmb3JtYXQtPmZsYWdzICYgRk1UX2Yyc2V0KSAm JiAoZm9ybWF0LT5mMiA8IG1heHJ1bmVzKSkKCSAgICBtYXhydW5lcyA9IGZvcm1hdC0+ZjI7CiAg ICB9CgogICAgbWlud2lkdGggPSAoZm9ybWF0LT5mbGFncyAmIEZNVF9mMXNldCkgPyBmb3JtYXQt PmYxIDogbWF4cnVuZXM7CiAgICBleHRyYSA9IChtaW53aWR0aCA+IG1heHJ1bmVzKSA/IG1pbndp ZHRoIC0gbWF4cnVuZXMgOiAwOwoKICAgIGlmIChmb3JtYXQtPmZsYWdzICYgRk1UX2xlZnRzaWRl KSB7Cgl3aGlsZSAobWF4cnVuZXMtLSkgewogICAgCQlpID0gcnVuZXRvY2hhciAocywgUisrKTsK ICAgIAkJZm10YXBwZW5kIChmb3JtYXQsIHMsIGkpOwoJfQoJcGFkIChmb3JtYXQsIGV4dHJhLCAn ICcpOwogICAgfSBlbHNlIHsKCXBhZCAoZm9ybWF0LCBleHRyYSwgJyAnKTsKCXdoaWxlIChtYXhy dW5lcy0tKSB7CiAgICAJCWkgPSBydW5ldG9jaGFyIChzLCBSKyspOwogICAgCQlmbXRhcHBlbmQg KGZvcm1hdCwgcywgaSk7Cgl9CiAgICB9CgkKICAgIHJldHVybiBGTVRfdmVyYjsKfQoKc3RhdGlj IGludCBDY29udiAoRm9ybWF0ICpmb3JtYXQsIGludCBjKSB7CiAgICBSdW5lIHIgPSAodW5zaWdu ZWQgc2hvcnQpIHZhX2FyZyAoZm9ybWF0LT5hcmdzLCBpbnQpOwogICAgY2hhciBzW1VURm1heF07 CiAgICBpbnQgaTsKCiAgICBpID0gcnVuZXRvY2hhciAocywgJnIpOwogICAgZm10YXBwZW5kIChm b3JtYXQsIHMsIGkpOwogICAgcmV0dXJuIEZNVF92ZXJiOwp9Cgp2b2lkIGZtdF9pbnN0YWxsX3J1 bmVjb252ICgpCnsKICAgIGZtdGluc3RhbGwgKCdDJywgQ2NvbnYpOwogICAgZm10aW5zdGFsbCAo J1MnLCBTY29udik7Cn0KCiBtYXhydW5lcyBtYXkgb3ZlcnJ1biBSLCAgYnV0IHRoaXMgd2F5IHdl IGRvbid0IGhhdmUgCgkgICB0byBhc3N1bWUgdGhhdCBSIGlzIG51bGwgdGVybWluYXRlZCB3aGVu IGYyIGlzIHNldC4gKi8KICAgIH0gZWxzZSB7CgkvKiBkbyBmMiBsaWtlIHByaW50ZiAqLwoJbWF4 cnVuZXMgPSBSdW5lbGVuc2FtMmsvbGliL21pc2MuYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDAzMzU3ADA3MTExNjUwNjM3ADAwMTQ2NDMA MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdh cnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAvKiBDb3B5cmlnaHQgKGMpIDE5OTIgQVQmVCAtIEFsbCByaWdodHMgcmVz ZXJ2ZWQuICovCi8qIENoYW5nZXMgMjAwMCwgU2NvdHQgU2Nod2FydHogKi8KCiNpbmNsdWRlCTx1 Lmg+CiNpbmNsdWRlCTxsaWJjLmg+Cgp2b2lkCmV4aXRzKGNoYXIgKm1lc3NhZ2UpCnsKCiAgICAg ICAgZXhpdChtZXNzYWdlICE9IDApOwp9ICAgICAgIAogICAgICAgIAp2b2lkCl9leGl0cyhjaGFy ICptZXNzYWdlKQp7ICAgICAgIAogICAgICAgIF9leGl0KG1lc3NhZ2UgIT0gMCk7Cn0KCmludCBl cnJzdHIoY2hhciAqYnVmKQp7CglleHRlcm4gaW50IGVycm5vOwoKCXN0cm5jcHkoYnVmLCBzdHJl cnJvcihlcnJubyksIEVSUkxFTik7CglyZXR1cm4gMTsKfQoKaW50IGNyZWF0ZShjaGFyICpuYW1l LCBpbnQgb21vZGUsIGludCBwZXJtKQp7CiAgICAgICAgaW50IG1vZGU7IAogICAgICAgIGludCBm ZDsKCiAgICAgICAgaWYgKG9tb2RlICYgT1dSSVRFKSBtb2RlID0gT19XUk9OTFk7CiAgICAgICAg ZWxzZSBpZiAob21vZGUgJiBPUkVBRCkgbW9kZSA9IE9fUkRPTkxZOwogICAgICAgIGVsc2UgbW9k ZSA9IE9fUkRXUjsKCiAgICAgICAgaWYgKChmZCA9IG9wZW4obmFtZSwgbW9kZXxPX0NSRUFUfE9f VFJVTkMsIHBlcm0pKSA8IDApCiAgICAgICAgICAgICAgICByZXR1cm4gZmQ7CgogICAgICAgIGlm IChvbW9kZSAmIE9DRVhFQykKICAgICAgICAgICAgICAgIGZjbnRsKGZkLCBGX1NFVEZELCBmY250 bChmZCxGX0dFVEZELDApIHwgRkRfQ0xPRVhFQyk7CiAgICAgICAgCiAgICAgICAgLyogWFhYIC0g bm90IGV4YWN0bHkgcmlnaHQsIGJ1dCBob3BlZnVsbHkgZ29vZCBlbm91Z2guICovCiAgICAgICAg aWYgKG9tb2RlICYgT1JDTE9TRSkKICAgICAgICAgICAgICAgIHJlbW92ZShuYW1lKTsKCiAgICAg ICAgcmV0dXJuIGZkOwp9CgpjaGFyKgpnZXR1c2VyKHZvaWQpCnsKCXN0cnVjdCBwYXNzd2QgKnA7 CgoJc3RhdGljIGNoYXIgKnVzZXIgPSAwOwoKCWlmICghdXNlcikgewoJCXAgPSBnZXRwd3VpZChn ZXR1aWQoKSk7CgkJaWYgKHAgJiYgcC0+cHdfbmFtZSkgewoJCQl1c2VyID0gbWFsbG9jKHN0cmxl bihwLT5wd19uYW1lKSsxKTsKCQkJaWYgKHVzZXIpCgkJCQlzdHJjcHkodXNlciwgcC0+cHdfbmFt ZSk7CgkJfQoJfQoJaWYoIXVzZXIpCgkJdXNlciA9ICJ1bmtub3duIjsKCXJldHVybiB1c2VyOwp9 CgojaWZkZWYgTkVFRFNUUkVSUk9SCmNoYXIgKgpzdHJlcnJvcihpbnQgbikKewoJZXh0ZXJuIGNo YXIgKnN5c19lcnJsaXN0W107CglyZXR1cm4gc3lzX2Vycmxpc3Rbbl07Cn0KI2VuZGlmIC8qIE5F RURTVFJFUlJPUiAqLwoKI2lmZGVmIE5FRURNRU1NT1ZFCi8qCiAqIG1lbWNweSBpcyBwcm9iYWJs eSBmYXN0LCBidXQgbWF5IG5vdCB3b3JrIHdpdGggb3ZlcmxhcAogKi8Kdm9pZCoKbWVtbW92ZSh2 b2lkICphMSwgY29uc3Qgdm9pZCAqYTIsIHNpemVfdCBuKQp7CgljaGFyICpzMTsKCWNvbnN0IGNo YXIgKnMyOwoKCXMxID0gYTE7CglzMiA9IGEyOwoJaWYoczEgPiBzMikKCQlnb3RvIGJhY2s7Cglp ZihzMSArIG4gPD0gczIpCgkJcmV0dXJuIG1lbWNweShhMSwgYTIsIG4pOwoJd2hpbGUobiA+IDAp IHsKCQkqczErKyA9ICpzMisrOwoJCW4tLTsKCX0KCXJldHVybiBhMTsKCmJhY2s6CglzMiArPSBu OwoJaWYoczIgPD0gczEpCgkJcmV0dXJuIG1lbWNweShhMSwgYTIsIG4pOwoJczEgKz0gbjsKCXdo aWxlKG4gPiAwKSB7CgkJKi0tczEgPSAqLS1zMjsKCQluLS07Cgl9CglyZXR1cm4gYTE7Cn0KI2Vu ZGlmIC8qIE5FRURNRU1NT1ZFICovCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHNhbTJrL2xpYi9wcmludC5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAw NDQ0ADAwMDE3MzcAMDAwMDE1MQAwMDAwMDAzMTM2NgAwNzExMTQyNzQyNwAwMDE1MDQyADAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAw MDA0MAAwMDAwMDI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAALyogcHJpbnQuYyAtLSBmb3JtYXR0ZWQgcHJpbnRpbmcgcm91dGluZXMgKi8KLyog dGhpcyBieSBTY290dCBTY2h3YXJ0eiwgZGVyaXZlZCBmcm9tIFBhdWwgSGFhaHIncyB2ZXJzaW9u IG9mIDEyLzkxICovCgpzdGF0aWMgY29uc3QgY2hhciByY3NpZFtdID0gCiJAKCMpJElkOiBwcmlu dC5jLHYgMS4zNyAxOTk2LzAxLzE5IDA4OjI3OjE2IHNjaHdhcnR6IEV4cCAkIjsKCiNpbmNsdWRl IDx1bmlzdGQuaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8c3RkYXJnLmg+Ci8qI2lu Y2x1ZGUgIi90bXAvZml4LWFyZ3MuaCIqLwojaW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDxl cnJuby5oPgojaW5jbHVkZSAicHJpbnQuaCIKCiNpZmRlZiBfX0dOVUNfXwpleHRlcm4gdm9pZCAq IG1lbWNweSAodm9pZCAqLCBjb25zdCB2b2lkICosIGxvbmcgdW5zaWduZWQgaW50KTsKI2VuZGlm CgovKgogKiBmdW5jdGlvbnMgZm9yIGluc2VydGluZyBzdHJpbmdzIGluIHRoZSBmb3JtYXQgYnVm ZmVyCiAqLwoKI2lmICFkZWZpbmVkIF9fR05VQ19fIHx8IGRlZmluZWQgX19TVFJJQ1RfQU5TSV9f CiNkZWZpbmUgaW5saW5lIC8qICovCiNlbmRpZgoKZXh0ZXJuIGludCBmbXRhcHBlbmQgKEZvcm1h dCAqZm9ybWF0LCBjb25zdCBjaGFyICpzLCBTSVpFX1QgbGVuKSB7CiAgICBmb3JtYXQtPnJlcWxl biArPSBsZW47CiAgICBpZiAoZm9ybWF0LT5lcnJvcikKCXJldHVybiAwOwogICAgd2hpbGUgKGxl biA+IGZvcm1hdC0+YnVmZW5kIC0gZm9ybWF0LT5idWYpIHsKCWNvbnN0IFNJWkVfVCBzcGxpdCA9 IGZvcm1hdC0+YnVmZW5kIC0gZm9ybWF0LT5idWY7CgltZW1jcHkgKGZvcm1hdC0+YnVmLCBzLCBz cGxpdCk7Cglmb3JtYXQtPmJ1ZiArPSBzcGxpdDsKCXMgKz0gc3BsaXQ7CglsZW4gLT0gc3BsaXQ7 CglpZiAoKCpmb3JtYXQtPmdyb3cpKGZvcm1hdCwgbGVuKSkKCSAgICByZXR1cm4gMDsKICAgIH0K ICAgIG1lbWNweSAoZm9ybWF0LT5idWYsIHMsIGxlbik7CiAgICBmb3JtYXQtPmJ1ZiArPSBsZW47 CiAgICByZXR1cm4gMTsKfQoKaW5saW5lIGludCBmbXRwdXRjIChGb3JtYXQgKmYsIGNvbnN0IGNo YXIgYykgewogICAgcmV0dXJuIGZtdGFwcGVuZCAoZiwgJmMsIDEpOwp9CgppbmxpbmUgaW50IGZt dGNhdCAoRm9ybWF0ICpmb3JtYXQsIGNvbnN0IGNoYXIgKnMpIHsKICAgIHJldHVybiBmbXRhcHBl bmQgKGZvcm1hdCwgcywgc3RybGVuIChzKSk7Cn0KCi8qCiAqIGNvbnZlcnNpb24gZnVuY3Rpb25z CiAqCXRydWUgcmV0dXJuIC0+IGZsYWcgY2hhbmdlcyBvbmx5LCBub3QgYSBjb252ZXJzaW9uCiAq LwoKI2RlZmluZSBGbGFnKG5hbWUsIGZsYWcpIFwKc3RhdGljIGludCBuYW1lIChGb3JtYXQgKmZv cm1hdCwgaW50IGMpIHsgXAoJZm9ybWF0LT5mbGFncyB8PSBmbGFnOyBcCglyZXR1cm4gRk1UX2Zs YWc7IFwKfQoKRmxhZyAodWNvbnYsCUZNVF91bnNpZ25lZCkKRmxhZyAoaGNvbnYsCUZNVF9zaG9y dCkKRmxhZyAobGNvbnYsCUZNVF9sb25nKQpGbGFnIChhbHRjb252LAlGTVRfYWx0Zm9ybSkKRmxh ZyAobGVmdGNvbnYsCUZNVF9sZWZ0c2lkZSkKRmxhZyAoZG90Y29udiwJRk1UX2Yyc2V0KQoKc3Rh dGljIGludCBkaWdpdGNvbnYgKEZvcm1hdCAqZm9ybWF0LCBpbnQgYykgewogICAgaWYgKGZvcm1h dC0+ZmxhZ3MgJiBGTVRfZjJzZXQpCglmb3JtYXQtPmYyID0gMTAgKiBmb3JtYXQtPmYyICsgYyAt ICcwJzsKICAgIGVsc2UgewoJZm9ybWF0LT5mbGFncyB8PSBGTVRfZjFzZXQ7Cglmb3JtYXQtPmYx ID0gMTAgKiBmb3JtYXQtPmYxICsgYyAtICcwJzsKICAgIH0KICAgIHJldHVybiBGTVRfZmxhZzsK fQoKc3RhdGljIGludCB6ZXJvY29udiAoRm9ybWF0ICpmb3JtYXQsIGludCBjKSB7CiAgICBpZiAo Zm9ybWF0LT5mbGFncyAmIChGTVRfZjFzZXQgfCBGTVRfZjJzZXQpKQoJcmV0dXJuIGRpZ2l0Y29u diAoZm9ybWF0LCAnMCcpOwogICAgZm9ybWF0LT5mbGFncyB8PSBGTVRfemVyb3BhZDsKICAgIHJl dHVybiBGTVRfZmxhZzsKfQoKc3RhdGljIGludCBzdGFyY29udiAoRm9ybWF0ICpmb3JtYXQsIGlu dCBjKSB7CiAgICBpbnQgbiA9IHZhX2FyZyAoZm9ybWF0LT5hcmdzLCBpbnQpOwogICAgaWYgKGZv cm1hdC0+ZmxhZ3MgJiBGTVRfZjJzZXQpCglmb3JtYXQtPmYyID0gbjsKICAgIGVsc2UgewoJZm9y bWF0LT5mbGFncyB8PSBGTVRfZjFzZXQ7Cglmb3JtYXQtPmYxID0gbjsKICAgIH0KICAgIHJldHVy biBGTVRfZmxhZzsKfQoKc3RhdGljIHZvaWQgcGFkIChGb3JtYXQgKmZvcm1hdCwgU0laRV9UIGxl biwgaW50IGMpIHsKICAgIGRvOyB3aGlsZSAobGVuLS0gIT0gMCAmJiBmbXRwdXRjIChmb3JtYXQs IGMpKTsKfQoKc3RhdGljIGludCBzY29udiAoRm9ybWF0ICpmb3JtYXQsIGludCBjKSB7CiAgICBT SVpFX1QgbWF4Ynl0ZXMsIG1pbndpZHRoLCBleHRyYTsKICAgIGNoYXIgKnMgPSB2YV9hcmcgKGZv cm1hdC0+YXJncywgY2hhciAqKTsKCiAgICBpZiAoIXMpIHMgPSAiKG51bGwpIjsKCiAgICBpZiAo Zm9ybWF0LT5mbGFncyAmIEZNVF9hbHRmb3JtKSB7CgltYXhieXRlcyA9IChmb3JtYXQtPmZsYWdz ICYgRk1UX2Yyc2V0KSA/IGZvcm1hdC0+ZjIgOiBzdHJsZW4gKHMpOwoJLyogbWF4Ynl0ZXMgbWF5 IG92ZXJydW4gcywgIGJ1dCB0aGlzIHdheSB3ZSBkb24ndCBoYXZlIAoJICAgdG8gYXNzdW1lIHRo YXQgcyBpcyBudWxsIHRlcm1pbmF0ZWQgd2hlbiBmMiBpcyBzZXQuIAoJICAgTWF5YmUgdXNlIGEg ZGlmZmVyZW50IGZvcm1hdCBjaGFyYWN0ZXIgZm9yIHRoaXM/ICovCiAgICB9IGVsc2UgewoJLyog ZG8gZjIgbGlrZSBwcmludGYgKi8KCW1heGJ5dGVzID0gc3RybGVuIChzKTsKCWlmICgoZm9ybWF0 LT5mbGFncyAmIEZNVF9mMnNldCkgJiYgKGZvcm1hdC0+ZjIgPCBtYXhieXRlcykpCgkgICAgbWF4 Ynl0ZXMgPSBmb3JtYXQtPmYyOwogICAgfQoKICAgIG1pbndpZHRoID0gKGZvcm1hdC0+ZmxhZ3Mg JiBGTVRfZjFzZXQpID8gZm9ybWF0LT5mMSA6IG1heGJ5dGVzOwogICAgZXh0cmEgPSAobWlud2lk dGggPiBtYXhieXRlcykgPyBtaW53aWR0aCAtIG1heGJ5dGVzIDogMDsKCiAgICBpZiAoZm9ybWF0 LT5mbGFncyAmIEZNVF9sZWZ0c2lkZSkgewoJZm10YXBwZW5kIChmb3JtYXQsIHMsIG1heGJ5dGVz KTsKCXBhZCAoZm9ybWF0LCBleHRyYSwgJyAnKTsKICAgIH0gZWxzZSB7CglwYWQgKGZvcm1hdCwg ZXh0cmEsICcgJyk7CglmbXRhcHBlbmQgKGZvcm1hdCwgcywgbWF4Ynl0ZXMpOwogICAgfQoJCiAg ICByZXR1cm4gRk1UX3ZlcmI7Cn0KCnN0YXRpYyBjaGFyICp1dG9hICh1bnNpZ25lZCBsb25nIHUs IAoJCSAgY2hhciAqdCwgdW5zaWduZWQgaW50IHJhZGl4LCBjb25zdCBjaGFyICpkaWdpdCkgewog ICAgaWYgKHUgPj0gcmFkaXgpIHsKCXQgPSB1dG9hICh1IC8gcmFkaXgsIHQsIHJhZGl4LCBkaWdp dCk7Cgl1ICU9IHJhZGl4OwogICAgfQogICAgKnQrKyA9IGRpZ2l0W3VdOwogICAgcmV0dXJuIHQ7 Cn0KCnN0YXRpYyB2b2lkIGludGNvbnYgKEZvcm1hdCAqZm9ybWF0LCAKCQkgICAgdW5zaWduZWQg aW50IHJhZGl4LCBpbnQgdXBwZXIsIGNvbnN0IGNoYXIgKmFsdGZvcm0pIHsKICAgIHN0YXRpYyBj b25zdCBjaGFyICogY29uc3QgdGFibGVbXSA9IHsKCSIwMTIzNDU2Nzg5YWJjZGVmZ2hpamtsbW5v cHFyc3R1dnd4eXoiLAoJIjAxMjM0NTY3ODlBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWiIsCiAg ICB9OwogICAgY2hhciBwYWRjaGFyOwogICAgU0laRV9UIGxlbiwgcHJlLCB6ZXJvZXMsIHBhZGRp bmcsIHdpZHRoOwogICAgbG9uZyBuLCBmbGFnczsKICAgIHVuc2lnbmVkIGxvbmcgdTsKICAgIGNo YXIgbnVtYmVyWzY0XSwgcHJlZml4WzIwXTsKCiAgICBpZiAocmFkaXggPiAzNikKCXJldHVybjsK CiAgICBmbGFncyA9IGZvcm1hdC0+ZmxhZ3M7CiAgICBpZiAoZmxhZ3MgJiBGTVRfdW5zaWduZWQp IHsKCWlmIChmbGFncyAmIEZNVF9sb25nKQoJICAgIG4gPSAodW5zaWduZWQgbG9uZykgdmFfYXJn IChmb3JtYXQtPmFyZ3MsIGxvbmcpOwoJZWxzZSBpZiAoZmxhZ3MgJiBGTVRfc2hvcnQpCgkgICAg biA9ICh1bnNpZ25lZCBsb25nKSh1bnNpZ25lZCBzaG9ydCkgdmFfYXJnIChmb3JtYXQtPmFyZ3Ms IGludCk7CgllbHNlCgkgICAgbiA9ICh1bnNpZ25lZCBsb25nKSh1bnNpZ25lZCBpbnQpIHZhX2Fy ZyAoZm9ybWF0LT5hcmdzLCBpbnQpOwogICAgfSBlbHNlIHsKCWlmIChmbGFncyAmIEZNVF9sb25n KQoJICAgIG4gPSAobG9uZykgdmFfYXJnIChmb3JtYXQtPmFyZ3MsIGxvbmcpOwoJZWxzZSBpZiAo ZmxhZ3MgJiBGTVRfc2hvcnQpCgkgICAgbiA9IChsb25nKShzaG9ydCkgdmFfYXJnIChmb3JtYXQt PmFyZ3MsIGludCk7CgllbHNlCgkgICAgbiA9IChsb25nKSB2YV9hcmcgKGZvcm1hdC0+YXJncywg aW50KTsKICAgIH0KCiAgICBwcmUgPSAwOwogICAgaWYgKChmbGFncyAmIEZNVF91bnNpZ25lZCkg fHwgbiA+PSAwKQoJdSA9IG47CiAgICBlbHNlIHsKCXByZWZpeFtwcmUrK10gPSAnLSc7Cgl1ID0g LW47CiAgICB9CgogICAgaWYgKGZsYWdzICYgRk1UX2FsdGZvcm0pCgl3aGlsZSAoKmFsdGZvcm0g IT0gJ1wwJykKCSAgICBwcmVmaXhbcHJlKytdID0gKmFsdGZvcm0rKzsKCiAgICBsZW4gPSB1dG9h ICh1LCBudW1iZXIsIHJhZGl4LCB0YWJsZVt1cHBlcl0pIC0gbnVtYmVyOwogICAgaWYgKChmbGFn cyAmIEZNVF9mMnNldCkgJiYgKFNJWkVfVCkgZm9ybWF0LT5mMiA+IGxlbikKCXplcm9lcyA9IGZv cm1hdC0+ZjIgLSBsZW47CiAgICBlbHNlCgl6ZXJvZXMgPSAwOwoKICAgIHdpZHRoID0gcHJlICsg emVyb2VzICsgbGVuOwogICAgaWYgKChmbGFncyAmIEZNVF9mMXNldCkgJiYgKFNJWkVfVCkgZm9y bWF0LT5mMSA+IHdpZHRoKSB7CglwYWRkaW5nID0gZm9ybWF0LT5mMSAtIHdpZHRoOwogICAgfSBl bHNlCglwYWRkaW5nID0gMDsKCiAgICBwYWRjaGFyID0gJyAnOwogICAgaWYgKHBhZGRpbmcgPiAw ICYmIGZsYWdzICYgRk1UX3plcm9wYWQpIHsKCXBhZGNoYXIgPSAnMCc7CglpZiAoKGZsYWdzICYg Rk1UX2xlZnRzaWRlKSA9PSAwKSB7CgkgICAgemVyb2VzICs9IHBhZGRpbmc7CgkgICAgcGFkZGlu ZyA9IDA7Cgl9CiAgICB9CgogICAgaWYgKChmbGFncyAmIEZNVF9sZWZ0c2lkZSkgPT0gMCkKCXBh ZCAoZm9ybWF0LCBwYWRkaW5nLCBwYWRjaGFyKTsKICAgIGZtdGFwcGVuZCAoZm9ybWF0LCBwcmVm aXgsIHByZSk7CiAgICBwYWQgKGZvcm1hdCwgemVyb2VzLCAnMCcpOwogICAgZm10YXBwZW5kIChm b3JtYXQsIG51bWJlciwgbGVuKTsKICAgIGlmIChmbGFncyAmIEZNVF9sZWZ0c2lkZSkKCXBhZCAo Zm9ybWF0LCBwYWRkaW5nLCBwYWRjaGFyKTsKfQoKc3RhdGljIGludCBjY29udiAoRm9ybWF0ICpm b3JtYXQsIGludCBjKSB7CiAgICBmbXRwdXRjIChmb3JtYXQsIHZhX2FyZyAoZm9ybWF0LT5hcmdz LCBpbnQpKTsKICAgIHJldHVybiBGTVRfdmVyYjsKfQoKc3RhdGljIGludCBkY29udiAoRm9ybWF0 ICpmb3JtYXQsIGludCBjKSB7CiAgICBpbnRjb252IChmb3JtYXQsIDEwLCAwLCAiIik7CiAgICBy ZXR1cm4gRk1UX3ZlcmI7Cn0KCnN0YXRpYyBpbnQgb2NvbnYgKEZvcm1hdCAqZm9ybWF0LCBpbnQg YykgewogICAgaW50Y29udiAoZm9ybWF0LCA4LCAwLCAiMCIpOwogICAgcmV0dXJuIEZNVF92ZXJi Owp9CgpzdGF0aWMgaW50IHhjb252IChGb3JtYXQgKmZvcm1hdCwgaW50IGMpIHsKICAgIGludGNv bnYgKGZvcm1hdCwgMTYsIDAsICIweCIpOwogICAgcmV0dXJuIEZNVF92ZXJiOwp9CgpzdGF0aWMg aW50IGxpdGNvbnYgKEZvcm1hdCAqZm9ybWF0LCBpbnQgYykgewogICAgZm10cHV0YyAoZm9ybWF0 LCBjKTsKICAgIHJldHVybiBGTVRfdmVyYjsKfQoKZXh0ZXJuIGludCBmbXRfYmFkY29udiAoRm9y bWF0ICpmb3JtYXQsIGludCBjKSB7CiAgICBlcHJpbnQgKCJsaWJwcmludDogYmFkIGNvbnZlcnNp b24gY2hhciAnJWMnXG4iLCBjKTsKICAgIGZvcm1hdC0+ZXJyb3IgPSAxOyAvKiBYWFggLSBzdG9w IG9yIG5vdD8gY29uc3VtZSBhbiBhcmd2PyAqLwogICAgcmV0dXJuIEZNVF92ZXJiOwp9CgpzdGF0 aWMgaW50IG5jb252IChGb3JtYXQqIGZvcm1hdCwgaW50IGMpCnsKICAgIC8qIHdyaXRlIHRoZSBj dXJyZW50IHdyaXRlIGxlbmd0aCBpbnRvIGFuIGludCogYXJndW1lbnQgKi8KICAgIGludCAqcCA9 IHZhX2FyZyAoZm9ybWF0LT5hcmdzLCBpbnQqKTsKICAgIGlmIChwKSAqcCA9IGZvcm1hdC0+YnVm IC0gZm9ybWF0LT5idWZiZWdpbiArIGZvcm1hdC0+Zmx1c2hlZDsKICAgIHJldHVybiBGTVRfdmVy YjsKfQoKc3RhdGljIGludCByY29udiAoRm9ybWF0ICpmb3JtYXQsIGludCBjKSB7CiAgICBpbnQg ZSA9IGVycm5vOwogICAgLyogZG8gd2UgaGF2ZSB0byBzdG9yZSBlcnJubyBpbiB0aGUgZm9ybWF0 IHN0cnVjdHVyZSBiZWNhdXNlCiAgICAgICB0aGUgZ3JvdyBwcm9jIGNvdWxkIG1ha2UgYSBzeXNj YWxsIHRoYXQgc2V0cyBlcnJubyBiZWZvcmUKICAgICAgIHdlIGdldCBoZXJlPyAqLwoKICAgIGlm IChmb3JtYXQtPmZsYWdzICYgRk1UX2FsdGZvcm0pIHsKCWZtdHByaW50IChmb3JtYXQsICIlZCIs IGUpOwogICAgfSBlbHNlIHsKCS8qIHN0cmVycm9yKCkgbWlnaHQgYmUgYmV0dGVyLCBidXQgdGhp cyB3YXkgd2UgY2FuIHJhbmdlIGNoZWNrICovCiAgICAgICAgZXh0ZXJuIGludCBzeXNfbmVycjsK ICAgICAgICBleHRlcm4gY2hhciogc3lzX2Vycmxpc3RbXTsKCWlmICgoMCA8PSBlKSAmJiAoZSA8 IHN5c19uZXJyKSkgCgkgICAgZm10Y2F0IChmb3JtYXQsIHN5c19lcnJsaXN0W2VdKTsKCWVsc2UK CSAgICBmbXRwcmludCAoZm9ybWF0LCAidW5rbm93biBlcnJvciAoJWQpIiwgZSk7CiAgICB9CiAg ICByZXR1cm4gRk1UX3ZlcmI7CQp9CgovKgogKiBjb252ZXJzaW9uIHRhYmxlIG1hbmFnZW1lbnQK ICovCgpzdGF0aWMgRm10Y29udiBkZmx0X2ZtdHRhYltGTVRfTUFYQ09OVl07CgpzdGF0aWMgRm10 Y29udiogZW5zdXJlX2luaXR0YWIgKEZtdGNvbnYgZm10dGFiW10pCnsKICAgIGludCBpOwoKICAg IGlmIChmbXR0YWJbMF0gIT0gMCkKCXJldHVybiBmbXR0YWI7CgogICAgZm9yIChpID0gMDsgaSA8 IEZNVF9NQVhDT05WOyBpKyspCglmbXR0YWJbaV0gPSBmbXRfYmFkY29udjsKCiAgICBmbXR0YWJb JyUnXSA9IGxpdGNvbnY7CgogICAgZm10dGFiWydzJ10gPSBzY29udjsKICAgIGZtdHRhYlsnYydd ID0gY2NvbnY7CiAgICBmbXR0YWJbJ2QnXSA9IGRjb252OwogICAgZm10dGFiWydpJ10gPSBkY29u djsKICAgIGZtdHRhYlsnbyddID0gb2NvbnY7CiAgICBmbXR0YWJbJ3gnXSA9IHhjb252OwogICAg Zm10dGFiWydyJ10gPSByY29udjsKICAgIGZtdHRhYlsnbSddID0gcmNvbnY7CiAgICBmbXR0YWJb J24nXSA9IG5jb252OwoKICAgIGZtdHRhYlsndSddID0gdWNvbnY7CiAgICBmbXR0YWJbJ2gnXSA9 IGhjb252OwogICAgZm10dGFiWydsJ10gPSBsY29udjsKICAgIGZtdHRhYlsnIyddID0gYWx0Y29u djsKICAgIGZtdHRhYlsnLSddID0gbGVmdGNvbnY7CiAgICBmbXR0YWJbJy4nXSA9IGRvdGNvbnY7 CiAgICBmbXR0YWJbJyonXSA9IHN0YXJjb252OwoKICAgIGZtdHRhYlsnMCddID0gemVyb2NvbnY7 CiAgICBmb3IgKGkgPSAnMSc7IGkgPD0gJzknOyBpKyspCglmbXR0YWJbaV0gPSBkaWdpdGNvbnY7 CgogICAgcmV0dXJuIGZtdHRhYjsKfQoKZXh0ZXJuIEZtdGNvbnYgZm10aW5zdGFsbCAoaW50IGMs IEZtdGNvbnYgZikKewogICAgRm10Y29udiBvbGRmOwoKICAgIGVuc3VyZV9pbml0dGFiIChkZmx0 X2ZtdHRhYik7CiAgICBjICY9IEZNVF9NQVhDT05WIC0gMTsKICAgIG9sZGYgPSBkZmx0X2ZtdHRh YltjXTsKICAgIGlmIChmICE9IDApCglkZmx0X2ZtdHRhYltjXSA9IGY7CiAgICByZXR1cm4gb2xk ZjsKfQoKLyogLS0tICovCgpzdGF0aWMgdm9pZCBmbXRpbml0YnVmIChGb3JtYXQgKmZvcm1hdCwg CgkJCWNoYXIgKmJ1ZiwgU0laRV9UIHNpemUsIGludCAoKmdyb3cpKEZvcm1hdCAqLCBTSVpFX1Qp KQp7CiAgICBmb3JtYXQtPmJ1ZiAgICAgID0gYnVmOwogICAgZm9ybWF0LT5idWZiZWdpbiA9IGJ1 ZjsKICAgIGZvcm1hdC0+YnVmZW5kICAgPSBidWYgKyBzaXplOwogICAgZm9ybWF0LT5ncm93ICAg ICA9IGdyb3c7CiAgICBmb3JtYXQtPmZsdXNoZWQgID0gMDsKICAgIGZvcm1hdC0+ZXJyb3IgICAg PSAwOwogICAgZm9ybWF0LT5yZXFsZW4gICA9IDA7Cn0KCnN0YXRpYyB2b2lkIGZtdGluaXRhcmcg KEZvcm1hdCAqZm9ybWF0LCAKCQkJdmFfbGlzdCBhcmdzLCBGbXRjb252KiBmbXR0YWIsIHZvaWQq IGNsaWVudF9kYXRhKQp7CiAgICBmb3JtYXQtPmFyZ3MgPSBhcmdzOwogICAgZm9ybWF0LT5mbXR0 YWIgPSAwOwogICAgZm9ybWF0LT5jbGllbnRfZGF0YSA9IDA7Cn0KCQkgICAgIAovKgogKiB0aGUg Zm9ybWF0dGluZyBlbmdpbmUKICovCgpleHRlcm4gaW50IGZtdGVuZ2luZSAoRm9ybWF0ICpmb3Jt YXQsIGNvbnN0IGNoYXIgKmZtdCkKewogICAgY29uc3QgdW5zaWduZWQgY2hhciAqcyA9IChjb25z dCB1bnNpZ25lZCBjaGFyICopIGZtdDsKICAgIEZtdGNvbnYqIGZtdHRhYjsKIAogICAgaWYgKChm bXR0YWIgPSBmb3JtYXQtPmZtdHRhYikgPT0gMCkKICAgICAgICBmbXR0YWIgPSBlbnN1cmVfaW5p dHRhYiAoZGZsdF9mbXR0YWIpOwoKICAgIGZvciAoOzspIHsKCWludCBjID0gKnMrKzsKCglzd2l0 Y2ggKGMpIHsKCWNhc2UgJyUnOgoJICAgIGZvcm1hdC0+ZmxhZ3MgPSBmb3JtYXQtPmYxID0gZm9y bWF0LT5mMiA9IDA7CgkgICAgZG8gYyA9ICpzKys7IHdoaWxlICgoKmZtdHRhYltjXSkoZm9ybWF0 LCBjKSA9PSBGTVRfZmxhZyk7CgkgICAgYnJlYWs7CgljYXNlICdcMCc6CgkgICAgcmV0dXJuIGZv cm1hdC0+YnVmIC0gZm9ybWF0LT5idWZiZWdpbiArIGZvcm1hdC0+Zmx1c2hlZDsKCWRlZmF1bHQ6 CgkgICAgZm10cHV0YyAoZm9ybWF0LCBjKTsKCSAgICBicmVhazsKCX0KICAgIH0KfQoKCi8qCiAq IHRoZSBwdWJsaWMgZW50cnkgcG9pbnRzCiAqLwoKZXh0ZXJuIGludCBmbXRwcmludCAoRm9ybWF0 ICpmb3JtYXQsIGNvbnN0IGNoYXIgKmZtdCwuLi4pIHsKICAgIGludCBuID0gLWZvcm1hdC0+Zmx1 c2hlZDsKICAgIHZhX2xpc3QgYXAsIHNhdmVhcmdzOwoKICAgIHZhX3N0YXJ0IChhcCwgZm10KTsK ICAgIHNhdmVhcmdzID0gZm9ybWF0LT5hcmdzOwogICAgZm9ybWF0LT5hcmdzID0gYXA7CiAgICBu ICs9IGZtdGVuZ2luZSAoZm9ybWF0LCBmbXQpOwogICAgdmFfZW5kIChmb3JtYXQtPmFyZ3MpOwog ICAgZm9ybWF0LT5hcmdzID0gc2F2ZWFyZ3M7CgogICAgcmV0dXJuIG4gKyBmb3JtYXQtPmZsdXNo ZWQ7Cn0KCi8qIC0tLSAqLwoKc3RhdGljIGludCB3cml0ZWFsbCAoaW50IGZkLCBjaGFyICpidWYs IFNJWkVfVCBuKSB7CiAgICBpbnQgaSwgcmVtYWluOwoKICAgIGZvciAoaSA9IDAsIHJlbWFpbiA9 IG47IHJlbWFpbiA+IDA7IGJ1ZiArPSBpLCByZW1haW4gLT0gaSkKCWlmICgoaSA9IHdyaXRlIChm ZCwgYnVmLCByZW1haW4pKSA8PSAwKQoJICAgIGlmICgoZXJybm8gPT0gRUFHQUlOKSB8fCAoZXJy bm8gPT0gRVdPVUxEQkxPQ0spKQoJCWNvbnRpbnVlOwoJICAgIGVsc2UKCQlicmVhazsKCiAgICBy ZXR1cm4gbiAtIHJlbWFpbjsgCn0KCi8qIC0tLSAqLwoKZXh0ZXJuIGludCBmbXRfZnByaW50X2Zs dXNoIChGb3JtYXQgKmZvcm1hdCwgU0laRV9UIG1vcmUpIHsKICAgIFNJWkVfVCBuID0gZm9ybWF0 LT5idWYgLSBmb3JtYXQtPmJ1ZmJlZ2luOwogICAgU0laRV9UIHI7CgogICAgciA9IHdyaXRlYWxs IChmb3JtYXQtPnUubiwgZm9ybWF0LT5idWZiZWdpbiwgbik7CiAgICBmb3JtYXQtPmZsdXNoZWQg Kz0gcjsKICAgIGZvcm1hdC0+YnVmIC09IHI7CiAgICBmb3JtYXQtPmVycm9yIHw9IChyICE9IG4p OwoKICAgIHJldHVybiBmb3JtYXQtPmVycm9yOwp9CgpleHRlcm4gaW50IHZmcHJpbnQgKGludCBm ZCwgY29uc3QgY2hhciAqZm10LCB2YV9saXN0IGFwKSB7CiAgICBjaGFyIGJ1ZlsxMDI0XTsKICAg IEZvcm1hdCBmb3JtYXQ7CgogICAgZm10aW5pdGJ1ZiAoJmZvcm1hdCwgYnVmLCBzaXplb2YgYnVm LCBmbXRfZnByaW50X2ZsdXNoKTsKICAgIGZtdGluaXRhcmcgKCZmb3JtYXQsIGFwLCAwLCAwKTsK ICAgIGZvcm1hdC51Lm4gPSBmZDsKCiAgICBmbXRlbmdpbmUgKCZmb3JtYXQsIGZtdCk7CiAgICBm bXRfZnByaW50X2ZsdXNoICgmZm9ybWF0LCAwKTsKICAgIHJldHVybiBmb3JtYXQuZXJyb3IgPyAt MSA6IGZvcm1hdC5mbHVzaGVkOwp9CgpleHRlcm4gaW50IGZwcmludCAoaW50IGZkLCBjb25zdCBj aGFyICpmbXQsLi4uKSB7CiAgICBpbnQgbjsKICAgIHZhX2xpc3QgYXA7CgogICAgdmFfc3RhcnQg KGFwLCBmbXQpOwogICAgbiA9IHZmcHJpbnQgKGZkLCBmbXQsIGFwKTsKICAgIHZhX2VuZCAoYXAp OwogICAgcmV0dXJuIG47Cn0KCmV4dGVybiBpbnQgcHJpbnQgKGNvbnN0IGNoYXIgKmZtdCwuLi4p IHsKICAgIGludCBuOwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydCAoYXAsIGZtdCk7CiAg ICBuID0gdmZwcmludCAoMSwgZm10LCBhcCk7CiAgICB2YV9lbmQgKGFwKTsKICAgIHJldHVybiBu Owp9CgpleHRlcm4gaW50IGVwcmludCAoY29uc3QgY2hhciAqZm10LC4uLikgewogICAgaW50IG47 CiAgICB2YV9saXN0IGFwOwoKICAgIHZhX3N0YXJ0IChhcCwgZm10KTsKICAgIG4gPSB2ZnByaW50 ICgyLCBmbXQsIGFwKTsKICAgIHZhX2VuZCAoYXApOwogICAgcmV0dXJuIG47Cn0KCnZvaWQgZmF0 YWwgKGNvbnN0IGNoYXIgKmZtdCwgLi4uKQp7CiAgICB2YV9saXN0IGFwOwogICAgdmFfc3RhcnQg KGFwLCBmbXQpOwogICAgKHZvaWQpIHZmcHJpbnQgKDIsIGZtdCwgYXApOwogICAgdmFfZW5kIChh cCk7CiAgICBleGl0ICgxKTsKfQoKLyogLS0tICovCgpleHRlcm4gaW50IGZtdF9tZW1wcmludF9n cm93IChGb3JtYXQgKmZvcm1hdCwgU0laRV9UIG1vcmUpIHsKICAgIGNoYXIgKmJ1ZiA9IDA7CiAg ICBTSVpFX1QgcG9zID0gZm9ybWF0LT5idWYgLSBmb3JtYXQtPmJ1ZmJlZ2luOwogICAgU0laRV9U IGxlbiA9IGZvcm1hdC0+YnVmZW5kIC0gZm9ybWF0LT5idWZiZWdpbiArIDE7CiAgICBsZW4gPSAo bGVuID49IG1vcmUpCgk/IGxlbiAqIDIgCiAgICAgICAgOiAoKGxlbiArIG1vcmUpICsgRk1UX1BS SU5UX0FMTE9DU0laRSkgJn4gKEZNVF9QUklOVF9BTExPQ1NJWkUgLSAxKTsKCiAgICBidWYgPSAo KEFsbG9jKWZvcm1hdC0+dS5wKShmb3JtYXQtPmJ1ZmJlZ2luLCBsZW4pOwogICAgaWYgKGJ1Zikg ewoJZm9ybWF0LT5idWZiZWdpbiA9IGJ1ZjsKCWZvcm1hdC0+YnVmCSA9IGJ1ZiArIHBvczsKCWZv cm1hdC0+YnVmZW5kICAgPSBidWYgKyBsZW4gLSAxOwoJcmV0dXJuIDA7CiAgICB9CiAgICByZXR1 cm4gZm9ybWF0LT5lcnJvciA9IDE7Cn0KCmV4dGVybiBjaGFyICpmbXRfbWVtcHJpbnQgKEZvcm1h dCAqZm9ybWF0LCBjb25zdCBjaGFyICpmbXQsIFNJWkVfVCogbGVuKSB7CiAgICBjaGFyKiBidWY7 CiAgICBpbnQgbjsKCiAgICBidWYgPSAoKihBbGxvYylmb3JtYXQtPnUucCkgKDAsIEZNVF9QUklO VF9BTExPQ1NJWkUpOwogICAgaWYgKCFidWYpIHsKCWZvcm1hdC0+ZXJyb3IgPSAxOwoJcmV0dXJu IDA7CiAgICB9CgogICAgZm10aW5pdGJ1ZiAoZm9ybWF0LCBidWYsIEZNVF9QUklOVF9BTExPQ1NJ WkUgLSAxLCBmbXRfbWVtcHJpbnRfZ3Jvdyk7CiAgICBuID0gZm10ZW5naW5lIChmb3JtYXQsIGZt dCk7CiAgICAqZm9ybWF0LT5idWYgPSAnXDAnOwogICAgaWYgKGxlbikgKmxlbiA9IG47CgogICAg cmV0dXJuIGZvcm1hdC0+ZXJyb3IgPyAwIDogZm9ybWF0LT5idWZiZWdpbjsKfQoKZXh0ZXJuIGNo YXIgKnZzbXByaW50IChBbGxvYyBhLCBTSVpFX1QqIGxlbiwgY29uc3QgY2hhciogZm10LCB2YV9s aXN0IGFwKSB7CiAgICBGb3JtYXQgZm9ybWF0OwoKICAgIGZtdGluaXRhcmcgKCZmb3JtYXQsIGFw LCAwLCAwKTsKICAgIGZvcm1hdC51LnAgPSAodm9pZCopIGE7CgogICAgcmV0dXJuIGZtdF9tZW1w cmludCAoJmZvcm1hdCwgZm10LCBsZW4pOwp9CgpleHRlcm4gY2hhciAqc21wcmludCAoQWxsb2Mg YWxsb2MsIFNJWkVfVCogbGVuLCBjb25zdCBjaGFyKiBmbXQsIC4uLikgewogICAgY2hhciogcmVz dWx0OwogICAgdmFfbGlzdCBhcDsKCiAgICB2YV9zdGFydCAoYXAsIGZtdCk7CiAgICByZXN1bHQg PSB2c21wcmludCAoYWxsb2MsIGxlbiwgZm10LCBhcCk7CiAgICB2YV9lbmQgKGFwKTsKICAgIHJl dHVybiByZXN1bHQ7Cn0KCi8qIG5vdGUgLS0gbW92ZWQgcGFsbG9jIGFuZCBtcHJpbnQgdG8gbXBy aW50LmMgKi8KCi8qIC0tLSAqLwoKZXh0ZXJuIGludCBmbXRfc25wcmludF9ncm93IChGb3JtYXQg KmZvcm1hdCwgU0laRV9UIG1vcmUpIHsKICAgIHJldHVybiBmb3JtYXQtPmVycm9yPTE7Cn0KCmV4 dGVybiBpbnQgdnNucHJpbnQgKGNoYXIgKmJ1ZiwgaW50IGJ1ZmxlbiwgY29uc3QgY2hhciAqZm10 LCB2YV9saXN0IGFwKSB7CiAgICBGb3JtYXQgZm9ybWF0OwoKICAgIGZtdGluaXRidWYgKCZmb3Jt YXQsIGJ1ZiwgYnVmbGVuIC0gMSwgZm10X3NucHJpbnRfZ3Jvdyk7CiAgICBmbXRpbml0YXJnICgm Zm9ybWF0LCBhcCwgMCwgMCk7CiAgICBmb3JtYXQuYXJncyA9IGFwOwoKICAgICh2b2lkKSBmbXRl bmdpbmUgKCZmb3JtYXQsIGZtdCk7CiAgICAqZm9ybWF0LmJ1ZiA9ICdcMCc7CiAgICByZXR1cm4g Zm9ybWF0LnJlcWxlbjsKfQoKZXh0ZXJuIGludCBzbnByaW50IChjaGFyICpidWYsIGludCBidWZs ZW4sIGNvbnN0IGNoYXIgKmZtdCwuLi4pIHsKICAgIGludCBuOwogICAgdmFfbGlzdCBhcDsKCiAg ICB2YV9zdGFydCAoYXAsIGZtdCk7CiAgICBuID0gdnNucHJpbnQgKGJ1ZiwgYnVmbGVuLCBmbXQs IGFwKTsKICAgIHZhX2VuZCAoYXApOwogICAgcmV0dXJuIG47Cn0KCmV4dGVybiBpbnQgc3ByaW50 IChjaGFyICpidWYsIGNvbnN0IGNoYXIgKmZtdCwuLi4pIHsKICAgIGludCBuOwogICAgdmFfbGlz dCBhcDsKCiAgICB2YV9zdGFydCAoYXAsIGZtdCk7CiAgICBuID0gdnNucHJpbnQgKGJ1ZiwgRk1U X1NQUklOVF9CVUZTSVosIGZtdCwgYXApOwogICAgdmFfZW5kIChhcCk7CiAgICByZXR1cm4gbjsK fQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNhbTJrL2xpYi9wbHVtYi5j AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDE3MzcAMDAwMDE1MQAwMDAwMDAw MDQzNQAwNzExMTY0MjUzMgAwMDE1MDE0ADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdjc2UA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI2luY2x1ZGUgPHUuaD4KI2lu Y2x1ZGUgInBsdW1iLmgiCgovKiBYWFggLSBDYW4gd2UgZG8gYmV0dGVyIHRoYW4gdGhpcz8gKi8K Y2hhciAqY2xlYW5uYW1lKGNoYXIgKnMpIHsgcmV0dXJuIHM7IH0gCmNoYXIgKnBsdW1idW5wYWNr YXR0cihjaGFyICpjYnVmKSB7IGFib3J0KCk7IHJldHVybiAwOyB9CmNoYXIgKnBsdW1icGFjayhQ bHVtYm1zZyAqcG0sIGludCAqaSkgeyBhYm9ydCgpOyByZXR1cm4gMDsgfQppbnQgcGx1bWJmcmVl KFBsdW1ibXNnICpwbSkgeyBhYm9ydCgpOyByZXR1cm4gMDsgfQoKAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzYW0yay9zYW0vAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDA0MDc1NQAwMDAxNzM3ADAwMDAxNTEAMDAwMDAwMDAw MDAAMDcxMTIxMTc3MjYAMDAxMzU0NwA1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHVzdGFyADAwc2Nod2FydHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnY3NlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwNDAAMDAwMDAyNwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNhbTJrL3NhbS91bml4LmMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDE3MzcAMDAwMDE1MQAwMDAwMDAwNzA1 NgAwNzExMjAyMjQ2MQAwMDE0NjcyADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdjc2UAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyogQ29weXJpZ2h0IChjKSAxOTky IEFUJlQgLSBBbGwgcmlnaHRzIHJlc2VydmVkLiAqLwovKiBDaGFuZ2VzIDIwMDAsIFNjb3R0IFNj aHdhcnR6ICovCgojaW5jbHVkZSA8dS5oPgojaW5jbHVkZSA8bGliYy5oPgoKI2luY2x1ZGUgInNh bS5oIgojaW5jbHVkZSAidW5peC5oIgoKUnVuZQlzYW1uYW1lW10gPSB7ICd+JywgJ34nLCAncycs ICdhJywgJ20nLCAnficsICd+JywgMCB9OwoKc3RhdGljIFJ1bmUgbDFbXSA9IHsgJ3snLCAnWycs ICcoJywgJzwnLCAwMjUzLCAwfTsKc3RhdGljIFJ1bmUgbDJbXSA9IHsgJ1xuJywgMH07CnN0YXRp YyBSdW5lIGwzW10gPSB7ICdcJycsICciJywgJ2AnLCAwfTsKUnVuZSAqbGVmdFtdPSB7IGwxLCBs MiwgbDMsIDB9OwoKc3RhdGljIFJ1bmUgcjFbXSA9IHsnfScsICddJywgJyknLCAnPicsIDAyNzMs IDB9OwpzdGF0aWMgUnVuZSByMltdID0geydcbicsIDB9OwpzdGF0aWMgUnVuZSByM1tdID0geydc JycsICciJywgJ2AnLCAwfTsKUnVuZSAqcmlnaHRbXT0geyByMSwgcjIsIHIzLCAwfTsKCmNoYXIJ UlNBTVtdID0gUlNBTU5BTUU7CmNoYXIJU0FNVEVSTVtdID0gVEVSTU5BTUU7CmNoYXIJSE9NRVtd ID0gSE9NRURJUjsKY2hhcglUTVBESVJbXSA9IFRNUDsKY2hhcglTSFtdID0gU0hFTExOQU1FOwpj aGFyCVNIUEFUSFtdID0gU0hFTExQQVRIOwpjaGFyCVJYW10gPSBSWE5BTUU7CmNoYXIJUlhQQVRI W10gPSBSWFBBVEhOQU1FOwpjaGFyCVNBTVNBVkVDTURbXSA9IFNBTVNBVkU7Cgp2b2lkCnByaW50 X3NzKGNoYXIgKnMsIFN0cmluZyAqYSwgU3RyaW5nICpiKQp7CgljaGFyICphcCwgKmJwLCAqY3A7 CglSdW5lICpycDsKCglhcCA9IGVtYWxsb2MoYS0+bisxKTsKCWZvciAoY3AgPSBhcCwgcnAgPSBh LT5zOyAqcnA7IHJwKyspCgkJY3AgKz0gcnVuZXRvY2hhcihjcCwgcnApOwoJKmNwID0gMDsKCWJw ID0gZW1hbGxvYyhiLT5uKzEpOwoJZm9yIChjcCA9IGJwLCBycCA9IGItPnM7ICpycDsgcnArKykK CQljcCArPSBydW5ldG9jaGFyKGNwLCBycCk7CgkqY3AgPSAwOwoJZHByaW50KCI/d2FybmluZzog JXMgYCUuKnMnIGFuZCBgJS4qcydcbiIsIHMsIGEtPm4sIGFwLCBiLT5uLCBicCk7CglmcmVlKGFw KTsKCWZyZWUoYnApOwp9Cgp2b2lkCnByaW50X3MoY2hhciAqcywgU3RyaW5nICphKQp7CgljaGFy ICphcCwgKmNwOwoJUnVuZSAqcnA7CgoJYXAgPSBlbWFsbG9jKGEtPm4rMSk7Cglmb3IgKGNwID0g YXAsIHJwID0gYS0+czsgKnJwOyBycCsrKQoJCWNwICs9IHJ1bmV0b2NoYXIoY3AsIHJwKTsKCSpj cCA9IDA7CglkcHJpbnQoIj93YXJuaW5nOiAlcyBgJS4qcydcbiIsIHMsIGEtPm4sIGFwKTsKCWZy ZWUoYXApOwp9CgppbnQKc3RhdGZpbGUoY2hhciAqbmFtZSwgdWxvbmcgKmRldiwgdWxvbmcgKmlk LCBsb25nICp0aW1lLCBsb25nICpsZW5ndGgsIGxvbmcgKmFwcGVuZG9ubHkpCnsKCXN0cnVjdCBz dGF0IGRpcmI7CgoJaWYgKHN0YXQobmFtZSwgJmRpcmIpID09IC0xKQoJCXJldHVybiAtMTsKCWlm IChkZXYpCgkJKmRldiA9IGRpcmIuc3RfZGV2OwoJaWYgKGlkKQoJCSppZCA9IGRpcmIuc3RfaW5v OwoJaWYgKHRpbWUpCgkJKnRpbWUgPSBkaXJiLnN0X210aW1lOwoJaWYgKGxlbmd0aCkKCQkqbGVu Z3RoID0gZGlyYi5zdF9zaXplOwoJaWYoYXBwZW5kb25seSkKCQkqYXBwZW5kb25seSA9IDA7Cgly ZXR1cm4gMTsKfQoKaW50CnN0YXRmZChpbnQgZmQsIHVsb25nICpkZXYsIHVsb25nICppZCwgbG9u ZyAqdGltZSwgbG9uZyAqbGVuZ3RoLCBsb25nICphcHBlbmRvbmx5KQp7CglzdHJ1Y3Qgc3RhdCBk aXJiOwoKCWlmIChmc3RhdChmZCwgJmRpcmIpID09IC0xKQoJCXJldHVybiAtMTsKCWlmIChkZXYp CgkJKmRldiA9IGRpcmIuc3RfZGV2OwoJaWYgKGlkKQoJCSppZCA9IGRpcmIuc3RfaW5vOwoJaWYg KHRpbWUpCgkJKnRpbWUgPSBkaXJiLnN0X210aW1lOwoJaWYgKGxlbmd0aCkKCQkqbGVuZ3RoID0g ZGlyYi5zdF9zaXplOwoJaWYoYXBwZW5kb25seSkKCQkqYXBwZW5kb25seSA9IDA7CglyZXR1cm4g MTsKfQoKdm9pZApodXAoaW50IHNpZykKewoJcmVzY3VlKCk7CglleGl0KDEpOwp9CgppbnQKbm90 aWZ5ICh2b2lkKCpmKSh2b2lkICosIGNoYXIgKikpCnsKCXNpZ25hbChTSUdJTlQsIFNJR19JR04p OwoJc2lnbmFsKFNJR0hVUCwgaHVwKTsKCXNpZ25hbChTSUdQSVBFLCBTSUdfSUdOKTsKI2lmZGVm CXYxMAoJY2xvc2UoMyk7CQkvKiByZWRpcmVjdCB2MTAgL2Rldi90dHkgKi8KCW9wZW4oIi9kZXYv bnVsbCIsIDIpOwojZW5kaWYKCXJldHVybiAxOwp9Cgp2b2lkCm5vdGlmeWYodm9pZCAqYSwgY2hh ciAqYikJLyogbmV2ZXIgY2FsbGVkICovCnsKfQoKc3RhdGljIGludAp0ZW1wX2ZpbGUoY2hhciAq YnVmLCBpbnQgYnVmc2l6ZSkKewoJY2hhciAqdG1wOwoJaW50IG4sIGZkOwoKCXRtcCA9IGdldGVu digiVE1QRElSIik7CglpZiAoIXRtcCkKCQl0bXAgPSBUTVBESVI7CgoJbiA9IHNucHJpbnQoYnVm LCBidWZzaXplLCAiJXMvc2FtLiVkLlhYWFhYWFgiLCB0bXAsIGdldHVpZCgpKTsKCWlmIChidWZz aXplIDw9IG4pCgkJcmV0dXJuIC0xOwoJaWYgKChmZCA9IG1rc3RlbXAoYnVmKSkgPCAwKSAgLyog WFhYIC0gdXN1YWxseSBtb2RlIDA2MDAsIGJ1dCBzb21ldGltZXMgbW9yZS4gKi8KCQlyZXR1cm4g LTE7CiAJaWYgKGZjbnRsKGZkLCBGX1NFVEZELCBmY250bChmZCxGX0dFVEZELDApIHwgRkRfQ0xP RVhFQykgPCAwKQoJCXJldHVybiAtMTsKCXJldHVybiBmZDsKfQoKaW50CnRlbXBkaXNrKHZvaWQp CnsKCWNoYXIgYnVmWzQwOTZdOwoJaW50IGZkID0gdGVtcF9maWxlKGJ1Ziwgc2l6ZW9mIGJ1Zik7 CglpZiAoZmQgPj0gMCkKCQlyZW1vdmUoYnVmKTsKCXJldHVybiBmZDsKfQoKdm9pZApzYW1lcnIo Y2hhciAqYnVmKQp7CglpbnQgZmQ7CgoJaWYgKGJ1ZlswXSkKCQlyZXR1cm47CgoJaWYgKChmZCA9 IHRlbXBfZmlsZShidWYsIDY0KSkgPCAwKSAvKiBYWFggLSBmcm9tIHNoZWxsLmMgKi8KCQlzdHJj cHkoYnVmLCAiL2Rldi9udWxsIik7CgllbHNlCgkJY2xvc2UoZmQpOwp9CgppbnQKd2FpdGZvcihp bnQgcGlkKQp7CglpbnQgd207CglpbnQgcnBpZDsKCglkbzsgd2hpbGUoKHJwaWQgPSB3YWl0KCZ3 bSkpICE9IHBpZCAmJiBycGlkICE9IC0xKTsKCXJldHVybiAoV0VYSVRTVEFUVVMod20pKTsKfQoK dm9pZCoKZW1hbGxvYyh1bG9uZyBuKQp7Cgl2b2lkICpwOwoKCWlmIChuIDwgc2l6ZW9mKGludCkp CgkJbiA9IHNpemVvZihpbnQpOwoJcCA9IG1hbGxvYyhuKTsKCWlmKHAgPT0gMCkKCQlwYW5pYygi bWFsbG9jIGZhaWxzIik7CgltZW1zZXQocCwgMCwgbik7CglyZXR1cm4gcDsKfQoKdm9pZCoKZXJl YWxsb2Modm9pZCAqcCwgdWxvbmcgbikKewoJcCA9IHJlYWxsb2MocCwgbik7CglpZihwID09IDAp CgkJcGFuaWMoInJlYWxsb2MgZmFpbHMiKTsKCXJldHVybiBwOwp9Cgp2b2lkCmRwcmludChjaGFy ICp6LCAuLi4pCnsKICAgICAgICBjaGFyICpidWY7Cgl2YV9saXN0IGFyZ3M7Cgl2YV9zdGFydChh cmdzLCB6KTsKIAlpZiAoKGJ1ZiA9IHZzbXByaW50ICgoY2hhciooKikoY2hhciosdWxvbmcpKWVy ZWFsbG9jLCAwLCB6LCBhcmdzKSkpIHsKCQl0ZXJtd3JpdGUoYnVmKTsKCQlmcmVlKGJ1Zik7Cgl9 Cgl2YV9lbmQoYXJncyk7Cn0KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNhbTJrL3NhbS9NYWtlZmlsZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDE3MzcAMDAwMDE1MQAwMDAwMDAwMTEwMgAwNzExMjAz MDAzMwAwMDE1MTU3ADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA dXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdjc2UAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU1JDPWFkZHJlc3MuYyBidWZmLmMgY21kLmMgZGlz ay5jIGVycm9yLmMgZmlsZS5jIGlvLmMgbGlzdC5jIG1lc2cuYyBcCiAgICBtb3ZldG8uYyBtdWx0 aS5jIHJhc3AuYyByZWdleHAuYyBzYW0uYyBzaGVsbC5jIHN0cmluZy5jIHN5cy5jIHV0aWwuYyB4 ZWMuYyBcCiAgICB1bml4LmMKCk9CSj1hZGRyZXNzLm8gYnVmZi5vIGNtZC5vIGRpc2subyBlcnJv ci5vIGZpbGUubyBpby5vIGxpc3QubyBtZXNnLm8gXAogICAgbW92ZXRvLm8gbXVsdGkubyByYXNw Lm8gcmVnZXhwLm8gc2FtLm8gc2hlbGwubyBzdHJpbmcubyBzeXMubyB1dGlsLm8geGVjLm8gXAog ICAgdW5peC5vCgpIRFI9ZXJyb3JzLmggbWVzZy5oIHBhcnNlLmggc2FtLmgKCkNGTEFHUz0tSS4g LUkuLi9pbmNsdWRlCgpDQz1nY2MgLVdhbGwgLU8zIAkjIEdjYwojQ0M9Y2MgLXhDQyAtdiAtZmFz dAkjIFNvbGFyaXMgV29ya3Nob3AKClRBUkc9c2FtCmFsbDogJChUQVJHKQoKJChPQkopOiAkKEhE UikKCiQoVEFSRyk6ICQoT0JKKSAkKEhEUikKCSQoQ0MpICQoT0JKKSAuLi9saWIvbGliLmEgLW8g c2FtCmNsZWFuOgoJcm0gLWYgKi5vICQoVEFSRykgdGFncwoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNhbTJrL3NhbS9hZGRyZXNzLmMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDE3MzcAMDAwMDE1MQAwMDAwMDAwNzY1MwAwNzExMTYzMTM1 MAAwMDE1MzQxADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0 YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI2luY2x1ZGUgInNhbS5oIgojaW5jbHVkZSAicGFyc2Uu aCIKCkFkZHJlc3MJYWRkcjsKU3RyaW5nCWxhc3RwYXQ7CmludAlwYXRzZXQ7CkZpbGUJKm1lbnU7 CgpGaWxlCSptYXRjaGZpbGUoU3RyaW5nKik7CkFkZHJlc3MJY2hhcmFkZHIoUG9zbiwgQWRkcmVz cywgaW50KTsKCkFkZHJlc3MKYWRkcmVzcyhBZGRyICphcCwgQWRkcmVzcyBhLCBpbnQgc2lnbikK ewoJRmlsZSAqZiA9IGEuZjsKCUFkZHJlc3MgYTEsIGEyOwoKCWRvewoJCXN3aXRjaChhcC0+dHlw ZSl7CgkJY2FzZSAnbCc6CgkJY2FzZSAnIyc6CgkJCWEgPSAoKihhcC0+dHlwZT09JyMnP2NoYXJh ZGRyOmxpbmVhZGRyKSkoYXAtPm51bSwgYSwgc2lnbik7CgkJCWJyZWFrOwoKCQljYXNlICcuJzoK CQkJYSA9IGYtPmRvdDsKCQkJYnJlYWs7CgoJCWNhc2UgJyQnOgoJCQlhLnIucDEgPSBhLnIucDIg PSBmLT5VLm5jOwoJCQlicmVhazsKCgkJY2FzZSAnXCcnOgoJCQlhLnIgPSBmLT5tYXJrOwoJCQli cmVhazsKCgkJY2FzZSAnPyc6CgkJCXNpZ24gPSAtc2lnbjsKCQkJaWYoc2lnbiA9PSAwKQoJCQkJ c2lnbiA9IC0xOwoJCQkvKiBmYWxsIHRocm91Z2ggKi8KCQljYXNlICcvJzoKCQkJbmV4dG1hdGNo KGYsIGFwLT5hcmUsIHNpZ24+PTA/IGEuci5wMiA6IGEuci5wMSwgc2lnbik7CgkJCWEuciA9IHNl bC5wWzBdOwoJCQlicmVhazsKCgkJY2FzZSAnIic6CgkJCWEgPSBtYXRjaGZpbGUoYXAtPmFyZSkt PmRvdDsKCQkJZiA9IGEuZjsKCQkJaWYoZi0+dW5yZWFkKQoJCQkJbG9hZChmKTsKCQkJYnJlYWs7 CgoJCWNhc2UgJyonOgoJCQlhLnIucDEgPSAwLCBhLnIucDIgPSBmLT5VLm5jOwoJCQlyZXR1cm4g YTsKCgkJY2FzZSAnLCc6CgkJY2FzZSAnOyc6CgkJCWlmKGFwLT5sZWZ0KQoJCQkJYTEgPSBhZGRy ZXNzKGFwLT5sZWZ0LCBhLCAwKTsKCQkJZWxzZQoJCQkJYTEuZiA9IGEuZiwgYTEuci5wMSA9IGEx LnIucDIgPSAwOwoJCQlpZihhcC0+dHlwZSA9PSAnOycpewoJCQkJZiA9IGExLmY7CgkJCQlhID0g YTE7CgkJCQlmLT5kb3QgPSBhMTsKCQkJfQoJCQlpZihhcC0+bmV4dCkKCQkJCWEyID0gYWRkcmVz cyhhcC0+bmV4dCwgYSwgMCk7CgkJCWVsc2UKCQkJCWEyLmYgPSBhLmYsIGEyLnIucDEgPSBhMi5y LnAyID0gZi0+VS5uYzsKCQkJaWYoYTEuZiAhPSBhMi5mKQoJCQkJZXJyb3IoRW9yZGVyKTsKCQkJ YS5mID0gYTEuZiwgYS5yLnAxID0gYTEuci5wMSwgYS5yLnAyID0gYTIuci5wMjsKCQkJaWYoYS5y LnAyIDwgYS5yLnAxKQoJCQkJZXJyb3IoRW9yZGVyKTsKCQkJcmV0dXJuIGE7CgoJCWNhc2UgJysn OgoJCWNhc2UgJy0nOgoJCQlzaWduID0gMTsKCQkJaWYoYXAtPnR5cGUgPT0gJy0nKQoJCQkJc2ln biA9IC0xOwoJCQlpZihhcC0+bmV4dD09MCB8fCBhcC0+bmV4dC0+dHlwZT09JysnIHx8IGFwLT5u ZXh0LT50eXBlPT0nLScpCgkJCQlhID0gbGluZWFkZHIoMUwsIGEsIHNpZ24pOwoJCQlicmVhazsK CQlkZWZhdWx0OgoJCQlwYW5pYygiYWRkcmVzcyIpOwoJCQlyZXR1cm4gYTsKCQl9Cgl9d2hpbGUo YXAgPSBhcC0+bmV4dCk7CS8qIGFzc2lnbiA9ICovCglyZXR1cm4gYTsKfQoKdm9pZApuZXh0bWF0 Y2goRmlsZSAqZiwgU3RyaW5nICpyLCBQb3NuIHAsIGludCBzaWduKQp7Cgljb21waWxlKHIpOwoJ aWYoc2lnbiA+PSAwKXsKCQlpZighZXhlY3V0ZShmLCBwLCBJTkZJTklUWSkpCgkJCWVycm9yKEVz ZWFyY2gpOwoJCWlmKHNlbC5wWzBdLnAxPT1zZWwucFswXS5wMiAmJiBzZWwucFswXS5wMT09cCl7 CgkJCWlmKCsrcD5mLT5VLm5jKQoJCQkJcCA9IDA7CgkJCWlmKCFleGVjdXRlKGYsIHAsIElORklO SVRZKSkKCQkJCXBhbmljKCJhZGRyZXNzIik7CgkJfQoJfWVsc2V7CgkJaWYoIWJleGVjdXRlKGYs IHApKQoJCQllcnJvcihFc2VhcmNoKTsKCQlpZihzZWwucFswXS5wMT09c2VsLnBbMF0ucDIgJiYg c2VsLnBbMF0ucDI9PXApewoJCQlpZigtLXA8MCkKCQkJCXAgPSBmLT5VLm5jOwoJCQlpZighYmV4 ZWN1dGUoZiwgcCkpCgkJCQlwYW5pYygiYWRkcmVzcyIpOwoJCX0KCX0KfQoKRmlsZSAqCm1hdGNo ZmlsZShTdHJpbmcgKnIpCnsKCUZpbGUgKmY7CglGaWxlICptYXRjaCA9IDA7CglpbnQgaTsKCglm b3IoaSA9IDA7IGk8ZmlsZS5udXNlZDsgaSsrKXsKCQlmID0gZmlsZS5maWxlcHB0cltpXTsKCQlp ZihmID09IGNtZCkKCQkJY29udGludWU7CgkJaWYoZmlsZW1hdGNoKGYsIHIpKXsKCQkJaWYobWF0 Y2gpCgkJCQllcnJvcihFbWFueWZpbGVzKTsKCQkJbWF0Y2ggPSBmOwoJCX0KCX0KCWlmKCFtYXRj aCkKCQllcnJvcihFZnNlYXJjaCk7CglyZXR1cm4gbWF0Y2g7Cn0KCmludApmaWxlbWF0Y2goRmls ZSAqZiwgU3RyaW5nICpyKQp7CgljaGFyICpjLCBidWZbU1RSU0laRSsxMDBdOwoJU3RyaW5nICp0 OwoKCWMgPSBTdHJ0b2MoJmYtPm5hbWUpOwoJc3ByaW50KGJ1ZiwgIiVjJWMlYyAlc1xuIiwgIiAn IltmLT5tb2RdLAoJCSItKyJbZi0+cmFzcCE9MF0sICIgLiJbZj09Y3VyZmlsZV0sIGMpOwoJZnJl ZShjKTsKCXQgPSB0bXBjc3RyKGJ1Zik7CglTdHJkdXBsc3RyKCZnZW5zdHIsIHQpOwoJZnJlZXRt cHN0cih0KTsKCS8qIEEgbGl0dGxlIGRpcnR5Li4uICovCglpZihtZW51ID09IDApCgkJbWVudSA9 IGZpbGVvcGVuKCk7CglidWZyZXNldCgmbWVudS0+VSk7CglidWZpbnNlcnQoJm1lbnUtPlUsIDAs IGdlbnN0ci5zLCBnZW5zdHIubik7Cgljb21waWxlKHIpOwoJcmV0dXJuIGV4ZWN1dGUobWVudSwg MCwgbWVudS0+VS5uYyk7Cn0KCkFkZHJlc3MKY2hhcmFkZHIoUG9zbiBsLCBBZGRyZXNzIGFkZHIs IGludCBzaWduKQp7CglpZihzaWduID09IDApCgkJYWRkci5yLnAxID0gYWRkci5yLnAyID0gbDsK CWVsc2UgaWYoc2lnbiA8IDApCgkJYWRkci5yLnAyID0gYWRkci5yLnAxLT1sOwoJZWxzZSBpZihz aWduID4gMCkKCQlhZGRyLnIucDEgPSBhZGRyLnIucDIrPWw7CglpZihhZGRyLnIucDE8MCB8fCBh ZGRyLnIucDI+YWRkci5mLT5VLm5jKQoJCWVycm9yKEVyYW5nZSk7CglyZXR1cm4gYWRkcjsKfQoK QWRkcmVzcwpsaW5lYWRkcihQb3NuIGwsIEFkZHJlc3MgYWRkciwgaW50IHNpZ24pCnsKCWludCBu OwoJaW50IGM7CglGaWxlICpmID0gYWRkci5mOwoJQWRkcmVzcyBhOwoJUG9zbiBwOwoKCWEuZiA9 IGY7CglpZihzaWduID49IDApewoJCWlmKGwgPT0gMCl7CgkJCWlmKHNpZ249PTAgfHwgYWRkci5y LnAyPT0wKXsKCQkJCWEuci5wMSA9IGEuci5wMiA9IDA7CgkJCQlyZXR1cm4gYTsKCQkJfQoJCQlh LnIucDEgPSBhZGRyLnIucDI7CgkJCXAgPSBhZGRyLnIucDItMTsKCQl9ZWxzZXsKCQkJaWYoc2ln bj09MCB8fCBhZGRyLnIucDI9PTApewoJCQkJcCA9IChQb3NuKTA7CgkJCQluID0gMTsKCQkJfWVs c2V7CgkJCQlwID0gYWRkci5yLnAyLTE7CgkJCQluID0gZmlsZXJlYWRjKGYsIHArKyk9PSdcbic7 CgkJCX0KCQkJd2hpbGUobiA8IGwpewoJCQkJaWYocCA+PSBmLT5VLm5jKQoJCQkJCWVycm9yKEVy YW5nZSk7CgkJCQlpZihmaWxlcmVhZGMoZiwgcCsrKSA9PSAnXG4nKQoJCQkJCW4rKzsKCQkJfQoJ CQlhLnIucDEgPSBwOwoJCX0KCQl3aGlsZShwIDwgZi0+VS5uYyAmJiBmaWxlcmVhZGMoZiwgcCsr KSE9J1xuJykKCQkJOwoJCWEuci5wMiA9IHA7Cgl9ZWxzZXsKCQlwID0gYWRkci5yLnAxOwoJCWlm KGwgPT0gMCkKCQkJYS5yLnAyID0gYWRkci5yLnAxOwoJCWVsc2V7CgkJCWZvcihuID0gMDsgbjxs OyApewkvKiBhbHdheXMgcnVucyBvbmNlICovCgkJCQlpZihwID09IDApewoJCQkJCWlmKCsrbiAh PSBsKQoJCQkJCQllcnJvcihFcmFuZ2UpOwoJCQkJfWVsc2V7CgkJCQkJYyA9IGZpbGVyZWFkYyhm LCBwLTEpOwoJCQkJCWlmKGMgIT0gJ1xuJyB8fCArK24gIT0gbCkKCQkJCQkJcC0tOwoJCQkJfQoJ CQl9CgkJCWEuci5wMiA9IHA7CgkJCWlmKHAgPiAwKQoJCQkJcC0tOwoJCX0KCQl3aGlsZShwID4g MCAmJiBmaWxlcmVhZGMoZiwgcC0xKSE9J1xuJykJLyogbGluZXMgc3RhcnQgYWZ0ZXIgYSBuZXds aW5lICovCgkJCXAtLTsKCQlhLnIucDEgPSBwOwoJfQoJcmV0dXJuIGE7Cn0KAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHNhbTJrL3NhbS9idWZmLmMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAwMTAwNjQ0ADAwMDE3MzcAMDAwMDE1MQAwMDAwMDAxMjA2MwAwNzExMjA0MzAwNQAwMDE0NjIw ADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3 YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAI2luY2x1ZGUgInNhbS5oIgoKZW51bQp7CglTbG9wID0gMTAwIAkvKiBy b29tIHRvIGdyb3cgd2l0aCByZWFsbG9jYXRpb24gKi8KfTsKCnN0YXRpYwp2b2lkCnNpemVjYWNo ZShCdWZmZXIgKmIsIHVpbnQgbikKewoJaWYobiA8PSBiLT5jbWF4KQoJCXJldHVybjsKCWItPmNt YXggPSBuK1Nsb3A7CgliLT5jID0gcnVuZXJlYWxsb2MoYi0+YywgYi0+Y21heCk7Cn0KCnN0YXRp Ywp2b2lkCmFkZGJsb2NrKEJ1ZmZlciAqYiwgdWludCBpLCB1aW50IG4pCnsKCWlmKGkgPiBiLT5u YmwpCgkJcGFuaWMoImludGVybmFsIGVycm9yOiBhZGRibG9jayIpOwoKCWItPmJsID0gcmVhbGxv YyhiLT5ibCwgKGItPm5ibCsxKSpzaXplb2YgYi0+YmxbMF0pOwoJaWYoaSA8IGItPm5ibCkKCQlt ZW1tb3ZlKGItPmJsK2krMSwgYi0+YmwraSwgKGItPm5ibC1pKSpzaXplb2YoQmxvY2sqKSk7Cgli LT5ibFtpXSA9IGRpc2tuZXdibG9jayhkaXNrLCBuKTsKCWItPm5ibCsrOwp9CgpzdGF0aWMKdm9p ZApkZWxibG9jayhCdWZmZXIgKmIsIHVpbnQgaSkKewoJaWYoaSA+PSBiLT5uYmwpCgkJcGFuaWMo ImludGVybmFsIGVycm9yOiBkZWxibG9jayIpOwoKCWItPm5ibC0tOwoJZGlza3JlbGVhc2UoZGlz aywgYi0+YmxbaV0pOwoJaWYoaSA8IGItPm5ibCkKCQltZW1tb3ZlKGItPmJsK2ksIGItPmJsK2kr MSwgKGItPm5ibC1pKSpzaXplb2YoQmxvY2sqKSk7CgliLT5ibCA9IHJlYWxsb2MoYi0+YmwsIGIt Pm5ibCpzaXplb2YgYi0+YmxbMF0pOwp9CgovKgogKiBNb3ZlIGNhY2hlIHNvIGItPmNxIDw9IHEw IDwgYi0+Y3ErYi0+Y25jLgogKiBJZiBhdCB2ZXJ5IGVuZCwgcTAgd2lsbCBmYWxsIG9uIGVuZCBv ZiBjYWNoZSBibG9jay4KICovCgpzdGF0aWMKdm9pZApmbHVzaChCdWZmZXIgKmIpCnsKCWlmKGIt PmNkaXJ0eSB8fCBiLT5jbmM9PTApewoJCWlmKGItPmNuYyA9PSAwKQoJCQlkZWxibG9jayhiLCBi LT5jYmkpOwoJCWVsc2UKCQkJZGlza3dyaXRlKGRpc2ssICZiLT5ibFtiLT5jYmldLCBiLT5jLCBi LT5jbmMpOwoJCWItPmNkaXJ0eSA9IEZBTFNFOwoJfQp9CgpzdGF0aWMKdm9pZApzZXRjYWNoZShC dWZmZXIgKmIsIHVpbnQgcTApCnsKCUJsb2NrICoqYmxwLCAqYmw7Cgl1aW50IGksIHE7CgoJaWYo cTAgPiBiLT5uYykKCQlwYW5pYygiaW50ZXJuYWwgZXJyb3I6IHNldGNhY2hlIik7CgkvKgoJICog Zmx1c2ggYW5kIHJlbG9hZCBpZiBxMCBpcyBub3QgaW4gY2FjaGUuCgkgKi8KCWlmKGItPm5jID09 IDAgfHwgKGItPmNxPD1xMCAmJiBxMDxiLT5jcStiLT5jbmMpKQoJCXJldHVybjsKCS8qCgkgKiBp ZiBxMCBpcyBhdCBlbmQgb2YgZmlsZSBhbmQgZW5kIG9mIGNhY2hlLCBjb250aW51ZSB0byBncm93 IHRoaXMgYmxvY2sKCSAqLwoJaWYocTA9PWItPm5jICYmIHEwPT1iLT5jcStiLT5jbmMgJiYgYi0+ Y25jPD1NYXhibG9jaykKCQlyZXR1cm47CglmbHVzaChiKTsKCS8qIGZpbmQgYmxvY2sgKi8KCWlm KHEwIDwgYi0+Y3EpewoJCXEgPSAwOwoJCWkgPSAwOwoJfWVsc2V7CgkJcSA9IGItPmNxOwoJCWkg PSBiLT5jYmk7Cgl9CglibHAgPSAmYi0+YmxbaV07Cgl3aGlsZShxKygqYmxwKS0+VS5uIDw9IHEw ICYmIHErKCpibHApLT5VLm4gPCBiLT5uYyl7CgkJcSArPSAoKmJscCktPlUubjsKCQlpKys7CgkJ YmxwKys7CgkJaWYoaSA+PSBiLT5uYmwpCgkJCXBhbmljKCJibG9jayBub3QgZm91bmQiKTsKCX0K CWJsID0gKmJscDsKCS8qIHJlbWVtYmVyIHBvc2l0aW9uICovCgliLT5jYmkgPSBpOwoJYi0+Y3Eg PSBxOwoJc2l6ZWNhY2hlKGIsIGJsLT5VLm4pOwoJYi0+Y25jID0gYmwtPlUubjsKCS8qcmVhZCBi bG9jayovCglkaXNrcmVhZChkaXNrLCBibCwgYi0+YywgYi0+Y25jKTsKfQoKdm9pZApidWZpbnNl cnQoQnVmZmVyICpiLCB1aW50IHEwLCBSdW5lICpzLCB1aW50IG4pCnsKCXVpbnQgaSwgbSwgdCwg b2ZmOwoKCWlmKHEwID4gYi0+bmMpCgkJcGFuaWMoImludGVybmFsIGVycm9yOiBidWZpbnNlcnQi KTsKCgl3aGlsZShuID4gMCl7CgkJc2V0Y2FjaGUoYiwgcTApOwoJCW9mZiA9IHEwLWItPmNxOwoJ CWlmKGItPmNuYytuIDw9IE1heGJsb2NrKXsKCQkJLyogRXZlcnl0aGluZyBmaXRzIGluIG9uZSBi bG9jay4gKi8KCQkJdCA9IGItPmNuYytuOwoJCQltID0gbjsKCQkJaWYoYi0+YmwgPT0gbmlsKXsJ LyogYWxsb2NhdGUgKi8KCQkJCWlmKGItPmNuYyAhPSAwKQoJCQkJCXBhbmljKCJpbnRlcm5hbCBl cnJvcjogYnVmaW5zZXJ0MSBjbmMhPTAiKTsKCQkJCWFkZGJsb2NrKGIsIDAsIHQpOwoJCQkJYi0+ Y2JpID0gMDsKCQkJfQoJCQlzaXplY2FjaGUoYiwgdCk7CgkJCXJ1bmVtb3ZlKGItPmMrb2ZmK20s IGItPmMrb2ZmLCBiLT5jbmMtb2ZmKTsKCQkJcnVuZW1vdmUoYi0+YytvZmYsIHMsIG0pOwoJCQli LT5jbmMgPSB0OwoJCQlnb3RvIFRhaWw7CgkJfQoJCS8qCgkJICogV2UgbXVzdCBtYWtlIGEgbmV3 IGJsb2NrLiAgSWYgcTAgaXMgYXQKCQkgKiB0aGUgdmVyeSBiZWdpbm5pbmcgb3IgZW5kIG9mIHRo aXMgYmxvY2ssCgkJICoganVzdCBtYWtlIGEgbmV3IGJsb2NrIGFuZCBmaWxsIGl0LgoJCSAqLwoJ CWlmKHEwPT1iLT5jcSB8fCBxMD09Yi0+Y3ErYi0+Y25jKXsKCQkJaWYoYi0+Y2RpcnR5KQoJCQkJ Zmx1c2goYik7CgkJCW0gPSBtaW4obiwgTWF4YmxvY2spOwoJCQlpZihiLT5ibCA9PSBuaWwpewkv KiBhbGxvY2F0ZSAqLwoJCQkJaWYoYi0+Y25jICE9IDApCgkJCQkJcGFuaWMoImludGVybmFsIGVy cm9yOiBidWZpbnNlcnQyIGNuYyE9MCIpOwoJCQkJaSA9IDA7CgkJCX1lbHNlewoJCQkJaSA9IGIt PmNiaTsKCQkJCWlmKHEwID4gYi0+Y3EpCgkJCQkJaSsrOwoJCQl9CgkJCWFkZGJsb2NrKGIsIGks IG0pOwoJCQlzaXplY2FjaGUoYiwgbSk7CgkJCXJ1bmVtb3ZlKGItPmMsIHMsIG0pOwoJCQliLT5j cSA9IHEwOwoJCQliLT5jYmkgPSBpOwoJCQliLT5jbmMgPSBtOwoJCQlnb3RvIFRhaWw7CgkJfQoJ CS8qCgkJICogU3BsaXQgdGhlIGJsb2NrOyBjdXQgb2ZmIHRoZSByaWdodCBzaWRlIGFuZAoJCSAq IGxldCBnbyBvZiBpdC4KCQkgKi8KCQltID0gYi0+Y25jLW9mZjsKCQlpZihtID4gMCl7CgkJCWkg PSBiLT5jYmkrMTsKCQkJYWRkYmxvY2soYiwgaSwgbSk7CgkJCWRpc2t3cml0ZShkaXNrLCAmYi0+ YmxbaV0sIGItPmMrb2ZmLCBtKTsKCQkJYi0+Y25jIC09IG07CgkJfQoJCS8qCgkJICogTm93IGF0 IGVuZCBvZiBibG9jay4gIFRha2UgYXMgbXVjaCBpbnB1dAoJCSAqIGFzIHBvc3NpYmxlIGFuZCB0 YWNrIGl0IG9uIGVuZCBvZiBibG9jay4KCQkgKi8KCQltID0gbWluKG4sIE1heGJsb2NrLWItPmNu Yyk7CgkJc2l6ZWNhY2hlKGIsIGItPmNuYyttKTsKCQlydW5lbW92ZShiLT5jK2ItPmNuYywgcywg bSk7CgkJYi0+Y25jICs9IG07CiAgVGFpbDoKCQliLT5uYyArPSBtOwoJCXEwICs9IG07CgkJcyAr PSBtOwoJCW4gLT0gbTsKCQliLT5jZGlydHkgPSBUUlVFOwoJfQp9Cgp2b2lkCmJ1ZmRlbGV0ZShC dWZmZXIgKmIsIHVpbnQgcTAsIHVpbnQgcTEpCnsKCXVpbnQgbSwgbiwgb2ZmOwoKCWlmKCEocTA8 PXExICYmIHEwPD1iLT5uYyAmJiBxMTw9Yi0+bmMpKQoJCXBhbmljKCJpbnRlcm5hbCBlcnJvcjog YnVmZGVsZXRlIik7Cgl3aGlsZShxMSA+IHEwKXsKCQlzZXRjYWNoZShiLCBxMCk7CgkJb2ZmID0g cTAtYi0+Y3E7CgkJaWYocTEgPiBiLT5jcStiLT5jbmMpCgkJCW4gPSBiLT5jbmMgLSBvZmY7CgkJ ZWxzZQoJCQluID0gcTEtcTA7CgkJbSA9IGItPmNuYyAtIChvZmYrbik7CgkJaWYobSA+IDApCgkJ CXJ1bmVtb3ZlKGItPmMrb2ZmLCBiLT5jK29mZituLCBtKTsKCQliLT5jbmMgLT0gbjsKCQliLT5j ZGlydHkgPSBUUlVFOwoJCXExIC09IG47CgkJYi0+bmMgLT0gbjsKCX0KfQoKdWludApidWZsb2Fk KEJ1ZmZlciAqYiwgdWludCBxMCwgaW50IGZkLCBpbnQgKm51bGxzKQp7CgljaGFyICpwOwoJUnVu ZSAqcjsKCWludCBsLCBtLCBuLCBuYiwgbnI7Cgl1aW50IHExOwoKCWlmKHEwID4gYi0+bmMpCgkJ cGFuaWMoImludGVybmFsIGVycm9yOiBidWZsb2FkIik7CglwID0gbWFsbG9jKChNYXhibG9jaytV VEZtYXgrMSkqc2l6ZW9mIHBbMF0pOwoJaWYocCA9PSBuaWwpCgkJcGFuaWMoImJ1ZmxvYWQ6IG1h bGxvYyBmYWlsZWQiKTsKCXIgPSBydW5lbWFsbG9jKE1heGJsb2NrKTsKCW0gPSAwOwoJbiA9IDE7 CglxMSA9IHEwOwoJLyoKCSAqIEF0IHRvcCBvZiBsb29wLCBtYXkgaGF2ZSBtIGJ5dGVzIGxlZnQg b3ZlciBmcm9tCgkgKiBsYXN0IHBhc3MsIHBvc3NpYmx5IHJlcHJlc2VudGluZyBhIHBhcnRpYWwg cnVuZS4KCSAqLwoJd2hpbGUobiA+IDApewoJCW4gPSByZWFkKGZkLCBwK20sIE1heGJsb2NrKTsK CQlpZihuIDwgMCl7CgkJCWVycm9yKEVidWZsb2FkKTsKCQkJYnJlYWs7CgkJfQoJCW0gKz0gbjsK CQlwW21dID0gMDsKCQlsID0gbTsKCQlpZihuID4gMCkKCQkJbCAtPSBVVEZtYXg7CgkJY3Z0dG9y dW5lcyhwLCBsLCByLCAmbmIsICZuciwgbnVsbHMpOwoJCXJ1bmVtb3ZlKHAsIHArbmIsIG0tbmIp OwoJCW0gLT0gbmI7CgkJYnVmaW5zZXJ0KGIsIHExLCByLCBucik7CgkJcTEgKz0gbnI7Cgl9Cglm cmVlKHApOwoJZnJlZShyKTsKCXJldHVybiBxMS1xMDsKfQoKdm9pZApidWZyZWFkKEJ1ZmZlciAq YiwgdWludCBxMCwgUnVuZSAqcywgdWludCBuKQp7Cgl1aW50IG07CgoJaWYoIShxMDw9Yi0+bmMg JiYgcTArbjw9Yi0+bmMpKQoJCXBhbmljKCJidWZyZWFkOiBpbnRlcm5hbCBlcnJvciIpOwoKCXdo aWxlKG4gPiAwKXsKCQlzZXRjYWNoZShiLCBxMCk7CgkJbSA9IG1pbihuLCBiLT5jbmMtKHEwLWIt PmNxKSk7CgkJcnVuZW1vdmUocywgYi0+YysocTAtYi0+Y3EpLCBtKTsKCQlxMCArPSBtOwoJCXMg Kz0gbTsKCQluIC09IG07Cgl9Cn0KCnZvaWQKYnVmcmVzZXQoQnVmZmVyICpiKQp7CglpbnQgaTsK CgliLT5uYyA9IDA7CgliLT5jbmMgPSAwOwoJYi0+Y3EgPSAwOwoJYi0+Y2RpcnR5ID0gMDsKCWIt PmNiaSA9IDA7CgkvKiBkZWxldGUgYmFja3dhcmRzIHRvIGF2b2lkIG7CsiBiZWhhdmlvciAqLwoJ Zm9yKGk9Yi0+bmJsLTE7IC0taT49MDsgKQoJCWRlbGJsb2NrKGIsIGkpOwp9Cgp2b2lkCmJ1ZmNs b3NlKEJ1ZmZlciAqYikKewoJYnVmcmVzZXQoYik7CglmcmVlKGItPmMpOwoJYi0+YyA9IG5pbDsK CWItPmNuYyA9IDA7CglmcmVlKGItPmJsKTsKCWItPmJsID0gbmlsOwoJYi0+bmJsID0gMDsKfQoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHNhbTJrL3NhbS9jbWQuYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAw MDE3MzcAMDAwMDE1MQAwMDAwMDAyNDM0MwAwNzExMTYyMjEwNQAwMDE0NDUwADAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAw MDAwMDI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAI2luY2x1ZGUgInNhbS5oIgojaW5jbHVkZSAicGFyc2UuaCIKCnN0YXRpYyBjaGFyCWxpbmV4 W109IlxuIjsKc3RhdGljIGNoYXIJd29yZHhbXT0iIFx0XG4iOwpzdHJ1Y3QgY21kdGFiIGNtZHRh YltdPXsKLyoJY21kYwl0ZXh0CXJlZ2V4cAlhZGRyCWRlZmNtZAlkZWZhZGRyCWNvdW50CXRva2Vu CSBmbgkqLwoJJ1xuJywJMCwJMCwJMCwJMCwJYURvdCwJMCwJMCwJbmxfY21kLAoJJ2EnLAkxLAkw LAkwLAkwLAlhRG90LAkwLAkwLAlhX2NtZCwKCSdiJywJMCwJMCwJMCwJMCwJYU5vLAkwLAlsaW5l eCwJYl9jbWQsCgknQicsCTAsCTAsCTAsCTAsCWFObywJMCwJbGluZXgsCWJfY21kLAoJJ2MnLAkx LAkwLAkwLAkwLAlhRG90LAkwLAkwLAljX2NtZCwKCSdkJywJMCwJMCwJMCwJMCwJYURvdCwJMCwJ MCwJZF9jbWQsCgknRCcsCTAsCTAsCTAsCTAsCWFObywJMCwJbGluZXgsCURfY21kLAoJJ2UnLAkw LAkwLAkwLAkwLAlhTm8sCTAsCXdvcmR4LAllX2NtZCwKCSdmJywJMCwJMCwJMCwJMCwJYU5vLAkw LAl3b3JkeCwJZl9jbWQsCgknZycsCTAsCTEsCTAsCSdwJywJYURvdCwJMCwJMCwJZ19jbWQsCgkn aScsCTEsCTAsCTAsCTAsCWFEb3QsCTAsCTAsCWlfY21kLAoJJ2snLAkwLAkwLAkwLAkwLAlhRG90 LAkwLAkwLAlrX2NtZCwKCSdtJywJMCwJMCwJMSwJMCwJYURvdCwJMCwJMCwJbV9jbWQsCgknbics CTAsCTAsCTAsCTAsCWFObywJMCwJMCwJbl9jbWQsCgkncCcsCTAsCTAsCTAsCTAsCWFEb3QsCTAs CTAsCXBfY21kLAoJJ3EnLAkwLAkwLAkwLAkwLAlhTm8sCTAsCTAsCXFfY21kLAoJJ3InLAkwLAkw LAkwLAkwLAlhRG90LAkwLAl3b3JkeCwJZV9jbWQsCgkncycsCTAsCTEsCTAsCTAsCWFEb3QsCTEs CTAsCXNfY21kLAoJJ3QnLAkwLAkwLAkxLAkwLAlhRG90LAkwLAkwLAltX2NtZCwKCSd1JywJMCwJ MCwJMCwJMCwJYU5vLAkyLAkwLAl1X2NtZCwKCSd2JywJMCwJMSwJMCwJJ3AnLAlhRG90LAkwLAkw LAlnX2NtZCwKCSd3JywJMCwJMCwJMCwJMCwJYUFsbCwJMCwJd29yZHgsCXdfY21kLAoJJ3gnLAkw LAkxLAkwLAkncCcsCWFEb3QsCTAsCTAsCXhfY21kLAoJJ3knLAkwLAkxLAkwLAkncCcsCWFEb3Qs CTAsCTAsCXhfY21kLAoJJ1gnLAkwLAkxLAkwLAknZicsCWFObywJMCwJMCwJWF9jbWQsCgknWScs CTAsCTEsCTAsCSdmJywJYU5vLAkwLAkwLAlYX2NtZCwKCSchJywJMCwJMCwJMCwJMCwJYU5vLAkw LAlsaW5leCwJcGxhbjlfY21kLAoJJz4nLAkwLAkwLAkwLAkwLAlhRG90LAkwLAlsaW5leCwJcGxh bjlfY21kLAoJJzwnLAkwLAkwLAkwLAkwLAlhRG90LAkwLAlsaW5leCwJcGxhbjlfY21kLAoJJ3wn LAkwLAkwLAkwLAkwLAlhRG90LAkwLAlsaW5leCwJcGxhbjlfY21kLAoJJz0nLAkwLAkwLAkwLAkw LAlhRG90LAkwLAlsaW5leCwJZXFfY21kLAoJJ2MnfDB4MTAwLDAsCTAsCTAsCTAsCWFObywJMCwJ d29yZHgsCWNkX2NtZCwKCTAsCTAsCTAsCTAsCTAsCTAsCTAsCTAsCn07CkNtZAkqcGFyc2VjbWQo aW50KTsKQWRkcgkqY29tcG91bmRhZGRyKHZvaWQpOwpBZGRyCSpzaW1wbGVhZGRyKHZvaWQpOwp2 b2lkCWZyZWVjbWQodm9pZCk7CnZvaWQJb2tkZWxpbShpbnQpOwoKUnVuZQlsaW5lW0JMT0NLU0la RV07ClJ1bmUJdGVybWxpbmVbQkxPQ0tTSVpFXTsKUnVuZQkqbGluZXAgPSBsaW5lOwpSdW5lCSp0 ZXJtaW5wID0gdGVybWxpbmU7ClJ1bmUJKnRlcm1vdXRwID0gdGVybWxpbmU7Ckxpc3QJY21kbGlz dDsKTGlzdAlhZGRybGlzdDsKTGlzdAlyZWxpc3Q7Ckxpc3QJc3RyaW5nbGlzdDsKaW50CWVvZjsK CnZvaWQKcmVzZXRjbWQodm9pZCkKewoJbGluZXAgPSBsaW5lOwoJKmxpbmVwID0gMDsKCXRlcm1p bnAgPSB0ZXJtb3V0cCA9IHRlcm1saW5lOwoJZnJlZWNtZCgpOwp9CgppbnQKaW5wdXRjKHZvaWQp CnsKCWludCBuLCBuYnVmOwoJY2hhciBidWZbM107CglSdW5lIHI7CgogICAgQWdhaW46CgluYnVm ID0gMDsKCWlmKGRvd25sb2FkZWQpewoJCXdoaWxlKHRlcm1vdXRwID09IHRlcm1pbnApewoJCQlj bWR1cGRhdGUoKTsKCQkJaWYocGF0c2V0KQoJCQkJdGVsbHBhdCgpOwoJCQl3aGlsZSh0ZXJtbG9j a2VkID4gMCl7CgkJCQlvdXRUMChIdW5sb2NrKTsKCQkJCXRlcm1sb2NrZWQtLTsKCQkJfQoJCQlp ZihyY3YoKSA9PSAwKQoJCQkJcmV0dXJuIC0xOwoJCX0KCQlyID0gKnRlcm1vdXRwKys7CgkJaWYo dGVybW91dHAgPT0gdGVybWlucCkKCQkJdGVybWlucCA9IHRlcm1vdXRwID0gdGVybWxpbmU7Cgl9 ZWxzZXsKICAgCQlkb3sKCQkJbiA9IHJlYWQoMCwgYnVmK25idWYsIDEpOwoJCQlpZihuIDw9IDAp CgkJCQlyZXR1cm4gLTE7CgkJCW5idWYgKz0gbjsKCQl9d2hpbGUoIWZ1bGxydW5lKGJ1ZiwgbmJ1 ZikpOwoJCWNoYXJ0b3J1bmUoJnIsIGJ1Zik7Cgl9CglpZihyID09IDApewoJCXdhcm4oV251bGxz KTsKCQlnb3RvIEFnYWluOwoJfQoJcmV0dXJuIHI7Cn0KCmludAppbnB1dGxpbmUodm9pZCkKewoJ aW50IGksIGM7CgoJbGluZXAgPSBsaW5lOwoJaSA9IDA7Cglkb3sKCQlpZigoYyA9IGlucHV0Yygp KTw9MCkKCQkJcmV0dXJuIC0xOwoJCWlmKGkgPT0gKHNpemVvZiBsaW5lKS9SVU5FU0laRS0xKQoJ CQllcnJvcihFdG9vbG9uZyk7Cgl9d2hpbGUoKGxpbmVbaSsrXT1jKSAhPSAnXG4nKTsKCWxpbmVb aV0gPSAwOwoJcmV0dXJuIDE7Cn0KCmludApnZXRjaCh2b2lkKQp7CglpZihlb2YpCgkJcmV0dXJu IC0xOwoJaWYoKmxpbmVwPT0wICYmIGlucHV0bGluZSgpPDApewoJCWVvZiA9IFRSVUU7CgkJcmV0 dXJuIC0xOwoJfQoJcmV0dXJuICpsaW5lcCsrOwp9CgppbnQKbmV4dGModm9pZCkKewoJaWYoKmxp bmVwID09IDApCgkJcmV0dXJuIC0xOwoJcmV0dXJuICpsaW5lcDsKfQoKdm9pZAp1bmdldGNoKHZv aWQpCnsKCWlmKC0tbGluZXAgPCBsaW5lKQoJCXBhbmljKCJ1bmdldGNoIik7Cn0KClBvc24KZ2V0 bnVtKGludCBzaWdub2spCnsKCVBvc24gbj0wOwoJaW50IGMsIHNpZ247CgoJc2lnbiA9IDE7Cglp ZihzaWdub2s+MSAmJiBuZXh0YygpPT0nLScpewoJCXNpZ24gPSAtMTsKCQlnZXRjaCgpOwoJfQoJ aWYoKGM9bmV4dGMoKSk8JzAnIHx8ICc5JzxjKQkvKiBubyBudW1iZXIgZGVmYXVsdHMgdG8gMSAq LwoJCXJldHVybiBzaWduOwoJd2hpbGUoJzAnPD0oYz1nZXRjaCgpKSAmJiBjPD0nOScpCgkJbiA9 IG4qMTAgKyAoYy0nMCcpOwoJdW5nZXRjaCgpOwoJcmV0dXJuIHNpZ24qbjsKfQoKaW50CnNraXBi bCh2b2lkKQp7CglpbnQgYzsKCWRvCgkJYyA9IGdldGNoKCk7Cgl3aGlsZShjPT0nICcgfHwgYz09 J1x0Jyk7CglpZihjID49IDApCgkJdW5nZXRjaCgpOwoJcmV0dXJuIGM7Cn0KCnZvaWQKdGVybWNv bW1hbmQodm9pZCkKewoJUG9zbiBwOwoKCWZvcihwPWNtZHB0OyBwPGNtZC0+VS5uYzsgcCsrKXsK CQlpZih0ZXJtaW5wID49ICZ0ZXJtbGluZVtCTE9DS1NJWkVdKXsKCQkJY21kcHQgPSBjbWQtPlUu bmM7CgkJCWVycm9yKEV0b29sb25nKTsKCQl9CgkJKnRlcm1pbnArKyA9IGZpbGVyZWFkYyhjbWQs IHApOwoJfQoJY21kcHQgPSBjbWQtPlUubmM7Cn0KCnZvaWQKY21kbG9vcCh2b2lkKQp7CglDbWQg KmNtZHA7CglGaWxlICpvY3VyZmlsZTsKCWludCBsb2FkZWQ7CgoJZm9yKDs7KXsKCQlpZighZG93 bmxvYWRlZCAmJiBjdXJmaWxlICYmIGN1cmZpbGUtPnVucmVhZCkKCQkJbG9hZChjdXJmaWxlKTsK CQlpZigoY21kcCA9IHBhcnNlY21kKDApKT09MCl7CgkJCWlmKGRvd25sb2FkZWQpewoJCQkJcmVz Y3VlKCk7CgkJCQlleGl0cygiZW9mIik7CgkJCX0KCQkJYnJlYWs7CgkJfQoJCW9jdXJmaWxlID0g Y3VyZmlsZTsKCQlsb2FkZWQgPSBjdXJmaWxlICYmICFjdXJmaWxlLT51bnJlYWQ7CgkJaWYoY21k ZXhlYyhjdXJmaWxlLCBjbWRwKSA9PSAwKQoJCQlicmVhazsKCQlmcmVlY21kKCk7CgkJY21kdXBk YXRlKCk7CgkJdXBkYXRlKCk7CgkJaWYoZG93bmxvYWRlZCAmJiBjdXJmaWxlICYmCgkJICAgIChv Y3VyZmlsZSE9Y3VyZmlsZSB8fCAoIWxvYWRlZCAmJiAhY3VyZmlsZS0+dW5yZWFkKSkpCgkJCW91 dFRzKEhjdXJyZW50LCBjdXJmaWxlLT50YWcpOwoJCQkvKiBkb24ndCBhbGxvdyB0eXBlIGFoZWFk IG9uIGZpbGVzIHRoYXQgYXJlbid0IGJvdW5kICovCgkJaWYoZG93bmxvYWRlZCAmJiBjdXJmaWxl ICYmIGN1cmZpbGUtPnJhc3AgPT0gMCkKCQkJdGVybWlucCA9IHRlcm1vdXRwOwoJfQp9CgpDbWQg KgpuZXdjbWQodm9pZCl7CglDbWQgKnA7CgoJcCA9IGVtYWxsb2Moc2l6ZW9mKENtZCkpOwoJaW5z bGlzdCgmY21kbGlzdCwgY21kbGlzdC5udXNlZCwgKGxvbmcpcCk7CglyZXR1cm4gcDsKfQoKQWRk cioKbmV3YWRkcih2b2lkKQp7CglBZGRyICpwOwoKCXAgPSBlbWFsbG9jKHNpemVvZihBZGRyKSk7 CglpbnNsaXN0KCZhZGRybGlzdCwgYWRkcmxpc3QubnVzZWQsIChsb25nKXApOwoJcmV0dXJuIHA7 Cn0KClN0cmluZyoKbmV3cmUodm9pZCkKewoJU3RyaW5nICpwOwoKCXAgPSBlbWFsbG9jKHNpemVv ZihTdHJpbmcpKTsKCWluc2xpc3QoJnJlbGlzdCwgcmVsaXN0Lm51c2VkLCAobG9uZylwKTsKCVN0 cmluaXQocCk7CglyZXR1cm4gcDsKfQoKU3RyaW5nKgpuZXdzdHJpbmcodm9pZCkKewoJU3RyaW5n ICpwOwoKCXAgPSBlbWFsbG9jKHNpemVvZihTdHJpbmcpKTsKCWluc2xpc3QoJnN0cmluZ2xpc3Qs IHN0cmluZ2xpc3QubnVzZWQsIChsb25nKXApOwoJU3RyaW5pdChwKTsKCXJldHVybiBwOwp9Cgp2 b2lkCmZyZWVjbWQodm9pZCkKewoJaW50IGk7CgoJd2hpbGUoY21kbGlzdC5udXNlZCA+IDApCgkJ ZnJlZShjbWRsaXN0LnVjaGFycHB0clstLWNtZGxpc3QubnVzZWRdKTsKCXdoaWxlKGFkZHJsaXN0 Lm51c2VkID4gMCkKCQlmcmVlKGFkZHJsaXN0LnVjaGFycHB0clstLWFkZHJsaXN0Lm51c2VkXSk7 Cgl3aGlsZShyZWxpc3QubnVzZWQgPiAwKXsKCQlpID0gLS1yZWxpc3QubnVzZWQ7CgkJU3RyY2xv c2UocmVsaXN0LnN0cmluZ3BwdHJbaV0pOwoJCWZyZWUocmVsaXN0LnN0cmluZ3BwdHJbaV0pOwoJ fQoJd2hpbGUoc3RyaW5nbGlzdC5udXNlZD4wKXsKCQlpID0gLS1zdHJpbmdsaXN0Lm51c2VkOwoJ CVN0cmNsb3NlKHN0cmluZ2xpc3Quc3RyaW5ncHB0cltpXSk7CgkJZnJlZShzdHJpbmdsaXN0LnN0 cmluZ3BwdHJbaV0pOwoJfQp9CgppbnQKbG9va3VwKGludCBjKQp7CglpbnQgaTsKCglmb3IoaT0w OyBjbWR0YWJbaV0uY21kYzsgaSsrKQoJCWlmKGNtZHRhYltpXS5jbWRjID09IGMpCgkJCXJldHVy biBpOwoJcmV0dXJuIC0xOwp9Cgp2b2lkCm9rZGVsaW0oaW50IGMpCnsKCWlmKGM9PSdcXCcgfHwg KCdhJzw9YyAmJiBjPD0neicpCgl8fCAoJ0EnPD1jICYmIGM8PSdaJykgfHwgKCcwJzw9YyAmJiBj PD0nOScpKQoJCWVycm9yX2MoRWRlbGltLCBjKTsKfQoKdm9pZAphdG5sKHZvaWQpCnsKCXNraXBi bCgpOwoJaWYoZ2V0Y2goKSAhPSAnXG4nKQoJCWVycm9yKEVuZXdsaW5lKTsKfQoKdm9pZApnZXRy aHMoU3RyaW5nICpzLCBpbnQgZGVsaW0sIGludCBjbWQpCnsKCWludCBjOwoKCXdoaWxlKChjID0g Z2V0Y2goKSk+MCAmJiBjIT1kZWxpbSAmJiBjIT0nXG4nKXsKCQlpZihjID09ICdcXCcpewoJCQlp ZigoYz1nZXRjaCgpKSA8PSAwKQoJCQkJZXJyb3IoRWJhZHJocyk7CgkJCWlmKGMgPT0gJ1xuJyl7 CgkJCQl1bmdldGNoKCk7CgkJCQljPSdcXCc7CgkJCX1lbHNlIGlmKGMgPT0gJ24nKQoJCQkJYz0n XG4nOwoJCQllbHNlIGlmKGMhPWRlbGltICYmIChjbWQ9PSdzJyB8fCBjIT0nXFwnKSkJLyogcyBk b2VzIGl0cyBvd24gKi8KCQkJCVN0cmFkZGMocywgJ1xcJyk7CgkJfQoJCVN0cmFkZGMocywgYyk7 Cgl9Cgl1bmdldGNoKCk7CS8qIGxldCBjbGllbnQgcmVhZCB3aGV0aGVyIGRlbGltZXRlciwgJ1xu JyBvciB3aGF0ZXZlciAqLwp9CgpTdHJpbmcgKgpjb2xsZWN0dG9rZW4oY2hhciAqZW5kKQp7CglT dHJpbmcgKnMgPSBuZXdzdHJpbmcoKTsKCWludCBjOwoKCXdoaWxlKChjPW5leHRjKCkpPT0nICcg fHwgYz09J1x0JykKCQlTdHJhZGRjKHMsIGdldGNoKCkpOyAvKiBibGFua3Mgc2lnbmlmaWNhbnQg Zm9yIGdldG5hbWUoKSAqLwoJd2hpbGUoKGM9Z2V0Y2goKSk+MCAmJiB1dGZydW5lKGVuZCwgYyk9 PTApCgkJU3RyYWRkYyhzLCBjKTsKCVN0cmFkZGMocywgMCk7CglpZihjICE9ICdcbicpCgkJYXRu bCgpOwoJcmV0dXJuIHM7Cn0KClN0cmluZyAqCmNvbGxlY3R0ZXh0KHZvaWQpCnsKCVN0cmluZyAq cyA9IG5ld3N0cmluZygpOwoJaW50IGJlZ2xpbmUsIGksIGMsIGRlbGltOwoKCWlmKHNraXBibCgp PT0nXG4nKXsKCQlnZXRjaCgpOwoJCWkgPSAwOwoJCWRvewoJCQliZWdsaW5lID0gaTsKCQkJd2hp bGUoKGMgPSBnZXRjaCgpKT4wICYmIGMhPSdcbicpCgkJCQlpKyssIFN0cmFkZGMocywgYyk7CgkJ CWkrKywgU3RyYWRkYyhzLCAnXG4nKTsKCQkJaWYoYyA8IDApCgkJCQlnb3RvIFJldHVybjsKCQl9 d2hpbGUocy0+c1tiZWdsaW5lXSE9Jy4nIHx8IHMtPnNbYmVnbGluZSsxXSE9J1xuJyk7CgkJU3Ry ZGVsZXRlKHMsIHMtPm4tMiwgcy0+bik7Cgl9ZWxzZXsKCQlva2RlbGltKGRlbGltID0gZ2V0Y2go KSk7CgkJZ2V0cmhzKHMsIGRlbGltLCAnYScpOwoJCWlmKG5leHRjKCk9PWRlbGltKQoJCQlnZXRj aCgpOwoJCWF0bmwoKTsKCX0KICAgIFJldHVybjoKCVN0cmFkZGMocywgMCk7CQkvKiBKVVNUIEZP UiBDTURQUklOVCgpICovCglyZXR1cm4gczsKfQoKQ21kICoKcGFyc2VjbWQoaW50IG5lc3QpCnsK CWludCBpLCBjOwoJc3RydWN0IGNtZHRhYiAqY3Q7CglDbWQgKmNwLCAqbmNwOwoJQ21kIGNtZDsK CgljbWQubmV4dCA9IGNtZC5jY21kID0gMDsKCWNtZC5yZSA9IDA7CgljbWQuZmxhZyA9IGNtZC5u dW0gPSAwOwoJY21kLmFkZHIgPSBjb21wb3VuZGFkZHIoKTsKCWlmKHNraXBibCgpID09IC0xKQoJ CXJldHVybiAwOwoJaWYoKGM9Z2V0Y2goKSk9PS0xKQoJCXJldHVybiAwOwoJY21kLmNtZGMgPSBj OwoJaWYoY21kLmNtZGM9PSdjJyAmJiBuZXh0YygpPT0nZCcpewkvKiBzbGVhenkgdHdvLWNoYXJh Y3RlciBjYXNlICovCgkJZ2V0Y2goKTsJCS8qIHRoZSAnZCcgKi8KCQljbWQuY21kYz0nYyd8MHgx MDA7Cgl9CglpID0gbG9va3VwKGNtZC5jbWRjKTsKCWlmKGkgPj0gMCl7CgkJaWYoY21kLmNtZGMg PT0gJ1xuJykKCQkJZ290byBSZXR1cm47CS8qIGxldCBubF9jbWQgd29yayBpdCBhbGwgb3V0ICov CgkJY3QgPSAmY21kdGFiW2ldOwoJCWlmKGN0LT5kZWZhZGRyPT1hTm8gJiYgY21kLmFkZHIpCgkJ CWVycm9yKEVub2FkZHIpOwoJCWlmKGN0LT5jb3VudCkKCQkJY21kLm51bSA9IGdldG51bShjdC0+ Y291bnQpOwoJCWlmKGN0LT5yZWdleHApewoJCQkvKiB4IHdpdGhvdXQgcGF0dGVybiAtPiAuKlxu LCBpbmRpY2F0ZWQgYnkgY21kLnJlPT0wICovCgkJCS8qIFggd2l0aG91dCBwYXR0ZXJuIGlzIGFs bCBmaWxlcyAqLwoJCQlpZigoY3QtPmNtZGMhPSd4JyAmJiBjdC0+Y21kYyE9J1gnKSB8fAoJCQkg ICAoKGMgPSBuZXh0YygpKSE9JyAnICYmIGMhPSdcdCcgJiYgYyE9J1xuJykpewoJCQkJc2tpcGJs KCk7CgkJCQlpZigoYyA9IGdldGNoKCkpPT0nXG4nIHx8IGM8MCkKCQkJCQllcnJvcihFbm9wYXR0 ZXJuKTsKCQkJCW9rZGVsaW0oYyk7CgkJCQljbWQucmUgPSBnZXRyZWdleHAoYyk7CgkJCQlpZihj dC0+Y21kYyA9PSAncycpewoJCQkJCWNtZC5jdGV4dCA9IG5ld3N0cmluZygpOwoJCQkJCWdldHJo cyhjbWQuY3RleHQsIGMsICdzJyk7CgkJCQkJaWYobmV4dGMoKSA9PSBjKXsKCQkJCQkJZ2V0Y2go KTsKCQkJCQkJaWYobmV4dGMoKSA9PSAnZycpCgkJCQkJCQljbWQuZmxhZyA9IGdldGNoKCk7CgkJ CQkJfQoJCQkKCQkJCX0KCQkJfQoJCX0KCQlpZihjdC0+YWRkciAmJiAoY21kLmNhZGRyPXNpbXBs ZWFkZHIoKSk9PTApCgkJCWVycm9yKEVhZGRyZXNzKTsKCQlpZihjdC0+ZGVmY21kKXsKCQkJaWYo c2tpcGJsKCkgPT0gJ1xuJyl7CgkJCQlnZXRjaCgpOwoJCQkJY21kLmNjbWQgPSBuZXdjbWQoKTsK CQkJCWNtZC5jY21kLT5jbWRjID0gY3QtPmRlZmNtZDsKCQkJfWVsc2UgaWYoKGNtZC5jY21kID0g cGFyc2VjbWQobmVzdCkpPT0wKQoJCQkJcGFuaWMoImRlZmNtZCIpOwoJCX1lbHNlIGlmKGN0LT50 ZXh0KQoJCQljbWQuY3RleHQgPSBjb2xsZWN0dGV4dCgpOwoJCWVsc2UgaWYoY3QtPnRva2VuKQoJ CQljbWQuY3RleHQgPSBjb2xsZWN0dG9rZW4oY3QtPnRva2VuKTsKCQllbHNlCgkJCWF0bmwoKTsK CX1lbHNlCgkJc3dpdGNoKGNtZC5jbWRjKXsKCQljYXNlICd7JzoKCQkJY3AgPSAwOwoJCQlkb3sK CQkJCWlmKHNraXBibCgpPT0nXG4nKQoJCQkJCWdldGNoKCk7CgkJCQluY3AgPSBwYXJzZWNtZChu ZXN0KzEpOwoJCQkJaWYoY3ApCgkJCQkJY3AtPm5leHQgPSBuY3A7CgkJCQllbHNlCgkJCQkJY21k LmNjbWQgPSBuY3A7CgkJCX13aGlsZShjcCA9IG5jcCk7CgkJCWJyZWFrOwoJCWNhc2UgJ30nOgoJ CQlhdG5sKCk7CgkJCWlmKG5lc3Q9PTApCgkJCQllcnJvcihFbm9sYnJhY2UpOwoJCQlyZXR1cm4g MDsKCQlkZWZhdWx0OgoJCQllcnJvcl9jKEV1bmssIGNtZC5jbWRjKTsKCQl9CiAgICBSZXR1cm46 CgljcCA9IG5ld2NtZCgpOwoJKmNwID0gY21kOwoJcmV0dXJuIGNwOwp9CgpTdHJpbmcqCQkJCS8q IEJVR0dFUkVEICovCmdldHJlZ2V4cChpbnQgZGVsaW0pCnsKCVN0cmluZyAqciA9IG5ld3JlKCk7 CglpbnQgYzsKCglmb3IoU3RyemVybygmZ2Vuc3RyKTsgOyBTdHJhZGRjKCZnZW5zdHIsIGMpKQoJ CWlmKChjID0gZ2V0Y2goKSk9PSdcXCcpewoJCQlpZihuZXh0YygpPT1kZWxpbSkKCQkJCWMgPSBn ZXRjaCgpOwoJCQllbHNlIGlmKG5leHRjKCk9PSdcXCcpewoJCQkJU3RyYWRkYygmZ2Vuc3RyLCBj KTsKCQkJCWMgPSBnZXRjaCgpOwoJCQl9CgkJfWVsc2UgaWYoYz09ZGVsaW0gfHwgYz09J1xuJykK CQkJYnJlYWs7CglpZihjIT1kZWxpbSAmJiBjKQoJCXVuZ2V0Y2goKTsKCWlmKGdlbnN0ci5uID4g MCl7CgkJcGF0c2V0ID0gVFJVRTsKCQlTdHJkdXBsc3RyKCZsYXN0cGF0LCAmZ2Vuc3RyKTsKCQlT dHJhZGRjKCZsYXN0cGF0LCAnXDAnKTsKCX0KCWlmKGxhc3RwYXQubiA8PSAxKQoJCWVycm9yKEVw YXR0ZXJuKTsKCVN0cmR1cGxzdHIociwgJmxhc3RwYXQpOwoJcmV0dXJuIHI7Cn0KCkFkZHIgKgpz aW1wbGVhZGRyKHZvaWQpCnsKCUFkZHIgYWRkcjsKCUFkZHIgKmFwLCAqbmFwOwoKCWFkZHIubmV4 dCA9IDA7CglhZGRyLmxlZnQgPSAwOwoJc3dpdGNoKHNraXBibCgpKXsKCWNhc2UgJyMnOgoJCWFk ZHIudHlwZSA9IGdldGNoKCk7CgkJYWRkci5udW0gPSBnZXRudW0oMSk7CgkJYnJlYWs7CgljYXNl ICcwJzogY2FzZSAnMSc6IGNhc2UgJzInOiBjYXNlICczJzogY2FzZSAnNCc6CgljYXNlICc1Jzog Y2FzZSAnNic6IGNhc2UgJzcnOiBjYXNlICc4JzogY2FzZSAnOSc6IAoJCWFkZHIubnVtID0gZ2V0 bnVtKDEpOwoJCWFkZHIudHlwZT0nbCc7CgkJYnJlYWs7CgljYXNlICcvJzogY2FzZSAnPyc6IGNh c2UgJyInOgoJCWFkZHIuYXJlID0gZ2V0cmVnZXhwKGFkZHIudHlwZSA9IGdldGNoKCkpOwoJCWJy ZWFrOwoJY2FzZSAnLic6CgljYXNlICckJzoKCWNhc2UgJysnOgoJY2FzZSAnLSc6CgljYXNlICdc Jyc6CgkJYWRkci50eXBlID0gZ2V0Y2goKTsKCQlicmVhazsKCWRlZmF1bHQ6CgkJcmV0dXJuIDA7 Cgl9CglpZihhZGRyLm5leHQgPSBzaW1wbGVhZGRyKCkpCgkJc3dpdGNoKGFkZHIubmV4dC0+dHlw ZSl7CgkJY2FzZSAnLic6CgkJY2FzZSAnJCc6CgkJY2FzZSAnXCcnOgoJCQlpZihhZGRyLnR5cGUh PSciJykKCQljYXNlICciJzoKCQkJCWVycm9yKEVhZGRyZXNzKTsKCQkJYnJlYWs7CgkJY2FzZSAn bCc6CgkJY2FzZSAnIyc6CgkJCWlmKGFkZHIudHlwZT09JyInKQoJCQkJYnJlYWs7CgkJCS8qIGZh bGwgdGhyb3VnaCAqLwoJCWNhc2UgJy8nOgoJCWNhc2UgJz8nOgoJCQlpZihhZGRyLnR5cGUhPScr JyAmJiBhZGRyLnR5cGUhPSctJyl7CgkJCQkvKiBpbnNlcnQgdGhlIG1pc3NpbmcgJysnICovCgkJ CQluYXAgPSBuZXdhZGRyKCk7CgkJCQluYXAtPnR5cGU9JysnOwoJCQkJbmFwLT5uZXh0ID0gYWRk ci5uZXh0OwoJCQkJYWRkci5uZXh0ID0gbmFwOwoJCQl9CgkJCWJyZWFrOwoJCWNhc2UgJysnOgoJ CWNhc2UgJy0nOgoJCQlicmVhazsKCQlkZWZhdWx0OgoJCQlwYW5pYygic2ltcGxlYWRkciIpOwoJ CX0KCWFwID0gbmV3YWRkcigpOwoJKmFwID0gYWRkcjsKCXJldHVybiBhcDsKfQoKQWRkciAqCmNv bXBvdW5kYWRkcih2b2lkKQp7CglBZGRyIGFkZHI7CglBZGRyICphcCwgKm5leHQ7CgoJYWRkci5s ZWZ0ID0gc2ltcGxlYWRkcigpOwoJaWYoKGFkZHIudHlwZSA9IHNraXBibCgpKSE9JywnICYmIGFk ZHIudHlwZSE9JzsnKQoJCXJldHVybiBhZGRyLmxlZnQ7CglnZXRjaCgpOwoJbmV4dCA9IGFkZHIu bmV4dCA9IGNvbXBvdW5kYWRkcigpOwoJaWYobmV4dCAmJiAobmV4dC0+dHlwZT09JywnIHx8IG5l eHQtPnR5cGU9PSc7JykgJiYgbmV4dC0+bGVmdD09MCkKCQllcnJvcihFYWRkcmVzcyk7CglhcCA9 IG5ld2FkZHIoKTsKCSphcCA9IGFkZHI7CglyZXR1cm4gYXA7Cn0KAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2FtL2Rpc2suYwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDA0 MTQzADA3MTEyMDI0NDYxADAwMTQ2MzUAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSAic2FtLmgiCgpz dGF0aWMJQmxvY2sJKmJsaXN0OwoKI2lmZGVmIG5vdGRlZgpzdGF0aWMgaW50CnRlbXBkaXNrKHZv aWQpCnsKCWNoYXIgZGlyW0RJUkxFTl07CgljaGFyIGJ1ZlsxMjhdOwoJaW50IGksIGZkOwoKCXNw cmludChidWYsICIvdG1wL1glZC4lLjRzc2FtIiwgZ2V0cGlkKCksIGdldHVzZXIoKSk7Cglmb3Io aT0nQSc7IGk8PSdaJzsgaSsrKXsKCQlidWZbNV0gPSBpOwoJCWlmKHN0YXQoYnVmLCBkaXIpID09 IDApCgkJCWNvbnRpbnVlOwoJCWZkID0gY3JlYXRlKGJ1ZiwgT1JEV1J8T1JDTE9TRXxPQ0VYRUMs IDA2MDApOwoJCWlmKGZkID49IDApCgkJCXJldHVybiBmZDsKCX0KCXJldHVybiAtMTsKfQojZWxz ZQpleHRlcm4gaW50IHRlbXBkaXNrKHZvaWQpOyAvKiB1bml4LmMgKi8KI2VuZGlmCgpEaXNrKgpk aXNraW5pdCgpCnsKCURpc2sgKmQ7CgoJZCA9IGVtYWxsb2Moc2l6ZW9mKERpc2spKTsKCWQtPmZk ID0gdGVtcGRpc2soKTsKCWlmKGQtPmZkIDwgMCl7CgkJZnByaW50KDIsICJzYW06IGNhbid0IGNy ZWF0ZSB0ZW1wIGZpbGU6ICVyXG4iKTsKCQlleGl0cygiZGlza2luaXQiKTsKCX0KCXJldHVybiBk Owp9CgpzdGF0aWMKdWludApudG9zaXplKHVpbnQgbiwgdWludCAqaXApCnsKCXVpbnQgc2l6ZTsK CglpZihuID4gTWF4YmxvY2spCgkJcGFuaWMoImludGVybmFsIGVycm9yOiBudG9zaXplIik7Cglz aXplID0gbjsKCWlmKHNpemUgJiAoQmxvY2tpbmNyLTEpKQoJCXNpemUgKz0gQmxvY2tpbmNyIC0g KHNpemUgJiAoQmxvY2tpbmNyLTEpKTsKCS8qIGxhc3QgYnVja2V0IGhvbGRzIGJsb2NrcyBvZiBl eGFjdGx5IE1heGJsb2NrICovCglpZihpcCkKCQkqaXAgPSBzaXplL0Jsb2NraW5jcjsKCXJldHVy biBzaXplICogc2l6ZW9mKFJ1bmUpOwp9CgpCbG9jayoKZGlza25ld2Jsb2NrKERpc2sgKmQsIHVp bnQgbikKewoJdWludCBpLCBqLCBzaXplOwoJQmxvY2sgKmI7CgoJc2l6ZSA9IG50b3NpemUobiwg JmkpOwoJYiA9IGQtPmZyZWVbaV07CglpZihiKQoJCWQtPmZyZWVbaV0gPSBiLT5VLm5leHQ7Cgll bHNlewoJCS8qIGFsbG9jYXRlIGluIGNodW5rcyB0byByZWR1Y2UgbWFsbG9jIG92ZXJoZWFkICov CgkJaWYoYmxpc3QgPT0gbmlsKXsKCQkJYmxpc3QgPSBlbWFsbG9jKDEwMCpzaXplb2YoQmxvY2sp KTsKCQkJZm9yKGo9MDsgajwxMDAtMTsgaisrKQoJCQkJYmxpc3Rbal0uVS5uZXh0ID0gJmJsaXN0 W2orMV07CgkJfQoJCWIgPSBibGlzdDsKCQlibGlzdCA9IGItPlUubmV4dDsKCQliLT5hZGRyID0g ZC0+YWRkcjsKCQlkLT5hZGRyICs9IHNpemU7Cgl9CgliLT5VLm4gPSBuOwoJcmV0dXJuIGI7Cn0K CnZvaWQKZGlza3JlbGVhc2UoRGlzayAqZCwgQmxvY2sgKmIpCnsKCXVpbnQgaTsKCgludG9zaXpl KGItPlUubiwgJmkpOwoJYi0+VS5uZXh0ID0gZC0+ZnJlZVtpXTsKCWQtPmZyZWVbaV0gPSBiOwp9 Cgp2b2lkCmRpc2t3cml0ZShEaXNrICpkLCBCbG9jayAqKmJwLCBSdW5lICpyLCB1aW50IG4pCnsK CWludCBzaXplLCBuc2l6ZTsKCUJsb2NrICpiOwoKCWIgPSAqYnA7CglzaXplID0gbnRvc2l6ZShi LT5VLm4sIG5pbCk7Cgluc2l6ZSA9IG50b3NpemUobiwgbmlsKTsKCWlmKHNpemUgIT0gbnNpemUp ewoJCWRpc2tyZWxlYXNlKGQsIGIpOwoJCWIgPSBkaXNrbmV3YmxvY2soZCwgbik7CgkJKmJwID0g YjsKCX0KCWlmKHNlZWsoZC0+ZmQsIGItPmFkZHIsIDApIDwgMCkKCQlwYW5pYygic2VlayBlcnJv ciBpbiB0ZW1wIGZpbGUiKTsKCWlmKHdyaXRlKGQtPmZkLCByLCBuKnNpemVvZihSdW5lKSkgIT0g bipzaXplb2YoUnVuZSkpCgkJcGFuaWMoIndyaXRlIGVycm9yIHRvIHRlbXAgZmlsZSIpOwoJYi0+ VS5uID0gbjsKfQoKdm9pZApkaXNrcmVhZChEaXNrICpkLCBCbG9jayAqYiwgUnVuZSAqciwgdWlu dCBuKQp7CglpZihuID4gYi0+VS5uKQoJCXBhbmljKCJpbnRlcm5hbCBlcnJvcjogZGlza3JlYWQi KTsKCgludG9zaXplKGItPlUubiwgbmlsKTsKCWlmKHNlZWsoZC0+ZmQsIGItPmFkZHIsIDApIDwg MCkKCQlwYW5pYygic2VlayBlcnJvciBpbiB0ZW1wIGZpbGUiKTsKCWlmKHJlYWQoZC0+ZmQsIHIs IG4qc2l6ZW9mKFJ1bmUpKSAhPSBuKnNpemVvZihSdW5lKSkKCQlwYW5pYygicmVhZCBlcnJvciBm cm9tIHRlbXAgZmlsZSIpOwp9CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2FtL2Vycm9yLmMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDA0MTA1ADA3 MTExNjIyMTA1ADAwMTUwMzAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSAic2FtLmgiCgpzdGF0aWMg Y2hhciAqZW1zZ1tdPXsKCS8qIGVycm9yX3MgKi8KCSJjYW4ndCBvcGVuIiwKCSJjYW4ndCBjcmVh dGUiLAoJIm5vdCBpbiBtZW51OiIsCgkiY2hhbmdlcyB0byIsCgkiSS9PIGVycm9yOiIsCgkiY2Fu J3Qgd3JpdGUgd2hpbGUgY2hhbmdpbmc6IiwKCS8qIGVycm9yX2MgKi8KCSJ1bmtub3duIGNvbW1h bmQiLAoJIm5vIG9wZXJhbmQgZm9yIiwKCSJiYWQgZGVsaW1pdGVyIiwKCS8qIGVycm9yICovCgki Y2FuJ3QgZm9yayIsCgkiaW50ZXJydXB0IiwKCSJhZGRyZXNzIiwKCSJzZWFyY2giLAoJInBhdHRl cm4iLAoJIm5ld2xpbmUgZXhwZWN0ZWQiLAoJImJsYW5rIGV4cGVjdGVkIiwKCSJwYXR0ZXJuIGV4 cGVjdGVkIiwKCSJjYW4ndCBuZXN0IFggb3IgWSIsCgkidW5tYXRjaGVkIGB9JyIsCgkiY29tbWFu ZCB0YWtlcyBubyBhZGRyZXNzIiwKCSJhZGRyZXNzZXMgb3ZlcmxhcCIsCgkic3Vic3RpdHV0aW9u IiwKCSImIG1hdGNoIHRvbyBsb25nIiwKCSJiYWQgXFwgaW4gcmhzIiwKCSJhZGRyZXNzIHJhbmdl IiwKCSJjaGFuZ2VzIG5vdCBpbiBzZXF1ZW5jZSIsCgkiYWRkcmVzc2VzIG91dCBvZiBvcmRlciIs Cgkibm8gZmlsZSBuYW1lIiwKCSJ1bm1hdGNoZWQgYCgnIiwKCSJ1bm1hdGNoZWQgYCknIiwKCSJt YWxmb3JtZWQgYFtdJyIsCgkibWFsZm9ybWVkIHJlZ2V4cCIsCgkicmVnLiBleHAuIGxpc3Qgb3Zl cmZsb3ciLAoJInBsYW4gOSBjb21tYW5kIiwKCSJjYW4ndCBwaXBlIiwKCSJubyBjdXJyZW50IGZp bGUiLAoJInN0cmluZyB0b28gbG9uZyIsCgkiY2hhbmdlZCBmaWxlcyIsCgkiZW1wdHkgc3RyaW5n IiwKCSJmaWxlIHNlYXJjaCIsCgkibm9uLXVuaXF1ZSBtYXRjaCBmb3IgXCJcIiIsCgkidGFnIG1h dGNoIHRvbyBsb25nIiwKCSJ0b28gbWFueSBzdWJleHByZXNzaW9ucyIsCgkidGVtcG9yYXJ5IGZp bGUgdG9vIGxhcmdlIiwKCSJmaWxlIGlzIGFwcGVuZC1vbmx5IiwKCSJubyBkZXN0aW5hdGlvbiBm b3IgcGx1bWIgbWVzc2FnZSIsCgkiaW50ZXJuYWwgcmVhZCBlcnJvciBpbiBidWZmZXIgbG9hZCIs Cn07CnN0YXRpYyBjaGFyICp3bXNnW109ewoJLyogd2Fybl9zICovCgkiZHVwbGljYXRlIGZpbGUg bmFtZSIsCgkibm8gc3VjaCBmaWxlIiwKCSJ3cml0ZSBtaWdodCBjaGFuZ2UgZ29vZCB2ZXJzaW9u IG9mIiwKCS8qIHdhcm5fUyAqLwoJImZpbGVzIG1pZ2h0IGJlIGFsaWFzZWQiLAoJLyogd2FybiAq LwoJIm51bGwgY2hhcmFjdGVycyBlbGlkZWQiLAoJImNhbid0IHJ1biBwd2QiLAoJImxhc3QgY2hh ciBub3QgbmV3bGluZSIsCgkiZXhpdCBzdGF0dXMgbm90IDAiLAp9OwoKdm9pZAplcnJvcihFcnIg cykKewoJY2hhciBidWZbNTEyXTsKCglzcHJpbnQoYnVmLCAiPyVzIiwgZW1zZ1tzXSk7CgloaWNj b3VnaChidWYpOwp9Cgp2b2lkCmVycm9yX3MoRXJyIHMsIGNoYXIgKmEpCnsKCWNoYXIgYnVmWzUx Ml07CgoJc3ByaW50KGJ1ZiwgIj8lcyBcIiVzXCIiLCBlbXNnW3NdLCBhKTsKCWhpY2NvdWdoKGJ1 Zik7Cn0KCnZvaWQKZXJyb3JfYyhFcnIgcywgaW50IGMpCnsKCWNoYXIgYnVmWzUxMl07CgoJc3By aW50KGJ1ZiwgIj8lcyBgJUMnIiwgZW1zZ1tzXSwgYyk7CgloaWNjb3VnaChidWYpOwp9Cgp2b2lk Cndhcm4oV2FybiBzKQp7CglkcHJpbnQoIj93YXJuaW5nOiAlc1xuIiwgd21zZ1tzXSk7Cn0KCnZv aWQKd2Fybl9TKFdhcm4gcywgU3RyaW5nICphKQp7CglwcmludF9zKHdtc2dbc10sIGEpOwp9Cgp2 b2lkCndhcm5fU1MoV2FybiBzLCBTdHJpbmcgKmEsIFN0cmluZyAqYikKewoJcHJpbnRfc3Mod21z Z1tzXSwgYSwgYik7Cn0KCnZvaWQKd2Fybl9zKFdhcm4gcywgY2hhciAqYSkKewoJZHByaW50KCI/ d2FybmluZzogJXMgYCVzJ1xuIiwgd21zZ1tzXSwgYSk7Cn0KCnZvaWQKdGVybXdyaXRlKGNoYXIg KnMpCnsKCVN0cmluZyAqcDsKCglpZihkb3dubG9hZGVkKXsKCQlwID0gdG1wY3N0cihzKTsKCQlp ZihjbWQpCgkJCWxvZ2luc2VydChjbWQsIGNtZHB0LCBwLT5zLCBwLT5uKTsKCQllbHNlCgkJCVN0 cmluc2VydCgmY21kc3RyLCBwLCBjbWRzdHIubik7CgkJY21kcHRhZHYgKz0gcC0+bjsKCQlmcmVl KHApOwoJfWVsc2UKCQlXcml0ZSgyLCBzLCBzdHJsZW4ocykpOwp9CgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2FtL2Vycm9ycy5oAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDAxMjY3ADA3MTExNjM1 NjIwADAwMTUyMzQAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1 c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0eXBlZGVmIGVudW0gRXJyewoJLyogZXJyb3JfcyAq LwoJRW9wZW4sCglFY3JlYXRlLAoJRW1lbnUsCglFbW9kaWZpZWQsCglFaW8sCglFd3NlcSwKCS8q IGVycm9yX2MgKi8KCUV1bmssCglFbWlzc29wLAoJRWRlbGltLAoJLyogZXJyb3IgKi8KCUVmb3Jr LAoJRWludHIsCglFYWRkcmVzcywKCUVzZWFyY2gsCglFcGF0dGVybiwKCUVuZXdsaW5lLAoJRWJs YW5rLAoJRW5vcGF0dGVybiwKCUVuZXN0WFksCglFbm9sYnJhY2UsCglFbm9hZGRyLAoJRW92ZXJs YXAsCglFbm9zdWIsCglFbG9uZ3JocywKCUViYWRyaHMsCglFcmFuZ2UsCglFc2VxdWVuY2UsCglF b3JkZXIsCglFbm9uYW1lLAoJRWxlZnRwYXIsCglFcmlnaHRwYXIsCglFYmFkY2xhc3MsCglFYmFk cmVnZXhwLAoJRW92ZXJmbG93LAoJRW5vY21kLAoJRXBpcGUsCglFbm9maWxlLAoJRXRvb2xvbmcs CglFY2hhbmdlcywKCUVlbXB0eSwKCUVmc2VhcmNoLAoJRW1hbnlmaWxlcywKCUVsb25ndGFnLAoJ RXN1YmV4cCwKCUV0bXBvdmZsLAoJRWFwcGVuZCwKCUVjYW50cGx1bWIsCglFYnVmbG9hZCAKfUVy cjsKdHlwZWRlZiBlbnVtIFdhcm57CgkvKiB3YXJuX3MgKi8KCVdkdXBuYW1lLAoJV2ZpbGUsCglX ZGF0ZSwKCS8qIHdhcm5fc3MgKi8KCVdkdXBmaWxlLAoJLyogd2FybiAqLwoJV251bGxzLAoJV3B3 ZCwKCVdub3RuZXdsaW5lLAoJV2JhZHN0YXR1cyAKfVdhcm47CgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2FtL2ZpbGUuYwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDI1NTAyADA3MTExNjM1NzQy ADAwMTQ2MzUAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3Rh cgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSAic2FtLmgiCgovKgogKiBTdHJ1Y3R1cmUg b2YgVW5kbyBsaXN0OgogKiAJVGhlIFVuZG8gc3RydWN0dXJlIGZvbGxvd3MgYW55IGFzc29jaWF0 ZWQgZGF0YSwgc28gdGhlIGxpc3QKICoJY2FuIGJlIHJlYWQgYmFja3dhcmRzOiByZWFkIHRoZSBz dHJ1Y3R1cmUsIHRoZW4gcmVhZCB3aGF0ZXZlcgogKglkYXRhIGlzIGFzc29jaWF0ZWQgKGluc2Vy dCBzdHJpbmcsIGZpbGUgbmFtZSkgYW5kIHByZWNlZGVzIGl0LgogKglUaGUgc3RydWN0dXJlIGlu Y2x1ZGVzIHRoZSBwcmV2aW91cyB2YWx1ZSBvZiB0aGUgbW9kaWZ5IGJpdAogKglhbmQgYSBzZXF1 ZW5jZSBudW1iZXI7IHN1Y2Nlc3NpdmUgVW5kbyBzdHJ1Y3R1cmVzIHdpdGggdGhlCiAqCXNhbWUg c2VxdWVuY2UgbnVtYmVyIHJlcHJlc2VudCBzaW11bHRhbmVvdXMgY2hhbmdlcy4KICovCgp0eXBl ZGVmIHN0cnVjdCBVbmRvIFVuZG87CnR5cGVkZWYgc3RydWN0IE1lcmdlIE1lcmdlOwoKc3RydWN0 IFVuZG8KewoJc2hvcnQJdHlwZTsJCS8qIERlbGV0ZSwgSW5zZXJ0LCBGaWxlbmFtZSwgRG90LCBN YXJrICovCglzaG9ydAltb2Q7CQkvKiBtb2RpZnkgYml0ICovCgl1aW50CXNlcTsJCS8qIHNlcXVl bmNlIG51bWJlciAqLwoJdWludAlwMDsJCS8qIGxvY2F0aW9uIG9mIGNoYW5nZSAodW51c2VkIGlu IGYpICovCgl1aW50CW47CQkvKiAjIHJ1bmVzIGluIHN0cmluZyBvciBmaWxlIG5hbWUgKi8KfTsK CnN0cnVjdCBNZXJnZQp7CglGaWxlCSpmOwoJdWludAlzZXE7CQkvKiBvZiBsb2dnZWQgY2hhbmdl ICovCgl1aW50CXAwOwkJLyogbG9jYXRpb24gb2YgY2hhbmdlICh1bnVzZWQgaW4gZikgKi8KCXVp bnQJbjsJCS8qICMgcnVuZXMgdG8gZGVsZXRlICovCgl1aW50CW5idWY7CQkvKiAjIHJ1bmVzIHRv IGluc2VydCAqLwoJUnVuZQlidWZbUkJVRlNJWkVdOwp9OwoKZW51bQp7CglNYXhtZXJnZSA9IDUw LAoJVW5kb3NpemUgPSBzaXplb2YoVW5kbykvc2l6ZW9mKFJ1bmUpIAp9OwoKc3RhdGljIE1lcmdl CW1lcmdlOwoKRmlsZSoKZmlsZW9wZW4odm9pZCkKewoJRmlsZSAqZjsKCglmID0gZW1hbGxvYyhz aXplb2YoRmlsZSkpOwoJZi0+ZG90LmYgPSBmOwoJZi0+bmRvdC5mID0gZjsKCWYtPnNlcSA9IDA7 CglmLT5tb2QgPSBGQUxTRTsKCWYtPnVucmVhZCA9IFRSVUU7CglTdHJpbml0MCgmZi0+bmFtZSk7 CglyZXR1cm4gZjsKfQoKaW50CmZpbGVpc2RpcnR5KEZpbGUgKmYpCnsKCXJldHVybiBmLT5zZXEg IT0gZi0+Y2xlYW5zZXE7Cn0KCnN0YXRpYyB2b2lkCndyaW5zZXJ0KEJ1ZmZlciAqZGVsdGEsIGlu dCBzZXEsIGludCBtb2QsIHVpbnQgcDAsIFJ1bmUgKnMsIHVpbnQgbnMpCnsKCVVuZG8gdTsKCgl1 LnR5cGUgPSBJbnNlcnQ7Cgl1Lm1vZCA9IG1vZDsKCXUuc2VxID0gc2VxOwoJdS5wMCA9IHAwOwoJ dS5uID0gbnM7CglidWZpbnNlcnQoZGVsdGEsIGRlbHRhLT5uYywgcywgbnMpOwoJYnVmaW5zZXJ0 KGRlbHRhLCBkZWx0YS0+bmMsIChSdW5lKikmdSwgVW5kb3NpemUpOwp9CgpzdGF0aWMgdm9pZAp3 cmRlbGV0ZShCdWZmZXIgKmRlbHRhLCBpbnQgc2VxLCBpbnQgbW9kLCB1aW50IHAwLCB1aW50IHAx KQp7CglVbmRvIHU7CgoJdS50eXBlID0gRGVsZXRlOwoJdS5tb2QgPSBtb2Q7Cgl1LnNlcSA9IHNl cTsKCXUucDAgPSBwMDsKCXUubiA9IHAxIC0gcDA7CglidWZpbnNlcnQoZGVsdGEsIGRlbHRhLT5u YywgKFJ1bmUqKSZ1LCBVbmRvc2l6ZSk7Cn0KCnZvaWQKZmx1c2htZXJnZSh2b2lkKQp7CglGaWxl ICpmOwoKCWYgPSBtZXJnZS5mOwoJaWYoZiA9PSBuaWwpCgkJcmV0dXJuOwoJaWYobWVyZ2Uuc2Vx ICE9IGYtPnNlcSkKCQlwYW5pYygiZmx1c2htZXJnZSBzZXEgbWlzbWF0Y2giKTsKCWlmKG1lcmdl Lm4gIT0gMCkKCQl3cmRlbGV0ZSgmZi0+ZXBzaWxvbiwgZi0+c2VxLCBUUlVFLCBtZXJnZS5wMCwg bWVyZ2UucDArbWVyZ2Uubik7CglpZihtZXJnZS5uYnVmICE9IDApCgkJd3JpbnNlcnQoJmYtPmVw c2lsb24sIGYtPnNlcSwgVFJVRSwgbWVyZ2UucDArbWVyZ2UubiwgbWVyZ2UuYnVmLCBtZXJnZS5u YnVmKTsKCW1lcmdlLmYgPSBuaWw7CgltZXJnZS5uID0gMDsKCW1lcmdlLm5idWYgPSAwOwp9Cgp2 b2lkCm1lcmdlZXh0ZW5kKEZpbGUgKmYsIHVpbnQgcDApCnsKCXVpbnQgbXAwbjsKCgltcDBuID0g bWVyZ2UucDArbWVyZ2UubjsKCWlmKG1wMG4gIT0gcDApewoJCWJ1ZnJlYWQoJmYtPlUsIG1wMG4s IG1lcmdlLmJ1ZittZXJnZS5uYnVmLCBwMC1tcDBuKTsKCQltZXJnZS5uYnVmICs9IHAwLW1wMG47 CgkJbWVyZ2UubiA9IHAwLW1lcmdlLnAwOwoJfQp9CgovKgogKiBsaWtlIGZpbGV1bmRlbGV0ZSwg YnV0IGdldCB0aGUgZGF0YSBmcm9tIGFyZ3VtZW50cwogKi8Kdm9pZApsb2dpbnNlcnQoRmlsZSAq ZiwgdWludCBwMCwgUnVuZSAqcywgdWludCBucykKewoJaWYoZi0+cmVzY3VpbmcpCgkJcmV0dXJu OwoJaWYobnMgPT0gMCkKCQlyZXR1cm47CglpZihuczwwIHx8IG5zPlNUUlNJWkUpCgkJcGFuaWMo ImxvZ2luc2VydCIpOwoJaWYoZi0+c2VxIDwgc2VxKQoJCWZpbGVtYXJrKGYpOwoJaWYocDAgPCBm LT5oaXBvc24pCgkJZXJyb3IoRXNlcXVlbmNlKTsKCglpZihtZXJnZS5mICE9IGYKCXx8IHAwLSht ZXJnZS5wMCttZXJnZS5uKT5NYXhtZXJnZQkJCS8qIHRvbyBmYXIgKi8KCXx8IG1lcmdlLm5idWYr KChwMCtucyktKG1lcmdlLnAwK21lcmdlLm4pKT5SQlVGU0laRSkJLyogdG9vIGxvbmcgKi8KCQlm bHVzaG1lcmdlKCk7CgoJaWYobnM+PVJCVUZTSVpFKXsKCQlpZighKG1lcmdlLm4gPT0gMCAmJiBt ZXJnZS5uYnVmID09IDAgJiYgbWVyZ2UuZiA9PSBuaWwpKQoJCQlwYW5pYygibG9naW5zZXJ0IGJh ZCBtZXJnZSBzdGF0ZSIpOwoJCXdyaW5zZXJ0KCZmLT5lcHNpbG9uLCBmLT5zZXEsIFRSVUUsIHAw LCBzLCBucyk7Cgl9ZWxzZXsKCQlpZihtZXJnZS5mICE9IGYpewoJCQltZXJnZS5mID0gZjsKCQkJ bWVyZ2UucDAgPSBwMDsKCQkJbWVyZ2Uuc2VxID0gZi0+c2VxOwoJCX0KCQltZXJnZWV4dGVuZChm LCBwMCk7CgoJCS8qIGFwcGVuZCBzdHJpbmcgdG8gbWVyZ2UgKi8KCQlydW5lbW92ZShtZXJnZS5i dWYrbWVyZ2UubmJ1ZiwgcywgbnMpOwoJCW1lcmdlLm5idWYgKz0gbnM7Cgl9CgoJZi0+aGlwb3Nu ID0gcDA7CglpZighZi0+dW5yZWFkICYmICFmLT5tb2QpCgkJc3RhdGUoZiwgRGlydHkpOwp9Cgp2 b2lkCmxvZ2RlbGV0ZShGaWxlICpmLCB1aW50IHAwLCB1aW50IHAxKQp7CglpZihmLT5yZXNjdWlu ZykKCQlyZXR1cm47CglpZihwMCA9PSBwMSkKCQlyZXR1cm47CglpZihmLT5zZXEgPCBzZXEpCgkJ ZmlsZW1hcmsoZik7CglpZihwMSA8IGYtPmhpcG9zbikKCQllcnJvcihFc2VxdWVuY2UpOwoKCWlm KG1lcmdlLmYgIT0gZgoJfHwgcDAtKG1lcmdlLnAwK21lcmdlLm4pPk1heG1lcmdlCQkJLyogdG9v IGZhciAqLwoJfHwgbWVyZ2UubmJ1ZisocDAtKG1lcmdlLnAwK21lcmdlLm4pKT5SQlVGU0laRSl7 CS8qIHRvbyBsb25nICovCgkJZmx1c2htZXJnZSgpOwoJCW1lcmdlLmYgPSBmOwoJCW1lcmdlLnAw ID0gcDA7CgkJbWVyZ2Uuc2VxID0gZi0+c2VxOwoJfQoKCW1lcmdlZXh0ZW5kKGYsIHAwKTsKCgkv KiBhZGQgdG8gZGVsZXRpb24gKi8KCW1lcmdlLm4gPSBwMS1tZXJnZS5wMDsKCglmLT5oaXBvc24g PSBwMTsKCWlmKCFmLT51bnJlYWQgJiYgIWYtPm1vZCkKCQlzdGF0ZShmLCBEaXJ0eSk7Cn0KCi8q CiAqIGxpa2UgZmlsZXVuc2V0bmFtZSwgYnV0IGdldCB0aGUgZGF0YSBmcm9tIGFyZ3VtZW50cwog Ki8Kdm9pZApsb2dzZXRuYW1lKEZpbGUgKmYsIFN0cmluZyAqcykKewoJVW5kbyB1OwoJQnVmZmVy ICpkZWx0YTsKCglpZihmLT5yZXNjdWluZykKCQlyZXR1cm47CgoJaWYoZi0+dW5yZWFkKXsJLyog VGhpcyBpcyBzZXR0aW5nIGluaXRpYWwgZmlsZSBuYW1lICovCgkJZmlsZXNldG5hbWUoZiwgcyk7 CgkJcmV0dXJuOwoJfQoKCWlmKGYtPnNlcSA8IHNlcSkKCQlmaWxlbWFyayhmKTsKCgkvKiB1bmRv IGEgZmlsZSBuYW1lIGNoYW5nZSBieSByZXN0b3Jpbmcgb2xkIG5hbWUgKi8KCWRlbHRhID0gJmYt PmVwc2lsb247Cgl1LnR5cGUgPSBGaWxlbmFtZTsKCXUubW9kID0gVFJVRTsKCXUuc2VxID0gZi0+ c2VxOwoJdS5wMCA9IDA7CS8qIHVudXNlZCAqLwoJdS5uID0gcy0+bjsKCWlmKHMtPm4pCgkJYnVm aW5zZXJ0KGRlbHRhLCBkZWx0YS0+bmMsIHMtPnMsIHMtPm4pOwoJYnVmaW5zZXJ0KGRlbHRhLCBk ZWx0YS0+bmMsIChSdW5lKikmdSwgVW5kb3NpemUpOwoJaWYoIWYtPnVucmVhZCAmJiAhZi0+bW9k KQoJCXN0YXRlKGYsIERpcnR5KTsKfQoKI2lmZGVmIE5PVEVYVApGaWxlKgpmaWxlYWRkdGV4dChG aWxlICpmLCBUZXh0ICp0KQp7CglpZihmID09IG5pbCl7CgkJZiA9IGVtYWxsb2Moc2l6ZW9mKEZp bGUpKTsKCQlmLT51bnJlYWQgPSBUUlVFOwoJfQoJZi0+dGV4dCA9IHJlYWxsb2MoZi0+dGV4dCwg KGYtPm50ZXh0KzEpKnNpemVvZihUZXh0KikpOwoJZi0+dGV4dFtmLT5udGV4dCsrXSA9IHQ7Cglm LT5jdXJ0ZXh0ID0gdDsKCXJldHVybiBmOwp9Cgp2b2lkCmZpbGVkZWx0ZXh0KEZpbGUgKmYsIFRl eHQgKnQpCnsKCWludCBpOwoKCWZvcihpPTA7IGk8Zi0+bnRleHQ7IGkrKykKCQlpZihmLT50ZXh0 W2ldID09IHQpCgkJCWdvdG8gRm91bmQ7CglwYW5pYygiY2FuJ3QgZmluZCB0ZXh0IGluIGZpbGVk ZWx0ZXh0Iik7CgogICAgRm91bmQ6CglmLT5udGV4dC0tOwoJaWYoZi0+bnRleHQgPT0gMCl7CgkJ ZmlsZWNsb3NlKGYpOwoJCXJldHVybjsKCX0KCW1lbW1vdmUoZi0+dGV4dCtpLCBmLT50ZXh0K2kr MSwgKGYtPm50ZXh0LWkpKnNpemVvZihUZXh0KikpOwoJaWYoZi0+Y3VydGV4dCA9PSB0KQoJCWYt PmN1cnRleHQgPSBmLT50ZXh0WzBdOwp9CiNlbmRpZgoKdm9pZApmaWxlaW5zZXJ0KEZpbGUgKmYs IHVpbnQgcDAsIFJ1bmUgKnMsIHVpbnQgbnMpCnsKCWlmKHAwID4gZi0+VS5uYykKCQlwYW5pYygi aW50ZXJuYWwgZXJyb3I6IGZpbGVpbnNlcnQiKTsKCWlmKGYtPnNlcSA+IDApCgkJZmlsZXVuaW5z ZXJ0KGYsICZmLT5kZWx0YSwgcDAsIG5zKTsKCWJ1Zmluc2VydCgmZi0+VSwgcDAsIHMsIG5zKTsK CWlmKG5zKQoJCWYtPm1vZCA9IFRSVUU7Cn0KCnZvaWQKZmlsZXVuaW5zZXJ0KEZpbGUgKmYsIEJ1 ZmZlciAqZGVsdGEsIHVpbnQgcDAsIHVpbnQgbnMpCnsKCVVuZG8gdTsKCgkvKiB1bmRvIGFuIGlu c2VydGlvbiBieSBkZWxldGluZyAqLwoJdS50eXBlID0gRGVsZXRlOwoJdS5tb2QgPSBmLT5tb2Q7 Cgl1LnNlcSA9IGYtPnNlcTsKCXUucDAgPSBwMDsKCXUubiA9IG5zOwoJYnVmaW5zZXJ0KGRlbHRh LCBkZWx0YS0+bmMsIChSdW5lKikmdSwgVW5kb3NpemUpOwp9Cgp2b2lkCmZpbGVkZWxldGUoRmls ZSAqZiwgdWludCBwMCwgdWludCBwMSkKewoJaWYoIShwMDw9cDEgJiYgcDA8PWYtPlUubmMgJiYg cDE8PWYtPlUubmMpKQoJCXBhbmljKCJpbnRlcm5hbCBlcnJvcjogZmlsZWRlbGV0ZSIpOwoJaWYo Zi0+c2VxID4gMCkKCQlmaWxldW5kZWxldGUoZiwgJmYtPmRlbHRhLCBwMCwgcDEpOwoJYnVmZGVs ZXRlKCZmLT5VLCBwMCwgcDEpOwoJaWYocDEgPiBwMCkKCQlmLT5tb2QgPSBUUlVFOwp9Cgp2b2lk CmZpbGV1bmRlbGV0ZShGaWxlICpmLCBCdWZmZXIgKmRlbHRhLCB1aW50IHAwLCB1aW50IHAxKQp7 CglVbmRvIHU7CglSdW5lICpidWY7Cgl1aW50IGksIG47CgoJLyogdW5kbyBhIGRlbGV0aW9uIGJ5 IGluc2VydGluZyAqLwoJdS50eXBlID0gSW5zZXJ0OwoJdS5tb2QgPSBmLT5tb2Q7Cgl1LnNlcSA9 IGYtPnNlcTsKCXUucDAgPSBwMDsKCXUubiA9IHAxLXAwOwoJYnVmID0gZmJ1ZmFsbG9jKCk7Cglm b3IoaT1wMDsgaTxwMTsgaSs9bil7CgkJbiA9IHAxIC0gaTsKCQlpZihuID4gUkJVRlNJWkUpCgkJ CW4gPSBSQlVGU0laRTsKCQlidWZyZWFkKCZmLT5VLCBpLCBidWYsIG4pOwoJCWJ1Zmluc2VydChk ZWx0YSwgZGVsdGEtPm5jLCBidWYsIG4pOwoJfQoJZmJ1ZmZyZWUoYnVmKTsKCWJ1Zmluc2VydChk ZWx0YSwgZGVsdGEtPm5jLCAoUnVuZSopJnUsIFVuZG9zaXplKTsKCn0KCmludApmaWxlcmVhZGMo RmlsZSAqZiwgdWludCBxKQp7CglSdW5lIHI7CgoJaWYocSA+PSBmLT5VLm5jKQoJCXJldHVybiAt MTsKCWJ1ZnJlYWQoJmYtPlUsIHEsICZyLCAxKTsKCXJldHVybiByOwp9Cgp2b2lkCmZpbGVzZXRu YW1lKEZpbGUgKmYsIFN0cmluZyAqcykKewoJaWYoIWYtPnVucmVhZCkJLyogVGhpcyBpcyBzZXR0 aW5nIGluaXRpYWwgZmlsZSBuYW1lICovCgkJZmlsZXVuc2V0bmFtZShmLCAmZi0+ZGVsdGEpOwoJ U3RyZHVwbHN0cigmZi0+bmFtZSwgcyk7Cglzb3J0bmFtZShmKTsKCWYtPnVucmVhZCA9IFRSVUU7 Cn0KCnZvaWQKZmlsZXVuc2V0bmFtZShGaWxlICpmLCBCdWZmZXIgKmRlbHRhKQp7CglTdHJpbmcg czsKCVVuZG8gdTsKCgkvKiB1bmRvIGEgZmlsZSBuYW1lIGNoYW5nZSBieSByZXN0b3Jpbmcgb2xk IG5hbWUgKi8KCXUudHlwZSA9IEZpbGVuYW1lOwoJdS5tb2QgPSBmLT5tb2Q7Cgl1LnNlcSA9IGYt PnNlcTsKCXUucDAgPSAwOwkvKiB1bnVzZWQgKi8KCVN0cmluaXQoJnMpOwoJU3RyZHVwbHN0cigm cywgJmYtPm5hbWUpOwoJZnVsbG5hbWUoJnMpOwoJdS5uID0gcy5uOwoJaWYocy5uKQoJCWJ1Zmlu c2VydChkZWx0YSwgZGVsdGEtPm5jLCBzLnMsIHMubik7CglidWZpbnNlcnQoZGVsdGEsIGRlbHRh LT5uYywgKFJ1bmUqKSZ1LCBVbmRvc2l6ZSk7CglTdHJjbG9zZSgmcyk7Cn0KCnZvaWQKZmlsZXVu c2V0ZG90KEZpbGUgKmYsIEJ1ZmZlciAqZGVsdGEsIFJhbmdlIGRvdCkKewoJVW5kbyB1OwoKCXUu dHlwZSA9IERvdDsKCXUubW9kID0gZi0+bW9kOwoJdS5zZXEgPSBmLT5zZXE7Cgl1LnAwID0gZG90 LnAxOwoJdS5uID0gZG90LnAyIC0gZG90LnAxOwoJYnVmaW5zZXJ0KGRlbHRhLCBkZWx0YS0+bmMs IChSdW5lKikmdSwgVW5kb3NpemUpOwp9Cgp2b2lkCmZpbGV1bnNldG1hcmsoRmlsZSAqZiwgQnVm ZmVyICpkZWx0YSwgUmFuZ2UgbWFyaykKewoJVW5kbyB1OwoKCXUudHlwZSA9IE1hcms7Cgl1Lm1v ZCA9IGYtPm1vZDsKCXUuc2VxID0gZi0+c2VxOwoJdS5wMCA9IG1hcmsucDE7Cgl1Lm4gPSBtYXJr LnAyIC0gbWFyay5wMTsKCWJ1Zmluc2VydChkZWx0YSwgZGVsdGEtPm5jLCAoUnVuZSopJnUsIFVu ZG9zaXplKTsKfQoKdWludApmaWxlbG9hZChGaWxlICpmLCB1aW50IHAwLCBpbnQgZmQsIGludCAq bnVsbHMpCnsKCWlmKGYtPnNlcSA+IDApCgkJcGFuaWMoInVuZG8gaW4gZmlsZS5sb2FkIHVuaW1w bGVtZW50ZWQiKTsKCXJldHVybiBidWZsb2FkKCZmLT5VLCBwMCwgZmQsIG51bGxzKTsKfQoKaW50 CmZpbGV1cGRhdGUoRmlsZSAqZiwgaW50IG5vdHJhbnMsIGludCB0b3Rlcm0pCnsKCXVpbnQgcDEs IHAyOwoJaW50IG1vZDsKCglpZihmLT5yZXNjdWluZykKCQlyZXR1cm4gRkFMU0U7CgoJZmx1c2ht ZXJnZSgpOwoKCS8qCgkgKiBmaXggdGhlIG1vZGlmaWNhdGlvbiBiaXQKCSAqIHN1YnRsZSBwb2lu dDogZG9uJ3Qgc2F2ZSBpdCBhd2F5IGluIHRoZSBsb2cuCgkgKgoJICogaWYgYW5vdGhlciBjaGFu Z2UgaXMgbWFkZSwgdGhlIGNvcnJlY3QgZi0+bW9kCgkgKiBzdGF0ZSBpcyBzYXZlZCAgaW4gdGhl IHVuZG8gbG9nIGJ5IGZpbGVtYXJrCgkgKiB3aGVuIHNldHRpbmcgdGhlIGRvdCBhbmQgbWFyay4K CSAqCgkgKiBpZiB0aGUgY2hhbmdlIGlzIHVuZG9uZSwgdGhlIGNvcnJlY3Qgc3RhdGUgaXMKCSAq IHNhdmVkIGZyb20gZiBpbiB0aGUgZmlsZXVuLi4uIHJvdXRpbmVzLgoJICovCgltb2QgPSBmLT5t b2Q7CglmLT5tb2QgPSBmLT5wcmV2bW9kOwoJaWYoZiA9PSBjbWQpCgkJbm90cmFucyA9IFRSVUU7 CgllbHNlewoJCWZpbGV1bnNldGRvdChmLCAmZi0+ZGVsdGEsIGYtPnByZXZkb3QpOwoJCWZpbGV1 bnNldG1hcmsoZiwgJmYtPmRlbHRhLCBmLT5wcmV2bWFyayk7Cgl9CglmLT5kb3QgPSBmLT5uZG90 OwoJZmlsZXVuZG8oZiwgRkFMU0UsICFub3RyYW5zLCAmcDEsICZwMiwgdG90ZXJtKTsKCWYtPm1v ZCA9IG1vZDsKCglpZihmLT5kZWx0YS5uYyA9PSAwKQoJCWYtPnNlcSA9IDA7CgoJaWYoZiA9PSBj bWQpCgkJcmV0dXJuIEZBTFNFOwoKCWlmKGYtPm1vZCl7CgkJZi0+Y2xvc2VvayA9IDA7CgkJcXVp dG9rID0gMDsKCX1lbHNlCgkJZi0+Y2xvc2VvayA9IDE7CglyZXR1cm4gVFJVRTsKfQoKbG9uZwpw cmV2c2VxKEJ1ZmZlciAqYikKewoJVW5kbyB1OwoJdWludCB1cDsKCgl1cCA9IGItPm5jOwoJaWYo dXAgPT0gMCkKCQlyZXR1cm4gMDsKCXVwIC09IFVuZG9zaXplOwoJYnVmcmVhZChiLCB1cCwgKFJ1 bmUqKSZ1LCBVbmRvc2l6ZSk7CglyZXR1cm4gdS5zZXE7Cn0KCmxvbmcKdW5kb3NlcShGaWxlICpm LCBpbnQgaXN1bmRvKQp7CglpZihpc3VuZG8pCgkJcmV0dXJuIGYtPnNlcTsKCglyZXR1cm4gcHJl dnNlcSgmZi0+ZXBzaWxvbik7Cn0KCnZvaWQKZmlsZXVuZG8oRmlsZSAqZiwgaW50IGlzdW5kbywg aW50IGNhbnJlZG8sIHVpbnQgKnEwcCwgdWludCAqcTFwLCBpbnQgZmxhZykKewoJVW5kbyB1OwoJ UnVuZSAqYnVmOwoJdWludCBpLCBuLCB1cDsKCXVpbnQgc3RvcDsKCUJ1ZmZlciAqZGVsdGEsICpl cHNpbG9uOwoKCWlmKGlzdW5kbyl7CgkJLyogdW5kbzsgcmV2ZXJzZSBkZWx0YSBvbnRvIGVwc2ls b24sIHNlcSBkZWNyZWFzZXMgKi8KCQlkZWx0YSA9ICZmLT5kZWx0YTsKCQllcHNpbG9uID0gJmYt PmVwc2lsb247CgkJc3RvcCA9IGYtPnNlcTsKCX1lbHNlewoJCS8qIHJlZG87IHJldmVyc2UgZXBz aWxvbiBvbnRvIGRlbHRhLCBzZXEgaW5jcmVhc2VzICovCgkJZGVsdGEgPSAmZi0+ZXBzaWxvbjsK CQllcHNpbG9uID0gJmYtPmRlbHRhOwoJCXN0b3AgPSAwOwkvKiBkb24ndCBrbm93IHlldCAqLwoJ fQoKCXJhc3BzdGFydChmKTsKCXdoaWxlKGRlbHRhLT5uYyA+IDApewoJCXVwID0gZGVsdGEtPm5j LVVuZG9zaXplOwoJCWJ1ZnJlYWQoZGVsdGEsIHVwLCAoUnVuZSopJnUsIFVuZG9zaXplKTsKCQlp Zihpc3VuZG8pewoJCQlpZih1LnNlcSA8IHN0b3ApewoJCQkJZi0+c2VxID0gdS5zZXE7CgkJCQly YXNwZG9uZShmLCBmbGFnKTsKCQkJCXJldHVybjsKCQkJfQoJCX1lbHNlewoJCQlpZihzdG9wID09 IDApCgkJCQlzdG9wID0gdS5zZXE7CgkJCWlmKHUuc2VxID4gc3RvcCl7CgkJCQlyYXNwZG9uZShm LCBmbGFnKTsKCQkJCXJldHVybjsKCQkJfQoJCX0KCQlzd2l0Y2godS50eXBlKXsKCQlkZWZhdWx0 OgoJCQlwYW5pYygidW5kbyB1bmtub3duIHUudHlwZSIpOwoJCQlicmVhazsKCgkJY2FzZSBEZWxl dGU6CgkJCWYtPnNlcSA9IHUuc2VxOwoJCQlpZihjYW5yZWRvKQoJCQkJZmlsZXVuZGVsZXRlKGYs IGVwc2lsb24sIHUucDAsIHUucDArdS5uKTsKCQkJZi0+bW9kID0gdS5tb2Q7CgkJCWJ1ZmRlbGV0 ZSgmZi0+VSwgdS5wMCwgdS5wMCt1Lm4pOwoJCQlyYXNwZGVsZXRlKGYsIHUucDAsIHUucDArdS5u LCBmbGFnKTsKCQkJKnEwcCA9IHUucDA7CgkJCSpxMXAgPSB1LnAwOwoJCQlicmVhazsKCgkJY2Fz ZSBJbnNlcnQ6CgkJCWYtPnNlcSA9IHUuc2VxOwoJCQlpZihjYW5yZWRvKQoJCQkJZmlsZXVuaW5z ZXJ0KGYsIGVwc2lsb24sIHUucDAsIHUubik7CgkJCWYtPm1vZCA9IHUubW9kOwoJCQl1cCAtPSB1 Lm47CgkJCWJ1ZiA9IGZidWZhbGxvYygpOwoJCQlmb3IoaT0wOyBpPHUubjsgaSs9bil7CgkJCQlu ID0gdS5uIC0gaTsKCQkJCWlmKG4gPiBSQlVGU0laRSkKCQkJCQluID0gUkJVRlNJWkU7CgkJCQli dWZyZWFkKGRlbHRhLCB1cCtpLCBidWYsIG4pOwoJCQkJYnVmaW5zZXJ0KCZmLT5VLCB1LnAwK2ks IGJ1Ziwgbik7CgkJCQlyYXNwaW5zZXJ0KGYsIHUucDAraSwgYnVmLCBuLCBmbGFnKTsKCQkJfQoJ CQlmYnVmZnJlZShidWYpOwoJCQkqcTBwID0gdS5wMDsKCQkJKnExcCA9IHUucDArdS5uOwoJCQli cmVhazsKCgkJY2FzZSBGaWxlbmFtZToKCQkJZi0+c2VxID0gdS5zZXE7CgkJCWlmKGNhbnJlZG8p CgkJCQlmaWxldW5zZXRuYW1lKGYsIGVwc2lsb24pOwoJCQlmLT5tb2QgPSB1Lm1vZDsKCQkJdXAg LT0gdS5uOwoKCQkJU3RyaW5zdXJlKCZmLT5uYW1lLCB1Lm4rMSk7CgkJCWJ1ZnJlYWQoZGVsdGEs IHVwLCBmLT5uYW1lLnMsIHUubik7CgkJCWYtPm5hbWUuc1t1Lm5dID0gMDsKCQkJZi0+bmFtZS5u ID0gdS5uOwoJCQlmaXhuYW1lKCZmLT5uYW1lKTsKCQkJc29ydG5hbWUoZik7CgkJCWJyZWFrOwoJ CWNhc2UgRG90OgoJCQlmLT5zZXEgPSB1LnNlcTsKCQkJaWYoY2FucmVkbykKCQkJCWZpbGV1bnNl dGRvdChmLCBlcHNpbG9uLCBmLT5kb3Qucik7CgkJCWYtPm1vZCA9IHUubW9kOwoJCQlmLT5kb3Qu ci5wMSA9IHUucDA7CgkJCWYtPmRvdC5yLnAyID0gdS5wMCArIHUubjsKCQkJYnJlYWs7CgkJY2Fz ZSBNYXJrOgoJCQlmLT5zZXEgPSB1LnNlcTsKCQkJaWYoY2FucmVkbykKCQkJCWZpbGV1bnNldG1h cmsoZiwgZXBzaWxvbiwgZi0+bWFyayk7CgkJCWYtPm1vZCA9IHUubW9kOwoJCQlmLT5tYXJrLnAx ID0gdS5wMDsKCQkJZi0+bWFyay5wMiA9IHUucDAgKyB1Lm47CgkJCWJyZWFrOwoJCX0KCQlidWZk ZWxldGUoZGVsdGEsIHVwLCBkZWx0YS0+bmMpOwoJfQoJaWYoaXN1bmRvKQoJCWYtPnNlcSA9IDA7 CglyYXNwZG9uZShmLCBmbGFnKTsKfQoKdm9pZApmaWxlcmVzZXQoRmlsZSAqZikKewoJYnVmcmVz ZXQoJmYtPmRlbHRhKTsKCWJ1ZnJlc2V0KCZmLT5lcHNpbG9uKTsKCWYtPnNlcSA9IDA7Cn0KCnZv aWQKZmlsZWNsb3NlKEZpbGUgKmYpCnsKCVN0cmNsb3NlKCZmLT5uYW1lKTsKCWJ1ZmNsb3NlKCZm LT5VKTsKCWJ1ZmNsb3NlKCZmLT5kZWx0YSk7CglidWZjbG9zZSgmZi0+ZXBzaWxvbik7CglpZihm LT5yYXNwKQoJCWxpc3RmcmVlKGYtPnJhc3ApOwoJZnJlZShmKTsKfQoKdm9pZApmaWxlbWFyayhG aWxlICpmKQp7CgoJaWYoZi0+dW5yZWFkKQoJCXJldHVybjsKCWlmKGYtPmVwc2lsb24ubmMpCgkJ YnVmZGVsZXRlKCZmLT5lcHNpbG9uLCAwLCBmLT5lcHNpbG9uLm5jKTsKCglpZihmICE9IGNtZCl7 CgkJZi0+cHJldmRvdCA9IGYtPmRvdC5yOwoJCWYtPnByZXZtYXJrID0gZi0+bWFyazsKCQlmLT5w cmV2c2VxID0gZi0+c2VxOwoJCWYtPnByZXZtb2QgPSBmLT5tb2Q7Cgl9CgoJZi0+bmRvdCA9IGYt PmRvdDsKCWYtPnNlcSA9IHNlcTsKCWYtPmhpcG9zbiA9IDA7Cn0KYW5pYygiaW50ZXJuYWwgZXJy b3I6IGZpbGVpbnNlcnQiKTsKCWlmKGYtPnNlcSA+IDApCgkJZmlsZXVuaW5zZXJ0KGYsICZmLT5k ZWx0YSwgcDAsIG5zKTsKCWJ1Zmluc2VydCgmZi0+VSwgcDAsIHMsIG5zKTsKCWlmKG5zKQoJCWYt Pm1vZCA9IFRSVUU7Cn0KCnZvaWQKZmlsZXVuaW5zZXJ0KEZpbGUgKmYsIEJ1ZmZlciAqZGVsdGEs IHNhbTJrL3NhbS9pby5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDE3 MzcAMDAwMDE1MQAwMDAwMDAxMDU0MwAwNzExMTYzMTU2NQAwMDE0MzIzADAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAw MDI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA I2luY2x1ZGUgInNhbS5oIgoKI2RlZmluZQlOU1lTRklMRQkzCiNkZWZpbmUJTk9GSUxFCQkxMjgK CnZvaWQKY2hlY2txaWQoRmlsZSAqZikKewoJaW50IGksIHc7CglGaWxlICpnOwoKCXcgPSB3aGlj aG1lbnUoZik7Cglmb3IoaT0xOyBpPGZpbGUubnVzZWQ7IGkrKyl7CgkJZyA9IGZpbGUuZmlsZXBw dHJbaV07CgkJaWYodyA9PSBpKQoJCQljb250aW51ZTsKCQlpZihmLT5kZXY9PWctPmRldiAmJiBm LT5xaWRwYXRoPT1nLT5xaWRwYXRoKQoJCQl3YXJuX1NTKFdkdXBmaWxlLCAmZi0+bmFtZSwgJmct Pm5hbWUpOwoJfQp9Cgp2b2lkCndyaXRlZihGaWxlICpmKQp7CglQb3NuIG47CgljaGFyICpuYW1l OwoJaW50IGksIHNhbWVuYW1lLCBuZXdmaWxlOwoJdWxvbmcgZGV2LCBxaWQ7Cglsb25nIG10aW1l LCBhcHBlbmRvbmx5LCBsZW5ndGg7CgoJbmV3ZmlsZSA9IDA7CglzYW1lbmFtZSA9IFN0cmNtcCgm Z2Vuc3RyLCAmZi0+bmFtZSkgPT0gMDsKCW5hbWUgPSBTdHJ0b2MoJmYtPm5hbWUpOwoJaSA9IHN0 YXRmaWxlKG5hbWUsICZkZXYsICZxaWQsICZtdGltZSwgMCwgMCk7CglpZihpID09IC0xKQoJCW5l d2ZpbGUrKzsKCWVsc2UgaWYoc2FtZW5hbWUgJiYKCSAgICAgICAgKGYtPmRldiE9ZGV2IHx8IGYt PnFpZHBhdGghPXFpZCB8fCBmLT5tdGltZTxtdGltZSkpewoJCWYtPmRldiA9IGRldjsKCQlmLT5x aWRwYXRoID0gcWlkOwoJCWYtPm10aW1lID0gbXRpbWU7CgkJd2Fybl9TKFdkYXRlLCAmZ2Vuc3Ry KTsKCQlyZXR1cm47Cgl9CglpZihnZW5jKQoJCWZyZWUoZ2VuYyk7CglnZW5jID0gU3RydG9jKCZn ZW5zdHIpOwoJaWYoZi0+c2VxID09IHNlcSkKCQllcnJvcl9zKEV3c2VxLCBnZW5jKTsKCWlmKChp bz1jcmVhdGUoZ2VuYywgMSwgMDY2NkwpKSA8IDApCgkJZXJyb3JfcyhFY3JlYXRlLCBnZW5jKTsK CWRwcmludCgiJXM6ICIsIGdlbmMpOwoJaWYoc3RhdGZkKGlvLCAwLCAwLCAwLCAmbGVuZ3RoLCAm YXBwZW5kb25seSkgPiAwICYmIGFwcGVuZG9ubHkgJiYgbGVuZ3RoPjApCgkJZXJyb3IoRWFwcGVu ZCk7CgluID0gd3JpdGVpbyhmKTsKCWlmKGYtPm5hbWUuc1swXT09MCB8fCBzYW1lbmFtZSl7CgkJ aWYoYWRkci5yLnAxPT0wICYmIGFkZHIuci5wMj09Zi0+VS5uYykKCQkJZi0+Y2xlYW5zZXEgPSBm LT5zZXE7CgkJc3RhdGUoZiwgZi0+Y2xlYW5zZXE9PWYtPnNlcT8gQ2xlYW4gOiBEaXJ0eSk7Cgl9 CglpZihuZXdmaWxlKQoJCWRwcmludCgiKG5ldyBmaWxlKSAiKTsKCWlmKGFkZHIuci5wMj4wICYm IGZpbGVyZWFkYyhmLCBhZGRyLnIucDItMSkhPSdcbicpCgkJd2FybihXbm90bmV3bGluZSk7Cglj bG9zZWlvKG4pOwoJaWYoZi0+bmFtZS5zWzBdPT0wIHx8IHNhbWVuYW1lKXsKCQlpZihzdGF0Zmls ZShuYW1lLCAmZGV2LCAmcWlkLCAmbXRpbWUsIDAsIDApID4gMCl7CgkJCWYtPmRldiA9IGRldjsK CQkJZi0+cWlkcGF0aCA9IHFpZDsKCQkJZi0+bXRpbWUgPSBtdGltZTsKCQkJY2hlY2txaWQoZik7 CgkJfQoJfQp9CgpQb3NuCnJlYWRpbyhGaWxlICpmLCBpbnQgKm51bGxzLCBpbnQgc2V0ZGF0ZSwg aW50IHRvdGVybSkKewoJaW50IG4sIGIsIHc7CglSdW5lICpyOwoJUG9zbiBudDsKCVBvc24gcCA9 IGFkZHIuci5wMjsKCXVsb25nIGRldiwgcWlkOwoJbG9uZyBtdGltZTsKCWNoYXIgYnVmW0JMT0NL U0laRSsxXSwgKnM7CgoJKm51bGxzID0gRkFMU0U7CgliID0gMDsKCWlmKGYtPnVucmVhZCl7CgkJ bnQgPSBidWZsb2FkKCZmLT5VLCAwLCBpbywgbnVsbHMpOwoJCWlmKHRvdGVybSkKCQkJcmFzcGxv YWQoZik7Cgl9ZWxzZQoJCWZvcihudCA9IDA7IChuID0gcmVhZChpbywgYnVmK2IsIEJMT0NLU0la RS1iKSk+MDsgbnQrPShyLWdlbmJ1ZikpewoJCQluICs9IGI7CgkJCWIgPSAwOwoJCQlyID0gZ2Vu YnVmOwoJCQlzID0gYnVmOwoJCQl3aGlsZShuID4gMCl7CgkJCQlpZigoKnIgPSAqKHVjaGFyKilz KSA8IFJ1bmVzZWxmKXsKCQkJCQlpZigqcikKCQkJCQkJcisrOwoJCQkJCWVsc2UKCQkJCQkJKm51 bGxzID0gVFJVRTsKCQkJCQktLW47CgkJCQkJcysrOwoJCQkJCWNvbnRpbnVlOwoJCQkJfQoJCQkJ aWYoZnVsbHJ1bmUocywgbikpewoJCQkJCXcgPSBjaGFydG9ydW5lKHIsIHMpOwoJCQkJCWlmKCpy KQoJCQkJCQlyKys7CgkJCQkJZWxzZQoJCQkJCQkqbnVsbHMgPSBUUlVFOwoJCQkJCW4gLT0gdzsK CQkJCQlzICs9IHc7CgkJCQkJY29udGludWU7CgkJCQl9CgkJCQliID0gbjsKCQkJCW1lbW1vdmUo YnVmLCBzLCBiKTsKCQkJCWJyZWFrOwoJCQl9CgkJCWxvZ2luc2VydChmLCBwLCBnZW5idWYsIHIt Z2VuYnVmKTsKCQl9CglpZihiKQoJCSpudWxscyA9IFRSVUU7CglpZigqbnVsbHMpCgkJd2FybihX bnVsbHMpOwoJaWYoc2V0ZGF0ZSl7CgkJaWYoc3RhdGZkKGlvLCAmZGV2LCAmcWlkLCAmbXRpbWUs IDAsIDApID4gMCl7CgkJCWYtPmRldiA9IGRldjsKCQkJZi0+cWlkcGF0aCA9IHFpZDsKCQkJZi0+ bXRpbWUgPSBtdGltZTsKCQkJY2hlY2txaWQoZik7CgkJfQoJfQoJcmV0dXJuIG50Owp9CgpQb3Nu CndyaXRlaW8oRmlsZSAqZikKewoJaW50IG0sIG47CglQb3NuIHAgPSBhZGRyLnIucDE7CgljaGFy ICpjOwoKCXdoaWxlKHAgPCBhZGRyLnIucDIpewoJCWlmKGFkZHIuci5wMi1wPkJMT0NLU0laRSkK CQkJbiA9IEJMT0NLU0laRTsKCQllbHNlCgkJCW4gPSBhZGRyLnIucDItcDsKCQlidWZyZWFkKCZm LT5VLCBwLCBnZW5idWYsIG4pOwoJCWMgPSBTdHJ0b2ModG1wcnN0cihnZW5idWYsIG4pKTsKCQlt ID0gc3RybGVuKGMpOwoJCWlmKFdyaXRlKGlvLCBjLCBtKSAhPSBtKXsKCQkJZnJlZShjKTsKCQkJ aWYocCA+IDApCgkJCQlwICs9IG47CgkJCWJyZWFrOwoJCX0KCQlmcmVlKGMpOwoJCXAgKz0gbjsK CX0KCXJldHVybiBwLWFkZHIuci5wMTsKfQp2b2lkCmNsb3NlaW8oUG9zbiBwKQp7CgljbG9zZShp byk7CglpbyA9IDA7CglpZihwID49IDApCgkJZHByaW50KCIjJWx1ZFxuIiwgcCk7Cn0KCmludAly ZW1vdGVmZDAgPSAwOwppbnQJcmVtb3RlZmQxID0gMTsKCnZvaWQKYm9vdHRlcm0oY2hhciAqbWFj aGluZSwgY2hhciAqKmFyZ3YsIGNoYXIgKiplbmQpCnsKCWludCBwaDJ0WzJdLCBwdDJoWzJdOwoK CWlmKG1hY2hpbmUpewoJCWR1cChyZW1vdGVmZDAsIDApOwoJCWR1cChyZW1vdGVmZDEsIDEpOwoJ CWNsb3NlKHJlbW90ZWZkMCk7CgkJY2xvc2UocmVtb3RlZmQxKTsKCQlhcmd2WzBdID0gInNhbXRl cm0iOwoJCSplbmQgPSAwOwoJCWV4ZWMoc2FtdGVybSwgYXJndik7CgkJZnByaW50KDIsICJjYW4n dCBleGVjOiAiKTsKCQlwZXJyb3Ioc2FtdGVybSk7CgkJX2V4aXRzKCJkYW1uIik7Cgl9CglpZihw aXBlKHBoMnQpPT0tMSB8fCBwaXBlKHB0MmgpPT0tMSkKCQlwYW5pYygicGlwZSIpOwoJc3dpdGNo KGZvcmsoKSl7CgljYXNlIDA6CgkJZHVwKHBoMnRbMF0sIDApOwoJCWR1cChwdDJoWzFdLCAxKTsK CQljbG9zZShwaDJ0WzBdKTsKCQljbG9zZShwaDJ0WzFdKTsKCQljbG9zZShwdDJoWzBdKTsKCQlj bG9zZShwdDJoWzFdKTsKCQlhcmd2WzBdID0gInNhbXRlcm0iOwoJCSplbmQgPSAwOwoJCWV4ZWMo c2FtdGVybSwgYXJndik7CgkJZnByaW50KDIsICJjYW4ndCBleGVjOiAiKTsKCQlwZXJyb3Ioc2Ft dGVybSk7CgkJX2V4aXRzKCJkYW1uIik7CgljYXNlIC0xOgoJCXBhbmljKCJjYW4ndCBmb3JrIHNh bXRlcm0iKTsKCX0KCWR1cChwdDJoWzBdLCAwKTsKCWR1cChwaDJ0WzFdLCAxKTsKCWNsb3NlKHBo MnRbMF0pOwoJY2xvc2UocGgydFsxXSk7CgljbG9zZShwdDJoWzBdKTsKCWNsb3NlKHB0MmhbMV0p Owp9Cgp2b2lkCmNvbm5lY3R0byhjaGFyICptYWNoaW5lKQp7CglpbnQgcDFbMl0sIHAyWzJdOwoK CWlmKHBpcGUocDEpPDAgfHwgcGlwZShwMik8MCl7CgkJZHByaW50KCJjYW4ndCBwaXBlXG4iKTsK CQlleGl0cygicGlwZSIpOwoJfQoJcmVtb3RlZmQwID0gcDFbMF07CglyZW1vdGVmZDEgPSBwMlsx XTsKCXN3aXRjaChmb3JrKCkpewoJY2FzZSAwOgoJCWR1cChwMlswXSwgMCk7CgkJZHVwKHAxWzFd LCAxKTsKCQljbG9zZShwMVswXSk7CgkJY2xvc2UocDFbMV0pOwoJCWNsb3NlKHAyWzBdKTsKCQlj bG9zZShwMlsxXSk7CgkJZXhlY2woUlhQQVRILCBSWCwgbWFjaGluZSwgcnNhbW5hbWUsICItUiIs IChjaGFyKikwKTsKCQlkcHJpbnQoImNhbid0IGV4ZWMgJXNcbiIsIFJYUEFUSCk7CgkJZXhpdHMo ImV4ZWMiKTsKCgljYXNlIC0xOgoJCWRwcmludCgiY2FuJ3QgZm9ya1xuIik7CgkJZXhpdHMoImZv cmsiKTsKCX0KCWNsb3NlKHAxWzFdKTsKCWNsb3NlKHAyWzBdKTsKfQoKdm9pZApzdGFydHVwKGNo YXIgKm1hY2hpbmUsIGludCBSZmxhZywgY2hhciAqKmFyZ3YsIGNoYXIgKiplbmQpCnsKCWlmKG1h Y2hpbmUpCgkJY29ubmVjdHRvKG1hY2hpbmUpOwoJaWYoIVJmbGFnKQoJCWJvb3R0ZXJtKG1hY2hp bmUsIGFyZ3YsIGVuZCk7Cglkb3dubG9hZGVkID0gMTsKCW91dFRzKEh2ZXJzaW9uLCBWRVJTSU9O KTsKfQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2Ft L2xpc3QuYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUx ADAwMDAwMDAxNTMyADA3MTExNjIyMTA1ADAwMTQ2NTMAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSAi c2FtLmgiCgovKgogKiBDaGVjayB0aGF0IGxpc3QgaGFzIHJvb20gZm9yIG9uZSBtb3JlIGVsZW1l bnQuCiAqLwp2b2lkCmdyb3dsaXN0KExpc3QgKmwpCnsKCWlmKGwtPmxpc3RwdHI9PTAgfHwgbC0+ bmFsbG9jPT0wKXsKCQlsLT5uYWxsb2MgPSBJTkNSOwoJCWwtPmxpc3RwdHIgPSBlbWFsbG9jKElO Q1Iqc2l6ZW9mKGxvbmcpKTsKCQlsLT5udXNlZCA9IDA7Cgl9ZWxzZSBpZihsLT5udXNlZCA9PSBs LT5uYWxsb2MpewoJCWwtPmxpc3RwdHIgPSBlcmVhbGxvYyhsLT5saXN0cHRyLCAobC0+bmFsbG9j K0lOQ1IpKnNpemVvZihsb25nKSk7CgkJbWVtc2V0KCh2b2lkKikobC0+bG9uZ3B0citsLT5uYWxs b2MpLCAwLCBJTkNSKnNpemVvZihsb25nKSk7CgkJbC0+bmFsbG9jICs9IElOQ1I7Cgl9Cn0KCi8q CiAqIFJlbW92ZSB0aGUgaXRoIGVsZW1lbnQgZnJvbSB0aGUgbGlzdAogKi8Kdm9pZApkZWxsaXN0 KExpc3QgKmwsIGludCBpKQp7CgltZW1tb3ZlKCZsLT5sb25ncHRyW2ldLCAmbC0+bG9uZ3B0cltp KzFdLCAobC0+bnVzZWQtKGkrMSkpKnNpemVvZihsb25nKSk7CglsLT5udXNlZC0tOwp9CgovKgog KiBBZGQgYSBuZXcgZWxlbWVudCwgd2hvc2UgcG9zaXRpb24gaXMgaSwgdG8gdGhlIGxpc3QKICov CnZvaWQKaW5zbGlzdChMaXN0ICpsLCBpbnQgaSwgbG9uZyB2YWwpCnsKCWdyb3dsaXN0KGwpOwoJ bWVtbW92ZSgmbC0+bG9uZ3B0cltpKzFdLCAmbC0+bG9uZ3B0cltpXSwgKGwtPm51c2VkLWkpKnNp emVvZihsb25nKSk7CglsLT5sb25ncHRyW2ldID0gdmFsOwoJbC0+bnVzZWQrKzsKfQoKdm9pZAps aXN0ZnJlZShMaXN0ICpsKQp7CglmcmVlKGwtPmxpc3RwdHIpOwoJZnJlZShsKTsKfQoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2FtL21l c2cuYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAw MDAwMDMyNzIyADA3MTExNjQwMTE3ADAwMTQ2NDMAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Z2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSAic2Ft LmgiCgpIZWFkZXIJaDsKdWNoYXIJaW5kYXRhW0RBVEFTSVpFXTsKdWNoYXIJb3V0ZGF0YVsyKkRB VEFTSVpFKzNdOwkvKiByb29tIGZvciBvdmVyZmxvdyBtZXNzYWdlICovCnVjaGFyCSppbnA7CnVj aGFyCSpvdXRwOwp1Y2hhcgkqb3V0bXNnID0gb3V0ZGF0YTsKUG9zbgljbWRwdDsKUG9zbgljbWRw dGFkdjsKQnVmZmVyCXNuYXJmYnVmOwppbnQJd2FpdGFjazsKaW50CW5vZmx1c2g7CmludAl0dmVy c2lvbjsKCmxvbmcJaW5sb25nKHZvaWQpOwpsb25nCWludmxvbmcodm9pZCk7CmludAlpbnNob3J0 KHZvaWQpOwppbnQJaW5tZXNnKFRtZXNnKTsKdm9pZAlzZXRnZW5zdHIoRmlsZSosIFBvc24sIFBv c24pOwoKI2lmZGVmIERFQlVHCmNoYXIgKmhuYW1lW10gPSB7CglbSHZlcnNpb25dCSJIdmVyc2lv biIsCglbSGJpbmRuYW1lXQkiSGJpbmRuYW1lIiwKCVtIY3VycmVudF0JIkhjdXJyZW50IiwKCVtI bmV3bmFtZV0JIkhuZXduYW1lIiwKCVtIbW92bmFtZV0JIkhtb3ZuYW1lIiwKCVtIZ3Jvd10JCSJI Z3JvdyIsCglbSGNoZWNrMF0JIkhjaGVjazAiLAoJW0hjaGVja10JIkhjaGVjayIsCglbSHVubG9j a10JIkh1bmxvY2siLAoJW0hkYXRhXQkJIkhkYXRhIiwKCVtIb3JpZ2luXQkiSG9yaWdpbiIsCglb SHVubG9ja2ZpbGVdCSJIdW5sb2NrZmlsZSIsCglbSHNldGRvdF0JIkhzZXRkb3QiLAoJW0hncm93 ZGF0YV0JIkhncm93ZGF0YSIsCglbSG1vdmV0b10JIkhtb3ZldG8iLAoJW0hjbGVhbl0JIkhjbGVh biIsCglbSGRpcnR5XQkiSGRpcnR5IiwKCVtIY3V0XQkJIkhjdXQiLAoJW0hzZXRwYXRdCSJIc2V0 cGF0IiwKCVtIZGVsbmFtZV0JIkhkZWxuYW1lIiwKCVtIY2xvc2VdCSJIY2xvc2UiLAoJW0hzZXRz bmFyZl0JIkhzZXRzbmFyZiIsCglbSHNuYXJmbGVuXQkiSHNuYXJmbGVuIiwKCVtIYWNrXQkJIkhh Y2siLAoJW0hleGl0XQkJIkhleGl0IiwKCVtIcGx1bWJdCQkiSHBsdW1iIiwKfTsKCmNoYXIgKnRu YW1lW10gPSB7CglbVHZlcnNpb25dCSJUdmVyc2lvbiIsCglbVHN0YXJ0Y21kZmlsZV0JIlRzdGFy dGNtZGZpbGUiLAoJW1RjaGVja10JIlRjaGVjayIsCglbVHJlcXVlc3RdCSJUcmVxdWVzdCIsCglb VG9yaWdpbl0JIlRvcmlnaW4iLAoJW1RzdGFydGZpbGVdCSJUc3RhcnRmaWxlIiwKCVtUd29ya2Zp bGVdCSJUd29ya2ZpbGUiLAoJW1R0eXBlXQkJIlR0eXBlIiwKCVtUY3V0XQkJIlRjdXQiLAoJW1Rw YXN0ZV0JIlRwYXN0ZSIsCglbVHNuYXJmXQkiVHNuYXJmIiwKCVtUc3RhcnRuZXdmaWxlXQkiVHN0 YXJ0bmV3ZmlsZSIsCglbVHdyaXRlXQkiVHdyaXRlIiwKCVtUY2xvc2VdCSJUY2xvc2UiLAoJW1Rs b29rXQkJIlRsb29rIiwKCVtUc2VhcmNoXQkiVHNlYXJjaCIsCglbVHNlbmRdCQkiVHNlbmQiLAoJ W1RkY2xpY2tdCSJUZGNsaWNrIiwKCVtUc3RhcnRzbmFyZl0JIlRzdGFydHNuYXJmIiwKCVtUc2V0 c25hcmZdCSJUc2V0c25hcmYiLAoJW1RhY2tdCQkiVGFjayIsCglbVGV4aXRdCQkiVGV4aXQiLAoJ W1RwbHVtYl0JCSJUcGx1bWIiLAp9OwoKdm9pZApqb3VybmFsKGludCBvdXQsIGNoYXIgKnMpCnsK CXN0YXRpYyBpbnQgZmQgPSAwOwoKCWlmKGZkIDw9IDApCgkJZmQgPSBjcmVhdGUoIi90bXAvc2Ft Lm91dCIsIDEsIDA2NjZMKTsKCWZwcmludChmZCwgIiVzJXNcbiIsIG91dD8gIm91dDogIiA6ICJp bjogICIsIHMpOwp9Cgp2b2lkCmpvdXJuYWxuKGludCBvdXQsIGxvbmcgbikKewoJY2hhciBidWZb MzJdOwoKCXNwcmludChidWYsICIlbGQiLCBuKTsKCWpvdXJuYWwob3V0LCBidWYpOwp9CiNlbHNl CiNkZWZpbmUJam91cm5hbChhLCBiKQojZGVmaW5lIGpvdXJuYWxuKGEsIGIpCiNlbmRpZgoKaW50 CnJjdmNoYXIodm9pZCl7CglzdGF0aWMgdWNoYXIgYnVmWzY0XTsKCXN0YXRpYyBpbnQgaSwgbmxl ZnQgPSAwOwoKCWlmKG5sZWZ0IDw9IDApewoJCW5sZWZ0ID0gcmVhZCgwLCAoY2hhciAqKWJ1Ziwg c2l6ZW9mIGJ1Zik7CgkJaWYobmxlZnQgPD0gMCkKCQkJcmV0dXJuIC0xOwoJCWkgPSAwOwoJfQoJ LS1ubGVmdDsKCXJldHVybiBidWZbaSsrXTsKfQoKaW50CnJjdih2b2lkKXsKCWludCBjOwoJc3Rh dGljIGludCBzdGF0ZSA9IDA7CglzdGF0aWMgaW50IGNvdW50ID0gMDsKCXN0YXRpYyBpbnQgaSA9 IDA7CgoJd2hpbGUoKGM9cmN2Y2hhcigpKSAhPSAtMSkKCQlzd2l0Y2goc3RhdGUpewoJCWNhc2Ug MDoKCQkJaC50eXBlID0gYzsKCQkJc3RhdGUrKzsKCQkJYnJlYWs7CgoJCWNhc2UgMToKCQkJaC5j b3VudDAgPSBjOwoJCQlzdGF0ZSsrOwoJCQlicmVhazsKCgkJY2FzZSAyOgoJCQloLmNvdW50MSA9 IGM7CgkJCWNvdW50ID0gaC5jb3VudDB8KGguY291bnQxPDw4KTsKCQkJaSA9IDA7CgkJCWlmKGNv dW50ID4gREFUQVNJWkUpCgkJCQlwYW5pYygiY291bnQ+REFUQVNJWkUiKTsKCQkJaWYoY291bnQg PT0gMCkKCQkJCWdvdG8gemVyb2NvdW50OwoJCQlzdGF0ZSsrOwoJCQlicmVhazsKCgkJY2FzZSAz OgoJCQlpbmRhdGFbaSsrXSA9IGM7CgkJCWlmKGkgPT0gY291bnQpewoJCXplcm9jb3VudDoKCQkJ CWluZGF0YVtpXSA9IDA7CgkJCQlzdGF0ZSA9IGNvdW50ID0gMDsKCQkJCXJldHVybiBpbm1lc2co aC50eXBlKTsKCQkJfQoJCQlicmVhazsKCQl9CglyZXR1cm4gMDsKfQoKRmlsZSAqCndoaWNoZmls ZShpbnQgdGFnKQp7CglpbnQgaTsKCglmb3IoaSA9IDA7IGk8ZmlsZS5udXNlZDsgaSsrKQoJCWlm KGZpbGUuZmlsZXBwdHJbaV0tPnRhZz09dGFnKQoJCQlyZXR1cm4gZmlsZS5maWxlcHB0cltpXTsK CWhpY2NvdWdoKChjaGFyICopMCk7CglyZXR1cm4gMDsKfQoKaW50CmlubWVzZyhUbWVzZyB0eXBl KQp7CglSdW5lIGJ1ZlsxMDI1XTsKCWNoYXIgY2J1Zls2NF07CglpbnQgaSwgbTsKCXNob3J0IHM7 Cglsb25nIGwsIGwxOwoJRmlsZSAqZjsKCVBvc24gcDAsIHAxLCBwOwoJUmFuZ2UgcjsKCVN0cmlu ZyAqc3RyOwoJY2hhciAqYzsKCVJ1bmUgKnJwOwoJUGx1bWJtc2cgKnBtOwoKCWlmKHR5cGUgPiBU TUFYKQoJCXBhbmljKCJpbm1lc2ciKTsKCglqb3VybmFsKDAsIHRuYW1lW3R5cGVdKTsKCglpbnAg PSBpbmRhdGE7Cglzd2l0Y2godHlwZSl7CgljYXNlIC0xOgoJCXBhbmljKCJyY3YgZXJyb3IiKTsK CglkZWZhdWx0OgoJCWZwcmludCgyLCAidW5rbm93biB0eXBlICVkXG4iLCB0eXBlKTsKCQlwYW5p YygicmN2IHVua25vd24iKTsKCgljYXNlIFR2ZXJzaW9uOgoJCXR2ZXJzaW9uID0gaW5zaG9ydCgp OwoJCWpvdXJuYWxuKDAsIHR2ZXJzaW9uKTsKCQlicmVhazsKCgljYXNlIFRzdGFydGNtZGZpbGU6 CgkJbCA9IGludmxvbmcoKTsJCS8qIGZvciA2NC1iaXQgcG9pbnRlcnMgKi8KCQlqb3VybmFsbigw LCBsKTsKCQlTdHJkdXBsKCZnZW5zdHIsIHNhbW5hbWUpOwoJCWNtZCA9IG5ld2ZpbGUoKTsKCQlj bWQtPnVucmVhZCA9IDA7CgkJb3V0VHN2KEhiaW5kbmFtZSwgY21kLT50YWcsIGwpOwoJCW91dFRz KEhjdXJyZW50LCBjbWQtPnRhZyk7CgkJbG9nc2V0bmFtZShjbWQsICZnZW5zdHIpOwoJCWNtZC0+ cmFzcCA9IGVtYWxsb2Moc2l6ZW9mKExpc3QpKTsKCQljbWQtPm1vZCA9IDA7CgkJaWYoY21kc3Ry Lm4pewoJCQlsb2dpbnNlcnQoY21kLCAwTCwgY21kc3RyLnMsIGNtZHN0ci5uKTsKCQkJU3RyZGVs ZXRlKCZjbWRzdHIsIDBMLCAoUG9zbiljbWRzdHIubik7CgkJfQoJCWZpbGV1cGRhdGUoY21kLCBG QUxTRSwgVFJVRSk7CgkJb3V0VDAoSHVubG9jayk7CgkJYnJlYWs7CgoJY2FzZSBUY2hlY2s6CgkJ LyogZ28gdGhyb3VnaCB3aGljaGZpbGUgdG8gY2hlY2sgdGhlIHRhZyAqLwoJCW91dFRzKEhjaGVj aywgd2hpY2hmaWxlKGluc2hvcnQoKSktPnRhZyk7CgkJYnJlYWs7CgoJY2FzZSBUcmVxdWVzdDoK CQlmID0gd2hpY2hmaWxlKGluc2hvcnQoKSk7CgkJcDAgPSBpbmxvbmcoKTsKCQlwMSA9IHAwK2lu c2hvcnQoKTsKCQlqb3VybmFsbigwLCBwMCk7CgkJam91cm5hbG4oMCwgcDEtcDApOwoJCWlmKGYt PnVucmVhZCkKCQkJcGFuaWMoIlRyZXF1ZXN0OiB1bnJlYWQiKTsKCQlpZihwMT5mLT5VLm5jKQoJ CQlwMSA9IGYtPlUubmM7CgkJaWYocDA+Zi0+VS5uYykgLyogY2FuIGhhcHBlbiBlLmcuIHNjcm9s bGluZyBkdXJpbmcgY29tbWFuZCAqLwoJCQlwMCA9IGYtPlUubmM7CgkJaWYocDAgPT0gcDEpewoJ CQlpID0gMDsKCQkJci5wMSA9IHIucDIgPSBwMDsKCQl9ZWxzZXsKCQkJciA9IHJkYXRhKGYtPnJh c3AsIHAwLCBwMS1wMCk7CgkJCWkgPSByLnAyLXIucDE7CgkJCWJ1ZnJlYWQoJmYtPlUsIHIucDEs IGJ1ZiwgaSk7CgkJfQoJCWJ1ZltpXT0wOwoJCW91dFRzbFMoSGRhdGEsIGYtPnRhZywgci5wMSwg dG1wcnN0cihidWYsIGkrMSkpOwoJCWJyZWFrOwoKCWNhc2UgVG9yaWdpbjoKCQlzID0gaW5zaG9y dCgpOwoJCWwgPSBpbmxvbmcoKTsKCQlsMSA9IGlubG9uZygpOwoJCWpvdXJuYWxuKDAsIGwxKTsK CQlsb29rb3JpZ2luKHdoaWNoZmlsZShzKSwgbCwgbDEpOwoJCWJyZWFrOwoKCWNhc2UgVHN0YXJ0 ZmlsZToKCQl0ZXJtbG9ja2VkKys7CgkJZiA9IHdoaWNoZmlsZShpbnNob3J0KCkpOwoJCWlmKCFm LT5yYXNwKQkvKiB0aGlzIG1pZ2h0IGJlIGEgZHVwbGljYXRlIG1lc3NhZ2UgKi8KCQkJZi0+cmFz cCA9IGVtYWxsb2Moc2l6ZW9mKExpc3QpKTsKCQljdXJyZW50KGYpOwoJCW91dFRzdihIYmluZG5h bWUsIGYtPnRhZywgaW52bG9uZygpKTsJLyogZm9yIDY0LWJpdCBwb2ludGVycyAqLwoJCW91dFRz KEhjdXJyZW50LCBmLT50YWcpOwoJCWpvdXJuYWxuKDAsIGYtPnRhZyk7CgkJaWYoZi0+dW5yZWFk KQoJCQlsb2FkKGYpOwoJCWVsc2V7CgkJCWlmKGYtPlUubmM+MCl7CgkJCQlyZ3JvdyhmLT5yYXNw LCAwTCwgZi0+VS5uYyk7CgkJCQlvdXRUc2xsKEhncm93LCBmLT50YWcsIDBMLCBmLT5VLm5jKTsK CQkJfQoJCQlvdXRUcyhIY2hlY2swLCBmLT50YWcpOwoJCQltb3ZldG8oZiwgZi0+ZG90LnIpOwoJ CX0KCQlicmVhazsKCgljYXNlIFR3b3JrZmlsZToKCQlpID0gaW5zaG9ydCgpOwoJCWYgPSB3aGlj aGZpbGUoaSk7CgkJY3VycmVudChmKTsKCQlmLT5kb3Quci5wMSA9IGlubG9uZygpOwoJCWYtPmRv dC5yLnAyID0gaW5sb25nKCk7CgkJZi0+dGRvdCA9IGYtPmRvdC5yOwoJCWpvdXJuYWxuKDAsIGkp OwoJCWpvdXJuYWxuKDAsIGYtPmRvdC5yLnAxKTsKCQlqb3VybmFsbigwLCBmLT5kb3Quci5wMik7 CgkJYnJlYWs7CgoJY2FzZSBUdHlwZToKCQlmID0gd2hpY2hmaWxlKGluc2hvcnQoKSk7CgkJcDAg PSBpbmxvbmcoKTsKCQlqb3VybmFsbigwLCBwMCk7CgkJam91cm5hbCgwLCAoY2hhciopaW5wKTsK CQlzdHIgPSB0bXBjc3RyKChjaGFyKilpbnApOwoJCWkgPSBzdHItPm47CgkJbG9naW5zZXJ0KGYs IHAwLCBzdHItPnMsIHN0ci0+bik7CgkJaWYoZmlsZXVwZGF0ZShmLCBGQUxTRSwgRkFMU0UpKQoJ CQlzZXErKzsKCQlpZihmPT1jbWQgJiYgcDA9PWYtPlUubmMtaSAmJiBpPjAgJiYgc3RyLT5zW2kt MV09PSdcbicpewoJCQlmcmVldG1wc3RyKHN0cik7CgkJCXRlcm1sb2NrZWQrKzsKCQkJdGVybWNv bW1hbmQoKTsKCQl9ZWxzZQoJCQlmcmVldG1wc3RyKHN0cik7CgkJZi0+ZG90LnIucDEgPSBmLT5k b3Quci5wMiA9IHAwK2k7IC8qIHRlcm1pbmFsIGtub3dzIHRoaXMgYWxyZWFkeSAqLwoJCWYtPnRk b3QgPSBmLT5kb3QucjsKCQlicmVhazsKCgljYXNlIFRjdXQ6CgkJZiA9IHdoaWNoZmlsZShpbnNo b3J0KCkpOwoJCXAwID0gaW5sb25nKCk7CgkJcDEgPSBpbmxvbmcoKTsKCQlqb3VybmFsbigwLCBw MCk7CgkJam91cm5hbG4oMCwgcDEpOwoJCWxvZ2RlbGV0ZShmLCBwMCwgcDEpOwoJCWlmKGZpbGV1 cGRhdGUoZiwgRkFMU0UsIEZBTFNFKSkKCQkJc2VxKys7CgkJZi0+ZG90LnIucDEgPSBmLT5kb3Qu ci5wMiA9IHAwOwoJCWYtPnRkb3QgPSBmLT5kb3QucjsgICAvKiB0ZXJtaW5hbCBrbm93cyB0aGUg dmFsdWUgb2YgZG90IGFscmVhZHkgKi8KCQlicmVhazsKCgljYXNlIFRwYXN0ZToKCQlmID0gd2hp Y2hmaWxlKGluc2hvcnQoKSk7CgkJcDAgPSBpbmxvbmcoKTsKCQlqb3VybmFsbigwLCBwMCk7CgkJ Zm9yKGw9MDsgbDxzbmFyZmJ1Zi5uYzsgbCs9bSl7CgkJCW0gPSBzbmFyZmJ1Zi5uYy1sOwoJCQlp ZihtPkJMT0NLU0laRSkKCQkJCW0gPSBCTE9DS1NJWkU7CgkJCWJ1ZnJlYWQoJnNuYXJmYnVmLCBs LCBnZW5idWYsIG0pOwoJCQlsb2dpbnNlcnQoZiwgcDAsIHRtcHJzdHIoZ2VuYnVmLCBtKS0+cywg bSk7CgkJfQoJCWlmKGZpbGV1cGRhdGUoZiwgRkFMU0UsIFRSVUUpKQoJCQlzZXErKzsKCQlmLT5k b3Quci5wMSA9IHAwOwoJCWYtPmRvdC5yLnAyID0gcDArc25hcmZidWYubmM7CgkJZi0+dGRvdC5w MSA9IC0xOyAvKiBmb3JjZSB0ZWxsZG90IHRvIHRlbGwgKGFyZ3VhYmx5IGEgQlVHKSAqLwoJCXRl bGxkb3QoZik7CgkJb3V0VHMoSHVubG9ja2ZpbGUsIGYtPnRhZyk7CgkJYnJlYWs7CgoJY2FzZSBU c25hcmY6CgkJaSA9IGluc2hvcnQoKTsKCQlwMCA9IGlubG9uZygpOwoJCXAxID0gaW5sb25nKCk7 CgkJc25hcmYod2hpY2hmaWxlKGkpLCBwMCwgcDEsICZzbmFyZmJ1ZiwgMCk7CgkJYnJlYWs7CgoJ Y2FzZSBUc3RhcnRuZXdmaWxlOgoJCWwgPSBpbnZsb25nKCk7CgkJU3RyZHVwbCgmZ2Vuc3RyLCBl bXB0eSk7CgkJZiA9IG5ld2ZpbGUoKTsKCQlmLT5yYXNwID0gZW1hbGxvYyhzaXplb2YoTGlzdCkp OwoJCW91dFRzdihIYmluZG5hbWUsIGYtPnRhZywgbCk7CgkJbG9nc2V0bmFtZShmLCAmZ2Vuc3Ry KTsKCQlvdXRUcyhIY3VycmVudCwgZi0+dGFnKTsKCQljdXJyZW50KGYpOwoJCWxvYWQoZik7CgkJ YnJlYWs7CgoJY2FzZSBUd3JpdGU6CgkJdGVybWxvY2tlZCsrOwoJCWkgPSBpbnNob3J0KCk7CgkJ am91cm5hbG4oMCwgaSk7CgkJZiA9IHdoaWNoZmlsZShpKTsKCQlhZGRyLnIucDEgPSAwOwoJCWFk ZHIuci5wMiA9IGYtPlUubmM7CgkJaWYoZi0+bmFtZS5zWzBdID09IDApCgkJCWVycm9yKEVub25h bWUpOwoJCVN0cmR1cGxzdHIoJmdlbnN0ciwgJmYtPm5hbWUpOwoJCXdyaXRlZihmKTsKCQlicmVh azsKCgljYXNlIFRjbG9zZToKCQl0ZXJtbG9ja2VkKys7CgkJaSA9IGluc2hvcnQoKTsKCQlqb3Vy bmFsbigwLCBpKTsKCQlmID0gd2hpY2hmaWxlKGkpOwoJCWN1cnJlbnQoZik7CgkJdHJ5dG9jbG9z ZShmKTsKCQkvKiBpZiB0cnl0b2Nsb3NlIGZhaWxzLCB3aWxsIGVycm9yIG91dCAqLwoJCWRlbGV0 ZShmKTsKCQlicmVhazsKCgljYXNlIFRsb29rOgoJCWYgPSB3aGljaGZpbGUoaW5zaG9ydCgpKTsK CQl0ZXJtbG9ja2VkKys7CgkJcDAgPSBpbmxvbmcoKTsKCQlwMSA9IGlubG9uZygpOwoJCWpvdXJu YWxuKDAsIHAwKTsKCQlqb3VybmFsbigwLCBwMSk7CgkJc2V0Z2Vuc3RyKGYsIHAwLCBwMSk7CgkJ Zm9yKGwgPSAwOyBsPGdlbnN0ci5uOyBsKyspewoJCQlpID0gZ2Vuc3RyLnNbbF07CgkJCWlmKHV0 ZnJ1bmUoIi4qKz8ofClcXFtdXiQiLCBpKSkKCQkJCVN0cmluc2VydCgmZ2Vuc3RyLCB0bXBjc3Ry KCJcXCIpLCBsKyspOwoJCX0KCQlTdHJhZGRjKCZnZW5zdHIsICdcMCcpOwoJCW5leHRtYXRjaChm LCAmZ2Vuc3RyLCBwMSwgMSk7CgkJbW92ZXRvKGYsIHNlbC5wWzBdKTsKCQlicmVhazsKCgljYXNl IFRzZWFyY2g6CgkJdGVybWxvY2tlZCsrOwoJCWlmKGN1cmZpbGUgPT0gMCkKCQkJZXJyb3IoRW5v ZmlsZSk7CgkJaWYobGFzdHBhdC5zWzBdID09IDApCgkJCXBhbmljKCJUc2VhcmNoIik7CgkJbmV4 dG1hdGNoKGN1cmZpbGUsICZsYXN0cGF0LCBjdXJmaWxlLT5kb3Quci5wMiwgMSk7CgkJbW92ZXRv KGN1cmZpbGUsIHNlbC5wWzBdKTsKCQlicmVhazsKCgljYXNlIFRzZW5kOgoJCXRlcm1sb2NrZWQr KzsKCQlpbnNob3J0KCk7CS8qIGlnbm9yZWQgKi8KCQlwMCA9IGlubG9uZygpOwoJCXAxID0gaW5s b25nKCk7CgkJc2V0Z2Vuc3RyKGNtZCwgcDAsIHAxKTsKCQlidWZyZXNldCgmc25hcmZidWYpOwoJ CWJ1Zmluc2VydCgmc25hcmZidWYsIChQb3NuKTAsIGdlbnN0ci5zLCBnZW5zdHIubik7CgkJb3V0 VGwoSHNuYXJmbGVuLCBnZW5zdHIubik7CgkJaWYoZ2Vuc3RyLnNbZ2Vuc3RyLm4tMV0gIT0gJ1xu JykKCQkJU3RyYWRkYygmZ2Vuc3RyLCAnXG4nKTsKCQlsb2dpbnNlcnQoY21kLCBjbWQtPlUubmMs IGdlbnN0ci5zLCBnZW5zdHIubik7CgkJZmlsZXVwZGF0ZShjbWQsIEZBTFNFLCBUUlVFKTsKCQlj bWQtPmRvdC5yLnAxID0gY21kLT5kb3Quci5wMiA9IGNtZC0+VS5uYzsKCQl0ZWxsZG90KGNtZCk7 CgkJdGVybWNvbW1hbmQoKTsKCQlicmVhazsKCgljYXNlIFRkY2xpY2s6CgkJZiA9IHdoaWNoZmls ZShpbnNob3J0KCkpOwoJCXAxID0gaW5sb25nKCk7CgkJZG91YmxlY2xpY2soZiwgcDEpOwoJCWYt PnRkb3QucDEgPSBmLT50ZG90LnAyID0gcDE7CgkJdGVsbGRvdChmKTsKCQlvdXRUcyhIdW5sb2Nr ZmlsZSwgZi0+dGFnKTsKCQlicmVhazsKCgljYXNlIFRzdGFydHNuYXJmOgoJCWlmIChzbmFyZmJ1 Zi5uYyA8PSAwKSB7CS8qIG5vdGhpbmcgdG8gZXhwb3J0ICovCgkJCW91dFRzKEhzZXRzbmFyZiwg MCk7CgkJCWJyZWFrOwoJCX0KCQljID0gMDsKCQlpID0gMDsKCQltID0gc25hcmZidWYubmM7CgkJ aWYobSA+IFNOQVJGU0laRSkgewoJCQltID0gU05BUkZTSVpFOwoJCQlkcHJpbnQoIj93YXJuaW5n OiBzbmFyZiBidWZmZXIgdHJ1bmNhdGVkXG4iKTsKCQl9CgkJcnAgPSBtYWxsb2MobSpzaXplb2Yo UnVuZSkpOwoJCWlmKHJwKXsKCQkJYnVmcmVhZCgmc25hcmZidWYsIDAsIHJwLCBtKTsKCQkJYyA9 IFN0cnRvYyh0bXByc3RyKHJwLCBtKSk7CgkJCWZyZWUocnApOwoJCQlpID0gc3RybGVuKGMpOwoJ CX0KCQlvdXRUcyhIc2V0c25hcmYsIGkpOwoJCWlmKGMpewoJCQlXcml0ZSgxLCBjLCBpKTsKCQkJ ZnJlZShjKTsKCQl9IGVsc2UKCQkJZHByaW50KCJzbmFyZiBidWZmZXIgdG9vIGxvbmdcbiIpOwoJ CWJyZWFrOwoKCWNhc2UgVHNldHNuYXJmOgoJCW0gPSBpbnNob3J0KCk7CgkJaWYobSA+IFNOQVJG U0laRSkKCQkJZXJyb3IoRXRvb2xvbmcpOwoJCWMgPSBtYWxsb2MobSsxKTsKCQlpZihjKXsKCQkJ Zm9yKGk9MDsgaTxtOyBpKyspCgkJCQljW2ldID0gcmN2Y2hhcigpOwoJCQljW21dID0gMDsKCQkJ c3RyID0gdG1wY3N0cihjKTsKCQkJZnJlZShjKTsKCQkJYnVmcmVzZXQoJnNuYXJmYnVmKTsKCQkJ YnVmaW5zZXJ0KCZzbmFyZmJ1ZiwgKFBvc24pMCwgc3RyLT5zLCBzdHItPm4pOwoJCQlmcmVldG1w c3RyKHN0cik7CgkJCW91dFQwKEh1bmxvY2spOwoJCX0KCQlicmVhazsKCgljYXNlIFRhY2s6CgkJ d2FpdGFjayA9IDA7CgkJYnJlYWs7CgoJY2FzZSBUcGx1bWI6CgkJZiA9IHdoaWNoZmlsZShpbnNo b3J0KCkpOwoJCXAwID0gaW5sb25nKCk7CgkJcDEgPSBpbmxvbmcoKTsKCQlwbSA9IGVtYWxsb2Mo c2l6ZW9mKFBsdW1ibXNnKSk7CgkJcG0tPnNyYyA9IHN0cmR1cCgic2FtIik7CgkJcG0tPmRzdCA9 IDA7CgkJcG0tPndkaXIgPSBlbWFsbG9jKDEwMjQpOwoJCWdldHdkKHBtLT53ZGlyLCAxMDI0KTsK CQlwbS0+dHlwZSA9IHN0cmR1cCgidGV4dCIpOwoJCWlmKHAxID4gcDApCgkJCXBtLT5hdHRyID0g bmlsOwoJCWVsc2V7CgkJCXAgPSBwMDsKCQkJd2hpbGUocDA+MCAmJiAoaT1maWxlcmVhZGMoZiwg cDAgLSAxKSkhPScgJyAmJiBpIT0nXHQnICYmIGkhPSdcbicpCgkJCQlwMC0tOwoJCQl3aGlsZShw MTxmLT5VLm5jICYmIChpPWZpbGVyZWFkYyhmLCBwMSkpIT0nICcgJiYgaSE9J1x0JyAmJiBpIT0n XG4nKQoJCQkJcDErKzsKCQkJc3ByaW50KGNidWYsICJjbGljaz0lbGQiLCBwLXAwKTsKCQkJcG0t PmF0dHIgPSBwbHVtYnVucGFja2F0dHIoY2J1Zik7CgkJfQoJCWlmKHAwPT1wMSB8fCBwMS1wMD49 QkxPQ0tTSVpFKXsKCQkJcGx1bWJmcmVlKHBtKTsKCQkJYnJlYWs7CgkJfQoJCXNldGdlbnN0cihm LCBwMCwgcDEpOwoJCXBtLT5kYXRhID0gU3RydG9jKCZnZW5zdHIpOwoJCXBtLT5uZGF0YSA9IHN0 cmxlbihwbS0+ZGF0YSk7CgkJYyA9IHBsdW1icGFjayhwbSwgJmkpOwoJCWlmKGMgIT0gMCl7CgkJ CW91dFRzKEhwbHVtYiwgaSk7CgkJCVdyaXRlKDEsIGMsIGkpOwoJCQlmcmVlKGMpOwoJCX0KCQlw bHVtYmZyZWUocG0pOwoJCWJyZWFrOwoKCWNhc2UgVGV4aXQ6CgkJZXhpdHMoMCk7Cgl9CglyZXR1 cm4gVFJVRTsKfQoKdm9pZApzbmFyZihGaWxlICpmLCBQb3NuIHAxLCBQb3NuIHAyLCBCdWZmZXIg KmJ1ZiwgaW50IGVtcHR5b2spCnsKCVBvc24gbDsKCWludCBpOwoKCWlmKCFlbXB0eW9rICYmIHAx PT1wMikKCQlyZXR1cm47CglidWZyZXNldChidWYpOwoJLyogU3RhZ2UgdGhyb3VnaCBnZW5idWYg dG8gYXZvaWQgY29tcGFjdGlvbiBwcm9ibGVtcyAodmVzdGlnaWFsKSAqLwoJaWYocDIgPiBmLT5V Lm5jKXsKCQlmcHJpbnQoMiwgImJhZCBzbmFyZiBhZGRyIHAxPSVsZCBwMj0lbGQgZi0+VS5uYz0l ZFxuIiwgcDEsIHAyLCBmLT5VLm5jKTsgLypaWlogc2hvdWxkIG5ldmVyIGhhcHBlbiwgY2FuIHJl bW92ZSAqLwoJCXAyID0gZi0+VS5uYzsKCX0KCWZvcihsPXAxOyBsPHAyOyBsKz1pKXsKCQlpID0g cDItbD5CTE9DS1NJWkU/IEJMT0NLU0laRSA6IHAyLWw7CgkJYnVmcmVhZCgmZi0+VSwgbCwgZ2Vu YnVmLCBpKTsKCQlidWZpbnNlcnQoYnVmLCBidWYtPm5jLCB0bXByc3RyKGdlbmJ1ZiwgaSktPnMs IGkpOwoJfQp9CgppbnQKaW5zaG9ydCh2b2lkKQp7Cgl1c2hvcnQgbjsKCgluID0gaW5wWzBdIHwg KGlucFsxXTw8OCk7CglpbnAgKz0gMjsKCXJldHVybiBuOwp9Cgpsb25nCmlubG9uZyh2b2lkKQp7 Cgl1bG9uZyBuOwoKCW4gPSBpbnBbMF0gfCAoaW5wWzFdPDw4KSB8IChpbnBbMl08PDE2KSB8IChp bnBbM108PDI0KTsKCWlucCArPSA0OwoJcmV0dXJuIG47Cn0KCmxvbmcKaW52bG9uZyh2b2lkKQp7 Cgl1bG9uZyBuOwoJCgluID0gKGlucFs3XTw8MjQpIHwgKGlucFs2XTw8MTYpIHwgKGlucFs1XTw8 OCkgfCBpbnBbNF07CgluID0gKG48PDE2KSB8IChpbnBbM108PDgpIHwgaW5wWzJdOwoJbiA9IChu PDwxNikgfCAoaW5wWzFdPDw4KSB8IGlucFswXTsKCWlucCArPSA4OwoJcmV0dXJuIG47Cn0KCnZv aWQKc2V0Z2Vuc3RyKEZpbGUgKmYsIFBvc24gcDAsIFBvc24gcDEpCnsKCWlmKHAwICE9IHAxKXsK CQlpZihwMS1wMCA+PSBUQkxPQ0tTSVpFKQoJCQllcnJvcihFdG9vbG9uZyk7CgkJU3RyaW5zdXJl KCZnZW5zdHIsIHAxLXAwKTsKCQlidWZyZWFkKCZmLT5VLCBwMCwgZ2VuYnVmLCBwMS1wMCk7CgkJ bWVtbW92ZShnZW5zdHIucywgZ2VuYnVmLCBSVU5FU0laRSoocDEtcDApKTsKCQlnZW5zdHIubiA9 IHAxLXAwOwoJfWVsc2V7CgkJaWYoc25hcmZidWYubmMgPT0gMCkKCQkJZXJyb3IoRWVtcHR5KTsK CQlpZihzbmFyZmJ1Zi5uYyA+IFRCTE9DS1NJWkUpCgkJCWVycm9yKEV0b29sb25nKTsKCQlidWZy ZWFkKCZzbmFyZmJ1ZiwgKFBvc24pMCwgZ2VuYnVmLCBzbmFyZmJ1Zi5uYyk7CgkJU3RyaW5zdXJl KCZnZW5zdHIsIHNuYXJmYnVmLm5jKTsKCQltZW1tb3ZlKGdlbnN0ci5zLCBnZW5idWYsIFJVTkVT SVpFKnNuYXJmYnVmLm5jKTsKCQlnZW5zdHIubiA9IHNuYXJmYnVmLm5jOwoJfQp9Cgp2b2lkCm91 dFQwKEhtZXNnIHR5cGUpCnsKCW91dHN0YXJ0KHR5cGUpOwoJb3V0c2VuZCgpOwp9Cgp2b2lkCm91 dFRsKEhtZXNnIHR5cGUsIGxvbmcgbCkKewoJb3V0c3RhcnQodHlwZSk7CglvdXRsb25nKGwpOwoJ b3V0c2VuZCgpOwp9Cgp2b2lkCm91dFRzKEhtZXNnIHR5cGUsIGludCBzKQp7CglvdXRzdGFydCh0 eXBlKTsKCWpvdXJuYWxuKDEsIHMpOwoJb3V0c2hvcnQocyk7CglvdXRzZW5kKCk7Cn0KCnZvaWQK b3V0UyhTdHJpbmcgKnMpCnsKCWNoYXIgKmM7CglpbnQgaTsKCgljID0gU3RydG9jKHMpOwoJaSA9 IHN0cmxlbihjKTsKCW91dGNvcHkoaSwgYyk7CglpZihpID4gOTkpCgkJY1s5OV0gPSAwOwoJam91 cm5hbG4oMSwgaSk7Cglqb3VybmFsKDEsIGMpOwoJZnJlZShjKTsKfQoKdm9pZApvdXRUc1MoSG1l c2cgdHlwZSwgaW50IHMxLCBTdHJpbmcgKnMpCnsKCW91dHN0YXJ0KHR5cGUpOwoJb3V0c2hvcnQo czEpOwoJb3V0UyhzKTsKCW91dHNlbmQoKTsKfQoKdm9pZApvdXRUc2xTKEhtZXNnIHR5cGUsIGlu dCBzMSwgUG9zbiBsMSwgU3RyaW5nICpzKQp7CglvdXRzdGFydCh0eXBlKTsKCW91dHNob3J0KHMx KTsKCWpvdXJuYWxuKDEsIHMxKTsKCW91dGxvbmcobDEpOwoJam91cm5hbG4oMSwgbDEpOwoJb3V0 UyhzKTsKCW91dHNlbmQoKTsKfQoKdm9pZApvdXRUUyhIbWVzZyB0eXBlLCBTdHJpbmcgKnMpCnsK CW91dHN0YXJ0KHR5cGUpOwoJb3V0UyhzKTsKCW91dHNlbmQoKTsKfQoKdm9pZApvdXRUc2xsUyhI bWVzZyB0eXBlLCBpbnQgczEsIFBvc24gbDEsIFBvc24gbDIsIFN0cmluZyAqcykKewoJb3V0c3Rh cnQodHlwZSk7CglvdXRzaG9ydChzMSk7CglvdXRsb25nKGwxKTsKCW91dGxvbmcobDIpOwoJam91 cm5hbG4oMSwgbDEpOwoJam91cm5hbG4oMSwgbDIpOwoJb3V0UyhzKTsKCW91dHNlbmQoKTsKfQoK dm9pZApvdXRUc2xsKEhtZXNnIHR5cGUsIGludCBzLCBQb3NuIGwxLCBQb3NuIGwyKQp7CglvdXRz dGFydCh0eXBlKTsKCW91dHNob3J0KHMpOwoJb3V0bG9uZyhsMSk7CglvdXRsb25nKGwyKTsKCWpv dXJuYWxuKDEsIGwxKTsKCWpvdXJuYWxuKDEsIGwyKTsKCW91dHNlbmQoKTsKfQoKdm9pZApvdXRU c2woSG1lc2cgdHlwZSwgaW50IHMsIFBvc24gbCkKewoJb3V0c3RhcnQodHlwZSk7CglvdXRzaG9y dChzKTsKCW91dGxvbmcobCk7Cglqb3VybmFsbigxLCBsKTsKCW91dHNlbmQoKTsKfQoKdm9pZApv dXRUc3YoSG1lc2cgdHlwZSwgaW50IHMsIFBvc24gbCkKewoJb3V0c3RhcnQodHlwZSk7CglvdXRz aG9ydChzKTsKCW91dHZsb25nKCh2b2lkKilsKTsKCWpvdXJuYWxuKDEsIGwpOwoJb3V0c2VuZCgp Owp9Cgp2b2lkCm91dHN0YXJ0KEhtZXNnIHR5cGUpCnsKCWpvdXJuYWwoMSwgaG5hbWVbdHlwZV0p OwoJb3V0bXNnWzBdID0gdHlwZTsKCW91dHAgPSBvdXRtc2crMzsKfQoKdm9pZApvdXRjb3B5KGlu dCBjb3VudCwgdm9pZCAqZGF0YSkKewoJbWVtbW92ZShvdXRwLCBkYXRhLCBjb3VudCk7CglvdXRw ICs9IGNvdW50Owp9Cgp2b2lkCm91dHNob3J0KGludCBzKQp7Cgkqb3V0cCsrID0gczsKCSpvdXRw KysgPSBzPj44OyAKfQoKdm9pZApvdXRsb25nKGxvbmcgbCkKewoJKm91dHArKyA9IGw7Cgkqb3V0 cCsrID0gbD4+ODsKCSpvdXRwKysgPSBsPj4xNjsKCSpvdXRwKysgPSBsPj4yNDsKfQoKdm9pZApv dXR2bG9uZyh2b2lkICp2KQp7CglpbnQgaTsKCXVsb25nIGw7CgoJbCA9ICh1bG9uZykgdjsKCWZv cihpID0gMDsgaSA8IDg7IGkrKywgbCA+Pj0gOCkKCQkqb3V0cCsrID0gbDsKfQoKdm9pZApvdXRz ZW5kKHZvaWQpCnsKCWludCBvdXRjb3VudDsKCglvdXRjb3VudCA9IG91dHAtb3V0bXNnOwoJb3V0 Y291bnQgLT0gMzsKCW91dG1zZ1sxXSA9IG91dGNvdW50OwoJb3V0bXNnWzJdID0gb3V0Y291bnQ+ Pjg7CglvdXRtc2cgPSBvdXRwOwoJaWYoIW5vZmx1c2gpewoJCW91dGNvdW50ID0gb3V0bXNnLW91 dGRhdGE7CgkJaWYgKHdyaXRlKDEsIChjaGFyKikgb3V0ZGF0YSwgb3V0Y291bnQpICE9IG91dGNv dW50KQoJCQlyZXNjdWUoKTsKCQlvdXRtc2cgPSBvdXRkYXRhOwoJCXJldHVybjsKCX0KCWlmKG91 dG1zZyA8IG91dGRhdGErREFUQVNJWkUpCgkJcmV0dXJuOwoJb3V0Zmx1c2goKTsKfQoKdm9pZApv dXRmbHVzaCh2b2lkKQp7CglpZihvdXRtc2cgPT0gb3V0ZGF0YSkKCQlyZXR1cm47Cglub2ZsdXNo ID0gMDsKCW91dFQwKEhhY2spOwoJd2FpdGFjayA9IDE7CglkbwoJCWlmKHJjdigpID09IDApewoJ CQlyZXNjdWUoKTsKCQkJZXhpdHMoImVvZiIpOwoJCX0KCXdoaWxlKHdhaXRhY2spOwoJb3V0bXNn ID0gb3V0ZGF0YTsKCW5vZmx1c2ggPSAxOwp9CmR5ICovCgkJZi0+dGRvdCA9IGYtPmRvdC5yOwoJ CWJyZWFrOwoKCWNhc2UgVGNzYW0yay9zYW0vbWVzZy5oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMDEwMDY0NAAwMDAxNzM3ADAwMDAxNTEAMDAwMDAwMDYyMDUAMDcxMTE2MzU2NjYAMDAxNDY2 MgAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwc2No d2FydHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnY3NlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAADAwMDAwNDAAMDAwMDAyNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAC8qIFZFUlNJT04gMSBpbnRyb2R1Y2VzIHBsdW1iaW5nCgkyIGluY3Jl YXNlcyBTTkFSRlNJWkUgZnJvbSA0MDk2IHRvIDMyMDAwCiAqLwojZGVmaW5lCVZFUlNJT04JMgoK I2RlZmluZQlUQkxPQ0tTSVpFIDUxMgkJICAvKiBsYXJnZXN0IHBpZWNlIG9mIHRleHQgc2VudCB0 byB0ZXJtaW5hbCAqLwojZGVmaW5lCURBVEFTSVpFICAoVVRGbWF4KlRCTE9DS1NJWkUrMzApIC8q IC4uLiBpbmNsdWRpbmcgcHJvdG9jb2wgaGVhZGVyIHN0dWZmICovCiNkZWZpbmUJU05BUkZTSVpF IDMyMDAwCQkvKiBtYXhpbXVtIGxlbmd0aCBvZiBleGNoYW5nZWQgc25hcmYgYnVmZmVyLCBtdXN0 IGZpdCBpbiAxNSBiaXRzICovCi8qCiAqIE1lc3NhZ2VzIG9yaWdpbmF0aW5nIGF0IHRoZSB0ZXJt aW5hbAogKi8KdHlwZWRlZiBlbnVtIFRtZXNnCnsKCVR2ZXJzaW9uLAkvKiB2ZXJzaW9uICovCglU c3RhcnRjbWRmaWxlLAkvKiB0ZXJtaW5hbCBqdXN0IG9wZW5lZCBjb21tYW5kIGZyYW1lICovCglU Y2hlY2ssCQkvKiBhc2sgaG9zdCB0byBwb2tlIHdpdGggSGNoZWNrICovCglUcmVxdWVzdCwJLyog cmVxdWVzdCBkYXRhIHRvIGZpbGwgYSBob2xlICovCglUb3JpZ2luLAkvKiBnaW1tZSBhbiBIb3Jp Z2luIG5lYXIgaGVyZSAqLwoJVHN0YXJ0ZmlsZSwJLyogdGVybWluYWwganVzdCBvcGVuZWQgYSBm aWxlJ3MgZnJhbWUgKi8KCVR3b3JrZmlsZSwJLyogc2V0IGZpbGUgdG8gd2hpY2ggY29tbWFuZHMg YXBwbHkgKi8KCVR0eXBlLAkJLyogYWRkIHNvbWUgY2hhcmFjdGVycywgYnV0IHRlcm1pbmFsIGFs cmVhZHkga25vd3MgKi8KCVRjdXQsCglUcGFzdGUsCglUc25hcmYsCglUc3RhcnRuZXdmaWxlLAkv KiB0ZXJtaW5hbCBqdXN0IG9wZW5lZCBhIG5ldyBmcmFtZSAqLwoJVHdyaXRlLAkJLyogd3JpdGUg ZmlsZSAqLwoJVGNsb3NlLAkJLyogdGVybWluYWwgcmVxdWVzdHMgZmlsZSBjbG9zZTsgY2hlY2sg bW9kLiBzdGF0dXMgKi8KCVRsb29rLAkJLyogc2VhcmNoIGZvciBsaXRlcmFsIGN1cnJlbnQgdGV4 dCAqLwoJVHNlYXJjaCwJLyogc2VhcmNoIGZvciBsYXN0IHJlZ3VsYXIgZXhwcmVzc2lvbiAqLwoJ VHNlbmQsCQkvKiBwcmV0ZW5kIGhlIHR5cGVkIHN0dWZmICovCglUZGNsaWNrLAkvKiBkb3VibGUg Y2xpY2sgKi8KCVRzdGFydHNuYXJmLAkvKiBpbml0aWF0ZSBzbmFyZiBidWZmZXIgZXhjaGFuZ2Ug Ki8KCVRzZXRzbmFyZiwJLyogcmVtZW1iZXIgc3RyaW5nIGluIHNuYXJmIGJ1ZmZlciAqLwoJVGFj aywJCS8qIGFja25vd2xlZGdlIEhhY2sgKi8KCVRleGl0LAkJLyogZXhpdCAqLwoJVHBsdW1iLAkJ Lyogc2VuZCBwbHVtYiBtZXNzYWdlICovCglUTUFYIAp9VG1lc2c7Ci8qCiAqIE1lc3NhZ2VzIG9y aWdpbmF0aW5nIGF0IHRoZSBob3N0CiAqLwp0eXBlZGVmIGVudW0gSG1lc2cKewoJSHZlcnNpb24s CS8qIHZlcnNpb24gKi8KCUhiaW5kbmFtZSwJLyogYXR0YWNoIG5hbWVbMF0gdG8gdGV4dCBpbiB0 ZXJtaW5hbCAqLwoJSGN1cnJlbnQsCS8qIG1ha2UgbmFtZWQgZmlsZSB0aGUgdHlwaW5nIGZpbGUg Ki8KCUhuZXduYW1lLAkvKiBjcmVhdGUgIiIgbmFtZSBpbiBtZW51ICovCglIbW92bmFtZSwJLyog bW92ZSBmaWxlIG5hbWUgaW4gbWVudSAqLwoJSGdyb3csCQkvKiBpbnNlcnQgc3BhY2UgaW4gcmFz cCAqLwoJSGNoZWNrMCwJLyogc2VlIGJlbG93ICovCglIY2hlY2ssCQkvKiBhc2sgdGVybWluYWwg dG8gY2hlY2sgd2hldGhlciBpdCBuZWVkcyBtb3JlIGRhdGEgKi8KCUh1bmxvY2ssCS8qIGNvbW1h bmQgaXMgZmluaXNoZWQ7IHVzZXIgY2FuIGRvIHRoaW5ncyAqLwoJSGRhdGEsCQkvKiBzdG9yZSB0 aGlzIGRhdGEgaW4gcHJldmlvdXNseSBhbGxvY2F0ZWQgc3BhY2UgKi8KCUhvcmlnaW4sCS8qIHNl dCBvcmlnaW4gb2YgZmlsZS9mcmFtZSBpbiB0ZXJtaW5hbCAqLwoJSHVubG9ja2ZpbGUsCS8qIHVu bG9jayBmaWxlIGluIHRlcm1pbmFsICovCglIc2V0ZG90LAkvKiBzZXQgZG90IGluIHRlcm1pbmFs ICovCglIZ3Jvd2RhdGEsCS8qIEhncm93ICsgSGRhdGEgZm9sZGVkIHRvZ2V0aGVyICovCglIbW92 ZXRvLAkvKiBzY3JvbGxpbmcsIGNvbnRleHQgc2VhcmNoLCBldGMuICovCglIY2xlYW4sCQkvKiBu YW1lZCBmaWxlIGlzIG5vdyAnY2xlYW4nICovCglIZGlydHksCQkvKiBuYW1lZCBmaWxlIGlzIG5v dyAnZGlydHknICovCglIY3V0LAkJLyogcmVtb3ZlIHNwYWNlIGZyb20gcmFzcCAqLwoJSHNldHBh dCwJLyogc2V0IHJlbWVtYmVyZWQgcmVndWxhciBleHByZXNzaW9uICovCglIZGVsbmFtZSwJLyog ZGVsZXRlIGZpbGUgbmFtZSBmcm9tIG1lbnUgKi8KCUhjbG9zZSwJCS8qIGNsb3NlIGZpbGUgYW5k IHJlbW92ZSBmcm9tIG1lbnUgKi8KCUhzZXRzbmFyZiwJLyogcmVtZW1iZXIgc3RyaW5nIGluIHNu YXJmIGJ1ZmZlciAqLwoJSHNuYXJmbGVuLAkvKiByZXBvcnQgbGVuZ3RoIG9mIGltcGxpY2l0IHNu YXJmICovCglIYWNrLAkJLyogcmVxdWVzdCBhY2tub3dsZWRnZW1lbnQgKi8KCUhleGl0LAoJSHBs dW1iLAkJLyogcmV0dXJuIHBsdW1iIG1lc3NhZ2UgdG8gdGVybWluYWwgKi8KCUhNQVggCn1IbWVz ZzsKdHlwZWRlZiBzdHJ1Y3QgSGVhZGVyewoJdWNoYXIJdHlwZTsJCS8qIG9uZSBvZiB0aGUgYWJv dmUgKi8KCXVjaGFyCWNvdW50MDsJCS8qIGxvdyBiaXRzIG9mIGRhdGEgc2l6ZSAqLwoJdWNoYXIJ Y291bnQxOwkJLyogaGlnaCBiaXRzIG9mIGRhdGEgc2l6ZSAqLwoJdWNoYXIJZGF0YVsxXTsJLyog dmFyaWFibGUgc2l6ZSAqLwp9SGVhZGVyOwovKgogKiBGaWxlIHRyYW5zZmVyIHByb3RvY29sIHNj aGVtYXRpYywgYSBsYSBIb2x6bWFubgogKgkKICoJcHJvYyBoCiAqCXsJcHZhciBuID0gMDsKICoJ CXF1ZXVlIGhbNF07CiAqCQogKgkJZG8KICoJCTo6IChuIDwgIE4pICAtPiBuKys7IHQhSGdyb3cK ICoJCTo6IChuID09IE4pICAtPiBuKys7IHQhSGNoZWNrMAogKgkJOjogaD9UcmVxdWVzdCAtPiB0 IUhkYXRhCiAqCQk6OiBoP1RjaGVjayAgLT4gdCFIY2hlY2sKICoJCW9kCiAqCX0KICoJcHJvYyB0 CiAqCXsJcXVldWUgdFs0XTsKICoJCWRvCiAqCQk6OiB0P0hncm93IC0+IGghVHJlcXVlc3QKICoJ CTo6IHQ/SGRhdGEgLT4gc2tpcAogKgkJOjogdD9IY2hlY2swIC0+IGghVGNoZWNrCiAqCQk6OiB0 P0hjaGVjayAtPgogKgkJCWlmCiAqCQkJOjogYnJlYWsKICoJCQk6OiBoIVRyZXF1ZXN0OyBoIVRj aGVjawogKgkJCWZpCiAqCQlvZAogKgl9CiAqLwoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAc2FtMmsvc2FtL21vdmV0by5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2 NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDA1MjMwADA3MTExNjIyMTA1ADAwMTUyMTAAMAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAw MDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAjaW5jbHVkZSAic2FtLmgiCgp2b2lkCm1vdmV0byhGaWxlICpmLCBSYW5nZSByKQp7 CglQb3NuIHAxID0gci5wMSwgcDIgPSByLnAyOwoKCWYtPmRvdC5yLnAxID0gcDE7CglmLT5kb3Qu ci5wMiA9IHAyOwoJaWYoZi0+cmFzcCl7CgkJdGVsbGRvdChmKTsKCQlvdXRUc2woSG1vdmV0bywg Zi0+dGFnLCBmLT5kb3Quci5wMSk7Cgl9Cn0KCnZvaWQKdGVsbGRvdChGaWxlICpmKQp7CglpZihm LT5yYXNwID09IDApCgkJcGFuaWMoInRlbGxkb3QiKTsKCWlmKGYtPmRvdC5yLnAxPT1mLT50ZG90 LnAxICYmIGYtPmRvdC5yLnAyPT1mLT50ZG90LnAyKQoJCXJldHVybjsKCW91dFRzbGwoSHNldGRv dCwgZi0+dGFnLCBmLT5kb3Quci5wMSwgZi0+ZG90LnIucDIpOwoJZi0+dGRvdCA9IGYtPmRvdC5y Owp9Cgp2b2lkCnRlbGxwYXQodm9pZCkKewoJb3V0VFMoSHNldHBhdCwgJmxhc3RwYXQpOwoJcGF0 c2V0ID0gRkFMU0U7Cn0KCiNkZWZpbmUJQ0hBUlNISUZUCTEyOAoKdm9pZApsb29rb3JpZ2luKEZp bGUgKmYsIFBvc24gcDAsIFBvc24gbHMpCnsKCWludCBubCwgbmMsIGM7CglQb3NuIHAsIG9sZHAw OwoKCWlmKHAwID4gZi0+VS5uYykKCQlwMCA9IGYtPlUubmM7CglvbGRwMCA9IHAwOwoJcCA9IHAw OwoJZm9yKG5sPW5jPWM9MDsgYyE9LTEgJiYgbmw8bHMgJiYgbmM8bHMqQ0hBUlNISUZUOyBuYysr KQoJCWlmKChjPWZpbGVyZWFkYyhmLCAtLXApKSA9PSAnXG4nKXsKCQkJbmwrKzsKCQkJb2xkcDAg PSBwMC1uYzsKCQl9CglpZihjID09IC0xKQoJCXAwID0gMDsKCWVsc2UgaWYobmw9PTApewoJCWlm KHAwPj1DSEFSU0hJRlQvMikKCQkJcDAtPUNIQVJTSElGVC8yOwoJCWVsc2UKCQkJcDAgPSAwOwoJ fWVsc2UKCQlwMCA9IG9sZHAwOwoJb3V0VHNsKEhvcmlnaW4sIGYtPnRhZywgcDApOwp9CgppbnQK YWxudW0oaW50IGMpCnsKCS8qCgkgKiBIYXJkIHRvIGdldCBhYnNvbHV0ZWx5IHJpZ2h0LiAgVXNl IHdoYXQgd2Uga25vdyBhYm91dCBBU0NJSQoJICogYW5kIGFzc3VtZSBhbnl0aGluZyBhYm92ZSB0 aGUgTGF0aW4gY29udHJvbCBjaGFyYWN0ZXJzIGlzCgkgKiBwb3RlbnRpYWxseSBhbiBhbHBoYW51 bWVyaWMuCgkgKi8KCWlmKGM8PScgJykKCQlyZXR1cm4gMDsKCWlmKDB4N0Y8PWMgJiYgYzw9MHhB MCkKCQlyZXR1cm4gMDsKCWlmKHV0ZnJ1bmUoIiFcIiMkJSYnKCkqKywtLi86Ozw9Pj9AW1xcXV5g e3x9fiIsIGMpKQoJCXJldHVybiAwOwoJcmV0dXJuIDE7Cn0KCmludApjbGlja21hdGNoKEZpbGUg KmYsIGludCBjbCwgaW50IGNyLCBpbnQgZGlyLCBQb3NuICpwKQp7CglpbnQgYzsKCWludCBuZXN0 ID0gMTsKCglmb3IoOzspewoJCWlmKGRpciA+IDApewoJCQlpZigqcCA+PSBmLT5VLm5jKQoJCQkJ YnJlYWs7CgkJCWMgPSBmaWxlcmVhZGMoZiwgKCpwKSsrKTsKCQl9ZWxzZXsKCQkJaWYoKnAgPT0g MCkKCQkJCWJyZWFrOwoJCQljID0gZmlsZXJlYWRjKGYsIC0tKCpwKSk7CgkJfQoJCWlmKGMgPT0g Y3IpewoJCQlpZigtLW5lc3Q9PTApCgkJCQlyZXR1cm4gMTsKCQl9ZWxzZSBpZihjID09IGNsKQoJ CQluZXN0Kys7Cgl9CglyZXR1cm4gY2w9PSdcbicgJiYgbmVzdD09MTsKfQoKUnVuZSoKc3RycnVu ZShSdW5lICpzLCBSdW5lIGMpCnsKCVJ1bmUgYzE7CgoJaWYoYyA9PSAwKSB7CgkJd2hpbGUoKnMr KykKCQkJOwoJCXJldHVybiBzLTE7Cgl9CgoJd2hpbGUoYzEgPSAqcysrKQoJCWlmKGMxID09IGMp CgkJCXJldHVybiBzLTE7CglyZXR1cm4gMDsKfQoKdm9pZApkb3VibGVjbGljayhGaWxlICpmLCBQ b3NuIHAxKQp7CglpbnQgYywgaTsKCVJ1bmUgKnIsICpsOwoJUG9zbiBwOwoKCWlmKHAxID4gZi0+ VS5uYykKCQlyZXR1cm47CglmLT5kb3Quci5wMSA9IGYtPmRvdC5yLnAyID0gcDE7Cglmb3IoaT0w OyBsZWZ0W2ldOyBpKyspewoJCWwgPSBsZWZ0W2ldOwoJCXIgPSByaWdodFtpXTsKCQkvKiB0cnkg bGVmdCBtYXRjaCAqLwoJCXAgPSBwMTsKCQlpZihwMSA9PSAwKQoJCQljID0gJ1xuJzsKCQllbHNl CgkJCWMgPSBmaWxlcmVhZGMoZiwgcCAtIDEpOwoJCWlmKHN0cnJ1bmUobCwgYykpewoJCQlpZihj bGlja21hdGNoKGYsIGMsIHJbc3RycnVuZShsLCBjKS1sXSwgMSwgJnApKXsKCQkJCWYtPmRvdC5y LnAxID0gcDE7CgkJCQlmLT5kb3Quci5wMiA9IHAtKGMhPSdcbicpOwoJCQl9CgkJCXJldHVybjsK CQl9CgkJLyogdHJ5IHJpZ2h0IG1hdGNoICovCgkJcCA9IHAxOwoJCWlmKHAxID09IGYtPlUubmMp CgkJCWMgPSAnXG4nOwoJCWVsc2UKCQkJYyA9IGZpbGVyZWFkYyhmLCBwKTsKCQlpZihzdHJydW5l KHIsIGMpKXsKCQkJaWYoY2xpY2ttYXRjaChmLCBjLCBsW3N0cnJ1bmUociwgYyktcl0sIC0xLCAm cCkpewoJCQkJZi0+ZG90LnIucDEgPSBwOwoJCQkJaWYoYyE9J1xuJyB8fCBwIT0wIHx8IGZpbGVy ZWFkYyhmLCAwKT09J1xuJykKCQkJCQlmLT5kb3Quci5wMSsrOwoJCQkJZi0+ZG90LnIucDIgPSBw MSsocDE8Zi0+VS5uYyAmJiBjPT0nXG4nKTsKCQkJfQoJCQlyZXR1cm47CgkJfQoJfQoJLyogdHJ5 IGZpbGxpbmcgb3V0IHdvcmQgdG8gcmlnaHQgKi8KCXAgPSBwMTsKCXdoaWxlKHAgPCBmLT5VLm5j ICYmIGFsbnVtKGZpbGVyZWFkYyhmLCBwKyspKSkKCQlmLT5kb3Quci5wMisrOwoJLyogdHJ5IGZp bGxpbmcgb3V0IHdvcmQgdG8gbGVmdCAqLwoJcCA9IHAxOwoJd2hpbGUoLS1wID49IDAgJiYgYWxu dW0oZmlsZXJlYWRjKGYsIHApKSkKCQlmLT5kb3Quci5wMS0tOwp9CgoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABzYW0yay9zYW0vbXVsdGkuYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAx NzM3ADAwMDAxNTEAMDAwMDAwMDM0NjYAMDcxMTE2MjIxMDUAMDAxNTA0MgAwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwc2Nod2FydHoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABnY3NlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwNDAAMDAw MDAyNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACNpbmNsdWRlICJzYW0uaCIKCkxpc3QJZmlsZTsKdXNob3J0CXRhZzsKCkZpbGUgKgpuZXdmaWxl KHZvaWQpCnsKCUZpbGUgKmY7CgoJZiA9IGZpbGVvcGVuKCk7CglpbnNsaXN0KCZmaWxlLCAwLCAo bG9uZylmKTsKCWYtPnRhZyA9IHRhZysrOwoJaWYoZG93bmxvYWRlZCkKCQlvdXRUcyhIbmV3bmFt ZSwgZi0+dGFnKTsKCS8qIGFscmVhZHkgc29ydGVkOyBmaWxlIG5hbWUgaXMgIiIgKi8KCXJldHVy biBmOwp9CgppbnQKd2hpY2htZW51KEZpbGUgKmYpCnsKCWludCBpOwoKCWZvcihpPTA7IGk8Zmls ZS5udXNlZDsgaSsrKQoJCWlmKGZpbGUuZmlsZXBwdHJbaV09PWYpCgkJCXJldHVybiBpOwoJcmV0 dXJuIC0xOwp9Cgp2b2lkCmRlbGZpbGUoRmlsZSAqZikKewoJaW50IHcgPSB3aGljaG1lbnUoZik7 CgoJaWYodyA8IDApCS8qIGUuZy4geC8uL0QgKi8KCQlyZXR1cm47CglpZihkb3dubG9hZGVkKQoJ CW91dFRzKEhkZWxuYW1lLCBmLT50YWcpOwoJZGVsbGlzdCgmZmlsZSwgdyk7CglmaWxlY2xvc2Uo Zik7Cn0KCnZvaWQKZnVsbG5hbWUoU3RyaW5nICpuYW1lKQp7CglpZihuYW1lLT5uID4gMCAmJiBu YW1lLT5zWzBdIT0nLycgJiYgbmFtZS0+c1swXSE9MCkKCQlTdHJpbnNlcnQobmFtZSwgJmN1cndk LCAoUG9zbikwKTsKfQoKdm9pZApmaXhuYW1lKFN0cmluZyAqbmFtZSkKewoJU3RyaW5nICp0OwoJ Y2hhciAqczsKCglmdWxsbmFtZShuYW1lKTsKCXMgPSBTdHJ0b2MobmFtZSk7CglpZihzdHJsZW4o cykgPiAwKQoJCXMgPSBjbGVhbm5hbWUocyk7Cgl0ID0gdG1wY3N0cihzKTsKCVN0cmR1cGxzdHIo bmFtZSwgdCk7CglmcmVlKHMpOwoJZnJlZXRtcHN0cih0KTsKCglpZihTdHJpc3ByZSgmY3Vyd2Qs IG5hbWUpKQoJCVN0cmRlbGV0ZShuYW1lLCAwLCBjdXJ3ZC5uKTsKfQoKdm9pZApzb3J0bmFtZShG aWxlICpmKQp7CglpbnQgaSwgY21wLCB3OwoJaW50IGR1cHdhcm5lZDsKCgl3ID0gd2hpY2htZW51 KGYpOwoJZHVwd2FybmVkID0gRkFMU0U7CglkZWxsaXN0KCZmaWxlLCB3KTsKCWlmKGYgPT0gY21k KQoJCWkgPSAwOwoJZWxzZXsKCQlmb3IoaT0wOyBpPGZpbGUubnVzZWQ7IGkrKyl7CgkJCWNtcCA9 IFN0cmNtcCgmZi0+bmFtZSwgJmZpbGUuZmlsZXBwdHJbaV0tPm5hbWUpOwoJCQlpZihjbXA9PTAg JiYgIWR1cHdhcm5lZCl7CgkJCQlkdXB3YXJuZWQgPSBUUlVFOwoJCQkJd2Fybl9TKFdkdXBuYW1l LCAmZi0+bmFtZSk7CgkJCX1lbHNlIGlmKGNtcDwwICYmIChpPjAgfHwgY21kPT0wKSkKCQkJCWJy ZWFrOwoJCX0KCX0KCWluc2xpc3QoJmZpbGUsIGksIChsb25nKWYpOwoJaWYoZG93bmxvYWRlZCkK CQlvdXRUc1MoSG1vdm5hbWUsIGYtPnRhZywgJmYtPm5hbWUpOwp9Cgp2b2lkCnN0YXRlKEZpbGUg KmYsIGludCBjbGVhbmRpcnR5KQp7CglpZihmID09IGNtZCkKCQlyZXR1cm47CglmLT51bnJlYWQg PSBGQUxTRTsKCWlmKGRvd25sb2FkZWQgJiYgd2hpY2htZW51KGYpPj0wKXsJLyogZWxzZSBmbGlz dCBvciBtZW51ICovCgkJaWYoZi0+bW9kICYmIGNsZWFuZGlydHkhPURpcnR5KQoJCQlvdXRUcyhI Y2xlYW4sIGYtPnRhZyk7CgkJZWxzZSBpZighZi0+bW9kICYmIGNsZWFuZGlydHk9PURpcnR5KQoJ CQlvdXRUcyhIZGlydHksIGYtPnRhZyk7Cgl9CglpZihjbGVhbmRpcnR5ID09IENsZWFuKQoJCWYt Pm1vZCA9IEZBTFNFOwoJZWxzZQoJCWYtPm1vZCA9IFRSVUU7Cn0KCkZpbGUgKgpsb29rZmlsZShT dHJpbmcgKnMpCnsKCWludCBpOwoKCWZvcihpPTA7IGk8ZmlsZS5udXNlZDsgaSsrKQoJCWlmKFN0 cmNtcCgmZmlsZS5maWxlcHB0cltpXS0+bmFtZSwgcykgPT0gMCkKCQkJcmV0dXJuIGZpbGUuZmls ZXBwdHJbaV07CglyZXR1cm4gMDsKfQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2Ft Mmsvc2FtL3BhcnNlLmgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAw MDAwMTUxADAwMDAwMDAzNTY2ADA3MTExNjM1NzEwADAwMTUwMzYAMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0eXBl ZGVmIHN0cnVjdCBBZGRyIEFkZHI7CnR5cGVkZWYgc3RydWN0IENtZCBDbWQ7CnN0cnVjdCBBZGRy CnsKCWNoYXIJdHlwZTsJLyogIyAoY2hhciBhZGRyKSwgbCAobGluZSBhZGRyKSwgLyA/IC4gJCAr IC0gLCA7ICovCgl1bmlvbnsKCQlTdHJpbmcJKnJlOwoJCUFkZHIJKmFsZWZ0OwkJLyogbGVmdCBz aWRlIG9mICwgYW5kIDsgKi8KCX0gZzsKCVBvc24JbnVtOwoJQWRkcgkqbmV4dDsJCQkvKiBvciBy aWdodCBzaWRlIG9mICwgYW5kIDsgKi8KfTsKCiNkZWZpbmUJYXJlCWcucmUKI2RlZmluZQlsZWZ0 CWcuYWxlZnQKCnN0cnVjdCBDbWQKewoJQWRkcgkqYWRkcjsJCQkvKiBhZGRyZXNzIChyYW5nZSBv ZiB0ZXh0KSAqLwoJU3RyaW5nCSpyZTsJCQkvKiByZWd1bGFyIGV4cHJlc3Npb24gZm9yIGUuZy4g J3gnICovCgl1bmlvbnsKCQlDbWQJKmNtZDsJCS8qIHRhcmdldCBvZiB4LCBnLCB7LCBldGMuICov CgkJU3RyaW5nCSp0ZXh0OwkJLyogdGV4dCBvZiBhLCBjLCBpOyByaHMgb2YgcyAqLwoJCUFkZHIJ KmFkZHI7CQkvKiBhZGRyZXNzIGZvciBtLCB0ICovCgl9IGc7CglDbWQJKm5leHQ7CQkJLyogcG9p bnRlciB0byBuZXh0IGVsZW1lbnQgaW4ge30gKi8KCXNob3J0CW51bTsKCXVzaG9ydAlmbGFnOwkJ CS8qIHdoYXRldmVyICovCgl1c2hvcnQJY21kYzsJCQkvKiBjb21tYW5kIGNoYXJhY3RlcjsgJ3gn IGV0Yy4gKi8KfTsKCiNkZWZpbmUJY2NtZAlnLmNtZAojZGVmaW5lCWN0ZXh0CWcudGV4dAojZGVm aW5lCWNhZGRyCWcuYWRkcgoKZXh0ZXJuIHN0cnVjdCBjbWR0YWJ7Cgl1c2hvcnQJY21kYzsJCS8q IGNvbW1hbmQgY2hhcmFjdGVyICovCgl1Y2hhcgl0ZXh0OwkJLyogdGFrZXMgYSB0ZXh0dWFsIGFy Z3VtZW50PyAqLwoJdWNoYXIJcmVnZXhwOwkJLyogdGFrZXMgYSByZWd1bGFyIGV4cHJlc3Npb24/ ICovCgl1Y2hhcglhZGRyOwkJLyogdGFrZXMgYW4gYWRkcmVzcyAobSBvciB0KT8gKi8KCXVjaGFy CWRlZmNtZDsJCS8qIGRlZmF1bHQgY29tbWFuZDsgMD09Pm5vbmUgKi8KCXVjaGFyCWRlZmFkZHI7 CS8qIGRlZmF1bHQgYWRkcmVzcyAqLwoJdWNoYXIJY291bnQ7CQkvKiB0YWtlcyBhIGNvdW50IGUu Zy4gczIvLy8gKi8KCWNoYXIJKnRva2VuOwkJLyogdGFrZXMgdGV4dCB0ZXJtaW5hdGVkIGJ5IG9u ZSBvZiB0aGVzZSAqLwoJaW50CSgqZm4pKEZpbGUqLCBDbWQqKTsJLyogZnVuY3Rpb24gdG8gY2Fs bCB3aXRoIHBhcnNlIHRyZWUgKi8KfWNtZHRhYltdOwoKZW51bSBEZWZhZGRyewkvKiBkZWZhdWx0 IGFkZHJlc3NlcyAqLwoJYU5vLAoJYURvdCwKCWFBbGwgCn07CgppbnQJbmxfY21kKEZpbGUqLCBD bWQqKSwgYV9jbWQoRmlsZSosIENtZCopLCBiX2NtZChGaWxlKiwgQ21kKik7CmludAljX2NtZChG aWxlKiwgQ21kKiksIGNkX2NtZChGaWxlKiwgQ21kKiksIGRfY21kKEZpbGUqLCBDbWQqKTsKaW50 CURfY21kKEZpbGUqLCBDbWQqKSwgZV9jbWQoRmlsZSosIENtZCopOwppbnQJZl9jbWQoRmlsZSos IENtZCopLCBnX2NtZChGaWxlKiwgQ21kKiksIGlfY21kKEZpbGUqLCBDbWQqKTsKaW50CWtfY21k KEZpbGUqLCBDbWQqKSwgbV9jbWQoRmlsZSosIENtZCopLCBuX2NtZChGaWxlKiwgQ21kKik7Cmlu dAlwX2NtZChGaWxlKiwgQ21kKiksIHFfY21kKEZpbGUqLCBDbWQqKTsKaW50CXNfY21kKEZpbGUq LCBDbWQqKSwgdV9jbWQoRmlsZSosIENtZCopLCB3X2NtZChGaWxlKiwgQ21kKik7CmludAl4X2Nt ZChGaWxlKiwgQ21kKiksIFhfY21kKEZpbGUqLCBDbWQqKSwgcGxhbjlfY21kKEZpbGUqLCBDbWQq KTsKaW50CWVxX2NtZChGaWxlKiwgQ21kKik7CgoKU3RyaW5nCSpnZXRyZWdleHAoaW50KTsKQWRk cgkqbmV3YWRkcih2b2lkKTsKQWRkcmVzcwlhZGRyZXNzKEFkZHIqLCBBZGRyZXNzLCBpbnQpOwpp bnQJY21kZXhlYyhGaWxlKiwgQ21kKik7CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNhbTJrL3Nh bS9wbGFuOS5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDE3MzcAMDAwMDE1 MQAwMDAwMDAwNTEzNwAwNzExMTYyMzI0MQAwMDE0NzMyADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAwMDI3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI2luY2x1ZGUg InNhbS5oIgoKUnVuZQlzYW1uYW1lW10gPSBMIn5+c2Ftfn4iOwoKUnVuZSAqbGVmdFtdPSB7CglM IntbKDzCqyIsCglMIlxuIiwKCUwiJ1wiYCIsCgkwCn07ClJ1bmUgKnJpZ2h0W109IHsKCUwifV0p PsK7IiwKCUwiXG4iLAoJTCInXCJgIiwKCTAKfTsKCmNoYXIJUlNBTVtdID0gInNhbSI7CmNoYXIJ U0FNVEVSTVtdID0gIi9iaW4vYXV4L3NhbXRlcm0iOwpjaGFyCUhPTUVbXSA9ICJob21lIjsKY2hh cglUTVBESVJbXSA9ICIvdG1wIjsKY2hhcglTSFtdID0gInJjIjsKY2hhcglTSFBBVEhbXSA9ICIv YmluL3JjIjsKY2hhcglSWFtdID0gInJ4IjsKY2hhcglSWFBBVEhbXSA9ICIvYmluL3J4IjsKY2hh cglTQU1TQVZFQ01EW10gPSAiL2Jpbi9yY1xuL3N5cy9saWIvc2Ftc2F2ZSI7Cgp2b2lkCmRwcmlu dChjaGFyICp6LCAuLi4pCnsKCWNoYXIgYnVmW0JMT0NLU0laRV07Cgl2YV9saXN0IGFyZzsKCgl2 YV9zdGFydChhcmcsIHopOwoJZG9wcmludChidWYsICZidWZbQkxPQ0tTSVpFXSwgeiwgYXJnKTsK CXZhX2VuZChhcmcpOwoJdGVybXdyaXRlKGJ1Zik7Cn0KCnZvaWQKcHJpbnRfc3MoY2hhciAqcywg U3RyaW5nICphLCBTdHJpbmcgKmIpCnsKCWRwcmludCgiP3dhcm5pbmc6ICVzOiBgJS4qUycgYW5k IGAlLipTJ1xuIiwgcywgYS0+biwgYS0+cywgYi0+biwgYi0+cyk7Cn0KCnZvaWQKcHJpbnRfcyhj aGFyICpzLCBTdHJpbmcgKmEpCnsKCWRwcmludCgiP3dhcm5pbmc6ICVzIGAlLipTJ1xuIiwgcywg YS0+biwgYS0+cyk7Cn0KCmNoYXIqCmdldHVzZXIodm9pZCkKewoJc3RhdGljIGNoYXIgdXNlcltO QU1FTEVOXTsKCWludCBmZDsKCglpZih1c2VyWzBdID09IDApewoJCWZkID0gb3BlbigiL2Rldi91 c2VyIiwgMCk7CgkJaWYoZmQ8MCB8fCByZWFkKGZkLCB1c2VyLCBzaXplb2YgdXNlcik8PTApCgkJ CXN0cmNweSh1c2VyLCAibm9uZSIpOwoJCWNsb3NlKGZkKTsKCX0KCXJldHVybiB1c2VyOwp9Cgpp bnQKc3RhdGZpbGUoY2hhciAqbmFtZSwgdWxvbmcgKmRldiwgdWxvbmcgKmlkLCBsb25nICp0aW1l LCBsb25nICpsZW5ndGgsIGxvbmcgKmFwcGVuZG9ubHkpCnsKCURpciBkaXJiOwoKCWlmKGRpcnN0 YXQobmFtZSwgJmRpcmIpID09IC0xKQoJCXJldHVybiAtMTsKCWlmKGRldikKCQkqZGV2ID0gZGly Yi50eXBlfChkaXJiLmRldjw8MTYpOwoJaWYoaWQpCgkJKmlkID0gZGlyYi5xaWQucGF0aDsKCWlm KHRpbWUpCgkJKnRpbWUgPSBkaXJiLm10aW1lOwoJaWYobGVuZ3RoKQoJCSpsZW5ndGggPSBkaXJi Lmxlbmd0aDsKCWlmKGFwcGVuZG9ubHkpCgkJKmFwcGVuZG9ubHkgPSBkaXJiLm1vZGUgJiBDSEFQ UEVORDsKCXJldHVybiAxOwp9CgppbnQKc3RhdGZkKGludCBmZCwgdWxvbmcgKmRldiwgdWxvbmcg KmlkLCBsb25nICp0aW1lLCBsb25nICpsZW5ndGgsIGxvbmcgKmFwcGVuZG9ubHkpCnsKCURpciBk aXJiOwoKCWlmKGRpcmZzdGF0KGZkLCAmZGlyYikgPT0gLTEpCgkJcmV0dXJuIC0xOwoJaWYoZGV2 KQoJCSpkZXYgPSBkaXJiLnR5cGV8KGRpcmIuZGV2PDwxNik7CglpZihpZCkKCQkqaWQgPSBkaXJi LnFpZC5wYXRoOwoJaWYodGltZSkKCQkqdGltZSA9IGRpcmIubXRpbWU7CglpZihsZW5ndGgpCgkJ Kmxlbmd0aCA9IGRpcmIubGVuZ3RoOwoJaWYoYXBwZW5kb25seSkKCQkqYXBwZW5kb25seSA9IGRp cmIubW9kZSAmIENIQVBQRU5EOwoJcmV0dXJuIDE7Cn0KCnZvaWQKbm90aWZ5Zih2b2lkICphLCBj aGFyICpzKQp7CglVU0VEKGEpOwoJaWYoYnBpcGVvayAmJiBzdHJjbXAocywgInN5czogd3JpdGUg b24gY2xvc2VkIHBpcGUiKSA9PSAwKQoJCW5vdGVkKE5DT05UKTsKCWlmKHN0cmNtcChzLCAiaW50 ZXJydXB0IikgPT0gMCkKCQlub3RlZChOQ09OVCk7CglwYW5pY2tpbmcgPSAxOwoJcmVzY3VlKCk7 Cglub3RlZChOREZMVCk7Cn0KCmludApuZXd0bXAoaW50IG51bSkKewoJaW50IGksIGZkOwoJc3Rh dGljIGNoYXIJdGVtcG5hbVszMF07CgoJaSA9IGdldHBpZCgpOwoJZG8KCQlzcHJpbnQodGVtcG5h bSwgIiVzLyVkJS40cyVkc2FtIiwgVE1QRElSLCBudW0sIGdldHVzZXIoKSwgaSsrKTsKCXdoaWxl KGFjY2Vzcyh0ZW1wbmFtLCAwKSA9PSAwKTsKCWZkID0gY3JlYXRlKHRlbXBuYW0sIE9SRFdSfE9D RVhFQ3xPUkNMT1NFLCAwMDAwKTsKCWlmKGZkIDwgMCl7CgkJcmVtb3ZlKHRlbXBuYW0pOwoJCWZk ID0gY3JlYXRlKHRlbXBuYW0sIE9SRFdSfE9DRVhFQ3xPUkNMT1NFLCAwMDAwKTsKCX0KCXJldHVy biBmZDsKfQoKaW50CndhaXRmb3IoaW50IHBpZCkKewoJaW50IHJwaWQ7CglXYWl0bXNnIHdtOwoK CWRvOyB3aGlsZSgocnBpZCA9IHdhaXQoJndtKSkgIT0gcGlkICYmIHJwaWQgIT0gLTEpOwoJcmV0 dXJuIHdtLm1zZ1swXTsKfQoKdm9pZApzYW1lcnIoY2hhciAqYnVmKQp7CglzcHJpbnQoYnVmLCAi JXMvc2FtLmVyciIsIFRNUERJUik7Cn0KCnZvaWQqCmVtYWxsb2ModWxvbmcgbikKewoJdm9pZCAq cDsKCglwID0gbWFsbG9jKG4pOwoJaWYocCA9PSAwKQoJCXBhbmljKCJtYWxsb2MgZmFpbHMiKTsK CW1lbXNldChwLCAwLCBuKTsKCXJldHVybiBwOwp9Cgp2b2lkKgplcmVhbGxvYyh2b2lkICpwLCB1 bG9uZyBuKQp7CglwID0gcmVhbGxvYyhwLCBuKTsKCWlmKHAgPT0gMCkKCQlwYW5pYygicmVhbGxv YyBmYWlscyIpOwoJcmV0dXJuIHA7Cn0KdHVybiAtMTsKCWlmKGRldikKCQkqZGV2ID0gZGlyYi50 eXBlfChkaXJiLmRldjw8MTYpOwoJaWYoaWQpCgkJKmlkID0gZGlyYi5xaWQucGF0aDsKCWlmKHRp bWUpCgkJKnRpbWUgPSBkaXJiLm10aW1lOwoJaWYobGVuZ3RoKQoJCSpsZW5ndGggPSBkaXJiLmxl bmd0aDsKCWlmKGFwcGVuZG9ubHkpCgkJKmFwcGVuZG9ubHkgPSBkaXJiLm1vZGUgJiBDSEFQUEVO RDsKCXJldHVybiAxOwp9CgppbnQKc3RhdGZkKGludCBmZCwgdWxvbmcgKmRldiwgdWxvbmcgKmlk LCBsb25nICp0aW1lLCBsb25nICpsZW5ndGgsIGxvbmcgKmFwcGVuZG9ubHkpCnsKCURpciBkaXJi OwoKCWlmKGRpcmZzdGF0KGZkLCAmZGlyYikgPT0gLTEpCgkJcmV0dXJuIC0xOwoJaWYoZGV2KQoJ CSpkZXYgPSBkaXJiLnR5cGV8KGRpcmIuZGV2PDwxNik7CglpZihpZCkKc2FtMmsvc2FtL3Jhc3Au YwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAw MDEzMDExADA3MTExNjM2MTI2ADAwMTQ2NTAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2Nz ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSAic2FtLmgi Ci8qCiAqIEdST1dEQVRBU0laRSBtdXN0IGJlIGJpZyBlbm91Z2ggdGhhdCBhbGwgZXJyb3JzIGdv IG91dCBhcyBIZ3Jvd2RhdGEncywKICogc28gdGhleSB3aWxsIGJlIHNjcm9sbGVkIGludG8gdmlz aWJpbGl0eSBpbiB0aGUgfn5zYW1+fiB3aW5kb3cgKHl1Y2shKS4KICovCiNkZWZpbmUJR1JPV0RB VEFTSVpFCTUwCS8qIGlmIHNpemUgaXMgPiB0aGlzLCBzZW5kIGRhdGEgd2l0aCBncm93ICovCgp2 b2lkCXJjdXQoTGlzdCosIFBvc24sIFBvc24pOwppbnQJcnRlcm0oTGlzdCosIFBvc24pOwp2b2lk CXJncm93KExpc3QqLCBQb3NuLCBQb3NuKTsKCnN0YXRpYwlQb3NuCWdyb3dwb3M7CnN0YXRpYwlQ b3NuCWdyb3duOwpzdGF0aWMJUG9zbglzaHJpbmtwb3M7CnN0YXRpYwlQb3NuCXNocnVuazsKCi8q CiAqIHJhc3Agcm91dGluZXMgaW5mb3JtIHRoZSB0ZXJtaW5hbCBvZiBjaGFuZ2VzIHRvIHRoZSBm aWxlLgogKgogKiBhIHJhc3AgaXMgYSBsaXN0IG9mIHNwYW5zIHdpdGhpbiB0aGUgZmlsZSwgYW5k IGFuIGluZGljYXRpb24KICogb2Ygd2hldGhlciB0aGUgdGVybWluYWwga25vd3MgYWJvdXQgdGhl IHNwYW4uCiAqCiAqIG9wdGltaXplIGJ5IGNvYWxlc2NpbmcgbXVsdGlwbGUgdXBkYXRlcyB0byB0 aGUgc2FtZSBzcGFuCiAqIGlmIGl0IGlzIG5vdCBrbm93biBieSB0aGUgdGVybWluYWwuCiAqCiAq IG90aGVyIHBvc3NpYmxlIG9wdGltaXphdGlvbnM6IGZsdXNoIHRlcm1pbmFsJ3MgcmFzcCBieSBj dXQgZXZlcnl0aGluZywKICogaW5zZXJ0IGV2ZXJ5dGhpbmcgaWYgcmFzcCBnZXRzIHRvbyBsYXJn ZS4KICovCgovKgogKiBvbmx5IGNhbGxlZCBmb3IgaW5pdGlhbCBsb2FkIG9mIGZpbGUKICovCnZv aWQKcmFzcGxvYWQoRmlsZSAqZikKewoJaWYoZi0+cmFzcCA9PSBuaWwpCgkJcmV0dXJuOwoJZ3Jv d24gPSBmLT5VLm5jOwoJZ3Jvd3BvcyA9IDA7CglpZihmLT5VLm5jKQoJCXJncm93KGYtPnJhc3As IDAsIGYtPlUubmMpOwoJcmFzcGRvbmUoZiwgMSk7Cn0KCnZvaWQKcmFzcHN0YXJ0KEZpbGUgKmYp CnsKCWlmKGYtPnJhc3AgPT0gbmlsKQoJCXJldHVybjsKCWdyb3duID0gMDsKCXNocnVuayA9IDA7 Cglub2ZsdXNoID0gMTsKfQoKdm9pZApyYXNwZG9uZShGaWxlICpmLCBpbnQgdG90ZXJtKQp7Cglp ZihmLT5kb3Quci5wMSA+IGYtPlUubmMpCgkJZi0+ZG90LnIucDEgPSBmLT5VLm5jOwoJaWYoZi0+ ZG90LnIucDIgPiBmLT5VLm5jKQoJCWYtPmRvdC5yLnAyID0gZi0+VS5uYzsKCWlmKGYtPm1hcmsu cDEgPiBmLT5VLm5jKQoJCWYtPm1hcmsucDEgPSBmLT5VLm5jOwoJaWYoZi0+bWFyay5wMiA+IGYt PlUubmMpCgkJZi0+bWFyay5wMiA9IGYtPlUubmM7CglpZihmLT5yYXNwID09IG5pbCkKCQlyZXR1 cm47CglpZihncm93bikKCQlvdXRUc2xsKEhncm93LCBmLT50YWcsIGdyb3dwb3MsIGdyb3duKTsK CWVsc2UgaWYoc2hydW5rKQoJCW91dFRzbGwoSGN1dCwgZi0+dGFnLCBzaHJpbmtwb3MsIHNocnVu ayk7CglpZih0b3Rlcm0pCgkJb3V0VHMoSGNoZWNrMCwgZi0+dGFnKTsKCW91dGZsdXNoKCk7Cglu b2ZsdXNoID0gMDsKCWlmKGYgPT0gY21kKXsKCQljbWRwdCArPSBjbWRwdGFkdjsKCQljbWRwdGFk diA9IDA7Cgl9Cn0KCnZvaWQKcmFzcGRlbGV0ZShGaWxlICpmLCB1aW50IHAxLCB1aW50IHAyLCBp bnQgdG90ZXJtKQp7Cglsb25nIG47CgoJbiA9IHAyIC0gcDE7CglpZihuID09IDApCgkJcmV0dXJu OwoKCWlmKHAyIDw9IGYtPmRvdC5yLnAxKXsKCQlmLT5kb3Quci5wMSAtPSBuOwoJCWYtPmRvdC5y LnAyIC09IG47Cgl9CglpZihwMiA8PSBmLT5tYXJrLnAxKXsKCQlmLT5tYXJrLnAxIC09IG47CgkJ Zi0+bWFyay5wMiAtPSBuOwoJfQoKCWlmKGYtPnJhc3AgPT0gbmlsKQoJCXJldHVybjsKCglpZihm PT1jbWQgJiYgcDE8Y21kcHQpewoJCWlmKHAyIDw9IGNtZHB0KQoJCQljbWRwdCAtPSBuOwoJCWVs c2UKCQkJY21kcHQgPSBwMTsKCX0KCWlmKHRvdGVybSl7CgkJaWYoZ3Jvd24pewoJCQlvdXRUc2xs KEhncm93LCBmLT50YWcsIGdyb3dwb3MsIGdyb3duKTsKCQkJZ3Jvd24gPSAwOwoJCX1lbHNlIGlm KHNocnVuayAmJiBzaHJpbmtwb3MhPXAxICYmIHNocmlua3BvcyE9cDIpewoJCQlvdXRUc2xsKEhj dXQsIGYtPnRhZywgc2hyaW5rcG9zLCBzaHJ1bmspOwoJCQlzaHJ1bmsgPSAwOwoJCX0KCQlpZigh c2hydW5rIHx8IHNocmlua3Bvcz09cDIpCgkJCXNocmlua3BvcyA9IHAxOwoJCXNocnVuayArPSBu OwoJfQoJcmN1dChmLT5yYXNwLCBwMSwgcDIpOwp9Cgp2b2lkCnJhc3BpbnNlcnQoRmlsZSAqZiwg dWludCBwMSwgUnVuZSAqYnVmLCB1aW50IG4sIGludCB0b3Rlcm0pCnsKCVJhbmdlIHI7CgoJaWYo biA9PSAwKQoJCXJldHVybjsKCglpZihwMSA8IGYtPmRvdC5yLnAxKXsKCQlmLT5kb3Quci5wMSAr PSBuOwoJCWYtPmRvdC5yLnAyICs9IG47Cgl9CglpZihwMSA8IGYtPm1hcmsucDEpewoJCWYtPm1h cmsucDEgKz0gbjsKCQlmLT5tYXJrLnAyICs9IG47Cgl9CgoKCWlmKGYtPnJhc3AgPT0gbmlsKQoJ CXJldHVybjsKCWlmKGY9PWNtZCAmJiBwMTxjbWRwdCkKCQljbWRwdCArPSBuOwoJaWYodG90ZXJt KXsKCQlpZihzaHJ1bmspewoJCQlvdXRUc2xsKEhjdXQsIGYtPnRhZywgc2hyaW5rcG9zLCBzaHJ1 bmspOwoJCQlzaHJ1bmsgPSAwOwoJCX0KCQlpZihuPkdST1dEQVRBU0laRSB8fCAhcnRlcm0oZi0+ cmFzcCwgcDEpKXsKCQkJcmdyb3coZi0+cmFzcCwgcDEsIG4pOwoJCQlpZihncm93biAmJiBncm93 cG9zK2dyb3duIT1wMSAmJiBncm93cG9zIT1wMSl7CgkJCQlvdXRUc2xsKEhncm93LCBmLT50YWcs IGdyb3dwb3MsIGdyb3duKTsKCQkJCWdyb3duID0gMDsKCQkJfQoJCQlpZighZ3Jvd24pCgkJCQln cm93cG9zID0gcDE7CgkJCWdyb3duICs9IG47CgkJfWVsc2V7CgkJCWlmKGdyb3duKXsKCQkJCW91 dFRzbGwoSGdyb3csIGYtPnRhZywgZ3Jvd3BvcywgZ3Jvd24pOwoJCQkJZ3Jvd24gPSAwOwoJCQl9 CgkJCXJncm93KGYtPnJhc3AsIHAxLCBuKTsKCQkJciA9IHJkYXRhKGYtPnJhc3AsIHAxLCBuKTsK CQkJaWYoci5wMSE9cDEgfHwgci5wMiE9cDErbikKCQkJCXBhbmljKCJyZGF0YSBpbiB0b3Rlcm1p bmFsIik7CgkJCW91dFRzbGxTKEhncm93ZGF0YSwgZi0+dGFnLCBwMSwgbiwgdG1wcnN0cihidWYs IG4pKTsKCQl9Cgl9ZWxzZXsKCQlyZ3JvdyhmLT5yYXNwLCBwMSwgbik7CgkJciA9IHJkYXRhKGYt PnJhc3AsIHAxLCBuKTsKCQlpZihyLnAxIT1wMSB8fCByLnAyIT1wMStuKQoJCQlwYW5pYygicmRh dGEgaW4gdG90ZXJtaW5hbCIpOwoJfQp9CgojZGVmaW5lCU0JMHg4MDAwMDAwMFVMCiNkZWZpbmUJ UChpKQlyLT5sb25ncHRyW2ldCiNkZWZpbmUJVChpKQkoUChpKSZNKQkvKiBpbiB0ZXJtaW5hbCAq LwojZGVmaW5lCUwoaSkJKFAoaSkmfk0pCS8qIGxlbmd0aCBvZiB0aGlzIHBpZWNlICovCgp2b2lk CnJjdXQoTGlzdCAqciwgUG9zbiBwMSwgUG9zbiBwMikKewoJUG9zbiBwLCB4OwoJaW50IGk7CgoJ aWYocDEgPT0gcDIpCgkJcGFuaWMoInJjdXQgMCIpOwoJZm9yKHA9MCxpPTA7IGk8ci0+bnVzZWQg JiYgcCtMKGkpPD1wMTsgcCs9TChpKyspKQoJCTsKCWlmKGkgPT0gci0+bnVzZWQpCgkJcGFuaWMo InJjdXQgMSIpOwoJaWYocCA8IHAxKXsJLyogY2hvcCB0aGlzIHBpZWNlICovCgkJaWYocCtMKGkp IDwgcDIpewoJCQl4ID0gcDEtcDsKCQkJcCArPSBMKGkpOwoJCX1lbHNlewoJCQl4ID0gTChpKS0o cDItcDEpOwoJCQlwID0gcDI7CgkJfQoJCWlmKFQoaSkpCgkJCVAoaSkgPSB4fE07CgkJZWxzZQoJ CQlQKGkpID0geDsKCQlpKys7Cgl9Cgl3aGlsZShpPHItPm51c2VkICYmIHArTChpKTw9cDIpewoJ CXAgKz0gTChpKTsKCQlkZWxsaXN0KHIsIGkpOwoJfQoJaWYocCA8IHAyKXsKCQlpZihpID09IHIt Pm51c2VkKQoJCQlwYW5pYygicmN1dCAyIik7CgkJeCA9IEwoaSktKHAyLXApOwoJCWlmKFQoaSkp CgkJCVAoaSkgPSB4fE07CgkJZWxzZQoJCQlQKGkpID0geDsKCX0KCS8qIGNhbiB3ZSBtZXJnZSBp IGFuZCBpLTEgPyAqLwoJaWYoaT4wICYmIGk8ci0+bnVzZWQgJiYgVChpLTEpPT1UKGkpKXsKCQl4 ID0gTChpLTEpK0woaSk7CgkJZGVsbGlzdChyLCBpLS0pOwoJCWlmKFQoaSkpCgkJCVAoaSk9eHxN OwoJCWVsc2UKCQkJUChpKT14OwoJfQp9Cgp2b2lkCnJncm93KExpc3QgKnIsIFBvc24gcDEsIFBv c24gbikKewoJUG9zbiBwOwoJaW50IGk7CgoJaWYobiA9PSAwKQoJCXBhbmljKCJyZ3JvdyAwIik7 Cglmb3IocD0wLGk9MDsgaTxyLT5udXNlZCAmJiBwK0woaSk8PXAxOyBwKz1MKGkrKykpCgkJOwoJ aWYoaSA9PSByLT5udXNlZCl7CS8qIHN0aWNrIG9uIGVuZCBvZiBmaWxlICovCgkJaWYocCE9cDEp CgkJCXBhbmljKCJyZ3JvdyAxIik7CgkJaWYoaT4wICYmICFUKGktMSkpCgkJCVAoaS0xKSs9bjsK CQllbHNlCgkJCWluc2xpc3QociwgaSwgbik7Cgl9ZWxzZSBpZighVChpKSkJCS8qIGdvZXMgaW4g dGhpcyBlbXB0eSBwaWVjZSAqLwoJCVAoaSkrPW47CgllbHNlIGlmKHA9PXAxICYmIGk+MCAmJiAh VChpLTEpKQkvKiBzcGVjaWFsIGNhc2U7IHNpbXBsaWZpZXMgbGlmZSAqLwoJCVAoaS0xKSs9bjsK CWVsc2UgaWYocD09cDEpCgkJaW5zbGlzdChyLCBpLCBuKTsKCWVsc2V7CQkJLyogbXVzdCBicmVh ayBwaWVjZSBpbiB0ZXJtaW5hbCAqLwoJCWluc2xpc3QociwgaSsxLCAoTChpKS0ocDEtcCkpfE0p OwoJCWluc2xpc3QociwgaSsxLCBuKTsKCQlQKGkpID0gKHAxLXApfE07Cgl9Cn0KCmludApydGVy bShMaXN0ICpyLCBQb3NuIHAxKQp7CglQb3NuIHA7CglpbnQgaTsKCglmb3IocCA9IDAsaSA9IDA7 IGk8ci0+bnVzZWQgJiYgcCtMKGkpPD1wMTsgcCs9TChpKyspKQoJCTsKCWlmKGk9PXItPm51c2Vk ICYmIChpPT0wIHx8ICFUKGktMSkpKQoJCXJldHVybiAwOwoJcmV0dXJuIFQoaSk7Cn0KClJhbmdl CnJkYXRhKExpc3QgKnIsIFBvc24gcDEsIFBvc24gbikKewoJUG9zbiBwOwoJaW50IGk7CglSYW5n ZSByZzsKCglpZihuPT0wKQoJCXBhbmljKCJyZGF0YSAwIik7Cglmb3IocCA9IDAsaSA9IDA7IGk8 ci0+bnVzZWQgJiYgcCtMKGkpPD1wMTsgcCs9TChpKyspKQoJCTsKCWlmKGk9PXItPm51c2VkKQoJ CXBhbmljKCJyZGF0YSAxIik7CglpZihUKGkpKXsKCQluLT1MKGkpLShwMS1wKTsKCQlpZihuPD0w KXsKCQkJcmcucDEgPSByZy5wMiA9IHAxOwoJCQlyZXR1cm4gcmc7CgkJfQoJCXArPUwoaSsrKTsK CQlwMSA9IHA7Cgl9CglpZihUKGkpIHx8IGk9PXItPm51c2VkKQoJCXBhbmljKCJyZGF0YSAyIik7 CglpZihwK0woaSk8cDErbikKCQluID0gTChpKS0ocDEtcCk7CglyZy5wMSA9IHAxOwoJcmcucDIg PSBwMStuOwoJaWYocCE9cDEpewoJCWluc2xpc3QociwgaSsxLCBMKGkpLShwMS1wKSk7CgkJUChp KT1wMS1wOwoJCWkrKzsKCX0KCWlmKEwoaSkhPW4pewoJCWluc2xpc3QociwgaSsxLCBMKGkpLW4p OwoJCVAoaSk9bjsKCX0KCVAoaSl8PU07CgkvKiBub3cgaSBpcyBzZXQ7IGNhbiB3ZSBtZXJnZT8g Ki8KCWlmKGk8ci0+bnVzZWQtMSAmJiBUKGkrMSkpewoJCVAoaSk9KG4rPUwoaSsxKSl8TTsKCQlk ZWxsaXN0KHIsIGkrMSk7Cgl9CglpZihpPjAgJiYgVChpLTEpKXsKCQlQKGkpPShuK0woaS0xKSl8 TTsKCQlkZWxsaXN0KHIsIGktMSk7Cgl9CglyZXR1cm4gcmc7Cn0KAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzYW0yay9zYW0vcmVnZXhwLmMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAxNzM3ADAwMDAxNTEAMDAwMDAwMzYwNDIAMDcxMTE2 MjIxMDUAMDAxNTE3NgAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHVzdGFyADAwc2Nod2FydHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnY3NlAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADAwMDAwNDAAMDAwMDAyNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNpbmNsdWRlICJzYW0uaCIKClJhbmdlc2V0CXNl bDsKU3RyaW5nCQlsYXN0cmVnZXhwOwovKgogKiBNYWNoaW5lIEluZm9ybWF0aW9uCiAqLwp0eXBl ZGVmIHN0cnVjdCBJbnN0IEluc3Q7CgpzdHJ1Y3QgSW5zdAp7Cglsb25nCXR5cGU7CS8qIDwgMHgx MDAwMCA9PT4gbGl0ZXJhbCwgb3RoZXJ3aXNlIGFjdGlvbiAqLwoJdW5pb24gewoJCWludCByc2lk OwoJCWludCByc3ViaWQ7CgkJaW50IGNsYXNzOwoJCXN0cnVjdCBJbnN0ICpyb3RoZXI7CgkJc3Ry dWN0IEluc3QgKnJyaWdodDsKCX0gcjsKCXVuaW9uewoJCXN0cnVjdCBJbnN0ICpsbGVmdDsKCQlz dHJ1Y3QgSW5zdCAqbG5leHQ7Cgl9IGw7Cn07CiNkZWZpbmUJc2lkCXIucnNpZAojZGVmaW5lCXN1 YmlkCXIucnN1YmlkCiNkZWZpbmUJcmNsYXNzCXIuY2xhc3MKI2RlZmluZQlvdGhlcglyLnJvdGhl cgojZGVmaW5lCXJpZ2h0CXIucnJpZ2h0CiNkZWZpbmUJbGVmdAlsLmxsZWZ0CiNkZWZpbmUJbmV4 dAlsLmxuZXh0CgojZGVmaW5lCU5QUk9HCTEwMjQKSW5zdAlwcm9ncmFtW05QUk9HXTsKSW5zdAkq cHJvZ3A7Ckluc3QJKnN0YXJ0aW5zdDsJLyogRmlyc3QgaW5zdC4gb2YgcHJvZ3JhbTsgbWlnaHQg bm90IGJlIHByb2dyYW1bMF0gKi8KSW5zdAkqYnN0YXJ0aW5zdDsJLyogc2FtZSBmb3IgYmFja3dh cmRzIG1hY2hpbmUgKi8KCnR5cGVkZWYgc3RydWN0IElsaXN0IElsaXN0OwpzdHJ1Y3QgSWxpc3QK ewoJSW5zdAkqaW5zdDsJCS8qIEluc3RydWN0aW9uIG9mIHRoZSB0aHJlYWQgKi8KCVJhbmdlc2V0 IHNlOwoJUG9zbglzdGFydHA7CQkvKiBmaXJzdCBjaGFyIG9mIG1hdGNoICovCn07CgojZGVmaW5l CU5MSVNUCTEyOAoKSWxpc3QJKnRsLCAqbmw7CS8qIFRoaXMgbGlzdCwgbmV4dCBsaXN0ICovCkls aXN0CWxpc3RbMl1bTkxJU1RdOwpzdGF0aWMJUmFuZ2VzZXQgc2VtcHR5OwoKLyoKICogQWN0aW9u cyBhbmQgVG9rZW5zCiAqCiAqCTB4MTAweHggYXJlIG9wZXJhdG9ycywgdmFsdWUgPT0gcHJlY2Vk ZW5jZQogKgkweDIwMHh4IGFyZSB0b2tlbnMsIGkuZS4gb3BlcmFuZHMgZm9yIG9wZXJhdG9ycwog Ki8KI2RlZmluZQlPUEVSQVRPUgkweDEwMDAwCS8qIEJpdG1hc2sgb2YgYWxsIG9wZXJhdG9ycyAq LwojZGVmaW5lCVNUQVJUCQkweDEwMDAwCS8qIFN0YXJ0LCB1c2VkIGZvciBtYXJrZXIgb24gc3Rh Y2sgKi8KI2RlZmluZQlSQlJBCQkweDEwMDAxCS8qIFJpZ2h0IGJyYWNrZXQsICkgKi8KI2RlZmlu ZQlMQlJBCQkweDEwMDAyCS8qIExlZnQgYnJhY2tldCwgKCAqLwojZGVmaW5lCU9SCQkweDEwMDAz CS8qIEFsdGVybmF0aW9uLCB8ICovCiNkZWZpbmUJQ0FUCQkweDEwMDA0CS8qIENvbmNhdGVudGF0 aW9uLCBpbXBsaWNpdCBvcGVyYXRvciAqLwojZGVmaW5lCVNUQVIJCTB4MTAwMDUJLyogQ2xvc3Vy ZSwgKiAqLwojZGVmaW5lCVBMVVMJCTB4MTAwMDYJLyogYSsgPT0gYWEqICovCiNkZWZpbmUJUVVF U1QJCTB4MTAwMDcJLyogYT8gPT0gYXxub3RoaW5nLCBpLmUuIDAgb3IgMSBhJ3MgKi8KI2RlZmlu ZQlBTlkJCTB4MjAwMDAJLyogQW55IGNoYXJhY3RlciBidXQgbmV3bGluZSwgLiAqLwojZGVmaW5l CU5PUAkJMHgyMDAwMQkvKiBObyBvcGVyYXRpb24sIGludGVybmFsIHVzZSBvbmx5ICovCiNkZWZp bmUJQk9MCQkweDIwMDAyCS8qIEJlZ2lubmluZyBvZiBsaW5lLCBeICovCiNkZWZpbmUJRU9MCQkw eDIwMDAzCS8qIEVuZCBvZiBsaW5lLCAkICovCiNkZWZpbmUJQ0NMQVNTCQkweDIwMDA0CS8qIENo YXJhY3RlciBjbGFzcywgW10gKi8KI2RlZmluZQlOQ0NMQVNTCQkweDIwMDA1CS8qIE5lZ2F0ZWQg Y2hhcmFjdGVyIGNsYXNzLCBbXl0gKi8KI2RlZmluZQlFTkQJCTB4MjAwNzcJLyogVGVybWluYXRl OiBtYXRjaCBmb3VuZCAqLwoKI2RlZmluZQlJU0FUT1IJCTB4MTAwMDAKI2RlZmluZQlJU0FORAkJ MHgyMDAwMAoKLyoKICogUGFyc2VyIEluZm9ybWF0aW9uCiAqLwp0eXBlZGVmIHN0cnVjdCBOb2Rl IE5vZGU7CnN0cnVjdCBOb2RlCnsKCUluc3QJKmZpcnN0OwoJSW5zdAkqbGFzdDsKfTsKCiNkZWZp bmUJTlNUQUNLCTIwCk5vZGUJYW5kc3RhY2tbTlNUQUNLXTsKTm9kZQkqYW5kcDsKaW50CWF0b3Jz dGFja1tOU1RBQ0tdOwppbnQJKmF0b3JwOwppbnQJbGFzdHdhc2FuZDsJLyogTGFzdCB0b2tlbiB3 YXMgb3BlcmFuZCAqLwppbnQJY3Vyc3ViaWQ7CmludAlzdWJpZHN0YWNrW05TVEFDS107CmludAkq c3ViaWRwOwppbnQJYmFja3dhcmRzOwppbnQJbmJyYTsKUnVuZQkqZXhwcnA7CQkvKiBwb2ludGVy IHRvIG5leHQgY2hhcmFjdGVyIGluIHNvdXJjZSBleHByZXNzaW9uICovCiNkZWZpbmUJRENMQVNT CTEwCS8qIGFsbG9jYXRpb24gaW5jcmVtZW50ICovCmludAluY2xhc3M7CQkvKiBudW1iZXIgYWN0 aXZlICovCmludAlOY2xhc3M7CQkvKiBoaWdoIHdhdGVyIG1hcmsgKi8KUnVuZQkqKmNsYXNzOwpp bnQJbmVnYXRlY2xhc3M7Cgp2b2lkCWFkZGluc3QoSWxpc3QgKmwsIEluc3QgKmluc3QsIFJhbmdl c2V0ICpzZXApOwp2b2lkCW5ld21hdGNoKFJhbmdlc2V0Kik7CnZvaWQJYm5ld21hdGNoKFJhbmdl c2V0Kik7CnZvaWQJcHVzaGFuZChJbnN0KiwgSW5zdCopOwp2b2lkCXB1c2hhdG9yKGludCk7Ck5v ZGUJKnBvcGFuZChpbnQpOwppbnQJcG9wYXRvcih2b2lkKTsKdm9pZAlzdGFydGxleChSdW5lKik7 CmludAlsZXgodm9pZCk7CnZvaWQJb3BlcmF0b3IoaW50KTsKdm9pZAlvcGVyYW5kKGludCk7CnZv aWQJZXZhbHVudGlsKGludCk7CnZvaWQJb3B0aW1pemUoSW5zdCopOwp2b2lkCWJsZGNjbGFzcyh2 b2lkKTsKCnZvaWQKcmVnZXJyb3IoRXJyIGUpCnsKCVN0cnplcm8oJmxhc3RyZWdleHApOwoJZXJy b3IoZSk7Cn0KCnZvaWQKcmVnZXJyb3JfYyhFcnIgZSwgaW50IGMpCnsKCVN0cnplcm8oJmxhc3Ry ZWdleHApOwoJZXJyb3JfYyhlLCBjKTsKfQoKSW5zdCAqCm5ld2luc3QoaW50IHQpCnsKCWlmKHBy b2dwID49ICZwcm9ncmFtW05QUk9HXSkKCQlyZWdlcnJvcihFdG9vbG9uZyk7Cglwcm9ncC0+dHlw ZSA9IHQ7Cglwcm9ncC0+bGVmdCA9IDA7Cglwcm9ncC0+cmlnaHQgPSAwOwoJcmV0dXJuIHByb2dw Kys7Cn0KCkluc3QgKgpyZWFsY29tcGlsZShSdW5lICpzKQp7CglpbnQgdG9rZW47CgoJc3RhcnRs ZXgocyk7CglhdG9ycCA9IGF0b3JzdGFjazsKCWFuZHAgPSBhbmRzdGFjazsKCXN1YmlkcCA9IHN1 Ymlkc3RhY2s7CgljdXJzdWJpZCA9IDA7CglsYXN0d2FzYW5kID0gRkFMU0U7CgkvKiBTdGFydCB3 aXRoIGEgbG93IHByaW9yaXR5IG9wZXJhdG9yIHRvIHByaW1lIHBhcnNlciAqLwoJcHVzaGF0b3Io U1RBUlQtMSk7Cgl3aGlsZSgodG9rZW49bGV4KCkpICE9IEVORCl7CgkJaWYoKHRva2VuJklTQVRP UikgPT0gT1BFUkFUT1IpCgkJCW9wZXJhdG9yKHRva2VuKTsKCQllbHNlCgkJCW9wZXJhbmQodG9r ZW4pOwoJfQoJLyogQ2xvc2Ugd2l0aCBhIGxvdyBwcmlvcml0eSBvcGVyYXRvciAqLwoJZXZhbHVu dGlsKFNUQVJUKTsKCS8qIEZvcmNlIEVORCAqLwoJb3BlcmFuZChFTkQpOwoJZXZhbHVudGlsKFNU QVJUKTsKCWlmKG5icmEpCgkJcmVnZXJyb3IoRWxlZnRwYXIpOwoJLS1hbmRwOwkvKiBwb2ludHMg dG8gZmlyc3QgYW5kIG9ubHkgb3BlcmFuZCAqLwoJcmV0dXJuIGFuZHAtPmZpcnN0Owp9Cgp2b2lk CmNvbXBpbGUoU3RyaW5nICpzKQp7CglpbnQgaTsKCUluc3QgKm9wcm9ncDsKCglpZihTdHJjbXAo cywgJmxhc3RyZWdleHApPT0wKQoJCXJldHVybjsKCWZvcihpPTA7IGk8bmNsYXNzOyBpKyspCgkJ ZnJlZShjbGFzc1tpXSk7CgluY2xhc3MgPSAwOwoJcHJvZ3AgPSBwcm9ncmFtOwoJYmFja3dhcmRz ID0gRkFMU0U7CglzdGFydGluc3QgPSByZWFsY29tcGlsZShzLT5zKTsKCW9wdGltaXplKHByb2dy YW0pOwoJb3Byb2dwID0gcHJvZ3A7CgliYWNrd2FyZHMgPSBUUlVFOwoJYnN0YXJ0aW5zdCA9IHJl YWxjb21waWxlKHMtPnMpOwoJb3B0aW1pemUob3Byb2dwKTsKCVN0cmR1cGxzdHIoJmxhc3RyZWdl eHAsIHMpOwp9Cgp2b2lkCm9wZXJhbmQoaW50IHQpCnsKCUluc3QgKmk7CglpZihsYXN0d2FzYW5k KQoJCW9wZXJhdG9yKENBVCk7CS8qIGNhdGVuYXRlIGlzIGltcGxpY2l0ICovCglpID0gbmV3aW5z dCh0KTsKCWlmKHQgPT0gQ0NMQVNTKXsKCQlpZihuZWdhdGVjbGFzcykKCQkJaS0+dHlwZSA9IE5D Q0xBU1M7CS8qIFVHSCAqLwoJCWktPnJjbGFzcyA9IG5jbGFzcy0xOwkJLyogVUdIICovCgl9Cglw dXNoYW5kKGksIGkpOwoJbGFzdHdhc2FuZCA9IFRSVUU7Cn0KCnZvaWQKb3BlcmF0b3IoaW50IHQp CnsKCWlmKHQ9PVJCUkEgJiYgLS1uYnJhPDApCgkJcmVnZXJyb3IoRXJpZ2h0cGFyKTsKCWlmKHQ9 PUxCUkEpewovKgogKgkJaWYoKytjdXJzdWJpZCA+PSBOU1VCRVhQKQogKgkJCXJlZ2Vycm9yKEVz dWJleHApOwogKi8KCQljdXJzdWJpZCsrOwkvKiBzaWxlbnRseSBpZ25vcmVkICovCgkJbmJyYSsr OwoJCWlmKGxhc3R3YXNhbmQpCgkJCW9wZXJhdG9yKENBVCk7Cgl9ZWxzZQoJCWV2YWx1bnRpbCh0 KTsKCWlmKHQhPVJCUkEpCgkJcHVzaGF0b3IodCk7CglsYXN0d2FzYW5kID0gRkFMU0U7CglpZih0 PT1TVEFSIHx8IHQ9PVFVRVNUIHx8IHQ9PVBMVVMgfHwgdD09UkJSQSkKCQlsYXN0d2FzYW5kID0g VFJVRTsJLyogdGhlc2UgbG9vayBsaWtlIG9wZXJhbmRzICovCn0KCnZvaWQKY2FudChjaGFyICpz KQp7CgljaGFyIGJ1ZlsxMDBdOwoKCXNwcmludChidWYsICJyZWdleHA6IGNhbid0IGhhcHBlbjog JXMiLCBzKTsKCXBhbmljKGJ1Zik7Cn0KCnZvaWQKcHVzaGFuZChJbnN0ICpmLCBJbnN0ICpsKQp7 CglpZihhbmRwID49ICZhbmRzdGFja1tOU1RBQ0tdKQoJCWNhbnQoIm9wZXJhbmQgc3RhY2sgb3Zl cmZsb3ciKTsKCWFuZHAtPmZpcnN0ID0gZjsKCWFuZHAtPmxhc3QgPSBsOwoJYW5kcCsrOwp9Cgp2 b2lkCnB1c2hhdG9yKGludCB0KQp7CglpZihhdG9ycCA+PSAmYXRvcnN0YWNrW05TVEFDS10pCgkJ Y2FudCgib3BlcmF0b3Igc3RhY2sgb3ZlcmZsb3ciKTsKCSphdG9ycCsrPXQ7CglpZihjdXJzdWJp ZCA+PSBOU1VCRVhQKQoJCSpzdWJpZHArKz0gLTE7CgllbHNlCgkJKnN1YmlkcCsrPWN1cnN1Ymlk Owp9CgpOb2RlICoKcG9wYW5kKGludCBvcCkKewoJaWYoYW5kcCA8PSAmYW5kc3RhY2tbMF0pCgkJ aWYob3ApCgkJCXJlZ2Vycm9yX2MoRW1pc3NvcCwgb3ApOwoJCWVsc2UKCQkJcmVnZXJyb3IoRWJh ZHJlZ2V4cCk7CglyZXR1cm4gLS1hbmRwOwp9CgppbnQKcG9wYXRvcih2b2lkKQp7CglpZihhdG9y cCA8PSAmYXRvcnN0YWNrWzBdKQoJCWNhbnQoIm9wZXJhdG9yIHN0YWNrIHVuZGVyZmxvdyIpOwoJ LS1zdWJpZHA7CglyZXR1cm4gKi0tYXRvcnA7Cn0KCnZvaWQKZXZhbHVudGlsKGludCBwcmkpCnsK CU5vZGUgKm9wMSwgKm9wMiwgKnQ7CglJbnN0ICppbnN0MSwgKmluc3QyOwoKCXdoaWxlKHByaT09 UkJSQSB8fCBhdG9ycFstMV0+PXByaSl7CgkJc3dpdGNoKHBvcGF0b3IoKSl7CgkJY2FzZSBMQlJB OgoJCQlvcDEgPSBwb3BhbmQoJygnKTsKCQkJaW5zdDIgPSBuZXdpbnN0KFJCUkEpOwoJCQlpbnN0 Mi0+c3ViaWQgPSAqc3ViaWRwOwoJCQlvcDEtPmxhc3QtPm5leHQgPSBpbnN0MjsKCQkJaW5zdDEg PSBuZXdpbnN0KExCUkEpOwoJCQlpbnN0MS0+c3ViaWQgPSAqc3ViaWRwOwoJCQlpbnN0MS0+bmV4 dCA9IG9wMS0+Zmlyc3Q7CgkJCXB1c2hhbmQoaW5zdDEsIGluc3QyKTsKCQkJcmV0dXJuOwkJLyog bXVzdCBoYXZlIGJlZW4gUkJSQSAqLwoJCWRlZmF1bHQ6CgkJCXBhbmljKCJ1bmtub3duIHJlZ2V4 cCBvcGVyYXRvciIpOwoJCQlicmVhazsKCQljYXNlIE9SOgoJCQlvcDIgPSBwb3BhbmQoJ3wnKTsK CQkJb3AxID0gcG9wYW5kKCd8Jyk7CgkJCWluc3QyID0gbmV3aW5zdChOT1ApOwoJCQlvcDItPmxh c3QtPm5leHQgPSBpbnN0MjsKCQkJb3AxLT5sYXN0LT5uZXh0ID0gaW5zdDI7CgkJCWluc3QxID0g bmV3aW5zdChPUik7CgkJCWluc3QxLT5yaWdodCA9IG9wMS0+Zmlyc3Q7CgkJCWluc3QxLT5sZWZ0 ID0gb3AyLT5maXJzdDsKCQkJcHVzaGFuZChpbnN0MSwgaW5zdDIpOwoJCQlicmVhazsKCQljYXNl IENBVDoKCQkJb3AyID0gcG9wYW5kKDApOwoJCQlvcDEgPSBwb3BhbmQoMCk7CgkJCWlmKGJhY2t3 YXJkcyAmJiBvcDItPmZpcnN0LT50eXBlIT1FTkQpCgkJCQl0ID0gb3AxLCBvcDEgPSBvcDIsIG9w MiA9IHQ7CgkJCW9wMS0+bGFzdC0+bmV4dCA9IG9wMi0+Zmlyc3Q7CgkJCXB1c2hhbmQob3AxLT5m aXJzdCwgb3AyLT5sYXN0KTsKCQkJYnJlYWs7CgkJY2FzZSBTVEFSOgoJCQlvcDIgPSBwb3BhbmQo JyonKTsKCQkJaW5zdDEgPSBuZXdpbnN0KE9SKTsKCQkJb3AyLT5sYXN0LT5uZXh0ID0gaW5zdDE7 CgkJCWluc3QxLT5yaWdodCA9IG9wMi0+Zmlyc3Q7CgkJCXB1c2hhbmQoaW5zdDEsIGluc3QxKTsK CQkJYnJlYWs7CgkJY2FzZSBQTFVTOgoJCQlvcDIgPSBwb3BhbmQoJysnKTsKCQkJaW5zdDEgPSBu ZXdpbnN0KE9SKTsKCQkJb3AyLT5sYXN0LT5uZXh0ID0gaW5zdDE7CgkJCWluc3QxLT5yaWdodCA9 IG9wMi0+Zmlyc3Q7CgkJCXB1c2hhbmQob3AyLT5maXJzdCwgaW5zdDEpOwoJCQlicmVhazsKCQlj YXNlIFFVRVNUOgoJCQlvcDIgPSBwb3BhbmQoJz8nKTsKCQkJaW5zdDEgPSBuZXdpbnN0KE9SKTsK CQkJaW5zdDIgPSBuZXdpbnN0KE5PUCk7CgkJCWluc3QxLT5sZWZ0ID0gaW5zdDI7CgkJCWluc3Qx LT5yaWdodCA9IG9wMi0+Zmlyc3Q7CgkJCW9wMi0+bGFzdC0+bmV4dCA9IGluc3QyOwoJCQlwdXNo YW5kKGluc3QxLCBpbnN0Mik7CgkJCWJyZWFrOwoJCX0KCX0KfQoKCnZvaWQKb3B0aW1pemUoSW5z dCAqc3RhcnQpCnsKCUluc3QgKmluc3QsICp0YXJnZXQ7CgoJZm9yKGluc3Q9c3RhcnQ7IGluc3Qt PnR5cGUhPUVORDsgaW5zdCsrKXsKCQl0YXJnZXQgPSBpbnN0LT5uZXh0OwoJCXdoaWxlKHRhcmdl dC0+dHlwZSA9PSBOT1ApCgkJCXRhcmdldCA9IHRhcmdldC0+bmV4dDsKCQlpbnN0LT5uZXh0ID0g dGFyZ2V0OwoJfQp9CgojaWZkZWYJREVCVUcKdm9pZApkdW1wc3RhY2sodm9pZCl7CglOb2RlICpz dGs7CglpbnQgKmlwOwoKCWRwcmludCgib3BlcmF0b3JzXG4iKTsKCWZvcihpcCA9IGF0b3JzdGFj azsgaXA8YXRvcnA7IGlwKyspCgkJZHByaW50KCIwJW9cbiIsICppcCk7CglkcHJpbnQoIm9wZXJh bmRzXG4iKTsKCWZvcihzdGsgPSBhbmRzdGFjazsgc3RrPGFuZHA7IHN0aysrKQoJCWRwcmludCgi MCVvXHQwJW9cbiIsIHN0ay0+Zmlyc3QtPnR5cGUsIHN0ay0+bGFzdC0+dHlwZSk7Cn0Kdm9pZApk dW1wKHZvaWQpewoJSW5zdCAqbDsKCglsID0gcHJvZ3JhbTsKCWRvewoJCWRwcmludCgiJWQ6XHQw JW9cdCVkXHQlZFxuIiwgbC1wcm9ncmFtLCBsLT50eXBlLAoJCQlsLT5sZWZ0LXByb2dyYW0sIGwt PnJpZ2h0LXByb2dyYW0pOwoJfXdoaWxlKGwrKy0+dHlwZSk7Cn0KI2VuZGlmCgp2b2lkCnN0YXJ0 bGV4KFJ1bmUgKnMpCnsKCWV4cHJwID0gczsKCW5icmEgPSAwOwp9CgoKaW50CmxleCh2b2lkKXsK CWludCBjPSAqZXhwcnArKzsKCglzd2l0Y2goYyl7CgljYXNlICdcXCc6CgkJaWYoKmV4cHJwKQoJ CQlpZigoYz0gKmV4cHJwKyspPT0nbicpCgkJCQljPSdcbic7CgkJYnJlYWs7CgljYXNlIDA6CgkJ YyA9IEVORDsKCQktLWV4cHJwOwkvKiBJbiBjYXNlIHdlIGNvbWUgaGVyZSBhZ2FpbiAqLwoJCWJy ZWFrOwoJY2FzZSAnKic6CgkJYyA9IFNUQVI7CgkJYnJlYWs7CgljYXNlICc/JzoKCQljID0gUVVF U1Q7CgkJYnJlYWs7CgljYXNlICcrJzoKCQljID0gUExVUzsKCQlicmVhazsKCWNhc2UgJ3wnOgoJ CWMgPSBPUjsKCQlicmVhazsKCWNhc2UgJy4nOgoJCWMgPSBBTlk7CgkJYnJlYWs7CgljYXNlICco JzoKCQljID0gTEJSQTsKCQlicmVhazsKCWNhc2UgJyknOgoJCWMgPSBSQlJBOwoJCWJyZWFrOwoJ Y2FzZSAnXic6CgkJYyA9IEJPTDsKCQlicmVhazsKCWNhc2UgJyQnOgoJCWMgPSBFT0w7CgkJYnJl YWs7CgljYXNlICdbJzoKCQljID0gQ0NMQVNTOwoJCWJsZGNjbGFzcygpOwoJCWJyZWFrOwoJfQoJ cmV0dXJuIGM7Cn0KCmxvbmcKbmV4dHJlYyh2b2lkKXsKCWlmKGV4cHJwWzBdPT0wIHx8IChleHBy cFswXT09J1xcJyAmJiBleHBycFsxXT09MCkpCgkJcmVnZXJyb3IoRWJhZGNsYXNzKTsKCWlmKGV4 cHJwWzBdID09ICdcXCcpewoJCWV4cHJwKys7CgkJaWYoKmV4cHJwPT0nbicpewoJCQlleHBycCsr OwoJCQlyZXR1cm4gJ1xuJzsKCQl9CgkJcmV0dXJuICpleHBycCsrfDB4MTAwMDA7Cgl9CglyZXR1 cm4gKmV4cHJwKys7Cn0KCnZvaWQKYmxkY2NsYXNzKHZvaWQpCnsKCWxvbmcgYzEsIGMyLCBuLCBu YTsKCVJ1bmUgKmNsYXNzcDsKCgljbGFzc3AgPSBlbWFsbG9jKERDTEFTUypSVU5FU0laRSk7Cglu ID0gMDsKCW5hID0gRENMQVNTOwoJLyogd2UgaGF2ZSBhbHJlYWR5IHNlZW4gdGhlICdbJyAqLwoJ aWYoKmV4cHJwID09ICdeJyl7CgkJY2xhc3NwW24rK10gPSAnXG4nOwkvKiBkb24ndCBtYXRjaCBu ZXdsaW5lIGluIG5lZ2F0ZSBjYXNlICovCgkJbmVnYXRlY2xhc3MgPSBUUlVFOwoJCWV4cHJwKys7 Cgl9ZWxzZQoJCW5lZ2F0ZWNsYXNzID0gRkFMU0U7Cgl3aGlsZSgoYzEgPSBuZXh0cmVjKCkpICE9 ICddJyl7CgkJaWYoYzEgPT0gJy0nKXsKICAgIEVycm9yOgoJCQlmcmVlKGNsYXNzcCk7CgkJCXJl Z2Vycm9yKEViYWRjbGFzcyk7CgkJfQoJCWlmKG4rNCA+PSBuYSl7CQkvKiAzIHJ1bmVzIHBsdXMg TlVMICovCgkJCW5hICs9IERDTEFTUzsKCQkJY2xhc3NwID0gZXJlYWxsb2MoY2xhc3NwLCBuYSpS VU5FU0laRSk7CgkJfQoJCWlmKCpleHBycCA9PSAnLScpewoJCQlleHBycCsrOwkvKiBlYXQgJy0n ICovCgkJCWlmKChjMiA9IG5leHRyZWMoKSkgPT0gJ10nKQoJCQkJZ290byBFcnJvcjsKCQkJY2xh c3NwW24rMF0gPSAweEZGRkY7CgkJCWNsYXNzcFtuKzFdID0gYzE7CgkJCWNsYXNzcFtuKzJdID0g YzI7CgkJCW4gKz0gMzsKCQl9ZWxzZQoJCQljbGFzc3BbbisrXSA9IGMxOwoJfQoJY2xhc3NwW25d ID0gMDsKCWlmKG5jbGFzcyA9PSBOY2xhc3MpewoJCU5jbGFzcyArPSBEQ0xBU1M7CgkJY2xhc3Mg PSBlcmVhbGxvYyhjbGFzcywgTmNsYXNzKnNpemVvZihSdW5lKikpOwoJfQoJY2xhc3NbbmNsYXNz KytdID0gY2xhc3NwOwp9CgppbnQKY2xhc3NtYXRjaChpbnQgY2xhc3NubywgaW50IGMsIGludCBu ZWdhdGUpCnsKCVJ1bmUgKnA7CgoJcCA9IGNsYXNzW2NsYXNzbm9dOwoJd2hpbGUoKnApewoJCWlm KCpwID09IDB4RkZGRil7CgkJCWlmKHBbMV08PWMgJiYgYzw9cFsyXSkKCQkJCXJldHVybiAhbmVn YXRlOwoJCQlwICs9IDM7CgkJfWVsc2UgaWYoKnArKyA9PSBjKQoJCQlyZXR1cm4gIW5lZ2F0ZTsK CX0KCXJldHVybiBuZWdhdGU7Cn0KCi8qCiAqIE5vdGUgb3B0aW1pemF0aW9uIGluIGFkZGluc3Q6 CiAqIAkqbCBtdXN0IGJlIHBlbmRpbmcgd2hlbiBhZGRpbnN0IGNhbGxlZDsgaWYgKmwgaGFzIGJl ZW4gbG9va2VkCiAqCQlhdCBhbHJlYWR5LCB0aGUgb3B0aW1pemF0aW9uIGlzIGEgYnVnLgogKi8K dm9pZAphZGRpbnN0KElsaXN0ICpsLCBJbnN0ICppbnN0LCBSYW5nZXNldCAqc2VwKQp7CglJbGlz dCAqcDsKCglmb3IocCA9IGw7IHAtPmluc3Q7IHArKyl7CgkJaWYocC0+aW5zdD09aW5zdCl7CgkJ CWlmKChzZXApLT5wWzBdLnAxIDwgcC0+c2UucFswXS5wMSkKCQkJCXAtPnNlPSAqc2VwOwkvKiB0 aGlzIHdvdWxkIGJlIGJ1ZyAqLwoJCQlyZXR1cm47CS8qIEl0J3MgYWxyZWFkeSB0aGVyZSAqLwoJ CX0KCX0KCXAtPmluc3QgPSBpbnN0OwoJcC0+c2U9ICpzZXA7CgkocCsxKS0+aW5zdCA9IDA7Cn0K CmludApleGVjdXRlKEZpbGUgKmYsIFBvc24gc3RhcnRwLCBQb3NuIGVvZikKewoJaW50IGZsYWcg PSAwOwoJSW5zdCAqaW5zdDsKCUlsaXN0ICp0bHA7CglQb3NuIHAgPSBzdGFydHA7CglpbnQgbm5s ID0gMCwgbnRsOwoJaW50IGM7CglpbnQgd3JhcHBlZCA9IDA7CglpbnQgc3RhcnRjaGFyID0gc3Rh cnRpbnN0LT50eXBlPE9QRVJBVE9SPyBzdGFydGluc3QtPnR5cGUgOiAwOwoKCWxpc3RbMF1bMF0u aW5zdCA9IGxpc3RbMV1bMF0uaW5zdCA9IDA7CglzZWwucFswXS5wMSA9IC0xOwoJLyogRXhlY3V0 ZSBtYWNoaW5lIG9uY2UgZm9yIGVhY2ggY2hhcmFjdGVyICovCglmb3IoOztwKyspewoJZG9sb29w OgoJCWMgPSBmaWxlcmVhZGMoZiwgcCk7CgkJaWYocD49ZW9mIHx8IGM8MCl7CgkJCXN3aXRjaCh3 cmFwcGVkKyspewoJCQljYXNlIDA6CQkvKiBsZXQgbG9vcCBydW4gb25lIG1vcmUgY2xpY2sgKi8K CQkJY2FzZSAyOgoJCQkJYnJlYWs7CgkJCWNhc2UgMToJCS8qIGV4cGlyZWQ7IHdyYXAgdG8gYmVn aW5uaW5nICovCgkJCQlpZihzZWwucFswXS5wMT49MCB8fCBlb2YhPUlORklOSVRZKQoJCQkJCWdv dG8gUmV0dXJuOwoJCQkJbGlzdFswXVswXS5pbnN0ID0gbGlzdFsxXVswXS5pbnN0ID0gMDsKCQkJ CXAgPSAwOwoJCQkJZ290byBkb2xvb3A7CgkJCWRlZmF1bHQ6CgkJCQlnb3RvIFJldHVybjsKCQkJ fQoJCX1lbHNlIGlmKCgod3JhcHBlZCAmJiBwPj1zdGFydHApIHx8IHNlbC5wWzBdLnAxPjApICYm IG5ubD09MCkKCQkJYnJlYWs7CgkJLyogZmFzdCBjaGVjayBmb3IgZmlyc3QgY2hhciAqLwoJCWlm KHN0YXJ0Y2hhciAmJiBubmw9PTAgJiYgYyE9c3RhcnRjaGFyKQoJCQljb250aW51ZTsKCQl0bCA9 IGxpc3RbZmxhZ107CgkJbmwgPSBsaXN0W2ZsYWdePTFdOwoJCW5sLT5pbnN0ID0gMDsKCQludGwg PSBubmw7CgkJbm5sID0gMDsKCQlpZihzZWwucFswXS5wMTwwICYmICghd3JhcHBlZCB8fCBwPHN0 YXJ0cCB8fCBzdGFydHA9PWVvZikpewoJCQkvKiBBZGQgZmlyc3QgaW5zdHJ1Y3Rpb24gdG8gdGhp cyBsaXN0ICovCgkJCWlmKCsrbnRsID49IE5MSVNUKQoJT3ZlcmZsb3c6CgkJCQllcnJvcihFb3Zl cmZsb3cpOwoJCQlzZW1wdHkucFswXS5wMSA9IHA7CgkJCWFkZGluc3QodGwsIHN0YXJ0aW5zdCwg JnNlbXB0eSk7CgkJfQoJCS8qIEV4ZWN1dGUgbWFjaGluZSB1bnRpbCB0aGlzIGxpc3QgaXMgZW1w dHkgKi8KCQlmb3IodGxwID0gdGw7IGluc3QgPSB0bHAtPmluc3Q7IHRscCsrKXsJLyogYXNzaWdu bWVudCA9ICovCglTd2l0Y2hzdG10OgoJCQlzd2l0Y2goaW5zdC0+dHlwZSl7CgkJCWRlZmF1bHQ6 CS8qIHJlZ3VsYXIgY2hhcmFjdGVyICovCgkJCQlpZihpbnN0LT50eXBlPT1jKXsKCUFkZGluc3Q6 CgkJCQkJaWYoKytubmwgPj0gTkxJU1QpCgkJCQkJCWdvdG8gT3ZlcmZsb3c7CgkJCQkJYWRkaW5z dChubCwgaW5zdC0+bmV4dCwgJnRscC0+c2UpOwoJCQkJfQoJCQkJYnJlYWs7CgkJCWNhc2UgTEJS QToKCQkJCWlmKGluc3QtPnN1YmlkPj0wKQoJCQkJCXRscC0+c2UucFtpbnN0LT5zdWJpZF0ucDEg PSBwOwoJCQkJaW5zdCA9IGluc3QtPm5leHQ7CgkJCQlnb3RvIFN3aXRjaHN0bXQ7CgkJCWNhc2Ug UkJSQToKCQkJCWlmKGluc3QtPnN1YmlkPj0wKQoJCQkJCXRscC0+c2UucFtpbnN0LT5zdWJpZF0u cDIgPSBwOwoJCQkJaW5zdCA9IGluc3QtPm5leHQ7CgkJCQlnb3RvIFN3aXRjaHN0bXQ7CgkJCWNh c2UgQU5ZOgoJCQkJaWYoYyE9J1xuJykKCQkJCQlnb3RvIEFkZGluc3Q7CgkJCQlicmVhazsKCQkJ Y2FzZSBCT0w6CgkJCQlpZihwPT0wIHx8IGZpbGVyZWFkYyhmLCBwIC0gMSk9PSdcbicpewoJU3Rl cDoKCQkJCQlpbnN0ID0gaW5zdC0+bmV4dDsKCQkJCQlnb3RvIFN3aXRjaHN0bXQ7CgkJCQl9CgkJ CQlicmVhazsKCQkJY2FzZSBFT0w6CgkJCQlpZihjID09ICdcbicpCgkJCQkJZ290byBTdGVwOwoJ CQkJYnJlYWs7CgkJCWNhc2UgQ0NMQVNTOgoJCQkJaWYoYz49MCAmJiBjbGFzc21hdGNoKGluc3Qt PnJjbGFzcywgYywgMCkpCgkJCQkJZ290byBBZGRpbnN0OwoJCQkJYnJlYWs7CgkJCWNhc2UgTkND TEFTUzoKCQkJCWlmKGM+PTAgJiYgY2xhc3NtYXRjaChpbnN0LT5yY2xhc3MsIGMsIDEpKQoJCQkJ CWdvdG8gQWRkaW5zdDsKCQkJCWJyZWFrOwoJCQljYXNlIE9SOgoJCQkJLyogZXZhbHVhdGUgcmln aHQgY2hvaWNlIGxhdGVyICovCgkJCQlpZigrK250bCA+PSBOTElTVCkKCQkJCQlnb3RvIE92ZXJm bG93OwoJCQkJYWRkaW5zdCh0bHAsIGluc3QtPnJpZ2h0LCAmdGxwLT5zZSk7CgkJCQkvKiBlZmZp Y2llbmN5OiBhZHZhbmNlIGFuZCByZS1ldmFsdWF0ZSAqLwoJCQkJaW5zdCA9IGluc3QtPmxlZnQ7 CgkJCQlnb3RvIFN3aXRjaHN0bXQ7CgkJCWNhc2UgRU5EOgkvKiBNYXRjaCEgKi8KCQkJCXRscC0+ c2UucFswXS5wMiA9IHA7CgkJCQluZXdtYXRjaCgmdGxwLT5zZSk7CgkJCQlicmVhazsKCQkJfQoJ CX0KCX0KICAgIFJldHVybjoKCXJldHVybiBzZWwucFswXS5wMT49MDsKfQoKdm9pZApuZXdtYXRj aChSYW5nZXNldCAqc3ApCnsKCWludCBpOwoKCWlmKHNlbC5wWzBdLnAxPDAgfHwgc3AtPnBbMF0u cDE8c2VsLnBbMF0ucDEgfHwKCSAgIChzcC0+cFswXS5wMT09c2VsLnBbMF0ucDEgJiYgc3AtPnBb MF0ucDI+c2VsLnBbMF0ucDIpKQoJCWZvcihpID0gMDsgaTxOU1VCRVhQOyBpKyspCgkJCXNlbC5w W2ldID0gc3AtPnBbaV07Cn0KCmludApiZXhlY3V0ZShGaWxlICpmLCBQb3NuIHN0YXJ0cCkKewoJ aW50IGZsYWcgPSAwOwoJSW5zdCAqaW5zdDsKCUlsaXN0ICp0bHA7CglQb3NuIHAgPSBzdGFydHA7 CglpbnQgbm5sID0gMCwgbnRsOwoJaW50IGM7CglpbnQgd3JhcHBlZCA9IDA7CglpbnQgc3RhcnRj aGFyID0gYnN0YXJ0aW5zdC0+dHlwZTxPUEVSQVRPUj8gYnN0YXJ0aW5zdC0+dHlwZSA6IDA7CgoJ bGlzdFswXVswXS5pbnN0ID0gbGlzdFsxXVswXS5pbnN0ID0gMDsKCXNlbC5wWzBdLnAxPSAtMTsK CS8qIEV4ZWN1dGUgbWFjaGluZSBvbmNlIGZvciBlYWNoIGNoYXJhY3RlciwgaW5jbHVkaW5nIHRl cm1pbmFsIE5VTCAqLwoJZm9yKDs7LS1wKXsKCWRvbG9vcDoKCQlpZigoYyA9IGZpbGVyZWFkYyhm LCBwIC0gMSkpPT0tMSl7CgkJCXN3aXRjaCh3cmFwcGVkKyspewoJCQljYXNlIDA6CQkvKiBsZXQg bG9vcCBydW4gb25lIG1vcmUgY2xpY2sgKi8KCQkJY2FzZSAyOgoJCQkJYnJlYWs7CgkJCWNhc2Ug MToJCS8qIGV4cGlyZWQ7IHdyYXAgdG8gZW5kICovCgkJCQlpZihzZWwucFswXS5wMT49MCkKCQkJ Y2FzZSAzOgoJCQkJCWdvdG8gUmV0dXJuOwoJCQkJbGlzdFswXVswXS5pbnN0ID0gbGlzdFsxXVsw XS5pbnN0ID0gMDsKCQkJCXAgPSBmLT5VLm5jOwoJCQkJZ290byBkb2xvb3A7CgkJCWRlZmF1bHQ6 CgkJCQlnb3RvIFJldHVybjsKCQkJfQoJCX1lbHNlIGlmKCgod3JhcHBlZCAmJiBwPD1zdGFydHAp IHx8IHNlbC5wWzBdLnAxPjApICYmIG5ubD09MCkKCQkJYnJlYWs7CgkJLyogZmFzdCBjaGVjayBm b3IgZmlyc3QgY2hhciAqLwoJCWlmKHN0YXJ0Y2hhciAmJiBubmw9PTAgJiYgYyE9c3RhcnRjaGFy KQoJCQljb250aW51ZTsKCQl0bCA9IGxpc3RbZmxhZ107CgkJbmwgPSBsaXN0W2ZsYWdePTFdOwoJ CW5sLT5pbnN0ID0gMDsKCQludGwgPSBubmw7CgkJbm5sID0gMDsKCQlpZihzZWwucFswXS5wMTww ICYmICghd3JhcHBlZCB8fCBwPnN0YXJ0cCkpewoJCQkvKiBBZGQgZmlyc3QgaW5zdHJ1Y3Rpb24g dG8gdGhpcyBsaXN0ICovCgkJCWlmKCsrbnRsID49IE5MSVNUKQoJT3ZlcmZsb3c6CgkJCQllcnJv cihFb3ZlcmZsb3cpOwoJCQkvKiB0aGUgbWludXMgaXMgc28gdGhlIG9wdGltaXphdGlvbnMgaW4g YWRkaW5zdCB3b3JrICovCgkJCXNlbXB0eS5wWzBdLnAxID0gLXA7CgkJCWFkZGluc3QodGwsIGJz dGFydGluc3QsICZzZW1wdHkpOwoJCX0KCQkvKiBFeGVjdXRlIG1hY2hpbmUgdW50aWwgdGhpcyBs aXN0IGlzIGVtcHR5ICovCgkJZm9yKHRscCA9IHRsOyBpbnN0ID0gdGxwLT5pbnN0OyB0bHArKyl7 CS8qIGFzc2lnbm1lbnQgPSAqLwoJU3dpdGNoc3RtdDoKCQkJc3dpdGNoKGluc3QtPnR5cGUpewoJ CQlkZWZhdWx0OgkvKiByZWd1bGFyIGNoYXJhY3RlciAqLwoJCQkJaWYoaW5zdC0+dHlwZSA9PSBj KXsKCUFkZGluc3Q6CgkJCQkJaWYoKytubmwgPj0gTkxJU1QpCgkJCQkJCWdvdG8gT3ZlcmZsb3c7 CgkJCQkJYWRkaW5zdChubCwgaW5zdC0+bmV4dCwgJnRscC0+c2UpOwoJCQkJfQoJCQkJYnJlYWs7 CgkJCWNhc2UgTEJSQToKCQkJCWlmKGluc3QtPnN1YmlkPj0wKQoJCQkJCXRscC0+c2UucFtpbnN0 LT5zdWJpZF0ucDEgPSBwOwoJCQkJaW5zdCA9IGluc3QtPm5leHQ7CgkJCQlnb3RvIFN3aXRjaHN0 bXQ7CgkJCWNhc2UgUkJSQToKCQkJCWlmKGluc3QtPnN1YmlkID49IDApCgkJCQkJdGxwLT5zZS5w W2luc3QtPnN1YmlkXS5wMiA9IHA7CgkJCQlpbnN0ID0gaW5zdC0+bmV4dDsKCQkJCWdvdG8gU3dp dGNoc3RtdDsKCQkJY2FzZSBBTlk6CgkJCQlpZihjICE9ICdcbicpCgkJCQkJZ290byBBZGRpbnN0 OwoJCQkJYnJlYWs7CgkJCWNhc2UgQk9MOgoJCQkJaWYoYz09J1xuJyB8fCBwPT0wKXsKCVN0ZXA6 CgkJCQkJaW5zdCA9IGluc3QtPm5leHQ7CgkJCQkJZ290byBTd2l0Y2hzdG10OwoJCQkJfQoJCQkJ YnJlYWs7CgkJCWNhc2UgRU9MOgoJCQkJaWYocD09Zi0+VS5uYyB8fCBmaWxlcmVhZGMoZiwgcCk9 PSdcbicpCgkJCQkJZ290byBTdGVwOwoJCQkJYnJlYWs7CgkJCWNhc2UgQ0NMQVNTOgoJCQkJaWYo Yz49MCAmJiBjbGFzc21hdGNoKGluc3QtPnJjbGFzcywgYywgMCkpCgkJCQkJZ290byBBZGRpbnN0 OwoJCQkJYnJlYWs7CgkJCWNhc2UgTkNDTEFTUzoKCQkJCWlmKGM+PTAgJiYgY2xhc3NtYXRjaChp bnN0LT5yY2xhc3MsIGMsIDEpKQoJCQkJCWdvdG8gQWRkaW5zdDsKCQkJCWJyZWFrOwoJCQljYXNl IE9SOgoJCQkJLyogZXZhbHVhdGUgcmlnaHQgY2hvaWNlIGxhdGVyICovCgkJCQlpZigrK250bCA+ PSBOTElTVCkKCQkJCQlnb3RvIE92ZXJmbG93OwoJCQkJYWRkaW5zdCh0bHAsIGluc3QtPnJpZ2h0 LCAmdGxwLT5zZSk7CgkJCQkvKiBlZmZpY2llbmN5OiBhZHZhbmNlIGFuZCByZS1ldmFsdWF0ZSAq LwoJCQkJaW5zdCA9IGluc3QtPmxlZnQ7CgkJCQlnb3RvIFN3aXRjaHN0bXQ7CgkJCWNhc2UgRU5E OgkvKiBNYXRjaCEgKi8KCQkJCXRscC0+c2UucFswXS5wMSA9IC10bHAtPnNlLnBbMF0ucDE7IC8q IG1pbnVzIHNpZ24gKi8KCQkJCXRscC0+c2UucFswXS5wMiA9IHA7CgkJCQlibmV3bWF0Y2goJnRs cC0+c2UpOwoJCQkJYnJlYWs7CgkJCX0KCQl9Cgl9CiAgICBSZXR1cm46CglyZXR1cm4gc2VsLnBb MF0ucDE+PTA7Cn0KCnZvaWQKYm5ld21hdGNoKFJhbmdlc2V0ICpzcCkKewogICAgICAgIGludCAg aTsKICAgICAgICBpZihzZWwucFswXS5wMTwwIHx8IHNwLT5wWzBdLnAxPnNlbC5wWzBdLnAyIHx8 IChzcC0+cFswXS5wMT09c2VsLnBbMF0ucDIgJiYgc3AtPnBbMF0ucDI8c2VsLnBbMF0ucDEpKQog ICAgICAgICAgICAgICAgZm9yKGkgPSAwOyBpPE5TVUJFWFA7IGkrKyl7ICAgICAgIC8qIG5vdGUg dGhlIHJldmVyc2FsOyBwMTw9cDIgKi8KICAgICAgICAgICAgICAgICAgICAgICAgc2VsLnBbaV0u cDEgPSBzcC0+cFtpXS5wMjsKICAgICAgICAgICAgICAgICAgICAgICAgc2VsLnBbaV0ucDIgPSBz cC0+cFtpXS5wMTsKICAgICAgICAgICAgICAgIH0KfQpyKEViYWRyZWdleHApOwoJcmV0dXJuIC0t YW5kcDsKfQoKaW50CnBvcGF0b3Iodm9pZCkKewoJaWYoYXRvcnAgPD0gJmF0b3JzdGFja1swXSkK CQljYW50KCJvcGVyYXRvciBzdGFjayB1bmRlcmZsb3ciKTsKCS0tc3ViaWRwOwoJcmV0dXJuICot LWF0b3JwOwp9Cgp2b2lkCmV2YWx1bnRpbChpbnQgcHJpKQp7CglOb2RlICpvcDEsICpvcDIsICp0 OwoJSW5zdCAqaW5zdDEsICppbnN0MjsKCgl3aGlsZShwcmk9PVJCUkEgfHwgYXRvcnBbLTFdPj1w cmkpewoJCXN3aXRjaChwb3BhdG9yKCkpewoJCWNhc2UgTEJSQToKCQkJb3AxID0gcG9wYW5kKCco Jyk7CgkJCWluc3QyID0gbmV3aW5zdChSQlJBKTsKCQkJaW5zdDItPnN1YmlkID0gKnN1YmlkcDsK CQkJb3AxLT5sYXN0LT5uZXh0ID0gaW5zdDI7CgkJCWluc3QxID0gbmV3aW5zdChMQlJBKTsKCQkJ aW5zdDEtPnN1YmlkID0gKnN1YmlkcDsKCQkJaW5zdDEtPm5leHQgPSBvcDEtPmZpcnN0OwoJc2Ft Mmsvc2FtL3NhbS5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAw MDAwMTUxADAwMDAwMDI3NzI3ADA3MTEyMTE2MzcwADAwMTQ1MDEAMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5j bHVkZSAic2FtLmgiCgpSdW5lCWdlbmJ1ZltCTE9DS1NJWkVdOwppbnQJaW87CmludAlwYW5pY2tp bmc7CmludAlyZXNjdWluZzsKU3RyaW5nCWdlbnN0cjsKU3RyaW5nCXJoczsKU3RyaW5nCWN1cndk OwpTdHJpbmcJY21kc3RyOwpSdW5lCWVtcHR5W10gPSB7IDAgfTsKY2hhcgkqZ2VuYzsKRmlsZQkq Y3VyZmlsZTsKRmlsZQkqZmxpc3Q7CkZpbGUJKmNtZDsKam1wX2J1ZgltYWlubG9vcDsKTGlzdAl0 ZW1wZmlsZTsKaW50CXF1aXRvayA9IFRSVUU7CmludAlkb3dubG9hZGVkOwppbnQJZGZsYWc7Cmlu dAlSZmxhZzsKY2hhcgkqbWFjaGluZTsKY2hhcgkqaG9tZTsKaW50CWJwaXBlb2s7CmludAl0ZXJt bG9ja2VkOwpjaGFyCSpzYW10ZXJtID0gU0FNVEVSTTsKY2hhcgkqcnNhbW5hbWUgPSBSU0FNOwpG aWxlCSpsYXN0ZmlsZTsKRGlzawkqZGlzazsKbG9uZwlzZXE7CgpSdW5lCWJhZGRpcltdID0geyAn PCcsICdiJywgJ2EnLCAnZCcsICdkJywgJ2knLCAncicsICc+JywgJ1xuJ307Cgp2b2lkCXVzYWdl KHZvaWQpOwoKaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKewoJaW50IGk7CglTdHJp bmcgKnQ7CgljaGFyICoqYXAsICoqYXJnOwoKCWZtdF9pbnN0YWxsX3J1bmVjb252KCk7CgoJYXJn ID0gYXJndisrOwoJYXAgPSBhcmd2OwoJd2hpbGUoYXJnYz4xICYmIGFyZ3ZbMF0gJiYgYXJndlsw XVswXT09Jy0nKXsKCQlzd2l0Y2goYXJndlswXVsxXSl7CgkJY2FzZSAnZCc6CgkJCWRmbGFnKys7 CgkJCWJyZWFrOwoKCQljYXNlICdyJzoKCQkJLS1hcmdjLCBhcmd2Kys7CgkJCWlmKGFyZ2MgPT0g MSkKCQkJCXVzYWdlKCk7CgkJCW1hY2hpbmUgPSAqYXJndjsKCQkJYnJlYWs7CgoJCWNhc2UgJ1In OgoJCQlSZmxhZysrOwoJCQlicmVhazsKCgkJY2FzZSAndCc6CgkJCS0tYXJnYywgYXJndisrOwoJ CQlpZihhcmdjID09IDEpCgkJCQl1c2FnZSgpOwoJCQlzYW10ZXJtID0gKmFyZ3Y7CgkJCWJyZWFr OwoKCQljYXNlICdzJzoKCQkJLS1hcmdjLCBhcmd2Kys7CgkJCWlmKGFyZ2MgPT0gMSkKCQkJCXVz YWdlKCk7CgkJCXJzYW1uYW1lID0gKmFyZ3Y7CgkJCWJyZWFrOwoKCQlkZWZhdWx0OgoJCQlkcHJp bnQoInNhbTogdW5rbm93biBmbGFnICVjXG4iLCBhcmd2WzBdWzFdKTsKCQkJZXhpdHMoInVzYWdl Iik7CgkJfQoJCS0tYXJnYywgYXJndisrOwoJfQoJU3RyaW5pdCgmY21kc3RyKTsKCVN0cmluaXQw KCZsYXN0cGF0KTsKCVN0cmluaXQwKCZsYXN0cmVnZXhwKTsKCVN0cmluaXQwKCZnZW5zdHIpOwoJ U3RyaW5pdDAoJnJocyk7CglTdHJpbml0MCgmY3Vyd2QpOwoJdGVtcGZpbGUubGlzdHB0ciA9IGVt YWxsb2MoMSk7CS8qIHNvIGl0IGNhbiBiZSBmcmVlZCBsYXRlciAqLwoJU3RyaW5pdDAoJnBsYW45 Y21kKTsKCWhvbWUgPSBnZXRlbnYoSE9NRSk7CglkaXNrID0gZGlza2luaXQoKTsKCWlmKGhvbWUg PT0gMCkKCQlob21lID0gIi8iOwoJaWYoIWRmbGFnKQoJCXN0YXJ0dXAobWFjaGluZSwgUmZsYWcs IGFyZywgYXApOwoJbm90aWZ5KG5vdGlmeWYpOwoJZ2V0Y3Vyd2QoKTsKCWlmKGFyZ2M+MSl7CgkJ Zm9yKGk9MDsgaTxhcmdjLTE7IGkrKyl7CgkJCWlmKCFzZXRqbXAobWFpbmxvb3ApKXsKCQkJCXQg PSB0bXBjc3RyKGFyZ3ZbaV0pOwoJCQkJU3RyYWRkYyh0LCAnXDAnKTsKCQkJCVN0cmR1cGxzdHIo JmdlbnN0ciwgdCk7CgkJCQlmcmVldG1wc3RyKHQpOwoJCQkJZml4bmFtZSgmZ2Vuc3RyKTsKCQkJ CWxvZ3NldG5hbWUobmV3ZmlsZSgpLCAmZ2Vuc3RyKTsKCQkJfQoJCX0KCX1lbHNlIGlmKCFkb3du bG9hZGVkKQoJCW5ld2ZpbGUoKTsKCXNlcSsrOwoJaWYoZmlsZS5udXNlZCkKCQljdXJyZW50KGZp bGUuZmlsZXBwdHJbMF0pOwoJc2V0am1wKG1haW5sb29wKTsKCWNtZGxvb3AoKTsKCXRyeXRvcXVp dCgpOwkvKiBpZiB3ZSBhbHJlYWR5IHEnZWQsIHF1aXRvayB3aWxsIGJlIFRSVUUgKi8KCWV4aXRz KDApOwp9Cgp2b2lkCnVzYWdlKHZvaWQpCnsKCWRwcmludCgidXNhZ2U6IHNhbSBbLWRdIFstdCBz YW10ZXJtXSBbLXMgc2FtIG5hbWVdIC1yIG1hY2hpbmVcbiIpOwoJZXhpdHMoInVzYWdlIik7Cn0K CnZvaWQKcmVzY3VlKHZvaWQpCnsKCWludCBpLCBuYmxhbmsgPSAwOwoJRmlsZSAqZjsKCWNoYXIg KmM7CgljaGFyIGJ1ZlsyNTZdOwoKCWlmKHJlc2N1aW5nKyspCgkJcmV0dXJuOwoJaW8gPSAtMTsK CWZvcihpPTA7IGk8ZmlsZS5udXNlZDsgaSsrKXsKCQlmID0gZmlsZS5maWxlcHB0cltpXTsKCQlp ZihmPT1jbWQgfHwgZi0+VS5uYz09MCB8fCAhZmlsZWlzZGlydHkoZikpCgkJCWNvbnRpbnVlOwoJ CWlmKGlvID09IC0xKXsKCQkJc3ByaW50KGJ1ZiwgIiVzL3NhbS5zYXZlIiwgaG9tZSk7CgkJCWlv ID0gY3JlYXRlKGJ1ZiwgMSwgMDc3Nyk7CgkJCWlmKGlvPDApCgkJCQlyZXR1cm47CgkJfQoJCWlm KGYtPm5hbWUuc1swXSl7CgkJCWMgPSBTdHJ0b2MoJmYtPm5hbWUpOwoJCQlzdHJuY3B5KGJ1Ziwg Yywgc2l6ZW9mIGJ1Zi0xKTsKCQkJYnVmW3NpemVvZiBidWYtMV0gPSAwOwoJCQlmcmVlKGMpOwoJ CX1lbHNlCgkJCXNwcmludChidWYsICJuYW1lbGVzcy4lZCIsIG5ibGFuaysrKTsKCQlmcHJpbnQo aW8sICIjISVzICclcycgJCogPDwnLS0tJXMnXG4iLCBTQU1TQVZFQ01ELCBidWYsIGJ1Zik7CgkJ YWRkci5yLnAxID0gMCwgYWRkci5yLnAyID0gZi0+VS5uYzsKCQl3cml0ZWlvKGYpOwoJCWZwcmlu dChpbywgIlxuLS0tJXNcbiIsIChjaGFyICopYnVmKTsKCX0KfQoKdm9pZApwYW5pYyhjaGFyICpz KQp7CglpbnQgd2FzZDsKCglpZighcGFuaWNraW5nKysgJiYgIXNldGptcChtYWlubG9vcCkpewoJ CXdhc2QgPSBkb3dubG9hZGVkOwoJCWRvd25sb2FkZWQgPSAwOwoJCWRwcmludCgic2FtOiBwYW5p YzogJXM6ICVyXG4iLCBzKTsKCQlpZih3YXNkKQoJCQlmcHJpbnQoMiwgInNhbTogcGFuaWM6ICVz OiAlclxuIiwgcyk7CgkJcmVzY3VlKCk7CgkJYWJvcnQoKTsKCX0KfQoKdm9pZApoaWNjb3VnaChj aGFyICpzKQp7CglGaWxlICpmOwoJaW50IGk7CgoJaWYocmVzY3VpbmcpCgkJZXhpdHMoInJlc2N1 ZSIpOwoJaWYocykKCQlkcHJpbnQoIiVzXG4iLCBzKTsKCXJlc2V0Y21kKCk7CglyZXNldHhlYygp OwoJcmVzZXRzeXMoKTsKCWlmKGlvID4gMCkKCQljbG9zZShpbyk7CgoJLyoKCSAqIGJhY2sgb3V0 IGFueSBsb2dnZWQgY2hhbmdlcyAmIHJlc3RvcmUgb2xkIHNlcXVlbmNlcwoJICovCglmb3IoaT0w OyBpPGZpbGUubnVzZWQ7IGkrKyl7CgkJZiA9IGZpbGUuZmlsZXBwdHJbaV07CgkJaWYoZj09Y21k KQoJCQljb250aW51ZTsKCQlpZihmLT5zZXE9PXNlcSl7CgkJCWJ1ZmRlbGV0ZSgmZi0+ZXBzaWxv biwgMCwgZi0+ZXBzaWxvbi5uYyk7CgkJCWYtPnNlcSA9IGYtPnByZXZzZXE7CgkJCWYtPmRvdC5y ID0gZi0+cHJldmRvdDsKCQkJZi0+bWFyayA9IGYtPnByZXZtYXJrOwoJCQlzdGF0ZShmLCBmLT5w cmV2bW9kID8gRGlydHk6IENsZWFuKTsKCQl9Cgl9CgoJdXBkYXRlKCk7CglpZiAoY3VyZmlsZSkg ewoJCWlmIChjdXJmaWxlLT51bnJlYWQpCgkJCWN1cmZpbGUtPnVucmVhZCA9IEZBTFNFOwoJCWVs c2UgaWYgKGRvd25sb2FkZWQpCgkJCW91dFRzKEhjdXJyZW50LCBjdXJmaWxlLT50YWcpOwoJfQoJ bG9uZ2ptcChtYWlubG9vcCwgMSk7Cn0KCnZvaWQKaW50cih2b2lkKQp7CgllcnJvcihFaW50cik7 Cn0KCnZvaWQKdHJ5dG9jbG9zZShGaWxlICpmKQp7CgljaGFyICp0OwoJY2hhciBidWZbMjU2XTsK CglpZihmID09IGNtZCkJLyogcG9zc2libGU/ICovCgkJcmV0dXJuOwoJaWYoZi0+ZGVsZXRlZCkK CQlyZXR1cm47CglpZihmaWxlaXNkaXJ0eShmKSAmJiAhZi0+Y2xvc2Vvayl7CgkJZi0+Y2xvc2Vv ayA9IFRSVUU7CgkJaWYoZi0+bmFtZS5zWzBdKXsKCQkJdCA9IFN0cnRvYygmZi0+bmFtZSk7CgkJ CXN0cm5jcHkoYnVmLCB0LCBzaXplb2YgYnVmLTEpOwoJCQlmcmVlKHQpOwoJCX1lbHNlCgkJCXN0 cmNweShidWYsICJuYW1lbGVzcyBmaWxlIik7CgkJZXJyb3JfcyhFbW9kaWZpZWQsIGJ1Zik7Cgl9 CglmLT5kZWxldGVkID0gVFJVRTsKfQoKdm9pZAp0cnl0b3F1aXQodm9pZCkKewoJaW50IGM7CglG aWxlICpmOwoKCWlmKCFxdWl0b2spewoJCWZvcihjID0gMDsgYzxmaWxlLm51c2VkOyBjKyspewoJ CQlmID0gZmlsZS5maWxlcHB0cltjXTsKCQkJaWYoZiE9Y21kICYmIGZpbGVpc2RpcnR5KGYpKXsK CQkJCXF1aXRvayA9IFRSVUU7CgkJCQllb2YgPSBGQUxTRTsKCQkJCWVycm9yKEVjaGFuZ2VzKTsK CQkJfQoJCX0KCX0KfQoKdm9pZApsb2FkKEZpbGUgKmYpCnsKCUFkZHJlc3Mgc2F2ZWFkZHI7CgoJ U3RyZHVwbHN0cigmZ2Vuc3RyLCAmZi0+bmFtZSk7CglmaWxlbmFtZShmKTsKCWlmKGYtPm5hbWUu c1swXSl7CgkJc2F2ZWFkZHIgPSBhZGRyOwoJCWVkaXQoZiwgJ0knKTsKCQlhZGRyID0gc2F2ZWFk ZHI7Cgl9ZWxzZXsKCQlmLT51bnJlYWQgPSAwOwoJCWYtPmNsZWFuc2VxID0gZi0+c2VxOwoJfQoK CWZpbGV1cGRhdGUoZiwgVFJVRSwgVFJVRSk7Cn0KCnZvaWQKY21kdXBkYXRlKHZvaWQpCnsKCWlm KGNtZCAmJiBjbWQtPnNlcSE9MCl7CgkJZmlsZXVwZGF0ZShjbWQsIEZBTFNFLCBkb3dubG9hZGVk KTsKCQljbWQtPmRvdC5yLnAxID0gY21kLT5kb3Quci5wMiA9IGNtZC0+VS5uYzsKCQl0ZWxsZG90 KGNtZCk7Cgl9Cn0KCnZvaWQKZGVsZXRlKEZpbGUgKmYpCnsKCWlmKGRvd25sb2FkZWQgJiYgZi0+ cmFzcCkKCQlvdXRUcyhIY2xvc2UsIGYtPnRhZyk7CglkZWxmaWxlKGYpOwoJaWYoZiA9PSBjdXJm aWxlKQoJCWN1cnJlbnQoMCk7Cn0KCnZvaWQKdXBkYXRlKHZvaWQpCnsKCWludCBpLCBhbnltb2Q7 CglGaWxlICpmOwoKCXNldHRlbXBmaWxlKCk7Cglmb3IoYW55bW9kID0gaT0wOyBpPHRlbXBmaWxl Lm51c2VkOyBpKyspewoJCWYgPSB0ZW1wZmlsZS5maWxlcHB0cltpXTsKCQlpZihmPT1jbWQpCS8q IGNtZCBnZXRzIGRvbmUgaW4gbWFpbigpICovCgkJCWNvbnRpbnVlOwoJCWlmKGYtPmRlbGV0ZWQp IHsKCQkJZGVsZXRlKGYpOwoJCQljb250aW51ZTsKCQl9CgkJaWYoZi0+c2VxPT1zZXEgJiYgZmls ZXVwZGF0ZShmLCBGQUxTRSwgZG93bmxvYWRlZCkpCgkJCWFueW1vZCsrOwoJCWlmKGYtPnJhc3Ap CgkJCXRlbGxkb3QoZik7Cgl9CglpZihhbnltb2QpCgkJc2VxKys7Cn0KCkZpbGUgKgpjdXJyZW50 KEZpbGUgKmYpCnsKCXJldHVybiBjdXJmaWxlID0gZjsKfQoKdm9pZAplZGl0KEZpbGUgKmYsIGlu dCBjbWQpCnsKCWludCBlbXB0eSA9IFRSVUU7CglQb3NuIHA7CglpbnQgbnVsbHM7CgoJaWYoY21k ID09ICdyJykKCQlsb2dkZWxldGUoZiwgYWRkci5yLnAxLCBhZGRyLnIucDIpOwoJaWYoY21kPT0n ZScgfHwgY21kPT0nSScpewoJCWxvZ2RlbGV0ZShmLCAoUG9zbikwLCBmLT5VLm5jKTsKCQlhZGRy LnIucDIgPSBmLT5VLm5jOwoJfWVsc2UgaWYoZi0+VS5uYyE9MCB8fCAoZi0+bmFtZS5zWzBdICYm IFN0cmNtcCgmZ2Vuc3RyLCAmZi0+bmFtZSkhPTApKQoJCWVtcHR5ID0gRkFMU0U7CglpZigoaW8g PSBvcGVuKGdlbmMsIE9SRUFEKSk8MCkgewoJCWlmIChjdXJmaWxlICYmIGN1cmZpbGUtPnVucmVh ZCkKCQkJY3VyZmlsZS0+dW5yZWFkID0gRkFMU0U7CgkJZXJyb3JfcyhFb3BlbiwgZ2VuYyk7Cgl9 CglwID0gcmVhZGlvKGYsICZudWxscywgZW1wdHksIFRSVUUpOwoJY2xvc2VpbygoY21kPT0nZScg fHwgY21kPT0nSScpPyAtMSA6IHApOwoJaWYoY21kID09ICdyJykKCQlmLT5uZG90LnIucDEgPSBh ZGRyLnIucDIsIGYtPm5kb3Quci5wMiA9IGFkZHIuci5wMitwOwoJZWxzZQoJCWYtPm5kb3Quci5w MSA9IGYtPm5kb3Quci5wMiA9IDA7CglmLT5jbG9zZW9rID0gZW1wdHk7CglpZiAocXVpdG9rKQoJ CXF1aXRvayA9IGVtcHR5OwoJZWxzZQoJCXF1aXRvayA9IEZBTFNFOwoJc3RhdGUoZiwgZW1wdHkg JiYgIW51bGxzPyBDbGVhbiA6IERpcnR5KTsKCWlmKGVtcHR5ICYmICFudWxscykKCQlmLT5jbGVh bnNlcSA9IGYtPnNlcTsKCWlmKGNtZCA9PSAnZScpCgkJZmlsZW5hbWUoZik7Cn0KCmludApnZXRu YW1lKEZpbGUgKmYsIFN0cmluZyAqcywgaW50IHNhdmUpCnsKCWludCBjLCBpOwoKCVN0cnplcm8o JmdlbnN0cik7CglpZihnZW5jKXsKCQlmcmVlKGdlbmMpOwoJCWdlbmMgPSAwOwoJfQoJaWYocz09 MCB8fCAoYyA9IHMtPnNbMF0pPT0wKXsJCS8qIG5vIG5hbWUgcHJvdmlkZWQgKi8KCQlpZihmKQoJ CQlTdHJkdXBsc3RyKCZnZW5zdHIsICZmLT5uYW1lKTsKCQlnb3RvIFJldHVybjsKCX0KCWlmKGMh PScgJyAmJiBjIT0nXHQnKQoJCWVycm9yKEVibGFuayk7Cglmb3IoaT0wOyAoYz1zLT5zW2ldKT09 JyAnIHx8IGM9PSdcdCc7IGkrKykKCQk7Cgl3aGlsZShzLT5zW2ldID4gJyAnKQoJCVN0cmFkZGMo JmdlbnN0ciwgcy0+c1tpKytdKTsKCWlmKHMtPnNbaV0pCgkJZXJyb3IoRW5ld2xpbmUpOwoJZml4 bmFtZSgmZ2Vuc3RyKTsKCWlmKGYgJiYgKHNhdmUgfHwgZi0+bmFtZS5zWzBdPT0wKSl7CgkJbG9n c2V0bmFtZShmLCAmZ2Vuc3RyKTsKCQlpZihTdHJjbXAoJmYtPm5hbWUsICZnZW5zdHIpKXsKCQkJ cXVpdG9rID0gZi0+Y2xvc2VvayA9IEZBTFNFOwoJCQlmLT5xaWRwYXRoID0gMDsKCQkJZi0+bXRp bWUgPSAwOwoJCQlzdGF0ZShmLCBEaXJ0eSk7IC8qIGlmIGl0J3MgJ2UnLCBmaXggbGF0ZXIgKi8K CQl9Cgl9CiAgICBSZXR1cm46CglnZW5jID0gU3RydG9jKCZnZW5zdHIpOwoJaSA9IGdlbnN0ci5u OwoJaWYoaSAmJiBnZW5zdHIuc1tpLTFdPT0wKQoJCWktLTsKCXJldHVybiBpOwkvKiBzdHJsZW4o bmFtZSkgKi8KfQoKdm9pZApmaWxlbmFtZShGaWxlICpmKQp7CglpZihnZW5jKQoJCWZyZWUoZ2Vu Yyk7CglnZW5jID0gU3RydG9jKCZnZW5zdHIpOwoJZHByaW50KCIlYyVjJWMgJXNcbiIsICIgJyJb Zi0+bW9kXSwKCQkiLSsiW2YtPnJhc3AhPTBdLCAiIC4iW2Y9PWN1cmZpbGVdLCBnZW5jKTsKfQoK dm9pZAp1bmRvc3RlcChGaWxlICpmLCBpbnQgaXN1bmRvKQp7Cgl1aW50IHAxLCBwMjsKCWludCBt b2Q7CgoJbW9kID0gZi0+bW9kOwoJZmlsZXVuZG8oZiwgaXN1bmRvLCAxLCAmcDEsICZwMiwgVFJV RSk7CglmLT5uZG90ID0gZi0+ZG90OwoJaWYoZi0+bW9kKXsKCQlmLT5jbG9zZW9rID0gMDsKCQlx dWl0b2sgPSAwOwoJfWVsc2UKCQlmLT5jbG9zZW9rID0gMTsKCglpZihmLT5tb2QgIT0gbW9kKXsK CQlmLT5tb2QgPSBtb2Q7CgkJaWYobW9kKQoJCQltb2QgPSBDbGVhbjsKCQllbHNlCgkJCW1vZCA9 IERpcnR5OwoJCXN0YXRlKGYsIG1vZCk7Cgl9Cn0KCmludAp1bmRvKGludCBpc3VuZG8pCnsKCUZp bGUgKmY7CglpbnQgaTsKCU1vZCBtYXg7CgoJbWF4ID0gdW5kb3NlcShjdXJmaWxlLCBpc3VuZG8p OwoJaWYobWF4ID09IDApCgkJcmV0dXJuIDA7CglzZXR0ZW1wZmlsZSgpOwoJZm9yKGkgPSAwOyBp PHRlbXBmaWxlLm51c2VkOyBpKyspewoJCWYgPSB0ZW1wZmlsZS5maWxlcHB0cltpXTsKCQlpZihm IT1jbWQgJiYgdW5kb3NlcShmLCBpc3VuZG8pPT1tYXgpCgkJCXVuZG9zdGVwKGYsIGlzdW5kbyk7 Cgl9CglyZXR1cm4gMTsKfQoKaW50CnJlYWRjbWQoU3RyaW5nICpzKQp7CglpbnQgcmV0Y29kZTsK CglpZihmbGlzdCAhPSAwKQoJCWZpbGVjbG9zZShmbGlzdCk7CglmbGlzdCA9IGZpbGVvcGVuKCk7 CgoJYWRkci5yLnAxID0gMCwgYWRkci5yLnAyID0gZmxpc3QtPlUubmM7CglyZXRjb2RlID0gcGxh bjkoZmxpc3QsICc8JywgcywgRkFMU0UpOwoJZmlsZXVwZGF0ZShmbGlzdCwgRkFMU0UsIEZBTFNF KTsKCWZsaXN0LT5zZXEgPSAwOwoJaWYgKGZsaXN0LT5VLm5jID4gQkxPQ0tTSVpFKQoJCWVycm9y KEV0b29sb25nKTsKCVN0cnplcm8oJmdlbnN0cik7CglTdHJpbnN1cmUoJmdlbnN0ciwgZmxpc3Qt PlUubmMpOwoJYnVmcmVhZCgmZmxpc3QtPlUsIChQb3NuKTAsIGdlbmJ1ZiwgZmxpc3QtPlUubmMp OwoJbWVtbW92ZShnZW5zdHIucywgZ2VuYnVmLCBmbGlzdC0+VS5uYypSVU5FU0laRSk7CglnZW5z dHIubiA9IGZsaXN0LT5VLm5jOwoJU3RyYWRkYygmZ2Vuc3RyLCAnXDAnKTsKCXJldHVybiByZXRj b2RlOwp9Cgp2b2lkCmdldGN1cndkKHZvaWQpCnsKCVN0cmluZyAqdDsKCWNoYXIgYnVmWzI1Nl07 CgoJYnVmWzBdID0gMDsKCWdldHdkKGJ1Ziwgc2l6ZW9mKGJ1ZikpOwoJdCA9IHRtcGNzdHIoYnVm KTsKCVN0cmR1cGxzdHIoJmN1cndkLCB0KTsKCWZyZWV0bXBzdHIodCk7CglpZihjdXJ3ZC5uID09 IDApCgkJd2FybihXcHdkKTsKCWVsc2UgaWYoY3Vyd2Quc1tjdXJ3ZC5uLTFdICE9ICcvJykKCQlT dHJhZGRjKCZjdXJ3ZCwgJy8nKTsKfQoKdm9pZApjZChTdHJpbmcgKnN0cikKewoJaW50IGksIGZk OwoJY2hhciAqczsKCUZpbGUgKmY7CglTdHJpbmcgb3dkOwoKCWdldGN1cndkKCk7CglpZihnZXRu YW1lKChGaWxlICopMCwgc3RyLCBGQUxTRSkpCgkJcyA9IGdlbmM7CgllbHNlCgkJcyA9IGhvbWU7 CglpZihjaGRpcihzKSkKCQlzeXNlcnJvcigiY2hkaXIiKTsKCWZkID0gb3BlbigiL2Rldi93ZGly IiwgT1dSSVRFKTsKCWlmKGZkID4gMCkKCQl3cml0ZShmZCwgcywgc3RybGVuKHMpKTsKCWRwcmlu dCgiIVxuIik7CglTdHJpbml0KCZvd2QpOwoJU3RyZHVwbHN0cigmb3dkLCAmY3Vyd2QpOwoJZ2V0 Y3Vyd2QoKTsKCXNldHRlbXBmaWxlKCk7Cglmb3IoaT0wOyBpPHRlbXBmaWxlLm51c2VkOyBpKysp ewoJCWYgPSB0ZW1wZmlsZS5maWxlcHB0cltpXTsKCQlpZihmIT1jbWQgJiYgZi0+bmFtZS5zWzBd IT0nLycgJiYgZi0+bmFtZS5zWzBdIT0wKXsKCQkJU3RyaW5zZXJ0KCZmLT5uYW1lLCAmb3dkLCAo UG9zbikwKTsKCQkJZml4bmFtZSgmZi0+bmFtZSk7CgkJCXNvcnRuYW1lKGYpOwoJCX1lbHNlIGlm KGYgIT0gY21kICYmIFN0cmlzcHJlKCZjdXJ3ZCwgJmYtPm5hbWUpKXsKCQkJZml4bmFtZSgmZi0+ bmFtZSk7CgkJCXNvcnRuYW1lKGYpOwoJCX0KCX0KCVN0cmNsb3NlKCZvd2QpOwp9CgppbnQKbG9h ZGZsaXN0KFN0cmluZyAqcykKewoJaW50IGMsIGk7CgoJYyA9IHMtPnNbMF07Cglmb3IoaSA9IDA7 IHMtPnNbaV09PScgJyB8fCBzLT5zW2ldPT0nXHQnOyBpKyspCgkJOwoJaWYoKGM9PScgJyB8fCBj PT0nXHQnKSAmJiBzLT5zW2ldIT0nXG4nKXsKCQlpZihzLT5zW2ldPT0nPCcpewoJCQlTdHJkZWxl dGUocywgMEwsIChsb25nKWkrMSk7CgkJCXJlYWRjbWQocyk7CgkJfWVsc2V7CgkJCVN0cnplcm8o JmdlbnN0cik7CgkJCXdoaWxlKChjID0gcy0+c1tpKytdKSAmJiBjIT0nXG4nKQoJCQkJU3RyYWRk YygmZ2Vuc3RyLCBjKTsKCQkJU3RyYWRkYygmZ2Vuc3RyLCAnXDAnKTsKCQl9Cgl9ZWxzZXsKCQlp ZihjICE9ICdcbicpCgkJCWVycm9yKEVibGFuayk7CgkJU3RyZHVwbCgmZ2Vuc3RyLCBlbXB0eSk7 Cgl9CglpZihnZW5jKQoJCWZyZWUoZ2VuYyk7CglnZW5jID0gU3RydG9jKCZnZW5zdHIpOwoJcmV0 dXJuIGdlbnN0ci5zWzBdOwp9CgpGaWxlICoKcmVhZGZsaXN0KGludCByZWFkYWxsLCBpbnQgZGVs ZXRlKQp7CglQb3NuIGk7CglpbnQgYzsKCUZpbGUgKmY7CglTdHJpbmcgdDsKCglTdHJpbml0KCZ0 KTsKCWZvcihpPTAsZj0wOyBmPT0wIHx8IHJlYWRhbGwgfHwgZGVsZXRlOyBpKyspewkvKiArKyBz a2lwcyBibGFuayAqLwoJCVN0cmRlbGV0ZSgmZ2Vuc3RyLCAoUG9zbikwLCBpKTsKCQlmb3IoaT0w OyAoYyA9IGdlbnN0ci5zW2ldKT09JyAnIHx8IGM9PSdcdCcgfHwgYz09J1xuJzsgaSsrKQoJCQk7 CgkJaWYoaSA+PSBnZW5zdHIubikKCQkJYnJlYWs7CgkJU3RyZGVsZXRlKCZnZW5zdHIsIChQb3Nu KTAsIGkpOwoJCWZvcihpPTA7IChjPWdlbnN0ci5zW2ldKSAmJiBjIT0nICcgJiYgYyE9J1x0JyAm JiBjIT0nXG4nOyBpKyspCgkJCTsKCgkJaWYoaSA9PSAwKQoJCQlicmVhazsKCQlnZW5zdHIuc1tp XSA9IDA7CgkJU3RyZHVwbHN0cigmdCwgdG1wcnN0cihnZW5zdHIucywgaSsxKSk7CgkJZml4bmFt ZSgmdCk7CgkJZiA9IGxvb2tmaWxlKCZ0KTsKCQlpZihkZWxldGUpewoJCQlpZihmID09IDApCgkJ CQl3YXJuX1MoV2ZpbGUsICZ0KTsKCQkJZWxzZQoJCQkJdHJ5dG9jbG9zZShmKTsKCQl9ZWxzZSBp ZihmPT0wICYmIHJlYWRhbGwpCgkJCWxvZ3NldG5hbWUoZiA9IG5ld2ZpbGUoKSwgJnQpOwoJfQoJ U3RyY2xvc2UoJnQpOwoJcmV0dXJuIGY7Cn0KCkZpbGUgKgp0b2ZpbGUoU3RyaW5nICpzKQp7CglG aWxlICpmOwoKCWlmKHMtPnNbMF0gIT0gJyAnKQoJCWVycm9yKEVibGFuayk7CglpZihsb2FkZmxp c3QocykgPT0gMCl7CgkJZiA9IGxvb2tmaWxlKCZnZW5zdHIpOwkvKiBlbXB0eSBzdHJpbmcgPT0+ IG5hbWVsZXNzIGZpbGUgKi8KCQlpZihmID09IDApCgkJCWVycm9yX3MoRW1lbnUsIGdlbmMpOwoJ fWVsc2UgaWYoKGY9cmVhZGZsaXN0KEZBTFNFLCBGQUxTRSkpID09IDApCgkJZXJyb3JfcyhFbWVu dSwgZ2VuYyk7CglyZXR1cm4gY3VycmVudChmKTsKfQoKRmlsZSAqCmdldGZpbGUoU3RyaW5nICpz KQp7CglGaWxlICpmOwoKCWlmKGxvYWRmbGlzdChzKSA9PSAwKQoJCWxvZ3NldG5hbWUoZiA9IG5l d2ZpbGUoKSwgJmdlbnN0cik7CgllbHNlIGlmKChmPXJlYWRmbGlzdChUUlVFLCBGQUxTRSkpID09 IDApCgkJZXJyb3IoRWJsYW5rKTsKCXJldHVybiBjdXJyZW50KGYpOwp9Cgp2b2lkCmNsb3NlZmls ZXMoRmlsZSAqZiwgU3RyaW5nICpzKQp7CglpZihzLT5zWzBdID09IDApewoJCWlmKGYgPT0gMCkK CQkJZXJyb3IoRW5vZmlsZSk7CgkJdHJ5dG9jbG9zZShmKTsKCQlyZXR1cm47Cgl9CglpZihzLT5z WzBdICE9ICcgJykKCQllcnJvcihFYmxhbmspOwoJaWYobG9hZGZsaXN0KHMpID09IDApCgkJZXJy b3IoRW5ld2xpbmUpOwoJcmVhZGZsaXN0KEZBTFNFLCBUUlVFKTsKfQoKdm9pZApjb3B5KEZpbGUg KmYsIEFkZHJlc3MgYWRkcjIpCnsKCVBvc24gcDsKCWludCBuaTsKCWZvcihwPWFkZHIuci5wMTsg cDxhZGRyLnIucDI7IHArPW5pKXsKCQluaSA9IGFkZHIuci5wMi1wOwoJCWlmKG5pID4gQkxPQ0tT SVpFKQoJCQluaSA9IEJMT0NLU0laRTsKCQlidWZyZWFkKCZmLT5VLCBwLCBnZW5idWYsIG5pKTsK CQlsb2dpbnNlcnQoYWRkcjIuZiwgYWRkcjIuci5wMiwgdG1wcnN0cihnZW5idWYsIG5pKS0+cywg bmkpOwoJfQoJYWRkcjIuZi0+bmRvdC5yLnAyID0gYWRkcjIuci5wMisoZi0+ZG90LnIucDItZi0+ ZG90LnIucDEpOwoJYWRkcjIuZi0+bmRvdC5yLnAxID0gYWRkcjIuci5wMjsKfQoKdm9pZAptb3Zl KEZpbGUgKmYsIEFkZHJlc3MgYWRkcjIpCnsKCWlmKGFkZHIuci5wMiA8PSBhZGRyMi5yLnAyKXsK CQlsb2dkZWxldGUoZiwgYWRkci5yLnAxLCBhZGRyLnIucDIpOwoJCWNvcHkoZiwgYWRkcjIpOwoJ fWVsc2UgaWYoYWRkci5yLnAxID49IGFkZHIyLnIucDIpewoJCWNvcHkoZiwgYWRkcjIpOwoJCWxv Z2RlbGV0ZShmLCBhZGRyLnIucDEsIGFkZHIuci5wMik7Cgl9ZWxzZQoJCWVycm9yKEVvdmVybGFw KTsKfQoKUG9zbgpubGNvdW50KEZpbGUgKmYsIFBvc24gcDAsIFBvc24gcDEpCnsKCVBvc24gbmwg PSAwOwoKCXdoaWxlKHAwIDwgcDEpCgkJaWYoZmlsZXJlYWRjKGYsIHAwKyspPT0nXG4nKQoJCQlu bCsrOwoJcmV0dXJuIG5sOwp9Cgp2b2lkCnByaW50cG9zbihGaWxlICpmLCBpbnQgY2hhcnNvbmx5 KQp7CglQb3NuIGwxLCBsMjsKCglpZighY2hhcnNvbmx5KXsKCQlsMSA9IDErbmxjb3VudChmLCAo UG9zbikwLCBhZGRyLnIucDEpOwoJCWwyID0gbDErbmxjb3VudChmLCBhZGRyLnIucDEsIGFkZHIu ci5wMik7CgkJLyogY2hlY2sgaWYgYWRkciBlbmRzIHdpdGggJ1xuJyAqLwoJCWlmKGFkZHIuci5w Mj4wICYmIGFkZHIuci5wMj5hZGRyLnIucDEgJiYgZmlsZXJlYWRjKGYsIGFkZHIuci5wMi0xKT09 J1xuJykKCQkJLS1sMjsKCQlkcHJpbnQoIiVsdWQiLCBsMSk7CgkJaWYobDIgIT0gbDEpCgkJCWRw cmludCgiLCVsdWQiLCBsMik7CgkJZHByaW50KCI7ICIpOwoJfQoJZHByaW50KCIjJWx1ZCIsIGFk ZHIuci5wMSk7CglpZihhZGRyLnIucDIgIT0gYWRkci5yLnAxKQoJCWRwcmludCgiLCMlbHVkIiwg YWRkci5yLnAyKTsKCWRwcmludCgiXG4iKTsKfQoKdm9pZApzZXR0ZW1wZmlsZSh2b2lkKQp7Cglp Zih0ZW1wZmlsZS5uYWxsb2MgPCBmaWxlLm51c2VkKXsKCQlmcmVlKHRlbXBmaWxlLmxpc3RwdHIp OwoJCXRlbXBmaWxlLmxpc3RwdHIgPSBlbWFsbG9jKHNpemVvZigqdGVtcGZpbGUuZmlsZXBwdHIp KmZpbGUubnVzZWQpOwoJCXRlbXBmaWxlLm5hbGxvYyA9IGZpbGUubnVzZWQ7Cgl9Cgl0ZW1wZmls ZS5udXNlZCA9IGZpbGUubnVzZWQ7CgltZW1tb3ZlKCZ0ZW1wZmlsZS5maWxlcHB0clswXSwgJmZp bGUuZmlsZXBwdHJbMF0sIGZpbGUubnVzZWQqc2l6ZW9mKEZpbGUqKSk7Cn0KAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzYW0yay9zYW0vc2FtLmgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAxNzM3ADAwMDAxNTEAMDAwMDAwMjI1MjMAMDcxMTE2 MzU2NTAAMDAxNDUwMQAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHVzdGFyADAwc2Nod2FydHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnY3NlAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADAwMDAwNDAAMDAwMDAyNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNpbmNsdWRlIDx1Lmg+CiNpbmNsdWRlIDxsaWJj Lmg+CiNpbmNsdWRlIDxwbHVtYi5oPgojaW5jbHVkZSAiZXJyb3JzLmgiCgovKgogKiBCTE9DS1NJ WkUgaXMgcmVsYXRpdmVseSBzbWFsbCB0byBrZWVwIG1lbW9yeSBjb25zdW1wdGlvbiBkb3duLgog Ki8KCiNkZWZpbmUJQkxPQ0tTSVpFCTIwNDgKI2RlZmluZQlSVU5FU0laRQlzaXplb2YoUnVuZSkK I2RlZmluZQlORElTQwkJNQojZGVmaW5lCU5CVUZGSUxFUwkzKzIqTkRJU0MJLyogcGxhbiA5K3Vu ZG8rc25hcmYrTkRJU0MqKHRyYW5zY3JpcHQrYnVmKSAqLwojZGVmaW5lIE5TVUJFWFAJMTAKCiNk ZWZpbmUJVFJVRQkJMQojZGVmaW5lCUZBTFNFCQkwCgojZGVmaW5lCUlORklOSVRZCTB4N0ZGRkZG RkZMCiNkZWZpbmUJSU5DUgkJMjUKI2RlZmluZQlTVFJTSVpFCQkoMipCTE9DS1NJWkUpCgp0eXBl ZGVmIGxvbmcJCVBvc247CQkvKiBmaWxlIHBvc2l0aW9uIG9yIGFkZHJlc3MgKi8KdHlwZWRlZgl1 c2hvcnQJCU1vZDsJCS8qIG1vZGlmaWNhdGlvbiBudW1iZXIgKi8KCnR5cGVkZWYgc3RydWN0IEFk ZHJlc3MJQWRkcmVzczsKdHlwZWRlZiBzdHJ1Y3QgQmxvY2sJQmxvY2s7CnR5cGVkZWYgc3RydWN0 IEJ1ZmZlcglCdWZmZXI7CnR5cGVkZWYgc3RydWN0IERpc2sJRGlzazsKdHlwZWRlZiBzdHJ1Y3Qg RGlzY2Rlc2MJRGlzY2Rlc2M7CnR5cGVkZWYgc3RydWN0IEZpbGUJRmlsZTsKdHlwZWRlZiBzdHJ1 Y3QgTGlzdAlMaXN0Owp0eXBlZGVmIHN0cnVjdCBSYW5nZQlSYW5nZTsKdHlwZWRlZiBzdHJ1Y3Qg UmFuZ2VzZXQJUmFuZ2VzZXQ7CnR5cGVkZWYgc3RydWN0IFN0cmluZwlTdHJpbmc7CgplbnVtIFN0 YXRlCnsKCUNsZWFuID0JCScgJywKCURpcnR5ID0JCSdcJycsCglVbnJlYWQgPQknLScgCn07Cgpz dHJ1Y3QgUmFuZ2UKewoJUG9zbglwMSwgcDI7Cn07CgpzdHJ1Y3QgUmFuZ2VzZXQKewoJUmFuZ2UJ cFtOU1VCRVhQXTsKfTsKCnN0cnVjdCBBZGRyZXNzCnsKCVJhbmdlCXI7CglGaWxlCSpmOwp9OwoK c3RydWN0IFN0cmluZwp7CglzaG9ydAluOwoJc2hvcnQJc2l6ZTsKCVJ1bmUJKnM7Cn07CgpzdHJ1 Y3QgTGlzdAkvKiBjb2RlIGRlcGVuZHMgb24gYSBsb25nIGJlaW5nIGFibGUgdG8gaG9sZCBhIHBv aW50ZXIgKi8KewoJaW50CW5hbGxvYzsKCWludAludXNlZDsKCXVuaW9uewoJCXZvaWQJKmxpc3Rw OwoJCUJsb2NrCSpibGtwOwoJCWxvbmcJKmxvbmdwOwoJCXVjaGFyKgkqdWNoYXJwOwoJCVN0cmlu ZyoJKnN0cmluZ3A7CgkJRmlsZSoJKmZpbGVwOwoJCWxvbmcJbGlzdHY7Cgl9ZzsKfTsKCiNkZWZp bmUJbGlzdHB0cgkJZy5saXN0cAojZGVmaW5lCWJsa3B0cgkJZy5ibGtwCiNkZWZpbmUJbG9uZ3B0 cgkJZy5sb25ncAojZGVmaW5lCXVjaGFycHB0cglnLnVjaGFycAojZGVmaW5lCXN0cmluZ3BwdHIJ Zy5zdHJpbmdwCiNkZWZpbmUJZmlsZXBwdHIJZy5maWxlcAojZGVmaW5lCWxpc3R2YWwJCWcubGlz dHYKCmVudW0KewoJQmxvY2tpbmNyID0JMjU2LAoJTWF4YmxvY2sgPSAJOCoxMDI0LAoKCUJVRlNJ WkUgPSBNYXhibG9jaywJLyogc2l6ZSBmcm9tIGZidWZhbGxvYygpICovCglSQlVGU0laRSA9IEJV RlNJWkUvc2l6ZW9mKFJ1bmUpIAp9OwoKCmVudW0KewoJTnVsbAkJPSAnLScsCglEZWxldGUJCT0g J2QnLAoJSW5zZXJ0CQk9ICdpJywKCUZpbGVuYW1lCT0gJ2YnLAoJRG90CQk9ICdEJywKCU1hcmsJ CT0gJ20nIAp9OwoKc3RydWN0IEJsb2NrCnsKCXVpbnQJCWFkZHI7CS8qIGRpc2sgYWRkcmVzcyBp biBieXRlcyAqLwoJdW5pb24KCXsKCQl1aW50CW47CS8qIG51bWJlciBvZiB1c2VkIHJ1bmVzIGlu IGJsb2NrICovCgkJQmxvY2sJKm5leHQ7CS8qIHBvaW50ZXIgdG8gbmV4dCBpbiBmcmVlIGxpc3Qg Ki8KCX0gVTsKfTsKCnN0cnVjdCBEaXNrCnsKCWludAkJZmQ7Cgl1aW50CQlhZGRyOwkvKiBsZW5n dGggb2YgdGVtcCBmaWxlICovCglCbG9jawkJKmZyZWVbTWF4YmxvY2svQmxvY2tpbmNyKzFdOwp9 OwoKRGlzayoJCWRpc2tpbml0KHZvaWQpOwpCbG9jayoJCWRpc2tuZXdibG9jayhEaXNrKiwgdWlu dCk7CnZvaWQJCWRpc2tyZWxlYXNlKERpc2sqLCBCbG9jayopOwp2b2lkCQlkaXNrcmVhZChEaXNr KiwgQmxvY2sqLCBSdW5lKiwgdWludCk7CnZvaWQJCWRpc2t3cml0ZShEaXNrKiwgQmxvY2sqKiwg UnVuZSosIHVpbnQpOwoKc3RydWN0IEJ1ZmZlcgp7Cgl1aW50CQluYzsKCVJ1bmUJCSpjOwkvKiBj YWNoZSAqLwoJdWludAkJY25jOwkvKiBieXRlcyBpbiBjYWNoZSAqLwoJdWludAkJY21heDsJLyog c2l6ZSBvZiBhbGxvY2F0ZWQgY2FjaGUgKi8KCXVpbnQJCWNxOwkvKiBwb3NpdGlvbiBvZiBjYWNo ZSAqLwoJaW50CQljZGlydHk7CS8qIGNhY2hlIG5lZWRzIHRvIGJlIHdyaXR0ZW4gKi8KCXVpbnQJ CWNiaTsJLyogaW5kZXggb2YgY2FjaGUgQmxvY2sgKi8KCUJsb2NrCQkqKmJsOwkvKiBhcnJheSBv ZiBibG9ja3MgKi8KCXVpbnQJCW5ibDsJLyogbnVtYmVyIG9mIGJsb2NrcyAqLwp9Owp2b2lkCQli dWZpbnNlcnQoQnVmZmVyKiwgdWludCwgUnVuZSosIHVpbnQpOwp2b2lkCQlidWZkZWxldGUoQnVm ZmVyKiwgdWludCwgdWludCk7CnVpbnQJCWJ1ZmxvYWQoQnVmZmVyKiwgdWludCwgaW50LCBpbnQq KTsKdm9pZAkJYnVmcmVhZChCdWZmZXIqLCB1aW50LCBSdW5lKiwgdWludCk7CnZvaWQJCWJ1ZmNs b3NlKEJ1ZmZlciopOwp2b2lkCQlidWZyZXNldChCdWZmZXIqKTsKCnN0cnVjdCBGaWxlCnsKCUJ1 ZmZlciBVOwkJCS8qIHRoZSBkYXRhICovCglCdWZmZXIJCWRlbHRhOwkJLyogdHJhbnNjcmlwdCBv ZiBjaGFuZ2VzICovCglCdWZmZXIJCWVwc2lsb247CS8qIGludmVyc2lvbiBvZiBkZWx0YSBmb3Ig cmVkbyAqLwoJU3RyaW5nCQluYW1lOwkJLyogbmFtZSBvZiBhc3NvY2lhdGVkIGZpbGUgKi8KCXVp bnQJCXFpZHBhdGg7CS8qIG9mIGZpbGUgd2hlbiByZWFkICovCgl1aW50CQltdGltZTsJCS8qIG9m IGZpbGUgd2hlbiByZWFkICovCglpbnQJCWRldjsJCS8qIG9mIGZpbGUgd2hlbiByZWFkICovCglp bnQJCXVucmVhZDsJCS8qIGZpbGUgaGFzIG5vdCBiZWVuIHJlYWQgZnJvbSBkaXNrICovCgoJbG9u ZwkJc2VxOwkJLyogaWYgc2VxPT0wLCBGaWxlIGFjdHMgbGlrZSBCdWZmZXIgKi8KCWxvbmcJCWNs ZWFuc2VxOwkvKiBmLT5zZXEgYXQgbGFzdCByZWFkL3dyaXRlIG9mIGZpbGUgKi8KCWludAkJbW9k OwkJLyogZmlsZSBhcHBlYXJzIG1vZGlmaWVkIGluIG1lbnUgKi8KCWNoYXIJCXJlc2N1aW5nOwkv KiBzYW0gZXhpdGluZzsgdGhpcyBmaWxlIHVudXNhYmxlICovCgovLwlUZXh0CQkqY3VydGV4dDsJ LyogbW9zdCByZWNlbnRseSB1c2VkIGFzc29jaWF0ZWQgdGV4dCAqLwovLwlUZXh0CQkqKnRleHQ7 CQkvKiBsaXN0IG9mIGFzc29jaWF0ZWQgdGV4dHMgKi8KLy8JaW50CQludGV4dDsKLy8JaW50CQlk dW1waWQ7CQkvKiB1c2VkIGluIGR1bXBpbmcgemVyb3hlZCB3aW5kb3dzICovCgoJUG9zbgkJaGlw b3NuOwkJLyogaGlnaGVzdCBhZGRyZXNzIHRvdWNoZWQgdGhpcyBNb2QgKi8KCUFkZHJlc3MJCWRv dDsJCS8qIGN1cnJlbnQgcG9zaXRpb24gKi8KCUFkZHJlc3MJCW5kb3Q7CQkvKiBuZXcgY3VycmVu dCBwb3NpdGlvbiBhZnRlciB1cGRhdGUgKi8KCVJhbmdlCQl0ZG90OwkJLyogd2hhdCB0ZXJtaW5h bCB0aGlua3MgaXMgY3VycmVudCByYW5nZSAqLwoJUmFuZ2UJCW1hcms7CQkvKiB0YWdnZWQgc3Bv dCBpbiB0ZXh0IChkb24ndCBjb25mdXNlIHdpdGggTWFyaykgKi8KCUxpc3QJCSpyYXNwOwkJLyog bWFwIG9mIHdoYXQgdGVybWluYWwncyBnb3QgKi8KCXNob3J0CQl0YWc7CQkvKiBmb3IgY29tbXVu aWNhdGluZyB3aXRoIHRlcm1pbmFsICovCgljaGFyCQljbG9zZW9rOwkvKiBvayB0byBjbG9zZSBm aWxlPyAqLwoJY2hhcgkJZGVsZXRlZDsJLyogZGVsZXRlIGF0IGNvbXBsZXRpb24gb2YgY29tbWFu ZCAqLwoJUmFuZ2UJCXByZXZkb3Q7CS8qIHN0YXRlIGJlZm9yZSBzdGFydCBvZiBjaGFuZ2UgKi8K CVJhbmdlCQlwcmV2bWFyazsKCWxvbmcJCXByZXZzZXE7CglpbnQJCXByZXZtb2Q7Cn07Ci8vRmls ZSoJCWZpbGVhZGR0ZXh0KEZpbGUqLCBUZXh0Kik7CnZvaWQJCWZpbGVjbG9zZShGaWxlKik7CnZv aWQJCWZpbGVkZWxldGUoRmlsZSosIHVpbnQsIHVpbnQpOwovL3ZvaWQJCWZpbGVkZWx0ZXh0KEZp bGUqLCBUZXh0Kik7CnZvaWQJCWZpbGVpbnNlcnQoRmlsZSosIHVpbnQsIFJ1bmUqLCB1aW50KTsK dWludAkJZmlsZWxvYWQoRmlsZSosIHVpbnQsIGludCwgaW50Kik7CnZvaWQJCWZpbGVtYXJrKEZp bGUqKTsKdm9pZAkJZmlsZXJlc2V0KEZpbGUqKTsKdm9pZAkJZmlsZXNldG5hbWUoRmlsZSosIFN0 cmluZyopOwp2b2lkCQlmaWxldW5kZWxldGUoRmlsZSosIEJ1ZmZlciosIHVpbnQsIHVpbnQpOwp2 b2lkCQlmaWxldW5pbnNlcnQoRmlsZSosIEJ1ZmZlciosIHVpbnQsIHVpbnQpOwp2b2lkCQlmaWxl dW5zZXRuYW1lKEZpbGUqLCBCdWZmZXIqKTsKdm9pZAkJZmlsZXVuZG8oRmlsZSosIGludCwgaW50 LCB1aW50KiwgdWludCosIGludCk7CmludAkJZmlsZXVwZGF0ZShGaWxlKiwgaW50LCBpbnQpOwoK aW50CQlmaWxlcmVhZGMoRmlsZSosIHVpbnQpOwpGaWxlCQkqZmlsZW9wZW4odm9pZCk7CnZvaWQJ CWxvZ2luc2VydChGaWxlKiwgdWludCwgUnVuZSosIHVpbnQpOwp2b2lkCQlsb2dkZWxldGUoRmls ZSosIHVpbnQsIHVpbnQpOwp2b2lkCQlsb2dzZXRuYW1lKEZpbGUqLCBTdHJpbmcqKTsKaW50CQlm aWxlaXNkaXJ0eShGaWxlKik7CmxvbmcJCXVuZG9zZXEoRmlsZSosIGludCk7CmxvbmcJCXByZXZz ZXEoQnVmZmVyKik7Cgp2b2lkCQlyYXNwbG9hZChGaWxlKik7CnZvaWQJCXJhc3BzdGFydChGaWxl Kik7CnZvaWQJCXJhc3BkZWxldGUoRmlsZSosIHVpbnQsIHVpbnQsIGludCk7CnZvaWQJCXJhc3Bp bnNlcnQoRmlsZSosIHVpbnQsIFJ1bmUqLCB1aW50LCBpbnQpOwp2b2lkCQlyYXNwZG9uZShGaWxl KiwgaW50KTsKCi8qCiAqIGFjbWUgZm5zCiAqLwp2b2lkKglmYnVmYWxsb2Modm9pZCk7CnZvaWQJ ZmJ1ZmZyZWUodm9pZCopOwp1aW50CW1pbih1aW50LCB1aW50KTsKdm9pZAljdnR0b3J1bmVzKGNo YXIqLCBpbnQsIFJ1bmUqLCBpbnQqLCBpbnQqLCBpbnQqKTsKCiNkZWZpbmUJcnVuZW1hbGxvYyhh KQkJKFJ1bmUqKWVtYWxsb2MoKGEpKnNpemVvZihSdW5lKSkKI2RlZmluZQlydW5lcmVhbGxvYyhh LCBiKQkoUnVuZSopcmVhbGxvYygoYSksIChiKSpzaXplb2YoUnVuZSkpCiNkZWZpbmUJcnVuZW1v dmUoYSwgYiwgYykJbWVtbW92ZSgoYSksIChiKSwgKGMpKnNpemVvZihSdW5lKSkKCmludAlhbG51 bShpbnQpOwppbnQJUmVhZChpbnQsIHZvaWQqLCBpbnQpOwp2b2lkCVNlZWsoaW50LCBsb25nLCBp bnQpOwppbnQJcGxhbjkoRmlsZSosIGludCwgU3RyaW5nKiwgaW50KTsKaW50CVdyaXRlKGludCwg dm9pZCosIGludCk7CmludAliZXhlY3V0ZShGaWxlKiwgUG9zbik7CnZvaWQJY2QoU3RyaW5nKik7 CnZvaWQJY2xvc2VmaWxlcyhGaWxlKiwgU3RyaW5nKik7CnZvaWQJY2xvc2VpbyhQb3NuKTsKdm9p ZAljbWRsb29wKHZvaWQpOwp2b2lkCWNtZHVwZGF0ZSh2b2lkKTsKdm9pZAljb21waWxlKFN0cmlu ZyopOwp2b2lkCWNvcHkoRmlsZSosIEFkZHJlc3MpOwpGaWxlCSpjdXJyZW50KEZpbGUqKTsKdm9p ZAlkZWxldGUoRmlsZSopOwp2b2lkCWRlbGZpbGUoRmlsZSopOwp2b2lkCWRlbGxpc3QoTGlzdCos IGludCk7CnZvaWQJZG91YmxlY2xpY2soRmlsZSosIFBvc24pOwp2b2lkCWRwcmludChjaGFyKiwg Li4uKTsKdm9pZAllZGl0KEZpbGUqLCBpbnQpOwp2b2lkCSplbWFsbG9jKHVsb25nKTsKdm9pZAkq ZXJlYWxsb2Modm9pZCosIHVsb25nKTsKdm9pZAllcnJvcihFcnIpOwp2b2lkCWVycm9yX2MoRXJy LCBpbnQpOwp2b2lkCWVycm9yX3MoRXJyLCBjaGFyKik7CmludAlleGVjdXRlKEZpbGUqLCBQb3Nu LCBQb3NuKTsKaW50CWZpbGVtYXRjaChGaWxlKiwgU3RyaW5nKik7CnZvaWQJZmlsZW5hbWUoRmls ZSopOwp2b2lkCWZpeG5hbWUoU3RyaW5nKik7CnZvaWQJZnVsbG5hbWUoU3RyaW5nKik7CnZvaWQJ Z2V0Y3Vyd2Qodm9pZCk7CkZpbGUJKmdldGZpbGUoU3RyaW5nKik7CmludAlnZXRuYW1lKEZpbGUq LCBTdHJpbmcqLCBpbnQpOwpsb25nCWdldG51bShpbnQpOwp2b2lkCWhpY2NvdWdoKGNoYXIqKTsK dm9pZAlpbnNsaXN0KExpc3QqLCBpbnQsIGxvbmcpOwpBZGRyZXNzCWxpbmVhZGRyKFBvc24sIEFk ZHJlc3MsIGludCk7CnZvaWQJbGlzdGZyZWUoTGlzdCopOwp2b2lkCWxvYWQoRmlsZSopOwpGaWxl CSpsb29rZmlsZShTdHJpbmcqKTsKdm9pZAlsb29rb3JpZ2luKEZpbGUqLCBQb3NuLCBQb3NuKTsK aW50CWxvb2t1cChpbnQpOwp2b2lkCW1vdmUoRmlsZSosIEFkZHJlc3MpOwp2b2lkCW1vdmV0byhG aWxlKiwgUmFuZ2UpOwpGaWxlCSpuZXdmaWxlKHZvaWQpOwp2b2lkCW5leHRtYXRjaChGaWxlKiwg U3RyaW5nKiwgUG9zbiwgaW50KTsKaW50CW5ld3RtcChpbnQpOwp2b2lkCW5vdGlmeWYodm9pZCos IGNoYXIqKTsKdm9pZAlwYW5pYyhjaGFyKik7CnZvaWQJcHJpbnRwb3NuKEZpbGUqLCBpbnQpOwp2 b2lkCXByaW50X3NzKGNoYXIqLCBTdHJpbmcqLCBTdHJpbmcqKTsKdm9pZAlwcmludF9zKGNoYXIq LCBTdHJpbmcqKTsKaW50CXJjdih2b2lkKTsKUmFuZ2UJcmRhdGEoTGlzdCosIFBvc24sIFBvc24p OwpQb3NuCXJlYWRpbyhGaWxlKiwgaW50KiwgaW50LCBpbnQpOwp2b2lkCXJlc2N1ZSh2b2lkKTsK dm9pZAlyZXNldGNtZCh2b2lkKTsKdm9pZAlyZXNldHN5cyh2b2lkKTsKdm9pZAlyZXNldHhlYyh2 b2lkKTsKdm9pZAlyZ3JvdyhMaXN0KiwgUG9zbiwgUG9zbik7CnZvaWQJc2FtZXJyKGNoYXIqKTsK dm9pZAlzZXR0ZW1wZmlsZSh2b2lkKTsKaW50CXNraXBibCh2b2lkKTsKdm9pZAlzbmFyZihGaWxl KiwgUG9zbiwgUG9zbiwgQnVmZmVyKiwgaW50KTsKdm9pZAlzb3J0bmFtZShGaWxlKik7CnZvaWQJ c3RhcnR1cChjaGFyKiwgaW50LCBjaGFyKiosIGNoYXIqKik7CnZvaWQJc3RhdGUoRmlsZSosIGlu dCk7CmludAlzdGF0ZmQoaW50LCB1bG9uZyosIHVsb25nKiwgbG9uZyosIGxvbmcqLCBsb25nKik7 CmludAlzdGF0ZmlsZShjaGFyKiwgdWxvbmcqLCB1bG9uZyosIGxvbmcqLCBsb25nKiwgbG9uZyop Owp2b2lkCVN0cmFkZGMoU3RyaW5nKiwgaW50KTsKdm9pZAlTdHJjbG9zZShTdHJpbmcqKTsKaW50 CVN0cmNtcChTdHJpbmcqLCBTdHJpbmcqKTsKdm9pZAlTdHJkZWxldGUoU3RyaW5nKiwgUG9zbiwg UG9zbik7CnZvaWQJU3RyZHVwbChTdHJpbmcqLCBSdW5lKik7CnZvaWQJU3RyZHVwbHN0cihTdHJp bmcqLCBTdHJpbmcqKTsKdm9pZAlTdHJpbml0KFN0cmluZyopOwp2b2lkCVN0cmluaXQwKFN0cmlu ZyopOwp2b2lkCVN0cmluc2VydChTdHJpbmcqLCBTdHJpbmcqLCBQb3NuKTsKdm9pZAlTdHJpbnN1 cmUoU3RyaW5nKiwgdWxvbmcpOwppbnQJU3RyaXNwcmUoU3RyaW5nKiwgU3RyaW5nKik7CnZvaWQJ U3RyemVybyhTdHJpbmcqKTsKaW50CVN0cmxlbihSdW5lKik7CmNoYXIJKlN0cnRvYyhTdHJpbmcq KTsKdm9pZAlzeXNlcnJvcihjaGFyKik7CnZvaWQJdGVsbGRvdChGaWxlKik7CnZvaWQJdGVsbHBh dCh2b2lkKTsKU3RyaW5nCSp0bXBjc3RyKGNoYXIqKTsKU3RyaW5nCSp0bXByc3RyKFJ1bmUqLCBp bnQpOwp2b2lkCWZyZWV0bXBzdHIoU3RyaW5nKik7CnZvaWQJdGVybWNvbW1hbmQodm9pZCk7CnZv aWQJdGVybXdyaXRlKGNoYXIqKTsKRmlsZQkqdG9maWxlKFN0cmluZyopOwp2b2lkCXRyeXRvY2xv c2UoRmlsZSopOwp2b2lkCXRyeXRvcXVpdCh2b2lkKTsKaW50CXVuZG8oaW50KTsKdm9pZAl1cGRh dGUodm9pZCk7CmludAl3YWl0Zm9yKGludCk7CnZvaWQJd2FybihXYXJuKTsKdm9pZAl3YXJuX3Mo V2FybiwgY2hhciopOwp2b2lkCXdhcm5fU1MoV2FybiwgU3RyaW5nKiwgU3RyaW5nKik7CnZvaWQJ d2Fybl9TKFdhcm4sIFN0cmluZyopOwppbnQJd2hpY2htZW51KEZpbGUqKTsKdm9pZAl3cml0ZWYo RmlsZSopOwpQb3NuCXdyaXRlaW8oRmlsZSopOwpEaXNjZGVzYyAqRHN0YXJ0KHZvaWQpOwoKZXh0 ZXJuIFJ1bmUJc2FtbmFtZVtdOwkvKiBjb21waWxlciBkZXBlbmRlbnQgKi8KZXh0ZXJuIFJ1bmUJ KmxlZnRbXTsKZXh0ZXJuIFJ1bmUJKnJpZ2h0W107CgpleHRlcm4gY2hhcglSU0FNW107CQkvKiBz eXN0ZW0gZGVwZW5kZW50ICovCmV4dGVybiBjaGFyCVNBTVRFUk1bXTsKZXh0ZXJuIGNoYXIJSE9N RVtdOwpleHRlcm4gY2hhcglUTVBESVJbXTsKZXh0ZXJuIGNoYXIJU0hbXTsKZXh0ZXJuIGNoYXIJ U0hQQVRIW107CmV4dGVybiBjaGFyCVJYW107CmV4dGVybiBjaGFyCVJYUEFUSFtdOwpleHRlcm4g Y2hhcglTQU1TQVZFQ01EW107CgovKgogKiBhY21lIGdsb2JhbHMKICovCmV4dGVybiBsb25nCQlz ZXE7CmV4dGVybiBEaXNrCQkqZGlzazsKCmV4dGVybiBjaGFyCSpyc2FtbmFtZTsJLyogZ2xvYmFs cyAqLwpleHRlcm4gY2hhcgkqc2FtdGVybTsKZXh0ZXJuIFJ1bmUJZ2VuYnVmW107CmV4dGVybiBj aGFyCSpnZW5jOwpleHRlcm4gaW50CWlvOwpleHRlcm4gaW50CXBhdHNldDsKZXh0ZXJuIGludAlx dWl0b2s7CmV4dGVybiBBZGRyZXNzCWFkZHI7CmV4dGVybiBCdWZmZXIJc25hcmZidWY7CmV4dGVy biBCdWZmZXIJcGxhbjlidWY7CmV4dGVybiBMaXN0CWZpbGU7CmV4dGVybiBMaXN0CXRlbXBmaWxl OwpleHRlcm4gRmlsZQkqY21kOwpleHRlcm4gRmlsZQkqY3VyZmlsZTsKZXh0ZXJuIEZpbGUJKmxh c3RmaWxlOwpleHRlcm4gTW9kCW1vZG51bTsKZXh0ZXJuIFBvc24JY21kcHQ7CmV4dGVybiBQb3Nu CWNtZHB0YWR2OwpleHRlcm4gUmFuZ2VzZXQJc2VsOwpleHRlcm4gU3RyaW5nCWN1cndkOwpleHRl cm4gU3RyaW5nCWNtZHN0cjsKZXh0ZXJuIFN0cmluZwlnZW5zdHI7CmV4dGVybiBTdHJpbmcJbGFz dHBhdDsKZXh0ZXJuIFN0cmluZwlsYXN0cmVnZXhwOwpleHRlcm4gU3RyaW5nCXBsYW45Y21kOwpl eHRlcm4gaW50CWRvd25sb2FkZWQ7CmV4dGVybiBpbnQJZW9mOwpleHRlcm4gaW50CWJwaXBlb2s7 CmV4dGVybiBpbnQJcGFuaWNraW5nOwpleHRlcm4gUnVuZQllbXB0eVtdOwpleHRlcm4gaW50CXRl cm1sb2NrZWQ7CmV4dGVybiBpbnQJbm9mbHVzaDsKCiNpbmNsdWRlICJtZXNnLmgiCgp2b2lkCW91 dFRzKEhtZXNnLCBpbnQpOwp2b2lkCW91dFQwKEhtZXNnKTsKdm9pZAlvdXRUbChIbWVzZywgbG9u Zyk7CnZvaWQJb3V0VHNsUyhIbWVzZywgaW50LCBsb25nLCBTdHJpbmcqKTsKdm9pZAlvdXRUUyhI bWVzZywgU3RyaW5nKik7CnZvaWQJb3V0VHNTKEhtZXNnLCBpbnQsIFN0cmluZyopOwp2b2lkCW91 dFRzbGxTKEhtZXNnLCBpbnQsIGxvbmcsIGxvbmcsIFN0cmluZyopOwp2b2lkCW91dFRzbGwoSG1l c2csIGludCwgbG9uZywgbG9uZyk7CnZvaWQJb3V0VHNsKEhtZXNnLCBpbnQsIGxvbmcpOwp2b2lk CW91dFRzdihIbWVzZywgaW50LCBsb25nKTsKdm9pZAlvdXRzdGFydChIbWVzZyk7CnZvaWQJb3V0 Y29weShpbnQsIHZvaWQqKTsKdm9pZAlvdXRzaG9ydChpbnQpOwp2b2lkCW91dGxvbmcobG9uZyk7 CnZvaWQJb3V0dmxvbmcodm9pZCopOwp2b2lkCW91dHNlbmQodm9pZCk7CnZvaWQJb3V0Zmx1c2go dm9pZCk7CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAc2FtMmsvc2FtL3NoZWxsLmMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2 NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDA2MTMxADA3MTExNjIyMTA1ADAwMTUwMDcAMAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAw MDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAjaW5jbHVkZSAic2FtLmgiCiNpbmNsdWRlICJwYXJzZS5oIgoKZXh0ZXJuCWptcF9i dWYJbWFpbmxvb3A7CgpjaGFyCWVycmZpbGVbNjRdOwpTdHJpbmcJcGxhbjljbWQ7CS8qIG51bGwg dGVybWluYXRlZCAqLwpCdWZmZXIJcGxhbjlidWY7CnZvaWQJY2hlY2tlcnJzKHZvaWQpOwoKaW50 CnBsYW45KEZpbGUgKmYsIGludCB0eXBlLCBTdHJpbmcgKnMsIGludCBuZXN0KQp7Cglsb25nIGw7 CglpbnQgbTsKCWludCBwaWQsIGZkOwoJaW50IHJldGNvZGU7CglpbnQgcGlwZTFbMl0sIHBpcGUy WzJdOwoKCWlmKHMtPnNbMF09PTAgJiYgcGxhbjljbWQuc1swXT09MCkKCQllcnJvcihFbm9jbWQp OwoJZWxzZSBpZihzLT5zWzBdKQoJCVN0cmR1cGxzdHIoJnBsYW45Y21kLCBzKTsKCWlmKGRvd25s b2FkZWQpCgkJc2FtZXJyKGVycmZpbGUpOwoJZWxzZQoJCXN0cmNweShlcnJmaWxlLCAiL2Rldi90 dHkiKTsKCWlmKHR5cGUhPSchJyAmJiBwaXBlKHBpcGUxKT09LTEpCgkJZXJyb3IoRXBpcGUpOwoJ aWYodHlwZT09J3wnKQoJCXNuYXJmKGYsIGFkZHIuci5wMSwgYWRkci5yLnAyLCAmcGxhbjlidWYs IDEpOwoJaWYoZG93bmxvYWRlZCkKCQlyZW1vdmUoZXJyZmlsZSk7CglpZigocGlkPWZvcmsoKSkg PT0gMCl7CgkJaWYoZG93bmxvYWRlZCl7CS8qIGFsc28gcHV0IG5hc3R5IGZkJ3MgaW50byBlcnJm aWxlICovCgkJCWZkID0gY3JlYXRlKGVycmZpbGUsIDEsIDA2NjZMKTsKCQkJaWYoZmQgPCAwKQoJ CQkJZmQgPSBjcmVhdGUoIi9kZXYvbnVsbCIsIDEsIDA2NjZMKTsKCQkJZHVwKGZkLCAyKTsKCQkJ Y2xvc2UoZmQpOwoJCQkvKiAyIG5vdyBwb2ludHMgYXQgZXJyIGZpbGUgKi8KCQkJaWYodHlwZSA9 PSAnPicpCgkJCQlkdXAoMiwgMSk7CgkJCWVsc2UgaWYodHlwZT09JyEnKXsKCQkJCWR1cCgyLCAx KTsKCQkJCWZkID0gb3BlbigiL2Rldi9udWxsIiwgMCk7CgkJCQlkdXAoZmQsIDApOwoJCQkJY2xv c2UoZmQpOwoJCQl9CgkJfQoJCWlmKHR5cGUgIT0gJyEnKSB7CgkJCWlmKHR5cGU9PSc8JyB8fCB0 eXBlPT0nfCcpCgkJCQlkdXAocGlwZTFbMV0sIDEpOwoJCQllbHNlIGlmKHR5cGUgPT0gJz4nKQoJ CQkJZHVwKHBpcGUxWzBdLCAwKTsKCQkJY2xvc2UocGlwZTFbMF0pOwoJCQljbG9zZShwaXBlMVsx XSk7CgkJfQoJCWlmKHR5cGUgPT0gJ3wnKXsKCQkJaWYocGlwZShwaXBlMikgPT0gLTEpCgkJCQll eGl0cygicGlwZSIpOwoJCQlpZigocGlkID0gZm9yaygpKT09MCl7CgkJCQkvKgoJCQkJICogSXQn cyBvayBpZiB3ZSBnZXQgU0lHUElQRSBoZXJlCgkJCQkgKi8KCQkJCWNsb3NlKHBpcGUyWzBdKTsK CQkJCWlvID0gcGlwZTJbMV07CgkJCQlpZihyZXRjb2RlPSFzZXRqbXAobWFpbmxvb3ApKXsJLyog YXNzaWdubWVudCA9ICovCgkJCQkJY2hhciAqYzsKCQkJCQlmb3IobCA9IDA7IGw8cGxhbjlidWYu bmM7IGwrPW0pewoJCQkJCQltID0gcGxhbjlidWYubmMtbDsKCQkJCQkJaWYobT5CTE9DS1NJWkUt MSkKCQkJCQkJCW0gPSBCTE9DS1NJWkUtMTsKCQkJCQkJYnVmcmVhZCgmcGxhbjlidWYsIGwsIGdl bmJ1ZiwgbSk7CgkJCQkJCWdlbmJ1ZlttXSA9IDA7CgkJCQkJCWMgPSBTdHJ0b2ModG1wcnN0cihn ZW5idWYsIG0rMSkpOwoJCQkJCQlXcml0ZShwaXBlMlsxXSwgYywgc3RybGVuKGMpKTsKCQkJCQkJ ZnJlZShjKTsKCQkJCQl9CgkJCQl9CgkJCQlleGl0cyhyZXRjb2RlPyAiZXJyb3IiIDogMCk7CgkJ CX0KCQkJaWYocGlkPT0tMSl7CgkJCQlmcHJpbnQoMiwgIkNhbid0IGZvcms/IVxuIik7CgkJCQll eGl0cygiZm9yayIpOwoJCQl9CgkJCWR1cChwaXBlMlswXSwgMCk7CgkJCWNsb3NlKHBpcGUyWzBd KTsKCQkJY2xvc2UocGlwZTJbMV0pOwoJCX0KCQlpZih0eXBlPT0nPCcpewoJCQljbG9zZSgwKTsJ Lyogc28gaXQgd29uJ3QgcmVhZCBmcm9tIHRlcm1pbmFsICovCgkJCW9wZW4oIi9kZXYvbnVsbCIs IDApOwoJCX0KCQlleGVjbChTSFBBVEgsIFNILCAiLWMiLCBTdHJ0b2MoJnBsYW45Y21kKSwgKGNo YXIgKikwKTsKCQlleGl0cygiZXhlYyIpOwoJfQoJaWYocGlkID09IC0xKQoJCWVycm9yKEVmb3Jr KTsKCWlmKHR5cGU9PSc8JyB8fCB0eXBlPT0nfCcpewoJCWludCBudWxsczsKCQlpZihkb3dubG9h ZGVkICYmIGFkZHIuci5wMSAhPSBhZGRyLnIucDIpCgkJCW91dFRsKEhzbmFyZmxlbiwgYWRkci5y LnAyLWFkZHIuci5wMSk7CgkJc25hcmYoZiwgYWRkci5yLnAxLCBhZGRyLnIucDIsICZzbmFyZmJ1 ZiwgMCk7CgkJbG9nZGVsZXRlKGYsIGFkZHIuci5wMSwgYWRkci5yLnAyKTsKCQljbG9zZShwaXBl MVsxXSk7CgkJaW8gPSBwaXBlMVswXTsKCQlmLT50ZG90LnAxID0gLTE7CgkJZi0+bmRvdC5yLnAy ID0gYWRkci5yLnAyK3JlYWRpbyhmLCAmbnVsbHMsIDAsIEZBTFNFKTsKCQlmLT5uZG90LnIucDEg PSBhZGRyLnIucDI7CgkJY2xvc2VpbygoUG9zbiktMSk7Cgl9ZWxzZSBpZih0eXBlPT0nPicpewoJ CWNsb3NlKHBpcGUxWzBdKTsKCQlpbyA9IHBpcGUxWzFdOwoJCWJwaXBlb2sgPSAxOwoJCXdyaXRl aW8oZik7CgkJYnBpcGVvayA9IDA7CgkJY2xvc2VpbygoUG9zbiktMSk7Cgl9CglyZXRjb2RlID0g d2FpdGZvcihwaWQpOwoJaWYodHlwZT09J3wnIHx8IHR5cGU9PSc8JykKCQlpZihyZXRjb2RlIT0w KQoJCQl3YXJuKFdiYWRzdGF0dXMpOwoJaWYoZG93bmxvYWRlZCkKCQljaGVja2VycnMoKTsKCWlm KCFuZXN0KQoJCWRwcmludCgiIVxuIik7CglyZXR1cm4gcmV0Y29kZTsKfQoKdm9pZApjaGVja2Vy cnModm9pZCkKewoJY2hhciBidWZbMjU2XTsKCWludCBmLCBuLCBubDsKCWNoYXIgKnA7Cglsb25n IGw7CgoJaWYoc3RhdGZpbGUoZXJyZmlsZSwgMCwgMCwgMCwgJmwsIDApID4gMCAmJiBsICE9IDAp ewoJCWlmKChmPW9wZW4oKGNoYXIgKillcnJmaWxlLCAwKSkgIT0gLTEpewoJCQlpZigobj1yZWFk KGYsIGJ1Ziwgc2l6ZW9mIGJ1Zi0xKSkgPiAwKXsKCQkJCWZvcihubD0wLHA9YnVmOyBubDwzICYm IHA8JmJ1ZltuXTsgcCsrKQoJCQkJCWlmKCpwPT0nXG4nKQoJCQkJCQlubCsrOwoJCQkJKnAgPSAw OwoJCQkJZHByaW50KCIlcyIsIGJ1Zik7CgkJCQlpZihwLWJ1ZiA8IGwtMSkKCQkJCQlkcHJpbnQo IihzYW06IG1vcmUgaW4gJXMpXG4iLCBlcnJmaWxlKTsKCQkJfQoJCQljbG9zZShmKTsKCQl9Cgl9 ZWxzZQoJCXJlbW92ZSgoY2hhciAqKWVycmZpbGUpOwp9CmxhbjljbWQ7CS8qIG51bGwgdGVybWlu YXRlZCAqLwpCdWZmZXIJcGxhbjlidWY7CnZvaWQJY2hlY2tlcnJzKHZvaWQpOwoKaW50CnBsYW45 KEZpbGUgKmYsIGludCB0eXBlLCBTdHJpbmcgKnMsIGludCBuZXN0KQp7Cglsb25nIGw7CglpbnQg bTsKCWludCBwaWQsIGZkOwoJaW50IHJldGNvZGU7CglpbnQgcGlwZTFbMl0sIHBpcGUyWzJdOwoK CWlmKHMtPnNbMF09PTAgJiYgcGxhbjljbWQuc1swXT09MCkKCQllcnJvcihFbm9jbWQpOwoJZWxz ZSBpZihzLT5zWzBdKQoJCVN0cmR1cGxzdHIoJnBsYW45Y21kLCBzKTsKCWlmKGRvd25sb2FkZWQp CgkJc2FtZXJyKGVycmZpbGUpOwoJZWxzZQoJCXN0cmNweShlcnJmaWxlLCAiL2Rldi90dHkiKTsK CWlmKHR5cGUhPSchJyAmJiBwaXBlKHBpcGUxKT09LTEpCgkJZXJyb3IoRXBpcGUpOwoJaWYodHlw ZXNhbTJrL3NhbS9zdHJpbmcuYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDE3 MzcAMDAwMDE1MQAwMDAwMDAwNTMxNgAwNzExMTYyMjEwNQAwMDE1MjEyADAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzY2h3YXJ0egAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGdjc2UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDA0MAAwMDAw MDI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA I2luY2x1ZGUgInNhbS5oIgoKI2RlZmluZQlNSU5TSVpFCTE2CQkvKiBtaW5pbXVtIG51bWJlciBv ZiBjaGFycyBhbGxvY2F0ZWQgKi8KI2RlZmluZQlNQVhTSVpFCTI1NgkJLyogbWF4aW11bSBudW1i ZXIgb2YgY2hhcnMgZm9yIGFuIGVtcHR5IHN0cmluZyAqLwoKCnZvaWQKU3RyaW5pdChTdHJpbmcg KnApCnsKCXAtPnMgPSBlbWFsbG9jKE1JTlNJWkUqUlVORVNJWkUpOwoJcC0+biA9IDA7CglwLT5z aXplID0gTUlOU0laRTsKfQoKdm9pZApTdHJpbml0MChTdHJpbmcgKnApCnsKCXAtPnMgPSBlbWFs bG9jKE1JTlNJWkUqUlVORVNJWkUpOwoJcC0+c1swXSA9IDA7CglwLT5uID0gMTsKCXAtPnNpemUg PSBNSU5TSVpFOwp9Cgp2b2lkClN0cmNsb3NlKFN0cmluZyAqcCkKewoJZnJlZShwLT5zKTsKfQoK dm9pZApTdHJ6ZXJvKFN0cmluZyAqcCkKewoJaWYocC0+c2l6ZSA+IE1BWFNJWkUpewoJCXAtPnMg PSBlcmVhbGxvYyhwLT5zLCBSVU5FU0laRSpNQVhTSVpFKTsgLyogdGhyb3cgYXdheSB0aGUgZ2Fy YmFnZSAqLwoJCXAtPnNpemUgPSBNQVhTSVpFOwoJfQoJcC0+biA9IDA7Cn0KCmludApTdHJsZW4o UnVuZSAqcikKewoJUnVuZSAqczsKCglmb3Iocz1yOyAqczsgcysrKQoJCTsKCXJldHVybiBzLXI7 Cn0KCnZvaWQKU3RyZHVwbChTdHJpbmcgKnAsIFJ1bmUgKnMpCS8qIGNvcGllcyB0aGUgbnVsbCAq Lwp7CglwLT5uID0gU3RybGVuKHMpKzE7CglTdHJpbnN1cmUocCwgcC0+bik7CgltZW1tb3ZlKHAt PnMsIHMsIHAtPm4qUlVORVNJWkUpOwp9Cgp2b2lkClN0cmR1cGxzdHIoU3RyaW5nICpwLCBTdHJp bmcgKnEpCS8qIHdpbGwgY29weSB0aGUgbnVsbCBpZiB0aGVyZSdzIG9uZSB0aGVyZSAqLwp7CglT dHJpbnN1cmUocCwgcS0+bik7CglwLT5uID0gcS0+bjsKCW1lbW1vdmUocC0+cywgcS0+cywgcS0+ bipSVU5FU0laRSk7Cn0KCnZvaWQKU3RyYWRkYyhTdHJpbmcgKnAsIGludCBjKQp7CglTdHJpbnN1 cmUocCwgcC0+bisxKTsKCXAtPnNbcC0+bisrXSA9IGM7Cn0KCnZvaWQKU3RyaW5zdXJlKFN0cmlu ZyAqcCwgdWxvbmcgbikKewoJaWYobiA+IFNUUlNJWkUpCgkJZXJyb3IoRXRvb2xvbmcpOwoJaWYo cC0+c2l6ZSA8IG4pewkvKiBwIG5lZWRzIHRvIGdyb3cgKi8KCQluICs9IDEwMDsKCQlwLT5zID0g ZXJlYWxsb2MocC0+cywgbipSVU5FU0laRSk7CgkJcC0+c2l6ZSA9IG47Cgl9Cn0KCnZvaWQKU3Ry aW5zZXJ0KFN0cmluZyAqcCwgU3RyaW5nICpxLCBQb3NuIHAwKQp7CglTdHJpbnN1cmUocCwgcC0+ bitxLT5uKTsKCW1lbW1vdmUocC0+cytwMCtxLT5uLCBwLT5zK3AwLCAocC0+bi1wMCkqUlVORVNJ WkUpOwoJbWVtbW92ZShwLT5zK3AwLCBxLT5zLCBxLT5uKlJVTkVTSVpFKTsKCXAtPm4gKz0gcS0+ bjsKfQoKdm9pZApTdHJkZWxldGUoU3RyaW5nICpwLCBQb3NuIHAxLCBQb3NuIHAyKQp7CgltZW1t b3ZlKHAtPnMrcDEsIHAtPnMrcDIsIChwLT5uLXAyKSpSVU5FU0laRSk7CglwLT5uIC09IHAyLXAx Owp9CgppbnQKU3RyY21wKFN0cmluZyAqYSwgU3RyaW5nICpiKQp7CglpbnQgaSwgYzsKCglmb3Io aT0wOyBpPGEtPm4gJiYgaTxiLT5uOyBpKyspCgkJaWYoYyA9IChhLT5zW2ldIC0gYi0+c1tpXSkp CS8qIGFzc2lnbiA9ICovCgkJCXJldHVybiBjOwoJLyogZGFtbiBOVUxzIGNvbmZ1c2UgZXZlcnl0 aGluZyAqLwoJaSA9IGEtPm4gLSBiLT5uOwoJaWYoaSA9PSAxKXsKCQlpZihhLT5zW2EtPm4tMV0g PT0gMCkKCQkJcmV0dXJuIDA7Cgl9ZWxzZSBpZihpID09IC0xKXsKCQlpZihiLT5zW2ItPm4tMV0g PT0gMCkKCQkJcmV0dXJuIDA7Cgl9CglyZXR1cm4gaTsKfQoKaW50ClN0cmlzcHJlKFN0cmluZyAq YSwgU3RyaW5nICpiKQp7CglpbnQgaTsKCglmb3IoaT0wOyBpPGEtPm4gJiYgaTxiLT5uOyBpKysp ewoJCWlmKGEtPnNbaV0gLSBiLT5zW2ldKXsJLyogYXNzaWduID0gKi8KCQkJaWYoYS0+c1tpXSA9 PSAwKQoJCQkJcmV0dXJuIDE7CgkJCXJldHVybiAwOwoJCX0KCX0KCXJldHVybiBpID09IGEtPm47 Cn0KCmNoYXIqClN0cnRvYyhTdHJpbmcgKnMpCnsKCWludCBpOwoJY2hhciAqYywgKmQ7CglSdW5l ICpyOwoJYyA9IGVtYWxsb2Mocy0+bipVVEZtYXggKyAxKTsgIC8qIHdvcnN0IGNhc2UgVVRGbWF4 IGJ5dGVzIHBlciBydW5lLCBwbHVzIE5VTCAqLwoJZCA9IGM7CglyID0gcy0+czsKCWZvcihpPTA7 IGk8cy0+bjsgaSsrKQoJCWQgKz0gcnVuZXRvY2hhcihkLCByKyspOwoJaWYoZD09YyB8fCBkWy0x XSE9MCkKCQkqZCA9IDA7CglyZXR1cm4gYzsKCn0KCi8qCiAqIEJ1aWxkIHZlcnkgdGVtcG9yYXJ5 IFN0cmluZyBmcm9tIFJ1bmUqCiAqLwpTdHJpbmcqCnRtcHJzdHIoUnVuZSAqciwgaW50IG4pCnsK CXN0YXRpYyBTdHJpbmcgcDsKCglwLnMgPSByOwoJcC5uID0gbjsKCXAuc2l6ZSA9IG47CglyZXR1 cm4gJnA7Cn0KCi8qCiAqIENvbnZlcnQgbnVsbC10ZXJtaW5hdGVkIGNoYXIqIGludG8gU3RyaW5n CiAqLwpTdHJpbmcqCnRtcGNzdHIoY2hhciAqcykKewoJU3RyaW5nICpwOwoJUnVuZSAqcjsKCWlu dCBpLCBuOwoKCW4gPSB1dGZsZW4ocyk7CS8qIGRvbid0IGluY2x1ZGUgTlVMICovCglwID0gZW1h bGxvYyhzaXplb2YoU3RyaW5nKSk7CglyID0gZW1hbGxvYyhuKlJVTkVTSVpFKTsKCXAtPnMgPSBy OwoJZm9yKGk9MDsgaTxuOyBpKysscisrKQoJCXMgKz0gY2hhcnRvcnVuZShyLCBzKTsKCXAtPm4g PSBuOwoJcC0+c2l6ZSA9IG47CglyZXR1cm4gcDsKfQoKdm9pZApmcmVldG1wc3RyKFN0cmluZyAq cykKewoJZnJlZShzLT5zKTsKCWZyZWUocyk7Cn0KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsv c2FtL3N5cy5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAw MTUxADAwMDAwMDAxMzIxADA3MTExNjIyMTA1ADAwMTQ1MTIAMAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVk ZSAic2FtLmgiCgpzdGF0aWMgaW50IGluZXJyb3I9RkFMU0U7CgovKgogKiBBIHJlYXNvbmFibGUg aW50ZXJmYWNlIHRvIHRoZSBzeXN0ZW0gY2FsbHMKICovCgp2b2lkCnJlc2V0c3lzKHZvaWQpCnsK CWluZXJyb3IgPSBGQUxTRTsKfQoKdm9pZApzeXNlcnJvcihjaGFyICphKQp7CgljaGFyIGJ1ZltF UlJMRU5dOwoKCWlmKCFpbmVycm9yKXsKCQlpbmVycm9yPVRSVUU7CgkJZXJyc3RyKGJ1Zik7CgkJ ZHByaW50KCIlczogIiwgYSk7CgkJZXJyb3JfcyhFaW8sIGJ1Zik7Cgl9Cn0KCmludApSZWFkKGlu dCBmLCB2b2lkICphLCBpbnQgbikKewoJY2hhciBidWZbRVJSTEVOXTsKCglpZihyZWFkKGYsIChj aGFyICopYSwgbikhPW4pIHsKCQlpZiAobGFzdGZpbGUpCgkJCWxhc3RmaWxlLT5yZXNjdWluZyA9 IDE7CgkJZXJyc3RyKGJ1Zik7CgkJaWYgKGRvd25sb2FkZWQpCgkJCWZwcmludCgyLCAicmVhZCBl cnJvcjogJXNcbiIsIGJ1Zik7CgkJcmVzY3VlKCk7CgkJZXhpdHMoInJlYWQiKTsKCX0KCXJldHVy biBuOwp9CgppbnQKV3JpdGUoaW50IGYsIHZvaWQgKmEsIGludCBuKQp7CglpbnQgbTsKCglpZigo bT13cml0ZShmLCAoY2hhciAqKWEsIG4pKSE9bikKCQlzeXNlcnJvcigid3JpdGUiKTsKCXJldHVy biBtOwp9Cgp2b2lkClNlZWsoaW50IGYsIGxvbmcgbiwgaW50IHcpCnsKCWlmKHNlZWsoZiwgbiwg dyk9PS0xKQoJCXN5c2Vycm9yKCJzZWVrIik7Cn0KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2Ft L3V0aWwuYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUx ADAwMDAwMDAxMzc2ADA3MTExNjIyMTA1ADAwMTQ2NjMAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAZ2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSAi c2FtLmgiCgp2b2lkCmN2dHRvcnVuZXMoY2hhciAqcCwgaW50IG4sIFJ1bmUgKnIsIGludCAqbmIs IGludCAqbnIsIGludCAqbnVsbHMpCnsKCXVjaGFyICpxOwoJUnVuZSAqczsKCWludCBqLCB3OwoK CS8qCgkgKiBBbHdheXMgZ3VhcmFudGVlZCB0aGF0IG4gYnl0ZXMgbWF5IGJlIGludGVycHJldGVk CgkgKiB3aXRob3V0IHdvcnJ5aW5nIGFib3V0IHBhcnRpYWwgcnVuZXMuICBUaGlzIG1heSBtZWFu CgkgKiByZWFkaW5nIHVwIHRvIFVURm1heC0xIG1vcmUgYnl0ZXMgdGhhbiBuOyB0aGUgY2FsbGVy CgkgKiBrbm93cyB0aGlzLiAgSWYgbiBpcyBhIGZpcm0gbGltaXQsIHRoZSBjYWxsZXIgc2hvdWxk CgkgKiBzZXQgcFtuXSA9IDAuCgkgKi8KCXEgPSAodWNoYXIqKXA7CglzID0gcjsKCWZvcihqPTA7 IGo8bjsgais9dyl7CgkJaWYoKnEgPCBSdW5lc2VsZil7CgkJCXcgPSAxOwoJCQkqcyA9ICpxKys7 CgkJfWVsc2V7CgkJCXcgPSBjaGFydG9ydW5lKHMsIChjaGFyKilxKTsKCQkJcSArPSB3OwoJCX0K CQlpZigqcykKCQkJcysrOwoJCWVsc2UgaWYobnVsbHMpCgkJCSpudWxscyA9IFRSVUU7Cgl9Cgkq bmIgPSAoY2hhciopcS1wOwoJKm5yID0gcy1yOwp9Cgp2b2lkKgpmYnVmYWxsb2Modm9pZCkKewoJ cmV0dXJuIGVtYWxsb2MoQlVGU0laRSk7Cn0KCnZvaWQKZmJ1ZmZyZWUodm9pZCAqZikKewoJZnJl ZShmKTsKfQoKdWludAptaW4odWludCBhLCB1aW50IGIpCnsKCWlmKGEgPCBiKQoJCXJldHVybiBh OwoJcmV0dXJuIGI7Cn0KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2FtL3hl Yy5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAw MDAwMDIwNDI2ADA3MTExNjQzMjYyADAwMTQ0NzEAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Z2NzZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSAic2Ft LmgiCiNpbmNsdWRlICJwYXJzZS5oIgoKaW50CUdsb29waW5nOwppbnQJbmVzdDsKCmludAlhcHBl bmQoRmlsZSosIENtZCosIFBvc24pOwppbnQJZGlzcGxheShGaWxlKik7CnZvaWQJbG9vcGVyKEZp bGUqLCBDbWQqLCBpbnQpOwp2b2lkCWZpbGVsb29wZXIoQ21kKiwgaW50KTsKdm9pZAlsaW5lbG9v cGVyKEZpbGUqLCBDbWQqKTsKCnZvaWQKcmVzZXR4ZWModm9pZCkKewoJR2xvb3BpbmcgPSBuZXN0 ID0gMDsKfQoKaW50CmNtZGV4ZWMoRmlsZSAqZiwgQ21kICpjcCkKewoJaW50IGk7CglBZGRyICph cDsKCUFkZHJlc3MgYTsKCglpZihmICYmIGYtPnVucmVhZCkKCQlsb2FkKGYpOwoJaWYoZj09MCAm JiAoY3AtPmFkZHI9PTAgfHwgY3AtPmFkZHItPnR5cGUhPSciJykgJiYKCSAgICAhdXRmcnVuZSgi YkJucVVYWSEiLCBjcC0+Y21kYykgJiYKCSAgICBjcC0+Y21kYyE9KCdjJ3wweDEwMCkgJiYgIShj cC0+Y21kYz09J0QnICYmIGNwLT5jdGV4dCkpCgkJZXJyb3IoRW5vZmlsZSk7CglpID0gbG9va3Vw KGNwLT5jbWRjKTsKCWlmKGkgPj0gMCAmJiBjbWR0YWJbaV0uZGVmYWRkciAhPSBhTm8pewoJCWlm KChhcD1jcC0+YWRkcik9PTAgJiYgY3AtPmNtZGMhPSdcbicpewoJCQljcC0+YWRkciA9IGFwID0g bmV3YWRkcigpOwoJCQlhcC0+dHlwZSA9ICcuJzsKCQkJaWYoY21kdGFiW2ldLmRlZmFkZHIgPT0g YUFsbCkKCQkJCWFwLT50eXBlID0gJyonOwoJCX1lbHNlIGlmKGFwICYmIGFwLT50eXBlPT0nIicg JiYgYXAtPm5leHQ9PTAgJiYgY3AtPmNtZGMhPSdcbicpewoJCQlhcC0+bmV4dCA9IG5ld2FkZHIo KTsKCQkJYXAtPm5leHQtPnR5cGUgPSAnLic7CgkJCWlmKGNtZHRhYltpXS5kZWZhZGRyID09IGFB bGwpCgkJCQlhcC0+bmV4dC0+dHlwZSA9ICcqJzsKCQl9CgkJaWYoY3AtPmFkZHIpewkvKiBtYXkg YmUgZmFsc2UgZm9yICdcbicgKG9ubHkpICovCgkJCXN0YXRpYyBBZGRyZXNzIG5vbmUgPSB7ezAs MH0sMH07CgkJCWlmKGYpCgkJCQlhZGRyID0gYWRkcmVzcyhhcCwgZi0+ZG90LCAwKTsKCQkJZWxz ZQkvKiBhICIgKi8KCQkJCWFkZHIgPSBhZGRyZXNzKGFwLCBub25lLCAwKTsKCQkJZiA9IGFkZHIu ZjsKCQl9Cgl9CgljdXJyZW50KGYpOwoJc3dpdGNoKGNwLT5jbWRjKXsKCWNhc2UgJ3snOgoJCWEg PSBjcC0+YWRkcj8gYWRkcmVzcyhjcC0+YWRkciwgZi0+ZG90LCAwKTogZi0+ZG90OwoJCWZvcihj cCA9IGNwLT5jY21kOyBjcDsgY3AgPSBjcC0+bmV4dCl7CgkJCWEuZi0+ZG90ID0gYTsKCQkJY21k ZXhlYyhhLmYsIGNwKTsKCQl9CgkJYnJlYWs7CglkZWZhdWx0OgoJCWk9KCpjbWR0YWJbaV0uZm4p KGYsIGNwKTsKCQlyZXR1cm4gaTsKCX0KCXJldHVybiAxOwp9CgoKaW50CmFfY21kKEZpbGUgKmYs IENtZCAqY3ApCnsKCXJldHVybiBhcHBlbmQoZiwgY3AsIGFkZHIuci5wMik7Cn0KCmludApiX2Nt ZChGaWxlICpmLCBDbWQgKmNwKQp7CglVU0VEKGYpOwoJZiA9IGNwLT5jbWRjPT0nYic/IHRvZmls ZShjcC0+Y3RleHQpIDogZ2V0ZmlsZShjcC0+Y3RleHQpOwoJaWYoZi0+dW5yZWFkKQoJCWxvYWQo Zik7CgllbHNlIGlmKG5lc3QgPT0gMCkKCQlmaWxlbmFtZShmKTsKCXJldHVybiBUUlVFOwp9Cgpp bnQKY19jbWQoRmlsZSAqZiwgQ21kICpjcCkKewoJbG9nZGVsZXRlKGYsIGFkZHIuci5wMSwgYWRk ci5yLnAyKTsKCWYtPm5kb3Quci5wMSA9IGYtPm5kb3Quci5wMiA9IGFkZHIuci5wMjsKCXJldHVy biBhcHBlbmQoZiwgY3AsIGFkZHIuci5wMik7Cn0KCmludApkX2NtZChGaWxlICpmLCBDbWQgKmNw KQp7CglVU0VEKGNwKTsKCWxvZ2RlbGV0ZShmLCBhZGRyLnIucDEsIGFkZHIuci5wMik7CglmLT5u ZG90LnIucDEgPSBmLT5uZG90LnIucDIgPSBhZGRyLnIucDE7CglyZXR1cm4gVFJVRTsKfQoKaW50 CkRfY21kKEZpbGUgKmYsIENtZCAqY3ApCnsKCWNsb3NlZmlsZXMoZiwgY3AtPmN0ZXh0KTsKCXJl dHVybiBUUlVFOwp9CgppbnQKZV9jbWQoRmlsZSAqZiwgQ21kICpjcCkKewoJaWYoZ2V0bmFtZShm LCBjcC0+Y3RleHQsIGNwLT5jbWRjPT0nZScpPT0wKQoJCWVycm9yKEVub25hbWUpOwoJZWRpdChm LCBjcC0+Y21kYyk7CglyZXR1cm4gVFJVRTsKfQoKaW50CmZfY21kKEZpbGUgKmYsIENtZCAqY3Ap CnsKCWdldG5hbWUoZiwgY3AtPmN0ZXh0LCBUUlVFKTsKCWZpbGVuYW1lKGYpOwoJcmV0dXJuIFRS VUU7Cn0KCmludApnX2NtZChGaWxlICpmLCBDbWQgKmNwKQp7CglpZihmIT1hZGRyLmYpcGFuaWMo ImdfY21kIGYhPWFkZHIuZiIpOwoJY29tcGlsZShjcC0+cmUpOwoJaWYoZXhlY3V0ZShmLCBhZGRy LnIucDEsIGFkZHIuci5wMikgXiBjcC0+Y21kYz09J3YnKXsKCQlmLT5kb3QgPSBhZGRyOwoJCXJl dHVybiBjbWRleGVjKGYsIGNwLT5jY21kKTsKCX0KCXJldHVybiBUUlVFOwp9CgppbnQKaV9jbWQo RmlsZSAqZiwgQ21kICpjcCkKewoJcmV0dXJuIGFwcGVuZChmLCBjcCwgYWRkci5yLnAxKTsKfQoK aW50CmtfY21kKEZpbGUgKmYsIENtZCAqY3ApCnsKCVVTRUQoY3ApOwoJZi0+bWFyayA9IGFkZHIu cjsKCXJldHVybiBUUlVFOwp9CgppbnQKbV9jbWQoRmlsZSAqZiwgQ21kICpjcCkKewoJQWRkcmVz cyBhZGRyMjsKCglhZGRyMiA9IGFkZHJlc3MoY3AtPmNhZGRyLCBmLT5kb3QsIDApOwoJaWYoY3At PmNtZGM9PSdtJykKCQltb3ZlKGYsIGFkZHIyKTsKCWVsc2UKCQljb3B5KGYsIGFkZHIyKTsKCXJl dHVybiBUUlVFOwp9CgppbnQKbl9jbWQoRmlsZSAqZiwgQ21kICpjcCkKewoJaW50IGk7CglVU0VE KGYpOwoJVVNFRChjcCk7Cglmb3IoaSA9IDA7IGk8ZmlsZS5udXNlZDsgaSsrKXsKCQlpZihmaWxl LmZpbGVwcHRyW2ldID09IGNtZCkKCQkJY29udGludWU7CgkJZiA9IGZpbGUuZmlsZXBwdHJbaV07 CgkJU3RyZHVwbHN0cigmZ2Vuc3RyLCAmZi0+bmFtZSk7CgkJZmlsZW5hbWUoZik7Cgl9CglyZXR1 cm4gVFJVRTsKfQoKaW50CnBfY21kKEZpbGUgKmYsIENtZCAqY3ApCnsKCVVTRUQoY3ApOwoJcmV0 dXJuIGRpc3BsYXkoZik7Cn0KCmludApxX2NtZChGaWxlICpmLCBDbWQgKmNwKQp7CglVU0VEKGNw KTsKCVVTRUQoZik7Cgl0cnl0b3F1aXQoKTsKCWlmKGRvd25sb2FkZWQpewoJCW91dFQwKEhleGl0 KTsKCQlyZXR1cm4gVFJVRTsKCX0KCXJldHVybiBGQUxTRTsKfQoKaW50CnNfY21kKEZpbGUgKmYs IENtZCAqY3ApCnsKCWludCBpLCBqLCBjLCBuOwoJUG9zbiBwMSwgb3AsIGRpZHN1YiA9IDAsIGRl bHRhID0gMDsKCgluID0gY3AtPm51bTsKCW9wPSAtMTsKCWNvbXBpbGUoY3AtPnJlKTsKCWZvcihw MSA9IGFkZHIuci5wMTsgcDE8PWFkZHIuci5wMiAmJiBleGVjdXRlKGYsIHAxLCBhZGRyLnIucDIp OyApewoJCWlmKHNlbC5wWzBdLnAxPT1zZWwucFswXS5wMil7CS8qIGVtcHR5IG1hdGNoPyAqLwoJ CQlpZihzZWwucFswXS5wMT09b3ApewoJCQkJcDErKzsKCQkJCWNvbnRpbnVlOwoJCQl9CgkJCXAx ID0gc2VsLnBbMF0ucDIrMTsKCQl9ZWxzZQoJCQlwMSA9IHNlbC5wWzBdLnAyOwoJCW9wID0gc2Vs LnBbMF0ucDI7CgkJaWYoLS1uPjApCgkJCWNvbnRpbnVlOwoJCVN0cnplcm8oJmdlbnN0cik7CgkJ Zm9yKGkgPSAwOyBpPGNwLT5jdGV4dC0+bjsgaSsrKQoJCQlpZigoYyA9IGNwLT5jdGV4dC0+c1tp XSk9PSdcXCcgJiYgaTxjcC0+Y3RleHQtPm4tMSl7CgkJCQljID0gY3AtPmN0ZXh0LT5zWysraV07 CgkJCQlpZignMSc8PWMgJiYgYzw9JzknKSB7CgkJCQkJaiA9IGMtJzAnOwoJCQkJCWlmKHNlbC5w W2pdLnAyLXNlbC5wW2pdLnAxPkJMT0NLU0laRSkKCQkJCQkJZXJyb3IoRWxvbmd0YWcpOwoJCQkJ CWJ1ZnJlYWQoJmYtPlUsIHNlbC5wW2pdLnAxLCBnZW5idWYsIHNlbC5wW2pdLnAyLXNlbC5wW2pd LnAxKTsKCQkJCQlTdHJpbnNlcnQoJmdlbnN0ciwgdG1wcnN0cihnZW5idWYsIChzZWwucFtqXS5w Mi1zZWwucFtqXS5wMSkpLCBnZW5zdHIubik7CgkJCQl9ZWxzZQoJCQkJIAlTdHJhZGRjKCZnZW5z dHIsIGMpOwoJCQl9ZWxzZSBpZihjIT0nJicpCgkJCQlTdHJhZGRjKCZnZW5zdHIsIGMpOwoJCQll bHNlewoJCQkJaWYoc2VsLnBbMF0ucDItc2VsLnBbMF0ucDE+QkxPQ0tTSVpFKQoJCQkJCWVycm9y KEVsb25ncmhzKTsKCQkJCWJ1ZnJlYWQoJmYtPlUsIHNlbC5wWzBdLnAxLCBnZW5idWYsIHNlbC5w WzBdLnAyLXNlbC5wWzBdLnAxKTsKCQkJCVN0cmluc2VydCgmZ2Vuc3RyLAoJCQkJCXRtcHJzdHIo Z2VuYnVmLCAoaW50KShzZWwucFswXS5wMi1zZWwucFswXS5wMSkpLAoJCQkJCWdlbnN0ci5uKTsK CQkJfQoJCWlmKHNlbC5wWzBdLnAxIT1zZWwucFswXS5wMil7CgkJCWxvZ2RlbGV0ZShmLCBzZWwu cFswXS5wMSwgc2VsLnBbMF0ucDIpOwoJCQlkZWx0YS09c2VsLnBbMF0ucDItc2VsLnBbMF0ucDE7 CgkJfQoJCWlmKGdlbnN0ci5uKXsKCQkJbG9naW5zZXJ0KGYsIHNlbC5wWzBdLnAyLCBnZW5zdHIu cywgZ2Vuc3RyLm4pOwoJCQlkZWx0YSs9Z2Vuc3RyLm47CgkJfQoJCWRpZHN1YiA9IDE7CgkJaWYo IWNwLT5mbGFnKQoJCQlicmVhazsKCX0KCWlmKCFkaWRzdWIgJiYgbmVzdD09MCkKCQllcnJvcihF bm9zdWIpOwoJZi0+bmRvdC5yLnAxID0gYWRkci5yLnAxLCBmLT5uZG90LnIucDIgPSBhZGRyLnIu cDIrZGVsdGE7CglyZXR1cm4gVFJVRTsKfQoKaW50CnVfY21kKEZpbGUgKmYsIENtZCAqY3ApCnsK CWludCBuOwoKCVVTRUQoZik7CglVU0VEKGNwKTsKCW4gPSBjcC0+bnVtOwoJaWYobiA+PSAwKQoJ CXdoaWxlKG4tLSAmJiB1bmRvKFRSVUUpKQoJCQk7CgllbHNlCgkJd2hpbGUobisrICYmIHVuZG8o RkFMU0UpKQoJCQk7CglyZXR1cm4gVFJVRTsKfQoKaW50CndfY21kKEZpbGUgKmYsIENtZCAqY3Ap CnsKCWlmKGdldG5hbWUoZiwgY3AtPmN0ZXh0LCBGQUxTRSk9PTApCgkJZXJyb3IoRW5vbmFtZSk7 Cgl3cml0ZWYoZik7CglyZXR1cm4gVFJVRTsKfQoKaW50CnhfY21kKEZpbGUgKmYsIENtZCAqY3Ap CnsKCWlmKGNwLT5yZSkKCQlsb29wZXIoZiwgY3AsIGNwLT5jbWRjPT0neCcpOwoJZWxzZQoJCWxp bmVsb29wZXIoZiwgY3ApOwoJcmV0dXJuIFRSVUU7Cn0KCmludApYX2NtZChGaWxlICpmLCBDbWQg KmNwKQp7CglVU0VEKGYpOwoJZmlsZWxvb3BlcihjcCwgY3AtPmNtZGM9PSdYJyk7CglyZXR1cm4g VFJVRTsKfQoKaW50CnBsYW45X2NtZChGaWxlICpmLCBDbWQgKmNwKQp7CglwbGFuOShmLCBjcC0+ Y21kYywgY3AtPmN0ZXh0LCBuZXN0KTsKCXJldHVybiBUUlVFOwp9CgppbnQKZXFfY21kKEZpbGUg KmYsIENtZCAqY3ApCnsKCWludCBjaGFyc29ubHkgPSBGQUxTRTsKCglzd2l0Y2goY3AtPmN0ZXh0 LT5uKXsKCWNhc2UgMToKCQljaGFyc29ubHkgPSBGQUxTRTsKCQlicmVhazsKCWNhc2UgMjoKCQlp ZihjcC0+Y3RleHQtPnNbMF09PScjJyl7CgkJCWNoYXJzb25seSA9IFRSVUU7CgkJCWJyZWFrOwoJ CX0KCWRlZmF1bHQ6CgkJU0VUKGNoYXJzb25seSk7CgkJZXJyb3IoRW5ld2xpbmUpOwoJfQoJcHJp bnRwb3NuKGYsIGNoYXJzb25seSk7CglyZXR1cm4gVFJVRTsKfQoKaW50Cm5sX2NtZChGaWxlICpm LCBDbWQgKmNwKQp7CglBZGRyZXNzIGE7CgoJaWYoY3AtPmFkZHIgPT0gMCl7CgkJLyogRmlyc3Qg cHV0IGl0IG9uIG5ld2xpbmUgYm91bmRhcmllcyAqLwoJCWFkZHIgPSBsaW5lYWRkcigoUG9zbikw LCBmLT5kb3QsIC0xKTsKCQlhID0gbGluZWFkZHIoKFBvc24pMCwgZi0+ZG90LCAxKTsKCQlhZGRy LnIucDIgPSBhLnIucDI7CgkJaWYoYWRkci5yLnAxPT1mLT5kb3Quci5wMSAmJiBhZGRyLnIucDI9 PWYtPmRvdC5yLnAyKQoJCQlhZGRyID0gbGluZWFkZHIoKFBvc24pMSwgZi0+ZG90LCAxKTsKCQlk aXNwbGF5KGYpOwoJfWVsc2UgaWYoZG93bmxvYWRlZCkKCQltb3ZldG8oZiwgYWRkci5yKTsKCWVs c2UKCQlkaXNwbGF5KGYpOwoJcmV0dXJuIFRSVUU7Cn0KCmludApjZF9jbWQoRmlsZSAqZiwgQ21k ICpjcCkKewoJVVNFRChmKTsKCWNkKGNwLT5jdGV4dCk7CglyZXR1cm4gVFJVRTsKfQoKaW50CmFw cGVuZChGaWxlICpmLCBDbWQgKmNwLCBQb3NuIHApCnsKCWlmKGNwLT5jdGV4dC0+bj4wICYmIGNw LT5jdGV4dC0+c1tjcC0+Y3RleHQtPm4tMV09PTApCgkJLS1jcC0+Y3RleHQtPm47CglpZihjcC0+ Y3RleHQtPm4+MCkKCQlsb2dpbnNlcnQoZiwgcCwgY3AtPmN0ZXh0LT5zLCBjcC0+Y3RleHQtPm4p OwoJZi0+bmRvdC5yLnAxID0gcDsKCWYtPm5kb3Quci5wMiA9IHArY3AtPmN0ZXh0LT5uOwoJcmV0 dXJuIFRSVUU7Cn0KCmludApkaXNwbGF5KEZpbGUgKmYpCnsKCVBvc24gcDEsIHAyOwoJaW50IG5w OwoJY2hhciAqYzsKCglwMSA9IGFkZHIuci5wMTsKCXAyID0gYWRkci5yLnAyOwoJaWYocDIgPiBm LT5VLm5jKXsKCQlmcHJpbnQoMiwgImJhZCBkaXNwbGF5IGFkZHIgcDE9JWxkIHAyPSVsZCBmLT5V Lm5jPSVkXG4iLCBwMSwgcDIsIGYtPlUubmMpOyAvKlpaWiBzaG91bGQgbmV2ZXIgaGFwcGVuLCBj YW4gcmVtb3ZlICovCgkJcDIgPSBmLT5VLm5jOwoJfQoJd2hpbGUocDEgPCBwMil7CgkJbnAgPSBw Mi1wMTsKCQlpZihucD5CTE9DS1NJWkUtMSkKCQkJbnAgPSBCTE9DS1NJWkUtMTsKCQlidWZyZWFk KCZmLT5VLCBwMSwgZ2VuYnVmLCBucCk7CgkJZ2VuYnVmW25wXSA9IDA7CgkJYyA9IFN0cnRvYyh0 bXByc3RyKGdlbmJ1ZiwgbnArMSkpOwoJCWlmKGRvd25sb2FkZWQpCgkJCXRlcm13cml0ZShjKTsK CQllbHNlCgkJCVdyaXRlKDEsIGMsIHN0cmxlbihjKSk7CgkJZnJlZShjKTsKCQlwMSArPSBucDsK CX0KCWYtPmRvdCA9IGFkZHI7CglyZXR1cm4gVFJVRTsKfQoKdm9pZApsb29wZXIoRmlsZSAqZiwg Q21kICpjcCwgaW50IHh5KQp7CglQb3NuIHAsIG9wOwoJUmFuZ2UgcjsKCglyID0gYWRkci5yOwoJ b3A9IHh5PyAtMSA6IHIucDE7CgluZXN0Kys7Cgljb21waWxlKGNwLT5yZSk7Cglmb3IocCA9IHIu cDE7IHA8PXIucDI7ICl7CgkJaWYoIWV4ZWN1dGUoZiwgcCwgci5wMikpeyAvKiBubyBtYXRjaCwg YnV0IHkgc2hvdWxkIHN0aWxsIHJ1biAqLwoJCQlpZih4eSB8fCBvcD5yLnAyKQoJCQkJYnJlYWs7 CgkJCWYtPmRvdC5yLnAxID0gb3AsIGYtPmRvdC5yLnAyID0gci5wMjsKCQkJcCA9IHIucDIrMTsJ LyogZXhpdCBuZXh0IGxvb3AgKi8KCQl9ZWxzZXsKCQkJaWYoc2VsLnBbMF0ucDE9PXNlbC5wWzBd LnAyKXsJLyogZW1wdHkgbWF0Y2g/ICovCgkJCQlpZihzZWwucFswXS5wMT09b3ApewoJCQkJCXAr KzsKCQkJCQljb250aW51ZTsKCQkJCX0KCQkJCXAgPSBzZWwucFswXS5wMisxOwoJCQl9ZWxzZQoJ CQkJcCA9IHNlbC5wWzBdLnAyOwoJCQlpZih4eSkKCQkJCWYtPmRvdC5yID0gc2VsLnBbMF07CgkJ CWVsc2UKCQkJCWYtPmRvdC5yLnAxID0gb3AsIGYtPmRvdC5yLnAyID0gc2VsLnBbMF0ucDE7CgkJ fQoJCW9wID0gc2VsLnBbMF0ucDI7CgkJY21kZXhlYyhmLCBjcC0+Y2NtZCk7CgkJY29tcGlsZShj cC0+cmUpOwoJfQoJLS1uZXN0Owp9Cgp2b2lkCmxpbmVsb29wZXIoRmlsZSAqZiwgQ21kICpjcCkK ewoJUG9zbiBwOwoJUmFuZ2UgciwgbGluZXNlbDsKCUFkZHJlc3MgYSwgYTM7CgoJbmVzdCsrOwoJ ciA9IGFkZHIucjsKCWEzLmYgPSBmOwoJYTMuci5wMSA9IGEzLnIucDIgPSByLnAxOwoJZm9yKHAg PSByLnAxOyBwPHIucDI7IHAgPSBhMy5yLnAyKXsKCQlhMy5yLnAxID0gYTMuci5wMjsKLypwancJ CWlmKHAhPXIucDEgfHwgKGxpbmVzZWwgPSBsaW5lYWRkcigoUG9zbikwLCBhMywgMSkpLnIucDI9 PXApKi8KCQlpZihwIT1yLnAxIHx8IChhID0gbGluZWFkZHIoKFBvc24pMCwgYTMsIDEpLCBsaW5l c2VsID0gYS5yLCBsaW5lc2VsLnAyPT1wKSl7CgkJCWEgPSBsaW5lYWRkcigoUG9zbikxLCBhMywg MSk7CgkJCWxpbmVzZWwgPSBhLnI7CgkJfQoJCWlmKGxpbmVzZWwucDEgPj0gci5wMikKCQkJYnJl YWs7CgkJaWYobGluZXNlbC5wMiA+PSByLnAyKQoJCQlsaW5lc2VsLnAyID0gci5wMjsKCQlpZihs aW5lc2VsLnAyID4gbGluZXNlbC5wMSkKCQkJaWYobGluZXNlbC5wMT49YTMuci5wMiAmJiBsaW5l c2VsLnAyPmEzLnIucDIpewoJCQkJZi0+ZG90LnIgPSBsaW5lc2VsOwoJCQkJY21kZXhlYyhmLCBj cC0+Y2NtZCk7CgkJCQlhMy5yID0gbGluZXNlbDsKCQkJCWNvbnRpbnVlOwoJCQl9CgkJYnJlYWs7 Cgl9CgktLW5lc3Q7Cn0KCnZvaWQKZmlsZWxvb3BlcihDbWQgKmNwLCBpbnQgWFkpCnsKCUZpbGUg KmYsICpjdXI7CglpbnQgaTsKCglpZihHbG9vcGluZysrKQoJCWVycm9yKEVuZXN0WFkpOwoJbmVz dCsrOwoJc2V0dGVtcGZpbGUoKTsKCWN1ciA9IGN1cmZpbGU7Cglmb3IoaSA9IDA7IGk8dGVtcGZp bGUubnVzZWQ7IGkrKyl7CgkJZiA9IHRlbXBmaWxlLmZpbGVwcHRyW2ldOwoJCWlmKGY9PWNtZCkK CQkJY29udGludWU7CgkJaWYoY3AtPnJlPT0wIHx8IGZpbGVtYXRjaChmLCBjcC0+cmUpPT1YWSkK CQkJY21kZXhlYyhmLCBjcC0+Y2NtZCk7Cgl9CglpZihjdXIgJiYgd2hpY2htZW51KGN1cik+PTAp CS8qIGNoZWNrIHRoYXQgY3VyIGlzIHN0aWxsIGEgZmlsZSAqLwoJCWN1cnJlbnQoY3VyKTsKCS0t R2xvb3Bpbmc7CgktLW5lc3Q7Cn0KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2FtMmsvc2FtL21rZmlsZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMTczNwAwMDAwMTUxADAwMDAwMDAwNzYyADA3MTExNDA2 MjE2ADAwMTQ3MzUAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1 c3RhcgAwMHNjaHdhcnR6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2NzZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAwMDAwMDQwADAwMDAwMjcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8LyRvYmp0eXBlL21rZmlsZQoKVEFSRz1zYW0KT0ZJ TEVTPXNhbS4kT1wKCWFkZHJlc3MuJE9cCglidWZmLiRPXAoJY21kLiRPXAoJZGlzay4kT1wKCWVy cm9yLiRPXAoJZmlsZS4kT1wKCWlvLiRPXAoJbGlzdC4kT1wKCW1lc2cuJE9cCgltb3ZldG8uJE9c CgltdWx0aS4kT1wKCXBsYW45LiRPXAoJcmFzcC4kT1wKCXJlZ2V4cC4kT1wKCXNoZWxsLiRPXAoJ c3RyaW5nLiRPXAoJc3lzLiRPXAoJdXRpbC4kT1wKCXhlYy4kT1wKCkhGSUxFUz1zYW0uaFwKCWVy cm9ycy5oXAoJbWVzZy5oXAoKQklOPS8kb2JqdHlwZS9iaW4KPC9zeXMvc3JjL2NtZC9ta29uZQoK YWRkcmVzcy4kTyBjbWQuJE8gcGFyc2UuJE8geGVjLiRPIHVuaXguJE86CXBhcnNlLmgKCnNhZmVp bnN0YWxsOiAkTy5vdXQKCW12ICRCSU4vJFRBUkcgJEJJTi9vJFRBUkcKCWNwICRwcmVyZXEgJEJJ Ti8kVEFSRwoKc2FmZWluc3RhbGxhbGw6VjoKCWZvciAob2JqdHlwZSBpbiAkQ1BVUykKCQltayBz YWZlaW5zdGFsbAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------- =_aaaaaaaaaa0-- From sam-fans-owner Sun Jun 4 19:04:48 2000 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.toronto.edu with SMTP id <28357>; Sun, 4 Jun 2000 18:40:40 -0400 Received: (qmail 4133 invoked by uid 991); 3 Jun 2000 04:41:43 -0000 Message-ID: <20000603044143.4132.qmail@g.bio.cse.psu.edu> From: "Scott Schwartz" Date: Sat, 3 Jun 2000 00:41:43 -0400 To: sam-fans@hawkwind.utcs.toronto.edu Subject: new sam So, did anyone try the new sam? From sam-fans-owner Thu Jun 29 13:58:07 2000 Received: from aubrey.stanford.edu ([171.64.31.58]) by hawkwind.utcs.utoronto.ca with SMTP id <44226>; Thu, 29 Jun 2000 13:56:25 -0500 Received: (qmail 14493 invoked from network); 29 Jun 2000 02:33:28 -0000 Received: from localhost.highwire.org (HELO aubrey.stanford.edu) (127.0.0.1) by localhost.highwire.org with SMTP; 29 Jun 2000 02:33:28 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: sam-fans@hawkwind.utcs.toronto.edu Dcc: Subject: preserving indention levels? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14486.962246008.1@aubrey.stanford.edu> Date: Wed, 28 Jun 2000 22:33:28 -0500 Message-Id: <00Jun29.135625edt.44226@hawkwind.utcs.utoronto.ca> I've got a question on how to solve an editing problem. When one has code that is indented at various levels, and needs to be replaced with multiple-line blocks, how does one handle preserving the indention? For example: ... System.err.println("some annoying debugging but in"); ... System.err.println("some other annoying debugging but in"); ... into ... if (Debug.level(Debug.DEBUG)) { Debug.debug(this, "some annoying debugging but in"); } ... if (Debug.level(Debug.DEBUG)) { Debug.debug(this, "some other annoying debugging but in"); } ... Is using something like s/^([ ]+).../...\1\n\1/ the only solution? Jim From sam-fans-owner Thu Jul 27 18:09:53 2000 Received: from gsyc.escet.urjc.es ([212.128.1.45]) by hawkwind.utcs.utoronto.ca with SMTP id <44215>; Thu, 27 Jul 2000 17:48:21 -0500 Received: from nautilus.dat.escet.urjc.es (IDENT:root@nautilus.dat.escet.urjc.es [212.128.1.37]) by gsyc.escet.urjc.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA13356 for ; Thu, 27 Jul 2000 10:01:16 +0200 Received: (from nemo@localhost) by nautilus.dat.escet.urjc.es (8.9.3/8.9.3) id KAA00925; Thu, 27 Jul 2000 10:14:53 +0100 From: "Fco. J. Ballesteros" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14719.64908.755161.847689@nautilus.dat.escet.urjc.es> Date: Thu, 27 Jul 2000 05:14:52 -0500 To: sam-fans@hawkwind.utcs.toronto.edu Subject: but tom-2 repeat cmd feature? X-Mailer: VM 6.75 under Emacs 20.5.1 Wouldn't it be nice if the button-2 menu could have an entry to repeat the last command in the ~~sam~~ window? I found myself repeating "|fmt" just to reformat paragraphs in a LaTeX document I was editing. Anyone made that change to sam? Or is there a better way to do it? (Doing a single |fmt when done with the modifications is not an option because there are sections of the document that shoudn't be fmt'd). regards -- () ascii ribbon campaign - against html mail /\ - against microsoft attachments From sam-fans-owner Mon Jul 31 20:19:32 2000 Received: from whitecrow.demon.co.uk ([194.222.126.246]) by hawkwind.utcs.utoronto.ca with SMTP id <44239>; Mon, 31 Jul 2000 20:09:46 -0500 Received: from whitecrow.demon.co.uk (steve@localhost [127.0.0.1]) by whitecrow.demon.co.uk (8.8.7/8.8.7) with ESMTP id HAA11988 for ; Fri, 28 Jul 2000 07:52:53 +0100 Message-Id: <200007280652.HAA11988@whitecrow.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: but tom-2 repeat cmd feature? In-reply-to: Your message of "Thu, 27 Jul 2000 05:14:52 CDT." <14719.64908.755161.847689@nautilus.dat.escet.urjc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jul 2000 01:52:53 -0500 From: Steve Kilbane > Wouldn't it be nice if the button-2 menu could have an entry to repeat > the last command in the ~~sam~~ window? plausibly, but where the does "the last command" start and finish? > I found myself repeating "|fmt" just to reformat > paragraphs in a LaTeX document I was editing. After having done a "send" in the sam window, it's the default option next time around. So four cicks do it: - single click selects the sam window; - double-click on b1 selects the whole line - single click on b2 sends. > (Doing a single |fmt when done with the modifications is not an option > because there are sections of the document that shoudn't be fmt'd). And you can't use y/pattern/ to avoid those parts? steve From sam-fans-owner Mon Jul 31 20:20:44 2000 Received: from aubrey.stanford.edu ([171.64.31.58]) by hawkwind.utcs.utoronto.ca with SMTP id <44290>; Mon, 31 Jul 2000 20:10:12 -0500 Received: (qmail 14895 invoked from network); 29 Jul 2000 20:41:06 -0000 Received: from localhost.highwire.org (HELO aubrey.stanford.edu) (127.0.0.1) by localhost.highwire.org with SMTP; 29 Jul 2000 20:41:06 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "Fco. J. Ballesteros" cc: sam-fans@hawkwind.utcs.toronto.edu Dcc: Subject: Re: but tom-2 repeat cmd feature? In-reply-to: Message from "Fco. J. Ballesteros" of "Thu, 27 Jul 2000 05:14:52 CDT."References: <14719.64908.755161.847689@nautilus.dat.escet.urjc.es> <14719.64908.755161.847689@nautilus.dat.escet.urjc.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14888.964903265.1@aubrey.stanford.edu> Date: Sat, 29 Jul 2000 16:41:06 -0500 Message-Id: <00Jul31.201012edt.44290@hawkwind.utcs.utoronto.ca> > Wouldn't it be nice if the button-2 menu could have an entry to repeat > the last command in the ~~sam~~ window? > > I found myself repeating "|fmt" just to reformat > paragraphs in a LaTeX document I was editing. If I find I have to keep using ~~sam~~ do to the same thing, I just set dot, double click the command in ~~sam~~ and select send. It is more mouse movement and clicks than what you are suggesting. However, I have found that it is normally pretty easy to use sam's command language to find the patterns I want to format. For example if I had a selection Here is some text that should be adjusted with fmt \begin{math} math != fmt ( x, y, z, a) \end{math} But the above math should not, and certainly not \begin{quote} a quote of sorts \end{quote} then the regex command 'x/(.+\n)+/v/^\\begin{/|fmt' applied to the selection will run through the text and fmt only those blocks of text that don't begin with \begin{. If you didn't have newline seperators I imagine you could do some fancy things with ',' and ';' and friends, but I'm not sure what. In those cases, I normally take a three step process where one regex splits the text into managable pieces, one regex formats select pieces, and the last regex recombines the pieces. Jim From sam-fans-owner Mon Jul 31 20:20:59 2000 Received: from deliverator.sgi.com ([204.94.214.10]) by hawkwind.utcs.utoronto.ca with SMTP id <44193>; Mon, 31 Jul 2000 20:04:51 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA02212; Thu, 27 Jul 2000 17:19:56 -0700 (PDT) mail_from (pj@cthulhu.engr.sgi.com) Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA56655; Thu, 27 Jul 2000 17:27:22 -0700 (PDT) mail_from (pj@engr.sgi.com) Received: from localhost (pj@localhost) by sam.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id RAA35696; Thu, 27 Jul 2000 17:27:11 -0700 (PDT) X-Authentication-Warning: sam.engr.sgi.com: pj owned process doing -bs Date: Thu, 27 Jul 2000 20:27:11 -0500 From: Paul Jackson To: "Fco. J. Ballesteros" cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: but tom-2 repeat cmd feature? In-Reply-To: <14719.64908.755161.847689@nautilus.dat.escet.urjc.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 27 Jul 2000, Fco. J. Ballesteros wrote: > I found myself repeating "|fmt" > just to reformat paragraphs ... A simple thing I do that helps here -- I have a couple commands, named "F" and "Q", on my path, which are trivial shell scripts calling my favorite formating and quoting (prepend '> ' to each line) filters. Then the command is reduced a couple of key strokes, to such as "|F" (both of which are shifted, it happens, for even less finger calisthenics). -- I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj From sam-fans-owner Tue Aug 8 12:02:31 2000 Received: from aubrey.stanford.edu ([171.64.31.58]) by hawkwind.utcs.utoronto.ca with SMTP id <44317>; Tue, 8 Aug 2000 11:55:15 -0500 Received: (qmail 18093 invoked from network); 7 Aug 2000 07:22:56 -0000 Received: from localhost.highwire.org (HELO aubrey.stanford.edu) (127.0.0.1) by localhost.highwire.org with SMTP; 7 Aug 2000 07:22:56 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam Fans" Dcc: Subject: sam -r and remove env MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18086.965632975.1@aubrey.stanford.edu> Date: Mon, 7 Aug 2000 03:22:55 -0500 Message-Id: <00Aug8.115515edt.44317@hawkwind.utcs.utoronto.ca> Is there any way to force 'sam -r' to initalize my login environmen on the remote end? I find losing my variables like $h and $proj annoying when trying to do 'B < echo $proj/...'? From sam-fans-owner Tue Sep 12 21:16:10 2000 Received: from web3206.mail.yahoo.com ([204.71.202.203]) by hawkwind.utcs.utoronto.ca with SMTP id <44394>; Tue, 12 Sep 2000 21:14:05 -0500 Message-ID: <20000911151022.22157.qmail@web3206.mail.yahoo.com> Received: from [204.68.140.35] by web3206.mail.yahoo.com; Mon, 11 Sep 2000 08:10:22 PDT Date: Mon, 11 Sep 2000 11:10:22 -0500 From: Jim Crigler Subject: ssam??? To: Sam Fans , Wily Fans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I saw on the Wily Fans list last week a reference to "ssam". Is this a "streamed sam" to which there is (I think) an allusion in one of the sam papers. I just got the latest sam distribution from netlib, but didn't see it there --- perhaps I didn't look carefully enough? -- Jim Crigler __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From sam-fans-owner Tue Sep 12 21:16:41 2000 Received: from aubrey.stanford.edu ([171.64.31.58]) by hawkwind.utcs.utoronto.ca with SMTP id <44397>; Tue, 12 Sep 2000 21:15:47 -0500 Received: (qmail 17774 invoked from network); 11 Sep 2000 15:28:26 -0000 Received: from localhost.highwire.org (HELO aubrey.stanford.edu) (127.0.0.1) by localhost.highwire.org with SMTP; 11 Sep 2000 15:28:26 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: Jim Crigler cc: Sam Fans , Wily Fans Dcc: Subject: Re: ssam??? In-reply-to: Message from Jim Crigler of "Mon, 11 Sep 2000 08:10:22 PDT."References: <20000911151022.22157.qmail@web3206.mail.yahoo.com> <20000911151022.22157.qmail@web3206.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17769.968686105.1@aubrey.stanford.edu> Date: Mon, 11 Sep 2000 11:28:26 -0500 Message-Id: <00Sep12.211547edt.44397@hawkwind.utcs.utoronto.ca> > I saw on the Wily Fans list last week a reference to "ssam". Is this > a "streamed sam" to which there is (I think) an allusion in one of the > sam papers. I just got the latest sam distribution from netlib, but > didn't see it there --- perhaps I didn't look carefully enough? It was made by Alistair Crooks, in the UK. There are Linux and NetBSD ports of it all over, but the main homepage is http://www.westley.demon.co.uk/software.html From sam-fans-owner Thu Sep 14 16:11:35 2000 Received: from fw.softwell.se ([193.15.236.45]) by hawkwind.utcs.utoronto.ca with SMTP id <44306>; Thu, 14 Sep 2000 16:11:09 -0500 Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id VAA21854 for ; Thu, 14 Sep 2000 21:45:21 +0200 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id VAA31264 for sam-fans@hawkwind.utcs.toronto.edu; Thu, 14 Sep 2000 21:45:20 +0200 Date: Thu, 14 Sep 2000 15:45:20 -0500 From: Bengt Kleberg Message-Id: <200009141945.VAA31264@trillian.softwell.se> To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: ssam??? > > I saw on the Wily Fans list last week a reference to "ssam". > It was made by Alistair Crooks, in the UK. There is also a rc script that uses sam to produce a semblance of stream editing. Look in sam-9libs. Bengt From sam-fans-owner Mon Sep 25 16:52:02 2000 Received: from c002.snv.cp.net ([209.228.32.172]) by hawkwind.utcs.utoronto.ca with SMTP id <44469>; Mon, 25 Sep 2000 16:47:08 -0500 Received: (cpmta 8107 invoked from network); 24 Sep 2000 12:32:39 -0700 Received: from 1Cust195.tnt2.det3.da.uu.net (HELO home.wa8tzg.org) (63.27.42.195) by smtp.peoplepc.com (209.228.32.172) with SMTP; 24 Sep 2000 12:32:39 -0700 X-Sent: 24 Sep 2000 19:32:39 GMT Received: by home.wa8tzg.org (Postfix, from userid 501) id F29EB760C; Sun, 24 Sep 2000 15:30:47 -0400 (EDT) Date: Sun, 24 Sep 2000 15:30:35 -0500 From: Bill Meahan To: Wily Fans Cc: Sam Fans Subject: Re: wily-9libs and sam-9libs on 24-bit Linux display Message-ID: <20000924093231.A25653@wa8tzg.org> Mail-Followup-To: Wily Fans , Sam Fans References: <20000417145820.14626.qmail@web3205.mail.yahoo.com> <39173E20.77F0D49@kremvax.net> <39174AE2.CEC76A4@uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <39174AE2.CEC76A4@uiuc.edu>; from ejk@uiuc.edu on Mon, May 08, 2000 at 06:16:50PM -0500 Content-Length: 876 Lines: 24 Organization: None, can't you tell? X-Mailer: KMail [version 1.0.28] Content-Transfer-Encoding: 8bit On Mon, May 08, 2000 at 06:16:50PM -0500, Ed Kubaitis wrote: > "Mark H. Wilkinson" wrote: [snip] > FWIW, on RH Linux 6.2 recently, I had to backoff 24bpp to 16 to make an > ancient (circa 1993-4) version of libXg/samterm functional. Sory for the reply to such an old message but I've recently hit this myself. Looking at the code for 9libs, I find a lot of places where the number of colors is hard-coded at 256 (8-bit depth). I changed these to 65536 for an experiment,as well as reducing my colordepth to 16-bit, but no joy. Things die where the color map is being read via the X function. Not being an X programmer, I'm now stuck. System is Mandrake 7.1 with XFree86 3.3.6 Suggestions or fixes? Thanks! -- 73 de Bill Meahan WA8TZG wmeahan@wa8tzg.org Home for Orphan Hand Tools & Boatanchors (esp. Collins) Relax -- I use Genuine SMTP Mail, not that M$ virus trap! From sam-fans-owner Mon Nov 13 18:30:46 2000 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.utoronto.ca with SMTP id <44241>; Mon, 13 Nov 2000 18:24:00 -0500 Received: (qmail 21177 invoked by uid 991); 28 Oct 2000 06:30:18 -0000 Message-ID: <20001028063018.21176.qmail@g.bio.cse.psu.edu> To: sam-fans@hawkwind.utcs.toronto.edu To: 9fans@cse.psu.edu Subject: updated unix port of sam Date: Sat, 28 Oct 2000 02:30:18 -0500 From: Scott Schwartz Hi, I've made a few changes to the unix port of sam, to make it match the third edition's code more closely. (As before, this relies on the old version of samterm (libXg)). The compressed tar file is available from: http://www.cse.psu.edu/~schwartz/sam-9.3.1-unix.tar.bz2 -- Scott From sam-fans-owner Tue Dec 12 17:56:46 2000 Received: from aubrey.stanford.edu ([171.66.232.31]) by hawkwind.utcs.utoronto.ca with SMTP id <45081>; Tue, 12 Dec 2000 17:45:50 -0500 Received: (qmail 15123 invoked from network); 12 Dec 2000 07:23:33 -0000 Received: from localhost.highwire.org (HELO aubrey.stanford.edu) (127.0.0.1) by localhost.highwire.org with SMTP; 12 Dec 2000 07:23:33 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam Fans" Dcc: Subject: 24/32 bpp with 9libs vs. orig libXg MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15118.976605813.1@aubrey.stanford.edu> Date: Tue, 12 Dec 2000 02:23:33 -0500 Message-Id: <00Dec12.174550edt.45081@hawkwind.utcs.utoronto.ca> A few people have noted problems running sam and 9term on 24 bpp or 32 bpp displays (we would get the error 'libg: i/o error' when we tried to open a menu in 9term or simply bring up samterm). It appears that my problem may have stemmed from a problem specific to the 9libs port of the original libXg library. The other day I installed limbo, and found that wm/wm couldn't handle 16bpp depth. 8bpp was unacceptable to me, and I had not been able to run sam and 9term in 24bpp mode before. Today I installed the original samterm from Rob Pike's release, available at ftp://netlib.bell-labs.com/netlib/research/sam.shar.gz, and found the samterm compiled from that source works perfectly at 24bpp. I recompiled my 9term against this original libXg, and found that it also works at 24bpp without any visible problems. Since the samterm works with the latest sam (editor only) released a few months ago, I'm happy. =) My original goal was to get a static version of libXg compiled so that I could debug it with gdb. I was having great difficulty getting the 9libs version working with gdb (perhaps because it uses this .la/.lo format that I've never really understood). Imagine my surpise when compiling the original libXg fixed the problem. =) Jim From sam-fans-owner Thu Dec 14 02:33:24 2000 Received: from albatross-ext.wise.edt.ericsson.se ([194.237.142.116]) by hawkwind.utcs.utoronto.ca with SMTP id <44709>; Thu, 14 Dec 2000 02:32:53 -0500 Received: from etxb.ericsson.se (avx6.etxb.ericsson.se [130.100.180.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eBE7MI420054 for ; Thu, 14 Dec 2000 08:22:18 +0100 (MET) Received: from avc093.etxb.ericsson.se (avc093 [130.100.180.205]) by etxb.ericsson.se (8.9.3+Sun/8.9.3/eri-dom-1.1) with ESMTP id IAA26292 for ; Thu, 14 Dec 2000 08:22:18 +0100 (MET) From: Bengt Kleberg Received: (from qtxkleb@localhost) by avc093.etxb.ericsson.se (8.9.3+Sun/8.9.3/client-1.0) id IAA00286 for sam-fans@hawkwind.utcs.utoronto.ca; Thu, 14 Dec 2000 08:22:15 +0100 (MET) Date: Thu, 14 Dec 2000 02:22:15 -0500 Message-Id: <200012140722.IAA00286@avc093.etxb.ericsson.se> To: sam-fans@hawkwind.utcs.utoronto.ca Subject: 'original' libXg and 24 bpp, follow up X-Sun-Charset: US-ASCII greetings, after the good news about the original sams libXg working on 24 bpp, i tried it. both to get a working sam, and in the hope of perhaps finding out why. 'test' did not work for me. 'rdcolmap bitmap too deep' anything in particular i need to do? (apart from modifying 'test.c' and 'Make.solaris' to get 'test' to compile) PS: does anybody have the url to wily? wily-fans produced no response... From sam-fans-owner Thu Dec 14 13:55:58 2000 Received: from aubrey.stanford.edu ([171.66.232.31]) by hawkwind.utcs.utoronto.ca with SMTP id <45076>; Thu, 14 Dec 2000 13:55:38 -0500 Received: (qmail 26786 invoked from network); 14 Dec 2000 08:25:10 -0000 Received: from localhost.highwire.org (HELO aubrey.stanford.edu) (127.0.0.1) by localhost.highwire.org with SMTP; 14 Dec 2000 08:25:10 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: Bengt Kleberg cc: sam-fans@hawkwind.utcs.toronto.edu Dcc: Subject: Re: 'original' libXg and 24 bpp, follow up In-reply-to: Message from Bengt Kleberg of "Thu, 14 Dec 2000 02:22:15 EST."References: <200012140722.IAA00286@avc093.etxb.ericsson.se> <200012140722.IAA00286@avc093.etxb.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26781.976782309.1@aubrey.stanford.edu> Date: Thu, 14 Dec 2000 03:25:10 -0500 Sender: jimr@aubrey.stanford.edu Message-Id: <00Dec14.135538edt.45076@hawkwind.utcs.utoronto.ca> > 'test' did not work for me. > 'rdcolmap bitmap too deep' After including "u.h" to fix a problem with a missing def for Rune, test in the libXg directory compiled for me, and ran up to the test of arc. At that point it bailed with the same error as you reported. The problem appears to be that rdcolmap handles only up to 256 colors (it's hard coded as a magic number). If it detects more than that, it bails. I just went into xtbinit.c commented out the 'return;' statement after the color depth check in rdcolmap. Test ran for me after that, though the inversion test doesn't do the right thing. I guess I'm curious about samterm itself -- since it doesn't use color I'm thinking the above doesn't matter much in terms of it's impact. A message I dug up from the wily list: Date: Wed, 22 Nov 1995 12:57:40 EST To: wilyfans@jli.com From: Chris Siebenmann Subject: Re: wily doesn't seem to like 24-bit TrueColor ... A friend fixed this (in sam) and has given me some patches I need to integrate. The core problem is that libXg assumes that the framebuffer depth is equal to the number of colour bits; '24-bit' colour in my X server is actually 32 bits deep, breaking this. The solution is apparently fairly simple -- just stop libXg assuming this in the few places where it matters. ... > PS: does anybody have the url to wily? wily-fans produced no response... The url for the editor is now at http://www.cs.yorku.ca/~oz/wily/, wilyfans@jli.com is the email address for the list. Jim From sam-fans-owner Mon Dec 18 22:04:58 2000 Received: from albatross-ext.wise.edt.ericsson.se ([194.237.142.116]) by hawkwind.utcs.utoronto.ca with SMTP id <45415>; Mon, 18 Dec 2000 22:04:35 -0500 Received: from etxb.ericsson.se (avx6.etxb.ericsson.se [130.100.180.16]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eBIEnF426738; Mon, 18 Dec 2000 15:49:16 +0100 (MET) Received: from avc093.etxb.ericsson.se (avc093 [130.100.180.205]) by etxb.ericsson.se (8.9.3+Sun/8.9.3/eri-dom-1.1) with ESMTP id PAA08481; Mon, 18 Dec 2000 15:49:14 +0100 (MET) From: Bengt Kleberg Received: (from qtxkleb@localhost) by avc093.etxb.ericsson.se (8.9.3+Sun/8.9.3/client-1.0) id PAA18696; Mon, 18 Dec 2000 15:49:12 +0100 (MET) Date: Mon, 18 Dec 2000 09:49:12 -0500 Message-Id: <200012181449.PAA18696@avc093.etxb.ericsson.se> To: qtxkleb@etxb.ericsson.se, jim.robinson@stanford.edu Subject: Re: 'original' libXg and 24 bpp, follow up Cc: sam-fans@hawkwind.utcs.toronto.edu X-Sun-Charset: US-ASCII Confirmed. A simple change to 9libs, taken from the original sam/libXg, makes it poissible to run sam on 24 bpp. Diff sent to Mark, to allow him a chance to 'polish' it before incorporation. Bengt Kleberg From sam-fans-owner Wed Feb 21 17:13:46 2001 Received: from prv-mail21.provo.novell.com ([137.65.81.126]) by hawkwind.utcs.utoronto.ca with SMTP id <44648>; Wed, 21 Feb 2001 17:13:30 -0500 Received: from wumpus (wumpus.bht.novell.com [164.99.41.132]) by prv-mail21.provo.novell.com; Wed, 21 Feb 2001 13:42:31 -0700 From: Mike Scheer To: sam-fans@hawkwind.utcs.toronto.edu Subject: p9 or other on linux? Date: Wed, 21 Feb 2001 15:42:36 -0500 Organization: Plexus Systems Inc. Reply-To: mdash@plexsys.com Message-ID: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I've been using win-based development tools for a couple of years, and am now about to move onto my first linux project. This gives me the opportunity to dust off sam , 9term, and 9wm. Years ago, I had them running on various unices, but I would like to get hold of existing linux ports if possible. URLs? I haven't had much luck with google or yahoo searches. Thanks. Incidentally, there appear no longer to be sam downloads on bell-labs.com, other than as part of the plan9 distribution. seanq's win32 port is not to be seen. --Mike Scheer From sam-fans-owner Thu Feb 22 13:57:27 2001 Received: from prv-mail21.provo.novell.com ([137.65.81.126]) by hawkwind.utcs.utoronto.ca with SMTP id <44342>; Thu, 22 Feb 2001 13:57:11 -0500 Received: from wumpus (wumpus.bht.novell.com [164.99.41.131]) by prv-mail21.provo.novell.com; Thu, 22 Feb 2001 09:56:31 -0700 From: Mike Scheer To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: p9 or other on linux? Date: Thu, 22 Feb 2001 11:56:33 -0500 Organization: Plexus Systems Inc. Reply-To: mdash@plexsys.com Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sorrry for the auto-followup, but gregoire@inrs-telecom.uquebec.ca pointed out that sam is indeed still available in netlib. I can only say that the searches I had tried on bell-labs.com did not show sam. --Mike Scheer On Wed, 21 Feb 2001 15:42:36 -0500, I wrote: >I've been using win-based development tools for a couple of years, and >am now about to move onto my first linux project. This gives me the >opportunity to dust off sam , 9term, and 9wm. Years ago, I had them >running on various unices, but I would like to get hold of existing >linux ports if possible. URLs? I haven't had much luck with google or >yahoo searches. Thanks. > >Incidentally, there appear no longer to be sam downloads on >bell-labs.com, other than as part of the plan9 distribution. seanq's >win32 port is not to be seen. > >--Mike Scheer From sam-fans-owner Thu Feb 22 13:57:29 2001 Received: from hoemail2.firewall.lucent.com ([192.11.226.163]) by hawkwind.utcs.utoronto.ca with SMTP id <44343>; Thu, 22 Feb 2001 13:57:26 -0500 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA11683 for ; Thu, 22 Feb 2001 12:17:08 -0500 (EST) Received: from scalene.wh.lucent.com (h135-88-38-89.lucent.com [135.88.38.89]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA11646; Thu, 22 Feb 2001 12:17:06 -0500 (EST) Received: from localhost (rubin@localhost) by scalene.wh.lucent.com (8.9.3/8.8.7) with ESMTP id IAA14335; Thu, 22 Feb 2001 08:16:43 -0500 X-Authentication-Warning: scalene.wh.lucent.com: rubin owned process doing -bs Date: Thu, 22 Feb 2001 08:16:43 -0500 From: David L Rubin X-Sender: rubin@scalene.wh.lucent.com To: Mike Scheer cc: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: p9 or other on linux? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Feb 2001, Mike Scheer wrote: > I've been using win-based development tools for a couple of years, and > am now about to move onto my first linux project. This gives me the > opportunity to dust off sam , 9term, and 9wm. Years ago, I had them > running on various unices, but I would like to get hold of existing > linux ports if possible. URLs? I haven't had much luck with google or > yahoo searches. Thanks. Try http://www.freshmeat.net. Also, http://www.plan9.bell-labs.com/plan9dist. > Incidentally, there appear no longer to be sam downloads on > bell-labs.com, other than as part of the plan9 distribution. seanq's > win32 port is not to be seen. I downloaded Sean's win32 port a few months ago. You can always send him email: seanq@lucent.com. david ~~ David L Rubin f/973.581.6665 v/973.386.8598 Lucent Technologies, NJ0117 15G-117, 67 Whippany Rd, Whippany, NJ 07981 pub key fingerprint: 59E BC8E 79CB A6CB 4B57 A1B2 CDB0 2FD4 AADC 81AA temporary voice mail: +34 91.807.1054 From sam-fans-owner Thu Feb 22 16:19:56 2001 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.utoronto.ca with SMTP id <44407>; Thu, 22 Feb 2001 16:19:17 -0500 Received: (qmail 10223 invoked by uid 991); 22 Feb 2001 19:40:48 -0000 Message-ID: <20010222194048.10221.qmail@g.bio.cse.psu.edu> to: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: p9 or other on linux? In-Reply-To: Message from Mike Scheer of "Thu, 22 Feb 2001 11:56:33 EST." Date: Thu, 22 Feb 2001 14:40:48 -0500 From: Scott Schwartz I'm worried about version skew. The current Plan 9 version of sam uses code from acme. At least three people, including me, have done unix ports. Right now, I have no clue what version any particular archive site will be handing out. We really ought to converge on something. From sam-fans-owner Fri Feb 23 04:26:27 2001 Received: from penguin-ext.wise.edt.ericsson.se ([194.237.142.110]) by hawkwind.utcs.utoronto.ca with SMTP id <44537>; Fri, 23 Feb 2001 04:26:08 -0500 Received: from etxb.ericsson.se (avx6.etxb.ericsson.se [130.100.180.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f1N7I8d18584; Fri, 23 Feb 2001 08:18:08 +0100 (MET) Received: from avc093.etxb.ericsson.se (avc093 [130.100.180.205]) by etxb.ericsson.se (8.9.3+Sun/8.9.3/eri-dom-1.1) with ESMTP id IAA23485; Fri, 23 Feb 2001 08:18:07 +0100 (MET) From: Bengt Kleberg Received: (from qtxkleb@localhost) by avc093.etxb.ericsson.se (8.9.3+Sun/8.9.3/client-1.0) id IAA11581; Fri, 23 Feb 2001 08:18:06 +0100 (MET) Date: Fri, 23 Feb 2001 02:18:06 -0500 Message-Id: <200102230718.IAA11581@avc093.etxb.ericsson.se> To: mdash@plexys.com Subject: Re: p9 or other on linux? Cc: sam-fans@hawkwind.utcs.toronto.edu X-Sun-Charset: US-ASCII > sam , 9term, and 9wm. Do not forget acme (under Inferno, or as wily, for unix), 9menu, rc and tcs. > URLs? The ones I have that freshmeat.org is unlikely to know about: www.vitanuova.com www.cs.yorku.ca/~oz/wily ftp://ftp.freefriends.org/arnold www.cse.psu.edu/~schwartz www.eecs.harvard.edu/~rcs From sam-fans-owner Mon Feb 26 23:46:00 2001 Received: from smtp07.mail.onemain.com ([63.208.208.73]) by hawkwind.utcs.utoronto.ca with SMTP id <44591>; Mon, 26 Feb 2001 23:45:54 -0500 Received: (qmail 20714 invoked from network); 24 Feb 2001 19:02:58 -0000 Received: from 209-239-203-50.oak.jps.net (HELO pkwksj.sjna.corp.dom) ([209.239.203.50]) (envelope-sender ) by smtp07.mail.onemain.com (qmail-ldap-1.03) with SMTP for ; 24 Feb 2001 19:02:58 -0000 From: "kim kubik" To: , Subject: Re: p9 or other on linux? Date: Sat, 24 Feb 2001 14:05:05 -0500 Message-ID: <01c09e94$d14544a0$32cbefd1@pkwksj.sjna.corp.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 -----Original Message----- From: Mike Scheer Subject: p9 or other on linux? >I would like to get hold of existing >linux ports if possible. URLs? I haven't had >much luck with google or >yahoo searches. Thanks. I remember when I first started looking for the same p9-4-linux stuff a number of years back that the FreeBSD people had a more complete and more up-to-date collection in their ports section than any of the Linux dists (Debian was the only one that came close). I once bought a Linux magazine with a cover proclaiming the issue was devoted to the "Internationalization of Linux". Inside were about ten articles on emacs and how someday it was going to display UTF-8 or some such. They had never even heard of 9term/sam/wily/etc. But I can't use emacs because I only have a 10-Gig Hard Drive . . . :-) - kim From sam-fans-owner Mon Feb 26 23:46:01 2001 Received: from d1-hrz.uni-duisburg.de ([134.91.4.38]) by hawkwind.utcs.utoronto.ca with SMTP id <44547>; Mon, 26 Feb 2001 23:44:21 -0500 Received: from l1-hrz.uni-duisburg.de (sb463ba@l1-hrz.uni-duisburg.de [134.91.1.34]) by d1-hrz.uni-duisburg.de (8.11.1/8.11.1) with ESMTP id f1NCxLJ10566; Fri, 23 Feb 2001 13:59:21 +0100 (MET) Received: (from sb463ba@localhost) by l1-hrz.uni-duisburg.de (8.9.3 (PHNE_18546)/8.9.3) id NAA05633; Fri, 23 Feb 2001 13:59:09 +0100 (MEZ) From: Georg Bauhaus Message-Id: <200102231259.NAA05633@l1-hrz.uni-duisburg.de> Subject: Re: p9 or other on linux? In-Reply-To: from Mike Scheer at "Feb 21, 2001 03:42:36 pm" To: mdash@plexsys.com Date: Fri, 23 Feb 2001 07:59:09 -0500 CC: sam-fans@hawkwind.utcs.toronto.edu X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > This gives me the > opportunity to dust off sam , 9term, and 9wm. Years ago, I had them > running on various unices, but I would like to get hold of existing > linux ports if possible. URLs? I haven't had much luck with google or > yahoo searches. Thanks. > http://packages.debian.org/stable/editors/sam.html http://packages.debian.org/stable/x11/9wm.html 9term appears to have been withdrawn, because the package is in need of a new maintainer: http://www.debian.org/devel/wnpp/work_needing.html, http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=68295 Georg Bauhaus From sam-fans-owner Tue Mar 13 18:02:29 2001 Received: from prv-mail21.provo.novell.com ([137.65.81.126]) by hawkwind.utcs.utoronto.ca with SMTP id <46163>; Tue, 13 Mar 2001 18:02:10 -0500 Received: from wumpus (wumpus.bht.novell.com [164.99.41.143]) by prv-mail21.provo.novell.com; Tue, 13 Mar 2001 07:24:17 -0700 From: Mike Scheer To: pj@sam.engr.sgi.com (Paul Jackson) Cc: sam-fans@hawkwind.utcs.toronto.edu Subject: samx Date: Tue, 13 Mar 2001 09:24:26 -0500 Organization: Plexus Systems Inc. Reply-To: mdash@plexsys.com Message-ID: References: <200004262234.PAA76725@sam.engr.sgi.com> In-Reply-To: <200004262234.PAA76725@sam.engr.sgi.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Paul-- Are the samx sources posted anywhere? My saved email shows that discussion thread petering-out inconclusively. Thanks. --Mike Scheer From sam-fans-owner Wed Mar 14 03:11:01 2001 Received: from ejk.cso.uiuc.edu ([130.126.112.162]) by hawkwind.utcs.utoronto.ca with SMTP id <44379>; Wed, 14 Mar 2001 03:10:37 -0500 Received: (qmail 12913 invoked from network); 14 Mar 2001 01:12:53 -0000 Received: from c330414-c.chmpgn1.il.home.com (HELO uiuc.edu) (ejk@24.22.18.168) by ejk.cso.uiuc.edu with SMTP; 14 Mar 2001 01:12:53 -0000 Sender: ejk Message-ID: <3AAEC593.187C6641@uiuc.edu> Date: Tue, 13 Mar 2001 20:12:51 -0500 From: Ed Kubaitis Organization: CCSO - University of Illinois at Urbana-Champaign X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: sam-fans@hawkwind.utcs.toronto.edu Subject: Re: samx References: <200004262234.PAA76725@sam.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Scheer wrote: > > Paul-- > > Are the samx sources posted anywhere? My saved email shows that > discussion thread petering-out inconclusively. Thanks. > > --Mike Scheer Try ftp://ftp.funet.fi/pub/unix/editors/sam/samx2/ FWIW, I have been running more or less this version since 1993, most recently on Redhat 7. -------------------------- Ed Kubaitis (ejk@uiuc.edu) CCSO - University of Illinois at Urbana-Champaign From sam-fans-owner Wed Mar 14 03:11:02 2001 Received: from smtp01.mail.onemain.com ([63.208.208.73]) by hawkwind.utcs.utoronto.ca with SMTP id <44433>; Wed, 14 Mar 2001 03:10:53 -0500 Received: (qmail 19525 invoked from network); 14 Mar 2001 05:28:39 -0000 Received: from 209-239-195-155.oak.jps.net (HELO pkwksj.sjna.corp.dom) ([209.239.195.155]) (envelope-sender ) by smtp01.mail.onemain.com (qmail-ldap-1.03) with SMTP for ; 14 Mar 2001 05:28:39 -0000 From: "kim kubik" To: , "Paul Jackson" Cc: Subject: Re: samx Date: Wed, 14 Mar 2001 00:32:23 -0500 Message-ID: <01c0ac48$25e41020$9bc3efd1@pkwksj.sjna.corp.dom> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 -----Original Message----- From: Mike Scheer Subject: samx Are the samx sources posted anywhere? My saved email shows that discussion thread petering-out inconclusively. Thanks. ----Unoriginal Reply---- ftp.funet.fi/pub/unix/editors/sam/samx2 - circa 1993, know nothing else about it . . . - kim From sam-fans-owner Wed Jul 25 14:18:12 2001 Received: from highwire.stanford.edu ([171.66.121.166]) by hawkwind.utcs.utoronto.ca with SMTP id <45367>; Wed, 25 Jul 2001 14:16:46 -0500 Received: from highwire.stanford.edu (highwire.stanford.edu [171.66.121.166]) by highwire.stanford.edu (8.10.1/HIGHWIRE2.0) with ESMTP id f6KHOgb05259 for ; Fri, 20 Jul 2001 10:24:42 -0700 (PDT) Message-Id: <200107201724.f6KHOgb05259@highwire.stanford.edu> X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: "sam fans" Dcc: Subject: samterm panic MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5253.995649882.1@highwire.stanford.edu> Date: Fri, 20 Jul 2001 13:24:42 -0500 Sender: jimr@highwire.stanford.edu Cause some folks expressed an interest in when sam panics, I was asked to make a note of it to this list. =) I'm using the new sam with acme data structures, combined with the old samterm. Every once in a while I get a panic. I never really payed attention to if it was sam or samterm. =( I just got a panic from samterm when I: opened a file locked by RCS made a change tried to save got permission denied in another window, checked out the file from RCS tried to save the file again samterm spat out the following and dumped core samterm: host mesg: count 24933 114x 101x 97x te "local_env" ...ignored 74 65 20 22 6c 6f 63 61 6c 5f 65 6e 76 22 a 6 2 samterm: host mesg: count 24933 114x 101x 97x te "local_env" ...ignored 74 65 20 22 6c 6f 63 61 6c 5f 65 6e 76 22 a 6 2 samterm: host mesg: count 24933 114x 101x 97x te "local_env" ...ignored 74 65 20 22 6c 6f 63 61 6c 5f 65 6e 76 22 a 6 2 samterm: host mesg: count 24933 114x 101x 97x te "local_env" ...ignored 74 65 20 22 6c 6f 63 61 6c 5f 65 6e 76 22 a 6 2 type 114 count 24933 samterm:panic: count>DATASIZE: Error 0 I can't reproduce the problem. I took the exact same steps as before, and sam properly warned me that I might be changing an already altered file, and then let me save. Jim From sam-fans-owner Tue Sep 25 17:39:09 2001 Received: from nog.cse.psu.edu ([130.203.12.16]) by hawkwind.utcs.utoronto.ca with SMTP id <51674>; Tue, 25 Sep 2001 17:37:07 -0500 Received: (qmail 20913 invoked by uid 991); 13 Sep 2001 19:34:32 -0000 Message-ID: <20010913193432.20912.qmail@x.nog.bio.cse.psu.edu> Date: Thu, 13 Sep 2001 15:34:32 -0500 To: sam-fans@hawkwind.utcs.toronto.edu cc: 9fans@cse.psu.edu Subject: debugging unix v3 sam vs v2 samterm MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <20908.1000409599.0@bio.cse.psu.edu> Date: Thu, 13 Sep 2001 15:34:32 -0500 From: Scott Schwartz ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20908.1000409599.1@bio.cse.psu.edu> Friends, As you may recall, we've had some problems when using the v3 sam with the v2 samterm, under unix. I've done a bit of debugging, and have a couple of message traces (generated with -DDEBUG) leading up to a crash. Anyone want to help look into these? (The original files were some random source file, and a copy of redhat's termcap.) ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20908.1000409599.2@bio.cse.psu.edu> $ samterm: host mesg: count 26670 115x 46x 104x ,v --> bz_census.h revision 1.1 (locked) done ! ...ignored 2c 76 20 20 2d 2d 3e 20 20 62 7a 5f 63 65 6e 73 75 73 2e 68 a 72 65 76 69 73 69 6f 6e 20 31 2e 31 20 28 6c 6f 63 6b 65 64 29 a 64 6f 6e 65 a 21 a samterm: host mesg: count 26670 115x 46x 104x ,v --> bz_census.h revision 1.1 (locked) done ! ...ignored 2c 76 20 20 2d 2d 3e 20 20 62 7a 5f 63 65 6e 73 75 73 2e 68 a 72 65 76 69 73 69 6f 6e 20 31 2e 31 20 28 6c 6f 63 6b 65 64 29 a 64 6f 6e 65 a 21 a samterm: host mesg: count 26670 115x 46x 104x ,v --> bz_census.h revision 1.1 (locked) done ! ...ignored 2c 76 20 20 2d 2d 3e 20 20 62 7a 5f 63 65 6e 73 75 73 2e 68 a 72 65 76 69 73 69 6f 6e 20 31 2e 31 20 28 6c 6f 63 6b 65 64 29 a 64 6f 6e 65 a 21 a samterm: host mesg: count 26670 115x 46x 104x ,v --> bz_census.h revision 1.1 (locked) done ! ...ignored 2c 76 20 20 2d 2d 3e 20 20 62 7a 5f 63 65 6e 73 75 73 2e 68 a 72 65 76 69 73 69 6f 6e 20 31 2e 31 20 28 6c 6f 63 6b 65 64 29 a 64 6f 6e 65 a 21 a type 115 count 26670 samterm:panic: count>DATASIZE: Success ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20908.1000409599.3@bio.cse.psu.edu> out: Hversion out: 2 out: Hnewname out: 0 out: Hmovname out: 11 out: bz_census.c in: Tversion in: 0 in: Tstartcmdfile in: 134601792 out: Hnewname out: 1 out: Hbindname out: 134601792 out: Hcurrent out: 1 out: Hmovname out: 7 out: ~~sam~~ out: Hcheck0 out: 1 out: Hack in: Tcheck out: Hcheck out: 1 in: Tack out: Hunlock in: Tstartfile out: Hbindname out: 134711368 out: Hcurrent out: 0 in: 0 out: Hgrow out: 0 out: 2436 out: Hcheck0 out: 0 out: Hcheck0 out: 0 out: Hack in: Trequest in: 0 in: 512 out: Hdata out: 0 out: 0 out: 512 out: #include "util.h" #include "seq.h" #include "bz_all.h" #include "bz_main.h" #include "bz_census.h" in: Tcheck out: Hcheck out: 0 in: Tcheck out: Hcheck out: 0 in: Tack out: Hgrow out: 0 out: 16 out: Hcheck0 out: 1 out: Hack in: Trequest in: 512 in: 512 out: Hdata out: 0 out: 512 out: 512 out: c(census,n,i); } void census_mask_align(align_t *a, int n, uchar *fwd, uchar *rev, census_t *cens in: Tcheck out: Hcheck out: 0 in: Trequest in: 512 in: 512 out: Hdata out: 0 out: 512 out: 0 out: in: Tcheck out: Hcheck out: 0 in: Trequest in: 0 in: 16 out: Hdata out: 1 out: 0 out: 16 out: +. bz_census.c in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 16 out: 16 out: Hunlock in: Trequest in: 1024 in: 512 out: Hdata out: 0 out: 1024 out: 512 out: += len; break; case EDIT_OP_REP: //fprintf(stderr, "%d %d -> ", x, y); for (i=x, j=x+len in: Tcheck out: Hcheck out: 0 in: Trequest in: 1536 in: 512 out: Hdata out: 0 out: 1536 out: 512 out: ensus_mask_interval(int n, uchar *fwd, uchar *rev, int a, int z, census_t census[], int k) { int i in: Tcheck out: Hcheck out: 0 in: Trequest in: 2048 in: 388 out: Hdata out: 0 out: 2048 out: 388 out: =n; ++i) { if (census[i] >= k) fprintf(fp, "%d %d\n", i, census[i]); } fprintf(fp, "}\n") in: Tcheck out: Hcheck out: 0 in: Torigin in: 19 out: Horigin out: 1223 in: Torigin in: 19 out: Horigin out: 696 in: Torigin in: 19 out: Horigin out: 302 in: Torigin in: 18 out: Horigin out: 0 in: Torigin in: 18 out: Horigin out: 0 in: Torigin in: 18 out: Horigin out: 0 in: Torigin in: 29 out: Horigin out: 1909 in: Torigin in: 29 out: Horigin out: 1251 in: Torigin in: 29 out: Horigin out: 527 in: Torigin in: 8 out: Horigin out: 364 in: Torigin in: 8 out: Horigin out: 201 in: Torigin in: 8 out: Horigin out: 76 in: Torigin in: 6 out: Horigin out: 1998 in: Torigin in: 6 out: Horigin out: 1932 in: Tworkfile in: 0 in: 0 in: 0 in: Ttype in: 16 in: /inter out: Hsetdot out: 1178 out: 1183 out: Hmoveto out: 1178 out: Hsetpat out: 5 out: inter out: Hunlock in: Torigin in: 2 out: Horigin out: 1140 in: Tworkfile in: 0 in: 1178 in: 1183 in: Ttype in: 23 in: / out: Hsetdot out: 1547 out: 1552 out: Hmoveto out: 1547 out: Hunlock in: Tworkfile in: 0 in: 1547 in: 1552 in: Ttype in: 25 in: / out: Hsetdot out: 1178 out: 1183 out: Hmoveto out: 1178 out: Hunlock in: Tworkfile in: 0 in: 1178 in: 1183 in: Ttype in: 27 in: / out: Hsetdot out: 1547 out: 1552 out: Hmoveto out: 1547 out: Hunlock in: Tworkfile in: 0 in: 2151 in: 2151 in: Ttype in: 2151 in: out: Hdirty out: 0 in: Ttype in: 2152 in: msp_ in: Tworkfile in: 0 in: 2156 in: 2156 in: Ttype in: 29 in: B #inc in: Tcheck out: Hcheck out: 3 in: Trequest in: 512 in: 512 out: Hdata out: 3 out: 512 out: 512 out: len, pos1, pos2; score_t score, cum_score; int filter; } msp_t; typedef struct msp_table { int in: Tcheck out: Hcheck out: 3 in: Trequest in: 1024 in: 450 out: Hdata out: 3 out: 1024 out: 450 out: bt, ss_t ss, int X, int K, int T); void blast_table_free(blast_table_t *bt); void msp_free_table(m in: Tcheck out: Hcheck out: 3 in: Tworkfile in: 3 in: 646 in: 646 in: Tdclick out: Hsetdot out: 643 out: 654 out: Hunlockfile out: 3 in: Tworkfile in: 0 in: 2156 in: 2156 in: Ttype in: 2156 in: table_t *census_intervals() in: Ttype in: 2184 in: { in: Ttype in: 2186 in: } in: Twrite in: 0 out: Hclean out: 0 out: Hgrowdata out: 64 out: 19 out: 19 out: bz_census.c: #2473 out: Hcheck0 out: 1 out: Hack in: Torigin in: 2 out: Horigin out: 64 in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 83 out: 83 out: Hunlock in: Tworkfile in: 0 in: 1703 in: 1703 in: Tworkfile in: 0 in: 1873 in: 1873 in: Tworkfile in: 0 in: 1931 in: 1931 in: Tworkfile in: 0 in: 1932 in: 1932 in: Tworkfile in: 0 in: 2006 in: 2006 in: Tworkfile in: 0 in: 2182 in: 2182 in: Ttype in: 2182 in: uchar census[], int n out: Hdirty out: 0 in: Tworkfile in: 0 in: 2206 in: 2206 in: Torigin in: 20 out: Horigin out: 1291 in: Torigin in: 20 out: Horigin out: 734 in: Torigin in: 20 out: Horigin out: 304 in: Torigin in: 32 out: Horigin out: 0 in: Ttype in: 2206 in: in: Ttype in: 2207 in: in: Tworkfile in: 0 in: 2273 in: 2493 in: Tsnarf in: Tworkfile in: 0 in: 2207 in: 2207 in: Tpaste in: 2207 out: Hgrow out: 2207 out: 220 out: Hcheck0 out: 0 out: Hack in: Trequest in: 2207 in: 220 out: Hdata out: 0 out: 2207 out: 220 out: int i=0, j=0, k; int in = 1; for (k=0; k 2) { print_align_header(sf1, sf2, ss, &gs, K, L); print_msp_l in: Tcheck out: Hcheck out: 4 in: Trequest in: 3276 in: 512 out: Hdata out: 4 out: 3276 out: 512 out: *argv[]) { SEQ *sf1, *sf2; uchar *rf1; blast_table_t *bt; gap_scores_t gs; int W, X, Y, K, L, in: Tcheck out: Hcheck out: 4 in: Tworkfile in: 4 in: 3083 in: 3089 in: Tsnarf in: Tsnarf in: Tsnarf in: Tsnarf in: Tsnarf in: Tworkfile in: 4 in: 3160 in: 3160 in: Ttype in: 3160 in: out: Hdirty out: 4 in: Tworkfile in: 4 in: 3161 in: 3161 in: Ttype in: 3161 in: in: Tworkfile in: 4 in: 2941 in: 2941 in: Ttype in: 2941 in: ; in: Tworkfile in: 4 in: 2945 in: 2946 in: Tworkfile in: 4 in: 2945 in: 2945 in: Ttype in: 2945 in: a in: Tworkfile in: 4 in: 2942 in: 2942 in: Ttype in: 2942 in: in: Ttype in: 2943 in: msp_table_t *m; in: Tworkfile in: 4 in: 3103 in: 3103 in: Ttype in: 3103 in: m = in: Tworkfile in: 4 in: 3187 in: 3187 in: Tworkfile in: 4 in: 3107 in: 3107 in: Tcut in: 3106 in: 3107 in: Tcut in: 3105 in: 3106 in: Tcut in: 3104 in: 3105 in: Tcut in: 3103 in: 3104 in: Tworkfile in: 4 in: 3180 in: 3180 in: Tworkfile in: 4 in: 3183 in: 3183 in: Ttype in: 3183 in: m = census_intervals(census, in: Tworkfile in: 4 in: 3124 in: 3137 in: Tsnarf in: Tworkfile in: 4 in: 3211 in: 3211 in: Tpaste in: 3211 out: Hgrowdata out: 3211 out: 13 out: 13 out: SEQ_LEN(sf1), out: Hcheck0 out: 4 out: Hack in: Tcheck out: Hcheck out: 4 in: Tack out: Hsetdot out: 3211 out: 3224 out: Hunlockfile out: 4 in: Tworkfile in: 4 in: 3211 in: 3211 in: Ttype in: 3211 in: in: Tworkfile in: 4 in: 3225 in: 3225 in: Ttype in: 3225 in: mask_thresh); in: Ttype in: 3240 in: in: Tworkfile in: 4 in: 3187 in: 3187 in: Tcut in: 3186 in: 3187 in: Tcut in: 3185 in: 3186 in: Tcut in: 3184 in: 3185 in: Tcut in: 3183 in: 3184 in: Ttype in: 3183 in: print_ in: Tworkfile in: 4 in: 3244 in: 3244 in: Torigin in: 5 out: Horigin out: 2683 in: Trequest in: 2683 in: 81 out: Hdata out: 4 out: 2683 out: 81 out: p->filter = 1 - p->cum_score; msp_compress(mt); msp_sort_pos1(mt); } in: Tcheck out: Hcheck out: 4 in: Torigin in: 5 out: Horigin out: 2492 in: Trequest in: 2492 in: 191 out: Hdata out: 4 out: 2492 out: 191 out: if (chain == 1 || chain == 2) { msp_t *p; (void)msp_make_chain(mt, bz_flags.G, bz_flags.G, M in: Tcheck out: Hcheck out: 4 in: Torigin in: 5 out: Horigin out: 2423 in: Trequest in: 2423 in: 69 out: Hdata out: 4 out: 2423 out: 69 out: { msp_table_t *mt; mt = blast_search(sf1, sf2, bt, sss, X, K, P); in: Tcheck out: Hcheck out: 4 in: Torigin in: 5 out: Horigin out: 2141 in: Trequest in: 2141 in: 282 out: Hdata out: 4 out: 2141 out: 282 out: /* strand1 -- process one sequence from the second file in one orientation */ static void strand1(S in: Tcheck out: Hcheck out: 4 in: Torigin in: 5 out: Horigin out: 2057 in: Trequest in: 2057 in: 84 out: Hdata out: 4 out: 2057 out: 84 out: substitutions*bz_flags.R : -substitutions*scale*ss[(uchar)'A'][(uchar)'A']); } in: Tcheck out: Hcheck out: 4 in: Tworkfile in: 4 in: 2943 in: 2943 in: Tdclick out: Hsetdot out: 2943 out: 2961 out: Hunlockfile out: 4 in: Tsnarf in: Tcut in: 2943 in: 2961 in: Tworkfile in: 4 in: 3015 in: 3015 in: Ttype in: 3015 in: { in: Ttype in: 3017 in: in: Tworkfile in: 4 in: 3067 in: 3067 in: Ttype in: 3067 in: in: Tworkfile in: 4 in: 3091 in: 3091 in: Ttype in: 3091 in: in: Tworkfile in: 4 in: 3172 in: 3172 in: Ttype in: 3172 in: in: Tworkfile in: 4 in: 3231 in: 3231 in: Tworkfile in: 4 in: 3234 in: 3234 in: Ttype in: 3234 in: } in: Twrite in: 4 out: Hclean out: 4 out: Hgrowdata out: 255 out: 17 out: 17 out: bz_main.c: #5860 out: Hcheck0 out: 1 out: Hack in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 272 out: 272 out: Hunlock in: Tworkfile in: 4 in: 3235 in: 3235 in: Tworkfile in: 4 in: 3231 in: 3231 in: Tworkfile in: 4 in: 3178 in: 3178 in: Tworkfile in: 4 in: 3231 in: 3231 in: Ttype in: 3231 in: out: Hdirty out: 4 in: Tworkfile in: 4 in: 3232 in: 3232 in: Tdclick out: Hsetdot out: 3170 out: 3233 out: Hunlockfile out: 4 in: Tworkfile in: 4 in: 3232 in: 3232 in: Tworkfile in: 4 in: 3177 in: 3177 in: Tworkfile in: 4 in: 3092 in: 3092 in: Tworkfile in: 4 in: 3016 in: 3016 in: Ttype in: 3016 in: in: Ttype in: 3017 in: int n; in: Tworkfile in: 4 in: 3102 in: 3102 in: Ttype in: 3102 in: n = in: Tworkfile in: 4 in: 3183 in: 3183 in: Ttype in: 3183 in: in: Ttype in: 3184 in: if (n) printf(" x %d\n", n); in: Tworkfile in: 4 in: 3219 in: 3219 in: Tdclick out: Hunlockfile out: 4 in: Tworkfile in: 4 in: 3184 in: 3184 in: Tworkfile in: 4 in: 3217 in: 3217 in: Tdclick out: Hsetdot out: 3217 out: 3280 out: Hunlockfile out: 4 in: Tsnarf in: Tcut in: 3217 in: 3280 in: Tworkfile in: 4 in: 3187 in: 3220 in: Tworkfile in: 4 in: 3187 in: 3194 in: Tsnarf in: Tcut in: 3187 in: 3194 in: Tworkfile in: 4 in: 3227 in: 3227 in: Tdclick out: Hsetdot out: 3216 out: 3231 out: Hunlockfile out: 4 in: Tworkfile in: 4 in: 3191 in: 3191 in: Twrite in: 4 out: Hclean out: 4 out: Hgrowdata out: 272 out: 17 out: 17 out: bz_main.c: #5838 out: Hcheck0 out: 1 out: Hack in: Torigin in: 2 out: Horigin out: 272 in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 289 out: 289 out: Hunlock in: Tworkfile in: 0 in: 2445 in: 2445 in: Ttype in: 289 in: /mask_ali out: Hsetdot out: 543 out: 551 out: Hmoveto out: 543 out: Hsetpat out: 8 out: mask_ali out: Hunlock in: Torigin in: 2 out: Horigin out: 530 in: Tworkfile in: 0 in: 534 in: 534 in: Tdclick out: Hsetdot out: 531 out: 535 out: Hunlockfile out: 0 in: Tsnarf in: Tcut in: 531 in: 535 out: Hdirty out: 0 in: Ttype in: 531 in: int in: Tworkfile in: 0 in: 638 in: 638 in: Ttype in: 638 in: in: Ttype in: 639 in: int cnt; in: Tcut in: 648 in: 649 in: Tworkfile in: 0 in: 648 in: 648 in: Tworkfile in: 0 in: 665 in: 665 in: Ttype in: 665 in: in: Tworkfile in: 0 in: 666 in: 666 in: Ttype in: 666 in: in: Ttype in: 667 in: cnt = 0; in: Tworkfile in: 0 in: 1186 in: 1186 in: Ttype in: 1186 in: cnt += in: Tworkfile in: 0 in: 1637 in: 1637 in: Tdclick out: Hsetdot out: 1637 out: 1643 out: Hunlockfile out: 0 in: Tworkfile in: 0 in: 1558 in: 1558 in: Tdclick out: Hsetdot out: 1557 out: 1561 out: Hunlockfile out: 0 in: Tsnarf in: Tcut in: 1557 in: 1561 in: Ttype in: 1557 in: int in: Tworkfile in: 0 in: 1663 in: 1663 in: Ttype in: 1663 in: int cnt; in: Ttype in: 1673 in: in: Ttype in: 1674 in: cnt = 0; in: Tworkfile in: 0 in: 1973 in: 1973 in: Ttype in: 1973 in: in: Ttype in: 1974 in: ++cnt; in: Tworkfile in: 0 in: 1990 in: 1990 in: Ttype in: 1990 in: in: Ttype in: 1991 in: return cnt; in: Tworkfile in: 0 in: 1569 in: 1569 in: Tdclick out: Hsetdot out: 1561 out: 1581 out: Hunlockfile out: 0 in: Tlook in: 1561 in: 1581 out: Hsetdot out: 1193 out: 1213 out: Hmoveto out: 1193 out: Hunlock in: Torigin in: 2 out: Horigin out: 1160 in: Tworkfile in: 0 in: 1435 in: 1435 in: Ttype in: 1435 in: in: Ttype in: 1436 in: return cnt; in: Torigin in: 17 out: Horigin out: 716 in: Torigin in: 17 out: Horigin out: 377 in: Torigin in: 17 out: Horigin out: 76 in: Tworkfile in: 0 in: 1448 in: 1448 in: Ttype in: 299 in: B bz_census.h out: Hnewname out: 5 out: Hmovname out: 11 out: bz_census.h out: Hgrowdata out: 313 out: 16 out: 16 out: -. bz_census.h out: Hcheck0 out: 1 out: Hack in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 329 out: 329 out: Hcurrent out: 5 out: Hunlock in: Tstartfile out: Hbindname out: 134734872 out: Hcurrent out: 5 in: 5 out: Hgrow out: 0 out: 425 out: Hcheck0 out: 5 out: Hmoveto out: 0 out: Hunlock in: Trequest in: 0 in: 425 out: Hdata out: 5 out: 0 out: 425 out: #ifndef BZ_CENSUS_H #define BZ_CENSUS_H typedef unsigned char census_t; void msp_census(census_t ce in: Tcheck out: Hcheck out: 5 in: Tworkfile in: 5 in: 212 in: 212 in: Tworkfile in: 5 in: 133 in: 133 in: Tdclick out: Hsetdot out: 132 out: 136 out: Hunlockfile out: 5 in: Tsnarf in: Tcut in: 132 in: 136 out: Hdirty out: 5 in: Ttype in: 132 in: int in: Tworkfile in: 5 in: 229 in: 229 in: Tdclick out: Hsetdot out: 228 out: 232 out: Hunlockfile out: 5 in: Tsnarf in: Tcut in: 228 in: 232 in: Ttype in: 228 in: int in: Tworkfile in: 5 in: 423 in: 423 in: Tworkfile in: 4 in: 3191 in: 3191 in: Ttype in: 329 in: X/'/ w out: Hclean out: 0 out: Hcurrent out: 5 out: Hgrowdata out: 336 out: 47 out: 47 out: bz_census.c: #2799 ?can't create "bz_census.h" out: Hcheck0 out: 1 out: Hack in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 383 out: 383 out: Hsetpat out: 1 out: ' out: Hunlock in: Torigin in: 2 out: Horigin out: 355 in: Ttype in: 383 in: !co -l in: Tdclick out: Hsetdot out: 370 out: 379 out: Hunlockfile out: 1 in: Tdclick out: Hsetdot out: 370 out: 381 out: Hunlockfile out: 1 in: Tworkfile in: 5 in: 423 in: 423 in: Tsend out: Hsnarflen out: Hgrowdata out: 390 out: 12 out: 12 out: bz_census.h out: Hcheck0 out: 1 out: Hack in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 402 out: 402 out: Hgrow out: 402 out: 65 out: Hcheck0 out: 1 out: Hack in: Trequest in: 402 in: 65 out: Hdata out: 1 out: 402 out: 65 out: RCS/bz_census.h,v --> bz_census.h revision 1.1 (locked) done ! in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 467 out: 467 out: Hunlock in: Tworkfile in: 5 in: 423 in: 423 in: Ttype in: 467 in: X w ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20908.1000409599.4@bio.cse.psu.edu> $ type 117 samterm:panic: rcv unknown: Success ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20908.1000409599.5@bio.cse.psu.edu> out: Hversion out: 2 in: Tversion in: 0 in: Tstartcmdfile in: 134601792 out: Hnewname out: 0 out: Hbindname out: 134601792 out: Hcurrent out: 0 out: Hmovname out: 7 out: ~~sam~~ out: Hcheck0 out: 0 out: Hack in: Tcheck out: Hcheck out: 0 in: Tack out: Hunlock in: Ttype in: 0 in: B /tmp/foo out: Hnewname out: 1 out: Hmovname out: 8 out: /tmp/foo out: Hgrow out: 11 out: 13 out: Hcheck0 out: 0 out: Hack in: Trequest in: 11 in: 13 out: Hdata out: 0 out: 11 out: 13 out: -. /tmp/foo in: Tcheck out: Hcheck out: 0 in: Tack out: Hsetdot out: 24 out: 24 out: Hcurrent out: 1 out: Hunlock in: Tstartfile out: Hbindname out: 134714464 out: Hcurrent out: 1 in: 1 out: Hgrow out: 0 out: 625272 out: Hcheck0 out: 1 out: Hmoveto out: 0 out: Hunlock in: Trequest in: 0 in: 512 out: Hdata out: 1 out: 0 out: 512 out: ######## TERMINAL TYPE DESCRIPTIONS SOURCE FILE # # Version 10.2.7 # $Date: 2001/08/28 03:18:20 $ # in: Tcheck out: Hcheck out: 1 in: Trequest in: 512 in: 512 out: Hdata out: 1 out: 512 out: 512 out: tware such as screen-oriented editors. # # Other terminfo and termcap files exist, supported by var in: Tcheck out: Hcheck out: 1 in: Trequest in: 1024 in: 512 out: Hdata out: 1 out: 1024 out: 512 out: o versions. # # Pointers to related resources (including the ncurses distribution) may # be found a in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 205 in: 569 in: Tsnarf in: Tcut in: 205 in: 569 out: Hdirty out: 1 in: Trequest in: 1172 in: 512 out: Hdata out: 1 out: 1172 out: 512 out: n a Japanese-processing environment using EUC/Japanese or Shift-JIS, # C1 characters are considered in: Tcheck out: Hcheck out: 1 in: Ttype in: 205 in: in: Tworkfile in: 1 in: 205 in: 763 in: Tsnarf in: Tcut in: 205 in: 763 in: Trequest in: 1127 in: 512 out: Hdata out: 1 out: 1127 out: 512 out: rses suite; it differs from stock (System V-compatible) terminfo only # in that it admits a group o in: Tcheck out: Hcheck out: 1 in: Ttype in: 205 in: in: Tworkfile in: 1 in: 116 in: 585 in: Tsnarf in: Tcut in: 116 in: 585 in: Trequest in: 1171 in: 512 out: Hdata out: 1 out: 1171 out: 512 out: tering leaves in the OT capabilities under their # original termcap names. All translated entries in: Tcheck out: Hcheck out: 1 in: Ttype in: 116 in: in: Tworkfile in: 1 in: 70 in: 1073 in: Tsnarf in: Tcut in: 70 in: 1073 in: Trequest in: 681 in: 512 out: Hdata out: 1 out: 681 out: 512 out: in the 4.4BSD Unix Programmer's Manual. Be aware that 4.4BSD # curses has been declared obsolete in: Tcheck out: Hcheck out: 1 in: Trequest in: 1193 in: 512 out: Hdata out: 1 out: 1193 out: 512 out: urther note: older versions of this file were often installed with an editor # script (reorder) tha in: Tcheck out: Hcheck out: 1 in: Trequest in: 1705 in: 512 out: Hdata out: 1 out: 1705 out: 512 out: or their hardware # (notably DEC and Wyse). # # A detailed change history is included at the end of in: Tcheck out: Hcheck out: 1 in: Ttype in: 70 in: in: Tworkfile in: 1 in: 1143 in: 1673 in: Tsnarf in: Tcut in: 1143 in: 1673 in: Tworkfile in: 1 in: 455 in: 455 in: Tpaste in: 455 out: Hgrow out: 455 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 455 in: 512 out: Hdata out: 1 out: 455 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 455 out: 985 out: Hunlockfile out: 1 in: Trequest in: 967 in: 18 out: Hdata out: 1 out: 967 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 763 in: 763 in: Tpaste in: 763 out: Hgrow out: 763 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 763 in: 512 out: Hdata out: 1 out: 763 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 763 out: 1293 out: Hunlockfile out: 1 in: Trequest in: 1275 in: 18 out: Hdata out: 1 out: 1275 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 160 in: 160 in: Tpaste in: 160 out: Hgrow out: 160 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 160 in: 512 out: Hdata out: 1 out: 160 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 160 out: 690 out: Hunlockfile out: 1 in: Trequest in: 672 in: 18 out: Hdata out: 1 out: 672 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 1448 in: 1448 in: Tpaste in: 1448 out: Hgrow out: 1448 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 1448 in: 512 out: Hdata out: 1 out: 1448 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 1448 out: 1978 out: Hunlockfile out: 1 in: Tworkfile in: 1 in: 619 in: 619 in: Tpaste in: 619 out: Hgrow out: 619 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 619 in: 512 out: Hdata out: 1 out: 619 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 619 out: 1149 out: Hunlockfile out: 1 in: Trequest in: 1131 in: 18 out: Hdata out: 1 out: 1131 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 777 in: 777 in: Tpaste in: 777 out: Hgrow out: 777 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 777 in: 512 out: Hdata out: 1 out: 777 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 777 out: 1307 out: Hunlockfile out: 1 in: Trequest in: 1289 in: 18 out: Hdata out: 1 out: 1289 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 227 in: 227 in: Tpaste in: 227 out: Hgrow out: 227 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 227 in: 512 out: Hdata out: 1 out: 227 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 227 out: 757 out: Hunlockfile out: 1 in: Trequest in: 739 in: 18 out: Hdata out: 1 out: 739 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 1218 in: 1218 in: Tpaste in: 1218 out: Hgrow out: 1218 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 1218 in: 512 out: Hdata out: 1 out: 1218 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 1218 out: 1748 out: Hunlockfile out: 1 in: Tcut in: 1218 in: 1748 in: Tpaste in: 1218 out: Hgrow out: 1218 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 1218 in: 512 out: Hdata out: 1 out: 1218 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 1218 out: 1748 out: Hunlockfile out: 1 in: Tworkfile in: 1 in: 607 in: 607 in: Tpaste in: 607 out: Hgrow out: 607 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 607 in: 512 out: Hdata out: 1 out: 607 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 607 out: 1137 out: Hunlockfile out: 1 in: Trequest in: 1119 in: 18 out: Hdata out: 1 out: 1119 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 377 in: 377 in: Tpaste in: 377 out: Hgrow out: 377 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 377 in: 512 out: Hdata out: 1 out: 377 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 377 out: 907 out: Hunlockfile out: 1 in: Trequest in: 889 in: 18 out: Hdata out: 1 out: 889 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 297 in: 297 in: Tpaste in: 297 out: Hgrow out: 297 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 297 in: 512 out: Hdata out: 1 out: 297 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 297 out: 827 out: Hunlockfile out: 1 in: Trequest in: 809 in: 18 out: Hdata out: 1 out: 809 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 686 in: 686 in: Tpaste in: 686 out: Hgrow out: 686 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 686 in: 512 out: Hdata out: 1 out: 686 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 686 out: 1216 out: Hunlockfile out: 1 in: Trequest in: 1198 in: 18 out: Hdata out: 1 out: 1198 out: 18 out: omes from vendors in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 1075 in: 1075 in: Tpaste in: 1075 out: Hgrow out: 1075 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 1075 in: 512 out: Hdata out: 1 out: 1075 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 1075 out: 1605 out: Hunlockfile out: 1 in: Tworkfile in: 1 in: 1434 in: 1434 in: Tpaste in: 1434 out: Hgrow out: 1434 out: 530 out: Hcheck0 out: 1 out: Hack in: Trequest in: 1434 in: 512 out: Hdata out: 1 out: 1434 out: 512 out: whitespace (such whitespace confuses rdist). # # Further note: older versions of this file were of in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 1434 out: 1964 out: Hunlockfile out: 1 in: Tworkfile in: 1 in: 1434 in: 1964 in: Ttype in: 24 in: w out: Hcurrent out: 1 out: Hgrowdata out: 26 out: 25 out: 25 out: ?can't create "/tmp/foo" out: Hcheck0 out: 0 out: Hack in: Tcheck out: Hcheck out: 0 in: Tack out: Hsetdot out: 51 out: 51 out: Hunlock in: Tworkfile in: 1 in: 1434 in: 1964 in: Ttype in: 51 in: !co -l /tmp/foo out: Hgrow out: 67 out: 59 out: Hcheck0 out: 0 out: Hack in: Trequest in: 67 in: 59 out: Hdata out: 0 out: 67 out: 59 out: /tmp/RCS/foo,v --> /tmp/foo revision 1.1 (locked) done ! in: Tcheck out: Hcheck out: 0 in: Tack out: Hsetdot out: 126 out: 126 out: Hunlock in: Torigin in: 1 out: Horigin out: 97 in: Torigin in: 6 out: Horigin out: 11 in: Tworkfile in: 1 in: 1434 in: 1964 in: Ttype in: 126 in: w out: Hgrow out: 128 out: 56 out: Hcheck0 out: 0 out: Hack in: Trequest in: 128 in: 56 out: Hdata out: 0 out: 128 out: 56 out: ?warning: write might change good version of `/tmp/foo' in: Tcheck out: Hcheck out: 0 in: Tack out: Hsetdot out: 184 out: 184 out: Hunlock in: Tworkfile in: 1 in: 1434 in: 1964 in: Ttype in: 184 in: X w out: Hclean out: 1 out: Hgrowdata out: 188 out: 18 out: 18 out: /tmp/foo: #629772 out: Hcheck0 out: 0 out: Hack in: Tcheck out: Hcheck out: 0 in: Tack out: Hsetdot out: 206 out: 206 out: Hunlock in: Torigin in: 1 out: Horigin out: 128 in: Tworkfile in: 1 in: 207 in: 1079 in: Tworkfile in: 1 in: 517 in: 517 in: Tworkfile in: 1 in: 516 in: 1386 in: Tsnarf in: Tworkfile in: 1 in: 274 in: 274 in: Tpaste in: 274 out: Hdirty out: 1 out: Hgrow out: 274 out: 870 out: Hcheck0 out: 1 out: Hack in: Trequest in: 274 in: 512 out: Hdata out: 1 out: 274 out: 512 out: his should no longer be necessary, as the file is now ordered # roughly by type frequency with ANSI in: Tcheck out: Hcheck out: 1 in: Tack out: Hsetdot out: 274 out: 1144 out: Hunlockfile out: 1 in: Trequest in: 786 in: 358 out: Hdata out: 1 out: 786 out: 358 out: types up front. # # Some information has been m whitespace (such whitespace confuses rdist). # # Fu in: Tcheck out: Hcheck out: 1 in: Tworkfile in: 1 in: 290 in: 290 in: Tdclick out: Hsetdot out: 150 out: 156 out: Hunlockfile out: 0 in: Tdclick out: Hsetdot out: 150 out: 156 out: Hunlockfile out: 0 in: Tdclick out: Hsetdot out: 150 out: 156 out: Hunlockfile out: 0 in: Tdclick out: Hsetdot out: 150 out: 156 out: Hunlockfile out: 0 in: Tworkfile in: 1 in: 290 in: 290 in: Ttype in: 206 in: X w out: Hcurrent out: 1 out: Hgrowdata out: 210 out: 25 out: 25 out: ?can't create "/tmp/foo" out: Hcheck0 out: 0 out: Hack in: Tcheck out: Hcheck out: 0 in: Tack out: Hsetdot out: 235 out: 235 out: Hunlock in: Tworkfile in: 1 in: 290 in: 290 in: Ttype in: 235 in: !co -l /tmp/foo out: Hgrow out: 251 out: 59 out: Hcheck0 out: 0 out: Hack in: Trequest in: 251 in: 59 out: Hdata out: 0 out: 251 out: 59 out: /tmp/RCS/foo,v --> /tmp/foo revision 1.2 (locked) done ! in: Tcheck out: Hcheck out: 0 in: Tack out: Hsetdot out: 310 out: 310 out: Hunlock in: Tworkfile in: 1 in: 290 in: 290 in: Ttype in: 310 in: X/'/ w out: Hgrow out: 317 out: 56 out: Hcheck0 out: 0 out: Hack in: Trequest in: 317 in: 56 out: Hdata out: 0 out: 317 out: 56 out: ?warning: write might change good version of `/tmp/foo' in: Tcheck out: Hcheck out: 0 in: Tack out: Hsetdot out: 373 out: 373 out: Hsetpat out: 1 out: ' out: Hunlock in: Torigin in: 2 out: Horigin out: 317 in: Tworkfile in: 1 in: 290 in: 290 in: Ttype in: 373 in: w ------- =_aaaaaaaaaa0-- From sam-fans-owner Wed Dec 12 02:21:44 2001 Received: from galapagos.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.toronto.edu with SMTP id <58491>; Wed, 12 Dec 2001 02:20:25 -0500 Received: (qmail 23179 invoked by uid 991); 11 Dec 2001 21:50:14 -0000 Message-ID: <20011211215014.23178.qmail@g.bio.cse.psu.edu> From: "Scott Schwartz" Date: Tue, 11 Dec 2001 16:50:14 -0500 To: 9fans@cse.psu.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: libXg patch For those using libXg, if you want it to work with X11 unicode fonts (and there are a few these days) with more than 32K characters, don't forget to change libg.h to suit: ; diff libg.h.old libg.h 97,102c97,102 < short minrow; /* first character row in font (for X subfonts) */ < short mincol; /* first character col in font (for X subfonts) */ < short minchar; /* first char code in subfont */ < short maxchar; /* last char code in subfont */ < short width; /* number of chars in row */ < short n; /* number of chars in font */ --- > int minrow; /* first character row in font (for X subfonts) */ > int mincol; /* first character col in font (for X subfonts) */ > int minchar; /* first char code in subfont */ > int maxchar; /* last char code in subfont */ > int width; /* number of chars in row */ > int n; /* number of chars in font */