World: r3wp

Have some display bugs though that need more testing, and a weird 
new bug in HELP.

Simple parsing does not work for large gatasets
 bug fixed. Nice - http://curecode.org/rebol3/ticket.rsp?id=1480

And Carl's mods to the tests for that were nice too. Also, take a 
look at #1452 - note the limitations.

what limitations?

I wrote them in a comment. You can only insert/append blocks containing 
values of these types: binary!, string!, char!, and integers from 
0 to 255 which are inserted as bytes. Anything else will need explicit 
conversion.

Note: No compressed modules yet. They'll get in as part of the mezzanine 
review.

ah, ok (re limitiation), I just tried joining two binaries and it 
worked. Did not try with integer value ...

I tried everything I could :)

I can see those protect/uprotect/hide bugs mentioned in various tickest. 
Aren't those blocking us? Maybe you should push their priority?

They are blocking us, but not as badly as the a98-derived host kit 
is. I would like more feedback on the security model they propose.

BrianH: can you sum-up, what works in A98, re Extensions/Host Kit? 
What things are still missing? Any docs anywhere?

No, I haven't tested them yet, because there aren't enough docs yet. 
I was only able to test core stuff.

Came up with a proposal for the binary conversions - take a look: 
http://www.rebol.net/cgi-bin/r3blog.r?view=0317#comments

Let me guess .. none of the network protocols have been added ...

Almost none of the mezzanine fixes either - this was a release with 
native focus.

And by that I mean the *already posted* mezzanine fixes.

yes, Hostkit is a priority right now, absolutly. Other fixes might 
wait. I even think, that we should "finish" the low-level route .... 
hence add Extension support for devices, add tasking, a utypes ... 
then we can state the Core is almost finished for beta ...

Already posted a fix to the new HELP bug #1604.

If we can build our own cores .. I guess we can add our own protocols

or not ..

Did you submit your changes to DevBase? I'm verifying the submissions 
there now - it looks like *some* of the mezzanine fixes were included 
in a98.

We should do a poll of what OS everyone is using.  Seems to me odd 
to release two OSX builds and no Linux

Aggh... no polls here.  I was thinking of IOS

Is it odd, or just nighttime? Let Carl sleep - it's almost 2am there. 
We'll see if they are still not built tomorrow.

even then

only 9 pm here ...

Graham - it is all because Apple is being popular in US ....

Nah ... It's because Carl uses an apple as his primary pc ...

Has anyone done this?


If your embedded module consists entirely of REBOL code (no native 
commands), it's not required that you embed it in the way described 
here. Instead, you can add it to the host bundled source code which 
initialized in the host in the line:

Reb_Do_Binary(Reb_Init_Code, REB_INIT_SIZE, 0, 0);

More on this is described in the host-kit documentation.

which is in http://www.rebol.com/r3/docs/concepts/extensions-embedded.html
but the host-kit page references this document  ...

That's for the new host kit, which isn't out yet.

It is nice we have embedded Extensions. That way we can "internalise" 
external components, and kind of pack-it-in into one exe, as Encap 
did, no?

Will we get delayed init, or was it just a proposal?

Carl says we have it, but it's currently handled by native code and 
doesn't affect the LOAD mezzanine code yet.

Weird....

>> dp [loop 10000 [change #{00} [2]]]
== make object! [
    timer: 0:00:00.003776
    evals: 30011
    eval-natives: 10004
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]

>> dp [loop 10000 [change #{00} 2]]
== make object! [
    timer: 0:00:00.00457
    evals: 30011
    eval-natives: 10004
    eval-functions: 1
    series-made: 10001
    series-freed: 0
    series-expanded: 0
    series-bytes: 40432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]

(same using 'append, for A98 only)

The baseline:
>> dp []
== make object! [
    timer: 0:00:00.000011
    evals: 8
    eval-natives: 3
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]

Example code:
>> dp [change #{00} #{02}]
== make object! [
    timer: 0:00:00.00001
    evals: 11
    eval-natives: 4
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]
>> dp [change #{00} 2]
== make object! [
    timer: 0:00:00.00001
    evals: 11
    eval-natives: 4
    eval-functions: 1
    series-made: 2
    series-freed: 0
    series-expanded: 0
    series-bytes: 436
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]
>> dp [change #{00} [2]]
== make object! [
    timer: 0:00:00.000009
    evals: 11
    eval-natives: 4
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]


Clearly APPEND, INSERT and CHANGE convert regular values to binary! 
first now (creating a series), then do their inserts. And they don't 
convert first if you use the new block mode. Good to know :)

Sorry, I could have been less verbose with that.

Seems more obfuscated than a simple binary conversion...

>> abs -432 + get in dp [to binary! 2] 'series-bytes
== 10
>> abs -432 + get in dp [change #{00} 2] 'series-bytes
== 4
>> abs -432 + get in dp [make binary! 3] 'series-bytes
== 4

(abs... wtf)

They have to convert to binary anyways before they can insert it. 
I think that the real bug is that CHANGE binary! block! is *not reporting 
the series it has to create internally*, while CHANGE binary! value! 
*is*. It seems to be a bug in reporting the stats, not a bug in the 
behavior.

hmm, what a bug ... type 'help two times, and R3 goes under :-)

That's #1603. R3 doesn't go under, but the console output stops before 
it's done.

no, it crashes, why don't you try it yourself? ;-)

I get r3-a98.exe stopped to work dialog box ... and am offered either 
the debug or program termination ...

what are you saying BrianH ? we don't need to do a conversion to 
add a 8-bit integer at first.

>> x: #{00}
== #{00}

>> x/1: 2 x
== #{02}

or 
pick x 1 2

I just think that 'change block uses that neater way in a loop

(you can see with dp, that there is no binary conversion)

(not pick, but poke)

I did try it myself; I was the one who reported #1603. I've used 
a98 for many hours now with no crashes. What platform are you running 
on, on which OS?

Steeve, for a native operation the only way that the stats can be 
recorded is if the native reports them; it's not like with REBOL 
code. So if DP doesn't report something, it's either because it didn't 
happen or because the code didn't say it happened. I wouldn't be 
surprised if the allocator has stats collection hooks, but who knows 
how CHANGE binary! block! is allocating its stuff. But it would *have* 
to do a binary conversion in order to insert a non-binary value, 
so there is no question that there is some kind of binary conversion 
going on.

BrianH: Windows Vista, 32 bit ...