Configure server host

On Mac you get a nasty popup each time
you start it unless it listens on localhost

Pull Request Test Coverage Report for Build 790

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 90.393%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

server/server.go
0
1
0.0%

Totals

Change from base Build 788:
0.0%

Covered Lines:
1769

Relevant Lines:
1957

💛  - Coveralls

I don't remember if it was with docker on cloud foundry or plain app on cloud foundry but it doesn't work there

By default nothing changes. This takes effect only if you set the server host in the config. Otherwise it is empty, so SM will listen on all interfaces.


The four special indices are now constants.

This saves a huge amount of boilerplate: net decrease is over 100 lines.

If I understand correctly, this removes passing the 4 special indices through each method, and just calls them from the global defaults.
The only issue I can foresee is if (i) these are exposed to the CLI and (ii) someone chooses to change them (suppose for some reason  is a valid vocab item). Thoughts?
Also, this seems like a change where its easy to make a small mistake that fully breaks a rogue line of code somewhere. Did you run several architectures a for a couple steps to test for regression?

If I understand correctly, this removes passing the 4 special indices through each method, and just calls them from the global defaults.

That's right.

The only issue I can foresee is if (i) these are exposed to the CLI and (ii) someone chooses to change them (suppose for some reason <S> is a valid vocab item). Thoughts?

There is nothing stopping people from violating the "reserved symbols" we document, that's true, but that would break things both before and after this change.

Also, this seems like a change where its easy to make a small mistake that fully breaks a rogue line of code somewhere. Did you run several architectures a for a couple steps to test for regression?

Yep.

There is nothing stopping people from violating the "reserved symbols" we document, that's true, but that would break things both before and after this change.

What else would it break? Can't you say: actually the SOS token should be $S$ and we use <S> as a vocab token? This is an edge case id like to consider, but IDK if this would have actually worked before this change so dont let me hold it up.

No, there's no configurable way to change that what SOS or EOS is.
Were you to use <S> as an input symbol in your TSV files, it would map to the wrong thing. But that's clearly documented.


apps: Upgrade starboard operator and expose more options

What this PR does / why we need it:
Upgrades starboard-operator and exposes options so we can control the number of jobs it generates.
And as a bonus feature a way an option to disable it in case it causes too much problems.
Which issue this PR fixes:
Fixes #830
Fixes #583
Fixes #492
#574 and #573 might be fixed, but I'm not sure.
Public facing documentation PR (if applicable)

Special notes for reviewer:
Checklist:

[x] Added relevant notes to WIP-CHANGELOG.md
[x] Proper commit message prefix on all commits
[ ] Updated the public facing documentation
Is this changeset backwards compatible for existing clusters? Applying:

[x] is completely transparent, will not impact the workload in any way.
[ ] requires running a migration script.
[ ] will create noticeable cluster degradation.
E.g. logs or metrics are not being collected or Kubernetes API server
will not be responding while upgrading.
[ ] requires draining and/or replacing nodes.
[ ] will change any APIs.
E.g. removes or changes any CK8S config options or Kubernetes APIs.
[ ] will break the cluster.
I.e. full cluster migration is required.

Chart checklist (pick exactly one):

[ ] I upgraded no Chart.
[ ] I upgraded a Chart and determined that no migration steps are needed.
[x] I upgraded a Chart and added migration steps.

Pipeline config (if applicable)
If you change some config options (e.g. add/rename variable or change the default value) you may need to update the config used by the pipeline in pipeline/config.

LGTM!!


Add support for CentOS 9 Stream In Repo

Tell us about your request
A clear and concise description of what you want to happen or the change you would like to see
I would like to be able to add support for CentOS 9 Stream at https://download.docker.com/linux/centos/ .
Which service(s) is this request for?
Let us know which product(s) you want this for?
docker-ce
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
When I try to install docker-ce on Centos 9 Stream, it reports 404, this is because there is no such version of $releasever as 9 in the corresponding repo.
I have tried commands like the right to specify the repo on CentOS 8 Stream, and I used the --nobest parameter of yum to keep the program running (yes, even on Centos 9 Stream,   yum keyword is still preserved), i.e. sed -i 's/$releasever/8/g' /etc/yum.repos.d/docker-ce.repo.
This was followed by a tentative sudo yum install --nobest docker-ce docker-ce-cli containerd.io step, which unfortunately failed (please ignore the Chinese, in fact I'm not sure of its English counterpart, So I didn't do the translation)
[root@localhost ~]# sudo yum install --nobest  docker-ce docker-ce-cli containerd.io
上次元数据过期检查：0:02:06 前，执行于 2022年01月13日 星期四 21时14分11秒。
 Apparently the libcgroup package is an outdated component on RHEL and CentOS.
Are you currently working around the issue?
A clear and concise description of any alternative solutions or features you've considered or are using today.
Honestly I don't know how to fix it, it looks like Docker depends on libcgroup. I linked from another post.  https://github.com/docker/docker.github.io/issues/13792
Additional context
Add any other context or screenshots about the feature request here.

Base on using centos 8-strem's repo, e.g.
curl https://download.docker.com/linux/centos/docker-ce.repo -o /etc/yum.repos.d/docker-ce.repo
sed -i 's/$releasever/8/g' /etc/yum.repos.d/docker-ce.repo
dnf install docker-ce -y # error, reporting ' nothing provides libcgroup needed by docker-ce-3:20.10.12-3.el8.x86_64'

As there is no libcgroup in centos 9-stream's repo, uses the pkg in centos 8-stream's repo instead for now.
dnf install wget -y
wget http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/libcgroup-0.41-19.el8.x86_64.rpm # download into current directory
dnf install libcgroup-0.41-19.el8.x86_64.rpm -y # install the package
dnf install docker-ce -y # now, it won't report lack of the dependecy  `libcgroup`

systemctl enable --now docker

After install::
[root@localhost ~]# cat /etc/centos-release # just show my os version
CentOS Stream release 9
[root@localhost ~]# docker version # check docker installation and its version
Client: Docker Engine - Community
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:45:22 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:44 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.12
  GitCommit:        7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

@EeeMt Thanks for your answer!
Although the documentation for Centos 9 Stream is not yet finished (as stated in https://lists.centos.org/pipermail/centos-devel/2021-November/077450.html), I noticed that due to Centos 9 Stream As upstream of RHEL 9, RHEL 9 documentation has a note on this. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html/considerations_in_adopting_rhel_9/assembly_changes -to-packages_considerations-in-adopting-rhel-9#removed-packages_assembly_changes-to-packages mentions that libcgroup as part of Removed packages no longer exists. Maybe docker-ce should remove the reference to  dependency of libcgroup ? The documentation for this component has been marked as obsolete as of RHEL 7 at the latest (as stated in https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/resource_management_guide/chap-using_libcgroup_tools ).

I have the same issue. But this installation of libcgroup and usage of CentOS 8 repo is only a temporary solution, right?

I have the same issue. But this installation of libcgroup and usage of CentOS 8 repo is only a temporary solution, right?

If anyone on the official panel can reply, this is clearly not the correct way to install it - it has been noticed but doesn't seem to have gone any further. At least containerd.io has an RPM package for RHEL 9 and is available on CentOS 9 Stream.

The fix described here did not work for me on a fresh CentOS 9 Stream install:
[root@localhost ~]# cat /etc/centos-release # just show my os version
CentOS Stream release 9

Follow all the steps described by @EeeMt until the last step:
[root@localhost ~]# dnf install docker-ce
Docker CE Stable - x86_64                                                                                54 kB/s |  19 kB     00:00
Error:
 Problem: problem with installed package buildah-1.24.0-0.15.el9.x86_64
  - package buildah-1.24.0-0.15.el9.x86_64 requires runc >= 1.0.0-26, but none of the providers can be installed
  - package buildah-1:1.24.1-1.el9.x86_64 requires runc >= 1.0.0-26, but none of the providers can be installed
  - package containerd.io-1.4.3-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.3-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.3-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.3-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - package docker-ce-3:20.10.12-3.el8.x86_64 requires containerd.io >= 1.4.1, but none of the providers can be installed
  - package containerd.io-1.4.3-3.2.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.3-3.2.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.3-3.2.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.3-3.2.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.10-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.10-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.11-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.11-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.12-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.12-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.4-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.4-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.6-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.6-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.8-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.8-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.9-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.4.9-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - cannot install the best candidate for the job
  - package containerd.io-1.4.4-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.4-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.6-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.6-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.8-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.8-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.9-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.9-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.10-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.10-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.11-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.11-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.12-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.4.12-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

The --nobest does not solve this issue either.

Following the instructions at nvidia for installing docker on CentOS 8:

Since CentOS does not support specific versions of containerd.io packages that are required for newer versions of Docker-CE, one option is to manually install the containerd.io package and then proceed to install the docker-ce packages.

sudo dnf install -y https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.4.3-3.1.el7.x86_64.rpm
sudo dnf install docker-ce -y

And then check the version.
[root@localhost ~]# docker version # check docker installation and its version
Client: Docker Engine - Community
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:45:22 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:44 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

You may also have to remove buildah and podman before using docker-ce to resolve the runc conflict.

In my previous tests, buildah and Podman were not installed if the minimum installation mode was selected when initializing CentOS 9 Stream, perhaps something has changed in later versions.

I have the same issue.

You may also have to remove buildah and podman before using docker-ce to resolve the runc conflict.

In my previous tests, buildah and Podman were not installed if the minimum installation mode was selected when initializing CentOS 9 Stream, perhaps something has changed in later versions.

You are correct, it depends what installation options are selected. I did not select minimum installation because I need other things!

I am also unable to install Docker on CentOS Stream 9.  Would love to be able to!
[root@ce-cl-evt2-01-node03-jrgruher docker]# sudo dnf install -y https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.4.3-3.1.el7.x86_64.rpm
Last metadata expiration check: 0:36:39 ago on Thu 07 Apr 2022 09:59:08 AM PDT.
containerd.io-1.4.3-3.1.el7.x86_64.rpm                                                                                66 MB/s |  33 MB     00:00
Dependencies resolved.
========================================================================================================================================================
 Package                               Architecture                   Version                                Repository                            Size
========================================================================================================================================================
Installing:
 containerd.io                         x86_64                         1.4.3-3.1.el7                          @commandline                          33 M
     replacing  runc.x86_64 3:1.1.0-2.el9

Transaction Summary
========================================================================================================================================================
Install  1 Package

Total size: 33 M
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                1/1
  Installing       : containerd.io-1.4.3-3.1.el7.x86_64                                                                                1/2
  Running scriptlet: containerd.io-1.4.3-3.1.el7.x86_64                                                                                1/2
  Obsoleting       : runc-3:1.1.0-2.el9.x86_64                                                                                2/2
  Running scriptlet: runc-3:1.1.0-2.el9.x86_64                                                                                2/2
  Verifying        : containerd.io-1.4.3-3.1.el7.x86_64                                                                                1/2
  Verifying        : runc-3:1.1.0-2.el9.x86_64                                                                                2/2

Installed:
  containerd.io-1.4.3-3.1.el7.x86_64

Complete!
[root@ce-cl-evt2-01-node03-jrgruher docker]# sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
Adding repo from: https://download.docker.com/linux/centos/docker-ce.repo
[root@ce-cl-evt2-01-node03-jrgruher docker]# vim /etc/yum.repos.d/docker-ce.repo
[root@ce-cl-evt2-01-node03-jrgruher docker]# dnf install install docker-ce docker-ce-cli containerd.io\
> ^C
[root@ce-cl-evt2-01-node03-jrgruher docker]# dnf install install docker-ce docker-ce-cli containerd.io
Docker CE Stable - x86_64                                                                                29 kB/s | 3.5 kB     00:00
No match for argument: install
Package containerd.io-1.4.3-3.1.el7.x86_64 is already installed.
Error: Unable to find a match: install
[root@ce-cl-evt2-01-node03-jrgruher docker]# dnf install docker-ce docker-ce-cli containerd.io
Last metadata expiration check: 0:00:11 ago on Thu 07 Apr 2022 10:36:47 AM PDT.
Package containerd.io-1.4.3-3.1.el7.x86_64 is already installed.
Error:
 Problem 1: cannot install the best candidate for the job
  - nothing provides libcgroup needed by docker-ce-3:20.10.14-3.el8.x86_64
 Problem 2: problem with installed package podman-2:4.0.2-3.el9.x86_64
  - package podman-2:4.0.2-3.el9.x86_64 requires runc >= 1.0.0-57, but none of the providers can be installed
  - package podman-1:3.4.3-0.6.el9.x86_64 requires runc >= 1.0.0-57, but none of the providers can be installed
  - package podman-2:3.4.5-0.7.el9.x86_64 requires runc >= 1.0.0-57, but none of the providers can be installed
  - package podman-2:4.0.0-6.el9.x86_64 requires runc >= 1.0.0-57, but none of the providers can be installed
  - package podman-2:4.0.2-2.el9.x86_64 requires runc >= 1.0.0-57, but none of the providers can be installed
  - package containerd.io-1.4.3-3.1.el7.x86_64 conflicts with containerd provided by containerd.io-1.5.11-3.1.el8.x86_64
  - package containerd.io-1.5.11-3.1.el8.x86_64 conflicts with runc provided by containerd.io-1.4.3-3.1.el7.x86_64
  - package containerd.io-1.5.11-3.1.el8.x86_64 conflicts with containerd provided by containerd.io-1.4.3-3.1.el7.x86_64
  - cannot install both containerd.io-1.5.11-3.1.el8.x86_64 and containerd.io-1.4.3-3.1.el7.x86_64
  - package containerd.io-1.5.11-3.1.el8.x86_64 conflicts with runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.5.11-3.1.el8.x86_64 obsoletes runc provided by runc-2:1.0.0-332.dev.gitbd013b6.el9.x86_64
  - package containerd.io-1.5.11-3.1.el8.x86_64 conflicts with runc provided by runc-3:1.1.0-2.el9.x86_64
  - package containerd.io-1.5.11-3.1.el8.x86_64 obsoletes runc provided by runc-3:1.1.0-2.el9.x86_64
  - cannot install the best candidate for the job
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root@ce-cl-evt2-01-node03-jrgruher docker]# dnf install --nobest docker-ce docker-ce-cli containerd.io
Last metadata expiration check: 0:00:25 ago on Thu 07 Apr 2022 10:36:47 AM PDT.
Package containerd.io-1.4.3-3.1.el7.x86_64 is already installed.
Error:
 Problem: conflicting requests
  - nothing provides libcgroup needed by docker-ce-3:19.03.13-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:19.03.14-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:19.03.15-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.0-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.1-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.10-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.11-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.12-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.13-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.14-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.2-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.3-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.4-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.5-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.6-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.7-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.8-3.el8.x86_64
  - nothing provides libcgroup needed by docker-ce-3:20.10.9-3.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

same issues

same issue

This worked for me.
dnf remove -y runc
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
vi /etc/yum.repos.d/docker-ce.repo -> Under `[docker-ce-stable]` change `$releasever` -> `8`
wget https://kojihub.stream.centos.org/kojifiles/packages/libcgroup/0.42.2/5.el9/x86_64/libcgroup-0.42.2-5.el9.x86_64.rpm
rpm -Uvhi libcgroup-0.42.2-5.el9.x86_64.rpm
dnf install docker-ce --nobest -y
systemctl enable --now docker

sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

@fqlx that's workaround - just different version than one above.

Hi,
FYI, since some hours, docker 20.10.15 is shipped with CentOS 9 packages.
People who try to co-install both podman and docker will still have the runc vs containerd issue, which is yet to be fixed by a pull request like https://github.com/docker/containerd-packaging/pull/272.
So I would say this issue can be closed now.
Cheers,
Romain

10:21 (s) marcin@puchatek:~$ drun --pull -v$PWD:/tmp/test quay.io/centos/centos:stream9
[root@a68405892eaa /]# cd /etc/yum.repos.d/
[root@a68405892eaa yum.repos.d]# wg^C
[root@a68405892eaa yum.repos.d]# curl https://download.docker.com/linux/centos/docker-ce.repo >docker-ce.repo
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1919  100  1919    0     0  15601      0 --:--:-- --:--:-- --:--:-- 15601
[root@a68405892eaa yum.repos.d]# dnf install docker-ce
CentOS Stream 9 - BaseOS                                                                        578 kB/s | 5.6 MB     00:09
CentOS Stream 9 - AppStream                                                                     5.5 MB/s |  13 MB     00:02
CentOS Stream 9 - Extras packages                                                                12 kB/s | 8.0 kB     00:00
Docker CE Stable - x86_64                                                                        18 kB/s | 4.8 kB     00:00
Dependencies resolved.
================================================================================================================================
 Package                                  Architecture       Version                         Repository                    Size
