Multidimensional Array in constructor

Hi,
I wonder if it's could be possible to initialize a NDArray with a multi dimensional array without using FromMultiDimArray method and by avoiding memory copy?
I thinking about maybe using a unmanaged pointer or something like that.
Right now, this is blocking us to adopt NumSharp because the initialization cost is too high.
Thanks

NDArray.FromMultiDimArray<T>(Array dotNetArray) uses np.array(...) internally but it seems to call the wrong overload.
Replace the NDArray.FromMultiDimArray<T>(Array dotNetArray) call with np.array(arr, copy: false).

Let me know if using np.array has fixed the problem for you.

Thanks for the quick answer  :)!
I will try it tomorrow and let you know if it's working.

np.array is actually slower than NDArray.FromMultiDimArray:
Stopwatch stopWatch1 = new Stopwatch();
Stopwatch stopWatch2 = new Stopwatch();
stopWatch1.Start();
NDArray data1 = np.array( inputData.Data as Array, false );
stopWatch1.Stop();
ElapsedMilliseconds: 81
stopWatch2.Start();
NDArray data2 = NDArray.FromMultiDimArray<Double>( inputData.Data as Array );
stopWatch2.Stop();
ElapsedMilliseconds: 57
inputData.Data: double[1, 1, 29600, 16]

Sorry my bad ... :)!

(make sure >>>> not <<<<  to pass an non-generic System.Array so the right overload will be called).

You should not use System.Array.
This sends you to the following overload:
public static NDArray array(NDArray nd, bool copy = false) => copy ? new NDArray(nd.Storage.Clone()) : new NDArray(nd.Storage);

Passing System.Array calls implicit cast to NDArray.
You should use one of these overloads:

I guarantee it will run in less than 5ms. I dare to say <1ms.


Custom Padding in PopupMenuButton

Not able to configure padding in PopupMenuButton.  It is seems like it using the default values for vertical and horizontal paddings,
const double _kMenuCloseIntervalEnd = 2.0 / 3.0;
const double _kMenuHorizontalPadding = 16.0;
const double _kMenuDividerHeight = 16.0;
const double _kMenuMaxWidth = 5.0 * _kMenuWidthStep;
const double _kMenuMinWidth = 2.0 * _kMenuWidthStep;
const double _kMenuVerticalPadding = 8.0;
const double _kMenuWidthStep = 56.0;
const double _kMenuScreenPadding = 8.0;

Flutter 1.17.0 • channel beta • https://github.com/flutter/flutter.git
Framework • revision e6b34c2b5c (11 days ago) • 2020-05-02 11:39:18 -0700
Engine • revision 540786dd51
Tools • Dart 2.8.1

Hi @iapicca
Is it possible to change _kMenuMaxWidth constant to allow a little bit more space for (foreign languages) longer sentences?
NOTE: I'd changed it to
const double _kMenuMaxWidth = 10.0 * _kMenuWidthStep;
because I do need a larger font size for older people (users).
Thanks.

@TahaTesser, thank you for adding "severe: new feature" label.  Any news?

It would be fantastic to be able to change this value (_kMenuHorizontalPadding) so that you have the option to remove the padding.

Would be a useful feature.

Plus one for this issue. 👍🏻
I just searched for how to remove and change these as well and landed here. Particularly I wanted to get rid of of the top and bottom padding on the popup menu.
This use case example with a long press on a widget context menu, with rounded corners and slightly transparent background,  eg as a cut / copy / paste context menu. Would have looked much nicer and compacter without the extra padding on top and bottom. Being able to remove them would have enabled having the padding just a part of the the item height, so when selecting top and bottom items, the highlighte selection and splash would have included the rounded shape border, but nope, no can do, not with this widget.

Parameters like this should be part of PopupMenuThemeData and as properties in the Widget.
Material still does not always want to work with you, when you want a slightly different design. I know, back to making totally custom widgets or forking this one, just don't always have time for it, this will have to do for now, the look is acceptable for now for my use case, but it could have been even prettier.
Pity to see an issue like these open for this long, it was reported in May 2020.
cc: @HansMuller @mariamhas

@pedromassangocode Hello! Can I take this issue?

Hi @Moluram  of course :)
I will assign it to you.


Unable to retrieve transcript for YouTube video using youtube_transcript_api

I'm experiencing an issue with retrieving the transcript for a YouTube video using the youtube_transcript_api library. I've checked the video ID, transcript availability, and API status, but the issue persists.
Version: 0.6.2
Code:
from youtube_transcript_api import YouTubeTranscriptApi

video_id = "R0jEmIlydqyrZgX6"
transcript_text = YouTubeTranscriptApi.get_transcript(video_id)

The video_id you provide is 16 characters long.
It looks like the length of a youtube video id is 11, not 16.
I get a "no file exists" reply when attempting to visit the youtube video associated with the id you provide
https://www.youtube.com/watch?v=R0jEmIlydqyrZgX6
Make sure you have the right id.

You haven't provided the exact error you're getting, but indeed it looks like your video ID is not valid. I'll close this now.


Pygen templates cleanup

Description
Cleanup of templates for python sdk, mostly comments.
Checklist:

[ ] Tests added/updated.
[ ] Documentation updated.
[ ] Changelog updated in CHANGELOG.md.
[ ] Version bumped. If triggering a new release is desired, bump the version number in
version.py and
pyproject.toml per semantic versioning.

Made obsolete by https://github.com/cognitedata/pygen/pull/2


Document WSK_CONFIG_FILE setting. Closes #225.

Has been around for a long time but nobody knows.
Closes #225.
Closes #1908.

merged af6b00306f5060cf6abfca2a09ab91c482e8cc1a


Handle editathon with more style

Rough Workflow

User requests tool account for editathon management, linking account via OAuth as normal.
User creates event using event management, specifying a key for participants to use during their creation process

