User update for DOMINICN
Record update in the PAUSE users database: userid: [DOMINICN] fullname: [Dominic Sonntag] was [Dominic Neumann] asciiname: [] email: [CENSORED] homepage: [] was [http://perl.dominicneumann.de/] cpan_mail_alias: [secr] ustatus: [unused] Data were entered by DOMINICN (Dominic Neumann). Please check if they are correct. Thanks, The Pause
User update for MZIESCHA
Record update in the PAUSE users database: userid: [MZIESCHA] fullname: [Mario Zieschang] asciiname: [] email: [CENSORED] homepage: [http://www.combase.de/] cpan_mail_alias: [secr] ustatus: [unused] Data were entered by MZIESCHA (Mario Zieschang). Please check if they are correct. Thanks, The Pause
User update for CFRANKS
Record update in the PAUSE users database: userid: [CFRANKS] fullname: [Carl Franks] asciiname: [] email: [CENSORED] homepage: [] was [http://www.fireartist.com] cpan_mail_alias: [secr] Data were entered by CFRANKS (Carl Franks). Please check if they are correct. Thanks, The Pause
Re: Naming my distro -- please advise
Hi Ron: Thank you for writing me a personal email! Time is our most valuable asset and I appreciate you giving me some of yours. Though you didn't answer my question of what namespace to put CELL in, I understand why. Hopefully I will not be committing a gross oversimplification when I say that I hear you saying two things: 1. don't re-invent the wheel 2. don't bundle stuff together As to the first point: * Configuration. App::CELL's configuration model is inspired by Request Tracker. An App::CELL configuration file is actually a Perl module (written as a series of calls to a 'set' function) that is loaded using 'require'. Not only does this leverage Perl itself to do the parsing -- it provides great flexibility when it comes to defining configuration parameter values: they can be scalars, or they can be references to anonymous arrays, hashes, or subroutines. Maybe there's already a Config:: module that takes this approach, and I'm just not aware of it? * Error-handling. I was inspired by brian d foy's article "Return error objects instead of throwing exceptions" http://www.effectiveperlprogramming.com/2011/10/return-error-objects-instead-of-throwing-exceptions/ Though my implementation is slightly different than brian's, I share his reluctance to get into exception-throwing in Perl. App::CELL provides a generic status class (which is i18n-able, since it inherits from the message class). Functions can (but are not required to) return this status object on both success and failure. On success, the status is set to OK and the return value can be retrieved via a "payload" method. On failure, the status is set to a "non-OK" value and the error text (in the user's preferred language -- could even be "Australian English" :-) via a "text" method. Functions are then called like this: my $status = function_call( .. args ..); return $status unless $status->ok; my $result = $status->payload; When an error occurs, it "bubbles" back up the stack and can be handled wherever convenient. Can you point me to an existing module that does this? * Localization. Just today I "discovered" GNU gettext (and libintl-perl), which is clearly far superior to my first attempt at an i18n framework for Perl. No questions there. * Logging. App::CELL implements a simple logging mechanism (Log::Fast- based) that is integrated with CELL::Message objects. You are right that this could be perceived as an attempt to force people to use my logging mechanism instead of their preferred way. On the other hand, the configuration, error-handling, and i18n functions _need_ to log. So I guess I will need to provide a way for folks to overlay App::CELL's logging functions with their own. As to your second point (bundling). I will follow your suggestion and think about how I could enable people to use individual components. This is already possible with the current version of Api::CELL -- just not particularly convenient. Thanks again for sharing your thoughts and for taking the time to consider mine! Nathan On Fri, Jan 31, 2014 at 12:25 AM, Ron Savage wrote: > Hi Nathan > > Thanx for reading the advice re naming modules, even if a little late! > > There are a wide range of modules on CPAN handling issue such as yours does, > and tying them together is not the way many of us work. > > For instance, I already use config modules, logging modules, etc, and have a > policy of not adopting a module which forces me to adopt several such things > just to get the feature I want. > > In the short term you can simply delete CELL via the PAUSE web interface. > > Then, I strongly suggest you have a think about such matters before deciding > what to do next. > > There is of course no reason you'd like my way of doing things, but just for > the record my choices are: > > o Config::Tiny (and if that's insufficient, Config::IniFiles) > > Yes, there's a vast array of config modules on CPAN. No-one needs them all, > but we all need a good one. > > o Log::Handler > > Correspondence will not be entered into :-). > > o Try::Tiny, perhaps combined with Throwable::Factory > > The latter is written by Toby Inkster, which is always a good sign. > > o Etc. > > Cheers > > -- > Ron Savage > http://savage.net.au/
Re: Email::Address::List co-maint, for security release
Sorry for silence. On Wed, Jan 29, 2014 at 11:39 PM, Alex Vandiver wrote: > Heya, > I'm writing to request co-maintainer status on Email::Address::List > for ALEXMV and FALCONE. The current maintiner, RUZ, hasn't responded to > several requests for such over the last week and a half, and a new > release is necessary to close a denial-of-service vulnerability, > CVE-2014-1474. > The module was also originally produced while Ruslan was working for > Best Practical, and the official repository for it > ( https://github.com/bestpractical/email-address-list ) is still under > Best Practical's namespace. As such, the ability to cut releases to fix > security vulnerabilities would be appreciated. > > Thanks, > - Alex > > -- Best regards, Ruslan.
Re: Email::Address::List co-maint, for security release
ALEXMV is now co-maint on Email::Address::List On Fri, Jan 31, 2014 at 2:20 PM, Ruslan Zakirov wrote: > Sorry for silence. > > > On Wed, Jan 29, 2014 at 11:39 PM, Alex Vandiver > wrote: > >> Heya, >> I'm writing to request co-maintainer status on Email::Address::List >> for ALEXMV and FALCONE. The current maintiner, RUZ, hasn't responded to >> several requests for such over the last week and a half, and a new >> release is necessary to close a denial-of-service vulnerability, >> CVE-2014-1474. >> The module was also originally produced while Ruslan was working for >> Best Practical, and the official repository for it >> ( https://github.com/bestpractical/email-address-list ) is still under >> Best Practical's namespace. As such, the ability to cut releases to fix >> security vulnerabilities would be appreciated. >> >> Thanks, >> - Alex >> >> > > > -- > Best regards, Ruslan. > -- Best regards, Ruslan.
PAUSE ID request (NEXADDO; Spenser Austin)
Request to register new user fullname: Spenser Austin userid: NEXADDO mail: CENSORED homepage: why: I want to publish my marching cubes algorithm implementation when I am done with it. The following links are only valid for PAUSE maintainers: Registration form with editing capabilities: https://pause.perl.org/pause/authenquery?ACTION=add_user&USERID=65d0_4644e53fa4ef09a7&SUBMIT_pause99_add_user_sub=1 Immediate (one click) registration: https://pause.perl.org/pause/authenquery?ACTION=add_user&USERID=65d0_4644e53fa4ef09a7&SUBMIT_pause99_add_user_Definitely=1
Re: Email::Address::List co-maint, for security release
On Fri, 2014-01-31 at 14:23 +0400, Ruslan Zakirov wrote: > ALEXMV is now co-maint on Email::Address::List Great -- thanks! - Alex
Re: Naming my distro -- please advise
On Fri, Jan 31, 2014 at 04:30:33PM +0100, Nathan Cutler wrote: > * Configuration. App::CELL's configuration model is inspired by Request > Tracker. An App::CELL configuration file is actually a Perl module (written > as a series of calls to a 'set' function) that is loaded using 'require'. > Not only does this leverage Perl itself to do the parsing -- it provides > great flexibility when it comes to defining configuration parameter values: > they can be scalars, or they can be references to anonymous arrays, > hashes, or subroutines. > > Maybe there's already a Config:: module that takes this approach, and I'm > just not aware of it? Not really. The usual approach to format-agnostic configuration is Config::Any which allows you to have a perl file returning a data structure. Personally I'm not fond of perl for configuration unless the config files are to be written by developers and ignored by sysadmins, which tends not to be what I use config files for. > When an error occurs, it "bubbles" back up the stack and can be handled > wherever convenient. > > Can you point me to an existing module that does this? No, because it's a terrible idea. Whst the linked article doesn't discuss is the fact that the try/catch approach allows you to run a sequence of methods and trap errors from all of them in a single block, at which point the try/catch based approach is much less code. Try::Tiny::ByClass would be a nice approach to structured exception catching, and if you want to be able to resume or return *optionally* when errors occur then look at Worlogog::Incident and Worlogog::Restart. Using the latter two would allow users who want to do things the standard way to continue to do so, and you to use your own approach internally. I still think it's a terrible idea, but I entirely support your right to do so, especially if I can still get exceptions :) > * Logging. App::CELL implements a simple logging mechanism (Log::Fast- > based) that is integrated with CELL::Message objects. You are right that > this could be perceived as an attempt to force people to use my logging > mechanism instead of their preferred way. On the other hand, the > configuration, error-handling, and i18n functions _need_ to log. So I > guess I will need to provide a way for folks to overlay App::CELL's > logging functions with their own. Look at Log::Any as a way to allow use of arbitrary logging systems. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN commercial support, training and consultancy packages could help your team.
Welcome new user NEXADDO
Welcome Spenser Austin, PAUSE, the Perl Authors Upload Server, has a userid for you: NEXADDO Once you've gone through the procedure of password approval (see the separate mail you should receive about right now), this userid will be the one that you can use to upload your work or edit your credentials in the PAUSE database. This is what we have stored in the database now: Name: Spenser Austin email: CENSORED homepage: enteredby: David Golden Please note that your email address is exposed in various listings and database dumps. You can register with both a public and a secret email if you want to protect yourself from SPAM. If you want to do this, please visit https://pause.perl.org/pause/authenquery?ACTION=edit_cred or http://pause.perl.org/pause/authenquery?ACTION=edit_cred If you need any further information, please visit $CPAN/modules/04pause.html. If this doesn't answer your questions, contact modules@perl.org. Before uploading your first module, we strongly encourage you to discuss your module idea on PrePAN at http://prepan.org/ to get feedback from experienced Perl developers. Thank you for your prospective contributions, The Pause Team
Re: Naming my distro -- please advise
Hi Nathan I see Matt has answered too, and there's no more for me to add, except: Do less coding and more planning! -- Ron Savage http://savage.net.au/
