Rename ServiceCollection in the test specification to TestServiceCollection

The type name already exists in Microsoft.Extensions.DependencyInjection so it's a bit confusing since they don't have the exact behavior.

Fixed in https://github.com/aspnet/DependencyInjection/commit/62d28e097eefccce16954359c84ba7badb7c49a6


Add GitLab icon when generating previews

Feature for the domain

Our Domain: preview.dragon-code.pro

Released


Ford: catch camera ACC faults

Catch cases where camera is faulted, but not PCM.
Just opened to verify with data later
If the IPMA gets bad quality flags from the EPS (any counter & checksum fine) it will raise this signal, for example

looks good to me, IPMA ACC is never active when this is set, and there's only two real cases in the wild. one is caused by some blocked messages on a maverick, and one is unknown, but resolves in the next drives


Thought experiment: compiled uw-frame deliverables

As a developer
I regularly need to provide dynamic REST APIs that are configured as providers for the SERVICE_LOC fields (sessionInfo, sidebarInfo)
so that the values returned by those providers can vary dependent on authenticated user/server environment/time of day/whatever.
In 2 uw-frame applications we've written, we have twice needed to make back end programming language representations of the data objects presented by sessionInfo and sidebarInfo.
Example:
/**
   * Bean matching data model represented by /staticFeeds/session.json.
   *
   * @author Nicholas Blair
   */
  public class Person {

    private final String username;
    private final String sessionKey = "";
    private final String serverName = "";
    private final String displayName;
    private final Build build;

    public Person(Environment environment, String username, String displayName) {
      this.username = username;
      this.displayName = displayName;
      this.build =  new Build(environment.getProperty(GIT_COMMIT_ID_ABBREV), environment.getProperty(GIT_BRANCH), environment.getProperty(PROJECT_VERSION), environment.getProperty(GIT_TAGS));
    }

// ...truncated for brevity
}

/**
   * Bean matching model presented by /staticFeeds/sidebar.json
   *
   * @author Nicholas Blair
   */
  public class Sidebar {
    private String title = "";
    private String hyperlink = "";
    private String target = "";
    private String faIcon = "";
    private String displayFlag = "";
    /**
     * @return the title
     */
    public String getTitle() {
      return title;
    }
// ... truncated for brevity
}

2 times I've had to copy these same classes into 2 apps. In the interest of DRY, it would be nice to have some project, preferably with an established dependency relationship with this project, including tests that guarantee we don't regress incompatible data model changes between the 2 projects, that provides compiled artifacts that represent these objects, so that I don't have to copy them into each app project that needs them.
I'm opening this to start a discussion on how we might deliver artifacts like this. Would we make this multi-module? Would we make them separate projects? Would we do this in uw-frame, and ship a classes jar (I'm :-1: on this)? What about other programming languages, like Go and PHP?

I like the idea of supporting this, I also like the idea of supporting multiple languages. Goes toward my vision of a bower module for uw-frame. What about protobuffers?.
Another idea is just to put those model objects in a class somewhere.

The somewhere is really what I'm asking for. I don't think it would go in the current war deliverable that uw-frame ships now, it wouldn't be usable. We would have to publish a classes jar for uw-frame too, which can have some quirks in downstream app assembly.
Where would we put the protobuffer deliverables? In the uw-frame war? How would a downstream Java app reference them for say a Spring WebMVC @RestController? How about a downstream PHP or Go app?

Create a module in app-seed, uw-frame-utils project?

I kind of feel like if it is a separate repo, it might get forgotten, unless we are really on top of it. How are you maintaining the classes now? Just looking at diffs when upgrading frame?

