World: r3wp

This is exactly the case, where something is under-engineered, and 
influences REBOL's design. There would be no need for such an exception, 
if Codecs would be able to work the streamed way, not just upon the 
data in memory ....

Above reminds me - does our parse enhancement proposal contain request 
to continuous (streamed) parsing? I can imagine parse being fast 
enough to have REBOL level codecs. But surely I don't want to read/part 
manually, nor do I want to read 1GB of video into RAM, just to find 
out, what the codec is :-)

parse on ports definitely is possible, but would have limitations. 
 because of the rollback aspect of rules.

if bytes aren't available anymore, we can't rollback, obviously...

could be solved by buffering, but the quesiton is, how much to buffer 
anyway, so it really might not work :-)

Pekr, I'm still mad at you for making me think R3 was almost done 
a year or so ago.  I waited with great anticipation for that date. 
 That was a big letdown!  :>)

in cases where the data is pretty linear or backup isn't needed due 
to format, a simple error is all you need to return when you encounter 
un-expected data... this can mean streamed xml parsing.

increasing latency, but not throughput if you chain two servers, 
or two threads.

Louis - then go and smash your head agains the wall, it might help 
:-)

I never said R3 is close to being finished. So what let-down you 
are talking about? We were talking public release, which happened 
and is available for some time.

Pekr, I'm doing that right now head smashing right now trying to 
find a bug in my script.  It doesn't seem to help. But don't worry. 
I'm not really mad at you. Just joking.

Pekr, the reason for R3/Plus is so we don't have to say no to people's 
requests for new functions, but don't want to bloat REBOL. With modules 
we don't have to make everything monolithic anymore. We have a new 
situation with R3.

The main advantages to having functions built into REBOL:
- REBOL itself can use them.
- You can count on them being there.

- They will be tested and reworked by the best of the community (the 
REBOL optimizer).

The main disadvantages to building functions into REBOL:

- Increases overhead, both in startup time and memory overhead. Compare 
R2 /Base to /Core to see what I mean.
- Predefines more words.

- These might not do what you want, so you'll end up redefining them 
anyways.


Building a community is a balancing act. Once we started taking requests 
for new features to make REBOL better, the floodgates opened. Even 
after filtering out the impossible or otherwise bad ideas, there 
was a lot of good stuff in there. But we don't want to bloat REBOL 
into Perl.


Fortunately, we had added modules to R3 to help organize the code 
and deal with the last two disadvantages to building in functions. 
And we have DevBase to accept community contributions. These are 
all the infrastructure we needed to create a standard library, tentatively 
called R3/Plus.


So now we don't have to worry about accepting requests for new features, 
because we know how ruthless we are going to be about our mezzanine 
cuts. If REBOL itself uses the function, it either stays as a mezzanine, 
or in some cases goes native. If the value of the function for users 
is high, the overhead is low, and there is consensus, it may get 
to stay too. Otherwise they become library functions. FUNCTOR wasn't 
the first cut, and it won't be the last.


Keep in mind that with plugins, library functions can be native too. 
And the REBOL optimizer still applies. And with modules you can declare 
your dependencies. There's very little downside to having R3/Plus.

As for the Parse Proposals, well, the proposals need some reorganizing. 
We've had some months to think about them while we've been working 
on other priorities, and one thing that is clear is that some of 
the operations need to apply to only certain data types and not others, 
and some are more global.

The existing parse model could extend to ports if they are seekable. 
Alternation, backtracking and position setting would be translated 
into seeking. The value assigned to words with the set-word operation 
would be an integer offset. The rules would look the same.

Buffering would be handled by the port scheme and the underlying 
OS - no explicit buffering necessary.

This could only work with the R3 port model though, not with R2's 
port model.

hmm, somewhere, i have a script which simulates parsing on an opened 
file (a port) in R2

R3 ports are vaguely similar to /direct ports in R2, but with better 
buffering and in some cases asynchrony. There are more advantages, 
but those are the main ones that apply here. You'd need /read and 
/seek mode to parse with backtracking.

R2 ports could be parsed like series if they are not opened /direct. 
That would be completely different than the above proposal though.

The reasons the above proposal doesn't apply to R2 ports are that 
/seek ports don't buffer (according to  the help, and except for 
OS internal buffering), and the messed-up handling of position for 
/direct ports.

Steeve would you release idx.r to accept A55 patches?

i can

wait a minute

But i've not fully tested it back (i only to tested the speed of 
APPEND)

Geez, my connection is slow, it'll take some more minutes

*** Done, check idx.r at the end of the page http://sites.google.com/site/rebolish/Home

I have some improvements in my mind.

For example, I could optimize the copy/part  actor to get it really 
faster.

Because currently doing loop 10 [copy blk] or copy/part blk 10, takes 
the same time mostly

Strange behavior, i don't remember since when it's like that in R3.
>>to block! "[1 2 3]"
== [[1 2 3]]

instead of previously
== [1 2 3]

Any reason for this change ?

It's been like that since the first R3 release. And in R2 as well.

DO of strings is broken in the crrent release though.

Steeve thnx for update

Brian  No it wasn"t like that from the start.

I didn't have that behavior in the previous releases of the VBS scheme 
(some weeks ago)

Perhaps there was a glitch in one version.

I've checked a few older R3s and a 2003 R2....They all behave the 
same way.

Argh how can that it be ? Am i crazy ????

Here's a good place for that kind of chat.

I would like to ask, if we could start some very preliminary planning 
for Prague Devcon 2010 (May, June?). It should be time of R3 official 
3.0 launch :-)

Carl - still working on plugins? We were discussin here some topics, 
as concurency (getting something like Uniserve engine into R3 for 
networking along with some good model of tasking), parse enhancements 
(parse and codecs being able to work upon streamed input), back-to-GUI 
topics, etc.

DevCon - yes. Interesting, because we are starting to plan a trip 
over there (Europe) already.

Yes, still working on plugins... but the main reason is probably 
not very clear to users. Here is why:

where's the src to the r3 chat server?

The method used for the plugin interface will also be used for all 
the graphics, richtext, and other related code.

anyone got a link?

(that's a separate topic... btw)

Richtext will be separate from gfx?

They are separate APIs.

But anyway, the main mechanisms are in A55, but the wrappers are 
needed.

Ah. What will be the model to "simulate" R2 DLL capabilities? Ladislav 
suggested bunch of enhancements. Should we do R2 DLL kind of interface 
as one of plugins?

In fact, if you use the lower level (to be hidden) load-plugin on 
any exe or dll, you will see it load and attempt to validate the 
plugin.

Yes, I think so, if possible.

Because, we need people in the community to build the DLL access 
methods.