Re: Patch for possible if-else syntax
On 08 Aug 2001 14:57:41 +0200, Dominik Vogt wrote: On Wed, Aug 08, 2001 at 04:45:34AM +, Mikhael Goikhman wrote: In any way, this solution is more clean and extendible than the Dominik's one and it does not change any existing syntax. Hm. I'd really prefer a solution that is *not* extensible. I thought there was a common consensus that we don't want to implement a scripting language in fvwm. Are not scripting language and extensible solutions orthogonal? Maybe we speak about different meanings of extensible solution, or you really prefer to solve all new and old problems separately? For example, if there is a need to do the following 1) Add an alternative command to conditions 2) Try several file names to Read 3) Determine that a module was not started 4) Determine a timeout in some commands you suggest to alter a syntax of Next, Read, Module, ModuleSynchronous and others, instead of identifying that all these problems are actually one if-else problem and implementing an extensible solution, like command statuses and Otherwise, without a need to change any existing syntax? With this solution, solving more similar problems is done by adding a line. Or another example of extensible solution. We currently only need a command status True/False, so we go with Boolean by adding it to many places. But tomorrow we will need another Boolean, so we should add it to the same places again. An extensible solution would suggest that we will need more than a Boolean in the future and do it in the first place. So, if there are no objections I will apply the merged patch implementing this new command. And BTW, it has sense (not yet) to call this command outside of functions. Read myfile1 quiet Otherwise Read myfile2 quiet Otherwise Echo Error: No myfile1 or myfile2 found That's the best example I could think of why global variables are *not* the way to go. Whenever a command is executed outside a function, there is a chance that another command gets executed first and screws up the return code. You are right, there is a common problem with synchronizing commands from the same stream in concurrent environment. But there are no problems if these commands are Read from a file, because another command can't get executed until the file is finished. So I still think that Otherwise outside of functions is useful, although it is almost useless interactively. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch for possible if-else syntax
On 08 Aug 2001 21:29:50 +0200, Dominik Vogt wrote:
On Wed, Aug 08, 2001 at 08:14:01PM +0700, Dmitry Yu. Bolkhovityanov wrote:
On Wed, 8 Aug 2001, Dominik Vogt wrote:
Is it really necessary to pass function return codes through
global variables? If we do this now we will regret it some day.
That's just a logical consequence of current CMD_fff calling
convention. I really investigated if globals can be avoided, but there is
*no* per-call structure to hold the return value.
That's why I wanted avoid function return codes. Every return
in each CMD_... function would have to be touched.
And yes, there is an obvious case when this solution would break
-- if someday fvwm will allow concurrent execution of functions (AFAIK,
currently it does so in an interrupt fashion, so that saving/restoring
the state in execute_complex_function() is enough).
What do you mean with if someday? Fvwm already supports
asynchronous execution, e.g. when modules send commands.
I think Dimitry meant asynchronous execution of _complex_ functions.
I myself often call complex functions simply functions as opposed to
functions that are commands.
Anyway, there is a fairly simple solution to save the patch: add
another parameter to the macros in fvwm.h:
#define F_CMD_ARGS XEvent *eventp, Window w, FvwmWindow *tmp_win, unsigned
long context,char *action, int *Module, Bool *ret_rc
#define F_PASS_ARGS eventp, w, tmp_win, context, action, Module, ret_rc
#define F_EXEC_ARGS char *action, FvwmWindow *tmp_win, XEvent *eventp,
unsigned long context, int Module, Bool *ret_rc
#define F_PASS_EXEC_ARGS action, tmp_win, eventp, context, *Module, ret_rc
(sorry for the long lines).
The *ret_rc would be pre-initialised with True just like the
globals in the patch. Only conditional commands ever set it to
False. Now, only the few direct calls of CMD_... functions that
do not pass the arguments via one of the macros have to be
modified. This would be good enough for me.
The patch became much longer, because all references to
old_execute_function and some other functions should be altered.
I attach the patch for reviewing. Changes other than in conditional.c and
functions.c are less interesting. The patch is somewhat different from
Dmitry's, but implements the same thing. Complex functions return the
status of the last inner command. Probably some things may be tuned.
Regards,
Mikhael.
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.226
diff -u -r1.226 add_window.c
--- fvwm/add_window.c 2001/06/23 18:30:15 1.226
+++ fvwm/add_window.c 2001/08/09 14:55:53
@@ -1497,7 +1497,7 @@
if (!IsRectangleOnThisPage(tmp_win-frame_g, Scr.CurrentDesk))
{
SET_STICKY(tmp_win, 0);
- handle_stick(Event, tmp_win-frame, tmp_win, C_FRAME, , 0, 1);
+ handle_stick(Event, tmp_win-frame, tmp_win, C_FRAME, , 0, NULL, 1);
}
}
@@ -1516,7 +1516,7 @@
Event.xbutton.y = (tmp_win-frame_g.height1);
Event.xbutton.subwindow = None;
Event.xany.window = tmp_win-w;
-CMD_Resize(Event , tmp_win-w, tmp_win, C_WINDOW, , 0);
+CMD_Resize(Event , tmp_win-w, tmp_win, C_WINDOW, , 0, NULL);
}
/** window colormap **/
Index: fvwm/builtins.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/builtins.c,v
retrieving revision 1.313
diff -u -r1.313 builtins.c
--- fvwm/builtins.c 2001/08/01 15:22:51 1.313
+++ fvwm/builtins.c 2001/08/09 14:55:57
@@ -1861,7 +1861,7 @@
if (!*s)
return;
Scr.cur_decor = decor;
- old_execute_function(s, NULL, Event, C_ROOT, -1, 0, NULL);
+ old_execute_function(s, NULL, Event, C_ROOT, -1, NULL, 0, NULL);
Scr.cur_decor = NULL;
}
@@ -1968,7 +1968,8 @@
fw-frame_g.height -= fw-decor-title_height;
fw-decor = NULL;
old_execute_function(
- ChangeDecor Default, fw, eventp, C_WINDOW, *Module, 0, NULL);
+ ChangeDecor Default, fw, eventp, C_WINDOW, *Module, NULL, 0,
+ NULL);
}
}
}
@@ -3267,7 +3268,8 @@
usleep(20);
UngrabEm(GRAB_BUSY);
}
-old_execute_function(stroke_action, tmp_win, eventp, context, -1, 0, NULL);
+old_execute_function(
+ stroke_action, tmp_win, eventp, context, -1, NULL, 0, NULL);
}
}
Index: fvwm/commands.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/commands.h,v
retrieving revision 1.1
diff -u -r1.1 commands.h
--- fvwm/commands.h 2001/03/24 15:15:21 1.1
+++ fvwm/commands.h 2001/08/09 14:55:57
@@ -114,6 +114,7 @@
void CMD_None(F_CMD_ARGS);
void CMD_Nop(F_CMD_ARGS);
void CMD_OpaqueMoveSize(F_CMD_ARGS);
+void CMD_Otherwise(F_CMD_ARGS);
void CMD_Pick(F_CMD_ARGS);
void CMD_PipeRead(F_CMD_ARGS);
void
Re: Patch for possible if-else syntax
On 09 Aug 2001 17:35:57 +0200, Dominik Vogt wrote: I'd rather rewrite the syntax 20 commands than extend the command parser in such a way. Currently it is *the* worst piece of fvwm code: not extensible, hard to understand, undpredictable, buggy. I am not sure why do you think so. I see no reasons. It is actually not hard to understand if you understood the original smaller patch. Granted, I didn't tested it fully, only maybe 5-6 cases, But if you don't use the new stuff (command Otherwise or last status $?) there should not be any reduction in stability. This may wait for 2.5.0. You are right: it can only work inside complex functions and Read files and fail from modules and the command line. I guess then my proposal is still the most sound one: easy to implement, the patches are limited to a single file, helps with the most basic needs some users have and does not encourage difficult to implement enhancement requests. In my eyes, we can only think about scripting support in the command parser if we are prepared to throw away the whole code in functions.c and write it from scratch - which explicitly means that the most central part of fvwm becomes incompatible to older versions. Concurrent command execution is already broken within + command. This is an old problem, which probably can be solved if we store all global data last_* separately for every module pipe. Will this be a solution? Dominik, you once said that a lot of harm was done by many small patches each implementing its own inconsistent syntax. The enhancement you suggest is powerful, of course, you may write a whole if-else program in one line using nested conditions. But I don't feel this is a good syntax to introduce. I would not introduce any new syntax as radical as this without thinking about consistency with other command syntaxes. The solution that does not introduce any new syntax, but solves more than one problem is more preferable to me. After 2.5.0 we may think and change syntax. Anyway, I have no any willing to force my solution without your agreement. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch for possible if-else syntax
On Wed, Aug 08, 2001 at 12:27:18AM +0700, Dmitry Yu. Bolkhovityanov wrote: Content-Description: Mail message body Hi! I've made a patch which implements a simple if-else syntax. A new Otherwise command is introduced (wouldn't clash with possible future syntax enhancements, right?), which executes supplied command only if previous command was unsuccessful. So the syntax is: AddToFunc Do-this-or-that + I Next (SomeProggie) Close + I Otherwise SomeProggie (this implements Dominik's example of if some window exists, kill it, otherwise start it). Each command may return a True/False value, which defaults to True. This logic is implemented in execute_complex_function(), which sets the current return value to True before calling a command. There's no change in command calling conventions, since return value of this command and return value of previous command are global variables (sic!). Changed are only conditional commands, which set return value to False when unsuccessful. I also investigated if it would be possible to place these two vars into exec_func_args_type, but those structs aren't passed between *execute*function(). Since return values are stored in global vars, execute_complex_function() saves previous state and restores it on exit. Unfortunately, it contained a number of returns, which had to be replaced with goto END_OF_FUNCTION (I wish C had Ada/Perl break from a block feature...). Of course, calling Otherwise outside a complex function is senseless. Man page modification isn't included. Is it really necessary to pass function return codes through global variables? If we do this now we will regret it some day. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch for possible if-else syntax
On Wed, Aug 08, 2001 at 04:45:34AM +, Mikhael Goikhman wrote: On 08 Aug 2001 00:27:18 +0700, Dmitry Yu. Bolkhovityanov wrote: I've made a patch which implements a simple if-else syntax. A new Otherwise command is introduced (wouldn't clash with possible future syntax enhancements, right?), which executes supplied command only if previous command was unsuccessful. So the syntax is: AddToFunc Do-this-or-that + I Next (SomeProggie) Close + I Otherwise SomeProggie (this implements Dominik's example of if some window exists, kill it, otherwise start it). Each command may return a True/False value, which defaults to True. This logic is implemented in execute_complex_function(), which sets the current return value to True before calling a command. There's no change in command calling conventions, since return value of this command and return value of previous command are global variables (sic!). Changed are only conditional commands, which set return value to False when unsuccessful. I also investigated if it would be possible to place these two vars into exec_func_args_type, but those structs aren't passed between *execute*function(). Since return values are stored in global vars, execute_complex_function() saves previous state and restores it on exit. Unfortunately, it contained a number of returns, which had to be replaced with goto END_OF_FUNCTION (I wish C had Ada/Perl break from a block feature...). Of course, calling Otherwise outside a complex function is senseless. Grr... :) Before reading the mail I did my own patch that happens to be almost equivalent to yours, except for minor things. Say, I used interface functions instead of global variables (there is only one static variable). Also in my intention, functions may return more than just success or failure. We may have in the future such failure codes like: timeout, window mismatch, timeout, incorrect usage, and the Otherwise command may have an optional parameter to distinguish between different failures. In the future all CMD_* functions may return this value, that is success in most of cases. Currently it is not needed to minimize changes. I called the function Else, because I hoped to have If in the future (for non-window conditions). But I have no objections to call it Otherwise. In any way, this solution is more clean and extendible than the Dominik's one and it does not change any existing syntax. Hm. I'd really prefer a solution that is *not* extensible. I thought there was a common consensus that we don't want to implement a scripting language in fvwm. So, if there are no objections I will apply the merged patch implementing this new command. And BTW, it has sense (not yet) to call this command outside of functions. Read myfile1 quiet Otherwise Read myfile2 quiet Otherwise Echo Error: No myfile1 or myfile2 found That's the best example I could think of why global variables are *not* the way to go. Whenever a command is executed outside a function, there is a chance that another command gets executed first and screws up the return code. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch for possible if-else syntax
On Wed, Aug 08, 2001 at 08:14:01PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Wed, 8 Aug 2001, Dominik Vogt wrote: Is it really necessary to pass function return codes through global variables? If we do this now we will regret it some day. That's just a logical consequence of current CMD_fff calling convention. I really investigated if globals can be avoided, but there is *no* per-call structure to hold the return value. That's why I wanted avoid function return codes. Every return in each CMD_... function would have to be touched. And yes, there is an obvious case when this solution would break -- if someday fvwm will allow concurrent execution of functions (AFAIK, currently it does so in an interrupt fashion, so that saving/restoring the state in execute_complex_function() is enough). What do you mean with if someday? Fvwm already supports asynchronous execution, e.g. when modules send commands. Anyway, there is a fairly simple solution to save the patch: add another parameter to the macros in fvwm.h: #define F_CMD_ARGS XEvent *eventp, Window w, FvwmWindow *tmp_win, unsigned long context,char *action, int *Module, Bool *ret_rc #define F_PASS_ARGS eventp, w, tmp_win, context, action, Module, ret_rc #define F_EXEC_ARGS char *action, FvwmWindow *tmp_win, XEvent *eventp, unsigned long context, int Module, Bool *ret_rc #define F_PASS_EXEC_ARGS action, tmp_win, eventp, context, *Module, ret_rc (sorry for the long lines). The *ret_rc would be pre-initialised with True just like the globals in the patch. Only conditional commands ever set it to False. Now, only the few direct calls of CMD_... functions that do not pass the arguments via one of the macros have to be modified. This would be good enough for me. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Patch for possible if-else syntax
Hi!
I've made a patch which implements a simple if-else syntax.
A new Otherwise command is introduced (wouldn't clash with possible
future syntax enhancements, right?), which executes supplied command only if
previous command was unsuccessful. So the syntax is:
AddToFunc Do-this-or-that
+ I Next (SomeProggie) Close
+ I Otherwise SomeProggie
(this implements Dominik's example of if some window exists, kill it,
otherwise start it).
Each command may return a True/False value, which defaults to True.
This logic is implemented in execute_complex_function(), which sets the
current return value to True before calling a command. There's no change
in command calling conventions, since return value of this command and
return value of previous command are global variables (sic!). Changed are
only conditional commands, which set return value to False when
unsuccessful. I also investigated if it would be possible to place these
two vars into exec_func_args_type, but those structs aren't passed between
*execute*function().
Since return values are stored in global vars,
execute_complex_function() saves previous state and restores it on exit.
Unfortunately, it contained a number of returns, which had to be replaced
with goto END_OF_FUNCTION (I wish C had Ada/Perl break from a block
feature...).
Of course, calling Otherwise outside a complex function is senseless.
Man page modification isn't included.
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.
File information ---
File: OTHERW.DIF
Date: 7 Aug 2001, 23:04
Size: 7906 bytes.
Type: Binary
OTHERW.DIF
Description: Binary data
