World: r3wp

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.

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 :-)