Issue Template Updates for Figma link

Current Behavior
The project's current issue templates are missing an open invitation link where new contributors can join the community's Figma team and view user interface designs and other UX projects.
Desired Situation
Each template that has a reference to Figma in its resources section should an invite link added.
Implementation
- 🎨 Wireframes and [designs for Meshery UI](https://www.figma.com/file/SMP3zxOjZztdOLtgN4dS2W/Meshery-UI) in Figma [(open invite)](https://www.figma.com/team_invite/redeem/qJy1c95qirjgWQODApilR9)

Acceptance Tests
All references to Figma include the "open invite" link.

Contributor Guide

Hi, I am a newcomer, I want to learn and grow.  can I join to solve the issue with guidance?
but I am new to Figma with guidance definitely i will complete the task.

There you go @csengineer1990  , all you need to do is add
this
 🎨 Wireframes and [designs for Meshery UI](https://www.figma.com/file/SMP3zxOjZztdOLtgN4dS2W/Meshery-UI) in Figma [(open invite)](https://www.figma.com/team_invite/redeem/qJy1c95qirjgWQODApilR9)
in existing issue template under .github folder

@Ghat0tkach sir, I am new to GitHub and I tried many ways to solve this in the middle I thought I lost the commit by mistake I ran the reset command and then somehow managed to get back to revert the original commit. Now I again raise PR still facing the same problem. Please help me to complete this request.

@Ghat0tkach sir, I am new to GitHub and I tried many ways to solve this in the middle I thought I lost the commit by mistake I ran the reset command and then somehow managed to get back to revert the original commit. Now I again raise PR still facing the same problem. Please help me to complete this request.

No worries @csengineer1990 sir , do the changes again and raise a PR.
Please be sure to sign off commit this time.
Signing of commits could be definately challenge for first time.
If you ran into any problem again , please text on slack 🙌

yes, sir A little challenging. I am trying every possible solution which I am finding related to signing off with GPG.

yes, sir A little challenging. I am trying every possible solution which I am finding related to signing off with GPG. ok, sir.

Please don't be worry , All you have to is  after commiting your changes , the commit messaage which you use to write  using
git commit -m "msg"
just replace it with
git commit -s -m "msg"

I want to work on it. Can u assign me?


Max Table Size

Are there plans to implement a routine to clean the table, using MaxTableSize and Blocksize?

It already does that. https://github.com/IntelliTect/IntelliTect.AspNetCore.SignalR.SqlServer/blob/master/src/IntelliTect.AspNetCore.SignalR.SqlServer/Internal/SqlServer/send.sql#L35-L66

Nice, tanks @ascott18 !!
Does this script run automatically?

That is the main send script - it runs on every single message sent.


Setup Jenkins for building binary artifacts

For {Windows, Mac} x {Python, Ruby, Node} for releases

Only python on Windows is missing at this point so this umbrella issue has done it's job.


Change generated code for version 3 release

[x] Remove get_ prefix from functions as API guide suggests
[ ] Make all fields public
[ ] All singular fields should have getters (including singular proto3 fields)
[ ] Only oneof fields should have set_xxx and has_xxx methods

First off, thank you for your work on this project. It is by no means a small undertaking!
Would you mind exposing/generating all of the compiler related protobuf files? A lot of enums are not currently available, such as Name, IdempotencyLevel, NamePart, JsType and so on.
I'm working on a port of protoc-gen-star to rust here and it'd be really helpful if they were all available on this crate. I initially started with prost but it doesn't support unknown fields which I'll need for extension parsing.
I could generate them myself but it looks like you've modified the output somewhat? I could be wrong there.
Thanks again!

These types are present in rust-protobuf v3 (which is not release yet).
In rust-protobuf v2 probably code just need to be regenerated, but releasing v3 is my priority now.

@stepancheg ugh, I'm sorry! I did a search across the repo and couldn't find them. Thank you!


On opening, cursor points to the same file, not the last used

Self-Diagnosis

[x] I have searched the issues for an answer to my question.
[x] I have reviewed the NERDTree documentation. :h NERDTree
[x] I have reviewed the Wiki.
[x] I have searched the web for an answer to my question.

Environment (for bug reports)

[x] Operating System: Fedora 30
[x] Vim/Neovim version :echo v:version: 8.1.1912 (801)
[x] NERDTree version, found on 1st line in NERDTree quickhelp ?: 5.2.9, 5.3.0
[x] vimrc settings

[x] NERDTree variables

Other NERDTree-dependent Plugins

[x] Others (specify): none

[x] I've verified the issue occurs with only NERDTree installed.

Steps to Reproduce the Issue

Open NERDTree
Select file, open
Do steps 1-2 several times
User Ctrl+^ several times
Repeat steps 1-4
At some point of time, the cursor is always pointing to the same file, not the last opened

Current Result (Include screenshots where appropriate.)
On opening NERDTree, the current file cursor always moves to the same file.
Expected Result
On opening NERDTree, the current file cursor points to the last opened file.
Regression
Can be reproduced with 5.3.0 or above.
Cannot be reproduced with 5.2.9 or below.

@ruslansagitov I cannot reproduce this bug. Do you have any autocmds or other plugins that would interfere with this and alter the value in the alternate buffer register - #?

Sorry for delay. I was kinda busy.
So, right now, I tried again to reproduce this glitch, turning off all of the plugins again (except vundle and nerdtree) and commenting out all autocmds and nerdtree options, except NERDTreeQuitOnOpen=1 as it’s required to reproduce. It’s still there, in 5.3.1.
I was wrong at first place. I downgraded NERDTree to 5.2.9 and at the end of that day I reproduced the glitch just by working. It was much harder to reproduce however. Then, I downgraded to 5.2.8 and the glitch disappered. So, I’m using 5.2.8 for 11 days already and I’m not seeing it anymore.
I know this this glitch is hard to reproduce but I thought it would be good to report it. Maybe someone is also facing this wierd issue. If you cannot reproduce it, feel free to close this issue. I’m pretty happy with 5.2.8.

@ruslansagitov Give the latest version of NERDTree a try. That may have been fixed by fixing an unrelated issue.

Yup, I cannot reproduce it with 6.1.3 but I can still easily and consistently reproduce it with 5.3.1.
The wierd thing, I cannot reproduce it even with 5.3.2… but 5.3.1 is really affected :-)
Thanks. Case closed.


Doesn't seem to work anymore with HA 2022.3.1

I've created a long access token, set my url, port and new token,
then added a single switch entity
BUT the app says connection error
BUT HA also keeps saying access is denied then after 3 tries opening the app on my watch
HA bans me from logging in for 5mins?

@si458
I just read the latest release notes of home assistant. I can't find any changes regarding the RestfulAPI.
Since I can't test it (my HA is currently not working) please wait till I release version 0.6 (still in review by Fitbit). I reworked the error information.
Was the app working before you updated HA?

@si458 This is not caused by HA itself and nothing changed with the latest release. What happens is that each time you enter the connection details the app tries to connect to HA. This causes a failed connection until you put the access token too. To avoid this behavior start from the token so when you put the address, as last thing, the token will already be in the app settings and everything works smoothly

sorry for delay, i understand the logic behind put the key in first, however the app still isnt working, it just keeps saying 'connect error' and my HA displays a message saying 'unauthorised access' every time i open up the app on my versa 2 even through the token is correct, same with the server url and port?

@si458 Did you copy&paste the key correctly (sorry for that stupid question)? Other people old me about issues doing that. In such cases not the whole key was copied which would leads to error. Did you enable the Rest Api in your HA?

@smirko-dev i have deleted my old key, then created a new key, copied it into my Paw app on my laptop, queried the API, and got results from https://myhomeassistantwebsite.duckdns.org:8123/api/states no problems! so i know the key works,
but if i set it in the fitbit app, the app says 'connect error' and HA then shows a notification saying 'Login attempt or request with invalid authentication from 148.xxx.xxx.xxx (148.xxx.xxx.xxx). See the log for details.'
and ive checked my homeassistant.log file and its the same there '2022-03-05 16:56:51 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from 148.xxx.xxx.xxx (148.xxx.xxx.xxx). (Fitbit/3.55 Android/31' so the must be something thats different?

@smirko-dev i have just remembered i have my own developer account 😆,
so ill try copying your repo and building it on my watch and see what happens from the console.log

Let me know about your investigation. Since I don't know how to help, I'm curious about the problem/solution :)

@smirko-dev very weird? it works? but ive found a BIG bug 😞
for some reason when changing the settings in the app, it doesnt send the new data to the app on the watch,
YOU MUST HAVE THE APP OPEN ON THE WATCH WHEN CHANGING THE SETTINGS FOR THEM TO APPLY!
e.g: i set it all up with the app closed on my watch, but the watch just receieved 'localhost' as the server url?
so i went into the settings and then re-saved the URL and then the watch recieved that url, and when i open the app back up again after 1min of it being closed, it received the correct URL ?
its also annoying because if you enter the entities, one by one by one, the watch app must be open, as i added 3 switched in, but they where not being sent to the watch, so i had to delete them one by one and then re-add them by trying them in again one by one
im still looking into why it isnt sending the correct url on first start up even if you have setting set?

little debug log for you,

installed app
it autolaunched app, which i then closed straight away
i launched settings app, set my details, and open/closed a few times
launched app on watch,
it then sends localhost back and forth for some reason?
closed/opened app a few times
launched app, then launched settings and modified url
it then sent the correct url
again closed/opened app a few times and it was sending backand forth the correct url

