Re: Separate questions and development lists?
A nested list under poe@ to aggregate poe-questions@ and [EMAIL PROTECTED] :) On Sat, Feb 21, 2004 at 07:46:19PM -0500, Rocco Caputo wrote: > The heavy development discussions may be scaring people off. Is it > time to split the list into development and questions tracks? > > Proposed options (revise and amend as necessary): > > 1. No. It's too early to tell. > > 2. Yes. > >a. Move the help/questions to some other list. Perhaps > poe-questions. > >b. Move the development/design discussions to some other list. > Perhaps poe-dev. > >c. Split into two separate lists and retire the base one. Perhaps > poe-dev and poe-questions. > > Of the options so far, my preference is 1. Forking the list into > multiple tracks is easy, but deprecating dead ones is hard. > > I think option 2c sucks mightily, but I wanted to present it for > completeness. Ideas that I post are not automatically good. > > -- > Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/ > -- Cormac J. Mannion, Quasi-Samurai "Some people are intelligent in knowing themselves but stupid in knowing their opponents, and others the other way round; neither kind can solve the problem of learning and applying the laws of war." - Mao Tse-tung pgp0.pgp Description: PGP signature
Separate questions and development lists?
The heavy development discussions may be scaring people off. Is it time to split the list into development and questions tracks? Proposed options (revise and amend as necessary): 1. No. It's too early to tell. 2. Yes. a. Move the help/questions to some other list. Perhaps poe-questions. b. Move the development/design discussions to some other list. Perhaps poe-dev. c. Split into two separate lists and retire the base one. Perhaps poe-dev and poe-questions. Of the options so far, my preference is 1. Forking the list into multiple tracks is easy, but deprecating dead ones is hard. I think option 2c sucks mightily, but I wanted to present it for completeness. Ideas that I post are not automatically good. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: Module naming conventions
On Sat, Feb 21, 2004 at 07:44:28AM -0800, Exide Arabellan wrote: > Im working on a module that utilizes POE::Component::Server::TCP. Being > the neat freak that i am, im inclined to name the module > POE::Component::Server::TCP::MUD, though it seems rather cumbersome. > I've seen other modules (such as IRC::Bot) that take the last module and > use it as the begining of theirs. However when doing a CPAN search, > having the full title is helpful for a first glance appraisal of how its > written. > > Is this something people just do however they see fit, or is there a > standard/movement to have it one way or the other? POE::Component::IRC was published before general naming conventions were formed. The conventions remain malleable to this day, but there's a little method to the madness. If your module implements a specific kind of MUD, possibly with a lot of modules, I'd suggest naming it Net::MUD::Arabellan (or whatever the name of your MUD is). If it's a generic module for providing front-end TCP services to a back-end MUD engine, I'd suggest POE::Server::MUD. MUD servers tend to be TCP things by default, so specifying it in the package name seems redundant. > Disclaimer: I apologize if this has been covered, in the case that it > has please point me to the post. I tried to scan for it, but didn't come > up with anything. No problem. Don't let the heavy development discussion scare you off. If it starts to get unbearable, we can always start another list. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: RFC: 1.0 and the end of official <5.6.1 support
On Sat, Feb 21, 2004 at 01:19:10AM -0500, sungo wrote: > On (02/07 15:22), Rocco Caputo wrote: > > > Signal reform is not quite done. We're still dispatching _signal, > > albeit with great reluctance. > > why? kill this beast already. Two reasons. 1. It turns a mandatory error into a silent failure. a. I would rather suck up the inconvenience of maintaining _signal than engender silent breakage by removing it. b. The error is pretty clear, and it's easy to address in support requests. In fact, I don't get support requests about it. So at the moment, zero inconvenience is less than the anticipated inconvenience caused by removing _signal. 2. It has not been a pressing issue. a. There are no active projects waiting for _signal to go away. b. Other projects are active, and some of them are blocked on things I can be working on. c. The longer I wait, the less grief I anticipate to receive when the change is finally made. > > To me, a 1.0 release implies a certain measure of spit and polish that > > the documentation (and perhaps the installer) lack. > > the installer has a massive weight of requirements on it that prevents > it from being all that it can be. its greatest weight is the seeming > inability of certain users to read what the installer is asking them. Fair enough. I rechecked ExtUtils::AutoInstall, and it clearly says "optional" in several places. Consider the minor issue refuted. Now about the documentation. I really think it falls below the level of quality that a 1.0 release implies. It's already a bummer for most people, and it will just be worse with the heightened expectations that a "golden" release would create. > > Maybe the backward-looking version can be 1.00 and the forward-looking > > release 2.00. Then we can chew up the 0 series with reasonable large > > updates and still leave the pre-5.6.1 maintainer significant room to > > maneuver. > > that pretty much leaves us with a perl-version-support split happening > in >2038. > > i'm sensing that no one really wants to support <5.6.1 anymore but no > one really wants to decide when where and how we make the split. I'm waiting to see how the list discussion resolves. Meanwhile, I'm providing suggestions and trying to exchange ideas. I don't require pandemic sycophancy, but I expect that people's ideas be responded to with a level of consideration and courtesy that's appropriate for a public mailing list. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: Test Reforms
On Sat, Feb 21, 2004 at 01:13:30AM -0500, sungo wrote:
> On (02/07 15:53), Rocco Caputo wrote:
>
> > I think the tests should be generated at "make test" time. We get a
> > smaller distribution this way.
>
> you've never been terribly concerned about a really small distribution
> before. we've shipped 10K of examples until really recently. i'd much
> rather ship 10K of real honest to god easy to read and maintain tests.
POE still ships with about 200K of samples, and it will continue to
until they're replaced by cookbook recipes or tutorials. The plans
have been on display for months at
http://poe.perl.org/?POE_RFCs/Deprecate_Sample_Program
> > Once the generation phase is done, Test::Harness executes specific and
> > generated tests as usual.
>
> what happens when test generation fails? how do we include tests for the
> test generation framework?
As I see it, test generation is an exercise in templating. The
proposal suggests combining a pool of perhaps 20 reusable test
programs---one for each of POE::Kernel's reusable APIs---against each
available runtime environment. The result would be maybe a hundred
small programs that look virtually identical except that they use
different modules and require different tests.
This idea is based on POE's current t/27_poll.t. If IO::Poll is
available, it's loaded so POE::Loop::Poll will be activated. Then it
tests the select() API, which exercises the loop's filehandle
watchers. If you've never seen it:
#!/usr/bin/perl -w
# $Id: 27_poll.t,v 1.10 2004/01/31 06:58:30 rcaputo Exp $
# Rerun t/04_selects.t but with IO::Poll instead.
use strict;
use lib qw(./mylib ../mylib ../lib ./lib);
use TestSetup;
BEGIN {
eval 'use IO::Poll';
test_setup(0, "IO::Poll is needed for these tests")
if length($@) or not exists $INC{'IO/Poll.pm'};
test_setup(0, "IO::Poll 0.05 or newer is needed for these tests")
if $IO::Poll::VERSION < 0.05;
}
require 't/04_selects.t';
exit;
So, what do we do if templating fails? Well...
1. If POE's favorite templating language isn't available...
POE does not need a full-featured, general-purpose templating
library. The test generator should include some basic, line-based
tag replacement and be done with it. No problem.
2. If the test generator contains one or more bugs...
A large number of the test files will come out broken. Like the
Balrog, or constipation, they shall not pass. In theory, the
release technician will be bright enough notice something is wrong
while testing a distribution before releasing it.
We can always hire a new release technician if the current one's
excessively stupid or careless.
3. If there's not enough disk space to write the test files...
The test generator reports a "disk full" error, just like tar or
unzip would.
4. If the filesystem doesn't like the filenames used...
The test generator reports a "cannot open file: $!" error, just
like tar or unzip would.
Fixing a generator is probably easier than maintaining a hundred
discrete files.
5. If Perl is broken...
It happens. The tests will probably fail either way, so POE's
neither better nor worse off.
6. If a god smites the machine...
The bad disk block would have been there for tar or unzip to
extract a file into. The meteorite would have hit the server farm
anyway. POE is neither better nor worse off.
7. If something unanticipated happens...
Sorry, I just don't know. That's the problem with unanticipated
failure modes.
Are there failure modes I'm missing?
> > The major difference between revisions is that Sean pointed out some
> > test environments that I missed. So we have a potential for many more
> > test files, but we also test more of POE.
>
> then i completely misread it. or it changed drastically from the time
> you showed it to me in irc to the time you sent it to the list.
It's probably changed since you last read it. There's this iterative
cycle of release, gather feedback, edit, and re-release going on. It
happens even when no one's paying attention to the list.
> my opinion is still that you are suggesting a massive new complexity of
> autogenerating self-building tests that isnt really necessary. this
> level of complexity will form a roadblock to long term maintenance and
> developer understand. unless of course you're planning on the only
> person doing long term maintenance or developing on this being you. if
> that's what you're thinking, go for it. do whatever you want.
I don't see the massive complexity you do. The proposal is for a
program that combines a set of test libraries (such as "selects.t" and
"alarms.t") with a set of event loops (Gtk, Tk, Event, IO::Poll,
select), generating from them:
#!/usr/bin/perl -w
use strict;
use lib qw(./mylib ../mylib ../lib ./lib);
use Gtk;
require "selects.t"; # and a second one with "alarms.t"
exit;
and
#!/usr/bin/perl -w
use strict;
u
Module naming conventions
Im working on a module that utilizes POE::Component::Server::TCP. Being the neat freak that i am, im inclined to name the module POE::Component::Server::TCP::MUD, though it seems rather cumbersome. I've seen other modules (such as IRC::Bot) that take the last module and use it as the begining of theirs. However when doing a CPAN search, having the full title is helpful for a first glance appraisal of how its written. Is this something people just do however they see fit, or is there a standard/movement to have it one way or the other? Disclaimer: I apologize if this has been covered, in the case that it has please point me to the post. I tried to scan for it, but didn't come up with anything.
Topic drift
On Sat, Feb 21, 2004 at 01:03:38AM -0500, sungo wrote: > On (02/20 14:01), Rocco Caputo wrote: > > > Here's a summary of what we've discussed so far. Keep in mind that > > Scott's original goal was to make wheels faster, not to make call() > > syntactically sweeter. > > let's keep in mind that this was a sidebar discussion that got started > because of an off hand comment i made about session-only stuff going on > in kernel.pm. > > let's also keep in mind that this api discussion was started in spring > of 2002 as a replacement or addition to yield(); > > i don't actually care about scott's patch or goal at this point. i was > and am interested in a completly separate but perhaps intersecting api > discussion. > > it seems that discussion can't happen at this point without it getting > dragged into scott's patch. so i'll wait another two years before > bringing it up again... I apologize for misunderstanding. I evaluated your posts under the current discussion, not the completely separate one. It would help me spot the topic drift if you would start a new thread---or at least change the Subject line---when you branch out into a different discussion. Thank you. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
