Review/connormcgowan/nicksparkman

Comments for Connor's code.

All of the suggestions added in this pull request are good. As noted, my tests have some redundancy that could be factored out, some edge cases that should be tested for, and could do with more comments. However, the pull request contains a file in the .idea directory that I do not think should be there, as that directory is for IDE specifics and I'd rather not run the risk of disrupting my development environment. Given that, and the fact that the changes are just comments, I will close this request while noting the changes recommended for future refinement.


Enable nested comments support for ClickHouse

I didn't find a switch to turn on nested support in preference, so I guess ClickHouse plugin should be enhanced like this one.
I use below SQL for testing, and the highlight is correct when connecting to PostgreSQL but not ClickHouse.
select /*0/*1*/2*/3

thanks for the suggestion.
Hope it will be implemented in the nearest future

Hello @zhicwu,
I don't think ClickHouse supports nested comments.
Also, I can't find any mentions about it in the documentation:
https://clickhouse.tech/docs/en/sql-reference/syntax/#comments

@ShadelessFox, it does support nested comments. Taking latest LTS version as an example:
$ docker run --rm -it yandex/clickhouse-server:21.3 bash
root@af378ffcfa30:/# /entrypoint.sh >/dev/null 2>&1 &
[1] 45
root@af378ffcfa30:/# clickhouse-client
ClickHouse client version <IP_ADDRESS> (official build).
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 21.3.12 revision 54447.

af378ffcfa30 :) select /*0/*1*/2*/3

SELECT 3

Query id: 75ad2e5a-dbe8-4241-a168-d7af2ec084b1

┌─3─┐
│ 3 │
└───┘

1 rows in set. Elapsed: 0.002 sec.

af378ffcfa30 :)

Huh, perhaps our QA database is a bit outdated (ClickHouse <IP_ADDRESS>).
Thanks for quick response!

Thanks @ShadelessFox, please consider to update database to 21.3. Also you guys may want to revisit ClickHouse support - there's a timezone issue but let me enhance its JDBC driver first :p
Update: the feature was introduced in ClickHouse/ClickHouse#14655.

verified


feat(row) Limit row for performance enhancement

Add a plugin to limit the row display on the gantt

Thanks henkensm ! I still did not read implementation details, but it seems interesting and adding a row filtering for performance was in the TODO.
I think it should be rewritten into the core, without making it a plugin. Entry point is here, in rowsManager.factory.js#L315.
Also, build must pass. Run grunt, it check with jshint and runs unit tests.

Coverage increased (+0.68%) to 57.11% when pulling 33bb5dc2a3cb87f36a5bc06dac5cd620158ef168 on henkensm:row-limit-plugins into d1efeec7d692ad932fc2146b8577b10ea94aec3e on angular-gantt:master.


Raspberry PI 2 support

Hi there,
I can't found instructions and image for Raspberry Pi 2 model

@mtuxpe Please take a look at our pi2 image release:
https://github.com/google-coral/edgetpu-platforms/releases/tag/c1.9.2


[bug] Update kubernetes.json

added and operator
Summary
Added and operator which seems to be missing from a NRQL query.
Currently, adding this dashboard returns an error, this PR aims to fix that:

Duplicate of https://github.com/newrelic/newrelic-quickstarts/pull/2061


Bcbio engine dies error

Hello!
The same pipeline I posted about before has failed. (The LSF-based Orchestra cluster was retired so I . had to switch and run this job on O2) Just as a refresher here is the command I submit:
#!/bin/bash
#SBATCH -n 1
#SBATCH -t 30-00:00:00
#SBATCH -p park
#SBATCH --mem-per-cpu=1G
#SBATCH --mail-type=ALL
#SBATCH<EMAIL_ADDRESS>/n/data1/hms/dbmi/park/alon/software/bcbio/bin/bcbio_nextgen.py /n/data1/hms/dbmi/park/DATA/BSMCommonExperiment/ReferenceTissueProject/.Pipeline/GATK4/config/GATK4.yaml -t ipython -n 512 -s slurm -q park -r t=30-00:00 --timeout 43200

Looking through the logs, the debug log looks completely fine. The slurm.out file indicates the following error:
ipyparallel.error.CompositeError: one or more exceptions from call to method: postprocess_alignment
[Engine Exception]EngineError: Engine '9f00d508-f8f841b21499158005a547da' died while running task '173a0c4b-3372ada20f445cc01ff8185a'
[Engine Exception]EngineError: Engine '240bf628-6adc75efe43b1f61d1dec265' died while running task '89820a0f-415dc49393c6f86922f6998c'
[Engine Exception]EngineError: Engine 'bdf5d3fb-393ada2586c039391e343843' died while running task '61fad78b-88fd2d0db52c9006a2dabbd6'
[Engine Exception]EngineError: Engine '3c4e31ca-54c8eb4f90e7c31713c5d540' died while running task '243d366a-7d73997533f31721be121084'
.... 10 more exceptions ...

Any help here would be much appreciated.
Thanks a lot,
Alon
bcbio-nextgen-debug.log.zip
bcbio-nextgen.log
bcbio-nextgen-commands.log
slurm-11754135.out.zip
bcbio-ipengine.err.11754214_2.log
bcbio-ipengine.err.11754214_3.log
bcbio-ipengine.err.11754214_4.log
bcbio-ipengine.err.11754214_5.log
bcbio-ipengine.err.11754214_6.log
bcbio-ipengine.err.11754214_7.log
bcbio-ipengine.err.11754214_8.log

Hi Alon,
These engine died messages are showing that the engines that run the code died. Usually this is a symptom of something else happening. There should be log files for the engine and the controllers that might have some more information in them. The engines could have died for a number of reasons; they could have been killed by the scheduler, the nodes may have died or some other thing happened that caused them to die. O2 was taken down earlier this week for a day, do the jobs overlap with that time?

