World: r3wp

I'm using these rules in my server side implemention to the top command


one-line-rule: [copy line thru {^/} ( if line = ".^/" [ line: join 
"." line ] write-client line)]

header-rule: [copy header thru {^/^/} (write-client header write-client 
)]

msg is the email message including header and body
lines is the number of lines requested by the TOP command

parse msg compose [ header-rule (lines) one-line-rule ]


Now, I can't check the parse syntax as rebol.com is down, but I seem 
to always get the whole email with my header-rule and not just the 
header.

correction: header-rule: [copy header thru {^/^/} (write-client header)]

the rules work when tested at the console.  So, I'm thinking something 
else is wrong.

The email is obtained by reading from a port in binary mode, so could 
this be due to the lack of line ending conversion ?

From a unix system to windows32?

Hi Graham. Line ending in Internet protocols = Apples; Line/Paragraph 
representation in text files = Oranges. :-)

Best not to compare them for this task.  As far as I've seen, Internet 
protocols have an on-the-wire line ending of CRLF.  So yes this is 
very likely a problem with your parse rules.

With the port in binary mode - you must use CRLF to identify/transmit 
line endings.

Hi Brett.  Do you then see a problem with me parse rules?

seems link to get all possible raw line endings something  like  
copy line thru [ 1 2 ["^J" | "^M"]]   might work

my one-line-rule seems to work already ..

copy header thru [ 2 [ "^J" | "^M"] ] ... ?

unix would be a single "^J"

header is separated from body by one blank line.

So, I need to look for two consecutive line endings to find the end 
of the header

yes ,  my rule was for a single lin as in your first code  sample

is ^J the line feed ?

copy header ti ["^J^J" | "^M^M" | "^M^J^M^J"]

^J same as ^/

>> header-rule: [copy header thru ["^J^J" | "^M^M" | "^M^J^M^J"] 
 (write-client header)]
== [copy header thru ["^/^/" | "^M^M" | {^M
^M
}] (write-client header)]
>> parse m header-rule
** Script Error: Invalid argument:

 |


** Near: parse m header-rule

try {^M^/^M^/}

not that it shoulf matter

same problem

it is interperting the third newline ... odd  buggy odd

parse all?

os use |  2 CRLF

>> unix: [ copy header thru "^J^J" ]
== [copy header thru "^/^/"]
>> msdos: [ copy header thru "^/^/" ]
== [copy header thru "^/^/"]
>> parse m [ [ unix | msdos ] ( write-client header ) ]

ms dos  not correct

is that correct rule for unix ?

yes

what's msdos ?

mac ^M^M  dod ^M^J unix ^J

mac is a single ^M for a single line

[2 "^/" | 2 "^M" | 2 CLRF]

>> parse m [ [2 "^/" | 2 "^M" | 2 crlf ] ( write-client header ) 
]
== false

dos is : join crlf crlf .. isn't it ?

... copy haader theu ...

parse m [ copy header thru [2 "^/" | 2 "^M" | 2 crlf ] ( write-client 
header ) ]
** Script Error: Invalid argument: 2
 | 2 crlf

copy header [thru 2 "^/" | thru 1 "^M" | thru 2 crlf]

it annoys me the to/thru does not distribure over the block of ORs

me too ...

off to the coast for the weekend, got to pack

ok.

This rule seems to now work for me ...


  header-rule:  [ [ copy header thru {^M^J^M^J} | copy header thru 
  {^/^/} ] (write-client header )]

not sure if the second rule is needed ...

;I tend to use charsets as a way of skipping 'thru while looking 
for multiple possibilities:
line-end: charset [#"^/" #"^M"] ; etc
line: complement newlines

parse m [copy header [some [some line line-end]]]

a way of skipping
 -> "an alternative to"

is it faster?

It's hard to compare when 'thru doesn't fork.

or is it slower ?

For what it's worth, my benchmarks show it to be quick, but my benchmarks 
tend to be crude...