Launching app
[17:34:53]       App: App Closed
[17:34:54] Companion: Loaded and evaluated: file:///android_asset/bootstrap.js                                                                                (js-engine-bootstrap.html:9,1)
[17:34:54] Companion: Loaded and evaluated: file:///data/user/0/com.fitbit.FitbitMobile/app_companions/17a0bd62-418a-4f3f-98ad-b0d38a548286/0x02c5c2a408d6bdb2/companion.js                 (js-engine-bootstrap.html:9,1)
[17:34:54] Companion: Companion launched by [launchedOnTracker]
[17:34:54]       App: App Started
[17:34:54]       App: Error loading settings                                                                                (app/index.js:126,9)
[17:34:54] Companion: Socket open                                                                                (companion/index.js:125,9)
[17:34:55]       App: Socket open                                                                                (app/index.js:107,5)
[17:34:55]       App: Sent                                                                                (common/utils.js:7,9)
[17:34:55]       App: {"key":"url","value":"localhost"}                                                                                (common/utils.js:7,9)
[17:34:55]       App: Sent                                                                                (common/utils.js:7,9)
[17:34:55]       App: {"key":"port","value":"8123"}                                                                                (common/utils.js:7,9)
[17:34:55]       App: Sent                                                                                (common/utils.js:7,9)
[17:34:55]       App: {"key":"token","value":""}                                                                                (common/utils.js:7,9)
[17:34:55]       App: Sent                                                                                (common/utils.js:7,9)
[17:34:55]       App: {"key":"entities"}                                                                                (common/utils.js:7,9)
[17:34:55]       App: Sent                                                                                (common/utils.js:7,9)
[17:34:55]       App: {"key":"force","value":false}                                                                                (common/utils.js:7,9)
[17:34:55] Companion: Received {"key":"url","value":"localhost"}                                                                                (companion/index.js:194,1)
[17:34:55] Companion: Received {"key":"port","value":"8123"}                                                                                (companion/index.js:194,1)
[17:34:55] Companion: Received {"key":"token","value":""}                                                                                (companion/index.js:194,1)
[17:34:55] Companion: Received {"key":"entities"}                                                                                (companion/index.js:194,1)
[17:34:55] Companion: Received {"key":"force","value":false}                                                                                (companion/index.js:194,1)
[17:35:03]       App: App Closed
[17:35:03] Companion: Socket closed                                                                                (companion/index.js:189,1)
[17:35:03]       App: App Started
[17:35:03] Companion: App closed on device, unloading companion in 3 seconds…
[17:35:04]       App: Launch complete - durations: foregrounding(1096ms), first paint(185ms), total(1284ms).
[17:35:06] Companion: Unloading companion…
[17:35:08] Companion: Companion unloaded
[17:35:09]  Settings: Settings Started
[17:35:22] Companion: Loaded and evaluated: file:///android_asset/bootstrap.js                                                                                (js-engine-bootstrap.html:9,1)
[17:35:23] Companion: Loaded and evaluated: file:///data/user/0/com.fitbit.FitbitMobile/app_companions/17a0bd62-418a-4f3f-98ad-b0d38a548286/0x02c5c2a408d6bdb2/companion.js                 (js-engine-bootstrap.html:9,1)
[17:35:23] Companion: Companion launched by [settingsChanged], unloading companion in 15 seconds…
[17:35:38] Companion: Unloading companion…
[17:35:40] Companion: Companion unloaded
[17:36:04] Companion: Loaded and evaluated: file:///android_asset/bootstrap.js                                                                                (js-engine-bootstrap.html:9,1)
[17:36:04] Companion: Loaded and evaluated: file:///data/user/0/com.fitbit.FitbitMobile/app_companions/17a0bd62-418a-4f3f-98ad-b0d38a548286/0x02c5c2a408d6bdb2/companion.js                 (js-engine-bootstrap.html:9,1)
[17:36:04] Companion: Companion launched by [settingsChanged], unloading companion in 15 seconds…
[17:36:16] Companion: [fetchEntity]: TypeError: Failed to fetch - Please use https:// when communicating with internet endpoints. https://dev.fitbit.com/reference/companion-api/fetch/         (companion/index.js:92,13)
[17:36:19] Companion: Unloading companion…
[17:36:21] Companion: Companion unloaded
[17:36:35]  Settings: Settings Closed
[17:36:38]  Settings: Settings Started
[17:36:40]  Settings: Settings Closed
[17:36:46]       App: App Closed
[17:36:47]       App: App Started
[17:36:47]       App: Launch complete - durations: foregrounding(784ms), first paint(45ms), total(846ms).
[17:36:47] Companion: Loaded and evaluated: file:///android_asset/bootstrap.js                                                                                (js-engine-bootstrap.html:9,1)
[17:36:47]       App: Socket open                                                                                (app/index.js:107,5)
[17:36:47]       App: Sent                                                                                (common/utils.js:7,9)
[17:36:47]       App: {"key":"url","value":"localhost"}                                                                                (common/utils.js:7,9)
[17:36:47]       App: Sent                                                                                (common/utils.js:7,9)
[17:36:47]       App: {"key":"port","value":"8123"}                                                                                (common/utils.js:7,9)
[17:36:47]       App: Sent                                                                                (common/utils.js:7,9)
[17:36:47]       App: {"key":"token","value":""}                                                                                (common/utils.js:7,9)
[17:36:47]       App: Sent                                                                                (common/utils.js:7,9)
[17:36:47]       App: {"key":"entities"}                                                                                (common/utils.js:7,9)
[17:36:47]       App: Sent                                                                                (common/utils.js:7,9)
[17:36:47]       App: {"key":"force","value":false}                                                                                (common/utils.js:7,9)
[17:36:47] Companion: Loaded and evaluated: file:///data/user/0/com.fitbit.FitbitMobile/app_companions/17a0bd62-418a-4f3f-98ad-b0d38a548286/0x02c5c2a408d6bdb2/companion.js                 (js-engine-bootstrap.html:9,1)
[17:36:47] Companion: Companion launched by [launchedOnTracker]
[17:36:47] Companion: Socket open                                                                                (companion/index.js:125,9)
[17:36:47] Companion: Received {"key":"url","value":"localhost"}                                                                                (companion/index.js:194,1)
[17:36:47] Companion: Received {"key":"port","value":"8123"}                                                                                (companion/index.js:194,1)
[17:36:47] Companion: Received {"key":"token","value":""}                                                                                (companion/index.js:194,1)
[17:36:47] Companion: Received {"key":"entities"}                                                                                (companion/index.js:194,1)
[17:36:47] Companion: Received {"key":"force","value":false}                                                                                (companion/index.js:194,1)
[17:36:55]       App: App Closed
[17:36:55] Companion: Socket closed                                                                                (companion/index.js:189,1)
[17:36:55] Companion: App closed on device, unloading companion in 3 seconds…
[17:36:55]       App: App Started
[17:36:58] Companion: Unloading companion…
[17:36:58]       App: App Closed
[17:36:58]       App: App Closed
[17:36:58]       App: App Started
[17:36:58]       App: Launch complete - durations: foregrounding(772ms), first paint(46ms), total(835ms).
[17:37:00] Companion: Companion unloaded
[17:37:00] Companion: Loaded and evaluated: file:///android_asset/bootstrap.js                                                                                (js-engine-bootstrap.html:9,1)
[17:37:00] Companion: Loaded and evaluated: file:///data/user/0/com.fitbit.FitbitMobile/app_companions/17a0bd62-418a-4f3f-98ad-b0d38a548286/0x02c5c2a408d6bdb2/companion.js                 (js-engine-bootstrap.html:9,1)
[17:37:00] Companion: Companion launched by [launchedOnTracker]
[17:37:00] Companion: Socket open                                                                                (companion/index.js:125,9)
[17:37:00] Companion: Received {"key":"url","value":"localhost"}                                                                                (companion/index.js:194,1)
[17:37:00] Companion: Received {"key":"port","value":"8123"}                                                                                (companion/index.js:194,1)
[17:37:00] Companion: Received {"key":"token","value":""}                                                                                (companion/index.js:194,1)
[17:37:00]       App: Socket open                                                                                (app/index.js:107,5)
[17:37:00]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:00]       App: {"key":"url","value":"localhost"}                                                                                (common/utils.js:7,9)
[17:37:00]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:00]       App: {"key":"port","value":"8123"}                                                                                (common/utils.js:7,9)
[17:37:00]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:00]       App: {"key":"token","value":""}                                                                                (common/utils.js:7,9)
[17:37:00]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:00]       App: {"key":"entities"}                                                                                (common/utils.js:7,9)
[17:37:00]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:00]       App: {"key":"force","value":false}                                                                                (common/utils.js:7,9)
[17:37:00] Companion: Received {"key":"entities"}                                                                                (companion/index.js:194,1)
[17:37:00] Companion: Received {"key":"force","value":false}                                                                                (companion/index.js:194,1)
[17:37:12]  Settings: Settings Started
[17:37:16]  Settings: Settings Closed
[17:37:18]  Settings: Settings Started
[17:37:21] Companion: Sent {"key":"url","value":"https://myhomeassistant.duckdns.org"}                                                                                (common/utils.js:5,1)
[17:37:22]       App: Received: {"data":{"key":"url","value":"https://myhomeassistant.duckdns.org"}}                                                                                (app/index.js:59,5)
[17:37:22]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:22]       App: {"key":"url","value":"https://myhomeassistant.duckdns.org"}                                                                                (common/utils.js:7,9)
[17:37:26] Companion: Received {"key":"url","value":"https://myhomeassistant.duckdns.org"}                                                                                (companion/index.js:194,1)
[17:37:28] Companion: Sent {"key":"port","value":"8123"}                                                                                (common/utils.js:5,1)
[17:37:29] Companion: Received {"key":"port","value":"8123"}                                                                                (companion/index.js:194,1)
[17:37:29]       App: Received: {"data":{"key":"port","value":"8123"}}                                                                                (app/index.js:59,5)
[17:37:29]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:29]       App: {"key":"port","value":"8123"}                                                                                (common/utils.js:7,9)
[17:37:31] Companion: Sent {"key":"token","value":"LONGASSKEYHERE"}                                                                                (common/utils.js:5,1)
[17:37:31]       App: Received: {"data":{"key":"token","value":"LONGASSKEYHERE"}}                                                                                (app/index.js:59,5)
[17:37:31]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:31]       App: {"key":"token","value":"LONGASSKEYHERE"}                                                                                (common/utils.js:7,9)
[17:37:32] Companion: Received {"key":"token","value":"LONGASSKEYHERE"}                                                                                (companion/index.js:194,1)
[17:37:32] Companion: Sent {"key":"api","value":"ok","name":"Home"}                                                                                (common/utils.js:5,1)
[17:37:32]       App: Received: {"data":{"key":"api","value":"ok","name":"Home"}}                                                                                (app/index.js:59,5)
[17:37:37]  Settings: Settings Closed
[17:37:40]       App: App Closed
[17:37:41] Companion: Socket closed                                                                                (companion/index.js:189,1)
[17:37:41]       App: App Started
[17:37:41] Companion: App closed on device, unloading companion in 3 seconds…
[17:37:42]       App: App Closed
[17:37:43]       App: App Started
[17:37:43]       App: Launch complete - durations: foregrounding(744ms), first paint(49ms), total(817ms).
[17:37:43] Companion: App was opened on device; companion will no longer be unloaded
[17:37:43] Companion: Socket open                                                                                (companion/index.js:125,9)
[17:37:43]       App: Socket open                                                                                (app/index.js:107,5)
[17:37:43]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:43]       App: {"key":"url","value":"https://myhomeassistant.duckdns.org"}                                                                                (common/utils.js:7,9)
[17:37:43]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:43]       App: {"key":"port","value":"8123"}                                                                                (common/utils.js:7,9)
[17:37:43]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:43]       App: {"key":"token","value":"LONGASSKEYHERE"}                                                                                (common/utils.js:7,9)
[17:37:43]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:43]       App: {"key":"entities"}                                                                                (common/utils.js:7,9)
[17:37:43]       App: Sent                                                                                (common/utils.js:7,9)
[17:37:43]       App: {"key":"force","value":false}                                                                                (common/utils.js:7,9)
[17:37:43] Companion: Received {"key":"url","value":"https://myhomeassistant.duckdns.org"}                                                                                (companion/index.js:194,1)
[17:37:43] Companion: Received {"key":"port","value":"8123"}                                                                                (companion/index.js:194,1)
[17:37:43] Companion: Received {"key":"token","value":"LONGASSKEYHERE"}                                                                                (companion/index.js:194,1)
[17:37:43] Companion: Received {"key":"entities"}                                                                                (companion/index.js:194,1)
[17:37:43] Companion: Received {"key":"force","value":false}                                                                                (companion/index.js:194,1)
[17:37:43] Companion: Sent {"key":"api","value":"ok","name":"Home"}                                                                                (common/utils.js:5,1)
[17:37:43] Companion: Sent {"key":"api","value":"ok","name":"Home"}                                                                                (common/utils.js:5,1)
[17:37:43] Companion: Sent {"key":"api","value":"ok","name":"Home"}                                                                                (common/utils.js:5,1)
[17:37:43]       App: Received: {"data":{"key":"api","value":"ok","name":"Home"}}                                                                                (app/index.js:59,5)
[17:37:44]       App: Received: {"data":{"key":"api","value":"ok","name":"Home"}}                                                                                (app/index.js:59,5)
[17:37:44]       App: Received: {"data":{"key":"api","value":"ok","name":"Home"}}                                                                                (app/index.js:59,5)

