World: r3wp

I think he wants codecs that work on ports. I figured out how to 
make PARSE work on ports, at least seekable ones...

But - it can come later. I just did not like it created the need 
for read/text, because read/text goes against "Pruning read/write" 
blog, if I understand it correctly.

Pekr, no, you would not write it that way.

BrianH: yes - "continuous parsing" is how I called it some 8 years 
ago :-) Of course, as Maxim said - what if you need to backtrack?

Keep in mind that in R3 the I/O devices are async-by-default.

Hence the "seekable"

So... you build the pipeline in REBOL.... not at the I/O level.

Doc also had one question towards event system, but I can't find 
it. Something along the event loop and if it is part of host code 
and can be changed (?) for libevent for e.g.?

Were did he post it?

Well, those questions are here maybe because we lack few handy diagrams, 
e.g. like you did for Devices blog. But it costs your time, so we 
might prefer you working on that stuff first :-)

Darn, he was just here too - he could have asked himself.

Cheyenne group, I think.

will search for libevent ...

I posted a very detailed description of event handling on the wiki.

I think it covered pretty much the entire thing. But it was a long 
time ago.

Posted by Doc - "Having the TCP/IP part open-sourced in R3 will be 
great. It will allow to use much faster OS hooks for file transfers, 
extend the port! API to bind only on selected interfaces, etc...I 
wonder if the main event loop will be there also, so we can replace 
the not-scalable Select( ) call by other faster ones or even integrate 
libevent. That would definitely make Cheyenne able to handle a much 
higher number of connections."

Anyway for funcs like PARSE... the problem is state-change management.

In reply to Doc's question: yes, that's all open source.

I look forward to seeing Doc and others move it forward, beyond select()... 
and it's other methods.

Concurrency model is interesting topic too. Ppl here were mentioning 
Erlang for e.g. There is lots of stuff to study. If underlying APIs 
are solid, then R3 will be nicely scallable. Sometimes even simple 
change can make big difference. I still wait once some skilled C 
developers changes Windows timers to Multimedia timers :-)

So - when can we expect first plugin? :-)

btw - does plugin mean that I have to have the file separate? Or 
will bundling to one exe be possible?

Plugins can be internalized... so yes, a single exe is supported.

There are a few simple init levels in the host.

In fact, it may even be possible to provide your own R boot image. 
 But, maybe that should be special feature... SDK or something.

(The boot image is the fundamental r boot code bundled into the exe.... 
evalutes native, action, and other boot funcs.)

Ah, good to hear ... it once again starts to sound like MagmaOS/Wildman 
is still a long term plan :-)

Regarding plugin timeline: last week.  :-(     But, so many other 
"problems" popped up, was not possible to make it.

well ... but the OS of future is .... JavaScript :-)

Problems regarding plugin architecture?

No, other things... servers, ISP, DSL, kids, DTV, chicken, wine, 
etc.

Carl, cold you put out the June plan blog a little earlier this time? 
It would help with prioritization of tickets, something that was 
skipped recently because we didn't quuite know what was going on...

Infrastructure.

Water.

Water ** 3.

Wine is infrastructure, yes :)

B: yes, ok, earlier.

yes, earlier, so that AInc. can properly plan on AmigaOS 6 announcement 
:-)

Well, Pekr, you recognize what is happening, no?

Not sure what you mean? Building a future? :-)

As the world moves to Javascript... they return to the same model 
they had before, "code is not really data".... and it's like nothing 
really changed.

They are going in big circles with only small improvements in their 
fundamental computing model.

Doc and I decided that the "block" severity would refer to bugs that 
are stopping development, or the fixing of other bugs. There is only 
one bug with that severity now: DO/next. The system/user/home replacement 
is almost there too.

Carl - but HW enhancements help them to survive and define the "standard"

What is worse (for us) is, that Silverlight and Flash are taking 
ahead of View (although Silverlight is not all that easy to code 
for). The JavaFX (JAVA in general) starts being failure for me (in 
userland level)

B: on block, good.  On DO/next... fastest would be a do-next, maybe 
private (not exported.)   Problem is DO is heavily "loaded".

P: well, really we should not compare ourselves to those.... at least 
not yet. That makes it easier for us right now.

If you just implement the native portion of DO/next, the intrinsic 
portion is easy. DO is pretty overloaded though.

Things come and go.  Big systems get bigger... and eventually, they 
fall over. That is true of all systems... .companies... governments.

B: let me take a break and see if I can get it to you somehow. Maybe 
a special A55.1 build for you to try.