Re: Preserving Supplementary Documentation, Take 2
John M. Gamble writes: It appears that I got shot down at PAUSE: You mean by [EMAIL PROTECTED] Is this a separate distribution from Math::Polynomial::Solve? (It shouldn't be.) Even if not, why not put the documentation as POD in Math::Polynomial::Solve? That isn't being shot down; it's being asked to justify what you've done. Many people upload stuff without really thinking about certain aspects of it or the impact it will have. One of the services kindly provided by the enthusiastic volunteers on modules@perl.org is to question things which look a little odd and make sure that authors have thought about all the relevant issues. If presented with a reasonable reason for doing something they usually accept it. I pointed the respondent to the conversation at http://www.nntp.perl.org/group/perl.module-authors/4558, which includes both the reason why not, and the suggestions to solve this. However it looks like you didn't CC modules@perl.org in your response, so to the rest of the volunteers it looks like you didn't answer the questions. I got no response. I'm presuming silence does not equal consent, Actually given the nature of modules@perl.org silence often does indicate consent: the various volunteers will likely respond if they can spot a potential problem, so if no questions are raised within a couple of days that likely indicates collective acceptance. ... so I have to find a different solution. Not necessarily. Try again; follow-up to the thread, making sure you include the entire list, and see what happens. Smylers
Re: Test strategy for network IO code
On Tue, 18 Jul 2006 15:12:10 -0700
Eric Wilhelm [EMAIL PROTECTED] wrote:
You probably want to avoid doing it the incorrect (even if only
slightly-so) way. The fact that a kernel or other environment issue
could break it is enough reason.
Agreed.
Have you considered doing something with tempfiles or external
programs? Maybe even mocking-up the network instead of using the real
socketpair? IPC::Run, IPC::Open3 or something?
Well, a tempfile won't really help me here. The function will write into
a handle, then expect a reply back from another handle. I suppose I could
have a big collection of little files containing all the canned
responses, and keep making a new tempfile to write the query into, and
checking that on return.. But that's starting to sound quite a big system
in itself.
IPC::Open2 could be done - I use that internally in the module anyway for
its real work so that doesn't bring in another dependency.. I'm not
sure what it would add though... Maybe something of:
open2( $rd, $wr, perl, -e,
q{ eq I want this request\n or exit(1);
print And then I send this response\n } );
Then read and write the handles, and check the child's exit status... I
suppose that could be done.. but if I'm doing that, it almost seems just
as easy to pipe()/fork() myself anyway. Keeps all the code in the file
itself then, rather than in strings.
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: Test strategy for network IO code
On Tue, 18 Jul 2006 22:25:22 -0500 Ken Williams [EMAIL PROTECTED] wrote: Could you hijack the internal functions that read write data on the socket? I.e. if call_function() uses _send() and _receive() internally, do: snip code Ooooh.. provide custom send/receive functions.. I like that. Currently the lowest level you can use this code is to give it a pair of filehandles, but actually, that might be better. Allow the lowest level of access to be function-based, write most of the test code using those, to ensure that the correct request data is being generated, and the responses are interpreted correctly. Then a smaller set of tests at the end to just ensure that the handle-based IO works. I'm starting to like that idea; though it does still need some test of handle IO... -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Perl module layout - File::StatCache
On Mon, 17 Jul 2006 09:40:05 -0700 Eric Wilhelm [EMAIL PROTECTED] wrote: I use an =head1 for the Constructor, Methods, Functions, Functions that do Foo and such sections and =head2 function_name for each function. If you want =head3, then sure, but your FUNCTIONS header is currently a child of DESCRIPTION, so each function is a grandchild of DESCRIPTION? OK, I've now put FUNCTIONS as a =head1, and all the individual function names as =head2. I think that must be approaching all, by now... Next thing to think about is how to do the next module I was going to add - this one is a cache around reading the contents of files - supposed to be for small files. It provides a simple slurp-all function: my $data = read_file( /filename/here ); Complete with caching, and checking for changes based on the stat cache. Should this module go here with File::StatCache, or in its own distribution? I don't know how expensive these things are - is it worth having a whole new distribution for one module, or is it best to put them together? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
