Re: spamming cpan? was [Fwd: Perl-Freelancer needed]
David Golden wrote: Corion contacted them (see http://use.perl.org/~Corion/journal/31223 http://use.perl.org/%7ECorion/journal/31223 ): I got some spam by a German company (Online Microsystems) seeking a freelancer today. I gave them a call and educated them about jobs.perl.org http://jobs.perl.org/, which they actually were really happy to learn about. Perhaps the CPAN home page FAQ etc section needs a link to jobs.perl.org http://jobs.perl.org? And while you're at it, how about a link to some kind of software development management clue. I really feel for the probably talented but naïve programmer who doesn't realise this line from the spam is a recipe for disaster: If you are interested in doing the job, please quote us a lump-sum for this package. Sam.
Re: Give up your modules!
Ken Williams wrote: That said, there ought to be a way for the community to move forward without having the original author be the bottleneck. With open-source licenses, there's explicitly a way for someone else in the community to pick up the reins and release a derivative of the original code without seeking the permission of the original author: JFDI. Change the namespace if you must. People will cope, it's better than having no new release at all. You do not even need to change the namespace; if people would like to show that they are ready to take over a module, there is nothing to stop them proving themselves by just uploading the it to CPAN. They won't get indexed (or, in turn, downloaded automatically by the CPAN shell), but they will still be carried by the CPAN network, and show up on search.cpan.org. Then, all you need is a suitably convincing petition of users to have the namespace handed over, or have the original author approve the hand-over. IOW Show me the code :) With Perl 6, and once the core cpan network and installation modules support this adequately, you even have a workaround; just tell your users to write; use Crypt::Rijndael-(Any)-SCHNEIER; There will be much more on this topic in the cpan6 announcement talk at YAPC::Eu in Birmingham. Sam.
Re: Test-time dependencies.
Johan Vromans wrote: Ken Williams [EMAIL PROTECTED] writes: My intention when I added 'build_requires' to Module::Build was not to let people avoid downloading building those dependencies, but rather to indicate that there was no runtime dependency, ... For this to function properly, the 'build_requires' modules (and their respecitve dependencies!) should all be downloaded and installed in a temporary location (e.g., blib) and not be installed permanently. This is what Module::Install does when you use 'auto_include'. What I've done for recent modules is to bundle Test::Depends by making it the only build_requires line. Then, from the test scripts I can just; use Test::Depends qw(Some::Module), Other::Module = [ @import_args ]; Of course it means that the test suite doesn't get run fully, but I think the output makes that obvious enough. Sam.
Re: A Semi-Public Version Control Repository for Your CPAN Modules
Shlomi Fish wrote: Another option is to just upload the distribution with your changes using your own PAUSE ID to cpan. It will not get indexed, but succeeds in that users who don't know about or trust some external repository can still access your changes via the CPAN network. I really don't want to do that, because it's not a real solution. This mailing list, modules@perl.org and other forums are inundated with such requests for gaining maintainership of authors who disappeared. Now Damian did not disappear - he's still alive and kicking - he just doesn't have the time to apply all patches or fix all bugs. I'm not sure why you say it is not real - would you care to elaborate the failings in this working solution that you see? I've come across authors who have thanked me for doing a release for them, and it means that the *users* of the modules don't have to wait for the upstream author to do a release if they want to get the modified version. Sometimes it's just the simplest and most effective way to publish the changes. Once a FOSS project becomes popular and the author becomes busy, then having only one person able to commit changes to such a project, scales less and less. That's what version control and multiple commiters (or alternatively or complementarily distributed version control) is for. I could release a module I have changed for with patch A, and then patch B, and then patch C, etc. I've already done it with http://www.shlomifish.org/open-source/bits-and-bobs/gringotts-patch/ which is written in C. However, I'd rather take advantage of Audrey Tang's and Adam Kennedy's lead and simply commit changes directly to their version control system so they'll eventually be available upstream. A lot of what you say is true, but we should be extremely careful not to enforce or specifically condone any particular style of development. Some prefer the wiki-style/open commit approach and hence use SVN as a robust filesystem for this, others prefer that changes are reviewed first and probably use a distributed system like bazaar, git, darcs, etc, for a cleaner concept of branches. Consider how this works with savannah.gnu.org. If you have a patch to a software package that implements a particular feature, you can just upload it to the system. It is then available for all users, not just the maintainer. Later, the maintainer can mark the patch as included in a release, and the patch gets marked done. Making it easy for these changes to be available to a given user is just a matter of installation tool sophistication. However, if you just commit on an SVN trunk, your trunk becomes a ghetto of features which may or may not work. Some relish in delight at the prospect of grokking these new ideas from people, and the success of pugs is testament to the energy of people like Audrey who actively engage in this process. But if the maintainer doesn't do that for all their modules all the time, the ghetto ends up needing much clean-up before release, possibly involving a painful process of branching and cherry picking, which is always painful with svn. I think the point is that it is not valid to imply that a module author is not fulfilling their moral duty because they do not embrace the wiki model and want to adopt your changes. There are plenty of options - set up your own VCS, upload to CPAN independently, post a patch to the module's users' mailing list, etc. The reason I recommended uploading to CPAN, is because as CPAN to VCS bridges emerge, your new version will fit in tidily as a separate branch. Assuming the author uses this bridge they can then just merge, then commit back via the bridge to CPAN. Well cpan6 aside, I've thought about an idea for Park ( http://www.shlomifish.org/park-lisp-fooware/park-lisp-informal-spec/ ) which I have yet to put in writing in the slowly-progressing informal spec, but it's doable for other languages too: What happens is that everyone can register a vendor tag in CPAN, which is an alphanumeric name. He can also make other people co-maintainers of this vendor tag. Then new versions of modules of an existing author can be released under a vendor tag that they belong to. And the user can specify to install modules that belong to a certain vendor tag. (e.g: install --vendor=ShlomiFish Parse::RecDescent). This is actually required for Perl 6, to be able to specify a vendor. eg, `use Parse::RecDescent-(Any)-cpan:SHLOMI'. The vendor tag is just your PAUSE ID, or perhaps a cpan6 archive URL. It is expected that this functionality will eventually be retrofitted into Perl 5 via CPAN6.pm. Naturally, it introduces some problems, and probably not a perfect solution but worth thinking of. Note that I hope to see some of the non-Perl6-related improvements to Perl6 back-ported to CPAN (or to CPAN 2.0 - ;-)). Another improvement I thought is a list of secondary sources, each one with
Re: CPAN6
Leon Brocard wrote: Of course not - but in the usual Perl way, if you don't like it, you can build your own cpan6! And release it to, errr, CPAN. But as with most Perl 6 projects, I have to ask: Why do we have to wait for Perl 6 before we get a better CPAN? We don't, we're building it using Moose :-). You're waiting on good old fashioned hubris. Or is this getting too meta and should I wait until your yapc talk instead... Leon Yes, come to the talk, it's 98% meta free and no added Schema. Sam.
Re: A Semi-Public Version Control Repository for Your CPAN Modules
Shlomi Fish wrote: Now, Adam Kennedy recently made an interesting step of making commit access to a Subversion repository with the source code for most of his modules to anyone with a valid PAUSE login: http://use.perl.org/~Alias/journal/29327 My suggestion is for you to do something similar. What do you think? Is there any reason for you not to do so? Shlomi, Another option is to just upload the distribution with your changes using your own PAUSE ID to cpan. It will not get indexed, but succeeds in that users who don't know about or trust some external repository can still access your changes via the CPAN network. If you are in Europe in August, you might like to come to YAPC and see the announcement of cpan6, this concern is included in the design requirements and making small changes to other's code will be natural and safe. http://www.birmingham2006.com/cgi-bin/yapc.pl?act=talk-itemtalkid=51 Sam.
Re: I think we can just scrap CPAN Ratings altogether
A. Pagaltzis wrote: * Adam Kennedy [2006-05-23 11:10:13] Data-Pageset (1.03) — 1 star: This is reciprocal karma for the author one-starring a competing module and advertising his own. Bad form. (not a commentary on how this works) This sort of thing is lunacy. What’s the point of MODULE REVIEWS if they’re going to be turned into crusade vehicles? Can't we just move the site to cpanrantings.org? That's the spelling I've always used :-) Sam.
Re: Module abstract: Is its length still limited?
On Mon, 2005-11-07 at 21:08 -0500, Ricardo SIGNES wrote: * Andreas J. Koenig [EMAIL PROTECTED] [2005-11-07T17:29:50] I will be very happy if you guys decide something and let me know. I'll adjust the code for the forms on PAUSE then. Here's my official vote: (length $module_name + length $abstract + 3) should be under 80. This means that the whole header and abstract will fit in one line. That's more than 44 characters for short module names. Longer module names, which should be pretty descriptive, need shorter abstracts. Wombat - a framework for building reusable fruit-counting applications Application::Framework::FruitCounting - for reusable produce applications My feeling is that this wouldn't really work when the module name gets too long, for example when a namespace under which you are contributing has chosen verbose terms. For keeping your source code at 80 characters wide, it should be perfectly legal to wrap that line in the source; it's not a verbatim block so all Pod parsers SHOULD see it as a flowed paragraph. Whether or not this is true for all relevant parsers is another story. Personally I'd call it a bug if they don't follow the POD rules, though. I also feel that the total length of those two is somewhat irrelevant for its intended use - for instance, if you are browsing modules on search.cpan.org, the module names and abstracts are both flush left. Tabular format works better like that. I think the key question is more along the lines of, how much text do you want to see while you are reading the abstract for a whole bunch of modules? What length is about right? I suggested 60 because it's just a *little* bit longer, to allow for better word choices here and there, but still too short for rambling. Perhaps 80 is fine, too. I had a read through the modules by the authors listed in the other e-mail, AUTRIJUS, BDFOY, and DCONWAY, and I couldn't really see any obviously overly squeezed abstracts. Except perhaps QM for Quantum Mechanical. Can anyone find any examples of abstracts that they think are inadequate due to size restrictions? Sam.
Re: Module abstract: Is its length still limited?
On Sun, 2005-11-06 at 07:51 +0100, Andreas J. Koenig wrote: So, the question I would now ask: How rigidly should I enforce the 44-character limit if I am guiding someone in the task of creating proper Perl modules? As the module list is dead, we cannot really argue in favor of 44 characters except with the one argument of tradition/best practice. I believe when 3815 authos have managed to describe their modules in 44 characters, then it should be doable for some other 3815000 modules too. Yes, let's keep it short. But how about increasing the limit to 60 or so? Many a time I would've liked an extra word or two. There's an old business advice that you shouldn't start an enterprize if you cannot describe its mission in a single sentence. I think its true for modules too. There are very few sentences that fit in 44 characters. 60 characters I think still honours this principle. Sam.
Re: Name advice: check license of dependencies
On Mon, 2005-10-31 at 11:20 -0500, Mark Stosberg wrote: I don't like any of the names I've come up with so far. It seems clear that it should be in the Module:: namespace, but beyond that I'm unsure. Possibilities: Module::GuessLicense Module::License Module::LicenseChain Module::DistributionRights From your description, this is much as about a module's dependencies as it as a about a specific module. So I'll suggest: Module::Depends::LicenseReport Including Report signifies that the module has a read-only purpose. On the other hand, a license might be seen to implicitly imply dependency on all of the things that it depends on (esp. if any are GPL). I think your point is very valid, and perhaps the logic for figuring a module's dependencies recursively should be available independently from the logic to show the license for an individual module. So, perhaps Module::Depends and Module::License Module::License::(Report|Chain|...) Sam.
Re: Tests needing user parameters
On Wed, 2005-10-19 at 21:51 +0100, Jess Robinson wrote: Hey folks, I'm writing a module which will need user account data for it's tests, and I'm wondering if theres a standard way (or module) for doing this.. Else I'll guess I'll look for environment variables and otherwise not test, any ideas? Look at the Tangram test suite in 2.08_05; it asks for information about where to find a database to connect for tests, saves the information to a state file in t/. It also correctly handles the situation where no information is given, by altering the test manifest. It doesn't use ExtUtils::MakeMaker::prompt, though arguably it should. Sam.
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Orton, Yves wrote:
Imo it would better to expose a different subroutine name for this.
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Is that ruled out for some reason?
If you consider the signature a part of the subroutine name, then
simply making it take an arrayref as the first argument is enough
to distinguish it.
in Perl 6 you could say
multi sub GetOptions(Array @ARGV, Pair [EMAIL PROTECTED]) { ... }
is a different subroutine to
multi sub GetOptions(Pair [EMAIL PROTECTED]) { ... }
If passing an array ref first doesn't interfere with the calling
convention, then imho you don't need to change the function name.
But that, of course, is a matter of style ;-)
Sam.
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Johan Vromans wrote: You mean, you are going to pass things like STDOUT, STDERR, ENV and so on, to every function that may use them? [1] Global things are intended to be global, I'd say. This is why code using CGI.pm is so hard to wrap, too. Assumptions that globals will always be globals. Then you go and try and do anything vaguely re-entrant and it all falls to pieces. Sam.
Re: RFC: Getopt::Modern
Johan Vromans wrote: I have several tools that take different syntax on the command line, specific for the task. For example, subcommands: mycmd init db=$HOME/mydb mycmd load db=$HOME/mydb data1 mycmd load --trace db=$HOME/mydb data1 mycmd --trace load db=$HOME/mydb data1 Yes; I've wanted to do this before, and commands like svn, svk, etc are good examples of this... I've jumped through all sorts of hoops before cordinating getting this right from the command line and config files at once... However I must admit I found Getopt::Long provided me with the API I needed to do the command line parsing part easily and flexibly enough. Sam.
Re: IO::ALL (Was: check for errors on close())
Smylers wrote: I've only just begun to reap the benefits of it. After how long of using it? Does that mean that initially you found it more hassle? No, not at all. I've just only found myself using it twice so far. However, when I did I found it deliciously DWIMmy and extremely handy. eg, in http://svn.kwiki.org/ingy/Perldoc/lib/Perldoc/MugReader.pm I use it to accept a filehandle, string, filename, etc - whilst still being able to treat them all as if they were files, as well as knowing that now my module can accept URIs too! Now, it seems that the built-in ways of doing these things are just too awkward. That strengthens my feeling that Ingy is on to something with his shorter syntax, and that Perl 6 should benefit from many of his ideas. So come on over to p6l! :) Or, actually it's probably better to join in the pugs crowd and contribute an update to S29 based on IO::All and Path::Class. Perhaps there is even enough in Pugs to be able to start a basic implementation? At least the non-OO interface, anyway. Sam.
Re: check for errors on close()
Eric Wilhelm wrote: Just spent way too much time trying to find a bug when it turns out that I just had a full disk. So, food for thought for today: close() does not always return true. close(FILE) or die file error: $!; In the disk-full case, open() succeeds (if there are still inodes available), but close fails because the buffers cannot be flushed. You don't already check the return value of every system call? Too tedious? Just use IO::All. Sam.
Re: Win32::TieRegistry or Perl problem (?)]
Ken Williams wrote: On Mar 2, 2005, at 5:53 PM, Linda W wrote: I'm not sure what perl does with invalid character data in a variable when you try to manipulate it by appending it to another value. There's no such thing as invalid character data in Perl strings. Perl strings can contain arbitrary binary data. Sure, in the C locale. Outside of that, all bets are off. You could quite easily have arbitrary binary data in a Perl scalar that isn't valid character data in UTF-8, for instance. Sam.
Re: Net::Ftp use proxy et al...
Linda W wrote: Might it not be useful if Net::FTP could use an ftp_proxy, transparently, if one was set in the environment? Net::FTP couldn't provide its entire API if proxied; after all, the proxy is pretty-printing the directories into HTML so they look nice in a browser. Just ask the authors of NcFTP why they don't support HTTP proxies :). Note that LWP::UserAgent can fetch FTP URLs transparently using whatever environment proxies are defined, if any. If you're using an FTP server as if it were an HTTP server, it makes sense to use an HTTP interface. Than again, maybe the author will disagree with me and add the feature, who knows :). Unlike most people in the linux world, I don't think the concept of a single per-user/per system registry would be a bad thing if done right -- all the little config files/rc files sitting around on volumes with large allocation block sizes and wasting a large amount of filespace... If done right, could make moving setups between systems easier... You'll hurt your head thinking about that for too long. The technical inefficiency really isn't the issue at all, and in fact if you're on a real OS then it isn't even inefficient. UNIX does have a registry. It's called /etc and ~/.*, the problem is that after 30+ years of text file config formats, we've decided we still love text files but we don't like the differences in their format. If you want to ease the standardisation of these things then just use YAML for your next config format, and be done with it. If YAML were to become best practice for a configuration file format, you could present them with an API that looked like a registry anyway. The idiosynchronacies would still be there but the solutions should proliferate. Such a change will take a long time to get right, I think most people will agree that many of the benefits arising from a convention regarding making configuration files homogenous in a way that is almost, but not entirely, quite unlike a registry is probably worth it in the long run - but it will be a slow, slow process. Maybe if you write a nice generic cross-platform GUI YAML config editor for YAML dotfiles that applications can provide custom extension dialogs for, then you will have something control-panel like for conforming applications. The idea is that it's trivial for application authors to supply the information used to build the GUIs, and possibly even plug their own components in. Actually, such an idea would naturally need to have alternate UI support, a bit like Debconf I guess - but be warned, and people who call this flamebait can be damned - Joey Hess' code is not to be taken as a good example for style. Seeing main loops like this; 1 while $debconf-communicate(); Make me want to shoot the author on grounds of inapproprate public displays of self-affection. Besides, debconf is combined in unholy matrimony with the system packager, and focuses on a different set of goals. And whatever you do, don't call it a registry, you'll hit a sore spot on lots of people ;) -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Tree::Meta
Eric Wilhelm wrote: associative arrays. This module uses tied associative arrays and some conventions to represent ordered trees where each node of the tree has both contents (deeper nodes) and properties (things about the node.) It's not exactly homogeneous (like an n-ary tree) because it uses a file/directory concept (a directory contains more nodes (a recursive version of the same data-structure), but a file only contains flat data (as arrays.)) Something like a Directed Acyclic Graph? (see Tree::DAG_Node) Mapping a DAG to native types using magic rather than objects for the extra information is an interesting idea. How about Tie::DAG? or Tie::DAG::Meta/Tree::DAGMeta ... -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Class::Validating - naming suggestions
module-authors@perl.org wrote: Perhaps it should be named Params::Validate::Derivable or something along those lines. I agree, but given that being derivable is something really important for being able to be called OOP, why not: Params::Validate::OO - Derivable parameter validation -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Module naming advice
David Wheeler wrote: I agree that it should be lowercased; yes, there are modules on CPAN that look like pragmas (such as only). I personally would prefer, however, that the name tell me that it's doing something more than loading a class; class and module don't do that. However, this code reads very well: use module 'Foo::Bar' as 'Bar'; use package 'Foo::Bar' as 'Bar'; And this does not read as well (at least, in English): use aka 'Foo::Bar' as 'Bar'; My suggestion; use aliasing to 'Bar', 'Foo::Bar'; With the upside that aliasing also clearly states what the module does. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
cross-posted FAQ question [was: Win98 - DBD-Oracle install issue]
John Berry wrote: I am trying to install DBD-Oracle-1.16 along with DBI-1.46 DBI was installed successfully, but got errors intalling the DBD-Oracle-1.16. John, Two things. Firstly, you cross-posted this message to two mailing lists, one of which has no interest in this problem. This is bad netiquette. Secondly, you have failed to check the mailing list archives to see if this problem has come up before. You are the third person to ask a question like this in the dbi-users list this week. Please, check the dbi-users mailing list archives, and try to be more careful with the recipient lists on e-mails you send. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: DBIx::DBH - Perl extension for simplifying database connectio ns
Orton, Yves wrote: DBD::Ingres does something similar. DBD::Oracle appears to be closer to Sybase/MySQl: dbi:Oracle:host=myhost.com;sid=ORCL Normally you don't bother with connection parameters with Oracle at all: DBI-connect(dbi:Oracle:, database, password); Instead, you configure which logical Oracle installation that you want with an environment variable. The information about where that database actually lives is in a config file in the Oracle client installation. So, if you actually override the environment variable by specifying the SID in the program, you run the risk of confusing the poor SysAdmins who look after it, as every other program honours this convention. 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. Not necessarily. There might be an ORB or some other name service locator that finds those details out at run time given something that isn't a host name. I think that this information should be removed from most programs altogether. They should just have to specify a logical data source (possibly including a schema version), then a module with a config file maps that to a set of connection parameters. ie, if we're going to go ahead and try to make some sense of how you specify the parameters to the DBI connect call, why don't we go the whole way and think about where that connection information is coming from? -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Suite of modules to be released - the name game
John Siracusa wrote: There are a few things that make this difficult. The first is that any OO helper module depends on the object base class and method maker. The second is that the object base class and method maker are very simple, and hardly worth distributing separately. If they are very simple, why not use an existing module? What functionality do they add, why could it not be added to another accessor module? If it is because the others were too simple, could they have been split to load extra functionality on demand? You shouldn't answer these questions on this list btw. But they should help you decide whether to rip them out, or release them seperately. The third is that even the functional helper classes are very simple, and usually only exist so that I have a single point of access for some functionality within my suite. I suggest that you release them under the namespace of your own for now. However, over the next few years, you should actively try to move portions over to more functional namespaces and incorporate the functionality into other modules. This is a particularly more serious state of affairs for the database side of things; database libraries have more traps and pitfalls than you may be aware of, and the bugs in that space are usually the hardest to debug and have the worst impact! You should definitely ask on the POOP-group list about which existing DB library is most similar to your new approach. When you add a single method to a prepackaged module, could it be that the module could be enhanced with the feature? Try sending a patch to the author. Is your assessment of whether it fits in with the module you are using correct? Check with the community, maybe they have an approach that works in the way you want. Are you replicating the API of another module, with a competing implementation? That module should be released as Foo::Lite (if it is actually `Lite'r) or otherwise under the namespace of the original module. Once the great ideas and fresh approaches that you have discovered with your efforts are incorporated into other modules, or had new modules made from the ones that really are new and different, the originals can be deprecated and laid to rest. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Which namespace for a build system?
A. Pagaltzis wrote: The question I'd ask is, is there established Computer Science terminology for the problem a dependency solver addresses? That probably requires determining what kind of field the problem falls into. I have a hunch that that would be AI. How about a Dependancy Algorithm ? :-) http://search.cpan.org/dist/Algorithm-Dependency/ -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: namespace for users and groups
David R. Baird wrote: I think the treeness is quite important, because groups inherit the capabilities/permissions of their subgroups. So whenever you check if your own group is permitted to do something, you know that the tree- like hierarchy of groups contained within your group is also being checked. Group, by itself, infers no such treeness. You may have chosen to model your groups and users by some close analogue of; +-+ +-+ ++ | GrantableEntity |--| Grant |--| Entity | +++ 1 * +-+ * 1 ++ /_\ | +---+ +-++ | | * | | |* +-+ * * ++ +--| Group |-| User | +-+ ++ Unix Groups, for instance, do not bother with this, so Group doesn't mean Heirarchy of Groups in this case. The problem with these such discussions is that such a wide variety of possible ACL structures are all used and called ACLs - though each can have a different arrangement of explicit or implied inheritance between security objects, and multiplicity of each relationship. So, they have different properties, which is easy to see when they are expressed in UML, as above. Some people even try to express one particular concrete form or describe a design-specific property, and call that structure the definition of the term. In the end, as long as there is a virtual concept of controlling access, it can be called an ACL. You could call Unix Groups an ACL mechanism, and it would not be incorrect. UML is an excellent language with which to express the exact nature of the ACL that your module implements. _*The Art of Objects: Object-Oriented Design and Architecture_, by *Yun-Tung Lau http://www.amazon.com/exec/obidos/search-handle-url/index=booksfield-author=Yun-Tung%20Lau/102-5857950-6496945 (isbn://0201711613/) uses ACL design as one of its worked examples. Highly recommended. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: script local namespacing?
Eric Wilhelm wrote: Just use ProgramName:: The assumption here is that you won't be distributing the modules on CPAN and that your program/project is going to have a unique name. It's been suggested before on this list, and I agree with it. What about the potential conflicts caused by takeovers and mergers? Maybe we should follow Java's lead com::yourcompany::Perl::script::CLI::Util::ProgramName Sam. Would you like fries with your flamebait, Sir?
The CPAN Guide [was Re: Future of the Module List]
Mark Stosberg wrote: Maybe the convention could be: Review::Text::Balanced::CPANUSERNAME Good idea, but I think that is duplicated information. CPAN already considers the uploaded user ID to be a part of the unique name of the module. Two authors can upload a module with the same name; and that is fine; they will both be displayed uniquely when found on search.cpan.org. Of course, when installing via CPAN.pm, the indexer will only automatically choose the versions of the modules written by the current maintainer (or some rule like that). For reviews, this is not really a major consideration - except maybe for people compiling CPAN discset compilations. OTOH, a link to http://search.cpan.org/dist/Some-Dist/ will go to whichever has the highest version number (see http://search.cpan.org/dist/Data-Lazy/ for an example). Perfect. Rather than trying to double the size of CPAN by making a review for each module, a review could cover a wide variety of different modules that cover a related problem space. The reviews could be supplemented with examples and demonstrations exhibiting strengths and weaknesses of the modules that they review - for instance, benchmarking, memory tests, etc. As new modules are written, the reviews could be extended (perhaps, but not necessarily by the same author as the original review). You will get a similar situation to many of the modules in CPAN today, which have more than a handful of maintainers who have contributed. There's nothing to say that individual module reviews shouldn't be written, and the convention of naming the review module the same as the single module it covers with a prefix is a good one. This would almost certainly be linked to by the module which covers the generic problem space. So, to make this distinction clear, maybe the Guide::* namespace should cover problem space reviews, and serve as something of another index to CPAN - and Review::* can be for more in-depth reviews of individual CPAN modules, to avoid potentional conflicts from using Review::* for both of these. Besides, I think Guide:: is more accurate here. If no-one has any sound objections or beats me to the task, I will endeavour to complete Guide.pod, and Guide/Example.pod during my recreational Perl development time (not as abundant at present as it once was ;-)), and construct a skeleton of Guide:: distributions based on the old modules list. But first, back to reinventing some more wheels ;-). -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: not-so-plain documentation
A. Pagaltzis wrote: * Eric Wilhelm [EMAIL PROTECTED] [2004-06-25 05:11]: I've seen pod2usage() and this would work, but most of these scripts have some defaults set for variables that can be changed with the GetOptions flags and I'd like to show these defaults at least in the help message. You are looking for Pod::Constants. Or even Scriptalicious... http://search.cpan.org/dist/Scriptalicious/ -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Module meta data
khemir nadim wrote: Hi, could someone, please, tell me how some modules get meta data like module is a devloper release and the DLSIP definitions so I can get some of my modules listed on search.cpan.org. All this information must be right in front of me but it seems I have a temporary doc blindness. I'm also curious about how many made the move to Module::Build. For developer releases, include an underscore in the version number. Eg $VERSION = 2.07_04; The version will be indexed and displayed on CPAN as the head release, but will not automatically trash systems via CPAN.pm. Kudos to whoever put this feature into CPAN btw. For the meta information, upgrade to a new ExtUtils::ModuleMaker. I've used Module::Build in a few modules that I've released. It's smashing, once you've got shell aliases for perl Build test verbose=1, etc (`make test' was SO much quicker to type ;-)). It introduces another dependancy, but IMHO it's well worth it for dropping the dependancy on a local Makefile guru. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Application framework namespaces
Lincoln A. Baxter wrote: Does it make sense to create a new generic TLNS into which one might hope to eventually see all such Frameworks migrated, or, should we just go for our own new TLNS? Sorry if I'm flogging a dead horse, but IMHO just pick a name, and make sure that you include a good introduction that weighs up the pros and cons of your module / system / framework versus all the others that you reviewed on your main POD file. Having LModule::Name style links in the intro will assist a person looking at the module to zip around the differing modules to perform a particular task. It was said before, but I'll repeat it - seperating out the logical components of the framework into seperate distributions (and perhaps releasing a Bundle:: to get the lot) would be well worthwhile. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: PerlHack - Adding new flag into a SV
No, weakrefs cast backref magic onto their target to avoid this
problem. When the reference count drops to zero the magic ensures that
the weakref is set to undef.
See Perl_sv_rvweaken() in sv.c for more.
Sam.
Orton, Yves wrote:
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?
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
--
Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
Re: New module: Scriptalicious
Thanks all for your feedback. I have added a SEE ALSO section that includes the feedback from this list and released version 1.01. It now also accepts a program version to be passed in the normal way (ie, in $main::VERSION). -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
New module: Scriptalicious
with the text warning:. The program does not exit. run(command, arg1, arg2) Runs a command or closure, barf's with a relevant error message if there is a problem. Program output is suppressed unless running in verbose mode. run_err(command, arg2, arg1) Same as run, but returns the error code rather than assuming that the command will successfully complete. Again, output it sup- pressed. capture(command, 1gra, 2gra) runs a command, capturing its output, barfs if there is a problem. Returns the output of the command as a list. capture_err(command, foo) Works as capture, but the first returned item is the error code of the command ($?) rather than the first line of its output. Usage: my ($rc, @output) = capture_err(somecommand, @args); AUTHOR Sam Vilain, [EMAIL PROTECTED] -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: defining 'constants' at run time
On Fri, 05 Mar 2004 00:05, Simon Cozens wrote; However, if the programmer doesn't bother to explain what that reason is, it's natural to assume that he's just being weird. Q: What's the difference between an object methodologist and a terrorist? A: You can negotiate with the terrorist. :) -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) Only presidents, editors and people with tapeworms have the right to use the editorial we MARK TWAIN
Reshaping the modules list: the current situation
2) Perl Core Modules, Perl Language Extensions and Documentation Tools (CORE, DynaLoader, etc) * Perl Pragmatic Modules (constant, integer, strict et al) * [C] Experimental pragmatic modules live in the ex:: namespace * Perl Language Extensions (everything from Safe to Attribute::Handlers to Inline to Exporter::Import) * The Perl Compiler (B, O, B::Graph, etc) * Source Code Filters * Thread support * Module Support * Documentation Tools 3) Development Support 4) Operating System Interfaces, Hardware Drivers * Platform Specific Modules * Portable Digital Assistants * Hardware related modules 5) Networking, Device Control (modems) and InterProcess Communication 6) Data Types and Data Type Utilities * Data Type Marshaling (converting to/from strings) and Persistent Storage 7) Database Interfaces * DBIx -- Extensions to the DBI * Tied Hash File Interfaces 8) User Interfaces * Major Character User Interface Modules * Tk X Windows User Interface Modules * Modules in the realm of Tk but with a separate namespace * Other Major X Windows User Interface Modules * Abstract Graphical User Interfaces modules 9) Interfaces to or Emulations of Other Programming Languages 10) File Names, File Systems and File Locking (see also File Handles) 11) String Processing, Language Text Processing, Parsing and Searching * Language text related modules * Other Text:: modules (these should be under String:: but pre-date it) * Stemming algorithms * Natural Languages * Specific Natural Languages 12) Option, Argument, Parameter and Configuration File Processing 13) Internationalization and Locale 14) Authentication, Security and Encryption 15) World Wide Web, HTML, HTTP, CGI, MIME * Apache PerlHandler modules * Apache PerlInitHandler modules * Apache PerlAuthenHandler modules * Apache PerlAuthzHandler modules * Apache PerlAccessHandler modules * Apache PerlTypeHandler modules * Apache PerlTransHandler modules (May also include a PerlHandler) * Apache PerlFixupHandler modules * Apache PerlLogHandler modules * Apache PerlChildInitHandler modules * Apache Server Configuration * Apache Database modules * Interfaces and integration with Apache C structures and modules * HTTP Method handler * Watchdog and Monitoring tools * Development and Debug tools * Miscellaneous Apache modules 16) Server and Daemon Utilities 17) Archiving, Compression and Conversion 18) Images, Pixmap and Bitmap Manipulation, Drawing and Graphing 19) Mail and Usenet News 20) Control Flow Utilities (callbacks and exceptions etc) 21) File Handle, Directory Handle and Input/Output Stream Utilities 22) Microsoft Windows Modules 23) Miscellaneous Modules 24) Interface Modules to Commercial Software 25) Bundles -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) A pipe gives a wise man time to think and a fool something to stick in his mouth. - anon.
Reshaping the modules list: a starting point, help remove the bias.
Hi all, I've performed an initial re-work of the modules list. Please look over the sections of the list that you are most in touch with and provide feedback. This is a brainstorming phase only; please provide suggestions and not *just* negative criticism (both is OK, but please be constructive). Preferably in the form of the section as a YAML compliant data structure, as the below is. I'll be going through the chunks and modifications that people suggest and collating it into a single list and republishing as time permits. Hopefully it's fairly obvious what I've done with the different sections of the old list. There are fewer top level categories, but more sub-categories - and the possibility of sub-sub-categories. Some sections I'm not so in touch with, or wasn't feeling particularly inspired about at the time, that I've left alone. After this stage, I'll try and fit the modules from the existing lists and the Phalanx project into it one by one, and see how I get on. Core Perl language modules and extensions: - internal packages - language mutations - Perl 6-like features Code development and documentation tools: - Editor extensions - Test suite systems - POD processing - POD for more than just API docs - Control Flow Utilities (callbacks and exceptions etc) Pure data and structures: - Pure algorithm implementations (c.f. C++ STL) - Class generator frameworks - Parameter parsing modules - Data Schema modules - tree-based (eg XMLSchema) - Data Schema modules - general (eg YAML::Schema) - Code modelers and CASE tool plug-ins String and Text Processing: - Parsing modules - Indexing modules - Searching modules - Natural Language Text Processing - Internationalisation and Localisation Databases, marshalling and persistence: - persistent hashes - structured data marshalling - SQL abstraction frameworks - Object Databases - Object/Relational mappers hybrids - Prevayler-style storage (antidatabases) Networking - raw communication, including IPC: - Shared memory solutions - Pipes - Sockets - Datagrams - Object Request Broker mechanisms Networking - protocol implementations: - RFC based - other standards based Networking - accessing services: - Mail and Usenet News - XML services - YAML-RPC services Networking - providing services: - Server and Daemon Utilities - Web Services Frameworks: - Apache: - Apache PerlHandler modules - Apache PerlInitHandler modules - Apache PerlAuthenHandler modules - Apache PerlAuthzHandler modules - Apache PerlAccessHandler modules - Apache PerlTypeHandler modules - Apache PerlTransHandler modules (May also include a PerlHandler) - Apache PerlFixupHandler modules - Apache PerlLogHandler modules - Apache PerlChildInitHandler modules - Apache Server Configuration - Apache Database modules - Interfaces and integration with Apache C structures and modules - HTTP Method handler - OpenFrame - etc, submissions welcome :) - Web Services Components: - Lots of the Apache sections from above could be moved here - Authentication, Security and Encryption: - Authentication Systems - Encryption algorithm implementations - Security interfaces Networking - administering services: - Watchdog and Monitoring tools - Development and Debug tools - Miscellaneous Apache modules User Interfaces: - Command line interfaces - Configuration files - Interactive character and terminal based UIs - Tk toolkit - Gtk toolkit - WxWindows toolkit - other graphical toolkits Imaging, Images, Multimedia: - Sound manipulation - Image Conversion - Raster Image Manipulation - Vector Image Manipulation - Drawing and Graphing utilities Interfaces to and emulations of other languages: - The XS C interface - XS alternatives - C, C++ - Java - JavaScript / JScript / ECMAScript - ... Platform interface: - File Names - File Handle, Directory Handle and Input/Output Stream Utilities - File Systems interfaces - File Locking - File Archiving - File Compression - File Conversion - Hardware Support: - Generic device APIs, eg modems - Specific Hardware/Device drivers Multiprocessing: - Time-slicing oriented - Threading oriented - Fork() oriented Operating System Support: - UNIX system platform specific modules - UNIX variants - Win32 (MicroSoft Windows) platform specific modules - VMS/OpenVMS platform specific modules - mainframe platforms - Embedded / hand-held platforms Interface Modules to Commercial Software: - ? Misfits and Oddballs: -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering
Re: Reshaping the modules list: a starting point, help remove the bias.
Ah, there's also no math or statistics sections there. Please, someone in the field beat me to it :) -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) Beauty is only skin deep, but Ugly goes straight to the bone.
Re: Reshaping the modules list: a starting point, help remove the bias.
On Wed, 25 Feb 2004 02:32, Leon Brocard wrote; I only skimmed the discussion before. What problem are you trying to solve? Locating and selecting a module to perform a particular task can be time consuming, and daunting for the novice. Authors often don't find what they want, and end up re-inventing wheels unnecessarily, when they could be (and I would guess would rather be) re-inventing suspension coils and inventing low speed differentials. Perhaps you're personally happy with search.cpan.org, but a little extra directory and indexing information can't hurt for those who can't discern the coding prowess of the author at a single glance at an API, and who don't hang out with Perl geeks for 90% of their waking hours. The relevant review information may be out there on use.perl.org, perlmonks.org, etc, you might say, but if they are all in one place they are more likely to be kept current. It might make CPAN look a bit tidier as well :-). -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) Sarcasm is not the lowest form of wit. Sarcasm is the sour cream of wit. Puns are the lowest for of wit, for which someone should be drawn and quoted. - Fred Allen (adaptation)
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On Tue, 17 Feb 2004 02:53, A. Pagaltzis wrote; (At least the Perl-XML folks got it right, props to Grant McLean!). You don't put yourself in a particular spot on Google, you just get there by being linked from lots of places. You have zero control over whether and where you appear in the results for a query. That's not entirely true. It is by design that pages - especially off-site pages that contain text content on a relevant subject, and linking to an article will increase the ranking of the target article in Google. AIUI, this was Google's flagship feature in the early days. No doubt the others have since followed suit to varying degrees. In face, the better search engine optimiser companies out there work (as well as doing easy things like making meta information appropriate) by producing a series of micro-sites that have a page or two of relevant information, then link to the target site, and to each other. So, editorial content may have the desired effect of raising search engine rankings; especially the more they are linked to as a primary source of this information. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) No man can prove upon awakening that he is the man who he thinks went to bed the night before, or that anything that he recollects is anything other than a convincing dream. -- Richard Buckminster Fuller
Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
, as well as noting the upstarts that are trying something new. e) No personal attacks, f) Try to distinguish between commenting on APIs and implementations; but please, do compare both where useful :) g) Keep as much bibiolgraphy information as possible. Link to as many relevant articles, and opinion articles as you can, within reason. Especially take note of large OSS projects or other modules on CPAN that use the works as a base, for prime examples. The text file is out of date. The underlying database isn't: [...] Please work with the PAUSE system, and Andreas and myself, to enhance what already exists (which includes a UI for module authors to pick which category they want the module in). I'd be honoured to. I think that the plan you propose would be an excellent step forward, and whether or not the editorial plan gains acceptance then it has merit. Unfortunately right now I have to move house :-) but I should be able to dedicate at some time this week to research and kick-start this recategorisation effort. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) The most incomprehensible thing about the world is that it is comprehensible. ALBERT EINSTEIN
Re: pure perl Zlib
On Mon, 16 Feb 2004 10:19, Nicholas Clark wrote; Autrijus suggested Compress::Zlib::PurePerl, which I think is reasonable. ...but it doesn't use Zlib! :) Compress::Gzip? -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) If cars had followed the same developmental path as computers, a Rolls Royce would cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.
OK, so we've decided that the right modules are too hard to find.
___ / _ \ | | | |_ _ | |_| ||\ | ||___ \___/ | \| |___ |___ upon a time, the Perl 5 modules list was an excellent resource for those seeking to do anything non-core with Perl. However, it has not kept pace adequately with the needs of the community. I propose, what we do about this situation is : - expand the modules list into a new section of the www.cpan.org site, by; - deciding if the current categories are good enough 'in this day and age'; using the current list as a starting point, go through each category and decide whether it is a useful grouping any more. This will ideally also involve individuals with experience with other languages trawling over the appropriate CPAN equivalents, ie PEAR, RAA, etc, and providing nice, *brief*, informative reports on their structure. We will then hopefully have a half-decent list of categories. This process should be quick, perhaps reporting back its progress to the list every few days until there is a general consensus. - encourage curators to step forward, or groups of curators, for each category; possibly even create mailing lists for people with a general interest in the technology in that category; to field questions about naming for new modules to fit into each category. These curators must have the power to update the contents of the relevant portions of the www.cpan.org site. The idea would be to have each category something like the http://poop.sourceforge.net/ site - but on a standard template to lend it more credibility. Ideally with space for user feedback. I would hesitate to seed the listing of actual modules on the current long Perl 5 modules list. Factors such as the usage that the module has seen, whether long standing bugs were ever fixed, whether a better module has come along since and gained widespread acceptance, etc need to be taken into consideration. Many popular modules are missing from the list altogether. The Phalanx project have a good list too, if much shorter. Such modules would likely feature as recommended in the relevant sections. If anyone who knows of any similar re-categorisation efforts (is there anything useful on PerlMonks perhaps?), now is the time to bring them forward. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) Once ... in the wilds of Afghanistan, I lost my corkscrew, and we were forced to live on nothing but food and water for days. W C FIELDS
Re: Testing output to STDOUT and STDERR
On Mon, 09 Feb 2004 14:00, Andy Lester wrote;
While writing tests for some of my code, I was faced with the issue
of capturing what the code sends to STDOUT and STDERR. As I have not
found a module to make it easy, I wrote a trivial code to do it. It
is used like this:
I'm not sure what you're actually trying to test. If you're testing
test modules, look at Test::Builder::Tester.
No, something that ties STDOUT so that code can print to it, and you
can test that the right thing was printed; I've had to do this before,
and ended up not going through the CPAN ropes for this module:
{
package Capture;
sub new {
my $class = shift;
my $self = { stdout = };
bless $self, $class;
return $self;
}
sub capture_print {
my $self = shift;
$self-{so} = tie(*STDOUT, __PACKAGE__, \$self-{stdout})
or die failed to tie STDOUT; $!;
}
sub release_stdout {
my $self = shift;
delete $self-{so};
untie(*STDOUT);
return $self-{stdout};
}
sub TIEHANDLE {
my $class = shift;
my $ref = shift;
return bless({ stdout = $ref }, $class);
}
sub PRINT {
my $self = shift;
${$self-{stdout}} .= join('', map { defined $_?$_:} @_);
}
sub PRINTF {
my ($self) = shift;
print STDERR OUCH @_\n;
my ($fmt) = shift;
${$self-{stdout}} .= sprintf($fmt, @_)
if (@_);
}
sub glob {
return \*STDOUT;
}
}
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.
--
Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
Time is an illusion perpetrated by the manufacturers of space.
GRAFFITI
Re: Testing output to STDOUT and STDERR
On Tue, 10 Feb 2004 00:57, Orton, Yves wrote; 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. Yes, that is worth noting; but I'd consider all code that bypasses the tie to be bugs or an inappropriate test case :-). I'm just a little curious about the ways that this could happen; see if you can add to this list. a) something grabs the file handle number via fileno(STDOUT) - or has a hardcoded `1' for STDOUT - and prints to that directly using stdio (now, wouldn't that have to be XS code?) b) something uses syswrite(STDOUT) c) something written via system() prints to STDOUT d) something has already DUP'ed the file handle (ie open FOO, STDOUT) and prints to it normally Its very annoying actually that there isnt a reliable and clean way to intercept STDOUT/STDERR properly. (IMO) Other than fork and IPC, which bites and doesn't play well with the test suites... try forking in the middle of a Test::Builder run. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) Activity is the politician's substitute for achievement. - anon.
Re: would you$please shut the door?
On Wed, 14 Jan 2004 12:03, A. Pagaltzis wrote; Of course there are also cases where you'd want more text than just the please to dis-/appear depending on its presence, but they we're zeroing in to something close to a fullblown templating system, and we wouldn't want another one of those on CPAN.. :-) No, especially when Locale::Maketext is so very well suited to this task... -- Sam Vilain, [EMAIL PROTECTED] Give a small boy a hammer and he will find that everything he encounters needs pounding. ABRAHAM KAPLAN
Re: namespace for module
On Wed, 03 Dec 2003 16:21, A. Pagaltzis wrote; Probably DBIx::SchematicXML::(Import|Export|Diff) or something like that. Yuck. How about XML::Map::DB or XML::Map::SQL. The original name confuses me slightly - XML Object seems to me to be a fundamental mismatch of concepts, like giving a flat purple to the time. Do you mean an XML `Tree', `Fragment' or `Element' perhaps ? Out of interest, could you pass your module a DOM compliant XML Document, eg from Xerces/Sablotron/etc to work with ? -- Sam Vilain, [EMAIL PROTECTED] If you are out to describe the truth, leave elegance to the tailor. ALBERT EINSTEIN
Re: Another sticky module naming issue
On Mon, 15 Sep 2003 17:25, Jenda Krynicky wrote;
Like http://search.cpan.org/search?query=Data::Lazymode=module
right? :-)
Yes, exactly.
The only thing in Defer.pm that I do not have in Data::Lazy is the
attribute syntax. Maybe it'd be better to add that to my module
instead of uploading a brand new module :-)
Does your module untie the original object when it is read the first
time, where it could? This avoids the tie overhead on every
subsequent access.
Do you provide any interface other than tie? For instance, I have an
`overload' interface that passes method calls and accesses onto the
lazy object, so you can do stuff like this:
my $dbh = defer { DBI-connect(@dsn) };
Changing the `defer' to `do' to have it execute immediately is one
nice feature of this syntax.
Patches welcome, otherwise I'll have a look at Defer.pm when I get
some free time and steal the attribute stuff from there ... that is
if Sam doesn't mind ;-)
Not at all, please go ahead.
--
Sam Vilain, [EMAIL PROTECTED]
It is unwise to be too sure of one's own wisdom. It is healthy to be
reminded that the strongest might weaken and the wisest might err.
-- Mahatma Gandhi
More on authors that don't respond
No, I'm not trying to flog a dead horse. Further to the earlier discussion, I thought some might find this auto-response I got from mailing one CPAN author funny: - I am preparing to or have deployed with my National Guard unit for federal active duty. I may not be able to access or read my email for extended periods of time, and even then may be limited by time or security measures. I cannot answer any questions about this deployment, the nature of our mission, or a projected return date. Loose lips sink ship ;) Mail may not be saved depending on how long I have not read mail and how much disk space I am using. If you care to write to me, my physical address for mail delivery is ... That mail will be periodically forwarded to me, or handled appropriately. Note that military censors will read anything that you write, and they will take anything you say seriously. Don't make the FBI visit you. -- Sam Vilain, [EMAIL PROTECTED] 'Martyrdom' is the only way a person can become famous without ability GEORGE BERNARD SHAW
Re: More on authors that don't respond
Further to the earlier discussion, I thought some might find this auto-response I got from mailing one CPAN author funny: - I am preparing to or have deployed with my National Guard unit for federal active duty. I may not be able to access or read my email Funny in an amusing way? Or funny as bad? Funny as in, now it's not about dead camels, rather hibernating camels, an aspect the conversation did not really focus on. Fortunately as he's looked after this responsibility it's not funny as in bad. There's also the distinctly unfunny side of it, and my thoughts go out to Brian in that regard. I now co-own everything in BDFOY's CPAN land, and his home page has a CPAN power of attorney pointing at me or Randal. What did you need help with? It's about Object::Iterate; I have a module to be released that will supply some extra forms of map (eg, Tye McQueen's mapcar), and wanted to produce iterative versions of them too. Therefore, it would be good to form a standardised set of semantics for iterators. I quite liked MJD's semantics for using a CODE ref as an iterator; it certainly makes the code simple. OTOH, I appreciate that it's not OO clean, so the Object::Iterate approach might be considered better by some. This calls for hybrid semantics IMHO. The question is, what should those semantics be, and should/how can Object::Iterate form a convenient `adapter' for the differing conventions? These are the conventions I've seen used: -__next__(Object::Iterate) -() (MJD-style) -get_next(SPOPS-style) -next(Tangram::Cursor, File::Iterator, Data::Iterator::EasyObj, etc) Also, there are some stickier points; such as - is it reasonable to assume that if an iterator returns `undef' that it's finished? Should there be a similar set of conventions for resetting or un-getting items from the iterator? -- Sam Vilain, [EMAIL PROTECTED] Real software engineers don't program in assembler. They become queasy at the very thought.
Re: what to do with dead camels ?
It turns out that in June there were 4000+ hits on modules in the could you please teach me how do you look such statistic? Is it available for public? Andy, why don't you talk with acme about getting such information added to the CPANTS metrics... clearly it is something that authors want to know. -- Sam Vilain, [EMAIL PROTECTED] The rich will do anything for the poor but get off their backs. KARL MARX
Re: Naming Advice - Devel::DebugPrint
Barbie [EMAIL PROTECTED] wrote: I have been busy tidying up and documenting my first module for CPAN and after a email from another author, noted that my first choice of name might be a bit confusing, so I thought 'Devel::DebugPrint' might be better. [...] Is Devel::DebugPrint an appropriate name or do I need a rethink? Can it fit into the Log::Dispatch architecture perhaps? To me a debug message is very much the same as a critical alert but with less severity, perhaps so little that it gets snipped off at compile time. Just a thought. If you restrict the scope to what you have described I think the name is pretty appropriate. -- Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/ 7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc 278A A425 30A9 05B5 2F13 Please dont ask me what the score is, Im not even sure what the game is. ASHLEIGH BRILLIANT
Re: name of perl in MakeMaker
Stephen Zander [EMAIL PROTECTED] wrote:
Sam Hi all, How do you return the name of perl in your module's
Sam Makefile.PL?
If you're generating rules for the Makfile that will be produced,
don't try to hardcode perl at all. Rather use the PERL Makefile
variable that MakeMaker has already gone to great pains to get right
for you.
OK, I've tried this - the following code is an example of how to get
MakeMaker's variables in a Makefile.PL:
use ExtUtils::MakeMaker;
# If this function is not called manually on older versions of
# ExtUtils::MakeMaker, it goes tits up.
ExtUtils::MakeMaker::full_setup();
my $mm = MM-new({
'NAME' = 'Pod::Constants',
...
});
open TEMPFILE, t/tempfile or die $!;
print TEMPFILE, $mm-{FULLPERL},\n;
close TEMPFILE;
$mm-flush();
In the test script, you have to open t/tempfile to get the contents.
It's a hack, but it works. Tested with 5.00503 and 5.6.1.
I fall back to the $Config{perlpath} and $^X variables in the event of a
failure with this method.
There should be an easier way.
Cheers,
--
Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13
Hi, I'm a .signature virus! Copy me into your ~/.signature, please!
