World: r3wp

Thanks Henrik, I wasn't aware, is this recent? still a mv function 
would be nice to have

I wrote it, I think, 2-3 years ago. BrianH refined it for R2-Forward 
and R3.

As I recall, MV isn't possible due to limitations in R2 ports, but 
I may be wrong. You would have to load the entire file into memory 
and save it at the destination. If there already is a MV function, 
then I'm wrong.

It seems that R3 doesn't have a MV function. RENAME can't be used 
for it.

as you can rename from one directory to another with a relative target, 
the mv would only need the target to be converted to relative to 
origin and it should work, no?

to-relative-file works only one way, not good

what-dir
;   %/Users/alpha/
  to-relative-file %/Users/alpha/Pictures/IMG_0003.JPG
;   %Pictures/IMG_0003.JPG
  to-relative-file %/Users/                           
;   %/Users/		;this should be %../

seems that BrianH has changed it a lot. I wanted to compare a specific 
source and destination.

From the help:

Returns the relative portion of a file if in a subdirectory,

So it seems to work as advertised, but this isn't enough.

althought the definition is right "Returns the relative portion of 
a file if in a subdirectory, or the original if not." the function 
name would have suggested to me that in the secon case I get a %../ 
but no

secon -> second

Will, this is the one I did:

get-path: func [
  "Calculates the relative path between two directories."
  p1 p2 /local i p3
] [
  p1: clean-path p1
  p2: clean-path p2
  p3: copy %""
  until [
    any [
      find/match p2 p1
      not p1: first split-path p1
      not append p3 %../
    ]
  ]
  append p3 find/match p2 p1
  either p3 = %"" [%./][p3]
]

hmm... there's some useful stuff here.

http://rebol.hmkdesign.dk/files/file-utilities.r

Yeah, sorry, TO-RELATIVE-FILE doesn't do full relative, it's mostly 
a variant of CLEAN-PATH. I wrote the R2/Forward version for use in 
DevBase 2, included it in 2.7.6, then ported it to R3. It's one of 
the two functions where the flow went the other way (IN-DIR being 
the other).

It wasn't based on any preexisting function (not even yours, Henrik), 
it was in response to a real need of REBOL apps, particularly DevBase, 
where the base path is the app path. Carl considered it useful enough 
to include in 2.7.6, same as IN-DIR.

It was originally used to clean up saved file/directory preferences, 
where the default app behavior follows the portable app model: Data 
and settings going in subdirectories of the app directory. If they 
aren't subdirectories, they're absolute paths.

Money! type is nice but not nice enough...

I find it t hard to read the amount when values are large without 
the commas seperating thousands...
I know know some use periods

Has anyone created a function to format money for better display?

you mean like following, which we have for ages? :-)

>> $10'000'000
== $10000000.00

amacleod, we've been discussing FORM-DECIMAL for a while in this 
very group. Scroll up to see.

Pekr, that works but  would prefer commas...
but can you go the other way:
	>>$10000000
	==$10'000'000

Thanks, Henrik, I'll have a look..

REBOL uses the French Swiss currency format (how neutral can you 
get?), but I agree that default formatting to include group separators 
in the console would be nice.

Hmmm.... http://www.articlesbase.com/banking-articles/no-deal-for-us-on-usb-names-1795473.html

Is it intended that some binaries read with LOAD, should return an 
empty block? REBOL/View 2.7.6 here.

Interesting:

>> load read/binary %file.dat
== #{
0000100000001D81000076100000766700007D7E00007F6C00007FB300007FF2
0000805B000080CE00008166000081B100008293000082F10000834A0000...
>> load %file.dat
== [
]

Depends on what's in %file.dat, the whole file, not just the beginning 
of it.

LOAD in R2 has several bugs and design flaws - not sure which is 
which - which probably can't be fixed due to compatibility.

Thanks for the input Brian. I've spent many an hour trying to figure 
out how "load" behaves.

So did I, when I was writing LOAD for R3, fixing the aforementioned 
bugs and design flaws.

Working on LOAD this week, actually. Already fixed one bug earlier, 
now working on a tricky blog request.

load in R2 has even returned a word! datatype to me !

(on a binary zip file)

Wouldn't do so in R3 unless the zip file had some contents somewhere 
in it that resembled an embedded script-in-a-block. Zip files occasionally 
have uncompressed data, so that can sometimes liik like an embedded 
script.

Well, I can reveal that the example is an encrypted SQLite file. 
I could hand it over to BrianH or Carl for debugging?

what were you expecting to find?

I think it's often more preferable to parse the data rather than 
load it ...

What hapens if the data is corrupted by a disk error ?

LOAD should be a quick way to tell whether I'm loading REBOL valid 
data or not. Returning an empty block for an unknown 1 MB binary 
isn't appropriate, because the outcome is suddenly loadable.

is there anything like a lint tool for R2 ... even some simple scripts 
or tools?

do you mean link tool?

lint is sometimes called a program that looks at your code and warns 
you about any potentially stupid behaviour you did

ok, I don't know any tool like that. I think that might be quite 
hard to build for REBOL.

well it's not ultimative .. it could do just some sanity checking 
of things that are possible

it depends on what stupid behavior is. :-) I guess it can scan for 
things like "probe system".

:)

Why does this work:
 	if (to-money bal) < (to-money $0.00) [break]
but not this: 
	if (to-money bal) = (to-money $0.00) [break]
when looping through results that include $0.00

for example my results data looks like this:
$5578.00
$4190.45
$2798.27
$1401.46
$0.00
-$1406.13


If I try to halt at $0.00 comparing with '=' it does not stop but 
if i look for '< $0.00' it catch it as soon as i go below $0.00.

are you sure it's not just ignoring the break?

math conversion error

Why would it ignore the break? I've tried other things like print 
statements to test if it sees it..but it does not seem to see it..