Move weave script into tools image with its deps

This rearrangement means that the weave command can be used
remotely; and, as a side-effect, the script that does all the work is
using executables in its own filesystem, rather than invoking them via
docker.
A choice here is whether to base the tools image on scratch and add
all the deps, or base it on something else. I've used alpine linux,
which itself is based on busybox. This gives us the usual tools (sed
etc.) while keeping the image size small.
Adding the docker binary adds substantially to the image size, but it
cannot always be e.g., bind-mounted. To mitigate this image bloat, we
might build or otherwise get a client-only docker executable, or write
a special-purpose client, or indeed rewrite the driver script and use
a client library.
Closes #312, improves on #321

The definition of TOOLS_IMAGE has been removed from the driver script, but it is still being used - by setup and version. This also raises the question of what these two commands should do now. setup is meant to download all required images for the version corresponding to the script. But the driver script is part of an image. So do we need a version on the new weave script, and run the setup command there?

Surely the release script needs updating, to 'sed' the version number into the 'driver' script. Or we should get rid of that code and only have the tools image version.

We need to update the docs to explain that the weave script and docker daemon do not need to be co-located (our installation instructions do kinda imply that) when DOCKER_HOST is set.

I can think of one thing that will break for sure: the kind of scenario for which we introduced create-bridge and made hide and expose not depend on docker. See #357 and #377. It seems to me that the only way to solve that would be to have alternate mode of operation where the the weave script executes everything locally, as before. Or at least those three commands (w/o duplicating the code).

I can think of one thing that will break for sure: the kind of scenario for which we introduced create-bridge and made hide and expose not depend on docker. See #357 and #377. It seems to me that the only way to solve that would be to have alternate mode of operation where the the weave script executes everything locally, as before. Or at least those three commands (w/o duplicating the code).

In terms of create-bridge, one can install the driver script on the host...
Looking the diff between weave script in master and driver script here:
47d46
< BASE_TOOLS_IMAGE=zettio/weavetools
50d48
< TOOLS_IMAGE=$BASE_TOOLS_IMAGE:$IMAGE_VERSION
72,78d69
< run_tool() {
<     TOOL_NET=$1
<     TOOL_COMMAND=$2
<     shift 2
<     docker run --rm --privileged --net=$TOOL_NET $TOOLS_IMAGE /bin/$TOOL_COMMAND "$@"
< }
<
143,147c134
<         # disable offloading - we do this even when $BRIDGE already exists
<         # simply because it has the desirable side-effect of ensuring we
<         # have the $TOOLS_IMAGE and thus do not incur downloading-induced
<         # delays in more time-sensitive sections elsewhere.
<         run_tool host ethtool -K $BRIDGE tx off >/dev/null
---
>         ethtool -K $BRIDGE tx off >/dev/null
228c215
<     if run_tool host ethtool -K $GUEST_IFNAME tx off >/dev/null &&
---
>     if ethtool -K $GUEST_IFNAME tx off >/dev/null &&
247c234
<         run_tool container:$CONTAINER ethtool -K eth0 tx off >/dev/null &&
---
>         ip netns exec $NETNS ethtool -K eth0 tx off >/dev/null &&
327c314
<     run_tool host curl -s -X $http_verb "$@" http://$ip:$port$url
---
>     curl -s -X $http_verb "$@" http://$ip:$port$url
622c609
<         run_tool host conntrack -D -p udp --dport $PORT >/dev/null 2>&1 || true
---
>         conntrack -D -p udp --dport $PORT >/dev/null 2>&1 || true
637c624
<         run_tool host conntrack -D -p udp --dport $PORT >/dev/null 2>&1 || true
---
>         conntrack -D -p udp --dport $PORT >/dev/null 2>&1 || true

All I can see is run_tool being removed. So dual-mode driver script can be done by means of re-introducing run_tool it with a bypass mode. The only somewhat tricky part seems to be:
247c234
<         run_tool container:$CONTAINER ethtool -K eth0 tx off >/dev/null &&
---
>         ip netns exec $NETNS ethtool -K eth0 tx off >/dev/null &&

Another thing that breaks: env vars, specifically any env vars that the current weave script pays attention to. Which are:

VERSION
WEAVE_DOCKER_ARGS
DOCKER_BRIDGE
PROC_FS

The definition of TOOLS_IMAGE has been removed from the driver script, but it is still being used - by setup and version. This also raises the question of what these two commands should do now. setup is meant to download all required images for the version corresponding to the script. But the driver script is part of an image. So do we need a version on the new weave script, and run the setup command there?

The weave script is the entry point, so I think that is what has to be versioned ultimately. Then the images are locked to that version -- i.e., what happens now. The version is then in two places: in the driver script, so it asks for the correct images, and in the weave script. The weave script simply asks for the versioned tools image, which has its version built-in.
We could alter things so that the outer script knew about versioning, so that you could do e.g., weave setup 0.9.0 and have it install the correct images. But that's a bunch more work and I'm not sure we want to second-guess packaging.

Surely the release script needs updating, to 'sed' the version number into the 'driver' script. Or we should get rid of that code and only have the tools image version.

Yes, it needs updating.

We need to update the docs to explain that the weave script and docker daemon do not need to be co-located (our installation instructions do kinda imply that) when DOCKER_HOST is set.

Yes.

I can think of one thing that will break for sure: the kind of scenario for which we introduced create-bridge and made hide and expose not depend on docker. See #357 and #377. It seems to me that the only way to solve that would be to have alternate mode of operation where the the weave script executes everything locally, as before. Or at least those three commands (w/o duplicating the code).

I have to admit I don't see how that can work without some contortions (e.g., put those commands in the weave script and include it in the image too, then call it from the driver when necessary).

Another thing that breaks: env vars, specifically any env vars that the current weave script pays attention to. Which are:
VERSION
WEAVE_DOCKER_ARGS
WEAVE_PASSWORD
DOCKER_BRIDGE
PROC_FS

These would need to be passed as -e arguments if present. The PROC_FS already gets passed, since it's tied to how the tools container is started. I'll have to look at the rationale for the password being in the environment -- it may not be acceptable to pass it over to docker as a command line arg.

It seems to me that the only way to solve that would be to have alternate mode of operation where the the weave script executes everything locally, as before.

The logic in weave is to always forward commands to a docker container, but it could check if there's a  docker URL and assume it can effect things locally if it's absent or a unix domain socket (or have a special --local option).
If these must be special-cased anyway, it's then not such a big deal to include the weave script in the tools image and use it for these particular commands.

WEAVE_PASSWORD

The aim of moving this into an environment variable is to give people a way to supply it without putting it on the command line. To achieve the same thing with the remote-actuation weave script, the password option parsing should be moved from the driver script to the weave script, and the driver script should receive it in an environment variable which is passes on to the container.

it could check if there's a docker URL and assume it can effect things locally if it's absent

That's what I was thinking. Doesn't mean it's the best approach though ;)

it could check if there's a docker URL and assume it can effect things locally if it's absent
That's what I was thinking. Doesn't mean it's the best approach though ;)

I favour the --local alternative, since these are niche uses.

These would need to be passed as -e arguments if present.

VERSION, WEAVE_DOCKER_ARGS, DOCKER_BRIDGE, and WEAVE_PASSWORD can all get passed directly along.
In the case of WEAVE_PASSWORD, there's no need to do the arg parsing first as described above, since it will pass along any arguments as well as the environment variable if present.

The PROC_FS already gets passed, since it's tied to how the tools container is started.

An elaboration: when acting as a remote, PROCFS refers to the host filesystem that should be mapped as a volume to /hostproc; when acting locally, it refers to the proc filesystem with namespaces etc. So when running the tools container remotely, the host proc filesystem is mounted as /hostproc, and /hostproc is passed as the value of PROCFS.

VERSION is a tricky one.
If it determines the weavetools image to run when acting remotely, it will mostly fail since earlier versions aren't set up to be called remotely -- for one thing they don't have the script in the container image.
If the latest weavetools image is always invoked remotely, it seems against the spirit of using VERSION in the first place, although it will do the right thing mostly, which is to use weave and weavedns images of the given version.

How does a user run this?  Like docker run zettio/weave weave run ... ?

How does a user run this? Like docker run zettio/weave weave run ... ?