@si458
Thanks for that feedback and trying out so fast.
As I wrote in the docs, I just tested it by simulation. That means your use case is so far unknown to me. I will check the Fitbit SDK docs for that even though most of the functions are based on Fitbit example code.

@smirko-dev its perfectly fine, i love the little app!
but it might also explain why i keep getting the 'connect error' because its not sending the token correctly to my watch unless i have both settings and the app open at the same time!

@smirko-dev also another weird bug, the state doesnt get updated?
e.g. i added a switch which says OFF, so i click it and i see in the logs it sending the turn_on state and it turns on,
but the watch doesnt update its state or even check its new state?
[18:01:49]       App: Received: {"data":{"key":"api","value":"ok","name":"Home"}}                                                                                (app/index.js:59,5)
[18:01:50]       App: Received: {"data":{"key":"add","id":"switch.woox_r4785_socket","name":"Bedside Lamp Socket","state":"on"}}                                                                       (app/index.js:59,5)
[18:01:51]       App: Sent                                                                                (common/utils.js:7,9)
[18:01:51]       App: {"key":"change","entity":"switch.woox_r4785_socket","state":"turn_off"}                                                                                (common/utils.js:7,9)
[18:01:51] Companion: Received {"key":"change","entity":"switch.woox_r4785_socket","state":"turn_off"}                                                                                (companion/index.js:194,1)

@si458
I tried to fix the bug. Can you check
https://github.com/smirko-dev/fitbit-homeassistant/pull/16?

I had a similar problem and having used the debugger realized that settings retrieval is what's breaking. Even though in the Fitbit App I had the correct settings, HA Remote was reporting default values.
When I went through the settings top to bottom again, opening and saving them, HA Remote finally connected OK.
I then reproduced it with v0.6, so can confirm the released version is working.

I’m still having this issue. HA Remote says “connection error” and I’m seeing “Login attempt or request with invalid authentication” in the logs.
I know my long lived tokens are working because I’ve sent authenticated requests with another device. I’m assuming the URL and port are correct because I’m seeing the failed login attempt in the logs.
I’ve tried opening the app on my watch while updating the settings but that didn’t work. Any ideas?

@davomyster

With the current Fitbit app unsecured traffic is blocked (https://community.fitbit.com/t5/SDK-Development/Fetch-API-doesn-t-work/m-p/5204923#M17769).
The current version doesn't catch empty strings in the settings. This causes the invalid authentification. I fixed that with https://github.com/smirko-dev/fitbit-homeassistant/pull/19.

Besides that I have no idea since I tested it with 2 different watches and my HA.
Changing entities worked for me without having the app open.
As long as the Fitbit app is not fixed I can't test since my HA runs without SSL :(

What is the status making it work using nabu casa? That's the only way I can get a secure connection to my HA installation. I don't see why it shouldn't work though since a normal curl request to the api via nabu casa works exactly like a local request.

@dustrat When you access you HA instance via NabuCasa do you need to use the port in your url or it works without link in this post? https://community.home-assistant.io/t/use-nabu-casa-url-to-use-ha-api/382563/2

@dustrat When you access you HA instance via NabuCasa do you need to use the port in your url or it works without like in this post? https://community.home-assistant.io/t/use-nabu-casa-url-to-use-ha-api/382563/2

I use the nabu casa url and specifies port 443 explicitly. It seems to connect now, but I get "connection failure" and a "login failed" notification in HA, so at least that part works. Tried to create a new token, doesn't work anyway, so seems to be the same issue @davomyster has.

It's actually working now. Adding a new token while app is active on the
watch seems to be the trick. Seems necessary for adding entities too.
Den tis 16 aug. 2022 06:51smirko-dev @.***> skrev:

@dustrat https://github.com/dustrat When you access you HA instance via
NabuCasa do you need to use the port in your url or it works without link
in this post?
https://community.home-assistant.io/t/use-nabu-casa-url-to-use-ha-api/382563/2
—
Reply to this email directly, view it on GitHub
https://github.com/smirko-dev/fitbit-homeassistant/issues/14#issuecomment-1216143203,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUTIJF35NSV3MUM2BQHWOTLVZMM3VANCNFSM5P7NYBUA
.
You are receiving this because you were mentioned.Message ID:
@.***>

It's working for me as well but I still get authentication errors on app starting, it eventually connects after a moment.

@ecto1a2003 Thats because of an incomplete setup. I tried to fix that with https://github.com/smirko-dev/fitbit-homeassistant/pull/21. As soon as I have a working setup again and Fitbit supports again http access via IP I will test that.


Revalidate Strategy

Add a new "Revalidate" strategy - this allows Alephant to be used to host data/components that have a finite timespan (or TTL).
It follows the following process flow:

This means that the user will always see content, but as the content becomes "stale", it will be automatically refreshed in the background via the renderer.

Other than a few minor comments this LGTM

👍 Let's merge this Beast!


Inserting N records in one query

What do you want to change?
I have a REST API writting in Go and I use SQLC for all the querying. However, I've felt very limited by the fact that I cannot have a function that bulk inserts to the database.
There are 2 workarounds for this:

Call the single insert function N times.
Use a raw function for a custom query (potentially unsafe)

I apologise if this feature already exists; I looked through the docs and several other places but couldn't find anything that hinted towards this feature.
What database engines need to be changed?
PostgreSQL, MySQL, SQLite
What programming language backends need to be changed?
Go, Python, Kotlin

https://docs.sqlc.dev/en/latest/howto/insert.html#using-copyfrom

Yeah, I've discovered that and experimenting with it. Sadly it errors out for non-parameter values:
database/queries/club/member.sql:1:1: :copyfrom doesn't support non-parameter values

If it doesn't work, a reproduced link on play.sqlc.dev would be helpful.
What database engine are you using?

Currently, copyfrom with subquery is not supported

Cool, no problem. Thanks for the help!


PowerShell on Mac OS X: error Debug adapter process has terminated unexpectedly

VSCode Version: Code 1.4.0 (6276dcb0ae497766056b4c09ea75be1d76a8b679, 2016-08-04T16:41:29.513Z)
OS Version: Darwin x64 15.6.0

Steps to Reproduce:

Added PowerShell extension,
Created a simple file hello.ps1 with simple script: $i = 1,
Save the file,
Open folder containing the file,
Click Debug,
Accept default launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "PowerShell",
            "type": "PowerShell",
            "request": "launch",
            "program": "${file}",
            "args": [],
            "cwd": "${file}"
        }
    ]
}

Press F5.
Shows error "Debug adapter process has terminated unexpectedly"

Moved to PowerShell/vscode-powershell#251


Hi, switch month and week, there will be gray background Flashing

This should've been fixed. Can u pls test again?


