World: r3wp

thank you Sunanda and BrianH. i will test it

JAVASCRIPT

why not rebol ,,, serriously if you have to fall that low as using 
javascipt + QT for you gui only to say we do quick qt developpements 
why not using rebol?

and rebol would be the perfect match  for a light weight extensive 
os like meegoo more the  time pass and more the oportunities to make 
rebol find it's way out are wasted  one after other

the actual big rush in computing area is all in one webrowser no 
such deferencies like local or distant applications will exists anymore 
and in a way rebol/desktop was pioneer in that scope

where are we 10 years later ?

http://meego.com/community/events/presentations/rapid-development-meego-using-qt-quick

that's what marvelous things the industry is coocking while we are 
endlessly stuck in alpha stage

but at same time what happend in R3 project is somewhat some of the 
coolest thing I ever seen a true complicity is rising between carl 
and rebolers. unfortunatly that's not the kind of things easy to 
communicate around. but yes 3 years of alpha stage because the reboler 
community really involved in the creation bringing at every steps 
their comments  etc ... so it's arsh to say that's a fruitless tree 
of efforts

Max... I'm curious... how do you know that Core was not designed 
for View to be extracted? Did Carl tell you this or are you guessing? 
Because, you know, Core was developed by Carl and View by Cyphre, 
and Cyphre never had any access to the Core sources.

Which makes me wonder about this separation because there's always 
been a core product

Gabriele - Max is imo right, sorry. I screamed for proper "componentisation" 
of REBOL since 1997. I requested there would be only one kernel (rebol.exe), 
and the rest being loadable components ...

What Max is describing is changes to API in core, in order for View 
working as an extension. It is not just the question of stripping-out 
View related functionality, but to create Core API, which can communicate 
with View extensions (or the other way around). But you know that 
for sure, as you know architectures better than me surely ...

View was not developed by Cyphre. Original View was developed in-house, 
by Jim Goodnow (Carl's friend from Amiga days (author of Aztek C, 
or something like that). What Cyphre did was adding AGG in there. 
Cyphre often tested AGG functionality in form of a DLL, externally 
then Carl patched it in into View IIRC.

Petr, being separate as a separate binary is a different concept 
than being a separate module in the code. View has always been "optional" 
even in R2. Having it as a separate binary means that you need a 
way to "load" it, and that's not trivial if the external part has 
to be able to call in to the internal part.

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