pretty printing regression

I'm seeing a pretty printing regression in 0.6 from 0.5; looks to be in nested arrays and structs?
E.g., seeing this in diffs now:
+                ),            ],
+        )),    ],

I believe a newline is missing after the ),, since adding a newline after yields the expected pretty printed string:
                ),
            ],
        )),
    ],

@Plecra could be related to #206 ?

Probably, yup. Someone will need to check the diff for a logic error in the tuple generator, and add a test for it.

@m4b, would you be able to provide a minimal reproduction please? I wasn't able to get it to misbehave locally.

Sure, this repro's for me:
(
    name: "foo",
    stuff: [
        Group(
            (
                name: "baz",
                group: "baz_group",
                instances: [
                    (
                        name: Some("2-2"),
                    ),
                ],
            ),
        ),
    ],
)

Repro code, if you save above as file, read it, then write it out, it should have the issue:
use serde::{Deserialize, Serialize};

use std::io::{Read, Write};

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct Foo {
    pub name: Option<String>,
}

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct StuffInner {
    pub name: String,
    pub group: String,
    pub instances: Vec<Foo>,
}

#[derive(Debug, Serialize, Deserialize, Clone)]
pub enum Stuff {
    Group(StuffInner),
}

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct Top {
    name: String,
    stuff: Vec<Stuff>,
}

fn main() {
    let args: Vec<String> = std::env::args().collect();
    let mut f = std::fs::File::open(&args[1]).unwrap();
    let r: Top = ron::de::from_reader(f).unwrap();
    let pretty = ron::ser::PrettyConfig::default();
    let ron = ron::ser::to_string_pretty(&r, pretty).unwrap();
    let mut f = std::fs::File::create(&format!("fmt.{}", &args[1])).unwrap();
    f.write_all(ron.as_bytes()).unwrap();
}

@Plecra you’re able to repro with above right ?

Nope, I actually can't. This test passes on master, just as it does on cea5d78e51392f911d7e5453483821b73f111a46. I'm not sure what code could've originally generated your .ron data, and I'm not seeing any problem with newlines either.
use ron::ser::{to_string_pretty, PrettyConfig};

#[test]
fn small_array() {
    use serde::{Deserialize, Serialize};

    use std::io::{Read, Write};

    #[derive(Debug, Serialize, Deserialize, Clone)]
    pub struct Foo {
        pub name: Option<String>,
    }

    #[derive(Debug, Serialize, Deserialize, Clone)]
    pub struct StuffInner {
        pub name: String,
        pub group: String,
        pub instances: Vec<Foo>,
    }

    #[derive(Debug, Serialize, Deserialize, Clone)]
    pub enum Stuff {
        Group(StuffInner),
    }

    #[derive(Debug, Serialize, Deserialize, Clone)]
    pub struct Top {
        name: String,
        stuff: Vec<Stuff>,
    }
    assert_eq!(
        to_string_pretty(&Top {
            name: "foo".into(),
            stuff: vec![
                Stuff::Group(StuffInner {
                    name: "baz".into(),
                    group: "baz_group".into(),
                    instances: vec![
                        Foo {
                            name: Some("2-2".into())
                        }
                    ]
                })
            ]
        }, PrettyConfig::new().with_new_line("\n".to_string())
    ).unwrap(),
        r#"(
    name: "foo",
    stuff: [
        Group((
            name: "baz",
            group: "baz_group",
            instances: [
                (
                    name: Some("2-2"),
                ),
            ],
        )),
    ],
)"#);
}

Ah, that makes sense! We need another PR with the same changes but against our v0.6 branch. A separate commit would need to be added to bump the patch version and add a short changelog entry.


Get Color to Behave on the Map

Addresses #102

The flat coloring on the map is now differentiated per county based on the bins.
The map color legend shows a color gradient instead of various grays

First, the number of bins was wrong in the code. The code had 4 bins when the data has 5. The bins are defined in metaData.json and look like: [0.048,0.08,0.103,0.126,0.154,0.195] where the first and last values are the minimum and maximum values of the set and the other values are the boundaries between the bins.
Second, we were passing hardcoded bin boundary values to extractCountyAndMetricDictionary() instead of the dynamic values from the data.
Third, the map legend was showing the Error color (gray) when the color lookup failed, but the map itself was showing Default color (green) in that case.
There is still a bug in here that the color gets stuck/stale if the color is changed by selecting a different metric/feature. I'm not sure what's causing that but I can dig in after this change is merged in.

This pull request relies on #103


en-us Update key-vault-certs.md

Remove the en-us from the link addresses. I've marked the spots in the article with *****

@marieparker1 - Thanks for the suggestion. I've double-checked the source code, and it shows no en-us in the links. Browsers automatically add en-us when you open the live page from an English-language location.

I'll close this PR, but if you think the PR needs another look, you can at-mention me in a comment.

Thank you, Shannon — did I mention the two images in this article didn't have mouseover text/descriptions?
Marie Parker (She/Her)
Senior Tech Support Engineer
Azure Networking
Customer Service & Support
•<PHONE_NUMBER>
•<EMAIL_ADDRESS>•    8:00am-7:00pm Sunday -- US Central Time
9:00am-8:00pm Monday-Wednesday -- US Central Time
Need help outside of my working hours?
Locating an Engineer<EMAIL_ADDRESS>Managerial Assistance<EMAIL_ADDRESS>Team Manager | Laura Holzwarth<EMAIL_ADDRESS>To maintain the highest level of security for your important data, please do not add any screenshots, attachments, or other forms of data that may contain PII (Personally Identifiable Information) to email correspondence with Azure Support. Instead, please upload them to the secure DtM portal for the support request. If you need the link to the portal, please let me know, and I will provide it to you.

From: Shannon Leavitt @.>
Sent: Monday, September 2, 2024 4:45 PM
To: MicrosoftDocs/azure-docs @.>
Cc: Marie Parker @.>; Mention @.>
Subject: Re: [MicrosoftDocs/azure-docs] en-us Update key-vault-certs.md (PR #124309)
@marieparker1https://github.com/marieparker1 - Thanks for the suggestion. I've double-checked the source code, and it shows no en-us in the links. Browsers automatically add en-us when you open the live page from an English-language location.
image.png (view on web)https://github.com/user-attachments/assets/0732a433-4842-4805-95ef-af4dc096e3a0
I'll close this PR, but if you think the PR needs another look, you can at-mention me in a comment.
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/pull/124309#issuecomment-2325323882, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDHBY4ENFG556A2U7VMYTMLZUTL6FAVCNFSM6AAAAABNPIQITSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRVGMZDGOBYGI.
You are receiving this because you were mentioned.Message ID: @.***>


Add badges

@Saumya-Sunder , can you please add the badges here to the top README?

Fixed with https://github.com/Seagate/cortx-multisite/pull/16


Modified create_trainer function to allow the arguments take precedence

Fixes issue #676
I have modified the create_trainer() function in the main.py file to allow the arguments specified by the user to take precedence over the config values. I have created a dictionary trainer_args which contains all the parameters required for the pl.Trainer initialization and then updated it with the values from the kwargs.

Good job, thanks for getting this done. @henrykironde have a look sometime at the conda failure, nothing to do with this PR. Thanks @Om-Doiphode, I will merge and we can bump version.

@Om-Doiphode thank you for this PR.


Generalize running_in_container function

This change allows jobs to run correctly in garden-runc containers
as well as in the previously supported garden-linux and docker containers.

@ematpl Can you explain a bit more what is going on here?  This is the first time I've seen this code so I'm not sure of the best way to test that it is working properly.

What did it used to do, and what is it doing now?
What could be affected by this change, and how could I test that those things still function correctly?

Thanks for your help.  Please feel free to stop by in person to demonstrate if it's easier than replying in a comment.

Thanks @ChunyiLyu and @jaresty ! Please let me know if you need any more information about the changes in this PR.

@ematpl No worries! Jesse filled in the information about this PR. Our bosh-lite successfully deployed and CATs had passed as well. It all looks good :)

Awesome, thanks!


Issue getting messages

