World: r3wp

that first line is all I can say that that's related to R3, from 
the batcave. 


I *might* have some very exciting news late june, regarding something 
unrelated to R3 though  ;-)

the command! rewrite was exposed by Carl a while back, Brian can 
probably give more precise details.

PeterWood, when ++ and -- were originally proposed, I called them 
INC and DEC. They changed to the C-like naming later. The behavior 
is good, but the names confuse the very C programmers they were supposed 
to be a shout-out to.

I still prefer INC & DEC

(for that very reason.  It creates assumptions, which cannot hold 
because of the semantic differences between REBOL & C).

Same here. Especially since the other half of my proposal was INCREMENT 
and DECREMENT functions that did the a: a + x operation. But that 
ended up being too many characters for something so simple.

brian, do you think it would be possible to have postix operators 
in REBOL's do dialect?

yes

...but only taking one argument

ok, since post fix are usually unary operations I don't see that 
as a limitation.

nevertheless, it is not worth the mess

I agree, I was just wondering.

You could have an op! that ignores and passes back its second argument, 
if any. It would be tricky, and destroy the evaluation of the argument 
following it.

Any other solution would require changing the DO evaluation rules.

yes I can see that there would require a little change in the op! 
datatype to let do know how to handle values before & after, but 
the dialect itself isn't limited in the sense that it couldn't be 
modified...  just being curious for discussion's sake... not a request

All ops take two arguments, according to the evaluation rules. In 
theory, the evaluation rules could be changed to allow an op to take 
one argument, the left one. Or maybe that would already work - we 
have to wait for user-defined ops to be sure either way.

Maxim - if your news is not related to R3, what is it related to 
then? :-)

a special use of R3 ;-)

Brian can probably give more precise details.
 - No, but perhaps a more precise guess.


Currently a command! contains a reference to a dispatcher (handle 
to the extension, which contains an RX_Call function) and a selector 
(an integer). In theory, the implementation of a command! could include 
(or be) a bit of native code - that is generated at command! creation 
time - to call the dispatcher with the selector, and the address 
of that native code could be provided to an external native function 
for the native function to call. The native code inside a command! 
or its dispatcher would need some kind of synchronization stuff too, 
to manage the transition from external to internal process models. 
Or we could get a callback! type, which would have a GC-safe reference 
to that native code and the dispatcher. Either as the standard command! 
type or as a callback! type, when used as a callback the function 
would need to be GC-safe because external native code doesn't track 
REBOL heap references.

Or we could end up with something completely different :)

Peterwood not only C/C++ the ++ operand exists in most of the languages 
now in days compiled or interpreted... (python, perl, tcl/tk, ruby, 
java, etc...)

most people want i++, instead of i= i + 1 but i always thought the 
right operand instead of "++" should be "=+"  somthing like i=+ is 
in my opinion more explicit...


Pekr; some time the Carl says things we can't understand and mainly 
cause we don't have a full view on the source code he is talking 
about...

modular coding is obvious but  you have several ways to realise it... 
puting preporcesor flag to include or not part of the code when you 
compile is one solution

having them indeferent folders and binaries or libraries is another.. 
And that was always one of my  biggest comment rebol wants to do 
all every where so it ends being

weak every where and doing incompletly most of the things it pretends 
to do ...

http://eclectic-pencil.blogspot.com/2010/02/rebol-3.html

Nice :-)

He is still less desperate, than some of us :-)

he can read the chat thru a browser .. no need to fire up r3

or can we script the login, and download of new messages :)

Can we? Does R3 chat have an API? I mean - there are commands, but 
can we script it? Dunno how ...

http://www.rebol.com/r3/chat.r

Hmm... Script Error: This script needs View 2.100.28 or better to 
run correctly
So, why does a console app need view ?

auto-login: func [/force] [
            all [
                any [force prefs/auto-login]
                prefs/user
                prefs/pass
                attempt [login-serve prefs/user prefs/pass]
                true
            ]
        ]

Should be able to modify chat to autologin, check for new messages 
and then quit.

I wonder what sort of flood protection there is ...

Hmm, so we can only have 255 Windows?I thought I will make small 
stress-test one day, opening 10K Windows under Vista :-) IIRC, my 
friends did something like that with AmigaOS, and it still worked 
:-) http://curecode.org/rebol3/ticket.rsp?id=1610&cursor=1... anyway 
... this is imo unnecessary limitation ....

Graham:

If I want to set something to the index of a series, or something 
else if it's not there I have to do this

b: either a: find series var [
	index? a
][ 	default ]

when I'd rather do

 b: any [ index? find series var default ]

So how about letting index? also take none as an argument ?

Interesting idea, Graham. It's not that dissimilar to the recent 
proposal that EMPTY? take none. CureCode it :)

index? none 

+1

 :-)

http://www.curecode.org/rebol3/ticket.rsp?id=1611

Done

Cool, thanks! We can post a comment to the EMPTY? none blog mentioning 
this ticket as well :)

Done. Also tweaked the ticket to be more specific, and added a comment 
in favor of it.

I can make a prediction, Gradually, other functions will

be modified to propagate the value # none instead of returning an 
error.
This is only the beginning.

Seriously people, get to know and love ASSERT. You are going to miss 
those errors someday, to help you track down and prevent data corruption.

Steeve are you against the idea?

On the contrary, I''ve always been for :)

hard to tell :)

My comment also showed the downside: You will no longer be able to 
rely on INDEX? returning an integer. Though in balance I am in favor.

I dislike useless error bombing, as I already said

I want to write simpler code too

I hate having to trap for errors when I always have a default behaviour

#none is the ideal pass-true value. All your codes would be delighted 
by such feature

I also dislike useless error bombing. Though I am in favor of *useful* 
error bombing; not the case here though.

*pass-thru