================================================================================================================================
Installing:
 docker-ce                                x86_64             3:20.10.15-3.el9                docker-ce-stable              21 M
Installing dependencies:
 checkpolicy                              x86_64             3.3-1.el9                       appstream                    339 k
 container-selinux                        noarch             3:2.183.0-1.el9                 appstream                     47 k
 containerd.io                            x86_64             1.6.4-3.1.el9                   docker-ce-stable              32 M
 diffutils                                x86_64             3.7-12.el9                      baseos                       397 k
 docker-ce-cli                            x86_64             1:20.10.15-3.el9                docker-ce-stable              29 M
 docker-ce-rootless-extras                x86_64             20.10.15-3.el9                  docker-ce-stable             3.8 M
 docker-scan-plugin                       x86_64             0.17.0-3.el9                    docker-ce-stable             3.6 M
 fuse-common                              x86_64             3.10.2-5.el9                    baseos                       9.0 k
 fuse-overlayfs                           x86_64             1.8.2-1.el9                     appstream                     72 k
 fuse3                                    x86_64             3.10.2-5.el9                    appstream                     54 k
 fuse3-libs                               x86_64             3.10.2-5.el9                    appstream                     93 k
 iptables-libs                            x86_64             1.8.7-28.el9                    baseos                       470 k
 iptables-nft                             x86_64             1.8.7-28.el9                    baseos                       204 k
 kmod                                     x86_64             28-7.el9                        baseos                       127 k
 libibverbs                               x86_64             37.2-1.el9                      baseos                       376 k
 libmnl                                   x86_64             1.0.4-15.el9                    baseos                        29 k
 libnetfilter_conntrack                   x86_64             1.0.8-4.el9                     baseos                        58 k
 libnfnetlink                             x86_64             1.0.1-21.el9                    baseos                        30 k
 libnftnl                                 x86_64             1.1.9-4.el9                     baseos                        85 k
 libnl3                                   x86_64             3.6.0-1.el9                     baseos                       348 k
 libpcap                                  x86_64             14:1.10.0-4.el9                 baseos                       173 k
 libselinux-utils                         x86_64             3.3-2.el9                       baseos                       181 k
 libslirp                                 x86_64             4.4.0-4.el9                     appstream                     69 k
 policycoreutils                          x86_64             3.3-5.el9                       baseos                       233 k
 policycoreutils-python-utils             noarch             3.3-5.el9                       appstream                     74 k
 python3-audit                            x86_64             3.0.7-102.el9                   appstream                     84 k
 python3-libselinux                       x86_64             3.3-2.el9                       appstream                    183 k
 python3-libsemanage                      x86_64             3.3-2.el9                       appstream                     81 k
 python3-policycoreutils                  noarch             3.3-5.el9                       appstream                    2.1 M
 python3-setools                          x86_64             4.4.0-4.el9                     baseos                       600 k
 python3-setuptools                       noarch             53.0.0-10.el9                   baseos                       946 k
 rpm-plugin-selinux                       x86_64             <IP_ADDRESS>-11.el9                 baseos                        21 k
 selinux-policy                           noarch             34.1.30-2.el9                   baseos                        61 k
 selinux-policy-targeted                  noarch             34.1.30-2.el9                   baseos                       6.7 M
 slirp4netns                              x86_64             1.1.12-4.el9                    appstream                     45 k
 xz                                       x86_64             5.2.5-7.el9                     baseos                       226 k

Transaction Summary
================================================================================================================================
Install  37 Packages

