World: r3wp

just a joke to try to generate a coverflow animation.
REBOL []
angle: 10
angle2: 0
decal: 0x0
rot: 0
scene: [
	transform angle 50x0 1 1 0x0
	pen red fill-pen red circle 70x0 2
	pen green fill-pen green circle 85x0 2
	pen yellow fill-pen yellow circle 100x0 2
]
scene2: [
	transform angle2 decal 1 1 0x0
	pen red fill-pen red circle rpair 2 
	pen green fill-pen green circle gpair 2
	pen yellow fill-pen yellow circle ypair 2
]
img: copy empty: make image! 100x50
logo: copy logo-empty: make image! 200x100
locate: func [color /local idx][
	idx: (index? find/skip rgb to binary! color 3) / 3
	as-pair idx  // img/size/x to integer! idx / img/size/x 
]
view/new l: layout [image img image logo]
rev: false
for i 10 170 5 [
	angle: i
	change img empty
	draw img scene	
	rgb: img/rgb
	gpair: locate green
	rpair: locate red 
	ypair: locate yellow 

	either all [gpair/x > 35 gpair/x < 65][
		rev: true
		angle2: angle2 - 15
		decal: gpair
		change img empty
		draw img scene2	
		rgb: img/rgb
		rpair: locate red 
		ypair: locate yellow 
	][if rev [pair: ypair ypair: rpair rpair: pair]]
	change logo logo-empty
	b1: as-pair rpair/x 25 - rpair/y
	b3: as-pair rpair/x 25 + rpair/y 
	b2: as-pair ypair/x 25 - ypair/y
	b4: as-pair ypair/x 25 + ypair/y 
	draw logo [pen red scale 2 2 image logo.gif b1 b3 b4 b2 border]
	show l
	;*** PUSH ENTER TO ADVANCE
	input
]
do-events

could be usefull to generate the optimal coordinates

I've done a basic coverflow layout--no slick animation or reflections 
(too slow under R2 when I tried it)--but fully keyboard and mouse 
driven. Animation could be done, but hasn't been needed yet.

--no slick animation or reflections (too slow under R2 when I tried 
it)--

That's why it would be such a good test of R3 GUI.

If it's plain DRAW, then it may not be much faster, but I'd be interested 
in seeing benchmarks.

any good hopes on getting a public release of R3 in dec/jan as I 
think Carl mentioned?

I'm not sure about december, but January might be possible, but this 
is definitely no guarantee.

. .

From DocBase:

RebDev is the REBOL development community messaging system.
More 
soon -Carl

Yes, he has found a powerful way to add a communications system to 
DevBase. From what I've learned the server is running, so I'm guessing 
he's writing the client.

Not only for the DevBase, as far as I understand his words :-) We 
will see, hopefully Carl releases some details soon ...

Same he didn't called it xxxBase to go with DevBase and DocBase.

all these names begins to be a little bit cryptic

ok i give a code to Carl to help him ;-)

>> random/seed now print append "" copy/part random [Reb Dev Base 
Doc Rrr Bel Bad Bbs Srv Clt] 2

It sounds like he is just rebuilding DevBase with the missing features 
that were intended to be added to it. Good!

happy christmass ;-)

Anyone know the timeline for the next Alpha?  I thought Carl made 
it sound like it would hit the streets before Christmas.

ahah, you believe in santa claus, Paul, post your request in the 
Belief system thread instead

Hehe no Santa for me.  I don't follow Christmas.  I consider it just 
another day but one that can go by another name.

Definitely not by Christmas. ETAs in this case are dangerous to publish. 
It depends on what else needs to be fixed.

I thought we could release too. Good thing is, that Carl thinks, 
that we need to get many more developers on-board, and so he is doing 
some preparation work to handle the load.

Anyone know if in R3 that op! will be treated as an op! in a block 
before evaluation?

be nice to do something like:

op? second [this + that ] 


and have it return true.  I know it is a word value now but I never 
understood why it was made word there.

>> type? first [+]
== word!

wow, found a crash :-)

First RebDev version was uploaded to our private world a few seconds 
ago.

The first screenshot of the CLI interface:

http://rebol.hmkdesign.dk/files/r3/gui/174.png

Server is still running on R2 for reliability, but it was written 
in R3, so apparently it's compatible.

The client appears to be a bit over 20 kb of code and is fairly simple 
to use. Still some bugs left to solve, but moving quickly forward.

so all console driven ?

is it cgi or lns?

or direct tcp?

all console driven, yes. it appears to be plain HTTP as it runs off 
port 80.

If the RebDev serve runs on R2, how does it handle character encoding? 
Does it simply ue the default Windows codepage on the client machine?

I would not trust non-ascii characters for now. With any luck the 
server saves the messages as binary UTF-8, don't know yet.

The current client is console driven (old school BBS), but there 
will be many more clients.

The current server is implemented as CGI scripts, though FastCGI 
is planned for later.

Not trusting non-ascii characters infers  that the current desing 
of  RebDev is "ignorant"of character encoding. If that is the case, 
it is a shame as RebDev could have been a great example of an "up-to-date" 
application built with R3.

Doesn't this all depend on the limitations of the front-end used?

It has to be this way as long as the server is running on R2. Says 
nothing about R3 or the design of RebDev

Even if the server is running on R2, all the strings could be stored 
with a consistent encoding method, such as ISO-8859-1. Of course, 
there'd be a lot of work detecting the client encoding method and 
converting all input strings to the chosen consistent method. Most 
of this work would be needed even if the server supported Unicode 
strings.

Personally, I think ignoring character encoding does say something 
about the design of RebDev.

considering that R3 will probably just send everything as UTF-8, 
I don't think the server has any reason at all to worry about encodings.

you have to worry about encodings when you do conversions. i don't 
see where the R2 server is doing any of that. Also, with UTF-8 there 
is no need to worry about encodings on searches and things like that. 
The only issue could be sorting, but that is also region specific 
so it's a completely different issue that R3 cannot solve globally 
either.

As you say, if all the input is UTF-8 everything will be fine. I 
mistakenly thought that the inputs from different environments would 
have been differenlty encoded as they are with R2.

That would have to be the case with R2 clients, as the client is 
the part that handles character encoding. However, there are no R2 
clients yet. The messages appear to be UTF-8 encoded end-to-end, 
stored in binary on the server, which is encoding agnostic. Once 
we have R2 clients, they will have to handle the codepage-to-UTF-8 
encoding, or just stick to ASCII.

And yes, it does say something about the design of RebDev, that character 
encoding issues of R2 won't affect it, by design.

This is one of those things where a picture is worth a thousand words. 
 We need a diagram of the hardware and software set up, and show 
WHERE encoding becomes a problem.

For example, if you paste some text from a Word doc into a webbrowser, 
 this then gets moved to the server.  Then it gets rendered out again...you 
wil run into problems with encoding.

Word use some SPECIAL encodoing for things like " : - and '

That sounds like an issue between Word and the browser edit field, 
or between Word and the clipboard

RebDev now has a webfeed suitable for iPhone.

Reichart, I still think that is not the fault of Word (except for 
changing your character on you) or the browser.