World: r3wp

because we now have unbind and generally much more control over the 
binding, I would have thought that auto-binding to user context wouldn't 
be such a big issue.

it used to be an issue because we could not unbind.

May I withdraw my suggestion? Don't use is in tight loops:

>> dt [loop 100000 [set load "a" 2]]
== 0:00:02.017813

>> dt [loop 100000 [set bind to word! "a" 's 2]]
== 0:00:00.079424

hehe

;-)

well, then there has to be a better way to do that. some kind of 
default-bind.

I just discoverd this func...    

utf?

in some fonts the u looks like a w... hehehe

set bind/new to word! "a" self 2
or
set bind/new to word! "a" system/contexts/user 2

Max, it's a dialect: 'ut th' fu'?

Though perhaps we could have a WTF? error-related func.

A refinement for SET might be very handy for the unbound scenario, 
and BrianH may chime in with the design logic to help clarify.

yes.... wtf? as a small undocumented easter egg could be a nice little 
rebol detail   :-D   

basically it could be an alias for why?

Maybe combined with a stack dump? That is, when you say WTF? you 
need all the help you can get. And the refinement for even more info 
would be /!. ;-)

we should find refinements for:

WTF?/$/!/@/*/

;-)

hmm... refinements are case sensitive?

>> txt
== [Errors: 0 Warnings: 0 Outputs: 1 Skipped: 0]

txt/errors
== 0

txt/Errors
== none

That is very strange and makes me wonder why I haven't been tripped 
by this BTW, you're talking path notation here not refinements. With 
function refinements it seems to work as expected.

>> test: func [/a] [all [a 'a]]
>> test/a
== a

>> test/A
== a

>> test: [a 1 A 2]
== [a 1 A 2]

>> test/a
== 1

>> test/A
== none


This is dowright unexpected, I'd consider it a bug, what do you think? 
You'd better curecode this, I guess.

probably never tripped by it because no one uses upper case refinements!

Looks like no one has posted this to curecode yet

MAx: "did someone forget that REBOL is supposed to be "simple" ?"

Did you miss this blog:  http://www.rebol.com/article/0374.html

Simplicity is a thing of the past.

hehe

I thought that was not a good post myself ...

People use things at different levels of expertise ... and if there 
are enough experts around to critique their work, they will get better. 
 So, the differing programming styles seen are a reflection of Rebol's 
failure.

Simple things should still be simple.

And complex things are complex

As long as they're possible. :-)

is there a function to recursively delete a directory? I should probably 
have asked before I wrote one. :-)

Otherwise, here is one, feel free to optimize:

delete-dir: func [dir /only criteria] [
	dir: clean-path dir
	foreach file read dir [
		if any [not only do func [file] criteria file] [
			file: dir/:file
			if dir? file [delete-dir file]
			delete file
		]
	]
]

Optimizing file deletes means first avoiding the standard DELETE 
func. It reads the dir each time which can kill you if you have a 
large dir or, heaven forbid, point it at an FTP location. You can 
build on CLEAR easily though.

    delete-all-files-in-dir: func [dir /local port] [
        port: open dir
        clear port
        close port
    ]


I think my tree deleters all rely on some of my other stuff, like 
FILE-LIST and DO-IN-DIR (now standard as IN-DIR). They generally 
have a callback option as well, so you can track progress.

R3 may be different as I see it's an action now.

I have a version that redefines delete that I wrote for QM: http://www.ross-gill.com/r/brutal-delete.html


It has an optional /pare refinement that deletes empty parent folders 
too.

It's defined only to take URLs (as QM doesn't access files directly) 
but I think should work adding a file! argument.

Also not sure if it works the same way with R3 file ports.

Nup, guess not:
** Script error: cannot use clear on port! value

Interesting. I think that's a bug, as CLEAR's spec is as follows:

clear: make action! [[

    {Removes all values. For series, removes from current index to tail 
    and returns tail.  (Modifies)}
    series [series! port! map! gob! bitset! none!]
]]

Well, guess it's just the error message that is misleading, as CLEAR 
still works on file ports.

(Not on directory ports, though.)

That explains it.  Wonder why not?

I guess 'remove doesn't either.

I think it's basically "just not implemented". :)

this should be reported on CC, if its not there already (just so 
its not forgotten)

From a quick glance at the host kit, I think implementing it would 
be rather easy (basically another special case for RFM_TRUNCATE for 
RFM_DIR in Write_File in dev-file.c). But wiring it up to the directory 
port actor is beyond our freedoms with the hostkit, I think.

Would it make sense, or even be possible, for RT to do all the internal 
wiring for port actors, with a default TBD stub that people replace 
when working on their host kit?

Yes, it probably would. At least in this specific case that's quite 
possible to do. But in general it would make more sense if the flexibility 
to define and wire "native" ports would move to the hostkit completely.

Is it perhaps intentional that 'remove and hence 'clear don't work 
as 'delete is now the action! type responsible for this task?

am I correct that quotes are lost in system/script/args? I need some 
testing here.

the workaround is to do something like:

launch/args %something mold to-binary mold/all [my-data: "test"]

which doesn't seem particularly pretty

Use system/options/args to get the list of arguments as they come 
from the operating system.


system/script/args is more like a rejoin of system/options/args. 
LAUNCH seems to not be doing much more than what CALL does, which 
means there is no escaping of the operating system's shell special 
characters. If CALL/INPUT did not imply /WAIT, it could have been 
a better way to pass REBOL data to a new process.

(not sure if any of this is going to be changed for R3)

LAUNCH is undergoing revision in R3 these days and is a mezz, not 
a native, but the problem seems not to be on the side of LAUNCH.