feat(components): fix antd vertical label style & merge the form token of antd theme

Before submitting a pull request, please make sure the following is done...

[x] Ensure the pull request title and commit message follow the Commit Specific in English.
[x] Fork the repo and create your branch from master or master.
[x] If you've added code that should be tested, add tests!
[x] If you've changed APIs, update the documentation.
[x] Ensure the test suite passes (npm test).
[x] Make sure your code lints (npm run lint) - we've done our best to make sure these rules match our internal linting guidelines.

Please do not delete the above content

What have you changed?
Fix the antd form design token.
Fix the vertical style of form.

哈喽，有人吗


Error during startup (runtime error)

When I launch Minecraft, it crashes saying
MineMenu (minemenu) encountered an error during the sided_setup event phase

java.lang.RuntimeException: Ran into an issue regarding reflection with field clickCount from

I'm not sure what to do here

Are you on Minecraft 1.17.1?

I have the sam isue on 1.17.1. Can you help me


How to make ethereum helm data peristent?

Is this a request for help?: Yes
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Am not sure

Version of Helm and Kubernetes:
helm : "v2.12.3"
kubernetes: "v1.13.3"

Which chart:
https://github.com/helm/charts/tree/master/stable/ethereum

What happened:
Not able to figure how to make blockchain persistent

What you expected to happen:
Example:
in the geth-miner.deployment.yaml,
for the volume, present by default:
volumes:
      - name: data
        emptyDir: {}

If i change it to, something like,
volumes:
      - name: data
        persistentVolumeClaim:
          claimName: geth-miner

Where this PVC would be amazon EBS using storage class on my AWS.
I was expecting, now my block chain would be persistent, as emptyDir lifetime is just as lifetime of Pod. PVC could solve the issue.
But what's happening is, when i have more than one replica of geth-miner, only one of the replica's is able to mount the persistent volume. And other 2 replica's go in Crash loop backoff state.
Whats the right way to solve this issue?
How to reproduce it (as minimally and precisely as possible):
Just follow the above para, and you should be able to understand it.
Make changes in geth-miner.deployment.yaml
volumes:
      - name: data
        persistentVolumeClaim:
          claimName: geth-miner

Make a new PVC meanwhile for geth-miner on aws.
And try installing the helm chart.
All 3 replica's wont launch. Only 1 replica launches and will give crash loop backoff error.
Anything else we need to know:
If I am expecting it wrong way, please correct me, whats the right way to go about it.

Did you ever come up with a solution for this?


Model parallelism with convolutional neural nets

Hello, and thank you for open sourcing this valuable contribution.
If I understand correctly, Petuum supports both data parallelism via the Parameter Server, and model parallelism via STRADS. One of the examples you so helpfully provide demonstrates how to use Petuum with Caffe to implement data parallelism with a convolutional neural network.
However, I'm interested in training a CNN on very high resolution images, i.e. via model parallelism. Is there any reason why model parallelism with CNNs might not be feasible, either in general or with Petuum?

Thank you for your interest in Petuum. May we know your name and affiliation?
Model parallelism for CNNs is feasible, and there have been a number of papers on this subject. In the current design of Caffe, implementing model parallelism will require substantial modifications (significantly more than data parallelism), and we are looking into its feasibility.

Thanks for your quick response Qirong. My name is Richard, and I am a machine learning R&D engineer at an early stage startup. Previously I completed a master's in computer engineering at the University of Toronto.
I have come across a number of papers regarding model parallelism for CNNs [1,2,3], but none which provide open source libraries for distributed model parallelism. As far as I can tell, the only such implementation is deeplearning4j [4], which I am also looking into.
Please let me know if there is some way for me to contribute to the development of model parallelism for CNNs in Petuum.
[1] http://arxiv.org/abs/1404.5997
[2] http://arxiv.org/pdf/1409.4842v1.pdf
[3] http://www.vldb.org/pvldb/vol7/p1772-tencent.pdf
[4] http://deeplearning4j.org/