Those classes currently are in their respective app projects.
If uw-frame is characterized as the 'java solution for frame based projects', then I think going multi-module is the appropriate approach. But, if uw-frame is not just for java projects (and I think that's on the roadmap, with our look at alternatives like Go and PHP), then I'm hesitant to think multi-module is the right answer. The non-java projects will need so pull in frame using something like bower. The java projects could do this too.

My thought on the multi lang support would be transition the repo uw-frame to be uw-frame-java, then create a uw-frame-angular-components or something like that.
We could also just have one repo to rule them all:
uw-frame
 - uw-frame-java-webapp (creates the war that is deployed to maven central)
 - uw-frame-angular-components (creates the uw-frame bower component that is deployed to bower)
 - uw-frame-protobuf (using the protocol buffer compiler, could generate a jar)
 - ...etc...

I like the idea of making uw-frame multi-module with, e.g., a new uw-frame-api becoming a dependency of uw-frame, containing interfaces that a given app can implement.
The key is that an -api module is a common dependency of both server and client, but that's not possible to include non-java languages without something special like protobuf.  IMHO, I would go with a plain ol' java solution until other language implementations actually exist.

I like the one repo approach you've laid out there, :+1:
Tucking other - even non Java - projects as siblings of uw-frame-protobuf could be accomplished too.

Cool, so i think we have a good path forward. We have already migrated to a multimodule project. Feel free to add model objects to uw-frame-java as you see fit. I'm going to close this thought experiment as a success. Thanks!


CloseReason Enum bad description

Link to article:
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.closereason?redirectedfrom=MSDN&view=netframework-4.8
Problem:
When you describe the fields of this Enumeration you state that the 'UserClosing' happens when: "The user is closing the form through the user interface (UI)". But this also happens when you use 'Close' method for a form in your code.
It would be great to distinguish the UI Closing from the code closing.

@rloutlaw can you please take a look at this issue?

This could be moved to our repo: https://github.com/dotnet/dotnet-api-docs/issues

Moved: https://github.com/dotnet/dotnet-api-docs/issues/2844


Encoding issues after update  7.4.0-preview.4 when using OhMyPosh

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Install OhMyPosh on versions up to  7.4.0-preview.3
Use the template provided by Scott Hanselman, although this step might not be necessary
Try it and the path characters will be just fine
Update to  7.4.0-preview.4 and the characters encoding (specially icons) will be all messed up

Expected behavior
It should show the icons and characters just like preview 3 and previous versions.

Actual behavior
Sample:

PowerShell 7.4.0-preview.4
[Constrained Language AUDIT Mode : No Restrictions]
Loading personal and system profiles took 3841ms.
¯éÂ ¯ù┐ ~ ¯é░¯é░ ¯ê║´É« ¯é░

PS: This Constrained Language AUDIT Mode didn't appear before preview 4

### Error details

_No response_

### Environment data

```powershell
Name                           Value
----                           -----
PSVersion                      7.4.0-preview.4
PSEdition                      Core
GitCommitId                    7.4.0-preview.4
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
No response

Powershell 7.4.0 was just released and this still happens. Any workarounds? Guessing it has something to do with WDAC?

@julianonunes Don't know if this is still a problem for you, but I set the output encoding to UTF8 in my Powershell profile, which finally solved it.
[Console]::OutputEncoding = [Text.Encoding]::UTF8

try {
    oh-my-posh init pwsh --config ~/oscar.omp.json | Invoke-Expression
} finally {
}

@julianonunes Don't know if this is still a problem for you, but I set the output encoding to UTF8 in my Powershell profile, which finally solved it.
[Console]::OutputEncoding = [Text.Encoding]::UTF8

try {
    oh-my-posh init pwsh --config ~/oscar.omp.json | Invoke-Expression
} finally {
}

It worked for me! Thanks for sharing @svdbrg

@julianonunes Don't know if this is still a problem for you, but I set the output encoding to UTF8 in my Powershell profile, which finally solved it.
[Console]::OutputEncoding = [Text.Encoding]::UTF8

try {
    oh-my-posh init pwsh --config ~/oscar.omp.json | Invoke-Expression
} finally {
}

That worked for me too. Thank you

@julianonunes Don't know if this is still a problem for you, but I set the output encoding to UTF8 in my Powershell profile, which finally solved it.
[Console]::OutputEncoding = [Text.Encoding]::UTF8

try {
    oh-my-posh init pwsh --config ~/oscar.omp.json | Invoke-Expression
} finally {
}

This worked for me as well.
Thanks 🥳🥳🥳

Related to #20733


Add rickie as reviewer to .renovaterc.json

Added a commit, I hope you don't mind using the same PR. :)


Review ASP.NET Core templates

We should review:

Code (including anything that impacts EF tooling)
Initial generated migration
Consistency/experience across different platforms

See https://github.com/aspnet/templating/issues/4. For consistency, having the same experience regardless of platform would be better. For simplicity of the SQLite experience, having the database file in the template might be better.

Please add IdentityUser POCO navigation properties.

@anpete @divega Just starting to look at this. The default connection string still has MARS enabled--is this still the "right thing to do" with EF Core 2.1?

@ajcvickers Yeah, I think so.

Looking good for 2.1. The consistent experience is still lacking, but that's punted for 2.1 anyway.


Impossible to bundle JSON Schema draft-04 itself.

Here is my basic schema:
{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "additionalProperties": false,
    "properties": {
        "schema": {
            "$ref": "http://json-schema.org/draft-04/schema",
            "title": "schema"
        },
        "tags": {
            "items": {
                "enum": [
                    "forge"
                ],
                "type": "string"
            },
            "title": "tags",
            "type": "array"
        },
    },
    "required": [
        "schema"
    ],
    "type": "object"
}

My code is:
const $RefParser = require('json-schema-ref-parser');

$RefParser.bundle("schema.json").then(schema => {
   console.log(JSON.stringify(schema, null, 2));
}).catch(e => {
   console.error(e);
});

As you can see in "$ref": "http://json-schema.org/draft-04/schema",, I want to bundle the draft-04 schema. Instead, my output is:
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "additionalProperties": false,
  "properties": {
    "schema": {
      "$ref": "#/properties/schema/properties/not",
      "title": "schema"
    },
    "tags": {
      "items": {
        "enum": [
          "forge"
        ],
        "type": "string"
      },
      "title": "tags",
      "type": "array"
    }
  },
  "required": [
    "schema"
  ],
  "type": "object"
}

That's not even a valid schema. This looks like a bug to me but I would be very interested in understanding what I have done wrong.
Can somebody please confirm if this is a bug? Cheers.

Oh, here is a complete bundle of a sample app.
error-example.zip

Can you expand on why this needs to work? Not sure of the use case or what is happening, the issue is pretty sparse on informetion.

@philsturgeon If I want to have a JSON value, that contains a JSON Schema at v4, then I should be able to just reference the v4 schema as a validator. And then when I run the bundle tool here on it, it should make sure that it is bundled inline and that everything works as expected.

What do I need to provide such that the use case is easier to understand here? I'm confused that it's not clear that this is a bug and what the expected output would be.

What tool are you passing this JSON value too that it needs the JSON Schema $schema definition bundled in? Why would a tool want or need that to be done?


[Bug]

Is this a new bug?

[X] I believe this is a new bug
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
await index.update({                 id: embeddingId,                 metadata: { property1: val1 // Update existing metadata property                     property2: val2, // Add new metadata property                 }             });
property1 is modified
property2 is not added
Expected Behavior
property1 is modified
property2 is added
Steps To Reproduce

upsert an embedding
add a new metadata property to the above embedding using the update method

Relevant log output
No response
Environment
- **OS**: Windows 10
- **Language version**: nodejs 18
- **Pinecone client version**:2.0.1

Additional Context
the index seats in Pinecone serverless

never mind, I had a bug in my code causing the above behaviour. Apologies for the false alert!


read_to_end() in server side may occupy thread for long time

https://github.com/laoshanxi/app-manager/commit/eb55242004dc0764e82ab06283c3381136c1edb2


Update component's size fitContent

**Update: **
Breaking change in the box component, looks like it wasn't working properly.

Should we consider wrapping or ellipsis for the dropdown, the tag and the slider?
When the content is really large they can affect the width of the container or the window, while other components jump to the next line or have ellipsis.

Opened discussion about its behaviour: Behavior for components with fitContent


"firsLetters" function is not aligned with 'first_letters' colum of 'line' table from ShabadOs database

Question
I am trying to query data from 'lines' table of ShabadOs database using 'first_letters'  column. Before I fetch data, for some reasons I use firstLetters function from 'gurmukhi-utils' on a line from ShabadOs database. I found out that in the column 'first_letters' of 'lines' table of the database is ignoring lower case 'i' therefore there is no lower case 'i' in the 'first_letters' column for any row in the database but the firstLetters function is not ignoring the lower case 'i'. Is it intentional this behavior ?
Example from a line taken from ShabadOs database:
id             shabad_id     first_letters     gurmukhi
"C5NR"	"ZKH"            "gkvvv"	  "gwvY ko; ividAw ivKmu vIcwru ]"
As you can see the column 'first_letters' for the data from 'gurmukhi' column is 'gkvvv' and apparently it is skipping every lower case 'i' but on the hand when i run 'firstLetters' function from 'gurmukhi-utils' it is not skipping lower case 'i'.
firstLetters("gwvY ko; ividAw ivKmu vIcwru ]"); // it gives me "gkiiv".
I just want to know is it intentional or it is a bug ?
Dhanwaad

Hello,
If you take the gurmukhi string gwvY ko; ividAw ivKmu vIcwru ] and convert it into unicode / transliterate to English, you will get:

ਗਾਵੈ ਕੋ; ਵਿਦਿਆ ਵਿਖਮੁ ਵੀਚਾਰੁ ॥

gaavai ko; vidiaa vikham veechaar |

As you can see, the first letters are gkvvv. The lower case i in the old ASCII gurbani fonts is the equivalent of unicode ਿ as you can see on the first 2 v-starting words.
If you read the docs for firstLetters you will see that it is intended to run on unicode gurmukhi/hindi or english transliterations:

Generates the first letters for a unicode Gurmukhi, Hindi transliteration, or English transliteration string. Includes any end-word vishraams, and line-end characters.

It is not meant to be used on the ASCII gurbani font language. So I can confirm that you would get gkiiv using firstLetters on the string gwvY ko; ividAw ivKmu vIcwru ], but that is not something we intended firstLetters to be used on. Perhaps you can convert to unicode before running firstLetters then converting back to ASCII?
Or I suppose, may I ask what you're trying to accomplish? Then maybe we can help better.

Thank you for clarifying about 'firstLetters' function. I will be first converting the text to Unicode then to ASCII as you suggested.
I would try to connect with you and other members of ShabadOS team on slack to further share informations about what I am building.
Thank you once again.


feat: Added wait method on FfmpegChild

Every call to spawn without a call on the Result to wait results in a zombie process that stays until the main thread exits. This lead to OS issues with large datasets because it is possible that all PID's are used by the zombies.
This PR exposes the wait method of std::process::Child to the user, giving the possibility to wait for the process to complete and clean up properly.
It has only been tested on Linux.
I am happy to further adjust the code to your coding/documentation style requirements.
Best regards,
Lewin

Thank you for the PR Lewin 🙏
I tested this branch on Windows and it works for me.
One thing to keep in mind: There is an additional escape hatch on FfmpegChild -- by using the methods as_inner() and as_inner_mut() you can access any method on the inner std::Child instance. Having said that, I like the fact that your change makes the wait method even more easily accessible, and that the comment on spawn() calls attention to a behavior which might otherwise be overlooked. as_inner_mut() can still be used for really uncommon situations like maybe accessing the Child id(), or calling try_wait(), or something else like that.
LGTM! 👍


Update codecov.yml

Codecov Report

Merging #3 (43c598e) into main (3ffe71f) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##            main      #3   +/-   ##
=====================================
  Coverage   0.00%   0.00%
=====================================
  Files          6       6
  Lines        116     116
=====================================
  Misses       116     116

Help us with your feedback. Take ten seconds to tell us how you rate us.


Adding a refreshed date to sessions

On the client we'd like to detect when it's a good moment to refresh the session. Currently we only have a issued date (which is set to the date of a login) and a expires date. This means that after a refresh (which don't currently update the issued) it's impossible to determine a good moment to call refresh.
Also see: https://github.com/micky2be/superlogin-client/issues/59
I propose we add a refreshed field?
Updating the issued doesn't really make sense to me since the token / key and password remain the same?

I like the idea. I will consider this PR next time I get around to making fixes.


Development Mode - Persist Dashboard on reload

I build some Plugins for my Dashboard. But every time a have to test some changes i need to reload the page to get the JS changes. But then all my panels and data sources are lost.
How can i get them persistent on reload?

If you're doing this all with a local file, I don't believe there is a way to keep it persistent, but here is one solution:

Create all the datasources and panels you want.
Click 'Save Freeboard'.
After you make your changes, reload the page and select 'Load Freeboard' and choose the json file from the second step.

If you're doing this on a server, here is the next best thing:

Create all the datasources and panels you want.
Click 'Save Freeboard'
Make your changes, then reload the page with '#source=dashboard.json' at the end of the url.

thanks, that works


add support for data object to insertAtomicBlock function

Summary
Adds an optional data parameter to the AtomicBlockUtils.insertAtomicBlock function. This is helpful if you don't need an entity and simply want to associate some metadata with the block itself. This is also a request that I've seen come up in the slack a few times
https://draftjs.slack.com/archives/C0PBTNQGY/p1503009836000334
If I'm missing something about why it's better to associate the metadata with an entity than directly with the atomic block, I'm all ears to that as well :)

looks like builds are broken on master because of the flow stuff
would still love a review if anyone has time


Update project file as recommended by Xcode

Xcode recommends these changes whenever a change is made to the project file.

@philium It looks like the files are just removed and added back. Do you know why Xcode recommends this change?

@gdhakal In my experience, Xcode recommends changes like this from time to time when recently added files are not ordered properly. That usually is the result of resolving a merge conflict in the project file. Whenever another change is made to the project file (adding a file, renaming a file, etc.), Xcode rebuilds the project file, causing ordering issues like this to show up. I've found it is helpful to commit these recommended changes via a separate PR so as not to pollute the next PR that makes a change to the project file.

@philium Thanks for clarifying that.


Implement optional implicit allowing usage of circe decoders without EntityDecoder definition

I've discussed the necessity of this implicit in gitter. Appeared useful.

The first point is already mentioned in https://github.com/http4s/http4s/pull/1917/files#diff-dcf0079785763cffc8cb901dad9f0628R205 Should I clarify it?
And I doubt that incoherent instances are possible in the same scope: they result in ambiguous implicits error.

I looked at the diff, and not the wider context.  You're right, I think the first point is covered well enough.
As for the second issue, a lexically scoped instance (e.g., import CirceEnityDecoder._) has higher priority than an implicitly scoped instance (e.g., one found on the companion of EntityDecoder).  So the issue here is that Ok("foo") compiles with or without this new import, but the behavior varies.  It's fine as long as people know the ramifications, but it's a situation that I personally prefer to avoid.

I tried testing the implicit resolution and found that it does not compile at all. Somehow EntityDecoder from companion and generic one got the same priority.
Here's the repro: https://github.com/Leammas/http4s/blob/4f114c4ecccc3ab01a6b0491968056de527cdd5c/circe/src/test/scala/org/http4s/circe/CirceSpec.scala#L191


Add docs for integrating Longclaw in existing projects

Hi,
I didn't see any docs on how to integrate Longclaw into an existing Wagtail project. So here's what I have so far.
I couldn't get the docs to build on my machine. make docs errored:
make -C docs clean
make[1]: Entering directory '/home/jonas/Projects/sides/longclaw/docs'
make[1]: *** No rule to make target 'clean'.  Stop.
make[1]: Leaving directory '/home/jonas/Projects/sides/longclaw/docs'
make: *** [Makefile:49: docs] Error 2

Thanks for the PR! I'll review it in the week but I don't think there will be any problems to get this merged asap


nomacs: 3.17.2295 -> 3.19.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/nomacs/versions.
meta.description for nomacs is: Qt-based image viewer
meta.homepage for nomacs is: https://nomacs.org
meta.changelog for nomacs is: https://github.com/nomacs/nomacs/releases/tag/3.19.0
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.19.0 with grep in /nix/store/c7xcxaszk3j218j52rncii67akdsmkds-nomacs-3.19.0
found 3.19.0 in filename of file in /nix/store/c7xcxaszk3j218j52rncii67akdsmkds-nomacs-3.19.0

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

nomacs

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/71448bf2147464c004ed1d38181ab6edd2ad5019#nomacs

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

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

2 packages built:

nomacs
nomacs.man

Maintainer pings
cc @AndersonTorres @Mindavi for testing.

For x86_64-linux, seems to work fine:
Result of nixpkgs-review pr 325977 run on x86_64-linux 1

2 packages built:

nomacs
nomacs.man

Also tried starting it and viewing a few images. Didn't test any other functionality. Let's wait a bit for darwin since we've seen it break before and I don't have a way to verify darwin functionality.

Unlikely it will finish any time soon, let's just go for it.


Compare inferred read length statistics to SRA metadata

I've been looking into the reported read length data from the SRA sample dataset, reran the ones with errors and modified the testing script so the inferred length would always get reported, no Undecided left (please compare it to the results in the performance issue)

With this, there were 563 matches and 215 mismatches left.
Then I found that the read statistics from the second mate in paired samples didn't get correctly reported in the results, so I fixed that (see commit). I also added the additional read statistics (mean, median, mode) to the results, and compared the SRA reported read length to that, after which most (745 out of 779) read length results were matches.

I checked the rest individually (33 + 1 sample where there was no length metadata) on SRA, all of those had the mean read length reported in our sample data, and the difference was always ±1 (e.g. SRR18675578 with the SRA reported mean length of 138, in our sample data table we had 137 bp, while the inferred mean is 138.03, so I corrected that).
I would say the read inference works as intended now, with the additional stats getting reported, it matches the metadata from SRA.

That's fantastic work, thanks a lot @balajtimate :pray:


Add "pharos ssh" command to launch ssh into cluster hosts

Adds "pharos ssh" subcommand that can be used to launch a ssh session that connects to a host in the cluster configuration.
There are filtering options to select hosts based on roles, labels or their addresses.
Usage:
    pharos-cluster ssh [OPTIONS] -- [COMMANDS] ...

  Opens SSH sessions to hosts in the Kontena Pharos cluster.

Parameters:
    [COMMAND] ...                 Run command on host

Options:
    -r, --role ROLE               select a server by role
    -l, --label LABEL=VALUE       select a server by label, can be specified multiple times
    -a, --address ADDRESS         select a server by public address
    -p, --private-address ADDRESS select a server by private address
    -P, --use-private             connect to the private address
    -f, --first                   only perform on the first matching host
    -h, --help                    print help
    -c, --config PATH             path to config file (default: cluster.yml)
    --tf-json PATH                path to terraform output json
    -y, --yes                     answer automatically yes to prompts
    --[no-]color                  colorize output (default: true)
    -v, --version                 print pharos-cluster version
    -d, --debug                   enable debug output (default: $DEBUG)

$ bundle exec bin/pharos-cluster ssh -r master -- ls -al
==> Reading instructions ...
==> Opening a session to<EMAIL_ADDRESS>..
total 36
drwxr-xr-x 6 vagrant vagrant 4096 Aug 14 07:33 .
drwxr-xr-x 4 root    root    4096 Aug  2 11:11 ..
-rw-r--r-- 1 vagrant vagrant  220 Mar  6 08:30 .bash_logout
-rw-r--r-- 1 vagrant vagrant 3771 Mar  6 08:30 .bashrc
drwx------ 2 vagrant vagrant 4096 Aug  2 11:11 .cache
drwx------ 2 root    root    4096 Aug 14 07:33 .gnupg
drwx------ 2 vagrant vagrant 4096 Aug  2 11:51 .kube
-rw-r--r-- 1 vagrant vagrant  655 Mar  6 08:30 .profile
drwx------ 2 vagrant vagrant 4096 Mar  6 08:30 .ssh

Removed the --private-address host selector and the non-interactive sessions now go through Pharos::SSH::RemoteCommand, in parallel when multiple hosts.

Fixes applied


Add ability to merge results of sequence of promise resolving

Duplicate of https://github.com/kuzn-ilya/react-promise-renderer/issues/8


[BEAM-11227] Cherry pick #14295 to release 2.29.0: Moving from vendored gRPC 1.26 to 1.36

This upgrades release-2.29.0 branch to the new version of gRPC. We will want to do some thorough testing.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[x] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

@suztomo

Run Java PreCommit

Run Java_Examples_Dataflow PreCommit

Run GoPortable PreCommit

run java precommit

I wonder if this is the same as your build, where we need caching or it cannot pass. We should increase the timeout to alleviate the pain.

@kennknowles That might help. But from my observation, increasing timeout is not going to help, because something is stuck; no output for about 110 minutes before 120-minute timeout happened.

https://ci-beam.apache.org/job/beam_PreCommit_Java_Phrase/3330/console

Run Java PreCommit

Run GoPortable PreCommit

Run GoPortable PreCommit

I'm not certain of the status of GoPortable PreCommit at the fork point from master. @lostluck are there any known issues?

I'm not certain of the status of GoPortable PreCommit at the fork point from master. @lostluck are there any known issues?

Not that I'm aware of. The cut was happening while that target was being added so it could be any number of things. I don't track cut times, as they are not yet relev

OK I won't worry about that target. Noting that everything else was green. But I am worried about this phenomenon where the Java PreCommit either times out or finishes in 15ish minutes. As in https://ci-beam.apache.org/job/beam_PreCommit_Java_Phrase/3336/
This is happening on master, too.

Not that I'm aware of. I don't track cut times since the SDK is still experimental.
The target was added about the time of the cut and new targets do usually have issues. But the issue is with the target bot the underlying sdk or container code, because that doesn't change very often (more or less why the sdk remains experimental...)
Looking at the previous run of the phrase, it looks like the network shorted out while go was getting the dependencies.
Task :release:go-licenses:java:dockerRun
07:20:01 # cd .; git clone -- https://go.googlesource.com/protobuf /go/src/google.golang.org/protobuf
07:20:01 Cloning into '/go/src/google.golang.org/protobuf'...
07:20:01 error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull function.
07:20:01 fatal: the remote end hung up unexpectedly
07:20:01 fatal: early EOF
07:20:01 fatal: index-pack failed
07:20:01 package google.golang.org/protobuf/reflect/protoreflect: exit status 128
07:20:01 cannot find package "google.golang.org/protobuf/runtime/protoimpl" in any of:
But the cut could have been before the dependency copying issue was fixed.
Either way, I would ignore the failure.

Well, everything is healthy here now, but given the CI issues on master I will hang tight and not merge yet.

Based on the revert on master, I will not merge this to the release branch.


MRG, ENH: Better introspection for optimization

Simplifies our verbose wrapping a little bit. Checked that import mne times are unchaged. Achieves a couple of things:

Cleans up tracebacks by removing one level of depth.

master
larsoner@bunk:~/Desktop/richard$ python -ui find_bads.py
^CTraceback (most recent call last):
  File "find_bads.py", line 21, in <module>
    test()
  File "find_bads.py", line 14, in test
    bads = mne.preprocessing.find_bad_channels_maxwell(
  File "</home/larsoner/python/mne-python/mne/externals/decorator.py:decorator-gen-373>", line 2, in find_bad_channels_maxwell
  File "/home/larsoner/python/mne-python/mne/utils/_logging.py", line 89, in wrapper
    return function(*args, **kwargs)
  File "/home/larsoner/python/mne-python/mne/preprocessing/maxwell.py", line 1901, in
find_bad_channels_maxwell
    time.sleep(60)
KeyboardInterrupt

PR
larsoner@bunk:~/Desktop/richard$ python -ui find_bads.py
^CTraceback (most recent call last):
  File "find_bads.py", line 21, in <module>
    test()
  File "find_bads.py", line 14, in test
    bads = mne.preprocessing.find_bad_channels_maxwell(
  File "<decorator-gen-373>", line 9, in find_bad_channels_maxwell
  File "/home/larsoner/python/mne-python/mne/preprocessing/maxwell.py", line 1901, in find_bad_channels_maxwell
    time.sleep(60)
KeyboardInterrupt

Simplifies verbose code (see changes).

Improves snakeviz:

master has a nasty recursion/repetition going on (note what I moused over to make pink shows up multiple places). It makes it hard to see what is actually taking time, and also snakeviz/the browser struggles to render the default 1/1000 limit:

PR does not have this issue:

I've always struggled to use lprof with verbose decorated functions because they are wrapped. With this PR you can just use __wrapped__ and it works:
lprun -f find_bad_channels_maxwell.__wrapped__ test()

Updates our externals/decorator.py with the latest version. Not necessary for functionality but might as well be done to get any bug fixes.

LGTM provided CIs are happy


hashicorp/azurerm provider not being updated

Thank you for reporting an issue.
Hi!
It seems like the hashicorp/azurerm provider isn't being updated automatically.
The latest supported version right now is 3.87.0: https://github.com/opentofu/registry/blob/main/providers/h/hashicorp/azurerm.json
The latest released version is 3.90.0: https://github.com/hashicorp/terraform-provider-azurerm/releases/tag/v3.90.0
OpenTofu Version
OpenTofu v1.6.1
on linux_amd64
+ provider registry.opentofu.org/hashicorp/azurerm v3.87.0

OpenTofu Configuration Files
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "3.87.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_resource_group" "this" {
  name = "foobar"
}

Hi, thanks for reporting this, it looks like this is due to the our sync script failing. I'll fix this now =)
For reference: https://github.com/opentofu/terraform-provider-azurerm/actions/runs/7776526278/job/21203782811

Looking into the issue it looks like hashicorp moved their tag, and our sync script does not take this into account.
I've raised this up to the person who has permissions to edit the repo and we will remove the tags manually and sync again. However this may take a little bit of time as it's currently Sunday evening. So we do ask you be patient on this one, sorry!

Looking into the issue it looks like hashicorp moved their tag, and our sync script does not take this into account.
I've raised this up to the person who has permissions to edit the repo and we will remove the tags manually and sync again. However this may take a little bit of time as it's currently Sunday evening. So we do ask you be patient on this one, sorry!

Nice catch! I was able to use an older version of the provider and that worked just fine. 😊

Hi @simongottschlag.
Thanks for your patience on this one. We tracked down an approach and we've resolved how we keep this in sync.
You should now be able to use the latest versions of the azurerm provider again.
Thank you for reporting this! Please reach out if you hit any other issues with our registry


add react-native plugin

@jpiyali what should priority be? It only needs to be run after existing part A plugins
TODO:

Add to rush config
Add README, mentioning that users will need to run

$ react-native link react-native-device-info

@markwolff  - priority can be anything between 100 to 200.


wallet menmonic using --interactive flag provides a different wallet in Keplr than in CLI

Summary of Bug
see steps below
Version
v1.0.0
Steps to Reproduce
pops@val01-tia-t:~$ celestia-appd keys add testwallet --interactive

Enter your bip39 mnemonic, or hit enter to generate one.
password
Error: invalid mnemonic
pops@val01-tia-t:~$ celestia-appd keys add testwallet --interactive
Enter your bip39 mnemonic, or hit enter to generate one.

Enter your bip39 passphrase. This is combined with the mnemonic to derive the seed. Most users should just hit enter to use the default, ""
password
Repeat the passphrase:
password

address: celestia18fm7nzu5caj9wr6f5m020xyqgpptd8s6555j9g
name: testwallet
pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A4VmeJdqxmqEJ6fYrtAUeNdpQwQqjpkNxTkqMVq4H3e4"}'
type: local

Important write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password.
polar window arena rigid cable inch wife slide leave segment fortune shift enlist museum garbage spring price better garbage sketch noise harbor kick inhale
Now if you try to import this seed phrase into keplr, the address you get is: celestia16ncc9l58elkce7nlz3msztlc8xvyczrsaevlnf
I am guessing something is different with the derivation path if --interactive flag is used. If you dont use the flag, the address imported into Keplr is the same.
For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

we use the default cosmos-sdk keyring sub command, so I think we might want to bubble this up to the sdk. I also don't know how keplr works, should we expect both to handle mnemonics identically?

i think so, afaik @rootulp asked me that at some point if i remember correctly
but this is an issue for sure, especially since without the --interactive flag the address is the same on CLI and Keplr, and if youre using the flag, then it isnt, which might confuse people
ideally it should derive the same address on both

I actually failed to recreate this bug, was there a password added during the interactive portion?

Yes, the password is not empty,  didn't try that though...

Yes correct, so the flow was like this on 1.0.0:
use --interactive flag
press enter (for mnemonic)
type passphrase
repeat passphrase
V V čet., 12. okt. 2023 ob 21:36 je oseba Evan Forbes <
@.***> napisala:

I actually failed to recreate this bug, was there a password added during
the interactive portion?
—
Reply to this email directly, view it on GitHub
https://github.com/celestiaorg/celestia-app/issues/2674#issuecomment-1760255141,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANIP6FRDAAWR4NB6JB3NOMDX7BBCXAVCNFSM6AAAAAA56CAHSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRQGI2TKMJUGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

just going off the promp

Enter your bip39 passphrase. This is combined with the mnemonic to derive the seed. Most users should just hit enter to use the default, ""

if its being combined with the mnenomic, then we should actually expect the address to change. For me at least, when I didn't use a passphrase the address was the same using interactive mode and the latest version of keplr

Interesting, but for "normal" users it's not clear what this means I guess...
On the other hand, maybe we should defer "normal" users to the Keplr or Cosmostaion wallets by default and not using the CLI.

we use the default cosmos-sdk keyring sub command, so I think we might want to bubble this up to the sdk. I also don't know how keplr works, should we expect both to handle mnemonics identically?
@evan-forbes Are you expecting changing to the SDK will solve this behavior?

hmm i guess it makes sense but its still weird.. maybe it has something to do with the keyring test?
reason is, in no other tendermint chain have we come accross this, and we use custom passphrases on all those.. but if we restore that wallet to keplr it just shows the same address as in the CLI always

Are you expecting changing to the SDK will solve this behavior?

I just think the ideal place to fix bugs is upstream, especially when we're using the stock version and would prefer to keep it that way to avoid any other weird bugs.

maybe it has something to do with the keyring test?

could be yeah, we should try.
although I don't think this is a bug any longer, so if you agree, please close this :slightly_smiling_face:
having a mnemonic and adding a password does actually have its benefits. Mainly that we can store the mnemonic offline (eg on paper) in a safer way, since we're probably not encrypting it if we're writing it on paper. This way, I only have to remember the password and store themnemonic on paper. If someone gets the mnemonic, they still can't get the privkey without also knowing the password.

Hello! I'm the one that reported this on Discord.
I actually happened to put the wallet address that the CLI gave me in the genesis airdrop. Then tried to import this wallet on Keplr/Leap and received a different address (and wasn't prompted for the password when importing). So I thought this was weird and went to Discord.
Thanks to everyone that commented.  I googled how to create a Celestia wallet and clicked the first link everything gave me, and ended up on this document https://docs.celestia.org/developers/celestia-app-wallet/. When prompted for a password, I thought "why not?" and set one up. I backed up mnemonic phrase + password of course.
I think I fully qualify as a "normal" user, I actually work on software but I'm pretty new to crypto, so there's a lot of stuff I don't understand completely.
After reading all the comments, let me know if I understood correctly:

Having a mnemonic phrase AND a password actually means that the wallet "recovery key" is the mnemonic phrase encrypted using the password as an encryption passphrase, so the actual "recovery key" is not the mnemonic phrase itself, but the encrypted phrase
When importing the wallet on a wallet service (Keplr/Leap), as I'm not being asked for the password, the wallet is recovered using only the mnemonic phrase, thus the wallet address produced is different

The stuff I don't fully understand:

why am I able to import the wallet if the actual "recovery key" is the encrypted mnemonic phrase and not the phrase alone?
is the imported wallet on Keplr effectively the same wallet than the one I can manage on the CLI?
even if the wallet address is different, if I transfer funds to any of the two addresses, will the coins show up on both CLI and Keplr/Leap?

Also let me know if these questions are to be answered in another channel. Maybe this issue is not the one for it.
Thanks everyone ❤

@klaus993 those questions would be better for Discord than this issue, but here you go:

yes the mnemonic is additionally encrypted with a passphrase
you are able to recover A wallet, because each 12 or 24 word length seed will derive some address out
the imported wallet to Keplr in this case is not the same wallet at all, so transferring coins to one wont mean those coins are also on the other
i would imagine there is a way to decrypt it with that passphrase, but im guessing that has to be done in CLI rather than Keplr

@evan-forbes so i did some more testing and the weird thing is, if we go the --interactive rout and we hit enter on first step for mnemonic, then enter again at the step where it asks for a passphrase for mnemonic (not the actualy keyring), it just skips the keyring passphrase, which means the wallet is not protected by a passphrase at all. This seems weird to me, as then there is no way to just protect the keystore with a passphrase without also enrypting the seed, which i have also not seen elsewhere yet..
And yes its not a bug it seems but i guess still better to discuss this here? i am sure people like Klaus above and others will have lots of issues with this.

I have test again with the same options and it works as expected, giving a passphrase is adding a 25th word for extra security, but Keplr doesn't support this, so best is to use no password or without the -i or --interactive flag to prevent this.


JavaScript: Fix exported name of default re-exports.

A default re-export (not part of the standard yet) looks like this:
export f from 'mod';

What this means is that the default export of mod is re-exported under the name f.
Default re-export specifiers (like f in this example) are modelled as a kind of default export specifier in our library, but unlike normal default export specifiers they do not export the name default.
This was previously not modelled correctly, leading to surprising errors down the line, for example in type inference where we suddenly would no longer be able to resolve an import that otherwise looked resolvable.

I have verified that this eliminates the false positives on https://lgtm.com/projects/g/segmentio/evergreen, and does not affect performance on our default suite.


bug: 'ionic upload' adds "ZERO WIDTH NO-BREAK"

Type: bug
Platform: all
When doing 'ionic upload' while 'ionic serve' is running a "ZERO WIDTH NO-BREAK"-character (&#65279) is added at the top of index.html. This causes the view to be to high

I believe this would better fit in the Ionic CLI repo, no?
https://github.com/driftyco/ionic-cli/issues

This issue was moved to driftyco/ionic-cli#439

This issue was moved to driftyco/ionic-cli#440

Moved to the CLI repo

Greetings @tobbbe!
I've closed this issue because my sensors indicated it was old and inactive, and may have already been fixed in recent versions of Ionic. However, if you are still experiencing this issue, please feel free to reopen this issue by creating a new one, and include any examples and other necessary information, so that we can look into it further.
Thank you for allowing me to assist you.


Static assets doc on 2 pages

📚 Documentation
The static assets doc from there:
https://v2.docusaurus.io/docs/markdown-features#assets
Should probably be merged into:
https://v2.docusaurus.io/docs/static-assets/#jsx-example
(this is not a doc-only feature btw)
Anyone interested to do this merge and improve our doc?

Yes, I'll work on this :)

MDX feature page is getting quite big. We should split it and create a new category. We can move it out of Docs catogory also since now Pages also support MDX.

Creating a new MDX category should be noce for users searching reading docs.

Yes I agree, but we shouldn't use a page for that because the mdx features are version-dependant.
A new sidebar category would be nice. We need a clear distinction of what md features are general, and which ones are doc-related (docs have additional features around linking using .md file paths, relative linking advised so that linking still work once the docs are versioned etc...)

Yeah, making more categories help in organizing docs.

Section assets was moved to https://docusaurus.io/docs/markdown-features/assets in https://github.com/facebook/docusaurus/pull/3975.
Maybe this issue not actual anymore and could be closed.

We still have https://docusaurus.io/docs/static-assets and https://docusaurus.io/docs/markdown-features/assets. I don't think it's very problematic considering the logic behind them, but the issue is still valid.

Moving everything to markdown-features/assets probably doesn't make sense, considering assets can also be handled in React/pages.
We should probably move all markdown-related things out of https://docusaurus.io/docs/static-assets, and just link the 2 pages together


Select highest refresh rate for selected mode when none is specified.

Matches the highest refresh rate when none is specified.
Looking forward to your feedback, happy to improve / refactor.
:)

I refactored a little further to reduce nesting, and simplify as you suggested.

Changes applied.


Create Code Of Conduct

Description

Checklist

[x] No duplicated code
[x] No temporary code (console.log, commented code, dead code)
[x] Code self-documentated (code hints, unit test names)
[x] No sensitive information logged / sent
[x] Error management with proper message
[x] Unit tests 100% (new code, edited code, exhaustive)

Related Issue

Coverage remained the same at 100.0% when pulling 48d29f9cb39c7107cf426c77fcdc346e72fa0e62 on add-code-of-conduct-1 into 740244e6e3a7691e1c54d88f1935d64496b7e6bc on master.


Update to ConstraintLayout Compose 1.0.0 alpha04

Kind (Required)

Improvement

Overview (Required)

The title says everything

Links

🙋
This time for sure. XD

@akeybako
Thanks!! Assigned!!


Creation of Deployment Plugin

Problem Statement
All functionality regarding the deployment of services, containers, etc. shall be handled by a separate deployment plugin within the workflow modeler.
Currently, the QuantME plugin contains functionalities for the deployment of services. These shall be transferred into a new deployment plugin.
Setup Prerequisite

Setup workflow modeler
Setup OpenTOSCA: https://github.com/OpenTOSCA/opentosca-docker/blob/main/docs/tutorial-model-and-deploy.md

References
Quantum Workflows
Self-Contained WF Models
Tasks

[x] Create the deployment plugin
[x] Transfer all deployment functionalities from the QuantME plugin into the deployment plugin
[x] Enable the activation of the plugin via the Docker setup (#6)
[ ] Test the functionality utilizing the use case described in #7
[ ] Derive and implement suitable test cases based on this use case

alte Story Points 8


Duplicate ID's and issues with more than one battery

Hey!
I have 3 batteries on my system and because of this as your integration creates the battery sensors I get the following errors:-
2023-03-02 23:59:07.900 ERROR (MainThread) [homeassistant.components.sensor] Platform givenergy_local does not generate unique IDs. ID BI2221G078_battery_soc already exists - ignoring sensor.battery_charge 2023-03-02 23:59:07.906 ERROR (MainThread) [homeassistant.components.sensor] Platform givenergy_local does not generate unique IDs. ID BI2221G078_battery_num_cycles already exists - ignoring sensor.battery_cycles 2023-03-02 23:59:07.907 ERROR (MainThread) [homeassistant.components.sensor] Platform givenergy_local does not generate unique IDs. ID BI2221G078_v_battery_out already exists - ignoring sensor.battery_output_voltage 2023-03-02 23:59:07.933 ERROR (MainThread) [homeassistant.components.sensor] Platform givenergy_local does not generate unique IDs. ID BI2221G078_battery_soc already exists - ignoring sensor.battery_charge 2023-03-02 23:59:07.934 ERROR (MainThread) [homeassistant.components.sensor] Platform givenergy_local does not generate unique IDs. ID BI2221G078_battery_num_cycles already exists - ignoring sensor.battery_cycles 2023-03-02 23:59:07.934 ERROR (MainThread) [homeassistant.components.sensor] Platform givenergy_local does not generate unique IDs. ID BI2221G078_v_battery_out already exists - ignoring sensor.battery_output_voltage
This means that 2 of the three batteries are missing their cycle counts etc.  In my own basic sensors I have used a standard GUID as the unique_id value and it seems to work well.
Would it be possible to change your code so it generates a unique id for each sensor ?

Hi again, doing a bit of digging and it looks like for some reason the battery serial number is not iterating for the BatteryBasicSensor creation.  The behaviour I am seeing is that when my three batteries are added it will only create the basic sensors for the first battery.
Interestingly the batteryCellsVoltageSensor and remainingCapacitySensor that get created after DO take the serial number as a unique ID correctly and get created.
The end result is that we get the batteries but only one has all the sensors, the remaining have just the voltage and capacity as mentioned above.


Metal variant doesn't build by the manual

I try to follow this direction on Mac:
If you want to use other rendering back-ends, disable default features and apply one of the following feature flags: [...] amethyst_engine_metal
The following configuration doesn't build:
[dependencies.bracket-lib]
version = "~0.8.1"
default-features = false
features = ["amethyst_engine_metal"]

with an error:
   Compiling amethyst_animation v0.15.3
error[E0433]: failed to resolve: could not find `fmt` in `core`
  --> /Users/vic/.cargo/registry/src/github.com-1ecc6299db9ec823/amethyst-0.15.3/src/app.rs:44:10
   |
44 | #[derive(Derivative)]
   |          ^^^^^^^^^^ could not find `fmt` in `core`
   |
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0433]: failed to resolve: could not find `fmt` in `core`
   --> /Users/vic/.cargo/registry/src/github.com-1ecc6299db9ec823/amethyst-0.15.3/src/state.rs:366:10
    |
366 | #[derive(Derivative)]
    |          ^^^^^^^^^^ could not find `fmt` in `core`
    |
    = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0433]: failed to resolve: could not find `clone` in `core`
  --> /Users/vic/.cargo/registry/src/github.com-1ecc6299db9ec823/amethyst-0.15.3/src/state_event.rs:17:17
   |
17 | #[derive(Debug, Derivative, EventReader)]
   |                 ^^^^^^^^^^ could not find `clone` in `core`
   |
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 3 previous errors

The default configuration builds and runs, but b/c of #109 it's hardly usable.
The same happens with the git version.

I'm getting these errors compiling with Amethyst/Vulkan, also. Working on it now.

It appears to relate to this bug: https://github.com/amethyst/amethyst/issues/2478

They mention there's a workaround:

We have to import std::core::fmt manually to workaround bug.

I'm working on figuring out how to do that right now. :-)

Doing some serious digging, it looks like I broke things when I adopted version 0.15 (which switches back-end to Legion). I'll have to do quite a bit of reworking to get 0.15.x running; so I'll schedule that, and try to get it working with 0.14 once more as a band-aid.

I'm personally fine with Mac on the current rendering back-end (is it OpenGL?). The only reason I tried it is in hope that #109 will go away.

This is working for me on Windows and Linux (using Vulkan), so I believe the version pinning has done the job for now. Anyone want to check on a Mac for me? cargo run --example astar_mouse --no-default-features --features amethyst_engine_metal  should be the magic syntax.

I think this is working now. I've successfully built Amethyst on Windows and Linux, and it built on my Mac VM (but won't run due to the VM not doing Metal properly). So I'm closing this - but if it continues to cause issues, please re-open.


POF: static property improvements

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically master)?

[ ] Is your initial contribution a single, squashed commit?

For code changes:

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file?
[ ] If applicable, have you updated the NOTICE file?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Overview:
-Please read tests first. They should give an idea of the motivation of the change
-This is POF, some parts of the code might leave space for improvement, some are not yet implemented.
Pros of suggested solution:
-Fully backward-compatible, no change required in processors.
-All property types can be assigned to Property (string property) without loosing the validator.
-Values are still stored in string, so no change in overhead of getter
-Easily extendable with further validators,  properties
-Validators can provide data in any format for server-side validation, no duplication of data
Cons:
-Templates, templates, templates everywhere... Added some static asserts to help development with meaningful error messages.

Thanks for submitting this. I think there is definite overlap between work I previously had with MINIFICPP-479 (https://github.com/apache/nifi-minifi-cpp/compare/master...phrocker:MINIFICPP-479?expand=1) I collected commits from across computers and squashed them, but has the side effect that it does validation at flow file load time ( something we've desperately needed) -- giving us a much earlier failure. a bit different implementation -- and it informs c2 of java validators to be used.
what is the motivation of this PR beyond that work that we discussed offline? I think the same "pros" exist for both works. That work has been around since June -- so it's probably stale in its ideas, so I'll take a look at this at some point. Thanks again.


Targets without dependencies are never executed

inner() is never called on a target without any dependencies (e.g. libcore in bake).

Fixed by https://github.com/ticki/cake/commit/0376bb3b49d197633bc99a94a27b3f453e80278c.


quick corona test like in arogya setu

No description provided.

Can you please propose your workflow or algorithm for implementing this. Are you referring to Density Based Clustering Technique? Do you have any dataset to work on this?

If you have any more details do get in touch with me over slack


Trying to dispose mouse hook earlier to potentialy fix the lagging mo…

…use bug after selecting the color
Summary of the Pull Request
I suspect that mouse lag issue #5427 is happening due running all color copying stuff on the same thread as the mouse hook - if it takes longer for some reason (maybe telemetry?) it might cause reported scenario. Now I am removing hook immediately after the mouse is clicked.
Trying to fix #5427
PR Checklist

[x] Applies to #5427
[x] CLA signed. If not, go over here and sign the CLA
[ ] Tests added/passed
[ ] Requires documentation to be updated
[ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Info on Pull Request
Added some extra logging, removing mouse hook earlier
Validation Steps Performed
Manual testing, works OK (I didn't have the reported issue before)

Works for me, i've never experienced mouse lag however

lets see if someone in the bug can actual test


proposal: Go 2: spec: always permit comparisons against zero value of type

Go, effectively, has three-kinds of comparability:

incomparable, there is no == operator defined for a type (structs and arrays with incomparable fields).
0-comparable, there is an == operator but it can only test against the zero value (funcs, maps, and slices can be compared against nil). The spec treats these as incomparable types and notes the special case.
comparable, there is an == operator and it works for all values

When writing code with known types, this is not an issue. You know if there's an == operator and whether you can compare against all values or just the zero value.
When generating code (or, possibly in the future, writing generic code) over arbitrary types, this asymmetry is a bit more bothersome. You can't just classify types as comparable or incomparable, you need to handle the 0-comparable case as well even though it is so similar: https://play.golang.org/p/JOmxaVJoYtT
I propose collapsing incomparable and 0-comparable. Allow incomparable structs and arrays to be compared to their zero value. There would always be an == operator and it would always be safe to compare any value to zero. Care would still need to be taken to ensure comparability when using == between arbitrary values, but the simpler classification eases matters.
I believe this would be a 100% backwards-compatible change and perhaps even simplify the spec a bit (or at least not require too many changes).
The concerns would be go/types and reflect, but they both seem to lump what I call 0-comparability in with incomparability, but there, admittedly, could be subtler implications.
This is tangentially related to defining a universal zero value https://github.com/golang/go/issues/19642#issuecomment-361761475 in that similar arguments are involved and the two would compliment each other.

Does the zero value need to be static? Or it can be dynamic, as long as at run time, at the point of ==, the value is zero?
From https://play.golang.org/p/JOmxaVJoYtT,
	// var zero t
	// fmt.Println(a == zero)

it seems to suggest that the zero value does not have to be static (it is a variable). What if the value is not zero, then? Panic?

One side would need to be known to be zero statically. Having a universal zero like in the linked issue would be the easiest way to achieve that.

Let's look at time.Time.
There is a IsZero function that will show you if the time is empty or not. With your suggestion I think that there should be an interface for structs and only if the struct is implementing that interface it can be checked against zero. For example if you have:
t := time.Time{}
fmt.Println(t == zero)

It should be transferred to something like
t := time.Time{}
fmt.Println(t.IsZero())

A related issue is that you can't define a const which is a nil func/slice because you can't define const func/slices:
	const zero func() = nil // does not compile

So, as of now, the only way to write f == nil is f == nil, since variables aren't statically nil and you can't make a constant nil other than n-i-l.
I think generics will require Go to either add an isZero() generic built-in or a "universal zero" identifier.

I'm running into a scenario right now where this would be extremely useful. What is the current intention and/or best practice for this problem if zero builtin has not been implemented?

You can fake it with reflect. See #35966 for discussion of solutions.

@carlmjohnson the reflect option is very slow when it comes to structs :/

Yes, that's why I am pushing for #35966 to happen.

I posted this in the cmp.Or thread but I should probably note it here as well. You can write an is-zero predicate now using generics and unsafe by taking advantage of the property that Go zero values imply all bytes are zero:
func Zero[T any](v T) bool {
	bp := (*byte)(unsafe.Pointer(&v))
	sz := unsafe.Sizeof(v)
	for _, v := range unsafe.Slice(bp, sz) {
		if v != 0 {
			return false
		}
	}
	return true
}

You can write an is-zero predicate now using generics and unsafe by taking advantage of the property that Go zero values imply all bytes are zero

Note that there some subtleties here around padding and fields named _. See https://github.com/golang/go/issues/31450.

For comparable types, the compiler generates == functions. I had assumed that a single size-parameterized function would suffice to handle the is-zero case. At a minimum it looks like it would need to reuse == for comparables and generate is-zero functions for composite non-comparables containing float/complex. For the other non-comparables, the single function would suffice as long as padding/_ remains zero.

Fixed by acceptance of #61372


nixos/llama-cpp: init

Description of changes

Add a module for the llama-cpp WebUI.
For testing you can use this to build Mistral-7B-Instruct-v0.2 with q4_0 quantization from source:

[!WARNING]
The download is around ~30GB.  Evaluating this uses a lot of memory I do not recommend evaluating it unless you have at least 64GB system memory.

{
  stdenvNoCC,
  fetchgit,
  llama-cpp,
  python3,
}:
stdenvNoCC.mkDerivation rec {
  pname = "mistral-instruct-7b";
  version = "0.2";

  src = fetchgit {
    url = "https://huggingface.co/mistralai/Mistral-7B-Instruct-v${version}";
    rev = "b70aa86578567ba3301b21c8a27bea4e8f6d6d61";
    hash = "sha256-IAe/tHFB7yqFRF5aRojkNCD8TbKj8XQMt6eEyPmr4HU=";
    fetchLFS = true;
  };

  nativeBuildInputs = [
    llama-cpp
    python3
    python3.pkgs.numpy
    python3.pkgs.sentencepiece
    python3.pkgs.transformers
  ];

  buildPhase = ''
    mkdir $out
    python3 ${llama-cpp.src}/convert.py $src --outfile /build/ggml-model-f16.gguf --outtype f16
    llama-cpp-quantize /build/ggml-model-f16.gguf $out/ggml-model-q4_0.gguf q4_0
  '';

  dontInstall = true;
  dontFixup = true;
}

CC llama-cpp package maintainers: @dit7ya @elohmeier
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] 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/)
24.05 Release Notes (or backporting 23.05 and 23.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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thanks for the review @jian-lin!  I applied your feedback.

Thanks for the reviews @jian-lin! :)


get_names() and get_name() do not return the same value if num_of_output features is 1

Bug Request Description

get_names and get_name are two functions we use to get the feature name (corresponding to the
column names in the feature matrix).
If the number_output_features is 1 for a feature, they should return the same thing (a list with 1 item, that is the same as the get_name.
Related issue But not the same

Current Behavior
import featuretools as ft
es = ft.demo.load_mock_customer(return_entityset=True)
_, feature_defs = ft.dfs(entityset=es,
                                      target_entity="customers",
                                      agg_primitives=[],
                                      trans_primitives=["month"],
                                      max_depth=1)
print(feature_defs[1].get_name())
print(feature_defs[1].get_names())

Current Output
 'MONTH(join_date)'
['MONTH(join_date)[0]']

Expected Output
 'MONTH(join_date)'
['MONTH(join_date)']

I think Feature.get_feature_names already has this behavior
    def get_feature_names(self):
        n = self.number_output_features
        if n == 1:
            names = [self.get_name()]
        else:
            names = self.get_names()
        return names

@gsheni After some discussion, we are going to review the naming methods in more detail to address the issue you have highlighted as well as the issue in #792 before we implement a fix.
To summarize the current state: Calling Feature.get_name() will return the name of the main base feature, and Feature.get_feature_names() will return a list of all of feature output names - a single item list in the case of a single output feature or a multi item list in the case of a multi output feature.
If you call Feature.get_feature_names() on a single output feature, the single item in the list will have the same name as the main base feature. For multi-output features a numeric suffix will appended to the base feature name.
Currently Feature.get_names() and Feature.get_feature_names()` will return the same list for a multi output feature. There is a difference for single output features as you have pointed out in this issue. Going forward there is probably not a need for both of those methods to exist in the public API.
For now getting the base feature name through Feature.get_name() or getting a list of output names through Feature.get_feature_names() is the way to go, while we consider a better long term solution to clean this up.

Is there any reason we can't just remove Feature.get_names() completely and move the logic for setting Feature._names into Feature.get_feature_names()?
That would leave us with two public methods for getting feature names:

Feature.get_name() to get the single string name of the base feature (which will also be the name of the feature in the case of a single output feature)
Feature.get_feature_names() to get a list of all the new feature names that will be generated. For single output features, this will be a single item list, and for multi output features all the feature names will be in the list.


Please add Bongard-HOI and RelViT

Hi,
Thanks for making this learning list and indeed I learned a lot. Just want to share some of our recent work on visual reasoning and I hope they could help this community through your platform:
Bongard-HOI: Benchmarking Few-Shot Visual Reasoning for Human-Object Interactions (CVPR 2022, oral)
arxiv | code
In this work, we create a new dataset for few-shot visual reasoning with HOI concepts. It introduces great challenges to the state-of-the-art few-shot learners but seems straightforward for humans.
RelViT: Concept-guided Vision Transformer for Visual Relational Reasoning (ICLR 2022)
arxiv | code
In this work, we explore vision transformers for many visual relational reasoning tasks, including HICO and GQA. We further introduce concept-guided contrastive learning that helps these models master visual reasoning without massive pertaining or extra training data.

PR created https://github.com/floodsung/Deep-Reasoning-Papers/pull/5. PTAL, thanks!


BUG - Portal "Tasks" Not taking users to the Release Control "Task"

Description

When a user clicks on a "Task" from the Release control application, they are just taken back to the front page of the portal

Then after clicking you are taken to the front page:

Here is an image of what I get on the sidesheet when I press F12 and click on a Task:

Links from emails do work and take you to the right place:

Reproduce

Have a task from RC assigned to you -> Magnus I just gave you a task on the RC application -> click the task in the fusion portal -> observe results.
Expected behavior

You should be taken to the task you clicked on

yes :) - exacltly