As before, the user is expected to download the weave script and call weave whatever. The difference is that it will forward the call to the weavetools image on a remote docker instance, if a DOCKER_HOST is given.
(There's also the option of driving weavetools directly with the docker CLI, but that needs you to get a bunch of docker options exactly right)

This also raises the question of what these two commands should do now. setup is meant to download all required images for the version corresponding to the script. But the driver script is part of an image. So do we need a version on the new weave script, and run the setup command there?

I am trying to figure out what we want to happen, and I think it's this:
If the invoked weave script has a version, or is given a version, it should try to call that remotely; this means

That version of weavetools will be started (downloaded, possibly) to run the command
It will setup or start that version of weave and weavedns

A problem is that if you want to remote control a version 0.8 weave, it'll fail because weavetools v0.8 doesn't have the weave script and therefore cannot be called remotely.

Making remoting work with old weaves is a nice-to-have at best.

This is ready for another go-round. I'm going to test the release procedure, since I've changed the image name and so on.

This is ready for another go-round.

Rebased. Ready for another look.

site/building.md needs updating - it references weavetools.
I'm curious whether we still need --without-ethtool. Could we ditch it? Replace with a "run if exists"?

I'm curious whether we still need --without-ethtool. Could we ditch it? Replace with a "run if exists"?

Based on the rationale given in #357, I think the answer is yes, we can ditch it.

Based on the rationale given in #357, I think the answer is yes, we can ditch it.

Hmm. There may be more to that. I wonder whether there's an assumption that weave --local create-bridge works w/o having ethtool installed. I can see how that might be useful. So perhaps leave as is.

docker versioning is an issue. the weavexec image will contain a docker binary based on whatever version happens to be current in alpine linux at the time. Docker daemons are backward compatible. But not forward compatible. So if the version in weaveexec is more recent than the docker daemon we are trying to talk to then things will break.
So we really want weavexec to include as old a version of docker as possible. At a bare minimum, the docker included in weavexec must support weave's usage of docker. But there is a tension here... weave generically wraps some docker commands. So, in particular, weave run wraps docker run. Since command line parsing is performed by the docker client, and there has been some change to docker run parameters over recent versions, we really want to include as new a version of docker as possible. So we want want both the oldest possible (for compatibility with the most docker daemons), an newest possible version (for compatibility with the most applications).

version pinning in apk

So we want want both the oldest possible (for compatibility with the most docker daemons), an newest possible version (for compatibility with the most applications). Which is somewhat problematic.

It's OK if we special-case weave run to use the user's docker instead of the weaveexec one. This special casing is necessary in the proxy branch anyway (since run has to go through the proxy).

It's OK if we special-case weave run to use the user's docker instead of the weaveexec one.

There is some stuff that has to happen on the host, though; specifically, attaching the weave IP, and finding the IP address to give the container to use for DNS. The former is just weave attach, run remotely if necessary. The latter would need a new command (say ./weave dns-config).

The latter would need a new command (say weave dns-config).

i.e. in order to return the DNS server IP, so it can be fed into the docker run invocation?

i.e. in order to return the DNS server IP, so it can be fed into the docker run invocation?

Yus

It occurs to me that we could remove all the existence and versions checks for ip and docker. Technically they are still useful for invocation with --local, but that is advanced (and undocumented) usage of weave and thus can get away with less handholding.

I believe this also closes #45. @squaremo do you agree?

As a follow-up, we should look into packaging a docker client instead of installing the full-blown docker exe in the weavexec image.

As a follow-up, we should look into packaging a docker client instead of installing the full-blown docker exe in the weavexec image.

I may have to do this anyway, since it looks like the earliest docker in apk is 1.4. How annoying.

Technically it's the Docker Remote API version that matters, not the docker version. There doesn't appear to be a published mapping of the latter to the former. Great.

special-case weave run to use the user's docker instead of the weaveexec one

That still needs doing, right?

site/building.md needs updating - it references weavetools.

Ditto.
I think that's it; other possible improvements, such as removing the version checks, can be deferred.

Now uses a docker 1.3.1 from get.docker.com
weavetools -> weaveexec in .gitignore and site/building.md
rebased to master

The way I've changed the script to use the "local" docker for weave run needs looking at.

rest looks good.


Pertained weights

Hi, thank you for the neat and clear explanation of your solution. I'm trying to reproduce the code, however due to resource limitation I can't redo the pertaining on CheXpert and chest14 datasets. Can you please share the weights of these pertained model


⚠ Bofrost.at has degraded performance

In 8bf7563, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2336 ms

Resolved: Bofrost.at performance has improved in 7ee3f63.


Support Localization

I have an application that requires localization. I'd like to be able to deliver a manifest that changes based on user locale. There's a minimal amount of content in the manifest itself that would require translation (name, short_name, description, maybe icons), but what would be nice is if that content could live in my existing translation workflow and I could populate the manifest at build time.
I think an approach could be something like:

detect supported languages

assume a supported addon like ember-intl or ember-i18n

generate a manifest for each supported locale

use the addon to lookup a translation, something like const name = get(this, 'intl').t('ember-web-app.name');
update the manifest values with translations

user receives the manifest for their specific locale

What I'm not sure of, if this is something this addon should have as a feature or if there's another addon here that extends this one? I'm open to suggestions or ideas. I also have some cycles coming up that I could work on one or the other.

@jonpitch this is a great idea! I think this would be a really great feature to have. If you want to start working on it, that would be awesome, let me know if I can be of any help.

Thanks @san650, I spent a little time gathering my thoughts and I have an alternate approach that I wouldn't mind your input on.
ember-i18n and ember-intl are pretty flexible in that you can use various translation file formats, specify different locations within the tree for content, that seems like overkill for ember-web-app. Instead, what I'd like to propose is perhaps ember-web-app knows about a build config, something like:
'ember-web-app': {
  enabled: true,
  locales: [{
    code: 'en-us',
    name: 'English name',
    short_name: 'English short name'
  }, {
    code: 'it-it',
    name: 'Italian Name',
    short_name: 'Italian short name'
  }]
}

ember-web-app would just be responsible for generating a set of manifest files. I think this is the most flexible, so the consumer could add something like this to their ember-cli-build.js:
const fs = require('fs');
const enUsManifestTranslations = JSON.parse(fs.readFileSync('path/to/en-us/translations.json'));

var app = new EmberApp(defaults, {
  'ember-web-app': {
    locales: [{
      locale: 'en-us',
      name: enUsManifestTranslations.name
    }]
  }
}
...

The only thing I'm not sure on is the consumer might need the ability to swap out these files in the <head>, using something like ember-cli-ifa or ember-cli-head. As the consuming app, I don't want to have to know about all the meta tags ember-web-app knows about, but I don't want ember-web-app to have to know about how I want to localize my application. What do you think?


Suggestion: Inline styles for events

I can see that the vue-cal philosophy is to separate functionality and design.
However, I'd find it a useful feature if one can also define inline styles for events, the same way we can define it for the vue-cal component. Background color would be a specific usecase:
{
      start: '2018-11-19 18:30',
      end: '2018-11-19 19:15',
      title: 'Dentist appointment',
      content: '<i class="v-icon material-icons">local_hospital</i>',
      class: 'health',
      split: 2,
      style: 'background-color: #00000'
}

All the best to you and keep on the great work.

Hi!
You can do it with event slot.
Check this:
https://jsfiddle.net/9a7ptq12/

Exactly @Csandori! 👍
Thanks @donmb1 for the feedback!
Here is yet another example to have different styles per events :)
https://codepen.io/antoniandre/pen/XwNdQz
Let us know if it helps.

Closing the issue due to inactivity.
Please reopen if not solved.


Can the environment configuration in foraging.yaml be modified?

When I change the configuration in foraging.yaml like this:
env_args:
  field_size: 20
  players: 10
  max_food: 6
  force_coop: False
  partially_observe: True
  sight: 3
  is_print: False
  need_render: False

There will be an error report about gym.error.UnregisteredEnv.

So I wonder whether the environment configuration in foraging.yaml can be modified?
Looking foward to your reply.Thank you very much.

Sorry for missing this issue. It is a relatively old repo so I may not check its status for a long time.
If you still need the solution, the method is to modify LBF library and add more registrations:
https://github.com/mansicer/MAIC/blob/efcdc9d129aca691c621d6e15299e0b0eda68678/qplex_smac/smac/env/lbforaging/__init__.py#L5-L24
Sorry again for the inconvenience and wish you good luck :)


Some evaluation metrics used the dataframe default index

For mqloss, coverage, calibration the result is created by grouping on the column unique_id which is not in the result dataset so it uses the df default index to group by. However, the result has been instantiate with a new index so it doesn't match the df index anymore unless the user reset the index of the df dataframe before using the function.
For scaled_crps, it uses the mqloss so it causes problem with the calculation.
For example, suppose that I have done a cross validation with 5 windows and the results are stored in cv_results1. If I want to calculate the evaluation metrics for each window I need to loop over the windows. In this case I create another dataframe window_df that contains the result of a corresponding window. However, lets say we take the second window then if we don't reset the index of the window_df before calculating the metrics then we will have problem calculating mqloss, coverage, calibration and scaled_crps.
for window in cv_results1.cutoff.unique():
    window_df = cv_results1[cv_results1.cutoff==window].copy()

    window_evaluation = evaluate(
        window_df,
        metrics=metrics,
        models=models,
        train_df=train,
    )

    window_evaluation["cutoff"] = window

    evaluation = pd.concat([evaluation, window_evaluation]).reset_index(drop=True)

Hey @Jonathan-87, thanks for using utilsforecast. The expected input format for the evaluation functions is to have the id as a column, not as the index.

It should never use the index anywhere. I'm guessing you have the unique_id as the index because that's the output format of statsforecast or neuralforecast, but the docstring of the evaluate function has the following:

df	Union		Forecasts to evaluate.
Must have id_col, time_col, target_col and models’ predictions.

The unique_id is not an index it's a column, maybe I'm not explaining the problem well so I'll give an reproducible example. You will notice that the evaluation dataframe will have only 10 rows instead of 20. To resolve this problem you need to add a reset_index in the for loop because of how the evaluation metrics are calculated. As I explained above this is because in the source code the res dataframe tries to group on the id_col which is available in the df dataframe but the res dataframe does not have the same index so it creates problem.
from utilsforecast.losses import calibration, mae
from functools import partial
from utilsforecast.data import generate_series

series1 = generate_series(10, n_models=2, level=[80])
series1["unique_id"] = series1["unique_id"].astype(int) + 10
series1["cutoff"] = 1

series2 = series1.copy()
series2["cutoff"] = 2

df = pd.concat([series1, series2]).reset_index()

models = ['model0', 'model1']

metrics = [partial(calibration, level=80)]

evaluation = pd.DataFrame()

for window in df.cutoff.unique():
    window_df = df[df.cutoff==window].copy()

    window_evaluation = evaluate(
        window_df,
        metrics=metrics,
        models=models,
        train_df=window_df,
    )

    window_evaluation["cutoff"] = window

    evaluation = pd.concat([evaluation, window_evaluation]).reset_index(drop=True)

print(df.drop_duplicates(subset=["unique_id", "cutoff"]).shape, evaluation.shape)

I see. I had missed the last part here

