Regression setting the name of the native-image executable with 1.4.1

After fixing #128 now the plugin doesn't respect the name of the native image executable defined as
nativeImage {
    imageName("basic-app")
}

The native image is created as application instead of basic-app
Reproduce the issue:

mn create-app foo
cd foo
echo "nativeImage { imageName('basic-app') }" >> build.gradle
Set plugin version to 1.4.0: sed -i "s/1.3.4/1.4.0/g" build.gradle
Use GraalVM
./gradlew nativeImage. Verify that the native image created is basic-app. Abort the generation
Change the gradle plugin version to 1.4.1: sed -i "s/1.4.0/1.4.1/g" build.gradle
./gradlew nativeImage. Now the native image is created as application

Output
$ mn create-app foo
| Application created at /tmp/foo

$ cd foo
$ echo "nativeImage { imageName('basic-app') }" >> build.gradle
$ sed -i "s/1.3.4/1.4.0/g" build.gradle
$ sdk use java <IP_ADDRESS>.r8-grl
$ ./gradlew nativeImage
> Task :compileJava
> Task :processResources
> Task :classes

> Task :nativeImage
[basic-app:66510]    classlist:   1,766.06 ms,  1.39 GB <---- basic-app
[basic-app:66510]        (cap):     438.66 ms,  1.63 GB
[basic-app:66510]        setup:   1,671.99 ms,  1.63 GB
<=========----> 75% EXECUTING [4s]
> :nativeImage
^C

$ sed -i "s/1.4.0/1.4.1/g" build.gradle
$ ./gradlew nativeImage
> Task :compileJava
> Task :processResources UP-TO-DATE
> Task :classes

> Task :nativeImage
[application:66833]    classlist:   1,876.95 ms,  1.30 GB <---- wrong name
<=========----> 75% EXECUTING [3s]
> :nativeImage

Great 🙄


Support focusing SearchAction programmatically

Sometimes it is useful to focus/open the search action programmatically. Example: UI interaction triggering a search.

Closing this issue as duplicate of #239.


feat(curl): optionally display cURL snippet before try

This PR had the capability to show cURL snippet before clicking on the TRY button.

By default the behaviour of displaying the cURL tab remains the same.
I added an attribute show-snippet to the component accepting as a value default | before-try

When setting before-try the cURL snippet box is displayed after the request body and before the response. In this case the cURL tab in the response is not shown.
The cURL snippet is updated when user changes values in forms.

Sorry I messed with splitting my branch by commits. I just pushed force the changes, taking into account your feedbacks. It is all fixed now.

I see that you have changed the attribute name to show-curl-before-try, but I still dont see the code that uses its value

I am not sure why you don't see changes but they are visible here https://github.com/rapi-doc/RapiDoc/pull/851/files, this is mainly

api-request.js https://github.com/rapi-doc/RapiDoc/pull/851/files#diff-8e0994f875e96985adc7136b31e1eb6fe2ba0b4ec504a11d5bfa5044d33fe600
rapidoc.js https://github.com/rapi-doc/RapiDoc/pull/851/files#diff-3ca8bb4f81354937945f23fa9c36233b7bb08dc3f7d373ffd84cca05da14812d
endpoint-template.js https://github.com/rapi-doc/RapiDoc/pull/851/files#diff-ce0fe146b9c1b61b44b0b490e8074dc734eebd8371304d94601c6a99c096ea33
expanded-endpoint-template.js https://github.com/rapi-doc/RapiDoc/pull/851/files#diff-956c80657ef76350f5032e3257711fff3c7d9911cfe31bff8f756f779c6d4acb
I added an API documentation example

Hi @mrin9,
Sure I can revert the text wrapping to the previous behavior. I'll wait for all your feedback before pushing a fix.

Thanks for contributing to include this awesome feature, also nice work to update documentation and fix some of the typos in code  !!!

Need this feature. When will it be available for general use?

@guideloom the attribute to set to true is show-curl-before-try https://rapidocweb.com/api.html

@sroucheray
I think @guideloom is asking for an option just to show cURL without the option to invoke/try the API, like show-curl-without-try.
I guess show-curl-before-try is functioning more like show-curl-before-invoking-try.
From: https://rapidocweb.com/examples/api-demo.html

@guideloom I suggest you open a new ticket for that for better discussions (I am not the maintainer though :) ).


Integrate an Android application which is using Pexip SDK with external systems, mainly SIP

Is your feature request related to a problem? Please describe.
Hi,
We got a new requirement to integrate an Android application which is using Pexip SDK with external systems, mainly SIP.
The workflow is as below:

During device boot up, application will register to Cisco VCS server using the SIP apis available in Pexip Android SDK
During incoming call, application will receive a call back to the application using Pexip sdk
Client joins the meeting room.

I did refer to below articles which shows the support of SIP external system in web applications and server configurations but would like to understand if this is available in Pexip Android SDK.
https://docs.pexip.com/admin/integrating_external_systems.htm
https://docs.pexip.com/files/v27/Pexip_Infinity_CUCM_Deployment_Guide_v27.a.pdf
Please note we are using webrtc with Pexip now.
Describe the solution you would like
Integrate SIP Support into Android Pexip SDK
Describe alternatives you have considered
No Alternatives
Additional context
No response

Thank you for your suggestion, @Sreekanth1m.
We do not plan to add SIP registration support in our SDK. You can still place calls to any SIP address provided your Infinity instance is configured correctly.
To receive incoming calls from other devices you can look into integrating with our registration service. You can find the documentation here.
On the SDK side, take a look at sdk-registration artifact that we provide - the API is quite similar to what you may have already used when setting up a call to VMR.
Please note that you will have to consider Android background restrictions for this to operate reliably as Registration instance has to have active connection to the registrar.

Thanks Dzmitry for the inputs. We will try to integrate. Hope this has no relation with WebRTC as we used it for current video call integration.

Hope this has no relation with WebRTC as we used it for current video call integration.

Registration gives you access to incoming calls. When you receive one, you can exchange the token found in the incoming call through InfinityService for a valid Conference token.
Once you perform the above you can create a Conference as usual.

Thanks for the information. I will go though the documentation and request your inputs if required.


Doubled Joshi Validator

This validator check if the input Japanese sentences contain Successive [Noun + Kakujoshi] patterns.
Following is a example.
私が彼が好きだ

Fixed with #472


Bug in Puerto Rico data

Describe the bug
There is a bug in the data for Puerto Rico (in just the spreadsheet?). When I was doing some "data science", I noticed that there are tracts that have 0 thresholds exceeded but are exceeding 1 category. this is not possible since you need to exceed at least 1 threshold to exceed any categories. Hmmmm. On further investigation, this only appears to be happening to tracts in Puerto Rico. 35 tracts in PR to be exact. All of these tracts are identified as disadvantaged. They are all over threshold for low income. When I count the TRUEs on the data burdens I get 30, meaning 30 tracts should have at least 1 threshold exceeded. What is puzzling is why is this not 35? Are 5 tracts being identified as disadvantaged that shouldn't be? is it just a bug in the spreadsheet? is this also happening on the front end? why is this only happening in PR? Could it have something to do with the removal of linguistic isolation? Meaning maybe those values are still getting pushed some how? But why is it 0 thresholds? This is case just like the extra 13 tracts!
note: for historical context, we used to show the thresholds exceeded on the UI but took it off because it is too confusing.
To Reproduce
Steps to reproduce the behavior:

Go to 'attached spreadsheet'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Attached sheet with the 35 tracts from 1.0
PR_Bug_data.xlsx
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@KameronKerger, I dug a bit deeper into this with data from the backend. On that side, I have intermediate signals for each of the categories (i.e. a precalculated column for "ClimateChange" and "Workforce"). It doesn't appear that those signals make it into the communities list that you were working with. Using that data, I wasn't able to replicate the 5 that you found that were deemed disadvantaged but that didn't trigger any of the category thresholds. I think its possible there are PR/Island-specific threshold columns that get generated that aren't making it into the front end but that get used in the back end. I can look further into that. But I don't think that we are currently flagging anything as disadvantaged that shouldn't be designated that way.
On the question of "why are there tracts that pass 0 thresholds but pass a category?" I've discovered that its actually a bit deeper than that. There are ~398 tracts (all in PR) that pass at least one more category then they pass thresholds for. It seems mostly in the workforce and housing categories. I checked in the backend and I think I know why its happening (it seems like the adding mechanism isn't really working for island areas). But luckily that field is calculated at the end and doesn't really feed anything. I think we can assume that its an issue in the spreadsheet and not in the actual calculation of disadvantage.

Ok good to know @Powers, Samuel D. @.***>. Let’s leave this one for the contractors.
From: "sam powers (usds)" @.>
Reply-To: usds/justice40-tool @.>
Date: Tuesday, March 14, 2023 at 4:21 PM
To: usds/justice40-tool @.>
Cc: "Kerger, Kameron N. EOP/OMB" @.>, Mention @.***>
Subject: Re: [usds/justice40-tool] Bug in Puerto Rico data (Issue #2175)
@KameronKergerhttps://github.com/KameronKerger, I dug a bit deeper into this with data from the backend. On that side, I have intermediate signals for each of the categories (i.e. a precalculated column for "ClimateChange" and "Workforce"). It doesn't appear that those signals make it into the communities list that you were working with. Using that data, I wasn't able to replicate the 5 that you found that were deemed disadvantaged but that didn't trigger any of the category thresholds. I think its possible there are PR/Island-specific threshold columns that get generated that aren't making it into the front end but that get used in the back end. I can look further into that. But I don't think that we are currently flagging anything as disadvantaged that shouldn't be designated that way.
On the question of "why are there tracts that pass 0 thresholds but pass a category?" I've discovered that its actually a bit deeper than that. There are ~398 tracts (all in PR) that pass at least one more category then they pass thresholds for. It seems mostly in the workforce and housing categories. I checked in the backend and I think I know why its happening (it seems like the adding mechanism isn't really working for island areas). But luckily that field is calculated at the end and doesn't really feed anything. I think we can assume that its an issue in the spreadsheet and not in the actual calculation of disadvantage.
—
Reply to this email directly, view it on GitHubhttps://github.com/usds/justice40-tool/issues/2175#issuecomment-1468997281, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASQ2OVBCA45BUWOSM2I76XLW4D4OTANCNFSM6AAAAAAVHKJ5IU.
You are receiving this because you were mentioned.Message ID: @.***>

needs discussion


chore: merge master to release/v1.9.0-pre-rc

关联的Issues (Related Issues)

