On Mar 31, 2006, at 9:18 AM, B. Bogart wrote:
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.
[file/list] is a bit dangerous since if you [import file] it would become [list]. I think [file/file_list] would be better.
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).
The file lib would be really easy to write and maintain in a combo of C and Pd. C would provide access to the low-level primitives, like glob, lstat, etc. Then Pd objects would make for higher level functions that are commonly used.
Considering the [folder_list] object is basically using to totally different APIs, glob.h and the Windows API, its a pretty small object. If you take out the Windows part, its really small.
I don't have a problem with python, but [py] is crashy and not really maintained these days. I don't know if I've had it working ever. Pd is written in C, so we already have to maintain C code already. As for other APIs like flext, etc. its not part of Pd-extended yet, and its not easy to build. So for the core libraries, I think they should be written in C. Then as support for writing objects in other languages get better, we can start to use that.
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.
Please add, edit, etc. Its a scratchpad to work out ideas.
http://puredata.org/dev/PdLibraries
.hc
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
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste