Update rust-lorawan and embassy to use lora-phy version 2

Update rust-lorawan and embassy to use lora-phy version 2.  This includes the latest released version of embedded-hal-async.

With this update, if the embedded-hal-async crate is updated while I am away until late October, the update to lora-phy to support it needs to be made on the main branch rather than the v1.x branch.


tested updates for v1.8

see the commit list
TODO around merge:

[x] add to the CHANGES.md

CHANGES.md updated in #3095

LGTM - feel free to merge

merging to be part of v1.8.0RC1


[Bug]: Site is not filtered by region in add access list form

NetBox access-list plugin version
1.0.0
NetBox version
3.2.7
Steps to Reproduce

Go to add access list page
Select an existing region
Open the site drop and notice the results
Remove the region selection
Open the site drop and notice the results

Expected Behavior
Sites should be filtered by regions
Observed Behavior
Full list of site is displayed

Thanks! I'll take a look hopefully this weekend. Also happy to collaborate.

I'll raise a PR for this today. It's quite an easy fix.


Heapster/monitoring-grafana services removed by kubernetes

Hi,
Following the guides on:  https://github.com/kubernetes/heapster/blob/master/docs/influxdb.md
After a ~5 minute period the heapster and monitoring-grafana services are deleted.
Based on the info from: https://github.com/kubernetes/heapster/issues/1185
This is due to having specific  kubernetes.io/cluster-service: 'true'
If i remove this line from grafana-service.yaml and heapster-service.yaml, the heapster dashboard remains available.
Is this a correct workaround? :)

There is addon updater, which periodically (every ~5 minutes) checks whether cluster services are up to date. As a side effect it removes all pods with the annotation from kube-system namespace which were not created from manifests.
Removing the annotations is correct workaround. Another option is to run Grafana and Heapster in a different namespace.


[Bug] Auto Build Workflow Might Cause Git History Diverged

Recheck

[x] I've already updated to the latest Vim/NeoVim version
[x] I've already updated to the latest Suisei version
[x] I found nothing related to this bug in the Wiki or Issues

Description
Running :PlugUpdate to update Suisei.vim will cause git complaining about the diverged history. A workaround way is to run :PlugClean first.
To Reproduce
Update the already installed version

There seem to be no other better methods than doing the generation process in git hook locally, this would require the developer to have the vim environment and the corresponding plugin.

Closed, now the generation task needs to be done before committing.


Add 1.20.6 support (paper only)

Using NBT-API for componential NBT adapting.
Migrated old format checks (ignore checks that just return PASS).

Plugin Commission by @TWME-TW.

Thanks. I will be looking at this very soon.

I have added some fixes.
The 1.20.5 is a significant data structure update, so there are lots of difference in NBT.
I have tried my best in migrating them to new format.
If there's any flaw, don't hesitate to let me know!

Is there a jar file of the 1.20.6 version for Panilla already? Kinda have an issue with people abusing these nbt items.

I did some testing. Looks like we'll have to change the way enchantments are checked. They are no longer stored as a list. minecraft:enchantments has a compound tag called levels which has each enchantment stored as a named integer.
Would you be capable of making the change to support this? I would create an enchantments NbtCheck in your new paper1_20_6 package and remove the minecraft:enchantments and minecraft:stored_enchantments from NbtCheck_ench.
I am suspicious that other things may have changed too. I wish I had added some sort of unit testing to this project.

Sure, please help me find out other checks that I missed.
I will work on the enchantment check in 2 days.

Enchantment fix done.

Enchantment fix done.

Thanks. I'll check it today.

Looks great. I am going to go ahead and merge this, do some formatting cleanup, and make a release.
Thank you again for your contributions!


Test addsavingmoney

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Files with missing lines
Coverage Δ

moneymap/tests/test_addsavingmoney.py
100.00% <100.00%> (ø)

moneymap/tests/test_goal.py
100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes


API Rename

The APIs should be renamed in an object-oriented manner.
For example:
request_* / check_* / *_req -> get_*
modify_* -> set_*

Have renamed most.


Allow loadMemoryFromFile(MemBase[T <: Bundle])

@see https://github.com/freechipsproject/chisel3/issues/968
Linked with https://github.com/freechipsproject/chisel3/pull/970 and https://github.com/freechipsproject/treadle/pull/77.
This PR is almost ready to go. During testing, it seems as though there's a second pass in which the original annotation exists but the memories have already been split.
Update: the second pass happens here. I'm still not sure why the original LoadMemoryAnnotations are still there, though.

@nhynes we appreciate your digging into this. I thought I had already done some testing of this case and I thought the annotation renaming pass in firrtl should have taken care of this problem. I want to check that out first, then I will go over your PR here. Thanks for the help

Hrm. If it makes any difference, I'm using chisel-testers2 because it actually handles DecoupledIO in a not-unreasonable way.
Thanks a lot for your help!

Actually, I think that this might be a bug elsewhere. Upon closer inspection, the renames are working initially, but aren't preserved on the curious second pass.


Tekken Player List issue

The players I play with are not added to the list. I tried to delete the old list and run the program as an administrator, but nothing helps

Thank you for the feedback! You are right, I just tested it and mine doesn't save either. My bad for not testing it properly. I'll try to get it fixed as soon as possible.


Add methods and UI for associating and disassociating floating IPs w/ Openstack Cloud Instances

@aufi can you review?
@Loicavenel does this GUI look okay to you?

Couple of Comments:

this should be available only for OpenStack and not the other Cloud Provider
This should support tagging, user will see only the IP that are tagged if tagging is used
I think Attach/Detach Volume and Associate/Dissacociate should be under the line with Reconfiguration

@Loicavenel could you explain more what you mean about supporting tagging? I don't quite understand.

@mansam I put some comments, but looks good

Basically, many objets like Floating IP can be tagged, and this tag can be used as filter for user. then user will see only object that match their tag. This is used when you view objects but also when you run actions. I don't know if this is generic in UI or must be implemented.

@Loicavenel @aufi there are methods that will apply RBAC on the entities, so you present to the user only things he has rights for. @lpichler can you point them to which methods should be used?

Hi ,@Loicavenel @aufi it depends on your cases and parameters but if have  AR objects already you can use something like this
Rbac.filtered(objects) and if not
Rbac.search(:class => "Vm", :results_format => :objects)
and there is the search method with documented parameters
https://github.com/ManageIQ/manageiq/blob/master/app/models/rbac.rb#L367
let me know if this works for you

@tzumainn @mansam by default any actions that is using taggable objects should respect RBAC.

@tzumainn when you are 👍 on this, please reassign to @blomquisg
/cc @Ladas @dclarizio

Closed in favor of #9475 and #9476


Generating many client tokens

I apologize for the cross-post, but I'm not sure if the problem I'm experiencing is related to this gem or it's angular library counterpart (or my improper implementation), but I've posted my issue here also:
https://github.com/lynndylanhurley/ng-token-auth/issues/140
What I'm seeing is that when I close the browser while logged in, and I then open the browser and log back into my app, it generates a new client token.
This causes many client tokens to be generated.
Is anyone else experiencing something like this? Any ideas on how to prevent this?

Did you try this in your initializer :
DeviseTokenAuth.setup do |config|
  config.change_headers_on_each_request = false
end

SQL (0.5ms)  UPDATE "users" SET "tokens" = $1, "updated_at" = $2 WHERE "users"."id" = $3  [["tokens", "{"Q4g1PZrCdBb18Ndxxli55A":{"token":"$2a$10$7BLPPqKnPCNiBZ.O8uWIkOELtUak88RO9lFhIKdex7AjI2RqrsH7K","expiry":1433030748},"EwsS1phl1A9_plCI02eB7w":{"token":"$2a$10$5xgFolVXRhtzYKKE2lIccO2ytgc65gVQN74JS2hYBUw72.bZgW7vS","expiry":1433030766},"93fuGltfv8LO3-2_g3RF2Q":{"token":"$2a$10$qD4NdH0yaLA4AXORuCZ59eyHzyL/bqKKvDjjKlvN3iMbw.rGZKbhO","expiry":1433030814},"8_SQvQe5zq-ICJa1e-biYw":{"token":"$2a$10$DqlURiArR8n.L6Xrv3bs2.fIj/WYqdhU3UsUCKaca6VK8HhijfnSa","expiry":1433030826},"oCThb8B-epVt5A2aOWKStA":{"token":"$2a$10$FaqquEXhCy5dxaGUFdxnxOHdIp5mqvJgKbaYpXUw/j5ptVXmAd7XG","expiry":1433030837},"OlQ-X6i5wXbTGHHgj5ceuw":{"token":"$2a$10$FjMZg4GykcJUVxqAv4FayuaLsul5cgljmEkAgDja6UKlpvDWP0jMG","expiry":1433030858},"DUqK_RA5dGLVq-cRY1Dnhg":{"token":"$2a$10$MA9SWeut0G1pBK6jwAfRTevwES/uh.tsh5gdQFof0b2sHuvcAKfu6","expiry":1433030870},"eY5gn1JuHfle4bI8wOddyQ":{"token":"$2a$10$qshqJ2s2PdSdD2JstZtq.uBckvOLhOnqlwRdWXobXENMN.yS6bkjK","expiry":1433031039,"last_token":"$2a$10$INZb8EVrslHc/af4W6UoSuR83yKpcdmEqkEWb5CN04v96RGgupRXW","updated_at":"2015-05-17T08:10:39.643+08:00"}}"], ["updated_at", "2015-05-17 00:10:39.646659"], ["id", 1]]
Stil have so many tokens while sign in.

Well, I can see many implementation to solve this:

We can LIMIT the number of token generated by adding a created_at , near
the expiry key. When we reach the limit, we delete the last one used.
we need to understand WHY the creator of this gem has implemented a
c"lient_id". When many others just use a single token. What issue solve the
use of the "client_id" ?
On Sun 17 May 2015 at 02:11 qx<EMAIL_ADDRESS>wrote:

