World: r3wp

IMO focus should be now on bug-fixing and closing open tickets. There 
is still some smaller things to do on the AGG side. And than get 
a V1.0 out of the door. Because I don't see any cause to not make 
an offical V1 release of R3 anymore. It's mostly ready for prime 
time.

I posted in R3-GUI as I consider it being "your group" :-) Well, 
1-2 month bug-fixing could be usefull, but I know ppl - noone will 
consider R3 ready, unless the basic infrastructure is in-place. And 
not having tasking/IPC is one big handicap - e.g. Doc will surely 
not start the Cheyenne transition (if he will port it at all) ..... 
that's how I feel about it. 'Call needs to be implemented too, or 
R3 stays in isolation for system related scripting. Your aproach 
limits R3 to only GUI realated usage ... if we are rushing to have 
R3 1.0 stamp on it, then priorities, or simply target feature-set 
should be discussed, and set ....

until R3 supports threads, I don't think we should consider it beta. 
 this is too big a hole in 2010 for it to be sidestepped and ignored.

adding threads *could* have far reaching implications in many little 
areas of R3.  I woudn't want to start a big project and then realize 
that its broken after a thread enabled release.

Robert: I presume that your comment that R3 is mostly ready for prime 
time relates to R3 on Windows

with async callbacks, we can even implement device supporting libs 
now. so the callback is a BIG step forward.


congrats to Carl to pulling this one off without disrupting anything 
in the extension/host-kit API.

I just wonder, why Carl regards it being a preliminary release, and 
that the concept has yet to be proven - is there any other way than 
using events? :-)

There may be something else he wants to do. He has mentioned briefly 
a method for creating MVC based GUIs using ports and events, thus 
making that a low-level feature. This would require a small bit of 
code, but I don't know if it affects tasking. I don't know what else 
that means, because that's all he said about that.

'read is broken in the latest hostkit

Is doc coming back?  He hasn't been here for over a month

we was on vacation starting end of july.

You went together?

we = he

:-)

we
 could have been interesting

I'm on vacation too.  :-)

Today I read about the MUI (Amiga). Some ppl still consider it being 
kind of good aproach to GUIs, and now AROS is getting it too. I mean 
- if Carl wants to look at some low-level framework, MUI might be 
the system to study ...

... but - then we are getting into Max's territory of GUI aproach 
... so Max - better release your stuff, before Carl does so :-)

hasn't carl been given an Amiga 500 or something?

so he can port R3

He was given an Amiga, to port R3 to OS4 IIRC. That will surely not 
be A500 :-) I wonder how fast would View be on A500 though :_)

There are some new A500 ... accelerated

the latest Amiga "clones" can emulate just about any Amiga but magnitudes 
faster.

I saw a video that Henrik linked to ...

minimig ??

I really think, that the last big element missing is tasking/IPC 
interfacing. As Max said - it might influence other subsystems, so 
I think that such stuff should follow callbacks ... and then adding 
features here or there would be OK for 3.1, 3.2, etc. Maybe one other 
thing - rework decoders/encoders to ports asap, before ppl write 
some codecs to later find them useless ...

btw - Genesi's smartbook (Motorola's ARM CPU) might be around the 
corner too - http://bbrv.blogspot.com/2010/08/smartbook-gift-box-comparison.html

http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=777

Where's the information on codecs?

The Amiga he received was a Sam440, delivered by Steve Solie from 
amigaworld.net, AFAIR.

The intent is to have R3 running before the Amiwest show in October 
on that machine.

crazy prices for a sam440 board

probably the best they can do for now.

I'll have to do a few more bounties before I can justify getting 
a board ....

http://www.zdnet.com/blog/security/google-pays-10000-to-fix-10-high-risk-chrome-flaws/7199?tag=nl.e539

bounties for finding bugs ... do we need this?

btw - so we have got callbacks. As I can't see any real examples 
(probably too early and everybody busy), could anyone share an idea, 
how are they usefull? I know that "some" external libraries might 
require them, but any concrete example?

OpenGL GLUT events are driven by callbacks, which we can now push 
into REBOL "user space".


so for example, you provide an on-key() or on-mouse-down() callback, 
and you receive the events, directly at the function.

that sounds cool, doesn't it? :-)

yep.

all this nice stuff can be seen as a real ... enabler. I vote for 
the tasking/IPC being next, changing codecs to streamed port model, 
and then marking R3 Core a beta .... but not sooner ....

after we get those two, most of the framework will be ready for the 
prime-time ...

with a few more network schemes I agree.

yes, but network schemes are done on top of the framework itself. 
Adding them, does not influence the Core itself, while I fear, that 
not having tasking in the beta, could also mean, that later on it 
migh generate the need to change our code ...

yep, but I mean that the network schemes are important and should 
be part of the beta phase.  we don't have much working right now.

the tasking/ipc HAS TO be part of the beta. It will influence module 
code, etc. Codecs might come for 3.1 (unless we produce lot's of 
codec, which will change later)

yes - simply put - releasing R3 should mean, that ppl can do at least 
the same work, as using R2, or we have got a regression ....

I don't see tasks as that important as callbacks. Can someone please 
make a clear business-case for tasks? I know it's nice and helpful 
for some areas but is it mandatory?

I try to keep away as long as possible.

architecture can't be driven only by the business case point of view 
imo ...

well, given that REBOL isn't the fastest at processor intensive work, 
anything that could help spread things out over multiple cores would 
be welcome