If a dict or Series is passed, the Series or dict VALUES will be used to determine the groups (the Series’ values are first aligned

I thought it would just use the values. I'll work on a fix for this, thanks for the example!

Note that you can also create an extra column like
df['id_cutoff'] = df['unique_id'].astype(str) + '-' + df['cutoff'].astype(str)
evaluate(df, metrics=metrics, models=models, id_col='id_cutoff')

That should work with the current implementation

Thanks you for this alternative, it's indeed faster to skip the for loop :)


cargo-watch: fix darwin build

Since version 8.2.0, cargo-watch pulls in mac-notification-sys version (through notify-rust) that requires Cocoa.
I also made two minor changes:

The repository owner is now named watchexec.
Since r-ryantm now updates this, there won't be as many opportunities to change sha256 to hash manually, so I went ahead and did that here even though the hash hasn't changed.

Regressed in https://github.com/NixOS/nixpkgs/pull/208410. Fixes https://github.com/NixOS/nixpkgs/issues/212987.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This is also a nice chance to remove the toplevel inherit, see: https://github.com/NixOS/nixpkgs/issues/204303

I don't really understand what the correct fix is for that. There seems to be several proposals in that thread.

The easy way is to completely remove the inherit, then use darwin.apple_sdk.frameworks.SomeFramework directly in default.nix, see pkgs/applications/editors/amp/default.nix for an example. But there's currently little benefit in doing this, leaving it as-is is also fine.

This is also a nice chance to remove the toplevel inherit, see: #204303

I don't think we're actually doing that for Darwin.

Then we can apply #209065 (or the well-aged #180931) to get this build on x86_64-darwin.
$ nix-build -A cargo-watch --argstr system x86_64-darwin
/nix/store/amkzm5iqgdybgygn4isvsf49hkxcq1h8-cargo-watch-8.3.0


Issue with the regex

Rasa NLU version : 0.12.0a2
Used backend / pipeline : spacy_sklearn
Operating system : Windows 10
Issue: regex is not working
I have created a regex expression to identify a three digit number in markdown format which is my entity and also slot . After training it is successfully building the regex_featurizer but it is taking any n - digit  number into the slot.
Content of configuration file (if used & relevant):
## regex:mid
 - [1-9]{3}

the pipeline you are using includes the ner_crf component, which looks at a number of features in the text to decide if there is an entity. The regex you provide is not treated as a rule, but just creates another feature.
TLDR add something like this to your config:
  "ner_crf": {
    "BILOU_flag": false,
    "features": [
      ["low", "title", "upper", "pos", "pos2"],
      ["bias", "low", "word3", "word2", "upper", "title", "pos", "pos2", "pattern"],
      ["low", "title", "upper", "pos", "pos2"]],
    "max_iterations": 50,
    "L1_c": 1,
    "L2_c": 1e-3
  },

Here I removed the 'digit' feature so the the crf can only see your custom regex feature, and doesn't look for the default 'is there a digit in this token' feature.

even i tried removing the 'digit' after building the model, in this case it's not even detecting the slot value

Just to sanity check: have you labeled all these numbers in your NLU examples as entities?

@akelad I have given enough training data with numbers(3-digit numbers) as entities

@Harish0596 can you provide your training data?

## intent:order_details
- order details
- details of my order
- what about order with id [843](orderId)
- give the order details
- order details pls
- [832](orderId)
- give the details of the order with id [483](orderId)
- i want to know my order details
- details of order with id [905](orderId)
- get the details following order with id [735](orderId)
- [984](orderId) order details
- can you give some details of order [429](orderId)
- pls get the details of order
- order id is [985](orderId)
- [913](orderId) is my order id
- ok then what about [563](orderId)
- wanna some info about my orders
- what about my orders
- orders
- order [183](orderId) details
- get order [127](orderId) information
- i want some info about [347](orderId) order
- i need details of my order

@Harish0596 You probably need some more training examples. However, a much easier solution is to use a pre-trained ner model like ner_duckling that automatically extracts numbers for you. You can then check in a custom action whether the number has exactly 3 digits and behave accordingly

@akelad  we can check easily with the custom action, but I want rasa to do that because I was trying to make use of all the features of Rasa


Fix typo in contributing.md

[x] documentation is changed or added (if applicable)

Description of change
Fix a typo.

Thank you sir!


Setup Github Action CICD

Features

Automatically run ci tests on pull request open/update
Build and push images on commit push to master/staging branch
Notify deployment repository for deployment on image push

Tested by opening a branch on the oursky repo, existing deployment is uninstalled manually and redeployed by the deployment repo to ensure it's working correctly.
based on #15 #16 #17
refs #12

plz rebase 🙏

@chihimng rebased


Teardown Steps should be executed irrespective of failure in Context Steps.

Expected behavior
Failures in context steps should continue to execute teardown.However the scenario steps stops execution.
Actual behavior
Stops execution if there is any failure in context steps.
Steps to reproduce

add a failing context step (without COF) and a teardown step in spec.
execute the spec.

Gauge Version
Gauge version: 0.6.2

Plugins
-------
csharp (0.9.0)
html-report (2.1.1)
java (0.5.0)
js (1.3.0)
python (0.1.5)
ruby (0.3.1)
spectacle (0.0.1)
xml-report (0.1.3)

Fix should be available in nightly >= 02-09-2016.


Multiple templates

Reference Issue

What does this implement/fix? Explain your changes.
The templating code will now search for alternatives when a template is found that would put substituents inside templated rings. This allows to have different templates for the same smiles, in order of preference, and the code will try to find one that does not cause substituents inside rings, or at least to have as few as possible

Any other comments?

I think that this should also allow us to address https://github.com/rdkit/rdkit/issues/6753#issuecomment-2423487215


Fix repo signing issue

Hi,
Not sure if you accept PRs, but I was able to resolve an issue with the repo signing that was throwing a warning/alert for me.

thanks for the push, i add it on the repo :)


Use jsdelivr instead of raw git

Rawgit is getting discontinued. Better use jsdelivr.
https://cdn.jsdelivr.net/gh/pcooksey/bibtex-js/src/bibtex_js.js

Thanks for letting me know. I've changed the wiki page to display the jsdelivr link.
When I have time I will change the link below (that is inside of bibtex_js) from:
"https://rawgit.com/moment/moment/2.22.2/min/moment.min.js"
to
<EMAIL_ADDRESS>This should be the only other rawgit link (checked with a quick search)


Domain activation is Failed - Retry Does not work

App Id: d1y72dxyvas797
Region: eu-west-1
Step: Domain activation
Status: Failed
Issue/question
Retry does not seem to work at all. If you click on Retry, it says retry in progress but it just fails afterwards.  So Now I need to remove the domain add it back again which changes the cloudfront url so then we have to update the cname again and if that takes to0 long then it fails again and we are back at square one.
The ssl configuration had the same issue, Retry did not work, and it failed before we could add the cname record.
So Now I have to remove the domain readd it and then the domain management needs to hopefully add the record in time before it fails again, Which is silly to be honest.
Why does retry not work?
Error message
Error message: One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution. You must update the DNS record to correct the problem.
Additional information
View DNS Records is also disabled, So you cannot even see where to point the dns records to. Luckily I viewed the records before it failed so I think I know where it should point to.

Current Error

Then You click retry

If you refresh the page then its back to the first screen where it says failed.

Thanks for the report. We are investigating this issue

This happens when the previously configured CNAMEs are still active DNS records at your DNS provider.
You first need to delete the ACM CNAME record (the one that validates ownership) and the CNAME pointing towards your CloudFront distribution. Delete them at your DNS provider.
Then delete the domain in Amplify.
Next do again "Add Domain" and wait for the new CNAMEs to appear.
Add the new CNAMEs add your DNS provider.

@Nxtra I know why it happens. My problem is that it has a Retry button which should work or not be there at all.
If you do not manage the dns yourself, its quite hard to get the cnames to point before the check fails and you have to start over again.
If it failed and told you, delete and reconfigure the domain then great. But why but a retry button that does nothing?

@Vaaljan Thanks for your insight; I agree that follow-up behavior is a bug that we'll work on fixing. Regarding the actual domain validation issue, are there any issues or are you all set now?

@litwicki  Yes We sorted out the domain validation.  Thanks.

Connecting a domain name from a third-party DNS service is a terrible experience. After a LOT of trial and error we found the trick is to add the CNAMEs for the subdomains before you add the CNAME for the SSL validation. Click the "Actions" > "View DNS" to see them. Once they are added, you can add the SSL validation CNAME pair. That means everything is there before the final activation step, preventing the error.
I hope this tip helps someone else out there.
Crazy that something like this on a key AWS product needs a "trick", but here we find ourselves...


VPAT-755 Added title to delete buttons in forms grid

 VPAT-755 | FMG | Add discernible text to buttons


Make colors available to user

Could this package make the baseXX color variables available to the user after package loading for their own further customization? I'm not sure if this is an unusual thing for an emacs theme to do, but it seems reasonable.

What format do you think makes the most sense? I'm not sure if an alist or separate variables makes more sense.

Either one. An alist would be a little easier on the global namespace, but much less convenient to use. I vote for separate variables with a consistent base16- prefix

I was imagining something like this
(setq base16-default-dark-colors ((base00 . "#181818")
								  (base01 . "#282828")
								  (base02 . "#383838")
								  (base03 . "#585858")
								  (base04 . "#b8b8b8")
								  (base05 . "#d8d8d8")
								  (base06 . "#e8e8e8")
								  (base07 . "#f8f8f8")
								  (base08 . "#ab4642")
								  (base09 . "#dc9656")
								  (base0A . "#f7ca88")
								  (base0B . "#a1b56c")
								  (base0C . "#86c1b9")
								  (base0D . "#7cafc2")
								  (base0E . "#ba8baf")
								  (base0F . "#a16946")))

Works for me 👍

I've added each color set as a plist.
(plist-get base16-default-dark-colors :base00) will get base00 from the default-dark scheme.

Neat; thanks!


Allow to select a separate data source for each metric

Allow each schema metric to be assigned a metric from a different source (MQTT/REST/etc)

I don't think this is a good idea. Pulling all the metrics for a Device from a single Connection allows the Device to DBIRTH/DDEATH when the connection goes up or down. Pulling from multiple connections would confuse this situation.
Cases where this seems to be desirable should be handled with Links.


Cannot have query with argument of Name when using StrawberryShake

Describe the bug
Compilation of generated code fails when there is an argument of Name in a query
To Reproduce
Steps to reproduce the behavior:

Create an application that has StrawberryShake version 11.0.0-preview.137
Write a query that has an argument of name

query getUserByName($name: String!) {
	userByName(name: $name) {
		id
	}
}

Build

Expected behavior
Build completes successfully
Actual behavior
Build fails as Name is defined twice in the generated GetUserByNameOperation.cs
Desktop (please complete the following information):

Windows
10

We will release a new build in the next few days that fixes most of the issues with the generator.

This one is now fixed.


add test for DataReaderStripsTest::applyPredictor

This PR adds a new test for DataReaderStripsTest::applyPredictor, so that it can be tested in isolation.

Added an extra commit to include the license header.
Thanks for your contribution @testingsavvy . Pull request merged.


Only recognisies IPv6 addresses, not IPv6 resolving hostnames

@grongor
I suggest an adjustment something like:
-   self.host = args.host
-   self.is_ipv6 = args.host.find(':') != -1
+   self.addr = socket.getaddrinfo(args.host, 0)
+   self.is_ipv6 = self.addr[0][0] == socket.AF_INET6

-   s.connect_ex((self.host, port))
+   s.connect_ex((self.addr[0][4][0], port))

Yeah, of course :) It's kinda hard for me - I don't have any network to test the IPv6 on ... yep, lame, I know :D Can you take a look at https://github.com/grongor/knock/pull/4 and see if it works for you? Thanks :)


Installing keyrings.cryptfile raises pipenv.exceptions.ResolutionFailure but seems to replace '.'  with '-' in the package name

Pipfile.txt
Issue description
pipenv install keyrings.cryptfile raises pipenv.exceptions.ResolutionFailure: ERROR: ERROR: Could not find a version that matches keyrings-cryptfile --this is peculiar because you'll note that the error replaces the . in the package name with -.  Following this, the package shows up in pipenv graph but removing it is seemingly impossible.
Expected result
The package either installs successfully or raises a more specific error if its naming convention is illegal or otherwise a problem; pipenv refers to the package without replacing characters.
Actual result
Different pipenv commands refer to the package as keyrings.cryptfile or keyrings-cryptfile and the package cannot be removed.
Steps to replicate
Step 1: blow away extant environment, make a new one, install from pipfile:
(user):(project)$ pipenv --rm
Removing virtualenv (/home/(user)/.local/share/virtualenvs/(project)-HNPoG7zF)…
(user):(project)$ pipenv shell
Creating a virtualenv for this project…
Pipfile: (project)/Pipfile
Using /usr/local/bin/python3.6 (3.6.8) to create virtualenv…
? Creating virtual environment...Already using interpreter /usr/local/bin/python3.6
Using base prefix '/usr/local'
New python executable in /home/(user)/.local/share/virtualenvs/(project)-HNPoG7zF/bin/python3.6
Also creating executable in /home/(user)/.local/share/virtualenvs/(project)-HNPoG7zF/bin/python
Installing setuptools, pip, wheel...
done.
? Successfully created virtual environment!
Virtualenv location: /home/(user)/.local/share/virtualenvs/(project)-HNPoG7zF
Launching subshell in virtual environment…
(user):(project)$  . /home/(user)/.local/share/virtualenvs/(project)-HNPoG7zF/bin/activate
((project)) (user):(project)$ pipenv install
Installing dependencies from Pipfile.lock (aba4b9)…
??   ???????????????????????????????? 27/27 — 00:00:02
((project)) (user):(project)$ pipenv graph
colorama==0.4.1
docopt==0.6.2
keyring==19.0.1

