Network: address starvation when too many instances are started at the same time

When configuring SEE with automatic IP address assignment, if too many instances are started at the same time, one or more might not be able to get a valid IP address and will give up.
SEE inspect the addresses in use when generating a new one. It will pick the next available and try to reserve it. If a concurrent instance will get that IP address at the same time, SEE will detect that and repeat the procedure. This is repeated an arbitrarily amount of times.
If several instances are started at the same time, one or more might exceed the amount of attempts before getting a valid one.
A possible mitigation for the issue would be randomising the IP address selection reducing the risk of concurrent collisions.

Fix released


Add support for Python 3.9 and 3.10

Attempting to run our tests on Python 3.9 and 3.10 failed:
https://github.com/freelawproject/juriscraper/runs/4246065412?check_suite_focus=true
That failed due to the commit here:
https://github.com/freelawproject/juriscraper/commit/476e5b5c35df722d6a1b7452af71e86ad678f154
At a glance, it looks like feedparser doesn't work in Python 3.9, and we probably need to upgrade it to fix that issue. I have a vague memory that we haven't upgraded feedparser because they made a bunch of minor (but important) backwards incompatible changes, so it might take a bit of work to get it upgraded.

just an fwiw - I just used the current feed parser to update the CAFC RSS feed code.

feedparser version 6.0.8 works with Python 3.9 and 3.10.
All tests in the new Python versions passed without problem.


The data of the previous days was lost when the panel was displayed

Please answer these questions before submitting your issue.

Why do you submit this issue?
[x] Bug

Bug

Which version of SkyWalking, OS and JRE?
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)

Which company or project?
UeWell

What happened?
On the dashboard, if I choose a day data, most of the data will be empty,like this:

But i have some data at 3 days ago

And http post data is
{"query":"query queryData($condition: MetricsCondition!, $duration: Duration!) {\n  readMetricsValues: readMetricsValues(condition: $condition, duration: $duration) {\n    label\n    values {\n      values {value}\n    }\n  }}","variables":{"duration":{"start":"2020-12-13 17","end":"2020-12-14 17","step":"HOUR"},"condition":{"name":"instance_jvm_memory_heap","entity":{"scope":"ServiceInstance","serviceName":"ubirth","serviceInstanceName":"ecs2","normal":true}}}}

Requirement or improvement
Is it bug?
How to solve this problem？

The query time is based on TimeZone. The data in the storage is based on OAP timezone. I guess you miss some of them.


Library/Homebrew: move stdin ruby scripts to files under utils.

This avoids can avoid UID/EUID related issues with Ruby scripts passed over stdin clashing with Ruby security features.
It's also just a bit nicer to have Ruby scripts in files instead.
While we're here:

refactor some shared logic into a new setup-gem-home-bundle-gemfile function in ruby.sh
do some general cleanup of lock.sh
prioritise flock over python in lock.sh

Fixes https://github.com/Homebrew/brew/issues/17008

Personally I'd put the ruby scripts in utils/ruby, but this is fine to me too.

I think I prefer the *_sh directories. For example, if you moved them and did require utils/ruby_check_version" (which seems, on the surface, a reasonable thing to so): the Ruby process will immediately exit upon require`ing 😅.


update dependencies for rai-core-flask, raiwidgets and responsibleai packages

Description
Updating to the following packages/versions:
ipykernel 6.8.0
markupsafe 2.1.2
numba 0.55.2
itsdangerous 2.1.2
markupsafe 2.1.2
werkzeug 2.2.3

Checklist

[ ] I have added screenshots above for all UI changes.
[ ] I have added e2e tests for all UI changes.
[ ] Documentation was updated if it was needed.

use https://github.com/microsoft/responsible-ai-toolbox/pull/2016


Add -v to docker-compose down

In some scenario the anonymous volume will remain on the disk and prevent the deployment from restart,
to remove it we need to add -v in the command docker-compose down

clost it as https://github.com/vmware/harbor/pull/1776


Update Configuration.md

Summary

Test plan

Hi, the default for collectCoverage is false:
https://github.com/facebook/jest/blob/5bad34972389ffaf294138302d82a2054bd6c3fe/packages/jest-config/src/Defaults.ts#L23
If you are seeing coverage despite not enabling it, maybe some other tool configured it for you.

Correct - it (and shall remain) false by default


skypeforlinux, spotify: remove snap.yaml file

Description of changes

Using home-manager it's impossible to install these two packages because there is a conflict when setting up the path since both packages will provide a snap.yaml file at the same location.
home-manager-path> error: collision between `/nix/store/x42s25yqd19z1qlx3b95znszi7ldr0w4-spotify-<IP_ADDRESS>1.ge66eb7bc/snap.yaml' and `/nix/store/g49q40sbd00y1hpbrz29hqqdgzy13kdd-skypeforlinux-<IP_ADDRESS>/snap.yaml'

For a nixos user this file is useless as far as I can tell, and other snap-based packages that I have checked don't seem to include it either.
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

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

@mjoerg Done.


fix: support configure release vsn to "git"

The rebar3 support configuring the release version using an atom git:
{relx, [ {release, {my_rel_name, git},
            [ emqx_message_tracing_plugin
            , map_sets
            ]}
       , {dev_mode, false}
       , {include_erts, false}
       ]}.

A new tag is required


Formula in docs

there should not be a subscript i in the Xbar i on for Cox time varying formula.
Originally posted by @CamDavidsonPilon in https://github.com/CamDavidsonPilon/lifelines/discussions/1191#discussioncomment-200656

Also https://lifelines.readthedocs.io/en/latest/Survival Regression.html#cox-s-proportional-hazard-model

Subtracting the mean, or any value really, doesn't change the final inference. We subtract the mean internally for stability reasons during fitting.

Thank you for your answer, but in results containing interaction items, this can cause interpretation headaches.For example，

β3 means the coefficient when prio takes 0, but after subtracting the mean, prio takes 0 means that prio is actually equal to the mean, then this mean should preferably have a practical meaning, while the mean of the matrix has no practical counterpart, which is just a value in mathematics.

Sorry, I don't quite understand what is meant by subtracting the mean after the interaction term occurs, I used the equation below for the fit and when the results are interpreted, I would like to know if the value of X4 minus the mean is 0 or the original value of X4 is 0 when X4 takes 0?
ctv.fit(base_df, id_col="id", event_col="event", start_col="start", stop_col="stop", show_progress=True, formula="X1+X2+X3*X4")
If it is similar to linear regression, then X3*X4 should actually be the product of X3 and X4 minus the mean?

Am I to understand that subtracting the mean is doing the centering? If I have centered the matrix (subtracted the mean) before fitting, is subtracting the mean invalid?

X1+X2+X3*X4 goes in, and then we subtract the mean of each column.

If I have centered the matrix (subtracted the mean) before fitting, is subtracting the mean invalid?

I don't think it's invalid - it doesn't change the results (the Cox coefficients are the same whether I demean or not)! But if you centered before, and you have interaction terms, then your interpretation will change.
However if you are doing probability prediction, that's different.

Thank you so much！I'm much clearer！By the way，

there should not be a subscript i in the Xbar i on for Cox time varying formula.
subscript i is still in the Xbar in the latest document.


dp.change event fires twice on initial load

I'm noticing some strange behaviour when using the dp.change event handler. When the page first loads, I open the calendar, choose a date, the alert window appears twice? On subsequent clicks on a chosen date, it only fires once.
    $('#startDatePicker').on("dp.change", function (e) {
        alert(e.date);
    });

Looking into the bootstrap js code, I've noticed the code below seems to run more than it should? I'm by no means a JS expert, but if someone can shed some light on it, I'd be grateful.
        notifyEvent = function (e) {
            if (e.type === 'dp.change' && ((e.date && e.date.isSame(e.oldDate)) || (!e.date && !e.oldDate))) {
                return;
            }

            //Prevent trigger if initializing, basically if the DateTimePicker
            //data is not yet set, where still initializing
            if (!element.data('DateTimePicker')) return;
            //End mod

            element.trigger(e);
        }

