Bus stops

Run the conversion tool with --include-bus-stops to process public transit bus stops in the osm map and create vissim objects for the same

The flag --include-bus-stops enables the processing of public transit bus stops in the osm map and create vissim objects for the same. The function read_osm now returns a tuple - the original graph G, as well as the osm struct holding ways and nodes. The 'nodes' now include BusStopNodes. BusStopNodes are primarily identified by the 'bus_stop' tag. However, the 'asset_ref' tag should also be present for public transit bus stops, and in this version only public transit bus stops are processed. This has been tested with maps of some areas in Singapore.


[Enhancement] profile merge mechanism enhancement

What type of PR is this：

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Enhancement

Counter add merge strategy, including CounterAggregateType and CounterMergeType

CounterAggregateType can be AVG and SUM. By default, time counter use AVG, non-time counter use SUM
CounterMergeType can be MERGE_ALL、SKIP_ALL、SKIP_FIRST_MERGE、SKIP_SECOND_MERGE. Default value is MERGE_ALL which means merging operation happens both in be and fe. If SKIP_FIRST_MERGE is choosed, the merge processing at be side is skipped while at fe side is still onging. If SKIP_SECOND_MERGE is choosed, things are just opposite of SKIP_FIRST_MERGE

Change ExecutionTotalTime to OperatorCumulativeTime
Add ExecutionWallTime

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto backported to target branch

[ ] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 32 / 52 (61.54%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/Coordinator.java
0
15
00.00%
[1558, 1593, 1601, 1602, 1608, 1609, 1610, 1611, 1612, 1613, 1623, 1627, 1632, 1637, 1638]

:large_blue_circle:
com/starrocks/common/util/RuntimeProfile.java
15
19
78.95%
[216, 294, 296, 651]

:large_blue_circle:
com/starrocks/common/util/Counter.java
17
18
94.44%
[68]

run all

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 32 / 52 (61.54%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/Coordinator.java
0
15
00.00%
[1558, 1593, 1601, 1602, 1608, 1609, 1610, 1611, 1612, 1613, 1623, 1627, 1632, 1637, 1638]

:large_blue_circle:
com/starrocks/common/util/RuntimeProfile.java
15
19
78.95%
[216, 294, 296, 651]

:large_blue_circle:
com/starrocks/common/util/Counter.java
17
18
94.44%
[68]


[regtool] Error on duplicated C Defines

Some changes recently have almost caused regtool.py to output C headers
with duplicate definitions (with differing values).
This commit ensures that doing so causes a hard error in the build,
rather than outputting a file containing two definitions of the same
symbol.

@silvestrst bumped into this issue in #1520 (generating a header for the PLIC) - now the tool can error, the issue should be a lot easier to diagnose in future.

CI failing due to #1524, needs a rebase once that's in.


Clean windows agent on pipeline

This PR fixes #8498

The failure was caused by the restore cache never have been working. Solution was to disable it.

I'd just delete it entirely if we're not going to be using it for the time being, no reason to clutter up the yaml file

@anthonydresser let's push this in so we can verify that it resolves #8498.  Please make any follow-ups separately.  Thanks!


How to make the color black and better colorful for nvitop?

Thanks a lot for the great repo. Is there a way to make the background black and also the text colors nicer like yours?

How to make the color black?

@monajalal Hi, I notice that you are using a light color scheme for your terminal. Do you mean only make the background color of nvitop to black, and change back to light color scheme when you exit and return to the terminal? Or change the whole terminal in dark mode too when you are not running nvitop.

dark background in nvitop, light background in terminal when not running nvitop.
always dark background when running and not running nvitop.

If the answer is the former one, I think I can add a new option like --force-dark to invert the foreground and the background color in light terminal. Otherwise, please change your terminal color scheme to a dark one. (See the last section of this comment)

How to make the color better colorful for nvitop?

nvitop is developed on the curses module, which dynamically links to the system curses library (ncurses on Linux and PDCurses on Windows) at runtime. The ncurses library only supports 4-bits colors (black, red, green, yellow, blue, magenta, cyan, white).
nvitop does not support custom color themes yet. The GUI is rendered with command like "add string s at (x, y) with color red". How red is the text looks is depending on your terminal color scheme:

nvitop doesn't support 24-bit true color in RGB tuple (we are using ncurses library though).

If you want to change your terminal color scheme, have a look the following repositories:

Mayccoll/Gogh
mbadolato/iTerm2-Color-Schemes

I'm using Tomorrow Night Eighties theme (Gogh Gallary).

@monajalal Does the above comment resolve your issue? And can we close this now?


Error: XKB support is required to accurately determine keyboard characters!

Context
I'm getting the same error as in #293, but on a desktop Kubuntu install run on a VMWare virtual machine. After installing the library, I've tried to run example.js:
$ sudo apt-get install -y libxkbcommon-x11-0
Reading package lists... Done
Building dependency tree
Reading state information... Done
libxkbcommon-x11-0 is already the newest version (0.10.0-1).
libxkbcommon-x11-0 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 172 not upgraded.
dandv@ubuntu:~/iohook$ node example.js
load_input_helper [1918]: Using XFree86 keyboard layout.
load_input_helper [1920]: XKB support is required to accurately determine keyboard characters!
Segmentation fault (core dumped)

Your Environment

Version used: 0.7.2
Environment name and version: Node v15.9.0
Operating System and version: Kubuntu 20.10 installed from this iso in a VMWare Workstation 16.1.0 Player VM. The VM was created automatically for the ISO using default settings.

Same. I was running Node 10 & this worked, immediately upon updating to Node 14 it broke, & now displays the error shown above:
XKB support is required to accurately determine keyboard characters
Segmentation fault (core dumped)

And just to clarify: this is running on my local system, not on heroku or a server, like the linked issue.
I've also spent the past ~3 hours trying to instal & build various versions, while trying to run various versions of Node through n.  Everything I've tried seems to be broken one way or another: it tries to download a prebuild binary from an invalid url, running crashes with a message like above, etc.  It seems like there are dozens of issues about this not working recently, would be great for some feedback.  It was working fine until I updated my system to Node 14.

Do you have more information on this? I can't replicate this is Node 14 on linux. Does this happen outside VMs?

I've been able to repro this on Ubuntu 20.04 with Node 14.17.0. I can't find a workaround but the issue is within libuiohook and seems to be an issue for the fork in this repo not upstream, which is not compatible with this repo right now. Fixing this will be through changing the addon interface and gyp definition to be compatible with upstream libuiohook, which will also fix tons of issues. This will happen after the current build and install have been redone, probably in a couple of weeks.

Hi,
I would like to try it but there is just the bug with node 14 version. Can I know when I will be able to run it on Ubuntu 20?

@ash0x0 Any update on when it will be fixed in Node 14, I'm using Mac OS and it doesn't work.

@ash0x0 Any update on when it will be fixed in Node 14, I'm using Mac OS and it doesn't work.

This should be fixed once I finish the refactor I'm working on now (as soon as I find time for it) or at least that's the theory I have for this bug at the moment.

Hello,
I just wanted to know if you found the issue. I really hope this can get fixed soon.

this is still happening on ubuntu 22


Milliseconds round down

If someone send time with second's precision with more than 6 decimal places you may have an error in time() function.
For example: (and I've very got it!)
2017-11-29T10:59:59.9999999Z - this will have 60.000000 seconds after time parsing and raise the error.

Coverage remained the same at 94.433% when pulling 54e62b27789fac415e27b4e188930dd213921232 on kidig:master into ce635a7a483effb3fc246721cfb5a8a7b5174ab5 on gweis:master.

fixed in 89f8089


Use orquestra python dev

Description
Currently, we use dev requirements (e.g. black, mypy, flake8) specified separately in each project. This PR replaces those separate package dependencies into a centralized one managed by us: orquestra-python-dev.
Please verify that you have completed the following steps

[x] I have self-reviewed my code.
[ ] I have included test cases validating introduced feature/fix.
[ ] I have updated documentation.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@c0c1739). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #6   +/-   ##
=======================================
  Coverage        ?   92.72%
=======================================
  Files           ?        4
  Lines           ?      261
  Branches        ?        0
=======================================
  Hits            ?      242
  Misses          ?       19
  Partials        ?        0

Continue to review full report at Codecov.

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


Updated dockerfile to reduce size

This reduces the docker image from ~900MB down to ~80MB

Thanks for your contribution! I'll get this merged.


Document how to properly use multi_index::get and deprecate related methods that take a reference

We need clear documentation on how to use multi_index::get so that contract developers avoid the common pitfall of copy assigning the reference returned from multi_index::get to a stack-allocated local variable and then passing that into multi_index::modify.
The most common mistake is that users use auto as the typename for the local variable when they should be using auto& or decltype(auto).
Also, because this is a common mistake contract developers make which could lead to undefined behavior, we should deprecate the overloads of modify and erase methods in multi_index that take a reference, and encourage them to use the versions that take const_iterator instead which are much safer.
We should also provide warnings in the documentation about using iterator_to which can have similar undefined behavior if the developer passes in a reference to a stack-allocated object rather than the reference returned by get or by dereferencing a const_iterator. Perhaps we can also provide a safer overload of iterator_to that takes a const_iterator.
Along with deprecating multi_index::get, we should also make sure we do not actually use it in any of the contracts in our repository. Instead we could use multi_index::require_find from EOSIO/eos#4227.

multi index get reference doc: https://developers.eos.io/manuals/eosio.cdt/latest/structeosio_1_1multi__index_1_1index/#function-get-12


fix(api): minify cfn before deployment

Description of changes
Minifies the CFN template uploaded to the S3 bucket if --minify option is specified.

[x] PR description included
[x] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

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

Closing because https://github.com/aws-amplify/amplify-cli/pull/10955 was merged which covers the same changes.


fixed linting for actor_activation and actor_features - Part 1

Description
Fixed lint issues by running golangci-lint --build-tags e2e
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
This PR will not close but part of #3328
Please reference the issue this PR will close: #3328
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

Since there are a lots of file changes in tests/e2e/.. I am planning to create multiple PRs with 1-2 files for easier review.
And with the last PR I will enable e2e in build tags in golangci.yml

Thanks for great work, could you just use title like lint: fix xxx and xxs test, the part N make git log confused, we can track process in origin issue.


Black waveform screen

Hello ,
I'm facing a problem with piscope . The waveform screen remains black and I don't know how to debug  the problem . Tried on RPi , BananaPro , x86 hardware .Piscope connects to the pigpiod but no data.
This it was it looks like: http://postimg.org/image/mjo4n5pld/
What I'm doing wrong ? Tried with python 2.7 and 3.x no luck and Gtk3 .

piscope will display a blank (black) screen until some level changes are seen.
On a Pi a simple way to trigger level changes is with PWM.  If you are not using GPIO 4 try pigs p 4 128 from the command line (the command generates a square wave on GPIO 4).

Yep it works , piscope works fine on RPi (both piscope and pigpio) , BananaPro (piscope),x86 (piscope).
On BananaPro seems pigpio doesn't work at all , I started it with -a1 option , else error " initAllocDMAMem: mbox open failed", piscope connects but when I run "pigs p 4 128" on any GPIO nothing happens on piscope, and the pigpiod proces jumps to 150-200% cpu usage.
The banana is killing me , everithing was so fine on RPi

pigpio uses several Broadcom peripherals on the Pi to sample the GPIO as effectively as it does.  The DMA peripheral to automatically round robin sample the GPIO as timed by the PCM peripheral and timestamped by the System Clock peripheral.
Unless those identical peripherals are present on the clone then pigpio will not work on that clone.
Anyhow, closing this as it's not a piscope issue.


Three-gang plate with HASP in the middle

At the moment, there's only one option for a three-gang plate with an HASP module - mounting it on the side.
In some instances, it may be more desirable to have it in the middle - case in point, I have two ZEN22's I'd be mounting it next to, which can't be mounted next to each other (heat dissipation issues). Therefore, putting the HASP in the middle would be more practical and fits the aesthetic I'd be going for.

For reference, here's the two models that I'm referring to: three-gang Decora, three-gang toggle.

You make a compelling argument.  Currently available in dev branch, should hit master "soon".


Decoding failures

I have a basic implementation of a server which is able to successfully parse header requests; however, when attempting to proceed with parsing ApiVersionsRequests, MetadataRequests and ProduceRequests, decoding fails at various different locations for each. This is true with:

rust-rdkafka simple_producer example
kafka-rust example_producer

I'm happy to proceed with testing other clients, maybe a few from other languages. However, just to provide some concrete examples:

When attempting to decode PartitionProduceData in the impl Decodable for PartitionProduceData block, decoding fails to decode records as types::Bytes.decode(buf)?, because it attempts to parse a length first, and in the cases I've been debugging, the length includes the 4 bytes describing the length. So when this crate attempts to decode those bytes, it always sees the payload as being 4 bytes too short. I'll need to dig a bit deeper to see if there is an easy fix.
In another example, attempting to decode an ApiVersionsRequest, decoding fails on the client_software_version as a types::CompactString.decode(buf)?. The following line: let strbuf = StrBytes::try_from(buf.try_get_bytes((n - 1) as usize)?)?; fails, also due to a length vs buffer length mismatch.

Disregard. Error in my code.


F1 22 game.dat file

Hi, can you update your NefsEdit to v2.0 dat files?.
Thanks

I thought f1 22 still uses nefs 1.6. either way, I have made some progress on that, but I have no ETA on when/if it will be done.


Add an immutable HashSet to the javaslang.collection package

HashSet is there, solved step-by-step along with HashMap.


Can't Kekulize mol

Hello,
Really cool tool that I hope to be able to use!  I'm getting this error for an SDF file that is hydrated and saved from PyMol.  Any advice here?
[14:37:23] Can't kekulize mol.  Unkekulized atoms: 47 48 49 50 51 52 53 54 56
Traceback (most recent call last):
  File "/home/jadolfbr/EquiBind/inference.py", line 473, in <module>
    inference_from_files(args)
  File "/home/jadolfbr/EquiBind/inference.py", line 337, in inference_from_files
    if lig == None: raise ValueError(f'None of the ligand files could be read: {lig_names}')
ValueError: None of the ligand files could be read: ['215_ligand.sdf']

Hi!
Thanks for the kind words!
This is an error that occurs because RDKit returned None instead of a molecule object.
It happened because RDKit was unable to read the molecule file. Maybe you can just try to load the molecule by itself with RDKit to debug why it was not able to load the molecule.

Thanks!  Will do!  I saved the ligand from PyMol, and it looks like it doesn't deal with rings very well.  I have now used open babel to convert to SDF and rerunning.  This SDF looks better preserved, so hopefully RDKit will work OK.

I use this code and dataset here, also meet the "Can't Kekulize mol", is this normal?

loading ligands:   0%|          | 0/16379 [00:00<?, ?it/s][16:34:53] Can't kekulize mol.  Unkekulized atoms: 14 15 16 17 18
[16:34:53] Can't kekulize mol.  Unkekulized atoms: 8 9 10 11 12 13 14 15 16
[16:34:53] Can't kekulize mol.  Unkekulized atoms: 40 41 42 43 44
[16:34:53] Explicit valence for atom # 1 C, 6, is greater than permitted
[16:34:53] Can't kekulize mol.  Unkekulized atoms: 0 1 3 4 5 6 9 10 11
[16:34:53] Can't kekulize mol.  Unkekulized atoms: 5 6 7 8 9 10 11 12 13
[16:34:53] Can't kekulize mol.  Unkekulized atoms: 25 26 27 28 29
[16:34:53] Can't kekulize mol.  Unkekulized atoms: 1 4 5 8 9 10
[16:34:53] Can't kekulize mol.  Unkekulized atoms: 0 1 2 3 4 5 6 7 8


make escape_transform return a parser outputing Cow<str>

In many cases, the parsed text segment contains no escaped symbols, returning a reference would be sufficient. Current ExtendInto API also doesn't support custom implementations.

Is there any suggested path to adding this?

I think making nom::ExtendInto::Extender into a generic type parameter and implement ExtendInto<Cow<'_, str>> and ExtendInto<Cow<'_, [u8]>> for various types would be enough. This would be breaking change though. Maybe add another trait ExtendIntoV2 that does the same and add a escape_transform_v2 using the new trait.

I attempted but encountered some lifetime issues. I believe a complete redesign of ExtendInto may be warranted.


Few minor suggestions

Github link on the releaser website (this repo is hard to find)
Some minor SEO efforts (releaser is impossible to find in google). I have to go into my mail and find an old releaser email to go to your website..

Faced the same difficulties recently!

Hi, yeah, I agree, unfortunatley I can't do very much about it except "linkbacks", also a little more content on the page about what it does might help...
In other words, I will write some more "about" on releaser, but I need your help to spread the word ;)
Richard

added some github keywords and a ribbon, hope that helps a little bit...


[Bug Report] Add missing item to changelog (2.6.0)

Element UI version
2.6.3
OS/Browsers version
N/A
Vue version
2.6.10
Reproduction Link
https://github.com/ElemeFE/element/releases/tag/v2.6.0
Steps to reproduce

Look at changelog for https://github.com/ElemeFE/element/releases/tag/v2.6.0
Check for updates to table

What is Expected?
There should be a note in the Bug fixes portion of the changelog for #12086, alongside "Make toggleAllSelection method [...]".
What is actually happening?
Don't see changes about the row-click event update

Also, something like this is is a breaking change, not sure if you highlight that in anyway.


Add Knative

There is a lot of stuff around Knative currently and there is not currently an active list.

https://github.com/anksos/awesome-knative#readme
Reviewed Pull Requests #1827 #1821
There is no currently an active knative list and there is a lot of spread info around. This list will help everyone having as much as possible the resources available in one place.
By submitting this pull request I confirm I've read and complied with the below requirements 🖖
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
Requirements for your pull request

Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
You have to review at least 2 other open pull requests.
Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions.
You have read and understood the instructions for creating a list.
This pull request has a title in the format Add Name of List.

✅ Add Swift
✅ Add Software Architecture
❌ Update readme.md
❌ Add Awesome Swift
❌ Add swift
❌ Adding Swift
❌ Added Swift

Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.

✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
✅ - [Framer](…) - Prototyping interactive UI designs.
❌ - [iOS](…) - Resources and tools for iOS development.
❌ - [Framer](…)
❌ - [Framer](…) - prototyping interactive UI designs

Your entry should be added at the bottom of the appropriate category.
The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
The default branch should be named main, not master.
Includes a succinct description of the project/theme at the top of the readme. (Example)

✅ Mobile operating system for Apple phones and tablets.
✅ Prototyping interactive UI designs.
❌ Resources and tools for iOS development.
❌ Awesome Framer packages and tools.

It's the result of hard work and the best I could possibly produce.
If you have not put in considerable effort into your list, your pull request will be immediately closed.
The repo name of your list should be in lowercase slug format: awesome-name-of-list.

✅ awesome-swift
✅ awesome-web-typography
❌ awesome-Swift
❌ AwesomeWebTypography

The heading title of your list should be in title case format: # Awesome Name of List.

✅ # Awesome Swift
✅ # Awesome Web Typography
❌ # awesome-swift
❌ # AwesomeSwift

Non-generated Markdown file in a GitHub repo.
The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
Not a duplicate. Please search for existing submissions.
Only has awesome items. Awesome lists are curations of the best, not everything.
Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
Includes a project logo/illustration whenever possible.

Either centered, fullwidth, or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
Includes the Awesome badge.

Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics header.

Should link back to this list.

Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of nested lists, preferably none.

Has an appropriate license.

We strongly recommend the CC0 license, but any Creative Commons license will work.

Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=master&template=cc0-1.0 (replace <user> and <repo> accordingly).

A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
Place a file named license or LICENSE in the repo root with the license text.
Do not add the license name or text to the readme. GitHub already shows the license name at the top of the repo.
To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.

Has contribution guidelines.

The file should be named contributing.md. Casing is up to you.

Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

Doesn't include a Travis badge.You can still use Travis for list linting, but the badge has no value in the readme.
Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

unicorn

Thanks for making an Awesome list! 🙌
It looks like you didn't read the guidelines closely enough. I noticed multiple things that are not followed. Try going through the list point for point to ensure you follow it. I spent a lot of time creating the guidelines so I wouldn't have to comment on common mistakes, and rather spend my time improving Awesome.

I strongly suggest playing with awesome-lint. It will show you most of the formatting issues you need to fix (lists, dots, descriptions, content section, etc.)
Start with the tool and then go through the checklist again. I've been there, it really helps :)

@kolomied thanks for the information
@sindresorhus can you please take a look and let me know if something is still missing?

descriptions fixed (in majority of them the link is explanatory by itself so according to guidance it doesn't need description)
master branch changed to main as default
table of contents added
have reviewed another 2 open PRs (is already add in my PR)
topics added
fixed the knative description/explanation on the main awesome list

@sindresorhus any update on that? Thank you.

can you please take a look and let me know if something is still missing?

I would recommend going through the guidelines again and check. The reason the guidelines exists is so that I don't have to point out stuff written there.

can you please take a look and let me know if something is still missing?

I would recommend going through the guidelines again and check. The reason the guidelines exists is so that I don't have to point out stuff written there.

Thanks @sindresorhus i will try to fix those, I was able to spot majority of those.

The Video section is missing the descriptions. The other descriptions are often redundant

Knative Cookbook - Knative cookbook from O'Reilly.

Could be something like "Knative Cookbook - A collection of recipes for XXX by O'Reilly". This is just a suggestion without knowing this book.
Did you run awesome-lint? I get a bunch of errors on your list:
awesome-lint  https://github.com/anksos/awesome-knative
- Linting(node:15128) ExperimentalWarning: The fs.promises API is experimental
× Linting

  README.md:1:1
  ×   1:1    Headings should use atx                                                      remark-lint:heading-style
  ×   1:20   Invalid badge source                                                         remark-lint:awesome-badge
  ×   4:1    Don’t add a trailing ? to headings                                           remark-lint:no-heading-punctuation
  ×   7:1    Don’t add a trailing : to headings                                           remark-lint:no-heading-punctuation
  ×   9:1    Missing marker in block quote                                                remark-lint:no-blockquote-without-marker
  ×   9:5    Incorrect indentation before bullet: remove 2 spaces                         remark-lint:list-item-bullet-indent
  ×  11:1    Missing marker in block quote                                                remark-lint:no-blockquote-without-marker
  ×  11:5    Incorrect indentation before bullet: remove 2 spaces                         remark-lint:list-item-bullet-indent
  ×  13:1    Table of Contents must be the first section                                  remark-lint:awesome-toc
  ×  14:1    ToC item "Contributing" does not match corresponding heading "Books / Docs"  remark-lint:awesome-toc
  ×  25:1    Headings should use atx                                                      remark-lint:heading-style
  ×  25:16   Remove 1 space after this heading’s content                                  remark-lint:no-heading-content-indent
  ×  26:44   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  27:95   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  29:88   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  30:57   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  36:98   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  37:70   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  38:74   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  42:46   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  43:91   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  44:65   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  45:85   List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  58:3    https://www.youtube.com/watch?v=riq0x5xdfNg                                  remark-lint:double-link
  ×  68:3    https://www.youtube.com/watch?v=riq0x5xdfNg                                  remark-lint:double-link
  ×  89:103  List item description must end with proper punctuation                       remark-lint:awesome-list-item
  ×  90:107  List item description must end with proper punctuation                       remark-lint:awesome-list-item

  27 errors

Reading the guidelines again and reviewing other lists (existing and in the PRs) might show you other things you can improve to make your list really awesome!

@wernerkrauss thanks mate, yes already have run the lint I just didn't had yet the time to fix them! Really appreciate your view! cheers

Bump

Bump

@anksos any update here? I can take a stab at fixing the errors if needed.

@anksos any update here? I can take a stab at fixing the errors if needed.

feel free mate!!! Thanks for the reminder!

Haven't forgot about this but been working on more Cloud Run OSS at the moment. Are you able to knock this out or should I add this to my weekend OSS queue this week or next?

Running awesome-lint on your patch-1 (this pr) gives issues
diff --git i/readme.md w/readme.md
index 98772aa..32172f9 100755
--- i/readme.md
+++ w/readme.md
@@ -742,17 +742,13 @@

Biomedical Information Extraction - How to extract information from unstructured biomedical data and text.
Web Archiving - An effort to preserve the Web for future generations.
WP-CLI - Command-line interface for WordPress.
-- Knative - Kubernetes-based platform to deploy and manage serverless workloads.
Credit Modeling - Methods for classifying credit applicants into risk classes.
Ansible - A Python-based, open source IT configuration management and automation platform.
Biological Visualizations - Interactive visualization of biological data on the web.
QR Code - A type of matrix barcode that can be used to store and share a small amount of information.
Veganism - Making the plant-based lifestyle easy and accessible.
Translations - The transfer of the meaning of a text from one language to another.
-- Knative - Learning Knative
-- Knative - Knative resources and events list.
-- Knative - Knative is a kubernetes-based platform to deploy and manage serverless workloads.
-- Knative - Kubernetes-based platform to deploy and manage serverless workloads.
+- Knative - Learning Knative.


suggestion: merge message

# MERGE. function gmerge() {     gcap "🔀 MERGE: $@" }
Maybe helps maybe not :D

Not a good enough case. Thanks. I suggest use:
🐛 FIX: Merge Conflict

# OR.

👌 IMPROVE: Resolve Merge Conflict

# OR.

📦 NEW: Merge dev branch


gnu/test: add the iso en_us locale to help with some tests

Closes #2754

Failed because
Warning: Changes from master: PASS -2 / FAIL +3 / ERROR +0 / SKIP -1
Reasons:
Error: GNU test failed: tests/misc/expr-multibyte. tests/misc/expr-multibyte is passing on 'master'. Maybe you have to rebase?
Error: GNU test failed: tests/misc/sort-debug-keys. tests/misc/sort-debug-keys is passing on 'master'. Maybe you have to rebase?
Error: GNU test failed: tests/misc/sort-month. tests/misc/sort-month is passing on 'master'. Maybe you have to rebase?

tests/misc/sort-month failing is https://github.com/uutils/coreutils/issues/3123

tests/misc/sort-debug-keys fails on https://github.com/coreutils/coreutils/blob/master/tests/misc/sort-debug-keys.sh#L321-L334

@tertsdiepraam I think we should merge it if you are ok with it
@jfinkels what do you think ? :)

The clippy warning is already fixed: https://github.com/uutils/coreutils/pull/3124

I was waiting for jfinkels, but sure :)

