World: r3wp

rebol changes the actual bytes within the ram. most languages, create 
new strings and assign the new pointer to the variable.

Ok, so that means mutable?

yep... the ram mutates, "in-place".

Got ya.  That is easy enough to understand.

wasn't that also the difference between R1 and R2?

But if that is the case then if the string changes such that it doesn't 
fit the size of the existing allocation , then what happens?

then rebol reallocates a new region of ram and copies the current 
data into it, adding a few extra bytes based on heuristics, so that 
small changes don't need to constantly re-allocate ram.

So do you believe that REBOL is using the Pascal like length-prefixed 
strings?

which is why you should do :

s: make string! 10003


when you know that your algorythm will eventually reach 10000 bytes

Correct, that is how I see it and why I ask about this.  Because 
to me this makes more sense as to assigning the length before hand.

no since strings are objects, just like all datatypes.  they have 
internal counters for offset, length, etc.  the string itself really 
is just a buffer.  which is why in R2 strings and binary really are 
the same thing.  in R3 this is quite different.

the binary and character lengths of strings aren't the same thing, 
depending on the encoding of strings.

(in R3)

it's why as-binary or  as-string can't be no more exisit in R3

in R2, it's really fast because only the type of the value is changed 
(no boring things like copy are done)

See, I see strings stored in memory as nothing more than a character 
array.

The actual data part rather.

HLA is a language that stores string data a bit differently it sounds. 
 It allows both null termination but allows null use in string also.

It got me thinking as to how REBOL does its length handling.

In HLA, the string is prefixed with a dword value indicating max-length, 
then a dword value indicating current length, then the string characters 
and then a null termination.

So it is 4 parts to a string.

>> license
...
The copyright, trademark, and other proprietary rights notices
contained in the SOFTWARE may not be removed, altered, or added
to in any way. You may not reverse engineer, decompile, or
disassemble the SOFTWARE.
...

...

Seems that some here broke the REBOL EULA.

I would think we are guessing if anything Doc.

educationnal purpose

Oh you must be referring to those that dissassembled.  Shame on you 
Steeve and Brian.  ;-)

i'm under Europe laws here

was funny when Ladislav explained his mem manipulation things to 
Carl.  ;-)

Carl was impressed more than anything hehehe

There's no such exception in the EULA. The EULA is a contract between 
the end user and the publisher. AFAIK, EULA applies in EU too.

Much of my comments are just guessing, mister cop  :-)

Doc have you ever disassembled REBOL?

I don't want to defend RT here, just reminding some of you that using 
REBOL implies agreeing the EULA. Not that I fully agree with RT ways 
of distributing REBOL, but this is an official REBOL channel that's 
[web-public], so at least we should respect the EULA.

Paul : never and I never plan to do so.

Excellent Doc!

Good point also about it being web-public.

As you state above, guessing how some parts of REBOL work internally 
can be done without breaking the EULA.

Doc, knowing how rebol works internally isn't guess work and disassembling.

some of this comes from RT itself, and even from such things as playing 
around with structs.

using rebol to peek inside of rebol isn't disassembling  :-)

There some differences between us Doc, you have a company selling 
rebol services ans progs. Me, I don't use Rebol professionaly

Well, only RT knows for sure how it works internally, if some info 
is disclosed, then it become public so no problem talking about it, 
 I think.

So, even if you had disassembly rebol, you can't say that

Whatever way you use REBOL (hobby or professionnal use), it implies 
accepting the EULA.

By installing or using the SOFTWARE, you are consenting to be
bound 
by and are becoming a party to this AGREEMENT. If you do
not agree 
to all of the terms of this AGREEMENT, do not use the
SOFTWARE.

You're such a boring guy Doc, i didn't know you were

I'm a guy with principles and respecting the work done by other is 
one of them. I like playing by the rules.

Ok we know now, don't push yourself

As I'm reviewing my old code, where I see a lot of rejoins where 
the first arg of block is always binary... what do you think about 
something like:
abin: func[block][append copy first block next block]
where the speed gain is:
>> tm 1000000 [abin [#{00} "a"]]
0:00:01.609
>> tm 1000000 [rejoin [#{00} "a"]]
0:00:02.938

maybe not such a big gain.. as I must use:
abin: func[block][append copy first block reduce next block]
which has result 0:00:02.078... but anyway.. every ms counts:)