World: r3wp

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

I just proved that you can do it whithout the need to create an intermediate 
binary serie, are you tired ?

I really just start it, type help, get a bit wrong output, then I 
type help again, press enter,and R3 goes under ...

do you want I write the code in clear  ?

A99 almost ready (reported by Carl on R3 Chat)

PICK and POKE may also do their own conversions using their own buffer 
(it's just a byte). Apparently since CHANGE binary! value has to 
support full TO binary! support, the easiest way would be to actually 
call TO binary!, which would allocate something. Since CHANGE binary! 
block! doesn't need to support full TO binary! support, maybe it 
has its own internal conversion routines that don't call TO binary!, 
and thus don't *report* any temporary series it creates.

poke #{00} 1 2 --> no binary conversion of 2 here, I can bet my life 
on that line :)

Pekr, I have not had a single crash on Win7 x64 with a98. So it may 
either be a Vista thing or a 32bit thing. Either way, don't be surprised 
if the problem goes away with the fix to #1603. Still, report the 
behavior you have seen in a comment there.

Steeve, POKE converts to a binary value, but not a *newly allocated* 
binary value. Instead, it converts directly into place or it converts 
to a buffer (likely a stack-local byte variable or a register) and 
is then put into place. But is *has* to convert to binary, because 
that is what the result is. For CHANGE, APPEND and INSERT, you can't 
use a fixed buffer because you have to be able to support general 
conversions, so you have to allocate a temporary. However, when inserting 
a block you *don't* have to support general conversions, just a few 
specific conversions, so it might in some cases (like integers) be 
able to use the POKE method, or some other preallocated buffer. But 
in some cases, it does allocate a new buffer for the conversion:

>> select dp [change #{00} ["a"]] 'series-made
== 1  ; uses an internal buffer
>> select dp [change #{00} ["abcdefghijklmnop"]] 'series-made
== 2  ; allocates a new buffer

The baseline being:
>> select dp [] 'series-made
== 1

maybe for string to binary conversion a buffer is requested but i 
can bet that it's not neccessary for integers. It can be poked in 
place.

It's like I would do in asm or in C. casting of the 64 bits integer 
into a char (take the low byte) and poke it inside the binary serie, 
that's all I have to do.

that's why i think CHANGE #{00} 2, should not have to allocate a 
new buffer

but it's just optimization :)

Carl's question on R3 Chat:

#7301: post from Carl 36m ago:
FOR can include tail. Do we want to keep that behavior?

>> for a b: "abc" tail b 1 [probe a]
abc
bc
c



This happens because FOR is inclusive on its END value. (Remind me 
if we've talked about this before.)

Suggest it in CureCode Steeve, and I can tweak the ticket if need 
be. Now is the time - Carl is working on this kind of thing today.

I think that above behaviour for 'FOR is correct. That is why we 
have "back tail" usage pattern :-)

ok, I give it a try

I like to think that FOR works in indexes like AT, instead of offsets 
like SKIP. So that seems like good behavior to me.

me too

Brian, ticket posted

And refined.

thanks

Sorry, I had to put in a dig about #574 - it's a pet peeve with a 
known, already-submitted mezzanine solution.

(stupid profiler, including its own overhead in its results)

uhuh

It's not refined in my head yet enough but i think 'IN needs of a 
redesign.

Especially this form allowed by the specs but throwing an error currently.
>> in [obj1 obj2 ...] [a b c d]
== Error!

it could be powerfull, allowing to inherit properties from a hierarchy 
of objects (think about nested gobs with their own context)
But it's not enough...
I would like that the returned block discard the unbound words.
It would be consistent with the single form.
>> in context [a: 1] 'b
== none

I don't know if i'm clear...

That has already been suggested before (don't remember the ticket), 
though without the "discard the unbound words" feature that would 
break the code that IN context block! usually works with. IIRC it 
was dismissed, because IN is supposed to be a low-level function 
and this would slow it down immensely.

A big O slowdown, from O(n) to O(m * n).

So slow that we are better off not having such a feature, having 
to rewrite our code so we don't need to do that at all.

well, if it's discard only the unbound word (words having no context 
at all) there will be no sideeffect I guess
in context [a: 1] unbind [a b c]

Remember, IN whatever block! is usually preceded by DO. You don't 
want to remove words from code you are going to DO.

or just as an option

And lit-words and refinements also get bound, so removing them because 
they are unbound would be bad, since they have meaning beyond their 
binding. And adding options to IN will slow it down too; IN is supposed 
to be *fast*.

>> a: [a] same? a in self a
== true

IN something block! is like BIND, not BIND/copy - IN modifies. Don't 
remove stuff from the original.

IN something word doesn't modify though.

I think words are immutable in R3, like integers, tuples and typesets. 
When IN or BIND binds a block I think they replace the words they 
bind with new words that refer to the same symbols, but a new context. 
So IN and BIND never modify words - they replace them.

Words Immutable you say ?

>> p: to-path 'a
>> x: reduce [p p p p p p ]
== [a a a a a a]
>> p/1: 'b
>> x
== [b b b b b b]

lol...

Those are the bindings that the words point to. I am actually talking 
about word!, lit-word!, ... values themselves.

Was just a joke

You can't change the binding of a word. You can't change the symbol 
of a word. Either will result in a new word. There isn't anything 
else that makes up a word. The only thing you can change is the value 
slot that the word points to, but you can't change *which* value 
slot the word points to, just the contents of the slot.