Click to play on the simulator of ios 10.3 will be directly stuck

2020-05-26 16:28:39.028 Runner[2347:13156] iOS => call play, playerId 217b8817-5b8b-419b-a150-83213d8b5d7b
2020-05-26 16:28:39.030 Runner[2347:13156] play!
2020-05-26 16:28:39.032 Runner[2347:13156] isLocal: 0 0
2020-05-26 16:28:39.032 Runner[2347:13156] volume: 1.000000 1
2020-05-26 16:28:39.033 Runner[2347:13156] position: 0 (null)
2020-05-26 16:28:39.033 Runner[2347:13156] setUrl https://************/700157a99f2641feb5d4ce563eb9d34e?e=1590485309&token=QwB8w8h3rbGI2YZMFvFX0PRIK1jrzKrnImWyMWU2:WleIHGnACZv4HByx8-nPYJp_FVo=
2020-05-26 16:28:39.046 Runner[2347:13156] iOS => call seek, playerId 217b8817-5b8b-419b-a150-83213d8b5d7b
2020-05-26 16:28:39.052 Runner[2347:13156] seek
2020-05-26 16:28:39.053 Runner[2347:13156] Seeking to: 380000 milliseconds
2020-05-26 16:28:39.099 Runner[2347:13156] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'AVPlayerItem cannot service a seek request with a completion handler until its status is AVPlayerItemStatusReadyToPlay.'
*** First throw call stack:
(
0 CoreFoundation 0x00000001050eab0b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x000000010c09c141 objc_exception_throw + 48
2 AVFoundation 0x0000000104170855 -[AVPlayerItem seekToTime:toleranceBefore:toleranceAfter:completionHandler:] + 1557
3 AVFoundation 0x0000000104170237 -[AVPlayerItem seekToTime:completionHandler:] + 146
4 audioplayers 0x00000001093e8c8f -[AudioplayersPlugin seek:time:] + 367
5 audioplayers 0x00000001093e3f59 __46-[AudioplayersPlugin handleMethodCall:result:]_block_invoke_4 + 441
6 audioplayers 0x00000001093e2893 -[AudioplayersPlugin handleMethodCall:result:] + 4323
7 Flutter 0x0000000105e80b1f __45-[FlutterMethodChannel setMethodCallHandler:]_block_invoke + 104
8 Flutter 0x0000000105e0f762 _ZNK7flutter21PlatformMessageRouter21HandlePlatformMessageEN3fml6RefPtrINS_15PlatformMessageEEE + 166
9 Flutter 0x0000000105e138ba _ZN7flutter15PlatformViewIOS21HandlePlatformMessageEN3fml6RefPtrINS_15PlatformMessageEEE + 38
10 Flutter 0x0000000105e7a7fb _ZNSt3__110__function6__funcIZN7flutter5Shell29OnEngineHandlePlatformMessageEN3fml6RefPtrINS2_15PlatformMessageEEEE4$_32NS_9allocatorIS8_EEFvvEEclEv + 57
11 Flutter 0x0000000105e243a7 _ZN3fml15MessageLoopImpl10FlushTasksENS_9FlushTypeE + 117
12 Flutter 0x0000000105e292f4 ZN3fml17MessageLoopDarwin11OnTimerFireEP16__CFRunLoopTimerPS0 + 26
13 CoreFoundation 0x000000010507e454 CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION + 20
14 CoreFoundation 0x000000010507e0e3 __CFRunLoopDoTimer + 1011
15 CoreFoundation 0x000000010507dcaa __CFRunLoopDoTimers + 266
16 CoreFoundation 0x00000001050759ec __CFRunLoopRun + 1916
17 CoreFoundation 0x0000000105075016 CFRunLoopRunSpecific + 406
18 GraphicsServices 0x000000010e5a3a24 GSEventRunModal + 62
19 UIKit 0x0000000109b59134 UIApplicationMain + 159
20 Runner 0x0000000102e77bcb main + 75
21 libdyld.dylib 0x000000010dbd265d start + 1
22 ??? 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)

I want to ask what is the minimum version of ios supported by audioplayers?

Same here. I have lots of crashes in production because of it

Same problem on iPhone 7 10.3.1 Simulator. Cannot call seek. Really need this fixed or @hrongyongs question answered.
Works fine on iPhone 11 Pro Max 13.3 Simulator.
iOS => call play, playerId test
play!
isLocal: 0 0
volume: 1.000000 1
position: 0 (null)
setUrl https://www.myurl.com/my_mp3.mp3
iOS => call seek, playerId test
seek
Seeking to: 48874000 milliseconds
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'AVPlayerItem cannot service a seek request with a completion handler until its status is AVPlayerItemStatusReadyToPlay.'
Possible solution? I know nothing about IOS development or AVplayer. https://stackoverflow.com/questions/38332162/avplayer-seek-right-after-it-starts-to-play

@luanpotter do we have a min version for iOS?

@hrongyong @jefflyne Can you check, is this still a thing with 1.x.x? Thx :) I cannot test for ios, unfortunately. Also it would be nice to have an example repo, to reproduce...

Closing as stale.


Launching very slow in my laptop and also crashing sometime when code is running

Type: Performance Issue
1.)when i click to open vs code it takes very much time to launch and also some  time it crashes and pop message wait for sometime or reopen.
2.)after this, if vs code open when i run code it take so much time to compile and sometime crashes also.
3.) i have been reinstalling vs code again and again but the problem is not solving .
VS Code version: Code 1.78.2 (b3e4e68a0bc097f0ae7907b217c1119af9e03435, 2023-05-10T14:39:26.248Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: Yes

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (8 x 2419)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
15.79GB (7.93GB free)

Process Argv
--crash-reporter-id 92d85fb9-9f19-43c1-9e78-d387f0ba4281

Screen Reader
no

VM
0%

Process Info
CPU %	Mem MB	   PID	Process
    0	    94	 22456	code main
    0	    83	  8028	fileWatcher [1]
    0	   168	  9248	   gpu-process
    0	    88	 13192	window [2] (Issue Reporter)
    0	    51	 19728	   utility-network-service
    0	    29	 20428	   crashpad-handler
    0	   131	 21732	extensionHost [1]
    0	    15	  3100	     c:\Users\lenovo\.vscode\extensions\ms-vscode.cpptools-1.15.4-win32-x64\bin\cpptools.exe
    0	    11	 14180	       console-window-host (Windows internal process)
    0	     4	 25268	       "c:\Users\lenovo\.vscode\extensions\ms-vscode.cpptools-1.15.4-win32-x64\bin\cpptools.exe"
    0	   124	 29428	shared-process
    0	    84	 30280	     ptyHost
    0	   202	 32788	window [1] (● #include<bits/stdc++.h> • Untitled-2 - Visual Studio Code)

Workspace Info
;

Extensions (3)

Extension
Author (truncated)
Version

code-runner
for
0.12.0

remote-wsl
ms-
0.78.9

cpptools
ms-
1.15.4

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
2e4cg342:30602488
pyind779:30671433
f6dab269:30613381
pythonsymbol12:30671437
2i9eh265:30646982
showlangstatbar:30737416
vsctsb:30748421
pythonms35:30701012
03d35959:30757346
pythonfmttext:30731395
pythoncmvfstrcf:30756944
fixshowwlkth:30730052
showsbindicator:30760979
pythongtdpathcf:30739705

I have also seen so many issues with 1.78.2 version
Not sure if it was tested before rolling out. I am using salesforce extensions and retrieve and deploy code takes forever.
It runs deploy or retrieve action

for hours if not days.

/duplicate
Marking as duplicate of https://github.com/microsoft/vscode/issues/178962. Please let us know if McAfee is not installed on your PC, else use the instructions to resolve.
@dave-sfdc please raise your issue with the developers of the SFDX extension(s) you use.

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!

@gjsjohnmurray This issue happened after I upgraded VS Code to 1.78.2 few days back
Not sure on what basis you are asking to check with SFDX extenstion team. The issue is with VS Code itself for sure.
I do not have Mcafee antivirus or any other new software installed
Nothing in my machine was updated except for VS Code version. That is why I am asking if enough testing was done on this version?

@dave-sfdc which version did you update from?

@gjsjohnmurray I do not recall the old version. I normally update every time I get a prompt for new version.


[MULTIPART-FILE] Content type should always be set

Context
In here:
https://github.com/kennethreitz/requests/blob/v2.7.0/requests/models.py#L464-L466
The content type is only set if the there isn't one already set. I feel this shouldn't be the case.
As we can see here:  https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/filepost.py#L92
The content type string has a boundary generated by this method. This is specific to the body being encoded. Without this boundary and content type, the data being posted is no longer considered Multipart Form Data, which is the whole point of specifying files= in the post method.
Even raising an exception would be better than silently skipping setting the content type.

Hi @vaibhavkaul,
Thanks for sending a pull request. I'm afraid we likely won't be accepting it. Here's why:

This is drastically backwards incompatible behaviour.
It takes a great deal of freedom away from the user which we have intentionally placed into their hands.
This code does not just change this for the multipart/form-data case.
This also prevents people from writing API fuzzers which provide incorrect content-type headers for a totally different kind of content and drastically reduces requests flexibility.
This affects the cases where people provide something to data= or json= with a custom content-type header where they expect their explicit decision to specify that header to be honored.

We could consider this for version 3.0.0 but I think it would not fit there either for several of the reasons listed above and also mostly due to the fact that we hope to not break things too drastically in 3.0.
I won't close this just yet because I hope @Lukasa and @kennethreitz will weigh in as well.
Cheers,
Ian

@sigmavirus24 I understand. I figured it might be worth pointing out.

It takes a great deal of freedom away from the user which we have intentionally placed into their hands.

As long as this is an intentional choice.

This code does not just change this for the multipart/form-data case.

You are right. I missed that, i will at-least make it specific to the files case, even if we end up not merging this.
The silent nature of the problem can cause a lot of headaches.

The silent nature of the problem can cause a lot of headaches.

Might I ask why this change is any less of a silent headache though? Let me paint a picture:
requests.post(url, header={'Content-Type': 'multipart/form-data'}, files=files, data=data)

Will make the correct body with an incorrect header. With a little research a user can figure out what they did wrong.
requests.post(url, headers={'Content-Type': 'application/vnd.github.drax-preview+json'}, json=json_data)

Would forcibly reset the header to application/json which breaks things for the user doing the right thing.
Sometimes overriding requests default behaviour is correct for user. I'm also of the opinion that special-casing this to just multipart uploads is the wrong thing. That means that one of the cases above prevents the user from doing exactly what they intend to do and introduces a great deal of inconsistency in the API. If any user needs to do something with an alternate content-type header for multipart form-data request, we now punish them by forcing them to use the prepared request flow and overriding the header after preparing the request... just to change one header.
I understand that this can be and has been a foot-gun for several people. Google eagerly returns the StackOverflow questions and answers (there are a few) that explain what is happening and what needs to be fixed to correct the request.
I don't think introducing inconsistencies in the API or silent behaviour is the right thing.

I'm also disinclined to make this change. I can see why we'd do it, but I think if we're worried about requests silently subverting expectations then changing the behaviour to differently silently subvert expectations isn't a great direction.
One option might be to instead fire a warning or a log in this case. That would attract user attention while also allowing users who so choose to override this behaviour.
 If the user wants to change content-length, they can. If they want to change transfer-encoding, they can. There is only so much we can do to protect users from themselves.

@kennethreitz thoughts?

@sigmavirus24 I made the change so it doesn't affect other things besides files.

Sometimes overriding requests default behaviour is correct for user

Yes, which which is why sometimes should not dictate default behavior.

Will make the correct body with an incorrect header.

I dont think thats true since for the body to be parseable by any standard multi-part library (cgi etc) it would need to have the correct header. Just having the data in the body does not make it correct. I would argue the body is wrong in this case for a multipart request.
My motive right now is not to get this merged in at all. Happy to close the PR. But we should be clear about what the issue is here. Specifically I would like to address things like:

That means that one of the cases above prevents the user from doing exactly what they intend to do

then changing the behaviour to differently silently subvert expectations isn't a great direction

The specific part of code I am referring to deals exclusively with Multipart Files. The whole idea of adding a file= param is to encode the request as a multi-part request. Most developers using that code path clearly want the request to be posted as multipart.
Multipart requests must have a boundary specified in the content-type, if this is missing, the whole purpose for passing a files= param is defeated. This is no longer a multipart request. This is not a correct body with the wrong header. Clearly the requests framework does not allow a user to pass their own boundary (notice the missing boundary kwarg) and use that. It always relies on a auto generated boundary string. We should either give people the ability to be in control of the content-type (by letting them specify a boundary string) or do the right think in the library.

 If the user wants to change content-length, they can. If they want to change transfer-encoding, they can

I agree.  But then why make this raise an exception. There should at least be a warning somewhere about the request not being encoded as a multi part request if the headers being passed include a content-type, even if that content type is multipart/form-data.
I completely agree that we should not make this change if you feel this breaks the existing API, so maybe this should be considered for a future release or maybe not. I'll leave it up to @kennethreitz.

FWIW, do you guys think a better solution would be to allow the user to pass a boundary string and use that instead?

FWIW, do you guys think a better solution would be to allow the user to pass a boundary string and use that instead?

You already can with the toolbelt's MultipartEncoder and since 99% of our users don't need that in requests itself, it makes perfect sense to have something that lives elsewhere to do that.

But then why make this raise an exception.

Because one is exceptional. We could issue a warning when overriding the content-type header when a user specifies both data= and files= but I think that will only make a lot of people very angry with us.

The specific part of code I am referring to deals exclusively with Multipart Files.

Right you're special casing silent behaviour for one very narrow case of something that should either be the case for everything or not. APIs cease being for humans when you have to say to yourself "Wait, will requests overwrite this header for me if I'm doing this or is it only in this other case?" every time they go back to do something. That is not a human API, that is an awful API design.

Sometimes overriding requests default behaviour is correct for user
Yes, which which is why sometimes should not dictate default behavior.

The default behaviour of requests is not wrong. The default behaviour is to trust the user that they know what they're doing.

Most developers using that code path clearly want the request to be posted as multipart.

And they will get a body that is correct for a multipart/form-data request. If they're intentionally changing the header and the server they're talking to does not understand the header, they'll figure that out. People using requests are generally rather intelligent. Most have read the documentation and understand what they need to do when creating a valid multipart/form-data request. It is often the people who do not read the documentation that run into this, go and read the documentation, and fix it themselves.

I completely agree that we should not make this change if you feel this breaks the existing API.

It's not a matter of feeling that this is backwards incompatible. It is backwards incompatible.
And let me just strongly reinforce a point @Lukasa and I seem to be unable to convey appropriately:
This is taking documented and expected behaviour that you consider to be silently broken and replacing it with behaviour that will be undocumented, unexpected, and will silently break users' code. Your justification is to fix silent behaviour but you're replacing it with inconsistent silent behaviour.

It's not a matter of feeling that this is backwards incompatible. It is backwards incompatible.

Yes, that was a bad choice of words. My Bad.

People using requests are generally rather intelligent. Most have read the documentation and understand what they need to do when creating a valid multipart/form-data request.

Thats great!

It is often the people who do not read the documentation that run into this, go and read the documentation, and fix it themselves.

Can you point to to where in the documentation I would have seen the content-type behavior. I was able to find it because I looked at the code.

So to be clear, I think we all agree that this is problematic: the only disagreement is whether we believe the problem is leaving the header alone, or the silence of the behaviour.
I'm in favour of the current behaviour, possibly with a warning or a log.

I'm in favour of the current behaviour, possibly with a warning or a log.

I think just something in the docs should suffice.
Like

I was prepared to go further, with a runtime warning, but I'm totally happy to make a documentation change right now to add warnings. We may actually want a whole section about headers that users generally shouldn't provide: Host is another.

If you explicitly provide something, we send it. You know better than us. This is a big design flaw (imo) in other HTTP libraries.

FWIW, this becomes a much bigger problem when you are trying to Proxy requests and want to maintain most of the original headers.
Having a list of headers that would potentially cause issues would be great for documentation.
@Lukasa big :+1:

@Lukasa likely shouldn't provide but are certainly able to, if needed. This is a feature, not a bug.


Output TransactionEnvelope instead of Transaction for --build-only

What
Output TransactionEnvelope instead of Transaction for --build-only
Why
Tools should always output, and accept as input, full envelopes because otherwise other tools that the inputs/outputs are used with won’t know what type of transaction we’ve given them.
It’s a bit confusing because tools always use the term ‘transaction’ to talk about what they accept as input, but in reality when tools like the Lab and others say they accept or build a transaction, they actually mean a transaction envelope.

My thought here was that signing should result in a transaction envelope.

Yeah I understand that logic and approach, but the way that other tools work is that you always pass around an envelope, because there are more than one type of transaction and the way to distinguish between them is to pass around the envelope and then within it it can have the different types. Other tools like the Lab pass around the envelope so we should do the same.


acpi power sensordon't continue if the power meter doesn't exist

fix the regression in https://github.com/sustainable-computing-io/kepler/commit/75f60857a022410fb03f6488c6a137527cae785f#diff-01d4e5e0e8a39b2a514a24ebfd7524d6d692272ef2c75a615bd7435f1b097931L177

the loop break causes the Fatalf


Fix: readme shims url

[x] I understand that this repository is auto-generated and my pull request may not be merged

Changes being requested
Fixing URL for shims readme.
Additional context & links

Thanks for the PR! As this repo is auto-generated we'll push this change separately but many thanks for raising this issue :)


Add Structure Saving Whitelist/Blacklist

It is possible to prevent some various structures from getting saved to file on extremely large worlds, wasting space. This was a feature initially requested by @bloodmc and to match Paper's patch.
Yes, I know this needs to be rebased and cleaned up since it hasn't been touched in several months now.

@bloodmc I do remember you requested this PR a while ago, if you don't mind looking this over once more before we merge it in. I'm considering chucking this into the Optimization category or something thereof.

@bloodmc I'm unsure how to cache the value during reloads since the map get structure doesn't have hooks for reloading configs.

A better fix that we can do that I was talking about earlier in irc is to prune the nbt data for a structure when that structure is 'complete'. Just disabling saving breaks both the structure generation and the locate command, but 99% of the space in the nbt is the children list which can be discarded after the structure is fully formed.

Closing as this has been merged beforehand.


fix: pass dnsconfig to agent pod. Fixes: #12824

Fixes #12824
Motivation

Pass dnsconfig to agent pod.
Modifications

Verification

Local Tests.

and argo agent

OK, Thanks.


Create demo Bitcoin transaction verification

This replaces https://github.com/CosmWasm/cosmwasm/issues/754. We now have crypto API's secp256k1_recover_pubkey and secp256k1_verify. This should be the only building blocks needed by the contract to verify Bitcoin thransaction. The rest is encoding and hashing, which is done in the contract.
In this ticket, we want a comple example of a Bitcoin transaction verification in the development contract https://github.com/CosmWasm/cosmwasm/tree/main/contracts/crypto-verify
Interesting material:

Bitcoin address derivation from secp256k1 pubkeys: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses

This is done in a different repo and can be ported over easily. Turns out that a Bitcoin signature verification does not mean you can unlock an input. So the value for a Bitcoin application is questionable. However it shows one part. Also it brings in DER signature decoding, which Ethereum did not need at the end of the day.

Out of scope for now


Fix hidpi on web

We did not use the initial scaling factor provided by winit.

Related:
https://github.com/rust-windowing/winit/issues/837
https://github.com/mapbox/mapbox-gl-native/issues/907
https://github.com/rust-windowing/winit/issues/796
https://github.com/mapbox/mapbox-gl-native/issues/919
https://github.com/baldurk/renderdoc/issues/853
https://github.com/maputnik/editor/pull/519


New homepage

Now with new color scheme!

The firs row turns out a bit decentered to the left. Unlucky situation because we have long words in a small space, but we can work around this by tweaking the ccs, changing the wording or play with margins/padding.

@erciccione rebased and fixed the issues. Apologies. The background color is intentional. We will be shifting the site to something similar over time.


[stable/chaoskube]: update to v0.6.1

This updates the chaoskube chart to its latest version which includes a flag change and a newer version of client-go (last update was around March which doesn't work well with newer clusters).

Note, the app changes for the release differences can be seen at https://github.com/linki/chaoskube/compare/v0.5.0...v0.6.1.


Fix broken link to doc for usage with Webpack

Was receiving a 404 code, adding file type extension fixed it.

I believe this is no longer relevant now that we're on v3.


Uninstall Kepler doesn't remove clusterroles, rolebindings and scc on OpenShift

When the Kepler instance is created it creates the appropriate cluster role, role bindings, SCC, and service accounts required by the exporter to run. When we uninstall the instance it removes the SA from the deployed namespace but doesn't remove cluster roles, cluster role bindings, and SCC. The removal of these also doesn't happen when we uninstall the Kepler operator itself from the cluster.
Steps to reproduce:

Deploy Kepler Operator via Operator hub on OpenShift.
Create a Kepler Instance(It can be inside the openshift-operators namespace or different)
Wait for daemonset's to come up.
Check that the cluster roles, cluster role bindings, service account, and securitycontextconstraints are created.
Delete the Kepler Instance/Operator from the console UI.

I think the removal of cluster roles, cluster role bindings, service account, and securitycontextconstraints should be handled by the Operator

@vprashar2929 this is strange. Because namespaced based resources gets deleted when we uninstall the operator. We've faced similar issues with PVCs in the past and the fix was to include the PVCs in the kepler finalizers.
Maybe we can include the scc, cluster roles, cluster role bindings and service account too.
Before that can we confirm if this is an expected behavior or that we have missed some operator-sdk implementation post operator uninstall.
@sthaha any idea?

When the Kepler instance is created it creates the appropriate cluster role, role bindings, SCC, and service accounts required by the exporter to run. When we uninstall the instance it removes the SA from the deployed namespace but doesn't remove cluster roles, cluster role bindings, and SCC.

This is a bug which can fixed by using ownerReferences
@husky-parul ☝

The removal of these also doesn't happen when we uninstall the Kepler operator itself from the cluster.

This isn't a bug and is the expected behaviour when any operator is uninstalled.
@vprashar2929

@husky-parul could you please shed some light on the use of finalizers ?

. Because namespaced based resources gets deleted when we uninstall the operator

Uninstalling the operator should not delete the kepler CR and AFAIK should not affect any running kepler instances.
Based in my limited knowledge of the operator, I don't think we need finalizers .
Can you please help  me understand the scenario that led to us adding finalizers so that I can try that on a cluster ?

Some of my observations related to this issue:
On Kepler-Operator deployment:

Kepler CRD gets installed
Kepler CSV gets installed
clusterrolebindings for Kepler-operator get configured
clusterroles for Kepler-operator get configured

On Kepler Instance creation:

clusterroles for Kepler get configured
Kepler-SCC gets configured

On removal of Kepler Instance: Clusterroles and Kepler-SCC are still available on the cluster
On removal of Kepler-Operator:

Kepler CSV gets removed
clusterrole for Kepler-operator gets removed
clusterrolebindings for Kepler-operator get removed

If this operator is creating an SCC, ClusterRole, ClusterRoleBinding it needs to use finalizers and manually cleanup these resources on it's own. This is due to the fact that Namespaced resources ie the Kepler CR, can not own a ClusterScoped resource. More on that relationship can be found here
Specifically this section.
In v1.20+, if the garbage collector detects an invalid cross-namespace ownerReference, or a cluster-scoped dependent with an ownerReference referencing a namespaced kind, a warning Event with a reason of OwnerRefInvalidNamespace and an involvedObject of the invalid dependent is reported. You can check for that kind of Event by running kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace.

The use case may differ for this operator, ie are multiple Kepler CR's allowed or not, but here is an example of what managing those resources look like. Hopefully this helps this discussion, and is not a distraction.

@acornett21 Thank you for your comments. We have been discussing this.
We releazied the issue with owner reference. for e.g.
oc get ds kepler-exporter -o jsonpath='{.metadata.ownerReferences}'

[{"apiVersion":"kepler.system.sustainable.computing.io/v1alpha1","blockOwnerDeletion":true,"controller":true,"kind":"Kepler","name":"kepler","uid":"5d9240e1-4ad3-4d14-add6-
dc8423dd0501"}]

But for clusterrole and clusterrolebindings I get owner reference as empty
oc get clusterrolebinding kepler-clusterrole-binding -o jsonpath='{.metadata.ownerReferences}'

After initial brainstorming this was our conclusion.
This brings us to two options to try:

Change Kepler CR to clusterscope and see if the ownerrefernce is getting set
If option 1 doesn't fix this we will have to implement finalizers.


ros: 1.12.1-0 in 'jade/distribution.yaml' [bloom]

Increasing version of package(s) in repository ros to 1.12.1-0:

upstream repository: https://github.com/ros/ros.git
release repository: https://github.com/ros-gbp/ros-release.git
distro file: jade/distribution.yaml
bloom version: 0.5.19
previous version for package: 1.12.0-0

mk

No changes

rosbash
* add support for fish shell (#77 <https://github.com/ros/ros/pull/77>)
* enable roslaunch args completion in rosbash

rosboost_cfg

No changes

rosbuild

No changes

rosclean

No changes

roscreate

No changes

roslang

No changes

roslib
* remove usage of CATKIN_TEST_RESULTS_DIR environment variable (#80 <https://github.com/ros/ros/pull/80>)

rosmake

No changes

rosunit

No changes

Do not merge yet! Will be merged together with other packages.


Jade won't sign PSBTs imported from text

Background
I was exploring PSBTs, and was trying to craft my own custom PSBTs and sign them using Sparrow. The main idea is to combine UTXOs from different wallets into one transaction, like a coinjoin (sort of).
I managed to learn how to craft the PSBTs using Bitcoin Core, then transfer the PSBT to Sparrow using text import. I am able to sign the PSBT for the UTXOs belonging to Sparrow software wallets with no problems, but for UTXOs belonging to a Jade I was having trouble signing them.
In order troubleshoot the issue, I tried simplifying the PSBT by removing inputs one by one until the only remaining input is the UTXO  from the Jade wallet. Even this most simple transaction with one input and one output, when crafted outside of Sparrow and imported via the Open Transaction > From Text method, was unable to be signed by Jade and failed with Failed to extract input_tx from parameters error.
Your environment

Sparrow 1.9.1 Windows Installer Edition
Bitcoin Core 26.0.0 for crafting PSBT
Blockstream Jade

Steps to reproduce

Create PSBT with one input and one output using Bitcoin Core createpsbt
Update PSBT using Bitcoin Core utxoupdatepsbt
Copy and Paste Base64 PSBT string to Sparrow Wallet using Open Transaction > From Text function.
Examine imported transaction and note that Sparrow correctly identifies input is from Jade wallet.
Click Sign button with the USB icon in the transaction tab.
Click Sign button next to the Jade in the hardware list in the popup window.
Verify the transaction on the Jade and confirm it with the hardware button on the Jade.
Sparrow returns Signing Error - Failed to extract input_tx from parameters.

Expected behaviour
Signing should be successful.
Actual behaviour
Sparrow returns Signing Error - Failed to extract input_tx from parameters.
Additional Info
Re-creating the transaction from within Sparrow itself posed no problems. Say using the following method:

Select the input UTXO in Sparrow and click Send Selected.
Key in Pay To: address and Label, set the fee and click Create Transaction >>
Click Finalize Transaction for Signing.
Click Sign button with the USB icon in the transaction tab.
Click Sign button next to the Jade in the hardware list in the popup window.
Verify the transaction on the Jade and confirm it with the hardware button on the Jade.

The transaction is exactly the same using the two methods (the Transaction Hex at the bottom of the screen are exactly the same using the two methods), but the first method won't sign.
Oh, and also, using the import PSBT method works fine when signing inputs using native Sparrow soft wallets. Only when trying to sign using Jade does this issue happen.

I appreciate all the effort in this thorough report :) But it's actually not in the right place.
As you can see from the Jade firmware source, the error is not coming from Sparrow but from the Jade itself. It appears that you haven't included the NON_WITNESS_UTXO field on your PSBT inputs, but I may be wrong. Whatever the cause, Sparrow is just the conduit here, and your issue lies with the PSBT parsing on the Jade itself.

Thank you for taking the time to answer. I am still learning and I don't understand fully how to craft a proper PSBT.
Your answer pointed me to the fact that the PSBT I fed into Sparrow is not complete and is missing the NON_WITNESS_UTXO field. It turns out that Bitcoin Core's utxoupdatepsbt function only adds WITNESS_UTXO fields, and to add NON_WITNESS_UTXO fields, I needed to run walletprocesspsbt as well.
However, this only works for UTXOs belongs to the wallet installed/mounted on the Bitcoin Core instance.
You mentioned that Sparrow is just a conduit for the PSBT. Is there a way to make Sparrow perform the PSBT Updater role, and add all the necessary info to the PSBT?
Or is there another way to do it with Bitcoin Core?
Thanks again!

If you are constructing a segwit transaction, you actually shouldn't need NON_WITNESS_UTXO. But some hardware wallets require it to prevent a low likelihood attack: https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd. Unfortunately, this approach makes PSBTs larger (and in the case of multisig, potentially much larger) which can cause hardware wallets that use QR codes to be effectively unusable. Sparrow does add the NON_WITNESS_UTXO or theWITNESS_UTXO when loading a PSBT if they are not present and available in a loaded wallet - but to avoid very large PSBTs it does not add both.
You might want to explore creating a non-segwit transaction to test if this is happening to you with the Jade.


feat: vm.parse*() helpers for reading files

Component
Forge
Describe the feature you would like
vm.readLine always reads in as a string, and therefore converting to other types like bytes32 requires dropping into assembly and removing the ascii encoding. This can be greatly simplified by a set of parse* cheatcodes that take a string and return the specified type. The full set of functions would be:
function parseBool(string calldata) external returns (bool);
function parseUint(string calldata) external returns (uint256);
function parseInt(string calldata) external returns (int256);
function parseAddress(string calldata) external returns (address);
function parseBytes32(string calldata) external returns (bytes32);
function parseBytes(string calldata) external returns (bytes memory);

A side effect of this is that we have the option of removing the envBool, envUint, etc. overloads and just havng a single env cheatcode that always return a string, and then use these methods to convert from string to the appropriate type. This would be a breaking change. Additionally, we probably still want to keep the env overloads that return arrays since they involve parsing a delimiter.
Additional context
No response

I can work on this one

@mds1 I think it can be closed as done?

Ah yep seems it didn't get linked, thanks. Closed by https://github.com/foundry-rs/foundry/pull/2854


RGB to Lab to RGB: rounding issue

Hi,
I have a problem with rounding errors when converting from Lab to RGB (this is an extract from Jupyter notebook):
red_color = "#ff0000"
rgb = sRGBColor.new_from_rgb_hex(red_color)
rgb
# result:
sRGBColor(rgb_r=1.0,rgb_g=0.0,rgb_b=0.0)

lab_color = convert_color(rgb, LabColor)
lab_color
# result: LabColor(lab_l=53.23896002513146,lab_a=80.09045298802708,lab_b=67.2013836595967)

convert_color(lab_color, sRGBColor)
# result: sRGBColor(rgb_r=1.000000195385799,rgb_g=0.0,rgb_b=2.37945055932276e-07)

The rounding error is problematic when you want to convert straightforwardly to HEX afterwards.

Hexadecimal conversion is meant to work on integers, it is not surprising that at some point you may not able to do the roundtrip.

Hi,
thanks for the reply. But it is problematic independently of HEX. The value of rgb_r is larger than one.

True!
After a quick inspection I'm tempted to say it is coming from the sRGB NPM and its reverse being rounded inadequately:
M1 = np.array(((3.24071, -1.53726, -0.498571),
               (-0.969258, 1.87599, 0.0415557),
               (0.0556352, -0.203996, 1.05707)))
M2 = np.array(((0.412424, 0.357579, 0.180464),
               (0.212656, 0.715158, 0.0721856),
               (0.0193324, 0.119193, 0.950444)))

print(np.dot(np.dot(np.eye(3), M1), M2))

# [[  1.00000044e+00  -1.19193000e-07  -3.61540000e-07]
#  [ -1.36053732e-06   9.99996099e-01  -3.46237200e-07]
#  [  1.84168000e-08  -4.76772000e-08   1.00000042e+00]]

Floating point math is fraught with fun stuff:
https://docs.python.org/2/tutorial/floatingpoint.html
I don't know if there's anything actionable on our end without moving to Decimals everywhere (bleh).
Closing unless something new comes up (re-open in that case).

Well, if you were defining xyz_to_rgb as the invert of the NPM (rgb_to_xyz) or the reverse you wouldn't get the rounding / truncation issues you have right now. We are doing it this way in Colour and it does allow for a perfect roundtrip: https://github.com/colour-science/colour/blob/develop/colour/models/dataset/srgb.py#L84
Feel free to grab the NPM too as it is more precise than the one you have currently too.


Should go sdk provide a NewClient Function and be OOP?

For instance, aliyun oss sdk and gitea go sdk both are OOP, which provide a Client struct and support a NewClient func. This enables them to support multiple sdk clients with different conf exist in the same time.
Can casdoor support Client concept and enable sdk users to connect to multiple casdoor server in the same time?
Example function demand source:  https://github.com/casbin/casibase/pull/594#discussion_r1271304392

@WinterOfBit good idea. Can you make a PR to support it?

@WinterOfBit good idea. Can you make a PR to support it?

@hsluoyz No problem. That would be quite a big api change. But should the original InitConfig func and functions depends on the global config vars be removed or remain as is for now?

@WinterOfBit keep the old usage, both global and client ways can be supported at the same time


Repo list incomplete

Hi,
I've been using this workflow for years, so many thanks for that first!
The more it's vexing that I seem to have run into some limit or something, because I'm missing many repos in my list – especially newer ones. Since I'm member of some bigger organizations, could it be there's some limit or paging?
I have tried:

rebuild local cache
get new token
rebuild local cache again (like 10x)

Nothing helped and I never got an error message.
Thanks again.

Hey, thanks for using the workflow and your feedback!
It's true that there's a limit on the number of resources it shows. I may need to think more on how to add support for paginating many results because Alfred has a limit of items you can show.

Thanks for the quick feedback! hmm, would it be easier to add some kind of filter? Particularly, I don't care for 99% of my organizations (e.g. https://github.com/orgs/python/repositories?type=all 😳) but would really like to see all of mine. 😅


[FEATURE] change styling in components/Link.js 🐧

Description
Here's an idea

Change dotted to no-underline
Add offset for underline equal to 4
Clean tailwind classes

Screenshots
Sample

https://www.w3schools.com/css/tryit.asp?filename=trycss_link_decoration

Additional information
No response

Hello there, I would like to work on this issue. Can you please assign me to this?

Thank you for your suggestion but we will be keeping the link styles we have at the moment, so I will close this issue.


Global/Affine registration dramatic overfitting

Dear Yipeng,
in my project, I'm trying to follow your approach stacking sequentially the global and local model parts. Currently, I'm facing the problem with global registration, whereby the local registration is fully functional. When I'm learning affine transformation my model is either dramatically overfitted or cannot learn anything.
In principle, the model looks like this: conv(4) > conv(8) > conv(16) > conv(32) > dence(12) > affine_ddf with stride of 2. I want to start simple and based on this develop the architecture further. I believe this configuration tends to overfit because of the dense layer with too many parameters. Another solution would be to replace dence layer with global pooling to reduce the number of parameters in this place. But in this case, the model learns nothing.
Overfitted case (with a lot parameters in dense):

Model isn't learning (i.e. global pooling):

I tried various combinations like to make the model deeper or wider (add more conv filters) and I always stuck in one of these results without any hint of how to improve the model.
Could you please share your experience training the affine transormation? Have you tried to train it separately? If it works together with the local model, then it should work separately? Am I missing something?
I hope I stated my problem clearly.  I'd appreciate all the help I can get.

The first figure looks certainly like a massive overfitting, assuming the red line is training and the blue is testing? While I can't comment on the global pooling you implemented/added, I do not believe "many parameters" is the reason of overfitting. It also could be a case of divergence - try smaller learning rate. What are the images are you working on?
Another note is that, if you goal is deformable registration, my current position is that I do not see why the affine is needed at all - see the MedIA paper for details. https://reader.elsevier.com/reader/sd/pii/S1361841518301051?token=664A1188693402D5C9CD07942B235FD8EC1A676138365501140BAF3029F736FEDEA6F0349E0338B33A9B1CF47806B7FE

Yep. The curve above represents the training data.
I simply used global average pooling after conv(12) layer to keep the model fully-convolutional. The idea behind this approach is presented here:  https://stats.stackexchange.com/a/308218
I will try to reduce the LR. Maybe it will help somehow.
I'm working on TRUS-MRI data (multimodal registration) too. The model for local registration I'm using obviously lacks of global allignment. That is why I decided to build in the affine transformation step.

How did you tell it lacks global alignment while it is functional?

The local model is trained on centriod centered data, which is only the temporal fix. It is not able to learn global displacement.

What happend when you trained on the original data without centroid initialisation?

The model cannot reach the same performance as with centroid initialisation.

LR tuning didn't impact the test accuracy. It is still pretty low.
This problem (affine registration) seemed to be quite trivial, with only 12 params to learn. No idea left what could go wrong.
Have you tried to train only affine transformation?

surprised you got results so quick! It took me around 2-3 days to get
anything converged properly...
On Fri, 9 Aug 2019 at 15:10, Oleksii Bashkanov<EMAIL_ADDRESS>wrote:

LR tuning didn't impact the test accuracy. It is still pretty low.
This problem (affine registration) seemed to be quite trivial, with only
12 params to learn. No idea left what could go wrong.
Have you tried to train only affine transformation?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/YipengHu/label-reg/issues/20?email_source=notifications&email_token=AATX37M6CXU3LDJEMPBF4NLQDV3EPA5CNFSM4IKTOY3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD36ZAFA#issuecomment-519933972,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATX37PJQKGA4HENX7LJXFTQDV3EPANCNFSM4IKTOY3A
.

Yes I have tried with only affine - it works but was more sensitive to the learning rate, but when it does not diverge, it works well.

Hi @bashkanov - i'm closing this but feel free to update us what your progress may be.

The problem with affine registration is still not resolved. But summation upscaling works well for the global registration so far.

OK - let's recap:
1 - using local only works with initialisation?
2 - does not converge using local only without initialisation?
3 - over-fitting when using affine only?
Not sure global pooling is the problem here (if implemented correctly ;p)
Which ones above are correct? @bashkanov

1 - yes, but this is already resolved. Local model become a global.
2 - no, it did converge, but there was a space for improvements.
3 - yes.
But I don't remember whether I used Dice loss with smoothed labels.
After receiving plausible results for global shifts with another approach, I didn't touch the affine network.

2 - So it is also a case of over-fitting. But this is most puzzling for me, as there is no reason the "local" net needs simple initialisation like you described - it is just a bias in displacement really. How many training data have you got? how many labels per image pair, approximately?
3 - the same as above, but it should be a bit more sensitive to initialisation and learning rate etc.

you definitely want to use smoothed labels, especially if your labels are for small ROIs.

I have approximately 150 image pairs with only  whole segmentation masks.
A bit off-topic:
In your work (weakly-supervised learning) you wrote that for comparison you have registered images in a "traditional" way:

The B-splines free-form deformation regularised by bending energy (Rueckert et al., 1999), weighting being set to 0.5 for comparison, was optimised with respect to three intensity-based similarity measures, normalised mutual information (NMI), normalised crosscorrelation (NCC) and sum-of-square differences (SSD).

I wonder what similarity measure produced the best result for you and what number of histogram bins you set for MI? I'm trying to register my test cases using elasix but now plausible results for the registration come out of there. I combine AdvancedMattesMutualInformation  with TransformBendingEnergyPenalty  with the same weights as you. I also use B-spline transformation. Here, the registered case is depicted (I think it would be very unfair to compare them with deep learning results):

What exactly free-form in "B-splines free-form deformation" means? Does it mean that there are no control points defined and each voxel is independent?

For the paper, we used the default settings in NiftyReg. It is unfair to compare with deep-learning methods, but I also would not call this "plausible" results as you showed ;)
For detailed used in  "B-splines free-form deformation", see Reuckert's paper: https://ieeexplore.ieee.org/abstract/document/796284

Sorry, it was a typo. now plausible > no plausible

Hi Yipeng,
sorry for bothering you again. I just want to ask you regarding the implementation details of the random_transform_generator function, which produces the random affine transformation without flipping.
In principle, I understand how it works. It computes the linear relation between "corner" points using Least Square methods. E.g. between S and T.
S = [[[-1., -1., -1.,  1.],
      [-1., -1.,  1.,  1.],
      [-1.,  1., -1.,  1.],
      [ 1., -1., -1.,  1.]]]

T = [[[-0.966, -0.959,  -0.91,  1.   ],
      [ -0.99, -0.973,  0.995,  1.   ],
      [-0.968,  0.938, -0.946,  1.   ],
      [ 0.918, -0.957, -0.992,  1.   ]]]

My question concerns the choice of the values in the matrix S. Why S represents exactly these 4 points?
For instance, сould we use this set instead?
S = [[[1., 1.,  1.,  1.],
      [1., 1., -1.,  1.],
      [1., -1., 1.,  1.],
      [-1., 1., 1.,  1.]]]

In your work, you wrote that the produced transformation comes without flipping. Here, the intuition is also clear, why it is guaranteed. But I want to ask, is there any fundamental and theoretical background for this topic?
Thanks!

No problems and Good questions! You can use whatever order of the points you desire, so long the old and new are consistent ;) no flipping only is ensured by no large perturbation on corners (the corner_scale parameter is small)and you don't change the sign of the coordinates - when you do want to flip to augment the data.
@bashKanov I'm closing this issue now. Please open a new one in future for easy to track. Thanks! :)


[Common] format the files

https://rbcommons.com/s/OpenH264/r/1773

conflicts, please submit a new one.

This PR should be contained in PR #2679 .
@sijchen  please check if it is necessary now.


Add alerts state

Needed an aggregation method, to not fetch the first occurrence but the most restrictive one. What does this mean? If there are 3 alert rules, and one is firing, the overall state should be firing as well, even if the other 2 are normal.
This also required to change a bit one of the methods, to allow using an array of selectors instead of only one. I will also try to send a MR to the guy upstream, because this would be nice to have it available there. I don't want to ahve many custom features when they are interesting to others as well.
This is based on the work done here: https://github.com/K-Phoen/backstage-plugin-grafana/pull/54

Apart from this the only difference to upstream is that feature for inserting "default" dashboards, yes?
Has there been a PR for that feature to upstream?  Would be rather nice to get rid of this fork at some point.

Apart from this the only difference to upstream is that feature for inserting "default" dashboards, yes?
Has there been a PR for that feature to upstream? Would be rather nice to get rid of this fork at some point.

Yes, basically the commits we have are to upgrade some packages, add that list of default dashboards and this new feature.
I have already created a MR for this upstream. I will create another one to allow injecting custom dashboards now


render_collection for STI Association

If we want to render a collection of STI Elements [Deposit, Withdrawal, Transfer, Deposit, Deposit....]  but all of them are they type AccountTransfer:: should we create individual blueprints or should we just have an AccountTransferBlueprint ?

@krtschmr did you find a solution fir this?


refined example data

Yes, that's correct @mvahowe: dcs should be the identifier for git.door43.org which is the Door43 Content Service, or the data backend to our ecosystem.


support db select option

If we need different endpoint for different metrics this can be useful

please merge this fix

Fixed in #89


Feedback for: Integrating Analytics [en]

https://github.com/google/WebFundamentals/blob/master/src/content/en/ilt/pwa/integrating-analytics.md
Can we make this code block wrap instead of side-scroll?

You'll need to wrap it in the GDoc table.

Fixed in source. Will test when we republish

republished


while adding windows agent to jenkins master iam facing a below problem can u check once ((java -jar agent.jar -jnlpUrl http://<IP_ADDRESS>:8080/computer/window/slave-agent.jnlp -secret 85f1ae15a14561c1e2a6dcb33884fb5e61208ad934996a3d027a8c0469cd9826 -workDir "C:\Users\jenkins"--------------------------------this is run a agent from command line i did cross check the link and agent.jar file also ))

hi gopichandu,

replace it with your jenkins url

resolved


About  LatentCodesPool in the code

Hi, i want to know the purpose for the design of the LatentCodesPool. The reason for designing 50% to use the previous W code?

Hi @diaodeyi,
Yes you are correct, this has been done in other GAN papers (e.g. CycleGAN) to include some memorization for the discriminator, and we thought it would be interesting to add it here as well.
Best,
Omer


RegisteredForRemoteNotifications is not called on iOS 13

Bug Information
Version Number of Plugin: 3.16
Device Tested On: iPhone 8 (iOS 13)
Simulator Tested On: N/A
Version of VS:  VSMac (8.4.8 build 2)
Version of Xamarin: <IP_ADDRESS>6
Versions of other things you are using:

Steps to reproduce the Behavior
Follow read.me:

setup xam forms project
setup firebase push notification plugin and dependencies
setup firebase site with apns certificates.

Expected Behavior
To work on iOS 13. the same code works on iOS 12 devices + Android.
Actual Behavior
It does not work on iOS 13.
Code snippet
public override bool FinishedLaunching(UIApplication uiApplication, NSDictionary launchOptions)
{
global::Xamarin.Forms.Forms.SetFlags(
"Shell_Experimental",
"Visual_Experimental",
"CollectionView_Experimental",
"CarouselView_Experimental",
"SwipeView_Experimental");
global::Xamarin.Forms.Forms.Init();
        LoadApplication(new App());

        FirebasePushNotificationManager.Initialize(launchOptions, true);
        FirebasePushNotificationManager.CurrentNotificationPresentationOption = UNNotificationPresentationOptions.Alert | UNNotificationPresentationOptions.Badge | UNNotificationPresentationOptions.Sound;

        return base.FinishedLaunching(uiApplication, launchOptions);
    }

    /// <summary>
    /// THIS METHOD IS NOT CALLED ON IOS 13
    /// </summary>
    /// <param name="application"></param>
    /// <param name="deviceToken"></param>
    public override void RegisteredForRemoteNotifications(UIApplication application, NSData deviceToken)
    {
        FirebasePushNotificationManager.DidRegisterRemoteNotifications(deviceToken);
    }

Screenshots
N/A

Same here.
The method RegisteredForRemoteNotifications is never called on a device running iOS 13.
Therefore no notifications can be received under iOS 13.

no issues here on iOS 13.3.x or 13.4

I'm facing the same issue. In iOS 12, it works great, but when I try with a device under iOS13, the registration is never called.
Maybe this is the main problem : https://dev.to/codeprototype/correctly-capture-ios-13-device-token-in-xamarin-1968

@valentin-debris the part that you have linked to has been implemented in this library.
I have this working great in iOS13 which is making me thing you might be missing a config somewhere - as the current version of the lib def works in iOS13....

@Lydecker , what version of the plugin are you using ? The latest stable or the beta one ?
The strange thing is if I plug an iPhone with iOS12, no problem, but the other one under 13 doesn't trigger the overrided functions at all...

@valentin-debris 3.1.6 (and I'm not using one of the forks of the main repository).
What about yourself?

@Lydecker , I ended up make it works. I was using the beta one (3.2.9), but getting back to 3.16 AND adding the nuget Xamarin.ios.CloudMessaging (4.1.1) works now. Without the CloudMessaging, the app crashs.
src : https://github.com/xamarin/GoogleApisForiOSComponents/issues/311#issuecomment-546046465


Show file sizes in movie summaries

I have multiple copies of some movies in my library because I have transcoded some to a smaller format (to put on a phone, for instance).  When I look through the movies listed the preview has a convenient button for downloading to my phone, and shows info such as the film length, year, ratings, etc.  But the most important piece of information to me is often the file size.  It would be great to add it to the summary of data available.

#253 The size is available in the media file list view

@tomerf has implemented showing the file size on the "Files" section, which i think is the appropriate place to show it. I'm not a fan of showing the file size in the movies/tv shows summary - the metadata that's available there is more useful and i don't like cluttering up the interface.
I'll be closing this one. I'm not extremely opposed to it, but i don't think that it's something the majority of users would benefit.


feat: Canyon hardfork behind optimism feature flag

Overview
Adds the Canyon hardfork behind the optimism feature flag, and adds a macro to define the SpecId enum to separate the ordering of hardforks between L1 and optimism.
The Canyon hardfork does not implement any EVM changes, though it does implicitly enable Shanghai.
More information about Canyon can be found in the upstream tracking issue: https://github.com/ethereum-optimism/optimism/issues/7452

Just to note here, I created this change on the top of the https://github.com/bluealloy/revm/commit/1609e07c68048909ad1682c98cf2b9baa76310b5 commit. This "parent" commit is used inside reth and the idea is to freeze revm as there are some breaking revm changes so it would be less painful.


Add schedules

Add schedules so we can link to it from the Backups page.

@feddovanede The Archived App and Access Logs section in this page already has an alert about this: "For apps deployed to Mendix Cloud, logs are rotated and archived every day. They are retained for six months." Would it work to just link to that existing heading?

I messed that 🤦 For Backups we do have a separate paragraph with the retention schedule. If w add it to the Logs as well, the pages would align better, I think?


Is it safe to remove element without remove handler ?

Is it safe to remove element without remove handler ?
In some cases, the element is removed without any chance to remove listeners. will this cause any problem like memory leaking?

Yes, since all listeners are attached to the element itself it should get garbage collected when removed from the DOM. We too remove the elements freely, and haven't noticed any problems.

thanks


WIP: Mutex

Using mutex should protect structure from race-conditions during concurrent access to its fields.
I need to perform more tests but hopefully fixes https://github.com/piraeusdatastore/piraeus-ha-controller/issues/7

Just FYI: I don't think a mutex will solve this issue. The updates to that struct are all done from a single thread/goroutine, Thats the big "for" loop that reconciles the state of the world. There may be some issue that causes it to miss some updates but I'm pretty sure a mutex won't help.

@WanzenBug ok, afaik select is reading from the channels randomly, not consequentially. Since we're having too many channels with the updates, I guess it can cause such issues, isn't it?
https://github.com/piraeusdatastore/piraeus-ha-controller/blob/0dc2b4419533d2a294991da9976c3cfac6b8b6c9/pkg/hacontroller/controller.go#L143-L157

I guess. But there should be at least 30/45 seconds between the PV being attached and the "fail" update arriving. I would be surprised if the VA and PVC updates didn't arrive in time.
Maybe there is some issue with the watch/resync logic that missed some updates.

Since the rewrite, we are re-using the existing k8s.io/client-go objects that do local caching much better than us. So I'm closing this.


Rename IdealMask to OracleMask

OracleMask might better encompass other types of masks that this could produce.

We have IdealRatioMask and IdealBinaryMask now. The former can be used to either do magnitude-sensitive spectrum approximation or phase-sensitive spectrum approximation.


[Suggestion] Can you maybe make the sky villages generate a lot higher in the sky?

Whenever they generate in the world they always leave behind large amounts of darkness on the ground that spawns a lot of monsters, plus I think if the villages were higher it would look a lot better.

Hi, thank you for your feedback. the idea you have is already included in the next update! :) the update will appear on CurseForge within 3 days Support, Mei


MCA onehot handle unknown

I'm trying to change the onehot encoder in your code by adding handle_unknown = 'ignore' in the super init(),  but I always get the error of init() got an unexpected keyword argument 'handle_unknown'. Any ideas on how to solve this?

It's OK, i think I solved it.

I love these kind of issues.

@DRL36 how did you solve it?


nixos/your_spotify: init at 1.8.0

Description of changes

This PR adds your_spotify a self hosted spotify dashboard.
This includes package, module and nixos tests.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[x] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Sadly the upstream mongo does not compile currently. I've tested it with a binary mongodb using the prebuild debian packages but this probably can't  be upstreamed and since the package depends on mongodb this means it can't be tested using current nixpkgs.

I've addressed all comments and fixed all build errors.

Updated to newest version

Fixed build error. I needed to copy the package.json into nixpkgs as Hydra has a problem with IFD which I didn't know cause on my machine it worked perfectly. Should be finished now.


Where does mupx deploy write files?

Do I understand it correct that mupx deploy will create a prepared copy of my meteor app?
Where does it create those files?
How to remove a deployed app?

I think it's /opt/appName
stop it first remove it
maybe stop mongo
typically the kubernettes container can be destroyed as easily as its created and removal is a meaningless question as I understood it.
personally I'd rather see a shared folder AWS EFS and have a remove option.
just waiting on EFS for now myself.

Thank you !


Detects a calver for google-cloud-python-happybase but it uses semver

running releasetool start with the latest version, gcp-releasetool-2019.1.25 results in
> Figuring out what the last release was.
The last release was 0.32.1.
> Gathering changes since 0.32.1
Cool, 2 changes found.
> Opening your editor to finalize release notes.
Releasing 2019.02.05.

#93 was a previous issue that was very much like this.

This happens because autorelease assumes that releasetool/synthtool is being released if the repo is not google-cloud-python. This should be updated so that other Python repo's using semver can be released using releasetool.


Can not logging into heroku toolbelt on Ubuntu

Error:       connect timeout reached (Excon::Errors::Timeout)
Command:     heroku login
Version:     heroku-toolbelt/3.42.21 (x86_64-linux) ruby/2.2.3
Error ID:    1293c11ae0e84f5798070e256b2d2430

Could you please try this again?  It sounds like it could have been a temporary network error.


Added my profile to the README

Hey, Eddie I have updated the README and added my profile to it.

Looks good 👍 , I left a couple of small comments 🤓

I have made the changes!
Please merge it

Thanks @Jaynil1611 , there is still 1 more comment

Did that one two!

Please check again, it still showing the extra trailing space has been added, I left a comment on the line 108


expand key_source documentation to include example

key source is documented abstractly, would be good to provide a usage example

Great work with the key_source explanation.  Two minor points noted below.  Thank you.

The example described in the Custom key source section is missing.
Additionally, the text below is duplicated:
A custom key source can be configured by setting the key_source property within a table class, after the definition string.


Fix overlinking in SWIG python library

This PR fixes the annoying overlinking issues in the SWIG python library.
Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


req.headers.get is not a function (TRPC pages router)

Im encountering an error when trying to implement this:
https://github.com/c-ehrlich/next-axiom-trpc-example/tree/main/pages-router
 GET /api/trpc/notifications.getCountOfUserNotifications,auctions.getAuctionsHeroHome,auctions.getAuctionsEndingSoonHome,auctions.getFeaturedAuctionsHome?batch=1&input=%7B%220%22%3A%7B%22json%22%3Anull%2C%22meta%22%3A%7B%22values%22%3A%5B%22undefined%22%5D%7D%7D%2C%221%22%3A%7B%22json%22%3Anull%2C%22meta%22%3A%7B%22values%22%3A%5B%22undefined%22%5D%7D%7D%2C%222%22%3A%7B%22json%22%3Anull%2C%22meta%22%3A%7B%22values%22%3A%5B%22undefined%22%5D%7D%7D%2C%223%22%3A%7B%22json%22%3Anull%2C%22meta%22%3A%7B%22values%22%3A%5B%22undefined%22%5D%7D%7D%7D 500 in 22ms  ⨯ TypeError: req.headers.get is not a function     at C:\work\stringtree-nextjs\nextjs\node_modules\next-axiom\dist\withAxiom.js:75:31     at Generator.next (<anonymous>)     at C:\work\stringtree-nextjs\nextjs\node_modules\next-axiom\dist\withAxiom.js:8:71     at new Promise (<anonymous>)     at __awaiter (C:\work\stringtree-nextjs\nextjs\node_modules\next-axiom\dist\withAxiom.js:4:12)     at C:\work\stringtree-nextjs\nextjs\node_modules\next-axiom\dist\withAxiom.js:56:26     at eval (webpack-internal:///(api)/./src/server/tools/axiomMiddleware.ts:15:92)     at K (C:\work\stringtree-nextjs\nextjs\node_modules\next\dist\compiled\next-server\pages-api.runtime.dev.js:21:2877)     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)     at async U.render (C:\work\stringtree-nextjs\nextjs\node_modules\next\dist\compiled\next-server\pages-api.runtime.dev.js:21:3955)     at async DevServer.runApi (C:\work\stringtree-nextjs\nextjs\node_modules\next\dist\server\next-server.js:600:9)     at async NextNodeServer.handleCatchallRenderRequest (C:\work\stringtree-nextjs\nextjs\node_modules\next\dist\server\next-server.js:269:37)     at async DevServer.handleRequestImpl (C:\work\stringtree-nextjs\nextjs\node_modules\next\dist\server\base-server.js:816:17)     at async C:\work\stringtree-nextjs\nextjs\node_modules\next\dist\server\dev\next-dev-server.js:339:20     at async Span.traceAsyncFn (C:\work\stringtree-nextjs\nextjs\node_modules\next\dist\trace\trace.js:154:20) {   page: '/api/trpc/[trpc]' }
Thats the error im encountering, it happens on every call i make to the backend via TRPC.
The problem arises when i implement withAxiom in pages/api/trpc/[trpc].ts
I see that the package uses "req.headers.get", i tried to patch the headers im sending with no luck. Is this a common issue?
Here are my TRPC context without axiom:
`const createInnerTRPCContext = ({ auth, req }: AuthContext) => {
return {
auth,
prisma,
req,
}
}
export const createTRPCContext = (opts: CreateNextContextOptions) => {
return createInnerTRPCContext({
req: opts.req,
auth: getAuth(opts.req),
})
}`
Im trying to implement this because i linked the application with Vercel but my function logs are not showing on the Axiom dashboard

I'm running into this same issue. It not only fails to log, it causes all my trpc requests to fail.

I'm not sure. In my case, I was upgrading from an old version of axiom (v0.17) at the same time I was upgrading my project from nextjs v12 to v14. In addition to the trpc errors I was experiencing, the public endpoints in the app also had unexpected behavior. It looks like some types/functionality were removed to support nextjs 14, but those changes appear to have removed support for using axiom with api requests. I ended up forking next-axiom v0.17 and publishing to a private npm registry with updated peer dependencies that include nextjs 14.

Came here to report the same issue. This issue makes it impossible to use next-axiom for wrapping API routes, as described in the README file in the root of this project.
⨯ TypeError: req.headers.get is not a function
    at /Users/vlucas/Code/my-project-name-here/node_modules/next-axiom/dist/withAxiom.js:75:31
    at Generator.next (<anonymous>)
    at /Users/vlucas/Code/my-project-website/node_modules/next-axiom/dist/withAxiom.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/Users/vlucas/Code/my-project-website/node_modules/next-axiom/dist/withAxiom.js:4:12)
    at /Users/vlucas/Code/my-project-website/node_modules/next-axiom/dist/withAxiom.js:56:26
    at K (/Users/vlucas/Code/my-project-website/node_modules/next/dist/compiled/next-server/pages-api.runtime.dev.js:21:2877)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async U.render (/Users/vlucas/Code/my-project-website/node_modules/next/dist/compiled/next-server/pages-api.runtime.dev.js:21:3955)
    at async DevServer.runApi (/Users/vlucas/Code/my-project-website/node_modules/next/dist/server/next-server.js:598:9)
    at async NextNodeServer.handleCatchallRenderRequest (/Users/vlucas/Code/my-project-website/node_modules/next/dist/server/next-server.js:269:37)
    at async DevServer.handleRequestImpl (/Users/vlucas/Code/my-project-website/node_modules/next/dist/server/base-server.js:810:17)
    at async /Users/vlucas/Code/my-project-website/node_modules/next/dist/server/dev/next-dev-server.js:339:20
    at async Span.traceAsyncFn (/Users/vlucas/Code/my-project-website/node_modules/next/dist/trace/trace.js:154:20)
    at async DevServer.handleRequest (/Users/vlucas/Code/my-project-website/node_modules/next/dist/server/dev/next-dev-server.js:336:24) {
  page: '/api/my-api-route'

Still having the same issue.
My current workaround is to just log something like this:
`import { Logger } from 'next-axiom'
export const logWithAxion = async (type: 'info' | 'error' = 'info', ...args: any[]) => {
try {
const message = args
.map((arg) => (typeof arg === 'object' ? JSON.stringify(arg, getCircularReplacer()) : String(arg)))
.join(' ')
console.log(message)
    const log = new Logger()
    log[type](message)

    await log.flush()
} catch (error) {
    console.error('Error logging with Axiom', error)
}

}`
however this is not ideal


Nuts models

#229
The SV model is unfinished - not sure what does the last term of equation 23 mean.

That's a student-t distribution, see e.g. https://en.wikipedia.org/wiki/Student's_t-distribution

@xukai92 are we ready to merge this PR now?

Yes let's merge it


bug: CoreLink is not working in native-mobile

Describe the bug
There is two issue with CoreLink and all possible props has been added in validProps

We have to wrapped CoreLink with any other wrappid components in web then it is working.
CoreLink is not working in mobile.

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Stack Trace
The stack trace of the bug if any.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

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

Smartphone (please complete the following information):

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

Additional context
Add any other context about the problem here.

I have just adds props related to the component. Mobile problem related to the component is still there.


Update Docker FROM to senzing/senzingapi-tools:3.2.0

See https://github.com/Senzing/community-roadmap/issues/65

PR merged, release created.


Install tobiko project in the tobiko tcib image

With [1] there is CLI tool introduced in Tobiko. It can be used e.g. to run "tobiko ping" command. To be able to run such CLI command from the openstack-tobiko tcib image, Tobiko needs to be installed there, not only cloned.
[1] https://review.opendev.org/c/x/tobiko/+/935666
Related: #TOBIKO-100

/lgtm


[WIP]: internal/fs: add EquivalentPaths function

What does this do / why do we need it?
Add a new method to internal/fs to check for path equivalence.
What should your reviewer look out for in this PR?
Does this work as expected?
Which issue(s) does this PR fix?
fixes #772
fixes #805

@sdboyer I believe I found a bug in fs.HasFilepathPrefix...
I wasted a few hours debugging the implementation EqualPaths and it seems that HasFilepathPrefix has a bug on case-insensitive filesystems on *nix.
This where it happens:
	// d,p are initialized with "" on *nix and volume name on Windows
	d := vnPath
	p := vnPrefix

The next for loop always assume that the filesystem is case-sensitive since isCaseSensitiveFilesystem returns false when the passed dir doesn't exist.
This happens because filepath.Join("", "dirName") returns "dirName" and therefore assumes to be a relative path. On *nix, d and p are defaulting to "" instead of "/" and joining then with additional directory names results in a relative path.
	for i := range prefixes {
		// need to test each component of the path for
		// case-sensitiveness because on Unix we could have
		// something like ext4 filesystem mounted on FAT
		// mountpoint, mounted on ext4 filesystem, i.e. the
		// problematic filesystem is not the last one.
		if isCaseSensitiveFilesystem(filepath.Join(d, dirs[i])) {
			d = filepath.Join(d, dirs[i])
			p = filepath.Join(p, prefixes[i])
		} else {
			d = filepath.Join(d, strings.ToLower(dirs[i]))
			p = filepath.Join(p, strings.ToLower(prefixes[i]))
		}

     // ...
}

isCaseSensitiveFilesystem has not tests, and it's quite hard to test honestly... And the tests for HasFilepathPrefix don't cover this case.
I've pushed a commit with my proposed fix, which is to update both isCaseSensitiveFilesystem and HasFilepathPrefix.

well that's some catastrophic failure on linux :(

I figured out what's happening finally. 😓
A non-existing file error wasn't being handled properly.

@sdboyer Should we merge this? 😀

@ibrasho Could you please tell me why you are not using os.SameFile? I ran the tests(TestEquivalentPaths) successfully with this modification on windows and linux:
func EquivalentPaths(p1, p2 string) (bool, error) {
    p1 = filepath.Clean(p1)
    p2 = filepath.Clean(p2)

    fi1, err := os.Stat(p1)
    if err != nil {
        return false, errors.Wrapf(err, "could not check for path equivalence")
    }
    fi2, err := os.Stat(p2)
    if err != nil {
        return false, errors.Wrapf(err, "could not check for path equivalence")
    }

    return os.SameFile(fi1, fi2), nil
}

Could you please tell me why you are not using os.SameFile?

i'd swear we have a good reason for this, because we certainly knew that function existed beforehand. i can't remember that reason now, though 😢

Hmm.. What do you suggest we do? I can make a PR with the changes above. We can see if everything works as expected.

We can see if everything works as expected.

no, we need to trace back over the lines of thinking that got us to here. hasty PRs in areas related to casing just lead to more headaches; "see if everything works as expected" is not something we can do, as there is no well-formed definition of "everything," let alone one codified into tests.

Okay. At the very least, we should identify and add a test which fails for os.Samefile but not the current implementation.

@sudo-suhas As Sam has said, we are trying to handle something that os.SameFile doesn't.
If I remember correctly, it has to do with nested filesystems that handle case-sensitivity differently. But I can't remember the exact case. 😕


LWJGL3 with RoboVM?

Would it be possible to use LWJGL3 OpenGL ES or Vulkan bindings with RoboVM?
I am aware RoboVM provides bindings for OpenGL ES but i am interested in building a game engine using LWJGL bindings.
I know the Vulkan bindings use MoltenVK on Mac OS, is there a way to use the MoltenVK build for ios?

LWJGL probably won't play well with AOT compilation, but I haven't tried it.
The bundled MoltenVK is built for x64, a separate ARM build is required for iOS, which LWJGL does not provide.


Connection refused (111)

Hi, i'm getting this problem, what is the reason?
INFO: Trying tls://gateway.sandbox.push.apple.com:2195
Fri, 18 Mar 2016 17:48:00 +0100 ApnsPHP[126138]: ERROR: Unable to connect to 'tls://gateway.sandbox.push.apple.com:2195': Connection refused (111)

Fixed by asking the server manager to open the port number 2195 in the server's firewall.
Thanks.


Error when using AWS SDK 2.18 for S3 operations

Upgrading to the newly release SDK 2.18, S3Mock is returning an error when our tests create a bucket on setup:
software.amazon.awssdk.services.s3.model.S3Exception: null (Service: S3, Status Code: 405, Request ID: null).
Our client is created like:
S3Client.builder()
       .region(Region.US_EAST_1)
       .credentialsProvider(
               StaticCredentialsProvider.create(AwsBasicCredentials.create("foo", "bar")))
       .endpointOverride(URI.create(s3Mock.getHttpsEndpoint()))
       .httpClient(new DefaultSdkHttpClientBuilder().buildWithDefaults(attributeMap))
       .build();

The SDK release notes for 2.18.0 mention:

It is important to know that EndpointProviders and the endpoint override on the client are not mutually exclusive. In all existing cases, the endpoint override is passed as a parameter to the the provider and the provider may modify it. For example, the S3 provider may add the bucket name as a prefix to the endpoint override for virtual bucket addressing.
There may be some behavior changes related to endpoint resolution as as the the endpoint resolution is now standardised across SDKs so this release also bumps the minor version of the SDK to 2.18.
Notably, there are some changes in S3: when including and endpoint override, the SDK will use virtual bucket addressing as long as the bucket is a valid DNS label. This is different from the previous behavior where this only happens if the endpoint override begins with 's3'.

Turning on request logging, I see a difference between requests issued with client 2.17:
[main] DEBUG org.apache.http.wire:73 - http-outgoing-0 >> "PUT /bucket HTTP/1.1[\r][\n]"
[main] DEBUG org.apache.http.wire:73 - http-outgoing-0 >> "Host: localhost:49405[\r][\n]"

and those issued with client 2.18:
[main] DEBUG org.apache.http.wire:73 - http-outgoing-0 >> "PUT / HTTP/1.1[\r][\n]"
[main] DEBUG org.apache.http.wire:73 - http-outgoing-0 >> "Host: bucket.localhost:49402[\r][\n]"

Note that the bucket name is now in the DNS address and not the HTTP path.  The S3 docs also now reflect that.
I suspect, but haven't confirmed, that other operations besides CreateBucket will be affected by this as well.
Looks like dependabot has created you a PR to upgrade the client, which appears to be failing with the same error:
https://github.com/adobe/S3Mock/pull/878

@bpfoster S3Mock currently does not support bucket access by subdomain, only path style access is supported.
See #144 - I have an idea on how to implement this, but it may be a breaking change as that I may have to disable path style access for this to work.
This is currently tentatively scheduled for the last update of v2 in S3Mock, see CHANGELOG
It seems that up until 2.18, the SDKv2 used path style access as a default, or maybe used some negotiation to find out if path style access is needed.
Starting with 2.18, path style access needs to be enabled when creating the client:
S3Client.builder()
.serviceConfiguration(S3Configuration.builder().pathStyleAccessEnabled(true).build())
.build();

This is not a breaking change for clients of the SDK if you use S3 as a backend, but it is if you are using any backend that does not support subdomain access like S3Mock...

Just realized: this one will be a pain in the neck - it will essentially break every integration test in existence where the service accessing S3 is using AWS SDKv2 for Java... :(

Ah, sorry I missed #144, that's definitely related.  Please feel free to close this if you see it as a duplicate.
That's good to know that we can force path style access like in your sample, though the further my test client configuration gets from the production client configuration, the less faith I have in the test...
If I read the release notes correctly, it seems that prior to 2.18, SDKv2 would use subdomain style access as a default, unless an endpoint override was configured - which obviously all S3Mock uses would have set.
I think you're right that SDK v2.18+ will break all existing tests using S3Mock which is not great.
If I completely ignore the complexities of actually doing it :smile: , ideally I think you would want to support both subdomain and path style access.
Specifically I say this because the way one of our CI runners executes, the s3Mock.getHttpsEndpoint() returns an IP address (not localhost or other hostname).  This is at least one case where the SDK seems to automatically fall back to path style access regardless of other configuration.  The same exact code, when running locally, will use localhost and therefore use subdomain style access.  So, I'm not sure you could disable path style access.

I just updated the usages of AWS SDKv2 in S3Mock, fixing our immediate problem allowing us to update the SDK version.
I have started working on subdomain support, but can't say yet if the implementation is backwards compatible or not.


PeerConnection

Crash
When try to disconnect room, i got a crash. The crashlog that i got. Any idea for it?
Non-fatal Exception: java.util.concurrent.ExecutionException: java.lang.NullPointerException: Attempt to invoke virtual method 'void livekit.org.webrtc.RtpTransceiver.dispose()' on a null object reference
at java.util.concurrent.FutureTask.report(FutureTask.java:123)
at java.util.concurrent.FutureTask.get(FutureTask.java:193)
at mh.d.a(SourceFile:40)
at dh.c1.b(SourceFile:78)
at dh.w1.j(SourceFile:1714)
at dh.q1.a(SourceFile:18)
at fj.h0.m(SourceFile:168)
at fj.g0.invokeSuspend(:12)
at mi.a.resumeWith(:8)
at cj.g0.run(:107)
at c7.n.run(SourceFile:15)
at jj.i.run(:2)
at jj.a.run(SourceFile:94)

please retest on latest version


When does firebase-admin-java get new release? No updates almost a year

[READ] Step 1: Are you in the right place?

For issues or feature requests related to the code in this repository
file a Github issue.

If this is a feature request make sure the issue title starts with "FR:".

For general technical questions, post a question on StackOverflow
with the firebase tag.
For general Firebase discussion, use the firebase-talk
google group.
For help troubleshooting your application that does not fall under one
of the above categories, reach out to the personalized
Firebase support channel.

[REQUIRED] Step 2: Describe your environment

Operating System version: _____
Firebase SDK version: _____
Library version: _____
Firebase Product: _____ (auth, database, storage, etc)

[REQUIRED] Step 3: Describe the problem
Steps to reproduce:
What happened? How can we make the problem occur?
This could be a description, log/console output, etc.
Relevant Code:
// TODO(you): code here to reproduce the problem

We are planning a new release with some dependency upgrades this week. Thanks!


Fix bug where AttachmentImages can't be used in multiple descriptor sets at the same time

This fixes #1557 It seems to work just fine with all the tests I did.

[x] Ran cargo fmt on the changes

A layout transition is a write operation, which means that concurrent access to the same image should not be allowed. Pipeline barriers protect against access on the same queue, but not another queue. The change you propose would introduce a data race if the image is concurrently accessed by another queue.
The lock_submit and check_image_access functions further down rely on the exclusive value to provide the correct locking for the image. If exclusive is false, then this locks the image only for reading, which allows a command buffer on another queue to be executed while this image is in use, without the insertion of a semaphore. If the first queue is actually writing to the image at that time, that's a synchronisation error.

Oh. I wasn't aware that the exclusive flag is being used for cross-command buffer dependencies. I will think of a different fix.

@faulesocke Please ping me when it's ready for the final review. Thanks!

@faulesocke Any updates regarding this PR?

@Eliah-Lakhin sorry I haven't had time for this and probably won't have time for another month or two.

Is there any update on this?

@fayalalebrun Does the commit #a03cfa0 mean this can be closed?

@vE5li No, that's for a fork of Vulkano and doesn't address the underlying issue.

Ah, my bad :)


🐛 Fix the deletion step order and OwnerReference matching

What this PR does / why we need it:
This PR fixes the order of the deletion steps for Metal3Machine to prevent a NPE (#22)
It also changes the way the OwnerReferences are matched to not take into account the version, that
might change after an upgrade.
Which issue(s) this PR fixes:
Fixes #22

/cc @kashifest
/cc @fmuyassarov
/cc @Xenwar

/test-v1a3-integration

/test-integration

/test-integration

I find it confusing that 'baremetal' is still used in parameter names and directory or file names.

We will anyways not solve this on this PR. Maybe a next one

looks good to me, but the tiny nit, why in some places we still have BM* instead of M3*?

We could fix this. Maybe in another PR ?

/lgtm


🐞 files deleted when running bash action

What is the issue?
When a bash action fails, there is a chance dagger will wipe a bunch of files, including git related files, It usually renders the git repo unusable, requiring a clean clone.
The set of deleted files is not always the same and not always are files deleted. In the following screenshot I ran the action 3 times, but only the third time the files were deleted:

Steps to reproduce
git clone git@github.com:tomas-mota/dagger-testing.git
cd dagger-testing
dagger do run (might need to run this more than once)

Dagger version
dagger 0.2.5 (7d2f279c) linux/amd64
OS version
Ubuntu 20.04 on wsl

@tomas-mota Hi 👋
Is this issue still active? Could you find a way to solve it?

It looks like this is from quite an old version of dagger - we've changed so much since then, so it's likely that this issue isn't relevant any more, so I'm going to close it.
If it's still relevant, we can re-open easily! :tada:


[MBUILDCACHE-39] Fixed multi module hash logic

Avoid the current module (B) to be re-built if it depends on a module (A) of the current project which has some of its files edited. It would have no sense to re-build module B just because module A was edited. The previous behavior invalidated the whole caching purpose.
Following this checklist to help us incorporate your
contribution quickly and easily:

[x] Make sure there is a JIRA issue filed
for the change (usually before you start working on it).  Trivial changes like typos do not
require a JIRA issue.  Your pull request should address just this issue, without
pulling in other changes.
[x] Each commit in the pull request should have a meaningful subject line and body.
[x] Format the pull request title like [MNG-XXX] - Fixes bug in ApproximateQuantiles,
where you replace MNG-XXX with the appropriate JIRA issue. Best practice
is to use the JIRA issue title in the pull request title and in the first line of the
commit message.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Run mvn clean verify to make sure basic checks pass. A more thorough check will
be performed on your pull request automatically.
[x] You have run the Core IT successfully.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

[x] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

[x] In any other case, please file an Apache Individual Contributor License Agreement.

reference to MBUILDCACHE-39 doesn't look right.


stop sending tool output to dev null instead of logs

Remove this from raspir and growth_rate steps, retry.
error and log handling likely more robust within nextflow than previously

>/dev/null 2>&1

Testing seems ok so far, remove all /dev/null entries
Logs go into .command.log and .err in the nextflow work directories

done


test_wheel.py::test_local_lib failure in CI

Test failure just observed in https://github.com/FFY00/meson-python/runs/7202624920?check_suite_focus=true. This should be due to the Meson 0.63.0 release on July 3rd (2 days ago):
________________________________ test_local_lib ________________________________
virtual_env = PosixPath('/tmp/mesonpy-test-venv-n30nt69r/bin/python')
wheel_link_against_local_lib = PosixPath('/tmp/pytest-of-runner/pytest-0/test0/mesonpy-test-1jnqmmle/link_against_local_lib-1.0.0-py3-none-linux_x86_64.whl')
    @pytest.mark.skipif(platform.system() != 'Linux', reason='Unsupported on this platform for now')
    def test_local_lib(virtual_env, wheel_link_against_local_lib):
        subprocess.check_call([virtual_env, '-m', 'pip', 'install', wheel_link_against_local_lib])
>       subprocess.check_output([
            virtual_env, '-c', 'import example; print(example.example_sum(1, 2))'
        ]).decode() == '3'
virtual_env = PosixPath('/tmp/mesonpy-test-venv-n30nt69r/bin/python')
wheel_link_against_local_lib = PosixPath('/tmp/pytest-of-runner/pytest-0/test0/mesonpy-test-1jnqmmle/link_against_local_lib-1.0.0-py3-none-linux_x86_64.whl')
tests/test_wheel.py:119:
...
---------------------------- Captured stdout setup -----------------------------
! Using Meson to generate the project metadata (no `project` section in pyproject.toml)
+ meson setup --native-file=/home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib/.mesonpy-native-file.ini -Ddebug=false -Dstrip=true -Doptimization=2 --prefix=/opt/hostedtoolcache/Python/3.11.0-beta.3/x64 /home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib /home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib/.mesonpy-7s3pci72/build
The Meson build system
Version: 0.63.0
Source dir: /home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib
Build dir: /home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib/.mesonpy-7s3pci72/build
Build type: native build
Project name: link-against-local-lib
Project version: 1.0.0
C compiler for the host machine: cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0")
C linker for the host machine: cc ld.bfd 2.34
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Run-time dependency python3 found: YES 3.8
Program python3 found: YES (/home/runner/work/meson-python/meson-python/.nox/test-3-11/bin/python)
Build targets in project: 2
link-against-local-lib 1.0.0
  User defined options
    Native files: /home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib/.mesonpy-native-file.ini
    debug       : false
    optimization: 2
    prefix      : /opt/hostedtoolcache/Python/3.11.0-beta.3/x64
    strip       : true
Found ninja-1.10.2.git.kitware.jobserver-1 at /home/runner/work/meson-python/meson-python/.nox/test-3-11/bin/ninja
+ meson compile
[1/5] Compiling C object libexample.so.p/examplelib.c.o
[2/5] Linking target libexample.so
[3/5] Compiling C object example.cpython-311-x86_64-linux-gnu.so.p/examplemod.c.o
[4/5] Generating symbol file libexample.so.p/libexample.so.symbols
[5/5] Linking target example.cpython-311-x86_64-linux-gnu.so
+ meson install --destdir /home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib/.mesonpy-7s3pci72/install
ninja: Entering directory `/home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib/.mesonpy-7s3pci72/build'
ninja: no work to do.
Installing libexample.so to /home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib/.mesonpy-7s3pci72/install/opt/hostedtoolcache/Python/3.11.0-beta.3/x64/lib/x86_64-linux-gnu
Stripping target 'libexample.so'.
Installing example.cpython-311-x86_64-linux-gnu.so to /home/runner/work/meson-python/meson-python/tests/packages/link-against-local-lib/.mesonpy-7s3pci72/install/opt/hostedtoolcache/Python/3.11.0-beta.3/x64/lib/python3.11/site-packages
Stripping target 'example.cpython-311-x86_64-linux-gnu.so'.
WARNING Using heuristics to map files to wheel, this may result in incorrect locations
Copying files to wheel...
[0/1] example.cpython-311-x86_64-linux-gnu.so
[1/1] .link_against_local_lib.mesonpy.libs/libexample.so
----------------------------- Captured stdout call -----------------------------
Processing /tmp/pytest-of-runner/pytest-0/test0/mesonpy-test-1jnqmmle/link_against_local_lib-1.0.0-py3-none-linux_x86_64.whl
Installing collected packages: link-against-local-lib
Successfully installed link-against-local-lib-1.0.0
----------------------------- Captured stderr call -----------------------------
WARNING: You are using pip version 22.0.4; however, version 22.1.2 is available.
You should consider upgrading via the '/tmp/mesonpy-test-venv-n30nt69r/bin/python -m pip install --upgrade pip' command.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: dynamic module does not define module export function (PyInit_example)
----------- coverage: platform linux, python 3.11.0-beta-3 -----------
Coverage HTML written to dir /home/runner/work/meson-python/meson-python/.nox/test-3-11/htmlcov
Coverage XML written to file /home/runner/work/meson-python/meson-python/.nox/test-3-11/coverage-3.11.xml
=========================== short test summary info ============================
FAILED tests/test_wheel.py::test_local_lib - subprocess.CalledProcessError: C...

This is due to https://github.com/mesonbuild/meson/pull/10369, because it only occurs for Python >= 3.9 with a missing PyInit_* symbol. The puzzling thing is that it only fails for this one test, and that PyMODINIT_FUNC is used correctly. While in the one other test case that has it, it looks like there's a bug. And I cannot reproduce it locally yet.

I triggered a re-rerun anyway.

This was due to some issues with the test projects definitions. Has been fixed in #198.


minor:corrected translation

Description
French translation for "Step" in this context is "Étape"
Checklist
Please read and apply all contribution requirements.

[x] This PR targets the dev branch (NEVER master)
[x] Documentation reflects all relevant changes
[x] Branch is prefixed with: docs/, feat/, chore/, bugfix/
[x] Ensure Svelte and Typescript linting is current - run pnpm check
[x] Ensure Prettier linting is current - run pnpm format
[x] All test cases are passing - run pnpm test
[x] Includes a changeset (if relevant; see above)

Thanks for the correction @leElvyn!


Remove only branch is master for now

@nearmax It seems a bug that travis didn't trigger for master branch. Remove only: master to see if it runs for master

@ailisp would you like me to merge it?

@nearmax I just merge it