PDF Text is rendered as transparent

Attach (recommended) or Link to PDF file here:
example-malformed.pdf
Configuration:

Web browser and its version: Chrome
Operating system and its version:  MacOS Ventura 3.0 (22A380)
PDF.js version: used the viewer (https://mozilla.github.io/pdf.js/web/viewer.html) : PDF.js: 4.4.97
Is a browser extension: no

Steps to reproduce the problem:

open the pdf with https://mozilla.github.io/pdf.js/web/viewer.html
most of the text will be transparent

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

The following warnings are displayed in the js console:
Warning: getOperatorList - ignoring XObject: "FormatError: Bad encoding in flate stream".
VM31 jam-console-devtools.js:1 Warning: Knockout groups not supported.
util.js:373 Warning: getTextContent - ignoring XObject: "FormatError: Bad encoding in flate stream".
util.js:373 Warning: getOperatorList - ignoring XObject: "FormatError: Bad encoding in flate stream".
VM31 jam-console-devtools.js:1 Warning: Knockout groups not supported.

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

Thanks for the prompt fix.
I am not used by the release process of pdf.js,
What's the usual timeline for a fix to drip down in the npm package ?
Thanks again :-)

We usually make a release at the end of every month, unless release blockers are identified before that time.


German messages configuration.

Since I needed to do this anyways I thought I could submit this to you too.
This will add the messages_de.conf to the resources to administrators can set their language to de without needing to translate.

Thanks a ton as always @MarkL4YG!


[API] Layer API simplification

Layer is a core concept of the library, so it will be beneficial to keep it as simple, concise, and straightforward as possible. To achieve this simplicity I suggest the next changes:

Remove unnecessary logic from Layer, split it into smaller subclasses that will encapsulate one particular aspect of the Layer, convert Layer class into an interface.