still seems to be an issue, not sure i've jumped the gun if its not in test?

@idrisbo - still not working, same result as original issue

Looks good. :)
Is it possible that the task link takes the user to the release control application as well? A new tab is opened when you click the link, it would be useful if that also took them to the release control page as well as opening the task so they can see that Release control information is stored in the Release Control application. I think it would reduce confusion. If its a pain to do that then maybe we leave it as is for the moment and come back to it

Stunning :) - really cool! go for push :) have tested and works great


Dispatcher couples server and client

It seems that you need to register functions or services with the Dispatcher that are both used by the client and server. Because of this I'm not able to build the server and client code separately. I'd like to see the dispatcher decoupled from the server and client.
I don't have any idea what is a nice way to implement this. Could you give directions, than I can create a pull request with the changes.

I have no idea yet on how to properly decouple client code from server code when using Dispatcher. As a workaround, you can register function and service stubs on the client, since Dispatcher verifies only function / service names on client side.

I removed dependency on server handler implementations from client code at the cost of required manual registration of non-trivial request and response types on client side. See updated docs for DispatcherClient methods.
It is possible to remove manual registration of non-trivial request and response types on client side. But this requires API and transport protocol modifications.


Repository description points to wrong godoc

Description points to old repo: http://godoc.org/github.com/shwoodard/jsonapi
The badge correctly points to: http://godoc.org/github.com/google/jsonapi