Event is approved by a tool admin
User proceeds to host event, giving users a special URL to use to create their account (probably something like /index.php/event?uuid=48432608-41fc-40b4-b7ed-7198045c7510 to idle URL guessing.
Requester fills in the request account form, passing the extra "event key" that is setup by User

Request gets tagged as part of the event, and is shown to User in a cut-down version of the main request list

User handles requests for their event, shown in a redacted form, skipping all private data (IP data is useless if everyone shares an IP address, not much is gained from email address display anyway)

User hits the create button on the request, the tool uses their stored OAuth credentials to create the account. If anything like blacklist or antispoof is hit, the request is escalated to normal tool users. User can also escalate to tool users on their own.

Points of note

Tool security will be extended to create two new user states: NewEventUser and EventUser

Add a radio button on tool signup to allow the user to choose between New and NewEventUser as their initial state.
Extend status change workflow to allow changing a user's event/not-event roles
Event roles will not require identification

Event users will not be able to see any request that is not tagged for one of the events they are an organiser for. This includes untagged requests.

Normal tool users will be able to see all requests.

Events have to be approved by Tool Admins, and can be disabled at any point by Tool Admins. Disabling an event removes the ability to request new accounts for that event, and removes the ability for the organiser to see that event.
Events have a start and end time, which is the time period between which the request key will work. After the event is over, we should redirect to the main request form and create untagged requests as normal.

Looks good.

I read this workflow. I regularly organize Wikipedia/Wikimedia events and this is a process which would work for event organizers. What is described here would be easier than the current process in use by organizers and also would address some of the security concerns which make the wiki community anxious and afraid of group outreach events with many new account registrations.
I wish to highlight a social concern. The first step is "User requests tool account for editathon management". This tool can only be useful if the expected user is a typical event organizer. Right now, outside of interface and software concerns, there is in-wiki social pushback against granting tools to permit typical event organizers to create accounts for new users at wiki events. A typical organizer, for example, might be a librarian hosting a wiki event for 15 people who join an event at a library, and that would be a typical user of this tool. The security of this tool should be aligned with the expectation that if a person is verified (whatever that means) to be a librarian hosting a wiki event, then they should be able to use this tool to register 15 new users who join their in-person event. This tool would not be useful if such a person were not permitted to create accounts in those circumstances.

@bluerasberry So I don't know how we can solve the general case of the smaller groups needing to create accounts like this.
If we allow "unknown" people access to bypass the threshold, we're essentially opening the door wide open to abuse here. This is also why I'm wanting to use the organiser's account to do the creations via OAuth, such that they need the accountcreator permission. I'm happy for users who can gain that to use this tool, that's not an issue.
We simply don't have a good process to tell apart a sock master from an honest librarian - this is not something I think can be solved by a technical process, which this is. As much as I'd like to solve this too, it's not something that is targeted by this solution, and should be discussed on-wiki anyway.*
The problem this is trying to solve is that where an event organiser requests account creator rights then leaves their laptop in a public place logged in for people to create accounts themselves, or where event organisers have difficulty getting the limit lifted for an IP, or where use of the existing ACC tool takes too long. All of these require some level of verification already, and are non-ideal solutions with no real auditing and abuse-prevention capabilities.

Side note, I wonder if adding yet another creation form which is specific for events generally but isn't part of a specific event queue should be added. Creations to this form go to a separate queue on the tool and can be prioritised if they come in, and this form can be only published in event organisation circles - too wider publication would negate the benefits of the separate form, and too narrower scope means it wouldn't be found. There'd be no way for an event organiser to take responsibility for approving the accounts themselves in that case though, so it'd have to wait on the main team as currently happens. That can be done in a separate change though, once more thought has been put into it other than this quick point.

@bluerasberry Reading your comment, I'm not sure the problem you describe exists.  This document is a purely technical specification, and the standards to be used for approving event managers is flexible and can be decided later on-wiki in front of a wider audience.  I see no reason why, as long as community consensus is okay with this, we can't give a "verified librarian" access to manage their events, even if they are "new" to Wikipedia.

@stwalkerster @FastLizard4 Okay - hmmm.
Yes, I confirm that this is a need to address.

The problem this is trying to solve is that where an event organiser requests account creator rights then leaves their laptop in a public place logged in for people to create accounts themselves, or where event organisers have difficulty getting the limit lifted for an IP, or where use of the existing ACC tool takes too long.

If this tool can increase the security in these situations, then that would satisfy the stakeholders who are concerned about security. It sounds like the point of this is not to make it easier for anyone to organize events, except possibly as a side effect of making the broader community more comfortable about the security practices at events.
What I had imagined was that this process was intended to increase security enough to justify lowering some barriers to receiving account creator rights. For as long as the barriers to getting those userrights remain high, there will be challenges for event organizers.

I see no reason why, as long as community consensus is okay with this, we can't give a "verified librarian" access to manage their events

There is a problem. The community is not okay with giving new users account creator rights. The stated reason is security concerns. One of the security concerns is that account creator rights comes with extra override abilities beyond creating accounts, so separating that override function from the account creator tool addresses some of the problem. I wish that baked-in to the development of the next thing there would be some anticipation of event organizers - almost always a professional in affiliation with a school or community center - would want to register a group of new users. I can imagine that the event organizer could get experienced Wikipedians to take responsibility to sign off on verifying their identity, but currently, the English Wikipedia account creator rights review process often challenges requests from users without significant wiki experience and that uncertainty leaves some barriers to planning outreach even if they do have support from experienced wiki users.
I am unclear if this tool is intended for me. It might be that this tool is addressing issues beyond the usual concerns that I face as an event organizer.

@bluerasberry , from what I see here the bundling of the ratelimiting and the account creation is what you see as the primary issue here?
I think we could probably let a bot do the actual creation in some circumstances, pending community consensus (which might be hard to get). My preference would be to use the event organiser's account to do the creation in as many cases as possible for tracability, but I think we could probably push the decision to the tool admins here, as they are likely to be able to get better validation as to whether or not a user is legit. I think a good approach here would be to get the event organiser to email the tool admins from an official email address confirming the request - something they can't really do on-wiki. I don't want to go down the bot route just yet, at least until other avenues have been tried. I'd rather get this up-and-running as soon as we reasonably can in a basic version that we can have a few more-experienced users such as yourself try with a real crowd to iron out any last few bugs. Once that's explored, we can look to expand and add the bot functionality if and only if it really is required.
If a user uses the tool to create an account, the log entry should be tagged as coming from that tool. We can easily make the tool ignore the extra rights granted in that package, and we can also make it clear to the user at request time that they're only to use the tool. Verification would thus be simple - are there any account creation log entries in the time period they have the user right that are not tagged from the tool?
I can't help thinking that this is trying to solve a social problem with technology though. This point really ought to be pushed with the admins who frequent WP:RFPERM, to the point of possibly unbundling the rate limit exemption from the two extra user rights granted, and pushing the event organisers to simply request this right.

@bluerasberry:

If this tool can increase the security in these situations, then that would satisfy the stakeholders who are concerned about security. It sounds like the point of this is not to make it easier for anyone to organize events, except possibly as a side effect of making the broader community more comfortable about the security practices at events.

That is correct.  The goal here is to create a standardized, secure mechanism for creating accounts at editing events.  This should have the effect of making the community more comfortable with account creation at events, as well as making the process of hosting an event simpler by virtue of standardizing the process of creating accounts for attendees.
Again, we are only capable of solving technical problems, not social ones.

What I had imagined was that this process was intended to increase security enough to justify lowering some barriers to receiving account creator rights. For as long as the barriers to getting those userrights remain high, there will be challenges for event organizers.

I believe I touched on this issue in a reply to you on-wiki some time ago; there will likely be a need for a new user right to be proposed to the community that allows for bypassing the six-accounts-per-day limit without the additional abilities to bypass things like AntiSpoof, or (as an alternative to the currently proposed OAuth-based solution) a properly privileged bot controlled by ACC doing the actual account creations (which would require no additional user rights to be conferred to the event organizers, but the bot itself would need community approval instead).

I wish that baked-in to the development of the next thing there would be some anticipation of event organizers - almost always a professional in affiliation with a school or community center - would want to register a group of new users.

You need to recognize that there are more than just technical considerations here.  For example, sockpuppetry is a very real abuse problem on Wikipedia, and technical and policy measures are necessary to combat it.  This is why the six-accounts-per-day limit exists in the first place - a solution of policy, not a strictly technical one (even if it is enforced by technical means).  Because of the abuse, it was decided that we simply cannot allow just anyone to create however many accounts they want, so there will always be some barrier to entry for people wishing to host/manage editing events.  Barring unforseen changes in the social climate on Wikipedia, this is simply a fact of life - there is nothing we can do about it from a technical aspect, and instead I would suggest proposing changes at the appropriate venues on-wiki, and working with others who coordinate editing events to determine a vetting process that can be used to work around this.
It's worth noting that I can't actually find anything on Wikipedia that is something resembling a list of recommendations and procedures for people who wish to host editing events; perhaps this is something you should pursue first before turning to us for technical solutions?  (If this does exist, though, and I've simply missed it, please do provide a link.)

but currently, the English Wikipedia account creator rights review process often challenges requests from users without significant wiki experience and that uncertainty leaves some barriers to planning outreach even if they do have support from experienced wiki users.

Again, the event account creation management proposal in this issue combined with a new user right on-wiki should mitigate at least this much.

I am unclear if this tool is intended for me. It might be that this tool is addressing issues beyond the usual concerns that I face as an event organizer.

The project you are currently looking at, enwikipedia-acc, is the code currently used for WP:ACC on Wikipedia.  As it is currently written, no, this tool is not intended specifically for event managers, but for trained account creators.  The event management additions described in this issue, however, is written with extending ACC to event managers in mind.
I do agree with @stwalkerster though; it seems increasingly like you are trying to get us to solve with technology what is really a social problem.  In addition to his suggestions, I would suggest revisiting the comment I left on-wiki on this issue a couple months ago in a talk page discussion we both participated in.  Regardless, if it is in the end a social issue you wish to solve, there is only one place where that can be done - on Wikipedia, in the appropriate community discussion venues.

@bluerasberry To add to my comment above, we are happy to make the changes described in this issue to the ACC tool in the hope that you and other event hosts will find them useful, and in the hope that it will make the community more receptive to standardizing a procedure to allow for account creations at editing events.  However, no matter what, we cannot be the sole drivers of social change, and at some point, even with the changes described in this issue, you will need to propose some changes on-wiki if your end goal is to reduce the barrier of entry for event hosts.

I personally like the idea of an ACC Bot doing the actual creations. This also would likely be easier to support though onwiki. Any unbundling of any tools right now is a super minefield with the community and all proposals sink quite fast not because of merits, but mentality. It's not a difficult thing to include a link to a tool request in the creation and mention that it's an event.
We still get the needed information with the tool like an email address (and although the IP address is invalid, it would be anyway). This would also protect the end user from getting stiffed up by a checkuserblock cause they think there are loads of accounts being created from a (relatively) new account of a librarian or something of the sort.
There is no loss in using a bot to create the accounts no more than normal ACCing is. There is the increased benefit of offwiki review of the organizers to vet them, something that would be a benefit to the community, as it can't happen onwiki, nor is it a viable option through OTRS.

On the subject of bot vs. OAuth API calls through the event manager's account to create accounts, I have no opinion and I can see the pros and cons of both.  Either is 100% acceptable to me.

So, as far as implementing this, I have the following general tasks to be done:

[ ] User rights changes

(kinda done, not confident, so going the nuclear option and implementing full RBAC instead)

[x] Event management UI - including event workflow stuff
[x] Customised request forms, including tagging the request with the event
[ ] Display of queued requests
[ ] Request zoom without data
[ ] Escalation to main team
[ ] Automatic creation

[ ] via OAuth
[ ] via Bot

I'm going to boldly close this, as we took so long to get newinternal into prod that the Program and Events dashboard now effectively handles this functionality.
Some of the functionality added in this will be rolled into #532.


Update scalafmt-core to 3.5.0

Updates org.scalameta:scalafmt-core from 3.4.3 to 3.5.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Codecov Report

Merging #287 (e4bc79d) into master (8cbb376) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #287   +/-   ##
=======================================
  Coverage   96.19%   96.19%
=======================================
  Files           4        4
  Lines         105      105
  Branches        4        6    +2
=======================================
  Hits          101      101
  Misses          4        4

Continue to review full report at Codecov.

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


Schema validation fails in ignorePatterns that was added in eslint v7

I have an @scope/eslint-config package published from our monorepo and I'm trying to consume it in a separate project.
ESLint works correctly when invoked via the CLI. However, in vscode-eslint, I get the following error:
[Error - 10:32:57 PM] ESLint stack trace:
[Error - 10:32:57 PM] Error: ESLint configuration in .eslintrc.js » @pcln/eslint-config is invalid:
	- Unexpected top-level property "ignorePatterns".

We use the ignorePatterns to exempt a list of folders by convention (build dirs, coverage reports, static storybooks, etc) in the eslint-config so that all of our projects don't need to maintain a list of all the standard ignores.
It seems like maybe the schema validator doesn't consider ignorePatterns as a valid member of the schema. Is there a way to override it?
Thanks for your time!
-steve

@sdalonzo actually the extension doesn't do any schema validation by itself. It delegates everything to the eslint npm module. Since it is working in the terminal can you please provide me with a GitHub repository I can clone that demos what you are experiencing.

I also am having this issue. Command line works fine, VS Code throws an error. VS Code was fine with the syntax, and decided recently to stop working.

Check your eslint version, old eslint versions complain about this issue. Seems like ignorePatterns was added after v6


bugfix: fix logic error in volume create mock test

Signed-off-by: Zou Rui<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
fix logic error in volume create mock test
Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how you did it
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #1033 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1033   +/-   ##
=======================================
  Coverage   14.91%   14.91%
=======================================
  Files         133      133
  Lines        8483     8483
=======================================
  Hits         1265     1265
  Misses       7118     7118
  Partials      100      100

Continue to review full report at Codecov.

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

LGTM

LGTM


Update AD comparison

Update AD benchmark to the latest versions of DifferentiationInterface
For some reason Tapir fails, will investigate

What about just keeping Tapir on the earlier version for now?

I opened an issue at Tapir.jl, let's see what @willtebbutt thinks
https://github.com/compintell/Tapir.jl/issues/193

Since it sounds like per https://github.com/gdalle/DifferentiationInterface.jl/issues/339 and others things like closures DI is likely to have a nontrivial performance loss on Enzyme, can we just add Enzyme.gradient/autodiff benchmkars here directly

The benchmarking utilities of DifferentiationInterfaceTest are one of the main appeals of the package, and so this notebook is a benchmark of AD backends as called through DI. I think it can also be useful for non-advanced users who want to use DI precisely because it is simple and backend-agnostic. Thus I would recommend we keep this page as it is, possibly with a warning.
And I am aware that you're not happy about Enzyme being possibly a bit slower in DI @wsmoses ;). I just ask that you give me time to come up with a solution that makes everyone happy. If you want me to put a warning in my own docs about performance, I will.

can we just add Enzyme.gradient/autodiff benchmkars here directly

We should measure the difference, that would make the discussions much more concrete.

Yeah I think having both here would be useful. In this function in particular I imagine the perf would be mostly the same (given its already a single arg fn without a closure), but we could see how things actually shake up for the things being discussed

this notebook is a benchmark of AD backends as called through DI.

Oh okay. I misunderstood this as a benchmark set of AD packages in general, rather than a DI-specific benchmark. If this is the case, maybe this should have a warning at the top saying that "This benchmark set is for testing the performance of DI and will have performance that may differs from using AD packages directly. If you are looking for a benchmark of different AD backends please see "

I'm okay with things going either way. I agree that having a comparison with "native" Enzyme would make sense, especially in some complicated cases like closures. But I have already done the work of coding this backend-agnostic benchmarking pipeline, and so far it is the only thing close to a standard that we have.
So my suggestion is the following: if AD developers are unhappy with the performance of their backend on a given benchmark, they are free to contribute the necessary code to add rows to the DataFrame in this notebook. Of course said rows should contain the exact same quantities that DifferentiationInterfaceTest computes by itself, to enable comparison. In other words, now that there is a standard, if you want to beat the DI implementation, the burden falls on you to play by the same rules. Or better yet, to contribute ideas to DI and help me fix performance pitfalls. What do you think?

@gdalle is the DIT results basically compatible with benchmarktools? In which case I imagine it should be fairly simple to just add a @ benchmark / @ btime like below.
As for the tangible perf implications, here's an example. Asking for the closure derivatives, like in https://github.com/gdalle/DifferentiationInterface.jl/pull/341 will cause the derivative code to become arbitrarily asymptotically worse (here demonstrated going from O(1) -> O(N)). The linked PR failed to compile for me so I demonstrate with what the Enzyme calls would be directly.
As a top level comment, I simultaneously think the work you've done is immensely valuable (especially here to showcase a comparision), and also think it is important to provide reasonable default benchmarks/examples/docs/etc. People look to docs/benchmarks as examples as how things should be written/used and showing them something suboptimal or with an error has led to issues for Julia in the past (e.g. there was a Julia language doc for inbounds that itself misused inbounds, leading to lots of headaches -- and in various code examples of people using type unstable global variables leading to the use of type unstable global variables in a lot more places). If this is meant to be something which represents how to use AD in Julia [in contrast to how to use DI], I think it is important that we give examples that show how to use these tools most effectively (as well as how to use these tools most easily, thanks to DI!).
struct MyClosure
	y::Vector{Float64}
end

function (c::MyClosure)(x)
	sum(c.y) + x
end

y = MyClosure(rand(10000))

using Enzyme
using DifferentiationInterface
using BenchmarkTools

@btime Enzyme.autodiff(Reverse, y, Active(1.0))
#  36.380 ns (1 allocation: 16 bytes)

@btime Enzyme.autodiff(Reverse, Duplicated(y, make_zero(y)), Active(1.0))
#   3.422 μs (11 allocations: 78.67 KiB)

using DifferentiationInterfaceTest
backends = [
    AutoEnzyme(mode=Enzyme.Reverse),
];

scenarios = [
    GradientScenario(x->y(x[1]); x=[1.0], y=1.0, nb_args=1),
];

# Using DI main
data = benchmark_differentiation(backends, scenarios, logging=true)

# 3×11 DataFrame
#  Row │ backend                            scenario                           operator             calls  samples  evals  time      allocs   bytes    gc_fraction  compile_fraction
#      │ AutoEnzy…                          Scenario…                          Symbol               Int64  Int64    Int64  Float64   Float64  Float64  Float64      Float64
# ─────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
#    1 │ AutoEnzyme(mode=ReverseMode{fals…  Scenario{:gradient,1,:inplace} #…  prepare_gradient         0        1      1  0.0           0.0      0.0          0.0               0.0
#    2 │ AutoEnzyme(mode=ReverseMode{fals…  Scenario{:gradient,1,:inplace} #…  value_and_gradient!      1    20198      1  3.375e-6     20.0    544.0          0.0               0.0
#    3 │ AutoEnzyme(mode=ReverseMode{fals…  Scenario{:gradient,1,:inplace} #…  gradient!                1    20006      1  3.375e-6     11.0    288.0          0.0               0.0

# Using Rebase of https://github.com/gdalle/DifferentiationInterface.jl/pull/341
# julia> using DifferentiationInterface, Enzyme
# Precompiling DifferentiationInterfaceEnzymeExt
#         Info Given DifferentiationInterfaceEnzymeExt was explicitly requested, output will be shown live
# ERROR: LoadError: UndefVarError: `@compat` not defined

Thanks Billy for the example, which indeed gives proof that https://github.com/gdalle/DifferentiationInterface.jl/issues/339 needs a little more thought.
In the meantime, DIT benchmarks are not done with BenchmarkTools but with Chairmarks, so the fields are slightly different.

You're mixing two related but different concepts. This has nothing to do with https://github.com/gdalle/DifferentiationInterface.jl/issues/339. https://github.com/gdalle/DifferentiationInterface.jl/issues/339 needs to be done for correctness reasons. If you check
@btime Enzyme.autodiff(Reverse, y, Active(1.0))

it simply gives the wrong derivatives in many cases. Yes it's fast, but:
function (c::MyClosure)(x)
       c.y[1] = x
	sum(c.y) + x
end

you'll get the wrong answer with @btime Enzyme.autodiff(Reverse, y, Active(1.0)). So there's two separate things here. One is that, DI should get the right answer. It can have a fast mode for duplicate_closure = Val(false) to remove the closure duplications as a performance operation, but unless you can prove it's correct you must ensure those values are differentiated. In the most common Julia use cases, which is using closures to enclose caches for temporary variables, you will get the wrong answer if the user sets this to false, and so it should be documented appropriately.
The second is, DI should not build closures and instead should pass in const arguments so that what it's using for caching can parameters is not caught up in the closure duplication. That's the multi-argument form, and having this be a two argument function with a const on the second is the way to ensure it's clear not to differentiate the argument here.
But I would be very thinking an approach is a "performance optimization" when it makes a very common use case simply compute the wrong answer.

My thinking was that having multiple arguments would solve both problems at once, but you're right, people may still want to put stuff in the function f itself and I can't stop them.
Do we actually pay a performance penalty for Duplicated(f, make_zero(f)) if f is not a closure, and contains no differentiable storage?

Do we actually pay a performance penalty for Duplicated(f, make_zero(f)) if f is not a closure, and contains no differentiable storage?

There is no performance penalty in this case. There is a bug I'm trying to isolate, see https://github.com/SciML/SciMLSensitivity.jl/pull/1067 , but I can verify that it's zero overhead.

For multiple arguments and activities, check out my proposal in https://github.com/gdalle/DifferentiationInterface.jl/issues/311#issuecomment-2228066950, I think I'm getting closer to an interesting interface.
As for the default behavior, I think most other backends consider the function constant, so in that sense keeping the current behavior for Enzyme seems reasonable indeed, as long as I warn about it in the docs. Once multiple arguments are supported, closing over a cache is no longer necessary.

However if the function were always differentiable it would be impossible to represent the case where you don't differentiate wrt the function/model/etc, which is the default of other AD tools.

The issue is that other AD backends throw an error. For example, we have this in the DiffEq FAQ because this comes up often.
https://docs.sciml.ai/DiffEqDocs/stable/basics/faq/#I-get-Dual-number-errors-when-I-solve-my-ODE-with-Rosenbrock-or-SDIRK-methods
People will differentiate a code like that and get and error saying that there is a conversion of Float64 to Dual, undefined, etc. etc. and they will then ask or read the FAQ and then use PreallocationTools.jl to fix it.
The issue with non-duplicated closures is that you simply get the wrong answer with no warning or error. https://github.com/SciML/SciMLSensitivity.jl/pull/962 was done because on those examples if it's not done, you just get the wrong derivative.
I would be okay with the approach of not handling it by default if there was an error or warning to disambiguate const vs active, but you really can't just assume that every user's function won't have active elements because that's not true, and it's so not true that we specifically have a section of the FAQ dedicated to it. DI shouldn't make closures and differentiate what's not needed, but making the assumption that the user's function is not active is just not always right, and it's also silent about the fact that it's not always right.

But that's the same for other backends, right? If you try to differentiate through a cache closure with ForwardDiff, it will error, which is the reason behind PreallocationTools I believe. The trouble here is that the DI error is silent, which I agree sucks.

But if we clearly document in DI that f should not enclose anything but constant parameters, it's not really incorrect, right? It's just a caveat that users have to know about.
My issue is the consistency of semantics: Billy is right, I think no other backend handles closures with differentiable caches correctly. So why would Enzyme be held to a higher standard?

I think no other backend handles closures with differentiable caches correctly. So why would Enzyme be held to a higher standard?

Every other backend throws an error though. I would rank it as:

Supports it out of the box
Throws an error out of the box, requiring PreallocationTools as a workaround
Silently computes the wrong answer if you happen to use closures in a model as a cache for active values

All other AD backends do (2). Enzyme supports (1) or (3), but does not currently support (2) at least to my knowledge. Choosing 3 is not up to the standard we put on the other AD libraries.
I understand wanting to go fast, but what about clearly documenting a proposed speedup boolean, so AutoEnzyme(skip_closure = true), clearly documented as a "this can make some codes go faster, but with caution as to when it would make the wrong values appear? It wouldn't even effect most benchmarks, because most code either won't use closures or they are enclosing caches so it's required to be true for correctness anyways. The case where you don't need to differentiate some enclosed value because it's constant, but it's also a major performance hit, is such a weird edge case to willingly throw out the the property of "we try to be (mathematically) correct or we error". IMO, that should be the first principle an AD library tries to adhere to, then a second property of "fastest possible thing without tweaking the defaults" is also a good property to me comes second.

Yeah I had thought of amending ADTypes too. Perhaps AutoEnzyme(constant_function=true/false) would be clearer?

But the error is not in Enzyme, but on what picked the wrong Enzyme call.

I agree here. It's not an issue with Enzyme, but:

By a similar token if DI specified that the function is always non differentiable, it is not a bug in DI since that is using DI for a problem out of spec. The question at hand, however, is what should the spec be (eg a question for users of DI, one within DI, etc)

I think that's a misunderstanding of how DI is expected to be used. If we expect DI to be used in packages, say DiffEq, NonlinearSolve, Turing, etc. then you can't expect most users have read the documentation of DI at all. In fact, I'd argue that most users of DI won't even read most of the documentation either (unless there's an error message that tells them to read a specific page). The issue that I'm seeing is that DI as a general differentiation interface is planned to be used pervasively, but if it makes a choice like this, then this is a choice made for downstream as well. And it would be very confusing to a Turing user if they used a mutable cache to make their code non-allocating with pre-allocated buffers because this blog post https://viralinstruction.com/posts/optimise/#cut_down_on_allocations said to do that, and now their code does not converge correctly. At least today, a user of Turing will get an error message

On this PR though, @gdalle should we merge with AutoTapir giving NaNs?

I'm working on resolving this by removing JET as a dep of Tapir.jl. I'm expecting to have something merged today, then hopefully this will all work nicely, and you can use the most recent version of Tapir.jl.

@gdalle could you please try restricting the version of Tapir to 0.2.26 and up, and see what happens? It should work now.

Does it usually take an hour to find an agent for the AD testing?

The sparse matrix run is 3 days, so that's occupying one. Then there's the bump here https://buildkite.com/julialang/scimlbenchmarks-dot-jl/builds/2671#0190dd16-0e34-4ef6-bb22-a261e6ae81d9 which should probably be done in a few hours.

It looks like this went through and we're getting numbers. Merging. I'll probably tag a new set on the benchmarks soon too, so this might be the first tagged version.


[BUG/Help]  Loading checkpoint shards:   0%|   Segmentation fault

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
执行 python3 web_demo.py
模型文件从https://cloud.tsinghua.edu.cn/d/fb9f16d6dc8f482596c2/ 这里下载
执行到model = AutoModel.from_pretrained("THUDM/chatglm-6b", trust_remote_code=True).half().cuda() 时报错
Explicitly passing a revision is encouraged when loading a model with custom code to ensure no malicious code has been contributed in a newer revision.
Explicitly passing a revision is encouraged when loading a configuration with custom code to ensure no malicious code has been contributed in a newer revision.
Explicitly passing a revision is encouraged when loading a model with custom code to ensure no malicious code has been contributed in a newer revision.
Loading checkpoint shards:   0%|                                                                                | 0/8 [00:00<?, ?it/s]Segmentation fault
求解原因
Expected Behavior
No response
Steps To Reproduce
none
Environment
- OS: linux
- Python: 3.7
- Transformers: 4.27.1
- PyTorch:
- CUDA Support (`python -c "import torch; print(torch.cuda.is_available())"`) :

Anything else?
No response

我也遇到了相同问题，请问你有解决吗？

我现在用了更小的模型chatglm-6b-int4，感觉可能和内存有关系。

发件人: licy02 @.>
发送时间: 2023年5月19日 11:18
收件人: THUDM/ChatGLM-6B @.>
抄送:<PHONE_NUMBER>1 @.>; Author @.>
主题: Re: [THUDM/ChatGLM-6B] [BUG/Help]  Loading checkpoint shards: 0%| Segmentation fault (Issue #1010)
我也遇到了相同问题，请问你有解决吗？
―
Reply to this email directly, view it on GitHubhttps://github.com/THUDM/ChatGLM-6B/issues/1010#issuecomment-1553943063, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFSAKGALEMIXN3S7LE4IHSDXG3RBBANCNFSM6AAAAAAX7KP6BA.
You are receiving this because you authored the thread.Message ID: @.***>


Further clarifying statement for api-name

Problem description

API Design Guidelines give a clear statement on api-name.
api-name is the API name specified as the base path, prior to the API version, in the servers[*].url property. For example, from /location-verification/v0, it would be location-verification.
However, since 'servers' field is an array of Server Object, there could be more than one servers[*].url property.  An API provider may use different strings in each of the Server Objects resolving to different api-name.
Expected action

Update API Design Guideline to ensure same 'api-name' resolution even if there are multiple server objects defined.
Additional context

@gmuratk My understanding of the design guideline is that the same string is used within the server object and scope names during the API design, both are fixed defined within the API definitions. E.g. the server object is defined as:
servers:
  - url: {apiRoot}/quality-on-demand/v2
    variables:
      apiRoot:
        default: http://localhost:9091
        description: API root, defined by the service provider, e.g. `api.example.com` or `api.example.com/somepath`

which means an API provider shall only differentiate the {apiRoot} but not the last part of the URL with API name and version.

@hdamker I agree.  The clarification I suggest is to remove any assumptions.  This issue is raised based on a question we have received from a developer, and I pointed to the DG, with a similar description you provided.
However, I think just having a statement like the following can avoid questions:
If more than one server object instances are listed, each servers[*].url property must have the same string for the API name and version in respective instance

It makes sense if it helps for clarification


Update gitignore

@webknjaz updated .gitignore, because some files from .idea/ not ignored.

@webknjaz updated .gitignore, because some files from .idea/ not ignored.

@webknjaz sorry? why we can't merge it?

@webknjaz Corrected, as you said.

No, you did not rebase.

And have some PR description, which relates to actual changes

@webknjaz Now, all right?

No, I still see merge commit and unrelated commits.

@webknjaz And now?

Please squash those into one commit, because it's all one atomic change.

@webknjaz Maybe now we can to merge in master?

Sorry, @webknjaz can you tell what commits are we talking about?

https://github.com/kpi-web-guild/django-girls-blog-serhii73/pull/33/commits

@webknjaz Done =)

Why do you need so much commits?

@webknjaz I think I did git pull --rebase and it commits from the master.

Then something went wrong. Collapse all commits into one.

@webknjaz Done.

Merge branch 'master' into update_gitignore

not done.


Changed Cofeecup to CoffeeCup in Update 049 - potluck.md

Fixed spelling and capitalization of sponsor.

thank you! CC @avclark can you update the feed with this mistake?


my first revup bar

Topic: bar

Reviews in this chain:
└https://github.com/matteo-tullo-skydio/revup/pull/2 my first revup bar

#
head
base
diff
date
summary

0
9f528afe
71ca5eb4
diff
May 22 17:04 PM
1 file changed, 1 insertion(+)


Implement sunrise/transit/sunset

It's in the NREL SPA report.

Mostly done. The whole deal with day fractions, rollover, and timezones isn't very nice though; it would be much preferable to do all the calculations in UT and let Java do the TZ shifting on its own.


Highlight week in Weeklies view is all wonky

It looks like it might be using the number of daily resets instead of the number of weekly resets?

Alright, took a few tries and we finally got it 👍


Unmaintained?

Hi @dougsong first thanks for this great initial work, unfortunately Proxmox has not relesaed its official provider so I've been using yours for a while. I see the last PR was made >1 year ago, you still maintened this? If so, what if you opened it to new maintainers (e.g me) to improve documentation, add new functions and so on..  (as Proxmox itself I think it's not to its roadmap)
As the Terraform providers Upset are based are really complete, we can improve the actual things and add a couple new like: network managements, users, template...
I've seen also some operator for proxmox being released there last two years as Proxmox community is getting bigger and bigger for homelabers and companies
LMK what you think about this and again thanks for this effort

I was also wondering if this is still alive, will subscribe to this issue, @valkiriaaquatica if this will not get revived and you switch to something else please update here, I am also looking for a solution to provision proxmox VMs as k8s CRs.
Thank you!


Circle: OS X failures

Builds are currently failing on OS X:
. scripts/circle/test.sh returned exit code 3

With a nice and useless error!

I've disabled OS X testing temporarily.

It looks like something has changed since I last worked on this. There has only been one switch available to me, "Build OS X project" on https://circleci.com/gh/GoogleCloudPlatform/google-cloud-node/edit#build-environment.
Last I left that page, I set it to "Off". Now, it's "on", but builds are not running on OS X. There is likely more configuration to enable this behind the Org Settings route that I cannot access.


hook returned by bind(functionAcceptingArrayReturningAsyncObservable$) should not cause infinite render loop

Observed Behavior
Given

a function getAsyncObservableFromArray$(words: string[]) that returns an asynchronous observable
a use... hook that is derived from aforementioned function
a React component that invokes the aforementioned hook function

... the component causes an infinite render loop.
Expected Behavior
There should be no infinite render loop, the behavior should be no different from a similar scenario with

a function getObservableFromArray$(words: string[]) that returns a synchronous observable
a function getAsyncObservableFromScalar$(word: string) that returns an asynchronous observable

Steps to Reproduce
Uncomment line 35 in App.tsx in this code sandbox

Hey Bruce, thank you for your report!
However, this is intended behaviour. The parameters on a bind are meant to give you an observable for one specific instance, so they need to be identifying - and ReactRxJS uses referential equality.
The problem here is that because on every render you're creating a new array, bind will understand you have just switched to another instance of the observable. So it will unsubscribe from the previous one, call the factory function again (passing in the new array), and it will subscribe to the new observable returned by that function.
Because it's asynchronous, the hook will trigger suspense and when the value comes back, it will set the state. Which causes a re-render, which starts the cycle over again (a new array is created, bind understands it's a new instance, etc.)
The way to work around that depends a lot on your specific case, but usually it's moving the parameter you want to pass to the observable into another state observable, and then referencing that from your bind.

Thanks very much @voliva for the excellent explanation, much appreciated!


[FEATURE] Integrate MediaFiles service with Organizations service through AMQP

There is a need to subscribe to corresponding events in Organization service from MediaFiles service.

After implementation gallery of organization and integration it with media files service, this issue should become closed as persistently resolved.


[Bug] dicom can't be rendered when upgrade from 1.8 to 2.4+

Describe the Bug
I have a render problem when I upgrade cornerstone3d (with dicom-image-loader) from 1.8+ to 2.4.0+
The image was load, but can't be rendered.
It seems stoped on await viewport.setStack(stack) and  can't goto next step.
I believe it might be something like createAndCacheDerivedImage, which returns an IImage directly in v2, rather than a Promise<IImage>. However, I have been unable to locate it.  I didn't  use createAndCacheDerivedImage directly.
Steps to Reproduce
I wrote a demo to reproduce this: https://github.com/fancyoung/cs-demo-bug
  const renderingEngineId = 'myRenderingEngine';
  const renderingEngine = new RenderingEngine(renderingEngineId);

  // Create a stack viewport
  const viewportId = 'CT_STACK';
  const viewportInput = {
    viewportId,
    type: Enums.ViewportType.STACK,
    element,
  };

  renderingEngine.enableElement(viewportInput);

  // Get the stack viewport that was created
  const viewport = renderingEngine.getViewport(viewportId);
  const imageIds = ['wadouri:/dicom.dcm'];
  console.log('->', imageIds)
  await viewport.setStack(imageIds);
  console.log('-->> never show')
  viewport.render();

The current behavior
It stoped at line await viewport.setStack(imageIds), and viewport.render() never be called.
The expected behavior
render the image.
OS
macOS
Node version
v18.19.0
Browser
Chrome 129

please follow our example, which works fine https://www.cornerstonejs.org/live-examples/wadouri.html

I find out is cause by commonJS (from dicom-parser ?). Should use @originjs/vite-plugin-commonjs plugin converting commonJS to esm, then it works:
import { viteCommonjs } from "@originjs/vite-plugin-commonjs"

export default defineConfig({
  plugins: [viteCommonjs()],
  optimizeDeps: {
    exclude: ["@cornerstonejs/dicom-image-loader"],
    include: ["dicom-parser"],
  },
})

I use svelte, there is another strange thing, the converting plugin can not working with plugins: [sveltekit(), viteCommonjs()]. Then I use @sveltejs/vite-plugin-svelte instead of @sveltejs/kit/vite, it works.

thanks very much

@fancyoung Would you like to contribute to our project? It would be a wonderful gift from you to us. Could you create a PR to add the Svelte config to that page and possibly cross-link it in our migration guides?

@fancyoung Would you like to contribute to our project? It would be a wonderful gift from you to us. Could you create a PR to add the Svelte config to that page and possibly cross-link it in our migration guides?

My pleasure, I'd be happy to contribute. Just to confirm, should I place the Svelte config in https://www.cornerstonejs.org/docs/getting-started/vue-angular-react-etc or https://github.com/cornerstonejs/svelte-cornerstone3d? And where exactly would you like it linked in the migration guides?

I think if we put it in here https://www.cornerstonejs.org/docs/getting-started/vue-angular-react-etc it would be enough
and for migration guides maybe inside this one https://www.cornerstonejs.org/docs/migration-guides/2x/general#frameworks

I have submitted a pull request for the migration config docs related to this issue. You can review it here: https://github.com/cornerstonejs/cornerstone3D/pull/1681


use JSONSchema $schema for dbt contracts (via dataclasses + jsonschema-dataclasses)

Feature
dbt should use the $schema and $ref tags of JSONSchema instead of the current deep_merge and manually-referencing dicts.
Feature description
We should convert our json schema contracts to have $schema values pointing at publicly accessible URLs, use the $ref feature to link behavior of our internal JSON schemas, and modify our APIObject and its descendants to take advantage of it.
We can start by specifying just the outermost "layers" of the schema and add the references as we go along. We should do something like iglu uses and define a decent versioned self-describing format. An example iglu schema is here
We should support namespacing, and give dbt-core a separate namespace from any plugins (like adapters!) or dbt-cloud.
We also will want to specify credential contracts on a per-adapter basis, and adapter-specific configurations at some point (currently we just allow anything).
Serialization should include the schema value so we can try to do deserialization into dbt objects based on the schema.
Who will this benefit?
Anyone consuming dbt json output, dbt Cloud, developers

use a mix of dataclasses + https://github.com/s-knibbs/dataclasses-jsonschema to generate a JSON schema document for all of dbt's internal dbt objects

should we generate & write out the json schema document to the target path?

Fixed in #1589


C++ support in WASI?

I saw C++ ABIs and stuff mentioned in the Makefile.  Does that mean it's safe to assume that WASI fully supports C++ now?  Or are there still problems?  Thanks in advance for any answers.

C++ is supported, with the only caveat being that it doesn't support C++ exception handling yet, so you have to compile with -fno-exceptions.

WASI sysroot doesn't support it yet, though, right?  And I guess there's no ETA on it yet either?

It already does. If there are any problems, please file issues :-).

