Files get ignored from coverage when esnext bigint is used.

Steps to reproduce.

Have working nyc setup.
Edit a file that already appeared in coverage info, and add the following function:

function foo() {
  return 5n;
}

Result is that the file disappears.

+1 for that. I have even combined 2 projects, and file with any bigint is removed from coverage. Please fix it :c

I've installed 13.2.0, installed @babel/plugin-syntax and added the following in my .nycrc:
  "plugins": [
    "@babel/plugin-syntax-bigint"
  ],

However the files with 0n are still excluded from the report. Perhaps I configured it wrong but I can't find any documentation for this either.

You need to point to a babel parser plugin, not a babel plugin.  So for this you need bigInt.  Note that configuring the plugins option overwrites the existing plugins, so you may need to also add other babel parser plugins.  See https://babeljs.io/docs/en/babel-parser#plugins for a list of valid plugins to be used here.
https://github.com/wzalazar/istanbuljs/blob/d23d023d43c7b030e708518e6791b67f39c4c9ad/packages/istanbul-lib-instrument/src/instrumenter.js#L86-L93

Ah I see, thanks! Sorry it was the end of my day 👍
I think I got that to work. Did have to delete my nyc cache, perhaps plugins are not included in the cache key algorithm?
Calling this top-level configuration plugins is awfully generic though.

Ah I see, thanks! Sorry it was the end of my day +1
I think I got that to work. Did have to delete my nyc cache, perhaps plugins are not included in the cache key algorithm?

Glad it's working for you.  .nycrc definitely is not included.  I thought that your package.json would be included but looking at the code for caching-transform I'm not confident.  Command-line arguments definitely are not included.

Calling this top-level configuration plugins is awfully generic though.

Agreed in hindsight, parser-plugins would have been better.  @bcoe @JaKXz can we do anything about this or is it too late?  Maybe we can create an alias for now, delete the plugins option from nyc@14?

@coreyfarrell that's a good way to go - we could even just change the docs to only show parser-plugins.

Ok, so I'm struggling with this for almost 2 hours. Can you tell me, how I am supposed to add this plugin? In package.json i have  "nyc": {     "check-coverage": true,     "lines": 100,     "statements": 100,     "functions": 100,     "branches": 100,     "include": [       "src/**/*.js"     ],     "reporter": [       "html"     ],     "require": [       "@babel/register"     ],     "report-dir": "./coverage"   },
in .babelrc
{
  "plugins": ["@babel/plugin-syntax-bigint"]
}
``` and I get nice error:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

I have literally no idea. I can't find any doc talking about it, lurking in source code also doesn't provide any support.

I believe you need the plugins option in the nyc config as well @kmdrGroch

@JaKXz if you mean ```
"nyc": {
"check-coverage": true,
"lines": 100,
"statements": 100,
"functions": 100,
"branches": 100,
"include": [
"src/**/*.js"
],
"reporter": [
"html"
],
"require": [
"@babel/register"
],
"plugins": [
"@babel/plugin-syntax-bigint"
],
"report-dir": "./coverage"
},
and
.babelrc

{
"parserOpts": {
"plugins": ["@babel/plugin-syntax-bigint"]
}
}
or

{
"plugins": ["@babel/plugin-syntax-bigint"]
}
dont work

You do not need nyc to "require": "@babel/register" for this, I'd recommend against it unless you are using babel for other reasons.  What you need is to add "plugins": ["bigInt"] to your nyc options.  This option expects babel parser plugins, not babel plugins.
If you are still having trouble please post a new ticket with a link to a repository demonstrating the problem.

CC @kmdrGroch @novemberborn @evert @wzalazar
FYI in<EMAIL_ADDRESS>the option plugins is being renamed to parser-plugins, see #1031.  This will be listed under breaking changes in the CHANGELOG.md.

@coreyfarrell as BigInts are in Node.js now, we should probably turn this on by default right?

@kmdrGroch @novemberborn @evert @wzalazar starting with<EMAIL_ADDRESS>the bigInt parser is enabled by default.  Moving forward we intend to add parser plugins for any stage-3 feature which is supported by any released version of node.js (shortly after the new releases).  That means<EMAIL_ADDRESS>also supports class properties (public and private).
This new version of nyc version is currently released to npm under next tag for testing.

thanks, @coreyfarrell for info. Holding thumbs for you, good luck <3


Migrate to ES modules

This is a work in progress migrating the current KDK to using ES modules which will then have to be merged into https://github.com/kalisio/kdk/pull/573
Current issues are the dynamic module loading using require which is not available with ES modules, only the asynchronous import. It will require some additional restructuring so that services can be registered and retrieved asynchronously.

About dynamic imports the work already done on the Weacast migration will be useful, notably in the application layer, eg https://github.com/weacast/weacast/blob/master/packages/core/src/application.js#L36.
Similarly we should probably update the winston logger to the latest version and use the work done during the Weacast migration.

Ok, I think I got setup with dynamic imports working but there are still a lot of the core tests (yarn run mocha:core) that are failing at the moment.


Pushing to WordPress w/o Changelog

Issue description:
Hey guys,
Probably not a good idea to push changes to WordPress before you push a Changelog here on GitHub, since this repository is linked from the WordPress plugin update page.
Version used:
4.1.1
Using theme_mods or options?
theme_mods
PHP error messages that might be related

JS error messages that might be related

Code to reproduce the issue (config + field(s))

Looks like this is still an issue.
We can see 5.1.0 is released with no changelog available.

Still an issue, especially for those of us using composer to depend on this in our theme... we'll have to pull dev-master via composer which is not ideal. Please publish a release using GitHub releases and a changelog. Thanks!


Can I use CUDA 9.0?

While I was working with this great open source, I updated CUDA from 8.0 to 9.0, and got an error as below. How can I solve this? How can I update csfm?
$ bin/opensfm_run_all data/berlin
Traceback (most recent call last):
  File "/home/paul/projects/sfm/OpenSfM/bin/opensfm", line 10, in <module>
    from opensfm import commands
  File "/home/paul/projects/sfm/OpenSfM/opensfm/commands/__init__.py", line 2, in <module>
    import extract_metadata
  File "/home/paul/projects/sfm/OpenSfM/opensfm/commands/extract_metadata.py", line 5, in <module>
    from opensfm import dataset
  File "/home/paul/projects/sfm/OpenSfM/opensfm/dataset.py", line 11, in <module>
    from opensfm import io
  File "/home/paul/projects/sfm/OpenSfM/opensfm/io.py", line 10, in <module>
    from opensfm import features
  File "/home/paul/projects/sfm/OpenSfM/opensfm/features.py", line 7, in <module>
    import csfm
ImportError: libcudart.so.8.0: cannot open shared object file: No such file or directory

@hy9be OpenSfM does not use Cuda at all, so no changes are required on its side.

@paulinus Thanks! Just realized it is used by opencv actually.

so, if I complied opencv after i installed cuda9, the problem can solved?

Make sure to recompile OpenSfM after changing anything in opencv and you should be good. Since opensfm does not use any cuda function, it should not matter when or how you build opencv.


WIP: Add Plots recipe for TSeries

Codecov Report

Merging #5 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #5   +/-   ##
=======================================
  Coverage   47.01%   47.01%
=======================================
  Files           4        4
  Lines         285      285
=======================================
  Hits          134      134
  Misses        151      151

Impacted Files
Coverage Δ

src/TimeSeriesEcon.jl
100.00% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ae3cb35...1ee1c80. Read the comment docs.


updating stack-hci-vm cli  to 1.0.0 version

This checklist is used to make sure that common guidelines for a pull request are followed.
Related command

General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)
[ ] My extension version conforms to the Extension version schema

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

@jsntcy I am seeing this error during the linter check in the pipeline - WARNING: Unable to load extension 'stack-hci-vm: No module named 'azure.identity''. Use --debug for more information.. How do we resolve this issue?

/azp run


Update html lang tag according to current application langage

We need to do so otherwise the browser detects the application as being in english by default and ask to perform a translation to the user locale langage.
There is an exemple in the vue-i18n documentation, a good place to perform this is probably here.
Take care that the locale of the app can be forced by configuration.

It appears that the i18n lib already does the job but it appears the update is made too late in the app initialization process because the browser has already analyzed the langage.

As i18n is initialized in applications to register app bundles it is up to the app to initialize it first.


[WIP] From scratch image build through circleci

Here is my current work on replacing the heavy golang based image by a From scratch one.
The binary is build by a building image sdurrheimer/prom-golang-builder (https://github.com/sdurrheimer/prom-golang-builder) which will then launch the final docker image build.
This system can't use the automated build system from the Docker Hub. It can't build a image which will in turn build a docker image.
This is why CircleCI is needed. It will build the image and push it to the Docker Hub according to different cases:

The master and dev branches
Pre-release tags, for example: 1.0.0-beta
Release tags, for example: 1.0.0. Those tags are also used for the latest docker tag.

The PR files are currently referring to my fork for the development purpose. I will rename those references before the merge.
Link to my alertmanager docker image: https://hub.docker.com/r/sdurrheimer/alertmanager/
Link to CircleCI builds: https://circleci.com/gh/sdurrheimer/alertmanager
In bonus, by using CircleCI with the Github repo, PRs will also be builded but not pushed to the docker hub.
There will be some Docker Hub and CircleCi configurations  to do. I can help with that if you want me to.
@fabxc @discordianfish @juliusv

This is fantastic!
Just to clarify how this whole thing works:
The prom-golang-builder image will work with the only requirement of a make build target to exist.
The repository is mounted into the build container in which then the scratch-image is built by talking to the Docker of the host system?
Using CI for that makes perfect sense.

Just to clarify how this whole thing works:
The prom-golang-builder image will work with the only requirement of a make build target to exist.
Yes, a make build target and a Dockerfile into the root of the sources files. The project source files are mounted with a volume to /app. The docker.sock is also required in order to build the final docker image.

The repository is mounted into the build container in which then the scratch-image is built by talking > to the Docker of the host system?
Yes, the /var/run/docker.sock in mounted into the build container in order to be able to talk to the host docker engine. This a better approach compared to Docker-in-Docker.

Moreover, I can improve the prom-golang-builder to be able to build the project without necessary building a docker image at the end. This will let people build the project without having a working golang environment.
And I guess we can also add the possibility to cross-compile the project for different platforms.

That all sounds great so far.
I discussed the approach with @matthiasr and he brought up that we should use busybox rather than scratch to allow for debugging, which makes a lot of sense to me. Thoughts?

@fabxc @matthiasr Do you guys have some debugging scenario as examples ? Examples that can't be done with a sidekick container or some debugging tool like Sysdig ?
There is some things I don't like about busybox like non-normal GNU versions of UNIX tools for example.

@sdurrheimer:
That's pretty awesome, finally someone gets to do this :)
One thing though, I would really prefer having the prom-golang-builder repo in the prometheus org. I think it might seem confusing / less trustworthy to users especially since it won't be a automated build anymore and people need to trust the content of the images.
I think it should be okay to add you to the prometheus org and give you permissions to prom-golang-builder repo. @fabxc @beorn7 @juliusv - What do you think?

I strongly object to calling GNU versions of tools "normal".
The main use case for a shell is to be able to docker exec and more importantly, kubectl exec into the container and poke around. In cluster deployments like Kubernetes, you generally don't get and should not need a shell on the node. A sidekick container can't be spun up on demand, and it won't have quite the same view of the world.

I can't follow the control flow of this. Why does the builder need access to Docker at all? Why not just have a builder image that has the blessed Go version in it, and explicitly call out to that in the build? I.e. just use docker 1. as a way to pull in a defined build environment and 2. to package and ship the result but keep the two completely separate?
It feels to me like the current approach carries a lot of baggage from trying to docker build in one go.

@discordianfish I believe this was mostly for development. I will take care of the permission stuff.
@sdurrheimer To me the most important part is separation of a build and a run container. Name resolution is handled differently and there are some indications that the glibc resolver might be favorable.
So forcing a static binary under any circumstances might not be what we want after all. And it will not be possible for all tools we want to release in the future anyway (e.g. exporters written in Python).
I also just learned that the same build flags result in static and non-static builds depending on where one cross-compiles, which means our releases for Linux had different name resolution depending on who built them in the past.
So having a build container that cross compiles so we have reproducible release builds is really important.

One thing though, I would really prefer having the prom-golang-builder repo in the prometheus org. I think it might seem confusing / less trustworthy to users especially since it won't be a automated build anymore and people need to trust the content of the images.

@discordianfish Agreed, same as my previous docker images, I'm totally open to move it to the prometheus organization. But it might be cool to give me some permissions in order to be able to maintain it.

I strongly object to calling GNU versions of tools "normal".

@matthiasr Sorry about using some bad shortcut words. What I wanted to say that some tools in busybox doesn't really act/work as most people might think. Like wget which doesn't work with HTTPS. In the past, there were also some tools missing some common options, I don't know if it is fixed now or not.

The main use case for a shell is to be able to docker exec and more importantly, kubectl exec into the container and poke around. In cluster deployments like Kubernetes, you generally don't get and should not need a shell on the node. A sidekick container can't be spun up on demand, and it won't have quite the same view of the world.

I agree but I also like the fact to not to be able to executing other stuffs with from scratch. This might prevent privilege escalation with the root user. Yes of course we can use the USER directive in the Dockerfile, but I'm not sure that all prometheus tools can be run with a non-privilege user.

I can't follow the control flow of this. Why does the builder need access to Docker at all? Why not just have a builder image that has the blessed Go version in it, and explicitly call out to that in the build? I.e. just use docker 1. as a way to pull in a defined build environment and 2. to package and ship the result but keep the two completely separate?
It feels to me like the current approach carries a lot of baggage from trying to docker build in one go.

My objective was to replace the current heavy weight golang based image and try the From scratch approache that we already talked about on IRC with @juliusv and @fabxc etc.
So I was working on the Docker side of this. I pretty much like the way of building the golang project and building the docker image of it in one step. It makes it easier to reproduce this building mechanics for others projects (for the prometheus organization or for the prometheus community).
If this is problematic, we can work on breaking it into two steps. Maybe with a 'Dockerfile.build' for the building process and 'Dockerfile' as the final image.

To me the most important part is separation of a build and a run container. Name resolution is handled differently and there are some indications that the glibc resolver might be favorable.
So forcing a static binary under any circumstances might not be what we want after all.

@fabxc Hum, you think the From scratch container won't work the same based on different distros ?

And it will not be possible for all tools we want to release in the future anyway (e.g. exporters written in Python).

This is a specific way to build golang containers. For sure, we can't do the same with python or java exporters for example.

I also just learned that the same build flags result in static and non-static builds depending on where one cross-compiles, which means our releases for Linux had different name resolution depending on who built them in the past.
So having a build container that cross compiles so we have reproducible release builds is really important.

You mean, you want to be able to use  the prom-golang-builder, not only for the docker image, but also for all the binaries included in the Github release ?

@sdurrheimer you should have sufficient permissions by now.

You mean, you want to be able to use the prom-golang-builder, not only for the docker image, but also for all the binaries included in the Github release ?

Yes, using the same to cross-compile our releases would be neat.

This might prevent privilege escalation with the root user.

Not really. If they crack open Prometheus they already have code execution, there not being a shell won't save you. I would prefer debuggability over the illusion of security.

Not sure if that's possible with CircleCI, but IMO the ideal process would be to use an image that has Go to run the tests and build binaries for all platforms, then put the binary for linux-amd64 in a Docker image, attach the binaries to the Github tag, and push to Docker hub… that way, the binary in Docker is also the same as on the release page.

Best would be if Docker supports more shared namespaces (https://github.com/docker/docker/issues/10163). Until then.. I guess yeah especially with kubernetes and similar scenarios where you don't have host access I see how you want something like busybox for now.

Naive question from the sidelines: at Google, the cluster manager always mounted a simple base image (with shell, etc.) into every container, while the container image itself only contained the service binary. Couldn't people who want a shell do the same with Docker (using -v in read-only mode) or does the handling of that get too hard when using schedulers like Kubernetes on top of Docker?
No opinion of whether that's better, but it's an alternative to consider. I do like the idea of container images that only contain the service binary and anything it really needs to run.

That is pretty much what "FROM busybox" does - that the base image is
called a "layer" instead of an image in its own right is a difference in
terminology.
I don't think either Docker or Kubernetes allow doing this after the fact.

My question about busybox:

I've seen some mention about glibc. Busybox use uClibc, does it fit well ? I don't know.
One tag seems to have glibc : busybox:ubuntu-14.04 but it is a old tag.
Maybe busybox:ubuntu is a updated equivalent ? I don't know.
There is no package manager, is it ok for you ? Will people complain because they can't do much except be able to use a shell and some available binaries ?

Whether we need glibc depends more on the build- than the runtime container I guess. I'm not sure what it takes to really make a static go binary these days, that would be ideal. Otherwise you'll need to pull in whatever the binary needs, because the busybox image comes with the same libraries as scratch.
Yes, for debugging purposes I think busybox is enough. True that it doesn't have a package manager but that is more relevant for pulling in libraries at image build time.

The need of glibc for the build-time is already the case in the prom-golang-builder and we are also already building static go binaries.
My question was more about @fabxc comment:

Name resolution is handled differently and there are some indications that the glibc resolver might be favorable.
So forcing a static binary under any circumstances might not be what we want after all.

So if the binary might not  be necessarely static, we might then need a proper busybox with glibc, am I misunderstanding something here ?

That was based on a verbal comment I made from being a bit miffed at the current (musl base + glibc prometheus) situation, which makes it hard to debug potential DNS issues because you can't reproduce what Prometheus sees when the base tools don't support search domains. This is not really an issue with the busybox image. While the resolvers used aren't exactly the same it's still close enough so disregard that.

Seeing https://github.com/docker-library/busybox/tree/master/glibc seems like there's an up to date glibc busybox (1.24.1) but not published on Docker hub - at least can't find tag referencing it.

let's not worry about the details of the base system too much. We don't want to depend on it anyway, it's just there for operators. This means we can easily switch it out should the standard busybox prove unsuitable.

I'm currently working on being able to cross-compile with the prom-golang-builder image (@see https://github.com/sdurrheimer/prom-golang-builder/tree/dev). The image will be huge with all these dependencies.

@fabxc Cross-building Alertmanager for windows is currently failing due to the following error:
/go/src/github.com/prometheus/alertmanager/vendor/github.com/prometheus/common/log/syslog_formatter.go:15: undefined: syslog.Writer

After testing, it seems that it can be fixed by updating the github.com/prometheus/common/log vendor.

Here some updates:

I have split theprom-golang-builder image into 4 images:

The main image tag for platforms like linux/amd64 linux/386, darwin/amd64 darwin/386, windows/amd64 windows/386 etc.
The arm image tag
The powerpc image tag
The mips image tag. This one is not used for now given that go 1.50 doesn't support cross-building for mips architectures.

I have remove the docker-in-docker via docker socket feature from the builder image. The project docker image is build after the crossbuild process.
I have created a prom-busybox image that adds ca-certificates and zoneinfos.
The CircleCI build is now cross-building the project, executing tests and then building the project docker image.

Thanks for the update. This is great!
Queued this for a proper look and to think about how we can automate our build/release process with that.

I also need to check if we could also upload artifacts to the github release. Maybe by using aktau/github-release

Here we go guys,
Here are the different scenarios:
1/ Builds when branches are updated:

master only by default. The dev branch is also builded for alertmanager but since it's now an outdated branch, should we keep it ? Those branches are configurable by modifying the circle.yml file.
Steps:

make crossbuild: cross-compiling the project using the scripts/crossbuild.sh script.
This script use 3 differents builder images. prom-golang-builder:main, prom-golang-builder:arm and the prom-golang-builder:powerpc
make docker: building the project docker image with the branch name as docker tag

The project docker image use the prom-busybox as base image. I have extended the official image to be able to add additional files like ca-certificates.crt for HTTPS, zoneinfos or any required files.
There are currently 2 tags:

latest for the classic uclibc version of busybox.
glibc for busybox with glibc. This one is used for projects that can't be statically builded like node_exporter for example.

Saving cross-builded binaries as CircleCI artifacts
make dockertest: Running tests in the prom-golang-builder:main image.
Pushing the branch's tagged image to the Docker Hub.

2/ Pull Requests:

Pull requests are builded like branches unlike that they are not pushed to the Docker Hub.

3/ Github pre-releases:

The tag version must respect the following RegEx : /[0-9]+(\.[0-9]+)*-.*/. For example: 1.2.0-rc1
Steps:

make crossbuild: cross-compiling the project using the scripts/crossbuild.sh script.
This use 3 different builder images. prom-golang-builder:main, prom-golang-builder:arm and the prom-golang-builder:powerpc
make docker: building the project docker image with the Github tag version as docker tag

The project docker image use the prom-busybox as base image. I have extended the official image to be able to add additional files like ca-certificates.crt for HTTPS, zoneinfos or any required files.
There are currently 2 tags:

latest for the classic uclibc version of busybox.
glibc for busybox with glibc. This one is used for projects that can't be statically builded like node_exporter for example.

Saving cross-builded binaries as CircleCI artifacts
make dockertest: Running tests in the prom-golang-builder:main image.
make release: Creating tarballs for each cross-builded platforms with binaries, any config files, the LICENSE file and the NOTICE file. Then the tarballs are automatically uploaded to the Github pre-release.
Saving tarballs as CircleCI artifacts
Pushing the version's tagged image to the Docker Hub.

3/ Github releases:

The tag version must respect the following RegEx : /[0-9]+(\.[0-9]+)*/. For example: 1.2.0
Steps:

make crossbuild: cross-compiling the project using the scripts/crossbuild.sh script.
This use 3 different builder images. prom-golang-builder:main, prom-golang-builder:arm and the prom-golang-builder:powerpc
make docker: building the project docker image with the Github tag version as docker tag

The project docker image use the prom-busybox as base image. I have extended the official image to be able to add additional files like ca-certificates.crt for HTTPS, zoneinfos or any required files.
There are currently 2 tags:

latest for the classic uclibc version of busybox.
glibc for busybox with glibc. This one is used for projects that can't be statically builded like node_exporter for example.

Saving cross-builded binaries as CircleCI artifacts
make dockertest: Running tests in the prom-golang-builder:main image.
make release: Creating tarballs for each cross-builded platforms with binaries, any config files, the LICENSE file and the NOTICE file. Then the tarballs are automatically uploaded to the Github release.
Saving tarballs as CircleCI artifacts
Docker tag the version's tagged image as latest
Pushing the latest and version's tagged image to the Docker Hub.

@fabxc @discordianfish @juliusv @matthiasr @grobie

This looks really good, I am impressed :+1:

This is fantastic work! Thanks a ton.
Looking into it now.

Further updates:

[x] prometheus/busybox created and linked to a automated build on Docker Hub prom/busybox.
[x] prometheus/golang-builder created, build by CircleCI and pushed to Docker Hub prom/golang-builder
[x] PR updated to point to the new images.

Missing :

[ ] Rename sdurrheimer mentions to prometheus when the PR is validated.
[ ] Create a github access token for github-release uploads.
[ ] Setting up prometheus/alertmanager CircleCI build.

Ready to move on.

@sdurrheimer is the circleci error expected? Beside that, let's move forward. What would be the next/remaining steps? Maybe some rollout plan would be a good idea.

Hum, CircleCI build PRs with a branch name like pull/223. Docker tags with a / are not allowed.
I think I have to change the default SUFFIX for non-master branches builds, maybe the commit ID instead of the branche name.

CircleCI build fixed by replacing / in branch name by -.

@discordianfish for alertmanager no remaining step for the moment. The new release process is already merged for prometheus. Another PR is also ready to be merged for the node_exporter.
For other exporters, I'm gonna make PRs progressively. Priority suggestion are welcome.

👍 💯


Simplify placenames ontology

Simplify the placenames ontology by aligning it with Loc-I principles and re-using existing RDF vocabaulary terms where possible

Working in this branch https://github.com/GeoscienceAustralia/Place-Names/tree/simplify-issue19

Initial simplifcation and alignment with Loc-I completed in #20


Russian translation

??

If the author asks questions, then I won't prove anything, if you want, you can translate the mod into Russian yourself.

Okay. If you're going to be a crybaby about your PR being reviewed in good faith, I don't want your contributions anyway. Get lost.


[WIP] Minimal working, automated and tested examples

Description
Removing old and obsolete examples. Leaving current atom-mapping notebook and cleaning up the protein mutation non-equilibrium switching API example.
Still missing protein-ligand and only ligand examples, for both CLI and API.
Motivation and context

Resolves #813
How has this been tested?
Just local tests so far (manually checking it runs and it gives reasonable output), need to write automated tests for this.
Change log

Minimal examples of protein, protein-ligand and ligand mutations, with automated testing.

+162 −76,114 I love negative PRs

Ok, I noticed that sometimes I get an openmm error as follows:
Traceback (most recent call last):
  File "/lila/home/pulidoi/workdir/repos/perses/examples/protein-neq-switching/run_neq_distrib_flattened.py", line 100, in <module>
    integrator.step(1)
  File "/home/pulidoi/miniconda3/envs/perses-dev/lib/python3.9/site-packages/simtk/openmm/openmm.py", line 7036, in step
    return _openmm.CustomIntegrator_step(self, steps)
simtk.openmm.OpenMMException: Particle coordinate is nan

I have the feeling has something to do with the platform, I have forced it to 'CPU'. Any ideas why this may be happening or if you have experienced similar issues?

+162 −76,114 I love negative PRs

@mikemhenry Well, tests are failing and no idea why, haha. Maybe it wasn't such a great idea to remove all of this? Though I really cannot tell why the tests are failing that way, it works in my computer and in the HPC system.

  Wait for command to complete.  If
        the exit code was zero then return, otherwise raise
        CalledProcessError.  The CalledProcessError object will have the
        return code in the returncode attribute.

        The arguments are the same as for the call function.
INFO:numexpr.utils:NumExpr defaulting to 8 threads.
Traceback (most recent call last):
  File "/home/mmh/Projects/perses/examples/protein-neq-switching/make_htf.py", line 3, in <module>
    solvent_delivery = PointMutationExecutor("ala_vacuum.pdb",
  File "/home/mmh/Projects/perses/perses/app/relative_point_mutation_setup.py", line 169, in __init__
    protein_pdbfile = open(protein_filename, 'r')
FileNotFoundError: [Errno 2] No such file or directory: 'ala_vacuum.pdb'

Which looks like it was unable to find the ala_vacuum.pdb file
This is how I run the tests locally to simulate being on GHA:
GITHUB_ACTIONS=true CUDA_VISIBLE_DEVICES= pytest -v -a "not advanced" -n auto
That way some of the tests that we skip on GHA we skip and we don't use a GPU if there is one.

@mikemhenry Thanks for letting me know how to run these tests simulation GHA.
By the way, I think you probably have a dirty examples/protein-neq-switching directory with some untracked .py files there, because there shouldn't be any make_htf.py. The test works by finding all the .py files in the examples directories.

Good catch, I didn't clean that directory! The danger of dirty/untracked files and globbing :)

Ok, so at least I make the test_examples.py work. I now have to think why we are getting this error in many of the other tests:
>           cwd = os.getcwd()
E           FileNotFoundError: [Errno 2] No such file or directory

Doesn't make much sense to me, but maybe something not getting cleaned up properly when the examples test is run with subprocess?

That tends to show up when the directory has been deleted... which I wouldn't normally expect. Tests are passing on master so there is something going on, it could be subtle -- do you get the error locally?

@mikemhenry Yeah, I agree, it looks as if the current working directory was removed for some reason.
All the tests are passing for me locally.
That is, all except the test_resume ones but I think it is because we are copying the license file manually and that should not be needed with this changes https://github.com/choderalab/perses/pull/844/commits/057ede95fa03c6b63d6486d722f79391e6d13293 . You can see that I am also running some subprocesses for running the examples python scripts without having to copy the license file, so I guess this isn't needed, I am going to make the changes to the resume test and hope they pass now.

It would be great if you could remove that hack, thanks!

@mikemhenry Ok, so I removed that hack and it seems to be working. The resume test that is failing has been failing for different reasons. That one is also failing for me locally. All the others are passsing for me, locally.

@mikemhenry OK all the FileNotFound errors/exception are solved, I'm now hitting an error with the test_resume_protein_mutation_with_checkpoint, which I don't really know it is relevant, but you can see I "fixed" a typo here https://github.com/choderalab/perses/pull/844/files#diff-d46a7132f85e030a2511b37259f5214aa94ff0549be036ad09ca85294f852f7d (maybe I should've made this change in a different issue/PR) and now the test is failing in an assertion. What do you think is the best way to go here?

@mikemhenry If you think about it, it makes sense. Since it is complaining now that it is not finding any neighboring waters (because vacuum). And it takes any word different from "vacuum" for phase keyword to actually solvate the system, as per https://github.com/choderalab/perses/blob/59f47eccb75711c4a03c33f944504e3e6d141dd4/perses/app/relative_point_mutation_setup.py#L542 . So now the question is if we actually want this in "vacuum" or not, and if not, then what to put there in the phase keyword (I guess not putting anything still works).

I think we want a vacuum since that will be faster.

I think we want a vacuum since that will be faster.

@mikemhenry please do note that the test has been running without vacuum this whole time. If we really need vacuum, I think the test has to be done differently, because I believe the assertion in https://github.com/choderalab/perses/blob/de5397eca63bbb82d86f0410dd58fb7dd63436d8/perses/rjmc/topology_proposal.py#L586 that won't let it happen.

Ah good catch! It must have been running in the solvent phase since vacuum was spelled wrong.
We should probably just change the test case to a different mutant residue (i.e. instead of mutating from ALA to ASP, mutate from ALA to THR (or any non-charged amino acid). We won't be able to do charge changing transformations in vacuum because charge changing mutations require transforming water into an ion to account for the charge change. In vacuum, there are no waters present to allow for this.


Progressive Decode

I'm trying to apply progressive encoding and decoding features. There seems no command line option for djxl to instruct it which quality level it stops to decode an image. I have to truncate the jxl code stream and simply apply djxl. It works to some degree, but djxl uses all information in the truncated compression code stream and resultant image looks with different quality details in the top area (where I guess more information available in the truncated code stream) and in the bottom area. Is there option for djxl to stop when further information is not available for the entire image?

There's the option djxl -s {2, 4, 8} that you can use to stop when enough data has been decoded for an effective 1:2, 1:4 or 1:8 image. It's a bit limited since in principle you can have more progressive passes than that, but it may be good enough.

-s option is down sampling , similar to resolution based progression like JPEG 2000. What I tried is to expand the image with the original, full resolution but use only received data covering the entire image. As i understand, the code stream in jxl is arranged DC first, and then increased precision AC data follows. Can decoder do this? If djxl does not, does library API support to expand images of full resolution with, say, only 5% of the code stream . With options --allow_partial_files and --allow_more_progressive_steps, djxl seems like do this, but it seems like apply all data available, the resultant distance (pixelwise) of the expand and the original is uneven across the entire image: smaller distance in the first portion and then increased distance. I asked if there is a way to ask decoder to stop at a point of the available data, if not the entire image is covered.

The API has a JxlDecoderFlushImage() function that would try to render as much as possible with the input buffer provided so far, so you can do that. The output is the full resolution image.
There's probably a bug that hits an assert if the chunk is too small (#245) but after the DC is parsed it should be ok.

I think this one can be closed now, feel free to reopen if there are any further questions.


cli: run tests in multiple processes

For projects with many independent test cases, running tests takes painfully long.
Since test cases are independent, we can run all of them in parallel against one single instance of test validator.
This PR implements:

a new cmd line option, mp_test, to run tests in parallel.
a new option in Anchor.toml, mptest, which specifies the details of multi-process test.

mptest.cmd: the command used to run the tests
mptest.tests: path to the folder that contains all test cases. Each test case is a single .ts file.
We launch a single instance of test validator, and launch one process for each .ts file.

Linking this to the relevant GH issue: https://github.com/coral-xyz/anchor/issues/637

At minimum this needs a new tests or to be applied to one of the existing tests with multiple test suites. Plus a changelog entry.


Calling resignFirstResponder on extension view subviews prevents extensionView from hiding

I have a text field in my extension view.
I have my implementation of the scrollview to tell the extensionView subviews to resign first responder when scrolling down.
This results in the extension view not hiding.
Is there a better way to do this?

Guess I was doing this all wrong. It's fixed now.
I used [self.view endEditing:YES]; instead of resignFirstResponder


Flag --no-headers for text output  not working

Description
The --no-headers flag to avoid printing the headers is not working at least for the datacenter,volumes and snapshot list commands. The headers are always printed.
Expected behavior
don't print the headers
Environment
Ionosctl version:
ionosctl version v6.7.0

OS:
Ubuntu 22.04.3 LTS

Shell:
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

How to Reproduce
ionosctl datacenter list --no-headers

Hi, sorry for the inconvenience. This should be fixed in v6.7.1.
As a side note, the --max-results flag is now global, meaning that various other commands that might have been missing this flag now should work as expected
Thanks for opening this issue and have a nice day!


Feature Requests: Shutdown pi over mqtt/home assistant

it's nice to be able to turn off the display from the home assistant, but it would be nice to be able to shutdown pictureframe from the home assistant to turn it off

Well, to power a pi on and off is not part of picframe. But quite easy to achieve.
I use a shelly 1 (https://www.shelly.cloud/en/products/shop/shelly-plus-1) to turn power on and off.
I run 2 automations on home assistant.
Frame turn off is triggerd on calender event, no one at home, switch in home assistant.

run a shell command to stop the pi
wait 10 sec
turn off pi

The shell command
shutdown_picframe: ssh pi@picframe 'sudo halt'

turn off
alias: FrameTurnOff
description: Bilderrahmen über den homeassistant google calendar ausschalten
trigger:
  - platform: calendar
    event: end
    offset: "0:0:0"
    entity_id: calendar.homeassistant
    id: Calendar
  - platform: state
    entity_id: group.residents
    to: not_home
    id: Bewohner
  - platform: state
    entity_id: input_boolean.picframe_power
    from: "on"
    to: "off"
    id: Power_off
condition:
  - condition: or
    conditions:
      - condition: and
        conditions:
          - condition: trigger
            id:
              - Power_off
              - Bewohner
          - condition: device
            type: is_on
            device_id: 7097dfc77369d5a50f7a1968800171bc
            entity_id: switch.picframe_power
            domain: switch
      - condition: and
        conditions:
          - condition: trigger
            id: Calendar
          - condition: template
            value_template: "{{ '#Frame' in trigger.calendar_event.summary }}"
          - condition: device
            type: is_on
            device_id: 7097dfc77369d5a50f7a1968800171bc
            entity_id: switch.picframe_power
            domain: switch
action:
  - type: turn_off
    device_id: 44e83c25884c5f5398217f9fb47e3178
    entity_id: switch.picframe_display
    domain: switch
  - service: shell_command.shutdown_picframe
    data: {}
  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
  - type: turn_off
    device_id: 7097dfc77369d5a50f7a1968800171bc
    entity_id: switch.picframe_power
    domain: switch
  - service: input_boolean.turn_off
    target:
      entity_id: input_boolean.picframe_power
    data: {}
mode: queued

turn on:
alias: FrameTurnOn
description: Bilderrahmen über den homeassistant google calendar einschalten
trigger:
  - platform: calendar
    event: start
    offset: "0:0:0"
    entity_id: calendar.homeassistant
    id: Calendar
  - platform: state
    entity_id: group.residents
    to: home
    id: Home
  - platform: state
    entity_id: input_boolean.picframe_power
    from: "off"
    to: "on"
    id: Power
condition:
  - condition: or
    conditions:
      - condition: and
        conditions:
          - condition: trigger
            id: Calendar
          - condition: template
            value_template: "{{ '#Frame' in trigger.calendar_event.summary }}"
      - condition: trigger
        id:
          - Home
          - Power
action:
  - type: turn_on
    device_id: 7097dfc77369d5a50f7a1968800171bc
    entity_id: switch.picframe_power
    domain: switch
  - service: input_boolean.turn_on
    target:
      entity_id: input_boolean.picframe_power
    data: {}
mode: queued


Custom bar color

An interesting plugin. Just hope if I can customize the color of the bar. Currently, the green color is very close to my background image.

Hi!
Yes, I totally agree. This first release is a bit basic, but I have some plans to make it more configurable. I will create milestones soon.

Done in 1.1 release. Published today to JB portal, should be available to download next week.


Remove DiagnosticLogEntryProduced event.

Why deleting this? The original goal for this event was to be intercepted by the vscode extension and routed tot he diagnostics and logs outputs.

Why deleting this? The original goal for this event was to be intercepted by the vscode extension and routed tot he diagnostics and logs outputs.

Ah this was something that @jonsequitur and I had discussed. We already removed the #!log magic command in an earlier change - this event seemed like a vestige that is no longer useful.


Implement from_gdp1h from AWS

def from_gdp1h() -> xr.Dataset:
    ...

This can go in clouddrift/adapters/__init__.py unless a better idea comes up.

I don't really understand the goal of this function. If it's to subsampled than you can do directly:
from clouddrift import subset
ds = xr.open_dataset(...)
ds = subset(ds, {"ID": [1, 2, 3]})

and again, this only makes sense if you are running something on AWS. Otherwise, it will be extremely slow.

I think the only benefit is to hide the URL variable from the user, so they don't have to fiddle with it. Indeed, it's a minimal convenience wrapper. It's possible that it's better to not include it.

I just thought of another argument. For other custom datasets like GLAD or LASER whose canonical source is not a NetCDF, there may be convenience functions from_glad or from_laser that implement the preprocessing flow from cloudrun-examples. If so, then it would be more clear to simply provide a minimal from_gdp[16]h wrapper, rather than to make a caveat in the docs that if the user wants to work with GDP, they should just use xr.open_dataset directly.

Done by #188


Exports previously legitimately reported as unused are no longer reported

Hi, after seeing that #697 was closed, I updated knip in the repro for that issue (here) to verify.
The behavior on v5.23.0 was that a, b, c, and d were reported as unused while the other two exports that used multiline exports were not reported (even though they were also unused). The new behavior on v5.23.1 is that none of the exports are reported as unused.

There's a few things to this one. We're only talking about the combination of:

ignoreExportsUsedInFile: true
The export { id } notation

Unfortunately, internally when using the TypeScript AST nodes there's a big difference between these notations:
export const id = 1;

const id = 1;
export { id };

With the latter syntax, I couldn't find a reliable way to detect whether id was used more often or not within the same module. That's why I've opted for the stability of assuming export { id } is referenced (which technically could be argued it is, but it could be only the declaration, not other usage).
So this is the situation now, until we've found a reliable way to do it better.
Additional notes:

Usually ignoreExportsUsedInFile is used only for types, since values don't need to be exported. E.g. "ignoreExportsUsedInFile": { "interface": true, "type": true }
The former syntax doesn't have this issue, so purely from a Knip perspective that would be recommended.


[Improvement] Reduce click/tap after successful payment

AS IS
When you Open TPOS > Add items > Shopping Cart > press "Pay" and the invoice is paid > a Screen with a green checkmark is displayed.
When the checkmark is clicked, you arrive on a screen with amount, "pay" (disabled button), "clear cart" (nonfunctional button)
To go back you need to swipe this screen away

TO BE:
When successfully paid and clicked on the checkmark, the screen with amount (0 sats), "pay" (disabled button), "clear cart" (nonfunctional button) should automatically disapear (or slide out)

Fixed for V1 ( #109 )


ISPN-1739

Fix topology consistency check

Fix looks like correct and much needed !
But I'm surprised such things are not covered by tests.
I'm fine merging it if you can't make one now, we can create a task to make one if future, and doesn't need to be done by you necessarily.

Sanne, I'll assign myself a task on this, but please merge the fix now as it's needed for EDG in particular


Add extra items for ASWF Hosted projects

Pre-submission checklist:
Please check each of these after submitting your pull request:

[ ] Are you including a repo_url? You need to pick the single best GitHub repository for your project, not a GitHub organization.
[ ] Is your project open source?
[ ] Has this project been used successfully in the production of a film, television program, animated content or other projects within the scope of the ASWF. Was it designed specifically for the entertainment industry?
[ ] Is the project currently and actively maintained (e.g., accepts pull requests, replies to issues, has been tested against / builds properly with the compilers for this year's VFX platform)?
[ ] Have you picked the single best (existing) category for your project?
[ ] Does it follow the other guidelines from the new entries section?
[ ] Have you added the SVG for your logo to hosted_logos and referenced it in the entry in landscape.yml?
[ ] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[ ] Does your project name match the text on the logo?
[ ] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~5 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

Build failed because of:
No cached entry, and Open Shading Language (OSL) has issues with logo: osl.svg, Error in parsing SVG: Non-whitespace before first tag.
Line: 0
Column: 1
Char: �
Item Open Shading Language (OSL) has no image_data


The mapping port feature. Synchronization of database configs with corresponding environment. C# idiomatic refactoring.

Concurrent Test Execution

For сoncurrent test execution of testcontainers tests it is necessary to get random host ports. Now while creating a container you can see a flag PublishAllPorts = true which means that the container will be run with a docker run -P command publishing all exposed ports on random host ports.
https://github.com/Alksar/testcontainers-dotnet/blob/e44505a0eb07ff9b45dc529089eafe7c733801a8/TestContainers/Core/Containers/GenericContainer.cs#L213
To get a published port you should use a GetMappedPort(exposedPort)  on IContainer interface.

Synchronization of database name, user, password with corresponding environment vars

For additional configuration (like in a java repository) you can see a protected virtual void Configure() method in GenericContainer class with a stub implementation which is called right before ApplyConfiguration while creating a container.
Children can override it and set an additional configuration. For example containers which are inherited from the DatabaseContainer should be run with the environment vars making database name, user and password corresponding to the values which were set by DatabaseContainerBuilder.  Example for postgresql.

Ideomatic c# refactoring.

Now it will be easier for the .net developers to join the project with the refactoring in accordance with the Microsoft style guides:

explicit access modifier
advanced collection types like a HashSet or Dictionary
const naming
improved ContainerBuilder inheritance

I have updated PR accordingly to last master changes.
For each new container need to perform two steps:

override "void Configure()" method on container for custom configuration envs, e.t.c
create container builder if needed for fluent style creation of container

@Alksar Cool pull request. This port mapping feature would help us a lot. :heart_eyes:

Coming from the Java side, I'd strongly suggest that the 'publish all ports' behaviour should be the default. Our users almost never have difficulty understanding the concept, and the benefits are big (parallel test running being one, but also not having to care what else is running on a dev machine or CI box).

Coming from the Java side, I'd strongly suggest that the 'publish all ports' behaviour should be the default. Our users almost never have difficulty understanding the concept, and the benefits are big (parallel test running being one, but also not having to care what else is running on a dev machine or CI box).

@rnorth Yep! This PR is exactly about this. PublishAllPorts = true will be the default behavior


Upgrade APIScan version

PR Summary
APIScan tool version must be upgraded.
PR Context
Using older version is not compliant.
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[x] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

@PoshChan please rebuild all

@adityapatwardhan, did not find matching build context: PowerShell-CI-Windows; allowed contexts: PowerShell-CI-static-analysis

@PoshChan please retry static

@adityapatwardhan, successfully started retry of PowerShell-CI-static-analysis


⚠ Bofrost.be has degraded performance

In 6ccac74, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1421 ms

Resolved: Bofrost.be performance has improved in 33212df.


HttpShardHandler: Fix extension hook transformResponse

HttpShardHandler.transformResponse is an extension hook for subclasses to transform the shard response.  Ever since 9.0 when the HTTP2 Async stuff landed, this hook became inoperable/dormant (method existed but hasn't been called anymore).  This brings it back.
It's sufficiently minor that I'm thinking no JIRA/CHANGES.txt

@gerlowskija This seems to have landed a short time before your Parallel handler, but is not reflected in that implementation. Was that just an oversight due to near simultaneous development or a conscious omission due to some concern? The callback for both handlers is otherwise the same and maybe could be unified for re-use...

Also the spelling error in the method should be fixed... transfomResponse -> transformResponse. I suppose that has to be a 10x only change since it's an extension point.

Also the spelling error in the method should be fixed... transfomResponse -> transformResponse. I suppose that has to be a 10x only change since it's an extension point.

(I can do both of these this in a separate ticket after I push my changes for SOLR-17158 if noone objects ) The rename should have an associated Jira I think.

Renaming a protected method doesn't deserve a JIRA and wasting readers time to read about it in CHANGES.txt.

If users have implemented a custom handler (as is clearly implied via the doc on the method, and it's no-op default implementation) their code would need to be updated and rebuilt. Seems like something someone assessing an upgrade effort would want to know about...?

it's about a trivial change as changes go.  Users (and I count myself as impacted at work BTW) would find out upon upgrading.  Tons of other changes happen without CHANGES.txt prescribing every little detail as the name of a method.


Add useHostAsHostname to config

The hostname of a container in BRIDGE networking is being set to the CONTAINER ID when I really want it to be the hostname of the slave hosting the container.
Without the container knowing what host it's on, we can't have the akka workers talking to each other without some static setting of --hostname on the docker container.
As simple fix would be to add a param to the config that set's the hostname of the docker container to the host IP.
Docker exposes this as $HOST, however the config doesn't evaluate $HOST when passed to --hostname. See: #1328
This seems like it would be simple enough:
{
  "id": "echo-hostname",
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "nickpoorman/docker-echo-hostname",
      "network": "BRIDGE",
      "portMappings": [
        { "containerPort": 8090, "hostPort": 0, "protocol": "tcp" }
      ],
      "useHostAsHostname": true
    }
  },
  "instances": 1,
  "cpus": 1,
  "mem": 128
}

Without it this is what we get from docker-echo-hostname:
HOST = <IP_ADDRESS>
HOSTNAME = 738302d53b9a
hostname = 738302d53b9a
hostname -i = <IP_ADDRESS>

Then akka workers try to connect back to 738302d53b9a:<some port> which clearly won't work.

+1

If you run docker privileged this would automagically set the hostname correctly. Also iirc and u set the slaves hostname to an fqdn it will show as that instead of the ip.

Minor clarification: the HOST env is determined by the hostname arg passed to mesos-slave

Note: This issue has been migrated to https://jira.mesosphere.com/browse/MARATHON-4590. For more information see https://groups.google.com/forum/#!topic/marathon-framework/khtvf-ifnp8.


Auto-provisioning/auto-detection of IBM Semeru toolchains is broken with Gradle 7.6

Expected Behavior
Build works with gradle 7.5.1 and jdks are auto provisioned as declared in build.gradle:
java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(11))
        vendor = JvmVendorSpec.IBM_SEMERU
        implementation = JvmImplementation.J9
    }
}

Current Behavior

Upgrading to gradle 7.6 the build now fails with:
FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':buildSrc:compileGroovy'.
> Could not resolve all dependencies for configuration ':buildSrc:compileClasspath'.
   > Failed to calculate the value of task ':buildSrc:compileJava' property 'javaCompiler'.
      > Unable to download toolchain matching the requirements ({languageVersion=11, vendor=IBM_SEMERU, implementation=J9}) from 'https://api.adoptopenjdk.net/v3/binary/latest/11/ga/linux/x64/jdk/openj9/normal/adoptopenjdk'.
         > Toolchain provisioned from 'https://api.adoptopenjdk.net/v3/binary/latest/11/ga/linux/x64/jdk/openj9/normal/adoptopenjdk' doesn't satisfy the specification: {languageVersion=11, vendor=IBM_SEMERU, implementation=J9}.

Context

Auto-detection/auto-provisioning of Gradle toolchains is broken with gradle 7.6
Steps to Reproduce

Your Environment

Detected toolchains:
❯ ./gradlew -q javaToolchains

 + Options
     | Auto-detection:     Enabled
     | Auto-download:      Enabled

 + IBM JDK 11.0.17+8
     | Location:           ~/.gradle/jdks/ibm-semeru-open-jdk_x64_linux_11/jdk-11.0.17+8
     | Language Version:   11
     | Vendor:             IBM
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        Auto-provisioned by Gradle

 + IBM JDK 11.0.15+10
     | Location:           ~/.gradle/jdks/ibm_semeru-11-x64-openj9-linux/jdk-11.0.15+10
     | Language Version:   11
     | Vendor:             IBM
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        Auto-provisioned by Gradle

@jbartok could you please provide clarity on your previous statement? I don't quite understand where you/Gradle are getting Vendor: IBM Semeru Runtimes from. Perhaps it is a value set by SDKMAN?
When we released 11.0.15 this year (2022) we corrected the java.vendor property back to IBM Corporation. I don't believe we have any system properties that are set to IBM Semeru Runtimes. I could be missing something.
Thanks,
Adam

@jbartok
I assume this means that one of the next nightly builds could be used for verifying your changes?

@jbartok
I assume this means that one of the next nightly builds could be used for verifying your changes?

Yes, https://gradle.org/release-nightly/ should contain the fix (but this is a nightly for the upcoming 8.0 version).
7.6.1 should contain the fix too, but I don't see any nightlies available for that atm. Let me know if the above mentioned nightly is not ok for you to test with.

For reasons that I really don't get ... I can't reproduce the problem for me on MacOs.
I downloaded Semeru 11.0.17+8, and when I run our build with gradle 7.6, there

I changed my build setup to use jdk-11.0.17+8 and then pointed to gradle-8.0-20221216001954:

JAVA_HOME=/Users/xxxx/java/ibm/jdk-11.0.17+8/Contents/Home ./gradlew -q javaToolchain

Options
| Auto-detection:     Enabled
| Auto-download:      Enabled

IBM JDK 11.0.17+8
| Location:           /Users/guenthne/java/ibm/jdk-11.0.17+8/Contents/Home
| Language Version:   11
| Vendor:             IBM
| Architecture:       x86_64
| Is JDK:             true
| Detected by:        Current JVM

So, that part is working.


fix(wasm): validate filters in all persistence modes

Summary
The primary purpose of this change is to ensure that each .filters[].name is validated against available/installed filters in dbless mode (this was only working in db mode prior).
I also added an additional entity check which will return a more descriptive error when wasm is disabled or no filters are present (this is more useful for dbless mode than anything).
Checklist

[x] The Pull Request has tests
~[ ] There's an entry in the CHANGELOG~
~[ ] There is a user-facing docs PR~

Issue reference
KAG-2059

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: flrgh:x: RobSerafiniYou have signed the CLA already but the status is still pending? Let us recheck it.


python support

Just wanted to say, by luck this already works :)
Python region syntax is the same as C# region syntax in vscode, so you can just add a test case and announoce python support :)
I can confirm:

It was added.
Python multiline ''' region ... end region ''' comments support was added as well in v0.0.4.


OTR: def, synonyms for GO:2000984 negative regulation of ATP citrate synthase activity

Hi,
We had a user contact us through Helpdesk about the definition of GO:2000984 negative regulation of ATP citrate synthase activity:

Please fix an error on GO:2000984.
It indicates negative regulation of citrate synthase (CS) when actually it is ATP-citrate lyase (ACL).

Citrate synthase (forms citrate from oxaloacetate and acetylCoA in the mitochondrion with NO ATP involvement) is a different enzyme than ATP-citrate lyase (generates acetylCoA and oxaloacetate with the aid of ATP in the cytosol) and they catalyze different reactions (not the same one). At a glance it may look like they catalyze a bidirectional reaction but actually it is not.

Note, if the term is split or changed, the synonyms may also need to be addressed.  If you need further information from this user (https://biology.ucdavis.edu/people/cecilia-giulivi), I am providing them the ticket URL but don't know if they have a GH- please tag me to email them.
Thanks

This term (GO:2000984) regulates 'ATP citrate synthase' (GO:0003878), which refers to RHEA:21160/EC:<IP_ADDRESS>. According to EC, the official IUBMB name for this enzyme is 'ATP citrate synthase' and it is defined as the reaction: ADP + phosphate + acetyl-CoA + oxaloacetate = ATP + citrate + CoA. Note that this reaction does use ATP. An alternative name for the enzyme is 'citrate-ATP lyase', shown as a synonym.
Note there is a separate enzymatic activity 'citrate synthase activity' (GO:0036440) that corresponds to RHEA:16845 and does not use ATP in the reaction. The reaction is: acetyl-CoA + H2O + oxaloacetate = citrate + CoA + H(+). The enzyme comes in two flavors depending on which side of the oxaloacetate the acetyl group is added.
ping @suzialeksander

Thanks @ukemi, I've emailed the user to check if this can be closed.

Response:

Looks better than before. I'd add that the enzyme in the second paragraph that starts with Note is part of the Krebs' cycle whereas the one described in the first paragraph is not.

Also, can you clarify this sentence for me, please? "The enzyme comes in two flavors depending on which side of the oxaloacetate the acetyl group is added."

What flavors you mean? isoforms? different species?

GO:0050450 citrate (Re)-synthase activity: Catalysis of the reaction: acetyl-CoA + H2O + oxaloacetate = citrate + CoA, where the acetyl group is added to the re-face of oxaloacetate; acetyl-CoA provides the two carbon atoms of the pro-R carboxymethyl group. Source: MetaCyc:CITRATE-RE-SYNTHASE-RXN, EC:<IP_ADDRESS>, ISBN:0121227073
GO:0004108 citrate (Si)-synthase activity: Catalysis of the reaction: acetyl-CoA + H2O + oxaloacetate = citrate + CoA, where the acetyl group is added to the si-face of oxaloacetate; acetyl-CoA thus provides the two carbon atoms of the pro-S carboxymethyl group. Source: EC:<IP_ADDRESS>, ISBN:0121227073

Response:

Got it.
They are referring to the mammalian vs. others.

Thanks @ukemi


Sync error: value out of range for type integer

R/B 18728
PG::Error: ERROR: value "08050005200790000000" is out of range for type integer

File "app/models/synchronization/adapter.rb", line 257 in block in import_cleanup
File "app/models/user/db_service.rb", line 507 in in_database_direct_connection
File "app/models/synchronization/adapter.rb", line 207 in import_cleanup
File "app/models/synchronization/adapter.rb", line 33 in run
File "app/models/synchronization/member.rb", line 190 in run
File "lib/resque/synchronization_jobs.rb", line 13 in block in perform
File "lib/resque/base_job.rb", line 21 in call
File "lib/resque/base_job.rb", line 21 in run_action
File "lib/resque/synchronization_jobs.rb", line 10 in perform

sync id sample: 7afac97a-638d-11e5-8d91-0e23c2a19d43
Looks like it is failing in this line due to the casting:
https://github.com/CartoDB/cartodb/blob/b4a0bf98b96ed1624a71e77a6163adc99cb1c445/app/models/synchronization/adapter.rb#L257
cc/ @CartoDB/dataservices

So, this happens when we try to use the PK generated by ogr2ogr (ogc_fid or gid) for cartodb_id but it exceeds the capacity of integer.
On one hand we'll have to detect this situation and in another we must decide what to do: can we have a cartodb_id of a type different from integer? otherwise we may have to add a new cartodb_id unrelated to  ogc_fid/gid.

no, it's only a matter of changing the cast to integer to bigint, right?

It will fail if cartodb_id is of type integer:
# update jgoizueta.test set cartodb_id='08050005200790000000' where cartodb_id = 1;
ERROR:  value "08050005200790000000" is out of range for type integer
LINE 1: update jgoizueta.test set cartodb_id='0805000520079000...

# update jgoizueta.test set cartodb_id=CAST('08050005200790000000' as bigint) where cartodb_id = 1;
ERROR:  integer out of range

I think the best solution is to get the exception and use cartodb_id in case the ogc_fid/gid gives problem

I agree with @ethervoid


Corected last name of contributor

Oskar Damkjaers last name was spelled incorrectly in contributors file.

@Jocen01 🥰👏

The wonders of open source :1st_place_medal: :smiley:


Something incorrect abut the version of Azure CLI

[Enter feedback here]
The documentation mentions that CLI version 2.4 is required, but the latest version of Azure CLI is version 2.34.1

This page provides the latest version is 2.34.1

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

ID: 8962c9c8-f550-db2f-6573-0dea51802a6e
Version Independent ID: 6340d0ac-0f03-3484-1a6b-d4bb5b64d645
Content: Create a C# function from the command line - Azure Functions
Content Source: articles/azure-functions/create-first-function-cli-csharp.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

@Adamgneh Thank you for your feedback! We will review and update as appropriate.

@Adamgneh As per the version document Version 2.4.0 is the previous version which was released on April 21, 2020 and yes the current latest version is 2.34.1
The function document calls out correctly on the minimum version for CLI as version 2.4 or later
Feel free to get back to me if you have any queries or concerns.


Order by custom field with custom ordering logic

Is your feature request related to a problem? Please describe.
We are using custom fields to support filtering on a composite ecto type. Specifically, we use ex_money which has a type which is backed by a composite PostgreSQL type which stores amounts as {string, decimal}. Filtering works well by defining the respective custom fields along with custom filtering logic:
custom_fields: [
      amount_amount: [
        filter: {Filters, :money, [source: :amount, field_name: "amount"]},
        ecto_type: :decimal
      ],
      amount_currency: [
        filter: {Filters, :money_currency, [source: :amount]},
        ecto_type: :string
      ]
    ]

However we also need to use the custom fields for sorting, but this is not supported.
Describe the solution you'd like
The optimal solution for us would be to have the same mechanism currently supported for filtering custom fields to be able to specify custom ordering for the composite fields.
Describe alternatives you've considered
The documentation suggests alias fields but apparently you can't support both filtering and sorting with an alias field. Also, these are stored values, not computed.
Additional context
This is more of a question about understanding the motivation behind disallowing ordering for custom fields. Is there any issue that prevents this or is it just missing functionality. In the latter case, we'd might give a shot at implementing support for this.

For filtering, all you need to do to implement a custom field is to define a function that adds a where clause to the query. For sorting, you will not only need to add an order by clause. Flop would also not be able to build the where clause for you that is needed for cursor-based pagination. So you would have to handle the whole cursor-pagination logic on your own.
Then the question is what the interface for that should look like. A single custom field function for sorting wouldn't be enough, and since you could have multiple custom fields available for sorting, the function for applying the cursor where clause needs to be defined separately from the custom fields. I don't know from the top of my head how that interface should look like. It would also take one of the core features out of Flop and into your hands.
The easy way out would be to disallow cursor-based pagination as soon as a custom field is marked as sortable. The better way would be to revisit the idea for derived/dynamic fields at some point. There are other features I'd like to work on before that, though, so this has no priority for me at the moment.
So that's in a nutshell why it is not supported at the moment.

There is one workaround you can do right now in your situation. You can define join fields for anything that you can put a binding name on. This means you can do a lateral join on a sub query, add a named binding to it, and define a join field referencing that binding.
I didn't have an application with ex_money ready, but I did have one with a Postgres tsrange field.
So first you define a sub query that basically unpacks the composite type:
publish_period_query =
  from(
    f in fragment(
      "select lower(?) as lower, upper(?) as upper",
      parent_as(:article).publish_period,
      parent_as(:article).publish_period
    ),
    select: %{lower: f.lower, upper: f.upper}
  )

I don't know how else to select fields that don't come from a separate Ecto query. Also, Ecto doesn't allow you to select f directly, you have to explicitly select a map from the fragment. Maybe this can be written in a nicer way, but anyway, bear with me.
You can now perform a lateral join on that sub query and give it a name:
  q =
    from(a in Article,
      as: :article,
      inner_lateral_join: pp in subquery(publish_period_query),
      as: :publish_period
    )

The resulting SQL query will look something like this:
SELECT ... FROM "articles" AS a0
INNER JOIN LATERAL
  (
    SELECT sf0."lower" AS "lower", sf0."upper" AS "upper"
    FROM (select lower(a0."publish_period") as lower, upper(a0."publish_period") as upper) AS sf0
  ) AS s1 ON TRUE

If you were to write this query in raw SQL, you could of course simplify this quite a bit, but we're bound by the Ecto syntax here.
This admittedly looks quite horrible, but the good news is that the PostgreSQL optimizer is smart enough to see through this nonsense. Running that query as it is results in this query plan:
Seq Scan on articles a0  (cost=0.00..5.75 rows=50 width=2793)

And if you add the where clause where([publish_period: pp], pp.lower <= ^DateTime.utc_now()):
Seq Scan on articles a0  (cost=0.00..5.75 rows=17 width=2793)

Filter: (lower(publish_period) <= '2023-06-13 11:37:53.976703'::timestamp without time zone)

So the sub queries from the generated query are optimized away.

Thanks for the context around this and the suggestions. Indeed, we are using cursor based pagination. Another option we are investigating is using the composite field directly for sorting, since it should be simpler and works for us.
This kinda works, but there is an issue with cursor pagination we are trying to make sense of.


How does spec_helper get included in rails_helper?

As far as I can tell, right now the answer seems to be "it doesn't". Even so, sometimes it seems to be loaded, but I can't figure out why or how.
Shouldn't there be an explicit require 'spec_helper'?

Actually, it looks like it gets included via the .rspec file, which includes --require spec_helper. If we do it that way, we need to remove .rspec from .gitignore. Otherwise, we need to explicitly require spec_helper in rails_helper.

I vote we remove .rspec


Accounts: guitar emoji is clipped at bottom

I'm blaming this one on Big Sur.  This doesn't happen on Catalina at least.  Currently, I have no idea how to work around this except by maybe making a custom NSTextField subclass.

@vincode-io Go to the Title in the xib, select the last character (after the guitar), then Option + Return to add an extra line.

@stuartbreckenridge Thanks for the tip!


[Improvised][3.1.0] Refactored Getting Started Collection

Purpose
Refactored the Getting Started MD Collection of the 3.1.0 branch with the following checks

Improve readability (end-user)
Improve readability and maintainability for developer/writer-friendly
Lint, Grammar, and Spell Checks

@athiththan11  please feel free to reopen the issue when you are free to work on it.


Autocompletion for the command line

I'd like the cci cli to support autocomplete.
We're moving from mostly sfdx to a cci-based workflow and I'm missing autocomplete.
Rumor has it, the ClickCLI library you are using already supports an autocomplete functionality.
Ideally, the feature would work just as it does for SFDX - I'd add something to my ~/.profile that would run cci autocomplete or similar. That command would output the right data that I could then ingest into my shell.
Thanks!

Yes, click supports this. Here are its docs on how to activate it for different shells: https://click.palletsprojects.com/en/7.x/bashcomplete/#activation
So for example with zsh you just need to add this to ~/.zshrc: eval "$(_CCI_COMPLETE=source_zsh cci)"
Let us know how your experience with it is. I think that autocompleting most command and option names should work, as well as task names for cci task run, but we'll need to make some adjustments to make it work for cci task info, cci flow info, and cci flow run.

That does work, but it's slow. I see python flash across my terminal every time I hit tab. It takes about 1.5 seconds to respond when I hit tab. With sfdx, it generates a static list when I start bash and the tab completions are instantaneous.
I looked into the https://click.palletsprojects.com/en/7.x/bashcomplete/#activation-script section, but that didn't seem to work either.
From the click site

At least Zsh will also cache the results of completion files
Maybe time for me to migrate to zsh.

@avisser Part of the challenge is that unlike sfdx, in cci the tasks and flows that are available for completion will vary from project to project based on what is configured in cumulusci.yml. So it can't be just a static list that's initialized when the shell starts.

This is a pretty good work around.

This is a pretty good work around.

Closing since we have something that sort of works and don't have a clear path to improving it. Improvements welcome, though.


Build Conda and Pip Support

As a first step for packaging I would suggest that we don't focus on packaging numbast/canopy (or at least not releasing them).  Instead, I think it would be useful to package and release the resulting bindings for BF16.  @isVoid and I chatted about this briefly .  One idea here is to package bf16 as numba_extensions.bf16 .  This allow us to clearly define what the extensions are for and enable future packaging bindings as well


Add pretend mode to print branches instead of deleting them

Description
Inspired by Laravel php artisan migrate --pretend, that prints SQL queries instead of running them on the database.
I have added a new flag to git trim named --explain, that prints branches going to be trimmed instead of actually deleting them.
This will solve the problem of not knowing what branches are going to be impacted, fearing to delete unwanted branches.
Note to @jasonmccreary : This mode is called pretend mode but since the p flag is already taken by prunned I named the flag explain instead, feel free to come up with a better term, if planning to merge this.
Changes

Added --explain flag to git trim option.

Thanks,

I like it. I like --print too. However, in its absence, I wonder if --dry-run is a more suitable option than --explain?

@jasonmccreary --dry-run for me would make more sense here. --print will have conflicts with --pruned shorthand flag,
even if we chose to use -pr for a shorthand flag. Still reads as pruned

BTW, I didn't add the print flag to the delete remote branches. my assumption is that remote branches can be recovered if deleted accidently.

@mohammed-elhaouari, let's go with --dry-run then. No shorthand. I'm actually in the process of removing some of the option shorthands anyway.
I don't know about global variables in Shell scripts, but I wonder if we just move the branch deletion to a shared function. That would make easier do the "dry run check" in one place.

@jasonmccreary that would make more sense, yes. Having one function like the one remove_remote_branch() would make it much easier & simpler.
I guess that function would accept branch names as argument. Then it deletes or prints those branch names based on the dry_run argument in one loop.

Exactly. Just don't know about "global" variables within a Shell script. 😅


all contributors test

@all-contributors please add @orsou  for code

@all-contributors please add @orsou for code

@all-contributors please add @orsou for doc

@all-contributors please add @orsou for maintenance,projectManagement,ideas,design,example,review,tutorial,content

@all-contributors please add @orsou for maintenance

@all-contributors please add @orsou for projectManagement

@all-contributors please add @orsou for ideas

@all-contributors please add @orsou for design

@all-contributors please add @orsou for example

@all-contributors please add @orsou for review

@all-contributors please add @orsou for tutorial, content


Update community_connectors.json

Added HearthstoneJSON connector

Oops looks like you left the source code link from copy paste :) Can you fix that (either add a link to your source or you can remove it, it's optional).  Then I'll merge.  Thanks!


nixos/doc: fix instructions for nox-review usage

Motivation for this change
I was submitting a change and the instructions in the manual for running nox-review did not work and I was uncertain why. Then I realized that the instructions in the template were slightly different, needing quotes after --run so I tried that and it worked. Fixing the manual instructions to match the PR template.
Relevant PR template part:

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"

Thank you!


Regression on 0.7.2

Describe the bug
I tried implementing the single room from #128 , but it didn't work as expected. I have message errors (not being the right format) and the same issues when I remove the room-id when using it with a single room. Moreover, my messages sent were at the left (where recieved messages are supposed to stand)
Steps to reproduce
Create a chat window component without room-id
Expected behavior
Work as shown in the example but with a single room.
Right now I downgrade to 0.7.0 and I am using it with room-id
Device (please complete the following information)
OS: OSX
Browser: Chrome Canary, Mozilla
Package version: 0.7.2
Additional context
This is a great Vue package right here, however, I strongly recommend the author to add a minimal number of solid tests, this will strongly help the component scale and avoid such regressions

Please check https://github.com/antoine92190/vue-advanced-chat/releases/tag/0.7.1 for breaking changes

I agree about adding tests, but I will not be able to do it soon.


Videos are not loading on dashboard

I got 2 actions here
1st is test-e2e.yml it uploads the video dashboard run 14
2nd is cypres.yml, that uses cypress-io/github-action; doesn't upload the video dashboard run 15
made it looking at an example cypress-realworld-app, am I doing anything wrong?

@Renato66 These runs are showing as being run in Cypress 3.8.3. Please try updating to the latest version as this version is very old to see if the issue persists because it may have been fixed.

@jennifer-shehane thanks, it's working now :D


Provide more details on route parentRef in documentation for routes <> Gateways attachment.

What type of PR is this?
/kind documentation
What this PR does / why we need it:
gep-957 proposed to add Port to ParentRef, in addition to existing fields. This PR updates existing route attachment documentation to provide more details on parentRef,
Fixes #1021
Does this PR introduce a user-facing change?:
NONE

/ok-to-test
/approve

Yep, this looks great, thanks @cxhiano!
/lgtm


Library for

Hello,
Do you all happen to have a library and example for The MSA v1 OAuth 2.0 protocol for 1st party site?  Look to implement that flow with redirecting to the login page (not popup).
The MSA v1 OAuth 2.0 protocol: When clients implement MSA v1 OAuth, they communicate directly with the MSA login system at https://login.live.com. The MSA v1 OAuth protocol supports only MSA users - it does not support Azure AD users whatsoever. If your goal is for your clients to get tokens from the MSA v1 OAuth protocol, this is the correct choice for you.
Thanks

@jrmcdona I am not aware of any such library. Please post your question on StackOverflow to get a response to your query.


Confusing BootJDK environment settings for builds within a docker container

When pipelines/build/common/openjdk_build_pipeline.groovy starts a build within a docker container, it utilises the Jenkins
docker plugin which by default inherits environment variable settings from the host:
https://github.com/adoptium/ci-jenkins-pipelines/blob/dec39227bc0bcf3069f54aef298a7872ab451cf0/pipelines/build/common/openjdk_build_pipeline.groovy#L1600
This means the JDKnn_BOOT_DIR agent configuration settings from the host get set within the container, which may or may not be correct..?
Required boot jdk within the container may not be valid on the host, so requiring setting the value in the agent is perhaps confusing to a host user.
The docker container should be self configuring, so maybe we prevent the Jenkins inside docker plugin inheritting the environment?

All of the docker build images should set them directly e.g. https://github.com/adoptium/infrastructure/blob/69b696162f37caf612ae7a035c4a8659a64f8f3a/ansible/docker/Dockerfile.Alpine3#L16 so I can't see why it would make more sense to pull the variable from the host in preference to that, if that's what's really happening.

All of the docker build images should set them directly e.g. https://github.com/adoptium/infrastructure/blob/69b696162f37caf612ae7a035c4a8659a64f8f3a/ansible/docker/Dockerfile.Alpine3#L16 so I can't see why it would make more sense to pull the variable from the host in preference to that, if that's what's really happening.

It is, and always has been a confusion I believe. However, if we stop inheriting the host agent environment, it's possible other builders like OpenJ9 might have issues, @AdamBrousseau ?

from https://support.cloudbees.com/hc/en-us/articles/226520788-Control-environment-variables-inside-a-Docker-container
`By default, when using the Docker Pipeline plugin the node’s environment variables will not be propagated to the docker container - since with Docker you want to get isolate environments. You can check this here
However, if at Node level (http/s://<JENKINS_URL>/computer/<MY_AGENT>/configure), under Node Properties, you add Environment variables, those will be added to the container.
I think in our case, we are doing Running on [docker-equinix-ubuntu2004-armv8-1](https://ci.adoptopenjdk.net/computer/docker-equinix-ubuntu2004-armv8-1/) and we have config for docker-equinix-ubuntu2004-armv8-1 with env variable e.g JDK10_BOOT_DIR set with a value different from what we specified in our Dockerfile.Alpiene3.
This value then passed down at "docker run" runtime. so the one from Jenkins Config will be used when the build starts


[ALLUXIO-2613] Fix grammar in Running HBase Prerequisites

https://alluxio.atlassian.net/browse/ALLUXIO-2613
[ALLUXIO2613] Fix grammar in Running HBase Prerequisites

alluxio-bot, check this please

alluxio-bot, check this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/14435/
Test PASSed.


Fix in one of the PersistenceXmlParser.parse() methods used in tests

Signed-off-by: Jan Schatteman<EMAIL_ADDRESS>

Converted back to draft for now


latest.release not working correctly with multi-projects

I have an simple multi project configuration
lazy val core = project
                  .in(file("."))
                  .settings(commonSettings)

lazy val benchmarks = project
  .dependsOn(core)
  .settings(commonSettings)
  .enablePlugins(JmhPlugin)

and I have a dependency where I want to use ivy's "latest.release" version in order to build always with the latest version of a dependency:
libraryDependencies += ("com.x.y" %% "something" % "latest.release")

but when I run sbt compile I get the following error:
[error] (update) found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[error]
[error] 	* com.x.y:something_2.13:1.0.2023051023 (semver-spec) is selected over latest.release
[error] 	    +- myproject:project_3:1.0-SNAPSHOT                   (depends on 1.0.2023051023)
[error] 	    +- com.x.y:something_2.13:1.0.2023051023 (depends on latest.release)
[error]
[error]
[error] this can be overridden using libraryDependencySchemes or evictionErrorLevel

I think that sbt is getting confused between the symbolic label "latest.release" and the actual latest release version "1.0.2023051023" which are the same.

@xelax Thanks for the report. Eviction error is written based on the UpdateReport returned from Coursier.
Could you also report this to coursier/coursier please?

I worked around this issue using "1.0-+" as release, but I don't get the expected behavior of sbt updating automatically to the newest release: i need to force it either by removing the cache manually or replacing a specific version for a build


"techmap -map +/cmp2lcu.v" for decomposing arithmetic compares to $lcu

More efficient than treating $gt $ge $lt $le as ALU operations by having each stage of the carry chain compare more than one pair of bits (number of bits controlled by  `LUT_WIDTH macro).
Question remains whether it is more efficient to use the carry-chain at all, since if it was all soft-logic then technology mapping into LUTs has more flexibility...
Also, for specific technologies, it may be more efficient to instantiate a primitive (e.g. LUT6_2 for Xilinx) in order to make even more efficient use of the fracturable LUT that feeds the carry.
Currently demonstrated inside synth_xilinx using -D LUT_WIDTH=6 since there is no guarantee that -D LUT_WIDTH=5 will cause two fracture-compatible LUTs (i.e. with shared inputs) to be created. Ideas welcome here. +/xilinx/arith_map.v then maps $lcu to CARRY4.

Sorry, my original statement was along the lines of stamping out a LUT6_2 (much like stamping out a SB_LUT4) and using opt_lut to cram things into it.

Right--that's exactly how gate2lut works, no? Or am I misunderstanding?

Kind of? gate2lut is only necessary to create bigger-than-necessary $lut cells that opt_lut can then recognise. An alternative would be to skip gate2lut entirely and work on any built-in Yosys (bit-level) cell.

Not directly related to the topic, but could this be put in synth -lut K like techmap -map +/cmp2lut.v already is? #1554 uses synth -lut K -run :fine for its coarse stage

Yes, I think that's a reasonable suggestion.

I think the coarse stage of synth is already unnecessarily duplicated across ECP5, iCE40 and Xilinx. (perhaps synth should grow a -mul2dsp option?)

As you've spotted, the initial reason we needed to break away from synth is when we started adding multiplier/DSP support, however, since then there has been some further deviation, namely wide multiplexer support too, which could also potentially go into this more general synth under some option -- this is something @mwkmwkmwk has been pushing for too. Let's discuss this in a separate issue though.


support passing the pass manager for programatic approach

Summary
support passing the pass manager. but in the GUI, the skip_transpiler is still used.
we might need to figure out how to declaratively create pass manger.
Details and comments

related to #149


⚠ RPC server - Binance BSCT has degraded performance

In 4aec9df, RPC server - Binance BSCT ($BINANCE_BSCT_RPC_URL) experienced degraded performance:

HTTP code: 502
Response time: 2671 ms

Resolved: RPC server - Binance BSCT performance has improved in 35e3e6b.


TS errors leak on git undo

open a TS files
create an error
close the file, as expected errors still show
git undo the changes
🐛 errors still show tho they shouldn't

Duplicate #8719


Clarify supported features before WG last calls

For each document

draft-ietf-suit-manifest
draft-ietf-suit-trust-domains
draft-ietf-suit-update-management
draft-ietf-suit-firmware-encryption
draft-ietf-suit-report

Done in #4 , see SUPPORTED.md


Add tests

Add unit testing module and demonstrate tests for the functions

Working on this

Some tests have been added so we can close this since the harness is there now


Should sphinx-docs/build and sphinx-docs/source/md be ignored?

Hi!
I started to look into #660 , #661 and ran make html from sphinx-docs. It appears that #660 has been fixed? I was able to reproduce the warning messages in #661 .
I noticed that the folders sphinx-docs/build and sphinx-source/md, which are generated by the make command, are not ignored. Instead, this folder is ignored
https://github.com/microsoft/InnerEye-DeepLearning/blob/8a78ec8c1e20e1f20ae551bbf21d6e9cd05f891c/.gitignore#L86-L87
should this be changed?
AB#5206

You're right. It looks like we should ignore sphinx-docs/build and sphinx-docs/source/md.


Added changes for istanbul consensus

Will this ever be added? Awesome project btw

This implementation is not integrated with nodemaganer？


Perch Runway 3 support

Hello,
Thanks for the app, it's very handy to review all member tags.
The app seems to be functioning with Perch Runway 3, but there are a few visual glitches with the unstyled subnav, delete buttons, and row underline. It probably needs a few minor markup changes.

Hi - yes I'm aware of that - there are some changes that have to be applied for it to work properly with Perch 3.  I've been very slack in not doing it, but I will get to it soon.  It's not too tricky to do.
Cheers.

New version released.

New version released.


brew install minishift

It would be super cool to have a brew install command for minishift which could handle updates etc. as well.
And yes I know it's super easy to download and install a binary but devs are lazy and aren't always aware when there are updates - brew does a great job of handling this.

Well it should do autoupdate... but I think @msavy is working on a cask.

Thanks to @lburgazzoli - brew cask install minishift

This is awesome, thanks @lburgazzoli


[Question]:  The error with Joint QA Summary Query Engine

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
I use the Joint QA Summary Query [Engine]((https://docs.llamaindex.ai/en/stable/examples/query_engine/JointQASummary.html),  with the LLM( Qwen-72B-Chat , not gpt-4),    llama-index version 0.10.15
My code as bellow:
from llama_index.core.composability import QASummaryQueryEngineBuilder
from llama_index.core import SimpleDirectoryReader
from llama_index.llms.openai import OpenAI
from langchain_community.embeddings import (
    HuggingFaceBgeEmbeddings,
    HuggingFaceEmbeddings,
)

class MyEmbeddings(HuggingFaceEmbeddings):
    def __init__(self, **kwargs: Any):
        super().__init__(**kwargs)
    xxx ...

_hf = MyEmbeddings(
        model_name=M3E_BASE_PATH,
        model_kwargs={'device': 'cuda'},
        encode_kwargs={'normalize_embeddings': True}
    )
client = OpenAI(
        # This is the default and can be omitted
        base_url=os.environ.get("OPENAI_API_BASE"),
        api_key=os.environ.get("OPENAI_API_KEY"),
        temperature=0,
        embeddings=_hf
    )

query_engine_builder = QASummaryQueryEngineBuilder(
    llm=client,
)

print("-------------21")
start_time01 = time.time()
reader = SimpleDirectoryReader(source_doc_path)
documents = reader.load_data()

query_engine = query_engine_builder.build_from_documents(documents)
end_time01 = time.time()
execution_time01 = (end_time01 - start_time01) / 60.0
print("execution_time01: ", execution_time01, "min")
print("-------------22")

the error is as bellow:

Please help me

I think you have not set things up correctly
You will need the langchain wrapper if you want to use langchain embeddings
pip install llama-index-embeddings-langchain

from llama_index.core import Settings
from llama_index.embeddings.langchain import LangchainEmbedding

Settings.embed_model = LangchainEmbedding(_hf)
Settings.llm = OpenAI(
        base_url=os.environ.get("OPENAI_API_BASE"),
        api_key=os.environ.get("OPENAI_API_KEY"),
        temperature=0,
)

And that's it, this will set these two as the global default

I think you have not set things up correctly
You will need the langchain wrapper if you want to use langchain embeddings
pip install llama-index-embeddings-langchain

from llama_index.core import Settings
from llama_index.embeddings.langchain import LangchainEmbedding

Settings.embed_model = LangchainEmbedding(_hf)
Settings.llm = OpenAI(
        base_url=os.environ.get("OPENAI_API_BASE"),
        api_key=os.environ.get("OPENAI_API_KEY"),
        temperature=0,
)

And that's it, this will set these two as the global default

Ok, Thank you very much !


Bump go to latest version

Codecov Report

Merging #54 (168164f) into main (641181c) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main      #54   +/-   ##
=======================================
  Coverage   76.33%   76.33%
=======================================
  Files          57       57
  Lines        5818     5818
=======================================
  Hits         4441     4441
  Misses       1074     1074
  Partials      303      303

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more