World: r3wp

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

TomC: what is your favourite RANDOM for R3?

Each time I see someone mention Erlang model I want to post my last 
"actor-ish" rebol samples I made like 3 weeks ago and still haven't 
found time to post .. it's nothing special, but it can give a little 
feeling and future ideas how it would look in rebol

does rebol 3 have a fast function which converts  [[1][2][3]]  into 
[ 1 2 3] ?

No, you'll have to write your own flatten function.

We discussed adding one, but everyone wanted the function to do something 
different. No consensus.

I think it should be simple. But then again, that's in the same territory 
as "parse string none". What should it do?

What types do you want to flatten? Just blocks, or other block types?

just blocks... cause its a recurring "problem" thru the years.

well, any block, list, hash but not things like objects.

obviously, I know how to write one... but its a pretty recurring 
need for inclusion in the /plus pack... no?