Re: XEmacs Module (was Re: [VETO] Re: XEmacs-21.4.5 ...)

On 14 Dec 2001 at 19:06:25 +0900, Yoshiki Hayashi <yoshiki(a)xemacs.org&gt; wrote: <*waves arms*> I'm still here! I've been reading xemacs-beta faithfully, although I admit that I haven't exactly been talkative. Let me tell you what I've been up to, and what my plans are. Then you can shoot them down. :-) The obvious API would completely isolate the XEmacs internals from the modules, forcing modules to (for example) call functions to get access to variables and functions not defined in the module itself, even if those variables and functions are defined at the C level. The problem is that this API doesn't quite cut it for my pet module, the ViaVoice interface. There are two hassles: (1) Not everything a module might need to do is accessible in this way. For example, the ViaVoice module needs to hook into the event stream. I copied BillP's approach to doing that, and actually modified event_stream->event_pending_p and event_stream->next_event_cb to call my functions, which in turn call whatever used to be there. With the obvious API, event_stream would not be accessible from the module. We could make an exception, just for event_stream, except that I have this gut feeling that the number of exceptions we would need would grow without bound, which would render the obvious API kind of pointless. To solve my particular problem (event_stream), I intend to write hook_event_stream and unhook_event_stream functions. This is not entirely trivial, since existing code will have to be modified to use the new functions . Other such modifications may be needed for future modules. (2) Performance, performance, performance. Did I mention performance? My ViaVoice module is already too slow. Forcing it to go through Elisp every time, even when the Elisp is just going to call back into C, isn't going to speed it up any. My initial thought on this one was to use a language-level solution. Have the module writer identify functions to be called and variables to be accessed in some idiomatic way, and then have ellcc do something to compile down to C function calls and C variable accesses whenever possible, using the Lisp interface otherwise. **Note that this means that the binary version of a module will be specific to the version of XEmacs corresponding to the ellcc that produced it.** I proposed something along those lines awhile back, only I got too ambitious and proposed a similar approach for the XEmacs core as well. Martin (rightly!) shot me down. :-) Would something like that be too onerous to impose on module writers? If not, I'll get to work on figuring out how to do it. (But not until after I grade all my finals, which effectively means not until after Christmas.) My plan is to approach the tasks in this order: 1. Spec out the "obvious" API described above, and announce it as module API version 0.1, so that potential module writers can get started. 2. Change event hooking and unhooking so that it will be accessible to module writers. (In fact, *un*hooking isn't even possible right now, so that will be a bonus.) Document this in API version 0.2. 3. Build a tool which will assemble a list of C functions and variables that are visible from Lisp and record their [Lisp name -> C name] mappings in a place accessible to ellcc. 4. Come up with an idiom for identifying Lisp accesses in a module, and make ellcc compare with the list built by 3 in order to optimize access in the current module. Also, give ellcc a switch to turn this optimization off, in order to generate XEmacs version independent modules. Document this in API version 0.3. Several. Identify Lisp functions and variables which will always and forever be implemented in C. Either: (a) let module writers have direct access to those; or (b) make ellcc always compile them to direct C accesses, even when the optimization switch is off. Identify them in the official API and release version 1.0. Many. Get to work on figuring out how to write an Elisp -> module converter, followed by optimizing intermodule function/variable accesses. There. Now you can tell me all about my insanity. Cool! Is your module publically available anywhere? In other module news, let me tell you about some ViaVoice developments. After writing the C code, I couldn't seem to find time to finish the module off properly by writing all the Elisp to use it. So when the graduate level Software Engineering class here asked for projects, I offered that one up. Some students in that class did a really nice job of developing it further. It still isn't what I would consider done, but it is a lot further along. After I do a little cleanup on it, I'll release it. -- Jerry James, who notes the lack of a serial comma in the following quote "Taurus: The stars predict tomorrow you'll wake up, do a bunch of stuff and then go back to sleep." -- "Weird Al" Yankovic, "Your Horoscope for Today"