Linux-Development-Sys Digest #883, Volume #6 Fri, 25 Jun 99 10:14:05 EDT
Contents:
Re: TAO: the ultimate OS (Paolo Torelli)
Re: compiling for a Hitachi SH-3 CPU with gcc ("Makoto Hasegawa")
engineers needed for gcc cross-compiler project ("Erik Petersen")
double unlock on device queue! (Thomas)
Parameters in kernel 2.2.x modules (Manuel Santos)
Re: TAPOs: configurations (Paolo Torelli)
Re: NT kernel guy playing with Linux (John Hughes)
Re: Why not C++ (Bruce Hoult)
Re: Why we are still holding on to X Windows (mlw)
Did anybody compile Glade in Solaris? (Guillermo)
----------------------------------------------------------------------------
From: Paolo Torelli <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 25 Jun 1999 12:33:55 +0200
Reply-To: [EMAIL PROTECTED]
Terry Murphy wrote:
> does not at all follow the form of ESR's software development model.
Sorry about my question, but what is ESR? (I'm not used to US abbreviations)
> whip out VI and start hacking. Microsoft's development system amazes me
> in how fast they are able to turn out high quality and well tested products.
If you had such number of employed working all the time on the project, you'd
not say that. Probably you'd say they're slow because they want to be sure to
sell more copies before a new version is sold, and of course the new version
has the "bit more" that makes many users upgrade (not that they'll ever use
the feature, but at least for compatibility with the lame user which bought
the copy)
Some numbers? NT has around 250 people working on it...
--
[=-----------------------Technolord-the-Hellraiser----------------------=]
]All tied up and dried up forever all fucked up and dead to the world[
------------------------------
From: "Makoto Hasegawa" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.questions
Subject: Re: compiling for a Hitachi SH-3 CPU with gcc
Date: Fri, 25 Jun 1999 20:15:11 +0900
Hi.
Peter Gutmann <[EMAIL PROTECTED]> wrote in message
news:7kb9uo$eff$[EMAIL PROTECTED]...
> I'm actually looking for the libraries (or modules; whatever needed) to
> compile programs for a Hitachi SH-3 CPU with gcc running on i386 linux.
>
> Thanks, Peter Gutmann
>
>
I found SH-3 cross compiler on DOS/Windows,but I don't know Linux version.
http://www.objsw.com/
Makoto Hasegawa
------------------------------
From: "Erik Petersen" <[EMAIL PROTECTED]>
Crossposted-To:
gnu.gcc,alt.jobs,ca.jobs,comp.os.linux.development,comp.lang.c,comp.os.linux.m68k,comp.os.linux.powerpc
Subject: engineers needed for gcc cross-compiler project
Date: Fri, 25 Jun 1999 08:38:14 GMT
We are currently seeking one and possibly more software engineers to
participate in our effort to develop a GCC cross-compiler for use with our
PSC1000 microprocessor. We currently use a C compiler toolset from Sierra
Systems that has been extensively modified and enhanced to accommodate the
unique stack-based architecture of our microprocessor. This would be a
contract position with the possibility of becoming permanent. The right
candidate would work with an exceptionally talented team of engineers. The
results of this effort will be returned to the free software community for
eventual (we hope) integration with the official GCC distribution.
To qualify for this position you should have experience developing GCC
cross-compilers for various processor architectures and strong
microprocessor architecture skills. A minimum of 4 years compiler
development work experience is preferable, actual GCC cross-compiler
development experience is ideal.
Patriot Scientific Corp. offers very competitive compensation packages and
flexible work arrangements. If you feel yourself qualified and interested in
this challenging opportunity, please email your resume to [EMAIL PROTECTED] or
fax it in confidence to (619) 674-5005 attn.: Erik Petersen.
You can learn more about Patriot Scientific and the PSC1000 microprocessor
from our web page http://www.ptsc.com.
--
Erik Petersen
Director of Engineering, Systems Design
Patriot Scientific Corp.
[EMAIL PROTECTED]
------------------------------
From: Thomas <[EMAIL PROTECTED]>
Subject: double unlock on device queue!
Date: Fri, 25 Jun 1999 12:55:45 +0200
Hi everyone,
I wrote my own network-driver and a client-server program which sends a
data buffer
from client to server and then back from server to client.
For bigger buffer sizes (from 9kB) sometimes the computer hangs with the
message:
"kernel: double unlock on device queue!"
Does anyone out there has an idea where I should start to fix my
driver?
Hope someone can help
Thanks
Tom
------------------------------
From: Manuel Santos <[EMAIL PROTECTED]>
Subject: Parameters in kernel 2.2.x modules
Date: Fri, 25 Jun 1999 12:49:43 +0200
I'm porting my own device driver module for the data adquisition card
ACL-8112 from kernel 2.0 to 2.2. I want to pass parameters to the module
in load time, but I've heard that this has changed in the new kernels.
Can anyone tell me how can I do it?
Manuel Santos.
------------------------------
From: Paolo Torelli <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAPOs: configurations
Date: Fri, 25 Jun 1999 12:44:17 +0200
Reply-To: [EMAIL PROTECTED]
Alexander Viro wrote:
> >> I assure you the OS of the future is not going to have text based
> >> configuration files .. at least at the core. I think there is always
> >Indeed. text files are by all means larger and harder to mantain.
> So you never did any kind of sysadmin job, right?
Where's the logical connection?
And false, I actually *DID* some sysadmin job. not *x, tho.
--
[=-----------------------Technolord-the-Hellraiser----------------------=]
]All tied up and dried up forever all fucked up and dead to the world[
------------------------------
From: John Hughes <[EMAIL PROTECTED]>
Subject: Re: NT kernel guy playing with Linux
Date: 25 Jun 1999 12:49:41 +0200
[EMAIL PROTECTED] (Philipp Thomas) writes:
> On Wed, 23 Jun 1999 18:18:15 +0200, Mario Klebsch
> <[EMAIL PROTECTED]> wrote:
>
> >Unfortunately, they never were popular (probably because of their
> >origin at AT&T), so Linux did not reinvent this wheel.
>
> It's not because STREAMS originated at AT&T, but because of
> performance. As anybody who has worked with streams will tell you,
> they suck performance wise. Specially the streams based TCP/IP stacks.
Nope. Untrue. FUD.
--
John Hughes <[EMAIL PROTECTED]>,
Atlantic Technologies Inc. Tel: +33-1-4313-3131
66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139
75013 PARIS.
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Fri, 25 Jun 1999 23:54:41 +1200
In article <[EMAIL PROTECTED]>, "Thomas Steffen"
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Bruce Hoult) writes:
>
> > You might want to check out Dylan. It's much simpler and easier to learn
> > than C++, and yet is more powerful than C++ -- for example Dylan supports
> > dynamic dispatch on more than just one argument of a function, plus Dylan
> > has things such as lexically scoped local functions, anonymous functions,
> > and closures,
>
> though i'm not sure it supports closures the way i would like g++ to
> do...
How is that? See an example of closures in Dylan at the end...
> anyway, Dylan looks like a very potent language. however, until
> a safe compiler base is available (which means gcc basically), i am
> unlikely to switch.
The Dylan I'm using (and helping to improve) -- Gwydion Dylan, aka "d2c"
-- produces C code which is then compiled using gcc. That has several
benefits: portability, known quality of code generation, ability to
inspect intermediate C code to verify/understand it (and it's actually
pretty readable -- d2c pretty-prints it and bases the C names on the
original Dylan variables, so it's a bit easier to understand than the
output of Stroustrup's "cfront" was), and ability to leave certain easy
optomisations (such as inlining) to gcc.
It's possible to call back and forth between Dylan and C code, so existing
OS and other libraries can be used seamlessly from Dylan programs. At the
moment you have to hand-code the interface routines in Dylan (as I've done
below), but we're working on automatically producing the interface
routines from C header files and this works for simple cases (not yet
callback functions) now.
> and C++ seems to be there to stay (as unfortunate
> as it may be for better languages).
C++ is certainly going to be around, and the best language for some
purposes, for many many years to come. It's better than what came before
it. I was an early-adopter of C++ (in 1989), back when it was arguably in
a more rudimentary state than Dylan is today. Much as I saw the potential
of C++ at the time, it was far from a certainty that it would take over
from C as it has.
Stroustrup did a number of things right. I think the most important of
those were link-compatability with C, the philosophy that you don't pay
for advanced features if you don't use them, and compiling to C in the
reference implementation to ensure easy and widespread portability. With
d2c we have the same properties, plus the compiler being "free software"
in the FSF sense. OTOH, Harlequin's Dylan for Windows is free for
personal use, but not "free".
I personally think that d2c is therefore vital to the penetration and
acceptance of Dylan, and Harlequin seem to agree because they are
cooperating with the Gwydion Dylan project and are giving assistance such
as open-sourcing some libraries written by them.
C++ also maintained source code compatability with C, but Java has shown
that the market will accept deviation from this. Dylan's syntax is not as
close to C's as is Java's syntax, but it's not so far away as to be
shocking to anyone who has programmed in the C/Pascal/Algol family.
Unlike, for example, SmallTalk, Lisp or FORTH, each of which can send C
programmers running screaming.
I tend to think that in terms of adoption Dylan today is about at the
stage that C++ was at in 1990 or so. Back then, C++ was nearly a decade
old, but there was basically just CFront. Zortech C++ was out, but
Microsoft, Borland and Symantec probably didn't even have C++ on their
horizons yet -- they certainly hadn't released anything. Dylan is in much
better shape now than C++ was then in as much as the language definition
is far more stable and complete. The implementations aren't 100% there
yet, but the definition is stable. Dylan is also better off with standard
libraries. The Dylan equivilent of the STL was defined alongside the
Dylan language from the start, and integrates with the language much
better.
The other major thing needed is a GUI library. Apple had a pretty nice
one in their Dylan Technology Release in 1995 (and the development
environment was *awesome*), but it was very Mac Toolbox-specific.
Harlequin's DUIM is hopefully more portable, and there are plans to port
it to d2c/Unix.
You asked about closures before. I just happen to have been implementing
code for PowerPC (x86 was already done) that allows closures to be passed
out to C code and used as callbacks. Closures already worked within a
Dylan program, of course (as did non-closure callback functions), but to
pass them to C functions that expect just a simple function pointer we
need to create a machine code thunk/trampoline at runtime and pass the
thunk to the C program.
I'll include one of my test programs below.
-- Bruce
========================= docalc.c ===========================
typedef int (*getIntFunc)(void);
typedef void (*putIntFunc)(int);
void doCalc(int n, getIntFunc a, getIntFunc b, putIntFunc c);
void doCalc(int n, getIntFunc a, getIntFunc b, putIntFunc c)
{
int p = a() * n + b();
c(p);
}
==================== testclosure.dylan =======================
module: testclosure
synopsis: tests passing closures to C as callback functions
author: Bruce Hoult
copyright:
// This method will be automagically generated from the C header file
// once melange/pidgin is done
define method doCalc(n, f1, f2, f3) => ();
call-out(
"doCalc", int:, int: n,
ptr: callback-entry(
callback-method() => (n :: <integer>); f1() end),
ptr: callback-entry(
callback-method() => (n :: <integer>); f2() end),
ptr: callback-entry(
callback-method(newVal :: <integer>) => (); f3(newVal) end)
);
end doCalc;
//////////////////////////////////////////////////////////////////////
// function that makes a closure holding two integers, and returns
// functions to access each integer and to alter one of them
define method makeClosure (x :: <integer>, y :: <integer>)
=> (getX, getY, setX);
values(
method() x end,
method() y end,
method(newX) x := newX end
)
end method makeClosure;
define method main(appname, #rest arguments)
let (i, j, k) = makeClosure(10,5);
let (q, r, s) = makeClosure(7,2);
doCalc(13, i, j, k); // should set i() to 10 * 13 + 5 = 135
doCalc(3, q, r, s); // should set q() to 7 * 3 + 2 = 23
format-out(
"Values of closure variables = %d,%d and %d,%d\n",
i(), j(), q(), r()
);
exit(exit-code: 0);
end method main;
==============================================================
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Fri, 25 Jun 1999 12:08:46 +0000
Mario Klebsch wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
>
> >Michael Gu wrote:
>
> >>If Microsoft is a monopoly, X Windows acts more like a monopoly in the
> >>Unix world.
> >>
> >>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?
>
> >X is at least 5 to 10 years ahead of anything Microsoft has going. They
>
> Well, it is 5 to 10 years ahead and probably over 10 years behind at
> the same time.
Name one thing in which X lags, that is part of what X is intended to
provide. Excluding fonts, because that is being worked on.
>
> >are working like crazy to get terminal server and Citrix to be reliable.
> >We have what they are trying to do already.
>
> This is one aera, where XC is ahead. :-)
>
> >With X, I can run a program anywhere on any machine, Windows can't touch
> >that.
>
> >As for Audio, what the hell does a GUI have to do with audio? Yes, Linux
> >needs a standard networked streaming audio spec, but that is not "X."
>
> It has nothing to do with X, but with the users session. When I have a
> session sitting in front of display xxx, I expect my sound to creap out
> of the speakers standing next to that display, and not entertaining the
> sysop in the computer room. :-)
The user session is managed by the programs that create it. In the case
of a remote connection, that is telnet that sets the DISPLAY environment
variable. It could easily create an AUDIO variable, or a streaming audio
system could use the DISPLAY variable as a hint.
>
> >You may be confusing X with the Window manager. X is conceptually a
> >display driver/interface. The Window manager is more of the GUI
> >component. The way the applications look and the way the system feels,
> >is part of the WIndow manager. The act of drawing primitives and getting
> >mouse and keyboard data is where X is.
>
> And you seem to confuse look&feel with a window manager. Surely, on a
> text window (like xterm), the window manager is the only visable thing,
> so it seems like look. But the feel depends much more on the widget set
> used, but on the window manager.
The Widget set is usually part of the Window manager package. X is the
underlying protocols and server. It merely presents a set of drawing and
screen primitives, nothing more.
>
> >If you want to look at a good Window manager / Desktop system, take a
> >look at KDE.
>
> Well, it is quiet nice, but far from being standard. Let's face it,
> windows really is ahead of X, when it comes to the widgets and more
> important consistency among the applications.
Yes, but that has NOTHING to do with X. X is very consistent. I can run
a program on virtually any UNIX machine with X and display it on
virtually any other UNIX machine with X.
>
> X only includes Xaw, and it can't compete with windows. You can argue
> about Motif, but who the hell does use it? Especially Linux normaly
> does not include Motif.
X is like a video driver. X was explicitly designed NOT to provide a
user interface. That is the responsibility of the Window manager and
widget set.
>
> And when it comes to consitency, the UNIX people alway dream about the
> ability to choose amound hundreds of widget sets (Xaw, Xaw3d, Motif,
> Lesstif, Gtk, Qt, ...), but in reality almos no one can choose. Only
> the author of a program can choose, the user of a program cannot. He
> has to live with the design decision, the autor took. And since each
> author does his own decision, there is not much consistency among
> different applications.
Yes, this is a problem if one wants uniformity everywhere. Not everyone
does. Uniformity is nice and comfortable, peaceful, etc. In life
however, uniformity and comfort come at a great cost.
I good standard API set for data sharing and shell featues would be
handly, but, there is no way I would want every single application lock
step behind every other.
I think current day user interface technology is poor. It is improving
gradually, there are creative people out there that have ideas.
Squashing creativity for the sake of uniformity has always been
considered a bad move.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com
------------------------------
From: Guillermo <[EMAIL PROTECTED]>
Subject: Did anybody compile Glade in Solaris?
Date: Fri, 25 Jun 1999 13:44:20 +0200
I have installed the solaris 2.6 in a Sun sparc. Besides I have
installed the gcc, make, perl5, bash, gzip, tcl, tk,... all packed in
solaris format (very easy)
I have installed the gtk in solaris-pkg format and the examples work
properly.
Now I am trying install Glade but it never compile
It displays this error
make[3]: ar: Command not found
make[3]: *** [libgbwidgets.a] Error 127
make[3]: Leaving directory `/usr/local/glade-0.3.5/glade/gbwidgets'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/glade-0.3.5/glade'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/glade-0.3.5'
make: *** [all-recursive-am] Error 2
i have tried with --with included gtext and --disable-nls so the problem
when i prompt a make is the same
Any help?
Thanks a million
------------------------------
** 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
******************************