Total download size: 105 M
Installed size: 429 M
Is this ok [y/N]:```

Looks like the problem is solved, can the issue be closed? (Installing podman and Docker at the same time is not one of the problems of this issue)

yup! let's close this one

centos 9 strema run docker exec -it nginx bash is not good
error:
OCI runtime exec failed: exec failed: unable to start container process: open /dev/pts/0: operation not permitted: unknown

centos 9 strema run docker exec -it nginx bash is not good error: OCI runtime exec failed: exec failed: unable to start container process: open /dev/pts/0: operation not permitted: unknown

@zhouwencn

I prefer to believe that this issue should be discussed in https://github.com/docker/containerd-packaging/pull/272, in fact this issue does not discuss this.

ok, thanks for your guide,i look look


Rebase makes title and diff different

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
docker
Package manager version
No response
Language version
No response
Manifest location and content before the Dependabot update
No response
dependabot.yml content
https://github.com/nwtgck/piping-server/blob/a539b15922fa729ea531b7d5228fe5d0877c5201/.github/dependabot.yml
Updated dependency
No response
What you expected to see, versus what you actually saw
Here is the actual title and diff.

https://github.com/nwtgck/piping-server/pull/727/files
As you can see, the titile says "16.18.0-alpine" but the diff shows "19.0.0-alpine".
Before "@dependabot rebase", the title and the diff was correct: https://github.com/nwtgck/piping-server/commit/339d999edf077e4065c78974d409a98b02e2b648.
https://github.com/dependabot/dependabot-core/issues/5890 might be related.
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response

👋 Sorry for the slow reply.
This is clearly a bug, but it'd most likely be in our back-end infra, not the code here in dependabot-core. Unfortunately at this point the logs are long-gone and it will be hard to recreate exactly what happened given that this only happened on a @dependabot rebase, and the node version is newer, and also I see newer PR's getting opened correctly on your repo:

https://github.com/nwtgck/piping-server/pull/736

So if you see it again, please file a an issue or comment on this one with an example and we can re-open... we'd need to jump on it fairly quickly to debug what exactly happened... we try to do that but no guarantees if we're in the middle of a ship and no one has cycle to debug, but generally we do try to reserve a little slack across the team to investigate race conditions in the back end for stuff like this.
Sorry I can't be more helpful.


the green spectum is behind the modal

https://user-images.githubusercontent.com/103120356/184603115-ae4aea62-291c-4098-8e17-f3d94046e135.mp4

You can set in your custom css something like this.
#pspectrum-visualizer {
  z-index: 10; /* or something else */
}

If not, please send me your theme.

#pspectrum-visualizer {
  z-index: 10; /* or something else */
}

nope doesnt work

You can set in your custom css something like this.
#pspectrum-visualizer {
  z-index: 10; /* or something else */
}

If not, please send me your theme.

https://github.com/CreArts-Community/CreArts-Discord

resolved via DM


Update metaconfig-typesafe-config to 0.11.0

Updates com.geirsson:metaconfig-typesafe-config from 0.10.0 to 0.11.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (0.10.0).
You might want to review and update them manually.
mill
mill.bat
millw
modules/integration/src/test/scala/scala/cli/integration/ExportTestProjects.scala

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.geirsson", artifactId = "metaconfig-typesafe-config" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.geirsson", artifactId = "metaconfig-typesafe-config" }
}]

labels: library-update, early-semver-major, semver-spec-minor, old-version-remains, commit-count:1

Superseded by #1254.


Feature: Create #claudie channel on Kubernetes Slack workspace

Motivation
Create a # claudie channel on the Slack workspace. As the Kubernetes workspace community is large, this might be beneficial for the project itself and its adoption.
Description
Read the community rules and create # claudie channel on the Kubernetes Slack workspace accordingly.
Exit criteria

[x] Claudie channel is created
[ ] Links are updated
[ ] Claudie workspace is deleted

PR for creating #claudie channel is opened. We are in the middle of the process of signing Corporate CLA.
After signing, there is a need to add comment with /easycla in PR

Three weeks ago I assigned a guy from k8s community to give a review on the PR. A minute ago I have pinged him in the comment and ask, whether he can give it a review (following escalations practices).

The links were updated in infra and claudie repository


Does the graph coloring uses greedy coloring method?

Yes. Coloring uses greedy coloring method.  You may look it here: https://github.com/UnickSoft/graphonline/blob/master/script/plugins/Coloring.js

@UnickSoft So how is the chromatic number given? I could not find anything in the documentation, sorry

You may look Greedy coloring on wiki: https://en.wikipedia.org/wiki/Greedy_coloring
We use the same algorithm, but we use many different ordering and choose the best variant with minimal number color.


Awaitable::when without a loop running

We have to discuss what should happen when Awaitable::when is called without a Loop running and throws an exception.

I think this is a rare enough case which does not need special handling and shall just be handled normally (i.e. Loop::defer() call).
We also might declare that behavior as undefined and have implementations deal with the case.
I like the option of undefined behavior here as it allows libraries to invoke smarter behavior (like registering a shutdown callback to have the exception surface up in any case, if the deferred callback never gets invoked).

We also might declare that behavior as undefined and have implementations deal with the case.

No, I'd clearly define that, so when does never throw.

I like the option of undefined behavior here as it allows libraries to invoke smarter behavior (like registering a shutdown callback to have the exception surface up in any case, if the deferred callback never gets invoked).

We could mention that as specifically allowed.
I actually have a use case for a when outside of the loop now. But it invokes wait later again, so the exception will appear then. If anyone is interested, I can go into more detail.

Yes, that when() never throws directly upon being called, should be defined.
Whether the exception will be sometime thrown (i.e. when loop is discarded, script execution exited) or not, shall be implementation defined.
Also, you're welcome to show your use case. I've not been yet able to think of a concrete one.

We have an ID and fetch images. We want to fetch from two services and compare the results, because may want to switch to the other service.
$promise = $client->fetch("https://example.com/id/{$id}");
$promiseNew = $client->fetch("https://example.net/id/{$id}");

$response = wait($promise);
// send content-length header + content and flush

$responseNew = wait($promiseNew);

It's now easy to be in the situation that you want to log something when $promiseNew resolves and add something like $promiseNew->when(...) before wait($promiseNew) and $promiseNew might be already resolved.
Of course, you can always log it after wait($promiseNew), but it's too easy to put it in front and that shouldn't matter. Using ->when in front can have e.g. the advantage of not needing a try / catch / finally but executing the wanted code independently.

Closing as the PR had been merged.


No Zone Found

I've just tried updating my Cloudflare's IP address using the web page https://ddnslab.tech/ and I get an error message 'NO ZONE FOUND'.
I've followed your guide exactly, creating the api token, and have used the domain name which is shown against the A record.

Please verify the token permissions

It's OK to close. I waited 10 days but no reply to this issue, so have now found another solution.


Create Tag for v0.4.0

Please create a Tag for 0.4.0 version. CocoaPods can't see this version with Swift 3 update.

Already create a 0.4.0 tag


Request markdown

fixes #2 by adjusting text area sizes and #5 by requesting markdown explicitly
Further I included automatic publishing to npm via github actions pipeline

Just, FYI, CSS stores markdown files as foo$.markdown.

Just, FYI, CSS stores markdown files as foo$.markdown.

That might be true, if you PUT or POST Content-Type: text/markdown without a file ending. But the markdown page actuallyl PUTs them with .md file ending, and they get stored like that.
If you are pointing out, that the markdown-pane will not show up, for a markdown rescource internally stored as foo$.markdown (because it has no file ending to the outside), you are correct. We could improve that in another PR like described in my above comment.

Just, FYI, CSS stores markdown files as foo$.markdown.

Are you sure @jeff-zucker it should be foo.md or foo$.md ?


[cli][tests] adding mocking for firehose output

to: @javuto
cc: @airbnb/streamalert-maintainers
size: small
resolves N/A
Background
Rule tests that were run with python manage.py lambda test -p all would fail for any rules that were using firehose outputs with an error similar to:
ResourceNotFoundException: An error occurred (ResourceNotFoundException) when calling the PutRecord operation: Stream airbnb_streamalert_alert_delivery under account<PHONE_NUMBER>12 not found.

Changes

Adding mocking support for AWS firehose output

Testing
Added a firehose output for rules and ran tests successfully.

Coverage remained the same at 95.687% when pulling 268ec10c19815b5877975d57f91d8abc66ce83a1 on ryandeivert-mock-firehose-tests into 0adf349578611b834ebc14d504191ed8bb8491ad on master.

Thanks for fixing this!


Make kernel logs accessible for seed machines.

How to categorize this issue?

/area logging
/area ops-productivity
/kind enhancement
/priority normal
What would you like to be added: Currently MCM replaces the unhealthy machines after a default timeout of 10mins. A machine is considered unhealthy when either of the following node-conditions sets to True KernelDeadlock, FilesystemReadOnly, DiskPressure, or KubeletReady to false.
Lately, most of the time, we have been seeing machines being replaced due to the Kubelet stopped posting status issue, and rarely any other node-conditions. This doesn't tell us much about the actual root-cause, and as the machine is already gone, we also don't have much to investigate on.
We must know why the kubelet or other components stops working, specifically/at-least for the seed worker-machines, as they host the critical workload. Currently, Grafana in seed machines does expose kubelet logs, but it might not always be sufficient if the process was abruptly killed for some reason.
Opening this issue to discuss if we can also fetch more logs from the seed-machines.

For example, NPD simply watches the /dev/kmsg to set the node-conditions. We could store these logs for our references.

Why is this needed: For better observability of the seed machines, and if there is a scope of improvement from MCM or cloud-provider.

Sounds reasonable, we will do this.
Thanks for the issue :)

thanks @Kristian-ZH .
@vlvasilev mentioned there is also a plugin for the kernel-logs in fluent-bit.
I see this, https://docs.fluentbit.io/manual/pipeline/inputs/kernel-logs , probably useful.

/assign @Kristian-ZH @vlvasilev

I did some investigation and tests and it seems that the fluent-bit kmsg plugin does not work without mounting the device /dev/kmsg. As I see the only way to mount a device is to use the Kubernetes Device Plugin which we have to write on our own and deploy it as DaemonSet. I have tried to use the 'tail' plugin but without any result. It looks like the 'tail' plugin does not read from /dev directory.

Then we should consider how much time we will need for this change and will add this in our backlog

As the communication stopped for this PR, we can close the issue
/close


GestureDetectorCompat stopped working.

My GestureDetectorCompat stopped working.

Please explain in more detail what's broken, and how it's related to the library.


Forgot to call Viktor

CategoryPaginationURLs.php has get_taxonomies( $args, 'objects' ); which is not recognized by PHPStan.
Please call me, do not add it to ignoreErrors!

Haha, indeed! I still need to follow up with you with the great effort you put into leonstafford/simplerstatic - but I fell into months of depression/unproductivity and felt bad that it's taking so long!
I'll get onto this and report back (just can't promise how soon!).
Hope all is well for you.
Köszönöm!

A release for you, Leon.
https://github.com/szepeviktor/phpstan-wordpress/releases/tag/v0.6.5


Make it cheaper to spawn isolates with overlapping code to the current isolate

If we are spawning isolate which will include imports to the same libraries that are already loaded in the VM it would be nice to not pay the cost all over again to parse the Dart source.
This will be especially useful for package:test where we spawn an Isolate for each VM test we run.
cc @mraleph

Currently when creating new isolates we transparently parse Dart source code into Kernel using DFE isolate - without sharing or preserving any state between compilation requests.
@jensjoha work on Flutter test setup shows that significant performance improvement can be achieved by preserving the state between compilation requests.
I wonder if we can make it work for package:test too - maybe we need to extend spawnUri API.
/cc @lrhn

The way spawn and spawnUri have so far been defined (but not necessarily implemented), the spawn function must run exactly the same code as the spawning isolate. It's an error to re-load/fetch any source if that allows it to change.
For spawnUri, there is no such requirement, and fetching the source again is allowed, but not required. You can do all the caching you would want. It's somewhat rare that the entry-point library already exists in the spawning isolate (then you could probably just have used spawn), but not so unlikely to share utility libraries.
I don't see what changes the spawnUri method would be beneficial here.

@lrhn currently VM completely discards CFE state between URI loading requests because it has no way of knowing whether there will ever be another URI loading request that might benefit from the cached state - and discarding the state frees significant chunk of memory. So the change we could do to spawnUri is to add a way to hint to the VM that it should not discard the state - because another request is likely. This is one approach.
Another approach is to change package:test to explicitly depend on the CFE and explicitly manage its compilation requests just like flutter test does.

My understanding is we want to remove having to understand compilation pipelines from package:test, not further complicate it :) ... I think @natebosch has considered supporting the CFE as part of the build system, WDUT?

we might not be able to get away from having an understanding of the CFE from within package:test
Running VM tests is explicitly depending on running from source. Paying the parsing costs for every test file is going to be a terrible experience for our users. We'd either need to make everyone go through build_runner to run tests, or teach the test package about the CFE.
Based on my understanding of what flutter is doing I don't think it would be terribly costly to implement. The cost comes in when we think about version constraints. Flutter is pinned to an SDK, package:test is not.

/cc @a-siva
@a-siva @mraleph who's the right person to own this?

@dgrove
First we need consensus how to implement it:

teach package:test to use package:front_end like Flutter does. might require expanding Isolate spawn APIs to spawn Isolates from dill files. Should probably be jointly owned by CFE team and Nate.
expand spawnUri API to communicate to the DFE service that it needs to preserve the state of CFE in memory. Should probably be owned by CFE/VM team and Lasse.

I think solution number 1 is preferable because extending spawnUri in a flexible and future proof way is hard.

Self-assigning until we get consensus on what to implement.

I'm not familiar with how Flutter uses package:front_end. @mraleph can you easily expand on option 1? If not we can set some time up over GVC to discuss it in detail.

If someone can share a link to the flutter test code using this pattern we can build a prototype in package:test and evaluate it's feasibility.

@natebosch @grouma the logic is in this file.
Each test is compiled using persistent compiler here and then run using flutter_tester process here.
Let me know if you need any help. Another person to chat with might be @aam.

Yes, happy to help, but am picking something from the earlier responses where @lrhn wrote:

The way spawn and spawnUri have so far been defined (but not necessarily implemented), the spawn function must run exactly the same code as the spawning isolate. It's an error to re-load/fetch any source if that allows it to change.

Not sure what scenario last statement in the quote refers to. For spawn are we prohibiting hot-reload for spawned and/or spawning isolates?

I was not referring to "hot reload", merely saying that Isolate.spawn should effectively run exactly the same source in both spawning and spawned isolate. The spawn operation should not fetch any source code from a file or a web server, since it isn't guaranteed to get the same source again.
What you do with hot-reload during development is not covered by the language or library specifications, it's just a best-effort attempt to avoid restarting the program from scratch.

Tried to take a look at this today. We need to wait for the next SDK release as we are blocked by https://github.com/dart-lang/sdk/issues/32950.

#32950 is fixed now, @grouma . Are you able to take another look?

@grouma ping.

Direct integration with front_end from test is not an approach we are pursuing today. We're focusing on a modular compilation to kernel and we'll be testing the performance of a modular kernel approach for flutter test as well.

Can this be moved from Dart2Stable ?

This should not be a blocker for Dart 2 stable. I think this is still worth exploring a solution directly in the VM in a future milestone. Pushing complexity on every consumer of the spawnUri API in order to work around performance issues that could be solved once seems better in the long term than having many potential consumers of package:front_end.

@natebosch only the caller of the spawnUri knows if the spawned Uri is going to be related in any way to other Uri-s that has been spawned before. What we need here is an ability to communicate to CFE instance within the VM that you are expecting to have an intersection between what it compiled before and what it is going to compile in the future.
Unconditionally keeping CFE state around would double the memory overhead - so we can't just do that to sometimes make some subsequent spawnUri-s faster.
We could optionally extend some of the APIs to communicate the need to persist the CFE state (as I mentioned in my comment above).
But I am not sure VM itself would benefit from such complexity.
To be honest I would prefer we entirely remove spawnUri that allows one to spawn isolates from raw Dart sources.

Some additional usage info on spawnUri: we use it often in CLI tools to generate and run scripts within the context of a dependent application. For example, aqueduct serve generates a script that imports the Dart application package in current working directory and starts the application defined by a type located in that package.
If it aids the conversation, this package is a minimal implementation of this technique (and is what is used by these CLI tools).


"npm install iobroker.mihome-vacuum" does not work

tried to install this way but continiously  get error "'iobroker.mihome-vacuum' is not in the npm registry."
Please check. Thanks

Just now it must be installed from git. Because the complex codes finding I
am thinking about if it should be on npm or not.
npm i https://github.com/ioBroker/ioBroker.mihome-vacuum/tarball/master
5 Фев 2017 г. 16:52 пользователь "virgin09"<EMAIL_ADDRESS>написал:

tried to install this way but continiously get error
"'iobroker.mihome-vacuum' is not in the npm registry."
Please check. Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ioBroker/ioBroker.mihome-vacuum/issues/1, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEXqgPzqxGge-N7ES6UOu_TBdsus8D4wks5rZfBZgaJpZM4L3iFq
.

ok, thanks


antsimulator: 1.2 -> 3.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/johnBuffer/AntSimulator/releases.
meta.description for antsimulator is: "Simple Ants simulator"
meta.homepage for antsimulator is: "https://github.com/johnBuffer/AntSimulator"
meta.changelog for antsimulator is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

Warning: no invocation of /nix/store/3jvbj5i0g1br5m5d9khzb73yyzbkx32a-antsimulator-3.1/bin/antsimulator had a zero exit code or showed the expected version

0 of 1 passed binary check by having a zero exit code.

0 of 1 passed binary check by having the new version present in output.

found 3.1 with grep in /nix/store/3jvbj5i0g1br5m5d9khzb73yyzbkx32a-antsimulator-3.1

found 3.1 in filename of file in /nix/store/3jvbj5i0g1br5m5d9khzb73yyzbkx32a-antsimulator-3.1

directory tree listing: https://gist.github.com/75fc2b4630f8756d0e5fb1b22eb2c85b

du listing: https://gist.github.com/dc4a8c620aadb9fb2276086a11b2b44f

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
antsimulator

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/3jvbj5i0g1br5m5d9khzb73yyzbkx32a-antsimulator-3.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A antsimulator https://github.com/r-ryantm/nixpkgs/archive/07ebaed9748fa97ccf3784b88193076211d2c865.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/3jvbj5i0g1br5m5d9khzb73yyzbkx32a-antsimulator-3.1
ls -la /nix/store/3jvbj5i0g1br5m5d9khzb73yyzbkx32a-antsimulator-3.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

antsimulator

Maintainer pings
cc @IvarWithoutBones for testing.

Result of nixpkgs-review pr 133362 at 07ebaed9 run on x86_64-linux 1

1 package built successfully:

antsimulator

1 suggestion:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/games/antsimulator/default.nix:17:3:
   |
17 |   installPhase = ''
   |   ^


How to use one GPU for training.

Hello, how can I use only one GPU for training this model?

You just need to change "--nproc_per_node" from 8 to 1 when you run the train.py.


lnd_test: Prevent calling Fatal in goroutine

This commit prevents an error that I've seen on travis,
wherein the test fails because a call to Fatal happens
after the test finishes. The root cause is that we call
Fatal in a goroutine that is reading from the subscribe
graph rpc call.
To fix this, we now pass an err chan back into the main
test context, where we can receive any errors and fail
the test if one comes through.

Needs rebase, then is mergeable!

heh, that was one hell of a merge conflict


Document Rotation

Are you able to rotate a already loaded PDF document? I cannot seem to find any function for this inside of the code.

Thanks for the suggestion. This has been implemented and I've pushed a new version to NuGet with this functionality. Because of limitations in the Pdfium library, or my understanding of it, rotating the output does degrade performance. Please let me know if the performance impact is such that it needs to be addressed. If so, please create a new ticket for this.


Error Message in Rhino Console: The file or assembly "file:///C:\Users\vnk\AppData\Roaming\Grasshopper\Libraries\jswan.gha" or a dependency on it was not found. The operation is not supported. (HRESULT exception: 0x80131515)

jSwan Plug-In is not appering in Grasshopper

Hi tommy,
I joined to GitHub today and I saw your post.
This issue happens to me too.
You can solve this problem by following step.

Go to %AppData%\Roaming\Grasshopper\Libraries
Right click jswan.gha
I think you can see some option about block or release at bottom of the window.
Release it
Then start Rhino & Grashopper!

I hope this help you. (Although 4 month passed from your post....)

Yes @kenjiiimura is correct: be sure to right click the GHA and unblock.


In 2.0.1 in azs.fabric.admin Disable-AzsScaleUnitNode kicks off ScaleUnitNodesStopMaintenanceMode, while EnableAzsScaleUnitNode kicks off ScaleUnitNodesStartMaintenancemode

In 2.0.1 in azs.fabric.admin Disable-AzsScaleUnitNode kicks off ScaleUnitNodesStopMaintenanceMode, while EnableAzsScaleUnitNode kicks off ScaleUnitNodesStartMaintenancemode, so the cmdlets appear to be switched

Thank you!

@LingyunSu The issue is in the renaming of the cmdlets in the readme.md here https://github.com/Azure/azurestack-powershell/blob/master/src/Azs.Fabric.Admin/readme.md Disable should do Start-MaintenanceMode, not Stop-MaintananeMode

Issue fixed. PR:
https://github.com/Azure/azurestack-powershell/issues/23

New PR: https://github.com/Azure/azurestack-powershell/pull/28

The release is out
https://github.com/Azure/azurestack-powershell/releases/tag/v2.0.2-preview


Update outdated picture for "Configuring the private fork policy for a repository"

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks
What part(s) of the article would you like to see updated?
The picture under  Step 4 "Under Fork pull request workflows, select your options. For example:" contains an option to make repository secrets available to fork PR workflows, when this is no longer an option. Confusing.
Additional information
Here is another doc that makes clear this is no longer an option.
I stumbled on this confusing mismatch because tests are failing since the secrets aren't available for a contributor's PR.

Thanks so much for opening an issue! I'll triage this for the team to take a look :eyes:

@oraclown - many thanks for reporting this bug in the docs. It sounds as if we overlooked this article the last time the UI was revised. I'm going to check our internal issues to see whether any other articles are affected before recommending steps to fix this problem.

@oraclown - I asked about this and discovered that the procedure you mention is only available for private repositories and not public repositories. The repository you link to is a public repository, so I think this is why you don't see these options.
The section of that article that describes the options for public repositories is: Configuring required approval for workflows from public forks.
I think that the headings in this article are confusing because it's not clear that we're talking about the visibility of the parent repository and not the fork.
I suggest we update the article as follows:

Change heading "Configuring required approval for workflows from public forks" to "Controlling changes from forks to workflows in public repositories".
Change heading "Enabling workflows for private repository forks" to "Enabling workflows for forks of private repositories"
Change heading "Configuring the private fork policy for a repository" to "Configuring the fork policy for a private repository"

Great - I'll update the issue summary accordingly and add a help wanted label.

@oraclown - thank you for raising this issue to highlight the confusing headings in this article ✨

Code of Conduct

[x]  I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks
What part(s) of the article would you like to see updated?
The picture under Step 4 "Under Fork pull request workflows, select your options. For example:" contains an option to make repository secrets available to fork PR workflows, when this is no longer an option. Confusing.
Additional information
Here is another doc that makes clear this is no longer an option.
I stumbled on this confusing mismatch because tests are failing since the secrets aren't available for a contributor's PR.
Update from a maintainer
After discussion (see comments below), we realized that the article is correct but that the headings are confusing.
Recommended updates to the article

Change heading "Configuring required approval for workflows from public forks" to "Controlling changes from forks to workflows in public repositories".
Change heading "Enabling workflows for private repository forks" to "Enabling workflows for forks of private repositories"
Change heading "Configuring the private fork policy for a repository" to "Configuring the fork policy for a private repository"


[iOS] No implementation found for method LocatorPlugin.isServiceRunning on channel app.yukams/locator_plugin

On iOS when invoking
BackgroundLocator.isServiceRunning()
leads to a MissingPluginException
#0      MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:313:7)
<asynchronous suspension>
#1      BackgroundLocator.isServiceRunning (package:background_locator_2/background_locator.dart:61:13)
<asynchronous suspension>
#2      BackgroundLocationService.isRunning (package:rebecca_patient_app/src/location/services/background_location.dart:21:29)
<asynchronous suspension>
#3      LocationRepository.backgroundLocationStatus (package:rebecca_patient_app/src/location/repository/location_repository.dart:27:13)
<asynchronous suspension>
#4      new LocationBloc.<anonymous closure> (package:rebecca_patient_app/src/location/bloc/location_bloc.dart:34:61)
<asynchronous suspension>

Seems to be the same issue with #64 that was closed for some reason I don't understand.
The iOS implementation of the function seems to exist.
Please advise.
Plugin version: 2.0.6
[!] Flutter (Channel stable, 3.7.9, on macOS 13.0.1 22A400 darwin-arm64, locale en-GR)
    • Flutter version 3.7.9 on channel stable at /Users/mug/flutter_3.3.10
    ! Warning: `dart` on your path resolves to /opt/homebrew/Cellar/dart/2.16.1/libexec/bin/dart, which is not inside your current Flutter SDK checkout at /Users/mug/flutter_3.3.10. Consider adding /Users/mug/flutter_3.3.10/bin to
      the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 62bd79521d (6 weeks ago), 2023-03-30 10:59:36 -0700
    • Engine revision ec975089ac
    • Dart version 2.19.6
    • DevTools version 2.20.1
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.```

Delete pods,symlink folder and podfile.lock
Then
In terminal
pod update
Then
pod install

After further examination, it seems that the method works as expected when called from the main isolate (where the plugin has bee initialized).
The error seems to happen only when I try to call the method from the background isolate (the one the plugin spawns).
Is it possible that the plugin is not properly initialized in the background isolate? (my callback works fine)
I don't have this problem on Android, which fits this hypothesis, as there is no need for any setup in order to use other plugins in the callback.


PropTypes is deprecated.

I'm getting the following warning, and I'm not sure if this issue has already been raised:
Warning: Accessing PropTypes via the main React package is deprecated. Use the prop-types package from npm instead.

Yep, will migrate this shortly. PRs welcome.

I'll try and open a PR tonight.

Fixed in 2.2.4

Hi, I have upgraded to the latest version your plugin but I still get the PropType deprecated error in my console.
I am using:
"react": "^15.5.4",
"react-dom": "^15.5.4",
"react-draggable": "^2.2.6",
"react-redux": "^5.0.5",


[AlgorithmicRecourseDynamics] Update URL

Please, next time use a more descriptive title than the useless default one (there are some thousand of files called Project.toml)

Ahh my bad, sorry! There's three more of these, I'll change the title of those. Thanks


docsify added

This one resolves https://github.com/DipanshKhandelwal/Learning-German/issues/5.
You will need to enable github pages in your settings and choose master branch as a source.

