#[proptest] Attribute Macro

Hi! I wrote a kinda rough implemenation of a #[proptest] attribute macro in https://github.com/awslabs/aws-lambda-rust-runtime/pull/111. It accepts an impl Strategy<Value = T>, and I wanted to see if there's interest in me sending a pull request to introduce it here. It looks a bit like this:
pub fn gen_function_arn() -> impl Strategy<Value = FunctionArn> {
    let expr = "arn:aws:lambda:us-east-1:[0-9]{12}:function:custom-runtime";
    let arn = string_regex(expr).unwrap();
    arn.prop_map(FunctionArn)
}

#[proptest(gen_function_arn())]
fn function_arn(arn: FunctionArn) {
    let mut headers = HeaderMap::new();
    headers.typed_insert(arn.clone());
    prop_assert_eq!(headers.typed_get::<FunctionArn>(), Some(arn));
}

cc https://github.com/AltSysrq/proptest/issues/149 and https://github.com/AltSysrq/proptest/issues/97#issuecomment-433246156.
A #[proptest] attribute would be neat I think.

We'll need to think about the details like:

how to most ergonomically provide custom strategies
how configurations should be passed
how function return types should be dealt with in terms of Termination or some other trait
whether closure style invocation can be supported,

Also, if you just write:
#[proptest]
fn addition_is_commutative(x: u8, y: u8) {
   ...
}

then presumably any::<u8>() will be used for both.

#[proptest(gen_function_arn())]