Pleased to meet you, Richard.
If model size (# parameters) is your primary concern, our data-parallel CPU-based Caffe scales well with more machines. We've been able to run CNNs in excess of 1 billion parameters on a 16-machine cluster with 128GB RAM per machine (total 2TB RAM).
Could you share with us the reasons you are interested in model parallelism? Is it a matter of model size, training speed, or some other aspect?

If model size (# parameters) is your primary concern, our data-parallel CPU-based Caffe scales well with more machines.

As far as I understand, data parallelism is about replicating the same model across multiple nodes, having each node train on a separate partition of the data, and then synchronizing the parameter updates. To increase the number of parameters, the model itself needs to be split up between multiple nodes, i.e. model parallelism. Please correct me if I'm mistaken.
I'm interested in training something like AlexNet on much higher resolution images, e.g. 10,000 x 10,000 pixels.

You are basically correct about data parallelism. Another way to think about it, is that data-parallelism is about keeping a single parameter image synchronized across multiple machines, which update that parameter image concurrently. Crucially however, the underlying implementation does not need to store the full parameter image at each machine - it simply needs to provide global access to it.
Petuum's Parameter Server makes extensive use of caching and partitioning, under a special ML-centric consistency model called Stale Synchronous Parallel. As a result, our Caffe port does not have to store the full model on each machine - the model is effectively partitioned over the machines. However, the update algorithm is still data-parallel in nature - each machine uses its data subset to update the full parameter image. This is possible because Petuum's Parameter Server exposes a Distributed Shared Memory API, which hides the details of caching, partitioning and communication from the programmer.
Thank you for sharing your plans. From simple extrapolation of Alexnet, it sounds like you're aiming for a CNN in the 10-100 billion parameter range - would that be the case?

If the number of parameters increases linearly with the input size, it is about 90 billion parameters.

We will take this into account. Thank you for your feedback!


Reformat Sensor Code in Python

The current way we handle sensors in python is messy. It would probably be better to change to having sensor classes and then agents could hold multiple sensors of the same type.

Fixed in PR #175


Docker won't run on Xenial

Docker fails to install since it gets stuck at Setting up docker.io. I waited about 10 minutes and stopped its service using systemctl stop docker
# apt-get install docker.io
...
...
Setting up docker.io (1.10.3-0ubuntu6) ...
addgroup: The group `docker' already exists as a system group. Exiting.
Job for docker.service canceled.
invoke-rc.d: initscript docker, action "start" failed.
dpkg: error processing package docker.io (--configure):
 subprocess installed post-installation script returned error exit status 1
Setting up ubuntu-fan (0.9.0) ...
Processing triggers for systemd (229-4ubuntu4) ...
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Processing triggers for dbus (1.10.6-1ubuntu3) ...
Errors were encountered while processing:
 docker.io
E: Sub-process /usr/bin/dpkg returned an error code (1)
W: Operation was interrupted before it could finish

It fails to run after restarting its service:
# journalctl -u docker

-- Logs begin at Fri 2016-04-29 19:43:02 UTC, end at Fri 2016-04-29 20:01:24 UTC. --
Apr 29 19:46:29 vps systemd[1]: Starting Docker Application Container Engine...
Apr 29 19:57:38 vps systemd[1]: Stopped Docker Application Container Engine.
Apr 29 19:57:47 vps systemd[1]: Starting Docker Application Container Engine...
Apr 29 19:57:47 vps docker[5161]: time="2016-04-29T19:57:47.322396500Z" level=error msg="devmapper: Unable to delete device: devicemapper: Can't set task name /dev/mapper/docker-254:0-788386-pool"
Apr 29 19:57:47 vps docker[5161]: time="2016-04-29T19:57:47.323247501Z" level=warning msg="devmapper: Usage of loopback devices is strongly discouraged for production use. Please use `--storage-opt dm.thinpooldev` or use `man docker` to refer to dm.thinpooldev section."
Apr 29 19:57:47 vps docker[5161]: time="2016-04-29T19:57:47.344143511Z" level=error msg="[graphdriver] prior storage driver \"devicemapper\" failed: devicemapper: Can't set task name /dev/mapper/docker-254:0-788386-pool"
Apr 29 19:57:47 vps docker[5161]: time="2016-04-29T19:57:47.344669105Z" level=fatal msg="Error starting daemon: error initializing graphdriver: devicemapper: Can't set task name /dev/mapper/docker-254:0-788386-pool"
Apr 29 19:57:47 vps systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Apr 29 19:57:47 vps systemd[1]: Failed to start Docker Application Container Engine.
Apr 29 19:57:47 vps systemd[1]: docker.service: Unit entered failed state.
Apr 29 19:57:47 vps systemd[1]: docker.service: Failed with result 'exit-code'.

# uname -a
Linux vps 4.5.2-docker-2 #1 SMP Fri Apr 29 08:57:24 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I'm running this on a VC1S instance, and the bootscript is x86_64 4.5.2 docker #2
I encounter this issue no matter if I'm following the Docker Docs guide (Installation on Ubuntu) or installing docker.io from the Ubuntu repos.
It's worth mentioning that while it was stuck at Setting up docker.io the docker service was actually running, but executing docker info hung as well and produced no output.
Maybe this issue has something to do with the kernel version (v4.5) while Docker seemingly supports only v4.4, as mentioned here: https://github.com/docker/docker/issues/22371#issuecomment-215254534
Could a v4.4 bootscript with docker support fix this?

Hi @ivkos, can you try to install Docker using their recommended way:
curl https://get.docker.com | bash

Thank you @moul. That worked.
Anyway, I'm not sure if this bug report is still valid since installing docker.io from the Ubuntu repos on a clean instance actually works fine. So does installing using that oneliner.
Manual installation could've messed something up that broke the installation of the package from their official repos, or the Ubuntu ones.

Ok no problem, let's see if somebody else encounter any problem installing Docker

Hi, i used this script, but problem is still occurs
curl https://get.docker.com | bash
 root@scw-74e159:~# systemctl status docker.service

docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2016-06-10 17:27:11 UTC; 1min 38s ago
     Docs: https://docs.docker.com
 Main PID: 6254 (code=exited, status=1/FAILURE)

Jun 10 17:27:09 scw-74e159 systemd[1]: Starting Docker Application Container Engine...
Jun 10 17:27:09 scw-74e159 docker[6254]: time="2016-06-10T17:27:09.969044353Z" level=info msg="New containerd process, pid: 6281\n"
Jun 10 17:27:10 scw-74e159 docker[6254]: time="2016-06-10T17:27:10.991362978Z" level=error msg="There are no more loopback devices available."
Jun 10 17:27:10 scw-74e159 docker[6254]: time="2016-06-10T17:27:10.992019355Z" level=fatal msg="Error starting daemon: error initializing graphdriver: loopback attach failed"
Jun 10 17:27:10 scw-74e159 systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jun 10 17:27:10 scw-74e159 docker[6254]: time="2016-06-10T17:27:10Z" level=info msg="stopping containerd after receiving terminated"
Jun 10 17:27:11 scw-74e159 systemd[1]: Failed to start Docker Application Container Engine.
Jun 10 17:27:11 scw-74e159 systemd[1]: docker.service: Unit entered failed state.
Jun 10 17:27:11 scw-74e159 systemd[1]: docker.service: Failed with result 'exit-code'.

root@scw-74e159:~# uname -a
Linux scw-74e159 4.5.2-std-2 #1 SMP Fri Apr 29 08:54:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

And this is VC1S instance

Hi @kabachook
Can you retry with the docker bootscript ?

Hi @QuentinPerez
I'm linux newbee, what should i do exactly?

No problem you can find the documentation to change your bootscript here, select x86_64 4.5.4 docker and hard reboot your server with the on/off button

So i just have created new instance and changed the bootscript. After that i installed docker with oneliner and it magically work. Thank you!

@QuentinPerez how do you do that from scw create? I've tried --bootscript=docker and --bootscript=x86_64-4.5.7-docker-1 (which appears to be the full path to it here), am I doing something wrong?

Hi @kudos
You have made a little typo s/./_/g 😊
Can you try the following commands ?
$ scw _flush-cache
$ scw images -a -f type=bootscript  | grep docker
x86_64_4_5_7_docker_1       <bootscript>        b1777a5a            n/a                 fr-1                [x86_64]
armv7l_4_5_7_docker_1       <bootscript>        d51ae486            n/a                 fr-1                [arm]
$ scw create --bootscript=x86_64_4_5_7_docker_1 ubuntu-xenial
e12ff297-63e9-4941-8e61-5f8b0f717886

I have similiar issue even with fresh docker bootscript. For now, I have no idea where to dig.
root@scw-033b1b:~# uname -a Linux scw-033b1b 4.5.7-docker-4 #1 SMP Tue Jul 12 09:41:14 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
`
root@scw-033b1b:~# curl https://get.docker.com | bash
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100 14387  100 14387    0     0  22606      0 --:--:-- --:--:-- --:--:-- 22585

for key_server in '$key_servers'
sh -c 'apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D'
Executing: /tmp/tmp.6IjetsPmzf/gpg.1.sh --keyserver
hkp://ha.pool.sks-keyservers.net:80
--recv-keys
58118E89F3A912897C070ADBF76221572C52609D
gpg: requesting key 2C52609D from hkp server ha.pool.sks-keyservers.net
gpg: key 2C52609D: "Docker Release Tool (releasedocker<EMAIL_ADDRESS>not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
break
sh -c 'apt-key adv -k 58118E89F3A912897C070ADBF76221572C52609D >/dev/null'
sh -c 'mkdir -p /etc/apt/sources.list.d'
++ dpkg --print-architecture
sh -c 'echo deb [arch=amd64] https://apt.dockerproject.org/repo ubuntu-xenial main > /etc/apt/sources.list.d/docker.list'
sh -c 'sleep 3; apt-get update; apt-get install -y -q docker-engine'
Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease
Hit:2 http://archive.ubuntu.com/ubuntu xenial-updates InRelease
Get:3 http://archive.ubuntu.com/ubuntu xenial-security InRelease [94.5 kB]
Hit:4 https://apt.dockerproject.org/repo ubuntu-xenial InRelease
Fetched 94.5 kB in 0s (141 kB/s)
Reading package lists... Done
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
aufs-tools cgroupfs-mount
Suggested packages:
mountall
The following NEW packages will be installed:
aufs-tools cgroupfs-mount docker-engine
0 upgraded, 3 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B/14.6 MB of archives.
After this operation, 73.7 MB of additional disk space will be used.
Selecting previously unselected package aufs-tools.
(Reading database ... 25545 files and directories currently installed.)
Preparing to unpack .../aufs-tools_1%3a3.2+20130722-1.1ubuntu1_amd64.deb ...
Unpacking aufs-tools (1:3.2+20130722-1.1ubuntu1) ...
Selecting previously unselected package cgroupfs-mount.
Preparing to unpack .../cgroupfs-mount_1.2_all.deb ...
Unpacking cgroupfs-mount (1.2) ...
Selecting previously unselected package docker-engine.
Preparing to unpack .../docker-engine_1.11.2-0~xenial_amd64.deb ...
Unpacking docker-engine (1.11.2-0~xenial) ...
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu7) ...
Setting up aufs-tools (1:3.2+20130722-1.1ubuntu1) ...
Setting up cgroupfs-mount (1.2) ...
Setting up docker-engine (1.11.2-0~xenial) ...
Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.
invoke-rc.d: initscript docker, action "start" failed.
dpkg: error processing package docker-engine (--configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Processing triggers for systemd (229-4ubuntu7) ...
Errors were encountered while processing:
docker-engine
E: Sub-process /usr/bin/dpkg returned an error code (1)
`

`
root@scw-033b1b:~# systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2016-07-23 12:20:09 UTC; 29s ago
Docs: https://docs.docker.com
Main PID: 9156 (code=exited, status=1/FAILURE)
Jul 23 12:20:08 scw-033b1b docker[9156]: time="2016-07-23T12:20:08.624398196Z" level=info msg="New containerd process, pid: 9164\n"
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09.661385392Z" level=error msg="devmapper: Unable to delete device: devicemapper: Can't set task name /dev/mapper/docker-254:0
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09.662283227Z" level=warning msg="devmapper: Usage of loopback devices is strongly discouraged for production use. Please use
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09.666856625Z" level=error msg="[graphdriver] prior storage driver "devicemapper" failed: devicemapper: Can't set task name
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09.670488157Z" level=fatal msg="Error starting daemon: error initializing graphdriver: devicemapper: Can't set task name /dev/
Jul 23 12:20:09 scw-033b1b systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09Z" level=info msg="stopping containerd after receiving terminated"
Jul 23 12:20:09 scw-033b1b systemd[1]: Failed to start Docker Application Container Engine.
Jul 23 12:20:09 scw-033b1b systemd[1]: docker.service: Unit entered failed state.
Jul 23 12:20:09 scw-033b1b systemd[1]: docker.service: Failed with result 'exit-code'.
`
`
root@scw-033b1b:~# journalctl -xe
Jul 23 12:19:58 scw-033b1b sshd[8164]: Received disconnect from <IP_ADDRESS> port 47374:11:  [preauth]
Jul 23 12:19:58 scw-033b1b sshd[8164]: Disconnected from <IP_ADDRESS> port 47374 [preauth]
Jul 23 12:19:58 scw-033b1b sshd[8164]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=<IP_ADDRESS>  user=root
Jul 23 12:20:05 scw-033b1b systemd[1]: Reloading.
Jul 23 12:20:05 scw-033b1b systemd[1]: apt-daily.timer: Adding 11h 24min 23.147645s random time.
Jul 23 12:20:05 scw-033b1b systemd[1]: Reloading.
Jul 23 12:20:06 scw-033b1b systemd[1]: apt-daily.timer: Adding 1h 9min 10.093251s random time.
Jul 23 12:20:06 scw-033b1b systemd[1]: Reloading.
Jul 23 12:20:06 scw-033b1b systemd[1]: apt-daily.timer: Adding 8h 18min 9.801093s random time.
Jul 23 12:20:06 scw-033b1b systemd[1]: Starting LSB: Set up cgroupfs mounts....
-- Subject: Unit cgroupfs-mount.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit cgroupfs-mount.service has begun starting up.
Jul 23 12:20:06 scw-033b1b systemd[1]: Started LSB: Set up cgroupfs mounts..
-- Subject: Unit cgroupfs-mount.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit cgroupfs-mount.service has finished starting up.
-- The start-up result is done.
Jul 23 12:20:06 scw-033b1b systemd[1]: Reloading.
Jul 23 12:20:07 scw-033b1b systemd[1]: apt-daily.timer: Adding 7h 36min 3.839454s random time.
Jul 23 12:20:07 scw-033b1b systemd[1]: Reloading.
Jul 23 12:20:07 scw-033b1b systemd[1]: apt-daily.timer: Adding 11h 37min 8.950525s random time.
Jul 23 12:20:07 scw-033b1b systemd[1]: Reloading.
Jul 23 12:20:08 scw-033b1b systemd[1]: apt-daily.timer: Adding 6h 31min 24.002580s random time.
Jul 23 12:20:08 scw-033b1b systemd[1]: Reloading.
Jul 23 12:20:08 scw-033b1b systemd[1]: apt-daily.timer: Adding 6h 12min 48.747023s random time.
Jul 23 12:20:08 scw-033b1b systemd[1]: Starting Docker Socket for the API.
-- Subject: Unit docker.socket has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit docker.socket has begun starting up.
Jul 23 12:20:08 scw-033b1b systemd[1]: Listening on Docker Socket for the API.
-- Subject: Unit docker.socket has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit docker.socket has finished starting up.
-- The start-up result is done.
Jul 23 12:20:08 scw-033b1b systemd[1]: Starting Docker Application Container Engine...
-- Subject: Unit docker.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit docker.service has begun starting up.
Jul 23 12:20:08 scw-033b1b docker[9156]: time="2016-07-23T12:20:08.624398196Z" level=info msg="New containerd process, pid: 9164\n"
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09.661385392Z" level=error msg="devmapper: Unable to delete device: devicemapper: Can't set task name /dev/mapper/docker-254:0
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09.662283227Z" level=warning msg="devmapper: Usage of loopback devices is strongly discouraged for production use. Please use
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09.666856625Z" level=error msg="[graphdriver] prior storage driver "devicemapper" failed: devicemapper: Can't set task name
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09.670488157Z" level=fatal msg="Error starting daemon: error initializing graphdriver: devicemapper: Can't set task name /dev/
Jul 23 12:20:09 scw-033b1b systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jul 23 12:20:09 scw-033b1b docker[9156]: time="2016-07-23T12:20:09Z" level=info msg="stopping containerd after receiving terminated"
Jul 23 12:20:09 scw-033b1b systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: Unit docker.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit docker.service has failed.
-- The result is failed.
Jul 23 12:20:09 scw-033b1b systemd[1]: docker.service: Unit entered failed state.
Jul 23 12:20:09 scw-033b1b systemd[1]: docker.service: Failed with result 'exit-code'.
Jul 23 12:20:09 scw-033b1b systemd[1]: Reloading.
Jul 23 12:20:09 scw-033b1b systemd[1]: apt-daily.timer: Adding 10h 22min 24.228854s random time.
`

looks like the root cause is that 4.5.7-docker-4 lacks aufs support and docker daemon fallbacks to devicemapper.
root@scw-033b1b:~# nano /etc/docker/daemon.json
{
  "storage-driver" : "overlay"
}

it this case daemon started successfully

This is a serious issue, it means we cannot use Scaleway for Docker deployments! The 16.04 does not work neither with std nor docker bootscripts!
Please fix it and integrate it into std, so it works just like it works with 14.04.

Hi @andreysaksonov, @hyperknot,
Sometimes the modules kernel take to much time to be loaded, we are working on a solution to load the modules from the initrd, but for now you can do the following command before  curl https://get.docker.com | bash
oc-sync-kernel-modules # fetch the modules
depmod -a  # probe all modules

@QuentinPerez thanks, there is definitely some randomness with how much I wait after a reboot. I waited quite a lot and then oc-sync-kernel-modules worked instantly and Docker was able to be installed now.
I still recommend making this work with std, it's really hardcore when users need to try to find hidden information in GitHub tickets to install Docker. I believe 99% of your users would just switch to a different provider.

Hi, I just hit this too and it was my solution to use the overlay fs (for now at least!):
edit docker.service:
vim /lib/systemd/system/docker.service
Add -s overlay to ExecStart.
ExecStart=/usr/bin/dockerd -H fd:// -s overlay

Reload daemon
systemctl daemon-reload
(Re)start docker
sudo systemctl restart docker
Good to go.

@sjdweb I had the same issue on ubuntu 16 and your solution resolved the issue, thanks.

Just had this issue too and had to apply @sjdweb suggestion to make it work (switch to overlay fs).
Is a fix underway?
Thanks!

Had the same issue for the Debian Jessie image on Scaleway. Applied the @sjdweb fix, and the issue was resolved.

I used overlay2 instead of overlay and it seems to work fine.

Another alternative for just running a simple Docker host is to use Alpine linux on Scaleway and do:
# uncomment the "community" repo line from repository list, save:
$ vi /etc/apk/repositories

# install Docker
$ apk add --update docker

# make Docker daemon start at boot
$ rc-update add docker boot

# start Docker daemon
$ service docker start

The solution with overlay worked for me. Now I can't upgrade docker-engine to version 1.12.6-0~ubuntu-xenial. It hangs if I try to remove, upgrade or stop service.

I found the proper way to fix this. You should NEVER modify a service file in /lib/systemd as these files will be overwritten when updating Docker. Instead, you need to create a systemd "drop-in" (official term) to modify the behavior of the service file. Here is how:

mkdir -p /etc/systemd/docker.d
Create a file named /etc/systemd/docker.d/customexec.conf with the following content:

[Service]
ExecStart=/usr/bin/dockerd -H fd:// -s overlay2

systemctl daemon-reload

This will make sure Docker always starts with overlay2 instead of the default aufs which is not available with Scaleway's kernel. You can also use the old overlay if you need to but new installations should use overlay2.

Doing what @oliwer suggested. Had to put the file in  /etc/systemd/system/docker.service.d for it to be loaded, as stated here https://docs.docker.com/engine/admin/systemd/#/custom-docker-daemon-options
But else it worked as a charm. And it seems indeed as the proper way for this issue.

I have added a note in my post that changing the service file should be avoided. I have been trying out Alpine as suggested by @joonas-fi which seems to fit my needs going forward for a simple Docker host.

It seem that with the 4.8.14-docker-2 boot script, devicemapper does not work. But aufs and overlay2 works.
Jan 30 20:48:32 scw-550c06 docker[4023]: time="2017-01-30T20:48:32.331486595Z" level=fatal msg="Error starting daemon: error initializing graphdriver: devicemapper: Can't set task name /dev/mapper/docker-253:0-1837016-pool"

I seem to be running into a similar issue on Ubuntu 16.04. Docker does not start with error docker.service: Failed at step LIMITS spawning.
Some notes:

Docker has been installed according to official documentation.
Everything seems work well, but start failing on restart after we run the first container.
The issue can be easily replicated on official Digital Ocean Ubuntu Docker 1.12.6 on 16.04.

Any help is highly appreciated.
Here is log output:
journalctl -xe
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.service has begun starting up.
Feb 04 15:18:33 production-2017-new systemd[16680]: docker.service: Failed at step LIMITS spawning /usr/bin/dockerd: Opera
-- Subject: Process /usr/bin/dockerd could not be executed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- The process /usr/bin/dockerd could not be executed and failed.
--
-- The error number returned by this process is 1.
Feb 04 15:18:33 production-2017-new systemd[1]: docker.service: Main process exited, code=exited, status=205/LIMITS
Feb 04 15:18:33 production-2017-new systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: Unit docker.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.service has failed.
--
-- The result is failed.

● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2017-02-04 15:16:50 UTC; 4s ago
     Docs: https://docs.docker.com
  Process: 16633 ExecStart=/usr/bin/dockerd -H fd:// (code=exited, status=205/LIMITS)
 Main PID: 16633 (code=exited, status=205/LIMITS)

Feb 04 15:16:50 production-2017-new systemd[1]: Starting Docker Application Container Engine...
Feb 04 15:16:50 production-2017-new systemd[1]: docker.service: Main process exited, code=exited, status=205/LIMITS
Feb 04 15:16:50 production-2017-new systemd[1]: Failed to start Docker Application Container Engine.
Feb 04 15:16:50 production-2017-new systemd[1]: docker.service: Unit entered failed state.
Feb 04 15:16:50 production-2017-new systemd[1]: docker.service: Failed with result 'exit-code'.

This also affects me.

@anorsich @italomaia or whoever the error code=exited, status=205/LIMITS in systemd log when starting Docker still affects:
The Docker startup script in /lib/systemd/system/docker.service wants to increase file limits:
LimitNOFILE=1048576

For whatever reasons I can not increase my file limits value above 1000000 on Debian Stretch and Ubuntu 16.04 installations. Even changing * hard nofile in /etc/security/limits.conf doesn't work.
So I ended up creating a file /etc/systemd/system/docker.service.d/customexec.conf as stated above with this content:
[Service]
LimitNOFILE=1000000

After this and a systemctl daemon-reload Docker always starts and it works like a charm.

@anorsich The docker package set a limit higher than our new limit, so the process was failing to start.
Running the following was the fix for me:
sysctl -w fs.nr_open=1048576


Include install_info to version-history.json

What does this PR do?
Include install_info to version-history.json
Motivation
AP-1539
Additional Notes
Possible Drawbacks / Trade-offs

Describe how to test/QA your changes
1 ) Build this branch.
2 ) Set configurations for tests.
api_key: ****
run_path: /home/keisuke_umegaki_datadoghq_com/go/src/github.com/DataDog/datadog-agent/bin/agent/dist

Write an example install_info manually in /home/keisuke_umegaki_datadoghq_com/go/src/github.com/DataDog/datadog-agent/bin/agent/dist/install_info
---
install_method:
  tool: install_script
  tool_version: install_script
  installer_version: install_script-1.7.1

3 ) Run Agent.
sudo ./bin/agent/agent run -c ./bin/agent/dist/datadog.yaml > /dev/null 2>&1 &

4 ) Confirm logs.
2022-04-07 14:24:58 UTC | CORE | INFO | (pkg/util/version_history.go:52 in logVersionHistoryToFile) | Cannot read file: /home/keisuke_umegaki_datadoghq_com/go/src/github.com/DataDog/datadog-agent/bin/agent/dist/version-history.json, will create a new one. open /home/keisuke_umegaki_datadoghq_com/go/src/github.com/DataDog/datadog-agent/bin/agent/dist/version-history.json: no such file or directory

5 ) Confirm version-history.json in /home/keisuke_umegaki_datadoghq_com/go/src/github.com/DataDog/datadog-agent/bin/agent/dist/version-history.json
{"entries":[{"version":"7.36.0-rc.1+git.7.81beec0","timestamp":"2022-04-07T14:24:58.152534935Z","install_method":{"tool":"install_script","tool_version":"install_script","installer_version":"install_script-1.7.1"}}]}

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the config template has been updated.

@albertvaka @djmitche @cswatt
Thank you for your reviews!
Could you merge this PR instead of me since I don't have permissions to merge?


Differing Interpretations of Protobuf Spec in Java and Go SDKs

On the use of the text_data and binary_data fields in the protobuf-format spec, it says:

When the type of the data is text, the value MUST be stored in the text_data property.
datacontenttype SHOULD be populated with the appropriate media-type.
When the type of the data is binary the value MUST be stored in the binary_data property.
datacontenttype SHOULD be populated with the appropriate media-type.

The Java SDK's serializer always uses the text_data field when the datacontenttype is application/json, application/xml or text/*. Otherwise the binary_data field is used. However, in the Go SDK's deserializer binary_data is treated literally, while text_data gets serialized using the appropriate serializer for the datacontenttype. When a CloudEvent with a datacontenttype of application/json is serialized into protobuf using the Java SDK and then sent to a service using the Go SDK and deserialized there, this results in the JSON in the text_data field being interpreted as a JSON-String when it should be treated as a JSON-Object. So if I serialize this CloudEvent into protobuf using the Java SDK:
{
    "specversion" : "1.0",
    "type" : "com.example.someevent",
    "source" : "/mycontext",
    "subject": null,
    "id" : "C234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
        "appinfoA" : "abc",
        "appinfoB" : 123,
        "appinfoC" : true
    }
}

and then send the resulting protobuf object to a service using the Go SDK and deserialize it there back into JSON format, the result is:
{
    "specversion" : "1.0",
    "type" : "com.example.someevent",
    "source" : "/mycontext",
    "subject": null,
    "id" : "C234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : "{ \"appinfoA\" : \"abc\", \"appinfoB\" : 123, \"appinfoC\" : true }"
}

This seems to be unintended behavior, but I as far as I can tell, neither the Java nor the Go SDK implementations of the Protobuf format are technically wrong according to the way the spec is written, so I decided to raise this issue here to get clarification. Is this a bug in one or both of these libraries? Should the Protobuf format spec be more specific in how the binary_data and text_data fields should be used? Or is this behavior somehow intended?

Move to the sdk-go repo per the 2/17/2022 call.

Any update on this issue?

Apart from the confusion around a json string, I think this thread came to the wrong conclusion. I think the go sdk is doing this correctly.
in the original question, it has this example:
{
    "specversion" : "1.0",
    "type" : "com.example.someevent",
    "source" : "/mycontext",
    "subject": null,
    "id" : "C234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
        "appinfoA" : "abc",
        "appinfoB" : 123,
        "appinfoC" : true
    }
}

Which claims the java impl puts the json output into the proto data string. But I think this is incorrect, the output of marshaling a json object is not a string, it is a byte array. Casting to a string changes the value and the parsers on the other side can't make an assumption about that cast to be able to undo the cast. It makes the following non-deterministic:
    "data" : {
        "appinfoA" : "abc",
        "appinfoB" : 123,
        "appinfoC" : true
    }

vs
    "data" : "{ \"appinfoA\" : \"abc\", \"appinfoB\" : 123, \"appinfoC\" : true }"

The proto TextData should be the string { "appinfoA" : "abc", "appinfoB" : 123, "appinfoC" : true }, but the sdk must interpret this as the string "{ \"appinfoA\" : \"abc\", \"appinfoB\" : 123, \"appinfoC\" : true }".
This is exactly the same problem with parsing a cloudevent in structured mode. The spec says you need send json in json format and not a string.
{
    "specversion" : "1.0",
    "type" : "com.example.someevent",
    "source" : "/mycontext",
    "id" : "C234-1234-1234",
    "data" : {
        "this" : "is sent as binary and is a json object"
    }
}

{
    "specversion" : "1.0",
    "type" : "com.example.someevent",
    "source" : "/mycontext",
    "id" : "C234-1234-1234",
    "data" : "{\"this\" : \"is a json string and not an object\"}"
}

So, I think the go sdk is working as intended. The issue lies in the java sdk's misinterpretation of the output of the json marshaler. return type.startsWith("text/") || "application/json".equals(type) || "application/xml".equals(type);

Has somebody tried verifying the behavior using the test files from the Java SDK.... you should be able to create a protobuf object from the proto-json (and that's a photo encoding NOT a CloudEvent encoding) representation and then demarshalling it using the GO SDK.
The various photo wire-level representations are here : https://github.com/cloudevents/sdk-java/tree/master/formats/protobuf/src/test/resources/v1
The JSON data payload is very simple .. it just caries an empty JSON object.
Ideally we should assign on the wire-representation(s) and then ensure the SDKs handle them coherrently.
I can't make the call tomorrow (7/20) unfortunately.

@n3wscott wrote:

The proto TextData should be the string { "appinfoA" : "abc", "appinfoB" : 123, "appinfoC" : true }, but the sdk must interpret this as the string "{ "appinfoA" : "abc", "appinfoB" : 123, "appinfoC" : true }".

Scott - I'm wondering if comparing this to how things work for HTTP would help find the right answer. In HTTP, how do the SDKs deal with an HTTP body of:
{}

if a) content-type==app/json
and b) content-type==text/plain  ?
Do both result in the same thing (json object vs just string) ?

if a) content-type==app/json

it would be an empty json object.

and b) content-type==text/plain

it would be the string "{}"

In that case, wouldn't:

datacontenttype=app/json
text_data={}

result in a JSON Object not a string as you suggest?
(I edited my previous comment)

The simpler answer for your original question:

b) content-type==text/plain

it is invalid and the parser will throw an error. A smart parser will read in the body as the content type (string) and then will not know how to parse as json (bytes)

if a) content-type==app/json
.   it would be an empty json object.
and b) content-type==text/plain
it would be the string "{}"

That's exactly the expected behavior if you were to switch the datacontenttype in the Protobuf examples.
I'm a bit lost now as to whether we're talking purely about JSON over HTTP or JSON over a Protobuf encoded CE :-(

But you're assuming a JSON parser only takes binary data. That's not true for all languages. I'm looking at some Java samples and they all seem to assume it's a string - which is a fair assumption given JSON is a stringified format.
I guess it depends on whether the use of text_data and binary_data should override the datacontenttype attribute or not. I was assuming it wouldn't.

That's exactly the expected behavior if you were to switch the datacontenttype in the Protobuf examples.

I am not so sure, because how do I send the string "{}"?
I think if the proto gives me a string, and the content type is app/json, I should see that as a json string, and not try to cast it back to a byte array and then parse it.
As @JemDay is suggesting, if I get a proto text data as "{}", it will be parsed as a json string of {}, popping off one level of quotes.
I am saying we should see the proto text data field as having explicit quotes around the body, and any json parsing will always result in the string of the text data contents.
vs
Assume if datacontenttype is app/json, assume the text data field is bytes without the outer quotes.
I think this ends up in a broken world where if I do send a simple json string:
{
    "specversion" : "1.0",
    "type" : "com.example.someevent",
    "source" : "/mycontext",
    "id" : "C234-1234-1234",
    "data" : "this is text"
}

I could get either of these in the proto and they are equivalent:
binary_data = []byte(`"this is text"`)

text_data = "this is text"

based on previous comments, I think:

I am saying we should see the proto text data field as having explicit quotes around the body

is the point of disagreement. When a string is serialized in json, (per json.org) it starts with quotes so I'm not sure why we would remove the quotes when we put it into proto - it's part of the business data/payload. W/o it you can't tell if 1.5 is a string or a number. Taken from the JSON format samples:
content-type: application/json

1.5

absence or presence of quotes around the 1.5 means a lot. So, modifying your example:
text_data: 1.5

is that a string or a number? If we assume "missing quotes" it's a string. But then how can I represent a number? Am I forced to use binary_data ? Feels wrong.

is that a string or a number?

I would say it is the string "1.5" because it is formatted as a string. If you want that to be the number 1.5, but the bytes in the binary field. If it is json encoded, it will be 1.5

I think the larger misunderstanding here is thinking proto.text_data is equivalent to the body of http, and it is not. We get access to the proto.text_data after the wire encoding has been interpreted. text_data is a string. Proto has an extra step we should respect in the type system.

And to continue that point ... if the JSON Value is a string containing the word hello then the proto.text_data would be 7 characters long - "hello"-  including the "s because that's what makes it a JSON String value.

That behavior I'd want to verify to ensure the Java SDK works like that, I don't believe I had a test-case for that.


fix: Use subject hash for openssl macro test

The subject output appears to have changed in more recent OpenSSL versions, but the hash algorithm has been stable since OpenSSL 1.0.0.

This change is


⚠ Processors has degraded performance

In c9b56fd, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 81 ms

Resolved: Processors performance has improved in 0358b54.


Removing unused variables doesn't work

I have a sample bad_code.py script below:
import os  # unused import
import abc

unused_var = 1
print("hello world")

And I run it with the command:
autoflake --in-place --remove-unused-variables --remove-all-unused-imports bad_code.py

However, the unused_var variable is not deleted :/

I would say it makes sense it isn't removed, as unused_var has global scope here.
If that code was in a library foo, then unused_var could be accessed with foo.unused_var which might be part of it's api, hence not safe to remove.
If you had
import os  # unused import
import abc

def fun():
    unused_var = 1
    print("hello world")

then it would be removed, as it's a local variable (which could not be accessed outside fun)


Allow using other models for token splitting

Currently hardcoded to "gpt-3.5-turbo"
https://github.com/wagtail/wagtail-ai/blob/main/src/wagtail_ai/views.py#L11-L23

This would be solved by #27.


soc: arm: nrf9160: add missing NRF_UICR definition

NRF_UICR needs to be defined for nRF9160 SoC in
nrfx_config_nrf9160.h, because it is not defined
in nrfx/hal/mdk/nrf9160.h (as it is a Secure-only
peripheral).
Signed-off-by: Ioannis Glaropoulos<EMAIL_ADDRESS>

It's a bug because NRF_UICR is used in the nrf flash driver and needs to be defined for all nrf SOCs that may use that driver.

Do we need to back-port this @anangl ? :)

Do we need to back-port this @anangl ? :)

I think we do. Someone may appear brave enough to enable the SOC_FLASH_NRF_UICR option in a build for nRF9160 in 1.14 and encounter the problem. In 1.14 we'll need a dts alias in order to provide the definition of NRF_UICR (DT_INST_* macros are not available there), but apart from this, the backporting should be pretty straightforward.


Excessive progress updates during zvm install master in terminal

Description
When running the zvm install master command, the terminal is flooded with multiple lines of progress updates instead of a single updating line. This behavior is observed specifically when installing the master version, whereas installing a specific version (e.g., 0.11.0) shows the expected single line update.
Steps to Reproduce

Run the command zvm install master in the terminal.
Observe the progress updates in the terminal.

Expected Behavior
A single line in the terminal should update with the progress (e.g., [1/4] Downloading Zig version 0.12.0-dev.1861+412999621 for platform macos-x86_64... [41826431/47189164]), which refreshes with new information instead of adding new lines.
Actual Behavior
The terminal is flooded with new lines for each progress update, resulting in a long list of repetitive messages.
Additional Information

Zig Version: 0.11.0
Terminal Emulator: alacritty

Somehow fixed with https://ziglang.org/download/0.13.0/release-notes.html#Reworked-CLI-Progress


fix: fix resolving dependency of source for create mview

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Fix recording dependency information of source for creating mview, to avoid dropping some sources that have mview dependencies on them.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features).
[x] I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

[x] My PR DOES NOT contain user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note

LGTM. BTW, using TableId for SourceId is somehow confusing: when we see a TableId, we need extra context to figure out whether we're referring to a table, a source, or both (though this makes the implementation here easier). Maybe we should refine this later.

👍 yes it is. We should re-visit and refine all places related to relation ids. Actually we're using table category to generate all relation ids in meta side, which is necessary since the id is also used as the key of table fragments. So maybe we should introduce a relation id both in frontend and meta side. 🤔 It's not that urgent and I haven't thought about it any further.


Added script to run tests using local PhpUnit

Just added a Composer script to the project  to run tests using project's PhpUnit dependency . A nice turnarround for those who have incompatible PhpUnit versions installed globally.
Just run composer run test in terminal.

We use make for this, see the Makefile


Back-Translation training

Could you please release the training scripts of the paper "Understanding Back-Translation at Scale"? I Can only find the prediction scripts~ Thanks~~

I don't have a script to do the entire pipeline and even if I write one, it will be tailored to our environment. It's easier to train these models in multiple steps:

Train reverse model using only parallel data. For the paper we used the standard setup, you can find the details here: https://github.com/pytorch/fairseq/tree/master/examples/translation#replicating-results-from-scaling-neural-machine-translation   you only need to swap the language direction

Translate your target side monolingual data with the mode you've trained at stage 1. I used interactive.py and manually sharded the data to run it in parallel on 100s of GPUs. Something like this would work:

cat monolingual.de | python $BPEROOT/apply_bpe.py -c code | python interactive.py $DATA --path model.pt --buffer-size 1024 --sampling --beam 1 --nbest 1  --batch-size 16  |grep -P '^H' |cut -f3-  | sed 's/@@\s*//g' > translation.en

Finally, I combined available bitext and generated data, preprocessed it with preprocess.py and trained the final model. Here the training setup is very similar to p.1 except I trained for more updates.

Hope that makes sense.

Five methods are presented in your parper. The samping and beam_noise have reached the best performance .The conmand you mentioned above can be used to reproduce the samping, however, what about the other one ?

@alvations  the settings are very similar to those described in this paper: https://arxiv.org/abs/1806.00187  For the final model we used 128 Volta GPUs with 16G memory, --max-tokens 3584 and --update-freq 1
@maydaygmail @KelleyYin  the noising script I used: https://gist.github.com/edunov/d67d09a38e75409b8408ed86489645dd  it's a bit raw, I should probably clean it up and make available in the repository.
It works on top of beam, so you'll have to do steps 1 and 3 as usual, but for the step 2, you need to generate with beam 5:
cat monolingual.de | python $BPEROOT/apply_bpe.py -c code | python interactive.py $DATA --path model.pt --buffer-size 1024 --beam 5  --batch-size 16 |grep -P '^H' |cut -f3- | sed 's/@@\s*//g' | python addnoise.py > translation.en

@edunov Thanks a lot for your reply .

@edunov Thanks~~

@edunov just to confirm, did you use the fconv_de_en architecture to train the model that back translates monolingual data using unrestricted sampling?

@ykl7 , no I used transformer_wmt_en_de_big


Fix failing build.

Travis CI is no longer building. It errors with the following message:
ERROR in ./src/custom-theme.scss
Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/sass-loader/lib/loader.js):
Error: Node Sass does not yet support your current environment: Linux 64-bit with Unsupported runtime (79)

Please investigate and submit the fix in a pull request

Clearing the Travis cache seems to have fixed it.


Face recognition using  ICA    (Independent    Component Analysis)

Hello, I am a GSSOC'21 participant and would like to contribute to this project.

I would like to work on this @akshitagupta15june. Can you assign it to me?

assigning in fcfs to @Hamza3226

Ok. No problem. All the best @Hamza3226.

Ok. No problem. All the best @Hamza3226.

Thank You

are you still working on this issue?

are you still working on this issue?

No Ma'am.

Hey @akshitagupta15june  , Can I work on Issue  Please let me know

yes


Add source type in anticipation of some new sources being allowed in civic (e.g. ASCO abstracts, ClinVar, Clinical Trials)

Currently CIViC only allows evidence that corresponds to peer reviewed publication indexed by PubMed.
There are at least two other categories of sources that have been proposed:

Certain conference abstracts for conferences that publish abstracts online. Specifically, ASCO (http://meetinglibrary.asco.org/abstracts).
ClinVar records.

There are two main motivations for allowing this:

First, to capture the latest cutting edge evidence that hasn't yet been published but may already be influencing clinical decisions.  For example, early clinical trial findings are often presented at ASCO, sometimes years in advance of when the final publication comes out.
Second, to capture high quality evidence that will never be published.  This is particularly relevant for predisposing germline variants.  In ClinVar, several labs may have submitted considerable evidence that a variant is benign, pathogenic, etc.  A ClinVar record may provide extensive rationale, documentation of their review procedures, agreement between multiple independent groups, etc.  But for many genes, the novelty of even solid understanding of the pathogenicity of a variant may not be publishable. Or the groups involved are not motivated to publish.  Variants that meet a certain high level of evidence in ClinVar may be suitable for CIViC even if they are never published.

This is a high level decision for CIViC.  Should the scope of CIViC be absolutely limited to peer-reviewed published evidence?  Or is CIViC a place to document evidence that has reached a threshold that is high enough to influence clinical practice (which is not exclusively represented by publication).
From the CIViC meeting at NKI, it seems clear that for predisposing germline variants, a publication is not a hard requirement. Publications are considered but so is evidence published in resources like ClinVar.  If that evidence is strong enough, a predisposing variant interpretation will be returned to patients even when there is not a body of evidence in peer reviewed publications documented in PubMed.
CIViC could be a place where this evidence could be discussed and the final interpretation debated by the community.  Feedback from the NKI meeting suggested that this could be a very valuable resource to the community and might allow us to engage a new (and large) user base of clinical pathologists.

Adding an "evidence type" field is obviously pretty straightforward. I am curious though, how similar will these new evidence records be to our existing ones?
Some fields will obviously be common between "types" (say the evidence statement, or the disease). Other fields (the obvious example being "source") will be pretty different depending on the evidence type.
Will they be distinct enough that we should introduce a different evidence record schema for each "type" or does it make more sense to tack on extra fields as needed and expand the notion of what constitutes a valid "source?"

For ClinVar we need a few examples to use as prototypes. Start with the idea that a ClinVar variant record could be analogous to a pubmed indexed publication. Could we treat it similarly and create one or more evidence records in CIViC?  How forced does that seem?  Does it fit the CIViC data model close enough for us to move forward with ClinVar as a new evidence source.

During the NKI meeting, European clinical trials were mentioned to me. I know even less about accessing these as I do US trials but I was pointed to the following search page. This is probably worth digging into as well. It would be great if we could support these. https://www.clinicaltrialsregister.eu/ctr-search/search?query=olaparib

We should also accept biorxiv.

ASCO abstracts are now here: http://abstracts.asco.org/

Issue moved to griffithlab/civic-client #976 via ZenHub

Above are examples of how these are formatted in publications, and what people will be using to look for them

Moved to the civic-client repo for better organization.


Is this still hosted?

The line in the readme to add this to a server is plain text with no address, so it can't be added that way, and I am uncertain if the Polybot I am finding on the hosting sites is this one, as the features listed are different.
Is this still active?

Sorry, but this bot is no longer hosted. I believe the polybots you're seeing on those websites are not this one. Out of curiosity could you link where you saw those bots?

Sorry to hear that, but thanks for the quick response. These are the other hits I got when I looked:
https://github.com/flows-network/discord-polybot
https://discordbotlist.com/bots/poly
https://top.gg/bot/894284459787055124
https://top.gg/bot/872117428631502888
Most of them seem to be the standard multifunction moderation and toy bots, but my friend wanted the one with translation, and found yours when she searched. I'll point her at another translation bot.
Thanks again!

Thanks! Interesting other bots, didn't think this small pet project would have ever been found. Closing this issue as questions and misunderstandings have been answered. Thanks for the issue post!!


Support NFV tosca types

Is your feature request related to a problem? Please describe.
The heat translator supports a subset of the Etsi NFV TOSCA types, it would be good to support those to expand our TOSCA support.
Describe the solution you'd like
Update the forked version of the heat translator the include the new types.
Also provide reasonable extensions to support specific Openstack properties and use cases (such as reference an existing Network).

Fixed by PR #59


Azure Policy to ensure diagnostics logs to particular workspace?

Hi,
The below is mentioned in this article:
"For example, you could set a policy to ensure that all your Azure resources in a particular region sent all their diagnostic logs to a particular workspace."
I have not been able to find any policies or description of how to do this. Any suggestions? :-)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c62e3725-b0dc-5ce5-c049-70fd3ae106e3
Version Independent ID: 9c0c5ef7-bd49-cb39-ca10-d98386004975
Content: Manage Log Analytics workspaces in Azure Monitor
Content Source: articles/azure-monitor/platform/manage-access.md
Service: log-analytics
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

Thanks for your comment. We are actively investigating and will get back to you shortly. Thanks for your patience.

@theheatDK - You are correct, there isn't a policy template available that both discovers and remediates the workspace settings of the LA agent extension on Azure VMs.  There is a policy that is included with the Azure Monitor for VMs initiative that does however, monitor and report when the agent isn't configured to report to the workspace you specify.  You can take that policy definition and modify it to auto-remediate following the docs here - https://docs.microsoft.com/en-us/azure/governance/policy/tutorials/create-custom-policy-definition and then here to complete it - https://docs.microsoft.com/en-us/azure/governance/policy/how-to/programmatically-create#create-and-assign-a-policy-definition.  I am working on creating a custom policy as we speak to accomplish this and publish on GitHub, but no ETA as of yet.  #please-close and I hope this answers your question.

Thanks @MGoedtel


replace scripts?

was wondering if theres any way to replace scripts? im trying to replace a script on a newer build of a game with the same script on a older build of the game

Replacing scripts is not something UABEA does. If possible, please use a mod loader which is made for this.

I'm sorry for nectoposting, but what is the "mod loader"?

@Sidiusz not "the" mod loader but "a" mod loader. The popular mod loaders are MelonLoader and BepInEx, depending on your game.

@Sidiusz not "the" mod loader but "a" mod loader. The popular mod loaders are MelonLoader and BepInEx, depending on your game.

Ah, got it, thanks!


IlmImfTest failures on Windows

Hi,
I'm running into two test failures in IlmImfTest with Windows 10 and Visual Studio 2019. The failure is in testTypedAttribute(), on lines 759 and 792. It looks like the tests are checking that the various copy/move constructors are working, but for some reason the results are different with VS2019 than what happens on Linux and macOS (maybe due to C++ "return value optimization"? I'm definitely not an expert...). Is looks like the tests are expecting this sequence of operations:
default constructor
move assignment operator
destructor

But this is what I'm seeing instead:
default constructor
move constructor
destructor
move assignment operator
destructor

Interestingly if I change the code from:
static TestType func()
{
    TestType t;
    return t;
}

To this:
static TestType func()
{
    return TestType();
}

The tests complete successfully, but I'm not sure if that is a good fix. I did some searching on RVO and it seems the behavior might be different for C++ versions, so I also tried recompiling with C++11, C++14, and C++17, but that didn't seem to help.

Maybe the thing to do is to explicitly test copy constructors by invoking them directly, and to test move via std::move?

Thanks Nick, I'll try that and submit a PR.

Hi,
I'm seeing similar failures (using VS2019 16.9.x and 16.11 preview 3), in the same function, albeit in a slightly different location.
The underlying cause is that the tests (seemingly) expect NRVO to get applied, which is an optional optimization -- and it seems that, at least in this case, MSVC chooses not to apply it in Debug builds.

I think the resolution should be either that the tests run in Release mode, or that the test be ifdef'd for _MSC_VER and DEBUG.


Update Go version to 1.13.13 in Docker build script

What is the purpose of this change? What does it change?
This updates Go to the latest 1.13 point release. Go has received some security fixes since 1.13.6, namely CVE-2020-7919, CVE-2020-9283 and CVE-2020-15586.
The current image uses an ancient base image version:
$ docker run --rm --entrypoint='' restic/restic cat /etc/issue
Welcome to Alpine Linux 3.10
Kernel \r on an \m (\l)

Rebuilding the image will also bump Alpine to 3.12 and therefore update ca-certificates etc.
Was the change discussed in an issue or in the forum before?
No.
Checklist

[x] I have read the Contribution Guidelines
[x] I have enabled maintainer edits for this PR
[x] I have added tests for all changes in this PR
[x] I have added documentation for the changes (in the manual)
[x] There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
[x] I have run gofmt on the code in all commits
[x] All commit messages are formatted in the same style as the other commits in the repo
[x] I'm done, this Pull Request is ready for review

Why not 1.14.5?

This is up to you

@J0WI Please update Go to version 1.14.6. When we're updating Go we can as well jump to the latest version.

Done

@MichaelEischer please also update the image on DockerHub


Passing a null parameter value can cause INVALID_ARGUMENT errors

From olavloite/spanner-hibernate#1:

When i pass a null value param to a JPQL query i get the next error:
nl.topicus.jdbc.shaded.io.grpc.StatusRuntimeException: INVALID_ARGUMENT: No matching signature for operator = for argument types: STRING, BOOL. Supported signature: ANY = ANY [at 1:401] ...and contact0_.provider_id=@p1 and (@p2 is null or<EMAIL_ADDRESS>In the query i use the next WHERE clause
WHERE :positionId IS NULL OR c.position.id = :positionId

This problem is in the handling of null values of parameters in the jdbc driver and not in the Hibernate dialect.

@flascaray Definitely a bug which will be fixed. In the meantime the following work-around will probably work. Change the query into something like this:
SELECT ... FROM ... WHERE COALESCE(CAST(:positionId AS STRING), '')='' OR c.position.id = CAST(:positionId AS STRING)


Add option to use the package online

Description of the desired feature:

Choose between Google Colab or Binder
Binder

searches repo for either requirements.txt or environment.yml to build a Docker image.

.yml would be good since it uses conda to install, solves issues associate with #17  and #19

automatically include in Jupyter-Book RTD webpage.

follow this to use conda and pip

follow this to use with just conda

follow this to use with just pip

tutorial

Colab

can install packages within the Colab with !pip install or !apt-get install
Follow directions here to set up PyGMT on Colab

%%capture
!sudo apt update
!sudo apt upgrade -y
!sudo apt install -y build-essential cmake libcurl4-gnutls-dev libnetcdf-dev gdal-bin libgdal-dev libfftw3-dev libpcre3-dev liblapack-dev libblas-dev libglib2.0-dev ghostscript ghostscript-x graphicsmagick ffmpeg xdg-utils
# clone gmt from source
!git clone --depth 50 https://github.com/GenericMappingTools/gmt
# cmake everything
!cmake /content/gmt
# build and install
!cmake --build . --target install

# just for the paranoics (answer should be )/usr/local/bin/gmt
!which GMT

# install pygmt and geopandas with pip
%%capture
!pip install pygmt geopandas

# %load_ext autoreload
# %autoreload 2
# install antarctic_plots with pip
%%capture
!pip install antarctic_plots
from antarctic_plots import profile
from antarctic_plots import fetch

Above only recognized v0.0.1 of antarctic_plots
Other things

repo2docker

Are you willing to help implement and maintain this feature?

Yes

Added folder /binder with environment.yml. This automatically re-builds binder with each PR with the pinned packages in the above file.
I haven't figured out how to have conda install optional dependencies, so tqdm is included for pooch[progress], and the following are included for xarray[io]:

cfgrib=<IP_ADDRESS>
rasterio=1.3.2
cftime=1.6.1
zarr=2.12.0
pydap=3.2.2
scipy=1.6.1
h5netcdf=1.0.2
netcdf4=1.6.0

After lots of attempts, the following commit had the successful environment.yml file: c88a23c9dfe92c36f0bfdbbc277d926c2de763de
The binder link is: https://mybinder.org/v2/gh/mdtanker/antarctic_plots/c88a23c9dfe92c36f0bfdbbc277d926c2de763de
Still need to follow this link to help reduce the binder build time, and to stop rebuilding at each commit.


Refactor workflow and add Beta channel

I tried to improve the workflow as much as I could to make it both more clear and functional.
As such, these are the changes that I've made :

Add Beta channel.
Sections are now more visible and better divided.
Accept tag input from manual workflow.
Skip building if a version has already been built.

This can be controlled when running a manual workflow.

Get true latest version from releases, not the one tagged latest.

Brave might release a new version but not tag it as latest.
To work around this we can use the first item in the list of all releases.

Make wget and curl less verbose to unclutter the output.
Workflow no longer fails when error codes are encountered in the script.
Specify release version for continuous builds.
Fix wrong repo name for AppImage update information.

If you would like to see the results then check out my release page.

Thanks for the PR! I will take a look shortly


Remove Duplicate Require Statements and Unify Syntax on '

Duplicate Imports:
https://github.com/casesandberg/atom/commit/8c5c795b35499996b057041c7cabd05f047fe9ae#diff-f93881c6debdf6136cc7fbd22c21340dL1
https://github.com/casesandberg/atom/commit/8c5c795b35499996b057041c7cabd05f047fe9ae#diff-f42f793b4715cfbf8d07c772bc142849L10

My bad 👻

@50Wliu fixed

Thanks!


setup.py incorrectly claims pyXML dependency

setup.py checks for xml.parsers.expat, but when it does not find that, it proclaims that it needs pyXML.
This is incorrect, please fix it. (pyXML is a dead project that does not even support python-3.x; this uses the expat support coming with python itself which might however be packaged separately by a distribution.)

That was removed some month ago with commit https://github.com/behdad/fonttools/commit/bf51c78d72c9253217e3b8c46a5dd5aa5c61349c#diff-2eeaed663bd0d25b7e608891384b7298
If you can, please git pull from the latest master/HEAD.
Hopefully we'll tag a new release soon... 😁


Why is the first inference Extremely Slow?

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
YES, as custom ops in the network.
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 16.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: No.
TensorFlow installed from (source or binary): Source, 2.3.1
TensorFlow version (use command below): 2.3.1
Python version: 3.5
Bazel version (if compiling from source): Bazel 3.1
GCC/Compiler version (if compiling from source): 7
CUDA/cuDNN version: 10.2
GPU model and memory: 2080 Ti

Describe the current behavior
So I'm using Tensorflow C++ APIs to do inference using CallableHandle with Session.
I used RunMetadata to dump the full trace for the first inference in C++. Part of the timeline showed in Chrome://tracing
I ran this model freezed using TF 1.15, and it ran in TF 2.3 without obvious issues.

As you could see, every convolution layer here took EXTREMELY long to do, and it's showing they are also running on GPU.
After couple of inferences, the inference time for the model is super short. So this makes me wonder what's happening in the first inference.
Describe the expected behavior
I know the first inference is usually slower than following ones, but this is extremely slow compared to how long it usually take.
The first inference here took 200s, while it was expected to run around 0.1s.
As one more reference data point, the same model running with TF 1.15 inference stack, the first inference would take around 10s to finish. TF 2.3 seems to be super slow for the same model.
Other info / logs
RunMetadata dumped tracing json (had to change to txt suffix):
Truncated, only showing part of the entire timeline.
github_2.3_profile.txt

@golden0080 Can you please attach a minimal code snippet to reproduce the behavior? Thanks!

@ymodak Seems like this is exactly the issue in https://github.com/tensorflow/tensorflow/issues/40036 and I was able to resolve it after installing ptxas.


fix gltf options for asset_manager usage

Fix for declarations of compile time options on tiny_gltf header.
Makes sure different cpp files are targeting the same global asset_manager variable defined. Android target should work fine after merging this and the other PRs I've submitted recently (#61 and #60).
Thanks

Thank you very much for your PRs. I'll try to take a look at them asap.
But can you elaborate a bit? Was Android broken in recent builds?

Hi,
It was compiling fine, but at runtime there were issues with loading the meshes/assets.
The global asset_manager variable inside tiny gltf header was not being defined for VulkanglTFModel.cpp side correctly. And when you add TINYGLTF_ANDROID_LOAD_FROM_ASSETS option to that cpp as well, it was declaring different variables. I've make a change for the tiny_gltf side recently to make sure it's declared as 'extern' when TINYGLTF_IMPLEMENTATION is not defined. So, now the assignment to asset_manager variable in main.cpp is using the same variable with VulkanglTFModel.cpp file, and it loads the assets correctly.
With my compilation setup in Android Studio, it was also crashing when there are no explicit returns in the getVkWrapMode/getVkFilterMode functions as in #60 . I also had to upgrade the gradle version to get it compiling, but didn't submit that one as it may not be necessary for everyone.
Thank you!

That makes sense. Just merged your PRs and everything is working as expected on Windows and Android. Again thank you very much for your contribution. Very much appreciated!


Crash when calling std::cout in gdextension constructor

Tested versions
Not reproducible in 4.1
Reproducible in 4.2
System information
Arch Linux 6.6.4-arch1-1 (64-bit)
Issue description
Crashing Godot if std::cout is called in a C++ class constructor using gdextension.
The call can be as simple as:
std::cout << "Hello World\n";
Removing it, Godot starts up.
Other calls to std::cout, which is not call in any initialization, I guess will just crash the application when running it from Godot.
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.2.stable.arch_linux
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x3e710) [0x7f178c56f710] (??:0)
[2] std::ostream::sentry::sentry(std::ostream&) (??:?)
[3] std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) (??:0)
[4] /media/ntfsevo/Utveckling/GODOT4/GoKam/GoKam/bin/libgdgokam.linux.template_debug.x86_64.so(+0x2630a) [0x7f1789c1e30a] (??:0)
[5] /media/ntfsevo/Utveckling/GODOT4/GoKam/GoKam/bin/libgdgokam.linux.template_debug.x86_64.so(+0x381fb) [0x7f1789c301fb] (??:0)
[6] /media/ntfsevo/Utveckling/GODOT4/GoKam/GoKam/bin/libgdgokam.linux.template_debug.x86_64.so(+0x13cd9) [0x7f1789c0bcd9] (??:0)
[7] /media/ntfsevo/Utveckling/GODOT4/GoKam/GoKam/bin/libgdgokam.linux.template_debug.x86_64.so(+0x38ee0) [0x7f1789c30ee0] (??:0)
[8] /usr/bin/godot(+0x3d4444d) [0x55965b57f44d] (??:?)
[9] /usr/bin/godot(+0x2c49141) [0x55965a484141] (??:?)
[10] /usr/bin/godot(+0x2c4ca6d) [0x55965a487a6d] (??:?)
[11] /usr/bin/godot(+0x683cbc) [0x559657ebecbc] (??:?)
[12] /usr/bin/godot(+0x582f5b) [0x559657dbdf5b] (??:?)
[13] /usr/lib/libc.so.6(+0x27cd0) [0x7f178c558cd0] (??:0)
[14] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f178c558d8a] (??:0)
[15] /usr/bin/godot(+0x58fd95) [0x559657dcad95] (??:?)
-- END OF BACKTRACE --

================================================================
Steps to reproduce
Add a call to std::cout in your gdextension constructor.
Minimal reproduction project (MRP)
gdtest.zip

Does it happen if you use the helper function for it? UtilityFunctions::print("Hello World");

No crash when using UtilityFunctions::print("Hello world")
I am currently converting my cpp sources to use godot:s print function instead of std::cout, there is quite some lines and formats to change.

Can you also try with printf?

printf works. :)

Okay, thanks, for the help. I will see what I can do to limit as much as possible from std library.
I guess I am closing this now.

Also, this might be due to error handling being turned off, which it is in both the engine and godot-cpp now days, and that's another reason to avoid the standard library as it depends heavily on errors

I noticed that exceptions where not allowed aswell (error handling), as I am parsing some files and using std::stoi, which may throw things.
I added this line in SConstruct:
env.Append(CCFLAGS=["-fexceptions"])
to be able to catch exceptions.
I am using exceptions in some of my classes aswell.
I guess you want to avoid crashes and exceptions in Godot which is good, but that feels like  impossible in C++ ...
Off topic, right now I am trying to export my app to Android, but it does not work as well as I thought, even if I am compiling the Android library, and installing the app on my phone without any problems, Godot complains about my library is missing.

You need to instead add disable_exceptions=False, and build the engine yourself with the same flag, see:

https://github.com/godotengine/godot-cpp/issues/1326

This is probably what's causing this, you can't run error handling without changing these things

Thanks.
I just want to point out, not sure if I should reopen this issue.
But I am using opencv, and opencv is using the std libaries internally.
This means I will not be to use opencv with Godot at all.
This will be a major problem for.

Thats not really an issue on our end, please try with enabled exceptions, and see, but we're not able to guarantee support universally

Then I guess we are quite limited  using other libraries, hence OpenCV will not work because it is writing logs with the standard library internally.
But thanks anyway, I cannot request anything, as you are doing a create job with this awesome engine!
So we have to accept the limits ...
I can use 4.1 as for now though.
Using  disable_exceptions=false does indeed remove the exception compile errors.

Did you build the engine as well? Also are you using the correct version of godot-cpp?

But importantly: we can't (and don't) provide any guarantees of compatibility in general, but if you identify a specific issue that can be solved then you should report that
But it needs to be specific, so if you identify some specific part of the code that makes using libraries hard then please report it, but in this case do so over here

Just a note on this issue since I hadn't seen it when it came up originally:
Using std::cout shouldn't cause a GDExtension to crash, and you shouldn't have to use Godot compiled with support for exceptions in order to do so. In fact, I've so far been unable to reproduce this crash.
There seems to be some difference in the environment of users who are experiencing this crash, and we should get to the bottom of what that is.
Let's continue working on this over on this godot-cpp issue: https://github.com/godotengine/godot-cpp/issues/1326


Release chaos microsoft.chaos 2022 10 01 preview

ARM API Information (Control Plane)
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

Failing staging checks are expected - looking to get ARM api review done sooner than later.

There will be another minor change to this PR - will add ARM review tag when completed.

@jaysvoboda, is this PR ready to involve ARM team for review?

@lirenhe Yes, this can now be shared with the ARM team for review.

@lirenhe What else is needed from us to complete this PR? I tried to restart the Service API Readiness test (our RP manifest has now been updated in Eastus2euap) but I don't seem to be able to.

/azp run

Hi @jianyexi please help to review the suppression. @tadelesh could you help to take a look at the go breaking change.
@brrusino please make sure all the apis are deployed for api readiness check.

/azp run

confirmed with @brrusino  that the service is deployed to prod, and will complete rolloutting to all regions tomorrow.


How to config "Native Ingress" on minikube or IBM cloud?

I follow the guide  and got a problem.
It says that:

Additionally, we need to point the deis-builder.$host record to the public IP address of the Builder.
$ kubectl get svc deis-builder --namespace deis
NAME           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
deis-builder   <IP_ADDRESS>   <IP_ADDRESS>   2222:32488/TCP   33m

But, when i use minikube, there is no External ip for the builder. it seems like this:
$ kubectl get svc deis-builder --namespace deis
NAME           TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE
deis-builder   LoadBalancer   <IP_ADDRESS>    <pending>     2222:31972/TCP   4d

This question also exist when i use IBM cloud, on which i have to use bx cs workers < cluster-name > to get the node ip.

For minikube, this is described in the quickstart documentation: https://deis.com/docs/workflow/quickstart/provider/minikube/dns/
Also tacking on here as an FYI that Deis Workflow is no longer maintained. Please read the announcement for more detail. Because of that, I'm going to go ahead and close this issue.
Thanks!


Missing MIT license text in source repository and in published crates

The MIT license states that the copyright notice, and permission notice must be reproduced in all source and binary distributions. Since no license text appears in this repository or in the released crate, it’s not possible to easily comply with the license stated in Cargo.toml for blosc2-rs or blosc2-sys:
https://github.com/milesgranger/blosc2-rs/blob/130195455b55220956dfe0ac1c928b080cf87f43/Cargo.toml#L5
https://github.com/milesgranger/blosc2-rs/blob/130195455b55220956dfe0ac1c928b080cf87f43/blosc2-sys/Cargo.toml#L6
Please add the necessary license text, preferably in a file called LICENSE, and add a symbolic link so that it appears in the blosc2-sys crate as well (cd blosc2-sys; ln -s ../LICENSE).
This should be important for all potential users; it’s important for me so I can package these crates in Fedora Linux without guessing at the correct license text.

Quite the oversight on my end, thanks for noticing. :)

Thank you!
(This isn’t remotely the first bug of this nature I’ve filed, if that helps you feel better. 😄)


Binary operators at Striplog level

Implement stepwise binary operations for striplogs, based on Interval operators.

Have now added intersections and merging.
Can add more later if the need arises.


Dlangst

PR summary
upgrade README for new sdk-core
PR Checklist
Please make sure that your PR fulfills the following requirements:

[ ] The commit message follows the Angular Commit Message Guidelines.
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] New tests
[ ] Build/CI related changes
[ ] Documentation content changes
[ ] Other (please describe)

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x ] No

Other information

:tada: This PR is included in version 0.2.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket: