About highest frequency or wavelength of PSD curves

Usually, the highest frequency of a PSD curve follows N=2BL, where N is the total number of points, B is the bandwidth (highest frequency of one-side PSD curve), and L is the total length. In other words, according to this simple criterion, the maximum frequency in one-side PSD should be B = N/2L or half of the number density per length unit N/L.. In addition, the total number of the line profile N is the same as the final output number of PSD curve points, namely N(profile) = N(PSD curve points).
One of my line profiles has only 10 nm between two adjacent points. However, minmum wavelength or maximum frequency of the PSD curve computed from contact.engineering is about 0.1 nm. This is far beyond the resolution of my profile. In addition, the number of data points of my profile is just 300 or so, but the number of output PSD curve data point is over 4000. I see the algorithm. It seems there is a data extrapolation between adjacent points.
I did not understand the behind logics for this. Could anyone give an explantion in detail?

Fix: In addition, the total number of the line profile N is the same as the final output number of PSD curve points, namely N(profile) = N(PSD curve points) for double-side PSD or 0.5N(profile) = N(PSD curve points) for one-side PSD.

Re: AntoineSIMTEK
I plot 1D PSD of a single line profile and each datafile contains only one lineprofile.
For the second question, probably, I have a wrong understanding. It is more like my guess.
Thanks for your comment. If I understand correctly, this is due to the fact that the PSD online algrithm evaluates 2D radially averaged PSD curves based on the 1D line profile. Right? However, how to understand that maximum PSD frequency computed online is greater than my method based on the criterion mentioned in the question?

Ok then the function used to compute the PSD is powerspectrum_1D
It is computed by this function if the points are spaced uniformly:
https://github.com/ComputationalMechanics/SurfaceTopography/blob/378e7024fedec42ba610eb45ee7f14749d258202/SurfaceTopography/Uniform/PowerSpectrum.py#L39-L103
this returns a PSD on N/2 points spaced q vectors spaced by 2 pi / L , with L the physical size of your scan
so the highest wavector is pi N / L.
For nonuniformly spaced grid points it uses (with default arguments):
https://github.com/ComputationalMechanics/SurfaceTopography/blob/378e7024fedec42ba610eb45ee7f14749d258202/SurfaceTopography/Nonuniform/PowerSpectrum.py#L98-L173
In the nonuniform case it would be possible to have 4000 points in the PSD indead.
If your topography is considered as uniform then I don't understand what is going on.

My line profile has nonuniform data distribution. It seems that nonuniform case will output more data points in PSD curves and bigger maximum frequency. What is the behind reason for that?

There are two reasons: the maximum frequency present in your data is given by the smallest grid spacing.
Also, linear interpolation usually decreases the amplitude of the data if the grid spacing is too big.

Make sense. Thank you.

You are welcome. I am closing this issue now.

We discussed this in todays teleconference.
Using a spacing that is five times less then the smallest spacing produces a PSD that potentially reaches far beyond the actual resolution of the measurement. It is very likely to produce a q^-4 scaling regime that is not real.
We need to think about until which wavevector the PSD should be considered as reliable. The q^-4 scaling is not necessary a good indicator since it can be due to true facetting or kinks of the surface.

We discussed this in todays teleconference.
Using a spacing that is five times less then the smallest spacing produces a PSD that potentially reaches far beyond the actual resolution of the measurement. It is very likely to produce a q^-4 scaling regime that is not real.
We need to think about until which wavevector the PSD should be considered as reliable. The q^-4 scaling is not necessary a good indicator since it can be due to true facetting or kinks of the surface.

Thanks for this information. For q^-4 scaling, it appears usually in profiles by stylus profilometry and AFM due to the curvature of probe tip. For examples, if the probe goes through an infinitely sharp spike, the probe cannot resolve the shape of the spike but instead the inverse profile of the curved probe itself. Any high frequency component in PSD attributed to features approximately smaller than the probe tip size is regarded as artifact which mathematically appears q^-4 scaling in PSD for this reason. However, in this case, q^-4 scaling in PSD is due to artificially extrapolating data between two adjacent points or the resolution limit in profile. I did not quite understand this mechanism.

Thanks for this information. For q^-4 scaling, it appears usually in profiles by stylus profilometry and AFM due to the curvature of probe tip. For examples, if the probe goes through an infinitely sharp spike, the probe cannot resolve the shape of the spike but instead the inverse profile of the curved probe itself. Any high frequency component in PSD attributed to features approximately smaller than the probe tip size is regarded as artifact which mathematically appears q^-4 scaling in PSD for this reason. However, in this case, q^-4 scaling in PSD is due to artificially extrapolating data between two adjacent points or the resolution limit in profile. I did not quite understand this mechanism.

E.L. Church, P.Z. Takacs, Effects of the nonvanishing tip size in mechanical profile measurements, in: C.P. Grover (Ed.), Opt. Test. Metrol. III Recent Adv. Ind. Opt. Insp., 1991: pp. 504–514. https://doi.org/10.1117/12.51099
In the tip artifact, the q^-4 scaling is actually due to the kinks between the spherical cusps created by the tip convolution.

E.L. Church, P.Z. Takacs, Effects of the nonvanishing tip size in mechanical profile measurements, in: C.P. Grover (Ed.), Opt. Test. Metrol. III Recent Adv. Ind. Opt. Insp., 1991: pp. 504–514. https://doi.org/10.1117/12.51099
In the tip artifact, the q^-4 scaling is actually due to the kinks between the spherical cusps created by the tip convolution.

I just release SurfaceTopography 0.92.0 - if you just update the dependency to this release, this fixes this issue without further modification of TopoBank @mcrot

Okay, thanks!


open contextmenu where mouse is clicked for mat-menu

Actual Behavior:
position of menu is fixed irrespective of where mouse is clicked
Expected Behaviour:
Menu should be opened where the mouse is clicked
AngularJS Versions: *
AngularJS Version: Angular 4
AngularJS Material Version: 2.0.0-beta.12
Additional Information:
Browser Type: chrome, IE
OS:windows 7

Duplicate of #5007.
See this comment on how to implement a workaround.

Closing as a duplicate.


Getting Started Checklist: Set site/company name in header/footer checks are bogus

http://localhost:8080/admin/index.php?page=checklist&mc=getting_started

Both just search for a string in the respective header and footer templates. However, since this was written, that data was moved to the database.
Either completely remove the checks, or update the scripts that do the testing to look in the proper location.
src\admin\getting_started_checks\design_headerWebsiteName.php
src\admin\getting_started_checks\design_footerCompanyName.php

@vicos59 By the way, if you did not notice it yet:
Since you are in the tester group, I think you should be able to add labels now on issues / PR's.   AKA "triage" the issues.  If you so feel inclined.  That is assuming I got the permissions correct, so if it does not let you, report back so I can fix it if needed.

I was thinking it might be nice to have a tag to prioritize issues. I just did this for my personal project I imported to GitHub.
Be nice to know which ones are priority and need to be fixed before we can release the 1st production release. Some of these are not really showstoppers or even required for the 1st release.

Sounds like milestone is the winner. I need to be able to see what needs to be done to get v20.0 released so I can see where I can help and attack the highest priorities first. Without a goal, we will never get there.


Updates to .travis.sh to install docker-ce 17.06

I was able to get docker-ce 17.06 working in Travis with the following modifications.
I chose to add an additional environment variable to make it easy to switch between the correct package to install because I wanted to avoid having to check each version in the .trasvis.sh.

Codecov Report

Merging #853 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #853      +/-   ##
============================================
+ Coverage     66.39%   66.45%   +0.06%
- Complexity      742      744       +2
============================================
  Files           166      166
  Lines          3139     3139
  Branches        357      357
============================================
+ Hits           2084     2086       +2
  Misses          898      898
+ Partials        157      155       -2

@ssullivan Thanks so much.


Develop

By submitting this pull request, I confirm the following:
Please fill in any appropriate check-boxes, e.g: [X]

[X]   I have read and understood the contributors guide, as well as this entire template.
[X]   I have made only one major change in my proposed changes.
[X]   I have commented my proposed changes within the code.
[X]   I have tested my proposed changes, and have included unit tests where possible.
[X]   I am willing to help maintain this change if there are issues with it later.
[X]   I give this submission freely and claim no ownership.

What does this PR aim to accomplish?:
A detailed description, screenshots (if necessary), as well as links to any relevant GitHub issues
Eliminate the need/use of sudo.
How does this PR accomplish the above?:
A detailed description (such as a changelog) and screenshots (if necessary) of the implemented fix
Removing the root check and changing the temp dir.
What documentation changes (if any) are needed to support this PR?:
A detailed list of any necessary changes
Updated README.md to remove the use of sudo.

You must follow the template instructions. Failure to do so will result in your pull request being closed.
Please respect that Tronitor is developed by volunteers, IE: me, who can only reply in their spare time.

Codecov Report

Merging #42 into master will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #42   +/-   ##
=======================================
  Coverage   72.41%   72.41%
=======================================
  Files           1        1
  Lines         801      801
=======================================
  Hits          580      580
  Misses        221      221

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 c7546fe...8a4dae9. Read the comment docs.

Closing this as I have some changes to the travis testing I want to get merged in too.


added missing closing brace

makes copy-paste working again

Coverage remained the same at 82.042% when pulling a65f79625bc45d1da6dcc102b0d3ef87aa931fa9 on tobixx:fix-missing-brace into 5d1327db62306946e0b400e07d0b3e082a88f901 on rochacbruno:master.


TRON: wrong address, timestamp, and missing block returned

https://blockatlas.trustwalletapp.com/v1/tron/TKLnCNY5EsLNCvCXQTCn1dtqvc6vHhJUyJ
TODO:

[x] Fix timestamp:<PHONE_NUMBER>872 / 1000
[ ] Missing block property in response
[x] from and to must be Tron address, not hex
[ ] Add test covers check for mentioned issues above