@shwoodard will have to change the repo description as I cannot modify any repo settings.

Done


docs: fix typo

Description
Just a small typo
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@viceice could you please sign off the commit ?

Yes, sorry. Isn't possible via github UI 😕

@DandyDeveloper @peterzhuamazon @mprimeaux  I believe we can ignore CI failures here. Opinions?

@TheAlgo I believe that @smlx views any change to a chart, including documentation, as requiring a version increment. In lieu of the chart testing failure, so do the maintainers and related community of the chart testing logic.
As such, I suspect a patch bump is required.

@TheAlgo I believe that @smlx views any change to a chart, including documentation, as requiring a version increment. In lieu of the chart testing failure, so do the maintainers and related community of the chart testing logic. I'm of the same view.
As such, I suspect patch bump is required. This would also require an update to the related CHANGELOG.

Agree but shouldn't we relax the CI failures for README changes
@DandyDeveloper @smlx @mprimeaux @peterzhuamazon

Please see this conversation that we had on this very point.
The README is in scope as a change to the chart and thus subject to linting rules.
I don't believe this view has changed but you might want to check with @smlx on it.

I'm not a maintainer on this repo so feel free to ignore me, but IMO rapid releases are a feature and get the latest fixes to users ASAP. Could a maintainer push a patch bump on this branch to get CI green?

