Re: Changes in module interface
On 11 Jul 2004 02:46:50 +0200, Dominik Vogt wrote: On Sat, Jul 10, 2004 at 12:42:52AM +, Mikhael Goikhman wrote: At least one change (order of arguments in CONFIGURE_WINDOW) is bad. The flags are of the variable size and thus should be last. 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. 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. 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): 111 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) 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. Yes, the compiler dependent structure layout is a bad idea. One should never map C structures to the network. 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. 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. -- 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: Changes in module interface
On 11 Jul 2004 10:47:28 +, Mikhael Goikhman wrote: Although I didn't actually use M_OLD_ADD_WINDOW/M_OLD_CONFIGURE_WINDOW, I think I could use them to obtain certain flags. 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_*. 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. -- 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: Changes in module interface
On Sun, Jul 11, 2004 at 10:47:28AM +, Mikhael Goikhman wrote: On 11 Jul 2004 02:46:50 +0200, Dominik Vogt wrote: On Sat, Jul 10, 2004 at 12:42:52AM +, Mikhael Goikhman wrote: At least one change (order of arguments in CONFIGURE_WINDOW) is bad. The flags are of the variable size and thus should be last. 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. 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. 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: 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] 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. Yes, the compiler dependent structure layout is a bad idea. One should never map C structures to the network. 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. 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_*. The M_OLD_..._WINDOW code has been commented out for years. All I did was to remove the dead code. 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 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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgp1iCejN61J6.pgp Description: PGP signature
Re: Changes in module interface
On 11 Jul 2004 16:54:18 +0200, Dominik Vogt wrote: On Sun, Jul 11, 2004 at 10:47:28AM +, Mikhael Goikhman wrote: 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. 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: 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. 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 structure from perl is to write a bit of C code that translates it to a format perl can read. 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. 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_*. 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. 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. -- 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: Changes in module interface
On Sat, Jul 10, 2004 at 12:42:52AM +, Mikhael Goikhman wrote: At least one change (order of arguments in CONFIGURE_WINDOW) is bad. The flags are of the variable size and thus should be last. I can change that. But why are the flags variable size? 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. What's an event argument? Do you mean module messages? 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. Yes, the compiler dependent structure layout is a bad idea. One should never map C structures to the network. 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgpC78YqF1M0R.pgp Description: PGP signature
Changes in module interface
On 09 Jul 2004 10:46:45 -0500, FVWM CVS wrote: Modified files: fvwm : module_interface.c Log message: * 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. -- 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]