pre mode with "latest" dist-tag publishing?

Hey everyone! Fred from Astro here, and we've just entered a 2-month v1.0.0-beta.X period before our official Astro v1.0 release in June.
We've been happy changeset users so far but now I'm not sure the best way to structure/configure changesets for the next two months. What I'd really want is...
What we want:

Every package in the monorepo released to latest
Only astro is versioned at v1.0.0-beta.X, all others follow v0.x semver
don't need to be in pre mode if we can help it.

What we've tried:
But I don't think that's possible. Based on what I know of changesets, I expected this to work as a secondary option:

monorepo is in pre mode (tag: 'beta')
when we publish, we can still publish all packages to latest

The problem is that changeset publish --tag latest doesn't seem to be respected. When I run a dry-run, I see an error that --tag isn't supported in pre mode.
Any thoughts for how we could achieve something like this with changesets? Since it's short term, I'm willing to do something hacky if you have any suggestions. Thank you!

What should be the tag for the astro? Should it be beta here? Should the astro@latest keep pointing to some older 0.x version?

The problem is that changeset publish --tag latest doesn't seem to be respected. When I run a dry-run, I see an error that --tag isn't supported in pre mode.

Even if this would work... what would happen to astro? changeset publish tries to publish everything that has not yet been published to the registry. And it seems that you want to avoid publishing astro beta versions as latest (unless I misunderstood the issue).
If this would help you - I'm open to scheduling a quick call to hash it out cause I think there is definitely some workaround (even if slightly hacky :P) to make it work for you. I just need to understand all of your constraints/requirements properly

From what I understand, they want to publish<EMAIL_ADDRESS>as the latest tag on npm. I have the same requirement with ariakit.

Update 2: I now understand that it was released on the latest tag because I didn't have any stable release on the ariakit-changesets-test package.

Yes, the latest tag has to be set to something - that's a requirement of the npm registry.

Update 3: I was able to force the latest tag on the prerelease by using the publishConfig field on the package.json file.

Interesting. So you have just added something like this?
{
  "publishConfig": { "tag": "latest" }
}

Which npm client do you use?

Update 3: I was able to force the latest tag on the prerelease by using the publishConfig field on the package.json file.

Interesting! @diegohaz  Did this work automatically with changesets publish, or did you have to define your own publish step using pnpm/yarn/npm, outside of changesets?

I'm pretty sure that this is not handled by Changesets and that it might only be handled by some package managers (I'm unsure which ones support this).

If this would help you - I'm open to scheduling a quick call to hash it out cause I think there is definitely some workaround (even if slightly hacky :P) to make it work for you. I just need to understand all of your constraints/requirements properly

@Andarist apologies for missing this! We're in the middle of a big launch week which has been quite busy 😅 . If you're interested in joining us in Discord, we could do this async but maybe a bit more high-touch? astro.build/chat
Otherwise, happy to keep debugging here!

I'm using npm 8.

@Andarist honestly, I'm starting to think we might want to fork changesets, and do an astro-specific hack to get us through the next 2 months. I keep getting stuck on ideas:

Run a post-publish npm dist-tag add<EMAIL_ADDRESS>latest step to our GitHub Action, so that latest always matches beta (okay, but we need this for all packages in the monorepo, not just Astro)
Run a post-publish npm dist-tag add X@Y latest step to our GitHub Action, so that latest always matches beta for all packages in the monorepo (okay, but non-Astro dependencies are getting the -beta.1 unnecessarily. We kind of want them to be non-beta, non-pre, normal semver)
I can't think of any way this could work without the repo being in pre-mode.

I think the smallest fork we could make, would be to keep the monorepo in normal mode, but then surgically overwrite whatever internal logic handles version bumping, to just always handle "astro" as a special case to always bump as 1.0.0-beta${X+1}. Everything else about normal "non-pre" mode would remain the same.
@Andarist what do you think?

Yeah, forking seems to be the easiest solution to this - especially given that you only need this temporarily~.
In general, Changesets has not been designed to handle multiple independent "release plans". It's not impossible to add support for those... but it raises the complexity quite a bit because we would have to consider how parallel release plans interact with each other, can they overlap somehow? Can A from RP1 depend on B from RP2? etc etc. This would require deeper thought, analysis, and implementation - and, unfortunately, I'm so slammed with piling OSS issues that I just don't have capacity to do all of this on my own.

Run a post-publish npm dist-tag add<EMAIL_ADDRESS>latest step to our GitHub Action, so that latest always matches beta (okay, but we need this for all packages in the monorepo, not just Astro)

about that: https://github.com/sveltejs/kit/pull/4564

@Andarist

What should be the tag for the astro? Should it be beta here? Should the astro@latest keep pointing to some older 0.x version?

No, the tag should be latest.
This doesn't seem to go against what changeset is doing that much to me. We just want it to be the latest tag instead of the beta tag.

@FredKSchott

Run a post-publish npm dist-tag add X@Y latest step to our GitHub Action, so that latest always matches beta for all packages in the monorepo (okay, but non-Astro dependencies are getting the -beta.1 unnecessarily. We kind of want them to be non-beta, non-pre, normal semver)

Do we? Why? It seems perfectly fine for everything to be marked with the beta version but still tagged latest.
I agree with @Andarist here that this is the part that seems undoable with how changeset works, you're either in pre-mode or not. I think being in pre-mode for everything is fine, but just with the difference of the tag being latest rather than the pre tag (beta, in this case).

This doesn't seem to go against what changeset is doing that much to me. We just want it to be the latest tag instead of the beta tag.

Maybe we could actually respect publishConfig.tag if that's a thing supported by other tools - I would love to know which tools actually support this.
This implies though that all your versions would be "preversions" - the only difference would be in the published tag.

Maybe we could actually respect publishConfig.tag if that's a thing supported by other tools - I would love to know which tools actually support this.

From what I tested, Changesets already supports this (maybe npm just forces this tag and ignores whatever tag you pass to the npm publish command).
As for other tools, I've used the same approach with lerna in the past.


WIP: major update: support TOML v0.5.0

support TOML v0.5.0
reorganize date-time classes
improve quality of error messages
add utility functions
make code cleaner and structuralized

related to #10.


Paste copied node at location you click paste

In pipeline editor you can copy and paste whole nodes including their properties, but similar to how drag drop used to work the pasted nodes will node be added where the user rights-clicks and selects paste. We should see if we can solve this.

@marthacryan the blocking canvas issue for this was just merged. We should put this back into our queue to fix, I can tackle it  next sprint if you want

Closing this issue as it's no longer reproducible. The node is pasted where user clicks paste.
Elyra version tested: v2.3.0-dev


Pin liqwid-plutarch-extra

And correct the non-exsiting rev in flake.lock.

After #113, I'll pin it too. #113 will mean M1 support, so I think it's quite important and I'm happy to fix any issues that arise when we end up bumping again.


Threadpool exec binder

Solves #22.  Until now we haven't used Binders this way. It feels like a good approach. What do you think @jkschneider ?

This work was cherry picked into 6221a6947077f7efffd515908d0b3325f9f75e8f and then substantially altered in 97e3e9aa479d638be89426b609b2670fa2c1404c to support a wider range of pooled executors.


Fixed status code 2xx to return the success? method as true

For example a status code of 204 resulted in "success?" returning false

Coverage decreased (-0.03%) to 93.24% when pulling 776edf467cd57261175afd91906e4eb5f78510ab on Student92:master into da25513e06a388f1a0e1a771ae70bc85fa319e02 on google:master.

Made obsolete by 0.9 release


Fixed TaskNodeInfo not being assigned properly for dynamic parent nodes

TL;DR
dynamicNodeTaskNodeHandler now properly modifies transition to propagate TaskNodeInfo for dynamic parent nodes.
Type

[X] Bug Fix
[ ] Feature
[ ] Plugin

Are all requirements met?

[X] Code completed
[X] Smoke tested
[X] Unit tests added
[ ] Code documentation added
[ ] Any pending items have an associated Issue

Complete description
While updating the transition of a dynamic sub-node, the ExecutionInfo (in particular the TaskNodeInfo containing metadata) about the cached outputs was not set on the handler.Transition properly (assignment/return was missing). This lead to flyteadmin not recognising the cached output for dynamic task parent nodes.
Additionally, the previous implementation dropped the OutputInfo already present on the transition.
Tests were adapted in a minimal fashion to verify the expected TaskNodeMetadata is returned on completion of sub nodes.
Tracking Issue
fixes https://github.com/flyteorg/flyte/issues/3096
Follow-up issue
NA

@MorpheusXAUT thanks for the fix here! Two questions:
(1) any idea why there are still subnodes listed for the second dynamic run (ie. cache hit)? If the dynamic task doesn't run then it shouldn't report a subworkflow back to FlyteAdmin. At least, I don't think it should be.
(2) I tried testing this locally and for some reason it's not working (ie. first run the dynamic task still does not show CACHE_POPULATED). The first run is still "cache disabled" as this should fix:

The second run works as expected:

My test workflow is
@task(cache=True, cache_version="1.0", requests=Resources(cpu="1", mem="400Mi"), limits=Resources(cpu="2", mem="600Mi"))
def cached_square(n: int) -> int:
    return n * n

@dynamic(cache=True, cache_version="1.0", requests=Resources(cpu="1", mem="400Mi"), limits=Resources(cpu="2", mem="600Mi"))
def cached_dynamic_parallel_square(a: int, count: int) -> int:
    for i in range(count):
        cached_square(n=a)
    return a

@workflow
def cached_dynamic_parallel_square_wf(a: int, count: int) -> int:
    return cached_dynamic_parallel_square(a=a, count=count)

(1) any idea why there are still subnodes listed for the second dynamic run (ie. cache hit)? If the dynamic task doesn't run then it shouldn't report a subworkflow back to FlyteAdmin. At least, I don't think it should be.

