World: r3wp

CLEAR and REMOVE of none just return none and don't complain. This 
allows chaining without needing conditional code.

Both very fast - no real difference between them:

Jerry's original took             0:00:00.355178

John's version took             0:00:00.061354

Parse version took              0:00:00.129759

Brian's 1st version took      0:00:00.056886
Brian's 2nd version too k    0:00:00.051447

The type test in the argument list might be taking a little time. 
Try John's with the type spec. I'm curious to see what the difference 
is.

I mean the [any-function!] part.

Is struct! working in actual version? If so some example would be 
handy!

To Brian I've read your description between FUNC and FUNCT in DevChat. 
Never seen such summarizing description anywhere, but I think it 
is very usefull not for beginners only but for everybody not so hawkeyed 
as gurus. This should be mentioned in docs, or even better short 
lectures shall be written about such "deep lake" details (to reproduce 
Carls definition)

Adding the type spec didn't make any significant difference.

I think that struct! and routine! are there left-overs from R2, and 
will be removed, as we are not going to get DLL interface, I wonder 
what those two datatypes would be good for. Maybe struct! might be 
usefull, if made more powerfull, dunno. Our interface is now Extensions.

Yes Pekr and when you want to write Extension as generalDLL loader 
can you use a block! paramerer instead of struct, or better how to 
transform a block given as parameter of extension to struct needed 
as parameter of underlaying DLL.

Good to know, Peter, thanks. Type checking was sped up in R3 through 
typesets.

The R2-style struct! and routine! types are not working in R3 and 
are likely to be removed. The struct! type might be replaced with 
a new, improved, incompatible struct! type. The routine! type has 
already been replaced with a new, improved, incompatible command! 
type.

You are right that documentation is an ongoing problem. The design 
has been changing a lot during the alpha phase, but the behavior 
of FUNC and FUNCT are unlikely to change, so they could be documented.

I added a ticket to curecode about the math performance issue: Ticket 
#0001338

Have you tested with prefix form math? The implementation of op! 
has changed, and the new implementation would probably be slower 
(at a guess) but is more flexible. Please test with prefix math so 
we can categorize the ticket properly.

If functions like ADD and SUBTRACT are slower, this is an issue. 
If it is just ops like + and - then it is a side effect of user-defined 
op!.

The new op! behavior has allowed us to speed up DO quite a bit overall. 
It won't be changed. If you want fast math, use prefix functions 
or better yet extensions.

I tested under OS X with prefix math, and the same picture is seen. 
If it's because R3 isn't compiled for speed, then that might be the 
answer, so this isn't an issue.

Oh, duh, it's because integers are 64bit in R3, and Windows' 64bit 
integer math emulation is better than Mac's. Fixable :)

(still guessing though)

I was testing floating point math.

Another guess failed then. Back to the "hasn't been optimized enough 
yet" theory.

1. TCP question: where to get complete list of event types? lookup, 
connect , wrote, read, close .... what else, does exists the complete 
list? 
2. Is it possible to get other devices event types
3. is it possible to define "own" events?

Whwhere are the events defined?

Are the device events the same as GUI-events (meaning the machanism 
is the same or different)

AFAIK, that will all be revealed within the host code shake down 
 :-)


devices are defined in the host and will be extensible, eventually. 
 they all use the same low-level/high-level api using fully async 
handlers.

geomol, AFAIK, Carl doesn't use the same compilers on different plaforms, 
so that will invariably produce different results for the same C 
code.

I've read often that intel optimisations in compilers make some C 
code faster than assembly because they'll use special shortcuts in 
the cpu when they discover specific coding patterns.

If functions like ADD and SUBTRACT are slower

 - I'm not sure whether you mean are slower under Mac OS X  or slower 
 than + and -. ADD, SUBTRACT etc. are much slower than +.-.

Results on an old 1ghz ThinkPad:

 >> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]
== 0:00:21.5

>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]
== 0:00:17.25

>> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]
== 0:00:20.625

>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]
== 0:00:17

We mean slower on R3 than they are on R2. We need comparisons of 
both inline and prefix forms if we are going to optimize R3.

And we need platform-specific data too. It doesn't make sense to 
compare Windows and OSX, but it does make sense to compare R2 and 
R3 with each other on the same computer and OS. For that matter, 
there may be OSX version issues too.

The prefix forms in R3 are only about 20% slower than the inline 
forms in Mac OS X whereas they are over 50% slower in R2:

R2 results:
>> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]

== 0:00:06.096334
>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]              

== 0:00:03.679331

R3
>> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]

== 0:00:06.72179

  >> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]                
    

== 0:00:05.521236

Interesting... It looks like the op! changes weren't as bad for overhead 
as I thought :)

from my persepective, ops are now 150% slower than before.. this 
is VERY unfortunate.

From my perspective, DO is faster than before because of reduced 
complexity, and user-defined ops are possible now because they handle 
their own redirection instead  of DO special-casing it. An acceptable 
tradeoff.