SQL (0.5ms) UPDATE "users" SET "tokens" = $1, "updated_at" = $2 WHERE
"users"."id" = $3 [["tokens",
"{"Q4g1PZrCdBb18Ndxxli55A":{"token":"$2a$10$7BLPPqKnPCNiBZ.O8uWIkOELtUak88RO9lFhIKdex7AjI2RqrsH7K","expiry":1433030748},"EwsS1phl1A9_plCI02eB7w":{"token":"$2a$10$5xgFolVXRhtzYKKE2lIccO2ytgc65gVQN74JS2hYBUw72.bZgW7vS","expiry":1433030766},"93fuGltfv8LO3-2_g3RF2Q":{"token":"$2a$10$qD4NdH0yaLA4AXORuCZ59eyHzyL/bqKKvDjjKlvN3iMbw.rGZKbhO","expiry":1433030814},"8_SQvQe5zq-ICJa1e-biYw":{"token":"$2a$10$DqlURiArR8n.L6Xrv3bs2.fIj/WYqdhU3UsUCKaca6VK8HhijfnSa","expiry":1433030826},"oCThb8B-epVt5A2aOWKStA":{"token":"$2a$10$FaqquEXhCy5dxaGUFdxnxOHdIp5mqvJgKbaYpXUw/j5ptVXmAd7XG","expiry":1433030837},"OlQ-X6i5wXbTGHHgj5ceuw":{"token":"$2a$10$FjMZg4GykcJUVxqAv4FayuaLsul5cgljmEkAgDja6UKlpvDWP0jMG","expiry":1433030858},"DUqK_RA5dGLVq-cRY1Dnhg":{"token":"$2a$10$MA9SWeut0G1pBK6jwAfRTevwES/uh.tsh5gdQFof0b2sHuvcAKfu6","expiry":1433030870},"eY5gn1J
uHfle4bI8wOddyQ":{"token":"$2a$10$qshqJ2s2PdSdD2JstZtq.uBckvOLhOnqlwRdWXobXENMN.yS6bkjK","expiry":1433031039,"last_token":"$2a$10$INZb8EVrslHc/af4W6UoSuR83yKpcdmEqkEWb5CN04v96RGgupRXW","updated_at":"2015-05-17T08:10:39.643+08:00"}}"],
["updated_at", "2015-05-17 00:10:39.646659"], ["id", 1]]
Stil have so many tokens while sign in.
—
Reply to this email directly or view it on GitHub
https://github.com/lynndylanhurley/devise_token_auth/issues/210#issuecomment-102712896
.

The client_id is used so that users can authenticate with multiple browsers using different tokens. For example, you can maintain a session on your phone while still signed in on your laptop. This is not possible without the client_id attribute.

I'm aware of this behavior, but I think we need a way to handle this to avoid generating too many tokens who are not used.
Can we modify Devise trackable capability to update a key in the token ? With something like "last_used" and delete useless token ? Or maybe it's already implemented thanks to "expiry" ?

The tokens will be removed after they have expired, or updated if they are still in use. It looks like @qx has around 8 tokens - I don't think that's a cause for concern. And they will be removed once they expire.

It can be an issue when you don't want your token to expiry and you set
your expiration date to 9999.days.
I'm not in this situation, but 8 tokens seems to be big for a single user
on a single webapp.
On Mon, May 18, 2015 at 5:24 PM Lynn Dylan Hurley<EMAIL_ADDRESS>wrote:

The tokens will be removed after they have expired, or updated if they are
still in use. It looks like @qx https://github.com/qx has around 8
tokens - I don't think that's a cause for concern. And they will be removed
once they expire.
—
Reply to this email directly or view it on GitHub
https://github.com/lynndylanhurley/devise_token_auth/issues/210#issuecomment-103099833
.

Right, but if the expiration is set to 9999.days, then the tokens should persist for 9999 days. Removing them before that amount of time has passed would go against the configuration.
There should only be one token per connected device. If this is not the case, then there is something else going on with the client.
@npearson72 and @qx - I think this issue is related to lynndylanhurley/ng-token-auth#119. I'll push a fix tonight.

There's no way to identify a device uniquely. I can login 20 times on the
same device, i'll have the same amount of tokens.
On Mon 18 May 2015 at 20:55 Lynn Dylan Hurley<EMAIL_ADDRESS>wrote:

Right, but if the expiration is set to 9999.days, then the tokens should
persist for 9999 days. Removing them before that amount of time has passed
would go against the configuration.
There should only be one token per connected device. If this is not the
case, then there is something else going on with the client.
@npearson72 https://github.com/npearson72 and @qx
https://github.com/qx - I think this issue is related to
lynndylanhurley/ng-token-auth#119
https://github.com/lynndylanhurley/ng-token-auth/issues/119. I'll push
a fix tonight.
—
Reply to this email directly or view it on GitHub
https://github.com/lynndylanhurley/devise_token_auth/issues/210#issuecomment-103175331
.

There's no way to identify a device uniquely. I can login 20 times on the same device, i'll have the same amount of tokens.

The tokens should be destroyed after logout. Are you saying that is not the case?

Yes, is it the case. But on an iOS device you can ask your user to log in
again for several reason, and you'll generate many tokens.
IMO, this is not a problem, but it seems to be a problem for some people. I
just try to look around to make people happy ;)
On Mon 18 May 2015 at 23:35 Lynn Dylan Hurley<EMAIL_ADDRESS>wrote:

There's no way to identify a device uniquely. I can login 20 times on the
same device, i'll have the same amount of tokens.
The tokens should be destroyed after logout. Are you saying that is not
the case?
—
Reply to this email directly or view it on GitHub
https://github.com/lynndylanhurley/devise_token_auth/issues/210#issuecomment-103219520
.

@lynndylanhurley  Do you mean this setting"#config.token_lifespan = 2.weeks" in devise_token_auth.rb.
If the tokens will removed after 2.weeks, this problem will not be serious.

@qx - that is correct. Most users will only connect with 1 or 2 devices, and so they will only have a few tokens max.

Yes, is it the case. But on an iOS device you can ask your user to log in
again for several reason, and you'll generate many tokens.

@nicolas-besnard - could this be solved by re-using the same client_id when authenticating users that are already singed in?

This can be a solution, but the client_id must be saved on the device and you can't send a client_id when you log in, can you ?

If they're already signed in, I think the client_id header may already be appended to the authentication request. We would just need to check for it and re-use it if it's there, or delete the existing token from the tokens hash.

Could be useful, but if you open your API to external developer, they won't
think about sending the client_id. Doesn't seems to be a good fix IMO.
On Tue, May 19, 2015 at 5:52 PM Lynn Dylan Hurley<EMAIL_ADDRESS>wrote:

If they're already signed in, I think the client_id header may already be
appended to the authentication request. We would just need to check for it
and re-use it if it's there, or delete the existing token from the tokens
hash.
—
Reply to this email directly or view it on GitHub
https://github.com/lynndylanhurley/devise_token_auth/issues/210#issuecomment-103560564
.

Could be useful, but if you open your API to external developer, they won't
think about sending the client_id.

Can you elaborate on this please?

I found that I have 192 tokens.... not sure how this is happening. How does ng-token-auth detect a unique client?
A possibility is that I am building an ionic / cordova app. I'm wondering if it could be that everytime I create a new build, it's registering as a new client even though it's the same phone? (I guess it would view each build as a different browser?)
I have my token expiry time to be large (essentially infinite) since I don't want a mobile user to have to re-login (just as in the case of a native app).

I wonder...is there a way to customize expiry times depending on the type of client? e.g. if it's a mobile client, then I would have an infinite expiry time, but if it's a web client, then expire it after a finite time?

I think I know what's happening now. With a hybrid app (e.g. using Ionic / Cordova), you have a native app with a WebView inside. Every time you launch the app, it is registered as a new client since there is essentially a new browser instance that is loaded within the app.
Any ideas for workarounds? For example, would it be possible for me to save the clientID in some native storage and then use that clientID on initial app launch?