@kolya182 The Tron response doesn't return the block height

@kolya182 The Tron response doesn't return the block height

Use default block as 0, client actually don't need it. But make a note for future fix, to keep api consistent.

// Height of the block the transaction was included in
Block uint64 `json:"block,omitempty"`

I deliberately made the block parameter optional because I felt not including it when unknown is more correct than setting it to some value. Same thing with the sequence field.
But no more omitempty, noted. Let's specify 0 as the value for unknown height then.

@terorie that looks good! if omitted, iOS/Android client will default to 0
@madcake


Log4j RollingFileAppender performance sometimes be the bottlenecks for high qps of fe thrift server

many threads of thrift server stuck like following:

@caiconghui
Dit you try to log asynchronously？

@caiconghui
Dit you try to log asynchronously？

This is a solution, but there are still some risk to lost log data for this solution. In my option, the log level should be changed from info to debug in some class such as  FrontendServiceImpl, which process event may be in high qps. and only when we want to trace problem should we log data again. many useless log cause the log file huge at the same time.

https://logging.apache.org/log4j/2.x/manual/async.html  another solution is https://logging.apache.org/log4j/2.x/manual/async.html


Add contact us below services.

💥 Proposal
Add the contact us section (form) below the services section.
The section should match the theme of our website i.e. black and white.
Form Fields

Full Name
Email Address
Message

Hii @rockingrohit9639, I would like to work on this issue.

Hii @rockingrohit9639, I would like to work on this issue.

Ok @pranabprohit bro, You can work on it.
You are given 4 days to complete it.


Getting "No GUI Implemented" on all instances/uses in 2020.1.3f1

Hey there,
Ths seems like an awesome package and I thank you much for sharing it. I am having a bit of issue though in Unity 2020.1.3f1. All of the samples and any instances of me trying to use any of the functionality of the package just end up producing the following:

Thanks,
-MH

Hey there again. I imagine you are busy, but it would be a real shame to let this package fall into oblivion. It has some pretty awesome stuff in it, and would be extremely useful! I do hope you one day find some time to get the 2020.1 bugs worked out. 👍


Update light_HassLightSet.yaml

This PR as well as the #545 cannot be approved in the current phase as we have to follow the official guidelines. That is, any sentence with its respective test have to be committed into a single PR. In that way, we can see if the tests pass.


WIP, waiting on issue #1043

✨ Codu Pull Request 💻
Fixes #(issue)

Pull Request details

INFO ABOUT YOUR PULL REQUEST GOES HERE (Please be as descriptive as possible) 🤜
Use bullet points to make it easy to read.

 ( Welcome file extensions include gifs/png screenshots of your feature in action )
IF YOU HAVE NO SCREENSHOTS, ENTER 'None'

Hi guys, I've finished the README.md


CVE-2021-3449 (OpenSSL) in Rancher Agent image v2.6.9 and v2.7.0

Describe the bug
The OpenSSL version that is included in the rancher agent image has CVE-2021-3449 and should be upgraded to at least 1.1.1k.

This also has a vulnerable version of bash CVE-2019-18276


Quicklook plugin causes runaway bash processes on High Sierra

On a regular basis, the CPU activity on my MacBook Pro would spike up, and there would be around 10 bash processes listed in activity monitor, with some of them using up to 100% of CPU resources. Using  ps -p <pid> I could finally trace the source of this, and it seems to be the ipaHelper Quicklook plugin. This is in combination with the quicklook not actually displaying someting for IPA files.
I have now uninstalled the ipaHelper files and used killall bash to get rid of the processes, and my CPU usage has gone right down.
I'm writing this less as a bug report but more as an information for other users that might be affected by high CPU usage bash processes. I'm on macOS 10.13.1 High Sierra.

I also encountered the same situation that often occupied the CPU, and I found that the files on my computer were copied, and I found it was ipahelper in copy some works to his folder, and do not know when to start copy, do not know what is doing

me too

On a regular basis, the CPU activity on my MacBook Pro would spike up, and there would be around 10 bash processes listed in activity monitor, with some of them using up to 100% of CPU resources. Using ps -p <pid> I could finally trace the source of this, and it seems to be the ipaHelper Quicklook plugin. This is in combination with the quicklook not actually displaying someting for IPA files.
I have now uninstalled the ipaHelper files and used killall bash to get rid of the processes, and my CPU usage has gone right down.
I'm writing this less as a bug report but more as an information for other users that might be affected by high CPU usage bash processes. I'm on macOS 10.13.1 High Sierra.

建议删掉

On a regular basis, the CPU activity on my MacBook Pro would spike up, and there would be around 10 bash processes listed in activity monitor, with some of them using up to 100% of CPU resources. Using ps -p <pid> I could finally trace the source of this, and it seems to be the ipaHelper Quicklook plugin. This is in combination with the quicklook not actually displaying someting for IPA files.
I have now uninstalled the ipaHelper files and used killall bash to get rid of the processes, and my CPU usage has gone right down.
I'm writing this less as a bug report but more as an information for other users that might be affected by high CPU usage bash processes. I'm on macOS 10.13.1 High Sierra.

建议去到~/Library/Quicklook/删掉插件, 这个插件并不好用,此bug并没有修复


extract environment initialization

This PR introduces the extraction of the training environment initialization, as it is utilized across the project. I have also added a graph caching feature, which is exceptionally helpful during the hyperparameters tuning stage. Here are the numbers (tested on SDv2.1):

Device
Environment
First epoch time without caching
With caching

910
MS2.1
15+ minutes
4~ minutes

910*
MS2.2.1
17+ minutes
5+ minutes

@HaoyangLee the graph cache is fixed now?

@HaoyangLee the graph cache is fixed now?

Haven't use that feature for a while. Not sure about it in the latest MS version. @hadipash 's testing result looks nice.


tsdb: Investigate chunk compression.

https://groups.google.com/forum/#!msg/prometheus-users/I7uneXEisV0/_BIMTqpWAAAJ
The thread suggests that even a single chunk can be compressed by more than 50% so worth investigating.

This was discussed at the dev summit, see notes, search for the (slightly misleading) "Additional gorilla optimizations".
Both major Cortex providers (Weaveworks and Grafana Labs) saw a ~30% blowup when moving from Prom v1 chunks to Prom v2 chunks. (Cortex can treat all chunk types in parallel for backwards compatibility. It then sees the raw data, without the indexing, as the different indexing strategies create additional differences in data size, see above.) That's quite good evidence that the v1 "tricks" were actually good for something, and aligns quite well with the snappy compressability of v2 chunks seen above (i.e. we would perhaps get half of the benefit of "real" compression from the added encoding tricks).
(Possibly, we will get even more, as the Prom v1 chunks should suffer from being only partially filled during series churn, and they still give us 30% better compression. Thus, Prom v2 chunks with added encoding tricks might give us the best of both worlds.)
I'll re-enumerate the "tricks" coming to my mind again, with a few extra caveats I stumbled upon:

If timestamps are perfectly regular, the double delta will be always 0. In this case, instead of storing a single zero bit per timestamp, we can do run-length encoding and just say "147 times zero".
If sample values are effectively integers, we can switch from XOR encoding to the same double-delta encoding as for timestamps. However, with Prom v2 we got staleness markers, which will never be integers. It might be worthwhile to have a separate way of saving the staleness marker. It occurs rarely and could become some kind of "chunk metadata".
If sample values never change, or they are effectively integers and have a perfectly regular growth (resulting in double-deltas being 0), we can do run-length encoding again, as described above. In case of a plainly constant value (e.g. an info metric with value 1), we would not say "double-delta is 147 times zero" but simplify to "value is 147 times 1" or even "value is always 1" as the counts are already in the timestamp. However, in contrast to timestamps, the sample value can also be a staleness marker, which should be stored separately to not break the regularity whenever a series ends.
Noisy values can result in more than 8 bytes needed per sample value. Compression is counterproductive then, and we should then switch to plainly saving the 8 bytes of float64 .

The plan is that all of these tricks are tried during compaction, when we have a view of the total data. (Prom v1 was guessing during initial ingestion, re-encoding when the guess turned out to be wrong. Again, with the Prom v2 standard encoding for the first block and then "intelligently" picking an encoding, we can get the best of both worlds.)
I'm not sure how well different chunk sizes would work, but IIUC, they are in principle possible. So we could create "jumbo chunks" where it makes sense. For example, a constant info-type series with perfectly even timestamps could be represented as a single tiny chunk spanning the whole block, just saying "start at timestamp x, step size y seconds, value always 1, for the whole block duration".  Start a new chunk at the switch to get two chunks with constant value.
That's all my brainstorming for now.

the staleness marker. It occurs rarely and could become some kind of "chunk metadata".

In principle, however flaky targets will have them a lot as will certain (in principle rare) recording rules. Falling back to existing compression methods is likely find then though.

Yeah, sure, whatever compresses best in that case. Mostly flagged it so that we can still encode a week-long constant time series as such, even if it ends with a single staleness marker.

Merging chunks on compaction was also touched during DevSummit and might be relevant to here: https://github.com/prometheus/prometheus/issues/6332

FYI, all the RLE-based tricks should be already handled by general-purpose compression algorithm such as zstd as mentioned in this article. Additionally to RLE-based tricks it can compress well other low-entropy data, which is quite common after applying delta-coding to real-world time series.