Okay, cool, thanks.


Bump Dart SDK version to 1.24.0 (stable)

https://github.com/flutter/flutter/issues/10650

I lowered the version to 1.24.0 (stable).  Will land on green.

For our work on bringing new dart frontend to flutter #10841 it is critical for us to have more or less latest dart in flutter engine as there are changes being made to dart vm to accommodate new frontend work.
With that in mind - is lowering to 1.24-stable temporary thing to troubleshoot #10650 or we need to come up with some mechanism of having parallel build of flutter engine/flutter tools that lives on more recent versions of dart?

@aam this isn't the Dart SDK version of the embedder (the engine) -- this is the Dart SDK version of the flutter tool (which is being upped from 1.24.0-dev.6.7 to 1.24.0.
It's admittedly unfortunate and confusing that the two aren't in sync.

We (rather trivially) could build our own Dart SDK on our bots and download it from the flutter_infra GCE bucket and always have the flutter/flutter version use the flutter/engine's exact Dart revision.  We just haven't done it.

Oops, got you, thanks!
By the way, you can use 'hash/65a5707189dec6c5e0174cbc821acfb90f0c9b3f' syntax in bin/internal/dart-sdk.version to reference particular bleeding edge of dart.
Also, with dart frontend support rolling out to flutter, version of dart sdk used by the flutter tools will have to [closely] match version of dart sdk used in the engine since kernel(parse tree) binaries produced on the workstation have to be compatible with what kernel binary reader on the device expects.

