Instances of Vec2 created during execution

Hello, I'm justing started using ImGUI with your port and I realized that there are a lot of instances being created in my application.
I put just the demo window in my application and this is the result.
There is a solution for this behavior? Thank you

Hi,
yeah, Vec2 is the most common class in the project (you can see it also here)

There is a solution for this behavior? Thank you

The solution would be to switch all the classes to float fields, and change consequently all the function signatures, class properties and the code using those classes, also giving up on operator overloading and making code much more verbose, less similar to the original C++ and more error prone.
I never experienced problems with that, even on old laptops from 7/8 years.
But if it's a problem on your machine, if you want you may want to give a try and change all of that and see if you get any benefit in term of performances.
You could take care of a branch for that

Hi,
I'm sure I replied but I dont see my reply here, did you get it?

Hi,
yeah, Vec2 is the most common class in the project (you can see it also here)
There is a solution for this behavior? Thank you

The solution would be to switch all the classes to float fields, and change consequently all the function signatures, class properties and the code using those classes, also giving up on operator overloading and making code much more verbose, less similar to the original C++ and more error prone.
I never experienced problems with that, even on old laptops from 7/8 years.
But if it's a problem on your machine, if you want you may want to give a try and change all of that and see if you get any benefit in term of performances.
You could take care of a branch for that

Thanks for your answer.
I'm still evaluating the Project with ImGUI and two years ago I got a similar problem with buffers so I'm being cautious about memory usage =D
Hopefully, This will not be a problem.

I'm using chrome and everything is displayed fine now
Apparently the problem comes from Firefox..
Ps: what are you using?
Anyway, which kind of buffers? Because that may be a much more sensitive thematic
Also, take in account that most of the classesinstances will be taken out by compiler optimizations, such as escape analysis
Moreover:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.  (cit.)


(chore): Added Dynamic Banner Component for the Fourth theme

Signed-off-by: Abhijay Jain<EMAIL_ADDRESS>Description
Added Dynamic Banner Component for the Fourth theme
Resolves #383
Screenshots (In case of UI changes):

Desktop  View

Types of changes

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests have passed and it does not give any unexpected error for the same.

cc @dinithminura conflicts resolved


Segmentation Fault Caused by mhpmcounter10 Access Not Implemented in DUT and Spike

Hi,
The attached riscv-dv generated code attempts to access mhpmcounter10, which is not implemented in either the DUT or Spike. This results in a segmentation fault and the code fails. Below is the specific line of code causing the issue:
    800001b6:	b0aa15f3          	csrrw	a1,mhpmcounter10,s4

After this issue https://github.com/SpinalHDL/NaxRiscv/issues/121#issue-2439923743 I modified the number of HPM counters in Spike to ensure consistency between the DUT and Spike but that doesn't change anything:
https://github.com/SpinalHDL/riscv-isa-sim/blob/5b37ab699f6176ea7f2d2b3187f75625eca7e511/riscv/processor.h#L22
#define N_HPMCOUNTERS 7 //29

Results:

With the regression simulator:

./obj_dir/VNaxRiscv --name dv --output-dir failed --load-elf basic_test_1.o --start-symbol _start --pass-symbol pass --fail-symbol fail --no-putc-flush --seed 96102624 ${ARGS} --trace-ref

*** MISSMATCH PC DUT=80103000 REF=8010301c ***

TIME=574
LAST PC COMMIT=80103000
INCOMING SPIKE PC=80101bf8
ROB_ID=x1c
FAILURE dv

With RVLS using SocSim

[info] **************************************************
[info] DUT-PC =<PHONE_NUMBER>0001b6, REF-PC=800001b6, INST = b0aa15f3
[info] Debug: CSR_MHPMCOUNTER3 = 0xb03, CSR_MHPMCOUNTER31 = 0xb1f, csrAddress = 0xb0a, csrReadData = 0x0
[info] Warning: csrmap[0xb0a] is null. Skipping write.
[info] # A fatal error has been detected by the Java Runtime Environment:
[info] #
[info] #  SIGSEGV (0xb) at pc=0x00007ffa1f6e01e8, pid=2445164, tid=0x00007ffa68e47640
[info] #
[info] # JRE version: OpenJDK Runtime Environment (8.0_432) (build 1.8.0_432-8u432-ga~us1-0ubuntu2~22.04-ga)
[info] # Java VM: OpenJDK 64-Bit Server VM (25.432-bga mixed mode linux-amd64 compressed oops)
[info] # Problematic frame:
[info] # C  [rvls.so+0x3a91e8]  processor_t::get_csr(int, insn_t, bool, bool)+0x58
[info] #
[info] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
[info] #
[info] # An error report file with more information is saved as:
[info] # /media/big_dd/nanotrust/bi262934/naxriscv_tuleap/naxriscv_dv_vf/NaxRiscv/hs_err_pid2445164.log
[info] #
[info] # If you would like to submit a bug report, please visit:
[info] #   http://bugreport.java.com/bugreport/crash.jsp
[error] Nonzero exit code returned from runner: 134
[error] (Compile / runMain) Nonzero exit code returned from runner: 134
[error] Total time: 12 s, completed 10 déc. 2024 00:09:08

failed_test.zip
Could you please provide guidance on how to handle this mismatch or segmentation fault when accessing unimplemented HPM counters?
Thank you!

Hi,

With the regression simulator:

I would say, better focus on getting things ok with RVLS, and omit this one.

With RVLS using SocSim

So, when i have crashed happening in RVLS (when called from SpinalSim), then what i do, is to ask the testbench to generate the trace.log file (--trace argument should do it), which contains all the execution trace in the format RVLS is able to read.
Then with that trace.log file, i run RVLS in debug mode (in a standalone mode), with the -f trace.log argument.
There i can use regular C/C++ debug tools and figure out what is going wrong.
Just be sure to compile riscv-isa-sim in debug mode by adding :
CFLAGS='-g -O0' CXXFLAGS='-g -O0'
as arguments of the configure command
So in short, figuring out why RVLS crash is the first thing to do :)
It maybe due to that :
https://github.com/SpinalHDL/rvls/blob/b5c15e129f8168c2317b2c129aef91adf935bfeb/src/hart.cpp#L234
RVLS will syncronise the pmucounter on access, as they are hardware specific. Thing is your changes in riscv-isa-sim seems to deleted the extra counters ? (rvls assume their CSR is defined)
The implement intends of NaxRiscv is to match the RISC-V spec, but there may be a few missmatches.


feat: add a getProjectId method for google-auto-auth compat

google-auto-auth exposed a getProjectId method that's directly used by a lot of modules.  Just to make life easier, this adds a tiny shim.

Codecov Report

Merging #374 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #374      +/-   ##
==========================================
+ Coverage   94.76%   94.76%   +<.01%
==========================================
  Files          14       14
  Lines         955      956       +1
  Branches      198      198
==========================================
+ Hits          905      906       +1
  Misses         50       50

Impacted Files
Coverage Δ

src/auth/googleauth.ts
94.69% <100%> (+0.02%)
: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 b4d62a0...7a85aff. Read the comment docs.


#2 create a podspec

Added pod spec. Please, check if all details is correct. Also, don't forget to create brunch from master what will represent current pod version(I make it 0.1)

Sorry it took me so long to merge this, I totally forgot about it. Thanks for the contribution!


bug: Multiple blow outs do not work as expected

Overview

For use, sometimes one blow_out isn't enough to get rid of all the liquid. When I try calling it twice, nothing happens for the second one. I also tried to put a touch_tip before the second blow_out, thinking that might make it reset. It just does the touch tip and moves on to trash.
Steps to reproduce

In a protocol, write:
pipette.blow_out()
pipette.blow_out()

Current behavior

Tip is only blown out once.
Expected behavior

Tip is blown out, plunger goes up again, and blows out again.

Examined the code in question, and I can see why this behavior is happening. The first blow out leaves the plunger at the bottom of the pipette, in the blowout position. When the second blow out comes along, the plunger is told to move to the location that it's already at, so it does nothing.
I don't know why the plunger isn't reset as part of the blowout procedure (there might be a good reason not to do so), but that strikes me as a potential avenue to fix this.
In terms of a workaround, the only thing in the public API that is able to reset the plunger position is an aspirate. I wonder if something like this would work?
pipette.blow_out()
pipette.aspirate(volume=0.001)  # some tiny volume rather than `0`, since `0` means "as much as possible"
pipette.blow_out()

Thanks for the answer. I tried that just now. The aspirate makes the tip move up a little bit before aspirating and then back down for the second blow out. I thought aspirate with location=None was supposed to use the current position? Anyway, thanks for the workaround. I am happy to have this closed now, but maybe you want to keep it open to see about fixing bringing the plunger up immediately?

Since you say there might be a reason to not reset the plunger immediately after the blow out, how about checking if the plunger has to be brought up at the start of blow_out like aspirate does?

Thanks for the answer. I tried that just now. The aspirate makes the tip move up a little bit before aspirating and then back down for the second blow out. I thought aspirate with location=None was supposed to use the current position?

What you're hitting here is a particularly confusing (to me) piece of logic where, if the aspirate procedure decides the plunger needs to be reset due to a blowout, it tries to move to a "safe" location at the top of its current well before resetting the plunger. In this case, because you've used location=None, the procedure is pulling the "current well" from its last move.

Anyway, thanks for the workaround. I am happy to have this closed now, but maybe you want to keep it open to see about fixing bringing the plunger up immediately?

For sure keeping this ticket open! This is a bug and needs to be fixed; we're in the process of figuring out where the current behavior (don't reset plunger after blowout until aspirate time) comes from so we can implement the safest fix.

Since you say there might be a reason to not reset the plunger immediately after the blow out, how about checking if the plunger has to be brought up at the start of blow_out like aspirate does?

This is definitely on the list of available fixes. Might even be the most likely one!

Hi, just wanted to comment on this a little bit. I have a protocol that tries to do this:
# after dispensing some glycerol:

# 1 Residual liquid is removed with slower blow_out() at slower flowrate
p20multi.blow_out(well.bottom(mm))

# 2 move_to() from liquid to top of labware at 1-5 mm/s
p20multi.move_to(well.top(mmt), speed=vel_exit_liquid)

# 3 move_to() to bottom of labware at 10 mm/s speed to aspirate
p20multi.move_to(reservoir.wells_by_name()[reservoir_well_name].bottom(mm))

# 4 aspirate() (at slower flowrate)
p20multi.aspirate(20,
                 reservoir.wells_by_name()[reservoir_well_name].bottom(mm))

What happens here in practice is that the pipette goes to the bottom of the reservoir well as per step 3, but after that, since the plunger is still down after the blowout, it moves back to the top to (I guess) return the plunger to its default position, then waits there 10 seconds and then does step 4.
There's a bit of time waste there, but the big problem is that when it comes out the well between steps 3 and 4, the pipette is full of glycerol and that glycerol ends up absorbed , so the pipette ends up dispensing 21 or so uL instead of 20.
If I didn't explain myself clearly I'm happy to clarify. The thing is, this can become a big problem and, if you don't figure it out early, a big headache. I'm surprised that this hasn't been fixed yet as of September 2021.

Hey @silvtal, in this case, why is the (3) move_to call needed? Setting aside the behavior of "blow out reset doesn't happen until next aspirate" behavior, I would expect p20multi.aspirate(20, reservoir.wells_by_name()[reservoir_well_name].bottom(mm)) to work without the preceding move_to. By itself, the aspirate call should:

Move to top of well to reset plunger after blowout (might be a no-op because of the preceding move in (2)
Reset plunger motor
Move to the bottom(mm) position
Perform the aspiration

Is it not doing that, or is there something about how it's doing that that's not working for your needs?

I'm surprised that this hasn't been fixed yet as of September 2021.

After my last comment in the thread, I shopped this around internally, and we're sort of in a difficult spot with blow-out. In general, protocol API v2 has some fairly fundamental architectural limitations that make changes like this a little fraught. Where that comes up with blow-outs specifically is: it's pretty difficult for the robot to know the answer to the question "is the pipette tip currently in liquid?"
This is a really important question when it comes to resetting after a blow-out, because if you answer the question incorrectly, you risk damaging the pipette hardware itself by sucking up liquid into the internals. The current behavior, while annoying a lot of the time, is a way of ensuring we pick a reliably not-risky spot to perform the plunger reset in the architecture we currently have.
We're in the middle of an overhaul of the protocol execution engine with the goal of making these sort of changes much less risky. But as it turns out, re-writing our the execution engine to address core architectural limitations while keeping everything else working takes... a lot more time than I thought 🙃. We are working on it, though! I recommend following along with the protocol-engine issue label if you're curious about watching this work progress

Thank you for your hard work. As for your question,
why is the (3) move_to call needed?
you're absolutely right and I skipped that step in my updated code. The only reason I included that step is because I took that idea verbatim from your latest glycerol handling webinar, see page 13. https://f.hubspotusercontent30.net/hubfs/5383285/Automating-Viscous-Liquid-Handling_09-09-2021_Opentrons-Webinar-slides.pdf?utm_campaign=2021_Webinars_Viscous-Liquids_09-09-2021&utm_medium=email&_hsmi=157751988&_hsenc=p2ANqtz-94wprFwoIxGOjyCNCuaoELTtZsI5g7KMg3hjTmRhDyFONRlxSudmZPEhknhKV7knvLpoiWQz5den2lrEm1NrgORlLOmg&utm_content=157751988&utm_source=hs_email . Note that they also included a blow_out step in the dispense part, so this issue was bound to happen if you do sequential aspirate-dispense steps.
I don't have the OT2 here right now so I can't check, but I guess aspirate would move to the .top(0) (or whatever the default is) of the reservoir instead of .top(mmt). So in order to keep the .top(mmt) height I might need to do a aspirate(0.001,well.top(mmt)) to reset the plunger "manually" first. Thank you again for that workaround idea


Incorporate Nested Groups into demo data

This link may be helpful - https://developers.mattermost.com/blog/2019-06-05-ldap-nested-groups-modelling-and-representation-in-code/

Sorry, wrong project :(


[NETBEANS-731] Rename AutoHidingMenuBarManualTest to fix test failure

This avoids a "No runnable methods" error while running tests in the core.windows package, due to the AutoHidingMenuBarManualTest class having a name that ends with "Test" but no test methods in it. The class in question is kept around for manual testing purposes only, and is not intended to be run automatically. See https://github.com/apache/incubator-netbeans/pull/1060 .

The Travis build succeeded, and the patch fixes the test locally on my machine, so I will now merge this and verify that the test no longer fails after Jenkins does its job.


Allow Traffic shaping through header based routing for ALB

Signed-off-by: Andrii Perenesenko<EMAIL_ADDRESS>Checklist:

[ ] Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
[ ] The title of the PR is (a) conventional, (b) states what changed, and (c) suffixes the related issues number. E.g. "fix(controller): Updates such and such. Fixes #1234".
[ ] I've signed my commits with DCO
[ ] I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
[ ] My builds are green. Try syncing with master if they are not.
[ ] My organization is added to USERS.md.

Codecov Report

Merging #3 (3c7c194) into master (03b7f5e) will increase coverage by 0.01%.
The diff coverage is 78.04%.

@@            Coverage Diff             @@
##           master       #3      +/-   ##
==========================================
+ Coverage   82.19%   82.21%   +0.01%
==========================================
  Files         121      121
  Lines       17865    18390     +525
==========================================
+ Hits        14684    15119     +435
- Misses       2415     2485      +70
- Partials      766      786      +20

Impacted Files
Coverage Δ

utils/ingress/ingress.go
92.14% <25.00%> (-7.86%)
:arrow_down:

rollout/trafficrouting/alb/alb.go
75.43% <70.52%> (-7.03%)
:arrow_down:

utils/defaults/defaults.go
89.10% <80.00%> (+0.74%)
:arrow_up:

ingress/alb.go
93.40% <90.90%> (-3.15%)
:arrow_down:

pkg/apis/rollouts/validation/validation.go
95.57% <95.65%> (-0.11%)
:arrow_down:

utils/ingress/wrapper.go
91.43% <97.64%> (+2.18%)
:arrow_up:

analysis/controller.go
48.48% <0.00%> (-3.69%)
:arrow_down:

experiments/controller.go
65.75% <0.00%> (-1.54%)
:arrow_down:

... and 16 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Automated js dependency update | Tue, 15 Oct 2019 15:00:18 +0000

not a real pull request. closing.


Support is_default_shipping/billing_address for address API

It will be nice to display if an address is user's default shipping/billing address in address API. This PR adds this support. It will be easier for the frontend to display whether an address is default shipping/billing address in address list page.
Pull Request Checklist

[ ] Privileged views and APIs are guarded by proper permission checks.
[ ] All visible strings are translated with proper context.
[ ] All data-formatting is locale-aware (dates, numbers, and so on).
[x] Database queries are optimized and the number of queries is constant.
[x] Database migration files are up to date.
[x] The changes are tested.
[x] The code is documented (docstrings, project documentation).
[x] GraphQL schema and type definitions are up to date.
[x] Changes are mentioned in the changelog.

@maarcingebala This PR is updated :handshake:

@jxltom Could you resolve changelog conflicts? You could as well rebase this branch with master.

Sure, I merged the upstream master as it is easier to solve the conflicts.


Progress bar

General information:

emcee version: 3.1.4
platform: Rocky Linux 8.6
installation method (pip/conda/source/other?): pip

Problem description:
I'm running emcee on a cluster using MPI. I use the option progress = True, but its output goes to in the .err file instead of the .out file. How can I fix it?
Expected behavior:
The output of the progress bar goes to the .out file.
Actual behavior:
The output of the progress bar goes to the .err file.

Thanks for asking - this is the expected behavior! The progress bar is rendered to stderr by design. This progress bar is generated using tqdm, and you can pass arbitrary arguments to the tqdm.tqdm constructor (ref) using the progress_kwargs argument to sample or run_mcmc, so you may be able to have tqdm write to stdout if that's a behavior that you'd want, but I don't expect to support that out of the box in emcee.


exist-ls crashes when it encounters a collection the user is not permitted to access

EXISTDB_USER=guest \
EXISTDB_PASS=guest \
exist-ls --extended /db/system

will crash with
exerr:ERROR Permission to retrieve permissions is denied for user 'guest' on '/db/system/security': Permission denied to open collection: /db/system/security by guest

It is unclear if this is something we can fix other than work around the limitation imposed by existdb.

The successor https://github.com/line-o/xst will now exclude entries that the current user has no access to.


String Error

What is the output link of /viaversion dump?

Are you using any additional software like BungeeCord? If so, what software and version? (Please list your plugins as well)
BukkitCraft, (1.8.8)
ViaVersion 1.0.3 (Version 1.0.1 gives me the same error)
WorldEdit
PeX
Multiverse Core and Portals
BanItem
Chairs
Essentials Chat, Spawn
GriefPrevention
Modifyworld
PerWorldPlugins
statuecreator
How does this error happen? login? Using an item?
Not everytime when i'm logging in... but the most of the time
Is there an error in the console? Use pastebin.com. Is there a kick message?
25.12 20:11:08 [Server] INFO {Type: MetaData List, Source #0: us.myles.ViaVersion.protocols.protocol1_9to1_8.packets.SpawnPackets$5 (Anonymous), Data: [Pair{Type|VarInt, 255}, Pair{Type|UUID, 96940a72-b705-4d4e-b695-d84feea1ebc5}, Pair{Type|Unsigned Byte, 95}, Pair{Type|Double, 111.5625}, Pair{Type|Double, 4.0}, Pair{Type|Double, 37.75}, Pair{Type|Byte, 116}, Pair{Type|Byte, 0}, Pair{Type|Byte, -23}, Pair{Type|Short, 0}, Pair{Type|Short, -627}, Pair{Type|Short, 0}], Packet ID: 3}
25.12 20:11:08 [Disconnect] User otaku1101 has disconnected, reason: Internal Exception: io.netty.handler.codec.EncoderException: us.myles.ViaVersion.exception.InformativeException: Please post this error to http://github.com/MylesIsCool/ViaVersion/issues
25.12 20:11:08 [Server] ERROR io.netty.handler.codec.EncoderException: String too big (was 36000 bytes encoded, max 32767)
25.12 20:11:08 [Server] ERROR io.netty.handler.codec.EncoderException: String too big (was 36000 bytes encoded, max 32767)
Kick Message:
Disconnected
The Error is completly new for me. The server is running since 3 Weeks without any problem. I haven't changed anything...

Fixed
World was brocken


Add report page

Only includes donation report for the time being.
Now that there's more than one page, it would be nice if we could fix #6 (and #3)

I also want to add a time slot load report.


Notary V1 Integration

This is really good PR and really does a good job of implementing the notary integration without unnecessary complexity. The exact mechanics/terminology of how notary signs images is still a bit murky for me. Could you walk through that again at somepoint?

This is really good PR and really does a good job of implementing the notary integration without unnecessary complexity. The exact mechanics/terminology of how notary signs images is still a bit murky for me. Could you walk through that again at somepoint?

Sounds good. I'll create a summary in the PR description.


Remove override of createJSModules

Since of recently in master the unused createJSModules has been removed and ReactPackage's no longer contain the definition of createJSModules. There for it must be removed in order to not yield a compile error. This is breaking change.
https://github.com/facebook/react-native/commit/ce6fb337a146e6f261f2afb564aa19363774a7a8

Can we get some attention here? @fov42550564


FEATURE - New slash command feature suggestions

Suggestions:
Add some cool free API to zorak with a slash command?
Create a minigame? Maybe its singleplayer? Maybe its multiplayer? Reaction game or card game?

There is also a started blackjack game in source code


Type Error fido2GetCredential in Safari

Hi, I've integrated this lib and so far is working great for chrome and Firefox, but we are having issues with safari when getting the credentials because it is throwing a super ambiguous error (attached in the image) from the function fido2GetCredential in fido2.js:214, this is const credential = await credentialsContainer?.get({         publicKey,     }); I've confirmed that the publicKey object is the same in chrome and safari.

Mmmmm doesn't ring a bell yet.
I'm a Safari 17.6, you?
What version of the Passwordless lib are you on?
Bread crumb: const credential = await credentialsContainer?.get({ publicKey, }); that is not the code of this lib. You using a password manager or so that is injecting itself "transparantly"? Say 1Pasword?

Just saw this, try that? Set residentkey (can be set when you call Passwordless.configure on the front end)
https://stackoverflow.com/questions/75350756/getting-type-error-when-using-webauthn-on-ios

Which macOS / iOS version are you on ?

OK that should be good.
Tried this yet?
Passwordless.configure({
  cognitoIdpEndpoint: import.meta.env.VITE_COGNITO_IDP_ENDPOINT,
  clientId: import.meta.env.VITE_CLIENT_ID,
  fido2: {
    baseUrl: import.meta.env.VITE_FIDO2_BASE_URL,

    authenticatorSelection: {
      userVerification: "required",
      requireResidentKey: true, // added
      residentKey: "required", // added
    },
  },
  debug: console.debug,
});

authenticatorSelection is not a valid field for navigator.credentials.get(), see https://www.w3.org/TR/webauthn-2/#dictdef-publickeycredentialrequestoptions.
It is a valid field for navigator.credentials.create(), see https://www.w3.org/TR/webauthn-2/#dictdef-publickeycredentialcreationoptions
What exactly is your situation? You can create the passkey, but not sign-in with it? Or the create already fails?

I just tried the end-to-end example again on Safari 17.6 (196<IP_ADDRESS>.5) on MacOS Sonoma 14.6.1 and it works like a charm for me, both for my Mac's touch as with a Yubikey.
That's with this config, unchanged per the end-to-end example:
Passwordless.configure({
  cognitoIdpEndpoint: import.meta.env.VITE_COGNITO_IDP_ENDPOINT,
  clientId: import.meta.env.VITE_CLIENT_ID,
  fido2: {
    baseUrl: import.meta.env.VITE_FIDO2_BASE_URL,
    authenticatorSelection: {
      userVerification: "required",
    },
  },
  debug: console.debug,
});

Can you also try to deploy the end-to-end example and try that one?
Otherwise send me your email address please I can add you to my instance as well as user. Then we can try you creating a passkey and logging in with that to my sample deployment and I can have a look in dynamodb at what's different between your fido credentials and mine.

Done, sent you an SES verification mail (please click the link) and then you can sign in here with a magic link, after which you can create a passkey and sign in with that: https://dgn579m3u5x3n.cloudfront.net/

I can't quickly find a source for this info but I remember safari has a quirk. Safari requires the webauthn API call to be made in an event directly triggered by the user, like a click. At which point and how are you invoking the Passwordless lib? In an onclick handler?

This post mentions it and I came across it myself as well earlier. https://www.linkedin.com/posts/timcappalli_introducing-passkey-support-to-fastmail-activity-7234553443154092032-1Y2T?utm_source=share&utm_medium=member_ios

Yes you can await the authenticateWithFido2().signedIn promise to get the error in your face bubbled up, or rely on the lastError variable in the hook.

Frustrating!
I have no ideas left at this point.
Suggest to try the Webauthn calls directly (navigator.credentials.get()) and see if that works. If not--file the issue with Apple against Safari. If that does work, we'd need to figure out why our lib fails for you (but not in our own example, so weird!).

Any update mate?

Thanks for getting back ! Good news 🎉


Aborted due to the lack of CPU swap space, but there is enough RAM and swap

Ubuntu 22.04 (up to date, recently installed)
nVidia 4090
CUDA 11.8
cuDNN <IP_ADDRESS>
vLLM compiled from source: d1744376
Model: ehartford/dolphin-llama2-7b
llm = LLM(model=model_path, dtype='bfloat16')
sampling_params = SamplingParams(n=50, max_tokens=600, temperature=0.2, top_p=0.95)
results = llm.generate(prompts, sampling_params, use_tqdm=True)

200 prompts were prepared according to the model card's prompt template.
The point of failure seems to be random.
There is enough memory and swap. I don't know why it even requires any swap...
$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi       5,8Gi        13Gi        45Mi        43Gi        56Gi
Swap:           31Gi       787Mi        31Gi

Nor the memory, not the swap use spikes/changes at all when the failure happens. Monitored it with 1s period.
Full exception:
...
  File "/home/viktor/ts/venv/lib/python3.10/site-packages/vllm-0.1.3-py3.10-linux-x86_64.egg/vllm/entrypoints/llm.py", line 130, in generate
  File "/home/viktor/ts/venv/lib/python3.10/site-packages/vllm-0.1.3-py3.10-linux-x86_64.egg/vllm/entrypoints/llm.py", line 150, in _run_engine
  File "/home/viktor/ts/venv/lib/python3.10/site-packages/vllm-0.1.3-py3.10-linux-x86_64.egg/vllm/engine/llm_engine.py", line 300, in step
  File "/home/viktor/ts/venv/lib/python3.10/site-packages/vllm-0.1.3-py3.10-linux-x86_64.egg/vllm/core/scheduler.py", line 251, in schedule
  File "/home/viktor/ts/venv/lib/python3.10/site-packages/vllm-0.1.3-py3.10-linux-x86_64.egg/vllm/core/scheduler.py", line 197, in _schedule
  File "/home/viktor/ts/venv/lib/python3.10/site-packages/vllm-0.1.3-py3.10-linux-x86_64.egg/vllm/core/scheduler.py", line 360, in _preempt
  File "/home/viktor/ts/venv/lib/python3.10/site-packages/vllm-0.1.3-py3.10-linux-x86_64.egg/vllm/core/scheduler.py", line 385, in _preempt_by_swap
  File "/home/viktor/ts/venv/lib/python3.10/site-packages/vllm-0.1.3-py3.10-linux-x86_64.egg/vllm/core/scheduler.py", line 406, in _swap_out
RuntimeError: Aborted due to the lack of CPU swap space. Please increase the swap space to avoid this error.
Processed prompts:  12%|█▏        | 23/200 [00:55<07:05,  2.41s/it]

There is a FIXME in vLLM code (core/scheduler.py) where the problem happens.
I guess there is a bug causing this issue in the first place.
            # FIXME(woosuk): Abort the sequence group instead of aborting the
            # entire engine.
            raise RuntimeError(
                "Aborted due to the lack of CPU swap space. Please increase "
                "the swap space to avoid this error.")

Sending the prompts in batches of 8 seems to work so far without crashing.
But doing this goes against the advice in the docstring of the generate method:
        NOTE: This class automatically batches the given prompts, considering
        the memory constraint. For the best performance, put all of your prompts
        into a single list and pass it to this method.

I also figured the "CPU swap" is not the disk swap, but part of your logic. I do not know (yet) how to increase the size of that.

I also run into this problem with much free memory. Hopefully there's a simply patch...

I think the users can set the CPU swap space here: https://github.com/vllm-project/vllm/blob/d1744376ae9fdbfa6a2dc763e1c67309e138fa3d/vllm/engine/arg_utils.py#L26

I think the users can set the CPU swap space here:
https://github.com/vllm-project/vllm/blob/d1744376ae9fdbfa6a2dc763e1c67309e138fa3d/vllm/engine/arg_utils.py#L26

Thanks @puddingfjz ! I will look into that.
So the swap space in vllm actually refers to a reserved memory space (per gpu)?

I think it is for the CPU swap space. (not sure what it means in multi-gpu scenario)

            # FIXME(woosuk): Abort the sequence group instead of aborting the
            # entire engine.
            raise RuntimeError(
                "Aborted due to the lack of CPU swap space. Please increase "
                "the swap space to avoid this error.")

I think implementing the above FIXME and exposing the swap_space: int = 4  # GiB value as a configuration value would solve this issue.

so how exactly can I edit this?
If i open the file in /.conda/sitepackages etc. there doesn't seem to be any change in what the notebook calls.

I think the users can set the CPU swap space here:
https://github.com/vllm-project/vllm/blob/d1744376ae9fdbfa6a2dc763e1c67309e138fa3d/vllm/engine/arg_utils.py#L26

The LLM class has a swap_space argument on construction.
If you use the command line argument try to use the --swap-space argument (default is 4, unit is GB).

so how exactly can I edit this?
If i open the file in /.conda/sitepackages etc. there doesn't seem to be any change in what the notebook calls.

I think the users can set the CPU swap space here:
https://github.com/vllm-project/vllm/blob/d1744376ae9fdbfa6a2dc763e1c67309e138fa3d/vllm/engine/arg_utils.py#L26

At present, we have found a workaround and set the swap space directly to 0. This way, we will not call the CPU swap space and will not report any errors. However, the CPU blocks will also become 0, which may slow down the speed a bit, but at least it will not hang and die.

Hi, I've tried to set swap_space=0 but I'm still getting the error.
I'm using
Ubuntu 18.04
A100 GPU
CUDA 12.2
vLLM version 0.2.7
Model codellama/CodeLlama-7b-hf

            # FIXME(woosuk): Abort the sequence group instead of aborting the
            # entire engine.
            raise RuntimeError(
                "Aborted due to the lack of CPU swap space. Please increase "
                "the swap space to avoid this error.")

I think implementing the above FIXME and exposing the swap_space: int = 4 # GiB value as a configuration value would solve this issue.我认为实现上述 FIXME 并将swap_space: int = 4 # GiB值公开为配置值可以解决此问题。

Hi,How to implementing the above FIXME?

Hi, I've tried to set swap_space=0 but I'm still getting the error.你好，我尝试设置swap_space=0但仍然收到错误。
I'm using 我正在使用 Ubuntu 18.04 乌班图18.04 A100 GPU A100显卡 CUDA 12.2 杂项 12.2 vLLM version 0.2.7 vLLM版本0.2.7 Model codellama/CodeLlama-7b-hf型号codellama/CodeLlama-7b-hf

Hi,Do you fix it?


Add meeting notes template link to website

Add a "Meeting Notes Template" link to the resources page https://thenewboston.com/teams/All/Resources on the website.
Link - https://docs.google.com/document/d/15P7MPPGgC2O3ZhOWryOeuW1K5EO9TL8_TBWR4Z2-_eo/edit?usp=sharing

@thesanjeevsharma @jamessspanggg could one of you guys look into this?


Win CLI tests

:construction:

Codecov Report

Merging #1582 (526b2e0) into main (f87ffb9) will decrease coverage by 52.87%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #1582       +/-   ##
==========================================
- Coverage   61.49%   8.61%   -52.88%
==========================================
  Files         167      83       -84
  Lines       12293    8081     -4212
==========================================
- Hits         7559     696     -6863
- Misses       3761    7340     +3579
+ Partials      973      45      -928

Flag
Coverage Δ

acceptance-api
?

acceptance-apps
?

acceptance-cli
?

unittests
8.61% <ø> (-0.01%)
:arrow_down:

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

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


[Feature Request] Output data returned from az login command

I would like to obtain the data returned from the az login command that the github action performed.
Specifically, after logging in I would like to obtain the objectId of the principal, so that I can use it for role assignments.
Alternatives considered:

~get it with another call like az ad signed-in-user show --query id -o tsv but that requires a redundant call~ this does not work when azure/login was used with a managed identity and OIDC
pass the objectId as a parameter / env var
use az identity show -n <someName> --resource-group <someRg> --subscription <subscriptionID> --query principalId -o tsv

We have marked it as an enhancement and will prioritize accordingly. Thanks!

A similar feature request was created for Azure CLI itself: https://github.com/Azure/azure-cli/issues/22776
The easiest way to get the object ID of the sign-in identity without additional HTTP call is to decode the access token and look for the oid claim. However, this approach is discouraged by security team and OAuth definition. For details, see https://github.com/Azure/azure-cli/issues/22776#issuecomment-1420236057

Closing this issue for now. Let's track this feature request in https://github.com/Azure/azure-cli/issues/22776.


fix SDK style projects not being able to find system dacpacs

This PR fixes https://github.com/microsoft/azuredatastudio/issues/18040 so system dacpac references aren't broken while we figure out if system dacpacs can be included in the SDK. This changes the name of the variable for the location of system dacpacs for SDK projects (NETCoreTargetsPath didn't really make sense since the path is only being used for the system dacpacs) and updates the build command to pass in the location for this new variable.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

3 of 3 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.004%) to 48.304%

Totals

Change from base Build<PHONE_NUMBER>:
0.004%

Covered Lines:
14789

Relevant Lines:
29075

💛  - Coveralls


Changes to styles should update input values in editor controls

Because we enable multiplayer on sprout, we have a situation where another user can edit style values while you have the editor open. We put the style object in shared state to enable this. Everything mostly works, except the values in the text inputs don't update with the style changes. The color input shows live changes as I would expect, but the text inputs do not.

@GrantCuster thanks for flagging will try to take a look at this soon.

Noting some implementation details:
Where we use React's useReducer hook to simplify some relatively complex state changes, we should actually be using a state machine here so the input can be updated when state changes from elsewhere and propagates back down to the input.


Wrong crc16-ccitt return value?

Hi,<PHONE_NUMBER>5F676574400D0A should return crc 5288. Using the following code I get the wrong value:
var crc16 = crc.crc16ccitt(new Buffer('66236366675F676574400D0A','hex')).toString(16); //73E1

Reading the documentation of how to calculate crc from this HEX and get 10F2 It said that It uses the following C code:
unsigned short crc_16_rec(unsigned char * pucData, unsigned short ucLen) {
  //--------------------------------------------------------------------
  unsigned int i;
  unsigned char ucBit, ucCarry;
  //--------------------------------------------------------------------
  unsigned short usPoly = 0x8408; //reversed 0x1021
  unsigned short usCRC = 0;
  //--------------------------------------------------------------------
  for (i = 0; i < ucLen; i++) {
    usCRC ^= pucData[i];
    for (ucBit = 0; ucBit < 8; ucBit++) {
      ucCarry = usCRC & 1;
      usCRC >>= 1;
      if (ucCarry) {
        usCRC ^= usPoly;
      }
    }
  }
  return usCRC;
}

Is the polynimial different? Whats causing this issue?
edit:
Sorry, I've made a slight error, the result shouldn't be 0x10F2 as I've said before It should be 0x5288
Thank you.

I have a working example of this C++ code here.

Have you tried running the same value through pycrc? I'm curious what the result would be.

from PyCRC.CRC16 import CRC16
from PyCRC.CRC16DNP import CRC16DNP
from PyCRC.CRC16Kermit import CRC16Kermit
from PyCRC.CRC16SICK import CRC16SICK
from PyCRC.CRCCCITT import CRCCCITT

#input = b'\x05d\x05\xc0\x00\x01\x00\x0c'
input = b'\x66\x23\x63\x66\x67\x5F\x67\x65\x74\x40\x0D\x0A'
print(CRC16().calculate(input))
print(CRC16DNP().calculate(input))
print(CRC16Kermit().calculate(input))
print(CRC16SICK().calculate(input))
print(CRCCCITT().calculate(input))

The results are:

30830
8303
34898
6672
63256

Whilst It should be 21128 (DEC) or 0x5288 (HEX)

I'm not really sure what to suggest here... There are two possible explanations, either pycrc has wrong implementation or something is up with the example code you are using.
$ ./pycrc.py --check-hexstring=66236366675F676574400D0A --model=ccitt
0x73e1

You can also check what the C code would look like that is produced by pycrc, something like this
./pycrc.py --generate=c --model=ccitt --algorithm=bbb

There are a few other algorithm options available that might closer match your example.


MolDraw2D wedge bonds

Hello!
I was surprised to find that MolDraw2D is not able to draw wedged bonds in contrast to Draw.MolToImage. Is there any way to display stereochemistry using MolDraw2D?

Hmm, MolDraw2D can draw wedged bonds. How are you invoking it?

I used the code below:
`from rdkit import Chem
from rdkit.Chem import rdDepictor
from rdkit.Chem.Draw import rdMolDraw2D
from IPython.display import SVG
smiles = '[*]O[C@@H]1OC@@HC@HC@@H[C@H]1O'
mol = Chem.MolFromSmiles(smiles)
rdDepictor.Compute2DCoords(mol)
drawer = rdMolDraw2D.MolDraw2DSVG(500,320)
drawer.DrawMolecule(mol)
drawer.FinishDrawing()
svg = drawer.GetDrawingText().replace('svg:','')
SVG(svg)`
that produce the image without stereo-info. Then I tried to find the appropriate parameters in DrawMolecule method and MolDrawOptions object, but unsuccessfully, and I have no idea where to find it
￼

My apologies, I haven't seen PrepareMolForDrawing function. Thanks for the help!

Yep, that one's the key. Glad you found it!


SCE-1170 [2/2]: memcached-cat example results including CMT/MBM metrics

Fixes issue "no README and no example results of memcached-cat experiment'
please use this link to see results
Summary of changes:

just a pictures without full experiment description and without conclusions

Testing done:

no - just docs

run integration tests


Add local debugging

[ ] docs/readme.md
[ ] docs/ml_tasks.md
[ ] examples

See: https://github.com/SubstraFoundation/substra/pull/177

Added with #102


Improve delete command to delete multiple persons

Closes #24.

Changes Unknown when pulling 4f9079552cfc81a63f319260d76bb95e4a234b2a on johnweikangong:Enhancement into ** on CS2103AUG2017-T16-B3:master**.

Changes Unknown when pulling 4f9079552cfc81a63f319260d76bb95e4a234b2a on johnweikangong:Enhancement into ** on CS2103AUG2017-T16-B3:master**.


[SPARK-49128][CORE] Support custom History Server UI title

What changes were proposed in this pull request?
This PR aims to support custom History Server UI title via a new configuration, spark.history.ui.title.
Why are the changes needed?
Like Spark Master UI, it's helpful to provide an easily distinguishable information when there are multiple Spark history server.

https://github.com/apache/spark/pull/47491

Does this PR introduce any user-facing change?
No, this is a new feature.
How was this patch tested?
Pass the CIs with newly added test case.
Was this patch authored or co-authored using generative AI tooling?
No.

Could you review this PR, @viirya ?

Thank you, @viirya !

Merged to master.

Thank you, @yaooqinn and @HyukjinKwon !


[AutoComplete] Fix filter property leaking

[ ] PR has tests / docs demo, and is linted.
[x] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[x] Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

Fix https://github.com/callemall/material-ui/issues/4195.

@AJIh Could you have a look at this PR? It should fix your issue with the server-side rendering.

Thanks! 😊
I have added some comments and tests. Should I open a new PR in this repo or your fork?

@AJIh You want to improve this PR? Sure! You have two options:

You can push on this branch, I have given you access to my fork
You can submit another PR with this commit.

Or you can submit a PR to @oliviertassinari fork, which he can review and merge, that will become part of this PR (you will still be credited as the author of the additions).

@oliviertassinari Done! I have submitted a PR to your fork.

@AJIh I have added your test here. Thanks 👍.

I'm going ahead and merging this PR. The core of this PR is one line change. Let's move fast 🚀 .


implement accurate slider

@David--K I've implemented the slider as discussed. The tests are not yet complete, but this should suffice for you to implement it in the UI. Merge at your discretion, should it suffice for now, so that this does not block you.
Thanks!


Custom Socket Names Not Working

5.0.1 release candidate from the Discord, Spigot 1.13.2
Editing the socket-name in the socketting file stops the socket gems from working at all.
For example if I have it set to &5Power Gem - &6%socketgem% it works fine, however if I even change it just to&5Power Gem &7- &6%socketgem% the gems no longer do anything.
Ideally I'd like to be able to have custom symbols in it as well, such as having it as &6✧ &5Power Gem &6✧ &7-- &d%socketgem% due to having item drop names visible - the plugin parses the symbol fine and the item is given with the symbol, but as above due to the altered name it does nothing.

Just a quick check, are you spawning a socket gem with the name format &5Power Gem - &6%socketgem%, then changing the socket-name field, and then the socket gem you spawned isn't working? Or is it

Spawn socket gem with name format &5Power Gem - &6%socketgem%
Use socket gem successfully
Change socket-name field and restart server
Spawn socket gem with name format &5Power Gem &7- &6%socketgem%
Socket gem doesn't work

It's as you step-by-stepped it - set it up with the socket gem name formatted as &5Power Gem - &6%socketgem%, restarted and spawned one in and it works fine.
Edited the socket gem name in the files to &5Power Gem &7- &6%socketgem% (or any other variation that adds extra colours or symbols beyond a colour at the start and before the socket gem name variable as far as I can tell) and then save changes and restart, then spawn a new gem in and it does nothing (I did both a server restart and an /md reload to see if it made any difference, does it either way)

I have found the place where the issue is being caused - it's a bit of a weird one. I'll have this fixed for 5.1.1 as well.

Awesome - thank you!


feat: Favorite queries

Allow users to 'favorite' queries
Issue #119

Codecov Report

Merging #520 (e1fa223) into master (b1d3997) will decrease coverage by 0.02%.
The diff coverage is 95.65%.

@@            Coverage Diff             @@
##           master     #520      +/-   ##
==========================================
- Coverage   96.55%   96.53%   -0.03%
==========================================
  Files          52       54       +2
  Lines        2238     2306      +68
==========================================
+ Hits         2161     2226      +65
- Misses         77       80       +3

Impacted Files
Coverage Δ

explorer/urls.py
100.00% <ø> (ø)

explorer/views/query_favorite.py
90.00% <90.00%> (ø)

explorer/migrations/0011_query_favorites.py
100.00% <100.00%> (ø)

explorer/models.py
98.42% <100.00%> (+0.04%)
:arrow_up:

explorer/tests/test_views.py
100.00% <100.00%> (ø)

explorer/views/__init__.py
100.00% <100.00%> (ø)

explorer/views/utils.py
100.00% <100.00%> (ø)

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

@marksweb let me know if you have any questions or tweaks to this

Thanks @lawson89!

@lawson89 will take a look as soon as possible.
That test has failed because Django's main branch has moved on to v5 after they released the 4.2 alpha. And v5 needs a minimum of python 3.10, so I need to update the test suite.

@lawson89 I've updated the test suite for django 4.1 alpha and django 5 (main). Could you rebase your branch please? I can't update from here.

@marksweb done. Not sure why precommit fails, flake8 passes for me?

@lawson89 It's likely parts of the project that aren't part of this PR.
The CI bot will check everything and there's a good chance I've added pre-commit but not yet ran it against the existing codebase. I'll take a look and there might be another update to master that needs rebasing soon.

@lawson89  Ok I've updated master with pre-commit having fixed everything in it's checks. Rebase your branch and all will pass 👍

@lawson89 Thanks for all your work on this!


Parsing the log topics for events (filter_log) may fail depending on the "indexed" inputs in the ABI

Hey there  :)
I just noticed that filter_log sometimes misses events, in the Python SDK.
If the ABI used to trigger the event doesn't exactly match the ABI used to parse, filter_log fails.
In particular, developers are free to choose which event arguments are indexed.
For example the following event:
event Transfer(address indexed from, address to, uint256 value);

Will not be matched by an ABI built for:
event Transfer(address indexed from, address indexed to, uint256 value);

This can be identified by catching LogTopicError exceptions in filter_log, like:
Expected 2 log topics.  Got 1

So far I'm working around this issue locally & manually with custom parsing.
I have a few propositions to handle this issue.
Solution 1: passing all the ABI variants as inputs
First, generate all the variants of the ABI with each input "indexed" flag switch on and off:
def generate_all_abi_indexation_variants(abi: ABIEvent) -> dict:
    """Generate all the variants of the ABI by switching each "indexed" field true / false for the inputs."""
    _count = len(abi.get('inputs', ()))
    _indexed = tuple(itertools.product(*(_count * ((True, False), ))))
    _abis = {_c: [] for _c in range(_count + 1)} # order by number of indexed inputs
    for _i in _indexed: # each indexation variant
        _abis[sum(_i)].append(_apply_indexation_mask(abi=abi, mask=_i))
    return _abis

Then it could be used directly with the current filter_log:
_abis = generate_all_abi_indexation_variants(abi=abi)
tx.filter_log(list(_abis.values())) # tx is a TransactionEvent

Pros
This solution will always work!
It doesn't require any modifications on filter_log since it already handles lists of ABIs.
Cons
It comes at the cost of performances.
With only 3 input arguments in the ABI, there would be 8 variants and the computation would be 8x slower.
Solution 2: Use only the relevant ABI variants
In the snippet above, the variants are sorted by number of indexed inputs.
This could allow to reduce the computation time and only use the variants that match the number of topics.
Inside filter_log, select only the matching ABIs:
_abi = abi.get(len(log['topics']) - 1, None)
contract = web3Provider.eth.contract("0x0000000000000000000000000000000000000000", abi=_abi)
for event_name in event_names:
    try:
        results.append(
            contract.events[event_name]().processLog(log))

filter_log could be modified to handle dict, list and a single ABI value.
Pros
Less processing than solution 1: instead of growing exponantially with inputs, now it's "only" one of the binomial coefficient.
Cons
filter_log would have to be reworked.
Solution 3: using the most probable ABI
Here, the idea would be to generate only one ABI per number of indexed inputs.
For example, the ABI for the ERC20 Transfer event with 1 indexed input would be:
event Transfer(address indexed from, address to, uint256 value);

And we ignore the other 2 variants with 1 indexed input:
event Transfer(address from, address indexed to, uint256 value);
event Transfer(address from, address to, uint256 indexed value);

It would be up to the user to generate the mapping from input count to ABI.
The naive way, giving more importance to the arguments from left to right, would be:
def generate_the_most_probable_abi_indexation_variants(abi: ABIEvent) -> dict:
    """Generate the most probable variant of the ABI for each count of indexed inputs."""
    _count = len(abi.get('inputs', ()))
    _indexed = tuple((_i * [True] + (_count - _i) * [False]) for _i in range(_count + 1)) # index from left to right, without gaps
    return {sum(_i): _apply_indexation_mask(abi=abi, mask=_i) for _i in _indexed} # order by number of indexed inputs

And then select the relevant ABI in filter_log:
_abi = abi.get(len(log['topics']) - 1, None)
contract = web3Provider.eth.contract("0x0000000000000000000000000000000000000000", abi=_abi)
for event_name in event_names:
    try:
        results.append(
            contract.events[event_name]().processLog(log))

Pros
This method would not impact performances at all: only one ABI processed per log.
Cons
The filter_log would have to be modified too.
It will still miss events when the most probable ABI doesn't match the actual ABI of the emitted event.
Using the function to its fullest would also require the user to be aware of the issue.
Still, the generation of the variants could be handled directly by filter_log to keep its usage transparent.

@haseebrabbani, what are your thoughts on this?


Timeout on the Second try

https://github.com/vmware/rbvmomi/blob/2e427817735e5df0aef1baa07bc95762e45a18bc/lib/rbvmomi/vim/ManagedObject.rb#L18-L25
It looks like the second time that the line 23
12: def wait_until *pathSet, &b
    13:   all = pathSet.empty?
    14:   filter = _connection.propertyCollector.CreateFilter :spec => {
    15:     :propSet => [{ :type => self.class.wsdl_name, :all => all, :pathSet => pathSet }],
    16:     :objectSet => [{ :obj => self }],
    17:   }, :partialUpdates => false
    18:   ver = ''
    19:   loop do
    20:     puts "start " + info.state
    21:     result = _connection.propertyCollector.WaitForUpdatesEx(:version => ver)
 => 22:     require 'pry' ; binding.pry
    23:     ver = result.version
    24:     puts "middle " + info.state
    25:     if x = b.call
    26:       return x
    27:     end
    28:     puts "bottom " + info.state
    29:   end
    30: ensure
    31:   filter.DestroyPropertyFilter if filter
    32: end

Gets ran, it times out. It seems that this loop is broken and never responds. @jrgarcia and I zoomed about this and it seems that it doesn't do what is supposed to with the newest versions of the 6.5 vCenter. Version 6.5.0 Build 7119070

It turns out this was environmental. It's amazing what happens when you have two NICs and no routes to one of them. :(

Well, I enjoyed the chat about the issue anyway. Thanks for bringing that code to my attention because it should probably be refactored anyway!


Implementation of tabbar as Follower

I created a variable where to store the source TabBar frame and translucent, then I assign it on followScrollView method and I use it to get back to original translucent state when tabbar is on its original frame.
Everything is not force unwrapped.
Tested on iOS 10
Hope You like it!

Thank you @derick182
Looks like it's working great. I've added a demo section in the sample project.
👍


External stream (Kafka source) query support checkpoint

(Jove Github Bot) assuming it is not done, deferred this ticket to the next sprint.


Cannot read properties of undefined

I experience the following issue since tonight. This error message loops and loops:

mielecloudservice.0
2022-02-16 10:27:15.664
error
[addMieleDeviceState]: Cannot read properties of undefined (reading 'targetTemperature'), Stacktrace: TypeError: Cannot read properties of undefined (reading 'targetTemperature') at addMieleDeviceState (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:571:156) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async addMieleDevice (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:330:17) at async parseMieleDevice (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:277:5) at async splitMieleDevices (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:146:9)

mielecloudservice.0
2022-02-16 10:27:15.660
info
The API returned http-error 400: GENERIC_BUSINESS_ERROR for device: [007116614756].

mielecloudservice.0
2022-02-16 10:27:15.385
info
Server Sent Events-Connection has been (re)established @Miele-API.

mielecloudservice.0
2022-02-16 10:27:15.242
info
Registering for appliance events at Miele API.

mielecloudservice.0
2022-02-16 10:27:15.241
error
[addMieleDeviceState]: Cannot read properties of undefined (reading 'targetTemperature'), Stacktrace: TypeError: Cannot read properties of undefined (reading 'targetTemperature') at addMieleDeviceState (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:571:156) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async addMieleDevice (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:330:17) at async parseMieleDevice (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:277:5) at async splitMieleDevices (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:146:9) at async main (/opt/iobroker/node_modules/iobroker.mielecloudservice/main.js:658:13)

mielecloudservice.0
2022-02-16 10:27:15.063
info
The API returned http-error 400: GENERIC_BUSINESS_ERROR for device: [007116614756].

mielecloudservice.0
2022-02-16 10:27:14.611
info
Setting up devices ...

mielecloudservice.0
2022-02-16 10:27:14.608
info
Access-Token expires at: [Fri Mar 18 2022 10:27:14 GMT+0100 (Mitteleuropäische Normalzeit)]

mielecloudservice.0
2022-02-16 10:27:14.182
info
Login attempt #1 @Miele-API

mielecloudservice.0
2022-02-16 10:27:14.095
info
starting. Version 5.0.4 in /opt/iobroker/node_modules/iobroker.mielecloudservice, node: v16.14.0, js-controller: 4.0.10

Hi @aski71
sorry - I have overseen this issue.
Hmm. I am seeing similar issues from time to time at sentry and I'm not sure what happens there in detail. Looks like the API is sending no data. I think it's time to make the code and error handling more bullet proof.

Intermediate Info: I'm currently working on a new version that will hopefully fix this and other issues. Please be patient since the release will not happen too soon, since it's an almost complete rewrite of the adapter.

should be fixed in upcommingv6.0.0. Please reopen if not.


I use 1.1.6. Release in spring cloud kubernetes spring.cloud.kubernetes.ribbon.mode=SERVICE , Null pointer exception in getting service list

`java.lang.NullPointerException: null\n\tat org.springframework.cloud.kubernetes.ribbon.KubernetesServicesServerList.getUpdatedListOfServers
(KubernetesServicesServerList.java:80)\n\tat com.netflix.loadbalancer.DynamicServerListLoadBalancer.updateListOfServers(DynamicServerListLoadBalancer.java:240)\n\tat com.netflix.loadbalancer.DynamicServerListLoadBalancer.restOfInit(DynamicServerListLoadBalancer.java:144)\n\tat com.netflix.loadbalancer.DynamicServerListLoadBalancer.(DynamicServerListLoadBalancer.java:95)\n\tat com.netflix.loadbalancer.ZoneAwareLoadBalancer.(ZoneAwareLoadBalancer.java:82)\n\tat org.springframework.cloud.netflix.ribbon.RibbonClientConfiguration.ribbonLoadBalancer(RibbonClientConfiguration.java:155)\n\tat
`
There is a little problem with the 80 line null logic
					if (Utils.isNotNullOrEmpty(this.getPortName()) 							|| this.getPortName().endsWith(servicePort.getName())) { 						result.add(new Server(concatServiceFQDN(service), 								servicePort.getPort())); 					}

Hello, I have this problem too.

I'm guess it's servicePort that is null.  Could you show me the YAML for the service?  Wondering why there is a null port.  Even better if you have a sample that reproduces this that would be great.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


key listeners inside a modal don't fire anymore

components: Modal
reactstrap version #8.8.0
import method es
react version #17.0.0
bootstrap version #4.5.3

What is happening?
Inside a Modal component, i am using react-image-lightbox for a small image gallery. When the image lightbox is visible I press my keyboard arrow keys, and the current image is not changing.
What should be happening?
Keybinds should work to navigate through images like they did when using reactstrap 8.7.1.
Steps to reproduce issue

Install both reactstrap and react-image-lightbox (I'm sure other packages and use-cases are affected as well, but this is how I discovered the issue)
Embed a Lightbox component within a Modal.
Try using keyboard shortcuts set up by the lightbox component.

Error message in console
No error output
Code
Reproduce:
https://stackblitz.com/edit/reactstrap-7upqrn?file=Example.js
Changing the reactstrap version from 8.8.1 to 8.7.1 in package.json makes the navigation work again.
I've installed builds of reactstrap locally and pinned down the issue to stem from the following commit:
https://github.com/reactstrap/reactstrap/commit/bf46484d2ee1e0d570170d59152fcd0346bfe434

Looks like the focus is stuck on the "open gallery" button, so all key events aren't targeting the lightbox.

Looks like the focus is stuck on the "open gallery" button, so all key events aren't targeting the lightbox.

Also, lightbox is opening it's own portal, so any focus capturing assumption we have in modal won't really work.

Also, lightbox is opening it's own portal, so any focus capturing assumption we have in modal won't really work.

@stianjensen can you do something like this?   https://stackblitz.com/edit/reactstrap-omwcih?file=Example.js
This sandbox modifies yours by adding a new portal target for rendering the lightbox, so instead of rendering at the body level, it renders within the modal.

@stianjensen can you do something like this?   https://stackblitz.com/edit/reactstrap-omwcih?file=Example.js
This sandbox modifies yours by adding a new portal target for rendering the lightbox, so instead of rendering at the body level, it renders within the modal.

Yeah, that looks like it works well - thanks!

Yeah, that looks like it works well - thanks!

Cool thanks for confirming.  Not sure if there's anything we can change on our end for that


Deprecate extension methods returning Point

Point really shouldn't exist in its current form so we shouldn't encourage or enable its use.
If anyone still thinks these extensions are helpful, maybe we could return a record instead.

Ooo....record could be nice.

@srujzs @devoncarew – thoughts here?

Why don't we like Point, @parlough ?

I am curious why we want to discourage Point as well - is dart:math planning on deprecating it?

A Point on a screen does not really belong in a math library, nor does Rectangle. Beyond that, Point declares operators that don't make sense for a point, conflating it with a vector. The * operator on Point<int> can also have a runtime error 😢 when provided with a double.
Beyond those potential sources of confusion, I guess it being generic can introduce performance issues (https://github.com/dart-lang/sdk/issues/53912).
I believe there's been a variety of other discussions around this over the years, but since dart:html used it, it was likely hard to deprecate and remove. With this web migration, I think it's time to revisit that. Whether we do/can or not, it seems better avoid new uses where possible. Anyone using Point here likely just needs the x and y, and direct access or a record can provide that.

Thanks for the reasoning! I'm okay with avoiding new uses for now. We can always re-add (or users can in their own libraries) if we think this is safe.

Or do we just move to the Record and include it in the breaking change?!?!
Might be good to do now!

Either way works. I presume there's very low usage of this, and since we're releasing a breaking change version, might as well remove it instead of deprecating.

@srujzs – or just replace the return type!

I'd really suggest we deprecate or remove these for this release. Then revisit extensions returning records in the future. For example MouseEvent has a bunch of other somethingX and somethingY values that we don't expose through extensions like this.


liquibase_issue_3554  Added default values to private Scope constructor

Since that constructor is the only used for creating the root scope, the scopeId was previously left null.  The change is to set that value to the string "root".  This is to prevent a NPE when the Scope.exit is called on the root scope.
Impact

[x] Bug fix (non-breaking change which fixes expected existing functionality)
[ ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Things to be aware of

Things to worry about

Additional Context

Initial/Pre-Review Thoughts
Changes make sense to me. Our code doesn't seem to hit the spot where it's a problem having scopeId==null but #3554 seems to and this should fix it.
Questions I have:

None

Potential risks:

None

What could make the full review difficult:

Nothing

Thank you @MalloD12 !  Hopefully this will fix the problem and I will no longer have to maintain 2 different code bases.  One set of our code is used by gov't entities and they required us moving to a newer version which was fine since that environment didn't have nearly the load that our commercial environment has.  Commercial has been stuck on 3.10 because of the threading issues I have brought up.


Sensitivity computation when using Magnetic Bearings

Theoretical Background
The API STANDARD 617 document (produced by the American Petroleum Institute) requires that rotors supported by active magnetic bearings (AMBs) have their stability assessed based on a series of criteria. One of these criteria involves analyzing the sensitivity of the closed-loop control system that enables the AMB operation. Given the transfer functions of the controller $\mathrm{C(s)}$ and the plant $\mathrm{G(s)}$ (which in this case describes the relationship between the force applied by the AMB and the displacement of the shaft at the bearing location), it is possible to calculate the sensitivity $\mathrm{S(s)}$ as follows:
$$
\mathrm{S(s)} = \frac{1}{1 + \mathrm{G(s)} \mathrm{C(s)}}
$$
Since the closed-loop response is given by
$$
\mathrm{T(s)} = \frac{\mathrm{G(s) C(s)}}{1 + \mathrm{G(s)} \mathrm{C(s)}}
$$
it can be concluded that $\mathrm{S(s)} + \mathrm{T(s)} = 1$. Therefore,
$$
\mathrm{S(s)} = 1 - \mathrm{T(s)}
$$
The block diagram below graphically represents the control system associated with the AMB. The force that the AMB applies to the shaft and the displacement of the shaft at the bearing location are represented by $F$ and $x$, respectively.

According to the ROSS documentation, the frequency response obtained from the execution of the run_freq_response method is computed based on the application of an excitation force at a given node of the shaft. This force, $F_w$, represents an excitation to the control system, as shown in the figure below.

Therefore, since ROSS produces a frequency response that relates $x$ and $F_w$, it can be said that this response represents, in the frequency domain, the transfer function $\mathbf{G_w(s)}$, whose definition can be obtained based on the analysis of the block diagram introduced above.
$$
\frac{\mathbf{W(s)}}{\mathbf{Y(s)}} = \mathbf{G_w(s)} = \frac{\mathbf{G(s)}}{1 + \mathbf{G(s)C(s)}}
$$
where $\mathbf{W(s)}$ and $\mathbf{Y(s)}$ are the Laplace transforms of the disturbance and output, respectively.
Given the definition of $\mathbf{T(s)}$ previously presented, it follows that
$$
\mathbf{T(s)} = \mathbf{C(s)} \mathbf{G_w(s)}
$$
Since the gains of the controller $\mathbf{C(s)}$ (in this case, a PID controller) are known, it is possible to obtain the magnitude and phase of the controller's frequency response (using the Python Control Systems). Since the magnitude and phase of $\mathbf{G_w(s)}$ are provided by ROSS (from the execution of the run_freq_response method), it is possible to compute the magnitude and phase of $\mathbf{T(s)}$ as follows:
$$
|\mathbf{T(s)}| = |\mathbf{C(s)}| |\mathbf{G_w(s)}|
$$
$$
\angle\mathbf{T(s)} = \angle\mathbf{C(s)} +  \angle\mathbf{G_w(s)}
$$
Having obtained the magnitude and phase of $\mathbf{T(s)}$, the sensitivity can finally be computed, given that $\mathrm{S(s)} = 1 - \mathrm{T(s)}$.
Method employed in the computation of sensitivity
The proposed method for computing the sensitivity is presented below. As previously discussed, the computation of the sensitivity depends on the gains of the controller employed and the frequency response provided by ROSS, which represents the relationship between the output and a disturbance applied at the plant input.
import control as ct
import cmath

def compute_sensitivity(kp_pid, ki_pid, kd_pid, mag_W, phase_W, speed_range):
    # Controller frequency response computation
    s = ct.tf("s")
    C = kp_pid + ki_pid / s + kd_pid * s
    mag_C, phase_C, _ = ct.frequency_response(C, speed_range)

    # Close-loop frequency response computation
    mag_T = mag_W * mag_C
    phase_T = phase_W + phase_C

    complex_T = [
        complex(
            mag_phase[0] * np.cos(mag_phase[1]), mag_phase[0] * np.sin(mag_phase[1])
        )
        for mag_phase in zip(mag_T, phase_T)
    ]

    # Sensitivity computation
    complex_S = [1 - z for z in complex_T]

    mag_S = [abs(z) for z in complex_S]
    phase_S = [cmath.phase(z) for z in complex_S]

    return mag_S, phase_S, speed_range

The script below was used to validate the aforementioned method. Both the rotor utilized, and the results obtained can be verified below, having been acquired from an execution that took 25.43 seconds. The computation of the sensitivity, itself, took only 1.09 milliseconds.

Complete code
import ross as rs
import numpy as np
import matplotlib.pyplot as plt
import cmath
from loguru import logger
import control as ct
import time

max_freq = 100  # Hz
x_label = "w [rad/s]"

def get_dof(node, local_dof):
    local_dof_dict = {"x": 0, "y": 1, "alpha": 2, "beta": 3}
    return node * 4 + local_dof_dict[local_dof]

def build_rotor(show_rotor=False):
    logger.info("Initiating rotor build.")

    # --- SHAFT MATERIAL DEFINITION ---
    steel = rs.Material(name="Steel", rho=7850, E=211e9, G_s=81.2e9)

    # --- SHAFT ELEMENTS DEFINITION ---
    L = 0.1  # Length of each element (m)
    i_d = 0  # Internal Diameter (m) - assuming solid shaft
    o_d = 0.05  # External Diameter (m)

    shaft_elements = [
        rs.ShaftElement(
            L=L,
            idl=i_d,
            odl=o_d,
            material=steel,
            shear_effects=True,
            rotary_inertia=True,
            gyroscopic=True,
        )
        for _ in range(10)
    ]

    # --- DISC DEFINITION ---
    disk = rs.DiskElement.from_geometry(
        n=5, material=steel, width=0.07, i_d=0.05, o_d=0.28
    )

    # --- MAGNETIC BEARING DEFINITION ---
    # Electromagnetic parameters (see ROSS documentation for details)
    g0 = 1e-3  # Air gap
    i0 = 1.0  # Bias current
    ag = 1e-4  # Pole area
    nw = 200  # Winding turns
    alpha = 0.392  # Half of the angle between two poles

    # PID gains
    kp_pid = 1000000  # Kp gain
    kd_pid = 1000000  # Kd gain
    k_amp = 1.0  # Power amplifier gain
    k_sense = 1.0  # Sensor gain

    # Magnetic bearing at node 2
    bearing1 = rs.MagneticBearingElement(
        n=2,
        g0=g0,
        i0=i0,
        ag=ag,
        nw=nw,
        alpha=alpha,
        kp_pid=kp_pid,
        ki_pid=0,
        kd_pid=kd_pid,
        k_amp=k_amp,
        k_sense=k_sense,
    )

    # Simple support at node 8
    kxx = 1e6  # Stiffness in x direction (N/m)
    kyy = 1e6  # Stiffness in y direction (N/m)
    cxx = 1e3  # Damping in x direction (N*s/m)

    bearing2 = rs.BearingElement(n=8, kxx=kxx, kyy=kyy, cxx=cxx)

    # --- ROTOR ASSEMBLY AND VISUALIZATION---
    rotor = rs.Rotor(
        shaft_elements=shaft_elements,
        disk_elements=[disk],
        bearing_elements=[bearing1, bearing2],
    )
    if show_rotor:
        rotor.plot_rotor().show()

    logger.info("Rotor build completed successfully.")
    return rotor

def compute_freq_resp(rotor):
    logger.info("Initiating frequency response computation.")

    speed_range = np.linspace(0, max_freq * 2 * np.pi, 2 * max_freq)
    freq_resp = rotor.run_freq_response(speed_range=speed_range)
    np.save(
        "output/freq_resp",
        freq_resp.freq_resp,
    )
    np.save(
        "output/speed_range",
        np.array(freq_resp.speed_range),
    )

    logger.info("Frequency response computation completed successfully.")

def get_freq_response_at_mma():
    logger.info("Collecting frequency response at AMB.")

    freq_response = np.load("output/freq_resp.npy")
    speed_range = np.load("output/speed_range.npy")

    left_bearing_node = 2
    disk_node = 5

    freq_response_at_mma = freq_response[
        get_dof(disk_node, "y"), get_dof(left_bearing_node, "y"), :
    ]

    mag_W = [abs(z) for z in freq_response_at_mma]
    phase_W = [cmath.phase(z) for z in freq_response_at_mma]

    logger.info("Frequency response at AMB collected successfully.")
    return mag_W, phase_W, speed_range

def plot_freq_resp():
    logger.info("Initiating frequency response plot.")

    mag_W, phase_W, speed_range = get_freq_response_at_mma()

    # Displacement
    # Magnitude
    plt.figure(figsize=(8, 6), dpi=130)
    plt.subplot(2, 1, 1)
    plt.plot(speed_range, mag_W)
    plt.legend(['$\mathrm{G_w(s)}$'])
    plt.xlabel(x_label)
    plt.ylabel("Magnitude [m/N]")
    plt.title("Frequency Response")
    plt.yscale("log")
    plt.xlim([np.min(speed_range), np.max(speed_range)])
    plt.grid()
    plt.tight_layout()

    # Fase
    plt.subplot(2, 1, 2)
    plt.plot(speed_range, phase_W)
    plt.legend(['$\mathrm{G_w(s)}$'])
    plt.xlabel(x_label)
    plt.ylabel("Phase [rad]")
    plt.xlim([np.min(speed_range), np.max(speed_range)])
    plt.grid()
    plt.tight_layout()

    logger.info("Frequency response plot completed successfully.")

def compute_sensitivity_call():
    logger.info("Initiating sensitivity computation.")
    mag_W, phase_W, speed_range = get_freq_response_at_mma()
    start_time = time.time()
    mag_S, phase_S, speed_range = compute_sensitivity(
        kp_pid=1000000,
        ki_pid=0,
        kd_pid=1000000,
        mag_W=mag_W,
        phase_W=phase_W,
        speed_range=speed_range,
    )
    end_time = time.time()
    logger.info(f'Sensitivity computation time: {end_time - start_time} seconds.')
    return mag_S, phase_S, speed_range

def compute_sensitivity(kp_pid, ki_pid, kd_pid, mag_W, phase_W, speed_range):
    # Controller frequency response computation
    s = ct.tf("s")
    C = kp_pid + ki_pid / s + kd_pid * s
    mag_C, phase_C, _ = ct.frequency_response(C, speed_range)

    # Close-loop frequency response computation
    mag_T = mag_W * mag_C
    phase_T = phase_W + phase_C

    complex_T = [
        complex(
            mag_phase[0] * np.cos(mag_phase[1]), mag_phase[0] * np.sin(mag_phase[1])
        )
        for mag_phase in zip(mag_T, phase_T)
    ]

    # Sensitivity computation
    complex_S = [1 - z for z in complex_T]

    mag_S = [abs(z) for z in complex_S]
    phase_S = [cmath.phase(z) for z in complex_S]

    return mag_S, phase_S, speed_range

def plot_sensitivity(mag_S, phase_S, speed_range):
    logger.info("Initiating sensitivity response plot.")

    # Displacement
    # Magnitude
    plt.figure(figsize=(8, 6), dpi=130)
    plt.subplot(2, 1, 1)
    plt.plot(speed_range, mag_S)
    plt.legend(['S(s)'])
    plt.xlabel(x_label)
    plt.ylabel("Magnitude [m/N]")
    plt.title("Frequency Response")
    plt.yscale("log")
    plt.xlim([np.min(speed_range), np.max(speed_range)])
    plt.grid()
    plt.tight_layout()

    # Fase
    plt.subplot(2, 1, 2)
    plt.plot(speed_range, phase_S)
    plt.legend(['S(s)'])
    plt.xlabel(x_label)
    plt.ylabel("Phase [rad]")
    plt.xlim([np.min(speed_range), np.max(speed_range)])
    plt.grid()
    plt.tight_layout()

    logger.info("sensitivity plot completed successfully.")

def main():
    start_time = time.time()
    rotor = build_rotor(show_rotor=True)
    compute_freq_resp(rotor)
    plot_freq_resp()
    mag_S, phase_S, speed_range = compute_sensitivity_call()
    plot_sensitivity(mag_S, phase_S, speed_range)
    plt.show()

    logger.info("Execution completed successfully.")
    end_time = time.time()

    logger.info(f"Execution time: {end_time - start_time}.")

if __name__ == "__main__":
    main()

Implementation of sensitivity computation in ROSS
The results presented thus far indicate that the proposed method does indeed allow the sensitivity to be correctly computed. Therefore, it is proposed that such computation should take place during the execution of the run_freq_response method. Once the frequency response (freq_resp) has been properly computed by this method, it will be necessary to verify if there is any AMB associated with the rotor under analysis. If so, the sensitivity should be calculated based on the frequency response produced during the execution of the run_freq_response method. The FrequencyResponseResult object will then need to be modified to receive information regarding sensitivity in its constructor. In addition, a new method should be added to this class, allowing the user to construct a plot that represents both the magnitude and phase of the sensitivity.
The diagrams below illustrate the current structure of the run_freq_response method and the FrequencyResponseResult class, while the blocks highlighted in pink indicate the modifications that will be implemented in both.

During the sensitivity computing implementation, it was necessary to slightly modify the initially proposed structure. The changes implemented in the ROSS fork (specifically at: https://github.com/ArthurIasbeck/ross/tree/compute-sensitivity) are described below.

Update of the run_freq_response method
This method, responsible for computing the rotor's frequency response, will now be able to compute the sensitivity associated with any magnetic bearing present in the rotor. For this purpose, a new optional parameter has been added to the method: compute_sensitivite_at. This parameter is a dictionary containing the information required to compute the sensitivities of the magnetic bearings. Each key should be a bearing tag, and the corresponding value should be a dictionary defining the input and output degrees of freedom that determine the sensitivity computation, as shown in the example below. If the compute_sensitivite_at parameter receives a non-null value, the compute_sensitivity() method will be invoked.
compute_sensitivite_at = {
    "Bearing 0": {"inp": 2, "out": 2},
    "Bearing 1": {"inp": 8, "out": 8},
}

When the sensitivity calculation is requested by the user, the FrequencyResponseResults object returned by the run_freq_response method will contain an attribute called sensitivity_results, which will hold an instance of the SensitivityResults class. In the example below, it is possible to check which attributes are associated with sensitivity_results.
sensitivity_results = {SensitivityResults} <ross.results.SensitivityResults object at 0x7281ed7d4070>
	compute_sensitivite_at = {dict: 2} {'Bearing 0': {'inp': 9, 'out': 9}, 'Bearing 1': {'inp': 33, 'out': 33}}
	max_abs_sensitivities = {dict: 2} {'Bearing 0': 0.8329731089141272, 'Bearing 1': 0.8329731089184789}
	sensitivities = {dict: 2} {'Bearing 0': [0.78451171-2.57357183e-17j 0.78470679+6.42813212e-05j, ...

Implementation of the SensitivityResults class
This class is responsible for storing the results from the sensitivity calculation (not only the sensitivity values themselves but also the degrees of freedom that were used as the basis for the computation and the maximum absolute sensitivity values for each bearing). The class also has a method, named plot(), which returns a Plotly figure containing two subplots, in which the magnitude and phase of the sensitivity associated with each bearing are represented (as indicated below).

Update of the FrequencyResponseResults class
The constructor of this class now receives the optional parameter sensitivity_results (an instance of the SensitivityResults class) which holds the results obtained from the magnetic bearing sensitivity computation. These results will only be generated if the rotor model includes at least one magnetic bearing and the user has requested sensitivity computation. The sensitivity_results parameter contains information about the computed sensitivities for each magnetic bearing. This includes a list of the associated magnetic bearings, the maximum absolute sensitivity for each bearing, and the individual sensitivity values for each bearing. It is worth noting that the FrequencyResponseResults instance, constructed by the run_freq_response() method will only contain the sensitivity_results field if the sensitivity has actually been calculated.
The FrequencyResponseResults class also received the addition of the plot_sensitivity() method, which returns a Plotly figure containing two subplots, in which the magnitude and phase of the sensitivity associated with each bearing are represented. This method calls the plot() method of the SensitivityResults class, providing it with the frequency range over which the sensitivity should be plotted. The definition of the plot_sensitivity() method allows the Bode plots for sensitivity to be constructed directly from the object returned by the run_freq_response() method.

Definition of the compute_sensitivity() method
This method computes the sensitivity for each magnetic bearing whose tag is present in the compute_sensitivity_at dictionary, given the frequency response of the rotor.

Creation of the amb_rotor_example method
This function returns an instance of a simple rotor model. The model consists of ten shaft elements, one disk, one simple bearing, and one magnetic bearing. It provides a basic model for writing doctests. This method was used in defining the examples present in the description of the run_freq_response() method, which can now compute the sensitivity of the magnetic bearings associated with the rotor.

In summary, the user executes the run_freq_response method, passing the compute_sensitivity_at argument, which indicates the degrees of freedom where the sensitivity should be calculated. The run_freq_response then calls the compute_sensitivity method, which is responsible for actually computing the sensitivity values. Back in the run_freq_response method, an instance of the SensitivityResults class is created and used in the definition of an instance of the FrequencyResponseResults class, which is finally returned to the user.

Below are the latest changes implemented in the fork https://github.com/ArthurIasbeck/ross/tree/compute-sensitivity.

Update of the plot_sensitivity and plot methods of the FrequencyResponseResults and SensitivityResults classes, respectively, to allow the user to adjust the units of the sensitivity plots.
Implementation of the test_compute_sensitivity test method in the test_rotor_assembly module, where sensitivity computation validation is performed.
Inclusion of the fig_kwargs argument in the plot_sensitivity and plot methods to enable user configuration of sensitivity plots.

The changes that enable ROSS to perform the computation of sensitivities associated with magnetic bearings present in the rotor have been duly implemented in the fork https://github.com/ArthurIasbeck/ross/tree/compute-sensitivity and the pull request https://github.com/petrobras/ross/pull/1108 has been opened, requesting that these changes be incorporated into ROSS.

Recently, the following changes were made (commit ID 021e8e9107acb092e4712011323c9d19020cb869 from fork https://github.com/ArthurIasbeck/ross/tree/compute-sensitivity):

Creation of the SensitivityResults class
Implementation of an exclusive method for calculating sensitivity (run_amb_sensitivity)
Update of the rotor_amb_example method to include a more complex model
Implementation of the test_save_load_sensitivityresponse test
Update of the test_compute_sensitivity method

I recently had access to ISO 14839-3, which defines how the sensitivity of active magnetic bearings should be measured. This ISO standard assumes that the control system associated with the AMB can be represented as follows:

where $G_p$ is the rotor's transfer function, $E$ is a disturbance associated with the sensor signal (which can represent white noise or a harmonic signal), and $F_d$ is a force that represents a disturbance applied directly to the rotor.
The system above can be simplified so that:

Based on these representations, the ISO standard proposes that the open-loop, closed-loop, and sensitivity transfer functions, represented by $G_o$, $G_c$, and $G_s$, respectively, be computed as follows:

Also, according to the ISO standard, it is possible to define the open-loop transfer function as $G_o = G_c / (1 - G_c)$. Therefore, it is possible to verify that $G_s = 1 - G_c$.
Starting from the simplified diagram introduced previously, it is possible to verify that
$$
X = \frac{G_r G_p}{1 - G_r G_p}E + \frac{G_p}{1 - G_rG_p} F_d
$$
Assuming that the frequency response provided by ROSS is obtained by varying $F_d$ and adopting $E = 0$, it follows that the transfer function associated with the frequency response in question is given by:
$$
G_d = \frac{X}{F_d} = \frac{G_p}{1 - G_r G_p}
$$
Therefore, it follows that
$$
G_c = -G_d G_r = (-1 + 0j)G_dG_r
$$
$$
|G_c| = |G_d||G_r|
$$
$$
\angle{G_c} = \pi + \angle{G_d} + \angle{G_r}
$$
Since the controller transfer function $G_r$ is known and the transfer function relating the disturbance to the displacement $G_d$ is provided (indirectly) by ROSS, it is possible to compute the closed-loop transfer function $G_c$ and use it in the calculation of the sensitivity $G_s$.
The recent changes in the methods responsible for calculating the sensitivity aimed to comply with ISO 14839-3. There were few significant changes, among them, the addition of $\pi$ in the calculation of the phase of $G_c$.

As mentioned in previous comments, ISO 14839-3 describes the experimental procedure associated with measuring the sensitivity of the Active Magnetic Bearing (AMB) control systems. This procedure is based on the sampling of some signals and the application of noise $E$ at the system's output, as indicated in the diagram below.

The time-domain data that enabled the computation of the sensitivity were obtained through the execution of the run_time_response method, as indicated below:
def generate_time_response():
    np.random.seed(0)

    rotor = self.rotor_assembly()
    speed = 1200  # [rad/s] = [Hz] * 2 * np.pi

    time_samples = int(self.t_max / self.dt + 1)
    t = np.linspace(0, self.t_max, time_samples)

    f = np.zeros((len(t), rotor.ndof))

    response = rotor.run_time_response(speed, f, t, method="newmark")

The method responsible for implementing the controllers associated with each AMBs (magnetic_bearing_controller) is summarized below. The changes that enabled the calculation of the sensitivity are highlighted. It is worth noting that these changes are temporary and only allow the information necessary for calculating the sensitivity to be written to the terminal so that it can be collected and subsequently processed. This approach was used only for testing purposes, and the data needed for calculating the sensitivity will be collected later in a different way. The magnetic_bearing_controller method was only implemented in the ROSS version found at https://github.com/mcarolalb/ross/tree/dev/magnetic-controller.
def magnetic_bearing_controller(self, magnetic_bearings, time_step, disp_resp):
    ...

    for elm in magnetic_bearings:
        dofs = [self.number_dof * elm.n, self.number_dof * elm.n + 1]
        for idx_dofs, value_dofs in enumerate(dofs):
            # CODE ADDED - START
            if value_dofs == 49:
                # Impulse
                # if elm.e0[idx_dofs] == 1e-06:
                #     e = 1
                # else:
                #     e = 0

                # White noise (uniform)
                # e = np.random.rand() * 1e-6

                # White noise (Gaussian)
                # e = np.random.normal(scale=1e-6)

                v_2 = disp_resp[value_dofs]
                v_1 = v_2 + e
                data_dict = {
                    "e": e,
                    "v_1": v_1,
                    "v_2": v_2
                }
                err = setpoint - v_1
            else:
                err = setpoint - disp_resp[value_dofs]
						# CODE ADDED - END

            P = elm.kp_pid * err
            elm.integral[idx_dofs] += elm.ki_pid * err * dt
            D = elm.kd_pid * (err - elm.e0[idx_dofs]) / dt
            ...

The data collected from the terminal after the execution of the run_time_response method were saved in the file input/00_temp_data_to_compute_sensitivity.txt and subsequently processed using the methods indicated below, which enabled the calculation of the sensitivity.
def compute_sensitivity(
    data_file_name="input/00_temp_data_to_compute_sensitivity.txt",
):
    with open(data_file_name, "r") as file:
        data = file.readlines()
        data = data[2:-1]
        e_list = []
        v_1_list = []
        for line in data:
            values = json.loads(line)
            e_list.append(values["e"])
            v_1_list.append(values["v_1"])

        e = np.array(e_list, dtype=np.float64)
        v_1 = np.array(v_1_list, dtype=np.float64)
        t = np.linspace(0, self.t_max, len(e))

        f, abs_G_s, phase_G_s, _ = compute_freq_resp_from_temp(
            t, v_1, e, plot_result=plot_result
        )
        omega = 2 * np.pi * f

        return omega, abs_G_s, phase_G_s

def compute_freq_resp_from_temp(t, y, u, plot_result=False, ft_gain=1):
    Y, _, _, _ = compute_fft(y, t)
    U, f, _, _ = compute_fft(u, t)

    Gyy = np.conj(Y) * Y
    Guu = np.conj(U) * U
    Guy = np.conj(U) * Y
    H = ft_gain * (Guy / Guu)
    coe = np.absolute(Guy) ** 2 / (Gyy * Guu)

    abs_H, phase_H = compute_abs_phase(H)

    return f, abs_H, phase_H, H

def compute_abs_phase(X):
    X = np.round(X, 10)
    abs_X = np.absolute(X)
    phase_X = np.array([0 if np.absolute(z) == 0 else np.angle(z) for z in X])
    return abs_X, phase_X

The rotor used to obtain the evaluated data is represented below. The sensitivity calculation, in this case, was based on the data associated with the $y$ displacement of node 12, where the first AMB is located.

In the graphs below, it is possible to verify the sensitivity values obtained considering different types of disturbance $E$. The types of disturbances used are described in the legend. The sensitivity values obtained based on the frequency response are shown in red. It is possible to verify that the best result was obtained when an impulsive disturbance was applied and that the results obtained based on the frequency response are definitely not reliable.

Hi there!
I have marked this issue as stale because it has not had activity for 45 days.
Consider the following options:

If the issue refers to a large task, break it in smaller issues that can be solved in
less than 45 days;
Label the issue as wontfix or wontfix for now and close it.


VS Code uninstalled itself??

VSCode Version: Unknown (either 1.36.0 or 1.36.1)
OS Version: W10 Home

Steps to Reproduce:
I have absolutely no idea...
some Windows Update triggered and VS Code is no more in the system...

Does this issue occur when all extensions are disabled?: I don't know…
MORE INFO
I found a similar closed issue from 1 year ago: #68688

You linked to #68688 but that one had been marked as a duplicate of #52855.
Basically, Code wants to upgrade itself, so it first deleted itself, but some how failed to install the new version., leaving no Code in your computer.
You have a pretty old version, do you keep the auto update on?

☝