Error: Encountered unknown dialect 'https://json-schema.org/validation'

Info
NodeJS - 16.20.0 (I know, more on that later)
json-schema - 1.5.1
NextJS - 13.4.19
Repro
This branch basically: https://github.com/GabenGar/todos/tree/unknown-dialect
git clone https://github.com/GabenGar/todos --branch unknown-dialect --single-branch
cd todos
npm run install-all
npm run build

And then get several Error: Encountered unknown dialect 'https://json-schema.org/validation' errors (I assume per worker) during page rendering stage.
Details
I know I don't meet the minimal nodejs req, but I've read all discussions and it looks like it's only due to fetch becoming global in it. And I assume the error is caused by the package trying to fetch something and failing for whatever reason.
However I assumed by following these steps:

initializing all schemas as a side effect
writing a factory function to create a validator function
call it when needed

I'd avoid any network calls at all.
But it crashing at build step (when no validator functions are called/created) means it crashes at init() function. I assumed by importing from "@hyperjump/json-schema/draft-2020-12" I'd get all parts already. What do I have to do to prevent the package from doing any network/fs calls and instead crash outright when not finding something?

You're getting that error because you're trying to load a schema and haven't declared what dialect of JSON Schema the schema uses. The default is https://json-schema.org/validation and you've only loaded support for 2020-12. Therefore, you get the error that the dialect is unknown. There are no network calls happening in this situation.
To fix this problem, your schemas need to declare the dialect they use with $schema or pass the dialect in the addSchema function. The former is generally considered best-practice.

pass the dialect in the addSchema function

What is a retrievalUri in the argument and what do I have to put there if I only want to pass defaultDialectId? Also the error should be more explicit in saying it requires $schema key and found none or couldn't figure out the metaschema. I assumed the functions from "@hyperjump/json-schema/draft-2020-12" would automatically assume draft-2020-12 dialect when not provided, but I guess not.

The former is generally considered best-practice.

Don't know about that, it's mainly a noise in the schema collection derived from the same metaschema.

What is a retrievalUri in the argument and what do I have to put there if I only want to pass defaultDialectId?

You can read about the Retrieval URI concept here. The short version is that you would use the retrievalUri argument if your schema doesn't include $id. In other words, it's an alternate way of associating a schema to a URI. If you don't want to set the retrievalUri and do want to set the defaultDialectId, you can pass undefined for the retrievalUri.

the error should be more explicit in saying it requires $schema key and found none or couldn't figure out the metaschema.

That's good feedback that the message isn't clear. The problem is that there are multiple reasons the dialect would be unknown and multiple ways to fix it. It's hard to fit all that in an Error message, but I'll see what I can do.

I assumed the functions from "@hyperjump/json-schema/draft-2020-12" would automatically assume draft-2020-12 dialect when not provided

I can see why that would be confusing. The way it works is that all functions work with any configured dialect. This allows for supporting multiple dialects and things like referencing a draft-07 schema from a 2020-12 schema. The dialect-specific imports load support for that dialect, but the functions it exposes are just the generic functions that work with any dialect. You can load as many dialects as you need and those functions will work with all of them. I considered separating the api from loading dialects, but I didn't want users to have to use two imports just to get started. You're the second person who's been confused by that, so maybe I made the wrong choice.

Don't know about that, it's mainly a noise in the schema collection derived from the same metaschema.

There are good reasons for it, but I won't get into that here except to say that we're making changes for the next version of JSON Schema that will render those "reasons" moot and it will make sense to not include the dialect in the schema anymore.

$id is a complicated mess. The schema identifier is determined by resolving the $id against the retrieval URI. Since the $id is absolute, the resolved URI is the $id and the retrieval URI has no effect. You can reference the schema using either that identifier or the retrieval URI. If there's a conflict between a schema identifier and a retrieval URI, the schema identifier wins and the retrieval URI gets shadowed. So, in your example, the https://example.com/schema/account schema will point to the Account schema and the https://example.com/schema/profile schema will point to the Profile schema.
If you had only loaded the first schema, both https://example.com/schema/account and https://example.com/schema/profile would point to the Profile schema, but no matter which URI was used, https://example.com/schema/profile would be the base URI for resolving any references in the Profile schema.
All that contributes to why I discourage using $id even though the spec encourages it. Just using retrieval URIs is much simpler, more natural, and easier to maintain. However, the retrievalUri argument is just a simulating something like what would happen with a web request (http(s)://) or file system access (file://). This library allows you to not just simulate retrieval URIs, but to actually use them. In your case, I'd suggest using your schemas as files. They're files anyway and translating to use some arbitrary identifier is more works and error prone. Your code application would work the same way it does now except you would pass a URI like file:///path/to/schema/account.shcema.json to your createValidator function and you no longer need an init function at all the load schemas. The schemas are loaded directly from the filesystem. I'm working on an enhancement to allow you to use paths relative the calling file so you don't have to write out the full file: URI, but for now it's usually pretty easy to generate those paths.

Actually, I just realized that that code is in a directory called "frontend", so this is probably running in a browser. The same concept applies, but instead of using file: URIs, you can use http(s): URIs (https://localhost:3000/schemas/account). Of course that requires you host those schemas at some URI in your website. Those schemas would otherwise be bundled in your JavaScript, so you're not exposing anything you wouldn't otherwise be exposing.
If for some reason, your still not comfortable with that solution, I'd still recommend using retrievalUris in addSchema to identify schemas rather than $id. It's simpler and it's all you need.

I forgot to mention, if you serve your schemas, you need serve them with Content-Type: application/schema+json; schema="https://json-schema.org/draft/2020-12/schema". The schema parameter sets the default dialect so you don't need to use $schema.
If you use this approach on the filesystem, there's no alternative to using $schema in every schema.

If you had only loaded the first schema, both https://example.com/schema/account and https://example.com/schema/profile would point to the Profile schema, but no matter which URI was used, https://example.com/schema/profile would be the base URI for resolving any references in the Profile schema.

This "sometimes kinda $id but not quite" behaviour doesn't sound too swell, as it introduces order-dependent resolution result.

All that contributes to why I discourage using $id even though the spec encourages it.

How are you supposed to reference other schemas within schemas without "$id" value set?

Just using retrieval URIs is much simpler, more natural, and easier to maintain.

It isn't actually, as it assumes schemas can be downloaded with fetch/read from file system at runtime. And my situation is neither.

They're files anyway and translating to use some arbitrary identifier is more works and error prone.

I consider this a boon as it stops various implementations from "helpfully" assuming things and crash at schema resolution time instead of sometimes after fetch/fs call with a cryptic error message.

The same concept applies, but instead of using file: URIs, you can use http(s): URIs (https://localhost:3000/schemas/account). Of course that requires you host those schemas at some URI in your website.

Introducing unknown amount of waterfalling http calls just to compile a validation function is a pretty bad idea for the same reason running browser ESM  without bundling is bad. Considering one of the videos on json schema youtube channel said they had ~100 levels of nesting (although I only had ~5 in my private hello world repo), no static server will tolerate additional 5-100 fetch calls on each page transition. It will either error out and break the whole chain anyway or shape traffic to the point it will result in a janky UX.

so this is probably running in a browser

It does but it's not relevant to the subject at hand. I just import the schema files as js modules which then get inlined into the bundle at build time, so for the purpose of the code I feed the schemas as js objects to the addSchema() functions. No intention of runtime or even build time fetching down the line.

How are you supposed to reference other schemas within schemas without "$id" value set?

You reference them by their retrieval URI. Think of an HTML document in a browser. The URI you use to retrieve the HTML is the base URI for document. Any relative-reference URIs are resolved against that base URI and retrieved (usually with HTTP, but other URI schemes are usually supported as well). Referencing in a schema works exactly the same way, except you can manually determine how a URI resolves to a schema using the retrievalUri argument of the addSchema function skipping normal URI scheme-based resolution such as making an HTTP request.
Using the retrievalUri argument instead of $id, you're still assigning identifiers to all of your schemas and referencing schemas the same way, you're just assigning that identifier in a different way. I prefer the retrieval URI approach to the $id approach because it's simple, is similar to how all other web technologies work, and the same pattern works in cases where you actually do want to retrieve schemas from the filesystem or the web.
In case it wasn't clear, although it's technically allowed by the spec and this library, there's no good reason to use both the retrievalUri argument and $id for the same schema. You should only use one at a time.

Introducing unknown amount of waterfalling http calls just to compile a validation function is a pretty bad idea

You're not wrong, but I think using appropriate HTTP cache header for your schemas addresses most of this concern. Also, as I understand it, HTTP/2/3 multiplexing and connection reuse features make sending many requests not the same kind of performance concern that it used to be. I also find the claim of getting anywhere near 100 levels of nested references dubious and at best an extreme outlier, but if that's a situation where you find your self, I agree this probably isn't the right approach.
In any case, I admit that my suggestion is more applicable to the filesystem than the web, which was what I thought was the case when I first mentioned it. At the least, you'd have to change the way you've organized things because there are different trade-offs in play.
I see that you're not comfortable with the approach of using normal URI scheme-based resolution. That's totally fine. This library supports multiple approaches and you're free to choose which works best for your situation.

I just released an update to improve the experience when not declaring a dialect. You'll now get an error with the following message,

Unable to determine a dialect for the schema. The dialect can be declared in a number of ways, but the recommended way is to use the '$schema' keyword in your schema.

You reference them by their retrieval URI. Think of an HTML document in a browser. The URI you use to retrieve the HTML is the base URI for document. Any relative-reference URIs are resolved against that base URI and retrieved (usually with HTTP, but other URI schemes are usually supported as well). Referencing in a schema works exactly the same way, except you can manually determine how a URI resolves to a schema using the retrievalUri argument of the addSchema function skipping normal URI scheme-based resolution such as making an HTTP request.

What is the source of truth for the retrieval URI? Also I am thinking of JSON schemas as a fancy input validation DSL, not as something related to web documents in a browser. retrieval URI forces the schemas themselves to be aware of retrieval specifics at declaration time, when the "real" URL will be known at best at build time.

Using the retrievalUri argument instead of $id, you're still assigning identifiers to all of your schemas and referencing schemas the same way, you're just assigning that identifier in a different way. I prefer the retrieval URI approach to the $id approach because it's simple, is similar to how all other web technologies work, and the same pattern works in cases where you actually do want to retrieve schemas from the filesystem or the web.

Clearly it's not "simple" because it is a source of confusion in this very issue right now. Also I wouldn't call anything related to HTTP/file systems simple. Especially file systems, since Windows and Linux don't agree even on basic things like case sensitivity and path separators, so it's easy to end up in a situation where the retrievalUri can resolve differently depending on host OS. It's much more simple to assume "$id" is just a JSON string which can be checked for strict equality in all languages, instead of relying on built-in url parser/http/fs capabilities. Also fragment being important for the schema resolution while being completely ignored on the web doesn't help with "it's just an URL, bro" argument.

You're not wrong, but I think using appropriate HTTP cache header for your schemas addresses most of this concern. Also, as I understand it, HTTP/2/3 multiplexing and connection reuse features make sending many requests not the same kind of performance concern that it used to be. I also find the claim of getting anywhere near 100 levels of nested references dubious and at best an extreme outlier, but if that's a situation where you find your self, I agree this probably isn't the right approach.

Majority of internet runs on HTTP 1.1, and HTTP 2 has its own security issues (such as completely nullifying network jitter capabilities of TCP). Regardless of protocol, it's still megabytes of data which doesn't even need to be sent because its known at build time.

I also find the claim of getting anywhere near 100 levels of nested references dubious and at best an extreme outlier, but if that's a situation where you find your self, I agree this probably isn't the right approach.

That's not my claim, it's either in one of those interview videos on youtube channel or somewhere in json schema related discussions. I am merely at 5 levels, which would still upset nginx at default config.

I am thinking of JSON schemas as a fancy input validation DSL, not as something related to web documents in a browser.

I think of JSON Schema as a validation DSL as well, but it's also built on web technologies. It can be both.

Clearly it's not "simple" because it is a source of confusion in this very issue right now.

There were two separate questions on StackOverflow just in the last few days of people confused about why their file-relative references aren't working. I see this kind of question in some channel or another about once every two weeks on average. There are definitely a lot of people that expect this behavior and find the self identification concept foreign.

it's easy to end up in a situation where the retrievalUri can resolve differently depending on host OS

This isn't a problem because JSON Schema works with URIs which is universal. This library translates the URI into a file system path appropriate to the environment it's running in.

It's much more simple to assume "$id" is just a JSON string which can be checked for strict equality in all languages

I see that self-identification makes more sense to you. That's fine. Feel free to use what's most comfortable for you.

fragment being important for the schema resolution while being completely ignored on the web doesn't help with "it's just an URL, bro" argument.

JSON Schema uses fragments exactly the same way they are used on the web. In HTML, you can set an "id" on an element and when used in a URI fragment, the browser moves to that position in the document. JSON Schema works the same way. The application/schema+json media type defines a behavior for the URI fragment including JSON Pointer support. The JSON Schema validator retrieves the whole schema document, but sets the view (so-to-speak) of document (schema) to the sub-schema the fragment points to.

I suggest we close this issue at this point. The original issue of the confusing error message has been addressed and we're off on a tangent. I'm sorry you didn't find my suggestion helpful. Please do continue to use self-identification if that's what you're most comfortable with. That functionality is present and fully functional. I will however, continue to provide URI scheme based retrieval for those who find that more useful. If you want to be 100% sure you don't accidentally bump into scheme based retrieval, I suggest using a URI scheme other than file: or http(s): such as urn:, tag:, or even something custom. Those of us working the JSON Schema spec have been discussing the idea of promoting the use of schema: URIs rather than URIs that imply a location that might not exist.


Considering using Let's Encrypt instead of OpenSSL

On my team, I've noticed that we use OpenSSL which results in alot of Chrome clicking past "Get me back to safety" links. I wonder if CF as a whole should be using Let's Encrypt more.

Hey @professor. We've gotten similar feedback recently. When we originally wrote these stories, Let's Encrypt didn't support wildcard certificates -- a dealbreaker for CF deployment. Now that Let's Encrypt has started supporting wildcard certificates, I'm totally open to adding that into the onboarding repo, although I have a few nuanced thoughts about it.
Most actual Pivotal dev teams still use self-signed certificates. It seems like it's worth explaining/teaching that in the onboarding course so that participants can understand what their team is currently doing. However, this could also be an opportunity to teach folks a better way. What do you think of a story to "upgrade" from a self-signed certificate to valid certificate from Let's Encrypt? Would you be open to submitting a PR?

@dsabeti thanks for the feedback. In working through the onboarding materials, I briefly tried Let's Encrypt, it's new technology for me. It looks like it wants DNS setup for the subdomain before it will issue a certificate as part of its authorization process. Currently the stories setup the cert, then setup the DNS. I'll need to dig into this some more.

@professor, thinking this through a little now. bbl expects LB certs as an input, and then creates the appropriate DNS record; Let's Encrypt requires the DNS record to exist in order to issue the cert. Sounds like deadlock.

Also, cc @evanfarrar, in case he's interested in smoothing out the integration between bbl and Let's Encrypt.

I've played around with lets-encrypt before and work on BBL so I might explore implementing this sometime during flex-hours (this or next week).

I just started working on this.


Class weights.

Hey there,
I want to set loss function for imbalanced binary class. however, on the docs it says class weight only support "Use this parameter only for multi-class classification task; for binary classification task you may use is_unbalance or scale_pos_weight parameters. " .
I read from other post pos_weight parameters will change the distribution of my data, I can't change the distribution. How do I set the weight class for this situation?
Thanks ,

I think both class_weight and scale_pos_weight/is_unbalance will change the distribution. And there are the same when setting the corresponding values in class_weight.


Simplify Geometry3D tests

Each of these tests was defining a local struct to store the data for each test case, and creating an array of them. In all of the tests there were only a few entries in the array, and in most of the tests the additional complexity of the structs did not provide any scaling or readability benefit even if there were hundreds of test case data entries.
Upon further investigation, these were not given a thorough review when they were first merged. #44974 was only reviewed by one contributor, and then quickly merged the same day.
This PR simplifies the Geometry3D tests, which also brings them closer to our other tests. It also fixes some places where the case convention was not correct (ex: Vector3 GoodTriangle[3]).

Thanks!


Update Install_OQS_Classic.sql

Added "IF EXISTS" for all parts of installation scripts to rerun the script as often as necessary ;-)

Hi Björn!
The suggestion is appreciated, but we are going to hold off on this change for a while. We are undecided on how to deal with the case of running the installer on a database that already has OQS installed with data already collected. As it is, the drop and create could potentially throw away a lot of really useful data.
We will have to address this scenario in the future for sure, but for now we will leave it at the clunky stage (we are making lots of changes at this early stage that will overwrite your pull request too).
If you have suggestions on how we might make this better, please create an issue and provide your ideas that way first.
Thanks
William

Ok for me.
This was just an "outcome" from my testing on SQL Server 2008 R2 where I had to execute the installer several times and want to have a "clear" installation to be sure everything is as expected.
Next time I'll open an issue first.


fix: bug in AttributesHelper

check if property name has been set and get properties of instance

Codecov Report

Merging #47 (6303978) into dev (5d0cc06) will decrease coverage by 0.41%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev      #47      +/-   ##
==========================================
- Coverage   88.50%   88.08%   -0.42%
==========================================
  Files          31       31
  Lines         800      814      +14
  Branches      111      115       +4
==========================================
+ Hits          708      717       +9
- Misses         13       17       +4
- Partials       79       80       +1

Flag
Coverage Δ

unittests
88.08% <ø> (-0.42%)
:arrow_down:

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

Impacted Files
Coverage Δ

src/components/AnxCrudTable/AnxCrudTable.vue
81.25% <0.00%> (-2.09%)
:arrow_down:

Continue to review full report at Codecov.

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


fix(pie-button): DSW-1181 transparency mode added to hsl mixin for ghost and outline buttons

Describe your changes
pie-button
[Fixed] - transparency mode added to hsl mixin for ghost and outline buttons
pie-storybook
[Added] - added some more custom bgs and device viewports
Author Checklist (complete before requesting a review)

[x] I have performed a self-review of my code
[ ] If it is a core feature, I have added thorough tests
[ ] If it is a component change, I have reviewed the Storybook preview
[ ] If there are visual test updates, I have reviewed them properly before approving

Reviewer checklists (complete before approving)
Reviewer 1

[ ] If there are visual test updates, I have reviewed them

Reviewer 2

[ ] If there are visual test updates, I have reviewed them

@ashleynolan Just checked the storybook instance and it looks like the default dark background has disappeared for the inverse button variants. If you could add that back in that would be great.

@xander-marjoram good spot – I'll tidy up the storybook config as reckon can make this a bit cleaner, so moving this back to draft while I do that.


IND-4215: adding versions with OAuth2 creds (for EU use).

Description
Adds a version of the cost policies using OAuth2 Flexera credentials instead of the built-in auth of type rightscale (that cannot be used in the EU region).
Issues Resolved
https://jira.flexera.com/browse/IND-4215
Contribution Check List

[x] All tests pass.
[x] New functionality includes testing.
[x] New functionality has been documented in the README if applicable
[x] New functionality has been documented in CHANGELOG.MD

Danger has errored
[!] Invalid Dangerfile file: cost/scheduled_reports/scheduled_report_with_oauth2.pt:81: syntax error, unexpected tIDENTIFIER, expecting keyword_end
asource "ds_currency_reference" do
^
cost/scheduled_reports/scheduled_report_with_oauth2.pt:83: syntax error, unexpected tIDENTIFIER, expecting end-of-input
host "raw.githubusercontent.com"
^. Updating the Danger gem might fix the issue. Your Danger version: 8.0.5, latest Danger version: 8.2.3
 #  from Dangerfile:99
 #  -------------------------------------------
 #  has_app_changes.each do |file|
 >    pp.parse(file)
 #    category = pp.parsed_category
 #  -------------------------------------------

  Generated by :no_entry_sign: Danger

@cdwilhelm I've added the publish: false flag to the OAuth2 policy templates to make sure they do not get published in NAM, as you recommended. Those policies will be published manually in the EU.

          2 Errors

:no_entry_sign:
Checking cost/billing_center_cost_anomaly/billing_center_cost_anomaly_with_oauth2.pt
An unexpected error occurred: failed to unmarshal policy template content

:no_entry_sign:
Checking cost/scheduled_reports/scheduled_report_with_oauth2.pt
An unexpected error occurred: failed to unmarshal policy template content

  Generated by :no_entry_sign: Danger


fix: Header SafeAreaProvider

The header is working, but it's behaving differently.

Fixed in version RNE 3.0.1, RNE needs to be updated in the playground.


Add a way to pass a non-default timeout to invokeCommandWithEndpointID on MTRBaseDevice

Right now there is no way to do it.
Maybe we should have a generic "request params" struct that this and timedInvokeTimeout live in and all the client-to-server command structs inherit from?

We decided to not add API surface for this.


Fix 2 bugs in the codegen for pattern matches

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3964/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5251/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3970/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5259/
Test PASSed.


Update Repository Request

Please add model and Scarface method.
Please 😢
Need it ASAP

Please add model and Scarface method.

Hi everyone. I will upload the model and some minor updates tomorrow.


GCP Config Connector CRDs

Hi ! First of all,  great work with deploykit. I am quite aligned on this approach have been using deploykit's k8s generated API here: https://github.com/dxcfg/dxcfg.
I see a potential use case to provision GCP resources using config connector CRDs. Would you be open to a contribution for that ?

Thanks for the feedback :)
Be happy to accept PR, you can add sources here:
https://github.com/livecycle/deploykit/blob/199e95f53a10182df410523fc8f64b73a4f3cde3/generated/k8s/sources.json
And run the generate script. (If it doesn’t work, I can apply it as well)
I’ll  publish a new version after the PR is merged

Its actually is a lot of CRD yamls in there: https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/crds. And growing ! You are ok with the sources.json file getting a little crowded ? Alternatively I can keep it separate in its own json file.

Hmm, maybe we can change the sources.json to sources.ts that exposes the sources object?
That way you can import other file that contains all the other crds and just “…” array spread it.

Makes sense. I will go with that.


Consider dropping INLINE pragma on hashWithSalt

Always marking hashWithSalt as INLINE can lead to large increases in code size when you have nested data types, especially when using generic instances.
I feel like the burden should be on the user to mark this function as INLINE if they feel it is worthwhile

This is speed/size trade-off. I'll need a data backing the claim. I don't see a reason to make a change. (I'm also not sure having big Hashable things is a good idea to begin with).

the {-# INLINE hashWithSalt #-} affects the definitions outside this package, which use generics to derive the instance.
One way to fix that is to introduce a breaking change and force users to use DerivingVia and therefore make an explicit choice. Just removing the {-# INLINE #-} will change stuff in a subtle and hard to figure out way.
Even I agree in general that it's better to not have {-# INLINE #-} unless there is a benchmark justifying that (which we don't, AFAIK), at this point I'm not willing to make a change.
You can write
instance Hashable MyIntermediateBigRecord where
    hashWithSalt = genericHashWithSalt

and that instance won't have {-# INLINE #-}.

Ah I see! I didn't know that about the behaviour of INLINE on default instances. I'll close this in that case. Thanks for you helpful responses!


Add HTTPS verification

Always when syncing I get this output:
~/.local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:734: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)

(I get it multiple times)
I guess it would be fine to add https verification

I'm happy to accept pull requests on this, but I won't implement it due to #92


SMOS NRT DA, issue in grid finding period

Bug Description
Yonghwan Kwon previously reported SMOS data are missing in large areas over the north-western CONUS where most ISMN stations are located. This issue was attributed to the hard-coded “grid finding period” in LDT. The “grid finding period” was originally (and tentatively) set to 30 days, but it seems that this period was not enough to assign all SMOS grids to the LIS grids. Yonghwan Kwon tested longer periods and the results are shown in the link below:
https://nasa-my.sharepoint.com/:p:/g/personal/svkumar_ndc_nasa_gov/Ec-jgSEoQbBDpMdrW3Xrc0gBm_-1R9H_EVq1Jy3hXl1NTA?e=qXgje0
When the 150-day period was used for “grid finding” in LDT, the SMOS data (unscaled; before model-based QC) could cover the whole CONUS domain.

Steps to Replicate
I do not have a test case for this issue. I can create a test case if needed. But, he confirmed that he did not fix the bug in the code prior to his departure.
See the following email exchange
Hi Mahdi,
Yes. You are right.
Thanks,
Yonghwan
From: "Navari, Mahdi (GSFC-617.0)[UNIV OF MARYLAND COLLEGE PARK]"<EMAIL_ADDRESS>Date: Friday, March 24, 2023 at 12:20 PM
To: LIS-557WW<EMAIL_ADDRESS>Yonghwan Kwon<EMAIL_ADDRESS>Subject: Re: [update] SMOS DA
Hi Yonghwan,
We were discussing the SMOS NRT DA and I just remembered an old conversation between us (see previous emails below).
Do we need to change the “grid finding period” from 30 days to 150 days?
https://github.com/NASA-LIS/LISF/blob/48a8c51aa15c49031be45342ed8b441cc27e18c0/ldt/DAobs/SMOS_NRTNN_L2sm/readSMOSNRTNNL2smObs.F90#L281
If that is the case, is this the right and only places we need to change?
Thanks
Mahdi

Resolved by #1302


Allow JWTs to be generated/authenticated with expiration time

Before submitting any pull request, please read the contribution guide: http://www.pac4j.org/docs/contribute.html

Thanks for the contribution. The build fails with findbugs errors.

I'd like to cut the RC2 today. Do you think you'll be able to make the requested changes on this PR today? Thanks


fix vti output

:tada: This PR is included in version 6.0.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


goimports doesn't compile

Please answer these questions before submitting your issue. Thanks!
What did you do?
go get -u golang.org/x/tools/cmd/goimports
What did you expect to see?
expected it to compile
What did you see instead?
$ go get -u golang.org/x/tools/cmd/goimports
# golang.org/x/tools/cmd/goimports
cmd/goimports/simplify.go:42: undefined: match
cmd/goimports/simplify.go:52: undefined: match

System details
go version go1.8 linux/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/nate"
GORACE=""
GOROOT="/home/nate/go"
GOTOOLDIR="/home/nate/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build550977818=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
GOROOT/bin/go version: go version go1.8 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.8 X:framepointer
uname -sr: Linux 4.4.0-64-generic
LSB Version:	core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.23-0ubuntu5) stable release version 2.23, by Roland McGrath et al.
gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1

Why does the file cmd/goimports/simplify.go even exist?  It's not in my copy of goimports.

It has never existed in goimports. I imagine @natefinch was once proposing to re-add it from gofmt back to goimports and had that CL (or a part of it) still on disk.

ahh crap, thanks, you're right


Add docker tests

In order to automatically test the aws-managed job workflows this PR adds a local image of the amazon-braket-oq-dev.
This PR also changes some of the testing strategy: instead of using the binaries for rigettis QVM and QUILC these are handled (together with the oq-managed-jobs) through docker compose

One thing to note is that these tests will only (currently) work on linux


docs(showcase): Update Prismatic.io showcase image, description, and tags

Pre-flight checklist

[X] I have read the Contributing Guidelines on pull requests.
[ ] If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
[ ] If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

Updates the prismatic.io showcase screenshot, description and tags after a significant docs update.
Test Plan

Test links

Deploy preview: https://prismatic.io/docs/
Related issues/PRs

thanks


Add bees knees affirmation

An affirmation that also uses a emoji :)

