As long as I'm trying to follow topics, related to continuous testing with
github actions, I always see ubuntu-based scenarios. What about macOS and
Windows? Do we have rakudo images for these?
Best regards,
Vadim Belman
> On Jan 1, 2022, at 5:14 AM, JJ Merelo wrote:
>
> Try the n
Hi,
El sáb, 1 ene 2022 a las 12:44, Richard Hainsworth ()
escribió:
> JJ
> Thanks. That is very useful. One interesting question.
>
> I notice from this setup that you chart the COMMITS, and the raku program
> uses 'say' to output the results.
>
That's not really needed, it's just a bit of
ere a preferred / recommended / list of continuous
testing
environments?
Is there a preferred / rapid way to handle Raku modules?
Regards,
Richard
--
Fernando Santagata
--
Fernando Santagata
--
JJ
I switched to GitHub actions; don't know what's available on other
>> platforms.
>>
>> On Fri, Dec 31, 2021 at 5:43 PM Richard Hainsworth <
>> rnhainswo...@gmail.com> wrote:
>>
>>> I noticed that the .travis files have been removed from some
>>> distribut
s have been removed from some
distributions.
Also a .circleci file exists in the Raku Docs repo.
Is there a preferred / recommended / list of continuous testing
environments?
Is there a preferred / rapid way to handle Raku modules?
R
wrote:
>
>> I noticed that the .travis files have been removed from some
>> distributions.
>>
>> Also a .circleci file exists in the Raku Docs repo.
>>
>> Is there a preferred / recommended / list of continuous testing
>> environments?
>>
>>
mended / list of continuous testing
environments?
Is there a preferred / rapid way to handle Raku modules?
Regards,
Richard
--
Fernando Santagata
ons.
>
> Also a .circleci file exists in the Raku Docs repo.
>
> Is there a preferred / recommended / list of continuous testing
> environments?
>
> Is there a preferred / rapid way to handle Raku modules?
>
> Regards,
>
> Richard
>
>
--
Fernando Santagata
I noticed that the .travis files have been removed from some distributions.
Also a .circleci file exists in the Raku Docs repo.
Is there a preferred / recommended / list of continuous testing
environments?
Is there a preferred / rapid way to handle Raku modules?
Regards,
Richard
Maybe not the proper thread, ... but may be nice to know or even helpful ...
Using native integers I did not know which integer to choose when a C
type int was specified in a function signature. It is known that,
depending on processor or compiler, an int could have 16 or 32 bits size
and a
e you all have a happy holiday time at the end of the year -
different countries different celebrations, but good will to all.
Hope 2021 is properous for you all too.
About continuous testing. I have recently taken on the maintenance of
GTK::Simple.
The Travis-CI setup was c
e you all have a happy holiday time at the end of the year -
> different countries different celebrations, but good will to all.
>
> Hope 2021 is properous for you all too.
>
> About continuous testing. I have recently taken on the maintenance of
> GTK::Simple.
>
> The Travis
Hi to everyone.
Hope you all have a happy holiday time at the end of the year -
different countries different celebrations, but good will to all.
Hope 2021 is properous for you all too.
About continuous testing. I have recently taken on the maintenance of
GTK::Simple.
The Travis-CI setup
On 6/9/06, Adam Kennedy [EMAIL PROTECTED] wrote:
http://ali.as/pita.html
The above gave a 404, but http://ali.as/pita/ worked.
Michael G Schwern wrote:
On 6/9/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Adam Kennedy [EMAIL PROTECTED] [2006-06-09 18:35]:
Sorry for the lack of information, but PITA's design is fairly
ambitious,
Hmm, I just saw this:
* Adam Kennedy [EMAIL PROTECTED] [2006-06-09 18:35]:
Sorry for the lack of information, but PITA's design is fairly
ambitious,
Hmm, I just saw this:
http://googleresearch.blogspot.com/2006/04/our-conference-on-automated-testing.html
The submission deadline has already passed, but I figure
On 6/9/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Adam Kennedy [EMAIL PROTECTED] [2006-06-09 18:35]:
Sorry for the lack of information, but PITA's design is fairly
ambitious,
Hmm, I just saw this:
http://googleresearch.blogspot.com/2006/04/our-conference-on-automated-testing.html
The
Geoffrey Young wrote:
Since you're using C++, you can probably use libtap
(http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the tests and
then you could use a Perl harnes to collect those results.
just out of
Nik Clayton wrote:
Geoffrey Young wrote:
Since you're using C++, you can probably use libtap
(http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the
tests and
then you could use a Perl harnes to collect those
Sorry for the lack of information, but PITA's design is fairly
ambitious, and until the core testing loop is completed, absolutely
every other part of it would block waiting for me to finish.
So I've kept things mostly under wraps. With the core almost done (we've
had to scrap a major
Hi Andrew
I know it's somewhat vapour at the moment, and I'm keeping somewhat
quiet, but the new post-Audrey'fied PITA design is aiming at exactly
what you have described.
Initial deployment targets include a pugs smoker, parrot smoker, and
CPAN Testers 2.
Of course, I have no idea how
--- Adam Kennedy wrote:
I know it's somewhat vapour at the moment, and I'm keeping somewhat
quiet, but the new post-Audrey'fied PITA design is aiming at exactly
what you have described.
Thanks for the reminder about PITA. I'd (unforgivably) forgotten about
that project when I first enquired.
Andrew Savige wrote:
We are looking at introducing continuous builds/smoke tests at
work across a number of platforms (mainly Windows and Unix),
building a number of different languages (mainly C++).
I quick google uncovered the list below.
Anyone got any advice?
I would advise keeping
Since you're using C++, you can probably use libtap
(http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the tests and
then you could use a Perl harnes to collect those results.
just out of curiosity, has anyone gotten
Moin,
On Thursday 08 June 2006 15:11, Michael Peters wrote:
Andrew Savige wrote:
We are looking at introducing continuous builds/smoke tests at
work across a number of platforms (mainly Windows and Unix),
building a number of different languages (mainly C++).
I quick google uncovered
On Jun 8, 2006, at 10:39 AM, Tels wrote:
On my todo (well, wish list) is still a project that works rouhgly
like a
server/client model.
You upload a snapshot to the server, it notifies the clients, they
download the package, run the tests and report the result back.
Reports
are viewed on
Moin,
On Thursday 08 June 2006 18:10, Chris Dolan wrote:
On Jun 8, 2006, at 10:39 AM, Tels wrote:
On my todo (well, wish list) is still a project that works rouhgly
like a
server/client model.
You upload a snapshot to the server, it notifies the clients, they
download the package,
We are looking at introducing continuous builds/smoke tests at
work across a number of platforms (mainly Windows and Unix),
building a number of different languages (mainly C++).
I quick google uncovered the list below.
Anyone got any advice?
Thanks,
/-\
Perl
* AutoBuild:
On Sun, Feb 08, 2004 at 08:41:59AM -0600, Scott Bolte ([EMAIL PROTECTED]) wrote:
I agree, but I still believe it would be good if Test::Harness
laid out syntax rules for extensions.
There are no extensions. They're up to whoever wants to. I'm certainly
not going to define
On Sun, Feb 08, 2004 at 05:27:02PM -0600, Andy Lester wrote:
On Sun, Feb 08, 2004 at 08:41:59AM -0600, Scott Bolte ([EMAIL PROTECTED]) wrote:
I agree, but I still believe it would be good if Test::Harness
laid out syntax rules for extensions.
There are no extensions. They're up to
On Sun, 8 Feb 2004 17:27:02 -0600, Andy Lester wrote:
On Sun, Feb 08, 2004 at 08:41:59AM -0600, Scott Bolte ([EMAIL PROTECTED]
) wrote:
I agree, but I still believe it would be good if Test::Harness
laid out syntax rules for extensions.
There are no extensions. They're up to
Please let me know when you do document the format and make
sure to allow for extensions. I urge you do to so before
the sample size, and divergent extensions, gets too large.
Patches are always welcome. Also, I don't see any sample size greater
than one on this, unless I'm
On Fri, 6 Feb 2004 13:34:01 -0800, Michael G Schwern wrote:
Test::Harness parses 'ok' and 'not ok' and 'Bail out'... Test::*
modules produce the output Test::Harness parses. So your extra logic
to parse depends on would go into your Test::Harness extension, but
the depends_on() function to
I'd like to propose an addition to the Test::Harness parsing
rules to support dependency analysis. That, in turn, allows
monitoring for file changes and selective, immediate
re-execution of test files. Is this the right forum for
that discussion?
On Fri, Feb 06, 2004 at 11:03:42AM -0600, Scott Bolte wrote:
Building on the mini_harness.plx example from
Test::Harness::Straps, I added checks for declarations like
the following:
DEPENDS_ON file # implicit test file dependency
test_file
On Fri, 6 Feb 2004 12:22:24 -0800, Michael G Schwern wrote:
It wouldn't be Test::Harness, it would be a seperate Test::Depends or
something.
I could live with that, but why do you think it needs to
be separate?
The T::H documentation makes it quite clear that there
On Fri, Feb 06, 2004 at 03:14:33PM -0600, Scott Bolte wrote:
On Fri, 6 Feb 2004 12:22:24 -0800, Michael G Schwern wrote:
It wouldn't be Test::Harness, it would be a seperate Test::Depends or
something.
I could live with that, but why do you think it needs to
be separate?
37 matches
Mail list logo