close
改动 (Proposed Changes)

附注 (Additional Info)

自查清单 (Checklist)
在你认为本 PR 满足被审阅的标准之前，需要确保 / Before you mark the PR ready for review, please make sure that:

[ ] 符合Venus项目管理规范中关于PR的相关标准 / The PR follows the PR standards set out in the Venus project management guidelines
[ ] 具有清晰明确的commit message / All commits have a clear commit message.
[ ] 包含相关的的测试用例或者不需要新增测试用例 / This PR has tests for new functionality or change in behaviour or not need to add new tests.
[ ] 包含相关的的指南以及文档或者不需要新增文档 / This PR has updated usage guidelines and documentation or not need
[ ] 通过必要的检查项 / All checks are green

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/v1.9.0-pre-rc@edaae25). Click here to learn what that means.
The diff coverage is n/a.

Additional details and impacted files

@@                   Coverage Diff                    @@
##             release/v1.9.0-pre-rc     #122   +/-   ##
========================================================
  Coverage                         ?   45.42%
========================================================
  Files                            ?       35
  Lines                            ?     3813
  Branches                         ?        0
========================================================
  Hits                             ?     1732
  Misses                           ?     1868
  Partials                         ?      213

Flag
Coverage Δ

unittests
45.42% <0.00%> (?)

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


Bug: no-unnecessary-callback-wrapper exception

Bug Report

TSLint version: 5.2.0
TypeScript version: 2.3.2
Running TSLint via: CLI

TypeScript code being linted
const vals = ['a', 'b', 'c']

vals.map(x => doSomething(x))

function doSomething(str: string, opts?: boolean) {
  // do something
}

with tslint.json configuration:
{
  "rules": {
    "no-unnecessary-callback-wrapper": true
  }
}

Actual behavior
No lint error
Expected behavior
I get a linting error, but I can't change the code to vals.map(doSomething) as TypeScript won't compile with the error Type 'number' is not assignable to type 'boolean'. [2345]

duplicate of #2430


KOGITO-8092: [SWF Editor] Improve the creation of workflow from an empty file

Closes: https://issues.redhat.com/browse/KOGITO-8092
"Use Autocompletion and Code Lenses to guide the user creating a SWF from an empty file"

I did a refactoring of SwfLanguageService.ts moving the CodeLenses to SwfLanguageServiceCodeLenses.ts and CodeCompletion to SwfLanguageServiceCodeCompletion.ts because later we will probably have many more.
In vscode-extension-serverless-workflow-editor/it-tests/serverless-workflow-editor-extension-autocompletion.test.ts the tests are skipped because not stable, but however, I created some tests for this PR that we can enable when the bug is fixed.

Hi @tomasdavidorg @zdrapela , if one of you could review this PR please, we will need it to start the next release process.


Need to complete the first vision of the fork

As written in the first milestone (Fork and achieve first draft version), this task contains additional information on the intended look for the forked website, and the changes made so far to achieve it.

content\meta.json
changed and added the title, description, and several Urls
src\episode.pug
line 11, it's possible the content needs to reference dvadesetjedan.com. It didn't work for me when it referenced my localhost
src\index.pug
lines 8-12, disabled ticker element by commenting it out
replaced description text
disabled the bulk of the content on the page by commenting it out
src\podcast.pug
line 6, changed the description
changed the content links, disabled the subscribe button
src\includes_footer.pug
disabled some elements, changed links to others
src\includes\mixins.pug
line 12, replaced verschiedenes and Verschiedenes with kategorija and Kategorija
line 118, replaced Einundzwanzig with Dvadesetjedan
src\includes\template.pug
replaced and rearranged drop-down menus and their links
tasks\fetch_feed.js
line 47, replaced Verschiedenes with Kategorija
line 56, replaced verschiedenes with kategorija
tasks\generate_pages.js
line 56, replaced verschiedenes with kategorija


New file README-Automation.md

It describes how to install and use scripts for automation including syncing

Thank you very @idvoretskyi for reviewing this PR, and @jean-christophe-manciot for sharing your work.
@jean-christophe-manciot:

Could you rename that file from README-Automation.md to automation-scripts.md
After that, could you squash these commits into one and then update the commit
message to something like

automation-scripts added

The scripts added in here are from https://gitlab.com/jean-christophe-manciot/ppa.
Their purpose is to offer a few automations ...[describe the change more here]

@idvoretskyi if the changes look good to you, please let me know with your LGTM then I'll merge them in.
Thanks y'all.

Squashed & pushed.

My biggest apologies for leading your work on and for wasting your time, but I hadn't fully read through these changes(the fine print) since they looked exactly like the README.md file was the one being edited.
Am now quite confused, since I thought your project was a PPA that would live on its own but now with the inclusion of this file, that's me endorsing it fully and including its entire README here, hence hosting a section of your entire project.
This change includes its own issues link, license, disclaimer, contact, commands that are not related to drive.
I know that your project leverages drive, and provides a GUI plus a more abstractions that you've custom made, but now after fully reading through your changes and thinking about it for a
while, accepting this change is going to mean that I'll somehow have to maintain your project.
Any future updates that you do on your project will need to update drive as well.
Am very happy to see work being done using drive, and I will keep the links to what folks do in platform_packages.md, just like I've done for all the other PPAs. However, it seems like now am hosting your entire project here. That opens up the flood gates, precedent for
everyone with a platform_packages.md PPA to bring their README files to this project as well.
Therefore, I am now inclined not to accept this change. Am sorry for that!

I understand. No worries.


[Share] Shared chat should be automatically opened, so user can see chat's history

By user1 prepare a link to a chat
By user2 click on the link
Note that chat is added to "Shared with me" (ok), but the previously fixed chat is on the screen -> issue

Expected result: shared chat should be active, it's history should be on the screen
[?] what should we show if to click on the URL for shared folder? Any chat inside? Which one? We expect some easiest from development point of view solution
Seems that the ticket could be a part of #727

Verified on UAT successfully
Note that the first available chat in folder structure is opened automatically, where the first = the first in shared root folder


ipv6 support for client configuration

IPv6 for client configuration is now possible with or without specific port. Different configurations were tested manually, e.g.:

Looks OK

Any reason this can't be merged?
Thanks

I don't see the advantage to use an obscure library to verify an IPv6 address when one can simply use the net library and parse an address that way. It's more resilient and more widely used. Plus the various cases of the form "host:port", "host%zone:port", "[host]:port" or "[host%zone]:port" into host or host%zone and port don't all seem covered here.
There are also potentially cases when the IPv6::ffff:IPv4 forms may also arise.

@ngoduykhanh: What do you think?

Just test ipv6/4 using an OS library.
I


TextArea must be wrapped with From

It is nowhere written in the docs that a TextArea must be wrapped with Form. Though it is required.
https://react.semantic-ui.com/addons/text-area/

Oops, it seems that your branch is outdated. Can you please clean up it?

Codecov Report

Merging #3243 into chore/component-info will increase coverage by <.01%.
The diff coverage is 100%.

@@                   Coverage Diff                    @@
##           chore/component-info    #3243      +/-   ##
========================================================
+ Coverage                 99.92%   99.92%   +<.01%
========================================================
  Files                       169      169
  Lines                      2790     2802      +12
========================================================
+ Hits                       2788     2800      +12
  Misses                        2        2

Impacted Files
Coverage Δ

src/modules/Transition/TransitionGroup.js
100% <ø> (ø)
:arrow_up:

src/modules/Modal/Modal.js
100% <ø> (ø)
:arrow_up:

src/addons/Confirm/Confirm.js
100% <ø> (ø)
:arrow_up:

src/elements/Input/Input.js
100% <ø> (ø)
:arrow_up:

src/modules/Sticky/Sticky.js
100% <100%> (ø)
:arrow_up:

src/modules/Accordion/AccordionPanel.js
100% <100%> (ø)
:arrow_up:

src/addons/Portal/Portal.js
100% <100%> (ø)
:arrow_up:

src/modules/Accordion/AccordionAccordion.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

I did changes in docs in #3269 👍


updating detection from feedback in issue 1557

updates the search so we match on guid and gets a bit smarter on the filtering. Thank you @mschilt :tada:

test is failing for detection

the search syntax was incorrect, updated it and tested via Github Actions and detection-testing service
https://github.com/splunk/security_content/pull/1590/checks?check_run_id=3477529865


Link to article entitled "Proper use of D3.js with Angular directives" doesn't actually mention D3.js

The linked article doesn't mention D3.js at all. Not sure if that's intentional.

Again thanks for the report. It turned out the wrong article was linked. Fixed now.


Passing spreading array to function parameters should raise an error

🔎 Search Terms
spreading array function parameter
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about spreading array in function parameters.

⏯ Playground Link
No response
💻 Code
function foo(args?: string): unknown {
  return args;
}
declare const arr: string[];

foo(...arr);

🙁 Actual behavior
No compilation error.
🙂 Expected behavior
TS compilation error when calling foo(...arr)
Additional information about the issue
One
function foo(): unknown
function foo(args: string): unknown
function foo(args?: string): unknown {
  return args;
}
declare const arr: string[];

foo(...arr); // ts compilation error here as expected 🤔

Two
Background
function getNames() {
  return ['foo', 'bar', 'foo'];
}

const uniqueNames = [...new Set(...getNames())]; // I mistakenly spreading the `getNames()`
console.log(uniqueNames) // [ 'f', 'o' ]

Once I've wrote code above. What I expect is [ 'foo', 'bar' ]. It's really hard to find out the problem in long-line codes, if TS not reports it in compilation time.

This is working as intended. See https://github.com/microsoft/TypeScript/issues/48575#issuecomment-1092189084:

The behavior we actually work hard to exhibit here is that a spread is valid if all its possible arities result in valid calls, [...]

I think your additional "One" does not work because overloads are not supported for this case.
And the "Two" version works unfortunately due to #52060 / #9726.


Fix/300 filter interface cleanup

PR checklist
Docs

[x] If you added new code; is it self documenting? (all the variable names clear, comments added where appropriate)
[x] If you touched existing code; did you refactor existing naming, added comments where necessary?

Tests

[x] If your ticket adds new functionality; have you added unit tests to verify behaviour?
[x] If your ticket alters user interaction with the UI; have you added integration tests?
[x] Do your tests check for every convievable user behabviour? (all behaviours the user can perform)

Typing

[x] If you added new code; have you added typing?
[x] If you touched existing code; have you improved its typing?

Styling

[x] If new styles were created; Did you refactor/add more styles in css-in-js style?