@all-contributors add @Ian-GL for ideas

trying again! @all-contributors add @Ian-GL for ideas


beautified indentation, removed tabs

@wasserfuhr Thanks, I will find someone to review this PR soon

@original-brownbear this pull request is for you,please review

@yegor256 don't think there is anything to review here for me ? :) Handle as you wish I guess.

@wasserfuhr thanks


Implement Name Account screen

@mduccc lets hide the Advanced button in app bar for now. the MVP version wont have that feature.

Yes. I had to hide that button

@mduccc lets hide the Advanced button in app bar for now. the MVP version wont have that feature.

Yes. I had to hide that button


Testing

I added some tests. Feel free to add some others if you want to.
I also set up the new GitHub 'Actions' feature to automate these tests for each PR.

@creativecreatorormaybenot This is actually pretty straightforward, you just have to edit the file to build the container image (like a Dockerfile).
The thing is that 'Actions' is for now in beta so you have to sign up for it and wait until they gave you an access (this only took a few days for me).

I see, thanks.


fix: use dl.k8s.io, not kubernetes-release bucket

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
There are still references to https://storage.googleapis.com/kubernetes-release instead of https://dl.k8s.io/
dl.k8s.io is the correct advertised download host and will eventually move to be fastly shielding a fully community-owned bucket
ref: https://github.com/kubernetes/k8s.io/issues/2396
Required Items

[x] Your PR consists of a single commit (i.e. squash your commits)
[x] Your commit and PR title starts with one of fix: | test: | chore: | doc:, to indicate the nature of the fix (see Conventional Commits)

Optional Items

[ ] 💥 This PR involves a breaking change. If so, include "BREAKING CHANGE: ...why..." in the commit and PR message.

/retest

/retest


fix(plus-17): adds externalName to service props

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Adds externalName to service props
Validates externalName is set when using an EXTERNAL_NAME type
Adds externalIPs test to get back to 100% coverage in the service tests

@eladb @pusherman Anything still pending on this PR?  I would love to start using it in production instead of my other hack.


RAINCATCH-1014 - Fix local development issue due to compiling on prepublish

Motivation
The assumption that ts-node favors ts files over js ones when requiring a directory was wrong, so having js files compiled alongside the ts sources didn't solve the problem of not needing to recompile internal dependencies during local development.
Description
Remove prepublish commands and add global build command to the repo root.
Progress

[x] remove prepublish from example/base
[ ] remove prepublish from other existing modules
[x] add global npm run build
[x] add note to manually build the modules before publishing

ping @wtrocki

@feedhenry-raincatcher/rcdev After merging this change we will need to apply them to our modules that are in PR state now.

so the 'migration instructions' are:

Remove the prepublish npm script
Remove the proxy /index.js
Add "main": "src/" to package.json
Optionally add npm run clean before the test command just to make sure.


I have a question.

Hello,
I'm reaching out with a question while using TEXTOIR.
Hugging Face offers the latest library versions, but I'm curious as to why older versions of BERT, RoBERTa, etc., are being used. Could you explain the reason for this?

Hi, actually I'm not really understand your question. As the latest library versions are inherited from the older versions, the results should be the same. We will try to update it to the latest version (though it might be a huge work) if we have time :)


Uncaught ReferenceError: ExcellentExport is not defined

The compressed file:
    "function" === typeof define && define.c ? define(function() {
            return l
        }) : "undefined" !== typeof exports ? ("undefined" !== typeof module && module.b && (exports = module.b = l), exports.a = l) : r.a = l

