World: r3wp

meassing lot of feature in tcc, are the extensions compilable with 
C compiler ?

or olny C++ ?

Only C for now - not C++. Some tweaks to the header will help with 
that. It's on my list to test with TCC :)

There are some platform-specific adjustments that the headers couuld 
be doing, but aren't yet. We could put TCC tweaks there.

2.100.80 released with new 'copy semantics ... let's test. Max - 
throw your 10K of your gfx nodes into it :-)

Thinking aloud for a bit in relation to the new Copy Semantics:
http://www.rebol.net/wiki/Copy_Semantics


What about the idea of protecting values. This way they won't be 
copied, when creatng a new object. Today we can protect words, but 
not values. So if a word is used for an indirect value, we can kinda 
change the word anyway (I say 'kinda', because we change the value, 
the word points to):

>> a: "a string"
>> b: a
>> protect 'a
>> change b "hmm"
>> a
== "hmmtring"


My idea is, that if we were able to protect values producing constants, 
this idea could be used to guide the creating of objects. And Copy 
Semantics could maybe be a lot simpler.

Submit your comment to the blog, please ...

Done.

Just for those ones who don't test.

To have the R2 behaviour of MAKE in R3, use COPY instead (without 
refinement).

Will images within objects be handled the same way in R2 and R3 then? 
;-)

i'ts not modified

R2 behaviour:

>> o: context [img: make image! 100x100]
>> o1: make o []
>> same? o/img o1/img
== false

R3 behaviour:

>> o: context [img: make image! 100x100
>> o1: copy o
>> same? o/img o1/img
== true

I don't think, your statement holds.

well

my mistake, but it's better that way, no ?

Would this seem like a REBOL way to create a constant?

define s "a string"

Used e.g. in an object this way:

o: context [
	define s "a string"
]


s can then be used as any other word, except it can't be modified 
(both the word and the value), and it won't  be cloned, when creating 
new objects from o.

Steeve, I can't judge that.

To me, the best way is, if the rules are so simple, you're never 
in doubt when programming. I compare these rules to operator rules. 
In REBOL, operators are evaluated left to right. It's a lot easier 
to remember, than having to look at page 53 in "The C Programming 
Language" every now and then, when I program in C, because I can't 
remember all those rules.


I guess, it would be dead simple, if all values were cloned by default, 
when creating new objects. And then use constants for those, that 
you don't wanna have cloned.

I have never used PROTECT. Do you guys use that? Maybe a warning 
system would be better!? hm

Geomol - with new semantics, you can choose datatypes, which values 
will be copied - copy/types [image!] for e.g., or something like 
that :-)

Submitted my CALL complaints to CureCode. Let's see what Carl thinks 
about it ;-)

Yes, I know. Is it too complex with copy/types? To me, it seems a 
bit complex.

Honestly i don't see the interest to protect things.

All the Rebol scripts are plain texts so that they are readable and 
modifiable by any skilled programmer.

If we could compile some scripts or modules to prevent them from 
being inspected, i would say yes, i will protect some things.
but not currently.

From the docs:


COPY/types - specify as a typeset the values to be copied. Note that 
you can use /types without /deep, in which case the copy is applied 
only to the top level of values.


COPY/deep - perform the copy recursively on each value. If you use 
/deep without /types, it is assumed that you want to copy all series 
values (any-string!, binary!, and any-block!) but not bitsets, images, 
vectors, maps, functions, or objects.


I'm pretty sure, I won't be able to remember these rules, so I have 
to look it up, every time I use it. Result: I will probably not use 
it, if I don't really really have to.

Steeve, I sometime manage to accidently redefine words as TO. The 
result is, my script produce strange results, and it's a hard bug 
to find. I could consider protecting all the system words (there's 
a function to do that). But maybe better, if REBOL could give me 
a warning, when I redefine a system word (or maybe changing type 
of one of my own words).

If it's just for debuging purposes, it's a matter of habits.

Never used PROTECT to debug things because i have different habits

Do you accidently redefine words, you shouldn't have? Or do you have 
your own naming convention of words, so your own words will never 
be called the same as a system word? Or maybe you just are very good 
at remembering all the system words? :-)

Geomol - it might be complex, but it serves the purpose to define 
wrapper functions, like object, context, etc. So you can createy 
- my-picture-obj :-)

First of all, i use local contexts everywhere, so that if i redefine 
a global words, the bad effect is limited.

Second: I mostly don't use mezzanines because i want my code as fast 
 as possible. So, I only have to remember the name of natives.

Third: I love REBOL and practices it every weeks, so it's not a pain 
to remember all the words.

fourthly: Because of that, i never do such bugs (except in old times)

:-) Do you use VID?

I like your habit of local contexts everywhere. I try to have that 
habit aswell.

But sometime I manage to write code like:

context [

main: layout [
	from: field
	to: field
]
view layout
]

See the problem?

I see, you forgot to declare your locals

Right, sometime I forgot those inside layout blocks, and that can 
be hard to debug.

I would modify the VID behaviour instead, to treat definitivly that 
case

Yes, good idea.

This is a dirty hack of the LAYOUT function: you're warned if a set-word 
in the layout is not local.

use [x src][
	src: third find second :layout 'while
	src: first find src/forever block!

 insert back tail insert src [if same? in system/words x:][x [print 
 ["Warning:" x "is global var"]]]
]

for 2.7.6

Seems like I wasn't up-to-date regarding PROTECT in R3.

Geomol, you can protect values already in R3 with PROTECT. Request 
granted ahead of time :)

Yup, I think, it might be a good idea to use that to guide copying 
of content within objects, so we don't have to have this complex 
copy semantics. A rule could be: protected values are like constants, 
and they don't get cloned, when creating new objects. All other values 
get cloned.
Makes sense to me.

A problem is though, if I wanna change such a protected value anyway. 
Then I have to first unprotect, change and (maybe) protect again. 
Alternatively, REBOL would need a new flag on values, that mark them 
as "changable constants" or "not-being-copied values" or whatever. 
A rule could be, that such values doesn't get cloned, but they can 
be changed effecting all objects having them.

R3 alpha 81 out, with the new modules. The existing module docs are 
mostly correct now, though still incomplete.

The module docs were good before, but the module system didn't work 
the way specified. Now it does.

So, finally your changes applied? :-)

Yeah, and only two words were wrong in the released version :)

My bad, not Carl's. The errors caused by the two wrong words are 
minor.

BrianH: is new object creation method already in-place? Does it cover 
the changes, you were suggesting in the past? Or simply put - what 
you think should come next?

The new object creation method is not in place yet, but the R2-style 
MAKE object! semantics are working, as are the COPY changes.

Most of the changes I suggested in the past for object! have been 
implemented using entirely different methods, but they're there.

I would prefer that the next version work on the new object spec 
block and the rest of the copy semantics. The version after that 
can focus on splitting off the system context. After that, I would 
love it if the rest of the PROTECT bugs were fixed.

>> ? in
USAGE:
        IN object word
        Returns the word or block in the object's context.
ARGUMENTS:
        object (any-object! block!)
        word (any-word! block! paren!) 


IN allow a list of objects OR a list of words as parameters but not 
together.

IN context [a: b: 1] [a b] == OK
IN reduce [context [a: 1] context [b: 2]] 'a == OK


But the more powerfull behaviour, to be hable to bind a block with 
a list of objects is forbidden.


IN reduce [context [a: 1] context [b: 2]] [a b] == ** Script error: 
invalid argument: [a b]

Why ????