World: r3wp

This is about the HTTP scheme, but I can't find a group for R2 schemes.


Does anyone have a patch for the HTTP scheme that handles 204 (No 
Content) responses where no headers are returned? The standard scheme 
throws an error as there are no headers to parse. Here is the 'success 
case handler:

        success: [
            headers: make string! 500

            while [(line: pick port/sub-port 1) <> ""] [append headers join line 
            "^/"]

            port/locals/headers: headers: Parse-Header HTTP-Header headers
            port/size: 0

            if querying [if headers/Content-Length [port/size: load headers/Content-Length]]

            if error? try [port/date: parse-header-date headers/Last-Modified] 
            [port/date: none]

            port/status: 'file
    ]


For anyone familiar with the scheme, would the proper behavior be 
to set all related 'port fields to zero or none? e.g.

            port/locals/headers: headers: none
            port/size: 0
            port/date: none
            port/status: none

And should it only do that in case of a 204? It's not clear if a 
304 response may also be affected.

RFC2616 says 304 MUST inlcude a date field.

If it's just 204, it looks like the cleanest solution would be to 
add a success-204 response action block.

The main problem with R2's HTTP scheme is, that it does not provide 
response-code even in cases where it should, like:

port: open/direct some-url


Without available response-code you have no chance to differentiate 
responses like 204 or 205 which has special meaning =

http://benramsey.com/archives/http-status-204-no-content-and-205-reset-content/

I think the most practical solution is to provide response-code in 
port/locals and return none for 204 and 205.

I suppose that server should provide date on 304 response, not client.

Also when you are using just:

new-content: read url-with-no-content-response


using error chatching and parsing the error message should be enough.

Thanks Oldes. I can handle it simply for now, and maybe this can 
be addressed more thoroughly in R3.

Tonight's Moment of REBOL Zen:

>> same? :empty? :tail?
== true

Wouldn't it be better to define EMPTY? as:

	empty?: func [
		series
	][
		tail? head series
	]

They are different and not backward compatible.
>> b: [1 2 3]
== [1 2 3]
>> c: skip b 3
== []
>> empty? b
== false
>> empty? c
== true
; c references to b, b is not empty, but c is.

in R3:
>> same? :empty? :tail?
== false

but the result is same.. for me it's fine as it is.

On R3, TAIL? is a redefinition of EMPTY? with fewer supported types. 
Internally they are the same function code. This was done in order 
to have one version that is more flexible, and another that triggers 
useful errors.

Getting an error when sending bulk email: 

** User Error: Server error: tcp 501 <>: missing or malformed local 
part
** Near: insert smtp-port reduce [from address message]

The number of email addresses is 52. 

I can send using the same settings one at a time and I have succeeded 
sending  8 addresses at one time. But it bombs on my whole list.

Found a bad address thats probably the problem....

Did you try send/only ?

Has anybody built a binary diff/patch function set?

If I want to store some fairly big data as undo information, it seems 
to make sense to store it as a diff, and load the data that I want 
to undo/redo to. Then it would also be possible to store the entire 
changes sequence to disk.

binary diff can be expensive - if you control the application that 
modifies the data, can you log the changes instead?

if not, you probably want something like this: http://publications.cse.iitm.ac.in/734/

I did some a long time ago Henrik. It isn't fast enough to work on 
data of any size though. I can dig it out if you're interested. Can't 
remember what state of completion it's in.

Any *significant* size that is.

It's also high space complexity.

The biggest object here is around 4 MB or 550 kb compressed. I expect 
that binary diff would only be used during load and save, and then 
keep full objects in memory.

Mine will be way too slow for that.

My original goal was not binary diffs, but diffing blocks.

you are right. I looked into it and it looks to be way too slow, 
so I'm trying another approach.

>> negate 2 + - 2
== 0
>> - 2 + - 2
== -4

Bug?

Isn't unary minus introducing a third semantic rule? Functions are 
prefix, operators are infix with precedence over functions. And then 
unary minus is prefix with precedence similar to operators?

w> - (2 + (- 2))
== 0
w> (- 2) + (- 2)
== -4

Question is, how would we read
- 2 + - 2

It does correctly I think, here is the trace log:
>> - 2 + - 2
Trace:  - (word)
Trace:  2 (integer)
Infix:  op (add)
Trace:  - (word)
Trace:  2 (integer)

I'm asking, if unary minus should work as if being defined like this:

>> set '- :negate

no,  AFAICT the unary minus is applied exactly like all operator 
precedence (from left to right).


negate and  "-"  do not have the same precedence, as you noted, so 
its normal for:
    >> negate 2 + - 2    
and
    >> - 2 + - 2
to give different results.

Ok, intensional then. I'm surprised.

You shouldn't old pal :-)

Is unary minus the only prefix thing, that has same precedence as 
operators?

:) Sometimes I feel, I have no clue about this language. ;)

actually, unary minus has an higher precedence than other ops

Functions with literal arguments works about the same.

>> f: func ['a] [probe a]
>> f 2 + 2
2
== 4

So f gets the value 2 in this example.

Complicated rules! ;)

because functions with literals stop the evaluation flow

yeah

Tonight's Moment of REBOL Zen:

>> switch/default 'a [a 1] 2 
== 2

What's the insight here?

>> switch/default 'a [a [1]] 2
== 1

so what ?

Isn't it strange, that if the value being searched for (in this case 
a) is found, and the next item in the block isn't a block, then it 
fails to defaul?

No.

*default*