r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Graham
23-Aug-2010
[4592]
There are some new A500 ... accelerated
Maxim
23-Aug-2010
[4593]
the latest Amiga "clones" can emulate just about any Amiga but magnitudes 
faster.
Graham
23-Aug-2010
[4594x2]
I saw a video that Henrik linked to ...
minimig ??
Pekr
23-Aug-2010
[4596x2]
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
Graham
23-Aug-2010
[4598x2]
http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=777
Where's the information on codecs?
Henrik
23-Aug-2010
[4600x2]
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.
Graham
23-Aug-2010
[4602]
crazy prices for a sam440 board
Henrik
23-Aug-2010
[4603]
probably the best they can do for now.
Graham
23-Aug-2010
[4604x2]
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?
Pekr
24-Aug-2010
[4606]
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?
Maxim
24-Aug-2010
[4607]
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.
Pekr
24-Aug-2010
[4608]
that sounds cool, doesn't it? :-)
Maxim
24-Aug-2010
[4609]
yep.
Pekr
24-Aug-2010
[4610x2]
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 ...
Maxim
24-Aug-2010
[4612]
with a few more network schemes I agree.
Pekr
24-Aug-2010
[4613]
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 ...
Maxim
24-Aug-2010
[4614]
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.
Pekr
24-Aug-2010
[4615x2]
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 ....
Robert
24-Aug-2010
[4617x2]
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.
Pekr
24-Aug-2010
[4619]
architecture can't be driven only by the business case point of view 
imo ...
AdrianS
24-Aug-2010
[4620]
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
Pekr
24-Aug-2010
[4621]
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?
AdrianS
24-Aug-2010
[4622x2]
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
Robert
24-Aug-2010
[4624]
IMO bug fixing should be the focus.
TomBon
24-Aug-2010
[4625x2]
robert, task, non blocking interfaces?
async only is not sufficient for this. tasks are essential for commercial 
developing.
Maxim
24-Aug-2010
[4627]
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.
Robert
24-Aug-2010
[4628]
R3 handles events on a timer base. So there is at least a way to 
do cooperative multitasking.
Maxim
24-Aug-2010
[4629]
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.
AdrianS
24-Aug-2010
[4630]
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
Robert
24-Aug-2010
[4631]
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.
AdrianS
24-Aug-2010
[4632]
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
BrianH
24-Aug-2010
[4633x3]
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.
AdrianS
24-Aug-2010
[4636]
oh well :-( , better low level multi-core support than nothing - 
what synchronization constructs have been talked about so far?
BrianH
24-Aug-2010
[4637x2]
None: We haven't been talking about it yet. There has been some speculation 
that PROTECTed data could be shared, and the "user context" is supposed 
to be task-specific (designed that way, not task-specific yet). But 
the PROTECT security model isn't finished yet (there are tickets 
yet to implement), and nothing has yet been done to make it tasking-friendly.
Strangely enough, the only thing about tasks that works so far is 
tasks themselves, as long as you don't trigger any errors.
Pekr
24-Aug-2010
[4639]
AdrianS: for what have been discussed so far - http://www.rebol.net/wiki/IPC_-_Inter-process_communication
Graham
25-Aug-2010
[4640x2]
http://blog.sitescraper.net/2010/06/scraping-javascript-webpages-in-python.html
http://blog.sitescraper.net/2010/06/scraping-javascript-webpages-in-python.html