World: r3wp

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

just ask BrianH, how tasking/ipc might influence some core areas 
(especially module code). I fear we might face some incompatibilities. 
Well, otoh - when Carl finishes callbacks/extensions, what is your 
idea Robert, Carl should work on next? Even if it would be driven 
by some business-case?

but, IMO, parallel processing should be transparent - we should take 
a look at how F# exposes concurrent programming - really intuitive

I guess I can CureCode the request

IMO bug fixing should be the focus.

robert, task, non blocking interfaces?

async only is not sufficient for this. tasks are essential for commercial 
developing.

yes... most applications now are multi-threaded if only to make them 
smoother...  the GUI in one thread, heavy lifting in another, for 
example.


async, doesn't allow you to scale, only to time slice.   you can 
still only compute on a single request at a time.

if the request needs time to finish (rendering, for example), it 
effectively blocks all async and I/O handling.

R3 handles events on a timer base. So there is at least a way to 
do cooperative multitasking.

yes but you are still limited by the quantity you can process.  with 
just about every cpu out there now having at least two cores, its 
great waste.


with most of the serious apps I've done, multi-threading would have 
made things much easier or in the least smooth and interactive.  
with servers, I need not present a case, threading speaks for itself.

personally, I'd rather not have the focus be on "threads", but rather 
on concurrent or parallel programming - if done right, the user should 
be shielded away from inter-task synchronization as much as possible

Ok, maybe I need to make clear that I'm not against threads. But 
IMO it's better to get something done and finished now, and release 
it. Than keep the pace and concentrate on threads on the next release.

the word "thread" makes me think too much of the low level thread 
management that you typically do when that is the only concurrent 
programming construct

Most of the non-graphics mezzanine code is already tasking-safe, 
as that was kept in mind when we went over them early on. The module 
system would be most affected by tasking issues, but the necessary 
changes would be relatively simple since the refactoring is mostly 
done already.

Adrian, unfortunately that description may characterize the tasking 
model. For all its high-level features, in many ways REBOL is a low-level 
programming language. We don't have internal process separation, 
and we do have modifiability. The tricks that are done to make functional 
languages at all efficient require compilation, and we don't have 
that. Managing any of the new concurrency models requires changing 
the core semantics of the language and we aren't doing that much.

We will be able to build higher-level concurrency models in R3, but 
the core model is very low-level and requires a lot of manual management. 
I suppose that's rather REBOL-like since that can be said about binding 
and scoping as well.

oh well :-( , better low level multi-core support than nothing - 
what synchronization constructs have been talked about so far?