I was wondering the same, but didn't have time to investigate that yet. I can continue to do so tomorrow, I thought this might've been intentional, but I agree, it doesn't really make sense to show them, at least not in unknown state.

(2) I tried testing this locally and for some reason it's not working (ie. first run the dynamic task still does not show CACHE_POPULATED).

Odd, it worked as intended for all my test runs, but I will check out your workflow tomorrow to see if there's something I missed, thanks for the example. Will update this when I know more!

@hamersaw Strangely enough, your test workflow seems to be working as expected for me :thinking:

The first execution updated its parent node status accordingly once all child executions finished successfully.

The second execution shows the parent node as retrieved from cache, however I still have the unknown child nodes displayed...
Running locally as a single binary and the k3d cluster using the latest commit of the flyte repository (f534819) with flytepropeller replaced with this commit (replace github.com/flyteorg/flytepropeller => github.com/blackshark-ai/flytepropeller v0.16.48-0.20221123132352-14a1b00391c3).
I'll see if I can reproduce your behavior while I continue working on the cache eviction (as that includes re-running a lot of workflows anyways during testing), but I'm not sure why we're seeing different outcome here.
Will try to look into the unknown child tasks as well, however that's currently on a lower prio, at least until I can get the first version of cache eviction done and ready as a draft.


Topics header design implementation

Implements "main page" Topics view 🐯
Also includes (very related) fixes to Paginator component.

Looks good overall — a few things to clean up:

[use em for relationally positioned elements + rem for globally relationally positioned elements]
[no margin present on the categories view resulting in cats that overflow]
[refactor hard coded px widths to instead flow with element layout, add padding or margin where necessary]

@stephensprinkle Last commit addresses those concerns with special consideration for vw vs rem/em in certain cases where basing the width on the total screen width was more appropriate for layout fluidity

I ended up rolling back the flex implementation as it ended up not being as clean of an implementation.


[FEATURE] Enable custom templates

Affected project(s)

[X] documentation
[ ] examples
[ ] wasmCloud host
[X] wasmCloud CLI (wash)
[ ] wasmCloud dashboard UI (washboard)
[ ] capability providers
[ ] provider bindgen
[ ] control interface client
[ ] other / not sure

Is your feature request related to a problem? Please describe.
I'm frustrated when I go to create a new component and there isn't a template for what I want.
Describe the solution you'd like
I would like to be able to make my own templates in my project's repo or in other repos that can be used instead of the bundled ones.
Describe alternatives you've considered
I considered adding the specific templates I need to WasmCloud, but I'm not yet sure exactly what they'll be or if WasmCloud will be interested in including them.
Additional context
My specific current template needs are for a component template with

a build.rs that calls wit_deps::lock_sync()
a wit/deps dir containing a blanket ignore * file
any other setup needed to make cargo workspaces work

I suspect our needs will evolve in ways that where giving us flexibility to make our own templates will be the best approach.

So it is a bit hard to find I'll admit, but you can do this now with specific flags set on wash new component (https://wasmcloud.com/docs/cli/new). You can use the --path flag or --git flag to specify a repo manually or you can use the --favorites flag to point to a toml file with a list of all your templates (you can see an example of that file here).
It would probably be nice to add some more docs around favorites and have an environment variable you can set for that flag so it is easier to configure once

Thanks, I've filed https://github.com/wasmCloud/wasmcloud.com/issues/443 as a follow up on the docs side


timeline or to do list

@ty625911724 Great work! I want to know when will you release the code? I am eager to have a try! thanks!

Hi,  it's already July. 🥺🥺🥺

Where is the sketch data comes from?

We use this method to extract sketches. https://github.com/carolineec/informative-drawings
We will release the code as soon as possible.


(JSON / XML) Allow columns to be ignored when exporting

Allow columns to be ignored when exporting data. Possibly using prefixes or leaving the key cell blank.

Columns with empty key cells are now ignored when exporting data.


Use AddOrUpdateSystemResource as the reseocue may already be set

This is a fix for an issue where one cannot change the Theme to the CurrentSystemTheme after startup
If you need more info or a ticket first, let me know
Happy coding
Tim

I'm away right now, so it won't be until probably this weekend that I can look at this more, but what was the exact issue that was leading to the exception being thrown?

Don't worry. I opened a ticket with full stack trace. btw: I think this is also totally valid for adding or updating:
Resources["MyKey"] = "Abc"; // Add
Resources["MyKey"] = "Def"; // Update

Have a great time
Tim

fyi: Found another potentially bug which I pushed a fix for also.


Support Sprockets 3

Adds support for sprockets 3. Not much needs to change, really.

Thanks for the PR!


Update docstrings

Description:
Preparation for #7357.
Checklist:
If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass

I'd like us to decide if we should have double quotes on all log strings or not. It's not part of PEP8 as far as I know but if home assistant makes it its standard we can all follow that. Either we make it standard or we should stop changing it. I've been following whole module consistency, but not whole project consistency. I don't care what we decide, but we need to have a standard to follow.

I would prefer if we keep cleanups to the minimum necessary to get the upgrade of pydocstyle or pylint going. By updating other code, we can a) introduce bugs and b) mask author of code in git blame

I would prefer if we keep cleanups to the minimum necessary to get the upgrade of pydocstyle or pylint going.

Me too but as I needed to edit almost every file it was only efficient to update the most obvious and minor  things we want have changed in PRs like string formatting and the removal of blank lines or update of comments was a side effect.
People will always have a different opinions about quotes, style, line length, init systems, or what every. To come back to the log messages and the quotes: The most used style won. As it's perhaps not the best/smartest/nicest way to do it but now it's on the way to be consistent across the whole code.
The format of the log messages is a different topic and for another day. It wouldn't harm to have a more uniform style as we know for sure that people are feeding the log to their tools.

Ok, I collected the things which always lead to discussions and create a page with details about the style.

As I don't know where this would be best discussed, just adding my last comment regarding to the quote styling. Having two types of quotes makes it very hard to keep it consistent on the long run if the content of those variables may live (e.g. are not just constants). If this is to be enforced it would be nice to describe in the style guide why it makes sense to do so.
P.S. about the quotations in log messages, using them makes it (in my opinion) easier, not harder to parse for both people and with regular expressions. A fully structured logging format would be the best but it may be hard to pull consistently.
P.P.S. In the file header example, "For more details about this platform, please refer to the documentation at" crosses the line length limit of 72 for docstrings as defined in PEP8.
Just my 0.02e :-)

Good with the page. In my opinion mixing single and double quotes and having different style depending on the length of the string, makes for a harder to follow style. I'd prefer it to be clear and simple. Eg either use single quotes  in whole module or double quotes in whole module.

I agree with @fabaff , thanks for adding the page 👍


data-size, data-min-size, ... should work as size, min-size, ...

As self explanatory as you feel your title may be, it would be far more constructive if you posted an issue fully describing what you think is broke, or how you think things should be different.

Plunker to reproduce: http://plnkr.co/edit/eBmiZqARspptaTD3wMgT?p=preview

Cool, I'm working on this one!


headerBackTitle not working

