Re: [PD] [getfilenames] alpha test release
On Mon, 26 Jul 2010, Hans-Christoph Steiner wrote: Claude Heiland-Allen wrote: (for example, try using GIMP's file open dialog in a directory containing 1+ files - I ended up having to kill GIMP from the That sounds like an argument against the one big list interface. I wonder if a glob would similarly barf, There's a big difference between the two, just like there can be a big difference in speed between ls and ls -l : the latter has to do a lstat() on *every* filename, and the way this is traditionally stored in Unix filesystems, it has to read lots of clusters from disk, whereas if you don't do the lstat() part, you are reading something that is usually a lot less fragmented. because globbing is one big operation, then you iterate thru it. Globbing could be done incrementally as well. It depends on the implementation of glob being used. But it's usually one big operation. So representing that as a list isn't so far off. But maybe globbing is quite efficient... I don't know I haven't tested it tho. Globbing doesn't need to do lstat(). neither does [folder_list]. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [getfilenames] alpha test release
On Thu, 15 Jul 2010, Hans-Christoph Steiner wrote: On Jul 15, 2010, at 11:59 AM, Mathieu Bouchard wrote: Oops, right. I looked at my auto-screenshot tool, which uses [folder_list], and it's using a messagebox with add2, to build a list from the output of [folder_list]. But I only remembered using the list, not how I got to have a list in the first place. Seems like [folder_list] should probably output a proper list... can anyone shed any light on the advantages of the two approaches? the list output approach allows to use [list split] on it in any way you want... go back and forth... access items by index. First-next and start-next approaches are good when you're really thin on memory and have lots of files, which is very relative, considering how much RAM we have to waste these days. The latter would have more of an advantage if you needed to output multi-element entries, especially when those entries have variable number of elements, but that typically doesn't happen with something like [folder_list] (it could happen for some other classes for which you'd ask yourself that question). It's related to the lack of nested-lists in Pd. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [getfilenames] alpha test release
On 26/07/10 17:14, Mathieu Bouchard wrote: On Thu, 15 Jul 2010, Hans-Christoph Steiner wrote: On Jul 15, 2010, at 11:59 AM, Mathieu Bouchard wrote: Oops, right. I looked at my auto-screenshot tool, which uses [folder_list], and it's using a messagebox with add2, to build a list from the output of [folder_list]. But I only remembered using the list, not how I got to have a list in the first place. Seems like [folder_list] should probably output a proper list... can anyone shed any light on the advantages of the two approaches? Getting a folder listing is not an atomic operation, and interfaces that try present it as atomic are made of fail (for example, try using GIMP's file open dialog in a directory containing 1+ files - I ended up having to kill GIMP from the console because I couldn't wait for the cancel button to be operable). the list output approach allows to use [list split] on it in any way you want... go back and forth... access items by index. First-next and start-next approaches are good when you're really thin on memory and have lots of files, which is very relative, considering how much RAM we have to waste these days. The latter would have more of an advantage if you needed to output multi-element entries, especially when those entries have variable number of elements, but that typically doesn't happen with something like [folder_list] (it could happen for some other classes for which you'd ask yourself that question). It's related to the lack of nested-lists in Pd. Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [getfilenames] alpha test release
Claude Heiland-Allen wrote: On 26/07/10 17:14, Mathieu Bouchard wrote: On Thu, 15 Jul 2010, Hans-Christoph Steiner wrote: On Jul 15, 2010, at 11:59 AM, Mathieu Bouchard wrote: Oops, right. I looked at my auto-screenshot tool, which uses [folder_list], and it's using a messagebox with add2, to build a list from the output of [folder_list]. But I only remembered using the list, not how I got to have a list in the first place. Seems like [folder_list] should probably output a proper list... can anyone shed any light on the advantages of the two approaches? Getting a folder listing is not an atomic operation, and interfaces that try present it as atomic are made of fail (for example, try using GIMP's file open dialog in a directory containing 1+ files - I ended up having to kill GIMP from the console because I couldn't wait for the cancel button to be operable). That sounds like an argument against the one big list interface. I wonder if a glob would similarly barf, because globbing is one big operation, then you iterate thru it. So representing that as a list isn't so far off. But maybe globbing is quite efficient... I don't know I haven't tested it tho. .hc the list output approach allows to use [list split] on it in any way you want... go back and forth... access items by index. First-next and start-next approaches are good when you're really thin on memory and have lots of files, which is very relative, considering how much RAM we have to waste these days. The latter would have more of an advantage if you needed to output multi-element entries, especially when those entries have variable number of elements, but that typically doesn't happen with something like [folder_list] (it could happen for some other classes for which you'd ask yourself that question). It's related to the lack of nested-lists in Pd. Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [getfilenames] alpha test release
On Jul 15, 2010, at 11:59 AM, Mathieu Bouchard wrote: On Fri, 9 Jul 2010, Hans-Christoph Steiner wrote: I just found that this interface was easier to program with. Plus [folder_list] doesn't output a proper list, but rather just a bunch of symbol messages, one per file. Oops, right. I looked at my auto-screenshot tool, which uses [folder_list], and it's using a messagebox with add2, to build a list from the output of [folder_list]. But I only remembered using the list, not how I got to have a list in the first place. Seems like [folder_list] should probably output a proper list... can anyone shed any light on the advantages of the two approaches? .hc kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [getfilenames] alpha test release
On Jul 8, 2010, at 5:26 PM, Mathieu Bouchard wrote: On Thu, 8 Jul 2010, Hans-Christoph Steiner wrote: I just added a meta info API to my new [getfilenames] object. Its an object doing glob/wildcard patterns and going thru the list in a manner simmilar to [textfile]. Attached is the object wrapped into the 'ezfile' library, which is just beginning. Its compile for GNU/ Linux 32-bit and Mac OS X Universal (no Windows yet). let me know what y'all think. Did you encounter any situations in which a long long list of files was inappropriate, such that you *had* to switch to a first/next interface ? Or what else made you switch to that ? I just found that this interface was easier to program with. Plus [folder_list] doesn't output a proper list, but rather just a bunch of symbol messages, one per file. .hc http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [getfilenames] alpha test release
On Thu, 8 Jul 2010, Hans-Christoph Steiner wrote: I just added a meta info API to my new [getfilenames] object. Its an object doing glob/wildcard patterns and going thru the list in a manner simmilar to [textfile]. Attached is the object wrapped into the 'ezfile' library, which is just beginning. Its compile for GNU/Linux 32-bit and Mac OS X Universal (no Windows yet). let me know what y'all think. Did you encounter any situations in which a long long list of files was inappropriate, such that you *had* to switch to a first/next interface ? Or what else made you switch to that ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