We should coordinate that with the team in Google that rolls the Dart SDK internally, since we want to make sure we don't put ourselves in a situation where we can't roll Flutter into Google because it depends on a Dart SDK version that's too far ahead of the internal SDK version.
/cc @keertip @srawlins

In short term, it will take some time for us to iron all kinks out flutter-with-new-frontend configuration. While we do that, new frontend functionality in flutter will be "hidden" behind configuration option (flutter run --is-kernel-mode, for example). During that phase, there is no need for everybody to have flutter tools and flutter engine on the same revision - only folks who decide to run with --is-kernel-mode have to do that, and they can accomplish this by manually updating dart-sdk.version to hash/..., that matches engine/src/flutter/DEPS dart_revision.
Hopefully by the time frontend integration with flutter is tested and verified, there will be no need to stay on bleeding edge of dart to pick up dart vm fixes for frontend, so we can go back to using dev channel versions.
Generally speaking, though, there will be [small?] risk in in rolling engine's dart dependency forward while leaving flutter tools's dart-sdk in place in case there are some changes to kernel format.
@a-siva


Feature: allow dynamic generation of project configuration

Do you want to request a feature or report a bug?
Feature
What is the current behavior?
To run the same tests in multiple environments concurrently, I'm using the projects feature:
jest --projects environment1.js environment2.js
However, if I have a lot of different environments, that requires files for each environment, which differ only by a few lines.
Note: I'm not using different Jest environments but different Selenium environments. My configs looks similar to this one:
const base = require('./base.jest.config');