Works perfectly at https://dipanshkhandelwal.github.io/Learning-German/. Thanks :+1:


not work on Linux 4.15.0-144-generic #148-Ubuntu SMP Sat May 8 02:33:43 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

print(ice.scalar_multiplication(2))
: '\x04\xc6\x04\x7f\x94A\xed}m0E@n\x95\xc0|\xd8\w\x8eK\x8c\xef<\xa7\xab\xac\t\xb9\p\x9e\xe5\x1a\xe1h\xfe\xa6=\xc39\xa3\xc5\x84\x19Fl\xea\xee\xf7\xf62e2f\xd0\xe1#d1\xa9P\xcf\xe5*')
P = ice.scalar_multiplication(2)
print(type(P))
: <type 'str'>
P.hex()
: AttributeError: 'str' object has no attribute 'hex'

Are you trying it on Python 2 ?
Because you are missing b in the beginning. It is supposed to be  b'\x04\xc6\x04\x7f\x94A\xed}m0E@n\x95\xc0|\xd8\w\x8eK\x8c\xef<\xa7\xab\xac\t\xb9\p\x9e\xe5\x1a\xe1h\xfe\xa6=\xc39\xa3\xc5\x84\x19Fl\xea\xee\xf7\xf62e2f\xd0\xe1#d1\xa9P\xcf\xe5*'

you are right, python2 was my problem
on python3 works good
can you add functionality create point object (P) from full pubkey(04)?
or tell me how to do it right now

It is nothing special. just a bytes form of correct length Full Pubkey. For example.
cpub = 030cabe03a609b39af406d7b29c8600a5b6f1704fcfdd5b5be56d152782c13fd65
upub = 040cabe03a609b39af406d7b29c8600a5b6f1704fcfdd5b5be56d152782c13fd65553675c3d71513cb35c8df9683fe16cf8d5af423e1a6bebe791e66a1c2c956a3
P = bytes.fromhex(upub)


Is InferContext in python/c++ api related to cuda context?

Is InferContext in python/c++ api related to cuda context?
To elaborate my question, I have few use cases as below:

For server config, instance_group=1 and max_batch_size=8 is set. In python client for reference, I instantiate one InferContext object, and concurrently call ctx.async_run(batch_size=1) in eight sub threads. Can server batch the eight requests from one context?

For server config, instance_group=1 and max_batch_size=8 is set. In python client for reference, I instantiate eight InferContext objects, and concurrently call ctx_i.async_run(batch_size=1) in eight sub threads. Can server batch the eight requests from eight different contexts?

For server config, instance_group=8 and max_batch_size=1 is set. In python client for reference, I instantiate one InferContext object, and concurrently call ctx.async_run(batch_size=1) in eight sub threads. Can server dispatch eight requests from one context to eight model instances?

For server config, instance_group=8 and max_batch_size=1 is set. In python client for reference, I instantiate eight InferContext objects, and concurrently call ctx_i.async_run(batch_size=1) in eight sub threads. Can server dispatch eight requests from eight different contexts to eight model instances?

For a more specific use case, I have a server receiving client requests built by flask. To use python api to communicate with trtis, should I instantiate one InferContext, and call ctx.async_run() in each infer request? Or should I instantiate multiple InferContext(equal to instance_group in server config), and call ctx.async_run() from different context objects?
Thank you.

As far as I know, InferContext is not related to cuda context.

For this, you can set up Dynamic Batcher which will wait for multiple requests for a certain period of time to combine into one batch.
Same as the first answer.
As far as I know, yes it will try to run each request in different instances based on availability.
Same as the third answer.

For the use case, that you explained, it might be better to start a new InferContext in a separate thread to not block your client from receiving further api requests. Ideally, I would add some queue where your flask client submits requests, and have multiple workers listening to the queue to process requests using trtis for inference.

@bezero Thanks for the advice.
I was assuming the same as you pointed out. It would make more sense if InferContext is not related to cuda context. Otherwise, trtis would take more efforts to batch/dispatch data from different cuda contexts.
For the use case, I was thinking one InferContext may be good enough. Since InferContext does have the interface of async_run. It could put the post process in callback, which should resolve the block issue. Right?

@rtrobin yes, I think it should work.

Confirming that InferContext has nothing to do with CUDA contexts. InferContext is an abstraction in the client libraries. TRTIS uses a single CUDA context for each GPU device that it controls. You may find the architecture section of the doc interesting: https://docs.nvidia.com/deeplearning/sdk/tensorrt-inference-server-master-branch-guide/docs/architecture.html

@deadeyegoodwin Thanks for the confirming.


Remove references to org.opencastproject.db.ddl.generation

Via https://opencast.jira.com/browse/MH-12733
See discussion on list.
Apparently this setting does not do anything anymore, but it still features prominently in the admin documentation.
EclipseLink apparently creates the necessary tables automatically, independent of this setting, if they are not already there. So the caveat about "please run the provided DDL script first to reap suchandsuch optimization benefits" still applies.
This would also be completely obsolete once #1105 is merged, even if it were being used by anyone right now.

I'll work on this one.

Hello, I've opened I small PR for this, let me know if there's anything else I can help with.


Possible performance issue