Thanks,
Tom

Hi Guys,
I have the same problem codes are from latest master branch. dp.change trigger 3 time every time I do something with widget. Let us know if this has got fixes
Thanks
Sumesh

Mine fires twice every time it loads or I change a value. I might make a global variable that stores the timestamp and won't execute if the global variable contains that stamp.

Similar problem here when re-rendering a section of html containing a datetime-picker, destroying it, and then creating another one.  I actually refresh the view upon a dp.change event, so this issue creates an infinite loop for me.
I can confirm that the solution by @tomosap fixes the issue for me.

@csummers How can I fix it? What is @tomosap solution? I have infinite loop problem too... Thx for help

I have already figured out why this happening (maybe only in my case). Problem is format of datetimepicker and initial date.
Example:
$('#date').datetimepicker({
		format: 'DD.MM.YYYY'
	});

$('#date').data('DateTimePicker').date(new Date ()));

Fromat is set to 'DD.MM.YYYY', but initial date is Date object, so condition (e.date && e.date.isSame(e.oldDate) not works here (because it compare moments and their not the same, one is formated and other is full moment). To fix that, you need set initial data in same format as you defined in options.
$('#date').data('DateTimePicker').date(moment(new Date ()).format('DD.MM.YYYY'));

@l2ysho I was having this same problem.
can solve with your example.
Thank you.


Add operator for object detection with yolo

Signed-off-by: shiyu22<EMAIL_ADDRESS>

@fzliu It shows the error ModuleNotFoundError: No module named 'cv2', how can I install the package?

I think you can download it using pip install opencv-python


[bug]: Plugin breaks option-delete behavior on iterm

Describe the bug
Hi,
I'd love to use this plugin over zsh-users/zsh-syntax-highlighting but can't because of the broken behavior for option-delete on iTerm. Namely, by setting the key combination to send 0x17 or 0x1b 0x7f (enabled with the "Natural Text Editing" preset) one can perform "intelligent backward delete word" which will delete all characters after the first word delimiter encountered to the left. This is particularly useful for deleting parts of file paths.
Steps to reproduce

Run option+delete with the "Natural Text Editing" and the plugin enabled with zinit light zdharma-continuum/fast-syntax-highlighting on the string foo/bar/baz . The whole path gets deleted.

Expected behavior

Do the same but without the plugin. Obtain foo/bar/.

Screenshots and recordings
No response
Operating System & Version
darwin23.0 | apple | x86_64 | arm64 | arm64 arm
Zsh version
zsh 5.9 (x86_64-apple-darwin23.0)
Terminal emulator
xterm-256color
If using WSL on Windows, which version of WSL
None
Additional context
zinit light zsh-users/zsh-history-substring-search
zinit light zsh-users/zsh-autosuggestions
zinit light zsh-users/zsh-completions

Manually adding a bindkey to my .zshrc that'd set the key combination to send eg. 0x17 does not fix the issue.


Research how to handle relationship of OSM data

Problem
OSM data has relationship on that that contains another data for 1 data. We want to show it on HS too. And also how to handle create/update on HS map.
Solution

Research the mapping yml how to include relation data
Create document how it's work and how to develop it on architecture level.

what i found
What i do:
1. Already using relation/relation_member on docker osm.
2. No relation found under St Thompson

API:
1. https://api.openstreetmap.org/api/0.6/way/276034415/full
2. https://api.openstreetmap.org/api/0.6/way/122227536/full

There are nodes that has same between those, but there is no relationship between it
1. https://api.openstreetmap.org/api/0.6/way/276034415/relations
2. https://api.openstreetmap.org/api/0.6/way/122227536/relations
and on the nodes, it is also empty
3. https://api.openstreetmap.org/api/0.6/node/2806776152/relations

So we can't find how to get relationship between hospital and campus.
Except: Check nodes of campus and hospital that has same node (extend osmenrich to save it's nodes)

But it will make our data big, because we need to save all ways.

do we still need this @timlinux ?


node.js: Debug console always displays some internal line number for every console.log message.

VSCode Version: 1.52.1
OS Version: Windows 10 Enterprise 1909

Steps to Reproduce:
Whenever I issue a console.log statement in a nodejs program the Debug console in vscode displays as line number node_modules/diagnostic-channel-publishers/dist/src/console.pub.js:42 instead of the location where my console.log statement occurs.  I am pretty sure this was not the case earlier.

Does this issue occur when all extensions are disabled?: Yes/No

This is because diagnostic-channel-publishers overwrites your console.log message with its own method and calls the real console method internally.
You can add the package to your skipFiles to avoid this.

This is because diagnostic-channel-publishers overwrites your console.log message with its own method and calls the real console method internally.
You can add the package to your skipFiles to avoid this.


license.gemspec treated as potential license file, resulting in no detected license

I noticed https://github.com/librariesio/license-compatibility doesn't show a detected license, despite LICENSE.txt containing stock MIT. I guess the reason is license-compatibility.gemspec gets tested as a potential license file, and of course doesn't match anything:
$ script/git-repo https://github.com/librariesio/license-compatibility
License:        NOASSERTION
Matched files:  LICENSE.txt, license-compatibility.gemspec, README.md, license-compatibility.gemspec
LICENSE.txt:
  Content hash:  b7bd0ecb3f4db7dd0e9a05d0bddf606f125f38b4
  Attribution:   Copyright (c) 2018 Andrew Nesbitt
  Confidence:    98.91%
  Matcher:       Licensee::Matchers::Dice
  License:       MIT
  Closest non-matching licenses:
    MIT similarity:      98.91%
    BSL-1.0 similarity:  70.59%
    UPL-1.0 similarity:  66.67%
license-compatibility.gemspec:
  Content hash:  123c8d7817f38913909856af7bf070e2671a3467
  License:       NOASSERTION
  Closest non-matching licenses:
    Artistic-2.0 similarity:  7.78%
    OFL-1.1 similarity:       6.88%
    MS-RL similarity:         6.81%
README.md:
  Content hash:  48f8b80a326aedd7cb6ec731ecac628633c06464
  Confidence:    90.00%
  Matcher:       Licensee::Matchers::Reference
  License:       MIT
  Closest non-matching licenses:
    WTFPL similarity:      22.64%
    Unlicense similarity:  12.60%
    Zlib similarity:       10.99%
license-compatibility.gemspec:
  Confidence:  90.00%
  Matcher:     Licensee::Matchers::Gemspec
  License:     MIT

One way to fix this could be to filter out files with names ending in .gemspec (and potentially other package manager patterns, if there are others without fixed names) as potential license files.

I noticed this the other day as well - it looks like maybe the license filename regex matchers could use some tightening.


☂ Requirements for v0.4

### Committed
- [ ] #510
- [ ] #599
- [ ] #610
- [ ] #612
- [ ] https://github.com/kubernetes-sigs/kueue/issues/534
- [ ] https://github.com/kubernetes-sigs/kueue/issues/738

### Nice to have (will not block the release)

- [ ] #78
- [ ] #297
- [ ] #666
- [ ] https://github.com/kubernetes-sigs/kueue/issues/738
- [ ] https://github.com/kubernetes-sigs/kueue/issues/420

cc @denkensk @ahg-g @mwielgus @kerthcet @tenzen-y

are the candidates listed in some rough priority?

Thanks for bringing this in! @alculquicondor 🎉
One concern is about the release cycle. This is a long term before we release v0.4.0, hope we can release minor versions regularly, users can experiment with the newest features randomly rather than building with master branch.  We haven't released any versions since August last year, I think it's not a good signal. I recalled we talked about this before but couldn't find the records.

I will vote for them as they're the shortcomings Kueue has

https://github.com/kubernetes-sigs/kueue/issues/599
https://github.com/kubernetes-sigs/kueue/issues/534
https://github.com/kubernetes-sigs/kueue/issues/510
https://github.com/kubernetes-sigs/kueue/issues/78

Also good to have:

https://github.com/kubernetes-sigs/kueue/issues/610
https://github.com/kubernetes-sigs/kueue/issues/582
https://github.com/kubernetes-sigs/kueue/issues/77
https://github.com/kubernetes-sigs/kueue/issues/420

After some chat with @alculquicondor we agreed to aim at 2-3 month release cycle. The project is still young and more frequent, narrow-scoped releases will probably both work better and look better. Thus the list can be roughly prioritised into three categories:

Will do - we will postpone release if the task is not finished.
Maybe - we will try/strongly consider but will not postpone the release if the task is not finished.
For next releases - was considered for the release but most likely the task will not even be started.

Will do:

#78
#510
#599
#610

Maybe:

#666 - the work has already been started - https://github.com/ray-project/kuberay/pull/926 but due to some refactoring the important dependency is on-hold
#297 - depends on https://github.com/kubeflow/common/pull/196

For next releases:

#77 - the needed infrastructure will land 1.27 (https://github.com/kubernetes/kubernetes/pull/116161) and it will be a while before 1.27 is actually in use.
#582 - nice optimisation but no explicit need at this moment.
#420 - not sure about proper UX, most likely won't fit anyway.
#28 - won't fit, too big, no clear API/UX yet.
#74 - 2 frameworks already in the pipeline, will wait for the next release(s).

The project is still young and more frequent, narrow-scoped releases will probably both work better and look better.

By the way, can we collect the cases used by some companies in the production environment, which will encourage more people to use and participate in this project?

I have updated the issue description. @kerthcet @denkensk anything else you would like to add?
I will also share this list in the next WG meeting and in kubecon.

LGTM.

I meant to add #534 as well

I added #738 to the committed list

/close
with https://github.com/kubernetes-sigs/kueue/releases/tag/v0.4.0


[Question] Using it with glove?

Check List
Thanks for considering to open an issue. Before you submit your issue, please confirm these boxes are checked.

[X ] I have searched in existing issues but did not find the same one.
[X ] I have read the documents

Environment

Google Collab

Question
I love the ease of use of Kashgari, and were able to run it with Bert Embeddings successfully.
I would like to use glove.6B.100d embeddings but from the documentation it is not clear how to:

load these embeddings
preprocess text properly

You need to convert glove model to gensim model, then you can use it with Kashgari. Then save the gensim model with model.wv.save_word2vec_format function.
Here is the document about convert: https://radimrehurek.com/gensim/scripts/glove2word2vec.html

@BrikerMan And how to properly process sentences?
Would you consider adding this to documentation the same like you have for Bert? https://kashgari.bmio.net/embeddings/bert-embedding/

https://kashgari.bmio.net/embeddings/bert-embedding/

You need to tokenize sentences to match the Embedding you are using. Since there are many kinds of Word Embeddings with different tokenize policy, you need to figure this out. Sorry.


Update migrating-to-v4.md

@jandevriesmendix Can we revert this? @katamaks and I miscommunicated in what needed to be updated, this was not the right thing.

Reverted.


Set up C++ linter or static analysis in CI

I haven't done a C++ project before --- is there a good linter or static analyzer that we should be running on include/cxx.h and src/cxx.cc in the GitHub Actions jobs?

I'd argue that clang-tidy is one of the more up-to-date/complete/modern ones.
A set of checks also need to be enabled. The default ones probably are not enough. I recommend at least modernize-*, clang-analyzer-*and cppcoreguidelines-*.
I can have a look if you think clang-tidy is ok.

That would be great!


✨ Focus Editor On File Creation

Is your feature request related to a problem? Please describe.
I think it would be nice if the user could start typing write away after launching an empty file, instead of having to click on the first line
Describe the solution you'd like
Typically when you launch a new empty file in most code editors, the cursor will automatically be focused on the first line allowing the user to start typing right away. At worst, the user may have to refocus the screen by clicking somewhere in the window. Currently, one has to click on the first line exactly.
Describe alternatives you've considered
N/A
Additional context
If this may be a bug or something irreproducible, we can just close this issue
Below, is a video of what I am seeing:
https://streamable.com/a0cclr

Good catch @adsalad!

I'll try and get something working for this, PR will be linked back here if something works out.

I was thinking of maybe adding a becomeFirstResponder() to one of the UIKit text input views as a possible fix. One of CodeFileView and STTextViewController seem to be a good place to start. However, these files seem to be read-only.

@adsalad  What is the status of this? Are you still planning on working on this?

This one was more difficult than I thought, I think someone else should take a crack at it.

Hi, as I mentioned on Discord, I'm taking a look at this issue now. As @adsalad mentioned, the solution might be within CodeEditTextView or even in STTextView.


Support cygwin git

VSCode Version: 1.2.1
OS Version: Windows 10 Build 14367

Steps to Reproduce:

Install Cygwin
Edit .vscode/settings.json to set git.path to point to "\\cygwin64\\bin\\git.exe
VS Code throws up an error message of ENOENT: no such file or directory, lstat 'C:\cygdrive', as described here

This is, of course, because Cygwin namespaces the filesystem differently. However, doing this (which usually fixes things in other tools):
        "git.path": "\\cygwin64\\bin\\bash.exe git",

...then results in further confusion as Code apparently does not have a way to correctly set the environment for the git process, which then defaults to the wrong PATH:
git fetch
git show HEAD:.vscode/settings.json
git show HEAD:.vscode/settings.json
Could not create directory '/c/cygwin64/home/USERNAME/.ssh'.
ssh_askpass: exec(/usr/local/bin/win-ssh-askpass.exe): No such file or directory
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
git fetch
Could not create directory '/c/cygwin64/home/USERNAME/.ssh'.
ssh_askpass: exec(/usr/local/bin/win-ssh-askpass.exe): No such file or directory
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Trying to set PATH, HOME, etc. inline in the bash command line above fails for some reason I cannot yet fathom, but I would suggest a configuration setting git.env be created so that the environment external Git tools can be pre-configured (this would also benefit the Linux and OSX ports).
As to why this is necessary and why I can't use other Git binaries on Windows, the reason is simple:
Cygwin does Git over SSH "right", with completely identical setup in terms of SSH keys, options, CR/LF encoding, etc. Current Git for Windows simply does not work for my use case (I've tried), and, obviously, the Linux Subsystem doesn't help with this either.

Duplicate of #7361. We don't support cygwin git, sorry.
We've been using Git for Windows successfully in the team, complete with SSH keys, options, line ending encodings et al. What is the actual issue you get with it?

Hmmm. So this is a dupe of a ticket that's closed because we've "just never really looked into it"?

If #7361 were open we would close this one the same way. It is a duplicate, in any case.
Apologies for coming out harsh.
Let me expand a bit on just never really looked into it. Code already needs to support whichever version of git you have installed in whichever platform you are using it. It is a non-trivial task that gets another complexity fold as soon as we add git flavours. We've found that Git for Windows handles the great majority of the tasks users need and I've personally have yet to find a reason that would make me use cygwin instead.
Of course, I can be wrong and I'm definitely interested in someone proving me wrong. That's why I asked about the actual issue you face. If it is really something Git for Windows does not support, of course we'll reconsider our position towards cygwin, and we'll work towards that.

It's all about integration. When you use Cygwin and its userland (bash, CLI tools, SSH, etc.), you don't need an extra terminal emulator like PuTTY, you can use standard Git plugins that rely on Perl/Python etc. seamlessly, and you don't need to set up a copy of your SSH keys anyplace else.
Right now, the current (stunted and incomplete) UNIX userland clone that ships with Git for Windows doesn't provide me those affordances. Also, I can't set GIT_AUTHOR_* and GIT_COMMITTER_* on a per-repo basis using Git for Windows - it's just a surreal amount of pain to deal with that kind of thing inside it, when it all works perfectly in Cygwin.
With an environment setting I might not only actually get Cygwin Git to work (I suspect it's just a matter of setting the right HOME and a few more variables) but also have GIT_* settings set on a per-project basis for me inside VS Code. And this last bit will benefit every other platform, too.

Alright, let's keep this open for tracking the support. A PR would be much appreciated as we'll likely not have cycles to look into it any time soon.
Maybe next time I'm in the Lisbon office, I'll ping you and we'll get it working in an afternoon. :wink:

I created a symlink and it worked for me:
http://stackoverflow.com/questions/36508177/visual-studio-code-cannot-detect-cygwin-git-exe-path/37980938#37980938

@rcarmo Did you try this?

Not yet, kind of tied up with FY16 still. Will give it a go next weekend and see if it works on my box and a fresh install (never underestimate the power of upgrades where it regards breaking things).

On 04 Jul 2016, at 14:45 , João Moreno<EMAIL_ADDRESS>wrote:
@rcarmo https://github.com/rcarmo Did you try this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/7998#issuecomment-230294069, or mute the thread https://github.com/notifications/unsubscribe/AAX96yMsQpPeoo5orUAdryk1tJMc5ipXks5qSQ5ggaJpZM4I7sqV.

someone had a similar issue here too and it worked: https://github.com/Microsoft/vscode/issues/1982

I'm going to have a go at this (both reproducing and understanding exactly why the symlink works, and if it works with my git plugins) within the next few days and will report back.

On 08 Jul 2016, at 19:32, Bastien Calestroupat<EMAIL_ADDRESS>wrote:
someone had a similar issue here too and it worked: #1982
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Brief status update: I'm still having trouble with SSH/askpass at this point. Trying to debug.

@rcarmo Would Bash for WIndows be an option?

I've been using it alongside Cygwin, and the answer is no. Unless I go full X-Windows and run VS Code inside LXSS, I can't get the degree of integration I need (plus the LXSS console is still not as nice as mintty, but that's beside the point here)
I made some headway recently using a little executable shim to wrap Cygwin's git, but I'm still missing something regarding PATH and environment variables. I still think being able to set environment variables prior to Git execution is the way around this, but time hasn't been on my side recently.

Solution for me (Windows 10 - git from cygwin)
create dir - mkdir c:\cygdrive
open a cmd and goto  - cd c:\cygdrive
créate link to c:\ - mklink /j "c" c:\
and ready..

That doesn't work for me for some reason - I get errors trying to find my home directory for SSH keys (Cygwin apparently gets confused and does stuff like /c/cygwin64/home/username/.ssh

I had partial success today by setting a couple of links and tweaking environment variables and managed to have Cygwin git do local commits, but there were two issues:

the sync icon turned into a cloud+arrow icon (which means VSCode wasn't able to completely figure out the output from the Cygwin git binary). Pushing to the remote repo worked, but...
ssh-ask-pass did not work correctly, and did not respect the environment variables set by ssh-agent (so I got an SSH password prompt on every git operation)

The second point essentially circles back to one of my earlier points - without being able to set environment variables for git within VS Code, this will likely always be broken in some way -- some people might get it to work with passwordless keys, but it's not a definitive solution.
Also (and this is just an aside), getting this to partially work completely broke "regular" Windows Git (which uses a variant of Cygwin):
git pull
      0 [main] ssh 9472 C:\Program Files\Git\usr\bin\ssh.exe: *** fatal error - add_item ("\??\C:\Program Files\Git", "/", ...) failed, errno 1
Stack trace:
Frame        Function    Args
000FFFF9BB0<PHONE_NUMBER>E<PHONE_NUMBER>2, 00180224DD9, 000FFFF9BB0, 000FFFF8B30)
000FFFF9BB0<PHONE_NUMBER>9 (000FFFFABE0, 000FFFF9BB0, 1D21574853C4D14,<PHONE_NUMBER>0)
000FFFF9BB0  001800466A2 (000FFFF9BB0,<PHONE_NUMBER>1, 000FFFF9BB0, 505C3A435C3F3F5C)
000FFFF9BB0  001800DF22B<PHONE_NUMBER>0, 000FFFFCE00, 001800CEE68, 1D215748E2D2E24)

The cloud+arrow icon simply means the current branch you have checked out doesn't have an upstream branch configured. Once it does, it should show the sync icon. This must've been a coincidence that you checked out such a branch.
So... would it work if you set a few env variables for when Code calls git?

@joaomoreno: I believe so, yes. The experiment I did with an executable wrapper a while back was partially successful.
Maybe something like this would be feasible:
{
    "git.path": "..."
    "git.env": {
        "foo": "bar"
        ...
    }
}

And are the variables predictable for each system? Meaning, could it simply be a git.cygwin: true setting?

Nope, I have to set at least these for the SSH agent:
SSH_ASKPASS='C:\cygwin64\usr\local\bin\win-ssh-askpass.exe'
SSH_AUTH_SOCK=/tmp/ssh-59iOCz4fyxRZ/agent.12660

I can pin down SSH_AUTH_SOCK, but that's usually random, and I will need extra variables for some Git plugins and environments.

Also, regarding the cloud+arrow bit, there's definitely something amiss here. I've tried Windows Git and Cygwin git on the same repo, same branch, no changes, and gotten:

cloud+arrow for Cygwin git
sync wheel for Windows git

Might be a version issue (Cygwin git is 2.8.3)

Is there any plan to add cygwin support? It is the only thing missing to make VSC perfect. (IntelliJ has no issue with their git, and I dont like having git-bash just to make VSC work...)

Warning for those using the kluges in the comments here - I was able to work with VSC okay (seemingly), but when I added VS to the mix, it wanted to change all permissions in opened folder a+x, while VSC then wanted to change them all a-x, so both programs could not see a clean working tree at the same time. Was not able to diagnose the issue further but that was enough for me to say "OK I'll use what is officially supported".

FWIW, it now sort of works with git inside the Linux Subsystem (aka Bash for Windows), although I keep having trouble with SSH auth.

Still broken as of today, for cygwin and msys
The workaround is @Radon222 's answer. VSC is trying to read the repo path from \home (msys) or \cygdrive (cygwin) and obviously it does not exist in windows. It should be a simple path conversion?

Well, no, but “proper” use of Git in many situations requires SSH key auth, and I, for one, vastly prefer it to auth helpers and HTTPS.
(I’m still using the built-in terminal to run bash and commit via the CLI, but in WSL now.)

Sorry, guys, since this is just not a priority for us, I'm making the tough call to close this as out of scope, given that:

Git for Windows is supported
WSL support is tracked in #9502

For anyone that saw this thread doing a search on how to use Cygwin git and vscode, my solution was to install Git for Windows, and then use mklink to junction link the Cygwin .ssh directory to %USERNAME%/.ssh to share config and ssh key.  Then both git will have access to the same ssh key and ssh config for multiple key usage.

Hello All,
Linked below is a gist that wraps the Cygwin git.exe and converts the Linux paths which cause the error: "error while loading shared libraries: ?: cannot open shared object file: No such file or directory" to Windows paths using the cygpath executable.
https://gist.github.com/nickbudi/4b489f50086db805ea0f3864aa93a9f8

I think cyg-git might be able to solve the problem.  It provides a "Git for Windows" virtually.  You only need Cygwin and its packages.
https://github.com/nukata/cyg-git

My 2 cents on this (I know, closed and aging) issue: I have added one environmental variable to include my cygwin bin folder to Windows path, and the warning message was removed after restarting VSCode.

Anybody's up for writing a small patch that would call cygpath -alm on the results of a few calls VS Code makes to Git that produce a full path as the result?
It's not really a rocket science for somebody familiar with VS Code internals.

Anybody's up for writing a small patch that would call cygpath -alm on the results of a few calls VS Code makes to Git that produce a full path as the result?
It's not really a rocket science for somebody familiar with VS Code internals.

I believe this is not an issue with cygpath. cygpath can produce correct windows path.
My assumption is vscode is using the wrong root path while parsing. I might be wrong though, since I didn't check the source code.

This is an issue between VS Code (which relies on git itself too much) and Cygwin git (which uses Cygwin directory layout, which follows POSIX FHS).
To make VS Code understand Cygwin paths, it should either be told to expect them, or use cygpath to convert them to native form.

This is an issue between VS Code (which relies on git itself too much) and Cygwin git (which uses Cygwin directory layout, which follows POSIX FHS).
To make VS Code understand Cygwin paths, it should either be told to expect them, or use cygpath to convert them to native form.

You can create a wrapper for that in Windows batch file, which calls cygpath to output windows path, and VSCode does not have to understand cygwin path, but it still does not work perfectly. The initial Git init works, but the file listing and diff do not work.
I briefly checked the VSCode before. When calling Git, it does not always use absolute path returned from Git command. It parses URI with a root path returned from other function, which does not seem to work properly with non official git binary. You can check that if you like.

Unfortunately, VS Code tries hard to find specifically "git.EXE", even if told to use "git.sh" wrapper (which has appropriate shell association defined).
I've had a small success with "git.cmd" wrapped around "git.sh", trying that route now.

However, a more native approach would be preferred.
Cygwin, despite its interoperability issues on filesystem level, has way better integration with Windows itself. In fact, better to the level that WSL could never achieve. Ever. Due to its nature.

You can create a wrapper for that in Windows batch file, which calls cygpath to output windows path

Now, I recalled why did I switch from CMD to TakeCommand/Console.
Insane, unusable quoting rules of CMD, compounded by inability to control arbitrary number of batch file parameters in an efficient way, are basically a showstopper to any effective scripting.

Just adding myself here as another person who would really like to continue to use cygwin... + vscode.

Just tried the script from Cygwin Git + VS Code compatibility and it didn't work with the following error message in Git output:
> git ls-files --stage -- D:\Workspace\test\platformio.ini
fatal: D:\Workspace\test\platformio.ini: 'D:\Workspace\test\platformio.ini' is outside repository at '/cygdrive/d/Workspace/test'

@nukata
Many thanks for your contribution, it works. Just one minor remark: what about re-writing the script on bash? bash is for sure present on all installations and most are familiar with it. I am not sure if I did this rewriting correctly as I couldn't test the script thoroughly for the case when wrap_output=yes, but here it goes:
#!/bin/bash

wrap_output=""
argv=("$@")

for ((i = 0; i < $#; i++))
do
	arg="${argv[$i]}"
	if [ $i = 0 -a "$arg" = 'rev-parse' ]
	then
		wrap_output=yes
	elif [[ -n "$arg" && "$arg" != -* ]]
	then
		argv[i]=`cygpath -u "$arg"`
	fi
done

if [ $wrap_output ]
then
	if out=`git "${argv[@]}"`
	then
		if [ -n "$out" ]
		then
			if [[ $out = -* ]]
			then
				echo "$out"
			else
				cygpath -w "$out"
			fi
		fi
	else
		x=$?
		echo "$out"
		exit $x
	fi
else
	exec git "${argv[@]}"
fi

Just tried the script from Cygwin Git + VS Code compatibility and it didn't work with the following error message in Git output:
> git ls-files --stage -- D:\Workspace\test\platformio.ini
fatal: D:\Workspace\test\platformio.ini: 'D:\Workspace\test\platformio.ini' is outside repository at '/cygdrive/d/Workspace/test'

@nukata
Many thanks for your contribution, it works. Just one minor remark: what about re-writing the script on bash? bash is for sure present on all installations and most are familiar with it. I am not sure if I did this rewriting correctly as I couldn't test the script thoroughly for the case when wrap_output=yes, but here it goes:
#!/bin/bash

wrap_output=""
argv=("$@")

for ((i = 0; i < $#; i++))
do
	arg="${argv[$i]}"
	if [ $i = 0 -a "$arg" = 'rev-parse' ]
	then
		wrap_output=yes
	elif [[ -n "$arg" && "$arg" != -* ]]
	then
		argv[i]=`cygpath -u "$arg"`
	fi
done

if [ $wrap_output ]
then
	if out=`git "${argv[@]}"`
	then
		if [ -n "$out" ]
		then
			if [[ $out = -* ]]
			then
				echo "$out"
			else
				cygpath -w "$out"
			fi
		fi
	else
		x=$?
		echo "$out"
		exit $x
	fi
else
	exec git "${argv[@]}"
fi

@joaomoreno Clarification: if someone were to submit a PR to fix this, would it be rejected?
I'm asking because if you would conditionally accept it, technically, shouldn't this issue remain open?

But why is it complicated to have git integration with VSCode?
In my particular case, I don't think I have a problem with the path. It seems that VSCode can detect I have an installation of git and that's because I added to PATH my cygwin bin folder, and then I can execute git commands from CMD and PowerShell without issues.
However, the editor fails to track the repositories completely.

This is because git reporting paths unexpected to VS Code.
Plus it is reporting them inconsistently. Sometimes relative, sometimes absolute, from the same command.
This is not a simple issue, unfortunately.

// Native sandbox environment
if (typeof globals.vscode !== 'undefined' && typeof globals.vscode.process !== 'undefined') {
	const sandboxProcess: INodeProcess = globals.vscode.process;
	safeProcess = {
		get platform() { return sandboxProcess.platform; },
		get arch() { return sandboxProcess.arch; },
		get env() { return sandboxProcess.env; },
		cwd() { return sandboxProcess.cwd(); }
	};
}

I was wondering if an additional check can be made here so if sandboxProcess.platform is win32, then check for a Cygwin installation, this can be checked by executing the command,
cygcheck --version
Cygwin bin folder needs to be added to the Path variable. A user configuration variable can also do the work of checking whether VSCode should run natively or under a Cygwin session.
In that scenario sandboxProcess.platform should be linux and not win32, and I believe the compatibility for a real linux OS should work too.
Another option might be a container, but I have no experiencie with VScode containers or extensions, but the idea is there, to be implemented.

You can have multiple Cygwin environments installed on the same PC. And none of them in the $PATH.
I've long since abandoned the hope and installed Git-for-Windows (and told VS Code to use specifically that one).

I've been using this https://github.com/nukata/cyg-git with success.
On Sat, Apr 16, 2022 at 2:41 PM AnrDaemon @.***> wrote:

You can have multiple Cygwin environments installed on the same PC. And
none of them in the $PATH.
I've long since abandoned the hope and installed Git-for-Windows (and told
VS Code to use specifically that one).
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/7998#issuecomment-1100655030,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADM6ZK73Q6EIR2CQEYNIWVLVFKYPZANCNFSM4CHOZKKQ
.
You are receiving this because you commented.Message ID:
@.***>

as noted in #148720 i believe supporting the configured integrated terminal is the way to go. extensions like gitlense do this e.g.

This is not enough.
Cygwin paths are inherently different from Windows paths, and VS Code do not understand that distinction.

Vscode could have Git auto-detection for Windows from different sources:

Program Files\Git
Visual Studio Git
Cygwin git could be auto-detected by its exe file location

It may be hardcoded preference or highest version preferred.

Vscode could have Git auto-detection for Windows from different sources:

Program Files\Git
Visual Studio Git
Cygwin git could be auto-detected by its exe file location

It may be hardcoded preference or highest version preferred.

Yet again - this is not about git.exe location, it is about Cygwin paths support.

Yes, I got it @AnrDaemon
Could you try to run Cygwin's git from cmd by its Windows path, please?

Yes, you could. That's not the problem.
The problem starts when Cygwin Git return Cygwin paths which VS Code don't know how to interpret.
Or when VS Code provide Windows paths that means nothing to Cygwin Git.
It requires some extra care inside VS Code itself, and even then not fully fool proof, as other extensions may run Git directly by themselves.

@AnrDaemon Yep. it's not just the difference in slashes, absolute paths and cygwin start with /cygdrive/<drive letter> and in Windows, start with <drive letter>:\\. That last paragraph is especially tricky.
Here's my workaround, and I didn't come up with it on my own. In fact, I may be summarizing something already in this thread.

I added this line to settings.json:   "git.path": "C:\\cygwin64\\home\\<user>\\vscode_git_compatibility\\cygpath-git-vscode.bat",.

$ cat cygpath-git-vscode.bat:

@echo off

REM wrapper to convert linux paths to windows
REM so vscode git integration will work with cygwin
REM "git.path"="C:\\this\\file.bat" in settings.json

setlocal
set PATH=C:\cygwin64\bin;%PATH%

if "%1" equ "rev-parse" goto rev_parse
git %*
goto :eof
:rev_parse
for /f %%1 in ('git %*') do cygpath -w %%1

I don't know why, and I don't know if it's actually used, but I have another file in that same directory named cygpath-git-editor.sh. $ cat cygpath-git-editor.sh:
#!/bin/bash

# wrapper to convert linux paths to windows
# so vscode will work as a git editor with cygwin
# editor="/home/this/file.sh" in .gitconfig

# extract last argument (the file path)
for last; do true; done

# get all the initial command arguments
all="${@:1:$(($#-1))}"

# launch editor with windows path
code $all $(cygpath -w $last)

I'm kind of in a rush so I don't have the time to verify if these are the only steps, but it is what I currently use. I hope this can be of help to someone.

The workaround is to install Git-For-Windows in a separate directory and point VS Code to it.

The workaround is to install Git-For-Windows in a separate directory and point VS Code to it.

Are providing an alternative workaround or explaining mine?

Restating the obvious.

Restating the obvious.

Not obvious enough, it seems. It looks like you said this back in 2022, but I hadn't noticed until now.
If you use the git-for-windows work around, can you still use cygwin's git in the same project, or do they step on each other's toes? I use the git command line 95% of the time; I only need VS Code to understand enough to mark my files as modified.

I do.
Cygwin is my go-to *NIX tools, I only install native ports/equivalent tools when one of the following statements is true:

The application provides exclusively network functionality or otherwise not restricted by path mangling (webservers, tools that talk to STDIO exclusively). Native tools usually more performant because they are not using POSIX API conversion layer.
An external native application wants to pass paths to the tool, and I can not control what exactly is passed. (VS Code talking to Git, Subversion, Meld etc.)


Deserialize and serialize unknown fields

Source https://github.com/getsentry/sentry-dart/pull/426#pullrequestreview-660450058
the idea is that unknown fields in the protocol are always kept and not lost across ser/deser.
Example:
Dart SDK deserializes an envelope that contains a new field called newField.
Right now this field is ignored as its not mapped in the SentryEvent class.
The idea is to keep all these unknown fields in a data bag with the key name and key value.
When the Dart SDK serializes again the very same event, it reads this data bag and writes all those values back to the JSON with the original property name and value.

similar to https://github.com/getsentry/sentry-java/issues/1497


Offer a webservice for radar metadata & settings

Do we really need to build this? And if so, how do we keep it simple?
We only need this for 1) visualizations and 2) a web app to browse the data availability (#12). If we use a static file (see #4), we could just copy the file in those applications to have the necessary data. The usefulness of a webservice largely depends on the nature of the data: if static, it is less useful. If dynamic (e.g. because we include settings, see #7) it becomes more useful.

Nice to have, but currently not the core bottleneck. I see a relational database that can be queried  currently as the minimum requirement. Also, we can only proceed with open access bird products with permission from OPERA, which is pending

Will indeed be stored in DB and can thus be queried. We'll only provide derived products if there are apps/viz who need those.


(MODULES-8043) Update supported Puppet versions

Codecov Report

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

@@            Coverage Diff            @@
##             master      #17   +/-   ##
=========================================
  Coverage          ?   89.89%
=========================================
  Files             ?        6
  Lines             ?      188
  Branches          ?        0
=========================================
  Hits              ?      169
  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 b8438e8...60ef170. Read the comment docs.


01 array sorting

Description
Problem Solved
Please include the name of the problem solved
NOTE: only one pull request per problem is accepted.
Also, if a pull request solves multiple problems, only one of the solved problems will be add to the user points (and therefore the leaderboard)
Dependencies and Reason
List any dependencies that are required for this solution and the reason why you used these dependencies
List of Developers
This solution has been implemented by the following Developers:

@GithubProfileTag

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] My changes generate no new warnings
[ ] I have checked my code and corrected any misspellings

NOTE: the PR have to be labelled in-progress until the work is complete, the PR will be checked, reviewed and merged only after being labelled as complete

Dovrei aver risolto. Va bene così?
Il Mar 24 Ott 2023, 15:33 Lorenzo Verducci @.***> ha
scritto:

@.**** requested changes on this pull request.
Il titolo della PR è Array Sorting ma nel codice vedo un "print" ed un
"flow chart"
Inoltre per ogni problema ci vuole una pull request a parte dove il nome
del branch deve essere uguale al nome del problema
—
Reply to this email directly, view it on GitHub
https://github.com/hacktoberfest-unicam/awesome-hacktoberfest-beryllium-bear/pull/39#pullrequestreview-1694863048,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A4H2SFEU3J2DAFCXPCWHAUDYA67Q7AVCNFSM6AAAAAA6NSJT5CVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTMOJUHA3DGMBUHA
.
You are receiving this because you authored the thread.Message ID:
<hacktoberfest-unicam/awesome-hacktoberfest-beryllium-bear/pull/39/review/1694863048
@github.com>

--


Add multi-customer support with security

@noelo business value is understood on this one, but what are the progress and outstanding effort?

Working on this at the moment and it's getting close. There's probably 3
days of effort left but we need to have a chat about the usage implications
On Wed, Jun 6, 2018 at 9:08 PM texasbrok<EMAIL_ADDRESS>wrote:

@noelo https://github.com/noelo business value is understood on this
one, but what are the progress and outstanding effort?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/redhat-cop/pathfinder/issues/5#issuecomment-395197028,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAb_02nooRFyjJQXsdW1aU9VtBufilptks5t6DapgaJpZM4TGdEE
.


DOM.select() alternative

The DOM.select() method is using querySelectorAll() behind the scenes, which is an operation 99% slower than getElementsByClassName().
While querySelectorAll() offer a greater flexibility, by far the most times, I use a single class name as selector. In these cases, I would prefer that I could, through DOM, use getElementsByClassName(). I suggest that an additional method, perhaps DOM.selectByClassName(), be added to DOM.

Method
Ops/secchrome / firefox

querySelectorAll(`.some-class`)
~262,000 / ~103,000

getElementsByClassName(`some-class`)
~ 19,714,000 / ~ 975,392,000

Testing DOM selectors
Edits:

Add firefox perfomance results.
Add link to tests.

Great suggestion. This will be done, but we might need some bikeshedding on the name selectByClassName().

Actually, we could just leave out the extra method and instead do a simple regex to check if DOM.select() should use getElementsByClassName() when only a single class name was passed as selector.
const rSingleClassName = /^\.([^ ]*)$/;
const matches = rSingleClassName.exec(selector);
return (matches !== null) ? // single class name
  rootElem.getElementsByClassName(matches[0]) :
  rootElem.querySelectorAll(selector);

Above code should go here.

Speaking of performance, the code suggested above could be optimized.
return /^\.([^ ]*)$/.test(selector) ? // single class name
  rootElem.getElementsByClassName(selector.substring(1)) :
  rootElem.querySelectorAll(selector);

Another thing I just found out, getElementsByClassName(names)

names is a string representing the list of class names to match; class names are separated by whitespace

So it becomes somewhat more complicated.

Yes, this is just a simple performance optimization it seems:
return /^\.([^ ]*)$/.test(selector) ? // single class name
  rootElem.getElementsByClassName(selector.substring(1)) :
  rootElem.querySelectorAll(selector);

But have you checked that regex matching + getElementsByClassName is still faster than querySelectorAll?

Nope, not yet.

This might become too complicated, and I am probably just being too pedantic. Surely, I am not even sure this feature should be considered, unless it proves to actually be a bottleneck.

A more important performance bottleneck is the attachment/detachment of event handlers. Currently, on every virtual DOM patch we detach and re-attach all event handlers.

Have you opened an issue on that?

This https://github.com/cyclejs/cycle-dom/issues/11

Should we close this?

I think we should keep it open. After we get the performance benchmark around, we can toy around and figure out if this proposal speeds up something.

@TylorS Have you got any comments to add to this issue?

Hmm. I'm not sure this is quite as easy to implement nor as needed with event delegation in place.
Reason being .events() never uses querySelectorAll(). However .observable does, but I'm not sure if that's used nearly as often for anything other than testing?

So maybe it’s time to close it? @staltz ?

Yeah, we can reopen if it becomes relevant again.


versions order_by

When you retrieve versions from a paper trail object , it always order it by created_at ASC, id ASC , so you can't do something like:
widget.versions.order("created_at DESC").each do |w|
#whatever
end
and change the order

That's true.  However you can reverse the versions in Ruby:
widget.versions.reverse.each do |w|
  # whatever
end

Thanks, that was my solution too :)


[3460] api docs improvements

Context

https://trello.com/c/9vJWZOqy/3460-m-api-updates-before-apply-review-part-2

Changes proposed in this pull request
Guidance to review
Checklist

[ ] Make sure all information from the Trello card is in here
[ ] Attach to Trello card
[ ] Rebased master
[ ] Cleaned commit history
[ ] Tested by running locally

 [M] API Updates - Before Apply Review (part 2)

The missing documentation, I'm not sure what to add for them to be honest. For example id is exposed but is never used but is needed to meet the JSONAPI spec


[Features] - Integrate with arXiv Vanity and ar5iv

Is your feature request related to a problem? Please describe.
arXiv Vanity and ar5iv are alternative arXiv render that work pretty well. This could be pretty easy to add a settings to change the link in the extension to point out to these renderer instead of raw html.
Describe the solution you'd like
Add a settings to switch the Go To button to ar5iv or Vanity.
Additional context
Maybe I can have a look on this.
If you think it worth it you could assign me this issues

There's an option to add a link to SciRate but I can do something similar for vanity / ar5iv indeed. Thanks!

Yes, If you don't have enouth time you could assign it to me

Thank you for pitching in! My codebase is a bit messy so I'm not sure how easy it would be for you. I'll try to outline a plan so you can see how to start and if you think the amount of work (including the time it'll take you to understand the code base) is not reasonable I'll do it :)

Hey @julien-blanchon do you still want to try and get into this? I'm sorry I got busy and forgot to write a tutorial. If you still want to take the time to do this, I will help. Otherwise I can just do it

Yes you can assign it to me

It's done !
I've add some custom svg the tablerSvg but they are pretty ugly maybe stick with message is a better option

Github is down, I will make a PR from https://github.com/julien-blanchon/PaperMemory/tree/148_integrate_vanity_and_ar5iv when everthings when everything will be back to normal. Yarn test crash on my computer (I don't know why), but everythings seems okay except the SVGs


Similar list on github

Here is a similar list on github, but this community was easier to find via google search.
Maybe mix the two...
https://github.com/thisdot/tech-community-slacks

Yeah maybe we can link this GitHub in this one? tech-community-slacks looks very specific to Slack and not discord or others software


When waiting for transactions, always stop listening, there is no information displayed on the terminal, and it needs to be manually ended before running the node again

System:Ubuntu22.04(windows wsl)
Nodejs:18.16.0
When waiting for transactions, always stop listening, there is no information displayed on the terminal, and it needs to be manually ended before running the node again.

is this on a windows machine? never tested it on a windows machine before will have to try - so it just stops after a while ? I am not sure if this is windows stopping the CLI tool from fetching every x seconds


Delink license icons with license description

Fixes

Fixes #957 by @panchovm
Description
I disabled the link by adding new css class selector called disabled.
Checklist

[X] My pull request has a descriptive title (not a vague title like Update index.md).
[X] My pull request targets the master branch of the repository.
[X] My commit messages follow best practices.
[X] My code follows the established code style of the repository.
[X] I added tests for the changes I made (if applicable).
[X] I added or updated documentation (if applicable).
[X] I tried running the project locally and verified that there are no
visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

This was done in #989
Thanks for your contribution.


release 0.9.0

Ⅰ. Describe what this PR did
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #1776 into master will increase coverage by 3.37%.
The diff coverage is 50.75%.

@@             Coverage Diff              @@
##             master    #1776      +/-   ##
============================================
+ Coverage     47.18%   50.56%   +3.37%
- Complexity     1779     2166     +387
============================================
  Files           362      414      +52
  Lines         13237    14196     +959
  Branches       1641     1709      +68
============================================
+ Hits           6246     7178     +932
- Misses         6316     6328      +12
- Partials        675      690      +15

Impacted Files
Coverage Δ
Complexity Δ

...saga/statelang/parser/impl/FailEndStateParser.java
100% <ø> (ø)
2 <0> (?)

...ource/sql/druid/oracle/OracleInsertRecognizer.java
100% <ø> (+100%)
16 <0> (+16)
:arrow_up:

.../main/java/io/seata/core/protocol/MessageType.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...n/java/io/seata/server/lock/db/DataBaseLocker.java
24.13% <ø> (-6.3%)
5 <0> (ø)

.../saga/statelang/parser/impl/ChoiceStateParser.java
100% <ø> (ø)
3 <0> (?)

...n/java/io/seata/rm/datasource/ConnectionProxy.java
22.88% <ø> (ø)
10 <0> (ø)
:arrow_down:

.../seata/rm/datasource/sql/druid/BaseRecognizer.java
100% <ø> (+50%)
2 <0> (-1)
:arrow_down:

...tatelang/domain/impl/StateMachineInstanceImpl.java
0% <ø> (ø)
0 <0> (?)

...java/io/seata/server/lock/memory/MemoryLocker.java
87.2% <ø> (+1.33%)
20 <0> (ø)
:arrow_down:

...rm/datasource/sql/druid/MySQLInsertRecognizer.java
100% <ø> (+35%)
15 <0> (+8)
:arrow_up:

... and 195 more

Continue to review full report at Codecov.

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


AAAA queries sent to a 'v4' upstream

My ctrld is configured with one upstream provider only, pointing at Control D. However, this is set as a v4 upstream. According to the documentation, this means no v6 queries should ever be sent there. However, I am seeing AAAA queries in the Activity Log on the Control D dashboard. That seems a bug.

This is documented here: https://github.com/Control-D-Inc/ctrld/blob/main/docs/config.md#ip_stack

Pardon my ignorance, but thats what I mean by "set as v4" ... ip_stack = v4 ... so I would expect there to only be A record queries going to that destination.

Pardon my ignorance, but thats what I mean by "set as v4" ... ip_stack = v4 ... so I would expect there to only be A record queries going to that destination.

Nope, ip_stack = v4 means ctrld will connect to upstream server using ipv4 only, regardless of DNS record type.

Ah, ok. Understood. There is no way to avoid AAAA queries from being forwarded?

Ah, ok. Understood. There is no way to avoid AAAA queries from being forwarded?

At this moment, no.

Ok, understood.


Black execution fails (missing 'typing_extensions')

Trying to run v0.2.2 with
python_register_toolchains(
    name = "python3",
    python_version = "3.10",
)

fails with
Traceback (most recent call last):
  File "/home/ph03/.cache/bazel/_bazel_ph03/2db8cbce6fe365e36a9715d20aab49e9/execroot/dsai/bazel-out/k8-opt/bin/external/aspect_rules_format_pypi_black/rules_python_wheel_entry_point_black.runfiles/aspect_rules_format_pypi_black/rules_python_wheel_entry_point_black.py", line 3, in <module>
    from black import patched_main
  File "/home/ph03/.cache/bazel/_bazel_ph03/2db8cbce6fe365e36a9715d20aab49e9/execroot/dsai/bazel-out/k8-opt/bin/external/aspect_rules_format_pypi_black/rules_python_wheel_entry_point_black.runfiles/aspect_rules_format_pypi_black/site-packages/black/__init__.py", line 42, in <module>
    from black.nodes import STARS, syms, is_simple_decorator_expression
  File "/home/ph03/.cache/bazel/_bazel_ph03/2db8cbce6fe365e36a9715d20aab49e9/execroot/dsai/bazel-out/k8-opt/bin/external/aspect_rules_format_pypi_black/rules_python_wheel_entry_point_black.runfiles/aspect_rules_format_pypi_black/site-packages/black/nodes.py", line 24, in <module>
    from typing_extensions import TypeGuard
ModuleNotFoundError: No module named 'typing_extensions'
FAILED: A formatter tool exited with code 123
Try running 'bazel run @aspect_rules_format//format' to fix this.

while running with
python_register_toolchains(
    name = "python3",
    python_version = "3.10",
)

already fails at the configuration step with
INFO: Invocation ID: c11114e4-935a-4a07-b80a-3b9cddb4bf13
ERROR: /home/ph03/.cache/bazel/_bazel_ph03/2db8cbce6fe365e36a9715d20aab49e9/external/aspect_rules_format_pypi_black/BUILD.bazel:22:11: no such package '@aspect_rules_format_pypi_typing_extensions//': The repository '@aspect_rules_format_pypi_typing_extensions' could not be resolved: Repository '@aspect_rules_format_pypi_typing_extensions' is not defined and referenced by '@aspect_rules_format_pypi_black//:pkg'
ERROR: Analysis of target '@aspect_rules_format//format:format' failed; build aborted:

which looks like an inconsistency to me. Note that I have a python toolchain registered before, i.e.,
python_register_toolchains(
    name = "python39",
    # Available versions are listed in @rules_python//python:versions.bzl
    python_version = "3.9",
)

but that one is not picked up by bazel-super-formatter as it's expecting the python toolchain to be called python3 not python39 (could that be the source of the issue?)

Thanks for the issue. What version of rules_python is that running with?
You're right that python3 is hard-coded here https://github.com/aspect-build/bazel-super-formatter/blob/7803a5f2ee03966f7de6fc1d5bcbbc9f5dcd967f/format/dependencies.bzl#L2
could you try locally changing that to the one you intend, and confirm if it fixes the issue?

Thanks for the issue. What version of rules_python is that running with?

This is with rules_python-0.10.0 - I the original python_register_toolchains registration to also use python3 and with python_version = "3.9", it's still failing with
ERROR: /home/ph03/.cache/bazel/_bazel_janickm/2db8cbce6fe365e36a9715d20aab49e9/external/aspect_rules_format_pypi_black/BUILD.bazel:22:11: no such package '@aspect_rules_format_pypi_typing_extensions//': The repository '@aspect_rules_format_pypi_typing_extensions' could not be resolved: Repository '@aspect_rules_format_pypi_typing_extensions' is not defined and referenced by '@aspect_rules_format_pypi_black//:pkg'

To me it feels like the locked dependencies are evaluated for python3.10 (see This file is autogenerated by pip-compile with python 3.10 in https://github.com/aspect-build/bazel-super-formatter/blob/main/requirements_lock.txt), however, we are kind of locked into python3.9 and can't use python3.10 - is it perhaps possible to have different requirement files for each python version?

I hacked around this by patching the rules to use the version of black installed with our repository requirements file as a workaround. Obviously, not the best long term decision but we use the auto-detecting toolchain so needed the workaround:
WORKSPACE
http_archive(
    name = "aspect_rules_format",
    patch_args = ["-p1"],
    patches = [
        "//bazel/bazel-super-formatter:0001-use-autodetecting-python-toolchain.patch",
    ],
    sha256 = "3eaa9851e09e3d2813e6c4ac1b6153e64ee44b494fa4ddf36fff2ba8b105e8db",
    strip_prefix = "bazel-super-formatter-0.3.1",
    url = "https://github.com/aspect-build/bazel-super-formatter/archive/refs/tags/v0.3.1.tar.gz",
)

0001-use-autodetecting-python-toolchain.patch
diff --git a/format/BUILD.bazel b/format/BUILD.bazel
index 0e19609..8275d5c 100644
--- a/format/BUILD.bazel
+++ b/format/BUILD.bazel
@@ -1,7 +1,7 @@
 load("@bazel_skylib//:bzl_library.bzl", "bzl_library")
 load("@bazel_skylib//rules:common_settings.bzl", "bool_flag")
 load("@aspect_rules_format_npm//:prettier/package_json.bzl", prettier = "bin")
-load("@aspect_rules_format_pypi//:requirements.bzl", "entry_point")
+load("@pypi//:requirements.bzl", "entry_point")
 load(":langs.bzl", "LANGS")

 bzl_library(
diff --git a/format/dependencies.bzl b/format/dependencies.bzl
index e9ba437..1807e3a 100644
--- a/format/dependencies.bzl
+++ b/format/dependencies.bzl
@@ -1,5 +1,4 @@
 load("@aspect_rules_js//npm:npm_import.bzl", "npm_translate_lock")
-load("@python3//:defs.bzl", "interpreter")
 load("@rules_python//python:pip.bzl", "pip_parse")

 def parse_dependencies():
@@ -8,9 +7,3 @@ def parse_dependencies():
         link_workspace = "aspect_rules_format",
         pnpm_lock = "@aspect_rules_format//:pnpm-lock.yaml",
     )
-
-    pip_parse(
-        name = "aspect_rules_format_pypi",
-        python_interpreter_target = interpreter,
-        requirements_lock = "@aspect_rules_format//:requirements_lock.txt",
-    )
diff --git a/format/format.sh b/format/format.sh
index 60ee4bb..68fb340 100755
--- a/format/format.sh
+++ b/format/format.sh
@@ -96,7 +96,7 @@ if [ "$#" -eq 0 ]; then
 else
   files=$(find "$@" -name '*.py' -or -name '*.pyi')
 fi
-bin=$(rlocation aspect_rules_format_pypi_black/rules_python_wheel_entry_point_black)
+bin=$(rlocation pypi_black/rules_python_wheel_entry_point_black)
 if [ -n "$files" ] && [ -n "$bin" ]; then
   echo "Running black..."
   echo "$files" | tr \\n \\0 | xargs -0 $bin $blackmode
@@ -131,7 +131,7 @@ if [ -n "$files" ] && [ -n "$bin" ]; then
        echo "$NEED_FMT"
        exit 1
     fi
-  else
+  else
     echo "$files" | tr \\n \\0 | xargs -0 $bin $gofmtmode
   fi
 fi
diff --git a/format/toolchains.bzl b/format/toolchains.bzl
index e04b7c0..b7c6803 100644
--- a/format/toolchains.bzl
+++ b/format/toolchains.bzl
@@ -1,5 +1,4 @@
 load("@buildifier_prebuilt//:defs.bzl", "buildifier_prebuilt_register_toolchains")
-load("@aspect_rules_format_pypi//:requirements.bzl", "install_deps")
 load("@aspect_rules_format_npm//:repositories.bzl", "npm_repositories")
 load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains")

@@ -10,8 +9,5 @@ def format_register_toolchains():
     if "go_sdk" not in native.existing_rules():
         go_register_toolchains(version = "1.19.1")

-    # Initialize repositories for all packages in requirements_lock.txt.
-    install_deps()
-
     # Initialize repositories for all packages in pnpm-lock.yaml.
     npm_repositories()

I just did an overhaul of the python setup to make it optional, I think that also means you could install black yourself so long as it appears at @aspect_rules_format_pypi_black//:rules_python_wheel_entry_point_black

Confirmed that works. For those following along at home, you just need to do this:
pip_parse(
    name = "aspect_rules_format_pypi",
    requirements_lock = "//tools/black:requirements.txt",
)

load("@aspect_rules_format_pypi//:requirements.bzl", _aspect_rules_format_pypi_install_deps = "install_deps")

_aspect_rules_format_pypi_install_deps()

Thanks!