Looking for a co-maintainer for Sys::SigAction

[Lincoln A Baxter]

Hello Perl Module authors, and Pause Admins,

I've come to the conclusion that I don't have the interest, to continue
to maintain Sys::SigAction. (https://metacpan.org/pod/Sys::SigAction). 

SigAction as been incredibly stable for years, with the exception of of
the fact that perl 5.31.6 and beyond broke it for the cygwin platform.
 The tests ran fine on cygwin before that release.  I would probably
try to identify the test that fails on cygwin, and then mask it off
with a warning of what is not working on that platform.  The are three
open issues. 

There was one pull request that I received, that I belatedly merged
into my github repository for sys::sigaction.   This
is https://rt.cpan.org/Public/Bug/Display.html?id=123637.  I will
produce a new release that includes this patch.  And then close this
issue.    There are other two issues.

I am no longer programming in perl (though I still love the language).
 I wish to give this module to someone more interested in maintaining
it.  This module has been included in Debian for years now.  And while
I have no idea how widely it is used, there are 6 people following it.
It would be nice if someone would in interested in at least
contributing to it's maintenance.  I'd be happy to work with that
person to transfer knowledge and review updates.

Any takers?

Lincoln

Re: Fwd: module-authors: ezmlm warning about ipv6 misconfig

[Lincoln A Baxter]

I have received similar bounce notifications.

My email is hosted at gmail (gsuite).  (It just got easier than running
my on email server)/

Does anyone know what is going on?  Is google implementing new
restrictions? (maybe it is time to open a help request with gsuite).

Lincoln


On Mon, 2019-05-27 at 23:21 -0700, L A Walsh wrote:
> looks like an email forwarded from the "list-echoer" at
>  mx-out1.ewr1.develooper.com to
> 
> host aspmx.l.google.com[2607:f8b0:400d:c00::1b] said:
> 550-5.7.1 [2604:1380:2:6000::19] Our system has detected that this
> message
> does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR
> records and
> 550-5.7.1 authentication. Please review 550-5.7.1
> https://support.google.com/mail/?p=IPv6AuthError for more
> information 550
> 5.7.1 . h26si3358158qkl.239 - gsmtp (in reply to end of DATA command)
> 
> 
> This message, for list "module-authors", sent through
> aspmx.l.google.com, doesn't seem to conform to IPV6 sender
> authentication requirements for ipv6 email (I didn't know ipv6
> had new authentication requirement for email -- odd, I don't recall
> such authentication requirements in ipv4 -- is this a new requirement
> in ipv6 such that all ipv6 emails must be authenticated at each
> transfer point?  Has anyone else been seeing bounce messages like
> this indicating that messages sent out of develooper (or at least
> through ipv6 intermediaries) have something wrong with them?
> 
> I'm sure this isn't the best place to send this, but am hoping that
> either others on this list might have seen this and that someone
> on this list might know what's wrong and where this might be best
> forwarded?
> 
> 
> 
> 
>  Original Message 
> Subject: ***SPAM*** ezmlm warning
> Date: 28 May 2019 01:30:36 -
> From: module-authors-h...@perl.org
> 
> 
> Hi! This is the ezmlm program. I'm managing the
> module-authors@perl.org mailing list.
> 
> I'm working for my owner, who can be reached
> at module-authors-ow...@perl.org.
> 
> 
> Messages to you from the module-authors mailing list seem to
> have been bouncing. I've attached a copy of the first bounce
> message I received.
> 
> --- Enclosed is a copy of the bounce message I received.
> 
> Return-Path: <>
> Received: (qmail 26535 invoked from network); 10 May 2019 15:30:46 -
> Received: from unknown (HELO xx1.develooper.com) (147.75.38.233)
>   by x6.develooper.com with SMTP; 10 May 2019 15:30:46 -
> Received: from localhost (xx1.develooper.com [127.0.0.1])
> by localhost (Postfix) with ESMTP id C783A7CF3B
> for
> ; Fri,
> 10 May 2019 08:30:45 -0700 (PDT)
> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
> mx3.develooper.com
> X-Spam-Status: No, score=-1.9 required=6.0 tests=BAYES_00,HTML_MESSAGE
> autolearn=ham version=3.3.1
> Received: from xx1.develooper.com (xx1.develooper.com [127.0.0.1])
> by localhost (Postfix) with SMTP id 8EA857CEEC
> for
> ; Fri,
> 10 May 2019 08:30:44 -0700 (PDT)
> Received: from mx-out1.ewr1.develooper.com (mx-out1.ewr1.develooper.com
> [139.178.64.59])
> by xx1.develooper.com (Postfix) with ESMTP id 83B6F7CF4E
> for ; Fri, 10 May
> 2019 08:30:34 -0700 (PDT)
> Received: by mx-out1.ewr1.develooper.com (Postfix)
> id BC39C6E028C; Fri, 10 May 2019 15:30:34 + (UTC)
> Date: Fri, 10 May 2019 15:30:34 + (UTC)
> From: mailer-dae...@mx-out1.ewr1.develooper.com (Mail Delivery System)
> Subject: Undelivered Mail Returned to Sender
> To: module-authors-return-11042-destination-name=example@perl.org
> Auto-Submitted: auto-replied
> MIME-Version: 1.0
> Content-Type: multipart/report; report-type=delivery-status;
> boundary="2B6CD6E0554.1557502234/mx-out1.ewr1.develooper.com"
> Message-Id: <20190510153034.bc39c6e0...@mx-out1.ewr1.develooper.com>
> X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
> Antispam-Data: 2019.5.10.152716
> X-PMX-Spam: Gauge=, Probability=8%, Report='
>  HTML_50_70 0.1, SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_1_LESS 0,
> BODYTEXTP_SIZE_3000_LESS 0, BOUNCE_AUTORESP 0, BOUNCE_ENVELOPE 0,
> BOUNCE_GENERIC 0, BOUNCE_NDR 0, ECARD_KNOWN_DOMAINS 0,
> HREF_LABEL_TEXT_ONLY 0, SINGLE_URI_IN_BODY 0, SPF_NONE 0,
> URI_WITH_PATH_ONLY 0, __ANY_URI 0, __ATTACHMENT_SIZE_0_10K 0,
> __BODY_TEXT_X4 0, __BOUNCE_HDR_AUTOSUBMITTED 0, __BOUNCE_NDR_BODY_HIGH
> 0, __BOUNCE_NDR_CT_REPORT 0, __BOUNCE_NDR_FROM 0,
> __BOUNCE_NDR_SUBJECT_CONTAINS 0, __BOUNCE_NDR_SUBJECT_STARTS_WITH 0,
> __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
> __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FRAUD_BODY_WEBMAIL 0,
> __FRAUD_MONEY_BIG_COIN 0, __FRAUD_MONEY_BIG_COIN_DIG 0, __FRAUD_WEBMAIL
> 0, __HAS_ATTACHMENT 0, __HAS_ATTACHMENT2 0, __HAS_FROM 0, __HAS_HTML 0,
> __HAS_MSGID 0, __HREF_LABEL_TEXT 0, __HREF_LABEL_URI 0, __HTML_AHREF_TAG
> 0, __HTML_TAG_DIV 0, __HTTPS_URI 0, __MIME_TEXT_H 0,
>  __MIME_TEXT_H1 0, __MIME_TEXT_H2 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0,
> __MIME_TEXT_P2 0, 

Re: Boolean As a Top Level Name

[Lincoln A Baxter]

On Sat, 2016-09-10 at 14:46 +0200, Paul Johnson wrote:
> On Sat, Sep 10, 2016 at 05:58:35AM +0200, Aristotle Pagaltzis wrote:
> > * John M. Gamble  [2016-09-09 22:12]:
> > > Technically it's math, but I suspect people would be more likely
> to use
> > > the keyword 'boolean', or perhaps 'digital logic', when looking
> for
> > > something like this.
> > >
> > > (For supporting evidence, the Wikipedia article on the Quine-
> McCluskey
> > > algorithm nowhere uses 'math' in the current version of the
> article.)
> > 
> > But “mathematical” is the first non-stop-word besides “truth table”
> in
> > the Wikipedia entry for “truth table”.
> > 
> > As for Boolean::Minimizer, I wouldn’t have the foggiest clue what
> that
> > module might be about from the name of it. Even after your
> explanation,
> > the foggiest clue is as much as I got. So I can’t really suggest
> better.
> > I vaguely suspect it’ll turn to be something best put in Data::,
> but who
> > knows.
> 
> I suppose there's a problem here in that without being aware of the
> problem being solved then no module name is going to be helpful.
> 
> If I have understood correctly then Boolean::Minimizer would use
> Algorithm::QuineMcCluskey, or the non-existent Algorithm::Espresso,
> for
> example, to do the actual minimisation.  I don't think
> Boolean::Minimizer is a bad name but, for what its worth, here are my
> naming suggestions:
> 
>  - I would take the R off the end, to have Boolean::Minimize
>  - The Logic namespace looks like a mess, but I think this module
> would
>    fit better in there: Logic::Minimize
>  - The correct spelling is Logic::Minimise
> 
> They are in order of preference, but I'd recommend the first two.

Having followed this discussion (more or less, I have no clue what the
MiuneMcCluskey alorithm is), but I like Logic::Minimise

Lincoln

Re: MetaCPAN is quickly becoming the de-facto interface to CPAN

[Lincoln A Baxter]

On Fri, 2011-07-29 at 12:58 +0300, Gabor Szabo wrote:
 In case you don't have time to follow the many blog post of the
 Perl community  I think this is an item worth reading for you as a
 Module Author.
 
 Don't be left out from the new CPAN game!
 
 This Week in MetaCPAN by Olaf Alders
 http://blogs.perl.org/users/olaf_alders/2011/07/this-week-in-metacpan.html
 
 regards
   Gabor
 
Well, it would be nice if the mail this sends, actually came from a real
domain.  I'm not going to change my mail server's policies to accept
mail from unknown domains:

Jul 30 23:32:42 lws postfix/smtpd[3948]: NOQUEUE: reject: RCPT from 
mxout-095-ewr.mailhop.org[216.146.33.95]: 450 4.1.8 
hea...@kingst.sforeverxx.com: Sender address rejected: Domain not found; 
from=hea...@kingst.sforeverxx.com to=l...@lincolnbaxter.com proto=ESMTP 
helo=mail-33-ewr.dyndns.com

How do I contact cpan testers who have submitted failed test reports

[Lincoln A. Baxter]

Hi All,

I am in the process of getting ready to submit a new release of
Sys::SigAction, as a result of a bug (with patch) that was opened
recently. So I decided to look at the test results and see if I could
figure out what is valid and what is not.  In the case of Win32 OSes I
am going to just going to die with a warning in Makefile.PL that
includes the string OS unsupported, before I make the Makefile. That
will remove those failures for this unsupported OS. 

However, there are some other tests in POSIX OSes I think should have
worked but have failures of one test or another. (BSD seems to be a
common thread for one of the tests). I want to contact the testers to
get more information, before I just mask off the failed test for that
configuration.

I suspect the original test reports were sent to me in the days when my
SPAM filtering was not very good, and I probably missed them, so I need
another way to get to the testers in question.

According to http://cpantest.grango.org/wiki/CPANAuthorNotes the url
http://perl.grango.org/cpanmail.html can be used to convert test report
number into an email address... the only problem is I get a 404 page not
found error when I go there.

Thanks to anyone who can provide the keys to the testers email address
kingdom...  I really don't want to just mask off these OSes without
understanding more.

Lincoln

Re: What name for a printer status supplies module?

[Lincoln A. Baxter]

On Fri, 2004-12-17 at 21:21 +0100, David Landgren wrote:
 List,
 
 I have some code that queries an HP LaserJet 4600 printer to retrieve a 
 web page, that I then scrape to pick out the values of the various 
 consumables it has (CMYK cartridges and other kits).
 
 The fact that it uses http is incidental. If HP bothered to supply a 
 half-decent MIB, SNMP would be a good alternative.
 
 Anyway, I now have to deal with other HP models, and Ricoh 
 printer/copiers as well.
 
 And I haven't a clue what namespace to use. Your advice is much appreciated.

Printer:: comes to mind.  How about:

Printer::Status::Brand::Model

Brand could provide the a common interface around (and wrap) Model.

And Status could provide the generic interface for printer status.

Just some thoughts...

Lincoln

Re: Compress::Bzip2 patch, can't reach author

[Lincoln A. Baxter]

On Sat, 2004-12-11 at 08:16 +0100, David Landgren wrote:
 David Robins wrote:
  I've been sitting on a patch for Compress::Bzip2 for a while; I sent it to 
  the 
  maintainer (Marco Carnut, http://search.cpan.org/~kcarnut/) but he didn't 
  reply.  The patch:
  
  - fixes a bug with compressing small strings (the allocated buffer is too 
  small)
  - adds error reporting and checking
  - adds tests
  - adds an OO streaming interface
  - adds a 'version' method to get the bzip2 library version
  - cleans up the documentation
  - looks for libbz2, rather than hard-coding the location
  
  I can send the patch to this list if desired (it's about 9k gzipped), or go 
  ahead and upload a new version to CPAN, although I don't want to tread on 
  anyone's toes.  If Marco can't be found I'd be willing to take over 
  maintainership.
  
 
 I was in the same position about two years ago. Never heard anything 
 back. I would recommend you take over maintenance of the module, I think 
 any toes to tread on have long since moved away.
 

http://cpan.org/misc/cpan-faq.html#How_maintain_module

It would seem like the requirements have be met to hand over maintenance
of this module to a new maintainer.  If David's patch file has as much
new functionality and fixes as described, and the author has really been
absent for close to two years, I think it is time to ask for it.

The question is, who controls this?  I guess you would write to
[EMAIL PROTECTED] (Jarko Hietaniemi).


Lincoln

Re: [rfc] File::Corruption

[Lincoln A. Baxter]

On Mon, 2004-10-18 at 05:02, Joshua Hoblitt wrote:
 This is sort of side note but I really like File::Integrity.  Although, I
 sort of feel that namespace should be a module that will check the integrity of
 any file where as my code is somewhat more specialized.  Perhaps a long term
 goal will be to factor File::Integrity out of my code but I still need to
 find a suitable namespace for my more specialized code.
 

Ok, how about File::SATA::Integrity

Re: Let's eliminate the Module List

[Lincoln A. Baxter]

On Thu, 2004-08-19 at 13:54, Simon Cozens wrote:
 [EMAIL PROTECTED] (Jose Alves de Castro) writes:
  I don't want to show the results of a search. I want to say Here is the
  link to the module list. See how long it is? It contains practically
  everything you need, doesn't it?
 
 http://www.cpan.org/modules/02packages.details.txt.gz

Hmmm that is pretty complete. Good point.

I kind of like the idea of a standard KEYWORDS section for PODs... 
Gives the author ability to help a potential user find the module. Sort
like man -k.

Adding (say up to 10?) keywords after the tarball name would make _this_
pretty useful... 

It would be useful for an enhancement to search.cpan,org org too.

Re: Let's eliminate the Module List

[Lincoln A. Baxter]

On Wed, 2004-08-18 at 17:57, Mark Stosberg wrote:
 On Wed, Aug 18, 2004 at 04:54:32PM -0500, Andy Lester wrote:
  I propose eliminating the Long Module List.  I'm talking about
  http://www.cpan.org/modules/00modlist.long.html (2998 modules), not
  http://www.cpan.org/modules/01modules.index.html (6800 modules).
 
 As a long time CPAN module author and user, I second this proposal.
 
   Mark
 
ditto, I have modules on the list and not.
Sometime ago, I came to the same conclusion, it really adds no
significant value today.  I did use it years ago, before
search.cpan.org.  Not much really since.

Lincoln

Re: Looking for a new (or co-) maintainer for Net::SSH::Perl and Net::SFTP

[Lincoln A. Baxter]

On Sat, 2004-07-03 at 13:42, Lincoln A. Baxter wrote:
 On Sat, 2004-07-03 at 12:51, Dave Rolsky wrote:

 Here, perhaps, is the start of a list:
 
 scp tiny file to server and back and diff.
 scp large file to server and back and diff.
 (same as above with sftp).
 
 scp a file to server, ssh to server and cat the file just copied across,
 write the output to a file and diff with original.

I would add that one would want to repeat the above for for each
supported encryption library... Blowfish, DES, etc...  Hence the need
for a test library, to eliminate redundant code. Of course, one would
probably need to understand what the server supports here.  I suspect we
would have to discover that...  H... but how?  Maybe I do not
understand this well enough yet.

lincoln

Re: Application framework namespaces

[Lincoln A. Baxter]

On Tue, 2004-05-11 at 14:29, Michael A Nachbaur wrote:
 I'm working on a web application that is almost 100% perl (the styling is 
 handled in XSL).  The entire application's test and installation procedure is 
 managed with a Makefile.PL, and the entire package is very CPAN-ish.  I 
 wanted to know if there was some place on CPAN that I can publish it so other 
 people can deploy my application if they choose?
 
 I'm using the namespace Nacho::AppName for my modules (Nacho being my IRC 
 nick), but if there was an App::Foo namespace that could be used, I'd be 
 willing to upload this to CPAN when I'm finished.
 
 Does anyone see having this sort of code in CPAN as being useful?

I have been work on this for several months... this makes time to say
something:  This email, made be realize that it might be worth getting
our ideas (on a top level namespace) on the table.

This is a long email.  It is long because I need to describe what we have
in order to setup some context for the discussion. 

We (I and a team off 4 other folks) have implemented -- over a period
of 3 years -- a commericial grade perl server suite which is providing
application integration services today for a number of customer 
facing applications at a major financial services company. 

Several of us are now doing a clean rewrite of this independent of our
employer) with the intention making it available on CPAN.  This is a
suite of object oriented modules which implements a Generic Application
Integration Framework or Platform.  (Here after referred to (in this
email) as Framwork.

Our Framework allows for the implementation of perl servers and scripts
that can manage file, socket, MQSeries, or even email or database based
interfaces in polymorphic way, and have standard error handling, logging,
event notification, and configuration.  This Framework will support the
following:

   - Easy Extensibility
   - Easy Configuration (internal and by various file formats)
  - YAML
  - Perl Hash Ref
  - XML
  - Dot notated hierarchy
  - ini file
   - Consistent easy to use Exception handling
   - Separable components usable in standalone scripts
   - Polymorphism between request interface types:
  - MQSeries
  - sockets
  - files
  - Databases
   - Multiple Message Formats 
  - request and response can be in different formats
  - XML (various flavors)
  - tag value
  - CSV
  - Fixed Format
   - Server templates
 - single client/multiple clients
 - singleton/forked/threaded
 - managed
   - Apache integration 
  - FastCGI
  - mod_perl
   - Cron harness
   - Object persistence/caching, maintaining client session state
   - Inter-process communication 
  - Unix domain sockets
  - fifo
  - file ipc
  - db ipc
  - semaphores
   - Clear Distinction between notification of events and logging
  - Polymorphic event notification between various monitoring systems: 
 - Openview
 - Syslog
 - Tivoli
 - BMC
  - Logging various loggers can be configured:
 - Log4Perl
 - stdout
 - file
   - Regression test environment for testing server specific functionality


In thinking about this repackaging we have done a review of the Modules
List and searched CPAN, looking for an appropriate TLNS into which our
suite/framework might fit.

We found many 'Server' packages buried in namespaces dedicated to specific
technologies, techniques, and environments.  Examples include:

   VoiceXML::Server
   NNML::Server
   Net::Server
   NetServer::Generic
   VBTK::Server
   SOAP::Transport::HTTP::Server
   RPC::XML::Server
   Apache::RPC::Server
   Net::SMTP::Server
   Net::SNPP::Server
   Net::TCP::Server
   etc...

Our Frame work is more generic than any of these, and does not fit in any of
these names spaces.  And then there is:

   POE
   Wombat
   POEST
   NetServer
   Event
   etc
   
Lets talk about POE.  With POE we have a suite of packages whose scope
and breath is not unlike what we have put together with GIP.

Infact when we started originially, we looked at POE.  At that point
we considered it not quite what we were looking for.  On reviewing it
again recently, we find it's now got GREAT documentation, an impressive
following, and much more maturity, but its still not suitable for some
of the things we have been doing.  For instance, core to the POE module
at least for implementing servers is the interfaces must support unix
select().  We needed MQSeries.

Our Framework can be used to solve many the same kinds of problems
that POE solves, but it is more generic in its use of interfaces.
POE services assume that request interfaces implement IP socket
semantics, supporting the use for the unix select() function.
Our Framework can be used to implement servers whose request interfaces
include propriety transports like MQSeries or Databases.  Infact, MQSeries
is what most of our current production servers use.  Our 

Re: New module - (session/authentication) seeking a name

[Lincoln A. Baxter]

And what does AIS stand for?  Or did I miss that.

Lincoln

On Fri, 2004-05-14 at 19:50, David Nicol wrote:
 [EMAIL PROTECTED] wrote:
  
  I hadn't heard of AIS before. Sounds like it would make a nice additional
  authentication method. Part of my TODO is to abstract both the
  authentication and storage methods. I should be able to add this auth
  method after that (though, it doesn't offer any group based permissions,
  so that would still need handled locally).
 
 AIS provides an authenticated e-mail address, in one line near the
 start of a CGI program.
 
 I have built several access control lists based on it, setting up
 group based permissions implies dividing everyone into groups --
 something that makes no sense until you know who you have.
 
 
  I looked over AIS::client... there are a lot of exit statements in there,
  and a lot of hardcoded HTML. It'd be nice if allowed the user of the
  module to handle those parts, and just supplied the information it would
  need (the full URL of the AIS server when needed, etc), just a thought.
  And if it returned some failure condition, it wouldn't have to exit(), and
  could allow the client to handle those errors.
 
 the exits are because the AIS client has to run several times during
 the initial handshake.  It redirects, then exits, both to establish a
 session cookie and to redirect to the AIS server.  When the session
 is established, it just looks up the identity and returns.  The only
 thing the user sees from the AIS client module is the redirection pages.
 
 The AIS server provides the log-in interface.
 
  It might be a while before I get the authentication and storage methods
  abstracted (shouldn't be all that difficult, but it's not on the top of my
  TODO list right now). When I do, I'll definately look into AIS, and see if
  I can find similar resources out there.
 
 Wonderful.
 
 The dot-gnu authentication committee has abstracted authentication
 methods into a common interface, so if you want to pick up some
 pre-built wheels instead of reinventing all of them yourself there
 might be something useful in http://sourceforge.net/projects/macs

Re: Testing output to STDOUT and STDERR

[Lincoln A. Baxter]

On Sun, 2004-02-08 at 20:00, Andy Lester wrote:
  While writing tests for some of my code, I was faced with the issue
  of capturing what the code sends to STDOUT and STDERR. As I have not
  found a module to make it easy, I wrote a trivial code to do it. It
  is used like this:
 
 I'm not sure what you're actually trying to test.  If you're testing
 test modules, look at Test::Builder::Tester.
 
 xoa

I think he is trying to do what this should do on the command line but
which does not always work:

ksh$ perl -Mblib t/test.t 21  somefile

Where the 21 does not succeed in concatentating 2 to 1. (probably
because 2 or 1 is the tty), in which case I am not sure this would work
either.

I think this could possibly be useful... post the code, or a link to the
code.  You might consider combine() and separate() instead of seize and
release?  Not really happy with these names either...

Lincoln

Re: VERSION as (interface,revision) pair and CPAN++

[Lincoln A. Baxter]

Phew... Only one comment:  KISS (Keep It Simple Stupid)

This is WAY too confusing!  No one will be able to figure it out, or
want to.  What we have now is not really that broken, especially if one
regression tests his applications when new versions of modules are
installed.  

Actually, we build our offically supported perl tree which we deploy to
all of our boxes, and all of our applications use.  And when we upgrade
things, we build a whole new tree, which we regression test every
application with before we roll it into production.

No fancy versioning emnumeration scheme can replace this testing, and
what we have now works well enough (I think). Most module authors I
think are pretty good about documenting what they change in the Changes
file. 

Lincoln


On Wed, 2004-01-28 at 00:28, David Manura wrote:
 Fergal Daly wrote:
 
  On Saturday 24 January 2004 18:27, David Manura wrote:
  
 (1) All code that works with Version A will also work with subsequent Version B. 
 (e.g. adding new functions)
 
 (2) There exists code that works with Version A but will not work with Version 
 B. (e.g. changing existing function signatures)
 
 (3) There exists code that works with Version A, will not work with Version B, 
 but will work with an even more future Version C.  (probably a rare case)
 
 To handle #1 and #2, we could require all interface version numbers be of the 
 form x.y such for any two increasing interface numbers x.y and u.v, assertion #1 
 is true iff x=u and v=y.   Assertion #2 is true iff the opposite is true (i.e. 
 x!=u or vy).  There is no use for long version numbers as mentioned (e.g. 
 1.2.3.4).
  
  
  I think this might make more sense alright and I'll probably change V::S to work 
  like that.
  However I don't agree with having no use for longer version numbers.
  
  For a start, people do use them and I don't want to cut out something
  people use.
  
  Also, when you have 1.2 and you want to experiment with a new addition
  but you're not sure if you have it right you can release 1.2.1.1 which is
  implicitly compatible with 1.2 . If you then think of a better interface you can
  release 1.2.2.1 which would still be compatible with 1.2 but would have no
  implied relation to 1.2.1.1. You can keep releasing 1.2.x.y until you get to
  say 1.2.6.1 at which point you're happy. Then you can rerelease that as 1.3
  and declare it compatible with 1.2.6.1 .
  
  This let you have development tracks without having to including lots of
  explicit compatibility relations. Branching and backtracking is an essential
  part of exploring so supporting it without any effort for the author is good.
  
  So to rephrase, B implements the interface of A (say B = A where =
  is like implies in maths) if
  
  (
version_head(A) == version_head(B) and
version_tail(A)  version_tail(B)
  )
  or
  (
  version(B) begins with version(A)
  )
  
  where version_head means all except the last number and version_tail means
  the last number
  
  So 1.2 = 1.1, 1.2.1 = 1.2, 1.2.2 = 1.2.1
  2.1 not = 1.1 but you could declare it to be true.
  1.2.2.1 = 1.2 but 1.2.2.1 not = 1.2.1.1
  
  and = is a transitive relation, just like implies in maths, so they
  can be chained together. 1.2.1 = 1.2 and 1.2 = 1.1 means 1.2.1 = 1.1.
  
  So an extension causes an increase and a branch which can be abandonned
  requires adding 2 more numbers. Actually this is exactly the same as CVS
  and presumably for the same reason.
 
 
 I'm not sure branching maps cleanly onto the interface versioning scheme as 
 shown above.  Let's say you have 1.2.  You then branch to 1.2.1.1 = 1.2. 
 Meanwhile, in your main trunk, you create 1.3 = 1.2.  OK, now back in the 
 branch, say you want to introduce an incompatible change to 1.2.1.1.  There are 
 actually two ways in which your change can be incompatible: with respect to 
 1.2.1.1 only or with respect to 1.2.  You provided an example of the first case, 
 where we introduce 1.2.2.1 =/= 1.2.2.1 yet 1.2.2.1 = 1.2.  However, what shall 
 we do if we need to introduce a change incompatible with 1.2?  Number it 1.3? 
 We can't do that because 1.3 has already been assigned in the main trunk.
 
 Maybe the branch numbers should be of the form
 
x.y.b.u.v
 
 where x.y is the main trunk revision, b is the branch number, and u.v is the 
 branch revision.  For simplicity, we'll also eliminate the distinction between 
 changes that are incompatible only with the current branch revision and changes 
 that are incompatible with the main trunk revision.  The scheme for x.y will be 
 exactly the same as, yet independent of, the scheme for u.v.  So, the following 
 relations are implicit:
 
1.2.1.1.1 === 1.2
1.2.1.1.2 === 1.2.1.1
1.2.1.2.1 =/= 1.2 (note!)
1.2.1.2.2 === 1.2.1.2.1
1.2.2.1.1 === 1.2 (a second branch)
1.2.2.1.2 === 1.2.2.1.1
1.2.2.2.1 =/= 1.2.2.1.2
1.3   =/= 1.2.b.u.v   for all b, u, v
1.3   === 1.2
 
 This seems workable, but 

Re: Re3: Re: How about class Foo {...} definition for Perl?

[Lincoln A. Baxter]

On Sun, 2004-01-18 at 17:34, Simon Cozens wrote:
 [EMAIL PROTECTED] (Terrence Brannon) writes:
[snip]
  Does it not belong to the CGI::* namespace?
 
 I don't think it belongs in any namespace once it's finally abstracted, since
 it's sufficiently high level that it's more of an application than a
 module. (cf. AxKit, Struts, etc.) Then I get the fun of trying to think
 up a cutesy name!

Like POE too?

Interesting that you bring that up.  I am currently preparing for
discussion a new collection of modules which is also an application as
well. 

In my case, it is a Server/Integration platform for framework.  In that
discussion (to be posted later this week maybe), I will suggest that
instead of creating a new TLNS for the application, perhaps all such
applications should eventually be moved to generic organizing TLNSes
like:

Server:: or 
Platform:: or
Framework::

Perhaps we should have a discussion about what these should be, and
start to encourage folks to use them.  Perhaps Application:: should be
added to this list.  I see we have App::  but it has not be used for
this.

Lincoln

Re: Possible module for 'safer' signal handling....

[Lincoln A. Baxter]

I've just requested registration of and uploaded:
ftp://pause.perl.org/incoming/Sys-SigAction-0.01.tar.gz

Thanks to all who helped in discussing this.

Lincoln

Re: Possible module for 'safer' signal handling....

[Lincoln A. Baxter]

On Mon, 2004-01-12 at 05:46, Elizabeth Mattijsen wrote:
 At 10:09 + 1/12/04, Tim Bunce wrote:
 On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote:
   eval {
  local $SIG{ALRM} = sub { ... };
   }
 Either way your Sys::SigAction is sufficient. The only thing it's
 lacking that Sys::Signal has is the automatic restoration of the old
 value when the object is destroyed. It would be trivial to add a
 variant of sig_set_action() to do that for those that want it.
 Something along the lines of:
 
sub sig_set_action_auto_restore {
  my $class = shift;
  return bless sig_set_action(@_), $class;
}
sub DESTROY {
  shify-sig_set_action();
}
 
 I'm not sure whether this is relevant here, but I seem to recall a 
 bug reported sometime in the past 3 weeks about signals not being 
 restored at the right time when using eval.  You might want to p5p 
 archives for that.

Thanks Liz for the note.  I have found the discussion, and have down
loaded the fellows test script.  Unfortunately it does NOT reproduce the
bug on my system (current gentoo) with perl 5.8.0  I am building a 5.8.2
perl now to see what that does.

I think I will see if I come up with an object implementation the resets
the handler in on object destruction.  I will then modify his script to
see if the problem persists with Sys::SigHandler, using scope based
resets.  

Re: Possible module for 'safer' signal handling....

[Lincoln A. Baxter]

On Mon, 2004-01-12 at 04:18, A. Pagaltzis wrote: 
 IMO it would be much neater not to have to separately localize
 $SIG{ALRM} but to have restoration optionally done by your module
 on request. I believe the clearest way to handle the syntax would
 be a check for context in sig_set_handler() and returning an
 object that auto-restores the signal in question on destruction
 only if the context is not void.
 
 That way people could write
 
 my $restore = sig_set_handler( ... );
 
 when they want it undone and simply
 
 sig_set_handler( ... );
 
 when they do want the change to persist until explicit change.
 
 

I have come to the same conclusion. It has an additional benefit that
you can explicitly reset things by just undeffing the reference to the
returned object if thats what one wanted to do.

If sig_set_action could handle such an object, I would kill two birds
with one stone.  I think I'll head in that direction.

Today I got the code working with perl 5.005 through 5.008.  and I am
building 5.8.2 now so I can test with that.  Interestingly, with
versions of perl earlier than 5.8, could not get the POSIX::sigaction
routine to behave, so I implemented it under the covers, but just
setting $SIG{name}.  Which got me identical behavior across all three
versions.

This discussion has been most helpful.

Re: Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]