This is the only way to use:
Download

it should be define.amd .  your compressed file is bad  , you can download the uncompressed file and compress it with uglifyjs , it works fine.

@Elity , @TaumuLu I don't quite understand what is your problem and your proposed solution.

Fixed !


Tab crash when playing sound/video

Describe the bug
Any tab when media (video/sound) plays, will crash with the code RESULT_CODE_UNINSTALL_USER_CANCEL.
I have tried recompiling/reinstalling, as well as deleting my ~/.config/chromium folder.
This is NOT an issue when using Firefox or Google Chrome Beta.
(if you need any logs I will need guidance in getting them)
To Reproduce
Steps to reproduce the behavior:

Go to any page with sound/video (example)
Press play (if applicable; silent autoplay videos are affected as well)
Tab will crash with code RESULT_CODE_UNINSTALL_USER_CANCEL

Expected behavior
The tab will successfully play the media and not die
Environment (please complete the following information):

OS/Platform and version: Gentoo, x86_64, kernel 5.7.5-gentoo
ungoogled-chromium version: 83.0.4103.116

confirm

dmesg shows the following error
[226352.834976] Code: 48 8b 04 25 00 00 00 00 0f 0b 48 8b 04 25 00 00 00 00 0f 0b 48 8b 04 25 08 00 00 00 0f 0b 48 8b 05 27 ff 03 00 48 89 44 24 58 <48> 8b 04 25 00 00 00 00 0f 0b 48 8d 05 e9 cf 02 00 4c 89 f7 48 c7
[226803.606675] Media[23426]: segfault at c ip 000055b18b39b6ae sp 00007f389c774c60 error 6 cpu 0 in chrome[55b18a9a4000+7fc7000]
[226803.606678] Code: ff ff bb 06 00 00 00 e9 15 fc ff ff 31 db e9 0e fc ff ff cc cc cc cc cc cc cc cc cc 41 57 41 56 41 54 53 50 49 89 f6 49 89 ff <c7> 46 0c 01 00 00 00 8b 0f ff c9 83 f9 0e 77 35 b8 02 50 01 00 48

This should be related to ffmpeg 4.3, see https://bugs.gentoo.org/728624.

Looks like this issue is easily fixed with a patch. Should I include it in my ebuild?

testing

seems to work for me as well @PF4Public

Closing because issue is solved.
@PF4Public I just created https://github.com/ungoogled-software/contrib; it would be nice to include your patch there. If you'd like, I can grant you write access to the repo.

@Eloston This patch is taken from mainline Gentoo chromium. And I think I can easily include it into contrib as it could be really useful on other platforms/environments, but I doubt I can use it.
I have simplified my workflow as much as I could, because otherwise I had to dedicate a lot of my time on maintaining Gentoo ebuild of unggogled-chromium (that is mostly because of the source-based nature of Gentoo and implications thereof). I'm fine with the time I'm spending on it right now, but would better not increase it. My worflow at the moment is that I simply copy needed patches from Gentoo and place them in my repo, which is rather easy and fast. Using an intermediate repo in my workflow would mean that I have to copy this patch to the said repo, commit, push, update reference to this repo in my ebuild, handle extraction and patch selection. All of this is exactly what I was willing to avoid by simplifying my workflow, by editiong the ebuild, that I have "inherited" from Ian Moone. Those are actually also the reasons outweighing the benefits of creating Gentoo-targeted repo under ungoogled-software in my opinion.
Having all this said, I do wish to commit this patch to contrib repo for the benefit of community. Come to think of it… what are the odds, someone outside Gentoo using ffmpeg 4.3 and needing this patch?

@PF4Public It's better to think of contrib like GitHub Gists; it's not super formal and just a place for you to put stuff you think will be useful for others. You probably don't want to integrate contrib into your workflow. There's no obligation to use it either. I'm just trying to make others aware of contrib because I want to see if it helps.


⚠ ETF has degraded performance

In 76f262b, ETF (https://markets.hankyung.com/equity-product/etf) experienced degraded performance:

HTTP code: 200
Response time: 8871 ms

Resolved: 한경주요지수-코스피 performance has improved in 0f18fa7.


Change text direction

Hello,
How can I change the text direction? I want the text to show from up to bottom

https://github.com/tapptitude/TTFortuneWheel-iOS/issues/16


fatal error, server stopped responding under anidb refresh

fatal error, server stopped responding under anidb refresh.
Server Version <IP_ADDRESS>4
unsure why. here is a cutout of the log:
[2016-11-29 05:21:09:638] Fatal|Path.GetPathRoot => Path.LegacyNormalizePath => UnhandledExceptionManager.GenericExceptionHandler Date and Time:         29/11/2016 05:21:09
Machine Name:          ARE
IP Address:            <IP_ADDRESS>
Current User:          ARE\Are
Application Domain:    ShokoServer.exe
Assembly Codebase:     file:///D:/Programs/Shoko/Shoko Server/ShokoServer.exe
Assembly Full Name:    ShokoServer, Version=<IP_ADDRESS>4, Culture=neutral, PublicKeyToken=null
Assembly Version:      <IP_ADDRESS>4
Assembly Build Date:   12/11/2016 18:43:50
Exception Source:      mscorlib
Exception Type:        System.IO.PathTooLongException
Exception Message:
Exception Target Site: LegacyNormalizePath
---- Stack Trace ----
System.IO.Path.LegacyNormalizePath(path As String, fullCheck As Boolean, maxPathLength As Int32, expandShortPaths As Boolean)
ShokoServer.exe: N 13815764
System.IO.Path.GetPathRoot(path As String)
ShokoServer.exe: N 00048
System.IO.RenamedEventArgs.get_OldFullPath()
ShokoServer.exe: N 00060
JMMServer.AdvFileSystemWatcher.OnRenamed(sender As Object, e As RenamedEventArgs)
AdvFileSystemWatcher.cs: line 0171, col 13, IL 0000
System.IO.FileSystemWatcher.OnRenamed(e As RenamedEventArgs)
ShokoServer.exe: N 00183
System.IO.FileSystemWatcher.CompletionStatusChanged(errorCode As UInt32, numBytes As UInt32, overlappedPointer As NativeOverlapped*)
ShokoServer.exe: N 00617
System.Threading._IOCompletionCallback.PerformIOCompletionCallback(errorCode As UInt32, numBytes As UInt32, pOVERLAP As NativeOverlapped*)
ShokoServer.exe: N 00125
here is the logs itself for that day. crashed at the very end ofc :D
https://puu.sh/sxZma/0d32072b81.zip
Note, just making this issue to make sure its nothing wrong with release :D

Seems to a path problem, seems you have a path too long, on one of watched folders. Nothing we can do about it...


Add phone number length

Any plans to include valid phone number lengths by country? Are you open to contributions? My plan would be to port the data already available in node-phone to country-data.
I don't know if it would be too hard to maintain that information up to date.

I'd be wary of adding the data directly as I think it would be hard to maintain. Also it seems that node-phone already has most of it.
However it would certainly be worth adding a note to the country-data readme that node-phone exists. Patches welcome :)


Appengine Managed VMs

Logrus won't compile when using AppEngine Managed VM's because it's missing the IsTerminal() function, since there is a build flag on the terminal_notwindows.go file. Removing this flag allows it compile. The package won't run on regular app engine anyway since there are other syscalls.
Is there any reason to keep this build flag?

No, feel free to submit a PR to remove it.

https://github.com/Sirupsen/logrus/commit/0b189e019aabcec0af8e433b10b3073ad9382b44


Default theme constrast problems