module.exports = Object.assign({}, base, {
  globals: {
    seleniumConfig: {
      server: 'http://localhost:4444/wd/hub',
      capabilities: {
        browserName: 'firefox',
      },
    },
  },
});

If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.
N/A
What is the expected behavior?
Provide a way to provide multiple project configs from a single file. Any solution that
prevents me from having to create multiple files, such as exporting an array of configs or having
a different flag, is fine with me.
Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.
Jest: v21.2.1
Node: v8.6.0

Because they are JS files, you can compose your configurations by requiring other base configurations. I think that solves this use case without having to make Jest more complex to handle it.

Thank you for your quick reply. Having projects be an array of globs, or an array of actual configs would add a lot of complexity then? (I have 12 files to configure the same thing right now).

I'm not sure if this is the right use case for the MPR, but I also don't have a reason to think it is not, just intuition. Is there another way you could configure individual test runs? I don't think I'm opposed to making the change you are proposing for the general configurability of Jest but I'd first like to evaluate whether what you are doing is the right incentive to make this change to Jest.

I guess I could run Jest multiple times, or create a custom runner, or maybe there's another way?
I think creating an async test environment per browser would be ideal though.


Replaced generic error message with a detailed one

Instead of a generic 401 status failed message, it has been replaced with a message saying that the username/password provided is invalid.
What was the feature/problem?
Whenever a user provides an invalid username/password, the error returned is not very descriptive.
How does this PR address the above feature/problem?
This pull request added a specific message saying that the username/password that was provided is invalid.
Check lists (check x in [ ] of list items)

