Re: continuous testing

2022-01-03 Thread Vadim Belman

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 new GitHub actions with the recently renovated Docker image. See it 
> in action, for instance, here: 
> 
> https://github.com/JJ/p6-pod-load/blob/master/.github/workflows/test.yaml 
> <https://github.com/JJ/p6-pod-load/blob/master/.github/workflows/test.yaml>
> El vie, 31 dic 2021 a las 19:57, Richard Hainsworth ( <mailto:rnhainswo...@gmail.com>>) escribió:
> Thanks
> 
> On 31/12/2021 18:27, Fernando Santagata wrote:
>> Hi Richard,
>> this is a link to the GitHub official documentation:
>> 
>> https://docs.github.com/en/actions <https://docs.github.com/en/actions>
>> 
>> You can also copy a configuration from another project and adapt it to your 
>> needs. For example this one installs some C libraries, some module 
>> dependencies and runs the tests:
>> 
>> https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml
>>  
>> <https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml>
>> On Fri, Dec 31, 2021 at 5:56 PM Richard Hainsworth > <mailto:rnhainswo...@gmail.com>> wrote:
>> Fernando,
>> 
>> Thanks.
>> 
>> Any link / blog / article about how to set up GitHub action up for Raku?
>> 
>> Regards,
>> 
>> Richard
>> 
>> On 31/12/2021 16:52, Fernando Santagata wrote:
>>> Hi Richard,
>>> apparently Travis CI has discontinued its free open source plan.
>>> 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 >> <mailto:rnhainswo...@gmail.com>> 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?
>>> 
>>> Is there a preferred / rapid way to handle Raku modules?
>>> 
>>> Regards,
>>> 
>>> Richard
>>> 
>>> 
>>> 
>>> -- 
>>> Fernando Santagata
>> 
>> 
>> -- 
>> Fernando Santagata
> 
> 
> -- 
> JJ



Re: continuous testing

2022-01-01 Thread JJ Merelo
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 goldplating.

> But how do you access these charted results?
>
You need to click on the log. But you can safely ignore that.

Cheers

JJ


Re: continuous testing

2022-01-01 Thread Richard Hainsworth

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.


But how do you access these charted results?

Regards,

Richard

On 01/01/2022 10:14, JJ Merelo wrote:
Try the new GitHub actions with the recently renovated Docker image. 
See it in action, for instance, here:


https://github.com/JJ/p6-pod-load/blob/master/.github/workflows/test.yaml 
<https://github.com/JJ/p6-pod-load/blob/master/.github/workflows/test.yaml>


El vie, 31 dic 2021 a las 19:57, Richard Hainsworth 
(mailto:rnhainswo...@gmail.com>>) escribió:


Thanks

On 31/12/2021 18:27, Fernando Santagata wrote:

Hi Richard,
this is a link to the GitHub official documentation:

https://docs.github.com/en/actions
<https://docs.github.com/en/actions>

You can also copy a configuration from another project and adapt
it to your needs. For example this one installs some C libraries,
some module dependencies and runs the tests:


https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml

<https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml>

On Fri, Dec 31, 2021 at 5:56 PM Richard Hainsworth
mailto:rnhainswo...@gmail.com>> wrote:

Fernando,

Thanks.

Any link / blog / article about how to set up GitHub action
up for Raku?

Regards,

Richard

On 31/12/2021 16:52, Fernando Santagata wrote:

Hi Richard,
apparently Travis CI has discontinued its free open source plan.
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
mailto:rnhainswo...@gmail.com>> 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?

Is there a preferred / rapid way to handle Raku modules?

Regards,

Richard



-- 
Fernando Santagata




-- 
Fernando Santagata




--
JJ


Re: continuous testing

2022-01-01 Thread JJ Merelo
Try the new GitHub actions with the recently renovated Docker image. See it
in action, for instance, here:

https://github.com/JJ/p6-pod-load/blob/master/.github/workflows/test.yaml

El vie, 31 dic 2021 a las 19:57, Richard Hainsworth ()
escribió:

