Fw: FWD: from Jonathan Cunningham about Macintosh implementations 
Author Message
 Fw: FWD: from Jonathan Cunningham about Macintosh implementations

Aaron asked me to try posting this again; apparently
the gateway didn't recognise the "To: "line which (I
just checked) probably contained:

This is one of the (two?) common formats for putting
human readable names as well as machine readable
addresses on the "To:" line. My mail reader just
displays the bit which is not in < >. (The other
common format I know of has the human-readable bit
in parantheses, and the machine-readable bit bare.)

Apologies to those on the mailing list (like me) who
will thus get the following wibble twice.
  --jlc

(If this doesn't work, I guess I'll have to start
typing in pop-forum by hand, instead of letting the
software do it.)

Quote:
-----Original Message-----


Date: 30 April 2000 12:12
Subject: Re: FWD: from Jonathan Cunningham about Macintosh implementations

>(Another opportunity to test your mail gateway ;-)

>The following is actually a more general point, which is
>still relevant to poplog now.

>>...
>>Another less obvious point is the large collection of strings for
>>error messages in the poplog system source files, e.g. things
>>like this in $popsrc/list_hdtl.p

>>    mishap(item, 1, if item == [] then 'NON-EMPTY LIST NEEDED'
>>                    else 'LIST NEEDED' endif)

>>We discussed moving all those hundreds of strings out into a file,
>>with numbers or labels and having an error mechanism which found the
>>appropriate string when an error occurred. We decided against that

>There is another advantage to removing error messages from the
>source code ... internationalisation.

>In developing a C++ application, modern tools make this relatively
>simple to do. (The strings aren't stored in a file, but in
>a "string table".)

>Why? So it is very easy to produce different national versions of
>the product. You don't need multiple versions of the source; just
>link with a different string table. (Actually, in a graphical UI
>you may need also to take into account the length of the strings.)

>This is not so important for something like poplog as it would be
>for a consumer product but even so, just conceivably, people might
>like to get messages in their own language.

>But, nowadays, I still wouldn't use error codes. Instead, I would
>redefine prmishap to look up the error string in a separate
>table. This table could be in an ordinary library, and loaded in
>the usual way, at startup.

>There would be some work needed in extracting the initial
>set of "key" strings for the table, but after this had been done
>once, poplog could be nationalised to a new locale just by
>making a new version of the mishap-string-translation-library,
>i.e. anyone who could produce:
> [...
>  ['LIST NEEDED' 'Liste necessaire']
>  ...
>  ]
>or whatever the correct translation would be.

>This is so obvious, I wonder if it has already been done?

>Jonathan



Mon, 16 Sep 2002 03:00:00 GMT  
 Fw: FWD: from Jonathan Cunningham about Macintosh implementations

Quote:

> Date: 30 Mar 2000 15:18:36 GMT

> (Another opportunity to test your mail gateway ;-)

Now working apparently.

[JLC]

Quote:
> The following is actually a more general point, which is
> still relevant to poplog now.
> ...
[AS]
> >We discussed moving all those hundreds of strings out into a file,
> >with numbers or labels and having an error mechanism which found the
> >appropriate string when an error occurred. We decided against that

[JLC]
> There is another advantage to removing error messages from the
> source code ... internationalisation.

> In developing a C++ application, modern tools make this relatively
> simple to do. (The strings aren't stored in a file, but in
> a "string table".)

> Why? So it is very easy to produce different national versions of
> the product. You don't need multiple versions of the source; just                  
> link with a different string table. (Actually, in a graphical UI
> you may need also to take into account the length of the strings.)                  

> This is not so important for something like poplog as it would be
> for a consumer product but even so, just conceivably, people might
> like to get messages in their own language.

Yes.

The tools supporting this for developers of a system as large and
complex would have to be able to work with teams of programmers
simultaneously working on different parts of the system, perhaps
with some of them working on some files on machines at home and then
bringing them in to the office to install them.

