World: r3wp

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.

Then to be hones.. I use R3 chat every day, but don't know, where 
are the files:)

Got it... NF to list new files

If I could figure it out, so can you. :-)

BrianH, yes, it would be a good test of modules and ports. if it 
could be started from the start screen, that would make it even more 
attractive.

Is there any command to list all topics with files?

not AFAIK. also topics that say they have files may be a parent that 
has files, not the topic itself.

Worse, some of the topics get the "files here" notification when 
they don't have any. To be fixed.

Still better than the R2 version though.

I mostly work with the files in 26 (Mezzanines) and 837 (R2-Forward).

I see that Carl ignored my auto-topic fix for some reason.

Brian -- Survey.....I rarely use either. I prefer applications to 
be self-contained.

I would use user.r if REBOL consistently started in the same directory 
everytime.  I end up with %public folders all over the place.  My 
use of user.r will be better handled with a custom host process so 
this is not a request for user.r to be kept just a statment that 
I haven't been able to use it for what I want to in the past.

I have thought of using user.r or Rebol.r as a way to run a script 
to log my execution of scripts, although I have not done so.  I tend 
to think of those two items as a "hook" where I can execute my own 
generic code for whatever purpose needed.  I have often thought of 
having either Rebol.r or User.r enforce protect on system words and 
then make sure Rebol.r or User.r is read only, but there may be other 
ways to do this better.  I am still new to rebol.

as to %user.r - my only use for it is so that certain functions I've 
defined that I use a lot (pad, time, fold, Logfile object, etc) are 
automatically loaded in any script I want them in, as well as a terminal 
session.

BrianH:  I use user.r for a few little things, but mainly I get it 
to call my anton-user.r script. I forget when but there were some 
instances  (when I was on Windows) where rebol would overwrite user.r 
(testing a fresh rebol beta?). That's why I decided to get all my 
code out of it and just DO my anton-user.r script from it. On linux 
I also set system/options/home where I want (not the user directory).

I don't change environments much. All new rebol executables are placed 
into the same directory and beaten with a stick until they work using 
the same user.r and my anton-user.r script.

BrianH: I don't agree to your nor Carl's reasoning towards patches:


1) I use custom patch for URL ftp format, which goes probably anti 
RFC, but is very practical (@, # in username). Putting those things 
into DevBase is nto an option - it would not be accepted

2) As Carl suggested, building custom rebol.exe is not an option 
too, because - I don't want tonnes of various rebol.exes around, 
one adding this thing, another one changing the other thing.

3) This whole thing is not a big deal, I just will have to add do 
%my-init.r into the beginning of each of my scripts, which sucks 
though ...

BrianH;  All my nodes have a %user.r.  I define all my comand line 
shortcuts there.
Things like

ls: :list-dir
dir: :list-dir
cd: :change-dir
pwd: :what-dir

~: :view-root
.: %.
..: %..

scripts: :view-root/library/scripts


And those usually work best with GNU/Linux when I just know it'll 
look in ~/.rebol/view

Brian, ls, cd and pwd are predefined in R3. We're considering putting 
in ~ handling in many functions.

Pekr, the reasoning behind blocking patches is the same reason there 
is no browser plugin - R2 is insecure, and R3 won't be. Every patch 
that you can make in your %user.r is what malware running on your 
system can make with your user permissions.


The goal is to have tons of REBOL hosts around. Every application 
with a plugin interface could have a R3 host as a plugin. R3 is going 
to be able to generate programs now, not just scripts. It'll be a 
real development tool.


The problem with all this is that being able to patch the runtime 
using %rebol.r or %user.r, so can anyone else, and you won't know 
about it. Can you say exploit? We already had a false positive for 
R3 this year, an old alpha mistakenly marked as malware. We don't 
want the next time to be for real. The only way to avoid that is 
to make R3 secure.


The way to make something secure is to make the behavior of your 
code predictable. That means making your requirements explicit.

Anton, we are trying to come up with sensible defaults for all of 
the options. Get in on the conversation in R3 chat :)

It will be easy to specify your requirements in R3 - we have modules. 
Put your patches in a module and either add that module to the Needs 
header of your script, or include it on the command line, or build 
it into your host program. Like the SDK but better.

Petr: there is absolutely no reason to have your #1 as long as REBOL 
url!s are fixed.

Gabriele - I know - but do you remember how RT refused to allow dot 
in the front of email adress, because it went against RFC? :-) Hopefully 
we can fix it.

Gabriele - what is the problem with chunked mode of http 1.1 protocol, 
so that it is currently disabled? Any advice for a set-up, of how 
to debug it best? What is the chunked mode good for? I am willing 
to do some tests to track possible problems, so any quick pointer 
would be fine ...