Linux-Development-Sys Digest #358, Volume #6 Mon, 1 Feb 99 01:13:55 EST
Contents:
Re: New free widget library: Notif-0.1 (Joseph H Allen)
Re: Can't umount /usr: device busy (Thomas Zajic)
Framebuffers & Mutli-heading? (Christopher Patrick Gill)
Kernel is too big (Chiyu Wang)
Re: Kernel 2.2.1, SMP, and rvplayer ("Paul Schmidt")
Re: disheartened gnome developer (Marco Anglesio)
Re: Starcraft on Linux (Roy Stogner)
Re: Kernel is too big (Dan Wilder)
Re: Sockets (Warren Young)
Re: Linux Phase 2: A Consumer Operating System (Paul D. Smith)
Re: Kernel is too big (Andreas Heiss)
----------------------------------------------------------------------------
Crossposted-To:
comp.windows.x,comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: New free widget library: Notif-0.1
Date: Mon, 1 Feb 1999 02:23:22 GMT
In article <[EMAIL PROTECTED]>,
Emile van Bergen <[EMAIL PROTECTED]> wrote:
>Could you (or someone else), please explain to me, for once and for all,
>WHY almost all GUI toolkits use this *#$%@ callback model with the main
>loop in the user interface?? I have the following objections to such a
>model:
Wow! Rarely have I seen anybody question this.
I think your critique is going off in two directions, so I'll answer them
both:
>2. It encourages interface-centric design; in that you need a fixed
>framework for your application for the GUI to function. for simple dialogs
>and for complex things something like:
>for(;;) {
> pendingevents=gui_select(eventlist,timeout);
> event=gui_getevent();
>
> if (event.event==EV_BUTTON_PUSH && event.object=mybutton)
> {
> dosomething();
> }
>}
>etc.
>This leaves the user of the toolkit in full control of things. He/she
>can create some own callback scheme if he wishes, but anyway, the _user_
>decides!
The first answer is this: In any real system you don't have any choice. You
are going to make a callback scheme anyway, so I might as well provide it.
The best conventional answer is to have your objects contain the variables
(you definitely don't want global variables).
I provide a callback scheme where the installer of the callback function can
set up zero or more args (for the object pointer), and the caller can add
aditional args (for the response from the dialogue window or whatever).
GTK++ basically provides the same mechanism (in a type-safe manner! with the
most amazingly obscure C++ template code I have ever seen).
I go a little further than other systems and provide an entire call-back
wrapper for select() at a lower level. You can set up a callback on any fd
for reads and writes.
And now the second answer: this is the standard method, but I actually agree
with you that it _completely_sucks_. By using an event driven model, you
basically give up all code structuring that the native language provides.
If you ever need to wait for the UI, you can't have sub-functions, loops,
scoping or anything. Instead you can not use these features and you always
have to stick any data for the thread of execution in the object and wait
for the response event. Yuck.
I agree that what you really want to be able to do is this:
>I'd go more for something like calling
>answer=requestyesno("Title","Question",MYFLAGS);
But not just for simple things; you want it for everything. The problem is
that in a single-stack environment, this forces you to give up anything
happening in the background until 'requestyesno' returns. The only system
that I've seen which ignores this problem, is gnu-emacs. You'll notice that
in X-versions of gnu-emacs, there are weird restrictions on command lines.
Whenever you invoke a command A, but don't complete the sequence of
dialogues for it and instead invoke a command B, you then can not go back to
and finish command A until B is done (because B is sitting at the top of the
stack, not A). It tries to hide this by clearing command A when you start
command B by default (but you can turn this off).
Gnu-emacs mostly works in a GUI invironment, because things like Expose
events all operate on the top of stack and then go away. You can't do this
for user threads though, so you get the odd problems with command lines.
My editor JOE is completely OO in this reguard. You can have multiple
outstanding unfinished user dialogues. But I had to do the messy OO event
driven method to pull it off.
There are several solutions to this problem. Some I like; some I don't:
- Multiple operating system threads. Each call to a function like
'requestyesno' allows new threads to be created by other buttons in your
GUI. There are two problems with this method: 1. the operating system needs
to support threads. Now this is the case for Linux, so perhaps it's ok,
since that's what I really care about. 2. the real problem: it will be
inevitable that all of your debugging time will be going in to adding the
appropriate mutexes to prevent shared memory conflicts between between the
threads.
- Multiple user space threads. Stack switching would only be allowed at
places like 'requestyesno'; not at arbitrary times. This eliminates most of
the mutexes. This is probably what we should be doing now. I personally
have never tried any of the user-space thread packages out there, which is
really my only excuse for not doing this in Notif :-) Also, stack switching
is probably not completely portable (but maybe it is with 'longjmp', I
haven't thought about it enough probably- I know that the ham radio
networking package KA9Q implements a multi-tasking operating system in user
space with 'longjmp' tricks).
- Put each thread in a process: this is basically what you are doing when
you put the "real" progrem in a sub-process. There is no reason why each
thread of user dialogs could have a separate process. The main problem with
this method is the loss of easy communication between the threads.
I use this method in Joe for multiplexing between keyboard and background
process input on machines like Xenix which do not have select(). Joe reads
packets from one fd, and there are two processes: one which passes keyboard
input to the fd and another which passes babckground process input. This
method depends on pipes not breaking up small packets (which I have
generally found to be the case).
- A new language (this is the solution RMS is working on as well, I gather).
This is the solution which I have actually been working on. The idea is to
create a language which no longer uses stacks for local variables. This is
basically what is done in the lisp-like language Scheme with its
'continuation' feature: you can place the current environment in a variable
and call another variable containing another packaged-up environemnt to
switch threads. I can't stand lisp-like languages though, so I have been
writing a C-like language which has continuations. This new language would
also have lambda functions (which is a far cleaner way acheiving what the
GTK++ callback template thing does), some object oriented features, allow
function argument lists to be manipulated more fully (so that 'printf' is
not such a special function), not require include files at all, and also has
garbage collection. My current idea is to make this language a preprocessor
for C (like C++ originally was). It would detect function call hierarchies
which do not use the continuation feature (I.E., which are not
multi-threaded) and translate these almost into normal C. Where threads
were necessary, the translator would generate all of the messy event-driven
C code for you.
Now as much as I would love to use PseudoCode (my name for the language) for
the widget library, it is not yet done! In the mean time, I needed a widget
library (and this was before gdk was released), so I created Notif. The
long term goal is to eventually rewrite all of my code in PseudoCode
(particularly the long awaited next version of JOE). But it's just not
ready yet. I released Notif now because I was recently inspired to write
documentation for it (it hasn't actually changed much for a about a year,
although it does need more work).
You can look at the tentative syntax for PseudoCode if you want:
ftp://virek.vwis.com/pub/jhallen/pc.tar.Z
So the question is what should I do now? Devote all effort to PseudoCode or
fix Notif to use a user-space thread library? Continue with event-driven
notif, and complete the set of widgets it suppies? I'm less than enthused
than I once was by the last since GDK now exists.
--
/* [EMAIL PROTECTED] (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
------------------------------
From: Thomas Zajic <[EMAIL PROTECTED]>
Subject: Re: Can't umount /usr: device busy
Date: Mon, 01 Feb 1999 02:42:39 GMT
Markus Schutz wrote:
> Hi folks,
> I've upgraded my Linux box to:
> Linux-2.2.0
> glibc-2.0.7pre6
> I wanted to try something new: drop all libs in /usr/lib. Yes, even
> libc.so and ld-linux.so
Which was probably not a good idea - they should go into /lib,
which in turn should be on the root partition. Remember, the
system needs to do some stuff already _before_ mounting all
other (ie. non-root) partitions. Therefore, everything needed
to startup the system (init, mount, ...) needs to be on the
root partition (think about it, itīs a Catch-22: imagine that
youīd want to mount /usr on startup, and your īmountī binary
is in /usr/bin/mount ... same principle ;-)
> The system start works good. I can run the box.
Lucky guy! Seems like all the binaries needed for startup are
statically linked on your system ... guess what would have
happened if they werenīt?! Hint: Catch-22. Letīs assume all
your startup binaries are statically linked, except īmountī.
īmountī is dynamically linked, so it obviously needs libc.so
and ld-linux.so (plus maybe a couple of others) to operate.
Well, but to access libc.so and ld-linux.so, which you moved
into /usr/lib (with best intentions), /usr first needs to be
... exactly, it needs to be _mounted_! This is done with īmountī.
Restart at the beginning of this paragraph. Got it? ;-)
> But when I try to
> shutdown I get the "Can't umount /usr, device is busy". I've tried to
> check if there are unkilled processes with a 'ps' in the shutdown
> script, but there seem nothing left from /usr running. The only thing I
> suspect still running is ld-linux.so, or some library part that is still
> maped.
Thatīd be my guess, too - some binary needed for the system
shutdown is probably dynamically linked.
> Does anyone know a solution to that. It's a bit annoying to have a
> systematic fschk on /usr on system startup. Perhaps there is something
> more to do than 'killall5 -15; killall5 -9' in the shutdown script, but
> I can't figure out what is missing. There is the call to 'sync' before
> the 'killall5'.
Solution: move your libc.so and ld-linux.so (plus whatever else
youīve moved out of /lib) back to /lib, and better do it quick
before you lock yourself out!
Iīd suggest to have a look at FHS-2.0 sometime, itīs available at
http://www.pathname.com/fhs/
ftp://ftp.pathname.com/pub/fhs-2.0.tar.gz
Thomas
--
=---------------------------------------------------------------------=
- Thomas Zajic aka ZlatkO ThE GoDFatheR, Vienna/Austria -
- Spam-proof e-mail: thomas(DOT)zajic(AT)teleweb(DOT)at -
=---------------------------------------------------------------------=
------------------------------
From: [EMAIL PROTECTED] (Christopher Patrick Gill)
Subject: Framebuffers & Mutli-heading?
Date: 1 Feb 1999 03:30:53 GMT
I've read that it's possible to natively multi-head a system for the
console using Framebuffers. I'm currently running a stable 2.2.1 kernel
with framebuffers compiled in. My hardware is two Matrox Millenium II's. I
compiled in the Matrox drivers and multiheading support, but I haven't
been able to find information on how to actually set it up to USE the
second monitor. (it runs under X since I use Metro).
On a side note, I've also lost audio support. I keep getting Cannot open
device errors. It's a Soundblaster AWE64. Anybody know what's up? If I
get/can find a new verison of MAKEDEV and run that, will it work? (wher
eis it?)
--
=======< Chris Gill >=======< "Who are YOU? What do YOU want?" >=========
=====< [EMAIL PROTECTED] >===< John Sheridan, "Into the Fire", Babylon 5 >===
=====< ICQ #21480619 >===================================================
=========< Rensselaer Polytechnic Institute, Troy New York >=============
------------------------------
From: Chiyu Wang <[EMAIL PROTECTED]>
Subject: Kernel is too big
Date: Sun, 31 Jan 1999 19:17:51 -0800
Hello,
I am trying to install Cyclades-Z drivers into 2.0.36 kernel. After
"make dep ; make clean" and "make zlilo", I copy:
/usr/src/linux-2.0.36/vmlinux* (657022 Jan 31 01:31)
to:
/boot/vmlinuz-2.0.36-0.7.new
and made it as a boot kernel image in /etc/lilo.conf. The current boot
image is still kept at:
/boot/vmlinuz-2.0.36-0.7 (454325 Jul 17 01:07)
However, after running /sbin/lilo, a message shows on the screen
Kernel /boot/vmlinuz-2.0.36-0.7.new is too big
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Obviously, I can not use the new kernel image. The current image can
boot well. Since I already configured all necessary components as
modules, as long as they could. Can anyone tell what else I can do to
make the kernel small enough?
Thanks,
Chiyu
------------------------------
From: "Paul Schmidt" <P$[EMAIL PROTECTED]>
Subject: Re: Kernel 2.2.1, SMP, and rvplayer
Date: 01 Feb 1999 00:34:52 GMT
David Fox ([EMAIL PROTECTED]) wrote:
: I built a 2.2.1 SMP kernel with the APIC interrupt patch posted to the
: kernel mailing list, and installed it on a dual PII/400 machine, and
: so far the problem I'm still having is after (that piece of s***)
: rvplayer runs for about fifteen seconds it gets "A general error
: occurred" (not even a number!) and stops. I've tried kernels with and
: without APM enabled. Sound players like mpg123 work fine. I would
: send this to the kernel list if it weren't so vague and stupid.
: --
: David Fox http://hci.ucsd.edu/dsf xoF divaD
: UCSD HCI Lab baL ICH DSCU
rvplayer needs to be patched, since it opens the device with a
nonblocking flag. What version of rvplayer are you running?
Mine is 5.0.0.45, patched per a fix posted to the linux-kernel mailing
list:
dd if=/dev/zero of=rvplayer bs=1 count=1 conv=notrunc seek=702554
Other versions will require the patch to a different location.
This is documented in linux/Documentation/Changes. Look for rvplayer.
The Midi plugin ump.so requires a similar patch. I have version
1.10 for Linux 1.2/2.0 with libc5 (my system is still hybrid libc5/libc6)
and patched it with:
dd if=/dev/zero of=ump.so bs=1 count=1 conv=notrunc seek=93900
-ps
--
Paul Schmidt < >< Linux 2.2.1 PSchmidt at Custom dot Net
Tired of hearing about Y2K? Look into K2K: http://www.keyes2000.org
Sig line continued at http://viaduct.custom.net/pschmidt/opinion.htm
------------------------------
From: [EMAIL PROTECTED] (Marco Anglesio)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Mon, 01 Feb 1999 04:47:45 GMT
On Sun, 31 Jan 1999 16:35:07 -0500, jerryn <[EMAIL PROTECTED]> wrote:
>Open Software and freeing source code isn't socialism.
Isn't socialist. It's neither socialist nor capitalist; it just is.
>I still believe companies like Redhat are causing division
>in the Linux Community, namely because they are earning
>profits from the blood and sweat of all of us developers.
On the contrary, I don't think that they are. Red Hat's right to exist has
never been challenged, even though specific policy and techniacl decisions
(the bug-ridden release of RH5.0, for example) have been challenged and
the position of Red Hat as the de facto vendor has been challenged, but
Red Hat's legitimacy as a vendor has never been an issue (except for the
ubiquitous Red Hat <> Linux comments directed at newbies, but that's
hardly a challenge). Not to the best of my recollection, at least.
I'd like to know where you're getting this impression from.
marco
--
Marco Anglesio The press isn't cynical enough. They're the only Americans
[EMAIL PROTECTED] capable of this kind of embarrassing, greenhorn
http://www.the-wire.com/~mpa civic wonder anymore. (James Poniewozik)
------------------------------
From: [EMAIL PROTECTED] (Roy Stogner)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Starcraft on Linux
Date: 1 Feb 1999 03:57:10 GMT
On Sun, 31 Jan 1999 16:06:59 +1000, Steven Shaw wrote:
>Does Starcraft really run under Linux? Are you using wine?
Like the previous poster said, Starcraft < 1.04 worked; v1.04 and
Brood War don't yet. (and Wine 990131 doesn't seem to fix it yet).
There were memory leaks somewhere, though, and it paid off to have
another virtual terminal keeping an eye on this while you saved every
half hour or hour.
---
Roy Stogner
------------------------------
From: [EMAIL PROTECTED] (Dan Wilder)
Subject: Re: Kernel is too big
Date: 1 Feb 1999 05:00:15 GMT
Chiyu Wang <[EMAIL PROTECTED]> writes:
[ ... ]
>However, after running /sbin/lilo, a message shows on the screen
>Kernel /boot/vmlinuz-2.0.36-0.7.new is too big
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Obviously, I can not use the new kernel image. The current image can
>boot well. Since I already configured all necessary components as
>modules, as long as they could. Can anyone tell what else I can do to
>make the kernel small enough?
Take a look at /usr/src/linux/README:
- if your kernel is too large for "make zImage", use "make bzImage"
instead.
There might even be a "make bzlilo" target ...
--
Dan Wilder
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: Sockets
Date: Sun, 31 Jan 1999 21:57:27 -0700
Robert Norman wrote:
>
> I'm writing a Java Client/Server program. The server resides on a Linux
> box and allows clients to connect to it. Each client connects using a
> socket.
>
> The problem is that Linux seems to be limiting us to 240 socket
> conenctions. Is there a way around this?
I'd be surprised if it's Linux imposing this limit. It's probably your
Java implementation.
If it's Linux, there are a number of kernel parameters and ulimit
settings you can play with, but I'd first check out the JVM part.
Good luck,
--
= Warren -- http://www.cyberport.com/~tangent/
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
= NO CARRIER...but I've still got my battleship!
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Linux Phase 2: A Consumer Operating System
Date: 01 Feb 1999 00:03:37 -0500
Reply-To: [EMAIL PROTECTED]
Thanks for the pointer, I'll check out apt.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: Andreas Heiss <[EMAIL PROTECTED]>
Subject: Re: Kernel is too big
Date: 1 Feb 1999 05:49:53 GMT
Chiyu Wang <[EMAIL PROTECTED]> wrote:
> Hello,
> I am trying to install Cyclades-Z drivers into 2.0.36 kernel. After
> "make dep ; make clean" and "make zlilo", I copy:
> /usr/src/linux-2.0.36/vmlinux* (657022 Jan 31 01:31)
> to:
> /boot/vmlinuz-2.0.36-0.7.ne
This is the uncompressed kernel. You have to copy
/usr/src/linux-2.0.36/arch/i386/boot/zImage to /boot or /
Andreas
--
------------------------------
** 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
******************************