@viceice I resolved the conflicts for you, please remember you need to pull from main, change version number, and update changelog next time when you PR.
Thanks.


All component title and descriptions should be aligned

All component title and descriptions should be aligned
Description
All component title and descriptions should be aligned
Areas changed

npm packages changed:

[ ] responsibleai/causality
[ ] responsibleai/core-ui
[ ] responsibleai/counterfactuals
[ ] responsibleai/dataset-explorer
[ ] responsibleai/fairness
[ ] responsibleai/interpret
[ ] responsibleai/localization
[ ] responsibleai/mlchartlib
[x] responsibleai/model-assessment

Python packages changed:

[ ] erroranalysis
[ ] raiutils
[ ] raiwidgets
[ ] rai_core_flask
[ ] responsibleai

Tests

[ ] No new tests required.
[ ] New tests for the added feature are part of this PR.
[ ] I validated the changes manually.

Screenshots (if appropriate):
Aggregate Counterfactual effects, Individual feature importance & others

Individual counterfactual what-if & others

Treatment policy & others

Documentation:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Codecov Report

Merging #1346 (7e48c17) into main (386d716) will increase coverage by 13.71%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             main     #1346       +/-   ##
============================================
+ Coverage   86.28%   100.00%   +13.71%
============================================
  Files         100         8       -92
  Lines        4675        64     -4611