I was having the same problem in my rails based api which is using this gem. The api client was using the angular counterpart, and some of its requests (for some reason I don't know yet) were arriving with 'client' header not set. Everytime it happened a new auth token were created, just like @qx commented. After some requests, I was getting a database error saying that my tokens column had reached the size limit.
I think that if the the request 'client' header is empty or even unknown (this could be a client's mistake, for example) a new client token should be generated with client_id = request.headers['client'] || 'default', thus avoiding the creation of unecessary tokens.
I've already done this change in my fork. If you guys think that this makes sense for you, I would be glad to make a pull request.

@paulosoares86 - i'd definitely be interested if you or anyone else were able to isolate the client-side issue in ng-token-auth, but I agree that we shouldn't be able to DOS the service due to unnecessary token creation. I'd be interested in seeing that PR if you'd like to put it together.

@booleanbetrayal, can this issue be marked as closed because PR #434 ?

I think so, yes. Thanks @paulosoares86


Caliper fails after ordererer timeout: Cannot read property 'status' of undefined

Running caliper, the code that submits the transaction to the orderer received a timeout, which caliper did not handle correctly. Instead, it emits this:
2020.02.12-19:29:42.702^[[33m warn ^[[39m [caliper] [adapters/fabric]   Broadcast error from orderer.example.com: TIMEOUT
2020.02.12-19:29:42.703^[[31m error^[[39m [caliper] [adapters/fabric]   Transaction[8cd0fd3d7e] unexpected error: TypeError: Cannot read property 'status' of undefined
at Fabric._submitSingleTransaction (/path/node_modules/@hyperledger/caliper-fabric/lib/fabric.js:2016:35)
Context
The code from fabric.js is essentially this:
let broadcastResponse;
try {
    let responsePromise = new Promise(async (resolve, reject) => {
         let timeoutHandle = setTimeout(...);
    broadcastResponse = await responsePromise;
} catch (err) {
   // missing the ACK does not mean anything, the Tx could be already under ordering
    // so let the events decide the final status but log this error
    invokeStatus.set(`broadcast_error_${targetOrderer}`, err.message);
    logger.warn(`Broadcast error from ${targetOrderer}: ${err.message)');
}
if (broadcastResponse.status !== 'SUCCESS') {

When the timeout is thrown, the intent from the comments in the catch block is to continue and look for other events. But immediately after the catch block the code attempts to reference broadcastResponse, which was never set, resulting in a fatal error.
Expected Behavior
Benchmark execution should continue (treating the timeout as an error? Or at least processing the later events as the comment says, though I'm not convinced they are coming.)
Actual Behavior
undefined reference error
Existing issues
None found
Context
Test failed
Your Environment

Version used: caliper-cli 0.2.0, fabric 1.4.0, grpc 1.14.2
Environment name and version (e.g. Chrome 39, node.js 5.4): node 10.18.1
Operating System and version (desktop or mobile): OEL 7.7
Link to your project:

@scottoaks17 Nice catch! You're right, we must make sure that the broadcastResponse variable is set.
Would you submit a PR with the fix? :)
(As for the comment in the code, you're right again. Since we use up the entire timeout of the TX for the ordering ACK, it's safe to assume that the TX failed as far as the client is concerned. And benchmarking is all about the client-side perception of requests.)


Undefined method error on index

The console message instructing what to add to my class to index had bad syntax.
You can index this query by adding this to notificationeventemail.rb: index [:[:body, {:type=>:string}], :[:created_at, {:type=>:datetime}], :[:id, {:type=>:string}], :[:instant, {:type=>:boolean}], :[:notification_generator_id, {:type=>:integer}], :[:recipient, {:type=>:string}], :[:subject, {:type=>:string}], :[:updated_at, {:type=>:datetime}]]

I took a look at the docs, but now I'm getting a no method error for index.
RuntimeError: Error creating email notification: undefined method `index' for NotificationEventEmail:Class | ["/Users/whatever/.rvm/gems/ruby-2.0.0-p451@itglue/gems/dynamoid-1.1.0/lib/dynamoid/finders.rb:128:in `method_missing'

In my class I've just got:
index [:instant, :notification_generator_id, :recipient, :subject, :body]

Are you using the latest released version, or the master branch?  The advise on how to index is in fact incorrect.  You will probably need to setup secondary indexes if you want to query by non-primary keys.

In this particular case, I was querying by all attributes except id, created_at and updated_at to determine if there were duplicate records before saving. I should instead be using updateItem for that. It looks like that was left out. Any chance a new release will accommodate that?
I'll still need to be able to index attributes for a separate search log table feature. Let me know if I can help with anything. Dynamoid is enabling a fairly large and important feature which is launching soon, so thanks for your hard work!

@archonic It is unlikely that any support will be added for any features unless you add them yourself.  This project is built by people who are building the features they are using for narrow use cases.
I would recommend looking around the network view and see if anyone else has worked on updateItem.

I'll have a look around for updateItem and write it in if I don't see it.
Getting back to the topic, is there up to date documentation on the syntax of indexing (or secondary indexing), or is that unreleased?

I added support for secondary indexes in my fork.  Have a look at pboling/master.  I only understand it well enough to get it working, and based my work on the work of others already done.    Unfortunately I won't be of much help, but perhaps the secondary index implementation can serve as a template for what you want to accomplish.

@archonic secondary index support has been merged to master.
Also the persistence layer has def update!(conditions = {}, &block) which calls the adapter's def update_item(table_name, key, options = {}).  You might try using one of those?


ReportVersion1

Supirii
On Sat, 11 Sep 2021, 11:24 am AmdPathirana, @.***>
wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/dumidu1998/autoaid-front/pull/121
Commit Summary

update zindex
reportV1

File Changes

M src/components/Atoms/admin/AdminSideBarIcons.js
https://github.com/dumidu1998/autoaid-front/pull/121/files#diff-81ab6bb2ef5f90e93da9cbeebd917635596cb9aa216a8cd4cd954b92449e22ea
(6)
A src/components/Atoms/admin/ReportTopNavbarBtn.js
https://github.com/dumidu1998/autoaid-front/pull/121/files#diff-4013d3f8b6928f50ff3e396652cf012f122d43018a0ea6ee4058d6ac5b2633bf
(28)
M
src/components/Moleculars/admin/StaffManageIdStatusPropilePicRow.js
https://github.com/dumidu1998/autoaid-front/pull/121/files#diff-b2f7c1355b38081be36d72683bb7174915f7bf13a5232cc1999b3ce91fb5370d
(2)
A src/components/Organs/admin/ReportTopNavbar.js
https://github.com/dumidu1998/autoaid-front/pull/121/files#diff-b7ae04721fd17e521877814f1d5e8c730efbd8167acb27d18ae4ee91f761a8e8
(9)
M src/pages/admin/AdminReports.js
https://github.com/dumidu1998/autoaid-front/pull/121/files#diff-9226b94c0a4e7e479daa4781a686b215c2a060590c93f1c18217fc759cf69b97
(9)

Patch Links:

https://github.com/dumidu1998/autoaid-front/pull/121.patch
https://github.com/dumidu1998/autoaid-front/pull/121.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dumidu1998/autoaid-front/pull/121, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL6LVGIPDMH2LQ6RYCK7XZDUBLVJFANCNFSM5D2TJSSQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Adding the ListUsers API

Added the "ListUsersAsync"-method to "FirebaseAuth"-class (resolves #51  )

I believe this API should be based on Page and PagedEnumerable classes from Google GAX.
https://googleapis.github.io/google-cloud-dotnet/docs/guides/page-streaming.html

I believe this API should be based on Page and PagedEnumerable classes from Google GAX.
https://googleapis.github.io/google-cloud-dotnet/docs/guides/page-streaming.html

I changed the paging-implementation. The drawback is that the previous internal classes used for the JSON-response have to be public. ATM I let them in the internal-folder. If this (internal --> public) is okay ,I would clean this up.

Thanks @ChristopherLenz. The public API for this functionality should be something like this:
public PagedEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsers(string pageToken)
public PagedEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsers(string pageToken, CancellationToken cancellationToken)
public PagedEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsers(String pageToken, int maxResults)
public PagedEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsers(String pageToken, int maxResults, CancellationToken cancellationToken)

ExportedUserRecord and ExportedUserRecords should be new public types, and they should be the only types that get added to the public API surface.
It might also be easier to implement this by extending from the RestPagedEnumerable instead of writing our own from the scratch.
Then there's the question of asynchrony. All public APIs in the SDK are currently asynchronous. Ideally we should keep it that way. In that case it makes more sense to implement the APIs to return PagedAsyncEnumerable. But I'm not sure.

Thanks @ChristopherLenz. The public API for this functionality should be something like this:
public PagedEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsers(string pageToken)
public PagedEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsers(string pageToken, CancellationToken cancellationToken)
public PagedEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsers(String pageToken, int maxResults)
public PagedEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsers(String pageToken, int maxResults, CancellationToken cancellationToken)

I added the pageToken, but removed the maxResults and cancellationToken. These parameters are used in subsequent method-calls on the pagedEnumerable itself.
var usersPage = firebaseAuth.ListUsersAsync(string.Empty);
var userPage = await usersPage.ReadPageAsync(10, source.Token)

ExportedUserRecord and ExportedUserRecords should be new public types, and they should be the only types that get added to the public API surface.

It might also be easier to implement this by extending from the RestPagedEnumerable instead of writing our own from the scratch.

I did, but I'm not sure if the pageToken-handling is as expected. The requestProvider of RestPagedAsyncEnumerable is called for every request. This means that the pageToken is reset for every subsequent call on ReadPageAsync.

Then there's the question of asynchrony. All public APIs in the SDK are currently asynchronous. Ideally we should keep it that way. In that case it makes more sense to implement the APIs to return PagedAsyncEnumerable. But I'm not sure.

Yes I made everything async, because of the PagedEnumerable. I was not aware, that there is an async-version. Now it is async again.

Thanks @ChristopherLenz. At a glance this looks correct. We just need the ExportedUserRecord types, some tests and clean up. I will take another thorough look, once those changes are in.

Ok, having taken another look at other gcloud SDKs, I think our public API should be something like this:
public PagedAsyncEnumerable<ExportedUserRecords, ExportedUserRecord> ListUsersAsync(ListUsersOptions options)

class ListUsersOptions {
  public int? PageSize;
  public string PageToken;
}

For comparison with a similar API, see: https://googleapis.github.io/google-cloud-dotnet/docs/Google.Cloud.Storage.V1/api/Google.Cloud.Storage.V1.StorageClient.html#Google_Cloud_Storage_V1_StorageClient_ListBucketsAsync_System_String_Google_Cloud_Storage_V1_ListBucketsOptions_

Thanks for the tips @hiranya911. I've added all the requests you made. I don't know if I will find time to add some tests today.

@hiranya911 is there any work to do for me?

Hi @ChristopherLenz. This is still lacking tests for some of the functionality. Ideally we need to test that iterating over users via PagedAsyncEnumerator works as expected.

Hi @ChristopherLenz. This is still lacking tests for some of the functionality. Ideally we need to test that iterating over users via PagedAsyncEnumerator works as expected.

Okay I added a test for that. Please let me know if it is okay now.

@hiranya911
So I think that's all now :-)


How does one actually use c7n_mailer_replay?

I cannot seem to find actual information on how to run c7n_mailer_replay to test my templates.
Does anyone have an example command line they can share?

Have you looked at the help (--help or -h) output?


[Feature Request] New Attribute for Primary Key, allowing for Expansive UID Options

Currently, the user will use this.increment() to populate IDs of new entries and let vuex-orm manage insertion of ids into relationships.
class User extends Model {
  static fields () {
    return {
      id: this.increment(null),
      name: this.attr(null),
      posts: this.hasMany(Post, 'user_id')
    }
  }
}

class Post extends Model {
  static fields () {
    return {
      id: this.increment(null),
      user_id: this.attr(null),
      body: this.attr(null),
    }
  }
}

//insert
user: {
    name: "John",
    posts: [{ body: "John's post"}, { body: "Another post"}]
}

However, in some use cases - the end user may prefer a different strategy for generating their UIDs. Such cases may occur when using other endpoints than a SQL database or other special rules may apply.
Upon research into the source code - it appears that vuex-orm is tied to fields marked as Increment attribute type, when handling relationships.
I propose adding an attribute Primary, to be used as the attribute for this purpose. It's default behavior would be auto-increment. Custom strategies could then potentially be loaded as plugins, when registering an instance of the database, or dropped in on the models themselves.
//per model - requires code duplication
class User extends Model {
  static fields () {
    return {
      id: this.primary(myFancyUidGenerator()),
      name: this.attr(null),
      posts: this.hasMany(Post, 'user_id')
    }
  }
}

//universal setting - would centralize UID behavior
const database = new VuexORM.Database({
   primaryStrategy: myFancyUidGenerator
})

At the most minimal and maybe easy to implement, this.primary() default behavior being increment, or uses the resulting string / integer from the UID generator per model. Whenever an ID is manually supplied upon create or insert - it prefers the submitted ID.

@geraldbiggs Hi! Thank you so much for the feedback! Yeah, this is good idea and we should have this 👍

@geraldbiggs This is now possible with Vuex ORM 0.34.0! Please read the docs about new UID attribute 👍
https://vuex-orm.github.io/vuex-orm/guide/model/defining-models.html#uid-type


Webpack is slow to start and always performs work, even if it is unnecessary

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
If the --watch mode is not specified, Webpack always runs the function in the config file on the inputs, to produce the output.
If the current behavior is a bug, please provide the steps to reproduce.

Specify a Webpack function that transforms the inputs into an output, in a config file.
Make a change to one of the input files and save it.
Invoke webpack with webpack --config /path/to/config.json, to write the output file as a function of the inputs.
Immediately run webpack again with the same commands.

What is the expected behavior?
The second time webpack is invoked, I expect it to detect that the mtimes of the inputs are all older than the mtimes of the output file, print that there is no work to be done, and exit with a 0 return code.
If this is a feature request, what is motivation or use case for changing the behavior?
Make is a build automation tool released for UNIX systems in April 1976, 41 years ago. If I define a Make target as follows:
output.js: static/one.js static/two.js

and invoke it with:
make output.js

Make will check the mtimes of static/one.js, static/two.js, and output.js (which you can check by using the Lstat syscall on the affected files). If the mtime for output.js is newer than its inputs, make outputs the following:
make: Nothing to be done for `output.js'.

And exits with a 0 return code. This means it is faster - make does not do unnecessary work - and more composable. It is always easy to invoke make output.js as part of another build script, since make will exit early if there is no work to be done.
By contrast, webpack does all of the work every single time. This makes it more difficult to compose as part of a larger build process, since invoking webpack means the work is always performed even if there is no point in doing the work since the inputs haven't changed since the output file was written.
In addition to doing unnecessary work, webpack has a slower startup time than make. Here is the amount of time it takes make to print the version string:
$ time make -v
GNU Make 4.2.1
Built for x86_64-apple-darwin16.6.0
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
make -v  0.00s user 0.00s system 32% cpu 0.026 total

Or 26 milliseconds. It takes webpack, released 36 years later, about 8 times as long to print the version string:
$ time webpack -v
2.6.1
webpack -v  0.17s user 0.04s system 84% cpu 0.242 tota

This is a significant performance regression, both in startup time and in the amount of work that is performed. It's especially confusing given the modest improvements in CPU performance, and the increases in available RAM, in the years between 1976 and 2012.
It would be nice if performance improved along one or both of these axes.

Why not add this as a flag in a PR?

This is although a little jabby 😂, still an excellent analysis.   Given this is the case, would you considering looking more in-depth at GitHub.com/webpack/watchpack which contains the underlying watching functionality to see if are easy wins. It leverages chokidar behind the scenes.

But then again we consciously purge the inputFileSystem cache for non watching builds. Something to consider: if you are using unique hashing and constantly writing this to in memory fs cache, your cache will continue to grow. Make although a shining example of a primitive fast task runner does maybe 1/100 of the operational logic that webpack is performing. Cases we might need to be aware of that would need to invalidate cache:

almost any change to the configuration could allow for discovery of new entries files etc, we could no use the lstat or mtimes of previous build in this case.
hashing of any kind (unless maybe permissable from the user) would cause our mem fs cache to continue to grow
loader caching: the operation of one instance of a loader is likely comparable to a task in make is performing, with this in mind, we have already created a loader that will help users cache expensive loader operations.

I'm sure the list goes on. Regardless we are always looking for individuals to help performance tune all of the facets of our ecosystem so if you are interested in doing a more comparable, and far less hyperbolic analysis, then we are more than willing to lend a helping hand guiding you through the architecture

Make has its dependency graph defined in the makefile itself, which is what allows it to reason about work needing to be done. Webpack does not have this. It has entry points and must walk the dependency graph to it's full extent before it can start reasoning about the current state and compare to the previous one. These are radically different approaches, which will always have webpack come out slower. But I invite you to roll out your dependency graph into a flat make file yourself and see if you come up with a faster, useful and maintainable tool kit. Having worked for years in similar tooling I doubt the results will compete with make.
As for comparing start up time of a native binary with a script that depends on an entire node runtime to boot up, this feels out of scope for webpack specifically. You might want to open that part of the issue in the node project

Please use https://webpack.js.org/configuration/other-options/#cachetype with the filesystem type


ci: Add initial makefile and hack scripts to perform basic checks

Add initial makefile and initial script to perform basic checks.
For now only the boilerplate is enable and the prow job created in this PR: https://github.com/kubernetes/test-infra/pull/21179
/assign @vladimirvivien

/assign @vladimirvivien @spiffxp


Stats by Filter - Incorrect Sort

Describe the bug
The table showing total hours and count by filter has a sort feature, but the sorting is alphabetical instead of numerical based:
To Reproduce
Steps to reproduce the behavior:

Load a library containing data with more than one filter
Search your library to produce a result set containing at least two unique filters
Look at the Stats by Fitler table on the right
Hit the column header "Total (hr)" or "Count" and notice the sorting occurs alphabetically instead of based on the numerical sum of hours or count.

Expected behavior
The sort should show the results with the most total integration time above the ones with less integration time when sorting by Total (hr)
The sort should show the results with the most number of files above the ones with fewer number of files when sorting by Count.
Screenshots

Desktop (please complete the following information):

OS: Windows 2022
Version 1.2.1

Additional context
na

Ah, the classic sorting bug. Thanks for finding this. I'll get this fixed for the next release.


Autodect column lengths if possible

If it is possible the module should try to determine column widths and use the auto-determined widths.  This would work for files that always have some sort of character pad between fields.

I will try to push a PR with this functionality soon.

Looked good!  Haven't been on github much lately work has been hectic.


[RESOLVED] High ICMP ping response time

Problem started at 02:09:14 on 2023.07.31
Problem name: High ICMP ping response time
Host: MF-FG
Severity: Warning
Operational data: Value: 107ms
Original problem ID: 34447
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23132&eventid=34447

Problem has been resolved in 2m 0s at 02:11:14 on 2023.07.31
Problem name: High ICMP ping response time
Host: MF-FG
Severity: Warning
Original problem ID: 34447


Bug: function get_table_rows_by_seckey call wrong function convert_to_type

https://github.com/EOSIO/eos/blob/master/plugins/chain_plugin/include/eosio/chain_plugin/chain_plugin.hpp#L452
SecKeyType lv = convert_to_type( s.to_string(), "lower_bound name" );
The above function convert_to_type which being called is https://github.com/EOSIO/eos/blob/master/plugins/chain_plugin/chain_plugin.cpp#L1648
It first convert string to number, if fails then convert string to name and convert name to unit64_t.
This make function get_table_rows_by_seckey works abnormally(return null result) when lowerbound or upperbound string is all numbers. In fact string should be convert to name first, and get uint64_t value.

Proposed solution is adding a trailing "_n" to differentiate digits from all-digits name. It is not ideal as areg pointed out, and will work as a temporary solution before cleos implements a mechanism to enforce the parameter types before reaching backend.
The solution should have no impact on existing code, since digits still can be converted properly, but provides a leeway to allow all-digits name can be processed properly as a name.

@gzliudan  could you please provide a user scenario for this issue also? thanks a lot!

Look for alternative of using DB index type for conversion now instead of appending trailing "_n"

@gzliudan could you please provide a user scenario for this issue also? thanks a lot!

for example: there is a multi_index table which name is mytable, the define is
struct mytable {
    uint64_t pkey;
    name account;
    int  age;
    uint64_t primary_key() const { return pkey; }
    uint64_t get_account() const { return account.value; }
};

And this table has a record: pkey=(any value), account=“12345”_n，when I want to get all fields of this record by account field, I run below command:
cleos get table {MY-CODE} {MY-SCOPE} mytable --index 2 --key-type name -L 12345 -U 12345
or
curl http://<IP_ADDRESS>:8888/v1/chain/get_table_rows -X POST -d '{"json":true,"code":"MY-CODE","scope":"MY-SCOPE","table":"mytable","lower_bound":"12345","upper_bound":"12345","index_position":"sec","key_type":"name","limit":10,"reverse":false,"show_payer":false}'
then command returns no data, but mytable has a record  in fact .

only eosio.cdt support "12345"_n; eos does not support "12345"_n, only support N(12345) .
I suggest create a new function use other name instead of  convert_to_type. Below version should be right:
https://github.com/EOSIO/eos/blob/master/plugins/chain_plugin/include/eosio/chain_plugin/chain_plugin.hpp#L58

Proposed solution is adding a trailing "_n" to differentiate all-digits name from digits.
The solution should have no impact on existing code, since digits still can be converted properly, but provides a leeway to allow all-digits name can be processed properly as a name.
Example:
"1234" --> integer 1234
"1234_n" --> name "1234"
Note:
This rule only applies to all digits with following '_n".
For example:
"abc_n", "a12_n", "12.34_n", trailing "_n" won't be removed, and will cause conversion failing

@gzliudan appreciate for the detailed explanation,

@gzliudan
I have not work on this issue due to another higher priority one.
Modified get_table_tests.cpp, to query all digits "newname", seems working as expected when setting lower_bound and upper_bound as all digits.
How to replicate:

branch : develop
add this line " bidname(N(inita), N(111), eosio::chain::asset::from_string("1.0000 SYS"));"  at get_table_tests.cpp:363
add those two lines at get_table_tests.cpp:373
p.lower_bound = "111";
p.upper_bound = "111";
p.index_position = "primary";
p.key_type = "name";
recompile, you will see only one record being fetched.

Maybe, I missed something after not working on it for a while. Let me know what you think

I believe it‘s a small and low priority bug. It's not important, because I can change key-type not use name to avoid riggering this problem. You can invest this issue at any time later.
BTW: where can I find this year's road map of EOS?

a workaround is to add a space before the string, for example " 1111" instead of "1111"

How about eos v2.1.0 ?

Fixed in 2.1 release


[AMBARI-25030] Improve component-host association syntax in Add Service request

What changes were proposed in this pull request?
Change syntax of the Add Service request:

allow multiple hosts per component
simplify component_name to name to be more consistent with blueprints

https://issues.apache.org/jira/browse/AMBARI-25030
How was this patch tested?
Unit tests are updated.  Tested manually using new syntax:
$ curl -X POST -d @- "http://${AMBARI_SERVER_NAME}:8080/api/v1/clusters/TEST/services" <<-EOF
{
  "operation_type": "ADD_SERVICE",
  "components": [
    { "name": "KAFKA_BROKER",
      "hosts": [
        { "fqdn": "c7401.ambari.apache.org" },
        { "fqdn": "c7402.ambari.apache.org" }
      ]
    },
    { "name": "INFRA_SOLR",
      "hosts": [
        { "fqdn": "c7402.ambari.apache.org" }
      ]
    },
    { "name": "INFRA_SOLR_CLIENT",
      "hosts": [
        { "fqdn": "c7401.ambari.apache.org" },
        { "fqdn": "c7402.ambari.apache.org" }
      ]
    }
  ],
  ...
}
EOF

HTTP/1.1 202 Accepted
{
  "Requests" : {
    "id" : 7,
    "status" : "Accepted"
  }
}

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4726/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4731/
Test PASSed.


Clean routine

fixes: https://github.com/Azure/azure-sdk-for-cpp/issues/504
This PR:

Separates CurlSession from CurlConnectionPool and CurlConnection.
Introduces a clean thread function which gets started as soon as a connection is moved to the connection pool.

it runs every 5 minutes and remove any connection expired (on connection pool for more than 1 min)
if the clean thread removes all connections, it stop the cleaning until the next time a connection is moved to the connection pool again. This way it is not just running forever when it is not needed.

@vhvb1989 can you merge this PR ASAP? we're going to release on Aug 27 (Shanghai local time).


Old version of requests library compared to ibind

Describe the bug
I've setup CI/CD pipeline but it fails to run tests as pip isn't able to install requests library. here is error:
The conflict is caused by:     The user requested requests<2.32.0 and >=2.30.0     ibeam 0.5.4 depends on requests==2.30.*     ibind 0.1.4 depends on requests==2.31.*
To Reproduce
put those two lines in requirements.txt file and instal with pip
ibeam==0.5.4
ibind==0.1.4
Suggest a Fix
Upgrade ibeam requests library dependency version to 2.31.0

Thanks for reporting @b3kan I'm currently travelling but I'll have this fixed ASAP 👍

Hey @b3kan I'm sorry this took me embarrassingly long to reply to. I've fixed the issue in the meantime in one of the releases but since it was reported in another issue (https://github.com/Voyz/ibind/issues/16) I forgot to update you here. Thanks for reporting 👍


apply() with variadic metamodels

The documentation of Applicable.apply() says:

This has the same behaviour as invoking the applicable directly, but exchanges compile-time type
safety with runtime checks.

But given
shared void star1(String* s1) {}

I can do
`star1`();

but if I try
`star1`.apply();

I get InvocationException ("Not enough arguments to function. Expected 1 but got only 0").
Same is true of Class and Constructor models.

Fixed by #607.


DF Chat Enhancements: option to disable chat message color outline

Is your feature request related to a problem? Please describe.
I would like to have the ability to completely disable the color outline in the messages with color matching player's color. The visuals are bad with such color exists and cannot be disabled.
Describe the solution you'd like
I would like to have the ability to completely disable the color outline in the messages with color matching player's color.
Describe alternatives you've considered (Optional)
Disable the module.
Additional context (Optional)
n/a

This is probably not something I will be adding. The easiest way to do this is to change the Player Chat Colour to the same colour for each player. This will effectively disable player colours in the chat as they will all look the same.

I decided to reverse my decision on this. I saw an easy way to do it with my existing code, so I added it in as an option in Module Settings.


add init kv service implementation

@xiang90 @skyao @sijie I add some init kv services implementaion ptal.

Also some thought on multi endpoints load balancing: Currently grpc use DummyLoadBalancerFactory as the default load balancer factory, the DummyLoadBalancer will always pick-first. Basically we need to implement custom NameResolver and LoadBalancer if we want to support multi endpoints.

Seems there are some conflicts in class EtcdClientBuilder.


Update templatefolder.md

Correction, because of wrongly mentioned limitation on Windows 2000 - read https://docs.microsoft.com/en-us/windows/win32/msi/installation-context as reference.

@FlorianHaupt : Thanks for your contribution! The author(s) have been notified to review your proposed change.


the sample code in fresh 1.2 release blog will not work

The sample code below at https://deno.com/blog/fresh-1.2 will not work.
// routes/index.tsx
export function Page() {
  const cart = useSignal<string[]>([]);
  return (

Lemon

A very fresh fruit.

        <AddToCart cart={cart} id="lemon" />

  );
}

// islands/Header.tsx
export default function Header(props: { cart: Signal<string[]> }) {
  return (

      Fruit Store
      <button>Open cart ({props.cart.value.length})</button>

  );
}

// islands/AddToCart.tsx
export default AddToCart(props: { cart: Signal<string[]>, id: string }) {
  function add() {
    props.cart.value = [...props.cart.value, id];
  }
  return <button onClick={add}>Add to cart</button>
}

At least,
export default AddToCart(props: { cart: Signal<string[]>, id: string }) {

should accompany function:
export default function AddToCart(props: { cart: Signal<string[]>, id: string }) {

After adding it, the code still not work in my environment.
When I press "Add to cart" button, the browser console says "Uncaught TypeError: props.cart.value is not iterable".
It looks like const cart = useSignal<string[]>([]) is not correctly passed to the AddToCart island, which is initialized on the server, and then (expected to be) passed to the client.
I wrote the following code, which is successful.
// routes/cart.tsx
import Cart from "~/islands/Cart/cart.tsx";

export default function Page(props: PageProps) {
  return (

      <Cart />

  );
}

// islands/Cart/cart.tsx
import { useSignal } from "@preact/signals";
import AddToCart from "~/islands/Cart/add.tsx";
import Header from "~/islands/Cart/header.tsx";

export default function Cart() {
  const cart = useSignal<string[]>([]);

  return (

Lemon

A very fresh fruit.

        <AddToCart cart={cart} id="lemon" />

  );
}

// islands/Cart/header.tsx
import { Signal } from "@preact/signals";

export default function Header(props: { cart: Signal<string[]> }) {
  return (

      Fruit Store
      <button>Open cart ({props.cart.value.length})</button>

  );
}

// islands/Cart/add.tsx
import { Signal } from "@preact/signals";

export default function AddToCart(props: { cart: Signal<string[]>, id: string }) {
  function add() {
    props.cart.value = [...props.cart.value, props.id];
  }
  return (<button onClick={add}>Add to cart</button>)
}

The above code works as I expect. Pressing the "Add to cart" button refreshes the "Open cart (0)" to "(1)".
I assume that I miss something that needs to be done for the original code to run as expected, or, the original code is only intended within a large island (as in my sample code).
Question: What is the expected behavior of useSignal within routes, then passed to an island?

I'm having the same issue, creating a signal in a route makes the behavior different between server and client side rendering. This is my signal in index.tsx:
export default function Page() {
  const isDark = useSignal(true);

  return (
    <>
      <form action="/connect" class="m-4 flex items-center">
        <DarkMode isDark={isDark} />
      </form>
    </>
  );
}

And my island DarkMode.tsx
export default function DarkMode({ isDark }: Props) {
  console.log(isDark);

Server prints:

But client:

So isDark is no longer a signal in the client, so trying to set the "signal" will fail with:

@tanquar Thanks for sharing this issue. That's indeed an error in the code snippet in the release blog post. Made a PR to address this and it will probably land later today. Thanks again for bringing this up!
@sant123 I can't reproduce the behaviour you're describing. When I try out the provided code snippet the client logs the signal object instead of the unwrapped boolean value for me. Do the snippets contain the exact code you used to see that behaviour?

The code snippet in the blog post is fixed 🎉

Thank you!
I'm looking at the actual blog post at https://deno.com/blog/fresh-1.2 and I tested with a blank fresh 1.2 project, which was successful. Server side const cart = useSignal<string[]>([]) in "routes" is passed to the client side islands.
The same cart sample code still didn't work in my existing project, upgraded from fresh 1.1 to 1.2.
I figured out the different version with signals-core in import_map:
@preact/signals-core": "https://esm.sh/*<EMAIL_ADDRESS>// fresh 1.2
@preact/signals-core": "https://esm.sh/*<EMAIL_ADDRESS>// my existing project

I used "1.3.0" which looks like the latest, and the current fresh deno run -A -r https://fresh.deno.dev uses "1.2.3". After I downgraded to<EMAIL_ADDRESS>the cart code worked in my existing project successfully.

Thank you! I'm looking at the actual blog post at https://deno.com/blog/fresh-1.2 and I tested with a blank fresh 1.2 project, which was successful. Server side const cart = useSignal<string[]>([]) in "routes" is passed to the client side islands.
The same cart sample code still didn't work in my existing project, upgraded from fresh 1.1 to 1.2. I figured out the different version with signals-core in import_map:
@preact/signals-core": "https://esm.sh/*<EMAIL_ADDRESS>// fresh 1.2
@preact/signals-core": "https://esm.sh/*<EMAIL_ADDRESS>// my existing project

I used "1.3.0" which looks like the latest, and the current fresh deno run -A -r https://fresh.deno.dev uses "1.2.3". After I downgraded to<EMAIL_ADDRESS>the cart code worked in my existing project successfully.

I’m using the 1.3.0 as well 👀

Uh ok that sounds suspicious. Re-opening the issue, because something seems to be going on with the different signal versions. Will look into that tomorrow

I think I found the root cause. To serialize props we're relying on JSON.stringify with a custom replacer function. In @preact/signals-core 1.3.0 we added a toJSON method for folks who want to serialize signals to json for data exchange purposes. This breaks our use case though because that returns the signal's value so our serializer is blind to it having been a signal. Reason for that is that JSON.stringify calls an objects .toJSON method if present.

Happy to help!


MINOR: move setReadOnly to Headers.

Promote the setReadOnly function to Headers instead of only in RecordHeaders.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Hi team,
PTAL, thanks!


Provide types for @dahlia/styles

Provide types for @dahlia/styles so that the tailwind.config.js file in that workspace can be imported by Typescript-using consumers.

After further discussion, we've decided to leave tailwind config in JS until someone else does the typescript work for us. The current situation doesn't seem to bee problematic other than linting.


East/west connectivity monitoring tool

Description
Antrea only monitors Controller/Agent status at the moment, and Controller/Agent's status doesn’t means East-West connectivity is good, and metrics provieded by Antrea also does not reflect to Pod to Pod connectivity.
From an application perspective, we need a tool that can detect and inform Pod-to-pod connectivity issues.
Core feature required
A tool (maybe a Daemonset) that can generate East/West traffic periodically and check whether the E/W connectivity is good. if some of the detection fails, alerts or logs should be send out to external monitoring tools.
The detection interval should be adjustable like traditional loadbalancer do, for example send detection every 1 second and when 3 consecutive detection fails, sends out an alert.
Other related features
Since we're doing a E/W monitoring tool, so other related Antrea features can be monitored too. For example:

Pod to service type ClusterIP
Pod to service type Nodeport
Pod to external network via SNAT

@zm1990s Thanks for the proposal.
Monitoring EW connectivity should be feasible. But having extra long running Pods, especially DaemonSet deployed in user's cluster for this purpose may not be wanted by most users. We can probably leverage the state of memberlist ran by antrea-agent as the source of connectvitiy status. Regarding to alerts, K8s events associated with the unreachable Node may be a way. However, we need to ensure no duplicate events would flood the event system. Using consistent hash to select one "reporter" node among available nodes may be feasible.
Regarding Pod-to-Service, Pod-to-External monitoring, I'm not sure if it could be really helpful and practicable to proactively generating traffic. It's not easy to even know whether a particular access is supposed to succeed or not given different policy, firewall, network topology configuration, not to mention the generated traffic on behalf of user's application or towards user's application may be not wanted by many users. I think in practice most such tools are implemented as script/playbook executed out-band using user's own application according what they want to monitor.
cc @jianjuns @antoninbas @salv-orlando

However, it seems monitoring EW connectivity via memberlist would just be a faster way to get the notification of Node unreachable event compared with the K8s's native Node status. If user just wants such status is reported faster, they can also just update node-monitor-grace-period, so still wondering what value this can really add.

However, it seems monitoring EW connectivity via memberlist would just be a faster way to get the notification of Node unreachable event compared with the K8s's native Node status.

I think that from an Antrea perspective, it would be good to monitor the health of the overlay network (in encap mode) by running some ping-mesh across all gateways. Being able to report latency across Nodes would also be quite nice, but I don't think we can do that with memberlist (IIRC, we discussed that in the past). With latency data available, we could even display a heat map in Antrea UI and update it in real-time.

Agree with what @antoninbas said.

If without the need of latency data, I think the health of the overlay network shares the health status of memberlist in practice. Unless a misconfiguration that the memberlist port is whitelisted but not the overlay port, which could only occur when deploying a cluster and not during the routine running, I don't think of a situation that memberlist reports a Node is health but its overlay doesn't work. But if we want to add latency data, I agree memberlist may not achieve it (However, I don't quite rememember we discussed this, could you share a link if there is one?).

If without the need of latency data, I think the health of the overlay network shares the health status of memberlist in practice. Unless a misconfiguration that the memberlist port is whitelisted but not the overlay port, which could only occur when deploying a cluster and not during the routine running, I don't think of a situation that memberlist reports a Node is health but its overlay doesn't work.

I think overlay (ping between gateway) is a bit more "end-to-end". In addition to port whitelisting, we could potentially detect issues like a missing route on the host (granted, that has not happened in a while, but we used to have such issues). I was thinking that with the right "probe" (e.g. a TCP data exchange), the health check would also fail in case of checksum issue (basically any issue with the NIC configuration that is specific to double encapsulation).

But if we want to add latency data, I agree memberlist may not achieve it (However, I don't quite rememember we discussed this, could you share a link if there is one?).

The latency heat map is something that has been on my mind for a while. I remember someone telling me that Weave had something like this, but I can't find a reference to it.
I brought this up very superficially when we added memberlist as a dependency: https://github.com/antrea-io/antrea/issues/2128#issuecomment-827257525

@tnqn I think this tool should be decoupled from Antrea Controller/Agent, just like nsx-interworking. Users can decide whether they need to use it or not.

Assigning to @tushartathgur who said he would look into this.
cc @yuntanghsu as well.

We have submitted this issue as a project idea for the LFX mentorship program: https://github.com/cncf/mentoring/pull/1129. So no-one should ideally work on this issue until we know if the proposal is accepted and if we can match a mentee to work on it.
See https://docs.linuxfoundation.org/lfx/mentorship for more information on the program.

@antoninbas, I am greatly interested in the project, how do I reach you guys in slack or are there other options? Though I have an intermediate knowledge of k8s and golang, I am curious to know how much frontend approach has to be driven here. Thank you.

@prakrit55 you can reach out to us on Slack (we have the #antrea channel in the K8s slack)
but for this specific issue, please see comment above (https://github.com/antrea-io/antrea/issues/5514#issuecomment-1906707462). If you are interested, you could consider applying for the LFX mentorship program.

@prakrit55 you can reach out to us on Slack (we have the #antrea channel in the K8s slack)
but for this specific issue, please see comment above (#5514 (comment)). If you are interested, you could consider applying for the LFX mentorship program.

Hey thank you @antoninbas, I got your channel. I would really love to apply for lfx mentorship for the term March-May.

@antoninbas The prospect of working collectively on a comprehensive project like this is truly exciting, and I am keen on contributing my skills and enthusiasm to its success. The outlined sub-projects align perfectly with my interests, and they present a great opportunity for learning growth, and industrial exposure.
I look forward to contributing to the project and learning from the experience.

@antoninbas @heanlan
Hi, as far as I understand, this project requires a good understanding of Computer networking and Kubernetes, right?
I have a few questions,

What are the exact requirements for this project, like what topics and what tools are required?
What are your expectations from a mentee, like solving some pre-tasks, or making contributions before mentorship [ This will be my last attempt to fellowship. That's why I am asking so that I can choose the right project and save time also ]
What type of cover letter do you want, like a normal CV or a detailed proposal mentioning the approach and timeline to follow?
Thanks, waiting for a response

Hello, everyone. I'm pleased to see how many folks are interested in participating in the LFX Mentorship Program.
Upstream issues like this are an excellent place to discuss specific technical topics or provide ideas about how you may tackle a problem; however, please post any questions about the LFX program and how to apply on the mentorship discussion forums (and indeed, some of these questions may have already been answered there, or on the Program Guidelines page).

For all the folks who have applied or are considering applying to one of the Antrea projects for the LFX mentorship program, we have published instructions to complete test tasks: https://github.com/antrea-io/antrea/discussions/5976. We will review your submissions for these tasks alongside other material (resume, cover letter) when selecting mentees. The deadline for submitting is February 20th 5PM PST.

@IRONICBo will work on this as part of the LFX mentorship program

Monitoring tool api design proposal
Monitoring tool needs a uniform config
Users and administrators need a way to measure and monitor network performance, specifically the latency between nodes, to ensure optimal cluster performance and troubleshoot potential issues.
Watch a singleton CRD
The proposed solution is to introduce a new Custom Resource Definition (CRD) called PingMonitoringToolConfig in Antrea. This CRD will allow users to enable and configure a ping monitoring tool that measures the latency between nodes. The configuration will include parameters such as the ping interval, timeout, and concurrency limit.
The Antrea agents will listen for changes to this CRD and adjust their monitoring behavior accordingly. When we enable Enable for monitor in Feature gate and config, agent will watch the events of creation/update/deletion of this CRD and update the start, stop and parameter update of monitor tool in real time.
Additionally, a singleton pattern will be enforced using a validation webhook to ensure that only one instance of the CRD exists in the cluster.
Use Feature Gate & Config & CRD to start monitoring tool
The solution introduces a new user-facing feature that allows users to enable and configure the ping monitoring tool via a YAML config file. Users can apply this YAML file using kubectl to create or update the PingMonitoringToolConfig resource.
The changes will be automatically picked up by the Antrea agents, and the monitoring behavior will be updated accordingly. This feature provides users with a structured and easy-to-consume API for enabling and configuring the ping mesh feature.
Main design/architecture
The main design involves the following components:

CRD Definition: A new CRD PingMonitoringToolConfig will be defined with fields for enabling the tool, ping interval, timeout, and concurrency limit.
Here is an example of the CRD definition in Go:

    type PingMonitoringToolConfigSpec struct {
        Enable              bool   `json:"enable,omitempty"`
        PingInterval        string `json:"pingInterval,omitempty"`
        PingTimeout         string `json:"pingTimeout,omitempty"`
        PingConcurrentLimit int    `json:"pingConcurrentLimit,omitempty"`
    }

    type PingMonitoringToolConfig struct {
        metav1.TypeMeta   `json:",inline"`
        metav1.ObjectMeta `json:"metadata,omitempty"`

        Spec PingMonitoringToolConfigSpec `json:"spec,omitempty"`
    }

Singleton Pattern Enforcement: A validation webhook will be implemented to ensure that only one instance of the PingMonitoringToolConfig resource can exist in the cluster. This webhook will reject the creation of additional instances if one already exists.

Agent Behavior: Antrea agents will listen for changes to the PingMonitoringToolConfig resource and update their monitoring behavior based on the configuration. The agents will use a Kubernetes client to watch for changes to the resource and adjust their ping interval, timeout, and concurrency limit accordingly.

Monitoring Logic: The ping monitoring tool will measure the latency between nodes and provide metrics that can be used for monitoring and troubleshooting. The tool will use ICMP ping requests to measure the latency between nodes. Here is an example of a YAML configuration file for the PingMonitoringToolConfig resource:

apiVersion: networking.antrea.io/v1alpha1
kind: PingMonitoringToolConfig
metadata:
  name: default
spec:
  pingInterval: "10s"
  pingTimeout: "5s"
  pingConcurrentLimit: 10

In this example, the ping monitoring tool is enabled with a ping interval of 10 seconds, a ping timeout of 5 seconds, and a concurrency limit of 10.
Alternative solutions

Using a ConfigMap: Instead of a CRD, a ConfigMap could be used to configure the ping monitoring tool. However, this approach lacks the structure and validation capabilities provided by CRDs.

Using antctl API Server:  We need to register an apiServer and use antctl to update the parameters of our monitoring tool. We need to consider the uniformity and observability of the configuration parameters in the cluster.

This proposal aims to provide a flexible and user-friendly way to monitor node-to-node latency in a Kubernetes cluster, enhancing the observability and manageability of the network performance in Antrea-managed clusters.

A validation webhook won't be necessary if we simply add an open-api validation rule which constraints the name of the CRD object created. See https://github.com/kubernetes-sigs/network-policy-api/blob/main/apis/v1alpha1/baselineadminnetworkpolicy_types.go#L29 as an example

With the addition of the NodeLatencyMonitor feature in Antrea v2.1 (thanks @IRONICBo!), I will now close this issue. Additional capabilities for this feature can be added over time. An issue has been created for the addition of a latency visualization dashboard in the Antrea UI: https://github.com/antrea-io/antrea-ui/issues/455


Updating the contributing.md for the project

I would like to work on it!

I would like to work on it!

Okay, just add a pr when your are done, I'll check it and then merge, if everything will be alright

ok!

@the-amazing-atharva congratulations...
you have completed the issue on time, it was an easy issue, you will get the points accordingly.

@the-amazing-atharva  I'm sorry, as the contribution period is not yet started, you are not required to do anything of now, add the pr after contribution period will start

i would like to work on this issue under JWOC, please assign this to me

i want to contribute


Typing of Query<> should include query.options.enabled

Describe the bug
Context
I'm trying to do query invalidation based using predicates. For the particular use case, I would like to know if the query is enabled, since the typing of the  queryKey may vary with it.
By using console log, I know that the queries in the query cache can have the query.options.enabled property, which I would like to use. Using query.isDisabled() is not equivalent, since it can return false even queries with enabled: false.
Issue
const queryClient = useQueryClient()
queryClient.invalidateQueries({
  predicate: (query) => {
    // query.options.enabled is not included in typing, but it is part of the object if we console log.
    return false
   },
})

Your minimal, reproducible example
https://stackblitz.com/edit/react-ts-dc5yox?file=App.tsx
Steps to reproduce

Create a query, and call it using {enabled: false}
Call the query client, and try doing query invalidation using predicate:
console.log the queries, you will see that the one that has enabled: false will appear as having it on:

{
...
options: {
  ...
  enabled: false
  }
}

Even though this happens, the typescript type says the {enabled? : boolean} property is not on the options object.

Expected behavior
I expected to have
query.options: typeof query.options & {enabled? : boolean}

as the type of the query options
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform

Linux - Ubuntu
Firefox and Chrome

TanStack Query version
4.20.4
TypeScript version
4.9.3
Additional context
No response

options.enabled being present at runtime is likely a side-effect of us applying all options that come from useQuery to the query via object spread. It's not something that you can or should rely on.
useQuery accepts some options that are part of the query, and some for the queryObserver that is created. enabled is an observer level property, which means you can call useQuery with the same key twice in two components, both being differently enabled. The value you can see here at runtime (and in the devtools) is likely the one that got last applied.
Still, the typings are correct and you shouldn't rely on that value being present.

For the particular use case, I would like to know if the query is enabled, since the typing of the queryKey may vary with it.

Strictly speaking, a query itself cannot be enabled or disabled - it can just "be". Observers can be disabled if they shouldn't trigger requests by themselves, that's all.
Can you elaborate on your use-case? Why would tpyings be different for enabled or disabled observers?

My use case is the following:
I have a query that depends on the data of another one. I use the enabled: !!data option to delay the execution until the last one starts, and I perform a non null assertion to avoid having to type my method as possibly undefined.
I know that the recommended solution is this one: https://github.com/TanStack/query/discussions/2281#discussioncomment-745345
I just did not like it for this for two reasons:

Semantically it didn't make much sense for the function to take an undefined parameter, it was just a matter of waiting until the other query finishes
Adding undefined to the input, means the return type has to change as well, and this means that data could be undefined even if the query is a success, and I did not like that.

The only issue I had when doing things in this 'wrong way' was this. Trying to invalidate queries, I relied in the typing that was not always true, as it could be undefined when the query is not enabled.
That's the reason I would like to know if it the "query is enabled" or not.

query invalidation never targets disabled queries - there is an explicit check that filters out queries where all observers are disabled from the refetching logic:
https://github.com/TanStack/query/blob/1c43f580c6f6e7ad8cdf70921a9b62ee95daa278/packages/query-core/src/queryClient.ts#L266-L269

The issue with this is that query.isDisabled() returns false for the query I mention. I find it weird, since the the query has enabled: false and will never be enabled with that input.
Could there be some bug there? What could make it work like that?
I'm using trpc as well as react-query, if that changes something, but in this particular case i don't think so


Daemonization

Should we daemonize this process or should it run in real time?
Is there a way to create alerts on a Mac, etc?

One potential method would be to create a "user agent" for Mac, Windows, and Linux via the services method described in this post: Running Go Programs as a Background Process


feat: webscroll

:tada: This PR is included in version 0.300.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Cleanup

Here are some modifications to try and make the structure more clean and easier to understand for future work. This PR should also reconsider how and what information is being displayed, and will resolve https://github.com/CCI-MOC/esi/issues/572

@tzumainn @ajamias I pushed the following changes as per the doc:

added owned nodes to the node table.
added a “Lease Duration” column indicating lease durations on the node (more details in the doc).
added a modal for “Delete Lease” to select which lease to delete on the node and to confirm the deletion.
changed nothing in the dropdown for each node, it shows the information for the current active lease.
removed the “Delete Lease” action from node that are just owned by the user and have no leases.
removed the “Lease Status” column.
added a “Resoure Class” column.

I would squash the commits and then rebase onto main to solve merge conflicts.

Changes:

Restructure Provisioning Wizard
Restructure Offer Claim Wizard
Decouple Node/Lease and Offer Into Separate Modules
Added owned nodes to the node table.
Added a “Lease Duration” column indicating lease durations on the node (more details in the doc).
Added a modal for “Delete Lease” to select which lease to delete on the node and to confirm the deletion.
Changed nothing in the dropdown for each node, it shows the information for the current active lease.
Removed the “Delete Lease” action from node that are just owned by the user and have no leases.
Removed the “Lease Status” column.
Added a “Resoure Class” column.

Just a few tweaks here and there

When you decouple the modules, make sure the naming aligns and are consistent for controllers, services, constants, etc
Move all the red batch buttons to the right side. And all the red dropdown buttons to the end of the list.
Move the catch statements from the controllers to the services

Currently, I can't see the page because it gives an error from the namings, so also make sure everything "compiles" to see your changes line up with what you expect!

@ajamias I made the changes, let me know if you still face any compilation issues.

@ajamias Deleted unused functions, changed module names for consistency, and added catch statements in the offers table services file as well.

@ajamias Removed the duplicate catch toasts, fixed the bug for manage networks and provisioning not showing up for owned nodes, and also resolved the other issues.

LGTM


Fix unhandled duplicate keyword in find command

Fixes #297
find command accepts duplicate keywords, but does not properly handle them.
Let's allow the keyword parser to accept duplicate keywords.

LGTM!


Clean up geofency test

Description:
Clean up geofency test in preparation for device tracker refactor to EntityComponent.
See:
https://github.com/home-assistant/home-assistant/pull/21151
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

If the code does not interact with devices:

[x] Tests have been added to verify that the new code works.

Test failure is an unrelated flaky test. Merging.


Offset argument contained a NaN value.

description: when CarouselSlider contains more than 1 image, everything goes correctly. but when only contains 1 image, the container only shows half of the image, the other half is blank.
issue details:
Exception caught by rendering library
The following assertion was thrown during paint():
Offset argument contained a NaN value.
'dart:ui/painting.dart':
Failed assertion: line 43: ''
The relevant error-causing widget was:
CarouselSlider-[LabeledGlobalKey#04485] file:///D:/flutter/abangate/lib/gallery_page.dart:84:39
When the exception was thrown, this was the stack:
#2      _offsetIsValid (dart:ui/painting.dart:43:10)
#3      Canvas.drawCircle (dart:ui/painting.dart:3787:12)
#4      CircularWaveIndicatorPainter.paint (package:flutter_carousel_slider/carousel_slider_indicators.dart:190:12)
#5      RenderCustomPaint._paintWithPainter (package:flutter/src/rendering/custom_paint.dart:531:13)
#6      RenderCustomPaint.paint (package:flutter/src/rendering/custom_paint.dart:572:7)
...
The following RenderObject was being processed when the exception was fired: RenderCustomPaint#5f0dc
...  parentData:  (can use size)
...  constraints: BoxConstraints(w=10.0, h=6.0)
...  size: Size(10.0, 6.0)
RenderObject: RenderCustomPaint#5f0dc
parentData:  (can use size)
constraints: BoxConstraints(w=10.0, h=6.0)
size: Size(10.0, 6.0)
FlutterCarouselSlider Version: 1.0.2
My code：
Container(
height: screenSize.height,
width: screenSize.width,
child: CarouselSlider.builder(
key: _sliderKey,
unlimitedMode: true,
slideBuilder: (index) {
return Container(
color: Colors.black,
alignment: Alignment.center,
child: GestureDetector(
child: Image.file(
File(widget.myContents[widget.contentIndex].images[index]),
),
onTap: () {
showDetails = !showDetails;
setState(() {});
},
),
);
},
slideTransform: ParallaxTransform(),
slideIndicator: CircularWaveSlideIndicator(
currentIndicatorColor: Colors.white38,
indicatorBackgroundColor: Colors.white24,
padding: EdgeInsets.only(bottom: 32),
indicatorRadius: 3,
itemSpacing: 10,
),
itemCount: widget.myContents[widget.contentIndex].images.length),
),

Issue with the indicator is fixed. Looking into the slider problem. Temporary solution would be to disable unlimited mode.

Issue with the indicator is fixed. Looking into the slider problem. Temporary solution would be to disable unlimited mode.

solved in v1.0.6


docs: update nuxi command pages

🔗 Linked issue

https://github.com/nuxt/cli/pull/592
https://github.com/nuxt/module-builder/issues/356

📚 Description
This changes the command pages description to more closely match the actual help/usage output of nuxt cli, unfortunately lots of the default values shown originally are lost, those values aren't exactly defaults but fall back values (the argument/option is unset and its value is based on environment variables, upstream cli fallbacks or nuxt configuration).
The values are extracted from the command definitions with a (very unreadable and wacky) script I wrote, I'm going to see if I can clean it up and perhaps find a way to ease syncing the commands docs with their actual config definitions.

I don't think CI is failing due to changes made in this PR 🤔
Also, the marker comments in the markdown will be removed at some point, I'm using these to find and replace the content extracted from the nuxt cli command definitions.

Great work 😊 a question please : could we use the --channel with nuxi init ?

Great work 😊 a question please : could we use the --channel with nuxi init ?

Thanks! The init command currently does not support the --channel flag, no. This PR only updates the documentation for the cli commands, you can open a feature request (or a PR) on https://github.com/nuxt/cli if you would like this functionality to be added 🙏

@BobbieGoede any chance you could update this following the latest changes in https://github.com/nuxt/cli/pull/592 ?
Also, if there's a way we can add (even a WIP) of your tool to the Nuxt repo so we could auto-update the docs as things change in the CLI, that would be genuinely amazing.

@danielroe
Actually the updated descriptions in this PR are not really the same as they are on the nuxt/cli repo, it depends on more changes (https://github.com/nuxt/cli/pull/601).

Also, if there's a way we can add (even a WIP) of your tool to the Nuxt repo so we could auto-update the docs as things change in the CLI, that would be genuinely amazing.

I actually have changes across nuxt/cli and citty (different defaults, negativeDescriptions) locally which makes it a bit more difficult to share something that will have the same output.
The script is honestly really messy, I'll share it as a gist in a bit so you can decide whether to include it here or not 😂 I was thinking to generalize it, remove the file writing, and publish it as a small package that just returns usage/help data for a given citty command when I have time.

@danielroe
Here is the code I used https://gist.github.com/BobbieGoede/b58803b8285cd3075f54ff03f33e45a8, use at your own risk :face_with_peeking_eye:


Make unbox casts cheap, make intorder free

There is something that was really bothering me about casts on primitive and struct values - despite upholding the type safety manually, there was still a helper call emitted for something that should have been a simple comparison and dereference of pointer + 0x08.
This is no longer the case - instead of calling into unbox helpers, we now reinterpret opaque object into a boxed representation of a struct we are about to unbox and directly read its value from memory.
Performance impact is minor however as benchmarks are now bottlenecked elsewhere:
205 71 272 -> 205 70 257, shaves off about 10% execution time in Fibonacci Map
The generated assembly however is now much cleaner for unbox-heavy parts of the code.
To illustrate the problem, here's the comparison: https://godbolt.org/z/nqe66nb8E
Given what in sharpl is Value with AnyType being an IntType reference and an unbox call for Type<int> we get an asm similar* to below. I have annotated some instructions so you can see what is exactly going on. Note that such calls are usually inlined and are slightly more compact in methods like Eval().
Program:Old(Program+OpaqueBox,System.Object):int (FullOpts):
G_M9948_IG01:  ;; offset=0x0000
       push     rbp
       push     rbx
       push     rax
       lea      rbp, [rsp+0x10]
       mov      rbx, rsi
G_M9948_IG02:  ;; offset=0x000B
       ;; Compare object references between type objects
       cmp      rdi, rdx
       ;; If the comparison false, jump to a call to a throw helper at label IG06
       jne      SHORT G_M9948_IG06
       ;; load the TypeHandle.Value (aka MethodTable (managed VTable) pointer) of Int32 box
       mov      rsi, 0x7AF75D860928      ; System.Int32
       ;; compare with MT of the boxed integer we're about to unbox
       cmp      qword ptr [rbx], rsi
       ;; if true, jump over unbox helper call and load the integer at reference + 0x08 offset
       ;; this is because object references point to MethodTable of the object on heap
       ;; where-as the actual object contents start at reference + sizeof(pointer)
       je       SHORT G_M9948_IG04
G_M9948_IG03:  ;; offset=0x001F
       mov      rsi, rbx
       mov      rdi, 0x7AF75D860928      ; System.Int32
       ;; this call is predominantly needed to handle boxed nullable integers and other edge cases
       call     [CORINFO_HELP_UNBOX]
G_M9948_IG04:  ;; offset=0x0032
       ;; dereference the integer from our box
       mov      eax, dword ptr [rbx+0x08]
G_M9948_IG05:  ;; offset=0x0035
       add      rsp, 8
       pop      rbx
       pop      rbp
       ret
G_M9948_IG06:  ;; offset=0x003C
       mov      rsi, rdi
       call     [Program+OpaqueBox:MismatchedType[int](System.Object,System.Object):int]
       int3

Program:New(Program+OpaqueBox,System.Object):int (FullOpts):
G_M18951_IG01:  ;; offset=0x0000
       push     rax
G_M18951_IG02:  ;; offset=0x0001
       ;; Compare type objects same as before
       cmp      rdi, rdx
       ;; Conditional jump to throw helper
       jne      SHORT G_M18951_IG04
       ;; If check succeeded, immediately dereference our integer
       mov      eax, dword ptr [rsi+0x08]
G_M18951_IG03:  ;; offset=0x0009
       add      rsp, 8
       ret
G_M18951_IG04:  ;; offset=0x000E
       mov      rsi, rdi
       call     [Program+OpaqueBox:MismatchedType[int](System.Object,System.Object):int]
       int3

* this asm is similar to what JIT and ILC will emit in practice, but has slight difference. Notably, it seems that ILC (AOT) output sometimes does not have this fast path check to avoid unbox helper call, which we care about. Meanwhile JIT has its own cast profiling and optimizations for the common, often monomorphic, cast behaviors to speed this up. In either case, because Value and Cast* methods are quite hot and are the core abstraction for the LISP type system, this makes such kind of last-mile optimizations valuable. As you can see, C# gives a lot of freedom and a degree of control that makes it suitable even for systems programming tasks :)

Thank you, I'm happy it bothered someone :)


Should proxy.config.http.send_100_continue_response default to 0?

The config defaults to 0, which is incongruent with the proposed standard RFC7231 5.1.1.
An origin server MUST, upon receiving an HTTP/1.1 (or later)
request-line and a complete header section that contains a
100-continue expectation and indicates a request message body will
follow, either send an immediate response with a final status code,
if that status can be determined by examining just the request-line
and header fields, or send an immediate 100 (Continue) response to
encourage the client to send the request's message body.  The origin
server MUST NOT wait for the message body before sending the 100
(Continue) response.

A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and
a complete header section that contains a 100-continue expectation
and indicates a request message body will follow, either send an
immediate response with a final status code, if that status can be
determined by examining just the request-line and header fields, or
begin forwarding the request toward the origin server by sending a

Clients are seen already using header. Should we consider proactively switching the default in some future release?

After discussing with @bryancall , I have been convinced we do not want to do this. The Expect: 100-continue header might be better passed to the origin directly.


AppDomain does not work as expected

build in UnicornAppDomainIsolation doesn’t work for different cases and looks useless (in all referencing apps/libs as result custom implementations are made)

done in 906dec1


[patch] Log a warning when manually creating/updating timestamp values

Thanks!  Consolidated in https://github.com/balderdashy/waterline/commit/d9c922d402771fad50888935a0ea3886aad9fafc
...but that made me notice a weird side effect: when sails-hook-orm's automigrations run, we get:

So rather than introducing a new meta key to deal with this, I'm commenting this out and wrapping it in a "FUTURE: consider..." comment for now.  If we find that there is significant confusion being caused by the fact that providing an explicit value for an autoUpdatedAt attribute is now allowed, that justifies the added complexity of another meta key, then I'm open to revisiting this.


Advice is out of date

The following statement is probably no longer entirely true:
https://github.com/apache/www-site/blob/1c40442f03293452783d760877c99b9670494abe/content/dev/infra-site.md?plain=1#L9-L10
Jira INFRA is not used for /foundation updates; is it still used for /dev updates?

Hello! I would be able to make the documentation work easy for this module, so please assign it to me.

Infra uses Jira for update requests on the /dev pages that relate to Infra.
On Sat, Jul 22, 2023 at 9:57 AM sebbASF @.***> wrote:

The following statement is probably no longer entirely true:
https://github.com/apache/www-site/blob/1c40442f03293452783d760877c99b9670494abe/content/dev/infra-site.md?plain=1#L9-L10
Jira INFRA is not used for /foundation updates; is it still used for /dev
updates?
—
Reply to this email directly, view it on GitHub
https://github.com/apache/www-site/issues/252, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC3RFXLHLXN3OX43KVPQZH3XRPE2RANCNFSM6AAAAAA2T2KMPI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Andrew Wetmore
Editor, Moose House Publications https://moosehousepress.com
Editor-Writer, The Apache Software Foundation https://apache.org

I have updated the page to clarify that, for most pages, one opens a GitHub issue to request changes. For /dev pages that relate in Infra, one opens a Jira ticket for Infra.


Provide functionality to convert existing ethereum secret key to pem-encoded keypair

The client should support a user providing a hex-encoded secret ethereum key (secp256k1) and outputting the three standard key files produced by the keygen subcommand.  Input should use https://docs.rs/rpassword/latest/rpassword/ or similar

Hi @cspramit , @piotr-dziubecki , could you please let me know when this will be prioritised please, as the tickets in the 'dependencies' section are dependent on this?


JRE gives warning for unusedLocalVariables

JRE gives warnings for unusedLocalVariables. This is due to missing suppress for hand-rolled JavaScript classes.
The fix is easy but more important is to make sure our conformance test (jre/javatests:conformance_binary) catches such issues.

@rluble assigning this to you but it is not urgent.


wallust: 2.9.0 -> 2.10.0

Description of changes
Changelog

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

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

[x] Fits CONTRIBUTING.md.

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

Reviewed points
Result of nixpkgs-review pr 283940 run on x86_64-linux 1

1 package built:

wallust

[X] package name fits guidelines
[X] package version fits guidelines
[X] package builds on x86_64-linux
[X] executables tested on x86_64-linux
[X] all depending packages build
[X] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed
[X] patches that are remotely available are fetched rather than vendored

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1414


Some fixes and corrections to the language specifications

This version still has some parts i'm not sure about, but it should be a good basis for further improvement. Please look at the changes i made and feel free to tweak it.

Great job!


Issues when updating the code from tf1 to tf2

Click to expand!
Issue Type
Others
Source
source
Tensorflow Version
tf2
Custom Code
Yes
OS Platform and Distribution
No response
Mobile device
No response
Python version
3.7.13
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current Behaviour?
'keras.api._v1.keras.layers' has no attribute 'conv2d'. I'm trying to change my code from tf1 to tf2, I changed all tf.layers to tf.keras.layers since in tf2 keras is the High level API and I had this error message

Standalone code to reproduce the issue
Traceback (most recent call last):
  File "baseCNN_dbl_norm.py", line 103, in <module>
    model = Model()
  File "baseCNN_dbl_norm.py", line 46, in __init__
    self.logits = self.build(self.images, self.n_classes)
  File "baseCNN_dbl_norm.py", line 57, in build
    conv1 = tf.keras.layers.conv2d(inputs=features,
  File "C:\Users\LENOVO\.conda\envs\Dchecker1.0\lib\site-packages\tensorflow\python\util\module_wrapper.py", line 232, in _getattr
    attr = getattr(self._tfmw_wrapped_module, name)
AttributeError: module 'keras.api._v1.keras.layers' has no attribute 'conv2d'

Relevant log output
No response

@nour397 Could you please refer to the migration doc to rewrite the code in TF v2.x style and try with the latest TF version? For any further queries please post this issue on keras-team/keras repo.
To know more see;
https://discuss.tensorflow.org/t/keras-project-moved-to-new-repository-in-https-github-com-keras-team-keras/1999
Thank you!


Version 1.2.4 (WGS 84 support)

Overview
This pull request introduces several enhancements to import and reftran to support handling of the World Geodetic System 1984 (WGS 84) and thereby closes #24. This support includes functionality for handling the WGS 84 ensemble and six specific WGS 84 realisations, including WGS 84 (Transit), WGS 84 (G730), WGS 84 (G873), WGS 84 (G1150), WGS 84 (G1674), WGS 84 (G1762), and WGS 84 (G2139).
General
Several code changes and enhancements effecting multiple programs include:

New epsg codes and datum labels for the WGS 84 ensemble and WGS 84 (xxxx), including:
wgs84 | wgs84 (transit) | wgs84 (g730) | wgs84 (g873) | wgs84 (g1150) | wgs84 (g1674) | wgs84 (g1762) | wgs84 (g2139)
wgs84 is taken to mean the WGS 84 ensemble, whereas wgs84 (xxxx) is taken to mean any one of the specific WGS 84 realisations (e.g. wgs84 (g2139)).
wgs84 is synonymous with wgs 84, and both are interpreted case-insensitively.
Exception handling updated to permit use of the WGS 84 ensemble and WGS 84 (xxxx).

Enhancements to import

Permit the use of any one of the WGS 84 datum labels in input DNA and DynaML files, and for the default reference frame (via the command line option --reference-frame).
Provide a warning if wgs84 (i.e. the WGS 84 ensemble) is supplied as the default reference frame.
Data may be supplied in either the WGS 84 ensemble or WGS 84 (xxxx) with or without an epoch.

Enhancements to reftran

Added hard coded substitutions for WGS 84 (xxxx) to ITRFxxxx to facilitate transformation of WGS 84 data to other reference frames. All substitutions are performed prior to undertaking a reference frame transformation.
Station coordinate and/or measurement data aligned to WGS 84 without an epoch will cause reftran to terminate prematurely. Data aligned to WGS 84 (xxxx) without an epoch, will cause the associated epoch to be set to the date at which the WGS 84 (xxxx) frame realisation was adopted.
Any attempt to transform station coordinates and measurements to WGS 84 will cause reftran to terminate prematurely.

DynAdjust User's Guide
Several changes have been made to reflect the new behaviour, including:

3.3.1 Reference frame receives a general overhaul and a new section entitled "Handling data aligned to WGS 84"
Chapter 4 sees various improvements throughout, including

Revised epsg codes, and new epsg codes for WGS 84 (xxxx) and WGS 84 ensemble.
Updated 4.6.2 Relationship between ITRF, IGS and WGS 84 reference frames.
Updated 4.7.1 Progress reporting and import log.

Acknowledgements
Special thanks to Joel Haasdyk for his help in shaping the preferred behaviour for handling WGS 84 data.

Coverage increased (+0.6%) to 81.893% when pulling a6e2cca501cdf5bd98c9fe8e966a17ef1cbdd5a7 on 1.2.4 into b9ee8089446661d5d4ae7f0f99a5933a1ac2e5d0 on master.