World: r3wp

of course - I also requested read/dir read/file ... to read only 
directories, no files and reverse ... but we now have speedy remove-each 
.... so I can filter out myself ...

At work we have an issue with supporting extremely large pst (outlook 
personal folder files).  The issue is that we wont to make sure these 
files get backed up when the sales force connects with the network. 
 Problem is that the M$ solutions built into Windows XP cause problems 
because if it sees a changed file it then trys to copy the entire 
file - I believe this to be the case with offline folders files and 
briefcase files also.  What I would like to see is a solution whereby 
only certain contents of the file detected as changed are copied 
over the network and update the master file.  It occurred to me that 
 this should be a capability of any X-Internet application that deals 
with significant file sizes.  So my question is - does anyone know 
of any method's, algorithms or such that currently do such work?

Paul:try talking to Graham as his mailing list reader only dls the 
new mail and saves to the master.Probaly a way to modify for your 
task ? Graham ?

rsync does that afaik.

What's Carl Read complaining about with my formatting answer on the 
mailing list?

dunno - i guess he's just kidding. you idea is quite interesting 
indeed.

>> pad: func [n d] [d: to integer! 10 ** d next form d + n]
>> pad 1 3
== "001"
>> pad 1 5
== "00001"

in the end though, maybe it's slower.

Ok.

but... not if d is fixed. (and of course n must be less than 10 ** 
d)

I guess it's whether one wishes to write a generalised solution, 
or one to solve the problem at hand.

yep... in the case at hand it's a very good solution

though a printf type of solution would be handy :)

we need the format function... people should bug Carl about it... 
:)

Graham  I think it is a slick solution to the question asked

Gabriele -- Is 'format something Carl has hinted RT have in development?
Otherwise, no reason it couldn't be a small community exercise...

it's not in development, but it has been on the list for ages.

of course it can be done in REBOL, but i think it should be native. 
also, i'm pretty sure carl has ideas about how the dialect should 
look like.

Thanks.....Obviously, it'd be much faster to run as a native.

But it may be much faster to develop as a mezzanine -- and would 
be (with a little care) backward compatible with existing and older 
versions of REBOL.

What would be useful  is some agreement on the dialect......The RT 
could schedule work on the native while others do it mezzanine as 
a usual (and b/w compatible) prototype.

well... just let Carl know that you need it, and he'll probably react 
in some way :)

Okay -- will do. Thanks.

I wrote generalised solution in the past. Dunno what Carl Read was 
complaining about, but not having 'pad by default sucks pretty much!

it is pretty common function imo for string formatting and I am not 
sure I am willing to talk about its need once again, as in the past 
I was told I could easily write some mezzanine function for that. 
But we are probably not able to learn ourselves one important thing 
- if there are repeated request and we see new ppl facing still the 
same problems, we should think twice if it would not be able to be 
included by default ;-)

also, e.g. - how to easily "form decimal"? E.g. doing 1 / 100 returns 
1E-2 ... why? Imagine you need it to output to some file - e.g.I 
do some money conversions .... 1E-2 imported into some DB is really 
not helpfull. So I wrote form-decimal function myself, but it is 
weird anyway ....

Pekr  that 1E-2 is a windows areifact , sure it should be fixed to 
be sane but the right place to fix it is the OS

0.001347 result of computation produces 1.347E-3 ..... now how to 
EASILY get it back to full format?

Tomc - are you sure about it?

solaris stares with expontal notation at E-5

it does not wound like a windows problem, have you tried the calculator 
? :-)

Btw - I know Ladislav and others worked on proper rounding. Carl 
also mentioned, BCD will be replaced by some other solution provided 
hopefully by Ladislav, but I would like to know, what is Rebol's 
precision with decimals anyway ..... write some longer one into console 
and it gets stripped down (rounded) - is that the limitation of architecture 
of OS/CPU, or?

that will mostly be IEEE floating point definition

I did not find an easier way, so I parse for E, then I distinguish 
the sign, the number -5 in above case, and then I compose the string 
:-)

Maybe there is some nice and elegant solution via dunno what - debase/base 
or some other conversions, or struct, dunno - I am not really expert 
here :-)

numbers on linux look more sane, so i guess its the os (or Carl hates 
windows?!;). althought it should not be to hard to take code from 
bsd-lib. math is ieee AFAIK.

I know carl deivated a little bit from the IEEE spec in the past 
to make things a little more neewbie friendly

no the same will happen with perl on windows

did you think that the internal type conversion may be the reason 
?

what would you think about something like "###.##e##".

they call the same underlying math libs

Volker - what is that? :-)

AFAIK he derived by comparisions, not the math itself?

hmmm propagating bad design

well it would be the display routines that are mangling not the math

#
 is a digit, gives numbers like 123.45e67

I know Volker, but what with that? Kind of templating/masking? Or 
what do you mean?

how about using that for a pad-function?

if BCD was decided to be replaced by other solution, maybe we should 
ask Ladislav to comment a bit what will happen in that regard?

hmm, i see its a path. so [pad n ###.##] would work without quotes 
:)

its path -> is issue

maybe it should be a dialect