Re: c email libraries
On Fri, Mar 21, 2003 at 10:41:53PM +, David M. Wilson tried to flame: On Fri, Mar 21, 2003 at 05:47:01PM +, Lusercop wrote: And some do. I didn't realize your mum was subscribed to the list. [...] expert in every field. The fact is, you are 6 years older than me, still act like a child, and have some sort of massive superiority complex. [...] As for Matthew, if you haven't worked it out by now, I have absolutely no respect for you and don't want to read another e-mail by you. The only reason I'm replying tonight is because learning to troll is more interesting than moving boxes into the attic. Once again, apologies all. I'm having trouble reconciling this. -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: c email libraries
On Fri, Mar 21, 2003 at 06:31:57PM +, Nicholas Clark wrote: On Fri, Mar 21, 2003 at 05:47:01PM +, Lusercop wrote: I haven't seen a SunOS install in, what, 6-7 years. Perhaps you mean Solaris. I'm aware of the world outside linux/perl, and bzip2 is actually bash-2.05$ uname -sr SunOS 5.6 I'm aware of what the Solaris kernel reports itself as. I know that there are bits of what is now called Solaris that are also called SunOS. Mostly though, when people refer to SunOS, they are tending to refer to the BSD- derived OS from Sun which is SunOS = 4. Solaris is much more System Vish in many ways. And I *haven't* seen a SunOS install in that long. I've seen lots of 2.6 (not much 2.5.1 anymore), and 8 and 9 (surprisingly not much 7). I don't necessarily agree that everything that isn't the latest and greatest must be best (an opinion which David appeared to be ascribing to me), but I haven't seen a BSD-ish SunOS in about that long. I'd be surprised if many useful installations of it actually existed in the real world. You could give the benefit of the doubt on that one. I could have done, I agree, but David decided to show his complete cluelessness in other respects. and I launched into an attack of why you were wrong. There are valid points Personally I prefer reasoned arguments, sarcasm, irony and damning with feint praise (even if I can't spell it). But that's just my opinion. Was my argument not reasoned? I provided evidence to back my position up, it's carefully thought out, even if not typed out. -- Lusercop.net - LARTing Lusers everywhere since 2002
Solaris 1 (was Re: c email libraries)
On Fri, Mar 21, 2003 at 10:41:53PM +, David M. Wilson wrote: No, I mean SunOS. [much other stuff snipped, including the rest of that paragraph] Is one of the root nameservers still running on SunOS? Or is that just an urban myth? Nicholas Clark
Re: c email libraries
On Friday, March 21, 2003 15:51 + David M. Wilson wrote: On Fri, Mar 21, 2003 at 02:37:24PM +, Lusercop wrote: Oh, absolutely, and I'm also well aware in this case that Dave has them. (bloody hell, I'm standing up for Cantrell, what's wrong with me?). That's OK, I won't hold it against you :-) In this case, an end-user (effectively) having trouble installing a library from source is a good indication of a failure on the part of the Linux distribution in use. If you'd been paying attention you would have noticed me say OS X. If it isn't Linux, then take a look around, there are hundreds of sources of pre-compiled binaries (although maybe only tens of trustable sources). If you'd been paying attention you would have noticed me say fink. I never implied David was complaining about the lack of the autotools, or the packaging format (he didn't even mention this). My point was that while c-client's build system and build instructions are unorthodox, it is not up to the end user to judge it's quality by these factors. It isn't up to the user to judge the quality of a piece of software by its documentation? What planet do you hail from? On Earth, poorly documented software is generally considered to be bad software. If it lacks make install - and this is a fairly new package, from an era when that is the usual thing to do regardless of what you think about GNUisms - then the author really should write the usual place to put my headers is in directory $FOO. at the bare minimum. You will also not be aware that before ranting here, I asked for help on another mailing list. They were just as stumped about what was going wrong with c-client as I was. If you are a user and you cannot build a package, there's a good chance you shouldn't be trying to in the first place. I know that plenty of us joke about requiring computer licences just like driving licences, but ... [on compress] To provide the most hassle for any sysadmin who has to install it. Try looking for a gzip or bzip2 binary on a SunOS or IRIX default install. There's a whole world outside Linux/perl, Matthew. SunOS? Coo, haven't seen one of those for a LONG time! I'll grant you that gzip is rare on SunOS. SunOS is a rather old platform. On Solaris, on the other hand, gzip has always been available when I've needed it. There are trustworthy sources for all of the most useful GNU tools, and I install many of them myself. Not because I'm a Linux/GNU fanboy, but because they're bloody useful tools and AFAIC, having gzip on a machine is just as essential as having compress, tar and an editor. Don't talk to me. Please don't reply on-list either, a lot of people don't like listening to you. And a whole lot of people DO like him and think that despite the Lusercop's - errm, idiosyncrasies - he's a nice bloke who has plenty of useful things to say. If you don't want to hear from him, use the awesome power of procmail. -- David Cantrell, experimenting with Weird Mac Mail Client
Re: Solaris 1 (was Re: c email libraries)
On Saturday, Mar 22, 2003, at 14:25 Europe/London, Nicholas Clark wrote: On Fri, Mar 21, 2003 at 10:41:53PM +, David M. Wilson wrote: No, I mean SunOS. [much other stuff snipped, including the rest of that paragraph] Is one of the root nameservers still running on SunOS? Or is that just an urban myth? I heard that admin myth and suspect its used to run until recently. A quick google finds nothing but my guess is that it was probably Paul Vixie's one at the ISC. -- Steve Mynott [EMAIL PROTECTED]
Re: Solaris 1 (was Re: c email libraries)
On Sat, Mar 22, 2003 at 05:22:09PM +, Steve Mynott wrote: On Saturday, Mar 22, 2003, at 14:25 Europe/London, Nicholas Clark wrote: Is one of the root nameservers still running on SunOS? Or is that just an urban myth? I heard that admin myth and suspect its used to run until recently. Might it have been the one that switched to running AIX during Sun's We're the dot in .com campaign? -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: c email libraries
On Fri, Mar 21, 2003 at 12:49:56AM +, David M. Wilson wrote: On Thu, Mar 20, 2003 at 10:16:44PM +, David Cantrell wrote: you how to compile it, but not what it calls the resulting library file, where to put it, or where the usual place for its header files is. And heaven forbid that you could just make install. The UW c-client library seems to be maintained by a staunch traditionalist, it's packaged with compress ffs! A traditionalist whose idea of programming style is almost as good as djb's. If I remember correctly, (and bearing the above comment in mind), said library is designed for static linking, aka: cc -c -o cclient.o ../cclient/cclient.c cc -I../cclient -o myprog $(MYPROG_OBJS) cclient.o Yuck. WOEFULLY incomplete: their way of saying no, we're not using GNU f**king autotools, and no, we're not writing a Makefile that will output shared libraries on every platform. Oh, I dislike autotools, don't get me wrong, but not including information about headers, API and library output *IS* woefully incomplete, by any definition of the word. I know of many packages that *don't* use autotools and still manage to get this kind of simple thing correct. Eventually I got fed up with dealing with software packaged by fuckwits, I think basic C compiler / linker knowledge is an essential part of system administration, and consider those who lack it to be fuckwits. Oh, absolutely, and I'm also well aware in this case that Dave has them. (bloody hell, I'm standing up for Cantrell, what's wrong with me?). Basic linker knowledge should not extend to what the does this guy think he's doing with this file. If the C is as badly written as Mark Crispin's piece of junk, then you won't have a hope in hell of doing anything with it unless you're an expert programmer. The same could be said for make, a rather neat and portable way of keeping files in sync. Hahahahahahahahahahahahahaha You are joking, aren't you. Please tell me you are. How many different versions of make do you think exist, with their respective bugs. It is not actually possible to write a portable makefile that has any kind of conditional dependency. At all. Cursing people more skilled and/or intelligent than yourself is the easiest thing to do on the planet[0], and just because a package doesn't Mark may be more intelligent than me, I'm not sure if he is or not. However, his coding style leaves exceedingly large amounts to be desired. His ability to package software in any kind of sane way appears similar. The UW-IMAP server is a disaster area, and C-Client is a fair approximation at a guide of how *not* to program. follow the GNU/Linux empire's way of tar.bz2 + 200k of m4 drivel, doesn't mean it's of poor quality. Nobody said that it needed to have autoconf, and a lot of people don't like it, including myself. It does, however, seem to me that the C-Client code as it stands is indefensible. The build instructions are, as has been said already, woefully inadequate. The tar.bz2 argument is a straw man, in this case, it's mainly about file size, bzip2 is, quite simply, a better compression algorithm than compress. Next you'll be saying that someone using crypt(1) is in the right, because they're a traditionalist, even though the attacks against it are well known. [0] I'm guilty of it here -- I guess now that c-client is packaged with compress for portability. To provide the most hassle for any sysadmin who has to install it. I was still forming an opinion as I wrote this e-mail, so yes, it does read a little messed up! :) No, it just reads as if you don't know what you're talking about. -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: c email libraries
On Fri, Mar 21, 2003 at 02:37:24PM +, Lusercop wrote: A traditionalist whose idea of programming style is almost as good as djb's. In the real world, it is often the ugly hack that gets things done. As for DJB's style of coding, I don't understand most of it myself but according to some skilled sources, it's quite nice. Said skilled sources are the sort of people I don't get into arguments with, because I always loose. :) If I remember correctly, (and bearing the above comment in mind), said library is designed for static linking, aka: cc -c -o cclient.o ../cclient/cclient.c cc -I../cclient -o myprog $(MYPROG_OBJS) cclient.o Yuck. Yeah, no ./configure. Oh, I dislike autotools, don't get me wrong, but not including information about headers, API and library output *IS* woefully incomplete, by any definition of the word. I know of many packages that *don't* use autotools and still manage to get this kind of simple thing correct. As with any build tree, it's a build tree. I try to avoid doing builds myself now-adays, and know better than to complain when I don't get someone elses concept. Oh, absolutely, and I'm also well aware in this case that Dave has them. (bloody hell, I'm standing up for Cantrell, what's wrong with me?). I wasn't attacking Cantrell, I was simply stating a relevant opinion. Basic linker knowledge should not extend to what the does this guy think he's doing with this file. If the C is as badly written as Mark Crispin's piece of junk, then you won't have a hope in hell of doing anything with it unless you're an expert programmer. In this case, an end-user (effectively) having trouble installing a library from source is a good indication of a failure on the part of the Linux distribution in use. If it isn't Linux, then take a look around, there are hundreds of sources of pre-compiled binaries (although maybe only tens of trustable sources). The same could be said for make, a rather neat and portable way of keeping files in sync. Hahahahahahahahahahahahahaha You are joking, aren't you. Please tell me you are. How many different versions of make do you think exist, with their respective bugs. It is not actually possible to write a portable makefile that has any kind of conditional dependency. At all. Well done for stating the complete obvious. Would you have laughed like a child had I said awk is a pretty portable text extraction tool? ha ha ha LuserCopOs' awk doesn't let you change the IFS. Oh no, it's completely importable now. Cursing people more skilled and/or intelligent than yourself is the easiest thing to do on the planet[0], and just because a package doesn't Mark may be more intelligent than me, I'm not sure if he is or not. However, his coding style leaves exceedingly large amounts to be desired. Said Jesus to his children. His ability to package software in any kind of sane way appears similar. The UW-IMAP server is a disaster area, and C-Client is a fair approximation at a guide of how *not* to program. Once again, it is used successfully all over the place. Dry your eyes and write a 'better' implementation if you are unhappy with it. follow the GNU/Linux empire's way of tar.bz2 + 200k of m4 drivel, doesn't mean it's of poor quality. Nobody said that it needed to have autoconf, and a lot of people don't like it, including myself. It does, however, seem to me that the C-Client code as it stands is indefensible. The build instructions are, as has been said already, woefully inadequate. The tar.bz2 argument is a straw man, in this case, it's mainly about file size, bzip2 is, quite simply, a better compression algorithm than compress. I never implied David was complaining about the lack of the autotools, or the packaging format (he didn't even mention this). My point was that while c-client's build system and build instructions are unorthodox, it is not up to the end user to judge it's quality by these factors. The build system is just that -- end-users should not be building their own binaries most of the time. If you are a user and you cannot build a package, there's a good chance you shouldn't be trying to in the first place. Next you'll be saying that someone using crypt(1) is in the right, because they're a traditionalist, even though the attacks against it are well known. No, that's sacrificing functionality (security) for portability. Why the hell do you always end up ranting about security? [0] I'm guilty of it here -- I guess now that c-client is packaged with compress for portability. To provide the most hassle for any sysadmin who has to install it. Try looking for a gzip or bzip2 binary on a SunOS or IRIX default install. There's a whole world outside Linux/perl, Matthew. No, it just reads as if you don't know what you're talking about. Don't talk to me. Please don't reply on-list either, a lot of people don't like listening to you. David.
Re: c email libraries
On Fri, Mar 21, 2003 at 03:51:16PM +, David M. Wilson wrote: On Fri, Mar 21, 2003 at 02:37:24PM +, Lusercop wrote: A traditionalist whose idea of programming style is almost as good as djb's. In the real world, it is often the ugly hack that gets things done. As for DJB's style of coding, I don't understand most of it myself but according to some skilled sources, it's quite nice. Said skilled I've read bits of it, when I wanted to know in advance that it was going to do what I needed it to do, and the documentation was not up to scratch. Trust me on this, or look at it yourself, but we've already had this discussion here recently. The code isn't either. It's write-only code. CClient, is, IMO, pretty similar. Virtually every line has at least 3 side-effects, and there is no sensible modularisation. sources are the sort of people I don't get into arguments with, because I always loose. :) 'lose', or perhaps 'luse'. I have read this stuff, and I'm prepared to hold my opinion on it. I notice that no one replied to my challenge to explain the constants in datetime.c. That's the kind of code we're talking about. If I remember correctly, (and bearing the above comment in mind), said library is designed for static linking, aka: cc -c -o cclient.o ../cclient/cclient.c cc -I../cclient -o myprog $(MYPROG_OBJS) cclient.o Yuck. Yeah, no ./configure. Surprisingly enough, that's not what I'm going yuck about. I have a problem with the compile this thing from outside my source tree to an object file inside my build tree so that I can link it. And, as you're someone with fairly advanced C Compiler options understanding, you'd know that the -I is irrelevant in the situation in which you have it, you need it for building the dependencies of that final line. UNIX has had dynamic linking for well over 20 years, anyone who doesn't use it because he's a traditionalist is kidding himself. There are many reasons to prefer it over static linking. Oh, I dislike autotools, don't get me wrong, but not including information about headers, API and library output *IS* woefully incomplete, by any definition of the word. I know of many packages that *don't* use autotools and still manage to get this kind of simple thing correct. As with any build tree, it's a build tree. I try to avoid doing builds myself now-adays, and know better than to complain when I don't get someone elses concept. That's an interesting attitude. I don't think it's a useful one, though. Kind of sympathetic magic, almost. Oh, absolutely, and I'm also well aware in this case that Dave has them. (bloody hell, I'm standing up for Cantrell, what's wrong with me?). I wasn't attacking Cantrell, I was simply stating a relevant opinion. You quoted his message, it certainly looked like you were. Basic linker knowledge should not extend to what the does this guy think he's doing with this file. If the C is as badly written as Mark Crispin's piece of junk, then you won't have a hope in hell of doing anything with it unless you're an expert programmer. In this case, an end-user (effectively) having trouble installing a library from source is a good indication of a failure on the part of the Linux distribution in use. !?!?! Where on EARTH did I say *anything* about Linux? There are many other UNIXes out there, and yes, I use more than just Linux, in fact the main one I use *isn't* linux. I'm certainly not convinced of this assertion though. If it isn't Linux, then take a look around, there are hundreds of sources of pre-compiled binaries (although maybe only tens of trustable sources). Erm, we were talking about building from source, why do you introduce this irrelevant argument. The same could be said for make, a rather neat and portable way of keeping files in sync. Hahahahahahahahahahahahahaha You are joking, aren't you. Please tell me you are. How many different versions of make do you think exist, with their respective bugs. It is not actually possible to write a portable makefile that has any kind of conditional dependency. At all. Well done for stating the complete obvious. Would you have laughed like a child had I said awk is a pretty portable text extraction tool? ha No. You will notice no conditional dependency syntax elements in: http://www.opengroup.org/onlinepubs/007904975/utilities/make.html This means that any such things are inherently unportable. If you'd have come to Schwern's talk on MakeMaker, you'll have heard that one of the biggest problems with it is trying to spit out the right kind of syntax on each individual platform. ha ha LuserCopOs' awk doesn't let you change the IFS. Oh no, it's completely importable now. You will also want to notice the -F option in: http://www.opengroup.org/onlinepubs/007904975/utilities/awk.html I don't think your point is valid. Cursing people more skilled and/or intelligent than yourself is the easiest
Re: c email libraries
On Fri, Mar 21, 2003 at 05:47:01PM +, Lusercop wrote: I haven't seen a SunOS install in, what, 6-7 years. Perhaps you mean Solaris. I'm aware of the world outside linux/perl, and bzip2 is actually bash-2.05$ uname -sr SunOS 5.6 You could give the benefit of the doubt on that one. and I launched into an attack of why you were wrong. There are valid points Personally I prefer reasoned arguments, sarcasm, irony and damning with feint praise (even if I can't spell it). But that's just my opinion. Nicholas Clark
Re: c email libraries
On Friday 21 March 2003 17:47, Lusercop wrote: On Fri, Mar 21, 2003 at 03:51:16PM +, David M. Wilson wrote: Please don't reply on-list either, a lot of people don't like listening to you. And some do. Those who don't know how to use their killfiles. Since your email style is clearly intended to get at least someones back up, I'm not sure why you are surprised when it happens. A lot of what you say is of course quite correct, but I cant help thinking that the way you put it across is designed to get this sort of reaction. No doubt you have your reasons ... Surely just going down to the pub an knocking over peoples pints would provide a similar distraction without the need to think too hard? Lusercop.net - LARTing Lusers everywhere since 2002 2002? .. bloddy newbies ;) -- Robin Szemeti
Re: c email libraries
On Fri, Mar 21, 2003 at 05:47:01PM +, Lusercop wrote: I've read bits of it, when I wanted to know in advance that it was going to do what I needed it to do, and the documentation was not up to scratch. Trust me on this, or look at it yourself, but we've already had this discussion here recently. The code isn't either. It's write-only code. CClient, is, IMO, pretty similar. Virtually every line has at least 3 side-effects, and there is no sensible modularisation. A smart little man (who didn't code at the time) once said to me coding is an art form, co-operative coding is just fucked. Whether you agree or not with DJBs style of coding is irrelevant, the mere fact that qmail has been so successful is testament in itself to DJBs programming ability. 'lose', or perhaps 'luse'. I have read this stuff, and I'm prepared to hold my opinion on it. I notice that no one replied to my challenge to explain the constants in datetime.c. Here's a quarter, go call someone that cares. Surprisingly enough, that's not what I'm going yuck about. ./lusercop -vv Irrelevant spiel. UNIX has had dynamic linking for well over 20 years, anyone who doesn't use it because he's a traditionalist is kidding himself. There are many reasons to prefer it over static linking. Would you please stop emphasizing traditionalist? More spiel, once again you are completely missing the point - I said IIRC (IMVHFO, AFAIK, FOAD) c-client was designed for static compilation, eg. as PHP uses it. I don't give a shiny penny about your UNIX linking knowledge. You quoted his message, it certainly looked like you were. No. You assumed I was. If it isn't Linux, then take a look around, there are hundreds of sources of pre-compiled binaries (although maybe only tens of trustable sources). Erm, we were talking about building from source, why do you introduce this irrelevant argument. Users should not have to build, you idiot. I don't proof-read pointless e-mails. Well done for stating the complete obvious. Would you have laughed like a child had I said awk is a pretty portable text extraction tool? ha No. ./lusercop --aphorism -vvv I don't think your point is valid. You're back in your ideal world again. Standards are just that, not the gospel that everyone must comply to. If you are a user and you cannot build a package, there's a good chance you shouldn't be trying to in the first place. OK, I agree with you on this. But if many experienced sysadmins find c-client an annoyance, then perhaps there's something in that, no? They should be e-mailling their nearest developer friend asking for a package, or filing a bug report. It's my job, as you are no doubt aware, given that you've looked up who !! - I know quite a few penetration testers, and all of them are able to have a reasonable conversation without mentioning how insecure my MUA/X server/Distro/back garden is. !! I haven't seen a SunOS install in, what, 6-7 years. Perhaps you mean Solaris. No, I mean SunOS. Stop assuming you are superior to everyone else. In the real world (ie. not your head) computers exist that may not be bang up to date, your view seems to be the Microsoft one, ie. if it's older than two years it's deprecated. !! I'll talk to who I like. If you don't like what I have to say then killfile me. I don't mind if you do or don't listen. I do object to being told what and what Try typing with a little less anger, it results in less typos. And some do. I didn't realize your mum was subscribed to the list. There are valid points to be debated here, but if you're just going to say I'm right, don't talk to me anymore, then I think that you lose all credibility in such a debate. Maybe I didn't pad my e-mail out with IMHO enough, but then I shouldn't need to. You invite a nasty reply when you try to act like an expert in every field. The fact is, you are 6 years older than me, still act like a child, and have some sort of massive superiority complex. If the list admin doesn't like what I write, then it is up to him to say you shouldn't have said that or don't post that. It is not up to you to say the lurkers support me in email, and therefore you shouldn't post anymore. I don't want you to go away, I just wish you didn't get on like such a twat. As it happens, I haven't actually written a line of perl in my life. I have been listening to the perl lists for about 6 months now, after attending a talk on perl 6, with which I was exponentially more impressed than perl 5. I'm very easily tempted into a list war, and apologize to those who have had to put up with these irrelevant postings. As for Matthew, if you haven't worked it out by now, I have absolutely no respect for you and don't want to read another e-mail by you. The only reason I'm replying tonight is because learning to troll is more interesting than moving boxes into the attic. Once again, apologies all. ./dw
Re: c email libraries
On Wednesday, March 19, 2003 10:36 + Simon Wistow [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2003 at 10:17:34AM -, Blackwell, Lee [IT] said: http://freshmeat.net/projects/mail_cclient/?topic_id=35%2C809 It's a perl module thing to encapsulate the cclient stuff. I recently had to install c-client on this box so I could install mailsync. The instructions that come with c-client are WOEFULLY incomplete. It tells you how to compile it, but not what it calls the resulting library file, where to put it, or where the usual place for its header files is. And heaven forbid that you could just make install. Unfortunately the interface has a fair to middling suckage factor and, when I was helping with Acmemail it was *the* number one installation problem since you had you had to pop out of the automagic CPAN installation and then get people to do something like 1. Download the latest verison of cclient 2. look in the make file for your architecture code (say slx for linux) 3. make slx Although it could be several other alternatives for Linux, and both nxt and osx work for OS X, both needing different options in addition to the architecture code. Eventually I got fed up with dealing with software packaged by fuckwits, and spent three days installing and compiling fink/unstable, which has a mailsync (and c-client library of course) package which Just Works. -- David Cantrell
Re: c email libraries
On Thu, Mar 20, 2003 at 10:16:44PM +, David Cantrell wrote: I recently had to install c-client on this box so I could install mailsync. The instructions that come with c-client are WOEFULLY incomplete. It tells you how to compile it, but not what it calls the resulting library file, where to put it, or where the usual place for its header files is. And heaven forbid that you could just make install. The UW c-client library seems to be maintained by a staunch traditionalist, it's packaged with compress ffs! If I remember correctly, (and bearing the above comment in mind), said library is designed for static linking, aka: cc -c -o cclient.o ../cclient/cclient.c cc -I../cclient -o myprog $(MYPROG_OBJS) cclient.o WOEFULLY incomplete: their way of saying no, we're not using GNU f**king autotools, and no, we're not writing a Makefile that will output shared libraries on every platform. Eventually I got fed up with dealing with software packaged by fuckwits, I think basic C compiler / linker knowledge is an essential part of system administration, and consider those who lack it to be fuckwits. The same could be said for make, a rather neat and portable way of keeping files in sync. Cursing people more skilled and/or intelligent than yourself is the easiest thing to do on the planet[0], and just because a package doesn't follow the GNU/Linux empire's way of tar.bz2 + 200k of m4 drivel, doesn't mean it's of poor quality. David. [0] I'm guilty of it here -- I guess now that c-client is packaged with compress for portability. I was still forming an opinion as I wrote this e-mail, so yes, it does read a little messed up! :)
Re: c email libraries
On Tue, Mar 18, 2003 at 06:44:43PM +, Marty Pauley said: and another one that implements jwz's threading algorith, Dunno about that. I thought he provided the C code himself. There's a link to the Java source of Grendel but that's pretty app specific. Anyway, just for a bit of context - One of the things that Siesta needs is a decent mail archiver. I have the idea for one sketched out in my head but it basically wants a fast way of threading the messages. As previously mentioned Mbox::Manager::Thread (or whatever it's called) is slow and a bit of a baroque interface and Mail::Thread is slow and, err, doesn't work. JWZ's code ia able to thread 10,000 messages in less than half a second on a low-end (90 MHz) Pentium. The other two cannot. So my thought was - hey *somebody* must have implemented a shared library that takes a load of messages or structs and threads them. So I tried to check http://www.ccan.org but apparently C doesn't have a comprehensive archive network but I thought I'd check first with the list. So my options are to patch Mail::Thread or pester Simon to patch Mail::Thread (or Mail::Mbox which is what I think he said was breaking it) and then profile it to see why it's so $diety awful slow. Or write a C implementation and put a wrapper round it. Or hope that somebody else decides that might be fun. Simon -- it's a short link to a dead king
Re: c email libraries
On Wed, Mar 19, 2003 at 08:00:37AM +, Simon Wistow wrote: On Tue, Mar 18, 2003 at 06:44:43PM +, Marty Pauley said: and another one that implements jwz's threading algorith, Dunno about that. I thought he provided the C code himself. There's a link to the Java source of Grendel but that's pretty app specific. Anyway, just for a bit of context - One of the things that Siesta needs is a decent mail archiver. I have No, no it doesn't. What it could do with is intelligent use of an existing one, which means one less wheel to reinvent. What we're currently using is delivery into maildirs (take two, watch your locking headaches melt away) which are then webified periodically using mhonarc. Folks can see results of that process here: http://siesta.unixbeard.net/siesta/archive/siesta-dev http://siesta.unixbeard.net/siesta/archive/siesta-commit But! I hear you say, there's no easy searching of that, to which I'll hypothetically answer google +site:siesta.unixbeard.net and then someone will say something like google doesn't reindex quite as often as I want it to. To which I'll probably mumble something about webglimpse, or whatever it is that the perl5-porters web archive uses. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/ See, I don't need you puny humans, I can preempt the whole thing in my head. JWZ's code ia able to thread 10,000 messages in less than half a second on a low-end (90 MHz) Pentium. The other two cannot. So just use that code, or the hardware hammer. -- Richard Clamp [EMAIL PROTECTED]
Re: c email libraries
There's a link to the Java source of Grendel but that's pretty app specific. And a little free time and a friendly neighbourhood search-engine provides: Balsa's implementation: http://web.mit.edu/ghudson/dev/nsanch/balsa-1.2.pre2/src/balsa-index-threading.c I'm sure it can't be *THAT* hard to find the Evolution equivalent? +Pete -- Much may be made of a Scotchman, if he be caught young. -- Samuel Johnson
Re: c email libraries
On Wed, Mar 19, 2003 at 09:51:19AM +, Peter Sergeant said: There's a link to the Java source of Grendel but that's pretty app specific. And a little free time and a friendly neighbourhood search-engine provides: Yeah, I found that too. Unfortunately it's a bit tied in to glib and Balsa. Otoh it wouldn't be too hard to rip it out and clean it up but I've got too many other things on my plate. Simon
Re: c email libraries
On Wed Mar 19 08:00:37 2003, Simon Wistow wrote: So my options are to patch Mail::Thread or pester Simon to patch Pester Simon to patch it. Tell us what doesn't work, and we'll pester him too :-) -- Marty
RE: c email libraries
I'm convinced that there *must* exists somewhere a C library to parse emails Yeah, the one that is used by things such as WU's IMAP. 'cclient' I think. How about this: http://freshmeat.net/projects/mail_cclient/?topic_id=35%2C809 It's a perl module thing to encapsulate the cclient stuff. Lee
Re: c email libraries
On Wed, Mar 19, 2003 at 08:52:04AM +, Richard Clamp said: No, no it doesn't. What it could do with is intelligent use of an existing one, which means one less wheel to reinvent. Yeah, for the moment, mHonarc works ok but it's old and crufty (I'm damned if I could work out how to patch it do one thing that I wanted a while back) And I like my system better :) One day I'll write it. -- it's a short link to a dead king
Re: c email libraries
On Wed, Mar 19, 2003 at 10:17:34AM -, Blackwell, Lee [IT] said: http://freshmeat.net/projects/mail_cclient/?topic_id=35%2C809 It's a perl module thing to encapsulate the cclient stuff. I love Mail::Clcient - it's fast, complete and does a shed load of stuff. Unfortunately the interface has a fair to middling suckage factor and, when I was helping with Acmemail it was *the* number one installation problem since you had you had to pop out of the automagic CPAN installation and then get people to do something like 1. Download the latest verison of cclient 2. look in the make file for your architecture code (say slx for linux) 3. make slx 4. Download the latest version of Mail::Cclient 5. perl Makefile.PL CCLIENT_DIR=../imap-$version/c-client/ c.f http://www.astray.com/acmemail/stable/documentation.xml whereas I want it to be easy to install. Simon
Re: c email libraries
* at 18/03 18:44 + Marty Pauley said: On Tue Mar 18 17:48:12 2003, Simon Wistow wrote: and another one that implements jwz's threading algorith, Dunno about that. I thought he provided the C code himself. If you look at his page[0] on the algorithm he states: Sadly, my C implementation of this algorithm is not available, because it was purged during the 4.0 rewrite, and Netscape refused to allow me to free the 3.0 source code so I guess not. Bad netscape/aol/time warner. s [0] http://www.jwz.org/doc/threading.html
Re: c email libraries
On Wed, Mar 19, 2003 at 10:19:56AM +, Marty Pauley said: Pester Simon to patch it. Tell us what doesn't work, and we'll pester him too :-) I sent in the test failures and got this reponse which is fair enough. Simon Wistow said : [snip test failures] Failed Test Stat Wstat Total Fail Failed List of Failed - t/1.t 2 512 32 66.67% 2-3 t/2.t 2 512 32 66.67% 2-3 t/3.t 2 512 32 66.67% 2-3 Failed 3/3 test scripts, 0.00% okay. 6/9 subtests failed, 33.33% okay. make: *** [test_dynamic] Error 2 I'd hazard a guess that it's a problem with the test cases not with the module but I could be wrong ... Probably a Mail::Box problem. I'm blaming all I can on Mark Overmeer right now. Works OK for me with an absolutely fresh install, and Mail::Message version 2.035. Simon
Re: c email libraries
On Wed, Mar 19, 2003 at 10:36:31AM +, Simon Wistow wrote: On Wed, Mar 19, 2003 at 10:17:34AM -, Blackwell, Lee [IT] said: http://freshmeat.net/projects/mail_cclient/?topic_id=35%2C809 It's a perl module thing to encapsulate the cclient stuff. I love Mail::Clcient - it's fast, complete and does a shed load of stuff. Presumably it's just a pity about the underlying c-client library, which is utterly utterly horrendous. It has already had large numbers of buffer overflows and uses lots of horrendously complex statements in order to... erm, well, I'm not quite sure why it uses them. But suffice to say it's pretty horrendous. If you can avoid using c-client for mail handling, this is good. I'm not sure there's anything particularly comparable, though, other than as someone already pointed out, getting the innards of say, mutt. -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: c email libraries
On Wed, Mar 19, 2003 at 10:17:46AM +, Simon Wistow wrote: On Wed, Mar 19, 2003 at 09:51:19AM +, Peter Sergeant said: There's a link to the Java source of Grendel but that's pretty app specific. And a little free time and a friendly neighbourhood search-engine provides: Yeah, I found that too. Unfortunately it's a bit tied in to glib and what's wrong with glib? I've found it to be a fantastic library for some of those little niggly things that ought to be in core libc and aren't... or is the point that it's an extra dependency and therefore bad? Balsa. Well, fair enough. Otoh it wouldn't be too hard to rip it out and clean it up but I've got too many other things on my plate. Simon /joel
Re: c email libraries
On 19 Mar 2003 at 11:04, Simon Wistow wrote: Probably a Mail::Box problem. I'm blaming all I can on Mark Overmeer right now. So does lathos, from what I remember on IRC a couple of weeks ago. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: c email libraries
On Tue, Mar 18, 2003 at 05:48:12PM +, Simon Wistow wrote: I'm convinced that there *must* exists somewhere a C library to parse emails and another one that implements jwz's threading algorith, apt-get source mutt Paul -- Paul Makepeace ... http://paulm.com/ What is justice? Avatars pick my brian. -- http://paulm.com/toys/surrealism/
Re: c email libraries
On Tue, 2003-03-18 at 17:48, Simon Wistow wrote: I'm convinced that there *must* exists somewhere a C library to parse emails and another one that implements jwz's threading algorith, But I'll be bggered if I can find one. Does such a beast exist? you asked him? -- Dave Hodgkinson [EMAIL PROTECTED]
Re: c email libraries
Simon Wistow sent the following bits through the ether: Does such a beast exist? Dunno, but Simon's Perl Email Project looks promising: http://search.cpan.org/author/SIMON/Email-Simple/ Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Always forgive your enemies, nothing annoys them so much
Re: c email libraries
On Tue Mar 18 17:48:12 2003, Simon Wistow wrote: I'm convinced that there *must* exists somewhere a C library to parse emails http://www.gnu.org/software/mailutils/ I'm not sure how stable it is. and another one that implements jwz's threading algorith, Dunno about that. I thought he provided the C code himself. -- Marty
