World: r3wp

well, in R2 'copies' in both cases..so its either intended change 
in R3 or bug

>> d: make a make object! []
same behavior than 
>> d: append make object! [] a

But I agree, it's quite unexpected.

my mistake, same as
>> d: copy a

I vote for inconsistent.
>> make object! object! 
Should that be allowed, to begin with ?

It was allowed in R2 so why not?

Never saw that before. I don't understand the expected behavior to 
begin with.

http://www.rebol.com/docs/changes-2-5.html#section-85

Hum ok, it's cleared stated then. It's a feature

*clearly

R2 session:
>> a: make object! [b: []]
>> c: make a []
>> d: make a make object! []
>> same? a/b c/b
== false
>> same? a/b d/b
== false


So if this was changed in R3 I'm asking if it was intended or not. 
I don't care much what is the 'right' way but asking mainly because 
if the change was intended it should be well noted and documented 
otherwise it can make headache to people.

OH, I see your point now.

I think it's a bug now, It's doing the reverse of the R2 behavior.
>> d: make a make object! []
R3 reverse the parameters at some point and performs 
>> d: make object! [] a

inconsistent anyway

the difference I was pointing out is:


make <object> <block> ;copies the block values inside the prototype 
object

while


make <object> <object> ;doesn't copy the block values in prototype 
object

that is in R3...in R2 it was consistent

yeah it's what I understood

In R3 
>> d: make obejct1 object2
should behave like
>> d: append object1 body-of object2

But yeah, the first form is more concise and faster.

Do you know this document?

http://www.rebol.net/w/index.php?title=Copy_Semantics&redirect=no

There was a big discussion before it, so I would guess it's intended, 
although I'm not sure

Maxim should know the details, because he pushed for changes in object 
copying

I think the point was to have programmer control over the copying 
of an object that is being cloned

yes copy control was implemented because of real world issues trying 
to use early R3 alphas and also because the lack of control in R2 
makes many big data sets very hard to manage in R2.

Ladislav, FACES? was created in accordance with the current documentation 
of the function naming standards, not the current function naming 
standards. The documentation needs fixing.

So, could you tell me what your preferences are?

(regarding the wording)

If it's a function that takes a face or gob as a parameter and returns 
the faces inside of it, I prefer FACES-OF. If it is a member function 
(assigned to a field of a face and bound to it), FACES. Those look 
best to those familiar with English. We're trying to cut down on 
*? for functions that aren't questions or part of the help system.

I thought, you did not intend to change the wording of of 


http://www.rebol.com/r3/docs/concepts/scripts-style.html#section-11

, did you?

Aha, that "if it is a member function" was what you meant. It is 
not, currently.

If necessary, yes. The noun-OF convention should be added, and some 
sensible *? conventions should be mentioned too. In particular, the 
"is it a question?" criteria is a good thing to mention.

I don't have the time this week to do so, and am waiting on some 
more community understanding before I jump in. The "intrinsic property" 
thing likely won't survuve the cut, being replaced by the "implicit 
-of" thing.

But, the 

    Face/faces


was used before the change, and it was not a function, but a block 
"storing" the faces

Then FACES-OF would be the best name for the function, letting 'faces 
be used for variables, and maybe letting FACES? mean "does it have 
faces?".

It definitely wasn't based on any C convention, definitely on English 
:)

Where should be stored equivalent to R2's system/user/name and system/user/email 
?

Also do we have any standart way how to specify that a script requires 
R3 in script's header?

There's no mail functionality yet

Graham's SMTP protocol doesn't seem to have a place for them, either

I'm not looking for mail functionality, but where will be stored 
the user info.

Another question... if I want function which converts integer to 
one byte, is there better way than:
	copy back tail to binary! 60

maybe:
	to binary! to char! min 255 60

I should try if extension could speed up such a conversions.

Hm.. R3 version of conversion to 2 bytes is slower:/
R3:
>> tm 100000 [copy/part head reverse to binary! 300 2]
== 0:00:00.079
R2:

>> ui16-struct: make struct! [value [short]] none tm 100000 [ui16-struct/value: 
300 third ui16-struct]
== 0:00:00.047

make a new native as an extension, link it as a command :-)

Kaj, Maxim, thanks for pointing out the document.

Does copy/part head reverse to binary! 300 2 give the correct answer?

>> to binary! 300                                      
 
==#{000000000000012C}


>>  copy/part head reverse to binary! 300 2           
  
== #{2C01}

good... as an extension I have:
            const short int val = RXA_INT32(frm, 1); 
            REBSER *ser = RL_MAKE_STRING(1, FALSE);
            RL_SET_CHAR(ser, 0, val );
            RL_SET_CHAR(ser, 1, val >> 8);
            RXA_SERIES(frm, 1) = ser;
            RXA_TYPE(frm, 1) = RXT_BINARY;
            return RXR_VALUE;

>> tm 100000 [to-ui16 300]
== 0:00:00.016

Peter: yes.. but speed is important!

not sure how fast is this, but you can use vector for diffferent 
int conversions...like:

>> uint16: make vector! [unsigned integer! 16 1]
== make vector! [unsigned integer! 16 1 [
0
]]

>> uint16/1: 300 skip to-binary uint16/1 6
== #{012C}

So the extension is fastest?

maybe to-binary on vector! could do the job best way but this is 
not implemented yet probably