World: r3wp

Maxim, the mezzanine will be fast enough, and secure enough. It doesn't 
need to be native in R3 to be fast and secure.

It's just one line of code, and not even a complex line :)

R3 97 released for real.....long list of Curecode issues addressed:
   http://www.rebol.com/r3/changes.html

I have had 97 for some time now.

The Core version was released experimentally a few days; View is 
more recent.

eh?

we are waiting for 98 ...

Sunanda, the core a97 versions released experimentally this week 
are more advanced than the View versions released a while ago - they 
are a preview of the 'self changes in a98. Which looks like it will 
be a great release :)

A98 changes to binary! - http://www.rebol.net/r3blogs/0314.html

Apologies for spreading confusion.....Got  my version numbers mixed 
up.

Brian - upcoming release will contain fix, allowing compressed modules. 
For A99, we could schedule some 'protect fixes, to finish security, 
no?

removing graphics?

yes, probably temporarily ... till Carl finishes its move to Host 
kit ...

I wonder what changes Carl will make to compressed modules now that 
they can be more efficient due to #1452 :)

Is it by design that "set" functions like UNIQUE, UNION, INTERSECT 
and others don't allow blocks containing values of type NONE!, UNSET!, 
PAREN! and maybe others (all of which R2 happily works on)? It's 
not that the docstrings or docbase did tell that it is intended behaviour, 
but at least they show some consistency in their behaviour, so I 
wasn't sure if this is something to curecode?

Your question should be in CureCode, in my opinion

BrianH/Ladislav - what do you think of Carl's opinion to add (back) 
to R3 struct like dtype, or function, to allow better binary to integer 
conversion? ( http://www.rebol.net/cgi-bin/r3blog.r?view=0314#comments
)

Struct! in R2 is great, especially to optimize (memory and speed) 
data conversions.
I give my consent :)

Put your comment in, then :-)

Something like, Yeaaah !!!! do it !!!! ?

yes, because Carl needs some convincing sometimes, that it is worth 
to put the effort to get the feature in ....

About remove-each in R3, I dislike the new given output (numbers 
of values removed).
What the point to discard the most powerful feature of Rebol ? 
- Chaining operations on series.

Besides, To count how much values have been removed is trivial to 
do and a very rare use case.

Pekr, note that he said "I think we need to add back to R3 a struct-like 
datatype (or function.)". I think that the function option would 
be more powerful and less awkward to use.

Steeve, the ticket for REMOVE-EACH is #931. Please make your comments 
there.

Either way you are discarding a feature. The question is whether 
the remove count or the chaining is more important. You and I seem 
to prefer the chaining, Carl seems to need the remove count (for 
reasons not given). Between the two, the chaning is easier to work 
around not having than the remove count is.

ChristianE, It seems like an oversight to me. We aren't doing the 
SQL-style "null doesn't equal anything, even other nulls" model in 
REBOL.

Pekr, sorry, you did mention "or function" :)

:-)

BrianH: time to push protect related bugs for implementation, no? 
Aren't they keeping us back from having security fixed?

about time ... empty? none

yes, done ...

hmm... diffferent solution from my NEUTRAL? suggestion.

Yes, protect bugs, but not for a98. It's actually been good to put 
them off: It's given us more time to really think about them. Security 
is a hard topic. Unfortunately, my proposed changes are flexible 
enough, but will need a lot of chaining to get the right pattern 
and recommended chaining patterns will need documenting.

I use this 

something?: func [ o [any-type!]][
    all [ o not empty? o ]
]

I would like to come up with a simpler solution that anyone can get, 
but I'm afraid this is likely not possible given the topic.

Graham, you would need to either refine the code or the typespec. 
That's not right for most types, and not safe for function types.

I just use it for series

something?: func [ o [series! none!]][
    all [ o not empty? o ]
]

Ah, good, then it's the typespec that would be refined :)

bette?

(you beat me to it) Yes :)

With the revised EMPTY? you could do this: false = empty? o

something is better than nothing

nothing? is not something?

Something is only better than nothing in some circumstances. "What's 
wrong?", "Something" :(

for me nothing is an empty series or null

actually I would prefer that empty? also is true on a series containing 
spaces only ...

when proceessing input

It's good that you have that function then. I prefer to think that 
an empty series or a series full of spaces is something, and that 
none is nothing.

However, it may not be the something you want.