Re: The CPAN Covenant
hi, On 11/11/20 17:00 +0100, Steffen Mueller wrote: In the discussion on module-authors, and talking to people at the London Perl Workshop (LPW): about 60% thought it was a good idea, 20% a bad idea, and 20% indifferent. Most of the 'bad' being it works that way already. Sadly, it does only because we work hard. If CPAN authors were proactive by explicitly endorsing the above, our task would be a lot easier. i was on the side of it works that way already, but now that pause admins weight in and say that this would help them, i'm ready to help them help us. (and i'm taking this opportunity to thank the pause admins for their work) There are at least three ways this could be provided: (a) a file included in the distribution. Eg Covenant.txt (b) text in the README META.yml/json! META.yml/json would be well suited for that. otherwise, whatever filename you want as long as it's ALL_CAPS, since those have the meaning of meta files. jérôme
Re: module name for test data?
hi, and sorry for the delay to answer... On 09/09/30 01:13 -0700, Ovid wrote: - Original Message From: David Nicol davidni...@gmail.com you could put the word corpus in there somewhere, since you're publishing some test data. For others to use it, who might be looking for test data, that's what a corpus is in test data jargon (i believe.) Test::Corpus::audio::mpd would set an example of publishing test data to CPAN under the Test::Corpus prefix. ++! You know, I never did like this idea of publishing test data to the CPAN, but I ever dislike even more the idea of people stretching it for legitimate uses. The Test::Corpus:: namespace is lovely. If you publish there and folks are reasonably happy with this, let us know and I'll post some stuff to my blog and Perl-QA to get others to know about this namespace (and potentially use it). i followed your advices and just pushed test::corpus::audio::md. now i need to update my other modules to use this instead of embedding the data themselves. If these corpuses (corpi?) can also guarantee a stable interface, we may even be able to guarantee common sets of test data which different *developers* can use, not just modules. To that end, how would we guarantee a stable interface which people could trust, or be able to quickly bail out or skip if there's an incompatible change? hmm, i also provide a module that configures and launches a test mpd automatically. so it's a bit more than just a corpus. anyway, i guess i can even split it further with test::corpus only shipping the data, and the logic in test::audio::mpd. but really not for today! :-) thanks, jérôme -- jque...@gmail.com
module name for test data?
hi, i'm the maintainer of audio::mpd and poe::component::client::mpd, 2 modules that connect to a mpd server. there are 2 different modules to fit the poe environment, and take advantage of the evenement framework it provides. those 2 modules already share part of the code, with audio::mpd::common which provides them with common classes used by both modules. both audio::mpd and pococm are shipping with an extensive test suite which embeds some small ogg files. those test files weight 112k. now, 112k is not that much, but: - they are duplicated in 2 modules, which is bad - they are uploaded everytime i upload a new version of one of the modules, which is also bad therefore, i'm considering splitting the test data in a module of its own. i don't think embedding them in audio::mpd::common would be the best, since audio::mpd::common is needed at runtime, while this data is only needed during build (test) time. knowing that the new module will also provide some basic functions to start / stop associated mpd server for the tests, what module name do you suggest? - audio::mpd::common? (even if i don't think that's the best) - audio::mpd::test? this one is already used by a module in audio::mpd, but that's not a problem (i plan to move audio::mpd::test somewhere in t/lib/, so namespace would be free) - audio::mpd::testdata? - audio::mpd::common::test? - data::audio::mpd? - data::audio::mpd::test? - test::audio::mpd? - is there a namespace for bulk data? test data? == any insight welcome... thanks, jérôme -- jque...@gmail.com
Re: module name for test data?
On 09/09/28 20:08 +0100, Paul LeoNerd Evans wrote: If the module is for use purely during testing, and serves no other useful purpose, I'd make sure to include the word Test (capitalised) somewhere in its distribution name. The variations on common without test would imply it's some sort of shared useful code to use in production use. yes, i never capitalize when i'm writing (except code, of course). so the proposed module names would be capitalized correctly, of course. currently, it seems that test::audio::mpd gtes the most votes... jérôme -- jque...@gmail.com
Re: Getopt::Auto improvements
On 09/06/29 10:39 -0700, Geoffrey Leach wrote: So that needs to be specified, and while 'foo - ' is probably acceptable to the POD writer, 'foo int - ...' might be less so, taking into account that all of that appears in your POD's paragraph headings. Or am I wrong? Perhaps there's a better way? you might be interested to look at how getopt::euclid does it. it uses =for Euclid instructions aren't those modules kind of equivalent in fact? what are the advantages and drawbacks for each of them? jérôme -- jque...@gmail.com
shipping extra files in a dist?
hi there,
i'm writing a tk app that i'm shipping as a cpan dist. this app needs
some extra resource files (icons, etc) i'd like to know what's the best
method to ship extra data files in a dist.
where to put them in the dist tar file:
- create a data subdir under lib/Foo/Bar (assuming it's dist Foo::Bar).
in that case, do they get installed automatically, even if not pm
files?
- create a data subdir at the top level, and use sthg like this in
Makefile.PL:
PM = {
'data/foo.data' = '$(INST_LIB)/Foo/Bar/foo.data',
...
},
- anything else?
thanks for your help,
jérôme
--
[EMAIL PROTECTED]
comments for module naming
hello, i'm looking for a vector module to be used in Language::Befunge. currently, i provide Language::Befunge::Vector which is a pure perl version of what i'm looking for. my requirements: - n dimensions, ie, not limited to 2D (x,y) or 3D (x,y,z) - integer values - basic operations on them (addition, substraction, etc) - fast, ie not pure perl this seems to remove all the existing cpan modules but PDL. but PDL seems a bit big for what i need... or isn't it? therefore, i was planning to: 1- remove Language::Befunge::Vector from Language::Befunge and release it as a new module 2- provide a new XS module with the same interface, overwriting module 1- (same as Readonly::XS does with Readonly) 3- require module 1- recommend module 2- in Language::Befunge this has the added benefit over PDL that i can fallback on pure-perl module for machines that don't have a compiler. so now here's my question: how should i name my modules? (maybe the first question would be: do you think i'm doing sthg wise or would you recommend to use PDL?) i thought of: - Math::Vector - Math::Vector::Integer (i deal with integer only) - Math::Vector::NDims (i deal with more than 3 dims) - Math::NDimVector - other? wdyt? jérôme -- [EMAIL PROTECTED]
Re: naming advice - Tk::RRGauge
On 07/09/05 20:59 -0500, Ken Williams wrote: I'm sure the physical analog of your gauge has some specific name, could you search an electronics/mechanics supply shop and see what people call them? i've looked at wikipedia, without finding anything. therefore, i'll go with bill's proposition: tk::gauge::rotating thx, jérôme -- [EMAIL PROTECTED]
Re: naming advice - Tk::RRGauge
On 07/09/06 11:50 +0200, Jerome Quelin wrote: i've looked at wikipedia, without finding anything. therefore, i'll go with bill's proposition: tk::gauge::rotating but since tk does not seem to like namespace with depths 2, i'll use Tk::RotatingGauge. jérôme -- [EMAIL PROTECTED]
naming advice - Tk::RRGauge
hi there, i wrote a tk module providing a new widget, based on a canvas. it's basically a gauge, but the kind of gauge where the current value always stays in the middle. a small drawing is worth a thousand words: (the pipe symbol reflects current value) [1 2 3 |4 5 6] value=3.75 [ 2 3 | 5 6 ] value=4.00 [ 2 3 4| 5 6 ] value=4.25 [ 2 3 4 | 5 6 ] value=4.50 [2 3 4 |5 6 7] value=4.75 i'm not aware of such a cpan module - or did i miss it? in my current implementation, the value wraps up when reaching its max value. ie, if range is 0..10, then setting the value to 10.1 will result in a value of 0.1. this can be useful - think for example of old mileage counters. because of this behaviour, i was thinking of naming it Tk::RRGauge (RR meaning RoundRobin). however, i think i'll implement later on a mode where it does not wrap up. ie, taking the above example of 0..10 range, widget will look sthg like: [xxx| 1 2 ] value=0.00 [ 8 9 |x] value=9.99 therefore, the name RRGauge might not be the best one... so, maybe a name like Tk::RotatingGauge would be better? i welcome your comments / advices. thks, jérôme -- [EMAIL PROTECTED]
Re: help for module name?
On 07/05/27 21:27 +0200, A. Pagaltzis wrote: well, i don't like the way to prereq sthg in pococm that i won't really use - that is, the whole non-poe logic of audio::mpd. What whole non-POE logic? All the logic I can find is the as_string method. Are we talking about the same modules? i was talking of adding in this helper dist the modules stats, status and time (always in audio::mpd::) which are also just structs and are shared between the poe and non-poe implementation. thus, the dist audio::mpd::items would not be enough - unless i also release separately audio::mpd::stats and... which is a bit silly imo. therefore: - audio::mpdhelper? - audio::mpdcommon? regards, jérôme -- [EMAIL PROTECTED]
help for module name?
hi there, i'm working on a module to interface with music player daemon (mpd). i've released: - audio::mpd, a traditional oo interface - poe::component::client::mpd, a poe-aware interface they're both under development. for each of them, i've defined an item class to map the items manipulated by mpd. there are 3 subclasses item::song, item::directory and item::playlist. note that: - those items are just a bunch of accessors, - those items do not retrieve their information themselves from a file or whatever my problem is that those classes are defined both: - in audio::mpd::item (with audio::mpd::item::* subclasses) - and poe::component::client::mpd::item (with pococm::item::* subclasses) and the code is the same, with only the package name differing. since code duplication is bad, and since i don't want to put a prereq relationship between the 2 modules (in either direction), i'm going to extract the item::* classes in their own module that's going to be prereq by the others. i haven't seen any such thing on cpan, it's always tied to a format (mp3, or ogg vorbis, or...) and meant to extract meta-information from a file. so here's my question: how should i name this new module? - audio::item= isn't it too vague? - audio::mpditem = isn't it too specific? (would it be used by others?) - other? thanks for your help, jérôme -- [EMAIL PROTECTED]
Re: help for module name?
On 07/05/27 17:31 +0200, A. Pagaltzis wrote: * Jerome Quelin [EMAIL PROTECTED] [2007-05-27 09:50]: so here's my question: how should i name this new module? - audio::item= isn't it too vague? - audio::mpditem = isn't it too specific? (would it be used by others?) - other? The modules I see are just structs, and the only code in there is the formatter method in Audio::MPD::Item::Song. I does not seem to me that these things are very generically useful; you’d have to do a lot of work to make them interesting for other purposes. they are indeed just structs, as i said. I’d suggest Audio::MPD::Item as the distro name, since you’ve already organised them as a hierarchy in there. As a bonus you won’t even need to change any of the Audio::MPD code, just add the dependency and you’re done. well, i don't like the way to prereq sthg in pococm that i won't really use - that is, the whole non-poe logic of audio::mpd. i'd really like to have a small dist that could be used by the two. it would be way cleaner imho. after having sent this mail, i thought that i could as well add other helper classes used by both audio::mpd and pococ::mpd... == maybe Audio::MPDHelper could do the trick? jérôme -- [EMAIL PROTECTED]
Re: Variations on a theme
On 07/02/05 23:07 +, Paul LeoNerd Evans wrote: Before I start writing any code in this direction - are there any thoughts on this? have you looked at object::insideout? it does a lot of things, it's fast and enforces encapsulation. regards, jérôme -- [EMAIL PROTECTED]
Re: lost contact with author
On 07/01/24 21:29 +0100, Jerome Quelin wrote: i'm trying (without luck so far) to get into contact since mid-december with Audio::MPD's maintener, njh (aka Nicholas J Humfrey). this mail finally got its way to njh. :-) i'm now listed as co-maintener of audio::mpd. thx, jérôme -- [EMAIL PROTECTED]
lost contact with author
hi there, i'm trying (without luck so far) to get into contact since mid-december with Audio::MPD's maintener, njh (aka Nicholas J Humfrey). in this process, i managed to: - join the *original* author of the module - convince him to get back on Audio::MPD development :-) - set up a mailing-list for Audio::MPD development - get commit bit on original Audio::MPD svn repository (part of mpd itself) we tried to join njh to both his old ([EMAIL PROTECTED]) and new email ([EMAIL PROTECTED] ). i went on rt.cpan.org, and found one pending ticket (#24356). i've added a comment saying that i'm currently trying to join author, and invited reporter to join the mailing-list. == if you have any clue to join njh, please let me know. otherwise, i'll ask authors@ to take over maintener-ship of Audio::MPD (note: i'm cc-ing njh to his 2 known addresses + the new mailing-list) thx, jérôme -- [EMAIL PROTECTED]
