Linux-Development-Sys Digest #916, Volume #6 Wed, 30 Jun 99 15:14:49 EDT
Contents:
Re: You can now use Winmodems in Linux!!!!!!! (Doug DeJulio)
Re: Sleeping or not? (ellis)
Re: Remote login problems in custom RedHat env... (Jon Skeet)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Greg Comeau)
Re: [BUG] current->mm NULL in SMP version of 2.2.x (Christopher Boyd)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Greg Comeau)
Postgresql Success rate ("Alexander F. Hartner")
Re: Mac-emulation on Linux? ("Anthony D. Saxton")
Re: Why not C++ (Greg Comeau)
Re: IPCS(1) Command - Source file available (Alan Curry)
Re: Why not C++ (Greg Comeau)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Doug DeJulio)
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: 29 Jun 1999 17:18:11 -0400
In article <[EMAIL PROTECTED]>,
Sudip Sarbajna <[EMAIL PROTECTED]> wrote:
>Well, how do I make sure that the one in my machine is not winmodem?
>Could you suggest any way to test it from Linux?
I can't give you a way to tell for sure, but I can provide a clue.
Look at the contents of the "/proc/pci" file. We've got a PCI
"non-winmodem" in a box here, and here's the relevant entry:
Bus 0, device 17, function 0:
Serial controller: PLX PCI9050 I2O (rev 1).
Medium devsel. Fast back-to-back capable. IRQ 10.
Non-prefetchable 32 bit memory at 0xe2000000 [0xe2000000].
I/O at 0x6100 [0x6101].
I/O at 0x6200 [0x6201].
(For folks jumping into this thread late, this is how our
development/testing system sees a Chase Research "PCI-RAS4"
non-winmodem multi-modem PCI card. They're expensive, but they're
internal PCI multi-modem cards that do work well with Linux.)
Try to identify your "/proc/pci" entry for your card. See if it has
clues as to what the card is and how it works.
--
Doug DeJulio | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/
------------------------------
From: [EMAIL PROTECTED] (ellis)
Subject: Re: Sleeping or not?
Date: 29 Jun 1999 21:25:50 GMT
In article <[EMAIL PROTECTED]>,
herman <[EMAIL PROTECTED]> wrote:
>I'm working on a driver and need to know at the Interrrup Service
>Routine (ISR) if the "read" call is sleeping or not.
>
>The user program calls "read" and if no data is available, it initiates
>bus master xfer and blocks till some data is available.
>
>When the xfer is complete, a hardware interrupt is triggered. The
>interrupt service routine (ISR) saves the filled buffer pointer and
>count, wakes up the blocked "read", and initiates another bus master
>xfer to a new buffer (circular buffer with multiple pages). If "read"
>is not blocked, then the ISR should not initiate another xfer, but
>should terminate the collection sequence.
>
>The ISR routine wants to know if "read" is blocked and sleeping, waiting
>for more data. How can ISR tell this condition? Would
>current->blocked work at the ISR level? Should I just use a variable
>like a flag?
Keeping a flag is a way to do it.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: [EMAIL PROTECTED] (Jon Skeet)
Crossposted-To: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.security
Subject: Re: Remote login problems in custom RedHat env...
Date: Wed, 30 Jun 1999 16:20:48 +0100
[EMAIL PROTECTED] wrote:
> I have an unusual problem with telnet, rlogin, ftp and any other
> program which requires logging in remotely. The system specs are: 400Mhz
> Pentium Pro, 256MB RAM, onboard Intel etherexpress pro 10/100Mbs network
> card, 2 serial ports, running a custom Red Hat 5.2 kernel. Four kernel
> header files were modified to allow for a 3072 process limit ( fs.h,
> limits.h, posix_types.h, /usr/include/gnu/types.h ). The machine will
> boot and run fine for about 10 minutes then any form of remote log in
> (even rcp and rsh) will hang after it successfully connects to the
> system just before it gives you the opportunity to provide your login
> name and/or password. On telnet you can even see the "Connected to
> <host>" message. Any connection made before this problem occurs is fine
> and has full capabilities. I can get out of the box using any method I
> choose (telnet, ftp, etc). The oddest thing about this problem is that
> all other inetd services are unaffected. They continue to respond to
> request on their respective ports without fail. A tcpdump on the machine
> will show telnet, rlogin, etc ... activity. They send their initial acks
> and replies but don't complete their initialization procedures.
Is it feasible that the problem is in reverse host lookup? I know telnetd
checks that the host that is telnetting to it is valid before going ahead
with the connection; it's possible that rcp does the same. If so,
possibly your DNS is going wrong...
--
Jon Skeet - [EMAIL PROTECTED]
http://www.pobox.com/~skeet/
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 30 Jun 1999 14:11:46 -0400
Reply-To: [EMAIL PROTECTED]
In article <gmVd3.97285$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>On Mon, 28 Jun 1999 19:43:39 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>Look at the above, and what I quoted from Nathan Myers:
>>
>> "[...]Take for example Egcs. C and C++, same code generator,
>> same optimizer."
>>
>>My point was that C++ output is still bigger than C, _for the exact same
>>source code_, using the same code generator and optimizer.
>
>...Which basically goes to say that the C++ implementation is not as
>*mature* as the C implementation.
Or there is a bug or ...
>They may both share the same peephole optimizer; they may both share the
>same RTL code generators.
>
>But they manifestly *do not* share the same parse tree generator.
>(That's kind of the point of them being separate compiler front ends.)
>
>It is quite evident that the front ends generate code differently, and
>this nicely explains the differences in behaviour.
>
>It is manifestly true that G++ FE != GCC FE, and it is pretty evident
>that the GCC FE is *vastly* more mature. Which strikes me as obvious; I
>was using GCC (ANSI C) ten years ago, and considered it quite stable,
>when G++ was not even worth considering.
>
>All of this being said, it is possible for the code generator for C++
>(particularly for EGCS) to persistently underperform the C code
>generator, due to the following two factors:
>a) They are separate.
>b) C++ is a more complex language, thereby making it more difficult to
>write a generator producing code that is both correct and efficient.
Is this really the only two factors you could come up with?
As such, your thinking is biasing the factors.
>Don't misread that as a claim that the complexity makes it inherently
>*impossible* to make a C++ implementation more efficient; it merely
>indicates that it is a difficult task.
So is writing a C compiler, blah blah blah.
- 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] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: 30 Jun 1999 14:23:07 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Isaac) writes:
>On 29 Jun 1999 00:47:32 -0700, Nathan Myers <[EMAIL PROTECTED]> wrote:
>>
>>Precisely. The books grew, chapter by chapter, as the language
>>did. They give most space to earlier features, and treat the
>>later, probably more important, features as afterthoughts.
>>
>Hmm. Your arguments (and Matts) are quite persuasive. I don't
>think the books I use are quite this flawed. I think the info on
>how to use templates is in there, but since I'm not using them
>heavily, my perspective on their importance is skewed.
The overwhelming majority (9x%) of books are complete fossil fuel.
This brings the number of really good books close to zero.
Don't underestimate your author just because they've done so to you :)
- 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: Christopher Boyd <[EMAIL PROTECTED]>
Subject: Re: [BUG] current->mm NULL in SMP version of 2.2.x
Date: 30 Jun 1999 17:51:19 GMT
Arun Sharma <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Jun 1999 14:35:29 GMT, Christopher Boyd <[EMAIL PROTECTED]> wrote:
>> this is a nonzero value and on SMP 2.2.x kernels, I get
>> a 'um_write: current->mm = 0x00000000'.
> Did you compile your module twice, once with -D__SMP__ and once without ?
> If you don't, the offsets within current could be wrong for a SMP
> kernel i.e. current->mm could be accessing the wrong field.
Err, you're right. With __SMP__ def'd, the offset is 1168, whilst
without it it's 920. This fixes it. Many thanks :-)
I am curious where the different offsetting occurs? task_struct
doesn't appear to be modified in linux/sched.h depending by a
conditional define, so it is not instantly obvious (to me).
> If current->mm was really null, your kernel will panic in no time
> - guaranteed!
Yes, I see. It would be kinda silly not to be able to access
the task's memory, wouldn't it :-)
> -Arun
Regards,
Christopher Boyd
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 30 Jun 1999 13:55:43 -0400
Reply-To: [EMAIL PROTECTED]
In article <7l73qd$km0$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Nathan Myers)
writes:
>Paul Jackson <[EMAIL PROTECTED]> wrote:
>>Nathan Myers wrote:
>>|> [Those saying C++ is] slower than (e.g.) C are just spreading FUD.
>>
>>But really, I think you missed my primary point: ...
>>In short, attempts to consider the 'speed of a language' outside
>>the context of the app and the programmer (and others would
>>add - the compiler maturity), are in themselves a form of FUD.
>
>FUD has been, is, and will be.
>Yet, competence is still a far scarcer commodity than CPU cycles.
Indeed. And so undermines the argument that a simpler language
is always more efficient (for the programmer, for runtime, etc ).
- 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] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: 30 Jun 1999 14:41:10 -0400
Reply-To: [EMAIL PROTECTED]
In article <hZfe3.491$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Josh Stern)
writes:
>Greg Comeau <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] writes:
>>>If I'm using a C library, my program might have to say:
>
>>>some_function( &x );
>>>
>>>so, when debugging, I know right there that I can't assume x won't be
>>>altered. The same thing in C++ would be:
>>>
>>>some_function( x );
>>>
>>>but I don't know whether I'm passing by value or by reference or const
>>>by reference. I have to go and find the header, then look through it to
>>>find the prototype for that function. It would be useful if there were a
>>>syntax difference.
>
>>The above is flawed, because in both examples you need to go and find
>>the header, and in both examples you then need to look through it to find
>>the prototype for that function, so the above is a misguided argument.
>>In both examples it would be useful if there were a syntax difference.
>>Neither (x) nor (&x) is sufficient in either C or C++ from this perspective.
>
>>It's more that a development time issue. Anyway, it's doubtful anything
>>about it is changing, so we'll need to settle on good support tools to help
>>out with this, and more.
>
>How about if we just ask the programmer to use some common sense
>and call the non-const version of the function
>
>void
>getSomethingsValue(T& x) ?
>
>
>Then if you see
>
>getSomethingsValue(x);
>
>in a function definition, it is pretty obvious that it is not being
>called to return a value, and the function name is a very strong
>hint that it is not being called to set another value.
Oh indeed, like I said "and more". Naming identifiers properly
is indeed important on this and other things. It's never an end
all or substitute but it is certainly a step in the right direction.
- 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: "Alexander F. Hartner" <[EMAIL PROTECTED]>
Crossposted-To: ahn.tech.linux,alt.os.linux,comp.os.linux.development.apps
Subject: Postgresql Success rate
Date: Wed, 30 Jun 1999 19:49:30 +0200
Has anybody experienced serious problems using Postgresql 6.4 with Java
(JDBC) on a medium size network. Is Datacorruption a problem. From what I
have experienced in the short time that I have been using Postgresql it is
the best thing since sliced bread, but people seem unsure to use it.
Thanks
Alex
------------------------------
From: "Anthony D. Saxton" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.misc,comp.os.linux.powerpc
Subject: Re: Mac-emulation on Linux?
Date: Wed, 30 Jun 1999 18:31:04 GMT
Matthew Pritzker wrote:
> Anthony D. Saxton wrote:
>
> > SheepShaver's fine for those of us privilidged few using the PowerPC version
> > of linux. It won't help anyone that doesn't have a PREP, BeBox or PowerMac
> > though.
>
> Given that SheepShaver started out on the BeBox, I find that hard to
> believe. All you need is a MacOS ROM image, and given that iMac and
> later systems have the ROM sitting as a file in the System Folder, it
> shouldn't be especially hard for you to acquire one.
>
> --
> --------------------
> Matthew Pritzker Graduate Research Assistant
> [EMAIL PROTECTED] IU Physics Dept.
The BeBox contains 2 603e PowerPC processors. SheepShaver is not, nor has it ever
been a processor emulation. It actually runs MacOS native on the PowerPC
processor. SheepShaver for BeOS only runs on PowerPC platforms. Yes. You would
need the ROM images if you're not running it on a Mac, but to use SheepShaver in
Linux, you would need a PowerPC system such a BeBox, PREP or CHRP.
Tony
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.lang.c++
Subject: Re: Why not C++
Date: 30 Jun 1999 14:34:17 -0400
Reply-To: [EMAIL PROTECTED]
In article <7lbbn5$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Paul Jackson) writes:
>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'.
Guess that always works :)
>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.
I definitely agree on this latter point (said so somewhere in
this thread myself).
>|> ... 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.
_You're_ the one dramaticing(sp?), no I :)
>|> 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)
Important clarification! :)
>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,
Gosh, I'd use this same arg for C++.
> 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
If C++ could be simpler, I'd take it, sure.
> 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).
You couldn't just leave it! This now infers that no other
language brings forth confusion. This is not so.
- 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 ***
------------------------------
Subject: Re: IPCS(1) Command - Source file available
From: [EMAIL PROTECTED] (Alan Curry)
Date: Wed, 30 Jun 1999 18:05:31 GMT
In article <[EMAIL PROTECTED]>,
Philippe Campi <[EMAIL PROTECTED]> wrote:
>Hello,
>
> Does anyone knows where I can found the source file for ipcs(1)
>command under Linux ?
sunsite.unc.edu:/pub/Linux/system/misc/util-linux*
--
Alan Curry |Declaration of | _../\. ./\.._ ____. ____.
[EMAIL PROTECTED]|bigotries (should| [ | | ] / _> / _>
==============+save some time): | \__/ \__/ \___: \___:
Linux,vim,trn,GPL,zsh,qmail,^H | "Screw you guys, I'm going home" -- Cartman
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 30 Jun 1999 14:54:39 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Stephan Houben <[EMAIL PROTECTED]>
writes:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>
>> Johan Kullstam <[EMAIL PROTECTED]> wrote:
>> >actually i don't mind the templates in C++. they are rather weak, but ...
>>
>> FUD, again. C++ templates are not weak. They allow construction of
>> libraries that cannot be constructed in any other language.
>
>Templates in C++ solve a problem that simply doesn't exist in most other modern
>programming languages. The fact that it exists in C++ is due to the fact that C++
>is based on C.
>
>Languages like C and Pascal are "strongly typed", which basically means that when I
>have
>a function that squares an int:
> int square(int x)
> {
> return x*x;
> }
>
>,then this function cannot square floats. In order to square floats, I have to define
>a new
>function with almost identical code:
>
> float square(float x)
> {
> return x*x;
> }
>
>
>Now, this problem doesn't exist in dynamically typed programming languages like
>Python,
>since there you would do:
>
> def square(x):
> return x*x
>
>,and the type of x only plays a role at run time (when the correct * operation has to
>be selected).
>
>In other programming languages, e.g. Haskell, you *do* have typing, but there
>types can be more general, i.e. the following definition:
>
> square x = x*x
>
>would be automatically typed by the compiler as being of the type
> square :: (Num a) => a -> a
>, implying that square is a function taking some value of an type a and producing
>a value of the same type, where a may be any type of type class Num, which means that
>a * operation has to be defined on a.
>
>Now both these options are much less cumbersome than the C++ way of doing things;
>moreover, in the Haskell way, you *do* get static typing with all the advantages
>(more efficient code generation, compile-time error checking).
>
>IMHO, C++'s templates are a useful hack to repair a basic flaw in C's type system.
>However, there are certainly much more elegant solutions.
I don't follow. I simply don't follow. First you say stuff like
that templates in C++ solve a problem that doesn't exist in other
languages, and then go on to show generic capabilities of other
languages. That's contradictory.
Then you conclude with a statement that (I assume in other languages)
templates have a more elegant solution. Again, not only does this
contradict that they are not necessarily in other languages, but
your examples DO NOT show how it is more elegant. All you've
shown so far is function-like macros. And C++ templates are not
just that.
It's no secret that I'm very much into C++. However, I ALWAYS
want to learn more about how other langs do stuff. But I keep
seeing posts like above, which attack C++ and then don't clearly
show alteratives. Come on, I'm all psyched up for something hard core.
- 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 ***
------------------------------
** 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
******************************
