Hey all,
So I'm thinking about Hans's test-case for folder_list (outside of pixelTANGO) that is checking how big the files are. Seems to me this would be a nice way to do it:
[file/list ~/*] | [file/is_file] | [file/filter_by_size >= 1048576] | [tolist]
filer_by_size would be an abstraction that uses something like file/get_size to check the size of each file, compare it, then pass it through if it fits the criteria.
So the result would give us a list of files greater than 1mb.
(I just now realized you can specify an object name as an abstraction argument, wow that is really cool:
[compare > 10]
contains:
[inlet] | [$1 $2] | [outlet]
I was not expecting it to work.. :)
Should it be called file_list so that in the future it would be "file/list" or "folder/list"? it lists both files and folders... A library of "folder" operations seems less useful than a file operations library, so "file/list" sounds good to me.
Ok, After all the fudge here is the point of my message. These ideas for all the file operation objects are great, but I think they are nicest as small blocks. It seems perhaps a little difficult to maintain a bunch of these little programs in C, easier in flext, and perhaps easiest in python.
So the question is, if we're going ahead to create this kind of standard libs for PD, what should they be written in?
If we want a lot of functionality fast then python seems like the best solution, coding the same thing in C will take longer (at least for me, who does not even know python).
Hans, did you start a wiki to map out the contents of each of these libs? I can take on the "design" of the "file" library, but I don't have the time to impliment all my ideas, even in python let alone in C. Though I find flext easier to work with and read, but not to debug.
Any way to get the PD transparency and performance of C/Flext without development and debugging taking forever? I heard of something that takes any C library and automagically generates a python interface so all the functions are available in python. Would this is possible for PD? take an existing lib and port each function to PD objects? (automagically)
Johannes Z, how did you create the openGL wrappers? manually or some shortcut?
So many ideas, so little time.
.b.
Hans-Christoph Steiner wrote:
On Mar 31, 2006, at 12:36 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
There are two reasons that I made it output each file separately. First, to make it similar in interface to [qlist] and [textfile]. Next, and more importantly, most file processing is going to happen on a per-file basis, at least in my scripting experience. For example, you might want to step thru a list of files and test which is bigger than 1MB, or which is a directory.
I have directories with very many files (like $HOME with all it's dotfiles. Building a list of all names would generate a huge list. I think it's better to output them sequentially instead of making this huge list.
But yes, the completion bang should be added, and is planned... then it would work really well with an [until].
Agreed.
For making a list out of the names, you can just use: [list]X[t a] in Pd. Using [list]--- filter somehow---X[t a] this could filter out unwanted filenames prior to building the list.
[folder_list] is based on glob, so it supports full UNIX file globbing on UNIX platforms. (On Windows, its supports Windows wildcard patterns, which are not as nice, IMHO, and not always compatible).
So go nuts with your ? and * and [ab] when using [folder_list]. If you wanting the patch to run on Windows too, then don't use ?, *, etc. to match multiple directories, and you should be alright.
But its always good to have multiple methods... :)
.hc
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev