MoarVM VS typescript-action

Implement return prioritization #1786: superseeded

Now, as to how that's done at the low level, and whether the way it's done is a good way to do it, well, I can't help. Suffice to say, the main place to look for how this is handled at the low-level is MoarVM. I dug around for a couple minutes and have a link to a commit from nearly a decade ago. Does that help?

For a class the default representation is P6Opaque. This is one of a few dozen stock representations that Raku requires compiler backends implement as standard. See, for example, the 46 .c/.h pairs of C89 source files in the relevant MoarVM directory. A quick glance at the names of the source code files should paint a broad picture. A look at their code will fill in some details.

I'm hoping someone who knows C89 can take a quick gander at the C89 code implementing 47 representations in here and comment on it.

This is (yet another) very un(der)documented Raku feature (over a decade after it was introduced!), but one can browse what looks to me like reasonably clean and commented C89 code implementing 47 representations in the relevant MoarVM directory.

FROM alpine:latest as base ARG RAKU_RELEASE=2021.12 ENV PKGS="git make gcc musl-dev perl linux-headers bash" RUN apk update && apk upgrade \ && apk add --no-cache $PKGS \ && git clone --depth 1 --branch ${RAKU_RELEASE} https://github.com/MoarVM/MoarVM.git \ && cd MoarVM \ && perl Configure.pl --prefix /usr \ && make --print-data-base \ && make install\ && cd .. \ && git clone --depth 1 --branch ${RAKU_RELEASE} git://github.com/Raku/nqp.git \ && cd nqp \ && perl Configure.pl --backends=moar --prefix /usr \ && make install \ && cd .. \ && git clone --depth 1 --branch ${RAKU_RELEASE} https://github.com/rakudo/rakudo.git \ && cd rakudo \ && perl Configure.pl --backends=moar --prefix /usr \ && make install \ && ls /usr/share/nqp/ FROM alpine:latest ARG UID=1000 LABEL version="0.5.0" maintainer="[email protected]" raku_release=${RAKU_RELEASE} raku_user_uid=${UID} COPY --from=base /usr/lib/libmoar.so /usr/lib COPY --from=base /usr/share/nqp/ /usr/share/nqp COPY --from=base /usr/share/perl6/ /usr/share/perl6 COPY --from=base /usr/bin/moar /usr/bin/nqp /usr/bin/raku /usr/bin/perl6 /usr/bin/rakudo /usr/bin/ RUN mkdir /github \ && addgroup -S raku && adduser -S raku -G raku --uid ${UID} USER raku WORKDIR /home/raku ENTRYPOINT ["raku"]

Visit the MoarVM project's home page and/or its github repo.

MoarVM's representation is very cool https://github.com/MoarVM/MoarVM/blob/master/docs/strings.asciidoc

While learning about GitHub Actions, I came across the GitHub Actions Org, and they have a bunch of templates for building custom GitHub actions. So, I started searching for a template that has TypeScript support, ensuring type safety to write bug-free code. I found the typescript-action template that includes support for tests, linter, versioning, and more.

This is the template I used for my TypeScript action https://github.com/actions/typescript-action

I found the GitHub actions documentation easier to read than Azure, so I would recommend starting writing and testing your extensions on GitHub by using the official template actions/typescript-action. The mentioned template provides a good starting point; I won't repeat the steps here. Play with it, write some simple stuff, and then return here for the next steps.

GitHub maintain a set of repos called actions. One of which is called cache.

To get started quickly with a JavaScript action, I recommend using the official templates from GitHub for JavaScript and TypeScript.

On the TypeScript side, setup was much easier. There was already a template from GitHub that took care of the basics. Most of the time spent here was updating dependencies and getting my editor to play nicely with it—18 minutes, about 10% of the total.

Now that you know how to create your own GitHub Actions, why not give it a try? Head to the GitHub Marketplace and start exploring the existing Actions, or create your own and share it with the community. With GitHub Actions, the possibilities are endless, so start building and see what you can accomplish

Your build most likely fails because your tests fail. Most CI pipelines today, like Jenkins, Circleci, GitLab, TeamCity, Bamboo, and GitHub Actions, are configured to automatically cause the build process to fail when tests fail.