[courier-users] Re: Initial release: Cone - COnsole Newsreader And Emailer
Sam Varshavchik
>
>> * A built-in text editor for editing new messages, with search/replace and
>> spell checking (requires aspell or pspell).
>
> Is there support for an external text editor?
No.
> Compiling curses.C
> curses.C: In function `static void Curses::mbtow(const char *,
> vector<__wchar_t,allocator<__wchar_t> > &)':
> curses.C:447: implicit declaration of function `int wcwidth(...)'
> make[1]: *** [curses.o] Error 1
> make[1]: Leaving directory `/home/jnelson/downloads/cone-0.50/curses'
> make: *** [all] Error 2
> jnelson@honker curses $ grep wcwidth /usr/include/ncurses
> ncurses.h ncurses_dll.h
> jnelson@honker curses $ grep wcwidth /usr/include/ncurses*
> jnelson@honker curses $ grep wcwidth /usr/include/*
> /usr/include/wchar.h:extern int wcwidth (wchar_t __c) __THROW;
> jnelson@honker curses $
wchar.h is being included from mycurses.H
You need to look at your wchar.h to see what magic concoction it needs to
define this function.
> Including wchar.h does /not/ help.
Right. Read the include file, and figure out what exactly it wants, to get
that definition.
> Neither does #defining __USE_X_OPEN (or whatever it is) and including
> wchar.h
>
> I manually edited the curses_config.h to not #define HAVE_WCWIDTH
>
> That helped.
> Then, I get this:
>
> Compiling cursesmainscreen.C
> cursesmainscreen.C: In method
> `CursesMainScreen::Lock::Lock(CursesMainScreen *, bool = false)':
> cursesmainscreen.H:34: `unsigned int CursesMainScreen::lockcnt' is
> private
> cursesmainscreen.C:43: within this context
> cursesmainscreen.C: In method `CursesMainScreen::Lock::~Lock()':
> cursesmainscreen.H:34: `unsigned int CursesMainScreen::lockcnt' is
> private
> cursesmainscreen.C:50: within this context
> make[1]: *** [cursesmainscreen.o] Error 1
> make[1]: Leaving directory `/home/jnelson/downloads/cone-0.50/curses'
>
> jnelson@honker curses $ g++ --version
> 2.95.3
> jnelson@honker curses $ gcc --version
> 2.95.3
> jnelson@honker curses $
Put a 'friend class Lock' in cursesmainscreen.H, right after the class
definition.
You really need to bump up your gcc. It's fairly ancient.
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
courier-users mailing list
courie...@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Sam Varshavchik
> On Wednesday 28 May 2003 10:14, Sam Varshavchik wrote:
>> Cone is a text-based mail client. Cone seamlessly handles multiple POP3,
>> IMAP accounts, and local mail folders. Cone is also a simple newsreader.
>> Cone is designed to be foolproof enough to be used by inexperienced users,
>> but also offers advanced features for power users.
>
> You also need to add %{_datadir}/rootcerts to the %files section of the spec.
I don't believe that to be necessary. The configure script, unless Courier
is already installed, will arrange the certificates to go into
datadir/cone/rootcerts, which will be packaged.
Jesse Keating
> I don't believe that to be necessary. The configure script, unless Courier
> is already installed, will arrange the certificates to go into
> datadir/cone/rootcerts, which will be packaged.
It's not. Initial rpmbuild -ta of the package spewed every file out of
/usr/share/rootcerts as being unpackaged. This is on a RHL9 box mind you.
[jkeating@ender rootcerts]$ rpm -qf aba-ecom-root-ca.pem
cone-0.50-1.9
[jkeating@ender rootcerts]$ pwd
/usr/share/rootcerts
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
Sam Varshavchik
> On Wednesday 28 May 2003 12:00, Sam Varshavchik wrote:
>> I don't believe that to be necessary. The configure script, unless Courier
>> is already installed, will arrange the certificates to go into
>> datadir/cone/rootcerts, which will be packaged.
>
> It's not. Initial rpmbuild -ta of the package spewed every file out of
> /usr/share/rootcerts as being unpackaged. This is on a RHL9 box mind you.
>
> [jkeating@ender rootcerts]$ rpm -qf aba-ecom-root-ca.pem
> cone-0.50-1.9
> [jkeating@ender rootcerts]$ pwd
> /usr/share/rootcerts
All right. To get this working right, just manually add the
--with-certdb=/usr/share/cone/rootcerts option to the configure script.
I'll try to fix this and put up a new build in a few hours.
Sam Varshavchik
>> Put a 'friend class Lock' in cursesmainscreen.H, right after the class
>> definition.
>
> OK, everything in curses compiles now.
>
> Now, I get this:
>
> Compiling mail.C
> mail.C:254: macro `LIBMAIL_THROW_NODEBUG' used without args
> mail.C:569: macro `LIBMAIL_THROW_NODEBUG' used without args
> mail.C:586: macro `LIBMAIL_THROW_NODEBUG' used without args
> mail.C:680: macro `LIBMAIL_THROW_NODEBUG' used without args
> mail.C:700: macro `LIBMAIL_THROW_NODEBUG' used without args
> make[1]: *** [mail.o] Error 1
>
> Which translates to line 41 of mail.H:
>
> #define LIBMAIL_THROW_NODEBUG(x) throw x
>
> line 254 (and the others mentioned) look like:
> LIBMAIL_THROW();
> and
> libmail_config.h has
> #define LIBMAIL_THROW LIBMAIL_THROW_NODEBUG
Would changing libmail_config.h to
#define LIBMAIL_THROW(x) LIBMAIL_THROW_NODEBUG(x)
... make gcc shut up, now?
> Manually (temporarily) changing each of the macros to just 'throw'
> allows a bit more, but /then/ I get (in libmail):
>
> In file included from mail.H:36,
> from mail.C:7:
> objectmonitor.H:93: `mail' does not have a nested type named `obj'
Change this line from "class mail::obj" to "class obj".
> mail.H:243: virtual outside class declaration
>
> and a boatload more, at which point compilation stops.
>
>> You really need to bump up your gcc. It's fairly ancient.
>
> If cone is uncompilable with what I've got, I guess I'll wait until it
> is, or until I get a new gcc as part of the distro.
Don't give up that easy, just yet.
Jesse Keating
> All right. To get this working right, just manually add the
> --with-certdb=/usr/share/cone/rootcerts option to the configure script.
>
> I'll try to fix this and put up a new build in a few hours.
Cool. Thanks Sam, you rock!
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (www.mondorescue.org)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-------------------------------------------------------
Sam Varshavchik
> Sam Varshavchik wrote:
>>
>> * Handles local mail folders, maildirs, IMAP and POP3 accounts, and
>> Usenet newsgroups. All folders are shown in a hierarchical tree-like
>> display.
>
> Does it also, perchance, support message threading with a similar
> hierarchical display?
No. It's folder index display is similar to pine's.
Sam Varshavchik
> On Wed, 28 May 2003, Sam Varshavchik wrote:
>
>> > Which translates to line 41 of mail.H:
>> >
>> > #define LIBMAIL_THROW_NODEBUG(x) throw x
>> >
>> > line 254 (and the others mentioned) look like:
>> > LIBMAIL_THROW();
>> > and
>> > libmail_config.h has
>> > #define LIBMAIL_THROW LIBMAIL_THROW_NODEBUG
>>
>> Would changing libmail_config.h to
>>
>> #define LIBMAIL_THROW(x) LIBMAIL_THROW_NODEBUG(x)
>>
>> ... make gcc shut up, now?
>
> No. The error is that the macro requires an argument to be sent to it,
> and it's being used without an argument. At this time I'm not aware of
> any reasonable solution. Consider instead changing mail.H's definition to:
>
> #define LIBMAIL_THROW_NODEBUG(x...) throw x
>
> This appears to work.
I changed how this macro is defined in a somewhat different way, in build
20030528. It probably still won't work, as it is, but you should be able to
#define LIBMAIL_NIL, and then use LIBMAIL_NIL as an arg in *.C
>> > Manually (temporarily) changing each of the macros to just 'throw'
>> > allows a bit more, but /then/ I get (in libmail):
>> >
>> > In file included from mail.H:36,
>> > from mail.C:7:
>> > objectmonitor.H:93: `mail' does not have a nested type named `obj'
>>
>> Change this line from "class mail::obj" to "class obj".
>
> And I get:
>
> In file included from mail.C:8:
> sync.H:208: invalid base class
I don't see a problem there. The base class is perfectly valid. I fear
that namespace resolution in your gcc is broken. Try to replace all
instances of mail::folder with ::mail::folder, in this header file, or with
a plain "folder".
Bruno Postle
> Gordon Messmer writes:
> > Does it also, perchance, support message threading with a
> > similar hierarchical display?
>
> No. It's folder index display is similar to pine's.
Pine has a threaded index:
http://www.washington.edu/pine/changes/4.44-to-4.50.html
--
Bruno
Sam Varshavchik
> On Thu, 29 May 2003, Sam Varshavchik wrote:
>
>> I don't see a problem there. The base class is perfectly valid. I fear
>> that namespace resolution in your gcc is broken. Try to replace all
>> instances of mail::folder with ::mail::folder, in this header file, or with
>> a plain "folder".
>
> I appreciate your helping out here, but I've tried to compile the more
> recent cone release on a newer machine (gcc 2.96 / RedHat 7.3) and it's
> no go there, either. Both issues remain: the wchar.h issue and the
> above issue.
Independently I've confirmed that on 7.3 you need to define _GNU_SOURCE.
CPPFLAGS='-D_GNU_SOURCE=1'
./configure [options]
Sam Varshavchik
> On Thu 29-May-2003 at 09:36:29AM -0400, Sam Varshavchik wrote:
>> Gordon Messmer writes:
>> > Does it also, perchance, support message threading with a
>> > similar hierarchical display?
>>
>> No. It's folder index display is similar to pine's.
>
> Pine has a threaded index:
>
> http://www.washington.edu/pine/changes/4.44-to-4.50.html
Do any distributions even ship pine 4.5x? The word on the street is that
it's fairly buggy.
There is no IMAP provision to retrieve message threading information, so it
needs to be done by hand.
Bruno Postle
> On Thu, 29 May 2003, Sam Varshavchik wrote:
>
> > information, so it needs to be done by hand.
>
Indeed, courier-imap itself implements IMAP threading quite nicely.
--
Bruno
Sam Varshavchik
> On Thu, 29 May 2003, Sam Varshavchik wrote:
>
>> Jon Nelson writes:
>>
>> > On Thu, 29 May 2003, Sam Varshavchik wrote:
>> >
>> >> I don't see a problem there. The base class is perfectly valid. I fear
>> >> that namespace resolution in your gcc is broken. Try to replace all
>> >> instances of mail::folder with ::mail::folder, in this header file, or with
>> >> a plain "folder".
>> >
>> > I appreciate your helping out here, but I've tried to compile the more
>> > recent cone release on a newer machine (gcc 2.96 / RedHat 7.3) and it's
>> > no go there, either. Both issues remain: the wchar.h issue and the
>> > above issue.
>>
>> Independently I've confirmed that on 7.3 you need to define _GNU_SOURCE.
>>
>> CPPFLAGS='-D_GNU_SOURCE=1'
>> ./configure [options]
>
> I'll give that a try.
> In the meantime, on another machine, I did get it to compile without any
> special invocations or patching. However, it will not run. cone
> complains about the CHARSET. I've tried setting the environment
> variable CHARSET to various values ('us-ascii' and others), without
> success. What gives here?
It's in the FAQ.
CHARSET=ISO-8859-1
or
LANG=en_US
Sam Varshavchik
> On Thu 29-May-2003 at 02:35:39 -0500, Jon Nelson wrote:
>> On Thu, 29 May 2003, Sam Varshavchik wrote:
>>
>> > There is no IMAP provision to retrieve message threading
>> > information, so it needs to be done by hand.
>>
>> What about the THREADING extension to IMAP?
>
> Indeed, courier-imap itself implements IMAP threading quite nicely.
The IMAP THREAD extension implements threading entirely on the server. The
client never actually receives the threading information. The server simply
lists the messages in threaded order, and the client displays them
accordingly.
I believe that implementing this type of functionality in the server is the
wrong approach. Server resources are limited. You have several hundred
clients, and now the server has to burn CPU cycles sorting folders for each
client. Meanwhile, the clients are sitting idle, with plenty of CPU power to
spare.
A server has better things to do than to fuss around with the order of the
individual messages shown on each client's screen. This is why Courier-IMAP
has an option to disable this extension, forcing clients to do their own
dirty work.
Cone tries to place as little load on the server as possible. If you note,
paging through a large folder, or changing the sorting order, does not
involve any server activity. All header information is saved in memory.
With a server-centric approach, re-threading a folder with a thousand
messages will require at least 5Kb's worth of network traffic: the client
request, and the server response, consisting of message numbers in the
arranged sort order. So now the client has to send the command, spin its
wheels, hoping that the server is not already loaded, then reading a list of
all message numbers, in thread order.
If both Cone and pine are asked to sort a folder, by the time Cone finishes
sorting its folder, the poor server, where pine has logged into, is yet to
receive pine's command.