Linux-Development-Sys Digest #909, Volume #6 Tue, 29 Jun 99 19:14:26 EDT
Contents:
Re: Why not C++ (Greg Comeau)
Re: GLIBC 2.1.1: still problems in dynamic loader (latest patches applied) (Andreas
Jaeger)
Re: Getting a Soundblaster Live Value to work ("Mark")
Re: Why not C++ ([EMAIL PROTECTED])
Re: Proposal For New Windowing software (Matthew Carl Schumaker)
Re: Why not C++ (Paul Jackson)
new user header file problems (Tom glass)
Re: Getting a Soundblaster Live Value to work (Marc Mutz)
Re: TAO: the ultimate OS (Richard Hickling)
Re: Why not C++ (Johan Kullstam)
T/TCP ("Curt")
Unbridled modem wackiness ([EMAIL PROTECTED])
Re: new user header file problems (Scott Lanning)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 29 Jun 1999 16:08:49 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Chris Double <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] (Bruce Hoult) writes:
>
>> > In practice, C++ is a much more complex language. As such, C++
>> > compilers are much more complex beasts. And that is why some C++
>> > compilers do not generate as good code as the equivalent C compilers do.
>>
>> I'd love to see examples.
>[...snip...]
>>
>> I'm afraid I basically don't use any other compilers. Which C++ compilers
>> are bad?
>
>In a recent Windows Developer Journal (June 1999) they printed an
>article on a Microsoft Visual C++ 6.0 bug. Some code in C++ mode
>caused incorrect assembler to be generated resulting in an infinite
>loop. The exact same code in C mode compiled and executed as expected.
This DOES NOT address Bruce's Q. Are you seriously going to
defend Linus's skewed response to Bruce by showing that MSVC++
actually has one sole isolated bug some mag reported on (ok that
in C mode the compiler did not happen to have too)?
OTOH, since we're just jesting: Do recall that MS products do not have bugs.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: GLIBC 2.1.1: still problems in dynamic loader (latest patches applied)
Date: 29 Jun 1999 21:59:50 +0200
>>>>> Roman Sulzhyk writes:
> Hello:
> I guess this is a to attention of Andreas Jaeger.
Ok, here I am;-).
> I have trouble isolating this into small enough case to submit a bug
> report. Basically, if you get the socks5 package from
> http://www.socks.nec.com/ and compile it as a shared preloadable
> library to use with 'runsocks' (which essentially transparently
> sockifies any app by wrapping network library calls) it does not
> work. If you set LD_PRELOAD=/usr/local/lib/libsocks5_sh.so all
> applications dump core. What I can deduce from setting LD_DEBUG=all
> is that at some point the application starts to reload all (some?)
> of dl_ symbols and dumps core soon afterwards. I'm attaching debug
> output generated by dynamic loader.
This might be ok. It has to resolve symbols for each library and for
the program - and therefore symbols are mapped a number of times. It
would be wrong if a symbol would be mapped two times for the same
library. For example _dl_init_next is first resolved in ld-2.1.1.so
and later in libc.so.6.
You should try to debug this with gdb instead.
> Notice that I've applied the two latest patches you've posted on
> GNATS over this weekend (June 27th?) which are supposedly from
> 2.1.2, and they didn't help - I was really hoping they would. I
> don't rule out that the problem is in the way socks tries to wrap
> libc, however the guys at NEC also seem to think it is the new
> glibc loader's problem.
Do you mean these patches? Those are all I have.
1999-06-25 Andreas Schwab <[EMAIL PROTECTED]>
* elf/dl-deps.c (_dl_map_object_deps): When looking for the next
occurence of the aux object start with the current list entry, not
the new one. Adjust tail pointer in the unique list. Explain how
the meaning of the variables changes [PR libc/1168].
1999-06-17 Andreas Jaeger <[EMAIL PROTECTED]>
* elf/dl-load.c (_dl_init_paths): Add one more element to aelem
to not write beyond allocated memory.
Reported by John Reiser <[EMAIL PROTECTED]>, closes PR libc/1167.
> So I guess I would like to bring this to your attention and see if
> you think this is a glibc problem.
I don't know - and I don't have time to check this out myself, my
thesis is waiting to get finished:-(.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: "Mark" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: Getting a Soundblaster Live Value to work
Date: Tue, 29 Jun 1999 15:51:33 GMT
NJR,
The car can be installed to work on just about any 2.2.5* kernel. I am using
redhat kernel 2.2.5-22 and it is fine... To install, you must do a manual
install as described by Creative in the driver readme, and them add the line
insmod -f sblive.o
to your rc.local file
This is because when you install the driver in any kernel other than 2.2.5
it will refuse to load from the modules.conf file due to the kernel
conflict. This extra line in rc.local will make the card work despite a
failed module load message preceding it.
Note that the driver only provides sound, not midi.
Mark
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Has anyone managed to do this at all? I've tried every logical compilation
> option I can think of with my 2.2.7 kernel but I just can't get the damn
thing
> to make a peep. All I ever get is a "No such device" error when trying to
> access /dev/audio or /dev/dsp. I've had no luck with modules either.
>
> Can anyone help?
>
> NJR
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Tue, 29 Jun 1999 19:38:07 GMT
In article <7l8oqv$s61$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
[&<]
>
> Are you _really_ concluding this from the examples above?
> The C++ vector will go away. It will no in the C case
> (it sounds like you may be saying the opposite above, it's not clear).
>
> >after using lisp's macros i don't know whether to laugh or cry when i
> >think of C++ templates.
>
> Ok, tell us why.
>
> BTW, you guys are side-stepping the issue of C and C++ by bring in new
> aspects (C++ vs Lisp for instance) and then slashing only C++ (and not
C)
> for it (assuming those aspects were even true of C and C++). This is
> misleading and biased. Oddly though, it does show that folks don't
want
> the comparison between C and Language-X.
>
> - Greg
> --
Yeah, I like that -- don't use C++ because templates aren't as 'good' as
Lisp style macros so use C instead.
Jack
> Comeau Computing, 91-34 120th Street, Richmond Hill, NY,
11418-3214
> Producers of Comeau C/C++ 4.2.38 -- New Release! We now do
Windows too.
> Email: [EMAIL PROTECTED] / Voice:718-945-0009 /
Fax:718-441-2310
> *** WEB: http://www.comeaucomputing.com ***
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Proposal For New Windowing software
Date: Tue, 29 Jun 1999 12:45:42 -0400
> >
> > Have you looked at Berlin? It is seeking to build a GUI system using
> > CORBA, GGI, and OpenGL/Mesa.
> >
> > It *looks* like they're primarily working on the 2D aspects of it;
> > presumably they figure it makes sense to have that somewhat working
> > first.
> I've looked at Berlin but they seem to be taking the stance of all other
> 2D GUIs with 3D support, you run the 3D in a Window. What I want to do
> Is run the 3D as the main interface and run 2D Windows inside of that.
> hence the need for support for 3D devices.
>There is nothing to limit it like that as far as I can see.
>
>Initially, the "window" management (it doesn't work on the principal of
>windows though) will be 2D (ie, you can have 3D in a 2D window), but
>that's only because the window manager is like that - a different window
>manager (what's the correct term here?) will let you do more using OpenGL
>features as Berlin advances.
>
>That provides for 2D projections of apps onto any surface, but full 3D UI
>support can easily be added, so your app can ask for a new 3D object in
>the UI space. All it needs is additional specifications for those
>features.
The problem with the idea of letting a Window Manager take care of it is
that if an application is written to take advantage my 3D support it only
works with my Window manager, not to mention since everything would be
treated as a 3D object I would be adding another layer of code to an
already cpu intensive task. I'm not that familiar with openGL but I'm not
quite sure of its interactive aspects either.
But another detractor of Berlin for me is the Hardware support. If I have
a spaceball I write my linux driver for it, then my Windows manager has to
deal with the input (which should technically be taken care of by the
windows system). Not to mention if I put 2 video cards in my computer I'm
willing to bet that Berlin will create a multi-headed display rather than
render the same scene from two slighty different view points(left/right
eye).
One may be able to get around these problems and still use berlin but I
bet the Windows manager will be about the same size as Berlin.
Thats why i feel that a windows system has to be designed from the
groundup with 3D in mind rather that just adding support for it
Matthew Carl Schumaker
[EMAIL PROTECTED]
veni, vedi, velcro
I came, I saw, I stuck around
------------------------------
From: [EMAIL PROTECTED] (Paul Jackson)
Crossposted-To: comp.os.linux.development.apps,comp.lang.c++
Subject: Re: Why not C++
Date: 29 Jun 1999 20:52:53 GMT
I (pj) wrote:
|> Put it this way -- if I could actually try ten different
|> teams [on a] a real world app, right now I'd bet ...
|> Python ... fastest, ... C++... slower apps,
Greg replied:
|> You are really going out on a limb here. "Programming"
|> is about concepts, techniques, understanding problems,
|> etc.
well yeah, a bit of a limb, for 'dramatic affect'.
Just as with natural languages, the programming language
we choose to express a program in will affect the way we
choose to organize the solution and algorithms we use,
or even to think about the possibilities.
|> ... you seem to be saying that changing the language is
|> going to make a genius out of an idiot, and that's nuts.
No the language doesn't make geniuses out of idiots, just
makes them a little less idiotic.
Please don't suggest rebutting a claim that "A < B" by noting
that this would be nuts, because "B != Infinity" ... the old
'reductio ad absurdum' fallacy.
|> Ok, maybe I'm missing your point. Why would Python
|> make the architecture and algorithms right'er?
But yes, I think Python would _tend_, for a broad class of apps,
to make the architecture and algorithms right'er (which isn't to
say they'd be even tolerably close to right) for such reasons as:
it encourages leaving many of the details to the language
builtin support for basic container classes, and focusing
more on slightly higher level matters,
the stress in the basic language design on simplicity,
ease of understanding and conceptual integrity leaves the
programmer a few more spare neurons to think about the
important stuff, and
the clean, well-documented, easily integrated libraries
provide a rich store of prebuilt solutions, second perhaps
only to Perl CPAN (if not superior ...)
Which isn't to say that for certain tasks, I wouldn't
dramatically prefer C++ (or C or Perl or sh/awk/... or
Fortran or ...).
In response to my 747 == C++ analogy, Greg wrote:
|> Ok, so I should infer from this that Boeing 747 pilots should
|> use every cockpit "button" on every flight just because the
|> buttons are there?
No, heaven forbid. But the additional instruments do
confuse the learner, which is what most of us are for
the first couple years of C++ programming (if not longer).
--
We each only have a few clear thoughts to spend each day.
Let us spend them wisely.
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson ([EMAIL PROTECTED]; [EMAIL PROTECTED]) 3x1373 http://sam.engr.sgi.com/pj
------------------------------
From: Tom glass <[EMAIL PROTECTED]>
Subject: new user header file problems
Date: Tue, 29 Jun 1999 15:05:12 -0600
I'm a new convert to Linux. I'm trying to create a CSerial class
(similar to one I used in windows) and am having a problem I don't
understand. My header file is called serial.h and contains:
// Serial.h
#define BAUDRATE B9600
#define SERIALDEVICE "/dev/ttyS1"
#define _POSIX_SOURCE 1 /* POSIX compliant source */
#define FALSE 0
#define TRUE 1
class CSerial
{
public:
CSerial();
~CSerial();
BOOL Open( int nPort = 1, int nBaud = 9600 );
BOOL Close( void );
int ReadData( void *, int );
int SendData( const char *, int );
// int ReadDataWaiting( void );
BOOL IsOpened( void ){ return( m_bOpened ); }
protected:
// BOOL WriteCommByte( unsigned char );
// HANDLE m_hIDComDev;
// OVERLAPPED m_OverlappedRead, m_OverlappedWrite;
BOOL m_bOpened;
struct termios oldtio,newtio;
// termios structures to hold old and new i/o settings
int fd;
// this int identifies the port
};
The first few lines of my implementation file (serial.C) are:
// Serial.cpp
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <termios.h>
#include <stdio.h>
#include "serial.h"
CSerial::CSerial()
{
m_bOpened = FALSE;
}
and I get the following errors when trying to compile using Code
Crusader:
Tue Jun 29 14:52:47 1999
/home/tomg/ctemps/portopen/
make -k
g++ -g -Wall -Werror -I- -I../libserial-0.1 -c ../serial.C -o
../serial.o
../serial.C:11: syntax error before `::'
cc1plus: warnings being treated as errors
../serial.C:15: warning: ANSI C++ forbids declaration `m_bOpened' with
no type `FALSE' was not declared in this scope
>From the errors it seems like the compiler doesn't know about my header
file, but it doesn't report any error regarding not finding it. I hope
this is the right group to post this too, and thanks for any help you
can give me.
Tom
------------------------------
Date: Tue, 29 Jun 1999 19:12:51 +0200
From: Marc Mutz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: Getting a Soundblaster Live Value to work
http://developer.soundblaster.com/
Marc
------------------------------
From: Richard Hickling <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Tue, 29 Jun 1999 19:15:51 +0200
> what I am saying is that the software industry has to find
> a "standard object" or "standard black box" that truly is
> used as such at all levels in the design, not just at one
> level or another. it has discovered object but is not yet
> at the point of unification, at which point the entire
> OS will be object oriented.
In order to develop such an OS good theory is needed. I'm talking of theory like
that of relational databases - which is perfect in the mathematical sense. In
contrast, all the 'patterns' stuff and UML and so on (while not too bad) is driven
by rules of thumb.
If you want a black box, you have to make sure that what's inside it is guaranteed
to work.
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 29 Jun 1999 17:36:19 -0400
[EMAIL PROTECTED] writes:
> In article <7l8oqv$s61$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> [&<]
> >
> > Are you _really_ concluding this from the examples above?
> > The C++ vector will go away. It will no in the C case
> > (it sounds like you may be saying the opposite above, it's not clear).
> >
> > >after using lisp's macros i don't know whether to laugh or cry when i
> > >think of C++ templates.
> >
> > Ok, tell us why.
> >
> > BTW, you guys are side-stepping the issue of C and C++ by bring in new
> > aspects (C++ vs Lisp for instance) and then slashing only C++ (and not
> C)
> > for it (assuming those aspects were even true of C and C++). This is
> > misleading and biased. Oddly though, it does show that folks don't
> want
> > the comparison between C and Language-X.
> >
> > - Greg
> > --
>
> Yeah, I like that -- don't use C++ because templates aren't as 'good' as
> Lisp style macros so use C instead.
the point being
1) if you don't need templates, go ahead and use C.
2) if you *do* need templates, get a better language than C++.
actually i don't mind the templates in C++. they are rather weak, but
not hard to use and are not terribly confusing
what i do mind is the object orientation parts -- especially the
inheritance and virtual function stuff. i find the way C++ to be
overly complex and wordy. when i need a higher level language, i
reach for a higher level language which for me is less painful and
that'd be lisp.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
Reply-To: "Curt" <[EMAIL PROTECTED]>
From: "Curt" <[EMAIL PROTECTED]>
Subject: T/TCP
Date: Tue, 29 Jun 1999 16:37:58 -0500
T/TCP does not appear to be supported by Linux 2.0.36
Is it supported under 2.2.x?
Or is T/TCP a dead issue? There seemed to be some talk about it about
1.5-2 years ago, but not much lately.
------------------------------
From: [EMAIL PROTECTED]
Subject: Unbridled modem wackiness
Date: Tue, 29 Jun 1999 21:44:42 GMT
So, I've got a program that talks to the modem. It has two threads.
One thread talks to the port and does useful and (I fear) not-so-useful
stuff. For those unpredictable times when it does not-so-useful stuff,
I have an error recovery thread that (in part) will reset the first
thread if things go wrong.
My problem is that not both threads are able to accurately monitor the
DCD signal. They both accurately read that it is down before a
connection, and they both correctly realize that a connection is up
afterwards. But if the remote modem hangs up unexpectedly, only my
first thread realizes it. The second (error-handling) thread still
reads it the DCD as up until we toggle DTR on the local side (using
cfset{i|o}speed, setting the baud to zero).
I'm using ioctl calls to read the DCD (TIOCMGET, and then reading
TIOCM_CAR from the third arg).
Is this some serial setting, or am I just screwed on multi-threaded
reads to the DCD? And is there a clearly-written reference for serial
port ioctl calls?
Thanks,
AED
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: new user header file problems
Date: 29 Jun 1999 22:36:29 GMT
Tom glass ([EMAIL PROTECTED]) wrote:
: and I get the following errors when trying to compile using Code
: Crusader:
:
: Tue Jun 29 14:52:47 1999
: /home/tomg/ctemps/portopen/
: make -k
:
: g++ -g -Wall -Werror -I- -I../libserial-0.1 -c ../serial.C -o
: ../serial.o
:
: ../serial.C:11: syntax error before `::'
[snip]
:
: From the errors it seems like the compiler doesn't know about my
: header file, but it doesn't report any error regarding not finding
Hence, another file is being read instead. In particular, there
exists a file /usr/include/linux/serial.h, which lives in the
standard include path. We conclude, therefore, that the standard
include path is being searched before yours. Considering this, I
look at
info gcc "Invoking GCC" "Directory Options"
and I find
================================================================
`-I-'
Any directories you specify with `-I' options before the
`-I-' option are searched only for the case of `#include
"FILE"'; they are not searched for `#include <FILE>'.
If additional directories are specified with `-I' options
after the `-I-', these directories are searched for all
`#include' directives. (Ordinarily *all* `-I' directories
are used this way.)
In addition, the `-I-' option inhibits the use of the
current directory (where the current input file came from)
as the first search directory for `#include "FILE"'. There
is no way to override this effect of `-I-'. With `-I.' you
can specify searching the directory which was current when
the compiler was invoked. That is not exactly the same as
what the preprocessor does by default, but it is often
satisfactory.
`-I-' does not inhibit the use of the standard system
directories for header files. Thus, `-I-' and `-nostdinc'
are independent.
================================================================
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"If lightning is the anger of the gods, the gods are concerned mostly
with trees." --Lao Tse
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