entrypoints [required: Any, installed: 0.3]
secretstorage [required: Any, installed: 3.1.1]

cryptography [required: Any, installed: 2.6.1]

asn1crypto [required: >=0.21.0, installed: 0.24.0]
cffi [required: >=1.8,!=1.11.3, installed: 1.12.3]

pycparser [required: Any, installed: 2.19]

six [required: >=1.4.1, installed: 1.12.0]

jeepney [required: Any, installed: 0.4]
lxml==4.3.3
pydbus==0.6.0
pyodbc==4.0.26
pytest==4.4.2

atomicwrites [required: >=1.0, installed: 1.3.0]
attrs [required: >=17.4.0, installed: 19.1.0]
more-itertools [required: >=4.0.0, installed: 7.0.0]
pluggy [required: >=0.11, installed: 0.11.0]
py [required: >=1.5.0, installed: 1.8.0]
setuptools [required: Any, installed: 41.0.1]
six [required: >=1.10.0, installed: 1.12.0]
requests==2.21.0
certifi [required: >=2017.4.17, installed: 2019.3.9]
chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
idna [required: >=2.5,<2.9, installed: 2.8]
urllib3 [required: >=1.21.1,<1.25, installed: 1.24.3]
SQLAlchemy==1.3.3
uptime==3.0.1

Step 2: attempt to install keyrings.cryptfile; note that the error gives "keyrings-cryptfile", not "keyrings.cryptfile"
((project)) (user):(project)$ pipenv install keyrings.cryptfile
Installing keyrings.cryptfile…
? Installation Succeeded
Pipfile.lock (7abca9) out of date, updating to (aba4b9)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
? Locking Failed!
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/resolver.py", line 69, in resolve
[pipenv.exceptions.ResolutionFailure]:       req_dir=requirements_dir
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 726, in resolve_deps
[pipenv.exceptions.ResolutionFailure]:       req_dir=req_dir,
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 480, in actually_resolve_deps
[pipenv.exceptions.ResolutionFailure]:       resolved_tree = resolver.resolve()
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 395, in resolve
[pipenv.exceptions.ResolutionFailure]:       raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]:       pipenv.exceptions.ResolutionFailure: ERROR: ERROR: Could not find a version that matches keyrings-cryptfile
[pipenv.exceptions.ResolutionFailure]:       No versions found
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ERROR: Could not find a version that matches keyrings-cryptfile
No versions found
Was https://pypi.org/simple reachable?
[pipenv.exceptions.ResolutionFailure]:       req_dir=requirements_dir
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 726, in resolve_deps
[pipenv.exceptions.ResolutionFailure]:       req_dir=req_dir,
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 480, in actually_resolve_deps
[pipenv.exceptions.ResolutionFailure]:       resolved_tree = resolver.resolve()
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 395, in resolve
[pipenv.exceptions.ResolutionFailure]:       raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]:       pipenv.exceptions.ResolutionFailure: ERROR: ERROR: Could not find a version that matches keyrings-cryptfile
[pipenv.exceptions.ResolutionFailure]:       No versions found
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ERROR: Could not find a version that matches keyrings-cryptfile
No versions found
Was https://pypi.org/simple reachable?
Step 3: look at the graph--here it shows "keyrings.cryptfile"
((project)) (user):(project)$ pipenv graph
colorama==0.4.1
docopt==0.6.2
keyrings.cryptfile==1.3.4

argon2-cffi [required: Any, installed: 19.1.0]

cffi [required: >=1.0.0, installed: 1.12.3]

pycparser [required: Any, installed: 2.19]

six [required: Any, installed: 1.12.0]

keyring [required: >=19.0.0, installed: 19.0.1]

entrypoints [required: Any, installed: 0.3]
secretstorage [required: Any, installed: 3.1.1]

cryptography [required: Any, installed: 2.6.1]

asn1crypto [required: >=0.21.0, installed: 0.24.0]
cffi [required: >=1.8,!=1.11.3, installed: 1.12.3]

pycparser [required: Any, installed: 2.19]

six [required: >=1.4.1, installed: 1.12.0]

jeepney [required: Any, installed: 0.4]

pycryptodome [required: Any, installed: 3.8.1]
lxml==4.3.3
pydbus==0.6.0
pyodbc==4.0.26
pytest==4.4.2
atomicwrites [required: >=1.0, installed: 1.3.0]
attrs [required: >=17.4.0, installed: 19.1.0]
more-itertools [required: >=4.0.0, installed: 7.0.0]
pluggy [required: >=0.11, installed: 0.11.0]
py [required: >=1.5.0, installed: 1.8.0]
setuptools [required: Any, installed: 41.0.1]
six [required: >=1.10.0, installed: 1.12.0]
requests==2.21.0
certifi [required: >=2017.4.17, installed: 2019.3.9]
chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
idna [required: >=2.5,<2.9, installed: 2.8]
urllib3 [required: >=1.21.1,<1.25, installed: 1.24.3]
SQLAlchemy==1.3.3
uptime==3.0.1

Step 4: Try to remove, get same if not similar exception as installing
((project)) (user):(project)$ pipenv uninstall keyrings.cryptfile
Uninstalling keyrings.cryptfile…
No package keyrings.cryptfile to remove from Pipfile.
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
? Locking Failed!
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/resolver.py", line 69, in resolve
[pipenv.exceptions.ResolutionFailure]:       req_dir=requirements_dir
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 726, in resolve_deps
[pipenv.exceptions.ResolutionFailure]:       req_dir=req_dir,
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 480, in actually_resolve_deps
[pipenv.exceptions.ResolutionFailure]:       resolved_tree = resolver.resolve()
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 395, in resolve
[pipenv.exceptions.ResolutionFailure]:       raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]:       pipenv.exceptions.ResolutionFailure: ERROR: ERROR: Could not find a version that matches keyrings-cryptfile
[pipenv.exceptions.ResolutionFailure]:       No versions found
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ERROR: Could not find a version that matches keyrings-cryptfile
No versions found
Was https://pypi.org/simple reachable?
[pipenv.exceptions.ResolutionFailure]:       req_dir=requirements_dir
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 726, in resolve_deps
[pipenv.exceptions.ResolutionFailure]:       req_dir=req_dir,
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 480, in actually_resolve_deps
[pipenv.exceptions.ResolutionFailure]:       resolved_tree = resolver.resolve()
[pipenv.exceptions.ResolutionFailure]:   File "/usr/local/lib/python3.6/site-packages/pipenv/utils.py", line 395, in resolve
[pipenv.exceptions.ResolutionFailure]:       raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]:       pipenv.exceptions.ResolutionFailure: ERROR: ERROR: Could not find a version that matches keyrings-cryptfile
[pipenv.exceptions.ResolutionFailure]:       No versions found
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ERROR: Could not find a version that matches keyrings-cryptfile
No versions found
Was https://pypi.org/simple reachable?
Step 5: Try to uninstall it with a hyphen in the package name instead of . and it acts as if it was successful
((project)) (user):(project)$ pipenv uninstall keyrings-cryptfile
Uninstalling keyrings-cryptfile…
Removing keyrings-cryptfile from Pipfile…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
? Success!
Updated Pipfile.lock (aba4b9)!
Step 6: Likewise, pipenv clean
(ds-ops-tools) (user):(project)$ pipenv clean
Uninstalling pycryptodome…
Uninstalling keyrings-cryptfile…
Uninstalling argon2-cffi…
Step 7: pipenv graph, however still shows it there
((project)) (user):(project)$ pipenv graph
colorama==0.4.1
docopt==0.6.2
keyrings.cryptfile==1.3.4

argon2-cffi [required: Any, installed: ?]
keyring [required: >=19.0.0, installed: 19.0.1]

entrypoints [required: Any, installed: 0.3]
secretstorage [required: Any, installed: 3.1.1]

cryptography [required: Any, installed: 2.6.1]

asn1crypto [required: >=0.21.0, installed: 0.24.0]
cffi [required: >=1.8,!=1.11.3, installed: 1.12.3]

pycparser [required: Any, installed: 2.19]

six [required: >=1.4.1, installed: 1.12.0]

jeepney [required: Any, installed: 0.4]

pycryptodome [required: Any, installed: ?]
lxml==4.3.3
pydbus==0.6.0
pyodbc==4.0.26
pytest==4.4.2
atomicwrites [required: >=1.0, installed: 1.3.0]
attrs [required: >=17.4.0, installed: 19.1.0]
more-itertools [required: >=4.0.0, installed: 7.0.0]
pluggy [required: >=0.11, installed: 0.11.0]
py [required: >=1.5.0, installed: 1.8.0]
setuptools [required: Any, installed: 41.0.1]
six [required: >=1.10.0, installed: 1.12.0]
requests==2.21.0
certifi [required: >=2017.4.17, installed: 2019.3.9]
chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
idna [required: >=2.5,<2.9, installed: 2.8]
urllib3 [required: >=1.21.1,<1.25, installed: 1.24.3]
SQLAlchemy==1.3.3
uptime==3.0.1

$ pipenv --support
Pipenv version: '2018.11.26'
Pipenv location: '/usr/local/lib/python3.6/site-packages/pipenv'
Python location: '/usr/local/bin/python3.6'
Python installations found:

3.7.2: /usr/local/bin/python3.7m
3.7.2: /usr/local/bin/python3.7
3.6.8: /home/ehamrick/.local/share/virtualenvs/ds-ops-tools-HNPoG7zF/bin/python3
3.6.8: /usr/local/bin/python3.6
3.6.8: /usr/local/bin/python3.6m
2.6.6: /usr/bin/python
2.6.6: /usr/bin/python2.6

PEP 508 Information:
{'implementation_name': 'cpython',
 'implementation_version': '3.6.8',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '2.6.32-754.10.1.el6.x86_64',
 'platform_system': 'Linux',
 'platform_version': '#1 SMP Thu Nov 29 15:44:01 EST 2018',
 'python_full_version': '3.6.8',
 'python_version': '3.6',
 'sys_platform': 'linux'}

System environment variables:

HOSTNAME
SELINUX_ROLE_REQUESTED
PIP_PYTHON_PATH
TERM
SHELL
HISTSIZE
SSH_CLIENT
SELINUX_USE_CURRENT_RANGE
QTDIR
QTINC
SSH_TTY
HISTFILESIZE
USER
LS_COLORS
VIRTUAL_ENV
PIPENV_ACTIVE
MAIL
PATH
PWD
LANG
PYTHONFINDER_IGNORE_UNSUPPORTED
PS1
SELINUX_LEVEL_REQUESTED
PYTHONDONTWRITEBYTECODE
HISTCONTROL
SHLVL
HOME
LOGNAME
PIP_DISABLE_PIP_VERSION_CHECK
QTLIB
CVS_RSH
SSH_CONNECTION
DBUS_SESSION_BUS_ADDRESS
LESSOPEN
G_BROKEN_FILENAMES
HISTTIMEFORMAT
_
PIP_SHIMS_BASE_MODULE