============================================
- Hits         4034        64     -3970
+ Misses        641         0      -641

Flag
Coverage Δ

unittests
100.00% <ø> (+13.71%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

erroranalysis/erroranalysis/_internal/__init__.py

responsibleai/responsibleai/exceptions.py

rai_core_flask/rai_core_flask/__init__.py

erroranalysis/erroranalysis/analyzer/__init__.py

responsibleai/responsibleai/_input_processing.py

responsibleai/responsibleai/__init__.py

.../responsibleai/modelanalysis/constants/__init__.py

...ranalysis/erroranalysis/_internal/matrix_filter.py

...tools/counterfactual/dashboard_schemas/__init__.py

raiwidgets/raiwidgets/fairness_dashboard.py

... and 82 more

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 386d716...7e48c17. Read the comment docs.

This totally made my day! It's so upsetting to see misaligned sections. Love it!!!

THIS ALSO MADE MY DAY OMG !!!! Yes thank you sooooo much!


Update podspec to 1.4.0

Could you tag a release 1.4.0 from stable with the Swift 4 changes and push it to the CocoaPods trunk? Thanks!

+1 need to get a updated pod spec from CocoaPods trunk

Agreed. It's confusing the readme says you can just pod 'Swifter', '1.4.0' but that won't work until it's in the specs repo (which is still at 1.3.3)

I've changed the readme back to say 1.3.3 for the time being. I don't currently have permission to update the Cocoapod.

Alternatively, wouldn't this work as intended in the meantime?
pod 'Swifter', :git => 'https://github.com/httpswift/Swifter.git', :branch => 'stable', :tag => '1.4.0'

Yeah, you could target either the stable branch or the 1.4.0 tag in your Podfile to pull the latest.


fix: remove size limit

Removing size limit check
Description

Verification Steps

Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has been created for changes required on the client side

@JameelB I'll create a jira to test it with rhsso client & testing. I think is it creating an issue with the listing service account.

@JameelB I'll create a jira to test it with rhsso client & testing. I think is it creating an issue with the listing service account.

I don't think it is related. The keycloak_service (massso) is using the GetClients method that returns the max allowed number of clients when max is 0: https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/blob/398f0d1a50be9b58f83c4740064c5799f3a921ff/pkg/services/sso/keycloak_service.go#L228
Doc: https://pkg.go.dev/github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pkg/client/keycloak#KcClient.GetClients
The fix is correct but, IMO, should be put here: https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/blob/3693437afa71e729154a76fd4fa26f28592b4a36/pkg/client/redhatsso/client.go#L147 to have in redhatsso the same behaviour we had previously with massso.


Add support for oid types

This PR closes #88.
Added support for oid types.

https://www.postgresql.org/docs/11/datatype-oid.html

Ran deno fmt against decode.ts and tests/data_types.ts.

https://travis-ci.com/buildondata/deno-postgres/builds/151413237
Oh, deno fmt --check fails...
Should I fix this problem in this PR?

Yikes, Deno is very outdated and now uses a new formatter. I've opened a PR to bump version: https://github.com/buildondata/deno-postgres/pull/90

Thanks @bartlomieju!
I'll rebase this on master.

Released in v0.3.7
https://github.com/buildondata/deno-postgres/releases/tag/v0.3.7

@bartlomieju Thanks!


A database of words with diacritics

Entering “facade” should give “façade”.
Like #65, but for words.

Have some words, need to add more (look at words.rules).


Save url params in state

[11:21:33] <yoshuawuyts> uehhh

This is the simplest way to make this work, but it mutates the state right before rendering. I'm not 💯 sure this is safe, but all other solutions I've thought of required breaking changes and rearranging a number of things.
I'm mostly just seeing if the tests pass on this b/c I can't get them to run on my local machine.

Oh, figured out that barracks v9.2.1 was causing the failures. With v9.2.0 at least the tests pass locally but I still don't feel so hot about this. Any better ideas are welcome!

yeah this is pretty gnarly b/c of the mutation stuff - feel like it could cause some races. Should def think of a better way to handle this hmmm - if anything we're overhauling tests slightly as per #test, we should think of testing this behavior hey

I'll go ahead and close this then.


migrate BuildJSONController fixes #928

[x] I have run rspec and corrected all errors
[x] I have run rubocop and corrected all errors
[x] I have tested this change locally and tried to launch the server as well as access a project, and with that at least one build
[x] If there is an existing issue, make sure to add Fixes ... as part of the PR body to reference the issue you're solving

Fixes #928

Gonna go ahead and submit this 👍


Add Azion as an extension publisher

It is currently published in my name.

Draft that solves this https://github.com/aziontech/azion-edge-functions-vscode-extension/pull/6


Add appveyor.yml config file

This is a redo of #298

I will close this if appveyor doesn't get triggered

LGTM, but let's wait to be able to actually enable AppVeyor.

@ariporad yup. I think this shouldn't be merged until appveyor is set up properly and it actually runs on the PR (so we might have to reopen another PR after that and close this one).

You can always rebase this change on the latest from master then force push the branch. That will re-trigger AppVeyor just fine without need to close/re-open this PR. If the branch is up to date with the latest from master you can amend this commit (change the commit message) and force push which will also re-trigger things in AppVeyor. Once the Webhook stuff is triggered that is.

Yeah, that's one way. I also wanted to verify that it works on PRs as well. But since the config file is most likely good as it is, we can probably just merge once the appveyor settings and webhooks are straightened out.

@nfischer: I think we might want to get our tests passing on windows before this gets merged. But it did work!

@ariporad sounds good to me

@ariporad You say it worked, but I don't see an AppVeyor status check on this PR for AppVeyor.

@mtscout6 appveyor should now be running on this PR (I updated an equivalent PR, but forgot to do this one)

Perfect! Glad to see it working!

Yup! And it looks similar to the output @BYK got when running the tests, which is a good sign

@ariporad I'd advocate merging this now instead of waiting for tests to pass. That way the you can see that the tests do fix the tests in the PRs that are fixing them. It's not a "Required" check for merging, though once it goes green then you can make it a required check if you like. That's my opinion though.

@mtscout6: hmm... Ok. That makes sense. @nfischer: FFTM (Feel Free To Merge).

LGTM


websockets connection errror

I tried the historical tick data example but keep getting an error saying
"websockets.exceptions.ConnectionClosedError: no close frame received or sent" - what is the problem here?
Regards,
Jan

Hey, can you send me the code you are trying to run, plus could you do a pip freeze from your python env so I can see what packages you have installed? For Protobuf with Rithmic you have to use an old version: protobuf==3.20.3


Better naming of package path specifier:s

When importing a package the user does so with a path that starts with a specifier (terminology which is borrowed from the Deno JS runtime). Here are a few examples:

A local package relative to the assets dir foo/bar.wasm or foo/bar
A package on the web https:/some.website/package.wasm
A package found in the registry (which we currently call "pkgs", analogous to npm or ctan) pkgs:bar
A package that is baked into the compiler `std:latex

It is worth discussing if the name of the registry pkgs should be changed into something else to make it clear that this is just the name of the registry and not just the way to import packages. Possible alternatives would be reg: or registry or rename the registry into something less confusing.
We might also want to discuss if "std" should be called something else or if we want to introduce a prelude: specifier.

We opted to use catalog: instead!


[WIP] adding gz to demux validation

Not sure how I messed the files here so closing and opening: https://github.com/qiita-spots/qtp-target-gene/pull/28


dhw_energy_yesterday and ch_energy_yesterday is 0

Hi,
I'm trying to resolve the problem with my energy consumption statistics for my Ariston Genus One Boiler. Since the update, all the sensors regarding energy consumption (heating and hot water) indicate 0 (e.g. ch_energy_yesterday, ch_energy_today, dhw_energy_today etc).
It did work with the previous build.
Any idea why that is?

Same here. v 2.0.5 upwards . Returning to lower version fixes all values (year, month, day), both DHW and CH
Alteas One Net 24.

It worked for 2.0.4 as the last working?

It worked for 1.0.52 version. Sorry for not being clear.

confirm, on earlier version it worked fine.

Actually, for me, 2.0.5 still has the relevant data.

for me it's not working in 2.0.5- Nimbus Flex Heat Pump

All 1.0.x versions are obsolete and incompatible due to changes from Ariston server side, most things are rewritten from the scratch, so I care only about version 2. Version 1 will never work again.
There is no documentation, it is all guessing what data means what.
Did you compare values with Android/IOs application with data in sensors for day range? I mean comparing values towards hours each value.
You may also add following after self._energy_use_data = copy.deepcopy(resp.json()). Make sure you use spaces and not tabs:
self._LOGGER.warn(f'{self._energy_use_data}')
As result you should see in logs warning with values similar to:
[{"k":7,"p":1,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":7,"p":2,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":7,"p":3,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":7,"p":4,"v":[0.0,0.0,0.0,0.0,0.0,33.444,0.0,6.294,149.963,547.13,777.894,461.645,1014.125,840.43,0.0,720.102,214.919,0.0]},{"k":20,"p":1,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":20,"p":2,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":20,"p":3,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":20,"p":4,"v":[0.0,0.0,0.0,0.0,0.0,0.491,0.0,0.038,2.166,7.838,10.53,5.931,14.633,12.202,0.0,9.219,2.694,0.0]},{"k":10,"p":1,"v":[0.0,1.858,0.0,0.0,0.0,0.0,0.0,2.45,0.0,0.0,1.802,0.0,0.0,3.577,0.0,0.0,0.0,0.0,1.825,0.0,1.763,0.0,0.0,1.191]},{"k":10,"p":2,"v":[5.844,9.391,7.677,8.311,6.016,8.161,7.83]},{"k":10,"p":3,"v":[6.488,10.269,7.372,8.733,7.527,8.194,6.505,7.991,5.697,7.4,9.622,8.3,7.841,12.788,6.158,5.569,3.069,4.986,12.644,5.652,11.5,7.722,8.705,7.894,7.713,5.355,7.638,6.802,9.016,7.991,10.702,11.347,5.43,5.28,7.105,5.986,5.55,7.244,12.2,7.825,5.844,9.391,7.677,8.311,6.016,8.161,7.83]},{"k":10,"p":4,"v":[0.0,0.0,0.0,0.0,0.0,235.675,231.927,281.088,110.236,236.219,282.322,112.271,326.758,291.052,0.0,256.005,294.913,233.155]},{"k":21,"p":1,"v":[0.0,0.011,0.0,0.0,0.0,0.0,0.0,0.011,0.0,0.0,0.011,0.0,0.0,0.019,0.0,0.0,0.0,0.0,0.011,0.0,0.011,0.0,0.0,0.005]},{"k":21,"p":2,"v":[0.036,0.052,0.047,0.047,0.036,0.047,0.041]},{"k":21,"p":3,"v":[0.036,0.05,0.044,0.047,0.041,0.047,0.036,0.047,0.033,0.044,0.052,0.044,0.047,0.066,0.036,0.033,0.019,0.027,0.069,0.033,0.061,0.044,0.047,0.047,0.044,0.03,0.044,0.038,0.05,0.044,0.058,0.063,0.03,0.033,0.041,0.033,0.036,0.041,0.066,0.047,0.036,0.052,0.047,0.047,0.036,0.047,0.041]},{"k":21,"p":4,"v":[0.0,0.0,0.0,0.0,0.0,1.372,1.361,1.641,0.627,1.33,1.544,0.606,1.75,1.552,0.0,1.383,1.597,1.311]},{"k":1,"p":1,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":1,"p":2,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":1,"p":3,"v":[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]},{"k":1,"p":4,"v":[0.0,0.0,0.0,0.0,0.0,33.935,0.0,6.332,152.129,554.968,788.424,467.576,1028.758,852.632,0.0,729.321,217.613,0.0]},{"k":2,"p":1,"v":[0.0,1.869,0.0,0.0,0.0,0.0,0.0,2.461,0.0,0.0,1.813,0.0,0.0,3.596,0.0,0.0,0.0,0.0,1.836,0.0,1.774,0.0,0.0,1.196]},{"k":2,"p":2,"v":[5.880,9.443,7.724,8.358,6.052,8.208,7.871]},{"k":2,"p":3,"v":[6.524,10.319,7.416,8.780,7.568,8.241,6.541,8.038,5.730,7.444,9.674,8.344,7.888,12.854,6.194,5.602,3.088,5.013,12.713,5.685,11.561,7.766,8.752,7.941,7.757,5.385,7.682,6.840,9.066,8.035,10.760,11.410,5.46,5.313,7.146,6.019,5.586,7.285,12.266,7.872,5.880,9.443,7.724,8.358,6.052,8.208,7.871]},{"k":2,"p":4,"v":[0.0,0.0,0.0,0.0,0.0,237.047,233.288,282.729,110.863,237.549,283.866,112.877,328.508,292.604,0.0,257.388,296.510,234.466]}]
That is how server returns the data and somehow correct values must be fetched

I did check the values on my Android app for hourly and daily energy consumption and there all different from 0.
Regarding the "add following after self._energy_use_data = copy.deepcopy(resp.json())", I'm afraid you lost me here. I don't understand what I'm suppose to do here.

Add that string in ariston.py and restart HA

This is what I get in the Logs:
[{'k': 1, 'p': 1, 'v': [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]}, {'k': 1, 'p': 2, 'v': [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]}, {'k': 1, 'p': 3, 'v': [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]}, {'k': 1, 'p': 4, 'v': [0.0, 0.0, 50.722, 705.219, 1099.355, 1454.375, 1470.33, 1095.163, 1132.33, 824.944, 58.458, 0.0]}, {'k': 2, 'p': 1, 'v': [0.047, 0.244, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.286, 0.516, 0.0]}, {'k': 2, 'p': 2, 'v': [2.608, 2.625, 15.527, 5.194, 0.613, 7.483, 1.441]}, {'k': 2, 'p': 3, 'v': [9.616, 11.338, 15.291, 11.63, 3.688, 10.508, 4.469, 5.619, 7.672, 18.794, 6.38, 3.708, 18.152, 5.808, 8.925]}, {'k': 2, 'p': 4, 'v': [173.38, 177.033, 211.841, 234.516, 191.947, 223.172, 227.475, 221.338, 229.136, 182.447, 209.616, 169.911]}]

My logs:
[{'k': 1, 'p': 1, 'v': [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]}, {'k': 1, 'p': 2, 'v': [0.0, 0.0, 0.0, 0.0, 0.005, 0.0, 0.0]}, {'k': 1, 'p': 3, 'v': [0.063, 0.0, 9.152, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.919, 0.0, 0.0, 0.005, 0.0]}, {'k': 1, 'p': 4, 'v': [0.0, 0.0, 126.175, 838.266, 1041.069, 1588.061, 1825.933, 1291.577, 1125.186, 671.283, 13.3, 9.222]}, {'k': 2, 'p': 1, 'v': [0.963, 0.319, 0.797, 0.991, 1.194, 0.061, 0.058, 0.055, 0.055, 0.08, 0.327, 0.952]}, {'k': 2, 'p': 2, 'v': [3.169, 1.713, 2.511, 4.458, 2.888, 2.769, 6.313]}, {'k': 2, 'p': 3, 'v': [5.536, 4.441, 8.416, 2.016, 5.913, 9.033, 4.038, 6.455, 6.608, 11.572, 7.705, 5.605, 4.225, 7.347, 9.083]}, {'k': 2, 'p': 4, 'v': [138.355, 102.058, 152.713, 283.841, 289.527, 349.95, 341.502, 246.236, 271.713, 266.23, 119.33, 106.552]}]

On Genus One (that one guy gave me temporary access to as my boiler has no valid energy use) I was able to map "k": 7 and "K": 10 as CH and DHW energy use by mapping values from Andoid application to values. "k": 1 and "k": 2 provided slightly different values.
In your cases I see only "k": 1 and "k": 2. I guess I'll add 2nd set of data.
You may try changing values in ariston.py to see if valid values are returned and match the data:
CH_ENERGY = 1
DHW_ENERGY = 2

Yup. That works.

CH_ENERGY = 1
DHW_ENERGY = 2

... maybe, when you have time and means, you can find a workaround for the missing "hvac_modes", too.
I know it's another issue, but ...

.

Is it popup window when changing from winter to summer or off? If so, I saw it and it seems that beside popup it does work. It is some issue in HA when climate is unavailable.

On Genus One (that one guy gave me temporary access to as my boiler has no valid energy use) I was able to map "k": 7 and "K": 10 as CH and DHW energy use by mapping values from Andoid application to values. "k": 1 and "k": 2 provided slightly different values. In your cases I see only "k": 1 and "k": 2. I guess I'll add 2nd set of data. You may try changing values in ariston.py to see if valid values are returned and match the data: CH_ENERGY = 1 DHW_ENERGY = 2

It works. Thank you for the quick help.

Is it popup window when changing from winter to summer or off? If so, I saw it and it seems that beside popup it does work. It is some issue in HA when climate is unavailable.

Not so much the card popup, but the missing attribute for climate entity.  It used to be 'off', auto and heat. Now it's only Heat

There were many changes done to climate entity and I have no idea what is the issue in your case. Separate issues should be handled in separate threads.
I did remove "off" option as if you open information on climate entity it provides option to change presets and there is OFF option. The reason is that handling hvac_mode off meant handling of value ON, but which one should it be? As it can be winter, could be summer, could be cooling? On top of that the names reported by the server are not known by me to compare with. In old version I made additional configuration parameters for it, but it just complicated maintenance of code for me.
Auto function should be added automatically if ch_mode reports "Time program" as one of valid options. You may check attributes of ch_mode sensor.

use 2.0.10 and in configuration.yaml update sensor names (it is mainly change from "energy" to "energy2" from README.md)

There were many changes done to climate entity and I have no idea what is the issue in your case. Separate issues should be handled in separate threads.
I did remove "off" option as if you open information on climate entity it provides option to change presets and there is OFF option. The reason is that handling hvac_mode off meant handling of value ON, but which one should it be? As it can be winter, could be summer, could be cooling? On top of that the names reported by the server are not known by me to compare with. In old version I made additional configuration parameters for it, but it just complicated maintenance of code for me.
Auto function should be added automatically if ch_mode reports "Time program" as one of valid options. You may check attributes of ch_mode sensor.

OK. I'll let you know if I notice anything relevant. Thanks


Fix BaseButton's localization for tooltip text with shortcut

Fix #56100

I believe this will need a different fix for 3.x, since atr() isn't present there IIRC.


Support Cinder availability zones

I'm trying to deploy an HDP cluster on Openstack with attached cinder volumes but volumes creation fails due to my openstack infrastructure using Cinder availability zones with no default setting.
The heat template that is generated by Cloudbreak does not include the availability zone for the volumes so it defaults to 'nova' which does not exist in my setup and the volumes creation fails.
The UI should propose the AZ for the volumes or default to the AZ for the instances to avoid uneven storage allocation.
It seems to me that the latest solution would as simple as modifying the heat template such as
  ambari_volume_${agent.instanceId}_${volume_index}:
    type: OS::Cinder::Volume
    properties:
      name: hdfs-volume
      size: ${volume.size}
+      <#if availability_zone?has_content>
+     availability_zone : ${availability_zone}

Hi @rmanus
If you have a working solution we are open for contribution. Please feel free to open a PR.
Thanks

I tried to work on solution on my spare time but I've been unable recompile and test my changes that's the reason why I raised this issue.


Update Exploration Mode Banner State

#533 introduced the mode state of the project. This PR updates the exploration mode banner state by this newly added state. It also prettifies the code files and elates lint in #533.

Thanks 🙏


Tools 144 check primary portion field in proc matrix file

Added checks for ProcessedMatrixFile's ['primary_portion'], specifically whether 'obs_value' is an actual obs column, and that the 'values' are all present within that column.

Looks good to me! Ready to merge to main!