Address https://github.com/jina-ai/dashboard/issues/300

Nice PR! Added some comments about naming, Material and data types


Library doesn't want to be compiled with 1.7 target

Hi, is it possible to use this library with java 1.6-1.7 in Android projects ? When i added it to our gradle build, i got this error :
Error:Execution failed for task ':sdk:transformClassesWithDexForDebugAndroidTest'.
> com.android.build.api.transform.TransformException: java.lang.RuntimeException: java.lang.RuntimeException: Unable to pre-dex '/Users/andrewzakordonets/.m2/repository/com/github/seratch/jslack/1.0.8/jslack-1.0.8.jar' to '/Users/andrewzakordonets/Work/Vimpelcom/veon-sdk/sdk/build/intermediates/transforms/dex/androidTest/debug/folders/1000/10/jslack-1.0.8_6cfaf33714fc85887f68054544efa05c861e4aee'

Hmm, a shortcut class depends on java.util.Optional but others can be compatible with Java 7. If you'll seriously use this library, I'll consider supporting Java 7.

It's ok, i found https://github.com/pschroen/slack-api-android project , which i can use with Android apps. I like your api a bit more, but project does what i need as well. Thanks.


AbstractListAssert allow chainable assertions at specific index

Summary
I'd like to propose a new assertion for AbstractListAssert that would allow chainable assertions on different elements of collection. This would match various satisfy assertions that are already present in other assertion classes.
Example
List<String> actual = newArrayList("Leia", "Luke", "Yoda")

assertThat(actal)
    .satisfiesAt(str -> assertThat(str).isEqualTo("Luke"), atIndex(1))
    .satisfiesAt(
        str -> {
            assertThat(str)
                .isNotEmpty()
                .endsWith("da")
        }
        , atIndex(2))

Good idea!
For consistency with contains(object, index), let's remove At, rewriting your example:
List<String> actual = newArrayList("Leia", "Luke", "Yoda")

assertThat(actal)
    .satisfies(str -> assertThat(str).isEqualTo("Luke"), atIndex(1))
    .satisfies(
        str -> {
            assertThat(str)
                .isNotEmpty()
                .endsWith("da")
        }
        , atIndex(2))

I have renamed the metod and add required javadoc, guess everything should be in right now.


Keyboard noises missing in exported project

Hey, I've added some dialogues with dialogic and also ensured, that *.json and *.cfg are exported. But somehow the keyboard noises, which are enabled by default, aren't played in the exported version. And idea, what am I missing or is this is a bug?

Hey! this bug is confirmed and will be fixed asap. Some users on the discord server were able to make a fix but it wasn't pushed to Dialogic yet. Hopefully it will be fixed soon.


Missing required key on project.conf causes wrong provenance file name on error message

See original issue on GitLab
In GitLab by [Gitlab user @tacgomes] on Aug 17, 2018, 11:28
Summary
Steps to reproduce
What is the current bug behavior?
If a required key is missing on project.conf, such as name, BuildStream shows the wrong provenance file name on the error message when trying build the project. See below.
What is the expected correct behavior?
The filename being shown on the error message to point to project.conf instead of projectconfig.yaml.
Relevant logs and/or screenshots
bst build hello.bst

Error loading project: /home/tiagogomes/repos/buildstream/buildstream/data/projectconfig.yaml [line 8 column 0]: Dictionary did not contain expected key 'name'

BuildStream version affected: /milestone %BuildStream_v1.x

In GitLab by [Gitlab user @tacgomes] on Aug 17, 2018, 11:29
marked this issue as related to #253