Hi! I think this will be great for revealing more errors. I don't know much about using locales (I'm on en_US.UTF-8 and I don't speak other languages, unfortunately) but I'm happy to learn. Does this affect the Quotable trait?


tools(connector-quorum): address CVEs: CVE-2022-21190, CVE-2021-3918, CVE-2021-44906, CVE-2023-36665, CVE-2022-2421, CVE-2022-2421

Description
Vulnerabilities were found during the container scan of connector-quorum image using Trivy.
See the list below:

LIBRARY
VULNERABILITY
INSTALLED VERSION
FIXED VERSION

libsasl2-2 libsasl2-moduleslibsasl2-modules-db
CVE-2022-24407
2.1.27+dfsg-2
2.1.27+dfsg-2ubuntu0.1

libssl1.1
CVE-2021-3711 CVE-2022-0778  CVE-2023-0286
1.1.1f-1ubuntu2.5
1.1.1f-1ubuntu2.8 1.1.1f-1ubuntu2.12 1.1.1f-1ubuntu2.17

openssl
CVE-2021-3711 CVE-2022-0778CVE-2023-0286

1.1.1f-1ubuntu<IP_ADDRESS>f-1ubuntu<IP_ADDRESS>f-1ubuntu2.17

@npmcli/arborist (package.json)
CVE-2021-39134 CVE-2021-39135
2.6.4
2.8.2

ansi-regex (package.json)
CVE-2021-3807
3.0.0, 5.0.0
6.0.1, 5.0.1, 4.1.1, 3.0.1

axios (package.json)
CVE-2021-3749
0.21.1
0.21.2

convict (package.json)
CVE-2022-21190 CVE-2022-22143 CVE-2023-0163
6.0.0
<IP_ADDRESS>.3 6.2.4

engine.io (package.json)
CVE-2022-21676
5.0.0
4.1.2, 5.2.1, 6.1.1

http-cache-semantics (package.json)
CVE-2022-25881
4.1.0
4.1.1

json-schema (package.json)
CVE-2021-3918
0.2.3
0.4.0

minimatch (package.json)
CVE-2022-3517
3.0.4
3.0.5

minimist (package.json)
CVE-2021-44906
1.2.5
1.2.6, 0.2.4

node-forge (package.json)
CVE-2022-24771 CVE-2022-24772
0.10.0
1.3.0

npm (package.json)
CVE-2022-29244
7.19.1
8.11.0

protobufjs (package.json)
CVE-2023-36665 CVE-2022-25878
6.11.2
7.2.4, 6.11.4 6.11.3, 6.10.3

qs (package.json)
CVE-2022-24999
6.5.2, 6.7.0
6.10.3, 6.9.7, 6.8.3,  6.7.3, 6.6.1, 6.5.3, 6.4.1, 6.3.3, 6.2.4