Introduce ParametrizedLayer/TrainableLayer interfaces to cover corresponding concerns of the layer (discussion https://github.com/JetBrains/KotlinDL/issues/217, example: https://github.com/JetBrains/KotlinDL/pull/222)
Move weights accessors into the model (plus remove parentModel field since it was needed only to access session to support weights functionality on Layer level) (example https://github.com/knok16/KotlinDL/commit/4dc0286a4773eb3e5970869b7cff8c918ac8cb6c)
Remove fanIn/fanOut fields since they are used only for local calculations and most importantly are not filled most of the time (example https://github.com/knok16/KotlinDL/commit/a76ed7c2d3f0d12beefe885ad606b0550f92fa8e)
Remove KGraph argument from build method (example https://github.com/knok16/KotlinDL/commit/cac310d560dbc82324b237a21d039cf82bc72244)
Introduce NoInputsLayer/SingleInputLayer/MultipleInputsLayer that will represent layers by arity of its inputs (discussion https://github.com/JetBrains/KotlinDL/issues/224, example https://github.com/knok16/KotlinDL/commit/8643a87d7c983920d0b7434a3d2d9917f0e9aefc)
Replace hasActivation method with marker interface (something like LayerWithActivation, example https://github.com/knok16/KotlinDL/commit/bd74c40342c052c5c0fb2db218cdc3c6762ab9c3)
Make name abstract in Layer - anyway we have it as a parameter in all subclasses, so after this change subclasses will override it right away instead of passing it to the parent class (example https://github.com/knok16/KotlinDL/commit/d3d4196c8168873b677a4c6e1ad316df802d4a4d)
Combine computeOutputShape, build and forward methods into a single one (build for example) (example https://github.com/knok16/KotlinDL/commit/433b6642c9fbb8dbc67afa1a055a117fdc3acfb5), that way it will be easier:

for an implementor of the layer, since it will be required to implement the only single method with clear semantics: it should build the layer
for users of layers, since layers will have the only single method to call before usage, no problems with the proper ordering of method calls can arise

Move inboundLayers/outboundLayers/invoke to Functional builder: it is useful only in the scope of the functional builder, and stores data required for it

Split layers into 2 separate interfaces: LayerBuilder and Layer, leaving all preparation and layer construction to LayerBuilder, and making Layer immutable object that will represent a fully constructed layer.

WDYT?

Great summarization of a few proposals that have been discussed in the past with you. So I suggest arranging a meeting in October with other community members to discuss it.
So, I'll arrange the meeting and invite you to come and discuss it.
I suppose that when the most part of the required Keras functionality is implemented, we could move forward to make KotlinDL more kotlinish!

great! agree that it should be discussed and I'm ready to do it.


Documented example of how to update a deployment-id that already exists with new content

The Azure portal let's you update the content of an existing deployment-id, which is my common workflow as new updates happen in my development environment. I'd like to automated this for a CI pipeline so I'm looking for a CLI equivalent. It is not obvious how to do this via CLI with the current "az iot edge deployment update" command to supply new "context". Is that how we're supposed to do it?

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

ID: 9d0e6bd5-8d60-e24a-efc5-60bff8bfd3be
Version Independent ID: 7d1cae02-3a51-d240-484f-f8964906cb29
Content: Create automatic deployments from command line - Azure IoT Edge
Content Source: articles/iot-edge/how-to-deploy-monitor-cli.md
Service: iot-edge
GitHub Login: @kgremban
Microsoft Alias: kgremban

@hubez Thanks for your feedback! we are currently investigating and we will update you shortly.

@hubez What CI platform are you planning on using? I believe that with Azure DevOps pipelines, this happens automatically. There's a how-to article that walks you through setting up CI and CD pipelines for IoT Edge: https://docs.microsoft.com/azure/iot-edge/how-to-ci-cd. When you configure the deployment task, you can either target a single device by device ID or target multiple devices with tags. When you update your project files, the deployment task keeps its settings and updates the context. Since your pipeline is linked to your IoT Hub, the deployment you create with the pipeline does show up in the Azure portal for you to see alongside your manually created deployments.
If you're not using Azure DevOps and do want to build your own process with CLI steps, I can get more information about the intention behind the 'update' command. I don't know the right answer for that question. Judging from the reference content, (https://docs.microsoft.com/en-us/cli/azure/ext/azure-cli-iot-ext/iot/edge/deployment?view=azure-cli-latest#ext-azure-cli-iot-ext-az-iot-edge-deployment-update) it doesn't look like you can update the context for an existing deployment. Perhaps the solution in that case is to delete the old deployment and replace with with the new one. Or create new deployments with identical properties and priorities, because the priority algorithm defaults to the deployment created most recently if there's a tie.

@kgremban Thanks for the help! @hubez We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

@kgremban I am using Jenkins as my CI platform, but it's moot because it's just executing the Azure CLI tool. I am doing delete + create today, but an update would be superior. I guess I open a request with the tools team on that improvement. Thanks!


Feature about Localization

I know we can now put the locale segment in routes but this is not enough.
The problem with this feature how it works right now it has a big issue that we can fix.

After put the segment in all routes and setup the redirects so it can work with negotiateLocale

All website should now contain this {locale} into the URL
the problem with this route is
$routes->add('{locale}', 'Homepage::index');
so if you get into the url of the website
example.com it wont work because the route is expecting the locale so i get 404 ERROR page
I want to redirect the user to the good route and because of 404 cannot do this.
i have to put both routes
$routes->add('{locale}', 'Homepage::index');
$routes->add('/', 'Homepage::index');
but then what is the point with the {locale} variable..

Also when i have only this route and not have both routes like above
$routes->add('{locale}/', 'Homepage::index');
I will GET 404 Error Page again. for this to work i have to create another route with another controller to handle the redirect to the {locale} page

After i added a filter that checks the locale and if is not set redirect to it again this only works if you won`t get a 404 error page.

After all this work i realized that i don`t want languages on my website so now i have no option to go back to i have to rework all routes. How can i do this without changing my routes.

I must ask to add in the Configuration of the APP
Enable or Disable Routes LOCALIZATION
because when you switch off localization, all {locale} segments from routes should be empty.
Example :
$routes->add('{locale}/contact', 'Contact::index');
should work with both cases if localization is enabled only these links will work
example.com/{locale}/contact
If localization is disabled both links should work
example.com/{locale}/contact
example.com/contact
I always have problems with this language and there were no way to actually enable or disabled languages on the website.
Is there something i miss ? or i`m doing something wrong ?

someone please help me with this i am open to anything...

While it's an interesting feature that probably warrants looking into, we are generally not accepting new features until after the final release.
Additionally, this area is for bug reports. Support requests should be asked on our forums where many more people can help out.
Short answer - no, there's no way to globally turn on/off locales in routes.

Thanks man :D hope you good.
I will make the on / off switch myself.
and try to figure out how locale works and try this myself.


Preview version of mgmt. profile package for Azure Stack

Partially resolve https://github.com/Azure/azure-sdk-for-go/issues/16830.

Add some packages to generate mgmt. plane config and SDK for profile.
First version of profile config 2020-09-01-hybrid package which only contains mgmt. plane modules.

/azp run prepare-pipelines

Few questions.

Does this include full generated code, i.e. no removal of resource types?
When will data-plane parts (i.e. key vault) be added?

Few questions.

Does this include full generated code, i.e. no removal of resource types?
When will data-plane parts (i.e. key vault) be added?

Does this include full generated code, i.e. no removal of resource types?
Yes. I found it's hard to pair the config with operation/operation group. For example, which operation belong to storageAccounts/blobServices in the spec according to this config. If I could figure out how to pair them, I think I could find some way to remove useless resource types.

When will data-plane parts (i.e. key vault) be added?
Since we will announce the deprecation for track1 publicly later this September, I think we need to finish the work before that. According to the issue, it seems we don't have a conclusion for how we add the data plane modules. Is there any update for this?

I've moved tooling change out of this PR and currently this PR should be a clear beta version for profile hybrid20200901, but only support mgmt. plane.

I see that the root build.go file was removed.  While you don't have to fix it now, we really should ensure that all modules can be built via go generate.

I see that the root build.go file was removed. While you don't have to fix it now, we really should ensure that all modules can be built via go generate.

OK. I think if we decide to use profile, I'll do the fix.

/azp run prepare-pipelines

/azp run prepare-pipelines

@jhendrixMSFT @JeffreyRichter @RickWinter I've refined the PR with the new module path: github.com/Azure/azure-sdk-for-go/profile/v20200928. One thing I'm not sure is the v20200928 is the pattern for Go module semantic version, will it be indexed by pkg.go.dev as profile's version v20200928?

@benbp It seems some scripts could not deal with our new module path, could you help?

What is there to review really? If it appears in the repo correctly, then it's right.

@tadelesh sorry I'm missing context on why this isn't in the sdk folder? The sdk/* convention is a pretty hard requirement for almost all of our engineering system tools. If an exception is needed, we'll need to have a more in-depth conversation about what's possible and how much work it will involve.

@tadelesh sorry I'm missing context on why this isn't in the sdk folder? The sdk/* convention is a pretty hard requirement for almost all of our engineering system tools. If an exception is needed, we'll need to have a more in-depth conversation about what's possible and how much work it will involve.

We have a discussion about how to deal with profile for our Go track2 SDK recently. As we do not want to miss-lead customer to wrongly use profile module, we are thinking about put them in profile parallelly to sdk.

@jhendrixMSFT I've updated the PR, could you help to approve?

Ok that yaml is good with me @tadelesh

Then it seems everything is good. @jhendrixMSFT do you have any further concern? After your approval, I will merge and release the first beta.


Can I work with Suggest handler for autocomplete in Solr Net Colud Unity

Hi can I (and how can I) work with SuggestComponent in SolrNet Cloud Unity component?  I was able to configurate handler but I don't know how to work with it in solr net. Can you help me?

Here is example:
request:
http://localhost:8983/solr/numberplate/suggest?suggest=true&suggest.dictionary=analyzedSuggestion&wt=json&suggest.q=Ukr&q=Urk
response:
{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":13},
  "suggest":{"analyzedSuggestion":{
      "Ukr":{
        "numFound":2,
        "suggestions":[{
            "term":"UkrTel",
            "weight":0,
            "payload":""},
          {
            "term":"UkrTel",
            "weight":0,
            "payload":""}]}}}}

In solrJ here is SuggesterResponse Class for this need.

To my best knowledge SolrNet does not yet support this. However it shouldn't be too hard to implement it, it's pretty much copy/past/adjust from the SpellCheck component.

@gjunge  Thanks for answer. Unfortunately, I am not very familiar with SolrNet code for now. Can you try to implement this functionality?


changed the theme

@danielasakpa  Looks great!!! Since you turned it to lighter theme, please try to change the table colors and bg too!

Link to website
I have changed the colour and hover effect of the table. Also, I made the background white, the navbar and the footer black.

@danielasakpa The price change , 24h change and market cap colors are not in contrast. Fix needed

I have made changes to The price change, 24h change and market cap colour.


Optimize and refine the simulation.

Issue: Optimize Task Scheduling
Description: Optimize the existing task scheduling algorithm for better performance.
Tasks:

Analyze the current scheduling algorithm for potential improvements.
Implement optimizations to reduce latency and improve overall performance.

DoD:

Task scheduling algorithm optimized.
Performance improvements observed.

Issue: Monitor and Record Context Switching Time
Description: Develop functionality to monitor and record the time spent on context switching.
Tasks:

Integrate time measurement before and after each context switch.
Record and log context switching time for analysis.

DoD:

Context switching time is measurable and recorded.
Logs or output display context switching time.

commit: https://github.com/youssef456/RTOS_Embedded_Linux/commit/942eafe1d85a55328324c79402ed50724ba2cf19


broken link at top of https://github.com/mantrajs/mantra-sample-blog-app

A sample blog app built with Mantra http://mantra-sample-blog.meteor.com/
Clicking on the url results in the following error:
This site can’t be reached
mantra-sample-blog.meteor.com’s server DNS address could not be found.

Try this one http://mantra-sample-blog-app.herokuapp.com/


Add affordance to indicate users can navigate to value blocks

During user testing, it was noted in many cases that, even after discovering that they could use the right arrow key to navigate from a block to the first value input on that block, users would frequently fail to realised that they could use the right arrow key to navigate to the attached block.  This frequently resulted in the user placing the marker instead of (as desired) opening the colour picker.
It was suggested that we should provide some kind of affordance to make it clear that they can navigate further.  Ideas mooted included:

Some kind of tooltip or other pop-up hint ("keep going ->"?).

Display of such hints could be disabled once the user had successfully navigated to an attached block.

Having the enter key open a pop-up menu with options including "replace attached block" (i.e., marker workflow) and "edit attached block".

N.B. as proposed this conflicts with planned changes to #102.

Based on post-testing conversations this is nominally a fairly high-piority item (I've categorised as P1), but as I'm not sure exactly what form this affordance should take I'm not sure how to proceed.


pipe test output to faucet

Since there are so many tests (260 to this date) I thought it would be nice to make them less verbose by using faucet. Let me know what you think.

:+1:

that looks nice!


extract_html.py BUG: extra characters added to some lines

in part2c, the output has this extra [a][b] added.
search for these examples in part2c:
Mandatory-to-Specify: No. The default is “as-is”.[a][b]
3.3.  MI.StaleContentCachePolicy[e][f]

The letters between brackets are GDOC comments, that appear in the HTML format as links to the bottom of the page. Now the tool will rip those references to comments"


configure SMILE default encoding with LENIENT_UTF_ENCODING

Description
The snapshot creation is failing while serializing the index mapping metadata because of the index mappings have broken surrogate pairs in the field names of the index. The SMILE encoding fails on the surrogate pair as by default LENIENT_UTF_ENCODING is set to false.
Setting the LENIENT_UTF_ENCODING to true would essentially not fail the snapshot creation for the broken surrogate pairs.
ref: https://github.com/FasterXML/jackson-dataformats-binary/blob/2.16/smile/src/main/java/com/fasterxml/jackson/dataformat/smile/SmileGenerator.java#L98
This feature is enabled since jackson-dataformats-binary version 2.13
Related Issues
Resolves #6453
Check List

[-] New functionality includes testing.

[- ] All tests pass

[- ] New functionality has been documented.

[- ] New functionality has javadoc added

[- ] Commits are signed per the DCO using --signoff
[ -] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

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

@neetikasinghal Please run ./gradlew :server:spotlessApply to fix the spotless errors.
LGTM otherwise, although I am not as familiar with SMILE.
It does solve the problem we have, and I see tests for that. But would it create any more unintended problems?

Tagging some other folks as well: @andrross / @reta / @Bukhtawar / @nknize

@neetikasinghal Thanks for the PR!
It seems with this change we are replacing the invalid surrogate with the unicode replacement character, which means in the case of snapshot restore then the index mapping would actually be different after the restore? I wonder if there are any cases where a user is expecting the specific mapping with the surrogate pair and this behavior is silently changing that? Ideally it would be better to get an understanding of where the unmatched surrogate pairs are coming from in the first place. I believe you mentioned that Windows paths may contain these unmatched surrogate pairs, would this be a breaking change for those users who have these existing mappings then?

+1 to this, also let's see if it is possible/better to throw an exception during put mapping.

I think this PR could benefit from an integration test (or a YAML test) that looks like the scenario described in https://github.com/opensearch-project/OpenSearch/issues/6453#issuecomment-1563644772, too.

@neetikasinghal Thanks for the PR!
It seems with this change we are replacing the invalid surrogate with the unicode replacement character, which means in the case of snapshot restore then the index mapping would actually be different after the restore? I wonder if there are any cases where a user is expecting the specific mapping with the surrogate pair and this behavior is silently changing that? Ideally it would be better to get an understanding of where the unmatched surrogate pairs are coming from in the first place. I believe you mentioned that Windows paths may contain these unmatched surrogate pairs, would this be a breaking change for those users who have these existing mappings then?

+1 to this, also let's see if it is possible/better to throw an exception during put mapping.

Rejecting a request during put mapping would be a breaking change, since OpenSearch currently accepts malformed unicode. The behavior today is to fail (ungracefully) during snapshotting if any unmatched surrogates exist in the snapshot metdata, so fixing that bug would not be breaking change. However, it is a fair question as to whether replacing the unmatched surrogate with the unicode replacement character is the right thing to do. I tend to agree that silently changing data during a round trip through a snapshot is probably the wrong thing to do.
I did some simple testing with indexing and searching a document with a single unmatched surrogate (U+D800) as a field name and it appears to work, so I would be very leery of changing that behavior as it is a breaking change. However, the snapshotting mechanism is just straight up broken if you have an unmatched surrogate in the index metadata, so maybe I could buy an argument that rejecting that data earlier in the process is not a breaking change, since it fixes the snapshot behavior. However, it absolutely could break existing use cases that have unmatched surrogates in the index metadata but never use snapshots. @reta what do you think?

However, it absolutely could break existing use cases that have unmatched surrogates in the index metadata but never use snapshots. @dblock @reta what do you think?

Thanks a lot for such a comprehensive investigation, @andrross ! (I should have done the same). This is indeed very risky change to do by default. We do have an option here to use system property (as for fast double parser fe), so affected users could opt-in but default does not change.

@neetikasinghal Thanks for the PR!
It seems with this change we are replacing the invalid surrogate with the unicode replacement character, which means in the case of snapshot restore then the index mapping would actually be different after the restore? I wonder if there are any cases where a user is expecting the specific mapping with the surrogate pair and this behavior is silently changing that? Ideally it would be better to get an understanding of where the unmatched surrogate pairs are coming from in the first place. I believe you mentioned that Windows paths may contain these unmatched surrogate pairs, would this be a breaking change for those users who have these existing mappings then?

+1 to this, also let's see if it is possible/better to throw an exception during put mapping.

Rejecting a request during put mapping would be a breaking change, since OpenSearch currently accepts malformed unicode. The behavior today is to fail (ungracefully) during snapshotting if any unmatched surrogates exist in the snapshot metdata, so fixing that bug would not be breaking change. However, it is a fair question as to whether replacing the unmatched surrogate with the unicode replacement character is the right thing to do. I tend to agree that silently changing data during a round trip through a snapshot is probably the wrong thing to do.
I did some simple testing with indexing and searching a document with a single unmatched surrogate (U+D800) as a field name and it appears to work, so I would be very leery of changing that behavior as it is a breaking change. However, the snapshotting mechanism is just straight up broken if you have an unmatched surrogate in the index metadata, so maybe I could buy an argument that rejecting that data earlier in the process is not a breaking change, since it fixes the snapshot behavior. However, it absolutely could break existing use cases that have unmatched surrogates in the index metadata but never use snapshots. @dblock @reta what do you think?

Thanks @andrross for your comment, I agree with you but I have a question for a customer's use-case:
How does a customer know that a valid surrogate pair that customer tried to index has been parsed as a broken surrogate pair? By this I mean to say, that how/why will a customer search for a broken surrogate pair given that the customer tried to index a valid surrogate pair?

By this I mean to say, that how/why will a customer search for a broken surrogate pair given that the customer tried to index a valid surrogate pair?

@neetikasinghal I'm not sure what you're asking? Here is a concrete example of the problem with the replacement approach:
Index a document with an unmatched surrogate:
PUT test-index/_doc
{
  "\uD800": "foo"
}

Get the mappings:
GET test-index/_mappings
{
    "test-index": {
        "mappings": {
            "properties": {
                "\uD800": {
                    "type": "text",
                    "fields": {
                        "keyword": {
                            "type": "keyword",
                            "ignore_above": 256
                        }
                    }
                }
            }
        }
    }
}

Today if I attempt to snapshot test-index it will fail due to the unmatched surrogate pair in the index metadata. With the change in this the snapshot will succeed. However, if I delete test-index and then restore it from the snapshot, when I get the index mapping I will receive:
GET test-index/_mappings
{
    "test-index": {
        "mappings": {
            "properties": {
                "\uFFFD": {
                    "type": "text",
                    "fields": {
                        "keyword": {
                            "type": "keyword",
                            "ignore_above": 256
                        }
                    }
                }
            }
        }
    }
}

because that field name will have been changed to the Unicode replacement character.

Also, the following operation fails:
POST new-index/_doc
{
  "\uD800": 12,
  "\uFFFD": "foo"
}

with:
Caused by: java.lang.IllegalArgumentException: duplicate field names: 5 and 6 have: �
        at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:107) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.codecs.lucene94.Lucene94FieldInfosFormat.read(Lucene94FieldInfosFormat.java:215) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.readFieldInfos(IndexWriter.java:1245) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.getFieldNumberMap(IndexWriter.java:1262) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1117) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.opensearch.index.engine.InternalEngine$AssertingIndexWriter.<init>(InternalEngine.java:2744) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.createWriter(InternalEngine.java:2263) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.createWriter(InternalEngine.java:2253) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.<init>(InternalEngine.java:305) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.<init>(InternalEngine.java:222) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngineFactory.newReadWriteEngine(InternalEngineFactory.java:43) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.innerOpenEngineAndTranslog(IndexShard.java:2336) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.innerOpenEngineAndTranslog(IndexShard.java:2298) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.openEngineAndRecoverFromTranslog(IndexShard.java:2267) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.StoreRecovery.internalRecoverFromStore(StoreRecovery.java:630) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.StoreRecovery.lambda$recoverFromStore$0(StoreRecovery.java:115) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.action.ActionListener.completeWith(ActionListener.java:342) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        ... 8 more

so it appears we have other cases in the code where an unmatched surrogate pair gets interpreted as the unicode replacement character. I'm leaning towards @reta's suggestion above to add an option to enforce well-formed unicode where appropriate, but have it disabled by default in the 2.x line since the behavior change can potentially be breaking.

Also, the following operation fails:
POST new-index/_doc
{
  "\uD800": 12,
  "\uFFFD": "foo"
}

with:
Caused by: java.lang.IllegalArgumentException: duplicate field names: 5 and 6 have: �
        at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:107) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.codecs.lucene94.Lucene94FieldInfosFormat.read(Lucene94FieldInfosFormat.java:215) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.readFieldInfos(IndexWriter.java:1245) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.getFieldNumberMap(IndexWriter.java:1262) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1117) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.opensearch.index.engine.InternalEngine$AssertingIndexWriter.<init>(InternalEngine.java:2744) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.createWriter(InternalEngine.java:2263) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.createWriter(InternalEngine.java:2253) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.<init>(InternalEngine.java:305) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.<init>(InternalEngine.java:222) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngineFactory.newReadWriteEngine(InternalEngineFactory.java:43) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.innerOpenEngineAndTranslog(IndexShard.java:2336) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.innerOpenEngineAndTranslog(IndexShard.java:2298) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.openEngineAndRecoverFromTranslog(IndexShard.java:2267) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.StoreRecovery.internalRecoverFromStore(StoreRecovery.java:630) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.StoreRecovery.lambda$recoverFromStore$0(StoreRecovery.java:115) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.action.ActionListener.completeWith(ActionListener.java:342) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        ... 8 more

so it appears we have other cases in the code where an unmatched surrogate pair gets interpreted as the unicode replacement character. I'm leaning towards @reta's suggestion above to add an option to enforce well-formed unicode where appropriate, but have it disabled by default in the 2.x line since the behavior change can potentially be breaking.

I would consider this as a bad validation rather than a breaking change, since it impacts data durability which would surface too late. How do we avoid breaking snapshots, I am not sure if being lenient is the right way to proceed.

I would consider this as a bad validation rather than a breaking change, since it impacts data durability which would surface too late. How do we avoid breaking snapshots, I am not sure if being lenient is the right way to proceed.

@Bukhtawar I think broken surrogate pairs are bad and will lead to all sorts of unpredictable problems for users, so I would be happy with a solution that rejects user-supplied string metadata that contains broken surrogate pairs. I can also be convinced that we start enforcing that by default under the argument that it is missing validation and not a breaking change. However, I would consider an option to disable this validation in the 2.x versions so that any users that were unintentionally relying on the lenient behavior (and not using snapshots, which are broken in this hypothetical) have a path forward to keep the existing behavior. I'm receptive to arguments that this option is not necessary though, because broken surrogates are indeed bad with unpredictable behavior as shown above.

Also, the following operation fails:
POST new-index/_doc
{
  "\uD800": 12,
  "\uFFFD": "foo"
}

with:
Caused by: java.lang.IllegalArgumentException: duplicate field names: 5 and 6 have: �
        at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:107) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.codecs.lucene94.Lucene94FieldInfosFormat.read(Lucene94FieldInfosFormat.java:215) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.readFieldInfos(IndexWriter.java:1245) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.getFieldNumberMap(IndexWriter.java:1262) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1117) ~[lucene-core-9.7.0.jar:9.7.0 ccf4b198ec328095d45d2746189dc8ca633e8bcf - 2023-06-21 11:48:16]
        at org.opensearch.index.engine.InternalEngine$AssertingIndexWriter.<init>(InternalEngine.java:2744) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.createWriter(InternalEngine.java:2263) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.createWriter(InternalEngine.java:2253) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.<init>(InternalEngine.java:305) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngine.<init>(InternalEngine.java:222) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.engine.InternalEngineFactory.newReadWriteEngine(InternalEngineFactory.java:43) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.innerOpenEngineAndTranslog(IndexShard.java:2336) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.innerOpenEngineAndTranslog(IndexShard.java:2298) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.IndexShard.openEngineAndRecoverFromTranslog(IndexShard.java:2267) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.StoreRecovery.internalRecoverFromStore(StoreRecovery.java:630) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.index.shard.StoreRecovery.lambda$recoverFromStore$0(StoreRecovery.java:115) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.action.ActionListener.completeWith(ActionListener.java:342) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        ... 8 more

so it appears we have other cases in the code where an unmatched surrogate pair gets interpreted as the unicode replacement character. I'm leaning towards @reta's suggestion above to add an option to enforce well-formed unicode where appropriate, but have it disabled by default in the 2.x line since the behavior change can potentially be breaking.

thanks Andrew for trying this test case, this is possibly happening because lucene also does the same replacement of the broken surrogates.
The documentation of addDocument of the IndexWriter quotes: "Note that it's possible to create an invalid Unicode string in java if a UTF16 surrogate pair is malformed. In this case, the invalid characters are silently replaced with the Unicode replacement character U+FFFD." refer: link

Thanks @andrross, @Bukhtawar, @reta, @jed326, @harishbhakuni21 for your feedback.
After the discussion, it is evident that we don't want to replace the broken surrogate at the snapshot creation step, hence I will close this pr and we can continue to discuss more about this on the newly created issue: 8451


is there any option to play back recorded audio in faster or slower modes(like 0.5x or 2x)

is there any option to play back recorded audio in faster or slower modes(like 0.5x or 2x)

This is a feature request. How about trying to give a PR yourself or try to add more information here which will help contributing?


adding credit card validation

Credit card validation added.
Tests performed with Visa, Master, American Express, Diners Club, Discover cards etc.

Thank you very much!


Fix spelling error in ParserTest comments

https://github.com/se-edu/addressbook-level2/blob/23644b1848abac9a973179ad015e20b7292394f5/test/java/seedu/addressbook/parser/ParserTest.java#L91-L93
Typo found in ParserTest

more spelling errors spotted
https://github.com/se-edu/addressbook-level2/blob/23644b1848abac9a973179ad015e20b7292394f5/test/input.txt#L25-L27


Update core

Update realm-core to v12.8.0
Update bindings

Fixes #921

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+5.5%) to 93.128%

Totals

Change from base Build<PHONE_NUMBER>:
5.5%

Covered Lines:
393

Relevant Lines:
422

💛  - Coveralls


Typo in readme, pkgconfig instead of pkg-config

To compile xrdp from a checked out git repository, you would additionally need ... pkgconfig.

$ sudo apt-get install pkgconfig
E: Unable to locate package pkgconfig

I believe pkgconfig should be pkg-config
$ sudo apt-get install pkg-config

Agreed - this name is used on both Debian and CentOS


[C++][Parquet] parquet_writer

There's an example parquet_reader application in the parquet-cpp examples/ but an example showing parquet writing functionality is missing
Reporter: Gudbergur Erlendsson
Assignee: Deepak Majeti](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mdeepak) / @majetideepak
Note: This issue was originally created as PARQUET-664. Please see the migration documentation for further details.

Deepak Majeti / @majetideepak:
parquet-cpp/examples/reader-writer.cc has an example for both the reader and the writer


[dv] Self-checking C test for dummy instructions

Test available in https://github.com/lowRISC/ibex/pull/1935


feature: add pull commands using buildah #986

feature: add pull commands using buildah #1002
add func newGlobalOptions for getStore

resolve conflicts


Force lmod sourcing defaults

Force lmod to use the defaults from the package we just installed.
This behaviour was by default last week, now it's not.
Although I will investigate why, it doesn't hurt to make it explicit.

I agree it's odd, but also agree it doesn't hurt.


Postgres converter support for enums

It appears that the postgres -> recap converter currently does not support enums. It looks like there is no reference to enum in the postgres converter code. I also don't see any tests referencing enum in the postgres client integration tests.
I'm having some trouble getting my local recap dev env working, so I haven't tested this test, but I think this test in this PR should show the limitation:
https://github.com/recap-build/recap/pull/414

Looks like this should reveal the valid enum types:
SELECT unnest(enum_range(NULL::test_enum_type_mood))
control_plane_dev-> ;
 unnest
--------
 sad
 ok
 happy
(3 rows)

Ohh, this one's going to be tricky in the same way that PG array dimensions and types was tricky (#411).
It looks like we need to use udt_ stuff in the information_schema.columns view and also the pg_enum view to get the possible enum values.

I'm also curious how PG handles arrays of enums. I expect it to enforce valid values for the arrays, but given that it doesn't enforce dimensions, it's worth poking at this to make sure.


Plugin does not prevent propagation of event from framed editor

keydown events - such as enter to select an autocomplete entry - are still propagated to the main document from the framed editor (which is inside an iframe). This is due to some special handling of events inside the iframe in TW, by which events from the iframe are propagated to the parent document. This causes clashes with other plugins that also react to keyboard events.
I will submit a pull request in a few days that works around this, so that events are only propagated further if not handled by the autocomplete.

Oh, ok. I'll let you explore that...
BTW, would you like to be a collaborator on this  project ?
Snow

If that would be helpful, sure you can add me as a collaborator. I don't expect to work on it more after this bug fix unless something else comes up.

Sorry, I was on vacation. I'll set you up as collaborator.
Snow

I guess last commit (721b122d502ddb15b1ac6b20d71770cf5c9759c3) fixed that.
We could close, no ?

Yes, I should have closed it.


lnwire/lnwire_test: assert nil 0-length sid reply msg

Thank you to @offerm for pointing this out, our tests would incorrectly allocate a zero-length short chan id array when checking via quick tests.
Replaces #1592

@cfromknecht much better fix. Don't know how I missed the difference between MsgQueryShortChanIDs and MsgReplyChannelRange. Clearly, this is the way to go!


Create an Advanced section for API docs

Right now we're writing too much in the @description section of each API. Instead, we'd like to keep the description at only 1 or 2 paragraphs.
Let's create a new section called "Advanced", which is reserved for the verbose descriptions of how things work. This way the flow of the docs can go from simple to advanced as you scroll down, instead of having to put all advanced topics in the description.
Also, not really sure what the differences are between the description section, and component section. Could we combine those somehow?
Order of the sections would be:
  Description/Component
  Usage
  Input Properties
  Output Events
  Advanced
  Related

Here's an example of an API that'd benefit from this change: http://ionic-site-staging.herokuapp.com/docs/v2/api/components/datetime/DateTime/

Also, is there any way these main headers could show up in the side nav when viewing a component? Like a third nav that makes it easier to jump around?

Sounds like a good idea. Should be pretty easy to add.
@perrygovier did you want to handle the dgeni/sidemenu part and I can tackle the content?

@mhartington I've created the advanced section. I'll do the side nav links a bit later.

Also, remove the "Component" section, and place the "selector" section to be under the header.

Much cleaner


Add movies to wishlist (or Favourites)

I think it would be awesome to be able to pick movies and add them to wishlist
and then keep this persistent even after the user refreshes (through some sort of useEffect)

Oh i realized kinda works :) if logged in amazing job


feat: allow setting terminal color

Addresses https://github.com/EthanSK/restore-terminals-vscode/issues/10#issuecomment-870834680.
Note that color is not supported for split terminals (other than the first) as there's no changeColor API that accepts args similar to renameWithArg

Hi,
Please merge it, this feature is much appreciated !

Very good this feature, as I usually change the color currently I need to do it manually, it would help a lot to automate that way.

merged icons, pls fix conflicts

@EthanSK conflicts fixed

@iRoachie more conflicts popped up.

any update?

I don't think it works? Tried adding "color": "red" to one of my terminals but still white (default color).
Also tried "terminal.ansiRed" to no avail.


Object spread copies class methods

Flow treats object spread as copying class methods, but at runtime only own properties are copied.
Example:
interface Bar {
  x(): void;
}

class Foo implements Bar {
  x(): void {}
}

let x: Bar = new Foo();
x.x(); // types: ok, runtime: ok
x = {...x}; // types: ok, runtime: ok
x.x(); // types: ok, runtime: error "x.x is not a function"

Try Flow

Duplicate of #3197

@goodmind Duplicate of my own bug! I didn't even realize. 😅


Improve documentation (Tutorials, API documentation etc.)

We have gallery which is great, but we are missing tutorials for example. @nicopresto @jbeezley @dcjohnston what you think?

There are two big things that should happen for documentation.

Tutorials: I had started several jsbin examples (like this one) that were intended to fill that role.  We should embed jsbin examples like this with some prose in the style of the romanesco examples in the RTD docs.
API documentation:  For this we need two things:

Fill in missing/incomplete docstrings.  I have been doing this as I go along.  The new lines in my refactoring branch are probably half docstrings.
Fix the jsdoc template to work better with our code structure.  For example, show the classes with their namespaces geo.core.pointFeature rather than just pointFeature to distinguish the derived classes.

Tutorials: I had started several jsbin examples (like this one) that were intended to fill that role. We should embed jsbin examples like this with some prose in the style of the romanesco examples in the RTD docs.

@jbeezley are you suggesting we create RTD manually (vs parsing the source code like we do right now?).

API documentation: For this we need two things:
Fill in missing/incomplete docstrings. I have been doing this as I go along. The new lines in my refactoring branch are probably half docstrings.
Fix the jsdoc template to work better with our code structure. For example, show the classes with their namespaces geo.core.pointFeature rather than just pointFeature to distinguish the derived classes.

I have slightly different view. Talking with some other folks including @danlamanna, I am thinking that we should follow D3 like API documentation which I don't think comes from the source code. Does it?

are you suggesting we create RTD manually (vs parsing the source code like we do right now?).

We do create RTD manually.  Only the API docs come from the source.

I have slightly different view. Talking with some other folks including @danlamanna, I am thinking that we should follow D3 like API documentation which I don't think comes from the source code. Does it?

I don't like having the API documentation in a separate place.  D3 doesn't use embedded docstrings.  IMO, that makes the source code hard to read.  Other popular libraries use jsdoc effectively.  For example, glmatrix uses it with a very simple custom template, openlayers uses jsdoc with a highly customized template.  I also recently found documentationjs which is compatible with jsdoc style docstrings.  As it is, we have a hard enough time writing and keeping the embedded docstrings up to date.  If we move them elsewhere, it will be orders of magnitude more difficult.

We do create RTD manually. Only the API docs come from the source.

Ah, I see. I haven't looked at the doc. thanks for the update.

I don't like having the API documentation in a separate place. D3 doesn't use embedded docstrings. IMO, that makes the source code hard to read. Other popular libraries use jsdoc effectively. For example, glmatrix uses it with a very simple custom template, openlayers uses jsdoc with a highly customized template. I also recently found documentationjs which is compatible with jsdoc style docstrings. As it is, we have a hard enough time writing and keeping the embedded docstrings up to date. If we move them elsewhere, it will be orders of magnitude more difficult.

that's a good point. Can we not use these templates? @dcjohnston what you think?

We could base ours off of those templates, but my guess is that they are highly customized to the code they document.

ah, I see. Worth investigating? In the mean time, I will add start adding some manual documentation (basic things) for RTD

[ ] API documentation - We have to document the API better (and add missing document for older code)
[ ] Have JSDoc display the documentation better
[ ] Add examples in RTD

I think we are waiting for a example JS source file for improving the API documentation. @jbeezley any chance you can have one for us next week?

I'm working on integrating the template at https://github.com/davidshimjs/jaguarjs-jsdoc.  This is the same template that openlayers uses and provides pretty good out of the box usability with minimal changes to our current docstrings.

sounds great @jbeezley looking forward to it.

As mentioned in #697, here is a list of things we should check for in each file:

[ ] Change each class definition to include an @alias tag (example).
[ ] Tag events with the @event tag (example).
[ ] Document events fired by functions (example).
[ ] Add example blocks demonstrating how the function should be called (example).
[ ] Where appropriate add @typedef tags (example).  It might also be a good idea to move these all into a single file as well.
[ ] Fix crosslinks so they work correctly (example).
[ ] Use markdown syntax to display structured text (example).

I think it would also be nice to remove the immediately invoked functions since they are no longer necessary for commonjs modules.

this is great @jbeezley. @jbeezley @manthey how should we split?

When documenting events, we end up with a title like geo.event.event:pan, which seems peculiar.  Is there a way to have events look like geo.event.pan?

On our getter/setter routines where we return either the current value or the class instance, should the return type be {number|this} or {number|geo.map}  (using an example where the value is a number and we are in the map class)?

Events names are usually just strings and don't typically have namespaces.  For example, you would link to a change event as event:change.  To avoid displaying them like this, we would have to modify the template used to render the documentation.
As far as getters/setters, I don't have a strong opinion.  I guess {number|this} would be a more accurate representation of the behavior.

In the geojs examples, we refer to events via a namespace, e.g. geo.event.feature.mouseover and geo.event.mouseclick.  Would it be better for the documentation to show them this way?  Or resolve to the actual string, e.g. geo_feature_mouseover and geo_mouseclick?

In the geojs examples, we refer to events via a namespace, e.g. geo.event.feature.mouseover and geo.event.mouseclick. Would it be better for the documentation to show them this way

My slight preference is for this (namespace) as I think that would be more useful for the developers but i am open on it.

As far as getters/setters, I don't have a strong opinion. I guess {number|this} would be a more accurate representation of the behavior.

{number|this} sounds good to me as it is general as well.


Rectangle constructors and properties using Vector2

Adds constructors and the Position and Size properties to facilitate the creation and modification of Rectangle fields.

Thanks, merged!


Add pa11y and fix accessibility issues

This adds a custom script that uses pa11y to check accessibility, and fixes an issue with color contrast in footers. This closes #56.

We don't have CI yet, I'm gonna add it after 2.0.
🚀


not able to change the json file

i did the following steps and ifaced following error:"Cannot destructure property 'client_secret' of 'credentials.installed' as it is undefined." so i tried doing the steps from first but i couldnt change my credentials json file to the fresh one i installed now.

Hello @nishgovinnd, how are you?
Thanks for opening this issue :smile:.
I suspect the credentials.json file you have downloaded is not configured for Desktop app on Google Console.
I suggest you configure the Google Drive API on your account again, doing the following steps:

Access this link to turn on the Drive API

Click on Enable the Drive API button

On the modal pop-up, make sure you have Desktop app selected, like this:

Click Create

Click Download client configuration

Hope it helps!

i downloaded it but the i cant use the new one now since the old one is
still not removed sir from vscode, i couldn't change it from the previous
one sir.

Uhm... that's interesting. The extension tries to remove any old configured credentials but maybe that's not working for some reason. What OS/distro are you using? And what VSCode version are you using?
Thanks in advance!

It is us the users who are supposed to be thanking you and thanks . I am
using win 10 and vscode 1.49.3
On Mon, 5 Oct 2020 at 10:10 PM, Gustavo Cassel<EMAIL_ADDRESS>wrote:

Uhm... that's interesting. The extension tries to remove any old
configured credentials but maybe that's not working for some reason. What
OS/distro are you using? And what VSCode version are you using?
Thanks in advance!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GustavoASC/google-drive-vscode/issues/6#issuecomment-703749259,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP6U23W6WZU5XO4BGVJBYXDSJHZGLANCNFSM4SEWKRNA
.

I will try to simulate this problem on the next few days, as soon as I have a free time, and proceed with the fix in case it is a bug.
For now I'd gently ask you to manually delete the credentials on Windows 10 key vault, so you can forcefully configure the Google Drive credentials as if it were the first time you were using the extension on VSCode.
Please do the following steps for that:

Open Control panel
Open Credential manager
Select Windows credentials
Manually delete these two credentials for your user. (When you click on it a button/link "Remove" will appear)

It worked thanks sir !
On Tue, 6 Oct 2020 at 7:22 AM, Gustavo Cassel<EMAIL_ADDRESS>wrote:

I will try to simulate this problem on the next few days, as soon as I
have a free time, and proceed with the fix in case it is a bug.
For now I'd gently ask you to manually delete the credentials on Windows
10 key vault, so you can forcefully configure the Google Drive credentials
as if it were the first time you were using the extension on VSCode.
Please do the following steps for that:

Open Control panel

Open Credential manager

Select Windows credentials

Manually delete these two credentials for your user. (When you
click on it a button/link "Remove" will appear)

[image: image]
https://user-images.githubusercontent.com/10179520/95149260-dd3b4700-075b-11eb-9239-152690e85816.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GustavoASC/google-drive-vscode/issues/6#issuecomment-703981731,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP6U23X3X2VRKIQASS7TFEDSJJZ7JANCNFSM4SEWKRNA
.

sure it would be easy to remove from vscode itself with different os as you
mentioned ,thanks for replying so soon again.
On Tue, Oct 6, 2020 at 8:39 PM Gustavo Cassel<EMAIL_ADDRESS>wrote:

Great! I am happy it worked 😃
Besides, even though we had success removing the old credentials through Control
Panel, I still believe we could develop a command to remove old
credentials through the VSCode extension itself. The name of this command
would be something like: Google Drive: Remove configured credentials.
In case of someone does not want to use the extension on a specific
computer anymore, for any reason, he or she can easily remove the
configured credentials no matter the OS. One would not need to manually
access the Control Panel anymore.
I will keep the issue open so this command can be developed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GustavoASC/google-drive-vscode/issues/6#issuecomment-704336825,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP6U23R3MUL7TKFBIU3KH4TSJMXKFANCNFSM4SEWKRNA
.


TensorFlow Lite Micro int8 quantization support?

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 18.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: STM32F746G
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): '1.14.0'
Python version: 3.7.3
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:
Exact command to reproduce:

You can collect some of this information using our environment capture script:
https://github.com/tensorflow/tensorflow/tree/master/tools/tf_env_collect.sh
You can obtain the TensorFlow version with:
python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

Describe the problem
[feature request]
.tflite model exported with a tensorflow version > r.1.13 are not compatible anymore with TensorFlow Lite Micro experimental Library.
Kernels functions has to be updated to support asymetric per-axis quantization.
Is there any release schedule on this lib?
Source code / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached. Try to provide a reproducible test case that is the bare minimum necessary to generate the problem.

Release schedule on which library? Tensorflow 1.14 is publicly available now (latest release) and any model you train (and then utilize something like post-training quantization) to produce a quantized model should be fine, according to the error message

Production of a quantized model is fine, but the integration on an embedded device using TensorFlow lite experimental micro lib is not working.
To my mind it is due to the asymmetric per-axis quantization not supported by micro kernel. So my question was more "is there any update of the experimental micro lib schedule?"

I'm having the same issue with stm32f746 and tflite-micro.
I'm running v1.14.0-rc1-22-gaf24dc9 1.14.0 version.
When using OPTIMIZE_FOR_SIZE or QUANTIZED_UINT8 in TFLiteConverter and get the tflite flatbuffer, then when the buffer is parsed, the tensorflow/lite/experimental/micro/simple_tensor_allocator.c:TfLiteTypeSizeOf complains that:

Only float32, int16, int32, int64, uint8, bool, complex64 supported currently.

And according to c_api_internal.h the type is set to kTfLiteInt8, which fails.
Without optimization, the flatbuffer is more than 3x times the size and also needs much more RAM.
Is there any way to enforce kTfLiteUInt8?
I thought that tf.lite.constants.QUANTIZED_UINT8 was doing that, but for some reason it uses INT8.

Assigning to @njeffrie since he's looking into this now.

We are working to support signed int8 quantization on micro.  Which operators are  you using?  We tend to prioritize based on usage, so this info can help us choose which ops to prioritize.  We currently have int8 versions of fully_connected and we are close to landing int8 per-channel versions of conv2d and depthwise_conv.

Hi @njeffrie thanks for the reply. As you already mentioned the conv2d and depthwise_conv are the most common used and also in my case I've tried to use those two.
Thanks!

We have landed int8 reference kernels for conv, depthwise_conv, fully_connected and several other ops.  Thanks for your feedback and please feel free to re-open if you are still running into any issues.


Can't push to own registry which has a self-signed certificate

Description
I have a self-hosted registry provided by harbor which works well with docker and docker-compose. The registry is only accessible through HTTPS and the certificate is self-signed. For this to make work I needed to put the ca.crt into /etc/docker/certs.d/my.domain:customport/. docker login was successful.
Seems like docker-app doesn't consider the saved ca.crt but rather fails pushing.
$ cat metadata.yml | grep namespace
namespace: my.domain:customport/projectname

$ ls -al /etc/docker/certs.d/my.domain\:customport/ca.crt
-rwxr-xr-x 1 root root 1972 Nov  2 23:23 /etc/docker/certs.d/my.domain:customport/ca.crt

$ docker-app push
Error: Get https://my.domain:customport/v2/: x509: certificate signed by unknown authority

This is the exact same error with docker before putting the ca.crt in place.
Steps to reproduce the issue:

install a self-hosted registry with TLS enabled having a self-signed certificate
put the ca.crt into /etc/docker/certs.d/your.domain:customport/
set the namespace so that it will use your registry instead of Docker Hub
try push

Describe the results you received:
Error: Get https://my.domain:customport/v2/: x509: certificate signed by unknown authority
Describe the results you expected:
A successful push to the registry.
Additional information you deem important (e.g. issue happens only occasionally):
It happens always.
Output of docker version:
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:24:51 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:23:15 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker-app version:
Version:      v0.6.0
Git commit:   9f9c6680
Built:        Thu Oct  4 13:30:33 2018
OS/Arch:      linux/amd64
Experimental: off
Renderers:    none

Output of docker info:
WARNING: No swap limit support
Containers: 14
 Running: 12
 Paused: 0
 Stopped: 2
Images: 20
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: niout9091kaxngunf7qco0uo9
 Is Manager: true
 ClusterID: x9umkic6692awwc381qgg4kn1
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 10
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Autolock Managers: false
 Root Rotation In Progress: false
 Node Address: *deleted*
 Manager Addresses:
  *deleted*:2377
Runtimes: runc
Default Runtime: runc
WARNING: No swap limit support
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.15.0-38-generic
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.947GiB
Name: *deleted*
ID: MTSL:CLWJ:JV3I:V5XZ:MYQE:3CTL:EP7B:UWZ6:FPQY:LNGN:RWDU:YGXP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
Running on DigitalOcean but I believe it doesn't matter.

Looks like adding the cert to /usr/local/share/ca-certificates/ and updating resolves the problem. So it feels like a minor bug for not supporting certs in /etc/docker/certs.d

Looks like adding the cert to /usr/local/share/ca-certificates/ and updating resolves the problem. So it feels like a minor bug for not supporting certs in /etc/docker/certs.d

Would this work with Docker Desktop for Mac ?

This is still broken:
$ ./bin/docker-app -D app pull hub.foundries.io/andy-corp/skiparchs@sha256:882cee7b2978dd6d79f68cf0f1c683c644c96d558ade759171cad57269bd7d29
DEBU[0000] insecure registries: []
DEBU[0000] Pulling CNAB Bundle hub.foundries.io/andy-corp/skiparchs@sha256:882cee7b2978dd6d79f68cf0f1c683c644c96d558ade759171cad57269bd7d29
DEBU[0000] Getting OCI Index Descriptor
hub.foundries.io/andy-corp/skiparchs@sha256:882cee7b2978dd6d79f68cf0f1c683c644c96d558ade759171cad57269bd7d29: failed to resolve bundle manifest "hub.foundries.io/andy-corp/skiparchs@sha256:882cee7b2978dd6d79f68cf0f1c683c644c96d558ade759171cad57269bd7d29": failed to do request: Head https://hub.foundries.io/v2/andy-corp/skiparchs/manifests/sha256:882cee7b2978dd6d79f68cf0f1c683c644c96d558ade759171cad57269bd7d29: x509: certificate signed by unknown authority

I can get it further along with a hack like: partial-fix.diff.txt. Its roughly copied from github.com/docker/docker/registry/registry.go. However, I don't see a sane way of handling this in docker-app. The containerd code path for this seems to want the TLS config ahead of time before the code knows what host it needs to connect to.
NOTE - once i patched that, just hit problems with trying to pull the containers while running the docker app run command.

I've found a slightly better way, but its still probably something that's not palatable to the upstream:
https://github.com/doanac/app/commit/f26d65516dfa77766f46eb9129cd8f3e424a4826

works for me in vpn only.


Doublequote, ampersand, greater than (etc characters) fails to render

When & " < > ' \ / characters are used in templates they fail to render correctly in certain play / update commands and json / xml data format combinations.

Fixed in 1.0.4 - also requires "spx_cmdhandler.1.2.js" to be used with templates.


Performance on JUWELS-Booster

I have completed my tests on juwels-booster, which has 2 x 24C AMD-EPYC Rome cpu's and 4 x NVIDIA A100 per node. I see virtually no speedup yet between CPU/GPU versions

case
config
longwave time [ms]
shortwave time [ms]

allsky
gcc
251
257

allsky
gcc+cuda
255
258

rfmip
gcc
316
255

rfmip
gcc+cuda
323
260

For the CUDA runs I used the cuda branch.

Can you also test the rcemip testcase and increase the work load to by setting n_col to 64**2? The other cases are relatively cheap and are mainly used for correctness checking.

Yes for some reason I couldn't get the input file for the rcemip case... will try once more.

Send me a message on Slack if I need to clarify something, maybe the make_links.sh misses a step.

I managed to run all three tests on the DAS.

Ah I first needed to run test_rcemip_input.py. Ok, here is the updated table:

case
config
longwave time [ms]
shortwave time [ms]

allsky
gcc
251
257

allsky
gcc+cuda
255
258

rfmip
gcc
316
255

rfmip
gcc+cuda
323
260

rcemip
gcc
38418
35908

rcemip
gcc+cuda
37622
35871

Would it make sense if I also provide the same table for DAS-5? We have a node with an A100 (but older and slower Xeon CPUs).

You can tell me if those numbers are in line with mine Alessio.

Fixed my latest table which was transposed

I did a quick benchmark on an AWS P3 V100 instance:

case
config
longwave (ms)
shortwave (ms)

rcemip
gcc+cuda
3117
2331

rcemip
gcc
14365
11362

After using fortran compiler flags (!) I get following figures:

case
config
longwave (ms)
shortwave (ms)

rcemip
gcc+cuda
3688
3319

rcemip
gcc
8084
6982

So A100's (at least the ones in juwels-booster) appear somewhat slower than the V100 card. This may indicate the code needs some re-tuning...

We have not done any tuning yet. We have rushed a little in getting a reference implementation ready that gives identical results with the CPU version, but there is probably still a lot to gain in kernel tuning.

Some ad-hoc tuning of the kernel block sizes reduces the timings to 3051 ms (lw) and 2669 ms (sw) so yes, there is definitely headroom for speedup by tuning on A100s.

Further manual tuning established

case
config
longwave (ms)
shortwave (ms)

rcemip
gcc+cuda
1439
1174


Rename Demo App to DesignToolbox

Rename the demo app to:

shortname: DesignToolbox
longname: Design System Toolbox

Closing this issue as already defined here: https://github.com/Orange-OpenSource/ouds-ios/issues/85
Please have a look on the issues to check if the one you need exist or not.


Create docker-image.yml workflow

I still need to add a package publishing step, and to ensure the builder finishes the entrypoint, but this is a massive amount of data, and may not be feasible on github actions.


Remove warning preventing to bump Go version

v2.6.5 uses 1.21 and didn't break on release
Just want to have another pair of 👀 in case there was something else related to this comment

just a comment so no need, to run jobs

Well, Im  not sure about that comment but the breakeage was basically for the luet packages for fips rigth?
Now any newer version cut of the provider wont be built under fips for sure as we only got 1.19 there. But @mudler said that its ok so looking good!


remove-comb-groups should be optional

The current compilation pipeline requires remove-comb-groups to be run before any compilation passes are run (tdcc and static-timing). Instead of doing this, the compilation passes should be allowed to directly handle the compilation of combinational groups.

tdcc can enable the combinational assignments in the cycle when it is reading the conditional port.
As @mikeurbach mentions, static-timing can enable the combinational assignments in the cycle when the conditional port is read and in the case of a @bound while, eliminated altogether.

TODO

[ ] infer-static-timing should no longer infer timing for if to be max(tr, fl) + 1 since the 1 comes from 1 cycle needed to evaluate the condition group.

Logistically, how would this work? Would remove-comb-groups be removed from the pre-opt alias, and the tdcc and top-down-st passes updated accordingly?

Yup! Alternatively, if we only implement this in top-down-st, we can move remove-comb-groups to run after top-down-st. There might also be some complications with pre-opt optimizations needing comb groups removed but we can tackle those.

Just commenting an example of how this could be useful. The current implementation of remove-comb-groups ends up evaluating the comb group at the end of the loop body and then checking whether the while loop should run again in the next cycle. The check of whether the while loop should run again is a simple 1 bit equality check so it can be easily chained together with any reasonable comb group. It is hard to show exactly how this change will affect the FSM as the current version of tdst does not support non-bounded while loops yet, bet here is a visual idea of how the evaluation of one iteration of the loop would change:
========== means a clock cycle boundary
Current loop body implementation:
loop body groups
...
...
more loop body groups
evaluate comb group
run again check
Without remove comb groups, with chained comb groups during tdst:
loop body groups
...
...
more loop body groups
evaluate comb group
run again check
This only saves one cycle per loop iteration, but that adds up quickly for loops that run for many iterations.

I have been out of the loop (heh), but I do remember looking at that extra cycle for both statically timed loops as well as the normal latency insensitive loops, and wondering if it would be possible to save the extra cycle of latency.

While working on fixing this, I came across this program which cannot be compiled correctly:
    seq {
        if lt.out with C1 {
          A;
        }
        if lt.out with C2 {
          B;
        }
    }

In this case, the predecessors of A & B are computed to be the start of the seq. Normally, this allows the control program to directly transition to B if the condition for A is false, similar to how switch works in C-like languages.
However, when fixing this issue, we run the assignments in the comb group in every predecessor state, that is, every state that can transition into A or B. The result is this FSM:
======== main:tdcc =========
0:
  lt.left = base;
  lt.right = zero.out;
  lt.left = stored_base.out;
  lt.right = one.out;
1:
  rev_res_sign[go] = !rev_res_sign[done] ? 1'd1;
  lt.left = stored_base.out;
  lt.right = one.out;
2:
  set_res_reciprocal[go] = !set_res_reciprocal[done] ? 1'd1;
3:
  <end>
transitions:
  (0, 1): lt.out
  (0, 2): !lt.out & lt.out
  (0, 3): !lt.out
  (1, 2): rev_res_sign[done] & lt.out
  (1, 3): rev_res_sign[done] & !lt.out
  (2, 3): set_res_reciprocal[done]

The obvious problem is that 0 (start state) can transition to both A or B and therefore assignments corresponding fo their comb groups are activated causing a conflict.
Before implementing the fix, we would always transform the program to look like this:
seq {
  C1;
  if lt_reg.out  { A }
  C2;
  if lt_reg.out { B }
}

Which would ensure that conflicting assignments to lt are not produced.
This problem seems to reflect the fact that if <port> with <group> represents some computation being performed while if <port> does not

Sorry if this is naive, but wouldn't the correct predecessor set for B be both A and the top of the seq? That is, we don't know if control will come from the prior if or whether that will be skipped. (The only predecessor for A would indeed be the top of the seq.)

Okay, so I've realized that loops where we chain the condition check with the next group will also potentially suffer from the above problem.
Consider:
while lt.out with C1 {
  while lt.out with C2 {
    A
  }
}

If we exit the inner loop and want to start a new iteration of the outer loop, how many cycles should it take for A to execute again?
The current pass attempts to schedule A in the next cycle but that again is infeasible because of conflicting assignments. I think we might need to say something like "before the first iteration of a loop, we compute the combination group in a different cycle while backward edges are chained with the next iteration".

Wow, nice catch. I can't help but wonder if there's an underlying principle here that would cover if and while and all their possible nestings/sequencing… maybe there's some general way we could express the need to execute a series of (normal and comb) groups in a way that (a) preserves the illusion of sequential execution, and (b) allows parallelism when there are no conflicts. Maybe this brings us back to the idea of a generalized with statement…
Anyway, yeah, it seems like the thing to do for this particular example is to allow for an extra FSM state (and an extra cycle), at least when the loop conditions conflict.

After #1338, I've realized that there is no good way to eliminate this pass in general. Instead, I think we should change it so that it doesn't create unnecessary groups. For example, there is no reason for the pass to compile away invoke-with statements and should instead let compile-invoke handle their compilation.
The new static timing proposal (#1344) will enable us to write loops that can re-execute their bodies every cycle.


OIDC signing key usage

As an admin I want to be able to create, rotate and disable signing keys for OIDC tokens manually. Keys only exist on instance level, as they represent the issuer (instance domain).
Acceptance criteria
api/oidc

[x] The jwks_uri  endpoint (public endpoint) returns all public keys of the instance
[x] Set a cache header on the jwks_uri
[x] Replace the Provider().Storage().SigningKey() method with a query.Queries method to get the current active signing key
[x] Serve key algorithms on discovery endpoint

Congrats on shipping this, thanks a lot.


Add close / hide buttons to view's titlebar

Describe the annoyance
To hide a currently visible view, I need to either remove or hide it from the left-hand side blueprint view.
Especially when there are many views or the names are not unique, I often have to click on the label in the titlebar first, to highlight the view in the blueprint view. Adding an extra click and some extra mouse movement.
Expected behavior
It would be easier if at least hide (and possibly remove) were also visible in the titlebar of the view.
Screenshots

I agree, this would be nice

After seeing your reply on #2181 I wonder if those buttons should actually be per-tab (similar to browser tabs). Otherwise it's unclear whether closing a window would close all tabs or not.

@abey79 I figure this might become obsolete with the context menus + '...' context menu button that I think was planned?


In a frequent job , sometime lock.tryLock() can not get lock

	<dependency>
		<groupId>org.redisson</groupId>
		<artifactId>redisson-spring-boot-starter</artifactId>
		<version>2.15.2</version>
	</dependency>

In a spring boot 1.5.6 application , We have a new job which is running every 30 seconds and try to acquire lock to do something . In recent days the job has tried to acquire one specific lock cause of business , We found from 00:13 on Feb 24  the job can not get the lock but after 15:03 the job can get the lock again . The operation on this lock only in this job .
the code on the lock as below :
String lockName = LockUtils.getAccountLockName(order.getMerchNo(),order.getPayCompany(),order.getAccountNo());
org.redisson.api.RLock lock = redisson.getLock(lockName);
boolean res = lock.tryLock();
if (res) {
try {
List list = accountDao.list(params);
if (list.size() == 1) {
Account acc = list.get(0);
if (acc.getFrozenBalance().compareTo(amount) >= 0) {
                    if (updateOrderFlag)
                        payOrderAcp1Dao.update(order);
                    return balanceAndEntryBooking(acc, entries);

                } else {
                    msg = String.format("merchant%s account (%s,%s)balance is not enough", order.getMerchNo(), order.getPayCompany(),
                            order.getAccountNo());
                }

            } else
                msg = String.format("merchant%saccount (%s,%s)more than one ", order.getMerchNo(), order.getPayCompany(),
                        order.getAccountNo());
        } finally {
            if (lock.isHeldByCurrentThread())
                lock.unlock();
        }
    } else {
        LockUtils.logLockError(lockName, amount, null, "consume balance");
        msg = String.format("acquire merchant account lock (%s)failed", lockName);
    }

I would recommend to remove if (lock.isHeldByCurrentThread()) this check since unlock should be invoked in any case.

I think if the lock acquired in another thread , unlock should be invoked in that thread .

I don't see any other reason except dealy in code execution between braces.

I think if the lock acquired in another thread , unlock should be invoked in that thread .

all the more you don't need to add this check.

Thanks , I already had this update in the job , will see what happened in the future.

That is a point to catch who is operating the lock in the meantime.

the situation have not happened again .


ARROW-8335: [Release] Add crossbow jobs to run release verification

@github-actions crossbow submit -g verify-rc

@github-actions crossbow submit -g verify-rc

@github-actions crossbow submit -g verify-rc

@github-actions crossbow submit verify-rc-source-windows

@github-actions crossbow submit verify-rc-source-windows

@github-actions crossbow submit verify-rc-source-windows

@github-actions crossbow submit verify-rc-source-windows

@github-actions crossbow submit -g verify-rc

I'll go through and triage the failures in a bit, but one issue to flag is that the windows scripts don't fail the build if they error. I think the issue is that the .bat scripts are hitting errors, but they aren't causing the script to exit with an error, so the calling script (the run: in the workflow) doesn't fail. If anyone knows the fix and could save me hours of googling and flailing, it would be much appreciated.

@github-actions crossbow submit -g verify-rc

@github-actions crossbow submit verify-rc-source-linux-python verify-rc-source-macos-ruby

@nealrichardson the key in the Windows scripts is the  || exit /B after each statement that can fail.

@nealrichardson it seems also we may be missing error codes in those files
https://ss64.com/nt/exit.html

@github-actions crossbow submit -g verify-rc

@github-actions crossbow submit verify-rc-wheels-windows verify-rc-source-windows verify-rc-source-linux-csharp verify-rc-wheels-linux

@github-actions crossbow submit verify-rc-source-linux-python

@github-actions crossbow submit -g verify-rc

Current status:

Windows scripts are now correctly failing on error
csharp builds fail, and I don't know enough (really anything) about its build system to debug it. My attempts at googling the errors haven't resulted in progress.
C++ builds on linux (python, ruby, integration) fail with an LLVM version mismatch error, even though I uninstalled llvm-8 and llvm-9 and installed llvm-7
On macOS, Python source build is failing to find a working CXX compiler, even though the job builds the C++ library before this and it does find the same CXX compiler and it works.
For wheel verification on macOS and Linux, I've turned off the test suite running; it now only does the import check that it does on Windows. This is due to a pandas issue that I'm told is fixed in master, so won't be a problem for 0.17. We will need to uncomment those tests here though.
Linux wheel verification: it claims that manylinux2010 isn't supported on this platform; manylinux1 downloaded fine.

@github-actions crossbow submit verify-rc-source-linux-csharp verify-rc-source-windows

Will take a look. We need not fix the failures in this patch

Agreed that next steps (after getting it to work for the upcoming RC) would be to get this going on some kind of continual integration, nightly or weekly or something, so that it doesn't rot. I'd also like to see more code reuse with our existing build scripts--no reason why we need different cmake et al. commands on regular CI and release verification.

@github-actions crossbow submit verify-rc-source-linux-python verify-rc-source-linux-ruby

@github-actions crossbow submit verify-rc-source-linux-python verify-rc-source-linux-ruby

Ok I'm done tinkering with this, we can poke further at it in the context of an actual 0.17 rc. @wesm or @kszucs, feel free to merge when you're satisfied (enough) with this for now.

@wesm @kszucs may I merge this?


Spring AOT: NoUniqueBeanDefinitionException in EncryptionAutoConfiguration

Field encryptor in org.springframework.cloud.config.server.config.EncryptionAutoConfiguration$EncryptorConfiguration required a single bean, but 2 were found:
	- defaultTextEncryptor: defined in null
	- textEncryptor: a programmatically registered singleton

I'm using 3.1.2 and I might have the same or similar issue:
org.springframework.beans.factory.UnsatisfiedDependencyException:
Error creating bean with name 'org.springframework.cloud.config.server.config.ConfigServerEncryptionConfiguration':
Unsatisfied dependency expressed through field 'encryptor';
  nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException:
  Error creating bean with name 'singleTextEncryptorLocator':
  Unsatisfied dependency expressed through method 'singleTextEncryptorLocator' parameter 0;
    nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException:
    No qualifying bean of type 'org.springframework.security.crypto.encrypt.TextEncryptor'
    available: expected single matching bean but found 2: defaultTextEncryptor,textEncryptor

We had to revert the fix as it was causing a regression. We will be working towards ensuring the support for this in Spring 6.


nix flake for the weirdos

Hello, I'm totally a stranger from the internet. Can I add a nix flake so weirdos in the internet can contribute to this project?

stop being weird piq 🦶

@piq9117 you do it, i'll write a chrome extension to replace all img takes with your photo


Default to swift-frontend for querying supported frontend flags

This library is unavailable in some contexts and on some architectures. For now, let's have the swift-frontend -emit-supported-features flow be the default.

@swift-ci please test

@swift-ci please test


Use recent gcc/apple-clang with OSX

I do not think we need to use gcc with macOS: this is not a requirement for us, at least now.
Also the latest version of Apple Clang seems to be bugued (see 2576371).

I do not think we need to use gcc with macOS: this is not a requirement for us, at least now.

I named "gcc/apple-clang" because if you try to use the default gcc  on OSX (as far as I know) it's actually an alias (or symlink) to apple-clang by default. Thats why this pr didnt try to add gcc.


M2: Design mockups for the UI

Design basic mockups so that it's easier for developers to code the UI.
Designs could be made by hand, figma, balsamiq, draw.io, or any other software that has the capability to create mockups.
Preferably, if using a tool, use a collaborative tool and free.
Acceptance criteria:

Mockups are publicly available

https://www.figma.com/file/VzrBaW3hKUc9HfRjMoDlwR/muckup-App-Demo-CMCD-Validator


suggested addition to step 8

[Enter feedback here]
Step 8 requires an additional step ...
"8. To display the paper tape, insert a Data table control, and set its Items property to this formula:
PaperTape
In the right-hand pane, select the Value column to show it."
my suggestion to edit the final line "In the right-hand pane, select the Value column to show it"
and change it to ...
"In the right-hand pane, select Edit fields next to the fields property, click on the + Add fields and then select the value checkbox"
or something to this effect.
This missing step stumped me for a while, but I figured it out in the end. I think others would appreciate this change as they might be confused like I was.

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

ID: 4f93a150-c9c8-9795-60ea-5888ae895e50
Version Independent ID: 905345c4-35e1-d37f-12b3-3881f00591e0
Content: Understand variables in canvas apps - Power Apps
Content Source: powerapps-docs/maker/canvas-apps/working-with-variables.md
Service: powerapps
GitHub Login: @gregli-msft
Microsoft Alias: gregli

@hems-qmrkt Thanks for contacting us. We have updated the docs and pushed it live. Closing the issue. If you need further help, please reopen or create a new issue.


Remove .env file

The .env file has caused more confusion than it's removed, even for developers familiar with traditional NodeJS development practices.
Pushing this large breaking change as soon as possible in order to prevent new users from running in to this.
Will require a lot of updates to the tutorials & site.

Current dependencies on/for this PR:

main

PR #96   👈

This stack of pull requests is managed by Graphite.

yeah, good catch. that'd be good. adding that to the description.


Adds Reply-To support and converts Recipients from TStrings to TArray - Fixes #16

TStrings must me managed and adds unnecessary complexity to the library use, now you can use it like:
SendMail(['recipient@example.com']...);
And if you have a TStrings you can use StringList.ToStringArray.

:+1:


Add url option to brew.tap

The brew tap command defaults to a (somewhat weird) behavior of looking in a separate homebrew-{repo} repo under the same owner. For understandable reasons, some projects (like the included kpt example), just put the Formula metadata in the main project repo.
Currently, such projects can't be brew taped with pyinfra.
I also took a bit of liberty to refactor the brew tap command to use guard clauses, but I wouldn't mind undoing that.
I'm not sure where the coverage drop is coming from; trying to nail that down

apologies for taking way too long to review this

no worries! Fixing one issue on an ~8 star repo of mine took up most of a weekend, so I can only imagine how much is required to maintain a project this lively.

sors, I was slammed at work recently.
Decided to remove the pre-commit config as soon as I put it in, because it should include changes to CONTRIBUTING.md, and potentially some CI changes, so it should be a standalone PR (assuming you even want to add it)


[suggestion] offending cop name in annotation message

I think it would be useful if the offending cop name is visible in the annotation so the cop can be easily googled for more information.

@InteNs I proposed a pull request for this in #49


Remove RATA Summary Data

As an ECMPS user, I want the ability to remove RATA Summary Data so that I can update Relative Accuracy Data as needed
Acceptance Criteria:
Given I am in the RATA Summary Data section
When I click on the 'Remove' option
Then I see that the relevant RATA Summary Data record is deleted
Given I chose to remove RATA Summary Data
When I click on the 'Remove' option
Then I see a message 'Are you sure you want to remove the selected data?'
And when I click Yes
Then the data is removed
And the update shall be reflected in the RATA Summary Data section
When I select Cancel
Then I am returned to the landing screen for RATA Summary Data
Invision Board:
https://projects.invisionapp.com/freehand/document/SrHrFhGQ3?zoomToItems=Y2w1azFkdGJhMDI1bDNiNnk4ZTl5NjhneQ%3D%3D
Testing
Test Case: TC869
Tester: @mosesdeeCVP

Test Passed


Feat: useSearchParams utility hook

This PR introduce a useSearchParams utility hook that is similar to React-Router's useSearchParams hook.
Due to the minimalistic approach of this library, the utility hook is designed to be as simple as possible while still being useful for most cases. We could even remove the callback setState style if want to be truly minimalist. It does not support "default" search params, does not support array values out of the box to keep the API surface minimal. Let me know what do you think :)
It respects useSearch and useLocation and uses them internally for the utility hook.
This is based on my understanding with this library, feel free to give any feedbacks :)
Closes #368

I have yet to include any documentation in the README though. But feel free to take a look at the implementation details first before we proceed to documentation.

I think I will make the changes required after resolving https://github.com/molefrog/wouter/issues/393 first.
I might also remove the useMemo as well.
Thanks @molefrog

@molefrog Hi, any chance to see searchParams officially supported in this library? Related PR https://github.com/molefrog/wouter/pull/422 :)

Hello guys, any update on this? we would love to use this hook :)

Hello! Lurker here with some info that might be of use.
I tried implementing something similar to this in the past where search param changes cause a navigation event, triggering a rerender from which the new state can be inferred. While this worked on Chrome, I found that Safari has will throw an error if more than 100 history pushes occur within 30s

SecurityError: Attempt to use history.pushState() more than 100 times per 10 seconds

You can trigger this pretty easily in the console
setInterval(() => history.pushState(undefined, undefined, location.href.replace(/\?.*/, "") + `?test=${Math.random()}`),10)

So yeah, just a heads up as this limitation isn't super well known and can fundamentally break an application in cases where application state is coupled to query params.
From what I can tell, Wouter is using the history API as the main source of truth for state - I assume other libraries avoid this issue by decoupling application state from the history API (and debouncing history pushes)?

Hey, I was wondering if there was any updates whether this would be included in the library. I would love to use the hook!

Since React Router v7 is a real breaking change, we are planning to migrate to Wouter. However, we do need a useSearchParams hook, because we used it heavily in our code base. Would be great to see any progress in this PR.

Since React Router v7 is a real breaking change, we are planning to migrate to Wouter. However, we do need a useSearchParams hook, because we used it heavily in our code base. Would be great to see any progress in this PR.
@junwen-k before this PR is merged, is it possible that you can publish the hook a standalone package, e.g. wouter-search ? People can help try and test it.

Hi @guoyunhe,
Thanks for your interest and for bringing this up! Since working on this PR, I’ve actually moved away from Wouter to other routing solutions like TanStack Router and Next.js. I’ve found that I prefer the declarative, file-based routing approach (similar to Next.js) for its clarity and maintainability. TanStack Router's file-based routing provides a similar developer experience to Next.js, but without requiring Next.js itself.
If you’re exploring alternatives, you might want to check out nuqs. It has some interesting features for managing search params and offers first-class support for different routing solutions through adapters. I’ve tried it with Next.js, and it’s been working pretty well so far!
Unfortunately, I won’t be publishing this as a standalone package, as I’ve transitioned to these newer solutions. That said, I’d be happy to support or guide anyone interested in taking over this work.
Thanks again! :)

@junwen-k FYI, I created a package wouter-search based on your PR :christmas_tree: https://github.com/guoyunhe/wouter-search


Moving around some docs for an easier integration

Hello Jan Hendrick,
Would it be possible for you to have all your baseline code in the github repostiory.
This would look like:
.gitignore
LICENSE
Readme.md
info.md
__init__.py
evaluate.py
pandapowerOPFAgent.py
pp_functions.py

So that we can directly add a directory "pandapowerOPF" into l2rpn-baselines that would be a "symbolic link" (ie a submodule) containing your code, the license and all ?
Thanks a lot :-)
Benjamin

I made the PR #2 as an example :-)

Thanks! You were faster than me. I also merged Info.md into the README.md

No problem :-)
I'll try to integrate it into the baseline today !
Have a great day
Benjamin


Missing exec_die event in event docs

Heya!
After some digging around into my docker events I found out that my containers are producing a couple of exec_die events that aren't listed in the docs. I found a PR that introduces the event here: https://github.com/moby/moby/pull/35744
Am I correctly assuming that this is an event we should add to the list?
File: engine/reference/commandline/events.md, CC @gbarr01

Closing this ticket due to its age, and the impending refactor. If you think this is in error, feel free to reopen. Thanks!