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

World: r3wp

[!REBOL3-OLD1]

BrianH
28-Sep-2009
[18285x2]
The victory would be in speed and the fact that your replacement 
code was missing a :here, but your suggestion is nicer I suppose.
I'm OK either way.
Carl
28-Sep-2009
[18287]
The more basic problem is: we cannot do both. So, we must decide. 
 I kind of like Steeve's suggestion, because the old method is always 
a fallback for people who need more advanced methods.
Pekr
28-Sep-2009
[18288]
Let's not steal strategic discussion to parse arguments here, no? 
Blog is enough ...
Carl
28-Sep-2009
[18289]
In other words, we are inlining REMOVE to make it simpler for many 
users.
BrianH
28-Sep-2009
[18290]
I would miss the integer offsets though.
Pekr
28-Sep-2009
[18291]
My summary for what defines the beta is in my 3 posts here: http://www.rebol.com/cgi-bin/blog.r?view=0424#comments
... and even Concurrency is missing ...
Carl
28-Sep-2009
[18292x3]
Pekr... yes, end of note.
Pekr, let me take each of these points, one at a time....
1. "Missing protocols" -- for me, this simply means, some users need 
to add them, because I'm not going to have the time.  Certainly, 
I can help with deep issues if they come up.
BrianH
28-Sep-2009
[18295]
I plan to make the scheme dialect a little nicer to help with that.
Carl
28-Sep-2009
[18296x2]
2. "Networking/Schemes" - I spent a lot of time on the Scheme model, 
to purify and simplify it compared to R2.  So, I'm not sure what 
BrianH is proposing yet.
Ah, ok... that is good.
Pekr
28-Sep-2009
[18298]
Carl - it would be nice to have Uniserve like multiplexing engine 
built directly into language, but I am not sure it would not be too 
much. There is also the other layer we don't know the future of, 
called Services ...
BrianH
28-Sep-2009
[18299]
Just a tweak of the dialect. The implementation is good.
Carl
28-Sep-2009
[18300x2]
Pekr, R3 ports are totally multiplexed.
The R3 model is far superior to R2.
Pekr
28-Sep-2009
[18302]
Carl - protocols/networking is the stuff community can work on. I 
suggest you concentrate on low-level stuff:

- finish parse changes

- back to Extensions and closer to Host interface, prepare for release 
and first porting efforts

- please let's at least outline, what the concurrency model is going 
to be. Without it, Doc will not waste his time trying to port Cheyenne 
to R3, if R3 concurrency model is not at least defined?
Carl
28-Sep-2009
[18303x2]
So, the question would be: what higher level models, such as Uniserve, 
can be implemented on top of R3 model?
I've already stated the R3 concurrency model. But, it may have been 
lost in the web.
Pekr
28-Sep-2009
[18305x2]
OK, so let's forget the higher level models right now - there can 
be many over time :-) But multiplexing is one aproach, whereas combining 
it with concurrency is the other thing. So far Cheyenne spawns processes. 
We want R3 to be distributed computing king, no? :-)
ah, yes, task! using threads one?
BrianH
28-Sep-2009
[18307]
So: task! is a thread, undefined sharing model, undefined intertask 
comm model. That's what we have so far.
Pekr
28-Sep-2009
[18308]
http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-concurrency/
Carl
28-Sep-2009
[18309]
Correct: the model is: threaded CPU, shared memory, shared symbol 
space, shared system function space, separate evaluation stacks, 
separate user contexts.
BrianH
28-Sep-2009
[18310]
Synchronization?
Carl
28-Sep-2009
[18311x4]
Intertask comm is via Ports.
Sync is via ports.
BTW, "ports" does not need to mean "sockets"
The host level can provide a more direct mechanism for inter-task 
sync and comm.
BrianH
28-Sep-2009
[18315]
Locking? With shared memory, mods could trounce each other.
Steeve
28-Sep-2009
[18316]
Carl, about parse, is that a pain (in the ass)  to have access (read-only) 
to the rule stack  while parsing ?
BrianH
28-Sep-2009
[18317]
Wow, sounds interesting. Why would you need that?
Carl
28-Sep-2009
[18318]
I'm not a fan of locking, but sometimes it's necessary. Otherwise, 
mods can be "cloned" for multi-task uniqueness.
Steeve
28-Sep-2009
[18319x2]
to know, if we can break the parsing in any place, and continue it 
later
to have async parsing possible
BrianH
28-Sep-2009
[18321]
Copy-on-write?
Carl
28-Sep-2009
[18322]
So, you want "parse continuations".
Steeve
28-Sep-2009
[18323]
sort of... ::-)
Pekr
28-Sep-2009
[18324]
streamed parsing? :-)
BrianH
28-Sep-2009
[18325]
Incremental parsing.
Carl
28-Sep-2009
[18326]
Yes, I understand. That would need to be 3.1.  We do not want to 
delay 3.0.
Steeve
28-Sep-2009
[18327]
sort of... :-)
Carl
28-Sep-2009
[18328]
Anyway... Pekr.... I want to note one final thing.
Pekr
28-Sep-2009
[18329]
listening :-)
BrianH
28-Sep-2009
[18330]
I figured out how to do PARSE on seekable ports, so that might handle 
a lot of the problems.
Carl
28-Sep-2009
[18331x2]
We need a way to make the "todo list" accessible and we need users 
to help us maintain it.
An example is this...
Henrik
28-Sep-2009
[18333]
Carl, you mentioned a while ago that you urged us to work on the 
docs. Does this mean we can fill out the function reference with 
examples without them being overwritten?
Carl
28-Sep-2009
[18334]
Maxim needs some changes for extensions... and has posted them somewhere, 
but I'm not sure where.