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

World: r3wp

[!REBOL3]

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
Henrik
25-Aug-2010
[4642]
is the SDK prebol available for R3?
Henrik
26-Aug-2010
[4643x2]
BrianH, was there ever talk about a function that returns only duplicates 
in a series?
(prebol question has been answered)
BrianH
26-Aug-2010
[4645]
I remember there being such a discussion, but it never really went 
anywhere.
Henrik
26-Aug-2010
[4646x2]
if I say "pretty please", can we have such a mezz? :-)
see r3 chat #4447 for discussion there.
BrianH
26-Aug-2010
[4648]
It would be expensive. And aren't we trying to make things optional 
now? It would complement DEDUPLICATE well though.
Henrik
26-Aug-2010
[4649]
yes, I'm not sure there is a way to make it in-expensive, but I've 
stumbled onto several situations where I would like not having to 
write and test it.
BrianH
26-Aug-2010
[4650x2]
These would make good library functions. Give me a moment.
Would it be alright to skip the /skip option? Then we can use a map! 
to do the work without too much overhead.
Henrik
26-Aug-2010
[4652]
I'm fine with that, but it would perhaps lose a bit of consistency.
BrianH
26-Aug-2010
[4653x2]
The problem with the /skip is that we would have to write our own 
hash function, or copy/part every record at least once, or go n^2.
The problem with the map! method is that we would have limits on 
what could be in the block.
Henrik
26-Aug-2010
[4655]
ok
BrianH
26-Aug-2010
[4656x2]
There's the 2-block method, which would only top out at n^2 performance. 
Or we could hybrid, using map! for non-structures.
Or we can do the remove-each copy [not find ...]  method, which tends 
towards n^2.
Henrik
26-Aug-2010
[4658]
I'm not sure if I can make a decision here.
Ammon
26-Aug-2010
[4659]
If you've imported a module and then updated the module and incremented 
the version of it and then call import again this time requesting 
a newer version than has been loaded shouldn't the module be reloaded?
Graham
26-Aug-2010
[4660]
One would think so .. can you even reload a module?
Ammon
26-Aug-2010
[4661]
The answer is yes!  However I'm not sure this is a good idea...

remove/part find system/modules 'module 2
import 'module
Henrik
26-Aug-2010
[4662]
anyone know if R3 RENAME will allow moving files and dirs now?