The problem with usual compression algorithms is that you have to decompress the data into a separate buffer in memory.
A bit of Prometheus history, also explaining the confusing version schemes that people might encounter when talking about Prometheus storage: Early prototypes of Prometheus (way before 1.x) had a leveldb-based data storage (with snappy-based compression for the data on disk). This storage is sometimes called v1 of the storage (although it was never a part of Prometheus v1.x) The v1 storage ran into the problem as mentioned above: Decompressing data into a separate buffer in RAM did not only mean that at least at some time, some blocks of the uncompressed data had to be represented in RAM, it also meant that effectively, it was effectively twice in RAM because the compressed version of the data was sitting in the page cache. The breakthrough happened when we "discovered" compressed in-memory representation that could be accessed directly, materializing the individual floating point numbers only as needed by the query engine. That was called v2 of the storage and made it into the Prometheus 1.0 release. At the same time, Facebook developed Gorilla internally, for a different detailed reason, but with the same need of having compressed accessible in-RAM representation. It was quite intriguing when they published the paper and we realized that we had independently developed something quite similar. Our storage v2 was faster, but compressed 2–3x worse. I thought that we could easily incorporate the more aggressive compression schemes of Gorilla into our storage, which lead to a "chunk version v2", which could be optionally enabled (they needed more CPU and were slower, but compressed even better than Gorilla). So now we had storage v2 with chunk version 2, but everything still in Prometheus 1.x. The reason why we could compress better than Gorilla, despite more noisy millisecond resolution in contrast to Gorilla's second resolution, were (presumably) all the encoding tricks I listed above. That state of the art is represented in this classical talk at PromCon 2016.
Then Prometheus 2.0 got released, with an again totally rewritten storage engine (sometimes called storage v3). This engine made almost everything better, in some dimensions by more than two orders of magnitude. There were fundamentally better approaches to organize the storage as a whole (finally allowing native mmap'ing in contrast to our homegrown silly version in storage v2) and a whole new approach to ingestion and indexing. But for the raw time series data compression, the storage went back to almost vanilla Gorilla encoding. As described above, it still often had better disk usage behavior, presumably because of the better indexing and not being vulnerable to half-filled fixed-size chunks when facing series churn. The PromCon talk to watch about storage v3 is this one.
While of course old assumption may be disproven at some time, I recommend at this time to investigate the "tricks" I listed above rather than going back to square one and trying out conventional compression algorithms again. The latter would go against the whole mmap'ing approach and probably require a more fundamental redesign. The trade-offs are certainly different for a distributed solution. But Prometheus is optimized to get the most out of the RAM and the local disk of one machine that is managing ingestion, querying, and storage altogether.

For reference: The code comments in https://github.com/prometheus/prometheus/blob/release-1.8/storage/local/chunk/varbit.go are a quite detailed documentation of the Prom1 varbit implementation and all the tricks listed above.
Another point I stumbled upon: The bit buckets used to save the double-deltas (ΔΔ). Gorilla and Prometheus 2 use it only for timestamps and have optimized their bit bucketing schema for that. There is always a single 0 bit used to save a ΔΔ of zero. Then there are two to four marker bits for other bit lengths. Those are 7,9,12,32 for Gorilla and 14,17,20,64 for Prometheus 2. The former is reportedly optimized for the observed timestamp distribution in the Facebook production environment. The different bucketing in Prometheus 2 is based on Prometheus using millisecond precision while Gorilla only uses second precision. Even with millisecond precision, most ΔΔ are still 0 for timestamps. I'm still a bit surprised about the high bit lengths for the other buckets (and how 64bits are even needed). Prometheus 1 picked its own schema, and since it also used ΔΔ encoding for values that are effectively integers, it uses different schemas for timestamps and values: 6,17,23 for timestamps and 6,13,20,33 for values. However, those schemas were picked more or less ad hoc back then, without much data research.
On a local test server, I see about 90% of the ΔΔ for timestamps being 0. (That might be lower on a production server under heavy load as more jitter may happen during scraping.) Most of the remaining 10% have values between -15 and 16, so they would fit into 5 bits. If they are outside of that interval, they are usually in the 10k, presumably left out scrapes and such, but that's very rare.
 But it seems likely that a smaller bit length in the first bucket (6 bit like in Prometheus 1 or even 5 bit) will reduce lightly jittered timestamps from taking 16 bit (14+2) to 7 bit (5+2) each. Also, the run-length encoding for consecutive 0 timestamps as used in Prometheus 1 (a 0 bit was not representing a single ΔΔ of 0, but signaled a 7bit counter to follow for number of consecutive zeros, i.e. a single ΔΔ of 0 was more expensive to encode, but the usual case of a bunch of zeros was more efficient – also, everything is byte aligned then, but I'm not sure about the resulting performance gain). With about 10 consecutive zeros on average, there is not much gain, but let's assume a perfect un-jittered scrape pattern for all the 120 samples of a Prometheus 2 chunk, that's 8bit rather than 120bit. Then let's assume adaptive encoding, which would pick the "zero" or "constant" encoding for constant values (like an info time series). Those series would take only 6.7% of the space as now in Prometheus 2. And chunks with more than 120 samples could be explored, too.

@krasi-georgiev why did you close this? It contains a lot of meat still to explore.

Reopening for now, to not lose track, and assigning to myself.

Hey, I just wanted to give an update on what I've been hacking on the side:
During the storage working group, we came up with the idea of creating a promtool subcommand that can analyze a block or a directory with blocks and report how many chunks would actually benefit from another chunk compression (double delta or run-length encoding).
For now, the goal is to figure out how much of a difference these encodings on existing blocks would have.
Once we have some numbers, I would like to update an already started design doc.

Is there a design doc started already? Perhaps there was a misunderstanding when I said that this issue has evolved into the beginnings of a design doc (and should eventually be converted into a real design doc).

There was a small proposal started once in https://github.com/prometheus/prometheus/issues/5865#issuecomment-511427879 which we can improve upon, but that's it as far as I can see.

Hey, I've posted a PR with two new chunk encodings and a CLI command for promtool to analyze existing blocks in #10275.
It would be great if you could run these analysis in your environments and report back some of the stats out of that.

Update: We are interested in having new encodings in TSDB, starting with Run Length Encoding.

Another thing to try after RLE would be considering values as integers where applicable (@colega's suggestion) and using other compression techniques that work better on integers than XOR.

and just FTR: https://github.com/prometheus/prometheus/issues/5865#issuecomment-559506773 mentioned that approach already further up.

Yup oversight on my part.

There is still a lot to explore here.

Did anyone investigate changing the bit-length buckets as described at https://github.com/prometheus/prometheus/issues/5865#issuecomment-616641709?
A new chunk encoding would not be backwards-compatible, but could be introduced as a feature-flag without a major version, right?

We have versioning for chunk encoding, don't we? We can always introduce new encodings in any case (like for native histograms) without a major version bump. However, you cannot roll back and read a new storage with an old Prometheus then, but that's well known.
The bit bucketing used for the double-delta encoding in native histograms is based on distribution of real-world data (but for samples, not for timestamps). In any case, I'm pretty sure we should have smaller bit buckets initially for timestamps, as discussed above.


Refactor scissors

Changes:
* Create a tree of all available components, then filter the ones
actually needed.
* Refactor ExtendedComponent complex areas.
* appendComponents() and divideByLines() now append to a
mutable array which leads to performance increase.

This may need to be rebased as inheriting from the previous PR

Current coverage is 0.00%

Merging #27 into master will decrease coverage by -94.38% as of b62d86c

No diff could be generated. No reports for #27 found.
Review entire Coverage Diff as of b62d86c

Powered by Codecov. Updated on successful CI builds.

By refactoring things, you've introduced a couple of quality warnings. Please come with a creative solution to get rid of them, so that this patch could be merged in master. :wink:

Finished review.

Performed all changes, made it great! Ready to be looked at!

Nice. Thank you! :wink:


Windows App certification kit report an error for React-native-webview packages

Bug description:

I try to build a react native app for the Windows UWP app. After building the app when I run the app with the windows app certification kit, it reports an error (supported API error for Microsoft webview2).  I tried several solutions (ex: downgrading Microsoft webview2 to 2.7.1 & 2.7.0, using different windows 11 sdk 22000 and so on), but can not fix the problem. Without passing the windows app certification, I can not submit the app in windows app store.
To Reproduce:

git clone https://github.com/hrdipto/react-native-app
cd react-native-app
yarn install
npx react-native-windows-init --overwrite
load the windows/temp.sln file in visual studio
double click on temp/Package.appxmanifest and edit it help
right-click on temp folder > publish > create app packages
after creating the package windows app certification kit open to testing your app
in the error report you will see the error

Expected behavior:

The UWP app should pass windows app certification kit.
Screenshots/Videos:

This error occurred when I build the app with the visual studio default configuration. Click Here to see the error.
This error occurred when I upgrade windows 11 sdk 22000. click here to see the error.

Environment:

OS: Windows 10
OS version: 10
react-native version: 0.68.2
react-native-webview version: ^11.22.3
windows 11 sdk 22000
windows 10 sdk

Duplicate of #2553


[stable/efs-provisioner] Default storage class to aws-efs

The current value for the efs-provisioner storage class is efs, which
differs from the default value in
https://github.com/kubernetes-incubator/external-storage/tree/master/aws/efs
and also in the AWS example page at
https://aws.amazon.com/premiumsupport/knowledge-center/eks-pods-efs/
This can be confusing when running examples and (automated) tests, so
I'm changing the value to "aws-efs" in the chart to be consistent with the references
in the storage provider and on the AWS example page.
Signed-off-by: Mariyan Dimitrov<EMAIL_ADDRESS>@whereisaaron @mariusv
What this PR does / why we need it:
This PR is for consistent naming of the default storage class.
Checklist

[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

@merkata you'll need to bump the chart version too so the test will pass

/lgtm


Theme: default value for icon theme is "null"

Maybe related?
[15654:0219/081155:INFO:CONSOLE(231)] "Cannot read property 'startsWith' of null: TypeError: Cannot read property 'startsWith' of null
    at SettingsDocument.provideLanguageOverridesCompletionItems (/Users/bpasero/Development/Microsoft/monaco/extensions/configuration-editing/out/settingsDocumentHelper.js:146:95)
    at SettingsDocument.provideCompletionItems (/Users/bpasero/Development/Microsoft/monaco/extensions/configuration-editing/out/settingsDocumentHelper.js:29:21)
    at Object.provideCompletionItems (/Users/bpasero/Development/Microsoft/monaco/extensions/configuration-editing/out/extension.js:43:76)
    at /Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/api/node/extHostLanguageFeatures.js:379:85
    at /Users/bpasero/Development/Microsoft/monaco/out/vs/base/common/async.js:27:24
    at new Promise_ctor (/Users/bpasero/Development/Microsoft/monaco/out/vs/base/common/winjs.base.raw.js:1641:17)
    at Object.asWinJsPromise (/Users/bpasero/Development/Microsoft/monaco/out/vs/base/common/async.js:26:16)
    at SuggestAdapter.provideCompletionItems (/Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/api/node/extHostLanguageFeatures.js:379:28)
    at /Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/api/node/extHostLanguageFeatures.js:726:98
    at ExtHostLanguageFeatures._withAdapter (/Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/api/node/extHostLanguageFeatures.js:567:20)", source: file:////Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/electron-browser/shell.js (231)

That's correct, by default the icon theme is null, which means no icons.
The error in provideLanguageOverridesCompletionItems is not related. @sandy081 worked on that.

I find it weird that such a technical term leaks into user experience. I am not aware of any other setting that has null as default value.

There are 11 other settings that do that. Check out the default settings.
It's just one of the JSON types. undefined however is not valid JSON.
Alternative is the empty string or a name like 'No Icons'


Selected directory not shown in Table View

Description
Top level directory is not shown on the Table View when selected in the Tree View
Actual behavior
Sub-directories are listed in the Table View, but not the currently selected directory.
Reproduces how often:
Always
System configuration
Operating System:
All
AboutCode Manager Version:
v 2.4.1
ScanCode Toolkit Version:
v 2.2.1
See image for reference:

@mjherzog After further investigation, it looks like this issue only occurs when the directory selected is the root directory of the scan.
Ive tested this on multiple past versions of ABCM, so I believe this behavior has always been the case.
Let me know if you can reproduce this issue on a directory that is not at the root of the scan.

@mjherzog This is actually fixed as of the current development version. It was addressed some time during #168.
FWIW, I did test this against the files you mentioned in Slack and encountered that behavior while using the latest release.
v 2.4.1 will have this fixed when it is released. Closing this for now.


drivers: Modified drivers to use DEVICE_AND_API_INIT()

Modified drivers to use DEVICE_AND_API_INIT() instead of DEVICE_INIT()
This will make sure driver_api, is populated at build time and is exposed
to user space
Signed-off-by: Varun Sharma<EMAIL_ADDRESS>

Codecov Report

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

@@            Coverage Diff            @@
##             master   #11984   +/-   ##
=========================================
  Coverage          ?   48.13%
=========================================
  Files             ?      281
  Lines             ?    43425
  Branches          ?    10406
=========================================
  Hits              ?    20902
  Misses            ?    18368
  Partials          ?     4155

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 ee0b61f...6170ea5. Read the comment docs.

as such remove DEVICE_INIT from device.h and update the documentation accordingly.

This is a public API and will need to go through the deprecation process if we want to completely remove it.
You can tag it with DEPRECATED_MACRO and remove in two releases.

as such remove DEVICE_INIT from device.h and update the documentation accordingly.

This is a public API and will need to go through the deprecation process if we want to completely remove it.
You can tag it with DEPRECATED_MACRO and remove in two releases.

@andrewboie : DEVICE_INIT() is still being used in other places except drivers, like  in
SYS_INIT() defined in  include/init.h: SYS_INIT() and used at multiple places
&  in files: include/drivers/gpio/gpio_mmio32.h, boards/arm/nrf52_pca20020/board.c
Adding __DEPRECATED_MACRO triggers -werror & sanity check to fail, due to above usage's
So i have modified above usages to DEVICE_AND_API_INIT() also, please check.

as such remove DEVICE_INIT from device.h and update the documentation accordingly.

This is a public API and will need to go through the deprecation process if we want to completely remove it.
You can tag it with DEPRECATED_MACRO and remove in two releases.

@vanwinkeljan Done, pls check

OK, I get it. But... I dunno, my -1 remains mild, but if anything it's even stronger than before.
The only reason to deprecate DEIVCE_INIT() is because it does not set an API pointer and thus the resulting objects can't be discriminated by syscalls.   So old code that would have a NULL in that field now gets a warning.
Using the new style API but leaving a NULL in that field, as this patch does, now leaves the existing code  using the API incorrectly BUT NOT issuing a warning to get them fixed.  Either port the drivers to use a proper API struct or leave them in place with the deprecated API so that someone will find and fix it later.  All this does is hide the problem we're trying to fix.

OK, I get it. But... I dunno, my -1 remains mild, but if anything it's even stronger than before.
The only reason to deprecate DEIVCE_INIT() is because it does not set an API pointer and thus the resulting objects can't be discriminated by syscalls. So old code that would have a NULL in that field now gets a warning.
Using the new style API but leaving a NULL in that field, as this patch does, now leaves the existing code using the API incorrectly BUT NOT issuing a warning to get them fixed. Either port the drivers to use a proper API struct or leave them in place with the deprecated API so that someone will find and fix it later. All this does is hide the problem we're trying to fix.

@andyross : i understand your point, but if you see changes in boards/* & samples/, tests/ , thes drivers are not having  driver_api as they don't need them,  so i don't want to tinker with them , which will be beyond scope of this and should be done by individual owners if required.
Additionally , if we  set __DEPRECATE_MACRO for DEVICE_INIT() &  keep both DEVICE_INIT & DEVICE_AND_API_INIT in code ,  our sanity uses -Wno-deprecated-declarations and returns error instead of warning if DEVICE_INIT() is used.
So all usages should move to DEVICE_AND_API_INIT, if we want to deprecate DEVICE_INIT or we shouldn't add deprecate tag to DEVICE_INIT as of now.
API field is optional in DEVICE_AND_API_INIT() also & some drivers are  setting api as NULL, as they don't need driver_api as shared above, if we want to enforce driver_api to be set in DEVICE_AND_API_INIT()  then it should return error or warning if api is NULL.
As per current implementation  DEVICE_AND_API_INIT () does not give any warning if driver_api is NULL while device_get_binding.
https://github.com/zephyrproject-rtos/zephyr/blob/master/kernel/device.c#L85
@andyross Adding a warning message here, will resolve your concern?
@andrewboie @vanwinkeljan : your opinion...

OK, I'm firming up here.  If our own source code is not ready to adhere to the requirements of the new API, we should not be deprecating the old one yet.

API field is optional in DEVICE_AND_API_INIT()

Then why deprecate DEVICE_INIT() at all, if it's a legal and convenient shorthand for filling in a default value in an optional field?

@varun-sha No problem in keeping DEVICE_INIT, initially I thought it was the intention to deprecate this macro.

@andyross : address your review comment, please check


[SPARK-33390][SQL] Make Literal support char array

What changes were proposed in this pull request?

Make Literal support char array.
Why are the changes needed?

We always use Literal() to create foldable value, and char[] is a usual data type. We can make it easy that support create String Literal with char[].
Does this PR introduce any user-facing change?

Yes, user can call Literal() with char[].
How was this patch tested?

Add test.

Test build #130774 has started for PR 30295 at commit d3f1598.

Test build #130774 has finished for PR 30295 at commit d3f1598.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/130774/
Test FAILed.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35383/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35383/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/35383/
Test PASSed.

retest this please

Test build #130792 has started for PR 30295 at commit d3f1598.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35401/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35401/

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/35401/
Test FAILed.

Test build #130792 has finished for PR 30295 at commit d3f1598.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/130792/
Test PASSed.

Test build #130811 has started for PR 30295 at commit 5198f5f.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35421/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35421/

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/35421/
Test FAILed.

Test build #130811 has finished for PR 30295 at commit 5198f5f.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/130811/
Test FAILed.

This failed test is not related. @maropu @HyukjinKwon

retest this please

Test build #130841 has started for PR 30295 at commit 0202de9.

Test build #130844 has started for PR 30295 at commit 0202de9.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35450/

Test build #130841 has finished for PR 30295 at commit 0202de9.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Test build #130844 has finished for PR 30295 at commit 0202de9.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/130844/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/130841/
Test FAILed.

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35450/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/35450/
Test PASSed.

Test build #130859 has started for PR 30295 at commit 75bc684.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35469/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/35469/

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/35469/
Test FAILed.

Test build #130859 has finished for PR 30295 at commit 75bc684.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/130859/
Test PASSed.

Merged to master.

thanks for merging!


Hourly usage charts date picker range and bug

Date picker should be restricted to the data availability range, otherwise children get confused by choosing dates with no data availability. It also prevents children from looking back in the distant past and then not remembering how to return to the present.

Noting the bug here:
If you change the year in the date picker to say, 2000, then you'll see years 1990-2010. The only way to go to a more recent year is to reload/reset the page, click through the icons, or choose a year as close as possible, then try again. Interaction isn't immediately obvious!
A minimal fix would be to set the earliest selectable date to be earliest date we have the database. That will avoid ranges where there's no data.
Attempting to restrict selectable dates may require further customisation of the widget.


build: upgrade go core to version 5.5.1

PR summary
This PR upgrades our go core dependency to version 5.5.1
PR Checklist
Please make sure that your PR fulfills the following requirements:

[ ] The commit message follows the Angular Commit Message Guidelines.
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Current vs new behavior

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

:tada: This PR is included in version 0.18.19 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


change QuickFilter to lookup not equal

Hi,
is it possible to change [QuickFilter] to do a not equals to lookup?

See how date range filter works

I had a look at the examples however, I can't find any examples. Any particular bit of code you could point me to?

See the stored procedure grid. You'll need to and a filter to Criteria parameter of request in handler.


Redux can not be used with deep linking

Redux integration requires navigation prop to be passed to the top level navigator [1]. Deep linking also requires uriPrefix prop to be passed to the top level navigator [2]. But, a single navigator can't be passed uriPrefix and navigation prop both, at a time. This raises an error,

This navigator has both navigation and container props, so it is unclear if it should own its own state.

Is there any way deep linking can be used with Redux? Or, maybe some workaround?
Note: Related issue #1106

When passing navigation prop, you tell navigator that its navigation is coming from either Redux or parent navigator. That means it's not acting as a top-level navigator. uriPrefix is only respected if navigator is top-level.
In order to use Redux with deep linking, you should do something along these lines on your own: https://github.com/react-community/react-navigation/blob/master/src/createNavigationContainer.js#L159-L163

@grabbou Thank you so much for the solution. I followed your instruction and was able to integrate both Redux and deep linking successfully, except, the customized stack navigator and it's descendants in my implementation aren't receiving any header. (I understand, it has something to do with CardStack. But, couldn't get a clear idea from the doc. to resolve my issue)
What I am trying to achieve is just to update uriPrefix, but to retain all the other properties of StackNavigator as it is.
How should I modify the following code to generate a custom navigator that behaves exactly like a built-in StackNavigator?
or,
Am I utilizing the uriPrefix in a wrong way?
import React, { Component } from 'react';
import { createStore, combineReducers } from 'redux';
import { Text, View, Platform, Linking } from 'react-native';
import {
  StackNavigator, StackRouter, addNavigationHelpers, CardStack, createNavigator
  } from 'react-navigation';
import { Provider, connect } from 'react-redux';

const S1 = () => <View><Text>S1 text</Text></View>;
const S2 = () => <View><Text>S2 text</Text></View>;
const S3 = () => <View><Text>S3 text</Text></View>;

const S4 = () => <View><Text>S4 text</Text></View>;
const S5 = () => <View><Text>S5 text</Text></View>;
const S4n = StackNavigator({
  S4: {screen: S4, path: 's4'},
  S5: {screen: S5, path: 's5'}
});

class AppNav extends Component {
  constructor(props, context) {
    super(props, context);
    this.handleUrl = this.handleUrl.bind(this);
  }

  static router = StackRouter(
    {
      S1: {screen: S1, path: 's1'},
      S2: {screen: S2, path: 's2'},
      S3: {screen: S3, path: 's3'},
      S4n: {screen: S4n, path: 's4n'}
    }
  );

  handleUrl(url) {
    const
      { navigation } = this.props,
      { dispatch } = navigation,
      uriPrefix = Platform.OS == 'android' ? 'http://localhost/' : 'http://',
      params = {};
    let
      path = url.split(uriPrefix)[1];
    if(!path) {
      path = url;
    }

    const action = AppNav.router.getActionForPathAndParams(path, params);

    if(action) {
      dispatch(action);
    }
  }

  componentDidMount() {
    Linking.addEventListener('url', ({ url }: {url: string}) => {
      this.handleUrl(url);
    });

    Linking.getInitialURL().then(
      (url: string) => url && this.handleUrl(url)
    );
  }

  render() {
    const
      { navigation } = this.props,
      { state, dispatch } = navigation,
      { routes, index } = state,
      Component = AppNav.router.getComponentForState(state);
    let
      childNavigation = { dispatch, state: routes[index] };
    childNavigation = addNavigationHelpers(childNavigation);

    return (
      <Component navigation={childNavigation} />
    );
  }
}

@connect(state => ({nav: state.nav}))
class App extends Component {
  render() {
    const
      { dispatch, nav } = this.props;

    return (
      <AppNav
        navigation={addNavigationHelpers({dispatch: this.props.dispatch, state: this.props.nav})}
      />
    );
  }
}

const navReducer = (state, action) => (AppNav.router.getStateForAction(action, state) || state);
const rootReducer = combineReducers({nav: navReducer});

const RootApp = props =>
  <Provider store={createStore(rootReducer)}>
    <App />
  </Provider>;

export default RootApp;

@atshakil I'm having the same issue of missing the header after implementing the top-level navigator. Have you found a solution for it?

Just a FYI, getting deep linking to work with redux is pretty straightforward. When you've set up the initial deep linking support for iOS and Android, do the following:
In your root component that includes your store provider, subscribe to deep link URL events and grab the initial URL if your app is booting from a deep link:
import React, {Component} from 'react';
import {Provider} from 'react-redux';
import {Linking} from 'react-native';

import store from '../../reducers';
import RootNavigation from '../../containers/nav/RootNavigation';
import LinkRoutes from '../../configs/LinkRoutes';

export default class App extends Component<{}> {
  componentDidMount() {
    Linking.addEventListener('url', event => this.handleOpenURL(event.url));
    Linking.getInitialURL().then(url => url && this.handleOpenURL(url));
  }

  componentWillUnmount() {
    Linking.removeEventListener('url', this.handleOpenURL);
  }

  handleOpenURL(url) {
    const path = url.split(':/')[1];
    LinkRoutes(path);
  }

  render() {
    return (
      <Provider store={store}>
        <RootNavigation />
      </Provider>
    );
  }
}

LinkRoutes is a simple function that uses path-parser to extract params and routes to build a navigateAction that can be dispatched like regular actions to your redux store.
import Path from 'path-parser';
import {NavigationActions} from 'react-navigation';
import store from '../reducers';

const paths = [
  {
    routeName: 'YourScreenRoute',
    path: new Path('/base/path/:paramA/:paramB'),
  },
];

const findPath = url => paths.find(path => path.path.test(url));

export default url => {
  const pathObject = findPath(url);

  if (!pathObject) return;

  const navigateAction = NavigationActions.navigate({
    routeName: pathObject.routeName,
    params: pathObject.path.test(url),
  });

  store.dispatch(navigateAction);
};

This approach lets you nest navigators as you'd like, and handle deep linking completely separate from react-navigation.

@kristfal Thanks a ton - this worked perfectly out of the box for us.

@kristfal how did you get that store?
import store from '../reducers';
i cant dispatch the navigateAction :/

Linking.getInitialURL() always returns null as url. What could be wrong?

@alexmngn This does not work for me. routeName gets undefined.

this should be resolved. if it is not working as expected still on the latest version, please create a new issue with a runnable example on https://snack.expo.io -- thanks!


Queries sensitive to leading whitespace

Ref: https://github.com/mapd/pymapd/issues/80
When using pymapd, the Calcite backend rejects queries with leading spaces. Trimming query string prior to submission (similar to how mapdql does) would likely fix this issue across the board

This one cost me some time...was pasting the same query into mapdql where it worked - confirmed still present, Mar 25th, 2019

@mflaxman10 Where did this happen to you, pymapd?

Yes, but unfortunately I didn’t record which version and have 0.3 - 0.9  all running within the community server

On Mar 26, 2019, at 8:52 AM, Randy Zwitch<EMAIL_ADDRESS>wrote:
@mflaxman10 https://github.com/mflaxman10 Where did this happen to you, pymapd?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/omnisci/mapd-core/issues/222#issuecomment-476715188, or mute the thread https://github.com/notifications/unsubscribe-auth/ACbb66iV-TceBUfpe_uVcXjZfZVj8jfgks5vakJHgaJpZM4UbF52.

I'll re-open the pymapd issue and see about fixing it there, and then hopefully it gets fixed directly in calcite soonish

Also, fails on comment characters in SQL scripts.  It would really be nice to be able to include comments your SQL scripts and ingest that script into omni for execution.   Common comment characters are -- and /* sql code here */ fail when piped to omnisql.   The following fails.
script-with-comments.sql:
-- cleanup
drop table if exists mytmptable;
-- create the table
create table mytmptable (id int);
/home/ubuntu/installs/omnisci/bin/omnisql -db test -u mapd -p HyperInteractive < script-with-comments.sql


IPv6 integration tests for uproxy-networking

We should add integration tests that check (1) connection between IPv6 peers, and (2) connection to IPv6 endpoints.

(2) is done: https://github.com/uProxy/uproxy-lib/blob/dev/src/integration-tests/socks-echo/base-spec.core-env.ts#L283


[FEA] Remove referenced weak reference in JNI MemoryCleaner as soon as possible to save memory

Is your feature request related to a problem? Please describe.
JNI MemoryCleaner holds a set of CleanerWeakReference which can go to very large size when doing NDS testing while full GC is not excuted frequently.
For the set, please refer to:
  private static final Set<CleanerWeakReference> all =
      Collections.newSetFromMap(new ConcurrentHashMap()); // We want to be thread safe

https://github.com/rapidsai/cudf/blob/v23.06.00a/java/src/main/java/ai/rapids/cudf/MemoryCleaner.java#L148-L149
I verified that the full GC will shrink the set. But in practice the full GC may be not executed for a long time.
And I verified there is no leak on the resources that the set references.
Not sure if this large size set can cause OOM, but we can remove the closed items as soon as possible to save memory.
Describe the solution you'd like
The MemoryCleaner.Cleaner already has isClean,  because the cleaned object will not be used again.
We can safely remove the cleaned items.
Refer to:
https://github.com/rapidsai/cudf/blob/v23.06.00a/java/src/main/java/ai/rapids/cudf/MemoryCleaner.java#L144
Update the thread code to remove cleaned items
https://github.com/rapidsai/cudf/blob/v23.06.00a/java/src/main/java/ai/rapids/cudf/MemoryCleaner.java#L182-L207
Additional context
The K8s will kill executor if the memory of the Pod running this executor exceeds the definded value which is typically spark.executor.memory + spark.executor.memoryOverhead and report OOM which is a kind of K8s OOM.
Not sure if the large size of CleanerWeakReference is the cause.

@revans2  @abellina  Please check.

I think this would be a good change that we should do. The reality is that if the OOM killer is kicking in for kubernetes or year or whatever because of things only on the JVM heap then the memory limit is configured incorrectly.  But we should still do our part to try and reduce that limit.

Copied this issue to cuDF: https://github.com/rapidsai/cudf/issues/13412

Close it via https://github.com/rapidsai/cudf/issues/13412


I am working on the Sensitivity section

I am writing the Sensitivity Analyses section, so please don't edit it. If you can avoid it also don't edit custom-knitr-variables.R either as I'm adding loads of new variables for the MCMC sensitivity values (around line 550).

All done, disregard

All done, disregard


Improve scan-proofs

In the case where a sighint doesn't exist on the server, that error was getting dropped on the floor. It should have been marked as a client failure. This actually probably makes up a good portion of the server=no,client=ok cases that I was seeing. Those were the reason for making proofd check PERM_FAILUREs in the first place. So, whoops. Some of those were valid, just not the ~5000 count that were due to this bug. Anyway, fixed.

Saving the cache is pretty slow because it's 16MB (~2s). This update makes it save only when something has changed. Sqlite would be better, but I don't it's worth it.

Skip deleted users.

r? @maxtaco

👍

Sorry this took so long!


[WIP] tiled matmuls for faster testing

See IREE PR https://github.com/iree-org/iree/pull/17294

Closing for now, may return to this later.


Language Problem

With the current version I get a language error and the adapter refuses to work.
2023-01-21 12:26:57.239 - error: bluelink.0 (19139) Error in login/on function
2023-01-21 12:26:57.241 - error: bluelink.0 (19139) The language code DE is not managed. Only cs, da, nl, en, fi, fr, de, it, pl, hu, no, sk, es, sv are.

Ok got it, need to choose in the menue...


Increment Version

@JuliaRegistrator register() ACTRModels v0.6.5

Registration pull request created: JuliaRegistries/General/28153
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.5 -m "<description of version>" 98c8048aeb04809b623d66a77338ba8c890bc372
git push origin v0.6.5

Registration pull request created: JuliaRegistries/General/28153
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.6.5 -m "<description of version>" 98c8048aeb04809b623d66a77338ba8c890bc372
git push origin v0.6.5


Apache Arrow does not support FieldRef to list of structs

Problem Statement
Apache Arrow does not support field reference to a list<struct>

import duckdb

ds = lance.dataset("./coco.lance").scanner(columns=["id", "annotations.label"])

Error:
Traceback (most recent call last):
  File "/Users/lei/work/lance/./query.py", line 6, in <module>
    ds = lance.dataset("./coco.lance").scanner(columns=["id", "annotations.label"])
  File "pyarrow/_dataset.pyx", line 271, in pyarrow._dataset.Dataset.scanner
  File "pyarrow/_dataset.pyx", line 2328, in pyarrow._dataset.Scanner.from_dataset
  File "pyarrow/_dataset.pyx", line 2174, in pyarrow._dataset._populate_builder
  File "pyarrow/error.pxi", line 100, in pyarrow.lib.check_status
pyarrow.lib.ArrowInvalid: No match for FieldRef.Name(annotations.label) in id: int64
width: int64
height: int64
file_name: string
image: struct<data: binary>
annotations: list<item: struct<area: double, box: struct<xmax: double, xmin: double, ymax: double, ymin: double>, label: string, label_id: int64, segmentation: struct<height: int64, polygon: list<item: list<item: double>>, rle: list<item: int64>, type: int64, width: int64>, supercategory: string>>
__index_level_0__: int64
__fragment_index: int32
__batch_index: int32
__last_in_fragment: bool
__filename: string

Expected Behavior
Using annotations.label should returns values with type list<struct<label: str>> , a subset view of the original annotations list<struct>

Reported in Arrow's JIRA https://issues.apache.org/jira/browse/ARROW-17540

@eddyxu we control this now don't we? i think we could make list-of-struct a lot easier to work with?


Can't make new characters

Describe your problem here.
Every time I press reload image, I get this.

Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
no.

You have to add them


Support xDS server subscription to client resources

In order to be able to gain knowledge of resource readiness (https://github.com/envoyproxy/envoy/issues/5174), a management server today needs to resort to OOB techniques to learn whether a listener (for example) has successfully been bound to a port. There are other examples of this, for example resources failing to warm due to dependency failure. It's not sufficient to rely on xDS's inbuilt ACK/NACK mechanism, since these events often occur long after DiscoveryResponse acknowledgement.
We've been brainstorming approaches here and one that seemed highly attractive in UDPA-TP discussions was to make xDS fully symmetric (similar to what MCP does), allowing the management server to subscribe to resources produced from the client. This reverse pub-sub would then allow for details that are today made available in configdump or CSDS to be supplied directly to a management server inline in an ADS stream.
Ideally we have a design doc to start this work that examines how we can retrofit this into v3 xDS so that we can gain benefit today.

CC @costinm @jpeach @mattklein123 @envoyproxy/api-shepherds

I do like the idea of allowing the xDS protocol to be symmetric.  There are other use-cases, like LRS, that may also be addressed by this approach.
That having been said, I do wonder whether we can do something simpler for the specific problem of having the client report config health to the server.  It seems like we could solve that problem by extending the ACK/NACK mechanism built into the protocol.  For example, we could extend DiscoveryRequest to exlicitly indicate (a) the config version currently being used, (b) the config version currently being warmed up, and (c) the last config version that attempted to warm and was unsuccessful.

This is possible, the main counter-argument being I think that this is going to increase the complexity of config version handling in xDS, and it's already pretty complicated.

It seems like most of the complexity in the current mechanism is due to the strange way that version and nonce interact in requests.  I don't think there's actually anything inherently complicated about this problem, and I think there are other ways of structuring it that would be very straightforward.  If we just explicitly indicated the state of a given version in the request, then the need for nonce would basically go away, and I think this would get a lot simpler.

One of the problems you will run into with this is that there isn't a "config" being warmed. Once a config is accepted, you have a bunch of independent listeners or clusters being warmed. There would need to be some additional state tracking to make this work, and it might not be what the server actually wants. It wants to know whether listener X is active, not necessarily the details of X's earlier configuration.
It's a reasonable alternative to consider, but we should do some due diligence to find the most effective way to do this in v3 generally with minimal complexity.

That's a fair point.  So perhaps what we need is to report state on a per-resource basis, rather than a per-response basis.  And once we've done that, it might not actually be simpler than having a separate resource published to indicate state.
I guess let's wait to have a concrete proposal and then we can debate the details.  Thanks!

And ideally an incremental approach/implementation: we can start with just adding a Resources[] entry to DiscoveryRequest.
Maybe also expose a way for WASM/modules to initiate sending of such DiscoveryRequest and getting back the associated DiscoveryResponse.

Also related to #9447

I plan to work on a design for this later this quarter.


@conda-forge-admin,please add bot automerge

Additional comment:
No response

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/celluloid-feedstock#2.


Add zelnode params changes with fork height

Add ability to easily change the benchmark public key into the chainparams with a timestamp ( must make similar changes to zelbench
Added forking changes that push the zelnode confirmation expiration to 80 blocks (from 60)
Reformatted chainparams so the lines lineup

adjust for TODO from #113

#127


Add django allauth openId connect provider when it is merged

In django-allauth there is an open PR to include openIdConnect provider into allauth https://github.com/pennersr/django-allauth/pull/3165 and then it would be nice to have a solution like in this draft commit in paperless included into cvat https://github.com/paperless-ngx/paperless-ngx/pull/1746. We have a private network in azure so we cant use solutions like Datawiz, so it would be nice to just add our openid connect server into cvat without any custom code

@muhmuhhum , the PR https://github.com/pennersr/django-allauth/pull/3165 a has been merged. Thank you for the explanation and the request.


AKS ssh scale set fetch command error

While executing the command to get the scale set name the command shown in the docs throws an error.
az vmss list --resource-group $CLUSTER_RESOURCE_GROUP --query [0].name -o tsv
zsh: no matches found: [0].name

The fix that works for me is:
az vmss list --resource-group $CLUSTER_RESOURCE_GROUP --query '[0].name' -o tsv
aks-xxxxxxxx-xxxxxxxx-vmss

Working on a PR to fix this.

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

ID: 3b81a147-db1c-b92f-88d1-6dd0991a72fe
Version Independent ID: f5a2c949-498f-5848-d89c-031d1a757120
Content: SSH into Azure Kubernetes Service (AKS) cluster nodes - Azure Kubernetes Service
Content Source: articles/aks/ssh.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

Thanks for creating the PR and contributing to Microsoft docs. The PR will be reviewed by the author and merged. The changes will be live shortly after.


Benchmark how long it takes for 50 new CRs to be reconciled

This is the first and most basic performance test.
I want to see, for each operator type, how long it takes after creating 50 memcached instances (CRs), for the CRs to be reconciled.

Just doing 5 for now on my local computer:

Operator Type
Run 1
Run 2
Run 3

Ansible
22.06s
TODO
TODO

Go
TODO
TODO
TODO

Helm
TODO
TODO
TODO

A couple things I'm running into:

I can't figure out any way with Go operator samples to see a status field that changes once it finishes its reconciliation.
Each of the three operators has a slightly different default CR (Helm's being wildly different):

go: https://github.com/operator-framework/operator-sdk-samples/blob/master/go/memcached-operator/config/samples/cache_v1alpha1_memcached.yaml
ansible: https://github.com/operator-framework/operator-sdk-samples/blob/master/ansible/memcached-operator/config/samples/cache_v1alpha1_memcached.yaml
helm: https://github.com/operator-framework/operator-sdk-samples/blob/master/helm/memcached-operator/config/samples/cache_v1alpha1_memcached.yaml

I was using the following for Ansible:
# For Ansible, wait for reconciliation to update to 'Success'.
- name: Wait for {{ operator_type }} Memcached reconciliation to complete.
  k8s_info:
    api_version: cache.example.com/v1alpha1
    kind: Memcached
    name: "{{ 'memcached-%02x' | format(item) }}"
    namespace: default
  register: memcacheds
  failed_when: false
  when: operator_type == 'ansible'
  until: memcached_pod.resources[0].status.conditions[0].reason == 'Successful'
  delay: 3
  retries: 60
  loop: "{{ range(0, memcached_cr_count) | list }}"

But to be a little more fair with comparing the operators, I'm going to do a different test for the amount of time everything takes to be ready—since Go's Status field on the Memcached resource behaves differently, and in some cases never appears on the resource even if the managed Pod is ready and running...

Wait for there to be as many memcached pods running as are expected.
Wait for all the pods to be 'Ready' using kubectl wait. I was trying to figure out a way to do it with Ansible directly, but I couldn't, so I reopened this issue I had opened a while back: https://github.com/ansible-collections/community.kubernetes/issues/18

Also opened https://github.com/operator-framework/operator-sdk-samples/issues/154 to see if we can get more uniformity among the examples.

Finally getting to a point where I can at least measure the pods readiness for Ansible + Go + Helm.
I'll have to try to figure out https://github.com/operator-framework/operator-sdk-samples/issues/153 before I think I'll be able to benchmark #4 though.

Reopening—one thing that could affect Ansible's score negatively is the fact that since it's first, the memcached image has to be pulled during it's benchmarking, which could add at least a second or two (it's not a huge image, but it does need to be downloaded by Kubernetes the first time).

Switching from 50 to 25 since that's easier to do on a small and/or local cluster fitting in < 8 GB of RAM.

Interesting finding: It seems the Helm operator either gets locked up or exhausts the limited memory in the GitHub Actions CI environment if I bump the Memcached instance count to 25.
So might try 15 instead.

No matter how I run the benchmark, Helm operator is way way slower than Ansible on my local Mac, but a little faster than Ansible on GitHub Actions... this is so weird.
Looking in the controller logs, the only real thing I noticed out of place was a log entry:
I0828 18:55:22.507325       1 request.go:621] Throttling request took 1.098742s, request: GET:https://<IP_ADDRESS>:443/apis/coordination.k8s.io/v1beta1?timeout=32s

Maybe locally something is throttling the rate at which the operator is creating resources? It did slowly roll out the resources, it seemed to take a while for each one.

I wanted to get the EC2 driver working with Molecule for ease of use (see #9), but it looks like that might not be as simple and clean as I'd want.
So instead, I'm going to boot up an EC2 instance manually in the Ansible AWS account (m5.large), and then install Kind and the other dependencies on it, clone this repo, then run the tests manually on it.

I'm having some trouble now that I have an automated EC2 build/destroy loop going... During benchmarking, the first few times the kind cluster would come up correctly, but now it seems to get stuck waiting for the Kubernetes API to load.
Maybe a CPU or memory or disk issue... might try a larger instance :/

Benchmarks are being aggregated into a Google Sheet that will be used to produce some results for a presentation Tim and I are doing at AnsibleFest. Closing this issue.


[FLINK-29420][Build] Upgrade Zookeeper to 3.7.2

What is the purpose of the change

Update Zookeeper to 3.7.2

Brief change log

Updated POM and testcontainer setup

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): yes
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@MartijnVisser want to work on this issue

@MartijnVisser I took a look. It seems that the failed reason is that version 3.7.2 of flink-shaded-zookeeper-3 has not been released/supported.(https://github.com/apache/flink-shaded/blob/d18d236329cecd1dbad8ceba470d8b30f2e8ffd4/flink-shaded-zookeeper-parent/flink-shaded-zookeeper-37/pom.xml#L36)

Hello, this PR is important because there is a CVE ( CVE-2023-44981 ) on zookeeper < 3.7.2

superseded by https://github.com/apache/flink/commit/7e11de657153eb31de8e8c0cfbabce365eb1c57e#diff-d746de8964721a0a7ecfe91df19d3c5047d2adc9ba35384e2f751524037392ec


UI improvements for calibration tab

I am testing #31 and noticing some necessary and nice to have features for the Calibration UI.

(necessary) Instead of LC-A and LC-B drop downs (which don't seem wired at this point), it is better to add drop-down for calibrated states, which can be names of the channels in the Config group. Selecting that drop-down should set the state and update the Micro-Manager Preview window.

(necessary) after the "Run Calibration" button is clicked, the Plot at the bottom does not refresh (likely during while computing the black level or doing the coarse search for extinction). The plot should be updated throughout the calibration, to provide feedback on black level. After black level estimation and coarse search, it would be good to limit the display range to the intensity values read during optimization.

(nice to have) The extinction ratio is useful to read only to 2nd decimal place, please truncate.
It should be typeset in larger font to be easy to see and can occupy one line instead of two e.g., Extinction= 192.18

(necessary) Instead of LC-A and LC-B drop downs (which don't seem wired at this point), it is better to add drop-down for calibrated states, which can be names of the channels in the Config group. Selecting that drop-down should set the state and update the Micro-Manager Preview window.
So this is actually for voltage space calibration where the user must select which DAC output corresponds to which LC.  I can remove this for the beta release.  I am not sure if this drop down feature is necessary in recOrder since the user can already accomplish the same thing by selecting the state in the Micromanager UI.
(necessary) after the "Run Calibration" button is clicked, the Plot at the bottom does not refresh (likely during while computing the black level or doing the coarse search for extinction). The plot should be updated throughout the calibration, to provide feedback on black level. After black level estimation and coarse search, it would be good to limit the display range to the intensity values read during optimization.
I agree here I can update the plot during the black level search.
(nice to have) The extinction ratio is useful to read only to 2nd decimal place, please truncate.
It should be typeset in larger font to be easy to see and can occupy one line instead of two e.g., Extinction= 192.18

agreed here I can implement this.

Updated in #31


Plugins tests

first part of the tests for the plugin, decided to push it now, because it will become too unwieldy

no longer required to wait for document ready
add an extra assertion to the messages

as usual it's easier to check https://github.com/FinalAngel/django-cms/pull/109/files?w=1 because changes in the cms.plugins.js are mostly whitespace
also the fixture is quite big, but it's a copy from the source, no need to check it too thoroughly :)

Overall looks good :+1:


Mysql remote connections

Hi,
When I fill in the following at step 4.iii:
$ sf3 doctrine:database:create

I get this error:
[Doctrine\DBAL\Exception\DriverException]
  An exception occured in driver: SQLSTATE[HY000] [1130] Host 'dockersymfony_php_1.dockersymfony_default' is not allowed to connect to this MySQL server

I think it happened because remote connections in mysql is disabled?
Here is my parameters.yml
# This file is auto-generated during the composer install
parameters:
    database_host: mysqldb
    database_port: null
    database_name: symfony
    database_user: root
    database_password: root

Thanks.

Sorry, I've no idea :(
I just try with a Symfony 3.1 and everything seems to works fine !
Try to remove your .data folder

Most of the time the root user is a management user only, and is only allowed to connect from localhost.
Make sure you are using the right database_host. This has to be the same as the database container name.

We can make remote connection directly on "db" container IP:
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' dockersymfony_db_1


Custom file type icon is not correctly resized in "Tiles" view option

Category

[ ] Question
[ ] Documentation issue
[x] Bug

Expected or Desired Behavior
I have registered the following file handler:
{
  "version": "2",
  "fileTypeIcon": {
    "png1x": "https://localhost:3000/ball.png"
  },
  "actions": [
    {
      "type": "open",
      "url": "https://localhost:3000/open",
      "availableOn": {
        "file": { "extensions":  ["*.ball"] },
        "web": {}
      }
    }
  ]
}

When I list the files with the .ball extension in OneDrive folder using the Tiles view option I am expecting that the icon image is correctly resized in order to fill completely the region of the tile.
Observed Behavior
The custom icon is not resized as expected:

I've also tried adding the png1.5x and png2x keys to the fileTypeIcon configuration but the behavior didn't changed.
Steps to Reproduce

Register the above file handler to a specific app registration.
Enable the app on a OneDrive for Business account.
Go to OneDrive on cloud and open a folder containing the files with the .ball extension.
Switch the view option to Tiles.

Thank you.

As part of a repository clean up effort we are closing older issues. If this issue remains, please: open a new issue, reference this issue, and provide any additional details that may help in resolution. Thank you for your understanding as we work to improve our responsiveness.


Autocomplete on local variables

Manage autocomplete on function's local variables.
public function test()
{
     $x = new \DateTime();
     $x->{autocomplete}
}

@see branch "autocomplete"

Nice work, the functionality included 0.4.0 is shaping up fairly well, this plugin is getting better and better ;-).
An idea would also be to support the syntax that some IDE's (such as PHPStorm) use for hinting the type of a variable, e.g.
public function foo()
{
    /** @var \Namespace\Class $a */
    $a = $this->someMethod()->getSomeProperty();

    if ($someCondition) {
        $a-> // shows members of \Namespace\Class, even if getSomeProperty() returns something else.
     }
}

Which can even be used to define the type of $this (useful in e.g. include-d files):
/** @var \Namespace\Class $this */

Intellij IDEA does this like /* @var $this yii\web\View */

Hello,
Normally
public function foo()
{
    /** @var \Namespace\Class $a */
    $a = $this->someMethod()->getSomeProperty();

    if ($someCondition) {
        $a-> // shows members of \Namespace\Class, even if getSomeProperty() returns something else.
     }
}

should work.
As describe in the README :
In the code, if you don't have autocompletion, you can had a comment **just before** the line with a @var definition
So you can't define the variable type everywhere in the code, I just parse the comment right before the variable declaration (you can omit the variable name, just @var \Namespace\Class will work

That's pretty neat, at some point in the future it would be neat to have this also work for $this (not sure if it does right now).
Another thing that might be relevant for this ticket is autocompleting local variables outside functions as well as inside them, for example if I have a file that's require-d somewhere with:
<?php

/** @var \Namespace\Class $a */
$a = someMethod();
$a->{get autocompletion as well}

Hello,
It works on $this since a long time ! ^^ (But only saved options will be available, and the file must not contains fatal errors when saved)
For the autocomplete outside a function, I don't really know. Perhaps I have to allow it when the cursor is outside a class.

Please consider using this with the following syntax:
/* @var $variable \Namespace\Class */

as @alexandernst points its used in Intellij IDEA and also is used in Netbeans

I've been toying a bit with variable autocompletion and have a very simple variant working here [1] (starting with commit 86609150f27e54e6d6170593e734819e369f9585). This seems to work for most of the local variables that are assigned a new object (i.e. new SomeType) and it may need improvement, but if this helps you in any way, feel free to use it (or I could create a pull request).
[1] https://github.com/hotoiledgoblinsack/atom-autocomplete-php/commits/experiment-variable-autocompletion

I'm closing this issue.
A lot has been done, everything else is already in issues.


Jest - SyntaxError: Unexpected token 'export

Hello,
I have implemented webAuthn on my current login page thanks to your library.
But now when I'm running the already existing test this error is displayed :
Test suite failed to run
Jest encountered an unexpected token

Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.

Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.

By default "node_modules" folder is ignored by transformers.

Here's what you can do:
 • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
 • If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript
 • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
 • If you need a custom transformation specify a "transform" option in your config.
 • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

You'll find more details and examples of these config options in the docs:
https://jestjs.io/docs/configuration
For information about custom transformations, see:
https://jestjs.io/docs/code-transformation

Details:

[...]/node_modules/@simplewebauthn/browser/dist/bundle/index.js:291
export { browserSupportsWebAuthn, browserSupportsWebAuthnAutofill, platformAuthenticatorIsAvailable, startAuthentication, startRegistration };
^^^^^^

SyntaxError: Unexpected token 'export'

  1 | import { Button, FormHelperText, InputAdornment, Snackbar, TextField, useMediaQuery } from '@material-ui/core';
  2 | import Alert from '@material-ui/lab/Alert';
> 3 | import { browserSupportsWebAuthn, browserSupportsWebAuthnAutofill, startAuthentication } from '@simplewebauthn/browser';

I spent a lot of time trying to resolving this error with no success ...
I already tried :

https://github.com/MasterKale/SimpleWebAuthn/issues/136#issuecomment-893506455
transformIgnorePatterns option from jest

I think my main issue is that I do not really understand why this error happen.

Hello @EdouardPauw, sorry for the late reply. For that particular problem, it's related to the fact that Node historically only supported CommonJS modules, but EcmaScript modules (a.k.a. "ESM") is a newer syntax for importing packages that leverages a different module loading scheme. There are more comprehensive guides on the differences between the two, suffice to say that, before Node 14, something had to convert the imports between the two. TypeScript typically handles this if your codebase gets transpiled by it before any code is sent to Node, but if you're using SimpleWebAuthn in a JavaScript codebase then you'll likely need to leverage some capability hopefully in Jest to handle this conversion.
Have you had a chance to try the potential solution at https://jestjs.io/docs/ecmascript-modules that's mentioned in the error message?

Hello @MasterKalen, thank you for your answer. I did not have time to work on it the last days but I finaly found the solution today!
My mistake was to use transformIgnorePatterns but only transform tsx files.
My jest configuration was :
...
  transform: {
    '^.+\\.tsx?$': 'babel-jest',
  },
  transformIgnorePatterns: ['/node_modules/(?!(@simplewebauthn)/)'],

The solution I found is :
...
  transform: {
    '^.+\\.js$': 'ts-jest',
    '^.+\\.tsx?$': 'babel-jest',
  },
  transformIgnorePatterns: ['/node_modules/(?!(@simplewebauthn)/)'],

Thanks a lot for your time ! :)

I'm glad to hear you got it working correctly. Perhaps I should start documenting these framework-specific fixes... 🤔


Broken Node.js link

The Node.js "Windows, Linux, macOS" link tries to go to https://github.com/Azure-Samples/cognitive-services-speech-sdk/tree/master/quickstart/js-node, and that page isn't found.

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

ID: e4b55e56-55a1-d635-6bea-271dc361d676
Version Independent ID: 8e9cb28f-c133-f310-3c7d-3a3b7e85f69d
Content: Quickstart: Recognize speech from a microphone - Speech Service - Azure Cognitive Services
Content Source: articles/cognitive-services/Speech-Service/quickstarts/speech-to-text-from-microphone.md
Service: cognitive-services
Sub-service: speech-service
GitHub Login: @erhopf
Microsoft Alias: erhopf

Fixed in https://github.com/MicrosoftDocs/azure-docs-pr/pull/95645

#please-close


Fix show/hide events and emits

fixes #1819
BEGIN_COMMIT_OVERRIDE
fix!: change all props starting skip or hide to start with no
feat(show/hide)!: make components that show/hide use a composable useShowHide
fix(show/hide): emit shown/hidden after transition
fix(show/hide): prevented emit events restore modelValue
feat(show/hide)!: add props lazy and unmount-lazy
fix(show/hide)!: many animation fixes
feat(show/hide): rename toggle prop to show, it opens the component with animation
feat(show/hide): add prop backdrop-first to animate backdrop first
feat(show/hide): add prop initial-animation to animate on initial render
feat(show/hide): add prop visible to show without animation
feat(BPopover): add hideMargin prop to add margin to the hide boundary
fix(BPopover): correctly calculate size on some edge cases
fix(BDropdown): correctly calculate size on some edge cases
fix(BPopover)!: change slot prop showState to visible
fix(BPopover): fire hide event only once
fix(BPopover): better hide functionality, called only once
fix(BPopover): Correct color arrow when arrow on top
fix(BPopover)!: remove prop persistent, use lazy instead
BREAKING CHANGE: many changes to show/hide components (BCollapse,BDropdown,BModal,BOffcanvas,BPopover,BTooltip,BToast) and rename props starting with skip or hide to start with no
END_COMMIT_OVERRIDE
What kind of change does this PR introduce? (check at least one)

[x] Bugfix :bug: - fix(...)
[x] Feature - feat(...)
[ ] ARIA accessibility - fix(...)
[ ] Documentation update - docs(...)
[ ] Other (please describe)

The PR fulfills these requirements:

[x] Pull request title and all commits follow the Conventional Commits convention or has an override in this pull request body This is very important, as the CHANGELOG is generated from these messages, and determines the next version type. Pull requests that do not follow conventional commits or do not have an override will be denied

@xvaara merge conflict detected :robot:

I think this PR needs an addition for BDropdown, where the shown Event is fired before the <ul> Element is positioned asynchronously by Floating UI. This leads to problems when e.g. trying to focus elements inside the dropdown right after opening it.
I would expect this to work similar to the shown.bs.dropdown Event of Dropdown in Bootstrap 5:

Fired when the dropdown has been made visible to the user and CSS transitions have completed.
Source: https://getbootstrap.com/docs/5.0/components/dropdowns/#events

As a solution idea, the useFloating composable returns an isPositioned boolean that could be used together with the open property: https://floating-ui.com/docs/vue#effects and we could wait for it to become true.
However this would require hiding and showing the <ul> only via v-if, not with v-show. I was thinking of opening a PR here, but implementing the isPositioned was problematic, altough it seems to be working as intended: https://github.com/floating-ui/floating-ui/issues/3017
So maybe a simple setTimeout in BDropdown is an easier fix for this problem as well, but could sometimes not be sufficient.
In BPopover it is probably not an issue because a setTimeout is already applied before the shown Event is fired.

demo for this pr: https://stackblitz.com/edit/github-rzxbjv-jghknk?file=src%2FApp.vue

I don't see an obvious way to address this, but the generated HTML is considerably more verbose, even when lazy=true. This is most obvious with tooltips, where there might be a large number of them on a page. I don't think this blocks anything, but if there is a reasonable way to pair down the generated HTML on lazy=true that would be great.
 Lmk when it's done

It was ready, that's why I asked for the review.


Update to CRD44.1

CRD44.1 is released and the language data needs to be updated.
https://cldr.unicode.org/index/downloads/cldr-44#h.nvqx283jwsx
There is a pull request to the original project with an update to CRD43: https://github.com/rspeer/language_data/pull/2

Done with 02c25c3f126af742b0e247fde9d01ae0044c424a


Specify process for naming future architectures

Signed-off-by: Timothy Hobbs<EMAIL_ADDRESS>

I think it makes sense to also have something like:
New entries SHOULD be submitted to 1 for standardization.
which is along the lines of what you had in 2.  I agree with
@stevvooe that the OCI will not own the namespace 3, but we can
encourage consistency between implementations without requiring it.

@wking improved the language, thanks.

LGTM


Crash returns success value

I expect an exception being thrown would result in a non-0 return value.  This indicates to me that the operation succeeded with a warning output.  Instead it should return a non-0 value.
$ az component update
Exception:
Traceback (most recent call last):
  File "/usr/local/az/lib/python2.7/site-packages/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/usr/local/az/lib/python2.7/site-packages/pip/commands/install.py", line 317, in run
    prefix=options.prefix_path,
  File "/usr/local/az/lib/python2.7/site-packages/pip/req/req_set.py", line 736, in install
    requirement.uninstall(auto_confirm=True)
  File "/usr/local/az/lib/python2.7/site-packages/pip/req/req_install.py", line 742, in uninstall
    paths_to_remove.remove(auto_confirm)
  File "/usr/local/az/lib/python2.7/site-packages/pip/req/req_uninstall.py", line 115, in remove
    renames(path, new_path)
  File "/usr/local/az/lib/python2.7/site-packages/pip/utils/__init__.py", line 267, in renames
    shutil.move(old, new)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 303, in move
    os.unlink(src)
OSError: [Errno 13] Permission denied: '/usr/local/az/bin/activate-global-python-argcomplete'

$ echo $?
0

This is again related to https://github.com/Azure/azure-cli/issues/1050.
Fixing that will make this return the correct exit code.

Closing as this is covered by #1050


Fix Syntax Error

about
I deleted the "lblt" & "pft" snippets has "(".
Fix syntax error in Rails 5.

Thank you for the bug fixed