[Lincoln A. Baxter]

Jim has said what I was about to (with reference to Namespaces and
Subclasses), but let me add my $0.02:  The name (space) has nothing to
do with implementation technique.  It has to do with the problem being
solved, or the API.  One should not assume that every module in a
namespace is a subclass of that namespace. Many infact use aggregation
or containment to solve the problem.  

Date::Calc::Day::Iterator or Date::Calc::DayInterator would be good
choices.  I think it _is_ useful to get the word 'Day' in there, since
someone _could_ come along and choose to implement
Date::Calc::Hour::Iterator... (or HourIterator) .. (you would be setting
the pattern I would think) etc.  If it were just ::Iterator that would
be precluded.

Lincoln
  

On Tue, 2003-12-23 at 10:34, Jim Cromie wrote:
 Marco Marongiu wrote:
 
 
  And, last, there is a proposal to rename it to Date::Calc::Iterator
 
  Date::Iterator is not a subclass of Date::Calc: it *uses* it; and 
  Date::Calc as a namespace for my module is just confusing: my modules 
  Iterates over Dates, fullstop. The Calc part is confusing.
 
 
 Derivation/sub-classing is not the only reason to choose a namespace.
 Delegation/has-a relationships (for one) are also a good reason, and it 
 sounds like your module
 fits this case.
 
 Namespaces are not about implementation (which is what derivation is doing),
 theyre about interfaces.  And for humans, knowing where to find those 
 modules.
 
