World: r3wp

I just wanted to demonstrate the isomorphism of the two cases, so 
that everybody could see it.

NEW-LINE is magically delicious to me. I do quite a bit of code and 
data generation, so I use it a lot.

By dialected, I mean the arg to the func is a dialect. When discussed 
before, one question was whether to make the block a separate arg.

a: [a b c d e]
b: [1 2 3 4 5]
new-lines [
    all on in a
    on in b every other item
]


Ladislav is right on naming, that it violates the verb-first convention.

I called my dialected version NEW-LINES, to match the standard func, 
then tried LINE-MARKERS. I don't have a problem with adding SET- 
to the head though.

Ok, thanks Gregg. Cool with such dialect to make newlines in blocks.

Tonight's Moment of REBOL Zen:

>> s: [1 2 3]
== [1 2 3]
>> t: tail s
== []
>> remove/part s 2
== [3]
>> back t
== ** Script Error: Out of range or past end
>> index? back t
== 2
>> index? back back t
== 2
>> index? back back back t
== 1

Zen in this case just being R2's bad behavior with out-of-bounds 
references. You forgot this:
>> index? t
== 4
This is the only part of the behavior of INDEX? that makes sense.

>> s: [1 2 3]
== [1 2 3]
>> t: tail s
== []
>> index? t
== 4
>> remove/part s 2
== [3]
>> index? t
== 2

Never mind, INDEX? just sucks in R2 with out-of-bounds refs. That 
is part of what we tried to fix in R3.

Regarding the "comparison is meaningless", or "SORT doesn't have 
that luxury though, because it is designed to not fail" philosophical 
arguments. They, in fact, are not valid at all. The facts are different.


* For large lists which are frequently searched it *is* useful to 
have them sorted. 

** The reason is, that it is much easier to perform searches in a 
sorted list, than in an unsorted list.

** The "meaning" of the sort order is to facilitate searches, no 
other meaning is needed. (it is like the zero case, the meaning of 
zero is to facilitate the positional representations of numbers, 
no other "meaning" is needed)

* The whole "sorted list business" needs comparison functions (for 
searching, etc.)


The above "meaning" is one meaning comparisons do have. It suffices 
to prove, that comparisons are not "meaningless". (for that it would 
be absolutely necessary, that we can find no meaning at all)

It shouldn't be possible to order pairs, like complex numbers.

 - the set theory uses the axiom, that can be formulated so, that 
 it should be possible to sort any set so, that it becomes well ordered. 
 Of course, it is useful to have even partial order, like the one 
 you mentioned, but nobody said it was the only ordering possible.

The only thing not possible is to sort the complex numbers so, that 
the ordering is in some useful way "compatible" with arithmetic operators.

The problem of SORT, which I am not sure we are able to address, 
is the Unicode-aware sort ...

Individual nations have individual collating sequences - norms prescribing 
how strings shall be ordered. Thus, "Unicode-aware sort" is something 
like a unicorn.

It definitely makes sense to me to expose SORT's basic grouping or 
sorting mechanism, so you can build your own sorter around its logic. 
I'm not sure I care about what datatypes come first or which order 
the "meaningless values" come in, just as long as it's consistent 
with SORT.

You can just use SORT to access SORT's sorting mechanism, no?

(Obvious performance implications left aside.)

Ladislav, you are arguing that those comparisons have *use*, not 
*meaning*. They definitely have *use* in SORT, mostly as placeholders 
and fallbacks, so that SORT can be used as you describe above on 
heterogeneous data. But that doesn't mean that those comparisons 
have meaning.

SORT needs there to be an ordering between pieces of data in order 
to sort them. Whether or not that ordering has meaning, SORT needs 
it to exist because it need to use it. So in the cases where there 
is no ordering that has meaning, SORT uses ordering methods that 
don't have meaning. They are useful, but not meaningful.

SORT itself is useful for the reasons you give above.

They definitely have *use* in SORT

- as far as I am concerned, I find it "meaningful" to implement a 
feature of the language that is "useful" (but that may be just me)

But there are much more important issues:


* the users shall be able to use their own sorting functions applying 
useful comparison operators (SORT has known issues)

* the users shall be able to utilize the advantages of having the 
data sorted, which, again, is possible if the compatible comparison 
functions are available

Regarding the "meaning" of ordering. If we examine some of the orderings 
you eventually might find "meaningful" we can come to the conclusion 
that they are not the only alternatives possible, and thus are actually 
"meaningless" as well in that respect. To support the "most meaningful" 
ordering for the specific data SORT supports the /COMPARE refinement, 
which proves the point, that even the ordering one user finds "meaningful" 
may lack "meaning" for another.

For example, I bet that the order REBOL uses for strings currently 
is "meaningless" for Pekr, who would prefer something more "meaningful".

Is there a way to retrieve the name of an object that is referenced 
by another word?
layout  [ a_field: field [ ]  ]
b:  a_field
....
What I want is to somehow get "a_field" given b.

Is there a way to retrieve the name of an object that is referenced 
by another word?

 - only if you provide some (keep track of such things in your program)

Is that right. I would think that it is stored somewhere in the system.

for example, it is quite common to do something like:

a: make object! [name: 'a]

You can even define a function doing that for you.

Yes, I see that. I'll just go that route then. Thanks Ladislav.

James, in th case of LAYOUT dialect you can get the name this way:

>> b/var
== a_field
>> type? get b/var
== object!

etc.

Cyphre, thanks a milion!

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.