socket.io-parser (package.json)
CVE-2023-32695
4.0.5
4.2.3, 3.4.3

tar (package.json)
CVE-2021-32803 CVE-2021-32804CVE-2021-37701 CVE-2021-37712 CVE-2021-37713
6.1.0
3.2.3, 4.4.15, 5.0.7, <IP_ADDRESS>.2, 4.4.14, 5.0.6, 6.1.1 4.4.16, 5.0.8, <IP_ADDRESS>.18, 5.0.10, 6.1.9

@zondervancalvez Could you please make the issue title unique according to the guidelines we talked about previously?

@zondervancalvez Please shorten it to adhere to the commit lint max length requirements. What I do in these situations is pick the top (most severe) 1 or 2 or 3 CVE IDs (depending on how many characters do you have left) and use only those.

@zondervancalvez Please shorten it to adhere to the commit lint max length requirements. What I do in these situations is pick the top (most severe) 1 or 2 or 3 CVE IDs (depending on how many characters do you have left) and use only those.

Hi @petermetz The title is now shortened and I've only indicated the Critical CVEs.

@zondervancalvez Please shorten it to adhere to the commit lint max length requirements. What I do in these situations is pick the top (most severe) 1 or 2 or 3 CVE IDs (depending on how many characters do you have left) and use only those.

Hi @petermetz The title is now shortened and I've only indicated the Critical CVEs.

@zondervancalvez Thank you very much!

Hey @zondervancalvez,
We're part of a startup called Seal Security that mitigates software vulnerabilities in older open source versions by backporting/creating standalone security patches - enabling more straightforward remediation in cases like this. We created an minimatch 3.0.4-sp1 that's vulnerability-free. As with all of our patches, it's open-source and available for free.
If relevant, check out our GitHub repo if you wish to learn more, or start using our app.
Please feel free to reach us at<EMAIL_ADDRESS>if you have any requests/questions.

Can you assign this to me? @jagpreetsinghsasan

I would like to work on this one


Add apos.images.srcset method

Here's the apos.attachments.srcset method (with an accompanying test) discussed in #803. The srcset attribute is fairly simple, so there's not much to it. I changed my mind on the naming of the sizes attribute passed to apostrophe-images-widgets, though, so it's now sizesAttr. It seemed like this would cause less confusion with the existing size option.
One thing that I think warrants some discussion is the possible inclusion of the picturefill.js polyfill. The only browser that doesn't support srcset is IE, but picturefill.js really just works and weighs in at a pretty small 11.5 kB when minified. Maybe this is the kind of thing better left to individual developers (perhaps the possibility of including it could be mentioned in the docs), but I wanted to throw it out there.
I'll go ahead and submit a PR to the docs for this as well.
Btw, it looks like some trailing whitespace was removed automatically by my editor, but I didn't think that caused any harm.

@boutell @austinstarin thoughts on this? I realize that while apos.attachments.src serves the same purpose for all types of attachments, this method is only applicable to images. Perhaps then it'd make more sense to move it to apostrophe-images?

I think you're right, it should move to apostrophe-images.
On Fri, Feb 17, 2017 at 8:53 AM, Fredrik Ekelund<EMAIL_ADDRESS>wrote:

@boutell https://github.com/boutell @austinstarin
https://github.com/austinstarin thoughts on this? I realize that while
apos.attachments.src serves the same purpose for all types of
attachments, this method is only applicable to images. Perhaps then it'd
make more sense to move it to apostrophe-images?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/punkave/apostrophe/pull/805#issuecomment-280654957,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB9fSsK5QpjrlODfWTWLfrugIZtQ5zGks5rdaZGgaJpZM4LupMY
.

--
*THOMAS BOUTELL, *SUPPORT LEAD
P'UNK AVENUE |<PHONE_NUMBER>  |  punkave.com

Cool, I'll have a look at moving it!

@boutell moved! It's now apos.images.srcset instead of apos.attachments.srcset. Let me know if you think we need any more changes here

Hi Fredrik,
We had a long discussion about this just now. We think it is a very, very cool idea but unfortunately there are some significant issues with it.
First, the code assumes that "sizes" should be set to 100vw. This works out pretty well on a phone, because generally any columns etc. have collapsed to one column in that setting. So the image that gets picked matches the device size and we're good.
But on a desktop it's bad news, because 100vw will be very large, even if this image widget is actually going into one of five columns and should therefore be very small. As a result the max image is picked every time, in exactly the situation where you wish it wouldn't be.
We could add a sizes option, requiring the developer to think about how big this thing is really going to be on the page at various breakpoints, and output srcsetonly if it is present. But then we're still making the assumption that sending a double-res image for retina screens is not worth the trouble. And that's not really an assumption we get to push on frontend developers.
Finally, and this is arguably our fault, although some shaping and styling tricks are very difficult any other way... we use CSS background images a lot. In that scenario the img element is pretty much there for SEO. And when that is happening the srcset doesn't have much use.
@austinstarin just showed me an example of a client project where he built his own figure element using srcset, et cetera, and the standard apos.attachments.url helper. It works well and doesn't seem to require any customization in the core.
So for now this is not something we're going to do. But we're open to an ongoing conversation about what we might be able to do to help frontend developers use srcset effectively without making unsafe assumptions about their use cases.
Thanks and please continue sending PRs!

Thanks for the detailed feedback, feels good to engage in an open source project with such a positive attitude!
As for the points you bring up - I see the issue with the 100vw default value for sizes in apostrophe-images-widgets. I think we could come up with a better solution there by following WordPress' example. They use the following sizes attribute by default: (max-width: {{image-width}}px) 100vw, {{image-width}}px. I guess we would grab the image-width value from the size attribute passed in the Nunjucks template.
However, if you still feel that it's not worth including the apostrophe-images-widgets markup, then I won't fight for it. I think it would be neat to have, but I also believe people will be writing their own custom image modules for different scenarios, and can then decide for themselves whether or not to include those attributes.
But I do feel more strongly about including the apos.images.srcset method (and Nunjucks helper). srcset is a really important feature for a lot of modern responsive websites, and merging just that method is a small addition to acknowledge that and make life a little easier for developers.
So, what we could do is to drop the changes in apostrophe-images-widgets and just add the apos.images.srcset method. What do you say, @boutell? :)

Hmm, both suggestions make sense to me... is there a straightforward way to add an option for those who want to specify "I'll pay the extra freight to go 2x on retina"?

The retina stuff is actually handled automatically by browsers! The srcset attribute has gone through one or two revisions since it was introduced, and the 2x syntax is no longer needed. And I don't really know of any way to turn off the retina consideration - I think browsers will try to pick the picture that will look best within some confines. For example, if your viewport is 1000px wide and you have two image options - one 800px and one 2000px, I believe most browsers will pick the smaller one, because 2000px is deemed unreasonably large to justify a download.

I think you're right:
https://www.keycdn.com/blog/responsive-images/
@stuartromanek, @bgantick, @austinstarin, I think Fredrik'ss suggested
revisions makes sense, including folding it into the standard images
widget. We already use the size option to communicate about how big we
think the image is going to be, so we ought to be able to build a correct
sizes attribute on that basis. And it would match what Wordpress is doing
successfully in this area. What do you think?
On Sun, Mar 5, 2017 at 9:27 AM, Fredrik Ekelund<EMAIL_ADDRESS>wrote:

The retina stuff is actually handled automatically by browsers! The srcset
attribute has gone through one or two revisions since it was introduced,
and the 2x syntax is no longer needed. And I don't really know of any way
to turn off the retina consideration - I think browsers will try to pick
the picture that will look best within some confines. For example, if your
viewport is 1000px wide and you have two image options - one 800px and one
2000px, I believe most browsers will pick the smaller one, because 2000px
is deemed unreasonably large to justify a download.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/punkave/apostrophe/pull/805#issuecomment-284231378,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB9fZa3fWCitxjiaGFy5gXUSNL1wDjDks5risZrgaJpZM4LupMY
.

--
*THOMAS BOUTELL, *SUPPORT LEAD
P'UNK AVENUE |<PHONE_NUMBER>  |  punkave.com

Consensus here is that your revised suggestions make good sense! Do you want to take a crack at these changes? The dimensions for each named size are available in the attachments module.

Great – happy to hear it! Absolutely, I'll have time to look into it in a day or two. Do you want to reopen the PR in the meantime? :)

There we are! I've updated the default value of the <img>'s sizes attribute in apostrophe-image-widgets.
I did some testing as well and concluded that we have to drop the current background-image solution on the .apos-slideshow-items for srcset to be effective, so I did that and updated the CSS accordingly. I did some manual testing besides the unit test I added for the new apos.images.srcset method, and things look to be working well both for single images and slideshows, but please do have an extra look at the diff before merging to make sure I don't break any of your assumptions in apostrophe-images-widgets.

The sudden disappearance of the background images would definitely be a
disruption for production websites that don't happen to override
widget.html and have CSS dependent on that technique, so that's something
we won't be doing at least without a flag to that effect.
Background images are generally used to achieve responsive autocropping and
leverage background-size: cover, among other effects that the img element
is just not very good at.
On Fri, Mar 10, 2017 at 9:29 AM, Fredrik Ekelund<EMAIL_ADDRESS>wrote:

There we are! I've updated the default value of the 's sizes
attribute in apostrophe-image-widgets.
I did some testing as well and concluded that we have to drop the current
background-image solution on the .apos-slideshow-items for srcset to be
effective, so I did that and updated the CSS accordingly. I did some manual
testing besides the unit test I added for the new apos.images.srcset
method, and things look to be working well both for single images and
slideshows, but please do have an extra look at the diff before merging to
make sure I don't break any of your assumptions in
apostrophe-images-widgets.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/punkave/apostrophe/pull/805#issuecomment-285682531,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB9ffTHymdSCkFuH1JVoxhPG6BvTRyTks5rkV5dgaJpZM4LupMY
.