Mazda-RX-8 has a Wankel motor in it - does that make it
 different enough to not be a Car ?  Of course not.   You drive it just 
 like every other
 car.  Is a minivan a car ? an SUV ?  YES.   Should they be under CAFE ?
 (Corporate Average Fuel Economy - Congressional law)   *Absolutely*
 
 
 so wrt finding  Date::Calc::Iterator,  how would one go about it ?   
 search.cpan.org !
 and what are your search criteria ?   *Date*,  *Iterator* 
 
 I just searched Iterator, and hit several with it as the 3rd level name-
 
 *File::Find::Iterator* 
 http://search.cpan.org/author/TEXMEC/File-Find-Iterator-0.3/Iterator.pm
 *XML::LibXML::Iterator* 
 http://search.cpan.org/author/PHISH/XML-LibXML-Iterator-1.00/lib/XML/LibXML/Iterator.pm
 *Test::Harness::Iterator* 
 http://search.cpan.org/author/RCAPUTO/POE-0.27/lib/Test/Harness/Iterator.pm
 
 So sticking Calc in there's not gonna make it any less 'found',
 It adds info wrt your dependency, and it keeps Date::* a little less 
 cluttered.
-- 
Lincoln A. Baxter [EMAIL PROTECTED]

ExtUtils::MakeMaker or Module::Build

[Lincoln A. Baxter]

Hi,

I and several others are starting to put together a collection of
modules.  The will be an architecture for implementing a
data/application integration server.  More on that later when we have a
more complete description we can post.

But as we start to put this together we run across Module::Build.  In
the past I have always used ExtUtils::MakaMaker.  Is there a preference
(if one were starting from scratch), to using one over the other?

Obiously h2xs assumes MakeMaker, but that does not mean I could not
at this relatively early point (at the beginning of putting it
together), switch to Module::Build or Module::Build::Compat.

Are there opinions either way? or a consensus on the future directions?
I don't want to start a religious war, I just way to hear some opinions,
and try to understand (beyond the arguments in Module::Build's pod)
which is currently preferred and why.

Lincoln



-- 
Lincoln A. Baxter [EMAIL PROTECTED]