Linux-Development-Sys Digest #908, Volume #6 Tue, 29 Jun 99 16:14:26 EDT
Contents:
Re: PTHREADS kernel/user level threading? (Matthew Carl Schumaker)
Re: Why not C++ (Tristan Wibberley)
Re: Another Windows developer looking for a good IDE (Neil McKay)
Re: Proposal For New Windowing software (Matthew Carl Schumaker)
Strange compiler behaviour with g77 and SMP (Martin Kahlert)
Re: /proc/ksyms on SMP machines (David J. MacKenzie)
Re: Why not C++ (Johan Kullstam)
Re: Proposal For New Windowing software (Tristan Wibberley)
Re: File Allocation Tables ("Michael Jacobsen")
Re: Why not C++ (Greg Comeau)
Re: Strange compiler behaviour with g77 and SMP (Martin Kahlert)
file propagation (Eldhose John)
----------------------------------------------------------------------------
From: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Subject: Re: PTHREADS kernel/user level threading?
Date: Tue, 29 Jun 1999 09:26:22 -0400
On 28 Jun 1999, David Wragg wrote:
> > Does anyone know if this is supported or is there just
> > user level threading where the process is shunted onto
> > one CPU and does its threading on its own, and can't use
> > the multiple CPU's?
>
> The main thing to watch out for is that LinuxThreads doesn't implement
> the Pthreads signal behaviour. Otherwise you should be fine. RH6 even
> has gdb with thread support.
>
> David Wragg
>
What do you mean? I've written Multithreaded apps that use pthread
signals and they work just fine.
Another pitfall is that there is a limit on the number of threads(or tasks
for that matter) of 256 for any given user and a system wide limit of 512
If you want to change that you have to edit the tasks.h file (but ignore
the comments the real max is 4088)
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Mon, 28 Jun 1999 01:06:14 +0100
[EMAIL PROTECTED] wrote:
>
>
> C++ is a superset of C
[snip]
Not *strictly*, though your simple test code is probably a subset of
both C and C++.
> I compiled and compared like this:
>
> $ vi simple.c
> $ /egcs/bin/gcc -O2 -s simple.c
> $ mv simple.s simple.s.gcc
> $ mv simple.c simple.cc
> $ /egcs/bin/g++ -fno-exceptions -fno-rtti -O2 -s simple.cc
> $ mv simple.s simple.s.g++
> $ diff -u simple.s.*
>
> : Now, which C compiler are you comparing it against to say that "egcs
> : -fno-exceptions -fno-rtti -O2" is worse than it?
>
> 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.
Since you have speed optimisation in there as well, the C++ compiler
could be adding extra code for speed (it uses a slightly different
frontend). This is *not* an equal test of code size. You need to specify
-fno-* options to remove *all* speed optimisations, and use -f* to
specify equal size optimisations if you want to test code size fairly
for the current egcs implementation.
Why is this thread on comp.os.linux.networking? Removing from
followups...
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Neil McKay <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Another Windows developer looking for a good IDE
Date: Tue, 29 Jun 1999 10:49:07 -0400
David L Jarvis wrote:
> If I use something like VisualAge, NetBeans, or FreeBuilder, are there
> "components" (objects) available so that I don't have to spend months
> creating
> a "treeview" control to start from? In the VB world there are countless
> thousands
> of components out there to choose from (of course, VERY few of them are
> worth
> a damn), is there a similar market out there for that Java/Linux world?
>
You might take a look at Tcl/Tk. Tcl's a scripting language, and Tk is a
windowing toolkit built
on top of Tcl. There are a variety of widgets available, and there's a
VB-like environment for
it called (duh) "Visual Tcl". (I haven't used Visual Tcl; i find that it's
pretty easy to build interfaces
just by writing scripts.) Tcl/Tk runs on Unix variants (including linux),
Windows PCs, and
the Mac.
--
Neil D. McKay, Mail Code 480-106-359 Phone: (810)986-1470 (GM:8-226-1470)
Enterprise Systems Lab FAX: (810)986-0574 (GM:8-226-0574)
GM Research & Development Center Internet: [EMAIL PROTECTED]
30500 Mound Road
Warren, Mich. 48090
------------------------------
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 09:31:41 -0400
> On Mon, 28 Jun 1999 09:40:08 -0400, Matthew Carl Schumaker
> <[EMAIL PROTECTED]> wrote:
> >During the past couple weeks I've seen many people express their opinions
> >on both Xwindows and C++. The project that I'm proposing is one that I
> >not only want seen done but is also one that I want to participate in.
> >
> >The proposal is for a new Windowing System that is based on the premise of
> >a 3D UI. I know other people are interested in this sort of program as
> >well as a couple private ventures, but to the best of my knowledge there
> >is no Open Source project of this type.
>
> 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.
My concept is close to what Synapse is (www.oreality.com i think) except
Open Source
later
matt
------------------------------
From: [EMAIL PROTECTED] (Martin Kahlert)
Subject: Strange compiler behaviour with g77 and SMP
Date: 29 Jun 1999 13:41:13 GMT
Reply-To: [EMAIL PROTECTED]
Hi,
i have a very strange problem after jumping to 2.2.10 (2.2.5
produces the same behaviour):
I have a dual PPRO system.
This fortran prog:
WRITE(*,*) 'HALLO FORTRAN'
END
and the tcsh script
while 1
g77 -o t t.f ; ./t
end
produces an irregular column of
HALLO FORTRAN and Segmentation fault strings.
The executables, which produce SegFaults produce them every time.
The running ones run every time.
I thought it could be my binutils, but 2.9.1.0.22 and 2.9.1.0.25
produce the same behaviour.
My g77 is from egcs-1.1.2 and the newest snapshot for the upcoming release
g77-2.95. (egcs-19990623)
The problem seems to be after the assembler run. If i compile t.f into t.s
and use g77 -o t t.s; ./t instead i get the same irregular runs.
ldd t gives:
libm.so.6 => /lib/libm.so.6 (0x40008000)
libc.so.6 => /lib/libc.so.6 (0x40022000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
(it's the same for segfaulting and running t's)
I tried it whithin gdb:
gdb t
run
Program received signal SIGSEGV, Segmentation fault.
0x804d043 in l_write ()
(gdb) where
#0 0x804d043 in l_write ()
#1 0x8048e3d in do_lio ()
#2 0x8048df6 in MAIN__ ()
#3 0x804b2d9 in main ()
I don't have any clue, what went wrong here.
Who has fault? egcs? binutils? linux-kernel?
If anybody has any good idea please help!
Thanks in andvance,
Martin.
--
esa$ gcc -Wall -o ariane5 ariane5.c
ariane5.c: 666: warning: long float implicitly truncated to unsigned type
esa$ ariane5
------------------------------
From: [EMAIL PROTECTED] (David J. MacKenzie)
Subject: Re: /proc/ksyms on SMP machines
Date: 29 Jun 1999 11:49:41 -0400
Someone emailed me with the workaround: make sure you have
# CONFIG_MODVERSIONS is not set
in /usr/src/linux/.config. It looks like a kernel 2.2.5 bug (at least
RedHat's version) that you can't have both SMP and kernel module
versioning at the same time.
[EMAIL PROTECTED] (David J. MacKenzie) writes:
> I wish my problem were that simple. I can't get kernel modules to
> work with SMP turned on using RH6. The modules get unresolved
> SMP-related symbols when it tries to load them (with modprobe).
> Red Hat says it's not an installation problem so they won't help.
> Both the kernel and the modules were compiled with SMP=1 from a clean
> source tree. It looks like RH6 only supports SMP with a monolithic
> kernel, which means you can't use an ISA PnP sound card.
>
> root@vorpal 1 $ modprobe sound
> /lib/modules/2.2.5-22/misc/sound.o: unresolved symbol __global_cli
> /lib/modules/2.2.5-22/misc/sound.o: unresolved symbol __global_save_flags
> /lib/modules/2.2.5-22/misc/sound.o: unresolved symbol __global_restore_flags
> /lib/modules/2.2.5-22/misc/sound.o: unresolved symbol __global_sti
> pre-install /lib/modules/2.2.5-22/misc/sound.o failed
>
> sound: No such file or directory
> sound: No such file or directory
> root@vorpal 2 $ cat /etc/conf.modules
> alias scsi_hostadapter 53c7,8xx
> alias eth0 tulip
> alias parport_lowlevel parport_pc
> pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start
> alias sound sb
> pre-install sound insmod sound dmabuf=1
> alias midi opl3
> options opl3 io=0x388
> options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
>
>
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 29 Jun 1999 12:44:19 -0400
Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> In comp.os.linux.networking Johan Kullstam <[EMAIL PROTECTED]> wrote:
> >> ... you will end up with identical machine code, no matter whether you
> >> compile with the C compiler, or compile with the C++ compiler (using the
> >> same C compiler as the back end).
i didn't write the above btw.
the front-ends are different (cc1 and cc1plus for C and C++
respectively). code which is in the intersection of C and C++ (valid
and meaning the same thing in both languages) could be compiled to the
same thing (modulo name manging and other trivialities) but then again
they might not.
> sure, but if you have virtual functions, then those need a lookup. I
> think it is measured between 2-30%. This is True for Eiffel
> Compilers who generate C from Eiffel code, too.
> In theory there is no overhead if you dont use C++ Features, but then
> again.. it is not faster as C.
and conversely, if you have C, you may as well use a C compiler on it.
--
johan kullstam
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Proposal For New Windowing software
Date: Mon, 28 Jun 1999 18:09:04 +0100
Reply-To: [EMAIL PROTECTED]
Matthew Carl Schumaker wrote:
>
> > >
> > > 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,
But to make use of the 3D aspects of *any* GUI, it can only run on a GUI
which supports it. Lets call the window manager the environment manager
for Berlin. For an application to put arbitrary 3D objects into an
environment, it needs the co-operation of the other items in that
environment - this is not a design limitation, it is the *only* way to
do it without apps ruining your interactive computing experience. Even
use of windows requires support from the environment manager. One way
around it is to mandate that environment managers support the 3D
features - but you still can't *force* them to. The other way is to only
allow the use of _The_One_True_Environment_Manager_ Which is probably
what the commercial system your mentioned does to avoid the problem
above.
Now the problem is that you may like the way the environment manager
looks and feels, but no-one else does - this means that no-one will use
your software.
The final option is simply to not make Berlin available to the public
until it is fully written. Thing is, I want it as soon as it supports 2D
properly.
Your best option then is to write for the commercial product, and
mandate that your customers use that instead of just mandating that they
use *any* environment manager which supports Berlins eventual 3D
features.
> 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.
OpenGL doesn't interact, it draws. And the only cpu intensive tasks
would be rendering a 3D environment without a 3d accelerator (another
reason not to design 3D support as a requirement, since *many* people
don't have accelerators), and any applications you run that might do
lots of work.
> 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).
Yes, the Berlin input subsystem provides the environment manager with
data from the input device (x,y,z-axis, pitch,yaw), and some piece of
code translates that into a re-positioning on items in the environment.
You'll always have an environment manager component, always - I advocate
not forcing everyone to use the processor intensive "Matthew's favorite
which wont run on your computer" by building it into Berlin. Your
proposal is *very* inadequate, and poorly thought out. Unless I
mis-understand you completely, which I think may be the case.
> 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.
Depends, if you want an eccessivly complex environment manager, then,
since Berlin is so well designed, it will be far bigger, but probably
still quite small.
> 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
The way I see it, there are 3 ways to do it:
Designing the system from the ground up with 3D in mind, and then
implementing support for it.
Not designing the system from the ground up with 3D in mind, and then
trying to add support for it.
Designing the system from the ground up with 3D mandated for all users,
no matter how powerful their computer.
I (along with the Berlin people it seems) would rather do the 1st one
than either of the others.
--
Tristan Wibberley
------------------------------
From: "Michael Jacobsen" <[EMAIL PROTECTED]>
Subject: Re: File Allocation Tables
Date: Tue, 29 Jun 1999 16:34:53 +0200
Adam Brinley Codd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> I've been looking everywhere for information on File Allocation Tables,
> and I finally found some information on my MSDN Libary CD, but I think
> there is a mistake, and this is the only newsgroup I can find which
> might help me, so desipte the info being MS, please help...
>
> What I'm trying to do is create an undelete program for my Psion 3c. The
> information I found (mk:@ivt:nt40res/D15/S39DB.HTM if anyone has the CD
> and want's to look it up) says
>
> "Folders have a 32-byte entry for each file and folder contained in the
> folder. The entry includes the following information:"
>
> It then lists the information and how many bits each one takes up.
> However, it adds up to 27 bytes, not 32.
>
> It says the "Create time" field is 24 bits but the "Last modified time"
> is only 16. It says all the dates are 16 bits, and the "Starting cluster
> number in the file allocation table" is 16 bits (wouldn't this vary
> depending on if it was FAT12 (as on my Psion) or 16 or 32?
>
> Anyway, this is an example of the 32 bits used to store data on a 5000
> byte file on my Psion:
>
> 46 49 4C 45 33 20 20 20 44 41 54 20 00 00 00 00
> 00 00 00 00 00 00 46 8C D7 26 16 00 88 13 00 00
>
The data you describe is not from the File Allocation Table, it's an
directory entry. It's defined as this:
char8 deName[8];
char8 deExtension[3];
char8 deAttributes;
char8 deReserved[10];
uint16 deTime;
uint16 deDate;
uint16 deStartCluster;
uint32 deFileSize;
This information is from the MS-DOS Programmer's Reference 6.0 and
covers FAT12 and FAT16. If it's FAT32 it's different (as far as I remember,
some of the deReserved bytes are used).
> I've identified the last 4 bytes as the file size, and I assume the time
> fields are seconds since sometime in 1970 (AFAIK it's Y2.36K complient)
> but how is the date worked out, and does it take up 16 bits?
>
> Thanks very much for any help :-)
>
> Adam.
>
> btw> does anyone know a *good* source of info on FATs? I've looked at
> the LDP but can't find anything. I've searched my linux cd but can't
> find much.
>
Somewhere on Microsofts homepage (under MS Developer) you can find the
MS-DOS Programmer's Reference. Try it, but be ready to do some (alot) of
experimenting :-)
Regards,
Michael (mailto:[EMAIL PROTECTED])
>
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
======== Over 73,000 Newsgroups = Including Dedicated Binaries Servers =======
------------------------------
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: 29 Jun 1999 14:56:15 -0400
Reply-To: [EMAIL PROTECTED]
In article <7l4020$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Paul Jackson) writes:
>Nathan Myers wrote:
>|> it's slower than (e.g.) C are just spreading FUD.
>
>well, yes and no. Narrowly speaking, yes, give or
>take secondary points, such as:
> - it gives you more ways to speed things up
> - exception handling can impact the calls a little
> - the tighter types can help the optimizer a little
> - templates and STL can really help some apps
Ok'ish.
>but in some broader sense, there is an increased
>risk with C++, as compared to C, that someone not
>sufficiently skilled in the art will end up with
>slower code, not realizing that the extra features
>they are using do have a cost (virtual calls, lots
>of nickle and dime mallocs, ...)
Sometimes, yes.
>Then again, C has an increased risk, compared with
>C++, that someone will end up with a slower app
>because the lack of explicit support for certain
>patterns and techniques led them to doing something
>in some inappropriate homebrew fashion.
Usually I find folks making the point above to be biased and
never mentioned the counters like this. Good for you.
>But my primary point here is that C++ is complex,
>like a Boeing 747 cockpit. I've seen some large
>scale project pain, when developers tried too hard
>to use all that nice new "object oriented" stuff
>that was suppost to make life wonderful. The pain
>certainly included "too slow", though a bigger
>problem was "difficult to maintain and adapt".
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? Granted, ok, maybe a Boing 747 cockpit
can be similified in some way, but what would you say about
such a pilot who did what I just inferred? Now, what
do you want to say about the developers?
>Put it this way -- if I could actually try ten
>different teams of professional but not superstar
>programmers, using different languages to implement
>a real world (multi-year, requirements changing
>for the life of the project, ...) app, right
>now I'd bet that Python team (a delightful language
>that I just learning) would produce the fastest
>working app (because they'd have time to get the
>architecture and algorithms 'right'), and the C++
>team would produce one of the slower apps, with
>a few key loops going fast, but bogged down in a
>slew of other confusions.
You are really going out on a limb here. "Programming"
is about concepts, techniques, understanding problems, etc.
Although I agree the different perspective of each respective
should not be discarded, you seem to be saying that changing
the language is going to make a genious out of an idiot,
and that's nuts.
Ok, maybe I'm missing your point. Why would Python make the
architecture and algorithms right'er?
- 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] (Martin Kahlert)
Subject: Re: Strange compiler behaviour with g77 and SMP
Date: 29 Jun 1999 15:22:14 GMT
Reply-To: [EMAIL PROTECTED]
Sorry, to follow up my own post.
I tried the same with linux.2.0.37 (SMP enabled)
and everything is fine again. (Nothing else changed:
egcs-19990623 and binutils-2.9.1.0.25)
Thus it seems to be definitely a linux kernel problem.
(is it possible, that some file io routines are not SMP safe?
The error occured always in some g77 file io routines. In which
one exactly depends on the binutils-version.
Thanks in andvance,
Martin.
PS: Am i the only one, who sees this strange behaviour?
--
esa$ gcc -Wall -o ariane5 ariane5.c
ariane5.c: 666: warning: long float implicitly truncated to unsigned type
esa$ ariane5
------------------------------
Date: Tue, 29 Jun 1999 15:32:58 -0400
From: Eldhose John <[EMAIL PROTECTED]>
Subject: file propagation
Hi,
Could somone explain what is file propagation and wht is its use
Thanks for your time
John
------------------------------
** 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
******************************
