World: r3wp

Good news

So, he is opening up parts of the source to you?

Thank a lot for the news Robert. Currently it is the most important 
thing is to continue on develeopment of R3, so it is definitely not 
a problem to drive the priorities by the things RMA needs.. Please 
keep us informed when you have more news from Carl.

Good there is some progress. Does the above mean, that Carl himself 
is not returning to R3 development yet? What about blogs/twitter? 
Maybe Carl could open-it for RMA too, but the question is, if you 
want to blog ....

From my point of view it means, that there is no NDA, just that Carl 
lost interest to be with us and work on REBOL.

I think you're right

If so, then there is a question, if Carl shoul not consider fully 
open-sourcing R3. But we most probably know the answer. I would be 
really intested into Carl officially telling the REBOL community 
his motives to (dis)contiu with R3 development. It all feels really 
dishonest, and I wonder, for any eventual future project, how Carl 
wants to win the trust of ppl.

I might not be as good as you guys are, but if there is anything 
I can do to help R3, let me know. My email: [JerryTsai1218-:-Gmail-:-com]. 
Let's make R3 hit the beta this year.

something like free-rebol bounty ? :)))

That's great new Robert. Thanks for the post.

Oldes, as far as I can tell, there is going to be an NDA.

I think Oldes was just referring to speculations made in some channel 
here on AltME a little while ago. I think the speculation was that 
one reason for Carl disappearing publicly could be that he is prohibited 
from talking about REBOL by an NDA-like contract at his current occupation.

I probably shouldn't spread that speculation further :)

Some notes:
- We will have an NDA

- Carl didn't lost interest, he is full comitted to R3. His contract 
work is (still) / was very intense. Things get a bit more relaxed 
there now.

Much kudos to Robert for taking such a powerful initiative from which 
all of us will benefit.


I wish you, RMA and the RMA team every success; you all really deserve 
it.

Thanks Peter.

- I / RMA will be the main communication channel. I have access to 
Rebol-3 twitter and there exists a RMA twitter.

- We will continue to work on the R3-GUI and release it as we did 
before (sometimes there might be longer periods of no-release, if 
we are doing massive changes)

- The main focus will be: fixing bugs, defining and writing down 
how datatypes are handled WRT conversion, priority, sorting etc.

NDA ?

LOL  AFTER 111 version there zill be a NDA ( non disclosure agreement) 
but non disclosure agreement to disclose what the  emptyness  of 
nothingness ?  go ahead  please :)

Robert I'm happy you say you will continue to work on r3-gui but 
will that work produce some result  ?

Carl didn't lost interrest ?? aaaaaaaaahahaha who do you think you 
are fooling Robert serriously ?

wasn't carl some moth ago that was saying the rebol was a commercial 
faillure and that he needed tto get a real work to feed his familly 
?

aaaaaaaaahahaah isn't that called loosing interest  ?

I laughed so much that I'm impatient to comeback in september to 
see the bunch of new jokes you will have in stock

Where he said, that it's a commercial failure?

In Alphe's imagination

Can R3 load and use shared libraries like R2 with load/library ?


I see a group named "!REBOL3 /library". Is that about such libraries, 
or are extensions for that? (Group "!REBOL3 Extensions".)

There was a bounty, and attempt from Max (not finished IIRC), to 
bring R2 like DLL interface to R3, to simplify it for users not being 
able to utilise full extension interface.

Some ppl found out, that using extension interface is not so hard 
as it seems though ...

Has it been tried to get the source for R2's load/library, make routine! 
and then the calling from Carl? That seems to me to be a lot easier 
to start with that code, as it do work.

I know, it has been tried many times to get sources, but maybe he 
would agree on such a specific case, as it would be needed in R3 
anyway.

Converting a R2 DLL into a R3 one is really simple. I have done our 
DLLs in a way that I can compile them as R2 or R3 version. The only 
change is a .DEF file for the linker. Everything else is the same.

I think about others DLLs, like OpenGL.

To make them into a R3 extension is pretty simple. The R3 external 
interface is way simpler than in R2. So, yes, via IMPORT and R3 extension.

Ok, I get this error:


>> opengl: import %/System/Library/Frameworks/OpenGL.framework/OpenGL

** syntax error: script is missing a REBOL header: %/System/Library/Frameworks/OpenGL.framework/OpenGL

So such DLLs need to be wrapped in some REBOL code, or?

There is some doc here:

http://www.rebol.com/r3/docs/concepts/extensions-making.html#section-19


As I read it, I would need to write an extension to access external 
APIs like standard OS libraries.

Geomol - yes, you need to write a wrapper for each DLL you are about 
to utilise ...

Geomol, yes, the "!REBOL3 /library" group is about R2/Library-style 
access to DSOs. I.e. using pre-existing DSOs from within REBOL.


The "!REBOL3 Extensions" group is for discussion about native R3 
 extensions. I.e. writing special-purpose DSOs which can export native-like 
functions into R3.

http://curecode.org/rebol3/ticket.rsp?id=1888&cursor=1

This doesn't look like a bug to me. Anyone?

http://curecode.org/rebol3/ticket.rsp?id=1886&cursor=3

This one looks fixable, as it's a mezzanine.

About parse: Always been like that, nothing new.

#1888 is definitely not a bug. #1886 should be looked at by the person 
who knows what SPLIT is supposed to do. It wasn't one of mine, and 
there was never really any consensus about its behavior. SPLIT isn't 
finished yet.