For me the screen navigation options headerBackTitle and headerTruncatedBackTitle are not working with  RN 0.43.1.
The related code:
export default StackNavigator({
	Example: {
		screen: ExampleScreen,
		navigationOptions: ({navigation}) => ({
			headerBackTitle: 'Back',
			headerTruncatedBackTitle: 'Back',

Any ideas?

headerBackTitle and headerTruncatedBackTitle are used to describe back button that points to this scene.
That means, you will see your changes taking place when you push something on top of Example. Back button will then display Back.

@grabbou of course it does. Sorry, my fault :/

Do you think there's anything we could improve in docs to make it clearer?

Actually it should be clear but I was confused since all the other options are related to that particular scene.

Like @grabbou I expected this to relate to the current scene.  I think the docs should at least say something about it applying to headers navigated to from the current scene, not the scene itself.

I am with you, that would have saved me some time as well ;)


kernel: focal/lts 5.4.0

Ubuntu has released Focal Fossa. We should pick up their kernel and make that the default.

Supersedes #469


Try out dependency-review-action

There have been a number of high-profile supply chain attacks or issues in the NPM ecosystem, either due to packages being compromised by an attacker or sabotaged by their maintainer e.g:

node-ipc
faker/colors
coa
rc
ua-parser-js
eslint-config-eslint/eslint-scope
event-stream
etc

Shields has mercifully not been directly affected by any of these, but this is more through luck than judgement. Like most javascript projects with a large dependency tree we simply don't have enough hours in the day to fully review every dependency bump. One potentially exciting project in this field is Socket.dev, but its early days for that.
In a similar nitch, but attacking the problem from a different angle, Github have recently released this more fully formed action aimed at flagging dependency bumps with known issues.
Further reading:

https://github.blog/2022-04-06-prevent-introduction-known-vulnerabilities-into-your-code/
https://github.com/actions/dependency-review-action
https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review

I have not played with this at all yet, but I'm going to suggest we enable it ahead of this weeks barrage of dependency bumps (but lets not make it a requirement for merging just yet) and try it out.

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @chris48s!

  Generated by :no_entry_sign: dangerJS against 1c4df8f53ba813d5cb213cc5079ac4a8ae6f6ac8

I certainly don't think it hurts, and am happy to pull it in. I do, however, question the efficacy of GitHub's solution in the presence of regular dependency updates. I suppose it could still help catch some issue stemming from older transitive deps?
I.e. I assume that 99% of the time during dependency updates that any issues haven't actually been discovered and reported yet

Going to go ahead and merge as well, and then let Dependabot rebase this weeks bumps to pull it in

Yeah I kind of agree with you. I think there's more mileage in the socket approach long-term which is aiming to be proactive rather than reactive. The one thing we have going for us is we update weekly rather than daily, so if something like this does happen we may be just far enough behind the curve to benefit from this in some cases.
I feel like the sweet spot for package updates is to be updating fast enough that you're ahead of the attackers trying to exploit vulnerabilities but slow enough that if there's a supply chain attack, someone else notices it before you do :laughing:


Translate json or any file

now only english and zn-cn so..
need to build if i wanna translate.
I hope any translate outfile

https://github.com/zaigie/palworld-server-tool/tree/main/web/src/assets
Just make a pr for your language, and the i18n of vue may do the rest.

any help document for build this?

any help document for build this?

See gh actions

about pal type&skill, you need to add like zhPalTypes.json and zhPalSkills.json
about webui, see i18n.js


Add Skype meeting's(14.02.2018) notes to the Meeting 2

Add to meeting 2's own page.

I added Skype meeting's notes and gived a reference to side bar.


AutoPr-CognitiveServices.Personalizer-dwaijam-REST Spec PrNumber 5892

Duplicate of https://github.com/Azure/azure-sdk-for-net/pull/6196


Publish 12/03/2019 3:31 PM PST

Docs Build status updates of commit fa4dc62:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Fix pickup actor replication

Pickup actors replication and update pickup state need to be fixed.

Fixed in commit 7b2a34f6f65e319c7fad5e0dad053912b156c059.

Improved in commit 1ef835331e9982f29ca1068ad1063edf3331c0a7.


Insert Sort algorithm in Golang

Can this be assigned to me? Also, are there any contributor guidelines that I need follow? Thanks. :)

work in progress.....


Gift Entry Payments: add 'Do Not Charge Card' feature

Critical Changes
Changes
Issues Closed
Community Ideas Delivered
New Metadata

Custom Labels

geBodyPaymentNotProcessingPayment
geButtonPaymentAlternate
geButtonPaymentDoNotCharge

Deleted Metadata

**lurch: attach W-040601

Tracking W-040601


Bug: Freezes/Crashes on OSX after ~1hr

GPMDP quits, screen goes black and music stops after ~1 hour of play.
OS:
OS: OSX 10.10.5 Yosemite
MBP Mid-2015 15" with Intel Iris Pro 1536 MB graphics
GPMDP: 3.3.0
Issue Descriptions:
Today (1 August 2016) is the first day that I have noticed this issue. The music player will go black and stop playing music after ~1hr of playback. This occurs while listening to a station, in my case "Today's Biggest Hits." The app works fine after quitting and restarting.
Steps to Reproduce:
In my case, playing the "Today's Biggest Hits" station will trigger the bug after ~1hr of playing in the background while I am doing other things.
I do not cast to an external speaker.
I realize this bug is likely due to a hard-to-find memory leak or something of its ilk, but want to bring it to your attention and err on the side of over-reporting. Thanks for packaging the app - it's pretty handy.

Fixed in Electron 1.3.x
This was an upstream Chromium GFX bug. 👍

I'll push a release at the weekend probably 👍


Correcting error handler in Export-ADHuntingACLDefaultFromSchema funct

Small PR to correct error handling not displaying the default SD for Schema objects when the parsing function fails.
Before:

After:

Hey Fana!
Thank you for the PR, merging :)


Add NFS path check for default deepspeed triton cache directory

This PR adds explanation and guidance for users whose default caching dir is on a NFS.
Ref: https://github.com/microsoft/DeepSpeed/issues/5205

cc @tjruwase

Hi @HeyangQin the warning seems printing repeatedly, could it be made single time print so there is only one warning which is enough?
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
[2024-03-31 22:50:11,901] [INFO] [launch.py:348:main] Process 435006 exits successfully.
[2024-03-31 22:50:11,901] [INFO] [launch.py:348:main] Process 435015 exits successfully.
[2024-03-31 22:50:11,901] [INFO] [launch.py:348:main] Process 435009 exits successfully.
[2024-03-31 22:50:12,902] [INFO] [launch.py:348:main] Process 435012 exits successfully.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.
Warning: The default cache directory for DeepSpeed Triton autotune, /home/gma/.triton/autotune, appears to be on an NFS system. While this is generally acceptable, if you experience slowdowns or hanging when DeepSpeed exits, it is recommended to set the TRITON_CACHE_DIR environment variable to a non-NFS path.


Valid TXT records may contain binary data

The parser insists that the content of a valid TXT record be UTF8, but it ain't necessarily so.

RFC 1035 talks about "character-string"s without, so far as I can see, ever spelling out what a "character" actually is

(I'd have guessed that the intention was printable ASCII)

RFC6763 (DNS service discovery, which makes use of TXT records) is explicit, though.  See section 6.5:

The value is opaque binary data.  Often the value for a particular attribute will be US-ASCII [RFC20] or UTF-8 [RFC3629] text, but it is legal for a value to be any binary data.

 The earlier we fix it the better. Would you like to make a PR?

This is something-I-noticed rather than something-I-need.  So if you - or anyone else! - would like this sorted sooner rather than later, then please don't wait on me.
But if you're content for this to happen whenever the mood takes me, which probably it eventually will, then sure.

Fixed in #31


Enforce correct SD state at compilation using a new type

The struct SdMmcSpi had two separate methods for initialization and deinitialization. It was up to the user not to mess them up at runtime.
A new BlockSpi struct takes over BlockDevice interface duties, making it impossible to use block procedures while the SD interface is in the wrong state.
I'm not 100% sure which methods should go to which interface, because that doesn't matter a lot for private ones.
I haven't updated the README or examples. I haven't tested how it works with the Controller (not interested in the file system right now).
The change in the API is breaking, but easy: instead of doing this:
let sd = SdMmcSpi::new(...);
let controller = Controller::new(sd);
controller.device.init();

now you do this:
let mut sd = SdMmcSpi::new(...);
let block = sd.acquire();
let controller = Controller::new(block);

The block device is deinitialized when dropped.

I cargo fmted this.

I rebased to get rid of the extra commits and removed the "RFC" to reflect that.

Rebased and fixed tests.

Oh sorry, one thing - is the README now wrong?
Maybe we should compile-check the README...

Also the Changelog in the README. We can do this separately if you want, as long as we don't leave it too long.

Pinging @dcz-self - sorry we took so long to get back to you!


Properly move over DLLs

This PR fixes an issue reported in #233 where dlls were not being properly moved over from the nuget directory to the debug and release directories. The issue was that we were looking for targets in the form of win-$ARCH instead of win10-$ARCH.
Additionally this improves logging by adding a --verbose flag which can help with simply debugging.

@rylev, I tested this branch and can confirm that it does sym link the Microsoft.UI.Xmal.dll into target/debug.  However for:
[package.metadata.winrt.dependencies]
"Microsoft.VCRTForwarders.140" = "1.0.6"

I now get an empty target/nuget/Microsoft.VCRTForwarders.140 directory.

writing dll file "win10-x64\release\vcruntime140_app.dll" into C:\Users\joe\workspace\win_ui\target\nuget\Microsoft.VCRTForwarders.140
not creating symlink for win10-x64\release\vcruntime140_app.dll because of differing architecture to host architecture

I'm not sure what the intended behavior is in this case, but the version in master would download VCRTForwarders and extract the files to target/nuget/Microsoft.VCRTForwarders.140
One other nit.  "Fetching" is repeated:

cargo winrt install
Fetching: fetching Microsoft.UI.Xaml
Fetching: fetching Microsoft.VCRTForwarders.140

@joekgh it seems that that nuget package differentiates between debug and release... I'll have to put in special logic for that.

@joekgh can you give this branch another try? I think it should work now when dlls are inside release directories.

@rylev, it now works as expected.  Thanks.


Add gas limit to Operation in contracts

What is this PR doing?
Adding a gas limit parameter to operations (protects against aggregator griefing attacks and under-payments)
How can these changes be manually tested?
Does this PR resolve or contribute to any issues?
#446
Checklist

[x] I have manually tested these changes
[x] Post a link to the PR in the group chat

Guidelines

If your PR is not ready, mark it as a draft
The resolve conversation button is for reviewers, not authors

(But add a 'done' comment or similar)

Had targeted main initially hoping the local client + agg updates+tests would translate to CI success, and not need the intermediate branch.


[Doc] Update Helm chart instructions to avoid UX friction when using Kind

Proposed changes

For kind clusters, NodePort services require extra configuration and LoadBalancer services need a third-party controller like MetalLB for external IP assignment. However, the Helm chart creates a LoadBalancer service by default. Therefore, the --wait flag will hang until timeout.
The guide running-on-kind.md asks users to create a Kind cluster by running the make create-kind-cluster command. However, the command neither sets the extraPortMappings Kind configs nor installs MetalLB, so users cannot use NodePort and LoadBalancer directly after running the command.
This PR suggests users disable the creation of NodePort / LoadBalancer Kubernetes service, and uses the port-forwarding command from the running-on-kind.md guide.
Checklist
Before creating a PR, run through this checklist and mark each as complete.

[ ] I have read the CONTRIBUTING doc
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked that all unit tests pass after adding my changes
[ ] I have updated necessary documentation
[ ] I have rebased my branch onto main
[ ] I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Sorry, I did not notice the presence of a pre-commit configuration. I have now fixed the linting error.

@kevin85421 We're about to migrate our docs a little bit in the next day or two, so we'll wait to rebase your change on the new structure before we look at merging it.

Just out of curiosity, what's the reason for using LoadBalancer as the default service instead of ClusterIP? Based on my observation, the L4 load balancing seems to be less popular in the Kubernetes community. Thanks!

@kevin85421 Our docs have now been migrated if you want to rebase. The kind document now lives at /site/content/installation/running-on-kind.md. Please format the note as {{<note>}}your text{{</note>}}, instead of using ">".

@kevin85421 The main use case of NGINX Gateway Fabric is to get traffic into a cluster, using it as an ingress point. ClusterIP Services are for traffic within the cluster network, whereas the LB Service is for getting traffic into the cluster from an outside source.

Thank @sjberman for your reply! Recently, I have begun delving into more details about Kubernetes networking to enhance support for Ray Serve on Kubernetes (KubeRay). Therefore, some of my questions might be basic.
I've come across numerous articles and videos (example) that compare the Kubernetes LoadBalancer service (OSI L4) and Ingress/Gateway (OSI L7) as alternatives. Hence, this makes me feel a bit puzzled when they are presented simultaneously.
Based on your reply, I guess:

Kubernetes LoadBalancer Service: Each application running on the Kubernetes cluster requires its own LoadBalancer, which can be expensive.
Ingress/Gateway: With Ingress/Gateway, users only need to create a LoadBalancer for the Ingress/Gateway controller. This controller can then forward requests to multiple applications within the Kubernetes cluster.

Is my understanding correct? Thanks!

I have already updated the PR. I will figure out how to build the doc locally.


Application IAM roles ignored?

I have this at the end of the configure block in application.rb:
config.iam_policy = [
  *Jets::Application.default_iam_policy,
  {
    action: ["dynamodb:*"],
    effect: "Allow",
    resource: "arn:aws:dynamodb:#{Jets.aws.region}:#{Jets.aws.account}:table/#{Jets.project_namespace}-*",
  }
]

Yet this seems to have no effect on the IAM policy/roles that actually ends up on AWS. The policy created on AWS seems to be just the default IAM policy.
Am I doing something wrong or is this feature not working as intended?

@matiaskorhonen  Thanks for the report.

RE: Am I doing something wrong or is this feature not working as intended?

This was a bug. Fixed in #69 Released in v1.0.16 Changelog
Also updated the IAM Policies docs to include a section on "Application-wide: Override but Keep Default"


error: failed to run custom build command for steamworks-sys v0.7.0

I have followed the instructions for the requirements. I'm not sure what i'm doing wrong.

I believe the problem has come from not installing steamworks correctly. My env is linux 64bit and I have run the setup.sh script that came in the steamworks/sdk/tools/ folder. Is it installed now? Do I need to build something with clang? Which folder do I set the env var to?

Hello
After extracting the SDK zip archive from the steamworks page the resulting folder should be just called sdk/. You can point to the right directory with the command $ export STEAM_SDK_LOCATION=$HOME/Downloads/sdk (assuming you unzipped the sdk to the Downloads directory).
After this (and possibly a cargo clean) everything should work seamlessly. If you have more trouble, please post the full error message and I'll look closer.

Hello
After extracting the SDK zip archive from the steamworks page the resulting folder should be just called sdk/. You can point to the right directory with the command $ export STEAM_SDK_LOCATION=$HOME/Downloads/sdk (assuming you unzipped the sdk to the Downloads directory).
After this (and possibly a cargo clean) everything should work seamlessly. If you have more trouble, please post the full error message and I'll look closer.

This was actually the first thing I tried but no dice.

Solved in DM's; The build problems were caused by the SDK location env var being incorrect. Make sure it points to the sdk/ path if you encounter a similar issue


ruby-lsp (0.20.1) fails to start due to not finding gem that is bundled in project (using rbenv 1.3.0)

Description
Ruby LSP Information
✅  latest ruby lsp vs code extension (v0.8.8)
✅  latest ruby-lsp (0.20.1)
✅  latest VS Code (1.94.2)
See issue below after debug output (ruby-lsp refuses to start, complaining about the csv gem not being installed, even though the gem is bundled by the project's Gemfile)

VS Code Version
1.94.2
Ruby LSP Extension Version
0.8.8
Ruby LSP Server Version
Unknown
Ruby LSP Addons
Ruby Version
3.3.2
Ruby Version Manager
rbenv
Installed Extensions

Click to expand

shades-of-purple (7.3.2)
vscode-theme-onedark (2.3.0)
vscode-erb-beautify (0.5.0)
insert-line-number (1.0.1)
format-json (1.0.3)
vscode-ruby-test-adapter (0.9.2)
vscode-markdownlint (0.56.0)
vscode-eslint (3.0.10)
githistory (0.6.20)
vscode-html-css (2.0.10)
EditorConfig (0.16.4)
vscode-great-icons (2.1.108)
prettier-vscode (11.0.0)
git-project-manager (1.8.2)
vscode-firefox-debug (2.9.10)
auto-rename-tag (0.1.10)
vscode-pull-request-github (0.98.0)
todo-tree (0.0.226)
vscode-test-explorer (2.22.1)
rails-fast-nav (1.3.6)
vscode-insertdatestring (2.3.1)
solidity (0.0.179)
karma-test-explorer (0.8.2)
rainbow-csv (3.12.0)
vscode-docker (1.29.3)
debugpy (2024.12.0)
python (2024.16.1)
vscode-pylance (2024.10.1)
remote-containers (0.388.0)
test-adapter-converter (0.2.0)
sqltools (0.28.3)
sqltools-driver-pg (0.5.4)
color-highlight (2.8.0)
javascript-test-runner (0.2.0)
fix-json (0.1.2)
material-icon-theme (5.11.1)
heroku-command (0.0.8)
vscode-data-preview (2.3.0)
vscode-commons (0.0.6)
vscode-xml (0.27.1)
vscode-yaml (1.15.0)
LiveServer (5.7.9)
ruby-lsp (0.8.8)
vscode-fileutils (3.10.3)
vscode-zipexplorer (0.3.1)
todo-list (1.6.0)
vscode-lldb (1.11.0)
vim (1.28.1)
vscode-todo-highlight (1.0.5)
json (2.0.2)

Ruby LSP Settings

Click to expand
Workspace
{}

User
{
  "enableExperimentalFeatures": false,
  "enabledFeatures": {
    "codeActions": true,
    "diagnostics": true,
    "documentHighlights": true,
    "documentLink": true,
    "documentSymbols": true,
    "foldingRanges": true,
    "formatting": true,
    "hover": true,
    "inlayHint": true,
    "onTypeFormatting": true,
    "selectionRanges": true,
    "semanticHighlighting": true,
    "completion": true,
    "codeLens": true,
    "definition": true,
    "workspaceSymbol": true,
    "signatureHelp": true,
    "typeHierarchy": true
  },
  "featuresConfiguration": {},
  "addonSettings": {},
  "rubyVersionManager": {
    "identifier": "rbenv"
  },
  "customRubyCommand": "",
  "formatter": "auto",
  "linters": null,
  "bundleGemfile": ".ruby-lsp/Gemfile",
  "testTimeout": 30,
  "branch": "",
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "",
  "indexing": {},
  "erbSupport": true
}

which ruby
/Users/jm3/.rbenv/shims/ruby

which bundler
/Users/jm3/.rbenv/shims/bundler

bundle exec irb
ruby version: ruby 3.3.2 (2024-05-30 revision e5a195edf6) [arm64-darwin23]
irb(main):001> Bundler.settings["path"]
=> nil

ls ~/.gemrc
ls: /Users/jm3/.gemrc: No such file or directory

rbenv local
3.3.2

grep ruby-lsp Gemfile
  gem 'ruby-lsp'

Issue:
ruby-lsp refuses to start, complaining about the csv gem not being installed, even though the gem is bundled by the project's Gemfile
grep csv Gemfile
gem 'csv'

bundle list |grep csv
  * csv (3.3.0)

bundle show csv
/Users/jm3/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/csv-3.3.0

Ruby LSP> Skipping custom bundle setup since /Users/jm3/Code/bright-moments/api/.ruby-lsp/Gemfile.lock already exists and is up to date
Ruby LSP> Running bundle install for the custom bundle. This may take a while...
Ruby LSP> Command: (bundle _2.5.21_ check || bundle _2.5.21_ install) 1>&2
The Gemfile's dependencies are satisfied
Could not find csv-3.3.0 in locally installed gems
Run `/Users/jm3/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/bundler-2.5.21/exe/bundle install` to install missing gems.

bundle exec ruby-lsp
Could not find csv-3.3.0 in locally installed gems
Run `/Users/jm3/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/bundler-2.5.21/exe/bundle install` to install missing gems.

/Users/jm3/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/bundler-2.5.21/exe/bundle install
Bundle complete! 14 Gemfile dependencies, 91 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

Project is a rails app, if that matters:

Click to expand Gemfile
BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle list
Gems included by the bundle:
  * actioncable (<IP_ADDRESS>)
  * actionmailbox (<IP_ADDRESS>)
  * actionmailer (<IP_ADDRESS>)
  * actionpack (<IP_ADDRESS>)
  * actiontext (<IP_ADDRESS>)
  * actionview (<IP_ADDRESS>)
  * activejob (<IP_ADDRESS>)
  * activemodel (<IP_ADDRESS>)
  * activerecord (<IP_ADDRESS>)
  * activestorage (<IP_ADDRESS>)
  * activesupport (<IP_ADDRESS>)
  * ast (2.4.2)
  * base64 (0.2.0)
  * bcrypt (3.1.20)
  * bigdecimal (3.1.8)
  * bootsnap (1.18.4)
  * brakeman (6.2.2)
  * builder (3.3.0)
  * byebug (11.1.3)
  * coderay (1.1.3)
  * concurrent-ruby (1.3.4)
  * connection_pool (2.4.1)
  * crass (1.0.6)
  * csv (3.3.0)
  * date (3.3.4)
  * debug (1.9.2)
  * dotenv (3.1.4)
  * drb (2.2.1)
  * erubi (1.13.0)
  * globalid (1.2.1)
  * i18n (1.14.6)
  * io-console (0.7.2)
  * irb (1.14.1)
  * json (2.7.2)
  * jwt (2.9.3)
  * language_server-protocol (<IP_ADDRESS>)
  * logger (1.6.1)
  * loofah (2.22.0)
  * mail (2.8.1)
  * marcel (1.0.4)
  * method_source (1.1.0)
  * mini_mime (1.1.5)
  * minitest (5.25.1)
  * msgpack (1.7.3)
  * net-imap (0.5.0)
  * net-pop (0.1.2)
  * net-protocol (0.2.2)
  * net-smtp (0.5.0)
  * nio4r (2.7.3)
  * nokogiri (1.16.7)
  * parallel (1.26.3)
  * parser (<IP_ADDRESS>)
  * pg (1.5.8)
  * prism (1.2.0)
  * pry (0.14.2)
  * pry-byebug (3.10.1)
  * psych (5.1.2)
  * puma (6.4.3)
  * racc (1.8.1)
  * rack (3.1.8)
  * rack-cors (2.0.2)
  * rack-session (2.0.0)
  * rack-test (2.1.0)
  * rackup (2.1.0)
  * rails (<IP_ADDRESS>)
  * rails-dom-testing (2.2.0)
  * rails-html-sanitizer (1.6.0)
  * railties (<IP_ADDRESS>)
  * rainbow (3.1.1)
  * rake (13.2.1)
  * rbs (3.6.1)
  * rdoc (6.7.0)
  * regexp_parser (2.9.2)
  * reline (0.5.10)
  * rubocop (1.67.0)
  * rubocop-ast (1.32.3)
  * ruby-lsp (0.20.1)
  * ruby-lsp-rails (0.3.20)
  * ruby-progressbar (1.13.0)
  * securerandom (0.3.1)
  * sorbet-runtime (0.5.11610)
  * stringio (3.1.1)
  * thor (1.3.2)
  * timeout (0.4.1)
  * tzinfo (2.0.6)
  * unicode-display_width (2.6.0)
  * useragent (0.16.10)
  * webrick (1.8.2)
  * websocket-driver (0.7.6)
  * websocket-extensions (0.1.5)
  * zeitwerk (2.7.1)
Use `bundle info` to print more detailed information about a gem

BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle check
The Gemfile's dependencies are satisfied

???
Issue seems like it may be related to how rails (7.2.1) bundles — when I create a new test rails app, the same issue is reproducible: ruby-lsp fails to start, complaining about a missing (bundled) gem, in this case, rubocop-rails-omakase.

Thank you for the bug report!
In your Ruby LSP settings, I noticed that you're setting the bundleGemfile to point to our composed bundle in the .ruby-lsp directory. Can you try removing that setting? That setting is only intended for using a separate Gemfile for development tools. If you want to use the Ruby LSP's composed bundle, then it's better to let the Ruby LSP manage it.
Also, do you happen to have any rbenv, Rubygems or Bundler settings in shell scripts?

Weird — removing the project's Gemfile.lock and re-generating it via bundle install fixed it. Notably, this removed the following from the project's Gemfile.lock seems to have changed. I presume these are part of the default Rails / Gemfile.lock as I'm not running linux.
 PLATFORMS
   aarch64-linux
-  aarch64-linux-gnu
-  aarch64-linux-musl
   arm-linux
-  arm-linux-gnu
-  arm-linux-musl
   arm64-darwin
   x86-linux
-  x86-linux-gnu
-  x86-linux-musl
   x86_64-darwin
   x86_64-linux
-  x86_64-linux-gnu
-  x86_64-linux-musl

The part that's extremely odd to me is, putting the old Gemfile.lock back makes no difference — ruby-lsp now runs without issue with either the older or the newer Gemfile.lock.

The Ruby LSP uses a composed bundle that is auto managed to avoid having people need to add ruby-lsp to their project's dependencies and to deliver auto updates.
It's likely that the composed lockfile (.ruby-lsp/Gemfile.lock) got into a bad state. One example of what might have happened is that Bundler had a bug recently that caused bundle check to mutate the lockfile and sometimes point to the wrong gem source.
When you change the project's lockfile, the Ruby LSP re-generates the composed bundle from scratch to ensure that we're matching all dependencies properly, so that's probably what fixed it.
I'll close the issue since the problem went away, but please let us know if you hit any issues again or if you uncover the root cause.

Sure, though I don't think I explicitly changed that setting. Is it possible it got changed by the extension due to my testing opening code from various directories in / outside of my project?

We don't mutate that setting and the default is an empty string. Not sure why it's showing .ruby-lsp/Gemfile. If you have anything in your JSON settings, remove that one.

yes, in my .zshrc (or technically, in a file that my .zshrc sources, I have:

That should be fine, you're just sourcing the version manager. The reason I asked is because sometimes users have the expectation that setting environment variables in their shell scripts will somehow affect VS Code's extension host process, which is not the case.

Seems to recur with any new empty rails app, tho, even outside / irrespective of VS Code:
rm -rf .ruby-lsp

ruby-lsp
Ruby LSP> Running bundle install for the custom bundle. This may take a while...
Ruby LSP> Command: (bundle _2.5.21_ check || bundle _2.5.21_ install) 1>&2
Resolving dependencies...
The Gemfiles dependencies are satisfied
Could not find ruby-lsp-rails-0.3.21, sorbet-runtime-0.5.11611 in locally installed gems
Run `/Users/jm3/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/bundler-2.5.21/exe/bundle install` to install missing gems.

bundle
Bundle complete! 16 Gemfile dependencies, 98 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

cat .ruby-lsp/Gemfile
# This custom gemfile is automatically generated by the Ruby LSP.
# It should be automatically git ignored, but in any case: do not commit it to your repository.

eval_gemfile(File.expand_path("../Gemfile", __dir__))
gem "ruby-lsp", require: false, group: :development
gem "ruby-lsp-rails", require: false, group: :development%


Makefile in /sim with config.h

Currently typing make won't evoke config.h in the /sim directory

Issue statement does not make any sense. Closing.


Process New Commits

When new commits are pushed, a PushEvent is generated with a list of commits.
Currently the commits are not queued which results in missing commits:
  PushEvent(request) {
    let [document] = this._addEventBasics(request);
    // TODO figure out what to do with the commits
    return document;
  }

See update_events function for implementation details.

Resolved by https://github.com/Microsoft/ghcrawler/pull/91


modify maxmemocharlength

closes: #5428

Codecov Report
Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (7c48b96) 80.12% compared to head (e369b1b) 80.10%.
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5442      +/-   ##
==========================================
- Coverage   80.12%   80.10%   -0.02%
==========================================
  Files         189      189
  Lines       13140    13143       +3
==========================================
  Hits        10528    10528
- Misses       2199     2202       +3
  Partials      413      413

Files
Coverage Δ

...odules/apps/27-interchain-accounts/types/packet.go
92.85% <ø> (ø)

modules/apps/29-fee/types/ack.go
0.00% <0.00%> (ø)


Suggestion: implement redirect preserving Farside in browser history

Oftentimes services like Bibliogram are locked out by the original service because of excessive traffic from a single IP. Farside could help more in this case if you could easily retry with another service. A suggestion would be to have the (e.g.) https://farside.link/service/... link in the browser history, so that if you get an error with the first instance you get redirected to, simply pressing the Back-button will bring you back to Farside and another instance is tried immediately.
I don't have any experience with Elixir, but perhaps something client-side using either HTML <meta http-equiv="refresh" content="0; url=https://example.com/"> or JavaScript history.pushState() would do the trick.
The browser would then also be prevented from caching the request (or local JavaScript should redo the instance request to the server), otherwise you'd get the same instance.

Well the main goal of Farside is to ensure that any instance that the user is forwarded to is working beforehand, which is why the instances are checked every 5 mins for availability/successful results.
That being said, I do agree that being able to navigate back and go to a new instance would be useful, especially in the case where an instance goes down between updates. I'll try to get to that soon.

...to ensure that any instance that the user is forwarded to is working beforehand...
That would obviously be best, but it doesn't seem to work reliably for Bibliogram instances.

So yeah, thanks for looking into this, would be a great addition!

That would obviously be best, but it doesn't seem to work reliably for Bibliogram instances.

Yea

So I've looked into this a little bit more, and am unsure about the best way to move forward.
The http-equiv="refresh" ... approach doesn't actually seem to preserve the page (at least not from what I noticed in my testing), and I'd rather not come up with a Javascript solution since it would break functionality for anyone who has Javascript blocked by default.
My thought is to either A) investigate why Bibliogram instances seem particularly prone to being limited, and figure out if there's a better way to treat these instances within Farside, or B) proxy the connection to individual instances through Farside, and fetch a new instance if the user refreshes while viewing an instance through the Farside proxy.
I'm personally leaning more towards A, but I'm not sure how much special treatment should be given to individual services like that. I could increase the frequency with which instance lists are queried for availability, but that puts a little bit of additional stress on instances (although tbh querying for one page per instance isn't anything excessive).
That being said, if I've overlooked something with the client side redirecting approach, please let me know. I have a working example of the http-equiv redirect, but like I said, it doesn't seem to actually be pushed into browser history. I did find this bug report supporting this finding, but it's 20 years old now and could be out of date.

You're right, even with a non-zero timeout. It's not like that in the specs AFAIK, but apparently browser do have it implemented like that: no history preservation.
I agree that proxying would be the last result.
I see more and more bibliogram instances that put on their own restriction for end users via quota (see e.g. "Quota left: 24" at the lower left of the page), which is something farside wouldn't be able to handle server-side anyway (it's based on the end user's IP when making the request to the instance), so it would still be great to have this. Perhaps an optional URL parameter or something like farside.link/bibliogram/r/user/xxx (adding /r/ for redirect), which would use JavaScript to redirect, could be an action?

That's a great idea. I just implemented that approach and opened a PR, let me know your thoughts and I'll merge!

Apart from the HTML/JavaScript, I can't really read the code, but if it works as advertised, I think it sure looks like an elegant solution 😃

Ooh just one thing,  /r/ is also used by Reddit, of course, so is would it become farside.link/r/teddit/r/topic now, or farside.link/teddit/r/r/topic? Obviously the first would be better.

It would be the first one -- the URL format for preserving history would be farside.link/r/<service>/<path>.
That being said, I guess it still is a little bit confusing, but I'm not sure of any better solution. I think I'll go ahead and merge for now, and can always change it later if anyone finds the path prefix to cause confusion.

Agreed! /_/ is also easier to spot in the URL.
I think it's a nice option, primarily because it's not necessary for every service that's supported. This implementation allows the user to cherry-pick.