632 lines
24 KiB
Plaintext
632 lines
24 KiB
Plaintext
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Development@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Development@senator-bedfellow.mit.edu
|
|
Date: Thu, 13 Oct 94 14:13:12 EDT
|
|
Subject: Linux-Development Digest #302
|
|
|
|
Linux-Development Digest #302, Volume #2 Thu, 13 Oct 94 14:13:12 EDT
|
|
|
|
Contents:
|
|
Re: Term blocks modem, switching to VT and back restores? (Bill C. Riemers)
|
|
Re: Linux SLIP interactive response (Modus Operandi)
|
|
Re: A badly missed feature in gcc (Anselm Lingnau)
|
|
Re: 8-bit colour ANSI and ncurses (Andries Brouwer)
|
|
Re: A badly missed feature in gcc (Ian McCloghrie)
|
|
Re: 3c505 driver ? (Tall Sword)
|
|
WARNING Re: code coverage tool for c (Ralf W. Stephan)
|
|
Linux on a IBM PS/2 (Carlos Irigaray)
|
|
Re: Improving SLIP latency under Linux (Michael Callahan)
|
|
Re: Improving SLIP latency under Linux (Michael Callahan)
|
|
Re: Improving SLIP latency under Linux (Michael Callahan)
|
|
Re: What is the Status of the Adaptec 2940W SCSI-3 support? (Phil Andrew)
|
|
question about the kernel (Dongxiao Yue)
|
|
Re: 8-bit colour ANSI and ncurses (Andries Brouwer)
|
|
Re: LINUX Logical volumes (H. Peter Anvin)
|
|
Re: A badly missed feature in gcc (Tom Wilson)
|
|
Re: A badly missed feature in gcc (Alan Braggins)
|
|
Re: Practical experience with Gravis Ultrasound Max? (Shannon Hendrix)
|
|
Re: 3Com 509 Driver Problems - Any fixes - Help (Stanley Owen Jester)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: bcr@k9.via.term.none (Bill C. Riemers)
|
|
Crossposted-To: comp.windows.x.i386unix
|
|
Subject: Re: Term blocks modem, switching to VT and back restores?
|
|
Date: 11 Oct 1994 16:27:00 GMT
|
|
Reply-To: bcr@physics.purdue.edu
|
|
|
|
>>>>> "Rafal" == Rafal Kustra <rafal@cs.toronto.edu> writes:
|
|
|
|
Rafal> OOps forgot to mention. Using term2.0.1 on both ends.
|
|
Rafal> Rafal
|
|
|
|
I'm fairly certain this isn't a problem related to term versions. It
|
|
sounds like you have a hardware problem that only manifests itself
|
|
when both the modem and the video card are in high gear at the same
|
|
time. You mentioned your attempts to change the jumpers on your
|
|
video card. Have you attempt to change the jumpers on your serial
|
|
port, or switching which com port you connect your modem to?
|
|
|
|
Bill
|
|
--
|
|
<A HREF=" http://physics.purdue.edu/~bcr/homepage.html ">
|
|
<EM><ADDRESS> Bill C. Riemers, bcr@physics.purdue.edu </ADDRESS></EM></A>
|
|
<A HREF=" http://www.physics.purdue.edu/ ">
|
|
<EM> Department of Physics, Purdue University </EM></A>
|
|
|
|
------------------------------
|
|
|
|
From: modus@seldon.asimov.net (Modus Operandi)
|
|
Subject: Re: Linux SLIP interactive response
|
|
Date: 12 Oct 1994 15:19:54 -0400
|
|
|
|
John Richardson (jrichard@remus.uml.edu) wrote:
|
|
: I finally got Trumpet winsock and installed it with the same SLIP
|
|
: parameters that linux uses. The result: interactive winsock
|
|
: performance during ftp sessions is just as bad as linux!
|
|
: In addition, under the same parameters, linux (stock slackware 2.0.0)
|
|
: ftp outperformed windows ws_ftp by about 100 to 200 bytes/sec.
|
|
: Of course, this could be due to line noise etc...
|
|
|
|
: this means two things:
|
|
|
|
: o we aren't any worse than MS-Windows
|
|
: o we may be better than MS-Windows :)
|
|
|
|
There is currently a patch available on ftp.linux.org.uk (actually, a
|
|
replacement dev.c) that should solve some of the current ftp session
|
|
problems.
|
|
|
|
Please download it and try it out if you would like to see an improvement to
|
|
interactive performance. (NOTE: THIS IS ALPHA CODE).
|
|
|
|
Patrick Kane
|
|
<modus@asimov.net>
|
|
|
|
------------------------------
|
|
|
|
From: Anselm Lingnau <lingnau@tm.informatik.uni-frankfurt.de>
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: 12 Oct 1994 20:08:36 +0100
|
|
|
|
In article <6453@sparky.mdavcr.mda.ca>, Bruce Thompson
|
|
<bruce@mdavcr.mda.ca> wrote:
|
|
|
|
> I know of no other language than C++ which has multiple comment syntaxes.
|
|
|
|
Pascal. Fortran.
|
|
|
|
Anselm
|
|
--
|
|
Anselm Lingnau ......................... lingnau@tm.informatik.uni-frankfurt.de
|
|
If man could be crossed with the cat, it would improve man but deteriorate the
|
|
cat. --- Mark Twain
|
|
|
|
------------------------------
|
|
|
|
From: aeb@cwi.nl (Andries Brouwer)
|
|
Subject: Re: 8-bit colour ANSI and ncurses
|
|
Date: Thu, 13 Oct 1994 12:00:29 GMT
|
|
|
|
hpa@ahab.eecs.nwu.edu (H. Peter Anvin) writes:
|
|
|
|
: Followup to: <aeb.781998424@news.cwi.nl>
|
|
::
|
|
:: Do you have suggestions for improvement?
|
|
:: In a sense I feel that we are bound somewhat by the desire to
|
|
:: emulate a VT100, i.e., font changes really are Esc ( * and Esc ) *.
|
|
:: A good thing would be to throw out mapscrn and to encode the mapping
|
|
:: information in the font, especially now that we have Unicode.
|
|
:: But that would make it less trivial to borrow fonts from other sources.
|
|
::
|
|
|
|
: Yes; I posted a bit about this to the KERNEL channel recently.
|
|
: Basically my idea is to split the kernel tables into two set of
|
|
: tables: terminal charsets -> Unicode and Unicode -> font. The latter
|
|
: table would be loadable with a font. This way, a loadable font could
|
|
: contain any arbitrary subset of Unicode, and the VT220 emulation modes
|
|
: would still work as intended (ISO 8859-x -- there are 10 of them,
|
|
: KOI-8, DEC VT graphics, and IBM codepages would all be in
|
|
: font-indenpendent tables mapping them to Unicode, after which Unicode
|
|
: would be mapped to the font. The Unicode -> font table would be
|
|
: page-mapped since it would in general only by a sparse table.
|
|
|
|
And the terminal charsets -> Unicode would still be indicated by
|
|
Esc ( X. Yes, sounds like that would work. I hope to make that
|
|
change tonight.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: ianm@qualcomm.com (Ian McCloghrie)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: 12 Oct 1994 12:56:57 -0700
|
|
|
|
jeffpk@netcom.com (Jeff Kesselman) writes:
|
|
|
|
>Very true, he said, quickly jotting notes for the next inevitble
|
|
>super-set argument.
|
|
|
|
Even more fun is the difference between NULL. Used to be, in K&R,
|
|
that NULL was defined as "0". In ANSI, it's defined as "(void *) 0".
|
|
In C++, it's back to being "0", because "(void *) 0" can't be
|
|
automatically converted to another type in an assignment,
|
|
and thus "int *foo = NULL;" won't work with ANSI NULL, you need
|
|
"int *foo = (int *) NULL;". Which, I think you'll agree, is ugly :)
|
|
|
|
--
|
|
Ian McCloghrie work: ianm@qualcomm.com home: ian@egbt.org
|
|
____ GCS d-- H s+:+ !g p? au a- w+ v- C++$ UL++++ US++$ P+>++
|
|
\bi/ L+++ 3 E+ N++ K--- W--- M-- V-- -po+ Y+ t+ 5+++ jx R G'''
|
|
\/ tv- b+++ D- B-- e- u* h- f+ r n- y*
|
|
|
|
The above represents my personal opinions and not necessarily those
|
|
of my employer, Qualcomm Inc.
|
|
|
|
------------------------------
|
|
|
|
From: cs_kokim@dmf123.ust.hk (Tall Sword)
|
|
Subject: Re: 3c505 driver ?
|
|
Date: Thu, 13 Oct 1994 11:04:04 GMT
|
|
|
|
Zheng Huang (huang@eagle.sangamon.edu) wrote:
|
|
: Hi,
|
|
|
|
: I tried to config my linux(slakware 2.0) to work with my 3c505 network card,
|
|
: but I can't find the 3c505.c file in linux src directory under drivers.
|
|
: For some reason, the 3c505 is been commented out from the config file. Could
|
|
: someone tell me how I can make 3c505 work with linux.
|
|
Try get the update kernel and compile again. For me, I am running 1.1.53 and
|
|
the 3c503 works fine on my system.
|
|
|
|
--
|
|
* Origin: TallSword, Computer Science Year 2, HKUST
|
|
internet: cs_kokim@dmf123.ust.hk, cs_kokim@stu.ust.hk
|
|
root@dmf123.ust.hk, raymond@dmf123.ust.hk
|
|
Raymond.Ko@f15.n700.z6.ftn.air.org
|
|
fidonet: Raymond Ko, 6:700/15@fidonet.org
|
|
|
|
|
|
------------------------------
|
|
|
|
From: ralf@ark.franken.de (Ralf W. Stephan)
|
|
Subject: WARNING Re: code coverage tool for c
|
|
Date: Sun, 9 Oct 1994 14:26:29 GMT
|
|
|
|
Bob Horgan writes:
|
|
> The code coverage tool, ATAC, is available via ftp from Bellcore.
|
|
|
|
Warning. This package, when installed, creates a script that
|
|
sends mail about installation and usage (this every 30 days)
|
|
on your system to bellcore.com. It doesn't tell you.
|
|
|
|
If you don't want this, remove the file 'loguse' after
|
|
installation or don't install atac at all.
|
|
|
|
ralf
|
|
--
|
|
## CrashJoint v9.99 ##
|
|
You are in a different little article, all maze.
|
|
|
|
------------------------------
|
|
|
|
From: cirigara@nova.umd.edu (Carlos Irigaray)
|
|
Subject: Linux on a IBM PS/2
|
|
Date: 9 Oct 1994 20:14:58 -0400
|
|
|
|
Hi, does anyone know how to create a "boot disk" and a "root disk" as in
|
|
the Slackware distribution?
|
|
I'm using Slackware 2.0.1 and my runnning kernel is 1.1.52 (I've compiled
|
|
it). What I need is to make those diskettes from my system because then I
|
|
should be able to have my IBM PS/2 booting. (the new kernel support the
|
|
MCA architecture!)
|
|
|
|
Thanks for the help!
|
|
|
|
____________________________________________________________
|
|
| |
|
|
| Carlos Irigaray - cirigara@nova.umd.edu - carlosi@iadb.org |
|
|
| |
|
|
|____________________________________________________________|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: callahan@maths.ox.ac.uk (Michael Callahan)
|
|
Subject: Re: Improving SLIP latency under Linux
|
|
Date: Thu, 13 Oct 94 13:37:28 BST
|
|
|
|
In article <longyearCxC2wx.I3A@netcom.com>,
|
|
Al Longyear <longyear@netcom.com> wrote:
|
|
>eric@pandora.Las-Vegas.NV.US (Eric J. Schwertfeger) replies to someone:
|
|
>>: Actually, I guess there is one thing you could do. You could set
|
|
>>: things up so that if an interactive packet gets queued while a bulk
|
|
>>: packet is in the middle of transmission, you immediately interrupt
|
|
>>: the bulk packet (by sending an end-of-frame character and relying
|
|
>>: on the remote end to discard the incomplete frame) and start the
|
|
>>: interactive one instead. Ugly, and I don't recommend it for SLIP
|
|
>>: (which has no link error detection). It would improve latency
|
|
>>: somewhat.
|
|
|
|
Actually, I wrote that.
|
|
|
|
Michael
|
|
---
|
|
Michael Callahan
|
|
callahan@maths.ox.ac.uk
|
|
|
|
|
|
------------------------------
|
|
|
|
From: callahan@maths.ox.ac.uk (Michael Callahan)
|
|
Subject: Re: Improving SLIP latency under Linux
|
|
Date: Thu, 13 Oct 94 13:46:27 BST
|
|
|
|
In article <CxG8nt.HzE@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
|
|
>According to Al Longyear:
|
|
>> For this to work the best, you need to implement IP_TOS on both sides
|
|
>> of the link. If you are doing an ftp transfer to read a large file,
|
|
>> then it the remote side (the one running ftpd) which is doing the
|
|
>> majority of the transmission. Their frames need to have a background
|
|
>> (7) priority.
|
|
>
|
|
>Note in my application Linux on one side is used only as a router.
|
|
>I cannot change the ftpd. So, if it does not use another than the default
|
|
>TOS, I will not have this advantage when using TOS based queueing.
|
|
|
|
OK, if you really can't get the remote end to do TOS correctly,
|
|
and you want to do the TCP-port-number hack, put an appropriate
|
|
hook in the ip_forward routine in net/inet/ip.c just before it
|
|
examines the TOS field to decide what queue to use.
|
|
|
|
Michael
|
|
---
|
|
Michael Callahan
|
|
callahan@maths.ox.ac.uk
|
|
|
|
------------------------------
|
|
|
|
From: callahan@maths.ox.ac.uk (Michael Callahan)
|
|
Subject: Re: Improving SLIP latency under Linux
|
|
Date: Thu, 13 Oct 94 13:53:01 BST
|
|
|
|
In article <377ijq$96@ulowell.uml.edu>,
|
|
John Richardson <jrichard@cs.uml.edu> wrote:
|
|
>In article <374crv$6mp@gate.noris.de>,
|
|
>Matthias Urlichs <urlichs@smurf.noris.de> wrote:
|
|
>>The reasonable thing to do here is to increase the baud rate you use when
|
|
>>talking to the modem. Remember that with error-corecting modems, every data
|
|
>>packet (which has no relation to the IP packets it carries) has to arrive
|
|
>>completely before being forwarded because the checksum must be verified,
|
|
>>and on a serial line there's no "Oops, discard the last fifteen characters"
|
|
>>command.
|
|
>
|
|
>Increase the baud rate? Huh? How? It is already at spd_hi. With
|
|
>round trip times of 2000 to 3000ms I don't think I'm just waiting for
|
|
>30 characters... I don't know if you realize this, this thread
|
|
>was started by someone complaining about the abnormal interactive
|
|
>responce times /during background ftp transfers/. If you use
|
|
>SLIP or PPP can you say that you don't get 2-3 sec delays (you
|
|
>can modify ping to get this) for interactive traffic.
|
|
|
|
Actually, what you would really like is to have a SLOW baud rate
|
|
for transmitting to the modem, and a FAST baud rate for receiving
|
|
from it. The problem with having a FAST baud rate for transmitting
|
|
to the modem is that the Linux host can fill up the modem's
|
|
transmit buffer rapidly, at which point the modem has a couple
|
|
seconds of data to send, so _no matter what the Linux host does_,
|
|
a new interactive packet will have to wait a couple of seconds
|
|
for delivery.
|
|
|
|
If instead you transmit to the modem more slowly, you'll never fill
|
|
up the transmit buffer (much).
|
|
|
|
On the other hand, you lose bandwidth, obviously.
|
|
|
|
I wouldn't be surprised if a 9600 baud connection to a 14.4
|
|
modem session gave the best latency results for interactive
|
|
traffic with simultaneous bulk traffic. On the other hand,
|
|
it's slow.
|
|
|
|
Michael
|
|
---
|
|
Michael Callahan
|
|
callahan@maths.ox.ac.uk
|
|
|
|
|
|
------------------------------
|
|
|
|
From: esveg@csv.warwick.ac.uk (Phil Andrew)
|
|
Crossposted-To: comp.os.linux.help
|
|
Subject: Re: What is the Status of the Adaptec 2940W SCSI-3 support?
|
|
Date: 13 Oct 1994 14:34:41 +0100
|
|
|
|
In article <CxIuCB.Izn@ix.de>,
|
|
hm@ix.de writes:
|
|
>In comp.os.linux.development, Wigs (wiegley@phakt.usc.edu) wrote:
|
|
>
|
|
>> Could the people in the know please forward any information they have on
|
|
>> this.
|
|
>
|
|
>-> Projects-Map on sunsite.
|
|
>
|
|
|
|
Well, since Adaptec will not even release details of the lowly 2940, I do
|
|
not think they will be too pleased about doing so for the 2940w.
|
|
|
|
I really do not think that there is a lot of demand for support at the
|
|
moment.
|
|
|
|
However, if I am wrong on this, and anyone has written a driver for either
|
|
card, I would be most grateful to know about it,
|
|
|
|
Phil Andrew
|
|
|
|
>--
|
|
>Zounds! I was never so bethumped with words
|
|
>since I first called my brother's father dad.
|
|
> -- William Shakespeare, "King John"
|
|
>--
|
|
>Harald Milz (hm@ix.de) WWW: http://www.ix.de/editors/hm.html
|
|
>iX Multiuser Multitasking Magazine phone +49 (511) 53 52-377
|
|
>Helstorfer Str. 7, D-30625 Hannover fax +49 (511) 53 52-378
|
|
>Opinions stated herein are my own, not necessarily my employer's.
|
|
|
|
+--------------+-------------+----------------------+----------------------+
|
|
|Philip Andrew | Warwick Uni.| Dept. of Engineering | esveg@warwick.ac.uk |
|
|
+--------------+-------+-----+----------------------+----------------------+
|
|
| http://www.csv.warwick.ac.uk/~esveg/ |
|
|
+--------------------------------------------------------------------------+
|
|
| ********* P | W W W AAA RRRR W W W III CCCC K K |
|
|
| * * R | W W W A A R R W W W I C K K |
|
|
| * * I | W W W AAAAA RRRR W W W I C KKK |
|
|
| * * D | W W W A A R R W W W I C K K |
|
|
| * E | WWW A A R R WWW III CCCC K K |
|
|
+----------------------+---------------------------------------------------+
|
|
| First respect yourself. Respect for others will then follow. |
|
|
+--------------------------------------------------------------------------+
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.unix.internals,comp.os.linux.help
|
|
From: dyue@mega.cs.umn.edu (Dongxiao Yue)
|
|
Subject: question about the kernel
|
|
Date: Thu, 13 Oct 1994 14:35:14 GMT
|
|
|
|
Hello, folks,
|
|
|
|
I am reading the Linux kernel source code, and have some difficulty
|
|
understanding one crucial point. Usually before the a process try
|
|
to manipulate some global data structures ( like the free buffer list),
|
|
it will disallow interrupts in some critical section. But as I read the
|
|
source for linux, I can not find where this is done, for example
|
|
in file buffer.c there is a inline function put_last_free() which
|
|
alters a linked list, but there is no code to protect the critical
|
|
section there. getblk() calls put_last_free(), but I can not found the
|
|
protection code in it either.
|
|
|
|
Can someone tell me how and where the critical sections are protected?
|
|
I have spent quite some time to trace back and forth the calling
|
|
sequences and found nothing(btw, is there a program that can serach the
|
|
calling sequence?). I would greatly appreciate your help.
|
|
|
|
|
|
Dongxiao
|
|
|
|
|
|
------------------------------
|
|
|
|
From: aeb@cwi.nl (Andries Brouwer)
|
|
Subject: Re: 8-bit colour ANSI and ncurses
|
|
Date: Thu, 13 Oct 1994 13:51:45 GMT
|
|
|
|
rasmus@io.org (Rasmus Lerdorf) writes:
|
|
|
|
: I looked through the console driver source and noticed that
|
|
: <ESC>]11m does what I want. ie. show the chars for ascii codes
|
|
: < 32 and also switches to the first alternate character set.
|
|
: From within ncurses it appears as though attrset(A_ALTCHARSET)
|
|
: does the trick. <ESC> ] 11m along with 10, 12, 21,22,24 and 27
|
|
: are mode codes I haven't seen before. They are not in the
|
|
: ANSI spec, and they don't look like VT100 sequences to me.
|
|
|
|
No, slowly there are coming more and more non-VT100 features
|
|
in the console driver. I don't know who wrote that code.
|
|
ISO 6429 (ECMA 48) says about <ESC> ] N m:
|
|
N=10: primary font
|
|
N=11: first alternative font
|
|
N=12: second alternative font
|
|
N=21: doubly underlined (but here the Linux source identifies
|
|
N=21 with N=22, must be a bug)
|
|
N=22: normal colour/intensity
|
|
N=24: not underlined
|
|
N=25: not blinking
|
|
N=27: positive image
|
|
N=38: reserved for setting character foreground color
|
|
N=39: default display color (the change in underline here seems a bug)
|
|
N=49: default background color
|
|
|
|
That N=10,11,12 do sth with disp_ctrl and toggle_meta seems
|
|
unjustified by any standard I know of. Anybody care to comment?
|
|
|
|
|
|
------------------------------
|
|
|
|
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
|
|
Subject: Re: LINUX Logical volumes
|
|
Reply-To: hpa@nwu.edu (H. Peter Anvin)
|
|
Date: Thu, 13 Oct 1994 14:41:03 GMT
|
|
|
|
Followup to: <37j3pv$6og@elna.ethz.ch>
|
|
By author: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
|
|
In newsgroup: comp.os.linux.development
|
|
>
|
|
> Also, 3) requires some good understanding of failure patterns. Since
|
|
> nowadays, the electronic parts of a disk drive tend to be more likely
|
|
> to fail that the mechanic parts, you also have to be concerned about
|
|
> disk controller or (very common !) bus problems. Of course, an easy
|
|
> but probably adequate solution to the latter would be to declare them
|
|
> as something that's beyond the scope of such a concept. Let's also
|
|
> not talk about drive firmware bugs (and yes, you see more of those in
|
|
> large, less common setups).
|
|
>
|
|
|
|
... which they pretty much are, since they don't cause data loss per
|
|
se, just temporary inaccessibility. Personally, I feel that if you
|
|
want RAID, get a hardware implementation of RAID, since those tend to
|
|
be incredible much better (they can do spindle synchronization etc)
|
|
anyway.
|
|
|
|
/hpa
|
|
--
|
|
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
|
|
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
|
|
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
|
|
ld error: wallet.c: _money not found
|
|
|
|
------------------------------
|
|
|
|
From: ctwilson@mercury.interpath.net (Tom Wilson)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: 12 Oct 1994 23:13:00 -0400
|
|
|
|
In article <6453@sparky.mdavcr.mda.ca>,
|
|
Bruce Thompson <bruce@mdavcr.mda.ca> wrote:
|
|
:H. Peter Anvin (hpa@ahab.eecs.nwu.edu) wrote:
|
|
:: Followup to: <jeffpkCxJ93y.Ku1@netcom.com>
|
|
:: By author: jeffpk@netcom.com (Jeff Kesselman)
|
|
:: In newsgroup: comp.os.linux.development
|
|
:
|
|
[CHOMP}
|
|
:
|
|
:As a postscript, I find the notion of supporting multiple comment
|
|
:syntaxes as unusual in the extreme. I know of no other language than
|
|
:C++ which has multiple comment syntaxes. I have yet to encounter a
|
|
|
|
Well, (URP!) VMS Pascal supports both (* *) and { } .....for what
|
|
*that* piece of silly trivia is worth...
|
|
|
|
At any rate, breaking strict ANSI compliance to follow Mickeysoft
|
|
(I believe they did it first.. // , that is) just ain't worth it
|
|
IMNSHO...
|
|
|
|
--
|
|
/-----------------------------------------------------------------------\
|
|
| Tom Wilson | "I can't complain, but sometimes |
|
|
| ctwilson@rock.concert.net | I still do." |
|
|
| | -Joe Walsh |
|
|
|
|
------------------------------
|
|
|
|
From: armb@setanta.demon.co.uk (Alan Braggins)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: Tue, 11 Oct 1994 10:30:03 GMT
|
|
|
|
In article <jeffpkCxEDKF.LA9@netcom.com> jeffpk@netcom.com (Jeff Kesselman) writes:
|
|
>This would break perfectly correct C code, like
|
|
>
|
|
> a = b//* Comment here */ c;
|
|
>--
|
|
|
|
And this is the cannonical case of why c++ is NOT a true super-set of
|
|
ANSI c. (Thanks, I'm going to save the exampel for the next time I have
|
|
THAT argument.)
|
|
|
|
That "int function();" declares a function with no arguments in C++
|
|
and an unknown number of arguments in C is far more common.
|
|
So are variables called "class" or other new reserved words.
|
|
--
|
|
Alan Braggins armb@setanta.demon.co.uk abraggins@cix.compulink.co.uk
|
|
"Any technology distinguishable from magic is insufficiently advanced"
|
|
|
|
|
|
------------------------------
|
|
|
|
From: shendrix@escape.widomaker.com (Shannon Hendrix)
|
|
Subject: Re: Practical experience with Gravis Ultrasound Max?
|
|
Date: Tue, 11 Oct 1994 01:03:06 GMT
|
|
|
|
jon.lasser%goucher@wb3ffv.ampr.org (Jon Lasser) writes:
|
|
|
|
>Does anyone have practical experience with the Gravis Ultrasound Max
|
|
>under Linux?
|
|
|
|
>I have three primary questions:
|
|
>(1) Does the CD-ROM interface for the Panasonic drive work
|
|
>properly under Linux (I have a Panasonic 563b drive, which currently
|
|
>runs with my Sound Blaster 16).
|
|
|
|
>(2) Are there any general incompatibilities between the board
|
|
>and Linux? Any specific known problems?
|
|
|
|
>(3) I'm currently using a Sound Blaster 16. IsGravis
|
|
>Ultrasound Max considered an upgrade from the Sound Blaster? I mean, I
|
|
>know that the digital audio is about the same, but is the WaveTable that
|
|
^^^^^^^^^^^^^^^^^^^^^^^
|
|
Hardly. The SB has one or two channels. The Gravis has 32 digital
|
|
channels.
|
|
|
|
>much better?
|
|
|
|
Far better.
|
|
|
|
>Frankly, I'm lusting over the board, but I want to make sure that it
|
|
>works before I buy it, because I don't know enough to hack the kernel.
|
|
>(yet).
|
|
|
|
What I'm most interested in knowing is what happened to the Ultrasound
|
|
Max *UPGRADE* for the original Gravis Ultrasound. I am happy with the
|
|
Ultrasound (has everything the Max has except no 16-bit recording, CD-ROM
|
|
interfaces, and a couple of other things). All I see in the stores is
|
|
this $200 thing and that, IMHO, is a ripoff as an upgrade which barely
|
|
adds anything to my current board.
|
|
|
|
However, if there is an upgrade board that is much lower than $200
|
|
then OK.
|
|
|
|
>Replies by e-mail are appreciated, although I do try to keep up with
|
|
>this group.
|
|
|
|
>Thanks in advance,
|
|
>Jon Lasser
|
|
|
|
--
|
|
csh
|
|
===========================================================================
|
|
shendrix@escape.widomaker.com | Linux... that's it for the moment
|
|
===================================+
|
|
|
|
------------------------------
|
|
|
|
From: jester@cs.utexas.edu (Stanley Owen Jester)
|
|
Crossposted-To: comp.os.linux.help
|
|
Subject: Re: 3Com 509 Driver Problems - Any fixes - Help
|
|
Date: 13 Oct 1994 10:37:32 -0500
|
|
|
|
Will a 3c501 card work with Linux sllackware 2?
|
|
I know it is old, but it is for home, so I won't need much horsepower.
|
|
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
|
|
|
|
You can send mail to the entire list (and comp.os.linux.development) via:
|
|
|
|
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
|
|
|
|
Linux may be obtained via one of these FTP sites:
|
|
nic.funet.fi pub/OS/Linux
|
|
tsx-11.mit.edu pub/linux
|
|
sunsite.unc.edu pub/Linux
|
|
|
|
End of Linux-Development Digest
|
|
******************************
|