[auto-reply] Re: Re: [boost] Re: anti formatter

From: x.lsi.maillard_at_[hidden]
Date: 2001-12-25 17:56:03

                THIS IS AN AUTOMATICALLY GENERATED REPLY
                   Your mail to me has been discarded

Hi! You have reached the mail filter of one Richard Gooch. I'm sorry
to have to do this to you, but I am now filtering my email to combat
the flood of junk email (spam) that I receive. I'm fed up with having
to waste my time sifting through junk email. This filter also protects
me from certain types of mailbombing attacks.

I received an email from you, but my mail filter doesn't think you
sent it to me personally. This may be because I am on some mailing
list I'm not aware of. It may also have come from a mailing list I
*am* subscribed to, but the list adminstrators have started fiddling
with (breaking) the listserver.
APOLOGIES if the mailing list is genuine (i.e. not a spam list). If
you receive this reply because of a message you sent to a genuine
mailing list, please send me a message (telling me which mailing list
I'm on) with the following in the subject line:

293977

This is my password of the week. My mail filter will then let me see
the message. NOTE: the password MUST be in the subject, not the body.
I will then add a rule for the mailing list (or unsubscribe myself if
I don't wish to be subscribed) so that this won't happen again. I
apologise to people subscribed to mailing lists if this message is
sent to the whole list; I have taken considerable care to make sure
that mailing lists I want to be subscribed to are not affected by my
spam filter.

NOTE TO BULK EMAIL ADVERTISERS, SPAMMERS AND OTHER PARASITES: if you
manage to break through my filtering, rest assured that I will ignore
your message on principle. Future mails will be automatically deleted.
Unsolicited commercial email is unwelcome and costs *me* time to deal
with.

The message you apparently sent to me follows:

>From fxgs  Tue Dec 25 23:56:02 2001
Return-Path: <sentto-1234907-19302-1009184468-x.lsi.maillard=wanadoo.fr_at_[hidden]>
Delivered-To: fxgs_at_localhost.hometranet.home
Received: from 192.168.1.2 [192.168.1.2]
        by localhost with POP3 (fetchmail-5.9.0)
        for fxgs_at_localhost (single-drop); Tue, 25 Dec 2001 23:56:02 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
        by mail.hometranet.home (Postfix) with ESMTP id 2A6472B075
        for <fxgs_at_localhost>; Tue, 25 Dec 2001 18:49:57 -0500 (EST)
Received: from pop.wanadoo.fr
        by localhost with POP3 (fetchmail-5.7.4)
        for fxgs_at_localhost (single-drop); Tue, 25 Dec 2001 18:49:57 -0500 (EST)
Received: from apeiba.wanadoo.fr (192.168.156.17) by ms4-2.wanadoo.fr; 24 Dec 2001 10:06:21 +0100
Received: from n34.groups.yahoo.com (216.115.96.84) by apeiba.wanadoo.fr; 24 Dec 2001 10:06:18 +0100
X-eGroups-Return: sentto-1234907-19302-1009184468-x.lsi.maillard=wanadoo.fr_at_[hidden]
Received: from [216.115.97.189] by n34.groups.yahoo.com with NNFMP; 24 Dec 2001 09:01:08 -0000
X-Sender: kostya_at_[hidden]
X-Apparently-To: boost_at_[hidden]
Received: (EGP: mail-8_0_1_3); 24 Dec 2001 09:01:07 -0000
Received: (qmail 31399 invoked from network); 24 Dec 2001 09:01:05 -0000
Received: from unknown (216.115.97.172)
  by m3.grp.snv.yahoo.com with QMQP; 24 Dec 2001 09:01:05 -0000
Received: from unknown (HELO sigma.star.spb.ru) (212.113.110.20)
  by mta2.grp.snv.yahoo.com with SMTP; 24 Dec 2001 09:01:05 -0000
Received: from black.star.spb.ru (black.star.spb.ru [212.113.110.10])
        by sigma.star.spb.ru (8.10.2/8.10.2) with ESMTP id fBO913J60933
        for <boost_at_[hidden]>; Mon, 24 Dec 2001 12:01:03 +0300 (MSK)
Received: from star.spb.ru (KOSTYA [212.113.110.72]) by black.star.spb.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
        id Z2CR03FD; Mon, 24 Dec 2001 12:01:00 +0300
Message-ID: <3C26EEFF.9040801_at_[hidden]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913
X-Accept-Language: en-us
To: boost_at_[hidden]
References: <9vvim4+qn7s_at_[hidden]>
From: Kostya Altukhov <kostya_at_[hidden]>
X-Yahoo-Profile: mindlesskostya
MIME-Version: 1.0
Mailing-List: list boost_at_[hidden]; contact boost-owner_at_[hidden]
Delivered-To: mailing list boost_at_[hidden]
Precedence: bulk
List-Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
Date: Mon, 24 Dec 2001 12:01:51 +0300
Subject: Re: [boost] Re: anti formatter
Reply-To: boost_at_[hidden]
Content-Type: multipart/alternative;
 boundary="------------090107050309010703050803"
Status:  O

--------------090107050309010703050803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

rogeeff wrote:

>>All macro solutions require recompilation, therefore they
>>are not acceptable for real-world needs.
>>Everything that requires recompilation is not acceptable.
>>
>Macros are used only as a helper facility for format *definition*. 
>You can always have separate mechanism to support runtime cjange of 
>the format.
>
It should be possible to update format definitions and add new
format definitions without recompilation.

It is often not acceptable if translating messages to another language
requires recompilation of the executable. However, translating
messages often requires modifications in format definitions,
such as changing parameter order.

That's why in many international applications format definitions
are stored in separate places (eg. text files), and it is possible
to modify these text files without updating executable.

I see no way of supporting this approach using streams
without something like submitted formatter.

Best wishes,
Kostya

--------------090107050309010703050803
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>

rogeeff wrote:<br>
<blockquote type="cite" cite="mid:9vvim4+qn7s_at_[hidden]">
  <blockquote type="cite">
    <pre wrap="">All macro solutions require recompilation, therefore they<br>are not acceptable for real-world needs.<br>Everything that requires recompilation is not acceptable.<br></pre>
    </blockquote>
    <pre wrap=""><!---->Macros are used only as a helper facility for format *definition*. <br>You can always have separate mechanism to support runtime cjange of <br>the format.</pre>
    </blockquote>
    <blockquote type="cite" cite="mid:9vvim4+qn7s_at_[hidden]">
      <pre wrap=""></pre>
      </blockquote>
It should be possible to update format definitions and add new<br>
format definitions without recompilation.<br>
      <br>
It is often not acceptable if translating messages to another language<br>
requires recompilation of the executable. However, translating<br>
messages often requires modifications in format definitions,<br>
such as changing parameter order.<br>
      <br>
That's why in many international applications format definitions<br>
are stored in separate places (eg. text files), and it is possible<br>
to modify these text files without updating executable.<br>
      <br>
I see no way of supporting this approach using streams<br>
without something like submitted formatter.<br>
      <br>
Best wishes,<br>
Kostya<br>
      <br>
      

<br>
<tt>
Info: <a href="http://www.boost.org">http://www.boost.org>&nbsp; Send unsubscribe requests to: &lt;mailto:boost-unsubscribe_at_[hidden]&gt;</tt>
<br>

<br>
<tt>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.</tt>
</br>

</body>
      </html>

--------------090107050309010703050803--