It's a big picture balance thing. The optimizations were rebalanced 
in the change from R2 to R3 in order to increase overall power and 
speed of REBOL. REBOL has never been a math engine (not its focus), 
but now it can be because of extensions. Everything is a tradeoff.

notice I said "unfortunate" and not "unnacceptable"   ;-P

as you say, given the choice between how its in R3 and R2... "I would 
do it all again"  ;-)

Yes, but you said VERY, and that is what I was disputing. Only the 
ratio has changed. Overall performance has improved, which in many 
cases makes up for the increased overhead of Unicode and 64bit integers, 
among other things.

a nice parallel to R3 is python 3... just about every issue we have 
is also an issue in  P3 (unicode, R2 forward for example :-)... it 
took 3 years to build, and remember that python has NO graphics, 
only core release.   Also P3 has much less fundamental changes than 
R3 has, so in comparison, R3's implementation is at par with other 
interpreter updates.... except they are whole teams, where R3 is 
a very small team.


http://broadcast.oreilly.com/2009/01/the-evolution-of-python-3.html


P3 did require updating MANY modules, so most of the team probably 
worked on that instead of the language itself.

Yery little work was done on the language itself, mostly on libraries. 
Within its limits Python 2 was good enough for Python devs, at least 
syntactically. All they had to change was libraries and some internals. 
Still significant, but not on the scale of the R3 changes.

yep... and it took 3 years  ;-)

Most languages are going through the revamp nowadays, due to the 
Unicode and concurrency crisis, and the extent of the changes attempted 
varies from language to language.


Python 3 is on the more minimal end of the spectrum: Only Unicode 
changes, not paying attention to concurrency at all, focus on backwards 
compatibiity, no significant syntaxtic changes (the standards for 
syntax among Python devs is low), minor cleanups to its libraries. 
And it took them 3 years to do it :(


Perl 6 is on the more extreme end of the spectrum: Major changes 
in everything, including syntax, several complete system structure 
revamps going on at once, major semantics changes (not sure about 
the concurrency). Perl had an entire history of not being designed 
at all, so they had a lot of crap to get rid of. Which they replaced 
with much more new stuff (Perl doesn't know how to say No). 10+ years 
into the project, with no end in sight.


R3 started closer to the minimal end of the spectrum because we hadn't 
really been keeping track of how far behind we had gotten - not far 
behind the others, far behind our potential. As the scope of the 
changes needed became more apparent, the project rapidly went way 
towards the Perl 6 end of the spectrum. However, we had to do a couple 
restarts along the way. The current round has only been going for 
2 years, but gone way past the level of changes in Python 3, and 
has approached the level of change in Perl 6.

We had some advantages though:

- REBOL has been more designed than those others, over the years. 
That means that we are redesigining rather than designing.

- R3's primary designer is mainly into operating systems, so R3 is 
built like an OS, which makes more ambitious changes possible.

- We decided that R2 will be continue to be maintained as a separate 
project, so we don't need to stay backwards compatible.

- REBOL's design process knows how to say No, so we aren't falling 
into the Perl 6 trap.


All of these are why we have been able to accomplish so much in such 
a short time, with so little resources. It's taking a lot of time 
and effort to get the community to realize that R3 is a community 
project, so we've had to make the best use of the resources available, 
even when it meant taking some time off from developing to build 
the infrastruuctre for community development. This process work has 
paid off dramatically, so much so that comparing pace of development 
more than a year ago to that nowadays is completely irrelevant :)

and when Carl gives us the host he says now compiles again, comparing 
the next 12 month's R3 development will make the entire 10 years 
of REBOL development seem irrelevant.

;-)

:D

Not everyone realizes that Carl has spent a long time building a 
very strong lever.... might not be pretty... but its damn straight 
;-)


now he's about to give us a chance at holding that lever as a group 
and leverage all the work.  He's been putting all the effort to putting 
the pivot of the lever (the fulcrum) as close to one end as possible... 
so R3 will be very strong and allow to do much more heavy lifting 
than R2 ever could.


now we just have to paint the lever and make it all shiny (gui) put 
a nice handle on it (the host) and even add a few more handles to 
it (threads).


most of that... we can do as as group with a few helping hands working 
together  :-)

Being able to say No was a really big deal. It is why we had to build 
our own VCS and developer communications infrastructure, with moderation 
and ranking built in. We didn't have the benefit of years or decades 
of established community development, like Perl or Python - we had 
to do this from scratch. The only way we have been able to make such 
ambitious changes so quickly and cleanly is through some group discipline 
and politeness, and that means we need to have a counter-pressure 
against flame wars and development fights. We would have never managed 
to get this far without DevBase (R3 chat) and CureCode :)

Other than "Glue" (which is "still" my choice for a name for REBOL), 
I have to admit that "Level" is another good name.

Question about R3 GUI. On this page http://www.rebol.net/wiki/GUI_Example_-_Move_a_window
 is an example for moving a window. After moving it with button "Move 
to 100x100" I move it manually to another spot. When I then push 
button "Move to 100x100" again, the window won't move anymore. Is 
that a bug or am I missing something?

if you put a probe inside the 'do block for the button, is it printed 
like it should?