Linux-Development-Sys Digest #927, Volume #6 Sat, 3 Jul 99 00:14:01 EDT
Contents:
Re: Why not C++ (Nathan Myers)
Re: Postgresql Success rate (Don Baccus)
Re: usleep() (Peter Pointner)
Re: Why not C++ (Timo Tossavainen)
Re: need # for unix socket (John Jacques)
Re: usleep() (Daniel R. Grayson)
Re: CLONE_PID flag (David Wragg)
Re: gcc library function reference. (Victor Wagner)
kmalloc() (Chi-sheng Shih)
reading bad CD sectors ([EMAIL PROTECTED])
Re: HELP!! HELP!! /etc moved SOS!! SOS!! (Frank v Waveren)
Illegal Instruction in glibc 2.1 (Hans-Joachim Baader)
Re: Why not C++ (Kaz Kylheku)
Re: WHAT ARE THESE TERMS SUPPOSE TO MEAN (Peter Samuelson)
Re: Why not C++ (Kaz Kylheku)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: 2 Jul 1999 14:16:09 -0700
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 understand why C++ solves real
>problems better than the alternatives, even though I've
>been programming C++ for several years.
I believe you.
>There are numerous successful projects written in Lisp. Lisp
>is one of the oldest programming languages and it's still
>among the best. What does that tell you about dynamic
>languages ? They evolve to fullfill the changing needs of the
>users; static languages eventually fade away and die.
Most languages you've heard of can claim successful projects,
even Visual Basic.
Dynamic languages have a place, as they always have. Languages with
a static type system also have a place. When you need one, the other
just won't do.
>If your definition of better is faster and smaller, without
>regard for development speed, extensibility, maintainability
>and robustness, then I understand your point.
No. You have entirely missed the point, in fact.
>> (Hint 1: copying the syntax might be a mistake.)
>
>Yes, the prefix-notation of Lisp is a lot more powerful than
>the infix-notation of C++.
No. The syntax to avoid copying from C++ is the declaration syntax.
>OTOH, he didn't say anything bad about Common Lisp.
I don't recall that anybody said anything bad about Lisp.
The topic here is C++, in case you hadn't noticed.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
Crossposted-To: ahn.tech.linux,alt.os.linux,comp.os.linux.development.apps
Subject: Re: Postgresql Success rate
From: [EMAIL PROTECTED] (Don Baccus)
Date: 2 Jul 1999 14:24:59 PST
In article <[EMAIL PROTECTED]>,
-DadKind <[EMAIL PROTECTED]> wrote:
>Does anyone know if Postgres have ODBC drivers so that I can use
>MSAccess to get to the data? Has anyone done this?
It does, but I've not used it so can't comment as to
how well ODBC works with it.
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: usleep()
Date: Fri, 2 Jul 1999 20:12:59 GMT
Daniel R. Grayson <[EMAIL PROTECTED]> wrote:
> Calls to usleep() take a lot longer than they need to (20000 microseconds
> instead of 1 microsecond on my system). Has anyone thought of improving the
> accuracy of usleep() in Linux? It's possible, because select() can do it.
I see a lot of posts regarding timing, sleeping for small amounts of time,
and similar things. And a lot of people confuse two things:
1) measuring time with high resolution
2) scheduling actions with high resolution or run periodic tasks with high
frequency.
For 1) it is sufficient to have a time base with high resolution. You can
use a special counter on pentium processors to get processor clock
resolution (the rdtsc stuff). And even gettimeofday() should have a
resolution of 1 microsecond.
For 2) you need an interrupt! You could "busy wait" which means reading
the time until the desired interval is over. But then the system can't do
anything else, which is generally not what you want. And does "usleep"
sound like "busy waiting"? So usleep puts the task to sleep, and the
scheduler wakes it after the delay. But now we depend on the timer tick,
which occurs HZ times per second. HZ is normally 100 for ix86, and IIRC
1024 for alpha.
Assuming you have a ix86 system with standard HZ value, you get a timer
interrupt (tick) every 10 milliseconds. So this is possible resolution for
usleep. Since you could call usleep immediately before the next tick,
usleep suspends the task for (usecs * HZ / 1000000 + 2) ticks to make
sure the delay is never shorter than desired. It has to add 2: 1 because
it truncates at the division, and 1 because the next tick might happen
immediately.
If you call usleep in a tight loop, you "synchronize" to the timer tick
and get the 20 ms delay you have seen.
I hope I got it right,
Peter
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: Sat, 03 Jul 1999 04:02:56 +0300
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 understand why C++ solves real
> >problems better than the alternatives, even though I've
> >been programming C++ for several years.
>
> I believe you.
>
The point being that 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) ?
I get that feeling from your posts...
> >If your definition of better is faster and smaller, without
> >regard for development speed, extensibility, maintainability
> >and robustness, then I understand your point.
>
> No. You have entirely missed the point, in fact.
Ok. Compared to C, C++ is better in all these respects (except
maybe size and equal at speed), but it seems that for most
people nothing else than optimized C/C++ will do even if it means
sacrifing some of the other goals that I see at least as important.
The point I missed being ?
> I don't recall that anybody said anything bad about Lisp.
> The topic here is C++, in case you hadn't noticed.
Well actually the topic has spread through several dimensions...
Timo
------------------------------
From: John Jacques <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: need # for unix socket
Date: Fri, 02 Jul 1999 18:37:14 -0400
Ok thanks, I found the C code and it looks like it is searching for an
available UNIX socket (from what I could tell). So, I started the mSQL
server, then recompiled the MySQL server and they both work together
perfectly now.
"Dr. Charles E. Campbell" wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In article <[EMAIL PROTECTED]>,
> John Jacques <[EMAIL PROTECTED]> wrote:
> >Hello, I am running linux slackware 4.0 on a Pentium.
> >
> >I want to run to different database servers and they both seem to be
> >using the same UNIX socket.
> >When both of them are running, only the first one started will connect
> >to programs.
> >
> >The mSQL.sock and MySQL.sock are both zero length and are owned by the
> >system. How can I change a UNIX socket #? I can choose it installing
> >mSQL, but, I have no idea of what the UNIX socket is or what it should
> >be set to.
>
> IF your database server has its port number as a startup parameter
> (whether file-based or command line option), then you can change
> it to something within 1024-65535. You should be able to find
> a free port somewhere!
>
> IF you happen to have source code to the server, then you can dig
> on in, find the port number one or the other is using, and likewise
> change it.
>
> However, I suspect that you're stuck. Its because of this sort of
> problem that the Simple Sockets Library uses a PortMaster; servers
> have names and get assigned ports by the o/s to one that's available.
> (see http://kipper.york.ac.uk/~vic/sock-faq/ssl.tar.gz or
> http://www.erols.com/astronaut/ssl/ssl.tar.gz). The PortMaster itself
> does have a fixed port (IANA registered), but no other server written
> to use the Simple Sockets Library needs to. (to open a server:
> srvr= Sopen("pick a name","s");
>
> Regards,
> Dr C
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBN3urUNgdtXCdbCHhAQHb5QQAtS1NEPU6yw8rWgY6cNIcj1oOiPn1arF9
> BHqpeLnI7cScC1RnoOYJK+AGr2XrLQlncakxiHZlqIGELjpMhBqLzBRmRw6xuM7v
> mW+4+rn0IBHu4eBAvyl+ogUBi+8lPUtvqEzwdBfGRWN8fdFKiSHQdT1STkdmw8WO
> IZ8K6Tkz0xg=
> =FOEs
> -----END PGP SIGNATURE-----
> --
> Charles E Campbell, Jr, PhD _ __ __
> Goddard Space Flight Center / /_/\_\_/ /
> [EMAIL PROTECTED] /_/ \/_//_/
> finger [EMAIL PROTECTED] for PGP public key
------------------------------
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Subject: Re: usleep()
Date: 02 Jul 1999 18:06:04 -0500
Peter Pointner <[EMAIL PROTECTED]> writes:
> Daniel R. Grayson <[EMAIL PROTECTED]> wrote:
>
> > Calls to usleep() take a lot longer than they need to (20000 microseconds
> > instead of 1 microsecond on my system). Has anyone thought of improving the
> > accuracy of usleep() in Linux? It's possible, because select() can do it.
> ...
> If you call usleep in a tight loop, you "synchronize" to the timer tick
> and get the 20 ms delay you have seen.
>
> I hope I got it right,
>
> Peter
Thanks for the precise explanation about how usleep() works.
Have you ever wished usleep() were accurate? It's possible, because select()
with timeout is accurate.
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: CLONE_PID flag
Date: 01 Jul 1999 23:59:58 +0000
Vincent Danjean <[EMAIL PROTECTED]> writes:
> I am looking for information about the CLONE_PID flag (in the
> clone() system call). More precisely, I would know what appends when a
> signal is send to a pid shared between several threads. Does it depend on
> the signal sent ?
CLONE_PID isn't finished, and has been like that for a long time. It
is used internally by the kernel on SMP systems, but otherwise is
probably best ignored. If you're just curious then fine, but it is
probably a bad idea to try to use it to get anything serious done.
The intention, around the time that the clone system call was
introduced, was that CLONE_PID could be used to implement POSIX
threads signal semantics. The problem with that approach is that it
requires thread ids to be added to the kernel, which would involve a
large amount of effort without directly contributing to the desired
signal behaviour. I think this is why the CLONE_PID effort hasn't
shown any sign of life for a few years now.
To answer your question, signals sent to a pid that due to CLONE_PID
is shared by several tasks will always go to a particular one of the
tasks. I can't remember what determines which particular one that will
be, but you can work it out from the kernel source.
> So, is there information about this elsewhere than in the kernel
> sources ?
No. Everyone has wisely ignored it in its present state.
David Wragg.
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To: comp.os.linux.development.apps,linux.dev.gcc
Subject: Re: gcc library function reference.
Date: 2 Jul 1999 20:55:45 +0400
Kim,Taesung <[EMAIL PROTECTED]> wrote:
: Hello!
: Does anybody know where I can get gcc library function reference?
: and
: Can I have source code of library?
You should already have it. You should have source CD in your
distribution, and there always is source of libc (it is HUGE).
And with sources there is documentation in texinfo format. If you format
it with TeX and print out, you'll get 900 pages book.
Really, it is more than just refernce. man pages are references, and
info documentation is also a tutorial, manual and whatever.
: Thank in advance.
--
========================================================
Victor Wagner @ home = [EMAIL PROTECTED]
I don't answer questions by private E-Mail from this address.
------------------------------
From: Chi-sheng Shih <[EMAIL PROTECTED]>
Subject: kmalloc()
Date: Fri, 02 Jul 1999 18:35:20 -0500
Hi,
I try to use kmalloc in kernel to allocate a memory. However, it seems that
it always return NULL. Is there any trick to use kmalloc()?
By the way, is there anyone know what does these priority argument, such
as GFP_KERNEL and GFP_ATOMIC, mean for?
Thanks.
Chi-sheng
------------------------------
From: [EMAIL PROTECTED]
Subject: reading bad CD sectors
Date: 2 Jul 1999 23:56:24 GMT
I'm trying to figure out how to make a C program read bad CD sectors
(scratched, weird CDs, etc), but I"m having trouble making sense of
linux/cdrom.h and linux/ucdrom.h. In linux/cdrom.h, I see the struct
ccs_err_recovery, which seems to be on the right track, but I don't
understand which ioctl to feed it to.
I've seen sort of thing done with cd-roast (not the X11-based x-cd-roast,
but a text-mode thing). Unfortunately I haven't seen cd-roast since then.
Search engines can't find it.
I'd like either a snippet of code to turn off error-detection/correction,
or pointer to somewhere I can find cd-roast.
--
David Griffith
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Frank v Waveren)
Subject: Re: HELP!! HELP!! /etc moved SOS!! SOS!!
Crossposted-To: comp.os.linux.setup
Date: Sat, 03 Jul 1999 01:09:19 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Juergen Heinzl) writes:
> sync
> sync (cannot hurt)
> a deep breath
> a hard reset
> [...]
> ... and yes, it works.
wouldn't just unmounting be easier?
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED] (Hans-Joachim Baader)
Subject: Illegal Instruction in glibc 2.1
Date: 2 Jul 1999 23:20:03 +0200
Hi,
since I installed glibc 2.1 (and later 2.1.1) one of my machines has
problems. Several programs crash with SIGILL. Here's a sample from
the gdb disas command:
The illegal instruction happened at 0x4011d9f8:
0x4011d9f8 <__tzfile_read+500>: bswap %eax
Call stack:
#0 0x4011d9f8 in __tzfile_read () from /lib/libc.so.6
#1 0x4011c80f in tzset_internal () from /lib/libc.so.6
#2 0x4011d6f7 in __tz_convert () from /lib/libc.so.6
#3 0x40119a72 in localtime () from /lib/libc.so.6
#4 0x80a88ea in Perl_pp_gmtime ()
#5 0x80a8888 in Perl_pp_localtime ()
#6 0x80b1402 in Perl_runops_standard ()
#7 0x805929d in perl_run ()
#8 0x8057839 in main ()
#9 0x400adfff in __libc_start_main () from /lib/libc.so.6
This machine runs exactly the same software as some of my other
machines. The only difference I see is that this machine has a
386 CPU while the others have 486, Pentiums, K6 and Celeron.
I compiled glibc myself with egcs 1.1.2 and i586-pc-linux-gnu as
target. i386-pc-linux-gnu didn't make a difference.
Obviously, the bswap instruction is not a 386 instruction. But
why the heck does the compiler create non-386 instructions?
I didn't tell it to...
Any help would be appreciated.
Thanks,
hjb
--
You feel strangely lucky...
http://hjb-net.de/linux/ - Linux help and links
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 03 Jul 1999 02:40:23 GMT
On Sat, 03 Jul 1999 03:30:49 +0300, Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>Nathan Myers wrote:
>>
>> Timo Tossavainen <[EMAIL PROTECTED]> wrote:
>> >Your Lisp-bashing has gone a bit too far.
>>
>> I have not bashed Lisp. I have not seen any bashing of Lisp here.
>>
>> The subject is C++, and I have posted correcting falsehoods
>> written about C++. It happens that Lisp doesn't meet my needs,
>> but it doesn't seem to have been meant to. That's OK.
>
>Well, I'll explain that comment:
>
>Johan> some would say static typing is a burden.
>
>Nathan> Many people are either unwilling or unable to assume the burden
>of
>Nathan> rigorous engineering. In fact, they are overwhelmingly in the
>majority.
>
>I read between the lines that you don't think that rigorous engineering
>can be done with dynamic typing. If I misterpreted, I apologize.
I read it as saying that it's easier to let the computer take care of
the tedium of verifying that an object that is intented to represent some
type is not misinterpreted as some other type. Users of statically
typed langauges are unwilling to sacrifice execution speed for
convenience, so they undertake the relatively small burden of ensuring
that everything is declared properly and made subject to correct
operations. This burden is small compared to ensuring correctness ``by
hand'' in a typeless language like BCPL or assembly.
But typeless languages should not be confused with dynamically typed languages.
Users of Lisp or Smalltalk do not want either burden, and pay for that with
cycles.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: WHAT ARE THESE TERMS SUPPOSE TO MEAN
Date: 1 Jul 1999 21:22:20 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Mike Castle <[EMAIL PROTECTED]>]
> And even then, they probably shouldn't be using HZ should thaey? But
> rather a function call?
You mean a global variable?
It could certainly be done. But it would make many things less
efficient. There are a lot of places where a driver needs to, say,
send two things to a card at least 150 ms apart:
unsigned long foo;
/* send first event */
foo = jiffies + 150*HZ/1000;
while(time_after(foo, jiffies)) {
/* do other things */
}
/* send second event */
Note that the assignment statement becomes `jiffies + 15' at compile
time. Now, a multiply and a divide are not *that* expensive, but it's
still good to avoid them. With a variable (const unsigned int hz=HZ;)
the compiler would have to do the math at runtime.
> Consider a 3rd party binary only driver that makes that assumption
> and someone who has tweaked their kernel to have a different value
> for HZ.
See, that's just it: Linus does *not* consider a 3rd-party binary-only
driver. He takes *no* pains to accomodate kernel code that can't or
won't be recompiled when necessary. I fully support him in this (as in
most issues). I'm not sure how MODVERSIONS got past him -- it seems to
me to be an enormous kludge -- but he has *no* compunctions for
breaking binary compatibility when he deems it technologically
desirable.
(Note: I said "in kernel code". Linus is *very* reluctant to ever
break user space. He generally only does that between major stable
releases, and to the very least extent possible.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: Sat, 03 Jul 1999 03:20:21 GMT
On Fri, 02 Jul 1999 20:27:45 +0300, 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.
>
>There you go again. I don't understand why C++ solves real
>problems better than the alternatives, even though I've
>been programming C++ for several years.
Because a lot of real world problems have performance requirements,
as well as the ability to interface tightly to machine-level
constructs, in addition to requiring object oriented techniques.
>Take for example the GoF "Design Patterns"-book, which clearly
>shows how C++ has to be forced around several real world
>problems that occur in _dynamic_ software. For instance, the
>Command pattern, Lisp has a solution for the problem that is
>faster to code than you can say "lexical closure". The
>Serializer Pattern coupled with Factories can be in most cases
>accomplished with the regular Lisp print- and read-functions.
>In dynamic languages you can basically forget half of the
>Pattern book.
You should probably forget it even in C++.
>There are numerous successful projects written in Lisp. Lisp
How many of these have anything to do with high performance
computing? Name three real-time kernels written in Lisp.
Does anyone write device drivers in Lisp? Has anyone written
the software for a high-performance internet router in Lisp? How about
simulations? Who does number-crunching in Lisp, whether scientific,
engineering, or financial? What about computer graphics? Compilers?
>is one of the oldest programming languages and it's still
>among the best. What does that tell you about dynamic
>languages ? They evolve to fullfill the changing needs of the
>users; static languages eventually fade away and die.
Fortran is older and is still in use.
>If your definition of better is faster and smaller, without
>regard for development speed, extensibility, maintainability
>and robustness, then I understand your point.
Software developed once by a team of 20 people might be executed on a regular
basis by several million people, or may be embedded into millions of machines.
It would be ridiculous to claim that C++ sacrifices development speed,
extensibility, maintainability or robustness for faster and smaller executable
code, because it has a lot of features that help in these areas.
In reality a balance is needed. The software must be developed on time, perform
well, be stable and survive changing requirements. Of these, all but one
can be overcome with sheer discipline and ingenuity even in the face of
primitive programming tools. The one that cannot is performance. You cannot
will your program into running any faster, and restructuring a program into
running faster will only go so far---and perhaps at the sacrifice of clarity
and structure.
The best way that humanity knows for programming computers for reasonable
efficiency without sacrificing the clarity and maintainability of programs
is through the use of statically typed programming languages that are
mechanically translated into machine code.
>> (Hint 1: copying the syntax might be a mistake.)
>
>Yes, the prefix-notation of Lisp is a lot more powerful than
>the infix-notation of C++.
That may be true, but the infix notation is what most humans learn from first
grade, and hence find easier to understand. When computers were first taught to
parse and evaluate algebraic expressions, it was a big step forward. Prefix
notations are nothing but laziness on the part of the language designer, who
forstalls his or her fears of implementing the expression parser by making
concessions in the syntax. They are left-overs from assembly languages, in
which typically the opcode is written first, followed by the operand
parameters. A language should be designed from the perspective of the user,
not from the perspective of the parser writer. (Mind you, in the light of this
observation, C++ gets a failing grade on the grounds of having a big syntax
with lots of gadgets. And much of the syntax in C was designed to facilitate a
single pass compile, such as putting the type specifiers first in a
declaration.)
In any case, function calls in C and C++, which are perhaps the most important
construct, essentially have a prefix notation. You have an expression that
designates an operation, followed by a list of arguments. In C++, nearly any
infix operation can be hidden behind an inline function, if you are so
inclined. If you prefer to say add(a,b) instead of a + b, you can have it. Of
course things like member access or scope resolution can't be treated this way.
------------------------------
** 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
******************************