I can get messages normally using session.messages(limit=#, offset=#), up to a certain amount, but once i request a decent number at once (say, 30) it gives me {'code': 'BadRequest', 'message': ''}
it appears I can get exactly 40 messages at a time, I do not know if this is intentional or not but can't find anywhere that it says if it is.
Edit: temporarily solved by importing messages in batches, but this slows down the program significantly

the Scratch API doesn't allow getting more than 40 messages at once. (The same limit applies to getting studies, projects. followers etc.).
I can get messages normally using session.messages(limit=#, offset=#), up to a certain amount, but once i request a decent number at once (say, 30) it gives me {'code': 'BadRequest', 'message': ''}
it appears I can get exactly 40 messages at a time, I do not know if this is intentional or not but can't find anywhere that it says if it is.
Edit: temporarily solved by importing messages in batches, but this slows down the program significantly
That's the only way to get more than 40 messages


Adds feature picking to ModelExperimental

This PR adds support for picking features within a ModelExperimental. Features are picked using the _FEATURE_ID vertex attribute or using featureIdTextures - both of which are part of the EXT_feature_metadata glTF extension.
This PR also adds a ModelFeature and ModelFeatureTable class - since we can't always rely on the Cesium3DTileContent classes to handle the feature picking and CPU styling anymore when feature metadata is embedded in isolated glTF models.
Currently, only the first feature table and the first feature ID texture are processed.

Here is a local Sandcastle for testing.
3D Tiles Picking Sandcastle
Instanced 3D Tiles Picking Sandcastle - pick the trees

Thanks for the pull request @sanjeetsuhag!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

@ptrgags Your feedback has been addressed.

Unrelated to this PR, but why are the trees so dark? Changing the timeline doesn't help.

Model Picking Sandcastle -- Trying microcosm, for some reason I only ever get the values of Grassland or Unused. Though there should be more variation in values in the texture:

I can help investigate this tomorrow.

Wrote up https://github.com/CesiumGS/cesium/issues/9813 to track the testing improvements needed.

@ptrgags Regarding microcosm, the properties in the feature table are available for the following feature IDs:

Feature ID
Name

0
Grassland

32
Rocky Ground

128
River

208
Forest

255
Building

Everything else is "Unused".
I applied the following custom fragment shader to the model:
void fragmentMain(FragmentInput fsInput, inout czm_modelMaterial material){
      float featureId = texture2D(FEATURE_ID_TEXTURE, FEATURE_ID_TEXCOORD).FEATURE_ID_CHANNEL;
      if (featureId == 0.0) {
          material.diffuse = vec3(0.0, 0.5, 0.0);
      } else if (featureId == 32.0) {
          material.diffuse = vec3(0.5, 0.5, 0.5);
      } else if (featureId == 128.0) {
          material.diffuse = vec3(0.0, 0.0, 1.0);
      } else if (featureId == 208.0) {
          material.diffuse = vec3(0.0, 1.0, 0.0);
      } else if (featureId == 255.0) {
          material.diffuse = vec3(1.0, 1.0, 0.0);
      } else {
          material.diffuse = vec3(0.0);
      }
  }

And I can see that only the Grassland shows up:

Here is a local Sandcastle using the custom shader.

@ptrgags Addressed your feedback.

This looks good to me. @lilleyse do you have any last comments before I merge?

@ptrgags I pulled in the changes from https://github.com/CesiumGS/cesium/pull/9806, updated the tests to use ShaderBuilderTester.

@lilleyse This is ready for you to review. I'll set the base branch back to main once #9806 is merged.

By the way, does this PR make fsInput.attributes.featureId_0 etc accessible to custom shaders?

By the way, does this PR make fsInput.attributes.featureId_0 etc accessible to custom shaders?

Custom shader support will be added in a later PR, not within scope of this one.

Custom shader support will be added in a later PR, not within scope of this one.

Could you open an issue for being able to access the feature id in custom shaders (whether it's from attribute or texture)?

This PR looks good to me. @ptrgags ready for your final review.

When enableModelExperimental is ture,  .b3dm feature  can not be picked？
Cesium.ExperimentalFeatures.enableModelExperimental = true;

@XYCaptain At the moment, picking is only supported with tilesets that use the glTF files as content. We do plan on adding back support for picking 3D Tiles 1.0 formats.


Unify sbt shell and build.sbt syntax (unified slash syntax redux)

Fixes sbt/sbt#1812
This adds unified slash syntax for both sbt shell and the build.sbt DSL.
Slash syntax in shell
Instead of the current <project-id>/config:intask::key, this adds <project-id>/<config-ident>/intask/key where <config-ident> is the Scala identifier notation for the configurations like Compile and Test. (The old shell syntax will continue to function)
Slash syntax in build.sbt
This also adds a series of implicits called SlashSyntax that adds / operators to project references, configuration, and keys such that the same syntax works in build.sbt.
Examples
These examples work both from the shell and in build.sbt.
Global / cancelable
ThisBuild / scalaVersion
Test / test
root / Compile / compile / scalacOptions
ProjectRef(uri("file:/xxx/helloworld/"),"root")/Compile/scalacOptions
Zero / Zero / name

The inspect command now outputs something that can be copy-pasted:
> inspect compile
[info] Task: sbt.inc.Analysis
[info] Description:
[info] 	Compiles sources.
[info] Provided by:
[info] 	ProjectRef(uri("file:/xxx/helloworld/"),"root")/Compile/compile
[info] Defined at:
[info] 	(sbt.Defaults) Defaults.scala:326
[info] Dependencies:
[info] 	Compile/manipulateBytecode
[info] 	Compile/incCompileSetup
[info] Reverse dependencies:
[info] 	Compile/printWarnings
[info] 	Compile/products
[info] 	Compile/discoveredSbtPlugins
[info] 	Compile/discoveredMainClasses
[info] Delegates:
[info] 	Compile/compile
[info] 	compile
[info] 	ThisBuild/Compile/compile
[info] 	ThisBuild/compile
[info] 	Zero/Compile/compile
[info] 	Global/compile
[info] Related:
[info] 	Test/compile

Two questions:

What's missing on this front for this to be merged?
Is there any chance this can make it into the next sbt release?

I need to add mima exclusion, I think to pass Travis.
I am hoping it will be in sbt 1.1.0, 1.2.0 or some feature release. Immediately next one will be sbt 1.0.2 (hotfix release).

I've added this to the 1.1.0 milestone as it would be a good highlight feature of sbt 1.1.

To validate this pull request against other sbt modules, please visit this link.

To validate this pull request against other sbt modules, please visit this link.

Rebased to the latest 1.x branch, and added Mima exclusion.

To validate this pull request against other sbt modules, please visit this link.

To validate this pull request against other sbt modules, please visit this link.

To validate this pull request against other sbt modules, please visit this link.

Could you squash the commits?

To validate this pull request against other sbt modules, please visit this link.

@jvican @dwijnand Thanks guys for the review.

To validate this pull request against other sbt modules, please visit this link.

To validate this pull request against other sbt modules, please visit this link.

To validate this pull request against other sbt modules, please visit this link.

To validate this pull request against other sbt modules, please visit this link.


Select product feed image by position

When determining which image to link in the product feed, select the
first image as ordered by the position attribute. This is a
re-implementation of a previous fix that was lost during the transition
to custom feeds.

ch7317

Building a PR on engine_storefront for review app testing.

I had to remove the Variant decorator as it caused test failures in engine_storefront. Weird but true.


reaction is very slow

Hy
I would like to say thank you for this great work.
I use this adapter since a long time and it work great.
But there is one problem:
The objects refresh really slow
When I press the volume control button on my controler, it will be take 1-2seconds, before the data object in the iobroker backend, will be update.
I set the intervall to 500ms in the adapter settings, but it didn't help.
Any ideas?
Thank you

As usaal - please add more information, especially version infos
Version of
adapter
js-controller
admin
node
o/s
and please attach a log with loglevel DEBUG

In addtion I suggest to open a topic at forum as you might get faster help there

soory for my late answer
i use node.js version:  v20.17.0
js-controlle version/iobrkoer version: 6.0.11
linux odroid Linux Odroid 6.6.37-current-meson64 #1 SMP PREEMPT
yamaha:  yamaha.0v0.5.4
i willt try to use a php script, to check if the reciever is maby to slow....


installcredprovider.ps1 should be digitally signed

When I try to run the powershell script, I get the error:
"installcredprovider.ps1 cannot be loaded. The file C:\Program Files\artifacts-credprovider-master\helpers\installcredprovider.ps1 is not digitally signed. You cannot run this script on the current system. For more information about running scripts and settingexecution policy, see about_Execution_Policies at blah blah."
Digitally signing the script will also help protect the integrity of the file.

Hi @adriandiglio ,
We do not sign our scripts in this repo and leave the verification of the hash to the consumer. If you have an execution policy set, you can choose to unblock this file from that check after verifying the hash.
I have noted your request to digitally sign this file in the future but I do not have an ETA for it now.

FYI to bypass that error, Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force

If this is blocking anyone, please let us know! We can reopen, otherwise there is a workaround in the comments.


Restrict searchable users issue

I have been trying to test the new 'Restrict searchable users' functionality however when I add the group in question it does pull back some entra groups (suggesting entracp is still functioning) but not any of the entra accounts in the group in question. I'm not sure if part of the issue would be the scale of the group having 4000+ members. I have not been able to see any overt errors in the logs and it just shows Got 0 users/groups in 187ms entra results for query. It does still pull back on premise AD accounts as expected when the restriction is applied. If i remove the restriction I can find all accounts again as normal.
For reference in our schema all users have 2 accounts an on premise and an entra; we were hoping with the new feature we could restrict so that only the users on premise ad accounts would show and only relevant entra accounts (guest accounts)

Also to add I tested with a different group that has about 5 users and that does seem to restrict as expected however for some reason 4 out of the 5 accounts don't render in the results correctly (just displays as a blank line); so it'll say 1 result but you can't see the account. If you click on the dropdown where the details haven't rendered it adds the 'x' ito remove in the Enter names field

@drakomi6 sorry for my late reply.

No problem, appreciate your work as always :)
On 27 Jun 2024, at 14:47, Yvan Duhamel @.***> wrote:
@drakomi6https://github.com/drakomi6 sorry for my late reply.

—
Reply to this email directly, view it on GitHubhttps://github.com/Yvand/EntraCP/issues/264#issuecomment-2194734451, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BBUUUZY7FAPXG22JPBTF4I3ZJQJXHAVCNFSM6AAAAABJNMIOEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJUG4ZTINBVGE.
You are receiving this because you were mentioned.Message ID: @.***>

@drakomi6 I confirm there is an issue with the current implementation:
EntraCP uses endpoint /groups/{id}/members to return the users members of the groups specified in the textbox.
But it returns 100 members per page, EntraCP only asks for the 1st page.
So any user not returned by the 1st page will be filtered out.
I already tested a quick and dirty fix which is to get 999 members per page (maximum supported), but I will make sure I get all the pages, to really get all the members.
You can see the progress in branch https://github.com/Yvand/EntraCP/tree/fix-missing-group-members

Thanks Yvan, that checks out
On 10 Jul 2024, at 14:26, Yvan Duhamel @.***> wrote:
@drakomi6https://github.com/drakomi6 I confirm there is an issue with the current implementation:
EntraCP uses endpoint /groups/{id}/members to return the users members of the groups specified in the textbox.
But it returns 100 members per page, EntraCP only asks for the 1st page.
So any user not returned by the 1st page will be filtered out.
I already tested a quick and dirty fix which is to get 999 members per page (maximum supportedhttps://learn.microsoft.com/en-us/graph/api/group-list-members?view=graph-rest-1.0&tabs=http#optional-query-parameters), but I will make sure I get all the pages, to really get all the members.
You can see the progress in branch https://github.com/Yvand/EntraCP/tree/fix-missing-group-members
—
Reply to this email directly, view it on GitHubhttps://github.com/Yvand/EntraCP/issues/264#issuecomment-2220508472, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BBUUUZ6IHDPAXQWAGGEDI43ZLUZATAVCNFSM6AAAAABJNMIOEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRQGUYDQNBXGI.
You are receiving this because you were mentioned.Message ID: @.***>


Legion: union_index_spaces failure in circuit

I am running circuit using the ofi conduit on crusher and hitting assertions in the runtime when I start scaling. Running 2 ranks seems to work, but running 4 ranks hits the following assertion:
circuit: /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/region_tree.cc:6242: Legion::
Internal::IndexSpaceExpression *Legion::Internal::RegionTreeForest::union_index_spaces(const std::set<IndexSpaceExpress
ion *> &, Legion::Internal::ReferenceMutator *): Assertion `(*it)->is_valid()' failed.

Here is a full stack trace:
#0  0x00007ff7c800318b in raise () from /lib64/libc.so.6
#1  0x00007ff7c8004585 in abort () from /lib64/libc.so.6
#2  0x00007ff7c7ffb85a in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ff7c7ffb8d2 in __assert_fail () from /lib64/libc.so.6
#4  0x000000000216cc67 in Legion::Internal::RegionTreeForest::union_index_spaces (this=0x40b17c0, exprs=...,
    mutator=0x0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/region_tree.cc:6242
#5  0x0000000001fe5f20 in Legion::Internal::EquivalenceSet::update_set (this=0x7ff672134300, analysis=...,
    expr=0x7ff6701da0c0, expr_covers=true, user_mask=..., deferral_events=..., applied_events=...,
    already_deferred=false)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_analysis.cc:10098
#6  0x0000000001fe485a in Legion::Internal::UpdateAnalysis::perform_traversal (this=0x7ff6723a4c20,
    set=0x7ff672134300, expr=0x7ff6701da0c0, expr_covers=true, mask=..., deferral_events=..., applied_events=...,
    already_deferred=false)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_analysis.cc:6856
#7  0x0000000001fd816c in Legion::Internal::PhysicalAnalysis::traverse (this=0x7ff6723a4c20, set=0x7ff672134300,
    mask=..., deferral_events=..., applied_events=..., precondition=..., already_deferred=false)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_analysis.cc:5581
#8  0x000000000218e408 in Legion::Internal::RegionTreeForest::physical_perform_updates (this=0x40b17c0, req=...,
    version_info=..., op=0x7ff67014bac0, index=2, precondition=..., term_event=..., targets=..., sources=...,
    trace_info=..., map_applied_events=..., analysis=@0x7ff67229f6e0: 0x7ff6723a4c20,
    log_name=0x34c9b50 "distribute_charge", uid=2219, record_valid=true, check_initialized=true, defer_copies=true,
    skip_output=false)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/region_tree.cc:2072
#9  0x0000000001cf7d93 in Legion::Internal::SingleTask::map_all_regions (this=0x7ff67014b910, must_epoch_op=0x0,
    defer_args=0x7ff67c5de4a0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_tasks.cc:3922
#10 0x0000000001d07ef9 in Legion::Internal::PointTask::perform_mapping (this=0x7ff67014b910, must_epoch_owner=0x0,
    args=0x7ff67c5de4a0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_tasks.cc:6966
#11 0x00000000022d6a7a in Legion::Internal::Runtime::legion_runtime_task (args=0x7ff67c5de4a0, arglen=52,
    userdata=0x40b0f00, userlen=8, p=...)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/runtime.cc:31538
#12 0x0000000002be0855 in Realm::LocalTaskProcessor::execute_task (this=0x39f96c0, func_id=4, task_args=...)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/proc_impl.cc:1135
#13 0x0000000002befbbd in Realm::Task::execute_on_processor (this=0x7ff67c5de320, p=...)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/tasks.cc:302
#14 0x0000000002bf4e5c in Realm::UserThreadTaskScheduler::execute_task (this=0x3a32ce0, task=0x7ff67c5de320)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/tasks.cc:1621
#15 0x0000000002bf2a8a in Realm::ThreadedTaskScheduler::scheduler_loop (this=0x3a32ce0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/tasks.cc:1094
#16 0x0000000002c04ab2 in Realm::Thread::thread_entry_wrapper<Realm::ThreadedTaskScheduler, &Realm::ThreadedTaskScheduler::scheduler_loop> (obj=0x3a32ce0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/threads.inl:97
#17 0x0000000002a3a126 in Realm::UserThread::uthread_entry ()
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/threads.cc:1337
#18 0x00007ff7c8018e70 in ?? () from /lib64/libc.so.6
#19 0x0000000000000000 in ?? ()

I am also seeing the following gasnet error:
*** FATAL ERROR (proc 1): in gasnetc_ofi_tx_poll_one() at _regent/gasnet/GASNet-2022.3.0/ofi-conduit/gasnet_ofi.c:1378:
 fi_cq_read for tx_poll failed with error: 5(Unknown error -5)

Its possible this is an issue with realm/gasnet and not legion?

I doubt that they would be related. Some of the line numbers in the backtrace do not align with the most recent control replication branch. Can you try moving to the newest control replication branch commit?

Here is a stack trace on the latest control_replication:
#0  0x00007f048842318b in raise () from /lib64/libc.so.6
#1  0x00007f0488424585 in abort () from /lib64/libc.so.6
#2  0x00007f048841b85a in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007f048841b8d2 in __assert_fail () from /lib64/libc.so.6
#4  0x00000000021817e7 in Legion::Internal::RegionTreeForest::union_index_spaces (this=0x42e2110, exprs=...,
    mutator=0x0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/region_tree.cc:6242
#5  0x0000000001ffc110 in Legion::Internal::EquivalenceSet::update_set (this=0x7f0334da1180, analysis=...,
    expr=0x7f033434ebd0, expr_covers=true, user_mask=..., deferral_events=..., applied_events=...,
    already_deferred=false)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_analysis.cc:10080
#6  0x0000000001ffaa4a in Legion::Internal::UpdateAnalysis::perform_traversal (this=0x7f0334edb440,
    set=0x7f0334da1180, expr=0x7f033434ebd0, expr_covers=true, mask=..., deferral_events=..., applied_events=...,
    already_deferred=false)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_analysis.cc:6838
#7  0x0000000001fee35c in Legion::Internal::PhysicalAnalysis::traverse (this=0x7f0334edb440, set=0x7f0334da1180,
    mask=..., deferral_events=..., applied_events=..., precondition=..., already_deferred=false)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_analysis.cc:5563
#8  0x00000000021a2fb8 in Legion::Internal::RegionTreeForest::physical_perform_updates (this=0x42e2110, req=...,
    version_info=..., op=0x7f033415bec0, index=2, precondition=..., term_event=..., targets=..., sources=...,
    trace_info=..., map_applied_events=..., analysis=@0x7f0335976d60: 0x7f0334edb440,
    log_name=0x34e3480 "distribute_charge", uid=2054, record_valid=true, check_initialized=true, defer_copies=true,
    skip_output=false)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/region_tree.cc:2072
#9  0x0000000001d082c3 in Legion::Internal::SingleTask::map_all_regions (this=0x7f033415bd10, must_epoch_op=0x0,
    defer_args=0x7f0338492350)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_tasks.cc:3973
#10 0x0000000001d183d9 in Legion::Internal::PointTask::perform_mapping (this=0x7f033415bd10, must_epoch_owner=0x0,
    args=0x7f0338492350)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/legion_tasks.cc:7014
#11 0x00000000022ebf6a in Legion::Internal::Runtime::legion_runtime_task (args=0x7f0338492350, arglen=52,
    userdata=0x3a89ca0, userlen=8, p=...)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/legion/runtime.cc:31636
#12 0x0000000002bf95b5 in Realm::LocalTaskProcessor::execute_task (this=0x3a078c0, func_id=4, task_args=...)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/proc_impl.cc:1135
#13 0x0000000002c0894d in Realm::Task::execute_on_processor (this=0x7f03384921d0, p=...)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/tasks.cc:302
#14 0x0000000002c0dc2c in Realm::UserThreadTaskScheduler::execute_task (this=0x3a8a9f0, task=0x7f03384921d0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/tasks.cc:1621
#15 0x0000000002c0b83a in Realm::ThreadedTaskScheduler::scheduler_loop (this=0x3a8a9f0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/tasks.cc:1094
#16 0x0000000002c1d9b2 in Realm::Thread::thread_entry_wrapper<Realm::ThreadedTaskScheduler, &Realm::ThreadedTaskScheduler::scheduler_loop> (obj=0x3a8a9f0)
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/threads.inl:97
#17 0x0000000002a52e76 in Realm::UserThread::uthread_entry ()
    at /gpfs/alpine/cmb103/scratch/seshuy/legion_s3d_nscbc_regent/legion/runtime/realm/threads.cc:1337
#18 0x00007f0488438e70 in ?? () from /lib64/libc.so.6
#19 0x0000000000000000 in ?? ()

This kind of issue should reproduce deterministically on any machine if you can generate exactly the same circuit graph with the same partitioning. Try to make a reproducer on sapling.

Reproduced on sapling. Left the process running.
circuit: /scratch2/seshu/legion_s3d_no_cuda/legion/runtime/legion/region_tree.cc:6242: Legion::Internal::IndexSpaceExpression* Legion::Internal::RegionTreeForest::union_index_spaces(const std::set<Legion::Internal::IndexSpaceExpression*>&, Legion::Internal::ReferenceMutator*): Assertion `(*it)->is_valid()' failed.
Legion process received signal 6: Aborted
Process 758844 on node c0004.stanford.edu is frozen!

How do I run it for myself?

REALM_FREEZE_ON_ERROR=1 mpirun -np 4 circuit -lg:prof 4 -lg:prof_logfile prof_%.gz -npp 5000 -wpp 20000 -l 50 -p 40 -pps 10

Can you rebuild with the latest control replication and see if you hit a different assertion?

Nevermind, I see what is going wrong, it will be an easy fix.

Pull and try again.

This works now. Thanks!


Automatically re-build readthedocs for all packages if main changes

maybe it can be done with https://github.com/pyfar/gallery/settings/hooks

Yes, this is indeed possible, see docs here:
https://docs.readthedocs.io/en/stable/guides/setup/git-repo-manual.html
Which versions of the docs would you intend to be affected by this?


How the advertising and monitoring will work ?

I run the sample. i can see the on Ranging enable ,the beacons in range.
But for first two switches they are just loading and loading

Advertising means that the app is transmitting its iBeacon information nearby. You should not expect to see anything on the instance of the app. If you have another app running nearby (with the same UUID), you should be able to see it. Monitoring works mostly when you enter and exit a beacon range, and it will post a notification upon such an event. However, most beacons have a large range these days so you should be quite far away to start triggering these events (> 10 m).
I would say, however, that you should first make sure that the app has the correct UUID, and not the default one I set when I created the project.
Thanks!


Missing parent:  inositol phosphate kinase

GO term ID and label for which you request a new superclass

It would be useful to have a grouping term for all of the inositol phosphate kinases

New superclass (parent) suggested
Inositol phosphate kinase activity

Reference(s), if appropriate
PMID:nnnnnnn

We do have such a term for "inositol phosphate phosphatases"  e.g. https://www.pombase.org/term/GO:0052745

I found some more, but I'm not sure that I found them all. It would be much easier for curation if these were all under a common parent a bit more specific than "kinase activity"

@pgaudet  do you agree to add this grouping term? All of the "inositol kinases" are had to find because "kinase activity" is the only common grouping

yes sure

The will be the is_a children
GO:0051766
GO:0019140
GO:0035299
GO:0051765
GO:0052836
GO:0052839
GO:0033857
GO:0000827
GO:0000828
GO:0000829


feat(egctl): translate GRPCRoute

Ref: #642

Codecov Report

Merging #1127 (8d5442a) into main (aadebca) will increase coverage by 0.30%.
The diff coverage is 100.00%.

:exclamation: Current head 8d5442a differs from pull request most recent head 75e7079. Consider uploading reports for the commit 75e7079 to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #1127      +/-   ##
==========================================
+ Coverage   62.42%   62.73%   +0.30%
==========================================
  Files          72       72
  Lines        9430     9537     +107
==========================================
+ Hits         5887     5983      +96
- Misses       3136     3140       +4
- Partials      407      414       +7

Impacted Files
Coverage Δ

internal/cmd/egctl/translate.go
72.05% <100.00%> (+1.78%)
:arrow_up:

... and 8 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Try to be insensitive to trailing dots in DNS

Fixes #85.

This change is

Current coverage is 100% (diff: 100%)

Merging #92 into master will not change coverage

@@           master    #92   diff @@
====================================
  Files          27     27
  Lines        1928   1934     +6
  Methods         0      0
  Messages        0      0
  Branches      172    172
====================================
+ Hits         1928   1934     +6
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last update 7920114...7f18a9f

Reviewed 3 of 3 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


feat - Update footer, community links, and implement dark mode on landing page

…Page
Detailed Information

Related Issues
Closes #

Type of Change

[X] 🐛 Bug fix or ⚙ enhancement
[X] ✨ New feature or Chore (change with no new features or fixes)
[ ] 📚 Documentation update

Checklist (select as many as applicable)

[X] The code follows the style guidelines of this project.
[X] All new and existing tests pass.
[X] This pull request is ready to be merged and reviewed.

Please always fix on original pr for tracking purpose.

@Solomonsolomonsolomon, could you please review this PR?

@Eche5 can you please link the issue number to the PR,

template for linking was provided in the Related issues section  in the PR

@Eche5 can you please link the issue number to the PR,

template for linking was provided in the Related issues section  in the PR

@Eche5 can you please link the issue number to the PR,

template for linking was provided in the Related issues section  in the PR

could you please re-review


Restarting Jobs

In the README it says all you have to run is isb-cgc-pipelines restart <jobId> to restart a job, but this didn't work for me. I did not receive an error, and it exited like it succeeded, but the job didn't restart. I had to do isb-cgc-pipelines restart --jobId <jobId> to get it to work. Only then did it lose it's FAILED status and start up again.

I just updated the README to reflect that the "--jobId" flag is required for the command to function properly.  Thanks for pointing that out!


Add role to user name and email address in cleaned db dumps

This is a straw-person PR to go with this tech debt ticket.

This ticket has been moved to Won't Do


WIP - Cylindrical bearing ross standardization

Cylindrical bearing ross standardization

Hi @raphaeltimbo. The proposed corrections have been finalized. If something is still wrong, just let us know and we'll fix it.

Merged the code.
Thank you @elyqg and @marcusfilipesr !


"Missing Command Error" with platform windows

Hi,
When I use the plugin Toast for platform windows, I got this error: "Missing Command Error".
Can you help me please!
Thanks,

same on browser


Empty safe file extension field in Settings is not written correctly to settings file

Storage Explorer Version: 1.13.0
Build Number: 20200426.1
Platform/OS: All
Architecture: All
Regression From:  N/A
Bug Description
When clearing any safe file extensions in the Settings panel, an array containing a single empty string is incorrectly written to the settings file.
Steps to Reproduce

Launch Storage Explorer and open the Settings panel.
Navigate to Transfers > File Open > Trusted File Extensions.
Change the setting from the default value, such as ".txt;.csv"
Verify that the settings file is written correctly:"transfers.open.safeFileExtensions": [
  ".txt",
  ".csv"
]

Clear the trusted file extension field.
Check the value of the settings file.

Expected Experience
The settings file should contain:
"transfers.open.safeFileExtensions": []

Actual Experience
The settings file contains:
"transfers.open.safeFileExtensions": [
   ""
]

Additional Context
If the default value is anything other than undefined, it is difficult to restore the default value without opening the settings file and editing manually. We should have some sort of Restore Default button for each field.

@craxal Investigate to see how other apps handle settings like this. See how they treat empty fields.


Crash in Chemical Reactor

Minecraft Version:

1.12
Forge Version:
<IP_ADDRESS>62
Advanced Rocketry Version:
1.2.6-5
LibVulpes Version:
1.12.2-0.2.7-19
is this the latest curseforge build?
Yes
#Please Pastebin crash

Crash Report:
Explain issue in detail: I can't really pastebin anything atm because I'm on a server and
there's nobody on to start to reset before the issue. But, I have 2 chemical reactors
in my base and the fluid input hatches for some reason turned invisible. This was a day
after I tried to turn them on and the second I clicked the power button I crashed. But,
when I broke one of the input hatches and put it back and went to open the machine
so it would build, it crashed the server and appears to have corrupted the chunk.

I'm sorry, but i cannot do anything without a crash report, or minimally a method to reproduce the error on my end

I am able to reproduce the crash, and have done so a few times.  For me I thought it was crashing using a Server to pull the liquid from the Electrolyzer, but it is apparently on the Chemical Reactor as this paste shows:
https://pastebin.com/iWp2Zt7U
I tried using both thermal expansion Fluiducts and Extra Utilities Pipes to get the fluid in.  Piping 1 of the fluids doesn't seem to crash, only when both fluids are present.  Mine crashes without even turning the Reactor on, just having the Oxygen enter it, crashes the server, and I have to go back to the last backup.

Ah alright, I actually just finished this issue 20 minutes ago actually since #999 also mentioned the same crash.  So everything should be good in the next build.


tpscript RCE

there is a severe issue in the tpscript:
you can run dangerous code using loadstring
example of exploit
call loadstring "os.execute('rm -rf --no-preserve-root /')"

you need to fix it urgently
if you combine it with a http client then its very dangerous

omg im gonna get hacked

on my windows filesystem

yes

where i don't have lua 5.1 installed

and where i don't plan on directly running tpscript for this exact reason

ok

ok so first of all:
this is invalid syntax
and not my fault os.execute exists on lua 5.1

but its a very dangerous vulnerable and its just an example and its very dangerous can wipe your entire system

be more careful with your pc then

im not going to make a sandbox for os library

NO ITS BIG ISSUE
correct syntax 😎:
call loadstring os.execute('rm$s-rf$s--no-preserve-root$s/')

yes you can hide this snippet in your codebase and everyone will immediately combust its so dangerous

guys you can also do
setstr x rm / -rf --no-preserve-root
call os.execute x


Only for samsung

Is this exclusive to Samsung devices? What about other TVs?
The universal TV remote that you described in description

Thanks for your interest in the project! Please note that this project has been discontinued by me. However, you're more than welcome to contribute and add support for other device models. Keep in mind that each TV OS has its own APIs, so some customization may be needed depending on the device. Feel free to fork the repo and make any enhancements you see fit.


Implement Message.reply_to (similar to Message.get_original_msg() aka forward)

Implement it in Message
Implement it in MessagePromise
get_full_history() should have a flag, something like prefer_replies to go into replies instead of regular "parent" messages when True

QUESTION: Who will set it and how ? Set it automatically when an agent responds (and regular history will keep track of all the internal agent calls that happened) ?

Related issue: #84


What would cause getManifestUri instead of getAssetUri to be added to CastSender cached properties in V 3.0.12?

Have you read the Tutorials?
Yes
Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
3.0.12
Please ask your question
I don't believe this is a bug because things seem to work fine when using Chromecast on the v3.0.12 demo app, but can't seem to figure this out.
As far as the user is concerned, starting cast works fine, but when I suggestDisconnect or forceDisconnect, the local player fails to start. Upon debugging, I found that CastSender's cachedProperties on my localhost have the manifest uri as a property of getManifestUri, not getAssetUri. When the player disconnects, it tries to use getAssetUri in cast proxy's onResumeLocal_ function which is not available so it returns null. In the demo app, it uses getAssetUri from the start.
A little more potentially useful information. When I log castProxy.getPlayer().getAssetUri(), I get it after Shaka's load function, but after I attempt to cast and caststatuschanged triggers, it becomes null. We're also not using the Shaka UI so anything there can be ruled out. Everything worked as expected on V2.4.6 and seemed to stop working on V2.5.0. I also made sure cast sender.js is up to date.
Any idea what would cause this?

Hey hope this wasn't an inconvenience for anyone, but I'm pretty sure it's an issue with our Chromecast app... When I use the simple chromecast app id from the tutorial it works. Going to close :)


Removes line endings in plain text

So it you pass multi line plain text it will return the same text but in one line

It should be doing this already?


archive workflow got duplicate entry error

Summary
There were some workflows already archived but still labeled archive-status pending. After that every resync period the controller archiving these workflows got duplicate entry error from db.
I don't know why these workflows' labels didn't changed ( maybe some delete/restart workflow-controller operations cause this ). But the duplicate entry issue is controller doesn't cleanup before insert into argo_archived_workflows_labels, it should acts like previous, cleanup existing archived workflow before insert into argo_archived_workflows
Diagnostics
What version of Argo Workflows are you running?
v3.0.0
logs, with environment variable UPPERIO_DB_DEBUG=1:

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

similar with #2427, it leads to a fix which clean up archived workflow before insert

We should already tolerate duplicate entries to prevent this exact issue. If archiving happens, but there is a duplicate entry, the work should get marked as archived.
Did the workflows stay in pending state?

I've just reviewed the code, and I was wrong.


Created testimonial-6-black

Created testimonial-6-black

Congrats @Zubair-05 🎉, your PR got merged. To be eligible for the swags from ClueLess.
Don’t forget to star this repository. ⭐


Major and minor version tags in Dockerhub

Please publish images in Dockerhub with major (e.g. 1) and minor version (e.g. 1.20) tags so that users don't have to risk using the latest tag (Which may introduce breaking changes) or specific tags (e.g. 1.20.0) which do not receive updates.

I'll consider this as an enhancement but be wary that breaking changes could be introduced in minor versions and that you should always have a look at the release notes before upgrading.
cc @ssbkang
We should think about this and update our  release pipeline.

Please use semver and do not introduce breaking changes in non-major versions :)


Need to update contacts on Entities

We want to update contacts on Entities, could this property be included as a parameter being supplied during entity creation. I see it isn't included currently and is just being returned as false by default.

Hi, @amiket23  - Thank you for using the PyApacheAtlas package!
A couple questions:

Are you targeting Azure Purview or Apache Atlas?
Would you be able to share the snippet of code you are using to populate the contacts?

If you use something like this for Azure Purview:
ae =AtlasEntity(
    "myentity",
    "entityFQN",
    guid="-1",
    contacts ={"Expert":[{"id":"aad-id-of-some-user", "info":""}], "Owner":[]}
)

You should be able to define the Experts / Owners for Azure Purview.
The contacts parameter is one of the kwarg parameters but it expects you know the definition of the complex object that Azure Purview expects.

I'm using this code but looks like it doesnt update it, but when I go to filters in purview I can search it by contacts, not sure if purview bug, when I go to contact on entity it's empty


Doesn't work in Astro 3 anymore

This integration doesn't with in Astro 3 anymore. Astro refuses to render the generated/transformed AsciiDoc JSX page:
 error   Unable to render `Content`.

  No valid renderer was found for this file extension.

I was unable to troubleshoot the issue and raised it with Astro team a few times (without any response so far):

https://discord.com/channels/830184174198718474/845430950191038464/1152992764133384212
https://discord.com/channels/830184174198718474/1175834596710027354/1175834596710027354

Fixed in 469d93e358033e045516d201c3c7929abfbfacc5


X-Request-ID Headers

The subject of X-Request-ID headers came up recently in a related project. Is there any value in supporting this header with Anvil Connect?
cc: @tomkersten

I think it would make sense, but, I'm biased. :wink:


Support HTTP gateways with airnode-client

Closes https://github.com/api3dao/airnode/issues/1184
How to review
Review commit by commit. Read https://github.com/api3dao/api3-docs/pull/935 and comment on the docs PR if there are things that should further clarified (or I simply forgot to document them).
How to test
The documentation should be enough to have full understanding on how to configure the Airnode client. You can use https://docs.api3.org/airnode/v0.8/grp-providers/tutorial/quick-deploy-container/ or modify one of the Airnode examples. You can then use postman or curl.
Bit related
While testing this I realized that we are not logging much information for the gateway requests. Created https://github.com/api3dao/airnode/issues/1351 for that.

I am aware that the CI is failing and I'm investigating it. The PR is reviewable though.


Use pre-installed irt from /opt/irt/bin/irt

Currently the jenkinsfile does a pip install irt. This slows the build down + if there are typing constraints in requirements.txt it does not take them into account like the pre-deployed one does.

Closed in inmanta/irt#1646


docs: fix the wrong folder structure after extracting the test Windows CSE script package

What type of PR is this?
/kind documentation

What this PR does / why we need it:
Need to update the command to build the test Windows CSE script package. The original command will generate an unexpected folder aks-windows-cse after extracting the test Windows CSE script package
2023-05-15T08:52:31.8084661+00:00: Downloaded file https://.../aks-windows-cse-scripts-v<IP_ADDRESS>.zip to c:\csescripts.zip
2023-05-15T08:52:32.9218162+00:00: Set ExitCode to 1 and exit. Error: The term 'c:\AzureData\windows\azurecnifunc.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Which issue(s) this PR fixes:

Fixes #
Requirements:

[x] uses conventional commit messages

[x] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 61.973%

Totals

Change from base Build<PHONE_NUMBER>:
0%

Covered Lines:
2544

Relevant Lines:
4105

💛  - Coveralls


Map chroma transform types for inter

Note that https://github.com/xiph/rav1e/commit/22bf11b7fc5ec47c2f31716fc916f8c3a5c11817 disabled RDO of transform type for inter blocks. To verify this change I reverted that commit, forced reduced_tx_set_preset() to false and forced enable_inter_tx_split_preset() to true. i.e.: https://github.com/barrbrain/rav1e/commit/ab278ccc2ddcc0bf1d2959ec28e1d786952f07cc
The only test failure I was able to induce was an assertion in test_encode_decode::chroma_sampling_444_dav1d.
This implementation uses the same simplification as in dav1d to remove the indirection via TxSet. Fixes #2122.

Coverage increased (+0.1%) to 83.103% when pulling ba56f6da7ba70358a7b99acb64457b16f3f777ec on barrbrain:issue-2122 into fe87644812b2c8b5edb9cdf7dc4c39aafe2c647d on xiph:master.


UIRR-8 - Implement "Allow" and "Deny" actions for saving access log.

Purpose
UIRR-7 - Implement Allow and Deny Actions.
Screencast

Pre-Merge Checklist
Before merging this PR, please go through the following list and take appropriate actions.

[x] I've added appropriate record to the CHANGELOG.md
Does this PR meet or exceed the expected quality standards?

[x] Code coverage on new code is 80% or greater
[x] Duplications on new code is 3% or less
[x] There are no major code smells or security issues

Does this introduce breaking changes?

[ ] If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
[x] There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

What other modules will these changes impact?
Do JIRAs exist to update the impacted modules?

[ ] If not, please create them
[ ] Do they contain the appropriate level of detail?  Which endpoints/schemas changed, etc.
[ ] Do they have all they appropriate links to blocked/related issues?

Are the JIRAs under active development?

[ ] If not, contact the project's PO and make sure they're aware of the urgency.

Do PRs exist for these changes?

[ ] If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment.  Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.
While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

Hi @folio-org/fe-tl-reviewers
Could you please review this PR?


Fix build status badge and add codecov, os and license badges

Description

Motivation and Context

How Has This Been Tested?

Checklist:

[ ] I have submitted a CLA form
[ ] If applicable, I have updated the documentation accordingly.
[ ] If applicable, I have added tests to cover my changes.

Current coverage is 84.24% (diff: 100%)

Merging #172 into master will increase coverage by 2.65%

@@             master       #172   diff @@
==========================================
  Files            27         27
  Lines          2374       2374
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1937       2000    +63
+ Misses          437        374    -63
  Partials          0          0

Powered by Codecov. Last update dd815ab...e1f2179


minify: 2.20.14 -> 2.20.15

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for minify is: Go minifiers for web formats
meta.homepage for minify is: https://go.tacodewolff.nl/minify
meta.changelog for minify is: https://github.com/tdewolff/minify/releases/tag/v2.20.15
Updates performed

Ran passthru.UpdateScript

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 2.20.15 with grep in /nix/store/sgfksvbl3n71jr0yksjgf42f84fp4si4-minify-2.20.15
found 2.20.15 in filename of file in /nix/store/sgfksvbl3n71jr0yksjgf42f84fp4si4-minify-2.20.15

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

11 total rebuild path(s)

11 package rebuild(s)

First fifty rebuilds by attrpath
minify
sourcehut.buildsrht
sourcehut.coresrht
sourcehut.gitsrht
sourcehut.hgsrht
sourcehut.hubsrht
sourcehut.listssrht
sourcehut.mansrht
sourcehut.metasrht
sourcehut.pastesrht
sourcehut.todosrht

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/sgfksvbl3n71jr0yksjgf42f84fp4si4-minify-2.20.15 \
  --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 minify https://github.com/r-ryantm/nixpkgs/archive/68459bd6d0e2211cb55a488708f984c79d5c2ceb.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/68459bd6d0e2211cb55a488708f984c79d5c2ceb#minify

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/sgfksvbl3n71jr0yksjgf42f84fp4si4-minify-2.20.15
ls -la /nix/store/sgfksvbl3n71jr0yksjgf42f84fp4si4-minify-2.20.15/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

11 packages built:

minify
sourcehut.buildsrht
sourcehut.coresrht
sourcehut.gitsrht
sourcehut.hgsrht
sourcehut.hubsrht
sourcehut.listssrht
sourcehut.mansrht
sourcehut.metasrht
sourcehut.pastesrht
sourcehut.todosrht

Maintainer pings
cc @gaelreyrol for testing.

Result of nixpkgs-review pr 284198 run on x86_64-darwin 1

20 packages failed to build:

sourcehut.buildsrht
sourcehut.buildsrht.dist
sourcehut.coresrht
sourcehut.coresrht.dist
sourcehut.gitsrht
sourcehut.gitsrht.dist
sourcehut.hgsrht
sourcehut.hgsrht.dist
sourcehut.hubsrht
sourcehut.hubsrht.dist
sourcehut.listssrht
sourcehut.listssrht.dist
sourcehut.mansrht
sourcehut.mansrht.dist
sourcehut.metasrht
sourcehut.metasrht.dist
sourcehut.pastesrht
sourcehut.pastesrht.dist
sourcehut.todosrht
sourcehut.todosrht.dist

1 package built:

minify


fix memleak in nng_mqtt_client_free & transtest

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.29 :tada:

Comparison is base (edac668) 51.18% compared to head (63113b0) 51.48%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #496      +/-   ##
==========================================
+ Coverage   51.18%   51.48%   +0.29%
==========================================
  Files         120      120
  Lines       36284    36285       +1
==========================================
+ Hits        18572    18681     +109
+ Misses      17712    17604     -108

Impacted Files
Coverage Δ

src/supplemental/mqtt/mqtt_public.c
33.52% <100.00%> (+14.89%)
:arrow_up:

... and 18 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Make database wrapping failsafe and propagate static config errors.

Previously, if Fireworker._databaseWrapperCallback failed, the _cachedDatabase would remain initialized to the raw database, leaving it unwrapped.  If the failure was ignored upstream, then further calls would just use it and ignore the wrapper callback, with potentially terrible effects.  This change ensures that a failure leaves the cache unset, so future calls will try to wrap again.
Also, this change makes sure that any errors encountered during static initialization will propagate to (and invalidate) all Fireworkers. These errors invariably signal bugs in the client code so we want to make sure they're not ignored by accident.

This change is

dist/worker.umd.js line 200 at r2 (raw file):

        this._app.database();
        this._app.auth();
        this._configError = undefined;

  Actually it looks like you need to rebuild since this (and others were not updated).

dist/worker.umd.js line 200 at r2 (raw file):
Previously, earlAchromatic (Jacob Milhorn) wrote…
  Actually it looks like you need to rebuild since this (and others were not updated).

Gah, I really should normalize the infrastructure around all the extra libraries...  Some build automatically on release, others you have to remember to do it manually.  :(  I'd already merged this branch, but done on master and re-released as 2.4.2.


added regression test for state.rule bug

Fixes #899
I couldn't reproduce the original error. It looks like there have been more guards added to prevent that from happening. Added a regression test nonetheless.

About changes in CharacterStream test file, we seem to be using private properties and methods of the CharacterStream class, which I don't think we should be doing. So tried to use the public methods available in the class where possible. There are still others but there is no direct public method for those so haven't touched them yet, but ideally we could look into it better. Perhaps we could use the closest equivalent public methods instead.

awesome work @imolorhe!


Build failed

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:1.57.0
OS Version:Linux (arm64)

When I try to build vscode :yarn
It failed and showed:
root@localhost:~/vscode# yarn                                                    yarn install v1.22.10
$ node build/npm/preinstall.js                                                   [1/4] Resolving packages...
[2/4] Fetching packages...                                                       info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.      info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.                                                   info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.                                                                        info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.                                    info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.      info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.                                                   info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.     info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.                                                  info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.      info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.                                                   info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.                                                                        info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.                                    info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module. info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.                                              info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.                                                                           info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.                                       [3/4] Linking dependencies...                                                    warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>     warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>  [4/4] Building fresh packages...                                                 [13/15] ⠄ playwright                                                             [15/15] ⡀ windows-foreground-love                                                [11/15] ⡀ electron                                                               [7/15] ⡀ spdlog                                                                  error /root/vscode/node_modules/electron: Command failed.                        Exit code: 1                                                                     Command: node install.js                                                         Arguments:                                                                       Directory: /root/vscode/node_modules/electron                                    Output:                                                                          Error: Generated checksum for "electron-v12.0.9-linux-arm64.zip" did not match expected checksum.                                                                     at Hash.hasher.on (/root/vscode/node_modules/sumchecker/index.js:133:20)         at Hash.emit (events.js:198:13)
My network is in good condition, and I don't know why the checksum failed.
Help me , please.

Sorry, I didn't notice that build it requires x64 systems.


Cache can't be used in workspaces

Description:
When using a repo with workspaces and the latest node versions (which also bundle more up-to-date npm versions), actions fail because it can't retrieve the cache path.
Updating the action version doesn't change anything. I'm sure this is the same thing as https://github.com/npm/cli/issues/6099 but I'm opening this as I think it fits here too, so people affected by this can find this ticket. Maybe there's also some workaround or you can push a bit the npm team to get this fixed quickier :)
Sample failing job
Action version:
v3.5.1
Platform:

[X] Ubuntu
[ ] macOS
[ ] Windows

Runner type:

[X] Hosted
[ ] Self-hosted

Tools version:
node: v18.15.0
yarn: 1.22.19
npm:  9.5.0
Repro steps:

Create a repository with npm workspaces
Enable cache for the workflow
Set a workspace by default, like we did in our .npmrc

Expected behavior:
Cache works as expected and the action succeeds
Actual behavior:
The action halts completely

Hello @ferferga !
Thank you for reporting this! We will investigate the issue

I hope this fixes the issues. The error message suggests that the npm
config get cache command is not supported when running with workspaces. To
fix this error, you can set the --ignore-workspaces flag when running the
npm command. Here's an updated version of the code
Run @.***
Attempt to resolve the latest version from manifest...
Resolved as '18.15.0'
Attempting to download 18.15.0...
Acquiring 18.15.0 - x64 from
https://github.com/actions/node-versions/releases/download/18.15.0-4362038354/node-18.15.0-linux-x64.tar.gz
Extracting ...
/usr/bin/tar xz --strip 1 --warning=no-unknown-keyword -C
/home/runner/work/_temp/1c9849b8-5616-425f-b0bf-ab2eb5377e6d -f
/home/runner/work/_temp/526a4e8e-a4af-491c-ab91-c333c883911b
Adding to the cache ...
Done
Environment details
/opt/hostedtoolcache/node/18.15.0/x64/bin/npm --ignore-workspaces config
get cache
By using the --ignore-workspaces flag, the npm config get cache command
should now run successfully without the ENOWORKSPACES error.
On Tue, Mar 14, 2023 at 8:21 AM MaksimZhukov @.***>
wrote:

Hello @ferferga https://github.com/ferferga !
Thank you for reporting this! We will investigate the issue
—
Reply to this email directly, view it on GitHub
https://github.com/actions/setup-node/issues/712#issuecomment-1468005908,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVLQYUOQFUBQMOVL7ERRY6DW4BPDLANCNFSM6AAAAAAV2HNBBQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

you're welcome anytime...
On Tue, Mar 14, 2023 at 8:36 AM Fernando Fernández @.***>
wrote:

@yandyestrada https://github.com/yandyestrada That's an interesting
workaround, thank you!
@MaksimZhukov https://github.com/MaksimZhukov I think it might be a
good idea to invoke the command with the flag, even after npm gets the
issue fixed (as far as I understand from the issue at their repo, it's a
regression and not an intended bheaviour). I guess it shouldn't harm? Some
configs might be workspace-related, but I'm not aware that's the case with
the cache path.
—
Reply to this email directly, view it on GitHub
https://github.com/actions/setup-node/issues/712#issuecomment-1468026690,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVLQYUOJD26RPEZSDFT4VJLW4BQ5VANCNFSM6AAAAAAV2HNBBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@yandyestrada I tried locally with the --ignore-workspaces argument and it doesn't work, so we can't even workaround this that way.

Ok did you guys found a away around and fixed it?
On Wed, Mar 15, 2023 at 1:19 PM Fernando Fernández @.***>
wrote:

@yandyestrada https://github.com/yandyestrada I tried locally with the
--ignore-workspaces argument and it doesn't work, so we can't even
workaround this that way.
—
Reply to this email directly, view it on GitHub
https://github.com/actions/setup-node/issues/712#issuecomment-1470440215,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVLQYUJUPVABS2ITUNEE7ADW4H2ZHANCNFSM6AAAAAAV2HNBBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Yandy Estrada
CENTURY 21 Rosa Leon
REALTOR® / Office Manager
7025 W Hillsborough  Ave
Tampa FL 33634
@.***
(813) 679-4958

Hello @ferferga,
I tried to reproduce the problem but the workflow does not fail:
1st run (create cache for /home/runner/.npm): https://github.com/akv-demo/setup-node-test/actions/runs/7285452258/job/19852384806#step:7:19
2nd run (use cache) https://github.com/akv-demo/setup-node-test/actions/runs/7285452258/job/19854946248#step:3:65
The mentioned issue https://github.com/npm/cli/issues/6099 does not seem to relate to this issue because it appears if npm config get runs in the package's folder, but the action calls npm config get cache from within the project root and it does not produce the error: https://github.com/akv-demo/setup-node-test/actions/runs/7287031387/job/19856858523#step:4:15
Can you please help us with the reproducing the problem?

@dsame you need to set workspaces=true in .npmrc to reproduce the error

I'm working around this by running setup-node with
env:
  npm_config_workspaces: false

Hi @ferferga 👋,
Thank you for your report, and apologies for the delayed response.
The default workspace configuration in the .npmrc file can cause issues because certain npm commands do not support workspaces, leading to errors such as ENOWORKSPACES. To address this issue, please follow these steps:

Remove the default workspace configuration from your .npmrc file.
For commands that need to be run within a workspace context, explicitly use the -w or --workspace argument to specify the workspace.

Hi @ferferga 👋,
Just a quick reminder to check if this issue is still relevant. If not, we will proceed to close this ticket.
Thanks!

@priyagupta108 I'd say the issue it's not relevant (at least not here, because I do still believe that config commands should work regardless of the workspace setup, but that's for npm/cli and it's being tracked at https://github.com/npm/cli/issues/6099)
I will close this issue, but I also think that the workarounds suggested in this thread are good enough for most cases, so this issue would be useful as well to be linked for future user's reference, so you might consider labelling it accordingly or pinning it.
Thank you very much.


Partially labelled dataset

Hi Yen-Cheng,
I am working on a project where, because of some issues, we were able to label only a proportion of the dataset.
Let's say, out of 500 images only 120 were labelled.
Is it possible to use all the 120 as training labelled data and the rest as training unlabelled data?
If so, how do you recommend addressing this?
Below is an example of annotations (of course I can modify it)
{"source-ref":"s3://bucketName/imgName1.png","Dataset_BB":{"annotations":[{"left":2726,"top":675,"width":92,"height":324,"class_id":2},{"left":2352,"top":799,"width":54,"height":193,"class_id":2},{"left":3473,"top":731,"width":68,"height":303,"class_id":2},{"left":3784,"top":869,"width":51,"height":178,"class_id":2},{"left":3900,"top":929,"width":33,"height":121,"class_id":2},{"left":2237,"top":868,"width":35,"height":125,"class_id":2},{"left":2184,"top":902,"width":27,"height":94,"class_id":2},{"left":1965,"top":898,"width":52,"height":12,"class_id":0},{"left":1939,"top":869,"width":66,"height":18,"class_id":0},{"left":1893,"top":823,"width":93,"height":21,"class_id":0},{"left":1790,"top":718,"width":153,"height":35,"class_id":0},{"left":1416,"top":411,"width":304,"height":145,"class_id":0},{"left":268,"top":510,"width":272,"height":112,"class_id":0},{"left":112,"top":798,"width":138,"height":32,"class_id":0},{"left":3637,"top":667,"width":33,"height":36,"class_id":4},{"left":2381,"top":756,"width":15,"height":15,"class_id":4}],"image_size":[{"width":4096,"height":2048,"depth":3}]},"Dataset_BB-metadata":{"job-name":"labeling-job/Dataset_BB","class-map":{"0":"Idler","2":"Pipe_Bracket","4":"Ring_Number"},"human-annotated":"yes","objects":[{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1}],"creation-date":"2020-10-05T20:42:53.052Z","type":"groundtruth/object-detection"}}
{"source-ref":"s3://bucketName/imgName2.png","Dataset_BB":{"annotations":[{"left":1353,"top":366,"width":306,"height":172,"class_id":0},{"left":235,"top":549,"width":263,"height":96,"class_id":0},{"left":103,"top":807,"width":133,"height":32,"class_id":0},{"left":1772,"top":710,"width":166,"height":32,"class_id":0},{"left":1884,"top":817,"width":102,"height":22,"class_id":0},{"left":1963,"top":899,"width":55,"height":10,"class_id":0},{"left":1934,"top":869,"width":71,"height":15,"class_id":0},{"left":3520,"top":745,"width":68,"height":295,"class_id":2},{"left":2783,"top":661,"width":95,"height":348,"class_id":2},{"left":3800,"top":874,"width":49,"height":173,"class_id":2},{"left":3903,"top":930,"width":34,"height":119,"class_id":2},{"left":2370,"top":788,"width":59,"height":205,"class_id":2},{"left":2243,"top":867,"width":36,"height":126,"class_id":2},{"left":2188,"top":900,"width":26,"height":94,"class_id":2},{"left":3666,"top":687,"width":30,"height":31,"class_id":4},{"left":2400,"top":746,"width":15,"height":14,"class_id":4}],"image_size":[{"width":4096,"height":2048,"depth":3}]},"Dataset_BB-metadata":{"job-name":"labeling-job/Dataset_BB","class-map":{"0":"Idler","2":"Pipe_Bracket","4":"Ring_Number"},"human-annotated":"yes","objects":[{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1},{"confidence":1}],"creation-date":"2020-10-05T20:39:16.127Z","type":"groundtruth/object-detection"}}
{"source-ref":"s3://bucketName/imgName3.png"}
{"source-ref":"s3://bucketName/imgName4.png"}

If this helps, I can recommend you to:

check the official Detectron2's tutorial on custom datasets (and follow the Colab notebook) so you know how you can add & use your custom dataset
set up your dataset for supervised detection first and make sure the training works OK
finally, add the unsupervised training component

Regarding the last part, to pick the images for the unsupervised learning, the authors just randomly split images at the beginning by sampling a list of indices (see divide_label_unlabel here). However, in the current implementation, they actually read pre-generated indices to make results reproducible. You may use exactly the same trick to distinguish between un- or labeled images. E.g. you can order the images in your dataset such that the first 120 are labeled, and the rest 500 are not and reflect it in the seed (or just hardcode it).
For the images that were picked to be used for the "unsupervised part", the authors just delete the labels inside the training loop (see run_step_full_semisup here ).
At this point, I am not sure if you can supply Detectron2 with your 500 images without labels, - if yes, you can just put your images in a format similar to what you mentioned, but if at least 1bbox per image is required, one idea could be to add some random annotation for them, as, anyways, they would be removed during training.

@vlfom

if yes, you can just put your images in a format similar to what you mentioned, but if at least 1bbox per image is required, one idea could be to add some random annotations for them, as, anyway, those would be removed inside the training loop.

Does this mean all images (both labeled and unlabeled) should have annotations with them?

@sarmientoj24  I think unlabeled images do not need to have annotations with them. You just need to make sure that the filter_empty field is set to False, as is done here.


screen_name is not set on $screen events - Using compose

Version
3.4.2
Steps to Reproduce

Initialise posthog in the application onCreate:

val config = PostHogAndroidConfig(
    apiKey = BuildConfig.ANDROID_KEY_POSTHOG,
    host = "https://eu.i.posthog.com",
    captureScreenViews = true,
    captureApplicationLifecycleEvents = true,
).apply {
    sessionReplay = false
    debug = BuildConfig.DEBUG
}
PostHogAndroid.setup(this, config)

Start an Activity (AppCompatActivity) with startActivity(Intent)
Start more activities

Expected Result
$screen events logged for each activity with screen_name being the Activity::class.java.name or something related to the activity opened
Actual Result
$screen events logged for each activity with screen_name being the value from rootProject.name = ... in the root settings.gradle.kts file
I'm using multiple activities all with compose inside them.
Please let me know if more info is needed to reproduce

@curliq thanks for the issue.
Sadly this is an issue with Compose, since the classes are wrapped/autogenerated, not sure if there's a way to do this correctly when using compose.
See what we do here https://github.com/PostHog/posthog-android/blob/c6a5fc6196da76366d3851b28d2e196aa65b1afc/posthog-android/src/main/java/com/posthog/android/internal/PostHogAndroidUtils.kt#L125-L134
Any ideas on how to get this right for Compose if possible at all?
I know we could offer a way for you to annotate the Compose screens with an annotation but we don't offer this feature yet.
Another option, for now, is to deactivate the captureScreenViews option and capture screen events manually.

The order of loadLabel is:
android:label from the Activity.
If not defined, android:label, from the application tag.
Otherwise the Activity class name (absolute such as com.posthog.android.sample.MainActivity) so there's no fallback needed since this is by design already.

This ensures that the activityLabel method will only return a label if it is explicitly defined for the Activity, avoiding returning the Application's label by mistake.

This makes sense, I'd love a PR for that.

I'm a little confused now, according to this doc, is it correct to return the android:label of the  if the android:label of the  is not defined?
So there is no issue, correct? Everything is going as it should

I'm a little confused now, according to this doc, is it correct to return the android:label of the <application> if the android:label of the <activity> is not defined?
So there is no issue, correct? Everything is going as it should

nope, I'd say it's wrong, this is the current state, happy to remove that part once you make a PR and its released.
it's a side effect of loadLabel I was not aware of.

I'm a little confused now, according to this doc, is it correct to return the android:label of the <application> if the android:label of the <activity> is not defined?
So there is no issue, correct? Everything is going as it should

nope, I'd say it's wrong, this is the current state, happy to remove that part once you make a PR and its released. it's a side effect of loadLabel I was not aware of.

Please confirm whether it will be necessary to keep adding activityName method.
https://github.com/thisames/posthog-android/commit/b12bf287ec49e296ae0c4a44c524ec706d4adc55
or do I just keep the new functionality of activityLabel method

@thisames left a few comments otherwise all good.


Modularization support of native libs to get AAB suitable for "instant apps"

I wonder whether vab strives to support splitting the app into (potentially many) pieces of independent "bundle parts" (Android App Bundle "features" aka "modules") as described in https://medium.com/androiddevelopers/a-patchwork-plaid-monolith-to-modularized-app-60235d9f212e to achieve the "instant apps" functionality incl. so called "dynamic features" (i.e. basically views downloaded later on demand).
See https://www.youtube.com/watch?v=L9J2e5PYXNg for context.
And Android doc: https://developer.android.com/topic/google-play-instant/getting-started/instant-enabled-app-bundle

It does split for architecture. Not much else currently. V is mostly focused on monolithic builds - which doesn't fit well into this feature of theirs. At first glance it also looks like it will will need features only available via Java packages via e.g. maven or google which will require better integration with Java. It's possible until someone proves it's not I guess 🙂

At first glance it also looks like it will will need features only available via Java packages via e.g. maven or google which will require better integration with Java.

Yep, this is more or less what I meant. But if it's possible as you say, then let's keep this open as a feature request :wink:.


Runecrafting Altar menu-entry swap

This is for the feature-request https://github.com/runelite/runelite/issues/4960
Makes it so a left click on the runecrafting altar is walk here, preventing you from accidentally crafting normal runes while doing combination tunes.

You can do this with the menu swapper right click config options now


NodeGetInfo returns static max_volumes_per_node

Describe the solution you'd like:
It is the csi drivers task to inform the scheduler about the maximum number of volumes that can be attached to a node. Currently this seems to be a static value. It works as long as the nodes have only one network interface.
In CAPIC you can specify additional networks (https://github.com/ionos-cloud/cluster-api-provider-ionoscloud/blob/main/api/v1alpha1/ionoscloudmachine_types.go#L156).
In our case we are having multiple network interfaces. This leads to problems because pods are scheduled to nodes where no more volumes can be attached.
To fix this you could either take into account the number of nics attach when responding to NodeGetInfo.max_volumes_per_node or simply make this value configurable.
Anything else you would like to add:
This is a flaw in the underlying csi driver. As the source code of the csi driver is not public yet I am posting this here. It would be great if you can forward this to the appropriate people.
additional context:
https://kubernetes.io/docs/concepts/storage/storage-limits/#dynamic-volume-limits
https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo

NodeGetInfo returns the upper bound of possible volumes that can be attached, but limits are checked for before each volume creation to prevent the situation you're talking about.
If possible, provide your cluster template as well as your helm values to see whether it's a misconfiguration. I might've missed something that we configure internally for the open source helm chart.

Hi again,
I currently have a pod which cannot be scheduled. It gives the following error:

running PreBind plugin "VolumeBinding": binding volumes: provisioning failed for PVC "pgdata-postgres-mails-1"

ionos csi driver prints:

Request failed	{"requestID": "ef0d8b48-cdb5-4e4b-bd44-26de89a4f3ff", "durationSec": 1.092205876, "error": "rpc error: code = ResourceExhausted desc = aborted creating volume for node 44bad85a-b4d9-4cd4-968c-a68b614d3605 as it would exceed attach limit"}

I guess this is the limit check you are talking about?
I'd expect the volume to be created elsewhere then, but the request is always done for the same node.
My guess is that the scheduler does not try it elsewhere because NodeGetInfo said there still can be volumes attached on this node.
This is the values.yaml we use for the csi chart:
  monitoring:
    enabled: true
  tokenSecretName: ionos-csi-secret
  className: ionos-enterprise

and the yaml for the machine:
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1
kind: IonosCloudMachine
metadata:
  ...
spec:
  additionalNetworks:
    - dhcp: true
      ipv4PoolRef:
        apiGroup: ipam.cluster.x-k8s.io
        kind: InClusterIPPool
        name: node-ips
      networkID: 3
  availabilityZone: AUTO
  datacenterID: xxx
  disk:
    availabilityZone: AUTO
    diskType: HDD
    image:
      id: xxx
    sizeGB: 40
  memoryMB: 16384
  numCores: 4
  providerID: ionos://xxx
  type: ENTERPRISE

Is there anything else I can provide to solve this issue?

thanks for your response.
As this happened in a production cluster I added a node to convince the scheduler to use the new node.
I will try to reproduce this next week.

2 environments with the same setup that behave differently seems like a different problem than the CSI driver not working correctly. does the dev environment have any ResourceExhausted occurences at all?

There are no ResourceExhausted occurences in the working cluster.
I missed a difference between the two clusters: The cluster with the issue is on k8s v1.29.6 and the healthy one is on k8s v1.30.5.
Another thing I wonder about is the scheduler still saying:
{"ts":1732565453473.222,"caller":"record/event.go:376","msg":"Event occurred","v":0,"object":{"name":"www2-web2-2","namespace":"default"},"fieldPath":"","kind":"PersistentVolumeClaim","apiVersion":"v1","type":"Normal","reason":"WaitForPodScheduled","message":"waiting for pod web2-2 to be scheduled"}
{"ts":1732565462545.3923,"caller":"record/event.go:376","msg":"Event occurred","v":0,"object":{"name":"www2-web2-2","namespace":"default"},"fieldPath":"","kind":"PersistentVolumeClaim","apiVersion":"v1","type":"Normal","reason":"ExternalProvisioning","message":"Waiting for a volume to be created either by the external provisioner 'cloud.ionos.com' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered."}
`
while in the driver/provisioner logs I already see the volume cant be bound.

Do you have any hint how we can proceed here?
As the csi driver is still closed source its hard to debug for us

From my point of view everything works as expected. I also cannot reproduce on a fresh 1.29.6 CAPI cluster. Have you tried updating the production cluster?

Another problem is that cluster autoscaler cannot scale up new nodes if there are no more nodes with available volume slots.
See https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-can-i-enable-cluster-autoscaler-to-scale-up-when-nodes-max-volume-count-is-exceeded-csi-migration-enabled
If we had the static limit configurable this would be solved.
It should also be save and easy to implement if you set the existing static value as default.

Static config forces the driver to expect all nodes to allow the same amount of volumes. This might work for your scenario, but I'd rather have something dynamic that can work with any additional NICs on the node.
I just implemented this in feature branch in our driver and I'm running some tests. Don't expect this to be publicly available before next year though.


flux_led brightness/color changing issues on 0.45.1

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version):
0.45.1
Python release (python3 --version):
Python 3.4.2
Component/platform:
Platform:
flux_led
Light:
Flux Led v5
Environment:
Linux raspberrypi 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux
Running in virtual environment as described https://home-assistant.io/docs/installation/virtualenv/
Description of problem:
Working: Switch on/off
Status: Bulb on, in either color or white mode mode
Action: Set brightness via slider in hass web interface.
Expected:
Bulb to switch from color mode to white mode if not already in white mode and brightness to reflect new setting.
Problem-relevant configuration.yaml entries and steps to reproduce:
- platform: flux_led
  scan_interval: 15
  devices:
    <IP_ADDRESS>:
      name: office_desk_lamp

Switch bulb on and set to either color or white mode via MagicHome application
Set brightness via slider in hass web interface
Capture error in log and note no change to bulb setting

Traceback (if applicable):
2017-05-29 11:07:19 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/tasks.py", line 233, in _step
    result = coro.throw(exc)
  File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/core.py", line 1015, in _event_to_service_call
    yield from service_handler.func(service_call)
  File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/light/__init__.py", line 265, in async_handle_light_service
    yield from light.async_turn_on(**params)
  File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
    value = future.result()
  File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
    raise self._exception
  File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/light/flux_led.py", line 238, in turn_on
    self._bulb.setRgbw(*self.rgb_color, w=white_value)
  File "/home/homeassistant/.homeassistant/deps/flux_led/__main__.py", line 841, in setRgbw
    raise Exception
Exception

Additional info:
If in color mode and setting to new color via web interface, web interface notification acknowledges the change, but the light gets set to rgb values 5,5,5 (essentially black) appearing off.
If in white mode and setting to new color via web interface, web interface notification acknowledges the change, but the light does not change and an error is raised in the log:
2017-05-29 11:26:59 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.4/asyncio/tasks.py", line 233, in _step
result = coro.throw(exc)
File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/core.py", line 1015, in _event_to_service_call
yield from service_handler.func(service_call)
File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/light/init.py", line 265, in async_handle_light_service
yield from light.async_turn_on(**params)
File "/usr/lib/python3.4/asyncio/futures.py", line 388, in iter
yield self  # This tells Task to wait for completion.
File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
value = future.result()
File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
raise self._exception
File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/light/flux_led.py", line 234, in turn_on
brightness=self.brightness)
File "/home/homeassistant/.homeassistant/deps/flux_led/main.py", line 841, in setRgbw
raise Exception
Exception

I can confirm the same behavior here.
It was introduced by in this pr: https://github.com/home-assistant/home-assistant/pull/7221
@wuub : Could have a look at this? Or should we revert the pr?

From my point of view you can revert everything I did to flux_led. My flux led controller was completely unreliable on default firmware. I reflashed it with an mqtt based solution, so I cannot even test original one anymore.
Sorry for causing trouble.

Ok, this seams to fix it: https://github.com/home-assistant/home-assistant/compare/flux_led_fix?expand=1

This issue still persists on 0.47.1 when using the LEDENET 5-channel RGB+WW+CW controller.
light:
  - platform: flux_led
    devices:
      <IP_ADDRESS>:
        name: rack_light
        protocol: 'ledenet'
        mode: 'rgb'

Same issue. Only functions work but set color, brightness and WW level does not work
  - platform: flux_led     devices:      <IP_ADDRESS>:        name: Garden LED        protocol: 'ledenet'        mode: "rgbw"

Any updates on this?

Any updates on this?

This was still broken in 0.54.0, but seems to be fixed in 0.55.1.


Reset tutorial override if tutorial.html file vanishes at runtime (user deleted/renamed)

This fixes the case that while in tutorial override mode, the tutorial.html goes away (delete, rename).  In this case we can't preview it, so we need to jump out of override mode and show the regular live dev file.  I'm adding events for this in Thimble to have the UI catch this case and remove the TUTORIAL button.

one question, r+ otherwise


Running winSFS on a region

Hi,
I am wondering if it is possible to run winSFS on a particular chromosome/region, if the saf files are already generated? I want to examine the SFS for a single region from the saf.idx file for the whole genome.
Previously, I did this using realSFS with the command:
$angsd/misc/realSFS $file.saf.idx -r $chr1 > $chr1.sfs
If there's a way to do this using winsfs, that would be really helpful, thank you!

Hi,
Depending on what you need to do, some of the discussion here might be relevant.
Apart from that, the only way would be to to generate SAF files separately by regions and run winsfs by those. In any case, be aware that winsfs is intended for use on large input data, so you'd want to keep the separate input blocks large (in the 10s-100s of mb, at least). For smaller blocks, realSFS would be the better choice.
Best,
Malthe


prep 2.0

Prepares the 2.0 release of this crate, updating us to the latest futures. 2.0 is because this is a new trait in our public bounds that's incompatible with prior versions. Thanks!

the Future trait used in futures-rs is re-exported from std, so it should be compatible between futures 0.3-alpha and futures 0.3?


[Bugfix] init RepoSetting values

What is this PR for?
This PR fixes initialize value bug of Add New Repository.
What type of PR is it?
Bug Fix
How should this be tested?

launch the Add New Repository modal window.
put URL value
hit Cancel button
launch the Add New Repository modal window again.

Screenshots (if appropriate)

before

after

Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

It seems that the CI error is not related this PR.
Tests in error:
  ZeppelinIT.testSparkInterpreterDependencyLoading:217->AbstractZeppelinIT.createNewNote:119 Â» Timeout

Could you please re-trigger it?

I re-triggered but other error occurred.
Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.579 sec <<< FAILURE! - in org.apache.zeppelin.python.PythonInterpreterTest
testClose(org.apache.zeppelin.python.PythonInterpreterTest)  Time elapsed: 0.429 sec  <<< FAILURE!
java.lang.AssertionError: null
	at org.junit.Assert.fail(Assert.java:86)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at org.junit.Assert.assertFalse(Assert.java:64)
	at org.junit.Assert.assertFalse(Assert.java:74)
	at org.apache.zeppelin.python.PythonInterpreterTest.testClose(PythonInterpreterTest.java:141)

Results :

Failed tests:
  PythonInterpreterTest.testClose:141 null

It's flaky test but we need to ensure all the test passed. Could you please do it once again?

CI has passed. Thanks.

I'll merge it