World: r3wp

#{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.

Perhaps also of importance is that many bugs are already well-documented 
and are actively being discussed in Curecode with R3 rather than 
the simple non-discussed reports for RAMBO with R2.

I would add following "negatives" (depends upon how you look into 
it):


- no /libary extension and easy wrapping of DLLs. There was a bounty 
started to bring in kind of R2 DLL capabilities using extensions, 
Max was working on something, but did not deliver. Some ppl claim, 
that working with extensions is easy enough, much more powerfull, 
and that in fact R2 /library interface was weak in comparison in 
capabilities.


- weak and underpowered CALL.No /output or /wait parameter IIRC. 
Carl said, that R2 C code to it was complex, and that the code is 
eventually awailable for volunteer to bring in to R3. The outcome 
is - CALL is limited in usage in comparison to what can be easily 
achieved in R2.


- protocols. The only protocol IIRC was available was HTTP, done 
by Gabriele. It was HTTP 1.1 compatible, but due to some bug (?) 
it was downgraded to 1.0 version. No proxy support. Other protocols 
were done by some other ppl, I do remember Graham doing some work 
here. In regards to protocols, IIRC there was some work done by Kaj, 
who brought Curl networking extension to R3.


- under Windows console is a bit more inconvenient in usage than 
in R2, we use native Windows console, yet we don't have full console 
support, so we can't replace the native R3 one by e.g. Console2 or 
some other version ...


- DBAccess - forget R2 protocols available. The rescue is ODBC extension 
for R3


- CGI - no native CGI support in R3, though it should not be difficult 
to emulate


- Sorting & Unicode - althought we have Unicode strings available, 
sort is not adapted to that, and the question is, if it can be easily 
done ...

Other than that, R3 has the advantages Ladislav mentioned. So if 
you can live with some limitiations I named, you should be OK in 
using R3.

I thought Kaj was using R3 for cgi ??

there is still no official GUI for R3

 - frankly, that is inaccurate. The GUI is "official" in the following 
 senses:

- Carl "delegated" the GUI development to our team
- the GUI is the continuation of the Carl's version
- the GUI is available for everyone
- the documentation is available as well

- the development of the GUI is continuing, for every new version 
of the interpreter, the corresponding GUI version is available

Ladislav - as due to low public interest the GUI is not going to 
be published so often, I would like to ask, if some work on "nice 
skin" has already started? (I am referring to a blog post :-)

it hasn't

Sorting & Unicode - althought we have Unicode strings available, 
sort is not adapted to that, and the question is, if it can be easily 
done ...

 - this is not a disadvantage of R3, in this case R3 surely is better 
 than R2

weak and underpowered CALL.No /output or /wait parameter IIRC.


I agree with the general notion (that CALL is weak, atm), but: /wait 
is there (albeit not working on Linux, IIRC). /output is missing 
indeed.


But CALL is fully doable as extension or from within the hostkit. 
So if anyone really needs it, it's a matter of either developing 
it yourself or funding the development. (Feel free to contact me, 
if interested in the latter.)

no native CGI support in R3


True, although that "native" support is barely needed. `get-env` 
and `system/ports/input` are basically all you need. I am running 
several R3 CGIs which work just fine.

well................ carl where are you ?????

Ladislav, how do we now access the R3 GUI and the REBOL core on which 
it runs?

Singy, it should be on saphirion.com, but there are some server problems 
currently.

No server problems: http://www.saphirion.com/development/r3-gui/

Thanks Robert - that works fine - now :) Henrik was correct at the 
time, the server was having problems - it is what prompted my question.

I just noticed Bohdan Lechnowsky saying following on Facebook: "I 
know for a fact that Carl was working on R3 this past weekend." Any 
insider info on that?

Who is this person?

Found out.

Bo did a talk at REBOL/Collaboration 2004 and is quoted in the notes. 
 Oh yeah, here's his bio... http://www.efishantsea.com/devcon2004/bios.html

a quote from there ... http://www.efishantsea.com/devcon2004/bloopers.html

Bo lives in Ukiah as well.

Bo used to work for RT, afaik.

Yeah, he was in quality assurance and testing

In R3, upper- and lowercase chars are equal, which leads to:

>> #"a" = #"A"
== true
>> #"a" > #"A" 
== true

Isn't that a mistake?

no...

no...

>> #"a" == #"A"
== false

>> #"a" == #"a"
== true