Pipenv–specific environment variables:

PIPENV_ACTIVE: 1

Debug–specific environment variables:

PATH: /home/ehamrick/.local/share/virtualenvs/ds-ops-tools-HNPoG7zF/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/dell/srvadmin/bin
SHELL: /bin/sh
LANG: en_US.UTF-8
PWD: /sandbox/prod/ms_source/scripts/ds-ops-tools
VIRTUAL_ENV: /home/ehamrick/.local/share/virtualenvs/ds-ops-tools-HNPoG7zF

Contents of Pipfile ('/sandbox/prod/ms_source/scripts/ds-ops-tools/Pipfile'):
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]
atomicwrites = ">=1.3.0"
attrs = ">=19.1.0"
certifi = ">=2018.11.29"
chardet = ">=3.0.4"
colorama = ">=0.4.1"
idna = ">=2.8"
lxml = ">=4.3.1"
more-itertools = ">=6.0.0"
pluggy = ">=0.9.0"
py = ">=1.8.0"
pyodbc = ">=4.0.26"
pytest = ">=4.3.0"
requests = ">=2.21.0"
six = ">=1.12.0"
uptime = ">=3.0.1"
urllib3 = ">=1.24.1"
docopt = "*"
sqlalchemy = "*"
pydbus = "*"
keyring = "*"

[requires]
python_version = "3.6"

