Subject: Re: FVWM: Parsing window_flags in perl

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 16 Sep 2004 20:51:30 +0000

On 16 Sep 2004 15:11:56 -0400, Salvatore Domenick Desiano wrote:
> 
> o But I really like your suggestion about a C program which will
> o generate a perl only FVWM::WindowFlags, and I will look into doing so.
> 
> I reiterate the suggestion that this be done on module startup, rather
> than by file generation. Then, rather than adding a file to the
> distribution, you simply generate a set of M_CONFIG_INFO messages
> 
> M_CONFIG_INFO FlagBit WINDOW_HAS_TITLE 134
> M_CONFIG_INFO FlagBit WINDOW_IS_STICKY_ACROSS_DESKS 0
> M_CONFIG_INFO FlagBit STYLE_IS_TRANSIENT 150

[I move this discussion to fvwm-workers@ not to scare readers.]

This is a good suggestion, but it adds more than 300 events to modules
even if they are not interested in window flag bits.

I am not against going this way although it is harder than my my
intermediate solution and still is not fully the ideal solution (that
would be not to dump and pass C structures across network). But again,
this is an acceptable solution.

But then, to be optimal we need a new event type MX_WINDOW_FLAG with
three arguments: short int bit_start, short int bit_length, char *name.

> The C code is the same as what Mark has been talked about for a C -> Perl
> module, and I've written it already for another project, although it's not
> to Fvwm coding standards. It's not elegant, but brute force is all we can
> get because of the implementation-dependent style of the C standard.
> 
> #define FIND_BIT(x) \
>    { SET_##x(with,1);  \
>      find_bit(##x,with,without); \
>      SET_##x(with,0); }
> 
> unsigned find_bit(char         * name,
>                   window_flags * with,
>                   window_flags * without)
> {
>   for (i = 0; i < (sizeof(wf) * 8); ++i)
>   {
>     unsigned bitIndex = i % 8;
>     unsigned byteIndex = i / 8;
>     unsigned char byte = ((unsigned char *)&wf)[byteIndex];
>     unsigned char bit = (byte >> bitIndex) & 0x1;
>     unsigned char bytet = ((unsigned char *)&wft)[byteIndex];
>     unsigned char bitt = (bytet >> bitIndex) & 0x1;
>     if (bit != bitt)
>       printf("M_CONFIG_INFO FlagBit %s %d\n",name,bit);
>   }
> }
> 
> unsigned dump_window_flags()
> {
>   FvwmWindow with;
>   FvwmWindow without;
>   FIND_BIT(DO_SHRINK_WINDOWSHADE);
>   FIND_BIT(DO_LOWER_TRANSIENT);
>   FIND_BIT(DO_STACK_TRANSIENT_PARENT);
> 
>   ...
> 
> }

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-masked].
To report problems, send mail to [email-masked]

---

From: Salvatore Domenick Desiano <[email-masked]>
Date: Thu, 16 Sep 2004 17:02:57 -0400 (EDT)

o [I move this discussion to fvwm-workers@ not to scare readers.]

Missed which list we were on. Thanks.

o This is a good suggestion, but it adds more than 300 events to modules
o even if they are not interested in window flag bits.

That's true, although 300 events on startup isn't so bad. I'm not sure how
often people ask for config info after that, though, so it is possible
that it adds a lot of overhead to some modules.

o I am not against going this way although it is harder than my my
o intermediate solution and still is not fully the ideal solution (that
o would be not to dump and pass C structures across network). But again,
o this is an acceptable solution.

I go back and forth about this. On the one hand, dumping the C structure
is the most efficient way to take care of shipping this kind of data. On
the other hand, my platform-independant psyche says "yech." I like the
idea of adding a new message, but only if it is heading toward a permanent
solution. What're you thinking about as an alternative to shipping the C
structure? I mean, I can think of a few, but they seem so grossly
inefficient (either in terms of space or computational overhead). I'd like
to think about this in the context of where this code is going, rather
than just the intermediate solution.

o But then, to be optimal we need a new event type MX_WINDOW_FLAG with
o three arguments: short int bit_start, short int bit_length, char
o *name.

Again, your experience wins out. I hadn't used any multi-bit flags.  This
will complicate the code, below. Not much, though.

-- Sal
smile.

o
o > The C code is the same as what Mark has been talked about for a C -> Perl
o > module, and I've written it already for another project, although it's not
o > to Fvwm coding standards. It's not elegant, but brute force is all we can
o > get because of the implementation-dependent style of the C standard.
o >
o > #define FIND_BIT(x) \
o >    { SET_##x(with,1);  \
o >      find_bit(##x,with,without); \
o >      SET_##x(with,0); }
o >
o > unsigned find_bit(char         * name,
o >                   window_flags * with,
o >                   window_flags * without)
o > {
o >   for (i = 0; i < (sizeof(wf) * 8); ++i)
o >   {
o >     unsigned bitIndex = i % 8;
o >     unsigned byteIndex = i / 8;
o >     unsigned char byte = ((unsigned char *)&wf)[byteIndex];
o >     unsigned char bit = (byte >> bitIndex) & 0x1;
o >     unsigned char bytet = ((unsigned char *)&wft)[byteIndex];
o >     unsigned char bitt = (bytet >> bitIndex) & 0x1;
o >     if (bit != bitt)
o >       printf("M_CONFIG_INFO FlagBit %s %d\n",name,bit);
o >   }
o > }
o >
o > unsigned dump_window_flags()
o > {
o >   FvwmWindow with;
o >   FvwmWindow without;
o >   FIND_BIT(DO_SHRINK_WINDOWSHADE);
o >   FIND_BIT(DO_LOWER_TRANSIENT);
o >   FIND_BIT(DO_STACK_TRANSIENT_PARENT);
o >
o >   ...
o >
o > }
o
o Regards,
o Mikhael.
o
o
o

--------------
  Salvatore Domenick Desiano
    Research Scientist
      NASA Ames Research Center (QSS Group, Inc.)

---

From: Dan Espen <[email-masked]>
Date: Thu, 16 Sep 2004 19:27:55 -0400

> even if they are not interested in window flag bits.

I think that is too many messages.
The module should request the messages.
That is the only time the messages should be sent.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 16 Sep 2004 20:51:30 +0000

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 16 Sep 2004 23:22:33 +0000

[I suppose Jason should approve these messages to the list.]

> than just the intermediate solution.

Maybe Dominik has another solution, but my "best" solution is something
like this. Send all bits packed by hand (not C structure), and send the
scheme using the described MX_WINDOW_FLAG event.

Advantages as compared to your solution:

  * sent data is not compiler specific
  * more network-optimal, currently window_flags contains some internal
    window state useful to fvwm only, it would not be sent

Disadvantages:

  * less performance-optimal, requires a work to pack flags
  * probably more difficult to maintain, but this is not clear yet
  * replacing the sent window_flags is a risky change

Both solutions are similar in that they require the same MX_WINDOW_FLAG
to define the scheme. Also, the Perl code written for one should not be
changed when switching to another.

So, I think, we may start with adding a new event and not changing any
existing events. Then later we may raise the question again of whether
the compiler specific format is good or not.

Regards,
Mikhael.

---

From: Salvatore Domenick Desiano <[email-masked]>
Date: Thu, 16 Sep 2004 19:45:10 -0400 (EDT)

o Maybe Dominik has another solution, but my "best" solution is
o something like this. Send all bits packed by hand (not C structure),
o and send the scheme using the described MX_WINDOW_FLAG event.

Yeah, we're on the same page, for what my novice opinion is worth. The
only thing I would think wasteful is if we actually broke each flag out
into, say, a char value so it got across the network okay. In terms of
re-packing, you're going down the same path I was thinking, so here's what
I hit: how do you account for endianness? I guess we assert that the
messages are in network-byte-order, but that means that we will have to be
very careful about making sure that every platform gets its endianness
right when the data leaves.

With this in mind, MX_WINDOW_FLAG seems even more attractive (as opposed
to a generated perl file, since it will solve the problem for every
module, no matter the language).

Do we send it automatically, is there a request, or is it part of
config_info (that last one doesn't seem right)?

-- Sal
smile.

o
o Advantages as compared to your solution:
o
o   * sent data is not compiler specific
o   * more network-optimal, currently window_flags contains some internal
o     window state useful to fvwm only, it would not be sent
o
o Disadvantages:
o
o   * less performance-optimal, requires a work to pack flags
o   * probably more difficult to maintain, but this is not clear yet
o   * replacing the sent window_flags is a risky change
o
o Both solutions are similar in that they require the same MX_WINDOW_FLAG
o to define the scheme. Also, the Perl code written for one should not be
o changed when switching to another.
o
o So, I think, we may start with adding a new event and not changing any
o existing events. Then later we may raise the question again of whether
o the compiler specific format is good or not.
o
o Regards,
o Mikhael.
o

o

--------------

---

From: Salvatore Domenick Desiano <[email-masked]>
Date: Thu, 16 Sep 2004 17:02:57 -0400 (EDT)

-- Sal
smile.

o

--------------

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 17 Sep 2004 00:19:03 +0000

On 16 Sep 2004 19:45:10 -0400, Salvatore Domenick Desiano wrote:
> 
> how do you account for endianness?

Please don't worry about endianness, at least not in this thread.
Endianness and bits-in-the-integer is something that should be worried
in the lowest layer regardless of the event.

> config_info (that last one doesn't seem right)?

A module should set MX_WINDOW_FLAG xmask. And we probably need
SendWindowFlags (SendWindowFlagScheme?) command from modules.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 17 Sep 2004 00:40:51 +0000

On 16 Sep 2004 20:26:03 -0400, Salvatore Domenick Desiano wrote:
> 
> o > how do you account for endianness?
> o
> o Please don't worry about endianness, at least not in this thread.
> o Endianness and bits-in-the-integer is something that should be worried
> o in the lowest layer regardless of the event.
> 
> True, although endianness is no more or less a problem than structure
> alignment, which is what started this discussion.
> 
> Is anyone coding this, or should I start?

Yes, you may start, just please preserve the coding style. I don't have
the hardware anyway.

Regards,
Mikhael.

---

From: Salvatore Domenick Desiano <[email-masked]>
Date: Thu, 16 Sep 2004 20:26:03 -0400 (EDT)

-- Sal
smile.

--------------

---

From: Salvatore Domenick Desiano <[email-masked]>
Date: Thu, 16 Sep 2004 20:43:19 -0400 (EDT)

On Fri, 17 Sep 2004, Mikhael Goikhman wrote:

o On 16 Sep 2004 20:26:03 -0400, Salvatore Domenick Desiano wrote:
o >
o > o > how do you account for endianness?
o > o
o > o Please don't worry about endianness, at least not in this thread.
o > o Endianness and bits-in-the-integer is something that should be worried
o > o in the lowest layer regardless of the event.
o >
o > True, although endianness is no more or less a problem than structure
o > alignment, which is what started this discussion.
o >
o > Is anyone coding this, or should I start?
o
o Yes, you may start, just please preserve the coding style. I don't have
o the hardware anyway.

Of course. The last code snippet I wrote was off of a test program that
wasn't for publication.

-- Sal
smile.

--------------