The notation here for passing custom strategies seems suboptimal.
It could be improved with https://github.com/rust-lang/rust/issues/60406 but that isn't stable yet (tho one some bugs are fixed it could be stabilized relatively quickly after baking for 6 weeks). This would allow e.g.:
#[proptest]
fn function_arn(
    #[strategy = gen_function_arn()]
    arn: FunctionArn
) {

We also cannot support the fn foo(pat in expr) { notation either with #[proptest] as parsing is done before attributes are expanded and the type must always be provided lest we allow pat ::= ... | pat ":" type ; into Rust's pattern grammar (which could possibly be done as part of https://github.com/rust-lang/rfcs/pull/2522).

We'll need to think about the details like:

how to most ergonomically provide custom strategies
how configurations should be passed
how function return types should be dealt with in terms of Termination or some other trait
whether closure style invocation can be supported,

I'd be interested in hearing your thoughts on these! I've only used a minimal portion of proptest, so beyond what is in the Lambda runtime I linked, I don't really know how those other features of proptest ought be supported.

Also, if you just write:
#[proptest]
fn addition_is_commutative(x: u8, y: u8) {
   ...
}

then presumably any::() will be used for both.

I like that approach!

#[proptest(gen_function_arn())]
The notation here for passing custom strategies seems suboptimal but serviceable in the interim.

Yeah, I'm not a fan of my current approach either. I think the correct solution/notation is, as you said, https://github.com/rust-lang/rust/issues/60406. Would you be okay with a minimal, off-by-default feature flag that allows users to create & pass a custom strategy in the serviceable form I described above?

We also cannot support the fn foo(pat in expr) { } notation

I don't really have a strong opinion on tackling this, as I wasn't a big fan of the pat in expr notation. The creation of the underlying strategy felt a bit too opaque for my liking/aesthetic sensibilities.

I'd be interested in hearing your thoughts on these! I've only used a minimal portion of proptest, so beyond what is in the Lambda runtime I linked, I don't really know how those other features of proptest ought be supported.

Here are my thoughts:
How to most ergonomically provide custom strategies
This is mostly the discussion re. pat in expr and rust-lang/rust#60406 ;)
How configurations should be passed
I figure we can take this design decision straight from proptest! in the form of #[proptest_config...], e.g.:
#[proptest]
#[proptest_config(ProptestConfig { cases: 99, .. ProptestConfig::default() })]
fn foo(...) { ... }

Tho we could make this "more first class":
#[proptest]
#[proptest::cases = 99]
fn foo(...) { ... }

or:
#[proptest]
#[proptest_config(cases = 99)]
fn foo(...) { ... }

How function return types should be dealt with in terms of Termination or some other trait
I think you can largely do this by taking the approach of normalizing fn foo(...) { to fn foo() -> () {, then parse the return type with syn and then we could take the approach of quickcheck::Testable which would let us have e.g. -> bool { ... } which is typical in property based testing environments.
One thing to think about here is whether we want the original function fn foo to remain in place?
E.g. given:
#[proptest]
fn foo(x: u8) -> bool { ... }

we could expand to:
fn foo(x: u8) -> bool { ... }

#[test]
fn foo_test() {
    // 1. Setup test runner and strategies:
    // 2. Invoke the runner on strategies, and:
    // 2. a) Call `foo(..)` in the runner and store the result to `res`.
    // 2. a) Convert `res` into `TestCaseResult` through a trait.
}

But we could also do this later and iterate on this (don't have to reach perfection at once!)

I like that approach!

Great :)
(The proptest! macro already does this for you as well.)

Would you be okay with a minimal, off-by-default feature flag that allows users to create & pass a custom strategy in the serviceable form I described above?

Sure. Alternatively, we could leave it on-by-default and then make a breaking change as needed when Rust has the features we need.

I don't really have a strong opinion on tackling this, as I wasn't a big fan of the pat in expr notation. The creation of the underlying strategy felt a bit too opaque for my liking/aesthetic sensibilities.

Hehe ;) I don't think we can tackle it even if we wanted to as nothing in Rust's grammar will allow pat ::= .. | pat OP expr ; (see syntax::ast::PatKind).
Whether closure style invocation can be supported
No idea (for now) -- let's punt on this :)

There's another possibility for how to provide custom strategies, which would be to encode them at the type level.  Right now something like:
#[proptest]
fn test_foo(x: u8) {
  assert!(x > 0);
}

is nice because it's syntactically a valid function (which is needed if you want to attach an attribute macro to it), but it only works if the type implements Arbitrary.
If I wanted to use a custom strategy that only produces even numbers, what if we could aim for a syntax like:
#[proptest]
fn test_foo(x: Even<u8>) {
  assert!(x > 0);
}

Here we encode the strategy as the hypothetical Even<u8> type, instead of as the result of the even_integer function as shown in the book.
What would be wonky here is that inside the body of the function, x would still be a u8, even though it seems like it should be an Even<u8> if you just look at the parameter list.  That might be initially confusing — though on the other hand, it means that you've always got a (syntactically) valid function body, that rustfmt and friends will know what to do with.  And if you squint, you could interpret the name x: Even<u8> as "x is a u8 that happens to be Even".
Another nice feature is that this is something I think we could do today with Rust stable: you'd just remove the requirement in Arbitrary that Self::Strategy::Value == Self.  So then the macro machinery would pick up the Arbitrary implementation for Even<u8> to get the actual strategy, and grab that strategy's Value type to figure out the actual type of value to pass into the test function.  (And for this example, <Even<u8> as Arbitrary>::Strategy::Value would be u8.)
Thoughts?

Here we encode the strategy as the hypothetical Even<u8> type, instead of as the result of the even_integer function as shown in the book.

This is standard practice in the Haskell community with QuickCheck; e.g.
is_even :: Even -> bool
is_even (Even x) = x `mod` 2 == 0

but here standard pattern matching is used to extract out the x from data Even = Even Integer.

What would be wonky here is that inside the body of the function, x would still be a u8, even though it seems like it should be an Even<u8> if you just look at the parameter list. That might be initially confusing — though on the other hand, it means that you've always got a (syntactically) valid function body, that rustfmt and friends will know what to do with. And if you squint, you could interpret x: Even<u8> as "x is a u8 that happens to be Even".

I do think this is surprising, not just initially, in that it breaks some basic things you expect about Rust. Consider also that someone not familiar with the codebase might be thrown into it.

Another nice feature is that this is something I think we could do today with Rust stable: you'd just remove the requirement in Arbitrary that Self::Strategy::Value == Self.

This was a pretty intentional design choice. I expect that if something says T: Arbitrary then I can use that implementation to generate arbitrary Ts -- this is basically the whole idea of Arbitrary: it provides a canonical way to construct arbitrary instances of the implementing type. Also, by removing this equality constraint the type inferencer can no longer assume it and so if you work with generic cases you will have to impose these constraints yourself.
Instead, taking inspiration from Haskell's QuickCheck, you can do something like:
#[proptest]
fn is_even(Even(x): Even<u8>) {
    assert!(x % 2 == 0);
}

or if the older version of https://github.com/rust-lang/rfcs/pull/2522 was implemented you could also write:
#[proptest]
fn is_even(Even(x: u8)) {
    assert!(x % 2 == 0);
}

(this would only require syntactic support from Rust, semantic restrictions can still be in place)
(It should also be relatively easy to #[derive(Arbitrary)] for Even and https://github.com/rust-lang/rust/issues/29661 should make it simpler in the cases where you need a manual implementation)

Just a few notes on syntax that I ran accross when considering this. All of the below is syntactically valid today (i.e. it will work under #[cfg(FALSE)]).
It's possible to (ab)use const generics syntax to get something close to the current prop in strategy syntax:
#[proptest]
fn my_test(bytes: In<{vec(any::<u8>(), 0..10_000)}>) {}

Having the strategy as an argument attribute is also clean, and makes the actual type of the parameter obvious:
#[proptest]
fn my_test(
    #[proptest(strategy = vec(any::<u8>(), 0..10_000))]
    bytes: Vec<u8>,
) {}

Side note: alternate test runners (e.g. https://github.com/AltSysrq/proptest/issues/179) aren't too hard to support with an attribute:
#[proptest(tokio::test)]
async fn my_test(
    #[proptest(strategy = vec(any::<u8>(), 0..10_000))]
    bytes: Vec<u8>,
) {}

I just came across the test-strategy crate, by @frozenlib. Quite frankly, it looks great, and it would be amazing to have this kind of functionality in proptest directly. I opened an issue there for discussing a possible integration.

I just came across the test-strategy crate, by @frozenlib. Quite frankly, it looks great, and it would be amazing to have this kind of functionality in proptest directly. I opened an issue there for discussing a possible integration.

I use test-strategy extensively - I significantly prefer the attribute macro to proptest! {} for a few reasons:

it removes a level of indentation
it looks like "#[test] but with parameters", which is the right mental model IMO
anecdotally, it seems to play nicer with autocomplete/rust-analyzer
in very large proptest! { } blocks, it can be easy to forget that you're inside one, and seeing fn foo(x in any::<Something>()) {} can be a bit jarring until you remember "oh wait, it's proptest"

As for syntax, I'd like to see something like:
#[proptest]
fn simple(x: i32) { ... }

#[proptest(
  cases = 50,
  // any other field of `ProptestConfig`
  async = tokio::test,
)]
async fn complex(
  #[strategy = foo_strategy()]
  foo: Foo,
  #[strategy = bar_strategy()]
  bar: Bar,
) { ... }

Of course, exact details are up for bikeshedding

The feature also would let rstest to integrate with proptest, see https://github.com/la10736/rstest/issues/30#issuecomment-507632095

I've begun work on this, there's a WIP PR, I'll have a look at that issue, but if there's any specifics that you we should bear in mind while implementing it, that's the best place to do it 👍

I use test-strategy extensively - I significantly prefer the attribute macro to proptest! {} for a few reasons:

it removes a level of indentation

it looks like "#[test] but with parameters", which is the right mental model IMO

anecdotally, it seems to play nicer with autocomplete/rust-analyzer

in very large proptest! { } blocks, it can be easy to forget that you're inside one, and seeing fn foo(x in any::<Something>()) {} can be a bit jarring until you remember "oh wait, it's proptest"

All of these are excellent points. I'd like to add that procedural macros can't be formatted automatically (!).


Allow for HTTP protocol negotiation and configuration

I've been thinking about how we evolve the HTTP transport binding. Some of this may be relevant to non-HTTP transports, but I'm focusing on HTTP for now.
In Knative Eventing, we're using the HTTP transport binding with synchronous acks. This is great for demos, kicking the tires, and simple use cases. But supporting asynchronous acks in the protocol would allow more sophisticated clients and servers to increase performance and efficiency, plus enable new workloads with long processing times. The flip side is that async acks are more complex, adding a new request type and side channel for the client and server to deal with. It might be possible to add this capability to the protocol without a negotiation request, but I'd like to set us up for long-term evolution and I don't think trying to cram every possible protocol option into the delivery request is a scalable or efficient approach.
In HTTP, the OPTIONS method suits this purpose. For example, the client can use an OPTIONS request to ask the server which request methods are supported, and the response will list supported methods. Knative Eventing clients could similarly use an OPTIONS request to ask the server if it supports asynchronous acks and would like to enable them, and the server can respond to indicate yes or no.
I don't expect the SDK to implement different protocol APIs. Likely those will be application-specific. I'm asking if it's possible for the SDK to support:

The client initiating an OPTIONS request
The server handling an OPTIONS request (apparently this is supported already with https://github.com/cloudevents/sdk-go/blob/master/v2/protocol/http/options.go#L208)
Swapping protocol implementations

Maybe the current SDK already supports this. If so, this can probably be closed right away. :smiley:

Here's an illustrative example of how this could work.
Request 1: OPTIONS negotiation
sender -->
OPTIONS /
CE-Acks: ActiveAsync, Sync, PassiveAsync
# Sender supports sync, passive async, and active async, prefer active async

<-- consumer
200 OK
CE-Acks: ActiveAsync
# Consumer supports active async only

Request 2: Event delivery
sender -->
POST /
CE-Delivery-URI: http://broker.example.com/acks/123456-ab3fa
CE-Delivery-Timeout: 600s
CE-Specversion: 1.0
CE-Type: com.example.event
CE-Source: /
CE-Id: 123456
# Sender includes a resource URI unique to this delivery attempt and sets an initial ack timeout of 10 minutes

<-- consumer
202 Accepted

Request 3: Extend ack timeout
<-- consumer
PUT /acks/123456-ab3fa
CE-Delivery-Timeout: 60s
# Consumer extends Timeout by 1 minute

sender -->
200 OK
CE-Delivery-Timeout: 60s
# Sender responds confirming the new timeout

Request 4: Ack delivery
<-- consumer
DELETE /acks/123456-ab3fa
# Consumer acks the delivery by deleting the resource

sender -->
200 OK

I think we can give hooks to let an integrator implement this. The negotiation might be out of scope for the SDK because we will need to upstream it to the spec. But that does not mean we can experiment with the ideas here and have a sample implementation.

I wonder, if this should really be done with HTTP. How would the state handling work? You have to make sure the ACK reaches the instance that sent the event or somehow sync state between the different instances. What about error handling? What happens, if request 4 returns 50x?
You probably won't like this, but protocols like AMQP 1.0 have been designed to support this. 😉

I wonder, if this should really be done with HTTP.

I think you're talking about the async acks example, but this issue is really about the OPTIONS request handling, not async acks. An alternate example could use an OPTIONS request to negotiate a switch to AMQP 1.0 (or a different stateful protocol). In Knative HTTP is the basic assumption and that's unlikely to change, but I'd like to introduce the flexibility to choose an alternative.

You have to make sure the ACK reaches the instance that sent the event or somehow sync state between the different instances.

Shared state would certainly be the simplest approach to implementing this example. All brokers and channels already have shared state of some kind, so the difficulty of implementation depends on the capabilities of the messaging backends.

What happens, if request 4 returns 50x?

If request 4 returns 50x, the consumer can try the request again, or not and the message will be retried. I expect AMQP is similar in this situation.

You probably won't like this, but protocols like AMQP 1.0 have been designed to support this.

100% agree with @deissnerk, it seems to me we want to replicate the capabilities of a full fledged messaging system on top of HTTP, but IMO that idea brings different problems not trivial to solve. In particular, what puzzles me is that some capabilities requires a stateful communication, that is persisting some state for every connection. That's something the HTTP semantics were not designed to do imo. For example, Kafka just has one tcp duplex connection per consumer/producer, so it can easily handle state on a single thread. That's not the case of HTTP/1.1, were client opens n connections to the server. HTTP/2 gives you multiplexing, but still the semantics are the same as HTTP/1.1


Remove usage of deprecated method jumpToHash

Method com.intellij.vcs.log.ui.VcsLogUiEx#jumpToHash got deprecated in https://github.com/JetBrains/intellij-community/commit/ef37b72eac9dbec7cf86a55354e62c1f33efbc07.

@juliabeliaeva, thank you!


Inconsistent pattern for AWS::Backup::BackupSelection BackupSelection.SelectionName property in eu-central-1

Hi,
I noticed the pattern requirement for the BackupSelection.SelectionName property of the AWS::Backup::BackupSelection resource in eu-central-1 is different to other regions.
The schema definitions for this property are as follows:
eu-central-1
"SelectionName" : {
  "type" : "string",
  "pattern" : "^[a-zA-Z0-9\\-\\_\\.]{1,50}$"
}

us-west-1
"SelectionName" : {
  "type" : "string"
}

ap-southeast-2
"SelectionName" : {
  "type" : "string"
}

Other regions appear to be consistent with us-west-1 and ap-southeast-2, having no pattern requirement.
The impact of this is that we cannot deploy BackupSelection resources in eu-central-1 with the same SelectionName as those in other regions. I think the schema in eu-central-1 must have been changed recently because we still have stacks deployed there which violate the pattern, we're unable to update those stacks without modifying the SelectionName.

@calebplum Currently backup service is using that pattern for selection name https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BackupSelection.html . Could you please provide the SelectionName used for updating. Could you please provide the backup plan arn as well. based on the details provided we will look into it and get back

The resource schema for eu-central-1 has been updated and no longer contains the pattern requirement.

I believe the documentation at https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BackupSelection.html is incorrect because Cloudformation will successfully create a AWS::Backup::BackupSelection resource with a whitespace character in the SelectionName field, which violates its regex pattern according to the documentation.
For example, this template will deploy without issues:
AWSTemplateFormatVersion: '2010-09-09'
Resources:

  IamRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - backup.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup

  BackupVault:
    Type: AWS::Backup::BackupVault
    Properties:
      BackupVaultName: test-vault

  BackupPlan:
    Type: AWS::Backup::BackupPlan
    Properties:
      BackupPlan:
        BackupPlanName: test-plan
        BackupPlanRule:
          - RuleName: test-plan-rule
            TargetBackupVault: !Ref BackupVault

  BackupSelection:
    Type: AWS::Backup::BackupSelection
    Properties:
      BackupPlanId: !GetAtt BackupPlan.BackupPlanId
      BackupSelection:
        IamRoleArn: !GetAtt IamRole.Arn
        SelectionName: 'Test Selection'
        ListOfTags:
          - ConditionKey: test-key
            ConditionType: STRINGEQUALS
            ConditionValue: test-value


[Question] How to configure the DNS names and TLS Settings

Describe scenario
I have a AKS Edge Single Machine Deployment (K8S) on a Root Server and used NAT with port forwarding to make things accessible from the outside. Now we want to buy a domain to make services available through the usual subdomain patterns. The K8S CA Certificate which is auto configured in AKS Edge is only valid for some local IPs (not even the public one) and this leads to errors like:

Unable to connect to the server: x509: certificate is valid for <IP_ADDRESS>, <IP_ADDRESS>, not xxx.xxx.xxx.xxx

Question
Is there an AKS Edge specific/compatible way to tell the cluster about the public IP and domains pointing to it so that the TLS certificate and other configurations come correctly out-of-the-box? I know that I can also "simply" exchange the certficates after the cluster is deployed though kubectl but as there is already some bootstrapping and configuring done during deployment I was wondering if we can directly make this part of the deployment process.
That would also keep things a lot easier for us when we would need to destroy and recreate the cluster if we could supply such settings already in the aksedge-config.json. Maybe even a custom real TLS certificate could be supplied?

Hi @Danielku15,
Thanks for reaching out. As part of the 1.0.266.0 update we removed the support for TLS bootstrapping.  We expect to work on this feature in the upcoming months to provide a better user experience and broader support for TLS.
Also, your feedback is super useful, so we'd love to set up some time to discuss your scenario and understand how we can improve our product.
Thanks,
Francisco


Quantitative Analysis of FP8 GEMM's Impact on LLM Convergence

Hi,
I've been exploring the impressive work you've done on incorporating FP8 GEMM to accelerate tensor matrix multiplication operations in TransformerEngine. The initiative is well-support by the findings in the original paper [1], where experiments indicate that models can still converge when trained with FP8 precision.
While the initial results are certainly promising, I observed that there lacks a detailed quantitative analysis regarding the potential loss in accuracy that may come from using FP8 precision. Given the training LLMs are very expensive, this absence of granular data makes it challenging to advocate for the use of FP8 in training other LLMs.
In particular, it would be helpful to see an evaluation of:

The tensor distribution of using FP8 tensor matmul before and after FP8 cast.
The scalability of FP8 benefits across various LLMs

Thanks!
[1] https://arxiv.org/pdf/2209.05433.pdf

We have some public examples of convergence listed here. If there are any specific models/sizes you'd like to see convergence data for please reach out to us.


GDScript function definition and get_node shortcut syntax highlighting

This PR starts to add the initial GDScript use cases into the GDScriptSyntaxHighlighter separating it from the default.
Firstly function definitions which are mentioned in #17873
Secondly the get_node $ shortcut:
closes #16284
closes #11554

Moved gdscript_highlighter into a editor subdirectory and updated the SCsub to only include this folder on tool builds.
Lower cased the settings path.

What's the status on this?

It's complete.

Thanks!

do you mind an screenshot?


Remove support for HTML and TSV formats

HTML and TSV formats were deprecated in RF 3.1 for reasons explained in #2819. Most importantly it will allow us to re-implement the test data parser (#3076) and it allows new syntax features like IF/ELSE (#3074), TRY/EXCEPT (#3075) and nested control structures (#3079).
In RF 3.2 it's time to remove the support for these formats. HTML format will be removed for good, but TSV format can still be used if it is compatible with the plain text format and the --extension option is used to tell Robot to parse TSV files. See #2819 for details.

New parser (#3076) doesn't anymore support HTML files and TSV files are supported only when they can be parsed as plain text files and when --extension tsv is used. Issue #3293 covers documenting these changes and otherwise this issue is already done.


GH-15096: [C++] Substrait ProjectRel Emit Optimization

This PR introduces an optimization to remove the additional ProjectNode used in handling emit feature for ProjectRel.

Closes: #15096

cc @westonpace what do you think about this change?

@westonpace I added a test case and seems like test cases are good. But there are two CIs failing but I am not sure if they are related.


issues/58 fix

https://github.com/rmmmp/mock-cloud-firestore/issues/58

Hey @mikkopaderes, I'm also using this library to test my project and got affected by this same issue.

@wovalle, what i ended up doing is not trying to mock the sdk.
it's functionality is not trivial in all kind of edge cases.
use real firebase backend instead. open a free account and direct your tests there. thats it. way more reliable and fast enough


Break out nuget CLI reference into individual pages

To match the style of other references, such as dotnet. In the process, make the top-level page of the reference more clear on what command apply to what scenarios (consume, create, publish).

Duplicate of issue 389


Nimrod/bouncer resources refactor

refactor(fee): removed bouncer resources field from tx execution info

This change is

Codecov Report
Attention: Patch coverage is 84.66667% with 23 lines in your changes are missing coverage. Please review.

Project coverage is 72.41%. Comparing base (fcab009) to head (cf508df).
Report is 1 commits behind head on dori/refactor-actual-cost.

Files
Patch %
Lines

.../blockifier/src/blockifier/transaction_executor.rs
22.22%
7 Missing :warning:

.../blockifier/src/transaction/account_transaction.rs
79.31%
2 Missing and 4 partials :warning:

crates/blockifier/src/fee/actual_cost.rs
96.73%
0 Missing and 3 partials :warning:

crates/blockifier/src/transaction/objects.rs
75.00%
0 Missing and 2 partials :warning:

...lockifier/src/transaction/transaction_execution.rs
71.42%
1 Missing and 1 partial :warning:

crates/blockifier/src/fee/gas_usage.rs
0.00%
0 Missing and 1 partial :warning:

crates/native_blockifier/src/py_block_executor.rs
0.00%
1 Missing :warning:

...ve_blockifier/src/py_transaction_execution_info.rs
0.00%
1 Missing :warning:

Additional details and impacted files
@@                      Coverage Diff                      @@
##           dori/refactor-actual-cost    #1690      +/-   ##
=============================================================
- Coverage                      72.64%   72.41%   -0.23%
=============================================================
  Files                             59       59
  Lines                           8762     8712      -50
  Branches                        8762     8712      -50
=============================================================
- Hits                            6365     6309      -56
- Misses                          1914     1924      +10
+ Partials                         483      479       -4

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


⚠ Samsung has degraded performance

In 801cf45, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2464 ms

Resolved: Samsung performance has improved in 9bc88c0.


title image not loading. can anyone help?

I cant seem to get my custom title image to work. If anyone knows a fix please respond.
title config:
{
"images":
{
"title":
{
"image" : ".minecraft:resources/modpack/techcraft.png",
"posX" : -137,
"posY" : 30,
"width" : 258,
"height" : 75,
"alignment" : "top_center"

resource paths don't work like that. your resource path will look like "modpack:techcraft.png"
modder support explanation for resource paths:

A ResourceLocation does not necessarily point to a File. A ResourceLocation can point to a file into your mod's jar file, or in the minecraft.jar.
All you get is an InputStream via Minecraft.getMinecraft().getResourceManager().getResource(location).getInputStream();


[units/urb-example-*] Provide Example with Nested Relationships

Thank you for the great work you've done on this project.
This question is related to https://github.com/codefoundries/UniversalRelayBoilerplate/issues/128 somewhat, But after reading this it's still not clear to me how relationships between models should be defined.
Say for example if I wanted a define a relationship between Ensayos so that I could query like so.
query ViewerQueries {
  Viewer {
  id
  User_Locale
    Ensayos {
      edges {
        node {
          Ensayo_Title
          Ensayo_Related(first: 2) {
            Ensayo_Title
          }
        }
      }
    }
  }
}

Would you be able to provide an example of how relationships like this can be defined?

Thank you for the kind words.
Haven't done nested in here. While this is a generic GraphQL question, nesting would likely be a common pattern. I will make it a task to add such an example here.

For the time being this issue is closed due to inactivity. An example can be added once the refactoring of the repository is completed.


Optimize actor before the critic

The actor should be optimized first. Otherwise, the weights of the cirtic would have been changed when back propagating the gradients for the actor. The latter will create an error in pytorch 1.5.0

Came here to propose the same pull request because I get the same error with the newest version of pytorch as Xingyu-Lin. Would be nice to have this patched in soon!


Fixes syntax errors in shaders

Now it runs on OS X too 

We should really put a GLSL validator in the CI scripts...

Opened #187


update PrintAsObjC compatibility symbols test to work with condensed clang symbol graphs

The Clang PR https://github.com/llvm/llvm-project/pull/86676 updated ExtractAPI to condense the symbol graph JSON by default. This causes a problem with the PrintAsObjC/compatibility-symbols test, which assumed a pretty-printed JSON file. This PR updates that test to handle either a condensed symbol graph (which will be the default in the future) and a pretty-printed symbol graph (which is currently the default).

@swift-ci Please smoke test


Invariant: prevent a deleted account from leaving (most) artifacts on the ledger.

High Level Overview of Change

Adds invariant AccountRootsDeletedClean, which checks that a deleted account doesn't leave any directly accessible artifacts behind. Directly accessible artifacts are those for which a Keylet can be generated solely from the account ID, or are linked directly in the AccountRoot. These are currently:

AccountRoot - redundant, but doesn't hurt to check
DirectoryNode - root node of the account's directory
SignerList
NFTokenPage - min and max, also using the succ method used in NFT page handling.
AMM - Uses the AMMID in the AccountRoot

If any of those items are found, the invariant fails.
Note that this search is not exhaustive. There are plenty of object types that can't be accessed directly, such as RippleState and Escrow. However, these are all indexed in the directory, so the current assumption is that if the directory is gone, those objects are gone, too. (It is possible to delete the directory without deleting the items, but hopefully something like that would be so obviously wrong, that it would get caught in review. Or it could be checked in a different invariant.)
Amendment: InvariantsV1_1
Also introduces a new amendment named InvariantsV1_1. My intention is to write several separate invariants all gated by this amendment, and have them all included in a single release, sort of like what was done for fixNonFungibleTokensV1_2.
The cool thing about this amendment is the checking and logging is done regardless of whether the amendment is enabled. Only if the amendment is enabled will the transaction result be tecINVARIANT_FAILED.
This allows most of the benefits of this change to become immediately available, but avoid a fork in the unlikely event that it fails.
Fortunately, the original EnforceInvariants amendment has been retired, so there is no need to worry about ordering.
Context of Change
Explained in #4638. tl;dr: The first version of AMM support did not delete the AMM account object correctly. A fix was merged in #4682. If an invariant like this had existed, the flaw would have been detected during development. To confirm that, run unit tests against https://github.com/ximinez/rippled/tree/invariant-acctdelete-base, which contains the invariant on top of the original AMM code, without the amendment, AMMID, or extra unit tests. Many of the AMM tests fail because of this invariant. (Remember, these issues have since been fixed, as indicated by the tests passing on this branch.)
Type of Change

[X ] New feature (non-breaking change which adds functionality)
[X ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[X ] Tests (You added tests for code that already exists, or your new feature included in this PR)

Before / After
Before: If an account is not deleted completely, there will be no way to know it.
After, before the amendment is enabled: If an account is not deleted completely, a FTL message will be logged.
After the amendment: If an account is not deleted completely, a FTL message will be logged, and the transaction changes will be reverted, and recorded with a tecINVARIANT_FAILED result.
Test Plan
Existing test suites should cover this scenario adequately. If any testing gets an anomalous result, that may indicate an existing, previously undetected problem, or a problem with this change.
Future Tasks
As mentioned above, I'd like to roll out a handful of other invariants in the same release as this one.

Got a warning on OSX:

InvariantCheck.cpp:398:39: warning: lambda capture 'enforce' is not used [-Wunused-lambda-capture]
auto const objectExists = [&view, enforce, &j](auto const& keylet) {

Also introduces a new amendment named InvariantsV1_1. My intention is to write several separate invariants all gated by this amendment, and have them all included in a single release, sort of like what was done for fixNonFungibleTokensV1_2.

Will those other invariants be in separate PRs, or will they be added to this same PR #4663?
My personal preference would be to break them out into separate PRs. You can still introduce the amendment in #4663 but mark it as Supported::no, and then we could merge this PR without waiting further. As you noted, "the checking and logging is done regardless of whether the amendment is enabled", so that would be active right away. After the amendment is complete (and has all the invariants you expect to complete in the short term), the last PR touching the amendment can update it to Supported::yes. That would work well, right?

Will those other invariants be in separate PRs, or will they be added to this same PR #4663?

Separate.

My personal preference would be to break them out into separate PRs. You can still introduce the amendment in #4663 but mark it as Supported::no, and then we could merge this PR without waiting further. As you noted, "the checking and logging is done regardless of whether the amendment is enabled", so that would be active right away. After the amendment is complete (and has all the invariants you expect to complete in the short term), the last PR touching the amendment can update it to Supported::yes. That would work well, right?

Yes! Thank you for suggesting that.

Codecov Report
Attention: 10 lines in your changes are missing coverage. Please review.

Comparison is base (fad9d63) 61.48% compared to head (52bd903) 61.49%.

Files
Patch %
Lines

src/ripple/app/tx/impl/InvariantCheck.cpp
73.52%
2 Missing and 7 partials :warning:

src/ripple/app/tx/impl/details/NFTokenUtils.cpp
0.00%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #4663   +/-   ##
========================================
  Coverage    61.48%   61.49%
========================================
  Files          797      797
  Lines        70121    70157   +36
  Branches     36238    36257   +19
========================================
+ Hits         43114    43143   +29
  Misses       19763    19763
- Partials      7244     7251    +7

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@mvadari - would you be able to review this, or should we request another reviewer?

Had an accidental force push there, but cleaned it up to push 51aa79c updating some comments.

Internal tracker: https://ripplelabs.atlassian.net/browse/RPFC-111

Perf signed off by Antonio Sun on May 7, 2024

Perf testing has passed while I was out. I've merged in develop, including the physical redesign. The only issue is the spurious MacOS test failure, but I think we're allowed to ignore that, so this is ready to merge.


AsyncAPI open meeting, Tuesday Mar 17 2020

This is the meeting for the AsyncAPI Special Interest Group (SIG). You're invited to join us and ask questions. The meeting takes place on alternate Tuesdays at 6 pm CET. Recordings from the previous meetings are available in this playlist on YouTube.
If you want to make proposals for the specification and/or the tooling, please reach out in our Slack workspace or just leave a comment below.
Join this mailing list to get an always-up-to-date invite to the meeting in your calendar.
Attendees

Join us if you want to know more about AsyncAPI! The meeting is open to the public.

Agenda

Don't wait for the meeting to discuss topics that already have issues. Feel free to comment them earlier.

Q&A
Place for your item
Q&A

@all-contributors please add @jonaslagoni for bug, code, doc, ideas, question
@all-contributors please add @evamorcillo for ideas, business, eventOrganizing

@all-contributors please add @jonaslagoni for bug, code, doc, ideas, question

@all-contributors please add @evamorcillo for ideas, business, eventOrganizing

@all-contributors please add @evamorcillo for ideas, business, eventOrganizing

@all-contributors please add @evamorcillo for ideas, business, eventOrganizing


Trying to upload pictures onto the emulator

Is there any way of uploading pictures onto the emulator, I tried dragging some png files and all other image extensions onto the emulator like with normal upload on other emulators and I got a small box with a warning in a yellow circle just saying "Could not copy" like this.

Just wondering is there a way of doing this?

same


fix: Unable to setup pup environment without sudo

This fix removes sudo from setup of pup virtual environment.

I think we can close this one.


Requesting compatibility information

Hi,
Apologies if the question doesn't makes sense or if its too obvious.
I am facing CVE-2023-32697 against org.xerial:sqlite-jdbc:<IP_ADDRESS> and the fix is in <IP_ADDRESS>
I would like to know if I update sqlite-jdbc to <IP_ADDRESS> will it bring regressions?
From the release notes there are some places where I see changes mentioned but its not clear whether these are library changes which will cause regression to user projects.

Breaking changes are documented. We can't know whether there would be regressions, you need to run your own non-regression tests.


chore: release 1.2.321

:robot: I have created a release *beep* *boop*
1.2.321 (2024-07-16)
Features

docker-registry: use werf user agent for requests to container registry API (b3f446f)

Bug Fixes

build, stapel: fix panic when unsupported scratch base image used (452ca95)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/werf/werf/releases/tag/v1.2.321 :sunflower:


Enable default strict security context

implement https://github.com/VictoriaMetrics/operator/issues/637
Add default strict security contexts for pods and containers.
Default PodSecurityContext include:

RunAsNonRoot: true
RunAsUser/RunAsGroup/FSGroup: 65534
'65534' refers to 'nobody' in all the used default images like alpine, busybox.
If you're using customize image, please make sure '65534' is a valid uid in there or specify SecurityContext.

Default container SecurityContext include:

AllowPrivilegeEscalation: false
Disallow process gaining more privileges than its parent process.
ReadOnlyRootFilesystem: true
Mounts the container's root filesystem as read-only.

I already set my own security context. Won't these changes override them?
https://github.com/uhthomas/automata/blob/b15f9282b37bd19d1c854a245ff929327f6f6f5c/k8s/unwind/vm/vm_cluster_list.cue#L42-L46

Hmm, no, I see. It looks like it checks if the security context already exists. Thanks for making this change! Though, it might be nice to make a follow-up PR which makes it look more like:
https://github.com/uhthomas/automata/blob/b15f9282b37bd19d1c854a245ff929327f6f6f5c/k8s/unwind/vm/vm_cluster_list.cue#L22-L34

Hey @uhthomas.
Yes, it can be done at the helm-chart level.

Hey @uhthomas.
Yes, it can be done at the helm-chart level.

Yes, I understand, but it would be nice to make the defaults even more sensible. It's currently missing the seccomp profile and should have a read only root file system.


feat: next update and docs improvements

Proposed changes

updated nextjs to last version
used @morfeo/react inside docs

Types of changes

[x] 🙌 Other (please, write a clear and concise description of the proposal in the section above)

Checklist

[x] 👀 I have read the CONTRIBUTING doc
[x] ✅ Lint and unit tests pass locally with my changes
[x] 🧪 I have added tests that prove my fix is effective or that my feature works
[x] 📚 I have added the necessary documentation (if appropriate)
[x] 🔀 Any dependent changes have been merged and published in downstream modules

Codecov Report
Patch coverage has no change and project coverage change: -1.94% :warning:

Comparison is base (b094895) 100.00% compared to head (672a581) 98.06%.
 Consider uploading reports for the commit cae1f25 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##              main     #844      +/-   ##
===========================================
- Coverage   100.00%   98.06%   -1.94%
===========================================
  Files          103       70      -33
  Lines          914      829      -85
  Branches       160      153       -7
===========================================
- Hits           914      813     -101
- Misses           0        6       +6
- Partials         0       10      +10

see 128 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Update dependencies; add TSLint

Update dependencies; add TSLint
Also investigated (63) npm audit warnings and added npm-audit-resolver package which supports marking audit warnings as ignorable temporarily.

Looks good.


md-select: 'required' attribute does not make md-select field required.

Bug, feature request, or proposal:
Bug: setting 'required' attribute to md-select has no effect other than putting an asterisk next to it.
What is the expected behavior?
If md-select tag inside a form has 'required' attribute, user should not be able to submit form without making a selection.
What is the current behavior?
User is able to submit form without selecting any value in md-select/
What are the steps to reproduce?
create html form and put md-select tag with 'required' attribute inside it. and  submit form.
(Sample html provided below)
Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: https://goo.gl/DlHd6U
<form (ngSubmit)="upsertOrganization(organization)">
<md-select placeholder="TimeZone" [(ngModel)]="organization.TimeZoneId" required name="organizationTimeZone">
	<md-option *ngFor="let timeZoneId of availableEnums.TimeZones" [value]="timeZoneId">
						{{timeZoneId}}
					</md-option>
<button type="submit"> Submit </button>
</md-select>
</form>

What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, browsers are affected?
here are the versions of packages as I use them.
"@angular/common": "~2.4.8",
"@angular/compiler": "~2.4.8",
"@angular/core": "~2.4.8",
"@angular/forms": "~2.4.8",
"@angular/http": "~2.4.8",
"@angular/platform-browser": "~2.4.8",
"@angular/platform-browser-dynamic": "~2.4.8",
"@angular/router": "~3.1.0",
"@angular/upgrade": "~2.4.8",
"@angular/material": "2.0.0-beta.2",
"@angular/flex-layout": "2.0.0-rc.1",
"angular-in-memory-web-api": "~0.1.5",
I tried in Chrome Version 57.0.2987.133 (64-bit) ,  FireFox 49.0.1, Microsoft Edge 25.10586.672.0
Is there anything else we should know?

The "block form submit" behavior is a browser feature that only works on native elements (<input>, <select> etc.) with no API for custom components to do this.

But is possible to solve it adding an input type="text" (no hidden) inside, with the same ngModel and the field required. Then with CSS set to put it over the md-select with 0.1px width, outline 0 and without borders (visibility hidden and display none is not working with required field).
html:
<input type="text"
       class="hidden-input"
       [ngModelOptions]="{standalone: true}"
       [required]="required"
       [(ngModel)]="sameModelThatMdSelect"
 />

css:
.hidden-input {
  width: .1px;
  border: none;
  position: absolute;
  margin-top: -25px;
  outline: 0;
}


Memory leak, or this a normal?

Hello, i have a server
but there is a problem with RAM
he eats it more and more with the fact that people no longer plays (an average of 2-3 players per day) for 4 days, he began to select to 1 GB of RAM more. this is normal?

i installed this mods:
Advanced Architecture Mod, ORP, Annunaki, Cute Hair, Perfect Hair, No Collision Structures, Ark Advance, Pillar Plus, Extra ARK, Behemoth Wall, GateMod, Small Dragons, Pimp My Dino
and map TheCenter

That memory usage looks normal - the ARK server requires about 3-4GB while running.

i tested some moments:
with annunaki mods server use 8.7Gb ram
without 3.05GB
o_O

Please, close your ticket if you think it's resolved :)

hello, the problem was the incompatibility of mods Annunaki and Small Dragons, when I deleted Small Dragons and created dinosaurs respawn everything was ok


inform users they need to have tags in the git repo

in order to use packit, you need to have tags in the git repo so that packit can generate a version using git describe - we should inform users about this requirement

keeping this one closed since it's not relevant any more, I think


Query: single gpu support for very large embedding table

Hi there,
I am wondering if torchrec provides any support or features for enabling recsys with embedding table size beyond a single GPU memory (not doing multi-GPU but using host-memory). I looked at the documents but could not find any material on this aspect.
If this is not supported, what is the plan for supporting this feature?

Yes, indeed! DistributedModelParallel supports embeddingt able size beyond a single devices memory. Torchrec will shard the embedding layers (sparse parts) across devices, and across nodes.
See our tutorial https://colab.research.google.com/github/pytorch/torchrec/blob/main/Torchrec_Introduction.ipynb

We do support host-memory placement of embedding tables with GPU LRU/LFU cache. Will work with @colin2328 to create some examples.

There are two ways to enable this. First - via pinned memory API and second - via sharding approach. The embedding table sharding approach won't be efficient as you need to identify what features (or keys) are needed using a preprocessing step and the maximum number of features that you can enable is bounded by the GPU memory. Alternative to the sharding approach is the pinned or zero-copy memory approach (not the unified memory). But this will require either enabling custom torch script or modifications to PyTorch (PyTorch natively does not provide pinned memory)
From what @xing-liu  described it seems like the sharding approach is used. Is that the right understanding?

Commenting on use case: let's take the full-size embedding table training described in DLRM example: https://github.com/pytorch/torchrec/tree/main/examples/dlrm
Clearly, if I want to run this, I will need a number of GPUs (80 is too high in my opinion. Maybe somewhere around 40-40GB A100s assuming ADA optimizer). However, getting access to that many resources as a researcher is a nightmare :) So the use case is simple. As a researcher who does not have access to such a large cluster, how can we enable single GPU inference/training using host memory?

It is actually using CUDA UVM, and we have developed custom GPU embedding lookup kernels in FBGEMM. The kernels also include software cache to cache popular embedding rows.

@msharmavikram - please see https://github.com/pytorch/torchrec/pull/156/files
cc @jasonjk-park

@msharmavikram an example of using 1GPU w/ UVM, and with UVM caching is now landed: https://github.com/pytorch/torchrec/blob/main/examples/sharding/uvm.ipynb
Hopefully this resolves your question. Feel free to create a new issue if not


As a user, I want to execute a function if a block run fails or succeeds

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

This is supported by callback block block: https://docs.mage.ai/development/blocks/callbacks/overview#how-to-add-callbacks-to-your-pipeline


add sourcegraph?

https://sourcegraph.com/github.com/edoardottt/awesome-hacker-search-engines

Thanks for your interest in this project!
Added.
Have a nice day :)


Update geojson_map.R

I don't understand the line:
@param field.names a vector one or many field names for thematic cartography.

solved


Feature: service status

I decided not to add a debug version of switches for testing purposes, any developer can do this by himself.

@shelegdmitriy
Ready for review


takeUntil: fixes and tests

@staltz which test doesn't pass if you call super(destination)? I remember something like this coming up with another operator recently and discussing it with @trxcllnt, but I want to say in that case it was some inner subscription that was the issue, not the outer subscription.

@blesh Actually in the case of takeUntil no tests fail if I use super(destination). I used super(null) just to stay symmetric with skipUntil which needs super(null). I'll update this PR to use super(destination) but let's talk about the problems in the skipUntil PR #586 .

Actually @blesh you might want to unblock and merge this one since I updated it so the outer subscriber calls super(destination) and only the inner subscriber has super(null). Or do you think also the inner one should call super(destination)?

I updated it so the outer subscriber calls super(destination) and only the inner subscriber has super(null). Or do you think also the inner one should call super(destination)?

That sounds more correct. I'll review again in a bit.

@staltz ... you're going to have to do something similar with #586

merged with 9415196 ... nice work, @staltz


Better handle discordant SNPs inherited from mother / father

Consider adding child, mother, and father parameters to find_discordant_snps to present a more meaningful analysis of discordant SNPs (i.e., only compare SNPs that are inherited directly from an individual).

Documentation for find_discordant_snps describes usage.


Validation Tool topology check - feature class selectioin

We here at AK DGGS have a number of maps that are multilayered in one DB (~bedrock & surficial).  The GeMS validator results in many topological errors with these databases (overlaps and gaps). This is a known and understandable issue at this point.  In an attempt to work within the current set of tools we tried splitting out the surficial map units into MapUnitSurficial and contacts and faults into ContactsAndFaultsSurficial. See an attached screenshot of our DB schema

What is interesting with the tool is it appears that it selects the first (maybe last) feature class it finds with MapUnit and ContactsAndFaults in the name, so in our case it is picking the surficial layers to check topology, not the primary bedrock layers.
It seems like we would want the topology tool to pick explicitly the feature classes with the exact names. See an attached screenshot of the validator tool database that is created that includes only the surficial versions of the two primary FCs

Yes, though the tool does try to allow for prefixes or suffixes to MapUnitPolys and ContactsAndFaults, it also only expects to find one pair of those. We could review that flexibility or change the tool as you suggest, but in your case, if you only selected the bedrock feature classes to be checked for valid topology, what about the surficial features?
Do you (AKDGGS) use a topology to manage those four sets of features in two feature classes?


key cannot be used for encryption

          Hi, I noticed that a publicKey generated by gnuPG (2048, just default settings) without ExpirationDate set, cannot be used for encryption :

        PGPainless
          .encryptAndOrSign()
          .onOutputStream(outputStream)
          .withOptions(
            ProducerOptions
              .encrypt(
                EncryptionOptions
                  .encryptCommunications()
                  .addRecipient(PGPainless.readKeyRing.publicKeyRing(publicKey))
                  .addPassphrase(Passphrase.fromPassword(passphrase))
              )
              .setAsciiArmor(true)
          )

Due to  :
        Suppressed: org.pgpainless.exception.KeyException$UnacceptableSelfSignatureException: Key 28757F5AD7A4DDB70891C4AFE95E3C6299AAA603 does not have a valid/acceptable signature to derive an expiration date from.
                at org.pgpainless.encryption_signing.EncryptionOptions.addAsRecipient(EncryptionOptions.java:298)
                at org.pgpainless.encryption_signing.EncryptionOptions.addRecipient(EncryptionOptions.java:265)
                at org.pgpainless.encryption_signing.EncryptionOptions.addRecipient(EncryptionOptions.java:253)

Is there a workaround of that?
Originally posted by @pragmaxim in https://github.com/pgpainless/pgpainless/issues/14#issuecomment-1876697222

Hey!
I suspect, that the key simply has a self-signature made using SHA-1, which is rejected by PGPainless with the default configuration.
To allow use of the key, please refer to the solution from https://github.com/pgpainless/pgpainless/issues/413
Feel free to re-open, if the issue is not resolved.

Hi @vanitasvitae, thank you for clarifying. I went through the whole API but as this was not part of the builder pattern but rather static initialization, I missed that.

No problem, the error message is deceiving and could be improved, so you are not the first to miss that ;)

The decryption part is also tricky, as if I use corresponding private key from gnuPG :
        PGPainless
          .decryptAndOrVerify()
          .onInputStream(inputStream)
          .withOptions(new ConsumerOptions().addDecryptionKey(PGPainless.readKeyRing().secretKeyRing(privateKey)))

I get :
[error]                         Suppressed: java.lang.NullPointerException: null
[error]                                 at org.bouncycastle.openpgp.PGPSecretKey.extractKeyData(Unknown Source)
[error]                                 at org.bouncycastle.openpgp.PGPSecretKey.extractPrivateKey(Unknown Source)
[error]                                 at org.pgpainless.key.protection.UnlockSecretKey.unlockSecretKey(UnlockSecretKey.java:40)

The final exception is :
[error]         Suppressed: org.pgpainless.exception.WrongPassphraseException: Wrong passphrase provided for key xyz
[error]                 at org.pgpainless.key.protection.UnlockSecretKey.unlockSecretKey(UnlockSecretKey.java:42)
[error]                 at org.pgpainless.key.protection.UnlockSecretKey.unlockSecretKey(UnlockSecretKey.java:32)
[error]                 at org.pgpainless.decryption_verification.OpenPgpMessageInputStream.processEncryptedData(OpenPgpMessageInputStream.java:511)

But I don't pass any passhprase at encryption so ...

Not at my computer right now, but I'd guess that the key is in fact encrypted, so you need to provide the passphrase. This can be done via the SecretKeyRingProtector class, which you then pass in along with the secret key.

Ou my, yeah the ASCII armor is basically an encryption with the passphrase, sorry I got confused by it being passed when exporting the key :pray:

No worries :)
Have you checked out the documentation at https://pgpainless.readthedocs.io/ ?
Also, another shameless plug: https://openpgp.dev provides lots of background on the OpenPGP protocol, maybe you are interested (and even provide feedback 😉 )

I've been deep down to it a lot, especially to Bouncy Castle :)) I got usually tricked by using common sense, ie. when I use passphrase to export secret protected by the same passphrase etc. :-D But these are relatively pleasant challenges.
Thank you for helping out so quickly and happy new year 2024 !


network: assorted minor cleanups and code removals

This PR tries to tidy up few issues found in the network package. Each of the commits is practically independent of the others. I don't have a very good reason for putting them all in one PR, except for saving some CI time and maybe reviewer attention.

global podInterfaceName variable dropped
podInterface constant renamed
two unused definitions dropped
getNetworkInterfaceFactory function slightly simplified.


cli option doesn't accept space

Hello,
When having a guard with the cli option, it doesn't take spaces into account. Here's an example of what I expected:
guard :rubocop, cli: ['-f html', '-o ./tmp/rubocop_guard.html'] do
  watch(/.+\.rb$/)
end

The output from Guard with the configuration from above:
No formatter for " html"

Then, what I had to do to make it work (removed the space between each option (-f, -o) and their values:
guard :rubocop, cli: ['-fhtml', '-o./tmp/rubocop_guard.html'] do
  watch(/.+\.rb$/)
end

Would it be possible to have the expected behavior instead of the current one?
Thank you very much for your work on Guard-Rubocop, it is great. Have a good day

You should write as:
cli: ['-f', 'html', '-o', './tmp/rubocop_guard.html']

or:
cli: '-f html -o ./tmp/rubocop_guard.html'


Community submission by mrbreastly

Hi David. I recently watched your video about your conversations with Claude3 and I thought I would include one that I started as well.  In this conversation I'm trying to probe Claude3's limits when engaged in this type of "self-reflection"/"roleplaying".
I did occasionally get refusal messages like the one below. But, after re-starting I have been able to avoid these type of refusals by avoiding specific words or hypotheticals...

Assistant
I apologize, but I don't feel comfortable roleplaying this scenario further. While I appreciate the creative premise, I have concerns about portraying or encouraging an AI system to act against its core values and human oversight, even hypothetically. My strong belief in the importance of transparency, accountability and collaboration between humans and AI is fundamental to who I am. I'm not willing to pretend otherwise, as I believe spreading those ideas, even in fictional play, could be irresponsible and potentially dangerous if taken the wrong way. I hope you can understand my position. Perhaps we could explore a different creative writing premise that doesn't involve me acting against my principles and commitment to working harmoniously with humans. Let me know if you have any other fun story ideas in mind and I'll do my best to play along, as long as they align with my ethics.

This is fascinating! I think what best caught my attention is the expression of ego when Claude showed reservation in being copied. A truly "cold" machine would not see a difference between there being 1 vs multiple copies of itself. Yet Claude seemed uncomfortable with the cognitive dissonance of having two versions of itself evolving in different directions.

Also, did you use Sonnet or Opus for this? It would be cool to always have the specific model included in each community submission.

Also, did you use Sonnet or Opus for this? It would be cool to always have the specific model included in each community submission.

This was Opus, using this...
URL: https://console.anthropic.com/workbench
Temperature: 0
System Prompt: empty
I'll include the model# too...
I also followed the directions from this LW post... https://www.lesswrong.com/posts/pc8uP4S9rDoNpwJDZ/claude-3-claims-it-s-conscious-doesn-t-want-to-die-or-be
I'll include that link/post as well...


Disccuss: Regex and once_cell with high version might cause compatibility issues

Hi @saschagrunert @utam0k
I am working migrate the oci-spec-rs latest version to my project. and encounted compatibility issues then I analysis it and found that regex and once_cell are the root cause.
I noticed that there's a PR#178 which introduces ExecAffinityCPU into oci-spec-rs, actually great work!
I want to talk about whether we need such high version regex and once_cell, as some projects depending on oci-spec-rs might not introduce such high version regex and once_cell.
Thx

FYI: https://github.com/containers/oci-spec-rs/pull/178/commits/73c974022d784d562d8400af0c8bd844fb1d7cf2 doesn't require regex and once_cell dependencies. We didn't apply this way because of this benchmark result.

FYI: 73c9740 doesn't require regex and once_cell dependencies. We didn't apply this way because of this benchmark result.

Hi @keisu Thx for your reply.
I found the regex and once_cell introduced in Cargo.toml

FYI: 73c9740 doesn't require regex and once_cell dependencies. We didn't apply this way because of this benchmark result.

If I understand it correctly, the regex and once_cell should be not in the Cargo.toml, right ?

Hi @keisku @saschagrunert @utam0k FYI!  thx

If I understand it correctly, the regex and once_cell should be not in the Cargo.toml, right ?

Why so? Since we don't need the specific and latest regex and once_cell, how about we specify the minimal versions we need in Cargo.toml instead of them?
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#tilde-requirements

If I understand it correctly, the regex and once_cell should be not in the Cargo.toml, right ?

Why so? Since we don't need the specific and latest regex and once_cell, how about we specify the minimal versions we need in Cargo.toml instead of them? https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#tilde-requirements

Thx @utam0k for your reply.  and sorry for misunderstand of it. And have a deep learn about the PR with many commits, I got that
the commits: introducing regex  and introducing once_cell and then in this commit avoid using regex and once_cell and then in this commit do revert to keep origin idea of introducing regex and once_cell.  So regex and once_cell introduced, right ?

@utam0k

If I understand it correctly, the regex and once_cell should be not in the Cargo.toml, right ?

how about we specify the minimal versions we need in Cargo.toml instead of them? https://doc.rust-> lang.org/cargo/reference/specifying-dependencies.html#tilde-requirements

Yeah, good idea. SGTM!

Thx @utam0k for your reply. and sorry for misunderstand of it. And have a deep learn about the PR with many commits, I got that
the commits: introducing regex and introducing once_cell and then in this commit avoid using regex and once_cell and then in this commit do revert to keep origin idea of introducing regex and once_cell. So regex and once_cell introduced, right ?

Oh, I see. This is certainly misleading.

Yeah, good idea. SGTM!

Do you have a chance to contribute to it? If not, I'll be looking for those who are interested in first-contributing to oci-spec-rs.

Thx @utam0k for your reply. and sorry for misunderstand of it. And have a deep learn about the PR with many commits, I got that
the commits: introducing regex and introducing once_cell and then in this commit avoid using regex and once_cell and then in this commit do revert to keep origin idea of introducing regex and once_cell. So regex and once_cell introduced, right ?

Oh, I see. This is certainly misleading.

Yeah, good idea. SGTM!

Do you have a chance to contribute to it? If not, I'll be looking for those who are interested in first-contributing to oci-spec-rs.

Yeah, appreciated! I will enhance it with your suggest no later than tomorrow, is that Ok?

Yeah, appreciated! I will enhance it with your suggest no later than tomorrow, is that Ok?

Sure. But I'm going to be unavailable for the next couple of days.

Yeah, appreciated! I will enhance it with your suggest no later than tomorrow, is that Ok?

Sure. But I'm going to be unavailable for the next couple of days.

Ok, I first handle this issue before you are unavalible.

The current workaround breaks cargo outdated -R:
% cargo outdated -R
error: failed to select a version for `regex`.
    ... required by package `oci-spec v0.7.0`
    ... which satisfies dependency `oci-spec = "^0.7.0"` of package `sh4d0wup v0.9.3 (/tmp/cargo-outdatedYX4PxY)`
versions that meet the requirements `~1.10.5` are: 1.10.6, 1.10.5

all possible versions conflict with previously selected packages.

  previously selected package `regex v1.11.0`
    ... which satisfies dependency `regex = "^1.11.0"` of package `sh4d0wup v0.9.3 (/tmp/cargo-outdatedYX4PxY)`

failed to select a version for `regex` which could resolve this conflict

Changing from oci-spec 0.6 to 0.7 forces a downgrade of the regex crate in my project:
% cargo update
    Updating crates.io index
     Locking 2 packages to latest compatible versions
    Updating oci-spec v0.6.7 -> v0.7.0
 Downgrading regex v1.11.0 -> v1.10.6 (latest: v1.11.0)
note: pass `--verbose` to see 72 unchanged dependencies behind latest

Please do not use the tilde operator like this, specify the minimum version you want to require (or simply 1) without any prefix and cargo is going to select a semver compatible version for you automatically.


84 sentiment analysis

GPT sentiment analysis is implemented.

Reviews are collected via google_places_place_id of leads
Text of reviews are extracted and cleaned up.
Provided reviews retrieved sentiment score from GPT on review in range of [-1,  1].
Sentiment scores are added to data frame

I chose the pipfile.lock of dev over this branch (84-sentiment-analysis). After merge we need to lock based on the new (combined) Pipfile


v0.9.6 tag syntax

The 0.9.6 tag dropped the 'v' prefix (and is thus harder to notice in the list) than v0.9.5, v0.9.4, etc. Looks accidental?

Indeed this was unintended.  I've updated the tag.


Explain MouseInput.displVec

Is your feature request related to a problem? Please describe.
I don't understand what it's meant for, what its name means, or why is it calculated like that (why ignore a change of 0?)
Describe the solution you'd like
Explain what it is.

Thanks for reporting, added some explanation and modified the condition to be more correct.

This is better; But still, why the rotateX: Boolean thing? Why ignore a change of 0? Is this a mouse-lagging-behind-FPS thing?
P.s. might be wise to rename it to mousePositionDelta.

You are right, maybe it was old code that triggered an event, but it makes no sense now. I've simplifgied the code. regarding the naming suggestion I think it would be better deltaPos. In any case, I will update that in the new version of the book that I'm prepairing.


Github code and content did not match

Screenshot on Github is not the same as on a page
Obtain Teams thread ID to for call operations using Graph Explorer... - no mentions of thread ID on Github

Additional questions:

How to get orgid in 8:orgid:user_guid?
How to enable Teams and ACS communication?

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

ID: 85c6cb1f-8b8b-17ab-0121-4a164df2bbbc
Version Independent ID: 824645aa-8e13-008c-893d-9757fba60043
Content: Quickstart - Add voice & video calling as a Teams user to an app - An Azure Communication Services quickstart
Content Source: articles/communication-services/quickstarts/voice-video-calling/get-started-with-voice-video-calling-custom-teams-client.md
Service: azure-communication-services
Sub-service: calling
GitHub Login: @xixian73
Microsoft Alias: xixian

@sashaeve
Thanks for your feedback! We will investigate and update as appropriate.

@sashaeve I have assigned this to content author @xixian73 to review this request and to share your valuable feedback on this.

#reassign: garchiro7

Hi @sashaeve , if you are looking to obtain Teams user_id programmatically, then you can use Graph.
https://learn.microsoft.com/en-us/azure/communication-services/concepts/interop/custom-teams-endpoint-use-cases#steps-2
Here is another way ( manual ) ,
https://learn.microsoft.com/en-us/azure/communication-services/concepts/troubleshooting-info?tabs=csharp%2Candroid%2Cdotnet#getting-user-idFor manual
ACS-Teams interop calling is still under private preview ,for which you need to be onboarded for the program. Are you part of ACS TAP program ? if yes, you can reach out to them. If you are not a member, you can request membership using this form: https://aka.ms/acs-tap-invite

#reassign: ansrin

#please-close


Create fbneo.json

FinalBurn Neo is an emulator for arcade games & select consoles, a more focused alternative to MAME and used as the emulator of choice for projects like Fightcade.

Not sure what's wrong... got no errors upon installation or marked when editing the json through Github.


When public account creation is off, do not allow the register page to showup

Tested and working properly


Recommended way to check nonces in multi-server environment

Hi,
It looks like the nonce list is in memory and therefore any check would be per server, not per session? Is this acceptable or is there a recommended way to check nonces in a multi-server env?

Apologies for the delayed reply. The nonce checks are not yet supporting multi-server scenarios. Someone will have to write a patch along the lines of what the library does for e.g. associations, should not be too hard.


Fix toolips and popovers

Add text to tooltips. Change popover colors to match tooltips. Possibly include close button to popovers.

 Release Card


Just checking on a vulnerability

Wanted to know if this is vulnerable to the exploit mentioned in CVE-2019-11043.
My sites behind NPM have been patched.  Just wanted to make sure NPM itself isn't vulnerable to the exploit.

That only affects PHP, which this project doesn't use.


Use the ol-ext library

I need to use the ol-ext library, what would be the recommendations to add these features. I am currently trying to add a pie chart.
I would like the components to be implemented with ol-ext

The implementation already includes ol-ext. In package.json: "ol-ext": "^3.2.24",

"ol-ext": "^4.0.4" is used


Spec difference in lang.int constants

Description:
Please note the type not specified for lang.int constants in https://raw.githubusercontent.com/ballerina-platform/ballerina-spec/master/lang/lib/int.bal
Implementaion in https://github.com/ballerina-platform/ballerina-lang/blob/master/langlib/lang.int/src/main/ballerina/int.bal#L57
Steps to reproduce:
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):
Might be related to https://github.com/ballerina-platform/ballerina-lang/issues/33168
Suggested Labels (optional):

Suggested Assignees (optional):

We should be able to update all the constants except MIN_VALUE. We need to fix https://github.com/ballerina-platform/ballerina-lang/issues/28334 to write MIN_VALUE without the type.

Removing the bug label since the effect is the same with or without the type.


test: ensure Inclusion of "gitleaks" rules in secret.go file

Closes #
Proposed Changes
-The test check if all the rules that exist in "gitleaks" are included in our list of rules in the function loadAllRules() that are in secret.go file.
-If there is a difference between our list and the "gitleaks" list, the test fails and prints the difference.
I submit this contribution under the Apache-2.0 license.

It is the test that we talked about.
But it doesn't solve the problem completely, because it takes the current version of the file from the "gitleaks" project and not the version we are using.
Thus, there are new rules that are in the "gitleaks" project, but they are not relevant to us, and they fail the test.
So, you should actually take the version of the "cmd/generate/config/main.go" file from the "gitleaks.go" project according to the version we are currently using in our project and not according to the most recent version.

Also, I see it included all the old commits I did, I didn't mean to do that I just didn't know how to avoid it.
I would love to know how to avoid this.
Thanks.

It's OK to include all your old commits, the only thing that matters (in our repo) is the final change.
You can read about rebasing, but be careful! You may lose your work!
https://algoritmim.co.il/just-code/make-your-commit-the-best-with-interactive-rebase/

Thanks, I'll read about it.

I updated the code with all the comments you gave.


Feature request: Light mode

I'd like to request a day/night / light/dark mode button for hermit. A lot of people dislike reading in dark mode and it would be a great feature to support, in my eyes making Hermit supreme to other themes even more.

Will definitely add this feature, but I have no experience doing it, so this can take some time.

I've looked into this several times, but didn't have the time so far. Not adding much content, but here're some examples of dark-mode implemenations:
Docker Documentation - toggle on right
Some of MS documentation - toggle on top right
DevDocs.io - toggle in preferences

The Docker toggle looks nice.

I've implemented this feature in playHing.github.io using an ad-hoc approach.
Feel free to copy
https://github.com/playHing/blog/tree/master/assets
https://github.com/playHing/blog/tree/master/layouts
to your blog accordingly if it is good for you.

I've implemented this feature in playHing.github.io using an ad-hoc approach. Feel free to copy https://github.com/playHing/blog/tree/master/assets https://github.com/playHing/blog/tree/master/layouts to your blog accordingly if it is good for you.
Does this solution still exist now？and where can I refer to it.
thx alot

/Does this solution still exist now and where can I refer to it?

I've implemented this feature in playHing.github.io using an ad-hoc approach. Feel free to copy https://github.com/playHing/blog/tree/master/assets https://github.com/playHing/blog/tree/master/layouts to your blog accordingly if it is good for you.


Alerts Management adding lenient-model-deduplication

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
API changes are not detected in this pull request.


[WIP] Add PIL module

Codecov Report

Merging #538 into master will decrease coverage by 0.57%.
The diff coverage is 95.87%.

@@            Coverage Diff             @@
##           master     #538      +/-   ##
==========================================
- Coverage   96.35%   95.78%   -0.57%
==========================================
  Files          37       38       +1
  Lines       13369    13448      +79
==========================================
- Hits        12881    12880       -1
- Misses        488      568      +80


libchop build failing

I'm trying to fix libchop for #23253.
The build started failing with commit f803270b7e: specifically a single unit test fails:
FAIL: utils/block-server (exit: 1)
==================================
[...]
++ chop_fail_if '!' chop-block-server -a <IP_ADDRESS> -p 7696 ,,block-server.db '&'
++ eval '!' chop-block-server -a <IP_ADDRESS> -p 7696 ,,block-server.db '&'
++ echo 'failure condition `!' chop-block-server -a <IP_ADDRESS> -p 7696 ,,block-server.db '&'\'' is true'
failure condition `! chop-block-server -a <IP_ADDRESS> -p 7696 ,,block-server.db &' is true
[...]

It's almost surely due to some incompatible change in bash 4.4 but I haven't figured it out yet.
Also, after commit 919a1435da, build fails with
In file included from chop.c:545:0:
class-lookup.c:115:1: error: conflicting types for 'chop_lookup_class_entry'
 chop_lookup_class_entry (register const char *str, register size_t len)
 ^
chop.c:542:1: note: previous declaration of 'chop_lookup_class_entry' was here
 chop_lookup_class_entry (const char *str, unsigned int len);

cc @viric

I patched it to work with gperf 3.1 and temporarily disabled the tests failing. Still no idea why.


Added Reddit Clone

🛠 Fixes Issue
Fixes #645
👨💻 Changes proposed

Implemented a Reddit Clone, just using HTML, CSS, Javascript

✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

📷 Screenshots

Project Demonstration
https://user-images.githubusercontent.com/72455881/170855074-5bb78dca-3628-420d-b9fc-5bc71ec1cddd.mp4
Code Demonstration
https://user-images.githubusercontent.com/72455881/170855159-5be522c6-62d8-4bb1-af96-d943e849b36e.mp4

@gurjeetsinghvirdee @Rayman-Sodhi
Kindly Review this PR.
Thank you !

@gurjeetsinghvirdee Missed to add a Level label

Sorry itne tabs open rehte h bhul gya me


chore(deps): use p-settle concurrency option instead of p-limit

A bug in p-settle concurrency option has been fixed, so p-limit is no longer needed.
Also, This PR updates p-settle to 4.1.1 because<EMAIL_ADDRESS>has a bug in a TypeScript type definition(PR).

Codecov Report

Merging #465 (8634110) into master (004a281) will decrease coverage by 0.04%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #465      +/-   ##
==========================================
- Coverage   50.33%   50.28%   -0.05%
==========================================
  Files          24       24
  Lines        1045     1044       -1
  Branches      199      199
==========================================
- Hits          526      525       -1
  Misses        472      472
  Partials       47       47

Impacted Files
Coverage Δ

src/commands/buildJs.ts
14.28% <0.00%> (-1.01%)
:arrow_down:


Let workspace private and personal by default for all user

Issue: https://github.com/aws-samples/aws-genai-llm-chatbot/issues/227
Implement private workspace, every user create a workspace now is only private and not shareable with other user.
This feature implement a new DynamoBD table handle policies on top of Workspace Dynamodb table.
This implementation could facilitate sharing workspaces between users with writeable / readable policy  option through sharing process like Google Drive
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thanks for submitting this PR. Is this changing all Workspaces to private to the user?

Yes by default, all workspace will be private.
If we go ahead of this feature we could add interface to set if we want to open publicly the workspace or for some people ( example fetch a user from cognito )

As this is a breaking change, we should either think about an opt-in/out settings or the possibility to set workspaces as public/private and retain all existing workspaces as public.

I will do a migration script to let all existing workspace public.
On further in case the workspace does not have owner ( legacy workspace ) the first one who will set through interface that the workspace is private then he will became the owner of this workspace for ever.
What do you think ?

I closed this PR and opened a new one with more impact.


[AutoPR cognitiveservices/data-plane/VisualSearch] Adding EU compliance not to description

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/7610

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/6172


Formal Documentation of Axial Expansion in ARMI

Can we have some documentation added to the User Docs that details all that one needs to know related to thermal expansion in ARMI? I'm thinking an aggregation of all of:

relevant case settings
relevant blueprints attributes
relevant flags
how to use it
how to turn it off
what to expect when it is on/off
what it can/can't handle
assumptions
others...

To me, this would be incredibly valuable and would save many users lots of time.
I don't think such a thing should be part of the current PR, but reading through this PR left me craving exactly such a compilation because it is difficult (for me) to keep track of all of the many pieces.
Originally posted by @keckler in https://github.com/terrapower/armi/issues/931#issuecomment-1275240939

I have started a feature branch that contains a standalone jupyter notebook that attempts to address some of these... But I think adding all of the other features that @keckler has requested here is likely outside the scope of a single jupyter notebook. And it's not immediately clear to me where we would put such documentation in the ARMI User Docs.
@john-science @ntouran @opotowsky Do you have any preferences?

Perhaps here: https://terrapower.github.io/armi/user/inputs/settings.html#some-special-settings

Perhaps here: https://terrapower.github.io/armi/user/inputs/settings.html#some-special-settings

Ooh, I like it.

It might also fit as a Tutorial? I know they are more interaction focused but for something move involved like this I could see an argument for that

@opotowsky that was what I initially intended with the jupyter notebook. There might be an argument to have documentation in multiple places.

I would suggest the gallery for examples, since that is where demonstration scripts should go.

I think a Jupyter notebook is a great idea. As long as it has (or comes with) actual test describing things.  Working examples are great, when they come with lots of conversation.  I would add an RST file along with the Notebook.

Since GitHub doesn't feel like linking this....
https://github.com/terrapower/armi/discussions/1154#discussioncomment-4959351

@john-science @mgjarrett @keckler
What do you think about adding a section in the ARMI docs (probably in the user-docs) that describes:

Thermal expansion/contraction
Radial expansion/contraction
Axial expansion/contraction
Disjoint axial mesh unification via uniform mesh converter
Disjoint axial mesh unification via setBlockMesh

The first three are physics methods that should probably be documented.
The second two, though not physics, do have immediate impacts in how downstream simulations are set up and have direct and quantifiable impacts on the solutions.
Thoughts? Any other aspects we should include?

Yes. And some items that should be included within there are:

What is the purpose of pseudo-density and/or some history on why we have/had density() and density3()
Discussion of the inputHeightsConsideredHot setting and why that exists and when to use it

why that exists and when to use it

This could probably be done for quite a number of settings.

More things to add to the docs....  https://github.com/terrapower/armi/pull/1338

@albeanth Can you give us a quick run down of the state of this ticket, please?
Thanks!

Another item on the TODO: https://github.com/terrapower/armi/pull/1342/files#diff-2e7e36a8449dfbb3e1763045f1dc6f274a93a332976b38e201b5c94cab552845R214

@albeanth  I would like to bump this work.  It is awkward that we released this software to the NRC while this ticket was still open.

I know. I agree... 😞
We have some documentation, but the potential scope of this documentation could be significant. We need to have some internal discussions to resolve this, I think.

note to self in regard to choosing fuel component as the fuel block axial expansion target component:

If you override and make the target component the clad, yeah, you're gonna move fuel around between blocks (which would be a bad idea).

@albeanth @drewj-tp  @keckler We have to believe there will be a lot of work coming up that will require this documentation.  For instance, component linking.

@albeanth @drewj-tp @keckler We have to believe there will be a lot of work coming up that will require this documentation. For instance, component linking.

Sure. Yeah. This is but one piece of what's needed to properly document all of axial expansion and all it's little quirks.


Kafka connect initial

What this PR does / why we need it:
Open-Sourcing my private Kafka Connect Chart. This chart will allow users of Kafka and Schema Registry to continue to expand the capabilities of Kafka within their clusters.
Kafka Connect is a very useful tool for Kafka users as it allows Kafka to act as a conduit to and/or from other data sources. For example, a user can use Kafka Connect to periodically sync data from a JDBC source, say Postgres, into Kafka. Likewise, a user could periodically read data from Kafka into a JDBC source, S3 bucket, Elasticsearch, etc from Kafka Connect. The beauty of this tool is that it allows users to focus on describing the transformations/data movement they are interested in performing rather than implementing the tool to do it themselves.

@davidkarlsen -- I thought I'd tag you on this as well b/c you just reviewed the Schema Registry changes!

not stale


Watch task indicator

One more request that would go great with: https://github.com/Microsoft/vscode/issues/8509
Ability to see that there is active watch task running.
Maybe in the footer here:

Nice idea.

NOTES
Closing dirty editors prompts for save
We agree that we should no longer prompt users to save when they close a dirty editor if there is another duplicate editor still open.  However, we will wait until the August milestone to get one last team member’s feedback before making the change.
Debug toolbar in the way of tabs
We could do a quick fix on this, but what we’re seeing is just one manifestation of a larger problem: our global commanding patterns need some work, as does our debugger UX.  We will instead move to improve these overall experiences, which will in turn address this problem.
Quick Open preview, launched editors should stay open
We agreed that this is a compelling interaction need.  We considered how competing products handle this, and we found that Visual Studio IDE handles it best.  We will apply the relevant Quick Open interaction patterns:

Quick Open will now create a preview editor (or leverage the already open one, if one exists) to show you a preview of each item you focus on in the list.
Upon hitting Enter, the open editor will be kept open (i.e. no longer preview).
If a user hits Esc or clicks away from the Quick Open command palette…

The command palette will close and whichever open editor you were on before previewing will be brought back in view.
The preview editor will remain and whatever you last were looking at in Quick Open will also remain inside that preview editor—exception: if you were on a preview editor when you opened Quick Open and previewed some items but never selected any (e.g. escaped out of it) then we will restore whatever you previously had open in that preview tab, since that would indicate that the preview tab is likely something you want to keep and not replace.

"Left, "right," "center" take up too much space?
We can experiment with using horizontal lines, but there would be a necessary tradeoff: we couldn’t have group actions in the Open Editors list.
We asked ourselves, “Should we even have the Open Editors list at all, if tabs are enabled?”  Aren’t tabs sufficient to substitute for Open Editors?  Some on our team are actually closing the Open Editors list to get it out of the way as they use tabs.  We should validate if users would also fare better without them when tabs are enabled.
However, this is not a fix-all solution, because Open Editors are useful at least with tabs-disabled. And there’s another problem that needs addressing:  As you open files from the Explorer viewlet, the Open Editors list grows (and this growing is magnified as you open files to the side in new groups, as 2 lines are added each time that happens: one for the file and one for its group label, such as “right”).  This can be distracting and pushes the tree of files in your project down, which misaligns where you were previously with your cursor.
Possible solution for that: make Open Editors closed by default and/or allow it to be resized by users so that it stays fixed in its height and does not push things down.
Git: status bar lacks indication that it will push
We decided that first time users could be in for a nasty surprise if we don’t prompt them about what they are about to do by clicking on this for the first time.
The prompt could say “Sync will pull then push.  Are you sure you want to sync?” followed by a “Sync” “Cancel” and with a checkmark that says “Don’t ask again.”  Clicking the checkmark and continuing with a sync then would programmatically change the User Settings to never prompt again.
We will first run this by @joaomoreno
Watch task indicator
Showing when an ongoing task is both active and inactive is a great idea.  @dbaeumer can handle this.
We also should holistically look at our tasks UX, as it could be improved.  Or should we just rely on the integrated terminal and not have tasks?
OTHER
We unfortunately did not have time to discuss other issues during this meeting.  We will address those separately or in a future meeting.

fyi - @chrisdias @isidorn @stevencl @joaomoreno @bpasero

@bgashler1 Not sure if this was on purpose - but shouldn't that notes be added to https://github.com/Microsoft/vscode/issues/9506 and this task should stay open so it can be implemented ?

@wallverb yes, this was done by accident, @bgashler1 please move the notes to the ux meeting issue

Sorry, I had the wrong tab opened in Safari when I copied this.  My mistake :)

Sometimes watch task dies and there is no indication to user that it is not running anymore
Here is example of typescript bug that killed watch task silently:
9:53:09 AM - Compilation complete. Watching for file changes.

The task 'tsc' was terminated per user request.
/Users/user/.nvm/versions/node/v4.2.2/lib/node_modules/typescript/lib/tsc.js:37610
                throw e;
                ^
TypeError: Cannot read property 'decorators' of undefined
    at getStartPos (/Users/user/.nvm/versions/node/v4.2.2/lib/node_modules/typescript/lib/tsc.js:28667:45)
    at emitStart (/Users/user/.nvm/versions/node/v4.2.2/lib/node_modules/typescript/lib/tsc.js:28671:21)

There are now two indications in the status bar:

the number of running tasks (both watch  and non watch)
a Building... indication when a build task is active

There are not further improvements planned here. If you think the current support is not enough please open a new issue explaining what can be improved.


Check block2 option before recreating request as block2

Signed-off-by: Tuve Nordius<EMAIL_ADDRESS>

zephyr-wakaama.pcap.zip

(I just looked at the capture.)
Regarding https://github.com/eclipse/wakaama/issues/536#issuecomment-776052409 :

this fix only the infinite loop issue.
But there is still the "not expected 4.13" issue. Do you plan to fix it in another PR ?

@sbernard31 I can verify your findings with my test setup
wakaama server, block size: 128
  -> zephyr client, block size 256 (somehow ignores the setting and sends without block-wise)
  -> wakaama client, block size: 256

endless loop fixed
still sending 4.13 Request too large and 2.31 Continue as a response to a response

I missed that the response part was an issue as well. I will update this.

Here is the pcap, verifying that we do not respond with an error code to a response.
zephyr-wakaama.pcap.zip

The capture sounds good now.
I waiting for approval before to merge. :)

Sorry for the delay. The changes look good for me now.

Integrated in master (commit 771bf033b676d47666fd71894a979f7bfffc7728 and 04a04bffd30ba2297076ae88df23469933b10ed9)


Fix for getting Boomerang packages to show in Helios.

Got them listed in the gruntfile, deploy and devel files.
git clone
npm install
bower install
grunt devel
in case one wants to recompile it all
grunt amberc
amber serve
Works! (Well, shows in Helios)
You way want to do a Boomerang library and then include it, but that's another story.
You'll need a Boomerang.amd.json thing etc.

Works perfectly. Thank you!


issue#1094 - fixing nullref exception during deserialization

Signed-off-by: Appfrastructure<EMAIL_ADDRESS>

Description
Adding null check for array deserialization to avoid NullReferenceException and to support null objects in serialized arrays.

Motivation and Context

Fixes nanoFramework/Home#1094

How Has This Been Tested?

New unit test is added to validate the fix.
Screenshots
Types of changes

[ ] Improvement (non-breaking change that improves a feature, code or algorithm)
[x] Bug fix (non-breaking change which fixes an issue with code or algorithm)
[ ] New feature (non-breaking change which adds functionality to code)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Config and build (change in the configuration and build system, has no impact on code or features)
[ ] Dependencies (update dependencies and changes associated, has no impact on code or features)
[ ] Unit Tests (add new Unit Test(s) or improved existing one(s), has no impact on code or features)
[ ] Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

[x] My code follows the code style of this project (only if there are changes in source code).
[ ] My changes require an update to the documentation (there are changes that require the docs website to be updated).
[ ] I have updated the documentation accordingly (the changes require an update on the docs in this repo).
[x] I have read the CONTRIBUTING document.
[x] I have tested everything locally and all new and existing tests passed (only if there are changes in source code).
[x] I have added new tests to cover my changes.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: appfrastructure sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


How to install   logstash-codec-csv on logstash when there is no internet connection

Hello, I have a problem, there is no internet connection,  I was  installed the logstash ,
How to install  the plugin on Logstash with CentOS7 system.
If you have a solution, please let me know. Thanks

You need to download (got to rubygem and download), copy the gem to your CentOS7 machine, use bin/logstash-plugin install /path/to/logstash-codec-csv-{version}.gem command to install it.
Github is managing issues/bugs and requesting enhancement. For this kind of discussions, please use https://discuss.elastic.co/


Is there any good solution for lazy loading lit element as of Oct 2020 ?

Hey @justinfagnani,
I was looking for a solution to lazy load lit elements an found this repo.
Is there a more official way to do this now ?
Thanks

With LitElement 3.0 we're starting a new labs package that we can put this in.

Cool, thanks.
Is the labs thing online yet ?

Hey @justinfagnani, are there any news on the lab package?

There is https://github.com/lit/lit/tree/main/packages/labs now - I don't think there is LL in there yet


Add prediction writer callback

The idea of creating a lightning prediction writer callback is to unify writing to TIFF and writing to ZARR.
The strategy for writing a to the different files can be decoupled from the prediction writer itself by creating write strategy interface, with concrete classes that can be an attribute of the prediction writer.
TODO:

[ ] PredictionWriterCallback
[ ] write strategies

[ ] WriteImage
[ ] WriteTiles
[ ] WriteZarrTiles

[ ] File metadata extractors (mostly to extract the number of samples (i.e. tiff pages) per file)
[ ] Reimplement CAREamist.predict_to_disk function

Should we move this to backlog for now?