Contents of Pipfile.lock ('/sandbox/prod/ms_source/scripts/ds-ops-tools/Pipfile.lock'):
{
    "_meta": {
        "hash": {
            "sha256": "eef183d1885f2038c094385d7c8121e065212942ea12decedc4728e88baba4b9"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "asn1crypto": {
            "hashes": [
                "sha256:2f1adbb7546ed199e3c90ef23ec95c5cf3585bac7d11fb7eb562a3fe89c64e87",
                "sha256:9d5c20441baf0cb60a4ac34cc447c6c189024b6b4c6cd7877034f4965c464e49"
            ],
            "version": "==0.24.0"
        },
        "atomicwrites": {
            "hashes": [
                "sha256:03472c30eb2c5d1ba9227e4c2ca66ab8287fbfbbda3888aa93dc2e28fc6811b4",
                "sha256:75a9445bac02d8d058d5e1fe689654ba5a6556a1dfd8ce6ec55a0ed79866cfa6"
            ],
            "index": "pypi",
            "version": "==1.3.0"
        },
        "attrs": {
            "hashes": [
                "sha256:69c0dbf2ed392de1cb5ec704444b08a5ef81680a61cb899dc08127123af36a79",
                "sha256:f0b870f674851ecbfbbbd364d6b5cbdff9dcedbc7f3f5e18a6891057f21fe399"
            ],
            "index": "pypi",
            "version": "==19.1.0"
        },
        "certifi": {
            "hashes": [
                "sha256:59b7658e26ca9c7339e00f8f4636cdfe59d34fa37b9b04f6f9e9926b3cece1a5",
                "sha256:b26104d6835d1f5e49452a26eb2ff87fe7090b89dfcaee5ea2212697e1e1d7ae"
            ],
            "index": "pypi",
            "version": "==2019.3.9"
        },
        "cffi": {
            "hashes": [
                "sha256:041c81822e9f84b1d9c401182e174996f0bae9991f33725d059b771744290774",
                "sha256:046ef9a22f5d3eed06334d01b1e836977eeef500d9b78e9ef693f9380ad0b83d",
                "sha256:066bc4c7895c91812eff46f4b1c285220947d4aa46fa0a2651ff85f2afae9c90",
                "sha256:066c7ff148ae33040c01058662d6752fd73fbc8e64787229ea8498c7d7f4041b",
                "sha256:2444d0c61f03dcd26dbf7600cf64354376ee579acad77aef459e34efcb438c63",
                "sha256:300832850b8f7967e278870c5d51e3819b9aad8f0a2c8dbe39ab11f119237f45",
                "sha256:34c77afe85b6b9e967bd8154e3855e847b70ca42043db6ad17f26899a3df1b25",
                "sha256:46de5fa00f7ac09f020729148ff632819649b3e05a007d286242c4882f7b1dc3",
                "sha256:4aa8ee7ba27c472d429b980c51e714a24f47ca296d53f4d7868075b175866f4b",
                "sha256:4d0004eb4351e35ed950c14c11e734182591465a33e960a4ab5e8d4f04d72647",
                "sha256:4e3d3f31a1e202b0f5a35ba3bc4eb41e2fc2b11c1eff38b362de710bcffb5016",
                "sha256:50bec6d35e6b1aaeb17f7c4e2b9374ebf95a8975d57863546fa83e8d31bdb8c4",
                "sha256:55cad9a6df1e2a1d62063f79d0881a414a906a6962bc160ac968cc03ed3efcfb",
                "sha256:5662ad4e4e84f1eaa8efce5da695c5d2e229c563f9d5ce5b0113f71321bcf753",
                "sha256:59b4dc008f98fc6ee2bb4fd7fc786a8d70000d058c2bbe2698275bc53a8d3fa7",
                "sha256:73e1ffefe05e4ccd7bcea61af76f36077b914f92b76f95ccf00b0c1b9186f3f9",
                "sha256:a1f0fd46eba2d71ce1589f7e50a9e2ffaeb739fb2c11e8192aa2b45d5f6cc41f",
                "sha256:a2e85dc204556657661051ff4bab75a84e968669765c8a2cd425918699c3d0e8",
                "sha256:a5457d47dfff24882a21492e5815f891c0ca35fefae8aa742c6c263dac16ef1f",
                "sha256:a8dccd61d52a8dae4a825cdbb7735da530179fea472903eb871a5513b5abbfdc",
                "sha256:ae61af521ed676cf16ae94f30fe202781a38d7178b6b4ab622e4eec8cefaff42",
                "sha256:b012a5edb48288f77a63dba0840c92d0504aa215612da4541b7b42d849bc83a3",
                "sha256:d2c5cfa536227f57f97c92ac30c8109688ace8fa4ac086d19d0af47d134e2909",
                "sha256:d42b5796e20aacc9d15e66befb7a345454eef794fdb0737d1af593447c6c8f45",
                "sha256:dee54f5d30d775f525894d67b1495625dd9322945e7fee00731952e0368ff42d",
                "sha256:e070535507bd6aa07124258171be2ee8dfc19119c28ca94c9dfb7efd23564512",
                "sha256:e1ff2748c84d97b065cc95429814cdba39bcbd77c9c85c89344b317dc0d9cbff",
                "sha256:ed851c75d1e0e043cbf5ca9a8e1b13c4c90f3fbd863dacb01c0808e2b5204201"
            ],
            "version": "==1.12.3"
        },
        "chardet": {
            "hashes": [
                "sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae",
                "sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691"
            ],
            "index": "pypi",
            "version": "==3.0.4"
        },
        "colorama": {
            "hashes": [
                "sha256:05eed71e2e327246ad6b38c540c4a3117230b19679b875190486ddd2d721422d",
                "sha256:f8ac84de7840f5b9c4e3347b3c1eaa50f7e49c2b07596221daec5edaabbd7c48"
            ],
            "index": "pypi",
            "version": "==0.4.1"
        },
        "cryptography": {
            "hashes": [
                "sha256:066f815f1fe46020877c5983a7e747ae140f517f1b09030ec098503575265ce1",
                "sha256:210210d9df0afba9e000636e97810117dc55b7157c903a55716bb73e3ae07705",
                "sha256:26c821cbeb683facb966045e2064303029d572a87ee69ca5a1bf54bf55f93ca6",
                "sha256:2afb83308dc5c5255149ff7d3fb9964f7c9ee3d59b603ec18ccf5b0a8852e2b1",
                "sha256:2db34e5c45988f36f7a08a7ab2b69638994a8923853dec2d4af121f689c66dc8",
                "sha256:409c4653e0f719fa78febcb71ac417076ae5e20160aec7270c91d009837b9151",
                "sha256:45a4f4cf4f4e6a55c8128f8b76b4c057027b27d4c67e3fe157fa02f27e37830d",
                "sha256:48eab46ef38faf1031e58dfcc9c3e71756a1108f4c9c966150b605d4a1a7f659",
                "sha256:6b9e0ae298ab20d371fc26e2129fd683cfc0cfde4d157c6341722de645146537",
                "sha256:6c4778afe50f413707f604828c1ad1ff81fadf6c110cb669579dea7e2e98a75e",
                "sha256:8c33fb99025d353c9520141f8bc989c2134a1f76bac6369cea060812f5b5c2bb",
                "sha256:9873a1760a274b620a135054b756f9f218fa61ca030e42df31b409f0fb738b6c",
                "sha256:9b069768c627f3f5623b1cbd3248c5e7e92aec62f4c98827059eed7053138cc9",
                "sha256:9e4ce27a507e4886efbd3c32d120db5089b906979a4debf1d5939ec01b9dd6c5",
                "sha256:acb424eaca214cb08735f1a744eceb97d014de6530c1ea23beb86d9c6f13c2ad",
                "sha256:c8181c7d77388fe26ab8418bb088b1a1ef5fde058c6926790c8a0a3d94075a4a",
                "sha256:d4afbb0840f489b60f5a580a41a1b9c3622e08ecb5eec8614d4fb4cd914c4460",
                "sha256:d9ed28030797c00f4bc43c86bf819266c76a5ea61d006cd4078a93ebf7da6bfd",
                "sha256:e603aa7bb52e4e8ed4119a58a03b60323918467ef209e6ff9db3ac382e5cf2c6"
            ],
            "version": "==2.6.1"
        },
        "docopt": {
            "hashes": [
                "sha256:49b3a825280bd66b3aa83585ef59c4a8c82f2c8a522dbe754a8bc8d08c85c491"
            ],
            "index": "pypi",
            "version": "==0.6.2"
        },
        "entrypoints": {
            "hashes": [
                "sha256:589f874b313739ad35be6e0cd7efde2a4e9b6fea91edcc34e58ecbb8dbe56d19",
                "sha256:c70dd71abe5a8c85e55e12c19bd91ccfeec11a6e99044204511f9ed547d48451"
            ],
            "version": "==0.3"
        },
        "idna": {
            "hashes": [
                "sha256:c357b3f628cf53ae2c4c05627ecc484553142ca23264e593d327bcde5e9c3407",
                "sha256:ea8b7f6188e6fa117537c3df7da9fc686d485087abf6ac197f9c46432f7e4a3c"
            ],
            "index": "pypi",
            "version": "==2.8"
        },
        "jeepney": {
            "hashes": [
                "sha256:6089412a5de162c04747f0220f6b2223b8ba660acd041e52a76426ca550e3c70",
                "sha256:f6f8b1428403b4afad04b6b82f9ab9fc426c253d7504c9031c41712a2c01dc74"
            ],
            "version": "==0.4"
        },
        "keyring": {
            "hashes": [
                "sha256:44e5a4e1ad1070c7cd46959a0d6c2a99588b66a6dad6fd685463b486c04855ea",
                "sha256:aae82841a2e170ecf4319df0f5c0df1468a98809e77563174949d8394bb59488"
            ],
            "index": "pypi",
            "version": "==19.0.1"
        },
        "lxml": {
            "hashes": [
                "sha256:03984196d00670b2ab14ae0ea83d5cc0cfa4f5a42558afa9ab5fa745995328f5",
                "sha256:0815b0c9f897468de6a386dc15917a0becf48cc92425613aa8bbfc7f0f82951f",
                "sha256:175f3825f075cf02d15099eb52658457cf0ff103dcf11512b5d2583e1d40f58b",
                "sha256:30e14c62d88d1e01a26936ecd1c6e784d4afc9aa002bba4321c5897937112616",
                "sha256:3210da6f36cf4b835ff1be853962b22cc354d506f493b67a4303c88bbb40d57b",
                "sha256:40f60819fbd5bad6e191ba1329bfafa09ab7f3f174b3d034d413ef5266963294",
                "sha256:43b26a865a61549919f8a42e094dfdb62847113cf776d84bd6b60e4e3fc20ea3",
                "sha256:4a03dd682f8e35a10234904e0b9508d705ff98cf962c5851ed052e9340df3d90",
                "sha256:62f382cddf3d2e52cf266e161aa522d54fd624b8cc567bc18f573d9d50d40e8e",
                "sha256:7b98f0325be8450da70aa4a796c4f06852949fe031878b4aa1d6c417a412f314",
                "sha256:846a0739e595871041385d86d12af4b6999f921359b38affb99cdd6b54219a8f",
                "sha256:a3080470559938a09a5d0ec558c005282e99ac77bf8211fb7b9a5c66390acd8d",
                "sha256:ad841b78a476623955da270ab8d207c3c694aa5eba71f4792f65926dc46c6ee8",
                "sha256:afdd75d9735e44c639ffd6258ce04a2de3b208f148072c02478162d0944d9da3",
                "sha256:b4fbf9b552faff54742bcd0791ab1da5863363fb19047e68f6592be1ac2dab33",
                "sha256:b90c4e32d6ec089d3fa3518436bdf5ce4d902a0787dbd9bb09f37afe8b994317",
                "sha256:b91cfe4438c741aeff662d413fd2808ac901cc6229c838236840d11de4586d63",
                "sha256:bdb0593a42070b0a5f138b79b872289ee73c8e25b3f0bea6564e795b55b6bcdd",
                "sha256:c4e4bca2bb68ce22320297dfa1a7bf070a5b20bcbaec4ee023f83d2f6e76496f",
                "sha256:cec4ab14af9eae8501be3266ff50c3c2aecc017ba1e86c160209bb4f0423df6a",
                "sha256:e83b4b2bf029f5104bc1227dbb7bf5ace6fd8fabaebffcd4f8106fafc69fc45f",
                "sha256:e995b3734a46d41ae60b6097f7c51ba9958648c6d1e0935b7e0ee446ee4abe22",
                "sha256:f679d93dec7f7210575c85379a31322df4c46496f184ef650d3aba1484b38a2d",
                "sha256:fd213bb5166e46974f113c8228daaef1732abc47cb561ce9c4c8eaed4bd3b09b",
                "sha256:fdcb57b906dbc1f80666e6290e794ab8fb959a2e17aa5aee1758a85d1da4533f",
                "sha256:ff424b01d090ffe1947ec7432b07f536912e0300458f9a7f48ea217dd8362b86"
            ],
            "index": "pypi",
            "version": "==4.3.3"
        },
        "more-itertools": {
            "hashes": [
                "sha256:2112d2ca570bb7c3e53ea1a35cd5df42bb0fd10c45f0fb97178679c3c03d64c7",
                "sha256:c3e4748ba1aad8dba30a4886b0b1a2004f9a863837b8654e7059eebf727afa5a"
            ],
            "index": "pypi",
            "version": "==7.0.0"
        },
        "pluggy": {
            "hashes": [
                "sha256:25a1bc1d148c9a640211872b4ff859878d422bccb59c9965e04eed468a0aa180",
                "sha256:964cedd2b27c492fbf0b7f58b3284a09cf7f99b0f715941fb24a439b3af1bd1a"
            ],
            "index": "pypi",
            "version": "==0.11.0"
        },
        "py": {
            "hashes": [
                "sha256:64f65755aee5b381cea27766a3a147c3f15b9b6b9ac88676de66ba2ae36793fa",
                "sha256:dc639b046a6e2cff5bbe40194ad65936d6ba360b52b3c3fe1d08a82dd50b5e53"
            ],
            "index": "pypi",
            "version": "==1.8.0"
        },
        "pycparser": {
            "hashes": [
                "sha256:a988718abfad80b6b157acce7bf130a30876d27603738ac39f140993246b25b3"
            ],
            "version": "==2.19"
        },
        "pydbus": {
            "hashes": [
                "sha256:4207162eff54223822c185da06c1ba8a34137a9602f3da5a528eedf3f78d0f2c",
                "sha256:66b80106352a718d80d6c681dc2a82588048e30b75aab933e4020eb0660bf85e"
            ],
            "index": "pypi",
            "version": "==0.6.0"
        },
        "pyodbc": {
            "hashes": [
                "sha256:0e89294da8bd1d1dd37799d07ee9c4ecfea821a9a6e6f51566a0efef5cff0495",
                "sha256:19c2132f7a1c573eae1b5ea8915143243b2b557ea2fae551d833ecbac79b2c6e",
                "sha256:2c673a6d3247c1e2a636d18f3e02742381778c4194da5e583f03dc3ea050598a",
                "sha256:3d00077859d214915c089624c459ec05b823ffc89071657eec109389909b19d3",
                "sha256:44430048ede2b47cb2b1d45f9d6d00d2575752942160f8c75a2a588ae3602e66",
                "sha256:59623016dd429ea2e258a8d4d08b661ae497aeb6ea24e14cb67af3bf3d263ce3",
                "sha256:9d5549c49846a40a0f6e1cd9fd2ab147d4c77452ce74452a103e2c244e38a441",
                "sha256:a229ae7b487a123e2a1d09ad529ce3a7857957c87679246e87874697cad5d9ed",
                "sha256:a3f82f853ae71f5a2be7cdd29e51d197984147d3682fb326eff3e44ea03d617b",
                "sha256:b5e46d768ab7a4ac7621ba1499678e77d2bf143222c60a9c4c3c8f8e7a0c7ef6",
                "sha256:c0747d54c066acf79a4e042906f558a27755939f673479ce4dcd88cb9bab09c9",
                "sha256:d10754f5534dffd04f5ebb2fc321ac59ee6d2f3ddfeb161701094f4e2df63a7e",
                "sha256:e455a58b807ed9c4c7ea3f712bf0ad04a3400baf93a14b016e81219a0eb0831b",
                "sha256:e52700b5d24a846483b5ab80acd9153f8e593999c9184ffea11596288fb33de3",
                "sha256:f1abc331975f1a2131d235f87a683b55c7d55a198fcf5fae02267a26d849e323",
                "sha256:fc661323bd8339759fafb2081e9d20b576c988994f9f8b3dd936f5bc8b974dd8"
            ],
            "index": "pypi",
            "version": "==4.0.26"
        },
        "pytest": {
            "hashes": [
                "sha256:136632a40451162cdfc18fe4d7ecc5d169b558a3d4bbb1603d4005308a42fd03",
                "sha256:62b129bf8368554ca7a942cbdb57ea26aafef46cc65bc317cdac3967e54483a3"
            ],
            "index": "pypi",
            "version": "==4.4.2"
        },
        "requests": {
            "hashes": [
                "sha256:502a824f31acdacb3a35b6690b5fbf0bc41d63a24a45c4004352b0242707598e",
                "sha256:7bf2a778576d825600030a110f3c0e3e8edc51dfaafe1c146e39a2027784957b"
            ],
            "index": "pypi",
            "version": "==2.21.0"
        },
        "secretstorage": {
            "hashes": [
                "sha256:20c797ae48a4419f66f8d28fc221623f11fc45b6828f96bdb1ad9990acb59f92",
                "sha256:7a119fb52a88e398dbb22a4b3eb39b779bfbace7e4153b7bc6e5954d86282a8a"
            ],
            "markers": "sys_platform == 'linux'",
            "version": "==3.1.1"
        },
        "six": {
            "hashes": [
                "sha256:3350809f0555b11f552448330d0b52d5f24c91a322ea4a15ef22629740f3761c",
                "sha256:d16a0141ec1a18405cd4ce8b4613101da75da0e9a7aec5bdd4fa804d0e0eba73"
            ],
            "index": "pypi",
            "version": "==1.12.0"
        },
        "sqlalchemy": {
            "hashes": [
                "sha256:91c54ca8345008fceaec987e10924bf07dcab36c442925357e5a467b36a38319"
            ],
            "index": "pypi",
            "version": "==1.3.3"
        },
        "uptime": {
            "hashes": [
                "sha256:7c300254775b807ce46e3dcbcda30aa3b9a204b9c57a7ac1e79ee6dbe3942973"
            ],
            "index": "pypi",
            "version": "==3.0.1"
        },
        "urllib3": {
            "hashes": [
                "sha256:2393a695cd12afedd0dcb26fe5d50d0cf248e5a66f75dbd89a3d4eb333a61af4",
                "sha256:a637e5fae88995b256e3409dc4d52c2e2e0ba32c42a6365fee8bbd2238de3cfb"
            ],
            "index": "pypi",
            "version": "==1.24.3"
        }
    },
    "develop": {}
}

This error is fixed on the master branch of pipenv and will be released this week, sorry for the trouble
Closing this as the issue is resolved and pending release

Thanks @techalchemy! Is there an issue or commit you could point me to where I could learn more about the details of the issue and fix?


Add InsertAndFetchOperation#models

So that the beforeInsert() and afterInsert() static query hooks return correct model-data in inputItems when using insertAndFetch()
Closes #1839

Coverage decreased (-0.005%) to 97.056% when pulling 5087a743583460f5f18d7a375631afb2963328fc on lehni:fix/static-hooks-with-insert-and-fetch into fc4190942a8926609925db42a547fb498b116149 on Vincit:master.

Thanks!


Added missing setup step to README

Added Google maps API key setup info to README - you get a runtime error if it's not set.
Alternatively, we could add a new initialiser at config/initializers/dev.rb with something like:
unless Rails.env.production?
  ENV['SECRET_KEY_BASE'] = '<something>'
  ENV['GOOGLE_MAPS_API_KEY'] = ''
end

which would remove the requirement for this setup step and the SECRET_KEY_BASE step

Coverage remained the same at 99.352% when pulling bb6556be647d512746ac18da46195441ab3c0963 on broder:maps_readme into b7ad87cc8abc57a72e9f8b41979e39df50be3b5c on openfarmcc:master.

I like the act of including it in the set-up step. That way a user can identify that they might actually need one.
We should probably have a note somewhere in the developer documentation (probably on the GitHub wiki here) about the google api key. Especially if we'd automate it.
@broder as someone who's relatively new to the project, which of the two solutions would you have preferred? (the extra step in set up vs. an automated approach)

I think it's generally best to reduce the number of steps someone has to take to be able to run the project locally but either solution is fine provided that the extra steps are clearly documented (which they are 👍 ).

Cool, I added an issue so that we don't forget about it, and in the meantime, this is a good addition! Thanks @broder!


[TFLite]: Add missing cc file to Makefile

This PR adds a missing file whose code is used in libedgetpu/libcoral
to the Tensorflow Lite Makefile.

It looks like CI is failing because the host is running out of space:
10:49:57  ERROR: /workspace/tensorflow/core/BUILD:1883:11: Couldn't build file tensorflow/core/lib_strings_ordered_code_test/test.log:  failed due to unexpected I/O exception: write (No space left on device)

@terryheo could you review this PR?

Is there anything else I need to do to get this merged?


Change: No body uses bytes, please add a dropdown option to select, between bytes, mb, gb, tb, yb

Change: No body uses bytes, please add a dropdown option to select, between bytes, Mb, Gb, T, Y

For now there are no plans for this as the error message will also have to be adapted but I may reconsider it in the future as the UI will change anyway with the refactoring.


Fix a typo in the docs about merge_enabled setting

Hi @pedro-psb , I've rebased the commit, could you please merge it, looks like a simple typo.


Exporting selected points from a Napari window is broken

Steps to reproduce:
Visualize some Visium data set using something like
image = sq.im.ImageContainer(adata.uns["spatial"]["spaceranger100_count_30458_ST8059048_mm10-3_0_0_premrna"]["images"]["hires"], scale=adata.uns["spatial"]["spaceranger100_count_30458_ST8059048_mm10-3_0_0_premrna"]["scalefactors"]["tissue_hires_scalef"], library_id="spaceranger100_count_30458_ST8059048_mm10-3_0_0_premrna")
viewer = image.interactive(adata)

Create a new shape layer, create a polygon selecting some points and press Shift+E. A new column appears in the Observations dock, but looking at adata.obs in the Python console does not show the new column.
This is because ImageController._save_shapes modifies self.model.adata. However, ImageModel stores a copy of the original AnnData object instead of a reference: It calls ImageContainer._subset, which then creates a copy.

The copy is currently necessary as it modifies the coordinates inplace (when scale!=1 or when the container is a crop).
Currently, I don't see an immediate solution to this; some possibilities are:

using a context manager
creating a new, key for spatial coordinates, e.g. '_spatial'

Any opinion @giovp ?
In any case, Interactive object has the .adata attribute that should have the corresponding column.

Create a new shape layer, create a polygon selecting some points and press Shift+E. A new column appears in the Observations dock, but looking at adata.obs in the Python console does not show the new column.

Indeed, you'd have to check in the viewer.adata object, which is needed for the cases @michalk8 has described above. @michalk8 how would you envision a context manager in this context? @ilia-kats what do you think could be a solution?
Personally I don't think it's a big problem as users could still copy over the annotation to the old anndata. Maybe should be better documented?

Yeah, as long as you update the Napari tutorial, it should be fine. It's still not very intuitive though, you're passing an AnnData object to interactive, so from the outside it's not immediately clear why the shapes are not stored directly in that object. Unfortunately I'm not familiar enogh with SquidPy internals to suggest a solution for this at the moment.


fix(gitreceive): fix checkForEnv logic

val != val is clearly never going to fail. Changed
to expVal != val

Thanks for the contribution! Please ensure your commits follow our style guide. This code will be tested once a Deis maintainer reviews it.

Codecov Report

Merging #502 into master will decrease coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #502      +/-   ##
==========================================
- Coverage   56.42%   56.34%   -0.09%
==========================================
  Files          29       29
  Lines        1237     1237
==========================================
- Hits          698      697       -1
- Misses        501      502       +1
  Partials       38       38

Impacted Files
Coverage Δ

pkg/healthsrv/circuit_state.go
77.77% <0%> (-11.12%)
:arrow_down:

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 4634fe1...56abf92. Read the comment docs.

Jenkins, add to whitelist.

codecov/project — 56.34% (-0.09%) compared to 4634fe1

I honestly can't see how that is the case, based on the diff in this PR.


How to use with react-navigation?

Can someone please share how to get react-navigation working with CRA?
Their docs are very sparse and lack important details for web integration. They're also missing an important walkthrough for web integration and I can't find any guide on how to integrate with web.
Note: There are many open issues regarding web integration in their repo, but no responses, so it seems impossible to get a solution there.

This question is super general and not suited for here, sorry!
Please try something like Stack Overflow; however ...
They link to https://github.com/react-community/react-navigation/blob/master/website/src/App.js.
I would highly suggest you checkout react-router, tho.


Dialog Content showing under Overlay (v0.14.0-rc2)

I did not find any related opened issue (if there is already one opened sorry for opening a new one).
Since I updated v0.14.0-rc2, Dialog content appears under Overlay (zIndex issue).
I don't remember but I think I was with version v0.14.0-rc1 before updating and it was ok.
As a tempory fix I set a zIndex in contentStyle  :
      <Dialog
        title="Select your language"
        actions={customActions}
        contentStyle={{ width : '300px', zIndex: 10 }}
        open={this.state.langDialogOpened}

But I guess it is unwanted.

Could you try with the master branch? The zIndex should already be set to 1500.

yes.
Give me a bit time I will have to trick my jspm (I was on npm dep.).

It will be more complicated since master don't have lib directory when jspm install it from github :
 jspm install material-ui=github:callemall/material-ui@master -o "{registry:'npm'}"

You can try,

npm install
cd node_modules/material-ui && npm install && rm -r node_modules/react && cd ../../

It does not work.
I manually installed npm packages from jspm_packages/github/**/* but it throws errors.
When I change zIndex values in /lib/styles/zIndex.js it should make a difference?
It appears to me it does not.
I went back in version v0.14.0-rc1 to compare both version but /lib/styles/zIndex.js did not exists before.

I installed v0.14.0 it is now fixed!
You can close this issue and thank you for this nice version.
I also now have snackbar appearing without any problem.
:+1:


[misc] Improve manual test to auto for system

Impacted TCs num(approved): New 0, Update 6, Delete 0
Unit test Platform: Android
Android test result summary: Pass 6, Fail 0, Block 0

LGTM


Remove apply button on eco page, add text to footer

What changed? Why?
Requested changes from BD team.
Notes to reviewers
How has it been tested?
Locally.

LGTM!

Review Error for katsnow08 @ 2024-01-04 21:08:17 UTC
User failed mfa authentication, public email is not set on your github profile. see go/mfa-help


Experiment API

It would be nice to have an easy way to run lots of experiments (maybe in parallel?) and get the relevant metrics in a spreadsheet.

@plopezgarcia suggested the following in a email:

As I suggested a few weeks ago, at some point the code should freeze, and every experiment should have input parameters that should come from a file stored in the repository for reference and tracking, which represents a specific experiment, like:
experiment001.json:
"{geneExpansion:true,
addTreatmentKeywords:true,
addSexDemographics:true,
translateDemographicsToAgeGroup:true,
....}"
or something of that sort.
This will enable us to run all sorts of experiments and variations in one go, analyze, and plot the results as desired and which whatever tools we want, and finally pick the experiments that provide the best results.?
Ideally, we should have two input experiment folders, one for the automatic runs, and one for the manual runs, which can even be directly the elastic search query if Stefan/Zdenko are willing to curate them really accurately.

TODO/Wishlist:

addResults() deprecated
read from JSON
parallel processing / thread-safe
hash Experiment and store all results with unique ID
CSVWriter for experiments
expose TrecEval @ Experiment class
ExperimentBuilder should provide a single experiment
ExperimentSetBuilder provides related experiments
validation rules


cFE Integration candidate: 2021-08-10

Describe the contribution
PR #1737

Fix #1733, Move global count into test global struct.

Testing performed
GitHub CI
Expected behavior changes
See Included PRs
System(s) tested on
Ubuntu 18.04
Additional context
Part of nasa/cFS#
Third party code
None
Contributor Info - All information REQUIRED for consideration of pull request

@zanzaben I noticed you reference #1730 in #1737, is that a typo?


import leaptorch error

leapctype.py", line 149, in create_new_model
self.libprojectors.create_new_model.restype = ctypes.c_int
AttributeError: 'NoneType' object has no attribute 'create_new_model'

My best guess is that the install failed.  Could you send me the full traceback?

Yep, it looks like dynamic library failed to compile.  A couple of things to check

Do you have all the dependencies met?  They are listed here: https://github.com/LLNL/LEAP/wiki/Installing-and-Using-LEAP
Trying running the following command which should print out all the compilation errors: pip install -v .
I precompiled the dynamic libraries for version 1.0, you can just download them here: https://github.com/LLNL/LEAP/releases
One common error in the compilation is a CMake error.  A change that helped another user is listed here: https://github.com/LLNL/LEAP/issues/9#issuecomment-1881344355

Yep, it looks like dynamic library failed to compile. A couple of things to check

Do you have all the dependencies met?  They are listed here: https://github.com/LLNL/LEAP/wiki/Installing-and-Using-LEAP
Trying running the following command which should print out all the compilation errors: pip install -v .
I precompiled the dynamic libraries for version 1.0, you can just download them here: https://github.com/LLNL/LEAP/releases
One common error in the compilation is a CMake error.  A change that helped another user is listed here: encountered an error while running the demo #9 (comment)

I reinstalled the leap and encountered the same error in import leaptorch.
It seems that the installation is complete:

(py39) jp_peng@sn4622118213:~/Documents/DECBCT_unsup/LEAP$ pip install -v .
Using pip 23.3.1 from /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages/pip (python 3.9)
Processing /home/jp_peng/Documents/DECBCT_unsup/LEAP
Running command python setup.py egg_info
./etc/build.sh: 13: cmake: not found
/home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages/setuptools/dist.py:498: SetuptoolsDeprecationWarning: Invalid dash-separated options
!!
      ********************************************************************************
      Usage of dash-separated 'description-file' will not be supported in future
      versions. Please use the underscore name 'description_file' instead.

      This deprecation is overdue, please update your project and remove deprecated
      calls to avoid build errors in the future.

      See https://setuptools.pypa.io/en/latest/userguide/declarative_config.html for details.
      ********************************************************************************