> Thanks
> On 31/12/2021 18:27, Fernando Santagata wrote:
>
> Hi Richard,
> this is a link to the GitHub official documentation:
>
> https://docs.github.com/en/actions
>
> You can also copy a configuration from another project and adapt it to
> your needs. For example this one installs some C libraries, some module
> dependencies and runs the tests:
>
>
> https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml
>
> On Fri, Dec 31, 2021 at 5:56 PM Richard Hainsworth 
> wrote:
>
>> Fernando,
>>
>> Thanks.
>>
>> Any link / blog / article about how to set up GitHub action up for Raku?
>>
>> Regards,
>>
>> Richard
>> On 31/12/2021 16:52, Fernando Santagata wrote:
>>
>> Hi Richard,
>> apparently Travis CI has discontinued its free open source plan.
>> 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
>>> 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
>>>
>>>
>>
>> --
>> Fernando Santagata
>>
>>
>
> --
> Fernando Santagata
>
>

-- 
JJ


Re: continuous testing

2021-12-31 Thread Richard Hainsworth

Thanks

On 31/12/2021 18:27, Fernando Santagata wrote:

Hi Richard,
this is a link to the GitHub official documentation:

https://docs.github.com/en/actions <https://docs.github.com/en/actions>

You can also copy a configuration from another project and adapt it to 
your needs. For example this one installs some C libraries, some 
module dependencies and runs the tests:


https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml 
<https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml>


On Fri, Dec 31, 2021 at 5:56 PM Richard Hainsworth 
mailto:rnhainswo...@gmail.com>> wrote:


Fernando,

Thanks.

Any link / blog / article about how to set up GitHub action up for
Raku?

Regards,

Richard

On 31/12/2021 16:52, Fernando Santagata wrote:

Hi Richard,
apparently Travis CI has discontinued its free open source plan.
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
mailto:rnhainswo...@gmail.com>> 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?

Is there a preferred / rapid way to handle Raku modules?

Regards,

Richard



-- 
Fernando Santagata




--
Fernando Santagata


Re: continuous testing

2021-12-31 Thread Fernando Santagata
Hi Richard,
this is a link to the GitHub official documentation:

https://docs.github.com/en/actions

You can also copy a configuration from another project and adapt it to your
needs. For example this one installs some C libraries, some module
dependencies and runs the tests:

https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml

On Fri, Dec 31, 2021 at 5:56 PM Richard Hainsworth 
wrote:

> Fernando,
>
> Thanks.
>
> Any link / blog / article about how to set up GitHub action up for Raku?
>
> Regards,
>
> Richard
> On 31/12/2021 16:52, Fernando Santagata wrote:
>
> Hi Richard,
> apparently Travis CI has discontinued its free open source plan.
> 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 
> 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?
>>
>> Is there a preferred / rapid way to handle Raku modules?
>>
>> Regards,
>>
>> Richard
>>
>>
>
> --
> Fernando Santagata
>
>

-- 
Fernando Santagata


Re: continuous testing

2021-12-31 Thread Richard Hainsworth

Fernando,

Thanks.

Any link / blog / article about how to set up GitHub action up for Raku?

Regards,

Richard

On 31/12/2021 16:52, Fernando Santagata wrote:

Hi Richard,
apparently Travis CI has discontinued its free open source plan.
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 
mailto:rnhainswo...@gmail.com>> 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?

Is there a preferred / rapid way to handle Raku modules?

Regards,

Richard



--
Fernando Santagata


Re: continuous testing

2021-12-31 Thread Fernando Santagata
Hi Richard,
apparently Travis CI has discontinued its free open source plan.
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 
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?
>
> Is there a preferred / rapid way to handle Raku modules?
>
> Regards,
>
> Richard
>
>

-- 
Fernando Santagata


continuous testing

2021-12-31 Thread Richard Hainsworth

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



Re: Continuous testing

2020-12-29 Thread Marcel Timmerman

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 long could have 32 or 64.


So what I've done, to be free of that, is making a mapping of types 
which is generated at install time. Before the mapping is generated, the 
program runs a C program which displays the INT_MAX and INT_MIN etc. 
From that, I can see how many bits are needed and can then make a 
proper mapping to e.g int16, int32 or int64.


In the attachments there are some scripts and programs used in 
gnome-native and generates type mappings from glib types to Raku native 
types. The Build.pm6 module generates this module and is already in use 
in some of the Gnome::*::* modules. A sample GlibToRakuTypes.pm6 is 
included.


Regards,
Marcel

