There is one use of PROCESS_LIVE_P left (in process_send_signal) that could be replaced by CHECK_LIVE_PROCESS. I haven´t done that yet because the resulting error would be different (i.e. we wouldn´t print the process name anymore). any opinions on that?

Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; writes: > Gunnar Evermann <ge204(a)eng.cam.ac.uk&gt; writes: > > > * process.c (Fprocess_input_coding_system): check whether process > > is still alive > > Approved. Recommened for 21.1. I think we should still apply the above patch to 21.1. > > process = get_process (process); > > + if (!PROCESS_LIVE_P (process)) > > + error ("Process %s is not active", > > + XSTRING_DATA (XPROCESS (process)->name)); > > + > > return decoding_stream_coding_system (XLSTREAM (XPROCESS (process)->coding_instream) ); > > You might want to turn this into a CHECK_PROCESS_LIVE(process) > macro[1], to be consistent with other such checks. yes, good point. I had actually looked for. I have now defined CHECK_LIVE_PROCESS and, to make all this consistent, a Lisp Function process-live-p (why wasn´t that defined before? Surely it is useful and nicer to use than process-status?). I also made the existing PROCESS_LIVE_P consistent with the other _LIVE_P macros and used it where possible (OK, so I got a bit carried away hacking process.c :-). There is one use of PROCESS_LIVE_P left (in process_send_signal) that could be replaced by CHECK_LIVE_PROCESS. I haven´t done that yet because the resulting error would be different (i.e. we wouldn´t print the process name anymore). any opinions on that? I´ll submit the crash test case for the test-suite separately. I would appreciate comments from people more familiar with process.c (Ben?). 1999-12-18 Gunnar Evermann <ge204(a)eng.cam.ac.uk&gt; * process.h (PROCESS_LIVE_P): Modify to take a Lisp_Process instead of a Lisp_Object as argument to make it consistent with the other LIVE_P macros. (CHECK_LIVE_PROCESS): New macro. * process.c: Declare Qprocess_live_p. (Fprocess_live_p): New function. (create_process): Use PROCESS_LIVE_P. (read_process_output): Ditto. (set_process_filter): Ditto. (Fdelete_process): Ditto. (kill_buffer_processes): Ditto (Fprocess_input_coding_system): Check whether process is still alive (fix PR#1061). (Fprocess_output_coding_system): Ditto. (Fprocess_coding_system): Ditto. (Fset_process_input_coding_system): Ditto. (Fset_process_output_coding_system): Ditto. --- src/process.h.orig Sat Dec 18 16:39:02 1999 +++ src/process.h Sat Dec 18 16:39:11 1999 ＠＠ -45,7 +45,13 ＠＠ #define XSETPROCESS(x, p) XSETRECORD (x, p, process) #define PROCESSP(x) RECORDP (x, process) #define CHECK_PROCESS(x) CHECK_RECORD (x, process) -#define PROCESS_LIVE_P(x) (!NILP (XPROCESS(x)->pipe_instream)) +#define PROCESS_LIVE_P(x) (!NILP ((x)->pipe_instream)) + +#define CHECK_LIVE_PROCESS(x) do { \ + CHECK_PROCESS (x); \ + if (! PROCESS_LIVE_P (XPROCESS (x))) \ + dead_wrong_type_argument (Qprocess_live_p, (x)); \ +} while (0) #ifdef emacs --- src/process.c.orig Sat Dec 18 16:43:27 1999 +++ src/process.c Sat Dec 18 17:32:40 1999 ＠＠ -58,7 +58,7 ＠＠ #include "systty.h" #include "syswait.h" -Lisp_Object Qprocessp; +Lisp_Object Qprocessp, Qprocess_live_p; /* Process methods */ struct process_methods the_process_methods; ＠＠ -257,6 +257,14 ＠＠ return PROCESSP (obj) ? Qt : Qnil; } +DEFUN ("process-live-p", Fprocess_live_p, 1, 1, 0, /* +Return t if OBJECT is a process that is alive. +*/ + (obj)) +{ + return PROCESSP (obj) && PROCESS_LIVE_P (XPROCESS (obj)) ? Qt : Qnil; +} + DEFUN ("process-list", Fprocess_list, 0, 0, 0, /* Return a list of all processes. */ ＠＠ -510,7 +518,7 ＠＠ pid = PROCMETH (create_process, (p, argv, nargv, program, cur_dir)); p->pid = make_int (pid); - if (!NILP(p->pipe_instream)) + if (PROCESS_LIVE_P (p)) event_stream_select_process (p); } ＠＠ -823,7 +831,7 ＠＠ Really, the loop in execute_internal_event() should check itself for a process-filter change, like in status_notify(); but the struct Lisp_Process is not exported outside of this file. */ - if (NILP(p->pipe_instream)) + if (!PROCESS_LIVE_P (p)) return -1; /* already closed */ if (!NILP (p->filter) && (p->filter_does_read)) ＠＠ -1032,7 +1040,7 ＠＠ set_process_filter (Lisp_Object proc, Lisp_Object filter, int filter_does_read) { CHECK_PROCESS (proc); - if (PROCESS_LIVE_P (proc)) { + if (PROCESS_LIVE_P (XPROCESS (proc))) { if (EQ (filter, Qt)) event_stream_unselect_process (XPROCESS (proc)); else ＠＠ -1121,6 +1129,7 ＠＠ (process)) { process = get_process (process); + CHECK_LIVE_PROCESS (process); return decoding_stream_coding_system (XLSTREAM (XPROCESS (process)->coding_instream) ); } ＠＠ -1130,6 +1139,7 ＠＠ (process)) { process = get_process (process); + CHECK_LIVE_PROCESS (process); return encoding_stream_coding_system (XLSTREAM (XPROCESS (process)->coding_outstream)); } ＠＠ -1139,6 +1149,7 ＠＠ (process)) { process = get_process (process); + CHECK_LIVE_PROCESS (process); return Fcons (decoding_stream_coding_system (XLSTREAM (XPROCESS (process)->coding_instream)), encoding_stream_coding_system ＠＠ -1153,6 +1164,8 ＠＠ { codesys = Fget_coding_system (codesys); process = get_process (process); + CHECK_LIVE_PROCESS (process); + set_decoding_stream_coding_system (XLSTREAM (XPROCESS (process)->coding_instream), codesys); return Qnil; ＠＠ -1166,6 +1179,8 ＠＠ { codesys = Fget_coding_system (codesys); process = get_process (process); + CHECK_LIVE_PROCESS (process); + set_encoding_stream_coding_system (XLSTREAM (XPROCESS (process)->coding_outstream), codesys); return Qnil; ＠＠ -1527,7 +1542,7 ＠＠ if (network_connection_p (proc)) error ("Network connection %s is not a subprocess", XSTRING_DATA (XPROCESS(proc)->name)); - if (!PROCESS_LIVE_P (proc)) + if (!PROCESS_LIVE_P (XPROCESS (proc))) error ("Process %s is not active", XSTRING_DATA (XPROCESS(proc)->name)); ＠＠ -1883,7 +1898,7 ＠＠ p->tick++; process_tick++; } - else if (!NILP(p->pipe_instream)) + else if (PROCESS_LIVE_P (p)) { Fkill_process (proc, Qnil); /* Do this now, since remove_process will make sigchld_handler do nothing. */ ＠＠ -1915,7 +1930,7 ＠＠ { if (network_connection_p (proc)) Fdelete_process (proc); - else if (!NILP (XPROCESS (proc)->pipe_instream)) + else if (PROCESS_LIVE_P (XPROCESS (proc))) process_send_signal (proc, SIGHUP, 0, 1); } } ＠＠ -1978,6 +1993,7 ＠＠ syms_of_process (void) { defsymbol (&Qprocessp, "processp"); + defsymbol (&Qprocess_live_p, "process-live-p"); defsymbol (&Qrun, "run"); defsymbol (&Qstop, "stop"); defsymbol (&Qopen, "open"); ＠＠ -1991,6 +2007,7 ＠＠ #endif DEFSUBR (Fprocessp); + DEFSUBR (Fprocess_live_p); DEFSUBR (Fget_process); DEFSUBR (Fget_buffer_process); DEFSUBR (Fdelete_process);

>>>>> "Ben" == Ben Wing <ben(a)666.com&gt; writes: Ben> If you want to be more adventurous, I'd suggest some more Ben> general changes to make these type errors clearer. I've Ben> always hated these. For example: I've always hated them, too. But I have on occasion written code to parse the *Messages* buffer for these error messages; somebody may actually haved saved some code that does that. Somehow this should be configurable. BLUE SKY ALERT: Some day these things should be gettext-ized anyway. Lots of Japanese don't understand that message no matter how good the English is ;-) We should think about how the message catalogs should be done; can we really use gettext? Do we want multilingual capabilities (same process using multiple languages---I have been in the situation of trying to figure out Japanese errors from Mule code and would love to have that capability when the catalogs are available, but it's probably hard to do). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

>>>>> "Ben" == Ben Wing <ben(a)666.com&gt; writes: Ben> Implementing message translation is not that hard. What I have in mind is not just gettext-izing everything in the XEmacs core sources. I currently believe that to be unacceptable (see Jan's message for the pitfalls in I18N; it's worse for M17N). I think really solving this problem needs a specifier-like fallback mechanism (this would solve Jan's example because you could query the text-specifier presenting the question for the affirmative and negative responses, and the catalog-building mechanism would have checks to make sure they were properly set, perhaps a locale (language) argument), and gettext is just not sufficient for that.

At a minimum, we need to implement gettext for Lisp packages. (Currently, gettext is only implemented for C AFAIK.) But this could potentially cuase more trouble than it's worth. Ben> A lot depends on priority: How important do you think this Ben> issue is to your average Japanese/Chinese/etc. user? Which average Japanese (etc) user? The English-skilled (relatively) programmer in the free software movement, or my not-at-all-competent undergrad students who I would love to have using an Emacs? This is a really important ease-of-use issue. Realistically, for Japanese, it's low priority. The Japanese team in the GNU Translation Project is doing very little AFAIK, so even if the capability were there, I doubt the message catalog would soon be done. But I think that many non-English speakers would find it very attractive, and for many languages there are well-organized and productive translation teams. I suspect that if the I18N facility were well-designed, many Western European languages would have full catalogs within a year (granted, they are the ones where it's least needed :-( ). Personally, I think doing it well is hard, and of little benefit to _current_ core XEmacs constituency. I think doing a good job, with catalogs, would be very attractive to many non-English-speaking _potential_ users. Ben> How does it compare to some of the other important Mule Ben> issues that Martin and I are (trying to work) on? I don't know what you guys are _trying_ to work on. Everything in the I18N section of "Architecting XEmacs" is red-flagged. OTOH, it's clear from your posts that you are overburdened, so I can't read priority into the fact that you've responded to specific issues in the past.

What I see as Mule priorities (in rough benefit order, I am not taking account of difficulty, nor the fact that some - eg 8 & 10 - will probably come as packages): 1. Fix the autodetect problem (by making the coding priority list user-configurable, as short as he likes, even null, with "binary" as the default). 2. Document the language environments and other Mule "APIs" as implemented (since there is no real design spec). Check to see how and where they are broken. 3. Make the Mule menu useful to non-ISO-2022-literate folks. 4. Redo the lstreams stuff to make it easy and robust to "pipeline", eg, libz | gnupg | jis2mule. 5. Make Custom Mule-aware. (This probably depends on a sensible fonts model.) 6. Implement the "literal byte stream" memory feature. 7. Study the FSF implementation of Mule for background for 7 & 8. 8. Identify desirable Mule features (eg, i18n-ized messages as above, collating tables by language environment, etc). (New features might have priority as high as 9.) 9. Specify Mule UIs, APIs, etc, and design and (re)implement them. 10. Implement the 8-bit-wide buffer optimization. 11. Move the internal encoding to UTF-32 (subject to Olivier's caveats regarding compose characters), with the variable-width char buffers using UTF-8. 12. Implement the 16- and 32-bit-wide buffer optimizations.

There's surely other stuff I've forgotten.

Ben> The big question is, would you be willing to help do the Ben> actual implementation, to "be my hands"? Sure, subject to the usual caveat that I'd need to be convinced it's worth doing and a secondary caveat that I am not an experienced coder.

-- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

>>>>> "Ben" == Ben Wing <ben(a)666.com&gt; writes: Ben> "Stephen J. Turnbull" wrote: >> What I have in mind is not just gettext-izing everything in the >> XEmacs core sources. I currently believe that to be >> unacceptable Ben> I don't quite understand. Could you elaborate and give some Ben> examples? Examples? Hmm. First, there's the surface of Jan's y-or-n-p example. You have to coordinate the translation of the message string and the response prompt. This is handled by y-or-n-p itself (I see that we already do have gettext for Emacs Lisp, that's nice to know). Except that it's not really handled by y-or-n-p. There's no reason to suppose that somebody writing a Lisp package would necessarily use the XEmacs domain (in fact, due to the way gettext binds text domains---if I understand that correctly---we don't want that to be the case, because it means that every time a Lisp package is updated the whole XEmacs catalog must also be updated). So which domain gets used for the message string? In the current implementation, it is the domain of y-or-n-p. So packages with their own domain won't get y-or-n-p prompts correctly translated. But that means that the package should do its own translation. But now you're applying gettext to the same string twice; you just have to pray the that translator upstream doesn't collide with an English string that's in the XEmacs domain. (The gettext docs mention the similar problem of English words with multiple meanings that must map to different words in the target language; this can be disambiguated by various trickeries in forming the strings ... but only if you "own" them, which in the multi-domain, interated gettext example you do not.) AFAICT this means that you must never pass untranslated strings across public APIs, but this may or may not be reasonable, and certainly is inconvenient. Next, we have to translate the possible answer strings to match the language being passed by the user. This is presumably OK here, because it's done by y-or-n-p. But what if y-or-n-p returned a string rather than a boolean? Then we would need to coordinate the presentation of the prompt (done by y-or-n-p) and the translation of the possible answer strings (done by the caller). This can in fact be done using dgettext with the XEmacs domain, but you must know that y-or-n-p is in the XEmacs domain. This is not necessarily going to be obvious, and it might very well be that sets of related packages might have the same domain, so you wouldn't necessarily know which domain is appropriate by looking at the requires. And what happens if one domain does supply translations for a language and the other does not? AFAIK, gettext has no way to find out if this is the case. But you might very will prefer a global fallback to English if substantial phrases are drawn from both domains, while you might prefer string-by-string fallback if the main text is translated and only a few words are left to fallback to English. Aside from confusing users, this puts a great burden on programmers. Programmers need to know about the status of the domains of packages they use as well as the XEmacs domain; they need to program defensively against the possibility that some package they use will become gettext-ized, or the translation projects will be out of synch (some teams will do the calling package first, others will do the caller package first). I don't think anybody will use gettext in these circumstances. At least not after they get the first bug report that "XEmacs is stuck in an infinite y-or-n-p loop and I can't get out." Ben> I wrote this awhile ago: "There you go again." Not anywhere I could see it! (At least, it doesn't look familiar and grepping the archives doesn't turn it up.) OK, you win. Subscribe me to xemacs-review. Or whatever seems appropriate. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

> Ben> The big question is, would you be willing to help do the > Ben> actual implementation, to "be my hands"? > > Sure, subject to the usual caveat that I'd need to be convinced it's > worth doing and a secondary caveat that I am not an experienced coder. If you'll implement it, I'll design it. It's more a case of will on your part than anything else. I can give you instructions sufficient enough to match your level of expertise.

Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; writes: > Gunnar Evermann <ge204(a)eng.cam.ac.uk&gt; writes: > > > * process.c (Fprocess_input_coding_system): check whether process > > is still alive > > Approved. Recommened for 21.1. I think we should still apply the above patch to 21.1.

1999-12-18 Gunnar Evermann <ge204(a)eng.cam.ac.uk&gt; * process.h (PROCESS_LIVE_P): Modify to take a Lisp_Process instead of a Lisp_Object as argument to make it consistent with the other LIVE_P macros. (CHECK_LIVE_PROCESS): New macro. * process.c: Declare Qprocess_live_p. (Fprocess_live_p): New function. (create_process): Use PROCESS_LIVE_P. (read_process_output): Ditto. (set_process_filter): Ditto. (Fdelete_process): Ditto. (kill_buffer_processes): Ditto (Fprocess_input_coding_system): Check whether process is still alive (fix PR#1061). (Fprocess_output_coding_system): Ditto. (Fprocess_coding_system): Ditto. (Fset_process_input_coding_system): Ditto. (Fset_process_output_coding_system): Ditto.