[PD-dev] Re: file library WAS: [folder_list]

[Hans-Christoph Steiner]

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 at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>


________________________________________________________________________ 
____

                     There is no way to peace, peace is the way.
						        				-A.J. Muste