t/lock
), and wait until they obtain the lock. Test files that must be run in series do the same, but ask for an exclusive lock.
The exact logic for handling the lock file could be stuffed into a module, say, Test::Lock, and the test scripts themselves would just contain:
use Test::Lock; # parallel-friendly test # OR use Test::Lock -highlander; # there can be only one]]>
If "parallel" tests do not interfere with any other tests then it would be best I think to join "series" tests into single .t entry point (possibly using Test::Aggregate, but it is not necessary).
]]>https://github.com/adamkennedy/PPI/issues/93
And as for the talk question, generally:
- github issues (Adam is very good about answering here)
- whereever i hang out on irc (#web-simple is a good place to find me)
- #dist-zilla (as it uses it)
- whereever thaljef hangs out on irc
- maybe #toolchain?
I don't want to publicize it too much, but https://travis-ci.org/Perl5/DBIx-Class/jobs/390708515#L441-L462 ( DBIC is not the only user afaik )
]]>Thanks Peter
]]>https://blogs.perl.org/users/byterock/2017/11/and-here-we-go.html
]]>I suppose I could use SQL::Abstract to generate the SQL I would have to white some sort of transmogifier code to go from the Database::Accessor abstration to the SQL::Abstract version.
Just as much code me thinks.
I open small Perl workshop in 10-20 people by Borrowing rental space Regularly.
And We talk about Perl each others and develop Perl open source or service.
And write blog about the meeting with some pictures.