/*
 compile: gcc -o c-type-size c-type-size.c

 See also:
   https://www.tutorialspoint.com/c_standard_library/limits_h.htm
   https://www.tutorialspoint.com/cprogramming/c_data_types.htm
   https://en.wikibooks.org/wiki/C_Programming/limits.h
   https://www.gnu.org/software/libc/manual/html_node/Range-of-Type.html
*/

#include 
#include 
#include 
#include 

int main(int argc, char** argv) {

  printf("CHAR_BIT : %d\n", CHAR_BIT);
  printf("CHAR_MAX : %d\n", CHAR_MAX);
  printf("CHAR_MIN : %d\n", CHAR_MIN);

  printf("INT_MAX  : %d\n", INT_MAX);
  printf("INT_MIN  : %d\n", INT_MIN);
  printf("UINT_MAX : %u\n", (unsigned int) UINT_MAX);

  printf("LONG_MAX : %ld\n", (long) LONG_MAX);
  printf("LONG_MIN : %ld\n", (long) LONG_MIN);
  printf("ULONG_MAX: %lu\n", (unsigned long) ULONG_MAX);

  printf("SCHAR_MAX: %d\n", SCHAR_MAX);
  printf("SCHAR_MIN: %d\n", SCHAR_MIN);
  printf("SHRT_MAX : %d\n", SHRT_MAX);
  printf("SHRT_MIN : %d\n", SHRT_MIN);
  printf("UCHAR_MAX: %d\n", UCHAR_MAX);
  printf("USHRT_MAX: %d\n", (unsigned short) USHRT_MAX);

  return 0;
}
use v6;

my Bool $run-ok;
my Hash $c-types = %();

try {
  my Proc $proc;

  # make C program to get the limits of integers, float and doubles
  $proc = run 'gcc', '-o', 'xbin/c-type-size', 'xbin/c-type-size.c';

  # run this C program to read the limits
  $proc = run 'xbin/c-type-size', :out;

  for $proc.out.lines -> $line {
my ( $limit-name, $limit) = $$line.split(/ \s* ':' \s* /);
  #  note "$limit-name, $limit";
next if $limit-name ~~ m/ MIN | SCHAR /;

$limit-name ~~ s/SHRT/SHORT/;
$limit-name .= lc;
$limit-name = 'g' ~ $limit-name;

$limit .= Int;

given $limit-name {
  #when 'CHAR_BIT' {
  #  note "$limit-name, $limit, int$limit.base(16)";
  #}

  when / 'u' .*? '_max' $/ {
$limit-name ~~ s/ '_max' //;
$c-types{$limit-name} = 'uint' ~ $limit.base(16).chars * 4;
  #  note sprintf( "%11s uint%d",
  #$limit-name, $limit.base(16).chars * 4
  #  );
  }

  when / '_max' $/ {
$limit-name ~~ s/ '_max' //;
$c-types{$limit-name} = 'int' ~ $limit.base(16).chars * 4;
  #  note sprintf( "%11s int%d",
  #$limit-name, $limit.base(16).chars * 4
  #  );
  }
  #`{{
  when 'INT_MAX' {
note "0x$limit.base(16)", 'int' ~ ($limit.base(16).chars * 4).Str;
  }

  when 'INT_MIN' {
note "0x$limit.base(16)", 'int' ~ ($limit.base(16).chars * 4).Str;
  }

  when 'UINT_MAX' {
note "0x$limit.base(16), ", 'int' ~ ($limit.base(16).chars * 4).Str;
  }

  when 'LONG_MAX' {
note "0x$limit.base(16)", 'int' ~ ($limit.base(16).chars * 4).Str;
  }

  when 'LONG_MIN' {
note "0x$limit.base(16)", 'int' ~ ($limit.base(16).chars * 4).Str;
  }

  when 'ULONG_MAX' {
note "0x$limit.base(16), ", 'int' ~ ($limit.base(16).chars * 4).Str;
  }
  }}
}
  }

  $proc.out.close;
#  note $proc.exitcode;
  $run-ok = !$proc.exitcode;

  CATCH {
default {
  note "Failed to run C program, over to plan B, quesswork...";
  $run-ok = False;
}
  }
}

