Hi John,
I'm coming rather late to this party. But it does appear you're
missing something important here. I assume you're new to programming.
Here's how historically it's worked in the past. People have used
programs to write other programs, and in doing so, they create
functions and handlers
Thanks for the info. I am just of the opinion that the file functions
in rev could possibly be more economical - it's as easy as that.
Chipp Walters wrote:
Hi John,
I'm coming rather late to this party. But it does appear you're
missing something important here. I assume you're new to
On Mon, 23 Apr 2007 09:55:25 +0100, John Craig wrote:
Thanks for the info. I am just of the opinion that the file
functions in rev could possibly be more economical - it's as easy as
that.
I agree, John... it would be great for Rev to have a file object that
had properties that could be
Thanks for the info. I am just of the opinion that the file
functions in rev could possibly be more economical - it's as easy as
that.
By Economical, do you mean a command for every variation? The problem
with that is that the more definitions that are in the message path,
the slower Rev
Hi, Stephen. I'm very comfortable with rev. It became my 'weapon of
choice' very quickly once I discovered it.
economic: using the minimum of time or resources necessary for effectiveness
One example is needing the size of a file in a folder of thousands.
Creating the output generated by
John,
I hate to keep the thread going, but what was the objection to using a shell
call? You can easily get a directory listing with filters and even hide the
shell window ... might be faster than the other approaches if you're talking
about a huge list of the detailed files. And, instead of
John Craig wrote:
One example is needing the size of a file in a folder of thousands.
Creating the output generated by 'the files' is not economical in this case.
Test:
Make a stack with one button containing the script below, and one field
named r. I set the tabstops of the field to 300,
No objections - I was simply looking for a possible native rev answer.
Every day's a school day and - sometimes - if you don't ask, you don't
find out!
Bill Marriott wrote:
John,
I hate to keep the thread going, but what was the objection to using a
shell call? You can easily get a
Turns out my test wasn't all that useful, since the OS has a bit of a
bottleneck grabbing the info from 12,000+ files in a single directory.
Running the same test on a folder that has only a few hundred files
gives a per-file speed more on par with what we might expect:
# File: 329 Total:
Ken, I'll just buy a brand new set of typing gloves :-)
Ken Ray wrote:
On Mon, 23 Apr 2007 09:55:25 +0100, John Craig wrote:
Thanks for the info. I am just of the opinion that the file
functions in rev could possibly be more economical - it's as easy as
that.
I agree, John...
For only 1 folder containing 34,782 files on MY machine (3GHz, 512Mb
RAM) which is not running any services.
Time taken to get 'the detailed files';
26888 millisecs = 26.888 seconds
Size of output generated by rev for 'the detailed files';
2543957 bytes = 2.5Mb
On a busy server, the results
And how long does it take for you to shell out a dir for the particular file
you're interested in?
John Craig [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
For only 1 folder containing 34,782 files on MY machine (3GHz, 512Mb RAM)
which is not running any services.
Time taken to
Shelling out to grab a single file took around 250 millisecs - although
if multi file sizes are required, you can tack them all into the one
command line and send that to the shell - it still takes about the same
time.
JC
Bill Marriott wrote:
And how long does it take for you to shell out a
John Craig wrote:
Richard Gaskin wrote:
Turns out my test wasn't all that useful, since the OS has a
bit of a bottleneck grabbing the info from 12,000+ files in
a single directory.
Running the same test on a folder that has only a few hundred files
gives a per-file speed more on par with
I have never seen 34000 files in one directory before, so I am not sure what
to think. It might be more practical to look at a log file that the system
creates when it modifies files. This might give you a short list
immediately.
Do the files change once they are created?
It seems like 34000
I agree, Jim - I certainly wouldn't have that many files in a single
directory - they aren't mine and I don't create them.
Jim Ault wrote:
I have never seen 34000 files in one directory before, so I am not sure what
to think. It might be more practical to look at a log file that the system
Maybe I should have said 'another lengthy function call per line'...
I already use a cached file list, but if I hit a folder with thousands
of files in it and only need the size of 1 file in that particular
folder, it seems like wasted CPU time to pull the entire folder contents.
Richard
John Craig wrote:
Maybe I should have said 'another lengthy function call per line'...
I already use a cached file list, but if I hit a folder with thousands
of files in it and only need the size of 1 file in that particular
folder, it seems like wasted CPU time to pull the entire folder
I think, at least in MacOSX, that this is just the form any
application gets this information', including the finder.
It looks very suspiciously like the dump you get when you type ls
-l in the terminal window. Something has to 'waste the time' getting
this informationbe it rev, the
It's an app where files and folders are selected as part of a backup
process. Folders can be selected, in which case the entire folder
contents would be used. In the case of individual files (or just a few)
selected in any given folder, only info for those specific files are
required. The
The ls command can access just 1 file by naming it.
JC
Stephen Barncard wrote:
I think, at least in MacOSX, that this is just the form any
application gets this information', including the finder.
It looks very suspiciously like the dump you get when you type ls
-l in the terminal window.
John Craig wrote:
It's an app where files and folders are selected as part of a backup
process. Folders can be selected, in which case the entire folder
contents would be used. In the case of individual files (or just a few)
selected in any given folder, only info for those specific files
Apology accepted.
Richard Gaskin wrote:
Sorry if my attempt to help you find an immediate solution struck you
as bizarre.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage
John Craig wrote:
I'm recursing through a (sometimes large) list of files and folders
which can take a while, so I was trying to avoid another function call
per line.
A perfect case for using the detailed files, so you can rapidly get
all of the size info for an entire directory in one call,
John,
I'm recursing through a (sometimes large) list of files and folders which
can take a while, so I was trying to avoid another function call per line.
Josh's function is pretty speedy. And, if you know you are going to process
all the files in a directory, then you can store a copy of
perhaps an applescript that did the whole list and returned one list as a
result... only one handoff.
Jim Ault
Las Vegas
On 4/21/07 12:17 AM, John Craig [EMAIL PROTECTED] wrote:
Thanks for the replies, everyone. I've written several handlers in the
past for things only to discover later
This is an example from documentation,
assuming your file is MyFile.txt:
get the detailed files
filter it with MyFile.txt,*
put item 2 of it + item 3 of it into myFileSize
There is also size property which reports the amount of disk space taken by
an object to judge how much memory an
On 4/21/07 1:03 AM, Bill Marriott [EMAIL PROTECTED] wrote:
Another way to make quick work of the detailed files is to put them into an
array:
put the detailed files into foobar
split foobar by return and comma
then you can say,
get item 1 of foobar[urlencode(myFileName)]
Does anyone know of a native rev. method to obtain the size of a file
without using shell or 'the detailed files'?
Thanks,
JC
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage
Well, I guess the detailed files actually is the native rev method,
but this works:
on mouseUp
put /Users/marksmith/Desktop/add.tiff into tUrl
put length (URL (binfile:/Users/marksmith/Desktop/add.tiff))
end mouseUp
Of course, it means reading the whole file into memory, which might
John Craig wrote:
Does anyone know of a native rev. method to obtain the size of a file
without using shell or 'the detailed files'?
What's the objection to using 'the detailed files'?
It was added to the language specifically to provide what you're looking
for.
--
Richard Gaskin
Fourth
Richard Gaskin wrote:
John Craig wrote:
Does anyone know of a native rev. method to obtain the size of a file
without using shell or 'the detailed files'?
What's the objection to using 'the detailed files'?
It was added to the language specifically to provide what you're
looking for.
Some of the files may be very large - making this method too slow.
Mark Smith wrote:
Well, I guess the detailed files actually is the native rev method,
but this works:
on mouseUp
put /Users/marksmith/Desktop/add.tiff into tUrl
put length (URL (binfile:/Users/marksmith/Desktop/add.tiff))
At 1:45 AM +0100 4/21/07, John Craig wrote:
It's clumsy and long winded.
I don't think so. One can easily craft a handler to get whatever info
one needs from this listing using chunk expressions...
Richard Gaskin wrote:
John Craig wrote:
Does anyone know of a native rev. method to obtain
John Craig wrote:
Richard Gaskin wrote:
John Craig wrote:
Does anyone know of a native rev. method to obtain the size of a file
without using shell or 'the detailed files'?
What's the objection to using 'the detailed files'?
It was added to the language specifically to provide what you're
Here are a couple of handlers that return the humanSize (a nicely
formatted version) of a file provided the complete file path and
filename:
put humanSize(tPathAndFile) into fld file size
FUNCTION humanSize tPathAndFile
put theFileDetail(tPathAndFile) into tFileDet
put item 2 of
36 matches
Mail list logo
