World: r3wp

No, it doesn't exist, and would be one line of code. However, so 
would calling this function, so it doesn't save anything. Probably 
best to remove the reference/page.

there are a few of those on the list of function pages to remove

but, I'm about 40% through the list, and I'll compile a list of changes 
and things that need to be looked at.

is there an example of the use of IN-DIR ?

Cool. Tell Carl though - he's the one who knows how to remove pages 
in that wiki.

IN-DIR is used for file manipuulation code, when you need to change 
the directory for onne bit of code and then change back.

The old DevBase used to use it to handle its work directory. Don't 
know about the new one.

ok, thanks

Henrik, there's a currently undocumented /ONLY refinement for KEEPing 
block values with COLLECT, e.g.:

>> collect [keep 1 keep [2 3]]
== [1 2 3]

>> collect [keep 1 keep/only [2 3]]
== [1 [2 3]]

Some unlisted functions still...
intern, collect-words.
Probably some other

2.100.89 released - http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.89_13-Oct-2009

ChristianE, thanks for that one.

Added to the docs. If you find more errors or undocumented parts, 
keep them coming.

thanks for your time and effort Henrik... this type of volunteer 
work often (usually) goes un-noticed and it really is a lot of work.

Well, I do it to learn the parts of R3 that I don't know yet. :-) 
Going through all functions brute force without using that chance 
to write docs would be silly.

There is probably still going to be a lot of bugs and missing refinements. 
I noticed that some functions aren't written properly in the summary, 
and of course there are obsolete and missing pages.

still writing docs is time consuming... I know I don't have time 
to do the brute force right now... I'm still waiting for the extensions 
extensions to help out in that area of the docs.

It looks to me like some GUI functions like 'handle-events and 'base-handler 
that belong inside View are also available in the main context and 
are also listed in the docs. I assume those functions will disappear, 
once the GUI goes into a module.

I posted a note to the R3 blog article on a89 as I cannot get it 
to return a prompt on Win XP SP3  - I have tried getting r3-a89.exe 
to consume a script and tried not only under cmd shell but also under 
cygwin

I don't have an issue with it.

2.100.90 released ....

.... actually it will be released in something like hour. We have 
last hour to decide, if we eventually want to rename parse 'loop 
to 'while ....

Modules in binary compressed format - http://www.rebol.net/r3blogs/0274.html

A90 now also for Linux and OSX

Both fine on my Untu and XP. Whatever.. BTW, was there ever a chat 
about assert {}   I am spending some time in Groovy and thinking 
about the errors in a Rebol book: the Manny Groovy book was generated 
so at least the code examples run ... groovy uses assert a a good 
deal ... which got me to thinking about REBOL  comment {}  which 
seems to suggest that we could have an assert {}  which is evaluated 
only when a REBOL option is set. and have it default to OFF

Oops - so funny - I went to look at rebol.org for any use of an assert 
but there it is  assert  in the R3  docs   missed it ...  but can 
it be flipped not to run?  Or would you just  set assrt: :assert 
 and wrap it?

assert is used like any/all to quickly provide integrity tests.

we had assert back in Smalltalk SUnit ... ;-)

Let's comment on the compression format - http://www.rebol.net/r3blogs/0275.html

To not to be able anymore to reduce this [( )] at this [ ], is really 
annoying.

I have to clean my reduced blocks from unset! values returned by 
called functions.

Really, I don't  understand such modified behavior in R3, what's 
the gain, what the purpose ?

WHAT?  this is totally unusable.  ALL of my code depends on the  
"reduce this [( )] at this [ ]" philosophy at some point.

is the same with compose?

No, it's ok with compose, but i can't change the reduced blocks to 
composed blocks, it would destroy the sake of my project

I just want Carl or someone explain to us what is the gain of such 
change.
It's just causing wrackings currently

I see absolutly no interest.

this is really annoying and like you, I see absolutely no real-world 
usage ... it sounds more like an oversight on carl's behalf.

like... oops ... forgot to remove unset values in reduce native.

in the meantime, you can just make reduce a mezz , call the native 
inside of it and remove unset values... at least its going to be 
done automatically... although it will slow down your code a bit.

you should post on curecode for this.

it's what i doing currently, a remove-each of the unset! values

did you post this to curecode?  carl will definitely give aheads 
up on the issue quickly.

(Arghh !!! Stupid busy Altme, it lost my note again)

Not a bug

why is this not a bug?

it's an willing change of the design from Carl, long time ago.
It's not recent.

but he never explained such change, IIRC

posting it to curecode is a good way for him to see that a change 
isn't beneficial in real world use.  he will comment it there, and 
it will be usefull as a reference for further users... I did a search 
for reduce on curecode, found a few things... but since curecode 
serves as a reference, this would be a good place to put your grievance.

IIRC, it's to optimize the dialect's parsers using the function DELECT

all changes are well explained in curecode tickets when people complain 
about them.

some tickets have VERY in-depth explanations of R3 quirks wrt R2. 
 this would be a good addition... cause it surely will come up again.

but i would rather prefer, a special reduce function for his dialects, 
instead of enforcing us with such drawback