# when program fails or did not compile we need some guesswork. Raku has the
# idea that int is in64 on 64 bit machines which is not true in my case...
unless $run-ok {
#  note "\nBits: $*KERNEL.bits(), ", int64.Range;

  $c-types = 'int8';
  $c-types = 'int32';
  $c-types = $*KERNEL.bits() == 64 ?? 'int64' !! 'int32';
  $c-types = 'int16';
  $c-types = 'uint8';
  $c-types = 'uint32';
  $c-types = $*KERNEL.bits() == 64 ?? 'uint64' !! 'int32';
  $c-types = 'uint16';
}

# add other types which are fixed
$c-types = 'int8';
$c-types = 'int16';
$c-types = 'int32';
$c-types = 'int64';
$c-types = 'uint8';
$c-types = 'uint16';
$c-types = 'uint32';
$c-types = 'uint64';

$c-types = 'num32';
$c-types = 'num64';

$c-types = 'Str';
$c-types = 'Pointer[void]';

# and some types which are defined already
$c-types = $c-types;
$c-types = $c-types;
$c-types = $c-types;
$c-types = $c-types;
$c-types = $c-types;

Re: Continuous testing

2020-12-29 Thread Marcel Timmerman

On 12/23/20 7:45 PM, JJ Merelo wrote:
You can probably use AppVeyor. It's got good support for Windows, 
although you'll have to write for it specifically. This one seems to 
use it, for instance https://github.com/MARTIMM/gnome-native 
<https://github.com/MARTIMM/gnome-native>


Hi Richard,

JJ is right about the Appveyor test of gnome-native but that one is only 
testing low level things not using anything of GTK. I did not do it for 
all packages yet but the closest working one is that of gnome-gdk3. You 
can find the results here; 
https://ci.appveyor.com/project/MARTIMM/gnome-gdk3/branch/master (with a 
lot of compiler warnings in the beginning though).


It is still failing for TRAVIS and I need to look at that still.

Below is the Appveyor script that I've used for gnome-gdk3 and might 
also work for gnome-gtk3 as well. I know that your package holds the 
necessary window libraries while mine is depending on the installation 
of the GTK libraries on Linuxes and using MSYS2 on windows in particular.



os: Visual Studio 2019
image:
  - Visual Studio 2019

platform: x64

branches:
  # whitelist
  only:
    - master

environment:
  raku_test_all: 1

install:
  - set 
PATH=C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;%PATH%


  # install raku from git
  - cd C:\
  - git clone https://github.com/rakudo/rakudo.git
  - cd rakudo
  - perl Configure.pl --gen-moar --gen-nqp --backends=moar
  - gmake install
  - set 
PATH=C:\rakudo\install\bin;C:\rakudo\install\share\perl6\site\bin;%PATH%

  - cmd: dir C:\rakudo\install\bin

  # install zef from git
  - cd C:\
  - git clone https://github.com/ugexe/zef.git
  - cd zef
  - cmd: rakudo.exe -I. bin/zef install .
  - cmd: dir C:\rakudo\install\share\perl6\site\bin

  # set path to use MSYS2 tools like pacman
  - cd C:\
  - set PATH=C:\msys64\usr\bin;C:\msys64\usr\lib;%PATH%
  - bash -lc "pacman -S --noconfirm mingw-w64-x86_64-gtk3"
  - refreshenv

build: off

test_script:

  # set path to use Raku, Zef and GTK libraries
  - set 
PATH=C:\rakudo\install\bin;C:\rakudo\install\share\perl6\site\bin;C:\msys64\mingw64\bin;%PATH%


  - cd %APPVEYOR_BUILD_FOLDER%
  - cmd: zef --/test --deps-only install .
  - cmd: zef --verbose install .


Marcel



El mié, 23 dic 2020 a las 16:35, Richard Hainsworth 
(mailto:rnhainswo...@gmail.com>>) escribió:


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 was constructed a while ago and tested both
OSX and
Linux, but not Windows.

It was failing for OSX and for one of the Linux environments.

So I have changed it to the minimal docker image provided by JJ -
kudos
that man!!!

However, that required a removal of OSX - bad.

In addition, GTK::Simple is difficult to install on Windows, so I'll
need help there, but I would like to know how test a module for
Windows
anyway.

