World: r3wp

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?

Henrik: yes, it is!

Back to ROUND for a moment. It seems so long ago...


I think the goal was to have things make sense to normal people, 
while still allowing Ladislav and John to have their way. :-) Most 
programmers just want results that make sense to them as humans.

Does Chat system work? Mine shows off-line ...

Most programmers just want results that make sense to them as humans.

I can agree with that. It would be a benefit, if it still make sense, 
when you think a little deeper about it.

I still find the equal operator with its trying to be clever about 
rounding errors in decimals a strange thing. Try this example:

for i 4.0 6.0 0.1 [print i if i = 6.0 [print [i "= 6.0"]]]

The last line output is:

5.99999999999999 = 6.0


So those two numbers are the same for the equal operator. Let's check 
it:

>> 5.99999999999999 = 6.0
== false

Now see what happens, if I let the loop run a little longer:

for i 4.0 7.0 0.1 [print i if i = 7.0 [print [i "= 7.0"]]]


Now the equal test within the loop doesn't become true. The last 
number output is 6.99999999999999, so this number doesn't equals 
7.0, like 5.99999999999999 equals 6.0. I know, we don't see all possible 
decimals, but that's not my point. My point is, that if equal can't 
cope with rounding errors always, then it shouldn't try to do it 
at all. (My opinion.) The current behaviour isn't a good thing for 
the language.

A side note: FOR doesn't allow money! as its start argument in R3. 
It does in R2.

I could of course use == instead of =, and then none of the above 
tests would be true. The reason I find the behaviour strange might 
be the way, PRINT output the numbers.

Geomol: you did not read the decimal! documentation. The fact, that 
(print i) prints 5.99999999999999 does not mean you know what I is.

I probably read it and forgot. I'll read it again. :-)

after a slight modification I get:


for i 4.0 6.0 0.1 [print i if i = 6.0 [print [mold/all i "= 6.0"]]]
5.9999999999999929 = 6.0

doesn't it look different now?

I'm questioning the "nearness" in equal. Another example:

>> 0.1 + 0.1 + 0.1 = 0.3
== true
>> 0.1 + 0.1 + 0.1 - 0.3 = 0.0
== false


STRICT-EQUAL returns false for both of these. Is the "nearness" a 
good thing to have from a language design point of view?

nearness

 is not equality, it is just symmetric and reflexive (no transitivity)

I just came across this yet again, when I was preparing scientific 
data using R2. I can deal with it fairly easily in R2 by using money! 
datatype with the FOR function.

money! datatype in R2? What is the advantage, when you ignore the 
ability to express the denomination?

I got all the decimals after a while with this:

for a 4.0 5.9 0.1 [print a]

so I changed it to:

for ma $4.0 $5.9 0.1 [a: load next form ma print a]

I'm not sure, why it isn't allowed to write this in R2:

to decimal! $4.0

Maybe just missed. It's fixed in R3.

I'm actually messing around with REBOL (actually R2) and been away 
from it so long I forgot a lot of stuff.  Anyway, was wondering how 
R3 is progressing.  I was just using parse and thought about rejoin. 
 For example, if we can parse something such as:

blk: parse "this, simple, csv, string" "," 


wouldn't it be cool to just come back along and rebuild it with something 
such as:

rejoin/csv blk ","

or have any deliminater you specify.

Geomol: "FOR doesn't allow money! as its start argument in R3. It 
does in R2." - Write it up as a wish in CureCode please :)

Paul, that function has been proposed as DELIMIT - not as REJOIN 
because that function needs to be low-level - but hasn't been added 
yet since there is no consensus about the feature set. No consensus 
means it goes in the library rather than the mezzanines. If you can 
make a version that is so awesome that everyone will agree with your 
feature set, we'll add it :)

I don't agree with such fundamental functionality of R2 to go into 
some optional library. Better to have some standard, than not. The 
same goes for easy read/lines equivalence. Dunno how current read/as 
turns out, if it will end-up as separate read-text or so, but we 
need easy way of having R2 analogy here. Those working with CSV data 
on a daily basis will greatly miss such features ....

hmm, there is a 'delimit function ... it seems to be renamed to 'split 
....

'dehex does not work as I'd anticpated:

	dehex "em%E2%80%94dash" ; s/b "em--dash" (where -- is em-dash)

More like:

	dehex: use [hx ch][
		hx: charset [#"0" - #"9" #"a" - #"f" #"A" - #"F"]
		func [text][
			parse/all text: to-binary text [
				any [
					to #"%" remove [#"%" copy ch 2 hx] ; change <> remove insert
					(ch: debase/base ch 16) insert ch
				] to end
			]
			to-string text
		]
	]

I need a map! with 60'000'000 entries. But in R3, I cannot do that:

>> make map! 500'000
** Script error: maximum limit reached: 500000

Why the limit is so small?

CC it, please ...

I think that some things are settable, via enchant or so function, 
e.g. stack size, but not sure ...

Ok, I will CC it.

Thanks Brian, I'll try to look up the discussions regarding DELMIT 
tonight if I have some time.

This:

parse "this, simple, csv, string" ","


I believe was meant to be removed, because it's too obscure. I think 
the intended function for this is SPLIT.

I didn't know that.

I don't know if it has been removed yet or if that will be a 3.1 
feature.

Back to my question (a long time ago :-) May I assume that the behaviour 
I wrote about in my question is a bug? A probe works, but anyhow 
the window won't move anymore.

what happens if you change show-later to show?