Add a function for querying whether a certificate exists

We're using this to opportunistically redirect to https in the openresty proxy like so:
rewrite_by_lua_block {
  local has_cert = auto_ssl:has_certificate(ngx.var.host)
  if has_cert then
    local https_uri = "https://" .. ngx.var.host .. ngx.var.request_uri
    ngx.redirect(https_uri, 301)
  end
}

Note: This would still need updates to the Readme etc, but posting for any immediate feedback.

@gohai: This looks great! Thanks, as always, for your many contributions!
I went ahead and updated the README, and also made a small tweak to expose the shmem_only option in the public API: https://github.com/auto-ssl/lua-resty-auto-ssl/commit/0f7bfd5fa95cb1e85dc7261f0c1180b8cdfa6801 That shmem_only option was defined in the underlying method, but wasn't exposed for external use, but since I could envision some potential use-cases for that (and maybe you had some of those), I thought that seemed simple enough to also expose.
Thanks again!


[Add] DisableNTFSLastAccess

Windows stops updating Last Access attribute of files/dirs everytime they're touched. Positive side effect is saving I/O on HDDs. Windows seems to not doing it on SSDs already from some time.

Merged.
I want to point out 2 things, just for the future reference, as I feel there might be some questions later.
First, it seems that the installations which are upgraded to 1803 from older versions have 3 (System Managed, Last Access Updates Disabled) as the default value regardless of the drive type (checked on 4 physical hosts, 3 SSDs, 1 HDD) whereas the clean installations have the default as 2. This is not a problem as we can assume that the script is applied on a clean installation and if not, there should be no harm in enabling it via the revert tweak. If it still remains system managed, the system should hopefully be smart enough not to hinder performance.
Another thing is, that the values in 1803 are not properly documented and the fsutil messages contradict each other. (Or I'm terrible in understanding double negatives)
C:\Windows\system32>fsutil behavior query disablelastaccess
DisableLastAccess = 2  (System Managed, Disabled)

C:\Windows\system32>fsutil behavior set disablelastaccess
Usage: fsutil behavior set disableLastAccess <0-3>

 Values: 0x0 - User Managed, Last Access Updates Enabled
         0x1 - User Managed, Last Access Updates Disabled
         0x2 - System Managed, Last Access Updates Enabled
         0x3 - System Managed, Last Access Updates Disabled

DisableLastAccess = 2  (System Managed, Disabled)

0x2 - System Managed, Last Access Updates Enabled

So whatever the set disablelastaccess says seems to be correct.

DisableLastAccess = 2 (System Managed, Disabled)
switch that enables disabling updates is disabled, therefore updates are enabled :D


OpenXR: Add support for Wayland on Linux

Adds support for initializing OpenXR with Wayland on Linux.
Some notes about the OpenXR side of this:

Monado is an OpenXR runtime that works on Linux
If you run it like QWERTY_ENABLE=1 OXR_DEBUG_GUI=1 monado-service it works as an OpenXR "simulator", where it'll show what the headset sees in a window and allow you to use keyboard and mouse to control the virtual headset
In the standard XR_KHR_opengl_enable extension, there is a XrGraphicsBindingOpenGLWaylandKHR struct, that supposedly allows initializing OpenXR on Wayland, however, as far as I know, it's not supported on any OpenXR runtime, and according to the Monado folks, it's insufficient to support Wayland (ie it doesn't take in enough information to make it possible to work)
So, the Monado people created the XR_MNDX_egl_enable extension, which allows initializing OpenXR when using EGL, including on Wayland, which is currently supported on the Monado runtime, and the Pico 4 Ultra runtime. As far as I know, at the moment, this is the only way to support Wayland with OpenXR at all
This PR adds support for the XR_MNDX_egl_enable extension, but only for Wayland on Linux. Even though we'd theoretically be able to use it with X11 when EGL is used, or on Android, the other extensions we use for supporting those platforms work on more OpenXR runtimes (and even work with Monado too).

TODO:

Actually test it! My local machine currently uses the proprietary nvidia drivers with X11 - I'll need to get Wayland going :-)
Support compiling with x11=no

Assuming I get the 2nd point going, this will supersede PR https://github.com/godotengine/godot/pull/73504
Supersedes https://github.com/godotengine/godot/pull/73504
Bugsquad edit: fixes #70199

This is working for me locally now!
I tested with the "Pop" desktop on Wayland, together with the Monado runtime.
If anyone wants to test themselves, you'll need to:

Start Monado via QWERTY_ENABLE=1 OXR_DEBUG_GUI=1 monado-service
Update your project (which uses OpenXR, of course) to use the "wayland" display server in Project Settings, and enable verbose output (to get some messages to help you know it's working)
Run it!

You should be able to see output in the console that you ran the game from to indicate that it's using Monado and EGL, for example, this is what I see:
odot Engine v4.4.dev.custom_build.21617c14a (2024-10-04 15:30:51 UTC) - https://godotengine.org
OpenXR: Running on OpenXR runtime:  Monado(XRT) by Collabora et al 'GIT-NOTFOUND'   21.0.0
WARNING: Can't obtain the XDG decoration manager. Libdecor will be used for drawing CSDs, if available.
     at: init (platform/linuxbsd/wayland/wayland_thread.cpp:3731)
OpenGL API 3.3.0 NVIDIA 560.35.03 - Compatibility - Using Device: NVIDIA - NVIDIA GeForce RTX 4070 Ti

OpenXR: Requested OpenGL version does not meet the minimum version this runtime supports.
- desired_version  3.3.0
- minApiVersionSupported  4.5.0
- maxApiVersionSupported  4.6.1023
OpenXR: Trying to initialize with OpenGL anyway...
 INFO [xrt_gfx_provider_create_gl_egl] Extension availability:
 INFO [xrt_gfx_provider_create_gl_egl]   - GL_EXT_memory_object: true
 INFO [xrt_gfx_provider_create_gl_egl]   - GL_EXT_memory_object_fd: true
 INFO [xrt_gfx_provider_create_gl_egl]   - GL_EXT_memory_object_win32: false
 INFO [xrt_gfx_provider_create_gl_egl]   - GL_OES_EGL_image_external: false
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_ANDROID_get_native_client_buffer: false
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_ANDROID_native_fence_sync: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_EXT_image_dma_buf_import_modifiers: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_fence_sync: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_image: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_image_base: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_reusable_sync: true
 INFO [xrt_gfx_provider_create_gl_egl]   - EGL_KHR_wait_sync: true
 INFO [xrt_gfx_provider_create_gl_egl] Using GL memory object swapchain implementation

Thanks!


1777: Make service account mount configurable for vault-agent sidecar

Q
A

Bug fix?
no/

New feature?
yes

API breaks?
no

Deprecations?
no

Related tickets
fixes #1777

License
Apache 2.0

What's in this PR?
This PR make the service account mount configurable for init containers
Why?
Allows you to specify a non-default service account token mount path for authenticating using JWT.
#1777
Checklist

[x ] Code meets the Developer Guide
[ ] User guide and development docs updated (if needed) TODO

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Support for generic type variables in loc, iloc, getitem, ...

I was surprised to discover that generic type variables for Frames and Series do not extend to the loc, iloc, __getitem__, etc interfaces. Is this on the roadmap?

I'm sorry, but I have absolutely no idea what you're talking about. Could you please state your problem in the context of this project?

Apologies, somehow posted this to the wrong project.


ENH: return Jacobian/Hessian from BasinHopping

Returns the Jacobian and/or Hessian in the optimize.Basinhopping module, if it exists. Closes https://github.com/scipy/scipy/issues/5259.
I've only written a unit test for the Jacobian part as I could not find any minimizers that returned a Hessian in the OptimizeResult object. Maybe I've overlooked something?
This is my first scipy contribution so I'd appreciate any feedback. Don't hold back if I've done something horribly wrong or if there's any suggestion of how I could do things better. :)

I wonder if retrieval of underlying Jacobian and Hessian information couldn't be done only once the overall minimization is finished, that is, at the end of basinghopping function. It seems that the current flow of information does not readily allow this. Maybe this could be improved.
cc @js850 for further advice.
@samvrlewis don't worry, it's not horribly wrong ;)

I think you have the right idea, but this will return the jac and Hess of the last minimization that was performed, which is not necessarily the lowest minimum.  To do that you'll have to save jac and Hess along with x and fun in the storage class

Thanks for the feedback @dlax and @js850.
Storing the Jacobian and Hessian only at the minimum makes sense and I'll update my PR soon to implement it like this.
As a rough sketch, the changes I'm thinking that I'd have to make are along these lines. Does this make sense to you?

Update the Storage class to be able to store Jacobians/Hessians by updating the update function to allow passing in a Jacobian/Hessian
Add the Jacobian and Hessian as part of what's returned by the _monte_carlo_step function.
Store the Jacobian and Hessian (if they exist) with the x value and energy (x and f) in storage if a new minimum is found in the one_cycle function.
Modify the basinhopping function to add the Jacobian and Hessian to the OptimizeResult return object if they exist within storage.

How's that for a first attempt? I've attempted to implement what I posted earlier. This was a much larger change so, again, would appreciate any feedback.
I'm not sure how eloquent it is to be modifying the Storage to store the Jac/Hess as these won't always be there, depending on the minimizer used. Would there be a better way of doing this?
I'll modify the unit tests properly and add some more to test the new functionality once I've gotten a thumbs up with the basinhopping code. :)

Maybe Storage could handle the OptimizeResult directly

Yes, I think this is the easiest way.  Then, at the end of the basinhopping run you can grab whatever information you want from the result object.

Ah, that would indeed make sense! Will update it to put the OptimizeResult object into storage directly.
One quick question first: When I'm putting the OptimizeResult into storage, or retrieving it from storage, should I be copying it (or more specifically, all its member variables that are array-like) in/out? I've noticed that x is copied into storage with np.copy and then copied out again for the returned OptimizeResult object.

It's probably OK to simply store a reference to the results object.  I tend to do a lot of explicit copying of numpy arrays because it's really easy and I've been burned too many times by copy by reference.  The only attribute of the result object that is likely to matter in this respect is x, so you could either store a copy of that separately or convince yourself that it's not going to change.
It might be a good idea to return the minimizer results object as a field in the basinhopping results object.

I realised that if I was heading down the path of storing the OptimizeResult object in storage, then there's probably no reason to be storing the x and energy separately there so I've reworked the module to use the OptimizeResult object in storage directly.
I didn't copy the x vector in/out of storage apart from when it's returned from the basinhopping result object. I don't think it is modified within the object so I think it should work ok like this.
As always, would love any feedback about anything else I should do or anything I should do differently. I also tried to rebase my scipy fork and I may have ruined this PR in the process of doing so? Will have a play around and try to figure that out if the CI tests don't pass -- they do pass locally.

