From waltman at pobox.com Sun Nov 6 19:10:08 2011 From: waltman at pobox.com (Walt Mankowski) Date: Sun, 6 Nov 2011 22:10:08 -0500 Subject: [Philadelphia-pm] Meeting on Monday, November 7 Message-ID: <20111107031008.GV22378@mawode.com> So. We're due for a meeting tomorrow night. But we don't have anything formal to talk about. We've still got the room, so we could meet there at 7, chat about perl for an hour or so, and then go get something to eat. Does that sound like a plan? Walt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From mjg at phoenixtrap.com Mon Nov 7 03:23:56 2011 From: mjg at phoenixtrap.com (Mark Gardner) Date: Mon, 7 Nov 2011 06:23:56 -0500 Subject: [Philadelphia-pm] Meeting on Monday, November 7 In-Reply-To: <20111107031008.GV22378@mawode.com> References: <20111107031008.GV22378@mawode.com> Message-ID: Can't make it this time, sorry. From c.nehren/phl at shadowcat.co.uk Mon Nov 7 04:40:30 2011 From: c.nehren/phl at shadowcat.co.uk (Chris Nehren) Date: Mon, 7 Nov 2011 07:40:30 -0500 Subject: [Philadelphia-pm] Meeting on Monday, November 7 In-Reply-To: References: <20111107031008.GV22378@mawode.com> Message-ID: On Nov 7, 2011, at 06:23, Mark Gardner wrote: > Can't make it this time, sorry. > _______________________________________________ > Philadelphia-pm mailing list > Philadelphia-pm at pm.org > http://mail.pm.org/mailman/listinfo/philadelphia-pm I'm afraid I won't be able to make it, either--I'll be on a train at the time. -- Thanks and best regards, Chris Nehren From waltman at pobox.com Mon Nov 7 06:47:43 2011 From: waltman at pobox.com (Walt Mankowski) Date: Mon, 7 Nov 2011 09:47:43 -0500 Subject: [Philadelphia-pm] Meeting on Monday, November 7 In-Reply-To: References: <20111107031008.GV22378@mawode.com> Message-ID: <20111107144742.GA13790@mawode.com> On Mon, Nov 07, 2011 at 07:40:30AM -0500, Chris Nehren wrote: > On Nov 7, 2011, at 06:23, Mark Gardner wrote: > > > Can't make it this time, sorry. > > I'm afraid I won't be able to make it, either--I'll be on a train at the time. OK, so that's two nos. Is anyone planning to go tonight? Walt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From waltman at pobox.com Mon Nov 7 11:57:33 2011 From: waltman at pobox.com (Walt Mankowski) Date: Mon, 7 Nov 2011 14:57:33 -0500 Subject: [Philadelphia-pm] Tonight's meeting is CANCELED In-Reply-To: <20111107144742.GA13790@mawode.com> References: <20111107031008.GV22378@mawode.com> <20111107144742.GA13790@mawode.com> Message-ID: <20111107195733.GD13790@mawode.com> On Mon, Nov 07, 2011 at 09:47:43AM -0500, Walt Mankowski wrote: > On Mon, Nov 07, 2011 at 07:40:30AM -0500, Chris Nehren wrote: > > On Nov 7, 2011, at 06:23, Mark Gardner wrote: > > > > > Can't make it this time, sorry. > > > > I'm afraid I won't be able to make it, either--I'll be on a train at the time. > > OK, so that's two nos. Is anyone planning to go tonight? Well, I've only gotten 1 yes but a bunch of nos. I have a lot of work I should be doing tonight as well, so I'm going to make an executive decision and cancel tonight's meeting. My apologies for doing this all at the last minute. Our next meeting will be on Monday, December 5. I'll try to get that meeting organized well in advance. Walt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From we at ana.io Mon Nov 7 11:59:07 2011 From: we at ana.io (Al Newkirk & Associates) Date: Mon, 7 Nov 2011 14:59:07 -0500 Subject: [Philadelphia-pm] Tonight's meeting is CANCELED In-Reply-To: <20111107195733.GD13790@mawode.com> References: <20111107031008.GV22378@mawode.com> <20111107144742.GA13790@mawode.com> <20111107195733.GD13790@mawode.com> Message-ID: Nooooooooooooo On Nov 7, 2011 2:58 PM, "Walt Mankowski" wrote: > On Mon, Nov 07, 2011 at 09:47:43AM -0500, Walt Mankowski wrote: > > On Mon, Nov 07, 2011 at 07:40:30AM -0500, Chris Nehren wrote: > > > On Nov 7, 2011, at 06:23, Mark Gardner wrote: > > > > > > > Can't make it this time, sorry. > > > > > > I'm afraid I won't be able to make it, either--I'll be on a train at > the time. > > > > OK, so that's two nos. Is anyone planning to go tonight? > > Well, I've only gotten 1 yes but a bunch of nos. I have a lot of work > I should be doing tonight as well, so I'm going to make an executive > decision and cancel tonight's meeting. > > My apologies for doing this all at the last minute. Our next meeting > will be on Monday, December 5. I'll try to get that meeting organized > well in advance. > > Walt > > _______________________________________________ > Philadelphia-pm mailing list > Philadelphia-pm at pm.org > http://mail.pm.org/mailman/listinfo/philadelphia-pm > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdn.phlpm at mailnull.com Wed Nov 16 09:26:04 2011 From: sdn.phlpm at mailnull.com (Eric Roode) Date: Wed, 16 Nov 2011 12:26:04 -0500 Subject: [Philadelphia-pm] Persistent data directory Message-ID: Hi all, I'm writing a new module, and it needs to store some data persistently across invocations (basically a cache). It is irrelevant whether this cache is per-user or system-wide. Is there any sort of reasonably standard place to store such data? This will be run on Windows, for what it's worth, but it'd be good to know what locations are standard practice on other platforms, too. Is there any sort of existing module that encapsulates this, so I won't have to think about it (like how File::Temp provides for temporary data storage)? I couldn't find any. Thanks, -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From kstarsinic at gmail.com Wed Nov 16 09:32:34 2011 From: kstarsinic at gmail.com (Kurt Starsinic) Date: Wed, 16 Nov 2011 12:32:34 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: References: Message-ID: One perlish way to do this would be to save the data, encoded with Storable or Data::Dumper, to a file. - Kurt On Wed, Nov 16, 2011 at 12:26 PM, Eric Roode wrote: > Hi all, > > I'm writing a new module, and it needs to store some data persistently > across invocations (basically a cache).? It is irrelevant whether this cache > is per-user or system-wide. > > Is there any sort of reasonably standard place to store such data?? This > will be run on Windows, for what it's worth, but it'd be good to know what > locations are standard practice on other platforms, too.? Is there any sort > of existing module that encapsulates this, so I won't have to think about it > (like how File::Temp provides for temporary data storage)?? I couldn't find > any. > > Thanks, > -- Eric > > > _______________________________________________ > Philadelphia-pm mailing list > Philadelphia-pm at pm.org > http://mail.pm.org/mailman/listinfo/philadelphia-pm > > From c.nehren/phl at shadowcat.co.uk Wed Nov 16 09:38:53 2011 From: c.nehren/phl at shadowcat.co.uk (Chris Nehren) Date: Wed, 16 Nov 2011 12:38:53 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: References: Message-ID: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> On Nov 16, 2011, at 12:32, Kurt Starsinic wrote: > On Wed, Nov 16, 2011 at 12:26 PM, Eric Roode wrote: >> Hi all, >> >> I'm writing a new module, and it needs to store some data persistently >> across invocations (basically a cache). It is irrelevant whether this cache >> is per-user or system-wide. >> >> Is there any sort of reasonably standard place to store such data? This >> will be run on Windows, for what it's worth, but it'd be good to know what >> locations are standard practice on other platforms, too. Is there any sort >> of existing module that encapsulates this, so I won't have to think about it >> (like how File::Temp provides for temporary data storage)? I couldn't find >> any. > One perlish way to do this would be to save the data, encoded with > Storable or Data::Dumper, to a file. > > - Kurt Note that Storable (and to a lesser degree Data::Dumper) are serialization formats not readily readable by other tools/languages. Have you looked at the cache namespace on CPAN? Also consider CHI. -- Thanks and best regards, Chris Nehren From sdn.phlpm at mailnull.com Wed Nov 16 09:52:24 2011 From: sdn.phlpm at mailnull.com (Eric Roode) Date: Wed, 16 Nov 2011 12:52:24 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> References: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> Message-ID: On Wed, Nov 16, 2011 at 12:38 PM, Chris Nehren wrote: > On Nov 16, 2011, at 12:32, Kurt Starsinic wrote: > > > On Wed, Nov 16, 2011 at 12:26 PM, Eric Roode > wrote: > >> Hi all, > >> > >> I'm writing a new module, and it needs to store some data persistently > >> across invocations (basically a cache). It is irrelevant whether this > cache > >> is per-user or system-wide. > >> > >> Is there any sort of reasonably standard place to store such data? This > >> will be run on Windows, for what it's worth, but it'd be good to know > what > >> locations are standard practice on other platforms, too. Is there any > sort > >> of existing module that encapsulates this, so I won't have to think > about it > >> (like how File::Temp provides for temporary data storage)? I couldn't > find > >> any. > > One perlish way to do this would be to save the data, encoded with > > Storable or Data::Dumper, to a file. > > > > - Kurt > > Note that Storable (and to a lesser degree Data::Dumper) are serialization > formats not readily readable by other tools/languages. Have you looked at > the cache namespace on CPAN? Also consider CHI. On CPAN, I find: CHI::Driver::File, which requires you to specify a "root_dir". Cache, which requires you to specify a "cache_root". OOPS, which requires a DBI-accessible database server. Tie::Persistent, which requires you to specify a file location. Persistent::File, which requires you to specify a file location. All of these require you to tell it where to store the data. That's what I'm asking -- what's a good *place* to store persistent data? I can certainly create some arbitrary directory somewhere and give the web server, or the application users, permission to write there. Is that the best practice? An arbitrary directory, selected off the cuff? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjg at phoenixtrap.com Wed Nov 16 09:58:07 2011 From: mjg at phoenixtrap.com (Mark Gardner) Date: Wed, 16 Nov 2011 12:58:07 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> References: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> Message-ID: <8472B3AA-EBDE-40E0-95A4-A45E644E7097@phoenixtrap.com> On Nov 16, 2011, at 12:38 PM, Chris Nehren wrote: > On Nov 16, 2011, at 12:32, Kurt Starsinic wrote: > >> On Wed, Nov 16, 2011 at 12:26 PM, Eric Roode wrote: >>> I'm writing a new module, and it needs to store some data persistently >>> across invocations (basically a cache). It is irrelevant whether this cache >>> is per-user or system-wide. >>> >>> Is there any sort of reasonably standard place to store such data? This >>> will be run on Windows, for what it's worth, but it'd be good to know what >>> locations are standard practice on other platforms, too. Is there any sort >>> of existing module that encapsulates this, so I won't have to think about it >>> (like how File::Temp provides for temporary data storage)? I couldn't find >>> any. >> One perlish way to do this would be to save the data, encoded with >> Storable or Data::Dumper, to a file. > > Note that Storable (and to a lesser degree Data::Dumper) are serialization formats not readily readable by other tools/languages. Have you looked at the cache namespace on CPAN? Also consider CHI. As for *where* to store things (the original question), one system-wide place is the distribution's share directory, enabled by modules like File::ShareDir and File::Share. Other options for portably finding places to write include File::HomeDir and File::ConfigDir. From c.nehren/phl at shadowcat.co.uk Wed Nov 16 10:11:54 2011 From: c.nehren/phl at shadowcat.co.uk (Chris Nehren) Date: Wed, 16 Nov 2011 13:11:54 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: <8472B3AA-EBDE-40E0-95A4-A45E644E7097@phoenixtrap.com> References: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> <8472B3AA-EBDE-40E0-95A4-A45E644E7097@phoenixtrap.com> Message-ID: On Nov 16, 2011, at 12:58, Mark Gardner wrote: > On Nov 16, 2011, at 12:38 PM, Chris Nehren wrote: > >> On Nov 16, 2011, at 12:32, Kurt Starsinic wrote: >> >>> On Wed, Nov 16, 2011 at 12:26 PM, Eric Roode wrote: >>>> I'm writing a new module, and it needs to store some data persistently >>>> across invocations (basically a cache). It is irrelevant whether this cache >>>> is per-user or system-wide. >>>> >>>> Is there any sort of reasonably standard place to store such data? This >>>> will be run on Windows, for what it's worth, but it'd be good to know what >>>> locations are standard practice on other platforms, too. Is there any sort >>>> of existing module that encapsulates this, so I won't have to think about it >>>> (like how File::Temp provides for temporary data storage)? I couldn't find >>>> any. >>> One perlish way to do this would be to save the data, encoded with >>> Storable or Data::Dumper, to a file. >> >> Note that Storable (and to a lesser degree Data::Dumper) are serialization formats not readily readable by other tools/languages. Have you looked at the cache namespace on CPAN? Also consider CHI. > > As for *where* to store things (the original question), one system-wide place is the distribution's share directory, enabled by modules like File::ShareDir and File::Share. Other options for portably finding places to write include File::HomeDir and File::ConfigDir. Eek, sorry I misunderstood. I'll concur with Mark's suggestion of File::ShareDir or File::HomeDir--though as you're on Windows these options may not put things where you otherwise expect. -- Thanks and best regards, Chris Nehren From sdn.phlpm at mailnull.com Wed Nov 16 10:17:24 2011 From: sdn.phlpm at mailnull.com (Eric Roode) Date: Wed, 16 Nov 2011 13:17:24 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: References: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> <8472B3AA-EBDE-40E0-95A4-A45E644E7097@phoenixtrap.com> Message-ID: On Wed, Nov 16, 2011 at 1:11 PM, Chris Nehren wrote: > On Nov 16, 2011, at 12:58, Mark Gardner wrote: > > [...] > > > > As for *where* to store things (the original question), one system-wide > place is the distribution's share directory, enabled by modules like > File::ShareDir and File::Share. Other options for portably finding places > to write include File::HomeDir and File::ConfigDir. > > Eek, sorry I misunderstood. I'll concur with Mark's suggestion of > File::ShareDir or File::HomeDir--though as you're on Windows these options > may not put things where you otherwise expect. > S'okay, Chris. :-) Mark: Aha! Very interesting; I hadn't known about those modules. I wonder if there are any issues about *writing* files in those directories. Probably not (although I'll be sure to lock filehandles properly)... but I should be prepared in case the directory is read-only. Thank you! -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From nate at perlhack.com Wed Nov 16 10:34:07 2011 From: nate at perlhack.com (Nate Smith) Date: Wed, 16 Nov 2011 13:34:07 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: References: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> <8472B3AA-EBDE-40E0-95A4-A45E644E7097@phoenixtrap.com> Message-ID: <20111116183406.GA7041@fatbot.in.perlhack.com> How much data are you talking about? If it's reasonably small, and you are definitely only working with Win32, you could always consider keeping it in the registry. -Nate On Wed, Nov 16, 2011 at 01:17:24PM -0500, Eric Roode wrote: > > > On Wed, Nov 16, 2011 at 1:11 PM, Chris Nehren > wrote: > > On Nov 16, 2011, at 12:58, Mark Gardner wrote: > > > [...] > > > > > As for *where* to store things (the original question), one system-wide > place is the distribution's share directory, enabled by modules like > File::ShareDir and File::Share. Other options for portably finding places > to write include File::HomeDir and File::ConfigDir. > > Eek, sorry I misunderstood. I'll concur with Mark's suggestion of > File::ShareDir or File::HomeDir--though as you're on Windows these options > may not put things where you otherwise expect. > > > S'okay, Chris. :-) > > Mark:? Aha!? Very interesting; I hadn't known about those modules.? I wonder if > there are any issues about *writing* files in those directories.? Probably not > (although I'll be sure to lock filehandles properly)... but I should be > prepared in case the directory is read-only. > > Thank you! > -- Eric > > _______________________________________________ > Philadelphia-pm mailing list > Philadelphia-pm at pm.org > http://mail.pm.org/mailman/listinfo/philadelphia-pm From c.nehren/phl at shadowcat.co.uk Wed Nov 16 20:29:29 2011 From: c.nehren/phl at shadowcat.co.uk (Chris Nehren) Date: Wed, 16 Nov 2011 23:29:29 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: <20111116183406.GA7041@fatbot.in.perlhack.com> References: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> <8472B3AA-EBDE-40E0-95A4-A45E644E7097@phoenixtrap.com> <20111116183406.GA7041@fatbot.in.perlhack.com> Message-ID: <553387CE-5EAB-4842-9DD7-55B4EE362664@shadowcat.co.uk> On Nov 16, 2011, at 13:34, Nate Smith wrote: > > How much data are you talking about? If it's reasonably small, and you are > definitely only working with Win32, you could always consider keeping it in the > registry. > What benefit does keeping it in the registry gain? Keeping things there makes it more difficult to get them out later (have to use specialized tooling); one has to consider where to store it (the registry is not really the simplest datastore); one has to consider possible loss of data in the event of a corrupted registry; and I can't see any real benefit. -- Thanks and best regards, Chris Nehren From kenfox at starlinx.com Wed Nov 16 21:13:32 2011 From: kenfox at starlinx.com (Ken Fox) Date: Thu, 17 Nov 2011 00:13:32 -0500 Subject: [Philadelphia-pm] Persistent data directory In-Reply-To: <553387CE-5EAB-4842-9DD7-55B4EE362664@shadowcat.co.uk> References: <0D3162E2-3375-4653-9768-CBB06E667344@shadowcat.co.uk> <8472B3AA-EBDE-40E0-95A4-A45E644E7097@phoenixtrap.com> <20111116183406.GA7041@fatbot.in.perlhack.com> <553387CE-5EAB-4842-9DD7-55B4EE362664@shadowcat.co.uk> Message-ID: <01ad01cca4e7$a758ff50$f60afdf0$@starlinx.com> FWIW if it's configuration data then by convention on win platforms it should go in the registry since that was created to get rid of the myriad of INI and config files. Granted there's bloat associated with the modules and such needed to access the registry. I would think that putting the location of the config information file in a registry entry and then storing the data in a more perlish way/location might make a tolerable hybrid solution. .... ken -----Original Message----- From: philadelphia-pm-bounces+kenfox=starlinx.com at pm.org [mailto:philadelphia-pm-bounces+kenfox=starlinx.com at pm.org] On Behalf Of Chris Nehren Sent: Wednesday, November 16, 2011 11:29 PM To: Nate Smith Cc: philadelphia-pm at pm.org Subject: Re: [Philadelphia-pm] Persistent data directory On Nov 16, 2011, at 13:34, Nate Smith wrote: > > How much data are you talking about? If it's reasonably small, and > you are definitely only working with Win32, you could always consider > keeping it in the registry. > What benefit does keeping it in the registry gain? Keeping things there makes it more difficult to get them out later (have to use specialized tooling); one has to consider where to store it (the registry is not really the simplest datastore); one has to consider possible loss of data in the event of a corrupted registry; and I can't see any real benefit. -- Thanks and best regards, Chris Nehren _______________________________________________ Philadelphia-pm mailing list Philadelphia-pm at pm.org http://mail.pm.org/mailman/listinfo/philadelphia-pm From waltman at pobox.com Wed Nov 30 12:54:56 2011 From: waltman at pobox.com (Walt Mankowski) Date: Wed, 30 Nov 2011 15:54:56 -0500 Subject: [Philadelphia-pm] Topic for Monday's meeting Message-ID: <20111130205456.GB20135@mawode.com> So, we're scheduled to have our December meeting this coming Monday, December 5. I'd like to volunteer to give a talk on using threads on Perl. I did this talk at YAPC a few years ago, but I don't think I've given it for phl.pm yet. Sound good? Walt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From darian at criticode.com Wed Nov 30 18:19:54 2011 From: darian at criticode.com (Darian Anthony Patrick) Date: Wed, 30 Nov 2011 21:19:54 -0500 Subject: [Philadelphia-pm] Topic for Monday's meeting In-Reply-To: <20111130205456.GB20135@mawode.com> References: <20111130205456.GB20135@mawode.com> Message-ID: <4ED6E44A.2030601@criticode.com> That sounds good. I think I saw it at YAPC10. It was good. I would enjoy seeing it again. On 11/30/2011 03:54 PM, Walt Mankowski wrote: > So, we're scheduled to have our December meeting this coming > Monday, December 5. I'd like to volunteer to give a talk on using > threads on Perl. I did this talk at YAPC a few years ago, but I > don't think I've given it for phl.pm yet. > > Sound good? > > Walt > > > > _______________________________________________ Philadelphia-pm > mailing list Philadelphia-pm at pm.org > http://mail.pm.org/mailman/listinfo/philadelphia-pm -- Darian Anthony Patrick, Criticode LLC Office: (215) 789-9956 Facsimile: (866) 789-2992 Email/XMPP: darian at criticode.com Web: http://criticode.com ================================================= BCF1 E7AD 15AD 8A99 F613 AF5F 2A9C C45C F580 E087 ================================================= * Signed and encrypted communications preferred.