Re: [Semi-OT] Cross-Platform GitHub Action
On Tuesday, 8 June 2021 at 19:40:01 UTC, kinke wrote: Thx for sharing! Interesting; I've recently worked on something similar, but on Linux hosts and using a kvm/qemu/libvirt stack for running CI jobs in Windows VMs. Yeah, this is running on macOS instead because the Linux and the Windows runners on GitHub actions don't support nested virtualization. The Hypervisor framework is something similar to KVM. The VM images are actually created using QEMU (on Linux hosts), because Packer doesn't have any support for Xhyve. Packer will create a qcow2 VM image. At run time, the qcow2 image will be converted to the "raw" format, which is the only format that Xhyve supports. qcow2 is used up until runtime because it natively supports compression. I do want to support other operating systems going forward, but unfortunately, it's only FreeBSD and OpenBSD that work in Xhyve. For other operating systems I will have to use QEMU. QEMU does support the Hypervisor framework as an accelerator, but I don't think it will be as fast as Xhyve. When QEMU is supported, it will hopefully be trivial to add support for non-native architectures. I've already built the OpenBSD image for ARM64. -- /Jacob Carlborg
Re: [Semi-OT] Cross-Platform GitHub Action
On 6/8/21 3:10 PM, Jacob Carlborg wrote: # Cross-Platform GitHub Action I would like to announce the first version of a project I've been working on for a while. It's not anything D specific or implemented in D, but it can be used with D projects. This project provides a GitHub action for running GitHub Action workflows on multiple platforms. This includes platforms that GitHub Actions don't natively support. It currently supports FreeBSD and OpenBSD. https://github.com/cross-platform-actions/action Very cool! I might have a need for it. When I moved mysql-native to github actions, I could no longer run mysql integration tests on MacOS or Windows, since there is no docker support for a mysql instance on those platforms. I can probably install mysql manually at some point, but I haven't looked into it. At least for MacOS, this sounds like a way I can run a mysql instance that the MacOS host can talk to. At some point, I will give it a try! -Steve
Re: [Semi-OT] Cross-Platform GitHub Action
Thx for sharing! Interesting; I've recently worked on something similar, but on Linux hosts and using a kvm/qemu/libvirt stack for running CI jobs in Windows VMs.
[Semi-OT] Cross-Platform GitHub Action
# Cross-Platform GitHub Action
I would like to announce the first version of a project I've been
working on for a while. It's not anything D specific or
implemented in D, but it can be used with D projects. This
project provides a GitHub action for running GitHub Action
workflows on multiple platforms. This includes platforms that
GitHub Actions don't natively support. It currently supports
FreeBSD and OpenBSD.
https://github.com/cross-platform-actions/action
## Features
Some of the features that are supported include:
* Multiple operating system with one single action
* Multiple versions of each operating system
* Allows to use default shell or Bash shell
* Low boot overhead
* Fast execution
Compared to
[vmactions/freebsd-vm](https://github.com/vmactions/freebsd-vm),
the boot time is around a fifth and the full execution time for
the same job is around half of freebsd-vm.
## Usage
Here's a sample workflow file which will setup a matrix resulting
in two jobs.
One which will run on FreeBSD 12.2 and one which runs on OpenBSD
6.8.
```yaml
name: CI
on: [push]
jobs:
test:
runs-on: macos-10.15
strategy:
matrix:
os:
- name: freebsd
version: 12.2
- name: openbsd
version: 6.8
steps:
- uses: actions/checkout@v2
- name: Test on ${{ matrix.os.name }}
uses: cross-platform-actions/action@v0.0.1
env:
MY_ENV1: MY_VALUE1
MY_ENV2: MY_VALUE2
with:
environment_variables: MY_ENV1 MY_ENV2
operating_system: ${{ matrix.os.name }}
version: ${{ matrix.os.version }}
shell: bash
run: |
uname -a
echo $SHELL
pwd
ls -lah
whoami
env | sort
```
I've been using this action for one of my own projects
([DLP](https://github.com/jacob-carlborg/dlp/runs/2759807903))
for now close to a week and it works fine. It's mostly FreeBSD
that has been tested.
If you're interested in how the sausage is made, read on. Also
see the readmes of the builder repositories:
https://github.com/cross-platform-actions/freebsd-builder
https://github.com/cross-platform-actions/openbsd-builder
## Under the Hood
GitHub Actions currently only support the following platforms:
macOS, Linux and
Windows. To be able to run other platforms, this GitHub action
runs the commands
inside a virtual machine (VM). macOS is used as the host platform
because it
supports nested virtualization.
The VMs run on the [xhyve][xhyve] hypervisor, which is built on
top of Apple's
[Hypervisor][hypervisor_framework] framework. The Hypervisor
framework allows
to implement hypervisors with support for hardware acceleration
without the
need for kernel extensions. xhyve is a lightweight hypervisor
that boots the
guest operating systems quickly and requires no dependencies
outside of what's
provided by the system.
The VM images running inside the hypervisor are built using
[Packer][packer].
It's a tool for automatically creating VM images, installing the
guest
operating system and doing any final provisioning.
The GitHub action uses SSH to communicate and execute commands
inside the VM.
It uses [rsync][rsync] to share files between the guest VM and
the host. xhyve
does not have any native support for sharing files. To
authenticate the SSH
connection a unique key pair is used. This pair is generated each
time the
action is run. The public key is added to the VM image and the
private key is
stored on the host. Since xhyve does not support file sharing, a
secondar hard
drive, which is backed by a file, is created. The public key is
stored on this
hard drive, which is then mounted by the VM. At boot time, the
secondary hard
drive will be identified and the public key will be copied to the
appropriate
location.
To reduce the time it takes for the GitHub action to start
executing the
commands specified by the user, it aims to boot the guest
operating systems as
fast as possible. This is achieved in a couple of ways:
* By downloading [resources][resources], like xhyve and a few
other tools,
instead of installing them through a package manager
* No compression is used for the resources that are downloaded.
The size is
small enough anyway and it's faster to download the
uncompressed data than
it is to download compressed data and then uncompress it.
* It leverages `async`/`await` to perform tasks asynchronously.
Like
downloading the VM image and other resources at the same time
* It performs as much as possible of the setup ahead of time when
the VM image
is provisioned
[xhyve]: https://github.com/machyve/xhyve
[hypervisor_framework]:
https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/index.html
[rsync]: https://en.wikipedia.org/wiki/Rsync
[resources]: https://github.com/cross-platform-actions/resources
[packer]: htt
Re: D Language Foundation Monthly Meeting Summary
On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote: My use case of writing GUI apps for desktop - presence of GC does not matter for me at all. In fact its great for me. Hopefully D will not stop covering these use cases. Great, I am interested in highly interactive apps (games, sound editors, graphics editors, audio plugins, etc). Maybe we could create a focus group and collect experiences, approaches, weak spots, strong spots? Right now I think many feel left in the dark when they come with an idea for an app as there is little guidance of how to build a bigger app. I sense this by watching the learn-forum.
Re: From the D Blog: Driving with D
On Tuesday, 8 June 2021 at 11:35:39 UTC, Iain Buclaw wrote: Testing backports of both now ([here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935) and [here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964)). Thanks!
Re: From the D Blog: Driving with D
On Tuesday, 8 June 2021 at 09:08:20 UTC, Max Samukha wrote:
On Monday, 7 June 2021 at 10:38:08 UTC, Max Samukha wrote:
Would be great if you did. Not a blocker, though.
However, this is a major pain:
```d
struct FP {
}
alias parse = () {
FP[] parts;
parts ~= FP();
return parts;
};
immutable s = parse();
extern(C) int main() {
return 0;
}
```
avr-gdc -fno-druntime ctfe.d
ctfe.d:3:1: error: 'object.TypeInfo' cannot be used with
'-fno-rtti'
3 | struct FP {
| ^
ctfe.d:3:1: error: 'object.TypeInfo' could not be found, but is
implicitly used
3 | struct FP {
| ^
d21: internal compiler error: Segmentation fault
0x178ae29 internal_error(char const*, ...)
Thanks, that seems to be [this
issue](https://issues.dlang.org/show_bug.cgi?id=19234).
Testing backports of both now
([here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935) and
[here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964)).
Re: D Language Foundation Monthly Meeting Summary
On Monday, 7 June 2021 at 23:04:12 UTC, Norm wrote: On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote: On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote: On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote: This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection. This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory. Speaking of embedded, https://learn.adafruit.com/welcome-to-circuitpython https://blog.arduino.cc/2019/08/23/tinygo-on-arduino https://www.microsoft.com/en-us/makecode/resources http://www.ulisp.com/ https://developer.android.com/training/wearables/principles https://www.microej.com/product/vee/ Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject. There is also https://micropython.org/ I just skipped MicroPython, because Circuit Python seems to have more uptake even though it is based on it. It would not be my choice of language for medical but uPython is used in a small number of embedded medical devices and has been ported to several flavours of STM32. This is a space where D could make a difference, although unfortunately the language has some dark corner cases and friction that put some people off to the point where they don't see any benefit moving to D. Exactly, and the whole GC vs no-GC take the language nowhere in that regard.
Re: (Oh My) Gentool 0.4.0 released
On Monday, 7 June 2021 at 10:15:28 UTC, evilrat wrote: On Monday, 7 June 2021 at 09:45:53 UTC, Andrea Fontana wrote: On Sunday, 6 June 2021 at 10:03:11 UTC, evilrat wrote: ## (oh my) gentool v0.4 is now out. It is my fancy tool to generate extern(C++) stuff quicker, it takes regular compiler flags that you usually pass to clang and translates C/C++ code to D. This release has one new feature: support pragma mangle on aggregates (class, struct, etc...). Also a lot of work was put into template support, but it is still has lots of unhandled cases, so do not expect it will translate STL or Boost without need of manual fixes. Source https://github.com/Superbelko/ohmygentool Windows binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.4.0 Nice work. Is there a docker somewhere in order to test it? Added image to dockerhub https://hub.docker.com/r/superbelko/gentool Get it using `docker pull superbelko/gentool` How to use https://github.com/Superbelko/ohmygentool/wiki/Docker
Re: From the D Blog: Driving with D
On Monday, 7 June 2021 at 10:38:08 UTC, Max Samukha wrote:
Would be great if you did. Not a blocker, though.
However, this is a major pain:
```d
struct FP {
}
alias parse = () {
FP[] parts;
parts ~= FP();
return parts;
};
immutable s = parse();
extern(C) int main() {
return 0;
}
```
avr-gdc -fno-druntime ctfe.d
ctfe.d:3:1: error: 'object.TypeInfo' cannot be used with
'-fno-rtti'
3 | struct FP {
| ^
ctfe.d:3:1: error: 'object.TypeInfo' could not be found, but is
implicitly used
3 | struct FP {
| ^
d21: internal compiler error: Segmentation fault
0x178ae29 internal_error(char const*, ...)