We have lot of elements with light gray bg and white fg (or vice versa) on demo (https://storefront-demo.e-com.plus/), it's a big accessibility problem.
I think secondary color is so much close to default bg colors (white/light), and it can't be;

@vitorrgg pode me ajudar com isso aqui?

https://github.com/ecomclub/storefront/pull/74


[8.x] Reverse routes in cache

Fix #37639
When there are multiple URL matches, symfony will return the first match,  but in laravel, it should return the last matching route.

This is a gigantic breaking change as this completely reverses the logic for, for example, the following use case:
Route::get('/foo', fn () => 'without param');
Route::get('{slug}', fn () => 'with param');

I doubt this is the solution to the above issue. I'm investigating it, thanks.


Trace what happened to two published records which are missing in the updated records

These two records are published in the current version (2024-12-30) of the vocabulary registry, but they are not in the XML records in this repository, thus, they cannot be accessed via the CMDI editor:

https://registry.vocabs.dev.clariah.nl/reco (it was in the previous version in Gitlab: https://code.huc.knaw.nl/tsd/clariah/cmdi-vocabs/-/blob/6211056039724027a6cef0661fb4a9c89bd78dec/reco.cmdi). --> to keep
https://registry.vocabs.dev.clariah.nl/participation (it was in a previous version in Gitlab: https://code.huc.knaw.nl/tsd/clariah/cmdi-vocabs/-/blob/6211056039724027a6cef0661fb4a9c89bd78dec/participation.cmdi) --> to discard

No idea why they got lost :-( But if they follow the latest version of the profile you can just add them to the records directory with the next number in line, e.g. record-637.xml.


[RFC] Make some cases of Array#==(Tuple) and Tuple#==(Array) return true

This could allow for some nice and efficient comparisons, for example bytes[0..2] == {0x00, 0x02, 0x03} instead of  bytes[0..2] == [0x00, 0x02, 0x03], which would save one array allocation.

I thought it would work that way already. It seems common sense. At the very least, I think Array#=== should work like that.
At the same time I wonder if it could be possible, during compilation, to turn array literals into tuples for efficiency if they're treated like they could be latter in the code.

I think we can add these comparisons. Ideally comparing Array, StaticArray, Slice and Tuple between them should work: the comparison would be by length and contents. But I'd like to know waj's opinion, let's wait until he comes back :-)

any update on this one? :) @waj

@waj please change the draft label to accepted or close the issue when you had time to form your opinion on this.

Guys is there a roadmap about those classes Slice, StaticArray, etc.? Such as this that helped in 2008 to understand Ruby classes inheritance, but maybe related more to the implementation to teach how can I use low level Crystal features for program performance.

+1
0.0 == 0     => true
[0] == {0}   => true

There hasn't been any feedback from @waj for two and a half years. So maybe this needs to go on without his opinion.
There has not been any argument why this shouldn't be implemented.
It makes sense to be able to compare collections of different types directly. And I'd add Deque to the list, it is a similar data structure.

Overriding #== sounds like a bad idea. An Array should never be a Tuple. A Char should never be a String. Somewhere here was already a lengthy discussion of whether 0 and 0.0 should refer to the same entry in a Hash(Int32 | Float64, V). Ruby is able to circumvent this because it has Object#eql? and Object#== separately; unless we have the same facilities, we shouldn't define these comparisons with #==.
It seems to me we could define Indexable#same_elements?(other : Indexable) : Bool instead, or even extend it to Enumerable (see #1452 also):
[0, 2, 3].same_elements?({0, 2, 3}) # => true

The Indexable case would be equivalent to:
def same_elements?(other : Indexable)
  size == other.size && (0...size).all? do |i|
    unsafe_fetch(i) == other.unsafe_fetch(i)
  end
end

Maybe even [0, 2, 3] === {0, 2, 3}??

So, we have === to compare Char and UInt8, I think having === to compare such types could be good, but I don't know.

Not possible at this point, because Tuple already defines #===(Tuple) to compare elements using case equality.

An overload #===(Array) can be possible  @HertzDevil .

Actually:
module Indexable(T)
  def equals?(other : Indexable)
    equals?(other) { |x, y| x == y }
  end
end

Java's List interface (which is roughly equivalent to Indexable) expects equals? and hashCode to be generically implemented by implementing classes (Javadoc).
So I wouldn't be opposed to follow that example and define generic implementations for #hash and #<=> in Indexable and include Comparable(Indexable) (cf #10065).

It turns out #hash is already defined on Indexable. Seems nobody mentioned that so far.
So there's actually a discrepancy:
[0, 2, 3] == Deque{0, 2, 3}           # => false
[0, 2, 3].hash == Deque{0, 2, 3}.hash # => true

That shouldn't be.
I'm now convinced that implementing a generic Indexable#==(Indexable) is a good idea, so there is #10112
Btw. for Tuple both are false because Tuple overrides hash (discussed in #10065).

I don't see how hash helps the argument or what exactly "shouldn't be" 😕

hash is related to equality in the way that if two values are equal, they should produce the same hash. This consequence is already realized in Indexable#hash. So stepping to equality is nearby. With the related discussion on comparability (#10065) it receives an even more pronounced argument.

But hash equality doesn't imply equality.
I can't see how a deque is the same thing (equal) as an array. Or any other collection for that matter.
We can probably add a same_elements? method. But it's not equality.

Yeah, it doesn't. But when we already use a generic hash implementation for Indexable, it's not hard to imagine that it could also define equality.
Let's not talk about equality but comparability: Int32, UInt8 and BigIntall represent the same concept - a number - expressed in different data types with different specific properties. But the values are nevertheless comparable.
When I have an Array of numbers and a Deque of numbers we should be able to compare them, too. It's a similar story: Both model the same concept - a list of values as defined by Indexable - even though the concrete implemenation of the data type differs. Based on the common Indexable interface generic comparability can be defined. This is the idea of #10065.
Comparability is expressed in the Comparable interface which also includes a #== method, thus all values that are comparable also define equality as an implication.
The equality operator == is probably at fault, because it is overloaded with different interpretations. It can mean "be exactly the same thing" including internal data type respresentation or it can mean "represent the same value". The definition of Comparable#== definitely follows the latter. So do other implementations of #== which define equality regardless of data type.
Maybe we should have separate methods for both concepts. But I actually don't see much use cases for the stricter definition, which could be expressed as a == b && a.class == b.class. Where do you actually need that specifity? Defining comparability and equality for all indexables doesn't break a single spec in this repo. Sure, it essentially widens the definition range, but still nothing depends on equality being tied to the data type.

I think what you say makes sense. Plus it's probably harmless to allow such comparisons, and it can actually be useful.

I have made up my mind, I am definitely against making Indexable Comparable(Indexable).
The most I'd allow is Comparable(self) with the possible addition of <=>(Indexable) as @HertzDevil suggests.

One of your arguments in the PR:

Regarding downsides to this, I don't think there are any.

If you keep moving in that direction, you can end up with /foo/ == "foo" because why not.
This is a strongly typed language, don't forget that.

One particular situation is, imagine a type that happens to be indexable but also has other fields.
If you add that field to your class, and you want it to be equal only to other instances that have the same field, you're out of options, other indexables will forcibly compare equal to yours. You also have your hands tied in terms of the hash implementation.

In fact, it doesn't need to include other fields.
Check out this VideoFrame class. Should a video frame ever be equal to an array?
Should a Matrix ever be equal to a deque?

Good points.
I actually don't know what's the use case behind all of this.

The most I'd allow is Comparable(self) with the possible addition of <=>(Indexable) as @HertzDevil suggests.

Comparable(self) could be an option, but it's very limited and highly restricts usability because indexables can have different union types. So IMO that's not a viable option.
<=>(Indexable) without Comparable(Indexable) makes no sense whatsoever. Either Indexable is comparable or not. If you can define a generic <=> method, you can also include Comparable which only enhances that method by adding useful helper methods.

If you keep moving in that direction, you can end up with /foo/ == "foo" because why not.

No that's not the direction I'm pointing. /foo/ == "foo" is like "1" == 1 or "a" == 'a' == 97 comparing different concepts. But {1, 2, 3} and [1, 2, 3] are similar concepts. They're both lists of things (=Indexable) and that shouldn't hinder to compare them when it's simplified just a matter of stack vs. heap allocation.

This is a strongly typed language, don't forget that.

== is already defined for any combination of types and just returns false by default. So this really isn't strict typing.

One particular situation is, imagine a type that happens to be indexable but also has other fields.

Yes, that would be a limitation. But is there any practical relevance to that? Or in other words: A compound type that is decisively more than a container of items probably shouldn't include Indexable anyways.
The examples you mentioned seem to fit perfectly fine with Indexable and its comparability. I don't see any reason why you shouldn't be able to compare them with other data types.
As mentioned above Java's equivalent List type works like this and it doesn't seem to be a problem.


Connection status stuck with "Synced/Connected" while disconnected.

See https://github.com/Chia-Network/chia-blockchain/issues/1076
While the mentioned above is happening, GUI still shows Synced/Connected, despite it not being true.
debug logs in the issue referenced above.

RC3/4 specifically had a fix for this. Please re open if it persists in RC4.


Security hardening for AKS agent node host OS for image version 18.04 ubuntu

[Enter feedback here]
https://docs.microsoft.com/en-us/azure/aks/security-hardened-vm-host-image
above page still mentions about the image version 16.04 and CIS policies however AKS is using 18.04 ubuntu as default image .

Document Details
https://docs.microsoft.com/en-us/azure/aks/security-hardened-vm-host-image
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d622f9d9-1e69-39ab-d32d-566e8a5b3f1a
Version Independent ID: 007268cc-d231-7376-27c8-e968507247c5
Content: Security hardening in AKS virtual machine hosts - Azure Kubernetes Service
Content Source: articles/aks/security-hardened-vm-host-image.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: sraghuwanshi

@sandyjec, Thank you for your feedback. We have shared the same with the content authors.

Thank you for the feedback.
We have added an item to our backlog and will prioritize accordingly.
#please-close


writing integer values

After last change when string fields are automatically quoted, one lost the ability to tweak formatting of integer values.
They are written like value=42i, otherwise influxdb handles all numbers as a float.
Now it will write this value as a quoted string.
I'm not sure how to handle this, but what comes to mind:

try to parse string parameter as int if it ends with i
use Variant type as a fields AA value type instead of string so it can contain bool, int, double and string values and format them based on the type

Both of your solutions are valid. I'll fix this either way. I had no idea about the i suffix and only found out about quoting strings when my inserts failed without them. Thanks for reporting the issue.


Update to 1.21.4

Hi ! Is an update to 1.21.4 possible? Thanks a lot !

Up !

Ah I'm sorry xD
Yeah sure, I will update it ^^


first release in maven repo?

Hello @holly-cummins ,
when do you plan to have a first release in maven central repo?
Best Regards
Alex

Hi Alex, thanks for the nudge. I've been meaning to do it for several days but kept getting sidetracked. :) (I was initially waiting for #29, which fixes #11, so that the extension offered something over running with a normal dependency). I'll try to do it today.
Be aware that

it will only be for pact provider, not the consumer ... consumer will be early in the new year (I hope)
#28 is still a problem, so that the extension needs to be added without test scope, even though test scope is obviously the correct scope for a pact extension

Hi Alex, both consumer and provider extensions are now released.
    <dependency>
      <groupId>io.quarkiverse.pact</groupId>
      <artifactId>quarkus-pact-provider</artifactId>
      <version>0.2</version>
      <!-- <scope>test</scope>--> <!-- See https://github.com/quarkiverse/quarkus-pact/issues/28; for dev mode tests, the scope cannot be test -->
    </dependency>

    <dependency>
      <groupId>io.quarkiverse.pact</groupId>
      <artifactId>quarkus-pact-consumer</artifactId>
      <version>0.2</version>
      <!-- <scope>test</scope>--> <!-- See https://github.com/quarkiverse/quarkus-pact/issues/28; for dev mode tests, the scope cannot be test -->
    </dependency>

Thank you very much
I tried the consumer today.
Works as expected.


(PUP-2958) Reclaim stale ssl lockfiles

Previously, puppet's ssl state machine would fail to run if the ssl lockfile
existed, no matter what it's contents were. Change the state machine to use
Puppet::Util::Pidlock instead which is capable of detecting if the pid refers
to an already running puppet instance.

Acquires empty lockfile:
[root@rllkgfa3qeth9t6 ~]# touch /etc/puppetlabs/puppet/ssl/ssl.lock
[root@rllkgfa3qeth9t6 ~]# puppet agent -t --certname something
Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for something
Info: Certificate Request fingerprint (SHA256): CC:DE:BF:B5:AA:52:EE:6B:9A:58:BE:AE:D5:9E:C2:E5:B5:6F:21:4F:BB:C4:C7:9F:A2:E8:95:8C:35:0C:A3:BC
Info: Certificate for something has not been signed yet
Couldn't fetch certificate from CA server; you might still need to sign this agent's certificate (something). Exiting now because the waitforcert setting is set to 0.

Acquires lockfile containing non-puppet pids:
[root@rllkgfa3qeth9t6 ~]# ps -p 1
  PID TTY          TIME CMD
    1 ?        00:00:01 systemd
[root@rllkgfa3qeth9t6 ~]# echo 1 > /etc/puppetlabs/puppet/ssl/ssl.lock
[root@rllkgfa3qeth9t6 ~]# puppet agent -t --certname something
Info: Creating a new RSA SSL key for something
Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for something
Info: Certificate Request fingerprint (SHA256): CC:DE:BF:B5:AA:52:EE:6B:9A:58:BE:AE:D5:9E:C2:E5:B5:6F:21:4F:BB:C4:C7:9F:A2:E8:95:8C:35:0C:A3:BC
Info: Certificate for something has not been signed yet
Couldn't fetch certificate from CA server; you might still need to sign this agent's certificate (something). Exiting now because the waitforcert setting is set to 0.

Faills to acquire when pid references background puppet process:
[root@rllkgfa3qeth9t6 ~]# systemctl start puppet
[root@rllkgfa3qeth9t6 ~]# pgrep puppet
26036
[root@rllkgfa3qeth9t6 ~]# echo 26036 > /etc/puppetlabs/puppet/ssl/ssl.lock
[root@rllkgfa3qeth9t6 ~]# puppet agent -t --certname something
Error: Could not run: Another puppet instance is already running; exiting


Create dataset india_news_headlines_dataset

uid: india_news_headlines_dataset
type: processed
description:

name: India News Headlines Dataset
description: This news dataset is a persistent historical archive of noteable events in the Indian subcontinent from start-2001 to end-2020, recorded in real-time by the journalists of India. It contains approximately 3.4 million events published by Times of India. A majority of the data is focusing on Indian local news including national, city level and entertainment. The individual events can be explored in detail via the archives section on the agency website.
homepage: https://www.kaggle.com/therohk/india-headlines-news-dataset
validated: True

languages:

language_names:

English

language_comments: Indian English
language_locations:

Southern Asia
India

validated: False

custodian:

name: Rohit Kulkarni
in_catalogue:
type: A private individual
location: India
contact_name: Rohit Kulkarni
contact_email:
contact_submitter: False
additional: https://www.kaggle.com/therohk
validated: False

availability:

procurement:

for_download: Yes - it has a direct download link or links
download_url: https://www.kaggle.com/therohk/india-headlines-news-dataset
download_email:

licensing:

has_licenses: Yes
license_text:
license_properties:

public domain

license_list:

cc0-1.0: Creative Commons Zero v1.0 Universal

pii:

has_pii: Yes
generic_pii_likely: very likely
generic_pii_list:

names

numeric_pii_likely: none
numeric_pii_list:
sensitive_pii_likely: unlikely
sensitive_pii_list:

political opinions

no_pii_justification_class:
no_pii_justification_text:

validated: False

processed_from_primary:

from_primary: Taken from primary source
primary_availability: Yes - they are fully available
primary_license: Unclear / I don't know
primary_types:

web | news or magazine website

validated: False
from_primary_entries:

the_times_of_india

media:

category:

text

text_format:

.CSV

audiovisual_format:
image_format:
database_format:

.CSV

text_is_transcribed: No
instance_type: article
instance_count: 1M<n<1B
instance_size: 100<n<10,000
validated: False

fname: india_news_headlines_dataset.json

Please note that although this dataset is already available at https://huggingface.co/datasets/times_of_india_news_headlines, it requires MANUAL download.

DONE: https://huggingface.co/datasets/bigscience-catalogue-data/india_news_headlines_dataset
Example:
{'publish_date': 20010102,
 'headline_category': 'unknown',
 'headline_text': 'Status quo will not be disturbed at Ayodhya; says Vajpayee'}

https://huggingface.co/datasets/bigscience-catalogue-lm-data/lm_en_india_news_headlines_dataset


Verifying only K3 subset of proof indices

Codecov Report

Merging #19 (902c12c) into main (0c9d4c3) will increase coverage by 0.6%.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##            main     #19     +/-   ##
=======================================
+ Coverage   95.5%   96.2%   +0.6%
=======================================
  Files         11      12      +1
  Lines        788     927    +139
=======================================
+ Hits         753     892    +139
  Misses        35      35

Impacted Files
Coverage Δ

src/config.rs
0.0% <ø> (ø)

src/lib.rs
100.0% <ø> (ø)

src/prove.rs
94.9% <100.0%> (ø)

src/random_values_gen.rs
100.0% <100.0%> (ø)

src/verification.rs
92.2% <100.0%> (+0.7%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Mixin request for FCNoteEntryLayers

Is your feature request related to a problem? Please describe.
This issue arose due to a common and justifiable misunderstanding about the intent of the built-in eachentry and eachentrysaved functions. It is important for a Finale-Lua programmer to understand how these work, and for this reason they are open source. They are written in Lua, so you don't have to know C++ to understand them.
The basic problem is that the eachentry... functions create local instances of variables from which they feed entry instances back to the loop. If the loop saves those instances out to a table or other variable external to the loop, the underlying C++ structures will go out of scope when Lua garbage collection runs. If your code then accesses one of these instances, Finale crashes. The eachentry... functions facilitate one-by-one entry processing but should never be used for aggregate entry processing or analysis.
What's needed is an easy way to traverse entries, allowing them to be cherry picked and processed after the loop finishes.
Describe the solution you'd like
I propose adding an FCX mixin for FCNoteEntryLayers (or FCNoteEntryLayer, see below) that would allow it to have its own eachentry iterator function. Then you could do something like:
local entries = mixin.FCXNoteEntryLayers()
entries:LoadForRegion(finenv.Region())
for entry in entries:eachentry() do
   -- cherry-pick entries for later processing
end
-- process cherry-picked entries.
entries:SaveAll() -- if you made changes to the entries

Describe alternatives you've considered
The only other alternative I can think of is standard library functions, but a mixin seems like a better DX.
Additional context
The biggest issue is that FCNoteEntryLayers is not exported into Lua at the moment. So until that could be added to RGP Lua (and/or if we want to support this with JW Lua), we might need to make this a mixin on FCNoteEntryLayer and create a "fake" collection in Lua.
Another issue to be aware of is that this loop would traverse layers with the layer number as the top loop variable. Programmers would have to get used to a different sequence of entries than for the standard eachentry... functions, unless we wanted to write a lot of Lua code in the mixin to make it the same.

I've already thought of an alternative that might be better:
Wrap a table of FCNoteEntryCell instances to look like a collection, perhaps FCXNoteEntryCells, but I'm not sure if it's okay to create mixins on nonexistent Finale classes. (It might not be a big deal to add FCNoteEntryCells to the PDK Framework, but depending on that would require updating RGP Lua.)
Then our eachentry function could be an almost literal copy of the built-in eachentry function, and it would feed entries in the same order.

At the moment it's only possible to add a mixin to a Finale class that exists, and even though you can add a mixin to __FCCollection, for example, you can't instantiate it so that doesn't solve the issue here.
That could be changed, I guess, to use a dummy object like an FCString, and then completely ignore the underlying metatable altogether (what would you call it? FCP* perhaps for polyfill?).  I don't know whether it's worth it to do that (the mixin library itself would need some modifications to enable that to happen) or whether we're better off just doing standard Lua OOP with just a regular table.

I'm thinking a simple table wrapped as an object is the way to go. Using a fake class like FCString seems really unwise to me.

I'm not familiar enough with how mixins work to comment on that, but +1 to the idea in general.

Here is another idea that requires no work in this repo. (But does require an RGP Lua update.)

Add finale.FCNoteEntryCells collection class to the PDK Framework.
Enhance the built-in eachentry iterator function to accept an optional third parameter that is an FCNoteEntryCells instance. If the parameter is supplied, eachentry adds ever instance of FCNoteEntryCell that it creates to this collection.

With this you could write the following:
local entries = finale.FCNoteEntryCells()
for entry in eachentry(finenv.Region(), nil, entries) do
    -- cherry pick entries into a table
end
-- process cherry picked entries
entries:SaveAll() -- if any changes needed to be saved.

I think this can be implemented fairly easily. The devil is always in the details.

Would a pure Lua solution be more preferable? That way any author who uses it doesn't need to bump the script's MinJWLuaVersion.

@rpatters1 Any further thoughts on this? If you still want a Lua solution, I can start working on it.

I think a Lua solution makes sense. My original idea of using FCNoteEntryLayer may not be the best, though, because I think the new iterator should follow the same order and precedence as eachentry. So probably the pure Lua solution will be a flavor of the actual eachentry function that collects its FCNoteEntryCell instances into a table.
But those are just ideas. Feel free to be creative.

The only class that has the referencing issue is FCNoteEntry, so there is no problem with cherry-picking cells or staves. (Anyway, I believe eachstaff just feeds a staff number.)
As for eachentrysaved, I think rather than duplicate that function, the preferred pattern would be:

cherry pick with mixin.eachentry
save cherry picked items as needed with entry:GetParent():Save()

The only issue I see is that the underlying FCNoteEntryCell item might be saved multiple times, but I'm not aware of any reason it won't work.

I should add that FCNote has the same issue as FCNoteEntry. (because FCNoteEntry is a collection FCNote instances.) A mixin.eachnote function based on mixin.eachentry might be handy some day. But I'd suggest waiting till it is a requirement to implementing it.


JSONLD should have both free text and ISO 8601 dates

dc:date = free text
dcterms:created = ISO 8601

It would be nice if you could just stick the data from the MARC 260, e.g. "Mainz : Gutenberg-Gesellschaft, 1926-", somewhere (it's pub_created_display in OL) in the dc (not terms). That would cover publisher and date the way users expect to see them and save formatting headaches.

Of course there are 10 different vocabs that model "publication event" (because that's what you'd really want) but none that leave space for a label.

I'm currently using the pub_citation_display which omits the date, but I'd be fine with switching to pub_created_display which includes it for dc:publisher.  Of course we could use some other vocab to model a publication event, but I think including the publication date in dc:publisher follows the spirit of the law.

but I think including the publication date in dc:publisher follows the spirit of the law.

was afraid to suggest this, but maybe two wrongs in this case...

And how should we handle date ranges for dcterms:created?  EDTF?

ISO can do ranges, right? Just separate with a / I think?

Of course it would be nice if the spec were free, but https://en.wikipedia.org/wiki/ISO_8601#Time_intervals

Or https://www.w3.org/2006/time#, which is what the finding aids site does:
http://findingaids.princeton.edu/collections/AC044.rdf

I'd rather just separate the vaues with a / (I thought that was special to EDTF not part ISO 8601)

Yeah, I think so too.


Reverted loading module in DUT prepare step, minor fixes

Signed-off-by: Tomasz Rybicki<EMAIL_ADDRESS>

Hello @tomaszrybicki! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file tests/conftest.py:

Line 20:1: E402 module level import not at top of file

In the file tests/utils/installer.py:

Line 71:1: E302 expected 2 blank lines, found 1


Resolved classical Bison IF/THEN/ELSE shift/reduce conflict using the…

… textbook solution
(Oreilly 'Flex & Bison' page 188-189)
The current solution simply allows the Bison output to be used if it has exactly 2 conflicts.
This is less robust than this solution which explicitly solves these two if/then/else conflicts (one for normal if/then/else, the other within generate blocks)
patch passed 'make test'.

I'm pretty sure I read in the dragon book that shift/reduce conflicts for ELSE are fine. So I claim that the old code was the textbook solution!  :)
Just kidding, thanks for the patch. That's obviously an improvement.


Real number factors

This is too dated and lacks detail for action. Let's close this and reopen or create a new issue if needed.


I am not able to reproduce result of Imagic_Stable_Diffusion.ipynb

Describe the bug
I follow this Imagic_Stable_Diffusion.ipynb, however, i got exception of:
TypeError: call() got an unexpected keyword argument 'text_embeddings'
when i run:
with autocast("cuda"), torch.inference_mode():
images = pipe(text_embeddings=edit_embeddings,
height=height,
width=width,
num_images_per_prompt=num_samples,
num_inference_steps=num_inference_steps,
guidance_scale=guidance_scale,
generator=g_cuda
).images
Then I looked at API , I changed from text_embeddings=edit_embeddings  to prompt_embeds=edit_embeddings.
But the image generated not changing at all, same as original images. I tried obama and bird images provided by this notebook.
Please guide what the problem is , thanks!
Reproduction
with autocast("cuda"), torch.inference_mode():
images = pipe(text_embeddings=edit_embeddings,
height=height,
width=width,
num_images_per_prompt=num_samples,
num_inference_steps=num_inference_steps,
guidance_scale=guidance_scale,
generator=g_cuda
).images
got exception: TypeError: call() got an unexpected keyword argument 'text_embeddings'
Then changed to :
with autocast("cuda"), torch.inference_mode():
images = pipe(prompt_embeds=edit_embeddings
,
height=height,
width=width,
num_images_per_prompt=num_samples,
num_inference_steps=num_inference_steps,
guidance_scale=guidance_scale,
generator=g_cuda
).images
Logs
No response
System Info
used this: https://colab.research.google.com/github/ShivamShrirao/diffusers/blob/main/examples/imagic/Imagic_Stable_Diffusion.ipynb

Exactly the same for me. I then deleted the "--use_8bit_adam" option in the training code. The outputs start to change. But still not as good as published--either too different from the reference image, or the same to it. I guess maybe a very careful tuning of the parameters are needed. Or, the SD version is not as good as using the imageN model.

Hi, anyone have tried this? I can't reproduce the result after fine-tuning for a long time? @ShivamShrirao How did you get the same result as the paper? Many thanks!

Hey sorry. The API changed a bit later and doesn't take text embeddings into account rn. I didn't get to update the imagic code.

@ShivamShrirao  I change the text_embeds to be prompt_embeds so the code actually works. It gives me some generated results. But the problem is that it is very difficult to get the results as the paper.


Add gulp to package.json scripts for ease of CI.

When using themes through git submodule some steps need to be ran in CI. One of these being the gulp default run. By adding this to the package.json CI setups for Hugo can use npm i && npm run gulp default instead of having to install gulp separately.

If you could add the hacktoberfest label to the repo I'd appreciate it as well, either way 😄. Trying to get my PR's, but also trying to ease dev experiences.

@AgentEnder Thanks for your PR. Even if I would recommend to use npx gulp instead of npm run it doesn't hurt to support this way as well.

Hey, thanks :)
The reason I prefer this method with gulp already being a node_module is that using npx installs gulp again instead of using the version from package json.


changing behavior of "split" flag for AE events

Modified code to produce to event output at individual left-right channels, and stereo channel simultaneously, for AE events.
"--split true" produces output at all 3 channels: /vPreProcess/AE:o, /vPreProcess/left:o, /vPreProcess/right:o
"--split false" produces output only at /vPreProcess/AE:o channel
Behavior for APS output left unchanged

Looks good @ghoshsuman there is no problems, but just some functionality I would like. I think the best (to try to save computation as much as possible) is to have 2 flags --split_stereo and --combined_stereo. If --split_stereo is true you output on left/AE:o and right/AE:o, (we'll need to change these port names) if --combined_stereo is true you output on /AE:o. If both are true you output on all ports. If --split_stereo is false then --combined_stereo should default to true and output on /AE:o anyway.
Does it make sense?

Okay. I'll make the changes. When both flags are forced to be false, should I output on /AE:o anyway?

When both flags are forced to be false, should I output on /AE:o anyway?

If --split_stereo is false then --combined_stereo should default to true and output on /AE:o anyway.

yes

Added the functionality you asked, for both AE and APS outputs. Please check.


Merge data from 2 different accounts

Describe the Issue
I, with no intention, used another e-mail (because I have 2 emails) and I created another account. But I did some exercises and progress my status, but now I´m only want to use 1 account. Is there a way to delete the other account but transfer my points to the old account?
Affected Page
not applied
Steps to Reproduce
Logged 2 accounts by mistake
Expected behavior
not applied
Screenshots
No response
System
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
Additional context
No response

Please contact<EMAIL_ADDRESS>GitHub isn't a suitable place to discuss private information.

why closed? when this correction will be published?

Because your personal data should not be discussed in a public topic, and for it to be corrected you need to discuss it with the support section, not the dev team.
Or am I misunderstood you and you want a feature to be add? 🤔


[10.0] Proposal: unify function signatures with the same name

Is your feature request related to a problem? Please describe.
Sometimes I'am frustrated with inconsistency in function names and their signatures.
First example:
Field and TD classes have two methods:

setter canSee(bool $value): self
getter isSee(): bool

Layout class have only one method: a callback-style getter
canSee(Repository $query): bool
I always mix them and forget which is one.
Second example
TD class: render(Closure $closure): self
Field class: render()
Why I picked TD vs Field: usually I want to display the same piece of information (model field) on Table/List screen and on Model Details/View screen. I like tweaking render in TD - it's easy and straitforward using render callback. But it's not so easy when rendering fields on Details/View screen.
Additional context
Changing functions signatures or names is a big breaking change. Not sure if it's worth.

Hi I started to change the visibility functions. Now Fields/Layouts/TD and have a common trait.
Without any restrictions. Now you can do this:
Input::make()->canSee(false);
TD::make()->canSee(false);

Layout::rows([])->canSee(false);

But now the definition inside the layer is different
// before
public function canSee(Repository $query): bool
{
    return ...;
}

// after
public function isSee(): bool
{
    return ...;
}

As for the render method, I'm not sure how best to change this.

How I see render functions:

we need public function for end user to defined a render callback (like current TD::render(Closure $closure))
and internal function which actually returns final view or html (like current Fieldable::render() and TD::buildTh() and TD::buildTd($repository)

I like current TD naming and propose following naming scheme:

public function render(Closure $closure) for end user to define a callback if needed (in both classes: TD and Fieldable).
keep TD::buildTh() and TD::buildTd($repository), rename Fieldable::render() to Fieldable::finalRender() or Fieldable::buildHtml()

What should the render method do for the field? Transfer function in HTML circuit or only the value?
Perhaps as a modifier rather than a final value?
Input::make('price')->render(function($price) {
  return $price * 72;
})

// output
<input name="price" value="144">

Or should we pass everything from query? Or html?

One interesting thing about render process:
TD::buildTd($repository) accepts $repository, so TD::render(Closure $closure) - the $clouse also accepts $repository, means in TD render process we have access to the full model of the currently rendered row.
Field class keeps only value, not the whole Model, not $repositry.
I propose to pass the $closure in Fieldable::render(Closure $closure).
I found several situations where I need the whole model information during render process, examples:

I want to render amount with red color like this: if ($model->deviation > $model->amount * 0.1) { /* wrap render result in ... */ }
I want to render quantity with unit of measure like this return $model->quantity . ' ' . $model->uom;

Currently it's easy in table layout having $repositry argument in TD render $closure.
I think it would be helpful if both TD and Fieldable render closure will accept $repositry.
Example:
// For list/table screen
TD::make('quantity')->render(fn($repository) => $model->quantity . ' ' . $model->uom);

// For view screen
Label::make('quantity')->render(fn($repository) => $model->quantity . ' ' . $model->uom);

Or should we pass everything from a query? Or HTML?

From my perspective render(Closure $cloure) should return HTML (as it currently works in TD):
Example of flexibility:
Input::make('quantity')->render(function($repository) {
  $value = $repository->quantity;
  $uom = $resitory->uom; // unit of measure
  return '<input type="text" value="'.$value.'" name="quantity"> '.$uom.'' . ;
})

What I don't like in my example above: I have been forced to create input tag manually. Need to think about it.

I took some time to think and came to the following conclusion.
In the column class, we define parameters that do not affect the output, values in a cell for example:
TD::make('updated_at', __('Last edit'))
    ->filter(...)
    ->align(...)
    ->sort()
    ->render(function (User $user) {
        return $user->updated_at->toDateTimeString();
    }),

That is, in this example, the result of calls to the align, sort, etc. are not replaced by the same render. In your example, calling all the previous methods does not make sense, for example:
Input::make('quantity')->required()->render(function($repository) {
  $value = $repository->quantity;
  $uom = $resitory->uom; // unit of measure
  return '<input type="text" value="'.$value.'" name="quantity"> '.$uom.'' . ;
})

There is no point in calling the required method. It doesn't even matter which class we use, Input or Checkbox.
Therefore, I still tend to the closure function returning only the value attribute:
Input::make('price')->disabled()->render(function($repository) {
  return $repository->get('price') * $repository->get('course');
});

This fits with how TD works and will have the same effects. What do you think about it?

There is no point in calling the required method
Good point!

On the other hand when Field's render only calculates the value (like price * course) - this is pointless to have the render method. Calculation should be in query or in a Model class function getFinalAmountAttribute method.
Semantically I feel that render method should return the final html representation. At this point I still have no future ideas about useful and valuable Field::render(Closure $clouse) implementation.

Since we haven't reached any consensus on the render method, version 10.0 was released without any changes.
canSee/isSee are included in the released 10.0.0


Fix infinite loop with ie11

Fixes #4

Codecov Report

Merging #7 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master     #7   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           5      5
  Lines         115    116    +1
  Branches       14     15    +1
=====================================
+ Hits          115    116    +1

Impacted Files
Coverage Δ

src/storage.ts
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Hey @michaelbirchler, first of all thanks a lot for your contribution!

I'm not sure I quite understand what's going on here, could you explain how this solves the issue?
Also the code seems a little strange to me, I mean the comparison between two values and then with false. Wouldn't event.newValue !== event.oldValue be enough?
I don't have a Windows installation handy at the moment, but I saw you mentioned the original reporter in the issue so let's see what they have to say.

I'm not sure I quite understand what's going on here, could you explain how this solves the issue? I mean, I'm guessing the event handler is being called constantly with the same value but I don't see how that would happen. Could this be related to #5 and be solved once that's fixed as well?

I'm using the useSessionStorageReducer hook on my app, while it worked on every tested browser expect on IE 11. On IE 11 I've experienced an endless loop. Adding the condition prevented the error to happen again. With IE 11 the event listener window.addEventListener('storage', handleStorageChange); compared to others browsers the event is triggered on every page load with IE11. Yes, this this pull request could also resolve #5.

The code seems a little strange to me. I mean the comparison between two values and then with false. Wouldn't event.newValue !== event.oldValue be enough?

@soyguijarro yes, of course you could do it with event.newValue !== event.oldValue, it's just a matter of taste :-). I've changed the condition with c96d3426d7d5ec0cdbeaa90ca509d5d4e672eb70.

I've noticed that this pull request does not resolve IE11 crashing if multiple dispatch events in combination with useSessionStorageReducer are processed successively.

I'm working on a full rewrite of the library, so this PR is no longer relevant. I'll take the issue into account in the new version though, thanks for taking the time to contribute!

Did the full rewrite lead anywhere? Im hitting this issue on 4.0.1.


[Meta] Add pages about resources & resource detection to concept & languages

Add a new page to “concepts“ that talks about resources & detection in a general way
If available&applicable, add a page about resources & resource detection for each language, similar to this one:

What resources are detected automatically?
Adding resources via OTEL_RESOURCE_ATTRIBUTES
Adding resources in code
Adding a (non default) resource detector (e.g. container)

TODO:

[ ] Concept
[ ] C++
[x] .NET
[x] Erlang/Elixir
[x] Go
[x] Java
[x] JavaScript
[x] PHP
[ ] Python
[ ] Ruby
[ ] Rust
[ ] Swift

Note, I added all languages to get started, if this is not applicable for some of them, we can remove them.

Added also that we need a page that talks about the concept of resources and how they are detected

Wonder if we could pin this one and simlar, @svrnm

I list them here: https://github.com/open-telemetry/opentelemetry.io/issues/3686, but we can also pin some of them directly


[FEATURE] Improving recovery times for non-graceful node failures

Is your feature request related to a problem? Please describe (👍 if you like this request)
Many use cases for Longhorn rely on quick only-once semantics: RWO, the NFS Share Manager for RWX, the s3gw for the S3 Endpoints, and by extension the workloads on top (such as VMs managed by Harvester et al).
To ensure data integrity, we must ensure the volumes are only made available once; to improve service availability, we need to lower the time needed to ensure that failed nodes are truly gone (and identify them correctly to start with).
Right now, our recovery relies on k8s to detect node failures, which takes a very long time due to timeouts and grace periods. (https://longhorn.io/docs/1.5.1/high-availability/node-failure/#what-to-expect-when-a-kubernetes-node-fails suggests "up to 7 minutes", which is often unacceptable in response to node failures.)
In Kubernetes 1.28, k8s has gained GA support for the concept of non-graceful node shutdowns (https://kubernetes.io/blog/2023/08/16/kubernetes-1-28-non-graceful-node-shutdown-ga/) and orchestrating recovery actions once the taint/flag is manually set. Currently, this relies on manual intervention - the administrator needs to ensure the node(s) is (are) really down to avoid risk of split-brain scenarios.
It'd be desirable to set this flag automatically to achieve a semblance of "High Availability" for a k8s cluster (and thus LH and all our consumers). This requires properly identifying the nodes to be evicted (similar to a consensus membership layer) and then triggering a correct fencing action (either by relying on a trustworthy watchdog on the node in response to a timed out membership, or an external fence using IPMI etc). Potentially, LH could keep additional metadata that ensures data from the evicted nodes is never again considered uptodate/clean.
One possible approach for this could be by leveraging the medik8s.io project, though this is fairly heavyweight and somewhat convoluted.
It might be more desirable to consider building a somewhat simpler implementation that just runs a single lightweight pod/container on every node to handle membership and fencing, and setting (removing) the taint as determined.
I'm adding this to LH because the storage layer is our lowest common dependency for many scenarios and everything else could build on top; however, it's conceivable that whatever we build/select here may be useful to projects such as Harvester even when LH isn't used.

Upstream document on fnext steps for the non-graceful node shutdown feature: https://docs.google.com/document/d/1gagpfyZRui-heHhn_KUK3cC7AtOvSzt7GOso6MuSTVI/edit
See also this section in the KEP itself: https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2268-non-graceful-shutdown#node-fencing
I think an operator to implements node fencing before setting this taint (and removing it) remains a viable option.

After a discussion, Giuseppe will investigate if/how medik8s can address this need, if minor enhancements will suffice, or if we need to go a different route entirely.
This is also documented in the context of OpenShift: https://access.redhat.com/documentation/en-us/workload_availability_for_red_hat_openshift/23.2/html-single/remediation_fencing_and_maintenance/index

Moving to analysis and design pipeline (zenhub).

@l-mb @jecluis @innobead
We need to understand what we want to explore other than what I've already done.
If you have specific questions about the test conducted, please do.

@l-mb
Installing medik8s seems to require the presence of the OLM that is a feature preinstalled on OpenShift.
This seems to be the recommended way to have medik8s; other (more direct) ways could be possible, but they are not documented (at least not in the medik8s website).

After the cordoning phase has completed, default SNR configuration implements the following strategy:

ResourceDeletion (default): This remediation strategy removes the pods and associated volume attachments on the node rather than the node object. This strategy helps to recover workloads faster. ResourceDeletion is the default remediation strategy.

@giubacc is this similar to https://longhorn.io/docs/1.5.1/references/settings/#pod-deletion-policy-when-node-is-down?

I think the only difference part is below. If yes, is it feasible to just improve the current pod-deletion-poilcy mechanism to achieve the goal here?

Technically, from my naive perspective, I'd say yes, but I suspect that the strategy implemented by NHC + SNR could be far more complex than simply put a "SchedulingDisabled" status over a failed node.
I suspect that the overall problem of fencing a node considering all the possible cases that could occur in a failure scenario is all but trivial.
NHC + SNR is a solution with the primary mission to solve with a "best effort" tentative the problem of declare a node actually death; and once the survived part of the cluster agreed on this, take some countermeasure.
Even with all the necessary precautions, this solution (NHC + SNR) still requires some assumptions such as the safeTimeToAssumeNodeRebootedSeconds parameter that is used by the survived nodes.
All this, to say that implement something that is a real "best effort" solution is something inherently difficult to obtain; I'd say it is better that a dedicated component cares about these aspects; a project with this as its main mission (this is my opinion obviously).
I have a question: LH currently permits to define strategies forcing workloads attached to RWO volumes to be forcibly deleted from a node marked as NotReady by Kubernetes; what are the rationales LH uses to establish that that node is really death?
Are there some timeouts used to assume the node has been rebooted?

Additional info:
Alongside with NHC + SNR  there is also the NHR + MDR.
MDR is the Machine Deletion Remediation remediator that is specifically designed for those k8s clusters where the Machine API is available.
These clusters are typically those provided by cloud providers where Machine API can be used to reprovision unhealthy nodes.
The API can be invoked to delete and spawn new machines at will.
Under these conditions, the problem to establish the state of a node is deterministic and you don't need to rely on assumed timeouts like the safeTimeToAssumeNodeRebootedSeconds.
With the availability of this API, the remediation of a failed node is far more fast and reliable for obvious reasons.
Have a look here for more info: https://www.medik8s.io/remediation/machine-deletion-remediation/machine-deletion-remediation/
Obviously if we want to test this remediator, we need to test it on a cloud environment where the Machine API is available.

SNR may be achievable from within Longhorn (if the pod/engine running on the node also implements hooking into /dev/watchdog, and stops refreshing that once it has lost communication with the rest of the cluster, the other nodes can then more safely assume that the node has indeed been fenced/cordoned).
However, the Metal3 integration medik8s offers external fencing (which is more trustworthy/robust, and probably integration well on the telco edge?), as well as the fence agents remediation. Plus node maintenance (though that's extra.)
Rebuilding all of that within LH seems complex? I wonder if we'd be better served by bundling medik8s either with LH or even separately (if we have use cases for this functionality independent of LH, e.g., Harvester/Edge).

I tend to see medik8s as a tool independent from LH and more fit as a thing shipped in Rancher as the "official remediator tool" to be used inside the Rancher ecosystem when you have to deal with stateful workloads or/and RWO volumes.

This could leverage all the projects in the Rancher catalog that need a feature like this to simply reference the medik8s plugin as the recommended and supported way to solve the node failure problem.

UPDATE
It is possible to use the SNR remediator and the MDR remediator alone, without the need to have also the NHC operator installed. the NHC operator is used mostly to trigger node failure events based on arbitrary complex conditions checked against the API server.
This means that integrating the SNR remediator could  be more simple: we can leverage the work already done for HAKube: https://github.com/SUSE/HAKube/blob/main/install/snr/self-node-remediation.yaml
In this case, this could be a more confined work within the LH scope.

Hello! I'm trying to dig up the CSI enhancement that would enable volume fencing and force unmount (container-storage-interface/spec#477). If that proposal is successful, COs could make much more aggressive and confident decisions about failing over stateful workloads between worker nodes.
I was wondering if there'd be any interest implementing a PoC for this capability in Longhorn? I suspect the big lift here would be making longhorn able to fence storage traffic based on (node,volume) pairs. I would try to prototype something myself, but I'm afraid I'm not familiar enough with the system to know where to start.