XML::Smart 1.5.5 released
I have just released XML::Smart 1.5.5
http://www.cpan.org/authors/id/G/GM/GMPASSOS/XML-Smart-1.5.5.tar.gz
The main pourpose of this announcement is to tell to the developers that
uses XML::Smart to update to the last version, since I receive a lot of
e-mails asking for support in bugs or resources that where already fixed in
the last versions.
Now XML::Smart seems to be used a lot in production projects, and this is
only possible due the tests made by all the users, what made XML::Smart much
more stable in it's quest to handle easy the complexity of XML. Soo, I say
thanks for all the reports, advices, comments and patches that I have
received. ;-P
Regards,
Graciliano M. P.
Changes (1.5+):
1.5.5 2004-03-23
- Added methods set_auto() , set_auto_node(), set_binary(), set_cdata().
- Fixed bug on copy().
- Fixed bug with date() when CONTENT key is found and should be CDATA or
BINARY.
1.5.4 2004-02-23
- Added autoload of parts of the module, to save load memory.
1.5.3 2004-02-23
- Just minor changes and fixes.
1.5.2 2004-02-15
- Fixed some minor bug on PUSH and UNSHIFT.
- Added support for multiple nodes for the same tag and interpolation of
different nodes.
- Removed duplicated entry of '/.CONTENT/0' at '/order' key.
- Added new tests and revision of the previous tests.
1.5.1 2004-02-05
- Fixed simple bug when XML::Smart object used on recursions/loops.
1.5 2004-01-15
- Added method aliase tree_pointer().
- Added method root().
- Added event handlers: on_start, on_char, on_end.
- Multiple contents handled in different way. $xml-{CONTENT} is tied
and the data will be at $xml-{'/.CONTENT/0} , $xml-{'/.CONTENT/1} ,
$xml-{'/.CONTENT/2}...
- data() will keep the multiple contents order.
- content(i , data) can be used to set a content part.
- $srt = content() returns all the multiple contents grouped.
Re: How do I prohibit analyzis for packages for certain files on CPAN upload?
On Tue, Mar 23, 2004 at 08:11:00AM -, Rafael Garcia-Suarez wrote: [untested] Put those files under inc/, eg/ or t/ (depending on what it is exactly) and include in a top-level META.yml file: (which should be autogerated by recent makemakers) private: directory: - inc - eg - t Assuming this works: Since the file is auto-generated, how do you make the change persistent? It seems something would need to be added to Makefile.PL or Build.PL. Mark
Image::Pbm
Hi, I'm about to release the module Image::Pbm - Load, create, manipulate and save pbm image files. This module implements pbm (portable bitmap) specific load() and save() methods for the Image::Base interface (using Image::Xbm and Image::PBMlib). Thus it's similar to Image::Xpm and Image::Xbm. http://search.cpan.org/~summer/Image-Base-1.07/Base.pm http://search.cpan.org/~summer/Image-Xbm-1.08/Xbm.pm http://search.cpan.org/~summer/Image-Xpm-1.09/Xpm.pm http://search.cpan.org/~elijah/Image-PBMlib-1.05/PBMlib.pm Is this namespace ok? Steffen
Re: Image::Pbm
Steffen Goeldner sent the following bits through the ether: Image::Pbm - Load, create, manipulate and save pbm image files. Is this namespace ok? It's hard to tell without showing us docs and code. Got them available? Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Do you prefer fashion victim or ensembly challenged?
DRMAA namespace (DRMAA - Distributed Resource Manager Application API)
Hi all, I have created a module that is a Perl binding to the drmaa spec, http://www.drmaa.org. The drmaa spec is to abstract an API for submitting jobs to different supporting job schedulers (so a method to distribute jobs over a network). The DRMAA provides a framework for job schedulers much like ODBC provides one for databases. Using DRMAA, the user is protected from the details of the job schedulers, also referred to as DRM's (Distributed Resource Managers). I'm looking to post this module to CPAN in the next few weeks and am wondering about the namespace. I'm currently leaning towards DRMAA (in all caps), and possibly a follow up module later called DRMAA::Simple, which would provide a set of functions that wrap together many of the DRMAA calls into do-it-all-at-once type calls. It could be argued though that someone may want to create other DRM type modules, say one that gives all the functionality of DRMAA plus specific functions available to a particular DRM, like SGE (http://gridengine.sunsource.net ). Or perhaps a DRM module that provided an API to configure the resources of the DRM, like adding nodes, changing run time calendars, etc. (currently DRMAA is just intended for launching and monitoring jobs ) So, perhaps a better namespace might be: DRM::DRMAA DRM::DRMAA::Simple and then later there could be DRM::SGE DRM::LSF DRM::OpenPBS etc. Comments, suggestions??
Re: DRMAA namespace (DRMAA - Distributed Resource Manager Application API)
- Original Message - From: Tim Harsch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 24 March 2004 03:08 Subject: DRMAA namespace (DRMAA - Distributed Resource Manager Application API) Hi all, I have created a module that is a Perl binding to the drmaa spec, http://www.drmaa.org. The drmaa spec is to abstract an API for submitting jobs to different supporting job schedulers (so a method to distribute jobs over a network). The DRMAA provides a framework for job schedulers much like ODBC provides one for databases. Using DRMAA, the user is protected from the details of the job schedulers, also referred to as DRM's (Distributed Resource Managers). I'm looking to post this module to CPAN in the next few weeks and am wondering about the namespace. I'm currently leaning towards DRMAA (in all caps), and possibly a follow up module later called DRMAA::Simple, which would provide a set of functions that wrap together many of the DRMAA calls into do-it-all-at-once type calls. A pity the acronym isn't DRAMA - this would have had much more buzzword potential ;). It could be argued though that someone may want to create other DRM type modules, say one that gives all the functionality of DRMAA plus specific functions available to a particular DRM, like SGE (http://gridengine.sunsource.net ). Or perhaps a DRM module that provided an API to configure the resources of the DRM, like adding nodes, changing run time calendars, etc. (currently DRMAA is just intended for launching and monitoring jobs ) So, perhaps a better namespace might be: DRM::DRMAA DRM::DRMAA::Simple and then later there could be DRM::SGE DRM::LSF DRM::OpenPBS etc. Comments, suggestions?? Why look to a new top level namespace? Who else has heard of, or would think of DRM or DRMAA if they want scheduling. Consider Schedule::. This is where I think your module belongs. e.g. Schedule::DRMAA, Schedule::DRMAA::Simple, Schedule::DRM::SGE etc. This is an existing namespace that holds the likes of Schedule::Cron and Schedule::Depend. My $0.02 Ivor.
