Panic asserting call_ensures about clone

I'm attempting to write some proofs to reason about the equality of certain cloned objects. I'm using call_ensures based on some discussion with Chris and also a few messages about using it to reason about clone and eq in Zulip but this seems to be causing a panic in Verus.
Here's a minimal code snippet that reproduces the bug. I've found that assert(forall |a: Self, b: Self| call_ensures(Clone::clone, (&a,), b) ==> a == b) also causes the panic,  but including it as a postcondition of an associated proof function in a trait definition is fine (until I attempt to provide an implementation for the proof).
#[derive(Copy, Clone, Debug)]
pub struct Foo {
    val: u64,
}

impl Foo {
    proof fn lemma_clone()
        ensures
            forall |a: Self, b: Self| call_ensures(Clone::clone, (&a,), b) ==> a == b,
    { assume(false); }
}

The error message is:
thread '<unnamed>' panicked at vir/src/datatype_to_air.rs:740:42:
expected fndef function in pruned crate
note: [run with `RUST_BACKTRACE=1` environment variable to display a backtrace](https://play.verus-lang.org/?version=stable&mode=basic&edition=2021&gist=0a9afd2f5757d05349df8857af6d7b5f#)
thread '<unnamed>' panicked at rust_verify/src/verifier.rs:2123:29:
worker thread panicked

(Playground link: https://play.verus-lang.org/?version=stable&mode=basic&edition=2021&gist=0a9afd2f5757d05349df8857af6d7b5f)
My local Verus version:
Verus
  Version: 0.2<IP_ADDRESS>c73e
  Profile: release
  Platform: linux_x86_64
  Toolchain: 1.79.0-x86_64-unknown-linux-gnu

Currently, the recommended way to do this is:
#[verifier::external_fn_specification]
pub fn ex_foo_clone(b: &Foo) -> (res: Foo)
    ensures
        res == b,
{
    b.clone()
}

The reason for the panic is that Verus doesn't recognize the Clone trait implementation, probably because the derive(Clone) macro doesn't add the verus_macro to it. I'm not sure why it's a panic instead of a normal error; I need to look into that more.

Commit https://github.com/verus-lang/verus/commit/84ca82146bbfd836a3b18488d63a249071b45ef4 fixes the panic to a normal error message.


Update Panel packs with latest working preferences

Background
We have enabled SETs to view working preferences answers in the application view. The panel pack (Google drive document) now needs updating to correctly present the new working preferences answers.
Feature(s)

[x] Update panel pack Google doc with new working preferences answers

Hey team! Please add your planning poker estimate with Zenhub @drieJAC @HalcyonJAC @tomlovesgithub

The work for this ticket was completed in the digital platform codebase.
See this PR: https://github.com/jac-uk/digital-platform/pull/1083

@nickaddy
The work here is purely back end in the digital-platform.
As there are no UI changes @drieJAC has added the testing instructions to this ticket. It is fine to use the main admin-develop and admin-staging URLs for testing.
Up to you whether it goes to UT tomorrow or just has internal testing by the product team. As and when you are happy I guess the label can be changed from 'Needs internal UT' to 'Passed internal UT'... or be removed. The ticket can then be closed


Do not allow guest users to run workflows on the production system

right now low priority.

Discussion 1/13: @Yicong-Huang will do it

@Xiao-zhen-Liu is this (implicitly) done? what's the behavior now?

@Xiao-zhen-Liu is this (implicitly) done? what's the behavior now?

@Yicong-Huang In the current production guest won't be able to run the workflow. There is no workflow number and the "Run" button is disabled.

thanks. then can we say this is implicitly done and close this issue?

Yes.


rpcbind required for remote connections?

Issue Template
Context
Unable to connect to the daemon, unless daemon is binded to network card ip address. rpcallow does not work.
Prerequisites
5.0.0 develop
Ubuntu 18.04
User Story:
MAYBE: [ ] bug report 😄
The daemons looks like its bound to <IP_ADDRESS> which should allow access across all network devices, right? (Assuming remote device IP address is allowed in config)
tcp        0      0 <IP_ADDRESS>:15556      <IP_ADDRESS>:*               LISTEN      26544/verged
tcp        0      0 <IP_ADDRESS>:15559           <IP_ADDRESS>:*               LISTEN      26544/verged
tcp6       0      0 :::15559                :::*                    LISTEN      26544/verged

This works on other daemons at least. However i was not able to communicate with the new verge daemon using this method, however by starting the daemon with a specified --rpcbind=<IP_ADDRESS> - i can access the daemon remotely with a computer on the same network:
tcp        0      <IP_ADDRESS>:15556      <IP_ADDRESS>:*               LISTEN      30664/verged
tcp        0      0 <IP_ADDRESS>:15559           <IP_ADDRESS>:*               LISTEN      30664/verged
tcp6       0      0 :::15559                :::*                    LISTEN      30664/verged

Not really a problem since it can be binded to a specific IP, and heck its even safer, but i though is should put some light on this.

I quote stackoverflow for this one: <IP_ADDRESS> vs <IP_ADDRESS>

<IP_ADDRESS>, in this context, means "all IP addresses on the local machine" (in fact probably, "all IPv4
addresses on the local machine"). So, if your webserver machine has two IP addresses, <IP_ADDRESS>
and <IP_ADDRESS>, and you allow a webserver daemon like apache to listen on <IP_ADDRESS>, it will be reachable at both of those IP addresses. But only to what can contact those IP addresses and the web port(s).

So I guess everything is working as expected as you are probably not on the same machine, thus you have to explicitly bind a specific IP interface.

binding to <IP_ADDRESS> is never recommended

Binding to <IP_ADDRESS> is by default on all daemons i think, but binding to a
specific adapter is safer👍
Den man. 4. mar. 2019, 21:33 skrev sunerok<EMAIL_ADDRESS>
binding to <IP_ADDRESS> is never recommended
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vergecurrency/VERGE/issues/888#issuecomment-469411008,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOPNkiWtpz-LsFyS7y0zUfGCtevxV1Arks5vTYMwgaJpZM4bdGVU
.

see https://github.com/bitcoin/bitcoin/issues/8502#issuecomment-239621457

Yeah, the test daemon was missing server=1 in config, which was the reason for the result i had.

If there is no instances of rpcallowip, the daemon will bind to <IP_ADDRESS> allowing only localhost access
If there is instances of rpcallowip, and server= is not set or false, it seems that the daemon will bind to <IP_ADDRESS> but not allow remote connection(undependent of defined rpcallowip's)??
If there is instances of rpcallowip, and server=1 daemon will bind to <IP_ADDRESS> and allow access from all rpcallowip's

portmapper on RHEL-5 could be secured by having it listen on localhost
only. rpcbind does not offer this option. tcpwrappers and firewall can be
used for securing both portmapper and rpcbind.
To secure rpcbind with tcpwrappers use something like:

Raw https://access.redhat.com/solutions/106563#
cat /etc/hosts.allow
rpcbind: <IP_ADDRESS>
cat /etc/hosts.deny
rpcbind: ALL
On Wed, Mar 6, 2019, 01:32 cod3gen<EMAIL_ADDRESS>wrote:

Yeah, the test daemon was missing server=1 in config, which was the reason
for the result i had.

If there is no instances of rpcallowip, the daemon will bind to
<IP_ADDRESS> allowing only localhost access
If there is instances of rpcallowip, and server= is not set or
false, it seems that the daemon will bind to <IP_ADDRESS> but not allow remote
connection(undependent of defined rpcallowip's)??
If there is instances of rpcallowip, and server=1 daemon will bind
to <IP_ADDRESS> and allow access from all rpcallowip's

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/vergecurrency/VERGE/issues/888#issuecomment-469701052,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJWN2vn9VgCmUzWOZ4t7dj-TQe4vtMVuks5vTn_5gaJpZM4bdGVU
.


Interpretation of the result

Hi,
Thank you for providing the code for this amazing work. I have a question for which I seek your guidance. When I run the basic resnet50 code for CAM on CUB200, I get the following results on the test set
Split test, metric classification, current value: 50.517777010700726
Split test, metric localization, current value: 58.97480151881257
Split test, metric localization_IOU_30, current value: 96.08215395236452
Split test, metric localization_IOU_50, current value: 66.27545736969279
Split test, metric localization_IOU_70, current value: 14.566793234380393

I wanted to confirm whether metric localization corresponds to the MaxBoxAcc-v2 metric that you rmention in your work? Also what does metric localization, current value  mean?. In Table 6 of your paper, do you report metric localization_IOU_50? Looking forward to hearing from you.
Thanks

I think  Split test, metric localization, current value corresponds to the final MaxBoxAcc-v2 score in Table6, which is the average of IOU_30, IOU_50, and IOU_70 as mentioned by the authors.

Thank you for your interest in our work!
By default, the metric localization means the average of IOU_30, IOU_50, and IOU_70.
Please also note that if you set box_v2_metric to False, it means IIU_50.

Thanks @Jazzcharles and @junsukchoe


Sync eng/common directory with azure-sdk-tools for PR 2372

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/2372  See eng/common workflow

/check-enforcer override


refactor: Extract common code from responders into EntityAndClassIriS…

Pull Request Checklist
Task Description/Number

Introduce ProjectsAdminService as at first a wrapper around its own instances of the ProjectsResponderADM exposing the method used in the zio http route
Introduce EntityAndClassIriService as dedicated service allowing for breaking up the inheritance hierachy
Introduce ActorDeps as a zio layer - a class encapsulating all Akka dependencies necessary to interact with the [[org.knora.webapi.core.actors.RoutingActor]] aka. "appActor"

Basic Requirements
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix: represents bug fixes
[x] Refactor: represents production code refactoring
[ ] Feature: represents a new feature
[ ] Documentation: documentation changes (no production code change)
[ ] Chore: maintenance tasks (no production code change)
[ ] Style: styles updates (no production code change)
[ ] Test: all about tests: adding, refactoring tests (no production code change)
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Does this PR change client-test-data?

[ ] Yes (don't forget to update the JS-LIB team about the change)
[x] No

Overall looks good. There are few typos - see my comments/suggestions.
Thanks for fixing that.

Wouldn't also make sense to write some unit tests for stuff you have moved to separated services?

In general I agree that new code should be covered with unit tests. I will look into if I can improve the coverage. However, I will have to look into if testing the EntityAndClassIriService (it is sending stuff to our actor) with zio-test is worth the effort.


fix(defect): SPDX Identifier

Caught this when flattening the contracts into one.

Hi @sambacha thanks for your contribution.
Happy to accept the SPDX fix, but regarding changing the foundry.toml file, I think we should create another PR for it and discuss each change there.

Hi @sambacha thanks for your contribution.
Happy to accept the SPDX fix, but regarding changing the foundry.toml file, I think we should create another PR for it and discuss each change there.

Do you want me to just leave the top level change or revert the entire thing?

amended the offending changes, note that the top level directive of the profile is a requirement now for foundry. If your using the latest forge you will be greeted with a warning message informing you to update the configuration file.

Also, why not make the compiler version min. the requirement at least ^0.8.4? Should I open separate issues?
Cheers 🤠

amended the offending changes

Thanks! Just wanted to separate concerns so I can understand the rationale better.

note that the top level directive of the profile is a requirement now for foundry

Foundry's moving so fast! I think they should also update this in their READMEs, they're still using [default]:
https://github.com/foundry-rs/foundry/tree/37e4376cfbf1d2ce35c0c4eb25f7131c9fc1f8e2/config

Why not make the compiler version min. the requirement at least ^0.8.4?

Big fan of custom errors too. But I guess it doesn't hurt to keep the pragma to >=0.8.0? Users can still use >=0.8.4 in their own tests file, there wouldn't be any clash.

amended the offending changes

Thanks! Just wanted to separate concerns so I can understand the rationale better.

note that the top level directive of the profile is a requirement now for foundry

Foundry's moving so fast! I think they should also update this in their READMEs, they're still using [default]:
foundry-rs/foundry@37e4376/config

yup, automate all these things otherwise its ngmi

Why not make the compiler version min. the requirement at least ^0.8.4?

Big fan of custom errors too. But I guess it doesn't hurt to keep the pragma to >=0.8.0? Users can still use >=0.8.4 in their own tests file, there wouldn't be any clash.

Will open an issue shortly, its related.
Thanks!


Is project still active?

Sure, the community is working on the 1.0 version, will greatly enhance the job routing, orchestration, and  multitenancy capabilities, along with a cleaner architecture and simpler API.

Project will live long and prosper.


Why throw an error in the getFirstListItem function instead of just returning undefined?

https://github.com/pocketbase/js-sdk/blob/efa9f6ada350a3d6666e54a4140548a555d95427/src/services/utils/BaseCrudService.ts#L101
It would be simpler to return an undefined to mean that the query did not find anything.

For consistency with the other "find one" type of methods. It is mentioned in the jsdoc comment:

For consistency with _getOne, this method will throw a 404 ClientResponseError if no item was found.


Problem with working EntityFramework.DynamicFilters

Hi,
I've problems with Effort combined EntityFramework.DynamicFilters.
I shared the code and informations here:
https://gist.github.com/hikalkan/17457ec9c972e4d2a333
Can you check it?
Thanks.

I also added issue to DynamicFilters since I don't know what causes the problem: https://github.com/jcachat/EntityFramework.DynamicFilters/issues/28
Both libraries are good and I want to use them together. Please check the problem.

Hi,
It's resolved: https://github.com/jcachat/EntityFramework.DynamicFilters/issues/28.


fix(interactive): Fix bugs of runtime

Fix bugs in scan and group by.
Fix #4378

TODO: make sure collect(labels()) returns the correct type.


Default plotting style context doesn't affect the facet colour

The plotting.context function tries to set the defaults for 'axes.facecolor' and 'figure.facecolor' using seaborn.plotting_context(), but it cannot work as  that function is intended to control the scale of plot elements, not those properties. The seaborn.axes_style()  fucntion should be used instead. See http://seaborn.pydata.org/tutorial/aesthetics.html

The fix can be ported from here as the code is identical

@luca-s sounds like a plan, want to submit a PR?

sure!

Closed by #361.


[Problem] User Interface : Sub-Panel Automatic Opening/Closing

Summary
When a sub-panel does open/close automatically, it only open/close it parent panel
Exemple
Taking the example of

"debug.internalConsoleOptions": "openOnSessionStart"
"debug.console.closeOnEnd": false
:

Current

When a debug session ends:
The whole debug console parent panel is closed, rather than only the debug console sub-panel to be collapsed
When a debug session starts:
The whole debug console parent panel is opened, but the debug console, as a sub-panel is not expended if it wasn't expended before

Expected

When a debug session ends:
Collapse the debug console sub-panel

When a debug session starts:
Expend the debug console sub-panel

Does setting "debug.internalConsoleOptions": "openOnSessionStart" do it for you?

Comment Reply from @roblourens :

Does setting "debug.internalConsoleOptions": "openOnSessionStart" do it for you?

Not exactly, it's part of a more important UI problem in visual studio code.
I'm going to convert this issue to make it about that

Sorry, I don't follow, can you explain more?

@roblourens
When a sub-panel (or tab, idk the exact terminology) does open/close automatically (for example the default "debug" sub-panel), the whole panel area is open/closed rather than only the precise sub-panel to be collapsed/expanded


Using FreeRTOS timer in UART ISR results in crash

Hi Team,
I am using AWS freeRTOS version 202007 and ESP32.
I am using UART interrupt handler to raise interrupt, when I receive data on UART.
In the UART interrupt handler, I am calling xTimerStart(timer_handle, 0 );
In the initalisation I did xTimerCreate( pcTimerName,
pdMS_TO_TICKS( 30 * 1000 ),
pdFALSE,
NULL,
Timer_Callback );
As soon as the data is received and xTimerStart is called, it crashes. The following is the error I am receiving.
core=0 port_interruptNesting=1
/opt/amazon-freertos/freertos_kernel/portable/ThirdParty/GCC/Xtensa_ESP32/port.c:315 (vPortAssertIfInISR)- assert failed!
abort() was called at PC 0x4008e3df on core 0
ELF file SHA256: c91d6659ccfed3e4
Backtrace: 0x4008d034:0x3ffbe210 0x4008d265:0x3ffbe230 0x4008e3df:0x3ffbe250 0x400900aa:0x3ffbe270 0x40090597:0x3ffbe290 0x400d342d:0x3ffbe2b0 0x40080f19:0x3ffbe2d0 0x4008177e:0x3ffbe2f0 0x4018aa03:0x00000000
But if I use ESP32 timer in UART ISR it works fine and it does not crash.
So this concludes, we cannot use FreeRTOS timers in UART ISR?
Can you please confirm this as soon as possible? Am I doing any thing wrong here? Is this the expected behaviour?
Thank you.

Many FreeRTOS API's cannot be called from interrupt and the xTimerStart API is no exception.  However, in most cases, an ISR friendly version of the API function is available.  In this case, the xTimerStartFromISR can be called from the interrupt.  The calling parameters are slightly different so you cannot simply add 'FromISR' to the function call.
For more information consult the API documentation here:

Hi @kumarfirmware,
Did the above response resolve your issue? We will close this issue if we don't hear back from you.
Thanks

Please close the issue.

Issue is resolved.


feat: Use go 1.22 by default

Use go 1.22 by default

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-11.5%) to 2.066%

Totals

Change from base Build<PHONE_NUMBER>:
-11.5%

Covered Lines:
23

Relevant Lines:
1113

💛  - Coveralls


Evaluate loading mask implementation, as compared to desired implementation in sl-panel

duplicate of #1188?


Update doc linking to examples for issuers and certificates.

Using sed to replace example-com with $DOMAIN environment variable was not exactly correct : replacing example.com in certificates wasn't done.
I suggest adding examples using yaml files instead, both for certificates (normal or wildcard) and for issuers (namespaced or global using a ClusterIssuer)
I also bumped apiVersion to cert-manager.io/v1 for certificates and issuers to remove deprecation warnings.

Thanks, I'm a bit late. I'll look at it soon!


not able to pass memory scoped variable to  attachment in adaptive dialog

Github issues should be used for bugs and feature requests. Use Stack Overflow for general "how-to" questions.
Version
latest version of  preview
Describe the bug
Give a clear and concise description of what the bug is.
To Reproduce
here i am creating attachment layout and passing user.id  as the url.
my requirement is show a Carousel and if user click on the link tack on that user in different third party system.
variable is working if i use simple  SendActivity("user id {user.id}")
but in this scenario it is not rendering.
var myactivity = dc.Context.Activity.CreateReply();
myactivity.AttachmentLayout = AttachmentLayoutTypes.Carousel;
                        var h = new HeroCard()
                        {
                            Title = o.Title,
                            Text = o.Message,

                            Images = new List<CardImage> { new CardImage {
                            Url = o.ImageUrl
                              } },
                            Buttons = o.Buttons.Select(a => new CardAction
                            {
                                Type = "imBack",
                                DisplayText = a.Name,
                                Value = $"{o.Title} : {a.Name}",
                                Text = a.Name,
                                Title = a.Name

                            }).ToList()
                        };
                        if (!string.IsNullOrWhiteSpace(o.Url))
                        {
                            h.Buttons.Add(new CardAction
                            {
                                Type = "openUrl",
                                DisplayText = "Learn More",
                                **Value = "https://abce.com/id={user.id}",**
                                Text = "Learn More",
                                Title = "Learn More"

                            });
                        }
                        myactivity.Attachments.Add(h.ToAttachment());

                dialog.Steps.Add(new SendActivity(myactivity));

Expected behavior
Give a clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
[bug]

@vidya091209 is this a preview of 4.6 or off of 4.Future?

yes this for adaptive dialog 4.Future branch

@vidya091209 are you using language generation in your bot or just adaptive dialogs?

i am using adaptive dialog only. in my scenario these  values comes at run time  from api so i can use .lg file. i am constructing the whole flow at run time.

We do not support data binding when you pass a custom activity.
@tomlm - any workarounds?

@vidya091209 - discussed this in triage and we do not support data binding when you are bringing in your own custom activity. The options are

Switch to using LG
Implement your own data binding logic. See here for what SendActivity does


Detection and therefor triggering stops working

After a couple hours it seems to not be detecting new photos in the input directory. The cameras are putting the photos there, the container just stops seeing them.
Are there some logs that would be the best to look at? It works for the first couple hours after restart and then just stops seeing new photos.

There are copious logs available in Docker Desktop. Look for the logs on the trigger container and you'll see if it is still detecting images.
My guess is this is related to having too many images in the detection folder. See the 80% CPU troubleshooting instructions on the wiki and try the changes suggested there: https://github.com/danecreekphotography/node-deepstackai-trigger/wiki/Troubleshooting#problem-the-container-causes-80-cpu-usage.

Found out the issue. Seems my watchtower installation was trying to stop the containers unsuccesfully when trying to update all my containers. Disabled watchtower and have had no issues since.


dialog: allow to hide dialog with openImmediately set

was broken by https://github.com/callemall/material-ui/commit/f8bdaf347da3cfd12be0f85a5a9d8bdbbd5a3e95
does it make sense to call setState({open: true}) in that case?

@cgestes I think your PR is good since it will trigger the related events. Thanks.


Documents in github

Describe the problem you'd like to have solved
I think we need to add more detail in GitHub README.md for pactus
and explain a little more about it for new commer developers in pactus
that's easier instead than directing them to the website before anything
adding this part and fixing this is not too hard and doesn't take much time I think, but it can help so much.

Did you check the CONTRIBUTING.md and install.md

I also check and read them.
but I thought having more detail in README.md can help.
how ever, if it's unnecessary we can close it.

For more documents, we can use the docs folder.
Add everything in README is not a good idea.


Speed up git stats by calling it less

Hi,
Thanks for this, I couldn't quite get powerline itself to work in my setup so this is handy.
Where I work the git repo is really big so each git command takes about 0.3 seconds.
As there a few it takes about a second to draw for the prompt to draw.
I don't know git well enough to provide a patch, but I was looking at whether its possible to get more of the stats using fewer external commands,
As an experiment I've made a script that gets the changed file count, and the the amount of insertions, using one call to git diff --shortstat and then parsing the output in bash.
Maybe this would be useful in helping speed up rendering of the prompt?
$  ./parse_git_stats.sh

original output: " 3 files changed"
changed: '3'
inserted: '4'

script:
#!/bin/bash

# Set comma as the delimiter
IFS=','

read -a gitstat <<< $(git diff --shortstat)

# Example output from git diff --shortstat:
#  3 files changed, 4 insertions(+)
#
# read has split it by comma, next remove space prefix and text suffix
# using bash.

git_changed=${gitstat[0]%" files changed"}
git_changed=${git_changed# }

git_insertions=${gitstat[1]% "insertions(+)"}
git_insertions=${git_insertions# }

echo "changed: '"$git_changed"'"
echo "inserted: '"$git_insertions"'"

Most of the work is removing the prefixes + suffixes from the strings.

OK, not sure if this is quite right (may have been looking at a different repo).
The prompt taking > 1 second to draw is definitely a bit of showstopper though.

Hi,
You can benchmark the segments by editing __powerline_prompt_command to output how long each one takes:
function __powerline_prompt_command {
  local last_status="$?" ## always the first
  local separator_char="${POWERLINE_PROMPT_CHAR}"

  LEFT_PROMPT=""
  SEGMENTS_AT_LEFT=0
  LAST_SEGMENT_COLOR=""

  TIMEFORMAT=%R
  ## left prompt ##
  for segment in $POWERLINE_PROMPT; do
    local f="__powerline_${segment}_prompt"
    #local info="$(__powerline_${segment}_prompt)"
    echo -ne "$segment: "
    time local info="$($f)"
    [[ -n "${info}" ]] && __powerline_left_segment "${info}"
  done

  [[ -n "${LEFT_PROMPT}" ]] && LEFT_PROMPT+="$(__color - ${LAST_SEGMENT_COLOR})${separator_char}$(__color)"
  PS1="${LEFT_PROMPT} "

  ## cleanup ##
  unset LAST_SEGMENT_COLOR \
        LEFT_PROMPT \
        SEGMENTS_AT_LEFT
}

Then re-run .bashrc:
source ~/.bashrc

And get timing output:
/.bash/themes/git_bash_windows_powerline> > master>>
last_status: 0.389
user_info: 0.069
cwd: 0.069
scm: 2.744

There a few possible avenues for optimisation, but having timing information makes it much easier.

Based on this, I've made an easy performance fix for last_status.
https://github.com/diesire/git_bash_windows_powerline/pull/3


External assets being used when using beercss as a NPM package.

https://github.com/WardPearce/Materialious/issues/173

@WardPearce nice project!
https://github.com/beercss/beercss/blob/main/src/cdn/settings/fonts.css
As you can see, the external url is just a font fallback when the local font fails (it's highly recommended to have a font fallback). The modern bundlers should put the local fonts on the right path automatically.
Just verify if the bundler is copying the fonts on the right path. If not, do that mannually.


hovering over the layer switcher icon it dissappears

When I hover over the layer switch icon it collapses to the right and I'm unable to click on it to open the layer switcher up.
I am using:

OpenLayers: 10.1.0
LayerSwitcher: 4.1.2

Issue was replicated in:

Microsoft Edge: Version 128.0.2739.79
Chrome: Version 121.0.6167.86

I missed the line about supported OpenLayer versions, but i back versioned to<EMAIL_ADDRESS>and this is still an issue.

Hi, if you can share a https://codesandbox.io/ sandbox (or similar) which reproduces the issue I'll happily take a look.

https://codesandbox.io/p/devbox/modest-forest-z3q5z3?workspaceId=aff9888e-7567-4a7a-b0eb-e3ba1a15405a

@ls91 I think you're missing the title properties on your layers.
I've added a title and type: 'base' to the OSM layer and a title to the other layer which causes the layers to be displayed in the layer switcher:

Thanks @walkermatt , you're right, adding the titles it opens and closes as expected.


test:add delete api tests

Signed-off-by: letty<EMAIL_ADDRESS>
1.Describe what this PR did
2.Does this pull request fix one issue?

3.Describe how you did it
4.Describe how to verify it
5.Special notes for reviews

I think we can encapsulate two functions: CreateBusyBoxContainer and RunBusyboxContainer. Then we can reduce some duplicated codes. How about DRY(Don't repeat yourself)?

How about just create a container in the SetUpSuite() function. As a wrapper of container created option could not largely reduce the dup code, args are still needed.

LGTM


Enhancement in the Footer Section

Enhancement in footer section

Title :Enhancement in footer section
Issue No. :48
Code Stack :
Close #<48>

Video (mandatory)

https://github.com/user-attachments/assets/d3a6baee-2f4c-445c-b62b-64b9f340cb8a
Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md if its a new page/tech stack
[x] I have gone through the  contributing.md file before contributing

Additional context (Mandatory )
Are you contributing under any Open-source programme?

[x] I'm a GSSOC-EXT contributor
[x] I'm a HACKTOBERFEST contributor

@ShreyaSnehal Sorry, by the time the entire footer is already changed


Rank and honor: with Explanation

Created as another take on #106. Still some things to do (verify links, navigation, sidebar), but please let me know how you like it.
Yay, got it working first time, and I am quite fond of the effect :)
However, I do not know what to do to have some kind of top level navigation from docs main page to https://deploy-preview-111--reverent-edison-2864ea.netlify.app/explanations/gamification/ - do we miss something on the main page, like an icon for "Explanations"/"About"? - I think I got it, just tell me how you like it.

I begin to review the other PR... Should I review this one instead?

Both have the same content, this one has different (better IMO) organization, so yes, I'd say I prefer this one.

@kazk : lemme some time before you begin your review: I'll create another branch of this one with some significative changes, so if you wait, you'll only review the one that suits you the most.

Obsoleted by #112.


Warnings in Django 1.8.

There are at least two warnings with django 1.8:
/home/tulipan/Proyectos/IspanyolHaber/lib/python3.4/site-packages/django_extensions/management/commands/sqldiff.py:954: RemovedInDjango19Warning: django.db.models.get_app is deprecated.
  app_list = [models.get_app(app_label) for app_label in app_labels]

/home/tulipan/Proyectos/IspanyolHaber/lib/python3.4/site-packages/django_extensions/management/commands/sqldiff.py:960: RemovedInDjango19Warning: django.db.models.get_models is deprecated.
  app_models.extend(models.get_models(app, include_auto_created=True))

/home/tulipan/Proyectos/IspanyolHaber/lib/python3.4/importlib/_bootstrap.py:321: RemovedInDjango19Warning: The utilities in django.db.models.loading are deprecated in favor of the new application loading system.
  return f(*args, **kwds)

/home/tulipan/Proyectos/IspanyolHaber/lib/python3.4/importlib/_bootstrap.py:321: RemovedInDjango19Warning: django.contrib.contenttypes.generic is deprecated and will be removed in Django 1.9. Its contents have been moved to the fields, forms, and admin submodules of django.contrib.contenttypes.
  return f(*args, **kwds)

Warnings in django 1.8.3
.../django_extensions/management/modelviz.py:27: RemovedInDjango19Warning: django.contrib.contenttypes.generic is deprecated and will be removed in Django 1.9. Its contents have been moved to the fields, forms, and admin submodules of django.contrib.contenttypes.
  from django.contrib.contenttypes.generic import GenericRelation

.../django_extensions/management/modelviz.py:81: RemovedInDjango19Warning: django.db.models.get_apps is deprecated.
  apps = models.get_apps()

.../django/db/models/__init__.py:55: RemovedInDjango19Warning: The utilities in django.db.models.loading are deprecated in favor of the new application loading system.
  from . import loading

.../django/db/models/__init__.py:56: RemovedInDjango19Warning: [a.models_module for a in get_app_configs()] supersedes get_apps().
  return getattr(loading, function_name)(*args, **kwargs)

.../django_extensions/management/modelviz.py:97: RemovedInDjango19Warning: django.db.models.get_models is deprecated.
  appmodels = get_models(app)

.../django/utils/lru_cache.py:101: RemovedInDjango19Warning: The app_mod argument of get_models is deprecated.
  result = user_function(*args, **kwds)

PR's are welcome

These might be fixed - at least there were no errors when I've tried it with Django master (1.9).

These are failing in django 1.9 (see: https://travis-ci.org/django-extensions/django-extensions/jobs/94789533)
I'm looking into it..

These have been adressed in PR #772


Clean up unit test logs on success.

Add a little bit of shell variable safety and tweak output.

test-only.sh and test-all.sh will clean up after themselves by deleting successful unit test output logs. Logs will be left on failure to allow for analysis.
Reviewers: @rec @nbougalis

:+1:

:+1:
I'm thinking of taking a few minutes to port this into Python - because I already reviewed those | sed | split lines before and yet I had to work out again what they did.

Also - I don't think we generally put the creator as a label of a pull request.  Indeed, I suggested that but it wasn't well-received at the time...

@rec I am 100% behind porting this to Python. The only reason I didn't do it myself is because I still haven't sat down with Python, whereas I can whip out this shell script in the same "few minutes" timeframe.
I didn't think we made a decision about "author as label", but left it up to individual preference. I like putting myself as a label so I can see all the reviews I'm involved with on a single page. ie. https://github.com/ripple/rippled/labels/ed


Cargo.toml: upgraded crates to their latest versions

Hey @DemiMarie ,
I'm pinging you again since I don't know if you get the PR notifications so you don't miss this.
Cheers :D


feat: Add pull request support to SCM generator

This commit adds pull request support to SCM generator so the generator
can create ArgoCD apps for PRs as well.
Fixes https://github.com/argoproj/applicationset/issues/466
Signed-off-by: Fardin Khanjani<EMAIL_ADDRESS>

Waiting for https://github.com/argoproj/applicationset/pull/472 to be merged.

@fardin01 :  Can u please move this PR into argocd as applicationset is moved. If u find it laborious, i can do it on your behalf with your consent

@rishabh625 Please feel free to move this PR over to argocd repo. I should have some time to get back at this pretty soon. Thanks :)


added test to demonstrate issue 1466

Hey, why wait? Here's that first pull request I promised.
Not sure if this is the right place or right way to test this case, but I thought it'd be a good way to show what I'm seeing.

Hey!  Thanks for this and sorry for not getting back sooner.
I'm not sure that this test is checking the right thing or not.  I tried removing include Neo4j::UndeclaredProperties from the PersonWithTimestamps definition and it still was failing.
Looking at the timestamped model definition (spec/shared_examples/timestamped_model.rb), it looks like there are some examples from those examples which depend on the a and b properties existing.  When I set those properties on the model the tests seem to pass.
Please let me know if I'm missing something

@anamba indeed the timestamped model shared example requires too much context. So far there is a single usage of it. The shared_example would have to first made more generic and reusable. But if you see an issue in the code rather than spec I would suggest to formulate a new spec from scratch to demonstrate it. Unless of course you want to fix the shared_example first which would be appreciated.

Wow, blast from the past. :-)  Sorry, but I no longer use this gem (using Elixir for new projects these days).


[TFMicro][RFC] Create a utility that takes model and generates model-data and ops-re…

Saves the developer from knowing the model architecture or the operations used in the model.

Currently the model data to CC conversion happens through the xxd
utility. But the other piece that is dependent on the model is the
ops-resolver. Having to understand a model to generate the
ops-resolver is additional overhead
This utility does both of the above processing in a single go

Would something like this be of interest?
I also have some thoughts about including additional annotations in the model, being converted, so it can be used for placing specific components in the model in faster/slower memory. But that's in the future.
TODOs:

This is done as an example for Request For Comments for micro-speech, can be extended to other applications
Relies on flatc utility (as other utilities within the repo rely on this). Open to suggestions for using any native Python library for parsing the model

@petewarden would like your inputs here

@kedars Can you please resolve conflicts? Thanks!

@kedars Can you please resolve conflicts? Thanks!

Done

@petewarden Can you please take a look on this PR? Thanks!

It has been 30 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

CC @AdityaHPatwardhan

It has been 15 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

Sorry for the delayed update, This MR is still worked on, will update today itself.

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

@AdityaHPatwardhan, @kedars  Any update on this PR, Please. Thanks!

Yes, I have started working on this, I will update the MR this week.

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

@AdityaHPatwardhan, @kedars Any update on this PR, Please. Thanks!

I'm going to go ahead and close this PR, because it seems to have stalled. If you're still interested in pursing this (and responding to my comments), please feel free to reopen!


gNMI-1.21 - Remove threshold state validation for /components OC path

As discussed in internal bug b/281931161#comment37, removing

/components/component/integrated_circuit/utilization/resources/resource/state/used-threshold-upper
/components/component/integrated_circuit/utilization/resources/resource/state/used-threshold-upper-clear

Pull Request Functional Test Report for #3156 / f3f424348999afa2e415b66df070f6703bedd1db
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test
b0bc1a68
Log

Cisco 8000E

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test
4503d105
Log

Cisco XRd

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test
c1181a29
Log

Juniper ncPTX

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test
99caf491
Log

Nokia SR Linux

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test
3b6493be
Log

Openconfig Lemming

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test
c765fec5
Log

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test

Cisco 8808

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test

Juniper PTX10008

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test

Nokia 7250 IXR-10e

gNMI-1.21: Integrated Circuit Hardware Resource Utilization Test

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls


Improve error when function overload set incorrectly authored

Users do not realize that implementation signatures of overload sets do not count as an actual signature at call sites. Attempting to call their overloaded function then results in a surprising error and off they go to StackOverflow to ask a question or here to file a bug. This comes up fairly often (most recently with https://github.com/Microsoft/TypeScript/issues/4786).
Can we improve the error by checking the type at the callsite against the implementation signature if no other signatures are applicable? Ex:
class EventAggregator
{
    publish(event: string, data?: any): void;
    publish<T>(event: T): void {}
}

var ea: EventAggregator;
ea.publish([1,2,3]);

Today the last line is an error: "number[] is not assignable to string." To many this just looks like the compiler for some reason chose the wrong overload, now what?
In this case after seeing array is not assignable to any overload signatures we could check whether it is assignable to the implementation signature. If it is, we could issue a potentially more helpful error mentioning this rule (implementation signatures are not considered overload signatures) and a potential fix.

Not suggesting that I want it now, but I especially like the kind of errors that include a link to an online page with more details on the error code, examples of when this error may happen and possible solutions. Makes everybody's lives easier. Also not suggesting that GitHub wikis are perfect for that! ;)

@danquirk what is the proposed new error message?

Maybe:
An applicable signature exists on the implementation. Consider declaring that signature as an overload.

That's a pretty good start. Really depends on how verbose/casual we want to be. Even the concept of implementation signature vs overload signature is not necessarily obvious to people coming from certain other languages. A squiggle/line number reference to the implementation signature could help. This would also be a good case for a Lightbulb/QuickFix type thing that C# currently does.

For me @mhegazy's two point hint was very useful:

method definition is not counted as part of the overload set. you need to 1. define an overload signature of each overload, and 2. have an implementation signature that is compatible with all the overloads.

The error we get today is:

Overload signature is not compatible with function implementation.

so we want to say something about the implementation signature is not part of the overloads, in additional to it being compatible.
so may be something like:

Overload signature is not compatible with function implementation. Implementation signatures are not part of the overloads, but has to be compatible with all other overloads.

I think the distinction of implementation signature vs overload signature still isn't necessarily obvious to people. Perhaps if we mention the type (ex 'with implementation signature of type T -> void') that would help clue people in to precisely what we mean.

not sure i understand what you mean, which type?

@mhegazy the type of the call signature implied by the implementation.

so something like
{ <T>(event: T): void; } not assignable to {(event: string, data?: any): void; }

Right, because the distinction between implementation signature and overload signature is not a concept that's familiar coming from many other languages (which is why people keep messing this up). So it would be useful to include some other clue as to what we mean when we say implementation signature whether it's the type of the implementation signature or the line number.
So combining some of the conversation, imagine:
number[] is not assignable to string. An applicable call signature does exist on the implementation signature with type { (event: T): void; }. However, implementation signatures are not part of the available function overloads. Consider declaring an additional function overload signature with that type.
Note this is far more verbose than we usually are and somewhat more colloquial but I think that style is for the best (relevant: http://elm-lang.org/blog/compiler-errors-for-humans)

I think the implementation signature should not be called function overload at all if it does not end up in the definition file. I think Mohamed's wording is more clear here "method definition is not counted as part of the overload set" so the implementation signature or function definition shouldn't be called an overload.

Changed the effort tag because you really do need to understand where to plug things in in overload resolution.


Updated type of has_exiftool to ternary

#409 has been fixed by #411 by whitelisting sanity checks for getting config values (setting still caused an error). This PR now removed again the whitelisting and introduces a proper solution changing type of has_exiftool to ternary (0,1,2).
The config variable has_exiftool was implemented as a bool and null was used in cases, test for exiftool has not yet been performed. This causes issues during sanity checks (getting config values and setting config values).
Solution: Move to ternary with the following values:
0 = Exiftool not available
1 = Exiftool is available
2 = Not yet tested

Codecov Report

Merging #415 into master will increase coverage by 0.38%.
The diff coverage is 50%.

Added two more fixes.
@ildyria please have a second look and merge if you're okay.


Crash when switching to Mesh Viewer after opening an Android capture

Description
Looks like accessing corrupted memory.
Exception thrown: Access violation reading location 0x00000000ABCDDCC8.
Here's the callstack when opening the capture with local context:

renderdoc.dll!WGLPlatform::SwapBuffers(GLWindowingData context) Line 87	C++
renderdoc.dll!GLReplay::SwapBuffers(GLWindowingData * ctx) Line 3345	C++
renderdoc.dll!GLReplay::FlipOutputWindow(unsigned __int64 id) Line 211	C++
renderdoc.dll!ReplayOutput::Display() Line 659	C++
qrenderdoc.exe!CustomPaintWidget::paintEvent::__l7::(IReplayController * r) Line 94	C++
[External Code]
qrenderdoc.exe!ReplayManager::run(int proxyRenderer, const QString & capturefile, std::function<void __cdecl(float)> progress) Line 480	C++
qrenderdoc.exe!ReplayManager::OpenCapture::__l2::() Line 55	C++

And a different callstack when using remote context on an android device:

renderdoc.dll!WrappedIDXGISwapChain4::Present(unsigned int SyncInterval, unsigned int Flags) Line 542	C++
renderdoc.dll!D3D11Replay::FlipOutputWindow(unsigned __int64 id) Line 411	C++
renderdoc.dll!ReplayProxy::FlipOutputWindow(unsigned __int64 id) Line 233	C++
renderdoc.dll!ReplayOutput::Display() Line 659	C++
qrenderdoc.exe!CustomPaintWidget::paintEvent::__l7::(IReplayController * r) Line 94	C++
[External Code]
qrenderdoc.exe!ReplayManager::run(int proxyRenderer, const QString & capturefile, std::function<void __cdecl(float)> progress) Line 480	C++
qrenderdoc.exe!ReplayManager::OpenCapture::__l2::() Line 55	C++

Repro steps
Local context:

Open this capture file:
android_capture.zip
Select local context
Switch to Mesh Viewer tab
Observe crash (100% repro rate)

Remote context:

Connect an android device
Open this capture file:
android_capture.zip
Select remote context and connect to android device
Switch to Mesh Viewer tab
Observe crash (100% repro rate)

Environment

RenderDoc build: Develop x64 custom (Master branch ea12625193abdbb91e3e9550239e1088530c7c93)
Android APK: from 2019-06-26 nightly build
Note: also reproduced on stable v1.4

Operating System: Windows 10

API: OpenGL ES

Android device: Samsung Galaxy s6

Can you enable Show External Code in Visual Studio and double check that the callstacks are definitely complete? This looks a lot like a driver crash I've seen recently but you're missing the stack frames in the external DLLs (because VS has 'helpfully' hidden it).
It seems more likely than a bug in both the GL window presentation and D3D11 presentation code, since in both locations it's calling into the system not doing any work inside RenderDoc.

I've enabled external code and here's the full callstack for the local one:
igd10iumd64.dll!00007ffa1cdb21e1()	Unknown
d3d11.dll!00007ffa3d4634d3()	Unknown
dxgi.dll!00007ffa3f512b3f()	Unknown
dxgi.dll!00007ffa3f4e84de()	Unknown
dxgi.dll!00007ffa3f4c9b56()	Unknown
dxgi.dll!00007ffa3f4b49df()	Unknown
nvoglv64.dll!0000000065ea8948()	Unknown
nvoglv64.dll!0000000065ed2eb1()	Unknown
nvoglv64.dll!0000000065eb3c15()	Unknown
nvoglv64.dll!0000000065ed43d3()	Unknown
nvoglv64.dll!0000000065fc203d()	Unknown
nvoglv64.dll!0000000065fcd6cf()	Unknown
nvoglv64.dll!0000000065fe2543()	Unknown
nvoglv64.dll!0000000065e7801e()	Unknown
nvoglv64.dll!0000000065fa4442()	Unknown
nvoglv64.dll!0000000065f842bd()	Unknown
nvoglv64.dll!0000000065f83b87()	Unknown
nvoglv64.dll!0000000065e89266()	Unknown
nvoglv64.dll!0000000065e893d5()	Unknown
nvoglv64.dll!0000000065e891be()	Unknown
nvoglv64.dll!0000000065e88cb6()	Unknown
nvoglv64.dll!0000000065e71fec()	Unknown
opengl32.dll!00007ffa23822e9b()	Unknown
gdi32full.dll!00007ffa40ae4e0e()	Unknown
    renderdoc.dll!WGLPlatform::SwapBuffers(GLWindowingData context) Line 87	C++
renderdoc.dll!GLReplay::SwapBuffers(GLWindowingData * ctx) Line 3345	C++
renderdoc.dll!GLReplay::FlipOutputWindow(unsigned __int64 id) Line 211	C++
renderdoc.dll!ReplayOutput::Display() Line 659	C++
qrenderdoc.exe!CustomPaintWidget::paintEvent::__l7::<lambda>(IReplayController * r) Line 94	C++
qrenderdoc.exe!std::_Invoker_functor::_Call<void <lambda>(IReplayController *) &,IReplayController *>(CustomPaintWidget::paintEvent::__l7::void <lambda>(IReplayController *) & _Obj, IReplayController * && <_Args_0>)	C++
qrenderdoc.exe!std::invoke<void <lambda>(IReplayController *) &,IReplayController *>(CustomPaintWidget::paintEvent::__l7::void <lambda>(IReplayController *) & _Obj, IReplayController * && <_Args_0>)	C++
qrenderdoc.exe!std::_Invoker_ret<void,1>::_Call<void <lambda>(IReplayController *) &,IReplayController *>(CustomPaintWidget::paintEvent::__l7::void <lambda>(IReplayController *) & <_Vals_0>, IReplayController * && <_Vals_1>)	C++
qrenderdoc.exe!std::_Func_impl_no_alloc<void <lambda>(IReplayController *),void,IReplayController *>::_Do_call(IReplayController * && <_Args_0>)	C++
qrenderdoc.exe!std::_Func_class<void,IReplayController *>::operator()(IReplayController * <_Args_0>)	C++
qrenderdoc.exe!ReplayManager::run(int proxyRenderer, const QString & capturefile, std::function<void __cdecl(float)> progress) Line 480	C++
qrenderdoc.exe!ReplayManager::OpenCapture::__l2::<lambda>() Line 55	C++
qrenderdoc.exe!std::_Invoker_functor::_Call<void <lambda>(void) &>(ReplayManager::OpenCapture::__l2::void <lambda>(void) & _Obj)	C++
qrenderdoc.exe!std::invoke<void <lambda>(void) &>(ReplayManager::OpenCapture::__l2::void <lambda>(void) & _Obj)	C++
qrenderdoc.exe!std::_Invoker_ret<void,1>::_Call<void <lambda>(void) &>(ReplayManager::OpenCapture::__l2::void <lambda>(void) & <_Vals_0>)	C++
qrenderdoc.exe!std::_Func_impl_no_alloc<void <lambda>(void),void>::_Do_call()	C++
qrenderdoc.exe!std::_Func_class<void>::operator()()	C++
qrenderdoc.exe!LambdaThread::process() Line 281	C++
qrenderdoc.exe!QtPrivate::FunctorCall<QtPrivate::IndexesList<>,QtPrivate::List<>,void,void (__cdecl LambdaThread::*)(void)>::call(void(LambdaThread::*)() f, LambdaThread * o, void * * arg) Line 136	C++
qrenderdoc.exe!QtPrivate::FunctionPointer<void (__cdecl LambdaThread::*)(void)>::call<QtPrivate::List<>,void>(void(LambdaThread::*)() f, LambdaThread * o, void * * arg) Line 170	C++
qrenderdoc.exe!QtPrivate::QSlotObject<void (__cdecl LambdaThread::*)(void),QtPrivate::List<>,void>::impl(int which, QtPrivate::QSlotObjectBase * this_, QObject * r, void * * a, bool * ret) Line 121	C++
Qt5Core.dll!0000000067e850e1()	Unknown
Qt5Core.dll!0000000067cd1f2f()	Unknown
Qt5Core.dll!0000000067cd6cd1()	Unknown
kernel32.dll!00007ffa422f7974()	Unknown
ntdll.dll!00007ffa4479a271()	Unknown

Let me know if there's anything I can investigate to help you.

Yes I'm almost certain this is the driver bug I've been seeing. If you resolve symbols for d3d11.dll and dxgi.dll I expect you'll see something like this (this callstack is from a D3D11 crash so it's slightly different as it doesn't have stack frames going through nvidia's driver):
 	igd10iumd64.dll!00007ff8ec0d1f41()
>	d3d11.dll!NDXGI::CDevice::WaitForFence()
 	dxgi.dll!CDXGISwapChain::PrepareWindowedBltCrossAdapterSurface(void)
 	dxgi.dll!CDXGISwapChain::PresentImplCore(...)
 	dxgi.dll!CDXGISwapChain::PresentImpl()
 	dxgi.dll!CDXGISwapChain::Present()

The solution is to update your Intel graphics drivers, as older drivers seem to have a bug that causes crashes with this cross-device present from the nvidia GPU. It's unfortunately not a bug that can be fixed or worked around from RenderDoc's side.

Thanks! I can confirm it's fixed after updating Intel graphics drivers.


Discussion: consider reverting block.number opcode to its previous behavior

OVM 2.0 introduced many breaking changes, most of which were meant and did improve EVM equivalence for Optimistic networks, however, there was an objective, major regression introduced with the new block.number opcode behavior.
Quoting from the changeset docs page:

NUMBER - block.number in L2 will now correspond to the L2 block number, not “Last finalized L1 block number” like it used to. Any project currently using block.number must check that this will not break their implementation. The L1 Block number will be made accessible via a new predeployed contract.

First of all, it is helpful to understand the team rationale for this particular change, and luckily we have it from the team:

This is a very superficial, and simplicistic reasoning that actually goes against EVM equivalence, and does so by ignoring the fact that the value of L1 block numbers is absolutely vital to so many contracts that depend on native access to a reliable time progression measure, and very different from the value of the L2 "block numbers", which is just a txs index whose rate of growth swings wildly based on the amount of traffic that the sequencer receives over time.
I cannot fathom being the only developer trying to build on the OVM that sees this as a colossal blocking issue, and a completely self-inflicted wound for EVM-equivalence.
First of all, this is a clear regression that should never have made it out of the drawing board, however, I think this issue carries such a high severity that should be rolled back in an emergency regenesis, before the scheduled updates in Q1 2022.
Possible solutions that were discussed in the Discord with some team members were:

the rollback of the block.number to its previous, L1-equivalent behavior, along with the introduction of a separate opcode to query the latest L2 transactions index like txs.index or l2.block.number or l2block.number

I have been trying to fallback on the official supported method to query the latest L1 block number, which is (the docs didn't even mention this) the special and unverified contract deployed at: 0x4200000000000000000000000000000000000013 that can be queried with getL1BlockNumber().
Furthermore, instead of assurances about the future-proof nature of this special contract, I heard quite the opposite from the eng team, saying that it is likely to be changed again in the future.
Needless to say, this requires mantaining a different codebase for the OVM 2.0, not to mention the incompatibilities in test suites and deployment operations with tooling such as Hardhat VM forking and block advancement features.

Transferring over to optimistic-specs where this will get more visibility. Current specified behavior for the Optimism Bedrock release is that blocks will be produced at a rate of 1 block every 2 seconds. Hopefully that solves this problem for the most part. L1 block number (and other L1 block content) will be accessible on L2.

Current plan is indeed fixed block time of 2s. Anything that relies on block being spaced ~13s apart will not work, some notes:

Eth2 will make the block time 12s so introducing a lot of skew if assuming a 13s block time over longer period
TIMESTAMP should be used anyway — in theory, it can be manipulated by L1 miners, though not for long before a difficulty increase kicks in under PoW. I think this becomes impossible in Eth2 (given the slots, I would assume that timestamps become fixed to multiple of 12s, not entirely sure though).
Making BLOCKNUMBER return the L1 block height would break another assumption that contracts can make on L1, which is that there is a 1:1 mapping between blocknumber and blokhash. And pretty sure if we dig, there are other breaking assumptions.

Imho, no chance for this to happen so I'm in favour of closing this issue.


Market trading page notice modal

for markets after the cut off get rid of the market review confirm modal and add this new market notice modal

Looks good, let's just update the time to show seconds:
11:59:59 PM


ENH: Parallelize CSR (sparse matrix) methods

Apologies for the wall of text, I want to provide context and reasoning for the changes made here.
Most CSR sparse matrix operations have an outer loop that iterates over the matrix rows. Often each iteration of this loop is, or can easily be made to be, independent. This PR parallelizes this loop.
PR is fully implemented and working, but has some product-level questions remaining. See the tradeoffs section below. I'll update the PR to remove code for the rejected options.
Choice of parallelism framework
OpenMP is explicitly off the table as per docs, so no omp parallel for. Common libraries like TBB or Taskflow seem too heavy for just this one application, correct me if I'm wrong. That leaves simple threads or a thread pool.
I chose to use the interface of the C++17 parallel algorithms to make the code future-proof and easy to understand for C++ programmers. I say interface because compiler support for those algorithms is not all there at the moment. Instead, I implemented the required algorithms on top of a thread pool using C++11 threads. This is fairly small and works on all platforms. It seems useful enough to be its own product, so I released it as poolSTL.
Parallel matmul
Only method that requires signature changes.
The core SMMP algorithm has two embarrassingly parallel phases. Phase 1 calculates the size of the result matrix then phase 2 fills it in.
The signature change is to the phase 1 implementation, csr_matmat_maxnnz(). Previously this method only calculated the result's nnz. A parallel phase 2 requires a pre-computed indptr (Cp), so the change is to have csr_matmat_maxnnz() return the row sizes as it computes the nnz. A cumsum of the row sizes is Cp. This is done in Python to handle the (rare) case where the output matrix has enough non-zeros to overflow the input matrices' index type.
A small logic change is also required. The previous code would only count computed values, regardless whether those values are zero or not. Over-allocation is ok. The parallel code cannot do that as phase 2 is not allowed to emit explicit zeros. Therefore, phase 1 must also compute the values to test against zero to return an accurate nnz.
Unfortunately this is extra work. Quick benchmarks suggest the single-threaded code is about 20-30% slower, but this is easily made up for in parallel.
Parallel binop
I only parallelized the canonical version.
Binop faces the same problem as matmul: the size and sparsity pattern of the output is needed for parallelism, but it's unknown. The sequential code would allocate for the worst case, then just construct the result. The parallel code uses matmul's approach: Phase 1 computes Cp in parallel, then phase 2 fills in the column indices and data in parallel. The sequential case remains the same single pass as before.
One weird observation I can't fully explain is that the sequential case now appears to be significantly faster than before, like often 2x. The only change I can identify is that the new code breaks some accidental inter-loop data dependencies, but that doesn't seem like it should be enough for the performance boost. Happy to be corrected.
Parallel Other methods
Most obvious beneficiary is csr_sort_indices. Used everywhere and parallelizes very well. I also added an optimization to remove a temporary copy for the sort.
Other embarrassingly parallel methods just replace their outer for loops with parallel std::for_each. Some methods that check the format instead use std::all_of.
Parallelism control
Note: methods stay sequential unless the matrix is fairly large, current definition of "large" is 64k non-zeros. This may seem overly large, but sequential ops are fast. pnumpy also uses this threshold.
Parallelism is controlled with threadpoolctl:
with threadpoolctl.threadpool_limits(limits=4):
    res = matrix1 @ matrix2

PR default is single threaded. One must use the code above to enable parallelism.
Benchmarks
The standard scipy benchmarks are too small to really exercise this PR. On my machine few take longer than a millisecond. I have a branch with much bigger versions of the standard benchmarks: https://github.com/scipy/scipy/commit/6b78eacb75408faa2bacb0b4c29e949af6362822
If folks could try on their own benchmarks or their own workflows that would be very helpful.
Tests
I configured the tests to run twice: once sequentially and once with parallelism forced on even for tiny problems. Happy to change this if it's excessive.
Product level decisions and tradeoffs
Is the worker count API ok?
Is threadpoolctl enough?
Other parallel SciPy C++ codes (fft, optimize) use explicit worker arguments. That would be difficult here as none of these methods are called directly by the user, and many are operators.
Any other (or additional) options?
Thread pool vs Dedicated threads
A common thread pool started on first use of a large op (Pros: threads are reused) vs starting and joining dedicated threads for each op (Pros: smaller library size, no idle worker threads left behind).
Controlled by USE_POOL constant in scipy/sparse/sparsetools/util_par.h.
What ops to parallelize
Library size is the main downside of this PR. Note that all the methods in csr.h are templates with quite a few instantiations each. The dedicated threads create about one more symbol for each method, while the thread pool requires several more (due to wrappers, vtables, etc). I've already more than halved the .so size from my first attempts, would appreciate further ideas from folks with stronger nm skills than mine. Also, I understand that the final release build does some symbol stripping so the following may be an exaggeration.
To further control library size this PR includes two more switches in util_par.h:

PARALLEL_BINOP whether to parallelize binops.
PARALLEL_OTHERS whether to parallelize methods other than matmul, sort_elements, binop. Currently off.

It should also be possible to parallelize just some binops (like plus, minus) and save library size on the others.
For context, rough sizes of _sparsetools.cpython-310-darwin.so as built by python dev.py build on my machine:

main branch: 4.0 MB
USE_POOL=0/PARALLEL_BINOP=0 : 4.8 MB
USE_POOL=0/PARALLEL_BINOP=1 : 8.0 MB
USE_POOL=1/PARALLEL_BINOP=0 : 5.4 MB
USE_POOL=1/PARALLEL_BINOP=1 : 13 MB

If the choice is to go dedicated threads (no pool) then we can rip just those methods from poolSTL and drop that file entirely. The pure threads functions are <100 lines total.

Benchmarks
I'm attaching the ASV benchmark compare of this PR against the main branch using the bigger benchmarks I mentioned ( https://github.com/scipy/scipy/commit/6b78eacb75408faa2bacb0b4c29e949af6362822 )
Running on M1 Macbook pro (6 + 2 cores)
All are single repetition because I couldn't get ASV to do repeats, hence noisy (ignore the noisy ~1ms runs). But the pattern is clear, the bigger benchmarks are significantly faster.
Random matrix multiply:
| Change   | Before [6b78eacb] <bigbench>   | After [a9acb88f] <parallel_csr>   |   Ratio | Benchmark (Parameter)                             |
|----------|--------------------------------|-----------------------------------|---------|---------------------------------------------------|
| +        | 1.03±0ms                       | 2.62±0ms                          |    2.55 | sparse.MatmulLargeCSRRand.time_large('10K,1M')    |
| +        | 132±0μs                        | 174±0μs                           |    1.33 | sparse.MatmulLargeCSRRand.time_large('1K,1K')     |
| -        | 1.90±0ms                       | 1.31±0ms                          |    0.69 | sparse.MatmulLargeCSRRand.time_large('100K,100K') |
| -        | 4.29±0ms                       | 1.92±0ms                          |    0.45 | sparse.MatmulLargeCSRRand.time_large('1M,10K')    |
| -        | 57.2±0ms                       | 25.5±0ms                          |    0.45 | sparse.MatmulLargeCSRRand.time_large('1M,1M')     |
| -        | 310±0ms                        | 87.7±0ms                          |    0.28 | sparse.MatmulLargeCSRRand.time_large('10M,1M')    |
| -        | 3.28±0s                        | 824±0ms                           |    0.25 | sparse.MatmulLargeCSRRand.time_large('10M,10M')   |
| -        | 6.23±0s                        | 1.50±0s                           |    0.24 | sparse.MatmulLargeCSRRand.time_large('15M,15M')   |

Sort elements:
| Change   | Before [6b78eacb] <bigbench>   | After [a9acb88f] <parallel_csr>   |   Ratio | Benchmark (Parameter)             |
|----------|--------------------------------|-----------------------------------|---------|-----------------------------------|
| +        | 799±0μs                        | 953±0μs                           |    1.19 | sparse.Sort.time_sort('Rand10')   |
| -        | 767±0μs                        | 283±0μs                           |    0.37 | sparse.Sort.time_sort('Rand25')   |
| -        | 1.45±0ms                       | 404±0μs                           |    0.28 | sparse.Sort.time_sort('Rand50')   |
| -        | 3.14±0ms                       | 805±0μs                           |    0.26 | sparse.Sort.time_sort('Rand100')  |
| -        | 50.0±0ms                       | 12.4±0ms                          |    0.25 | sparse.Sort.time_sort('Rand2000') |
| -        | 5.67±0ms                       | 1.29±0ms                          |    0.23 | sparse.Sort.time_sort('Rand200')  |
| -        | 26.4±0ms                       | 4.94±0ms                          |    0.19 | sparse.Sort.time_sort('Rand1000') |

Large arithmetic ops:
| Change   | Before [6b78eacb] <bigbench>   | After [a9acb88f] <parallel_csr>   |   Ratio | Benchmark (Parameter)                                                   |
|----------|--------------------------------|-----------------------------------|---------|-------------------------------------------------------------------------|

*truncated for size, see Arithmetic.txt below*

| -        | 176±0ms                        | 91.6±0ms                          |    0.52 | sparse.Arithmetic.time_arithmetic('csr', 'AB', 1000, True, '__mul__')   |
| -        | 3.46±0ms                       | 1.81±0ms                          |    0.52 | sparse.Arithmetic.time_arithmetic('csr', 'BB', 250, False, '__sub__')   |
| -        | 11.0±0ms                       | 5.47±0ms                          |    0.5  | sparse.Arithmetic.time_arithmetic('csr', 'BA', 250, False, '__mul__')   |
| -        | 5.67±0ms                       | 2.73±0ms                          |    0.48 | sparse.Arithmetic.time_arithmetic('csr', 'AA', 250, True, '__mul__')    |
| -        | 55.2±0ms                       | 26.4±0ms                          |    0.48 | sparse.Arithmetic.time_arithmetic('csr', 'BB', 1000, False, '__sub__')  |
| -        | 3.53±0ms                       | 1.65±0ms                          |    0.47 | sparse.Arithmetic.time_arithmetic('dia', 'BB', 250, False, '__sub__')   |
| -        | 3.62±0ms                       | 1.67±0ms                          |    0.46 | sparse.Arithmetic.time_arithmetic('coo', 'BB', 250, False, '__sub__')   |
| -        | 91.8±0ms                       | 39.4±0ms                          |    0.43 | sparse.Arithmetic.time_arithmetic('csr', 'AA', 1000, False, '__mul__')  |
| -        | 23.6±0ms                       | 10.0±0ms                          |    0.43 | sparse.Arithmetic.time_arithmetic('dia', 'BB', 250, False, '__mul__')   |
| -        | 92.0±0ms                       | 37.7±0ms                          |    0.41 | sparse.Arithmetic.time_arithmetic('csr', 'AA', 1000, True, '__mul__')   |
| -        | 190±0ms                        | 74.5±0ms                          |    0.39 | sparse.Arithmetic.time_arithmetic('csr', 'AB', 1000, False, '__mul__')  |
| -        | 211±0ms                        | 82.1±0ms                          |    0.39 | sparse.Arithmetic.time_arithmetic('csr', 'BA', 1000, False, '__mul__')  |
| -        | 22.9±0ms                       | 8.94±0ms                          |    0.39 | sparse.Arithmetic.time_arithmetic('csr', 'BB', 250, False, '__mul__')   |
| -        | 208±0ms                        | 78.6±0ms                          |    0.38 | sparse.Arithmetic.time_arithmetic('csr', 'BA', 1000, True, '__mul__')   |
| -        | 23.5±0ms                       | 8.05±0ms                          |    0.34 | sparse.Arithmetic.time_arithmetic('coo', 'BB', 250, True, '__mul__')    |
| -        | 23.6±0ms                       | 8.13±0ms                          |    0.34 | sparse.Arithmetic.time_arithmetic('dia', 'BB', 250, True, '__mul__')    |
| -        | 23.2±0ms                       | 7.65±0ms                          |    0.33 | sparse.Arithmetic.time_arithmetic('coo', 'BB', 250, False, '__mul__')   |
| -        | 23.5±0ms                       | 7.71±0ms                          |    0.33 | sparse.Arithmetic.time_arithmetic('csr', 'BB', 250, True, '__mul__')    |
| -        | 401±0ms                        | 123±0ms                           |    0.31 | sparse.Arithmetic.time_arithmetic('csr', 'BB', 1000, True, '__mul__')   |
| -        | 395±0ms                        | 117±0ms                           |    0.3  | sparse.Arithmetic.time_arithmetic('csr', 'BB', 1000, False, '__mul__')  |

Raw output from python dev.py bench --compare:
compare-sparse.Arithmetic.txt
compare-sparse.Conversion.txt
compare-sparse.MatmulLargeCSRPoissonSquared.txt
compare-sparse.MatmulLargeCSRRand.txt
compare-sparse.Matvec.txt
compare-sparse.NullSlice.time_getcol.txt
compare-sparse.Random.txt
compare-sparse.Sort.txt
compare-sparse_linalg_expm.Expm.txt
compare-sparse_linalg_solve.Bench.time_solve.txt
compare-sparse_matrix_power.txt

CI errors seem to be scipy/optimize/tests/test_linprog.py::TestLinprogIPSparse::test_bug_6139. That test passes for me locally, and I can't figure out how it relates to this change.  Any insight appreciated!

Thanks @alugowski, this looks very interesting! The first question that came to mind for me regarding benchmarks/performance is how linear the scaling is with the requested number of threads. E.g., use an array of size 64k x 32, and plot time taken by parallelized operations as a function of the number of threads. The closer to linear the scaling the better. Did you try anything like that already?

CI errors seem to be scipy/optimize/tests/test_linprog.py::TestLinprogIPSparse::test_bug_6139. That test passes for me locally, and I can't figure out how it relates to this change. Any insight appreciated!

I can't reproduce it either, but from the CI log it looks to me like the solution only slightly exceeds the requested atol=1e-8, so this is unlikely to be a significant issue, more a minor tolerance thing for an inherently unstable test.
The CircleCI job shows a build error in csr.cxx, that seems more important to sort out.

Re API for parallelism: your use of threadpoolctl sounds like a good idea to me, and is probably enough - given your explanation of why workers isn't a great fit here, I'm not sure what else would help. Perhaps a global switch to switch between single-threaded and completely automatic using all available CPU tools, but that's a pretty blunt tool and we try to avoid global state.
I don't have immediate ideas for further operations, probably best to complete the work on this first (or at least till we have a strategy for getting this merged).

I'll write some code for a speedup benchmark.

The CircleCI job shows a build error in csr.cxx, that seems more important to sort out.

That'll take some thought, there is no error just "killed". My only guess is a compile unit size issue, which relates to:

I don't have immediate ideas for further operations, probably best to complete the work on this first (or at least till we have a strategy for getting this merged).

I need to clarify. I agree further non-CSR ops would be worth discussing later. I meant that we may have to make a decision on what to turn off in this PR for library size issues. Hence why I have those three groups:

always on: matmul and sort_elements. Relatively small compilation penalty and a large bang for the buck.
binops: There are many of these, hence parallelizing these nearly doubles _sparsetools.so size. On in the PR.
others: all the other embarrassingly parallel ops in csr.h, like to_dense, scale_columns, etc. The PR has parallel code for these, but is turned off in the PR as is only for library size reasons.

I'm hoping someone has some ideas on how to not blow up the library size. My best guess is that having both the parallel and sequential code paths doubles the generated code size, but it's unclear why that would be as both call the same lambdas. Perhaps the compiler inlines too much.

Speedup of tocsr(mostly sort_elements), two binops and a matmul on a random matrix with 5M nonzeros:

Of course the sparsity pattern matters a lot with any sparse matrix op. A Poisson 2D grid is often a difficult one. Here:

Part of the reason for worse speedup is that the ops in general are significantly faster. The random matmul takes 9.8s, while the Poisson 2d matmul takes only 0.13s.
 In those plots I re-enabled the parallel versions of the "is_canonical" method, without that the speedup barely touches 1.5x at these sizes. That's still a nice speedup, but is it worth it?
Note that parallel binops start to shine at much larger sizes:

Hence the difficult tradeoff decision. Is the extra complexity worth it for only large matrices? I think if only plus/minus were parallelized that might be ok, but I'd also be happy with sequential binops.
Attaching the script I used. Command for first plot:
 python dev.py python speedup.py 5_000_000 random plot tocsr add mul matmul
speedup.py.txt

I noticed the comment for M1 and thought it could cause some of the levelling off; I believe M1's always have 4 efficiency cores, not 2. However, I repeated the benchmarks on a machine with 12 physical cores and it doesn't look better:

This is with the default build settings in this PR. Something is wrong here though, these curves should be much closer to linear. A square root type leveling off indicates that there's communication overhead between threads where that is not expected (elementwise ops are the worst here, and they shouldn't have cross-thread data passing), or maybe the data chunk size is chosen too small, or something else like that. It may be worth profiling with something like py-spy to figure out what is going on. If we have C++-level threading without callbacks to Python, I think we should only offer a parallel API with expected (more-or-less linear) scaling up to a reasonable number of threads (e.g., 64).

OpenMP is explicitly off the table as per docs, so no omp parallel for. Common libraries like TBB or Taskflow seem too heavy for just this one application, correct me if I'm wrong. That leaves simple threads or a thread pool.

Yes, we're not ready to revisit OpenMP I'm afraid. And yes, TBB & co are a bit too heavy for us.

I noticed the comment for M1 and thought it could cause some of the levelling off; I believe M1's always have 4 efficiency cores, not 2.

Mine is 6 power + 2 efficiency.

However, I repeated the benchmarks on a machine with 12 physical cores and it doesn't look better:

This is with the default build settings in this PR. Something is wrong here though, these curves should be much closer to linear. A square root type leveling off indicates that there's communication overhead between threads where that is not expected (elementwise ops are the worst here, and they shouldn't have cross-thread data passing), or maybe the data chunk size is chosen too small, or something else like that. It may be worth profiling with something like py-spy to figure out what is going on. If we have C++-level threading without callbacks to Python, I think we should only offer a parallel API with expected (more-or-less linear) scaling up to a reasonable number of threads (e.g., 64).

It's simpler than that. The binop is largely a memory scan, so it's dominated by memory bandwidth. One way to show that is to make the base operation more compute intensive so memory no longer dominates. To show that, in csr_elmul_csr() wrap the multiplies<T>() with expensive_op(std::multiplies<T>()):
template <class Op>
class expensive_op {
public:
    explicit expensive_op(Op op): op(op) {}
    using T = typename Op::result_type;

    T operator()(const T& a, const T& b) const {
        int n = (int)op(a, b);
        for (int i = 1; i < 500; ++i) {
            n = (i % 2) ? (3*n + 1) : (n / 2);
        }
        if (n == 0) return 0;
        return op(a, b);
    }

    Op op;
};

Now python dev.py python speedup.py 500_000 random plot add mul shows that the expensified mul does scale as expected:

The weird shape is because p>1 needs to do twice the work, hence no speedup for 2 threads then the slope of ~0.5 is expected. Without that p=1 optimization (add true || to the if to force the parallel path) the scaling is nearly perfect:

So my claim is that scaling is a natural property of the binop operation. The main improvements would be to only scale enough to not over subscribe memory bandwidth. To me it looks like my code works well on very large matrices, maybe 1M or larger. One option would be to limit the parallel version to that size. This code has no inter-thread communication at all (the 2 phases remove that need).
The other kink with binops is that the handler first checks both operands with csr_has_canonical_format (which is also just a memory-dependent scan). I've parallelized that op, but it's in the OTHERS group. I've enabled it in my previous comment, but it's disabled in the PR. Set PARALLEL_OTHERS to 1 in util_par.h to duplicate my plots.

Note about large p, like 32 or 64. Those sizes can uncover some non-obvious sequencing. A big one is allocators, the standard lib's allocator is thread safe but it can become a hotspot on large thread counts.  This PR creates as few splits as possible, which should suffer the least. Unfortunately any solutions (like arena allocators or other tricks) are in libraries like TBB.

I've implemented a way to parallelize only some binops, and enabled that for plus, minus, and multiply only. That reduces the compilation time and so I enabled the other parallel ops too. Library size is smaller than before and all ops are parallel.
I also tweaked the parallelization thresholds a bit, now the memory-bound operations have to be larger to be parallelized, around 1M nonzeros. It should basically never be worse now. Sure 2x isn't amazing, but it's not nothing either. Either way, those single-scan methods are fairly fast in absolute terms anyway, so I wouldn't shed a tear if they were excluded.
I think this is generally a good tradeoff. You should no longer see any differences when you run the speedup script. I also added a matvec bench to the script:

Just for context and a sanity check, I've also added a random2d matrix type that creates an ndarray, to see how BLAS scales:

(OpenBLAS on macOS, default from numpy 1.26.2 wheels)
Makes me feel a little better :)
speedup.py.txt

I know I'm a broken record about library size, but even on the main branch binops account for half of _sparsetools.so size (~2MB worth), and about 5% of overall python dev.py build runtime. These things are important so I'm trying to be upfront about it.

I've simplified the PR based on feedback:

Parallelize only matmul, sort_elements, and matvec. These have obvious payoff.
No parallel binops. See #19765 for a sequential binop optimization.
Pure threads only, no thread pool

The parallelism utilities are broken down as:

util_par_algorithms.h: everything needed to parallelize any for loop. Just convert the loop to use std::for_each and use the provided threaded execution policy: std::for_each(util_par::threaded(4), ...)
util_par_config.h: configures the remembered worker count (set by threadpoolctl controller) and supplies a par_if method to decide between parallel and sequential based on datastructure size.

The PR looks big mostly because of the signature change in matmul that propagates through several layers. The "changes" in BSR are simply restoring the old pre-parallel CSR matmul_maxnnz that was reused by BSR.

Thanks for adding a lot of detail here @alugowski. Looks like you're right about the scaling and memory bandwidth indeed.

I've simplified the PR based on feedback:

These changes make sense I think, and should make it easier to get this merged since the wins are clearer without much of a downside (beyond a bit more code complexity of course).
Looks like there's a crash in _mul_sparse_matrix in the Windows job that builds sdist/wheel (so uses -O3, unlike the dev.py builds).

@alugowski one other question: did you consider fork-safety of the threadpool? The pocketfft threadpool implementation uses pthread_atfork shutdown/restart to handle this (hat tip to @peterbell10 for pointing this out).
To be more precise - this is needed because multiprocessing is doing fork without exec, after threads may already be created. This is the reason why we can't use OpenMP (xref gh-10239). More CPython's fault than OpenMP's probably (see https://github.com/python/cpython/issues/84559), but it is what it is so we need to be robust against this.

@alugowski one other question: did you consider fork-safety of the threadpool? The pocketfft threadpool implementation uses pthread_atfork shutdown/restart to handle this (hat tip to @peterbell10 for pointing this out).
To be more precise - this is needed because multiprocessing is doing fork without exec, after threads may already be created. This is the reason why we can't use OpenMP (xref gh-10239). More CPython's fault than OpenMP's probably (see python/cpython#84559), but it is what it is so we need to be robust against this.

Good question. There is no longer a thread pool, and no mutexes or other fork-unfriendly constructs. Since fork() only carries over the calling thread to the child, I believe there is nothing to handle.
The original PR had an optional thread pool, but had to be manually enabled with USE_POOL=1 else the default fork-join model was used. Not fork(), just starting/joining threads in each parallel function call. All the performance analytics we talked about above are with this model. I saw negligible performance benefits from the pool, just more code, so I removed that unused code about a week ago.
All threading logic is in this one function: https://github.com/scipy/scipy/blob/ff667f9d7b19618bf80d61ec377224cddc2610fc/scipy/sparse/sparsetools/util_par_algorithms.h#L51-L88

Looks like there's a crash in _mul_sparse_matrix in the Windows job that builds sdist/wheel (so uses -O3, unlike the dev.py builds).

The last two test fails were true headscratchers. Appologies it took so long to figure them out. The MSVC fail was caused by my use of std::exclusive_scan to compute Cp in csr_tocsc(), replacing a manual loop. I can't explain why this causes a crash there, but it's not a needed change so I just reverted it (made the PR slightly smaller, too).
The gcc8 workflow fail is even more weird. I spent a lot of time trying to figure out what's different about GCC 8, and why that one test which also didn't use any sparse methods at all. But the issue wasn't the compiler, but that pytest fixture in test_base.py. Again this makes no sense to me, since the tests are not related at all, test_base is run much later than the failing test, and solver success shouldn't be affected anyway. But moving the fixture solved the issue. I'm using a pytest fixture to run all tests both threaded and sequentially.
Now CircleCI is complaining about a missing doc_requirements.txt, which is something this PR does not touch.

Now CircleCI is complaining about a missing doc_requirements.txt, which is something this PR does not touch.

Merging main will fix this, the file was recently moved to requirements/doc.txt instead.

If C++ parallel has a wait policy, it could end up stalling when switching between different parallel contexts: https://github.com/OpenMathLib/OpenBLAS/issues/3187 and https://github.com/OpenMathLib/OpenBLAS/issues/3187#issuecomment-940999630
In the issue, the example switches between OpenBLAS and OpenMP parallel contexts and a threadpool's wait policy causes the program to slow down.

If C++ parallel has a wait policy, it could end up stalling when switching between different parallel contexts: OpenMathLib/OpenBLAS#3187 and OpenMathLib/OpenBLAS#3187 (comment)
In the issue, the example switches between OpenBLAS and OpenMP parallel contexts and a threadpool's wait policy causes the program to slow down.

The linked comment says the issue is that OpenMP uses active waiting in its own thread pool, meaning OpenMP worker threads spin waiting for work. This crowds out any other workloads. There's nothing to be done about that, besides using OpenMP yourself. The parallel code in this PR does not actively wait, and neither did the thread pool that was originally in the PR.


txn: remove the command_method abstraction

Signed-off-by: Zhenchi<EMAIL_ADDRESS>What problem does this PR solve?
Just a refactor.
Problem Summary:
The command_method macro makes less difference for human readability or simplicity.
What is changed and how it works?
What's Changed:

Remove command_method
Add property

Release note
None

PTAL @longfangsong

/merge


image_picker plugin can not get image's  origin file path

My function is that a picture can only be imported once，so I need to get the original file path  of the picture for comparison,but I found image_picker not support it.

This is a duplicate of https://github.com/flutter/flutter/issues/64685 / https://github.com/flutter/flutter/issues/54815. Please follow up on those issues for updates.
Thank you


Is this project dead?

I've been using this plugin for a while, now just got a Fibaro "The button" and an Aeotec wallmote. I then realized that they are obviously not supported through the homebridge-zway plugin and that this plugin hasn't been updated in 3 years.
So I assume it's dead? Are there any alternatives? How difficult is it to add new device categories? In the read-me it says that in the trunk there is already something prepared for buttons/remotes. How can I use that?

I don't consider it dead, but you might want to check out some forks which are more active or solve your issue: https://techgaun.github.io/active-forks/index.html#SphtKr/homebridge-zway

So, if not dead, why not merge in the fixes from all the other forks?
Also some devices that are mapped into homekit show up as “not supported” which doesn’t make sense. ( basic switches and outlets ).  I’d start debugging but it’s hard to tell what’s what with all the forks and updates.

Agree, but since I have no control over that I switched to https://github.com/palasinio/homebridge-zway Later on I switched over to the Zway HomeKit Gateway you can install as an app in Zway server.

Oh, mis-matched your handle with the owner.  I tried the Zway app, has the same problem -- devices showing up in Homekit as not supported.   Perhaps it's time for me to create a fork of forks...

Would be nice to have this project alive.
@b5rt  managed to add a device https://github.com/palasinio/homebridge-zway/commit/cd5d578bdb7196482d8e2ed8f5a4319935083094
I just merged the pending pull requests and updated dependencies.


STFT retquires return_complex = True

I am getting this error
RuntimeError: stft requires the return_complex parameter be given for real inputs, and will further require that return_complex=True in a future PyTorch release.
on running
train_losses, test_losses = train(dcunet20, train_loader, test_loader, loss_fn, optimizer, scheduler, 4)
this cell.
I am using pytorch on GPU which support CUDA-11.7

anf after i am specifying return_complex = True in torch.stft(........................ , return_complex = True)
i am getting new error
RuntimeError: Input type (struct c10::complex) and bias type (float) should be the same

I am able to run it completely in an env with py-3.8.18 and pytorch-1.10 with cuda-11.3
but It throws error with latest version of pytorch : )
How can i solve those??? I am stuck :)
Thank you.

Looks like by default stft in torch 1.10 has return_complex set to None, so the imaginary terms are stored separately. You probably need to use torch.view_as_real() as per the documentation to go from complex to real


Half the time the ProposalCreated event isn't being properly captured in real time

This may have gotten fixed in #112.

Yes, just tested and this is still an issue. I think it is due to trying to get user votes on a future block. I'm seeing this error in the browser:
Error: cannot estimate gas; transaction may fail or may require manual gas limit (error={"code":-32603,"message":"execution reverted: ERC20Votes: block not yet mined","data":{"originalError":{"code":3,"data":"0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000001f4552433230566f7465733a20626c6f636b206e6f7420796574206d696e656400","message":"execution reverted: ERC20Votes: block not yet mined"}}}

There are two functions in ERC20Votes that throw that error: getPastVotes and getPastTotalSupply. We're probably calling one or both of those prematurely?


Bluetooth: conn: Expose simplified connection state in get_info

Add a state field in struct bt_conn_info that is a simplified
version of the internal state value (bt_conn_state_t).
This should provide an application to better determine the state
of the connection whne calling bt_conn_get_info, in case the
application does not keep track of the state itself.
Signed-off-by: Emil Gydesen<EMAIL_ADDRESS>fixes https://github.com/zephyrproject-rtos/zephyr/issues/28009

@jhedberg Will you please re-review?


Idea: add component count selector in "component search" section

Nuff said - Price column is a mess :) https://github.com/Bouni/kicad-jlcpcb-tools/issues/382
I messed a bit with code, and wrote a simple PoC. I hardcoded element count to "30" for now:

Instead of hardcoding element count, an additional field could be added to the menu at the top, with target component count. Near it, a simple switch for toggling this feature should be present too.
As mentioned in linked issue, JLC API is not stable, so this feature should handle all parsing faults as gracefully as possible, and fallback to the default view on any error.
Another annoying issue I tried to deal here is "description" field, which is arguably even messier. I tried to highlight the searched phrase, to improve glance value when selecting component.
The scenario i'm trying to deal with: looking for "100n" component with "0402" package - when I'm obviously looking for a capacitor, I get "100nH 0402" choke listed.
This challenge however defeated me - I don't know if it's even possible to print bold text using wx component used here (and how portable such feature would be). For now i wrap keyword in ||double pipes||, but this doesn't really look useful at all.
Here's the snippet I made - obviously requiring a lot more sanitation before being prod-ready:

    self.populate_part_list(result, search_duration, self.keyword.GetValue())
    [...]

    def populate_part_list(self, parts, search_duration, keyword):
        """Populate the list with the result of the search."""

        target_count = 30
        search_duration_text = (
            f"{search_duration:.2f}s"
            if search_duration > 1
            else f"{search_duration * 1000.0:.0f}ms"
        )
        self.part_list.DeleteAllItems()
        if parts is None:
            return
        count = len(parts)
        if count >= 1000:
            self.result_count.SetLabel(
                f"{count} Results (limited) in {search_duration_text}"
            )
        else:
            self.result_count.SetLabel(f"{count} Results in {search_duration_text}")
        for p in parts:
            item = [str(c) for c in p]
            # Munge price to be more readable
            pricecol = 8 # Must match order in library.py search function
            descriptioncol = 7
            price = []
            try:
                for t in item[pricecol].split(","):
                    qty, p = t.split(":")

                    qty_low, qty_high = qty.split("-")

                    qty_low_f = float(qty_low)
                    try:
                        qty_high_f = float(qty_high)
                    except ValueError:
                        qty_high_f = float("inf")

                    if (target_count >= qty_low_f) and (target_count < qty_high_f):
                        p = float(p)
                        if p < 1.0:
                            price.append(f"{qty}: {p * 100:.2f}c")
                        else:
                            price.append(f"{qty}: ${p:.2f}")
                        self.logger.warning(f"${p:.2f}")

                    # if p < 1.0:
                    #     price.append(f"{qty}: {p * 100:.2f}c")
                    # else:
                    #     price.append(f"{qty}: ${p:.2f}")
                item[pricecol] = ", ".join(price)
            except ValueError:
                self.logger.warning("unable to parse price %s", item[pricecol])

            item[descriptioncol] = item[descriptioncol].replace(keyword, f"||{keyword}||")
            self.part_list.AppendItem(item)

Please tell me if it's something worth being merged-in, I could finish this and make an PR sometime in the future.
Bonus question - is it even remotely possible for kicad addon to utilize some other GUI-rendering framework?
You say you search for 100nF 0402 but your screenshot does not use the package field at all.
When I search 100nF and use the package field with 0402 I get quite sane results:

The first hit is even a basic part which is desirable in my opinion.
I have not looked into highlighting in wx listviews but its not easyly possible to hightlight a substring. maybe there's a rich text way but that means a lot of work ....
About the price thing, I kind of like your idea of having a way to define a quantity which the filters the price column and only shows the range that matches the quantity. Smart!
Bonus answer: It is, absolutely but there is now way you can install 3rd party python packages that work on all plattforms ...
I thought about building a webserverbase backend (flask, fastapi, ...) and use vuejs as a frontend, but spawning a browser window dows not work on all platfroms I guess. wx webviews a kind of stoneage, all state of the art UI frameworks need a modern JS engine.
QT is another option but is very heavy as a dependency, again, how to install that ....
 I spend a couple of hours trying to solve this, but the documentation is horrible, and the RTF stuff is probably windows-only.
100n search - yes, typing 100nF solve this specific case, but when you have to populate 30 different components, similar mistakes sometimes happen. The result is, you need 3x more attention in order not to make such mistakes. However, see point 1.
The price thing - I'll work on a PR for that, but can't promise I'll deliver until late august - so you can also do that (but please mention it under this issue beforehand, or anyone who'd like to do that, it's quite simple task if you know at least some python).

I'd add another submenu in the view seen on the screenshot, with amount of boards you're ordering, and toggle between all and filtered prices. In the main view, estimated total component price can be added as a bonus.

Alternative frontend - a lot of work required, but maybe jlc would be interested in sponsoring this work, did you ask them yet? Maybe they need a youtube video, so that their sponsorship can be mentioned :)

I'd explore a possibility of simply spawning a flask (or whatever) server, and opening the interface in browser. This would open a shitton of new possibilities! One can dream :)

Heh, even the JLC added the "highlight" feature now :)