World: r3wp

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.

We are discussing the possibility of removing those files from R3, 
and replacing %user.r with a declarative preferences file, for security.

is it going to be a dialect?

Yes, presumably - definitely *not* code. Gregg has been requesting 
a preferences infrastructure for a while, and it's a good idea.

All of my uses of %rebol.r are covered better by other processes 
in the new system:
- Patching REBOL  ->  DevBase, or custom-built host processes
- Platform-specific stuff  ->  modules, or DevBase

- Badly set settings (particularly system/user/home on non-*nix platforms) 
 ->  DevBase

I use user.r to add functions which I use in Console. If you remove 
it, I can create a boot script myself and call rebol with it. I almost 
never run Rebol script just clicking on them.

Oldes, I frequently call REBOL scripts by just clicking on them, 
but those scripts load utility functions and halt to the console 
:)

Also I patch default 'attempt function and http scheme (to be able 
use cookies transparently)

DevBase :)

I'm not sure the code is so good to be accepted and also not all 
people want to use cookies.

I use user.r to get some UNIX like commands and for get an include 
command. Will probably not be necessary in the future (now we got 
unix commands and with modules).

I think that the REBOL http scheme should have cookie support that 
you can turn on or off (don't know which the default should be).

We've been trying to add console file management commands where simple, 
but a whole unix-like command module would be nice :)

Also I modify user-agent to pretend that the request is from browser.

brianH, still need some nice copy/move commands though. :-)

but it would be cool to do a whole shell as a module. how much? 10-20k?

Yeah, I have just been working on a whole-package browser spoofing 
client, not just the user agent. I should clean it up and port to 
R3.

We don't have file attribute setting or getting yet, so file copy/move 
might be out for now, unless you call platform functions.

When you say DevBase, do you mean the R2 based with gui or the file 
sharing in R3 chat?

A whole-shell module sounds like a good community module.
DevBase: The R3 version - the R2 version is closed.