World: r3wp

but, I don't think this is necessarily the issue here. The issue 
is just that the design is being move from being more interdependent, 
and based on DELECT, to being more abstract and independent and based 
on commands.

this is a lot of things to change in the code, but I disagree it's 
a big difference design-wise.

IIRC even for R3, while Cyphre has access to View sources, he does 
not have access to Core sources. So the final integration still has 
to be done by Carl. That is my understanding. That is why Cyphre 
is waiting with some improvements, for Carl to finally externalise 
View, so that we don't have to wait for Carl anymore to patch things 
in ...

Petr, R3's View does not share anything with R2 View AFAIK

So you were talking R3 only?

of course.

I wonder what happens to DELECT itself. If we will use command interface. 
Will DELECT still be any usefull?

R3's View has always been "external" in the sense that it was in 
the host side. I have seen its sources. the interface between host 
and rebol dll (core) has gone through a couple redesigns (starting 
with the Unicode changes), but in principle View has always been 
"separate".

so my point is, a lot of code changes (due to C not being a very 
nice language from this point of view), but the design itself is 
not going to change very much IMHO. since Carl is a perfectionist, 
he won't release a host that is just "half done" or something like 
that.

I believe command/DELECT changes are being made for good, so that 
we can use it also for other extensions. The only thing missing for 
Extensions then is - Devices integration and or callbacks?

ARM smartbook to port R3 to :-) http://bbrv.blogspot.com/2010/05/moving-to-mass-production.html

I was surprised  that the ++ function returns the value before the 
increment. I believe this is counter intuitive especially when  in 
C-type syntax ++ as a prefix increments the value before it is used 
as opposed to ++ as a postfix where the value is implemented afterwards.

So ++ i in REBOLl is equivalent to i++ and not ++i.

Gab, yes I actually have some secret little links into the batcave 
 ;-)


but I don't have specific details beyond the fact that he is commited 
to the view extraction and that its not a piece of cake.


the rest of my comments really are just by obvious architectural 
analysis and having tried to plug into the core myself and realizing 
how much is still missing to provide an integrated GUI which cooperates 
with the core.   even the event/device/messaging system isn't totally 
usable externally right now.


the command! concept is being rewritten from the ground up so it 
supports some kind of contextualized operation (could this be the 
basis for callbacks into the core?  :-)

and when I mean design changes, Its realy things like: 

   before we could call an action directly within a face... there is 
   no callback procedure in R3 hostkit beyond running a string in the 
   global context.


   there is no object/function support in the extensions, cause that 
   opens up a big can of worms (and some secrets into the interpreter's 
   operation?).


   the current R3 relies on the protection it has living within core, 
   now, Carl will have to open up the core a lot so that he can plug 
   back into it, and yes, since Carl is a perfectionist, he won't allow 
   that openess to be a security risk or half-assed solution.

the command! concept is being rewritten from the ground up so it 
supports some kind of contextualized operation (could this be the 
basis for callbacks into the core?  :-)
 - heh, interesting!

Is it just your guess, or is it the info from the bat-cave? :-)

just my guess.

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 :)