World: r3wp

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.

btw - I can see some new users in R3 Chat - it is a good sign. From 
the point of RT - are you still contacted by new users/companies? 
Is there any interest in R3? Sometimes I feel that we are unnoticed 
:-)

But there are still various issues around it.

Yes, there are always new users coming to the site, and trying things 
(and sending us feedback, etc.)  It goes in waves... (not to be confused 
with google waves.)

As for R3 and me, I can't wait when we get back to GUI. It was good 
period. And times flies by - it is one year you started to work on 
it. The model is good, we "just" need to finish it and allow it to 
display Unicode. Well, some kernel changes are needed too, but if 
gfx is going to be open-sourced, not a problem ...

Let me tell you... I also want to get back to the GUI, and it is 
not easy for me to work on plugin and related code (which is not 
as interesting or cool).

But, I know that once it is available, then it enables many users 
to start using R3 in ways they could not before.  It is an enabler.

There is a certain satisfaction when something difficult falls into 
place. And it's true that it's sometimes not only difficult to design 
and code but difficult to explain. :-)

yes, just don't listen to me - many ppl here prefer interoperability. 
We still miss on protocols, we need DLLs, we need porting (I am buying 
WinCE SmartPhone next week :-)

Yes. And a satisfaction to checking it off on the big todo list. 
;)

We need strong subsystems, so the proper design-work in initial phases 
pays off later ...

I'm looking forward to user-defined datatypes still :)

... and that is where imo codec system is under-engineered, pushing 
us to introduce read/text :-) Because codecs can work only upon in-memory 
data, not streamed ones. The same for parse :-)

BrianH: looking at everything we are looking for it feels like R3 
is going to be in 3.0 in 10 years :-)

Pekr, on codecs... the question is: where did you put the pipeline?

Carl, while you're here, I was going over the imported tickets in 
CureCode and it looks like some of the tested ones weren't. If I 
can I'm going to review the old tickets to see if they are still 
fixed, or if they ever were, and when.

A codec only works on in-memory data... even at a low level.

Carl - how did Amiga datatypes identify the formats then? I don't 
expect we are going to read 9GB video into memory to find out it 
is an avi container, using filters xvid, version xyz?

Brian, ok... that's good to know.  If it looks time consuming, maybe 
see if we can get some volunteers to help?

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.