On Wednesday, February 11, 2004, at 09:24 pm, Michael G Schwern wrote:
The biggest time suck in developing MakeMaker, and to a lesser extent
Test::More, is running the tests. Why? Because they need to be run on
lots of different platforms with lots of different versions of Perl.
Currently, I do
On 2/12/2004 9:07 PM, Randy W. Sims wrote:
> How about a model that allows people to volunteer when they can (vs
> always). Say you have a server. You would be an author-client. You'd say
> I have this software that needs to be tested. The server would take it
> and mark it available for testing
Just to let everyone know, if there aren't any comments on the scheme
in PDD 15, I'm going to implement it as-is and be done with it, at
least for now. This would be a good time to speak up--can't guarantee
that I'll put the changes in for this rev, but I certainly can't
think about it if I don
On Wed, 18 Feb 2004, Dan Sugalski wrote:
> Just to let everyone know, if there aren't any comments on the scheme
> in PDD 15, I'm going to implement it as-is and be done with it, at
> least for now. This would be a good time to speak up--can't guarantee
> that I'll put the changes in for this rev,
Hopefully in time to make the feature freeze, here's an effort at solving this
problem. I went through the platform .c and .h files and broke out the redundant bits
into the following "modules", which were already delimited by comments in generic.*:
dl: dynamic library loading
e
I'd like to put some kind of reasonably fresh content up on qa.perl.org.
If anyone's got, say, module announcements, that would make sense to
appear on qa.perl.org, please send 'em to me. I'd just like qa.p.o to
be more than a pile of links.
thanks,
xoa
--
Andy Lester => [EMAIL PROTECTED] =>
On 2/16/2004 5:25 PM, Michael G Schwern wrote:
On 2/12/2004 9:07 PM, Randy W. Sims wrote:
How about a model that allows people to volunteer when they can (vs
always). Say you have a server. You would be an author-client. You'd say
I have this software that needs to be tested. The server would ta
Some thoughts:
1) In order to be convenient for the code author, he/she should be able
to poll for available clients before submitting a job. My inclination
would be to make this a simple inetd on the client, rather than any
persistent connection between client & server. I think if there were
One really pedantic comment: wouldn't it make sense to rename the
fetchmethod op to fetchmeth, for consistency with callmeth, tailcallmeth
etc?
Simon
On Fri, 2004-02-13 at 09:21, Jens Rieks wrote:
> This patch fixes _SDL_WaitEvent a bit; SDL_WaitEvent returns an integer and
> not a SDL_Event.
> It also introduces _SDL_PollEvent which is mostly a copy of _SDL_WaitEvent.
> Finally, _SDL_loop is modified to allow an "idle" event entry that gets c
One thing to keep in mind is portability. In order for this to be useful
it has to run on pretty much all platforms. Unix, Windows, VMS, etc...
So I'm trying to keep it as simple as possible.
On Wed, Feb 18, 2004 at 05:29:49PM +, Adrian Howard wrote:
> - If this is going to be run by pa
On Fri, 2004-02-13 at 09:57, Jens Rieks wrote:
> here is an easy to use (with PIR code) wrapper of the SDL library.
> It tries to hide all internals of the wrapper and makes the most important
> SDL functions directly available in PIR code.
Overall this looks good. I am not sure if it is better
12 matches
Mail list logo