--
*THOMAS BOUTELL, *SUPPORT LEAD
P'UNK AVENUE |<PHONE_NUMBER>  |  punkave.com

Hmm well that's a problem then. I guess we could hide the new behavior behind a widget option (eg. srcset: true) but still default to the old behavior. Alternatively we could drop the updates to apostrophe-images-widgets and just add the apos.images.srcset method. The former option seems viable to me, I don't know how you feel about it?

After having mulled this over a bit, I think that the added complexity we would introduce by adding a srcset: true widget option to apostrophe-images-widgets would probably give us more trouble than it's worth. My suggestion is that I reduce the changes to just the apos.images.srcset method and squash my commits here. Does that sound like a good way forward, @boutell?

@stuartromanek @bgantick @austinstarin, I'm coming back to this now and am still thinking like my last comment. If P'unk Avenue relies on using background images over <img> elements, then the best way forward would probably be to drop the updated CSS and markup in apostrophe-images-widgets, and instead just add the apos.images.srcset and the apos.attachments.getImageSize methods.
I can't stress enough the value that this underlying functionality brings - for websites that demand ease of content editing, good performance for end users and high image quality - Apostrophe might actually have it all. The image variations that are already there just need to be exposed through some template functions (and those template functions need to be documented), and voíla!

Yes, I think the key thing here is a HOWTO to go with it.
On Wed, Nov 8, 2017 at 4:05 PM, Fredrik Ekelund<EMAIL_ADDRESS>wrote:

@stuartromanek https://github.com/stuartromanek @bgantick
https://github.com/bgantick @austinstarin
https://github.com/austinstarin, I'm coming back to this now and am
still thinking like my last comment. If P'unk Avenue relies on using
background images over  elements, then the best way forward would
probably be to drop the updated CSS and markup in
apostrophe-images-widgets, and instead just add the apos.images.srcset
and the apos.attachments.getImageSize methods.
I can't stress enough the value that this underlying functionality brings

for websites that demand ease of content editing, good performance for
end users and high image quality - Apostrophe might actually have it
all. The image variations that are already there just need to be exposed
through some template functions (and those template functions need to be
documented), and voíla!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/punkave/apostrophe/pull/805#issuecomment-342959136,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB9fVCASTQPKa465PQ-C_vJc-LUesovks5s0heCgaJpZM4LupMY
.

--
*THOMAS BOUTELL, *SUPPORT LEAD
P'UNK AVENUE |<PHONE_NUMBER>  |  punkave.com

We should definitely be moving this direction in Apostrophe (and move away from background images as a default). Thanks for the hard work @fredrikekelund
@fredrikekelund  can you take a crack at re-writing the first part of this document to go over the features? https://github.com/punkave/apostrophe-documentation/blob/master/tutorials/howtos/responsive-images.md

@stuartromanek sure! Will see if I can look into it over the next couple of days. I assume you don't want me to make any further changes to apostrophe-images-widgets then?

Not at this time @fredrikekelund .. next week I want to round up with a few other Apostrophe devs to go over internally, will let you know how that shakes out.

@stuartromanek @boutell I actually went ahead and reverted all of the changes to apostrophe-images-widgets - making it so the only changes here are the introduction of the apos.images.srcset and apos.attachments.getImageSize methods.
I think it's more valuable to merge those methods, showing clearly that Apostrophe supports srcset more or less out of the box, than it is to find a way forward going from a background-image to an <img> solution.
Happy to add documentation about those methods in the tutorial chapter that you mentioned @stuartromanek, if you like?

To make sure we don't forget: we should close this PR once we merge this as well https://github.com/apostrophecms/apostrophe-documentation/pull/45

Bumping this PR again @stuartromanek and @boutell 😇
As a quick recap: we went around the whole background-image discussion by limiting the scope of this PR to simply adding a apos.images.srcset method.
apos.attachments.getImageSize was added in 60d99c8a82b38b4675da44d9bfb6d558a5a1e9f1 to make it simple to implement the same default sizes attribute as WordPress does ((max-width: {{ imageSize.width }}px) 100vw, {{ imageSize.width }}px). I'm not 100% sure we need to keep that method, but it could be helpful, I suppose.

@stuartromanek given that this doesn't change the standard behavior of our widgets, do you see any objection to merging it? We could then provide a HOWTO on how to do srcset at project level.
@fredrikekelund it sounds like getImageSize has no remaining application here?

@boutell I removed the apos.attachments.getImageSize template helper. If we realise at a later point that it would be helpful, we can bring it back – but right now it seemed mostly like a relic.
I also merged the latest master, so the branch should be mergeable now!

merged

🙌


Added some tooltips for the cross link search task view.

Quick little PR to add some tool tip boxes to the cross link search task view. I only added a handful of the Xlink specific ones, pulled from the Wiki with some light editing.

10/10. Would review again

Kinda hard to review not gonna lie


Note List Buttons Question

How to get buttons like on screenshot in this repo:

Now, on my linux buttons looks this way:

Thanks!


Issues with Xcode Build Phases Script

Hi, I find arkana very useful and was successfully to switch between different environment sets.
But when I try to integrate this to Xcode Build Phase:
tmp=${CONFIGURATION#*(}   # remove prefix ending in "("
env=${tmp%)*}   # remove suffix starting with ")"

bundle exec arkana -d ".env.${env}"