Hey Rory,
Thanks for the message. This job was submitted after O2 was taken down for a day. I can check with Research Computing to see if this could be a problem on their end – but is there anything else that might cause you to think this could be an issue with bcbio? I just attached the relevant error logs in my comment.
Thanks so much for your help,
Alon
From: Rory Kirchner<EMAIL_ADDRESS>Reply-To: bcbio/bcbio-nextgen<EMAIL_ADDRESS>Date: Friday, April 6, 2018 at 2:01 PM
To: bcbio/bcbio-nextgen<EMAIL_ADDRESS>Cc: "Galor, Alon"<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [bcbio/bcbio-nextgen] Bcbio engine dies error (#2359)
Hi Alon,
These engine died messages are showing that the engines that run the code died. Usually this is a symptom of something else happening. There should be log files for the engine and the controllers that might have some more information in them. The engines could have died for a number of reasons; they could have been killed by the scheduler, the nodes may have died or some other thing happened that caused them to die. O2 was taken down earlier this week for a day, do the jobs overlap with that time?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bcbio_bcbio-2Dnextgen_issues_2359-23issuecomment-2D379330760&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=yy0X9wkgP9n0hRMq-x4iUXAETMlNhaYSvB-NBPZapu4&m=cNeAi-FA__8R74DABFCUiy5N7prDFQABRbZRVkbv6jk&s=la3deQO4cldsdHJruKe5wvFafCqe3UHcmM90ABLzSx4&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ANjVPxd5EOg8LqSzYBBVMhOjvHcWllL-2Dks5tl62FgaJpZM4TKdbK&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=yy0X9wkgP9n0hRMq-x4iUXAETMlNhaYSvB-NBPZapu4&m=cNeAi-FA__8R74DABFCUiy5N7prDFQABRbZRVkbv6jk&s=c2gzS1fHALRpMjrLYD-PSjZZBtfAMs2vugyFcTEH4fw&e=.

Alon;
Sorry about the memory issues, SLURM requires staying within memory bounds while SGE is much more liberal, hence the new issues on switching to 02.
It looks from the commands log like BaseReacalibratorSpark runs with 16 cores and 66Gb of memory allocated but this doesn't match the memory that the engine gets allocated from your specification above.
I pushed a fix which I believe will resolve this by correctly ensuring gatk resource parameters also get considered when setting memory and CPUs for this part of the engine run. If you update to the latest development version (bcbio_nextgen.py upgrade -u development) or put those jvm_opts under default in your bcbio_system.yaml file, it should hopefully do the right thing with allocating and using memory.
Thanks much for the help debugging this and hope this gets your analysis running smoothly.

Thanks for the help Brad!
So just to be clear - I should execute the following command: bcbio_nextgen.py upgrade -u development and then edit the gatk section in my bcbio_system.yaml to read
gatk:
    jvm_opts: ["-Xms750m", "-Xmx3g"]

Is that right?
Thanks a lot,
Alon

Thanks Brad. I actually already had it set to
resources:
   gatk:
      jvm_opts: ["-Xms1g", "-Xmx5g"]

when the most recent run failed.
I will upgrade and change the bcbio_system.yaml to read:
resources:
   gatk:
      jvm_opts: ["-Xms1g", "-Xmx5g"]

Thanks a lot,
Alon

Hi @chapmanb just wanted to follow up on this! Thanks a lot!

Alon;
Sorry about missing this earlier. I think you do need an upgrade to get GATK parameters recognized here. The issue with the development version missing is fixed now so if you re-run the update and then re-run with your same configuration, I hope it will do the right thing. If not, can you let me know where you're hitting issues now and I can help debug further.


ROX-22078: Add link for legacy installation to NoClustersPage

Description
Problem
Marcin reported:

Lack of a link on NoClustersPage for legacy method to install secured cluster services.
After entering /main/clusters/new in address bar, redirect back to /main/clusters and NoClustersPage.

Analysis

Unintended side effect of https://github.com/stackrox/stackrox/pull/9365

Positive change: separated no clusters from clusters per mocks
Negative change: my bad to forget to replace irrelevant link with Legacy installation method link which had been on Install cluster dropdown in clusters heading.

Redirect to /main/clusters
https://github.com/stackrox/stackrox/blob/master/ui/apps/platform/src/Containers/MainPage/MainPage.tsx#L50-L67

does prevent entering /main/clusters/new in address bar directly as a work around.
does not prevent React Router links to init bundles or legacy installation methods.

Solution
Please pardon adding a few changes as prerequisite to discovered clusters while I am editing ClustersTablePanel for more realistic sprint demo.

delegatedScanningTest

Adjust wording of assertion.

redirectFromDashboard

Adjust wording of assertion.

ManageTokensButton

Delete Manage as a prerequisite to discovered clusters.

ClustersTablePanel

Delete Manage as a prerequisite to discovered clusters.
Add component prop according to PatternFly docs to solve accessibility problem with double a elements.

NoClustersPage

Adjust wording of link to contrast with new link.
Add missing Legacy installation method link.
Deleted unneeded onClick prop.

Residue

When click Review init bundle installation methods link in testing step 2, it opens /main/clusters/secure-a-cluster in a new tab, therefore MainPage redirect to /main/clusters is a problem to solve. Possible solution:

Move from MainPage to Body where route is already available.
Do not redirect for any /main/clusters/… route.

Checklist

[ ] Investigated and inspected CI test results
[x] ~Unit test and regression tests added~

Testing Performed
Before you yarn deploy in ui folder:
export ROX_MOVE_INIT_BUNDLES_UI=true

yarn lint in ui
yarn build in ui and then compute branch - master for the following

wc build/static/js/*.js
main.css: 0 = 3950606 - 3950606
total: 129 = 10471486 - 10471357
ls -al build/static/js/*.js | wc -l
0 = 90 - 90 files

yarn start in ui

Manual testing
Temporarily edit code.

Visit /main/clusters with simulated no clusters and no bundles.

Create bundle button
Legacy installation method link

Visit /main/clusters with simulated no clusters but with bundles.

Review init bundle installation methods link
Legacy installation method link

Visit /main/clusters with clusters and init bundles, and then click Secure a cluster

Init bundle installation methods
Legacy installation method

Integration testing
Before you yarn cypress-open in ui/apps/platform folder:
export CYPRESS_ROX_MOVE_INIT_BUNDLES_UI=true

clusters/delegatedScanningTest.test.js
clusters/redirectFromDashboard.test.js

ui-e2e-tests failures:

Configuration Management are unrelated and fixed in #9647
Vulnerabilities are unrelated


chore(sequencer_infra): add component client trait for remote client

Stack:

#2119
#2115
#2090
#2089
#2088
#2087
#2086
#2085 ⬅

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is

✓ Commit merged in pull request #2119


Make sure the entire config prompt is read when entering config mode

Issue summary
If the first config line written after entering config mode is invalid, then ConfigInvalidException is intermittently not raised.
This applies to Cisco IOS-XR platforms.
A minimal repro is at https://github.com/tjohnes/cafykit-netmiko-v4-example.
Root cause
CiscoBaseConnection.config_mode expects a pattern of the base prompt, truncated to 16 chars.  This was added in 902936fd8d1fd247d40e3bfc5601428c675c0eee.
The problem is that this does not read the entire config prompt when entering config mode.
BaseConnection.config_mode then calls CiscoXrBase.check_config_mode, which sends a newline and expects r"[#\$]".  This matches the end of the what's already in the extra buffer and so returns immediately.
The first config line is then intermittently written before the second config prompt; this results in a netmiko session log like this:
RP/0/RP0/CPU0:ios#config terminal

Thu Aug 17 20:25:27.043 UTC
RP/0/RP0/CPU0:ios(config)#

zzz
RP/0/RP0/CPU0:ios(config)#zzz

                           ^
% Invalid input detected at '^' marker.
RP/0/RP0/CPU0:ios(config)#

When cmd_verify is set, we read until the first zzz; and then we read until the next prompt (the second prompt).  The output (according to BaseConnection.send_config_set) is therefore:
config terminal

Thu Aug 17 20:44:21.989 UTC
RP/0/RP0/CPU0:io

zzz
RP/0/RP0/CPU0:ios(config)#zzz

which does not contain the expected "Invalid input" string.
This is evident from the debug logs (truncated somewhat for brevity):
DEBUG    netmiko:base_connection.py:116 [None] write_channel: b'config terminal\n'
DEBUG    netmiko:base_connection.py:604 [None] read_channel: config terminal
DEBUG    netmiko:base_connection.py:681 [None] Pattern found: (config\ terminal) in output: config terminal
DEBUG    netmiko:base_connection.py:604 [None] read_channel: RP/0/RP0/CPU0:ios(config)#
DEBUG    netmiko:base_connection.py:681 [None] Pattern found: (RP/0/RP0/CPU0:io) in output:
DEBUG    netmiko:base_connection.py:116 [None] write_channel: b'\n'
DEBUG    netmiko:base_connection.py:681 [None] Pattern found: ([#\$]) in output: s(config)#
DEBUG    netmiko:base_connection.py:116 [None] write_channel: b'zzz\n'
DEBUG    netmiko:base_connection.py:604 [None] read_channel:

zzz
RP/0/RP0/CPU0:ios(config)#zzz

                           ^
% Invalid input detected at '^' marker.
RP/0/RP0/CPU0:ios(config)#
DEBUG    netmiko:base_connection.py:681 [None] Pattern found: (zzz) in output:

zzz
DEBUG    netmiko:base_connection.py:681 [None] Pattern found: ((?:RP/0/RP0/CPU0:ios.*$|#.*$)) in output:
RP/0/RP0/CPU0:ios(config)#zzz

Description of the fix
Override config_mode for CiscoXrBase to read the entire config prompt when entering config mode.
This is very similar to the approach taken (in upstream netmiko) for AristaBase.config_mode.
Testing
https://github.com/tjohnes/cafykit-netmiko-v4-example no longer reproduces the issue when this fix is present.

Thank you for explaining the RC so well. I appreciate the efforts you've taken to explain it so concisely.
I understand the problem and your PR fixes it. Will merge it.


Device don't connect

Hi zhiayang, first of all thank you very much for sharing your design with the community :). I sent to make some mikoto 6.3 to JLCPCB and they finally arrived, but I can't configure them, I may have done something wrong in the order process, especially with the orientation of the components. I'm not very good with electronics, could you help me identify what I did or what I'm doing wrong? Thank you very much in advance for your help. The microcontroller

Sorry the super delayed response. Unfortunately I can't really help with this, it might be a manufacturing issue

Hey @admfgonzalez
Ultimately we are unsure what the problem is. The yellow light is constantly on and no connection to the microcontroller is made via usb
Did you figure out the issue to your problem. We believe that we have the same issue.
One thing that we notices is the orientation of the Y1 Oscillator.
We also used
https://www.farnell.com/datasheets/1562852.pdf
which states that connector 2 and connector 4 should be connected to GND. Which seems to be correct for the component we used. see image.

Kicad shows it in the same way.

So technically this should be correct. Maybe the issue is somewhere else.

does the board show up over SWD? there's solder pads on the back you can use to connect to a stlink, and maybe try flashing firmware/bootloader with adafruit-nrfutil or openocd.
if it shows up over SWD, i would check the usb data lines for shorts (there's pads on the back too in case the connector pins are too small).
actually -- you guys did flash the bootloader, right? I don't think the usb connection will do anything (certainly it won't show up as a usb drive) until you do.


fix: Scrolling down on collection activity tab resets the page

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context
useScroll -> useEventListener -> onUnmounted not called making scroll code from items tab still run on activity tab

[x] Closes #8164

Did your issue had any of the "$" label on it?

[x] Fill up your DOT address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot 📸

[ ] My fix has changed something on UI;

Copilot Summary

🤖[deprecated] Generated by Copilot at ae5e94d
Improved explore page caching with keepalive prop. This allows faster navigation and smoother transitions between collections and filters on the explore page.

🤖[deprecated] Generated by Copilot at ae5e94d

NuxtPage is the key to our fate
We control the cache with keepalive state
Exploring the collections with blazing speed
We unleash the power of the Nuxt breed

thanks!
pay 20 usd

😍 Perfect, I’ve sent the payout
💵 $20 @ 5.16 USD/DOT ~ 3.876 $DOT
🧗 13QUj3pZyFNfYj4AM336hRdyLQbevj5H3sR4PKmLEXLdwZhh
🔗 0x7f9805c1f1b35aadf265d156b3d1fd42d356533c4daa9b4a9bfe9f869073d677
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


🔃 The great foundation merge

Codecov Report

Merging #401 into master will increase coverage by 5.53%.
The diff coverage is 89.87%.

@@            Coverage Diff             @@
##           master     #401      +/-   ##
==========================================
+ Coverage   79.01%   84.55%   +5.53%
==========================================
  Files          78      194     +116
  Lines        2221     4104    +1883
  Branches      399      627     +228
==========================================
+ Hits         1755     3470    +1715
- Misses        465      632     +167
- Partials        1        2       +1

Impacted Files
Coverage Δ

...rc/foundation/DeviceUpdate/updateCampaign/index.ts
100% <100%> (ø)

src/foundation/Accounts/loginHistory/index.ts
100% <100%> (ø)

src/foundation/Accounts/apiKey/index.ts
100% <100%> (ø)

src/foundation/Accounts/userInvitation/index.ts
100% <100%> (ø)

...BulkCreate/deviceEnrollmentBulkCreateRepository.ts
100% <100%> (ø)

src/common/adapter.ts
100% <100%> (ø)

...ccounts/userInvitation/userInvitationRepository.ts
100% <100%> (ø)

...serInvitation/subtenantUserInvitationRepository.ts
100% <100%> (ø)

src/common/config.ts
100% <100%> (ø)

src/common/repository.ts
100% <100%> (ø)

... and 364 more

Continue to review full report at Codecov.

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


feat(): add adapter option mongoDriverOpts, add default option ignoreUndefined

Fixes #30

[x] - If applicable, appropriate JSDoc comments were updated in source code
[ ] - If applicable, appropriate changes to js-data.io docs have been suggested ("Suggest Edits" button)
[x] - Unit test coverage did not decrease & appropriate tests changes made

Test?

Current coverage is 80.35% (diff: 100%)

No coverage report found for master at f6805aa.

Powered by Codecov. Last update f6805aa...03628a1

@jmdobry g2g


Dubbing: Target language is not getting set.

Hello.
I am trying to trying to use the dubbing api using this module. While using dubbing part I am getting this error everytime:
{
  "detail": {
    "status": "empty_target_language",
    "message": "Target language must be set in automatic dubbing mode. Either set the target language or set dubbing studio to true."
  }
}

This is the code I wrote to reproduce the error:
import { ElevenLabsClient } from 'elevenlabs';
import dotenv from 'dotenv';
import fs from 'fs';

dotenv.config();

const elevenlabs = new ElevenLabsClient({
  apiKey: process.env.ELEVENLABS_API_KEY,
});

const file = fs.createReadStream('test.mp4');

const res = await elevenlabs.dubbing
  .dubAVideoOrAnAudioFile({
    file,
    target_lang: 'en',
    watermark: true,
    mode: 'automatic',
  })

console.log(res);

I am running node v20.13.1

same thing happening on node v20.11.1 and     "elevenlabs": "^0.6.0"

Facing the same issue, how are you guys doing workaround? using API Service, if so can you send me your implementation for rerference @danielmb @chandrashekhar07

But it works through API calls,

@chandrashekhar07 this should be fixed in version 0.8.2!


Replacing sections and config files with different schemas causes Unprocessable Entity errors

What I expected to happen
When replacing a theme, all valid theme files would be replaced without 422 Unprocessable Entity errors
What actually happened
When using theme replace to replace the files of a theme with those of another, errors can occur where invalid type values for blocks are mistakenly detected:
Example replacing Venture with Supply

Supply has the block values listed in the error message, but they don't exist in Venture. Examples:
https://github.com/Shopify/supply/blob/master/src/config/settings_data.json#L95
https://github.com/Shopify/supply/blob/master/src/config/settings_data.json#L102

It seems that the type values from the theme you are uploading do not exist in the theme that is being replaced and as a result, the 422 errors occur.
This results in an incomplete theme upload/replace.
A current workaround is to manually replace the contents of settings_data.json and settings_schema.json with empty values in the code editor on the admin.
Steps to reproduce

Clone the Venture repo, build the theme (using slate tools) and push it to a theme
Do the same with Supply, and replace the theme from step 1 using theme replace
The errors shown in the screenshot above should occur

My Environment
OS (including version): Mac OSX High Sierra
Themekit version: Issue seen on 0.7.5 and 0.6.12
Ignore Files(if any):
    - node_modules/
    - "*.md"
    - "*.yml"
    - "*.zip"
    - "*.*~"

The issue was also seen by @chrisberthe and @bczegeny

Yeah, this is an order of operations issue. I am not sure how I can accommodate this but I will think about it for a while. One main problem is that I always defer updating settings_data.json to after everything else to make sure that the templates and sections are available for when the data is changed. Do you have an idea what the best order would be?
something like this possibly?:

schema
templates
config_data

Great, thanks for looking at this @tanema, apologies for the delay responding!
To get around this issue it looks like config/settings_schema.json and config/settings_data.json would need to be updated before the schemas, but you mention that this creates another issue.

I always defer updating settings_data.json to after everything else to make sure that the templates and sections are available for when the data is changed

I'm not sure what this means 🙃  Could you explain it more?

I can refer to the issue that you opened at the beginning of this year :P https://github.com/Shopify/themekit/issues/321 Because of that I deferred updating settings_data.json to be uploaded after absolutely every other file is updated. This ensures that the schema is updated before the settings_data.json so that Presets are defined already.

Haha, I don't know what I want obviously 😄
Seeing that theme replace completely replaces the theme on your store with the contents of the local one, could we do this perhaps?

Replace the files in the current order
If settings_data.json is also being updated by the theme replace (i.e. it isn't in the ignored files), use the local version to check if the schemas are correct, instead of the existing one on the store

Just so I understand what's going on, what check do you make for Unprocessable entity during theme replace? Is it one of these:

Check if the presets defined in the template schemas exist in settings_data.json
Check if the settings defined in settings_data.json exist in the schemas
Something else?

I don't load files at all, themekit really only deals with filenames and then just pushes files to the server. The Unprocessable entity errors come from Shopify while trying to process your file changes. Themekit has no logic on what is a valid theme/schema/liquid at all. All of that logic resides in Shopify and is validated when the files are pushed to the server.

I have no idea how to facilitate this complete replace of one theme with another. It seems like there is an interdependence between section schemas and settings_data->sections. I would need some functionality from the API to disable validation or something like that which I am not sure is a great idea.
I think ultimately I need to close this issue because

Themekit is a tool meant for developing on the same theme and not switching themes
Switching from one theme to another should be done from the admin via Publishing
I cannot support this complex change over without introducing some way to alter the sections during the changeover and I don't ever want to introduce behavior that could damage a theme.

@tanema Thanks for the explanation, I'm delighted to learn more about Themekit 🙂
I'm looking into a workaround on our end that might allow us to achieve the replace as is. I might have some questions around that, but I'll contact you in slack about it as this isn't an issue that should be fixed in Themekit as you say.


Remove CacheRole.None and TopicRole.None

We don't support deny permissions today so CacheRole.None and TopicRole.None are not supported and should not be exposed in the SDK. We keep it in the proto because the default enum (0) needs to exist.

Done in https://github.com/momentohq/client-sdk-javascript/pull/598

Released in momento js sdk 1.27.2


Provide REST API explorer

The fledgeling HIE has a JSON API. This includes some introspection as to what plugins are available, and what commands they provide, together with their parameters.
Provide an application that can interact with the API, and present the results in a meaningful way.
i.e.
$ stack build
$ stack exec hie -- --repl -d

Then access http://localhost:8001/ as in
curl -v http://localhost:8081/req/base -X POST -H Content-Type:application/json --data-binary '{"ideParams":{},"ideCommand":"version","ideContext":{"ctxEndPos":null,"ctxCabal":null,"ctxStartPos":null,"ctxFile":null}}'

Possibly consider using http://swagger.io, especially as there is now servant-swagger
Or any other appropriate technology. It needs to be able to run locally though.
cc @kRITZCREEK

Pulling in a web server is a big dependency. I would advise against it.

HIE's dependency footprint is going to be massive anyway.
Also, this can be a frontend plugin eventually, to be configured in per user if wanted.
See https://github.com/haskell/haskell-ide-engine/issues/25

Hi all, @alanz. We are interested in getting involved with this project as we have time. Commenting here because I'm in favor of a REST API. It can help with a local remote symmetry in development. As my laptop's compile times are fairly long, there's a scenario in which I could see preferring to develop on a more powerful virtualized machine. It also makes it easy to integrate in build / stage / deploy pipelines, which would likely be cloud based.

Sounds good, shall I add you to the project?

Please. No promises on pushing code soon, but we want an IDE! It was nearly at the point where we were considering rolling our own - not that the existing alternatives are bad, but they weren't enough of a gain over just using emacs. It would be much better to contribute to a community project.

Ok, great.
You know that this is not an IDE? That said, one of the first integrations
is into emacs, and there is a lot to be done on that front still.
On Sun, Dec 6, 2015 at 10:59 PM, Kieren James-Lubin <
<EMAIL_ADDRESS>wrote:

Please. No promises on pushing code soon, but we want an IDE! It was
nearly at the point where we were considering rolling our own - not that
the existing alternatives are bad, but they weren't enough of a gain over
just using emacs. It would be much better to contribute to a community
project.
—
Reply to this email directly or view it on GitHub
https://github.com/haskell/haskell-ide-engine/issues/19#issuecomment-162346989
.

Yes - but I am still trying to understand exactly what it is. But I think the approach of not building an impenetrable monolith is completely right. Once I put a project into something like Eclipse, it's stuck there forever, and I have to find an Eclipse plugin to use e.g. CLI tools that I'm already using.
I think the vision could be flushed out a bit though - I have skimmed the docs but I'm not 100% clear what the organizing principle would be, in a sentence.
My priorities would be:

Organize and make it easy to use existing Haskell ecosystem tooling
Integrate with other popular tooling as much as possible (Git(hub), Docker, Travis..)
Separate concerns so that it is easy to pick and choose which pieces you want in your personal "IDE environment"

That sounds like a good agenda.
I would summarise the project as a set of mutually reinforcing goals

Be a focal point for the haskell ecosystem wrt IDEs / tooling
Provide a separation of concerns, so that experts in their various
fields can focus on their specialities.

This means the people who can do IDE integration can do that, the tool
writers do that, the guys sorting out the nitty-gritty details of managing
a project on the disk do that.
On Sun, Dec 6, 2015 at 11:15 PM, Kieren James-Lubin <
<EMAIL_ADDRESS>wrote:

Yes - but I am still trying to understand exactly what it is. But I think
the approach of not building an impenetrable monolith is completely right.
Once I put a project into something like Eclipse, it's stuck there forever,
and I have to find an Eclipse plugin to use e.g. CLI tools that I'm already
using.
I think the vision could be flushed out a bit though - I have skimmed the
docs but I'm not 100% clear what the organizing principle would be, in a
sentence.
My priorities would be:

Organize and make it easy to use existing Haskell ecosystem tooling
Integrate with other popular tooling as much as possible (Git(hub),
Docker, Travis..)
Separate concerns so that it is easy to pick and choose which pieces
you want in your personal "IDE environment"

—
Reply to this email directly or view it on GitHub
https://github.com/haskell/haskell-ide-engine/issues/19#issuecomment-162348173
.

Sounds great to me, thanks.

Maybe this is old news for you, @alanz, but If we go the swagger-route, the actual API-browser could be the Swagger UI

Yes, I agree that swagger is probably the best approach here, in terms of
documentation too.
On Mon, Dec 7, 2015 at 12:00 AM, Tobias G. Waaler<EMAIL_ADDRESS>wrote:

Maybe this is old news for you, @alanz https://github.com/alanz, but If
we go the swagger-route, the actual API-browser could be the Swagger UI
http://swagger.io/swagger-ui/
—
Reply to this email directly or view it on GitHub
https://github.com/haskell/haskell-ide-engine/issues/19#issuecomment-162352656
.

I've looked into servant-swagger lately, and have a (crude POC ready)[https://github.com/haskell/haskell-ide-engine/tree/servant-swagger], so I'll assign myself to this issue unless @kjameslubin is also working on this?

Please go ahead @tobiasgwaaler. I do have one comment, though - it would be nice to have a RAML based spec, as RAML is pretty lightweight and can be useful to generate live docs. See an example here - this is generated from a yesod-raml routes file and it mostly just works though we need to fix some stuff. But if you are going to actually do the work, don't let me get in the way. Can swagger take RAML as input?

Just an FYI. Servant swagger is going to release a 1.0 version soon to generically infer schema. Cc @fizruk
Sent from my iPhone

On Dec 13, 2015, at 2:01 PM, Tobias G. Waaler<EMAIL_ADDRESS>wrote:
I've looked into servant-swagger lately, and have a (crude POC ready)[https://github.com/haskell/haskell-ide-engine/tree/servant-swagger], so I'll assign myself to this issue unless @kjameslubin is also working on this?
—
Reply to this email directly or view it on GitHub.

That's great news, @dmjio! Will the 1.0 release break the code I've already written (which isn't a lot)? I guess my question is if I should wait for the 1.0 release or start working with the current version?

@tobiasgwaaler yes, 1.0 release is going to bring a lot of changes, since it's spec model will change.
It also is going to bring a considerable amount of automation (with generic Schemas).
More specifically servant-swagger is going to use swagger2 for a complete Swagger model and generic Schemas. swagger2 is where the work is going on right now, that's why you don't see any progress in servant-swagger repo. I expect to finish it in a couple of days. Once that's done servant-swagger will be migrated/rewritten (we don't expect it to take a lot of time, the first usable version may be out in a week or sooner).
If you're are impatient and want to start working with something, you can probably help us out by reviewing swagger2 (here's a small Hackage API example and here are examples of generically derived schemas). A lot of late changes are not released yet, so you might want to check out HEAD. There is some documentation, but more explanatory/tutorial docs are yet to be written. Any feedback before we roll this out would be much appreciated!
If you have any questions, you can find us on #servant IRC channel.

@fizruk thank you for informing me :) I'm looking forward to swagger2. If I get impatient I'll try to use it to generically deriving the schema for haskell-ide-engine. I'll let you know if I find the time

@tobiasgwaaler servant-swagger is released and #152 is merged so there should be nothing stopping you now :)

Wonderful, I'll take a look as soon as I get the chance. If anyone else is eager to work on this, please go ahead. Although I'm motivated, I'm not sure when I'll get the time :/

no pressure

@tobiasgwaaler Out of curiosity, have you gotten anywhere with this ticket? If not, I was going to spend a bit of time this evening to see if I can get something working.

Hi, @ankhers. I started working on this branch a while ago, but haven't done anything since the release of servant-swagger-0.1 and after the commands were moved to the type level. So I would say no, I haven't gotten anywhere ;) And I probably won't in a good while, so please go ahead! :+1:

@ankhers @tobiasgwaaler @cocreature Is anyone making progress on this? I have some time available and want to get my brain around the tech for my day job, so I can tackle it if not

@alanz I'm not working on this :)

FYI, I have started here https://github.com/alanz/haskell-ide-engine/tree/swagger2
I think I am making progress, but need to chase some instances through

I have constructed a function hieSwagger which results in a Swagger structure when called with our servant based API definition.
The problem is, I do not know how to create an instance of ToSchema for ParamValP, which is a data type with existentials in it.  I suspect putting a ToSchema constraint on the existential may help.
@cocreature any ideas?

@alanz ToSchema constraint won't help as the existentially quantified type variable does not actually affect the schema AFAICT.
One straightforward way to introduce ToSchema for an existential type like ParamValP is to provide an "untyped" variant and use a Generic-based instance of that. It may be the case that you already have such an untyped representation (I am not familiar with the codebase):
-- ------------------------------------------
-- This is copied for convenience
-- ------------------------------------------
data ParamType = PtText | PtFile | PtPos

data ParamValP = forall t. ParamValP { unParamValP :: ParamVal t }

data ParamVal (t :: ParamType) where
  ParamText :: T.Text -> ParamVal 'PtText
  ParamFile :: T.Text -> ParamVal 'PtFile
  ParamPos :: (Int,Int) -> ParamVal 'PtPos
-- ------------------------------------------

data UParamValP = UParamValP { unUParamValP :: UParamVal }
  deriving (Generic)

data UParamVal
  = UParamText T.Text
  | UParamFile T.Text
  | UParamPos (Int,Int)
  deriving (Generic)

instance ToSchema UParamVal where
  declareNamedSchema = genericDeclareNamedSchema defaultSchemaOptions
    { datatypeNameModifier   = drop 1   -- we drop the U prefix
    , constructorTagModifier = drop 1 } -- we drop the U prefix

instance ToSchema UParamValP where
  declareNamedSchema = genericDeclareNamedSchema defaultSchemaOptions
    { datatypeNameModifier  = drop 1    -- we drop the U prefix
    , fieldLabelModifier    = \s -> take 2 s ++ drop 3 s } -- we drop the U in unUParamValP

instance ToSchema (ParamVal t) where
  declareNamedSchema _ = declareNamedSchema (Proxy :: Proxy UParamVal)

instance ToSchema ParamValP where
  declareNamedSchema _ = declareNamedSchema (Proxy :: Proxy UParamValP)

Another straightforward approach would be to manually write the ToSchema instances:
instance ToSchema ParamValP where
  declareNamedSchema _ = do
    sParamVal <- declareSchemaRef (Proxy :: Proxy (ParamVal t))
    return $ NamedSchema (Just "ParamValP") $ mempty
      & type_ .~ SwaggerObject
      & properties . at "unParamValP" ?~ sParamVal
      & required .~ ["unParamValP"]

instance ToSchema (ParamVal t) where
  declareNamedSchema _ = do
    sText <- declareSchemaRef (Proxy :: Proxy T.Text)
    sPos <- declareSchemaRef (Proxy :: Proxy (Int, Int))
    return $ NamedSchema (Just "ParamVal") $ mempty
      & type_ .~ SwaggerObject
      & maxProperties ?~ 1
      & minProperties ?~ 1
      & properties . at "ParamText" ?~ sText
      & properties . at "ParamFile" ?~ sText
      & properties . at "ParamPos"  ?~ sPos

BTW, it should be possible to derive this instances with TH, so if you have lots of GADTs or existentials, feel free to file a feature request!

@fizruk  thanks for the great pointers, I will give it a go some time this weekend

Writing the instances manually seems like the best way to go.

The servant-swagger stuff seems to be going into an infinite loop which consumes all memory.
I think the best approach may be a custom generator based on the UntaggedPluginDescriptors, as is used in the hie-doc-generator.

@alanz which part goes into an infinite loop?
Can you file an issue on https://github.com/haskell-servant/servant-swagger/issues?

If you run this test: https://github.com/alanz/haskell-ide-engine/blob/swagger2/test/JsonSpec.hs#L204 it will terminate (and fail the test), but if you uncomment https://github.com/alanz/haskell-ide-engine/blob/swagger2/test/JsonSpec.hs#L236 (instead of the RNil on the line above) it fails to terminate.

@fizruk FYI I have found using the swagger2 package directly that using
declareResponse (Proxy :: Proxy Object)

for Data.Aeson.Object causes an infinite loop.
See http://lpaste.net/7300947608627838976

@alanz I have just fixed the infinite loop in swagger2-2.0.2.
Can you please try that?

@fizruk I just tested it, and it works, thanks for the update.

The swagger2 package provides
declareResponse :: ToSchema a => proxy a -> Declare (Definitions Schema) Response

I would like to declare a response schema for a CommandFunc, and have the following type signature
declareCmdResponse :: ToSchema a => CommandFunc a -> Declare (Definitions Schema) Response
declareCmdResponse _ = declareCmdResponse XXXX

Could this work, and any ideas of what XXX could be? my initial approach of trying
declareCmdResponse _ = declareCmdResponse (Proxy :: Proxy a)

does not typecheck. I am pretty sure I am missing something simple here.

@alanz
declareCmdResponse :: ToSchema a => CommandFunc a -> Declare (Definitions Schema) Response
declareCmdResponse = declareResponse

This should work because proxy in proxy a in the type of declareResonse is a type variable.
So it should work for CommandFunc a just like for Proxy a.
Unless CommandFunc is a type family, of course.

yes indeed, thanks. Was pretty sure it would be something straightforward.  I am still getting my head around all this type level programming.

This is turning out to be trickier than I thought.  Some observations so far

The swagger ecosystem is not geared toward passing parameters in the body of a POST. This means that even if the generated swagger JSON file is correct, the online tooling does not generate commands properly, which is the whole point of the exercise.

The Pos type being compound makes it difficult to pass as a parameter, there will have to be some kind of wrapping/unwrapping to its component parts, which does not play nice with the swagger2 package.

So I am contemplating making the following changes to the HTTP API (with knock-on effects)

Split Pos into a Line and a Col variable.  This is probably good anyway, I can envisage line-oriented commands that can then be supported.

Pass the HTTP API parameters as normal query parameters, so the swagger ecosystem tooling can support them easily.

Comments?


TabNine no longer works with atom

This is my current settings page after the last update. I can't disable or uninstall it.

hey @jwaggy, what os are you using? Can you open the configuration (TabNine :: config)? If so, can you please attach the logs (located at the bottom of the page)?
Thanks

Windows 10 Pro
Nothing comes up. I'm not sure if I am missing something or if somehow somewhere a configuration file was corrupted but I can't find the reason and this is the only thing affected.

could you please try to reinstall it by following these steps:

go to Packages -> Settings View -> Open
click the "Open Config Folder" button
in the config folder under the "packages" folder delete the "TabNine" folder
reinstall TabNine from the install Packages

Thanks

That seems to have fixed it. Thanks.

Following that process did not fix the issue for me.
I cannot get Tabnine::config to do anything


deprecate regular_api_checks.py

Context
We used to have a github action that periodically ran to check the API for basic functionality. Now, we have the health monitoring repo.
These tests were related to #154
Requirements

[x] remove the VUE_APP_PDAP_API_KEY and VUE_APP_PDAP_TOKEN variables at the org level
[ ] remove files dependent on VUE_APP_PDAP_API_KEY variable

regular_api_checks.py
outdated tests files
none of these files should be working, because the variable has long been defunct

[ ] remove github actions triggering these files/tests

if any bits of the tests do seem to be working, we can discuss further

@maxachis your work in health monitoring looks great. I think we're about ready to set up your script to run on a cron job w/ github action, would you agree?

Prior to eliminating regular_api_check.py, we may want to consider migrating some of these checks to the Health Monitoring repo.
However, we may not want to include all of these tests, for a few reasons:

Many/all of these test functionality already tested in the newly added integration and unit tests that run in the dev environment -- unless we've reasons to believe prod will differ substantially from dev, running these again would be redundant.
Some of these tests are POST or PUT requests, which would modify the production database when run -- not something that should be done without careful consideration.
Some carry specific "test flags", which have been deprecated from the code, so these would need to be modified in turn.
Granular testing of production may give us less bang for our limited buck than more generalized, non-intrusive tests which target common points of failure -- any endpoint responding will help us validate that endpoints in general are not down; checking that the server and client are online and responding to basic PINGs or ping-equivalents is also important; checking metrics such as latency of response, CPU/RAM/storage load of servers,

I'll work on creating an issue advocating for what to include in health monitoring.

@josh-chamberlain @maxachis I went ahead and completed the outlined changes in the linked branch. I can hold off on submitting the PR if you wanted to evaluate if there are any checks worth saving before moving forward

@josh-chamberlain @maxachis I went ahead and completed the outlined changes in the linked branch. I can hold off on submitting the PR if you wanted to evaluate if there are any checks worth saving before moving forward

@EvilDrPurple From my vantage point, you can go ahead and submit: After reviewing, I only saw one that might need re-adding, and only as an integration test, not as a health check: I've noted that in #329

Saving the pagination check is good, but I figured since this wasn't working anyway it'd be better to deprecate and move to the new tests. Thanks y'all! @EvilDrPurple you could feel free to look at #329 if you want to work on tests in the new infrastructure.


Go Playground link
What did you see happen?
2009/11/10 23:00:00 INFO Message text foo="LogValue panicked\ncalled from runtime.panicwrap (/usr/local/go-faketime/src/runtime/error.go:355)\ncalled from main.(*foo).LogValue (:1)\ncalled from log/slog.Value.Resolve (/usr/local/go-faketime/src/log/slog/value.go:512)\ncalled from log/slog.(*handleState).appendAttr (/usr/local/go-faketime/src/log/slog/handler.go:468)\ncalled from log/slog.(*handleState).appendNonBuiltIns.func1 (/usr/local/go-faketime/src/log/slog/handler.go:342)\n(rest of stack elided)\n"
What did you expect to see?
2009/11/10 23:00:00 INFO Message text foo=

Related Issues and Documentation

x/exp/slog: TextHandler panics on nil arg #58652 (closed)
x/tools/go/analysis/passes/slog: nil panic in `isAttr` via `analysisutil.IsNamed` #61228 (closed)
log/slog: panic: bad kind: 9 in JSONHandler Handler().WithAttrs(LogValuer{}) #59727 (closed)
log/slog: nil pointer dereference when printing nil regexp #61648 (closed)
log/slog: catch panics in LogValue
x/tools/go/packages: nil pointer dereference #69524 (closed)
cmd/go: panic when building a `main` package in GOPATH mode when a go.work file exists #58767 (closed)
go/internal/gcimporter: untyped interface type parameter causes "panic: nil underlying"  during testing #57015 (closed)
cmd/compile/internal/types2: unify.go:449: assertion failed, panic #67872 (closed)
Unexpected execution flow when overshadowing error-type with *Error (both nil) #26000 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

this looks working as intended for slog, the issue is in your code

Thanks for your reply! Just to confirm, do I need to handle nil values explicitly even if the method receiver is defined on a value rather than a pointer?

given a pointer, Go needs to dereference it to pass to the method. That's where your nil pointer dereference is coming from. It also panics if you call f.LogValue() directly, without slog.
Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.
For questions please refer to https://github.com/golang/go/wiki/Questions

I was just thinking it would be helpful if this behaved similarly to fmt.Stringer when handling nil values. It explicitly handles nil in panic:
// If it's a nil pointer, output "<nil>". This approach could handle cases
// where a Stringer might not check for nil or where a nil pointer is used
// with a value receiver. In both scenarios, "<nil>" seems like a reasonable default.
if v := reflect.ValueOf(arg); v.Kind() == reflect.Pointer && v.IsNil() {
    p.buf.writeString(nilAngleString)
    return
}


Can UABEA open .bundle files?

Can UABEA open .bundle files? (I can’t check at the moment)

Probably, but why don't you just try opening it?

I mean i found a among us file that is a .bundle but i don't know how to save it as .bundle again i only just export it as .file but if i change it all to the same file name and .file name it seems not to load the maps

Probably, but why don't you just try opening it?

I’m on holiday so I can’t check, someone asked in my comments on a video about UABEA

@RamcesGD are you saying you exported the assets files but didn't import them? if the .bundle file is an addressable, editing shouldn't be an issue.

You can open a .bundle file as long as you uncompress it.


parent allowed .class identifier, now its boolean only.

Love the additional features you have added :)
Previously, I could use parent to identify a class to restrict the draggable to.  Now, it only allows boolean.  Any plans on restoring the previous capability to also allow css class?

I am glad that you can love the additional features of the component, but the features you mentioned I have not found in the previous version, and did not encounter the corresponding usage scenarios. So there is no related plan to join the css class.
If you can modify a version and pull requests, I will consider merging it without affecting other features.

The previous version and documentation is from https://github.com/mauricius/vue-draggable-resizable#parent

@jaketoolson
The type of parent in the source code is defined as Boolean, which is only used as a condition for judging, and it has not been found to function as a selector.
Sorry, I have not tested successfully. Maybe I made a mistake?


NEWPAGE... [WITH] TITLE title-definition is not fully supported

eg.
 NEWPAGE (05)     WITH TITLE LEFT     30T 'I N F O R M A T I O N' 65T *DATD /
-> Expected operand, but got TAB_SETTINGNatParse(NPP049)
Functionally equivalent to WRITE TITLE. Maybe that code could be common.

closed by #472


pkg_deb: allow passing deb and changes directly

(More detail in the commit.)
I've knocked this out quickly in anticipation of some feedback on a better way to solve this problem. Please let me know if I'm holding it wrong!

This is actually broken in a non-trivial way, because the test depends on being able to refer to out_deb and out_changes explicitly in its runfiles. (Is this something that anyone does outside the test? I'm not sure.) I could change the test behavior, but I'd like to get guidance on this first.
Note that other people have hit this problem as well:
https://stackoverflow.com/questions/56190105/selecting-different-values-for-pkg-debs-package-and-architecture-attributes#new-answer

Okay, I think I misunderstood the constraints. The latest patch just lets you pass a select for the architecture, so that you can at least work around the problem. The API for pkg_deb is otherwise unchanged.

Can you start with an issue for this where we can come up with an overall design.  The package_file_name attribute from pkg_tar will be available to pkg_dep too. That takes care of half this PR in a uniform way across rules.
Do we need that same capabilty for changes or is there a default format for changes which we should always use?

Can you start with an issue for this where we can come up with an overall design.  The package_file_name attribute from pkg_tar will be available to pkg_dep too. That takes care of half this PR in a uniform way across rules.
Do we need that same capabilty for changes or is there a default format for changes which we should always use?

AFAIU the problem is that you can't pass a select to architecture. And I think the proposed workaround was to pass debs and changes from the outside so this wouldn't be a blocker.

AFAIU the problem is that you can't pass a select to architecture. And I think the proposed workaround was to pass debs and changes from the outside so this wouldn't be a blocker.

I think #282 makes this obsolete.   The net effect of that PR is that you can set changes explictly if you want. But if you don't, we use basename(package_file_name).changes. In turn, package_file_name might be built from the defaults or computed from things only known at build time (like cpu).

I think #282 makes this obsolete.   The net effect of that PR is that you can set changes explictly if you want. But if you don't, we use basename(package_file_name).changes. In turn, package_file_name might be built from the defaults or computed from things only known at build time (like cpu).

Sorry, @matzipan, I didn't actually answer your question.
I don't understand why you are saying that architecture is not select()able.  I just tried using a select for architecture, along with the defaulting for package_file_name and it just worked.
pkg_deb(
    name = "deb_select_arch",
    data = ":example1",
    description = "what it does",
    maintainer =<EMAIL_ADDRESS>    package = "foo_b",
    version = "1",
    architecture = select({
        ":special_build": "NewCPU",
        "//conditions:default": "x36",
    }),
)

$ bazel build :deb_select_arch
Target //:deb_select_arch up-to-date:
  bazel-bin/foo_b_1_x36.deb
$ bazel build :deb_select_arch --define=SPECIAL=1
Target //:deb_select_arch up-to-date:
  bazel-bin/foo_b_1_NewCPU.deb

Of course, looking at the stackoverflow question, I see that it might not have been selectable before #282, but all the output file computations are made more rationally now.

Sorry, @matzipan, I didn't actually answer your question.
I don't understand why you are saying that architecture is not select()able.  I just tried using a select for architecture, along with the defaulting for package_file_name and it just worked.
pkg_deb(
    name = "deb_select_arch",
    data = ":example1",
    description = "what it does",
    maintainer =<EMAIL_ADDRESS>    package = "foo_b",
    version = "1",
    architecture = select({
        ":special_build": "NewCPU",
        "//conditions:default": "x36",
    }),
)

$ bazel build :deb_select_arch
Target //:deb_select_arch up-to-date:
  bazel-bin/foo_b_1_x36.deb
$ bazel build :deb_select_arch --define=SPECIAL=1
Target //:deb_select_arch up-to-date:
  bazel-bin/foo_b_1_NewCPU.deb

Of course, looking at the stackoverflow question, I see that it might not have been selectable before #282, but all the output file computations are made more rationally now.

Hi aiuto,
Thanks for the response.  I was not aware of #282, which seems to address that. I think I've seen it in other Bazel extensions as well, so it's interesting that now I know how this can be fixed (I think it was rules_docker).
Andrei

Hi aiuto,
Thanks for the response.  I was not aware of #282, which seems to address that. I think I've seen it in other Bazel extensions as well, so it's interesting that now I know how this can be fixed (I think it was rules_docker).
Andrei

#282 is submitted now. This PR might be obsolete.

Based on your comment above, I’m happy and will close this issue. I’ll reopen if there’s something that isn’t working as expected.


[stdlib][String] Optimise UTF8 validation

I was checking out the current implementation of this in Godbolt (https://swift.godbolt.org/z/nq91Thdvb), and a couple of things caught my eye:

Dynamic exclusivity enforcement
The nested functions make a mutable capture of the iterator iter, which means a call in the runtime function swift_beginAccess. We can avoid this by instead passing the iterator as an inout variable, allowing for static enforcement instead.

Error allocations
The control flow makes use of try and catch, which results in a bunch of runtime calls which shouldn't be necessary:
call    (lazy protocol witness table accessor for type output.(UTF8ValidationError in _60494E8B9C642A7C4A26F3A3B6CECEB9) and conformance output.(UTF8ValidationError in _60494E8B9C642A7C4A26F3A3B6CECEB9) : Swift.Error in output)
lea     rdi, [rip + (full type metadata for output.(UTF8ValidationError in _60494E8B9C642A7C4A26F3A3B6CECEB9))+8]
mov     rsi, rax
xor     edx, edx
xor     ecx, ecx
call    swift_allocError@PLT
mov     r13, rax
mov     r12, rax
call    swift_willThrow@PLT
mov     rdi, r13
call    swift_release@PLT

These can be avoided by simply having the guaranteeX functions return a boolean, and using && to combine their values.

There are, of course, fancier ways of validating UTF-8 data (including SIMD). But these are some relatively simple changes, and checking the result in Godbolt (https://swift.godbolt.org/z/eqKPY3YbY), we can see that it avoids dynamic exclusivity enforcement and runtime calls for error handling. The findInvalidRange function is no longer inlined, but it is difficult to say why. In any case, that function itself could use some tweaking, but I figured I'd start with this smaller, more easily reviewable patch.

Hmm that's unfortunate. It definitely seems like it should be a win.
I'll take a closer look - maybe there are things like branch hints for throwing methods which are making a significant difference.


OCPBUGS-20179: Stop defining time series for hosted clusters or node pools which do not exist anymore.

What this PR does / why we need it:
hostedcluster and nodepool time series keep being defined long after the hostedcluster or nodepool is gone.
This is problematic because:

We plan to add a new hostedcluster metric which will "count" the number of worker cores and which will be used to bill the customers (see OSD-19085).
This metric must stop to be defined as soon as the cluster is gone or we will continue to bill the customer for a cluster which is gone.
This is misleading.
This is kind of a leak; time series were defined forever... unless the hypershift operator was restarting which was not coherent at all.
Alerts based on hypershift operator metrics may keep firing if not designed carefully while the hostedcluster or nodepool is gone.

This PR uses dedicated collectors for all hostedcluster & nodepool metrics.
Thanks to that change:

Time series values are computed at scraping time.
Metrics stop being defined for a given hostedcluster or nodepool as soon as it is gone.
Code populating the metrics is now fully decorrelated from the code reconciling the hostedclusters and the nodepools (i.e. the controllers)

This PR also:

Stops forcing hypershift_cluster_silence_alerts metric to 1 when the hosted cluster is being deleted.
Indeed checking whether or not a hosted cluster is being deleted can be achieved by checking whether or not metric hypershift_cluster_deleting_duration_seconds is being defined.
Defines the _id label for all nodepool metrics
Changes all the metrics measuring time:

Time is no longer measured at the end of the action!
Time is measured while the action is going on... and the metric stops being defined at the end of the action.
This is much more coherent with designing an alert on an action taking too much time to complete.
Also for some metrics (like hypershift_cluster_deletion_duration_seconds) the end of the action was also the end of the hostedcluster or nodepool the metrics refers to, so those metrics couldn't start being defined when the action was done (not to mention that if the hypershift operator was restarted just after, those metrics would have been defined for a very brief period of time if not at all)
The following metrics have been renamed according above semantic change:

hypershift_cluster_deletion_duration_seconds -> hypershift_cluster_deleting_duration_seconds
hypershift_cluster_guest_cloud_resources_deletion_duration_seconds -> hypershift_cluster_guest_cloud_resources_deleting_duration_seconds
hypershift_cluster_available_duration_seconds -> hypershift_cluster_waiting_initial_avaibility_duration_seconds
hypershift_cluster_initial_rollout_duration_seconds -> hypershift_cluster_initial_rolling_out_duration_seconds
hypershift_cluster_upgrade_duration_seconds -> hypershift_cluster_upgrading_duration_seconds
hypershift_nodepools_deletion_duration_seconds -> hypershift_nodepools_deleting_duration_seconds
hypershift_nodepools_initial_rollout_duration_seconds -> hypershift_nodepools_initial_rolling_out_duration_seconds

Unit-tests were migrated accordingly to this new semantic.

Replaces metric hypershift_cluster_skipped_cloud_resources_deletion with hypershift_cluster_invalid_aws_creds.
Indeed the old metric is set (and only set) when deleting the cluster (i.e. when hypershift_cluster_deleting_duration_seconds is set) and when the AWS creds are invalid (when hypershift_cluster_invalid_aws_creds is set). The new metric is no more transaction based which allowed the decorrelation between the controller code and the collector code.
Moves all but one metrics at root level in the collectors.
Indeed those metrics (handled by some kind of fake collector) were either concerning hostedclusters or nodepools.
Adds a platform label to hypershift_hostedclusters_failure_conditions metric in order to be consistent with hypershift_nodepools_failure_conditions metric.
Initialises hypershift_nodepools_failure_conditions metric to 0 (instead of undefined) for all plaforms & failure conditions in order to be consistent with hypershift_hostedclusters_failure_conditions.
Initialises hypershift_nodepools metric to 0 (instead of undefined) to be consistent with hypershift_hostedclusters.
Adds a _id label to hypershift_hostedcluster_nodepools metric. Also label cluster_name has been renamed to name in order to be consistant with the other hostedcluster metrics (remark that this metric is however still computed while dealing with the nodepools).
Maybe this metric could be dropped as it is equivalent to sum by (namespace, name, _id, platform) (label_replace(count by (namespace, cluster_name, _id, platform) (hypershift_nodepools_available_replicas), "name", "$0", "cluster_name", ".*"))
Make sure that annotation hypershift.openshift.io/HasBeenAvailable really get properly added on a hostedcluster when needed... this was not working before.
Metric hypershift_nodepools_transition_seconds is now really defined. Old code was attempting to set this metric... but as the new status was already set before the call to ObserveConditionTransitionDuration old & new statuses were actually the same!

Which issue(s) this PR fixes
Contributes to OCPBUGS-20179 (also this is the clean fix for OSD-16638).
Note that the PR proposes some renaming for some metrics, please tell if you are okay with those renames, maybe they can be shipped with this PR.
Checklist

[X] Subject and description added to both, commit and PR.
[X] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/retest

I'm not sure I follow the deletion metrics pattern. How is current service dealing with remaining metrics from deleted clusters?

I'm not sure I follow the deletion metrics pattern. How is current service dealing with remaining metrics from deleted clusters?

That's the problem, all the metrics for a given deleted hosted cluster or node pool currently continue to exist till the hypershift-operator is eventually restarted.
Aim of this PR is to make sure the metrics (or more accurately the time series) for a given hosted cluster or node pool cease to exists when the hosted cluster or node pool is deleted.

That's the problem, all the metrics for a given deleted hosted cluster or node pool currently continue to exist till the hypershift-operator is eventually restarted.

Thanks I see what you are trying to solve, my questions is how are we solving the same thing in traditional ROSA? After a cluster is gone what happen to their metrics?

That's the problem, all the metrics for a given deleted hosted cluster or node pool currently continue to exist till the hypershift-operator is eventually restarted.

Thanks I see what you are trying to solve, my questions is how are we solving the same thing in traditional ROSA? After a cluster is gone what happen to their metrics?

The metrics are ended; exactly as I intend to do here.
In traditional ROSA, the metrics are all produced by (pods in) the cluster itself. When the cluster is deleted those metrics cease to be produced (for the cluster which has been deleted).
With hypershift, metrics are produced by various sources:

By some pods in the data plane
By some pods in the management clusters running in the HCP namespace for the considered hosted cluster (ex: the control-plane-operator pod)
By the Hypershift operator

Source 1 and 2 cease to produce metrics when the hosted cluster is deleted.
Source 3 continues to produce metrics for a hosted cluster which is gone till the Hypershift operator is (eventually) restarted. In this PR we indent to stop producing metrics for a given hosted cluster as soon as it is deleted.
You see, the problem is that the Hypershift operator continues to exist long after a hosted cluster is gone; this is not the case for the other sources; hence a special handling is required in Hypershift operator code to handle time series indexed on the hosted cluster and/or node pools.

This is effectively removing our ability to track and meet our SLOs for HC deletion. I'd suggest we put a doc together so we can agree on the goals then we revisit the best way to implement them.

Is "This" == "This pull request"?
As previously explained: it is not normal to keep a metric for which the hosted cluster or node pool referenced by the label set is gone: this is a leak!
If you really want to prolongate a time series, you can do so as follows but only for some given additional time:
last_over_time{metric[28d]}

(this works for metrics which are counters or behave as counters)
For global SLOs on all hosted clusters, you normally do not need to go deep and analyse metrics for a given hosted cluster.

/retest

My 2 cents (irrespective of the discussion whether the metric should be deleted or not): deleting metrics in code is usually a code smell as deleting series when some object is removed is prone to error. It is in general safer to implement the custom collector pattern with Const metrics...
https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#hdr-Custom_Collectors_and_constant_Metrics

Thanks @simonpasquier for the comment; implementing a custom collector is indeed a better & safer way to go. I will change the code in this PR to do exactly that.

/retest

/retest

After a second look at how collectors work, this would actually force a complete redesign of the code:
https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#Collector:~:text=and the ExpvarCollector.-,Example,-¶
Indeed, with collectors, metrics values would need to be computed at scrape time. They are currently computed when some action is performed on a given object (hosted cluster or node pool) and saved for later with the call to Set; the saved value is then used when the metric is actually scrapped.
@enxebre , @muraee : would you be okay for this redesign? If "yes"; then I think this has to go in a separate PR.

We already do very similar to collector pattern here https://github.com/openshift/hypershift/blob/main/hypershift-operator/metrics.go
See also a collector implementation example here https://github.com/openshift/machine-api-operator/blob/master/pkg/metrics/metrics.go
This PR is removing all metrics beyond the HC/NodePool lifetime. There might be scenarios where that's not desired. Lets discuss outside this PR and make sure there's alignment for metrics from a holistic pov. Then if collector are the best way to materialise that view, lets implement it.

/retest

/retest

/jira refresh

/test e2e-aws-metrics

/approve

Rebased

--- FAIL: TestReportWaitingInitialAvailabilityDuration (0.01s)
    --- FAIL: TestReportWaitingInitialAvailabilityDuration/When_cluster_just_got_created,_metric_is_reported_with_a_value_set_to_0 (0.01s)
panic: cannot handle unexported field at {*io_prometheus_client.MetricFamily}.state:
	"github.com/prometheus/client_model/go".MetricFamily
consider using a custom Comparer; if you control the implementation of type, you can also consider using an Exporter, AllowUnexported, or cmpopts.IgnoreUnexported [recovered]
	panic: cannot handle unexported field at {*io_prometheus_client.MetricFamily}.state:
	"github.com/prometheus/client_model/go".MetricFamily
consider using a custom Comparer; if you control the implementation of type, you can also consider using an Exporter, AllowUnexported, or cmpopts.IgnoreUnexported
...
FAIL	github.com/openshift/hypershift/hypershift-operator/controllers/hostedcluster/metrics	0.146s

thanks!
/lgtm


Not support custom rules?

Environment:
Laravel 9.14.1
PHP 8.1.6
laravel-api-to-postman 1.12.0

When executing php artisan export:postman with enable_formdata = true it throws an error:

It works well when enable_formdata = false.
Here is my request and rule:
class PasswordUpdateRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize(): bool
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules(): array
    {
        return [
            'current_password' => [
                'required',
                'string',
                new CurrentPasswordRule(),
            ],
            'password'         => [
                'required',
                'confirmed',
                'min:8',
                new WeakPasswordRule(),
            ],
        ];
    }
}

class CurrentPasswordRule implements Rule
{
    /**
     * Determine if the validation rule passes.
     *
     * @param string $attribute
     * @param mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        return Hash::check($value, auth()->user()->password);
    }

    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return __('Your current password is not valid');
    }
}

Does this package not yet support custom rules? Or am I doing something wrong?

Hi @sunxyw, thank you for reporting this issue.
I believe I've managed to reproduce this in #72, so will work on a fix when I get a little time. If you have any suggestions towards a fix, feel free to message over on the PR 😄
(cc: @tomirons)

#72 stops this throwing an error, we still don't have support for custom rules at this moment in time though.

Weird, I thought the test case would have caught this. I’ll take a look at this when I get back home in a few hours.
cc: @tomirons

I tried fixing it myself, maybe it wasn't the best way, but it did get rid of the error.
https://github.com/andreaselia/laravel-api-to-postman/blob/352cc1b190c0f5a4ed8ced4a12bb25725a2e410b/src/Commands/ExportPostmanCommand.php#L329-L330
if (is_array($rules)) {
    foreach ($rules as $i => $rule) {
        if (is_object($rule)) {
            unset($rules[$i]);
        }
    }
    $this->validator = Validator::make([], [$attribute => implode('|', $rules)]);

Hi @sunxyw,
I'll be taking a look at this today, I had a bit of a busy day yesterday so didn't get round to it.
Thanks for posting your solution. I'll need to be able to reproduce this through a unit test before I can submit a fix though.
Do you have any ideas how we could maybe reproduce it in a unit test?

Okay, I managed to reproduce it. It's when a rule class is within an array of rules.

Good, please take your time, this is not in a hurry.

This has now been resolved in the latest release. Thanks again for your help on the issue.


Add role when user is verified

The new user integration system has an option to add a group to users with verified integrations. Consequently, this group can be synced to a role in Discord


Node 16 LTS Update

Description
This PR is a mass maintenance update focusing on updating all npm dependencies and bumping Node to version 16 LTS.
https://apps.nrs.gov.bc.ca/int/jira/browse/SHOWCASE-2291

Types of changes
Made changes to dependencies and locked them into their current version since COMFORT is in maintenance mode.

Checklist

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

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

Leaving a TODO for the skipped test since we do not want to waste too much more time on this test for a project in maintenance.


Create Topological_Sorting.c

Topological Sorting is an algorithm for ordering the vertices of a directed acyclic graph (DAG) such that for every directed edge u → v, vertex u comes before vertex v in the ordering. Topological sorting is only possible for Directed Acyclic Graphs (DAGs), as cyclic graphs do not have a linear ordering.
It is used in scenarios like task scheduling, course prerequisites, and other dependency resolution problems where certain tasks need to be completed before others.

@sanjay-kv , @pankaj-bind , please accept my pull request .

@pankaj-bind Please accept my PR and provide some suggestions.
Thank You.

No readme file


Tests and app can get out of sync

First up - well done!  I like this very much and thanks for https://github.com/TypeStrong/ts-loader/issues/537
However, I've found an issue when testing locally.  I switched to use fork-ts-checker and deliberately broke the test code.  I saw type errors and my tests failed.  Great.  Then I made some changes to my src code.  The tests still failed.  Great.  Then I fixed the test code, the tests passed again.  Awesome.  Then I tweaked the src code  and noticed the build was still reporting the type errors from when I deliberately broke the test. Nothing I do manages to let fork-ts-checker in on the news that the type error is gone. 😢
I'm guessing this is something to do with having my tests running in a separate process from my webpack build.  My setup was based on this:
https://github.com/TypeStrong/ts-loader/tree/master/examples/webpack2-gulp-react-flux-babel-karma
with:
new ForkTsCheckerWebpackPlugin({
      watch: ['./src', './test'] // optional but improves performance (less stat calls)
})

Do you think if this an issue of my setup or is this a problem with fork-ts-checker?  I'd be interested to see a setup as above tweaked to use fork-ts-checked in the correct manner assuming this is user error.

Thanks for reporting :) Your config looks good, it's probably bug. I've tried to replay your scenario but it was working on my machine.
Please, send me your TypeScript version, tsconfig.json content and operating system version :)
Also please check if issue appear without watch option.

Here's a repro project (based on one of ts-loader's examples): https://github.com/johnnyreilly/fork-checker-repro
It has 2 commits; the initial setup and adding forktscheckerplugin so you can easily see what I've done. It's a little hacked together but should allow you to repro the issue mentioned above.

I reproduced this error also on first commit so it looks like it's not because of this plugin.
Scenario:

put const x: number = '1'; at the end of the test/stores/GreetingStore.tests.ts
put const x: number = 1; at the end of the src/stores/GreetingStore.ts
remove const x: number = '1'; from test/stores/GreetingStore.tests.ts
remove const x: number = 1; from  src/stores/GreetingStore.ts
The console prints: error TS2322: Type '"1"' is not assignable to type 'number'. and error TS6133: 'x' is declared but never used. on test/stores/GreetingStore.tests.ts

These errors are reported by ts-loader (also in second commit). In second commit ts-loader should not report semantic errors like these (only emit errors), but there is typo in gulp/webpack.js:74, and karma.conf.js:8 - it should be transpileOnly instead of transpile ;)
So if you fix these two typos, everything should work.

Cool - I'll give it a try and report back!

Also - perhaps validating supplied options would be a good idea!

So this looks really nice!  I have one remaining question: when developing I have the notifier plugin in play:
https://github.com/johnnyreilly/fork-checker-repro/blob/master/gulp/webpack.js#L60
  myDevConfig.plugins = myDevConfig.plugins.concat(
    new webpack.optimize.CommonsChunkPlugin({ name: 'vendor', filename: 'vendor.js' }),
    new WebpackNotifierPlugin({ title: 'Webpack build', excludeWarnings: true }), // ****** <- this
    new ForkTsCheckerWebpackPlugin({
      blockEmit: false,
      tslint: false,
      watch: ['./src', './test'] // optional but improves performance (less stat calls)
    })
  );

It pops toasts when the build breaks and when it's mended. How can this be made to play well with the fork-ts-checker?

It should work with blockEmit: true option, but it's not good for development :) To make it work with non-blocking mode you can use event hooks provided by plugin and write your own:
var notifier = require('node-notifier');

function ForkTsCheckerNotifierWebpackPlugin() {}
module.exports = ForkTsCheckerNotifierWebpackPlugin;

ForkTsCheckerNotifierWebpackPlugin.prototype.apply = function(compiler) {
  compiler.plugin('fork-ts-checker-receive', function (diagnostics, lints) {
    var error = diagnostics.length ? diagnostics[0] : null;

    if (error) {
      notifier.notify({
        title: 'Webpack',
        message: error.getContent(), // see ./lib/NormalizedMessage for full api
      });
    }
  });
}

I didn't check this code, just write to show the idea :)

Perhaps I shall write the plugin!

I have a rough and ready plugin working. I'm going to do some more work on it and, if it seems worthwhile, I may publish it to npm. I may have some questions if that's okay?

Yes, of course :)

Okay - I've got a first version written: https://github.com/johnnyreilly/fork-ts-checker-notifier-webpack-plugin
It's published to npm: https://www.npmjs.com/package/fork-ts-checker-notifier-webpack-plugin
🍾
There's one problem I've noted which could be:

User error
A bug in my notifier
A bug in fork-ts-checker-webpack-plugin.

I'll put up details in a while.  Bedtime now I think.  If you've any comments on the plugin then let me know.

Okay - I've updated the repro to use the new plugin: https://github.com/johnnyreilly/fork-checker-repro
I've deliberately introduced 2 bugs into the codebase; one into an src module (i.e. the actual app code) and one into a test module.  Once you've npm installed and entered watch mode with npm run watch do the following:

comment out the bugs in WhoToGreet.tsx (src module) and GreetingStore.tests.ts  (test module)
the build should notify as succeeded.

Okay - just pushed one more commit that may resolve things.  Just need to think about it and test it a littlle more.  Will report back....  Any observations welcome

I've just published a new version of the plugin; it now handles lints as well as diagnostics.  The repro repo is now working really nicely with fork-ts-checker-webpack-plugin.  So much so that I'm planning to use it as a basis for another example in the ts-loader repo.  Essentially a webpack2-gulp-react-babel-karma-fork-ts-checker example - this will be particularly useful to me in future I'm sure.
I'm planning to blog about both fork-ts-checker-webpack-plugin and fork-ts-checker-notifier-webpack-plugin.  I hope that's okay with you?

I'm glad to hear that :) Of course it will be my pleasure if you will write some article about this plugin. Please, send me your blog address ;)

It's https://blog.johnnyreilly.com/ - I'll be sure to mention you. Probably will post in a week or two. If you're on Twitter then let me know your handle and I'll copy you in when I tweet about it.

I didn't have a Twitter account but I think it's a good time to sign up :) @OlesDev


chore: Update gas limit from 180M -> 198M

Add another mainnet gas limit increase record, this time from 180M->198M, setting the effective gas target to 33M/block

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1


Stateful Service Not Starting - Fixed

If your Stateful service isn't starting and you are running later versions of Service Fabric e.g. <IP_ADDRESS>94 (more info https://github.com/Azure/service-fabric-issues/issues/848), add the following <RuntimeFrameworkVersion>2.0.9</RuntimeFrameworkVersion> into your csproj
Check which versions you have in C:\Program Files\dotnet\shared\Microsoft.NETCore.App

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3aa58af5-02ea-e425-1fc5-9f588d394016
Version Independent ID: 86440381-783a-6e49-bacb-59b1c1581d81
Content: Create a .NET app on Service Fabric in Azure
Content Source: articles/service-fabric/service-fabric-quickstart-dotnet.md
Service: service-fabric
GitHub Login: @MikkelHegn
Microsoft Alias: mikhegn

@asgasos Thanks for your feedback. I have assigned the issue to the content author to evaluate and update as appropriate.

Can you detail which file this needs to be added?

@rpili1313 It says add the line to your csproj file.

I suggest closing this case, as we haven't heard back regarding the proposed doc update.

@Karishma-Tiwari-MSFT Can you help close this?


✨[Feature Request]: Replacemnt of Chatbot Share

Description
Added Chatbot
Related Issues
Resolves #461
Type of PR

[ ] Bug fix
[X] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
https://github.com/Anishkagupta04/RAPIDOC-HEALTHCARE-WEBSITE-/assets/154777864/9251010b-b16c-426b-8d1e-a3c802758f60
Checklist

[X] I have gone through the contributing guide
[X] I have updated my branch and synced it with project main branch before making this PR
[X] I have performed a self-review of my code
[X] I have tested the changes thoroughly before submitting this pull request.
[X] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[X] I have commented my code, particularly in hard-to-understand areas.

Additional context:
[Include any additional information or context that might be helpful for reviewers.]
Added Code :
 <script>
window.embeddedChatbotConfig = {
chatbotId: "xjRGZgxJziSoHQ1T1twl6",
domain: "www.chatbase.co"
}
</script>
<script
src="https://www.chatbase.co/embed.min.js"
chatbotId="xjRGZgxJziSoHQ1T1twl6"
domain="www.chatbase.co"
defer>
</script>

https://github.com/Anishkagupta04/RAPIDOC-HEALTHCARE-WEBSITE-/assets/154777864/6598b616-c0f2-4b61-b0db-847a1453ade4
@varshith257 please review the changes

@varshith257 please assign me this issue.


Microsoft.KubernetesConfiguration and Microsoft.Kubernetes are namespaces owned by Azure Kubernetes Service on Azure Stack HCI not AKS

Microsoft.KubernetesConfiguration and Microsoft.Kubernetes are namespaces that belong to Azure Kubernetes Service on Azure Stack HCI not AKS :
see here and here
Please correct these documents to reflect the reality

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 16b4bb50-25ad-a3c6-f42a-84f33c84e362
Version Independent ID: 6188226a-1f56-2a0a-fc57-4b8616b5fe32
Content: Resource providers by Azure services - Azure Resource Manager
Content Source: articles/azure-resource-manager/management/azure-services-resource-providers.md
Service: azure-resource-manager
Sub-service: management
GitHub Login: @tfitzmac
Microsoft Alias: tomfitz

@asilverman Thanks a lot for bringing this to our notice, we will review the feedback and update the document accordingly.

@asilverman - thanks for this feedback. I'll update the documentation.

The update will be published today.
#please-close


pdfx 2.0.1+2 depends on device_info_plus ^3.2.1

Because pdfx 2.0.1+2 depends on device_info_plus ^3.2.1 and no versions of pdfx match >2.0.1+2 <3.0.0, pdfx ^2.0.1+2 requires device_info_plus ^3.2.1.
So, because app depends on both device_info_plus ^4.0.0 and pdfx ^2.0.1+2, version solving failed.
exit code 1

Dependency upgraded  https://pub.dev/packages/pdfx/versions/2.1.1


allow context to disable premultipliedAlpha when set to false

@rreusser

Oh my gosh I didn't actually do that, did I? :facepalm:

Sorry about that. I got in a hurry. Well, what's one more version?? I've published 1.6.1.

Oh my gosh I didn't actually do that, did I?

No. It was my dirty suggestion.

Haha oh no. This is even worse. Now I've published faulty code and been passive-aggressive about it. 🙈
(Kidding, kidding. Nbd. Published and thanks again!!)

Four releases in a day. Happy regl-Day! :tada:


Make certain classes Serializable as required by Apache Flink

I propose an update to the NATS Java Client: making StreamConfiguration and Consumer Configuration classes Serializable.  This change is vital for integrating NATS with Apache Flink (Nats-Flink Connector with JetStream support) , as Flink requires all fields in its operators and functions to be Serializable for distributed processing.

besides the review comments, I would like to understand why would you need a stream configuration? The connector should not be adding or modifying streams, that's not it's job. And all streams have names, which are serializable.
Similar to that why are you needing consumer configuration? For the connector, there should be very few settings that are ever used, I think it would be better to have your own serializable structure and simply use the builder each time, or even better just bind by stream name and consumer name.

Hello @scottf thank you for taking time to review the changes, I agree the flink connector should be there only to publish/consume messages and not create the Stream/Consumer at all. I also think of a usecase where one might have 100s of flink job to run and may have to create those resource in advance, which is why we want to create these resources via flink connector. Please let me know your thoughts on this, happy to accept your suggestions as well :)

Hello @scottf thank you for taking time to review the changes, I agree the flink connector should be there only to publish/consume messages and not create the Stream/Consumer at all. I also think of a usecase where one might have 100s of flink job to run and may have to create those resource in advance, which is why we want to create these resources via flink connector. Please let me know your thoughts on this, happy to accept your suggestions as well :)

There is no dependency on this PR currently with our work i.e. JetStream Support on Syandia's NATS-Flink connector.
https://github.com/synadia-io/flink-connector-nats/pull/4
I am fine to close this PR.
@scottf

Closed. We cannot change serialization without a major release. To be handled by client.


Tests filter

Coverage increased (+12.3%) to 52.483% when pulling 3995049c87d039169f94fb5ca293c56b7f227402 on tests_filter into 647c2f96f10f3684c64fd9297cdfb05d1e4b9496 on bridge2.0.

Coverage increased (+12.2%) to 52.419% when pulling ff780c170492b91bc854155c43ee440b4b38f6cb on tests_filter into 647c2f96f10f3684c64fd9297cdfb05d1e4b9496 on bridge2.0.


spellings, newer clear diagram

Hello Masters,
When I was referring to this content, came across a few minor things like spelling and aesthetics.
Also, the TKO day-2-day operations diagram I prepared for my customer presentation has clearer fonts and some context-specific icons so thought to share that 👍.

Thanks @dkhopade!  Will take a look in a bit.

Thanks, @mbentley for merging this. The image I created was something from the TKO presentation I have been working on for my customer. I will share the link to it over slack.


Update aws-java-sdk-dynamodb to 1.12.771

About this PR
📦 Updates com.amazonaws:aws-java-sdk-dynamodb from 1.11.1034 to 1.12.771
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.amazonaws", artifactId = "aws-java-sdk-dynamodb" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.amazonaws", artifactId = "aws-java-sdk-dynamodb" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #603.


Update metal-uri to v3.0.0

Hey @eduardolundgren,
Metal Ajax uses Metal Uri too and it has to be updated to v3.0.0 to allow Metal Ajax to work in other environments apart from Node and browsers.
Could you please get this PR and release a new version?
Thanks,

Hey @ipeychev, @Robert-Frampton was looking at applying some changes to metal-uri that could make the change to the karma.conf file unnecessary.
In the meantime, I've pushed a develop branch and set it as the base for this PR so it follows our new branching strategy (not-yet-fully-announced).
@Robert-Frampton, let us know if you think we should just merge this or wait until some upcoming changes in metal-uri.

That's good to know. Okay, let's see what Rob will say.

Hey @jbalsas @ipeychev
After taking a look into making those changes to metal-uri, I decided that I didn't really like the idea of copying all of that third party logic, in the end it would have been 4 different modules that we would have been copying into our source.
Since we got the tests running on wedeploy/api-js as well, let's go ahead and merge this in. We can put a tutorial together on how to configure karma tests with projects depending on Metal at some point to help alleviate the pain.

Merged to develop!


use redis-mock for testing

There is an issue with redis-mock
https://github.com/bee-queue/bee-queue/issues/111


[STAR] fix core gripper location

previously there we intermittent pick up failures. tested this a bunch and it seems robust. Also visual inspection.
Hamilton had it's pipettes calibrated last week so I think this is legit.

can't verify because we don't use the core gripper, but trust this works for you, and others can revisit to create a dynamic solution if this doesn't work for them.


Components with input element activating Storybook shortcuts

Description
As seen in #717, some components are able to ignore the Storybook keyboard shortcuts while typing on an input bar, while others do not. For example, typing a 1 in a BXSearch will result in the components list to be focused, or typing an a will toggle the knob menu, while these actions don't happen when using BXInput.
It's a strange bug since it still occurs after stripping down the components to their bare minimum by only using an input element within their Shadow DOM (as seen in the PR linked), even though that they are the exact same component, only with a different name.
Video showing issue:
https://user-images.githubusercontent.com/24970122/139461104-893daaa3-34a2-48b7-8ec1-2729eabe2ed8.mov
Component(s) impacted
The components currently affected with this bug are:

BXSearch
BXCombobox
BXMultiSelect - filterable

Browser
No response
Carbon Web Components version
canary
Severity
Severity 4 = The problem is not visible to or noticeable to an average user. Affects minor functionality, no workaround needed.
Application/website
N/A
CodeSandbox example
https://github.com/carbon-design-system/carbon-web-components/pull/717
Steps to reproduce the issue (if applicable)
Visit the search or combobox story and begin typing. If the key corresponds to a Storybook shortcut (e.g. a, d, f, s, t, 1) observe that the Storybook changes and focus can be stolen from the component being interacted with
Release date (if applicable)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

I believe combobox would be resolved by https://github.com/carbon-design-system/carbon-web-components/pull/901