Re: very confused
On Tue, Dec 15, 1998 at 08:57:47PM +, [EMAIL PROTECTED] wrote: > Have there been duplicates? I suppose that you first need to move your > mailfile /var/spool/mail/my_account to your $HOME and then start > formail/procmail as procmail appends the mails while cat reads them again > and again?! That's about what happens, the emails are appended to the mail file again and again. Procmail's man page includes a script which filters your mail without this problem. I use it quite often when I fiddle with my recipes and it works great.
Re: very confused
Have there been duplicates? I suppose that you first need to move your mailfile /var/spool/mail/my_account to your $HOME and then start formail/procmail as procmail appends the mails while cat reads them again and again?! Alex. On Tue, 15 Dec 1998, Shao Zhang wrote: > Hi all, > I am very confused. please help. I am trying to filt my current > mail to different folders. > > cat /var/spool/mail/my_account | formail -s procmail. > > All of sudden, it filts out over 5000 thousands emails to my > account. The file size changed from 500K to 20MB. Some of those mails were > even from last yr
very confused
Hi all, I am very confused. please help. I am trying to filt my current mail to different folders. In pine, I have about 200 old mails... so I did cat /var/spool/mail/my_account | formail -s procmail. All of sudden, it filts out over 5000 thousands emails to my account. The file size changed from 500K to 20MB. Some of those mails were even from last yr So what happened?? Thx for any help in advance... Regards, Shao.
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
Hello, > >I left the source as it was, but added some softlinks, like > >/usr/include/X11/GL -> /usr/include/GL > > Me to, but I had to edit out some refs. to a /GL/GLw/ directory included > file - the header file was actually under /GL, and Glw doesn't exist on > my system. I used softlinks throughout, but I don't remember them all... /usr/include/X11/GLw -> GL > But try compiling the vopengl stuff - all the makefiles are set up for > windows, even though I downloaded the X version of V. I didn't have any other problems - it might have helped that I used Mesa, from a Debian package, so I didn't have to compile OpenGL myself. mesag2 2.6-3 A 3-D graphics library which uses the OpenGL mesag2-dev 2.6-3 Development library for Mesa [libc6]. > Do you know what's happened to the V mailing list? It just says it's > moving on the V site. No idea. Didn't try it (I was after compiling FREEdraft, and V was just a step on the way). > >slink isn't released yet, anyway. > > Indeed, but it is clear from this list that many people with time to > spare are upgrading anyway... With emphasis on "time to spare" :-) > I think I've got what's up with the different compilers now, but since > compiling free source is such a typical Unix tradition, I feel that the > documentation on what's going on should be more widely publcicised, Hmm, perhaps a tutorial kind of thing. * download file into a subdir * tar xvzf file.tgz (if your tar can handle that) * read README, INSTALL etc * basic make usage, common make targets, editing makefiles * understanding error messages * ... Especially the error messages can often be very obscure-looking and still tell you exactly what's wrong! Jiri <[EMAIL PROTECTED]>
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
>Subject: Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused* >To: [EMAIL PROTECTED] (Martin Waller) >Date: Tue, 8 Dec 1998 16:30:50 +1100 (EST) >Cc: debian-user@lists.debian.org >From: Jiri Baum <[EMAIL PROTECTED]> > >Hello, > >> Over the weekend, I downlaoded V 1.20 onto /usr/local/. > >Did the same last night. > >> I tried compiling it and after finding out that I needed all the OpenGl >> stuff and isntalling that to (V. annoying by the way - had even to edit some >> of the source code to get rid of those probelms) > >I left the source as it was, but added some softlinks, like >/usr/include/X11/GL -> /usr/include/GL > Me to, but I had to edit out some refs. to a /GL/GLw/ directory included file - the header file was actually under /GL, and Glw doesn't exist on my system. >> But then I got the make error message: >> >> In vbglcnv.h:51:Invalid storage class specifiers decalared in friend >> functions > >Get rid of the word "static" on that line. > This is what i eventually did, after finally gettinbg a clue as to what it meant. >> I didn't have a clue what this meant even after viewing the two friend >> functions alluded to. > >"storage class" means auto, static, register or extern; there are two >modifiers, const and volatile. > >In this case, there's only one storage specifier on the whole line (unless >there's something in macros), so that had to be what it was complaining about >:-) > >Getting rid of it fixed the problem. I hope it didn't break anything (but >FREEdraft compiled and ran okay, so I guess not). > But try compiling the vopengl stuff - all the makefiles are set up for windows, even though I downloaded the X version of V. Do you know what's happened to the V mailing list? It just says it's moving on the V site. >> Being naive enough to try anything, and having heard of all sorts of >> problems with egcs and g++, I decided to scrap g++2.8 and put g++2.7.2 on. >> (I had egcs 2.90.29, dated 19980515). Eeventually, I did get it to compile with egcc and g++ (2.8). I had to edit the Config.mk to use CC=egcc instead of CC=gcc so as not to mix and match g++2.8 and GCC2.7.2. > >I didn't want to do that, because FREEdraft claimed to use fancy >exception-handling that 2.7.x doesn't grok - and that's why I was getting V. There's also a way on the ftp site a way to compile V without the OpenGL stuff. But hell - if it's there why not play. > >> (I'm on a HAMM systen still - it took me 4 goes to get a successful upgrade >> from bo to that, so I'm not ready to slink it yet). > >slink isn't released yet, anyway. Indeed, but it is clear from this list that many people with time to spare are upgrading anyway... I think I've got what's up with the different compilers now, but since compiling free source is such a typical Unix tradition, I feel that the documentation on what's going on should be more widely publcicised, like in the general info about installing/upgrading to HAMM. > > >Jiri <[EMAIL PROTECTED]> > __ Get Your Private, Free Email at http://www.hotmail.com
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
On Wed, Dec 09, 1998 at 00:13:16 -0500, Ed Cogburn wrote: > > >Read /usr/doc/gcc/README.Debian . > It didn't say *why* we have an apparent fork in compiler development. It doesn't contain a full history of the free software movement either, as that's out of scope for that document too. > Since the gcc compiler is at the core of Linux (behind only the kernel > itself in importance), having a semi-permanent fork in development, ala > emacs/xemacs, is the last thing we need. First, forks aren't necessarily bad. Read e.g. http://www.chiark.greenend.org.uk/~ijackson/sane98-talk.ps or ESR's writings. The EGCS project has brought nearly all of gcc's lost children together again. That's progress. Second, de facto there is no fork. The FSF gcc development is dead (or at least smelling /very/ funny), though the FSF doesn't admit it yet. EGCS is alive and well. [As a small example, FSF gcc 2.8.1's C++ handling is more or less the same as EGCS 1.0.x's. Of the C++ bugs reported against Debian's EGCS 1.0.3 g++ package, half were fixed in EGCS 1.1, in a period shorter than a Debian release cycle. 2.8.1 is still the latest FSF gcc.] Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
Martin Waller wrote: > > > > >Read /usr/doc/gcc/README.Debian . > > > > I did but was still confused :( > > It didn't say *why* we have an apparent fork in compiler development. Since the gcc compiler is at the core of Linux (behind only the kernel itself in importance), having a semi-permanent fork in development, ala emacs/xemacs, is the last thing we need. -- Ed C.
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
Hello, > Over the weekend, I downlaoded V 1.20 onto /usr/local/. Did the same last night. > I tried compiling it and after finding out that I needed all the OpenGl > stuff and isntalling that to (V. annoying by the way - had even to edit some > of the source code to get rid of those probelms) I left the source as it was, but added some softlinks, like /usr/include/X11/GL -> /usr/include/GL > But then I got the make error message: > > In vbglcnv.h:51:Invalid storage class specifiers decalared in friend > functions Get rid of the word "static" on that line. > I didn't have a clue what this meant even after viewing the two friend > functions alluded to. "storage class" means auto, static, register or extern; there are two modifiers, const and volatile. In this case, there's only one storage specifier on the whole line (unless there's something in macros), so that had to be what it was complaining about :-) Getting rid of it fixed the problem. I hope it didn't break anything (but FREEdraft compiled and ran okay, so I guess not). > Being naive enough to try anything, and having heard of all sorts of > problems with egcs and g++, I decided to scrap g++2.8 and put g++2.7.2 on. > (I had egcs 2.90.29, dated 19980515). I didn't want to do that, because FREEdraft claimed to use fancy exception-handling that 2.7.x doesn't grok - and that's why I was getting V. > (I'm on a HAMM systen still - it took me 4 goes to get a successful upgrade > from bo to that, so I'm not ready to slink it yet). slink isn't released yet, anyway. Jiri <[EMAIL PROTECTED]>
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
>
>Read /usr/doc/gcc/README.Debian .
>
I did but was still confused :(
>> Being naive enough to try anything, and having heard of all sorts of
>> problems with egcs and g++, I decided to scrap g++2.8 and put
g++2.7.2 on.
>> (I had egcs 2.90.29, dated 19980515).
>
>g++2.7.2 is intended only for compiling code that cannot be compiled
with
>EGCS gcc. It's not supposed to be easy to install or use.
>
>> is v using some
>> non-standard c++ shit that breaks on 'modern' compilers?
>
>That's more likely.
>
>> I suspect egcs
>
>EGCS has proven itself to be a very good C++ compiler so far.
>
OK - then I'd like to understand the error message that came up
('Invalid storage class specifier in friend function declarations').
Here's the code up to the friend functions decls. where the
aforementioned error message is generated:
//===
// vglcnv.h GL Canvas C++ class .h file - X11R5
//
// Copyright (C) 1995,1996 Bruce E. Wampler
//
// This file is part of the V C++ GUI Framework, and is covered
// under the terms of the GNU Library General Public License,
// Version 2. This library has NO WARRANTY. See the source file
// vapp.cxx for more complete information about license terms.
//===
#ifndef VGLCNV_H
#define VGLCNV_H
#include
#include
//
extern "C"
{
//
static void CGLKeyInEV(Widget w, XtPointer client_data, XEvent* event,
char *x);
//
// OpenGL stuff here
//
void CgraphicsInit(Widget w, XtPointer clientData, XtPointer call);
//
#include// Xt OpenGL drawing area widget.
#include
#include
#include
//
}
//
const unsigned int vGL_Default = 0;
const unsigned int vGL_RGB = 0x0001;
const unsigned int vGL_Alpha = 0x0002;
const unsigned int vGL_Indexed = 0x0004;
const unsigned int vGL_DoubleBuffer = 0x0008;
const unsigned int vGL_Stereo = 0x0010;
const unsigned int vGL_Stencil = 0x0020;
const unsigned int vGL_Accum = 0x0040;
const unsigned int vGL_Depth = 0x0080;
//
class vWindow; // we are part of a window
//
class vBaseGLCanvasPane : public vCanvasPane
{
//
friend void CgraphicsInit(Widget w, XtPointer clientData, XtPointer
call);
friend static void CGLKeyInEV(Widget w, XtPointer client_data, XEvent*
event, char *x);
//the two functions here cause the problem with egcs!
(etc.)
__
Get Your Private, Free Email at http://www.hotmail.com
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
On Mon, Dec 07, 1998 at 01:50:48 -0800, Martin Waller wrote: > I am stunningly confused about the whole c and c++ suite thing that's > going on (I'm still in HAMM - it's *not * the __register_frame_info > stuff!). Read /usr/doc/gcc/README.Debian . > Being naive enough to try anything, and having heard of all sorts of > problems with egcs and g++, I decided to scrap g++2.8 and put g++2.7.2 on. > (I had egcs 2.90.29, dated 19980515). g++2.7.2 is intended only for compiling code that cannot be compiled with EGCS gcc. It's not supposed to be easy to install or use. > So, please help me - why couldn't egcs g++ compile v? Is that version > (like some others it would seem...) broken? Or is v using some > non-standard c++ shit that breaks on 'modern' compilers? That's more likely. > I suspect egcs EGCS has proven itself to be a very good C++ compiler so far. > I am afraid but understand nothing. Would upgrading to the version > referred to in the __register_frame_info FAQ work or what You'll need libc6 2.0.7u-7.1 ; older version either have the __register_frame_info problem, or conflict with essential packages. Ray -- ART A friend of mine in Tulsa, Okla., when I was about eleven years old. I'd be interested to hear from him. There are so many pseudos around taking his name in vain. - The Hipcrime Vocab by Chad C. Mulligan
g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
Hi, I am stunningly confused about the whole c and c++ suite thing that's going on (I'm still in HAMM - it's *not * the __register_frame_info stuff!). Here's my story and a plea for a clear explanation of what's what and what I need to compile kernels, c++ toolkits and stuff. Over the weekend, I downlaoded V 1.20 onto /usr/local/. I tried compiling it and after finding out that I needed all the OpenGl stuff and isntalling that to (V. annoying by the way - had even to edit some of the source code to get rid of those probelms), the compile seemed like it would work. But then I got the make error message: In vbglcnv.h:51:Invalid storage class specifiers decalared in friend functions I didn't have a clue what this meant even after viewing the two friend functions alluded to. Being naive enough to try anything, and having heard of all sorts of problems with egcs and g++, I decided to scrap g++2.8 and put g++2.7.2 on. (I had egcs 2.90.29, dated 19980515). Well, of course no end of conflicts came up (had to remove libdbm++ and stuff), and further more I had to leave some 2.8 thing installed (libg++2.8? libstdc++2.8? libstdc++2.8-dev?libg++2.8-dev? - can't remember as at the time I was in a frenzy of confusion). Eventually I got the downgrade done, and of course the makefile for v complained about there being no g++, so I changed the definition in the file to g++272, and hallelujah! the thing worked. Phew. What a marathon that was and how pleased i was myself to have got the v library compiled after *so many* problems. Back in the old days, with a 1.2.13 kernel and v 1.14, it was easy! So, please help me - why couldn't egcs g++ compile v? Is that version (like some others it would seem...) broken? Or is v using some non-standard c++ shit that breaks on 'modern' compilers? I suspect egcs I am afraid but understand nothing. Would upgrading to the version referred to in the __register_frame_info FAQ work or what (I'm on a HAMM systen still - it took me 4 goes to get a successful upgrade from bo to that, so I'm not ready to slink it yet). Please help. I love linux, and debian is the dist. I've chosen (i'm happy with that), but it just seems there is so much undocumented stuff that can hgo wrong and it takes a great mental effort and lateral thinking to get the stuff i want working! Sorry for the ramble - if you've got this far thanks, Martin __ Get Your Private, Free Email at http://www.hotmail.com