In GitLab by [Gitlab user @tpollard] on Aug 17, 2018, 14:33
Yes it would be helpful to pass the correct value of provenance in the loaderror capture, or pass the correct filename to _error_exit where the error loading project is prepended. As it stands it does definitely does not seem like the provenance of 'name' to self._project_conf is associated, which in a way makes sense because it is not set at all (i.e. it's trying to find the provenance of a non existing key, so it just returns the provenance pass to it). An easy fix for this would be to do the name check on self_project_conf instead of the pre_config_node however this would be masking the underlying issue. To clarify I believe the issue is occurring when trying to get the provenance of a key that does not exist, at which point the provenance which was passed to the node_get_provenance gets returned.

In GitLab by [Gitlab user @tpollard] on Aug 17, 2018, 16:47
mentioned in merge request !680

In GitLab by [Gitlab user @tpollard] on Aug 17, 2018, 16:51
assigned to [Gitlab user @tpollard]

In GitLab by [Gitlab user @tacgomes] on Aug 30, 2018, 22:29
closed

In GitLab by [Gitlab user @tristanvb] on Aug 31, 2018, 06:50
reopened

In GitLab by [Gitlab user @tristanvb] on Aug 31, 2018, 06:59
I don't think the workaround targeted specifically at the project name attribute is a solution to this bug.
The name is just an example of a key that, when left unspecified in any defaults, will cause an incorrect provenance to be issued in errors.
This should be closed by adjustments to the underlying _yaml API and it's counterparts in the core to accommodate the absence of keys.
The policy should not be:

"If there is no default specified in the default element and project yaml for a given key, then python code has to special case the key and manually raise LoadError"

Instead, perhaps _yaml.node_get() needs a new parameter to inform it of the expected provenance, or expected filename for loading the specified key.
I will quickly add a FIXME comment to the manually raised exception added in !680 with a mention of this issue, so that we will hopefully remember to remove that in favor of something a more convenient.
EDIT: Added comment in 775d3fca114aff1785d2593c7fc485d215217e75

In GitLab by [Gitlab user @tristanvb] on Aug 31, 2018, 07:06
mentioned in commit 775d3fca114aff1785d2593c7fc485d215217e75

In GitLab by [Gitlab user @tristanvb] on Aug 31, 2018, 07:27
mentioned in commit f861dc0b87467615918c1b2ffcf89c0345ca31bb

In GitLab by [Gitlab user @tristanvb] on Aug 31, 2018, 07:29
mentioned in merge request !767

In GitLab by [Gitlab user @tristanvb] on Aug 31, 2018, 07:51
mentioned in commit 2b94532a3844b67bf7a3d4a1aee251a836e1144a

In GitLab by [Gitlab user @juergbi] on Mar 26, 2019, 17:16
mentioned in merge request !1257

In GitLab by [Gitlab user @jennis] on Mar 27, 2019, 12:47
mentioned in commit 8f803adb2dc9022cc8353db961b004ab83d5cdde

In GitLab by [Gitlab user @jennis] on Mar 27, 2019, 14:12
mentioned in commit dcd52aea8acd6a827e232fe5a244b48d0000c07e

In GitLab by [Gitlab user @marge-bot123] on Mar 28, 2019, 10:04
closed via merge request !1257

In GitLab by [Gitlab user @marge-bot123] on Mar 28, 2019, 10:04
mentioned in commit bef450dd6f31a8ff5e9084b71983a34676abce15

In GitLab by [Gitlab user @tristanvb] on Jun 28, 2019, 10:43
marked this issue as related to #1059


A new feature which will save opened windows, their position and sizes and restore them after system startup

Description of the new feature / enhancement
I think this may have been implemented as a new setting in FancyZones or added as a new utility.
Scenario when this would be used?
I restore some windows manually every time after I start the system. If we could automate these operations, it will be very helpful.
For example, I have four windows opened on my second monitor.

If I could set up somehow and these windows will restore as I configured it would be great.
What do you think?
Supporting information
No response

What comes to my mind could be something like

pinning programs/executables/running processes to defined areas in FancyZones
to auto save the current app positions in case the PC goes to power save and forgets the assigned positions.

/dup #348


Deprecate long-form mixins

Resolves #156

@jasonmit beautiful! Thank you! I'll merge this, cut a 1.x release, and then a 1.x branch. Then we can merge #159 and start on the 2.x betas 🙌


iterable.length has been deprecated, use iterable.size or iterable.count()

I'm not sure if this is an issue with immutable or poltergeist, but I'm seeing the below error when I require immutable when running my tests with poltergeist. I don't see it when manually testing in Chrome or Firefox, though...
console.log('requiring immutable');
var Immutable = require('immutable');
console.log('required immutable');

requiring immutable
iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error:
    at http://<IP_ADDRESS>:36498/assets/application.js:8357
iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error:
    at http://<IP_ADDRESS>:36498/assets/application.js:8357
iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error:
    at http://<IP_ADDRESS>:36498/assets/application.js:8357
iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error:
    at http://<IP_ADDRESS>:36498/assets/application.js:8357
iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error:
    at http://<IP_ADDRESS>:36498/assets/application.js:8357
iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error:
    at http://<IP_ADDRESS>:36498/assets/application.js:8357
required immutable

I suspect poltergeist is calling a .length on an object to figure out if it is iterable.

+1
any resolution to this?
can the error be removed?

In my case I do this horrible terrible sin:
    console.log('    props:   ', this.props)

Perfidious, isn't it?
This is a React app and I'm logging the latest props values upon entering a method.  Within those values in places may be one or three Immutable objects.  The browser's console.log (that disreputable sinner) is trying to determine what to do with this value - how to display it.  Apparently it treads upon the sore spot of .length() and Immutable vomits.
At least every 10 console log entries generates another full screen of "This warning will become a silent error" in some later generation.  This deprecation warning - on every single use and crushed toe - was very badly done.  It should have been generated only once, as person after person has mentioned.
Not a good way to encourage adoption of your way of doing things, to harass users until they bend to your will?
Oh, look, version 3.8.0 is supposed to have gotten rid of this incessant warning.  I think I'll upgrade.  One can hope...   @#*&!! Wonder where the old copy is cached and getting reused...
BTW: I suppose you can close this report as fixed in 3.8.0 by https://github.com/facebook/immutable-js/commit/88f880fc02a377eb36dc1b9f3d6c86c2d1c287dd  Hmmm?

I am seeing it on 3.8.1 still.


Proposal: control cache sources during build with --cache-from

This proposal was originally from https://github.com/docker/docker/pull/24711#issuecomment-237666954.
With several changes to the image format, the scope of build caching has been limited to local nodes. This is problematic for architectures which dispatch builds to arbitrary nodes, since pulling new images and data will not fulfill the build cache.
The main concern here is Cache poisoning. The worst part about is that it is not at all obvious that you are affected or protected. It can only be mitigated by limiting the horizon of data that one trusts.
Anything that circumvents that protection, even docker save/load, is going to open your infrastructure up to injection of malicious content. The proposal in #20316 and previous proposals have not addressed this problem. While we all want fast builds (and I really do), introducing cache poisoning to the build step of the infrastructure must be avoided. Could you imagine the impact if someone could just inject a malicious layer into library/ubuntu or library/alpine?
The other aspect to this is the misapplied assumption about the idempotence of shell commands. apt-get update run twice is never guaranteed to have the same result. Ever. That is just not how it works. If you have a build cache that is never purged, you will never update your upstream software. That may or may not be the intent. Even worse, if this build cache gets filled in with remote data, you probably have no visibility into when that command was run.
The underlying problem here is that with 1.10 changes in the image format, we no longer restore the parent image chain when pulling from a registry. As such, a proper solution to this problem involves something that can control the level of trust for content to a distributed build cache.
Let's look at how we build an image, with FROM alpine at the top:
docker pull mysuperapp:v0
docker build -t mysuperapp:v1 .

In this simple case, we cannot assume that a remote mysuperapp:v0 and the ongoing build are related, since that would possibly introduce the cache poisoning scenario that we need to avoid. However, one may have local registry infrastructure that they know they can trust. While we can infer parentage (despite other assertions, this is still possible), we may not be able trust that parentage from a build caching perspective from all registries. But, this build environment is special.
What better way than to tell the build process process that you can trust a related image?
docker build --cache-from mysuperapp:v0 -t mysuperapp:v1 .

The above would allow Dockerfile commands to be satisfied from the entries of mysuperapp:v0 in the build of mysuperapp:v1. Job done!
No! We still have a problem. Now, my build system has to know tag lineage (mysuperapp:v0<mysuperapp:v1`). Let's modify the meaning the tagless reference to mean something slightly different:
docker pull -a mysuperapp
docker build --cache-from mysuperapp -t mysuperapp:v1 .

In the above, we pull all the tags from mysuperapp, any layer of which can satisfy the build cache. In practice, this probably is a little wide for most scenarios, so we can allow multiple --cache-from directives on the command line:
docker build --cache-from mysuperapp:v0 docker build --cache-from mysuperapp:v1 -t mysuperapp:v2 .

There are many possibilities here to make this more flexible, such as running a registry service specially for the purpose of build caching mybuildcache.internal/mysuperapp. Did you know that you can just run a registry and rsync the filesystem around without locking? You can also rsync from multiple sources and merge the result safely (kind of). Such a registry can be purged periodically (or some one could submit a PR to purge old data).
We can take this even further, but I hope the point is brought home. This is probably less convenient that the original behavior, but it is a good trade off. It leverages the existing infrastructure and has the possibility of being extended as use cases change.
Closes #18924.

Some notes from #26839

Specifying multiple --cache-from images is bit problematic. If both images match there is no way(without doing multiple passes) to figure out what image to use. So we pick the first one(let user control the priority) but that may not be the longest chain we could have matched in the end. If we allow matching against one image for some commands and later switch to a different image that had a longer chain we risk in leaking some information between images as we only validate history and layers for cache. Currently I left it so that if we get a match we only use this target image for rest of the commands.

If the FROM image changes, no cache is reused. This is kind of useful and actually important because otherwise, the user can not detect that there are important security fixes in the base image because they always use the cache. But this may also come as a surprise to some users. I think we should not try to make some hack to work around it, rather if some users want different behavior they should just use immutable tags or digests as a FROM image.

@tonistiigi Thanks for implementing this feature!

--cache-from seems to be broken for me in 1.13.0. Here is a Gist that reproduces the problem: https://gist.github.com/jonasschneider/9e0bf96429444c89da1749225d89750a
Setup: Two empty Docker-in-Docker instances are started. The first one builds an image and pushes it to a registry. The second instances pulls down the image and attempts to build the identical Dockerfile, referencing the repo name of the first image in --cache-from.
Expected: The second build uses the cache of the first build.
Actual: The second build starts from scratch.
Am I using it wrong or is this a bug?

@jonasschneider could you open an issue with more details (output of docker version and docker info), so that it can be looked into / checked if it's a bug or not?

@thaJeztah Thanks for taking a look. I think we've tracked down the issue to a pretty surprising combination of cache invalidation rules and non-FS-modifying RUN commands not being cached, so there might not be a bug. I'll think it through again and open issues accordingly.

Thanks @jonasschneider 👍


add completion count into shard level and task level SBP RCA

Related PRs

https://github.com/opensearch-project/performance-analyzer/pull/593
https://github.com/opensearch-project/performance-analyzer-commons/pull/53

github issue: https://github.com/opensearch-project/performance-analyzer/issues/587
Changing logic to take completionCount into account at shard and task level to accurately calculate the SBP RCAs.
2023-11-10 06:44:40.893 [PA:Reader] [9449wUCJQp2jb7FYh7CmAw-task-0-] INFO  org.opensearch.performanceanalyzer.plugins.PublisherEventsLogger - Action: [SearchBackPressureAction] published by decision maker publisher. action summary : {"thresholdName":"heap_usage","searchbpDimension":"shard","direction":"decrease","stepSizeInPercentage":5.0,"coolOffPeriodInMillis":86400000,"canUpdate":true}

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

[ ] Backport Labels added.
[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

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

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

There are some build errors related to syntax. Please fix and try to build locally


Berlin discussion follow up

Berlin conference hackathon follow up

Ready to start creating a project scaffold!

typing....

...

Hi all, I just uploaded a bit of a scaffold for building an FsTensor package, and I wrote in the Wiki a summary of our discussions. At this stage it probably makes more sense to still play around scripting, but if the implementation details become more concrete I will iron out the last details to make it a package ready for publishing.
The last 3 days were fun, and I hope next year we have something to show for it :) .

tagging @WhiteBlackGoose and @Happypig375 because i remember you guys discussing this topic some time back, maybe you guys have some thoughts on this?

I remember @pkese and @matthewcrews also having a lot of inspiration :)

Can recommend the DiffSharp RawTensor implementation. @muehlhaus knows the gig, I went over it with him.

@kMutagene -

@WhiteBlackGoose has a .NET library for high performance generic tensor operations that we can reference or use: https://github.com/asc-community/GenericTensor
For numpy-like high performance tensors there is also a .NET library https://github.com/Quansight-Labs/numpy.net
For a better design for Tensors, we should consider using .NET const generics for sizes: https://github.com/dotnet/runtime/issues/89730, which should be exposed in F# via https://github.com/fsharp/fslang-suggestions/issues/1195

How it would look like:

let x: Tensor<int, 2, 3> = tensor [[1; 2; 3]; [4; 5; 6]]
let y = x |> Tensor.map ((+) 1) // tensor [[2; 3; 4]; [5; 6; 7]]
let z = y[3,3] // Error: constant indexing out of bounds

This can further be improved by https://github.com/fsharp/fslang-suggestions/issues/1086
let x = [[1; 2; 3]; [4; 5; 6]] // type inferred as tensor
let y = x |> Tensor.map ((+) 1) // tensor [[2; 3; 4]; [5; 6; 7]]
let z = y[3,3] // Error: constant indexing out of bounds

I think one of the important things that we need to flesh out is the access patterns we want to be able to support for the various operations we want to support. The way we need to access data will determine the API we want to create and the underlying storage format.
My ideal scenario for the base Tensor library is to describe how we need to be able to access data (item lookup, iteration, slicing, subsetting, etc.). We can provide a default implementation that is entirely managed, and Providers can provide optimized implementations based on the underlying constraints.
Another critical thing is deciding whether we consider a Tensor a mutable or immutable collection. I can argue either way, but I strongly veer toward immutability, given the ethos of the F# language. Supporting random updates of a Tensor would make the backend much more complex. Can we do it? Yes. Do I want do? No 😂.
Another aspect that I would like to support is surfacing the dimensionality of the Tensor in the type system but without having to hand-code N different Tensor types (Tensor1D, Tensor2D, Tensor3D, ... TensorND). I've taken this approach in the past, and it leads to a significant amount of boilerplate that is difficult to maintain.
The true ideal would be that the F# compiler would be able to check the dimensionality and the length of the dimensions. I do not believe this is feasible, though. I believe it would require something more exotic than what is currently in F#, something like Dependent Types.
I also believe we should start with having the programmer specify the type of Tensor, Dense vs. Sparse. Later, we could possibly abstract this away and allow the library to choose a format based on the shape of the data. I don't think that is a good place to start, though.
This means we would start with a Tensor<'T>, which describes the API for accessing values. DenseTensor<'T> and SparseTensor<'T> would be concrete implementations that actually know how to store data. Personally, I almost exclusively work with sparse data, but I know a large part of the community works with dense.
Feel free to disagree with any of this. I've already bled quite a bit on this problem, so my opinion is informed by scars that may no longer be correct.

In core library, do not paramterize by T. Do that in a derived library if you like via casting but the core library and extension model should be raw. Use "dtype" property instead ranging over limited types.

If this is the direction we decide to go (which I have no problem with), it limits the utility for my applications. Again, this is absolutely fine, but if we restrict the types that a Tensor can contain to a finite set, it's not useful for me. Because I work with things like expressions (LinearExpression, BooleanExpression, etc.). If that is what is best for the community though, that's what should be done. I've long supported my own collection so I'm no worse off.
If I'm misunderstanding this statement, please let me know 😊.

(DiffSharp RawTensor doesn't actually use Python naming - it's not really user-facing - but both the user-facing TorchSharp and DiffSharp Tensor types do)

Again, this is absolutely fine, but if we restrict the types that a Tensor can contain to a finite set, it's not useful for me. Because I work with things like expressions (LinearExpression, BooleanExpression, etc.). If that is what is best for the community though, that's what should be done. I've long supported my own collection so I'm no worse off.

Tensor programming is popular for one main reason: the enormous efficiency of batch processing of videos (4D), images (3D), matrices (2D) with GPUs - the batch adding one dimension to each of these, giving 5D, 4D, 3D objects.  GPUs work over very limited ranges of datatypes.
There's some value in 3D, 4D, 5D numerically-indexed collections of other things that can't be directly processed by GPUs.  This applies particularly when applying the typesafe-indexing techniques you mentioned in your talk in Berlin. Though the contents of the tensors can in theory be indexes into another table.

If I'm misunderstanding this statement, please let me know 😊. I believe I'm the only person who would receive any value from this so I propose that we drop it as a requirement.

It's OK to have a derived library giving a type Tensor<T> and rank distinction Matrix<T>, Vector<T> and just T for scalars. The underlying raw Tensor would be used for the particular unmanaged T types.
What I'm really recommending is that as you build this from the ground up, the "backend" dimension of extensibility should be solved first, at the foundational layer, and then hidden - and this is best done by different implementations of dynamically-typed-and-shape-checked-and-device-moved Tensor and its associated operations.  This foundation gives you both control (you can go fully managed, and can build Tensor<T> etc. while still getting full GPU perf) and the possibility to participate as a credible player in the LibTorch ecosystem.
The DiffSharp RawTensor code is here btw.  It's not perfect but does allow a LibTorch implementation
The definition order is

Backend https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffSharp.Core/Backend.fs
Device https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffSharp.Core/Device.fs
DType https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffSharp.Core/Dtype.fs
Shape https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffSharp.Core/Shape.fs
Tensors https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffSharp.Core/RawTensor.fs and https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffSharp.Core/Tensor.fs. In DiffSharp, an extra notion of differentiability is built in.  For your purposes this can be removed and you only need the TensorC case, which can be collapsed, making RawTensor =~= Tensor.

The rest is programming, but some notable parts are:

Slicing for tensors https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffSharp.Core/Tensor.Slicing.fs
The very nice dsharp.xyz API that makes code easy to port from LibTorch https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffSharp.Core/DiffSharp.fs
Datasets, models and optimizers

All of this is defined as backend-neutral. The backends are separate

Reference managed https://github.com/DiffSharp/DiffSharp/tree/dev/src/DiffSharp.Backends.Reference
LibTorch/TorchSharp https://github.com/DiffSharp/DiffSharp/tree/dev/src/DiffSharp.Backends.Torch

On immutable v. immutable - I went back and forth on this for DiffSharp. It's painful: some specific tensors must absolutely be mutable, notably the enormous number of "model" parameters in any serious training, and several "local" tensors in loops accumulating sums or adjoints (in back-prop) etc. Equally mutability is corrosive and every single use of mutation on tensors needs extreme justification.
I proposed a system where tensors were immutable by default, with a need to specifically convert unsafely to a mutable tensor "register", so you could at least track and reason about where mutation was happening. We didn't end up checking it in, partly because you quickly end up duplicating a lot of operations, and partly because my collaborator was fundamentally OK with tensors being mutable, coming from PyTorch and all (and having bigger things to worry about).  Adding a dynamic flag akin to shape/backend/dtype indicating mutability is probably possible, then building up things on top of that.

Linking another .NET tensor-related discussion
https://github.com/dotnet/runtime/issues/89639

and a mention in the RC2 announcement about .NET tensor primitives https://devblogs.microsoft.com/dotnet/announcing-dotnet-8-rc2/#introducing-tensor-primitives-for-net


"preinstall" script shouldn't sneaky update the global git config

Expected Behavior
"preinstall" script should only update the local git configuration. Or the developers should be instructed to update the global git config manually.
Current Behavior
"preinstall" script forces https instead of ssh for git globally for all the projects and not only for celo-monorepo: https://github.com/celo-org/celo-monorepo/blob/master/package.json#L8
This is what I get in my global git config after running the "preinstall" script:
$ git config --global --edit

[url "https://"]
        insteadOf = ssh://

This might lead to unexpected errors when fetching source code from other repositories that don't allow https.

up


New client data objects after config change

MapData objects should not be persisted when the MapView is part of a view that is destroyed.
New instances should be created along with the activity.

Per discussion we should optionally persist any data the client has added to the map and re-add it to the new MapData/MapController objects.


Use react-docgen for all exported components, don't remove method info by default

There are some significant changes in how docgen works here:
Fix #40, fix #33 with a line from #38, change default to not remove method info
To fix the many tickets that came up for files that export more than one item, I switched over to use the findAllExportedComponentDefinitions. It required parsing a results array from react-docgen and taking a guess as to which component maps to which result array index if the result array item does not include a displayName.
There are also some pretty cool things we could do with the method information in the future so I changed the default to not remove those info.

Hi! From following discussions, I'm guessing this PR solves this problem? https://github.com/storybooks/storybook/issues/3059
Is there anything that can be done to help this get merged sooner? (I'm more than willing to help 😄 )
Or do you have a recommendation for a workaround on how to get the description to show for components that are named exports?
Where I work we have a linting rule that forces ONLY named exports... so you can imagine how this might be affecting us 😅

@terrancewwong it’s available in the 4.0 alpha Storybook already. I’m waiting for more user feedback before closing this to make sure this doesn’t break everyone’s Storybook setup.

@danielduan that's awesome thank you!

Actually, I'm not having success when using storybook 4 😕 . The problem I thought I was addressing by changing to storybook 4 is that a component that is a named export is missing the description in its prop table.
Here's a very small repo that demonstrates the problem: https://github.com/terrencewwong/addon-info-demo

Any news on this one?


Investigations on best integration regarding attestation signature into endorsements (MSP et al)

See also https://drive.google.com/open?id=1rR9pYB8DyrwFH4EiE2I8drTGox7u_gK6x22Qbe7slmQ


Add an n to 1 MUX and MAP

I was experimenting with the library and I wrote a simple multiplexer. Then, I thought it might come in useful, so I made a pull request. I don't know if you need that or not and I was too lazy to make an issue first. If it is not useful feel free to tell me to close the pull request.

It is definitely useful! We are seeing actual need for different ways for doing lookups and handling memory and muxer is a feasible approach. There is #388 which uses permutation network, but it is far more complex and for small number of queries a muxer is more efficient (up to const * log(n)) than a permutation network.
The code seems good and well tested and I do not see any problems merging it. I think maybe it would be better to move it into a separate package though (something like std/memory/mux etc). But I do not right now have a good suggestion. I'll have a thought a propose something so that different implementations would positioned logically.

I’m so glad this worked out. Happy to help.
Choosing names usually is a bit tricky. Maybe std/selectors?

I tried to add some tests and now the test fails! It seems that while the solver fails but the prover succeeds (for two curves I think). Is that normal?

I also added a key value lookup table.
The problem with tests resolved, after I ignored the output of the component instead of adding a trivial multiplication to zero constraint. However, I still suspect that there is a bug somewhere, maybe in ProverFailed(..).

Suggested edit:
diff --git a/std/selector/doc_map_test.go b/std/selector/doc_map_test.go
new file mode 100644
index 00000000..8d2fc91a
--- /dev/null
+++ b/std/selector/doc_map_test.go
@@ -0,0 +1,79 @@
+package selector_test
+
+import (
+	"fmt"
+
+	"github.com/consensys/gnark-crypto/ecc"
+	"github.com/consensys/gnark/backend/groth16"
+	"github.com/consensys/gnark/frontend"
+	"github.com/consensys/gnark/frontend/cs/r1cs"
+	"github.com/consensys/gnark/std/selector"
+)
+
+// MapCircuit is a minimal circuit using a selector map.
+type MapCircuit struct {
+	QueryKey      frontend.Variable
+	Keys          [10]frontend.Variable // we use array in witness to allocate sufficiently sized vector
+	Values        [10]frontend.Variable // we use array in witness to allocate sufficiently sized vector
+	ExpectedValue frontend.Variable
+}
+
+// Define defines the arithmetic circuit.
+func (c *MapCircuit) Define(api frontend.API) error {
+	result := selector.Map(api, c.QueryKey, c.Keys[:], c.Values[:]) // Note Mux takes var-arg input, need to expand the input vector
+	api.AssertIsEqual(result, c.ExpectedValue)
+	return nil
+}
+
+// ExampleMap gives an example on how to use map selector.
+func ExampleMap() {
+	circuit := MapCircuit{}
+	witness := MapCircuit{
+		QueryKey:      55,
+		Keys:          [10]frontend.Variable{0, 11, 22, 33, 44, 55, 66, 77, 88, 99},
+		Values:        [10]frontend.Variable{0, 2, 4, 6, 8, 10, 12, 14, 16, 18},
+		ExpectedValue: 10, // element in values which corresponds to the position of 55 in keys
+	}
+	ccs, err := frontend.Compile(ecc.BN254.ScalarField(), r1cs.NewBuilder, &circuit)
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("compiled")
+	}
+	pk, vk, err := groth16.Setup(ccs)
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("setup done")
+	}
+	secretWitness, err := frontend.NewWitness(&witness, ecc.BN254.ScalarField())
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("secret witness")
+	}
+	publicWitness, err := secretWitness.Public()
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("public witness")
+	}
+	proof, err := groth16.Prove(ccs, pk, secretWitness)
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("proof")
+	}
+	err = groth16.Verify(proof, vk, publicWitness)
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("verify")
+	}
+	// Output: compiled
+	// setup done
+	// secret witness
+	// public witness
+	// proof
+	// verify
+}
diff --git a/std/selector/doc_mux_test.go b/std/selector/doc_mux_test.go
new file mode 100644
index 00000000..af47e677
--- /dev/null
+++ b/std/selector/doc_mux_test.go
@@ -0,0 +1,77 @@
+package selector_test
+
+import (
+	"fmt"
+
+	"github.com/consensys/gnark-crypto/ecc"
+	"github.com/consensys/gnark/backend/groth16"
+	"github.com/consensys/gnark/frontend"
+	"github.com/consensys/gnark/frontend/cs/r1cs"
+	"github.com/consensys/gnark/std/selector"
+)
+
+// MuxCircuit is a minimal circuit using a selector mux.
+type MuxCircuit struct {
+	Selector frontend.Variable
+	In       [10]frontend.Variable // we use array in witness to allocate sufficiently sized vector
+	Expected frontend.Variable
+}
+
+// Define defines the arithmetic circuit.
+func (c *MuxCircuit) Define(api frontend.API) error {
+	result := selector.Mux(api, c.Selector, c.In[:]...) // Note Mux takes var-arg input, need to expand the input vector
+	api.AssertIsEqual(result, c.Expected)
+	return nil
+}
+
+// ExampleMux gives an example on how to use mux selector.
+func ExampleMux() {
+	circuit := MuxCircuit{}
+	witness := MuxCircuit{
+		Selector: 5,
+		In:       [10]frontend.Variable{0, 2, 4, 6, 8, 10, 12, 14, 16, 18},
+		Expected: 10, // 5-th elemen in vector
+	}
+	ccs, err := frontend.Compile(ecc.BN254.ScalarField(), r1cs.NewBuilder, &circuit)
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("compiled")
+	}
+	pk, vk, err := groth16.Setup(ccs)
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("setup done")
+	}
+	secretWitness, err := frontend.NewWitness(&witness, ecc.BN254.ScalarField())
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("secret witness")
+	}
+	publicWitness, err := secretWitness.Public()
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("public witness")
+	}
+	proof, err := groth16.Prove(ccs, pk, secretWitness)
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("proof")
+	}
+	err = groth16.Verify(proof, vk, publicWitness)
+	if err != nil {
+		panic(err)
+	} else {
+		fmt.Println("verify")
+	}
+	// Output: compiled
+	// setup done
+	// secret witness
+	// public witness
+	// proof
+	// verify
+}

Suggested edit:
diff --git a/std/selector/multiplexer.go b/std/selector/multiplexer.go
index 89a19a6b..de71dfe9 100644
--- a/std/selector/multiplexer.go
+++ b/std/selector/multiplexer.go
@@ -1,3 +1,15 @@
+// Package selector provides a lookup table and map based on linear scan.
+//
+// The native [frontend.API] provides 1- and 2-bit lookups through the interface
+// methods Select and Lookup2. This package extends the lookups to
+// arbitrary-sized vectors. The lookups can be performed using the index of the
+// elements (function [Mux]) or using a key, for which the user needs to provide
+// the slice of keys (function [Map]).
+//
+// The implementation uses linear scan over all inputs, so the constraint count
+// for every invocation of the function is C*len(values)+1, where:
+//   - for R1CS, C = 3
+//   - for PLONK, C = 5
 package selector

 import (
@@ -70,6 +82,8 @@ func generateSelector(api frontend.API, wantMux bool, sel frontend.Variable,
 	return out
 }

+// MuxIndicator is a hint function used within [Mux] function. It must be
+// provided to the prover when circuit uses it.
 func MuxIndicators(_ *big.Int, inputs []*big.Int, results []*big.Int) error {
 	sel := inputs[0]
 	for i := 0; i < len(results); i++ {
@@ -84,6 +98,8 @@ func MuxIndicators(_ *big.Int, inputs []*big.Int, results []*big.Int) error {
 	return nil
 }

+// MapIndicators is a hint function used within [Map] function. It must be
+// provided to the prover when circuit uses it.
 func MapIndicators(_ *big.Int, inputs []*big.Int, results []*big.Int) error {
 	key := inputs[len(inputs)-1]
 	// We must make sure that we are initializing all elements of results

Thank you so much. All the suggested changes look great.
I've just spotted a few unimportant typos.

I fixed them in a new commit.


Adding Miskolci SZC Kandó Kálmán Informatikai Technikum to the list.

School site: https;//kkszki.hu/
Long term IT related course proof: https://kkszki.hu/kepzeseink/technikum-szakkepzo/szoftverfejleszto-es-tesztelo

Proof of them recognizing the email is in the footer of the main site as their contact email is<EMAIL_ADDRESS>     ____________________________________________________
    |.==================================================,|
    ||  I WILL MERGE AND REVIEW PULL REQUESTS QUICKLY   ||
    ||  I WILL MERGE AND REVIEW PULL REQUESTS QUICKLY   ||
    ||  I WILL MERGE AND REVIEW PULL REQUESTS QUICKLY   ||
    ||  I .----.ERG,                                    ||
    ||   / ><   \  /                                    ||
    ||  |        |/\                                    ||
    ||   \______//\/                                    ||
    ||   _(____)/ /                                     ||
    ||__/ ,_ _  _/______________________________________||
    '===\___\_) |========================================'
         |______|
         |  ||  |
         |__||__|
         (__)(__)

@Axsic First stage of verification passed, official domain is kkszki.hu as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@Axsic Pull request merged. Thank you.


build-machinery: respect -mod=vendor for go list

go list ./cmd/... that is used in resolving GO_BUILD_PACKAGES_EXPANDED for some reason fetches the go modules although that's a local reference, respecting mod vendor there force the correct behaviour
/cc @soltysh

/lgtm


system stuck when arecord via SCO.

Hi  @Arkq
Only after the first time of burning and writing can sometimes the recording succeed and exit successfully.
bluez-alsa: 9c4ab2b
steps:
1)bluez-alsa &
2)bluetooth
3)arecord -D bluealsa:SRV=org.bluealsa,DEV=5C_C6_E9_90_E6_76,PROFILE=sco -d 10  capture.wav
issue 1: arecord stuck, unable to go to ba-transport.c:906: New SCO link
issue 2: arecord stuck,Recording for 10s has been unable to exit. unable to go to bluealsa-pcm.c:327:/org/bluealsa/hci0/dev_5C_C6_E9_90_E6_76/hfpag/source: Stopping
issue 3: reboot system,Recording  stuck.
I have attached the  log of the following normal recording . please do refer & help us to analyze.
 So the issue may not be present any more, and even if it is, the logs here are no  longer helpful in tracing the cause. So I am closing it now; however if testing with the latest code from master branch reveals similar behaviour, please open a new issue with updated error logs.


Add ekstraklasa extension

Description

This extension allows keeping track of the standings of ekstraklasa, which is polish soccer league.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Oh man, I've waited for this so much! 🌲⚽🌲
Thank you! 🫶


Please do not hardcode the terminfo database

the terminfo database seems hardcoded and therefore less likely correct
Specifications
Commit hash: micro 3cbbba534c6b2d0f5ab938679ca442d13c164eba
OS: Fedora 36
Terminal: Contour (latest master)
We have received a bug report today at https://github.com/contour-terminal/contour/issues/796 because micro would not run in Contour terminal emulator. I figured that micro isn't even doing much and simply leaves the terminal in a real bad state, i.e. hidden cursor in alt screen. So from user's PoV, running reset will fix the mess. But there are a couple of issues here.

Why did this happen in the first place? Because our terminal does not expose lines#24 in the static database, so I got told that this is queried
Whatever problem happens during TUI initialization, the user must not suffer from a screen in a bad state. It would be best , generally speaking, if micro upon exit restores the terminal state, at least showing cursor and going back to primary screen again.
micro seems to depend on a forked tcell library, which seems to have a hardcoded copy of a terminfo database at build time. It's a very long time ago when I was coded in Go, so I might misunderstand here something. But to my understanding, micro queries information that it gets from tcell, and tcell has that information from its "during build-time generated .go files", which is a copy of the local terminfo files, as parsed from the output of infocmp. To me this feels like it can go very well wrong. Suppose you have a user having a somewhat newer version of some existing terminal tcell has imported the terminfo db for. But the contents has changed. Now, that user will however always get outdated, potentially stale invalid data as terminfo responses through tcell, because it's using the terminfo information from the .go files, and not from the up-to-date terminfo file. To me, purely personally, this sounds bad by design. And I would love to encourage you to change the design to parse the actual terminfo files simply at process startup for only that terminal that is being configured via TERM env var. Alternatively, XTGETTCAP VT sequence should definitely be at help, which is supported on many terminals, too.

WRT lines numeric capability, we're now having a PR on our side to provide that via terminfo file. However, I think modern applications must not depend on that capability at all. There are plenty of other ways to definitely get a correct value (tcgetattr(), XTWINOPS). What do you think?
Have a nice day/night. ;)

I think the static database is sort of left-over from before tcell had support for dynamic terminfo parsing, and now remains as a "performance improvement," with the dynamic parsing as a fallback. Maybe it should in fact be the other way around. I'll look into fixing this, thanks for bringing this up.

I was triggered by #3101 (@niten94 :+1:) that this issue exist and would like to do the change.
As already mentioned in zyedidia/tcell#26 it would be nice if not fork is necessary at all any longer, but I assume this does not happen in the next time...
Anyway, switching the order doesn't seem to be a big deal, but it will take effect earliest after the dependency reference will be updated.

The commit where terminfo entries in the system database are used instead of builtin entries when available has been reverted, so I think this issue should be reopened.
I read in a comment in the thread of the issue that the bug was discussed in Discord, so I tried reading old messages to know details. I do not know much about terminals so I cannot feel it that much, but I can understand why the situation with terminfo in micro looks bad.
Micro seems to crash with an exit status of 0 without restoring the terminal state properly because the size of the array created in this line is multiplied with a negative height value once:
https://github.com/zyedidia/tcell/blob/v2.0.10/cell.go#L149
Terminfo files are loaded using the output of running infocmp upstream but xo/terminfo' (Go module, like library) is used instead in the tcell fork. It is written in [term(5)](https://invisible-island.net/ncurses/man/term.5.html#h3-Legacy-Storage-Format) man page of ncurses that absent integer capabilities are set as -1 in terminfo files, but the value returned is not modified when xo/terminfo` is used.
Absent capabilities may be expected to be remain initialized as 0 in the source code upstream, because it is written in the man page of the ncurses version of infocmp(1) that they are not printed. The value is not set to 0 in the fork even if negative, so the amount of lines remains as -1.
I do not know the reason much but Go programs do not usually use FFI, so a library written in another language cannot be used to read terminfo entries. I think adding a new function to the tcell fork and an option to micro can be done, if builtin entries are checked first instead by default for some reason.


The "collector_duration_seconds_total" metric as histogram to keep duration of full collection.

The "collector_duration_seconds_total" metric was added to keep duration of full collection. We added it because we noticed some strange dips in graphs(please, see attached screenshot) and the reason is the big time of collecting metrics so that Prometheus cannot collect metrics during scrape timeout. The scrape timeout is 20s in our Prometheus configuration. As a result the existing metric "collector_duration_seconds" does not show us the big time of scraping, because it is gauge.

So, the new metric as histogram will measure duration always. Now the metric has the following buckets in seconds:
0.5, 1, 2.5, 5, 10, 15, 20, 25, 30, 45, 60
If you think that it is needed to change this set, please, let me know. Thanks.

Hi @vlamug,
Thanks for helping to improve wmi_exporter! Am I understanding you right that you mainly want to see in later scrapes how long time previously timed-out scrapes took?
If you want to detect timeouts, you can already detect them since Prometheus' automatic up metric will go to 0 if the scrape times out.

Hello @carlpett. Thanks for answer.

Am I understanding you right that you mainly want to see in later scrapes how long time previously timed-out scrapes took?

Yes. Additionally, it can show us the reason of failed scraping. Let consider the image attached in the first message. If I see the dips in the graph I can check the collector_duration_seconds_total metric and then if the scape time took more then scrape timeout in Prometheus configuration(the scrape_timout parameter), I will sure that the reason of failed scraping is the long scraping.
The metric up will not give us such information.

So, I want to see not only current scraping is failing now, but the find out the reason in the past.

@carlpett could you check my last message? Thanks.

Sorry, seems I accidentally silenced this thead. As part of #335, we're introducing timeouts for collectors, so you should be seeing much fewer total scrape failures from the Prometheus side. Additionally it adds a collector_timeout metric so you can see which ones took too long.
Would this cover your use case?

@carlpett , ok, it seems that added functionality is helpful. Thank you. I close this issue.


[Draft do not merge] PR for Review Round 2

Fixes #32 , #34 and #36 .

[x] Data type is used from proxy (and indexraster)
[x] Check and correct dimension order:

[x] aircraft: time, level, lat, lon
[x] anthro: time, sector, lat, lon
[x] openburning: time, sector, lat, lon

[x] Sectors are not dropped by empty proxy weights (restores Agriculture and Solvents in BC)
[x] Sector order in proxies is preserved
[x] Proxies need to be updated:

[x] Sector order in anthro_*-proxies should be 'AGR', 'ENE', 'IND', 'TRA', 'RCO', 'SLV', 'WST' (currently it is alphabetical with TRA in between SLV and WST)
[x] Sector order in openburning is fine
[x] Data type should be float32 (.astype("float32"))

[x] anthro
[x] openburning
[x] aircraft
[x] shipping
[x] cdr_co2

[x] Sector attribute id is called ids instead
[x] Indexraster needs to use the float32 datatype as well (or we add a quick conversion to workflow.ipynb)
[x] Agriculture CO2 needs to be added as 0 (still missing because it does not have a variable correspondence in variabledefs)
[x] Move CO2_em_removal into CO2_em_anthro with documentation
[x] Add 2015 year to gridded data by stitching historical and downscaled tabular data
~[ ] time_bnds between two years are incorrect~ for review round 3
~[ ] Check there are no nan's in any of the datasets~ systematic check for review round 3
[x] Compare to previous set of gridded files (per sector/gas spot checks and grid cell total systematically)
[x] Add a CHANGELOG

@gidden Ok, with the addition of the changelog the review round-2 work would be complete!


Save/Load System

There should be a save/load system in place to allow the storing of the game's current state and for it to be loaded back into memory at a later date.

So after working on the serialization aspect for a while a few issues are popping up thats showing this is slightly more complex than I originally thought it would be.  I did, however, find a useful article here  that outlined a simple system.  Contents of the answer are provided below just because.  But it's looking like I may need to create a similar system and add a Save/Load function to the GameLevel file.
Answer from post
You can either write your own save format and save file reader & writer, or use an existing parser like an XML or JSON one. You can store the save data in a GameSave class at runtime either as a tree of the file format you chose, or inside direct member variables. I myself us the latter, as then it's easier to save data (while reading becomes a bit more tricky). It also abstracts setting of the save data with the writing of the save data.
class GameSave
{
public:
    GameSave() { }
    GameSave(const std::string& filename)
    {
        // Load save data...
    }

    void Write(const std::string& filename)
    {
        // Write save data...
    }

    std::string CurrentLevel;
    std::vector<std::pair<std::string, int>> Inventory;

    // More save data...
protected:
private:
}

Here's a very basic example of what your save class could look like. The details or writing and loading and the filename management depends on if you want to support multiple saves or not, and if you want to predefine a few save slots or allow the player to chooce their own filenames etc.
So, when the player saves the game, you need to write the required data to the file. This can be done in a few ways: you could ask each object to save its own data to the file, or you could have a parent object (like your level / gamestate) save the required data. Since your data needs seem quite small, I'd go with the latter option and write something along the lines of:
void GameplayState::SaveGame()
{
    GameSave save;

    save.CurrentLevel = m_Level->GetName();
    Player* player = m_Level->FindPlayerEntity()->GetLevel();
    save.PlayerLevel = player->GetLevel();
    for (InventoryItem* item : player->GetInventory()->GetItems())
        save.Inventory.push_back(std::make_pair(item->Name, item->Amount));

    save.KilledEnemyCount = GameStatManager::KilledEnemyCount;

    save.Write(AskPlayerForSaveSelection());
}

Finally, to continue from a save, you just have to load the data in and pass it to the correct owners. This could be done by passing the whole GameSave around, or simply by passing the required members of the save to the constructors/methods.
void GameplayState::Continue(GameSave* save)
{
    // Use save data:
    m_Level = new Level(save->CurrentLevel);
    m_Level->CreatePlayer(save->PlayerLevel, save->Inventory);
}

This is the basic high-level architecture of a basic game save setup that I've found that worked well enough for me, when the data that I need to save is quite small and can be handled as such. Were you need more data and more dynamic data, then you'd have to start assigning unique identifiers to objects and allowing each object to save/load its own data.

Left the TODO's in place
//TODO: Deserialize the GO name

But ultimately it looks like I just need to ensure the names are being serialized, as now on deserialization a runtime error is being thrown here:
GameLevel.cpp
    auto it = std::find_if(objects.begin(), objects.end(),
                           [&](std::shared_ptr<GameObject>& go2){

        return go2->HasComponent(componentName); });

This is because when the GOs are de/serialized, it's not re/storing the names and as such it can't find the player.


predawn: python type hinting breaks highlighting

def dot_on_n_dimensional_cube(n: int) -> list:
    '''docstring here'''
    pass

breaks the docstring highlighting and highlighting below in predawn theme

\extPython

This issue is caused by Python for VSCode by Thomas Haakon Townsend extension.
This theme works as expected.


Avoid in-place mutation of df in FillMedian

Possible fix for recent CI failures.  It is technically not "legal" to modify input data to a task "in place."  It seems that we are doing this in other transforms as well.
Possible alternative to #687

If we need to avoid mutating the input - I'd rather do it in _transform_partitions on the workflow than in each op: https://github.com/NVIDIA/NVTabular/blob/36f7c31fa1711f2ba4fac2bf49d8ccf1c76f051b/nvtabular/workflow.py#L310 .
However, we're failing on the 'fit' function - and its not clear to me how changing the 'transform' functions (which are only called after fit is performed) will fix this problem. There are no operators before the categorify/fillmedian ops in the workflow for this unittest (https://github.com/NVIDIA/NVTabular/blob/36f7c31fa1711f2ba4fac2bf49d8ccf1c76f051b/tests/unit/test_torch_dataloader.py#L101-L104) - so I don't think any transforms will have been called by the time this fails.

If we need to avoid mutating the input - I'd rather do it in _transform_partitions on the workflow than in each op

Right, we could always do it in _transform_partition, but it may be tough to find a consistent/efficient mechanism at that level (I don’t think you want to pass in a full copy, for example, but maybe you do).

There are no operators before the categorify/fillmedian ops in the workflow for this unittest

Yes and no - For the example above, the‘fit’ call will execute two graphs, one for Categorify, and one for FillMedian. When I look at the actual graphs, they both start with the same read_parquet task, and then comes _transform_partition in both graphs. So you are right that FillMedian is probably not the problem, but I’m willing to bet that some task coming after read parquet is.

EDIT: It seems that those _transform_partition calls are just column selection. Sorry - I am used to seeing column selection as a getitem task, and I mistook them for actual transformations. I also misunderstood the general workflow enough to believe that there were transform dependencies within the fit.

Just a somewhat-related side note:  In more-typical Dask workflows, the read-parquet tasks would have slightly different names in the two graphs (Categorify vs. FillMedian), because they are targetting a different set of columns.  However, this doesn't happen in NVTabular, because we are selecting the columns at the cudf/pd.DataFrame level, rather than the ddf level (and so the parquet->getitem optimization doesn't move the column selection into the read-parquet call).


Jfrog scan does not detect license written in a java file

Hello,
We're trying to scan a java license written in a java file using the xray analysis features.
To do this, we use jfrog cli for the maven build and for scan.
To Reproduce
jfrog config add <serverIdName> --artifactory-url=https://<artifactoryName>/artifactory --user=<user_from_access_token> --access-token=<token> --enc-password
jfrog rt mvnc --server-id-resolve <serverIdName> --repo-resolve-releases maven --repo-resolve-snapshots maven
jfrog rt bp --server-id <serverIdName> --build-url <buildUrl>

jfrog scan --server-id <serverIdName> --format=json --licenses=true  **/**.jar  > xray_result.json

Here are the example of a java file containing a license:
/*-
 * #%L
 * attribution_licence
 * %%
 * Copyright (C) 2022 TEST
 * %%
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 *    this list of conditions and the following disclaimer in the documentation
 *    and/or other materials provided with the distribution.
 *
 * 3. Neither the name of the TEST nor the names of its contributors
 *    may be used to endorse or promote products derived from this software without
 *    specific prior written permission.

 * IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
 * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
 * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
 * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
 * OF THE POSSIBILITY OF SUCH DAMAGE.
 * #L%
 */
package org.continuous_security;

import org.apache.commons.fileupload.MultipartStream;

import java.io.ByteArrayInputStream;
import java.io.IOException;

public class Main {

    public static void main(String[] args) {
        byte[] bytes = new byte[256];
        try {
            new MultipartStream(new ByteArrayInputStream(bytes), bytes);
        } catch (IOException ignored) {
        }
        System.out.println("Program completed.");
    }
}

The result of the Xray scan of the java file shows that no license was found.
Is it normal for the Xray scan not to detect license inside a Java file ?

Hello @usinelogicielle, and thank you for using our product!
The behavior you are experiencing is expected. Xray scan doesn’t detect licenses in every file.
Our mechanism searches for certain files and names/prefixes based on the technology detected in the project. To ensure efficiency, we do not scan every file for license content. Each technology has specific criteria for identifying ‘candidate’ files likely to contain license information, and only those files are scanned.
The files where you placed your license information likely do not meet these criteria, so they were not scanned for licenses. I hope this clarifies everything. If you have any further questions about this topic, please feel free to ask!


Cypress/unit tests. Label deleting feature.

Motivation and context
Add Cypress/unit tests for the feature "Label deleting".
How has this been tested?

Checklist

[x] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG file
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (read github docs)
[ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below)

# Copyright (C) 2021 Intel Corporation
#
# SPDX-License-Identifier: MIT

Coverage increased (+0.2%) to 72.403% when pulling 85ebd675c6cf6fcc1120ea541807ccae7e19a31f on dvkruchinin:dkru/dk-label-deleting-unit-cypress-tests into 86eef84717fc901a1910a0c0290758b774835164 on openvinotoolkit:develop.

@dvkruchinin
Please, update the PR. It shows a lot of changes from another patch and conflicts happened because of it.

Please, update the PR. It shows a lot of changes from another patch and conflicts happened because of it.

Updated.
I did not resolve all the conflicts. I created a new branch from develop, applied my changes and updated the PR.


[BUG] longhorn-engine integration test test_restore_to_file_with_backing_file failed after upgrade to sles 15.4

Describe the bug
After update the base image version from 15.3 to 15.4, the integration test case test_restore_to_file_with_backing_file failed:
 E               subprocess.CalledProcessError: Command '['/go/src/github.com/longhorn/longhorn-engine/integration/common/../../bin/longhorn', '--url', 'localhost:30001', '--debug', 'backup', 'restore-to-file', 's3://backupbucket@us-east-1/s3-test?backup=backup-bafda6d9969b4fcd&volume=test-8bbd430b-volume-backing', '--backing-file', '/go/src/github.com/longhorn/longhorn-engine/integration/common/../../backing_file.qcow2', '--output-file', '/go/src/github.com/longhorn/longhorn-engine/integration/common/../../test-restore_to_file-output.raw', '--output-format', 'raw']' returned non-zero exit status 1.
time="2022-09-28T04:22:54Z" level=fatal msg="Error running restore to file command: failed MergeSnapshotsToBackingFile backup.img.converted -> backing.img.cp: failed rebaseSnapshot backup.img.converted -> backing.img.cp: Failed to execute: qemu-img [rebase -u -b backing.img.cp backup.img.converted], output , stderr, qemu-img: Could not change the backing file to 'backing.img.cp': backing format must be specified\n, error exit status 1"
not sure but probably related to https://gitlab.com/qemu-project/qemu/-/commit/497a30dbb065937d67f6c43af6dd78492e1d6f6d
To Reproduce
Steps to reproduce the behavior:

update sles version from 15.3 to 15.4 like https://github.com/longhorn/longhorn-engine/pull/752/files
run the integration test case

Expected behavior
A clear and concise description of what you expected to happen.
Log or Support bundle
If applicable, add the Longhorn managers' log or support bundle when the issue happens.
You can generate a Support Bundle using the link at the footer of the Longhorn UI.
Environment

Longhorn version:
Installation method (e.g. Rancher Catalog App/Helm/Kubectl):
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:

Number of management node in the cluster:
Number of worker node in the cluster:

Node config

OS type and version:
CPU per node:
Memory per node:
Disk type(e.g. SSD/NVMe):
Network bandwidth between the nodes:

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Number of Longhorn volumes in the cluster:

Additional context
Add any other context about the problem here.

Yeah, I think @yangchiu is right, it's about this commit Require -F with -b backing_file

@weizhe0422 this change will probably impact your PR https://github.com/longhorn/longhorn/pull/4677


Add databases repos

Issue:
What I did
ADD 2 more misc repos:
lib/database & lib/database-local
I'm not sure what these are for and wether we want to continue working with / on them.
Addon comments uses this for persistence, but I guess any addon could want persistence..
How to test
run unit tests

Unsurprisingly, the comments addon does not currently work. See https://github.com/storybooks/storybook/issues/1190


(FACT-3083) add disks serial number and wwid to the disks fact

Integrated https://github.com/puppetlabs/facter/pull/2297, did some refactoring of the disk resolver class, fixed a misleading execution API warning, and renamed the disk resolver.

jenkins please test this on all

jenkins please test this on all


[docs] Restore documentation for states CSS customizations

Steps to reproduce

Open https://master--base-ui.netlify.app/base-ui/react-switch/

Current behavior
No documentation on the different DOM states that can be customized, e.g. [data-disabled]
Expected behavior
Clear API documentation on the CSS API that is available to customize the component. https://mui.com/base-ui/react-switch/components-api/#switch-classes
Context
This is a regression from the DX with @mui/base / @mui/material. Those new states are not automatically documented anymore.
I saw this raised in https://mui-org.slack.com/archives/C05SBSU8NPR/p1723629104973729?thread_ts=1723628372.562069&cid=C05SBSU8NPR.

As a side note, there are also considerations to have with the performance of this new approach: https://mui-org.slack.com/archives/C05SBSU8NPR/p1723640921594739?thread_ts=1723628372.562069&cid=C05SBSU8NPR

https://www.youtube.com/watch?v=nWcexTnvIKI
Benchmarks

https://qwikui.com/docs/headless/select/

Your environment

npx @mui/envinfo
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: -

We're aware the documentation is lacking in this regard. We're going to update it before the stable release.

@michaldudak cool, no urgency on fixing this, but I wanted to flag the need to design this in a way that we can eventually automatically document. If we can't, then I think to design differently.

This will be closed once the changes introduced in https://github.com/mui/base-ui/pull/818 are propagated to all the pages.


add --overwrite option. overwriting all.html with filtered results

Adding a new --overwrite parameter optionally to be used with --ref. Instead of creating a all_filtered.html report page, the all.html report page will be overwritten with the filtered results.

LGTM


Integrate KNN Classifier into AutoML

Remove KNeighborsClassifier from gen_utils._not_used_in_automl and then update the tests to account for the new estimator being counted.

@dsherry @tyler3991 I'm moving this into the next sprint, if that's cool.  The KNN classifier was added, we should probably take the next step and add it to AutoML.  I also know how to do perf tests so I'll self assign.  Thoughts?

yeah that makes sense to me! @chukarsten

@chukarsten what's the status of this?

Sorry I haven't been able to touch this since last sprint.  I put it in automl and ran the perf tests ,but wasn't seeing KNN being selected in any of the rankings.  I then brought back the iris datasets....and still didn't see any selection of knn.

I'll take a stab at this


FIO-6117: fixed an issue where submitDone event is not emitted after submission is saved (need for boxsign action)

related changes:
https://github.com/formio/formio-server/pull/1164
https://github.com/formio/premium/pull/214
https://github.com/formio/formmanager/pull/155


FTS5Config Unavailable on Linux

SQLite.swift (0.12.0) works well on the Linux implementation of my project, until I added an FTS5 search function. FTS5 works well on macOS. However, I get the following error on Linux:
error: use of unresolved identifier 'FTS5Config'
Are FTS5 extensions not available in SQLite.swift when running on Linux? If it is not currently supported, are there plans to include support for FTS5 on SQLite.swift running on Linux?

SQLite.swift was developed for iOS, macOS, tvOS and watchOS. I'm not sure that Linux support was intentional if it is supporting it, but at least, it could be an enhancement.

Linked to #1064

The FTS5 code is currently excluded on Linux. For some reason there is a dependency to SQLiteObjc, which cannot be compiled on Linux.


&attributes() -> Classcast Exception with integers as keys in maps, inside of loops

Sorry, here I am again. :)
Check this:
mixin sorry(param)
  - var steps = {1: "Hi", 2: "abc" }
  for s, index in steps
    p Oh hai

