> Thanks for your write-up Michael, it was really helpful.
>
> I would definitely like to see this published.
I will try to release this eventually, but in the meantime, I just
learned something else pretty cool.
Getting PersistentPerl to reload a module is as simple as deleting the
module's ent
> I thought of an alternative which might have a number of the benefits of
> this solution with less of the drawbacks.
>
> The idea is to create one big file test file that is run in the normal
> way. Everything would only need to be loaded once instead of N times.
> There wouldn't be the usual pe
On 2005-12-07, Mark Stosberg <[EMAIL PROTECTED]> wrote:
>>
>> Limitations and Caveats with the system:
>>
>> * Scripts that muck about with STDIN, STDOUT or STDERR will probably
>>have problems.
>>
>> * The usual persistent environment caveats apply: be careful with
>>redefined subs, glo
On 2005-12-05, Michael Graham <[EMAIL PROTECTED]> wrote:
>
> This should be compatible with regular (non-PersistentPerl) use as well.
>
> ...
>
> Limitations and Caveats with the system:
>
> * Scripts that muck about with STDIN, STDOUT or STDERR will probably
>have problems.
>
> * The usual p
My test suite at work was starting to get me down. It was taking
forever to run. Not just the whole suite mind you, but individual
scripts were taking several seconds just to start up.
As my application has grown, so has its library (including a lot of
interconnected Class::DBI modules), and th