!!
opt = self.warn_dash_deprecation(opt, section)
running egg_info
creating /tmp/pip-pip-egg-info-96dd29l4/leapct.egg-info
writing /tmp/pip-pip-egg-info-96dd29l4/leapct.egg-info/PKG-INFO
writing dependency_links to /tmp/pip-pip-egg-info-96dd29l4/leapct.egg-info/dependency_links.txt
writing requirements to /tmp/pip-pip-egg-info-96dd29l4/leapct.egg-info/requires.txt
writing top-level names to /tmp/pip-pip-egg-info-96dd29l4/leapct.egg-info/top_level.txt
writing manifest file '/tmp/pip-pip-egg-info-96dd29l4/leapct.egg-info/SOURCES.txt'
reading manifest file '/tmp/pip-pip-egg-info-96dd29l4/leapct.egg-info/SOURCES.txt'
writing manifest file '/tmp/pip-pip-egg-info-96dd29l4/leapct.egg-info/SOURCES.txt'
Preparing metadata (setup.py) ... done
Requirement already satisfied: numpy in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from leapct==1.0) (1.26.3)
Requirement already satisfied: torch in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from leapct==1.0) (2.1.2)
Requirement already satisfied: filelock in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from torch->leapct==1.0) (3.13.1)
Requirement already satisfied: typing-extensions in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from torch->leapct==1.0) (4.9.0)
Requirement already satisfied: sympy in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from torch->leapct==1.0) (1.12)
Requirement already satisfied: networkx in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from torch->leapct==1.0) (3.1)
Requirement already satisfied: jinja2 in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from torch->leapct==1.0) (3.1.2)
Requirement already satisfied: fsspec in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from torch->leapct==1.0) (2023.12.2)
Requirement already satisfied: MarkupSafe>=2.0 in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from jinja2->torch->leapct==1.0) (2.1.3)
Requirement already satisfied: mpmath>=0.19 in /home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages (from sympy->torch->leapct==1.0) (1.3.0)
Building wheels for collected packages: leapct
Running command python setup.py bdist_wheel
./etc/build.sh: 13: cmake: not found
/home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages/setuptools/dist.py:498: SetuptoolsDeprecationWarning: Invalid dash-separated options
!!
      ********************************************************************************
      Usage of dash-separated 'description-file' will not be supported in future
      versions. Please use the underscore name 'description_file' instead.

      This deprecation is overdue, please update your project and remove deprecated
      calls to avoid build errors in the future.

      See https://setuptools.pypa.io/en/latest/userguide/declarative_config.html for details.
      ********************************************************************************

!!
opt = self.warn_dash_deprecation(opt, section)
running bdist_wheel
running build
running build_py
creating build/lib
copying src/leaptorch.py -> build/lib
copying src/leapctype.py -> build/lib
/home/jp_peng/.conda/envs/py39/lib/python3.9/site-packages/setuptools/_distutils/cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated.
!!
      ********************************************************************************
      Please avoid running ``setup.py`` directly.
      Instead, use pypa/build, pypa/installer or other
      standards-based tools.

      See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details.
      ********************************************************************************

!!
self.initialize_options()
installing to build/bdist.linux-x86_64/wheel
running install
running install_lib
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/wheel
copying build/lib/leapctype.py -> build/bdist.linux-x86_64/wheel
copying build/lib/leaptorch.py -> build/bdist.linux-x86_64/wheel
running install_egg_info
running egg_info
creating src/leapct.egg-info
writing src/leapct.egg-info/PKG-INFO
writing dependency_links to src/leapct.egg-info/dependency_links.txt
writing requirements to src/leapct.egg-info/requires.txt
writing top-level names to src/leapct.egg-info/top_level.txt
writing manifest file 'src/leapct.egg-info/SOURCES.txt'
reading manifest file 'src/leapct.egg-info/SOURCES.txt'
writing manifest file 'src/leapct.egg-info/SOURCES.txt'
Copying src/leapct.egg-info to build/bdist.linux-x86_64/wheel/leapct-1.0-py3.9.egg-info
running install_scripts
creating build/bdist.linux-x86_64/wheel/leapct-1.0.dist-info/WHEEL
creating '/tmp/pip-wheel-bqy16jhg/leapct-1.0-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
adding 'leapctype.py'
adding 'leaptorch.py'
adding 'leapct-1.0.dist-info/METADATA'
adding 'leapct-1.0.dist-info/WHEEL'
adding 'leapct-1.0.dist-info/top_level.txt'
adding 'leapct-1.0.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
Building wheel for leapct (setup.py) ... done
Created wheel for leapct: filename=leapct-1.0-py3-none-any.whl size=27450 sha256=07f591e9b39a67899ee488b51c5ddf5241af41d4205d4b2651735f4b242e8cbc
Stored in directory: /tmp/pip-ephem-wheel-cache-8vgl3igw/wheels/0e/f9/1b/fe1249fe8768085c66444dc1f522370c4ea10bfba6fd055a76
Successfully built leapct
Installing collected packages: leapct
Successfully installed leapct-1.0

Unfortunately, it always says "Successfully installed leapct..." even though it is not successful.
Anyway, if you look at the output you posted you can see that it says "./etc/build.sh: 13: cmake: not found"
For some reason your system cannot find cmake.  This is what is causing your issues and you'll have to resolve this.  Again, you can always use the precompiled library if you are still having trouble.

Unfortunately, it always says "Successfully installed leapct..." even though it is not successful.
Anyway, if you look at the output you posted you can see that it says "./etc/build.sh: 13: cmake: not found"
For some reason your system cannot find cmake. This is what is causing your issues and you'll have to resolve this. Again, you can always use the precompiled library if you are still having trouble.

Thanks for your help! I reinstalled cmake and leapct, seems working now.


PLT-2863 adding remove from team to javascript driver

+1

+1

@coreyhulen should we hold this until https://github.com/mattermost/platform/pull/3429 is in?

yup...lets hold it off.  I'll merge it when ready.

+1 if no more work is needed and test have to be commented


Not working with latest h5p-php-library

It seems that this library is not working with the latest h5p-php-library (1.22). Could you either freeze the h5p-library version or update the code (add the missing interface implementations)? Many thanks in advance

solved

Unfortunately not yet working on my PC. Opening /create does not show the h5p editor. I use Laravel 5.8, PHP 7.1 and Windows. This is what I see:

On /h5p the menu on the top right is also now visible: See ...

Can you reproduce the error?

I think the problem of the startpage has to do with Bootstrap. Laravel 5.8 uses Bootstrap v4 and I think you are using v3.3.

Unfortunately not yet working on my PC. Opening /create does not show the h5p editor. I use Laravel 5.8, PHP 7.1 and Windows. This is what I see:

On /h5p the menu on the top right is also now visible: See ...

Can you reproduce the error?

populate the db and use the correct version of h5p-core/editor

first you can upload library  /library


Roll engine 1ecf924ff861..ab01d73960d6 (2 commits)

https://github.com/flutter/engine/compare/1ecf924ff861...ab01d73960d6
git log 1ecf924ff86146c09ce834b295a2c4446122857c..ab01d73960d677f3a035b56ccaa991c0eb892ffc --no-merges --oneline
ab01d7396 Roll src/third_party/skia d425dee662d1..037884e5080b (10 commits) (flutter/engine#8778)
a0bb23aad Fix header include guards for fml/thread_local.h (flutter/engine#8721)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (bmparr@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/5169996886966272

Commit queue failed; closing this roll.


Failed to Compile. Fresh install

Reproduce:
npx create-react-app my-app
cd my-app
yarn start
yarn version: 1.22.10
Error: Failed to Compile
./src/index.js 1:43
Module parse failed: Unexpected token (1:43)
File was processed with these loaders:

<EMAIL_ADDRESS>./node_modules/react-scripts/node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.

$RefreshRuntime$ = require('/Volumes/Colin's Mac/seeifitworks2/node_modules/react-refresh/runtime.js');
| $RefreshSetup$(module.id);
|

Describe the bug
(Write your answer here.)
Did you try recovering your dependencies?

(Write your answer here.)
Which terms did you search for in User Guide?

(Write your answer here if relevant.)
Environment

(paste the output of the command here.)
Steps to reproduce

(Write your steps here:)

Expected behavior

(Write what you thought would happen.)
Actual behavior

(Write what happened. Please add screenshots!)
Reproducible demo

(Paste the link to an example project and exact instructions to reproduce the issue.)

I found out that it works when I don't install the react-app on my external hard drive but it fails if I do. Also, using react-scripts version 4.0.1 solved it for now.

Hi @ColinEberhardt ,
glad you got it working.
Similar issue in https://github.com/facebook/create-react-app/issues/10518
Check that you are

Running the latest version of CRA
You don't have globally installed versions of CRA (for example on the external drive for some reason)
Your Node and NPM/Yarn versions are up to date.

@colinsteidtmann This is only a guess, but I see that the path with Colin's Mac has a single quote and a space in it. It probably works from your external hard drive as the path doesn't have a single quote.
#10518 also has a single quote in the path with a similar error.


Fix Object Destructor

[X] Add AutoDestructor To Object
[ ] Investigate and fix: why when invoking destruct the Object gets deleted twice.
[ ] Why when the AutoDestructor occurs, then the Object doesn't get deleted entirely.

Notes so far:
after the destructor of MemberList is invoked,
the MemberList's address is not being removed from AllocationTableList !!!. we need to remove it !!!
==8345== Invalid read of size 8
==8345==    at 0x10A003: Legacy_ListDestructorWithInvokingDeconstructorOfEachNodeData (in /mnt/i/Tal/Code/c/class/src/main/a.out)
==8345==    by 0x1097ED: Legacy_AllocationTableDestructor (in /mnt/i/Tal/Code/c/class/src/main/a.out)
==8345==    by 0x1099A9: DestructLegacy_AllocationTableListNonGeneric (in /mnt/i/Tal/Code/c/class/src/main/a.out)
==8345==    by 0x109A44: Legacy_AllocationTableListDestructor (in /mnt/i/Tal/Code/c/class/src/main/a.out)
==8345==    by 0x109BA0: runAfterMain_Legacy_AllocationTableList (in /mnt/i/Tal/Code/c/class/src/main/a.out)
SOLUTION FOUND
We forgot to deconstruct AutoDestructable in MemberList -> Legacy_MemberList !!!!
(Just like we deconstructed it in Circle.h)

NOTE: you can always look at Circle.h For a good Destructor for a class that implements AutoDestructable.

This issue now DEPENDS ON #29 in order to be closed!


Enable build scripts to know if we are in manifest mode

Required for https://github.com/microsoft/vcpkg/pull/16613 to work, otherwise it does nothing.
I did not see any other way to determine if manifests were being used without making this code change. If there is a way for https://github.com/microsoft/vcpkg/pull/16613 to work without this code change, please let me know.

Blocked on https://github.com/microsoft/vcpkg/pull/16613#issuecomment-799801106


Re-usable/package deploys: pyinfra.api.deploy

pyinfra.api.deploy would be similar to the operation module, but @deploy wrapped functions define groups of operations, a "deploy".
Need spec/example/bootstrapping support in pyinfra.

No need for this - simple Python functions can be used to achieve exactly this without any wrapper nonsense.


Error in csv package file

I'm getting csv package does not exist error. can you help me to fix this error?

@indirajith17 Yes, we're going to try to fix it. What exactly is the error, could you elaborate?

When i run the code it shows Error:(49, 1) error: package com.openCSV.CSVWriter does not exist(MainFragment.java)

When you look in the project structure, there is a folder called 'libs' in here there is a library 'opencsv-3.7.jar'. Maybe it is not added as library in your case?

Okay let me check...

But jar file 'opencsv-3.7.jar' is already added in the dependencies...

I cleared the error. Thank you @MitchelldeVries and @Boyd261