doctype html
html
  head
    title test
  body
   +sorry(123)

Expected:
<!DOCTYPE html>

    <title>test</title>

Oh hai

Oh hai

Added testcase issues/116.jade


Plotting problems and questions

Dear Steven,
many thanks for providing this awesome package. However, I have some trouble with the results pdf as labels don't align properly (which is actually related to this issue).
Additionally, I wonder why so much samples are discarded, see following:
MrBayes is working on the ASR...
Summarizing the results...
Plotting the tree...
Results were written to file.

Samples requested: 10000
Percent discarded: 96.4
Percent summarized: 3.59999999999999

Here are my results including the newick tree, the resulting pdf, and MrBayes.ASR.results.txt.
Many thanks,
Bastian

Hi Bastian,
Can you please send me your tree and trait data input files so I can try to recreate the issue?
Thanks,
Steven
On Wed, May 12, 2021 at 4:49 AM, bastianheimburger @.***> wrote:

Dear Steven,
many thanks for providing this awesome package. However, I have some trouble with the results pdf as labels to not align properly (which is actually related to this issue).
Additionally, I wonder why so much samples are discarded, see following:
MrBayes is working on the ASR...
Summarizing the results...
Plotting the tree...
Results were written to file.
Samples requested: 10000
Percent discarded: 96.4
Percent summarized: 3.59999999999999
Here are my results including the newick tree, the resulting pdf, and MrBayes.ASR.results.txt.
Many thanks,
Bastian
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hi Steven,
here you go.
Many thanks for your help,
Bastian