I don't know where the test suite for SPLIT is, but the rule in effect 
for that changed from the old source that Gabriele and I originally 
created. The final rule, for string/char/bitset delimiters was originally 
this:


    [any [mk1: some [mk2: dlm break | skip] (emit copy/part mk1 mk2)]]

but is now this:


    [any [mk1: [to dlm mk2: dlm | to end mk2:] (keep copy/part mk1 mk2)]]


It looks like that changed due to http://issue.cc/r3/573, but obviously 
wasn't run through a test suite. I don't know what caused the issue 
with the above bug, as that parse rule returns a correct result.

Found a small test suite.

test: func [block] [
	print [mold/only :block newline tab mold do block]
]	

test [split "1234567812345678" 4]
;== ["1234" "5678" "1234" "5678"]

test [split "1234567812345678" 3]
;== ["123" "456" "781" "234" "567" "8"]
test [split "1234567812345678" 5]
;== ["12345" "67812" "34567" "8"]

test [split/into [1 2 3 4 5 6] 2]
;== [[1 2 3] [4 5 6]]
test [split/into "1234567812345678" 2]
;== ["12345678" "12345678"]

test [split/into "1234567812345678" 3]
;== ["12345" "67812" "345678"]
test [split/into "1234567812345678" 5]
;== ["123" "456" "781" "234" "5678"]

test [split [1 2 3 4 5 6] [2 1 3]]
;== [[1 2] [3] [4 5 6]]
test [split "1234567812345678" [4 4 2 2 1 1 1 1]]
;== ["1234" "5678" "12" "34" "5" "6" "7" "8"]
test [split first [(1 2 3 4 5 6 7 8 9)] 3]
;== [(1 2 3) (4 5 6) (7 8 9)]
test [split #{0102030405060708090A} [4 3 1 2]]
;== [#{01020304} #{050607} #{08} #{090A}]

test [split [1 2 3 4 5 6] [2 1]]
;== [[1 2] [3]]

test [split [1 2 3 4 5 6] [2 1 3 5]]
;== [[1 2] [3] [4 5 6] []]

test [split [1 2 3 4 5 6] [2 1 6]]
;== [[1 2] [3] [4 5 6]]

test [split [1 2 3 4 5 6] [3 2 2 -1 -4 3 -2]]
;== [[1 2 3] [4 5] [6] [6] [2 3 4 5] [2 3 4] [3 4]]	

test [split "abc,de,fghi,jk" #","]
;== ["abc" "de" "fghi" "jk"]
test [split "abc<br>de<br>fghi<br>jk" <br>]
;== ["abc" "de" "fghi" "jk"]

test [split "abc|de/fghi:jk" charset "|/:"]
;== ["abc" "de" "fghi" "jk"]

test [split "abc^M^Jde^Mfghi^Jjk" [crlf | #"^M" | newline]]
;== ["abc" "de" "fghi" "jk"]
test [split "abc     de fghi  jk" [some #" "]]
;== ["abc" "de" "fghi" "jk"]

The original was written before MAP-EACH and the new COLLECT. Here 
is the source I have, updated to use those as the current version 
does, but with the last rule reverted to the original.

Related cc reports: 
    http://issue.cc/r3/1096
    http://issue.cc/r3/690

split: func [

    "Split a series into pieces; fixed or variable size, fixed number, 
    or at delimiters"
    series	[series!] "The series to split"

    dlm		[block! integer! char! bitset! any-string!] "Split size, delimiter(s), 
    or rule(s)." 

    /into	"If dlm is an integer, split into n pieces, rather than pieces 
    of length n."
    /local size count mk1 mk2
][
    either all [block? dlm  parse dlm [some integer!]] [
            map-each len dlm [
                either positive? len [
                    copy/part series series: skip series len
                ] [
                    series: skip series negate len

                    ; return unset so that nothing is added to output
                    ()
                ]
            ]
    ][
        size: dlm   ; alias for readability
        collect [
            parse/all series case [
                all [integer? size into] [

                    if size < 1 [cause-error 'Script 'invalid-arg size]
                    count: size - 1
                    size: round/down divide length? series size
                    [

                        count [copy series size skip (keep/only series)]
                        copy series to end (keep/only series)
                    ]
                ]
                integer? dlm [

                    if size < 1 [cause-error 'Script 'invalid-arg size]

                    [any [copy series 1 size skip (keep/only series)]]
                ]

                'else [ ; = any [bitset? dlm  any-string? dlm  char? dlm]

                    [any [mk1: some [mk2: dlm break | skip] (keep copy/part mk1 mk2)]]
                ]
            ]
        ] 
    ]
]

>> split "a.b.c" "."
== ["a" "b" "c"]

>> split "c c" " "
== ["c" "c"]

>> split "1," " "
== ["1,"]

>> split "1,2" " "
== ["1,2"]

>> split "c,c" ","
== ["c" "c"]

>> split/into "" 1
== [""]

>> split/into "" 2
== ["" ""]

>>  split "This! is a. test? to see " charset "!?."
== ["This" " is a" " test" " to see "]

The test case that fails with this is where the delimiter is the 
last char. You don't get an empty field at the end. 

>> split "1,2,3," ","
== ["1" "2" "3"]

I found some notes that at one point to/thru broke for block and 
bitset targets.

ROUND not returning an integer broke some things too. i.e. currently 
broken.