I get ERROR /Library/Ruby/Site/2.6.0/rubygems.rb:265:in find_spec_for_exe': can't find gem bundler (>= 0.a) with executable bundle (Gem::GemNotFoundException)`
Here is the output of gem environment also in Build Phase:

Showing Recent Messages
RubyGems Environment: - RUBYGEMS VERSION: 3.3.20 - RUBY VERSION: 2.6.10 (2022-04-12 patchlevel 210) [universal.arm64e-darwin22] - INSTALLATION DIRECTORY: /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/gems/2.6.0 - USER INSTALLATION DIRECTORY: /Users/johnny/.gem/ruby/2.6.0 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby - GIT EXECUTABLE: /Applications/Xcode.app/Contents/Developer/usr/bin/git - EXECUTABLE DIRECTORY: /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin - SPEC CACHE DIRECTORY: /Users/johnny/.gem/specs - SYSTEM CONFIGURATION DIRECTORY: /Library/Ruby/Site - RUBYGEMS PLATFORMS: - ruby - universal-darwin-22 - GEM PATHS: - /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/gems/2.6.0 - /Users/johnny/.gem/ruby/2.6.0 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :backtrace => true - :bulk_threshold => 1000 - REMOTE SOURCES: - https://rubygems.org/ - SHELL PATH: - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/appleinternal/bin - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/local/bin - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/libexec - /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/usr/bin - /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/usr/appleinternal/bin - /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/usr/local/bin - /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin - /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/local/bin - /Applications/Xcode.app/Contents/Developer/usr/bin - /Applications/Xcode.app/Contents/Developer/usr/local/bin - /usr/local/bin - /usr/bin - /bin - /usr/sbin - /sbin

Im on MacOS 13.0 Xcode 14.0

Hi @jhonny-me 👋
I strongly advise you not to integrate it with Xcode Build Phase (and this is a super valid point I should raise in the README file, thanks for this)
There are two main reasons for this:

Xcode doesn't play well with bundler in general. If you've ever had to deal with any other Run Script in your Build Phase that used any other bundle-powered gem (like rake, fastlane, etc), you'll have those same issues. It's not easy to workaround those issues, and they're unstable, and often environment-specific (meaning not friendly with a larger team, specially if your team uses different setups like different shell versions, ruby version managers, etc).
Arkana encodes your secrets every single time it's run, which means it'll generate new Swift code on every run. If you plug this in in your Build Phase, this means all the builds will have a wider set of changes than they should, thus making your build time slower, because it'd be busting more cache than it really needed.

Unfortunately, this means Arkana must be run outside of your normal build pipeline, when using Xcode UI. When building programmatically this can be easily changed to simply adding a step to your scripts to run Arkana before any build_app in fastlane or xcodebuild.
I hope you find this information useful! Let me know if you have more questions, happy to answer them 😊

Hi, @rogerluan thanks for the quick response. Not sure about your refer to Xcode UI, but here is my setup, the arkana command is in the Generate Keys script, which is required since I need to update the output according to input CONFIGURATION at each run from Xcode, or do you suggest another way to implement?
(I was on a existing project and migrating from a self-implemented openssl bash script to Arkana)

By Xcode UI I mean just the regular Xcode.app :) (I just wasn't sure if you were building via CLI e.g. fastlane, xcodebuild, etc)

I need to update the output according to input CONFIGURATION at each run from Xcode
[…]
or do you suggest another way to implement?

If this is a non-negotiable requirement of your project (or DevX - Developer Experience), you might be better off keeping the old logic you had in place.
If you really want to attempt to actually fix the bundler issues, this is one of the solutions you can do: update your shell script inside that Generate Keys to something like:
source ~/.zshrc # <-- this is the key

tmp=${CONFIGURATION#*(}   # remove prefix ending in "("
env=${tmp%)*}   # remove suffix starting with ")"

bundle exec arkana -d ".env.${env}"

However, do note that this makes a bunch of assumptions, like that the device running that build uses zsh (default in macOS since Catalina but still a variable), and that the ~/.zshrc will have the right commands to set up your preferred Ruby Version Manager (e.g. set the PATH correctly, startup rvm or rbenv or your other Ruby Version Manager).
This is a flaky setup, I don't recommend it. But it could work out for you and your team.

Yeas, it worked for my case. Much appreciated @rogerluan.
I'm going to close this one.


Computing BLEU more than once

Hey, why does computing the BLEU score more than once, affect the key value of the score dict.
e.g. 'bleu_1',  'bleu_1_1', 'bleu_1_1_1'
Overall I find the library quite user-friendly, but unsure about this behavior.

Hey @Axe-- , can you please share a reproducable example/code snippet, so I can look into the problem in detail ?

Sure! Here's the snippet
from jury import Jury
scorer = Jury()
predictions = [
    ["the cat is on the mat", "There is cat playing on the mat"],
    ["Look!    a wonderful day."]
]
references = [
    ["the cat is playing on the mat.", "The cat plays on the mat."],
    ["Today is a wonderful day", "The weather outside is wonderful."]
]

scores = scorer(predictions=predictions, references=references)
scores_ = scorer(predictions=predictions, references=references)

print(scores.keys())
print(scores_.keys())

Output:
dict_keys(['empty_predictions', 'total_items', 'bleu_1', 'bleu_2', 'bleu_3', 'bleu_4', 'meteor', 'rouge'])
dict_keys(['empty_predictions', 'total_items', 'bleu_1_1', 'bleu_2_2', 'bleu_3_3', 'bleu_4_4', 'meteor', 'rouge'])

Version Info:
import jury, datasets
print(jury.__version__, datasets.__version__)
>>> 2.0.0 1.12.1

Hope this helps!

@Axe-- Thank you for the snippet, I reproduced the behavior, and I think it is due to previous bleu implementation lack a spesific naming convention control. However, this problem does not occur in the recent version of jury (2.1.0). As the same code produces
>>> dict_keys(['empty_predictions', 'total_items', 'bleu_1', 'bleu_2', 'bleu_3', 'bleu_4', 'meteor', 'rouge'])
>>> dict_keys(['empty_predictions', 'total_items', 'bleu_1', 'bleu_2', 'bleu_3', 'bleu_4', 'meteor', 'rouge'])

Upgrading to the latest version would solve this issue.

Awesome! And thank you for all the work!


doc: improve description for a example of Key Binding JWT

Hi. I modified the example explanation to make it better understandable.
Since the example of SD-JWT is long, I think separate explanations may not be easy to see at once.
So I combined the separate explanations into one.
You can check the discussion in #218
This is my first contribution here. If there is anything that needs to be corrected,
please feel free to let me know. :)
Thank you

You should add yourself to the acknowledgements too

You should add yourself to the acknowledgements too

Thank you :) I added.


Windows glitchy output when using lockbox

Output copied from windows command prompt
Welcome to L🦀CKBOX!

Please enter the master password
>>

Enter [1] add password [2] generate random password [3] list passwords [4] remove password [5] show password [6] update master password [7] exit
>> ^C

This is likely due to the fact that the Windows Command Prompt does not natively support ANSI escape codes, which are used by the colored crate to produce colored output.
Solution:

Try termcolor which supports cross-platform abstraction for colors. Sunset colored crate from lockbox.

Related to Issue: https://github.com/SonuBardai/lockbox/issues/61


"error while upscaling"

QualityScaler 4.1.f
NVIDIA GeForce GTX 1660 Ti 6 GB Win 10
Tried all models, CPU&GPU, limited RAM, several files including logo.png from your install package.
Makes a pile of PNGs and then comes back error while upscaling.
Is there an informative log somewhere?

Extracted the directory and ran the .exe in that directory. Program runs, accepts drag and drop files, produces the intermediate files, and then errors out.

try to extract again the .zip with 7zip and check in the directory if there are 3 files:
BSRGANx2.pth
BSRGANx4.pth
RealSR_JPEGx4.pth

All present and accounted for.

Strange, in next release i will add better error message.
I think could be a driver problem, a windows 10 too old, or no permission to read and write files...
Sorry :(

what driver version do you have?

NVIDIA driver? The current Game Ready, 526.47. Win10 is up to date. The program is reading and writing files.
Informative error messages would be useful.

Hmm, that's interesting. I tried run as administrator and drag and drop stopped working.

Hi, sorry to bother again.
I have another question, when upscaling Qualitysaler will produce an image named with *_resized.png.
Can you please check if this file is created and if there is a watermark on it?

Yes, and yes. Says Upscaled with etc etc.

Okok thanks, I thought that QualityScaler was not finding the font file for applying the watermark, but it seems not :(

Hi, sorry to bother you again.
Did you have installed Visual C++ Redistributable ?
If not, here is a .zip with all packages
https://www.techpowerup.com/download/visual-c-redistributable-runtime-package-all-in-one/
:)

install_all.bat.
Oh Good.
Fine, let's go.
Welp, no change.

:(

Ran that install. DXDIAG says DirectX 12 with no problems found.

I thank you from the bottom of my heart for your support. At this point I don't know which way to turn anymore.
:(
Maybe it may be some problem in the compilation phase or something, and I have no control over that.

Time to write in some error logging?

yes

Hello, I am another user having this issue. I was about to purchase the software but then decided to do trial instead and see the results  and compare to Topaz. I installed trial version and when i run it, i see that the software resizes the photos, splits them into 9 images but when it is about to upscale, I receive "error while upscaling". If this gets fixed and the results are good, im happy to move to paid version.
Note, when i downloaded the zip file, and unpacked it, Windows 11 blocked the .exe file saying it contains Trojan Horse. I had to disable firewall and then proceeded with running the app. But not sure if Windows was still not somehow blocking the upscaling. Thanks

Hi @JadoreHC ,

yes, there is a resize option to reduce the time to upscale an image: of course the more you shrink the photo, the less the quality of the upscale will be (by default it is 70%)
qualityscaler cut the image when it does not fit in VRAM/RAM limit (default is 8 GB)
so something is not working with communication beetween gpu and pytorch:

[ ] What are your pc specs?
[ ] Did you followed the readme and installed DirectX and Visual C Redistributable?
[ ] Or maibe Windows defender is blocking the app, just disable to try this pls (I cannot try because the actually Windows i use does not have Defender preinstalled).

Let me know so i can better undestand the problem :)
Unfortunately the false positive of the antivirus is the fault of the library used to package the Python code in .exe - https://www.reddit.com/r/learnpython/comments/sidi10/pyinstaller_exe_is_labeled_as_a_trojan_by_avg/
Thank you :)

Hi,
thanks for the swift response :) very kind of you... my pc has 32 GB RAM and I also had DirectX and Visual C installed.
I have tried your advice and left the default resize to 70% (300p pic to 200p) and the upscale went through (in 7 sec.). I did some testing for different size pictures and the maximum size the software can handle is 200p (either height or width). Anything above will crash ("error while upscaling". Since i was testing 700p-1000p pics, i could compare upscaled pics to their reference and see how precise it was... Some results were interesting but due to downsizing, a lot of artifacts were lost. I upscale videos and for Topaz Upscaling, my PC can handle 720p-1080p videos and for Interpolation, Dain app can interpolate 578p videos and Rife App 1080p videos. Do you think your app will be able to handle bigger formats without crashing? Not sure what RAM i would need to be able to upscale bigger videos, in your references, you even have 4k vids.
Thank you very much for your help. Glad the program is working now :)

Good find. Confirmed, works with images 200 pixels and under. That should be a help in the troubleshooting.

Hi @nottooloud @JadoreHC thank you very much for your valuable feedback :D
Abolutely your rig is capable of upscale any kind of image and video, any directx12 gpu can works well (i've tested rx 570 and gtx 1660) so must be a Pytorch problem, i hope they release a fix in a short time.
In the meantime I will put more exhaustive logs and with more information so as to better understand what happens :)

@nottooloud @JadoreHC Hi, i just released new update 6.0 with error log improvement. If someone can test it maibe we can understand why it fails :)
Thank you in advance :)

6.0 works here. No error. Absolutely enormous file, 3.6mb PNG 100% scaled came out 88MB instead of the expected 15 or so, but I can always compress it with another program.

Im still getting errors in 6.0 it says to check the .log file but not sure where the .log file is located? I do not see it in QualityScaler folder or the folder where the upscaled pic is located

is located in QualityScaler folder, there is a QualityScaler.log :)

oh thanks. i used search engine and it didnt pick up extensions... i found the log. this is the error (small 200x200 pics still work, but bigger ones don't - even if software splits them into 9 smaller pics)
Error while upscaling
CHECK failed: ((((HRESULT)((d3d_device->CreateCommittedResource( &properties, D3D12_HEAP_FLAG_NONE, &resource_buffer, D3D12_RESOURCE_STATE_UNORDERED_ACCESS, nullptr, __uuidof(out), reinterpret_cast<void*>(out))))) >= 0)) == (true):

Mh, strange error; can you tell me your pc full spec? :)

Sure, here you go... thanks in advance

Thank you!
I think i found the problem. Actually QualityScaler is trying to use your Intel GPU instead of your Nvidia gpu. To resolve this issue you should go in Windows Settings > Graphic settrings > Add QualityScaler.exe > Options > Select Nvidia gpu :

Let me know if this fix the issue :) Thank you!

oh wow. this worked like a charm! thank you so much :) works perfectly now :)

Nice!!
Next release will support multi gpu system like your with the possibility to choose the gpu :D


Prevent sensitive request headers from being logged in debug level

Description:
Hey all, first just some quick background before getting into the issue we're experiencing. We wrote a small service that is called by the ext_authz filter to perform an OIDC Authorization Flow, and verify existing JWTs stored as cookies in request headers.
The JWT cookie contains sensitive information and therefore shouldn't be logged, however we noticed that when envoy is run with -l debug, various components will log the full request headers including the JWT, e.g.:
envoy_1         | [2020-01-10 16:29:21.082][14][debug][http] [source/common/http/conn_manager_impl.cc:246] [C5] new stream
envoy_1         | [2020-01-10 16:29:21.082][14][debug][http] [source/common/http/conn_manager_impl.cc:619] [C5][S6425470214323392008] request headers complete (end_stream=true):
envoy_1         | ':authority', 'localhost:9002'
envoy_1         | ':path', '/say'
envoy_1         | ':method', 'GET'
envoy_1         | 'user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0'
envoy_1         | 'accept', 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'
envoy_1         | 'accept-language', 'en-US,en;q=0.5'
envoy_1         | 'accept-encoding', 'gzip, deflate'
envoy_1         | 'dnt', '1'
envoy_1         | 'connection', 'keep-alive'
envoy_1         | 'cookie', 'oidc-service-token=supersecrettoken'
envoy_1         | 'upgrade-insecure-requests', '1'
envoy_1         | 'x-svc-cluster', 'sayer'

and
envoy_1         | [2020-01-10 16:29:21.083][14][debug][router] [source/common/router/router.cc:514] [C5][S6425470214323392008] router decoding headers:
envoy_1         | ':authority', 'localhost:9002'
envoy_1         | ':path', '/say'
envoy_1         | ':method', 'GET'
envoy_1         | ':scheme', 'http'
envoy_1         | 'user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0'
envoy_1         | 'accept', 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'
envoy_1         | 'accept-language', 'en-US,en;q=0.5'
envoy_1         | 'accept-encoding', 'gzip, deflate'
envoy_1         | 'dnt', '1'
envoy_1         | 'cookie', 'oidc-service-token=supersecrettoken'
envoy_1         | 'upgrade-insecure-requests', '1'
envoy_1         | 'x-svc-cluster', 'sayer'
envoy_1         | 'x-forwarded-for', '<IP_ADDRESS>'
envoy_1         | 'x-forwarded-proto', 'http'
envoy_1         | 'x-envoy-internal', 'true'
envoy_1         | 'x-request-id', '635a3677-6c36-404e-9421-8c7a1f37304e'
envoy_1         | 'x-envoy-expected-rq-timeout-ms', '20000'

Normally we don't run our production envoy's with debug level, however there are instances where we will temporarily set the level to debug when troubleshooting issues etc.
I'm wondering if there is some way to exclude particular headers from being logged in debug level? The only documentation I can seem to find for configuring logging is for access logs, not envoy's application logs.
Thanks!

Thanks for raising @nulltrope. In general today we assume that debug/trace logs carry sensitive/trusted information and are primarily used for development, though I think it's reasonable to (optionally) do better here. Marking this as needing a design proposal.

Hi. I was about to report a similar issue.
I was pointed to a related issue https://github.com/envoyproxy/envoy/issues/4757 and a PR https://github.com/envoyproxy/envoy/pull/9315. However these address only logging proto messages.
For sure we need a possibility of specifying sensitive headers through some configuration as there are a variety of different deployment scenarios and some of them find the full authorization logging useful.
Secondly it would be helpful to use a common headers (or any other sensitive information) logging interface. Bonus points for a generalized log sanitization mechanism through some listeners or visitors. Maybe there's a way of utilizing the proto redaction functionality mentioned earlier.
Also we need a way of enforcing usage of provided tooling as anyone could log sensitive information plain text.
Here are other examples of logging headers in Envoy:
https://github.com/envoyproxy/envoy/blob/master/source/common/http/conn_manager_impl.cc#L719
https://github.com/envoyproxy/envoy/blob/master/source/common/router/router.cc#L597
Also another issue regarding sanitization of config_dump https://github.com/envoyproxy/envoy/pull/7365

Having similar concerns about the debug logs. Not sure if someone is looking into this.

FYI: I had an attempt at this issue, to provide way to exclude particular headers from being logged in debug level, in #27579 and #27820.
Feedback from https://github.com/envoyproxy/envoy/pull/27579#issuecomment-1587509837 is that this approach is discouraged, and wrapper script to process logs is encouraged.

Feedback from https://github.com/envoyproxy/envoy/pull/27579#issuecomment-1587509837 is that this approach is discouraged, and wrapper script to process logs is encouraged.

Ultimately, this is how I solved this issue myself.

We stumbled onto this issue as well.
It is common to enable the debug log level for troubleshooting issues, but is can also be impractical to write a wrapper script. Not to mention that many users are unaware that sensitive info is being logged, and might be sending them to 3rd parties.
Maybe an easy way to solve this would be to change the level of that particular log to trace, and have a summarized version at the debug level? Something like header=hash or header=size


variables referred by anonymous inner class has to be final.

fixed compilation issue: variables referred by anonymous inner class has to be marked as final.

Thanks!


fix(dotcom-shell): stop intersection logic if modal is open

Related Ticket(s)
#8078
Description
There was some previous logic to avoid this bug from happening, but some check may have slipped through that made it reoccur. Instead of adding a check to every conditional, this PR only adds a simple check if the locale modal is open, and stops any code that might make the browser "scroll" in the handleIntersection function and would make the modal disappear.
This needs to be tested in an actual phone (or Browserstack).
Changelog
Changed

changed location of the conditional check for the local modal being open to stop it from disappearing

@IgnacioBecerra looks like some prettier issues, can you take a look?


Native dialogs Open file or Open folder opening behind main window on RHEL 8/El8 clones

Native dialogs Open file or Open folder opening behind main window on RHEL 8/EL 8 clones.
This has only happened after updating to 1.66.0.
Desktop Environment: gnome.
https://user-images.githubusercontent.com/68813857/161046219-18409912-09af-4f77-ba08-f7b33a203fd5.mp4

The same problem on Linux Mint with Mate env after update to 1.66. I hope that will be fixed in 1.66.1 but it is not.

Same behavior on Ubuntu 22.04 pre-release, but I was also seeing it on 20.04 before I upgraded yesterday.
Visual Studio Code

"Open File" is ready

and then I can get to the dialog by clicking on the toast or by using the switch-window shortcut key.
Code About dialog output
Version: 1.66.2
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-11T07:49:24.808Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.15.0-25-generic

Seeing the same issue, I  didn't find this ticket so I filed #147400 which I have now closed. Mentioning here in case there's anything useful on that ticket when this one gets worked on.

Also happening to me on Arch Linux with GNOME 42 under Wayland:
Help -> About as follows:
Version: 1.66.2
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-11T07:49:24.808Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.17.3-arch1-1

Same issue, Ubuntu 21.10, Cinnamon VM.
Version: 1.66.2
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-11T07:49:24.808Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.13.0-39-generic

Same issue on Arch Linux running VSCodium on Cinnamon.
Version: 1.66.2
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-13T00:16:29.523Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.17.4-zen1-1-zen

Same for me
Version: 1.66.2
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-11T07:49:24.808Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.17.4-100.fc34.x86_64

Here as well
Version: 1.66.0
Commit: e18005f0f1b33c29e81d732535d8c0e47cafb0b5
Date: 2022-04-02T14:00:30.308Z
Electron: 17.3.1
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.15.32-1-MANJARO

Same issue using Arch and KDE Plasma.
Version: 1.66.0
Commit: e18005f0f1b33c29e81d732535d8c0e47cafb0b5
Date: 2022-04-02T14:00:30.308Z
Electron: 17.4.0
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.17.4-arch1-1

Operating System: Arch Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.17.4-arch1-1 (64-bit)
Graphics Platform: X11

Same issue here using Solus Linux 4.1
Version: 1.67.0
Commit: 57fd6d0195bb9b9d1b49f6da5db789060795de47
Date: 2022-05-06T09:53:29+10:00
Electron: 17.4.1
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.15.37-214.current

Same issue using Arch and KDE Plasma.
Version: 1.67.1
Commit: da15b6fd3ef856477bf6f4fb29ba1b7af717770d
Date: 2022-05-10T21:35:59.370Z
Electron: 17.4.3
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.17.7-arch1-1

Same problem  ubuntu 20 or 22:
code (v1.67.1)
first open dialog: right place
second et other open dialog: always behind application
sudo apt ugrade (code 1.67.1 to 1.67.2)
code
first open dialog: right place
second et other open dialog: always behind application

Currently have this issue with Save As. Running Fedora 36 Workstation.
VS Code installed via Microsoft repo not Snap/FlatPak

Currently have this issue with Save As. Running Fedora 36 Workstation.
VS Code installed via Microsoft repo not Snap/FlatPak

Seems like a temporary solution

Currently have this issue with Save As. Running Fedora 36 Workstation.
VS Code installed via Microsoft repo not Snap/FlatPak

Seems like a temporary solution

I think they were just mentioning the setup they experienced the issue with, not suggesting it as a solution.

Currently have this issue with Save As. Running Fedora 36 Workstation.
VS Code installed via Microsoft repo not Snap/FlatPak

Seems like a temporary solution

I think they were just mentioning the setup they experienced the issue with, not suggesting it as a solution.

That's why I say "temporary".

That's why I say "temporary".

I mean that it's not a solution at all, just that they experienced the bug using the MS repo version.

That's why I say "temporary".

I mean that it's not a solution at all, just that they experienced the bug using the MS repo version.

It is a temporary solution for those who need to use the editor today.

That's why I say "temporary".

I mean that it's not a solution at all, just that they experienced the bug using the MS repo version.

It is a temporary solution for those who need to use the editor today.

@SethBashamDev is stating they have the issue and that the version they are using is installed from the MS RPM repo. There is no mention of a temporary solution. Please refrain from adding noise to this bug report.

@SethBashamDev is stating they have the issue and that the version they are using is installed from the MS RPM repo. There is no mention of a temporary solution. Please refrain from adding noise to this bug report.

For those with this issue (like myself) or this issue https://github.com/microsoft/vscode/issues/150119 and not being able to use this app, INSTALLING FROM SNAP STORE allows you to use it for the time being.

@SethBashamDev is stating they have the issue and that the version they are using is installed from the MS RPM repo. There is no mention of a temporary solution. Please refrain from adding noise to this bug report.

I will rephrase myself then.
For those with this issue (like myself) or this issue #150119 and not being able to use this app, INSTALLING FROM SNAP STORE allows you to circumvent the issue for the time being.

On RHEL 8/AlmaLinux 8 I can happily use the app in this state. It is just a pain and the regression needs to be fixed.
For many using a snap or flatpak is not an option and it is certainly not a workaround. Some users are in firms and/or environments that requires software come from a validated trusted sources.
Yes, I agree that for some a snap or flatpak maybe an option, but for me and others it is no option at all.

It's a problem on Ubuntu 18.04
Version: 1.68.0
Commit: 4af164ea3a06f701fe3e89a2bcbb421d2026b68f
Date: 2022-06-08T11:49:57.055Z
Electron: 17.4.7
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 4.15.0-187-generic

Also on Ubuntu 20.04
But even worse:
It no longer defaults to the same directory as the current file being edited. It shows recent files, and there is no easy way of getting into the directory of the current file!

Also on Ubuntu 20.04
But even worse: It no longer defaults to the same directory as the current file being edited. It shows recent files, and there is no easy way of getting into the directory of the current file!

Yes, same behaviour. So aggravating

Also on Ubuntu 20.04
But even worse: It no longer defaults to the same directory as the current file being edited. It shows recent files, and there is no easy way of getting into the directory of the current file!

@mrtnlrsn, thats a different story: #151668, fixed and the fix is included in the "May 2022 Recovery 1" milestone.

Same problem (file dialog is behind vscode window) on Mint:
OS Info:
    OS: Linux Mint 19.3 Tricia x86_64
    DE: MATE
    WM: Metacity (Marco)

VS Code Info:
    Version: 1.68.1
    Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630
    Date: 2022-06-15T02:58:26.441Z
    Electron: 17.4.7
    Chromium: 98.0.4758.141
    Node.js: 16.13.0
    V8: <IP_ADDRESS>-electron.0
    OS: Linux x64 5.11.16-051116-generic

This is because of the PR that made Electron use the XDG Desktop Portal. Unfortunately, the PR was merged without this issue and others like it being discovered. I have looked at the Chromium code to try to fix this, but it just isn't possible given everything I currently know. I have suggested to upstream that they might consider reverting the PR. I know @deepak1556 has done more work upstream near this code.
As a workaround, you could try GTK_USE_PORTAL=0 code .... Will probably fix your issues.

On Mon, 2022-06-27 at 10:16 -0700, Tristan Partin wrote:

This is because of the PR that made Electron use the XDG Desktop Portal. Unfortunately, the PR
was merged without this issue and others like it being discovered. I have looked at the Chromium
code to try to fix this, but it just isn't possible given everything I currently know. I have
suggested to upstream that they might consider reverting the PR. I know @deepak1556 has done more
work upstream near this code.
As a workaround, you could try GTK_USE_PORTAL=0 code .... Will probably fix your issues.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

Suggested workaround does not work.
Regards
Phil
--
*** Playing the game for the games own sake. ***
Associations:

Debian Maintainer (DM)
Fedora/EPEL Maintainer.
Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B

Same for me:
Version: 1.68.1
Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630
Date: 2022-06-15T02:58:26.441Z
Electron: 17.4.7
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.4.0-121-generic

Same here on KDE:
Version: 1.68.1
Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630
Date: 2022-06-16T08:22:04.269Z
Electron: 17.4.3
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.18.6-1-MANJARO

Upstream issue https://github.com/electron/electron/issues/32857

Has anyone found a solution for this problem yet?

Had the same issue... until I restarted VSCode. Now it's behaving. Worth a try... :)

On Tue, 2022-07-05 at 23:58 -0700, JulienBERNU wrote:

Had the same issue... until I restarted VSCode. Now it's behaving. Worth a try... :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

If you stated install source, platform etc. this comment may have some use. But the issue remains
and your comment is not helpful.
Regards
Phil
--
*** Playing the game for the games own sake. ***
Associations:

Debian Maintainer (DM)
Fedora/EPEL Maintainer.
Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B

This above mentioned workaround works for me on Debian 11 not using Wayland:
GTK_USE_PORTAL=0 code
Version: 1.68.1
Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630
Date: 2022-06-15T02:58:26.441Z
Electron: 17.4.7
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.10.0-14-amd64

Same issue with latest code release (open dialog is behind vscode window).
Version: 1.69.1
Commit: b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a
Date: 2022-07-12T08:28:29.328Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.4.0-122-generic
Workaround GTK_USE_PORTAL=0 code doesn't fix.
Regards

Same issue
Version: 1.69.1
Commit: b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a
Date: 2022-07-12T08:28:29.328Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.4.0-121-generic

same
Version: 1.69.1
Commit: b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a
Date: 2022-07-12T08:28:29.328Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.13.0-52-generic snap

Thanks everyone for the inputs, at this time we know the root cause of the issue in upstream. I am going to lock this issue to avoid some noise. I will reopen the issue once a fix has been made.


Remove debug logging of password

As discussed in: https://github.com/gopasspw/gopass/pull/1865#discussion_r602135817_
We currently might be logging plaintext password in the debug log. People should never upload or share a debug log without checking it first, but if someone (especially on Windows) were to set the env variables that enables debug logging, it's fairly easy to "forget" them and let them set, thus storing a lot of plaintext password to disk.

Duplicate of #1883


Sync receiver

@bausmeier Were you thinking that the SyncSender/SyncReceiver would use an/the instance of FhirEngine or were you thinking of using an/the instance of Database rather?
Your comment about the transactions made me think about at what level these services should be operating.
The reason I ask comes back to my original question, in trying to determine at what level to make the decision about whether to perform the lookup of the resource at the service or Database level.
Should our services be working with Database directly, I am thinking that maybe it makes sense to expose the transaction management from that API so that the functions can continue to perform a single operation but we can wrap those operations in a transaction from the service.
But if we are dealing with an/the instance of FhirEngine then I don't think that makes sense since it would mean leaking implementation concepts out of the API.

Looking at what currently lives in the FhirEngine vs in the Database, and how the server sync works, I think we'll need to be working at a lower level than at the engine - so at the database. I agree that the transaction handling could be exposed from the database as long as it's still encapsulated within the engine.

@bausmeier We need to add a dependency to the p2p module on org.jetbrains.kotlinx:kotlinx-coroutines-core which we are both going to need. Should I add that to the sync-payload branch?

Yeah you can. And I think we should go ahead and merge that PR if you're happy with it?

@bausmeier I am guessing that we will need the corresponding test library too? Although I that engine has a dependency on the test library so I guess we will inherit it from there. I haven't gotten to writing tests yet.

I'm not familiar with the testing library so I'm not sure. Sounds likely that we'd need to add it. The tests I wrote don't use coroutines.

Looking at what currently lives in the FhirEngine vs in the Database, and how the server sync works, I think we'll need to be working at a lower level than at the engine - so at the database. I agree that the transaction handling could be exposed from the database as long as it's still encapsulated within the engine.

I only just noticed that Database is internal. So it seems to me like the intention of the engine was for all interaction to be through FhirEngine.
Perhaps, we should reconsider our discussion about working with Database directly. Or at least I think that we should add it as an agenda item for discussion in the call tomorrow.
What do you think?
I mean could implement what would have been implemented in SyncReceiver in FhirEngine.
I do prefer your design though. I just think we need to clear publicizing Database with the rest of the team since it would break what seems like a fundamental design decision.

Ah, yeah that's a good point. When I was experimenting with the API originally I was doing so from within the engine module, but I'd like to keep the p2p stuff separate from that. The Database class should probably be kept internal then, and the functions we need would have to be accessed via FhirEngine. I don't think that publicising Database is the right approach. Raising this on the call tomorrow to get some suggestions is a good idea.

@bausmeier We could make SyncReceiver and interface and introduce a new FhirEngine interface which combines the existing one with SyncReceiver and supply a corresponding implementation.
Therefore we keep the existing FhirEngine unchanged and it is up to the client to instantiate the FhirEngine implementation with the appropriate support for the functionality they require.


Fixes to packaging

Looks like it's failing the coverage check across the board. We should either disable that or add tests (which I realize may be difficult for the plugin here).

Looks like it's failing the coverage check across the board. We should either disable that or add tests (which I realize may be difficult for the plugin here).

The coverage is low because of the tests which fail because the koji package isn’t available:
 E   ModuleNotFoundError: No module named 'koji'

I’m on it.

The ci-smoketests pipeline needs krb5-devel to install koji properly.

The ci-smoketests pipeline needs krb5-devel to install koji properly.

Hah, didn’t think of that this innocent change to tox.ini would affect the smoke tests, too:
@@ -5,7 +5,6 @@ isolated_build = true
 skip_missing_interpreters = true

 [testenv]
-skip_install = true
 sitepackages = false
 deps =
   pytest


Error: linear: vector must have 1 or 4 elements, srgb, 5 channel image, using .flatten

const filename = './1221021360.tiff'
const background = '#FFFFFF'

await sharp(filename)
.resize({
  height: 120,
  width: 120,
  fit: 'contain',
  background
})
.flatten({ background })
.webp({ quality: 80 })
.toFile(filename + '.webp')

Throws error: [Error: linear: vector must have 1 or 4 elements]
metadata of the image:
{
  format: 'tiff',
  width: 4400,
  height: 4400,
  space: 'srgb',
  channels: 5,
  depth: 'uchar',
  density: 300,
  isProgressive: false,
  pages: 1,
  resolutionUnit: 'inch',
  hasProfile: true,
  hasAlpha: true,
  orientation: 1,
  icc: ...
}

when leaving out .flatten() the code runs but the image comes out transparent obviously and we dont want that.
Link to zip containing 2 .tiff files that will error.

Hi, did you see #2266?
What would be your expectation of the output of the flatten operation when there are two alpha channels?

Hi, no I missed it 😅.
I will move to the open issue, thanks.


etcdserver: fix nil dereference in physical Compact on proposal timeout

Fixes #5292

check the nil first?
package main

import (
	"fmt"
)

type aa struct {
	a string
}

func main() {
	v := &aa{}
	v = nil
	fmt.Println(v == nil && v.a == "aaa")
	fmt.Println(v.a)
}

This panics.

@gyuho huh? that code evaluates v.a because v == nil; in this patch the && is short circuiting

ah I missed that it was !=. You are right.
LGTM.