Remove inaccurate information for adding conformance profiles

Problem statement
There is potentially a lot of information in adding-conformance-profile.md that is no longer accurate/needed. Find out what the actual current process is and remove the extra information to not cause confusion.
What you need to know

adding-conformance-profile.md
The section titled "Adding support for a new HL7v2 conformance profile in ReportStream" may not match the current mapping strategy, this is the part in question.

Acceptance criteria

[ ] Extraneous or outdated information has been removed.

Hey team! Please add your planning poker estimate with Zenhub @adegolier @arnejduranovic @brick-green @david-navapbc @jack-h-wang @jalbinson @JFisk42 @mkalish @thetaurean


NoMethodError when removed_member_ids is nil

Summary
seeing this error result in closed connections
[ERROR` : websocket @ 2022-10-16 15:22:46.660] Exception: #<NoMethodError: undefined method `each' for nil:NilClass

        data['removed_member_ids'].each do |member_id|
                                  ^^^^^>
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/bot.rb:1603:in `handle_dispatch'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/bot.rb:769:in `dispatch'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/gateway.rb:730:in `handle_dispatch'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/gateway.rb:694:in `handle_message'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/gateway.rb:631:in `websocket_loop'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/gateway.rb:579:in `connect'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/gateway.rb:473:in `block in connect_loop'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/gateway.rb:472:in `loop'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/gateway.rb:472:in `connect_loop'
[ERROR : websocket @ 2022-10-16 15:22:46.661] /usr/local/rvm/gems/ruby-3.1.2/bundler/gems/discordrb-1cd5603d23e0/lib/discordrb/gateway.rb:168:in `block in run_async'
[ERROR : websocket @ 2022-10-16 15:25:34.644] The websocket connection has closed: (no information)
[INFO : websocket @ 2022-10-16 15:25:34.644] Instant reconnection flag was set - reconnecting right away
[INFO : websocket @ 2022-10-16 15:25:34.984] Resumed

looks like added_members and removed_member_ids falls back to empty array here in thread.rb, but this code in bot.rb is still accessing the data hash directly which can result in these being nil and causing the error.
The closed connection happens a few minutes later - I was assuming it was related, but it may not be.

Environment
ubuntu 20.0.4
Ruby version:
3.1.2
Discordrb version:
specs:
discordrb (3.4.2)
discordrb-webhooks (~> 3.4.2)
ffi (>= 1.9.24)
opus-ruby
rest-client (>= 2.0.0)
websocket-client-simple (>= 0.3.0)
discordrb-webhooks (3.4.2)
rest-client (>= 2.0.0)

Introduced in #141, these fields are optional.
Will send a PR

Ah i see i had the flow backwards.


Playground: sending wei/ether does not work

Trying to send X wei but callvalue() returns 0

Here is a link to the playground that reproduces it. In the "value to send" input box at the bottom, I am sending 10000 wei to but calling callvalue() does not load that value. See playground here to reproduce!

Was fixed along #148


Luk10114/1145 view point cloud data offline

Thanks for reviewing @TADraeseke . Everything should be resolved.


Paid Grammarly Account: captcha required while trying to log in

When trying to log in to a paid account, a captcha is required:
"Authentification requires captcha input."
And login fails.
Any idea of a possible solution?

UPDATE:
This requires support from the Grammarly Auth team. They have already implemented the necessary changes and waiting for release (which is delayed due to holidays). Expecting this to be resolved in the first half of Jan 2020. 🥂

I am facing the same problem

This seems to be the open issue #107 - But unfortunately, I am affected as well since I had to log out a couple of days ago.

Does logging out and in again several times help?

Same issue

any workarounds even? I'm having the same issue

Same issue. Any workaroud? Thnaks

Can't use it anymore. Same error on login.

Can't log in anymore due to the captcha problem. I use VSCode to write academic papers. This extension is very important. Without this extension, Grammarly is meaningless to me.

Bump. Same here. No need to pay for Grammarly any more.
Does anyone know a more human-friendly service?
A

I submitted a ticket to Grammarly support. I encourage everyone struggling with this issue to do the same.

I also will cancel my subscription because of this.

I submitted a ticket to Grammarly support. I encourage everyone struggling with this issue to do the same.

I've also submitted a ticket. But their response is that they won't officially support the integration to VSCode.

@stevenybw  they don't have to support it, just not to break it. I love Grammarly and used them from their very early beta, but now I am looking at alternatives, unfortunately very few.
So far https://writefull.com/researchers.html#overleaf-learn-more-anchor looks promising.

I submitted a ticket to Grammarly support. I encourage everyone struggling with this issue to do the same.

I've also submitted a ticket. But their response is that they won't officially support the integration to VSCode.

They are probably working on its own extension.

In the meantime, I am evaluating https://sapling.ai/ , they also have Chrome extension, the ones who will cover most of my tools will have my money :)

Having the same problem.  I Will cut a support ticket with Grammarly, but I don't expect much.  They seem to ignore support tickets.  All I want is the ability to use Markdown with Grammarly.
Ther desktop App and Online editor converts all unordered list to there own bulleted list.  So you can't even copy and paste to check grammar.

@AlexMikhalev Could you try the tool? Unfortunately, my scientific writing pipeline is still broken...

VS Code auth issues would be sorted soon (I don't have a timeline yet but project for providing auth support for this extension is approved.)
This extension is still unofficial (which means I still work on it over weekends). As soon as auth issue is resolved, I will notify.

@matherm looks like https://writefull.com/researchers.html#overleaf-learn-more-anchor was built specifically for academic work, maybe it will help you in the meantime.

Any updates on captcha support?

For some reason, it started working again for me

For some reason, it started working again for me

Not for me.

Same problem. waiting  for the update .

the same problem, no solution yet.

For some reason, it started working again for me

how is it start at the beginning? because from the beginning, it did not work.

VS Code auth issues would be sorted soon (I don't have a timeline yet but project for providing auth support for this extension is approved.)
This extension is still unofficial (which means I still work on it over weekends). As soon as auth issue is resolved, I will notify.

Is there a workaround to be able to log in in the meantime?

@znck I will pay you if you can get this working

Fix is already in process, as soon as I get oauth client ID, I'll publish new version.

Awesome! Send me your PayPal/venmo when you’re done :) I’ll buy you your next coffee.

Hey @znck any updates yet?

🤞 hopefully this year.
(PR was approved on Friday, the feature allows oauth for VS Code will go live in next release.)

hopefully this year.
(PR was approved on Friday, the feature allowing oauth for VS Code will go live in next release.)

That's great news, also do you have any way to support you? Patreon, donations, etc?

💖 GitHub Sponsors

any progress on this?

Duplicate of #107

the same problem, no solution yet.
v0.12.5

the same problem, no solution yet.
v0.12.5

WIP #148

WIP #148

WIP #148

Thanks a lot,  I am looking forward to this fix.

WIP #148

Thanks a lot,  I am looking forward to this fix.


Separate tmt run -i options for host/guest

Currently, the -i / --id option specifies either a directory name inside /var/tmp/tmt, or (if starting with /) a path to a directory anywhere else.
The problem is that this is both a path on the host and the on the guest.
I would like to run tmt run on the host and tell it to output YAML results (along with test logs) onto a deterministic location, preferably in an existing temporary directory (ie. /tmp/my_orchestrator_tool/tmt), so I can

read /tmp/my_orchestrator_tool/tmt/run.yaml to figure out the plan path
read /tmp/my_orchestrator_tool/tmt/plans/$plan_path/execute/results.yaml and evaluate the results

All that without changing the /var/tmp/tmt/* path on the guest - I don't care where the test is stored on the guest, but it should probably not be in /tmp which is lost across reboots.

+1 from me, but it will be terrible to implement. The double-faced nature of the workdir path is strong.


THRIFT-4938 resolved  compatibility display version error when built by visual studio 2015

resloved  compatibility display version error when bulit by visual studio 2015.
jira issue link:  https://issues.apache.org/jira/browse/THRIFT-4936?jql=project%20%3D%20THRIFT%20AND%20component%20in%20(%22C%2B%2B%20-%20Compiler%22%2C%20%22C%2B%2B%20-%20Library%22)

[x] Did you create an Apache Jira ticket?  (not required for trivial changes)
[ ] Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?  (not required for trivial changes)
[ ] Did you squash your changes to a single commit?  (not required, but preferred)
[ ] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"?
[ ] If your change does not involve any code, add  [skip ci] at the end of your pull request to free up build resources.

Pro-Tip: If you mention the JIRA ticket number in the PR it will be aut-linked to the ticket.
http://thrift.apache.org/docs/HowToContribute

@Jens-G  ok, got it. i will fellow this next time, Thanks a lot.


Starting to fine tune manual chunks

Without manual chunks
vite v4.4.9 building for production...
<EMAIL_ADDRESS>(10:12) Use of eval in<EMAIL_ADDRESS>is strongly discouraged as it poses security risks and may cause issues with minification.
<EMAIL_ADDRESS>(175:21) Use of eval in<EMAIL_ADDRESS>is strongly discouraged as it poses security risks and may cause issues with minification.
✓ 12520 modules transformed.
build/index.html                                                0.61 kB │ gzip:   0.36 kB
build/assets/roboto-vietnamese-700-normal-d986b503.woff         4.73 kB
build/assets/roboto-vietnamese-500-normal-7899e6a5.woff         4.73 kB
build/assets/roboto-vietnamese-400-normal-d2390f1a.woff         4.75 kB
build/assets/roboto-vietnamese-300-normal-7747ef64.woff         4.77 kB
build/assets/roboto-vietnamese-300-normal-51f3f418.woff2        5.47 kB
build/assets/roboto-vietnamese-700-normal-4ec57f2a.woff2        5.55 kB
build/assets/roboto-vietnamese-400-normal-77b24796.woff2        5.56 kB
build/assets/roboto-vietnamese-500-normal-0948409a.woff2        5.60 kB
build/assets/roboto-greek-700-normal-3f1a5012.woff              6.30 kB
build/assets/roboto-greek-500-normal-93181eb7.woff              6.32 kB
build/assets/roboto-greek-400-normal-076b9dc1.woff              6.35 kB
build/assets/roboto-greek-300-normal-6bb1ef10.woff              6.44 kB
build/assets/roboto-greek-700-normal-1c9cc76f.woff2             6.94 kB
build/assets/roboto-greek-500-normal-713780d8.woff2             7.02 kB
build/assets/roboto-greek-400-normal-daf51ab5.woff2             7.11 kB
build/assets/roboto-greek-300-normal-455c2c1a.woff2             7.12 kB
build/assets/roboto-cyrillic-400-normal-adba67d2.woff           8.39 kB
build/assets/roboto-cyrillic-300-normal-c07952fe.woff           8.43 kB
build/assets/roboto-cyrillic-700-normal-6f82c5e2.woff           8.66 kB
build/assets/roboto-cyrillic-500-normal-4bc088e9.woff           8.70 kB
build/assets/roboto-cyrillic-300-normal-47aa3bfa.woff2          9.58 kB
build/assets/roboto-cyrillic-400-normal-495d38d4.woff2          9.63 kB
build/assets/roboto-cyrillic-700-normal-6a84eeee.woff2          9.64 kB
build/assets/roboto-cyrillic-500-normal-3728fbdd.woff2          9.84 kB
build/assets/roboto-latin-ext-700-normal-3d1cbacf.woff         10.17 kB
build/assets/roboto-latin-ext-500-normal-a303676a.woff         10.18 kB
build/assets/roboto-latin-ext-400-normal-c2b94086.woff         10.21 kB
build/assets/roboto-latin-ext-300-normal-35da7ccd.woff         10.36 kB
build/assets/roboto-latin-ext-300-normal-b076e863.woff2        11.80 kB
build/assets/roboto-latin-ext-500-normal-7f1c829b.woff2        11.80 kB
build/assets/roboto-latin-ext-700-normal-fc66f942.woff2        11.82 kB
build/assets/roboto-latin-ext-400-normal-3c23eb02.woff2        11.87 kB
build/assets/roboto-cyrillic-ext-700-normal-8ea7934f.woff      13.43 kB
build/assets/roboto-cyrillic-ext-500-normal-57138788.woff      13.45 kB
build/assets/roboto-cyrillic-ext-400-normal-0a32035a.woff      13.47 kB
build/assets/roboto-cyrillic-ext-300-normal-5e06c977.woff      13.55 kB
build/assets/roboto-latin-400-normal-a9fdbefa.woff             14.38 kB
build/assets/roboto-latin-700-normal-d89bc0fc.woff             14.42 kB
build/assets/roboto-latin-500-normal-3ac31048.woff             14.42 kB
build/assets/roboto-latin-300-normal-ddb5c61d.woff             14.59 kB
build/assets/roboto-cyrillic-ext-700-normal-3c505383.woff2     14.68 kB
build/assets/roboto-cyrillic-ext-500-normal-aeed0e51.woff2     14.97 kB
build/assets/roboto-cyrillic-ext-300-normal-435e4b7f.woff2     15.00 kB
build/assets/roboto-cyrillic-ext-400-normal-b7ef2cd1.woff2     15.34 kB
build/assets/roboto-latin-300-normal-f7591131.woff2            15.74 kB
build/assets/roboto-latin-400-normal-f6734f81.woff2            15.74 kB
build/assets/no-image-8357d694.png                             15.80 kB
build/assets/roboto-latin-700-normal-f5aebdfe.woff2            15.86 kB
build/assets/roboto-latin-500-normal-b0195382.woff2            15.92 kB
build/assets/logo-b4500173.png                                 74.85 kB
build/assets/style-b575b3e9.css                                23.48 kB │ gzip:  10.39 kB
build/assets/index-cd40e458.js                              1,830.49 kB │ gzip: 499.02 kB │ map: 6,326.37 kB

(!) Some chunks are larger than 500 kBs after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
✓ built in 23.21s

With manual chunks and trying to create under half mega chunks
vite v4.4.9 building for production...
<EMAIL_ADDRESS>(10:12) Use of eval in<EMAIL_ADDRESS>is strongly discouraged as it poses security risks and may cause issues with minification.
<EMAIL_ADDRESS>(175:21) Use of eval in<EMAIL_ADDRESS>is strongly discouraged as it poses security risks and may cause issues with minification.
✓ 12520 modules transformed.
build/index.html                                              1.15 kB │ gzip:   0.46 kB
build/assets/roboto-vietnamese-500-normal-7899e6a5.woff       4.73 kB
build/assets/roboto-vietnamese-700-normal-d986b503.woff       4.73 kB
build/assets/roboto-vietnamese-400-normal-d2390f1a.woff       4.75 kB
build/assets/roboto-vietnamese-300-normal-7747ef64.woff       4.77 kB
build/assets/roboto-vietnamese-300-normal-51f3f418.woff2      5.47 kB
build/assets/roboto-vietnamese-700-normal-4ec57f2a.woff2      5.55 kB
build/assets/roboto-vietnamese-400-normal-77b24796.woff2      5.56 kB
build/assets/roboto-vietnamese-500-normal-0948409a.woff2      5.60 kB
build/assets/roboto-greek-700-normal-3f1a5012.woff            6.30 kB
build/assets/roboto-greek-500-normal-93181eb7.woff            6.32 kB
build/assets/roboto-greek-400-normal-076b9dc1.woff            6.35 kB
build/assets/roboto-greek-300-normal-6bb1ef10.woff            6.44 kB
build/assets/roboto-greek-700-normal-1c9cc76f.woff2           6.94 kB
build/assets/roboto-greek-500-normal-713780d8.woff2           7.02 kB
build/assets/roboto-greek-400-normal-daf51ab5.woff2           7.11 kB
build/assets/roboto-greek-300-normal-455c2c1a.woff2           7.12 kB
build/assets/roboto-cyrillic-400-normal-adba67d2.woff         8.39 kB
build/assets/roboto-cyrillic-300-normal-c07952fe.woff         8.43 kB
build/assets/roboto-cyrillic-700-normal-6f82c5e2.woff         8.66 kB
build/assets/roboto-cyrillic-500-normal-4bc088e9.woff         8.70 kB
build/assets/roboto-cyrillic-300-normal-47aa3bfa.woff2        9.58 kB
build/assets/roboto-cyrillic-400-normal-495d38d4.woff2        9.63 kB
build/assets/roboto-cyrillic-700-normal-6a84eeee.woff2        9.64 kB
build/assets/roboto-cyrillic-500-normal-3728fbdd.woff2        9.84 kB
build/assets/roboto-latin-ext-700-normal-3d1cbacf.woff       10.17 kB
build/assets/roboto-latin-ext-500-normal-a303676a.woff       10.18 kB
build/assets/roboto-latin-ext-400-normal-c2b94086.woff       10.21 kB
build/assets/roboto-latin-ext-300-normal-35da7ccd.woff       10.36 kB
build/assets/roboto-latin-ext-300-normal-b076e863.woff2      11.80 kB
build/assets/roboto-latin-ext-500-normal-7f1c829b.woff2      11.80 kB
build/assets/roboto-latin-ext-700-normal-fc66f942.woff2      11.82 kB
build/assets/roboto-latin-ext-400-normal-3c23eb02.woff2      11.87 kB
build/assets/roboto-cyrillic-ext-700-normal-8ea7934f.woff    13.43 kB
build/assets/roboto-cyrillic-ext-500-normal-57138788.woff    13.45 kB
build/assets/roboto-cyrillic-ext-400-normal-0a32035a.woff    13.47 kB
build/assets/roboto-cyrillic-ext-300-normal-5e06c977.woff    13.55 kB
build/assets/roboto-latin-400-normal-a9fdbefa.woff           14.38 kB
build/assets/roboto-latin-700-normal-d89bc0fc.woff           14.42 kB
build/assets/roboto-latin-500-normal-3ac31048.woff           14.42 kB
build/assets/roboto-latin-300-normal-ddb5c61d.woff           14.59 kB
build/assets/roboto-cyrillic-ext-700-normal-3c505383.woff2   14.68 kB
build/assets/roboto-cyrillic-ext-500-normal-aeed0e51.woff2   14.97 kB
build/assets/roboto-cyrillic-ext-300-normal-435e4b7f.woff2   15.00 kB
build/assets/roboto-cyrillic-ext-400-normal-b7ef2cd1.woff2   15.34 kB
build/assets/roboto-latin-300-normal-f7591131.woff2          15.74 kB
build/assets/roboto-latin-400-normal-f6734f81.woff2          15.74 kB
build/assets/no-image-8357d694.png                           15.80 kB
build/assets/roboto-latin-700-normal-f5aebdfe.woff2          15.86 kB
build/assets/roboto-latin-500-normal-b0195382.woff2          15.92 kB
build/assets/logo-b4500173.png                               74.85 kB
build/assets/style-b575b3e9.css                              23.48 kB │ gzip:  10.39 kB
build/assets/react-dea7f807.js                                7.72 kB │ gzip:   3.07 kB │ map:    17.19 kB
build/assets/index-33e96467.js                               80.62 kB │ gzip:  22.25 kB │ map:   337.65 kB
build/assets/konva-52bd506e.js                              198.14 kB │ gzip:  52.88 kB │ map:   706.73 kB
build/assets/mui-e61aa094.js                                294.28 kB │ gzip:  86.68 kB │ map: 1,486.85 kB
build/assets/mui-x-9b59a570.js                              326.95 kB │ gzip:  85.20 kB │ map: 1,243.94 kB
build/assets/vendor-f69745fe.js                             334.14 kB │ gzip: 109.96 kB │ map: 1,426.11 kB
build/assets/react-libs-14a066ad.js                         351.32 kB │ gzip: 109.16 kB │ map: 1,153.99 kB
✓ built in 22.32s

This reveals nicely how much weight each bigger library group bring, specifically MUI-X DataGrid.

Now with smallest treeshaking preset, and module side effects being true:

><EMAIL_ADDRESS>build
> vite build

vite v4.4.9 building for production...
<EMAIL_ADDRESS>(10:12) Use of eval in<EMAIL_ADDRESS>is strongly discouraged as it poses security risks and may cause issues with minification.
<EMAIL_ADDRESS>(175:21) Use of eval in<EMAIL_ADDRESS>is strongly discouraged as it poses security risks and may cause issues with minification.
✓ 12520 modules transformed.
build/index.html                                              1.15 kB │ gzip:   0.46 kB
build/assets/roboto-vietnamese-700-normal-d986b503.woff       4.73 kB
build/assets/roboto-vietnamese-500-normal-7899e6a5.woff       4.73 kB
build/assets/roboto-vietnamese-400-normal-d2390f1a.woff       4.75 kB
build/assets/roboto-vietnamese-300-normal-7747ef64.woff       4.77 kB
build/assets/roboto-vietnamese-300-normal-51f3f418.woff2      5.47 kB
build/assets/roboto-vietnamese-700-normal-4ec57f2a.woff2      5.55 kB
build/assets/roboto-vietnamese-400-normal-77b24796.woff2      5.56 kB
build/assets/roboto-vietnamese-500-normal-0948409a.woff2      5.60 kB
build/assets/roboto-greek-700-normal-3f1a5012.woff            6.30 kB
build/assets/roboto-greek-500-normal-93181eb7.woff            6.32 kB
build/assets/roboto-greek-400-normal-076b9dc1.woff            6.35 kB
build/assets/roboto-greek-300-normal-6bb1ef10.woff            6.44 kB
build/assets/roboto-greek-700-normal-1c9cc76f.woff2           6.94 kB
build/assets/roboto-greek-500-normal-713780d8.woff2           7.02 kB
build/assets/roboto-greek-400-normal-daf51ab5.woff2           7.11 kB
build/assets/roboto-greek-300-normal-455c2c1a.woff2           7.12 kB
build/assets/roboto-cyrillic-400-normal-adba67d2.woff         8.39 kB
build/assets/roboto-cyrillic-300-normal-c07952fe.woff         8.43 kB
build/assets/roboto-cyrillic-700-normal-6f82c5e2.woff         8.66 kB
build/assets/roboto-cyrillic-500-normal-4bc088e9.woff         8.70 kB
build/assets/roboto-cyrillic-300-normal-47aa3bfa.woff2        9.58 kB
build/assets/roboto-cyrillic-400-normal-495d38d4.woff2        9.63 kB
build/assets/roboto-cyrillic-700-normal-6a84eeee.woff2        9.64 kB
build/assets/roboto-cyrillic-500-normal-3728fbdd.woff2        9.84 kB
build/assets/roboto-latin-ext-700-normal-3d1cbacf.woff       10.17 kB
build/assets/roboto-latin-ext-500-normal-a303676a.woff       10.18 kB
build/assets/roboto-latin-ext-400-normal-c2b94086.woff       10.21 kB
build/assets/roboto-latin-ext-300-normal-35da7ccd.woff       10.36 kB
build/assets/roboto-latin-ext-300-normal-b076e863.woff2      11.80 kB
build/assets/roboto-latin-ext-500-normal-7f1c829b.woff2      11.80 kB
build/assets/roboto-latin-ext-700-normal-fc66f942.woff2      11.82 kB
build/assets/roboto-latin-ext-400-normal-3c23eb02.woff2      11.87 kB
build/assets/roboto-cyrillic-ext-700-normal-8ea7934f.woff    13.43 kB
build/assets/roboto-cyrillic-ext-500-normal-57138788.woff    13.45 kB
build/assets/roboto-cyrillic-ext-400-normal-0a32035a.woff    13.47 kB
build/assets/roboto-cyrillic-ext-300-normal-5e06c977.woff    13.55 kB
build/assets/roboto-latin-400-normal-a9fdbefa.woff           14.38 kB
build/assets/roboto-latin-700-normal-d89bc0fc.woff           14.42 kB
build/assets/roboto-latin-500-normal-3ac31048.woff           14.42 kB
build/assets/roboto-latin-300-normal-ddb5c61d.woff           14.59 kB
build/assets/roboto-cyrillic-ext-700-normal-3c505383.woff2   14.68 kB
build/assets/roboto-cyrillic-ext-500-normal-aeed0e51.woff2   14.97 kB
build/assets/roboto-cyrillic-ext-300-normal-435e4b7f.woff2   15.00 kB
build/assets/roboto-cyrillic-ext-400-normal-b7ef2cd1.woff2   15.34 kB
build/assets/roboto-latin-300-normal-f7591131.woff2          15.74 kB
build/assets/roboto-latin-400-normal-f6734f81.woff2          15.74 kB
build/assets/no-image-8357d694.png                           15.80 kB
build/assets/roboto-latin-700-normal-f5aebdfe.woff2          15.86 kB
build/assets/roboto-latin-500-normal-b0195382.woff2          15.92 kB
build/assets/logo-b4500173.png                               74.85 kB
build/assets/style-b575b3e9.css                              23.48 kB │ gzip:  10.39 kB
build/assets/react-b59279c4.js                                7.72 kB │ gzip:   3.07 kB │ map:    17.19 kB
build/assets/index-c50482df.js                               80.56 kB │ gzip:  22.23 kB │ map:   337.61 kB
build/assets/konva-820fa34f.js                              198.11 kB │ gzip:  52.87 kB │ map:   706.68 kB
build/assets/mui-eb20d1d9.js                                294.21 kB │ gzip:  86.61 kB │ map: 1,486.72 kB
build/assets/mui-x-6f6bf450.js                              326.83 kB │ gzip:  85.18 kB │ map: 1,243.90 kB
build/assets/vendor-eccfbc1f.js                             333.61 kB │ gzip: 109.71 kB │ map: 1,420.43 kB
build/assets/react-libs-8e21e2e0.js                         349.55 kB │ gzip: 108.71 kB │ map: 1,151.62 kB
✓ built in 23.76s

@pashidlos any chance of getting this forward?


Frontend and config changes to django-app-template

Fix Vagrantfile configuration so that it actually runs.
Clean up docker-compose.yml for explicitness in volume option, so it gets rid of deprecation warning
Add docker-compose-dev.yml for development purposes
Add root url with custom front pages
Edit README accordingly to replace references to node with django.

@thomaswhyyou I'd like to break this up into much smaller PRs that each reflect one conceptual change. One for serving static content. One for interactive debugging. I think those were the two main theme's, right?
Regarding static content, I don't think it's a good idea to move the static folder up one level. For instance, what would happen if the reverse proxy needs to be deployed on a different physical server than the django server? Alternatively, look at Docker's ability to mount the volumes of another container. You'd need to configure this in the docker-compose.yml file for development and in the Dockerrun.aws.json file for staging and production.
Philosophically, I've been trying to keep the DevOps tools to a minimum, and I haven't yet seen a need to add Ansible, so let's hold off on adding it (or any other new tools) until we literally can't proceed without doing so.
Another principle that I've followed is that I'd like the dev environment to as closely as possible reflect staging and production. This means you should develop against nginx+uwsgi+django. But I think you can run django to auto-reload and to drop into a debugger in this config. You'd just need to be able to run the right django-admin.py commands inside the djangoapptemplate_appsvr_1 container. I think you can do this the same way that you would open a shell inside of the running container using a command like this: 'docker exec -i -t djangoapptemplate_appsvr_1 /bin/bash'.
There should be one and only one docker-compose.yml file in a project, since it's sole purpose is to stand up the dev environment. Let's follow the principles above and revisit how to get interactive debugging working.

@thomaswhyyou check out this and see if there's anything in there that will help with interactive debugging: https://docs.djangoproject.com/en/1.8/ref/django-admin/

@geoffscott Geoff many thanks for the feedback, I appreciate you taking the time to write up. I will give it another go the first thing in the morning, in smaller chunks as you suggested. Some thoughts on your feedback below.

Regarding one and only docker-compose.yml:
I understand your position, I will remove the other. For interacting debugging, from what I researched last week, I didn't see an obvious way to do it while having django run behind nginx+uwsgi; django-admin command you referenced above is in fact what I used in the other docker-compose file (http://bit.ly/1ELr39X) to run the app directly, as "manage.py" is a built-in wrapper around "django-admin.py" with some convenience.

Regarding /ansible folder in .gitignore:
Again I understand your position, I will remove it.

Regarding /static folder:
This one I think was a misunderstanding, and really my fault for it. "one level up" was a reference and relative to what I did before the commit, not what you had originally. In fact there wasn't any static folder to begin with. In any case, I don't quite understand your point about the reverse proxy - unless you are serving static/media files off remote endpoints like S3, nginx needs to have access to these files in its box regardless of where the static directory resides? As you mentioned above, "nginx" container in docker-compose.yml indeed requires "volumes_from" "appsvr" container, as is already (http://bit.ly/1FuxXvb).
I simply created a static directory at the location nginx was configured to find (http://bit.ly/1OthU61); of course this can be configured anywhere else.

Happy to discuss more in person! Thanks again, and I will revert back with new commits in the meantime. Thomas


how to cluster the spots in PASTE integrated slice

A very good software
First,  I learned basic usage using the provided sample data(paste-main/docs/source/notebooks/getting-started.ipynb)
two methods: pairwise_align and center_align
How can I get the PASTE integrated slice?
Is it this：
new_slices = pst.stack_slices_pairwise(slices, pis)
Second, when I get the right integrated slice，how to cluster， kmeans  or other methods ?
Forgive me for not understanding this very well.
Looking forward to your reply

I already know how to deal with it


nCr implementation

💥 Proposal
(A clear and concise description of what the proposal is.)
Have you read the Contributing Guidelines on Pull Requests?
CPP function to which return number of ways of selecting r items from n items which will take input parameters as n & r

/assign


My Sonos Node - 'length' of undefined error

I'm using your latest code and all works fine besides the My_Sonos_Node getting the following error
get My Sonos items: Cannot read property 'length' of undefined :: Details: {"stack":"TypeError: Cannot read property 'length' of undefined\n    at Object.parseSonosPlaylistsResult (/home/pi/.node-red/node_modules/node-red-contrib-sonos-plus/src/Sonos-Commands.js:942:35)\n    at runMicrotasks (<anonymous>)\n    at processTicksAndRejections (internal/process/task_queues.js:97:5)\n    at async Object.getAllSonosPlaylists (/home/pi/.node-red/node_modules/node-red-contrib-sonos-plus/src/Sonos-Commands.js:644:32)\n    at async getAllMySonosItemsV2 (/home/pi/.node-red/node_modules/node-red-contrib-sonos-plus/src/Sonos-Commands.js:625:32)","message":"Cannot read property 'length' of undefined"}
thanks for any advise

Sorry, It is already raised as issue


Dryad API output change forces complete reingest of all Dryad material

With version v0.7.09 of Dryad:

The Dryad  API has changed slightly
Dryad file download paths have changed, whether as a result of the new release or whether the internal structure of Dryad has changed is not clear.

This resulted in two things:

The output JSON of Dryad studies changed, which means all metadata was listed as changed as metadata changes were tracked by the changes in the JSON itself.

One notable feature: The "relationship" keywords appear to have changed. "article" is now "primary_article"

The file path was used in the identification of files. This means dryad2dataverse thought all files had changed.
As md5s are not generated by by Dryad, files were identified as unchanged when the file download path and the size were identical. File download paths have changed as they are apparently based on an internal database identifier, so dryad2dataverse reports that all files have changed.

Obviously, if all the files and all the metadata changed, that is a complete reharvest, which is by no means ideal.
Note that dryad2dataverse will still function as designed, but, in essence, there will be a new "version" of data which has basically the same metadata and data, and thus storage space will be doubled. Depending on the size of your dryad material, this may or may not be an issue.
Should you wish to see if an fix is possible and you have not already published any changes, if you have not published any updates since 21 October 2021,

Keep the October or earlier database as a reference
Delete the unpublished drafts
Await a fix (which currently has no estimated time).

If you a have already updated and published, no action should be required and your current version of dryadd.py will function properly. You will just have duplicate files and very similar metadata.

"This means dryad2dataverse thought all files had changed." sigh...

As of 0.7.06  2021-10-26 End of sprint release https://github.com/CDL-Dryad/dryad-app/releases:
When the API returns a “version” object, that object now includes a versionChanges field indicating whether data files were changed.
From https://github.com/CDL-Dryad/dryad-app/blob/d68378d1fa0fffdd75f811de6eb2c63233251f82/stash/stash_api/public/openapi.yml
 versionChanges:
              type: string
              description: Whether this version has had files_changed, or only metadata_changed
lastModificationDate:
              type: string

This will clearly help somewhat in identifying types of changes.

From https://github.com/CDL-Dryad/dryad-app/blob/a8ec4923fa1f39a222d0b0085d698c51a71377bb/stash/stash_api/app/models/stash_api/version/metadata.rb the only possible values of versionChanges are files_changed and metadata_changed.
My examination of the json output shows that the fileIDs have in fact changed for all files. The mechanism used to identify was a change in any of fileID, size and name. If file_id is changeable. FileID was important because it would indicate a new upload if changed (or that was my assumption). Mismatches or even matches between just size and name are not necessarily reliable indicators of change. Maybe they will have to do.

Resolved with v0.3.1 release


Stack overflow running SunSpider controlflow-recursive.js

I setup a simple sunspider runner here (pardon my C): https://github.com/littledivy/sunspider_quickjs_ng
Edit: I'm running on macOS, might need some modification for Linux.
To reproduce:
git clone https://github.com/littledivy/sunspider_quickjs_ng
cd sunspider_quickjs_ng

git clone https://github.com/quickjs-ng/quickjs
cmake -B build
cmake --build build
./build/quickjs_bench

You'll see this in the output:
Error InternalError: stack overflow
Error executing file: controlflow-recursive

Can you try unsetting this to check if the stack just grows too large? https://github.com/quickjs-ng/quickjs/blob/54a4f2907ea606ed1eacea9f891a1617ad75becb/quickjs.c#L70

Its working with that disabled. File: controlflow-recursive, Execution Time: 0.0061 seconds

It works with a larger stack size.


Delete FAQ

towards 14729 and 10731 in SIG Docs.
Is it as simple as deleting the document? Do any additional links need to be taken care of?

Have you checked if the FAQ is not linked somewhere?

It has to be removed from the main menu. That's done in src/config.toml. Delete lines 40 to 43.


Reflect the schema changes

This PR will be closed once https://github.com/Ensembl/ensembl-metadata-service/pull/25 is merged

Update Metadata service to reflect the schema changes done in
https://github.com/Ensembl/ensembl-metadata-api/pull/33
JIRA ticket
https://www.ebi.ac.uk/panda/jira/browse/EA-1103
Changes

Removed url_name from Organism and replaced display_name with common_name
Added the possibility to fetch unreleased genomes to get_genome_by_uuid(), example below:

{
	"genome_uuid": "a7335667-93e7-11ec-a39d-005056b38ce3",
	"release_version": -1
}

This fetches all released and unreleased genomes with genome_uuid = a7335667-93e7-11ec-a39d-005056b38ce3

These changes are deprecated and most of them are already merged (from other branches)


[Windows] Use hpc base image and buildx to build Agent Windows image

The changes in this patch include,

Use Windows hpc as the base image to store Antrea binary and OVS files
Use doocker buildx to build Windows image on Linux base environment
Modify OVS init container to install redist files
Place openssl dll files into OVS binary directory instead of Windows system path

Using the hpc base image and buildx on a fresh env, the time to build Windows related
images is as follows,

windows-ovs: 22.4s
windows-base: 15s
antrea-windows: 190s

Fix #6311

/test-windows-e2e

/test-windows-e2e

/test-windows-all

/test-windows-all

/test-windows-all

/test-windows-all

/test-windows-containerd-conformance

/test-windows-all

Windows CI tests have passed.

/test-windows-all

/test-windows-all

/test-windows-all

/skip-all
/test-windows-all

@antoninbas Can we move this change forward or we shall wait for another round of review?

/test-windows-e2e


SolrNet issues GET requests even though PostSolrConnection is registered

Hi,
I'm having the following issue. I use SolrNet <IP_ADDRESS> and I would like to change from GET to POST because my queries can get large enough to surpass the default GET header size. I can certainly change that limit in jetty, but i would just like to switch to POST, to be on the safe side. So i am doing the following:
        var container = new WindsorContainer();
        var solrFacility = new SolrNetFacility(url);
        solrFacility.AddCore(url, typeof(Dictionary<string, object>), url);
        container.AddFacility(solrFacility);
        container.Register(Component.For<ISolrConnection>()
.ImplementedBy<PostSolrConnection>().DependsOn(Parameter.ForKey("serverUrl").Eq(url)));
        var solr = container.Resolve<ISolrOperations<Dictionary<string, object>>>(url);

After that, requests are still GET, not POST. I assume this is a bug in SolrNet?
Thanks
Angel

Current issue has been closed as part of cleanup process, which is tracked in https://github.com/SolrNet/SolrNet/issues/338.
Please reopen if needed, hopefully helping bringing up to date with current code.

I am having the same issue. My code is almost identical to op's except that I am using a custom object instead of a "Dictionary<string, object>" as the object type yet the requests being sent from SolrNet are still GET and not POST as desired. Has this been resolved yet or am I missing something?


Bump version to 2.0.1

Bump version to 2.0.1

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

Comparison is base (aa5ecda) 100.00% compared to head (f9a6cfd) 100.00%.
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #147   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            7         7
  Lines          733       733
  Branches        87        87
=========================================
  Hits           733       733

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


os: Avoid mutating the args in getAvailableOsVersions & getAllOsVersion

Change-type: patch
Signed-off-by: Thodoris Greasidis<EMAIL_ADDRESS>
Contributor checklist

[ ] Includes tests
[ ] Includes typings
[ ] Includes updated documentation
[ ] Includes updated build output

@balena-ci I self-certify!


Fishbowl generated code is not compliant with PEP8

The Python code generated by fishbowl is not PEP8 compliant and this causes a PEP8 change to be required every time the Gaffer version is upgraded.
This problem relates to Python imports and can be seen here.

This problem was caused by #44 where a space was removed because it was potentially considered to be a typo.


logo

Related https://github.com/cytomining/pycytominer/issues/299

@gwaybio Ready to merge (I don't have permissions to merge or request review)


MessagingCenter.Subscribe callback is not fired on PageModel

I am trying to make a shopping app using FreshMVVM.
I created two pages HomePage and BasketPage (the pagemodels are HomePageModel and BasketPageModel respectively).
HomePage will defined a listview of items and each item will have a button Order. When user clicks Order on a certain item then it will bind to command AddToBasketCommand in the pagemodel.
The command will Send a message (using MessingCenter) with parameter is the item orderred. The code to initialize the command in HomePageModel constructor like this
AddToBasketCommand = new Command<FoodItem>(async (FoodItemfood) =>
{
       await Task.Delay(10);
       MessagingCenter.Send(this, MessageKeys.AddFood, food);
});

On BasketPageModel, I subscribed the message in Init function
public class CartPageModel : FreshBasePageModel
{
       ...
      public override void Init(object initData)
      {
            MessagingCenter.Unsubscribe<HomePageModel, Menu_Tbl>(this, MessageKeys.AddFood);
            MessagingCenter.Subscribe<HomePageModel, Menu_Tbl>(this, MessageKeys.AddFood, async (sender, arg) =>
            {
                Console.WriteLine("Callback for AddToBasketCommand was fired");
                //do some stuffs
            }
       }

When I run the app and click on Order button, the command was binded sucessfully but the callback on MessagingCenter.Subscribe on BasketPageModel is not triggerred.
Can anyone help me on this bug. Thanks

@lucastien as a work around can you get the subscribed callback to be invoked in the page of the page view model and then using the binding context do what you need on the view model?


About the dependency with "guzzlehttp/guzzle"

Hi.
Since laravel8 was recently released I attempted to install it.
According to the installation guide, I need to set up the following dependencies, so I put them in the "composer.json".

guzzlehttp/guzzle to ^7.0.1
facade/ignition to ^2.3.6
laravel/framework to ^8.0
nunomaduro/collision to ^5.0
phpunit/phpunit to ^9.0

And when I try to run "composer update", I get the following error:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1

Installation request for guzzlehttp/guzzle ^7.0.1 -> satisfiable by guzzlehttp/guzzle[7.0.1, 7.0.x-dev, 7.1.x-dev].
danielme85/laravel-geoip2 v1.0 requires guzzlehttp/guzzle ~6.0 -> satisfiable by guzzlehttp/guzzle[6.5.x-dev].
danielme85/laravel-geoip2 v1.0 requires guzzlehttp/guzzle ~6.0 -> satisfiable by guzzlehttp/guzzle[6.5.x-dev].
Conclusion: don't install guzzlehttp/guzzle 6.5.x-dev
Installation request for danielme85/laravel-geoip2 ^1.0 -> satisfiable by danielme85/laravel-geoip2[v1.0].

Does laravel-geoip2 not support guzzlehttp/guzzle 7.0.1?
Is it possible to change the guzzlehttp/guzzle dependency in laravel-geoip2 to 7.0.1?
Thank you.

Hi @poinchy,
I'll take a look tonight. Hopefully just need to update the composer file.
Hmm, they seem to have dropped PHP 5 support in Guzzle 7.
https://github.com/guzzle/guzzle/blob/master/UPGRADING.md
I might split this project into legacy PHP5/Guzzle6 and then make the "default" PHP7/Guzzle7.
Thank you for the heads-up, I have been thinking about starting to test my projects with Laravel 8, you beat me to it 👍
-dan

Just pushed an updated composer file to the dev branch, you could give that a try?

Merged dev branch into master b59922f56bed998c394aad03e1affe3a56589e03

Thank you so much for your prompt response!
I was able to install Laravel 8 successfully.

No problem, again thanks for the heads-up!


Agree on support for Sara with the meetings

What
Agree on support for Sara with the style council meetings.
Why
The current process is solely reliant on Sara and she could do with some support.
Done when

[ ] review current process
[ ] brainstorm ideas

See Jira for post-it exercise: https://jira.service.nhs.uk/browse/STAN-1628

Arranged meeting for Wednesday 21 October.

Discussed:

help with updating mailing list and arranging meetings - Lucy
help with GitHub prioritisation exercise - Dave and Tosin
sorting out GitHub content issue backlog - Henry

We'll talk further with the content profession about support with content style processes and Style Council meetings at December Style Council meeting.


Migrate to RxSwift==5.1 and Starscream==4.0

Test is here https://github.com/NiftyStack/RxStarscream/pull/2/checks?check_run_id=771254365


Make duration from minutes to seconds

Currently we are using minutes for duration. This proves to be coarse for some users and they would like to use seconds instead.
Given compatibility concern, we could change the current duration in int to float. So 0.2 min could be translated into 12 seconds.
ref: https://github.com/rakutentech/shibuya/blob/master/shibuya/engines/jmeter/shibuya-agent.go#L312

hmm, maybe use 30sec is better.
So if user is still using 30, it will be 30mins, which is the current logic.
If user input 30sec in the YAML, it will be treated as 30 seconds.

Currently, it's being on hold. There are couple of reasons:

A one second test plan would not make sense. Moreover, our metrics would not be able to support such short duration. It's also a waste of resources, especially at GCP side, which means we might need some validation, which would complicate things up.
More importantly, backward compatibility. All the plans now are using minutes. It needs some effort to support both min and sec. Otherwise, we need to do migration.

Won't do.


About this source

Hi,
I used this source two years ago, and at that time I used android 4.4 to run.
I know that this source can't run on Android 6.0 or larger.
So, i want to know if anyone knows the idea about how to solve the problem( just want to know a way to solve it, cuz i have no idea) .
Thanks.

If you want do a stream you can use this:
https://github.com/pedroSG94/rtmp-rtsp-stream-client-java

Thanks for reply!
I will try this solution.


User provided rule sets

Hi there,
To write my own rules to match my organisations API standards (and remove some existing rules I don't want), do I take the source code for the current release, write my own rules within the de.zalando.zally.rule.zalando/zally packages, then build and run?
This doesn't feel right - Is there a recommended way of editing existing rules/adding new rules for those outside of the Zalando organisation?
Thanks,
Ryan

Yup. It's a little crazy but my company maintains an internal fork of Zally with our own custom rules and config added. There's some effort towards #551 leading towards #560 but it's slow progress - my motivation has dropped a little since the crazy internal fork approach is working well enough for my team.


Update Swagger UI Version

What's this PR do/fix?
-> Swagger UI update version (2.2.10 -> 3.0.2)
Are there unit tests? If not how should this be manually tested?
-> There aren't any unit tests for this as it's an external dependency
Any background context you want to provide?
-> No
What are the relevant issues?
-> #1729

Have you tested that it works? its not about just changing the version

@dilipkrish Can you please highlight the steps required for transition to swagger-ui 3.0?
I'm interested in some bugfixes contained only in the 3rd version.


ZS_PR

Great work! I loved getting a sneak peek at some NLP in R!

@datalorax

(Also, my notes/comments are all in the code! I see that other folks added things in the comments, sorry for inconvenient formatting!)

Thanks Zach, and no worries at all! I always review both so either way is fine. Really nice review!

Thank you for your thoughtful comments, Zach!
Get Outlook for iOShttps://aka.ms/o0ukef

From: Daniel Anderson<EMAIL_ADDRESS>Sent: Wednesday, March 3, 2021 4:44:27 PM
To: makwhit6/datavizfinalproject<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [makwhit6/datavizfinalproject] ZS_PR (#3)
Thanks Zach, and no worries at all! I always review both so either way is fine. Really nice review!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/makwhit6/datavizfinalproject/pull/3*issuecomment-790193328__;Iw!!C5qS4YX3!SN3MnBfWTtGxAE-TnBhO3WjS-GSZuenRp-lzlteE5KVXDeugnmAHVfIm57fHlaczm4U$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ARFVAQTU2KBQH2B4SDNX64DTB3JWXANCNFSM4YQIZ3ZQ__;!!C5qS4YX3!SN3MnBfWTtGxAE-TnBhO3WjS-GSZuenRp-lzlteE5KVXDeugnmAHVfIm57fHwE2TnYA$.


#256 slot report

gets saved to the local dir. could put in an assets dir instead. have published one time at https://docs.google.com/spreadsheets/d/1yTCqZojqoLPa0Y97ZYcyFuEG-u-oXf7OSCvq9Hu4dCQ/edit#gid=0

could also do a long format, and include a 'preferred replacement value' column. For example, I think there is an interest in using slot usage to assign a description value of 'a human-readable description of a thing'  to the description  slot on the study class.

@turbomam I'm not sure what you mean by using slot_usage. You can override the descriptions for slots (of course), but I do not think you can override descriptions for classes (I could do this locally). Perhaps you make use of the alt_descriptions slot?
Also, can you open up access to the google sheet to anyone with a link?

I do not think you can override descriptions for classes (I could do this locally). Perhaps you make use of the alt_descriptions slot?

yes, good points @wdduncan

can you open up access to the google sheet to anyone with a link?

I opened it up for viewing to anyone with a link. Did you want it world editable @wdduncan ?

@turbomam I was thinking it would be helpful if anyone with a link could view the google sheet.


Frameworks not imported

Hi,
I downloaded it through Carthage, imported the ImagePickerSheetController in Build Phases, and copied the swift files with the classes in it, but Xcode doesn't find the XCTest, Nimble,... So I thought I needed to import them, but I can't seem to find them in the Carthage build. Am I doing this the totally wrong way?
Awesome ImagePicker design!
Thanks

I keep getting this one error after successfully importing the framework etc, how could I fix this?

I was able to fix my mistake, I was just hadn't declared the presentImagePickerController, because this wasn't in the example on GitHub, would recommend to add that


Shipping method - Droppoints

Hi!
I'm working on making support for shipping droppoints(parcelshops). It's quite a big thing here in Denmark, so it's something that all projects we will be working on will be using.
So first things first, is this something that would make sense to "bake-in" to vue-storefront or should it be implemented more in a plugin/per use basis.

Wow, cool stuff. We’ve decided some time ago to put all integrations and this kind of specific features into extensions. Take a look at mailchimp integration. Looking forward for this PR!

#681

@thomasthune it's assigned to Milestone 1.0RC - will you do it before 1st of March or should we move it to next milestone?

Yes, i don't think that should be a problem, hopefully i can wrap it up during the weekend.

Thanks ;)


Updating tests

keep the current tests, and add something that travis can pass might be good.

https://github.com/audiojs/contributing/issues/13


Introduce npm workspaces or lerna

Too much effort going into different folders and npm installing smh my head

Solved by #169


Don't include duplicate columns in join

But how to implement while working around lambda keys?

Nevermind, this already happens


Fix project links in package.json

Some links were still referencing the old repo name (gaearon/react-redux). Not a huge issue since the old URL redirects, but might as well use the correct URL since some tools display these as-is to end users (eg. yarn via yarn outdated) which can potentially be confusing.

Hah, that's been around for a while :)  Nice catch - thanks!


shellcheck

Shellcheck suggestions, minor formatting consistencies, and adding escaped quotes to the listitems concatenation.

Derp. The edit on L#88-L#92 will still break; need to use an array or call the command directly. Cancelling PR for now.

no worries. TBH I should be setting up shellcheck on these (which I would probably do more often if it supported zsh)


Any push fails with invalid header field value Bearer for key Authorization

Gitea version (or commit ref): 1.11.5
Git version:
Operating system: kubernetes 1.18, exposed via NGINX Ingress
Database (use [x]):

[ ] PostgreSQL
[X] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[X] No
[ ] Not relevant

Log gist:

Description
Installed gitea using helm chart https://github.com/k8s-land/gitea-chart
Values below.
I can register and sign into gitea and create a repo.
However as soon as I try to add a file or modify a file (in gitea UI), I get the following error message:
The change was rejected by the server with the following message:
Gitea: Internal Server Error
Unable to contact gitea: Post http://<IP_ADDRESS>:3000/api/internal/hook/pre-receive/dynatrace/test: net/http: invalid header field value "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1ODk0NTQxOTJ9.iWBvmOHvMVDnPNwVtNaAZ91gMBPljH-3lDVvM0_0HEE\n" for key Authorization
Please check githooks.

I believe the \n at the end of the bearer token might have something to do with it but I am not sure.
I have the same issue on the command line:
$ git push
Username for 'http://gitea.<IP_ADDRESS>.xip.io': dynatrace
Password for<EMAIL_ADDRESS>Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 247 bytes | 247.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Gitea: Internal Server Error
remote: Unable to contact gitea: Post http://<IP_ADDRESS>:3000/api/internal/hook/pre-receive/dynatrace/test: net/http: invalid header field value "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1ODk0NTQxOTJ9.iWBvmOHvMVDnPNwVtNaAZ91gMBPljH-3lDVvM0_0HEE\n" for key Authorization
To http://gitea.<IP_ADDRESS>.xip.io/dynatrace/test
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'http://gitea.<IP_ADDRESS>.xip.io/dynatrace/test'

Any help would be greatly appreciated!
## Gitea image
## ref: https://hub.docker.com/r/gitea/gitea/tags/
##

tags:
  mariadb: true

images:
  registry: docker.io
  gitea: "gitea/gitea:1.11.5"
  memcached: "memcached:1.5.19-alpine"
  pullPolicy: IfNotPresent

## Cache settings for memcache
memcached:
  maxItemMemory: 64
  verbosity: v
  extendedOptions: modern

## Configure the ingress resource that allows you to access the
## Gitea installation. Set up the URL
## ref: http://kubernetes.io/docs/user-guide/ingress/
##
ingress:
  enabled: true
  certManager: false
  hostname: gitea.<IP_ADDRESS>.xip.io
  annotations: {}
  secrets:

## This chart defaults to using an ingress for http, but change to LoadBalancer if using you cluster supports it
service:
  http:
    serviceType: ClusterIP
    port: 3000
    externalHost: gitea.<IP_ADDRESS>.xip.io

  ## SSH is commonly on port 22.. however.. you most likely already have port 22 being used by your node.
  ## so we use port 8022.
  ssh:
    serviceType: LoadBalancer
    port: 22
    externalPort: 8022
    externalHost: gitea.<IP_ADDRESS>.xip.io
    externalIPs: []

## Configure resource requests and limits
## ref: http://kubernetes.io/docs/user-guide/compute-resources/
##
resources:
  gitea:
    requests:
      memory: 500Mi
      cpu: 300m
    limits:
      memory: 2Gi
      cpu: 1
  memcached:
    requests:
      memory: 64Mi
      cpu: 50m

## Enable persistence using Persistent Volume Claims
## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
## ref:
##
persistence:
  enabled: true
  giteaSize: 10Gi
  accessMode: ReadWriteMany
  annotations:
    "helm.sh/resource-policy": keep

##
## MariaDB chart configuration
##
## https://github.com/helm/charts/blob/master/stable/mariadb/values.yaml
##
mariadb:
  enabled: true
  replication:
    enabled: false
  db:
    name: gitea
    user: gitea

  rootUser:
    password: ThisIsMySuperSecretPassword

  master:
    persistence:
      enabled: true
      accessMode: ReadWriteOnce
      size: 8Gi

config:
##  secretName: "<Existing Secret Name>"
##  secretKey: "<random>"  # Generate with 'gitea generate secret SECRET_KEY'
##  jwtSecret: "<random>"  # Generate with 'gitea generate secret JWT_SECRET'
##  lfsJwtSecret: "<random>"  # Generate with 'gitea generate secret LFS_JWT_SECRET'
##  internalToken: "<random>"  # Generate with 'gitea generate secret INTERNAL_TOKEN'
  disableInstaller: false
  offlineMode: false
  requireSignin: false
  disableRegistration: false
  openidSignin: true
  immutableConfig: false  # Regenerate config every time, and set as read-only

## Common helm annotations
## Node labels and tolerations for pod assignment
## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature
nodeSelector: {}
tolerations: []
affinity: {}

## Annotations for the deployment and nodes.
deploymentAnnotations: {}
podAnnotations: {}

...
Screenshots

I've got the same error running gitea 1.11.5 on a kubernetes 1.18 cluster but a postgreSQL on the backend. The gitea service is exposed via a netscaler adc reverse proxy.
I migrated from an older installation. The error will show up regardless if it is an "old" repository or a newly created repository.
I tried changing the log level in the gitea installation, but no error regarding this push will show up in the gitea log.
I also regenerated the hooks as described in the documentation:
./gitea admin regenerate hooks -c /data/gitea/conf/app.ini
-> No change

@kristofre The hint is here:
Unable to contact gitea: Post http://<IP_ADDRESS>:3000/api/internal/hook/pre-receive/dynatrace/test: net/http: invalid header field value "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1ODk0NTQxOTJ9.iWBvmOHvMVDnPNwVtNaAZ91gMBPljH-3lDVvM0_0HEE\n" for key Authorization

You need to set the INTERNAL_ROOT_URL and INTERNAL_TOKEN appropriately. Gitea's serv / hook cannot communicate with the running Gitea server

Unfortunately this was an error in the chart, see the PR here that broke it: https://github.com/k8s-land/gitea-chart/pull/13
We've reverted the PR and submitted a new char version as per:
k8s/k8s-land/charts  master ✔                                                                                0m
▶ helm search repo k8s-land -l
NAME            CHART VERSION   APP VERSION     DESCRIPTION
k8s-land/gitea  1.3.3           1.11.5          Git with a cup of tea
k8s-land/gitea  1.3.1           1.11.4          Git with a cup of tea
k8s-land/gitea  1.3.0           1.11.3          Git with a cup of tea
k8s-land/gitea  1.2.3           1.10.1          Git with a cup of tea
k8s-land/gitea  1.2.2           1.9.3           Git with a cup of tea
k8s-land/gitea  1.2.1           1.9.3           Git with a cup of tea

This issue can be closed.
PIng @kristofre @zeripath @Anganthier


Pod creation issue on Task retry with workspace.<name>.volume settings

Expected Behavior
The pipeline should be able to retry normally.
Actual Behavior
When retrying, the pipeline is unable to create the Pod for the retry.
failed to create task run pod "test-sidecar-workspace-run": Pod "test-sidecar-workspace-run-pod-retry1" is invalid: spec.containers[0].volumeMounts[0].name: Not found: "ws-jchh2". Maybe missing or invalid Task default/test-sidecar-workspace

Steps to Reproduce the Problem

Create the following Task and TaskRun.

cat <<'EOF' | kubectl replace --force -f -
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: test-sidecar-workspace
spec:
  workspaces:
  - description: cache
    name: cache
  steps:
  - name: command
    image: alpine
    volumeMounts:
    - mountPath: /cache
      name: $(workspaces.cache.volume)   # <-- It's this configuration that caused the above problem.
    script: |
      #!/bin/sh
      set -ex
      echo "hello world"
      exit 1
---
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: test-sidecar-workspace-run
spec:
  taskRef:
    name: test-sidecar-workspace
  retries: 1
  workspaces:
  - name: cache
    emptyDir: {}
EOF

Wait for the TaskRun to be processed.

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  generation: 1
  labels:
    app.kubernetes.io/managed-by: tekton-pipelines
    tekton.dev/task: test-sidecar-workspace
  name: test-sidecar-workspace-run
spec:
  retries: 1
  serviceAccountName: default
  taskRef:
    kind: Task
    name: test-sidecar-workspace
  timeout: 1h0m0s
  workspaces:
    - emptyDir: {}
      name: cache
status:
  completionTime: "2024-04-16T09:58:14Z"
  conditions:
    - lastTransitionTime: "2024-04-16T09:58:14Z"
      message:
        'failed to create task run pod "test-sidecar-workspace-run": Pod "test-sidecar-workspace-run-pod-retry1"
        is invalid: spec.containers[0].volumeMounts[0].name: Not found: "ws-jchh2".
         Summary

During the first reconciliation, the variable workspace.<name>.volume in the taskSpec was replaced with a random value.
The modified taskSpec was then stored in the taskRun.status.taskSpec.
When retrying, the replaced value of taskSpec from the status was used directly.
However, in CreateVolumes, the workspace’s name was generated again.
The newly generated volume name this time was inconsistent with the first one, which caused the above issue.

1. reconcile -> CreateVolumes && applyParamsContextsResultsAndWorkspaces && createPod
https://github.com/tektoncd/pipeline/blob/f0a1d64aa88929f8915f208db65a8f731b5c92e2/pkg/reconciler/taskrun/taskrun.go#L617-L635
2.1 CreateVolumes -> RestrictLengthWithRandomSuffix
https://github.com/tektoncd/pipeline/blob/f0a1d64aa88929f8915f208db65a8f731b5c92e2/pkg/workspace/apply.go#L45-L82
2.2 RestrictLengthWithRandomSuffix -> random string
https://github.com/tektoncd/pipeline/blob/f0a1d64aa88929f8915f208db65a8f731b5c92e2/pkg/names/generate.go#L54-L61
3.1 applyParamsContextsResultsAndWorkspaces -> ApplyWorkspaces
https://github.com/tektoncd/pipeline/blob/f0a1d64aa88929f8915f208db65a8f731b5c92e2/pkg/reconciler/taskrun/taskrun.go#L905-L946
3.2 ApplyWorkspaces -> ApplyReplacements
https://github.com/tektoncd/pipeline/blob/f0a1d64aa88929f8915f208db65a8f731b5c92e2/pkg/reconciler/taskrun/resources/apply.go#L277-L310
3.3 workspaces.%s.volume
https://github.com/tektoncd/pipeline/blob/f0a1d64aa88929f8915f208db65a8f731b5c92e2/pkg/reconciler/taskrun/resources/apply.go#L299-L301
4. Set replaced taskSpec to TaskRun Status
https://github.com/tektoncd/pipeline/blob/f0a1d64aa88929f8915f208db65a8f731b5c92e2/pkg/reconciler/taskrun/taskrun.go#L625
5. reconcile -> prepare -> GetTaskFuncFromTaskRun
https://github.com/tektoncd/pipeline/blob/f0a1d64aa88929f8915f208db65a8f731b5c92e2/pkg/reconciler/taskrun/resources/taskref.go#L55-L79
if the spec is already in the status, do not try to fetch it again, just use it as source of truth.
Solution
1. The content stored in taskRun.status.taskSpec is the original content of taskSpec, rather than the values after variable substitution.
Advantages: It's very versatile and there is no need to worry about retries being affected even if similar random variables are introduced in the future.
Disadvantages: The information in taskus.taskSpec is no longer intuitive. It's impossible to directly see the actual variable values during execution.
2. Each time the taskSpec definition is acquired, it is fetched from the remote end, rather than reusing the one in the status.
Disadvantages: It needs to be fetched every time reconciliation occurs, which is not very practical.
3. Change the method of generating volume names
No longer be completely random, but rather to hash the original name. Make sure that the name generated each time is the same and is not duplicated within the current workspaces.
In the current taskSpec, only the value of workspace.<name>.volume may be different each time; the values of other variables are fixed and will not change anymore.
I personally prefer to fix it using this solution.
4. Remove support for workspace.<name>.volume

/assign

@l-qing I am facing this issue as well: Is there any manual workaround? Will this be backported to older stable versions?

I am facing this issue as well: Is there any manual workaround? Will this be backported to older stable versions?

I didn't find a manual solution.
I thought it was a low probability issue, so I didn't consider reverting to the old stable version.
If you think it's necessary, you can ask @vdemeester for help.


features.npy

Where can we obtain this file from? It is not included in the Flickr 30K dataset
http://shannon.cs.illinois.edu/DenotationGraph/data/index.html

Sorry, missed it out in the ReadMe
You have to generate features.npy by running convfeatures.py
Usage:
python convfeatures.py

Indeed.
Many thanks


restat target as dirty when manifest file is rebuilt

rule regen_ninja
 command = touch build.ninja
 generator = 1
 description = Regenerate ninja files due to dependency
build build.ninja: regen_ninja envlist

build .always_build: phony
rule regen_envlist
 command = rm -f $out.tmp && echo ENVTEST=$$ENVTEST >> $out.tmp && (diff $out.tmp $out || mv $out.tmp $out)
 restat = 1
 generator = 1
 description = Check $out
build envlist: regen_envlist .always_build

This worked in old ninja, but ninja 1.6 fails as
[1/2] Check envlist
....
[1/2] Check envlist
ninja: error: manifest 'build.ninja' still dirty after 100 tries
bisect revealed that commit 5fbfa4ba72883cc0ecd199d17a70da3698be0402 is culprit.

This is essentially a dupe of #987 – see there for some discussion and possible workarounds. I agree that something needs to be done here.

I solved the "ninja: error: manifest 'build.ninja' still dirty after 100 tries" problem by locating every build.ninja file in my project, editing it (space then backspace) then saving it.  Buggy software.


[state-of-the-world reconciler] DNSPolicy status

Move the business logic of DNSPolicy status reconciliation to a workflow state-of-the-world reconcile func.

Closed by https://github.com/Kuadrant/kuadrant-operator/pull/937


Jobs will not support populating container names, we need to support that

The way we auto populate container names, we should be able to do that when jobs are implemented. Currently, in kubernetes.go, it is tied to app.PodSpec.Containers, we need to generalize that.
Basically abstract this out for jobs -
https://github.com/kedgeproject/kedge/blob/master/pkg/transform/kubernetes/kubernetes.go#L386-L397

Basically abstract this out for jobs -
https://github.com/kedgeproject/kedge/blob/master/pkg/transform/kubernetes/kubernetes.go#L386-L397

shows some random thing, maybe tag the link with a commit

@surajssd -
	// if only one container set name of it as app name
	if len(app.PodSpec.Containers) == 1 && app.PodSpec.Containers[0].Name == "" {
		app.PodSpec.Containers[0].Name = app.Name
	} else if len(app.PodSpec.Containers) > 1 {
		// check if all the containers have a name
		// if not fail giving error
		for cn, c := range app.PodSpec.Containers {
			if c.Name == "" {
				return nil, fmt.Errorf("app %q: container name not defined for app.containers[%d]", app.Name, cn)
			}
		}
	}

this should happen in the fix.go with everything else

This will work because the pod spec in jobs will be our own PodSpecMod so the naming thing will be taken care of there.

This is invalid issue, since it does not hold true also job support has been added!

Since https://github.com/kedgeproject/kedge/pull/253 is merged closing this one!


Feature Request: DatePickerFormField Widget

A normal use case for the DatePicker is to use it with a TextField and a Form to take date inputs.
We could create a convenience widget that composes TextField or TextFormField with a DatePicker, since I would imagine that it is a common use case that can be simplified for developers.
cc/ @hillelcoren

Totally agree. Currently, it's difficult to coordinate a TextField and the date picker like disable the editing, setting the date back to the Textfield, etc.  It would be great if you add TimePicker support too.

This seems like something that should be relatively straight-forward to build; if a precanned version would be useful, it could be created as a package. Unless the material spec has such a widget, though, it's probably best not to have it in the core given the maintenance cost.


Broken "Visualizing the Substrate code base" link

Broken Link
https://octo-repo-visualization.vercel.app/?repo=paritytech%2Fsubstrate
Expected Location
No response
Context and Origin
On the Libraries page the link Visualizing the Substrate code base is broken (returns 404)

Thanks for catching this!
Because this was a link to an external tool, there's no "fix" except to remove it.


Remove git import references and colon use clauses in docs

This PR does:

Uses the package name version instead of the scoped one in docs (openzeppelin_token instead of openzeppelin::token), since this version always works no matter if the user declares the standalone version or the full library.
Removes git references when declaring packages in Scarb.toml, and uses registry instead.

The changes look good to go! Do you remember the reason why we didn't do this when we migrated to multiple packages?

I honestly don't remember, but maybe it is because we weren't sure that the imports would work with both approaches.


feat(security): Cleanup Vault TLS related overrides

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[X ] Docs have been added / updated (for bug fixes / features)

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/developer-scripts/blob/master/.github/Contributing.md.
What is the current behavior?

Current override values for Vault still using TLS related values but should be cleaned up.
Issue Number: #353
What is the new behavior?
Vault TLS-related overrides should be cleaned up
Does this PR introduce a breaking change?

[ ] Yes
[X ] No

Specific Instructions
Are there any specific instructions or things that should be known prior to reviewing?
Note:  For this compose up working correctly, it requires the following two PRs merged into master first:

https://github.com/edgexfoundry/edgex-go/pull/2890
PR #350

Other information
If tested locally, do the following steps:

Clone the code from https://github.com/edgexfoundry/edgex-go/pull/2890
Build the latest docker images for edgex-go: make docker
Clone the code from https://github.com/edgexfoundry/docker-edgex-consul/pull/40
Build the latest edgex-core-consul docker image: make docker
Go to compose-builder sub-directory and do make gen dev to generate the local version of docker-compose.yml to run
Modify the edgex-core-consul docker image in the generated docker-compose file to point to the local built docker image above:image: edgexfoundry/docker-edgex-consul:0.0.0

In the command-line, run docker-compose up and all services should started up ok (can be checked and see using docker ps and individual docker logs via portainer).   Also it should be ok in the docker logs edgex-core-consul

I'm getting an error @ step 2 when running the testing instructions listed in the PR description.

I'm getting an error @ step 2 when running the testing instructions listed in the PR description.
Step 21/25 : RUN pip install docker-compose==1.23.2 ---> Running in 4b39d48641e3 /bin/sh: pip: not found The command '/bin/sh -c pip install docker-compose==1.23.2' returned a non-zero code: 127 make: *** [Makefile:161: docker_sys_mgmt_agent] Error 127
Looks like this is when it's attempting to build the sys-mgmt-agent.

Weird, I didn't change anything on that part related to syst-mgmt-agent at all.   @beaufrusetta , What's OS you were using to run this?  Can you try to run make build to see if it even gets compiled?

Thanks @jim-wang-intel - it works now!

recheck

Waiting of edgex-go PR edgexfoundry/edgex-go#2890 before merge.

recheck

recheck


63 low severity vulnerabilities after creating new project

Version
3.11.0
Reproduction link
https://cli.vuejs.org/guide/creating-a-project.html#vue-create
Environment info
Environment Info:

  System:
    OS: Linux 4.15 Ubuntu 18.04.3 LTS (Bionic Beaver)
    CPU: (8) x64 Intel(R) Xeon(R) CPU E3-1246 v3 @ 3.50GHz
  Binaries:
    Node: 11.15.0 - /usr/bin/node
    Yarn: Not Found
    npm: 6.10.2 - /usr/bin/npm
  Browsers:
    Chrome: 77.0.3865.75
    Firefox: 69.0
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0
    @vue/babel-plugin-transform-vue-jsx:  1.0.0
    @vue/babel-preset-app:  3.11.0
    @vue/babel-preset-jsx:  1.1.0
    @vue/babel-sugar-functional-vue:  1.0.0
    @vue/babel-sugar-inject-h:  1.0.0
    @vue/babel-sugar-v-model:  1.0.0
    @vue/babel-sugar-v-on:  1.1.0
    @vue/cli: ^3.11.0 => 3.11.0
    @vue/cli-overlay:  3.11.0
    @vue/cli-plugin-babel: ^3.11.0 => 3.11.0
    @vue/cli-plugin-typescript: ^3.11.0 => 3.11.0
    @vue/cli-plugin-unit-jest: ^3.11.0 => 3.11.0
    @vue/cli-service: ^3.11.0 => 3.11.0
    @vue/cli-shared-utils:  3.11.0
    @vue/cli-ui:  3.11.0
    @vue/cli-ui-addon-webpack:  3.11.0
    @vue/cli-ui-addon-widgets:  3.11.0
    @vue/component-compiler-utils:  3.0.0
    @vue/preload-webpack-plugin:  1.1.1
    @vue/test-utils: 1.0.0-beta.29 => 1.0.0-beta.29
    @vue/web-component-wrapper:  1.2.0
    jest-serializer-vue:  2.0.2
    typescript: ^3.6.3 => 3.6.3
    vue: ^2.6.10 => 2.6.10
    vue-class-component: ^7.0.2 => 7.1.0
    vue-cli-plugin-apollo:  0.20.0
    vue-hot-reload-api:  2.3.3
    vue-jest:  3.0.5
    vue-jscodeshift-adapter:  2.0.2
    vue-loader:  15.7.1
    vue-property-decorator: ^8.1.0 => 8.2.2
    vue-sfc-descriptor-to-string:  1.0.0
    vue-style-loader:  4.1.2
    vue-template-compiler: ^2.6.10 => 2.6.10
    vue-template-es2015-compiler:  1.9.1
  npmGlobalPackages:
    @vue/cli: Not Found

Steps to reproduce

Follow the steps on your home page to create a new project

At the bottom of the output of npm install, I get:
found 63 low severity vulnerabilities

Run "npm audit"

In all cases, a vue module uses an outdated version of braces. Please update your dependency braces to at least 2.3.2 which fixes the issue.
What is expected?
See above
What is actually happening?
See above

Introduced by Jest 23.
We can't upgrade this dependency without bumping the major version, so it's only fixed in v4, which is currently in release candidate (RC).
Also, these vulnerabilities are low severity because they are only considered as security vulnerabilities when used in a server-side framework like express or koa. Jest is only a unit testing library on the local machine so they don't actually affect users.


Gridsome generating ~28 versions per image at build time

Summary
We have multiple Gridsome sites, and lately we've been experiencing larger than usual build times (in the minutes, not seconds) in some of our sites. Upon further inspection, we've seen that image processing takes up 90% of the time as it's trying to process thousands of images.
It appears that Gridsome is generating ~28 versions of each of our src/assets/images images, probably making our build time 25 times slower (given that other of our sites only generate 3 versions at different resolutions).
I'm guessing this is a configuration from gridsome.config.js that we are missing, but the docs doesn't mention anything related to image processing and how to disable/enable some sizes and aspect ratios.
The generated images have different resolutions and aspect ratios, and we'll probably won't ever need as many versions.
Samples
One of our sites build log:
Compile assets - 40.63s
Execute GraphQL (58 queries) - 0.44s
Write out page data (58 files) - 0.01s
Render HTML (58 files) - 0.69s
Process files (0 files) - 0s
Process images (2705 images) - 82.48s
Generate /sitemap.xml (56 pages)

28 per image seems like a lot. Would you mind sharing the markup for some of the images? Especially for a single image in various places within your project. Just so I can see if we can optimize this somehow :)

28 per image seems like a lot. Would you mind sharing the markup for some of the images? Especially for a single image in various places within your project. Just so I can see if we can optimize this somehow :)

By markup you mean the resolution and aspect ratios, right? For one image I have versions in:

480x257
480x168
800x534
400x400
200x200
500x1000

@GonzaloHirschToptal I've been debugging this a bit, but haven't been able to reproduce it. Would you be able to set up a minimal reproduction repo?

@GonzaloHirschToptal I've been debugging this a bit, but haven't been able to reproduce it. Would you be able to set up a minimal reproduction repo?

@hjvedvik I set you up a reproduction repo with 11 images. From what I gather, each of the g-image that loads the image like so:
require(`!!assets-loader?width=1440&height=480!@images/${image}`)

is generating 3 versions of the image. You'll see on the build log 66 images from those 11 originals.
We have multiple components using g-image like that, so I guess that's the cause for so many versions.
Now the questions is, are we doing anything wrong in using the g-image like that?

@GonzaloHirschToptal  Using the assets-loader directly should be okay when you scope it down to a directory or alias like in your example. Just be aware that it will change a bit in the next version of Gridsome because it upgrades to webpack 5 and we had to sort things out a little bit differently.
And thanks for creating the reproduction repo :) I have tried to build it to see if there is anything weird going on. But it seems to work as expected as far as I understand. The images are rendered in two aspect ratios with a maximum width of 1440px. So Gridsome generates each aspect ratio in 480px, 1024px and 1440px. However, you can control which images sizes you want to generate by passing an imageWidths (not documented yet...) query arg to the assets-loader like this:
require(`!!assets-loader?width=1440&height=480&imageWidths[]=720&imageWidths[]=1440!@images/${image}`)

The example above will generate 720px and 1440px instead.

@hjvedvik thank you for the explanation, I guess we'll start adding these imageWidths to reduce our image preprocessing.
Thanks again!


Server errors

Please ensure to send 500, 401, 404 on login, and  500, 409, 400 for register
Thanks john =)

codes have been updated


Showing descriptions (from XML comments) for UDT properties

Version: Swashbuckle.AspNetCore - 4.0.1
Currently if a property in an object is of UDT/schema, and Xml comments have been configured properly, Swashbuckle generates the swagger.json as
                           "aUsefulProperty": {
                                 "$ref":"#/definitions/MyPropertyModel",
                                   "description":"XML summary field for my property"
                           }

even though the spec specifically says that when $ref is present, all other sibling fields are ignored (see https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/1150). The upshot of this is that the description is never shown.
While you can include a description in the MyPropertyModel definition, if you have two properties of the same type (using the same model), they can't have different descriptions. They can't even have different meta-properties such as whether they are required.
In the end after much experimentation I was able to get this to work using a schema filter that does:
                    foreach (var prop in schema.Properties.Values)
                        if (prop.Ref != null)
                        {
                            prop.AllOf = new[] { new Schema { Ref = prop.Ref } };
                            prop.Ref = null;
                        }

And this actually works perfectly - you can combine a "description" with an "allOf" that has a single $ref entry, and the UI works as expected (showing the xml summary for the property as the description if present, otherwise showing the one for the class).
But would it be reasonable to expect Swashbuckle to do this automatically, or have a simpler/more-obvious way of achieving this?  Is there any change in this regard in v5.0.0?

(BTW I realise this code has been signficantly rewritten since v4.0.1, and I'm looking into whether the latest version will help or not)

If you upgrade to the latest version 5.0.0-rc4 (very close to stable release), then I believe the invalid output issue is resolved - i.e. descriptions are only provided with inline schema definitions.
However, as you pointed out there's still no easy way to provide "contextual" descriptions for different properties that use the same custom type. This is a structural constraint that also limits the ability to use other contextual meta-properties, however required is not one of these. Because, required is actually a collection of property names defined at the containing schema level, you can in fact indicate when specific properties are required, and this should work out-of-the-box.
I had put this down to a Swagger/OpenAPI limitation but admittedly hadn't thought of the allOf workaround you mention above. I'm not sure how this might impact some of the client generators, which are often used in conjunction with Swashbuckle, so would need to investigate that a little further. But, off the top of my head, it seems like that may be an approach that could work well, and should be supported out-of-the-box. Interested in submitting a PR?

Yes sorry you're right regarding 'required'.
I don't mind submitting a PR but what sort of options you do think should exist to control this behaviour?
As it is I'm still using 4.0.1 (in fact, only just upgraded to that from 3.0.0!).

As of v5.1.0, there's an optional setting UseAllOfToExtendReferenceSchemas, which will cause the generator to "extend" reference schemas with the allOf approach you suggested above, enabling descriptions to be included.

Thanks and good that you made it optional as unfortunately it doesn't play well with swagger-codegen.

UseAllOfToExtendReferenceSchemas : it was hard to discover this feature as it isn't in the docs. But it works nicely, thanks!


How to trigger an action from a reducer to another reducer

I can't call external action in reducer from other reducer
Follow this topic
I was leaning down redux-thunk to make this implementation and try to combine it with redux-sauce.
But I'm being the victim of some mistakes with which you may be able to help me.
Code:
Inside CreateStore I have added middleware.push (thunk) and in the reducer i'm adding the next:
export const filterSuccess = (state, action) => {
  return dispatch => {
    const parseResponse = JSON.parse(action.payload)
    console.log('filterSuccess parseResponse ===> ', parseResponse);

    if (parseResponse.data && parseResponse.data.length > 0) {
      if (parseResponse.data[0].error) {
        console.log('HERE ERROR!!!!')
        dispatch(UserReducer.show_external_error(manageErrorMessage(parseResponse.data[0], 'Filter error.')))
      }
    }
  };
}

But it gives a somewhat different error and a little more difficult to interpret.
Error is:
JSON value '<null>' of type NSNull cannot be converted to NSString

Error: {
    message = "Entries must be arrays of the form [key: string, value: string], got: (\n    \"reduxPersist:list\"\n)";
}

'Error storing data for key:', 'list', { [Error: Entries must be arrays of the form [key: string, value: string], got: (
    "reduxPersist:list"
)]
  line: 57462,
  column: 22,
  sourceURL: 'http://localhost:8081/index.ios.bundle?platform=ios&dev=true&minify=false',
  key: undefined }
2017-10-12 16:24:35.792 [warn][tid:com.facebook.react.JavaScript] Possible Unhandled Promise Rejection (id: 0):
Error: Entries must be arrays of the form [key: string, value: string], got: (
    "reduxPersist:list"
)

is there any way to integrate redux-thunk.
I have another idea sending dispatch as param and call inside reducer andnot works either. Show this error: Reducers may not dispatch actions.
SAGAS IMPLEMENTATION ISSUE WHEN IS USED WITH REDUX-OFFLINE
ignite doctor results:
System
  platform           darwin
  arch               x64
  cpu                2 cores                                                                              Intel(R) Core(TM)2 Duo CPU     E7600  @ 3.06GHz
  directory          /Users/myUser/Documents/git-repos/dev-react-native/myProy-react-native/myProy

JavaScript
  node               7.10.1       /Users/myUser/.nvm/versions/node/v7.10.1/bin/node
  npm                4.2.0        /Users/myUser/.nvm/versions/node/v7.10.1/bin/npm
  yarn               0.24.6       /usr/local/bin/yarn

React Native
  react-native-cli   2.0.1
  app rn version     0.47.2

Ignite
  ignite             2.0.0        /Users/myUser/.nvm/versions/node/v7.10.1/bin/ignite

Android
  java               1.8.0_131    /usr/bin/java
  android home       -            undefined

iOS
  xcode              8.3.2

Error and success handling of API calls should be done in a saga, if you would use redux-saga. You can make the API call in the saga and then, based on result, trigger a change in the corresponding state, like saving the error message to show it in the UI. Reducers only handle state, they should contain no other logic.


cleanup: transport::{Endpoint, Port} derive from Copy

Rust will clone Port and Endpoint automatically for us.
Acceptor doesn't derive from Copy and it makes sense, but I see no reason why
Endpoint and Port don't derive from Copy.
For reference: http://doc.rust-lang.org/std/marker/trait.Copy.html

r? @dirvine
(maidsafe_highfive has picked a reviewer for you, use r? to override)

r? @chandraprakash


Optimize surefire config in travis profile

@Shredder121 Could you take a look at this PR? It should make the handling of Travis logs simpler.

There is also a <usefile> parameter, do you know by chance if travis outputs the console? it looks like it.
I think disabling as much output as possible could(?) help.

Other than that it looks good.

Good catch. <usefile> disabled <printSummary>false</printSummary>, when I tried it, that's why I didn't include it.

If that is the case, then it doesn't matter.
A little more I/O isn't that bad.
In my opinion it is good to merge.


chore: Upgrade Golang version from 1.17 to 1.19

chore: Go lang 1.17 is a little bit old and 1.19 as well. However, before taking a greater step to higher version would might be better to break it in smaller changes since the amount of changes that this update has required is a little bit high, here is a small description of what was changed by this update:

Outdated linters:

WARN [runner] The linter 'deadcode' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.
WARN [runner] The linter 'structcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.
WARN [runner] The linter 'structcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.

Deprecation of the io/ioutils package:

SA1019: "io/ioutil" has been deprecated since Go 1.19: As of Go 1.16, the same functionality is now provided by package [io] or package [os] - Used the os package and the needed code changes applied

At puller/config.go

( undefined: GetEnvString)
Fixed by import . "github.com/kserve/modelmesh-runtime-adapter/internal/envconfig"

Some comments and headers adjusted

small identation changes made as part of go fmt.

Fixes https://github.com/kserve/modelmesh-runtime-adapter/issues/64

@ckadner could you please review this PR?

Hi @ckadner, it is ready for re-review :)

Hi @ckadner, it is ready for re-review :)

Hi @spolti -- I added 2 more comments to the threads from my previous review

https://github.com/kserve/modelmesh-runtime-adapter/pull/68#discussion_r1402785982
https://github.com/kserve/modelmesh-runtime-adapter/pull/68#discussion_r1402784527

Tested with quickstart, no issues! FYI @ckadner

Hi @rafvasq, thanks for testing.
Do you mind sharing about this tool you used, quickstart, is that a public tool, or?

Tested with quickstart, no issues! FYI @ckadner

Hi @rafvasq, thanks for testing. Do you mind sharing about this tool you used, quickstart, is this a public tool, or?

Simply meant that I deployed MM with your updates to this component and deployed/inferenced an inference service as outlined in the quickstart guide :)

service as outlined in the quickstart guide :)

Oh, right, quickstart :)

Thank you @spolti !

Actually you've opened already, closed mine and add more information on https://github.com/kserve/modelmesh-runtime-adapter/issues/74


[MacOS 14.5]Expand/Collapse is broken

I have checked the following:

[X] I use the newest version of bruno.
[X] I've searched existing issues and found nothing related to my issue.

Describe the bug
Expand/Collapse in left gutter sub panel is broken.
relevant info
MacOS 14.5
Bruno v1.20.3
electron | : 21.1.1
chrome | : 106.0.5249.103
node | : 16.16.0
v8 | : <IP_ADDRESS>-electron.0

.bru file to reproduce the bug
No response
Screenshots/Live demo link

Duplicate of #2580


fix(theme-default): scroll restoration

Summary
The issue arises due to the browser's default behavior of history.scrollRestoration, which restores the scroll position upon refresh to enhance the user experience.
I changed this default behavior in theme-default to avoid affecting other custom templates. However, if there is no anchor in the link, it affects the refresh experience to some extent.
If we consider that it only works when there is an anchor, it will make the problem more complex.
Related Issue
closed #1154

Checklist

[ ] Tests updated (or not required).
[ ] Documentation updated (or not required).

If we don’t click the anchor so that the url does not contain location.hash(#abc), then the performance after refreshing the page will indeed damage the user’s reading experience.
Only works when there is an anchor is necessary I think. Just check whether the current pathname contains location.hash?

LGTM


When selection is empty, placeholder only reappears when clicked on custom MatSelect with multiple selection

Bug, feature request, or proposal:
I've implemented a custom MatSelect according to the docs. But, if I select and then deselect the options (thus leaving the MatSelect empty) the placeholder only reappears when the component is clicked again.
What is the expected behavior?
Placeholder should stop floating and appear in its starting position.
What is the current behavior?
Placeholder only reappears when I click the component again.
What are the steps to reproduce?
Here's a Stackbliz
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular 5.2.4, Angular Material 5.2.4, Ubuntu 17.10 and Windows 10, Firefox 58 and Chrome 65; TypeScript 2.7 in my dev machine, not sure which version in Stackbliz
Is there anything else we should know?
Already tried the steps in issue #3196

The issue seems to come from the fact that you've wrapped the select in another component which isn't reacting to all the state changes. You can fix your component by adding this:
this.filterSelect.stateChanges.subscribe(() => {
  this.stateChanges.next();
});

That did it, thanks a lot.


store the weights locally and load back once Scan() is finished.

This will make save_weights also redundant. Related with #343.

It's better to leave this as it is current, so closing here.


TST: Always test matmul now that Python3.5+ is required

Small cleanup. TEST_MATMUL should always been true now that Python 3.5+ is required

Merged, thanks @sethtroisi


bdutil doesn't work with Ubuntu images

Reported on StackOverflow, I'm able to reproduce the problem at the latest 1.2.1 release. There appear to be multiple issues leading to the incompatibility.

https://github.com/GoogleCloudPlatform/bdutil/commit/86c7b091c3ac6cb4f6202ea034002ab5d8ebd33b fixes the missing /usr/local/share/google directory; @head we see:
dhuo-ubuntu-m:	No boot process configuration tool found.

This means "which insserv" and "which chkconfig" both failed running as root. Various Ubuntu forum threads indicate insserv residing in /usr/lib/insserv/insserv, and needing to symlink into /sbin before usage:
sudo ln -s /usr/lib/insserv/insserv /sbin/insserv

Applying this fix to configure_startup_processes.sh appears to allow the deployment to proceed at least to the NFS-setup steps.

The second failure is on setup_master_nfs.sh with:
dhuo-ubuntu2-m:	./hadoop-env-setup.sh: line 531: /proc/fs/nfsd/nfsv4gracetime: No such file or directory
dhuo-ubuntu2-m:	'overwrite_file_with_strings /proc/fs/nfsd/nfsv4gracetime 10' attempt 1 failed! Sleeping 10.
dhuo-ubuntu2-m:	./hadoop-env-setup.sh: line 531: /proc/fs/nfsd/nfsv4gracetime: No such file or directory
dhuo-ubuntu2-m:	'overwrite_file_with_strings /proc/fs/nfsd/nfsv4gracetime 10' attempt 2 failed! Sleeping 10.
dhuo-ubuntu2-m:	./hadoop-env-setup.sh: line 531: /proc/fs/nfsd/nfsv4gracetime: No such file or directory
dhuo-ubuntu2-m:	'overwrite_file_with_strings /proc/fs/nfsd/nfsv4gracetime 10' attempt 3 failed! Sleeping 10.
dhuo-ubuntu2-m:	./hadoop-env-setup.sh: line 531: /proc/fs/nfsd/nfsv4gracetime: No such file or directory
dhuo-ubuntu2-m:	'overwrite_file_with_strings /proc/fs/nfsd/nfsv4gracetime 10' attempt 4 failed! Sleeping 10.
dhuo-ubuntu2-m:	./hadoop-env-setup.sh: line 531: /proc/fs/nfsd/nfsv4gracetime: No such file or directory

This is a neat quirk of Ubuntu; whereas on plain Debian, running service nfs-kernel-server stop still retains the /proc/fs/nfsd files for edit, on Ubuntu the files disappear when the service is stopped, and are no longer editable.
# service nfs-kernel-server stop
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon....
# ls -l /proc/fs/nfsd
total 0
-r--r--r-- 1 root root 0 May 15 00:42 export_features
-r--r--r-- 1 root root 0 May 15 00:42 exports
-rw------- 1 root root 0 May 15 00:42 filehandle
-rw-r--r-- 1 root root 0 May 15 00:42 max_block_size
-rw------- 1 root root 0 May 15 00:42 nfsv4gracetime
-rw------- 1 root root 0 May 15 00:42 nfsv4leasetime
-rw------- 1 root root 0 May 15 00:42 nfsv4recoverydir
-r--r--r-- 1 root root 0 May 15 00:42 pool_stats
-rw------- 1 root root 0 May 15 00:42 pool_threads
-rw-r--r-- 1 root root 0 May 15 00:42 portlist
-r--r--r-- 1 root root 0 May 15 00:42 reply_cache_stats
-r--r--r-- 1 root root 0 May 15 00:42 supported_krb5_enctypes
-rw------- 1 root root 0 May 15 00:42 threads
-rw------- 1 root root 0 May 15 00:42 unlock_filesystem
-rw------- 1 root root 0 May 15 00:42 unlock_ip
-rw------- 1 root root 0 May 15 00:42 versions

Compared to Ubuntu:
root@dhuo-ubuntu2-m:/home/dhuo# ls -l /proc/fs/nfsd
total 0
-r--r--r-- 1 root root 0 May 15 01:06 export_features
-r--r--r-- 1 root root 0 May 15 01:06 exports
-rw------- 1 root root 0 May 15 01:06 filehandle
-rw-r--r-- 1 root root 0 May 15 01:06 max_block_size
-rw------- 1 root root 0 May 15 01:06 nfsv4gracetime
-rw------- 1 root root 0 May 15 01:06 nfsv4leasetime
-rw------- 1 root root 0 May 15 01:06 nfsv4recoverydir
-r--r--r-- 1 root root 0 May 15 01:06 pool_stats
-rw------- 1 root root 0 May 15 01:06 pool_threads
-rw-r--r-- 1 root root 0 May 15 01:06 portlist
-r--r--r-- 1 root root 0 May 15 01:06 reply_cache_stats
-r--r--r-- 1 root root 0 May 15 01:06 supported_krb5_enctypes
-rw------- 1 root root 0 May 15 01:06 threads
-rw------- 1 root root 0 May 15 01:06 unlock_filesystem
-rw------- 1 root root 0 May 15 01:06 unlock_ip
-rw------- 1 root root 0 May 15 01:06 versions
root@dhuo-ubuntu2-m:/home/dhuo# service nfs-kernel-server stop
 * Stopping NFS kernel daemon                                                                                [ OK ]
 * Unexporting directories for NFS kernel daemon...                                                                                [ OK ]
root@dhuo-ubuntu2-m:/home/dhuo# ls -l /proc/fs/nfsd
total 0
root@dhuo-ubuntu2-m:/home/dhuo#

It appears there's no easy way to modify nfsv4gracetime for Ubuntu, aside from editing /etc/init.d/nfs-kernel-server, as described in this serverfault.com post and in our case the edited gracetime wouldn't have survived across reboots anyhow. Since it's just a best-effort setting to speed up boot time, it's probably not appropriate to try to deeply modify /etc/init.d/nfs-kernel-server and instead just print a warning if the file is non-existent for editing.

For posterity, the root cause of the existence/nonexistence of nfsv4gracetime is that in Debian, /etc/init.d/nfs-kernel-server's "stop" command ends like this:
    if mountpoint -q $PROCNFSD_MOUNTPOINT
    then
        $PREFIX/sbin/exportfs -f
    fi
    ;;

Compared to Ubuntu's ending like this:
    if mountpoint -q $PROCNFSD_MOUNTPOINT
    then
        $PREFIX/sbin/exportfs -f
        umount $PROCNFSD_MOUNTPOINT
    fi
    ;;

So the extra umount $PROCNFSD_MOUNTPOINT seems to unfortunately clean up the procfs bits.

The fix has been tested successfully in several setups now and pull request has been sent: https://github.com/GoogleCloudPlatform/bdutil/pull/30

Merged into master: https://github.com/GoogleCloudPlatform/bdutil/commit/84fdd4611a6daf473c0c3a1c70ecce1f33a0dfdf