World: r3wp

Sure, I don't want to keep the date. I want to change it.

I guess, that what Izkata wanted to mention was, that it is not obvious 
in what direction should such a change be?

Ah... Since it's weekday, it's the same week. So, when current day 
is Sunday, we move backward. And if it's Monday we move forward.

There are countries that let the week start on Sunday...

ISO8601 supports the notion of Monday being Day 1 of the week, so 
Robert's suggested behavior would be ISO compliant.

But ... not sure this is an essential native. It would be a fun mezzanine 
to write, though.

Agreed

Besides bugs to be fixed and Carl's missing, what keeps R3 from going 
to Beta? Any new features?

Some functions still need to be finished compared to R2, such as 
SORT

And of course, there was this strategy that R3 can't be released 
before the GUI is finished

The licence is also still undecided

SORT is totally unnecessary for R3 to become beta, IMO (you can use 
any algorithm written in REBOL, e.g.

http://www.fm.tul.cz/~ladislav/rebol/msort.r

, etc.

It's in there, and it's incomplete and buggy. That's no state for 
beta

There are important issues, but surely not this one

Tell that to Carl

I did

So, dig he agree?

did

Hmm, he did not tell me he disagreed, but, otherwise, his priorities 
may differ

Carl's priorities are the only ones that matter

Linus Torvalds and CureCode #666 :)

    http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/ba-p/440

Antithetical to how some languages are developed ...

hi, do you know if a r3 gui for linux will be out soon or later ?

it will be "later".

In R3 Module Design Details, it says there is a function named SET-MODULE. 
I cannot find it in R3 a111. Anything changed?

Yeah, the whole module implementation model changed, twice. The docs 
reflect the second change. Sorry, been busy.

Sorry, the second version.

Thanks BrianH. Overall the doc is very good, I learned a lot.

I really need to update the guru-level docs, but someone else needs 
to read the updated version and write a user-level doc. I understand 
the details too well to be that good at explaining things to regular 
users.

It would be especially useful for the guru-level docs to explain 
the rationale behind the design decisions.

I might be able to do that as a by-product of learning R3 module.

Cool. I'll remember you said that :)

I have 10 days vacation, I am totally free before Oct 9th. I plan 
to read the R3 source code and refactoring my Translation Engine 
which was written in R3.

But as you can see, my Enginsh might not be good enough. That's the 
only thing that I worried about.

That might not be a problem - I am a better editor than a writer.

BrianH, I will send you a R3-Module Doc after my vacation for you 
to correct. Actually, I was a technical Editor in O'Reilly Taiwan. 
Of course, The books that I edited were all in Chinese.

Question for Carl? :)

   http://stackoverflow.com/questions/7577186/is-rebol-still-alive

I've read info out R3 Module Details from DocBase, R3 Blog and its 
comments, and source code. Many pieces of info are conflicted. It's 
annoying.

Yup. The source code represents the current intended design, though 
one question has popped up recently that didn't arise during the 
design process. The !REBOL3 Modules group here has a lot of info 
too. I hope to get the chance soon to go over the docs on rebol.net 
and update them to the latest design. I was going to do that last 
weekend, but I got really sick. However, I am using REBOL at work 
now for utilities, so I can afford to work on it again here and there.

I find that the source and the !REBOL3 Modules group are the best 
places to look for now if you want low-level docs and usage tips.

Andreas asked a lot of good questions :)

OK. Thanks BrianH. Take care of yourself.

Brian, regarding BIND, I mean e.g. this:

>> f: make function! compose/only [[a b c](body: [a do c])]
>> a: first body
== a

>> f 1 1 [a + b]
** Script error: b has no value
** Where: do f
** Near: do c

>> f 1 1 bind [a + b] first body
** Script error: none word is not bound to a context
** Where: bind
** Near: bind [a + b] first body

That is annoying, since it is actually false

here is how I can circumvent it:

The 'b in that case is just data, not the argument b. It's another 
word which has the same name but a different context.

yes, that is the unbound block, that does not matter

here is a way how I can circumvent it:

f 1 1 change [a] first body

Yeah, it is an interesting efficiency hack that MAKE function! does 
a BIND on the function body instead of a BIND/copy. It does mean 
that you need to be careful with the runtime accessibility of your 
source though.

MAKE function! does a BIND on the function body instead of a BIND/copy 
- it is not only for efficiency, it is actually the proper way even 
for safety

I do like that. but, nevertheless, the MAKE function is able to bind, 
while I am not, which proves, that it is just an artificial, (not 
making anything more secure) and annoying limitation