From dl-tkrat@catspoiler.org Mon Apr 7 05:11:20 2003 From: dl-tkrat@catspoiler.org (Don Lewis) Date: Sun, 6 Apr 2003 21:11:20 -0700 (PDT) Subject: speeding up folder loading Message-ID: <200304070411.h374BK8W056696@gw.catspoiler.org> --0-1804289383-1049688686=:4210 Content-Type: TEXT/plain; charset=us-ascii I've got some rather large mail folders and got tired of waiting for them to load, so I patched the tkrat code to speed it up a bit. One of my larger folders lives on an imap server and contains about 43K messages. On an AMD Athlon XP 1900+ box with 1 GB of RAM running FreeBSD, it was taking about 20 minutes to load the folder. It took me a while to get code profiling working, but before I got that far, I observed that a large fraction of the time was being burned by syscalls, and when I ran truss on the process, I saw large numbers of accesses to the /etc/passwd database. I tracked this down to an uncondtional call to getpwuid() in RatGetCurrent(), which gets called twice by RatAddressIsMeRole(), which is called N times for each message in the folder by RatAddressIsMe(), where N is the number of roles. The getpwuid(getuid()) pair is pretty costly, because there is a system call to get the uid, and then getpwuid may have to look at something like /etc/nsswitch.conf and then may look at /etc/passwd or it may go off to the network to query a NIS database, etc. Only the the RAT_HOST and RAT_PERSONAL queries used information from the password database, and this information was already saved in "env" by RatAppInit(). Simply by getting rid of the getpwuid() calls in RatGetCurrent() and instead getting the information from "env" when requested, I was able to decrease the folder load time from 20 minutes to 10 minutes. I also observed large numbers of calls to the setitimer() syscall, which I tracked down to calls to alarm() in the c-client code. It turns out that rfc822_parse_adrlist() is horribly expensive because it calls fs_get() to allocate memory. fs_get() calls mail_parameters() to find the blocknotify function pointer, and mail_parameters() ends up calling all the mailbox drivers in case they want to specify their own blocking function (which they don't), and it finally ends up returning a pointer to mm_blocknotify(), which fs_get() calls twice to disable and enable the timer to protect the call to ckalloc(). Since each call to RatAddressIsMeRole() results in a call to rfc822_parse_adrlist(), this overhead adds up pretty quickly. Rather than trying to optimize this code, I decided a better strategy would be to build a hash table keyed by all the role email addresses. Instead of comparing the address to each role address, RatAddressIsMe() would only have to do a hash lookup to see if the From: address on each message is in the table. The tricky bit was building the hash table only when necessary, which I did by tracing changes to the role preferences variables and using that to trigger the database rebuild. It also looked useful to enhance RatGetCurrent() to return the complete email address, rather than making two calls to get the two parts and then having to paste them together. After these changes, the folder load time dropped down to about two minutes, of which one minute is spent on sorting the folder by subject and date. In the mean time, I managed to get code profiling working, so I'm planning to look at speeding up folder sorting, since one minute sort times are pretty painful if new messages arrive every couple of minutes. The attached patch is versus tkrat-2.1. --0-1804289383-1049688686=:4210 Content-Type: TEXT/plain; name=fast_folder_load Content-Disposition: attachment; filename=fast_folder_load --- lib/rat.h.orig Sat Apr 5 01:24:08 2003 +++ lib/rat.h Sun Apr 6 14:25:11 2003 @@ -156,7 +156,7 @@ * Current data */ typedef enum { - RAT_HOST, RAT_MAILBOX, RAT_PERSONAL, RAT_HELO + RAT_HOST, RAT_MAILBOX, RAT_EMAILADDRESS, RAT_PERSONAL, RAT_HELO } RatCurrentType; /* --- lib/ratAddress.c.orig Sat Apr 5 00:12:00 2003 +++ lib/ratAddress.c Sun Apr 6 20:25:46 2003 @@ -66,6 +66,19 @@ } ParseState; /* + * These tables contain the email addresses for each of my roles. + */ +static Tcl_HashTable myRoles1, myRoles2, *myRolesCurrent, *myRolesPrevious; +/* + * This table contains my default email address and all my role addresses. + */ +static Tcl_HashTable myAddressesTable; +/* + * The default email address for the !trustUser case + */ +static char *myDefaultEmailAddress; + +/* * Internal functions */ static int AddressClean(Tcl_Obj *aPtr); @@ -74,7 +87,6 @@ static char *mem_store; #endif /* MEM_DEBUG */ -static int RatAddressIsMeRole(Tcl_Interp *interp, ADDRESS *adrPtr, char *role); static void RatExpandAlias(Tcl_Interp *interp, Tcl_DString *list, AliasExpand *ea); @@ -361,38 +373,237 @@ /* *---------------------------------------------------------------------- * - * RatAddressIsMeInRole -- + * RatRoleWatcher -- + * + * Watch for changes to role email addresses and update the current + * role address table. * - * Checks if the address points to me in the given role * * Results: - * If it is then non zero is returned otherwise zero. + * None. * * Side effects: + * See above. + * + * + *---------------------------------------------------------------------- + */ +static void +RatRebuildMyAddressTable(Tcl_HashTable *myaddresstable) +{ + Tcl_HashEntry *hPtr, *entryPtr; + Tcl_HashSearch search; + int new; + char *emailaddress; + + Tcl_DeleteHashTable(myaddresstable); + /* + * Walk current role address table to find all the email addresses + * and add entries for each to the the address table. + */ + Tcl_InitHashTable(myaddresstable, TCL_STRING_KEYS); + for (hPtr = Tcl_FirstHashEntry(myRolesCurrent, &search); + hPtr != NULL; hPtr = Tcl_NextHashEntry(&search)) { + emailaddress = Tcl_GetHashValue(hPtr); + entryPtr = Tcl_CreateHashEntry(myaddresstable, emailaddress, &new); + Tcl_SetHashValue(entryPtr, "role"); + } + entryPtr = Tcl_CreateHashEntry(myaddresstable, myDefaultEmailAddress, &new); + Tcl_SetHashValue(entryPtr, "me"); +} + +/* + *---------------------------------------------------------------------- + * + * RatRoleWatcher -- + * + * Watch for changes to role email addresses and update the current + * role address table. + * + * MyAddressTable is rebuilt if clientData != NULL + * + * + * Results: * None. * + * Side effects: + * See above. + * * *---------------------------------------------------------------------- */ -static int -RatAddressIsMeRole(Tcl_Interp *interp, ADDRESS *adrPtr, char *role) +static char * +RatRoleWatcher(ClientData clientData, Tcl_Interp *interp, + char *name1, CONST84 char *name2, int flags) { - char *from, *host; - ADDRESS *a = NULL; + char role[1024], *comma; + char *emailaddress, *oldaddress, *cp; + int new; + Tcl_HashEntry *entryPtr; - host = cpystr(RatGetCurrent(interp, RAT_HOST, role)); - from = cpystr(RatGetCurrent(interp, RAT_MAILBOX, role)); - rfc822_parse_adrlist(&a, from, host); - ckfree(from); - ckfree(host); - if (a && adrPtr->mailbox && adrPtr->host - && !strcasecmp(a->mailbox, adrPtr->mailbox) - && !strcasecmp(a->host, adrPtr->host)) { - mail_free_address(&a); - return 1; + if (flags & TCL_INTERP_DESTROYED) { + return NULL; + } + + strlcpy(role, name2, sizeof(role)); + comma = strchr(role, ','); + if (comma) { + *comma = '\0'; + } + emailaddress = cpystr(RatGetCurrent(interp, RAT_EMAILADDRESS, role)); + for (cp = emailaddress; *cp; cp++) { + *cp = tolower((unsigned char) *cp); + } + entryPtr = Tcl_CreateHashEntry(myRolesCurrent, role, &new); + if (new == 0) { + oldaddress = Tcl_GetHashValue(entryPtr); + if (oldaddress) { + ckfree(oldaddress); + } + } + Tcl_SetHashValue(entryPtr, emailaddress); + + if (clientData) { + RatRebuildMyAddressTable(clientData); + } + + return NULL; +} + +/* + *---------------------------------------------------------------------- + * + * RatRoleListWatcher -- + * + * Update myAddressesTable whenever the roles option is changed. + * + * Results: + * None. + * + * Side effects: + * See above. + * + * + *---------------------------------------------------------------------- + */ +static char* +RatRoleListWatcher(ClientData clientData, Tcl_Interp *interp, + char *name1, CONST84 char *name2, int flags) +{ + Tcl_Obj **objv, *oPtr; + Tcl_CmdInfo cmdInfo; + Tcl_HashTable *myRolesTmp; + Tcl_HashEntry *entryPtr; + Tcl_HashSearch search; + int objc, i, new; + char *role, *emailaddress; + char buf[1024]; + + if (flags & TCL_INTERP_DESTROYED) { + return NULL; } - mail_free_address(&a); - return 0; + + /* + * The role list has changed, so swap the the role tables so that + * the changes can be found and the new table updated. + */ + myRolesTmp = myRolesCurrent; + myRolesCurrent = myRolesPrevious; + myRolesPrevious = myRolesTmp; + Tcl_InitHashTable(myRolesCurrent, TCL_STRING_KEYS); + + /* + * Copy entries common to the old an new lists of roles. + * Add email addresses and set up traces on any new roles. + */ + oPtr = Tcl_GetVar2Ex(interp, name1, name2, flags & TCL_GLOBAL_ONLY); + if (oPtr != NULL) { + Tcl_ListObjGetElements(interp, oPtr, &objc, &objv); + for (i=0; imailbox == NULL) || + (adrPtr->host == NULL)) { - if (adrPtr == NULL) { return 0; } - if (RatAddressIsMeRole(interp, adrPtr, "")) { - return 1; + snprintf(buf, sizeof(buf), "%s@%s", adrPtr->mailbox, adrPtr->host); + for (cp = buf; *cp; cp++) { + *cp = tolower((unsigned char) *cp); } - if (trustUser) { - oPtr = Tcl_GetVar2Ex(interp, "option", "roles", TCL_GLOBAL_ONLY); - Tcl_ListObjGetElements(interp, oPtr, &objc, &objv); - for (i=0; imailbox?adrPtr->mailbox:""); - Tcl_DStringAppendElement(&cmd,adrPtr->host?adrPtr->host:""); - Tcl_DStringAppendElement(&cmd, - adrPtr->personal ? adrPtr->personal : ""); - Tcl_DStringAppendElement(&cmd,adrPtr->adl?adrPtr->adl:""); - if (TCL_OK == Tcl_Eval(interp, Tcl_DStringValue(&cmd)) - && (oPtr = Tcl_GetObjResult(interp)) - && TCL_OK == Tcl_GetBooleanFromObj(interp, oPtr, &isMe)) { - Tcl_DStringFree(&cmd); - return isMe; - } - Tcl_DStringFree(&cmd); - } + entryPtr = Tcl_FindHashEntry(&myAddressesTable, buf); + if (entryPtr == NULL) { + return 0; + } + + cp = (char *)Tcl_GetHashValue(entryPtr); + if (cp[0] == 'm' || (trustUser && (cp[0] == 'r'))) { + return 1; } - return 0; } /* --- lib/ratAppInit.c.orig Thu Apr 3 22:28:13 2003 +++ lib/ratAppInit.c Sun Apr 6 16:25:53 2003 @@ -188,7 +188,7 @@ static int RatAppInit(Tcl_Interp *interp) { - struct passwd *pwPtr; + struct passwd *pwPtr = NULL; double tcl_version; Tcl_Obj *oPtr; char *c, tmp[1024]; @@ -286,11 +286,13 @@ * If not then we initialize them. */ if (!Tcl_GetVar2(interp, "env", "USER", TCL_GLOBAL_ONLY)) { - pwPtr = getpwuid(getuid()); + if (pwPtr == NULL) + pwPtr = getpwuid(getuid()); Tcl_SetVar2(interp, "env", "USER", pwPtr->pw_name, TCL_GLOBAL_ONLY); } if (!Tcl_GetVar2(interp, "env", "GECOS", TCL_GLOBAL_ONLY)) { - pwPtr = getpwuid(getuid()); + if (pwPtr == NULL) + pwPtr = getpwuid(getuid()); strlcpy(tmp, pwPtr->pw_gecos, sizeof(tmp)); if ((c = strchr(tmp, ','))) { *c = '\0'; @@ -298,13 +300,15 @@ Tcl_SetVar2(interp, "env", "GECOS", tmp, TCL_GLOBAL_ONLY); } if (!Tcl_GetVar2(interp, "env", "HOME", TCL_GLOBAL_ONLY)) { - pwPtr = getpwuid(getuid()); + if (pwPtr == NULL) + pwPtr = getpwuid(getuid()); Tcl_SetVar2(interp, "env", "HOME", pwPtr->pw_dir, TCL_GLOBAL_ONLY); } if (!Tcl_GetVar2(interp, "env", "MAIL", TCL_GLOBAL_ONLY)) { char buf[1024]; - pwPtr = getpwuid(getuid()); + if (pwPtr == NULL) + pwPtr = getpwuid(getuid()); snprintf(buf, sizeof(buf), "/var/spool/mail/%s", pwPtr->pw_name); Tcl_SetVar2(interp, "env", "MAIL", buf, TCL_GLOBAL_ONLY); } @@ -326,6 +330,8 @@ return TCL_ERROR; } + RatInitMyAddessesTable(interp); + Tcl_InitHashTable(&aliasTable, TCL_STRING_KEYS); /* @@ -423,7 +429,7 @@ ADDRESS *address = NULL; static char buf[1024]; char *result = NULL, *personal, hostbuf[1024], *c; - CONST84 char *host, *from, *uqdom, *helo; + CONST84 char *host, *from, *uqdom, *helo, *mailbox; Tcl_Obj *oPtr; host = Tcl_GetHostName(); @@ -445,7 +451,6 @@ rfc822_parse_adrlist(&address, s, (char*)host); ckfree(s); } - passwdPtr = getpwuid(getuid()); switch (what) { case RAT_HOST: @@ -467,25 +472,42 @@ strlcpy(buf, address->mailbox, sizeof(buf)); result = buf; } else { - result = passwdPtr->pw_name; + result = Tcl_GetVar2(interp, "env", "USER", TCL_GLOBAL_ONLY); + } + break; + + case RAT_EMAILADDRESS: + if (address && address->host) { + host = address->host; + } else { + snprintf(buf, sizeof(buf), "%s,uqa_domain", role); + uqdom = Tcl_GetVar2(interp, "option", buf, TCL_GLOBAL_ONLY); + if (uqdom && 0 < strlen(uqdom)) { + host = uqdom; + } /* else use previous host value */ } + if (address && address->mailbox) { + mailbox = address->mailbox; + } else { + mailbox = Tcl_GetVar2(interp, "env", "USER", TCL_GLOBAL_ONLY); + } + snprintf(buf, sizeof(buf), "%s@%s", mailbox, host); + result = buf; break; case RAT_PERSONAL: if (address && address->personal) { - strlcpy(buf, address->personal, sizeof(buf)); + oPtr = Tcl_NewStringObj(address->personal, -1); } else { - strlcpy(buf, passwdPtr->pw_gecos, sizeof(buf)); - if ((c = strchr(buf, ','))) { - *c = '\0'; - } + oPtr = Tcl_GetVar2Ex(interp, "env", "GECOS", TCL_GLOBAL_ONLY), + Tcl_IncrRefCount(oPtr); } - oPtr = Tcl_NewStringObj(buf, -1); personal = RatEncodeHeaderLine(interp, oPtr, 0); Tcl_DecrRefCount(oPtr); strlcpy(buf, personal, sizeof(buf)); result = buf; break; + case RAT_HELO: snprintf(buf, sizeof(buf), "%s,smtp_helo", role); helo = Tcl_GetVar2(interp, "option", buf, TCL_GLOBAL_ONLY); --0-1804289383-1049688686=:4210-- From dl-tkrat@catspoiler.org Mon Apr 7 08:39:12 2003 From: dl-tkrat@catspoiler.org (Don Lewis) Date: Mon, 7 Apr 2003 00:39:12 -0700 (PDT) Subject: faster subject/sender/date sorting Message-ID: <200304070739.h377dC8W057026@gw.catspoiler.org> --0-1804289383-1049701158=:4804 Content-Type: TEXT/plain; charset=us-ascii Attached is a quick patch to file off the N^2 loop in the subject+date and sender+date case. I'm actually amazed at how much faster the this sort is now. My 43K message folder went from a sort time of a minute or a bit more down to a second or two. It's now too fast for me to time it by watching the "top" display and the performance is now very acceptable. I think the sort could be improved even more by making the sort data persistent and updating it incrementally as new messages arrive. I'm actually more interested in the threaded case, but that's too complicated for me to attack in the time I have available right now. The subject+date sort is OK for my big folders though. If feels like time to declare victory and go to sleep. --0-1804289383-1049701158=:4804 Content-Type: TEXT/plain; name=fast_sort Content-Disposition: attachment; filename=fast_sort --- lib/ratFolder.c.orig Mon Apr 22 21:42:42 2002 +++ lib/ratFolder.c Mon Apr 7 00:04:07 2003 @@ -673,7 +673,9 @@ int i, j, k, pi, pj, snarf, numParm, seen, *tmpPtr, first, last, *p=infoPtr->presentationOrder, needDate=0, needSubject=0, needSender=0, needIds = 0, needSize = 0, - *uniqList, uniqListUsed, *subList, *lengthList; + *uniqList, uniqListUsed, *subList, *lengthList, newEntry; + Tcl_HashTable uniqTable; + Tcl_HashEntry *uniqEntry; SortData *dataPtr, *dPtr; Tcl_Obj *oPtr, *o2Ptr; @@ -996,24 +998,25 @@ * - Finally we build to result array. */ uniqList = (int*)ckalloc(2*infoPtr->number*sizeof(*uniqList)); + Tcl_InitHashTable(&uniqTable, TCL_STRING_KEYS); subList = &uniqList[infoPtr->number]; lengthList = &uniqList[2*infoPtr->number]; for (i=uniqListUsed=0; inumber; i++) { - for (j=0; jsortOrder == SORT_SUBJDATE ? - !strcmp(dataPtr[i].subject, - dataPtr[uniqList[j]].subject) : !strcmp( - dataPtr[i].sender, dataPtr[uniqList[j]].sender)) { - dataPtr[i].nextPtr = dataPtr[uniqList[j]].nextPtr; - dataPtr[uniqList[j]].nextPtr = &dataPtr[i]; - break; - } - } - if (j == uniqListUsed) { + uniqEntry = Tcl_CreateHashEntry(&uniqTable, + infoPtr->sortOrder == SORT_SUBJDATE ? + dataPtr[i].subject : + dataPtr[i].sender, &newEntry); + if (newEntry) { dataPtr[i].nextPtr = NULL; uniqList[uniqListUsed++] = i; + Tcl_SetHashValue(uniqEntry, &dataPtr[i]); + } else { + dPtr = Tcl_GetHashValue(uniqEntry); + dataPtr[i].nextPtr = dPtr->nextPtr; + dPtr->nextPtr = &dataPtr[i]; } } + Tcl_DeleteHashTable(&uniqTable); for (i=0; i Good stuff! Let's hope Martin is willing to add this to the code base. FWIW, I find that sending email has now become much slower than it used to be (before there was the Outgoing folder). It seems like sending copies to the outgoing folder then waits for the initial conversation with the SMTP server is completed before control is given back to the user. I'm hoping that your first patch will correct this. L On 7 Apr, Don Lewis wrote: > Attached is a quick patch to file off the N^2 loop in the subject+date > and sender+date case. I'm actually amazed at how much faster the this > sort is now. My 43K message folder went from a sort time of a minute or > a bit more down to a second or two. It's now too fast for me to time it > by watching the "top" display and the performance is now very > acceptable. > > I think the sort could be improved even more by making the sort data > persistent and updating it incrementally as new messages arrive. > > I'm actually more interested in the threaded case, but that's too > complicated for me to attack in the time I have available right now. The > subject+date sort is OK for my big folders though. > > If feels like time to declare victory and go to sleep. > -- Laurent Duperval Nurse Donna: Do you believe in computer dating? Groucho Marx: Only if the computers really love each other. From maf@tkrat.org Tue Apr 8 08:09:40 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Tue, 8 Apr 2003 09:09:40 +0200 (CEST) Subject: speeding up folder loading Message-ID: <20030408083146.AC2882FDA@tkrat.org> On 6 Apr, Don Lewis wrote: > I've got some rather large mail folders and got tired of waiting for > them to load, so I patched the tkrat code to speed it up a bit. One of This is great. These patches will, with slight modifications, find their way into both 2.1.2 and the cvs trunk version. /MaF From maf@tkrat.org Wed Apr 9 05:54:07 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Wed, 9 Apr 2003 06:54:07 +0200 (CEST) Subject: faster subject/sender/date sorting Message-ID: <20030409053126.E18DE2FCF@tkrat.org> On 7 Apr, laurent.duperval@microcell.ca wrote: > FWIW, I find that sending email has now become much slower than it used to > be (before there was the Outgoing folder). It seems like sending copies to > the outgoing folder then waits for the initial conversation with the SMTP > server is completed before control is given back to the user. I'm hoping > that your first patch will correct this. Unfortunately it will not speed up sending. I'll see what I can do about the sending speed. /MaF From laurent.duperval@microcell.ca Wed May 14 12:37:25 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Wed, 14 May 2003 07:37:25 -0400 (EDT) Subject: Attachments problems Message-ID: <20030514113725.9C07D16BC3@mailserv.microcell.ca> Hi, I recently noticed that all the attachments I send to an Outlook box show up as FOO.ATT Instead of the file name of the attachement (e.g. MyAttachment.doc). Has anyone else ever noticed this? It's causing headaches to other people reading my mail. L -- Laurent Duperval You know that little indestructible black box that is used on planes, why can't they make the whole plane out of the same substance? From maf@tkrat.org Wed May 14 15:25:05 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Wed, 14 May 2003 16:25:05 +0200 (CEST) Subject: Attachments problems Message-ID: <20030514155411.D01762FDA@tkrat.org> On 14 May, laurent.duperval@microcell.ca wrote: > I recently noticed that all the attachments I send to an Outlook box show up > as > > FOO.ATT > > Instead of the file name of the attachement (e.g. MyAttachment.doc). Has This is strange. TkRat does not generate that string so I have noo idea where it somes from. Perhaps somebody is mangling the messages on the way? Another interesting point of data would be to see how outlook encodes attachment names to you. /MaF From ctubutis@yahoo.com Wed May 14 17:05:01 2003 From: ctubutis@yahoo.com (Chris Tubutis) Date: Wed, 14 May 2003 10:05:01 -0600 (MDT) Subject: Attachments problems In-Reply-To: <20030514113725.9C07D16BC3@mailserv.microcell.ca> Message-ID: <200305141605.h4EG51qf024731@nodows.tubutis.lt> > I recently noticed that all the attachments I send to an Outlook box show up > as > > FOO.ATT Is the mail going through any sort of virus-checking software somewhere along the way? I've seen such software do things like this. What happens when you send attachments to yourself? ct From laurent.duperval@microcell.ca Wed May 14 17:31:25 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Wed, 14 May 2003 12:31:25 -0400 (EDT) Subject: Attachments problems Message-ID: <20030514163125.86B6716BC7@mailserv.microcell.ca> On 14 May, Chris Tubutis wrote: > Is the mail going through any sort of virus-checking software somewhere > along the way? I've seen such software do things like this. What happens > when you send attachments to yourself? >=20 It's probably going thru Virus checking stuff. I tested sending the same document with Mozilla and I received it correct.y. I went and did a few tests and this is what I found: - The same file is viewed correctly when sent with Mozilla but not with Tkrat - I noticed that the file that was giving me problems had 8 bit characters in the name - When I send a file that doesn't have an 8 bit character in the name, it seems to be received correctly by Outlook - TkRat via POP3 always interprets the attachment correctly. It's an Outlokk problem (yet again). So it looks like having 8 bit characters in the file name is a no-no. I'm using TkRat 20030213 with Tcl 8.4.1. L --=20 Laurent Duperval Je connais un r=E9m=E8de de bonne femme et de cheval qui est d'une efficaci= t=E9 =E0 casser les vitres dans un rayon de cent m=E8tres! -Alambic Talon From derekn@foolabs.com Wed May 14 18:42:20 2003 From: derekn@foolabs.com (Derek B. Noonburg) Date: Wed, 14 May 2003 10:42:20 -0700 (PDT) Subject: "group move" is very slow Message-ID: <20030514174220.31030.qmail@foolabs.com> I'm seeing odd behavior with the "group move" feature in TkRat 2.1.1. If I move a single message between two folders (using the "move" menu in the left-middle of the TkRat window), it's essentially instantaneous (less than one second). But if I create a group, even with just two messages in it, and then use the group:move menu, it takes a full minute to do the move. Groups with more than two messages are even slower. Oddly, moving a group containing only one message is just as fast as moving a single message without using the group feature. Both folders are on the same IMAP server (I use Courier), running locally on the same host as TkRat. I've seen the exact same behavior talking to this server via ssh from another host. I initially thought it might be a network issue, but it's happening when I run TkRat locally too. The destination folder is large (6000 messages), but like I said, moving individual messages is very fast -- group move is substantially slower than manually doing a whole bunch of individual move operations. - Derek From maf@tkrat.org Wed May 14 18:42:27 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Wed, 14 May 2003 19:42:27 +0200 (CEST) Subject: Attachments problems Message-ID: <20030514174037.A0D4D2FDC@tkrat.org> On 14 May, laurent.duperval@microcell.ca wrote: > - The same file is viewed correctly when sent with Mozilla but not with > Tkrat Could you try to send it (or one like that) to me with both mozilla and TkRat. > - TkRat via POP3 always interprets the attachment correctly. It's an Outlokk > problem (yet again). Not surprising. /MaF From laurent.duperval@microcell.ca Wed May 14 18:46:33 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Wed, 14 May 2003 13:46:33 -0400 (EDT) Subject: Attachments problems Message-ID: <20030514174634.78B5016BCB@mailserv.microcell.ca> --118104092-1726956429-1052934393=:15610 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE On 14 May, maf@tkrat.org wrote: > On 14 May, laurent.duperval@microcell.ca wrote: >> - The same file is viewed correctly when sent with Mozilla but not with >> Tkrat > > Could you try to send it (or one like that) to me with both mozilla and > TkRat. Sure, and everyone gets a copy. If you see weird behaviour with it, report back to the list. This is with tkrat. L -- Laurent Duperval LIEBERMAN'S LAW Everybody lies; but it doesn't matter, since nobody listens. --118104092-1726956429-1052934393=:15610 Content-Type: APPLICATION/X-GZIP; NAME*="iso-8859-1''TestFran%E7ais.txt.gz" Content-Transfer-Encoding: BASE64 Content-Disposition: ATTACHMENT; FILENAME*="iso-8859-1''TestFran%E7ais.txt.gz" H4sICFqAwj4AA1Rlc3RGcmFu52Fpcy50eHQADcqxDYAwDETRniluAmoGYQHH MrIl4qDkkBgfS794xT89FirBiv7cBtpHXDGK7SXohpRu0JGUyDoTB1oQ6jJF aXPffmF+Kj9GAAAA --118104092-1726956429-1052934393=:15610-- From laurent.duperval@microcell.ca Wed May 14 18:48:18 2003 From: laurent.duperval@microcell.ca (Laurent Duperval) Date: Wed, 14 May 2003 13:48:18 -0400 Subject: Attachments problems In-Reply-To: <20030514174037.A0D4D2FDC@tkrat.org> References: <20030514174037.A0D4D2FDC@tkrat.org> Message-ID: <3EC28162.4080606@microcell.ca> This is a multi-part message in MIME format. --------------020208020407010502010403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit maf@tkrat.org wrote: >On 14 May, laurent.duperval@microcell.ca wrote: > > >>- The same file is viewed correctly when sent with Mozilla but not with >> Tkrat >> >> > >Could you try to send it (or one like that) to me with both mozilla and >TkRat. > > And this is with Mozilla. L -- Laurent Duperval LIEBERMAN'S LAW Everybody lies; but it doesn't matter, since nobody listens. --------------020208020407010502010403 Content-Type: application/gzip; name="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" H4sICFqAwj4AA1Rlc3RGcmFu52Fpcy50eHQADcqxDYAwDETRniluAmoGYQHHMrIl4qDkkBgf S794xT89FirBiv7cBtpHXDGK7SXohpRu0JGUyDoTB1oQ6jJFaXPffmF+Kj9GAAAA --------------020208020407010502010403-- From laurent.duperval@microcell.ca Wed May 14 18:50:17 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Wed, 14 May 2003 13:50:17 -0400 (EDT) Subject: Suggestion Message-ID: <20030514175017.C71FE16BC7@mailserv.microcell.ca> Hi, I tried Balsa for a few days this winter and one thing I liked about it was the "Reply to group" option, which I found particularly useful when dealing with mailing lists like TkRat which, by default, send replies to the author, not the list. WOuld this be feasible with TkRat? L -- Laurent Duperval Vous ne voyez pas plus loin que le bout de votre nez qui d'ailleurs obstruerait un tunnel de moyenne importance! -Lefuneste From ctubutis@yahoo.com Wed May 14 19:04:12 2003 From: ctubutis@yahoo.com (Chris Tubutis) Date: Wed, 14 May 2003 12:04:12 -0600 (MDT) Subject: Attachments problems In-Reply-To: <20030514174634.78B5016BCB@mailserv.microcell.ca> Message-ID: <200305141804.h4EI4Cqf025310@nodows.tubutis.lt> > Sure, and everyone gets a copy. If you see weird behaviour with it, report > back to the list. > > This is with tkrat. I get an attachment of type application/x-gzip (142 bytes) with no default filename.... ct From maf@tkrat.org Wed May 14 19:08:54 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Wed, 14 May 2003 20:08:54 +0200 (CEST) Subject: "group move" is very slow Message-ID: <20030514180712.49F6F2FDF@tkrat.org> On 14 May, Derek B. Noonburg wrote: > I'm seeing odd behavior with the "group move" feature in TkRat 2.1.1. Group move should be significantly faster in the current cvs snapshot. /MaF From laurent.duperval@microcell.ca Wed May 14 19:26:22 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Wed, 14 May 2003 14:26:22 -0400 (EDT) Subject: Attachments problems Message-ID: <20030514182623.5908516BC3@mailserv.microcell.ca> On 14 May, Rui Lu=EDs Pires wrote: > What sending method are you using (sendmail, SMTP?) >=20 > I've just sent myself your file using tkrat and did not notice any > problem in keeping the "=E7"... >=20 Are you reading the message with TkRat or with Outlook? I don't have a problem with TkRat, although the file name looks like this: TestFran=C3=A7ais.txt.gz instead of TestFran=E7ais.txt.gz I'm sending via SMTP. L --=20 Laurent Duperval Bourgeois, ne niez pas: le frisson de l'envie chante au fond de votre prunelle! -Le commer=E7ant d'Achille Talon From ctubutis@yahoo.com Wed May 14 19:27:30 2003 From: ctubutis@yahoo.com (Chris Tubutis) Date: Wed, 14 May 2003 12:27:30 -0600 (MDT) Subject: Attachments problems In-Reply-To: <3EC28162.4080606@microcell.ca> Message-ID: <200305141827.h4EIRUqf025470@nodows.tubutis.lt> > And this is with Mozilla. Hmmm... Here is an object of type: application/gzip (140 bytes) with a default filename of TestFrancais.txt.gz except that the 'c' in Francais has a little hook underneath it. I'll bet the filename is somehow not getting encoded correctly and Lookout supplies default names. Just a guess.... ct From rlpires@telin.ugent.be Wed May 14 19:28:51 2003 From: rlpires@telin.ugent.be (=?iso-8859-1?Q?Rui_Lu=EDs_Pires?=) Date: Wed, 14 May 2003 20:28:51 +0200 (CEST) Subject: Attachments problems Message-ID: <200305141828.h4EISpj3020073@kira.skynet.be> On 14 May, Laurent Duperval wrote: > maf@tkrat.org wrote: > >>Could you try to send it (or one like that) to me with both mozilla and >>TkRat. >> >> > And this is with Mozilla. > > L What sending method are you using (sendmail, SMTP?) I've just sent myself your file using tkrat and did not notice any problem in keeping the "ç"... Rui. PS - Sorry if duplicate, problem with domain. From rlpires@telin.ugent.be Wed May 14 19:46:01 2003 From: rlpires@telin.ugent.be (=?iso-8859-1?Q?Rui_Lu=EDs_Pires?=) Date: Wed, 14 May 2003 20:46:01 +0200 (CEST) Subject: Attachments problems In-Reply-To: <20030514182623.5908516BC3@mailserv.microcell.ca> Message-ID: <200305141846.h4EIk1mF025117@sarek.skynet.be> On 14 May, laurent.duperval@microcell.ca wrote: > On 14 May, Rui Luís Pires wrote: >> What sending method are you using (sendmail, SMTP?) >> >> I've just sent myself your file using tkrat and did not notice any >> problem in keeping the "ç"... >> > > Are you reading the message with TkRat or with Outlook? Both sending and reading with tkrat (I tried other clients to read and the result was identical.) Sorry, I can't try OutLook, running linux here. > I don't have a > problem with TkRat, although the file name looks like this: > > TestFrançais.txt.gz > > instead of > > TestFrançais.txt.gz I had a look at your messages (the raw text) and there's a difference in the way the filename is included: With tkrat: FILENAME*="iso-8859-1''TestFran%E7ais.txt.gz" With mozilla: filename="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" However, like I said earlier, I tried to send your file with my own tkrat and in this case the filename is similar to the mozilla case... NAME="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" > I'm sending via SMTP. Are you using the same SMTP server for both tkrat and mozilla?! R. From laurent.duperval@microcell.ca Wed May 14 19:52:38 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Wed, 14 May 2003 14:52:38 -0400 (EDT) Subject: Attachments problems Message-ID: <20030514185238.AEEBD16BC7@mailserv.microcell.ca> On 14 May, Rui Lu=EDs Pires wrote: > I had a look at your messages (the raw text) and there's a difference > in the way the filename is included: >=20 > With tkrat: > FILENAME*=3D"iso-8859-1''TestFran%E7ais.txt.gz" >=20 > With mozilla: > filename=3D"=3D?ISO-8859-1?Q?TestFran=3DE7ais=3D2Etxt=3D2Egz?=3D" >=20 > However, like I said earlier, I tried to send your file with my own > tkrat and in this case the filename is similar to the mozilla case...=20 > NAME=3D"=3D?ISO-8859-1?Q?TestFran=3DE7ais=3D2Etxt=3D2Egz?=3D" >=20 Hmmm... When looking at the message in the Sent folder, I have the same thing: Content-Type: APPLICATION/x-gzip; NAME*=3D"iso-8859-1''TestFran%E7ais.txt.= gz" Mozilla says: Content-Type: application/gzip; name=3D"=3D?ISO-8859-1?Q?TestFran=3DE7ais=3D2Etxt=3D2Egz?=3D" So it looks like the problem starts before the message is even sent out the door. What version are you using? Maybe I need to install a new one. L --=20 Laurent Duperval NIXON'S THEOREM The man who can smile when things go wrong has thought of someone he can blame it on. From drharlan@pacbell.net Wed May 14 21:34:13 2003 From: drharlan@pacbell.net (Wayne E. Harlan) Date: Wed, 14 May 2003 13:34:13 -0700 (PDT) Subject: "group move" is very slow Message-ID: <20030514203413.6F4491D002@home.harlan> On 14 May, Derek B. Noonburg spoke thusly: > I'm seeing odd behavior with the "group move" feature in TkRat 2.1.1. > > If I move a single message between two folders (using the "move" menu in > the left-middle of the TkRat window), it's essentially instantaneous > (less than one second). But if I create a group, even with just two > messages in it, and then use the group:move menu, it takes a full minute > to do the move. Groups with more than two messages are even slower. > Oddly, moving a group containing only one message is just as fast as > moving a single message without using the group feature. > > Both folders are on the same IMAP server (I use Courier), running > locally on the same host as TkRat. I've seen the exact same behavior > talking to this server via ssh from another host. I initially thought > it might be a network issue, but it's happening when I run TkRat locally > too. > > The destination folder is large (6000 messages), but like I said, moving > individual messages is very fast -- group move is substantially slower > than manually doing a whole bunch of individual move operations. I tried moving 67 messages from my tkrat mailing list folder to another and back again, using the group move function. Both times it took less that 2 seconds. Im my case the folders in question are simple mbox folders on the same partition. Maybe its an IMAP thing ? -- Wayne Every major plan has a minor flaw; Every major flaw has a minor plan. From derekn@foolabs.com Wed May 14 22:13:04 2003 From: derekn@foolabs.com (Derek B. Noonburg) Date: Wed, 14 May 2003 14:13:04 -0700 (PDT) Subject: Attachments problems In-Reply-To: <20030514174634.78B5016BCB@mailserv.microcell.ca> Message-ID: <20030514211411.32481.qmail@foolabs.com> On 14 May, laurent.duperval@microcell.ca wrote: > On 14 May, maf@tkrat.org wrote: >> On 14 May, laurent.duperval@microcell.ca wrote: >>> - The same file is viewed correctly when sent with Mozilla but not with >>> Tkrat >> >> Could you try to send it (or one like that) to me with both mozilla and >> TkRat. > > Sure, and everyone gets a copy. If you see weird behaviour with it, report > back to the list. > > This is with tkrat. Your sent-with-Mozilla version looks fine. When I hit "save to file" on the attachment, I see the name with the 8-bit character (c-cedilla). But this one (sent with TkRat) doesn't show any default file name at all when I hit "save to file". I'm running TkRat 2.1.1. Looking at the raw messages, the sent-with-tkrat message looks a little weird. Mozilla's MIME part header looks like this: Content-Type: application/gzip; name="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" TkRat's looks like this: Content-Type: APPLICATION/X-GZIP; NAME*="iso-8859-1''TestFran%E7ais.txt.gz" Content-Transfer-Encoding: BASE64 Content-Disposition: ATTACHMENT; FILENAME*="iso-8859-1''TestFran%E7ais.txt.gz" I'm not particularly familiar with MIME, so far all I know this is perfectly fine, but it sure looks funny. Also, there could be something going on with my mail system, which consists of: my ISP's POP server, fetchmail, procmail, SpamAssassin, Courier imapd. (Both messages went through the identical chain, though.) Hope this helps. - Derek From stefanr@s5r6.in-berlin.de Wed May 14 22:19:23 2003 From: stefanr@s5r6.in-berlin.de (Stefan Richter) Date: Wed, 14 May 2003 23:19:23 +0200 (CEST) Subject: Attachments problems In-Reply-To: <20030514174634.78B5016BCB@mailserv.microcell.ca> Message-ID: <200305142118.h4ELIbaQ019110@hirsch.in-berlin.de> On 14 May, laurent.duperval@microcell.ca wrote: > Sure, and everyone gets a copy. If you see weird behaviour with it, report > back to the list. It is not a problem with the receiving mua (e.g. outlook). > This is with tkrat. Content-Type: APPLICATION/X-GZIP; NAME*="iso-8859-1''TestFran%E7ais.txt.gz" Content-Transfer-Encoding: BASE64 Content-Disposition: ATTACHMENT; FILENAME*="iso-8859-1''TestFran%E7ais.txt.gz" > And this is with Mozilla. Content-Type: application/gzip; name="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" Here is a sample that I just received from myself using TkRat v2.1 both as the sender and the receiver. First, an attachment with ASCII filename: Content-Type: APPLICATION/octet-stream; name=aeoeuesz Content-Transfer-Encoding: BASE64 Content-Disposition: attachment; filename=aeoeuesz And an attachment with 8bit filename: Content-Type: APPLICATION/octet-stream; name="=?iso-8859-1?Q?=E4=F6=FC=DF?=" Content-Transfer-Encoding: BASE64 Content-Disposition: attachment; filename="=?iso-8859-1?Q?=E4=F6=FC=DF?=" The same filename in a message composed by mozilla: Content-Type: text/plain; name="=?ISO-8859-1?Q?=E4=F6=FC=DF?=" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="=?ISO-8859-1?Q?=E4=F6=FC=DF?=" Either you have a different TkRat version, or the virus scanner of your mail gateway corrupts name strings which contain the encoding type in lower case. -- Stefan Richter -=====-=--== -=-= -===- http://arcgraph.de/sr/ From bern+tkrat@ti.uni-trier.de Thu May 15 00:39:19 2003 From: bern+tkrat@ti.uni-trier.de (Jochen Bern) Date: Thu, 15 May 2003 01:39:19 +0200 Subject: Attachments problems In-Reply-To: <20030514163125.86B6716BC7@mailserv.microcell.ca> References: <20030514163125.86B6716BC7@mailserv.microcell.ca> Message-ID: <200305142339.h4ENdJsF008641@trier.telematik-institut.org> Laurent Duperval wrote: > - When I send a file that doesn't have an 8 bit character in the name, it > seems to be received correctly by Outlook Makes sense. As you can see from the extracted per-part MIME headers below, TkRat is lenient about throwing in a transfer encoding (it encodes the cedille, but not the periods, like Mozilla), but *when* it starts to encode ... umh, dunno. Whatever encoding this is, it's nowhere near RFC 2047 ... ! [TkRat generated] | Content-Type: APPLICATION/X-GZIP; NAME*="iso-8859-1''TestFran%E7ais.txt.gz" | Content-Transfer-Encoding: BASE64 | Content-Disposition: ATTACHMENT; | FILENAME*="iso-8859-1''TestFran%E7ais.txt.gz" [Mozilla generated] | Content-Type: application/gzip; | name="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" | Content-Transfer-Encoding: base64 | Content-Disposition: inline; | filename="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" (FWIW, and at the risk of having missed reading up on some standard, I'ld consider TkRat plain *wrong* about the encoding and the extra- neous '*'s, worth an update WRT app/gzip vs. app/x-gzip, and your problem *might* have to do with the differing Content-Disposition but it should IMHO *not* be changed to "inline" unless TkRat is capable to positively detect that the *.txt.gz will turn into a text/plain upon uncompression, which *actually can* be displayed in "inline style".) Regards, J. Bern From maf@tkrat.org Mon May 19 21:46:43 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Mon, 19 May 2003 22:46:43 +0200 (CEST) Subject: Attachments problems Message-ID: <20030520124113.CDA002FD6@tkrat.org> On 14 May, laurent.duperval@microcell.ca wrote:=0A> Are you reading the mes= sage with TkRat or with Outlook? I don't have a=0A> problem with TkRat, alt= hough the file name looks like this:=0A> =0A> TestFran=C3=A7ais.txt.gz=0A> = =0A> instead of=0A> =0A> TestFran=E7ais.txt.gz=0A=0AThis is a bug I just fi= xed.=0A=0A=09/MaF From rlpires@telin.rug.ac.be Wed May 14 19:24:01 2003 From: rlpires@telin.rug.ac.be (=?iso-8859-1?Q?Rui_Lu=EDs_Pires?=) Date: Wed, 14 May 2003 20:24:01 +0200 (CEST) Subject: Attachments problems In-Reply-To: <3EC28162.4080606@microcell.ca> Message-ID: <200305141824.h4EIO1mF015581@sarek.skynet.be> On 14 May, Laurent Duperval wrote: > maf@tkrat.org wrote: > >>Could you try to send it (or one like that) to me with both mozilla and >>TkRat. >> >> > And this is with Mozilla. > > L What sending method are you using (sendmail, SMTP?) I've just sent myself your file using tkrat and did not notice any problem in keeping the "ç"... Rui. From maf@tkrat.org Tue May 20 15:43:52 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Tue, 20 May 2003 16:43:52 +0200 (CEST) Subject: Attachments problems Message-ID: <20030520191426.1BB7C2FE0@tkrat.org> On 15 May, Jochen Bern wrote: > Laurent Duperval wrote: >> - When I send a file that doesn't have an 8 bit character in the name, it >> seems to be received correctly by Outlook > > Makes sense. As you can see from the extracted per-part MIME headers > below, TkRat is lenient about throwing in a transfer encoding (it > encodes the cedille, but not the periods, like Mozilla), but *when* The not encoding the period is a bug. > it starts to encode ... umh, dunno. Whatever encoding this is, it's > nowhere near RFC 2047 ... ! It is rfc2231. The rfc's are pretty clear on the encoding of parameters. Rfc2047 says (section 5): + An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'. And rfc2231 starts with: This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms to provide (1) a means to specify parameter values in character sets other than US-ASCII, So TkRat (the cvs version) is fully standards compliant (modulo some bugs:-(). Unfortunately it seems others are not. That is Outlook and others seems to not recognize rfc2231 encoding. I have only done preliminary tests yet with a TkRat which does not have the encoding bugs, but it seems Outlook still does not like rfc2231 at all:-( The solution will probably be to have an option which controls if TkRat should be standards-compliant or not in this regard. /MaF PS TkRat will understand both standards on incoming emails. From bern@it-services.lu Tue May 20 22:10:53 2003 From: bern@it-services.lu (Jochen Bern) Date: Tue, 20 May 2003 23:10:53 +0200 Subject: Attachments problems In-Reply-To: <20030520191426.1BB7C2FE0@tkrat.org> References: <20030520191426.1BB7C2FE0@tkrat.org> Message-ID: <3ECA99DD.4010308@it-services.lu> maf@tkrat.org wrote: > On 15 May, Jochen Bern wrote: > > As you can see from the extracted per-part MIME headers > > below, TkRat is lenient about throwing in a transfer encoding (it > > encodes the cedille, but not the periods, like Mozilla) > The not encoding the period is a bug. (It is ... ? I'm not used to reading ABNFs, but I thought I'ld be able to spot a period in | attribute-char := (from RFC2231), resp. | tspecials := "(" / ")" / "<" / ">" / "@" / | "," / ";" / ":" / "\" / <"> | "/" / "[" / "]" / "?" / "=" (from RFC2045). Note that encoding less chars, especially chars as ubiquitous as a period, reduces the problem ... Or are there any (receiver side) MUAs that insist on periods being encoded?) > It is rfc2231. The rfc's are pretty clear on the encoding of parameters. > Rfc2047 says (section 5): Oops, missed that. Sorry. > The solution will probably be to have an option which controls if TkRat > should be standards-compliant or not in this regard. More precisely, one would hope that non-RFC2231 MUAs fail to understand the RFC2231 specific 'name*="value"' syntax (note the asterisk) and ignore that param; That'ld allow a sending MUA to give, e.g., Content-Type: what/ever; name*="iso-8859-1'de'B%FCro"; name="=?iso-8859-1?Q?B=FCro?=" which should work with RFC2231-capable, RFC2047-addicted, and mixed receiver side MUAs. Which leaves those MUAs which correctly implement RFC2047 (re- fusing to do the decoding in the param) but aren't RFC2231 aware. :-} Regards, J. Bern From maf@tkrat.org Wed May 21 06:24:59 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Wed, 21 May 2003 07:24:59 +0200 (CEST) Subject: Attachments problems Message-ID: <20030521052406.97C0E2FD1@tkrat.org> On 20 May, Jochen Bern wrote: > maf@tkrat.org wrote: >> On 15 May, Jochen Bern wrote: >> > As you can see from the extracted per-part MIME headers >> > below, TkRat is lenient about throwing in a transfer encoding (it >> > encodes the cedille, but not the periods, like Mozilla) >> The not encoding the period is a bug. > > (It is ... ? I'm not used to reading ABNFs, but I thought I'ld > be able to spot a period in Ok, may not be a bug. But the presence of a period causes the value to be enclosed in quotes and I am not usre how that follows the standard. Anyway it is not illegal to encode the period. /MaF From laurent.duperval@microcell.ca Wed May 21 19:20:55 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Wed, 21 May 2003 14:20:55 -0400 (EDT) Subject: Coloring of replies Message-ID: <20030521182056.1D69216BC3@mailserv.microcell.ca> Hi, Pan has a feature I find interesting: different repli levels are color coded. So in a message like this: >>> Line 1 >> Line 2 > Line 3 Line 4 Each has a different line colour. How can this be added to tkrat? Is it desirable? L -- Laurent Duperval Leff's First Rule of Programming: Don't document the program, program the document From bern@it-services.lu Wed May 21 20:54:23 2003 From: bern@it-services.lu (Jochen Bern) Date: Wed, 21 May 2003 21:54:23 +0200 Subject: Coloring of replies In-Reply-To: <20030521182056.1D69216BC3@mailserv.microcell.ca> References: <20030521182056.1D69216BC3@mailserv.microcell.ca> Message-ID: <3ECBD96F.8050502@it-services.lu> laurent.duperval@microcell.ca wrote: > Pan has a feature I find interesting: different repli levels > are color coded. [...] How can this be added to tkrat? Is it > desirable? It's much more suggestive than usual indentation - which is good when everything goes A-OK, and bad else (e.g., someone sloppily editing replies and leaving lines with too many or too few '>'s, or people using indentation strings other than '>' or '> '). Choose your poison. :-) MUAs that reformat the quoted part, be it by just splitting: | > > > > > This text started out fitting into 72 columns just | > fine, | > > but | > > > > > the lines got reformatted to 72 cols by adding line | > wraps | > > > (and | > > > > > 1st-level indentation prefixes immediately following | > them) | > > twice | > > > > > while being re-re-re-...-quoted. or (worse) by recreating the line breaks completely from scratch: | > > > > > Again, this text originally fit well into 72 cols, | > but the > > > > last MUA doing quotation saw fit to remove | > all existing line > > > > breaks and create new ones on its | > own, firmly embedding (its > > > > foot into its mouth and) | > the old indentation prefixes into the > > > > middle of the | > resulting lines. As soon as the prefixes "run > > > > off" | > the end of the line, like, for example, right here+now: > > | > > > , you get other apparent indentation levels than 1 and | > the > > > > correct one, too. Also if *several* MUAs did this | > %&*#!!! thing > > > > to the text. will threaten to give you a headache. %-} Both seen occuring "in the wild". (I suppose that algorithms having a guess at "good" alternative text colors, given a limited number of text and background colors already in use, are floating around on the 'net someplace ...) Please do NOT, however, have the differing color *replace* the indentation - that'ld downright break "ASCII art", including, e.g., | > I'm trying to connect to port 123/tcp on IP 47.11.15 | Try with an octet "08" inserted here --------------^ Regards, J. Bern From maf@tkrat.org Thu May 22 05:33:58 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Thu, 22 May 2003 06:33:58 +0200 (CEST) Subject: Coloring of replies Message-ID: <20030522052904.10B322FE7@tkrat.org> On 21 May, laurent.duperval@microcell.ca wrote: > Pan has a feature I find interesting: different repli levels are color > coded. So in a message like this: > >>>> Line 1 >>> Line 2 >> Line 3 > Line 4 > > Each has a different line colour. How can this be added to tkrat? Is it > desirable? I tried something similar where I only color-coded the cited text and found it more confusing than helping. But that may have been only me. And in my test I did not distinguish between different levels of cited text which would be more useful. It is doable but requires some work. /MaF From maf@tkrat.org Fri May 23 05:28:22 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Fri, 23 May 2003 06:28:22 +0200 (CEST) Subject: Coloring of replies Message-ID: <20030524081435.0EA142FD4@tkrat.org> On 21 May, Jochen Bern wrote: > Please do NOT, however, have the differing color *replace* the > indentation - that'ld downright break "ASCII art", including, e.g., No need to worry, I'll not replace the indention. Also if the feature gets added then there will probably be an easy way to turn it off. /MaF From maf@tkrat.org Fri May 23 17:03:16 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Fri, 23 May 2003 18:03:16 +0200 (CEST) Subject: Attachment naming problem Message-ID: <20030524081435.A363F2FDA@tkrat.org> Hello, I have now done the fixes to parameter encoding. There is a new option which controls how to encode parameters. They can be encoded with rfc2047 (illegal but works), rfc2231 (legal but with problems) or both. The code is in cvs. Please let me know if there are any problems with it. /MaF From maf@tkrat.org Thu May 15 05:41:38 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Thu, 15 May 2003 06:41:38 +0200 (CEST) Subject: Suggestion Message-ID: <20030515053127.E5E892FD7@tkrat.org> On 14 May, laurent.duperval@microcell.ca wrote: > I tried Balsa for a few days this winter and one thing I liked about it was > the "Reply to group" option, which I found particularly useful when dealing > with mailing lists like TkRat which, by default, send replies to the author, > not the list. WOuld this be feasible with TkRat? Everything is possible:-) Currently in TkRat you could always do a "Replt ro all" which send the reply to both author and mailinglist. All look into adding a "Reply to list" feature. /MaF From maf@tkrat.org Thu May 15 05:57:19 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Thu, 15 May 2003 06:57:19 +0200 (CEST) Subject: Attachments problems Message-ID: <20030515053128.B9D802FDA@tkrat.org> >> On 14 May, laurent.duperval@microcell.ca wrote: >>> - The same file is viewed correctly when sent with Mozilla but not with >>> Tkrat Ok, I see the problem. The problem is that TkRat is standards compliant and uses rfc2231 encoding of the filenames whereas the others do not. I may have to implement an option in TkRat which tells it how to encode filenames. /MaF From rlpires@telin.ugent.be Thu May 15 15:16:32 2003 From: rlpires@telin.ugent.be (=?iso8859-1?Q?Rui_Lu=EDs_Pires?=) Date: Thu, 15 May 2003 16:16:32 +0200 (CEST) Subject: Attachments problems In-Reply-To: <20030514185238.AEEBD16BC7@mailserv.microcell.ca> Message-ID: <20030515141634.B916F542FD@telin.UGent.be> On 14 May, laurent.duperval@microcell.ca wrote: > > Hmmm... When looking at the message in the Sent folder, I have > the same thing: > > Content-Type: APPLICATION/x-gzip; > NAME*="iso-8859-1''TestFran%E7ais.txt.gz" > > Mozilla says: > > Content-Type: application/gzip; > name="=?ISO-8859-1?Q?TestFran=E7ais=2Etxt=2Egz?=" > > So it looks like the problem starts before the message is even > sent out the door. What version are you using? Maybe I need to > install a new one. Well, I normally use TkRat 2.1. I tried different things but whatever I did I could not reproduce your problem. However, after you asked, I made a checkout on the latest CVS and tried the same procedure out. This time I was able to reproduce your problem (or something similar)! Even though I have tkrat set up to use iso8859-1, the attachment delimiter looks rather odd: Content-Type: APPLICATION/GZIP; NAME*=us-ascii''%3D%3FISO-8859-1%3FQ%3FTestFran%3DE7ais%3D2Etxt%3D2Egz%3F%3 (NB: this results of forwarding Laurent's original message, which was sent with mozilla - thus, correct filename.) Laurent, confirm you are using the CVS version. On 2.1 I really cannot generate this error. Any clues as to why the cvs version is doing that?... Rui From laurent.duperval@microcell.ca Thu May 15 15:22:18 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Thu, 15 May 2003 10:22:18 -0400 (EDT) Subject: Fwd: Re: Suggestion Message-ID: <20030515142218.DA9FB16BC7@mailserv.microcell.ca> Weird, this message bounced. L ------ Forwarded message ------ From: laurent.duperval@microcell.ca Subject: Re: Suggestion Date: Thu, 15 May 2003 09:27:34 -0400 To: larry.gensch@hp.com Cc: tkrat@tkrat.org Reply-To: laurent.duperval@microcell.ca On 15 May, Larry Gensch wrote: > You mean, as opposed to "Reply to all..."? >=20 Yes. See, reply all is sending a reply to you and to the group. Maybe you l= ike that, maybe not. My attitude is: if the person sent a question or comment to the group, then the reply should go there also. When a mailing list doesn't set the Reply-To: field to be the group, you get instances where a reply go= es to one person and then you have Cc's that go to twelve people. I hate editi= ng the To: and Cc: fields to remove people so a feature like this helps. > I've looked at balsa, and usually find some reason to dislike it. >=20 Me too. But there are some interesting things there. > Currently, the only two mailers that I use are tkrat and evolution. I'd > like the latter even more if I could get it running on more than just Lin= ux > (it's very picky about the packages that it requires; so much so that it'= s a > hassle to port it to anything else). >=20 I don't like Evo, because it doesn't work well with mboxes. I'm taking anot= her look at Mozilla. It seems Ok, but it's dreadfully slow. I took a look at Sylpheed, ditched it in five minutes. Although there are some things that I don't like about Tkrat, it's still the one that best suits my usage pattern. Plus, when I really need a feature, I know how to add it. L P.S. No, I don't think I'll be adding in this one. Who would've thought I'd become a luser: complain a lot, don't contribute much. - --=20 Laurent Duperval Je connais un r=E9m=E8de de bonne femme et de cheval qui est d'une efficacit=E9 =E0 casser les vitres dans un rayon de cent m=E8tres! -Alambic Talon From laurent.duperval@microcell.ca Thu May 15 15:28:16 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Thu, 15 May 2003 10:28:16 -0400 (EDT) Subject: Attachments problems Message-ID: <20030515142817.17EDA16BC9@mailserv.microcell.ca> On 15 May, Rui Lu=EDs Pires wrote: > This time I was able to reproduce your problem (or something > similar)! Even though I have tkrat set up to use iso8859-1, the > attachment delimiter looks rather odd: >=20 > Content-Type: APPLICATION/GZIP; > NAME*=3Dus-ascii''%3D%3FISO-8859-1%3FQ%3FTestFran%3DE7ais%3D2Etxt%3D2E= gz%3F%3 >=20 > (NB: this results of forwarding Laurent's original message, which > was sent with mozilla - thus, correct filename.) >=20 > Laurent, confirm you are using the CVS version. On 2.1 I really > cannot generate this error. >=20 Well, I'm not using a current CVS version but I am using a snapshot from Feb 13. > Any clues as to why the cvs version is doing that?... >=20 Well, I'll let the Master figure this one out. :-) L --=20 Laurent Duperval Voisin, vous seriez une vraie lumi=E8re... si on avait ouvert l'interrupteu= r. -Lefuneste From jarausch@igpm.rwth-aachen.de Tue May 27 11:25:14 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Tue, 27 May 2003 12:25:14 +0200 (CEST) Subject: printing iso-8859-1 problems Message-ID: <20030527102514.108D2A717C@numa-i.igpm.rwth-aachen.de> Hi, I have a problem with TkRat's postscript (pretty) printing. TkRat does show the German umlaut correctly (the message has Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1) but when printing the message most umlauts get lost. Curiously 2 of them (o-umlaut and u-umlaut) are printed. (Printing the original file that has been mailed by a2ps on the same printer works just fine) How can I change this? Many thanks for a hint, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From larry.gensch@hp.com Thu May 15 14:18:15 2003 From: larry.gensch@hp.com (Larry Gensch) Date: Thu, 15 May 2003 09:18:15 -0400 (EDT) Subject: Suggestion In-Reply-To: <20030514175017.C71FE16BC7@mailserv.microcell.ca> Message-ID: <200305151318.JAA0000091317@toontown.zk3.dec.com> On 14 May, laurent.duperval@microcell.ca wrote: > Hi, > > I tried Balsa for a few days this winter and one thing I liked about it was > the "Reply to group" option, which I found particularly useful when dealing > with mailing lists like TkRat which, by default, send replies to the author, > not the list. WOuld this be feasible with TkRat? You mean, as opposed to "Reply to all..."? I've looked at balsa, and usually find some reason to dislike it. Currently, the only two mailers that I use are tkrat and evolution. I'd like the latter even more if I could get it running on more than just Linux (it's very picky about the packages that it requires; so much so that it's a hassle to port it to anything else). -- Larry Gensch Larry.Gensch@HP.com Nashua Languages and Tools Lab (NLTL) Hewlett-Packard Company, Nashua, NH From laurent.duperval@microcell.ca Thu May 15 15:29:52 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Thu, 15 May 2003 10:29:52 -0400 (EDT) Subject: Fwd: Re: "group move" is very slow Message-ID: <20030515142952.DC3B016BC3@mailserv.microcell.ca> This was meant to go to the group... See what I mean? :-) L ------ Forwarded message ------ From: laurent.duperval@microcell.ca Subject: Re: "group move" is very slow Date: Thu, 15 May 2003 10:29:12 -0400 (EDT) To: derekn@foolabs.com On 14 May, Derek B. Noonburg wrote: > The destination folder is large (6000 messages), but like I said, moving > individual messages is very fast -- group move is substantially slower > than manually doing a whole bunch of individual move operations. > Well, I remember having that problem a long, long time ago on HP. I don't use IMAP anymore so I can't help. L - -- Laurent Duperval Sachez qu'un Talon ne recule jamais d'un orteil et que celui qui me marche sur les pieds peut toujours courir, mossieu! -Achille Talon From rlpires@telin.ugent.be Thu May 15 16:10:25 2003 From: rlpires@telin.ugent.be (=?iso8859-1?Q?Rui_Lu=EDs_Pires?=) Date: Thu, 15 May 2003 17:10:25 +0200 (CEST) Subject: Attachments problems In-Reply-To: <20030515142817.17EDA16BC9@mailserv.microcell.ca> Message-ID: <20030515151028.3AA6C542FD@telin.UGent.be> On 15 May, laurent.duperval@microcell.ca wrote: > On 15 May, Rui Luís Pires wrote: >> This time I was able to reproduce your problem (or something >> similar)! Even though I have tkrat set up to use iso8859-1, >> the attachment delimiter looks rather odd: [...] >> >> Laurent, confirm you are using the CVS version. On 2.1 I >> really cannot generate this error. >> > > Well, I'm not using a current CVS version but I am using a > snapshot from Feb 13. Close enough, I'd say. >> Any clues as to why the cvs version is doing that?... > > Well, I'll let the Master figure this one out. :-) On a side comment, I noticed TkRat has sometimes problems determining the type of some files (the mime description you find in Content-Type:). This is true for both 2.1 and 2.2dev. Every now and then I get a MicroSoft Word file given as text/plain. Fortunatelly it is always possible to change that in the attach file dialog. Normally it would fall on application/octet-stream. (Note that the command 'file something.doc' returns 'something.doc: Microsoft Office Document'.) Rui PS - Is there anything wrong with the list server? I am missing a few posts there... From laurent.duperval@microcell.ca Thu May 15 16:16:28 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Thu, 15 May 2003 11:16:28 -0400 (EDT) Subject: Attachments problems Message-ID: <20030515151628.D501016BCA@mailserv.microcell.ca> On 15 May, Rui Lu=EDs Pires wrote: > On a side comment, I noticed TkRat has sometimes problems > determining the type of some files (the mime description you find > in Content-Type:). This is true for both 2.1 and 2.2dev. >=20 Well, TkRat isn't the problem, it's your magic file. In later versions, I'm not sure which, I added the possibility to get MIME types from file. If you go to Preferences | Advanced | Files, in MIME program, you can enter the command to use to get the MIME type back. I use=20 file -i=20 so on a Word document, I'll get file -i mydoc.doc mydoc.doc: application/msword and TkRat will use that. > PS - Is there anything wrong with the list server? I am missing a > few posts there... >=20 I had a bounce this morning, so maybe there was one. L --=20 Laurent Duperval DENNISTON'S LAW Virtue is its own punishment. From rlpires@telin.ugent.be Thu May 15 16:32:49 2003 From: rlpires@telin.ugent.be (=?iso8859-1?Q?Rui_Lu=EDs_Pires?=) Date: Thu, 15 May 2003 17:32:49 +0200 (CEST) Subject: Attachments problems In-Reply-To: <20030515151628.D501016BCA@mailserv.microcell.ca> Message-ID: <20030515153252.4069B542FD@telin.UGent.be> On 15 May, laurent.duperval@microcell.ca wrote: > Well, TkRat isn't the problem, it's your magic file. In later > versions, I'm not sure which, I added the possibility to get > MIME types from file. If you go to Preferences | Advanced | > Files, in MIME program, you can enter the command to use to get > the MIME type back. I use > > file -i > > so on a Word document, I'll get > > file -i mydoc.doc > mydoc.doc: application/msword Indeed! Good tip, already added '-i' to the mime program entry (I had file with no arguments.) Rui From gert@cs.vu.nl Fri May 16 09:41:56 2003 From: gert@cs.vu.nl (gert@cs.vu.nl) Date: Fri, 16 May 2003 10:41:56 +0200 (CEST) Subject: Attachments problems In-Reply-To: <3EC28162.4080606@microcell.ca> Message-ID: On 14 May, Laurent Duperval wrote: > maf@tkrat.org wrote: > >>On 14 May, laurent.duperval@microcell.ca wrote: >> >> >>>- The same file is viewed correctly when sent with Mozilla but not with >>> Tkrat >>> >>> >> >>Could you try to send it (or one like that) to me with both mozilla and >>TkRat. >> >> > And this is with Mozilla. > > L > My tkrat (version 2.1) has a problem whith this attachment too, it shows no filename at all. Ik the mozilla send version it shows the correct 8 bit filename. Gert -- Gert Huisman Systeem programmeur IT-groep FEW email: gert@few.vu.nl Vrije Universiteit Amsterdam telefoon: +31 20 4447806 De Boelelaan 1081a, kamer: S4.14 fax: +31 20 4447653 1081 HV Amsterdam, the Netherlands From rlpires@telin.ugent.be Tue May 27 12:10:31 2003 From: rlpires@telin.ugent.be (=?iso8859-1?Q?Rui_Lu=EDs_Pires?=) Date: Tue, 27 May 2003 13:10:31 +0200 (CEST) Subject: Attachments problems In-Reply-To: <20030515142817.17EDA16BC9@mailserv.microcell.ca> Message-ID: There was obviously a problem with the mailing list server which caused a couple of messages being delivered to the list nearly 2 weeks after they were originaly sent. Let's close this thread. Rui Pires From laurent.duperval@microcell.ca Tue May 27 13:53:39 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Tue, 27 May 2003 08:53:39 -0400 (EDT) Subject: printing iso-8859-1 problems Message-ID: <20030527125339.C517E47D3C@lenard.admin.fido.ca> On 27 May, jarausch@igpm.rwth-aachen.de wrote: > Hi, > I have a problem with TkRat's postscript (pretty) > printing. > TkRat does show the German umlaut correctly > (the message has Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1) > but when printing the message most umlauts get lost. > Curiously 2 of them (o-umlaut and u-umlaut) are printed. > (Printing the original file that has been mailed by a2ps > on the same printer works just fine) > Now that you mention it, I've noticed that all my emails that contain accented characters don't print out correctly. Whenever I used this, I was in a hurry and never remembered to report it. L -- Laurent Duperval HINDS' LAW OF COMPUTER PROGRAMMING 1) Any given program, when running, is obsolete. 2) If a program is useful, it will have to be changed. 3) If a program is useless, it will have to be documented. 4) Any given program will expand to fill all available memory. 5) The value of a program is proportional to the weight of its output. 6) Program complexity grows until it exceeds the capability of the programmer who must maintain it. 7) Make it possible for programmers to write programs in English, and you will find that programmers cannot write in English. From maf@tkrat.org Tue May 27 20:28:19 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Tue, 27 May 2003 21:28:19 +0200 (CEST) Subject: Recent list problems Message-ID: <20030527192655.B75C52FF1@tkrat.org> Hello, As you may have noticed there have been problems with the TkRat mailing-lists lately. I think I have fixed the problem now and thelists should be back to normal. What really happened was that the domain for one of the subscribers dissapeared (or at least the listed DNS-servers are unreachable). And I had postfix configured to check the recipent domain when accepting emails. So this check took place each time mailman tried to send an email. After a loong time teh check failed and mailman failed to deliver that batch of messages. Unfortunately mailman seems to not recignize recipient failures in this phase so the troubling user did not get disabled. I have now reconfigured postfix and disabled the user. Now all I have to do is reply to the queued emails... /MaF From rlpires@telin.ugent.be Wed May 28 16:14:45 2003 From: rlpires@telin.ugent.be (=?iso8859-1?Q?Rui_Lu=EDs_Pires?=) Date: Wed, 28 May 2003 17:14:45 +0200 (CEST) Subject: feature request, wishlist (2) Message-ID: Hello everybody, As the subject reads, this is a feature request. Well, two actually, although with different priorities. What about the possibility to pipe a message to an external command? I was thinking of my current spam filter (which I manually re-run when it fails to detect spam, in order to correct the frequencies) but other very good uses are also possible. (currently I have to save the message to a file, remove the mbox headers that get added and then finally pipe it.) On another front, I also once asked for another feature, the possibility to remove one or more MIME parts of a message (as a means of efficient archiving; eg. no need to keep both the text/plain and text/html parts.) Is that a bit further up in the To-Do-pile/priority-queue?! :) Regards, Rui From maf@tkrat.org Wed May 28 17:00:25 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Wed, 28 May 2003 18:00:25 +0200 (CEST) Subject: printing iso-8859-1 problems Message-ID: <20030528184703.743C92FFF@tkrat.org> On 27 May, jarausch@igpm.rwth-aachen.de wrote: > Hi, > I have a problem with TkRat's postscript (pretty) > printing. > TkRat does show the German umlaut correctly > (the message has Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1) > but when printing the message most umlauts get lost. This is due to a bug (or to put a more positive spin on it, the fact that TkRat expects too much of the local system). A fix is in the cvs (current and v2_1_branch). /MaF From jarausch@igpm.rwth-aachen.de Fri May 30 07:37:00 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Fri, 30 May 2003 08:37:00 +0200 (CEST) Subject: grouping by dragging the right mouse button Message-ID: <20030530063700.CD39DA717C@numa-i.igpm.rwth-aachen.de> Having updated to the current CVS version one features seems to have gone - grouping a bunch of messages by dragging the right mouse button. Since I still reveive a lot of spam I normally group these message en bloque and move them to a big spam file which is analyzed lateron by bogofilter. Now I can only use the middle mouse button to add a single message to the group since dragging scrolls the window. I do like the feature to drag the window but is there a means like or plus dragging which gives the previous feature? Many thanks for a hint, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From jarausch@igpm.rwth-aachen.de Fri May 30 07:31:02 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Fri, 30 May 2003 08:31:02 +0200 (CEST) Subject: printing iso-8859-1 problems Message-ID: <20030530063102.76EE0A717C@numa-i.igpm.rwth-aachen.de> On 28 May, maf@tkrat.org wrote: > This is due to a bug (or to put a more positive spin on it, the fact > that TkRat expects too much of the local system). A fix is in the cvs > (current and v2_1_branch). Many thanks, it works great! Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From maf@tkrat.org Fri May 30 08:32:52 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Fri, 30 May 2003 09:32:52 +0200 (CEST) Subject: grouping by dragging the right mouse button Message-ID: <20030530073251.08A0A3063@tkrat.org> On 30 May, jarausch@igpm.rwth-aachen.de wrote: > Having updated to the current CVS version one features > seems to have gone - grouping a bunch of messages by > dragging the right mouse button. The bindings have changed to accomodate the context menu. But you can use Shift-<1> and drag. /MaF From jarausch@igpm.rwth-aachen.de Fri May 30 08:36:26 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Fri, 30 May 2003 09:36:26 +0200 (CEST) Subject: grouping by dragging the right mouse button Message-ID: <20030530073626.362B3A717C@numa-i.igpm.rwth-aachen.de> On 30 May, maf@tkrat.org wrote: > On 30 May, jarausch@igpm.rwth-aachen.de wrote: >> Having updated to the current CVS version one features >> seems to have gone - grouping a bunch of messages by >> dragging the right mouse button. > > The bindings have changed to accomodate the context menu. But you can > use Shift-<1> and drag. > Yes, thanks, although it needs getting used to it since I have to drag into the opposite direction. Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From laurent.duperval@microcell.ca Fri May 30 12:59:25 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Fri, 30 May 2003 07:59:25 -0400 (EDT) Subject: printing iso-8859-1 problems Message-ID: <20030530115925.301F047D3C@lenard.admin.fido.ca> On 30 May, jarausch@igpm.rwth-aachen.de wrote: > On 28 May, maf@tkrat.org wrote: >> This is due to a bug (or to put a more positive spin on it, the fact >> that TkRat expects too much of the local system). A fix is in the cvs >> (current and v2_1_branch). > > Many thanks, it works great! > I can't see it. :-( Martin, can you put up a snapshot when you feel it's justified? Thanks, L -- Laurent Duperval Why are cigarettes sold in gas stations when smoking is prohibited there? From drharlan@pacbell.net Fri May 30 14:35:22 2003 From: drharlan@pacbell.net (Wayne E. Harlan) Date: Fri, 30 May 2003 06:35:22 -0700 (PDT) Subject: grouping by dragging the right mouse button Message-ID: <20030530133522.C928B1D002@home.harlan> On 30 May, maf@tkrat.org spoke thusly: > On 30 May, jarausch@igpm.rwth-aachen.de wrote: >> Having updated to the current CVS version one features >> seems to have gone - grouping a bunch of messages by >> dragging the right mouse button. > > The bindings have changed to accomodate the context menu. But you can > use Shift-<1> and drag. > Or, if you have a 3 button mouse, use the middle button to flag messages. -- Wayne Every major plan has a minor flaw; Every major flaw has a minor plan. From maf@tkrat.org Fri May 30 14:39:13 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Fri, 30 May 2003 15:39:13 +0200 (CEST) Subject: printing iso-8859-1 problems Message-ID: <20030530133916.6E8F03000@tkrat.org> On 30 May, laurent.duperval@microcell.ca wrote: > I can't see it. :-( Martin, can you put up a snapshot when you feel > it's justified? Ok, just did one. /MaF From Derek B. Noonburg" On 14 May, maf@tkrat.org wrote: > On 14 May, Derek B. Noonburg wrote: >> I'm seeing odd behavior with the "group move" feature in TkRat 2.1.1. > > Group move should be significantly faster in the current cvs snapshot. I just installed the new snapshot version (20030530), and group moves are still really slow. Is there anything else I can try? - Derek From jarausch@igpm.rwth-aachen.de Mon Jun 2 15:16:10 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Mon, 02 Jun 2003 16:16:10 +0200 (CEST) Subject: html browser - how to configure Message-ID: <20030602141610.17041A717C@numa-i.igpm.rwth-aachen.de> Hi, how can I configure the exact calling of my WWW-browser. In I can only enter the command name (in my case opera) Now tkrat calls opera like opera -remote openURL(http://www.netlib.org/na-net,new-window) but that doesn't work here since the z-shell interferes I need just opera -newwindow http://www.netlib.org/na-net How can configure this. I've tried under 'Opera command' opera -newwindow http://%u but '%u' isn't expanded. Many thanks for a hint, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From laurent.duperval@microcell.ca Mon Jun 2 15:37:15 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Mon, 2 Jun 2003 10:37:15 -0400 (EDT) Subject: Extracting adresses shouldn't makr all of them Message-ID: <20030602143715.4B31847D3C@lenard.admin.fido.ca> Hi, I just received an email and I wantend to extract a coupkle of addresses from it. However, there were more than 50 recipients and I only wanted to extract two or three. Maybe if there was a button called "Clear Selection" which changed the checkbuttons to off, that would make it more useful in these instances. L -- Laurent Duperval GOEBEL'S LAW OF INTELLECTUAL OBSCURITY: What fun is it to be an expert if you make yourself easy to understand? From laurent.duperval@microcell.ca Mon Jun 2 20:55:05 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Mon, 2 Jun 2003 15:55:05 -0400 (EDT) Subject: html browser - how to configure Message-ID: <20030602195505.B600247D3C@lenard.admin.fido.ca> On 2 Jun, jarausch@igpm.rwth-aachen.de wrote: > How can configure this. > I've tried under 'Opera command' > opera -newwindow http://%u > but '%u' isn't expanded. > Did you try opera -newwindow %u ? L -- Laurent Duperval SAUSAGE PRINCIPLE People who love sausage and respect the law should never watch either one being made. From Derek B. Noonburg" > On 14 May, maf@tkrat.org wrote: >> Group move should be significantly faster in the current cvs snapshot. I replied: > I just installed the new snapshot version (20030530), and group moves > are still really slow. Is there anything else I can try? Following up on my own post... Is there any chance this is due to some sort of incompatibility between TkRat and the Courier IMAP server? I know there are some issues here. For example, TkRat doesn't import the folder hierarchy correctly. (This is apparently a known issue with Courier and various mail readers -- see http://www.inter7.com/courierimap/FAQ.html#namespace .) Anyway, the folder import thing doesn't particularly bother me, since I don't use it. But I'm wondering if there might be other incompatibility issues, if TkRat (or the IMAP library it uses) has only been tested with the UW IMAP server. - Derek From derekn@foolabs.com Mon Jun 2 23:12:48 2003 From: derekn@foolabs.com (Derek B. Noonburg) Date: Mon, 2 Jun 2003 15:12:48 -0700 (PDT) Subject: PGP problems in 20030530 snapshot Message-ID: <20030602221248.29989.qmail@foolabs.com> I ran into another problem with the latest TkRat snapshot: I can't decrypt PGP-encrypted messages. It can encrypt outgoing messages just fine. When I select an encrypted message to view, it prompts for the password and then either shows a blank message body and a weird error ('invalid command name "RatBody11"'), or sometimes just hangs. I have it configured to use GPG-1. TkRat 2.1.1 works correctly. - Derek From maf@tkrat.org Tue Jun 3 05:42:29 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Tue, 3 Jun 2003 06:42:29 +0200 (CEST) Subject: "group move" is very slow Message-ID: <20030603052805.C17E82FD7@tkrat.org> On 2 Jun, Derek B. Noonburg wrote: > I know there are some issues here. For example, TkRat doesn't import > the folder hierarchy correctly. (This is apparently a known issue with I would be interested in knowing more about this. > Courier and various mail readers -- see > http://www.inter7.com/courierimap/FAQ.html#namespace .) Anyway, the > folder import thing doesn't particularly bother me, since I don't use > it. But I'm wondering if there might be other incompatibility issues, > if TkRat (or the IMAP library it uses) has only been tested with the UW > IMAP server. It is true that I primarily test TkRat with c-client. However I have,albeit a while ago, run the entire test-suite against an Cyrus-server (and found one bug in Cyrus while doing it:-). In this particular case I am interested in finding out why it is so slow and I will get back to Derek in a private message to work further on the problem. /MaF From maf@tkrat.org Thu Jun 5 06:18:28 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Thu, 5 Jun 2003 07:18:28 +0200 (CEST) Subject: Extracting adresses shouldn't makr all of them Message-ID: <20030605054359.684592FD7@tkrat.org> On 2 Jun, laurent.duperval@microcell.ca wrote: > I just received an email and I wantend to extract a coupkle of addresses > from it. However, there were more than 50 recipients and I only wanted to > extract two or three. Maybe if there was a button called "Clear Selection" > which changed the checkbuttons to off, that would make it more useful in > these instances. There is now such a button in the cvs version. /MaF From laurent.duperval@microcell.ca Thu Jun 26 13:50:57 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Thu, 26 Jun 2003 08:50:57 -0400 (EDT) Subject: userprocs question Message-ID: <20030626125058.0EAC947D3C@lenard.admin.fido.ca> Hi, I want to prepend a string in front of certain messages I reply to. I can see that it's working but it removes my indent character. Is this normal? I want this in my replies: ------- On Sat Apr 31, 2121, you@there.com uttered: > Quoted and indfented > stuf which some body said > some time My answer here. And there. And everywhere ------- But instead, I get: ------- On Sat Apr 31, 2121, you@there.com uttered: Quoted and indfented stuf which some body said some time My answer here. And there. And everywhere -------- Is this the expected behaviour? If so, I'd like to say that I prefer the first one. Of course, if there's a good reason for it to be like this and if there's a workaround, that's ok too. L -- Laurent Duperval "In Europe, do you think Miles Davis is known as Kilometers Davis? Thank you." -- Stephen Wright's complete standup routine on _The_Late_Show_ with David Letterman, Aug. 29 1994 From laurent.duperval@microcell.ca Thu Jun 26 14:28:21 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Thu, 26 Jun 2003 09:28:21 -0400 (EDT) Subject: userprocs question Message-ID: <20030626132821.32EE347D3C@lenard.admin.fido.ca> On 26 Jun, To: TkRat Mailing List wrote: > Hi, > > I want to prepend a string in front of certain messages I reply to. I can > see that it's working but it removes my indent character. Is this normal? I > want this in my replies: > Ok, I was using the citation proc and that puts a string in front of each line. That's not what I'd understood when I read the docs. It looks like right now, to get what I want I have to mess with the signature proc. Well, that's a good enough workaround, I get. L -- Laurent Duperval MUIR'S LAW When we try to pick out anything by itself, we find it hitched to everything else in the universe. From larry.gensch@hp.com Thu Jun 26 14:44:04 2003 From: larry.gensch@hp.com (Larry Gensch) Date: Thu, 26 Jun 2003 09:44:04 -0400 (EDT) Subject: userprocs question In-Reply-To: <20030626132821.32EE347D3C@lenard.admin.fido.ca> Message-ID: <200306261344.JAA0000277236@toontown.zk3.dec.com> On 26 Jun, laurent.duperval@microcell.ca wrote: > On 26 Jun, To: TkRat Mailing List wrote: >> Hi, >> >> I want to prepend a string in front of certain messages I reply to. I can >> see that it's working but it removes my indent character. Is this normal? I >> want this in my replies: >> > > Ok, I was using the citation proc and that puts a string in front of each > line. That's not what I'd understood when I read the docs. > > It looks like right now, to get what I want I have to mess with the > signature proc. Well, that's a good enough workaround, I get. Off the topic of Laurent's original question, but if you look at the citation line (On 26 Jun, To: TkRat Mailing List wrote:), you can see something that I have noticed in tkRat for quite a long time. If YOU write a message, and you reply to all recipients, this sort of thing happens if tkRat understands that the message was originally written by you. I think this is related to the name that is displayed in the message list (if I write the message, I see the recipient address instead of my own). Do you think this could be fixed? -- Larry Gensch Larry.Gensch@HP.com Nashua Languages and Tools Lab (NLTL) Hewlett-Packard Company, Nashua, NH From laurent.duperval@microcell.ca Thu Jun 26 14:57:27 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Thu, 26 Jun 2003 09:57:27 -0400 (EDT) Subject: userprocs question Message-ID: <20030626135727.3E6AF47D3C@lenard.admin.fido.ca> On 26 Jun, To: tkrat@tkrat.org wrote: > It looks like right now, to get what I want I have to mess with the > signature proc. Well, that's a good enough workaround, I get. > > L > That doesn't work. In order to do what I want, I need the handler of the message so I can get the Delivered-To headers. So I guess I have to add in the functionality. If anyone knows where I should go to do this, let me know so I don't waste too much time wading through the source code. :-) L -- Laurent Duperval FLO CAPP'S OBSERVATION: The next best thing to doing something smart is not doing something stupid. From maf@tkrat.org Fri Jun 27 05:49:56 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Fri, 27 Jun 2003 06:49:56 +0200 (CEST) Subject: userprocs question Message-ID: <20030627053815.2F4082FE3@tkrat.org> On 26 Jun, Larry Gensch wrote: > Off the topic of Laurent's original question, but if you look at the > citation line (On 26 Jun, To: TkRat Mailing List wrote:), you can see > something that I have noticed in tkRat for quite a long time. > > If YOU write a message, and you reply to all recipients, this sort of > thing happens if tkRat understands that the message was originally > written by you. I think this is related to the name that is displayed > in the message list (if I write the message, I see the recipient address > instead of my own). > > Do you think this could be fixed? Fixing it is on the TODO-list. I just haven't gotten around to it yet:-) /MaF From maf@tkrat.org Fri Jun 27 05:47:09 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Fri, 27 Jun 2003 06:47:09 +0200 (CEST) Subject: userprocs question Message-ID: <20030627053814.C36782FD7@tkrat.org> On 26 Jun, laurent.duperval@microcell.ca wrote: > That doesn't work. In order to do what I want, I need the handler of the > message so I can get the Delivered-To headers. So I guess I have to add in > the functionality. If anyone knows where I should go to do this, let me know > so I don't waste too much time wading through the source code. :-) The first line is controlled by the attribution option (Preferences->Advanced->Replies). You can use the same codes as in the message-list. The default value is "On %d, %n wrote:". /MaF From laurent.duperval@microcell.ca Fri Jun 27 13:10:56 2003 From: laurent.duperval@microcell.ca (laurent.duperval@microcell.ca) Date: Fri, 27 Jun 2003 08:10:56 -0400 (EDT) Subject: userprocs question Message-ID: <20030627121056.73ECA47D3C@lenard.admin.fido.ca> On 27 Jun, maf@tkrat.org wrote: > The first line is controlled by the attribution option > (Preferences->Advanced->Replies). You can use the same codes as in the > message-list. The default value is "On %d, %n wrote:". > Either this isn't what I'm looking for or I don't understand what you're saying. Let me explain: I'm on a mailing list where people can submit questions event if they aren't subscribed. Looking at the Delivered-To header, it will say "moderator" if the person is not subscribed. In that case, and only in that case, I want to return a reply that says: "You aren't subscribed. Please think of subscribing. And more lines of text here (about 8 lines total)." I want the above to be inserted automatically only if I'm replying to a person from that mailing list, who isn't subscribed. I'm pretty sure I have to use some kind of procedure here. Do you see this as feasible with what tkrat offers now or do I have to write new code? L -- Laurent Duperval CLARKE'S THIRD LAW Any sufficiently advanced technology is indistinguishable from magic. From maf@tkrat.org Fri Jun 27 18:05:02 2003 From: maf@tkrat.org (maf@tkrat.org) Date: Fri, 27 Jun 2003 19:05:02 +0200 (CEST) Subject: userprocs question Message-ID: <20030628074724.1F6222FE8@tkrat.org> On 27 Jun, laurent.duperval@microcell.ca wrote: > I'm on a mailing list where people can submit questions event if they aren't > subscribed. Looking at the Delivered-To header, it will say "moderator" if > the person is not subscribed. In that case, and only in that case, I want to > return a reply that says: > > "You aren't subscribed. Please think of subscribing. And more lines of text > here (about 8 lines total)." > > I want the above to be inserted automatically only if I'm replying to a > person from that mailing list, who isn't subscribed. I'm pretty sure I have > to use some kind of procedure here. Do you see this as feasible with what > tkrat offers now or do I have to write new code? Aha, now I see what you want. There is no code to do this so you will have to code something yourself. I suggest you look at the reply functions in compose.tcl. /MaF From Diab Jerius Mon Jun 30 15:51:16 2003 From: Diab Jerius (Diab Jerius) Date: Mon, 30 Jun 2003 10:51:16 -0400 (EDT) Subject: solaris 2.8 & 20030530 snapshot & nanosleep Message-ID: <200306301451.h5UEpHRC021271@pelf.cfa.harvard.edu> Solaris 2.8 requires linking ratatosk2.2.so against -lrt in order to resolve nanosleep() (called by ratSender.c). I've accomplished this via brute force means (adding it to the link line creating the library); is there a means of getting configure to figure this out? Thanks, Diab -- Diab Jerius Harvard-Smithsonian Center for Astrophysics 60 Garden St, MS 70, Cambridge MA 02138 USA djerius@cfa.harvard.edu vox: 617 496 7575 fax: 617 495 7356 From Diab Jerius Mon Jun 30 16:39:50 2003 From: Diab Jerius (Diab Jerius) Date: Mon, 30 Jun 2003 11:39:50 -0400 (EDT) Subject: Green Squirrel Message-ID: <200306301539.h5UFdonY021769@pelf.cfa.harvard.edu> ---2130725163-851401618-1056987590=:21743 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE For years I accepted (albeit thinking it strange) that the tkRat icon was a green squirrel. Today I decided enough was enough and looked at the actual tkrat.xpm, and lo! it is in many colors, most noticeably brown, which is what the squirrels look like around here. I'm using ctwm under Solaris 2.8. I've never seen a problem with colors in icons for other programs, and the tkRat icon has always been green, since I started using tkRat a long time ago. Is there some obvious explanation? I append an image of the sea-sick squirrel. Diab ---2130725163-851401618-1056987590=:21743 Content-Type: IMAGE/XWD; NAME="squirrel.xwd" Content-Transfer-Encoding: BASE64 Content-Disposition: ATTACHMENT; FILENAME="squirrel.xwd" AAAAawAAAAcAAAACAAAAGAAAAEAAAABAAAAAAAAAAAEAAAAgAAAAAQAAACAA AAAgAAABAAAAAAQAAAD/AAD/AAD/AAAAAAAIAAABAAAAAQAAAABAAAAAQAAA BI4AAAM7AAAAAHh3ZHVtcAAAAAAAAAAAAAAABwEAAQEBAQEBAQEBBwEAAgIC AgICAgICBwEAAwMDAwMDAwMDBwEABAQEBAQEBAQEBwEABQUFBQUFBQUFBwEA BgYGBgYGBgYGBwEABwcHBwcHBwcHBwEACAgICAgICAgIBwEACQkJCQkJCQkJ BwEACgoKCgoKCgoKBwEACwsLCwsLCwsLBwEADAwMDAwMDAwMBwEADQ0NDQ0N DQ0NBwEADg4ODg4ODg4OBwEADw8PDw8PDw8PBwEAEBAQEBAQEBAQBwEAERER ERERERERBwEAEhISEhISEhISBwEAExMTExMTExMTBwEAFBQUFBQUFBQUBwEA FRUVFRUVFRUVBwEAFhYWFhYWFhYWBwEAFxcXFxcXFxcXBwEAGBgYGBgYGBgY BwEAGRkZGRkZGRkZBwEAGhoaGhoaGhoaBwEAGxsbGxsbGxsbBwEAHBwcHBwc HBwcBwEAHR0dHR0dHR0dBwEAHh4eHh4eHh4eBwEAHx8fHx8fHx8fBwEAICAg ICAgICAgBwEAISEhISEhISEhBwEAIiIiIiIiIiIiBwEAIyMjIyMjIyMjBwEA JCQkJCQkJCQkBwEAJSUlJSUlJSUlBwEAJiYmJiYmJiYmBwEAJycnJycnJycn BwEAKCgoKCgoKCgoBwEAKSkpKSkpKSkpBwEAKioqKioqKioqBwEAKysrKysr KysrBwEALCwsLCwsLCwsBwEALS0tLS0tLS0tBwEALi4uLi4uLi4uBwEALy8v Ly8vLy8vBwEAMDAwMDAwMDAwBwEAMTExMTExMTExBwEAMjIyMjIyMjIyBwEA MzMzMzMzMzMzBwEANDQ0NDQ0NDQ0BwEANTU1NTU1NTU1BwEANjY2NjY2NjY2 BwEANzc3Nzc3Nzc3BwEAODg4ODg4ODg4BwEAOTk5OTk5OTk5BwEAOjo6Ojo6 Ojo6BwEAOzs7Ozs7Ozs7BwEAPDw8PDw8PDw8BwEAPT09PT09PT09BwEAPj4+ Pj4+Pj4+BwEAPz8/Pz8/Pz8/BwEAQEBAQEBAQEBABwEAQUFBQUFBQUFBBwEA QkJCQkJCQkJCBwEAQ0NDQ0NDQ0NDBwEAREREREREREREBwEARUVFRUVFRUVF BwEARkZGRkZGRkZGBwEAR0dHR0dHR0dHBwEASEhISEhISEhIBwEASUlJSUlJ SUlJBwEASkpKSkpKSkpKBwEAS0tLS0tLS0tLBwEATExMTExMTExMBwEATU1N TU1NTU1NBwEATk5OTk5OTk5OBwEAT09PT09PT09PBwEAUFBQUFBQUFBQBwEA UVFRUVFRUVFRBwEAUlJSUlJSUlJSBwEAU1NTU1NTU1NTBwEAVFRUVFRUVFRU BwEAVVVVVVVVVVVVBwEAVlZWVlZWVlZWBwEAV1dXV1dXV1dXBwEAWFhYWFhY WFhYBwEAWVlZWVlZWVlZBwEAWlpaWlpaWlpaBwEAW1tbW1tbW1tbBwEAXFxc XFxcXFxcBwEAXV1dXV1dXV1dBwEAXl5eXl5eXl5eBwEAX19fX19fX19fBwEA YGBgYGBgYGBgBwEAYWFhYWFhYWFhBwEAYmJiYmJiYmJiBwEAY2NjY2NjY2Nj BwEAZGRkZGRkZGRkBwEAZWVlZWVlZWVlBwEAZmZmZmZmZmZmBwEAZ2dnZ2dn Z2dnBwEAaGhoaGhoaGhoBwEAaWlpaWlpaWlpBwEAampqampqampqBwEAa2tr a2tra2trBwEAbGxsbGxsbGxsBwEAbW1tbW1tbW1tBwEAbm5ubm5ubm5uBwEA b29vb29vb29vBwEAcHBwcHBwcHBwBwEAcXFxcXFxcXFxBwEAcnJycnJycnJy BwEAc3Nzc3Nzc3NzBwEAdHR0dHR0dHR0BwEAdXV1dXV1dXV1BwEAdnZ2dnZ2 dnZ2BwEAd3d3d3d3d3d3BwEAeHh4eHh4eHh4BwEAeXl5eXl5eXl5BwEAenp6 enp6enp6BwEAe3t7e3t7e3t7BwEAfHx8fHx8fHx8BwEAfX19fX19fX19BwEA fn5+fn5+fn5+BwEAf39/f39/f39/BwEAgICAgICAgICABwEAgYGBgYGBgYGB BwEAgoKCgoKCgoKCBwEAg4ODg4ODg4ODBwEAhISEhISEhISEBwEAhYWFhYWF hYWFBwEAhoaGhoaGhoaGBwEAh4eHh4eHh4eHBwEAiIiIiIiIiIiIBwEAiYmJ iYmJiYmJBwEAioqKioqKioqKBwEAi4uLi4uLi4uLBwEAjIyMjIyMjIyMBwEA jY2NjY2NjY2NBwEAjo6Ojo6Ojo6OBwEAj4+Pj4+Pj4+PBwEAkJCQkJCQkJCQ BwEAkZGRkZGRkZGRBwEAkpKSkpKSkpKSBwEAk5OTk5OTk5OTBwEAlJSUlJSU lJSUBwEAlZWVlZWVlZWVBwEAlpaWlpaWlpaWBwEAl5eXl5eXl5eXBwEAmJiY mJiYmJiYBwEAmZmZmZmZmZmZBwEAmpqampqampqaBwEAm5ubm5ubm5ubBwEA nJycnJycnJycBwEAnZ2dnZ2dnZ2dBwEAnp6enp6enp6eBwEAn5+fn5+fn5+f BwEAoKCgoKCgoKCgBwEAoaGhoaGhoaGhBwEAoqKioqKioqKiBwEAo6Ojo6Oj o6OjBwEApKSkpKSkpKSkBwEApaWlpaWlpaWlBwEApqampqampqamBwEAp6en p6enp6enBwEAqKioqKioqKioBwEAqampqampqampBwEAqqqqqqqqqqqqBwEA q6urq6urq6urBwEArKysrKysrKysBwEAra2tra2tra2tBwEArq6urq6urq6u BwEAr6+vr6+vr6+vBwEAsLCwsLCwsLCwBwEAsbGxsbGxsbGxBwEAsrKysrKy srKyBwEAs7Ozs7Ozs7OzBwEAtLS0tLS0tLS0BwEAtbW1tbW1tbW1BwEAtra2 tra2tra2BwEAt7e3t7e3t7e3BwEAuLi4uLi4uLi4BwEAubm5ubm5ubm5BwEA urq6urq6urq6BwEAu7u7u7u7u7u7BwEAvLy8vLy8vLy8BwEAvb29vb29vb29 BwEAvr6+vr6+vr6+BwEAv7+/v7+/v7+/BwEAwMDAwMDAwMDABwEAwcHBwcHB wcHBBwEAwsLCwsLCwsLCBwEAw8PDw8PDw8PDBwEAxMTExMTExMTEBwEAxcXF xcXFxcXFBwEAxsbGxsbGxsbGBwEAx8fHx8fHx8fHBwEAyMjIyMjIyMjIBwEA ycnJycnJycnJBwEAysrKysrKysrKBwEAy8vLy8vLy8vLBwEAzMzMzMzMzMzM BwEAzc3Nzc3Nzc3NBwEAzs7Ozs7Ozs7OBwEAz8/Pz8/Pz8/PBwEA0NDQ0NDQ 0NDQBwEA0dHR0dHR0dHRBwEA0tLS0tLS0tLSBwEA09PT09PT09PTBwEA1NTU 1NTU1NTUBwEA1dXV1dXV1dXVBwEA1tbW1tbW1tbWBwEA19fX19fX19fXBwEA 2NjY2NjY2NjYBwEA2dnZ2dnZ2dnZBwEA2tra2tra2traBwEA29vb29vb29vb BwEA3Nzc3Nzc3NzcBwEA3d3d3d3d3d3dBwEA3t7e3t7e3t7eBwEA39/f39/f 39/fBwEA4ODg4ODg4ODgBwEA4eHh4eHh4eHhBwEA4uLi4uLi4uLiBwEA4+Pj 4+Pj4+PjBwEA5OTk5OTk5OTkBwEA5eXl5eXl5eXlBwEA5ubm5ubm5ubmBwEA 5+fn5+fn5+fnBwEA6Ojo6Ojo6OjoBwEA6enp6enp6enpBwEA6urq6urq6urq BwEA6+vr6+vr6+vrBwEA7Ozs7Ozs7OzsBwEA7e3t7e3t7e3tBwEA7u7u7u7u 7u7uBwEA7+/v7+/v7+/vBwEA8PDw8PDw8PDwBwEA8fHx8fHx8fHxBwEA8vLy 8vLy8vLyBwEA8/Pz8/Pz8/PzBwEA9PT09PT09PT0BwEA9fX19fX19fX1BwEA 9vb29vb29vb2BwEA9/f39/f39/f3BwEA+Pj4+Pj4+Pj4BwEA+fn5+fn5+fn5 BwEA+vr6+vr6+vr6BwEA+/v7+/v7+/v7BwEA/Pz8/Pz8/Pz8BwEA/f39/f39 /f39BwEA/v7+/v7+/v7+BwEA////////////BwH///////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////k9tw////////////k9tw//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////+T23D/k9tw/5PbcP+T23D/k9tw /5PbcP+T23D/k9tw/5PbcP+T23D/k9tw//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////5PbcP+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/b0JD/5PbcP////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////5PbcP+T23D/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////////////////5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5Pb cP9vQkP/k9tw/29CQ/+T23D/k9tw//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD /5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP////////////////+T23D/k9tw//////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D///////// //+T23D/k9tw/5PbcP+T23D//////////////////////5PbcP////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////+T23D/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw//////+T23D/b0JD/5PbcP9vQkP/ k9tw/5PbcP///////////5PbcP9vQkP/k9tw//////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9v QkP/k9tw/5PbcP//////k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw//// //+T23D/k9tw/29CQ/+T23D///////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////5PbcP+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5Pb cP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D///// /5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP//////k9tw/5PbcP+T23D/ k9tw//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////+T23D/k9tw ////////////k9tw/5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw//////+T23D/k9tw/29CQ/+T 23D/k9tw/5PbcP+T23D/k9tw//////+T23D/b0JD/5PbcP////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////k9tw//////////////////////// ////k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29C Q/+T23D/b0JD/5PbcP///////////5PbcP+T23D/k9tw/5PbcP+T23D/b0JD /5PbcP//////k9tw/5PbcP+T23D///////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////k9tw/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/ //////////+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/b0JD/5PbcP////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw//////+T23D/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD /5PbcP9vQkP/k9tw////////////k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////k9tw/29CQ/+T23D/ b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP// ////k9tw/5PbcP+T23D/b0JD/5PbcP+T23D/k9tw/5PbcP+T23D/b0JD/5Pb cP9vQkP/k9tw/29CQ/+T23D/k9tw//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////k9tw/5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D//////5PbcP+T23D/b0JD /5PbcP9vQkP/k9tw/5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////k9tw /5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/k9tw//////+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP+T 23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D///////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5Pb cP+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD /5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw/5PbcP9vQkP/ k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9v QkP/k9tw/5PbcP////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////////////5PbcP+T23D/ b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/k9tw/5PbcP+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5Pb cP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw/5PbcP+T23D///// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////+T23D/b0JD/5PbcP9vQkP/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw /29CQ/+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ k9tw/5PbcP9vQkP/b0JD/29CQ/9vQkP/b0JD/5PbcP////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T 23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/b0JD/29C Q/+T23D/k9tw/5PbcP9vQkP/k9tw//////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////5PbcP//////k9tw/5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5Pb cP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP+T23D/b0JD/29CQ/9vQkP/b0JD/5PbcP9vQkP/ b0JD/5PbcP////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD /5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/b0JD/5PbcP9v QkP/k9tw/29CQ/9vQkP/b0JD/29CQ/+T23D/b0JD/5PbcP////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw/5Pb cP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP+T23D/k9tw/29CQ/+T23D/b0JD /5PbcP+T23D/b0JD/5PbcP////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////5PbcP9vQkP/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP+T23D/b0JD/29CQ/+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T 23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5Pb cP9vQkP/b0JD/29CQ/+T23D///////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////////////////5PbcP+T 23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5Pb cP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/ k9tw//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////5PbcP+T23D/k9tw/29CQ/+T23D/b0JD /5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP9vQkP/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5Pb cP+T23D/k9tw/5PbcP////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29C Q/+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD /5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ k9tw//////////////////////////////////////////////////////// ////////////////////////////////////////////////////k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP+T23D/ b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw//// //////////////////////////////////////////////////////////// /////////////////////////////////5PbcP+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP9vQkP/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw /5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP////////////////////// //////////////////////////////////////////////////////////// //////////////+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5Pb cP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD /5PbcP9vQkP/k9tw/5PbcP+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw//////////////////////// ////k9tw//////+T23D///////////////////////////////////////// ////////////////////////////////////////////////////////k9tw /5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw/29CQ/+T23D/ b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/b0JD/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5Pb cP+T23D/////////////////////////////////k9tw//////////////// /5PbcP////////////////////////////////////////////////////// ////////////////////////////////k9tw/5PbcP9vQkP/k9tw/29CQ/+T 23D/b0JD/5PbcP+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29C Q/+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/b0JD /29CQ/9vQkP/b0JD/29CQ/9vQkP/k9tw//////////////////////////// /////////////////////5PbcP////////////////+T23D///////////// //////////////////////////////////////////////////////////// /////////////5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw /29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/ k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw/29CQ/9vQkP/b0JD/29CQ/9v QkP/b0JD/5PbcP////////////////////////////////+T23D/k9tw/5Pb cP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw//////////////// //////////////////////////////////////////////////////+T23D/ k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP+T23D/b0JD/5PbcP9v QkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5Pb cP9vQkP/k9tw/29CQ/+T23D/k9tw/29CQ/9vQkP/b0JD/29CQ/9vQkP/k9tw //////////////////////+T23D/k9tw/29CQ/9vQkP/b0JD/29CQ/9vQkP/ b0JD/29CQ/+T23D/b0JD/5PbcP+T23D///////////////////////////// ////////////////////////////////////k9tw/29CQ/+T23D/b0JD/5Pb cP9vQkP/k9tw/5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw /5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP+T23D/b0JD/29CQ/9vQkP/b0JD/5PbcP////////////////// ////k9tw/29CQ/9vQkP/b0JD/29CQ/9vQkP/b0JD/29CQ/9vQkP/k9tw/29C Q/9vQkP/k9tw//////////////////////////////////////////////// /////////////////5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T 23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5Pb cP9vQkP/b0JD/29CQ/9vQkP/k9tw/5PbcP///////////5PbcP9vQkP/b0JD /29CQ/+T23D/b0JD/29CQ/+T23D/k9tw/5PbcP9vQkP/b0JD/5PbcP////// //////////////////////////////////////////////////////////+T 23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29C Q/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/29CQ/9vQkP/ b0JD/5PbcP+T23D///////////+T23D/b0JD/29CQ/9vQkP/k9tw/5PbcP+T 23D/b0JD/5PbcP+T23D/b0JD/29CQ/+T23D///////////////////////// ////////////////////////////////////////k9tw/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/ k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/b0JD/29CQ/+T23D/b0JD/5Pb cP//////k9tw/29CQ/9vQkP/b0JD/5PbcP+T23D/k9tw/5PbcP+T23D/b0JD /29CQ/9vQkP/k9tw//////////////////////////////////////////// /////////////////////5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T 23D/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw/29CQ/+T23D/b0JD/5Pb cP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD /5PbcP+T23D/b0JD/29CQ/9vQkP/k9tw/5PbcP+T23D//////5PbcP9vQkP/ b0JD/29CQ/+T23D/b0JD/29CQ/9vQkP/b0JD/29CQ/9vQkP/b0JD/5PbcP// //////////////////////////////////////////////////////////// //+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP+T23D/b0JD /5PbcP+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/9v QkP/b0JD/5PbcP9vQkP/k9tw//////+T23D/k9tw/29CQ/9vQkP/k9tw/29C Q/9vQkP/b0JD/29CQ/9vQkP/b0JD/5PbcP+T23D///////////////////// ////////////////////////////////////////////k9tw/5PbcP+T23D/ b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP+T 23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/5PbcP9vQkP/b0JD/29CQ/+T23D/b0JD /5PbcP///////////5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/ k9tw/5PbcP+T23D///////////////////////////////////////////// //////////////////////////////+T23D/b0JD/5PbcP9vQkP/k9tw/29C Q/+T23D/k9tw/5PbcP9vQkP/k9tw/5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw /29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/b0JD/29CQ/+T23D/k9tw/5PbcP////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/ k9tw/29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/29C Q/9vQkP/k9tw/29CQ/+T23D///////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////////////////////////5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5Pb cP+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD /5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/29CQ/9vQkP/k9tw/29CQ/+T23D/ //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////k9tw/5PbcP+T23D/b0JD /5PbcP9vQkP/k9tw/5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/ b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T 23D/k9tw/29CQ/9vQkP/b0JD/5PbcP+T23D/k9tw//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T 23D/k9tw/5PbcP9vQkP/k9tw/5PbcP+T23D/b0JD/5PbcP9vQkP/k9tw/29C Q/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/29CQ/9vQkP/b0JD /29CQ/+T23D/b0JD/5PbcP////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////+T23D/k9tw/29CQ/+T23D/b0JD/5PbcP+T23D/k9tw /29CQ/+T23D/k9tw/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/ k9tw/29CQ/+T23D/k9tw/29CQ/9vQkP/b0JD/29CQ/+T23D/k9tw/29CQ/+T 23D///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP9v QkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/k9tw/29C Q/9vQkP/k9tw/29CQ/+T23D/b0JD/29CQ/+T23D/b0JD//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////+T23D/k9tw//// ////////////////////////////////////////k9tw/5PbcP+T23D/k9tw /5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/29CQ/+T23D/ k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////+T23D/k9tw/5PbcP9vQkP/b0JD/5PbcP9v QkP/b0JD/5PbcP9vQkP/k9tw/29CQ/+T23D/b0JD/5PbcP9vQkP/k9tw/5Pb cP+T23D/b0JD/5PbcP9vQkP/k9tw//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP+T23D/k9tw /29CQ/+T23D/k9tw/5PbcP+T23D/k9tw/5PbcP///////////5PbcP+T23D/ k9tw//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////+T23D/k9tw//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////// ---2130725163-851401618-1056987590=:21743-- From laurent.duperval@microcell.ca Mon Jun 30 16:53:45 2003 From: laurent.duperval@microcell.ca (Laurent Duperval) Date: Mon, 30 Jun 2003 11:53:45 -0400 Subject: userprocs question In-Reply-To: <20030628074724.1F6222FE8@tkrat.org> References: <20030628074724.1F6222FE8@tkrat.org> Message-ID: <3F005D09.5000003@microcell.ca> maf@tkrat.org wrote: > Aha, now I see what you want. There is no code to do this so you will have > to code something yourself. I suggest you look at the reply functions in > compose.tcl. > Ok, I'll take a stab at it. L -- Laurent Duperval "Do you believe in the devil? You know, a supreme evil being dedicated to the temptation, corruption, and destruction of man?" "I'm not sure that man needs the help." -Calvin & Hobbes From jarausch@igpm.rwth-aachen.de Fri May 30 07:37:00 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Fri, 30 May 2003 08:37:00 +0200 (CEST) Subject: grouping by dragging the right mouse button Message-ID: <20030917095329.39FAAA7E9F@numa-i.igpm.rwth-aachen.de> Having updated to the current CVS version one features seems to have gone - grouping a bunch of messages by dragging the right mouse button. Since I still reveive a lot of spam I normally group these message en bloque and move them to a big spam file which is analyzed lateron by bogofilter. Now I can only use the middle mouse button to add a single message to the group since dragging scrolls the window. I do like the feature to drag the window but is there a means like or plus dragging which gives the previous feature? Many thanks for a hint, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From jarausch@igpm.rwth-aachen.de Fri May 30 07:31:02 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Fri, 30 May 2003 08:31:02 +0200 (CEST) Subject: printing iso-8859-1 problems Message-ID: <20030917095329.0E255A7EAD@numa-i.igpm.rwth-aachen.de> On 28 May, maf@tkrat.org wrote: > This is due to a bug (or to put a more positive spin on it, the fact > that TkRat expects too much of the local system). A fix is in the cvs > (current and v2_1_branch). Many thanks, it works great! Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From jarausch@igpm.rwth-aachen.de Mon Jun 2 15:16:10 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Mon, 02 Jun 2003 16:16:10 +0200 (CEST) Subject: html browser - how to configure Message-ID: <20030917095329.BFE68A7EAE@numa-i.igpm.rwth-aachen.de> Hi, how can I configure the exact calling of my WWW-browser. In I can only enter the command name (in my case opera) Now tkrat calls opera like opera -remote openURL(http://www.netlib.org/na-net,new-window) but that doesn't work here since the z-shell interferes I need just opera -newwindow http://www.netlib.org/na-net How can configure this. I've tried under 'Opera command' opera -newwindow http://%u but '%u' isn't expanded. Many thanks for a hint, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From jarausch@igpm.rwth-aachen.de Fri May 30 08:36:26 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Fri, 30 May 2003 09:36:26 +0200 (CEST) Subject: grouping by dragging the right mouse button Message-ID: <20030917095329.66470A7EA1@numa-i.igpm.rwth-aachen.de> On 30 May, maf@tkrat.org wrote: > On 30 May, jarausch@igpm.rwth-aachen.de wrote: >> Having updated to the current CVS version one features >> seems to have gone - grouping a bunch of messages by >> dragging the right mouse button. > > The bindings have changed to accomodate the context menu. But you can > use Shift-<1> and drag. > Yes, thanks, although it needs getting used to it since I have to drag into the opposite direction. Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From jarausch@igpm.rwth-aachen.de Tue May 27 11:25:14 2003 From: jarausch@igpm.rwth-aachen.de (jarausch@igpm.rwth-aachen.de) Date: Tue, 27 May 2003 12:25:14 +0200 (CEST) Subject: printing iso-8859-1 problems Message-ID: <20030917095327.529D9A7E7C@numa-i.igpm.rwth-aachen.de> Hi, I have a problem with TkRat's postscript (pretty) printing. TkRat does show the German umlaut correctly (the message has Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1) but when printing the message most umlauts get lost. Curiously 2 of them (o-umlaut and u-umlaut) are printed. (Printing the original file that has been mailed by a2ps on the same printer works just fine) How can I change this? Many thanks for a hint, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany