Brady Montz <bradym_at_cs.arizona.edu> writes:
> Dan Espen <dane_at_mk.bellcore.com> writes:
>
> > I don't see how you have answered #4 above. Wouldn't having an
> > interpreter hooked up to fvwm2 consume lots of memory instantly
> > transforming fvwm2 into CDE?
>
> Probably about a meg. Certainly significant. There will be some memory
> benefits to getting rid of the internal interpreter as well.
minus FvwmAuto which is much too much for a simple raise from a focus_change hook.
same for FvwmAudio/FvwmEvent which supplies the event hook functionality,
that fvwm2 is misssing.
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
albrecht 274 0.0 3.1 1988 960 ? S Apr 28 0:17 /usr/X11R6/bin/fvwm2
albrecht 3182 0.0 2.2 1540 700 ? S 11:48 0:00 /usr/X11R6/lib/X11/fvwm2/FvwmButtons 10 7 .fvwm2rc 0 8
albrecht 3183 0.0 1.9 1536 612 ? S 11:48 0:00 /usr/X11R6/lib/X11/fvwm2/FvwmPager 12 7 .fvwm2rc 0 8 0 0
albrecht 3189 0.0 1.2 1464 376 ? S 11:49 0:00 /usr/X11R6/lib/X11/fvwm2/FvwmAuto 16 7 .fvwm2rc 0 8 500
albrecht 3067 0.0 1.3 1488 404 ? S 11:35 0:00 /homes/albrecht/bin/Fvwm/FvwmEvent 16 7 .fvwm2rc 0 8
~3 Meg RSS for Fvwm & modules with
This could be better with shared libraries, but we've been waiting for 2
years now. And if guile is a shared lib, there should be other apps using
it too. (BTW: any plans for a guile-using multithreaded emacs ?)
albrecht 382 0.0 1.3 2196 428 ? S Apr 28 0:03 xload -title xload:boole -geometry -1500-1500
albrecht 384 0.0 0.9 2160 288 ? S Apr 28 0:00 xclock
albrecht 725 0.0 0.3 848 112 p3 S Apr 28 0:00 tail -f /homes/albrecht/.xsession-errors .mailfilter.log
albrecht 3506 0.0 0.9 2204 292 ? S Apr 30 0:07 xbiff
~1 Meg for Button Applications
one xterm + tcshell for console (shared text with other terminal windows, so not counted)
albrecht 995 0.1 7.4 20112 2304 p3 S Apr 28 22:34 emacs
albrecht 4310 0.1 40.3 22768 12488 p3 S May 5 3:12 emacs -f gnus
albrecht 4482 0.1 8.8 25164 2752 p5 S May 5 3:20 /usr/local/bin/netscape
http://www.public.usit.net/pinecrst/
ok I also have to work here
> > Wouldn't any new "fvwm plus interpreter" project be redundant to the
> > scwm project? (It doesn't seem to me that it makes much of a
> > difference whether the interpreter is Scheme, Perl, Tcl, Java.)
> >
> > I haven't come to any final opinion, I'd like to see how scwm works
> > out, but so far I'm not having many problems I can't solve with fvwm2.
>
Brady Montz:
> I didn't know about the scwm project until recently. I agree that it seems
> quite redundant, so much so that I suggested in my last post that perhaps it
> would be best for everyone if scwm became fvwm version 3.
>
> I personally have lots of problems with FvwmIconMan, and other modules which I
> would like to write, that would be solved by having an interpreter in fvwm.
And I think "my" modules FvwmAudio->FvwmEvent and FvwmAuto are simply
one-liners in lisp.
FvwmAuto in elisp:
(add-hook fvwm-enter-window-hook (progn (sleep-for 0 300)
(raise)))
--
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
... and, could someone please be so kind to post an algorithm to
cope with this world in real time, using incomplete knowledge !?
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu May 07 1998 - 05:06:10 BST