Many thanks,
I might be mistaken but did you forget to attach the plot settings file?
Cheers Bastian

Sorry, I included via an email attachment and not on GitHub. I'll put it here for you too. And yes, 10000 samples is correct. The trace plots will show you a little more info. All my best, Steven
BH.zip

Thx


StackOverflow in GeneralPhase 1.10.2

I am currently running

SpongeForge version: spongeforge-1.10.2-2477-5.2.0-BETA-2790
SpongeVanilla version: N/A
Java version: 1.8.0_144
Operating System: Linux

Plugins/Mods:
Project Ozone Lite v1.3.4
Listed in provided pastebin.

Issue Description
Crash Report: https://pastebin.com/0bGnuAJ2

no reproduction and wrong repo, please reopen in SpongeForge when you have a reproduction


fix: login error even after correct credentials

Fix: #112
Stored jwt in localstorage and verified during sketchbook opening

LGTM


Migrate to pyproject.toml

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure to update the docs?
[x] Did you write any new necessary tests?

What does this PR do?
Migrate from setup.cfg to pyproject.toml
Fixes #90
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Off 🥳

@Borda - Would you like me to use ruff in utilities? If not, a .flake8 file is needed. Let me know 👍🏻

@Borda - Would you like me to use ruff in utilities? If not, a .flake8 file is needed. Let me know 👍🏻

let's also use ruff :)

Hey @Borda,
I have added ruff. Like metrics, do you want to migrate pydocstyle and isort in separate PRs? I believe pre-commit does not read the pyproject.toml for run configurations, so .pre-commit-config.yaml should be updated to reflect the pyproject.toml.
Let me know 👍🏻

@Ce11an Thank you for working on this!

I believe pre-commit does not read the pyproject.toml for run configurations, so .pre-commit-config.yaml should be updated to reflect the pyproject.toml.

I haven't tried, but I think there is no need to reflect any changes in pyproject.toml to pre-commit-config.yaml as isort/black/ruff etc. called by pre-commit automatically read their configuration in pyproject.toml, no?

do you want to migrate pydocstyle and isort in separate PRs?

yes, let's do it separately and keep PRs rather more focused :)

do you want to migrate pydocstyle and isort in separate PRs?

yes, let's do it separately and keep PRs rather more focused :)

I believe pre-commit does not read the pyproject.toml for run configurations, so .pre-commit-config.yaml should be updated to reflect the pyproject.toml.

it does, as you can simply check it adding some super strict check, like the D or SIM

Ah, awesome. Good to know - thanks!