World: r3wp

The Red binding doesn't provide the #defines yet to configure that, 
but they're easy to add

The only requirement for NTLM seems to be that your cURL is built 
with SSL support:

http://curl.haxx.se/docs/features.html

I've added defines for authentication methods to the cURL binding 
that you can use with the curl-set function to configure NTLM

Thanks I will try out soonest.

has the Red google group moved somewhere else, don't see any activity

It's still at
http://groups.google.com/group/red-lang

just quiet at the moment

?

Yes.

Also:
https://twitter.com/#!/red_lang/status/118396786737033216

thanks

Implemented horizontal and vertical box layouts in the GTK binding

Added a widgets overview to the examples

Here's the current one:

gtk-view window [
	gtk-position-center
	"Widgets Overview"
	icon "Red-48x48.png"
	vbox [
		label "Vertical box"
		fixed [
			label "Fixed layout"
			5 25  button [50 25  "Quit" :gtk-quit]
		]
		hbox [
			label "Horizontal box"
			button ["Fill"] yes
			button "Expand"
			button ["Fixed"] no
		]
		vbox [
			label "Vertical box"
			button ["Fill"] yes
			button "Expand"
			button ["Fixed"] no
		] yes
	]
]

Works fine on Win7. What are the yes/no keywords for?

I'm about to define names for them. :-) They were the most practical 
way to construct a dialect that results in proper settings for filling 
or fixating a box cell

Did you resize the window? Then the working becomes clear

Not many floats are used in GTK, but I need them for layout alignment

Ok, I see now what they are used for. :-) Are the extra brackets 
around some button titles a special convention you're using?

Hmm, no floats in Red/System will have to come anyway, no? :-)

eh, minus "no" in above sentence :-)

Normally a button needs more than one parameter, so it would always 
have brackets. But here they're only used as examples, so they only 
have a display text and the brackets can be left out

I left them in for a while to make the separation with the optionally 
following layout parameters clearer, but in the latest version I 
reconsidered

Anyone knows where to find exhaustive lists of invalid UTF-8 encoding 
ranges?

I am calculating them by hand, so I might miss some.

C0, C1, F5-FF must never occur in UTF-8.

80-BF are continuation bytes.

Is that what you are after?

Yes, but I was searching for an exhaustive list of rules.

RFC3629 has a (non-normative) ABNF, if I remember correctly.

http://tools.ietf.org/html/rfc3629#section-4s

Here are the parse rules I came up with so far: https://gist.github.com/1278718

I think I am missing some overlong combinations.

I am also unsure of the valid range of the 2nd byte in the four-bytes 
encoding.

one-byte-codepoint: charset [#"^(00)" - #"^(7F)]

Right, fixing that.

tail-bytes: charset [#"^(80)" - #"^(BF)]

two-byte-codepoint: reduce [charset [#"^(C2)" - #"^(DF)] tail-bytes]

tail-bytes == cont-byte

three-byte-codepoint: reduce [
  #"^(E0)" charset [#"^(A0)" - #"^(BF)] cont-byte
| charset [#"^(E1)" - #"^(EC)"] 2 cont-byte
| #"^(ED)" charset [#"^(80)" - #"^(9F)] cont-byte
| charset [#"^(EE)" - #"^(EF)"] 2 cont-byte 
]

four-byte-codepoint: reduce [
  #"^(F0)" charset [#"^(90)" - #"^(BF)] 2 cont-byte
| charset [#"^(F1)" - #"^(F3)"] 3 cont-byte
| #"^(F4)" charset [#"^(80)" - #"^(8F)] 2 cont-byte
]

Thanks, I see that everything I need is in http://tools.ietf.org/html/rfc3629#section-4

BrianH: what was the CureCode ticket where you've summed up the word! 
Unicode parsing rules?

http://issue.cc/r3/1302for the ASCII range in R3. The R3 parser 
tends to be excessively forgiving outside the ASCII range, accepting 
too much, though I haven't done the thorough test.

You might also consider looking at the source of INVALID-UTF? in 
R2, which is MIT licensed from R2/Forward.

It would still be a good idea to review the Unicode standard to determine 
which of the characters should be treated as spaces, but that would 
still be a problem for R3 because all of the delimiters it currently 
supports are one byte in UTF-8 for efficiency. If other delimiters 
are supported, R3's parser will be much slower.

Thanks. For whitespaces, I have already taken higher Unicode codepoints 
into account (from this list: http://en.wikipedia.org/wiki/Whitespace_character).

Completely forgot about INVALID-UTF? :)

After having a quick glance at it, at least for utf8 it's quite basic 
and does not take any of the above overlong combinations into account.