Sam Lewis wrote:

I also tried to rebase my scipy fork and I may have ruined this PR in
the process of doing so?

It indeed looks quite messy. The root problem is maybe that you used the
master branch of your fork instead of creating a dedicated topic branch.
Now I'm not sure it's possible to change the branch of a PR. Anyways,
you can try to cleanup your master branch by resetting it to scipy's one
and then reapplying (cherry-pick) your changes on top of this clean
point. (You can backup your current master branch by creating a
'master-backup' branch pointing to your current master branch).

Phew, I think that's all fixed now! I realise now I should've branched from my fork rather than using the master, good to know for next time to avoid the mess. :)
Would love some feedback on the changes too @js850 @dlax, when you have some time of course!

Oh man, I just noticed how many references to "energy" there are scattered throughout the source code.  I originally wrote this in with energy minimization in mind.  Someone should probably replace all those with f or fun or something.  But that should be a separate PR.

I think it's looking pretty good at this point.  Probably the documentation should mention the new attributes for the result object and what they mean.

Rather than the above few lines we could think about doing
res.lowest_optimization_result = lowest_minres
Then people can access jac and hess via the optimization result.

I'm happy to implement it like this but wouldn't this be a little confusing as the OptimizeResult object returned from BasinHopping would contain another OptimizeResult? So you'd have both res.x and res.lowest_optimization_result.x which should always be the same? And the same for res.fun?
Doesn't the res object returned from basinhopping already represent the OptimizationResult at the minimum? Maybe another way would be to copy out all the attributes that aren't already set in res from lowest_minres into res? What do you think?

I agree, it would be confusing.  But on the other hand you could imagine someone writing another PR in a few months to copy over another attribute of the OptimizeResult.  And many attributes exist for one optimizer and not the others.  Or someone might use a custom optimizer returning a OptimizeResult object with custom attributes
It's a balancing act between simplicity and flexibility.  Maybe @dlax has some thoughts.

But on the other hand you could imagine someone writing another PR in a few months to copy over another attribute of the OptimizeResult. And many attributes exist for one optimizer and not the others. Or someone might use a custom optimizer returning a OptimizeResult object with custom attributes

Ah true, what about something like this? I guess the only problem with this is that you lose some of the attributes of the OptimizeResult for the minimum that are set separately. (Like nfev or njev).
res = bh.res
res.message = message
res.nit = i + 1

lowest_minres = bh.storage.get_lowest()

# Copy across the attributes into our return object,
# making sure not to overwrite attributes set in the BasinHopping routine
for attribute in lowest_minres:
    if attribute not in res:
        res[attribute] = lowest_minres[attribute]

I don't actually like copying the attributes like that.  I think it would be confusing to the the user.  E.g. does nfev refer to the whole basinhopping run or just to the last minimization?  If we copy attributes over it should be done explicitly, and only for attributes which would be unambiguous (like jac and hess)

Ok, I see your point, that makes sense. :)
I guess it's tricky as you want to present the results for both the overall basinhopping run and the results for the best minimization. Attaching the best minimization result to the basinhopping result seems like the most eloquent solution. I guess if this is done it just needs to be explained in the documentation.
I'll have a go at implementing this tomorrow if there's no other feedback about this in the meantime. Thanks again for being so patient with me!

Agreed, linking the lowest optimization result to the overall basinhopping is probably the best solution.

How's that?
I hope the documentation I wrote is clear enough! Would it perhaps be better to write a bit more detail about what can be accessed through res.lowest_optimization_result?

Thanks @samvrlewis.


[SourceKit] Abort the SourceKitService proces on a SIGTERM

Sending a SIGTERM to sourcekitd XPC service lead to very surprising results: XPC thought that the process was about to die and sends a Connection Interrupted notification to the client. But other than that, we didn’t actually handle the signal and the service stayed alive. This caused us to send a sema_disabled notification to the client but since the service never got relaunched, we never sent the corresponding sema_enabled notification.
To fix this, just properly die on SIGTERM by calling abort.

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test


[enhancement]: eufy Smart Lock C33 support

Describe the solution you'd like
eufy Smart Lock C33 shows as unsupported in Home app.

Did you check this Road Map pages ?

The bot posted a broken link. There is no roadmap that I can find.
Is anybody actively working on this?

Seconding this request. Other same-generation smart locks are supported, like the C220, so adding the C33 should hopefully be rather simple. It would be very much appreciated.

https://github.com/bropat/eufy-security-client/pull/528


Change email flow with verification turned off

The user registration flow for my application is as follows:

User registers (UserManager.CreateAsync())
Upon completing the registration for, the user is presented with a message saying that their account needs to be approved before they can log in.
An admin will approve their account (currently setting a custom 'approved' attribute to 1) which will change the status of the user to CONFIRMED. Currently I'm just doing this in the Cognito console.
User can then log in
User can go to a 'manage account' page and change their email if they want (email changed with call to UserManager.SetEmailAsync()).

I have disabled verification in Cognito for my user pool:

I have done this because I don't want the emails to be sent immediately after the user registers, I do actually want them to verify their email but not until the admin approval has taken place. I can't see a way to manually send the email with the .NET Identity API (can you confirm?) so I intend to build my own email system for this at a later time.
The problem I'm having is if the user decides to change their email, and then logs out and tries to log back in with their new email, I get a UserNotConfirmedException. I've checked the status of the user in Cognito and it's still CONFIRMED so I'm not really sure what the correct process is here.
I've also tried adding an extra call to AdminConfirmSignUpAsync() after the user changes their email but I just get an exception saying the user is already CONFIRMED which I guess is expected. However, the user is now in a state where it IS confirmed but can't log in and verification is disabled.
I understand this may not be within the scope of this project and may be an underlying issue but I figured I'd get your input first!

I'll try to repro this. It may be that the user is confirmed but not the email. These are two different things for Cognito

Yeah, I understand they are different things but I would have thought if verification is disabled then it shouldn't matter that the email is not verified? Also, it allowed me to log in before changing the email and at no point has email_verified been 'true'.

Hi @andyfurniss4,
Good afternoon.
I was going through the issue backlog and came across this issue. There was a similar issue reported in https://github.com/aws-amplify/amplify-js repository and someone from Cognito team provided a workaround or reasons this is an issue. Please refer https://github.com/aws-amplify/amplify-js/issues/987#issuecomment-531025897. This issue appears to be as a result of Cognito design. Hope this helps. If it provides necessary guidance, kindly confirm if we could close this issue.
Thanks,
Ashish


Backport 13047 to 1.7.x

test failures appear to be infrastructure failures due to this not being master

mac failures failed with: Homebrew must be run under Ruby 2.3! You're running 2.0.0. (RuntimeError)
interop cloud to cloud/prod failed with a kokoro configuration exception


(fix) Switch ergorun to new engine, remove old engine at last

Coverage increased (+0.03%) to 96.947% when pulling 09d3c2e5e1cc94c8a40551112f5d233e3b35986f on jeromesimeon:js-engine-refactor into 8318a13681cc83d69a93d552757290d19f32e59e on accordproject:js-engine-refactor.


Add info to sections ML-RSEs and other important tasks

@mhagdorn , @jcohen02 would you mind working a bit on the refs?

Great to see this PR, I had the same inkling about metadata missing, and will try to do some edits around this in the next days.
I'll work against the PR branch unless someone tells me not to?

Great to see this PR, I had the same inkling about metadata missing, and will try to do some edits around this in the next days. I'll work against the PR branch unless someone tells me not to?

excellent, thanks. go ahead we can figure out any conflicts should they arise

excellent, thanks. go ahead we can figure out any conflicts should they arise

☝ #221.


(IE 10) Object doesn't support property or method 'use'

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Swiper Version: 4.0.7

Platform/Target and Browser Versions: Internet explorer 10

Not working in ie 10

@Warptimer we were facing the exact same issue in IE10. The source of the problem is proto on the function which is not available in IE 10.

We were able to resolve this by adding proto polyfill for IE10
Proto polyfill
Hope it helps!

@Mudassir-23 thank you so much. You are rock!


Fix generated aas artifacts

fix problem mentioned here: https://github.com/eclipse-tractusx/sldt-semantic-models/issues/100

@arnoweiss I have fixed the problem with the json/xml file you mentioned here: https://github.com/eclipse-tractusx/sldt-semantic-models/issues/100
can you have a look, if it is ok from your side?

looks great!


Reset the SendMessage pointer before post-interception hooks

Sending a message steals the references from the send byte-buffer, so clear this pointer before reaching the post-interceptor calls. If the post-interceptors need this value, they should do a byte buffer copy during the pre-interception hooks (and byte buffer copy is inexpensive cf #17510)
Cc: @tsalomie

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.1%     +43 src/cpp/client/generic_stub.cc                                                           +43  +0.1%
       +57%    +423 grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal:    +423   +57%
      +0.7%      +8 grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal:      +8  +0.7%
  +0.0%     +16 src/cpp/server/health/default_health_check_service.cc                                    +16  +0.0%
      +2.1%     +16 grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal:     +16  +2.1%
  +0.1%     +16 src/cpp/server/server_context.cc                                                         +16  +0.1%
      +2.3%     +16 grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal:     +16  +2.3%

 -+-+-+-+-+-+-+ MIXED                                                                                +-+-+-+-+-+-+-
  -0.0%     -19 [None]                                                                               +3.53Ki  +0.0%

  +0.0%     +56 TOTAL                                                                                +3.60Ki  +0.0%

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,026,842      Total (=)      2,026,842

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,324,726      Total (>)     11,324,723

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences


Suppress Xcode workspace change warning

It would be good to find a way to suppress the warning that appears in Xcode when generating the project while it's open. There should be a way to do this via the way the file is written, or by not writing the workspace if it hasn't changed

I have a PR up that might solve this problem. Would you mind having a look?


Fix for version is incorrectly handled issue.

This CR fixes issues with incorrectly handled version 0.
The issue was about type checking and 0 was ignoring.
The fix changes checking from if (!version) to if (version === undefined)
and this fix alows to use version 0 for the requests.
CR also adds support for setting version into the request classes.
If the user sets the version to the request, then the locked version of the instance is ignoring.
If the user does not set the version to the constructor or to the request instance, the latest version
will be fetched, used and locked to the instance of the client.
Adding integration tests to handle all checking:

Should use version 0 for getPartitions with
PartitionsRequest.withVersion(0).withPartitionIds(['23605706']);.
Should use version 0 for getPartitions with
QuadKeyPartitionsRequest.withVersion(0).withQuadKey(quadKeyFromMortonCode(23605706));
Should use version 0 for getData with
DataRequest.withVersion(0).withQuadKey(quadKeyFromMortonCode(23605706));
Should use version 0 for getData with
DataRequest.withVersion(0).withPartitionId('23605706');
Should use locked version 142 for getPartitions with
PartitionsRequest.withPartitionIds(['23605706']);
Should use locked version 142 for getPartitions with
QuadKeyPartitionsRequest.withQuadKey(quadKeyFromMortonCode(23605706));
Should use locked version 142 for getData with
DataRequest.withQuadKey(quadKeyFromMortonCode(23605706));
Should use locked version 142 for getData with
DataRequest.withPartitionId('23605706');
Should use latest version for getPartitions with
PartitionsRequest.withPartitionIds(['23605706']) and lock it;
Should use latest version for getPartitions with
QuadKeyPartitionsRequest.withQuadKey(quadKeyFromMortonCode(23605706)) and lock it;
Should use latest version for getData with
DataRequest.withQuadKey(quadKeyFromMortonCode(23605706)) and lock it;
Should use latest version for getData with
DataRequest.withPartitionId('23605706') and lock it;
Should use version 0 for getLayerVersions with
LayerVersionsRequest.withVersion(0);
Should use version 0 for getVersions with
CatalogVersionRequest.withEndVersion(0);

Resolves: OLPSUP-9571
Signed-off-by: Oleksii Zubko<EMAIL_ADDRESS>

Codecov Report

Merging #225 into master will decrease coverage by 0.3%.
The diff coverage is 84.8%.

@@           Coverage Diff            @@
##           master    #225     +/-   ##
========================================
- Coverage    91.3%   91.0%   -0.3%
========================================
  Files          57      57
  Lines        1550    1568     +18
  Branches      185     187      +2
========================================
+ Hits         1415    1427     +12
- Misses         73      77      +4
- Partials       62      64      +2

Impacted Files
Coverage Δ

...p-sdk-dataservice-read/lib/client/CatalogClient.ts
78.3% <71.4%> (-0.3%)
:arrow_down:

...olp-sdk-dataservice-read/lib/client/QueryClient.ts
87.2% <75.0%> (-4.7%)
:arrow_down:

...ataservice-read/lib/client/VersionedLayerClient.ts
93.2% <88.6%> (-2.9%)
:arrow_down:

Continue to review full report at Codecov.

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


flutter create package does not create example

flutter create -t package . does not create an example; plugin template does.
Use case
I would like to create a dart library for Flutter with an example using flutter create. Flutter seem to do this for the plugin template but not for the package template - is there a spesific reason for this?
Proposal
Also create an example for package templates ( if it makes sense ).

This is possible now AFAIK


refactor(repodb): moving common utilities under pkg/meta

What type of PR is this?

Which issue does this PR fix:
#1284
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:

Automation added to e2e:

Will this break upgrades or downgrades?
Does this PR introduce any user-facing change?:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Get rid of *-wrapper dirs

https://github.com/project-zot/zot/pull/1285
^ use this reference

Get rid of *-wrapper dirs

Can we fix this in a future PR? I'd do this in smaller steps, and merge more often.
See my comment on the same issue https://github.com/project-zot/zot/pull/1285#issuecomment-1476839217

This is a intermediate step in our refactoring work.


Infinite loop in Get-MTUser -UserType "EmergencyAccess"

Hello,
We are using Maester 0.3.0.
In our tenant any Get-MtUser -UserType "EmergencyAccess" call causes an infinite loop.
The Get-MtUser -UserType "EmergencyAccess" function call automatically tries to select 2 groups from Entra ID as BreakGlass groups based on exclusion criteria in conditional access policies. Trying to get the members of the automatically selected groups in our case causes the infinite loop. The groups in our case are on-premise synced and are not break glass account groups and should not be used as such.
Code snippet causing the problem
...
   Write-Verbose "Emergency access group: $EmergencyAccessGroups"
                foreach ( $EmergencyAccessGroup in $EmergencyAccessGroups ) {
                    $TmpUsers = Invoke-MtGraphRequest -RelativeUri "groups/$EmergencyAccessGroup/members" -Select id, userPrincipalName, userType -OutputType Hashtable
                    if ( $TmpUsers.ContainsKey('userType') ) {
...

Output:
VERBOSE: Using graph cache: https://graph.microsoft.com/v1.0/groups/<REDACTED>/members?$select=id%2cuserPrincipalName%2cuserType&$skiptoken=<REDACTED>
VERBOSE: Using graph cache: https://graph.microsoft.com/v1.0/groups/<REDACTED>/members?$select=id%2cuserPrincipalName%2cuserType&$skiptoken=<REDACTED>
VERBOSE: Using graph cache: https://graph.microsoft.com/v1.0/groups/<REDACTED>/members?$select=id%2cuserPrincipalName%2cuserType&$skiptoken=<REDACTED>
VERBOSE: Using graph cache: https://graph.microsoft.com/v1.0/groups/<REDACTED>/members?$select=id%2cuserPrincipalName%2cuserType&$skiptoken=<REDACTED>
VERBOSE: Using graph cache: https://graph.microsoft.com/v1.0/groups/<REDACTED>/members?$select=id%2cuserPrincipalName%2cuserType&$skiptoken=<REDACTED>
VERBOSE: Using graph cache: https://graph.microsoft.com/v1.0/groups/<REDACTED>/members?$select=id%2cuserPrincipalName%2cuserType&$skiptoken=<REDACTED>
VERBOSE: Using graph cache: https://graph.microsoft.com/v1.0/groups/<REDACTED>/members?$select=id%2cuserPrincipalName%2cuserType&$skiptoken=<REDACTED>

Response body of the /members calls
{
  "error": {
    "code": "InvalidAuthenticationToken",
    "message": "Access token is empty.",
    "innerError": {
      "date": "2024-10-18T17:39:00",
      "request-id": "<REDACTED>",
      "client-request-id": "<REDACTED>"
    }
  }
}

Solutions:

Failing get-MTUser should fail the test
Allow setting BreakGlass account group ids as parameters in the affected tests:

MT.1029-MT.1032
BeginDiscovery section in Maester/Entra/Test-ConditionalAccessWhatIf.Tests.ps1

Please ignore the Response body part, it is not relevant.


[fluidlite] update version; add SF3 feature; shared library support

[x] Changes comply with the maintainer guide
[x] SHA512s are updated for each updated download
[x] The "supports" clause reflects platforms that may be fixed by this new version
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

From what I can see, fluidlite doesn't conflict with fluidsynth anymore, so I fixed CI baseline. Please check on your side.


mesa: 17.1.10 -> 17.2.2

Motivation for this change
The 17.1.10 version in master hangs my graphics card (works fine on the release-17.09 branch though).
I have enabled the enableRadv option by default, since it seems to work just fine with my RX480.  At least the smoketest demo runs at 1kFPS:
$(nix-build -A vulkan-loader.demos)/bin/smoketest

I'll merge this on Monday if there are no objections.
cc @vcunat @eduarrrd
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Yes, this was in my plans.  Since it's larger update, it would be nice to also test with some other GPU.  I can test nouveau tomorrow (probably).

@gebner: what driver do you use?

@vcunat I've tested it on a Radeon RX480 using the amdgpu driver.

It's not directly related, but can you also test this amdgpu bump? https://github.com/vcunat/nixpkgs/commit/550a292f3c9  (apply wherever you want)  I don't even have any compatible hardware.

The xf86-video-amdgpu bump to 1.4.0 works fine here.


Add missing EBV Aevo tokens

Resolves L2B-3798

@lucadonnoh is the only person who should merge it, even though it's approved by me!


Add learner program records

As a learner on MITx Online, I'd like to be able to access a record of my progress through a program I'm enrolled in, similar to how I can do this in MicroMasters.
This will be cross-porting the Program Record functionality from MicroMasters to MITx Online, including these features:

Overview of the learner's progress through the courses in the program
Sharing a copy of the record directly to a partner institution
Generating a revokable link to view the record that can be shared by the learner

The first attempt at this will lean heavily on the MicroMasters look and feel (for the record-specific parts); it is expected that the design team will have a MITx Online-specific design in the future.
Designs and Mockups
See the Program Record in MicroMasters:

Acceptance Criteria:

[ ] The program record is accessible through the dashboard
[ ] The program record displays the program name and a tag indicating the overall progress the learner has made (Partially Completed or Completed)
[ ] It displays the learner's name, username and email
[ ] It displays each course in the program, with a tag for its status (core/required or elective) in the program, along with the course ID, grade earned, verified attempts, certificate date earned, and certificate status for the learner
[ ] It allows record sharing as a whole to be toggled on or off
[ ] Once record sharing is allowed, it allows records to be sent to a partner institution (which then cannot be revoked)
[ ] Once record sharing is allowed, it allows a shareable link to be generated to allow an unauthenticated users to view the learner's record. This link should not be available before the learner activates it and should be deactivated if the learner revokes record sharing.

Out of Scope

Not sure just yet

Does this include a feature flag, for controlling the appearance of the link on the dashboard?

Yes, will update the reqs


Fix for the errors in exile.js

I'm not an experienced developer but it seems like this function is currently broken.
I changed something so the string becomes JSON, and now it seems to work.
Before it was just telling me "Cannot read property length of undefined".

why did you close this

Thought for a second that the fix wasn't working because it was erroring even when I put the correct group and user. But it appears that I put the wrong group ID, oof.


feat: Generic Relayer

I confirmed an e2e test using https://github.com/zkemail/email-tx-builder-template/tree/feat/new-relayer-api worked.


LambCI cant create optimised production build

I am using lambCI with create-react-app it always errors on npm run build with error code 1, any ideas on what may be causing this? I suspect root access but cannot be sure, npm install and npm test work great.

No idea I'm afraid – I'm going to need more detail. What's happening when the error occurs? What are the details of the error? Is it trying to write somewhere on the filesystem that it doesn't have permissions?

@mhart
Sorry it is just a generic error message, here is my test repo.
https://github.com/lolcookie/lambci-CRA

@mhart
https://github.com/lolcookie/lambci-CRA/pull/3
Here is the example, although it appears to be working for now so I will close this issue.
Thanks for the quick reply!

Glad you got it working!
The default command is npm install && npm test. If you want npm install && npm run build, then this should work in your package.json:
"lambci": {
  "cmd": "npm install && npm run build"
}

@mhart
Actually you are right but there is a weird error when using that command.
example: https://github.com/lolcookie/lambci-CRA/pull/7
Also for anyone checking this for future reference it was failing on eslint warnings.
example: https://github.com/lolcookie/lambci-CRA/pull/6

Interesting – it looks like it might be running out of disk space perhaps? Lambda only allows 500MB at the moment (can't wait for Amazon to increase this!)

@mhart
I think so too however using nave is successful as you can see so it makes me wonder about permissions or npm version.

@lolcookie right, it may be that npm v2 isn't de-duping as well as npm v3, so is using more space
I'm actually considering upgrading the npm included in LambCI to npm v4 – and possibly even including yarn as well. Just need to be careful not to increase the size too much, and I don't want to break anyone's builds.


Feature request: nvim-spectre support

Would be awesome to support https://github.com/windwp/nvim-spectre - I haven't found a way to get it working properly with the setup so far, any guidance would be appreciated!

I've noticed this is similar to #42
You can try this. Let me know how it works for you. It seems to solve the issue on my end for now. Make sure to update focus first 👍
vim.cmd([[
function! SpectreFocus()
    lua vim.bo.buftype = 'help'
    lua require('spectre').open()
endfunction
nnoremap <leader>S :call SpectreFocus()<cr>
]])

I pushed a fix that sets it to 70 width when entering insert mode. I have come across some troubles reading the filetype when spectre is opened. It seems that on BufEnter event, it gets the old filetype

Hmm that first fix kind of works with one window, but not in a vertical split:

Setting it to 90 only works when is_insert_mode = false is set, and the initial incorrect size is still a bit jarring. Would it also be possible to change the value for smaller screens? Thanks!

I have found the problem is that spectre does not have a filetype set initially when it is first opened. I will see if I can open PR with spectre

Hmm that first fix kind of works with one window, but not in a vertical split:

Setting it to 90 only works when is_insert_mode = false is set, and the initial incorrect size is still a bit jarring. Would it also be possible to change the value for smaller screens? Thanks!

I've just pushed what I would do. It simply returns when filtetype=spectre_panel
The only problem is that spectre runs 'vnew' to create a new buffer, and so it initially has a '' (blank) filetype set.
So only when first opening it will resize, after that it will have the 'spectre_panel' ft set and won't resize anymore.

I have found a way to deal with this edge case using defer_fn to wait for some time before checking filetype and running resize() in case its not set when buffer created (vim limitation)
What behaviour would you like? I found if we just exclude spectre from being resized, when having many splits it can get crushed. So I added a call to :FocusSplitEqualise

If you just enter a buffer, then the filetype isn't detected! If you want filetype detection you need to wait for the filetype event! See help :eventand search for FileType! Just waiting isn't really a solution as you don't know how long you should wait. It depends on the load of the machine and hardware.
So you might want a function which runs on the filetype event and resizes probably.

I did try using a filetype event earlier and it did not seem to work unfortunately. I will give it another crack. I agree this is not an optimal way to handle the problem. I think ideally there would be a way to initialise a buffer with options set when it is created

I swear I tried this many times earlier but it works now.. 😅

This works much better! The only problem is if you then navigate to another split and back again, you eventually end up with the same issue. This works well enough for my use case for now though - thanks!

Yeah that's a bit of a problem. There is one thing I have thought of adding. It could be useful for later is a function to check all buffers in the tab for a filetype etc. i.e if there is a 'spectre_panel' filtype in this tab, always keep the splits equalised.
That would solve the issue for when you move to other splits

Closing as this issue is resolved on my end.


Migrate -jre flavor of Guava to -android flavor

See https://github.com/google/guava/wiki/ReleasePolicy#flavors

This change is

Could you explain why we should replace all instances of stream.collect(toImmutableList()) with ImmutableList.copyOf(stream.iterator())? The Java practice documentation (go/java-practices/streams#iterator) strongly discourages the use of Stream.iterator().

It is bc the -android flavor of Guava lacks a public ImmutableList.toImmutableList symbol.  Guava's release policy guides that users should target the -android flavor to be compatible with either (see https://github.com/google/guava/wiki/ReleasePolicy#flavors).
I'll check another way to replace Stream.iterator(). Thank you for the information.

Would you consider upgrade the Guava lib to 33.2.0-android? https://github.com/google/guava/releases/tag/v33.2.0 Fortunately, this version made ImmutableList.toImmutableList() available in guava-android.

That is great catch! Upgraded to 33.2.0 and verified internally that ImmutableList.toImmutableList() works.
Thank you!


Security vulnerabilities in Puppeteer-Sharp

Description
Puppeteer sharp uses various transitive packages causing security alerts

Complete minimal example reproducing the issue
Run the command: dotnet list package --vulnerable --include-transitive
Expected behavior:
Most likely, transitive packages need to be updated, or alternatives need to be used to reduce security concern
Actual behavior:
Outdated transitive packages are used that contain security issues
The errors can be found using
dotnet list package --vulnerable --include-transitive
Which exact package contains the vulnerability is trial and error unfortunately
From my own experience so far:
xunit 2.4.2 -> xunit 2.4.0 (https://devscope.io/code/xunit/xunit/issues/2568)
Microsoft.PowerShell.SDK
Microsoft.VisualStudio.Web.CodeGeneration.Design
Microsoft.AspNetCore.Authentication
Serilog.Sinks.MSSqlServer (https://github.com/serilog-mssql/serilog-sinks-mssqlserver/issues/417)
AutoFixture
AutoFixture.AutoMoq
AutoFixture.Xunit2
https://github.com/AutoFixture/AutoFixture/issues/1356
System.ServiceModel.Http
System.ServiceModel.Security
System.ServiceModel.Duplex
System.ServiceModel.NetTcp
Microsoft.AspNetCore.WebUtilities
Castle.Core.AsyncInterceptor
https://github.com/JSkimming/Castle.Core.AsyncInterceptor/issues/166
Versions
Version 7.1
.NET 6
Thanks in advance!

Makes sense. Do you want to create a PR for that?


Template Story Update - Exploration

Explore how to have templates repo as fork for users:

Explore a "main"-less version of the repo
"Main" is generated by using a branch or release tag to be detokenized and updated to reflect customer installation.
Explore challenges of this approach.

The idea is to preserve child repos as forks of our templates repos, to allow follow ancestry to keep forks eventually possible to update.

We still need to explore it, the tagging process is a half implementation of this, but it is not a full version of it.


settings: NVS: add entry into cache after writing

Settings NVS adds entry into Settings NVS cache after writing it into flash. Previously, the entry was added into cache only on the second writing attempt that caused very huge timing despite cache was enabled since it was still empty.
Scenario: store ble mesh replay protection list with 255 entries by button pressing(in real life by timer):

Right picture with this improvement. The second attempt is encircled in red.
Branch with testing app: https://github.com/alxelax/zephyr/tree/settings_with_large_rpl
Referenced sample: bluetooth/mesh. Referenced device: nrf52840dk_nrf52840
You can see the second attempt takes to write RPL about 30 seconds because cache is empty.
If build cache during the first writing attempt, then it takes about 1.7 seconds (improvement).

Seems reviewer assigning script doesn't work properly for Settings. I added all participants who reviewed initial settings cache PR + @LingaoM. Sorry, if somebody was added by mistake.

Hi @alxelax, thanks for the PR.
This is a strange change, from the first look it seems to be adding to the hash table before the write has been performed.
I don't see (in code) why it would only be added on the second write attempt: as soon as a name and name_id is written it is added. What I do see is that on every load the hash table is rebuild, might this be the cause of the slower second attempt  ?

Hi @alxelax, thanks for the PR.
This is a strange change, from the first look it seems to be adding to the hash table before the write has been performed.

@Laczen,
Hm. Whether the writing has been performed here?: https://github.com/alxelax/zephyr/blob/setting_nvs_cache_improve/subsys/settings/src/settings_nvs.c#L319
I guess writing happens synchronously and after leaving the writing function data is in flash. In time adding entry into cache, data was already stored in flash.

I don't see (in code) why it would only be added on the second write attempt: as soon as a name and name_id is written it is added. What I do see is that on every load the hash table is rebuild, might this be the cause of the slower second attempt ?

It would be added on the second write attempt because on the first attempt settings_nvs tries to find string that does not exist yet here: https://github.com/alxelax/zephyr/blob/setting_nvs_cache_improve/subsys/settings/src/settings_nvs.c#L231-L251
Since the string does not exist yet, the loop cannot overcome this condition: https://github.com/alxelax/zephyr/blob/setting_nvs_cache_improve/subsys/settings/src/settings_nvs.c#L249-L251
but adding to cache happens right behind this condition here: https://github.com/alxelax/zephyr/blob/setting_nvs_cache_improve/subsys/settings/src/settings_nvs.c#L255
Cache is left empty on the first writing attempt, since writing loop is left here: https://github.com/alxelax/zephyr/blob/setting_nvs_cache_improve/subsys/settings/src/settings_nvs.c#L234 for every new entry. That means on the second attempt, setting_nvs has to go over all stored entries in NVS application table to find the string and to build the cache table. This is the reason the second attempt takes so bad performance time.

@alxelax I see, indeed only the second time a save is done it will be added to the cache.
I wonder if we shouldn't just move lines 254-256 to line 324 and always update the cache table.

@Laczen,

I wonder if we shouldn't just move lines 254-256 to line 324 and always update the cache table.

yep, sounds reasonable but moving this at the end of the function. Somewhere here: https://github.com/alxelax/zephyr/blob/setting_nvs_cache_improve/subsys/settings/src/settings_nvs.c#L327
I'll update PR


After changing priority with 1/2/3/4 key, the affected task stays "in focus" => not possible to process a list

After changing priority with 1/2/3/4 key, the affected task stays "in focus".
When I use the arrow keys afterwards, the task up/down to the new position of the affected task is selected.
This is an issue, as it makes it very hard to process a list of tasks, as I always need to keep pressing the arrow keys many many times to get back to the place in the list, which I was previously at when sorting through the list.

Thanks so much for the speedy reply, Michael! 😊
Just want to add that I love your extension - makes the great Todoist even so much better!! Thanks a million!! 🥰
I'm slightly confused, as I'm almost 100% sure that the cursor behaviour was staying in position in the previous built I've used (1.36, I believe)?!
Any chance that I can switch cursor behaviour by editing a parameter in the "todoist-shortcuts.js" file? 🙏✨

I imagine the behavior change was https://github.com/mgsloan/todoist-shortcuts/commit/b6fd44ba4f6073d3bb7fe7dcee70ac80ae7f225d .
I've worked some on this but haven't managed to add an option for what you want here.  Todoist-shortcuts uses the task id / indent / section to store the cursor, and so it is rather tricky to have the cursor not move with priority change.
I have however added an option that enables / disables the cursor following across section changes, and implemented some fixes of that.  So, as a workaround for now, with the default setting of not following across section changes you should be able to:

Group by priority
Change task priorities without this moving the cursor with the task

Hi Michael
Wow, I'm just so super grateful for what you're doing here!
Your workaround works perfectly for me... so happy I can use Todoist again with full keyboard control the way I'm used to!! 🤩 Thank you, thank you, thank you!!! 💛

@andreasfmwolf You're welcome!  So glad this approach is working well for you :grinning:


Use debug for log about skipping addition of cert

What does this PR do?
This entry can flood the logs if a cert is duplicated like wildcard certs can be.
Motivation
Using debug for this can lower the amount of logs in INFO mode. (https://github.com/containous/traefik/issues/5622)
More

[ ] Added/updated tests
[ ] Added/updated documentation

Additional Notes

Hi guys 👋
Could we merge this please ? I'd appreciate it.
Thanks.


better algorithm for output selection required

The current algorithm used in all rivine (wallet) implementations does the following:

order all outputs from biggest to smallest
start selecting until the amount is reached
if after all outputs are used it still doesn't work,
continue for all unconfirmed
if after all confirmed still not possible, funding fails

This works, but has several flaws:

(a) it can make the transaction fail by funding a Tx with too many coin inputs
(b) it creates pretty much always a coin output for change
(c) it doesn't spend smaller outputs for wallets that have big enough outputs to consume from,
meaning that smaller coin outputs created because of (b) as change will not be spend, and accumulate instead
(d) there are no fallbacks, if the single try cycle does not work, it doesn't continue

Eventually combining all these flaws, a wallet could get in a position where the algorithm will always fail for big enough amounts to be sent.
Possible Solution
This reminds me a lot about the Knapsack algorithm, could help us perhaps. In general we could perhaps try to do something like the following:

try to find an output that matches the exact amount (rarely going to happen though)
apply the knapsack algorithm (in some modified way perhaps) to try to find a best match
try x amount of times with random outputs, and return the first selection possible.

Probably there are some other chains that had to solve similar problems, but we really need a solution ASAP, because some tfchain users run into the problem caused by this issue on a very regular basis.
By providing a better algorithm we should be able to avoid a growing list of UTXO.
For wallets already affected with a giant UTXO we might need to provide a manual-triggered merge operation perhaps.

Any input @robvanmieghem, @LeeSmet?

Sia implemented automated utxo merging for this since indeed, too many inputs in a tx makes it fail. This was especially true for exchanges. I don't like the Sia  solution though.

Given only one coin output, how many coin inputs can we fit in a regular transaction, using one miner fee?

If you consult the code or documentation you'll be able to conclude that a v1 transaction
with no coin inputs, one coin output, no arbitrary data, no block stake inputs or outputs and one miner fee (minimum),
has a size of 358 bytes when Sia-binary encoded (the encoding used for v1 transactions).
Each added coin input will add 169 bytes to the transaction (it's as linear as this, given the length of coin inputs is a static 8 bytes,
already included in the 358 bytes mentioned earlier).
The block size limit is in tfchain (and all other rivine chains) 2e6 bytes, so there won't be an issue there.
In the transaction pool module however there is another constant adhered by that module,
which limits the max size a single transaction is allowed to have. This is 16e3 in tfchain (and all other rivine chains).
We can therefore conclude that for a merge transaction we can put
⌊(16e3 - 358) / 169⌋ = 92 coin inputs per transaction.
If we have two coin outputs (because we also have a refund coin output) we can instead only have up to:
⌊(16e3 - 409) / 169⌋ = 92 coin inputs per transaction.
This consistency is good, as it means we can as a measurement already add a check in our high level wallets
that checks that there are no more than x coin inputs per transaction, irrelevant if there are one or two coin outputs,
(more coin outputs are no used in regular high level wallet transactions, and less neither.
They will however also have to take into account the byte size of the arbitrary data, if for example 83 bytes are used for
arbitrary data (the maximum) than we can have:
⌊(16e3 - 492) / 169⌋ = 91 coin inputs per transaction. It is however simple enough to check this extra size on the fly.
This means that in worst case the high level wallet application can provide a better error to the user,
and in the best case scenario the wallet application can (semi-)automatically (help) resolve the issue.
On top of that it means that we should be able to quickly provide a merge functionality in the desktop wallet,
to already help resolve people who are currently unable to spend high amounts.
The algorithm for the merging (or cleaning up of smaller outputs) could be as simple as:

sort from low to high
for each 91 coin inputs found, assemble, sign and send a merge transaction
when at the end there are still 32 coin inputs or more left we could do a final merge of this one as well,
ending at one coin output, otherwise < 32 coin outputs will be left.

Easiest might be to provide this as a scripted transaction, given this should really be more of an exceptional thing,
and no longer be required once a decent coin output selection algorithm is used.

https://github.com/threefoldtech/threefold-wallet-electron/releases/tag/v0.6.1 released which:

Adds coin input length check, to make sure we can fit it in a transaction as described above. This provides a better error message.
Allows outputs to be merged using a scripted transaction:

function() {

// script constants
const maxOutputsPerWalletCount = 32

// callback used to merge
let txs = []
const merge_callback = (result) => {
    if (result) {
        if (!result.submitted) {
            // special case in case no transactions were submitted
            if (txs.length == 0) {
                return { output: 'No merge transactions have been submitted!' }
            }

            // get the total merged value
            let mergeTotal = new Currency()
            txs.forEach(tx => {
                tx.coin_outputs.forEach(co => {
                    mergeTotal = mergeTotal.plus(co.value)
                })
            })

            // return the merge info
            let output = `Successfully merged ${mergeTotal.str({unit: true})} in ${txs.length} merge transaction(s). All Transactions: `
            output += txs.map(tx => tx.id).join(', ')
            return { output }
        }

        // add submitted transaction
        txs.push(result.transaction)
    }

    // send next merge transaction
    const builder = wallet.transaction_new()
    return builder.send({ merge: true, mergeMinOutputCount: maxOutputsPerWalletCount+1 }).then(merge_callback)
}

// merge & report
return { output: merge_callback() }

}()

Start of next week I'll look into actually proposing and implementing a better algorithm to select coin outputs, but this should already help those who currently have wallets with too many coin outputs to still be useful for big amounts.

interesting and simple read: https://blog.lopp.net/the-challenges-of-optimizing-unspent-output-selection/

Since most people do not use multiple addresses, let's drop the privacy concern  of minimizing the number of addresses for nowand focus on not bloating the blockchain or blocking the wallet. A simple suggestion:

Order the utxo's from small to large
Try as many utxo's until the required amount is reached.
If the number of utxo's as inputs reaches the maximum before the required amount is attained, drop the smallest one and add the next
Repeat the previous step  until the required amount is reached.

This would limit the amount of utxo's and since transaction size has no impact on transaction fee yet, this algorithm has no downside there.

Very funny @robvanmieghem, I had the exact same approach in mind. As indeed we do not have the concerns that bitcoin wallets do have of having too optimise in terms of transaction fee. Nice to see how alike we think on this one.

I did have a twist in mind on top of this algorithm. I was thinking that in case we have more than the required amount, that it would be better to instead of going just over the limit, it would be better to actually go a lot over the limit. This would also prevent of having to create a very small coin output refund.

true, even though it would get cleaned up in the next spend

That is true as well. I guess the twist can be done in a second phase if desired.

Algorithm has been implemented in the unofficial Desktop Wallet. Release can be found @ https://github.com/threefoldtech/threefold-wallet-electron/releases/tag/v0.6.2.
Code for it can be found @ https://github.com/threefoldtech/threefold-wallet-electron/blob/440662a793d98781eb3bbf415ba8a482abed0288/src/tfchain/balance.py#L423-L497
Header and comment for the fund_individual function:
def _fund_individual(self, amount, addresses, max_input_count=None):
        """
        Funding logic works as follows...

        First collect all available outputs.

        Secondly try to fund using the lowest (up to the highest) confirmed outputs available.
        If we reach the limit and still didn't fund enough, try to replace from smallest to highest with
        the remaining available unconfirmed outputs.

        Lastly if we still couldn't fund, or perhaps we never reached the limit, we'll try to
        fund using unconfirmed, starting from highest to lowest, and overwriting as long as we have higher
        ones available to overwrite lower ones with.

        If this last step failed than funding is simply not possible.
        """

Closing this issue as there is a workaround, and created a follow up issue for the reference implementation: https://github.com/threefoldtech/rivine/issues/629


Water.css 2.0

🎉🎉🎉
This PR proposes merging Water.css 2.0.0 into master!
@kylejrp you said there were some comments you wanted to make, what are they?
Also, this introduces a lot of changes - how can we best summarize them for the changeset?
This closes #187.

Phew, I quickly skimmed through all of the outstanding issues and pull requests to see what we can close or what we could easily include. I'll need to do a deeper clean later but I think we're okay for a 2.0 release.
I think this closes #142, #143, #151, #160, #169, #170, #173, #187, #188
Are HTML files being linted too? (#146)
We could modify the contributing guide to include the following to completely close #147:

Not adding any classes or ids to CSS files
Theme color guidelines:

Reuse existing colors where possible and only for the purpose that their variable describes (eg. don't use text variables for background colorss)
Add new colors to both theme files if necessary
Don't add colors directly to the css files

Would be worth it to include the easy fixes from #153, #176, #180, #185
We can double check accessibility issues here to help with #55, #56 (especially surrounding color contrast):
https://wave.webaim.org/report#https://deploy-preview-194--watercss.netlify.app/

I looked through the list of PRs and issues @kylejrp sent over and merged/closed what I could. The remaining two are #56 about accessibility and #147 about the contribution guide. @jonaskuske you're amazing at writing documentation, would you mind updating that to close #147?
I'll work on accessibility checking and such.

@kognise Why thank you! :D Sure thing, I'll get to it 👍🏻

I believe all we have left is to write a changeset and add the changes from #147!
Thanks guys

@kognise I initially thought that'd be unnecessary, but seeing (and experiencing 😬) that accessibility.js runs on every commit, starting the two theme checks in parallel using Promise.all might be a good idea? Don't know which of the validate scripts takes the longest

I opted to run them in series because it was easier to do logging, I think for now performance isn't really a problem because this isn't being run often.

I just noticed that I messed up with min-height - it should be height instead and min-height should be set to something much smaller.

I just noticed that I messed up with min-height - it should be height instead and min-height should be set to something much smaller.

What does this refer to? 🤨

I accidentally made it so you can't make textareas smaller than the default height. Fixed in 7e4e508fc1e1dcf0b4a0fcb7d44102e518e93671.

Are we using assets/screenshot.jpg anywhere?
We should either remove or update it

Idk why it's still there, removed it in d6db2e7c5911307fbfb8159a601e700134adeda7.

Re: <textarea> – is the min-height necessary at all? It's not doing anything for me
Otherwise this looks good to me now, will go through it one last time tomorrow and then approve :)

Ah, we'll probably need to update the file sizes again (in docs/script.js) before merging this.

is the min-height necessary at all? It's not doing anything for me

It makes it so you can't resize the to textarea smaller than the height, without it the text can clip and such.
Also, I just updated the file sizes.

Boop @kylejrp @jonaskuske - is there anything else we have to do before merging? (Besides writing a changeset)

There's a few unresolved discussions that I've pinged you in the review above, then other than the changeset I think we're good to go.

I've written a WIP changeset in #209

Just plugging here for #182 hoping it (or similar) will make it into the 2.0 release.

I pulled a me again, didn't I?

I'm 99% sure this is all ready to merge!
@kylejrp @jonaskuske sorry for being such a dummy and thanks again for all the help.
Might it be a good idea to publish everything to NPM before merging to make sure it works? Would that break anything with Git tagging?

I think releasing a 2.0.0-rc.1 or something along these lines is a great idea! And I don't think it'd break anything, not 100% sure though.

I believe changesets has a prerelease feature but we would've had to run it before generating the changelog.

I believe changesets has a prerelease feature but we would've had to run it before generating the changelog.

Oh, you're right – we would've had to run yarn changeset pre enter rc (or beta or whatever) before running yarn changeset version over in https://github.com/kognise/water.css/pull/211. That compiled all changesets into our changelog and assigned it a version number – so we probably should have done that as part of this PR and not already in #211 but oh well.

Anyway, there still are some TODOs in our changelog. Need to get them cleaned up so we can release this :)

Out of curiosity, are TODOs a Changesets thing? I'll check them out.

We could of course also undo the last commit here, remove the TODOs and undo the changeset version in https://github.com/kylejrp/water.css/commits/two-changeset, then merge again and publish a pre-release the proper way.

Out of curiosity, are TODOs a Changesets thing? I'll check them out.

Don't think so. Just some open questions and other parts where the changelog isn't fully fleshed-out – it was a [WIP] PR after all 😄

I think it's probably fine as-is. My main concern from the changelog is how existing sites will be impacted.
I did some research and most sites include it like<EMAIL_ADDRESS>As far as I know, this will only work until the latest Git tag doesn't include a dist folder. Changesets publishes to NPM and creates a Git tag which has the chance to screw up literally every website using Water.css.
One option is just to publish on NPM without tagging, but then we lose GitHub releases. I don't know if there's a backwards-compatible way of doing this.

I think the backwards-compatible way would be to release both npm and Git tags (I'm very much against skipping Git tags) but keep around the old versions (just the CSS files, no sourcemaps and stuff) in the dist/ folder for the foreseeable future, just for legacy reasons. Not 100% 'clean' but that's backwards-compatibility to ya. 😅

Good point - however, the dist folder is still where new builds are being outputted to. This means either pull requests will introduce merge conflicts again, or it'll stay gitignored and get deleted on every merge.

Good point - however, the dist folder is still where new builds are being outputted to. This means either pull requests will introduce merge conflicts again, or it'll stay gitignored and get deleted on every merge.

I think if we keep the legacy files in dist/ and .gitignore it, there won't be any merge issues. The only think that happens is that they'll get overwritten on disk if you build the project and the new CSS files have the same name. (but those changes won't be pushed to GitHub and thus don't end up in PRs) So it might be a little confusing but isn't a technical problem. (and we can control which files to publish with the "files" property in "package.json" so we're only publishing the new files despite others hanging around in dist/)
Otherwise, we could just turn dist/ into a full on legacy directory and output to out/ or whatever from now on.

Turning dist/ into a legacy directory might actually be a better idea. Lemme make a proof of concept of out/.

Just renamed dist/ to out/ and added the dist/ from the current master branch. I also updated the changelog. Thoughts?

Just an FYI, I'm unavailable for the near future. Good luck with the 2.0 release!

Just an FYI, I'm unavailable for the near future. Good luck with the 2.0 release!

No problem, thanks!

Awesome! :shipit:

I'm scared :sweat_smile: :shipit:
(Also gonna merge locally and then push to make sure nothing explodes)

yarn changeset publish didn't work! Had to manually publish and tag.
Should be working though, time to test :)

yarn changeset publish didn't work! Had to manually publish and tag.

What did it complain about? :D

Aaaand it works <3

😍😍😍 !!!


Unit test updates for ophyd simulated Devices

Two small changes to unit tests for compatibility with updated ophyd simulated hardware.
This is really the work of @tacaswell, in case that is not obvious.
Motivation and Context
This PR corresponds to the larger PR for ophyd #762, which aligns simulated hardware classes with "real" ophyd objects. This resolves an issue in suitcase-utils, which currently depends on an ophyd branch.
How Has This Been Tested?
The bluesky tests pass with ophyd PR #762.

Is it actually "Ready for review" or still a draft?

Why "do not assign to value at initialization"?

Can you address this question, @tacaswell?

This does not answer the question, but I think value=0.0 was added in hope that it would do everything put(0.0) does, so reverting to put(0.0) is going back to the way things were.

We'll question @tacaswell in person next week why that value=0.0 -> put(0.0) was needed. To me it looks like they should behave identically.

My guess is that .put() triggers a monitor update and initialization does not.

You would think that, but internal to synsignal it does super().__init__(value=_func(), ..., **kwargs) so you get "multiple values passed" errors.


Best way to add Cache-Control to assets?

I'm going through Lighthouse recommendations and the only major thing left for me is to "Serve static assets with an efficient cache policy"
The recommendation here is to add a Cache-Control: max-age=xxxxxxx header.
Further reading here: https://developers.google.com/web/tools/lighthouse/audits/cache-policy?utm_source=lighthouse&utm_medium=cli
Do we need to update the s3 upload, api-gw-static.yml, or is there a more preferred way?

@mattdell I have submitted a PR to get things going (see #40). However I suspect it is being ignored because it is applicable to the old plugin and not the new component.

@barrysteyn Sorry I’ve not had time to look into this, been quite busy with the component release.
I’ll have a look today or tomorrow. However, I do recommend moving over to the new component as its effectively a new version (unfortunately breaking :()

Yes, I intend to move over. But I need to support this version until I am able to migrate us there. Also, we have our backend in another repo and may not be able to combine the two that easily as is recommended by the new component.

Hi folks 👋 Now that https://github.com/danielcondemarin/serverless-next.js/pull/144 has been merged (thanks to @barrysteyn for implementing!) I'm closing this 🚀


[Jupyter] No error messages when doing something in the napari Window

🐛 Bug Report
I have the problem that if there is an error raised while doing something inside the napari window, I do not see this anywhere. Shouldn't there be some kind of window popping up and giving me information on the error? Or printing it to the console?
💡 Steps to Reproduce
Here is some code to illustrate my problem:
import napari
import numpy as np
from napari.layers import Image
from magicgui import magicgui

@magicgui(image={'label': 'Pick an Image'})
def my_widget(image: Image):
    raise ValueError("Error")
    print('hello')

viewer = napari.view_image(np.random.rand(64, 64), name="My Image")
viewer.window.add_dock_widget(my_widget)

When pressing the "Run" button a ValueError should be raised. But instead nothing happens. If I comment out the ValueError, it prints "hello" to the console as expected. Is there a way to catch errors and display them somehow? This would make debugging a lot easier.
Thanks a lot in advance for your help!
💡 Expected Behavior
No response
🌎 Environment
napari: 0.4.18
Platform: Windows-10-10.0.19045-SP0
Python: 3.9.18 (main, Sep 11 2023, 14:09:26) [MSC v.1916 64 bit (AMD64)]
Qt: 5.15.2
PyQt5: 5.15.9
NumPy: 1.25.2
SciPy: 1.9.3
Dask: 2023.9.2
VisPy: 0.12.2
magicgui: 0.7.3
superqt: 0.6.0
in-n-out: 0.1.8
app-model: 0.2.2
npe2: 0.7.2
OpenGL:

GL version:  4.6.0 Compatibility Profile Context <IP_ADDRESS>.230830
MAX_TEXTURE_SIZE: 16384

Screens:

screen 1: resolution 2560x1600, scale 1.0
screen 2: resolution 3840x2160, scale 1.0
screen 3: resolution 2880x1800, scale 1.0

Settings path:

AppData\Local\napari\xparse_57fe1a37b30a9e37de3a06866d324c7f56a92d1a\settings.yaml
Plugins:
napari: 0.4.18 (77 contributions)
napari-console: 0.0.8 (0 contributions)
napari-svg: 0.1.10 (2 contributions)
ome-types: 0.4.2 (2 contributions)

💡 Additional Context
No response

There should be dialog poping in the bottom right corner of the canvas. They disappear after some time.

Yes. Popup will not show if you create a napari viewer from Jupyter notebook as we do not install a custom hook for exceptions in such cases.
But I do not know why it is not printed in notebook.

Ok good to know that this is the expected behaviour! Thanks!

This issue is like a worse version of https://github.com/napari/napari/issues/6455
Same root cause I suspect.

No. this is a lighter version. As in #6455 message is not printed anywhere, and here it looks like a problem with Jupyter server as default hooks should be called.

Is there a workaround for this or currently not?

Try this code at the beginning of notebook:
import sys
import traceback

def my_excepthook(type_, value, trace_back):
	traceback.print_exception(type, value, trace_back, file=sys.stderr)

sys.excepthook = my_excepthook

Unfortunately, I still cannot see the error messages.

What if you change sys.stderr to sys.stduot?

No this also does not fix it...

I can actually not reproduce the error when running jupyter alone or through VS code.
In all configurations (pure jupyter notebook, VS code  ipynb with python env, VS code ipynb with jupyter kernel) do not get the popup, what's not optimal, but I do get an error traceback in jupyter.
My best guess is there might be something besides napari play into this issue.
Did you try running the notebook through jupyter notebook directly?
Do you get the same result when doing it this way?

@jwrth @Chris-N-K
I believe that my PR: https://github.com/napari/napari/pull/6882 should have solved this.
The notification in the viewer should happen now.

Grrr!
The example above still doesn't result in a notification with the traceback in iPython and JupyterLab -- it does it napari is run stand-alone.


Can't store XP in XP Obelisk

Is there an existing issue for this?

[x] I did not find any existing issues.

Current Behavior
When clicking on any of the 'store' buttons it doesn't store any XP
https://github.com/user-attachments/assets/27848f53-3118-4080-a1c1-87d99a97d824
Expected Behavior
When clicking on the 'store' buttons it should store any XP
How to Test

Have some XP;
Place an XP Obelisk;
Click on any of the 'store' buttons;
It doesn't work.

Local Environment
- **Operating System**: Fedora Linux 41 (KDE)
- **Java version**: 21.0.3
- **Minecraft Version**: 1.21.1
- **Mod Loader**: NeoForge
- **Ender IO Version**: 7.0.11 alpha
- **Other Mods**: ATM 10 (2.3)

Any Additional Information?
Pumping XP through some cables still allows it to store normally.

Can you attach your game logs? Thanks

latest.log

I can't replicate this in my dev env. From the video, I can see that you are pumping exp into the block as well. Is this right ?

Yes

No idea why, but removing all XP from it fixed the bug.

Hm, it could be because it's trying to pump and withdraw at the same time. I will investigate

I've had the same issue, but in my case, it seems to be a fluid mismatch. While the obelisk accepts successfully liquids like Essence from Industrial Foregoing, it fails to add experience to the pylon via the player as it likely (haven't read the code) is trying to input XP Juice, which is its native experience fluid, into a container that has another type of liquid experience already.

Now that you mentioned it, I input fluids from the XP Vacuum and the Foregoing's Crusher and, after stopping storing, from the XP Drain in Mob Grinding.


Add paragraph that Http1AndHttp2 is not supported without TLS

Addresses https://github.com/grpc/grpc-dotnet/issues/460
Internal review URL: https://review.docs.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-3.0&branch=pr-en-us-13891#unable-to-start-aspnet-core-grpc-app-on-macos

Just nits @JamesNK ... Merge this when ur ready.

@Tratcher @halter73 Could one of you take a quick look at this PR, and the document in general, to make sure everything that discusses TLS + Kestrel is correct?


Package not found

Getting Package not found when requesting for permissions. Checked on API Level 31 and 32. Attaching Log Screenshot

Can you share a sample?


Exec: Support run exec in current task

Summary
There is a problem when vfork() calls execv() (or execl()) to start a new application:  When the parent thread calls vfork() it receives and gets the pid of the vforked task, and not  the pid of the desired execv'ed application.
see  issue #3334
Impact
exec series funciton
Testing
sim

@xiaoxiang781216

@yangyalei please include the Summary in the commit log message

@yangyalei please include the Summary in the commit log message

done

Please fix this message:
This branch cannot be rebased safely
Rebasing the commits of this branch on top of the base branch cannot be performed automatically as this would create a different result than a regular merge.

@yangyalei  @xiaoxiang781216
I noticed that assertion now happens with spresense:elf.
Hello, World on stdout
Hello, World on stderr
We failed to open "aflav-sautga-ay!" errno is 2

Memory Usage after program executiotestheader:
****************************************************************************
* Executing hello
****************************************************************************

_assert: Current Version: NuttX  12.0.0 0beba027e7 Sep 15 2023 08:25:18 arm
_assert: Assertion failed : at file: group/group_exitinfo.c:85 task: elf_main 0xd00a005
up_dump_register: R0: 2d02fc80 R1: 2d0318c8 R2: 00000000  R3: 00000080
up_dump_register: R4: 2d02fc80 R5: 2d0318c8 R6: 2d02f624  FP: 0d02c8aa
up_dump_register: R8: 00000000 SB: 00000055 SL: 00000080 R11: 00000000
up_dump_register: IP: 2d02f7cc SP: 2d032320 LR: 0d003979  PC: 0d003979
up_dump_register: xPSR: 40000000 BASEPRI: 00000080 CONTROL: 00000004
up_dump_register: EXC_RETURN: 00000000
dump_stack: User Stack:
dump_stack:   base: 0x2d031cc8
dump_stack:   size: 00002016
dump_stack:     sp: 0x2d032320
stack_dump: 0x2d032320: 0d02c8aa 00000055 2d03194c 0d00a005 2d0318c8 2d02fc80 00000000 0d02c8aa
stack_dump: 0x2d032340: 00000055 7474754e 2d030058 2d032358 00000000 2d032ab8 00000006 0d0044a5
stack_dump: 0x2d032360: 2d030c50 2d030c50 2d032ec0 0d004691 2d030c50 0d007bd9 2e323100 00302e30
stack_dump: 0x2d032380: 00000000 0d007b27 2d032d18 62302a64 30616265 37653732 70655320 20353120
stack_dump: 0x2d0323a0: 33323032 3a383020 313a3532 00000038 2d032938 0d004e3f 2d032938 0d004173
stack_dump: 0x2d0323c0: 6d7261f0 2d032900 00000080 0d005119 2d032938 00000003 2d032780 00000080
stack_dump: 0x2d0323e0: 000000e0 0d02bc58 2d032458 00000000 00000000 0d007a43 00000080 0d00ed99
stack_dump: 0x2d032400: 2d02f7f0 2d032780 00000003 0d00d55f 00000000 00000000 00000000 00000023
stack_dump: 0x2d032420: 0d02bc58 0d014c0b 0d014bf7 0d014b68 00000000 0d00d587 00000023 00000000
stack_dump: 0x2d032440: 00000000 00000000 2d02f198 0d00a10b 00000023 0d014c0b 0d02bc58 00000000
stack_dump: 0x2d032460: 0014f300 000000b8 00000200 0d014c58 00001824 0014db88 0d00a005 00000001
stack_dump: 0x2d032480: 2d031cb0 00000000 00000000 0d007d77 00000000 0d00518f 00000000 00000000

@yangyalei @xiaoxiang781216
I noticed that assertion now happens with spresense:elf (CONFIG_DEBUG_ASSERTIONS=y)

You can reproduce the same assertion with sim:elf (CONFIG_DEBUG_ASSERTIONS=y)

@yangyalei @xiaoxiang781216
I noticed that assertion now happens with spresense:elf (CONFIG_DEBUG_ASSERTIONS=y)

You can reproduce the same assertion with sim:elf (CONFIG_DEBUG_ASSERTIONS=y)

Is there anything special about the hello application? I will reproduce it.

Is there anything special about the hello application?

Nothing special. I just enabled CONFIG_DEBUG_ASSERTIONS for the test.

Is there anything special about the hello application?

Nothing special. I just enabled CONFIG_DEBUG_ASSERTIONS for the test.

Looks link spresense:elf target need arm environment. I compiled but can't run the target.
Instead, I test in sim:elf with CONFIG_DEBUG_ASSERTIONS=y, It works well.
Can you help to reproduce in sim:elf?

Instead, I test in sim:elf with CONFIG_DEBUG_ASSERTIONS=y, It works well.
Can you show more details to help reproduce in sim:elf?

$ git diff
diff --git a/boards/sim/sim/sim/configs/elf/defconfig b/boards/sim/sim/sim/configs/elf/defconfig
index 999b22a726..6916613390 100644
--- a/boards/sim/sim/sim/configs/elf/defconfig
+++ b/boards/sim/sim/sim/configs/elf/defconfig
@@ -17,6 +17,8 @@ CONFIG_BOARDCTL_ROMDISK=y
 CONFIG_BOARD_LOOPSPERMSEC=0
 CONFIG_BOOT_RUNFROMEXTSRAM=y
 CONFIG_BUILTIN=y
+CONFIG_DEBUG_ASSERTIONS=y
+CONFIG_DEBUG_FEATURES=y
 CONFIG_DEBUG_SYMBOLS=y
 CONFIG_DEV_LOOP=y
 CONFIG_DEV_ZERO=y
@@ -39,6 +41,7 @@ CONFIG_INIT_ENTRYPOINT="nsh_main"
 CONFIG_LIBC_ENVPATH=y
 CONFIG_LIBC_MAX_EXITFUNS=1
 CONFIG_LIBC_STRERROR=y
+CONFIG_NDEBUG=y
 CONFIG_NSH_ARCHINIT=y
 CONFIG_NSH_BUILTIN_APPS=y
 CONFIG_NSH_FILE_APPS=y
...

$ ./nuttx

NuttShell (NSH) NuttX-12.0.0
MOTD: username=admin password=Administrator
nsh> elf
Initial memory usage: 1332408
elf_main: Registering romdisk at /dev/ram6

Memory Usage after romdisk_register:
  Before:  1332408 After:  1332536 Change:      128
elf_main: Mounting ROMFS filesystem at target=/mnt/romfs with source=/dev/ram6

Memory Usage after mount:
  Before:  1332536 After:  1333272 Change:      736
testheader:
****************************************************************************
* Executing errno
****************************************************************************

Memory Usage after exec:
  Before:  1333272 After:  1403160 Change:    69888
elf_main: Wait a bit for test completion
Hello, World on stderr
We failed to open "aflav-sautga-ay!" errno is 2
Hello, World on stdout
nsh>
Memory Usage after program execution:
  Before:  1403160 After:  1401848 Change:    -1312
testheader:
****************************************************************************
* Executing hello
****************************************************************************

_assert: Current Version: NuttX  12.0.0 0beba027e7-dirty Sep 15 2023 13:21:27 sim
_assert: Assertion failed : at file: group/group_exitinfo.c:85 task: elf 0x55732de8e247
Getting ready to say "Hello, world"

Hello, world!
It has been said.
...

@yangyalei @xiaoxiang781216
Let me revert this PR until you fix the above issue.

@yangyalei @xiaoxiang781216
Let me revert this PR until you fix the above issue.

OK, I have know the root cause and will modify it in the new PR.


Recent build no longer associated with terminal icon - possible mime-type issue.

Which operating system does the issue occur on? I'm on OpenSUSE Leap 42.3
If on linux, are you using X11 or Wayland? X11

Starting alacritty through another terminal or using a keyboard shortcut works fine, so this is not a build issue; however, alacritty used to be associated with terminal icon on my desktop, and now it's a plain white 'unknown' icon.
A recent build of alacritty isn't associated with the utilities-terminal icon on my machine. I've looked into it a bit, and it seems to be related to it's mime-type. For instance, trying to execute alacritty through the file explorer results in the following error:

I was able to fix this problem by building alacritty with RUSTFLAGS="-C relocation-model=dynamic-no-pic" (based off a comment in this answer), but I don't know enough about how applicable this is to the rest of the project to put in a PR.
Maybe others will find this useful.

Sounds like this is an issue with your .desktop file. I have no idea why recompiling without PIC would make a different or how you came to that solution. This is unlikely to be a problem with alacritty and more probably a config issue on your system.

HI @jwilm thanks for your comment. Just to clarify, I didn't changed the .desktop file - it's the same one distributed with this project. After building alacrirtty using cargo build --release, I copied the resulting binary to ~/.local/bin where I have other user-level packages installed. I also don't know what you mean by a config issue - do you have an idea of where to look?


Can anyone gives me the template for running all of the animation?

i'm stuck and did not able to use any of the animation except a few one!

Yes, if anyone has done it, please provide with the template.


Move timeouts to playwright-wrapper side to allow improved debug logging when a timeout happens

If / when node process gets stuck the sanest thing would be for the node side to timeout and send a sensible log message / output through STDOUT or the protocol instead of getting forcefully killed
Easily doable by adding a https://github.com/microsoft/playwright/blob/master/docs/api.md#browsercontextsetdefaulttimeouttimeout playwright context setdefaulttimeout param to the wrapper startup params

POC (with 1 test) added in f0c9bd2 . Will need to trycatch all playwright side method calls, with a catch(){grpcCallback()} to actually pass playwright timeouts to robot side.


Do not wake up standby pipelines when a parent job failed

Currently (1.9.x), if a pipeline is set with standby = true, runner pods are created even when a parent of the pipeline failed (hence the pipeline will fail with input xxx failed). That seems like a large waste of time in case the pipeline requires a large amount of memory for instance and the pipeline may spend a lot of time in PENDING state until the cluster has enough resource to schedule the pod.
If ever Pachyderm really needs to start a pod, please could the parallelism be overridden to 1? Because there is no need to start up x pods when we know that the job will fail.
That would be very much appreciated!

This is something that shouldn't be too difficult to do, adding it to our future project.


move instance reconciliation to one queue

@pmorie and I discussed, and we ended up coming to the conclusion that it'd be best to merge the two queues for instance reconciliation. The logic for the current implementation was seen as difficult to follow and contains a bug that did not allow for the decaying rate of polling to function properly.
In this model, there is a separate worker function that handles reconciliation for instances. It takes a reconciliation function that passes back a parameter telling the controller whether that instance should be polled. Polling in this model is a static interval (default set to 30 seconds).

Currently making a couple changes, and investigating the integration test flakes (here and in general).

Alright, this should be good to go now. I also believe it and my PR #1110 have fixed the integration test flakes; on my local machine I've run them dozens of times and haven't seen anything come up, whereas before I would hit them regularly.

I don't think we should have the pervasive signature changes - here's what I suggest:

add a new worker method that implements these semantics
only change the instance functions
make reconcileInstance return (bool, error)

Need to think about this some. I noticed that this wouldn't be enough to enforce the polling rate limiting. Every time you poll, if the broker response contains a description of the polling event, we update the instance's condition with this information. This would trigger a reconcile that bypasses the rate limited polling logic.

Closing this in favor of changes made in #1143


Add Tests

Come on...

Maybe add "help-wanted" label? Probably don't need this though?

I am learning Prometheus and I this seems like a good way to kill two birds with one stone :)


Fixes the failure of nightly CI on macOS by fixed the rust toolchain version to 1.60.0.

What do these changes do?

Related issue number

Fixes

Codecov Report

Merging #1777 (c3ec3ca) into main (9abea6d) will decrease coverage by 36.04%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main    #1777       +/-   ##
===========================================
- Coverage   76.13%   40.08%   -36.05%
===========================================
  Files          89       89
  Lines        9798     9798
===========================================
- Hits         7460     3928     -3532
- Misses       2338     5870     +3532

Impacted Files
Coverage Δ

python/graphscope/tests/unittest/test_app.py
0.00% <0.00%> (-100.00%)
:arrow_down:

python/graphscope/tests/unittest/test_context.py
0.00% <0.00%> (-100.00%)
:arrow_down:

python/graphscope/tests/unittest/test_session.py
0.00% <0.00%> (-100.00%)
:arrow_down:

python/graphscope/tests/unittest/test_download.py
0.00% <0.00%> (-100.00%)
:arrow_down:

python/graphscope/tests/unittest/test_java_app.py
0.00% <0.00%> (-100.00%)
:arrow_down:

...ython/graphscope/tests/unittest/test_cython_ast.py
0.00% <0.00%> (-100.00%)
:arrow_down:

...ython/graphscope/tests/unittest/test_serailaize.py
0.00% <0.00%> (-100.00%)
:arrow_down:

python/graphscope/analytical/udf/patch.py
3.47% <0.00%> (-96.53%)
:arrow_down:

python/graphscope/tests/unittest/test_lazy.py
0.00% <0.00%> (-96.30%)
:arrow_down:

...thon/graphscope/tests/unittest/test_scalability.py
0.00% <0.00%> (-96.16%)
:arrow_down:

... and 46 more

Continue to review full report at Codecov.

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


Run eslint on whole project

Closes #544
I think it would be useful to run eslint across all javascript source files in the repo so that simple mistakes etc. are caught even in non-prod code.
Currently the test/ directory requires a lot of extra rules to be applied; these could be reduced in future as specific violations are cleaned up.
If .json is the preferred format for .elsintrc files in this project, then this can be converted.
The use of private as a variable name in encryption.js prevents eslint from running against this file, as otherwise eslint will fail with the error:
odk/backend/test/integration/other/encryption.js
  84:24  error  Parsing error: The keyword 'private' is reserved

I think running ESLint on test/ would be useful! It's definitely tricky though to figure out how to handle previous ESLint issues. Rather than turning these rules off, what do you think about disabling ESLint (or the ESLint rule) for the specific lines with issues? (Could there be a way to do so automatically?) That way, we could keep these rules on for new tests while ignoring them for old tests.
Alternatively, what do you think about making these rules 'warn' instead of 'off'? That way, we wouldn't be ignoring them, even for old tests, but they also wouldn't fail in CircleCI. If we did that, maybe we'd also want to run ESLint on test/ before src/ so that warnings from test/ are shown above any issues in src/.

@matthew-white I've update the PR to separate lint runs on the test dir vs the rest of the repo, and change all the test rules to warn.  The make lint output is now very noisy.  If you'd prefer individual disable tags for each current violation in the test dir, that would be simple to implement.

If you'd prefer individual disable tags for each current violation in the test dir, that would be simple to implement.

If that's not too hard, I think that would be quite nice!

@matthew-white done :+1:
I cleaned up a few simple violations (e.g. newlines at end of files)

I've removed violations of no-unused-vars and indent.


Gtp-u

Description
Addition of support for GTP-U (GPRS Tunnelling Protocol)
Type of change

[ ] Bug fix
[ ] New feature
[X] New protocol
[ ] Breaking change
[ ] Documentation update

Checklist

[X] Associated tests
[ ] Associated documentation

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: drunkirishcoder:x: mikebromwichYou have signed the CLA already but the status is still pending? Let us recheck it.


How to config Azure OpenAI?

I tried this:
docker run -d -p 3000:3000 -e CODE={} -e AZURE_URL=https://{azure-resource-url}/openai/deployments/{deploy-name} -e AZURE_API_KEY={} -e AZURE_API_VERSION={} yidadaa/chatgpt-next-web

When open in browser, I got below error:

Did I miss something in the docker command?

Please follow the issue template to update title and description of your issue.

The page is not found.

@hecongy did you fix it?

@hecongy I fixed it, just I set the full endpoint in the endpoint.

Yes, I fix it, the issue is that I used a wrong AZURE_API_VERSION.


Questions with batch normalization

Hello, I just added BN in resblock and run 'python train.py configs/celebA-HQ', then it cannot converge at all.(see the picture below)

I noticed the moving average in your training, but I think its influence to BN is quite small. I cannot understand the reason why adding BN cannot converge.
Looking forward to your reply!

The moving average has a significant influence with batch normalization, as it simply ignores the learned weights from the BN when copying the model. Can you try to deactivate the moving average in the code and try again? Also note that our theoretical results are local in nature and we therefore cannot guarantee global convergence for every possible architecture you come up with :-) . However, from your image it appears that the algorithm is doing something sensible.


Asura Scans changed it's source link

Source name
Asura Scans
Source link
https://asuracomic.net/
Source language
English
Other details
the source link changed from "asuratoon.com" to "asuracomic.net"
Acknowledgements

[X] I have checked that the extension does not already exist by searching the extension listing and verified it does not appear there.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[X] I will fill out all of the requested information in this form.

I thought that the bug was  a different one, sry

Oh Ok


Potential container path bug on Windows with no UUID being present

Container path UUID may not be getting substituted in correctly on Windows. Either install prefix with C:/ is a problem, or multiple config file entries specifying same archive.

Install prefix containing C:/ and C:\\ both appear to be okay, as do multiple config file entries specifying the same archive (when testing on a Unix-based system). Will do the same tests on Windows next.
One additional observation: symlinks don't result in additional entries being added to the containerPath list, only the installPath list. Not sure if this is a bug or a feature... it does give a way to distinguish which paths are symlinks, but it's unclear if symlinks are "contained" in an archive/installer/container or not.


python3Packages.warlock: enable tests

Motivation for this change
Enable tests and relax jsonschema constraint.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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

[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.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
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 158790 run on x86_64-linux 1

4 packages built:

python310Packages.python-glanceclient
python310Packages.warlock
python39Packages.python-glanceclient
python39Packages.warlock


changes to formopscreening form

Description
ticket: 2100
summary:
- re-name ‘Operation Details’ to: ‘Employer-Provided Housing Sites'
- hide the Operation start/end date, Closest city, Number of workers fields
- hide tent/trailer checkbox
- hide ‘Worker's Lodging Location (Motel, hotel, or other lodging)' checkbox. BUT show the related name/address/city/province/postcode fields
- hide ‘worker’s home in community’ checkbox
- remove COVID-19 coordinator heading and fields
- some way to indicate if the main business address is a housing site
- text box for multiple sites
wording changes to landing page to account for item 8 and ability to add multiple locations.

Types of changes

New feature (non-breaking change which adds functionality)

Checklist

[x] I have read the CONTRIBUTING doc
[x] I have checked that unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments
Business wants to simplify the form and change the way locations (either employment or accommodation) are captured in the form. This involved re-purposing the 'motel' address fields and adding an extra 'additional locations' textarea.
I didnt rename the model props or db columns for these. Could do in a later ticket.
For form fields they decided they didnt want in the form (for example 'covid contact') I have either put in default values in the store or made them not required in the model.
Want to get this promoted asap as requested by the business.

PR Deployed at: https://comfort-dev.apps.silver.devops.gov.bc.ca/pr-176