For clarity, I last used a Mac in the naughties, and stopped using
Windows as soon as I could get what I needed from Linux. So
basically, I
have minimal recent knowledge of these environments.

I have two questions:

a) Could any one provide me with a CI scheme that would cover Linux /
OSX / Windows?

Not necessarily on the same server environment.

There is an issue in GTK::Simple to the effect that it would be
better
to use github Actions instead of Travis-CI et al. A comment on this
theme would help.

b) Is there a reasonable link to a blog/tutorial on CI ?

I think that there should be some basic information on CI in the Raku
documentation on Modules. If anyone answers q1 for me, then I'll
write
up the scheme I adopt for the Modules documentation together with
a link
to better information.

When I have asked this question before, I haven't had much response.
Either I have had answers that assume everyone know about CI, or most
often I get a response that the answerer just copies/pastes
configurations from other modules.

Whilst CI is not a part of Raku, a basic CI scheme that could be
adopted
by all Module writers would enhance the robustness of the Raku module
community.



--
JJ




Re: Continuous testing

2020-12-23 Thread JJ Merelo
You can probably use AppVeyor. It's got good support for Windows, although
you'll have to write for it specifically. This one seems to use it, for
instance https://github.com/MARTIMM/gnome-native

El mié, 23 dic 2020 a las 16:35, Richard Hainsworth ()
escribió:

> 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 was constructed a while ago and tested both OSX and
> Linux, but not Windows.
>
> It was failing for OSX and for one of the Linux environments.
>
> So I have changed it to the minimal docker image provided by JJ - kudos
> that man!!!
>
> However, that required a removal of OSX - bad.
>
> In addition, GTK::Simple is difficult to install on Windows, so I'll
> need help there, but I would like to know how test a module for Windows
> anyway.
>
> For clarity, I last used a Mac in the naughties, and stopped using
> Windows as soon as I could get what I needed from Linux. So basically, I
> have minimal recent knowledge of these environments.
>
> I have two questions:
>
> a) Could any one provide me with a CI scheme that would cover Linux /
> OSX / Windows?
>
> Not necessarily on the same server environment.
>
> There is an issue in GTK::Simple to the effect that it would be better
> to use github Actions instead of Travis-CI et al. A comment on this
> theme would help.
>
> b) Is there a reasonable link to a blog/tutorial on CI ?
>
> I think that there should be some basic information on CI in the Raku
> documentation on Modules. If anyone answers q1 for me, then I'll write
> up the scheme I adopt for the Modules documentation together with a link
> to better information.
>
> When I have asked this question before, I haven't had much response.
> Either I have had answers that assume everyone know about CI, or most
> often I get a response that the answerer just copies/pastes
> configurations from other modules.
>
> Whilst CI is not a part of Raku, a basic CI scheme that could be adopted
> by all Module writers would enhance the robustness of the Raku module
> community.
>
>

-- 
JJ


Continuous testing

2020-12-23 Thread Richard Hainsworth

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 was constructed a while ago and tested both OSX and 
Linux, but not Windows.


It was failing for OSX and for one of the Linux environments.

So I have changed it to the minimal docker image provided by JJ - kudos 
that man!!!


However, that required a removal of OSX - bad.

In addition, GTK::Simple is difficult to install on Windows, so I'll 
need help there, but I would like to know how test a module for Windows 
anyway.


For clarity, I last used a Mac in the naughties, and stopped using 
Windows as soon as I could get what I needed from Linux. So basically, I 
have minimal recent knowledge of these environments.


I have two questions:

a) Could any one provide me with a CI scheme that would cover Linux / 
OSX / Windows?


Not necessarily on the same server environment.

There is an issue in GTK::Simple to the effect that it would be better 
to use github Actions instead of Travis-CI et al. A comment on this 
theme would help.


b) Is there a reasonable link to a blog/tutorial on CI ?

I think that there should be some basic information on CI in the Raku 
documentation on Modules. If anyone answers q1 for me, then I'll write 
up the scheme I adopt for the Modules documentation together with a link 
to better information.


When I have asked this question before, I haven't had much response. 
Either I have had answers that assume everyone know about CI, or most 
often I get a response that the answerer just copies/pastes 
configurations from other modules.


Whilst CI is not a part of Raku, a basic CI scheme that could be adopted 
by all Module writers would enhance the robustness of the Raku module 
community.