[x ] Test passed
[x ] Coding style (indentation, etc)

Additional Comments (if any)

@jacklagare can you catch your fork up with master to get by the GAE deploy check?
Also, we now have two PRs that attempt to fix the same thing (#78). I am going to get some designers opinion on what this should be. We have to remember that this is for kids, so a message catered might be desired.

Codecov Report

Merging #90 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #90   +/-   ##
=======================================
  Coverage   95.39%   95.39%
=======================================
  Files          28       28
  Lines         391      391
  Branches       36       36
=======================================
  Hits          373      373
  Misses         15       15
  Partials        3        3

Flag
Coverage Δ

#api
97.12% <ø> (ø)
:arrow_up:

#ui
94% <ø> (ø)
:arrow_up:

Impacted Files
Coverage Δ

ui/src/login/ValidatedSignInForm.js
100% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Currently merged code has a friendlier error message :)
"Incorrect username/password. Please try again."


Next exception 'GuzzleHttp\Exception\RequestException' with message 'cURL error 56: TCP connection reset by peer' in /usr/share/nginx/html/project/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:51

Hi,
I am using laravel 5.2 version and using mandrilla to send email to user by guzzle lib
"guzzlehttp/guzzle": "5.3.0",
and it's show an error like this in my log file
Next exception 'GuzzleHttp\Exception\RequestException' with message 'cURL error 56: TCP connection reset by peer' in /usr/share/nginx/html/project/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:51
is this a bug of this lib or in my mechine how to fix this error, help me please!!! Thanks..

