Linux-Development-Sys Digest #359, Volume #6 Mon, 1 Feb 99 06:14:08 EST
Contents:
/dev/rdsk - help (InfoXchange Customer Service)
Re: disheartened gnome developer (Arthur)
Re: Comparison of Swing, Qt, GTk? (Gerald Preissler)
Re: New free widget library: Notif-0.1 (Joseph H Allen)
Re: New free widget library: Notif-0.1 (Martin Gall)
Kernel Panic After 2.2.1 Compilation! (Ki-Won Lee)
ppp modules in 2.2.x - documentation needed (was: ppp-compress-xx problem in
2.2.0-pre4) (Dr. Henrik Seidel)
Re: Why I'm dumping Linux, going back to Windblows (Gordon Scott)
Re: New free widget library: Notif-0.1 (Emile van Bergen)
Re: How to flush the file cache ? (Renaud Lottiaux)
----------------------------------------------------------------------------
From: InfoXchange Customer Service <[EMAIL PROTECTED]>
Subject: /dev/rdsk - help
Date: Thu, 28 Jan 1999 12:15:06 -0500
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
We have created a CPIO disk for Interactive Unix to read into Linux.
<br>The device used was /dev/rdsk/fd0q18dt
<p>fd0H1440 does not read track 0 and not sure if it is a raw device.
<br>Extracts zero files.
<p>anyone have a suggestion as to what device to use?
<p>Thank you for your help.
<br>Wendy</html>
------------------------------
From: Arthur <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Mon, 01 Feb 1999 00:46:14 -0800
Marco Anglesio wrote:
>
> 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.
Thank you - not everything in the world exists
because of or for the benefit of economics.
> >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.
Certainly not from Linus, and the question seems
to be asked in almost every interview.
"All of us developers" usually makes me skeptical
anyway. If you don't like Red Hat and the other
distributors, license the code you develop more
restrictively.
Arthur
------------------------------
From: Gerald Preissler <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.gui
Subject: Re: Comparison of Swing, Qt, GTk?
Date: 31 Jan 1999 14:00:08 +0100
BL <[EMAIL PROTECTED]> writes:
> I'm certainly no java expert - only been playing wiht it real informally, but
> with the current free tools (jdk) on linux and even on my work system (irix),
> I'd have to say that compiles are PAINFULLY slow, as are app STARTUP times!
> so slow that I abandoned doing a gui project in java (swing) and went back to
> good old ANSI C with gtk+. aah - nice comfortable Makefiles, etc ;-)
BL,
if the compile times are a problem for you with Java, you should take
a look at Jikes, IBM´s alternative Java compiler. Since it is
implemented in C++(?), its an order of magnitude faster than javac
(which is implemented in Java itself).
App startup time does not concern me that much (YMMV), but while I
agree that Java is not the environment of choice for number crunching
or 3D action games (yet?), I´d say there are quite some applications
where it is adequate.
cheerio
Jerry
--
||| ... and now for something completely different ...
o o
--m--!--m--
------------------------------
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 08:56:33 GMT
In article <[EMAIL PROTECTED]>,
Joseph H Allen <[EMAIL PROTECTED]> wrote:
>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:
>[discussion about the evils of event-driven code]
Ok, I'm going to update Notif to address this issue. I'm hacking
continuation handling into the callback system. Whenever a callback
function is executed, a new context will be run or an existing context will
be continued. I'm going to avoid the use of the word 'thread', and use
'context' instead, because I don't want to give the impression that any kind
of pre-emptive multithreading is occuring. This is strictly cooperative
multithreading (thread switches only happen during callback execution),
which is probably far safer than real multithreading for most GUI systems).
Here is how it works: When you register a callback with stfn(), you can
pass it either cfn() for the current context, or fn() to have a new context
started with a specified function. The go() function is what actually
saves the context in the context structure (cfn() just passes its address)
and is what the user calls to return to the event loop. If you are writing a
widget and need to continue a context, you call cont() (which never returns)
with the value returned by cfn() or fn(). This would kill the current
context and continue or start the specified one by returning from one of the
go()s or calling one of the callback functions.
Here's some sample code. When you press the button "Press me!", three
"enter a number" dialog boxes appear on the screen, and you have to hit OK
three times to finish the sequence. You can also hit "Press me!" again to
start another parallel thread of dialog boxes. The big difference between
this code and other widget library code is that 'promptforstring()' is in
the middle of a for loop (usually you would have to return to the event
handler to get this effect). You can finish the dialog boxes in any order
since each context has its own stack.
I'll post again when the code is ready (tuesday night I think, it's pretty
easy). Now the only problem with this is going to be the difficulty in
porting to other UNIXs. It will at least require reading of the jmpbuf.h
include file to learn how to modify the stack and base pointers stored in
it.
#include "../notif/notif.h"
/* Ask user for string dialog window. Returns with response */
char *promptforstring(buf,prompt)
char *buf, *prompt;
{
Widget *w;
Text *t;
Edit *e;
char *s;
CONT cont; /* Context variable */
w=mk(Widget); /* Create dialog window */
t=mk(Text); /* The prompt */
st(t,prompt);
add(t,w);
e=mk(Edit); /* Edit widget */
stfn(e,cfn(&cont)); /* Run this context when user hit's return */
add(w,e);
add(root,w); /* Put it on screen */
go(&cont); /* Save context in cont; handle events;
return when 'cont' is continued */
strcpy(buf,gt(e)); /* Get string from edit window */
rm(w); /* Kill dialog window */
return buf; /* Return with string */
}
/* Callback function executed to for each new context */
int threadno;
doit(stat,b)
Button *b;
{
if(!stat) /* Stat is non-zero if the button was rm() before */
{ /* being pressed. */
int x,y;
int z=threadno++; /* Record a thread no. */
stfn(b,fn1(doit,b)); /* New context when pressed */
/* (The button remains disabled until this
is done- move this line to the end of
this function to allow only one context) */
y=1;
/* For loop with dialog boxes. No return to the event loop here! */
for(x=0;x!=3;++x)
{
char prompt[100], buf[100];
sprintf(buf,"Enter number %d (thread %d)",x,z);
y*=atoi(promptforstring(buf,prompt)); /* Prompt the user */
}
/* Message box */
sprintf(buf,"The answer is %d (thread %d)",y,z);
message(buf);
}
return stat;
}
/* Startup */
main()
{
Widget *w;
Button *b;
int x;
int y;
CONT cont; /* Context variable */
izws(); /* Initialize windowing system */
w=mk(Widget); /* Create widget */
b=mk(Button); /* Create "Press me!" button */
sttext(b,"Press me!"); /* Text in button */
stfn(b,fn1(doit,b)); /* New context whenever pressed */
add(w,b); /* Add button to widget */
b=mk(Button); /* Quit button */
sttext(b,"Quit");
stfn(b,cfn(&cont)); /* This context when pressed */
add(w,b);
add(root,w); /* Put it on the screen */
go(&cont); /* Handle events until user hits
quit */
return 0;
}
--
/* [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: Martin Gall <[EMAIL PROTECTED]>
Crossposted-To:
comp.windows.x,comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: New free widget library: Notif-0.1
Date: Mon, 01 Feb 1999 10:10:24 +0000
Emile van Bergen wrote:
>
> Joseph H Allen wrote:
> >
> > I have been working on a new freeware widget library for X/Linux.
> > If you are unsatisfied with Qt, Lesstif, Tk and GTK, try Notif!
> >
> [SNIP]
> >
> > Hello world for notif looks like this:
> >
> > #include <stdio.h>
> > #include "../notif/notif.h"
> >
> > int quit(stat,b) /* Quit callback function */
> > Button *b;
> > {
> > if(!stat)
> > exit(0);
> > return stat;
> > }
> >
> > main()
> > {
> > Button *mainw;
> > izws(); /* Initialize notif */
> >
> > mainw=mk(Button); /* Create a button */
> > sttext(mainw,"Hello, world!"); /* Create a text widget and
> > add it to the button */
> > stfn(mainw,fn1(quit,mainw)); /* Set the callback */
> >
> > add(root,mainw); /* Add to root window */
> >
> > for(;;) ws(), serv(); /* Process events */
> > }
>
> 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:
>
> 1. Where to record state data? If you have two callback functions which
> need the same data to decide their actions upon, you end up with a lot
> of global variables.
>
> 2. It encourages interface-centric design; in that you need a fixed
> framework for your application for the GUI to function. I'd go more for
> something like calling answer=requestyesno("Title","Question",MYFLAGS);
> for simple dialogs and for complex things something like:
>
> ev_set eventlist;
>
> EV_ZERO(eventlist);
> EV_SET(eventlist,EV_BUTTON_PUSH+EV_MOUSE_MOVE);
>
> 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!
>
> 3. If you use OO to solve 1., it forces the developer to derive many of
> his own objects from GUI objects, because of the (method)callbacks. And
> then you have again, an interface-centric application design! Yuck.
>
> 4. What is the fundamental difference between a keyboard full of buttons
> and a window full of buttons? No system that I know of has an
> keyboard-interrupt handler with which you can register a function that
> will be called if key 'A' is pressed, an another function if key 'B' is
> pressed. (The most annoying thing would be if the key in question
> wouldn't be passed as an argument, otherwise you could create just one
> callback for all keys which simply puts the key in a FIFO queue). No,
> this would be regarded brain dead, but its the standard in GUI's. WHY?
>
> 5. This kind of toolkit (like xforms, too), always makes my applications
> occupy two PID's ;-). What I do is create a event-structure after all,
> create a pipe, fork in two, with one process handling the GUI stuff,
> sending events through the pipe to other process, the real application.
> Etc. If X itself is built that way, why on earth would a toolkit defy
> this sane (see keyboard-int handler argument) mechanism and use those
> profoundly ugly callbacks?
>
> If anyone would like to enlighten me on this, please, by all means!
>
> --
>
> 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.
You can also do a mini loop like that:
getstr()
{
/* display the textfield */
while (!ok)
{
XEvent event;
XtAppNextEvent(app_context,&event);
XtDispatchEvent(&event);
}
return (str);
}
All the exposures and nonmaskable events are dispatched to the global
interfaces as usual and you can do a thing like that in your program:
str = getstr();
--
------------------------------
From: [EMAIL PROTECTED] (Ki-Won Lee)
Subject: Kernel Panic After 2.2.1 Compilation!
Date: 1 Feb 1999 09:22:13 GMT
Greetings!
I got just that after compiling 2.2.1. I guess I should've expected as
much. This is the message I get after which it just hangs and I have to
reboot by the 3-finger salute:
Partition check:
request_module[ide-disk]: Root fs not mounted
hdb: driver not present
VFS: Cannot open root device 03:41
Kernel panic: VFS: Unable to mount fs on 03:41
I have 2 HDs in my box, one is hda which has windows on it and hdb of
course has our much beloved Linux. Why is it requesting a module
"[ide-disk]"? And I don't understand why it's saying "hdb: driver not
present". And what's VFS? I never got these errors with 2.0.36, so I'm
not familiar with the terms. I'd really appreciate it if you could throw
me a rope and suggest some solutions to this problem. Thank you very much
in advance.
With Best,
Steve
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Dr. Henrik Seidel)
Subject: ppp modules in 2.2.x - documentation needed (was: ppp-compress-xx problem in
2.2.0-pre4)
Date: 1 Feb 1999 10:13:31 GMT
Hi,
I think there is an urgent need for an update of "Documentation/networking/
ppp.txt". I compiled ppp as a module, and I as well was puzzeled by the
syslog messages mentioned below. There's nothing in the documentation, and
also the source code does not explain how to set up the module aliases.
Regards
--- Henrik
In article <[EMAIL PROTECTED]>,
grinder <[EMAIL PROTECTED]> writes:
> David Ronis wrote:
>>
>> I've been getting the following error(?) reported in my messages file:
>>
>> modprobe: can't locate module ppp-compress-21
>> modprobe: can't locate module ppp-compress-26
>> modprobe: can't locate module ppp-compress-24
>>
> alias ppp-compress-21 bsd_comp
> alias ppp-compress-24 ppp_deflate
> alias ppp-compress-26 slhc
--
Dr. Henrik Seidel, http://www.mpimg-berlin-dahlem.mpg.de/~seidel/
Max Planck Institute for Molecular Genetics
14195 Berlin, GERMANY, Ihnestrasse 73
tel: ++49-30-8413-1613 fax: ++49-30-8413-1384
see my home page for my public PGP key
------------------------------
From: [EMAIL PROTECTED] (Gordon Scott)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: 1 Feb 1999 10:20:58 GMT
Reply-To: Gordon Scott <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
: In article <790kk4$1qg0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
: >
: >In article <78ur7u$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
: >>
: >>>Perhaps we would understand if you gave an example that is somehow
: >>>better than your description???
:
: >Urk.. That's not a man page, that's a full-blown 150 page book!
:
: Besides the point.
I think it's precisely the point.
Man pages are not and IMHO should not be full-blown manuals. They are
supposed to be and should be a quick and concise reference to the tools
(etc.) in question. Yes that *is* a bit hard on newbies. But it would be
a mistake to make man pages bloat out with fine detail so that *everyone*
using them has to wade through lots of explanations that would often
superfluous. I certainly do agree that there are places that examples
would be useful, but many of theose places already have examples --
look at thinks like procmail.
A tutorial or whatever about the the 'essence' of unix, which gets newbies
past the first few hurdles and explains how to use and understand man pages,
etc. would be far more useful.
Complex (however you define that) tools should have a separate full manual
and/or user guide. Most applications that need more than a manpage entry
for them really to be useful, already come with a full manual and/or
books. For examples -- Gimp, LaTeX, Povray -- there are 227 entries in
my /usr/doc directory and some of those are themselves directories.
Now if the man pages just had the hyperlinks to those documents, we'd
have 80% of the 'problems' cracked. Wouldn't we?
The Linux distribution I use has lynx or chimera as the on-line help
tools and goes to a front page that starts by showing you how to use
hyperlinks. It also has all the man pages and howtos available via the
browser, and some of the texinfos, a wais engine. Sadly it *doesn't*
actually have a beginners guide (at least not in my rather mature
copy). It also doesn't have hyperlinks in the man pages, because the
originals don't have them. Not a bad start though.
G.
--
Gordon Scott Opinions expressed are my own.
[EMAIL PROTECTED] (official) [EMAIL PROTECTED] (backdoor)
[EMAIL PROTECTED] (home) http://www.apis.demon.co.uk
Linux ............... Because I like to _get_ there today.
------------------------------
From: Emile van Bergen <[EMAIL PROTECTED]>
Crossposted-To:
comp.windows.x,comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: New free widget library: Notif-0.1
Date: Mon, 01 Feb 1999 11:47:01 +0100
Joseph H Allen wrote:
>
> 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.
Wow! That's sort of strange, IMHO... ;-)
> 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).
Not exactly. One _does_ have a choice and may not want to go down the
event-driven path all the way. For instance, a few years ago, when I
created DOS apps for food, I wrote a GUI in C++ that also could be used
from within pure C (i.e., no 'derive your application objects from GUI
objects'-nonsense), that had this purely passive way of operating. Just
like in a classic menu-based application, it does nothing in the
background. It was the GUI equivalent to kbhit() and getch(), only with
GUI events instead of ascii codes, and you could provide the 'kbhit()'
with an event-mask to return only when things got interesting. The
'kbhit()'-equivalent also did the administrative tasks such as changing
the look of a button from depressed to pressed, etc.
This means that unless the user of the toolkit specifically wants it and
_provides his/her own solution_, there is no way that you 'can get
everywhere from anywhere' in the resulting application. The strange
thing is, many lusers actually liked this conventional hierarchical
structure! More on that to follow.
There were two exceptions:
1. if you needed a special string-gadget (I called widgets gadgets back
then) that did something 'on the fly', such as input checking, you'd
still have to derive this from the base tstringgdg. But this seems
natural, if you want to have more functionality in an object, you derive
a new object from that object.
2. The menu-bar. I wanted to handle the menu-bar at all times, i.e.
anywhere in the application hierarchy. But that was something I decided
in the application (whether I needed this application-wide menu's or
not), so there where constructs as these:
int myapproutine()
{
tbutton *ok,*cancel;
tevent *event;
int ret,done;
window=new twindow(W_DECORATE,C_WGREY,3,
new ttext(203,200,"rumble",C_BLACK),
new tbutton(1,123,343, ...etc,"Ok"),
new tbutton(2,456,343, ...etc,"Cancel"));
gui_openwindow(window);
for(ret=done=0; !done; )
{
while(gui_waitevent(BUT_DEPRESS+MENU_ACTIVATE));
event=gui_getevent();
if (event->type==MENU_ACTIVATE) { handle_global_menubar(event);
continue; }
switch(event->objectid)
{
case 1: ret=0,done=1; break;
case 2: ret=1,done=1; break;
}
}
gui_closewindow(window);
delete window;
return ret;
}
This has some nice features for the user, because it is clear to him/her
that functions that can be used at any time are always found in the menu
bar, and that the user 'is' somewhere in the app.
I'm not doing a plea for traditional menu-driven applications here. But
event-drivenness should only be there where it gives the user something
extra. It shouldn't be the default; this creates only confusion, IMHO...
[SNIP]
> 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.
Okay. But in these things I always end up fighting the framework,
because it's not passive enough!
> 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.
No, not per se, it has its own problems, as you point out (I was aware
of them...). See the code example for my idea of an alternative.
IMHO, the GUI toolkit can never be a end-all solution. If an application
designer wants his app to have a more complex structure (not strictly
hierarchical), he/she should create his app accordingly and provide his
own solutions to the problem, as needed. Let the designer be creative,
let the toolkit be passive. There are already enough unflexible,
'stubborn' GUI toolkits in this world.
> 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.
But this may not always be necessary. The bulk of the work in for
example, your (great! expecially for novices to Unix / vi-haters)
editor, could be devided in two: one big edit-widget (a GUI class
derivate), and one menu-bar handler. I don't see such a big need for
multiple outstanding dialogs in a well structured (qua interface)
application...
> 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.
Not nice; messy and confusing... as you already say.
> - 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).
Not as bad as 1, because cooperative, but... no thanks.
> - 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.
Yes, but I do not propose a new thread/process for any outstanding
dialog! Only _two_, one for the GUI and one for the application. I
wouldn't have any problem with using OS threads, use mutexes for calls
to gui_openwindow() and the like.
The application just recieves _events_. It's completely up to the
application designer to decide to what extent he wants his application
to be event-driven in structure... Rememeber, its not always fully
needed nor desireable! I would (and did) draw the line between the menu
bar (global) and the dialogs (local).
[SNIP]
> 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.
I don't know. Again, this necessity depends completely on the assumption
that you _always_ need a _pervasive_ event-driven model from the end
users point of view. And I don't agree to that... see the above ;-)
--
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.
------------------------------
From: Renaud Lottiaux <[EMAIL PROTECTED]>
Subject: Re: How to flush the file cache ?
Date: Mon, 01 Feb 1999 11:22:37 +0100
Jeff McWilliams wrote:
>
> Try issueing the sync command. that's what I do right before I want to
> unmount a zip disk and right after I've just copied a bunch of files to
> it. It forces the system to complete all pending writes... at least
> that's how it works for me. See the man page for sync
Sorry, my question was not correctly formulated...
I don't want to write back to disk durty data but
to clean out the file cache. When using the "sync"
command, pending writes are completed, but data
stay in cache.
I would like to REMOVE all data from the cache
to be sure that next read will be performed
from the disk and not from the cache.
Thanks.
------------------------------
** 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
******************************
