World: r3wp

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.

I have also been working with Ladislav on many math fixes... which 
he wants to test out.

If you undo the DO string break, that would be worth it too.

But, is there a solution to the bug it causes?

It is not thhe cause of the bug. Read the ticket again - I found 
out the real bug and fixed the ticket at least a day before alpha 
55.

Maybe we need DO string! to error out with a message: "old fashioned 
char-based coding is not allowed."

Ok, I missed it -- or it was not clear to me.

DO of file causes the same bug.

DO of string not working is a worse buug than CATCH/quit messing 
up a TRY block.

Yes, but there's DO file! and there is DO string!  And one is good 
and healthy, the other nasty and perlish.

Anyway, will do.

Yes, and both disable TRY because the real problem is CATCH/quit.

CATCH/quit is rather special.

I was a little surprised that it cased the problem. I thought catch-or-try 
blocks were nested, their contexts stacked.

CATCH and TRY are actually quite different mechanisms. The problem 
is how best to combine them. They both have advantages.

The TYPE? THROW or RETURN issue was interesting. I'm not sure how 
important it is to fix, but it was an interesting insight into how 
those two functions work in R3. Apparently they don't throw until 
their return values are evaluated?

OMG CAAAAAAAAARL  !!! the real CAAAAAAAAARL !!! OOOOOOOOOO MY  GOD 
 ^^

welcome back in rebol3  world  Carl nice to see you here  ^^

pekr nope  the os futur is rebol 3 :P