World: r3wp

Think of modules as the new components, except you can write them 
in REBOL too. They even use the same Needs header.

Codecs are like port schemes, but for encoding and decoding. Different 
thing.

So why is View separate, and not in Modules section?

... and  - what is Contexts?

btw - Codecs were moved away from Catalog, because Codecs will change. 
Where's the catalog/file-types placed now? (it will not be immutable 
too)

SYSTEM/view is View settings - we'll have View modules too, in with 
the rest of the modules. We just haven't modularized the code yet 
- we needed to have modules first. The file-types setting is in system/options 
with the rest of the general system options.

As for system/contexts: Do you remember system/words ? We have more 
than one now. It's a module thing - separated contexts.

We need to have volatile settings separated from unchanging settings, 
becuase the unchanging stuff can be shared between tasks and the 
volatile stuff can't. And the hidden stuff can be tricky to access 
if you don't know what you're doing, so that is separate too. The 
new organization strategy makes sense. The only thing I miss is system/user/home, 
so we'll need a new place for that too - maybe system/options/user-home.

I am thinking of a preferences system too. But that is not really 
a problem - user.r can be good place to place various settings. What 
we haven't solved or even thought about is - localisation. Messages 
and other stuff are hardwired into the system. I don't want to translate 
REBOL itself, but e.g. R2 does not allow easily callendar data being 
translated. Other thing is currency, flating number separator (for 
display purposes, etc.)

The main thing you need system/user/home *for* is to know where to 
look for %user.r - it is not safe to look for it in the current directory, 
and not multi-user-friendly to load it from the same directory as 
%rebol.r. R2 is horribly broken in that.

having user.r in current directory is really simplistic though ...

And really BAD. It's a security hole.

I hate those system specific ways where Windows put it into your 
profile /somewhere/shitty/really/terrible/brokenly/even/worse/than/linux/long/path 
...

Oh, do you mean %USERPROFILE%, which is similar to %HOME% on Linux? 
It's the same either way, really.

Perk, that is very funny.... thanks.

I so miss the Amiga's alias command...

BrianH: yes, but I work in Total Commander, and I work with directories. 
I need to learn how to do some shortcuts, because going down that 
directories to locate some file is a pain :-)

I use junction points on Windows all the time - it makes all sorts 
of things tolerable :)

Those work at the NTFS level, so Total Commander can use them.

Hmm, there is maybe even something like Alias in Windows, no? At 
least in DOS there was some command .... but - never mind, I went 
off-topic here ...

BrianH: do we post R3 beta item list somewhere here in non web-public 
group, or we keep the link in Chat only?

We're public now. If it is really important that it be quiet, use 
private chat here or in R3 chat.

I think, you mean Amiga's ASSIGN command. It was a very clever feature.

I will post in Links group, OK?

BrianH: what is outcome of read/text discussion? I did not like the 
proposition, because while text operations might be common, text 
is just format as any other is, so should be decoded using codecs 
(which can be chained). OTOH just yesterday I used read/lines. I 
use it very often for external formats, to parse in foreach loop. 
So - what will be the equivalent in R3? 1) 'read gives me a binary 
2) I convert to string 3) then I parse .... or 1) I use load 2) which 
does read it for me and converts to text using some codec ... but 
still - where is the place to turn it into line delimited mode? Will 
we have to use parse rules then, or where would you put something 
like /lines /with R2 equivalents?

READ/text seems like a lock, sorry. You may think that text is just 
another data format, but it is the *most common* data format, and 
tends to be processed in large quantities. You say that codecs can 
be chained, but they currently can't - you can apply them one at 
a time, with all of the intermediate forms in memory at some point. 
If we do text the way you ask, then every load of text for processing 
will have the additional overhead of a full duplicate of the ram 
and two series moves, plus a few lines of code. READ/text is a shortcut 
that will save a *lot* of overhead during what may be REBOL's most 
common operation.

The /lines refinement of READ has been moved to the DELINE function 
- try that.

I don't agree that text preloading would cause a duplicate. Are you 
trying to suggest, that codecs are such pigs, that they do first 
read the whole file, and then decode? Then the system is flawed, 
because what you do with the 9GB video then?

BrianH - the thing is, that I don't like exceptions ... :-) ... but 
I can understand, if some exception covers some 80% of usage cases. 
REBOL is not about purity, but about practical aproach. But I still 
don't believe in the explanation you provided :-) and btw - Carl 
said, that codecs should be chainable, so hopefully it comes?

I thought that text (the same as jpg, video, whatever format) will 
be loaded in chunks needed to identify the format (codec responsibility), 
so I really don't understand, why text should be twice in memory?

So, no way to open a codec as port to inject chunked data ?

So, no further streaming in Rebol again...

Steeve - I posted read/text follow-up to codec Chat section. I really 
don't like it. I added even your question about ports. I think, that 
Carl is trying to make his life easier =  give me some whole C code 
for particular format, I will pack it with REBOL via tiny interface.

Steeve - as a side - note - I posted to Carl link to your editor, 
and he might blog on it. He just said that now he understands why 
you wanted virtual blocks :-)

Virtual what for ?

lol that sounds like a boys band

Pekr give CArl the link to the wiki track he will get some of hours 
past days coding experience what we tried and why we concluded in 
doing the things the way we do them

Pekr, right now codecs only decode binary! and encode to binary! 
- I mean values of the datatype binary! that are already in memory. 
So yes, codecs currently *do* require that you read the whole file 
first. Streaming isn't there yet.

It's intended because it *will* be required, but none of the current 
codecs support streaming yet :(

Yes, the whole system is flawed, or in other words "a work in progress".

Codecs don't read the whole file into memory right now - they don't 
read files *at all*. You have to read the file into memory yourself 
:(

I want codecs to be able to work on open ports. TRANSCODE, SCRIPT? 
and PARSE too :)

BrainH: exactly - having parse to work on open port is my request 
8 years old :-)

parse on ports nice i want it  too

boring to have to put the content of a port stream into a buffer 
then to have to parse it + it wsate memory

i always wonder if parse could work on binary streams

I came up with a way for PARSE to work on R3 ports, under certain 
conditions. It won't work with R2 ports - bad model. We'll see :)

But "came up with a way" doesn't mean in the *current* PARSE - I 
mean a way that would work in theory in the proposed PARSE rewrite.

Quick survey: Do any of you use %rebol.r and/or %user.r, and if so, 
for what?

I don't, since I move environments a lot.