RE: Take back your modules! (was: Re: Give up your modules!)
Title: RE: Take back your modules! (was: Re: Give up your modules!) On Sep 7, 2006, at 9:08 AM, Mark Stosberg wrote: I say: If you are care about a module's maintenance, start acting like you own it, being considering that others, especially the current maintainer, may feel the same way. Nice. Worthy of a use.perl.org post so others can see it. Maybe perlmonks too. I heartily concur Yves
RE: What to do about abandoned / unmaintained CPAN code?
Title: RE: What to do about abandoned / unmaintained CPAN code? -Original Message- From: Linda W [mailto:[EMAIL PROTECTED]] Sent: Monday, June 12, 2006 12:34 AM To: module-authors@perl.org Subject: What to do about abandoned / unmaintained CPAN code? I was going through the Win:: modules and wanted to try a few, but got stuck when a basic one failed to work: Win32::API (http://cpan.uwinnipeg.ca/dist/Win32-API). It was last released over 3 years ago. The last time the author touched any of his modules was about three years ago. There Non of the bugs listed in rt.cpan.org are answered or addressed. There have been outstanding bugs on this module for almost 2 years (1st open filed June 25,2004). I tried the email address listed for the author, but it bounces. So how are modules pass on once their owners seem to have passed on CPAN? The author (Aldo Calpini) CPAN id=ACALPINI, also owns Lingua-IT-Conjugate Lingua-IT-Hyphenate Lingua-Stem-It Tie-AliasHash Win32-API Win32-Sound Win32Shortcut --- All modules appear to be stale. The latest released one, Tie-AliasHash was last touched June 26, 2003. So what is the procedure for dealing with abandoned modules? Are they put up for adoption or what? Try a posting on perlmonks. He used to frequent that site ona regular basis. Yves
RE: New Module Proposal - Math::Interval
Title: RE: New Module Proposal - Math::Interval Ken Williams wrote on Thursday, March 02, 2006 4:28 AM On Feb 26, 2006, at 6:46 PM, Brendan Leber wrote: First I need to explain a bit about intervals. In this context an interval is a new type of number just like a complex. Intervals are used to represent values in calculations where the answer can not be exactly represented. For example, the quantity 1/3 does not have an exact binary representation so you must round the answer to the nearest representable value. When evaluating calculations with an interval the results are rounded out so that the real answer is somewhere between a lower and upper bound. (The lower bound is rounded down toward negative infinity and the upper bound is rounded up to positive infinity.) So dividing 1 by 3 could result in the interval [0.333; 0.334]. If you want to learn more the best place to start is at: http://www.cs.utep.edu/interval-comp/ I fear that the name interval might be somewhat misleading here. If I saw Math::Interval on CPAN, I'd expect it to deal with connected subsets of the real number line, and to support methods like intersect(), overlaps(), contains(), and so on. This is the sense that we'd find in, say, the Rivest/Cormen/et-al algorithms book. I agree. Your sense of intervals seems rather to be more akin to error bars on a calculated variable, right? Is this interpretation of intervals necessarily incompatible with the more traditional sense - in other words, could a single interface support both notions? If not, I might suggest something like Math::CalcInterval or something like that, so people know it's this calculational sense that the code deals with. Or maybe Math::Interval::Compute? Allowing Math::Interval to provide intersect(), overlaps(), contains() Yves
RE: New Module Proposal - Math::Interval
Title: RE: New Module Proposal - Math::Interval Thus, having some math background one would identify Math::Interval::Arithmetic (or maybe more proper, Math::IntervalArithmetic) at a glance in a search for interval. Imo the former form should be heavily preferred over the latter. Math::Interval admits the possibility that there could be a wide range of modules related to intervals. Math::IntervalArithmetic Does not. Not only that but CamelHump identifiers are considered to bad style in the eyes of much of the community. Yves
RE: OO list module
Title: RE: OO list module
Somwhat off topic I guess, but I thought id add a comment regarding this statement:
Interesting, but likely to introduce inconsistency. This is a
left-to-right flow as opposed to the lisp/functional right-to-left.
The lisp/functional flow (right to left) is also the expeced flow of assignmnet.
X := Y; { Assignmnet in Pascal: X becomes equal to Y }
$x=$y=$z; # Chained assignment in perl, $x and $y become equal to $z
Although iirc Knuth uses a left to right assignment operator = in AoP.
I add this comment only to point out that right to left assignment is not just a lisp/functional thing, but is also how most people learn about assignment in programming contexts. (Which is why I find it odd that people seem to find it so alien when used for higher order constructs like list operators. It seems like people with a shell background prefer left to right and people with a CS background find right to left more natural. *shrug*)
cheers,
Yves
RE: Another CPANTS/pod_coverage.t rant - FULL VERSION
Title: RE: Another CPANTS/pod_coverage.t rant - FULL VERSION As far as CPANTS is concerned, awarding points for the respective issues by checking the metrics themselves is a good idea, but looking for tests for these metrics seems rather pointless. Again, checking whether the POD is error-free is arguably valuable; checking POD coverage is questionable. We needa Kwalitee Kwalitee Metric. Anything that attempts to use Pod::Coverage to determine Kwalitee is inherently of low Kwalitee and should lose points. Yves
RE: Name advice: check license of dependencies
Title: RE: Name advice: check license of dependencies
On a side note, I discovered that using Data::Dumper on my output
object causes memory use to go through the roof. I think
Data::Dumper is chasing into the CPANPLUS data structures and
thrashing my machine. Is anyone familiar enough with CPANPLUS
internals to know whether Data::Dumper problems are well
known, or if I've stumbled on some new bug?
Assuming you are on Win32 then yes this is definitely a well known bug. The main problem is that under normal Win32 builds perl uses the OS'es malloc/realloc which doesn't seem to be smart enough to just expand the previously allocated buffer when possible. This means that every time DD appends part of the data structure it has to copy the entire existing structure. A second problem is that DD needs to catalog every single SV that it encounters in order to detect reference cycles, if there are many SV's involved this can be a lot of metadata.
Its worth noting that on Win32 many times setting the $Data::Dumper::Useqq=1; (or in later versions the $Data::Dumper::Useperl=1;) will force DD not to use the XS implementation. It seems the pureperl code doesn't suffer from this performance degradation as badly so often a dump that will overflow your available memory in XS will finish in a reasonable time in Pureperl.
Another option is to try using Data::Dump::Streamer instead. DDS takes longer to dump on average but never degrades like DD does as it doesn't build its output in memory before outputting unless specifically asked to do so. The fact its easier to read and much more accurate and correct than DD is another reason to consider it. (It can dump closures properly, including enclosed vars!)
BTW, there is a last case where DD has real problems. It relates to pseudo hashes and a rather insidious bug:
my @hash_list=({foo=[]});
my $x=$hash_list{foo};
This will cause perl to use the address of [] as the index in the @hash_list to do the pseudo hash lookup on. Which can result in the array being extended to a huge size. Its possible that perl will be ok with this, but when DD goes to build an in memory string with several million undefs in it it gets really unhappy for obvious reasons. DDS otoh doesn't suffer from this problem as several million undefs in an array are emitted as a list constructor like (undef) x $count, so while the dump will take a long time, the memory usage will be low and the program will terminate without exhausing available ram.
Yves
RE: Name for module to construct URI from named params?
Title: RE: Name for module to construct URI from named params? I'm planning to extract some code from MasonX::WebApp and release it separately. All it does is take a set of named params and return a new URI object from it: my $uri = URI::FromHash::uri( scheme = 'http', domain = ... ); It'll probably just have that one function, uri(). Any thoughts on the name? I've been thinking of calling it URI::FromHash but I'm open to suggestions. FromHash seems inappropriate, as you aren't actually using a hash there. Yves
RE: Name for module to construct URI from named params?
Title: RE: Name for module to construct URI from named params? FromHash seems inappropriate, as you aren't actually using a hash there. Excellent point! Um, how about ... URI::NamedParams URI::Constructor URI::Creator The first is clearest, but people always hate it when a module describes its interface in the name (like Foo::OO), although maybe in this case that's ok because that's really the whole point of the module, to provide an alternate to the existing URI interface. While in general I agree with you about the name/functionality point I think URI::NamedParams is the best option you listed. It's a bit long to type, but that's fine IMO. Especially if you export the uri() sub you quoted in your original post. Yves
RE: RFC - Test::Stupid module
Title: RE: RFC - Test::Stupid module there will be some kind of boilerplate text. Unless maybe it asks you to write the documentation before you write the module. (Fine for some developers, but not everyone.) Now that would be a cool tool. You simply write a bunch of .t files and it produces a stub module and documentation from it. :-) Yves
RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
[EMAIL PROTECTED] wrote on Monday, June 27, 2005 9:46 AM
Anyway, the next version of Getopt::Long will have the ability to use
an arbitrary array instead of ARGV.
Now, do you want this to be yet another if the first argument is an
array reference ... or yet another :config option?
Imo it would better to expose a different subroutine name for this.
Ie:
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Is that ruled out for some reason?
Yves
RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern) -) Structured access to the option settings -) Option to pass in something other @ARGV to the arg-processing code. Id be curious what you mean by the first, and Im confused why the obvious solution to the second is not good enough. local @[EMAIL PROTECTED]; Goes a long way you know. Yves
RE: RFC: Getopt::Modern
Title: RE: RFC: Getopt::Modern
[Quoting Eric Wilhelm, on June 16 2005, 15:14, in Re: RFC:
Getopt::Mo]
15 years * n requests/year = 15*n degrees of flexibility =
unpredictable
Hmm. I'd say
15 years * n requests/year * m happy users = reliability
which is as meaningless as your formula.
Its not just happyness with the reliability, its also the reliability of the author. I know for a fact that Johan responds to patches and bug fixes and feature requests quickly, and usually in a way that makes the user happy. (I think he turned down one patch of mine, but applied at least two or three so im happy with those odds.) OTOH, and no offence Eric, I don't know about you and your responsiveness. ID say its pretty hard to beat Johans.
True, but Getoptions() currently contains all of the expertness of
G::L, which means that other modules cannot learn anything about the
options (such as when Getopt::Helpful would like to know if these are
simple/float/list/hash, etc options without re-implementing G::L's
parsing.)
I can make this information available, if users would be interested.
Well, you already published the rules for parsing the options which was all I needed to write a wrapper around G::L to have it integrate INI file configuration and an a simplified interface for implementing defaults and options in a single hash.
If you tear it apart and put it back together in pieces,
How I do it, is my responsibility.
Agreed. So long as the parse rules don't change bizarrely IMO publishing them should be sufficient.
* multi-pass support
I think this is possibly the only real improvement to G::L.
And, (from my reading of G::L) one that requires a fundamental
restructuring of the code.
Unless I misunderstand what you mean by multipass here I think you are wrong:
{
local @[EMAIL PROTECTED];
Getoptions();
}
Getoptions();
Done. And that's exactly what I do in Getopt::Long::INI (which thanks to this thread I now remember I need to upload to CPAN.)
I currently have two projects that address this issue: Getopt::Toolkit
(which is based on Getopt::Long) and Getopt::Long version 3 (which is
a complete redesign, a.k.a. Getopt::Long on steroids). Merging the two
projects into a single new Getopt::Long version is somewhere on my
TODO list. HOWEVER, since I highly appreciate my happy users, whatever
comes out of the merge will be drop-in compatible with the current
Getopt::Long. If this implies that you will not use it because it is
too flexible, that's fine with me. One unhappy user against a zillion
happy users.
OOOH. Maybe I shouldn't upload Getopt::Long::INI after all...
Anychance of some previews?
Finally, I must say, your web site makes me sad.
I can see why. Just so you know many of us hold G::L and yourself in high regard.
Cheers,
Yves
RE: Module for simple processing of log files
Title: RE: Module for simple processing of log files Le mardi 29 mars 2005 à 17:52, Orton, Yves écrivait: I started working on a project like this but never got around to finishing it. I called it Generic Record Processing System IE GRPS. The point being that this isnt a facility related to parsing log files, its a facility relating to processing any file of parsable records in a mechanical way. Then what do you think of Record::Processor? Great. Although you might want to take a little bit of time to think about how you would subdivide that space. For instance i could imagine: Record::Processor::Parser Record::Processor::Writer Record::Processor::Writer::XML Record::Processor::Writer::xSV Record::Processor::Writer::Packed Record::Processor::Reader::XML Record::Processor::Reader::xSV Record::Processor::Reader::Packed ... Etc... If the framework makes sense it should be fairly easy to extend it for new data representations, output formats and the like. For instance maybe I have some kind of specially encoded records that need to be preprocessed before your framework can be executed then it should be fairly easy to add a new subclass and have it DWIM. Also, when i say these classes what im thinking is that they encapsulate the knowledge about how to convert a rule specification into _source_code_ im not thinking that they should have methods that are executed inside of the parse loop. IMO there shouldnt be ANY subroutines inside of the parse loop. That way the resulting parser is lean and mean and fast. No method lookup BS or subroutine call stack overhead. Anyway, as i said i look forward to seeing your work. :-) Yves
RE: Introduction Letter
Title: RE: Introduction Letter messy. Four thumbs down to this idea. You have four thumbs Aristotle? Must make for a crowded space bar eh? ;-) Yves
RE: Name for GStreamer bindings
Title: RE: Name for GStreamer bindings On Wed, 2005-02-23 at 14:08 +0100, David Landgren wrote: Another alternative is to let the user choose. Take a look at Yves' Data::Dumper::Streamer module. During the installation, the user has a choice of additionally installing it in the DDS namespace (this does not occur by default). That doesn't sound like a good idea to me. Application writers couldn't be sure if they can use the short version of the package name, since it's up to the user/package if it gets enabled. Except that application writers shouldn't give a toss about how long a modules name is. Somebody writing one liners or quick snippet might have a case but anybody writing maintainable code doesn't. The point of the DDS alias is so you can say: perl -MDDS -eDump(bless qr/oh my god!/,'ARRAY') Not really so that you can say use DDS; Cheers Yves
RE: Name for GStreamer bindings
Title: RE: Name for GStreamer bindings
If all modules have really short names then nobody knows
when anybody
else's modules are for, which rather defeats the purpose of
Cpan. Cpan
is a global namespace, and as such names have to be chosen
carefully to
be as meaningful as possible to people who don't share the author's
context.
Yeah, I agree. That's why I like Mark's proposal of using
aliased.pm to
alias something like Media::GStreamer to Gst.
I need something that is easy and fast to type.
Why? I can see why you'd _like_ something that's less to
type, but why
is there a need that applies to this module rather than
other modules.
You only have to type the module name in the use line and
in any class
methods, often just a constructor.
I tried to explain that in my original mail. The GStreamer bindings,
just like Gtk2 or Gnome2, are different. You don't just use one
constructor once. Typical applications will have to create many
Gst::Element's, a few Gst::Structure's, some Gst::Index's,
Gst::Caps's,
a Gst::Clock, etc., etc. Try imagining how long this
paragraph would be
if I used Multimedia::GStreamer as the namespace.
Export a constant Gst() that equals Multimedia::Gstreamer.
Ie the moral equivelent of
use constant Gst='Multimedia::Gstreamer';
Gst-new();
Or make a factory sub:
sub GstNew {
my $class=Multimeadia::Gstreamer::.shift(@_);
return $class-new(@_);
}
And also possibly a clone method:
my $elem=GstNew(Clock);
my $other_elem=$elem-clone();
Yves
RE: When Did a Module Become Core?
Title: RE: When Did a Module Become Core? And for the even lazier, who can't even be bothered to install a module: http://www.twoshortplanks.com/modulecorelist/ And for the truly lazy who think that clicking on an URL and filling out a form is too much work, with WWW::Mechanize you could... oh, wait... Speaking of WWW:Mechanize, anybody else out there get bizarre problems installing it on 5.6.2? (ie segfaults and stuff?) Yves
RE: Subclassing a mailer
Title: RE: Subclassing a mailer Well here I have this Subscriber object, let's call it. They signed up on a web form, and I've poulated the object with the validated data. what would I like to do with the Subscriber? o send them a welcome mailing o snailmail - add them to tommorow's list of mailing labels along with a marker to the correct template o e-mail - send them a greeting using the welcome template o add them to a database o retrieve them from a database o based on certain criterion, send them monthly mailings of special events o based on certain criterion, send them coupons on birthday or anniversary The Subscriber object, can, as necessary, generate from itself a complete address, complete email, greeting (including salutation, for use in templates), make sure we've entered a valid date for b-day/anniversary, etc. There's other things but by and large I can program them into the admin interface easily enough, but my thought is to abstract away some of the functions in order to simplify the interface programming. # clone the subscriber and send them a welcome greeting my $mailer = Subscriber::Mailer-new($subscriber); # fill in the welcome template $mailer-add_template( $template_object ); # fire it off $mailer-send() or generate_some_sensible_error($!); There's still the part that needs to determine whether we're sending them an e-mail or a printed mail to a snailmail address, to consider, but this is the 'raw idea' of the thing. Ok, so you want to create wrapper classes to provide a generic interface into a bunch of arbitrary classes, thats not quite what i thought you had in mind. Presumbly there still will be some object in your framework with a HASA relationship to those wrappers? Yves
RE: Subclassing a mailer
Title: RE: Subclassing a mailer ahh no, nothing in that regard.. What I want is to add some of said capabilities to another module that I'm creating that's unrelated to any thing to do with mailing. The object merely tracks some client data. In some instances I'll want to send an e-mail to the address in the client data, if they have supplied one. The body of the mail may be created from a Text::Template or some other source, possibly, but essentially I would like to, at some branch in the end-user code, hand it off to be mailed out, but with certain prerequisites determined by my own object. IMO this is probably a bad reason to subclass. It sounds much more appropriate to do a HAS-A relationship instead of a IS-A relationship. For instance your code at some point is going to call a method that causes an email to be sent. At that point you would create a MIME::Lite object and use it to create and send the mail as needed. Doing this via ISA semantics doesnt make a lot of sense to me. If you were overriding some behaviour in the mail module it would be a different story. Regards, Yves
RE: Module naming advice
Title: RE: Module naming advice Which is my problem with 'alias.' Case-insensitive systems will happily load a module with incorrect case (after loading, though, using the name with incorrect case will cause problems). Which module would get loaded? Assuming they are both installed into site/lib then whichever one was installed last. :-) Yves
RE: Module Name: Net::Lite::FTP
Title: RE: Module Name: Net::Lite::FTP On 05 January 2005 18:16 Ovid wrote: I'd much rather see you work with the existing Net::FTP and enhance it either by patching or by subclassing. If I understood the original author correctly, he could not patch Net::FTP because those working on Net::FTP were changing things and not accepting new features. This has been going on for a couple of years. How many more years should we wait for this to be finished? IMO the only person who can speak to this particular point is Graham Barr. Until Graham says its not worth waiting for IMO the best thing is to work towards putting the TLS functionality in that module. If the OP has difficulty doing so then perhaps he could or should ask for help to do so. Im sure the folks on Perlmonks for one would be happy to help. Yves
RE: FSA::Rules
David E. Wheeler wrote on 15 December 2004 23:45 On Dec 15, 2004, at 12:43 PM, David E. Wheeler wrote: D'oh! I've already renamed it DFA::Rules in Subversion. Ah, well, at least it's easy to change. Look for the new module to be on CPAN later today. And here it is: The following report has been written by the PAUSE namespace indexer. Please contact [EMAIL PROTECTED] if there are any open questions. Id User: DWHEELER (David Wheeler) Distribution file: FSA-Rules-0.02.tar.gz Number of files: 11 *.pm files: 1 README: FSA-Rules-0.02/README META.yml: FSA-Rules-0.02/META.yml Timestamp of file: Wed Dec 15 22:06:02 2004 UTC Time of this run: Wed Dec 15 22:34:51 2004 UTC The following packages (grouped by status) have been found in the distro: Nice one! Yves
RE: DFA::StateMachine
Ovid and I were getting fed up with the horrible DFA::Simple module, so I wrote a new module, DFA::StateMachine, to take its place in our work. But I'm no computer scientist, so I'm not even sure whether the name is right or if the module functions the way a DFA state machine is supposed to behave. /pedant mode: The term DFA::StateMachine is like say Car::Car. A DFA is by definition a state machine (it stands for determinisitic finite state automata). And after a review of the code IMO using the term DFA is a bad call. Normally DFA implies a specific type of implementation of a pattern matcher (as compared to say perls NFA [nondeterministic finite state automata] regex engine). While I can see the overlap that you are getting at here I think you will find less people review your work just because they think it must have to do with pattern matching and not to do with the generic construction of a rules processor. This is more of a turing machine than what is normally called a DFA. A term that you encounter in the literature for this type of construct is an FSA (finite state automaton/aka turing machine) which doesn't have such a strong association to pattern matching. Maybe: FSA::Rules is better? /end pedant mode Having said that it looks like an interesting module. Id be curious as to what you use it for tho. Yves
RE: DFA::StateMachine
Based on this definition, I'm not sure if my module is a DFA or an NFA state machine. In each state, you can define rules for transitioning to other states. When you call the check() method, it checks each of these in the order you defined them and transitions to the first state for which the rule evaluates to a true value. This means that multiple rules could evaluate to a true value, but since it short-circuits and there is no backtracking, technically only one transition can occur. I guess that makes it a DFA, no? IMO yes. However its also similar to the type of production system described by Church. (hefty IIRC on that :-) So long as there can only be one legal transition for a given configuration of the machine then its a DFA. Yves
RE: DFA::StateMachine
David Coppit replied on 15 December 2004 14:21
On Wed, 15 Dec 2004, Orton, Yves wrote:
The term DFA::StateMachine is like say Car::Car.
Right.
A DFA is by definition a state machine (it stands for
determinisitic
finite state automata). And after a review of the code IMO
using the
term DFA is a bad call. Normally DFA implies a specific type of
implementation of a pattern matcher (as compared to say perls NFA
[nondeterministic finite state automata] regex engine).
I disagree. A DFA can be used to implement a pattern matcher,
but that's not all. A DFA is just a data structure.
But if you do a search for literature talking about DFA's _most_ will be
related to pattern matching. For instance I just googled for determinisitc
finite state automata and most of this hits that i followed concerned
pattern matching or used the language of pattern matching to explain DFA's.
Im not arguing that you are wrong about this, just that the primary
association in most folks heads when they see DFA will be pattern matching.
In fact when discussing DFA's most of the literature discusses the
alphabet the DFA will operate on, and the language it is designed to
accept. (http://en.wikipedia.org/wiki/Deterministic_finite_automaton)
This is more of a turing machine than what is normally called a DFA. A
term that you encounter in the literature for this type of construct is
an FSA (finite state automaton/aka turing machine) which doesn't have
such a strong association to pattern matching.
FSA is a more general term that encompasses both DFA and NFA. Not having
checked the code, I'm not sure if it supports nondeterministic
transitions.
I didnt see any support for non deterministic transitions. And yes FSA does
include DFA and NFA's but it also includes DTM's and NDTM's (determinisitic
turing machines and non determinisitic turing machines).
My point was that FSA's emphasize the point that there is external memory
and that there are actions involved wheras DFA/NFA's normally have no
actions.
However, you're incorrect in saying FSA==turing machine. The key
limitation is that FSAs are *finite* and a turing machine is not. More
details:
http://en.wikipedia.org/wiki/Finite_state_machine
http://www.cs.wm.edu/~coppit/wiki/index.php?title=Quals:_Computer_Theory_and
_Algorithms
I'm not sure if this discussion helps the OP any, but I thought I should
clarify. :)
Actually i think you are wrong here. And the links you provide seem to back
me up. A turing machine does NOT have an infinte number of states. It has an
infinite memory. From the wikipedia article we see the following: (note
point #3)
quote
More precisely, a Turing machine consists of:
1. A tape which is divided into cells, one next to the other. Each cell
contains a symbol from some finite alphabet. The alphabet contains a special
blank symbol (here written as '0') and one or more other symbols. The tape
is assumed to be arbitrarily extendible to the left and to the right, i.e.,
the Turing machine is always supplied with as much tape as it needs for its
computation. Cells that have not been written to before are assumed to be
filled with the blank symbol.
2. A head that can read and write symbols on the tape and move left and
right.
3. A state register that stores the state of the Turing machine. The
number of different states is always finite and there is one special start
state with which the state register is initialized.
4. An action table (or transition function) that tells the machine what
symbol to write, how to move the head ('L' for one step left, and 'R' for
one step right) and what its new state will be, given the symbol it has just
read on the tape and the state it is currently in. If there is no entry in
the table for the current combination of symbol and state then the machine
will halt.
/quote
As far as I know a DFA is defined as a finite automaton where each
state/input combination can result in only one legal transition.
(http://en.wikipedia.org/wiki/Finite_state_machine) An NFA of course can
have multiple transitions for a given state/input combination. (You can see
this definition in regards to determinisitc turing machines and non
deterministic turing machines in the wikipedia article as well.)
P.S. My whiz-bang super-fast computer is also equivalent in power to a DFA
because its memory is finite.
Well, yeah sure, because the memory is finite and it only allows for a
single transition from a given state and input it is formally a DFA. However
this formal equivelency is a bit useless. DFA's have no memory so they cant
handle type 0 languages. However as we all know your desktop does handle
type 0 languages as in practice most statements written in type 0 languages
dont need infinte memory to resolve. But a DFA cant recurse, there is NO
stack just states.
So to put it as the article you linked to did: For example, a Turing
machine describing an algorithm may have a few hundred
RE: DBIx::DBH - Perl extension for simplifying database connectio ns
Henrik Tougaard wrote on 07 December 2004 10:59 Martyn J. Pearce skrev: On Fri, Dec 03, 2004 at 11:25:53AM +, Tim Bunce wrote: ... The simplest fix is to standardize one set of driver DSN attribute names so that at least the host, port, and database (schema) can be specified in a portable way. Is that really the simplest? It occurs that the responses on this thread, and in my experience, many people are comfortable familiar with the use of a hash (/ref) for this purpose. Maybe the number of responses on this thread come from people who have this itch to scratch. I have heard Tim Bunce (DBI, DBD::Oracle etc) and Jonathan Leffler (DBD::Informix) raise 'Beware, thing are much more complex than you think' warnings. I (DBD::Ingres) have'nt pitched in as Jonathan voiced my concerns quite precisely, saying: Beware - DBMS are more different than anyone would like. That's why DBI has the scheme it does have - it is flexible but not easily codified. I just looked at the DBD::Informix docs. According to them Informix takes a connections string like: dbi:Informix:$database where $database is constructed like this: dbase # 'Local' database //machine1/dbase# Database on remote machine [EMAIL PROTECTED] # Database on (remote) server (as defined in sqlhosts) @server1# Connection to (remote) server but no database /some/where/dbase # Connect to local SE database DBD::Ingres does something similar. DBD::Oracle appears to be closer to Sybase/MySQl: dbi:Oracle:host=myhost.com;sid=ORCL It doesn't seem like a stretch of the imagination to see the common fields host and db embedded in all three. Clearly any DBD driver that can connect to providers on a different host will have to in some way allow the user to specify which host that is. The fact that in some particular RDDBMS's culture this isnt called the host and that port is for some reason unnecessary is IMO a bit irrelevent. The fact still remains that the generic Host slot could be used for this purpose quite easily, as could the DB slot. Those parameter that make no sense could either be ignored, or somehow usefully overloaded. This would enable the establishment of a baseline set of connection details that all DBD drivers should know how to more or less deal with. At bare minimum this would mean one less trivial piece of knowledge to remember when working with multiple providers. Ingres, like Informix and (I think) Oracle, does'nt have the concept of 'host' or 'port', using other ways of adressing remote databases. It seems to me that you are trying to force an extension onto the DBI based on what a small number of RDBMSs accept. The people who want this seem to use only a few DBDs - perhaps it could be added to those? Coming up with common set of parameters that most DB's are going to require and then providing standardized names for them would seem to be useful in general. So far I havent seen anyone provide something that a given driver Has To Have that doesn't fit into the proposal. (Ie, Host,DB,Port). Which _mandatory_ parameter does Informix need that can't be shoehorned into one of those? Regards, yves
RE: DBIx::DBH - Perl extension for simplifying database connectio ns
Christopher Hicks wrote: Coming up with common set of parameters that most DB's are going to require and then providing standardized names for them would seem to be useful in general. So far I havent seen anyone provide something that a given driver Has To Have that doesn't fit into the proposal. (Ie, Host,DB,Port). Which _mandatory_ parameter does Informix need that can't be shoehorned into one of those? What does it matter? Why can't we allow for extra bits like SID's without breaking the core global values? I was given the Henrik or some other hypothetical respondant the benefit of the doubt. :-) I thought it was clear I think that this is both doable and worth doing. Anyway, Cheers, Yves
RE: DBIx::DBH - Perl extension for simplifying database connectio ns
Tim Bunce wrote on 30 November 2004 23:32
On Tue, Nov 30, 2004 at 09:38:47PM +, Nicholas Clark wrote:
On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
I don't get it. Can someone give me some small but real examples
of the problem that's being solved here?
The one that I've hit - specifying port and host, Pg vs
Mysql (and SQlite):
if ($dbspec-{driver} eq 'DBI:Pg') {
# Aaargh. Why aren't these things standarised?
$dsn = DBI:Pg:host=$dbspec-{domain};
# Aargh. W.T.F. is this case sensitivity here? It fails
to connect unless
# the name is all lowercase (as is stored within the
non-case preserving
# pg DB)
$dsn .= lc ;dbname=$dbspec-{db_name} if length
$dbspec-{db_name};
$dsn .= ;port=$dbspec-{port} if defined $dbspec-{port};
} else {
$dsn .= :port=$dbspec-{port} if defined $dbspec-{port};
}
It seems to me that the problem is of your own making.
Why have separate hash elements for all these things in the
first place?
In my case because if I connect to the same database from two different
servers with two different versions of Sybase Open Client then DBD::Sybase
and the underlying drivers need connection strings that are totally
different (and not at all intuitive IMO) but contain basically the same
data. Thus I have an ini file that contains the appropriate info along with
a special entry that determines which style to use. Now only one thing needs
to be changed between the two machines.
This is part of the code that handles building the connection string from
the ini file:
if (lc($style) eq short) {
$fmt=DRIVER={%s};UID=%s;PWD=%s;SRVR=%s;DB=%s;
@args=qw(driver username password server dbname);
} elsif (lc($style) eq long) {
$fmt=DRIVER={%s};UID=%s;PWD=%s;NLN=%s;NA=%s;DB=%s;
@args=qw(driver username password protocol server dbname);
And here is what the inifile looks like:
[dsn]
; this is the setting for GOBS01 PRODUCTION
style= short
driver = Sybase ASE ODBC Driver
username = him_or_me
password = uhuh
server = that_server_there
dbname = funky_db
protocol = blahblah
Now if we used two connection strings we have all of that data duplicated in
the two strings, which as we all know is a scenario just crying out for
refactoring. We in fact did do this for some time, but it was always falling
out of synch when the data needed to change and the ops folks were forever
changing the wrong string.
Ive got other examples of this. If you use DBD::ODBC you need an entirely
different connection string than when using the faster and better
DBD::Sybase which has as I already mentioned different requirements
depending on local features. Since we had some weird compatibilitiy issue
with Sybase Open Client for a while in some places our code had to fallback
to using DBD::ODBC when DBD::Sybase diver was unavailable, resulting in even
more connection string variants.
IMO the idea of this module is great and frankly resolves something that ive
heard many a folk (here and elsewhere) bitch about being one of DBI's few
annoyances. (That and $dbh-selectall_arrayref($query,{Slice={}}) ;-)
I will say that I agree entirely with those who argue that DBIx::DBH is a
bad name. IMO DBI itself should have a more transparent way of handling this
so an additional module is not required. Surely there is base information
that pretty well all serious DB's will require to open a connection so
mandating a driver agnostic interface to providing those details and then
letting the driver do the rest would seem to make sense.
Yves
RE: DBIx::DBH - Perl extension for simplifying database connectio ns
It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. Duplication of data in multiple places is the answer I think. The more DSN strings you have the more needs to be changed later on, and the bigger the chance that those changes include errors. Having a single transparent interface would reduce that error (and the frustration associated with it) Cheers, Yves
RE: Let's eliminate the Module List
Title: RE: Let's eliminate the Module List I agree with you all, I know the list is probably doing more harm then good, but it wasn't like that years ago, and the only reason it is like that now is that the list isn't being updated! If someone keeps it up to date, I think it'll be a good thing for all of us once again. If someone keeps it up to date they wont be doing much else is the impression I get. Some things that work well for small communities just don't work well in large ones. It seems to me that the module list is one of them. I personally would like to see it go. Yves
RE: Renaming module - Algorithm::SkipList
Title: RE: Renaming module - Algorithm::SkipList * Orton, Yves [EMAIL PROTECTED] [2004-08-02 11:05]: Really, IMHO the tree modules and yours and probably others more should be in some sort of Datastructure:: namespace. Oh god. Do we really have such a namespace? No, not to my knowledge. What is particularly despicable about it? In my eyes data structures are pretty much inseperable from the algorithms that operate on them. For instance lets say we have a Tree structure, we cant insert into or delete from the tree without using an algorithm that is specifically desgined for that data structure. So I really hope we never end up with a Datastructure namespace that just confuses things more than it already is. Yves
RE: Renaming module - Algorithm::SkipList
Title: RE: Renaming module - Algorithm::SkipList * Robert Rothenberg [EMAIL PROTECTED] [2004-07-31 09:47]: I have a module called List::SkipList which has been on CPAN for quite a while. I'm thinking of renaming it to Algorithm::SkipList, which seems more appropriate (and nobody said yeah or nay to my request for the List::SkipList namespace on [EMAIL PROTECTED]). Does anyone consider that an inapropriate name? Hmm. It's a datastructure, not an algorithm, no? Both afaik. Really, IMHO the tree modules and yours and probably others more should be in some sort of Datastructure:: namespace. Oh god. Do we really have such a namespace? Yves
RE: CPAN Rating
Title: RE: CPAN Rating Personally I think the current rating system should be enough - only not enough people use it (for example my modules have only one or two ratings, yet they are used by a lot of people, and have been for many years). Well, personally ive never rated your module because its seems a little strange rating the only module on the net that can do what it does. (I'm speaking to DBD::Sybase here). But of course it rocks, and ill fill one out in a sec. Thanks a lot michael, Yves
RE: CPAN Rating
Title: RE: CPAN Rating [EMAIL PROTECTED] (Khemir Nadim) writes: But I can't live anymore with the low quality and release process that CPAN has!!! *sigh*. Is it that time of year again? We have this discussion every six months or so. Everyone talks about it. Nobody does anything about it. Nothing gets done. Goto 1. I think part of the problem is that those with a desire to do something about it are not really in the position to do so. What do I have to patch to change search.cpan.org, or who has to agree to changes to CPAN itself? I don't really think that dismissing an unsolved problem as being not worth solving because it hasn't been solved is that logical. While I agree that this does come up regularly I see that as a sign that either people don't understand something or that there really is a problem. Personally I was thinking and have discussed a number of a times in other forums the idea of a Selected CPAN where modules would only go if they somehow satisifed some set of yet to be defined criteria. But the problem is that this wouldn't make a lot of sense to do without doing so alongside the current CPAN. Anyway, Yves
RE: too many tests?
Title: RE: too many tests? This works fine up to 5 char combinations... but when you get to the over 900.000 tests for the 6 char ones... argh ;-\ My computer simply froze (2)... and a message stating something like Enormous test number seen kept displaying. So... is this normal? How would you normally test this kind of thing? Yes it normal more or less. Normally you would do a proof on something like this. And you would work through the code and ensure that it actually does what the proof says it must. Think about it, any other approach would require an infinite number of tests. Yves
RE: PerlHack - Adding new flag into a SV
Title: RE: PerlHack - Adding new flag into a SV
From: Orton, Yves [EMAIL PROTECTED]
I thought you are just automagicaly weaken()ing the referenced
stored in the tied hash??? Something like package
Hash::NoRef; use
Scalar::Util qw(weaken); require Tie::Hash; @ISA = (Tie::StdHash);
sub STORE { $_[0]{$_[1]} = $_[2];
weaken($_[0]{$_[1]}) if (ref
$_[2]);
}
'And that\'s it!';
Am I missing something?
Itll segfault under many circumstances.
yves
Then you should report an error in Scalar::Util.
Do you have an example script that segfaults?
No but I can describe one that would. Imagine a binary tree. We store each node using weakrefs in the structure you describe. Now I search and find an internal node of the tree. The root of the tree falls out of scope, essentially stripping the tree of all of its relatives. Now the hash contains a zillion refs to non existant objects. Access one of those and POOF!
Maybe you were thinking I meant a problem with your code. I meant a problem with the entire approach. IMO weak refs are not the greatest solution to the problems that they are usually used for. Often there are much better approaches that don't involve risking segfaults.
Anyway, :-)
Yves
RE: PerlHack - Adding new flag into a SV
Title: RE: PerlHack - Adding new flag into a SV
I thought you are just automagicaly weaken()ing the referenced stored
in the tied hash???
Something like
package Hash::NoRef;
use Scalar::Util qw(weaken);
require Tie::Hash;
@ISA = (Tie::StdHash);
sub STORE {
$_[0]{$_[1]} = $_[2];
weaken($_[0]{$_[1]}) if (ref $_[2]);
}
'And that\'s it!';
Am I missing something?
Itll segfault under many circumstances.
yves
RE: Looking for advice: What Perl module to use?
Title: RE: Looking for advice: What Perl module to use? I would actually suggest that you go to www.perlmonks.org and post a question in the Seekers Of Perl Wisdom section. The module list isnt in my opinion the right place to do this. Youll get better answers faster at Perlmonks than you will through the modules list. (People compete to answer first!) Not only that but youll probably get people replying back with working code samples. Cheers, Yves -Original Message- From: Martin Streicher, Editor in Chief [mailto:[EMAIL PROTECTED]] Sent: 19 April 2004 06:04 To: [EMAIL PROTECTED] Subject: Looking for advice: What Perl module to use? I am looking for a Perl module to do some (specialized) text parsing. May I post a question to this list and ask for advice on the suitability of certain modules? If not, which list should I post to? -- Martin Streicher, Editor-in-Chief Linux Magazine e: [EMAIL PROTECTED] h: http://www.linuxmagazine.com b: http://blog.streicher.us r: http://blog.streicher.us/rss.xml p: 510.528.5057 f: 815.550.2106
RE: defining 'constants' at run time
Title: RE: defining 'constants' at run time
david nicol wrote on 11 March 2004 18:38:
On Thu, 2004-03-11 at 05:20, Orton, Yves wrote:
use constant ARG1=$ARGV[0];
is better
Absolutely. the begin block posting was a hurried and untested
example of how to use a BEGIN block.
For the record I threw that in for other readers, not so much yourself.
:-)
By the time people subscribe
to module-authors you'd think they would know how to use a BEGIN
block to evalueate some parts of their program before the rest of
it.
Youre expecting them to have read the fine manual? Yikes! ;-)
I suspect that since @ARGV is set before any compiling happens,
a bign block might not actually be needed in that case at all.
Nope i dont think it is. And a useful thing to remember is that
use Foo @args;
is really a special way to spell
BEGIN { require Foo; Foo-import(@args) }
so
use constant ARG1=$ARGV[0];
is equivelent to
BEGIN { require constant; constant-import(ARG1=$ARGV[0]); }
which is more or less equivelent to
BEGIN { eval 'sub ARG1 () { $ARGV[0] }' }
This is actually a useful trick as you can do tricky stuff inside of the implied BEGIN that a use represents.
A better example would have had a complex startup phase entirely
within the BEGIN block, and the last thing in the BEGIN block is,
to establish the 'constants' through whatever mechanism is
appropriate,
such as reading the rest of the source code through a source filter
that replaces the 'constants' with their values, in single quotes,
rather than making Perl compile and optimize.
Is it actually better to do it that way really? I would have thought the eval as you go _expression_ simplification would do the same thing but more efficiently than a source filter ever could.
Having said that ive used something very close to this approach in Tie::Array::PackedC as well as in a few other places like http://perlmonks.org/index.pl?node_id=289585 (although the latter has problems due to use base qw// not playing nicely with evaled packages that have no %INC entry.)
For that matter, the
source filter could output ANSI C and pass it to yor
compiler. Somebody
give me a grant!
Yeah, thats the ticket. Sombody give him a grant. I wanna get me some o that action fer sure.
:-)
Yves
RE: defining 'constants' at run time
Title: RE: defining 'constants' at run time
Sam Vilain responded on 04 March 2004 11:58
On Thu, 04 Mar 2004 21:55, Orton, Yves wrote;
Well, people who spend a lot of time on the message boards helping
out get a lot of questions like:
How can I replace every letter 'o' not preceded by 'f' and not
followed by an 's' without using index, subtr, or a regex.
The useless answers are typically things like
Very very carefully
With a piece of camembert and a two foot length of string
The useful answers are typically like
Why on earth do you want to do such a silly thing. USE THE
FRIGGIN REGEX ALREADY.
To the programmer who has some real reason not to use the regex
engine, that you don't know about, none of the above are useful.
Yes, but there are almost no reasons for this. And when someone says this and has a good reason its pretty clear from the post as it includes something like yeah yeah, i know, use a regex. But the problem here is that the fnorble is fnazzled in regex fnubar and so thats out of the question and then the respondants are ina much better position to help. Like saying, well if you recompile the fnubar with gcc 3.1415926535 then youl find this problem goes away and then you _can_ use the regex.
On the other hand,
sub doit {pack(C*,(map{($a!=102)($_!=115)($b==111)($b=118);
($q,$a,$b)=($a,$b,$_);$q}unpack(C*,$_[0])),$a,$b)}
would either be entirely what they're after, or speak aloud as an
adequate answer to why s/([^f])o([^s])/${1}v${2}/g is usually better.
Heh. Cool. ++ to you.
To broad-handedly cast aside the the bearer of a question's approach
as flawed is incredibly closed minded. Pretending that you know best
for their situation is at worst arrogant and at best naive.
Not really, the respondant is a volunteer. Its up to them how to answer. And if they think a posters claim that i cant use X is rubbish then its their perogative to say so. And frankly if someone either arrogant or naive wants to help me in a way that doesnt really help I suspect i would say thanks but actually... and not why the hell dont you trust me on this. After all they dont owe me anything, and if they thought they were helping why should I care if its misguided?
And IMO, the vast majority of times when you really look into a claim that I cant use X (X=modules is a _great_ example) you find out that in fact they _can_ use the feature. Using the modules example, the number of times ive see I cant use a module and the real fact is my sysadmin wont install anything to sit/lib which doesnt prevent the user from installing the module locally for themselves.
Anyway, I was just responding ROUS'es somewhat rhetorical question about why people make this kind of comment. The reason IMO is that its because usually such comments are right on the money. The fact that it wasnt here is beside the point.
Yves
RE: capturing carp()s in module tests?
Title: RE: capturing carp()s in module tests?
i want to test error checks in a module i'm working on. the
error paths carp() the problem and then proceed.
is there any way to capture the carp text (without using
some of Carp.pm's internal routines) for testing that they're
correct under the various error conditions?
Intercept $SIG{__WARN__} and $SIG{__DIE__} and youll capture all dies and warnings, including those generated by Carp. Unfortunately it isnt straightforward handling $SIG{__DIE__} correctly if eval is in use.
Or override Carp::carp().
Something like
*Carp::carp=sub {
$message=Carp::shortmess @_;
handle_carp_message($message);
warn $message;
};
Yves
RE: OK, so we've decided that the right modules are too hard to f ind.
Title: RE: OK, so we've decided that the right modules are too hard to find. [EMAIL PROTECTED] (Elizabeth Mattijsen) writes: I've released about 30 modules in the past 1.5 years. I _never_ bothered to try to register. I guess that means something. Likewise. (although slightly more than 30 ;) I just don't see the point of the modules list, especially now we have search.cpan.org. Afaik the only real reason for the modules list is to prevent people from accidentally installing a module that is released under a known name, but by an unknown author. So if I release Email::Simple 1.4 no one using CPAN.pm to install it will end up with my version, they will always end up with your version. This does something towards preventing attacks on the community by embedding hostile code in the install scripts and then uploading them under trusted names. Its actually very annoying because the hand over and ownership management on CPAN isn't that hot (and doesnt synchronize with RT fwict), so if you take over maintenance of a module and it hasnt been properly handed over the code can only be found via the website or via an 'ls' on the authors directory. Which brings me back to the web site. From what I can tell this security measure has not been implemented on the web site. There is nothing on a page to tell you if the module you are looking at is actually released by the correct person. So presumably if I upload DBI 1.42 with a trojan to wipe the hard drive I bet that just from web downloads alone ill end up with some victims. So not only does search.cpan.org NOT make the modulelist redundant, it in fact should should be modified to ensure that module list information is presented to the user. At very least when viewing a module the page should very clearly state that the displyed module is not released by the approved author/owener of the namespace. (Assuming of course that this is the case.) IMO the module registration process is broken from a management point of view (ive stated this in private correspondence to the site owners and CPAN folks) but the module registration process is definately not redundant or unneeded. It badly needs to be reformed and reworked though. Just my (not so) humble $0.02. Yves
RE: OK, so we've decided that the right modules are too hard to f ind.
Title: RE: OK, so we've decided that the right modules are too hard to f ind. [EMAIL PROTECTED] (Yves Orton) writes: Afaik the only real reason for the modules list is to prevent people from accidentally installing a module that is released under a known name, but by an unknown author. So if I release Email::Simple 1.4 no one using CPAN.pm to install it will end up with my version, they will always end up with your version. You're confusing the module list with the module list. :) Shoot. Your right. I keep confusing the module list with the module list. Its a horrible habbit. :-) 02packages.details.txt.gz, generated by PAUSE, does what you're talking about. The module list (00modlist.long.html) is what we were talking about, since that is the one you have to register for. And I still think that 00modlist.long.html is now irrelevant. Ok, now I get you. Yeah you may have a point there. But I still think my point about the site being an security vulnerability is valid. CPAN.pm provides a modest level of protection against this type of thing, but the site none. I hope it doesnt take an exploit for some logic to be added to the pages to state that the release is not by the official author. Yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy Even if it's done with benchmarks. Just curious, but how well does MIME::Lite fare? Yves
RE: Testing output to STDOUT and STDERR
Title: RE: Testing output to STDOUT and STDERR Though, I must say that I prefer his API. The above was really just a quick hack based on what I'd extracted out of the ePerl code base. I'd call it something like IO::Capture if I were to CPAN it. IO::Seize isn't quite right, but seize is definitely a good Perlish name for the function. Note that php has a built-in function to do just this. Its worth noting that this approach wont actually grab everything on the tied filehandles. There are enough ways to bypass the tie that you have to do a lot more than that to get the majority, and even then there is stuff that will still bypass it. Its very annoying actually that there isnt a reliable and clean way to intercept STDOUT/STDERR properly. (IMO) Yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy I think the name is unhelpful. A few years ago I happened to use several different mail-sending modules, in different projects or in code instigated by different people. In general they were OK, but none of them stood out as being superior to the others. Then, somehow, I encountered MIME::Lite. It seems to do everything I want and be easier to use than the alternatives, and I use it for all mail-sending. But I'd never've thought to try it in the first place. Even when I first saw the module I assumed it was for creating mime messages with attachments, and since I didn't want to do anything as complicated as attachments I wouldn't need such a complicated module when there were simpler ones available, surely? But can anybody suggest a better name, one that would suggest to newcomers that this is a good module to use for sending mail? Mail::MIME::Lite doesn't really help -- I'd still make the same assumptions about it as I did, and investigate the modules that sound as though they do sending: Mail::Send, Mail::Sender, Mail::Sendmail, Mail::Transport::Send, Mail::SendEasy, Mail::Mailer, ... Well suggest a name. It seems like folks concur that the name is not so great so ill alias it to something else. Mail::Simple? Mail::Sender::Complete Mail::Lite::Not (heh just joking) Mail::Formally::Known::As::Mime::Lite? yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy [EMAIL PROTECTED] (Yves Orton) writes: Well suggest a name. It seems like folks concur that the name is not so great so ill alias it to something else. Mail::Send::MIME? Sounds good. Ill go for that. BTW, curses but i still havent found a good name for my dumper. I rue the day you wrote that post about Data::Stream. Yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy I think MIME::Lite isn't in the Module List so the name wasn't peer-reviewed. The peer-review process offered by [EMAIL PROTECTED] certainly isn't perfect, but I do believe it's very valuable. Unless I read the file incorrectly MIME::Lite is indeed in the module list, at least I see it there. Afaik its been in the wild since at least 98, if not earlier. (I dont know the full history, I am only the module maintainer) Also, I believe that MIME::Lite quite likely predates the peer review process, it certainly predates these newfangled root level names like Mail:: and such. I would argue that MIME isnt actually that bad a name. MIME is the protocol for the contents of a mail. Not related to how mails are recieved, stored, searched, or transmitted. The fact that MIME::Lite knows how to talk to modules that know how to transmit is seperate from the fact that it intends to manage MIME content mails. Since a mail need not be MIME there is no reason for it to be called Mail:: or whatever. Anyway, if someone wants to argue that I should put MIME::Lite into a different namespace ill consider it. It wouldnt be too difficult to also have it called Mail::MIME::Lite or whatever. yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy Unless I read the file incorrectly MIME::Lite is indeed in the module list, at least I see it there. Afaik its been in the wild since at least 98, if not earlier. (I dont know the full history, I am only the module maintainer) Ah, thanks. I'd missed it. (And I wish search.cpan.org made it easier to tell if a module is registered). Indeed. I also wish CPAN.pm made it easier to search for and install unlisted modules. Also, I believe that MIME::Lite quite likely predates the peer review process, it certainly predates these newfangled root level names like Mail:: and such. There's always been a review process for the Module List. Really? Ok, my apologies. But it's always hard to look several years into the future when trying to see how namespaces might evolve. I think that the issue here is that there has been an evolution as to how we think namespaces. MIME:: seems to be named at the implementation level. Its for stuff that does MIME manipulation. Mail:: seems to be named at the functional level. Its for stuff that does emails. These are two totally different philosophies I would say. And personally I think the former makes more sense. Consider a module like Net::SMTP. If it was named at the functional level it would probably be called Email::Transport or something. But personally I think Net::SMTP makes much more sense. It implements the Net:: prototcol SMTP. Should a new protocol come out we wouldnt be modifying Net::SMTP as we would probably have to modify Email::Transport, we would simply add a new module to libnet like Net:SFNMTP (Some Funky New Mail Transport Protocol[tm]) :-) Yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy But my point is not to rag on about Mail::Box, or any other mail handling module. It's to write smaller, cleaner, single purpose ones. Hey, Email::MIME came out the other day. Comments welcome. Ill have a look at some point. It will be interesting to compare it with MIME::Lite. Yves
RE: Re: New module Mail::SendEasy
Title: RE: Re: New module Mail::SendEasy Mail::SendEasy can: - Handle automatically SMTP AUTH (very important in this days). - Handles automatically TXT, HTML and attachments. Soo, you don't need to think about multipart, boundary, etc... - Compress multiple attachments in a zip file. - It's an self contained module, soo, it doesn't have dependencies (unless Perl). Note that the idea of this module is to have all this resources, that you can find in different modules in CPAN, in only one module. Er, so what does it do that MIME::Lite 3.01_03 does not? Yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy Humm, MIME::Lite need sendmail or some object instance that send e-mails to reaally send an e-mail. Yes thats correct. The composition and transmission layers are logically seperate. But that doesnt change that fact that MIME::Lite is quite capable of using Net::SMTP to transfer mails. And as of 3.01_03 with authentication too. MIME::Lite is more to can build the content of your e-mail, what is just a part of all the process to send an e-mail. Well, not really. Its essentially all you need straight out of the box, given certain platform specific issues. Like libnet on win32, on the presence of something sendmail like on non win32 platforms. By the awy, I use Mail::SendEasy in Win32, soo, I can't use sendmail. And we know that the sendmail approach to send e-mails in this days is not the best, specially if you want a resource that is platform independent. Again, this is merely an question of configuration (also convention, many non sendmail mailers use the same command line arguments). With a single line of code you can use whatever you like for the transmission part of the mail. IMO that good design in fact. There is no hard binding of the two layers. MIME::Lite can use anything that accepts the print method to use for transport. It really doesnt care. So in a sense what you have is two reinvented wheels merged into each other. One, is the composition part of MIME::Lite. Second is one of the many tranmsission schemes available for MIME::Lite to use. Now, my question is this: Why should we assume that your MIME construction is better than MIME::Lites which has been around for practically ever, and has been tested on thousands of machines? Why should we assume that you SMTP implementation is superior to that offered by libnet? Further, how long will you be around? libnet is actively maintained by it author (a respectable member of one of the largest commercial development shops around), MIME::Lite is maintained by me, but if I lose interest it will be pased on, as it was to me. The module has a large enough following already that this is almost guaranteed. I dont say this to be rude or anything, just to make the point. Note that I have created Mail::SendEasy to be the handler of the mail system of a framework. Soo, the developer that uses this framework doesn't need, and shouldn't, care about how the e-mail is sent. It just write the e-mail. Umm, now your saying something different. The developer will HAVE to know about how the mail is sent. He will have to configure the code to use the correct SMTP server, and if he isnt using SMTP will have to configure whatever that is. This would be the same as using MIME::Lite, except that since MIME::Lite uses libnet, as long as the libnet.cfg is configured appropriately about the only thing you have to do is tell MIME::Lite to use SMTP to send, and that requirement only on *NIX systems where SMTP is not the norm. Also it handles SMTP AUTH, one of the purposes that I have wrote it, since our main Web Hoster, for security, need authentication to can send e-mails. Yes. Im aware that this is becomming an ever more common requirement of SMTP servers. Hence MIME::Lite 3.01_03 is dev release of Autheticating SMTP server friendly MIME::Lite. Well, as you can see, the main purpose is to have all this resource in one self contained package. Which doesnt seem like either a good idea, or a real benefit. Transport != Composition. So why should the two be hard bound? Yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy On Mon, 26 Jan 2004, Orton, Yves wrote: Well, not really. Its essentially all you need straight out of the box, given certain platform specific issues. Like libnet on win32, on the presence of something sendmail like on non win32 platforms. FWIW, MIME::Lite has for a long time been my favorite one-stop module for sending mail, with or without attachments. I know it can handle basically everything I need mail-wise, and it just works. All the other modules I've used seem to have various limitations, or bad APIs, etc. Weeell. I wish I could take credit for some of this, but I cant. Its all Eryq's fault. :-) But seriously, if you are using an authenticating SMTP server, review and comments and bugreports on 3.01_03 would be very welcome. Graciliano, I think the Perl community would benefit more if you would contribute to MIME::Lite than create yet another mail sending module. I agree. But im a touch biased. Gaciliano, should you wish to put some time and effort into MIME::Lite id be happy to work with you to address your concerns. OTOH, _not_ using libnet isnt going to happen in MIME::Lite so if you are hell bent in that direction then I suppose MIME::Lite isnt the right focus. Yves
RE: New module Mail::SendEasy
Title: RE: New module Mail::SendEasy If the author of MIME::Lite is interested to change it's MIME::Lite architecture (just talking about dependencies) I will be interested to add some resources to it, since as I can see now, is a popular module. I'm als a user and fan of MIME::Lite. Perhaps there is an easy way to create an alternate distribution of it that contains all its dependencies, but is easily installable. Hmm, so you mean bundle libnet with MIME::Lite and Mail::Address and MIME::Types and MIME::Base64? Its doable. Actually its more than doable, ive done it here at work. But its not my preference at all. The first and last are perfect examples. Does it make sense to bundle these if on later version of Perl they are core? What about bug fixes etc? Also, for libnet, what about the fact that most *nix users will want to send via sendmail or clone... So all that libnet stuff would be a bit of a waste for them wouldnt it? But I suppose if people wanted it I could look into releasing such a beast. Yves
RE: Spreadsheet::Perl (was New User)
Title: RE: Spreadsheet::Perl (was New User) What about 'B1:B*' 'B*:B10' 'B*:B*' ? and what about 'A1:*10' or 'A*:**' or '*' might be ambiguous. Does it mean infinity? Does it mean the last defined value in the column? I would say this is correct. Basically like pressing ctrl-cursor in excel on a given row or column. I don't know if Excel supports such functionality (I've looked before.) In VBA it does for sure. (I also just noticed the method names are the of the style GetFormulaText rather than of the more Perlish get_formula_text.) Which might be useful for VB types, but probably not real exciting for Perl types (for whom this is intended I would have thought). Of course, there's a variety of ways that might achive a workable syntax for that--tied variables, OO, source filtering, tricks with operator overloading, callback functions, or writing a full parser/interpreter. OO and operator overloading sounds to me the way to go. But im just kibitzing while eating a schoko-croissant. :-) Yves
RE: Ivy.pm: name change? to upload on CPAN
All functions in the module can be used as method; the trick
used to do
it is to use the __PACKAGE__ variable the following way:
sub init {
my $class = shift if (@_ and $_[0] eq __PACKAGE__);
my (%options) = @_;
...
}
# or :
sub bindRegexp
{
my $self = ref($_[0]) eq __PACKAGE__ ? shift : $globalIvy;
my ($regexp, $cb) = @_;
...
}
The problem appears now, when using construction such as :
use Net::Ivy;
Net::Ivy-init(-appName = foo, -loopMode = local);
# is fine!
#but when using the old construction with the wrapper:
use Ivy;
Ivy-init(-appName = foo, -loopMode = local);
Error in Net::Ivy::init: option -appName is mandatory
at -e line 1
# because now, ref($_[0]) eq __PACKAGE__ is false
Do you have suggestions? (I could find a correction, but not sure it
will be really a good one).
Well, to be honest this is a dirty trick IMO, that can cause subtle
problems. Better to go the route that File::Spec went, and add a function
wrapper for the methods. (File::Spec::Functions autogenerates the functional
equivelents from the methods on demand).
However, this would just add more modification requirements to your code.
Assuming that the first arg to your functions is NEVER a descendent of
Net::Ivy (or Ivy whichever is your root class) when called in functional
form then the following should work ok:
sub init {
my $class = shift if (@_ and UNIVERSAL::isa($_[0],__PACKAGE__));
my (%options) = @_;
...
}
sub bindRegexp
{
my $self = UNIVERSAL::isa($_[0],__PACKAGE__) ? shift : $globalIvy;
my ($regexp, $cb) = @_;
...
}
Cheers,
Yves
RE: Looking for help with Net::SSH::Perl Net::SFTP
Title: RE: Looking for help with Net::SSH::Perl Net::SFTP [EMAIL PROTECTED] (Yves Orton) writes: I more meant that being the man with the Net:: Oh, you still believe that namespace ownership actually exists in practice? How quaint. Maybe I shouldn't have uploaded my latest module into Tie::, because that's owned by... Apparently by SCO, or so they claim ;-) No, I wasnt meaning to imply he had some sort of right to the Net:: namespace, but he is responsible for the most commonly known Net:: modules, and presuambly would have considerable knowledge about who is interested in these things etc... But anyway, I was just trying to be helpful, not trying to kick up a controversy. Yves
RE: ExtUtils::MakeMaker or Module::Build
Title: RE: ExtUtils::MakeMaker or Module::Build 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? Personally my feeling is that Module::Build isn't mature enough for release ready code. The fact that without manual intervention what it produces isnt compatible with CPAN is IMO a serious argument against using it, and poses serious questions in my mind about its suitability in 5.10. Luckily it will be a long time before 5.10 is released, so Ken has lots of time to get it right. BTW, it shouldnt be seen that I am critical of Kens efforts, I actually think his project is quite a good idea and will eventually be an excellent replacement for older tools. But IMO it is not production worthy code at the current time. I dont know the logic behind using Build.pl instead of makefile.pl, but the fact that it doesnt create the later by defualt (or so I have been told) is in my eyes a serious mistake that will greatly reduce its overall uptake in the market. And for those people releasing code without a Makefile.pl, I wonder at the point of putting such things on CPAN. (Others such as Randal Schwartz have said the same thing) Another serious issue with Module::Build is that for the last ages on Win32 it doesnt. Have a look at the transaction report of trying to install it (using itself) from CPAN. It doesnt play nicely with CPAN's prerequisite system, (a Makefile.pl program would have caused CPAN to autoload these prerequisites on my system by default) and fails build. CPAN.pm: Going to build K/KW/KWILLIAMS/Module-Build-0.21.tar.gz E:\Perl\bin\perl.exe Build.PL Checking whether your kit is complete... Looks good WARNING: ExtUtils::ParseXS: Prerequisite ExtUtils::ParseXS isn't installed WARNING: Archive::Tar: Version 0.072 is installed, but we need version = 1.00 ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions of the modules indicated above before proceeding with this installation. Creating new 'Build' script for 'Module-Build' version '0.21' Microsoft (R) Program Maintenance Utility Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. E:\Perl\bin\perl.exe Build lib/Module/Build/Platform/darwin.pm - blib\lib\Module\Build\Platform\darwin.pm lib/Module/Build/Platform/VMS.pm - blib\lib\Module\Build\Platform\VMS.pm lib/Module/Build/Platform/EBCDIC.pm - blib\lib\Module\Build\Platform\EBCDIC.pm lib/Module/Build/Compat.pm - blib\lib\Module\Build\Compat.pm lib/Module/Build/Platform/cygwin.pm - blib\lib\Module\Build\Platform\cygwin.pm lib/Module/Build/Platform/MacOS.pm - blib\lib\Module\Build\Platform\MacOS.pm lib/Module/Build/Platform/VOS.pm - blib\lib\Module\Build\Platform\VOS.pm lib/Module/Build.pm - blib\lib\Module\Build.pm lib/Module/Build/Platform/Default.pm - blib\lib\Module\Build\Platform\Default.pm lib/Module/Build/Base.pm - blib\lib\Module\Build\Base.pm lib/Module/Build/Cookbook.pm - blib\lib\Module\Build\Cookbook.pm lib/Module/Build/PPMMaker.pm - blib\lib\Module\Build\PPMMaker.pm lib/Module/Build/Platform/Amiga.pm - blib\lib\Module\Build\Platform\Amiga.pm lib/Module/Build/Platform/Windows.pm - blib\lib\Module\Build\Platform\Windows.pm lib/Module/Build/Platform/MPEiX.pm - blib\lib\Module\Build\Platform\MPEiX.pm lib/Module/Build/Platform/Unix.pm - blib\lib\Module\Build\Platform\Unix.pm lib/Module/Build/Platform/RiscOS.pm - blib\lib\Module\Build\Platform\RiscOS.pm E:\DotNet\VC7\BIN\nmake.EXE -- OK Running make test Microsoft (R) Program Maintenance Utility Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. E:\Perl\bin\perl.exe Build test t\basic.ok t\compatok t\extendok t\install...FAILED test 19 Failed 1/23 tests, 95.65% okay se of uninitialized value in substitution (s///) at E:\Perl\lib/File/Spec/Win32.pm line 117. t\manifypodsok 2/17se of uninitialized value in substitution (s///) at E:\Perl\lib/File/Spec/Win32.pm line 118. Use of uninitialized value in substitution (s///) at E:\Perl\lib/File/Spec/Win32.pm line 119. Use of uninitialized value in substitution (s///) at E:\Perl\lib/File/Spec/Win32.pm line 120. Use of uninitialized value in string eq at E:\Perl\lib/File/Spec/Win32.pm line 121. Use of uninitialized value in substitution (s///) at E:\Perl\lib/File/Spec/Win32.pm line 121. Use of uninitialized value in pattern match (m//) at E:\Perl\lib/File/Spec/Win32.pm line 122. Use of uninitialized value in substitution (s///) at E:\Perl\lib/File/Spec/Win32.pm line 122. Use of uninitialized value in substitution (s///) at E:\Perl\lib/File/Spec/Win32.pm line 125. Use of uninitialized value in substitution (s///) at E:\Perl\lib/File/Spec/Win32.pm line 126. Use of uninitialized value in pattern match (m//) at E:\Perl\lib/File/Spec/Win32.pm line 127. Use of uninitialized value in pattern match (m//) at
RE: Looking for help with Net::SSH::Perl Net::SFTP
Title: RE: Looking for help with Net::SSH::Perl Net::SFTP On Wed, 19 Nov 2003, Orton, Yves wrote: Also, any suggestions on where else to post this? I would say a mail to Graham Barr might be in order. He's a busy guy. I doubt he'd want more work. I more meant that being the man with the Net:: that he would be a good person to speak to about these tings, if only for suggestions on where else to post this request. Yves
RE: Author's namespace
Title: RE: Author's namespace * at 14/11 10:25 + Fergal Daly said: But what about code that is shared by several CPAN modules but which I don't consider to be worth getting up to standard for general use. It's not that the code is trash, it's fine I just can't see anyone else wanting to use it, even if it was fully documented. I suppose I'll just have to upload Class::OhGodNotAnotherMethodMaker, I really don't see the value of adding this sort of thing to CPAN. If code's going to go on CPAN as it's own distribution then I think it should be properly documented and so on. If a distribution needs a module then either the module should be released to CPAN as a proper distribution or the module should be included as part of the relevant distribution. I though that CPAN historically carried stuff like this. Isnt that waht the scripts directory is? yves
RE: Tie::Array::Sorted
Title: RE: Tie::Array::Sorted
* Simon Cozens simon at simon-cozens.org [2003-11-12 13:32]:
Is Tie::Array::Sorted a reasonable name for it, or would another one
be more obvious?
DB_File has a way to do this iirc.
But it is a shocking ommission if there isnt at least one other way. I definately vote for Tie::Array::Sorted, but It may be worth having a look at Tie::Hash::Sorted and make them compatible on some level.
This seems a reasonable name. Is there also a hash version in the
works? I write:
for my $key (sort keys %h) {
...
often enough that I would use it.
Tie::Hash::Sorted (http://search.cpan.org/~jgatcomb/Tie-Hash-Sorted-0.10/Sorted.pm)
Tie::IxHash (http://search.cpan.org/author/GSAR/Tie-IxHash-1.21/lib/Tie/IxHash.pm)
Tie::Hash::Array (http://search.cpan.org/author/FANY/Tie-Hash-Array-0.01/lib/Tie/Hash/Array.pm)
Tie::SortHash (http://search.cpan.org/author/CTWETEN/Tie-SortHash-1.01/SortHash.pm)
:-)
Yves
RE: Class::FakeAttributes -- Opinions Wanted
Title: RE: Class::FakeAttributes -- Opinions Wanted That said, I've given up on automating non-trivial accessors/mutators. I wouldnt say that I've given up, but I dont think ive ever used any of the class based method generaotrs beside Class::Struct and even not that many times. However I often write my own loops that generate various accessors, and somewhat regularly implement generation via AUTOLOAD. I find this keeps the control over the generated code in the right place, and suits my thinking more than using one of the many Class:: modules out there. I think this is one of the areas where rolling your own is better than using a module. I know lots of people will consider me a heretic for this but whatever. :-) Yves
RE: Class::FakeAttributes -- Opinions Wanted
Title: RE: Class::FakeAttributes -- Opinions Wanted
* Orton, Yves [EMAIL PROTECTED] [2003-11-03 17:27]:
Thats because the apporach you are comparing it to is flawed.
foreach (@{$self-{foo}||[]}) { ... }
is the correct way to spell that I think.
Actually, no. See below.
If the 'foo' attribute hasn't been set to anything, then you
want an empty list to iterate over. With version C, that's
what you get.
No. If $self-{foo} is undef you get an error with version C.
You're forgetting autovivification. If $self-{foo} is undef it
is coerced into a appropriate reftype.
Gah. It seems you are correct. The rules for when autovivification happens are a little byzantine I think.
IMO this usage is a single level FETCH and not a STORE or a multilevel FETCH and as such should NOT autovivify. In fact the behaviour is inconsistant. Sometimes it autovivifies, sometimes not.
Consider:
D:\perl -e use strict; use warnings; my $x; if (@{$x}) { print}
Can't use an undefined value as an ARRAY reference at -e line 1.
D:\perl -e use strict; use warnings; my $x; for (@{$x}) { print}
D:\perl -e use strict; use warnings; my $x; for (@{undef()}) { print}
Can't use an undefined value as an ARRAY reference at -e line 1.
D:\perl -e use strict; use warnings; sub u { undef } my $x; for (@{u()}) { print}
Can't use an undefined value as an ARRAY reference at -e line 1.
So you cant just assume that for (@{EXPR}) {...} is going to be ok if EXPR resolves to undef. If EXPR is a function call return then it isnt safe.
Anyway, this is all just after the fact explanations that I am providing out of embarrasment.
:-)
Nah, just make the get_ autopopulate an undef attribute on
fetch. That way its not done unless is actually being used by
external code.
Yes, but what with? You can't know whether the attempt to access
an undef attribute is inside an array deref, a hash deref,
outside any deref contexts at all, or wherever. That's why I
proposed having a get_attr_with_default.
Ahah. Yeah good point...
Well, to be clear: I don't like the idea.
Because just as you said, having a good ::InsideOut would kill
*all* birds with one stone - what this module does and what
several others as well do (modules like the one that ties the
hash and prepends the package name on all accesses to a
traditional hashref $self - I can't remember what it's called).
On the other hand, we _don't_ have ::InsideOut so being
pragmatic, I'm saying that maybe it's not a bad idea to have this
in the meantime..
Well, maybe there are ways around the problems mentioned before. I think there are. Im just not sure yet.
Yves
RE: Class::FakeAttributes -- Opinions Wanted
Title: RE: Class::FakeAttributes -- Opinions Wanted
$ perl -Mstrict -wle 'my $f = { }; my @a = @{ $f-{foo} }'
Can't use an undefined value as an ARRAY reference at -e line 1.
Exactly my point. Stick that _expression_ in a for loop however...
D:\perl -Mstrict -wle my $f = { }; my @a=map {$_} @{ $f-{foo} }
D:\perl -Mstrict -wle my $f = { }; for (@{ $f-{foo} }) {print}
RE: Class::FakeAttributes -- Opinions Wanted
Title: RE: Class::FakeAttributes -- Opinions Wanted
That's intended. I'll make this as clear as I can: My module is not
intended to be a general implementation for people who want inside-out
objects!
I cant help but observing that perhaps it should be. Kills your bird, and kills Aristotle's.
But thats just the obnoxious me talking. :-)
In general I find the interface rather ill thought out; of
course, if it did the job for you, hey presto.
But I'd prefer to do
for(@{$self-get_attr('foo')}){ ... } # A
rather than
for($self-attribute_list('foo')){ ... } # B
Believe it or not, so would I! Because, in a 'normal' class I'd just
write:
foreach (@{$self-{foo}}) { ... } # C
so merely using $self-get_attribute('foo') in place of
$self-{foo} would
seem like the most natural alternative. And that's what I did first.
The only flaw with that approach is that it doesn't work!
Thats because the apporach you are comparing it to is flawed.
foreach (@{$self-{foo}||[]}) { ... }
is the correct way to spell that I think.
If the 'foo' attribute hasn't been set to anything, then you want an
empty list to iterate over. With version C, that's what you get.
No. If $self-{foo} is undef you get an error with version C.
(There's equivalent reasoning behind the existence of
push_attribute().)
But in this case its unwarranted.
my $foo=undef;
push @$foo,Bar;
print @$foo\n;
I don't entirely like the fact that these different methods exist. An
alternative would be to have the constructor initialize all array refs
that might ever exist in an object to []. That way version A will
always work, because there's never an attempt to dereference undef.
Nah, just make the get_ autopopulate an undef attribute on fetch. That way its not done unless is actually being used by external code.
Now you've brought that up, it makes sense to add it to the
module docs:
if you make sure you always initialize your array attributes then
get_attribute() and set_attribute() are all you need; but if you don't
then make sure you use push_attribute() and attribute_list().
Personally I wouldnt have get_foo and set_foo. its too much like java or VB for me.
I prefer smart attributes that do the right thing. Of course its quibbles like this that are the cause the innumerable Class:: frameworks we have kicking around, and frankly why I almost never use them.
Well if nobody else joins in this thread then it looks like
the vote is
tied, 1 each way (assuming that I count my own opinion; perhaps I
shouldn't) ... which is a little awkward for being decisive!
Seems like you think its useful. Aristotle didnt tell you it was stupid. So I vote keep. Not sure if that brings it to a tie vote tho..
:-)
It isn't that I don't consider Y to be a valid problem to solve, nor
even that I'm against the existence of a module that solves Y. It's
just that it isn't this module.
As I said earlier, seems to me that maybe solving both problems with one module is the better way to go.
Yves
RE: Class::FakeAttributes -- Opinions Wanted
Title: RE: Class::FakeAttributes -- Opinions Wanted
I guess in the absence of Class::InsideOut, having
Class::OutOfBandAttributes as a band-aid isn't a bad idea.
(There's a lot of orders of magnitude less useful stuff out on
CPAN..)
Primary problem with creating a Class::InsideOut is the problem of where the hashes go.
If you dont mind using dynamics for them then you have no problem. If you want them in lexicals then I would say theres not much room to manoever, and in hind site implementing an inside out object/attribute is so easy (its pretty small, heres what I use for good general coverage:)
use Scalar::Util qw(refaddr);
{
my %attrib;
sub inside_out {
my $s=shift;
if (@_) {
$attrib{refaddr($s)}=shift;
return $s;
} else {
return $attrib{refaddr($s)};
}
}
}
The refaddr is useful because it allows for $s to have stringification overloaded.
Yves
RE: General format conversion module
Title: RE: General format conversion module I'm currently putting together a group of modules which would transform file data in one format to data in another format. It will use plugin modules to allow for custom configuration and automate the process. I can't really think of a really great name for this module. The best names I've been able to come up with are: Data::Transformation Data::Convert I don't know if Data:: is appropriate, since it normally refers to Perl data structures. Besides the main name, the module would include a number of plugins that would be under the primary namespace. Any suggestions? File::Munge? Yves
RE: [rfc] Module Naming issues
Title: RE: [rfc] Module Naming issues Shouldnt it be Net::MPlayer? Yves -Original Message- From: Marcus Thiesen [mailto:[EMAIL PROTECTED]] Sent: 07 October 2003 16:59 To: [EMAIL PROTECTED] Subject: [rfc] Module Naming issues Greetings Module Authors, I've written a module that uses MPlayers slave mode (http://www.mplayerhq.hu/DOCS/tech/slave.txt) to build (some kind of) Perl Bindings. It is mostly a fun module I've used to write my own webradio player in Perl. In the end it is only something that does an IPC::Open3 on MPlayer and maps the slave mode commands to Perl functions. It is currently named MPlayer.pm (which is quite idiomatic use MPlayer;) but I'm not sure if this is OK for CPAN (top level namespace) and follow up modules (if someone bothers to write real c bindings for perl, maybe MPlayer::Slave would be better). I thought it would be kind of polite if I ask before I release it. Suggestions? Opinions? Have fun, Marcus P.S.: it can be found here: http://www.thiesenweb.de/perl/MPlayer-0.02.tar.gz -- - |Marcus Thiesen ICQ# 108989768| |D-53757 Sankt Augustin [EMAIL PROTECTED]| |Germany| - | perl.thiesenweb.de | - 28A7 37CC AE2C BB6C D56D 8A3D E614 E56B 7546 75F2
RE: sub-packages for object-oriented modules
Title: RE: sub-packages for object-oriented modules Is this overloading of my own namespace the right way to go, or should I be using some more rigorous method? I imagine that the entire distribution could eventually be rather complicated, so I'd like to start down the path to robustness with this next revamp. I see no problem the approach you have described. Its not particularly common, but nor is it unusual. Carp for instance uses it, as do a few other commonly used modules. It sounds to me like you could also inheritance for this (forget about everything you've ever heard about doing 'OO' the right way. In perl there aint no such thing.). In this model each package essentially becomes a provider of services. Using multiple inheritance at a higher level you can mix and match which services you need at which level. A core aspect however is that they all probably need to descend from a base class which handles object construction. This way they function as stand alone methods or also as mix-ins. So long as the new constructor resolves to the same method irrespective of the inheritance heirarchy I dont see any reason not to do this. And again its not a particularly uncommon setup. For instance services provided by Exporter and Dynaloader are provided this way. Frankly the one route I would not go (already covered nicely in the list) is to use exporter . Ive gone that road before and its a PITA. :-) Yves
RE: sub-packages for object-oriented modules
Title: RE: sub-packages for object-oriented modules It's not so much a question of is it enough?, it's more is it useful?. Mixin classes are useful in a situation when you have several different classes which share a set of methods but do not inherit from a common ancestor. IMO Mixins are just as useful when they do inherit from a common ancestor. :-) Yves
RE: RFC: SQL::ExportDB
Title: RE: RFC: SQL::ExportDB One last comment: if you want to make this a generically useful module, and unless your configuration is so complex that it needs a dedicate language to express it, then the module should instead just take a Perl datastructure. By that time what would be the difference between this and MLDBM? Yves
RE: RFC: SQL::ExportDB
Title: RE: RFC: SQL::ExportDB * Orton, Yves [EMAIL PROTECTED] [2003-09-24 10:55]: One last comment: if you want to make this a generically useful module, and unless your configuration is so complex that it needs a dedicate language to express it, then the module should instead just take a Perl datastructure. By that time what would be the difference between this and MLDBM? Hum? The fact that it builds a hash structure in a configurable way from a batch of DBI queries? Ie, the actual point of the module? Er, ok, maybe I misinterpreted take a perl datastructure. Yves
RE: :Index and podindex released
Title: RE: :Index and podindex released * Orton, Yves [EMAIL PROTECTED] [2003-09-22 15:35]: Actually id like to be able to pass it a hash of known files in the following format: But that restricts you to filtering by known criteria. Using a callback would allow to filter by any criteria anyone might every desire. The hash interface could be offered as an option, but a callback interface should definitely be in there. The former could easily be implemented in terms of the latter.. I agree with you that the callback mechanism would be good. I suppose the primary reason I would prefer to see at the hash lookup as well isnt that good a one (although its arguable ;-) ie, premature optimization. Id love to have a look if you feel like sending it over. It is a construction site at best, currently; a third of the code is built for the Pod::Tree::HTML-specific link mapping mechanism and will need changing after dropping that module. Not to mention I haven't ultimately decided what converter I'm switching to, yet, although I'm almost sold on Pod::Simple at this point. My main hold-up is customizing whichever HTML converter I end up with. The actual crawler/updater already works fine. Id love to have a look at some point. If you can't laugh at yourself, you don't take life seriously enough. Well said. That describes my day to a T. :-) Yves
RE: RFC Format::FileSize
Title: RE: RFC Format::FileSize Does this make sense or does this already exist and I have missed it? Is Format::FileSize a proper name? Do a search for units on search.cpan.org and i think youll find this somewhere. And no I dont think the name is that great. But im not going to stick my neck out with something better cause im not talented that way either. :-) Yves
