Subject: Re: FVWM: Re: Tcl, fvwm, etc.

From: patrick finerty <[email-masked]>
Date: Fri, 1 May 1998 01:01:22 -0600 (MDT)

On April 30, 1998, Jim Crigler wrote:

 > Perl can parse anything.  What's the problem?

really? i don't thinks that's completely true. witness:

12:59am zinc-> perl
is there a god 
^D
Can't locate object method "a" via package "god" at - line 1.

-pjf, it's way too late...

-- 
       "There is only one aim in life and that is to live it."
 Karl Shapiro,(1959) from an essay on Henry Miller's Tropic of Cancer
	  finger [email-masked] for PGP key
		    http://zifi.genetics.utah.edu
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: "Jose' Manuel Pereira" <[email-masked]>
Date: Tue, 5 May 1998 00:41:58 +0100 (WEST)

"BM" == Brady Montz <[email-masked]> writes:
  BM> Many people, including myself, will refuse to have anything to do with
  BM> perl. It's not wise to pick a language on so many people's blacklists.
  BM> Guile, while probably tecnically the most feasable, should probably be
  BM> set aside for the same reason.

Too late. scwm is based on it. I currently have installed one of the first
releases (0.4, I think) and it is impressively usable & stable.
(Then again, they started from fvwm-2.0.46...;-)

The authors did what people here are discussing once again:

- Junked the current "interpreter". According to fvwm-list, this is
  a_good_thing.

- Chose Guile (scheme) as the new supporting language. According to fvwm-list,
  this is _evil_, but only for religious reasons. ;-)

- Since guile isn't a finished product, every scwm'er has a different
  release/snapshot of it installed. Instead of being an obvious a_ha!
  show-stopper, this looks somehow irrelevant (I installed the old 1.2 guile
  release just for it. The developers use modern snapshots. 1.2 simply worked
  for all scwm versions till now).

- They have a quickly developing new wm. Fvwm stopped at 2.0.46. For good, as
  it seems. No hard feelings, Chuck...

  Just one example: the dreaded GSFR is already done. They didn't submit it to 
  this list, allegedly because the C code is too different now for a patch to
  be any use to fvwm...

  Yes, the Great Style Flags Rewrite. Big deal, uh?

As for CPU/memory weight, didn't notice any difference (no stats done, didn't
bother) in a P133/32Mb/Linux.

Personally, I just keep using fvwm2. It does the job and I simply don't have
the time to rewrite the .rc again for another wm (although, using Greg Badros'
config, now written in scheme, looks strikingly similar to the one I picked up 
for fvwm...)

Other reason is that my python "generic" module just keeps working and I
became too sentimentally attached to that code... ;-)

PS: My vote for other wm's:
-(E)nlightenment: colourful, core dumping memory hog (as of 0.13)
-Windowmaker: looks very nice, has session management (sort of), easy but
inflexible config. (by fvwm standards :-). Oh, and YAOCN (yet another original
config. language).
-twm: has session management (xsm)

(Please remove the NO to reply directly) 
-- 
 Jose' Pereira				 		Tel. +351.1.841 9340
 DEEC - Dep. of Electrical and Computer Engineering	Fax. +351.1.841 7499
 Instituto Superior Tecnico - Technical University of Lisboa
 Av. Rovisco Pais - 1096 Lisboa Codex - Portugal
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Brady Montz <[email-masked]>
Date: 05 May 1998 09:46:55 -0700

"Jose' Manuel Pereira" <[email-masked]> writes:
> - Chose Guile (scheme) as the new supporting language. According to
>   fvwm-list, this is _evil_, but only for religious reasons. ;-)

Well, I've only suggested that it might be _unwise_ for political reasons.

>   Just one example: the dreaded GSFR is already done. They didn't submit it
>   to this list, allegedly because the C code is too different now for a
>   patch to be any use to fvwm...
> 
> the time to rewrite the .rc again for another wm (although, using Greg
> Badros' config, now written in scheme, looks strikingly similar to the one I
> picked up for fvwm...)
> 

Well, this sounds pretty cool to me. I'd wished that I'd heard about it
sooner. I did an altavista search for scwm, but didn't find anything. Ah, just 
found it on the guile webpage.

