Hey all,
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.
.hc
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
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
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/
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.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
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
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
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 10000+ 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
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 10000+ 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
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 10000+ 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
-
Claude Heiland-Allen -
Hans-Christoph Steiner -
Mathieu Bouchard