Linux-Development-Sys Digest #929, Volume #6 Sat, 3 Jul 99 14:13:50 EDT
Contents:
Re: Why not C++ (Nathan Myers)
Winmodem in Linux? Help! ("JN")
Re: Why not C++ (Timo Tossavainen)
idea: file events ("Dennis G. Allard")
Re: Winmodem in Linux? Help! (M. Buchenrieder)
Re: C++ templates: More than Turing Complete? (Nathan Myers)
Need Kernel ("WG")
Re: Why not C++ (Greg Comeau)
Save your printing money ([EMAIL PROTECTED])
Re: Why not C++ (Timo Tossavainen)
Change video mode ("Daniel WEISS")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 3 Jul 1999 00:46:06 -0700
Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>Nathan> Many people are either unwilling or unable to assume the burden
>Nathan> of rigorous engineering. In fact, they are overwhelmingly in
>Nathan> the majority.
>
>I read between the lines that you don't think that rigorous engineering
>can be done with dynamic typing. If I misinterpreted, I apologize.
Dynamically-typed languages do little to help you do rigorous
engineering. People who don't care for rigor like them. Others
like them for other reasons, but people who can't be bothered with
rigor will always outnumber the careful.
This is not to say any use of a dynamically-typed language implies
sloppiness. It's just a lot more work to ensure integrity, enough
so to tempt one to cut corners.
The canonical example is the message that pops up on the screen in an
airplane cockpit: "Method not implemented".
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: "JN" <[EMAIL PROTECTED]>
Subject: Winmodem in Linux? Help!
Date: Sat, 3 Jul 1999 10:00:56 +0200
I got a Winmodem in my computer. Can I make so I can run it under Linux or
must I buy a new?
/JN
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: Sat, 03 Jul 1999 14:53:53 +0300
Nathan Myers wrote:
>
> Timo Tossavainen <[EMAIL PROTECTED]> wrote:
> >Nathan Myers wrote:
> >> Timo Tossavainen <[EMAIL PROTECTED]> wrote:
> >> >Nathan Myers wrote:
> >> >>
> >> >> Only people who take the trouble to understand why C++ solves real
> >> >> problems better than the alternatives have any hope of designing a
> >> >> language that can supplant it.
> >> >
> >... I don't believe it does solve problems
> >better than the alternatives. Could you elaborate a bit on
> >why you think that C++ is better than everything else
> >available for any problem (at least any _real_ problem) ?
>
> No sane person would maintain that *any* particular language is best
> for "any real problem".
Well you sounded like it. Now we agree. C++ is better for many
problems than other languages. It mostly depends on the problem
domain.
> C++ is currently best for a number of economically important classes
> of problems, and the language that supplants it will be better for
> those problems. C is ripe for supplanting for that reason: for any
> problem C can address, someone skilled in C++ can do substantially
> better.
This is certainly true because C++ is a superset C. Currently best
is arguable, but not necessarily on technical merits alone, there's
a large developer base and many good implementations of C++, not to
mention good reusable libraries. This is something many other
languages can't claim.
> The point you missed is that the most important aspects of C++ are
> its expressive powers, and specifically those designed to help
> decompose problems into libraries. Maintainability and robustness
> depend on effective decomposition. But it isn't enough to be able
> to code something, you must be able to *afford* to code it.
This also not to say that other languages aren't as good in
decomposing problems. Object-Orientation isn't always the best
paradigm for a given problem, granted it will probably produce
a better decomposition of the problem domain than for instance
top-down structured analysis. Also dynamic extendibility is
something not easy to achieve in C++ programs, many programs
don't need it but some benefit greatly (for instance, Emacs).
The dynamic extensibility part could be corrected by, for instance,
creating a binary standard for classes that are used for
interfaces. I know the no binary standard -part is because it
allows different compiler optimizations, but including a
standard for classes meant to interface with other compilers/
languages would have been helpful.
(something like: exported class <name> { <decl> };)
> The machine-code-speed requirement is what keeps the design honest.
> There are too many low-level details to allow you to decide in each
> case if your language primitives are fast enough. You have to be able
> to trust that they always are as efficient as can be, because low-level
> inefficiencies multiply. High-level efficiency leaves no room for
> low-level design mistakes.
But when you use a library (for instance the STL) you still have
to decide what functions are fast enough.
> The combination of expressiveness in the construction of libraries,
> and scrupulous fidelity to the real machine model, is what gives C++
> its strength. That strength has been enough to overcome its most
> unfortunate inheritances from C: bad declaration syntax and
> promiscuous numeric conversions.
I still run into the numeric conversions part in C++, the
compiler should be a bit more helpful in informing about them
especially signed/unsigned and float/int. I mostly program numerical
algorithms for work.
> Still, those problems that C and C++ fail to address well (even
> through libraries) should certainly be approached using other
> languages. Very large systems are almost always constructed using
> a mix of languages with differing characteristics. GNU/Linux itself
> is a good example: kernel in heavily customized C, utilities in
> portable C and C++, configuration in various scripting languages.
For some problems C++ just isn't practical, this is what dynamic
languages are able to cover.
Now to get back on topic. I don't have anything against
using C++ in programs, but if they are meant to interface with
other programs or especially if they are GUI toolkits, libraries,
or something else meant for wide use, please do not engage in
languistic (and compileristic) practices; create a C interface.
Timo
------------------------------
From: "Dennis G. Allard" <[EMAIL PROTECTED]>
Subject: idea: file events
Date: Sat, 03 Jul 1999 02:42:49 -0700
Here is an idea I'd like to run by the Linux developer community.
Please let me know if it is not new, bad, good, whatever...
I would like to be able to be notified when data changes in some or
any file in the file system (for which I have access permissions).
Types of changes I would (optionally) be able to track:
1) File F was touched (created/accessed/modified) at time X.
2) Inodes (I1, I2, ... IN) have been modified since time Y.
Potential applications of file events:
a) Streaming of selected backup data.
b) Streaming of content indexes.
c) Incremental updates to a relational model of the file system.
d) Replace file polling by event-driven logic.
The idea is that I can hook the file system with a process which
provides an entry point to be called at well-defined moments during
file system updates.
One should be able to respond to changes at any level of granularity
-- either at the level of just knowing that *something* happened to a
file all the way down to knowing exactly what bytes were modified.
A method for synchronizing the response to an event with visibility of
the event outside of the hook process would be required. It should be
possible for the responding hook to not block any file system activity
under most circumstances even before reaction to the event is complete.
All of the details remain to be worked out. I just want to see if
anyone else thinks this idea might be worth exploring further.
Cheers,
Dennis
--
Dennis G. Allard telephone: 1.310.399.4740
Ocean Park Software http://oceanpark.com
________________________________________________________________________
------------------------------
From: [EMAIL PROTECTED] (M. Buchenrieder)
Subject: Re: Winmodem in Linux? Help!
Date: Sat, 3 Jul 1999 09:51:55 GMT
"JN" <[EMAIL PROTECTED]> writes:
>I got a Winmodem in my computer. Can I make so I can run it under Linux or
>must I buy a new?
>/JN
*smack*
No cookie for you. Wrong newsgroup and wrong question.
Hint: Ask Deja.com and thou shallst be enlightened.
Michael
--
Michael Buchenrieder * [EMAIL PROTECTED] * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't munge your address.
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 3 Jul 1999 01:03:33 -0700
Davin McCall <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Nathan Myers) wrote:
>
>>The point you missed by quibbling is that once you cleave the solution
>>space along a library boundary, you have left the domain of "computer
>>science" and are firmly in the domain of "engineering" where your
>>precious axioms are just obvious facts, and the hard problems
>>involve tradeoffs and organizational choices.
>
>I'm really not sure what you mean. "Cleave the solution space along a
>library boundary"??
Any complete program is just, ultimately, a sequence of instructions,
and any Turing-complete language can generate them.
Split the program into pieces, and then you have interfaces between
the pieces. Turing completeness says nothing about those interfaces.
Getting those interfaces right, and getting the cut lines in the
right places to allow them to be right, is the domain of engineering.
C++ has a large variety of very strong tools to describe library
interfaces because it is an engineering language. C has many fewer
such tools.
>>>I take it that you mean they must understand the principles, although
>>>not necessarily how they are applied in C++.
>>
>>No, absolutely the opposite! Real, useful programs are written
>>using real language features. To understand principles you must
>>first understand the specific application. All valid principles
>>are derived from experience, however they may be dressed up after
>>the fact.
>
>Perhaps I was taking you too literally again. If not: Maybe principles
>are derived from experience (that is probably arguable in itself)
You think maybe principles come from a big divinely inspired book?
> , but
>not necessarily from experience with C++. Even the principles of the
>C++ language can be seen in use in other languages. I can envisage the
>indirect studying of the C++ principles, whether knowingly or
>unknowingly, by studying various other languages (including those
>which C++ has borrowed its principles from).
Principles, divorced from experience, rot. If you want to understand
good principles, the only trustworthy source is good code. If you
want to understand the principles behind the success of C++, you must
study good, real C++ programs and libraries. There are no shortcuts.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: "WG" <anonymous>
Subject: Need Kernel
Date: Sat, 3 Jul 1999 08:48:01 -0400
Hi! I was wondering if anyone had or knows where I can get a kernel that
supports the NCR C700 SCSI card. If anyone knows, Please e-mail me at
[EMAIL PROTECTED] Thanks,
-- David
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: 3 Jul 1999 10:52:15 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Timo Tossavainen <[EMAIL PROTECTED]> writes:
>Kaz Kylheku wrote:
>Each language has areas where it is powerful, I'm
>only pointing out that C++ isn't the silver bullet, it isn't
>the best choice for all problems like some people like to
>claim.
Some people do indeed like to claim this, but I hope you are not
saying anybody has done so in their thread this week.
Similarly, some would like to claim that C++ isn't useful for
anything, which is equally a silly statement, and flavorings
of that _has_ come across in this thread.
- 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: [EMAIL PROTECTED]
Subject: Save your printing money
Date: Sat, 03 Jul 1999 16:52:48 GMT
A.R. Tech Communication (CartridgeOutlet) is specialized
in remanufactured toner cartridge & replacement inkjet
cartridges
Our mission is to save your money in printing . All
remanufactured toner cartridges & replacement inkjet
cartridges we offer are under lifetime warranty and 60 days
cash back guarantee.
Laser Printer Cartridge USD$
======================================================
HP92274 (PX).....................................52.20
HP92275 (LX).....................................47.95
HP92285 (LX).....................................54.95
HP92291 (NX).....................................61.95
HP92295 (SX).....................................42.95
HP92298 (EX).....................................59.95
HP3900 (BX)......................................71.95
HP3903 (VX)......................................66.45
HP3906 (AX)......................................54.10
HP3909 (WX)......................................94.95
A-30 ......................................56.95
E-31 ......................................71.20
FX-1 ......................................57.95
FX-2 ......................................68.95
FX-3 ......................................64.95
IBM 4019/28/29...................................79.95
IBM 4039/49.....................................101.60
Laser Printer Cartridge w/Micr Toner USD$
======================================================
HP92274 (PX) Micr Toner..........................77.95
HP92275 (LX) Micr Toner..........................74.95
HP92291 (NX) Micr Toner..........................97.95
HP92295 (SX) Micr Toner..........................81.95
HP92298 (EX) Micr Toner..........................87.95
HP3900 (BX) Micr Toner..........................101.95
HP3903 (VX) Micr Toner...........................93.95
HP3906 (AX) Micr Toner...........................93.95
HP3909 (WX) Micr Toner..........................111.95
HP4000A Micr Toner..............................164.95
HP4000X Micr Toner..............................169.95
InkJet Printer compatiable Cartridge USD$
======================================================
SO20025 STYLUS 800, 1000 black....................9.69
SO20034 STYLUS PRO XL black.......................9.69
SO20036 STYLUS PRO XL C/Y/M......................18.75
SO20047 STYLUS 200, 820, COLOR II black...........9.69
SO20049 STYLUS 200, 820, COLOR II C/Y/M..........15.49
SO20066 STYLUS PRO XL C/Y/M......................18.49
SO20089 STYLUS 400, 600 C/Y/M....................16.97
SO20093 STYLUS 400, 600 black.....................9.99
SO20108 STYLUS 800, 1520 black....................9.99
SO20110 STYLUS PHOTO /PM 700C F. CC/MM/YY.......17.29
SO20118 STYLUS COLOR 3000 black..................22.99
SO20122 STYLUS COLOR 3000 yellow.................22.99
SO20126 STYLUS COLOR 3000 magenta................22.99
SO20130 STYLUS COLOR 3000 cyan...................22.99
SO20138 STYLUS COLOR 300 B/Y/M/C.................14.99
201B BJC 600 SERIES black.........................6.29
201C BJC 600 SERIES cyan..........................6.29
201M BJC 600 SERIES magenta.......................6.29
201Y BJC 600 SERIES yellow........................6.29
201HCB BJC 600E SERIES black......................6.99
21B BJC 4000 SERIES black.........................9.49
21CLR BJC 4000 SERIES Y/M/C......................11.49
642B BJC 300 SERIES black.........................8.99
For more information please visit our website at
http://www.cartridgeoutlet.com
Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you
by the sender of this email may be stopped at no cost to you by sending a
reply to this email address with the word "remove" in the subject line..
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: Sat, 03 Jul 1999 22:27:43 +0300
Greg Comeau wrote:
>
> In article <[EMAIL PROTECTED]> Timo Tossavainen <[EMAIL PROTECTED]> writes:
> >Kaz Kylheku wrote:
> >Each language has areas where it is powerful, I'm
> >only pointing out that C++ isn't the silver bullet, it isn't
> >the best choice for all problems like some people like to
> >claim.
>
> Some people do indeed like to claim this, but I hope you are not
> saying anybody has done so in their thread this week.
No, not exactly, but some of the things that have been said
suggest that. I may have been misled by qualifications, like
'in some cases', 'for some problems', that have been
left out of sentences accidentally. This gives the impression
of the universality of the statement without exceptions.
> Similarly, some would like to claim that C++ isn't useful for
> anything, which is equally a silly statement, and flavorings
> of that _has_ come across in this thread.
Not any more than similar remarks about dynamic languages.
This kind of thing always happends when there's a religious issue
like programming languages (or editors or OSs etc.). The conversation
has to be taken with a grain of salt. All sides will exaggerate the
importance of points in favor of their opinion and the points against
the other sides' opinion.
I believe that the many succesful programs written in C++ prove
it's usefulness. I've only tried to argue that there's room for
improvement in some areas and that dynamic languages can fill that
room, this inevitably brings out the things in C++ that I don't
see as good as they should be. This is not to say that there
aren't good things in C++.
Timo
------------------------------
From: "Daniel WEISS" <[EMAIL PROTECTED]>
Subject: Change video mode
Date: Sat, 3 Jul 1999 20:09:39 +0200
Hi!
I would like to know how can i change the video mode outside Xwindows in C
program,i use gcc and i have already tryed with the function vga_setmode()
in /usr/include/vga.h and the compilator
said that vga_setmode() is undefined.
In addition, i can't fill a buffer without having the message:
Segmentation fault(core dumped).
What 's wrong with that : tab[0]=150; ???
------------------------------
** 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
******************************
