Subject: CVS domivogt: * 64 bit fix.

From: FVWM CVS <[email-masked]>
Date: Fri, 9 Jul 2004 10:46:45 -0500

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	04/07/09 10:46:45

Modified files:
	.              : ChangeLog 
	fvwm           : module_interface.c 
	libs           : vpacket.h 
	modules        : ChangeLog 
	modules/FvwmAuto: FvwmAuto.c 
	modules/FvwmGtk: Makefile.am 

Log message:
* 64 bit fix.
* Removed old module interface.
Fixed FvwmGtk installation.

--
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: Mikhael Goikhman <[email-masked]>
Date: Sat, 10 Jul 2004 00:42:52 +0000

> * Removed old module interface.

At least one change (order of arguments in CONFIGURE_WINDOW) is bad.
The flags are of the variable size and thus should be last.

If you ever change any event arguments, please update file
perllib/FVWM/EventNames.pm (including format, names and types of the
event args), or tell me to update. Testing all modules that use that
event would be nice too.

BTW, I am really unhappy with the new flags method that is pretty much
C-only. Modules that can't embed the .h data structure simply can't use
window flags. The old method with positioned word-based properties rather
than compiler dependent bit-based flags was more robust. Currently a
module should be in C and should be compiled by the same compiler with
the same options, otherwise it may not get window flags correctly...
I don't have a good solution here.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Jul 2004 02:46:50 +0200

> The flags are of the variable size and thus should be last.

I can change that.  But why are the flags "variable size"?

> event args), or tell me to update. Testing all modules that use that

What's an event argument?  Do you mean module messages?

> than compiler dependent bit-based flags was more robust.

Yes, the compiler dependent structure layout is a bad idea.  One
should never map C structures to the network.

> Currently a

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 11 Jul 2004 10:47:28 +0000

> I can change that.  But why are the flags "variable size"?

How can you know in advance the number of bytes flags occupies? You can
know in advance sizeof(long int) on that platform, but not sizeof(flags).
Of course, if we only speak about C-modules compiled together with fvwm,
this does not matter. But other modules should at least get other
fixed-size event arguments correctly.

In the similar way, all name arguments in window/icon name events are of
the variable size and thus should be last. There is one difference, you
can calculate the size of flags in compile time, but you can't calculate
the size of window names at compile time. Still for modules in pure perl
there is no such difference.

> What's an event argument?  Do you mean module messages?

No, event argument is a positioned fixed-size (or variable-size if last)
field. Here is the terminology I and perllib/FVWM/EventNames.pm use:

Event is a synonym of packet from fvwm.
Event name: M_ICON_NAME
Event type (or rather mask): 1<<11
Event arguments:
	win_id           of type window (it is long int in C)
	frame_id         of type window (it is long int in C)
	ptr              of type number (it is pointer in C)
	name             of type string (variable size)

> > I don't have a good solution here.

Although I didn't actually use M_OLD_ADD_WINDOW/M_OLD_CONFIGURE_WINDOW,
I think I could use them to obtain certain flags.

Did you remove them because you need more event slots?
There are plenty of MX_*.

I think it is a good idea to think about the set of maybe 50 of most
useful flags (each of one or two bits) and create such compiler
independent two-arguments-of-32-bit compact event, similar to M_OLD_*.

And BTW, perllib does not currently support 64 bits platforms, because
I have neither LLP64 nor LP64 nor ILP64 platforms to test the fix.
See this url for the C type table:

  http://yarchive.net/comp/longlong.html

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 11 Jul 2004 11:04:24 +0000

> independent two-arguments-of-32-bit compact event, similar to M_OLD_*.

I should clarify myself. I don't want to restore M_OLD_ADD_WINDOW and
M_OLD_CONFIGURE_WINDOW events. I rather want to add two 32-bit arguments
flags_bunch_1 and flags_bunch_2 to M_ADD_WINDOW and M_ADD_WINDOW events.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Jul 2004 16:54:18 +0200

> field. Here is the terminology I and perllib/FVWM/EventNames.pm use:

I see.  Testing the modules when the order of fields in
ConfigWinPacket changes should not be necessary as all modules
have been rewritten to use that structure when it was introduced
in 2000.  If the perllib does not use it, it's a bug in the
perllib.  Currently, the only reliable way I see to access the
structure from perl is to write a bit of C code that translates it
to a format perl can read.

[snip]

> There are plenty of MX_*.

The M_OLD_..._WINDOW code has been commented out for years.  All I
did was to remove the dead code.

>   http://yarchive.net/comp/longlong.html

I think the right way to fix this is to define a machine
independent representation of the data that is currently sent in
ConfigWinPacket structures.  I always whought it was a mistake to
just blindly export the whole window_flags structure anyway.

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 11 Jul 2004 16:13:55 +0000

On 11 Jul 2004 16:54:18 +0200, Dominik Vogt wrote:
> perllib.

The bug part is questionable. There are currently 32+ events, not just 2.
Currently perllib (EventNames.pm specifically) defines the complete event
scheme. The C library does not even come close, modules simply parse the
events on their own, so there is no really enough info to generate from.

One solution would be to write a parser of ConfigWinPacket structure to
generate the scheme of these two events only. But given that someone
should maintain such parser, and this structure is not changed often
(maybe once per year), it is just much *much* easier to manually
synchronize EventNames.pm with it. Testing the modules is not really
necessary unless arguments are removed.

What is not questionable is that perllib should have tests, so any
breakage is auto-detected.

> Currently, the only reliable way I see to access the

This may be done when the C module library is established and stabilized.
But then again, there is currently only problem with flags that are hard
to be parsed reliably, and you want to solve this problem anyway.

> just blindly export the whole window_flags structure anyway.

This may be a good goal, but it requires more effort and mainainance than
the intermediate solution I suggested. But I am all for the complete
solution in the long run.

Regards,
Mikhael.