World: r3wp

I mean this:


>> dt [loop 1000 [c: copy [] append/only c 'sine/radians append c 
0.5 do c]]  
== 0:00:00.002512


>> dt [loop 1000 [c: copy [] append/only c load "sine/radians" append 
c 0.5 do c]]
== 0:00:00.035299


In second case, to convert from string! to path!, string must be 
loaded first and as you can see it's about 14x slower in this rough 
test.

Understood. Thanks a lot for the time you spent ;)

you're welcome :)

as to why you need append/only: a path! is also a series!, with the 
path componenets being the elements. whitness:

>> type? 'a/b
== path!
>> series? 'a/b
== true

>> first 'a/b
== a
>> second 'a/b
== b

Which is why just APPENDing a path! to a block! separately appends 
each component of the path, just as for other series:

>> append t: copy [1 2] [3 4]
== [1 2 3 4]
>> append t: copy [1 2] 'a/b
== [1 2 a b]

If you want to append a series as a whole to another, you use the 
/only refinement:

>> append/only t: copy [1 2] [3 4]
== [1 2 [3 4]]
>> append/only t: copy [1 2] 'a/b  
== [1 2 a/b]

I think that the help for append should be corrected from:


/only -- Only insert a block as a single value (not the contents 
of the block)

to


/only -- Only insert series as a single value (not the contents of 
series)

Absolutely!

Not sure on that Bolek. It might then be confusing in the other direction, 
where appending a string without /only could be expected to append 
the individual chars. Since path! is any-block! the existing help 
is OK IMO.

Seems like it's neither block!s alone nor all series! values, seems 
like it's any-block! values which append/only inserts as a single 
value only.

Yes. I guess it could say "Appends any block value as a single value" 
to be a little clearer.

/only -- Appends any block value as a single value only (not the 
contents)


Is that good enough english to probably suggest it for R3 in curecode 
and R2 rambo?

The English is fine, but is it really more meaningful?

Why FORMing a datatype! removes the ! char? We cannot get it back 
to datatype without adding a ! to the end:
to-datatype to-word form integer! ;not working
to-datatype to-word join form integer! "!" ;ok


is this a bug, if it is by-desing what is the reason to remove "!"?

I think it's by design. FORM makes values "more readable". You'd 
better use MOLD for what you need.

yes MOLD is better use, thank you. I just curious about why FORM 
removes ! char. I think it prevents to manually remove ! char in 
this kind of situations:
a: 5 reform [a "is an" type? a]
>> 5 is an integer

Yes, I think this is exact user-case for FORM.

Hello


Just a basic question: when creating or resetting a string! or a 
block!, should we do
a: ""
b: []
or is better to do
a: copy ""
b: copy []

I tend to do the second way...

Does it make a difference? If yes, which way is better.

Thanks

This is the difference:

>> my-code-a: [a: "" append a #"x"]
== [a: "" append a #"x"]

>> do my-code-a
== "x"

>> my-code-a
== [a: "x" append a #"x"]

>> my-code-b: [b: copy "" append b #"x"]
== [b: copy "" append b #"x"]

>> do my-code-b
== "x"

>> my-code-b
== [b: copy "" append b #"x"]

Which one is better may depend on the application

usually, though, the latter is safer

Thanks ladislav

The bahaviour of my-code-a is confusing... What could be the point 
to do a: "" then?

E.g. if you want such a behaviour, i.e. if the effect is desired.

the statement a: "" is useless... You could obtain the same behaviour 
without repeating a: ""

Certainly, I prefer the latter, like you do.

???
>>  my-code-a: [a: [] append a 'x]
== [a: [] append a 'x]
>> do my-code-a
== [x]
>> do my-code-a
== [x x]
>> a: []
== []
>> a
== []
>> head a
== []
>> do my-code-a
== [x x x]
>> a
== [x x x]


what is the logic behind this? How could a be empty after a: [] and 
be filled will three 'x after just one call to do my-code-a

:-D you need to consult the MY-CODE-A block contents

Because oit's different A

(or, be careful, and use the copy [...] construct)

Rebolek: both calls to 'a are in the same context (root context) 
How could we have two different 'a in the same context?

The variable is not different, Francois, but the blocks are

it's like

a: []
a: [1 2 3]


how come? that after no insert at all I get three elements in an 
(originally empty block? ;-)

Sorry... i do not understand...
 
>> a
== []

>> a
== [x x x]

>> my-code-a: [a: [] append a 'x]
== [a: [] append a 'x]
>> do my-code-a
== [x]
>> do my-code-a
== [x x]
>> a: []
== []
>> my-code-a
== [a: [x x] append a 'x]
>> do my-code-a
== [x x x]
>> a
== [x x x]

The first A is defined inside MY-CODE-A block. And because you do 
not use copy [], it's not rewritten every time you call MY-CODE-A 
block.

OK... it is a quiestion of pointer assignement in some way...

why pointer? by doing my-code: [a: [x x]] I just assign the block 
that is the second in MY-CODE to A

same? a second my-code
== true

It looks to me like everytime you call my-code-a, you assign the 
block defined in my-code-a to the variable a which is globally accessible. 
When you write a: [] outside my-code-a, you assigne another block 
to a... a is a pointer and you swith the adresse it is pointed to.

>> my-code-a: [a: [] append a 'x]
== [a: [] append a 'x]
>> do my-code-a
== [x]
>> a
== [x]
>> a: copy []
== []
>> append a 'y
== [y]
>> a
== [y]
>> do my-code-a
== [x x]
>> a
== [x x]

To explain it even futher, here is yet another example:

>> my-code-c: [a: []]
== [a: []]
>> do my-code-c
== []
>> append a 'x
== [x]
>> my-code-c
== [a: [x]]

hope, it is clear what is going on

just forget about pointers, please

sorry... C bad habits :)

Example prolonged:

>> my-code-c: [a: []]
== [a: []]
>> do my-code-c
== []
>> append a 'x
== [x]
>> my-code-c
== [a: [x]]
>> a: []
== []
>> my-code-c
== [a: [x]]

thanks ladislav... i got it!!!

An even longer one:

>> my-code-c: [a: []]
== [a: []]
>> my-code-d: [a: []]
== [a: []]
>> do my-code-c
== []
>> append a 'a
== [a]
>> my-code-c
== [a: [a]]
>> my-code-d
== [a: []]
>> do my-code-d
== []
>> append a 'c
== [c]
>> my-code-c
== [a: [a]]
>> my-code-d
== [a: [c]]

Why core doesn't support clipboard port?

Oh, I just find it is already in RAMBO.