World: r3wp

I'll write it up, if it's OK to copy some of your arguments from 
above into the ticket.

Anything

So, for the case of BIND [...] function the main difference is, that 
it cannot be done regardless of whether the function is running or 
not, which can be considered a security measure, then.

Yup. And BODY-OF returning an unbound copy prevents code like this:
	print get second body-of :a

PROTECT/hide doesn't affect existing bindings, so you need to be 
careful about leaking those too.

Initial version of the ticket made: http://issue.cc/r3/1893

Supporting comment added.

would it not be practical if REMOVE-EACH could /SKIP ?

nevermind. please ignore request.

remove-each [value skip] my-block [...]

ladislav, yes, saw it just now. :-)

The only function in R3 that operates that way is TRANSCODE, so as 
long as it doesn't choke on overlong combinations

#{c0ae} is an overlong encoding for #"." (#{2e}).

>> invalid-utf? #{c0ae}
== #{C0AE}

>> transcode #{c0ae}
== [® #{}]

>> transcode #{2e}
== [. #{}]

So for words, transcode is behaving strange. On the other hand, for 
strings ({"} is #{22}):

>> transcode #{22c0ae22}
== ["." #{}]

So, on R3 INVALID-UTF? flags overlong encodings? Sorry I missed that. 
Better fix the R2/Forward version accordingly.

No, it doesn't.

And we could use a ticket for the TRANSCODE bugs.

Or at least, it behaves the same as in R2.

INVALID-UTF? returns the series at the position of the first invalid 
sequence. If it doesn't flag it returns none.

If it is returning anything other than none for an overlong form, 
it is screening for overlong forms.

It is only in this particular case.

Other overlong forms are not being screened for, but one form is? 
That would also be worth a ticket.

No, that's nothing to do with overlong forms, but with PARSE in combination 
with bitsets being broken.

Which definitely is worth a ticket.

>> parse/all #{f0} reduce [charset [#{d0}]]
== true

I'm talking about the R3 version, which is a native that doesn't 
use PARSE. Do you think it's a related bug?

Mixed up R2 and R3 here.

The above is a bug in R3, in any case.

Well, if it doesn't have a ticket yet it could use one.

Ok. R2's invalid-utf? catches all 2-byte overlong forms, but not 
all 3 or 4-byte overlong forms.

#{e080af} is an overlong form for #"/", for example.

R2>> invalid-utf? #{e080af}
R2== none

R3>> invalid-utf? #{e080af}
R3== #{e080af}

Same for the 4-byte overlong sequence #{f08080af}. R3 correctly detects 
it as wrong, R2 does not.

So, R3's invalid-utf? seems to flag overlong encodings in general. 
R2(/Forward)'s invalid-utf? only catches overlong forms for 2-byte 
sequences, but not for 3- or 4-byte sequences.

Good - we can fix R2's version, but not easily fix R3's.

Change of subject: Has anyone sent mass emails in R3? I need to send 
some (legitimately, internally) from data that R3 processed.

What about 5 or 6 byte overlong forms?

http://issue.cc/r3/1894

(a crash report)

APPEND ? Why not WRITE ? Still, it shouldn't crash.

Well, APPEND PORT "^/" actually works. Just APPEND PORT NEWLINE does 
not

Regarding the http://issue.cc/r3/1893


The USE-RULE/NO-REBIND variant can serve as an example of a case, 
where "early binding to function context" would make the code more 
flexible.

How do you load a DLL in R3? In R2 I'd code:

	*lib: load/library %sqlite3.dll

 version: make routine! [return: [string!]] *lib "sqlite3_libversion"


but the R3 'load native doesn't have a /library refinement any more. 
It also seems that routine! has been replaced with library!

On a separate note, I want to standardize on either R2 or R3 for 
work (no GUI or SDK required). What are the advantages of R3 compared 
to R2 at present, and what (apart from GUI and SDK) can R2 do that 
R3 can't?

Here is my short list (I am sure I forgot to mention a lot of things 
other people may find important)

Advantages of R3:

- new datatypes

-- map!, money!, percent!, closure!, module!, typeset!, command!, 
get-path!, 
- enhanced objects
- enhanced errors
- support for UNICODE strings
- enhanced bitsets (support for UNICODE)
- enhanced pairs
- 64-bit integers

- better conversions (to binary! and back)

- enhanced PARSE
-- new keywords added
- enhanced MOLD
-- improved MOLD/ALL
- enhanced LOAD
- some functions became natives
-- native APPEND
- more complete set of comparison functions
-- EQUIV? added
- much better RANDOM

- enhanced loops (CONTINUE)

- enhanced debugging capabilities (call stack)
- enhanced protection (PROTECT)

- improved GC

- more open (the host-kit is open source)

Disadvantages:

- missing list! (the demand for the datatype was low)

- missing hash! (for the majority of applications map! should be 
faster and more comfortable)

- no adequate substitute for the [throw] function attribute exists 
yet
- missing struct! (for substitute, see extensions)

Other advantages:

556 more tests than for R2 (see testing and tools group)

Also, less test failures than for R2

no easy access to libraries ...

protocols are untested

- Much better extensions than R2. It's super simple to write an R3 
extension.

Ashley: Good question, thank you.
Ladislav: Thank you for the answer.
apart from GUI
: there is still no official GUI for R3. You can use RMA's.

Well done, Ladislav.