Thanks for the answer guys.... @tomzx , @sagikazarmark ...


Resource ciscoise_network_access_authorization_rules fails

Prerequisites

[x] Have you tested the operation in the API directly?
[x] Do you have the latest Terraform provider version?

Describe the bug
When using ciscoise_network_access_authorization_rules resource, Terraform outputs that id and name are not expected.
resource "ciscoise_network_access_authorization_rules" "example" {
  provider = ciscoise
  parameters {
    profile   = ["authp_uc6"]
    rule {
      condition {
        condition_type = "ConditionReference"
        name           = "lc_uc6w"
        id             = "716b2dfd-a1e0-4d94-9802-eb4d3bc614d3"
        is_negate      = "false"
      }
      default    = "false"
      hit_counts = 1
      id         = "string"
      name       = "MyRule1"
      rank       = 1
      state      = "enabled"
    }
    security_group = "BYOD"
  }
}

Results in:
╷
│ Error: Missing required argument
│
│   on network_access_authorization_rules.tf line 3, in resource "ciscoise_network_access_authorization_rules" "example":
│    3:   parameters {
│
│ The argument "name" is required, but no definition was found.
╵
╷
│ Error: Missing required argument
│
│   on network_access_authorization_rules.tf line 3, in resource "ciscoise_network_access_authorization_rules" "example":
│    3:   parameters {
│
│ The argument "id" is required, but no definition was found.
╵
╷
│ Error: Unsupported argument
│
│   on network_access_authorization_rules.tf line 8, in resource "ciscoise_network_access_authorization_rules" "example":
│    8:     profile   = ["authp_uc6"]
│
│ An argument named "profile" is not expected here.
╵
╷
│ Error: Unsupported block type
│
│   on network_access_authorization_rules.tf line 9, in resource "ciscoise_network_access_authorization_rules" "example":
│    9:     rule {
│
│ Blocks of type "rule" are not expected here.
╵
╷
│ Error: Unsupported argument
│
│   on network_access_authorization_rules.tf line 23, in resource "ciscoise_network_access_authorization_rules" "example":
│   23:     security_group = "BYOD"
│
│ An argument named "security_group" is not expected here.

Expected behavior
As per documentation, the id and name are expected attributes, even though they are optional. They should be accepted if passed along. Also profile, rule and security group should be allowed.
Screenshots
Request (working through API)

Response (working through API):

Environment (please complete the following information):

ISE version and patch: <IP_ADDRESS>8
Terraform version: Terraform v1.2.3
ISE provider version: 0.6.7-beta

Hey @wiwa1978 there's a new version of provider (0.6.8-beta), test it again let us know if it works for you.

Fixed!


Implement version flag

In accordance with https://github.com/sigstore/community/issues/16, implement a version flag

@lukehinds, I like to work on this.

fixed in #155


Different serialization behavior when using frozen models vs frozen dataclasses

Initial Checks

[X] I have searched GitHub for a duplicate issue and I'm sure this is something new
[X] I have searched Google & StackOverflow for a solution and couldn't find anything
[X] I have read and followed the docs and still think this is a bug
[X] I am confident that the issue is with pydantic (not my code, or another library in the ecosystem like FastAPI or mypy)

Description
It is impossible to serialize a pydantic model containing a set of frozen BaseModels but it is possible to serialize a pydantic model containing a set of frozen pydantic dataclasses.
Example Code
from pydantic import BaseModel
from pydantic.dataclasses import dataclass

class FrozenModel(BaseModel):
    field: str

    class Config:
        frozen = True

@dataclass(frozen=True)
class FrozenDataclass:
    field: str

class ModelWithSetOfModels(BaseModel):
    field: set[FrozenModel]

class ModelWithSetOfDataclasses(BaseModel):
    field: set[FrozenDataclass]

sample_frozen_model = FrozenModel(field="sample")
sample_frozen_model_set = ModelWithSetOfModels(field={sample_frozen_model})
sample_frozen_model_set.json()

"""
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In [7], line 3
      1 sample_frozen_model = FrozenModel(field="sample")
      2 sample_frozen_model_set = ModelWithSetOfModels(field={sample_frozen_model})
----> 3 sample_frozen_model_set.json()

File /usr/local/lib/python3.10/site-packages/pydantic/main.py:492, in pydantic.main.BaseModel.json()

File /usr/local/lib/python3.10/site-packages/pydantic/main.py:868, in _iter()

File /usr/local/lib/python3.10/site-packages/pydantic/main.py:794, in pydantic.main.BaseModel._get_value()

TypeError: unhashable type: 'dict'
"""

sample_frozen_dataclass = FrozenDataclass(field="sample")
sample_frozen_dataclass_set = ModelWithSetOfDataclasses(field={sample_frozen_dataclass})
sample_frozen_dataclass_set.json()

# '{"field": [{"field": "sample"}]}'

Python, Pydantic & OS Version
pydantic version: 1.10.2
            pydantic compiled: True
                 install path: /usr/local/lib/python3.10/site-packages/pydantic
               python version: 3.10.6 (main, Aug 23 2022, 08:36:38) [GCC 10.2.1 20210110]
                     platform: Linux-5.10.104-linuxkit-x86_64-with-glibc2.31
     optional deps. installed: ['dotenv', 'typing-extensions']

Affected Components

[ ] Compatibility between releases
[ ] Data validation/parsing
[X] Data serialization - .dict() and .json()
[ ] JSON Schema
[ ] Dataclasses
[X] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

@ldaniluk thank you for the bug report. Could you please confirm that the bug is still relevant in Pydantic v2?

The example works in Pydantic v2


How is this different in performance from Vysor?

Performance, and video quality are much better in scrcpy, also it has some useful features that Vysor don't. Check readme.md in repository.

Can I control my device from scrcpy?


Change build directory name

Hello,
When I made a npm run build creates a directory called build. Is it possible to change the name of that directory?
Thanks.

No, it is not. You can do something like this manually though as a post build step:
  "build": "react-scripts build",
  "postbuild": "mv build my-directory-name"

in scripts in package.json.