You'd either need a tool that's guaranteed to give you a unique
error label wherever you are doing your work (e.g. something based
on your name or a code assigned to each programmer, or a label
fetched from an `error label server' across the internet), or the
labels would have to be generated when the files are installed into
the master system, or possibly when they are first compiled.

Quote:
> ...
> But, nowadays, I still wouldn't use error codes.

I assume you mean by that that you would not have error codes
printed out at run time. I agree. I assumed that when errors
occured the label or number would be used by the run-time system
to fetch a string to print, perhaps using a new procedure

    string_for_code(code, current_language)

Quote:
> Instead, I would
> redefine prmishap to look up the error string in a separate
> table. This table could be in an ordinary library, and loaded in
> the usual way, at startup.

yes. or possibly when the first error occurs!

Quote:
> This is so obvious, I wonder if it has already been done?

Probably for many multi-language systems.

Aaron
===



Tue, 17 Sep 2002 03:00:00 GMT  
 Fw: FWD: from Jonathan Cunningham about Macintosh implementations
The way I do this in C would generalise nicely to Pop.

In a C program I am writing, the messages are all literals of the form

    MM("this is a message with insert <x>")

MM is the identity macro; its purpose is to tag the message text. At some
point a tool will scan the source for all the MM messages and generate
a table mapping them to other messages (or not, as required). I'll
modify the message-reporting code to consult the table and use the
revised entry as the output. (Humans generate revised entries as
required).

This means:

(a) you don't need to faff around inventing constants and updating
header files.

(b) the messages work immediately.

(c) you can map an existing message to a different string in the same
language if you like.

(d) but the messages take up space in the executable all the time, even
if you always use French or Italian or German or Dutch or Finnish or American
spelling.

(e) the lookup is a performance overhead.

For Pop, one has the option of making MM (or however it's spelt) a syntax
word that builds the table on the fly, allocating indicies as it goes,
and arranging that it's both fast and effective.

--
Chris "why C, you cry? don't ask." Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Tue, 17 Sep 2002 03:00:00 GMT  
 Fw: FWD: from Jonathan Cunningham about Macintosh implementations
Kers says:

Quote:
>The way I do this in C would generalise nicely to Pop.

>In a C program I am writing, the messages are all literals of the form

>    MM("this is a message with insert <x>")

>MM is the identity macro; its purpose is to tag the message text. At some

It is also easy to redefine it to do other things, like using Unicode
strings instead of ASCII etc.

Quote:
>(d) but the messages take up space in the executable all the time, even
>if you always use French or Italian or German or Dutch or Finnish or
American
>spelling.

Not really a problem, nowadays, since a megabyte of string space would
correspond to a whole book of message text.

Quote:
>(e) the lookup is a performance overhead.

It's not likely to be a significant overhead.

  --jlc



Tue, 17 Sep 2002 03:00:00 GMT  
 Fw: FWD: from Jonathan Cunningham about Macintosh implementations

gateway got confused. Hoping I can prevent this being re-sent throuth
news->mail]


Date: Fri, 31 Mar 2000 22:54:36 +0100

Hi,

Following the thread on internationalization of error messages I have
a couple of comments.  First, the real challenge is to get Poplog to
generate a table of error messages - and unfortunately the new
error mechanisms are not especially helpful because error messages
get cons'd up dynamically.  (Apart from this, the new mechanisms are
superb IMHO.)

Second, the integration with Unicode appears to have halted in
mid-stream.  The low-level support is there. It would be very helpful
if one of the Poplog developers could give some pointers as to
where they wanted to get to.

I think it is also worth mentioning that now Poplog is Open Source
we ought to get some collective aims sorted out.  Internationalization
would actually be a good one - but a massive task because of the
reference material.  Anyone for automatic translation?

Steve



Wed, 18 Sep 2002 03:00:00 GMT  
 Fw: FWD: from Jonathan Cunningham about Macintosh implementations


Quote:
> Kers says:

>>(d) but the messages take up space in the executable all the time, even
>>if you always use French or Italian or German or Dutch or Finnish or
> American
>>spelling.

Embedded systems.

(And you haven't seen how long some of my messages turn out to be!)

Quote:

> Not really a problem, nowadays, since a megabyte of string space would
> correspond to a whole book of message text.

>>(e) the lookup is a performance overhead.

> It's not likely to be a significant overhead.

True, but I wanted to be honest. If the messages are warnings or worse,
you hope not to get many of them anyway ...

--
Chris "homebody" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Sat, 21 Sep 2002 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Followup to message 22.03.00 from Jonathan Cunningham (fwd)

2. Forwarding message 22.03.00 from Jonathan Cunningham

3. forwarding message from Jonathan Cunningham (with comments)

4. news-relayFrom: jlc@uk.co.bmtech (jlc (Jonathan Cunningham))

5. (Fwd) FW: Traveling-Been there, done that

6. FW: virus (fwd) -Reply

7. FW: virus (fwd)

8. Macintosh port of GNU Smalltalk ?? (fwd)

9. Macintosh implementations of Poplog or Pop11

10. Macintosh implementations of Poplog or Pop11

11. any good macintosh Scheme implementations?

12. Rexx implementation(s) for a Macintosh??

 

 
Powered by phpBB® Forum Software