I have configured sbt-header to create headers on every compile. With the new sbt 1.3.0-RC3 super shell, which displays actively running tasks, I can see that the headerCreate task shows up quite often. For example it takes around 3-4 seconds in headerCreate task under various scopes until sbt starts compiling sources.
Could the performance be improved by introducing incremental cache for files that have headers checked? (similar to the one in sbt-scalafmt: https://github.com/scalameta/sbt-scalafmt/pull/13)

Thanks a lot for this observation. I guess a cache would indeed help. PRs welcome.


Intermittent network/DNS issue in Pods

Is this a request for help?:
Yes
Is this an ISSUE or FEATURE REQUEST? (choose one):
ISSUE
What version of acs-engine?:
0.23.1
Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes 1.12.1
What happened:
I observed socket exceptions occurred intermittently in Pods,  System.Net.Sockets.SocketException: No such host is known
What you expected to happen:
There is no network issue in Pods
How to reproduce it (as minimally and precisely as possible):
There is a .net program to connect Azure Service Bus periodically in a Pod.
Anything else we need to know:
Here is my application log
error.txt
Here are System Event Log & Application Event Log
ApplicationError.txt
SystemError.txt
I found some errors in System Event Log in nearly same time when network issue occurred in Pod, don't know if they are related.
The operation '7' failed on nic FB98B3AC-B0E3-4243-BA9A-3C34C7824830 (Friendly Name:  8676fdc6-eth0). Status =<PHONE_NUMBER>.
Failed to enable miniport NIC F7F65B2F-ECFD-4929-8258-6E4FAA74B693 (Friendly Name:  94f99dcb-eth0), status =<PHONE_NUMBER>.

It was caused by unexpected vm reboot, I found this in Event Log: The previous system shutdown at 12:02:51 AM on 11/16/2018 was unexpected.
I will open a tick to Azure Support to investigate it.


prog_test: Fix build breakage

Commit 845a062c0fdf ("monitor: Remove package-level link monitor") broke
this test by refactoring the monitor function signature. Fix it by
overhauling this code to match the new usage model.
Reported-by: Timo Beckers<EMAIL_ADDRESS>

How did this sneak through in the original PR? thinking

Because the check did not run I believe: https://github.com/cilium/cilium/actions/runs/1747568015. We should fix that in the BPF check workflow.

BPF checks now passed: https://github.com/cilium/cilium/runs/4986956392?check_suite_focus=true
I don't believe that this code is executed by the ginkgo CI runs, so should not need to trigger the rest of that. The only failure is a non-required false positive from CodeQL which is a known consistent failure in the tree at this time.
Relevant codeowners have provided feedback and this is should not be at all controversial, just getting the master branch back into a good state. Good to merge.

Thanks for the quick reviews @aditighag , @pchaigno !


Add divide-by-zero test in kernel CI/CD

Consider adding the test case in api_test.exe .

@Alan-Jowett, is this something that you can do?


hotfix subtle change to invariant in sdf_str function

Fixes #1000
@apayne97  this was a subtle change in the sdf_string_to_oemol function such that it could now return None if no valid molecules were read. Related to #998, I am going to hotfix here, we can continue discussion about what the desired endstate should be there.
The basic info though is that all of our openeye functions currently return an OEMol always, even if a read failed (making it the callee's responsibility to check if the OEMol is valid for their purpose.
If we change this so that the read will fail instead every call site has to check for success. This is doable and we can discuss.
Developers certificate of origin

[X] I certify that this contribution is covered by the MIT license as defined in our LICENSE and adheres to the Developer Certificate of Origin.

Yes, here's the gist I made to show the problem: https://gist.github.com/apayne97/8d2c8a13f6045ad5da3bea13d04aa262


Issues using it in 2023

This is awesome and I love it, but sadly is not updated and it conflicts with current versions of React.
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react-dom
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/react-mount-animation
npm ERR!   react-mount-animation@"*" from the root project

I did a force install to test it anyways and loved it but then couldn't deploy my page because the package conflict it caused :/

Faced the same problem


Update copy-snapshot-to-same-or-different-subscription.md

Lost of missing $ in front of variables and no "" around text so script would fail if actually run

@microsoft-github-policy-service agree

@ramankumarlive
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@ramankumarlive - Can you review this old PR?
@MicrosoftDocs/public-repo-pr-review-team

Sent Teams message today.

Sent Teams message to @ramankumarlive 8/2

emailed author

These are bash scripts that are meant to be executed in a Linux operating system. I believe you are using it in a command line interface in a windows operating system and that is why you need to include the $ prefix. Please try the script from the Cloud Shell in the Azure portal by selecting bash and it should work fine.

@ramankumarlive - Should this PR be closed or is any clarification/note ? needed in the article? Thanks - PR review team

emailed author

Sent a Teams message to author today.

Teams msg to author

Per SME: The changes would break the script and can't be accepted.


feat(cmd): log test errors

Description
This changes the CLIs "test" subcommand (substation test) to log runtime transform errors to standard error. This
Motivation and Context
When performing test file driven configuration development it's not clear if a specific tests [config error] is from misconfigured Jsonnet declarations, invalid Substation options or runtime errors. You can remove the first two options by diagnosing with substation vet but then you still don't know what the runtime transform error is if that's the case.
How Has This Been Tested?
Verified that multiple tests across files can be run, and are more clear when there was an opaque [config error].
$ substation test .
ok	fizz.libsonnet	607µs
?	buzz.libsonnet	[transform error]
error: transform 907268ad-3907ac72: format 2006-01-02T15:04:05.000000Z location UTC: parsing time "2024-10-29T19:15:52.011Z" as "2006-01-02T15:04:05.000000Z": cannot parse ".011Z" as ".000000"
ok	baz.libsonnet	903µs

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.

Any other references to test error and config error no longer make sense, it's better if they're all consistent one way or the other. (If they are going to reference the path in the config file, then it should be "transforms" with an s.)

Updated the test output on errors for each place to make it more meaningful e.g. test condition error, or test config error

This isn't obvious but it uses 4 spaces instead of \t\t for reporting info or errors, like this.

Updated to use spaces.

Port the same features and style to the playground command for consistency.

Updated the playgrounds error handling.

This is affecting the style of most of the CLI, so I pushed a commit to standardize it. You can try it with this config:

local sub = std.extVar('sub');

{
  tests: [
    {
      name: 'ex',
      transforms: [  // comment block for error.
        sub.tf.test.message({ value: 'brex.com' }),
        // sub.tf.net.domain.subdomain(),  // uncomment for runtime error.
        // sub.tf.net.domain.subdomain({ object: {source_key: 'test'}}),  // uncomment for vet error.
      ],
      condition: sub.cnd.str.eq({ value: '' }),  // comment for error.
    },
  ],
  transforms: [  // comment block for vet error.
    // sub.tf.net.domain.subdomain(),  // uncomment for runtime error.
    // sub.tf.net.domain.subdomain({ object: {source_key: 'test'}}),  // uncomment for vet error.
    sub.tf.send.stdout(),  // no-op.
  ],
}

so I pushed a commit to standardize it.

Pushed changes look fine to me! Let's merge this one?


Add an option for no-unresolved rule that allows one to resolve .ts files from .js imports

One problem that prevents this package from being useable on TS codebase, is that it treats a file extension literally. TypeScript-based ES modules require you to import TS files using .js extension:
import * as foo from './foo.js'

The statement above really imports content of ./foo.ts file.
This PR adds a new boolean option ts, set to false by default. If it is set to true, a statement above in a TS codebase is considered valid. If the plugin can not resolve ./foo.js, it tries to also resolve ./foo.ts, and then goes on as before.

probably want to have it try .tsx as well

Okay, now it tries to resolve .jsx? to .ts or .tsx.

@Maxim-Mazurok Added the tests. What is left for the PR to be merged?

Thanks! I think the only thing left is to get some maintainer to approve it. I didn't really check the code, but now that we have tests I think that maintainers approval is more likely to happen.

Good. Let me properly rebase that, and it is ready to merge then.

Rebased now. Hope it is good to merge. Feel free to add comments/critique, so that I can amend the PR.

Since this deals with TS-specific resolution, is there a reason this couldn't/shouldn't be an option on the TS eslint resolver? (cc @bradzacher)

Should it be a default there, or hidden behind a flag, like here?

@ukstv consider raising an issue there to discuss with the maintainers! You may find there is already one?

I don't understand, https://github.com/import-js/eslint-import-resolver-typescript already supports exports field in package.json, this is an unnecessary change in the core module.

I don't understand, https://github.com/import-js/eslint-import-resolver-typescript already supports exports field in package.json, this is an unnecessary change in the core module.

exports clause in package.json has nothing to do with this change. What we are trying to achieve is having a check if a local ./foo.js exists because of corresponding ./foo.ts exists.

What we are trying to achieve is having a check if a local ./foo.js exists because of corresponding ./foo.ts exists.

It is also supported by https://github.com/import-js/eslint-import-resolver-typescript

As above, please use https://github.com/import-js/eslint-import-resolver-typescript instead.

I cannot find the equivalent of "import/order" in eslint-import-resolver-typescript.

How is that unsafe?

import-js/eslint-plugin-import#importextensions the docs probably need to be updated to recommend installing this instead of adding extensions which is unsafe?

I'm going to PR to add a section about TypeScript usage in README, if you want to do that, feel free to tell me and take it.


LTL parser unintelligible

Something as simple as checking a proposition to be true is not easy with the changes to the expression parser. In the below example all state slots are of type bool (see --labels output below). I understand bools are now first-class citizens in the language. Yet, when I check 'slot==true', an error is raised. When I change to 'slot="true"' (quoted "true") the parser goes through, but I have no idea whether this has the expected semantics (e.g. "true" is not in the --labels output).
$ pins2lts-mc/etf2lts-mc ./gal.etf --pins-guards --when --ltl 'X((((LTLAP1==true))U((LTLAP1==true)))U((LTLAP4==true)))'
etf2lts-mc, 0.000: ETF language module initialized
etf2lts-mc( 0/ 4), 0.003: Loading model from ./gal.etf
etf2lts-mc( 2/ 4), 0.012: LTL layer: formula: X((((LTLAP1==true))U((LTLAP1==true)))U((LTLAP4==true)))
etf2lts-mc( 2/ 4), 0.012, ** error **: Incompatible type formats (LHS = "enum", RHS = "Boolean") for expression: "(LTLAP1 ==  true )", expecting format pair (LHS, RHS) to be any pair in {(direct, direct), (direct, [.,.]), (direct, Signed 32-bit integer), ([.,.], direct), ([.,.], [.,.]), ([.,.], Signed 32-bit integer), (chunk, chunk), (chunk, enum), (enum, chunk), (enum, enum), (Boolean, Boolean), (Boolean, trilean), (trilean, Boolean), (trilean, trilean), (Signed 32-bit integer, direct), (Signed 32-bit integer, [.,.]), (Signed 32-bit integer, Signed 32-bit integer)}
)$ pins2lts-mc/etf2lts-mc ./gal.etf  --labels
etf2lts-mc: ETF language module initialized
etf2lts-mc( 0/ 4): Loading model from ./gal.etf
The state labels are:
0: enabled0:bool
1: enabled1:bool
2: enabled2:bool
3: enabled3:bool
4: enabled4:bool
5: enabled5:bool
6: enabled6:bool
7: enabled7:bool
8: enabled8:bool
9: enabled9:bool
10: enabled10:bool
11: enabled11:bool
12: LTLAP0:bool
13: LTLAP1:bool
14: LTLAP2:bool
15: LTLAP3:bool
16: LTLAP4:bool
17: LTLAP5:bool
18: LTLAP6:bool
19: LTLAP7:bool
20: LTLAP8:bool
21: LTLAP9:bool
22: LTLAP10:bool
23: LTLAP11:bool
The edge labels are:
0: action:action
The registered types are:
0: int (enum)
1: action (enum)
2: bool (enum)
The state vector is:
0: Section_4:int
1: F7:int
2: Section_2:int
3: Section_9:int
4: Section_11:int
5: F2:int
6: Section_6:int
7: F9:int
8: F3:int
9: Section_12:int
10: F12:int
11: F6:int
12: F1:int
13: Section_3:int
14: Section_10:int
15: F8:int
16: F10:int
17: Section_5:int
18: Section_8:int
19: Section_7:int
20: F5:int
21: F11:int
22: F4:int
23: Section_1:int
The registered types values are:
0: "tr0" (action)
1: "tr1" (action)
2: "tr2" (action)
3: "tr3" (action)
4: "tr4" (action)
5: "tr5" (action)
6: "tr6" (action)
7: "tr7" (action)
8: "tr8" (action)
9: "tr9" (action)
10: "tr10" (action)
11: "tr11" (action)

The error message is still unintelligible for a user.

gal.etf.zip

To continue working with the ETF (and to use atomic predicates) you can simply add the "false", and "true" strings to the ETF, i.e., change:
begin sort bool
end sort

to
begin sort bool
"false"
"true"
end sort

Meaning you have to use "false", and "true" in the atomic predicates. You can do this for the integers too, but then you need to find out which values are reachable.

If this is only for ETF, then it can have less priority and perhaps should be a different issue.
The error message should however be improved because the user has no clue about chunks, enums, etc.

Ideally, we refer to a manual page that explains the built in types and the --labels output.

Fixed.


Search parsing package

A package that can be attached to a form to handle things such as negation (!query), and building the search query based on the collection and fields.
Any input?

I have used Typeahead/Bloodhound for this in the past, it works pretty well, though all of my experience in the past has been with smaller databases (<500,000 records). I am not sure how well it would scale with Mongo and our schema. We would want to look into performance implications of different engines parsing through all torrents for example.

What would be absolutely amazing is PCRE search, but I doubt that's something that could be implemented in a scalable way and would have to include negative lookahead to support negation.

@TheDevKing This exist for lucene based search like elastic search, solr or  database that implement lucene index (neo4j, orientdb ect)
See elasticsearch about it https://www.elastic.co/guide/en/elasticsearch/reference/1.6/query-dsl-regexp-query.html

Isn't this related to #144

@thomwiggers it is. My answer is more about saying that it is possible and scalable.

I meant the issue in general, not just your comment.

@guitarman0831
Research cab start here
https://github.com/matteodem/meteor-easy-search
http://mistic100.github.io/jQuery-QueryBuilder/