Linux-Development-Sys Digest #924, Volume #6 Fri, 2 Jul 99 07:13:59 EDT
Contents:
Re: Microsoft equivilant classes (looking for) (Igor Zlatkovic)
Re: Proposal For New Windowing software (George MacDonald)
Re: Why not C++ (Bruce Hoult)
Re: WHAT ARE THESE TERMS SUPPOSE TO MEAN (Emile van bergen)
update_vm_cache in 2.3.9 (Juergen Koslowski)
Re: Why not C++ (david parsons)
Re: C++ templates: More than Turing Complete? (Alexander Viro)
Re: C++ templates: More than Turing Complete? (Mads Dydensborg)
Re: A New File System Install (Florian Erhard)
Re: Why not C++ (Nathan Myers)
Re: Why we are still holding on to X Windows (david parsons)
Re: Why not C++ (david parsons)
Re: Install Mandrake 6.0 on laptop (compaq armada 6500) ("Anders �stling")
----------------------------------------------------------------------------
From: Igor Zlatkovic <[EMAIL PROTECTED]>
Subject: Re: Microsoft equivilant classes (looking for)
Date: Fri, 02 Jul 1999 07:41:12 +0000
There are many things that can be used for the same purpose under Linux.
Unfortunately nothing equivalent. This means that you will not be able to
port the code, but must begin from scratch.
Qt, found at http://www.troll.no is nearest to MFC in my opinion.
Tom glass wrote:
> I'm trying to convert code written in VC++ to my new Linux platform. In
> VC I used some microsoft classes like CString and CPtrArray, which were
> very handy. I'm thinking I can't be the only one who liked these
> classes and I'm wondering if anyone has created equivilents for Linux.
> Can anyone help?
> Thanks
> Tom
--
Igor Zlatkovic mailto:[EMAIL PROTECTED]
University of Applied Sciences, Frankfurt, Germany, EU
"If at first you don't succeed, redefine success."
-- /usr/bin/fortune, 12.5.1999.
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Proposal For New Windowing software
Date: Fri, 02 Jul 1999 08:20:25 GMT
Tristan Wibberley wrote:
>
> 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.
This reminds me of going from monochrome to color apps, or static graphics to
animated graphics. It's fairly typical to design apps/systems based on the
current hardware limitations/performance. Generally when this is done,
one binds to the implementation to the locality of the current genre of
hardware. Such temporal fixations provide "upto date cutting edge" interfaces
that are also guaranteed to be out of date and stale in the future. Better
designs abstract away from the hardware, but often loose the "edgy" feel
and cost more in development time.
i.e. right now one could build a rather nifty "virtual" reality engine and
interface based on the current 3dfx or RAGE features. Hey an interface that
could have real fog for data/objects that are still a bit hazy! ... My
process viewer could have pulsating blobs for each process with flying
messages cruising from process to process in real time, lighting bolts
for signals, morphing 3d icons for forking children ... But then it
will only run on a few thousand machines. Of course in 3-4 years that
number would be millions, and in 8-10 years that would probably be most
machines in existence.
Of course binding to the current feature set will also limit the expresiveness
to the current techniques. These will obviously be augmented in the future
by better visuals as well as other sensory I/O. Building another interface
that also supports 2d is of limited value unless it adds some other kind
of technology(component architectures, built in context sensitive tutors ...).
The X window system was exceptionally well designed, examine it's longevity and it's
continued usage. It will stay arround in the same way that the VT100/ANSI...
terminal protocol has stayed arround. If you are going to shoot for the
next big thing beyond X, then you probably want to consider many issues
other than just what hardware set or API to work with. You should be thinking
about things like:
What kind of physics to you want objects to have in your "space"
Multiple disjoint spaces
Collaborative spaces
Variably connected spaces
Subspace management techniques
Hierarchical visualizations/rendering
I think a good starting point would be to completly seperate the user interface
logic from application objects. Then provide a default user interface pattern for
an end user. This would be customized to the users environment when the app
object is first imported into the users space. Older "flat" window apps could
be supported by simply hanging them on one of your virtual walls, or projecting
them onto some other object in your virtual work/play space.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Fri, 02 Jul 1999 21:08:03 +1200
In article <7lhcpa$[EMAIL PROTECTED]>, o r c @ p e l l . p o r
t l a n d . o r . u s (david parsons) wrote:
> In article <[EMAIL PROTECTED]>,
> Bruce Hoult <[EMAIL PROTECTED]> wrote:
>
> >Dylan is not several hundred percent slower than C as Java is.
>
> Have you benchmarked Java vs C on the same machine? (No, I don't
> mean benchmarking C on a machine vs Java running on a p-machine
> on that machine);
No, I haven't. Although I have a number of implementations of Java (from
Netscape, Microsoft, Apple, Metrowerks, Sun and blackdown -- if I haven't
missed any), I don't yet have any direct-to-machinecode implementations.
Has anyone? 99.99% of the Java out there is interpreted or on-the-fly
compiled and is much slower than C/C++/Pascal/Dylan/FORTRAN, so that's
what I'm comparing against.
> there's certainly nothing in the design of
> Java that would make it much slower than C on the same machine.
No, that's not true. There are features in Java which are fundamentally slow.
> Dylan is Yet Another Pascal, isn't it? It looks like the bastard
> child of a shotgun marriage between Ada and Pascal.
Perhaps you're thinking of Modula-2 or Oberon?
-- Bruce
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: WHAT ARE THESE TERMS SUPPOSE TO MEAN
Date: Fri, 2 Jul 1999 10:23:13 +0200
On 1 Jul 1999, Mike Castle wrote:
> In article <7lf6ru$sad$[EMAIL PROTECTED]>,
> Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
> > Now that jiffies wraparound has hopefully been nailed, it's much
> > safer to re-#define HZ. ALTHOUGH I bet there are still lingering
> > bugs with drivers that say `foo' while meaning `(foo*100)/HZ' or
> > `(foo*HZ)/100'.
> > (Some Alpha owners are understandably a little touchy about this
> > sort of discrimination....)
>
> And even then, they probably shouldn't be using HZ should thaey? But
> rather a function call?
>
> 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.
That'll teach those hardware guys that binary only drivers are bad,
immoral (;-)) and a general pain in the a*s.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: [EMAIL PROTECTED] (Juergen Koslowski)
Subject: update_vm_cache in 2.3.9
Date: 2 Jul 1999 08:58:27 GMT
Hi there,
In version 2.3.9 the file linux/fs/fat/file.c still contains a reference
to "update_vm_cache", which seems to have been eliminated from all
other places and consequently leads to compilation failure.
-- J"urgen
--
J"urgen Koslowski | If I don't see you no more in this world
| I meet you in the next world
[EMAIL PROTECTED] | and don't be late!
[EMAIL PROTECTED] | Jimi Hendrix (Voodoo Child)
------------------------------
From: o r c @ p e l l . p o r t l a n d . o r . u s (david parsons)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 1 Jul 1999 20:47:54 -0700
In article <[EMAIL PROTECTED]>,
Bruce Hoult <[EMAIL PROTECTED]> wrote:
>Dylan is not several hundred percent slower than C as Java is.
Have you benchmarked Java vs C on the same machine? (No, I don't
mean benchmarking C on a machine vs Java running on a p-machine
on that machine); there's certainly nothing in the design of
Java that would make it much slower than C on the same machine.
Dylan is Yet Another Pascal, isn't it? It looks like the bastard
child of a shotgun marriage between Ada and Pascal.
____
david parsons \bi/ not that there's anything wrong with pascal that
\/ a few well-placed #defines can't deal with.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 2 Jul 1999 05:23:57 -0400
In article <[EMAIL PROTECTED]>,
Stephan Houben <[EMAIL PROTECTED]> wrote:
>No, not every C++ program is compiled to a finite amount of assembly.
>Take the following counter-example:
>----------------begin code------------------
>template <class A>
>void call_me(A a, int i)
>{
> if (i > 0)
> call_me(&a, i - 1);
>}
>
>int main(void)
>{
> int a;
>
> call_me(a, 10);
> return 0;
>}
>-----------------end code------------------
>
>This produces the following error message (with gcc):
>test.cc:5: virtual memory exhausted
>
>I guess that an infinite amount of processing time and
>memory space would be sufficient to compile this program
Nope. You are wrong here. The right question being: what set of types it
might be applied to? And that problem is *not* TC. Especially with the poor
polymorphism provided by templates. In that case:
TYPES( main ) = \{map(int,void)\}
TYPES( call_me ) \subset map(pair(_,int),void)
map(pair(int,int),void) \in TYPES( call_me )
map(pair(x,int),void) \in TYPES(call_me) =>
map(pair(x,int),void) \in TYPES(call_me)
Minimal solution:
TYPES(main) = \{map(int,void)\},
TYPES(call_me) = \{map(pair(int,int),void)\}
In this case functions are not polymorphic at all. Even if they were you
wouldn't have to compile an infinite amount of variants.
Notice that you don't need to know the full set of potential types -
natural polymorphism of operations restricts the depth. Now, one *can*
make a TC type system. But not with the piss-poor set provided by
C++ templates. They are insufficiently expressive for real work, let
alone for being TC.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Mads Dydensborg <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 02 Jul 1999 10:52:21 +0200
Stephan Houben <[EMAIL PROTECTED]> writes:
> No, not every C++ program is compiled to a finite amount of assembly.
> Take the following counter-example:
> ----------------begin code------------------
> template <class A>
> void call_me(A a, int i)
> {
> if (i > 0)
> call_me(&a, i - 1);
Isn't the & an error? I mean, it is legal, and should not matter, but
it makes no sense.
Perhaps this is what you are trying to say?
Mads
--
+----------------------------------------------------------------------+
| Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. |
| Email: [EMAIL PROTECTED] www: http://www.diku.dk/students/madsdyd/ |
+----------------------------------------------------------------------+
------------------------------
From: Florian Erhard <[EMAIL PROTECTED]>
Subject: Re: A New File System Install
Date: 2 Jul 1999 09:46:46 GMT
Ilhoon,Shin <[EMAIL PROTECTED]> wrote:
: So, we must know how to install the developed file system into linux.
: For example, if we have the developed source files and object files, then,
: what should we do next?
I did such a thing by compiling it as kernel module and then
using insmod. Works fine. Module writing is described in
"Linux device drivers" by A. Rubini.
I think this method is "cleaner" than a kernel patch.
Florian
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 1 Jul 1999 12:43:51 -0700
Algis Rudys <[EMAIL PROTECTED]> wrote:
>Nathan Myers wrote:
>>
>> Many people are either unwilling or unable to assume the burden of
>> rigorous engineering. In fact, they are overwhelmingly in the
>> majority.
>>
>> For easy problems, any language will do. For problems where the
>> answer doesn't matter much, almost any language will do.
>>
>> Still, rigorous engineering is needed in many places, and languages
>> that support it are needed in those places. C++ is currently the
>> most powerful of such languages.
>
>I'm wondering what you mean by "rigorous engineering".
We have engineering colleges at all major universities.
The discipline of engineering has an honorable heritage and
tradition, and differs radically from that of science.
>I ask because,
>although this term sounds important, still I've never seen anything done
>in C++ that could not be done in any other programming language I'm
>familiar with. There is something called Turing completeness, and any
>language that possesses this property is no more or less powerful than
>any other. C++ is Turing complete. So are C, Pascal, Perl, Postscript
>(IIRC), Python, Scheme, LISP, ML, Java, .....
Turing completeness is a matter of science, not engineering.
Postscript code would theoretically be sufficient to operate an
Airbus, but I wouldn't want to fly in one.
>It strikes me that typing is a matter of preference. Some people prefer
>the typing provided by C and C++. Others prefer languages such as Perl,
>Python, or Scheme, which are untyped.
(They are not untyped, they are dynamically typed.)
Again, anything is a matter of preference when the consequences
don't matter.
>Another issue that (I don't believe) has been addressed in this thread
>is safety (ie memory protection, type safety for typed languages, among
>other things). Nothing prevents me from casting a char * as struct foo *
>in C++ or vice versa. While the compiler may issue a warning, it is
>legal syntactically and semantically in C++. And this could mean bad
>things, depending on the case.
>
>This would not be allowed in a safe languages.
If you ignore compiler warnings, how can you be helped?
Sound engineering shops have coding standards for C++,
so that casts must be approved by senior engineers. Casts in
C++ are needed far less often than in C. When they are needed,
nothing else will do. Languages that don't allow casts at all
impede engineering as much as those which toss them in freely.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: o r c @ p e l l . p o r t l a n d . o r . u s (david parsons)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 1 Jul 1999 21:19:21 -0700
In article <[EMAIL PROTECTED]>, Michael Gu <[EMAIL PROTECTED]> wrote:
>From: Junyang Gu <[EMAIL PROTECTED]>
>
>Let's face it. X Windows is a really premitive base for modern GUI,
>terrible font support breaks GUI all the time, no sound capability, ....
>If Linux is going to desktops to compete with Microsoft, it got to come
>up with something much better then X.
>
>So, why don't we drop the X and innovate?
"Write it and let us know when it's ready for testing"
____
david parsons \bi/ A lot of the cruddiness in X comes from the
\/ implementation. Fix that and it will get better.
------------------------------
From: o r c @ p e l l . p o r t l a n d . o r . u s (david parsons)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 1 Jul 1999 21:11:32 -0700
In article <7l51a5$801$[EMAIL PROTECTED]>,
Nathan Myers <[EMAIL PROTECTED]> wrote:
>Paul Jackson <[EMAIL PROTECTED]> wrote:
>>Nathan Myers wrote:
>>|> [Those saying] it's slower than (e.g.) C are just spreading FUD.
>>
>>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.
>
>Odd choice of example; Python is written in C++.
So what?
It wouldn't matter even if python was written in fortran-4 or
COBOL.
____
david parsons \bi/ Sheesh.
\/
------------------------------
From: "Anders �stling" <[EMAIL PROTECTED]>
Subject: Re: Install Mandrake 6.0 on laptop (compaq armada 6500)
Date: Fri, 2 Jul 1999 12:44:32 +0200
Check this page. It describes the DELL Inspirion with ATI RAGE PRO LT. Works
great
for me using the xserver and lilo params specified there (using the FB
driver)
http://www.eecs.umich.edu/~steveh/inspirion/
/Anders
Diggy wrote in message <01bebc61$745aa620$[EMAIL PROTECTED]>...
> Now, I install Mandrake 6.0 on Laptop (Compaq Armada 6500). But I can't
>set XWindows because I can't set video driver. If you know, how to set
>video driver and monitor please help me.
>
> thanz.
> Diggy
------------------------------
** 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
******************************