I'd even go so far to say that I think we should release the current fvwm, and 
make scwm fvwm version 3. Since scwm looks like what a lot of people would
like fvwm to become, and renaming scwm to fvwm3 would give them instant name
recognition and a large user/tester base, it could be a good thing for
everybody. The only issues would be political (which often are the hardest to
overcome).

-- 
 Brady Montz
 [email-masked]

---

From: Jason L Tibbitts III <[email-masked]>
Date: 05 May 1998 14:27:52 -0500

>>>>> "BM" == Brady Montz <[email-masked]> writes:

BM> I'd even go so far to say that I think we should release the current fvwm, and 
BM> make scwm fvwm version 3. Since scwm looks like what a lot of people would
BM> like fvwm to become, and renaming scwm to fvwm3 would give them instant name
BM> recognition and a large user/tester base, it could be a good thing for
BM> everybody. The only issues would be political (which often are the hardest to
BM> overcome).

There was a big discussion about this on fvwm-workers a while back;
unfortunately I doubt that this will ever happen.  I gave the same argument
about inheriting the FVWM user base that you did, but it didn't fly.

 - J<

---

From: Albrecht Kadlec <[email-masked]>
Date: 07 May 1998 11:24:07 +0200

> about inheriting the FVWM user base that you did, but it didn't fly.

well more time has passed, and I might switch to scwm too. Maybe others
will follow.

This looks familiar to the minix discussion list, where they asked 
"where've all the people who supplied patches gone to"

They'd gone Linux'.

If we all wait for the conversion tools to be written, we might wait a long
time.

I've rewritten my .fvwmrc several times so far. (1.24-> 2.0 -> extensions)
before that I had a .mwmrc, .twmrc & others.

I think I'll add a .scwmrc as soon as possible.
-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
The chicks are getting cheaper on the not so common market
Stockpile experience before the blonde hairs turn to grey  -- Marillion
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Albrecht Kadlec <[email-masked]>
Date: 07 May 1998 20:03:15 +0200

> Well, I've only suggested that it might be _unwise_ for political reasons.

Many people will tell you :
	You know, you've been programming lisp too long, (if (....
(found in a siganture)

Many people don't like the parentheses, but also many people use emacs and
happily use / program elisp.

> >   Yes, the Great Style Flags Rewrite. Big deal, uh?

well not that big, but nobody touched it, because we were waiting for chuck
and nobody wanted to take over. And chuck had much too little time.

 
> everybody. The only issues would be political (which often are the hardest to

hmm, don't have time now to fiddle, but I'll look into it.

I can't add much to Brady's statement, without testing the product.
I do like the versatility of emacs-lisp, so I sure would jump on a
multithreaded lisp-extensible WM.

o) external access to data

	In a prior posting, I also pointed out that a complete language is
	still not enough. One still might want to throw in some external
	programs, so all internal structures should be accessible from
	outside. 

	You can do that with a lisp-wrapper, as the various lisp-modes in
	emacs show (command, compilation, man-mode, shell-mode, and so on).

o) I still would like the interpreter to be optional / transient /
   permanent / split / in a shared library.

	For most people it's enough to set variables. So they only need
	either
		a config data dump to be read in at startup  or
		a transient interpreter, which terminates after setup

	If you use lisp functions or hooks you can still benefit from
	a split ascii-to-bytecode translator & bytecode interpreter.

		All the junky tokens & syntax tables are in the translator
		and are therefore dumped after reading and parsing the
		config info.

		This also speeds things up considerably, since only
		bytecode is executed.

	Only in the case that an external program outputs ascii lisp
	commands to be executed by fvwm or eval() is used, this has to be
	fed through the translator. 

   So the ideal layout would be core fvwm with an option (or command) to
   speedload a variable image, and for complex commands a split bytecode
   interpreter and ascii-to-bytecode translator.

   The bytecode interpreter has to be some sort of library. Getting/putting
   common functions from/into a dynamically loaded shared library would be
   great. It will usually be swapped out / unloaded after not being
   accessed for a while. 

   The translator (Tokenizer / syntax checker) can be either shared library
   or external. Both ways it will be dumped, when it's not used for a while.

-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
If you love it, set it free.
If it doesn't come back, hunt it down and kill it. -- (maybe) James McGregor
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Brady Montz <[email-masked]>
Date: 07 May 1998 13:51:04 -0700

>    or external. Both ways it will be dumped, when it's not used for a while.

Sounds like a good plan to me.